**** BEGIN LOGGING AT Tue Mar 05 02:59:58 2013
Mar 05 10:44:00 <blathijs> epienbro: Weren't the boot issues resolved by using a more recent revision I committed last week?
Mar 05 10:44:25 <blathijs> or the week before
Mar 05 10:46:32 <blathijs> epienbro: The picture is right, left is gnd, right is vcc (unconnected)
Mar 05 10:47:28 <blathijs> Looks like the pin numbers in the table are reversed, I'll correct that
Mar 05 15:59:23 <epienbro> blathijs, I tested out the latest revision, but it still failed to boot
Mar 05 16:02:51 <blathijs> epienbro: Hmm
Mar 05 16:03:25 <epienbro> is the wiki correct now?
Mar 05 16:08:23 <blathijs> yes
Mar 05 16:08:58 <epienbro> okay, I'll do another attempt to establish a serial connection now
Mar 05 16:13:02 <epienbro> btw, did you also get your uart adapter from conrad?
Mar 05 16:13:17 <epienbro> the one in the picture looks really similar to the one I just ordered from conrad :)
Mar 05 16:13:29 <blathijs> Quite possibly, yes :-)
Mar 05 16:13:49 <blathijs> I don't quite like Conrad usually, but their assortment is pretty hard to beat
Mar 05 16:19:02 <blathijs> epienbro: But don't be fooled by the connections on the UART in the picture, since I connected pin X1 to X5 with a short wire since I didn't need 5V TTL levels and wanted TX, RX and GND next to each other
Mar 05 16:20:08 <epienbro> hm..that's kinda hard to see on the picture
Mar 05 16:21:03 <blathijs> epienbro: It isn't intended to be seen in the picture, since it's specific to the UART :-)
Mar 05 16:22:17 <blathijs> I'm just saying, don't just assume that pin X1 on the UART is GND (it's not) just because I connected the black wire to it and we seem to be having the same UART
Mar 05 16:22:36 <epienbro> the docs which are bundled with the uart converted indeed contain a message that pin x1 (ttl driver input) should be connected to pin x5 (gnd) when the ttl driver input isn't used
Mar 05 16:23:04 <epienbro> that might also explain why I couldn't get it to work yesterday :)
Mar 05 16:25:21 <epienbro> now I need to search for a small wire which I can use to make that connection
Mar 05 16:26:12 <epienbro> a small piece of cat5 wire should be good enough I think
Mar 05 16:26:48 <blathijs> That should work (though solid core wire is a bit hard to solder perhaps
Mar 05 16:26:49 <blathijs> )
Mar 05 16:27:48 <epienbro> I don't have a soldeerbout available right now..
Mar 05 16:28:37 <epienbro> so a bit of improvisation is needed
Mar 05 16:28:58 <blathijs> You might get away with twisting a wire around the pins (solid core is better for that ;-p)
Mar 05 16:46:02 <epienbro> here goes nothing
Mar 05 16:47:40 <epienbro> hm..ModemManager tries to send AT commands over the serial connection
Mar 05 16:47:48 <epienbro> let's kill that one first before powering on the fon
Mar 05 16:49:18 <epienbro> yeah, it works :)
Mar 05 16:49:30 <epienbro> I can see the kernel output now
Mar 05 16:49:58 <epienbro> okay, now I can try to flash one of my 'broken' images to it and see what happens 'under the hood'
Mar 05 17:47:45 <blathijs> Cool
Mar 05 18:33:21 <epienbro> btw, the source code in the svn fails to build by default on modern environments (fedora 18)
Mar 05 18:33:37 <epienbro> up to now I've found 3 different issues:
Mar 05 18:34:08 <blathijs> it works on modern Debian :-)
Mar 05 18:34:13 <epienbro> * the quilt configure script fails to detect the latest version of patch (the output of 'patch -v' has changed a bit)
Mar 05 18:34:29 <blathijs> But I'm happy to fix any issues on Fedora of course
Mar 05 18:34:54 <epienbro> * the kernel fails to build on modern make (something about implicit..didn't save the output)
Mar 05 18:35:27 <epienbro> * binutils fails to build its documentation against the latest texlive because of more strictness
Mar 05 18:35:28 <blathijs> Hmm, I thought we fixed those make errors
Mar 05 18:36:22 <epienbro> and anothing odd thing I noticed is that iptables tries to use the native kernel source if it's available (/lib/modules/foo/build)
Mar 05 18:37:02 <epienbro> for now I've managed to workaround all these issues by downgrading the relevant packages and by moving the native kernel source code to a different folder
Mar 05 18:39:54 <epienbro> I just made a small typo, texlive should have been texinfo
Mar 05 18:46:36 <blathijs> Ok, I reproduced the patch issue, let's see if updating quilt helps for that
Mar 05 18:47:12 <blathijs> Nope, seems it doesn't
Mar 05 18:48:04 <blathijs> Ah, OpenWRT has a patch for this
Mar 05 18:49:11 <epienbro> does the error at http://fpaste.org/Ko0r ring any bells?
Mar 05 18:50:46 <blathijs> It does, but I can't quite remember which bell :-S
Mar 05 18:51:21 <epienbro> hehe, I've also managed to resolve it in the past, but I also can't remember any more what did the trick :)
Mar 05 18:53:48 <blathijs> The weird thing is that a lot of packages drop files in /etc/fonstated/, so it's weird that it's empty
Mar 05 18:55:57 <epienbro> I think I've got it, I did a 'scripts/feeds update' and some 'scripts/feeds install' commands and now I don't see the luci related items any more in 'make menuconfig'
Mar 05 18:58:47 <blathijs> Ah, I suspect the luci and fon feeds got removed somehow
Mar 05 18:59:07 <blathijs> You might need to re-run (parts of) install.sh?
Mar 05 18:59:25 <epienbro> I'll try
Mar 05 19:00:07 <epienbro> yes, the luci and fon packages are now visible again in make menuconfig :)
Mar 05 19:00:21 <blathijs> :-)
Mar 05 19:00:34 <epienbro> okay, now another attempt at running make :)
Mar 05 19:00:46 <blathijs> Looks like I fixed quilt by picking up a patch from OpenWRT
Mar 05 19:01:13 <epienbro> ah nice :)
Mar 05 19:02:40 <blathijs> What was the make version that was failing for you?
Mar 05 19:03:04 <epienbro> make 3.81 is the one which I'm currently using that works
Mar 05 19:03:16 <epienbro> one sec while I verify the current version of make in fedora..
Mar 05 19:03:32 <blathijs> Probably 3.82, which is the most recent released version of GNU make
Mar 05 19:03:38 <epienbro> 3.82 doesn't work any more :)
Mar 05 19:03:48 <blathijs> But I already have a patch to make it work with 3.82, so it has worked at some point
Mar 05 19:04:37 <epienbro> hm..let's look at the contents of that patch
Mar 05 19:05:47 <blathijs> epienbro: http://trac.fonosfera.org/fon-ng/changeset/1903
Mar 05 19:06:56 <epienbro> okay thanks, I'll verify in my copy whether this patch is applied correctly
Mar 05 19:07:38 <blathijs> I just installed 3.82 as well, I'll see if I can get it to break here
Mar 05 19:08:12 <blathijs> (but I first need to clean up and save some pending kernel patches I have, don't want to throw away that working trying to recompile my kernel ;-p)
Mar 05 19:08:59 <epienbro> nope, the patch isn't applied here
Mar 05 19:11:23 <blathijs> epienbro: Perhaps there is an error in an earlier patch, I've seen patching halt at an erronous patch before
Mar 05 19:11:58 <blathijs> I _thought_ I fixed that to error out instead of silently continuing, but perhaps I only fixed it for packages and not the kernel or something
Mar 05 19:12:05 <epienbro> but that patch is in a folder called 'patches-2.6.21' while the kernel used in the fon2.0g profile is 2.6.26.2..perhaps that may explain it?
Mar 05 19:12:40 <blathijs> Oh, it seems that it was only patched for 2.0n, not 2.0g
Mar 05 19:13:22 <blathijs> In the ticket I actually wondered if 2.0g would build, but I probably forgot about that later
Mar 05 19:14:03 <epienbro> yeah, it can be tricky to maintain multiple targets
Mar 05 19:14:05 <blathijs> You could try dropping the patch into the patches-2.6.26 folder and see if it applies?
Mar 05 19:15:00 <epienbro> I just got a complete image built, so I'll start the flash process first
Mar 05 19:17:23 <blathijs> Sounds good
Mar 05 19:26:47 <blathijs> Ok, the kernel patch needs a bit of tweaking for 2.0g, I'll send you one to test later
Mar 05 19:27:31 <epienbro> excellent
Mar 05 19:29:32 <blathijs> Do you have a bit more info on the texinfo issue? I need to upgrade half of my system to get version 5.0 of that...
Mar 05 19:29:46 <epienbro> sure, one sec
Mar 05 19:39:52 <epienbro> http://fpaste.org/Msw7
Mar 05 19:50:35 <blathijs> epienbro: Here's a combined patch that should fix all three issues, could yo test? http://www.stderr.nl/static/tmp/fedora-fixes.patch
Mar 05 19:51:06 <blathijs> I'm not sure about the binutils part, since it's a bit of a hack that I haven't been able to properly test, but at least it compiles here
Mar 05 19:51:41 <blathijs> epienbro: Did you some boot output from your 2.0g already?
Mar 05 19:57:07 <epienbro> yep, "Kernel panic - not syncing: No init found. Try passing init= option to kernel.
Mar 05 19:57:19 <epienbro> and above that:
Mar 05 19:57:30 <epienbro> Please be patient, while OpenWrt loads ...
Mar 05 19:57:43 <epienbro> Failed to execute /etc/preinit.  Attempting defaults...
Mar 05 19:57:51 <epienbro> and then the panic
Mar 05 19:58:38 <epienbro> this is with your latest busybox fix
Mar 05 19:59:43 <epienbro> in the folder build_dir/mips/root-fonera2/etc there's a script called preinit
Mar 05 20:00:03 <epienbro> so /bin/sh probably can't be executed for some reason
Mar 05 20:00:27 <epienbro> which is busybox..
Mar 05 20:01:21 <blathijs> epienbro: Could it be that busybox wasn't properly rebuilt after my fix?
Mar 05 20:01:40 <blathijs> Does build_dir/mips/root-fonera2/bin/sh exist?
Mar 05 20:01:49 <epienbro> here's the complete boot output: http://fpaste.org/KYyv
Mar 05 20:01:56 <epienbro> yes, it's a symlink to busybox
Mar 05 20:02:05 <epienbro> the busybox binary itself is around 500KB large
Mar 05 20:02:31 <epienbro> I did a 'make distclean' initially..so that should clear out any old stuff, right?
Mar 05 20:02:41 <blathijs> Yeah, I think it should
Mar 05 20:03:03 <blathijs> OTOH, I'm not sure if this also cleans up the package metadata stuff, perhaps that's still broken
Mar 05 20:07:11 <epienbro> although...the busybox binary seems to be missing it's +x chmod permission..
Mar 05 20:07:45 <epienbro> as well as all other binaries in the build_dir/mips/root-fonera2/bin folder
Mar 05 20:09:33 <epienbro> in the folder build_dir/mips/busybox-1.11.1/ipkg/busybox/bin the permissions are correct
Mar 05 20:10:00 <epienbro> I guess it must be something with the ipkg packaging part
Mar 05 20:17:43 <blathijs> weirdness
Mar 05 20:19:33 <epienbro> if I manually extract the ipkg then the permissions are correct..so the generate ipkg is okay
Mar 05 20:23:21 <epienbro> I think I'm onto something here..let's test this
Mar 05 20:24:14 <epienbro> just wondering: what version of tar are you using?
Mar 05 20:25:17 <blathijs> epienbro: 1.26
Mar 05 20:25:45 <epienbro> me too, but the fedora version of tar contains several patches..perhaps one of those is causing this behaviour
Mar 05 20:26:17 <epienbro> ah yes, this looks much better now :)
Mar 05 20:26:33 <blathijs> What did you change?
Mar 05 20:27:00 <epienbro> http://fpaste.org/hR1J
Mar 05 20:27:08 <blathijs> I did a distclean and make in my 2.0g build dir, just to see if that works here
Mar 05 20:27:59 <epienbro> with this change the permissions in the folder build_dir/mips/root-fonera2/bin are correct now
Mar 05 20:28:53 <blathijs> Looking at the docs for tar, -p is only default for root
Mar 05 20:29:06 <blathijs> I wonder why this stuff worked at all before
Mar 05 20:29:19 <epienbro> undocumented behaviour?
Mar 05 20:29:42 <epienbro> I'm not checking the fedora patches to the tar package to see if there's anything suspected there
Mar 05 20:29:49 <epienbro> not->now
Mar 05 20:31:09 <blathijs> Hmm, reading the manpage more closely, it seems that the inverse of -p, --no-same-permissions means to apply the regular umask, not to ignore permissions altogether
Mar 05 20:31:17 <blathijs> what's your umask?
Mar 05 20:31:32 <epienbro> 0002
Mar 05 20:31:35 <blathijs> (I have 0022)
Mar 05 20:31:42 <blathijs> that shouldn't remove +x bits afaics
Mar 05 20:32:01 <blathijs> I wonder if this is a bug in the Fedore tar version, then
Mar 05 20:32:07 <blathijs> or wether this is intentional
Mar 05 20:32:30 <blathijs> Perhaps you could try creating a test archive with just a single executable file?
Mar 05 20:32:47 <epienbro> sure
Mar 05 20:34:26 * blathijs will be away for a bit, btw
Mar 05 20:34:39 <epienbro> hm..can't be reproduced by hand..
Mar 05 20:34:49 <epienbro> perhaps some of the openwrt scripts manually adjust the umask
Mar 05 20:40:33 <epienbro> on second though..the patch is wrong
Mar 05 20:41:05 <epienbro> I checked the contents of the root folder while make was still running
Mar 05 20:41:25 <epienbro> now that make has completed, the permissions suddenly became b0rked again
Mar 05 20:41:35 <epienbro> so it's something else during make which messes up permissions
Mar 05 20:47:34 <epienbro> this looks suspicious: http://fpaste.org/aQEz
Mar 05 20:48:15 <epienbro> when I manually run the find -not -perm +0100 command then it returns all files (including libraries and binaries)
Mar 05 20:48:25 <epienbro> and the find -perm +0100 returns nothing
Mar 05 20:48:34 <epienbro> this looks umask related
Mar 05 20:51:00 <epienbro> according to the find man-page the '-perm +mode' method is deprecated
Mar 05 21:01:14 <epienbro> I just check the fedora history and the umask has been set to 002 for regular user accounts as of 2010..so there must be something else why this only started to show up recently
Mar 05 21:02:54 <epienbro> I'll try downgrading find (4.5.11 -> 4.5.10)
Mar 05 21:10:20 <epienbro> this is odd..the permissions are still okay now
Mar 05 21:10:25 <epienbro> I'll upgrade find again
Mar 05 21:10:31 <blathijs> epienbro: I don't think it's umask related, I just upgraded to find 4.5.11 and it also returns executables with find -not -perm +0100
Mar 05 21:10:58 <blathijs> epienbro: Interestingly enough find -not -perm /0100 gives the expected results
Mar 05 21:11:26 <blathijs> even though the "unexpected results" associated with -perm +... should only be when using symbolic permissions
Mar 05 21:12:34 <blathijs> Perhaps they changed some generic permission parsing thing in find 4.5.11?
Mar 05 21:12:55 <epienbro> looks like it yes..
Mar 05 21:15:04 <blathijs> It seems this particular chmod thing isn't present anymore in OpenWRT trunk, so I can't peek for a fix there
Mar 05 21:15:49 <epienbro> perhaps it would be good enough to just change '-perm /0100' to '-perm +0100' ?
Mar 05 21:15:59 <epienbro> the first one is deprecated
Mar 05 21:16:01 <blathijs> the other way around, yes
Mar 05 21:16:15 <blathijs> no, +0100 is deprecated according to my manpage
Mar 05 21:16:23 <epienbro> yeah, my bad
Mar 05 21:16:37 <blathijs> Trying that now
Mar 05 21:18:41 <epienbro> I'm also trying it here
Mar 05 21:20:13 <blathijs> Seems to have worked here
Mar 05 21:21:56 <epienbro> yep, same here
Mar 05 21:22:03 <epienbro> I'll try to flash this one now
Mar 05 21:22:18 <epienbro> *fingers crossed* :)
Mar 05 21:22:30 <blathijs> Weird, the findutils page from gnu doesn't actually list any 4.5.x versions...
Mar 05 21:23:23 <blathijs> Oh, it seems the .odd versions are alpha versions listed on alpha.gnu.org only
Mar 05 21:24:43 <blathijs> Might be worth filing a bug about this with GNU, considering it is behaviour change, even for a deprecated option
Mar 05 21:24:56 <blathijs> Would you care to do that?
Mar 05 22:09:15 * blathijs is off to bed
Mar 05 22:09:32 <blathijs> epienbro: Let me know if you create a bug report for find, if not I'll create one tomorrow morning
Mar 05 22:09:48 <blathijs> epienbro: Thanks for all your detailed feedback, it's been a great help!
Mar 05 22:30:15 <epienbro> blathijs, the new firmware works fine without issues now, thanks very much for your help!
Mar 05 22:31:30 <epienbro> if you could file the bug at GNU upstream that's fine by me, I'm also about to go to bed now and tomorrow is another long day of work
**** ENDING LOGGING AT Wed Mar 06 02:59:58 2013