Log from #neuros IRC channel

just one thing, i wasn't bashing imem. as i told you yesterday, i have no problem with imem per se, i wasn't just understanding why it impacted the other drivers

[02:54]

now i think i do

[02:55]

and i agree on the priority. now that this issue is understood, it's ok

[02:56]

<eigma>

well, I'm heading to bed.. have a good one

[05:54]

<anders_>

JoeBorn: No, that I wrote. It talks to xmms2.

[07:09]

<anders_>

JoeBorn: dir.gmane.org

[10:10]

<American-Tech>

Joe you here?

[10:11]

<American-Tech>

JoeBorn that is...:)

[19:31]

<eigma>

ping

[19:31]

<crweb>

pong

[19:31]

<crweb>

eigma: nice reply by the way. I understand now. thx

[19:53]

<eigma>

oh hey

[19:53]

<eigma>

I could have sworn I set my IRC client to bother me when someone writes something :\

[19:54]

<crweb>

lol

[19:54]

<crweb>

mine is green for talking, read for addressing me

[19:54]

<eigma>

I like that.. unfortunately, Billy G decided that taskbar flashes are only one colour..

[19:55]

<eigma>

anyway, so I want to do an overhaul on Derobert's guide.. specifically the "first compile" part, because that's really the only one I can help with

[19:55]

<eigma>

the things is, there's two approaches: download a tarball (which is what the guide currently recommends), and

[19:56]

<eigma>

getting latest trunk (well, actually, you could start from a tag).. and I don't know which is the better idea

[19:56]

<eigma>

now that I think about it.. getting a tarball is just like getting a tag, so really svn'ing is more flexible

[19:56]

<crweb>

you get a tarball

[19:56]

<crweb>

svn load is very high

[19:56]

<crweb>

because its not compressed, huge data transfers

[19:57]

<eigma>

yeah, but it's a one-time thing when someone new does a svn co

[19:57]

<eigma>

svn up's are very efficient

[19:57]

<crweb>

a 225mb download turns into 1gig download

[19:57]

<crweb>

no, you think its a 1 time thing

[19:57]

<crweb>

luckly enough, i take my own snapshots

[19:58]

<crweb>

make clean, make mrproper doesn't work right

[19:58]

<eigma>

hmm.

[19:59]

<eigma>

oh, btw, do you have access to /tarballs? there's a stale neuros-osd.tar.7z that's been sitting there for months and it's only confusing people

[19:59]

<crweb>

i do not

[19:59]

<crweb>

it got me once though

[19:59]

<eigma>

yeah, it's really stupid..

[20:00]

<eigma>

do you know who does have access to that?

[20:01]

<crweb>

derobert, Joe, or someone that started with a g i think

[20:01]

<crweb>

nerochiaro knows

[20:01]

<eigma>

k

[20:02]

<eigma>

hm, should joe be on wiki.neurostechnology.com ?

[20:03]

<crweb>

Xorlev is the odnt,wiki admin too

[20:03]

<crweb>

eigma: srob* i think can do tars

[20:04]

<crweb>

If you need to contact an administrator, look for:

[20:04]

<eigma>

hehe

[20:04]

<crweb>

should be, if you need to contact a Communicty administrator

[20:04]

<crweb>

community

[20:04]

<crweb>

good work ;)

[20:05]

<eigma>

what's diff between "admin" and "community admin", I don't understand?

[20:05]

<eigma>

what's the extra information?

[20:06]

<eigma>

oh, btw wiki user "Avol" is a bot, see wiki.neurostechnology.com - can you revert changes/ban him?

[20:38]

<eigma>

crweb: you get my message about the wiki

[20:38]

<eigma>

?

[20:39]

<crweb>

no, hold on just a few more min

[20:39]

<crweb>

i can't read anything

[21:01]

<crweb>

eigma: ok

[21:37]

<eigma>

crweb: you there?

[21:37]

<crweb>

yes

[21:38]

<eigma>

crweb: user "Avol" on wiki is a bot.. can your revert and ban?

[21:44]

<crweb>

Xorlev: wake up

[21:44]

crweb: Eh?

[21:45]

it is clean, all 2006, open.neurosaudio.com but RewriteRule don't remember :(

[21:45]

<crweb>

Xorlev: user "Avol" on wiki is a bot.. can your revert and ban?

[21:45]

<crweb>

and give me admin plz

[21:45]

<eigma>

crweb: I thought you had wiki admin

[21:45]

<crweb>

as did i

[21:45]

Yeah, sec

[21:45]

<crweb>

i think i removed myself

[21:46]

<eigma>

anyone with write access to /tarballs

[21:46]

<eigma>

?

[21:46]

<eigma>

xorlev, garbade?

[21:46]

<eigma>

*garbage

[21:47]

eigma: yes?

[21:47]

Looks like you reverted, I banned.

[21:47]

<crweb>

I overwrote

[21:47]

<eigma>

garbage: can you rm neuros-osd.tar.7z, it's totally outdated

[21:48]

crweb: You want me to rollback to before then?

[21:48]

<crweb>

yeah

[21:49]

<crweb>

i couldn't find the revert button

[21:49]

<crweb>

then I realized i wasn't admin

[21:49]

Gah, wrong revert. Sec

[21:49]

Good evening, everyone....

[21:49]

well, night, actually

[21:50]

root@lnx:/srv/svn-tarballs# ls -al neuros-osd.tar.7z

[21:50]

-rw-r--r-- 1 root root 139677065 Sep 21 06:54 neuros-osd.tar.7z

[21:50]

root@lnx:/srv/svn-tarballs#

[21:50]

this?

[21:50]

<crweb>

derobert good something :)

[21:50]

<eigma>

yes

[21:50]

well, could very well be morning if you're in the China division....

[21:51]

<crweb>

should be 2pm there i think maybe noon?

[21:51]

JoeBorn mailed me something about Asterisk on the OSD...

[21:52]

eigma: rm'd, thanks

[21:53]

<crweb>

eigma: our admin status are a bit sparatic

[21:53]

<eigma>

GarBage: no, thank you

[21:54]

<eigma>

also, is there any reason svn:externals on svn.neurostechnology.com is with neurosaudio.com instead of neurostechnology.com?

[21:55]

<crweb>

eigma: probably because the nt.com is used internally

[21:55]

<crweb>

eigma: and can't really add /OSD without a lot of work?

[21:56]

<crweb>

oh wait

[21:56]

<eigma>

I don't understand. both svn.na.com and svn.nt.com are the same IP.

[21:56]

<crweb>

virtual hosting

[21:56]

<eigma>

I'm talking about the svn:externals property on that url

[21:56]

<crweb>

there was a reason

[21:56]

eigma: There isn't really any reason it is one way or the other....

[21:56]

<crweb>

i think it was the certificate

[21:56]

<eigma>

certificate is self-signed anyway, doesn't really matter

[21:57]

<crweb>

it did when your client wouldn't auth it

[21:57]

<eigma>

and the externals are pure http, no cert involved

[21:57]

the certificate is, if I remember correctly, for both domains...

[21:57]

<eigma>

derobert: then can we change it to nt.com for consistency?

[21:57]

eigma: we could, but I don't think it'd be a good thing next time people did an 'svn up'

[21:57]

<crweb>

I remember getting a cert error with an.com

[21:57]

eigma: AFAIK, svn does not recognize them as the same... so it'd try to do something silly

[21:58]

<eigma>

derobert: yeah, it'd think the externals changed completely

[21:58]

<crweb>

oh yeah, thats what it was

[21:58]

<eigma>

derobert: do you see any long-term solution to this?

[21:58]

<eigma>

erm, medium-term

[21:58]

<crweb>

sorry

[21:58]

* crweb zips it

[21:58]

<eigma>

point is, I think this should be changed, if not soon, but eventually

[21:59]

eigma: well, right now AFAIK it isn't a problem....

[21:59]

well, other than cosmetic, possibly

[21:59]

<eigma>

hm, ok, I'll digest this a bit more and report back

[22:01]

eigma: it'd be nice if everything were consistent, it's a relatively minor issue compared to the problems changing it would cause with svn up

[22:02]

(there should have been a "while" in front of that)

[22:03]

<eigma>

yes, I agree.. for right now, anyway

[22:04]

I've been busy and ignoring the OSD for a while, so I'm not sure what the state of the scratchbox build stuff is... but, in the medium- to long-term, redesigning the repository around the new build system is probably the answer.

[22:04]

<eigma>

what is the "new build system"? 00_Build.sh?

[22:05]

<crweb>

derobert there have been some issues with that

[22:05]

<crweb>

derobert people are confusing "build system" and "bootstrap system"

[22:05]

eigma: 00_Build.sh is the old build system, sort of... It's pretty much a wrapper to make the old system use fakeroot, and be easier to use

[22:05]

<crweb>

whats in place now is "bootstrap system"

[22:06]

crweb: ah, ok... so basically, what's been done, is someone has gotten GCC compiled? Kernel too? Userland?

[22:06]

<crweb>

no, nothings done as far as i know

[22:06]

<eigma>

eigma: so what /is/ the new system?

[22:06]

<crweb>

just a lot of talk of trying to move neuros-bsp to a "build enviroment" which is wrong

[22:06]

eigma: ummm............

[22:07]

<crweb>

a build enviroment should only use the toolchain and libc, and kernel headers

[22:07]

<crweb>

and should be totally seperate from the "bootstrapping" of the system

[22:07]

<crweb>

the current repo does not need to be touched

[22:08]

crweb: well, the current repo was, last I looked, rather a mess...

[22:08]

<crweb>

all it is for is bootstrapping so you have something to run your programs on

[22:08]

<crweb>

well it is a mess

[22:08]

<crweb>

but thats not the bsp's fault

[22:08]

<crweb>

the bsp is fine.

[22:08]

<crweb>

you're not suppose to use the bsp

[22:08]

<crweb>

only the toolchain

[22:09]

<crweb>

the bsp is for bootstrapping

[22:09]

<crweb>

you don't develop apps in it. it shouldn't be connected to a dev enviroment, and it def should use automake/autoconf or scratchbox

[22:09]

<crweb>

scratchbox should only use the libs, headers, and toolchain IN the bsp

[22:09]

crweb: well, right now, the bsp is being used fairly extensivly, or has that changed? I mean, that's where the kernel lives, the POSIX shell, commands, etc.

[22:10]

<crweb>

no, its not used at all

[22:10]

<crweb>

busybox, the kernel, libc, and gcc is all that is there

[22:10]

crweb: not used at all with scratchbox, or not used at all in the old-style build?

[22:10]

<crweb>

think of it like this.

[22:11]

<crweb>

the bsp, is designed for you to run make. it builds. and gives you a booting system

[22:11]

<crweb>

NOTHING else

[22:11]

<crweb>

you are supposed to use the toolchain to build external apps

[22:11]

<crweb>

which is why nano-x, cooler, extra-apps are all outside of the neuros-bsp

[22:11]

<Ycros>

so which directions should all this be heading in?

[22:12]

<crweb>

the bsp shouldn't be touched. It is constant

[22:12]

crweb: ok, I see what you mean by "used"

[22:12]

<crweb>

the only time bsp changes is when the people working on the base linux system make changes

[22:12]

crweb: I was thinking "it provides the C and C++ libraries, the headers, the kernel, the shell, etc... of course it's used!"

[22:12]

<crweb>

right right

[22:12]

<crweb>

but that can be copied out

[22:13]

<crweb>

what needs to happen. IS

[22:13]

<eigma>

are you just saying that toolchain should be one level up? nothing else is used from the bsp afaik

[22:13]

<crweb>

someone get the toolchain working in scratchbox

[22:13]

<crweb>

the toolchain is all a developer enviroment needs

[22:14]

<crweb>

toolchain = linux headers, gcc, other utils for biulding

[22:14]

ok

[22:14]

<crweb>

if we go off and get rid of the bsp and make a whole build enviroment around it

[22:14]

<crweb>

we merge bootstrapping AND 3rd party application development

[22:14]

<Ycros>

I like openembedded

[22:14]

<crweb>

this is how openembedded is

[22:15]

<crweb>

there are always 2 systems

[22:15]

<crweb>

linux users just don't see it cause the bootstrapping system is before they get their distro

[22:15]

<crweb>

neuros-bsp is our distro

[22:15]

<Ycros>

oh, aye

[22:15]

<eigma>

what are you talking about, bootstrapping? bootstrapping gcc? building a rootfs?

[22:15]

<crweb>

we just happen to have to compile it

[22:15]

crweb: sure, but if neuros-bsp wants to be a distro, then it should become more distro-like...

[22:15]

<crweb>

it is distro-like

[22:16]

<crweb>

its for an embedded device

[22:16]

<Ycros>

hmm

[22:16]

<Ycros>

openmoko have chosen openembedded as their build env it seems

[22:16]

* Ycros is considering an openmoko phone

[22:16]

<crweb>

yes, that is a build enviroment

[22:17]

<crweb>

build enviroment assumes you already have a working rootfs etc

[22:17]

<crweb>

eigma: bootstrapping is what happens when gcc is used to build the base system, when there is no gcc to build with ;)

[22:18]

<crweb>

eigma: its the first build of glibc, gcc, and the kernel

[22:18]

<crweb>

what usually happens is: you take compiler, and compile everything you need to have a running system, the very base of one

[22:18]

<eigma>

crweb: I know how to build a cross-compiler, thanks

[22:19]

<crweb>

then, using that base, you recompile everything using itself

[22:19]

crweb: neuros-bsp isn't distro-like because it provides no tools to do things like build stuff, install packages, etc.... it's pretty much a cross-compiler and kernel, have fun

[22:19]

crweb: I suppose, strictly speaking, that is a distro....

[22:19]

... but not a very easy one to work on

[22:19]

<crweb>

derobert that has nothitng to do with distro's

[22:19]

<crweb>

so if you want automake/autoconf build it

[22:19]

<crweb>

you don't need to cause your distro already has it

[22:20]

<eigma>

proposal: sources for arm binutils, gcc, libc in svn with instructions; binary tarball on the web site, that users are recommended to use; neuros-bsp uses this toolchain (whether the user built it or downloaded it). no binaries in svn, easy development because "getting a toolchain" is simply tar xzf

[22:20]

<crweb>

derobert it doesn't need to provide autoconf, cause it uses yours

[22:20]

<crweb>

derobert the only reason IT would need autoconf is if it was going to compile autoconf for the osd

[22:21]

<crweb>

derobert automake/autoconf isn't used in bootstrapping a system. Its straight make files. just like the linux kernel

[22:21]

<crweb>

because there is nothing to autoconf

[22:21]

<crweb>

its constant

[22:21]

crweb: of course no autoconf there...

[22:22]

<crweb>

derobert thats where scratchbox comes in

[22:22]

<crweb>

you use automake/autoconf with the toolchain in scratchbox

[22:22]

<crweb>

you already have automake/autoconf, your distro gave it to you. all a toolchain is, is libs and crosscompilers

[22:23]

crweb: I heard before that scratchbox provided some way to make cross-compiling easier.... because, right now, it can be damn well difficult. And the OSD isn't self-hosting in any sane amount of time.

[22:23]

<crweb>

in neuros-bsp, you are building a distro

[22:23]

<crweb>

outside of neuros-bsp you use the toolchain, and whatever you want

[22:24]

<eigma>

derobert: re: cross-compiling is difficult. can you give examples?

[22:24]

crweb: I'm building a rather anemic distro, since it lacks anything like dpkg, rpm, portage, etc... or even a simple way to have './configure && make && make install' work

[22:24]

<crweb>

derobert You don't run anything on the osd anyway

[22:25]

<crweb>

derobert what good would it be to have it on the OSD?

[22:25]

eigma: any number of packages that either (a) have no way to specify "use this gcc, damn it" (though a little makefile hacking can work around that) or that want to run the code they just compiled

[22:25]

<crweb>

automake autoconf run ON your pc

[22:25]

crweb: umm, my *cell phone* has package management!

[22:25]

<crweb>

derobert thats the packages fault.

[22:25]

<Ycros>

crweb: I'm unclear as to what end solution you're suggesting

[22:25]

<crweb>

derobert your cellphone isn't read only

[22:25]

<crweb>

derobert package managers are not base system software

[22:26]

crweb: neither is an OSD with a hard disk, flash, or network attached

[22:26]

<crweb>

you want want you build it.

[22:26]

<crweb>

it is a distro

[22:26]

<crweb>

everything else is system software

[22:26]

<crweb>

rpm, dpkg, thats all system software

[22:26]

<crweb>

not part of the base system

[22:26]

crweb: and, as far as being hard to cross-compile being the package's fault... well, yeah. It was probably never designed for it.

[22:27]

<crweb>

derobert well thats actuall autoconf's fault it is very broken for cross compiling

[22:27]

<[g2]>

hence a main problem with cross-compiling (never designed for it)

[22:27]

<crweb>

My MAIN POINT:

[22:27]

crweb: irrelevant who's fault it is, quite relevant that we have to deal with it.

[22:27]

<Ycros>

ahh, finally, your main point :P

[22:28]

<crweb>

we can't modify neuros-bsp. It is constant. it IS NOT for developing system software. its for making your system bootable to RUN system software.

[22:28]

<Ycros>

uhha

[22:28]

<crweb>

what we can do, is port the toolchain to scratchbox. OR write instructions on how to modify autoconf scripts to cross-compile things

[22:28]

<eigma>

is something following up to that?

[22:28]

<Ycros>

that's totally reasonable

[22:29]

<Ycros>

scratchbox or openembedded is fine with me

[22:29]

crweb: ok, I understand the phrases "base system" and "system software" quite differently than you... but terminology is a silly thing to argue over...

[22:29]

<crweb>

derobert package management is not a base software. You can have a fully function OS without a package manager

[22:29]

<crweb>

;)

[22:30]

<crweb>

I'm a linux from scratch user

[22:30]

<crweb>

I do it everyday

[22:30]

<Ycros>

crweb: how do you deal with cruft?

[22:30]

crweb: sure, you can have a fully functional OS without a bloody kernel, too.

[22:30]

<crweb>

derobert you can? there is that neat java OS that runs in a browser

[22:31]

<crweb>

derobert base system is the minimal requirements to run software. Software such as a package manager. BUT anyway

[22:31]

crweb: yes. Mac OS pre-X semi-happily lived without a kernel... or protected memory... until it crashed :-(

[22:32]

<crweb>

what we are seeing int he repo's other than neuros-bsp

[22:32]

<crweb>

is neuros's software

[22:32]

well, a lot of neuros stuff is in neuros-bsp, too, I think

[22:32]

<crweb>

they are hard to develop for, yes. They aren't using automake and autoconf

[22:32]

<crweb>

derobert incorrect

[22:32]

<crweb>

derobert the bsp was purchased

[22:33]

<eigma>

this seems like a very pointless argument to me.. how many packages do people want to run on the OSD that needs to run its own code during the build process?

[22:33]

<crweb>

eigma: most

[22:33]

<eigma>

examples

[22:33]

<crweb>

eigma: samba, apache, java

[22:33]

<crweb>

need i go on?

[22:33]

I thought they've modified it a fair bit... e.g., I don't think that is anything near a stock kernel anymore

[22:33]

<Ycros>

configure scripts...

[22:33]

eigma: autoconf encourages such fun

[22:33]

<crweb>

derobert it was purchased like that

[22:33]

<crweb>

derobert we are modifing it yes

[22:34]

<crweb>

derobert but the apps that people are deving for have nothing to do with the kernel

[22:34]

<crweb>

derobert osdmain, nmsd, cooler, nano-x

[22:34]

<crweb>

derobert you'll find all of that outside of the bsp

[22:34]

<eigma>

do I understand correctly, that the root of the problem is that the build systems of many packages require the ability to run code for the target, on the host?

[22:34]

crweb: well, I wouldn't assume that people don't want to modify the kernel...

[22:34]

<crweb>

eigma: its called self tests

[22:34]

<crweb>

derobert BUT THAT isn't broken

[22:34]

<crweb>

;)

[22:35]

<crweb>

if you are modifying the base fs, then yes you are dev'ing for the bsp. thats what i do

[22:35]

<eigma>

crweb: how does scratchbox solve this problem?

[22:35]

<crweb>

but it has nothing to do with the autoconf/make and other build problems that these people are speaking of

[22:36]

<crweb>

eigma: it uses qemu to exe the tests via emulating an arm cpu

[22:36]

<crweb>

derobert if you are doing kernel work, you're not conserned about a dev enviroment

[22:36]

crweb: well, it could be much better (e.g., patches from stock kernel tree)... but, no, it probably isn't broken. Except that it is still is some old version

[22:36]

crweb: sure I am... I have to compile the kernel.

[22:36]

<crweb>

derobert USING the kernels enviroment

[22:37]

<crweb>

its there, it is provided by the kernel

[22:37]

<crweb>

same with busybox

[22:37]

<crweb>

there is nothing broken inside of the bsp

[22:37]

<crweb>

and thats 2 different issues, like i said

[22:38]

<crweb>

compiling 3rd party apps using the tool chain, and bootstrapping are 2 different systems and should remain seperate

[22:38]

<eigma>

crweb: back to your example of samba, you're saying that ./configure --target=arm-linux fails?

[22:38]

<crweb>

eigma: absolutely

[22:38]

<crweb>

eigma: it does self tests

[22:38]

<eigma>

I just need to see something fail, and maybe I'll undersatnd the problem better

[22:39]

<crweb>

eigma: it autoconf compiles mini programs that it executes to test the abilities of the system

[22:39]

<Ycros>

how does openembedded solve the problem?

[22:39]

<crweb>

eigma: and to make sure things compiled correctly

[22:39]

eigma: if you look at configure scripts, a lot of times it compiles a program and tries to run it

[22:39]

eigma: obviously, if you compile arm code and try and run it on x86, that fails pretty badly

[22:39]

<crweb>

Ycros: it doesn't, they modify the scripts

[22:39]

<eigma>

yeah, I know that; but autoconf explicitly supports cross-compiling, so I would assume that it would "know what do to" (TM)

[22:39]

<eigma>

I ugess not.

[22:40]

<crweb>

people don't know autoconf/automake very well

[22:40]

<crweb>

so scratchbox was invented

[22:40]

<Ycros>

crweb: ah.

[22:40]

crweb: yes, the real question... how does scratchbox solve the building problem?

[22:40]

<Ycros>

crweb: Then I think I prefer scratchbox.

[22:40]

<crweb>

derobert [22:36] <crweb> eigma: it uses qemu to exe the tests via emulating an arm cpu

[22:41]

crweb: cool, and how far has someone gotten with it and the OSD?

[22:41]

<Ycros>

my next question is: what are we waiting for?

[22:41]

<crweb>

derobert also when you type make install it installs to a clean virtual rootfs

[22:41]

<crweb>

derobert www.limesg.com

[22:41]

<crweb>

i didnt' use the neuros toolchain though

[22:41]

crweb: that is one thing wrong with bsp, last I checked, it doesn't understand make vs. make install...

[22:41]

<crweb>

it still runs fine, and is compatible

[22:42]

<crweb>

derobert ?

[22:42]

crweb: last I checked, it did things requiring root privs in 'make' instead of 'make install

[22:42]

<crweb>

derobert the bsp is setup to do 1 thing. give you a running fs and base linux system.

[22:42]

<crweb>

derobert the root privs were for creating dev nodes when you run setup-rootfs

[22:42]

<crweb>

that is all

[22:43]

<crweb>

nothing more

[22:43]

<crweb>

i don't even use fakeroot

[22:43]

crweb: do you run it as actual root?! Honestly, after the time it did rm -Rf $(SRC_DIR), I seriously don't trust it

[22:43]

<crweb>

derobert no i dont

[22:44]

<crweb>

derobert you don't have to, it is only for making the dev nodes

[22:44]

<crweb>

derobert install sudo

[22:44]

yes, sudo would be actual root...

[22:44]

<Ycros>

heh

[22:44]

<crweb>

and the only time it is called is while making the dev nodes

[22:44]

<Ycros>

I build it fine without fakeroot

[22:45]

<crweb>

i don't even use setup-rootfs

[22:45]

<crweb>

i don't use root at all

[22:45]

<Ycros>

aye

[22:45]

<crweb>

you don't need root to compile busybox, or the kernel

[22:45]

<crweb>

ever

[22:45]

which is a permission that absolutely positively should be given to no one but root. Given 'sudo mknod' to non-root is effectively giving them root....

[22:45]

<crweb>

whatever, thats not the issue

[22:45]

no, it's not

[22:45]

<crweb>

that is a self contained system

[22:46]

<crweb>

we are talkinga bout 2 different things like i said

[22:46]