Re: [gentoo-dev] PPC gets more help
* Homer Parker [EMAIL PROTECTED] [05/09/07 21:14 -0500]: The ppc team has found a new minion^W AT to help them out. Matti Bickel (mabi) has stepped up for abuse from JoseJX.. Please welcome him to the team! JoseJX, don't work him to hard! j/k, Where's the whip? ;) Damnit! Somebody else I know personally, but this time it wasn't my fault! Nice to see, that our ways cross for a second time, Matti, but some way down the road and in another area ;-) Regards, Lars PS: Can you suggest another planet? This one becomes too small... -- Lars Weiler [EMAIL PROTECTED] +49-171-1963258 Gentoo Linux PowerPC: Developer and Release Engineer Gentoo Infrastructure : CVS Administrator Gentoo Foundation : Trustee pgp2vUBhMfFPV.pgp Description: PGP signature
Re: [gentoo-dev] local USE flag gimp for xsane
On Mon, Sep 05, 2005 at 11:17:47AM -0400, Nathan L. Adams wrote: Or how about an xsane flag for GIMP that makes the xsane plugin a dependency. :) Sorry, I didn't get that joke - the result is bug #105192 :-/ Bye, Patrick pgp1vFczyZhJ8.pgp Description: PGP signature
[gentoo-dev] MySQL 4.0 = 4.1 upgrade
Please notice that MySQL-5.0 has been erroneously unmasked for few hours but it will return under the package.mask cover at next rsync. The MySQL herd is pleased to announce that Mysql 4.1 has been unmasked today and is now marked unstable. Hope that it's possible to stabilize it soon, here there is a upgrade path. .--- | propedeutic readings: http://dev.mysql.com/doc/mysql/en/upgrading-from-4-0.html http://dev.mysql.com/doc/mysql/en/news-4-1-x.html http://dev.mysql.com/doc/mysql/en/replication-upgrade-4-0.html .--- | Upgrade path: [[[ User with a old (4.0.24 ??) mysql start from here ]]] quickpkg dev-db/mysql cmd# emerge -av --buildpkg =mysql-4.0.25-r2 cmd# ebuild \ /var/db/pkg/dev-db/mysql-4.0.25-r2/mysql-4.0.25-r2.ebuild config # Insert some kind of data fex attached backup_mysql_4.0.sql.gz [[[ User with a recent version of mysql start from here ]]] cmd# mysqldump \ -uroot \ -p$PASSWORD \ -hlocalhost \ --all-databases \ --all \ --opt \ --allow-keywords \ --flush-logs \ --hex-blob \ --master-data \ --max_allowed_packet=16M \ --result-file=BACKUP_MYSQL_4.0.SQL # check the backup file, try one one load on a mysql-4.0 server cmd# /etc/init.d/mysql stop cmd# quickpkg dev-db/mysql cmd# rm -rf /var/lib/mysql/ [[[ Real upgrade start here ]]] cmd# emerge -C mysql cmd# rm -rf /var/lib/mysql/ /var/run/mysqld/ /var/log/mysql cmd# emerge -av --buildpkg =mysql-4.1.14 cmd# revdep-rebuild cmd# ebuild /var/db/pkg/dev-db/mysql-4.1.14/mysql-4.1.14.ebuild config cmd# /etc/init.d/mysql start cmd# cat backup_mysql_4.0.sql \ | mysql \ -uroot \ -p$PASSWORD \ -hlocalhost \ --max_allowed_packet=16M cmd# mysql_fix_privilege_tables \ --defaults-file=/etc/mysql/my.cnf \ --user=root \ --password=$PASSWORD cmd# /etc/init.d/mysql restart -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Fixing the TERM mess
| That'd also solve the cases where a terminal changes right beneath a | running application. That | happens during attaching a screen session. No it doesn't. Screen provides a virtual terminal with lots and lots of capabilities. It then reduces them itself internally to what it thinks the underlying term supports -- again, this is done via terminfo, so if you're running screen on xterm you're running a crippled screen. So, screen advertises the same capabilities to the starting apps regardless the terminal the screen is being run on? Or it advertises reduced capabilities according the terminal it's currently attached to? As for the former, I don't think that would work. If an app chooses a multi color style cuz screen is able to handle it, but then screen tries to reduce it to mono. And for the later, it'd work much better if terminal could pump its capabilities to the app at runtime, that is during reattachment. Would it be that hard to extend window resize or something? Ivan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Fixing the TERM mess
On Thu, 8 Sep 2005 18:50:10 +0200 ivan [EMAIL PROTECTED] wrote: | | That'd also solve the cases where a terminal changes right | | beneath a running application. That | | happens during attaching a screen session. | | No it doesn't. Screen provides a virtual terminal with lots and | lots of capabilities. It then reduces them itself internally to | what it thinks the underlying term supports -- again, this is done | via terminfo, so if you're running screen on xterm you're running a | crippled screen. | | So, screen advertises the same capabilities to the starting apps | regardless the terminal the screen is being run on? Yes. | Or it advertises reduced capabilities according the terminal it's | currently attached to? No. | As for the former, I don't think that would work. If an app chooses a | multi color style cuz screen is able to handle it, but then screen | tries to reduce it to mono. That's exactly what happens. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpbC94xaAzff.pgp Description: PGP signature
Re: [gentoo-dev] Comparing Openpkg with portage
Thanks for the response, I guess I'll post to the osx mailing list, but really my issue isn't about osx per se, but taking the osx portage port and making it run on any posix system (solaris, osx, flavors of linux etc) in a sandboxed environment. I've read through the developer documentation and didn't find anything there.Google hasn't necessarily been very useful either So, is it possible to sandbox a portage installation on top of say a debian or fedora install?If so, can anyone point me in the right direction? With current ebuilds, nope.There's no global prefix offset in thecode for it (root is merge offset, not runtime prefix offset). The osx port runs with the same ebuilds as the main portage tree right? Do any of the devs out here have experience with openpkg?Pretty much an extension of rpm spec's, afaik. Beyond that? Heh, nope :) The basic idea is you bootstrap an environment on an existing system, and then build rpm's on top of that. It would be nice to take advantage of Gentoo's larger component tree (openpkg has ~400 items) as well as the larger gentoo community.
Re: [gentoo-dev] USE=minimal for kernel sources
On Thursday 08 September 2005 20:10, solar wrote: Perhaps you can simply just take advantage of tar's --exclude=/-e options in the unpack() function of ebuild.sh when USERLAND == GNU tar --exclude/-e is supported by both bsdtar and gtar. -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpIHpeW69pzv.pgp Description: PGP signature
Re: [gentoo-dev] USE=minimal for kernel sources
For the record, there is a bug open for this. (#64009) Personally, I'm not keen on the idea. the only way which we can do this is by detecting which arch we are installing the sources, for, which immediately means many installs of USE=minimal are not the same. There are plenty of other reasons I can go into, but if anyone feels strongly to push this change, then feel free to reply with justification as to why. Technical info to back it up as well please :) - John On Thu, 2005-09-08 at 20:17 +0200, Diego 'Flameeyes' Pettenò wrote: On Thursday 08 September 2005 20:10, solar wrote: Perhaps you can simply just take advantage of tar's --exclude=/-e options in the unpack() function of ebuild.sh when USERLAND == GNU tar --exclude/-e is supported by both bsdtar and gtar. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Comparing Openpkg with portage
Browsing around on the osx list led me back to the archives of this list (may) for the new glep draft: Portage as a secondary package manager novel. Is this effort going anywhere? I could probably devote as much as a week to creating a proof of concept (don't know if that will be enough time), but would like to collaborate with others interested in this. I'm not very familiar with the inner workings of portage (just a happy gentoo user since 2002), but I am comfortable with bash and python and have read the developers documentation. Thoughts, comments?On 9/8/05, m h [EMAIL PROTECTED] wrote: Thanks for the response, I guess I'll post to the osx mailing list, but really my issue isn't about osx per se, but taking the osx portage port and making it run on any posix system (solaris, osx, flavors of linux etc) in a sandboxed environment. I've read through the developer documentation and didn't find anything there.Google hasn't necessarily been very useful either So, is it possible to sandbox a portage installation on top of say a debian or fedora install?If so, can anyone point me in the right direction? With current ebuilds, nope.There's no global prefix offset in thecode for it (root is merge offset, not runtime prefix offset). The osx port runs with the same ebuilds as the main portage tree right? Do any of the devs out here have experience with openpkg? Pretty much an extension of rpm spec's, afaik. Beyond that? Heh, nope :) The basic idea is you bootstrap an environment on an existing system, and then build rpm's on top of that. It would be nice to take advantage of Gentoo's larger component tree (openpkg has ~400 items) as well as the larger gentoo community.
Re: [gentoo-dev] USE=minimal for kernel sources
John Mylchreest wrote: For the record, there is a bug open for this. (#64009) Personally, I'm not keen on the idea. the only way which we can do this is by detecting which arch we are installing the sources, for, which immediately means many installs of USE=minimal are not the same. Er, but why is this a problem? Does it matter that the package will install different files on x86 than on mips? Or am I just overlooking the point? -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] USE=minimal for kernel sources
At one time we had a problem with gentoo sources having way too many use flags and patches which lead to there being an incalculable number of ways that gentoo -sources could turn out. It was a pita to maintain. A pita to troubleshoot. There were weird bugs that we couldn't reproduce easily. Basically, it was one of the worst packages to maintain in Gentoo. We had to adopt an attitude of complete loathing for kernel source packages having multiple outcomes. This loathing is probably still embedded somewhere in all of us that have been on the kernel team at one point or another. --Iggy Jan Kundrát wrote: John Mylchreest wrote: For the record, there is a bug open for this. (#64009) Personally, I'm not keen on the idea. the only way which we can do this is by detecting which arch we are installing the sources, for, which immediately means many installs of USE=minimal are not the same. Er, but why is this a problem? Does it matter that the package will install different files on x86 than on mips? Or am I just overlooking the point? -jkt -- I top post... suck it -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] USE=minimal for kernel sources
On Thu, 2005-09-08 at 22:14 +0200, Jan Kundrát wrote: Er, but why is this a problem? Does it matter that the package will install different files on x86 than on mips? Or am I just overlooking the point? In general, there is no obvious technical reason against individual installs differing from one another, however from a support and QA point of view it makes it a much less trivial issue. At the end of the day, when it comes to USE=minimal no-one can fully confirm what does, and does not exist (can cause breakages may I add) when it comes to supporting a bug, and also we can't promise it wont destroy an arch tree which you need. I'm thinking obscure (or not quite so) architecture. Pegasos, Sun, Sparc, SH, arm, etc. Although Kbuild is more than capable of functioning with only the required arch tree, what happens when it comes to things like cross-compile, not just of the sources but of anything else which might use them later on? ipw2200? nvidia? alsa-drivers? Just a bit of a worry to me, and not something I would really like to endorse. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 signature.asc Description: This is a digitally signed message part
[gentoo-dev] Modular X ATI users
if you're testing the new Modular X and have an ATI video card... Please do the following... Please e-mail me your /var/log/Xorg.#.log's off list? Thanks for your help. Trying to debug something in the ATI driver. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Developer: Lukasz Damentko
[EMAIL PROTECTED] wrote: Please welcome Lukasz if you haven't already done so (I'm sure he wont mind a repeat welcome either :) internal GDP joke Is staking, poking out of the eyes and burning of hands considered a warm welcome? :-) /internal GDP joke Welcome to the team, rane :-) -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] USE=minimal for kernel sources
Greg KH wrote: On Thu, Sep 08, 2005 at 10:49:04PM +0100, twofourtysix wrote: On 05/09/05, Petteri R?ty [EMAIL PROTECTED] wrote: I have a couple of old machines I maintain and emerging and unmerging kernel sources take a while because there are so many files. Also one set of gentoo sources takes about 230MB of disk space. By removing stuff not belonging to x86 I was able to succesfully run make with 58MB/230MB removed. The stuff I removed: arch/* except i386 and x86_64 include/asm-* expect asm-generic, asm-i386 and asm-x86_64 Is this safe? No it isn't. Please don't try to do this, it's not worth it. If disk space is limited, just build on one box, and install the kernel to the other one. IMHO it is, but not as a USE flag (it will never be stable enough without upstream support) but I think many would find the functionality useful in a script. I know I would. If it works most of the time and saves space, there is no reason not trim things. If it breaks, you immediately revert to a normal build. Or, put the kernel source on a cd, and build off of it (putting the objects on your local disk.) This lets you only use the local disk for your built objects. thanks, greg k-h -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New forum moderators
I've got a couple long-time forums moderators that's joined Gentoo officially. First we have Christian Hartmann (ian!) that's rejoined after a brief hiatus. Christian joined a Gentoo in late 2003 and is now officially part of Gentoo. Mauricio Lima Pilla (pilla) is another long time forums moderator that's now joined Gentoo staff officially. Mauricio's been a forums moderator since late 2002. Please welcome Christian and Mauricio. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GLEP: Standardizing arch keywording across all archs
Thanks to all who assisted in the tentative x86 arch team glep thread. It's now an official GLEP (as I abuse my GLEP-editor powers to add my own GLEP to the site), and it should be up on glep.gentoo.org soon. If I've misrepresented your views, please do let me know so that I can fix the GLEP. I'd like to go ahead and push this GLEP to the council for a vote at the next meeting (which I assume will be sometime in the next twenty-two days). -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp3Se6tAcRZ5.pgp Description: PGP signature
Re: [gentoo-dev] Re: remove
Mike Frysinger wrote: we know it's retarded, but not everyone is a ninja ... no reason to rant about it /me drags from the pile of dead conversations But it's easy to become a Ninja, all you need is a simple t-shirt: http://homepage.ntlworld.com/philbooth/How_To_Be_A_Ninja.jpg --Kumba -- Gentoo/MIPS Team Lead Gentoo Foundation Board of Trustees Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere. --Elrond -- gentoo-dev@gentoo.org mailing list
