[00:00] <udsbotu> uds-gb-g: This session has ended.
[00:41] <Effenberg0x0> Oh I got one
[00:54] <Effenberg0x0> Audio was cut
[00:54] <udsbotu> uds-gb-g: 5 minutes left in this session!
[00:55] <udsbotu> uds-gb-g: 4 minutes left in this session!
[00:56] <udsbotu> uds-gb-g: 3 minutes left in this session!
[00:57] <udsbotu> uds-gb-g: 2 minutes left in this session!
[00:58] <udsbotu> uds-gb-g: 1 minute left in this session!
[00:59] <udsbotu> uds-gb-g: This session has ended.
[16:03] <arosales> hello
[16:49] <udsbotu> uds-gb-g: 5 minutes left in this session!
[16:50] <udsbotu> uds-gb-g: 4 minutes left in this session!
[16:51] <udsbotu> uds-gb-g: 3 minutes left in this session!
[16:52] <udsbotu> uds-gb-g: 2 minutes left in this session!
[16:53] <udsbotu> uds-gb-g: 1 minute left in this session!
[16:54] <udsbotu> uds-gb-g: This session has ended.
[17:18] <xnox> My friend adds grub PC sound - it's Super Mario theme tune.
[17:18] <xnox> it was crytical for me to bring it back on reinstall
[17:19] <xnox> (grub supports playing sounds on boot)
[17:20] <NMinker> I personally use burg
[17:22] <xnox> NMinker: is that UEFI or BIOS?
[17:22] <xnox> (mbr)
[17:22] <xnox> NMinker: looks nice and better than rEFIt
[17:23] <xnox> I wonder if we can package and install it from the mac+amd64 image
[17:24] <mpt> When would the debconf error appear?
[17:25] <NMinker> https://launchpad.net/~n-muench/+archive/burg/+packages copied from natty because of GCC build issues
[17:27] <mpt> Is the point of using debconf just that it can output either to console or GUI?
[17:27] <NMinker> I didn't develop burg, I just put it in a repo
[17:28] <cjwatson> the point is that it's the standard interface for emitting errors from package maintainer scripts, and yes that it has multiple frontends
[17:28] <mpt> And update-grub falls into the category of "package maintainer scripts"?
[17:28] <cjwatson> NMinker: right, I'm just giving you my advice as the grub2 maintainer that burg is abandoned :-)
[17:29] <NMinker> I know
[17:29] <cjwatson> mpt: Not directly, but all the cases we're concerned with here are cases where it is called by package maintainer scripts
[17:29] <mpt> ok
[17:29] <NMinker> I don't maintain it, I put in my repo for convience
[17:29] <mpt> oh, like installing an updated kernel
[17:29] <cjwatson> Right
[17:29] <mpt> The current plan for the error tracker is to start treating debconf errors in general as problems to report, but that wouldn't be so useful for personally-created syntax errors
[17:30] <mpt> I'd enjoy designing an interface for graphical customization of the most common things that people currently manually edit the grub config for.
[17:31] <cjwatson> I think that would be great
[17:32] <cjwatson> There have been a few efforts at this kind of thing, e.g. startupmanager, but they've been sort of incomplete and problematic
[17:32] <cjwatson> Brutal scope pruning might help
[17:33] <cjwatson> The fact that these are personally-created is the main reason I think using debconf would be OK
[17:33] <mpt> Just to invoke Postel's Law briefly, might it make sense to silently treat Unicode quotes as if they were Ascii ones? :-)
[17:33] <cjwatson> But perhaps we should work out a way to whitelist certain debconf questions in the error tracker
[17:33] <cjwatson> Shell can't, but we could auto-fix the file
[17:33] <cjwatson> And I think we probably should, much though it obscurely offends me :-)
[17:35] <cjwatson> But only in an "offended by the brokenness of the world" kind of way
[17:35] <mpt> Hey, at least you don't work for a Web browser or mail client vendor
[17:36]  * xnox =)
[17:40] <udsbotu> uds-gb-g: 5 minutes left in this session!
[17:41] <udsbotu> uds-gb-g: 4 minutes left in this session!
[17:42] <udsbotu> uds-gb-g: 3 minutes left in this session!
[17:42] <mpt> yes please
[17:42] <mpt> dependent on bdmurray's for identifying the common cases
[17:43] <udsbotu> uds-gb-g: 2 minutes left in this session!
[17:44] <udsbotu> uds-gb-g: 1 minute left in this session!
[17:45] <udsbotu> uds-gb-g: This session has ended.
[18:10] <jtaylor> what kind of a jit does mono use?
[18:11] <jtaylor> just compiles function which are often used or a tracing jit like e.g. pypy?
[18:12] <RAOF> I don't think so.
[18:14] <jtaylor> that would involve changing all arch all packages to arch any
[18:18] <jtaylor> so the native and the IL code will both be installed?
[18:25] <directhex> gah, this stream is choppy
[18:28] <ajmitch> common complaint here, sorry
[18:30] <directhex> seems to have smoothed out now, more or less
[18:31] <directhex> er
[18:32] <directhex> one old blocker was over paths
[18:32] <directhex> something like you can't have your aot images in a different folder to your il, which is a multiarch problem
[18:33] <RAOF> But we don't have a multiarch mono, right?
[18:33] <directhex> dlr-languages builds fine, but the git is really unclear
[18:33] <directhex> tens of megs of binary dll cruft
[18:33] <directhex> like copies of silverlight, things like that
[18:33] <directhex> the only real blocker is someone making a "clean" tarball
[18:34] <RAOF> Are we likely to have both mono:armhf and mono:amd64 installed simultaneously?  If not, we don't need to care about paths.
[18:34] <directhex> i don't see that as a likely situation
[18:34] <directhex> armhf is fucked btw
[18:34] <RAOF> YAY!
[18:34] <directhex> p/invoke segfaults
[18:34] <directhex> so it builds and runs, until anything p/invokes anything
[18:35] <directhex> problem is mono is expecting armel ABI
[18:35] <directhex> mono doesn't support the armhf ABI at all
[18:35] <directhex> it's about 500 lines of changes. i woulc conjecture. if i had seen a non-public port.
[18:36] <directhex> zoltan vargaz has offered to coach anyone eager to do a port
[18:36] <directhex> but cannot write a line of code for it
[18:37] <RAOF> Maybe once I actually get an arm device I'll go for it.
[18:37] <directhex> i have an efikamx but i haven't managed to run dist-upgrade on armhf debian on it without it becoming unbootable
[18:37]  * RAOF *should* be getting a pandaboard or something shipped to him.
[18:39] <directhex> unrelated: i want monodevelop to have a "publish to PPA" button within a year. it'd be neato.
[18:39] <directhex> mono, not cli-common, since the aot cache is mono-specific
[18:39] <directhex> of course, dotgnu never did get resurrected, so that's an academic distinction
[18:40] <directhex> and nobody ported .net micro to linux
[18:40] <directhex> still, abstraction is good for the soul ^_^
[18:41] <directhex> more alive than plenty of core things in linux, tbh
[18:41] <directhex> still lots of critical tools last touched in 2006ish
[18:42] <directhex> (note: i have no idea how much latency there is in the audio, so i don't know if i'm communicating with 5 minutes ago)
[18:43] <directhex> so time my jokes for about 10 seconds of delay. got it.
[18:44] <directhex> oh, i was looking at doing CI snapshot packages, with upstream
[18:44] <directhex> i.e. served off a mono-project.com repo
[18:44] <directhex> waiting for some feedback from miguel
[18:45] <directhex> not system packages though, it'd be hell to maintain a full set like that
[18:46] <directhex> so mono-snapshot-201205101945 installs to /opt/mono-snapshot-201205101945, registers as a GAC runtime, and can be pushed into the environment via mono-snapshot command
[18:46] <directhex> it's a work in progress. it'd help if someone could sync environment-modules from debian
[18:47] <directhex> also i need to work out why modules only works via ssh, not interactively. debug time for jo
[18:47] <directhex> at any rate, it might be useful
[18:49] <udsbotu> uds-gb-g: 5 minutes left in this session!
[18:50] <udsbotu> uds-gb-g: 4 minutes left in this session!
[18:51] <udsbotu> uds-gb-g: 3 minutes left in this session!
[18:52] <directhex> upstreaming things is easy if you do it via github forks, and ping the right people on irc
[18:52] <directhex> they also like unit tests
[18:52] <directhex> i've only broken the mono build a half dozen times ¬_¬
[18:52] <udsbotu> uds-gb-g: 2 minutes left in this session!
[18:53] <udsbotu> uds-gb-g: 1 minute left in this session!
[18:53] <directhex> okay, that was an interesting session
[18:54] <directhex> all the fun of UDS, without the 8 hour flights
[18:54] <udsbotu> uds-gb-g: This session has ended.
[19:15] <med_> Did you guys already talk about fixing archives for ARM, (ie making ports.ubuntu.com avail in cloud-init)
[19:15] <med_> smoser, utlemming ^
[19:37] <arosales> oz =http://aeolusproject.org/oz.html
[19:55] <udsbotu> uds-gb-g: 5 minutes left in this session!
[19:56] <udsbotu> uds-gb-g: 4 minutes left in this session!
[19:57] <udsbotu> uds-gb-g: 2 minutes left in this session!
[19:58] <udsbotu> uds-gb-g: 1 minute left in this session!
[19:59] <udsbotu> uds-gb-g: This session has ended.
[22:55] <udsbotu> uds-gb-g: 5 minutes left in this session!
[22:56] <udsbotu> uds-gb-g: 4 minutes left in this session!
[22:57] <udsbotu> uds-gb-g: 3 minutes left in this session!
[22:58] <udsbotu> uds-gb-g: 2 minutes left in this session!
[22:59] <udsbotu> uds-gb-g: 1 minute left in this session!
[23:00] <udsbotu> uds-gb-g: This session has ended.
[23:54] <udsbotu> uds-gb-g: 5 minutes left in this session!
[23:55] <udsbotu> uds-gb-g: 4 minutes left in this session!
[23:56] <udsbotu> uds-gb-g: 3 minutes left in this session!
[23:57] <udsbotu> uds-gb-g: 2 minutes left in this session!
[23:58] <udsbotu> uds-gb-g: 1 minute left in this session!
[23:59] <udsbotu> uds-gb-g: This session has ended.