19:59:06 <zumbi> #startmeeting
19:59:06 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:59:17 <zumbi> #chair GyrosGeier
19:59:17 <MeetBot> Current chairs: GyrosGeier zumbi
19:59:23 <GyrosGeier> whee
19:59:34 <ibr> #help
19:59:39 <zumbi> somebody else wants to chair?
19:59:48 <ibr> Hmm, how does this work?
19:59:58 <ibr> Nope
20:00:25 <zumbi> ibr: http://wiki.debian.org/MeetBot/
20:00:50 <zumbi> MeetBot is going to help us to do the meeting
20:00:50 <MeetBot> zumbi: Error: "is" is not a valid command.
20:01:03 <ibr> Eh, new to irc, too :)
20:01:16 <ibr> Should I whisper to MeetBot?
20:01:30 <zumbi> ibr: hehe, do you want to introduce yourself?
20:01:57 <ibr> Sure, I'm Baurzhan Ismagulov
20:02:39 <zumbi> ok, let's start
20:03:11 <zumbi> #link http://wiki.debian.org/Emdebian/Meetings
20:03:20 <ibr> Thanks :)
20:03:32 <zumbi> #topic Introduction
20:04:18 <olasd_> Hi all, Nicolas Dandrimont, just looking around ;)
20:04:39 <zumbi> 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 <zumbi> hi olasd_
20:05:18 <ibr> Hi olasd_
20:05:21 <zumbi> #topic Squeeze release goals for emdebian
20:05:44 <zumbi> #link http://wiki.debian.org/Emdebian/SqueezeReleaseGoals
20:06:40 <sgnb> hi olasd_
20:06:56 <zumbi> 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 <zumbi> So, feel free to brainstorming it at the moment
20:08:01 <zumbi> Anyone is free to speak anytime
20:08:19 <zumbi> Someone?
20:08:51 <zumbi> #topic Multiarch
20:09:18 <zumbi> GyrosGeier: would you like to follow on this topic?
20:09:23 <GyrosGeier> whee
20:09:40 <ibr> Do you have a link, too?
20:09:45 <GyrosGeier> sure
20:09:51 <ibr> I'm somewhat interested in that
20:09:56 <GyrosGeier> #link https://wiki.ubuntu.com/MultiarchCross
20:10:19 <ibr> Although my emdebian involvement is "I will find time" ATM
20:10:22 <GyrosGeier> the general plan is to have everything in place in squeeze so that we need less and less of dpkg-cross
20:10:23 <ibr> Thanks
20:10:38 <zumbi> ibr: agenda to follow is at http://wiki.debian.org/Emdebian/Meetings (with references on multiarch topic)
20:10:55 <GyrosGeier> ideally, this means dependencies with full architecture qualification, but unless we implement it, that is not going to happen
20:11:11 <ibr> Ah, it's at the bottom; ok, see now
20:11:25 <GyrosGeier> ("full qualification" meaning "Depends: libfoo-dev:armel")
20:11:48 <GyrosGeier> the minimum we need is "Build-Depends: libfoo-dev:native"
20:11:56 <ibr> Aha, neat idea
20:11:59 <GyrosGeier> which is explained on the wiki page
20:12:28 <ibr> We were thinking about Host-Depends: and Target-Depends:, but this is even better
20:12:33 <GyrosGeier> in either case, we won't get rid of dpkg-cross entirely after squeeze as there are still non-multiarch libraries
20:13:06 <zumbi> GyrosGeier: is "full qualification" drawn in the multicross specification?
20:13:20 <GyrosGeier> IIRC as "would be nice"
20:14:08 <GyrosGeier> 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 <GyrosGeier> and if there is still time, submit a patch going from there to full qualification
20:14:32 <GyrosGeier> (:native is still needed)
20:14:50 <GyrosGeier> dpkg-cross behaviour for multiarch packages is slightly different
20:15:14 <GyrosGeier> (my proposal)
20:15:52 <zumbi> so, GyrosGeier would you like to take this action?
20:16:18 <GyrosGeier> 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 <GyrosGeier> 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 <GyrosGeier> 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 <zumbi> #action GyrosGeier zumbi to push :native support for dpkg-cross and make sure it is there before squeeze (release goal)
20:18:08 <GyrosGeier> right
20:18:17 <GyrosGeier> do you think this plan could work?
20:18:26 <zumbi> Interesting, that could help with help very much in case of transition
20:18:47 <GyrosGeier> these packages require multiarch enabled apt/dpkg to install
20:19:11 <GyrosGeier> which we have in squeeze, according to Debian release goals
20:19:35 <GyrosGeier> so post-squeeze -dev-*-cross packages will only be installable on squeeze or later
20:19:40 <GyrosGeier> is that acceptable to us?
20:19:51 <zumbi> I do not know if it would work, I think so, but we'll think on it :)
20:20:14 <GyrosGeier> (I could think of a "compatibility" mode where dpkg-cross converts normally and uses a "slightly lower" version
20:20:57 <GyrosGeier> in squeeze+1, we hope that there are no non-multiarch libraries left, so we can retire dpkg-cross then
20:21:02 <zumbi> We need to check with dpkg-cross maintainer which plan does he want to do
20:21:32 <GyrosGeier> 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 <GyrosGeier> AFAIK dpkg-cross shall die
20:22:20 <zumbi> yes, that's the plan
20:22:37 <GyrosGeier> will happen in squeeze+1, as soon as all libraries have been multiarchified
20:22:59 <GyrosGeier> I've posted a todo list to the list some time ago
20:23:16 <zumbi> GyrosGeier: could you migrate it to wiki?
20:23:24 <GyrosGeier> #link http://lists.debian.org/debian-embedded/2009/11/msg00043.html
20:23:28 <GyrosGeier> sure, can be done
20:24:01 <zumbi> ok, let's move on if nobody wants to add something
20:24:08 <GyrosGeier> #todo GyrosGeier moves multiarch todo list to wiki
20:24:09 <GyrosGeier> well
20:24:36 <GyrosGeier> is multiarch stuff clear to everyone?
20:24:45 <zumbi> #action GyrosGeier moves multiarch todo list to wiki
20:24:49 <GyrosGeier> ah
20:24:51 <GyrosGeier> better
20:25:18 <GyrosGeier> basically we need to touch dpkg in a few places, so we need a perl hacker
20:25:39 <zumbi> well, we better ask maintainer
20:25:44 <GyrosGeier> the stuff we need from dpkg-deb is going to be done by the dpkg team, no problem there
20:26:02 <GyrosGeier> but there are a few scripts like dpkg-checkbuilddeps that need changing
20:26:12 <zumbi> in case, dpkg maintainer request for help, somebody will need to step up
20:26:13 <GyrosGeier> and dpkg maintainers have no real interest in cross compiling
20:26:44 <GyrosGeier> i.e. if we want it, we need to submit patches
20:26:56 <zumbi> As far as we have libs and headers in place, we'll adapt to anything
20:27:39 <zumbi> #topic Which cross tools do we want for Squeeze?
20:27:55 <GyrosGeier> I'd say armel
20:28:30 <GyrosGeier> everything else on emdebian.org
20:28:54 <zumbi> Yes, that was agreed during DebConf in Extremadura
20:29:23 <zumbi> But we need to upload something that afterwards we do not need to draw a migration plan
20:29:27 <GyrosGeier> 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 <zumbi> see agenda notes
20:30:07 <GyrosGeier> i.e. the script would generate a binutils-armel-cross source package that build-depends on binutils-source
20:30:10 <GyrosGeier> same for gdb
20:30:17 <GyrosGeier> same for gcc and libc
20:30:42 <zumbi> gdb has no -source package, but we can talk with its maintainer, there is no problem
20:30:45 <GyrosGeier> and one additional one that build-depends on both gcc and libc source and does a bootstrap
20:31:06 <GyrosGeier> ideally the bootstrapped packages would use a ~ version number
20:31:38 <zumbi> yes ~bootstrap1
20:31:39 <GyrosGeier> so for a new arch, we'd upload both the bootstrap source and the components
20:32:05 <GyrosGeier> and the buildds start with the bootstrap source as components' builddeps cannot be satisfied
20:32:20 <zumbi> ok, bootstrap components are bare-metal compiler newlib based?
20:32:55 <GyrosGeier> no, the bootstrap package does the gcc - libc - gcc - libc - gcc dance
20:32:55 <zumbi> most likely
20:33:06 <GyrosGeier> for whatever libc we have
20:33:15 <GyrosGeier> it then provides the builddeps for the real packages
20:33:23 <zumbi> ok
20:33:39 <zumbi> That is done already for multiple packages
20:33:42 <GyrosGeier> 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 <GyrosGeier> from then on we only do component uploads, unless something breaks
20:34:08 <zumbi> but we were thinking on just do all the xtool dance out of one source package
20:34:28 <GyrosGeier> per arch
20:34:30 <GyrosGeier> yes
20:34:57 <GyrosGeier> the new idea I had then immediately obsoletes the binary packages from that build
20:35:28 <zumbi> we do not want to have to call ftp-masters anytime to remove bootstrap packages
20:35:51 <GyrosGeier> 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 <zumbi> so in one build, we could keep them or throw them again
20:35:59 <GyrosGeier> that is automated archive maintenance
20:36:00 <zumbi> s/agin/away
20:36:18 <GyrosGeier> source packages that have no binary packages are removed
20:36:31 <zumbi> GyrosGeier: i was talking more on a cross-armel source package
20:36:40 <GyrosGeier> yes
20:36:55 <zumbi> which builds all the toolchain
20:36:57 <GyrosGeier> that isn't necessary for binutils and gdb, as these can be built standalone
20:37:08 <GyrosGeier> which leaves libc and gcc
20:37:11 <zumbi> also linux headers
20:37:14 <GyrosGeier> true
20:37:43 <GyrosGeier> the goal for us should be to have one source package per tool
20:37:56 <GyrosGeier> so there is no version skew between source and binary packages
20:38:15 <GyrosGeier> while that is technically allowed, it's not nice
20:38:44 <GyrosGeier> so the idea is to have a temporary package that has a bit of a version skew
20:39:10 <GyrosGeier> as it builds a libc binary package that has a different version than the bootstrap source package
20:39:31 <GyrosGeier> but that doesn't matter, as the packages built are replaced by component packages
20:39:52 <GyrosGeier> i.e. gcc-armel-cross and libc-armel-cross replace bootstrap-armel-cross
20:41:17 <zumbi> and which layout? which compiler do we want? built with headers and libs?
20:41:40 <zumbi> as current layout
20:42:04 <zumbi> do we keep same layout for squeeze?
20:43:12 <zumbi> we need to find out if dpkg-cross and apt-cross are going to be released (fixed if broken)
20:43:27 <GyrosGeier> it is sufficient if the bootstrap compiler is built with only C language support
20:43:47 <GyrosGeier> the bootstrap package cannot use dpkg-cross
20:43:52 <zumbi> if not, then I would like to have sysroot compilers until multiarch
20:44:14 <GyrosGeier> as we cannot get binary packages onto the autobuilders
20:44:29 <GyrosGeier> we need sysroot support either way, even with multiarch
20:44:40 <GyrosGeier> because people may want to use non-Debian installs
20:45:03 <zumbi> but for Debian sysroot should be patched with multiarch
20:45:18 <GyrosGeier> even non-sysroot needs multiarch on Debian
20:45:25 <GyrosGeier> i.e. we have three cases
20:45:35 <zumbi> maybe add a switch to pick multiarch/sysroot and non-multiarch/sysroot
20:45:50 <zumbi> which is the other case?
20:46:15 <GyrosGeier> 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 <GyrosGeier> cross compiling using --sysroot pointed at non-Debian system: library search path needs $sysroot/usr/lib
20:47:23 <GyrosGeier> cross compiling using --sysroot pointed at Debian system: library search path needs $sysroot/usr/lib/$target and $sysroot/usr/lib
20:47:54 <GyrosGeier> the latter two cases are equivalent, as the compiler does not care if $sysroot/usr/lib/$target exists
20:48:15 <GyrosGeier> 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 <zumbi> (add ..include.. as well)
20:48:50 <GyrosGeier> i.e. both sysroot and non-sysroot invocation adds multiarch support
20:48:51 <GyrosGeier> yes
20:49:03 <zumbi> GyrosGeier: later case represents two diferent compilers
20:49:13 <GyrosGeier> no
20:49:32 <GyrosGeier> the emdebian compiler is fully sufficient to build anything with the same ABI
20:50:05 <GyrosGeier> I use the emdebian compiler to build full embedded stuff
20:50:40 <zumbi> yes, but one can not do a sysroot compiler and a libs/headers compiler in one
20:51:37 <zumbi> we need to build --with-sysroot=0 (like /)
20:51:46 <GyrosGeier> yes
20:51:55 <GyrosGeier> basically, --sysroot=/ is special
20:52:28 <GyrosGeier> or rather, "no --sysroot option given on compiler command line" is special
20:52:40 <zumbi> --sysroot=/ and non-sysroot case should have same paths, that would be ideal
20:52:47 <GyrosGeier> cannot be done
20:52:58 <GyrosGeier> sysroot case assumes native layout
20:53:24 <zumbi> ok, lets re focus, for squeeze... what do we want?
20:53:35 <GyrosGeier> basically the switch needs to be whether --sysroot is given on the command line
20:54:00 <zumbi> well have a look to this, but the safe approach is to do what we have been doing
20:54:31 <GyrosGeier> 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 <GyrosGeier> (that's the minimum requirement)
20:54:58 <zumbi> for squeeze or squeeze+1?
20:56:08 <GyrosGeier> 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 <GyrosGeier> (that's nice to have)
20:56:16 <GyrosGeier> for squeeze
20:56:42 <GyrosGeier> because in squeeze, multiarch dirs are where libc is going to be
20:56:55 <GyrosGeier> and after squeeze, more libraries wander there
20:57:46 <zumbi> ok, so current+multiarch dirs
20:58:09 <zumbi> we do not want to maintain any patch if posible
20:58:44 <zumbi> btw, for infrastructure
20:58:53 <zumbi> armel goes to Debian
20:59:08 <zumbi> but the rest, I am thinking to place them in debian-ports.org
20:59:21 <zumbi> so we do not need to fight infrastructure
20:59:39 <GyrosGeier> well, we need autobuilders for standard Debian arches
20:59:46 <GyrosGeier> if debian-ports can provide these
21:00:09 <zumbi> now that we have autobuilder compatible packages :)
21:00:28 <zumbi> yes, debian-ports can provide it
21:00:47 <zumbi> I have already talked with aurelien (debian-ports admin)
21:00:54 <GyrosGeier> excellent
21:01:12 <GyrosGeier> so debian-ports get an i386 arch as well
21:01:15 <zumbi> and I already have an account and everything
21:01:18 <GyrosGeier> or do they upload to us
21:01:19 <GyrosGeier> ?
21:02:00 <zumbi> I use some other buildd we need to sort out
21:02:27 <GyrosGeier> the question is whether it is a good idea to mix those archives
21:02:46 <GyrosGeier> debian-ports usually have full architectures
21:02:56 <GyrosGeier> we'd bring a bunch of partial ones
21:03:01 <GyrosGeier> that are also in Debian
21:03:15 <zumbi> we add a new suite
21:04:34 <zumbi> 'crosstool' suite iirc
21:04:35 <GyrosGeier> that can be done
21:04:35 <zumbi> anyway, let's move on
21:04:35 <GyrosGeier> is there anything agreed?
21:04:44 <zumbi> #action zumbi to upload armel cross tools to Debian. Current layout + multiarch patch enabled
21:04:59 <GyrosGeier> okay
21:05:09 <GyrosGeier> "one big metapackage"?
21:05:18 <GyrosGeier> "small ones + bootstrap"?
21:05:30 <zumbi> #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 <zumbi> i do not know on small or big
21:06:24 <zumbi> i have them in small already
21:07:30 <GyrosGeier> okay
21:07:32 <zumbi> #action zumbi resolves how to proceed in one big metapackage or small ones
21:07:38 <GyrosGeier> does bootstrapping work with these?
21:08:06 <zumbi> #topic Toolchain bootstrap
21:08:22 <zumbi> we already went thru this
21:08:34 <zumbi> #topic Phasing out dpkg-cross over the next two years
21:08:55 <GyrosGeier> that is multiarch again
21:09:00 <zumbi> already talked already, in case, someone wants to add something
21:09:20 <zumbi> #topic Grip 2.0
21:09:59 <GyrosGeier> Grip 2.0 is unlikely to happen unless someone commits to it
21:10:23 <zumbi> neil williams is commited to it, isn't he?
21:10:32 <GyrosGeier> Then that's good
21:10:49 <zumbi> I think there is no problem with grip 2.0
21:11:15 <GyrosGeier> well, not as far as we are concerned, because neither of us knows enough perl to help
21:11:29 <zumbi> AndrewLee wants to setup an autobuilder or mirror in .tw (ns.linux.org.tw)
21:11:55 <GyrosGeier> for grip?
21:11:58 <GyrosGeier> hmm
21:12:03 <zumbi> A push mirror infrastructure is done
21:12:06 <GyrosGeier> is autobuilding reproducible?
21:12:33 <GyrosGeier> i.e. will two emgrip instances produce identical binaries, and if not, can they be made to
21:12:37 <GyrosGeier> ?
21:12:40 <zumbi> but distributed builds might be helpful, so we start splitting www.e.o from buildd.e.o
21:13:01 <GyrosGeier> I'm thinking about forcing the gzip timestamp to be same as original package
21:13:11 <GyrosGeier> is there anything else that is variable?
21:13:20 <zumbi> GyrosGeier: neil surely has the details, but there are many arches that could be shared
21:13:50 <zumbi> so let's move on
21:13:51 <GyrosGeier> so action item "ask neil"?
21:14:15 <GyrosGeier> or do we simply expect that to magically happen? :)
21:14:17 <zumbi> #action ask codehelp (Neil Williams) for Grip bits
21:14:53 <GyrosGeier> okay
21:15:02 <zumbi> #topic Crush 2.0
21:15:19 <zumbi> Crush is a cross compiled from source distro
21:15:24 <GyrosGeier> basically, what would be needed here would be a proper autobuilder
21:15:48 <zumbi> it was dropped for Squeeze (before multiarch)
21:16:04 <GyrosGeier> because Neil has no time for that
21:16:15 <ibr> Is there some docs about that?
21:16:25 <zumbi> ibr: about what?
21:16:30 <ibr> About Crush
21:17:02 <zumbi> #link http://www.emdebian.org/crush/
21:17:16 <GyrosGeier> we have a bunch of patches against packages
21:17:40 <GyrosGeier> which largely use xcontrol to do the host/target build-dep split
21:17:47 <zumbi> also slind.org can be helpful
21:18:16 <zumbi> GyrosGeier: dh_auto_configure, now, handles cross compiling case
21:18:16 <GyrosGeier> when squeeze supports :native, all these can be merged into packages
21:18:35 <GyrosGeier> yes, but build-dep split is still missing
21:19:10 <ibr> What is build-dep split?
21:19:14 <zumbi> I was thinking on try to cross build crush 1.0 using emulation help
21:19:14 <GyrosGeier> 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 <GyrosGeier> ibr, Host-Build-Depends/Target-Build-Depends
21:19:36 * zumbi also thinks on cross compiling d-i udebs
21:20:01 <GyrosGeier> it is quite unlikely that we can get :native qualifiers into squeeze
21:20:22 <GyrosGeier> because a) the window for that is very small, and b) that would make backports difficult
21:20:38 <GyrosGeier> (squeeze -> lenny backports)
21:20:55 <GyrosGeier> so if we have a squeeze release, it is going to be sourceful
21:21:12 <zumbi> ok, so crush dropped for squeeze release, and we can play wacky on crush
21:21:28 <zumbi> do test and experiments, ok?
21:21:48 <GyrosGeier> I'd start with a crush sid autobuilder
21:22:17 <zumbi> Do we have a wiki page to coordinate crush?
21:22:22 <GyrosGeier> no idea
21:22:59 <zumbi> well, if there is not one lets write the roadmap
21:23:15 <zumbi> and link all useful bits there
21:23:22 <GyrosGeier> there is http://wiki.debian.org/EmdebianCrush
21:23:38 <GyrosGeier> which is a copy of Neil's mail
21:23:48 <zumbi> ok, so
21:24:05 <GyrosGeier> I'd suggest we use the todo list there and extend
21:24:09 <zumbi> #action update crush wiki pages and write a roadmap
21:24:10 <shifuimam> sup y'all
21:24:18 <GyrosGeier> #link http://wiki.debian.org/EmdebianCrush
21:24:29 <shifuimam> so i have what i THINK is a distro of emdebian running on a zipit Z2
21:24:32 <GyrosGeier> shifuimam, meeting is up :)
21:24:35 <shifuimam> having trouble getting wpa_supplicant to work, all of a suden
21:24:37 <shifuimam> sudden*
21:24:59 <zumbi> shifuimam: hi - we are in a meeting, try #debian
21:25:05 <shifuimam> i did. they told me to come here.
21:25:07 <GyrosGeier> heh
21:25:17 <zumbi> tell them you run debian :)
21:25:36 <GyrosGeier> lol
21:25:54 <shifuimam> they don't like me over there
21:26:07 <GyrosGeier> the problem with wpa_suppository is that it's hard to debug
21:26:31 <shifuimam> it thinks it's running but running dhclient claims no DHCP server available
21:26:45 <zumbi> ok -- we should proceed with meeting
21:26:57 <zumbi> #topic Development framework: Tools integration
21:27:21 <GyrosGeier> shifuimam, try running wpa_cli and look for output there
21:27:36 <GyrosGeier> at this point, it's very much like a desktop system still
21:27:50 <GyrosGeier> zumbi, not sure we can really integrate tools well
21:28:25 <zumbi> well, lets think about it, but there is happening lot of good stuff related to emulation
21:28:46 <zumbi> also, remark a "nice to have" eclipse plugin for our tools
21:28:49 <GyrosGeier> I'd rather have stuff implemented cleanly than resort to emulation
21:28:56 <zumbi> but, none of use use eclipse
21:29:22 <zumbi> It is just a remark, in case someone volunteers
21:29:25 <GyrosGeier> problem being that qemu either emulates a full system or needs a static qemu binary installed in the target system
21:29:45 <zumbi> GyrosGeier: yes, static approach
21:29:56 <GyrosGeier> neither of which is going to be really robust
21:30:33 <zumbi> i have used before qemu-static and it is somehow slow, but it works
21:30:54 <zumbi> there are also improvements to speed up the thing
21:31:18 <GyrosGeier> 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 <GyrosGeier> then we have leverage on package maintainers
21:31:34 <zumbi> And this is a shorcut to use with crush
21:32:06 <zumbi> GyrosGeier: long term yes, but we can not wait forever
21:32:30 <zumbi> we have a short-mid term tool which help us to resolve cleanly those bits
21:32:55 <zumbi> I'll have a look to it for a posible crush
21:32:56 <GyrosGeier> the alternative I can see is running qemu-armel from the dom0
21:33:14 <GyrosGeier> i.e. I could set up a small ARM system as a virtual server
21:33:54 <GyrosGeier> which would use virtio to talk to the host system
21:34:06 <GyrosGeier> but that's not cross compiling then
21:34:29 <zumbi> yeap
21:34:38 <zumbi> but you can link a cross compiler there
21:34:59 <GyrosGeier> not if it's a proper virtual box
21:35:02 <zumbi> having a native arch chroot inside
21:35:09 <suihkulokki> 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 <zumbi> yes, this is true
21:35:43 <GyrosGeier> does that properly work for vfork()+exec()?
21:35:55 <zumbi> GyrosGeier: even python
21:36:02 <suihkulokki> fork and exec yes, haven't tried vfork
21:36:03 <GyrosGeier> excellent
21:36:23 <GyrosGeier> the "script inbetween" is the hardest case of all
21:36:46 <zumbi> suihkulokki: i did not meant to make a release of it, but do you have any useful pointer?
21:37:18 <GyrosGeier> 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 <GyrosGeier> with some detection for 'if [ "$1" == "upgrade" ]' and the like
21:38:14 <zumbi> GyrosGeier: but it is the other way arround, you fetch from an insider chroot :)
21:38:58 <GyrosGeier> I want to go towards a debootstrap tool that gives you a fully installed root fs without emulating anything
21:39:21 <GyrosGeier> which fails if any package does something in a script which we don't recognize
21:39:24 <zumbi> that would be udeb based
21:39:39 <zumbi> without posibility to upgrade
21:39:44 <suihkulokki> the tool is called croco, and there is a demo here: http://afflict.kos.to/
21:39:52 <zumbi> no pre, post scripts
21:40:09 <zumbi> #link http://afflict.kos.to/
21:40:30 <suihkulokki> the bulk of the 245MB tar is fresh deboostrapped armel+x86 squeeze + zumbi's crosscompiler
21:41:14 <GyrosGeier> 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 <zumbi> GyrosGeier: ^ that's one of the reasons I want sysroot compilers
21:41:50 <GyrosGeier> sysroot compilers are tremenduously useful
21:42:31 <GyrosGeier> 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 <zumbi> yes, so, no more fighting with other groups
21:44:12 <zumbi> so, any action?
21:44:16 <suihkulokki> fwiw added zumbi, wookey_ and GyrosGeier to #emdebian masters
21:44:23 <GyrosGeier> whee
21:44:36 <suihkulokki> anyone else?
21:44:36 <zumbi> hey! thanks :)
21:44:47 <zumbi> suihkulokki: p2-mate
21:45:17 <GyrosGeier> I'd rather not force people to use chroots
21:45:47 <zumbi> why not?
21:45:49 <suihkulokki> p2-mate: register your nick and you'll get powers
21:45:58 <GyrosGeier> it is a good thing one can set up -dev-*-cross plus emdebian toolchain from packages and have a working environment
21:46:15 <ibr> Yes
21:46:16 <p2-mate> register my nick ?
21:46:23 <ibr> SLIND uses chroots
21:46:48 <ibr> It becomes "difficult" with time
21:47:09 <ibr> Although it has its advantages
21:47:43 <zumbi> I see more advantages nowadays than disadvantages
21:48:12 <suihkulokki> chroots have their inconviencies.. but they are damn lot more reliable IME
21:48:33 <GyrosGeier> they are more difficult to set up than "apt-get install"
21:48:50 <ibr> Well, setting up is a matter of debootstrapping
21:48:53 <zumbi> GyrosGeier: that can be automated
21:49:02 <ibr> But after that, you sometimes have to duplicate all the tools
21:49:03 <p2-mate> and imply bind mounts for home dir etc
21:49:12 <ibr> It's ok if it's emacs
21:49:13 <p2-mate> yeah, you really want git for example
21:49:26 <suihkulokki> apt-get install =)
21:49:39 <p2-mate> and preferably not emulated :)
21:50:15 <ibr> p2-mate: Yes, I was going to tell about ClearCase :) (although I'll understand if nobody cares :) )
21:50:36 <p2-mate> I think it's fine if we don't support ClearCase ...
21:50:41 <suihkulokki> :P
21:50:52 <GyrosGeier> @agreed we don't support clearcase
21:51:03 <ibr> No problem with me :)
21:51:04 <zumbi> #agreed we don't support clearcase
21:51:08 <GyrosGeier> heh
21:51:13 <suihkulokki> If you have money to buy clearcase, we can sell you a clearcase supporting solution =)
21:51:16 <GyrosGeier> zumbi, that was not a typo :)
21:51:31 <GyrosGeier> anyway
21:51:32 <zumbi> GyrosGeier: I thought it was
21:51:59 <ibr> -dev-*-cross has its advantages
21:52:12 <GyrosGeier> yes
21:52:21 <GyrosGeier> specifically, being autobuild safe
21:52:48 <GyrosGeier> I wouldn't want the scripting hell that is an auto-debootstrapping autobuider
21:52:51 <GyrosGeier> +l
21:53:08 <suihkulokki> not really different from pbuilder ?
21:53:21 <GyrosGeier> well
21:53:26 * zumbi just relizes what clearcase is... I understand sjr typo :)
21:54:02 <suihkulokki> IMHO -dev-*-cross are most useful if your target doesn't resemble your host
21:54:09 <GyrosGeier> also, dpkg-buildpackage -a... does not know where a chroot would live
21:54:33 <GyrosGeier> so it is a good thing to have reasonable default behaviour
21:54:55 <GyrosGeier> and ideally, cross compiling is as close as possible to native
21:55:21 <GyrosGeier> so if we have a bug report, we can simply tell people to install the cross compiler with apt-get and compile their package with -a
21:55:38 <GyrosGeier> no package maintainer will set up a chroot just to reproduce a bug
21:56:04 * zumbi thinks we should support both
21:56:17 <GyrosGeier> exactly
21:56:53 <GyrosGeier> the --sysroot approach is useful for software that is not packaged
21:56:54 <zumbi> #agreed to support -dev-*-cross schema and chroot one
21:57:19 <GyrosGeier> because it allows people to quickly point their compiler at a system installation without having to package stuff
21:57:43 <GyrosGeier> suihkulokki, does it make sense to package your tool?
21:57:53 <suihkulokki> GyrosGeier: once it matures a bit
21:58:00 <GyrosGeier> okay
21:58:05 <GyrosGeier> same for my tool :)
21:58:27 <GyrosGeier> currently all it does is say "I understand this script" or "I don't understand this"
21:58:29 <zumbi> #action emdebian folks to play with development frameworks
21:59:02 <zumbi> link any relevant bits to the wiki, please
21:59:09 <GyrosGeier> is anyone here with eclipse plugin experience?
21:59:24 <GyrosGeier> it'd be really nice to have a plugin once the cross toolchain hits Debian
22:00:10 <zumbi> GyrosGeier: i have some bits but no interest in eclipse
22:00:31 <zumbi> let's keep a task in the wiki in case someone steps up
22:00:34 <GyrosGeier> okay
22:00:46 <zumbi> move on
22:00:56 <zumbi> #topic Interesting packages for cross
22:01:18 <GyrosGeier> is that "stuff that should be in crush", or "cross toolchains"?
22:02:07 <zumbi> packages that emdebian cares about within Debian (to enable dpkg-buildpackage -a<arch>
22:02:23 <GyrosGeier> ah okay
22:02:30 * GyrosGeier points at his mail again
22:02:41 <GyrosGeier> basically, things that need to happen in dpkg
22:02:48 <zumbi> I have been doing some work on d-i, i'd like to have d-i to cross compile from udeb sources
22:02:55 <GyrosGeier> #info things that need to happen in dpkg
22:03:35 <GyrosGeier> #info dpkg-checkbuilddeps to support -a (either multiarch or -*-cross package suffices)
22:04:06 <zumbi> GyrosGeier: i mean, there are packages that can be cross built but they do not support it
22:04:17 <GyrosGeier> #info dpkg-checkbuilddeps to support :native qualifier
22:04:32 <GyrosGeier> #info dpkg-buildpackage to call dpkg-checkbuilddeps for cross builds
22:04:41 <GyrosGeier> those are the urgent ones
22:04:56 <GyrosGeier> I'd resolve those using the autobuilder
22:05:03 <zumbi> Also qt4-embedded is nice package for fb graphics
22:05:23 <zumbi> could even be used by the installer
22:05:31 <GyrosGeier> i.e. step one is to set up an autobuilder, and then sort out build failures
22:05:46 <zumbi> GyrosGeier: qt4-embedded is not packaged
22:05:55 <GyrosGeier> everything else is theoretical at best, and time-consuming at worst
22:06:13 <GyrosGeier> IIRC that is because it was merged back, or something
22:06:16 <zumbi> but you need packages to feed the builder... :)
22:06:19 <GyrosGeier> fabo knows more about that
22:06:23 <GyrosGeier> *pokes*
22:07:05 <GyrosGeier> yes, I'd set up our own source repo, and have the autobuilder work on that
22:07:12 <zumbi> pusling said it duplicates most qt4-x11 code and you need to rebuild packages again against qt4-embedded
22:07:17 <GyrosGeier> we start by copying a source package from Debian
22:07:23 <GyrosGeier> if it compiles, we win
22:07:27 <GyrosGeier> if it doesn't, we fix
22:07:34 <GyrosGeier> then we submit a patch
22:07:54 <zumbi> #action GyrosGeier set up our own source repo, and have the autobuilder work on that
22:07:59 <GyrosGeier> yay
22:08:34 <GyrosGeier> the idea is that the autobuilder has a list of packages to try
22:08:35 <zumbi> GyrosGeier: that is emdebian-tools with emdebian SVN
22:09:02 <GyrosGeier> that list is initially empty
22:09:15 <GyrosGeier> and we gradually add stuff as we need it
22:09:27 <zumbi> GyrosGeier: you should have a look to emdebian-tools scripts
22:09:42 <zumbi> that is done
22:09:45 <GyrosGeier> yes
22:09:52 <GyrosGeier> especially the patches db
22:09:58 <zumbi> also, iirc, grasp does that for slind.org + GIT repo
22:10:09 <GyrosGeier> I'd like to do the next step, and merge patches back into Debian
22:10:18 <GyrosGeier> so we need continuous integration tests
22:10:51 <GyrosGeier> i.e. new Debian upload of a package that once compiled from unpatched Debian source => autobuild is immediately attempted
22:10:58 <zumbi> #link http://wiki.debian.org/EmdebianCodeAudit
22:11:05 <GyrosGeier> failure to compile is a regression
22:11:33 <GyrosGeier> and specifically I'd like the code audit data to come from a db that is fed by the autobuilder
22:12:11 <zumbi> do you want to work on that?
22:12:18 <zumbi> or keep a task?
22:12:59 <GyrosGeier> I'd like to
22:13:10 <GyrosGeier> but I have no idea whether I'll manage to do that
22:13:26 <zumbi> #action GyrosGeier to improve EmdebianCodeAudit
22:13:29 <GyrosGeier> \o/
22:13:41 <GyrosGeier> I think I'll set up another VM as the autobuilder
22:13:50 <GyrosGeier> which runs in -snapshot mode
22:14:00 <zumbi> GyrosGeier: poke neil, he'll be happy to help (within multiarch context)
22:14:13 <GyrosGeier> so rebooting restores it to a sane state
22:14:38 <zumbi> ok.. move on
22:14:43 <GyrosGeier> yes
22:14:55 <zumbi> #topic uclibc support
22:15:02 <zumbi> this is not in the agenda
22:15:05 <GyrosGeier> finally something for me
22:15:06 <GyrosGeier> :)
22:15:11 <zumbi> but I want uclibc cross compilers
22:15:18 <GyrosGeier> uclibc 0.9.30.1 has been uploaded to Debian
22:15:22 <GyrosGeier> and ACCEPTED
22:15:28 <zumbi> blindvt: ^
22:15:39 <GyrosGeier> on Debian arches, there is only a single binary package
22:15:42 <GyrosGeier> uclibc-source
22:16:16 <GyrosGeier> dpkg supports "uclibc-linux-<cpu>" arches for some time now
22:16:52 <zumbi> gcc package has uclibc boostrap patches
22:17:21 <GyrosGeier> and I plan on having multiarch'd libc0.9.30.1, ... packages one these
22:17:25 <zumbi> so it is theoretically posible to start building cross compilers :)
22:17:53 <GyrosGeier> I'd treat these the same as Debian arches
22:18:06 <zumbi> GyrosGeier: why do we need libs for?
22:18:24 <GyrosGeier> the idea is to treat this as a full port
22:18:38 <zumbi> uhm.. ok
22:18:39 <GyrosGeier> although we probably build stuff on-demand only
22:18:50 <zumbi> as a partial architecture
22:18:53 <shifuimam> i'm getting errors on emdebian's aptitude release file
22:18:56 <GyrosGeier> so we can use multilib to pull in libraries linked against uclibc and uclibc++
22:19:05 <GyrosGeier> yes
22:19:15 <zumbi> shifuimam: yes, aptitude does not work with emdebian, use apt-get
22:19:22 <GyrosGeier> shifuimam, you need our archive key
22:19:33 <GyrosGeier> zumbi, works fine for me
22:19:34 <shifuimam> yah - apt-get update is erroring and saying "contrib/binary-armel/Packages in Meta-index file (malformed Release file?)"
22:19:56 <shifuimam> GyrosGeier: okay, what do i need to do to facilitate that?
22:19:58 <zumbi> no contrib, afaik
22:20:33 <GyrosGeier> shifuimam, that is a different problem from the one you have
22:20:44 <GyrosGeier> zumbi, that smells like a permissions problem
22:20:57 <zumbi> there is no contrib!
22:21:03 <zumbi> only main
22:21:17 <GyrosGeier> zumbi, yes, so why is it listed in the release file?
22:21:46 <shifuimam> this error shouldn't stop my other repositiories from updating, should it?
22:21:50 <zumbi> shifuimam: which sources.list line do you have?
22:21:59 <GyrosGeier> zumbi, anyway -- uclibc compiler bootstrap should be the same as eglibc compiler bootstrap
22:22:18 <GyrosGeier> i.e. build bootstrap packages, build real packages using small metapackages
22:22:55 <shifuimam> deb http://www.emdebian.org/grip/ lenny main contrib non-free
22:22:55 <shifuimam> deb http://ftp.us.debian.org/debian/ lenny main contrib non-free
22:22:55 <shifuimam> #deb http://ftp.us.debian.org/debian sid main
22:22:58 <shifuimam> sorry!
22:23:16 <shifuimam> i see it thinks there should bea  contrib in there
22:23:19 <zumbi> yes, i'll prepare packages for uclibc, but i also want to keep gcc package capabilities to cross build if posible and it already has uclibc support (at least on SVN)
22:24:03 <zumbi> #action zumbi to build uclibc cross compilers
22:24:44 <zumbi> ok -- I think we have covered all topics
22:25:30 <GyrosGeier> excellent
22:25:34 <zumbi> in 2h30, we need to improve timings for next meeting in 15 days (or after Xmas) to be scheduled in the wiki and announced in the mailing list
22:26:00 <GyrosGeier> note that uclibc-source binary package doesn't really know how to build binary packages yet
22:26:01 <zumbi> if someone wants to add something else
22:26:15 <GyrosGeier> I didn't expect it to go through NEW that fast :)
22:26:49 <zumbi> I'll have a look.. then complain to you, so you can complain to blindvt :)
22:27:00 <GyrosGeier> no, it's just a packaging issue
22:27:17 <GyrosGeier> so my prblem
22:27:20 <zumbi> well, yes, just being funny with the development chain
22:28:08 <zumbi> OK, nobody has anything to say
22:28:19 <zumbi> so we dismiss the meeting
22:28:26 <zumbi> thanks all for the attention
22:28:34 <zumbi> see you next time
22:28:39 <zumbi> #endmeeting