[01:35] <COrdel^> help
[01:35] <COrdel^> i crashed my box and it wont boot
[01:40] <infinity> COrdel^: You want #ubuntu
[05:45] <pitti> hrw: apport-collect deps> that's because there is no launchpadlib for python3, and barry wanted to kick out the python 2 modules from the default install
[05:45] <pitti> hrw: you don't need the launchpadlib part for reporting bugs, so I at least introduced that error message to explain which package you need
[05:47] <pitti> infinity, achiang: right, we don't quite need an explicit reference to valgrind -- just a kind of "shell" mode, i. e. you don't call apport-retrace on a .crash, but just on a binary
[06:36] <achiang> pitti: hm, i hacked up something over the weekend and got a proof of concept working
[06:37] <achiang> pitti: https://plus.google.com/u/0/118015160828356291747/posts/E4zxGafqojD
[06:38] <pitti> oh, nice!
[06:39] <pitti> achiang: btw, do you know if there are raring builds for the nexus7?
[06:39] <achiang> pitti: we are still blocked on nux. once we can test that, then people can start using raring
[06:40] <achiang> pitti: i'd like to get guidance from you on what i'm working on... right now i'm chasing out the SEGV's i introduced in valgrind, but in parallel, getting advice on direction for apport-valgrind would be good too
[06:41] <achiang> pitti: i think with a little extra work, we could potentially add automated valgrind support into our build infrastructure (if we wanted to)
[06:41] <achiang> and it would be super cool to hook it up to our daisie infrastructure too
[06:46] <pitti> achiang: there's certainly some small things, such as actually calling "which" instead of trying to figure it out yourself, not hardcoding DistroRelease (-> add_os_info()), and presumably some other code of apport-retrace can go as well, but we can clean that up later once it works
[06:47] <achiang> i actually just noticed that /usr/bin/valgrind messes with LD_LIBRARY_PATH, but somehow valgrind itself doesn't seem to really care anyway
[07:24] <hrw> pitti: I report bugs using web browser. apport-collect said that will do nothing wihtout launchpadlib
[07:24] <pitti> correct
[07:25] <hrw> pitti: so maybe (like xnox suggested) split it out of apport?
[07:25] <pitti> I don't really fancy that, TBH; at some point we'll get python3-launchpadlib, and everything will just work again
[07:26] <pitti> and splitting it out wouldn't buy that much, you need to install an extra package either way
[07:51] <dholbach> good morning
[07:52] <pitti> dholbach: guten Morgen
[07:52] <dholbach> hi pitti
[08:32] <jodh> @pilot in
[08:39]  * dholbach hugs jodh
[08:41]  * jodh hugs dholbach (1st time! :)
[08:41] <dholbach> :-D
[09:43] <bigon> https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1082325 << anybody responsible for lvm2 pkg?
[09:53] <xnox> not fun.
[10:31] <tjaalton> weird.. I need more debug output from a python module, and I see the added strings in the .pyc, but not when I run the actual app output that uses the module..
[10:58] <cjwatson> apw: Do you know if anyone might be able to sort out the fact that user-mode-linux still Build-Depends: linux-source-3.5.0?
[10:59] <apw> cjwatson, i seem to remember getting it as far a 3.5.0
[11:02] <dholbach> is the wiki broken for anyone else?
[11:02] <Laney> broken how?
[11:02] <Laney> loads fine
[11:03] <dholbach> it does not load for me. hum
[11:03] <apw> dholbach, w.u.c seems ok to me
[11:04] <dholbach> ah, it's fine again - seems to have been intermittent
[11:28] <mitya57> hey dholbach
[11:28] <mitya57> Wie geht es? :)
[11:30] <dholbach> hey mitya57 - хорошо :)
[11:30] <dholbach> how are you ? :)
[11:31] <mitya57> fine — after squashing some RC bugs in Debian I'm finally able to look at the sphinx patch
[11:31] <mitya57> can you please test if any external links work for you in Spanish HTML build?
[11:32] <dholbach> will do - give me a minute - just finishing some else before
[11:32] <mitya57> ok
[11:41] <dholbach> mitya57, with the sphinx from raring?
[11:42] <mitya57> dholbach, with any sphinx
[11:42] <mitya57> I still hope there's something wrong with my setup
[11:42] <dholbach> I might have the one with the broken patch installed, let me try the one in quantal
[11:42] <mitya57> yes, that would be better
[11:44] <mitya57> and also — did you ever get LOTS of "WARNING: Literal block expected; none found." warnings when trying to build html-es?
[11:44] <dholbach> yes
[11:44] <dholbach> mitya57, with quantal sphinx: http://paste.ubuntu.com/1388822/
[11:45] <dholbach> let me try raring
[11:45] <mitya57> can you comment out the footnote stuff?
[11:45] <dholbach> mitya57, where? :)
[11:45] <mitya57> nothing should change on raring — the only diff is python3.3 fix
[11:46] <dholbach> ah ok
[11:47] <mitya57> dholbach, http://paste.ubuntu.com/1388824/
[11:48] <mitya57> and then open for example python-packaging.html and check if "Python policy" link works
[11:52] <mitya57> ah, I know what's the reason for those warning
[11:52] <mitya57> *warnings
[11:52] <mitya57> spanish translators sometimes replace ``text`` with «text» :(
[11:53] <mitya57> like in https://translations.launchpad.net/ubuntu-packaging-guide/trunk/+pots/ubuntu-packaging-guide/es/50/+translate
[11:53] <mitya57> I will now fix some
[12:00] <mitya57> One of their translators (Jose Luis Tirado) does that *every* time :-(
[12:08] <mitya57> fixed translations up to 120
[12:08] <mitya57> dholbach, so what?
[12:09] <dholbach> sorry, got a phone call
[12:10] <dholbach> mitya57, no, the python-policy link is broken for me too
[12:10] <dholbach> mitya57, are you going to commit the fix for es.po?
[12:10] <dholbach> I'll mail Jose Luis Tirado then
[12:10] <mitya57> dholbach, so that's not a patch side-effect. thanks for testing?
[12:10] <mitya57> s/?/!/
[12:10] <dholbach> thanks a lot for your help!
[12:11] <mitya57> I'm editing it through launchpad
[12:12] <dholbach> ah ok
[12:12] <dholbach> great
[12:13] <mitya57> so I'll (a) file a bug upstream about links not working
[12:13] <mitya57> (b) release the new sphinx with the patch
[12:13] <mitya57> (it's already in debian svn)
[12:14] <dholbach> thanks a bunch!
[12:17] <mitya57> fixing translations is also a good way to learn some Spanish =)
[12:18] <dholbach> I like your positive attitude :)
[12:21] <mitya57> ... and find some syntax errors in source files
[12:23] <dholbach> mitya57, mailed Jose Luis Tirado
[12:23] <mitya57> thanks!
[12:42] <xnox> Please mark as merged, uploaded into raring. https://code.launchpad.net/~kampka/ubuntu/quantal/zabbix/upstart-support/+merge/124660
[12:43] <xnox> pitti: ^^^ =)
[12:59] <pitti> xnox: oui, Monsieur; fini
[13:00] <xnox> pitti: Merci, Monsieur.
[13:09] <jodh> @pilot out
[14:07] <seb128> ev, hey, is https://bugs.launchpad.net/ubuntu/+source/activity-log-manager/+bug/1082932 an issue you know about?
[14:07] <seb128> ups
[14:07] <seb128> ev, https://bugs.launchpad.net/ubuntu/+source/activity-log-manager/+bug/1082932
[14:08] <seb128> "Unable to keep "Send errors to Canonical" context-box marked"
[14:08] <ev> seb128: it's a duplicate of bug 993056, which is now fixed
[14:08] <ev> I've marked it as such
[14:08] <seb128> ev, it's still happening in raring
[14:08] <ev> thanks for finding that
[14:08] <ev> oh?
[14:08] <ev> hmm
[14:08]  * ev digs
[14:09] <seb128> ev, sorry, ignore that
[14:09] <seb128> ev, user problem here :p
[14:09] <ev> :)
[14:10] <seb128> ev, thanks ;-)
[14:10] <ev> sure thing
[14:10] <cjwatson> seb128: Your pyxdg merge had the effect of causing menu and menu-xdg to want to be promoted to main - was that deliberate?
[14:11] <cjwatson> It's made raring_probs.html explode
[14:11]  * xnox remembers something about pyxdg & python3
[14:11] <cjwatson> Unrelatd
[14:11] <cjwatson> +e
[14:11] <seb128> cjwatson, ups, no, I overlooked that those were in universe, let me fix
[14:11] <cjwatson> seb128: Thanks
[14:13] <xnox> ah, debian has python3 now, so we don't carry that delta. awesome.
[14:16] <seb128> cjwatson, updated version uploaded, sorry for the issue and thanks for the ping ;-)
[14:19] <cjwatson> Ta
[15:24] <darkbasic> what about kernel.ubuntu.com? why is it down?
[15:24] <cjwatson> Machine death - sysadmins are investigating
[15:24] <darkbasic> cjwatson: thanks
[15:38] <seb128> cjwatson, http://people.canonical.com/~ubuntu-archive/testing/raring_probs.html is happy again ;-)
[15:44] <cjwatson> seb128: It is indeed, thanks
[15:44] <seb128> yw ;-)
[15:48] <darkbasic> cjwatson: kernel.ubuntu.com is up again :)
[15:50] <cjwatson> No need to tell me, but thanks ;-)
[15:51] <pitti> cjwatson: I'd like to upload pygobject 3.7.2 to -proposed, but would like to hold it there for a bit until all revdeps were tested; can we block it in britney for a bit?
[15:51] <pitti> cjwatson: I tested it with software-center, apport, etc., but I'd rather also wait for ubiquity and the like
[15:51] <pitti> cjwatson: is that blocking something I can do, or only you?
[15:51] <cjwatson> You're not in ~ubuntu-release any more, so you can't do it
[15:52] <cjwatson> pitti: Done now
[15:52] <pitti> cjwatson: cheers
[16:12] <jelmer> slangasek: nice to see upstart working on sid again (-:
[16:12] <jelmer> slangasek: I had to help it a little bit (by killing startpar on boot) to get it working.
[16:28] <marga> seb128, just wrote a long reply to you... It seems I'm in verbose mode today
[16:28] <seb128> marga, hey
[16:28] <marga> seb128, just call me Marga, please... I don't like my full name that much.
[16:28] <seb128> marga, noted, sorry about that ;-)
[16:29] <slangasek> jelmer: hmm, interesting.  do you know what startpar was waiting for?
[16:30] <jelmer> slangasek: ps suggested it wasn't waiting for any child processes, at least. I haven't dug further, but can do so on next boot.
[16:30] <slangasek> yeah, it probably wasn't waiting for child processes but instead got confused about what jobs it could/couldn't start vs. jobs it was waiting for upstart to start for it
[16:31] <seb128> marga, ok, just read your reply, thanks for explaining the config.vapi thing, that explains why I was having no issue on raring ;-) Your first solution seems good to me, I will sponsor the precise and quantal debdiff you added to the bug, thanks for the work!
[16:31] <marga> seb128, yay, thanks for the sponsoring :)
[16:31] <seb128> then we need the SRU team to review some of the queue...
[16:31] <seb128> which is another story
[16:31]  * seb128 looks at slangasek
[16:31] <marga> Yes, I know.
[16:31] <seb128> slangasek, hey, had a good thanksgiving? ;-)
[16:32] <slangasek> seb128: hi ;)
[16:32] <seb128> slangasek, I've been told that there is nothing like reviewing some SRUs to digest turkey, just saying :p
[16:32]  * marga wonders... What's with the nick...
[16:33] <seb128> marga, like vorlon betteR?
[16:33]  * marga nods
[16:33] <seb128> ;-)
[16:33] <jelmer> slangasek: oh, and I got an error from initctl saying DEVNAME was not a valid event (?), perhaps that's related
[16:34] <jelmer> slangasek: possibly coming from cryptdisks-early.conf ?
[16:34] <slangasek> jelmer: ah, could be
[16:36] <slangasek> jelmer: I haven't tested this with cryptsetup yet in unstable; I know that there are some cryptsetup upstart jobs in the Debian package and they may be "misaligned" wrt the init scripts in some way
[16:48] <marga> seb128, I've done a number of patches already and I'll probably do more during 2013.  Is the debdiff the preferred way? Should I be doing them differently?
[16:48] <ScottK> Some people prefer debdiff.  Some people prefer bzr branches.
[16:48] <marga> Ouch
[16:48] <Laney> people should be able to work with either
[16:49] <seb128> marga, welcome to Ubuntu :p
[16:49] <marga> Yes, but I want to do what's more comfortable for the sponsors.
[16:49] <seb128> marga, I think debdiff is a safe bet, especially for SRUs
[16:50] <marga> I guess it would be more comfortable to just have upload rights, but right now it's a complicated copyright issue, so I'd rather not have them for my @google self.
[16:51] <seb128> marga, I would say that debdiff are easy enough to deal with everybody that they are the best option
[16:51] <seb128> marga, you will have people who prefer a merge request on the Vcs listed in the control file if there is one, but even often those Vcs are only for the current serie and not branched for stable ... so we default to debdiffs for stable update
[16:52] <marga> Right
[16:52] <marga> I guess I should get myself more comfortable with bzr for upstream patches, like the ones I sent to this activity-log-manager project today.
[16:52]  * cjwatson tries to work out how copyright is different for submitted patches vs. direct uploads
[16:53] <marga> cjwatson, no, I don't understand it either.
[16:53] <marga> But they told me that if I uploaded stuff, I'd lose copyright for my @debian self.
[16:53] <marga> So, I'm still trying to figure it out.
[16:57] <seb128> marga, the merge requests, it's summarize on http://developer.ubuntu.com/packaging/html/udd-sponsorship.html ... but it's basically "bzr branch lp:<project>; cd project; HACK; bzr commit; bzr push lp:~id/project/branch-name; bzr lp-open; click on the "propose to merge" and file the description etc"
[16:58]  * marga stores this in a file.
[16:59] <seb128> marga, oh, bonus point if you -- fixes lp:NNN on the commit to link the bug ticket to the commit
[16:59]  * marga nods
[16:59] <marga> Thanks
[17:00] <seb128> yw ;-)
[17:01] <xnox> jelmer: slangasek: yeah the upstart scripts in cryptsetup package in Debian need fixing. Currently they do not shutdown the system in a correct way.
[17:06] <cjwatson> slangasek: openssh with upstart support → experimental now
[17:07] <slangasek> cjwatson: yay :)
[17:07] <cjwatson> and syncable to Ubuntu once gina catches up with it, as a bonus
[17:08] <cjwatson> Only 4.5 years or so since we diverged
[17:17] <seb128> marga, ignore the reject mail from quantal if you get one, I uploaded twice the quantal version by error and rejected one of the two from the queue
[17:18] <marga> hm
[17:18] <marga> I haven't received an processing mails up to now.
[17:18] <marga> I wonder if they have been filtered into some folder without me realizing.
[17:21] <seb128> marga, I'm not sure if you are supposed to get one or not in fact, I'm never on the sponsored side... it might be just whoever sign the upload which gets the emails
[17:21] <marga> Yes, I think it's that, I just reviewed and couldn't find any mails of package processing for the debdiffs I've done up to now.
[17:22] <seb128> ok ;-)
[17:30] <ximion> seb128: hi! do you know if it will be possible to use systemd-logind APIs in Ubuntu?
[17:31] <seb128> ximion, hey, I don't think it is at the moment
[17:31] <ximion> or does every program which wants to make use of similar features have to use some upstart-API?
[17:32] <seb128> slangasek's team has plans to look at what we can do on that front at some point I think, maybe check with slangasek or jodh
[17:32] <ximion> I know the systemd stuff is controversial in Ubuntu, but this might lead to issues later, since many projects require systemd-logind or ConsoleKit, and I don't know Ubuntu's plans for both tools
[17:33] <seb128> ximion, what api do you need from logind?
[17:34] <ximion> seb128: usually interfacing with the session and e.g. controlling shutdowns etc.
[17:35] <seb128> ximion, the session is at the gnome-session level no?
[17:35] <ximion> we use it upstream in the PackageKit project for various things - I also use systemd here, so for me this is no issue, but it would be cool to make some of the features available to Ubuntu users too
[17:35] <seb128> ximion, well, your call as an upstream I guess
[17:36] <seb128> but I'm sure users would appreciate if you don't tide your software to an init systemd ;-)
[17:36] <ximion> seb128: sd-logind can take control of the session and manage it instead, so it can replace the existing desktop-specific managers
[17:36] <ximion> seb128: people can use ConsoleKit instead :) - and that option won't vanish soon
[17:37] <seb128> right
[17:37] <seb128> ximion, well, anyway it would be useful if you made a list of the logind api/features you need and maybe send an email on ubuntu-devel@lists.u.c about it
[17:38] <ximion> but knowing where https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions leads us might be nice :)
[17:38] <seb128> ximion, we for sure want to figure at some point how we deal with those needs in Ubuntu, which might be either by integrating logind or by implementing compatible dbus interface somewhere in our stack
[17:39] <ximion> seb128: I expected something like that, which would work, I guess. Last time I talked to Lennart about this, he said that this won't be possible, because logind relies on interfaces provided by systemd
[17:40] <ximion> for now, disabling that set of features in Ubuntu makes sense (I already do that for non-Linux ports of Debian, and so far everyone is happy)
[17:41] <seb128> ximion, well, maybe we can "make it fit" with some hacking
[17:41] <seb128> or maybe not and we need to figure how to reimplement those
[17:41] <seb128> it would still help to know what list of APIs you need, what we lack is a list of "useful things we should provide"
[17:42] <seb128> systemd does lot of things we don't want/need everything that is there
[17:42] <ogra-cb> we could always stay with consolekit and patch it to hell over time
[17:44] <seb128> ogra-cb, well, the issue is that code writers will want to use the systemd apis for some stuff, like inhibitions of logout,suspend,etc
[17:45] <seb128> ogra-cb, so ideally we want nice apis (and if possible compatible ones) for that as well
[17:45] <seb128> ogra-cb, ck has issues and I'm not sure it makes sense to add those to ck
[17:46] <seb128> graa
[17:46] <ogra-cb> oh, indeed
[17:46] <seb128> hate powerpc
[17:46] <ximion> seb128: what is the stuff you don't like about systemd?
[17:46]  * ximion wants to get rid of CK as soon as possible
[17:46] <seb128> builds start in almost 10 hours
[17:46] <seb128> I guess my uploads will stay in raring-proposed for today
[17:48] <micahg> seb128: sulfur went missing
[17:48] <seb128> ximion, I've personally nothing against systemd, but I've nothing again upstart either ... we have an init system that works fine, is well integrated in our distro, our init scripts are made for it, our documentation is for it, our users wrote scripts for it ... I just don't feel like a big motivation to go through the work of breaking and replacing all that for not gaining anything
[17:48] <seb128> ximion, e.g we have better things to do that go through an init system replacement
[17:49] <cjwatson> seb128: We've been waiting several days for a UK DCE to get to it; I'm assured it'll happen tomorrow
[17:49] <seb128> micahg, yeah, that's the issue with powerpc, one builder goes missing and your are screwed for the next half a day :-(
[17:49] <seb128> cjwatson, that's good news, thanks
[17:51] <ximion> seb128: sounds reasonable, for now - since Raring will still contain CK (will it?) I think waiting and watching is the best thing to do at time
[17:52] <seb128> ximion, yes, we don't plan to drop CK (yet) ... still having an email with the apis you need as a software writer would be useful ;-)
[17:53] <ximion> seb128: yes, but adding three ways to a software to implement somathing, e.g. CK, sd-logind and $NEW_API won't be accepted by the other developers ;-)
[17:54] <ximion> knowing what is actually required is certainly a good thing, but the answer will almost certainly be: removing CK in the most cases
[17:56] <seb128> ximion, well, what I'm saying is that having the sd-logind APIs you need listed would give use a list of APIs we should provide
[17:57] <seb128> ximion, I don't suggest we come with $NEW_API, just that we want to provide those same API one way or another on Ubuntu (using logind, reimplementing the server side, ..)
[17:57] <ximion> seb128: I'll do that then :)
[17:57] <seb128> ximion, thanks
[17:58] <ximion> I don't know if you want offline-update support in Ubuntu, as this would require much more work (for little gain at time, without btrfs), so we could skip that, maybe
[17:59] <seb128> yeah, I don't think we want that atm
[17:59] <xnox> ximion: but we do have lvm & btrfs snapshots available. What do you mean by 'offline-update'?
[17:59] <xnox> also we already have apt-btrfsnapshot integration.
[17:59] <seb128> xnox, redhat added support for "download the packages and apply the updates at shutdown"
[17:59] <ximion> (offline-update: rebooting into a special update-stage, create snapshot, upgrading the system and reboot again. (using Plymouth to show progress))
[18:00] <xnox> ximion: seb128: I see. I did see something like that in new plymouth.
[18:00] <xnox> stgraber: ^
[18:00]  * ximion is away for now, back in 1h
[18:00] <seb128> xnox, what ximion wrote
[18:00] <xnox> seb128: ximion: we possably want that for dist-upgrade though.
[18:00] <SpamapS> hrm.. having a hell of a time trying to install 12.10 on a mac from a USB key. Has anyone tested that?
[18:00] <xnox> & play the slideshow of the new release in the mean time =)
[18:01] <seb128> xnox, yeah, I'm sure how they technically did it is how we want to do it though
[18:01] <xnox> seb128: ack.
[18:02] <Laney> SpamapS: I ended up burning 12.04 to a CD and installing from that then dist-upgrading (had no DVDs available) ...
[18:02]  * Laney coughs
[18:04] <SpamapS> Laney: yeah, thats the situation I'm in too
[18:04] <SpamapS> I actually know, for a fact, there is a 10 pack of DVDs with only one used.. somewhere in this house
[18:55] <ximion> xnox, seb128: the offline-upgrade feature uses lots of systemd-specific stuff, like generators http://www.freedesktop.org/wiki/Software/systemd/Generators
[18:56] <ximion> but it is working fine here
[18:56] <ximion> this stuff is useful for distro upgradees, because for normal updates it doesn't make that much sense (I was confused too when the idea came up, but implementing it was actually very good - unfortunately, the media got it wrong :P)
[18:57] <ximion> I only use the systemd stuff, so I don't have any idea how hard it would be to recreate something similar
[20:01] <bitshuffler> Hello. I have a hard time trying to get conditionals working within a rules file. I would like to set $ARCH to x86_64 when building for 64 bit: http://pastebin.com/811cfvfV However I always end up in the 32 bit / else branch but "echo `dpkg-architecture -qDEB_HOST_ARCH`" returns amd64. Any ideas what I am missing?
[20:05] <jtaylor> bitshuffler: isn't there a shell missing? $(shell dpkg-...)
[20:06] <jtaylor> bitshuffler: also not that HOST_ARCH only covers linux
[20:06] <jtaylor> bitshuffler: on kfreebsd it returns something else, you may want to use DEB_HOST_ARCH_CPU
[20:08] <jtaylor> bitshuffler: and drop the quotes on amd64
[20:13] <bitshuffler> jtaylor: you are right, adding shell fixed it. Also thanks a lot for the pointer re DEB_HOST_ARCH_CPU :)
[20:15] <micahg> bitshuffler: DEB_BUILD_GNU_CPU is actually want you want if you want x86_64
[20:18] <micahg> ok, I'm confused now, why is DEB_BUILD_* and DEB_HOST_* the same in my 32 bit chroot on my 64 bit system...
[20:19] <slangasek> ?
[20:19] <micahg> or did I confuse the purpose of those again
[20:20] <dupondje> nobody hits https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1073649 ? :s
[20:20] <bitshuffler> micahg: but is that reliable, e.g. here it returns i686. What happens if I build on some very old computer that is i386 or i586?
[20:20] <micahg> bitshuffler: you just asked for what it would show on 64 bit systems :)
[20:20] <jtaylor> bitshuffler: I think you should HOST_ARCH_* because of that
[20:20] <slangasek> micahg: it's a 32-bit install; why would you expect DEB_* to be different?
[20:21] <slangasek> they only differ when cross-compiling
[20:21] <bitshuffler> micahg: heh, true, thanks :)
[20:21] <micahg> slangasek: ah, that's the bit I keep confusing :)
[20:21] <micahg> bitshuffler: so, you want DEB_HOST_GNU_CPU :)
[20:21] <jtaylor> that will also give i686
[20:21] <micahg> jtaylor: yeah, I meant instead of DEB_BUILD_GNU_CPU
[20:22] <bitshuffler> jtaylor: sounds like what I want :) What is * in that case? Or do you know where I can find a list of all vars and their meaning that are available since that is what I'm having a hard time with?
[20:22] <slangasek> always use DEB_HOST_* when querying details about the system that will /host/ the code you're building
[20:23]  * micahg shouldn't have skipped the glossary in the man page :-/
[20:24] <micahg> now it finally makes sense :)
[20:24] <jtaylor> and ARCH_* is always going to match the distribution architecture
[20:24] <jtaylor> (I think)
[20:25] <slangasek> well, all information dpkg-architecture spits out is relative to a distribution architecture
[20:26] <jtaylor> slangasek: even when you have a i486 cpu BUILD_GNU_CP U will output i686?
[20:27] <bitshuffler> But how can I see what variables are available on which I can rely (as in do not change between any release, which is why I don't want to rely on 'env' output for $distro I'm building for)?
[20:27] <slangasek> jtaylor: see for yourself: $ dpkg-architecture -ai386
[20:28] <slangasek> (and if you have an i486 cpu, you're not running Ubuntu)
[20:28] <jtaylor> for what do you need the GNU_* things in practice?
[20:29] <slangasek> jtaylor: they're what you want to pass as arguments to GNU autotools
[20:29] <slangasek> well, _GNU_SYSTEM anyway
[20:29] <slangasek> er, sorry, _GNU_TYPE
[20:29] <slangasek> the others, I don't think I use in practice, but someone might
[20:30] <jtaylor> doesn'T gnu support building for 386?
[20:30] <slangasek> yes, but Ubuntu doesn't
[20:31] <slangasek> dpkg-architecture isn't a tool for targeting arbitrary GNU targets; it's a tool for targeting supported architectures
[20:31] <hallyn> zul: smoser: have either of you used hugeadm at all to manage hugepages?
[20:31] <zul> hallyn: havent
[20:32] <hallyn> For integrating hugepages into qemu-kvm/libvirt, i'm trying to figure out whether to go with hugeadm or do it using sysctl and mount
[20:35] <bitshuffler> hm, since those packages are just for ubuntu and perhaps debian I think I rely on querying dpkg-architecture. Thanks a lot for your help once again :)
[20:35] <jtaylor> apropo hugetables, someone know details why transparent anon hugetables are disabled in ubuntu?
[20:41] <hallyn> jtaylor: #ubuntu-kernel would be a good place to ask
[20:41] <hallyn> jtaylor: (AFAICT they wouldn't help with kvm, though, unfortunately for me)
[20:53] <hallyn> https://launchpadlibrarian.net/124068316/buildlog_ubuntu-raring-powerpc.lxc_0.8.0%7Erc1-4ubuntu44_FAILEDTOBUILD.txt.gz   powerpc builder having issues?
[20:56] <jtaylor> seems so, https://launchpadlibrarian.net/124085710/buildlog_ubuntu-raring-powerpc.pandas_0.9.1-1ubuntu2_FAILEDTOBUILD.txt.gz
[21:16] <infinity> hallyn, jtaylor: That's not the "builder" having issues, just some bits out of sync.
[21:17]  * infinity investigates.
[21:18] <cjwatson> infinity: chdist is happy with both
[21:18] <cjwatson> infinity: Mind if I just give them back?  Pretty sure they'll be better next time
[21:19] <infinity> cjwatson: Go to town.
[21:19] <infinity> cjwatson: I was booting a PPC machine here to give it a real-world whirl.
[21:20] <infinity> (and to update chroots, we're about due)
[21:20] <cjwatson> Those in ~ubuntu-archive may find it helpful that there are pre-updated chdist environments in ubuntu-archive@lillypilly
[21:20] <cjwatson> chdist apt-get raring-proposed-powerpc build-dep lxc
[21:22] <ScottK> fontconfig was uninstallable on powerpc until just a few minutes ago.
[21:23] <infinity> ScottK: That would do it.
[21:32] <infinity> doko: I'm killing your gcj-4.8/powerpc build for now, while we wait on sulfur's recovery.  Don't be alarmed if it appears to ICE.