19:59:06 #startmeeting 19:59:06 Meeting started Tue Dec 15 19:59:06 2009 UTC. The chair is zumbi. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:59:06 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:59:17 #chair GyrosGeier 19:59:17 Current chairs: GyrosGeier zumbi 19:59:23 whee 19:59:34 #help 19:59:39 somebody else wants to chair? 19:59:48 Hmm, how does this work? 19:59:58 Nope 20:00:25 ibr: http://wiki.debian.org/MeetBot/ 20:00:50 MeetBot is going to help us to do the meeting 20:00:50 zumbi: Error: "is" is not a valid command. 20:01:03 Eh, new to irc, too :) 20:01:16 Should I whisper to MeetBot? 20:01:30 ibr: hehe, do you want to introduce yourself? 20:01:57 Sure, I'm Baurzhan Ismagulov 20:02:39 ok, let's start 20:03:11 #link http://wiki.debian.org/Emdebian/Meetings 20:03:20 Thanks :) 20:03:32 #topic Introduction 20:04:18 Hi all, Nicolas Dandrimont, just looking around ;) 20:04:39 Hello all, we are starting our first meeting on IRC to try to keep agenda up to date and organize items, actions and tasks so anybody is able to pick them out 20:04:44 hi olasd_ 20:05:18 Hi olasd_ 20:05:21 #topic Squeeze release goals for emdebian 20:05:44 #link http://wiki.debian.org/Emdebian/SqueezeReleaseGoals 20:06:40 hi olasd_ 20:06:56 This wiki page is empty, so there is a task of filling out how do we want embedded design to be in Debian for the next release 20:07:38 So, feel free to brainstorming it at the moment 20:08:01 Anyone is free to speak anytime 20:08:19 Someone? 20:08:51 #topic Multiarch 20:09:18 GyrosGeier: would you like to follow on this topic? 20:09:23 whee 20:09:40 Do you have a link, too? 20:09:45 sure 20:09:51 I'm somewhat interested in that 20:09:56 #link https://wiki.ubuntu.com/MultiarchCross 20:10:19 Although my emdebian involvement is "I will find time" ATM 20:10:22 the general plan is to have everything in place in squeeze so that we need less and less of dpkg-cross 20:10:23 Thanks 20:10:38 ibr: agenda to follow is at http://wiki.debian.org/Emdebian/Meetings (with references on multiarch topic) 20:10:55 ideally, this means dependencies with full architecture qualification, but unless we implement it, that is not going to happen 20:11:11 Ah, it's at the bottom; ok, see now 20:11:25 ("full qualification" meaning "Depends: libfoo-dev:armel") 20:11:48 the minimum we need is "Build-Depends: libfoo-dev:native" 20:11:56 Aha, neat idea 20:11:59 which is explained on the wiki page 20:12:28 We were thinking about Host-Depends: and Target-Depends:, but this is even better 20:12:33 in either case, we won't get rid of dpkg-cross entirely after squeeze as there are still non-multiarch libraries 20:13:06 GyrosGeier: is "full qualification" drawn in the multicross specification? 20:13:20 IIRC as "would be nice" 20:14:08 basically, we should push :native support into dpkg before squeeze, which we already have some sort of approval for from relevant people 20:14:27 and if there is still time, submit a patch going from there to full qualification 20:14:32 (:native is still needed) 20:14:50 dpkg-cross behaviour for multiarch packages is slightly different 20:15:14 (my proposal) 20:15:52 so, GyrosGeier would you like to take this action? 20:16:18 for multiarch library packages (i.e. those with a Multi-Arch field), the generated -cross package is empty, has the same architecture as the library package, declares a dependency on the library package and M-A: foreign 20:17:08 the idea is that legacy -cross packages can depend on this package, which can be fulfilled from the other arch due to M-A: foreign 20:17:44 and the correct arch -dev package is pulled in as the -cross package declares a dependency on a package that is M-A: same 20:17:57 #action GyrosGeier zumbi to push :native support for dpkg-cross and make sure it is there before squeeze (release goal) 20:18:08 right 20:18:17 do you think this plan could work? 20:18:26 Interesting, that could help with help very much in case of transition 20:18:47 these packages require multiarch enabled apt/dpkg to install 20:19:11 which we have in squeeze, according to Debian release goals 20:19:35 so post-squeeze -dev-*-cross packages will only be installable on squeeze or later 20:19:40 is that acceptable to us? 20:19:51 I do not know if it would work, I think so, but we'll think on it :) 20:20:14 (I could think of a "compatibility" mode where dpkg-cross converts normally and uses a "slightly lower" version 20:20:57 in squeeze+1, we hope that there are no non-multiarch libraries left, so we can retire dpkg-cross then 20:21:02 We need to check with dpkg-cross maintainer which plan does he want to do 20:21:32 because the only packages still depending on -cross packages then are other -cross packages, so we can drop them all at once) 20:21:49 AFAIK dpkg-cross shall die 20:22:20 yes, that's the plan 20:22:37 will happen in squeeze+1, as soon as all libraries have been multiarchified 20:22:59 I've posted a todo list to the list some time ago 20:23:16 GyrosGeier: could you migrate it to wiki? 20:23:24 #link http://lists.debian.org/debian-embedded/2009/11/msg00043.html 20:23:28 sure, can be done 20:24:01 ok, let's move on if nobody wants to add something 20:24:08 #todo GyrosGeier moves multiarch todo list to wiki 20:24:09 well 20:24:36 is multiarch stuff clear to everyone? 20:24:45 #action GyrosGeier moves multiarch todo list to wiki 20:24:49 ah 20:24:51 better 20:25:18 basically we need to touch dpkg in a few places, so we need a perl hacker 20:25:39 well, we better ask maintainer 20:25:44 the stuff we need from dpkg-deb is going to be done by the dpkg team, no problem there 20:26:02 but there are a few scripts like dpkg-checkbuilddeps that need changing 20:26:12 in case, dpkg maintainer request for help, somebody will need to step up 20:26:13 and dpkg maintainers have no real interest in cross compiling 20:26:44 i.e. if we want it, we need to submit patches 20:26:56 As far as we have libs and headers in place, we'll adapt to anything 20:27:39 #topic Which cross tools do we want for Squeeze? 20:27:55 I'd say armel 20:28:30 everything else on emdebian.org 20:28:54 Yes, that was agreed during DebConf in Extremadura 20:29:23 But we need to upload something that afterwards we do not need to draw a migration plan 20:29:27 the road I'd take would be to have one package that has a script that can generate a source package that has the correct incantations to build the cross compiler package 20:29:43 * zumbi refers to layout for squeeze 20:29:48 see agenda notes 20:30:07 i.e. the script would generate a binutils-armel-cross source package that build-depends on binutils-source 20:30:10 same for gdb 20:30:17 same for gcc and libc 20:30:42 gdb has no -source package, but we can talk with its maintainer, there is no problem 20:30:45 and one additional one that build-depends on both gcc and libc source and does a bootstrap 20:31:06 ideally the bootstrapped packages would use a ~ version number 20:31:38 yes ~bootstrap1 20:31:39 so for a new arch, we'd upload both the bootstrap source and the components 20:32:05 and the buildds start with the bootstrap source as components' builddeps cannot be satisfied 20:32:20 ok, bootstrap components are bare-metal compiler newlib based? 20:32:55 no, the bootstrap package does the gcc - libc - gcc - libc - gcc dance 20:32:55 most likely 20:33:06 for whatever libc we have 20:33:15 it then provides the builddeps for the real packages 20:33:23 ok 20:33:39 That is done already for multiple packages 20:33:42 as soon as the real packages are accepted, no binary packages from the bootstrap package remain in the archive, and the source package is cleaned up by ftpmaster 20:34:03 from then on we only do component uploads, unless something breaks 20:34:08 but we were thinking on just do all the xtool dance out of one source package 20:34:28 per arch 20:34:30 yes 20:34:57 the new idea I had then immediately obsoletes the binary packages from that build 20:35:28 we do not want to have to call ftp-masters anytime to remove bootstrap packages 20:35:51 so we upload binutils-armel-cross, bootstrap-armel-cross, eglibc-armel-cross, gcc-armel-cross, gdb-armel-cross all at the same time 20:35:54 so in one build, we could keep them or throw them again 20:35:59 that is automated archive maintenance 20:36:00 s/agin/away 20:36:18 source packages that have no binary packages are removed 20:36:31 GyrosGeier: i was talking more on a cross-armel source package 20:36:40 yes 20:36:55 which builds all the toolchain 20:36:57 that isn't necessary for binutils and gdb, as these can be built standalone 20:37:08 which leaves libc and gcc 20:37:11 also linux headers 20:37:14 true 20:37:43 the goal for us should be to have one source package per tool 20:37:56 so there is no version skew between source and binary packages 20:38:15 while that is technically allowed, it's not nice 20:38:44 so the idea is to have a temporary package that has a bit of a version skew 20:39:10 as it builds a libc binary package that has a different version than the bootstrap source package 20:39:31 but that doesn't matter, as the packages built are replaced by component packages 20:39:52 i.e. gcc-armel-cross and libc-armel-cross replace bootstrap-armel-cross 20:41:17 and which layout? which compiler do we want? built with headers and libs? 20:41:40 as current layout 20:42:04 do we keep same layout for squeeze? 20:43:12 we need to find out if dpkg-cross and apt-cross are going to be released (fixed if broken) 20:43:27 it is sufficient if the bootstrap compiler is built with only C language support 20:43:47 the bootstrap package cannot use dpkg-cross 20:43:52 if not, then I would like to have sysroot compilers until multiarch 20:44:14 as we cannot get binary packages onto the autobuilders 20:44:29 we need sysroot support either way, even with multiarch 20:44:40 because people may want to use non-Debian installs 20:45:03 but for Debian sysroot should be patched with multiarch 20:45:18 even non-sysroot needs multiarch on Debian 20:45:25 i.e. we have three cases 20:45:35 maybe add a switch to pick multiarch/sysroot and non-multiarch/sysroot 20:45:50 which is the other case? 20:46:15 cross compiling using dpkg-cross and multiarch packages within Debian, no --sysroot option given, library search path has /usr/lib/$target and /usr/$target/lib 20:46:46 cross compiling using --sysroot pointed at non-Debian system: library search path needs $sysroot/usr/lib 20:47:23 cross compiling using --sysroot pointed at Debian system: library search path needs $sysroot/usr/lib/$target and $sysroot/usr/lib 20:47:54 the latter two cases are equivalent, as the compiler does not care if $sysroot/usr/lib/$target exists 20:48:15 so if --sysroot is specified, use $sysroot/usr/lib/$target and $sysroot/usr/lib; if not, use /usr/lib/$target and /usr/$target/lib 20:48:43 (add ..include.. as well) 20:48:50 i.e. both sysroot and non-sysroot invocation adds multiarch support 20:48:51 yes 20:49:03 GyrosGeier: later case represents two diferent compilers 20:49:13 no 20:49:32 the emdebian compiler is fully sufficient to build anything with the same ABI 20:50:05 I use the emdebian compiler to build full embedded stuff 20:50:40 yes, but one can not do a sysroot compiler and a libs/headers compiler in one 20:51:37 we need to build --with-sysroot=0 (like /) 20:51:46 yes 20:51:55 basically, --sysroot=/ is special 20:52:28 or rather, "no --sysroot option given on compiler command line" is special 20:52:40 --sysroot=/ and non-sysroot case should have same paths, that would be ideal 20:52:47 cannot be done 20:52:58 sysroot case assumes native layout 20:53:24 ok, lets re focus, for squeeze... what do we want? 20:53:35 basically the switch needs to be whether --sysroot is given on the command line 20:54:00 well have a look to this, but the safe approach is to do what we have been doing 20:54:31 we want a compiler that can use any target libraries installed via multiarch, as well as all legacy libraries that have been installed using dpkg-cross 20:54:40 (that's the minimum requirement) 20:54:58 for squeeze or squeeze+1? 20:56:08 in addition, we'd like to be able to optionally use --sysroot=/home/foo/rootfs to point gcc at a root fs that may or may not use multiarch in order to have it completely switch over 20:56:13 (that's nice to have) 20:56:16 for squeeze 20:56:42 because in squeeze, multiarch dirs are where libc is going to be 20:56:55 and after squeeze, more libraries wander there 20:57:46 ok, so current+multiarch dirs 20:58:09 we do not want to maintain any patch if posible 20:58:44 btw, for infrastructure 20:58:53 armel goes to Debian 20:59:08 but the rest, I am thinking to place them in debian-ports.org 20:59:21 so we do not need to fight infrastructure 20:59:39 well, we need autobuilders for standard Debian arches 20:59:46 if debian-ports can provide these 21:00:09 now that we have autobuilder compatible packages :) 21:00:28 yes, debian-ports can provide it 21:00:47 I have already talked with aurelien (debian-ports admin) 21:00:54 excellent 21:01:12 so debian-ports get an i386 arch as well 21:01:15 and I already have an account and everything 21:01:18 or do they upload to us 21:01:19 ? 21:02:00 I use some other buildd we need to sort out 21:02:27 the question is whether it is a good idea to mix those archives 21:02:46 debian-ports usually have full architectures 21:02:56 we'd bring a bunch of partial ones 21:03:01 that are also in Debian 21:03:15 we add a new suite 21:04:34 'crosstool' suite iirc 21:04:35 that can be done 21:04:35 anyway, let's move on 21:04:35 is there anything agreed? 21:04:44 #action zumbi to upload armel cross tools to Debian. Current layout + multiarch patch enabled 21:04:59 okay 21:05:09 "one big metapackage"? 21:05:18 "small ones + bootstrap"? 21:05:30 #agreed armel cross tools goes to Debian and the rest of tools will live in debian-ports.org in a new suite called 'crosstool' 21:06:14 i do not know on small or big 21:06:24 i have them in small already 21:07:30 okay 21:07:32 #action zumbi resolves how to proceed in one big metapackage or small ones 21:07:38 does bootstrapping work with these? 21:08:06 #topic Toolchain bootstrap 21:08:22 we already went thru this 21:08:34 #topic Phasing out dpkg-cross over the next two years 21:08:55 that is multiarch again 21:09:00 already talked already, in case, someone wants to add something 21:09:20 #topic Grip 2.0 21:09:59 Grip 2.0 is unlikely to happen unless someone commits to it 21:10:23 neil williams is commited to it, isn't he? 21:10:32 Then that's good 21:10:49 I think there is no problem with grip 2.0 21:11:15 well, not as far as we are concerned, because neither of us knows enough perl to help 21:11:29 AndrewLee wants to setup an autobuilder or mirror in .tw (ns.linux.org.tw) 21:11:55 for grip? 21:11:58 hmm 21:12:03 A push mirror infrastructure is done 21:12:06 is autobuilding reproducible? 21:12:33 i.e. will two emgrip instances produce identical binaries, and if not, can they be made to 21:12:37 ? 21:12:40 but distributed builds might be helpful, so we start splitting www.e.o from buildd.e.o 21:13:01 I'm thinking about forcing the gzip timestamp to be same as original package 21:13:11 is there anything else that is variable? 21:13:20 GyrosGeier: neil surely has the details, but there are many arches that could be shared 21:13:50 so let's move on 21:13:51 so action item "ask neil"? 21:14:15 or do we simply expect that to magically happen? :) 21:14:17 #action ask codehelp (Neil Williams) for Grip bits 21:14:53 okay 21:15:02 #topic Crush 2.0 21:15:19 Crush is a cross compiled from source distro 21:15:24 basically, what would be needed here would be a proper autobuilder 21:15:48 it was dropped for Squeeze (before multiarch) 21:16:04 because Neil has no time for that 21:16:15 Is there some docs about that? 21:16:25 ibr: about what? 21:16:30 About Crush 21:17:02 #link http://www.emdebian.org/crush/ 21:17:16 we have a bunch of patches against packages 21:17:40 which largely use xcontrol to do the host/target build-dep split 21:17:47 also slind.org can be helpful 21:18:16 GyrosGeier: dh_auto_configure, now, handles cross compiling case 21:18:16 when squeeze supports :native, all these can be merged into packages 21:18:35 yes, but build-dep split is still missing 21:19:10 What is build-dep split? 21:19:14 I was thinking on try to cross build crush 1.0 using emulation help 21:19:14 I think the way to go here would be to set up an autobuilder with a hints database that allows us to override builddeps 21:19:31 ibr, Host-Build-Depends/Target-Build-Depends 21:19:36 * zumbi also thinks on cross compiling d-i udebs 21:20:01 it is quite unlikely that we can get :native qualifiers into squeeze 21:20:22 because a) the window for that is very small, and b) that would make backports difficult 21:20:38 (squeeze -> lenny backports) 21:20:55 so if we have a squeeze release, it is going to be sourceful 21:21:12 ok, so crush dropped for squeeze release, and we can play wacky on crush 21:21:28 do test and experiments, ok? 21:21:48 I'd start with a crush sid autobuilder 21:22:17 Do we have a wiki page to coordinate crush? 21:22:22 no idea 21:22:59 well, if there is not one lets write the roadmap 21:23:15 and link all useful bits there 21:23:22 there is http://wiki.debian.org/EmdebianCrush 21:23:38 which is a copy of Neil's mail 21:23:48 ok, so 21:24:05 I'd suggest we use the todo list there and extend 21:24:09 #action update crush wiki pages and write a roadmap 21:24:10 sup y'all 21:24:18 #link http://wiki.debian.org/EmdebianCrush 21:24:29 so i have what i THINK is a distro of emdebian running on a zipit Z2 21:24:32 shifuimam, meeting is up :) 21:24:35 having trouble getting wpa_supplicant to work, all of a suden 21:24:37 sudden* 21:24:59 shifuimam: hi - we are in a meeting, try #debian 21:25:05 i did. they told me to come here. 21:25:07 heh 21:25:17 tell them you run debian :) 21:25:36 lol 21:25:54 they don't like me over there 21:26:07 the problem with wpa_suppository is that it's hard to debug 21:26:31 it thinks it's running but running dhclient claims no DHCP server available 21:26:45 ok -- we should proceed with meeting 21:26:57 #topic Development framework: Tools integration 21:27:21 shifuimam, try running wpa_cli and look for output there 21:27:36 at this point, it's very much like a desktop system still 21:27:50 zumbi, not sure we can really integrate tools well 21:28:25 well, lets think about it, but there is happening lot of good stuff related to emulation 21:28:46 also, remark a "nice to have" eclipse plugin for our tools 21:28:49 I'd rather have stuff implemented cleanly than resort to emulation 21:28:56 but, none of use use eclipse 21:29:22 It is just a remark, in case someone volunteers 21:29:25 problem being that qemu either emulates a full system or needs a static qemu binary installed in the target system 21:29:45 GyrosGeier: yes, static approach 21:29:56 neither of which is going to be really robust 21:30:33 i have used before qemu-static and it is somehow slow, but it works 21:30:54 there are also improvements to speed up the thing 21:31:18 I think it'd make more sense to put some effort into making the base system cross-autobuildable without resorting to emulation 21:31:31 then we have leverage on package maintainers 21:31:34 And this is a shorcut to use with crush 21:32:06 GyrosGeier: long term yes, but we can not wait forever 21:32:30 we have a short-mid term tool which help us to resolve cleanly those bits 21:32:55 I'll have a look to it for a posible crush 21:32:56 the alternative I can see is running qemu-armel from the dom0 21:33:14 i.e. I could set up a small ARM system as a virtual server 21:33:54 which would use virtio to talk to the host system 21:34:06 but that's not cross compiling then 21:34:29 yeap 21:34:38 but you can link a cross compiler there 21:34:59 not if it's a proper virtual box 21:35:02 having a native arch chroot inside 21:35:09 actually, as I demoed to zumbi, it is possible to use a dynamicly linked qemu-linux-user in a cross-arch chroot 21:35:40 yes, this is true 21:35:43 does that properly work for vfork()+exec()? 21:35:55 GyrosGeier: even python 21:36:02 fork and exec yes, haven't tried vfork 21:36:03 excellent 21:36:23 the "script inbetween" is the hardest case of all 21:36:46 suihkulokki: i did not meant to make a release of it, but do you have any useful pointer? 21:37:18 I have started work on a tool to scan a {pre,post}{inst,rm} file and convert commands to work from outside a chroot 21:38:10 with some detection for 'if [ "$1" == "upgrade" ]' and the like 21:38:14 GyrosGeier: but it is the other way arround, you fetch from an insider chroot :) 21:38:58 I want to go towards a debootstrap tool that gives you a fully installed root fs without emulating anything 21:39:21 which fails if any package does something in a script which we don't recognize 21:39:24 that would be udeb based 21:39:39 without posibility to upgrade 21:39:44 the tool is called croco, and there is a demo here: http://afflict.kos.to/ 21:39:52 no pre, post scripts 21:40:09 #link http://afflict.kos.to/ 21:40:30 the bulk of the 245MB tar is fresh deboostrapped armel+x86 squeeze + zumbi's crosscompiler 21:41:14 but given that most packages do 'if [ "$1" == "configure" ]; then ldconfig; fi', recognizing that pattern alone will already allow us to detect that those scripts can be skipped 21:41:31 GyrosGeier: ^ that's one of the reasons I want sysroot compilers 21:41:50 sysroot compilers are tremenduously useful 21:42:31 but if we completely go to sysroot, we can drop all the dpkg-cross and multiarch stuff right away and just require everyone to use chroots for cross compiling 21:42:54 * suihkulokki .oO( with the recent disaster with fontconfig prerm trying to call nonexisting defoma tools messing all buildd chroots, I would be happy to ban maintainer scripts ) 21:42:59 yes, so, no more fighting with other groups 21:44:12 so, any action? 21:44:16 fwiw added zumbi, wookey_ and GyrosGeier to #emdebian masters 21:44:23 whee 21:44:36 anyone else? 21:44:36 hey! thanks :) 21:44:47 suihkulokki: p2-mate 21:45:17 I'd rather not force people to use chroots 21:45:47 why not? 21:45:49 p2-mate: register your nick and you'll get powers 21:45:58 it is a good thing one can set up -dev-*-cross plus emdebian toolchain from packages and have a working environment 21:46:15 Yes 21:46:16 register my nick ? 21:46:23 SLIND uses chroots 21:46:48 It becomes "difficult" with time 21:47:09 Although it has its advantages 21:47:43 I see more advantages nowadays than disadvantages 21:48:12 chroots have their inconviencies.. but they are damn lot more reliable IME 21:48:33 they are more difficult to set up than "apt-get install" 21:48:50 Well, setting up is a matter of debootstrapping 21:48:53 GyrosGeier: that can be automated 21:49:02 But after that, you sometimes have to duplicate all the tools 21:49:03 and imply bind mounts for home dir etc 21:49:12 It's ok if it's emacs 21:49:13 yeah, you really want git for example 21:49:26 apt-get install =) 21:49:39 and preferably not emulated :) 21:50:15 p2-mate: Yes, I was going to tell about ClearCase :) (although I'll understand if nobody cares :) ) 21:50:36 I think it's fine if we don't support ClearCase ... 21:50:41 :P 21:50:52 @agreed we don't support clearcase 21:51:03 No problem with me :) 21:51:04 #agreed we don't support clearcase 21:51:08 heh 21:51:13 If you have money to buy clearcase, we can sell you a clearcase supporting solution =) 21:51:16 zumbi, that was not a typo :) 21:51:31 anyway 21:51:32 GyrosGeier: I thought it was 21:51:59 -dev-*-cross has its advantages 21:52:12 yes 21:52:21 specifically, being autobuild safe 21:52:48 I wouldn't want the scripting hell that is an auto-debootstrapping autobuider 21:52:51 +l 21:53:08 not really different from pbuilder ? 21:53:21