[gentoo-dev] Last-Rites: app-emulation/vmware-gsx-console
Package is obsolete/unmaintained -- upstream replaced GSX with vmware-server several years ago, and recommended users migrate to esxi. Download also is likely non-functional. All users should have migrated long ago. Nothing appears to be depending on it. Bug #355301 assigned to vmware herd - package will be masked shortly. -- Matthew Marlowe/ 858-400-7430 /DeployLinux Consulting, Inc Professional Linux Hosting and Systems Administration Services www.deploylinux.net * m...@deploylinux.net 'MattM' @ irc.freenode.net
Re: [gentoo-dev] Re: Re: Downgrading glibc?
> "MH" == Michael Haubenwallner writes: MH> I've heard a colleague of mine debugged for 50(!) hours after moving MH> some quite old application to some recent Linux before he replaced a MH> memcpy by memmove, so this did ring some bells. MH> However, now he said this was on Ubuntu 10.04.1 LTS, having MH> glibc-2.11, so this might have been unrelated indeed. Check the archives of the glibc lists, as well as its bug db. There has been quite a bit of discussion there on that issue. It was added for sse3 some time ago; I beleive it was Intel engineers who contributed it for sse3, showing that it was inedeed faster on their chips to start at the high point and decrement the counter rather than starting at the low point and incrementing. The discussion in their lists does a better job of documenting the issue. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] RFC: package.keywords-compatible snippets when stabilizing multiple packages
On Tue, Feb 15, 2011 at 8:10 AM, Gilles Dartiguelongue wrote: > I don't think making a list for each arch is going to make anything any > easier for maintainers requesting stabilization, which means those list > we need more time to generate before being released. You just move the > problem to another place. >From my perspective, it should be more about making it easier for arch teams to test the packages. Lots of talk about what to do about "slacking arches". Well, maybe just give them an easy list they can grep to get the packages they need to test would help. Seems like a fairly straight forward thing to do. A tool to automate this process for the maintainers might be nice. Matt
Re: [gentoo-dev] RFC: package.keywords-compatible snippets when stabilizing multiple packages
On 2/15/11 9:10 AM, Gilles Dartiguelongue wrote: > I don't think making a list for each arch is going to make anything any > easier for maintainers requesting stabilization, which means those list > we need more time to generate before being released. You just move the > problem to another place. I was expecting such argument. It's a good point, but please consider the following: - if the stabilization list has been created automatically, we should adjust the tool to print in a format more suitable for the intended audience (arch developers) - if the stabilization list has been created manually, what prevents you from doing it in a slightly different way? I think it doesn't change the amount of work, and might even decrease it (no need for pretty tables) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Downgrading glibc?
On 02/16/2011 11:06 AM, Michael Haubenwallner wrote: > So I'm fine with Gentoo shipping vanilla memcpy, I'm just curious > if next RHEL will do. I'd be surprised as hell to find out Red Hat changed this in current RHELs (5 and 6) during their lifetime. On the other hand I'd be equally surprised if Red Hat wouldn't use upstream implementation in future products. If Fedora is any example, they will keep upstream implementation. Also RHEL 6 is still pretty fresh, so there are quite a few years until RHEL 6.0 goes EOL so software vendors have time to fix their problems :-) -- Stanislav Ochotnicky PGP: 7B087241 jabber: stanis...@ochotnicky.com signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: package.keywords-compatible snippets when stabilizing multiple packages
On Wed, 16 Feb 2011 09:14:59 -0600 Donnie Berkholz wrote: > On 14:17 Wed 16 Feb , Tobias Klausmann wrote: > > I think automatically generating per-arch lists and dumping them > > on the bug is a nice way to do it. Having a "tabled list" for use > > by the maintainer and then generating one comment per > > arch-specific list seems like a good idea to me. Yes it is more > > verbose on the bug, but that is a little price to pay, I'd say. +1 :) > Is using autounmask an option instead? That generates a nice little > file with everything that was actually unmasked, assuming it's a > single dependency tree of packages. autounmask takes ages on slow systems. jer
Re: [gentoo-dev] RFC: package.keywords-compatible snippets when stabilizing multiple packages
On 14:17 Wed 16 Feb , Tobias Klausmann wrote: > Hi! > > On Tue, 15 Feb 2011, Donnie Berkholz wrote: > > On 09:10 Tue 15 Feb, Gilles Dartiguelongue wrote: > > > Le lundi 14 février 2011 à 19:19 +0100, "Paweł Hajdan, Jr." a écrit : > > > > On 2/14/11 9:13 PM, Samuli Suominen wrote: > > > > > And http://bugs.gentoo.org/show_bug.cgi?id=349053#c1 ? I tried to > > > > > provide a clue howto get usable p.keywords list easy. > > > > > > > > IMHO it's in the middle. I still have to do a manual step, but at least > > > > it's pretty straightforward. Anyway, I think a list that can be blindly > > > > copy-pasted makes things even easier. > > > > > > I don't think making a list for each arch is going to make anything any > > > easier for maintainers requesting stabilization, which means those list > > > we need more time to generate before being released. You just move the > > > problem to another place. > > > > Why would you need to do that? Can't you just make a single list that > > either has keywords for every arch or a ** ? Presumably every arch needs > > a certain set of packages stable, and it doesn't matter if you > > redundantly specify packages that are already stable. > > Yes it does. I for one just use the list, compile and test all > the packages. If an entry is already stable, that effort is > wasted. > > I think automatically generating per-arch lists and dumping them > on the bug is a nice way to do it. Having a "tabled list" for use > by the maintainer and then generating one comment per > arch-specific list seems like a good idea to me. Yes it is more > verbose on the bug, but that is a little price to pay, I'd say. Is using autounmask an option instead? That generates a nice little file with everything that was actually unmasked, assuming it's a single dependency tree of packages. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpJUwhMoUlyS.pgp Description: PGP signature
Re: [gentoo-dev] RFC: package.keywords-compatible snippets when stabilizing multiple packages
Hi! On Tue, 15 Feb 2011, Donnie Berkholz wrote: > On 09:10 Tue 15 Feb, Gilles Dartiguelongue wrote: > > Le lundi 14 février 2011 à 19:19 +0100, "Paweł Hajdan, Jr." a écrit : > > > On 2/14/11 9:13 PM, Samuli Suominen wrote: > > > > And http://bugs.gentoo.org/show_bug.cgi?id=349053#c1 ? I tried to > > > > provide a clue howto get usable p.keywords list easy. > > > > > > IMHO it's in the middle. I still have to do a manual step, but at least > > > it's pretty straightforward. Anyway, I think a list that can be blindly > > > copy-pasted makes things even easier. > > > > I don't think making a list for each arch is going to make anything any > > easier for maintainers requesting stabilization, which means those list > > we need more time to generate before being released. You just move the > > problem to another place. > > Why would you need to do that? Can't you just make a single list that > either has keywords for every arch or a ** ? Presumably every arch needs > a certain set of packages stable, and it doesn't matter if you > redundantly specify packages that are already stable. Yes it does. I for one just use the list, compile and test all the packages. If an entry is already stable, that effort is wasted. I think automatically generating per-arch lists and dumping them on the bug is a nice way to do it. Having a "tabled list" for use by the maintainer and then generating one comment per arch-specific list seems like a good idea to me. Yes it is more verbose on the bug, but that is a little price to pay, I'd say. Regards, Tobias -- printk(KERN_ERR "msp3400: chip reset failed, penguin on i2c bus?\n"); linux-2.2.16/drivers/char/msp3400.c
Re: [gentoo-dev] Re: Re: Downgrading glibc?
On 02/11/11 16:24, Diego Elio Pettenò wrote: > Il giorno ven, 11/02/2011 alle 14.23 +0100, Michael Haubenwallner ha > scritto: >> >> But both that document as well as uncountable lines of source code are >> rather old. >> While the source code isn't that large a problem for Gentoo, existing >> binaries >> without source code still are. > > Beside flash what else is involved for now? We can decide that once > that's defined. I've heard a colleague of mine debugged for 50(!) hours after moving some quite old application to some recent Linux before he replaced a memcpy by memmove, so this did ring some bells. However, now he said this was on Ubuntu 10.04.1 LTS, having glibc-2.11, so this might have been unrelated indeed. Anyway, running old applications on recent Linux is quite common in "enterprise" world (where Gentoo might not be such a big player). So I'm fine with Gentoo shipping vanilla memcpy, I'm just curious if next RHEL will do. /haubi/ -- Michael Haubenwallner Gentoo on a different level
