update journal ready

Hi all,

just wanted to let you know that my latest update journal is tested and 
ready to be applied. It can be found here:

https://www.rocklinux.net/submaster/index.websplb?mode=journal&id=65

Certainly the most important changes include the update to Xorg R7.5 
with fully automated graphics hardware detection. Personally I've been 
waiting for something like this for years and it's great to finally have 
this technology available :)

Furthermore, besides other updates and some bugfixes, the latest patch 
set includes gnome 2.28 (partially tested) and KDE 4.4 (tested in a 
livecd build).

KDE 4 in ROCK Linux is improved in a way that more optional features, 
like the Nepomuk semantic desktop. are enabled. KDE 4 already works very 
well in the livecd target and will be able to replace KDE 3 as the 
default desktop with little effort.

Have fun,
Stefan Fiedler

New Webpage

Hello everyone,

I've replaced the ROCK Linux Webpage (the MediaWiki on rocklinux.org) and
the ROCK Linux Portal (the script generated html file on rocklinux.net)
with a simple HTML file today summarying the most important topics on rock
linux (what is it, how to build it, where to gather more information).

especially important: this page now states that there are no releases but
someone who wants to use rock linux is supposed to use the svn head.

the wiki is still available but this new top page states that some
information in the wiki is youtdated, as it is in fact..

please let me know if you have some additional input for this new rock
linux startup page.

btw: this new page is almost just plain text and looks a bit 'old world'
for a webpage, but I think that in fact matches the project very well.. 

yours,
 - clifford

--

-- 
2B OR (NOT 2B) That is the question. The answer is FF.

Building packages with make -jX

Hey ROCK Linux,

for decreased build time I tried to use make with the -j switch to utilize all
CPU cores of my new build host. Unfortunately not all all packages
support this option. The list below is created simply by trial and error
during a build which sets $MAKE in pkg-header.

My question is what  is or would  be the recommended way to deal with this 
issue in ROCK. In my next build I plan to automate the task of determining 
compatibilty with a customized pkgloop_action.
Are there plans to work around this in ROCK Linux core scripts? This would be 
nice. 

Cheers 
Sebastan aka giftnuss

glibc      # fix: should not match glib
qt4        # mit 4.5 nicht getestet
openssl
groff
slang # install skript regression
mesalib
mine
fbset
pth
gpm
samba

Crystal is now bootable?

Hello guys.

I just built me a crystal and a bootdisk target and wanted to create an
installable ISO from it:

root <at> fortuna:/usr/src/ROCK-CHROOT/rock-trunk# ./scripts/Create-ISO iso bootdisk 9400

[08:18:09 AM] Removing old files with same prefix ...
[08:18:09 AM] Reading configs and creating ISO index ...
Multiple boot options found!

Since when is a crystal build bootable?

Greetings,
	blindy
--

-- 
The Nethack IdleRPG! Idle to your favorite Nethack messages!
http://pallas.crash-override.net/nethackidle/
#######

Bitte beachte, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert
wird.
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
http://piratenpartei.de/navigation/politik/ueberwachung/vorratsdatenspeicherung

#######

gcc 43 in current TRUNK (rev 9400)

Hi list.

I just tried building a crystal with current TRUNK (rev 9400).
0-gcc43 fails because it can't find mpfr, which is first built in stage
2.
The current LiveCDs have been buildt wit gcc43 though. How did you do
this?

Greetings,
	blindcoder
-- 
 _  _     _   _            _   
| \| |___| |_| |_  __ _ __| |__
| .` / -_)  _| ' \/ _` / _| / /
|_|\_\___|\__|_||_\__,_\__|_\_\
| |  (_)_ _ _  ___ __
| |__| | ' \ || \ \ /
|____|_|_||_\_,_/_\_\
Play Nethack anywhere with an x86 computer:
	http://www.crash-override.net/nethacklinux.html
#######

Bitte beachte, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert
wird.
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
http://piratenpartei.de/navigation/politik/ueberwachung/vorratsdatenspeicherung

New Tracker for isos.rocklinux.org

Hi all.

Starting now, there's a new tracker used on the
http://isos.rocklinux.org/ website. For uploaders with access to
.torrent creation and deletion nothing changes. The tracker is
integrated into the administration interface.

Kind regards,
     Benjamin
-- 
  ____  _        _    ____  _   _ _ _____ __  __ 
 / ___|| |      / \  / ___|| | | ( ) ____|  \/  |
 \___ \| |     / _ \ \___ \| |_| |/|  _| | |\/| |
  ___) | |___ / ___ \ ___) |  _  | | |___| |  | |
 |____/|_____/_/   \_\____/|_| |_| |_____|_|  |_|
 play online: telnet://slashem.crash-override.net
 view scores: http://slashem.crash-override.net
 watch deaths: irc://irc.freenode.net#slashem
#######

Bitte beachte, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert
wird.
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
http://piratenpartei.de/navigation/politik/ueberwachung/vorratsdatenspeicherung

#######

hardware

hi,

boy has it been long 

i'm writing today because i have hardware to give away. i'm moving out  
of a house and into a flat, so there is no space to keep all this  
stuff anymore. please feel free to contact me with detailed questions  
about the hardware. it is absolutely free, but given away only on 2  
conditions:

a) you have to get it yourself. i will neither ship it nor will i  
bring it to you by other means. i live in ingolstadt, bavaria, germany.
b) you are not allowed to sell it. this is the same term i agreed to  
when i got most of the hardware, it is and stays free!

here's the list:

MIPS:
6x SGI Indigo2 (mixed green and black, no R10k unfortunately, one  
has a pc-compatible serial port soldered to it)
1x SGI Challenge S
1x Cobalt CacheRaq 2
1x Cobalt Qube

ripclaw also lended me these, so i guess he'll shout if he wants them  
back personally:
1x SGI Indy (with linux compatible graphics card, iirc. complete  
with camera and monitor)
1x SGI IRIS Indigo ("the coffee maker")

target-finish packages

Hi all,

today I'd like to write a bit about the packages in the target-finish 
repository. They have been in trunk for a while but so far haven't been used 
in any target by default. 

In ROCK Linux, targets can perform additional actions after all packages have 
been built (by adapting target/*/build.sh). The bootdisk, crystal and livecd 
targets extensively use this to e.g. prepare files for boot media and create 
package selections. 

target-finish packages are intended to provide the same feature but avoid code 
duplication between targets. The current implementation consists of slightly 
modified code from the bootdisk, crystal and livecd targets grouped by 
functionality into seven packages, e.g. bootloader, initramfs or packagedb. 

These packages can be used in any target to e.g. create files for a bootable 
install or live CD. It is noteworthy that this implementation does not 
require any changes to the build scripts. 

target-finish packages have a few things in common:
- no binary packages are created for these. This simply follows from the fact 
that these packages do not (or shouldn't) touch any files in the directories 
considered for binary package creation (as defined by the flistroot 
variable); target-finish packages create files below the directory 
build/<build-id>/ROCK/target-finish instead. 
- they are build after other packages and in a separate stage (currently stage 
8). Atm. stage 9 is the rebuild stage, but it should really be the other way 
round (which would require a few changes to the build scripts). 
- target-finish packages can only be built using Build-Target since they are 

KDE 4.0 Released

Hi,

as some of you might have noticed: KDE 4.0 has been released [1]. Does
anyone fell like performing the kde update for rock linux?

yours,
 - clifford

[1] http://www.kde.org/announcements/4.0/

--

-- 
 ____   ___   ____ _  __  _     _ www.rocklinux.org
|  _ \ / _ \ / ___| |/ / | |   (_)_ __  _   ___  __
| |_) | | | | |   | ' /  | |   | | '_ \| | | \ \/ /
|  _ <| |_| | |___| . \  | |___| | | | | |_| |>  <
|_| \_\\___/ \____|_|\_\ |_____|_|_| |_|\__,_/_/\_\

Submaster and patches >64k

Hi,

good news:
submaster can handle patches >64kB now (the new limit is 16MB).

yours,
 - clifford

--

-- 
"One of my most productive days was throwing away 1000 lines of code."
 - Ken Thompson

overview of sysroot/multilib patches

Hi all,

here is an overview of changes in the sysroot/multilib journal. The complete 
journal can be found at 
http://rocklinux.net/submaster/index.websplb?mode=journal&id=50 . The patches 
have been tested with various cross-builds (arm, sparc, x86_64 multilib and 
64-bit only) and the usual bootdisk and crystal builds. I have tested 
different gcc versions and cross-toolchain packages as well.

The toolchain packages have been rewritten with less code to be more easily 
understandable and maintable. gcc and binutils now use the --sysroot 
configure option which makes e.g. modifying the gcc specs file unecessary and 
is generally much less error prone.

The gcc is now build three times before chroot stages to get complete C/C++ 
cross-compilers with shared libraries including libstdc++. For this a third 
build stage before chroot is required. Most packages from stages 1, 2 and 3 
are now built one stage later and stage 3 is the first chroot stage.

The build scripts now support separate 32-/64-bit packages in multilib builds. 
Packages named *-32bit are built as 32-bit and $bindir etc. point to a 
temporary directory as not to overwrite 64-bit files. $libdir however 
contains the real location, so that packages with a configure script (or 
which consider $libdir otherwise) usually install libraries to the correct 
location. The build variable $multilib contains 'lib' or 'lib64' and 
indicates where to install libraries, e.g. if a package sets $libdir, it 
should do it like this: libdir="$root/usr/$multilib". Packages containing the 
MULTILIB flag will be automatically built as 32- and 64-bit in all stages.

The default $confopt now passes $prefix, $bindir, etc. without the $root