Re: [gentoo-dev] Re: stabilizing expat 2.0.0
Duncan написа: Caleb Tennis [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 16 May 2007 13:48:35 -0400: I have no problem waiting for 2007.1, if Gnome and KDE don't mind. I don't know what hackery has to take place to do that, but I'm sure someone out there does. What sort of timing are we looking at for 2007.1 anyway? With .0 delayed as it was, is .1 going to be relatively quick, say August, or are we looking at November now? If it's August, there shouldn't be much KDE to upgrade, maybe stabilize 3.5.6. 4.0 is the big one, but that's tentatively timed for Sept. if I'm not mistaken, and if release dates don't slip. If 2007.1 is November, there's a slim chance of getting 4.0 in, but not if it's like 3.5 was (IIRC 3.5.0 and 3.5.1 never stabilized, it was 3.5.2 before the issues were worked out enough to stabilize, which would put bump stable KDE 4.0.x to 2008.0 at the earliest). I doubt anyone wants to wait for a a November expat-2 stabilization, however, so if 2007.1's going to be that long, unless we want to talk about 2007.0-r1 and I doubt anyone's up for that either, the timing just doesn't look like it's going to work for a release/profile timed expat-2 stabilization. It'd be nice, but... So what /does/ the timing look like for 2007.1? Hi, Might i sugest making an doc expat-upgrade and posting it in Docs (or some dev's space). This only for those who can't wait and want earlier upgrade. Even can participate in making it, if needed. Rumen smime.p7s Description: S/MIME Cryptographic Signature
[gentoo-dev] OT: was 2007.0 release
Hi, Tempted by this recent thread, wanna just voice my thoughts. Can't there be some way (GWN, Bug, some general-purpose IRC channel etc.) on which users could at least be informed that work is under way to release 2007.0, with some kind of feedback. Releng could just choose to ignore it at all, but it's a possibility to inform users that work is done (once in a week or two). It's clear nobody can work on a busy/noisy street ;) so the current ways are ok. It's also evident that people who donate there time/force to work for others can't be pushed for anything, just a way to escape creating some tension among users. Somebody might want to know (for a new install) for how long (eventually) he/she will have to wait. A true community must communicate to be a community at all. The errors/weak points we make is what makes are go forward :) So nothing wrong with any kind of problems here (don't imply there are any). Time to finish, lets hope i could make myself clear enough. NO flames intended. Rumen -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Hi, On Fri, 30 Mar 2007 15:28:52 -0400 Seemant Kulleen [EMAIL PROTECTED] wrote: On Fri, 2007-03-30 at 20:42 +0200, Matthias Langer wrote: i don't think that personal issues should be taken into account when it comes to choosing a new official package manager for gentoo. It's relevant in that people have to work with the developers of the package manager. Unlike most other things in the portage tree, the package manager ties very closely to the very definition of the distribution itself. Hence, if people are unable to get along, then by adopting a package manager like that, you inherently adopt the developers of that package manager and all the personnel issues that accompany it. Ideally, however, I agree with you that it should be based on technical merits. The reality is that there are people involved. And people always complicate things. Isn't it true that people are meant to solve/facilitate things, not to make them harder/more complicate ? Rumen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Cultural Differences (was: Suggestion: INVALID - NOCHANGE in bugzilla)
On Sun, 25 Mar 2007 09:37:04 +0200 Denis Dupeyron [EMAIL PROTECTED] wrote: On 3/25/07, Alec Warner [EMAIL PROTECTED] wrote: Well I'm a native speaker [...] Yeah, right. May I remind you that you're a USian ? obligatory_smiley :o) /obligatory_smiley Denis. Hi, May be a little OT, but just two of four ancient-sayings: 1.Never accept things personaly (everyone is acting on his own motives); 2.Try not to make assumptions (just ask questions, till you get it). Clearly (from above, etc.) i'm not a native speaker, so forgive my wording. Hope you get the meaning ;) Better try to find common grounds, that assume something which (very often) isn't true at all. Rumen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resignation (was: Project Sunrise resumed)
On Sun, 30 Jul 2006 23:50:40 -0400 Brett I. Holcomb [EMAIL PROTECTED] wrote: Hi, Continue with *top-posting* as it is. Does Gentoo gives more choises to users or not? With the freedom/choise comes the responsibility (if anything breaks). Gentoo is known not to be for *everybody* (unless he/she is willing to learn quite stubborn to use it). These ebuilds *are* already in Bugzilla, and for some there're people interested in maintaining/improving them. IMHO this is better then an ebuild/s which seats for 2-3 years and is of *outstanding quality*. The world is in motion not static. The overall concern (for me) with 'sunrise' similar is the availability (in advance) of some *good/understandable* information about some consequences in using such project/s. Just a warning no more. All this on main docs page (to be visible). E.g. some of the current *semi/official* overlays mess with the versions in the *main tree* so i have to mask/unmask things to do what i want (i accept this). Just my point of view, no more. Rumen My concern is beyond me. As I stated I know enough about what to expect IF I use sunrise. But many do not and with it becoming official people figure it's gentoo and when it breaks Gentoo suffers. Gentoo has a reputation as a good solid, stable distro. As user and big fan of Gentoo I'm concerned - why couldn't sunrise have stayed unoffical like BMG. Why does it have to be official? Gentoo can choose to do what it feels is right and I will do the same. I answered only because someone asked for user's concerns well this is mine and you all can do with the input as you please without any hard feelings on my part. On Sunday July 30 2006 23:42, Seemant Kulleen wrote: OK wait, on your servers, are you actually planning to *use* any of the ebuilds in Sunrise's overlay? If not, how is it a concern? I personally don't use any of them, and my system is running perfectly fine. Let's not forget that nobody is shoving Sunrise down anyone's throat... -- Seemant Kulleen [EMAIL PROTECTED] Gentoo Foundation / Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Official overlay support
On Thursday 23 March 2006 19:16, Duncan wrote: Chris Bainbridge posted [EMAIL PROTECTED], excerpted below, on Thu, 23 Mar 2006 12:47:13 +: Adding the ebuilds to overlays is one option, but then other users will be expected to find an overlay with their package in, and then add it to make.conf. ... This hints at something I wasn't aware of. Does it mean that portage already supports remote overlays, using them as it would a local overlay only over HTTP/FTP/RSYNC, the the appropriate URL placed in make.conf, or must the user manually sync the overlay to a local dir using whatever protocol and let portage access the overlay from there? I had assumed a separate manual sync was necessary. Was I assuming incorrectly? Can it be as simple as putting the URL in make.conf? Wouldn't that be rather resource intensive in terms of portage access to the remote server? Or was the step of acquiring a local copy of that overlay simply omitted and a reference to that local copy, not the global instance, assumed, when mentioning putting it in make.conf? -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html Hi, Using a remote overlays is rather simple, just do emerge layman. Read the einfo and then man layman. It works flawlessly, just tested this with one remote overlay. Beside that man layman explains pretty much of it's innerwork. PS:There's an article in gentoo-wiki.com with a list of overlays. HTH.Rumen pgpJq5nfb3zgW.pgp Description: PGP signature
Re: [gentoo-dev] Re: Official overlay support
On Thursday 23 March 2006 20:43, Chris Bainbridge wrote: On 23/03/06, Rumen Yotov [EMAIL PROTECTED] wrote: Hi, Using a remote overlays is rather simple, just do emerge layman. Read the einfo and then man layman. It works flawlessly, just tested this with one remote overlay. Beside that man layman explains pretty much of it's innerwork. PS:There's an article in gentoo-wiki.com with a list of overlays. HTH.Rumen What is the status of those overlays? I believe the php, webapps, and java ones (at least) are official (in that they're run by gentoo devs) and bugs are to be reported to bugs.g.o, no? But the wiki page http://gentoo-wiki.com/Portage_Overlay_Listing says NEVER report bugs at bugs.gentoo.org for these ebuilds. So where should users report bugs? And how are they to know that? Hi, From a very quick scan - yes there're some overlays made/supported by Gentoo devs and some others are hosted/maintained by users,so i think for the latter case you can't use Bugzilla in a sense that the ebuild is not in the tree. But looking from another angle (POV) if this is a new version ebuild or an ebuild for a new (not in the tree) package, why not report it's status/workings/bugs in Bugzilla, generally it'll be an usefull info. Like now when somebody files a Bug on a new version or makes and attaches initial ebuild for a new package. Of course all depends on the policy (if any is made) about this external (official unofficial) overlays and Bugzilla. PS: you can yourself see/read there're big differences in opinion even between Gentoo devs conserning overlays. So a bug-report assigned to a dev who doesn't want to support overlays will probably get WONTFIX whatever. Rumen pgpz5HMo6A5Kr.pgp Description: PGP signature
Re: [gentoo-portage-dev] eix esearch problems with portage-2.1_pre6-r3
Hi Zac, On Saturday 18 March 2006 10:44, Zac Medico wrote: Rumen Yotov wrote: Hi, Recently have problems with latest portage-2.1_pre6-r3, specially when using eix and now esearch too. In the former case (eix) it gives too little packages in the database: Strange is that this happened just after i emerged qt-3.3.6 (which wanted me to rebuild kdelibs), and so i run: eix kdelibs getting nothing as result. Using metadata_overlay patch + FEATURES=... -metadata-transfer You don't need a patch to use metadata_overlay because it's included in 2.1_pre6. All you need to do is put portdbapi.auxdbmodule = cache.metadata_overlay.database in /etc/portage/modules and nothing more. If that's all you've done, then please file a bug for the CacheCorruption error. Here's my previous: === # cat /etc/portage/modules portdbapi.auxdbmodule = cache.metadata_overlay.database === Looked now but couldn't identify any metadata-patch (unless integrated) but it was on a mail two-three days ago (subj:kudoos to all on this ML). PS: will try emerge --metadata. Didn't file a Bug as i think it might be some config/other error on my side. TIA.Rumen Yeah, checked with 'qfile', so it's integrated in 2.1_pre6. Great. Try `rm -rf /var/cache/edb/dep` and that might help. Normally, you don't need to run `emerge --metadata` when you have the metadata_overlay cache module enabled. Zac Will keep you informed, thanks again. Rumen pgpev5EEKYooC.pgp Description: PGP signature
Re: [gentoo-portage-dev] eix esearch problems with portage-2.1_pre6-r3
On Saturday 18 March 2006 20:51, Zac Medico wrote: Rumen Yotov wrote: On Saturday 18 March 2006 10:44, Zac Medico wrote: If that's all you've done, then please file a bug for the CacheCorruption error. The error that you've received could be related to this: http://bugs.gentoo.org/show_bug.cgi?id=126692 Will keep you informed, thanks again. Rumen If you still have cache entries that cause the error to occur, their content may provide a clue for this bug. Zac Hi, No more crashed, sorry (i'm happy though ;) Rumen pgpw94WcGeiun.pgp Description: PGP signature
Re: [gentoo-portage-dev] vdb-update script (for global updates) with job progress framework
On Tuesday 28 February 2006 15:28, Zac Medico wrote: Hi everyone, I've been working on a script for doing global updates on packages installed in the vdb (related to bug 122089). It's called vdb-update [1] and it does basically the same thing as fixpackages but it works on installed packages instead of binary packages. vdb-update has the beginnings of a job progress framework that portage can use to run various time consuming tasks, display progress, and interrupt tasks when necessary. When vdb-update and fixpackages are ready, I'd like to make both of them into emaint modules. In order to run the script, you will need at least revision 2801 of portage, so I have made an svn snapshot and ebuild available [2] for the convenience of anyone who would like to try it. Your feedback on vdb-update (in it's unfinished state) would be appreciated. Zac [1] http://dev.gentoo.org/~zmedico/portage/branches/2.1/bin/vdb-update.py [2] http://dev.gentoo.org/~zmedico/overlay/sys-apps/portage/portage-2.1_pre2006 0228.ebuild Hi, Thanks, it works for me. Rumen pgpn0ELB0VT2O.pgp Description: PGP signature
Re: [gentoo-portage-dev] Portage-2.1_pre5
On Wednesday 22 February 2006 10:32, Zac Medico wrote: Rumen Yotov wrote: On Wednesday 22 February 2006 03:07, Alec Warner wrote: Your testing is appreciated. [1]http://dev.gentoo.org/~zmedico/overlay/sys-apps/portage/portage-2.1_p re5 .ebuild Hi, The install went w/o errors, but there's a problem afterwards. Before ever seeing 2.1-pre5 had an error (confcache) using 2.1-pre4, patched with 'confcache-final' + 'atomic-write' patches using FEATURES=confcache. Same with 2.1_pre5 (fcron-3.0.1). Thanks for testing. I think it will be a good release but it's nice to have a few different people try it before unleashing it. After disabling '...confcache...' in /etc/make.conf fcron-3.0.1 compiles OK. Should i file a Bug as i don't want to pollute the ML with error logs. Thanks for your work.Rumen I got curious and tried to compile fcron-3.0.0 with confcache-0.4.1 but got a permission denied error for /etc/shadow. I was able to compile it successfully with confcache enabled after I disabled userpriv (FEATURES=-userpriv). See the attached error log. Zac Hi, Disabling 'userpriv' solved the issue for me too, no more confcache errors. Thanks.Rumen pgp6aIJS13KqS.pgp Description: PGP signature
Re: [gentoo-portage-dev] Portage-2.1_pre5
On Wednesday 22 February 2006 03:07, Alec Warner wrote: Zac Medico has graciously done a pre5 release of the 2.1 tree and placed it in his dev space and on the mirrors. The ebuild is not currently in the portage tree, but please feel free to test it prior to it's actual release. The intent here is to hopefully catch any show stopping bug prior to it's 'actual' release. It is my estimation that a lot more users are running ~arch portage due to cache issues as well as added features ( confcache, parallel-fetch, etc ). The ebuild is at [1]. The tarball should be on the distfiles shortly, but if not the ebuild will fetch from Zac's devspace. Your testing is appreciated. [1]http://dev.gentoo.org/~zmedico/overlay/sys-apps/portage/portage-2.1_pre5 .ebuild Hi, The install went w/o errors, but there's a problem afterwards. Before ever seeing 2.1-pre5 had an error (confcache) using 2.1-pre4, patched with 'confcache-final' + 'atomic-write' patches using FEATURES=confcache. Same with 2.1_pre5 (fcron-3.0.1). After disabling '...confcache...' in /etc/make.conf fcron-3.0.1 compiles OK. Should i file a Bug as i don't want to pollute the ML with error logs. Thanks for your work.Rumen pgp413YAqfDvT.pgp Description: PGP signature
Re: [gentoo-dev] ERROR: gnome-base/bonobo-1.0.22 failed.
On Wed, 2005-11-02 at 10:56 -0600, Dale wrote: Well, it's me again. LOL I am trying to successfully finish a revdep-rebuild and am having a bit of fun with it. It wants to recompile gnome-base/bonobo-1.0.22 and it fails to finish the compile with this: ...SKIP... checking for GTK - version = 1.2.0... no *** Could not run GTK test program, checking why... *** The test program failed to compile or link. See the file config.log for the ... [EMAIL PROTECTED] / # * x11-libs/gtk+ Latest version available: 2.6.10 Latest version installed: 2.6.10 Size of downloaded files: 11,260 kB Homepage:http://www.gtk.org/ Description: Gimp ToolKit + License: LGPL-2 It looks like I have 2.6.10 installed even though it says 1.2.10. What's up with this? How I fix it? Thanks much. Dale, :-) -- To err is human, I'm most certainly human. Hi, An essential feature of portage is the ability to have two/three/more different (usually major) versions of the same package installed at the same time. Examples: GTK - 12 Glib 12 etc. etc. They are called SLOTS in gentoo terms. So the message means you don't have GTK-1.2.X. HTH.Rumen signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ERROR: gnome-base/bonobo-1.0.22 failed.
On Wed, 2005-11-02 at 11:41 -0600, Dale wrote: Rumen Yotov wrote: Hi, An essential feature of portage is the ability to have two/three/more different (usually major) versions of the same package installed at the same time. Examples: GTK - 12 Glib 12 etc. etc. They are called SLOTS in gentoo terms. So the message means you don't have GTK-1.2.X. HTH.Rumen I know Gentoo will let you have more than one version installed but it appears that I or it needs to do something so it will use which ever one it needs. I don't know how to do that, yet. Maybe Mike or you will help me with that 'yet' part. Maybe I need to install something new. Thanks, Dale :-) -- To err is human, I'm most certainly human. Hi, Wrote too fast, now checking things first. First advice is to recompile GTK+, this usually fixes things. Then bonobo again. Now to get some info first: ... #dep -l bonobo gnome-base/bonobo-1.0.22: =gnome-base/orbit-0* gnome-base/orbit-0.5.17 nls?=dev-util/intltool-0.11 dev-util/intltool-0.34.1 =gnome-base/gnome-print-0.30 gnome-base/gnome-print-0.37 =gnome-base/oaf-0.6.8 gnome-base/oaf-0.6.10 =media-libs/gdk-pixbuf-0.6 media-libs/gdk-pixbuf-0.22.0-r3 dev-lang/perldev-lang/perl-5.8.6-r6 nls?sys-devel/gettextsys-devel/gettext-0.14.4 sys-devel/gnuconfig sys-devel/gnuconfig-20050602 !bootstrap? sys-devel/patch sys-devel/patch-2.5.9 ... these are bonobo's dependencies. Now to check gdk-pixbuf: ... #dep gdk-pixbuf media-libs/gdk-pixbuf-0.22.0-r3: !amd64? sys-libs/db-2 sys-libs/db-1.85-r2 =x11-libs/gtk+-1.2* x11-libs/gtk+-1.2.10-r11 =gnome-base/gnome-libs-1.4.1.2-r1 gnome-base/gnome-libs-1.4.2 =media-libs/libpng-1.2.1 media-libs/libpng-1.2.8 media-libs/jpeg media-libs/jpeg-6b-r5 media-libs/tiff media-libs/tiff-3.7.3 sys-devel/gnuconfig sys-devel/gnuconfig-20050602 !bootstrap? sys-devel/patch sys-devel/patch-2.5.9 !!! ebuild_dep_to_stdout x11-base/xorg-x11-7.0.0_rc1 /var/portage X? virtual/x11 x11-base/xorg-x11-6.8.2-r4 ... See here gdk-pixbuf depends on =x11-libs/gtk+-1.2*. So it seems you must have GTK+-1.2.x. Use (the old deprecated) qpkg: qpkg --dups -v to check if you have both GTK+ installed (part of gentoolkit,but missing in latest versions). HTH.Rumen signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Sun, 2005-08-28 at 12:01 +0200, Simon Stelling wrote: Donnie Berkholz wrote: Brian Harring wrote: I don't recall having kde/gtk crap turned on by default when I first showed up. Maybe I'm missing something; regardless, the defaults (which should be minimal from my standpoint) are anything but. I think you recall wrong, then. The default USE flags have been set so that the majority of systems will work properly without modifications, not so that they're the minimal set. I agree with that, since it's easy to configure them, but the problem is that for most users, there is no default use flag at all. I'd say most of our users run either gtk (and gnome) or qt (and kde), but not both. Either you like gnome or kde ;) So we end up having qt, gtk, gtk2, gnome, kde and arts in the default use flags, but nearly nobody wants to use that, so I think it's better to have minimal use flags than pseudo-standard ones. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] Hi, Think that at least some users have both GnomeKDE (i for example). All this because there are some apps which are QT/KDE based and others are GTK/Gnome based. Using 'k3b' which requires QT/KDElibs, also kdebase-startkde just to have a working DE. Have full Gnome, but most time work using XFCE4. Initially when configuring my USE-flags took the default ones and put them (commented in /etc/make.conf) to see them and switch some ON/OFF. Rumen -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] flawfinder rats logs
Hi, Recently began using flawfinder rats and they're working (logging things). For now don't have time to look at the logs (beside *me* needing more time to check them), so is there some place/person which collects/is_interested in such info. Maybe some meta-bug or other, or just send they upstream (if correct)? Any experiences with them, are they correct? Thanks. Rumen. smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-dev] Even More Portage Bashrc Fun
Michael Tindal wrote:
Hello,
So a long time ago solar wrote a bashrc for portage, and posted it on
this mailing list for everyone to see. I took it, and started extending
it with various things of my own design, and some contributions from
others. I've since updated it with the things solar's been adding to
his bashrc, plus adding the functionality from ChrisWhites bashrc.
Well, adding all of that stuff made the bashrc quite large. In addition
I was using CVS for a while, and wrote a lot of hooks to work with CVS,
when I went back to 2.0.51, I didnt want to lose all of those, so I
backported in a way the hooks from CVS (I mean in a way because the post
hooks arent really post hooks, they just run before the pre hook of the
next phase), but that meant the bashrc was huge.
So, sometime last night or this morning I set out to create a modular
portage bashrc [1], and I have done so. I'll admit, the code is ugly,
and it probably could've been done better. But it does lay a good
framework for future extensions.
The bashrc file is just a skeleton that loads the modules, and handles
the pseudo-hook implementation. The real magic happens in the
bashrc-modules subdirectory. core-functions.bmod contains the basic
functions and handles loading other modules. hooks.bmod defines the
hooks used and defines functions used to add new function calls to the
hooks. The other bmod files define some sort of library for other
modules (like an eclass) or functions that get loaded into the hooks. I
don't have any documentation written up for that, so read through the
source and you should get an idea of how it all works.
The BASHRC_DYN_MODULES variable can be defined in make.conf to limit the
modules that are loaded by the bashrc. This is useful if you only want
to use a subset of the functionality available in the modules, and dont
want to load them all. The default behavior is to load all of the
modules under ${ROOT}/etc/portage/bashrc-modules/. To extend the
bashrc, for example, to add another feature, you simply create a new
bmod following the examples given, then either let it load automatically
or add it to BASHRC_DYN_MODULES.
I've done some thorough testing and beu did some testing as well, so
there shouldnt be any major bugs, but if you find some, please e-mail me
with them. I'm especially interested in command not found errors. This
is some really ugly bash code, so if you run into obscure errors, dont
freak out, theyre a result of how I deal with the infrastructure.
Overall though, it appears to be stable, and I'm currently using it on
my system.
Finally, I'd like to thank the people who directly or indirectly helped
with this bashrc and the bashrc system: solar, ChrisWhite, beu,
bluefoxicy, and anyone else who I forgot to name. Enjoy everyone!
Mike Tindal
PS: Heed the warning given in the setup phase, you *cannot* modify
variables that affect depends because the environment the bashrc
modifies isnt picked up by depends. Be very careful with what you do
with category.use, since that can very easily break builds.
[1]
http://dev.gentoo.org/~urilith/portage-tools/bashrc-2.0.51-modular-20050612.tar.bz2
I've got some sample files in that dir for the random files the bashrc
supports.
Hi,
Till now used the old/org bashrc-script plus package.* files.
Now when replaced them with the new one get some errors, seems just
syntax ones.
Here's the log when using it:
...
Loading module hooks.bmod...
Loading module string-utils.bmod...
Loading module audit.bmod...
Loading module autooverlay.bmod...
Loading module autopatch.bmod...
Loading module conf.bmod...
Loading module distdir-clean.bmod...
Loading module enotice.bmod...
Loading module etc-portage.bmod...
//etc/portage/bashrc-modules/core-functions.bmod: eval: line 103:
unexpected EOF while looking for matching `''
//etc/portage/bashrc-modules/core-functions.bmod: eval: line 104: syntax
error: unexpected end of file
//etc/portage/bashrc-modules/core-functions.bmod: eval: line 108:
unexpected EOF while looking for matching `''
//etc/portage/bashrc-modules/core-functions.bmod: eval: line 109: syntax
error: unexpected end of file
//etc/portage/bashrc-modules/core-functions.bmod: eval: line 103:
unexpected EOF while looking for matching `''
//etc/portage/bashrc-modules/core-functions.bmod: eval: line 104: syntax
error: unexpected end of file
//etc/portage/bashrc-modules/core-functions.bmod: eval: line 108:
unexpected EOF while looking for matching `''
//etc/portage/bashrc-modules/core-functions.bmod: eval: line 109: syntax
error: unexpected end of file
//etc/portage/bashrc-modules/core-functions.bmod: eval: line 103:
unexpected EOF while looking for matching `''
//etc/portage/bashrc-modules/core-functions.bmod: eval: line 104: syntax
error: unexpected end of file
//etc/portage/bashrc-modules/core-functions.bmod: eval: line 108:
unexpected EOF while looking for matching `''
//etc/portage/bashrc-modules/core-functions.bmod: eval: line 109: syntax
Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers
Paul Varner wrote: On Wed, 2005-05-25 at 18:20 -0400, Mike Frysinger wrote: yes, it's finally that time ... after months of hearing us say 'we want to get new baselayout stable asap', we're serious so can people please try out baselayout-1.11.12-r2+ and see if they notice any regressions ? the 'best' tests are simply rebooting and seeing if your system comes up :) Works fine here on a fairly basic ~x86 desktop. Regards, Paul Hi, Using mostly stable system with some (baselayout incl.) testing packages. Migration went OK, except for a warning about missing /etc/init.d/serial. See commented entries for serial in my /etc/inittab file, will check. Otherwise it all works. Rumen smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-dev] mysql-4.1.12 call for testers
Rumen Yotov wrote: Lance Albertson wrote: Robin H. Johnson wrote: Many thanks to Francesco Riosa [EMAIL PROTECTED] for his hard work in dealing with MySQL-4.1. He's joining Gentoo soon as a new developer to help maintain MySQL for the 4.1 and 5.0 series, and hopefully also providing a package for the official MySQL AB binaries. Great work! I used his 4.1.11 ebuild recently and everything seems to work pretty well. I'll see if I can try the 4.1.12 ebuild soon. Upgrades within the 4.1.x series shouldn't be painful right? Cheers, Hi, Also using 4.1.11 (ebuild from Francesco) on x86-stable, works OK. Will try out 4.1.12 soon. Rumen Hi, Just finished emerging mysql-4.1.12 (unmasked first)- all OK, warnings about m4's underquoted defs. Rumen smime.p7s Description: S/MIME Cryptographic Signature
