Re: [gentoo-user] ARGH I uninstalled python
On Wed, 27 May 2009 01:32:13 -0700 (PDT) Jon Hardcastle jd_hardcas...@yahoo.com wrote: I'd hope that if anyone else comes a cropper by this then at least this conv will help them! But I was EXPECTING portage to not let me do something that would stop the 'solution' (and that is what it is whether at the portage or the gentoo level) working. I hope you solve everything. Anyway there is something you should have learned: think before acting, and do not rely on safeguards. They were meant to diminish the damage if you get into problems, not to be counted on as if they were normal functionality. In terms of computer usage, do never perform a task without reading documentation and understanding what you are doing. You should have realized that Python is a core component of the system and that one needs great care when messing with core components. And specifically, it is *not* safe to remove a component just for a small time (this is not the first time I've seen this). For a normal component you have to, at least, ensure the component is not currently in use and will not be needed during the period it will be absent. For a core component you should be far more careful. And normally you don't have to mess with it at all. And after your first mistake you continued to make others. The instructions in that blog were not quite good. After a little time searching the forums I found the tinderbox solution - which is far simpler and cleaner. Also, the person recommending the solution has some credibility (being a site administrator for the Gentoo forums) and, the solution being simpler, it is easier for you to *understand* them and act with confidence (and I personally would take at the very lest one extra care - verify if the USE flags and CFLAGS the binary package was built with were compatible with my system). You appear to have executed commands you didn't understand - based on some blog. Anyway, how is the system now? Is portage working? What about the manual Python installations, are they still in the system? I don't know if it is healthy to have these remains around (and if you want to clean them, be careful). By the way, can you write with more clarity? I don't understand you completely - perhaps because I am a non-native English speaker. Regards, Jorge
Re: [gentoo-user] ARGH I uninstalled python
On Sat, 23 May 2009 19:08:50 -0300 Jorge Morais please.no.spam.h...@gmail.com wrote: One idea: you can can recompile python with a safe prefix (such as a subdir of your home), issue make install (not as root, for increased safety) and see where Python install its files relative to the prefix, so you can delete them from your system (to be more careful before deleting a file, you can issue qfile FILE to see if it is owned by a portage-installed package. And in the end you can emerge python properly, from the sources, so all the ebuild logic (which is more than just ./configure, make and make install) gets applied, and you get a Python installation that respects your USE flags, CFLAGS and other system-specific settings (obviously you don't get such a system-customized python when you use the binary package from tinderbox). I should mention that you should be careful about deleting any files - and qfile is not a 100% guarantee that the file does not come from a Portage-installed package. For example, in my system Python was installed by Portage, and $ file /usr/bin/python /usr/bin/python: symbolic link to `python2.5' , yet $ qfile /usr/bin/python No output So qfile giving an empty output is not a guarantee that the file is indeed orphan. Specially with symlinks - look at the Python ebuild and see the way these symlinks are generated. And of course, it is wise to emerge --buildpkg python before doing any cleaning. And after the cleaning, reemerge Python. Regards, Jorge
Re: [gentoo-user] ARGH I uninstalled python
On Wed, 27 May 2009 16:28:35 -0400 Wyatt Epp wyatt@gmail.com wrote: On Wed, May 27, 2009 at 8:49 AM, Jorge Morais please.no.spam.h...@gmail.com wrote: I should mention that you should be careful about deleting any files - and qfile is not a 100% guarantee that the file does not come from a Portage-installed package. For example, in my system Python was installed by Portage, and $ file /usr/bin/python /usr/bin/python: symbolic link to `python2.5' , yet $ qfile /usr/bin/python No output You know, I wonder if that's not a bug? There is no eselect module for setting your python version, and there's no entry for that symlink in the CONTENTS for these packages. If I understand the role of that file, that symlink really shouldn't exist without being listed there. I don't know enough about Portage to comment, but undoubtedly I (as a user) would like these files to be registered by Portage.
Re: [gentoo-user] cannot install emacs/emacs-cvs with X use
On Sun, 24 May 2009 08:44:32 +0800 Kevin kevin.tia...@gmail.com wrote: Hello, after reinstall my system, I can emerge neither emacs nor emacs-cvs successfully on my gentoo. when proceeded to the working fork check, it stops and hangs over, never go ahead. build.log: http://dpaste.com/hold/47083/ and here it is emerge --info: http://dpaste.com/hold/47084/ I can only USE=-X emerge app-editors/emacs-cvs, but I don't know why, other programs emerge well. config.log is too large to send to dpaste.com, I've attached it, hope someone can help me, thanks in advance. Could you try the version app-editors/emacs-cvs-23.0.93 ? That is the one I have here (23.0.94 entered Portage very very recently), and it works well. It could make things easier to compare. It would make it even easier if you used the same USE flags as me. You can see the USE flags I use to build emacs here: $ emerge -pqv =app-editors/emacs-cvs-23.0.93 [ebuild R ] app-editors/emacs-cvs-23.0.93 USE=X alsa dbus gif gpm gtk gzip-el jpeg png sound spell svg tiff toolkit-scroll-bars xpm -Xaw3d -hesiod -kerberos -m17n-lib -motif -source -xft Also, it seems you have interrupted the process with a SIGINT. Are you sure it was hung? How much did you wait? Did you use top to see if there was some process making heavy use of the processor?
Re: [gentoo-user] ARGH I uninstalled python
On Sun, 24 May 2009 01:52:45 -0700 Keith Dart ke...@dartworks.biz wrote: On Sat, 23 May 2009 19:08:50 -0300 Jorge Morais please.no.spam.h...@gmail.com wrote: Now, I do have concerns about your system having remains of multiple python installations. Any person with python knowledge can give an opinion on whether this is dangerous? And what is the easiest way to clean the mess? Python is designed to work with multiple versions installed. Therefore, the ebuild is also slotted so you can have multiple versions installed. Use eselect python to choose which one you want to use as the default. Also, don't forget to run python-updater after recent changes that installed Python 2.6 for you. You can always unmerge the specific old version afterwards. e.g. emerge --unmerge =dev-lang/python-2.5.4-r2 You don't seem to have taken into account that he has installed multiple vanilla python versions *manually* (with ./configure, make, and make install as root), to /usr, and then installed Python with Portage.
Re: [gentoo-user] How to manage package.keywords for greater system reliability?
On Fri, 22 May 2009 12:38:34 +0100 Neil Bothwick n...@digimed.co.uk wrote: On Fri, 22 May 2009 07:40:28 -0300, Jorge Morais wrote: maybe you should just run a ~arch system. I want a reliable system. Isn't ~arch quite less reliable than arch ? Not in my experience. ~arch only means the builds are in testing, the software is as reliable as upstream makes it. You may hit the occasional problem when updating, but once the software is installed it will be as reliable as on any other distro. I find it hard to believe this. ~arch often releases a X.0 version soon after it is released. It normally only enters stable after upstream has released the X.2 or X.3 bugfix release. Also, the Gentoo developers take some care to make the stable packages harmonious. For example, stable GCC can compile other stable packages. But a ~arch GCC seems to result in bugs (look at bug #198121, GCC 4.3 porting). So ~arch users tend to eat more bugs. I think my doubt is very important. Pity that the Python-uninstallation thread stole all attention :( Oh, and do you also think that the introduction of _FORTIFY_SOURCE by default in GCC-4.3.3 without warning (no mention in the Changelog) was bad manners of the developers? I think I should take this thread to gentoo-dev
Re: [gentoo-user] ARGH I uninstalled python
Thank you! Thank you! Thank you!
I followed this
http://blogs.pwmn.net/korkakak/2008/06/04/gentoo-i-unmerged-python-now-what
which worked - in the end. couple of caveats tho for anyone 'that follows'
get python from their site as the ftp link in this article is out of date.
http://www.python.org/download/releases/
also I initially tried 3.01 and that didn't work so i installed 2.6.2 which
worked 'out of the box' i then tested with 'emerge' and am now running
'emerge -va python'
Cheers guys!
Thanks to Dale too!
Glad it worked.
But, I don't know what will happen when the properly emerged python
overwrites the manually installed Python.
Does anybody know if the manual python install is slotted, in the sense
that it installs files in /usr/lib/python2.6, /usr/include/python2.6, etc?
If it isn't, and Portage installs a slotted Python, the old files wouldn't
be overwritten.
And even if it is, the differences between the differently-configured and
super-patched new python and the vanilla old python could result in
a different set of file names, so it is possible that the old python
will not be totally overwritten by the portage-emerged python.
If I were you, I would at the very least read the log (specially its tail)
of the python emerge (emerge logs normally go to /var/log/emerge).
And you did log the files installed by the manual python install,
didn't you?
And why did you try python 3.01 first? You should try a similar vesion to
what you were previously running. And specifically python 3.01 is crazy,
as it is widely known that it is *not* compatible with python 2.x software.
And did you properly uninstall python 3.0.1?
Also, I didn't like the instructions in this blog very much.
Wouldn't it be more appropriate to configure python like
portage would?
For example, in my system, where the last python install was
dev-lang/python-2.5.4-r2 USE=ncurses readline ssl threads xml -berkdb -build
-doc -examples -gdbm -ipv6 -sqlite -tk -ucs2 -wininst
the configure line was (from the log)
./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --with-fpectl --enable-shared --disable-ipv6
--infodir=${prefix}/share/info --mandir=${prefix}/share/man --with-libc=
--enable-unicode=ucs4 --with-threads --build=i686-pc-linux-gnu
Maybe it would be nice to install python to /usr/local (I'm not sure),
but if you are going to install it in /usr (like portage), I think you
might as well use the same configure line portage would.
And if you wanted to be really clean, you could apply the patches that
portage applies.
And most importantly,
*was this necessary*?
Couldn't he have emerged python by invoking
ebuild /usr/port/usr/portage/dev-lang/python/python-2.6.2.ebuild merge
?
This would do everyting correctly.
And wouldn't it work without Python, since it is written in Bash?
AFAIK, what needs Python is the high level interface to the portage
system, while the low-level interface only needs Bash (but I'm
totally not sure).
And finally, couldn't he have gotten a binary package from
http://tinderbox.dev.gentoo.org/default-linux/x86/dev-lang/
?
Re: [gentoo-user] ARGH I uninstalled python
On Sat, 23 May 2009 04:55:04 -0300 Jorge Morais please.no.spam.h...@gmail.com wrote: Couldn't he have emerged python by invoking ebuild /usr/port/usr/portage/dev-lang/python/python-2.6.2.ebuild merge ? This would do everyting correctly. And wouldn't it work without Python, since it is written in Bash? AFAIK, what needs Python is the high level interface to the portage system, while the low-level interface only needs Bash (but I'm totally not sure). Please forget this stupidity. The ebuild command is written in Python, not Bash (should have written the email with less haste) And finally, couldn't he have gotten a binary package from http://tinderbox.dev.gentoo.org/default-linux/x86/dev-lang/ ? But this point still stands.
Re: [gentoo-user] ARGH I uninstalled python
On Sat, 23 May 2009 03:51:40 -0700 (PDT) Jon Hardcastle jd_hardcas...@yahoo.com wrote: And finally, couldn't he have gotten a binary package from http://tinderbox.dev.gentoo.org/default-linux/x86/dev-lang/ ? Have you not yet tried to get python from a binary package? See http://forums.gentoo.org/viewtopic-p-4669397.html#4669397 That is both the easiest and cleanest solution I have found so far, (not that I have researched much, I admit). And maybe you don't even have to extract the tarball manually with tar; maybe you can use qmerge from app-portage/portage-utils (AFAIK it is written in C). Now, I do have concerns about your system having remains of multiple python installations. Any person with python knowledge can give an opinion on whether this is dangerous? And what is the easiest way to clean the mess? One idea: you can can recompile python with a safe prefix (such as a subdir of your home), issue make install (not as root, for increased safety) and see where Python install its files relative to the prefix, so you can delete them from your system (to be more careful before deleting a file, you can issue qfile FILE to see if it is owned by a portage-installed package. And in the end you can emerge python properly, from the sources, so all the ebuild logic (which is more than just ./configure, make and make install) gets applied, and you get a Python installation that respects your USE flags, CFLAGS and other system-specific settings (obviously you don't get such a system-customized python when you use the binary package from tinderbox).
Re: [gentoo-user] How to manage package.keywords for greater system reliability?
On Fri, 22 May 2009 09:00:05 +0100 Neil Bothwick n...@digimed.co.uk wrote: On Thu, 21 May 2009 21:41:22 -0300, Jorge Morais wrote: Or maybe I should just stick to all-stable, so as to not be different, and keep package.keywords for those packages where I really want a new feature (like packages with no stable versions)? If you want so many up to date packages It is not so much. My package.keywords/longterm lists 13 packages; my package.keywords/shortterm lists 21 packages, many of which will get out of there in the future, as the version I use become stable. 5 of these 21 packages would not be there if I always had my current it is better to avoid the bleeding edge view. maybe you should just run a ~arch system. I want a reliable system. Isn't ~arch quite less reliable than arch ? (Also, newer software versions are often more bloated). It's been said many times that a mixed system is a potential source of trouble. I didn't hear it. Your comparison of stable Gentoo with Debian testing is strange, since the Gentoo equivalent is ~arch. I thought Debian testing was more stringent regarding reliability than Gentoo ~arch; anyway, the point is that when a new bugfix release (like gimp 2.6.6) is released, I want to see if other distros consider the bugfixes important enough to pick it; I chose Debian because I am somewhat familiar with it; and Debian testing because AFAIK Debian stable only rarely picks updates that are not security-related. Some people even say that Debian stable is for servers.
[gentoo-user] How to manage package.keywords for greater system reliability?
Hi. I used to think it was safe to use ~arch packages (through package.keywords) on a stable system until I saw bug #257047 - GCC 4.3 didn't have a strict enough glibc dependency. And comment #15 in that bug report is: [...] we don't test or support half-stable half-testing toolchains, and they are likely to break, like in this case. if you're going to use an ~arch keyworded complier, you will need to use a ~arch libc. OK, I will avoid ~arch toolchain components. What worries me is that I never saw a warning about this. Also, GCC 4.3.3 enables FORTIFY_SOURCE=2 by default and this breaks some packages. A developer said on 2009-04-10 they were only processing bugs that can be confirmed in ~arch. So an arch system with ~arch toolchain could hit many bugs and maybe such a system would even be less reliable than an entirely ~arch system. So: 1) Certain subsystems, like the toolchain, need to be harmonious - either all arch or all ~arch. What other subsystems have this need? 2) With the FORTIFY_SOURCE issues, it seems that an ~arch toolchain shouldn't be used in an arch system at all. Now my greatest practical concern: bugfix releases 3) Sometimes Gentoo takes a long time to stabilize a bugfix release like media-gfx/gimp-2.6.6 (the latest arch-blessed release is 2.6.4); this release fixes many bugs and entered Portage in 2009-03-18 and by searching on b.g.o I can't find any regressions; and it entered Debian testing in 2009-04-01. I don't know the cause of this delay; I guess the arch testing teams are overworked. I often put these bugfix releases in package.keywords. Isn't it wise to use the latest bugfix release in a given major version? For example, I want to use sys-kernel/vanilla-sources-2.6.27.x, and since the last arch version is 2.6.27.12, far from the latest upstream stable version (2.6.27.24), I put =sys-kernel/vanilla-sources-2.6.27* in /etc/portage/package.keywords/shortterm. When I see a new bugfix release of a package I care about, I look at the changelog to see the bug corrections. I decide how much to wait before putting the bugfix version in package.keywords depending on the severity of the fixed bugs (and I look at bugs.gentoo.org for any regressions, and I look if the version has been accepted in distros like Debian testing).For example, I put mail-client/claws-mail-3.7.1 in package.keywords nearly immediately due to the importance of the bug fixes. Is it wise to do this for any program? Maybe only for programs not part of the core base system (such as the toolchain, bash or coreutils*), relying on the developers for the base system? Or maybe I should just stick to all-stable, so as to not be different, and keep package.keywords for those packages where I really want a new feature (like packages with no stable versions)? * Speaking of coreutils, it is still at 7.1, with upstream having released 7.4, which fixes bugs in 7.1 .
Re: [gentoo-user] Re: WARNING **: Failed to create dbus proxy for org.gnome.SettingsDaemon: Could not get owner of name 'org.gnome.SettingsDaemon': no such name
On Wed, 13 May 2009 17:13:23 -0700 walt w41...@gmail.com wrote: Jorge Morais wrote: On Sun, 10 May 2009 07:50:47 -0700 waltw41...@gmail.com wrote: Jorge Morais wrote: When starting evince from a terminal, I get a message like this: ** (evince:3597): WARNING **: Failed to create dbus proxy for org.gnome.SettingsDaemon: Could not get owner of name 'org.gnome.SettingsDaemon': no such name... If you don't have the settings-daemon running then such an error would be expected. But do you know what this error causes? If it is a harmless warning message, I think it is better to ignore it than install gnome-settings-daemon, which pulls 24 other packages. It's harmless, so ignore it. If you are not using gnome as your desktop then you don't need the settings-daemon. Thank you
Re: [gentoo-user] Re: WARNING **: Failed to create dbus proxy for org.gnome.SettingsDaemon: Could not get owner of name 'org.gnome.SettingsDaemon': no such name
On Sun, 10 May 2009 07:50:47 -0700 walt w41...@gmail.com wrote: Jorge Morais wrote: When starting evince from a terminal, I get a message like this: ** (evince:3597): WARNING **: Failed to create dbus proxy for org.gnome.SettingsDaemon: Could not get owner of name 'org.gnome.SettingsDaemon': no such name... You don't appear to be running an actual gnome session Yes. I use a minimal LXDE environment. And sorry for not making that clear. Stupid me. nor do you have the gnome-settings-daemon package installed, am I correct? Yes. I have gconf (as a dependency of evince), and I see that when evince is started, a process named gconfd-2 runs. I thought this was the settings daemon evince needs. I didn't know there was a gnome-settings-daemon package. If you don't have the settings-daemon running then such an error would be expected. But do you know what this error causes? If it is a harmless warning message, I think it is better to ignore it than install gnome-settings-daemon, which pulls 24 other packages.
[gentoo-user] WARNING **: Failed to create dbus proxy for org.gnome.SettingsDaemon: Could not get owner of name 'org.gnome.SettingsDaemon': no such name
When starting evince from a terminal, I get a message like this: ** (evince:3597): WARNING **: Failed to create dbus proxy for org.gnome.SettingsDaemon: Could not get owner of name 'org.gnome.SettingsDaemon': no such name 3597 is evince's pid. Does anybody know what causes this? Should I worry about this? Some info: $ emerge -qpv evince [ebuild R ] app-text/evince-2.24.2 USE=dbus tiff -debug -djvu -doc -dvi -gnome-keyring -nautilus -t1lib $ emerge --info emerge-output.txt emerge-output.txt: Portage 2.1.6.11 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.8_p20080602-r1, 2.6.27.22 i686) = System uname: Linux-2.6.27.22-i686-AMD_Athlon-tm-_XP_2600+-with-glibc2.0 Timestamp of tree: Tue, 05 May 2009 12:45:02 + app-shells/bash: 3.2_p39 dev-java/java-config: 2.1.7 dev-lang/python: 2.5.4-r2 dev-util/cmake: 2.6.2-r1 sys-apps/baselayout: 1.12.12 sys-apps/sandbox:1.6-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.7.9-r1, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS=x86 CBUILD=i686-pc-linux-gnu CFLAGS=-O2 -march=athlon-xp -pipe -fomit-frame-pointer CHOST=i686-pc-linux-gnu CONFIG_PROTECT=/etc CONFIG_PROTECT_MASK=/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d CXXFLAGS=-O2 -march=athlon-xp -pipe -fomit-frame-pointer DISTDIR=/usr/local/slowpart/usr/portage/distfiles EMERGE_DEFAULT_OPTS=--nospinner FEATURES=collision-protect distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch GENTOO_MIRRORS=ftp://ftp.las.ic.unicamp.br/pub/gentoo/ http://cudlug.cudenver.edu/gentoo http://mirrors.usu.edu/mirrors/gentoo/ http://gentoo.osuosl.org/ http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo/; LANG=pt_BR LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu LINGUAS=en MAKEOPTS=-j2 PKGDIR=/usr/local/slowpart/usr/portage/packages PORTAGE_CONFIGROOT=/ PORTAGE_RSYNC_OPTS=--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages PORTAGE_TMPDIR=/usr/local/slowpart/var/tmp PORTDIR=/usr/portage PORTDIR_OVERLAY=/usr/local/jorgeportage SYNC=rsync://rsync.samerica.gentoo.org/gentoo-portage USE=3dnow 3dnowext X a52 aac aalib acpi alsa aotuv bash-completion bluetooth branding bzip2 cairo cdio cdr cli cracklib dbus dvd dvdr dvdread emacs emboss encode evo exif fam ffmpeg firefox flac fortran gif glibc-omitfp gnuplot gnutls gpm gstreamer gzip-el hddtemp iceweasel iconv imap isdnlog jpeg libcaca libsamplerate logrotate lzma mad matroska midi mikmod mmx mmxext mng moznopango mp3 mpeg mplayer mudflap ncurses network-cron nptl nptlonly nsplugin offensive ogg opengl openmp pam pcre pdf png ppds pppd python qt3support quicktime readline reflection sdl session sox speex spell spl sse ssl svg symlink sysfs tcpd theora tiff toolkit-scroll-bars truetype unicode usb v4l2 vorbis x264 x86 xml xorg xosd xulrunner xv zlib commentLINE BROKEN BECAUSE CLAWS-MAIL WARNED THE LINE WAS TOO LONG/comment ALSA_CARDS=cmipci ALSA_PCM_PLUGINS=adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol APACHE2_MODULES=actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias ELIBC=glibc INPUT_DEVICES=keyboard mouse evdev KERNEL=linux LCD_DEVICES=bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text LINGUAS=en USERLAND=GNU VIDEO_CARDS=nv vesa Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS $ emerge -qpev evince emerge-output.txt emerge-output.txt : [ebuild R ] sys-apps/portage-2.1.6.11 USE=-build -doc -epydoc (-selinux) LINGUAS=-pl [ebuild R ] sys-apps/sed-4.1.5-r1 USE=-nls -static [ebuild R ] sys-libs/zlib-1.2.3-r1 [ebuild R ] sys-devel/gnuconfig-20080928 [ebuild R ] dev-libs/expat-2.0.1-r1 [ebuild R ] sys-devel/flex-2.5.35 USE=-nls -static [ebuild R ] virtual/libiconv-0 [ebuild R ] app-misc/pax-utils-0.1.19 USE=-caps [ebuild R ] sys-devel/automake-wrapper-3-r1 [ebuild R ] app-arch/bzip2-1.0.5-r1 USE=-static [ebuild R ] sys-devel/autoconf-wrapper-6 [ebuild R ] sys-devel/gcc-config-1.4.0-r4 [ebuild R ] dev-libs/gmp-4.2.4 USE=-nocxx
Re: [gentoo-user] Re: emerge --oneshot gcc-4.1.2
On Sat, 02 May 2009 20:34:02 +0300 Nikos Chantziaras rea...@arcor.de wrote: Hung Dang wrote: Hi all I have to emerge gcc-4.1.2 to use with CUDA. However, I receive the following message. !!! 'gcc-4.1.2' is not a valid package atom. !!! Please check ebuild(5) for full details. What should I do to avoid of this problem? Try: emerge --oneshot =gcc-4.1.2 (that is, you need an = in front.) Or simply just: emerge --oneshot gcc if you're not using an ~arch (testing) GCC. In many architectures GCC 4.3 is the newest stable versions, dude.
Re: [gentoo-user] question about portage capabilities
On Sat, 18 Apr 2009 21:33:18 -0400 Denis denis@gmail.com wrote: Hello all, I am using a package called Rasmol, which is used for visualization of molecular structures. This software uses a certain table for atomic sizes, and I need to change some values in that table - it is stored in a header file within Rasmol source code. There is an ebuild for Rasmol, and it works fine - but what I'm wondering is how I can tell portage to STOP once it unpacks Rasmol in the temporary work directory - so I can tweak some things in the source code - and then resume the build, using what's already in the work directory. Looking at a manpage for emerge, I didn't immediately get any creative ideas, but might someone offer some advice for how to accomplish this? man ebuild. I assume you are talking of sci-chemistry/rasmol. Then you can accomplish your hack with ebuild /usr/portage/sci-chemistry/rasmol/rasmol-2.7.2.1.1-r1.ebuild unpack tweak ebuild /usr/portage/sci-chemistry/rasmol/rasmol-2.7.2.1.1-r1.ebuild install But I am not sure this is a clean way to achieve your goal. The standard way would be to write a patch, and modify the ebuild to apply your patch. Alternatively, you can apply the patch to the distfile, and modify the ebuild to use the new distfile. Do you know how to write a patch? Note: if you are going to modify your ebuild, it is a good idea to put it in an overlay It would be something like this mkdir --parents /usr/local/denisoverlay/sci-chemistry/rasmol cp -rv /usr/portage/sci-chemistry/rasmol/* /usr/local/denisoverlay/sci-chemistry/rasmol/ tweak files in /usr/portage/sci-chemistry/rasmol to your heart's content. Add /usr/local/denisoverlay to the variable PORTDIR_OVERLAY in /etc/make.conf For example: PORTDIR_OVERLAY=/usr/local/denisoverlay -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] question about portage capabilities
On Sat, 18 Apr 2009 21:23:24 -0500 Paul Hartman paul.hartman+gen...@gmail.com wrote: ebuild /usr/portage/foo-bar/yourpkg-1.2.3.ebuild unpack ebuild /usr/portage/foo-bar/yourpkg-1.2.3.ebuild prepare ebuild /usr/portage/foo-bar/yourpkg-1.2.3.ebuild configure ebuild /usr/portage/foo-bar/yourpkg-1.2.3.ebuild compile ebuild /usr/portage/foo-bar/yourpkg-1.2.3.ebuild preinst ebuild /usr/portage/foo-bar/yourpkg-1.2.3.ebuild install ebuild /usr/portage/foo-bar/yourpkg-1.2.3.ebuild postinst One doesn't need to perform these steps explicitly; when one performs a command like merge, ebuild also performs all commands that normally precede merge. So I think that if he wants to tweak the source code before compiling, the easier way would be to issue a unpack command, tweak the source, then issue a merge command. But I think it would be much better to write a patch, or simply modify the distfile and create a new ebuild that uses the modified distfile. -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] Re: Does -Wl,--hash-style=gnu need a full world rebuild?
On Mon, 13 Apr 2009 10:57:37 -0400 ABCD en.a...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jorge Morais wrote: I want these two flags (--as-needed and --hash-style=gnu) to be active before I adopt GCC 4.3 and recompile world. Just as an FYI, you do not need to rebuild the world when you upgrade GCC - the only time this was needed was around the GCC 3.3 to 3.4 transition, because of a one-time ABI breakage. By the way, binaries linked with --as-needed are compatible with binaries linked without it, yes? The --as-needed flag simply tells the linker to be more selective about which libraries to link against -- it does not change anything about the format, etc. of the library itself (to be precise, using --as-needed will cause only the NEEDED entries that are actually needed to be emitted to the final binary). So, to answer your question, yes, they are perfectly compatible with each other. From http://www.gentoo.org/proj/en/qa/asneeded.xml#doc_chap2 Note: While applying patches to libraries to fix --as-needed support, it is usually not the case to apply a revision bump: those who don't want to use the flag don't need to rebuild the library. For this reason, those who want to use --as-needed are invited to run an emerge -e world so that libraries are rebuilt. This suggests that, to be safe, I should activate --as-needed only *after* the next world compilation. -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] KDE 4.2.1 : the undead has been killed
On Monday 13 April 2009 20:49:44 Philip Webb wrote: 090413 Philip Webb wrote: I've found out how to fix it: something is starting Plasma, so Htop to the rescue ! -- kill Plasma the hideous mask is removed -- it appears at the very end of the KDE start-up process -- the handsome KDE 3 desktop backgrounds reappear together with the desktop menus called up by mouse clicks. I didn't find out what was starting Plasma, but I fixed it : 'cd /usr/bin; mv plasma plasma-aside'. back to normal ! (clutches garlic, crucifix, incense ... ) Why invoke the supernatural when common logic is so superior? emerge -C plasma emerge --depclean Is it a good idea to tell people to run emerge -C? emerge --depc atom is dependency-aware. -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] burning HD mpeg4 to dvd
On Fri, 17 Apr 2009 13:43:35 -0600 Joseph syscon...@gmail.com wrote: Does anybody have any links, instructions, information etc. on how to burn HD video MPEG4 to DVD? I want to be able to play HD on TV and I don't want to reduce the quality. Do I need Blue-Ray dvd recorder to be able to play HD recording? Can standard DVD play HD mpeg4 files? I don't know, but I highly doubt that a DVD player can play a 1920x1080 file. The best way to be sure is to read the device manual. I have new camera that records HD (1920x1080) mpeg4 movies, most files are below 3GB; is there a way to burn them into standard DVD on Linux. I'm familiar with standard MPEG2 format and burning but not HD MPEG4.. Please provide more information. I *assume* that you have a dvd-recorder driver in your computer and a Blu-Ray player on top of your TV. If that is the case, 1) I would try some blu-ray authoring tool; presumably, such a tool would generate a .iso file intended to be recorded to a Blu-Ray media. I would record that .iso to a DVD media. I guess it would work. But to be sure it would work, I would 2) Read the device manual. If you don't have a Blu-Ray player, but only a normal DVD player, I think it is very unlikely you will be able to play a 1920x1080 file with it. -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] /etc/portage/package.keywords syntax
On Wed, 15 Apr 2009 08:47:29 +0200 Justin jus...@j-schmitz.net wrote: Thanasis schrieb: on 04/14/2009 11:09 PM Neil Bothwick wrote the following: On Tue, 14 Apr 2009 16:01:23 +0300, Thanasis wrote: Suppose I want to set the series of kernel sources: gentoo-sources-2.6.28* with the ~x86 keyword. What should I write in /etc/portage/package.keywords ? ~sys-kernel/gentoo-sources-2.6.28 ~x86 or, if you are running x86, ~sys-kernel/gentoo-sources-2.6.28 What is the meaning of the ~ in front ? Is it documented? same as =...2.6.28* but I disagree with the second suggestion, because no keyword means any keyword. You both should read the manual. I have copied some excerpts from relevant man pages, and even surrounded the most relevant parts with the word MYEMPHASIS. Not everyone has this patience. From man portage: package.keywords Per-package KEYWORDS. Useful for mixing unstable pack- ages in with a normally stable system or vice versa. This will allow ACCEPT_KEYWORDS to be augmented for a single package. Format: - comment lines begin with # (no inline comments) - one DEPEND atom per line followed by additional KEYWORDS MYEMPHASIS - lines without any KEYWORDS imply unstable host arch /MYEMPHASIS Example: # always use unstable libgd media-libs/libgd ~x86 # only use stable mplayer media-video/mplayer -~x86 # always use unstable netcat net-analyzer/netcat Note: In addition to the normal values from ACCEPT_KEYWORDS package.keywords supports three special tokens: * package is visible if it is stable on any architecture ~* package is visible if it is in testing on any architecture ** package is always visible (KEYWORDS are ignored completely) Additional Note: If you encounter the -* KEYWORD, this indicates that the package is known to be broken on all systems which are not otherwise listed in KEYWORDS. For example, a binary only package which is built for x86 will look like: games-fps/quake3-demo-1.11.ebuild:KEYWORDS=-* x86 If you wish to accept this package anyways, then use one of the other keywords in your package.keywords like this: games-fps/quake3-demo x86 From man 5 ebuild: DEPEND This should contain a list of all packages that are required for the program to com- pile. DEPEND Atoms A depend atom is simply a dependency that is used by portage when calculating relationships between packages. Please note that if the atom has not already been emerged, then the latest version available is matched. Atom Bases The base atom is just a full category/packagename. Hence, these are base atoms: sys-apps/sed sys-libs/zlib net-misc/dhcp Atom Versions It is nice to be more specific and say that only certain versions of atoms are acceptable. Note that versions must be combined with a prefix (see below). Hence you may add a version number as a postfix to the base: sys-apps/sed-4.0.5 sys-libs/zlib-1.1.4-r1 net-misc/dhcp-3.0_p2 Versions are normally made up of two or three numbers separated by peri- ods, such as 1.2 or 4.5.2. This string may be followed by a character such as 1.2a or 4.5.2z. Note that this letter is not meant to indicate alpha, beta, etc... status. For that, use the optional suffix; either _alpha, _beta, _pre (pre-release), _rc (release candidate), or _p (patch). This means for the 3rd pre-release of a package, you would use something like 1.2_pre3. The suffixes here can be arbitrarily chained without limitation. Atom Prefix Operators [ = = = ] Sometimes you want to be able to depend on general versions rather than specifying exact versions all the time. Hence we provide standard bool- ean operators: media-libs/libgd-1.6 =media-libs/libgd-1.6 =media-libs/libgd-1.6 =media-libs/libgd-1.6 media-libs/libgd-1.6 Extended Atom Prefixes [!~] and Postfixes [*] Now to get even fancier, we provide the ability to define blocking pack- ages and version range matching. Also note that these extended pre- fixes/postfixes may be combined in any way with the atom classes defined above. Here are some common examples you may find in the portage tree: !app-text/dos2unix =dev-libs/glib-2* !=net-fs/samba-2* ~net-libs/libnet-1.0.2a !!sys-apps/portage-2.1.4_rc1 ! means block packages from being installed at the same time. !! means block packages from being installed
Re: [gentoo-user] KDE 4.2.1 : goodbye good riddance
On Tue, 14 Apr 2009 09:56:20 -0700 Mark Knecht markkne...@gmail.com wrote: While not a KDE user I echo your thoughts. I'm personally a bit worried about Gentoo overlords sort of pushing this hald thing with reasons like 'Gnome's automounting depends on it'. Where have you got that from? I have not heard of that. I don't use hal either, and I have -hal in /etc/make.conf I started in Linux about 12 years ago and the best environment for my needs at that time (audio recording, 32 channels of live audio, real-time kernels, Ardour, etc.) was fluxbox. Low overhead. Easily customizable. Every time I get fed up with Gnome I go back to fluxbox. Takes a few minutes to build, not hours like Gnome or days like KDE. Not a great environment for my wife and kids, so they get Gnome. I have used Xfce at version 4.4.2 (or 4.4.3, I don't remember) and I think it has a lot of user-friendliness. And it is even similar to GNOME, so GNOME users will feel at home. I think Xubuntu is a good example of a well put together Xfce desktop. I don't agree with every Xubuntu choice for default apps, but it is a great start if you want to build a user-friendly, lightweight, customizable desktop with Xfce plus the right applications. So if you like simplicity and lightweight, but think your wife won't like fluxbox, give Xfce a try. Maybe even fluxbox could be configured and combined with the right applications to be easy to use, but starting with Xfce would probably be much easier (I say probably because I have never performed either of these tasks). On the other hand, maybe you should continue giving GNOME to your wife simply because GNOME is much more common than Xfce and, by knowing GNOME, she is more likely to know how to use another GNU/Linux computer, and if she needs technical support from, say, the ISP, the technicians are more likely to know GNOME and Xfce. For the record, I have moved from Xfce to LXDE because I am a speed freak and also a simplicity freak. More on simplicity below. I hope the future of Linux desktops doesn't look anything like Windows. Sometimes it seems to me we're moving too far that direction too fast. I get that feeling too. When I use Ubuntu and something fails, sometimes I feel it is hard to diagnose and fix the problem. Maybe this is the cost of things being automagic: when it works, great, but when it doesn't work, you've got to be a wizard to fix it. Car analogy: A person with mediocre knowledge of car mechanics can understand how a classical car works, and doesn't complain that the transmission is manual. He can even fix simple problems. A person with good knowledge of car mechanics can even fix more serious problems, because the car is simple, and many of its parts can be serviced by an interested man. But a modern car... With all of its automatic transmission and everything, one does not even need mediocre knowledge to drive it; but to understand how it works is hard. To fix simple problems is harder. To fix serious problems, one needs complex tools and specific knowledge that is almost beyond the reach of the common man. So I think that automagic things often tend to be harder to understand and much harder to fix. But so far, Ubuntu is actually *more* automagic than Windows but more open, easier to understand and easier to fix (Windows is a badly documented black box). And a Gentoo desktop is easier to understand and fix than Ubuntu. Specially if the user selected simple software such as Xfce or, even simpler, LXDE. Of course, you can theorize that at least part of this impression of mine is caused by me being used to my simple no-hal no-nothing LXDE Gentoo desktop and me being unfamiliar with Ubuntu. Regards, Jorge -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] Re: Does -Wl,--hash-style=gnu need a full world rebuild?
On Mon, 13 Apr 2009 13:22:39 +0300 Nikos Chantziaras rea...@arcor.de wrote: Jorge Morais wrote: Hi. According to discussion on gentoo-dev http://archives.gentoo.org/gentoo-dev/msg_50182554f851bedb82f8a349fbc90352.xml it seems the only reasons for -Wl,--hash-style=gnu not being default (yet) are these headaches for the developers: 1) Apparently it does not work on mips 2) Apparently it needs =glibc-2.5 and =binutils-2.17.50.0.2 My PC is x86 and my toolchain is obviously more recent than these old verions, so apparently the flag is completely safe. I've enabled it in /etc/make.conf and I like the slight reduction in binary size. My main question is: Can I just compile new packages with this flag, or do I need to recompile the whole world? In other words, is there any incompatibility between binaries linked with this flag and binaries linked with the default hash-style (which in Gentoo is --hash-style=both, AFAIK)? No, there's no need to rebuild everything since the older binaries have GNU-style hash too and there's no problem. Also, rebuilding anyway in order to gain something is not really recommendable; we're talking a few kilobytes here, *so* not worth the effort. OK, thank you very much. Hum, and to be pedantic, not all other binaries have GNU-style hash, since some are probably older than the introduction of --hash-style=both in Gentoo. And thinking about it, the fact that the devs silently introduced --hash-style=both by default offers some evidence that this kind of linker flag does not lead to incompatibilities. And next I am going to use --as-needed. From bug 129413, it seems to be very close to be ready for general use. And many people seem to be using it without any problems (and many begun many months or even years ago, when the packages were not as --as-needed ready as they are now.) So, for a guy prepared to look at bug 129413 and compare all the bugs with the software installed in his computer (should be quite easy to automate) it should be very safe. I want these two flags (--as-needed and --hash-style=gnu) to be active before I adopt GCC 4.3 and recompile world. By the way, binaries linked with --as-needed are compatible with binaries linked without it, yes? -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] Re: Does -Wl,--hash-style=gnu need a full world rebuild?
On Mon, 13 Apr 2009 10:57:37 -0400 ABCD en.a...@gmail.com wrote: Jorge Morais wrote: I want these two flags (--as-needed and --hash-style=gnu) to be active before I adopt GCC 4.3 and recompile world. Just as an FYI, you do not need to rebuild the world when you upgrade GCC - the only time this was needed was around the GCC 3.3 to 3.4 transition, because of a one-time ABI breakage. I think I read in the Gentoo GCC upgrade guide that there is also ABI incompatibility between GCC 3.4 and GCC 4.1 Weirdly, the page http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html seems to indicate that at least the libstdc++.so library has been forward compatible since GCC 3.4. Anyway, thank you for your information (which I had already heard), but nevertheless I think it would be a good idea to recompile world after all these years of upgrading packages, changing USE flags, upgrading the toolchain ... I think recompiling world would lead to a more harmonious system. And it would benefit from the increased optimization abilities of GCC 4.3 (which I assume generates faster code than GCC 4.1; at least with my simple programs, it seems to generate better assembly code - I often check the generated assembly code of my programs through the flags -S -fverbose-asm) By the way, binaries linked with --as-needed are compatible with binaries linked without it, yes? The --as-needed flag simply tells the linker to be more selective about which libraries to link against -- it does not change anything about the format, etc. of the library itself (to be precise, using --as-needed will cause only the NEEDED entries that are actually needed to be emitted to the final binary). I already knew that (on a superficial way), but thank you for being helpful. So, to answer your question, yes, they are perfectly compatible with each other. Thank you. -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] Re: Can't figure out why emerage wants to build xscreensaver
On Fri, 10 Apr 2009 11:43:46 -0700 Nick Fortino nfort...@gmail.com wrote: Grant Edwards wrote: On 2009-04-10, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Fri, Apr 10, 2009 at 11:30 AM, Grant Edwards gra...@visi.com wrote: Is something broken in the xfce ebuilds? emerge keeps wanting to install xscreensaver even though I've got -xscreensaver in my USE variable in make.conf. Everytime I update, xscreensaver gets reinstalled, and I have to manually emerge -C it: # emerge -auvtND world These are the packages that would be merged, in reverse order: Calculating dependencies... done! [nomerge ] xfce-base/xfce4-4.4.3 USE=alsa cups oss -minimal -xscreensaver [nomerge ] xfce-base/xfce4-session-4.4.3 USE=dbus -debug -gnome [nomerge ] xfce-base/xfce-utils-4.4.3 USE=dbus lock -debug [ebuild N]x11-misc/xscreensaver-5.07 USE=jpeg opengl pam -new-login -suid -xinerama 0 kB It is because of the lock USE flag on xfce-utils. I think it uses xscreensaver for the screen-locking function. I see. An unpleasant side-effect is that the screensaver function keeps kicking in. I guess I'll remove the lock flag from xfce-utils. Oddly, I have the lock flag for xfce-utils on another similar system, and emerge doesn't think it needs xscreensaver on that system. Perhpas because I have xlockmore installed on that system? If you don't want a specific package, echo 'x11-misc/xscreensaver' /etc/portage/package.mask In this case, the dependency is: lock? ( || ( x11-misc/xscreensaver gnome-extra/gnome-screensaver x11-misc/xlockmore ) ) so either gnome-screensaver or xlockmore will be pulled in to compensate. Nick Instead of needlessly messing with package.mask, it is easier to just emerge -a1v x11-misc/xlockmore (supposing he wants xlockmore and not gnome-screensaver). Now the dependency will be satisfied by xlockmore and xscreensaver won't be pulled anymore. -- Software is like sex: it is better when it is free. --Linus Torvalds
[gentoo-user] Does -Wl,--hash-style=gnu need a full world rebuild?
Hi. According to discussion on gentoo-dev http://archives.gentoo.org/gentoo-dev/msg_50182554f851bedb82f8a349fbc90352.xml it seems the only reasons for -Wl,--hash-style=gnu not being default (yet) are these headaches for the developers: 1) Apparently it does not work on mips 2) Apparently it needs =glibc-2.5 and =binutils-2.17.50.0.2 My PC is x86 and my toolchain is obviously more recent than these old verions, so apparently the flag is completely safe. I've enabled it in /etc/make.conf and I like the slight reduction in binary size. My main question is: Can I just compile new packages with this flag, or do I need to recompile the whole world? In other words, is there any incompatibility between binaries linked with this flag and binaries linked with the default hash-style (which in Gentoo is --hash-style=both, AFAIK)? Regards, Jorge Morais
Re: [gentoo-user] Mythfrontend segfaults
On Sun, 12 Apr 2009 16:45:57 -0700 Mark Knecht markkne...@gmail.com wrote: On Sun, Apr 12, 2009 at 3:16 PM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 12 Apr 2009 16:33:06 -0500, Michael Sullivan wrote: This doesn't tell me anything as far as I can see. Is there another way to turn up verbosity? mythfrontend -v help -- Neil Bothwick Are you sure this isn't the time for a colorful metaphor? I did updates today on my AMD64 machine and mythfrontend is segfaulting for me also. Not sure about the joystick stuff as I've never had a joystick. 2009-04-12 16:38:17.384 mythfrontend version: 0.21.20080304-1 www.mythtv.org 2009-04-12 16:38:17.384 Enabled verbose msgs: important general 2009-04-12 16:38:18.421 No theme dir: /home/mark/.mythtv/themes/Titivillus 2009-04-12 16:38:18.424 Primary screen 0. 2009-04-12 16:38:18.427 Running in a window 2009-04-12 16:38:18.427 Using screen 0, 1280x998 at 0,0 2009-04-12 16:38:18.429 No theme dir: /home/mark/.mythtv/themes/Titivillus 2009-04-12 16:38:18.430 Switching to square mode (Titivillus) 2009-04-12 16:38:18.491 Using the Qt painter 2009-04-12 16:38:18.491 JoystickMenuClient Error: Joystick disabled - Failed to read /home/mark/.mythtv/joystickmenurc Segmentation fault Frontend: m...@lightning ~ $ eix -Ic mythtv [I] media-plugins/gst-plugins-mythtv (0.10.6(0.10)@01/31/2009): plugin for gstreamer [I] media-tv/mythtv (0.21_p19961...@02/23/2009): Homebrew PVR project [I] x11-themes/mythtv-themes (0.21_p16...@02/01/2009): A collection of themes for the MythTV project. Found 3 matches. m...@lightning ~ $ Backend: Sector9 ~ # eix -Ic mythtv [I] media-tv/mythtv (0.21_p19961...@03/22/2009): Homebrew PVR project [I] x11-themes/mythtv-themes (0.21_p16...@04/02/2008): A collection of themes for the MythTV project. Found 2 matches. Sector9 ~ # I turned up verbosity but I don't think the response is all that helpful: 2009-04-12 16:43:30.350 MSqlQuery: SELECT keylist, description FROM keybindings WHERE context = 'Global' AND action = '8' AND hostname = 'lightning' ; 2009-04-12 16:43:30.352 MSqlQuery: SELECT keylist, description FROM keybindings WHERE context = 'Global' AND action = '9' AND hostname = 'lightning' ; 2009-04-12 16:43:30.355 MSqlQuery: SELECT data FROM settings WHERE value = 'QtFonTweak' AND hostname = 'lightning' ; 2009-04-12 16:43:30.356 MSqlQuery: SELECT data FROM settings WHERE value = 'QtFonTweak' AND hostname IS NULL; 2009-04-12 16:43:30.359 MSqlQuery: SELECT data FROM settings WHERE value = 'HideMouseCursor' AND hostname = 'lightning' ; Segmentation fault m...@lightning ~ $ The big change here today, other than the updates, was to rename xorg.conf to xorg.conf.old and reboot to try out lett hald set up the video stuff. I'm suspecting that may be the culprit? - Mark Have you looked at this bug? http://bugs.gentoo.org/show_bug.cgi?id=265868 Can any of you provide a backtrace? -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] Should we disable FORTIFY_SOURCE for packages where it is not default?
On Fri, 10 Apr 2009 14:55:36 +0200 Peter Alfredsen loki_...@gentoo.org wrote: I have seen some FORTIFY_SOURCE bugs in the bugzilla and in some cases, people claim the the bug lies in the FORTIFY_SOURCE feature itself (that is, people claim that FORTIFY_SOURCE misidentifies a buffer overflow). One example: http://bugs.gentoo.org/show_bug.cgi?id=257016 Very rare, but it happens. I have installed GCC-4.3.3 (but have not enabled it through gcc-config yet), but my system is otherwise mostly stable. 1) I would like to use GCC-4.3.3 because it is the latest bugfix release and is presumably more bug-free (correct?). So far, yes. Especially users of -march=amdfam10 flag want this version. Thank you. And do you know of any other new behavior from GCC-4.3.2 to GCC-4.3.3 aside from FORTIFY_SOURCE and warning options such as -Wformat? 2) But until FORTIFY_SOURCE is stable on Gentoo, I don't want it. How can I disable it? CXXFLAGS=-U_FORTIFY_SOURCE That's where most ebuilds will pick it up. Sorry to take your time, but CXXFLAGS? Isn't that for extra flags for the C++ compiler? Isn't the appropriate place CPPFLAGS (extra flags for the C preprocessor)? I even remember a Gentoo bug report in which someone criticized a user for putting a macro definition in CFLAGS, and said that certain ebuilds could fail because of it. Also, am I wise to use GCC 4.3.3 compiler in a mostly stable system? At the moment, we are only processing bugs about _FORTIFY_SOURCE when they can be confirmed on ~arch. As long as you're prepared to use package.keywords liberally, it should be mostly ok. A suggestion: with this kind of tracker (like bug 259417), don't you think it would be useful to have separate trackers for build-time bugs and run-time bugs? This way, users who want to test the new feature (GCC-4.3.3 and _FORTIFY_SOURCE in this case) can easily see if there are run-time bugs affecting them. Build-time bugs are much less worrisome for me. Well, this is a suggestion that seems convenient for users, but you obviously know fare more about Gentoo bug-squashing than me. Thank you for your time. -- Software is like sex: it is better when it is free. --Linus Torvalds
[gentoo-user] Should we disable FORTIFY_SOURCE for packages where it is not default?
From the info page of GCC 4.3.3 NOTE: In Gentoo, `-D_FORTIFY_SOURCE=2' is set by default, and is activated when `-O' is set to 2 or higher. This enables additional compile-time and run-time checks for several libc functions. To disable, specify either `-U_FORTIFY_SOURCE' or `-D_FORTIFY_SOURCE=0'. I have seen some FORTIFY_SOURCE bugs in the bugzilla and in some cases, people claim the the bug lies in the FORTIFY_SOURCE feature itself (that is, people claim that FORTIFY_SOURCE misidentifies a buffer overflow). One example: http://bugs.gentoo.org/show_bug.cgi?id=257016 I have installed GCC-4.3.3 (but have not enabled it through gcc-config yet), but my system is otherwise mostly stable. 1) I would like to use GCC-4.3.3 because it is the latest bugfix release and is presumably more bug-free (correct?). 2) But until FORTIFY_SOURCE is stable on Gentoo, I don't want it. How can I disable it? If I add -U_FORTIFY_SOURCE to CPPFLAGS (this would be the correct place to add it, right?), wouldn't it disable the feature for every package, even for those that specify FORTIFY_SOURCE on their own? I want the traditional behavior: packages that ask for FORTIFY_SOURCE get it, those that don't ask don't get it. And of course, do you know if FORTIFY_SOURECE has a significant performance cost and if it is really ready to be default (as in, it is unlikely for new false positives to appear)? Also, am I wise to use GCC 4.3.3 compiler in a mostly stable system? -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] revdep-rebuild quits at 21%
On Tue, 7 Apr 2009 09:12:30 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: I wish I could provide more information, the cursor just seats there, there is no error messages at the console. Which log revdep-rebuild writes to? I'm rebuilding the system with the old CFLAGS so I'll have more information tomorrow. I used -march=native but I think my AMD64 didn't like it :-/ It's possible that gcc got confused as to what cpu you have an it's abilities. If you still don't know what CFLAGS to use, post your /proc/cpuinfo here and someone is bound to know what works well. Alan, he already sent an email in another thread with his cpuinfo. Please see the thread with subject GCC-4.3.2 and see if you can help him. Regards, Jorge -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] GCC-4.3.2
On Mon, 6 Apr 2009 00:02:21 -0600 Joseph syscon...@gmail.com wrote: On 04/03/09 10:34, alain.didierj...@free.fr wrote: Has one of you guys already switched from gcc-4.1.2 to gcc-4.3.2 and performed emerge system ? What gives ? Any problem ? Is it worth it right now ? Please tell... -- ~adj~ I just notice that there is a problem with CFLAGS -march=native on AMD64 I recompile my system using this new flag and have a lot of problems. an examples new xorg-server-1.5... would not compile, I switch back to my previous settings: -march=athlon64 and it compiled on first pass. So, now I'm recompiling the system with my old flag: -march=athlon64 :-/ Have you filed a bug? Since in a later message you say that you are not sure of whether you should use -march=k8 or -march=k8-sse3, it seems that in your situation -march=native is interesting. -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] Re: Accidentally issued hdparm -X /dev/hda on running system
On Thu, 2 Apr 2009 11:23:55 +0200 Tom uebersh...@googlemail.com wrote: I have since fsck'ed all relevant partitions in /dev/hda and they came up clean. Am I safe? Hmm, I'd say yes. I mean, in what way should using hdparm really mess up your partitions or Filesystems in such a way, that they'd be beyond recovery?! I have been using the system and it seems fine. I still would like some hdparm guru to tell me the none of my data has been silently corrupted. Thank you for your attention. Cheers, Jorge -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] Re: Accidentally issued hdparm -X /dev/hda on running system
On Wed, 01 Apr 2009 07:00:21 +0300 Nikos Chantziaras rea...@arcor.de wrote: Jorge Peixoto de Morais Neto wrote: I then shut the computer down and I writing this from a liveCD. I do not even want to access the disk read only without knowing I have not messed up. So: does anybody know if hdparm -X /dev/hda is safe (on a running system...)? This setting, like most other hdparm commands, is just temporary. As soon as you reset the drive (happens during a reboot) all goes back to the defaults. I know it is temporary. The problem is that I issued hdparm -X /dev/hda, and hda holds /, swap and everything. The system was in multiuser mode. I fear that the command could have messed up the hard disk, and caused data corruption. I have taken a look at the hdparm source code, and I see that hdparm -X /dev/hda is indeed equivalent to hdparm -X 0 /dev/hda But I still don't know if this is safe. I cannot continue to investigate the source code because it gets to an ioctl about which I know nothing (I think this would be a *lot* of research). I have since fsck'ed all relevant partitions in /dev/hda and they came up clean. Am I safe?
Re: [gentoo-user] emacs-common-gentoo-1[X] mask
On Sat, 28 Mar 2009 14:47:56 -0400 John P. Burkett burk...@uri.edu wrote: Starting March 14, whenever I have tried doing emerge -D -uav system the response has included !!! All ebuilds that could satisfy =app-emacs/emacs-common-gentoo-1[X] have been masked. On my x86 box, the response adds - app-emacs/emacs-common-gentoo-1.0 (masked by: ~x86 keyword) On my amd64 machine, the equivalent line is - app-emacs/emacs-common-gentoo-1.0 (masked by: ~amd64 keyword) The dependency listing is as follows: (dependency required by app-editors/emacs-22.3-r2 [installed]) (dependency required by app-emacs/po-mode-0.17 [installed]) (dependency required by sys-devel/gettext-0.17 [installed]) (dependency required by sys-devel/gcc-4.1.2 [installed]) (dependency required by system [argument]) [..] I'm not sure whether it would be safer to (a) emerge a masked version of emacs-common-gentoo-1.0 or to (b) alter the dependency structure, eliminating the requirement for emacs-common-gentoo-1.0. Further, I am not sure how to do either one. Suggestions would be much appreciated. Looking at /usr/portage/app-editors/emacs/emacs-22.3-r2.ebuild, I see that it depends unconditionally on app-emacs/emacs-common-gentoo. You cannot eliminate this dependency by changing USE flags. The most natural solution is to tell Portage to accept the package app-emacs/emacs-common-gentoo, even though it is not officially stable. To learn how to do this, read the portage man page and look for package.keywords. For quick, cake recipe instructions: 1) If there is a file named package.keywords in /etc/portage, add to it the line app-emacs/emacs-common-gentoo 2) If there is a directory named package.keywords in /etc/portage, you can create a file in it (the name of this file is irrelevant), and add to this file the line app-emacs/emacs-common-gentoo If there is already some file in /etc/portage/package.keywords, then, at your option, you can either edit this file and add to it the line app-emacs/emacs-common-gentoo or you can create a new file with this line. -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] emacs-common-gentoo-1[X] mask
Looking at /usr/portage/app-editors/emacs/emacs-22.3-r2.ebuild, I see that it depends unconditionally on app-emacs/emacs-common-gentoo. You cannot eliminate this dependency by changing USE flags. The most natural solution is to tell Portage to accept the package app-emacs/emacs-common-gentoo, even though it is not officially stable. To learn how to do this, read the portage man page and look for package.keywords. For quick, cake recipe instructions: 1) If there is a file named package.keywords in /etc/portage, add to it the line app-emacs/emacs-common-gentoo 2) If there is a directory named package.keywords in /etc/portage, you can create a file in it (the name of this file is irrelevant), and add to this file the line app-emacs/emacs-common-gentoo If there is already some file in /etc/portage/package.keywords, then, at your option, you can either edit this file and add to it the line app-emacs/emacs-common-gentoo or you can create a new file with this line. Thank you very much for your prompt, clear, and comprehensive response. Your suggestion solved the problem. Best regards, John You are welcome. I forgot to stress something: after some version of app-emacs/emacs-common-gentoo at least as recent as 1.0 becomes stable, you may want to remove the line app-emacs/emacs-common-gentoo from the file you have edited, so that Portage will go back to its normal behavior of seeking stable versions of the package. Anyway, using a testing (not officially stable) version of a single, simple package is unlikely to lead to problems. I prefer to use stable, tested package versions in my system, but one small exception for a small and simple package is harmless. -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] linux boot logo in 2.6.29-gentoo sources
On Fri, 27 Mar 2009 11:48:22 -0400 Eric Martin freak4u...@gmail.com wrote: Also, the kernel is the last place that you want to drag your feet for updates. If there's a bug in the kernel I want to have it fixed asap. Granted you can also argue that I'm injecting buggy code. It's two sides of the same coin. Come on, that is what bugfix releases are for. Gentoo-sources is patched for bugs. I prefer to use vanilla-sources, so I rely on upstream's bugfix releases. Currently I use 2.6.27.21. I will stop using 2.6.27.x when a later version becomes gentoo-stable, and either 1) upstream stops bugfixing 2.6.27 2) 2.6.27 lacks a feature I want 3) 2.6.27 becomes so old that I fear it might be incompatible with the rest of Gentoo. Probably 1 or 2 will happen much earlier than 3. PS: I of course know that sys-kernel/vanilla-sources-2.6.27.21 is currently ~x86, but my rationale is that 2.6.27 is Gentoo-stable, and I want the latest bugfix release from the stable release family I am using. I don't know why, in the case of the 2.6.27.x version, the Gentoo kernel team is taking so long to stabilize the latest bugfix release. PS2: If something I said sounds strange, remember English is my second language. -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] linux boot logo in 2.6.29-gentoo sources
On Wed, 25 Mar 2009 22:50:46 +0200 Thanasis thana...@asyr.hopto.org wrote: Has anyone seen the boot logo in 2.6.29-gentoo sources? usr/src/linux/drivers/video/logo/logo_linux_vga16.ppm Why did they substitute the penguin with this ugly disguised mouse? If you had upgraded because of a needed feature, I assume you would have read about the release, and thus would know about Tuz. So you upgraded to a ~arch kernel without any need. Why? -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] linux boot logo in 2.6.29-gentoo sources
On Fri, 27 Mar 2009 03:36:41 +0500 Mike Kazantsev mike_kazant...@fraggod.net wrote: On Thu, 26 Mar 2009 19:13:38 -0300 Jorge Morais please.no.spam.h...@gmail.com wrote: If you had upgraded because of a needed feature, I assume you would have read about the release, and thus would know about Tuz. So you upgraded to a ~arch kernel without any need. Why? The question is probably not adressed to me, but... It's still a way to check out these new features hands-on :) It's a kernel. And while it's ~arch on gentoo, it's actually marked 'stable' by developers, and, since gentoo ebuild does pretty much nothing but unpacking it, it should be pretty much as stable as any non-~arch package. Even if it already released, it has a higher chance of bugs than a more established kernel. Waiting for the package to become stable on Gentoo is not just about ebuild bugs; it is also about waiting for enough users in general to test the upstream package, and Gentoo users in particular to test the package within Gentoo. And I don't know about the usual quality of brand new Linux releases, but in general, I believe upstream developers want to release early (to get testers and updated contributions), while a distribution may wait until the software is ready and tested. Of course, if you want to actively help, that is a reason to test the latest software... but I am afraid that a kernel bug could lead to unpredictable behavior, data loss and other problems I can't tolerate. Also, I think a kernel has a higher chance of hidden bugs (bugs that don't stand in your face). I think that if you want to contribute as a tester it is easier to test a beta version of mplayer or Firefox (backup your bookmarks!), for example, where bugs are more visible and likely less harmful. Cheers, Jorge -- Software is like sex: it is better when it is free. --Linus Torvalds
Re: [gentoo-user] glibc update
On Wed, 18 Mar 2009 23:49:12 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: msoul...@anton:~$ equery belongs /usr/include/linux/quota.h [ Searching for file(s) /usr/include/linux/quota.h in *... ] sys-kernel/linux-headers-2.6.23-r3 (/usr/include/linux/quota.h) ul...@anton:~$ uname -a Linux anton 2.6.25-gentoo-r8 #9 Sun Nov 23 19:14:08 EST 2008 i686 AMD Athlon(tm) XP 1700+ AuthenticAMD GNU/Linux So slightly off but compatible. At some point a newer glibc would simply fail to build if it's incompatible then, I assume? It is as close to guaranteed to build as you are ever going to get. The public interface to the kernel via it's headers simply does not change in incompatible ways. But if it ever did, then yes, glibc would fail to build This was a doubt of mine. One of the reasons I prefer to use a stable kernel is that I don't know if, when using a newer (and ~x86) kernel, I should also use the corresponding linux-headers version. So you say I can be 99.999% sure that, should I update my kernel (say, to 2.6.28) and meet problems, those will be intrinsic to this kernel version (and possibly to incompatibilities with things like out-of-tree kernel modules), but never because the kernel headers are outdated? IOW, the only real problem of using outdated kernel headers is not fully taking advantage of new features? I prefer to use stable software anyway, but it is important to know.
