18:27 < bgat> I'm trying to set up an armel rootfs.  Looking at rootfs.html, it appears as though I don't need 
              very many packages--- just the eleven listed under "Required".  Is this correct?
18:29 < zumbi_> shuold be
18:30 < zumbi_> s,shuold,should
18:32 < bgat> k
18:33 < bgat> What do I have to do with the "Base" packages?  Are those optional only?  Reason I ask is, apt 
              isn't building; it dies with "cannot remove 'debian/apt/usr/bin/apt-ftparchive': No such file or 
              directory".
18:37 < codehelp> bgat: no, required are just the ones that are unpacked first
18:37 < codehelp> in debootstrap, these are used for Pre-Depends
18:37 < codehelp> in Emdebian, the distinction is largely irrelevant
18:37 < codehelp> but you need both categories to have some packages
18:37 < codehelp> so I retain both and each rootfs needs both
18:38 < codehelp> the rootfs scripts are under intense development at the TCL worksession and there is quite a 
                  lot of breakage right now
18:38 < codehelp> particularly with login problems where the packages install but the root password cannot be 
                  set in advance
18:38 < codehelp> i.e. the root password comes from /dev/random and you can't login
18:38 < codehelp> :-(
18:43 < wookey_> if you just set init to runa shell insteadd of getty/login then you can ignore above problem
18:43 < wookey_> which is what svn emdebian-tools is doing right now
18:43 < wookey_> bgat ^
18:45 < bgat> holdonasec, NMI.  :)

19:42 < bgat> I'm back.
19:48 < bgat> seems like emdebian has been under "intense development" for quite some time--- and that's not a
              complaint at all.  It's a difficult problem to solve.  I'm just trying to use it as a
              debian-like embedded rootfs.
19:48 < bgat> ... for now.  :)
19:49 < bgat> so, to satisfy Pre-Depends I need dpkg, and dpkg isn't building with emdebuild.
19:49 < bgat> It dies during configure with: "checking for va_copy ... configure: error: cannot run test
              program while cross compiling"
19:56 < zumbi_> do you have g++ cross toolchain?
19:56 < bgat> dpkg -l | grep g++
19:56 < zumbi_> is it failing on configure? neil says it should work
19:56 < bgat> ii  g++-4.2-arm-linux-gnueabi                 4.2.4-1
19:57 < bgat> ii  g++-4.3-arm-linux-gnueabi                 4.3.0-5
19:57 < zumbi_> yes
19:59 < bgat> ok, so I do a "emsource -b dpkg --verbose"
19:59 < bgat> and it stops at "Recording that the Emdebian SVN patches are out of date for dpkg."
19:59 < wookey_> which version of dpkg? - it used to work
19:59 < wookey_> neil is on the case....
20:00 < bgat> dpkg-1.14.19

20:00 < bgat> emdebian svn 3993
20:00 < wookey_> hmm it's true  - last one we did was 1.14.18
20:00 < wookey_> either there is a patch that is not applying to the new one or some unhelkpful test has been 
                 added
20:01 < bgat> "Skipping emdebian-control.patch, unable to apply it."
20:01 < wookey_> neil will have a go at sorting it out for you - give him 10 mins
20:01 < bgat> I just tweaked emdebian-control.patch
20:02  * bgat closes eyes, turns crank
20:02 < bgat> nope
20:03 < wookey_> tomorrow is 'make an autobuilder' day so we get to find out this stuff sooner
20:03 < bgat> not surprising, since I have no idea how emtools work
20:03 < wookey_> just wait a mo and it'll be in svn for you....
20:04 < bgat> for cdebconf:
20:04 < bgat>  home/bgat/emdebian/workingdir/trunk/c/cdebconf/trunk/cdebconf-0.131/src/confmodule.c:21:30: 
              error: debian-installer.h: No such file or directory
20:05 < bgat> apt-get install libdebian-installer4-dev?
20:05 < bgat> apt-cross --install libdebian-installer4-dev?
20:06 < bgat> just did both, now let's see what emsource -b cdebconf does...
20:06 < bgat> ouch...
20:06 < wookey_> you need to copy arm-linux-gnu.cache to  arm-linux-gnueabi.cache and check it's right
20:07 < wookey_> we haven't really been worrying about armel yet...
20:08 < bgat> crap...
20:08 < bgat> when I did the apt-cross --install libdebian-installer4-dev, it updated my libc6 for armel.
20:08 < bgat> "no problem", I thought.
20:09 < bgat> but now I need newt.h for cdebconf, and apt-get is telling me this:
20:09 < bgat> The following packages have unmet dependencies:
20:09 < bgat>   libc6-dev-armel-cross: Depends: libc6-armel-cross (= 2.7-10) but 2.7-12 is to be installed
20:09 < bgat> E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
20:09 < wookey_> see http://wiki.debian.org/EmdebianGuide?highlight=%28emdebian%29
20:09 < wookey_> and you need to add a dep for libncursesw5-dev
20:10 < wookey_> that'll probably fix it
20:10 < bgat> apt-get -f install returns:
20:10 < bgat> The following packages will be REMOVED:
20:10 < bgat>   g++-4.2-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi libc6-dev-armel-cross
20:10 < bgat>   libpcre3-dev-armel-cross libstdc++6-4.2-dev-armel-cross libstdc++6-4.3-dev-armel-cross
20:10 < bgat>   libstdc++6-4.3-pic-armel-cross
20:10 < wookey_> ah, now that stuff is zumbi's problem :-)
20:11 < bgat> bad timing, I was hoping to have this rootfs stuff sorted out in the next couple of hours.  
              *sigh*
20:11 < wookey_> the autobuilder for keeping that uptodate is _almost_ working
20:11 < wookey_> bgat: I think that's optimistic for armel - you are probably breaking new ground with 
                 emdebian+armel
20:12 < bgat> bummer
20:12 < wookey_> bgat: move your armel cache file out of the way and do an emsource -c
20:12 < wookey_> new patch just uploaded.
20:13 < wookey_> what arch are you building on? i386?
20:13 < bgat> emsource -c 'ing now.
20:13 < bgat> amd64
20:13 < codehelp> use apt-cross -a armel -i libc6
20:14 < wookey_> OK arm build for dpkg 1.14.19 now works, so you should be able to work it out
20:14 < wookey_> send us a cache file to check in when it's working
20:19 < bgat> aah, I see what you're doing now...
20:22 < bgat> codehelp: apt-cross -a armel -i libc6-dev
20:24 < bgat> schweet!!  
20:24 < bgat> I now have a boatload of dpkg-*deb files
20:25 < bgat> just copied arm-linux-gnu.cache to arm-linux-gnueabi.cache.  The va_copy thing appears to be the 
              only issue.
20:30 < codehelp> make sure you remove any .deb files in the package directories before trying a build
20:30 < bgat> ok
20:34 < bgat> wow, cdebconf wants a lot of stuff.
20:50 < bgat> mktemp needs arm-linux-gnu.cache copied to arm-linux-gnueabi.cache
20:54 < bgat> !w00t!  I have built everything in the "Required" and "Base" lists for armel.
21:00 < bgat> alright, then, how do I drive emsandbox?
21:25 < codehelp> bgat: without armel packages in a repository (somewhere), emsandbox can't get the .debs it 
                  needs
21:25 < codehelp> to use your own repo, you need machine:variant support
21:25 < codehelp> if you send an SSH key to wookey, he can give you commit access to Emdebian
21:26 < bgat> not sure I want commit access, I tend to commit-before-think.  :)
21:26 < codehelp> create a local repo using reprepro and get used to how it works
21:26 -!- ruoso [~ruoso@195.23.92.2] has quit [Quit: Ex-Chat]
21:27 < codehelp> when we have an autobuilder, I'll be building armel - please send me the 
                  arm-linux-gnueabi.cache file 
21:27 < codehelp> to populate the repo, you need to include the .changes files
21:27 < codehelp> reprepro ...foo.. unstable include <path>.changes
21:27 < bgat> can you chat me through the machine:variant stuff?
21:28 < codehelp> once you have a repo, you create a directory $WORK/machine/$name/
21:28 < codehelp> bah
21:28 < codehelp> $WORK/machine/$name/default
21:28 < codehelp> you can have ../$name/$variant for more than one type of the same machine
21:29 < codehelp> then copy the skeleton files from emdebian-tools - packages.conf, setup.sh and config.sh
21:29 < codehelp> in packages.conf, you specify the apt location of the local repo
21:29 < codehelp> anything that apt can find is fine
21:29 < codehelp> put that under MIRROR
21:29 < codehelp> again, this is the first time anyone has done this . . . . for armel :-)
21:30 < codehelp> $WORK is your emdebian working directory

15:23 < bgat> ok, I think I've got an armel emdebian going.  mostly.
15:24 < bgat> it's a bit creaky in spots, maybe someone here can help iron out some of it?
15:24 < bgat> stuff that steadfastly refuses to build: libgcc1 libstdc++ libncurses5 libblkid1 libuuid1
15:25 < bgat> (I understand the reasons behind some of those, Google has been my friend all night)
15:26 < bgat> I also set up a local repo, so I could use emsandbox.
15:26 < codehelp> "a bit creaky" is a good summary of exactly where we are right now
15:26 < codehelp> libgcc1 is a PITa
15:26 < bgat> :)
15:27 < codehelp> try building it inside a cross-building chroot
15:27 < codehelp> there are various problems that I have not been able to pin down
15:27  * codehelp wishes libgcc1 would go to /dev/null really, really, soon.
15:27 < bgat> I don't mind grabbing libgcc1 and libstdc++6 from the armel repo of debian proper.  I have a 
              hunch the emdebian packages would produce very similar output, since there isn't much there 
              that's optional.
15:28 < codehelp> Why do you need libblkid1 ?
15:29 < bgat> when I run emsecondstage, I get some wierdness.  First, it wants to see /usr/sbin/install-info, 
              which in debian proper comes from dpkg.  No such thing in emdebian, apparently.
15:29 < codehelp> use 1.1.3 which creates a dummy one
15:29 < bgat> how do I "use 1.1.3"?
15:29 < codehelp> all you need is echo "#!/bin/sh" > /usr/sbin/install-info
15:29 < codehelp> dpkg seems to insist that it exists
15:29 < codehelp> apt-get install emdebian-tools :-)
15:30 < codehelp> new version - changelog posted to the list today
15:30 < codehelp> the dpkg version of install-info is perl
15:30 < codehelp> there are a lot of changes in the root filesystem setup in 1.1.3
15:32 < bgat> yea, saw the post about it.  I'm apt-get'ing it now.
15:32 < bgat> :)
15:32 < bgat> and that's how I "fixed" the missing install-info, too.  I guess I do still get lucky sometimes! 
              :)
15:33 < bgat> so, I'm going to blow away my reprepro, and rebuild all the packages therein under 1.1.3 and see 
              what I get.  
15:35 < bgat> I think I ended up needing libblkid1 because I drug in a debian/armel package somewhere that 
              I've forgotten to mention.  e2fsprogs, maybe?
15:36  * bgat does an apt-get dist-upgrade first.
15:39 < codehelp> no need to rebuild all packages
15:40 < codehelp> the main differences in the scripts preparing the root fs, rather than the packages 
                  themselves
15:40 < bgat> aah

15:40 < bgat> ok
15:40 < codehelp> have you deleted them already?
15:40 < codehelp> just upgrade the emdebian-tools packages and rebuild the root 
                  filesystem with those
15:40 < bgat> yep, but it's easy to regen now.  :)
15:41 < bgat> (got lots of practice lately)
15:41 < bgat> In case I forget to mention, I'm a huge debian fan and emdebian is just 
              more of the same awesome goodness.  Times ten.
15:41 < bgat> kudos
15:42 < bgat> rebuilding my reprepro now.
15:42 < bgat> (I hadn't trashed the emdebian workingdir)
15:46 < bgat> as of last night, when I ran emsecondstage on the target, after resolving 
              the install-info and related stuff, it ended up here:
15:46 < bgat> Setting up libc6 (2.7-12em1) ...
15:46 < bgat> BusyBox v1.9.2 (2008-06-03 22:33:02 CDT) multi-call binary
15:46 < bgat> Usage: init
15:46 < bgat> Init is the parent of all processes
15:46 < bgat> ... and then just hung.
15:47 < bgat> also, /dev/console needs to be in the emsandbox output.  otherwise I can't 
              seem to run the rootfs.
15:48 < bgat> er, I can boot it fine, but userland complains.

15:50 < bgat> also, some of my packages were built at 399x, and now emdebian svn is at
              400x.  Are there large-scale changes that would merit rebuilding a bunch of
              my packages?  Or are they just small tweaks?
15:50 < bgat> hi, wookey
15:51 < codehelp> bgat: changes in 1.13 solve that problem - rebuild the root filesystem
15:51 < bgat> codehelp: ... but not the packages that go into emsandbox, right?
15:51 < codehelp> yes
15:52 < codehelp> what do you mean by 399x ? the SVN revision? that is a combined value
                  for patches and emdebian-tools scripts and a whole load of other things
15:53 < bgat> right.  svn revision number.
15:53 < bgat> Got a meeting coming up in a sec, will be gone for a few minutes.  Darn,
              just when things are rolling again...
15:54 < bgat> ok, so I use emsandbox's tarball, adding only dev/console, and boot it.
15:54 < bgat> # export PATH
15:54 < bgat> # /emsecondstage
15:54 < bgat> mount: error while loading shared libraries: libblkid.so.1: cannot open
              shared object file: No such file or directory
15:54 < bgat> _now_ I remember how I ended up with libblkid1.  :)
15:54 -!- svolpe [~Gerrath_@70.89.111.251] has quit [Ping timeout: 480 seconds]
15:54 < bgat> bacinasec
16:04 -!- svolpe [~Gerrath_@70.89.111.251] has joined #emdebian
16:23 < bgat> I'm back
16:23 < bgat> anyone know why emsecondstage wants libblkid.so.1?
16:30 < bgat> darnL
16:30 < bgat> darn:
16:30 < bgat> # emsource -b libblkid1
16:30 < bgat> ...
16:30 < bgat> Skipping emdebian-rules.patch, unable to apply it.
16:30 < bgat> Recording that the Emdebian SVN patches are out of date for e2fsprogs.
16:31 < codehelp> true
16:31 < codehelp> :-)
16:31 < bgat> is it just a s/6/8 in emdebian-rules.patch?
16:32 < bgat> (I'll let you know in a sec)
16:32 < codehelp> no
16:32 < bgat> darn :(
16:32 < codehelp> the rules patch is old - it predates the change to allowing udebs
16:32 < codehelp> i.e. before FOSDEM
16:33 < codehelp> it needs to allow udebs and then see if it builds
16:33 < codehelp> the default emdebian builds don't need it
16:34 < codehelp> (where it == e2fsprogs in entirety)
16:35 < bgat> emsecondstage seems to want libblkid.so.1, which comes from e2fsprogs (?).

16:35 < bgat> I'm confused.  Enlighten me please?
16:37 < codehelp> emsecondstage doesn't need anything - it would be debootstrap bringing in extra deps
16:38 < codehelp> and that would happen with Debian packages alongside Emdebian ones
16:38 < bgat> yea, I'm seeing that in the emsecondstage script now
16:38 < codehelp> emsecondstage just runs dpkg --configure -a on the installed packages
16:38 < codehelp> debootstrap works out which ones to install
16:38 < codehelp> from the suite script
16:38 < codehelp> which suite script are you using/
16:38 < codehelp> emdebian.crossd ?
16:38 < codehelp> emdebian.gpe ?
16:39 < codehelp> those have also changed (a LOT) in 1.1.3
16:39 -!- svolpe [~Gerrath_@70.89.111.251] has quit [Ping timeout: 480 seconds]
16:39  * codehelp needs to post to the list that old custom suite scripts are v.v.v.v.broken
16:47 < bgat> emdebian.crossd
16:48 -!- svolpe [~Gerrath_@70.89.111.251] has joined #emdebian
16:49 < bgat> ok, the only Debian packages I'm bringing in are libgcc1, libncurses5, and libstdc++6
16:49 < bgat> and emsandbox won't proceed without them
16:50 < bgat> what is a "cross-building chroot"?
16:52 < codehelp> I'm still working on e2fsprogs - it is a dependency in emdebian.crossd so it's OK
16:52 < codehelp> a cross-building chroot is a chroot that has cross-compilers installed
16:52 < codehelp> sudo empdebuild create
16:53 < bgat> ... as opposed to just having the cross compilers installed in my main root?
16:53 < codehelp> yes
16:54 < codehelp> gcc-4.3 breaks due to some random config that I haven't been able to identify except that it
                  exists on "normal" systems and not in a chroot
16:55 < bgat> odd:
16:55 < bgat> $ sudo empdebuild create
16:55 < bgat> ...
16:55 < bgat> E: Failed getting release file http:///debian/dists/unstable/Release
16:55 < bgat> (three forward slashes)
16:57 < bgat> also:
16:57 < bgat> $ arm-linux-gnueabi-gcc --version
16:57 < bgat> arm-linux-gnueabi-gcc (GCC) 4.2.4 (Debian 4.2.4-1)
16:58 < zumbi_> that is my fault i have to update it
16:58 < zumbi_> i have been working on the autobuilder.. so we do not have to worry about it
16:58 < bgat> zumbi_: no rush, I haven't been able to get 4.3 to build armel Linux kernels.  I'm quite happy
              with 4.2.x.  :)
16:59 < bgat> I mean, it builds them--- they just won't urn.
16:59 < bgat> s/urn/run
16:59 < zumbi_> that is odd
16:59 < zumbi_> are you using emdebian one?
17:00 < bgat> um, not sure.  probably not.
17:00 < zumbi_> i am currently doing (amd64) arm and armel
17:00 < bgat> I'm amd64 as well
17:00 < codehelp> bgat: empdebuild create - looks like a missing primary mirror set up
17:01 < codehelp> that's a bug in 1.1.3
17:01 < zumbi_> bgat: i'll give you a voice when newer packages are in the repo (4.3)
17:02 < codehelp> you could add a primary (ftp.fr.debian.org) in /etc/emsource.conf or ~/.apt-cross/emsource
17:02 < codehelp> e2fsprogs fails to cross build at the latest version
17:02 < codehelp> I'll commit the updated patches for you to see the result
17:03 < bgat> I have primary: ftp.fr.debian.org in my /etc/emsource.conf
17:04 < codehelp> bah - that'll need a different fix
17:04 < bgat> added it to ~/.apt-cross/emsource, and now empdebuild seems happy.
17:07 < codehelp> ah, ok
17:08 < codehelp> I think I've found that bug, I'll test and upload in 1.1.4 or 1.2.0
17:12 < bgat> still empdebuild'ing
17:12 < bgat> so with that chroot, just do an emsource -b libgcc1?
17:19 < bgat> empdebuild "cannot find a native gcc for armel"
17:25 < codehelp> sudo empdebuild --save-after-login login
17:25 < codehelp> see about the network config in the chroot - it may be bust
17:25 < bgat> it is.  :)
17:25 < bgat> once in, I do apt-get install gcc-4.2-arm-linux-gnueabi ?
17:25 < codehelp> emsetup -a armel
17:26 < codehelp> you need more than just gcc-foo
17:26 < bgat> k
17:26 < codehelp> e2fsprogs still bust. :-(
17:27 < bgat> that's ok, if I can build libgcc1 and libstc++6, I don't think I need it ?
17:32 < zumbi_> yes, for the runtime
17:34 < wookey> hi bgat, I'm trying to play the same game as you but people keep asking me work questions
17:40 < bgat> wookey: heh, today this _is_ my work.  and I still keep getting interrupted!  (joys of working 
              at home)
17:41 < wookey> well it's supposed to be my work too, but other people think other things are more important
17:41 < bgat> :)
17:41 < bgat> ok, so I've got emsetup finished, doing an emsource --arch armel -b libgcc1...
17:48 < bgat> hmmm.  emsource went for gcc-4.1...
17:49 < bgat> checking assembler for .sleb128 and .uleb128... 
              /trunk/g/gcc-4.1/trunk/gcc-4.1-4.1.2/src/gcc/configure: line 14756: test: too many arguments
18:02 -!- bgat [~bgat@adsl-75-23-65-188.dsl.peoril.sbcglobal.net] has quit [Read error: Connection reset by 
          peer]
18:14 -!- bgat [~bgat@adsl-75-23-80-27.dsl.peoril.sbcglobal.net] has joined #emdebian
18:14 < bgat> did I miss anything?  :)
18:14 < bgat> (network hiccup)
18:17 < codehelp> nah
18:17 < codehelp> except don't use busybox em6 from the current repo
18:17 < codehelp> it's bust
18:18 < bgat> em4 is ok?
18:19 < bgat> gcc-4.1's emdebian-control.patch calls out arm and armeb.  why not armel?
18:20 < bgat> and how do I add armel and make it "stick"?
18:20 < codehelp> debian/control.m4
18:21 < bgat> and then emdebuild --arch armel?
18:21 < zumbi_> bgat: can you test if you can get an unstable gcc-4.3 armel for amd64 from emdebian.org 
                repository?
18:21 < bgat> if you can tell me how to do that, yes.  :)
18:22 < zumbi_> do you have emdebian.org unstable source.list ?
18:22 < codehelp> yes - emdebian-tools is installed, so he should have that
18:23 < bgat> libiberty/libiberty.a
18:23 < bgat> ../libiberty/libiberty.a: could not read symbols: Archive has no index; run ranlib to add one
18:23 < bgat> (gcc-4.1)
18:23 < bgat> zumbi_: dunno, where would that file be?
18:24 < zumbi_> /etc/apt/sources.list or /etc/apt/sources.lis.d/*
18:24 < bgat> deb http://ftp.fr.debian.org/debian unstable main
18:25 < codehelp> /etc/apt/sources.list.d/emdebian.sources.list
18:25 < bgat> in /etc/apt/sources.list
18:25 < codehelp> .../list.d/
18:25 < bgat> deb http://www.emdebian.org/debian/ unstable main
18:25 < bgat> in /etc/apt/sources.list.d/emdebian.sources.list
18:25 < zumbi_> fine
18:25 < zumbi_> $ apt-cache search armel
18:25 < zumbi_> $ apt-get install libc6-armel-linux libc6-dev-armel-linux
18:25 < zumbi_> $ apt-get install binutils-arm-linux-gnueabi
18:25 < zumbi_> $ apt-get install gcc-4.2-arm-linux-gnueabi
18:26 < zumbi_> sorry for flooding
18:26 < zumbi_> $ apt-get install g++-4.2-arm-linux-gnueabi
18:26 < codehelp> no problem - please make notes in the wiki so that others can find answers when IRC is quiet
18:26 < bgat> E: Couldn't find package libc6-armel-linux
18:26 < zumbi_> http://wiki.debian.org/EmdebianToolchain
18:27 < bgat> libc6-armel-cross, maybe?
18:28 < zumbi_> yes
18:28 < zumbi_> a mix
18:28 < bgat> # arm-linux-gnueabi-gcc --version
18:28 < bgat> arm-linux-gnueabi-gcc (Debian 4.3.0-5) 4.3.1 20080523 (prerelease)
18:29 < zumbi_> yeap
18:29 < zumbi_> get g++ too
18:29 < bgat> ok, throwing libgcc1 at it.
18:29 < zumbi_> wow.. that's brave
18:29 < bgat> emsource --arch armel --build libgcc1  :)
18:30  * zumbi_ modifies the wikipage
18:30 < bgat> I can't break this system any more than it already is.  :)
18:30 < bgat> so how does arm get their libgcc1?
18:33 < zumbi_> arm target packages, you mean?
18:33 < zumbi_> canadian cross'd
18:33 < bgat> emdebian arm libgcc1 package, yes.
18:33 < zumbi_> we got a REVERSE_CROSS var in sources that helps a bit
18:33 < bgat> crap.  you mean that if I had a debian armel running, that would make it easier to build 
              emdebian armel libgcc1?
18:34 < zumbi_> nooo... it is cross compiled from source
18:34 < codehelp> it's not a full canadian cross - more like cross building gcc as a normal package instead of 
                  as a cross compiler
18:35 < codehelp> ignore the fact that it is a compiler and build it as if it was just another library
18:35 < bgat> ok
18:35 < codehelp> but it breaks frequently
18:35 < codehelp> current libgcc1 for ARM comes from gcc-4.3 which is the only Debian version of gcc that 
                  builds libgcc1
18:36 < codehelp> libgcc1 breaks all the rules - it should be libgcc999 by the number of times it has changed
18:36 -!- AD-N770 [~jep@core.fluendo.com] has quit [Quit: Ex-Chat]
18:36 < bgat> ok, so how do I duplicate that feat for armel?
18:41 < bgat> emsource --arch armel --build gcc-4.3?
19:28 < bgat> what does it take to get the gcc-4.3 Emdebian SVN patches up to date?
19:28 < codehelp> a fair bit of fettling
19:28 < codehelp> :-)
19:29 < codehelp> you need to view the current file and the patch and get the changes transferred manually
19:29 < codehelp> I don't have time tonight, sorry
19:29 < bgat> alright, throw me a bone here.  how can I get a libgcc1 and libstdc++6 for armel or arm?
19:29 < bgat> maybe I should just use the pre-built emdebian arm packages for a little while longer...
19:32 < codehelp> libgcc1 for ARM is in the repo at 1:4.3.0-4em1 - do you have dependency issues using that 
                  one?
19:32 < codehelp> (same for libstdc++6)
19:32 < bgat> dunno.  I can't remember how to switch my system over to arm...
19:34 < codehelp> sadly, I think you are ahead of the development and there isn't a lot I can do, at least 
                  right now
19:34 < bgat> no problem.  if arm works, I can use that near-term.
19:34 < codehelp> I can't get ARM working properly yet (although the root filesystem does install)
19:35 < bgat> close enough.
19:35 < bgat> :)
19:35 < codehelp> it still needs tweaks to be useful (on balloon anyway)
19:35 < codehelp> and it has only had any testing at all on a single embedded device
19:35 < bgat> well, it's about to be two of them.  :)
19:35 < bgat> sudo emsetup --arch arm?
19:35 < codehelp> no need to compile anything
19:35 < codehelp> use the existing packages
19:35 < bgat> ok
19:36 < codehelp> sudo emsandbox -a arm create
19:36 < bgat> ok
19:36 < bgat> working...
19:36 < codehelp> there are three main problems with it right now:
19:36 < codehelp> 1. you must set the root password interactively which means having a bootloader environment 
                  available that can run a chroot
19:37 < bgat> k
19:37 < codehelp> 2. you need to ensure that sysfs is mounted via /etc/inittab - follow the examples in the 
                  same section for proc
19:37 < bgat> k
19:37 < codehelp> 3. there is a halt in the second stage install (on the device) where passwd insists on you 
                  typing 'y' to confirm some weird shadow passwd problem
19:37 < bgat> k
19:38 < codehelp> and not all of the modules appear to be mounted
19:38 < bgat> once I"m past all that, during a normal boot does it go to a login or something?  on the armel 
              rootfs, it went straight to shutdown...
19:38 < bgat> shoot, late for another meeting...  :(
19:38  * bgat wonders how he ever gets any work done.
19:46 < codehelp> yes, it goes to login
19:46 < codehelp> the armel rootfs direct to shutdown is likely to be the sysfs issue
19:50 < codehelp> if I can get busybox em6 fixed and reuploaded, I'll make 1.1.4 with those fixes too.
20:05 < bgat> ok
20:05 < codehelp> also, there seem to be problems with mounting - proc and sysfs get mounted more than once 
                  but don't seem to cause any problems by doing so - weird
20:05 < bgat> Is that the kind of stuff that can be done in $MACHINE/$VARIANT/...something?
20:06 < codehelp> not the root passwd thing - that must be interactive due to a bug in chpasswd / Emdebian
20:06 < codehelp> the sysfs thing would need some careful use of sed
20:06 < bgat> ... unless you want no password?
20:06 < codehelp> that isn't possible - you get a random one instead. :-)
20:07 < codehelp> what you can do is replace login with sh and get a root shell without login
20:07 < codehelp> roughly equivalent to having no root password
20:07 < codehelp> again, that needs a change in /etc/inittab
20:07 < codehelp> you can replace /etc/inittab with a machine:variant script
20:07 < codehelp> that could be useful
20:07 < codehelp> as would any ideas about why chpasswd fails
20:16 -!- ruoso [~ruoso@195.23.92.2] has quit [Quit: Ex-Chat]
20:17 < bgat> ... maybe because there's no /etc/shadow?
20:31 < codehelp> bgat: there is /etc/shadow - it's created in the emsandbox
20:31 < bgat> hmm
20:32 < bgat> I guess the /emsecondstage isn't working right, then...
20:32 < codehelp> the bug is in the postinst scripts somewhere
20:33 < codehelp> emsecondstage runs just dpkg --configure -a
20:33 < codehelp> (with a little wrapper to get cdebconf working properly)
20:33 < bgat> aaah.. hmm.
20:33 < bgat> it's missing dev/shm and dev/pts
20:37 < bgat> busybox egrep doesn't like -w
20:37 < bgat> as found in lib/init/vars.sh
20:40 < bgat> I untar the rootfs, mknod dev/console c 5 1, mkdir dev/shm dev/pts, and edit lib/init/vars.sh
20:40 < bgat> Then I boot, with init=/bin/sh and run /emsecondstage
20:40 < bgat> here's how that ends up:
20:40 < bgat> ...Setting up libc6 (2.7-11em4) ...
20:40 < bgat> BusyBox v1.9.2 (2008-06-01 13:41:12 BST) multi-call binary
20:40 < bgat> Usage: init
20:40 < bgat> Init is the parent of all processes
20:40 < bgat> ... and then it hangs
20:44 < codehelp> yes, one more bug for the list
20:44 < bgat> any ideas?
20:45 < codehelp> edit the libc6.postinst script and remove the init -u ; sleep 1 command
20:45 < codehelp> sysvinit isn't installed and libc6 fails to detect this (because Debian expects it to always 
                  be there)
20:45 < codehelp> the postinst then (wrongly) thinks that sysvinit is buggy
20:47 < bgat> aah
20:49 < codehelp> any other bugs you find, please send to the list
20:49 < codehelp> we'll have a pseudo-package in the BTS eventually but don't use that just yet
20:55 < bgat> ok, now what's left appears to be jus:
20:55 < bgat> init started: BusyBox v1.9.2 (2008-06-01 13:41:12 BST)
20:55 < bgat> starting pid 772, tty '': '/etc/init.d/rcS'
20:55 < bgat> ...
20:55 < bgat> Will now activate swapfile swap:done.
20:55 < bgat> The system is going down NOW!
20:55 < bgat> Sending SIGTERM to all processes
20:55 < bgat> Sending SIGKILL to all processes
20:55 < bgat> Requesting system halt
20:55 < bgat> System halted.
20:55 < bgat> i.e. as soon as it boots up, it halts.
20:56 < codehelp> rename /etc/rc.d/S25mountall.sh to /etc/rc.d/K25mountall.sh
20:56 < codehelp> or /etc/init.d/ actually
20:57 < codehelp> nah, right first time, /etc/rc.d/
20:57 < codehelp> (no run levels)
20:57 < codehelp> btw congratulations on getting this far!!!!
20:57 < codehelp> some updates are in SVN - untested right now
20:58 < codehelp> pending for 1.1.4
20:59 < codehelp> does that make sense ?
20:59 < codehelp> did any modules load?
21:00 < codehelp> we have to go soon, bgat, finished for the day. Back tomorrow by 9am BST (GMT +0100) 
21:00 < bgat> bummer
21:01 < bgat> getting rid of mountall in rc.d didn't affect the problem.  but killing the one one rcS.d caused 
              some damage.
21:01 < codehelp> we've been working on it for 12hrs straight - time to leave it for a while
21:01 < codehelp> damage?
21:01 < bgat> Checking all file systems.
21:01 < bgat> Done checking file systems.
21:01 < bgat> A log is being saved in /var/log/fsck/checkfs if that location is writable.
21:01 < bgat> Cleaning /var/run...find: unrecognized: -xtype
21:01 < bgat> BusyBox v1.9.2 (2008-06-01 13:41:12 BST) multi-call binary
21:01 < codehelp> what is in /etc/rcS.d/ ?
21:01 < bgat> Usage: find [PATH...] [EXPRESSION]
21:01 < bgat> a lot of the same stuff as in rc.d
21:02 < codehelp> not sure on that - I thought /etc/rcS.d/ was empty
21:02 < bgat> ... which is where init.d/rcS sends the system
21:03 < codehelp> ? that's not what I do at this end
21:03 < codehelp> rc.d/
21:03 < codehelp> not rcS.d/
21:03 < bgat> inittab goes to rcS
21:04 < codehelp> yes, but not rcS.d/
21:04 < bgat> ::sysinit:/etc/init.d/rcS
21:04 < codehelp> which is a script
21:04 < codehelp> not a directory
21:04 < bgat> exec /etc/init.d/rc S
21:04 < codehelp> ::sysinit:/etc/init.d/rcS
21:04 < codehelp> ?
21:05 < bgat> the emdebian-arm inittab has ::sysinit:/etc/init.d/rcS
21:05 < bgat> that sends you to /etc/init.d/rcS (script)
21:05 < codehelp> yes
21:05 < bgat> that script does an "exec /etc/init.d/rc S", i.e. launch script "rc", parameter "S"
21:06 < codehelp> there's no exec in the rcS in emdebian-rootfs - check /usr/lib/emdebian-tools/empbuilderlib
21:07 < bgat> etc/init.d/rc does this:
21:07 < bgat>         for s in /etc/rc$runlevel.d/S*
21:07 < bgat> where $runlevel is "S"
21:07 < codehelp> for i in /etc/rc.d/S??* ;do
21:07 < codehelp> different script
21:08 < codehelp> /etc/init.d/rcS
21:08 < codehelp> I have no /etc/init.d/rc
21:08 < codehelp> only /etc/init.d/rcS
21:09 < codehelp> and inittab calls /etc/init.d/rcS not rc S
21:09 < codehelp> but the routines do not clobber existing files so maybe a package is putting in the Debian
                  defaults?
21:09 < bgat> dunno
21:10 < codehelp> Get the Emdebian versions by looking at /usr/lib/emdebian-tools/empbuilderlib
21:11 < codehelp> busybox_inittab and busybox_rcS functions
21:11 < codehelp> I'd move /etc/init.d/rc aside
21:11 < codehelp> and /etc/inittab
21:11 < codehelp> then put in the ones from empbuilderlib
21:11 < bgat> my empbuilderlib has ::sysinit:/etc/init.d/rcS
21:11 < codehelp> yes
21:11 < codehelp> rcS not rc S
21:13 < bgat> ok, the tarball that comes from emsandbox has no etc/inittab
21:13 < bgat> oops... it has no "etc/initab"  :
21:13 < bgat> :)
21:13 < codehelp> ah
21:13 < bgat> The /etc/inittab I get in the emsandbox tarball is ::sysinit:/etc/init.d/rcS
21:14 < codehelp> yes
21:14 < codehelp> and /etc/init.d/rcS should just look at /etc/rc.d/S??*
21:14 < bgat> my tarball's etc/init.d/rcS has:
21:15 < bgat> exec /etc/init.d/rc S
21:15 < codehelp> that comes from the Debian sysv-rc
21:15 < bgat> I: Unpacking initscripts (2.86.ds1-58em3) ....
21:16 < codehelp> sysv-rc is separate from initscripts
21:16 < bgat> I: Unpacking sysv-rc (2.86.ds1-58em3) ....
21:16 < bgat> $ sudo emsandbox --arch arm create --machine csb737
21:17 < bgat> DEBOOTSTRAP_DIR=/usr/share/debootstrap/ debootstrap  --verbose --foreign --arch arm unstable
              /home/bgat/emdebian/workingdir/pbuilder/build http://buildd.emdebian.org/emdebian/
              /usr/lib/emdebian-tools/emdebian.crossd
21:20 < codehelp> really, really, have to go now.
21:20 < bgat> ok, I understand
21:20 < bgat> thanks very much for the help!
21:21 < zumbi_> ;-)
21:21 < zumbi_> bye
21:21 < codehelp> and well done for getting this far (i.e. as far as me). :-) bye.
09:34 < zumbi_> GyrosGeier: ayt?
09:46 -!- codehelp [~neil@62.254.222.241] has joined #emdebian
10:13 < GyrosGeier> yes
10:13 < GyrosGeier> zumbi_, ^^
10:13 < GyrosGeier> (not fully awake, but there)
10:18 < zumbi_> GyrosGeier: we found that dpkg deinstalls all busybox symlinks
10:19 < GyrosGeier> when, where?
10:19 < GyrosGeier> why?
10:19 < codehelp> hi GyrosGeier
10:19 < GyrosGeier> hi codehelp 
10:20 < codehelp> the problem is that the symlinks get listed as package files
10:20 < codehelp> by dpkg
10:20 < GyrosGeier> hmm
10:20 < GyrosGeier> in which package?
10:20 < codehelp> then installing a new package that contains a binary that tries to replace a busybox symlink 
                  causes an overwrite
10:20 -!- blindvt [~bf@85.127.91.31] has quit [Ping timeout: 480 seconds]
10:20 < GyrosGeier> official Debian or emdebian?
10:20 < codehelp> this is the emdebian busybox
10:20 < GyrosGeier> ah
10:20 < codehelp> but that version is largely unchanged
10:21 < codehelp> I want to revert to previous behaviour where the symlinks are created in a postinst
10:21 < codehelp> and are therefore not a problem for dpkg
10:21  * GyrosGeier needs to check dpkg code
10:22 < codehelp> I modify install.sh slightly and generate busybox.links again from the list of symlinks in 
                  debian/busybox/*
10:22  * GyrosGeier is not an expert in either dpkg or the Debian busybox package though
10:22 < codehelp> http://buildd.emdebian.org/svn/browser/current/target/trunk/b/busybox/trunk/emdebian-symlinks.pl.patch
10:22 < GyrosGeier> but dpkg removing all symlinks on an overwrite sounds wrong
10:23 < codehelp> 1. dpkg complains about missing Replaces: due to symlinks
10:23 < GyrosGeier> as it should
10:23 < codehelp> 2. dpkg removes the symlinks when removing the busybox package
10:23 < GyrosGeier> ah
10:23 < codehelp> so then things like mount and tar fail
10:24 < codehelp> which means that the new busybox cannot operate
10:24 < GyrosGeier> why does it remove busybox at all?
10:24 < codehelp> upgrading busybox package
10:24 < codehelp> with new version
10:24 < GyrosGeier> which doesn't have symlinks
10:24 < GyrosGeier> right
10:24 < codehelp> generates symlinks in postinst
10:24 < codehelp> to make them invisible to dpkg
10:24 < GyrosGeier> that cannot be done
10:24 < codehelp> so that we can replace them at will
10:24 < codehelp> ?
10:25 < codehelp> worked with old version of busybox.
10:25 < codehelp> http://buildd.emdebian.org/svn/browser/current/target/trunk/b/busybox/trunk/emdebian-busybox.postinst.patch
10:25 < GyrosGeier> the upgrade cannot be done in that way
10:25 < codehelp> yes, beginning to realise that
10:25 < GyrosGeier> dpkg will always remove all old files during unpack
10:25 < GyrosGeier> dpkg will always remove all old files during unpack
10:26 < codehelp> but we can't work with the symlinks being known to dkg
10:26 < GyrosGeier> the only way to immediately configure is to make all others pre-depend
10:26 < GyrosGeier> why?
10:26 < codehelp> because no one busybox config.deb will meet all requirements
10:26 < GyrosGeier> Replaces should allow other packages to replace symlinks
10:26 < codehelp> and it should be easy to install the "full" version of the package to replace the busybox 
                  symlink
10:26 < codehelp> but then every package needs a Replaces:
10:27 < GyrosGeier> every package that provides a binary that is also in busybox, yes
10:27 < GyrosGeier> that is the only correct answer
10:27 < codehelp> do I really have to set Replaces: busybox in up to 100 Emdebian packages ?
10:28 < codehelp> if the package is removed, the symlink won't be returned without a postinst in busybox
10:28 < codehelp> no point diverting the symlink
10:28 < GyrosGeier> hmm
10:28 < GyrosGeier> and any package overwriting it would become owner
10:29 < codehelp> e.g. if mount is the busybox version, mount is installed as a package, then mount is purged 
                  . . . 
10:29 < codehelp> reboot . . 
10:29 < codehelp> umm.....
10:30 < GyrosGeier> I think that is generally a problem with Replaces
10:30 < codehelp> this worked OK when we didn't need Replaces:
10:30 < codehelp> the postinst creates any missing symlinks by not overwriting any existing binaries
10:31 < GyrosGeier> if mount is installed and removed as a package, the symlink isn't recreated either
10:31 < codehelp> but a simple reconfigure of busybox will sort that out
10:31 < codehelp> true, not automated but not sure how else to do it
10:31 < GyrosGeier> hmm
10:32 < GyrosGeier> that is a true deficiency in dpkg
10:32 < GyrosGeier> it might make sense to ask #debian-dpkg about it
10:32 < codehelp> you mean in the Replaces: context or the postinst / symlink context?
10:33 < GyrosGeier> in Replaces
10:33 < codehelp> ok
10:33 < GyrosGeier> I cannot replace any binary in another package if I ever want it back
10:33 < GyrosGeier> if I want to do that, I need to divert
10:34 < GyrosGeier> for divert to work, dpkg needs to see the divertee
10:34 < GyrosGeier> and I'm not sure symlinks can be diverted properly at all
10:34 -!- blindvt [~bf@85.127.91.31] has joined #emdebian
10:35 < codehelp> GyrosGeier: see #debian-dpkg
10:36 < GyrosGeier> already seen :-)
10:36 < codehelp> can hardlinks work?
10:39 < codehelp> looks to me like dpkg can support diversion of busybox links if those links are hardlinks
10:39 < blindvt> codehelp, what's wrong with chpasswd? broken toolchain?
10:39 < codehelp> not sure - could be a config problem with /etc/passwd | /etc/shadow
10:39 < blindvt> codehelp, what version is that? Current is 1.10.3, fwiw
10:41 < codehelp> 1:4.1.1-1em2
10:41 < codehelp> ah, hang on
10:41 < codehelp> busybox 1:1.9.2-3em4
10:41 < codehelp> current Debian version
10:42 < blindvt> wow, that's so old that it ain't funny anymore. the 1.9.x series ended with 1.9.5, iirc
10:43 < blindvt> and is shadow enabled or not? builtin passwd handling enabled (shouldn't be needed)?
10:43 < GyrosGeier> I think patching dpkg to allow restoring replaced files in general might be the best thing
10:44 < GyrosGeier> the normal use case is for moving files from one package to another, there the old file 
                    silently goes away, so dpkg forgetting about it is okay
10:45 < codehelp> blindvt: shadow is enabled in em4 - been fiddling since and was considering replacing 
                  busybox passwd with Debian
10:45 < codehelp> GyrosGeier: but dpkg could divert busybox hardlinks
10:45 < codehelp> without patches