Re: [gentoo-dev] EAPI-2 - Let's get it started
If, as a user or an arch person, I get a src_test failure right now, I don't know whether this means eek! Something's gone wrong, and I really need to fix this or oh, whoever maintains this package doesn't care. But with EAPI 2, I'll be able to know that a src_test failure really does mean something's wrong. A developer should always care about src_test in my opinion. That some developers don't is a nuisance, and the core of the problem. But trying to change this via EAPI is doing things the wrong way round: At first there has to be an agreement about the importance of test suites (backed up by strict policies that every developer is bound to), and then we can discuss if it makes sense to activate them by default in EAPI-X. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] A few questions to our nominees
On Mon, 2008-06-09 at 14:18 +0200, 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. 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. The main point being using latex prevents people from modify it. Untrue... latex is documented, and lots of people feel more comfortable with it than with XML (for example me). It's just a matter of taste and thus a decision of the people actually doing the work. If they use LaTeX, more power to them, it's what enables them to do their job in the easiest way. Depends on what the job is. 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. The pdf renders poorly on xpdf due the fonts latex has, usually I'd rather have plain text anyway. Install app-text/evince. It looks quite nice there. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Strange behavior of fonts... help :(
On Tue, 2008-03-04 at 20:34 +1300, Alistair Bush wrote: This is not a support channel and that, while an interesting picture, provides absolutely no information whatsoever. Indeed. Please try [EMAIL PROTECTED] and include some useful background information. Matthias signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 02:47 +, Ciaran McCreesh wrote: On Tue, 8 Jan 2008 18:44:22 -0800 Alec Warner [EMAIL PROTECTED] wrote: Uh... So where do the original problems come from? Are you saying that packages mysteriously start breaking on their own because no-one's maintaining them? Of course they do Ah, right. Because of the magical elf that lives in the CVS server that mysteriously goes around breaking dependencies when no-one's looking. Yes, a magical elf. Much more plausible than the theory that it's actually developers screwing up by dropping keywords or best keyworded version on a package's deps. Software that is not maintained is known to fail after some time; not because the software changes, but the environment the software has to interact with - but i guess you know that very well. Really, this discussion is completely pointless unless some mips users/developers join in - or aren't there any at all? Matthias signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sun, 2008-01-06 at 09:12 +, Ciaran McCreesh wrote: On Sun, 6 Jan 2008 10:08:47 +0100 Denis Dupeyron [EMAIL PROTECTED] wrote: No. What he meant and doesn't dare to say is you didn't ask, but demanded, in your usual dry and pesky I'm a spoiled 6-year old tone. And this as usual results in people ignoring you. People aren't as stupid as you think they are, and they don't want to play this game with you anymore. So don't build a case on the fact that you're not getting answers. Someday you'll understand this. Oh, and council members too aren't as stupid as you think they are. If they decide to discuss this, one of their first steps will surely be to try and evaluate what the current situation is. If I were a council member I'd probably feel offended by such condescension from your part. Ah, so this is what you consider to be solid technical reasoning, is it? You certainly present a compelling case, but probably not for the position you were trying to... This kind of conversation is not technical at all... Ciaranm, are you a MIPS user? If so, do you think that running KEYWORDS=mips is less likely to result in breakage than running KEYWORDS=~mips? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sun, 2008-01-06 at 23:35 +, Ciaran McCreesh wrote: On Sun, 06 Jan 2008 14:09:24 +0100 Matthias Langer [EMAIL PROTECTED] wrote: This kind of conversation is not technical at all... Ciaranm, are you a MIPS user? If so, do you think that running KEYWORDS=mips is less likely to result in breakage than running KEYWORDS=~mips? I think you'd need a much larger sample than one to get any meaningful answer there (and it might be worth doing it across all other archs too, to find out whether mips is in any way anomalous). Right, but if everyone I ask gives me an answer like this, it will take quite a while before we have even two opinions... As you are engaged in this discussion very heavily, I thought that maybe you are a occasional MIPS user, that could point out, that for example removing stable keywords for all MIPS packages, would have a quite negative impact for most MIPS boxes. The thing that really bothers me about this discussion is, that there seems to be almost no input from the people actually affected (users and developers), which makes the whole thing a bit pointless, unless it turns out that exactly this is the problem, in which case MIPS support may be removed entirely without doing any harm. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild
On 02:10 Thu 13 Dec , Justin Bronder (jsbronder) wrote: 1.1 sys-cluster/openmpi/openmpi-1.2.4.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1content-type=text/plain Why have you removed the ifc USE flag (as well as a few others), that was present in the ebuilds that can still be found at bug 166787? Matthias signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild
On Fri, 2007-12-14 at 12:13 +, Sébastien Fabbro wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/12/07 10:24, Matthias Langer wrote: On 02:10 Thu 13 Dec , Justin Bronder (jsbronder) wrote: 1.1 sys-cluster/openmpi/openmpi-1.2.4.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-cluster/openmpi/openmpi-1.2.4.ebuild?rev=1.1content-type=text/plain Why have you removed the ifc USE flag (as well as a few others), that was present in the ebuilds that can still be found at bug 166787? For icc and f90-typesafe, I advised him to do so on #gentoo-science. Well, too bad that gfortran generates code that is often not even half as fast as the code generated by ifc. Thus, there is a *very valid* reason to prefer icc over gfortran when it comes to performance critical software, which programs that use MPI almost always are. However, the fortran eclass prefers gfortran over ifc even if both are installed (which is fine by me as long as it can be overridden) and the fortran-compiler-wrapper mpif90/opal_wrapper (which is a binary for some reason) wrapps gfortran then. For sure, something like F77=ifort FC=ifort FFLAGS=-O3 -xO emerge -av openmpi still does the trick, but if i want that f90-typesave stuff back, this line would have to be certainly a bit longer... Maybe someone can explain to me what positive side effects the removal of the ifc USE flag has - and why this flag is generally discouraged. ifc/icc use flags should be avoided (see bug #97929). Disabling f90-typesafe did not make much sense as a use flag once you have the fortran one enabled, but why --with-mpi-f90-size=medium and --with-f90-max-array-dim=4 disappeared I don't know. The reason it disappeared is that it makes gfortran horribly slow when compiling against mpi. This is not the case with ifc, and therefore the old ebuild in bugzilla emitted a bold warning when emerging with USE=-ifc f90-typesafe but kept quiet if USE=ifc f90-typesave. Thus it *did make sense* to control it with a USE flag, at least with the ifc USE flag being around also. For the gm and gx flags, I don't know, and there is still a nocxx one. I'm not qualified to talk about these flags as I've never used them. Matthias signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/openmpi: ChangeLog openmpi-1.1.1.ebuild openmpi-1.2.4.ebuild
On Fri, 2007-12-14 at 16:16 +, Sébastien Fabbro wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14/12/07 14:12, Matthias Langer wrote:
F77=ifort FC=ifort FFLAGS=-O3 -xO emerge -av openmpi
This how it should be. To make it automatically reproducible, specify
environment variables in the configuration files.
Hmm, i know this isn't a support list, but as it fits quite well: can
you tell me what configuration files I have to look for?
Maybe someone can explain to me what positive side effects the removal
of the ifc USE flag has - and why this flag is generally discouraged.
Positive side effect: avoid cluttering the tree. Why icc/ifc are
discouraged: you can always try to compile every C/C++ package with
CC=icc and fortran packages with F77=ifort or FC=ifort. Packages which
do specify more options with e.g. --enable-icc and friends can be easily
worked out with the toolchain-funcs and fortran eclass, and most of the
time they do nothing more than specify the environment variables.
If we allow icc/ifc flags, at some point, we could allow a whole bunch
of other compiler flags such as sunstudio. New keywords for compilers
could be a better idea, but I doubt we have the human resources to test
them.
Well, I basically agree. However, it should be noted that fortran cannot
be compared with C/C++. The latter are the languages no gentoo box can
live without, while fortran is a rather exotic kind of beast, that for
mostly historical reasons, is still used in scientific computing.
Last but not least, ifc is in the tree, while sunstudio is not...
To cut a long story short: I'm not completely happy with your reasoning,
but you convinced me nonetheless ;-).
The reason it disappeared is that it makes gfortran horribly slow when
compiling against mpi. This is not the case with ifc, and therefore the
old ebuild in bugzilla emitted a bold warning when emerging with
USE=-ifc f90-typesafe but kept quiet if USE=ifc f90-typesave. Thus
it *did make sense* to control it with a USE flag, at least with the
ifc USE flag being around also.
If the f90-typesafe options always improve compilation time with
gfortran only, why not using something like this (modified from the
openmpi bump bug):
To be exact, f90-typesafe slows down gfortran horribly, while ifc
seems to run as fast as normally with it...
if use fortran; then
case ${FORTRANC} in
g77) myconf=${myconf} --disable-mpi-f90 ;;
gfortran) myconf=${myconf} --with-mpi-f90-size=medium
myconf=${myconf} --with-f90-max-array-dim=4
;;
if*) myconf=${myconf} blah ;;
*) die unsupported fortran compiler: ${FORTRANC}
esac
else
myconf=${myconf} --disable-mpi-f90 --disable-mpi-f77
fi
Well, openmpi-1.2.4-r1 has just been commited by jsbronder and contains
code like this...
Matthias
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] checkrestart from debian-goodies
http://www.arcdraco.net/~dragon/checkrestart (Needs lsb-release, portage-utils, lsof and python) looks interesting indeed... whats also interesting: is there a reason for lsb-release (a shell script) to be keyworded for x86 only? matthias -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
On Thu, 2007-07-12 at 13:24 -0700, Mike Doty wrote: All- We're going to change the -dev mailing list from completely open to where only devs can post, but any dev could moderate a non-dev post. devs who moderate in bad posts will be subject to moderation themselves. in addition the gentoo-project list will be created to take over what -dev frequently becomes. there is no requirement to be on this new list. This will probably remove the need for -core(everything gets leaked out anyway) but that's a path to cross later. We're voting on this next council meeting so if you have input, now would be the time. --taco no offense, but this is one of the worst proposals i've ever read on this list; why? because, one of gentoo's major problems is that it is becoming more and more a toy exclusively for its own developers. by banning non-dev contributors from this list some of you may feel better - but gentoo as a whole will probably suffer. silencing people doesn't make their opinions invalid. what gentoo needs in my opinion is a clear structure, strict and unmistakable rules about what $dev may do and what $dev must not do, and ways to enforce these rules; this, and not moderating or restricting communication channels, would improve the way people are working together. as this may be my last post - and it seems to fit in quite nicely - i also want to say: gentoo's problem is not that ciaranm is a troll. the problem is that ciaranm is not a troll. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Script for easier stabilising of ebuilds
On Sun, 2007-07-08 at 14:45 +0200, Lars Weiler wrote: * Christian Faulhammer [EMAIL PROTECTED] [07/07/08 12:31 +0200]: Lars Weiler [EMAIL PROTECTED]: Comments are welcome! Have a look at app-portage/gatt-svn and help improve it. :) It's C++ :-( well, helping doesn't necessarily mean coding... just tell me exactly what kind of feature you are missing and what i need to know to provide a proper implementation; should we have made it this far, all you need to do is to give me some feedback and help me with testing. you don't have to even look at a single line of c++ ;-) matthias -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [RFC]: gentoo-politics ML
On Mon, 2007-06-11 at 19:01 +0200, Alexander Gabert wrote: The person has personally attacked me after i simply concluded that he should maybe change his attitude to make a better impression on gentoo-dev and Gentoo developers. This guy is trolling for years and he enjoys and knows it all too well. The gentoo-dev mailing list can be transformed to a technical mailing list again with setting up a gentoo-whatever mailing list where people like him can be the king with the crown and be right about their stuff. [...] if you came to the conclusion, that ciaranm is some kind of ultra-nasty troll, then why is it so hard for you to just ignore him? matthias -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [news-item] Paludis 0.24
On Sat, 2007-05-05 at 16:51 +0100, Ciaran McCreesh wrote: On Sat, 5 May 2007 17:44:46 +0200 Marius Mauch [EMAIL PROTECTED] wrote: Why did I knew that this argument would come? Maybe because it's your default reaction to any opposition. What, providing evidence to the contrary? What more do you want? Can we please stop that fruitless discussion. If the maintainers of the paludis ebuild think that they should release a news item, why not just let them, if only paludis users will be affected? If we have discussions like this for every news item, we could just drop them at all. Matthias -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for May
On Thu, 2007-05-03 at 08:11 +0100, Roy Marples wrote: On Wed, 2 May 2007 22:00:05 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: What, people deliberately breaking policy that directly leads to breaking stable and not having any working ebuilds for a package in the tree, and then refusing to do anything about it is nothing? the issue has been taken care of You have a conflict of interest in this one. What do other Council members who aren't games team members think? [to the detriment of users] How is not having broken packages committed straight to stable detrimental to users? I maintain and play a game called Eternal Lands. I'm a Council member, but not part of the games team/herd. One of the problems games have with stable/unstable/testing/whatever keywords is that upstream changes things that in any other application just would not change. For example, the network protocol when talking to servers. EL is very version specific and when a new client is launched, around once every 6 months they change over right away. That means our users need the game right away. ok, agreed, this is a valid point. so i would suggest, that maintainers of games where this argument applies, come to special agreements with the arch teams - or just file bugreports like this: although games-foo/lord-of-bar-2.4.6 has just been bumped, i would like to have it stable real soon, as upstream has changed the network protocol. i have x86 and amd64 hardware available, and can confirm, that the game works nice there; so, if no one objects, i'm gonna mark lord-of-bar-2.4.6 stable on x86 and amd64 in two days. i would also like to have a shiny sparc keyword, but have no hardware to test. so it would be highly appreciated if someone from the sparc team can give the game a try. but committing straight to stable on arches where the package wasn't even tested is an absolute no-do for me. DISCLAIMER: I've not read the bug mentioned as I've lost the email with it's number so I may just be talking out of my ass. no, in fact you are the first one that comes up with a valid argument, why games sometimes should go to stable almost immediately. sad, but true... -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: File collisions
On Fri, 2007-04-20 at 09:06 +0200, Rob C wrote: Its obviously not, Many users are reporting file-collisions on a weekly basis. So either this isn't sufficient or the arch teams are not acting as you describe. Can you provide some bug numbers to backup this claim? Matthias -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: File collisions
On Fri, 2007-04-20 at 19:56 +0200, Marijn Schouten (hkBst) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthias Langer wrote: On Fri, 2007-04-20 at 09:06 +0200, Rob C wrote: Its obviously not, Many users are reporting file-collisions on a weekly basis. So either this isn't sufficient or the arch teams are not acting as you describe. Can you provide some bug numbers to backup this claim? Matthias I count 33 open collision bugs http://bugs.gentoo.org/buglist.cgi?quicksearch=collision and 21 of those reported by users with a non-gentoo email. http://tinyurl.com/3x9yt2 Well, these are quite some bugs; however, at least the x86 arch team (can't speak for the others, but i think they do it the same way) always tests packages with collision-protect. Since i'm an arch tester, i've never seen that a package where we found collisions went to stable, before these where fixed. Of course, we may have missed some collisions every now and then, as it is in practice not possible to *ensure* that a package has no collision with other packages. As for enabling collision-protect by default: I'm not sure if this is a good idea for now, as my experience is, that a significant part of the packages that fail with collision-protect do so because of stale files, that have been left around by (older versions of?) portage. As soon as this is no longer the case, enabling collision-protect by default sounds like a very good idea to me. Matthias -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
not having it tested. That all depends. If having it tested means that it _will_ work, I'd be infavour of that. Well, the problem is, that a working test suite does not guarantee a working program, as well as a failing test suite doesn't necessarily mean that the program is broken. This doesn't mean that test suites aren't useful (i tend to write lot's of unit tests when I'm programming myself), but I would say that they are targeted at developers, both up- and downstream, not at end users. Thus, considering all arguments i've seen so far, i would highly appreciate it, if various src_test functions in the tree see some love, maybe encouraged due a changed policy, but i don't think that package managers should enable test suites by default. If you want some test action, try sys-devel/autoconf with tests activated with the package manager of your choice ;-) Matthias -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Sat, 2007-04-14 at 14:58 +0300, Petteri Räty wrote: Steve Long kirjoitti: That makes a lot of sense. How about exending it a tiny bit and asking for it to be policy for all ebuilds EAPI=1 not to be allowed into stable without RESTRICT=test, or a functional test suite on the arch in question? The last bit would be automagically checked by the arch team, if the ebuild has no RESTRICT=test, during normal stabilisation (I'd hope?) since the build would fail. And this is different from the current policy in what way? Hmm, i don't want to offend anyone, i don't even want to say that it was wrong to push these to stable regarding the current situation, but what, for example, about these? bug 165085 bug 133002 bug 156572 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
The arch teams have been pushing for this for a long time. They're trying to get this enforced, but are having limited success because there's no way for FEATURES=test to become widely used that won't lead to broken user systems. Moving src_test to be always on in future EAPIs is an easy way of helping arch teams achieve this goal without breaking anyone's system in the meantime. Hmm, as an arch tester, i completely agree that packages where src_test fails are an annoyance. However, I would not suggest to activate src_test by default, as for normal users, it just introduces another source of potential defects, without that much benefits. Instead, i think that arch teams should refuse to stable packages that fail with FEATURES=test and thus encourage ebuild developers to either fix their tests, or to deactivate them explicitly. Matthias -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Why don't you just ...
On Wed, 2007-04-11 at 13:47 +0200, Christian Faulhammer wrote: Matthias Langer [EMAIL PROTECTED]: Well, I don't know what your problem really is about; I'm running x86, and if something breaks on my system, it's mostly not because of broken packages, but because I should have been informed about possible issues that could have been caused by an upgrade, and how to avoid them. Often, ebuilds contain very important information that are brought to the user via elog, ewarn and friends. The problem with this approach is, that I won't read these messages if I'm doing a world update while I'm asleep. This is, why I think, that it should be one of Gentoos highest priorities to implement Glep 42 and make heavy use of it. Use the ELOG features of Portage. The needed software has been packaged by your master-dev. :) app-portage/elogviewer in your case... Thanks for that tip - app-portage/elogviewer seems to be an interesting program. However, it is not an alternative for glep 42 as it may not inform me about possible issues *before* it might be almost too late. While for me, searching through the logs, to fix things afterwards is acceptable, it is not on a system where functionality is critical. Matthias -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 2007-03-30 at 14:04 -0400, Mike Frysinger wrote: On Tuesday 27 March 2007, Ciaran McCreesh wrote: Do you acknowledge that Portage is a severe limiting factor when it comes to improving the Gentoo user experience as a whole? what a lame question ... rather than waste time on this, why dont we get to some relevant issues ... to start with, Paludis will never be an official package manager for Gentoo so long as you are heavily involved. i don't think that personal issues should be taken into account when it comes to choosing a new official package manager for gentoo. Matthias -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
I'm very strongly against using Gentoo SoC time and resources for things that are not officially part of Gentoo (yes, this statement could be spun however you wish) or are not official Gentoo projects. And no, just because a project has Gentoo developers in it doesn't mean that it's a Gentoo project -- let's avoid the gray areas now, shall we? Just because we have Gentoo devs who are also Gnome upstream doesn't make their Gnome-related packages that happen to be in our tree official Gentoo projects. In my opinion, any project that has reasonable potential to improve Gentoo as a whole *and* is strongly related to Gentoo should be considerable for SoC. While this is certainly not the case for say Improving gtk+, it definitely is for Pepers project. After all, what is PMS all about, if we keep on evaluating package managers solely on being official Gentoo projects or not? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Distrowatch
On Wed, 2007-03-14 at 18:18 +0100, Christian Faulhammer wrote: Kevin F. Quinn [EMAIL PROTECTED]: So please, friends, just ignore it, nothing positive will come of it. Unfortunately it made its way onto big news site and lowers the view on Gentoo even more. From many comments I read we are a dying distro. Gentoo will die the moment nobody cares for it any more; as long as big news sites care to spread some FUD about it every now and then, this is definitely not the case! so heads up - Gentoo is a great distro! -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
On Tue, 2007-01-30 at 06:27 +, Ciaran McCreesh wrote: [ Background: tr1 is a set of extensions to the C++ Standard Library giving various useful things like hash tables and smart pointers. There are partial implementations included in g++-4.1 and boost and full implementations available from Dinkumware. It is likely that a lot of C++ apps will start using it in the not too distant future. ] What is the best way to handle packages that require parts of tr1? The options appear to be: * Hard dep upon boost. This sucks for g++-4.1 users. * Hard dep upon g++-4.1, which isn't available for all archs. This doesn't even work because there's no guarantee that =4.1 is being used even if it's installed. isn't it possible to check the version of gcc that is in _use_ in an ebuild, like i can do in a configure script? if so, one could provide a old-gcc use flag that must be enabled when trying to build with gcc-4.1.0 (that actually pulls in boost etc.) and must not be enabled when using =gcc-4.1.0 ... * || ( ) deps, and hope that if the user has 4.1 installed then they're using it. Since library implementations aren't runtime switchable, this will lead to breakages if users upgrade gcc and then remove boost. switching gcc versions may lead to breakage anyway if the user doesn't know what he/she is doing. None of these are particularly nice... nope ... let's hope c++-0x comes out soon and that compiler vendors are faster in implementing it than c++-98. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] jpeg-mmx is dead
On Mon, 2006-11-06 at 02:31 -0500, Mike Frysinger wrote: On Sunday 05 November 2006 22:42, Matthias Langer wrote: however, someone should adapt media-video/mjpegtools-1.8.0-r1 (see bug 154199) and someone should search for duplicates before filing bugs ups ... sorry - i should have looked after closed bugs too. this should not excuse the fault on my side, as i should have known better, but: a close in 48h-button in bugzilla would surely reduce the number of duplicates in a significant way. in fact, not looking after closed bugs before filing your own as a user, without cvs access to the tree, is always risky, as the fix may not yet be distributed to the rsync mirrors ... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] jpeg-mmx is dead
On Sun, 2006-11-05 at 02:26 -0500, Mike Frysinger wrote: upstream says it's dead and they dont want people using it ... considering the problems we've seen that sounds just peachy fine ... however, someone should adapt media-video/mjpegtools-1.8.0-r1 (see bug 154199) thanks, matthias -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] firefox-1.5.x still in ~arch
I'm just curious: What is the reason that firefox-1.5.x is still in ~arch ? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: firefox-1.5.x still in ~arch
On Sun, 2006-03-19 at 07:56 -0700, Duncan wrote: Matthias Langer posted [EMAIL PROTECTED], excerpted below, on Sun, 19 Mar 2006 15:24:19 +0100: I'm just curious: What is the reason that firefox-1.5.x is still in ~arch ? General policy is that an ebuild should be bug-free in ~arch for 30 days before it is stabilized. Individual herds and maintainers may have their own policies, but the above 30 day guideline is the general Gentoo rule of thumb. Looking at the changelog, mozilla-firefox-1.5.0.1-r2 was only added to the tree on February 24. The -r2 indicates updates serious enough to bump the release number were released at least twice, and the 1.5 ebuilds are at -r9, indicating 10 versions (the first being -r0, not marked with an release number, of course). That's a /lot/ of versions! I'd guess there have simply been enough issues that no version of 1.5 has yet made it 30 days bug-free in ~arch, altho the .0.1-r2 version above is getting close to 30 days in ~arch now, tho I don't know its bug status. I often check the portage tree changelogs and Gentoo bugzilla site status of particular packages that I'm interested in. I'm glad the info is available, as it has proven useful quite often. -- Thanks for your answer; however, i've seen new versions of firefox getting from ~arch to stable much faster than 30 days, but i guess that was because of security issues; by the way, i was happy to read *mozilla-firefox-1.5.0.1-r1 (09 Feb 2006) 09 Feb 2006; [EMAIL PROTECTED] +mozilla-firefox-1.5.0.1-r1.ebuild: official branding support, ewarn about regchrome that gentoo now has official branding support ... Matthias -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.11.14 stabilization
On Tue, 2005-12-20 at 14:36 +, Mike Frysinger wrote: since we have baselayout-1.12.x in ~arch, the new stable candidate (1.11.14) isnt getting much air time ... can people try upgrading to it and post any feedback they have with it ? it should mostly be a bugfix release over 1.11.13 since we arent doing any more real features for the 1.11.x branch ... -mike Seems to work fine here ... Portage 2.0.51.22-r3 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.14.2 i686) = System uname: 2.6.14.2 i686 AMD Athlon(tm) XP 2400+ Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox:1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS=x86 AUTOCLEAN=yes CBUILD=i686-pc-linux-gnu CFLAGS=-O2 -march=athlon-xp -pipe CHOST=i686-pc-linux-gnu CONFIG_PROTECT=/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control CONFIG_PROTECT_MASK=/etc/gconf /etc/terminfo /etc/env.d CXXFLAGS=-O2 -march=athlon-xp -pipe DISTDIR=/usr/portage/distfiles FEATURES=autoconfig distlocks sandbox sfperms strict GENTOO_MIRRORS=http://gd.tuwien.ac.at/opsys/linux/gentoo/ LANG=en_US.utf8 LC_ALL=en_US.utf8 LINGUAS=de en MAKEOPTS=-j2 PKGDIR=/usr/portage/packages PORTAGE_TMPDIR=/var/tmp PORTDIR=/usr/portage PORTDIR_OVERLAY=/usr/local/portage SYNC=rsync://rsync.europe.gentoo.org/gentoo-portage USE=x86 3dnow 3dnowext X aalib alsa apm audiofile avi berkdb bitmap-fonts bzip2 bzlib cdr crypt cups curl dbus dvd dvdr emboss encode esd evo exif expat fam ffmpeg firefox foomaticdb fortran gd gdbm gif glut gmp gnome gphoto2 gpm gstreamer gtk gtk2 guile hal idn imagemagick imlib ipv6 java jpeg junit lcms libg++ libwww mad mikmod mmx mmxext mng motif mp3 mpeg ncurses nls nsplugin nvidia ogg oggvorbis opengl oss pam pcre pdflib perl plotutils png python readline recode ruby sdl slang speex spell sqlite sse ssl svga tcltk tcpd tiff truetype truetype-fonts type1-fonts udev unicode usb vorbis win32codecs xine xml xml2 xmms xv xvid zlib linguas_de linguas_en userland_GNU kernel_linux elibc_glibc Unset: ASFLAGS, CTARGET, LDFLAGS Matthias -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] gcc-3.4 migration guide
Well done, i've allready switched completely to gcc-3.4 with my main box by reemerging about 650 packages. However, i allready started doing so a few days ago, so I didn't read the official migration guide before starting. Now, as everything works fine i just read this guide to compair it with my own experiences as more or less simple user. There are two things i have to critisize: 1.) If you remove gcc-3.3* before emerge -e system you will be left behind with a broken python and therefore emerge. Thus i think there should be a big red box telling users about this. 2.) emerge -e world on a system with lot of packages will most likley fail somewhere during the process for various reasons. Fixig the problem (for example by unmerging the package which causes it) and restarting the process is not an option, as this may cost you lot's of time. In my case, emerge -e world stopped 3 times. To continiue without starting it all again, i did # emerge --resume -p package.list and then edited this file with vi so that # emerge --oneshot --nodeps `cat package.list` continued the process, leafing out the brocken package. The be honest, i expected to find some freaky sed command to accomplish what i did with vi (thanks to the makro recorder) in the gcc-3.4 migration guide. Have a nice day ! Matthias -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gcc-3.4 migration guide
On Sat, 2005-12-03 at 21:31 +0100, Jan Kundrát wrote: On Saturday 03 of December 2005 21:26 Matthias Langer wrote: 1.) If you remove gcc-3.3* before emerge -e system you will be left behind with a broken python and therefore emerge. Thus i think there should be a big red box telling users about this. Our guide says that you have to either run `revdep-rebuild` or `emerge -1 libstdc++-v3` and `emerge -e system` before unmerging old version of GCC. Of course you are right. I didn't say the the guide doesn't mention this, i just said that in my opinion this should be mentioned more eye catching, just to be sure. WKR, -jkt -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gcc-3.4 migration guide
On Sat, 2005-12-03 at 14:04 -0700, Joshua Baergen wrote: Matthias Langer wrote: 2.) emerge -e world on a system with lot of packages will most likley fail somewhere during the process for various reasons. Fixig the problem (for example by unmerging the package which causes it) and restarting the process is not an option, as this may cost you lot's of time. In my case, emerge -e world stopped 3 times. To continiue without starting it all again, i did # emerge --resume -p package.list and then edited this file with vi so that # emerge --oneshot --nodeps `cat package.list` You'd probably be interested in 'emerge --resume --skipfirst'. :-) well, this is just the kind of information i had expected to find in the migration guide. By the way, please don't get me wrong, i highly appreciate the hard work you are all doing - gentoo really is a great project and my remarks here in this list have the sole purpose to make it eaven better. Matthias -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gcc-3.4 migration guide
On Sat, 2005-12-03 at 21:38 -0400, Luis F. Araujo wrote: Matthias Langer wrote: On Sat, 2005-12-03 at 14:04 -0700, Joshua Baergen wrote: Matthias Langer wrote: 2.) emerge -e world on a system with lot of packages will most likley fail somewhere during the process for various reasons. Fixig the problem (for example by unmerging the package which causes it) and restarting the process is not an option, as this may cost you lot's of time. In my case, emerge -e world stopped 3 times. To continiue without starting it all again, i did # emerge --resume -p package.list and then edited this file with vi so that # emerge --oneshot --nodeps `cat package.list` You'd probably be interested in 'emerge --resume --skipfirst'. :-) well, this is just the kind of information i had expected to find in the migration guide. By the way, please don't get me wrong, i highly appreciate the hard work you are all doing - gentoo really is a great project and my remarks here in this list have the sole purpose to make it eaven better. I don't know if somebody recently updated it, but this is on the guide. Well, my fault - maybe i just missed that - sorry. Matthias -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Thu, 2005-12-01 at 01:30 +0100, Marien Zwart wrote: On Wed, 30 Nov 2005 18:50:02 -0500 Mark Loeser [EMAIL PROTECTED] wrote: Jakub Moc [EMAIL PROTECTED] said: 1.12.2005, 0:29:48, Chris Gianelloni wrote: revdep-rebuild --library=libstdc++.so.5 is all that's needed here to avoid things like Bug 64615. Yea, I updated my statement on the bug to reflect this. C++ stuff should be the only thing affected, so this _should_ be enough. Its also already something that's been in the ebuild for a while now. Not sure if everyone is aware of this, but most installed pythons link to libstdc++.so. This is not a problem if you run the above revdep-rebuild (it should catch it just fine). It is a problem if you get rid of gcc 3.3 before installing libstdc++-v3 or running the revdep-rebuild, as it will leave you with a broken python and therefore unable to emerge. How right you are; that just happend to me two days ago after removing gcc-3.3.6 before emerge -e system on x86. Luckily it was a fresh install ... matthias -- Marien. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Fri, 2005-12-02 at 03:03 +0100, Matthias Langer wrote: On Thu, 2005-12-01 at 01:30 +0100, Marien Zwart wrote: On Wed, 30 Nov 2005 18:50:02 -0500 Mark Loeser [EMAIL PROTECTED] wrote: Jakub Moc [EMAIL PROTECTED] said: 1.12.2005, 0:29:48, Chris Gianelloni wrote: revdep-rebuild --library=libstdc++.so.5 is all that's needed here to avoid things like Bug 64615. Yea, I updated my statement on the bug to reflect this. C++ stuff should be the only thing affected, so this _should_ be enough. Its also already something that's been in the ebuild for a while now. Not sure if everyone is aware of this, but most installed pythons link to libstdc++.so. This is not a problem if you run the above revdep-rebuild (it should catch it just fine). It is a problem if you get rid of gcc 3.3 before installing libstdc++-v3 or running the revdep-rebuild, as it will leave you with a broken python and therefore unable to emerge. How right you are; that just happend to me two days ago after removing gcc-3.3.6 before emerge -e system on x86. Luckily it was a fresh install ... But besides of this fact, which was my very own fault, i'm very happy with gcc-3.4. I thought, that maybe some c++ packages would fail to compile, as I'm a c++ devel myself and know that there are differneces in the c++ code that gcc-3.3.x and gcc-3.4.x are accepting. However, I'm running gcc-3.4 now on 2 of 3 gentoo boxes i'm mentaining and are very pleased with the results. matthias matthias -- Marien. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] contents of /dev after initial installation
I'm just a more or less simple user of gentoo who somtimes tries to look a bit behind the curtain, so if you think this posting doesn't belong to gentoo-dev let me know. However, maybe this is interesting to you: Recently i've got serious trouble with one of my hard drives, so that i was forced to move my gentoo root partition from one hd to another. I successfully did so by mainly rsync -av source dest directory after diretcory. However, there are /proc, /dev and /sys which are different. Especially on the /dev part i was unsure how to do this, so i looked at the gentoo-udev guide once again, and found out, that for a working udev, which i can confirm as i'm writing this mail, only the nodes console and null are requred to exist in the /dev diretory initially. That's the reason why i was i little bit surprised as # mkdir test # mount --bind / test # cd test/dev # ls revealed that there are in fact hundrets of premade device nodes in the /dev directory. And this is not only true for the box where i discovered this, which was brought up from a 2004.x cd, but also true for the box where i just installed gentoo from 2005.1-r1. Is there any reason for this ? Matthias -- gentoo-dev@gentoo.org mailing list
