Re: [gentoo-dev] status of bugs blocking gcc-4.8.3
On Saturday, 25 October 2014 12:47:21 CEST, Luca Barbato wrote: The ABI mismatch is due the library not being versioned properly as "usual"? Please note that this would be a "hard thing to do". This is not just a matter of calling an appropriate version of a given function; there are no guarantees about the internal layout of the data structures, etc. Furthermore, portions of C++ code might be inlined, so whenever you have a library compiled with different GCC versions, these cannot exchange any data which embed a C++11 data type inside. That's quite a bummer -- std::string and std::list have both changed in C++11 (forbidden ref-counting of std::string and O(1) size of std::list::size()). The upstream's promise is that the ABI will eventually ebcome stable when they remove the "experimental" label on their C++11 support. I suspect that the only solution would be a full ABI version number change at that time, though, and people want to avoid doing this because that will of course break all C++ programs out there. It would be terrific if the GCC guys provided a reasonable roadmap, because saying "we support C++11" while also saying "don't combine code built by 4.7 and 4.8, that's totally unsupported" is a bit strange. Yes, limited time and limited manpower and what not, but it's still something which makes using all of the C++11 features a very risky business. Cheers, Jan
Re: [gentoo-dev] How to support C++11 in libraries?
On Friday, 20 December 2013 12:56:43 CEST, Sven Eden wrote: And no, the languages are _not_ "source-incompatible". That would be a scandal! You might argue about this, but that doesn't change these facts. This is absolutely valid C++98 program: jkt@svist ~ $ cat foo.cpp int main() { auto int foo; return 0; } jkt@svist ~ $ g++ -std=c++98 -pedantic foo.cpp jkt@svist ~ $ echo $? 0 ...which will *not* build under the C++11 mode: jkt@svist ~ $ g++ -std=c++0x foo.cpp foo.cpp: In function ‘int main()’: foo.cpp:2:14: error: two or more data types in declaration of ‘foo’ Yes, -Wc++0x-compat warns about this, yes, it's included in -Wall, but it does not change the fact that there *is* code out there which does conform to C++98 standard, does *not* try to "outsmart the compiler", and which will not build in the C++11 mode. Do we really have to be having this discussion? Cheers, Jan
Re: [gentoo-dev] How to support C++11 in libraries?
On Friday, 20 December 2013 10:00:43 CEST, Martin Vaeth wrote: The example with string reference-counters which you gave is IMHO typical; one would really need to write strange code to make it work *with* reference counters but break without. Hard to believe that this happens in practice. What *will* happen in practice is that the execution speed changes (probably getting slower, but there might also be exceptions). You have not considered the implications of the updated requirements. With std::string, this might be hard to understand within all the layers of template wrapping, but consider std::list instead. The "old" (C++98/C++03) std::list is implemented by containing exactly one member, the struct _List_node_base. This struct has exactly two pointers inside, one for the next item and one for the last. This layout cannot be changed without breaking the binary compatibility; it is effectively made public because GCC's standard library does not use the PIMPL idiom. Now, this particular layout (which we just established cannot be changed without breaking the ABI) means that std::list::size() has O(n) time cost simply because it has to traverse the whole list to compute the number of items. The C++11 standard, however, mandates the time complexity to be O(1). This means that there will be a very visible change, at least for std::list. I won't speculate on how the upstream is going to solve this, but I do not expect that the end result will allow linking a translation unit built for C++98 by GCC <= 4.8 with one built for C++11 by the new compiler. Jan
Re: [gentoo-dev] How to support C++11 in libraries?
On Thursday, 19 December 2013 17:29:19 CEST, viv...@gmail.com wrote: just a question, what would do -fabi-version=6 added to CXXFLAGS even w/o C++11? I believe that -fabi-version is for "low level bits" at the level of e.g. identifier mangling. It cannot affect whether a std::string is refcounted or not, or whether a std::list contains a member for O(1) size() behavior -- these require modifications to the actual memory layout of the class. Cheers, Jan
Re: [gentoo-dev] How to support C++11 in libraries?
On Thursday, 19 December 2013 16:00:13 CEST, Ian Stakenvicius wrote: A change in profiles? 14.0/* adds that to the default CXXFLAGS in base, new stage3's etc are all rolled with this. We recommend migration to 14.0 profile and have a check somewhere about "-std=c++11" missing from CXXFLAGS in case it's overridden in make.conf, so users put it in place? Before you invest any more time in this, please understand that C++98 and C++11 are source-incompatible. There is no way to expect that a package builds fine when you throw -std=c++11 on it. And even if you patched them all, you are breaking an unknown number of 3rd party software over which you have exactly zero control. Also note that as of gcc 4.8, the C++11 support is still labeled as experimental and upstream developers announced they will introduce ABI breaks in future. With kind regards, Jan
Re: [gentoo-dev] How to support C++11 in libraries?
On Thursday, 19 December 2013 10:18:55 CEST, Michał Górny wrote: Would it be possible to have a consistent ABI for both C++03 and C++11? The simpler changes like adding new fields can be backported quite easily (even if it would mean having dummy fields in C++03), I have no idea about the more complex changes. I don't know, but from a bystander's point of view, I surely hope that it will be possible. Otherwise there would be no option but providing a multilib-like setup for C++11, after all. Some messages on gcc's ML indicate that there are software vendors who are *very* afraid of doing the SONAME change again. Given that C++11 forbids a refcounted std::string while libstdc++ currently use just that for its implementation, I suspect that the upstream developers have a very interesting problem to solve. (And there's much more.) It is pretty clear to me that even the gcc people have not reach a consensus on how the ABI of the standard library will look like in 4.9, so maybe it is premature for us to talk about how to solve this. The ball is on their side. Well, if they considered the C++11 ABI in gcc-4.9 stable, we could consider changing the default to C++11. Then, we could do our bump/switch thing as a matter of gcc-4.9 upgrade problem. To put things into perspective, *if* the ABI changes and if the new version is compatible between C++98 and C++11, then we're talking something very similar to an upgrade from GCC 3.3. Cheers, Jan
Re: [gentoo-dev] How to support C++11 in libraries?
On Thursday, 19 December 2013 09:44:38 CEST, "C. Bergström" wrote: libboost.so (or any really popular lib.. Qt..) built with -std=c++11 breaks abi As I said, the problem is more complicated. Qt5 built with the C++11 support does not break its ABI compared to usign the C++98 mode. Boost is in a category of its own because they do not provide a stable ABI to begin with. Jan
Re: [gentoo-dev] How to support C++11 in libraries?
On Thursday, 19 December 2013 09:35:14 CEST, Michał Górny wrote: And how is this an issue to the major distributions? Binary distros can do a simple switch with standard all-package upgrade and forget about it. Like they usually do. Only people who built from sources have to think about it. Wrong; the binary-only distributions have to ship a ton of compat-$foo packages, if only for compatibility with 3rd party software. At least that's what RHEL has been doing for ages. Jan
Re: [gentoo-dev] How to support C++11 in libraries?
On Thursday, 19 December 2013 02:41:55 CEST, hero...@gentoo.org wrote: I'd like to make an analogy to the version bump of gcc[1]. We (gentoo) decide to support c++11 officially or not. If so, open a tracker bug to push it globally. If not, patch lldb to support non-c++11, or leave it up to the user to fiddle with the CXXFLAGS, where we only point the user by to proper docs. To be honest, I do not really see a link between the "let's bring in a new version of compiler, it is a bit stricter in some situations, but these were bugs anyway, like missing headers or unfounded assumptions about memcpy()" with "let's support a new version of language which produces object files with different ABI". Perhaps a Python 2.6 vs. Python 3.3 is a better analogy? Anyway, GCC 4.8 is pretty clear that the C++11's support is still experimental [1] and subject to change [2]. The upstream developers have announced that they plan to break the ABI of the code using C++11 features in 4.9 [3]. Please also note that this is a very complicated problem, much more difficult than "code uses C++11's features -> it is incompatible". So far, the only known incompatibility is in the way STL is built. The impact of the other changes like the modified signatures of a couple of STL methods is not clear to me (and I did search for an ultimate answer). Even the document listing the breakage [4] does not provide a clear message "if you do $FOO, stuff breaks, but $BAR is completely safe". For example, there is no reason for not building e.g. Qt5 with C++11 support. In fact, limiting it to use just the C++98 features would be considered a regression from the perspective of a developer using Qt. Right now, it seems that we shall wait at least for GCC 4.9 to come and for upstream to decide how to solve this properly. Cheers, Jan [1] http://gcc.gnu.org/gcc-4.8/cxx0x_status.html [2] https://lwn.net/Articles/552831/ [3] https://lwn.net/Articles/552750/ [4] http://gcc.gnu.org/wiki/Cxx11AbiCompatibility
Re: [gentoo-dev] How to support C++11 in libraries?
On Wednesday, 18 December 2013 18:05:46 CEST, "C. Bergström" wrote: If moving to C++11 - Isn't that considered just part of the work along the path? There's some clang tools to help with the migration, but I don't think anyone expects it to be zero work. The flag is just a way to a) enable building programs that can be built with c++11 b) flush out the culprits in the cases it can't be. If (b) is a bug - how else to find it easily? This perspective is interesting (and I admit that I tend to like it) -- considering packages which won't build with C++11 to be buggy. I'm worried by the cost of such a policy, though, because we would suddenly have to patch some unknown amount of software (and I'm pretty sure some upstreams would reject these patches anyway). If we were an enterprise distro with binary compatibility requirements, we would also have to worry about that and either assume that the ABI changes are non-issue in real world, or provide two versions of all C++ libraries. I tried to check how RHEL7 will deal with it, but I wasn't able to find any information about that. It also seems that Fedora hasn't addressed this yet, either. Either way, it is reasonable to assume that some users would like to build their own software and link it with system libraries. It is not reasonable to force these users to build in the C++11 mode, IMHO. Cheers, Jan
Re: [gentoo-dev] How to support C++11 in libraries?
On Wednesday, 18 December 2013 17:37:56 CEST, "C. Bergström" wrote: From the perspective of a compiler vendor - I must ask why not? There is code out there which builds fine under C++98, but fails to build when C++11 is enabled (as but one exmaple, have a look at [1]). [1] https://bugs.freedesktop.org/show_bug.cgi?id=46147
Re: [gentoo-dev] How to support C++11 in libraries?
On Wednesday, 18 December 2013 14:58:07 CEST, hero...@gentoo.org wrote: I think it is better achieved by a (simple and stupid) global CXXFLAGS. Adding an extra USE flag feels a little over-engineering. What compiler flag do you propose to use? Note that --std=c++11 will not work. Cheers, Jan
[gentoo-dev] Re: Removing net-wireless/ipw3945*
On Tuesday, 4 June 2013 17:02:33 CEST, Markos Chandras wrote: Could you please open a bug so treecleaners can track this? https://bugs.gentoo.org/show_bug.cgi?id=472296 it is. Thanks. Cheers, Jan
[gentoo-dev] Removing net-wireless/ipw3945*
Hi folks, somehow it happened that I'm listed as the only maintainer of net-wireless/ipw3945d, net-wireless/ipw3945 and net-wireless/ipw3945-ucode. I'm not an ebuild developer, I no longer use that hardware on a production machine, and I believe that I switched that old laptop to iwl3945 years ago anyway. Could you please start the last rites process for it? As I said, I don't have commit access to gentoo-x86, so I cannot do this myself. Cheers, Jan
[gentoo-dev] USE=-ipv6 in the hardened profile
Hi, current hardened profile sets USE=-ipv6, but I wasn't able to find any reason for that in the ChangeLogs. With the upcoming v6 frenzy, I was wondering if we can remove that default. With kind regards, Jan signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Small change: Global USE flag nsplugin
Christian Faulhammer wrote: Ok. What about: "Build media plugin for browsers supporting the Netscape plugin architecture such as www-client/mozilla-firefox" "Build media plugin for browsers supporting the Netscape plugin architecture (that is almost any modern browser)" Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Fwd: News item: Generation 1 deprecation
See the patch. -- cd /local/pub && more beer > /dev/mouth --- generation1-deprecation.orig2009-02-23 14:50:37.920591164 +0100 +++ generation1-deprecation 2009-02-23 14:51:25.180617090 +0100 @@ -21,9 +21,9 @@ emerge -av --depclean virtual/jdk:1.4 -If don't need virtual/jdk:1.4 any more then you can remove the +If you don't need virtual/jdk:1.4 any more then you can remove the individual JDKs. First get the list of installed JDKs with -eselect and then remove with depclean, for example: +eselect and then remove those that are not needed anymore with depclean, for example: eselect java-vm list emerge -av --depclean sun-jdk:1.4 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GWN - how to restart ?
Man Shankar wrote: Firstly apologies if this is the wrong -list for such a post. "We solicit your feedback on the GMN, drop in an email to gmn-feedb...@gentoo.org. If you're interested in writing for the GMN, please email gmn-writ...@gentoo.org." -- is that really so hard to find nowadays? [1] http://www.gentoo.org/news/en/gmn/ -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files
Ferris McCormick wrote: 'cp -i' will at least ask a question, and I find that marginally better --- it's confusing, but at least it says something. But it seems to me that if we hit this case, no one (including the package owner) knows which .xml file to use, so stopping the build makes sense, but do it with some message that explains exactly what is going on. The problem is that the whole build won't *abort*, but rather become interactive. I for one think that having it die (in the unlikely case that s developer made a mistake) is better than letting it hang indefinitely (in the unlikely case that a developer made a mistake) :). Think about insane users setting up cronjobs and what not... Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs
Thomas Sachau wrote: as specified in the PMS spec [1] and stated in #gentoo-portage, RDEPEND will be set to DEPEND, if it is not defined in the ebuild itself. But devmanual [2] and developer handbook [3] both state, you have do explicitly set RDEPEND because it may be removed in the future. Please file a bug for devrel (the devrel handbook) and QA (for devmanual). Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Anouncement: Updated kde4 eclasses in the tree.
Tomáš Chvátal wrote: (i guess kmail4.2 is doing something fancy :D) Well, that explains it :). Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI 2 policy for portage tree
Jean-Marc Hengen wrote: tree and my policies (more precisely: I can't keep current stable portage and cmake-2.6.2). My solution to the problem, was to copy the ebuild in /var/db/pkg to my local overlay and I'm fine with it for now. The drawback of this workaround is, I could miss important fixes, like security fixes. [snip] the cmake-2.6.2 ebuild. This has the advantage, that people with a setup like mine can continue to use, what they already use and work on the cmake ebuild can continue in the new revision. If the new revision fixes a security issue, one can mask the old version, with a message with bug telling this. Just FYI, there's no difference -- when you've chosen to use the ~arch version, you *have* to follow any updates to it as soon as possible if you want to be reasonably sure you aren't affected by a security bug, as our security team doesn't issue GLSAs for ~arch packages. Sticking with a version that works for you doesn't mean you're somehow protected form security bugs. So to put this into perspective with cmake -- if there was a security bug in current version (which you'd keep as you don't want to upgrade Portage) and the fix for this bug would be using EAPI=2 (which is not an unrealistic situation), you'd be affected. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future
Diego 'Flameeyes' Pettenò wrote: - no need to replicate homepage data between versions; even though forks can change homepage, I would expect that to at worse split in two a package, or have to be different by slot, like Java; But also the need to replicate http://www.kde.org/ to metadata.xml of all KDE split ebuilds -- right now, this is set by an eclass. - allows proper handling of packages lacking a HOMEPAGE; Could you elaborate a bit about how different is handling of an empty/uninitialized shell variable from an empty XML element? - less data in metadata cache; Isn't it in the cache for some reason? Really, I'm just asking. - users can check the metadata much more easily by just opening the xml file or interfacing to that rather than having to skim through the ebuild, the xml files are probably more user readable then ebuilds using multiple eclasses; Haven't we already agreed that accessing ebuilds/... directly is broken by design? - webapps like packages.gentoo.org would be able to display basic information without having to parse the ebuilds or the metadata cache. Except for the ebuilds which still use the old format (that is 100% of the tree right now) Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
Diego 'Flameeyes' Pettenò wrote: I have a very quick proposal: why don't we move the packages' homepage in metadata.xml (since it's usually unique for all the versions) I believe the reason was that HOMEPAGE might change with new versions and that metadata.xml didn't (doesn't?) support version-specific data. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] An official Gentoo wiki
kashani wrote: How easy is it to checkout current GDP docs Append "?passthru=1" to the end of the URL. and make changes to them? I take it you want to make a patch. In such case, edit the file and submit the diff via Bugzilla. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] An official Gentoo wiki
Michael Hammer wrote: The wiki can be a staging ground for user contributed documents, which can become part of official docs after a review and cleanup by developers. ...as long as they use a compatible license, is not the case right now (and never was, IIRC). That's the way I intended my proposal. As some kind of early state GDP documents. It's an unwritten fact that user are willing to contribute to wiki systems - but I've never received an xml file for our GDP written by a user ;) ... The wiki can be the place to develop new howtos by disburding the devs - IMHO. Contrary to popular belief, we (the GDP) don't require submissions in any particular format. We have plenty of monkeys that can convert just about anything to our fancy internal format. We do our best to communicate this fact to other people in Gentoo, but apparently it's a tough job, as I don't recall much submissions in non-XML form. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PMS] Add RESTRICT="distcc" capability
Gordon Malm wrote: It looks to me like you've already made up your mind. How is hardened doing the entirely wrong thing? From the page [1] you mentioned: "If so, that seems to me like an abuse of the -D option." The abuse is in changing the compiler behavior based on -D options. What do you propose can be done to "fix" the hardened compiler? From the same page: "It would be better for you to remove the patch from gcc where it makes -D__KERNEL__ imply -nossp -nopie, and to instead patch the Linux kernel build system (Makefiles, etc.) so that it passes "-D__KERNEL__ -nossp -nopie" rather than "-D__KERNEL__"." [1] http://code.google.com/p/distcc/issues/detail?id=25 Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
Steve Long wrote: insinto /usr/share/doc/${P}/examples Is there any chance we can start using correctly quoted filenames across the board? Since when is ${P} allowed to have spaces? Besides being faster (quote the whole thing) Have you done a benchmark certifying that "/usr/share/doc/${P}/examples" is faster than /usr/share/doc/${P}/examples? more useful error messages in the case of a dev/user slip-up Could you elaborate? They also highlight better in a capable editor.[1] Please elaborate. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UTF-8 in GLEP56 use flags?
Ben de Groot wrote: The xml header in each metadata.xml states that the content is UTF-8 encoded, and any XML parser has to be able to handle this. Also, when used literally in xml, the 5 special characters & ' " < > cause a well-formedness error, as far as I know. You're wrong, it's absolutely safe to use ' and " in element contents. You might have to escape them when in attribute value, though -- example: That's because the XML parser would have no way of telling if the " is supposed to terminate the attribute value or not. of using the apostrophe. So in my opinion, if we want to use xml, we should use unicode properly. In my opinion, there's absolutely no benefit in using fancy characters everywhere, just because it's allowed by the XML spec. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
Jorge Manuel B. S. Vicetto wrote: Some members of the KDE team have been talking for some time about having a FHS compliant install (define KDE prefix as /usr instead of /usr/kde/). What are benefits of such a change? What happens when KDE release a version breaking ABI (like "KDE 5")? Right now [1], there's a conflict between some non-kdelibs kde3 libraries (kexiv2, kdcraw) from KDE3 and KDE4, mainly KDE4 applications being linked with KDE3 libraries. I don't expect ABI breakage in 4.x, but what happens after it? Will I be able to use my desktop in the middle of an upgrade from 4.x to 4.(x+1), when only half of the packages are already updated? In case someone is thinking on suggesting it, ignoring FHS or not allowing the install of multiple versions are not valid solutions to this problem. I might have missed something in your mail, but if you put, say, 4.1 and 4.2 libraries straight into /usr/lib, are you completely positive stuff won't break? [1] "Now" being the 3.5.9 release in Portage tree and 4.1.0 in an overlay Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP 56] metadata.xml USE flag descriptions [Clarifications]
Josh Saddler wrote: > XML doesn't put a space between the attribute and the closing slash -- > XHTML does. Common mistake. Also, use " for attributes, rather than '. Nope, both is perfectly legal in XML (and illegal per the GDP coding style, which certainly doesn't apply to metadata.xml) :p. Cheers, -jkt
Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins
Robin H. Johnson wrote: If you would like to have the new bot in your #gentoo-* channel, would each channel founder/leader please respond to this thread, stating the channel name, and that they are the contact for any problems/troubles. #gentoo.cs please, me as a contact. -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] IBM article of interest ?
Philip Webb wrote: > Neither an e-mail address nor an Internet URL is "some history": > they are a means of contacting a person & a link to a site > & as such they should be upto-date or deleted. Daniel Robbins founded Gentoo. His mail is still valid and will remain so. > but you are missing the point. Any newspaper or magazine editor knows > that when they reprint an article, some details may need updating > or at least a clear disclaimer needs adding to warn readers > that "This article was first published in 2000 & is reprinted as was". > In the current case neither IBM nor Gentoo docs has done either. Do you happen to know of any Internet news portal that adds a note "hey Philip, this article is older than two days, it might not be accurate anymore"? Anyway, perhaps you should read the articles more carefully: "Disclaimer : The original version of this article was first published on IBM developerWorks, and is property of Westtech Information Services. This document is an updated version of the original article, and contains various improvements made by the Gentoo Linux Documentation team. This document is not actively maintained." [1] "01 Dec 2000 Updated 03 Jul 2008" [2] *Nothing* needs changing. Better stick to the more important things. Cheers, -jkt [1] http://www.gentoo.org/doc/en/articles/l-awk1.xml [2] http://www.ibm.com/developerworks/linux/library/l-awk1.html -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] IBM article of interest ?
Josh Saddler wrote: Yes, it looks as if someone at IBM simply copied it from there, where it is indeed marked "updated". Perhaps you misunderstand -- the articles originally were written *for developerWorks*, not for Gentoo. That's where they first appeared 7 or 8 years ago. And that's also why Philip should thank IBM instead of pestering them :). Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
Jeroen Roovers wrote: PS: I wanted to respond to many more of your comments, but then I always thought: who is this man anyway and does he perhaps contribute to Gentoo in some obscure way? Now I tend to think you don't. David seems to be a PMS contributor [1]. Cheers, -jkt [1] http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
Luca Barbato wrote: http://www.gentoo.org/proj/en/releng/#doc_chap5 "The latest release of Gentoo Linux is: "Gentoo Linux 2007.0 for Alpha, AMD64, HPPA, IA64, MIPS, PPC, S390, SH, SPARC, and x86 architectures. " Good point, doc team please update those places. The GDP has zero control over /proj/en/releng (well, in fact any developer can commit to that area, but you generally aren't supposed to change a project's web page without their approval). This document is maintained by releng. Additionally, if you really expect any action from us (the GDP), please file a bug. We don't read every thread on the -dev ML. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [EMAIL PROTECTED]
Benedikt Morbach wrote: retired and work on an alternative package manager and a certain dokument where they try to set gentoo standards from the outside. Please stop spreading FUD about PMS forcing some standards over Gentoo. Get your facts straight before commenting any further, thanks. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] One-Day Gentoo Council Reminder for June
Ciaran McCreesh wrote: What, going around removing authors' names is 'a legitimate status update'? Nobody removed any author names. rane just removed a former developer from the list of active members of one Gentoo project. This happens all the time when a developer is retired. Being listed as a "developer" on that page says exactly nothing about one's ability to contribute to the PMS. If you are unhappy with present state of the page, then I hope you'll file a bugreport. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] One-Day Gentoo Council Reminder for June
Ciaran McCreesh wrote: On Thu, 12 Jun 2008 15:34:56 -0400 Doug Goldstein <[EMAIL PROTECTED]> wrote: I'd honestly like to see an official PMS project page i.e. http://www.gentoo.org/proj/en/pms/ There's http://www.gentoo.org/proj/en/qa/pms.xml . Unfortunately, rane decided to go and vandalise it for some reason and no-one working on PMS appears to have commit access to it... The only commit from rane that I see is [1], which removes "spb" as a maintainer. As far as I can tell, this is not a vandalizing, but a completely legitimate status update which was triggered by spb's retirement. All Gentoo developers have access to the file in question, so I'm looking forward to a bugreport from you assigned to myself that has a patch attached which clearly states what should be updated. Cheers, -jkt [1] http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/qa/pms.xml?r1=text&tr1=1.1&r2=text&tr2=1.2&makepatch=1&diff_format=h -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GLEP 55
Joe Peterson wrote: >>> But what users *really* don't care about is EAPIs, and this GLEP would >>> expose that technical detail to them in a very blatent way. >> Anyone who cares about ebuilds at a file level has to care about EAPIs. > > Not really. A typical user does not need to know about EAPIs at all, > but he might want to peruse the portage tree to look for ebuilds. He > might also want to grep for KEYWORDS or whatever. If the user knows that keywords are set by the KEYWORDS variable, then she must be familiar with the EAPI. The meaning of the KEYWORDS variable is defined by the EAPI. >>> Along those lines, as I've said before, migrating to a new extension, >>> *one-time*, as a solution to this, although not optimal, would be far >>> more satisfactory than introducing a series of ever-changing >>> extensions. >> No it won't. It means future EAPIs will be restricted to some >> particular source format. > > I assume you mean that EAPI needs to be in the file - again, is this > bad? Many file formats specify a file format version as part of the file. Sure. If current EAPI specified that a sequence of four bytes starting at offset 0x10 is a little-endian magic number that is used to identify an EAPI, that'd be all we want. However, current format definition is rather complex; there's nothing as simple as "read several bytes at some offset and use them". Cheers, -jkt -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: A few questions to our nominees
Tiziano Müller wrote: Having the EAPI versioned like this: X.Y where X is the postfix part of the ebuild (foo-1.0.ebuild-X) and Y the "EAPI=Y" in the ebuild itself we could increment Y in case the changes to the EAPI don't break sourcing (again: a package manager will have to mask those ebuilds) while changes breaking the sourcing of the ebuild need an increment of X to avoid that pm's not being able to even source such an ebuild still can mask it properly (or just ignore it). What benefits would that offer? Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] A few questions to our nominees
Luca Barbato wrote: Thomas Anderson wrote: As Fabian said it really isn't a matter of "We like XML better than LaTeX!" It's not those people's prerogative. Problems like having homogeneous documentation aren't that small. See the devmanual. It uses completely different XML markup. It is XML, but not compatible at all with the GuideXML. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] A few questions to our nominees
Thomas Anderson wrote: I personally have had no problems reading and/or understanding PMS, and I've had to reference a fair bit of it. I'd like to hear exactly who has problems with what sections and how to fix that. As Fabian said it really isn't a matter of "We like XML better than LaTeX!" It's not those people's perogative. The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. If they use LaTeX, more power to them, it's what enables them to do their job in the easiest way. You don't *have* to read PMS in LaTeX, which by the way makes my eyes bleed somewhat, you can read it in a very well done PDF. For those that don't know me, I'm a member of the Documentation Team. I also have some background with XSLT (not as huge as neysx, our leader, has, but still I'm not really a begginer in this area). That said, I completely agree with the choice of latex in this particular case. If there was a fixed request on GudeXML, this document would not have been at all written yet. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: lastrite: dev-cpp/libherdstat and app-portage/herdstat
Alin Năstac wrote: I remember that one time I had to split a command like dohtml "${S}"/something/*.{png,html} because the line was too long. At that time, bash had a limit of 32K. Now is what ... 1M? from execve(2): Limits on size of arguments and environment Most Unix implementations impose some limit on the total size of the command-line argument (argv) and environment (envp) strings that may be passed to a new program. POSIX.1 allows an implementation to advertise this limit using the ARG_MAX constant (either defined in or available at run time using the call sysconf(_SC_ARG_MAX)). On Linux prior to kernel 2.6.23, the memory used to store the environment and argument strings was limited to 32 pages (defined by the kernel constant MAX_ARG_PAGES). On architectures with a 4-kB page size, this yields a maximum size of 128 kB. On kernel 2.6.23 and later, most architectures support a size limit derived from the soft RLIMIT_STACK resource limit (see getrlimit(2)). For these architectures, the total size is limited to 1/4 of the allowed stack size, the limit per string is 32 pages (the kernel constant MAX_ARG_STRLEN), and the maximum number of strings is 0x7FFF. (This change allows programs to have a much larger argument and/or environment list. Imposing the 1/4-limit ensures that the new program always has some stack space.) Architectures with no memory management unit are excepted: they maintain the limit that was in effect before kernel 2.6.23. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] am I ready to step into Gentoo?
Hi Federico, a good start would be not to hijack threads [1] :p Cheers, -jkt [1] http://en.wikipedia.org/wiki/Thread_hijacking -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] global useflags
Andrey Grozin wrote: There was a period when qtiplot required qt4 emerged with qt3support USE flag. So, it had pkg_setup which checked this and produced an error it necessary. Ah, that's quite common -- a package FooBar is ported to Qt4, but it still uses some of the Qt4's Qt3support classes. This is handled by FooBar depending on qt4 being built with that particular USE flag, not a "qt3support" in for the FooBar package itself, though. Cheer, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] global useflags
Andrey Grozin wrote: sci-visualization/qtiplot, for example I don't see a reference to the "qt3support" flag in any of qtiplot ebuilds, could you please clarify what you mean? Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] global useflags
Markus Meier wrote: qt3support: Enable the Qt3Support libraries for Qt4 While it affects a few "packages", they all are parts of the Qt toolkit (which we previously shipped in one big package). I can't see a scenario where this flag might be used on a package not released by Trolltech. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: qemu -> add gcc-3.x dependency
Enrico Weigelt wrote: I'm just installing qemu, which requires gcc-3.x for building. The current breaks are very ugly, IMHO. So I'm proposing to add the old gcc-3.x as depedency to qemu, at least as long as it doesn't build w/ newer gcc. Hi Enrico, it is usually a good idea to search through the Bugzilla before asking for some feature, chances are that it has been already requested (in this case, you're looking for bug 190102). FYI, at least some of qemu's features were ported to gcc4 -- for example, see the kvm-qemu ebuild from bug 157987. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: language bindings as separate packages
Enrico Weigelt wrote: > Maybe you remember the discussions about stable vs. dev kernel > branches: the kernel folks wanted to give up stable branches, > leaving them to the individual distros and concentrate just on > devel branch. A lot of people were totally unhappy with this > idea, so they abondened the idea. Otherwise the kernel would > have been the killer job for an project like OSS-QM. What you mean by the "stable branch", the 2.4.x, 2.6.16.x or something completely different? Cheers, -jkt -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New developer : Chris Henhawke (bunder)
likewhoa wrote: plus the beer is free so you'll Hey! Location? Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] gcc-4.2 / gcc-4.3 plans
Vaeth wrote: Result: Compiles fine with gcc-4.3 on x86 but dies immediately at boot (before printing anything) unless acpi=off is used. (And just to be sure, I disabled every acpi feature except "general" acpi support - same result). Please file a bug at bugs,gentoo.org, our hardened team surely wants to know about that. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] gcc-4.2 / gcc-4.3 plans
Mike Frysinger wrote: there is no compile time problem. it's all runtime. i still think carrying the patch until gcc-4.3 goes stable is OK. 1400_prevent-gcc43-optimization-udivdi3.patch fixes compilation issue, another patch (already in some 2.6.24.x, I guess) fixes direction flag (that well-known runtime bug). So the point is, our current 2.6.24 kernel is safe. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] gcc-4.2 / gcc-4.3 plans
Donnie Berkholz wrote: Presuming you're adding the direction-flag patch to 4.3.0 so it doesn't break people on a kernel earlier than 2.6.25? gentoo-sources-2.6.24-r4 has that patch, at least when looking at the changelog. Or is it just for compile-time borkage and not for the direction flag cleaning? Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Return of a developer : Josh Glover (jmglov)
Denis Dupeyron wrote: he also enjoys drinking beer. So please everybody give a warm re-welcome to Josh. Sounds good, let's have one :] Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
Petteri Räty wrote: 26767 ingmar 41523 philantrop Go KDE go! :) Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
Petteri Räty wrote: If you can't manage weekly commits, you can't respond to security issues either. This means that you should have devaway on. That assumption is false. If there was a need to do weekly commits and the dev in question couldn't manage it, it would be wise to expect that he can't be relied upon with security fixes. However, there is no need to do periodic commits now, so the above theorem doesn't hold. :) Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New developer: Ahmed Ammar (b33fc0d3)
Petteri Räty wrote: Joining us from the land of the pyramids, we have Ahmed "b33fc0d3" Ammar. w3l(0m3 4b04rd, 4hm3d. (h33r5, -jk7 -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Help offered - Portage tree
Natanael Copa wrote: So since I build a distro where size does matter (uclibc) I realised that even if I submit bugs for broken RDEPEND, there will never be an end to those bug reports. Looking at this thread, it seems i was right. I wonder what you are looking at :(. You've been told by multiple developers that we do care about dep correctness and are willing to fix bugs when we hear about them. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Help offered - Portage tree
Fabio Erculiani wrote: ^^ This is a really stupid sentence. It seems some of you don't even realize how many users we brought to Gentoo, and this is really sad. I'm not sure I understand how exactly you bring people to Gentoo. You bring people to your distribution which is a binary rebuilt of Gentoo, AFAIK. Or do you have a steady stream of users drifting away from Sabayon to Gentoo? You see, people like Halcy0n, agaffney, zlin keep us away from interacting with you. "Us" being you or who exactly? Halcy0n was just trying to understand what exactly are you going to improve. If you want to stop bad press, you (all) should firstly become more gentle with users and external contributors.> I am not talking to you directly Robin, but to whom are quite annoying and provocative. I know that the majority of you have been always kind, but I will never hang on #gentoo-dev anymore just to be played around giving me voice until I annoy someone with my POV. Well, I was trying pretty hard last night to hear interesting suggestions from you which could be actually implemented. I have even asked the same questions as Halcy0n did, yet you call him a "bad guy" and not me. That's strange. Anyway, please take your time to read the following and think about it. Perhaps you'll find out that we aren't a group of lazy and angry morons, but a group of people that respect each other and wants to get technical issues solved, but with limited time at hand. All you said yesterday was "I don't have time to wait till my bugs are fixed, gimme access so that I can fix them myself". As we have been trying to tell you in more than two hours, this is not how things work. In Gentoo, we respect other developers' work, so if we see a flaw in their code, we speak to them about it and don't go blindly fixing stuff without prior chat with maintainers. Having more than 13k packages in the three, no single person can be expected to know the whole tree well. That's why we are organized into groups and generally talk to each other before fixing bugs. A change you make might have huge impact on packages you haven't ever heard of. During the chat, you proposed various things like "having a mailing lists where child distributions could send bugreports they find". This is not the way to go. We already have a support channel, the Bugzilla. There is really no way to speed up maintainers' reactions. That doesn't depend on how they get the reports, but entirely on their spare time and motivation. If you don't like working with bugzilla's web interface, you've been already offered another access vectors to the bugzilla database. But let me repeat it once again -- if you are worried about maintainers taking "long time" to respond (where "long time" is, by your definition, at about "more than two hours", if I understand you correctly), there's no way I'm aware of that this could be changed. We are just humans who have to sleep, eat, work, date beautiful girls and drink beer. We are not going to abandon any of these just to make the "child distributions" happy, sorry. I have quite a mixed feelings about your offer, too -- you said you're willing to fix stuff, yet you refuse to file bugs, giving a reason that it "takes time". That doesn't make much sense to me, sorry. If you don't file the bug, the same error will stay in the package, it will propagate to each and every next release and you'll have to fix it over and over again in your code. This is not a democratic way, let's talk publicly here, without hiding in a development channel, we probably get more visibility, don't we? I'm afraid I don't fully understand your point here -- Gentoo is not about democracy as in "what majority wants, that happens". If it was such kind of "democracy", we'd have reiser4 as a default filesystem for three years now. In Gentoo, things that happen are things that developers want. If you're bored with that, hey, become a developer and change stuff. Asking us to change the way we work, the process that has worked for many years and that we are happy with, just because it might give some benefits to your distribution, while also causing more work for us, that simply won't happen. Please, try to think about our reasons. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Help offered - Portage tree
Fabio Erculiani wrote: I offer my help to fix DEPEND/RDEPEND split issues which is causing me a lot of headaches (along with localizations). For reference, please have a look here: http://planet.sabayonlinux.org/?p=105 "The name [EMAIL PROTECTED] is not a valid username. Either you misspelled it, or the person has not registered for a Bugzilla account.", that's all what our bugzilla knows about you. Either you're using a different e-mail address there or you really haven't reported a single bug to us in that seven years. It would help if you file bugs against respective packages or provide a list of examples mentioning what exactly needs fixing. You can't reasonably expect us to act based on a post in $random_blog. With love, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Richard Freeman wrote: We might also aim to make it easy for users to mix-and-match levels of stability by package. I know it is possible already, but perhaps it could be improved, or pre-canned lists of packages that users might typically want bleeding-edge vs stable could be compiled. Tusnam said it better than I would, so I'll just post a link -- http://tsunam.org/2008/01/29/arch/ Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: removal of digest files from the tree
Davide Cendron wrote: >> Ok, so we're just blocking on the docs guys. Well, to the best of my knowledge, nobody asked us to fix stuff. Preferred way would be filing a bug to the docs-team that says "hey, we're gonna deprecate all digests, could you please fix your crap so that it doesn't recommend running `ebuild foo digest`?", but other methods like mailing the -dev ML or pinging us on irc are fine, too. If you don't want to be held back by our inactivity, you have to let us know :). Also note that docs team is responsible for files that are under http://www.gentoo.org/doc/ and *nothing else*. If there's a bug in some other document that is on our web nodes, like for example the Devrel Handbook, we leave it to their maintainers (devrel here) to fix it. If such team says "hey, fell free to fix whatever you want", I'm sure some GDP members (including rane myself) will gladly help, but right now, the policy is "we got a bug that speaks about stuff under /proj/ -> reassign". (As a side note, we have that great devmanual which seems a lot more useful than the ebuild part of the devrel handbook, perhaps it's time to reconsider their roles. And yeah, I've brought this to devrel's attention and don't count on them following -dev :). ) > I don't know exactly how many other docs must be changed accordingly, it's > better to ping some GDP member to get a better feedback. Quick grep suggests that these needs fixing: proj/en/desktop/games/games-ebuild-HOWTO.txt proj/en/devrel/handbook/hb-guide-ebuild.xml proj/en/devrel/handbook/hb-introduction-new-devs.xml proj/en/devrel/new-dev-training.xml I'm sure that rane will get someone from the devrel to fix them :) Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: debianutils: system worthy ?
Duncan wrote: > Mainstream kernel's default make install uses /sbin/installkernel if it > exists, so I've been using it, invoking the kernel's make install from my > own kernel scripts. installkernel invokes mkboot... We (the docs team) have never suggested out users to run `make install` for various reasons, see bug 183346 (and the linked gentoo-doc thread) for details. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting
Perhaps I'm just so much used to seeing automatic signatures separated by "-- \r\n" and consider non-separated text as "typed by the author". (And yes, Chris, I need beer from pubs :) ) Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting
Chrissy Fullam wrote: > I appreciate your opinion and your right to have such an opinion, however, I > have a hard time understanding your reason for said opinion. I would expect > any person to be able to say 'enough' and 'lets take this elsewhere.' Perhaps he feels in such a way because your mail wasn't really "please talk about it elsewhere", but rather a "warning" (at least that's how I perceived it) and you signed it as a "Gentoo Developer Relations Lead". I hope this helps you understand why someone might have such an opinion :). Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Chris Gianelloni wrote: > I have foo 1.0, which is mips. There is foo 2.0, which is stable > everywhere else. The foo 1.0 ebuild does not conform to current ebuild > standards. I want to commit changes to foo 2.0, and repoman won't allow > me due to problems in foo 1.0, but I don't want to WASTE MY TIME on foo > 1.0, because it's been EOL for 2 years Why don't fix repoman not to scream about such issues, then? Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Roy Marples wrote: > I understand that metadata in a file name is pure and simple hackery > that has no place here and the GLEP is a flimsy attempt to justify it. Do you count "version" as metadata? Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Zhang Le wrote: > Zhang Le wrote: >> I have just created a page of EAPI on wikipedia, let's improve it together. >> http://en.wikipedia.org/wiki/EAPI > > And later convert it to guidexml and put it on gentoo.org, of course. Wikipedia uses GFDL while we use CC-BY-SA, so no, you can't do that before the Wikimedia Foundation manages to persuade FSF to change GFDL. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Simon Cooper wrote: > nearly all binary files do versioning/format information inside the > files Think of different EAPIs as different set of rules for the ebuild contents. If you accept this, you can easily define "new EAPI" as a "new format for ebuilds". It's nice that current EAPI "1" is backwards compatible with the default one, but nobody can guarantee that for future EAPIs. And this is what this thread is about. So, now if it is a different format, it is perfectly reasonable to invent another extension for it, isn't it? > and one of the main things I like in unix is that file format is > *independant* of what you actually name it (a text file can be named > *.wibble, or even have no extension at all and nothing will break). On the contrary, if you rename an ebuild, it doesn't work. > Filenames are generally quite mutable - changing the filename is just a > single 'mv' Only root can mess with files in my $PORTDIR. If you're working as root, you should better pay attention before you move files around. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes
Piotr Jaroszyński wrote: > The package manger would have to look for ebuilds in the main > dir and all the subdirs in case it doesn't have/can't use the cache. No, it would have to check only for subdirectories named after known and supported EAPIs. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Some new global USE-flags
Santiago M. Mola wrote: > These are potentially ambiguos. Could you please elaborate a bit about the raw one? Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Update: qt-4
Caleb Tennis wrote: > Since Qt is starting to get rather, ahem, big, I've decided that with the > introduction of version 4.4 it's a good time to try and split it down into > more > manageable chunks. I'm introducing a few new packages that are designed to > break > out some of the major pieces into their own packages. I present: > > x11-libs/qt > x11-libs/qt-dbus ( Breaking out into its own package ) > x11-libs/qt-phonon ( New for 4.4, a wrapper around various sound modules ) > x11-libs/qt-qt3support ( Breaking out into its own package ) > x11-libs/qt-webkit ( New for 4.4, Qt's integrated WebKit support ) Great news. Why don't you split everything, though? In qt-4.3.0-r2, I see Core, Gui, Network, OpenGL, Sql, Script, Svg, Xml, Designer, UiTools, Assistant, 3Support, Test and DBus and can certainly imagine that at least putting the Gui out would make sense for console-based Qt applications. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Donnie Berkholz wrote: > If you turn off features you need, things break. There's nothing new > about that. If you disable ext3 support in your kernel, you can't mount > an ext3 partition and you'll get an error during boot about not finding > the root. I see your point, but extended attributes aren't as common as ext3, are they. And stuff that got broken because Portage suddenly started to require new features on the kernel side is bad. > The idea of the sqlite-based fallback is what's interesting here. If it is a fallback that must be supported (because of NFS), then there isn't much point in using xattrs. What benefits do they provide? There's no speed constraint here as we already cache metadata somewhere. >> Also note that in some circumstances like when running in a >> virtualized environment, imposing additional requirements on the kernel >> might be problematic. > > Why's that? Things with Xen got better than they were, but I can imagine a situation where some hosting provider offers their customers a virtual Xen box and their kernel configuration doesn't include extended attributes. You can't use your own kernel without access to dom0. >> It wouldn't be great to require extended attributes for each and every >> Gentoo box... > > Why not? Because they aren't so common, NFS doesn't support them and we haven't ever required them. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Donnie Berkholz wrote: > Looking at my kernel config, ext3 and reiser explicitly support > xattrs, and I see jfs and xfs have acls and security labels, which > might be usable. Extended attributes can be turned off during compile time for each filesystem you mentioned. NFSv3 doesn't support them (yes, I do share $PORTDIR). Also note that in some circumstances like when running in a virtualized environment, imposing additional requirements on the kernel might be problematic. It wouldn't be great to require extended attributes for each and every Gentoo box... Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
Alon Bar-Lev wrote: > On 12/12/07, Jan Kundrát <[EMAIL PROTECTED]> wrote: >> Alon Bar-Lev wrote: >>> As I told you before, I wont slot these two. >> Could you provide a link to reasons that lead you to this decision so >> that interested readers can make their own opinion? > > http://bugs.gentoo.org/show_bug.cgi?id=159623 I've read it, thanks. Are you referring to "There is no point in installing the TWO (means slot) at the same time.", or do you have something else? Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
Alon Bar-Lev wrote: > As I told you before, I wont slot these two. Could you provide a link to reasons that lead you to this decision so that interested readers can make their own opinion? Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP] scm package version suffix
> Specification > = > > ``scm`` is a special suffix. It can be used on its own, but also in any other > valid version spec, just before the place where revision would go. And just > like > revision it can be used only once in a version spec, e.g.: > > * ``cat/pkg-1.0_alpha0-scm`` > * ``cat/pkg-1.0_alpha-scm`` > * ``cat/pkg-1.0-scm-r3`` > * ``cat/pkg-1-scm`` > * ``cat/pkg-1-scm-r2`` > * ``cat/pkg-scm`` > > These package atoms are sorted in ascending order (see `Version Comparison`_). What is the point of using version information along the scm suffix? From the logical POV, scm is a special decorator saying "this is a special tarball that can change in time and we don't know its version when parsing ebuild, we'd have to ask the repository". Surely I can think of uses for *revision* specification (as in "revision of the ebuild"), but why to support full version for scm packages? Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] packages.gentoo.org lives!
Robin H. Johnson wrote: > My quote was from the first sentence of RFC1738, sec 3.3 (HTTP), para 4. Missed that, sorry. >> Redirecting clients to new URLs would give you perfect caching as well. > That's why I say i'm willing to do redirection at the cache level. > I do NOT want lots of users with old links to hit the actually web application > if it's just going to redirect all of them to a page that is already in the > cache. I thought you were doing caching/redirects on a service that sits before the real webapp . >>> - The old parsing and variable usage code was the source of multiple >>> bugs as well as the security issue that shuttered the site. >> Only because it passed the raw, unescaped values directly to shell, >> which is of course badly broken. > Have a look at the recent discussion about HTML5 issues > (http://www.crockford.com/html/), which also applies to web applications: > "HTML 5 is strict in the formulation of HTML entities. In the past, some > browsers have been too forgiving of malformed entities, exposing users to > security exploits. Browsers should not perform heroics to try to make bad > content displayable. Such heroics result in security vulnerabilities." I can't follow this one -- how are broken browsers related to non-standard URLs? Why is an attempt to invent a competitive standard to XHTML related to URLs? >> Now that's something that sound reasonable. Why limit the period and >> don't provide it forever? > Time limited to force everybody to move over, and to not have to support > the redirections for the old version of the site forever, when they > weren't advertised as permanent URLs. My question could be re-phrased as "why don't keep those redirects", but you did the work, so you decide how to run it and I have no problems with that :). > I did a quick hack up of some statistics, and I see that only 6.7% (5001 out > of > (69434+5001)) of the overall visitors were arriving at the old locations and > not receiving the content they were originally interested in. Fine with me, thanks for your answers and all the work. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] packages.gentoo.org lives!
Robin H. Johnson wrote: > - Using the ';' as an argument separator in the old side is not a valid > query argument separator, and there are URLs out there that have added > further arguments using it, complicating parsing. What is source of your definition of "valid query argument separator"? > - See also RFC1738: 'Within the and components, "/", > ";", "?" are reserved.' My copy of RFC1738 says (end of section 2.2): Many URL schemes reserve certain characters for a special meaning: their appearance in the scheme-specific part of the URL has a designated semantics. If the character corresponding to an octet is reserved in a scheme, the octet must be encoded. The characters ";", "/", "?", ":", "@", "=" and "&" are the characters which may be reserved for special meaning within a scheme. No other characters may be reserved within a scheme. I wasn't able to find your quote in that file. > - Having a single valid URL for a given resource greatly improves cache > hit rates (and we do use caching heavily on the new site, 60% hit rate > at the moment, see further down as well). Redirecting clients to new URLs would give you perfect caching as well. > - The old parsing and variable usage code was the source of multiple > bugs as well as the security issue that shuttered the site. Only because it passed the raw, unescaped values directly to shell, which is of course badly broken. > - I _want_ old sites to change to using the new form, which I do > advertise as being permanent resource URLs (as well as being much > easier to construct, take any "[CAT/]PN[-PF]" and slap it onto the > base URL, and you are done). Which isn't a reason for breaking old links, IMHO. > That said, if somebody wants to point me to something decent so that > Squid can rewrite the URLs WITH the query parameters (the built-in squid > stuff seems to ignore them) and hit the cache, and that can add a big > warning at the top of the page, I'd be happy to use it for a transition > period, just like the RSS URLs (which are redirected until January 2008, > but only because they are automated, and not browsed by humans). Now that's something that sound reasonable. Why limit the period and don't provide it forever? Don't get me wrong, I really appreciate your (and others') efforts on getting p.g.o back up again, but I don't agree at all with reasons given in this mail. If you said "because I didn't have time to do that" or "I'm not interested in that", I wouldn't argue (but might try to get in touch with you and provide patches fixing the stuff). Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libevent: ChangeLog libevent-1.3e.ebuild
Bo Ørsted Andresen wrote: > So on estonian locales those letters won't be included in [a-z] but > they will be included in [:alpha:]. Actually that was exactly my point. If user had some funny locale that has digits or dots in its [:alpha:], the ebuild wouldn't work as desired, but it would rather strip valid stuff from the variable. But that's probably pure sci-fi for now :). Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libevent: ChangeLog libevent-1.3e.ebuild
Steve Long wrote: >> Is [[:alpha:]] locale-safe? >> > Yes, all POSIX character classes listed here are: > http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html Thanks for a nice link. If I read section 7.3.1 correctly, [[:alpha:]] always contains those letters, but might contain more, depending on the locale. So it's probably very minor point, but as long as the script runs with user-provided locale, one should be explicit here. Or am I missing something here? Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Re: eselect_zenity: alpha eselect GUI
Steve Long wrote: >>> Whatever. Requiring root for certain tasks has a long history: >> On the kernel side. >> > Hmm, I'm sure I've used several apps which required root over the years. They are flawed unless they are things like su/sudo/... . As a fine example about why is this checking bad, see bug 186459 [1]. [1] https://bugs.gentoo.org/show_bug.cgi?id=186459 Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libevent: ChangeLog libevent-1.3e.ebuild
Donnie Berkholz wrote: >> if [[ -n "${ver}" ]] && [[ ${ver//[a-zA-Z-]} != "${PV//[a-zA-Z]}" ]] ; >> then > > It isn't terribly likely to become an issue here, but it might be nicer > to use [[:alpha:]] than [a-zA-Z]. Is [[:alpha:]] locale-safe? Cheers. -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils
Daniel Drake wrote: > OK, so having a dynamic libpci is an outstanding requirement for the > patch. I will follow up with pciutils upstream about the current state > of that. If you had any issues with Martin Mares, I can talk to him as he's my teacher in one course at the university. He looks like a reasonable person. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Resolving HAL vs. pciutils/usbutils
Guilherme Amadio wrote: > And sorry to a bit off this thread, but I also would like to help with > some translations of official docs and development. I've been using Gentoo > since 1.4, but never really had time to help. Now I feel I'll have more > time and, if you can point me to some Brazilian dev, if there are any, I > can take some stuff to do. Hi Guilherme, thanks for your interest, but this isn't really appropriate for this list. Please see [1] and [2]. [1] http://www.gentoo.org/proj/en/gdp/doc/translators-howto.xml [2] http://www.gentoo.org/proj/en/gdp/doc/doc-policy.xml Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New staff : Marion Agé (titefleu r)
We have no staff members, we have only developers, honey :). Welcome, titefleur. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New developer : Dawid We;glin' ski (cla)
Roy Marples wrote: > On Tue, 2007-10-16 at 10:27 -0700, Josh Saddler wrote: >> You make it sound like non-ebuild devs with >> different kinds of commit access aren't "full" or "real" devs and might >> be second-class Gentoo members! Which we aren't. :) > > Third class then? :P > > /me ducks the flame onslaught There will be no flame as we The Honorable Members of Gentoo usually don't speak to poor councilers like you :-P. /me expects Roy being grateful for these words which weren't deserved Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-kids/gcompris: ChangeLog gcompris-8.4.ebuild
Tristan Heaven wrote: > It's my understanding that anything in DEPEND will be installed into /, > so no. If you mean that running `ROOT=/target emerge --usepkgonly foo-package` will install foo-package's dependencies into real /, then no, it won't. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: use flags -> use options
Tobias Klausmann wrote: > For those apps that need an editor, one could think of editor=vim. USE flag change usually triggers a rebuild of the package in question. I certainly don't want to rebuild packages just because I switch $EDITOR. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] How to add a service to /etc/services?
Ulrich Mueller wrote: > if ! $(grep 2010/tcp /etc/services >/dev/null 2>&1) ; then > cp /etc/services ${T}/services > cat >>${T}/services<<-EOF > ndtp2010/tcp# Network > Dictionary Transfer Protocol > EOF > insinto /etc > doins ${T}/services > fi > > Which leads me to the question: What is the recommended way to add a > service to /etc/services? Unless I'm mistaken, altering file that is owned by another package (baselayout in this case) is not a good idea as it would invalidate file checksum that Portage keeps. Why not add that line to baselayout-provided file? Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] meaning of sqlite/sqlite3 use flag
Petteri Räty wrote: > We should remove 2.x from tree and use just sqlite. Oh, and another reason is compatibility -- sqlite2 and sqlite3 use different on-disk format. sqlite3 can't read sqlite2 data and vice versa. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] meaning of sqlite/sqlite3 use flag
Petteri Räty wrote: > Does anything need the sqlite2 support in QT? Anything that uses Qt for database access (and chooses sqlite as the backend). media-gfx/kphotoalbum is an example. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] meaning of sqlite/sqlite3 use flag
Petteri Räty wrote: > We should remove 2.x from tree and use just sqlite. Qt3 supports only sqlite2. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Some ideas on how to reduce territoriality
William L. Thomson Jr. wrote: > What about distcc? Sounds like we need to get you some more powerful > hardware to develop on or etc. Since xorg is a fairly major package. > Understandably hard to test every time, but ideally all should be. Well, last time I checked, PHP had about 90 USE flags. I guess one should grab a lot of beer for that... Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] 2.6.22 stable plans
Stephen P. Becker wrote: > I will say that this is still a better situation than the closed > drivers, which instantly hard lock my computer the first time I exit X > after the initial startup. Perhaps this might help you -- http://www.thinkwiki.org/wiki/Problems_with_fglrx#Hardlock_on_X_logout Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: New lists and their usage
Ryan Hill wrote: > zombieswift/new devs -project > council/trustee nominations -project Then it's worth cross-posting -core or -dev-announce or similar. I thought that goal of -project was to keep devs away from poisonous content without impairing their Gentoo-awareness. > more photos on planet -project Perhaps a note on -core, again. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC : New ebuild function pkg_create for creating corespondent sorce tarball
Alin Năstac wrote: > The upstream doesn't offer a source tarball, so I need to construct > it myself from their svn repository. If you're creating a live ebuild, there are already existing eclasses that works from the user's POV. If your aim is to create an ebuild for a specific version, you might as well checkout stuff yourself and let Gentoo mirror the generated tarball (your mail doesn't talk about RESTRICT=fetch). If you let Gentoo mirror the tarball, users are likely to be happier because they'll get the file faster and in a more reliable way. Or am I missing something? Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007/08
I'd also like to nominate mcummings (he's an old guy in Gentoo land and his mails look reasonable), lack (he's a bit fresher, but his mails are good) and kumba (old guy, nice mails). XML has been updated. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007/08
I nominate Wernfried Haas (amne). Based on a thorough and detailed review of Gentoo state-of-affair that we did together over several beers some time ago when he was at Prague, I'm sure he's one of the best candidates for the human, caring part of the Council. Anyone pointing out at any old dirty laundry concerning Wernfried will be slapped to death with an empty beer pint. This is no assault, but rather a simple matter of fact. Cheers, -jkt -- [EMAIL PROTECTED] mailing list