[01:09] ogra_cmpc: hmm, it seems that i dont get anything on the s-video output even though i am setting the right boot options [01:10] xorAxAx, which board? [01:10] BB C5 [01:10] BB C4 [01:11] i currently dont have a dvi connector, nor a serial cable, only s-video :) [01:12] that's going to make it almost impossible.. (speciall with no serial cable.) the s-video settings aren't always enabled in every kernel. (nor do i test it) take a look here, nottice how sakoman setup the tv section: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=blobdiff;f=arch/arm/mach-omap2/board-omap3beagle.c;h=915606ed2c8dd82bcd8942a2a0f958de4118e03a;hp=89eca2005d88239bd8ea411e5103c995f52b52e8;hb=9708463105204cb46fa8 [01:12] bd59f309e85f5936d4d6;hpb=76f65e01f23f435497cbd70cb574dd5689cddb58 [01:13] (that failed: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commit;h=9708463105204cb46fa8bd59f309e85f5936d4d6) [01:14] i dont see how that commit would help me [01:14] i'm saying if s-video isn't working, there's a good chance the s-video bits aren't setup... [01:16] looks like they are.. http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=0f66624dea24d97fc700e8effad9c4016a22224f (what's your bootargs) [01:18] setenv bootargs vram=12M omapdss.def_disp=tv omapfb.mode=tv:pal file=/cdrom/preseed/ubuntu-server.seed cdrom-detect/try-usb=true [01:19] rcn-ee: does that make sense? [01:20] that's valid... so how are verifying that's actually getting passed to the kernel? [01:21] i could check the output of uboot [01:22] (flashed an uboot which talks over usb :)) [01:22] okay, wasn't sure on that... can you log the kernel boot for me..? [01:23] i dont get to that step anymore [01:24] because the kernel doesnt talk usb :-P [01:24] hmm, uboot doesnt echo the bootargs [01:24] ah right.. (stick a printenv in your script) [01:26] videomode=1024x768@60,vxres=1024,vyres=768 [01:26] videospec=omapfb:vram:2M,vram:4M [01:26] thats in the env :) [01:27] but thats likely not used [01:27] mmcargs=setenv bootargs console=${console} video=${videospec},mode:${videomode} root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait [01:27] nandargs=setenv bootargs console=${console} video=${videospec},mode:${videomode} root=/dev/mtdblock4 rw rootfstype=jffs2 [01:27] ah, hmm. so it prefixed with video=? [01:27] that's a little weird.. you can call saveenv to safe your bootargs... [01:29] ah yeah i remember now.. that's an older u-boot, before they standarized on boot.scr's the video spec stuff is for 2.6.27/28 kernel's.. [01:29] i guess i'll wait for the serial cable to arrive [01:30] oh you can override, just setenv bootargs ' yada' then saveenv then boot.. [01:30] well, i am booting from sd card [01:30] and i just booted manually [01:31] with copying commands into the prompt [01:35] good night [02:31] What? Why not? [02:32] Err. That's an unintentional repeat. [07:32] amitk: morning [07:32] morning cooloney, all [07:33] amitk: Morning [07:33] morning lag [08:09] morning [08:13] hi [08:13] any ideas why making filesystem would fail in the installer? [08:14] i tried two different (well both were kingston) usb sticks on two different usb hubs [08:14] on beagleboard [08:14] yesterday :) [08:15] can i preformat on pc? [08:15] can i say 'use this partition, dont try to format it'? [08:41] huh [08:41] preformatting on pc helped a little [08:41] now it got to install the base system [08:41] crap [08:41] de bootstrap warning [08:42] ...bsdutils... was corrupt :/ [08:42] ogra_cmpc: can you show me default-after-install bootcmd from uboot? [08:44] ah [08:44] that _could_ explain [08:44] if my installation image was faulty? [08:47] is it possible to install / create the filesystem on a PC? [08:53] neure: You could use rootstock, but check your checksums: it's unlikely that you downloaded a faulty image. [08:54] persia, is it possible that the dd to sdcard was faulty? [08:54] well.. more like.. is it likely :) [08:54] Yes, that's much more likely (but in that case, you don't need a new filesystem) [08:55] since the install media is the sdcard, it should not be usb power issue [08:55] If you know the size, you can dd from the SD to a file, and then checksum compare the download version to the one read from SD. [08:55] unless the error is detected somehow after file has been copied to usb [08:55] well i have the original filesystem on the pc / vmware still [08:55] so i can use ls to get the size :() [08:56] but ḯ'll perhaps try later [08:56] If it's debootstrap failing, that's prior to actually using anything in the constructed target filesystem. [08:56] ok [08:56] could i use rootstock to install directly to the sdcard on pc? [08:57] that way i could bypass usb [08:58] i have ubuntu 9.04 on my vmware, can i use that to put 10.04 on sdcard for beagle? [08:59] hrw, you mean the kernel cmdline ? [09:00] oh, bootcmd [09:00] cmdline="root=UUID=$uuid ro quiet splash vram=12M omapfb.mode=dvi:1280x720MR-16@60 fixrtc" [09:00] bootcmd="nand read 80000000 280000 400000;nand read 81600000 680000 1000000;bootm 80000000 81600000" [09:00] hrw, ^^^ [09:01] thx [09:02] shit - out of luck [09:05] morning ogra [09:06] hey [09:06] hrw, whats wrong ? [09:07] ogra: how was your holiday? [09:07] ogra: nevermind - my error [09:07] short, relaxing and good for my touchbook :) [09:07] ogra: bah, why do you get the fun toys? [09:08] booted 2.6.34 [09:08] the touchbook is _not_ fun, after the first 15mins [09:08] hrw: does it work? [09:08] NCommander, you mean the SM toys :) [09:08] kinky [09:08] * NCommander coughs [09:08] ogra: so I smacked livecd-rootfs with a hammer yesterday [09:09] It now uses loopmounting, and doesn't make my systems free memory drain like a leaking pipe [09:09] ouch, poor livecd-rootfs [09:09] bah [09:09] dont use loop mounting [09:09] ogra: plus now we have ext4 [09:09] ogra: why not? [09:09] its ugly [09:09] amitk: serial works, usb works, 1280x800 on my 20" lcd also works [09:10] hrw: could you try out OTG [09:10] and genext2fs sucked down RAM faster than a hummer sucks down gas [09:10] NCommander, its works just fine [09:10] did you try it on a babbage yet ? [09:10] ogra: considered I never managed to build anything beside a base image with it, I don't think I'd use the word fine [09:10] No, my babbage is upstairs [09:11] i built about ten netbook images since mid last week with it [09:11] amitk: otg refuses to see my hub [09:11] no prob at all, you just need to make sure to have enough swap to pre-allocate the ram space genext2fs copies the files to [09:12] restarting with hub on otg [09:12] i have an identical setup to the buildd here and havent seen any probs [09:12] ogra: I can appericate the concept of throwing more resources to solve a problem, but I draw the line with a 30GiB swap :-) [09:12] i use 2G swap iver here [09:12] *over [09:12] note that 30G is default on the builder [09:13] i dont see any of the probs you mention [09:13] Well, yes, but that's kinda excessive, no? [09:13] are you using the genext2fs under arm from the archive ? [09:13] under ARM and amd64 [09:13] It crashes my laptop like few things ever have. [09:13] amitk: no hub on otg after reboot [09:13] i'D consider that an amd64 bug [09:14] i didnt see any issues under x86 nor under armel [09:14] please stick to the concept [09:14] if you need to access the image (for whatever reason) dont use loop but fuseext2 [09:14] I am sticking to the concept. I'm just not building my images in a way that causes my laptop to go TILT and OOM itself to death [09:14] use your babbage [09:15] thats what we use in the DC [09:15] as i said i dont see such issues on x86 or arm [09:15] i'D file a bug against amd64 :) [09:15] ogra: I'll go test it a little later. In other news, where are we with packaging the new x-loader/u-boot [09:16] since once we get that out of the way, we can spin our first images for omap4 (granted, without jasper they won't work, but at least we can get all the little bits in place) [09:16] i'm getting there slowly [09:16] its a lot of patching involved in x-loader to make it build and i didnt finish that yet [09:17] beyond that x-loader is going away soon so i'm not sure its actually worth the hassle [09:17] as i siad before, just build omap3 images [09:17] we have everything for them in the archive [09:17] No, that's what I'm doing [09:17] But I'd like to just have something that attempts to boot on omap4 ASAP [09:18] well, rather dont hold your breath, dont expect anything before A2 [09:18] * NCommander blinks [09:18] uh, that's July [09:18] cutting it a bit close, no? [09:18] ?? [09:18] thats june [09:19] ogra: https://wiki.ubuntu.com/MaverickReleaseSchedule -A2 is the first week of July [09:19] well, july1 [09:19] anyway, we dont have a kernel in maverick for omap4 [09:19] we cant build anything before thats there [09:20] * NCommander feels like he's missing something, but that may be lack of sleep and/or sanity [09:20] for maverick we need a 2.6.35 omap4 tree [09:20] which doesnt exist yet [09:21] or .34 at least [09:22] ogra: Hi! How do you generate a uImage from a .deb? (mkimage? with which arguments?) I'd like to test cooloney's image but the uImage I generate does not boot at all... [09:23] for omap4 i generate it manually, but with the same options the scripts use ... [09:23] * ogra looks up the command [09:23] mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Ubuntu Kernel" -d vmlinuz-"${KVER}" uImage [09:23] sebjan: it does not boot? [09:24] sebjan, http://paste.ubuntu.com/439253/ is exactly what i have on my blaze atm [09:25] the actual in-distro scripts will do something similar [09:26] ogra: ok thanks, this is what I had been using for the uImage creation... [09:27] sebjan, which u-boot/x-loader do you use ? i still use a binary for the pandaboard i got from robclark [09:27] ogra : cooloney : with the test6 image, I have a Uncompressing Linux...X-Loader hangs [09:27] X-loader hangs ? [09:28] how can it hang when it already loaded the kernel [09:28] ogra: I use the same x-loader/u-boot as before (which was working with test3 image for example) [09:28] amitk: which kernel tree/branch you use for omap3/2.6.34? I want to build compat-wireless against it [09:28] 802.11n dongle will be faster then usb ethernet ;D [09:28] ogra: yes, that's weird :) [09:29] hrw: maverick git tree, master branch [09:29] thx [09:30] * ogra goes to find some breakfast ... back soon [09:33] audio from uds is live [09:34] err, UDS was in the past, so it can't be live. Unless you're hearing future UDS feeds :-p [09:34] s/live/online [09:34] * hrw waits for coffee [09:43] * NCommander notes he'd like to know what specs to write UDS-N already so I can save myself some time [09:47] sebjan: it still doesn't boot? [09:49] cooloney: no, I wonder if it crashes during the uncompressing phase. [09:51] sebjan: too bad. i cannot verify it, i don't have hw yet. only ogra can confirm that [09:54] cooloney: I probably have a problem with my load addresses, I'll check that [09:55] sebjan: ok, no problem. [10:10] ogra: stupid question, how much RAM is in your x86 box? [10:10] 4G [10:11] ogra_cmpc: hrm, thanks [10:12] using the PAE kernel [10:12] the babbage has 512M and 2G swap [10:18] * ogra_tb waves from the touchbook [10:19] hmmm, no sound [10:20] * cooloney waves back to ogra_tb from his pc [10:21] funny, alsamixer has a ton of devices, gnome doesnt [10:23] ogra: morning. do we need a launchpad project for every package that we put in PPA? [10:24] ndec, nah [10:24] ogra: but what if I want that. is that possilble? [10:25] one PPA per package ? [10:25] ogra: nope. 1 PPA many packages [10:25] well, thats what you get [10:25] god, that touchbook kbd kills me [10:26] ogra: so I can't get automatic VCS (like for linut-tiomap) if we use 1 PPA with many packages... right? [10:26] ndec, you can indeed create a project for each package if you like but still upload all of them to the same PPA in the end [10:27] ogra_tb: gnome wants to be simple - forgot it? [10:27] ogra: what would the workflow be then. upload new source to project, and then upload to PPA? [10:27] the VCS you use for a project is independent from the centralized PPA [10:28] ogra: well but for kernel (linux-tiomap) everytime a new .dsc file is uploaded it creates a new bzr version in the corresponding project. at least this is what I understood... [10:28] you can for example have a gstreamer-omap project, have a bzr branch under the project but upload the source packages to the central PPA [10:28] no, it doesnt [10:28] bzr should be independent from the PPA uploads [10:29] * NCommander feels like stabbing something [10:29] hrw, well, i dont think its gnome but either alsa or pulse not handing the device through [10:31] ogra_tb: alsamixer gives you lot of mixer entries so alsa handle it. [10:31] funny is also that jockey came up on first boot here, offering me a driver for twl4030 [10:32] i sadly dont have enough space on the SD to hold the kernel tree to try out dkms modules [10:33] hrw, well, aplay doesnt give me any output even though i unmuted everthing [10:34] ogra: on blaze you have 32Gb of eMMC. you can use fdisk to format. that gives plenty of space [10:35] ogra_tb: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/alsa/alsa-state/omap3-touchbook/asound.state [10:35] ogra_tb: fetch, load, test? [10:35] ndec, i'm playing with the touchbook and ubuntu-netbook atm] [10:35] hrw, thanks [10:35] ogra: oops... [10:35] :) [10:35] the kbd is horrid [10:36] ogra_tb: after 6 years with OE my main source of fixes/configs etc is OE ;D [10:37] * ogra_tb tries firefox for the first time [10:38] ogra_tb: you have 256M or 512M TB? [10:38] 512 [10:38] FF is a bit stuttering but works ok [10:38] (i havent added swap yet) [10:41] ogra_tb: can you join #upstart? [11:25] mumble [11:29] ndec: The automatic bzr commits from uploads comes from something that scans the upload queue for uploads to Ubuntu, and then commits that to special branches. It's somewhat unrelated to either projects or PPAs. [11:29] persia: ok. I see. this is only for projects that are beneath launchpad.net/ubuntu/..., right? [11:30] right [11:30] ndec: You want to talk to james_w about this [11:30] it will happen for uploads to maverick [11:30] but vnot for PPA stuff [11:31] ndec: It could be done for PPAs equally well, but currently we only run package imports for the main Ubuntu archive and for Debian packages imported to Launchpad [11:31] lool, well, ndec doesnt want it for PPAs if i understood correctly [11:32] persia: so in my case, let me know if i get it right: i will create launchpad project such as launchpad.net/something, it will be linked to TI upstream git trees. when I make a new src package, I will upload to PPA. the PPA will have .dsc and .deb. the LP project will be used to report bug. but I won't be able to view the source code from the LP project... [11:32] ndec: You can set up a vcs-imports job that would pull the git commits into bzr daily. [11:32] right [11:32] And that makes bzr branch lp:foo work [11:33] Alternately, you could set up an upload scanner and have taht push to bzr, but if you7re working in git, and you're basically packaging upstream, then it makes more sense to me to have bzr track git. [11:34] ndec: Oh, and for the sake of completeness, your statement is entirely correct without any further effort taken. [11:42] persia: right. i don't want to have a bzr branch that tracks my git trees daily. upstream is done with git. but I would like all my source package to be tracked *somehow*. ideally I would like to commit the content of the source package in either git or bzr. I thought that what was done for linux-tiomap was the perfect solution.. [11:43] persia: so now I can either create an external git tree where I package my upstream git trees (e.g. it would contain debian/ and all packaging patches). or I can use the LP project bzr branch for that... [11:44] ndec: I don't know that much about it, but I believe git-buildpackage was designed to handle that use case. [11:44] I believe the model is to have a packaging branch, and rebase that against the trunk when pushing a package. [11:45] And then the packaging can just be committed to the regular git repos. [11:45] You dont rebase [11:45] you just merge the upstream branch in the packaging one [11:45] Right. [11:46] * persia isn't that familiar with git, and apologies for incorrect terminology [11:46] persia: i didn't know about git-buildpackage. will check that. however note that my upstream (e.g. other dev teams) who owns the dev git tree don't package with debian. so I will need another tree (git or bzr) to store packaging data [11:46] Well you might have to rebase if your tree is rebased [11:46] especially with kernel trees [11:47] But with other software I packaged in git in the past, upstream didn't rebase and I just merged in the packaging branches [11:47] If you work from tarballs, even more so [11:47] ndec: It's best to use the same VCS for both IMO, allows cherry picks [11:47] Indeed. [11:47] Or rather, makes cherry picks *lots* easier [11:47] ndec: For instance, you can prepare a new package upload cherry picking a single patch [11:47] lool: i agree, that also means that i don't need to learn bzr then ;-) [11:48] lol [11:48] It's a win all around :) [11:48] It does mean you get little launchpad integration, for instance your source wont be linked to closed bugs and such [11:48] But it's kind of inevitable that you work with git for kernel trees [11:52] hrw, so lets go to #ubuntu-kernel to talk about serial consoles :) [11:53] (and their upstart autodetection :) ) [11:54] hrw: I'd like to offer review or fixes to your shell script dealing with console= args if you keep it [11:54] I saw some issues with it [11:54] But it might be that it's not part of the final design, so [11:55] lool, well, we just asked Keybuk for upstream inclusion [11:55] and he wants some massive chnages first [11:55] mainly to the kernel [11:56] he also said that using /etc/default violates upstart policy [11:56] It does. [11:57] Yeah [11:57] Mind you, /etc/default is planned to come back with 0.10, but in an entirely different way (and likely with a different path) [11:57] lool, whats the timeline for having it in your arm project ? [11:57] pre maverick ? [11:57] Personally my main problem with it is the approach of having to pass cmdline args for things to work; I'd rather have upstart start a getty on all serial consoles or something like that [11:58] Problem is that there are many possible device names, so the current approach of tty1 - tty8.conf doesn't work [11:58] lool, right, thats what Keybuk wants [11:58] he wants to be able to have a "start on" if the device exists [11:58] without having to parse anything [11:58] I really don't want a getty on all serial. [11:58] ogra: I dont think we're considering changes to our image at this point, but it doesn't matter too much [11:58] so maverick would be fine then [11:58] I use serial for auxillary displays, on which I never want getty [11:59] i really want that function in 10.07 but can solve it trhough having my own package [11:59] though i'd rather not having to duplicate anything [12:00] persia: In most cases, my serial port is an USB adapter to connect to other boards, not to run a getty, so I'm in a similar situation [12:00] amitk: When I do a "git push HEAD", should I have to do things on the remote to see the changes reflected in the directory tree? [12:00] lool, well, the poin tis that you really only want a getty if console= was set on cmdline [12:00] else it doesnt make much sense [12:01] so the code needs to a) get a kerbel event for the device created and b) still needs to parse the cmdline [12:01] *kernel [12:02] So, why are we using upstart for this? [12:02] Couldn't we just add a udev script that parsed the command line and optionally launched getty when a serial port was reported? [12:03] because upstart handles all gettys [12:03] the code we have is already quite ok, its just not upstreamable [12:03] because it relies on the fact that the kernel has serial support builtin [12:04] which is true foe all armel ubuntu kernels but not necessarily for other distros [12:05] lool: ndec: you can have LP integration for closed bugs with kernel git packages if you commit message contains the BugLink keyword [12:05] ogra: 99% of serial console users in Ubuntu don't run armel. Please don't make this an arch-specific solution. [12:06] i will if it doesnt enter maverick in a timely manner [12:07] Why? Why can't it be an arch-neutral solution? [12:07] it can if you can guarantee that there is serial support for all ubuntu kernels [12:08] i know for sure its there for armel [12:08] How much "serial support" do you need? [12:08] a serial console for booting [12:08] serial console ++++++++++++++++++++++++++ [12:08] But since at least one armel kernel flavour is built from the regular kernel tree, I can't imagine it's a big leap to have it just work. [12:09] The kernel team is trying to collect the set of required configurations for a kernel to be an "Ubuntu kernel". Just make sure that the necessary CONFIG flags to make that work are on the list. [12:09] And they'll enforce it for all arches (or fail the builds) [12:09] as i said, if anypone can proof its available in all kernels i have no issue with a autodetect-serial-upstart package or something like that [12:09] until the kernel is fixed upstream to make it upstreamable in upstart [12:10] for now my only focus is 10.07 and only armel [12:11] I understand your focus. I'm just hoping you'd be willing to solve your problems in a way that also solves them for other folks. Getting that guarantee is just a matter of getting stuff into the required list. Specify the kernel config you need to the kernel mailing list, and it's very likely to be done. [12:11] And that saves you then having to hunt down each topic branch for the multitude of armel kernels. [12:11] and i'm not really after pushing a workaround into all arches if there is a proper solution in the pipe [12:12] its more than the kernel config for a proper solution [12:12] it will need patches [12:14] We don't get udev events for serial ports? [12:14] re [12:14] sorry, was called for emergency [12:17] Well, that makes sense. What's the proper solution? [12:19] a kernel event if the console device exists [12:19] so upstart can use "start on" [12:22] ogra: that seems to make some sense. No idea how hard it will be to add event support to the console driver(s), though [12:24] Could that cause a race condition with the VC gettys? [12:25] why ? [12:28] Because they could be consoles, which I wrote before I saw the discussion in -kernel, which makes my question obsolte (and obviouasly underimformed) [12:29] Err, obsolete and obviously underinformed [12:50] NCommander, persia, i have added work items for both of you to https://blueprints.edge.launchpad.net/ubuntu/+spec/preinstalled-sd-card-images-for-omap [12:51] OK. I should be able to get mine for Alpha 3, but not likely before. [12:51] (well, rather, sometime after Alpha 2) [12:51] to late for 10.07 though [12:52] between A2 and 3 should be ok [12:52] Depends on the freeze date, but likely. [12:52] If you need it sooner, please assign to someone else. [12:53] My (rough) guess would be that I'd be done ~15th July. [12:53] then i'll do it myself (which i will do anyway but not as deeply as you will i guess) [12:53] so it will happen in any case [12:53] Shall we plan two passes then? A quick pass for the obvious "Hey, this is broke" stuff, and a second pass for completeness later? [12:54] sure [12:54] With first pass for Alpha 2 and second pass for Alpha 3 (ideally both delivered at least a couple weeks early) [12:54] sounds good [12:54] Great. That works very well for me. [12:59] * hrw -> lunch break [13:32] ndec, did NCommander send you an invitation to the mobile team IRC meeting ? [13:55] lool: s/DH_COMPAT=2 dh_movefiles/dh_install --autodest/g and bumping debian/compat from 5 to 7 solved [13:55] lool: and that way I got gcc built with dh_isntall instead of dh_movefiles [14:02] hrw: did you debdiff the results? [14:02] hrw: dh_movefiles also renames files, so you need to be careful to mv stuff around before dh_install [14:03] lool: I crossbuilt maverick gcc-4.4 before and after changes. debdiff said 'no differences' [14:04] lool, asac, any idea where https://blueprints.edge.launchpad.net/ubuntu-arm/+spec/arm-m-image-builds-without-root went ? [14:05] ogra: to /ubuntu I'm pretty sure [14:05] JamieBennett is mass-moving specs to /ubuntu [14:05] it might also be renamed to mobile- instead of arm- as to allow for separate workitems trackers [14:05] hrm [14:05] not renamed yet [14:05] LP search doesnt find a thing [14:05] hrw: Ah cross-built [14:05] hrw: Please try a normal build (on intel) instead if you can [14:06] hrw: debdiff without and with the changes [14:06] ogra: just remove -arm ;) [14:06] the link then works [14:06] hrw: then open a bug against the source package with a debdiff and ask doko for review [14:06] JamieBennett, merci !! [14:07] ogra: https://edge.launchpad.net/+search?field.text=arm-m-image-builds-without-root works for me (top hit) [14:08] well, my top hit went to ubuntu-arm [14:08] and still does [14:08] sure [14:12] ogra: renamed you BP to mobile-* to set its context better. It can now be found at https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-m-image-builds-without-root! [14:12] thanks [14:19] hrw: When you're working on a work item, you can set it to INPROGRESS [14:19] hrw: when it's complete (fix released), mark it DONE [14:19] ok [14:19] hrw: thanks! [14:21] lool: I miss redmine [14:23] in my previous job we used redmine for task tracking so it was easy to find who is working on what. now it is more fuzzy I feel [14:23] Hmm, I'm quite at a loss on how to spec rm-m-dpkg-wishlist [14:23] *arm-m-dpkg-wishlist [14:28] dpkg wants filters [14:29] btw, i am bit confused what decision you made towards sysroot (in cross compilers) is that against multiarch? [14:29] IIRC, there was a variable WITH_SYSROOT properly set builds (or almost) sysroot cross compilers [14:32] FYI, there was also another variable to provide a canadian cross (have libgcc1 for the target system) called REVERSE_CROSS (or similar) [14:33] if you want a pure cross system, keep canadian cross in mind [14:37] zumbi: There is no decision against multiarch [14:38] zumbi: we will use multiarch when it's available [14:38] but that doesn't seem to be the case right now [14:38] hrw: ^ you might be interested in WITH_SYSROOT and REVERSE_CROSS above [14:38] zumbi: sysroot should already be implemented in gcc-4.5 [14:38] lool: either way is fine for me (at least I have always prefered sysroot way) [14:39] I noticed reverse_cross/deb_cross stuff already [14:39] deb_cross is set automatically for cross builds [14:40] well, thanks for the work, it is looking great! :) [14:40] and reverse_cross is not canadian [14:40] i hope to have some free time to help out sometime [14:40] # build != host && host == target : reverse cross (REVERSE_CROSS == yes) [14:40] # build != host && host != target : canadian (DEB_CROSS == yes) [14:40] # build == host && host != target : typical cross (DEB_CROSS == yes) === DavidBz is now known as berco [14:42] hrw: ok, i was referring to reverse cross then, nowadays, you even need to get a libstdc++ (because lzma dependency on dpkg) for base [14:42] and for most of situation we want normal build or cross. we can use crossgcc to build reversecross [14:43] hrw: i have never tried that crossgcc to build gcc [14:44] zumbi: I did it a lot with OpenEmbedded [14:44]