Re: [gentoo-dev] net-im/aim masked for removal
On Wednesday 02 August 2006 16:12, Enrico Weigelt wrote: > * Donnie Berkholz <[EMAIL PROTECTED]> schrieb: > > I've masked net-im/aim, AOL's proprietary offering. It hasn't seen a > > release in years, it's binary-only, and it's far less capable than any > > other client out there. > > BTW: could be introduce an separate (optional) masking method > for such proprietary stuff ? > I believe (don't have time to check right now) you'll want to look into ACCEPT_LICENSE -- # # electronerd, the electronerdian from electronerdia # pgp8QFgybgbNl.pgp Description: PGP signature
Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
On Wednesday 12 July 2006 14:36, Steve Dibb wrote: > Well, it could happen while testing an ebuild. :) I'd be pretty ticked > if I were testing Qt and I didn't realize they did change the doc files > around before doing a test run. > > Besides that though, imho, a simple function with a boolean return type > shouldn't kill the script executing it. Throw a warning, yes, but not > stop everything. Then you could have a IM_TESTING_STUFF_DONT_DIE_ON_DODOC variable to override the die or something -- # Just a user; my opinion doesn't matter here... # electronerd, the electronerdian from electronerdia # pgpVCaHEjVfru.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Monday 05 June 2006 23:13, Harald van Dijk wrote: > On Tue, Jun 06, 2006 at 01:48:37AM -0400, Mike Frysinger wrote: > > On Tuesday 06 June 2006 01:31, Harald van Dijk wrote: > > > On Tue, Jun 06, 2006 at 12:07:42AM -0400, Mike Frysinger wrote: > > > > On Monday 05 June 2006 21:23, Chris Gianelloni wrote: > > > > > On Mon, 2006-06-05 at 18:03 +0200, Stefan Schweizer wrote: > > > > > > -oss - oss is a legacy audio interface that has been superseeded > > > > > > by alsa in most current installs, a default use flag is no longer > > > > > > needed > > > > > > > > > > There are *many* applications in the tree that do not use ALSA, but > > > > > work only via the OSS emulation. Removing this is a bad idea and > > > > > it would definitely be blocked by the games team. Probably half of > > > > > the packages that I maintain require OSS capabilities. > > > > > > > > do we really need the USE flag though ? i was under the impression > > > > that you need to enable the OSS compat layer in the kernel and that's > > > > enough ... and the USE flag doesnt affect kernel build options ... > > > > > > It depends on whether you use the kernel drivers or the alsa-driver > > > package, I think. > > > > you dont use alsa-driver with 2.6 kernels and the 2006.1 profiles are 2.6 > > based > > You can use alsa-driver with 2.6 kernels. I use alsa-driver with 2.6 kernels. I forget exactly why (this was almost two years ago), but I actually switched _away_ from the in-kernel-tree drivers to alsa-driver for some particular reason. I have the oss useflag turned off, and then turned back on for alsa-driver in package.use. -- # # electronerd, the electronerdian from electronerdia # pgpa5PBuL3EH2.pgp Description: PGP signature
Re: [gentoo-dev] Signing everything, for fun and for profit
On Friday 19 May 2006 08:17, Chris Bainbridge wrote: > On 19/05/06, Andrew Gaffney <[EMAIL PROTECTED]> wrote: > > Chris Bainbridge wrote: > > > It is a single signature across the entire portage tree. It means that > > > after rsync emerge can check the signature against the retrieved tree > > > to validate the whole tree (or overlay). > > > > This idea has been brought up before and shot down. Signing the whole > > tree does not work, since we allow users to only sync parts of the tree. > > We do? What option to emerge enables this behaviour? RSYNC_EXCLUDES is the name, IIRC... -- # # electronerd, the electronerdian from electronerdia # pgp9semJpQyl7.pgp Description: PGP signature
Re: [gentoo-dev] KDE, metapackages, and monolithic packages
On Saturday 25 February 2006 10:33, Mike Myers wrote: > emerge --newuse kde-meta use also '--deep'. Also, consider using 'world' as the target Also, you don't have to unmerge packages before re-merging them. -- # # electronerd, the electronerdian from electronerdia # pgpT4o3hhtfsQ.pgp Description: PGP signature
Re: [gentoo-dev] Re: /etc/rc.conf
On Monday 13 February 2006 14:24, Forrest Voight wrote: > What happens if two env.d files set the same variable? AFAIK, the env.d files processed in lexicographic order, and later entries override earlier ones, except for certain variables (such as PATH) which are added to instead. -- # # electronerd, the electronerdian from electronerdia # pgpZbycadNUR0.pgp Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml
On Monday 26 December 2005 16:11, Marcelo Góes wrote: > ``maintainer`` can contain the tags ``name`` and ``email``, indicating the > person/organization responsible for upstream maintainership of the package. What if upstream is more than one person, but less than an organization? What if there is more than one upstream such as for gentoo-sources, where the maintainer of each of the patchsets could be considered an upstream? > ``remote-id`` should specify a type of package identification tracker and > the identification that corresponds to the package in question. > ``remote-id`` should make it easier to index information like its > identification in freshmeat or its cpan identification. if this is to be subject to automated processing, shouldn't there be a registry of valid "type" values maintaining a definition of what the value of the element corresponds to for each type? -- # # electronerd, the electronerdian from electronerdia # pgpq3TIE8wSKi.pgp Description: PGP signature
Re: [gentoo-dev] X.Org 7.0 Release
On Friday 23 December 2005 16:29, Donnie Berkholz wrote: > I've been meaning to get it into guidexml and make it a real project doc > for a while now (and the accompanying porting guide), but haven't had > time. Anybody who wants to help out by doing this is quite welcome to do > so. > Here's one I smashed together just now: -- # # electronerd, the electronerdian from electronerdia # Migrating to Modular X HOWTO Donnie Berkholz Joshua Baergen This guide shows you how to migrate to modular X.Org ? ? Migrating to Modular X Introduction To keep old packages from getting in the way, we're going to clean out all the old xorg-x11 cruft before installing modular X. This isn't absolutely crucial, but it will help ensure a smooth migration. First step: clean out your old X Before you start, make sure you have a package of the old, monolithic xorg-x11 built with USE=dlloader if the dlloader flag was available in that version. It's not available in >=6.8.99.15. # emerge gentoolkit # quickpkg xorg-x11 Get rid of the monolithic installation: # emerge -Ca xorg-x11 # rm -rf /usr/lib/opengl/xorg-x11 # rm -rf /usr/lib/libGL* You definitely want a backup copy of the monolithic xorg-x11 so you can mix and match parts if desired. The later steps are helpful in getting rid of symlinks created by opengl-update. If your /usr/X11R6 isn't a symlink to /usr, delete it and start from scratch. But first, save a list of all the packages installing there. # if [[ ! -L /usr/X11R6 ]]; \ then equery belongs /usr/X11R6 > usr-x11r6-packages \ && rm -rf /usr/X11R6; fi Second step: Installing modular X First, add the required packages to /etc/portage/package.unmask. Open /usr/portage/profiles/package.mask in your text editor of choice, then copy and paste the full modular X mask over to package.unmask. Do the same with package.keywords if you're running stable. For direct rendering, you'll want to activate the dri USE flag. Now, install the metabuild. This will install the server and popular applications, giving you a working desktop implementation of X: # emerge xorg-x11 Note that this install tries to be rather minimal, so things like xcursor-themes are not installed by default. Next, install some drivers. This will vary depending on your input and video hardware, so take a look in /usr/portage/x11-drivers/. Here's a sample: # emerge xf86-input-mouse xf86-input-keyboard xf86-video-ati With modular installed, external drivers such as nvidia-glx and wacom as well as some vnc apps may not work if they install things to /usr/lib/modules instead of /usr/lib/xorg/modules. Many of these will have modular X detection added to the installation process and thus will need to be re-merged after modular X install. Caveats/Common Problems 'emerge -u world' wants to install xorg-x11 This is because the tree isn't fixed for modular dependencies yet. You can help the porting effort by reading http://dev.gentoo.org/~spyderous/xorg-x11/porting_to_modular_x_howto.txt and filing bugs with patches to the individual package maintainers. The maintainers will be listed in metadata.xml in the same directory as the package, and the 'herdstat' package will speed up querying for them. Driver problems I've had reports that: ati won't start X But it works fine on my FireGL 8800 Resolved by moving /usr/lib/xorg/modules/multimedia out of the way vesa locks up box with an mga card vga produces a very weird-looking screen, divided into quarters Getting glxinfo/glxgears The best way to deal with this is undecided by upstream so far, so there's an ebuild in my overlay contributed by cardoe. Alternately, you can build them by hand. Option 1: http://dev.gentoo.org/~spyderous/overlay/x11-misc/glx-utils/ I'm not going to tell you how to use an overlay, so if you don't know and are too lazy to read the docs, use option 2. Option 2: Build by hand # emerge freeglut # tar zxvf /usr/portage/distfiles/Mesa-6.3.1.1.tar.gz # cd Mesa-6.3.1.1/configs # ln -s linux-dri-x86 current # cd ../progs/xdemos # make glxinfo # make glxgears # cp glxinfo glxgears /usr/bin/ To get some debugging info from glxinfo to help in getting direct rendering working: # LIBGL_DEBUG=verbose glxinfo Mouse protocol autodetection If you have Protocol "auto" set in xorg.conf for your mouse, it may not work. You may need to specify Protocol "ExplorerPS/2" or "IMPS/2" for your wheel to work. Where are imake/xmkmf? These are now in the tree. However, gccmakedep is not modularized yet and thus the imake build system is still broken for some packages. Everything in /usr/lib/xorg disappeared! Remerge >=xorg-server-0.99.1-r4. This was a temporary bug in the ebuild that resulted in deletion after removal of a package. Instead, /usr/lib/xorg should have only been deleted when no xorg-server rema
Re: [gentoo-dev] Optimizing performance
On Friday 23 December 2005 15:52, Diego 'Flameeyes' Pettenò wrote: > On Friday 23 December 2005 18:35, Paul de Vrieze wrote: > > Just to add. This is not so much related to debugging information in the > > library files (what gdb can use). That information never makes it from > > disk so is not that much of a speed issue (esp. if it is split out). > > Actually, if the binaries are not stripped, they consume more memory. > With splitdebug the issue is unseen (I'm happily using it with -g3 for > everything now..) But, as pauldv said, you still shouldn't USE=debug if you want speed -- # # electronerd, the electronerdian from electronerdia # pgp8Ow4AgbSnM.pgp Description: PGP signature
Re: [gentoo-dev] glep 42 (news) round six
On Saturday 17 December 2005 20:57, Ciaran McCreesh wrote: > On Sat, 17 Dec 2005 20:50:43 -0800 John Myers > > <[EMAIL PROTECTED]> wrote: > | GLEP 42 wrote: > | > * Before an ``emerge --ask `` sequence > | > | What, exactly, does this mean? I'm guessing it means between the > | package list and the prompt, but it's not quite clear. > > I dunno, I refuse to use emerge --ask for religious reasons. Feel free > to rewrite that bullet point. > How about * During ``emerge --ask``, the same as for ``emerge --pretend`` (i.e. after the package list) ? -- # # electronerd, the electronerdian from electronerdia # pgpdJu9AW28mK.pgp Description: PGP signature
Re: [gentoo-dev] glep 42 (news) round six
Not that my lowly user opinion matters, but I agree with ciaranm that repository IDs should not be allowed to contain spaces GLEP 42 wrote: > * Before an ``emerge --ask `` sequence What, exactly, does this mean? I'm guessing it means between the package list and the prompt, but it's not quite clear. Also, there's a typo in the last line of the "News Item Body" section: s/may/many/ -- # # electronerd, the electronerdian from electronerdia # pgplMBAjkKt00.pgp Description: PGP signature
Re: [gentoo-dev] Optimizing performance
On Thursday 15 December 2005 04:48, Patrick Lauer wrote: > Hi all, > > I was wondering if there are any sane ways to optimize the performance > of a Gentoo system. > Overoptimization (the well known "-O9 -fomgomg" CFLAGS etc.) tends to > make things unstable, which is of course not what we want. The "easy" > way out would be buying faster hardware, but that is usually not an > option ;-) > > So ... what can be done to get the stable maximum out of your hardware? This should be obvious, but don't USE=debug globally. Last time I did that, it made my Athlon64 3400+ with 1G of RAM feel like the 300MHz PII with 192M of RAM I have. -- # # electronerd, the electronerdian from electronerdia # pgpCQn0k0Wn8f.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sunday 11 December 2005 14:07, Diego 'Flameeyes' Pettenò wrote: > On Sunday 11 December 2005 22:57, Ciaran McCreesh wrote: > > You forgot d) a pain in the ass to parse, e) inconsistent with > > everything else, f) a pain in the ass to sort, g) massive overkill. > > I find ISO 8601 simple to sort Well, if you take the entire spec with all its variations, then ciaranm's points there are indeed correct (week number formats, day of the year formats, punctuationless formats, etc.) -- # # electronerd, the electronerdian from electronerdia # pgpizA6OEOzoY.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sunday 11 December 2005 13:19, Ciaran McCreesh wrote: > On Sun, 11 Dec 2005 04:57:23 -0700 Lares Moreau > | * Before an ``emerge --ask`` 'yes||no' response > > Does anyone really use emerge --ask? I do. Almost always in fact. When I want to install a package, I use --ask with --verbose so I get the --pretend output, and if I agree with the proposed list of dependencies and USE-flags, I allow it to proceed with just two keystrokes instead of having to go back up, change the command, and wait the extra time for it to recalculate the dependencies. Not a huge savings, but I do use it, and I would expect news items to be displayed right before the prompt where I can't miss them -- # # electronerd, the electronerdian from electronerdia # pgptDtCHOWvHW.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 "Critical News Reporting" Round Two
On Sunday 06 November 2005 13:38, Duncan wrote: > I don't believe the apache upgrade issues were announced on the announce > list. For the record, it was sent to the announce list on 2004-12-24. Message-Id: <[EMAIL PROTECTED]> Subject: [gentoo-announce] Apache packages refresh on 8th January 2005 pgpEpoIKfKkeT.pgp Description: PGP signature
Re: [gentoo-dev] GLEP ??: Critical News Reporting
[[ACK! I sent this out from the wrong address before. Hope you don't get it twice!]] On Thursday 03 November 2005 21:44, Nathan L. Adams wrote: > No, I happen to understand the that point. Emerge outputting a short > summary is great. But the GLEP should cover the "hey mr. end user, the > central repository for errata/full fledged migration guides is here: > [insert url]" as well. [snip] > I happen to think that the assumption that the errata are going to be > small is a bad one. I think if errata is neccessary in the first place > then its going to be something larger than a screen's worth of console > output and worth the supposed trouble of GuideXML. So why not approach > it from the GuideXML end first, and extract the summary from that? Here's an idea for a compromise solution. Sorry it's so messy: The errata entries would consist of two files per language: - An emerge news file, identical to the format ciaranm proposed. This file would give a very general notice of the issue, such as that given as an example in the GLEP, as well as containing the machine-readable commands for portage to control display. This file's name would end in .news..txt - A GuideXML-formatted errata document. This would be the actual migration guide, such as the contents of the http://www.gentoo.org/doc/en/yoursql-upgrading.xml referenced by the example. This file's name would end in .guide..xml - The leading part of the filename would be as in ciaranm's GLEP Once it is time for the errata item to be published (after review, etc.), the files would be placed in a standard location, where an automated process would pick them up. The news files would be transferred to the Portage tree for emerge to pick up, and simultaneously published to a central errata website, e.g. http://errata.gentoo.org/. On the errata website, *all* errata notices would be published to its front page, unless specified differently by each individual user (perhaps a feature storing filters in a cookie). Each entry in the list would contain at least the publication date, the title of the news item as a link to a news item page, and the title of the guideXML document as a link to the document. Errata items would be accessible in a uniform namespace with names derived from their source filenames. For example: 2005-11/2005-11-01-mysql-4.0-4.1-upgrade.news.en.txt 2005-11/2005-11-01-mysql-4.0-4.1-upgrade.guide.en.xml might become: http://errata.gentoo.org/2005-11-01-mysql-4.0-4.1-upgrade/en/ http://errata.gentoo.org/2005-11-01-mysql-4.0-4.1-upgrade/en/guide.xml For user convenience, URLs with language codes the text is not yet translated to, as well as URLs without a language code, should be redirected to the English version. Errata items may be published in other areas for wider exposure, but should always contain a link back to the main source. The news item page would contain a copy of the news text typeset in a fixed-width font, and with links made clickable, as well as a prominent link to the GuideXML document. The title of the page should be the title of the news item, and the title of the link to the GuideXML page should be the title of the GuideXML document. Questions? Comments? pgpHAcs3R8c1G.pgp Description: PGP signature
Re: [gentoo-dev] GLEP ??: Critical News Reporting
On Tuesday 01 November 2005 02:00, Thierry Carrez wrote: > Ciaran McCreesh wrote: > > Notification that new relevant news items will be displayed via the > > ``emerge`` tool in a similar way to the existing "configuration files > > need updating" messages: > > > > * Important: 3 config files in /etc need updating. > > * Type emerge --help config to learn how to update config files. > > > > * Important: there are 5 unread news items. > > * Type emerge --help news to learn how to read news files. > > Aren't those messages displayed after the damage is done ? Typical use : > > - emerge --sync run as a daily cron job > - emerge -a mysql > - great, a new version is there. Typing "Yes" > - system gets borken > - emerge spits out message saying 14 files need updating and there is 1 > unread news item > > I'm probably missing something here. Please elaborate on how this GLEP > meets the "Preemptive" design goal... The "configuration files need updating" messages also appear at the end of emerge sync Also, perhaps the news messages could be put at both ends of the emerge output? pgpIbDvAVqFTj.pgp Description: PGP signature
Re: [gentoo-dev] Reminder on dependencies.
On Tuesday 25 October 2005 07:09, Donnie Berkholz wrote: > Ciaran McCreesh wrote: > | On Mon, 24 Oct 2005 21:37:03 -0700 Donnie Berkholz > | > | <[EMAIL PROTECTED]> wrote: > | | Now, the other side of the story. It's not true runtime dependence > | | because it's not required for programs to run, only to compile. And > | | the way I see it, things required for programs to compile are by > | | definition DEPEND rather than RDEPEND. > | > | Not at all. If you've installed libfoo, one of the things you must be > | able to do is compile things that use libfoo. This sometimes means that > | libfoo would need a non-build-time dependency upon any libraries used > | by libfoo's header files. > > I disagree. You shouldn't expect to be able to compile things against it > unless all DEPENDs are installed. The whole point of DEPEND is to be > able to do things like this; remove all things not necessary for your > programs to run, not to compile. Perhaps, then, an additional dependency type would be useful? One that says "I may or may not need this for me to compile, Other programs definately need this to compile against me, and I don't necessarily need this to run" Let's call this CDEPEND, for the sake of example: package foo DEPENDs on bar, but does not CDEPEND or RDEPEND on it. bar CDEPENDs on baz, but does not DEPEND or RDEPEND on it. Scenario 1: 1) emerge bar - bar installed 2) emerge foo - baz installed - foo installed Scenario 2: 1) emerge foo - baz installed - bar installed - foo installed 2) "remove all compilation-only packages" - bar uninstalled - baz uninstalled 3) emerge bar - bar installed 4) emerge -u foo - baz installed - foo installed The pattern is that CDEPENDs of package fooquux are optional unless another package in the current dep list DEPENDs on fooquux. Only DEPEND would activate them, not RDEPEND or CDEPEND, so if fooquux needs a package in CDEPEND to compile, it must also specify it in DEPEND, and if it needs it at runtime, it must also specify it in RDEPEND. pgpnSCBPW3iKo.pgp Description: PGP signature
Re: [gentoo-dev] Suggestion: ebuilds linked to kernel upgrade
On Wednesday 19 October 2005 06:36, Henrik Brix Andersen wrote:
> On Wed, Oct 19, 2005 at 11:32:19AM -0200, Herbert G. Fischer wrote:
[snip]
> > - Patch kernel's "make" to warn at the end of "make modules_install"
[snip]
> I think you should check out sys-kernel/module-rebuild
Actually, a combination of these might not be a bad idea.
Something like this (not tested):
if [ -n "$(which module-rebuild 2>/dev/null)" ] ; then
if [ -n "${AUTO_MODULE_REBUILD}" ] ; then
echo "Rebuilding external modules:"
module-rebuild ${MODULE_REBUILD_OPTIONS} rebuild
else
echo "You might want to rebuild the following external modules:"
module-rebuild -XC list | tail -n +2
echo
echo "You can use module-rebuild to do that."
echo "If you want to have your external modules automatically rebuilt"
echo "when making a kernel's modules_install target, set"
echo "AUTO_MODULE_REBUILD in your environment. You can set"
echo "MODULE_REBUILD_OPTIONS to options to pass to module-rebuild."
echo "(-X for example)"
fi
else
echo "You might want to emerge sys-kernel/module-rebuild to keep track of"
echo "kernel modules you've installed with emerge"
fi
pgph1baGir1Oz.pgp
Description: PGP signature
Re: [gentoo-dev] Bugzilla Bug #109301 dev-db/mysql-4.1.14 stable request.
On Wednesday 19 October 2005 07:18, Petre Rodan wrote: > can anyone please check out if you can create a new user with the > 'deprecated' version and that you can actually use it in mysql-4.1.14? I > invariably got 'bad password for user ...'. What client version are you using? This sounds like it could be related to the new password crypto change, IIRC. pgphXBLzCctwG.pgp Description: PGP signature
Re: [gentoo-dev] New MySQL doc
On Monday 11 July 2005 21:38, Chris White wrote: > http://dev.gentoo.org/~chriswhite/mysql.html > > Comments, etc are welcome. Sorry for posting twice, but Code listing 4.11: REVOKE format is incorrect. It probably should say REVOKE [privleges] ON database.* FROM '[user]'@'[host]'; rather than PRIVLEGES [privleges] ON database.* FROM '[user]'@'[host]'; pgpBmcq6zi22G.pgp Description: PGP signature
Re: [gentoo-dev] New MySQL doc
On Monday 11 July 2005 21:38, Chris White wrote: > http://dev.gentoo.org/~chriswhite/mysql.html > > Comments, etc are welcome. You might want to make Code listing 4.19: Finding our guest user in the user table a little narrower, as it makes the page much wider than my 1,280 pixel wide screen can show. I would suggest SELECT Host, User, Password FROM user WHERE User = 'guest'; rather than SELECT * FROM user WHERE User = 'guest'; which will make the output much, much smaller. You might want to mention the other query in passing for the user to try on their own, however. pgpX5fWFA9EGF.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
On Tuesday 05 July 2005 02:39, Martin Schlemmer wrote: > Also as already asked, what about the chicken egg issue ... (think tar > needing tar, or gzip needing gzip to unpack)? The stages could come primed with the data that the packages on them are already installed. pgpyh0WySyPe7.pgp Description: PGP signature
Re: [gentoo-dev] i have an idea ! (erescue)
On Sunday 15 May 2005 16:41, david stanek wrote: > Add an option to emerge, --backup or something > similar, that will automatically run quickpkg. If you set FEATURES="buildpkg", portage automatically makes binary packages for you. No need to add new support. pgpqwMjzk44tL.pgp Description: PGP signature
Re: [gentoo-dev] Re: Cutting down on non-cascaded profiles
On Tuesday 03 May 2005 09:10, Chris Gianelloni wrote: > I think an easier solution would be a portage rescue set of profiles. > These would be minimal profiles not designed for actual use, but only > for performing a portage update for those people that lag too far > behind. The idea would be a very tiny profile, per arch, that is not > cascaded. Perhaps another solution would be to create a system with archives of the profiles and packages necessary to do an upgrade from an old portage and profile to a new portage and profile, seeing as portage has circular effective dependencies on at least the tree and python, perhaps other stuff as well. This could be some sort of script which downloads the archive, then upgrades, one major shift at a time. Once said system is in place, notices could be put in the deprecated files (and of course the homepage) to that effect, and the old profiles removed from the main tree after a while. Just a thought. --electronerd pgptovAAYBmCE.pgp Description: PGP signature
