Re: [gentoo-portage-dev] xattr wrapper for install, bug #465000
Il 29/01/2014 17:33, Anthony G. Basile ha scritto: On 01/27/2014 09:02 AM, viv...@gmail.com wrote: On 01/26/14 23:53, Anthony G. Basile wrote: Hi everyone, A while back, I wrote a python wrapper for install to preserve xattrs. Its installed in LIBDIR/portage/bin/install.py. It is *painfully* slow. For a package like moodle with 16650 .php files, none of which probably need any xattr's set, it takes about 30 mins to install. I rewrote the wrapper in C. Replacing the python wrapper with the C wrapper, the same example reduces from about 30 mins to 2 mins. Mike and I did some back and forth about how best to write it. The latest version is pretty much done at https://bugs.gentoo.org/show_bug.cgi?id=465000#c56 We need to get that integrated into portage. 1) I'm not 100% sure how to do that. 2) We may want to install it at /usr/bin/install-xattr because I'm sure it will be useful for more than just portage. Comments? patch install from coreutils (and then upstream changes) is not an option? they already support selinux contexts anyway install-xattr could be useful and /usr/bin would be a good option IMHO Been there and I even had a patch ready. Upstream answer was '\0'. The only people who engaged the discussion were gentoo devs. Would patching coreutils have been the better approach? Some people might argue install and cp and mv etc should just copy contents to keep these utilities as simple as possible. Although, as you say, install can copy selinux contexts, and cp can copy xattr attributes. So what's the problem with extending installs functionality to include arbitrary xattr attributes? Anyhow, seeing as upstream is uninterested, I prefer this wrapper to maintaining a local patch against coreutils. thanks for answering, so yes the wrapper seem the only sensible thing, good luck, since there are no other questions in 3 days the plan must be perfect ;) on a totally unrelated and ipotetical note kde is discussing a metadata engine that use xattr instead of databases, so this could become important even for desktops
Re: [gentoo-dev] New global use flags: 3dnowext, mmxext, ssse3, sse4_1, avx, avx2
Il 16/12/2013 01:30, Matt Turner ha scritto: On Sun, Dec 15, 2013 at 4:20 PM, Andreas K. Huettel dilfri...@gentoo.org wrote: Am Montag, 16. Dezember 2013, 00:34:13 schrieb Matt Turner: 3dnow: Use the 3DNow! instruction set 3dnowext: Use the Enhanced 3DNow! instruction set mmx: Use the MMX instruction set mmxext: Use the Extended MMX instruction set (intersection of Enhanced 3DNow! and SSE instruction sets) (3dnowext or sse in cpuinfo) sse: Use the SSE instruction set sse2: Use the SSE2 instruction set sse3: Use the SSE3 instruction set (pni in cpuinfo) ssse3: Use the SSSE3 instruction set sse4_1: Use the SSE 4.1 instruction set avx: Use the AVX instruction set avx2: Use the AVX2 instruction set What's the point of these flags? (or to be more precise, are they really justified whenever they are used?) Usually the set of cpu instructions should be controlled by your CFLAGS, and I've been actively patching packages (that do not do manually coded assembly) to make such flags unnecessary. Often they're for enabling assembly code that uses these instruction sets. For pixman, a package that I'm very familiar with, they turn on code using these instruction sets using intrinsics in C. I believe they are justified. If the package simply uses the flag to add an -misa flag to CFLAGS, then we should definitely remove it. If I recall correctly, I have only seen one instance of this. another possible case are packages that do run-time checking of usable instruction set. The use flag could restrict the code to be compiled and installed from the ebuild. Probably never used like this tough
Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors
Il 14/11/2013 05:38, Johann Schmitz ha scritto: long story short having a portage-20130126.tar.bz2 snapshot (before the EAPI 5 switch) greatly simplified the upgrade of an old server on a client. Updating from old portage versions or profiles isn't fun but it basically boils down to Sorry for the snip, but all you said is valid only if: you remember to update portage _before_ an emerge --sync _and_ you are able to do it. basically what I did was to remove the old snapshot find an old snapshot but recent enough to have EAPI5 portage. yes some wget of some distfiles was needed but it made the whole thing possible. Alternatively build a completely new system and then switch is a possibility, nothing deadly but as said a simple copy of a january snapshot would have made some paths simpler cheers, Francesco Riosa
Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors
Il 13/11/2013 20:12, Rich Freeman ha scritto: On Wed, Nov 13, 2013 at 1:58 PM, Francesco R. viv...@gmail.com wrote: long story short having a portage-20130126.tar.bz2 snapshot (before the EAPI 5 switch) greatly simplified the upgrade of an old server on a client. Why not keep a copy on the servers? I mean http://distfiles.gentoo.org/snapshots/ Going back in time with portage is the easy part - it is in CVS. The real problem is all the distfiles themselves, especially things like out-of-tree patch tarballs hosted by devs. Rich Rich, that made me smile, none of my remote machine has cvs since a _very_ long time say 2006. We are speaking of box that have troubles to emerging anything new, plus me and most of the internet barely remember cvs up :) I do highly appreciate the suggestion to keep a @system distfiles snapshot (once a year + portage snapshot would be a bone), but that it's not strictly needed, just a 40MB bzipped files on a public directory and maybe some change to the cron that wipe old files. cheers, Francesco R.
[gentoo-dev] keep a gen 2013 snapshot on mirrors
long story short having a portage-20130126.tar.bz2 snapshot (before the EAPI 5 switch) greatly simplified the upgrade of an old server on a client. Why not keep a copy on the servers? I mean http://distfiles.gentoo.org/snapshots/ thanks, Francesco Riosa
Re: [gentoo-dev] Adding large files to the mirrors?
Il 16/10/2013 11:15, Mike Auty ha scritto: Hiya, [snip] So downloading them manually is a pain (the larger tables aren't in a single zip, they're split amongst 12 files for each table), and the ebuild to do the downloading is already built. I'll include a postinst note indicating that the tables are getting stored twice, and I should even be able to give them an indication of how much space they're wasting. I'll also provide a URL they can visit if they want to download manually instead. The question then becomes, do I split the ebuild into two (giving us three ebuilds for what is otherwise a tiny package) just so some SRCs are mirror-restricted and others aren't? All of that hinges on whether our servers can handle the extra size... Mike 5:) Add a bash script that can download all the files and mention it in postinst. the script will download all the files in current directory and put them in the correct place.
[gentoo-dev] Re: color management in gentoo (kde expecially) proposal for help
re-adding the list, gmail still fool me some times. 2012/2/23 Kai-Uwe Behrmann k...@gmx.de: Hello, glad to read from you. Am 23.02.12, 15:47 +0100 schrieb Francesco Riosa: Hi, my name is Francesco Riosa, I would be interested in a more complete support of the oyranos color managment programs in ::gentoo. Oyranos is intended to be multy platform and in some sense multy os, but in the current incarnation has good support for kde. Joseph works on a GUI front end for Qt to broaden the support. And you are right, KDE's KolorManager is in the best shape. Synnefo is already in a good shape too right? I would also like to see a complete replacement for icc-examin, expecially it's ability to see multiply profiles in the same 3d space, you know, to be able to say those 300€ for a better monitor were a good price ;-) In case there is interest I can apply to return as a developer in gentoo, will respond to emails this week end (25/26 Feb) I read this as a offer to help packaging in gentoo. Typical I work with packagers and like to easen their work. Personally I maintain a openSUSE colour managed software stack as packager myself and be open for suggestions or ideas from Fedora and gladly from gentoo as well. indeed it's an offer for direct or proxyed help gentoo, a pair of ideas that would help gentoo later Often it was mentioned to use autotools or cmake. The next soon to be released rersion of libXcm, one small library, will be autotooled. The conversion is a hard and time consuming part for me, but we hope to get all packages converted. Initially I had some help, which was a good kick off. unlike the rest of the world I prefer cmake over autotools, but if you need help on autotools I suggest to ask this list, there is a lot of expertise here and packagers are going to fix bug in build system anyway, so better soon than later. Gentoo has good support for quite every build system out there, but yes the two you mentioned are preferred. While gentoo is more flexible than binary distro, there is one thing that help them a lot, do releases (possibly often), they need a fixed point to start with, having only a git repository where to pull mean to be a second class cityzen. In case you want to maintain gentoo specific files inside the upstream packages and keep them up to date, that is possible. I do so with a rpm and deb make target. Not sure if that makes sense for gentoo. I'm quite sure it's not needed, to the opposite, generally those files go out of sync easily and are better mantained by gentoo devs. The build scripts and a README are linked here: http://www.oyranos.org/wiki/index.php?title=Oyranos/git icc_examin-build-local.sh can be adapted. As one nice step it would be great, if you can name one or more command lines to get gentoo ready for building Oyranos and the other parts of the software stack. So people could test Oyranos from git easily inside gentoo. I've the complete oyranos software stack building well in gentoo at the moment (using git) :-) I'm _not_ offering support for digikam, for which I develop, because I would like to mantain a two step verification process (developer/packager) Regards, Francesco kind regards Kai-Uwe -- www.oyranos.org oy#open...@freenode.org
[gentoo-dev] LANG=en_GB.UTF-8 by default
as subject says could gentoo change the policy and set an UTF-8 environment by default? http://www.gentoo.org/doc/en/utf-8.xml how to do it very well but having it already set could have the following two advantages: 1) well utf-8 is everywhere, even the linux weekly newsletter has it in 2012 2) the user need to change, not to create a /etc/env.d/XX-lc, creating a standard place where every gentoo install has this settings. contra? P.S. would be nice to have a wd_WD.UTF-8 with WD standing for world, just a country is so 1900
Re: [gentoo-dev] Free Gentoo
On Saturday 21 January 2012 21:56:22 Markos Chandras wrote: On 01/21/2012 06:01 PM, . wrote: Hello there! Is there a chance that Gentoo may become a free distro? I'm so unhappy with the fact that there are some non-free packages in the main tree. The main goal of the GNU project was to replace the proprietary Unix system. You are actually ruining this goal. I'm also dissatisfied with the name of the distro. Linux is the kernel not the whole system. Cheers. Please guys stop replying to this email. It is clearly a spam or a flamebait. Try to avoid (unnecessary) flames :) well, while the original mail was disturbing most of the reply have been fun to read (some even instructive), so may be this time it was worth an exception and feeding the troll :-)
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/aria2: aria2-1.12.0.ebuild ChangeLog
2011/7/3 Paul Arthur junk+use...@flowerysong.com:
On 2011-07-03, Jonathan Callen a...@gentoo.org wrote:
Peter Volkov wrote:
rm -rf ${D}/usr/share/doc/aria2
|| die
`rm -f` never fails -- if the target does not exist, then rm simply returns
true. (The only reason it would fail that I can think of is /bin/rm not
existing, in which case you have a bigger problem.)
To test, try `rm -f /nonexistant/file; echo $?`
jill-zeke /var/tmp $ rm -f testfile
rm: cannot remove `testfile': Operation not permitted
jill-zeke /var/tmp $ echo $?
1
rm -f chuck norris
rm: cannot remove `Chuck Norris': Operation not contemplated
echo $?
42
jill-zeke /var/tmp $ rm -rf testdir
rm: cannot remove `testdir/test': Permission denied
jill-zeke /var/tmp $ echo $?
1
--
Suddenly, the door crashed open. Outside, purple prose rained down
like a bad metaphor.
--SteveD on RPGnet
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
2011/6/11 Mike Frysinger vap...@gentoo.org: On Saturday, June 11, 2011 16:24:00 Ciaran McCreesh wrote: On Sat, 11 Jun 2011 15:58:43 -0400 Mike Frysinger wrote: So, effectively the QA team lead can appoint the people who elect him. I'm not at all implying that Diego would abuse his position, but still I think that this is not a sane situation. it does seem trivial to remove people who disagree with you and thus cement an echo chamber Are you talking in a hypothetical future situation, or has this already happened? If so, can you point to an example of where Diego's been removing people for disagreeing with him, rather than for disagreeing with the Council? how is disagreeing with a Council decision valid grounds either ? punting people because they disagree with any group isn't really valid. -mike a user POV: If you are in the role of enforcing decision of the council and with disagreeing you mean acting versus their decision yes it's a very much valid ground. In real life if you are a policeman and disagree with politicians you must anyway enforce their laws or you're jailed. Anyway maybe the whole QA should resign (you too Diego) and election done again, seem the more correct thing at this point
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
2011/2/22 Rich Freeman ri...@gentoo.org: On Tue, Feb 22, 2011 at 3:55 AM, Ulrich Mueller u...@gentoo.org wrote: On Tue, 22 Feb 2011, Mike Frysinger wrote: that might disallow it for binaries, but it doesnt disallow it from being used in ebuilds. same situation as binary kernel drivers -- make it the end user's problem. Why should we impose such trouble on our users, when there's a (IMHO superior) replacement? Build gnuplot with USE=cairo and you can get PDF output with the pdfcairo terminal. Even with proper utf-8 support, which was always broken with pdflib. +1 to both - if a free alternative works then we should always prefer it. However, at worst linking license issues should just force us to set RESTRICT=bindist or the like (and mirror as well if we can't distribute the source). As long as users don't redistribute software they don't need to worry about licenses if the person sending it to them had the license to distribute it in the first place. Rich Last time (many moons ago) I've checked cairo did not generated pdf it did generated raster images and wrapped them in a thin pdf layer. pdflib is generating vector pdf which is a different thing.
Re: [gentoo-dev] Re: glibc-2.13 news item?
2011/2/9 Ryan Hill dirtye...@gentoo.org
On Tue, 08 Feb 2011 09:52:55 +0100
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
It seems that with glibc-2.13 there are some serious compatibility
issues. There are good warnings on the planet
(http://psykil.livejournal.com/340806.html), but not every ~arch user
reads the planet, so how about creating news item with detailed
instructions how to ensure smooth glibc-2.13 update or recover a hosed
system?
We've blocked prelink in the ebuild so if a user is able to sync they're
either not going to be affected or already have been.
Also I've the strong suspect that these changes:
* New optimized string functions for x86-64: strnlen (SSE2),
strcasecmp (SSE2, SSSE3, SSE4.2), strncasecmp (SSE2, SSSE3, SSE4.2)
Implemented by Ulrich Drepper.
Interact badly with strong optimizations like these
CFLAGS=-O2 -march=core2 -pipe
CFLAGS=${CFLAGS} -msse4.1 --param l1-cache-size=32 --param
l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=core2 # native
CFLAGS=${CFLAGS} -fgcse-after-reload -fpredictive-commoning
-ftree-vectorize -funswitch-loops # O3 - -finline-functions -fipa-cp-clone
CFLAGS=${CFLAGS} -fgraphite-identity -floop-block -floop-interchange
-floop-strip-mine # graphite co (-fira-loop-pressure no good amd64)
using gcc-4.5.2
Since the upgrade I do get portage emerging text files .sh, .conf and such
as file of the exact same size but filled of \0, luckily most upgrade fails.
cpu is:
model name : Intel(R) Core(TM)2 Quad CPUQ8400 @ 2.66GHz
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dts
tpr_shadow vnmi flexpriority
I've masked glibc-2.13, also I'm not filing a bug, because of non-usual
CFLAGS and because I'm not totally sure is glibc related.
Re: [gentoo-dev] Re: glibc-2.13 news item?
2011/2/9 Michał Górny mgo...@gentoo.org On Wed, 9 Feb 2011 13:32:36 +0100 Francesco R viv...@gmail.com wrote: Since the upgrade I do get portage emerging text files .sh, .conf and such as file of the exact same size but filled of \0, luckily most upgrade fails. I've seen similar issue in bug #353907 [1] but there they blame coreutils and/or btrfs. Maybe you should take a look. [1] http://bugs.gentoo.org/show_bug.cgi?id=353907 thanks Michał Górny, I had portage tmpdir on btrfs. My fault then, please ignore the noise in the my previous message. Best regards, Francesco R.
Re: [gentoo-dev] Re: Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable
2010/12/13 Ryan Hill dirtye...@gentoo.org
On Sun, 12 Dec 2010 09:01:13 -0400
Sergio D. Rodríguez Inclan srinc...@gmail.com wrote:
El 12/12/2010 02:46 a.m., Ryan Hill escribió:
I think the fewer sources of magic USE flags the better. Maybe we
could
document how to figure out what instruction sets a processor supports
in the
handbook instead.
A good manual would be greatly appreciated :)
I wrote a guide a couple weeks ago that might be a good starting point.
http://en.gentoo-wiki.com/wiki/Hardware_CFLAGS
if I read correctly the article on the wiki it does circa what the script
reported below does.
would be possible to adopt something similar for automatic C*FLAGS selection
if someone step in willing to take the pain to mantain it.
#!/usr/bin/python
# Copyright 2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# Author: Francesco Riosa
# extrapolated from http://en.gentoo-wiki.com/wiki/Hardware_CFLAGS, errors
are mine
# kate: encoding utf-8; eol unix
# kate: indent-width 4; mixedindent off; replace-tabs on;
# kate: remove-trailing-space on; space-indent on
# echo int main() { return 0; } | gcc -march=native -v -E - 21 | grep
march
# echo int main() { return 0; } | gcc -march=core2 -v -Q -x c - 21
example output:
./hw-cflags.py
extrapolating flags for gcc-4.4.5
useful flags: -march=core2 -msse4.1 --param l1-cache-size=32 --param
l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=generic
redundant:-mcx16 -msahf
extrapolating flags for gcc-4.5.1
useful flags: -march=core2 -msse4.1 --param l1-cache-size=32 --param
l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=core2
redundant:-mcx16 -msahf
import os
import time
import fnmatch
from subprocess import Popen, PIPE
GCC_PATH = '/usr/bin/'
GCC_LIST = fnmatch.filter(os.listdir(GCC_PATH), 'gcc-[0-9].*')
GCC_LIST.sort()
def extract_flags(gcccmd, header):
# get output from gcc
buf = ''
devnul = open('/dev/null', 'w')
p = Popen(gcccmd, stdin=PIPE, stdout=devnul, stderr=PIPE)
p.stdin.write(int main() { return 0; })
p.stdin.close()
while p.poll() is None:
t = p.stderr.read()
buf = buf%s % t
time.sleep(0.01)
p.stderr.close()
devnul.close()
# parse it
flags = []
add = False
for line in buf.split('\n'):
if line.startswith(header):
add = True
flags += line.strip().split(' ')
continue
if add:
if line.startswith(' '):
flags += line.strip().split(' ')
else:
break
# extract flags we are interested in
t = []
march = ''
mtune = '-mtune=generic'
for i in xrange(len(flags)):
if flags[i].startswith('-m'):
if flags[i].startswith('-mtune'):
mtune = flags[i]
elif flags[i].startswith('-march'):
march = flags[i]
else:
t.append(flags[i])
elif flags[i] == '--param':
t.append(%s %s % (flags[i], flags[i+1]))
flags = t
return march, mtune, flags
for gcc in GCC_LIST:
print extrapolating flags for %s % gcc
gcccmd = [ GCC_PATH + gcc, '-march=native', '-v', '-E', '-', ]
header='COLLECT_GCC_OPTIONS'
march, mtune, flags_native = extract_flags(gcccmd, header)
gcccmd = [ GCC_PATH + gcc, march, '-v', '-Q', '-x', 'c', '-', ]
header='options enabled:'
t, t, flags_enabled = extract_flags(gcccmd, header)
redundant_flags = []
useful_flags = []
for x in flags_native:
if x in flags_enabled:
redundant_flags.append(x)
else:
useful_flags.append(x)
if gcc gcc-4.5.0:
mtune = '-mtune=generic'
print useful flags: %s %s %s % (march, .join(useful_flags),
mtune)
print redundant:%s % .join(redundant_flags)
print
Re: [gentoo-dev] Re: use_echo() as a universal '?:' operator-like function
2010/9/11 Paweł Hajdan, Jr. phajdan...@gentoo.org
On 9/11/10 11:03 AM, Jonathan Callen wrote:
Just as a proof-of-concept, here's one implementation of such a
function, allowing for an arbitrary number of arguments:
use_echo() {
while [[ $# -gt 1 ]]; do
if use $1; then
echo $2
return
fi
shift 2
done
[[ $# -eq 1 ]] echo $1
}
Looks good to me. If it doesn't get included in any eclass, I will just
paste it to the chromium ebuilds. :)
Paweł
I don't count but sometimes I do still read ebuilds, the function proposed
look a bit^W unreadable to me,
may I suggest to aggregate use and echo, separating them with a comma ,.
The first element with an empty use always echo and return.
See implementation and example below
use_case() {
local u
local c
while [[ $# -gt 0 ]]
do
u=${1%%,*}
c=${1#*,}
if [[ ${u} == ]] || use $u
then
echo ${c}
break
fi
shift
done
}
echo $(use_case useA,echoA useB,echoB ,echoC)
Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
2010/8/10 Brian Harring ferri...@gmail.com
On Mon, Aug 09, 2010 at 07:05:11PM -0400, Mike Frysinger wrote:
On Mon, Aug 9, 2010 at 7:03 PM, Markos Chandras wrote:
On Sat, Aug 07, 2010 at 10:16:24PM -0400, Mike Frysinger wrote:
obviously you only mean linux x86/amd64 dev profiles. i dont have a
strong
opinion on that small subset in either direction.
So do you agree to make this linker option default to linux x86/amd64
dev/
profiles?
add them or dont add them, i dont have a [...] opinion [...] in
either direction. if put to a vote, i'd abstain.
Possibly a stupid question, but any reason we've not looked at
injecting something that has lower actual affect but can still be used
for a canary? I'm thinking of --build-id specifically...
~brian
I don't know how --hash-style=gnu is used to check for LDFLAGS, so this may
be OT.
On my personal and _breakable_ desktop I do use
LDFLAGS=${LDFLAGS} -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
-Wl,--sort-common -Wl,--build-id
in make.conf.
Would this two liners tell me which package who install binaries in /usr/bin
does not respect ldflags?
# for i in /usr/bin/* ; do eu-unstrip -n -e $i ; done build-id.txt
# qfile $(grep '0x[0-9]*+0x[0-9]* - ' build-id.txt | awk '{ print $3 }')
On a side note, I've noticed that build-id change at every re-compilation of
the package, even if nothing changed in the system, since it's supposed to
be a 160-bit SHA1 hash on the normative parts of the output contents
should it be the same if the package is compiled on the same system with no
changes?
Output of the two liners for this system:
sys-apps/turbotail (/usr/bin/turbotail)
app-arch/rzip (/usr/bin/runzip)
app-arch/rzip (/usr/bin/rzip)
dev-lang/go (/usr/bin/6a)
dev-lang/go (/usr/bin/6cov)
dev-lang/go (/usr/bin/6l)
dev-lang/go (/usr/bin/6nm)
dev-lang/xharbour (/usr/bin/pprun)
dev-lang/xharbour (/usr/bin/hbmake)
dev-lang/xharbour (/usr/bin/hbdict)
dev-lang/xharbour (/usr/bin/xbscript)
dev-lang/perl (/usr/bin/perl)
dev-lang/perl (/usr/bin/perl5.12.1)
dev-lang/R (/usr/bin/Rscript)
x11-misc/xcb (/usr/bin/xcb)
dev-libs/dietlibc (/usr/bin/dnsd)
dev-libs/dietlibc (/usr/bin/elftrunc)
app-text/o3read (/usr/bin/utf8tolatin1)
app-accessibility/festival (/usr/bin/audsp)
app-accessibility/espeak (/usr/bin/espeak)
sys-devel/gcc (/usr/bin/x86_64-pc-linux-gnu-gcjh-4.4.4)
sys-devel/gcc (/usr/bin/gcjh-4.4.4)
sys-devel/llvm-gcc (/usr/bin/llvm-gcov)
sys-devel/qconf (/usr/bin/qconf)
www-plugins/lightspark (/usr/bin/lightspark)
Re: [gentoo-dev] New eclass: autotools-utils.eclass
2010/7/19 Ciaran McCreesh ciaran.mccre...@googlemail.com
On Mon, 19 Jul 2010 18:23:36 +0200
Maciej Mrozowski reave...@gmail.com wrote:
status quo should be challenged occasionally.
Fixed autotools-utils.eclass, kde4-functions.eclass, virtuoso.eclass
case ${EAPI:-0} in
2|3|4) ;;
- *)
DEPEND=EAPI-TOO-OLD ;;
+ *) die EAPI=${EAPI} is not
supported ;;
esac
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/kde4-functions.eclass?r1=1.18r2=1.19;
This was changed for a reason. Did you find out what that reason was
before reverting it?
the comment for that commit is:
Update kde4 eclasses from kde-testing. Mostly minor sinc. Introduce support
for stable koffice2
So, since the reason it's not mentioned, the reason is not existent.
/could_not_resist
--
Ciaran McCreesh
Re: [gentoo-dev] showing file diffs as root
why not make a temporary copy of the files with appropriate permission, send a message the application the user originally opened to diff the files, then apply the user modified file and cleanup the $tmpdir? This would leave the user the possibility to choose whatever application she want to do the merge, which is a big plus. 2010/5/30 Christopher Harvey ch...@basementcode.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello gentoo-dev, I'm working on an app for GSoC that needs to show a diff of two files to the user. Right now I've just been calling meld from the python os.system call. I tried running my application as root to show diffs of system files that belong to root. I got this error: Traceback (most recent call last): File /usr/bin/meld, line 90, in module meldapp.main() File /usr/lib/meld/meldapp.py, line 982, in main app = MeldApp() File /usr/lib/meld/meldapp.py, line 562, in __init__ self.prefs = MeldPreferences() File /usr/lib/meld/meldapp.py, line 435, in __init__ super(MeldPreferences, self).__init__(/apps/meld, self.defaults) File /usr/lib/meld/prefs.py, line 92, in __init__ self._gconf.add_dir(rootkey, gconf.CLIENT_PRELOAD_NONE) glib.GError: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details - 1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.) I haven't looked into why this is happening very much because calling os.system(meld file1 file2 ) in python is putting up so many red flags in my head it's not funny. If anybody could tell me the proper gentoo/linux/python way to present a root level diff to a user running a program through su or sudo I'd really appreciate the help. thanks, Chris - -- My GnuPGP key at: www.basementcode.com/public_key.txt -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMAn1RAAoJEDqfZIFeqFH7brQH/RqeUmCHuopa+SufkzNNT4Ys 7IJArQCik3vBLJLpeTM3gf3NL3KMWjyzlxxQ8L74KAhItPuA3cVUQKQrSnOCBiDa y6yfDttBbOptOtcUYn7WkXQDm+BYEdpviMfjtym5ZF2nlGOMzZMxknP4ywXnhLZN q2169haoG0p1g0D11q2H9B4Vk++PUil7VLgzOfAOcLQ9YpFDkXIdxy5FRaRkx8K4 lcPfmzFha8OkdBpsXPJdhtY5pmzOEf+ziprDlyD7eCkE1xAkRNhjsNtEz9CTXeLh l46/tUCZTx+aX9ABW0m13Ache8jGN36+TvsRzRKfzqaMJ0z/wEOeESooPFYHnl0= =FxxJ -END PGP SIGNATURE-
Re: [gentoo-dev] About libpng-1.4 handling
2010/5/11 Graham Murray gra...@gmurray.org.uk George Prowse george.pro...@gmail.com writes: I have run revdep-rebuild about 30 times and I still can't fix it. revdep-rebuild does not fix it and libpng needs to have some serious action before it goes stable because I booted into, basically a completely broken machine because I had to stop a large upgrade on the previous emerge (~300 packages) in the middle. Are the failures during a gtk-doc scan? If so then try unmerging the affected package and then manually re-emerging it. For me not, possibly it's a problem with la files, steps done by me follow: revdep-rebuild -- --keep-going lafilefixer --justfixit # this does not work `revdep-rebuild -- --keep-going` export PKGLIST=$(qfile --slots --quiet --nocolor $(grep -l png12 /usr/lib64/*.la)) # PKGLIST=gnome-base/libgnomecanvas:0 gnome-base/libbonoboui:0 gnome-base/libgnomeui:0 gnome-base/gnome-keyring:0 # gnome-base/libglade:2.0 dev-cpp/gtkmm:2.4 dev-cpp/gtkmm:2.4 gnome-extra/evolution-data-server:0 sudo rm $(grep -l png12 /usr/lib64/*.la) gnome-extra/evolution-data-server:0 sudo emerge -1av $PKGLIST revdep-rebuild -- --keep-going # should do
Re: [gentoo-dev] Re: Stabilization of Python 3.1
On Sun, Sep 20, 2009 at 2:42 AM, Alistair Bush ali_b...@gentoo.org wrote: Someone here want people install paludis? because when I've switched to python 3.0 just out of curiosity, it broke totally that python written package manager who is portage. So another package manager was needed to re-install a sane portage. No it wasn't. [1] You just didn't know that ( which is completely understandable ). Just as you must not have understood the implications of emerge -C python:2.6. I don't want to be mean but would you like to enlighten us as to how you managed to unemerge python:2.6 while using python3 when portage didn't work with python3. [1] http://tinderbox.dev.gentoo.org/default-linux/amd64/dev-lang/python-2.6.2- r1.tbz2 I did not unmerge python-3, I was in hard multitasking mode so I could not reconstruct how it broken so badly, also tinderbox packages work better if the CFLAGS used are the same, which is not always true. Still, do you really want to have it in tree as stable? Really? Yes really. what said in the previous message which you snipped, eselect python should forget about =python-3 is still valid IMHO
Re: [gentoo-dev] Re: Stabilization of Python 3.1
On Sun, Sep 20, 2009 at 1:31 AM, Ryan Hill dirtye...@gentoo.org wrote: On Sun, 20 Sep 2009 08:55:00 +1200 Alistair Bush ali_b...@gentoo.org wrote: Stabilization of Python 3.1.* will be requested at the beginning of november. There was a suggestion to create a news item which would inform users that temporarily they shouldn't switch to Python 3 as their main interpreter. Python ebuilds don't automatically activate Python 3, so I'm not sure if the news item is required. What is your opinion about it? Stablise. And to pacify all the cry babies out there could we update portage tools to call /usr/bin/python2.6 directly? (yes I realise this will break, but at least it is a suggestion) Or how about we (remove python3.1 from the menu)/(stick a big fat warning message)/(do something else) on eselect-python. Or create a system-python link that all gentoo core apps use instead of /usr/bin/python (longer term solution?). [rant]Hell maybe we could even start using those slot dep thingy me bobbies to depend only a slot. So ppl don't have python3.1 unless something depends on it. Does portage have support for slots in world? [/rant] Or we could, say, leave it ~arch. Why do you need python-3 in stable? Someone here want people install paludis? because when I've switched to python 3.0 just out of curiosity, it broke totally that python written package manager who is portage. So another package manager was needed to re-install a sane portage. Still, do you really want to have it in tree as stable? Really? Than at least please update eselect python in such a way it could not in any case be used to choose a python version = 3
[gentoo-dev] mount portage from squashfs
Proposal, create snapshots of portage as squashfs iso, to be used in place of /usr/portage directory. prior art: see #1 Already working here: one central server which keep the portage full tree and that after a sync create portage.sqsh a squashfs 4.0 iso. Advantages are mainly: - cleaner root directory (ext4: du -sh /usr/portage ~= 600M | find /g/portage | wc -l ~= 13) - faster `emerge --sync` with fast connections - faster `emerge -uDpvN world` - less cpu/disk load on the server (if not serving from memory) Disadvantages - need to mount portage, or to use autofs - need kernel = 2.6.30 - bigger rsync transfer size (?= 2x) #2 - bigger initial transfer size, lzma snapshot currently weight 30.8M, portage.sqsh 45M How it's done here: Currently on the dispatcher the following run after every emerge --sync: mksquashfs /usr/portage /srv/portage.sqsh \ -noappend -no-exports -no-recovery -force-uid 250 -force-gid 250 The clients run from cron the following: umount /g/portage 2/dev/null \ ; cp /srv/server/portage.sqsh /var/tmp/portage.sqsh \ mount /usr/portage /etc/fstab: /srv/server/portage.sqsh /usr/portage squashfs loop,ro,noauto 1 1 some real data: stats for a portage sync, one day Number of files: 136429 Number of files transferred: 326 Total file size: 180345216 bytes Total transferred file size: 1976658 bytes Literal data: 1976658 bytes Matched data: 0 bytes File list size: 3377038 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 47533 Total bytes received: 4120255 sent 47533 bytes received 4120255 bytes 124411.58 bytes/sec total size is 180345216 speedup is 43.27 stats for a portage.sqsh sync, one day Number of files: 1 Number of files transferred: 1 Total file size: 46985216 bytes Total transferred file size: 46985216 bytes Literal data: 8430976 bytes Matched data: 38554240 bytes File list size: 27 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 48096 Total bytes received: 8454837 sent 48096 bytes received 8454837 bytes 5668622.00 bytes/sec total size is 46985216 speedup is 5.53 #1 http://forums.gentoo.org/viewtopic-p-2218914.html http://www.mail-archive.com/gentoo-...@gentoo.org/msg05240.html #2 May be mitigated by mksquashfs '--sort' option, to be tested - francesco (vivo)
Re: [gentoo-dev] mount portage from squashfs
On Wed, Aug 12, 2009 at 10:51 PM, Robin H. Johnson robb...@gentoo.orgwrote: On Wed, Aug 12, 2009 at 05:17:55PM +0200, Francesco R wrote: Proposal, create snapshots of portage as squashfs iso, to be used in place of /usr/portage directory. To all of these suggestions, I'd like to point out that if you're willing to pay the same cost in administration (maintaining a separate filesystem for /usr/portage), then you can have EVERYTHING in the advantages list, and none of the things in the disadvantages list by simply using a small reiserfs space for /usr/portage, with tail-packing enabled. well squashfs has a pair of advantages over reiserfs, duplicate file detection, compression and a bright future. For the rsync.g.o main rotation servers, we actually do that, just RAM-backed to serve files as fast as possible without hitting disk. only possibility to cope with the load they have I think When you removed bandwidth limitations and disk limitations on the client side, I believe the record time for a emerge --sync that was 24 hours out of date was somewhere around 23 seconds. 23 seconds are ... a lot without bandwidth and disk limitation, disk time for 50 MB is 1 sec (or even much less), and it transfer the whole iso in that time If you really wanted to get the rsync transfer size down, see what you can do about the 'file list size' section, which is eating up a lot of the download gains with the classical rsync:// sync. IMHKnowledge the only way to do this is to have one index file (or files) the file should contain a triple ctime, status and file name (ordered by ctime possibly descending), and provide a cheap way to retrieve the list of files changed in a certain amount of time, status would be needed mainly for deleted files, but it can be modified or added too. Portage already has timestamp in /metadata so that skew of the client clock are not a problem, skew on the server would be. As a side advantage this could be served by an http server, still having rsync as an option. Currently rsync already use the option --whole-file and does only time/size check, if those differ, it downloat the full (little) file. Right ? This would be interesting too, but what happen if the timestamp in the client is too old or absent? fallback to rsync? How much time or how much size would the index file be allowed to grow? P.S. as a http client curl would be more useful than wget because it permit to download more file in one session
Re: [gentoo-dev] my apologies for the mess with this release of MySQL 5.0.16
Problem fixed, going to readd ~amd64 now, sync again in 30 min. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] my apologies for the mess with this release of MySQL 5.0.16
my apologies for the mess with this release of MySQL 5.0.16 and for the
one will come with the dev-db/mysql-4.1.15-r1 ebuild
Here is the relevant list of bugs opened (and closed) as a consequence
of the new ebuild.
[Bug 113451] mysql-4.1.15 re-keyworded as -* with no note in changelog
as to why
[Bug 113440] typo in mysql-5.0.16-r2 init script
[Bug 113356] /etc/init.d/mysql script fails to start server in
mysql-5.0.16
[Bug 113352] mysql-5.0.16-r1 does not
create /usr/lib{64}/libmysqlclient.so.15 symlink
[Bug 113334] mysql MD5 mysql-extras-20050920.tar.bz2 VERIFY FAILED! (old
ebuild has correct value)
If you installed 5.0.16, the 1st and don't want to re-emerge it, follow
these steps:
(may need to adjust the path accordingly with ARCH and personal
settings)
# emerge --sync
# cp /usr/portage/dev-db/mysql/files/mysql-slot.rc6 /etc/init.d/mysql
# chmod +x /etc/init.d/mysql
# cd /usr/lib{64}
# for i in libmysqlclient.so libmysqlclient_r.so ; do \
for j in .15 .15.0 .15.0.0 ; do \
echo ln -s /usr/lib/${i}.15.0.0 ${i}${j} \
; done \
; done
# chown -R mysql:mysql /var/run/mysqld/
Regards,
Francesco R.
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] [test/suggestion request] MySQL rc scripts
--- ChangeLog extract
19 Nov 2005; Francesco Riosa [EMAIL PROTECTED] +files/mysql-slot.conf.d,
+files/mysql-slot.rc6:
These two are born for slotted MySQL, however they work as is on normal
MySQL
installations too. (require my_print_defaults)
Features added or changed
- Not using mysqld_safe anymore
- preparsing of my.cnf file, all options outed at startup
- (possible to) override my.cnf option from conf.d/mysql
- Start multiple server with different config files
- using new svc --nicelevel option, nice level may be specified on per
server basis
- stronger error handling
- some new warnings
- slotted mysql management
--- ChangeLog extract
Since these script have some improvements and since they are compatible
with the current stable, probably I'll bump the stable MySQL version to
use them (no, not tomorrow but not so far in time).
However my knowledge of sys-apps/baselayout is not so deep, so could
someone take a look at the two ?
Things that I'm worried about:
- They use a good quantity of bash magic, how much it's compatible with
every gentoo supported system?
- Will be future changes of baselayout be compatible with ?
- how much is it compatible with *past* release of baselayout ?
- and with sys-apps/*layout?
- the rc-script force start-stop-daemon to start multiple daemons from
the same script, how is it good/bad, thoughts ?
- the code is readable or an effort should be done to make it simplyer ?
please add your own here
provided you have dev-db/mysql already emerged testing is as easy as:
# mv /etc/init.d/mysql /etc/init.d/mysql~
# /etc/init.d/mysql stop
# cp ${PORTDIR}/dev-db/mysql/files/mysql-slot.conf.d /etc/conf.d/mysql
# cp ${PORTDIR}/dev-db/mysql/files/mysql-slot.rc6 /etc/init.d/mysql
# chmod +x /etc/init.d/mysql
# /etc/init.d/mysql start
TIA,
Francesco Riosa
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for media-video/realone, media-video/realvideo-codecs and old versions of realplayer
Alle 20:16, mercoledì 16 novembre 2005, Mike Frysinger el ga butta: |On Wed, Nov 16, 2005 at 07:48:56PM +0100, Diego 'Flameeyes' Petten?? wrote: | On Wednesday 16 November 2005 19:34, Julien Allanos (dju`) wrote: | So, what are the substitutes? | | win32codecs and realplayer-10.0.0.6 ? | |you asking or telling ? didnt you learn anything in elementary | school ? -mike noone here speak english at elementary school, I suggest you to follow one course here to learn about it. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Slotted MySQL ; mysql-herd
There are these ebuilds in cvs from few minutes: mysql-4.0.26-r30.ebuild mysql-4.1.15-r30.ebuild mysql-5.0.15-r30.ebuild these ones contain a starting point ebuild to make a slotted mysql installation. The motivations that push this choice are both developement and user side. Making a long story short there are two points: We want to support every major.minor version of mysql, having slotted mysql make life easyer to developers in testing all supported versions. User side, slotted mysql server and client make possible a smooter upgrade, keeping downtimes to the minimum (a stop and start in the best case). ; Further these days I was wondering to populate a bit more mysql-herd of developers and packages, also to cover my personal lack of knowledge on some languages (deeper explanation in private mails ;-) So if you're interested in join the herd, let me know (sorry non-dev, I cannot mentor these days). I'm listed on devaway from 2005-10-01 to 2005-10-10, will answer when I'll come back. Cheers, Francesco Riosa -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Unmasking dev-db/mysql-5
Alle 16:06, lunedì 17 ottobre 2005, Francesco R. ha scritto: mysql-4.1.14 has been added to the tree on 29 Aug 2005, should be time to stabilize the 4.1 branch of mysql. MySQL 4.1 is (keyworded) stable for amd64 and x86 . Going through step 2 now, unmasking MySQL 5.0 . As a security measure ARCHs that does not have a stable 4.1 have been removed from keywords . Best regards, Francesco Riosa -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla Bug #109301 dev-db/mysql-4.1.14 stable request.
Alle 16:06, lunedì 17 ottobre 2005, Francesco R. ha scritto: mysql-4.1.14 has been added to the tree on 29 Aug 2005, should be time to stabilize the 4.1 branch of mysql. has been reported on GWN, thanks gui [snip] If no one is versus I'll stabilize 4.1.14 for x86 and amd64 tomorrow (with dev-perl/DBD-mysql-2.9007), then mysql-5.0 will be unmasked. Little step back here, I'm working with x86 and amd64 ARCH teams to do a better testing before. Anyway it should be still stabilized soon. [snip] -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Bugzilla Bug #109301 dev-db/mysql-4.1.14 stable request.
mysql-4.1.14 has been added to the tree on 29 Aug 2005, should be time to stabilize the 4.1 branch of mysql. ARCH teams, robbat2, php-herd, thoughts ? If no one is versus I'll stabilize 4.1.14 for x86 and amd64 tomorrow (with dev-perl/DBD-mysql-2.9007), then mysql-5.0 will be unmasked. Furter note to the sh ARCH, my apologies, I've removed your keyword from mysql-4.0.[456]* ebuilds, repoman commit gived me a badindev for dev-perl/DBI. Best regards, Francesco Riosa -- gentoo-dev@gentoo.org mailing list
[gentoo-portage-dev] exclude cache from sync, was:Cache rewrite backport
Elaborating on the previous subject an idea come in mind, avoid the $PORTDIR/metadata/cache sync, It's 80 MB, 2 files So I've tryed the first python patch of my life, obviously it's also the first portage one (subliminal message, take the result with care and check it yourself) how? the patch add the option --withregen, the to exclude /metadata/cache from the sync and to issue a regen of the cache before to update the metadata. calling emerge --withregen --sync do the work. The following test has run with a dual opteron as rsync server and a Athlon XP 2500+ with an old and slow disk, cabled with gigabit ethernet. The rsync is forced removing the timestamp. The portage tree has been synced _before_ starting the bench, so the overhead of rsync is really reduced at the bare minimum, check the differences between the files on server and client. The surprising result is that recreating the cache is faster than rsync it. (real time) ===|=== ===|=== 1st try, portage [2.0.53_rc5] + cac|1st try, portage [2.0.53_rc5] + cac ===|=== sync with cache and _no_ regen |sync without cache and regen after |Regenerating cache entries... |done regen! | real6m23.727s |real4m14.837s user0m12.373s |user0m18.681s sys 0m13.849s |sys 0m7.744s ===|=== ===|=== 2nd try, portage [2.0.53_rc5] + cac|2nd try, portage [2.0.53_rc5] + cac ===|=== sync with cache and _no_ regen |sync without cache and regen after |Regenerating cache entries... |done regen! | real6m53.649s |real2m40.794s user0m12.361s |user0m18.361s sys 0m14.117s |sys 0m6.800s ===|=== ===|=== 3rd try, portage [2.0.53_rc5] + cac|3rd try, portage [2.0.53_rc5] + cac ===|=== sync with cache and _no_ regen |sync without cache and regen after |Regenerating cache entries... |done regen! | real6m46.973s |real4m19.261s user0m12.605s |user0m18.593s sys 0m13.733s |sys 0m7.648s | To run the test yourself (please with a local rsync mirror) mkdir tmptest ; cdtmptest # download the patch here bunzip2 emerge.patch.bz2 cp /usr/bin/emerge . patch -i emerge.patch emerge grep -B1000 ###end test with emerge.patch test_emerge # modify test_emerge for your needs . test_emerge == (/please with a local rsync mirror) Please check the correctness of what the patch do before test it. Cheers emerge.patch.bz2 Description: BZip2 compressed data
Re: [gentoo-dev] lights on internals
Brian Harring wrote:
On Sun, Oct 02, 2005 at 11:07:13PM +0200, Francesco R wrote:
The ready to cut ebuild at the bottom print it's environment (variable
and functions) to a bunch of files into /var/tmp/fakebuild/.
May be useful for who want to have a look at what and when is
avaible during the various emerge phases (but not limited to).
print_env() {
local fakebuild_output_dir=/var/tmp/fakebuild
mkdir -p ${fakebuild_output_dir} || die
[[ -z ${fakebuild_progr} ]] fakebuild_progr=100
fakebuild_progr=$(( $fakebuild_progr +1 ))
export fakebuild_progr
local fakebuild_ext=${1}.${fakebuild_progr}
# not sorting, break multiline vars
einfo ${fakebuild_output_dir}/env_${fakebuild_ext}
env \
${fakebuild_output_dir}/env_${fakebuild_ext}
# Remove egrep and sort to see the source of every fx
einfo ${fakebuild_output_dir}/fxlist_${fakebuild_ext}
typeset \
| egrep '^\b.* \(\)' \
| sort \
${fakebuild_output_dir}/fxlist_${fakebuild_ext}
}
This won't work as you expect. Env is a binary, it only gets
the exported env.
Got the point (maybe), typeset is a Bash built-in.
The first part of the typeset output command give the variable list
*and* it's different from the output of env binary.
The output is different in two ways, first the vars are differently
formatted, missing apices ' for example.
env also is missing all .bashrc defined vars (speaking of a normal
environment not of a portage/emerge one).
== the env command should be replaced by
typeset tmpfile
tmpfile | grep -B1 $(egrep ^\b.* \(\) tmpfile | head -n 1) |
head -n '-1'
(basically the output of typeset cutted at first function)
Elaborate on the what and when bit also, since the env that's dumped
to ebuild.sh varies depending on a lot of things.
~harring
The environment is changing between the various predefined functions and
in the global scope of an ebuild, at the moment only for vars, not for
functions.
example of variable vars are:
SANDBOX_*
PORTAGE_RESTRICT
TMP
EBUILD_PHASE
TMPDIR
PWORKDIR
DISTCC_DIR
LD_PRELOAD
All variables that must stay readonly, or not readed at all, inside an
ebuild but may explain at the human that's writing one, what's happening
and when.
better ?
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] lights on internals
The ready to cut ebuild at the bottom print it's environment (variable
and functions) to a bunch of files into /var/tmp/fakebuild/.
May be useful for who want to have a look at what and when is
avaible during the various emerge phases (but not limited to).
usage:
# env -i \
PORTDIR_OVERLAY=/the/path/ \
fakebuild_progr=100 \
ebuild fakebuild-1.ebuild digest
# env -i \
fakebuild_progr=200 \
PORTDIR_OVERLAY=/the/path/ \
emerge --buildpkgonly =fakebuild-1
hint: try also the following:
- remove the egrep, sort after typeset to have also the sorce code of
the functions
- remove {pkg,src}* functions (after the previous step) to have a
look at the predefined functions.
--- app-misc/fakebuild --
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
DESCRIPTION=fake ebuild to test environment
HOMEPAGE=http://dev.gentoo.org/~vivo/;
SRC_URI=
LICENSE=GPL-2
SLOT=0
KEYWORDS=~x86
print_env() {
local fakebuild_output_dir=/var/tmp/fakebuild
mkdir -p ${fakebuild_output_dir} || die
[[ -z ${fakebuild_progr} ]] fakebuild_progr=100
fakebuild_progr=$(( $fakebuild_progr +1 ))
export fakebuild_progr
local fakebuild_ext=${1}.${fakebuild_progr}
# not sorting, break multiline vars
einfo ${fakebuild_output_dir}/env_${fakebuild_ext}
env \
${fakebuild_output_dir}/env_${fakebuild_ext}
# Remove egrep and sort to see the source of every fx
einfo ${fakebuild_output_dir}/fxlist_${fakebuild_ext}
typeset \
| egrep '^\b.* \(\)' \
| sort \
${fakebuild_output_dir}/fxlist_${fakebuild_ext}
}
print_env global_scope
pkg_setup(){ print_env pkg_setup ; }
src_unpack() { print_env src_unpack ; }
src_compile() { print_env src_compile ; }
src_test() { print_env src_test ; }
src_install() { print_env src_install ; }
pkg_preinst() { print_env pkg_preinst ; }
pkg_postinst() { print_env pkg_postinst ; }
--- app-misc/fakebuild --
--
___ __ _ ___ ___
/ ___/_ \_ \/ \ / / ___/ ___/ _ / ___/ _ \ /_ \
/ __/ _/__ / \ \/ / /__/ _/_ _\ \/ /__/ / / / / _/
/_/ /_/\_\/_/_/_/ \__/\___///___ \___/\/ / /\_\o
Simultaneous breaking of databases and backups since '90s.
World wide since 2005.0
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] MySQL 4.0 = 4.1 upgrade
Michael Kohl wrote: On Sat, 10 Sep 2005 18:24:46 +0200 Maurice van der Pot [EMAIL PROTECTED] wrote: Is this path going to be published somewhere or is this mail it? As Francesco said he won't publish a guide somewhere and I think MySQl is a widely used package, I decided to write up a little guide: http://dev.gentoo.org/~citizen428/mysql-update.txt Yep, it's only plain text, no fancy GuideXML. I'm tired, so the wording most probably isn't perfect. Still it's better than nothing and you have a link to give to interested users... Convert a document from text to xml is something that I can do ;) . http://dev.gentoo.org/~vivo/doc/mysql-update.html /home/vivo/public_html/docmysql-update.xml the xml is chmoded 664, change, destroy, and revert whatever you want there. It's a extended and reorganized version from your txt doc. Hope someone finds this useful, me for sure, thanks a lot. Documentation herd what now ? cheers Francesco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] MySQL 4.0 = 4.1 upgrade
Martin Schlemmer wrote: [...] Just use bash's built-in read function: - local password newpasswd # Read the password into $password read -sp Please enter password: password # Just echo a newline so that next output start on new line echo [...] Or something to that regards. In Cvs, thanks. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] MySQL 4.0 = 4.1 upgrade
Jason Wever wrote: On Thu, 8 Sep 2005, Francesco R wrote: Please notice that MySQL-5.0 has been erroneously unmasked for few hours but it will return under the package.mask cover at next rsync. The MySQL herd is pleased to announce that Mysql 4.1 has been unmasked today and is now marked unstable. Is there any particular reason that the utf8 use flag was re-introduced rather than using the unicode use flag like everything else does (and was standardized on)? Because it does not Adds support for Unicode but switch default to utf8 character set in MySQL config file, it's not possible to deactivate support for unicode in 4.1 version. Regards, -- Jason Wever Gentoo/Sparc Co-Team Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] MySQL 4.0 = 4.1 upgrade
Jason Stubbs wrote: On Monday 12 September 2005 00:05, Francesco R wrote: http://dev.gentoo.org/~vivo/doc/mysql-update.html With step 2, you should probably mention the issues that can arise with non-ASCII data in char fields. The character set really needs to specified in the dump. After the upgrade to 4.1, the default charset of the server should be set to something compatible and then the charset of the data should be specified to mysql when re-importing the backup. --default-character-set=charset should be that of my.cnf config file, mysqldump don't permit an atomic setting of this variable. The only option for this kind of users is to atomically dump the tables and then concat the results. Importing in mysql-4.1 it's ok, provided your default character set is utf8. Russian, asian whatever person has experience on this please speak now to correct what affermed here. Just another one of the many gotchas... expand this please -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] MySQL 4.0 = 4.1 upgrade
Ciaran McCreesh wrote: On Sun, 11 Sep 2005 19:46:25 +0200 Francesco R [EMAIL PROTECTED] wrote: | Is there any particular reason that the utf8 use flag was | re-introduced rather than using the unicode use flag like everything | else does (and was standardized on)? | | Because it does not Adds support for Unicode but switch default to | utf8 character set in MySQL config file, it's not possible to | deactivate support for unicode in 4.1 version. Bleh. A USE flag for a configuration file setting? Just install with sane defaults and let the sysadmin change it if necessary... Agree, all toghether please say that it should be defaulted to utf8 also if the previous default was latin1. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] MySQL 4.0 = 4.1 upgrade
Maurice van der Pot wrote: Is this path going to be published somewhere or is this mail it? Not from me atm, I feel very bad at writing anglish documentation. An eventual reader sure feel worst. On Thu, Sep 08, 2005 at 01:08:06PM +0200, Francesco R wrote: cmd# ebuild /var/db/pkg/dev-db/mysql-4.1.14/mysql-4.1.14.ebuild config This asks for a password, but not all passwords can be entered. Specifically one with a ` in it fails =] Also, when it outputs: Check the password it is asking you to enter the password again. I wasn't sure how to interpret this, because the password was shown on the screen so it might have been asking me to verify it and type ok or something. It's a mixture, I've received a suggestion in bugzilla on howto hide the password, but need to be tested on all platform before. And here's a character case mismatch: --result-file=BACKUP_MYSQL_4.0.SQL cmd# cat backup_mysql_4.0.sql \ ach it has been discovered, I was already singing victory. Regards, Maurice. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] MySQL 4.0 = 4.1 upgrade
Please notice that MySQL-5.0 has been erroneously unmasked for few hours but it will return under the package.mask cover at next rsync. The MySQL herd is pleased to announce that Mysql 4.1 has been unmasked today and is now marked unstable. Hope that it's possible to stabilize it soon, here there is a upgrade path. .--- | propedeutic readings: http://dev.mysql.com/doc/mysql/en/upgrading-from-4-0.html http://dev.mysql.com/doc/mysql/en/news-4-1-x.html http://dev.mysql.com/doc/mysql/en/replication-upgrade-4-0.html .--- | Upgrade path: [[[ User with a old (4.0.24 ??) mysql start from here ]]] quickpkg dev-db/mysql cmd# emerge -av --buildpkg =mysql-4.0.25-r2 cmd# ebuild \ /var/db/pkg/dev-db/mysql-4.0.25-r2/mysql-4.0.25-r2.ebuild config # Insert some kind of data fex attached backup_mysql_4.0.sql.gz [[[ User with a recent version of mysql start from here ]]] cmd# mysqldump \ -uroot \ -p$PASSWORD \ -hlocalhost \ --all-databases \ --all \ --opt \ --allow-keywords \ --flush-logs \ --hex-blob \ --master-data \ --max_allowed_packet=16M \ --result-file=BACKUP_MYSQL_4.0.SQL # check the backup file, try one one load on a mysql-4.0 server cmd# /etc/init.d/mysql stop cmd# quickpkg dev-db/mysql cmd# rm -rf /var/lib/mysql/ [[[ Real upgrade start here ]]] cmd# emerge -C mysql cmd# rm -rf /var/lib/mysql/ /var/run/mysqld/ /var/log/mysql cmd# emerge -av --buildpkg =mysql-4.1.14 cmd# revdep-rebuild cmd# ebuild /var/db/pkg/dev-db/mysql-4.1.14/mysql-4.1.14.ebuild config cmd# /etc/init.d/mysql start cmd# cat backup_mysql_4.0.sql \ | mysql \ -uroot \ -p$PASSWORD \ -hlocalhost \ --max_allowed_packet=16M cmd# mysql_fix_privilege_tables \ --defaults-file=/etc/mysql/my.cnf \ --user=root \ --password=$PASSWORD cmd# /etc/init.d/mysql restart -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
Chris Gianelloni wrote: On Tue, 2005-08-30 at 01:03 -0500, Brian Harring wrote: On Sat, Aug 27, 2005 at 03:42:25AM -0500, Brian Harring wrote: Hola all. Straight to the point, I'm proposing that the following files- arch.list categories use.desc use.local.desc package.mask updates Addition to this list: thirdpartymirrors . Question about thirdpartymirrors (this is for everyone, not just Brian)... What is the preferred method for listing mirrors, just listing the site name, or listing the site name plus path to the particular item? example from mysql mirrors: ftp://mirror.mcs.anl.gov/pub/mysql http://mirror.sit.wisc.edu/mysql http://mysql.orst.edu The mirror item should be the minimum common denominator between the mirrors. In this specific case because the mirror is usable also for other products of mysql. The reason that I ask is the 3dgamers mirror rotation could have the paths added to it, which would actually shorten a lot of SRC_URI's in quite a few games ebuilds. there are always excepitions ;-) You are speaking of paths that will *never* change right ? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is this also a good time to note that the amd64 and x86 could *easily* be covered under the same keyword? We cover a large variety of mips machines/userlands under one keyword, with differences much more significant then that between x86 and amd64. Sorry I disagree with this, differences exists and sometimes are a problem. Some package and library don't compile cleanly under amd64 arch. On few but existant cases it's good to have two different archs. Not even going near the analizing the differences in the profiles. rgs, Francesco -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDFHTN1wNBTLVPMuARAkCpAJ4gkQQ9Ntp9j5dsldyFLLt1lj/iTgCfahlF avwo9tHBaW1LTWWPeLPDFO4= =yYUZ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
Stephen P. Becker wrote:
Is this also a good time to note that the amd64 and x86 could
*easily* be covered under the same keyword? We cover a large
variety of mips machines/userlands under one keyword, with
differences much more significant then that between x86 and amd64.
Sorry I disagree with this, differences exists and sometimes are a
problem. Some package and library don't compile cleanly under amd64
arch.
On few but existant cases it's good to have two different archs. Not
even going near the analizing the differences in the profiles.
So these things won't compile in a x86 chroot on a amd64 box even?
Never said this, I've a dual opteron running informix that can *only*
run under a x86 environment.
this is the profile for the main environment:
make.profile - ../usr/portage/profiles/default-linux/amd64/2005.0
and this one for the chroot:
/chroot/ifx/etc/make.profile -
../usr/portage/profiles/default-linux/x86/2004.0/
They are covered from completely different keywords and profiles.
I find that really hard to believe. Besides, close collaboration
between folks with x86 and folks with amd64 installs can make it easy
to ensure the same versions work on both arches (if you really want to
call them separate arches...) Your profile argument is silly too,
since both arches could *easily* be merged into sub-profiles in our
cascading system.
Maybe I've not understud the first sentence, what are you saying is that
amd64 teams can do x86 testing, we agree on this (all not kernel related).
profiles: /usr/portage/profiles/default-linux{/amd64/2005.1/ ,
x86/2005.1/} looks rather different to me (not analized them deeply)
Besides, we have the same sorts of problems on mips, except they are
magnified since we have a possibility of 3 different userland ABIs, on
both big and little endian hardware. After dealing with this sort of
stuff for a long time with *far* fewer developers and time in general,
I'm really not impressed with your argument. You'll have to do better
then that.
With your experience what are the pro and cons of merging different archs ?
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Fixing the TERM mess
Ciaran McCreesh wrote:
On Sun, 21 Aug 2005 18:43:54 -0400 Dan Meltzer
[EMAIL PROTECTED] wrote:
| putty pretends to be an xterm and dies at xtermcontrol --get-bg... I
| can test other things if you need.. just give me some idea :)
Thanks. The other useful one is to see whether it does 256 colours
properly like real xterm does. The following bash script, when run with
'256' as its argument, should look the same as it does when run under
a real xterm.
#!/usr/bin/env bash
# vim: set sw=4 sts=4 et :
[[ -z ${1} ]] cat END exit 1
Usage: ${0} [count]
count should usually be either 88 (rxvt-based terminals) or 256
(xterm-based terminals).
END
echo -n 0:
for (( a = 0 ; a ${1} ; a++ )) ; do
echo -n -e \e[38;5;${a#0}m#\e[48;5;${a#0}mX\e[0;0m
[[ -z ${a##*9} ]] echo -n -e \n\e[0;0m$(printf '%3d' ${a} ):
done
echo -e \e[0;0m ; echo
Probably putty use xterm as default instead to be usable on most
configurations.
I've found that putty is the best (free on windows) linux term
emulator around.
As a consequence all my win boxes use it with the following settings:
Terminal - Keyboard - The Functions keys and keypad - Linux
Connection - Data - Terminal-type string - linux
with this settings the xtermcontrol --get-bg output this:
xtermcontrol: TERM=linux: probably not xterm variant
The script you posted here has good results for $1 = 256 for putty
version 0.58 .
For version 0.56 of putty the for loop need to start from 13 instead
of 0 or it screwed up things at the extend that a reset need to be
run. Additionally the color support is limited to 16 .
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
Luca Barbato wrote: Christian Parpart wrote: Using the minimal useflag for this - IMHO - is a misuse of the idea of minimal semantically - as I do understand minimal in a way like don't overbloat me with patches and other feature additions-alike. minimal is about keeping the package at the minimum, that means strip every feature that won't prevent it to run. Maybe it's foggy for mysql usage, better suggestions (clientonly, libonly) ? Do we have a general accepted gentoo policy for this? Usually the policy is If the upstream has planned that we'll follow, otherwise no [IMHO] Upstream distribuite binaryes of only libraryes, in this direction it's supported. Build them from the source only libs is not deeply supported, see below. [/IMHO] And... any thoughts on this subject? I'd prefer to have those features enabled by useflag, sometimes (eg. qemu) I can split functionality in separated ebuild and use a metaebuild to let users merge both w/out major overhead. In your case a useflag IMHO would be enough since the situation require a particular setup and in the case the constraint changes won't be a problem rebuild a full mysql. The question is, does the mysql configure script have a clientonly and/or a libraryonly option? there is an option for configure --without-server , but actually the server is still build. Take a look at = dev-db/mysql-4.0.24-r2 for how minimal use flag is used, basically it force some flag off and remove some files from the install. There were a client and server useflag discussion before. lu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
Lance Albertson wrote: Mike Frysinger wrote: On Thursday 18 August 2005 10:28 am, Christian Parpart wrote: Do we have a general accepted gentoo policy for this? general policy is to not split packages (and i agree with this ...) bind and bind-tools is split ;) Why is it so bad to split packages? (I'm just curious) Seems a bit odd that we can't have a library only, client only, etc package like the other distros. Of course, I understand that we could use useflags for that, but is that really the best solution for this particular issue? Oh well, I'm just a sysadmin, not a coder so I'll got back to my cave. ;) vimdiff bind-tools/bind-tools-9.2.5.ebuild bind/bind-9.2.5-r5.ebuild In the eventuality of mysql being splitted the landscape is totally different. The code to duplicate is a 40% of the ebuild speaking of volume, in maintenance the percentage is bigger. I'm a (little) sysadmin too, redundancy is good speaking of servers but maintain a cluster or simply to synced servers is more difficult (and error prone) that maintain only one, right ? -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] last rites for dev-db/mysqltool
It's dead upstream and the ebuild need to be rewritten from scratch. Unless there is some volenterous it will be sadly removed 2005-08-29 See bugs 77539,93725 -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] MySQL ebuild removal selection
These ebuilds are scheduled for removal in the next 24 hours: - mysql-3.23.58 mysql-4.0.22-r1 mysql-4.0.23 mysql-4.0.23-r1 mysql-4.0.23-r2 mysql-4.0.24-r1 mysql-4.0.24-r2 mysql-4.0.25-r1 mysql-4.1.8 mysql-4.1.8-r1 These will survive: --- mysql-3.23.58-r1 mysql-4.0.22 mysql-4.0.22-r2 mysql-4.0.24 mysql-4.0.25-r2 mysql-4.1.13-r1 (masked) mysql-5.0.9_beta-r2 (masked) mysql-5.0.10_beta (masked) If you have some particular reason for keeping any of them drop me a note on/off list. Best regards Francesco R. -- . These pages are best viewed by coming to my house and looking at . . my monitor. [S. Lucas Bergman (on his website)]. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] init script guidelines
Eric Brown wrote: Services that use Gentoo init scripts often report a status of [started] or [OK] even though they fail to start. The most recent bug like this that I've found is with snort. If you have a bad rule, snort will initialize, the rc-scripts will give it an [OK] status, and then it will die once it parses the rules. The real problem is not that the daemons don't return errors, but that our init scripts do not make reasonable attempts to verify service startup. If a Gentoo init script claims that a service started, it should make an effort to check that the processes are actually running shortly after the script is run, even if start-stop-daemon says the parent process initialized. Relying on the return value of start-stop-daemon is simply insufficient for some services. I am aware that there are services that can monitor the status of other services (app-admin/mon?) but I think this issue is a little different. If an ebuild developer is aware of an error condition can commonly occur shortly after a daemon initializes, why not attempt to catch those errors? Most of them could probably be caught by simply checking to see if the process is still running shortly after the script is run. I propose increasing developer awareness of this problem, perhaps through some formal guidelines for ebuild developers. At the very least, I would like to see these bugs being acknowledged in bugs.gentoo.org instead of getting the same old upstream/it's not our fault response. We are responsible for our init scripts, and they are important to our users. I have 2 ideas for the actual implementation: 1) Some kind of check() function in the init.d script, or a generic check() function that just checks with ps | grep. This might typically be called after having the init script sleep for a certain amount of time. 2) Some kind of special init script that checks registered daemons after all services have started. (i.e. it depends on all daemons, or they are put into it’s config file). With this scheme we could avoid excessive sleeping during startup (to keep it fast), And perhaps even keep using service specific check() functions Does anyone else think this idea is worth looking into? http://bugs.gentoo.org/show_bug.cgi?id=90471 We managed this checking for the socket mysql always create on *nix . But whit a timeout of five seconds if there is no error message nor socket in that time the script assume the server started. I'm the first to say that this need to be improved but it's a start. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] init script guidelines
Roy Marples wrote: On Tue, 2005-07-19 at 12:42 -0400, Eric Brown wrote: The real problem is not that the daemons don't return errors, but that our init scripts do not make reasonable attempts to verify service startup. If a Gentoo init script claims that a service started, it should make an effort to check that the processes are actually running shortly after the script is run, even if start-stop-daemon says the parent process initialized. Relying on the return value of start-stop-daemon is simply insufficient for some services. I agree. Infact, rc-services.sh (/lib/rcscripts/sh) has been totally re-written for the baselayout-1.12.x branch. It now intercepts calls to start-stop-daemon and checks if the daemon is still active after a default time of 0.1 (adjustable) seconds. If not, the we assume the daemon failed. This solves many existing bugs :) Also, we kill any rogue processes and other such checks when a stop call to start-stop-daemon is made - which is handy for when asterisk fails to start and leaves mpg123 processes lying around :) Check it out when baselayout-1.12.0pre1 hits portage! Caveat: - some init scripts abuse start-stop-daemon. One example are all courier scripts which pass the env program as a daemon. This is easily worked around, but we fail badly if env then calls a shell script which in turn launches a daemon. Of all the server stuff I run, only couier has this issue - but there may be other programs too. Basically start-stop-daemon should only call daemons! http://bugs.gentoo.org/show_bug.cgi?id=98745 Roy what about to define two additional functions check_startup() and check_shutdown() intended to be filled from package mantainer. The rc scripts can call these one to check if a service is started/stopped or not. If not it wait and retry untill a timeout is reached. This open the road also to centralized policies of waits between check like : (1,1,1,1,1,1) (1,2,3,4,5,6) (1,2,4,8,16,32) and other nice stuff. Francesco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New MySQL doc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris White wrote: Here's the initial devspace draft of the new MySQL draft I've been working on: http://dev.gentoo.org/~chriswhite/mysql.html Comments, etc are welcome. Chris White one reminder: Code listing 1.3: MySQL configuration probably will change for mysql-4.1 and better (when unmasked) and having the possibility to scroll the screen, Code listing 4.19: Finding our guest user in the user table mysql SELECT * FROM user WHERE User = 'guest'; may become Code listing 4.19: Finding our guest user in the user table mysql SELECT * FROM user WHERE User = 'guest' \G to make it more readable. See J.M. email too the default my.cnf has the following line bind-address= 127.0.0.1 that actually restrict the server access to local machine only. You may want to signal this in the Granting Privleges with GRANT section. Last but not last, thankyou - nice intro document Francesco R. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0tyw1wNBTLVPMuARAroiAJsHl8+M1cOD0Yq2Zlti8kVaMxDnIQCdFIke NS4BndQanBMCysEuApHAwG0= =dy9e -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: qt.eclass
Francesco R wrote: [snip] s/ # example: ###MY_VER_RANGE 4.0 4.0.16 ###MY_VER_RANGE 4.1 4.1.4 ###MY_VER_RANGE 5.0 # if a patch contains these three lines then: # all version = 4.0 but 4.0.16, # all version = 4.1 but 4.0.16, # all version = 5.0 will be affected by this patch / example: ###MY_VER_RANGE [4.0,4.0.16) [4.1,4.1.4) [5.0,] # if a patch contains the previous line then: # all version = 4.0 but 4.0.16, # all version = 4.1 but 4.0.16, # all version = 5.0 will be affected by this patch / [snip] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] DBD-mysql select failures with MySQL 4.1
Anthony Gorecki wrote: On Sunday, June 26, 2005 9:28 pm, Zac Medico wrote: Have you checked the DBI error status? See the parts about $DBI::err, $DBI::errstr, and RaiseError here: In all cases, DBI::err() returns undefined, indicating no error. It's quite perplexing. Maybe we are a bit off topic on this list ... but here we are. Going to give some hints where to search the source of the error, nothing else, sorry. a) take a look at mysql logs. b) re-emerge =DBD-mysql-2.9007 c) try something like log = /tmp/mysqld.sql in [mysqld_safe] section of my.cnf then restart mysql. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] lcars gets his commit bit
Grant Goodyear wrote: Dear all, After quite some time merely being an infra dev, lcars has finally taken the leap and gained commit access to the tree. He's going to be officially taking over sendmail and supporting other packages that infra uses, so please feel free to start shoveling bugs his way! *Grin* -g2boojum- newer than you but every occasion is good for a welcome ;-) conspiracy ? hum good idea lakes of wine and beer ? still better -- gentoo-dev@gentoo.org mailing list
