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 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 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 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 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 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 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 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 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 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
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 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
[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] 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] 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] 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] [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] 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] 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] 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] [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: foo bar=baz quot; test/ 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/version). 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 ?
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] 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] [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] 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] 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] 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=texttr1=1.1r2=texttr2=1.2makepatch=1diff_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] 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] 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] 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] 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
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] 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
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: 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
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] 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] 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: 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: 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 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] [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] 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] [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] 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] [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] [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] [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] [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] 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] 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] 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] 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] How to add a service to /etc/services?
Ulrich Mueller wrote:
if ! $(grep 2010/tcp /etc/services /dev/null 21) ; 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] 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] 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] 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. 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] 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
Re: [gentoo-dev] New developer: Santiago M. Mola (coldwind)
Denis Dupeyron wrote: at obscure pubs New developer is always a good reason to have another beer. Welcome aboard! Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
Ciaran McCreesh wrote: what are the use cases for binary packages? Apart from those already mentioned by Chris, I use FEATURES=buildpkg to be able to recover from a catastrophic experiment with a package's content, for being able to quickly reinstall it. Although it's lame, it's pretty easy to run `emerge -K foo` to get vanilla config files. Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA issue: No stable skype in Tree
Abhay Kedia wrote: I am involved in this thread since its very beginning but looks like I am not being able to understand the problems. Would you please be kind enough to enumerate the issues discussed in this thread that warrant complete removal of Skype (rather than masking it) from the tree? We have a policy that ebuilds should be in the tree for at least 30 days before we mark them stable. Skype uses funny license that forbids us to mirror the installer file. Skype wants to remove that older file from their mirrors in less than 30 days after they release a new version. Current Gentoo stable would be unistallable. New version can't be marked as stable because it won't have been properly tested yet. Users will see that stuff that used to work for them is broken now. That's a regression that could have been avoided if Skype wasn't marked stable. It could be interesting to evaluate a new rule fetch/mirror restricted package can't be marked stable :). Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC]: gentoo-politics ML
Kent Fredric wrote: possible alternative names: gentoo-soap, gentoo-gossip ( not to be confused with net-im/gossip ) Please, please, make it gentoo-circuits [1]. [1] http://en.wikipedia.org/wiki/All_My_Circuits Yours faithfully, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: ion license
Matti Bickel wrote: It's main additions are a timely response clause, which requires us to get the same keywords for a newly released version as the previous had within 28 days. Another point is the no patches clause, which prohibits distributions from carrying a significantly modified ion-3 release under the ion name. So just rename the package to something that clearly illustrates that this isn't teh upstream Ion anymore!!!111one and be done with that. If users complain, ask them to talk to Tuomo Valkonen. Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Removing retired developers from project pages
Petteri Räty wrote: -date2006-05-02/date +date$DATE: $/date Please revert all date changes you've made for following reasons: a) $DATE: $ isn't expanded by CVS b) Even if it was expanded, I won't be expanded to the -mm-dd format c) Even if it was in -mm-dd format, it won't be fully usable by our XSLT stylesheets as we can't handle $Date 2007-05-02$, only 2007-05-02 d) We don't bump date automatically because some changes (typo fixes etc) aren't important enough to warrant that. Cheers :), -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Removing retired developers from project pages
Petteri Räty wrote: Maybe next time comment on the original patch to avoid pointless work. Well, first lines weren't changing any dates, so I've skipped the rest of the original mail. It was a pure coincidence that I spot them now. Anyway, thanks for fixing and removing retired people, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Removing retired developers from project pages
Petteri Räty wrote: was this reply really necessary ? you made a mistake and Jan didnt catch it until after you committed it. perhaps you meant to say thank you, ive fixed the issues you pointed out to me. -mike Plaah cultural issues. I just hope my comment makes people read the whole patches instead in the future. I could have worded my initial reply better as well, sorry for that. Anyway, let's drink some beer now :). Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
