[00:01] <slangasek> stgraber: so is that latter sysvinit change cleaning up after previous incomplete sysvinit migration code?
[00:01] <slangasek> (I suppose that's why it might be in sysvinit instead of lxc?)
[00:02] <slangasek> stgraber: also, can you please put a version guard on that upgrade code?
[00:54] <stgraber> slangasek: yeah, and lxc doesn't have any package inside the containers, so we don't have a way of fixing them other than SRUing initscripts for that. In theory the check I uploaded shouldn't even match a setup that's not broken but I should have indeed added a version guard on top of that if someome actually wants the "broken" setup.
[01:00] <slangasek> stgraber: <nod> the risk of a false positive is small, but I'm paranoid about upgrade code not having version checks; so please fix that in quantal and in the SRU :)
=== apachelogger___ is now known as apachelogger
[02:01] <stgraber> slangasek: please reject the SRU then, I'll prepare an updated postinst
[02:23] <slangasek> stgraber: rejected, thanks
[02:25] <stgraber> slangasek: re-uploaded to -proposed, testing the one to quantal to make sure I didn't mess up anything in the version check
=== mthaddon` is now known as mthaddon
[03:36] <psusi> so I'm trying to figure out how to bootstrap an x32 system by practicing building i386 packages from amd64... if I run debuild -ai386, it seems to build an i386 binary package ( though dh_strip tries to run i686-linux-strip instead of strip, so I had to make a symlink ), but I can't figure out how to get debuild to pass gcc -march=i386
[03:38] <slangasek> psusi: so debuild -ai386 will set DEB_HOST_ARCH and friends; packages that know about cross-building will take this as a hint to *do* cross-building, which means they'll look for a cross-compiler
[03:38] <slangasek> psusi: so they will look for i686-linux-gnu-gcc - provide this and have it do the right thing
[03:38] <psusi> slangasek, right... I guess that's why dh_strip was trying to run i686-linux-strip instead of just strip....
[03:39] <psusi> but the actual build didn't complain about not being able to find i686-linux-gnu-gcc
[03:39] <psusi> it seemed to run gcc and build just fine... just barfed at dh_strip, which I got around with a symlink
[03:39] <slangasek> ideally i686-linux-gnu-gcc could be implemented by gcc itself just knowing what to do; but at a push, you can make it a short wrapper script that calls exec gcc -m32 $@
[03:39] <slangasek> right, then your test package seems to not be cross-build-friendly
[03:39] <slangasek> (which package?)
[03:40] <psusi> but... while it built an i386 binary deb, the actual binaries are still amd64 since it isn't telling gcc the right -m
[03:40] <scientes> slangasek, yes i tested using multi-arch for that, it works great!
[03:40] <slangasek> depending on the package, it may be using gcc as a fallback
[03:40] <infinity> psusi: Yeah, it's obviously hardcoding the compiler, which is not cross-friendly.
[03:40] <psusi> hrm.... that could be
[03:40] <slangasek> and maybe creating i686-linux-gnu-gcc will be enough to make it happy
[03:40] <scientes> just using a -m32/-m64 wrapper for -afoo that can be satified by multilib
[03:40] <slangasek> again, which package?
[03:40] <infinity> Or, I suppose it could be cross-friendly but falling back in the absense of triplet-cc, yeah.
[03:41] <scientes> slangasek, you need symlinks for binutils, and gcc/cpp/etc, and then it works
[03:41] <slangasek> yes
[03:41] <psusi> so... you are saying to get it to work, I have to write a wrapper gcc script to run gcc -m32?  can't get dh to be happy just running gcc and adding -m32 to the CFLAGS?
[03:41] <scientes> but yeah i had that working great
[03:41] <scientes> paulliu, yep, i'll go find what i was using
[03:42] <scientes> paulliu, slacker_nl   this works: http://paste.ubuntu.com/1102847/
[03:43] <scientes> i called it "gcc-32", and you could easily make a similar gcc-64
[03:43] <psusi> it seems kind of silly to have to invoke all of the cross compiling machinery when the native gcc supports the "cross" arch, you just need to add a flag
[03:43] <psusi> but you're saying that's just how you have to do it?
[03:43] <scientes> psusi, the "c99" "c89" commands work exactly the same
[03:43] <scientes> of course this is called by the full qualified name
[03:44] <scientes> i got blocked on trying to wrap my head around how the packaging for gcc-defaults-cross might work
[03:45] <scientes> i think it should be packaged like this IMHO
[03:45] <psusi> so if you have to pretend you are doing a full cross compile... why doesn't our gcc package come with the cross compiler wrapper script to add -m32?
[03:46] <scientes> psusi, it could either be part of (gcc|g++|gobjc)-multilib packages, or a seperate package
[03:48] <infinity> psusi: You could certainly file a bug to that effect.
[03:58] <psusi> how do you smack bzr bd into passing options to debuild?  it pukes on -ai386
[03:58] <infinity> -- perhaps?
[03:58] <infinity> (I don't use it, just a wild guess)
[03:59] <ScottK> psusi: -- $OPTIONS
[03:59] <psusi> good guess... I was thinking that but the man page doesn't show it ;)
[03:59] <ScottK> Yes.  I've written bugs about it.
[03:59] <ScottK> It's not a guess.  I knew because I couldn't find it either and had to ask.
[04:00] <ScottK> "inconsitent interface" is on my reasons to avoid UDD kinds of things.
[04:00] <ScottK> Who'd have thought -S -- -sa -us -uc was a good plan?
[04:02] <psusi> hrm... when I add -ai386, it says /usr/include/linux/errno.h can't find asm/errno.h
[04:04] <scientes> psusi, install libc6-dev:i386 ?
[04:04] <psusi> ohh... I guess gcc expects a separate 32bit headers directory
[04:05] <scientes> psusi, or rather apt-get build-dep -ai386 <package>
[04:12] <slangasek> ScottK: it's equally valid to call it as -- -S -sa -us -uc, if that makes you happier ;P
[04:13] <psusi> hrm.. so why does apt-get want to remove the native amd64 -dev packages to install the i386 ones?