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
>> bin
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 t
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:
> > > > > An
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 co
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
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.
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 an
> "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 LT
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 - p
