[00:17] <slangasek> jcrigby: have opened bug #591968 with my notes to date on this issue (they were starting to fall out of my head)
[00:17] <ubot2> Launchpad bug 591968 in coreutils (Ubuntu Maverick) (and 1 other project) "coreutils 8.5-1ubuntu1 FTBFS on armel, powerpc, sparc (test-linkat assert fail) (affects: 1) (heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/591968
[00:19] <NCommander> ogra: so you fixed jasper?
[00:36] <bullet9mm> go to bed...good night!  :)
[00:38] <GrueMaster> NCommander: ogra is either in bed or traveling.
=== bjf[afk] is now known as bjf
[00:47] <jcrigby> slangasek: ok thanks
=== bjf is now known as bjf[afk]
[01:29]  * mozzwald is away: off to grandmothers house I go
[02:14]  * cwillu_at_work pokes around in rcn-ee's general direction
[02:14] <jcrigby> slangasek: still around?
[02:14] <slangasek> jcrigby: yep
[02:14] <jcrigby> just added a comment to the bug
[02:15] <jcrigby> I won't repeat it here
[02:19] <slangasek> jcrigby: hmm, is that strcmp() actually failing for you?  It didn't for me
[02:19] <slangasek> only the SAME_INODE() check fails
[02:19] <slangasek> (sorry, the line number is wrong in the logs I posted to the bug report because I inserted some other debugging)
[02:19] <slangasek> should be line 73 in the original file
[02:21] <jcrigby> I only have your strace data.  Strace does not work in qemu user emulation mode
[02:22] <slangasek> OK
[02:22] <jcrigby> from the strace data, I would predict that strcmp would fail
[02:22] <jcrigby> given the ... on the end of the strings
[02:22] <jcrigby> string
[02:22] <slangasek> I think that's an abberation in the strace output; if it was really non-null garbage data, I would have expected it inside the double quote
[02:23] <slangasek> rather - it may be signalling that there's more data there, but the string appears to be properly null terminated
[02:25] <jcrigby> can you try using calloc instead of malloc in areadlink_with_size and see if the problem goes away?  Just to humor me:)
[02:26] <slangasek> sure, lemme find it
[02:26] <slangasek> you want calloc(1, buf_size)?
[02:27] <jcrigby> its in lib/areadlink-with-size.c
[02:27] <jcrigby> yes, that should do it
[02:27] <slangasek> rebuilding
[02:28] <jcrigby> Meanwhile I'm going to figure out what strace really means by "string"...
[02:36] <slangasek> jcrigby: sorry, have to afk now and the build is still running (I took the lazy way out to rebuild, which means it's rebuilding everything and will take a while) - I'll report results when I return later this evening
[02:38] <slangasek> btw, it looks like the code does append the trailing \0?
[02:38] <slangasek>       if (link_length < buf_size)
[02:38] <slangasek>         {
[02:38] <slangasek>           buffer[link_length] = 0;
[02:38] <slangasek>           return buffer;
[02:38] <slangasek>         }
[02:41] <jcrigby> slangasek: oops
[03:03] <jcrigby> slangasek:ok sorry about the wild goose chase.   I have noticed one other oddity.  The test uses the size returned from lstat in the call to areadlink_with_size which should be 17 according to the strace data.  areadlink_with_size adds 1 to it and calls readlink.  In the amd64 case we see 18 which makes sense.  However, the armel strace shows 1025 which means that 1024 was passed to areadlink_with_size.
[04:19] <cwillu_at_work> what would "unknown location" be implying?
[04:19] <cwillu_at_work> er, "unknown relocation" while loading a kernel module
[04:24] <jcrigby> slangasek: I see this in the build log:  CC       test-linkat.o
[04:24] <jcrigby> In file included from test-linkat.c:44:
[04:24] <jcrigby> test-link.h: In function 'test_link':
[04:24] <jcrigby> test-link.h:47: warning: implicit declaration of function 'stat'
[04:24] <jcrigby> test-link.h:98: warning: implicit declaration of function 'mkdir'
[04:24] <jcrigby> test-linkat.c: In function 'check_same_link':
[04:24] <jcrigby> test-linkat.c:65: warning: implicit declaration of function 'lstat'
[04:27] <jcrigby> test-link.c does not get errors.  Its includes are different.  Can you try including sys/stat.h in test-linkat.c?
[04:45] <cwillu_at_work> hmm, I can't modprobe anything
[04:56]  * mozzwald is away: time for some zeez
[06:35] <slangasek> jcrigby: oh, nicely caught
[06:36] <slangasek> jcrigby: I saw those link warnings but wrote them off, thinking that the prototypes would Just Work by default
[06:38] <slangasek> jcrigby: so, the tests pass now - do you want to put that into a bzr branch that I can merge & upload?
[07:46] <ogra> NCommander, were your debian-cd changes merged or uploaded in any way ? (why did you close the workitem)
[07:52] <NCommander> ogra: the work is done, there is a seperate work item for merging I thought
[07:53]  * ogra doesnt see one that talks about merging
[07:53] <ogra> i see one that talks about debian-cd and one that talks about the post processing
[07:54] <ogra> and one about bziping
[07:54] <NCommander> ogra: huh, maybe I'm loosing it
[07:54] <ogra> anyway, leave it like that
[07:54]  * NCommander is having one of those weeks
[07:54] <NCommander> ogra: I'm filing MIRs for x-loader/x-loader-omap4 and uboot-omap
[07:55] <NCommander> ogra: much sanier for the code if they're in main since apt-selection doesn't seem to work in universe, and seems non-trivial to fix
[07:55] <ogra> it has to, how else would distros like edubuntu or xubuntu roll their images
[07:55] <ogra> but i agree, MIR is definately better
[07:56] <NCommander> ogra: its more a matter that when control passes into the boot/post-boot scripts, the necessary environment for apt-selection goes "poof" as far as I can tell
[07:56] <NCommander> and its proving difficult to get that to work.
[07:57] <NCommander> I'll keep poking at it, but we should have these in main anyway so only if we do a 10.04.1 do we need to care about actually retrieving these files from universe
[07:57] <ogra> well, there has to be a way that edubuntu and xubuntu use for the alternates
[07:57] <ogra> but dont bother now, MIRs are fine
[07:58] <ogra> i'm still experimenting with jasper, it could be that we need to generate ext2 by default and convert after resizing to ext3
[07:58] <ogra> bug 5583317 is really bad
[07:58] <ubot2> ogra: Error: Bug #5583317 not found.
[07:58]  * ogra pokes the bot
[07:58] <ogra> bug 583317
[07:58] <ubot2> Launchpad bug 583317 in genext2fs (Ubuntu) "genext2fs creates revision 0 filesystems instead of revision 1 (affects: 1) (heat: 156)" [Undecided,Confirmed] https://launchpad.net/bugs/583317
[07:59] <ogra> pfft
[07:59] <ogra> though thats apparently something to be fixed in genext2fs
[07:59] <NCommander> ogra: maybe we should use loop mounting
[08:00] <ogra> for now i added an extra ext2fsck to livecd-rootfs but i'm not sure that will not make livefs.sh explode
[08:00] <ogra> since it exits with 2
[08:00] <ogra> lets keep that as last resort, i'm not a fan of loop mounting
[08:00] <NCommander> ogra: I think you can pipe to true, to force a return of 0
[08:01] <NCommander> or osme other stupid trick
[08:01] <NCommander> or trap an exit code of two
[08:01] <ogra> well, it needs testing anyway but i wont have the time to run a livefs build on my lappie the next tw days
[08:02] <ogra> luckily nobody uses the ext3 code so i could just add it to the function for now, if it doent work we can always revert
[08:02] <ogra> using ext2 might also have speed advantages
[08:03] <ogra> in jasper
[08:03] <ogra> the resizing takes between 6 and 7 mins
[08:03] <ogra> NCommander, btw, not sure you saw it in your backlog http://people.canonical.com/~ogra/jasper/
[08:03] <ogra> there is an image to test if you feel bored enough :)
[08:04] <ogra> though there is a lot that doesnt work yet, the resizing does at least
[08:07]  * ogra wonders why his NM applet tends to disappear from the panel
[08:09] <NCommander> ogra: _\o/_
[08:09] <NCommander> ogra: I stll have tons to screw around with the d-cd backend code, but we should probably do an initial merger soon
[08:09] <NCommander> ogra: do we care about 10.04.1 for omap3 at all?
[08:10] <NCommander> Now that I have maverick locally, I can choose not to care
[08:10] <ogra> we do
[08:10] <NCommander> ogra: so we want pre-installed images for 10.04.1?
[08:10] <ogra> there are a bunch of bugs we need to milestone before the meeting
[08:10] <hrw> morning
[08:10] <ogra> no, but we want some kernel SRUs for 10.04.1 in omap3
[08:11] <NCommander> ogra: ok, so I'll leave the boot scripts for lucid alone, and just merge those into the maverick tree
[08:11] <ogra> like the USB NIC udeb misses a lot of drivers
[08:11] <ogra> yeah
[08:11] <NCommander> ogra: works for me, that makes my life simpiler. I'm going to add a work item on the MIRs for the bootloader
[08:11] <ogra> we wont change images, but there are some SRU bits we want, we need to add them to the release meeting report tomorrow
[08:12] <ogra> dont !
[08:12] <ogra> it will rise the WI count !
[08:18] <NCommander> ogra: https://bugs.edge.launchpad.net/ubuntu/+source/x-loader/+bug/592045
[08:18] <ubot2> Launchpad bug 592045 in x-loader-omap4 (Ubuntu) (and 3 other projects) "[MIR] x-loader/x-loader-omap4/u-boot-omap3/u-boot-omap4 (affects: 1) (heat: 10)" [High,New]
[08:19] <NCommander> ogra: ok, no work item
[08:21] <ogra> great, thanks
[08:24] <ogra> we'll mention the bug in the report, that saves us the WI
[08:52] <JamieBennett> /join #ubuntu-devel
[08:53] <ogra> heh
=== lag_ is now known as lag
[10:29] <JameswStubbs> Hello
[10:30] <JameswStubbs> Can someone please point me to some documentation for creating an initrd for an arm boot?
[10:38] <JameswStubbs> What's the difference between iop4xx, orion5x, iop32x
[10:38] <JameswStubbs> ?
[10:44] <bullet9mm> hi all!!
[10:44] <JameswStubbs> Hello
[10:54] <asac> ogra_cmpc: will you guys make good step forward on the thumb2 porting this cycle?
[10:54] <asac> (I assume not, but wanted to check if that is priority for your team)
=== ericm|ubuntu is now known as ericm-afk
[11:52] <JameswStubbs> is armv5tej the same as armv6?
[11:56] <hrw> no
[11:56] <hrw> armv6 runs armv5te binaries but not reverse
[11:57] <JameswStubbs> So a distrobution compiled for armv5te won't work with an armv6 kernel?
[11:57] <hrw> will work
[11:57] <JameswStubbs> Ah, good, thank you
[11:57] <hrw> armv6 binaries do not work with armv5te hardware
[11:57] <hrw> etc
[11:58] <JameswStubbs> Thanks
[11:58] <hrw> JameswStubbs: if you are rather x86 guy then remind i386<486<568<686 and then armv4 < armv4t < armv5te(j) < armv6 < armv7a
[11:59] <JameswStubbs> So arm like x86 has backwards compatibilty with older archs
[11:59] <hrw> yes
[11:59] <hrw> but in arm world it is more clean
[12:00] <hrw> in x86 i586 != i586 if cpu are from diferent vendors
[12:00] <hrw> amd k5 has 3dnow which intel pentium-mmx do not have. but both are i586
[12:01] <JameswStubbs> Do you prefer arm to x86?
[12:01] <hrw> or intel pentium pro (first i686) contra Core i7 (latest i686). first has only mmx, second has lot of addons...
[12:01] <hrw> JameswStubbs: for my gadgets I prefer arm. for small low power I prefer arm. for my desktop I prefer x86-64
[12:02] <JameswStubbs> This is my first experience with arm on embedded, atm it seems to be far more difficult to get a busybox than x86
[12:02] <hrw> my laptops are x86 and x86-64. but arm powered one would be nice
[12:02] <hrw> JameswStubbs: what hw?
[12:03] <JameswStubbs> iPhone 3g
[12:03] <JameswStubbs> armv6
[12:03] <hrw> s3c6410 iirc
[12:04] <JameswStubbs> Yes produced by samsung
[12:04] <JameswStubbs> Has imgtech power vr althought gpu drivers are not yet reverse engineered
[12:05] <hrw> powervr...
[12:13] <JameswStubbs> PowerVR (MBX Lite)
[12:53] <JameswStubbs> hrw using rootstock now with iPhone's kernel, should be able to emulate using qemu
[12:55] <hrw> qemu requires qemu kernel
[12:55] <JameswStubbs> Can you not use a different arm kernel?
[12:57] <hrw> arm kernels are bound to machine or set of machines
[12:57] <hrw> there is no such thing as 'one kernel image works on any arm device'
[12:57] <JameswStubbs> The iphone kernel works on the iphone :/
[12:57] <JameswStubbs> Android is already booting
[12:58] <JameswStubbs> The kernel is made just for the iPhone
[13:15] <sivang> hi all
[13:15] <JameswStubbs> Hello
[13:20] <sivang> so there's an official arm port? canonical supported?
[13:20]  * sivang is curious who does the arm port for Marvell
[13:21] <hrw> sivang: depends which marvell cpu
[13:21] <hrw> sivang: there is official ARM port but armv7a only (cortex-a8/a9 core)
[13:22] <sivang> hrw: coretx-a8 is TI's no?
[13:22] <sivang> hrw: or are marvell also producing it?
[13:22] <hrw> sivang: nope
[13:22] <sivang> hrw: N900 uses TI's right?
[13:22] <hrw> sivang: Cortex-A8/A9/A5 and M0/M3/M4 are names from ARM Ltd.
[13:23] <hrw> sivang: yes, it has TI OMAP3530
[13:23] <sivang> hrw: so it's their specs
[13:23] <sivang> okay
[13:23] <sivang> thanks
[13:23] <sivang> hrw: and the port is officiall supported by Canonical due to OEM's demand?
[13:23] <hrw> sivang: ARM creates core, vendors buy license and make a silicon
[13:23] <hrw> so Cortex A8/A9 you can get from TI, Freescale, Marvell, ST-Ericsson, NVidia and few others
[13:24] <hrw> sivang: I was not here when port was created so cant comment
[13:24] <sivang> hrw: okay, cool, thanks.
[13:24] <armin76> sivang: considering they've done it without using public hw, i'd say yes
[13:24] <armin76> nevertheless ask ogra, lool and asac
[13:25] <sivang> armin76: what do you mean using public hw?
[13:25] <armin76> hrw: qualcomm, how could you forget so important one? :P
[13:25] <armin76> sivang: one you can buy
[13:26] <armin76> sivang: as in smartbooks, nettops, you know...
[13:26] <armin76> stuff you can buy, not development stuff
[13:26]  * sivang wonders if ogra_cmpc remebers him 
[13:26] <sivang> or asac for that matter
[13:26] <sivang> :)
[13:27] <armin76> i can also tell you that here there are a lot of ppl from vendors, so that reinforces my thought :)
[13:31] <sivang> i see
[13:57] <asac> sivang: lucid has a official marvel dove port
[13:59] <lag> Has anyone seen this error before? omapdss DISPC error: SYNC_LOST_DIGIT
[13:59] <lag> It renders my Panda unusable
[14:05] <sivang> asac: nice, I see.
[14:06] <asac> lag: we are waiting for the pandas ;) ... so cant tell!
[14:06] <hrw> asac: ogra has panda
[14:07] <asac> ogra also has eucalyptus ;)
[14:08]  * lag shouts "OGRA"
[14:08] <lag> ogra_cmpc: Can you give me a shout when you return please?
[15:01] <asac> ogra_cmpc: what triggeres the flash-kernel thing?
[15:01] <asac> is that in postinst of linux-image?
[15:01] <asac> or a trigger?
=== bjf[afk] is now known as bjf
[16:56] <GrueMaster> asac: In answer to your question re:flash-kernel, I believe it is the postinst script that triggers it.  I know it runs whenever I install a test kernel.
[17:03] <asac> yeah i know its always run. just wanted confirm its not using a trigger
[17:03] <asac> thanks
=== hrw is now known as hrw|gone|lt
[17:09] <GrueMaster> asac: actually, it might be a triggered event.  I looked at /etc/kernel-img.conf and it lists postinst_hook=flash-kernel.  I also don't remember flash-kernel requiring any parameters, so this could be it.
[17:09] <asac> i dont think its triggered because it didnt get triggered when installing a custom kernel .deb
[17:09] <asac> from rcn
[17:11] <GrueMaster> Hmmm.  The custom test kernel packages I always get from clooney or ericm always initiated flash-kernel somehow.  I admit I don't know enough about the deb system to fully understand all the mechanisms used.
[17:17] <asac> right. i think they use the "official debian" packaging
[17:17] <asac> while rcn's lucid kernels do something else (supposed to be used without initram i guess)
[17:18] <GrueMaster> ah, fun.
=== bjf is now known as bjf[afk]
[20:13] <armin76> asac: i am getting a panda too, right? :D
=== bjf[afk] is now known as bjf