Re: [kde] virtuoso-t constantly segfaulting

[Frank Steinmetzger]

On Sat, Feb 01, 2014 at 12:39:16PM -0500, Gene Heskett wrote:

> It would not surprise me to learn that neither nepomuk, soprano, nor 
> virtuoso-t, can deal with a 30gig database on a 32bit PAE system.  They 
> have all been segfaulters from the gitgo here.
> 
> So I am intermittently looking for an alternative.  Including a full 64 bit 
> kernel build, but the build process makes that impossible.

How so? Special case on your machine? I'm running a 64 bit kernel with
an otherwise 32 bit userland on my Atom netbook. All you gotta do is get
a 64 bit compiler toolchain (which is quite easily achieved on Gentoo)
and pass some parameters to the kernel make.
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any Facebook service.

Here, have a unicorn: `^nn~


signature.asc
Description: Digital signature
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] virtuoso-t constantly segfaulting

[Gene Heskett]

On Sunday 02 February 2014 07:12:19 Frank Steinmetzger did opine:

> On Sat, Feb 01, 2014 at 12:39:16PM -0500, Gene Heskett wrote:
> > It would not surprise me to learn that neither nepomuk, soprano, nor
> > virtuoso-t, can deal with a 30gig database on a 32bit PAE system. 
> > They have all been segfaulters from the gitgo here.
> > 
> > So I am intermittently looking for an alternative.  Including a full
> > 64 bit kernel build, but the build process makes that impossible.
> 
> How so? Special case on your machine? I'm running a 64 bit kernel with
> an otherwise 32 bit userland on my Atom netbook. All you gotta do is get
> a 64 bit compiler toolchain (which is quite easily achieved on Gentoo)
> and pass some parameters to the kernel make.

Well, I just built 3.12.9, with the 64 bit box checked, twice last night, 
using the .config's from this working 3.12.6. Both crashed less that 2 
seconds into the boot but at different places.  So I unchecked the 64 bit 
box in a make xconfig, and I am about to see if that will then boot, brb.
Worked, without the 64 bit checkbox. But that lost me the PAE bits, 5Gb of 
my ram is gone.  As is the cpu family was now set for pentiums instead of 
my phenom, so fix that and rebuild again is in progress.

I took screen shots of the failures, but the last one apparently started 
about 3 feet above the screen, less than informative, so at this point, I 
am still stuck on a 32 bit, soon to be PAE system.  Soon being relative, a 
complete pass of my makeit script is an over 30 minute process even with 
ccache running. 

gentoo eh?  Thats a system I have not yet tried.  I wonder how long it 
would take to get this system rebuilt in gentoo?

Ubuntu seems to set a very high fence between 32 bit and 64 bit.  Time to 
reboot again and see if I have my memory back. brb.

Ok, got my memory back.  Wish it was that easy for my wet ram. Take 2 cups 
of coffee to bring it to life, so its in the one eye open simultaneously 
stage ATM. :)

So, what else do I need to change in the build tools dept, to be able to 
build a working 64 bit kernel?  This is the ubuntu 10.04.4 LTS version of 
build_essentials. So even the compiler is old, so old it hasn't the ability 
to build any stack protection bits.

And before I go charging off to do a gentoo build, what is the first users 
UID on gentoo?  That is 1000 for ubuntu, and switching back to a first 
UID=500 system totally disables my ability to "ssh -Y shop", running that 
specially built ubuntu 10.04.4 LTS because ssh doesn't use login names, but 
UID's, so it will not allow a login from a UID=500 system on its UID=1000 
system.  That is a right PIMA too.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] {OT} Cross-compiling the kernel

[Frank Steinmetzger]

On Sun, Feb 02, 2014 at 07:58:22AM -0500, Gene Heskett wrote:

> > On Sat, Feb 01, 2014 at 12:39:16PM -0500, Gene Heskett wrote:
> > > It would not surprise me to learn that neither nepomuk, soprano, nor
> > > virtuoso-t, can deal with a 30gig database on a 32bit PAE system. 
> > > They have all been segfaulters from the gitgo here.
> > > 
> > > So I am intermittently looking for an alternative.  Including a full
> > > 64 bit kernel build, but the build process makes that impossible.
> > 
> > How so? Special case on your machine? I'm running a 64 bit kernel with
> > an otherwise 32 bit userland on my Atom netbook. All you gotta do is get
> > a 64 bit compiler toolchain (which is quite easily achieved on Gentoo)
> > and pass some parameters to the kernel make.
> [...]
> gentoo eh?  Thats a system I have not yet tried.  I wonder how long it 
> would take to get this system rebuilt in gentoo?

The netbook takes maybe 20 hours to build a KDE update (not full
environment, only kdebase, most of kdepim and some select programs).
The kernel with only the stuff I need takes around 55 minutes (Atom
N450, single core with HT).

> So, what else do I need to change in the build tools dept, to be able to 
> build a working 64 bit kernel?  This is the ubuntu 10.04.4 LTS version of 
> build_essentials. So even the compiler is old, so old it hasn't the ability 
> to build any stack protection bits.

Well, the Gentoo way uses a package called crossdev. You just tell it the
desired architecture and it builds the toolchain (binutils, gcc and
glibc). With those three, I am able to build the kernel.

To actually build the kernel, you have to either set the different
compiler in menuconfig, or pass it as parameter to make. The line from
my Makefile:

cd /usr/src/64 && make -C /usr/src/linux O=`pwd` 
CROSS_COMPILE=x86_64-pc-linux-gnu- bzImage modules

(I separate build dir from sources dir)

> And before I go charging off to do a gentoo build, what is the first users 
> UID on gentoo?

1000

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any Facebook service.

Even a Bonsai dreams of greatness.


signature.asc
Description: Digital signature
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] {OT} Cross-compiling the kernel

[Gene Heskett]

On Sunday 02 February 2014 19:43:01 Frank Steinmetzger did opine:

> On Sun, Feb 02, 2014 at 07:58:22AM -0500, Gene Heskett wrote:
> > > On Sat, Feb 01, 2014 at 12:39:16PM -0500, Gene Heskett wrote:
> > > > It would not surprise me to learn that neither nepomuk, soprano,
> > > > nor virtuoso-t, can deal with a 30gig database on a 32bit PAE
> > > > system. They have all been segfaulters from the gitgo here.
> > > > 
> > > > So I am intermittently looking for an alternative.  Including a
> > > > full 64 bit kernel build, but the build process makes that
> > > > impossible.
> > > 
> > > How so? Special case on your machine? I'm running a 64 bit kernel
> > > with an otherwise 32 bit userland on my Atom netbook. All you gotta
> > > do is get a 64 bit compiler toolchain (which is quite easily
> > > achieved on Gentoo) and pass some parameters to the kernel make.
> > 
> > [...]
> > gentoo eh?  Thats a system I have not yet tried.  I wonder how long it
> > would take to get this system rebuilt in gentoo?
> 
> The netbook takes maybe 20 hours to build a KDE update (not full
> environment, only kdebase, most of kdepim and some select programs).
> The kernel with only the stuff I need takes around 55 minutes (Atom
> N450, single core with HT).
> 
> > So, what else do I need to change in the build tools dept, to be able
> > to build a working 64 bit kernel?  This is the ubuntu 10.04.4 LTS
> > version of build_essentials. So even the compiler is old, so old it
> > hasn't the ability to build any stack protection bits.
> 
> Well, the Gentoo way uses a package called crossdev. You just tell it
> the desired architecture and it builds the toolchain (binutils, gcc and
> glibc). With those three, I am able to build the kernel.
> 
> To actually build the kernel, you have to either set the different
> compiler in menuconfig, or pass it as parameter to make. The line from
> my Makefile:
> 
> cd /usr/src/64 && make -C /usr/src/linux O=`pwd`
> CROSS_COMPILE=x86_64-pc-linux-gnu- bzImage modules
> 
> (I separate build dir from sources dir)
> 
> > And before I go charging off to do a gentoo build, what is the first
> > users UID on gentoo?
> 
> 1000

Good, one less roadblock.  In the meantime I built a 3.13.1-x64, crashed 
about 2 secs into the boot, no init found. Uncheck that box, go turn on the 
PAE, and I expect it would boot ok.  Sigh...

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Re: [kde] virtuoso-t constantly segfaulting

[Duncan]

Gene Heskett posted on Sun, 02 Feb 2014 07:58:22 -0500 as excerpted:

> Soon being relative, a complete pass of my makeit script is an over 30
> minute process even with ccache running.
> 
> gentoo eh?  Thats a system I have not yet tried.  I wonder how long it
> would take to get this system rebuilt in gentoo?

As you may remember, I'm a gentooer as well.  So between Frank and I, you 
have two gentooers to consult with if you try it. =:^)

Build-time-wise, I started gentoo on a dual single-core (pre-multi-cores) 
CPU, a first generation (3-digit) AMD Opteron, back in 2004.  Mainboard 
was a Tyan s2882, IIRC.  A gig of RAM (DDR(1)) and dual Opteron 242 CPUs 
@ 1.6 GHz.  People were even running gentoo on 486s, but I wasn't /that/ 
masochistic.  Similarly, they run gentoo on some of the lower power ARM 
and MIPS hardware today, but I think in a lot of those cases they use 
crossdev for at least some of the build, as Frank mentioned.

Anyway, AFAIRC that old setup took about 5 minutes to do a purpose-
configured kernel build, and about 8 hours for kde build (what I used in 
kde, then kde3, which was most but not all of it back then).

I kept the same mainboard as my main system for 8 years until it died due 
to bulging/burst capacitors, but upgraded to 8 gig RAM, then back down to 
6 gig when a 2-gig stick died that I never replaced.  Similarly, I 
upgraded the CPUs to a pair of top-of-their-line dual-core Opteron 290s @ 
IIRC 2.8 GHz for dual-dual-cores.  I loved that system and knew it, its 
hardware and its kernel config like the back of my hand, which is why I 
continued to upgrade and use it so long -- I was shooting for 10 years 
but didn't quite make it.

FWIW the upgraded CPUs/memory took 3-4 hours for a KDE build, and about 2 
minutes for a custom kernel build from clean.

When it died I migrated to a 6-core AMD fx6100, overclocked slightly to 
3.6 GHz, now with 16 gig of DDR3 DRAM.  Gigabyte fx990-ud3 mainboard. The 
central system's a bit faster than the old tyan, but the big deal for me 
was getting off the old buses.  The tyan was still AGP and PCI-X (not PCI-
E), the new one PCI-E 2.  The old one SATA-1, the new one SATA-3, the old 
one USB-1 with a USB-2 addon card, the new one several USB-3 connectors 
and USB-2.

A bit later I upgraded my main storage to a pair of 256 gig SSDs (Corsair 
Neutron 256, NOT the Neutron GTX), which I have partitioned up with btrfs 
in raid1 mode on most partitions.  I'm still running spinning-rust for my 
media partition and second-level backups of the main system, but the main 
system including /home is btrfs in raid1 mode on the SSDs.

This system does a kde rebuild (noting that I have less of KDE actually 
installed now) in 20-30 minutes, and a kernel build in about a minute.  
Of course I'm actually running live-git versions of both, updating about 
once a week with a script that only rebuilds the packages whose repos 
have updated, and between that and ccache, the kde (along with a few 
other live-packages I run, but not the kernel, which I update separately) 
build runs perhaps 10 minutes.  It's fast enough now that's not a big 
deal.  In fact, for quite some time the time I spend tracking the updates 
to see what has changed and updating system configuration when necessary, 
has been a bigger deal than the update builds themselves.  That was 
actually true when the kde build took a couple hours too, and the 
breakover point was probably at about 4 hours kde build time, as I could 
do other things while it was happening so it took very little of /my/ 
time, but obviously my attention and time is actually required to track 
what the updates actually are (tho reading changelogs and git commit logs 
plus bugs they sometimes mention is mostly curiosity driven, I don't 
/have/ to do that), and more importantly, to make any system 
configuration changes required.

But the time to make system configuration changes would be about the same 
on any distro.  Tho with gentoo being a rolling distro, the changes are 
incremental and it's a few minutes a week on average, instead of hours a 
couple times a year for the twice-yearly distro releases, or days every 
few years, for the long-term-support releases.

> And before I go charging off to do a gentoo build, what is the first
> users UID on gentoo?  That is 1000 for ubuntu, and switching back to a
> first UID=500 system totally disables my ability to "ssh -Y shop",
> running that specially built ubuntu 10.04.4 LTS because ssh doesn't use
> login names, but UID's, so it will not allow a login from a UID=500
> system on its UID=1000 system.  That is a right PIMA too.

Frank says it's 1000 on his gentoo system, and I think that's correct.

On my system it's 500, but I believe that's historic, due to my switch 
from Mandrake 9.x back in 2004.  I dimly recall having some issues due to 
that during my switch, as you point out, and back then, I decided it was 
easier to simply reset my user UIDs in /etc/passwd than it was to