On 11/27/2010 08:22 PM, DJ Lucas wrote:
> On 11/27/2010 02:30 AM, DJ Lucas wrote:
>> Problem is acknowledged, and even suspected cause determined.
>
> We have an upstream fix, hasn't appeared in the archives yet.
>
The threaded code. Fixes are in upstream following the bug from the
previous thread
On 11/27/2010 02:30 AM, DJ Lucas wrote:
> Problem is acknowledged, and even suspected cause determined.
We have an upstream fix, hasn't appeared in the archives yet.
> On 11/27/2010 06:57 PM, Paul Eggert wrote:
>> Could you please try this little patch? It should fix your
>> problem. I came up
"Bruce Dubbs" wrote:
>
>It looks like he can't reproduce it.
>
Not all of messages are archived yet. Problem is acknowledged, and even
suspected cause determined.
--DJ Lucas
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
This message has been scanned for viruse
DJ Lucas wrote:
> On 11/26/2010 02:44 PM, Matthew Burgess wrote:
>> On Fri, 26 Nov 2010 14:09:30 -0600, Bruce Dubbs
>> wrote:
>>
>>> I've been pretty busy with a work project. I'd appreciate it if you can
>>> do it.
>> No probs, done in r9421. Thanks, DJ, for the report.
>>
>> Regards,
>>
>> Mat
On 11/26/2010 02:44 PM, Matthew Burgess wrote:
> On Fri, 26 Nov 2010 14:09:30 -0600, Bruce Dubbs wrote:
>
>> I've been pretty busy with a work project. I'd appreciate it if you can
>> do it.
>
> No probs, done in r9421. Thanks, DJ, for the report.
>
> Regards,
>
> Matt.
>
Yep yep...reported
On Fri, 26 Nov 2010 14:09:30 -0600, Bruce Dubbs wrote:
> I've been pretty busy with a work project. I'd appreciate it if you can
> do it.
No probs, done in r9421. Thanks, DJ, for the report.
Regards,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscra
Matthew Burgess wrote:
> On Fri, 26 Nov 2010 10:45:01 -0600, Bruce Dubbs wrote:
>
>> Should we revert to .6 until this is fixed?
>
> That's probably the safest/easiest option. Do you mind taking care of it,
> or do you want me to?
I've been pretty busy with a work project. I'd appreciate it i
On Fri, 26 Nov 2010 10:45:01 -0600, Bruce Dubbs wrote:
> Should we revert to .6 until this is fixed?
That's probably the safest/easiest option. Do you mind taking care of it,
or do you want me to?
Thanks,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfro
DJ Lucas wrote:
> On 11/26/2010 10:45 AM, Bruce Dubbs wrote:
>> Matthew Burgess wrote:
>>> On Wed, 24 Nov 2010 23:47:41 -0600, DJ Lucas
>>> wrote:
>>>
Can somebody else on a mult-core CPU, on 32-bit, confirm before I
troubleshoot further?
>>> This is also being tracked upstream and at R
On 11/26/2010 10:45 AM, Bruce Dubbs wrote:
> Matthew Burgess wrote:
>> On Wed, 24 Nov 2010 23:47:41 -0600, DJ Lucas
>> wrote:
>>
>>> Can somebody else on a mult-core CPU, on 32-bit, confirm before I
>>> troubleshoot further?
>>
>> This is also being tracked upstream and at RedHat:
>>
>> http://li
On 11/26/2010 10:45 AM, Bruce Dubbs wrote:
> Matthew Burgess wrote:
>> On Wed, 24 Nov 2010 23:47:41 -0600, DJ Lucas
>> wrote:
>>
>>> Can somebody else on a mult-core CPU, on 32-bit, confirm before I
>>> troubleshoot further?
>>
>> This is also being tracked upstream and at RedHat:
>>
>> http://li
Matthew Burgess wrote:
> On Wed, 24 Nov 2010 23:47:41 -0600, DJ Lucas
> wrote:
>
>> Can somebody else on a mult-core CPU, on 32-bit, confirm before I
>> troubleshoot further?
>
> This is also being tracked upstream and at RedHat:
>
> http://lists.gnu.org/archive/html/coreutils/2010-11/msg00083
It happened to my lfs too
Program terminated with signal 11, Segmentation fault.
#0 0xb75c926f in __strlen_ia32 () from /lib/libc.so.6
(gdb) bt
#0 0xb75c926f in __strlen_ia32 () from /lib/libc.so.6
#1 0xb75cd15a in strcoll_l () from /lib/libc.so.6
#2 0xb75c8c22 in strcoll () from /lib/libc.so.
On Wed, 24 Nov 2010 23:47:41 -0600, DJ Lucas wrote:
> Can somebody else on a mult-core CPU, on 32-bit, confirm before I
> troubleshoot further?
This is also being tracked upstream and at RedHat:
http://lists.gnu.org/archive/html/coreutils/2010-11/msg00083.html
https://bugzilla.redhat.com/show_b
On Thu, 25 Nov 2010 22:42:10 -0600, DJ Lucas wrote:
> Also, the update to expect broke jhalfs.
I fixed that in http://wiki.linuxfromscratch.org/alfs/changeset/3534
shortly after I committed the expect upgrade to LFS. Doing an 'svn up'
should get you going again.
As for your coreutils issue, I
- Original Message -
From: "DJ Lucas"
To: "LFS Developers Mailinglist"
Sent: Friday, November 26, 2010 5:42 AM
Subject: Re: Segmentation fault in sort with Coreutils-8.7
> On 11/25/2010 12:17 AM, DJ Lucas wrote:
> > On 11/25/2010 12:14 AM, Stuart Stegal
On 11/26/2010 12:07 AM, Bruce Dubbs wrote:
> DJ Lucas wrote:
>
>> The update to expect broke jhalfs. I
>> haven't looked into why yet, but last time I had seen similar error, it
>> was due to a missing role= tag on one of the screen blocks.
>
> I suspect it's because the package was renamed expe
DJ Lucas wrote:
> The update to expect broke jhalfs. I
> haven't looked into why yet, but last time I had seen similar error, it
> was due to a missing role= tag on one of the screen blocks.
I suspect it's because the package was renamed expect5 instead of
expect-5. IIRC, the same problem exis
On 11/25/2010 12:17 AM, DJ Lucas wrote:
> On 11/25/2010 12:14 AM, Stuart Stegall wrote:
>> x86, arm, ppc64, and x86_64 all work without a problem here - x86 and
>> x86_64 are both built from current SVN - arm and ppc64 are 6.7 +
>> coreutils-8.7.
>>
>
> Okay, probably a problem on my system then.
On 11/25/2010 12:14 AM, Stuart Stegall wrote:
> x86, arm, ppc64, and x86_64 all work without a problem here - x86 and
> x86_64 are both built from current SVN - arm and ppc64 are 6.7 +
> coreutils-8.7.
>
Okay, probably a problem on my system then. Will check and see if it
happens native.
Thanks
x86, arm, ppc64, and x86_64 all work without a problem here - x86 and
x86_64 are both built from current SVN - arm and ppc64 are 6.7 +
coreutils-8.7.
On 11/24/10, DJ Lucas wrote:
> Guys, getting a segfault in sort using large input set. The behavior
> changed to always use the number of processor
Guys, getting a segfault in sort using large input set. The behavior
changed to always use the number of processors available in parallel by
default. The following commands (taken from cracklib installation which
is where I first saw the error) work to successfully reproduce the error
(in a chroot
22 matches
Mail list logo
