[10:31] <lool> doko__: d-shlibs > are you sure ld-linux3-dev is the right thing to do?
[10:32] <lool> doko__: Is it normal that all our binaries start getting linked to ld-linux when they didn't use to?
[10:32] <lool> doko__: If you check jaunty, they weren't linked in this way
[10:39] <ogra> sigh, d-i is missing a dep on parted for teh merged netboot image to work ... what made me assume its there by default ...
[10:41] <ogra> i guess redboot-install should actually depend on it
[10:46] <ogra> lool, btw, i'm sure you'll find improvements ... http://bazaar.launchpad.net/~ubuntu-mobile/redboot-tools/ubuntu/annotate/head%3A/redboot-cmdline/redboot-cmdline :)
[10:48] <lool> I would have encoded the FIS directory offset instead of the config offset
[10:48] <ogra> well, i want to have it detect the offset at some point
[10:48] <ogra> but for a start using the default we use in our images seemed fine to me
[10:49] <lool> We hardcode the config offset in our images?
[10:49] <ogra> its just a start and does the job
[10:49] <lool> Oh but we create it from scratch
[10:49] <ogra> right
[10:49] <ogra> redboot-install uses the same offset
[10:49] <ogra> so as long as you use one of ouor images or used redboot-install, the default is fine ... if not you can use -o
[10:50] <ogra> we'll needs something to change the cmdline once we switch debian-cd
[10:50] <ogra> *need
[10:50] <lool> I'd match on exec .* "" instead of ""
[10:50] <ogra> because at the point wheer redboot-install will run the second partition wont exist, so wee dont have the UUID
[10:50] <lool> No set -e?
[10:51] <ogra> bah, you always catch me on that :P
[10:51] <lool> ogra: otherwise it looks good
[10:52] <ogra> set -e added
[10:53] <ogra> i'll upload it post beta ...
[10:53] <ogra> together with the missing dep on parted ... sigh ...
[11:10] <ogra> yay, casper with my serialtty option was just uploaded :)
[11:15] <lool> ogra: BTW I did an install of Debian Lenny on my Thecus and it did setup a serial TTY
[11:15] <lool> I think we should make sure we do that for imx51, dove, beagle etc.
[11:15] <ogra> with d-i over serial ?
[11:16] <ogra> i know d-i automatically does that if you used a serial tty initially
[11:16] <ogra> but only then
[11:17] <ogra> it doesnt do that if your install ran from tty0
[11:19] <lool> ogra: Ah that might be
[11:19] <lool> ogra: Well that kind of makes sense
[11:20] <lool> We should check that works with our platforms too then
[11:20] <lool> And we could reuse this logic in casper too I guess
[11:21] <ogra> we do :)
[11:21] <ogra> hmm, though ... well
[11:22] <ogra> my current change sets up the device file in /etc/init in the live session only
[11:22] <ogra> that needs additional stuff in ubiquity
[11:23]  * ogra notes on whiteboard under the post beta items
[11:36] <ogra> lool, hmm, though it might be a bit pointless to have such a feature in casper/ubiquity ... you wont be able to actually run ubiquity over serial
[11:37] <ogra> the casper feature only helps for debugging from the livefs
[11:38] <lool> ogra: Yes, but the test would be nice
[11:38] <lool> Not needing any serialtty bit
[11:39] <ogra> what kind of test ? if you set serialtty in casper *and* do a normal install ?
[11:39] <ogra> i.e. have a working X session to run ubiquity
[11:40] <lool> ogra: My understanding is that d-i checks cmdline or /dev/console for a serial tty; if we can copy that bit to setup a getty on serial console during casper, that would be nice
[11:40] <lool> Would avoid needing any cmdline arg
[11:41] <ogra> i'll look what d-i uses for that though i fear the logic to actually match all known serial tty devices might become quite complex
[11:41] <ogra> casper would have to copy that
[11:41] <ogra> i always fear to slow down casper through adding any additional checks
[12:18] <ogra> lool, hmm, the serial console detection in rootskel (which i think is what d-i uses) is quite complex, involving .c tools to actually detect the console type
[12:20] <ogra> it actually seems to use http://paste.ubuntu.com/280299/
[12:23] <ogra> oh, there is an easier way i gues
[12:23] <ogra> s
[12:24] <ogra> heh, i see other code that definately wont work with imx51
[12:24] <ogra> using "readlink /proc/self/fd/0"
[12:34] <ogra> ha ...
[12:34] <ogra> case $(readlink /proc/self/fd/0) in
[12:34] <ogra>     /dev/console|/dev/tty[A-Z]*|/dev/hvc*|/dev/hvsi*)
[12:34] <ogra>     ...
[12:34] <ogra>     ;;
[12:34] <ogra> esac
[12:34] <ogra> that works
[12:35] <ogra> lool, so the above is what d-i seems to use ^^^ should i switch the casper code to it ?
[12:35] <ogra> ogra@babbage2:~$ readlink /proc/self/fd/0
[12:35] <ogra> /dev/ttymxc0
[12:36] <ogra> my issue with it is that it will be run every time if there is no cmdline option while my current code just skips if /proc/cmdline doesnt contain serialtty=
[12:37] <ogra> i.e. it'll slow down all arches
[12:52] <lool> ogra: the above code needs patching
[12:52] <lool> To allow ttymxc0
[12:52] <lool> ogra: I think your code is just as expensive to run as the above
[12:53] <ogra> ogra@babbage2:~$ case $(readlink /proc/self/fd/0) in
[12:53] <ogra> >     /dev/console|/dev/tty[A-Z]*|/dev/hvc*|/dev/hvsi*)
[12:53] <ogra> > TERM_TYPE=serial
[12:53] <ogra> >     ;;
[12:53] <ogra> > esac
[12:53] <ogra> ogra@babbage2:~$ echo $TERM_TYPE
[12:53] <ogra> serial
[12:53] <ogra> no patching needed
[12:53] <lool> Is it /dev/console?
[12:53] <ogra> i dont get why though, i thought the same until i tested
[12:53] <ogra> nope
[12:53] <ogra> <ogra> ogra@babbage2:~$ readlink /proc/self/fd/0
[12:53] <ogra> <ogra> /dev/ttymxc0
[12:54] <ogra> its weird that it matches
[12:54] <lool> Odd, I was sure it was case sensitive
[12:54] <ogra> yes
[12:54] <ogra> me too
[12:55] <lool> case FOO in foo) echo yes ;; esac doesn't match
[12:55] <ogra> http://paste.ubuntu.com/280321/
[12:55] <ogra> thats the full code
[12:55] <lool> case /dev/ttymxc0 in /dev/console|/dev/tty[A-Z]*|/dev/hvc*|/dev/hvsi*) echo yes;; esac => nothing
[12:55] <ogra> using it on my babbage serial console clearly sets TERM_TYPE=serial
[12:56] <lool> I dont have a serial console hooked up right now
[12:56] <ogra> ogra@babbage2:~$ TERM_TYPE=""
[12:56] <ogra> ogra@babbage2:~$ if [ -z "$TERM_TYPE" ]; then
[12:56] <ogra> >     case $(readlink /proc/self/fd/0) in
[12:56] <ogra> >         /dev/console|/dev/tty[A-Z]*|/dev/hvc*|/dev/hvsi*)
[12:56] <ogra> >         TERM_TYPE=serial
[12:56] <ogra> >         ;;
[12:56] <ogra> >         /dev/tty*)
[12:56] <ogra> >         TERM_TYPE=virtual
[12:56] <ogra> >         TERM_FRAMEBUFFER_TRY=yes
[12:56] <ogra> >         ;;
[12:56] <ogra> >         /dev/pts/*)
[12:56] <ogra> >         TERM_TYPE=pts
[12:56] <ogra> >         ;;
[12:56] <ogra> >     esac
[12:56] <ogra> > fi
[12:56] <ogra> ogra@babbage2:~$ echo $TERM_TYPE
[12:56] <ogra> serial
[13:06] <doko__> lool: d-devshlibs is only used to check for missing build dependencies. we know that the dynamic linker is in libc6-dev, so I assume it's safe to remove that. Didn't dig up why it shows up in the first place
[13:07] <lool> doko__: Yes, that's the basic question I have
[13:07] <ogra> should we push that to debian ?
[13:07] <lool> doko__: I agree with you about the change to workaround the effects of our binutils though
[13:08] <ogra> given that mojo had the same prob ages ago
[13:08] <doko__> i filed a bug report
[13:08]  * ogra suspects it makes sense to have it upstream
[13:08] <ogra> cool
[13:09] <doko__> lool: hmm, I don't see the connection yet (binutils/d-shlibs)
[13:10] <lool> doko__: binaries from jaunty didn't have this odd NEEDED entry
[13:10] <lool> doko__: Which is only present on armel since karmic
[13:10] <lool> doko__: So it seems suspicious
[13:13] <doko__> lool: is there a bug report about this?
[13:13] <lool> I don't remember
[13:13] <lool> ogra: Do you remember?
[13:14]  * lool greps ogs
[13:14] <lool> logs
[13:15] <lool> doko__: http://paste.ubuntu.com/280331/
[13:15] <lool> doko__: Conclusion was to consult you   :-)
[13:16] <lool> doko__: http://paste.ubuntu.com/280333/
=== doko__ is now known as doko
[13:38] <ogra> lool, i dont think there was a bug
[13:39] <ogra> (sorry was at lunch )
[13:40] <lool> ogra: You dont think there was a bug where?
[13:40] <ogra> anywhere :)
[13:40] <ogra> i didnt file one
[13:40] <lool> ogra: So why isn't it a bug?
[13:40] <ogra> ??
[13:41] <ogra> i dont say its not a bug
[13:41] <lool> ogra: Sorry misunderstood you
[13:41] <ogra> :)
=== serdar__ is now known as Serdar
=== bjf-afk is now known as bjf
[16:12] <NCommander> lool, ogra, just a note: my change to d-i fixes alternate images on armel in general (we weren't including fat-modules so no alternate CDs are working. I also know theres an optoin that has to be set on the kernel command line to get debian_installer/try-usb set so d-i will work, would either of you know off the top of your head which option that is?
[16:13] <lool> NCommander: I know, I added the fat-modules to imx51 but they were not built at all in dove
[16:14] <NCommander> lool, oh, strange, I didn't see it when I pulled the branch the other day. I must have just missed your commit :-/
[16:14] <ogra> probably fat is in the kernel there ?
[16:14] <ogra> did anyone check ?
[16:15] <NCommander> ogra, its all modules on dove, I didn't check imx51
[16:15] <lool> NCommander: http://bugs.launchpad.net/bugs/431945
[16:15] <ubot4> Launchpad bug 431945 in linux-mvl-dove "Lacks a bunch of modules for d-i support" [Undecided,Fix released]
[16:15] <lool> NCommander: You didn't see build/pkg-lists/cdrom/armel/imx51.cfg?
[16:15] <lool> ogra: I checked yes
[16:15] <lool> NCommander: You also want keyboard modules if any
[16:16] <NCommander> lool, no, i added mine to the generic arm.cfg file. I didn't even see the imx51.cfg one :-/
=== bjf is now known as bjf-afk
[16:38] <ogra> NCommander, err
[16:38] <ogra> NCommander, you are aware that our arch isnt arm, right ?
[16:38] <NCommander> ogra, arm is symlink to armel
[16:38] <NCommander> (in d-i for the pkg-lists)
[16:39] <lool> ogra: haha second time you're hit by this
[16:39] <ogra> heh
[16:40] <lool> ogra, NCommander: Anything you need in d-i before I upload it?
[16:40] <NCommander> lool, just fat-modules/input-modules for d-i on armel. I can't think of any other changes I need off the top of my head (or that I had to make to get d-i do something :-))
[16:40] <ogra> a redboot-imx51-babbage dep would be nice
[16:40] <lool> bdep?
[16:41] <ogra> yep
[16:41]  * NCommander needs to get out of his apartment
[16:41] <ogra> redboot-install doesnt find reboot and fconfig.bin otherwise
[16:41] <ogra> hmm
[16:41] <lool> ogra: So the build fails because of that?
[16:41] <ogra> now i'm pondering a redboot-tools upload
[16:41] <lool> ogra: Can you please fix it in bzr then?
[16:41] <ogra> nope
[16:42] <ogra> redboot-install exists but doesnt make the build fail
[16:42] <lool> ogra: I personally think it makes more sense for redboot-tools to not depend on it; if it's the default you could add a Recommends though
[16:42] <ogra> on what ?
[16:42] <lool> We have the case on antimony that we dont want to install redboot-imx
[16:42] <lool> But we want the tools
[16:42] <lool> ogra: s/exists/exits/?
[16:42] <ogra> redboot-tools doesnt depend on redboot-imx
[16:42] <ogra> and will never do
[16:43] <ogra> but d-i needs to
[16:43] <ogra> for the merged sd netboot image
[16:43] <ogra> exits, yes
[16:44] <lool> ogra: Did you add the image yet?
[16:44] <ogra> d-i needs to b-d on it so redboot-install finds the bianry during its armel build
[16:44] <ogra> yes, but its empty
[16:45] <ogra> due to redboot-install a) not having parted available (missing dep in redboot-tools i added today, but after redboot-cmdline which is why i considered to keep the upload until after beta) and b) not having the redboot binary file
[16:45] <ogra> b) should be solved by the build dep
[16:46] <ogra> (of d-i on redboot-imx51-babbage)
[16:46] <ogra> (on [armel])
[16:48] <lool> Is redboot-tools uploaded with the parted dep?
[16:48] <ogra> no, thats what i said above
[16:49] <lool> ogra: Feel free to commit the relevant bdeps to d-i right now
[16:49] <lool> I'll pull the changes
[16:49] <ogra> it would bring in redboot-cmdline too and i didnt want to upload new code before beta
[16:49] <lool> ogra: Well then that needs to happen now or we need to disable your netboot image
[16:49] <ogra> hrm, ok, then i'll do an upload
[16:49] <ogra> i thought the release managers are busy enough
[16:51] <lool> ogra: Well either do an upload of redboot-tools or disable the netboot image
[16:51] <lool> ogra: I can do the later if you like
[16:51] <ogra> nope, i'll upload redboot-tools
[16:52] <ogra> gimme a sec for the di push
[16:52] <ogra> do you prefer a versioned dep here too ?
[16:52] <ogra> (you wanted me to do one for redboot-tools)
[16:53] <lool> Yes
[16:54] <ogra> lool, ok, i didnt add a changelog entry, change pushed though
[16:55] <ogra> err, yes ?
[16:55] <ogra> meh
[16:55] <ogra> could you add that ?
[16:55] <ogra> 200933-0ubuntu1 is the current redboot version
[16:56] <ogra> awew, CIA bot is evil, it reacts to local commits even if i didnt push
[17:06] <lool> ogra: I would have preferred for you to upload redboot-tools then update d-i but well
[17:06] <ogra> r-t is up
[17:26]  * NCommander is back
[18:02] <lool> NCommander: Can you please revert the flash-kernel bits to use flash-kernel for UUID instead of the initramfs hook?
[18:02] <lool> NCommander: cjwatson commented last week that this was probably not very stable to use
[18:02] <lool> NCommander: I thought you got these bits from #ubuntu-installer
[18:07] <lool> NCommander: (sorry if you missed them   :-/)
=== bjf-afk is now known as bjf
[18:30] <NCommander> lool, oh, I see
[18:31] <NCommander> lool, sure, let me fix that
[18:32] <armin76> NCommander: fix gcc
[18:32] <NCommander> armin76, on SPARC?
[18:32] <NCommander> armin76, or ARM?
[18:32] <NCommander> (and how is it broken on ARM if thats the case)
[18:32] <armin76> NCommander: arm
[18:32] <NCommander> armin76, how is it broken?
[18:33] <armin76> http://bugs.gentoo.org/show_bug.cgi?id=286251
[18:33] <ubot4> bugs.gentoo.org bug 286251 in Core system "sys-devel/gcc-4.4.1 fails to rebuild itself on ARM" [Normal,New]
[18:33] <armin76> nice bot
[18:34] <armin76> NCommander: probably you aren't going to hit it, its probably due to our make line
[18:34] <NCommander> armin76, I don't really have the time to look at Gentoo bugs :-/
[18:34] <armin76> make LDFLAGS=-Wl,-O1 STAGE1_CFLAGS=-O LIBPATH=/usr/lib/gcc/armv5tel-softfloat-linux-gnueabi/4.4.1 'BOOT_CFLAGS= -march=armv5te -pipe -O2' bootstrap-lean
[18:35] <armin76> NCommander: heh, it was just fyi
[18:35]  * NCommander feels like eyes burn
[18:36] <armin76> NCommander: do you have a babbage as well, right?
[18:37] <NCommander> armin76, just a Babbage 1, my imx 2.0 is in London  ATM
[18:37] <armin76> NCommander: gimme!
[18:37] <NCommander> armin76, I don't think you want a B1 :-P
[18:38] <armin76> why not?
[18:39] <NCommander> armin76, USB isn't very stable on it which means your more or less limited to SD cards
[18:40] <armin76> SDHC?
[18:40] <NCommander> armin76, nope
[18:40] <NCommander> (or at least, no SDHC card that I had worked, it was very picky)
[18:41] <armin76> gimme!
[18:41] <armin76> nfs++
[18:48] <NCommander> lool, I'm SO lost on what you want me to do with respect to the UUID its not funny (I just read the logs). Do you want me to keep the current behavior with the UUID then?
[19:07] <lool> NCommander: Sorry, let me send you the relevant logs
[19:08] <lool> ogra: pushed d-i
[19:08] <lool> NCommander: I only included input-modules (+fat on cdrom)
[19:08] <lool> NCommander: I didn't test the z0 stuff; not sure it's picked up -- likely not
[19:08] <lool> But then I don't think we will care much longer about it
[19:08]  * NCommander nods
[19:11] <lool> NCommander: http://paste.ubuntu.com/280589/
[19:11] <lool> NCommander: I did try to ping you on it; I guess I should have updated the bug
[19:11] <lool> NCommander: That was on #ubuntu-installer on 20090924 BTW
[19:12] <NCommander> lool, I probably missed it since my IRC proxy machine had to be restarted and I forgot to dump logs into my client before restarting it
[19:12] <NCommander> ok, so old behavior it is
[19:12] <lool> NCommander: I uploaded d-i now; I will consider updating your flash-kernel tomorrow along d-i and ubiquity if cjwatson is ok with that
[19:12]  * NCommander has the branch ready as soon as I test it
[19:13] <Martyn> Re
[19:13] <Martyn> UEFI is ... neat.
[19:13] <Martyn> A bit full of fail at the moment, but that's because it's seriously alpha on ARM
[19:15] <lool> Martyn: Which UEFI impl are you looking at?
[19:15] <Martyn> apples
[19:15] <Martyn> We have the source and are working on getting it working and compiling.
[19:15] <Martyn> We also hired a new person whose only job is to work on the bootloader now.
[19:16] <Martyn> So, I have high expectations :)
[19:16] <lool> Martyn: Is Apple's open?
[19:17] <Martyn> it is
[19:17] <lool> Martyn: Interesting; URL?
[19:17] <Martyn> They open sourced it two weeks ago (well, it's been open source, but they released it)
[19:17] <Martyn> lool : no idea.  We got it via sneakernet
[19:18] <Martyn> on nothing less than a usb key
[19:18] <lool> What's sneakernet?
[19:19] <Martyn> lool : Put on a pair of sneakers .. then walk?
[19:19] <Martyn> lool : Yep, this is something that I think Ubuntu is moving to.
[19:19] <Martyn> lool : I'll be putting together a blueprint, and getting something ready to present at the ubuntu meetup @Dallas
[19:34] <Martyn> url is edk2.tianocore.org
[19:37] <lool> Martyn: excellent
[19:37] <neonfreon> speak up if you make any progress with it! =)
[19:40] <NCommander> OOOOOOOOH
[19:40]  * NCommander can't believe Apple opened their EFI core
[19:41] <NCommander> its based off Intel's EFI reference implementation but with a ****ton of tweaks for OS X
[19:41] <NCommander> (like FAT binary support and Mach-O support)
[19:41] <NCommander> Martyn, what SoC are you working against?
=== bjf is now known as bjf-afk
=== darkstar62 is now known as darkstar62[away]
=== bjf-afk is now known as bjf
=== darkstar62[away] is now known as darkstar62
=== Q_Continuum_ is now known as Q_Continuum
=== darkstar62 is now known as darkstar62[away]
[22:22] <Martyn> Hey al.
[22:22] <Martyn> lool : awake?
=== darkstar62[away] is now known as darkstar62