[00:23] <doko> bryceh, please could you have at the *nvidia* ftbfs in quantal?
[00:24] <bryceh> doko, do you mean the one waiting on MIR #1053065?
[00:26] <doko> bryceh, nividia-texture-tools, nvidia-cuda-toolkit, pycuda
[00:31] <bryceh> doko, ok, those appear unrelated to the MIR but I'll take a look
[01:27] <|Anthony|> are there any plans to support multiseat setups comparable to how fedora currently does?
[01:28] <|Anthony|> not with systemd though, but through existing and currently in use (but being developed upstream) software?
[01:28] <|Anthony|> for example, Xorg has a new -seat option in 7.7
[01:51] <|Anthony|> is udev going to be forked/maintained for/by *buntu since it has been merged into systemd? If not will there be a replacement, or will it just age?
[01:53] <sarnold> |Anthony|: ooh, -seat ? sounds cool
[01:54] <|Anthony|> yeah
[01:54] <|Anthony|> the more i look into this the more mad i get honestly
[01:55] <|Anthony|> lennart et al has managed to get their hands into so many system critical things that all distros will have to use systemd
[01:55] <|Anthony|> udev
[01:55] <|Anthony|> consolekit
[01:56] <|Anthony|> the -seat switch in Xorg was introduced to enhance systemd imo

[01:57] <|Anthony|> idk why -seat is needed tbh when there is -layout and -config
[01:57] <|Anthony|> both of which are able to maintain a group of associated hardware
[01:58] <sarnold> |Anthony|: I've coined the phrase "the lennartisation of Linux" to describe many of the things I've come to dislike or detest...
[01:58] <sarnold> .. but that's just my own personal opinion. :)
[01:58] <|Anthony|> it is one that is shared by many
[01:59] <sarnold> I had hoped, when you first mentioned -seat, that it'd be that cleverl little final piece of glue to make it easy to piece together four video cards, four keyboards, four mice, into a single system with four separate X systems all at once.
[01:59] <sarnold> (A dream I've seen discussed for 15 years at this point...)
[02:00] <|Anthony|> if i understand it's purpose, it is used by udev (now systemd) for rule matching
[02:00] <|Anthony|> sarnold, it already is easy to do that with the version of x included in 12.04
[02:01] <|Anthony|> very actually
[02:01] <sarnold> yay!
[02:01] <|Anthony|> and some simple udev magic to allow hotplugging of input devices makes it nice
[02:01] <|Anthony|> only headache i have atm is routing audio to each seat
[02:02] <sarnold> ohhh
[02:02] <|Anthony|> there is no audio support in X as far as i can tell
[02:03] <|Anthony|> just video, keyboard and mouse
[02:03] <|Anthony|> and guess who owns pulseaudio?
[02:03] <|Anthony|> lennart
[02:04] <sarnold> (just between you and me, every new install I do I find audio breaks soon... and after half-hour fiddling with knobs, I find that "apt-get purge pulseaudio" seems to fix all the problems and I haven't yet discovered what I'm missing..)
[02:05] <|Anthony|> pulseaudio has been a fkn thorn in my side for... well since i started in linux 4 years ago
[02:05] <|Anthony|> i came late to the linux party
[02:05] <|Anthony|> heh
[02:06] <sarnold> aha. :) That role used to be played by ALSA, which these days looks downright reliable in comparison.
[02:06] <|Anthony|> what is the difference between alsa and pulse
[02:06] <|Anthony|> cause they both run concurrently
[02:07] <|Anthony|> pulse is a sound server, and alsa is...
[02:08] <|Anthony|> i know the acronym but what it really is escapes me
[02:08] <sarnold> ALSA is the kernel interface between the /dev/dsp, /dev/mixer, etc. userspace interfaces and the soundcards
[02:08] <sarnold> ALSA is just a pile of modules that run in the kernel.
[02:08] <|Anthony|> ah
[02:09] <|Anthony|> and pulse manages it in userspace?
[02:09] <sarnold> I _think_ pulse is supposed to provide per-application mixers, volume levels, etc.
[02:09] <sarnold> but I've never seen that interface.
[02:09] <|Anthony|> haha
[02:09] <sarnold> anyway, dinner time. good luck :)
[02:10] <|Anthony|> i'm actually stuck at configuring pulse/alsa for the multiseat setup here
[02:10] <|Anthony|> and am banging my head cause i have no experience with configuring either one
[02:34] <mwhudson> totally random underresearched question, but is it possible that something removes /etc/resolv.conf when networking goes down?
[02:41] <mwhudson> one way to find out i guess
[02:42] <slangasek> mwhudson: nothing that's not buggy does so :/
[02:42] <mwhudson> heh
[02:43] <mwhudson> slangasek: so this is a linaro/lava thing
[02:43] <mwhudson> we deploy a test rootfs, boot into it, reboot into the master rootfs and the resolv.conf is gone from the testrootfs partition
[02:43] <mwhudson> ... sometimes
[02:43] <slangasek> hmm
[02:44] <slangasek> is this using resolvconf?  i.e., /etc/resolv.conf is a symlink into /run?
[02:45] <mwhudson> i think it's precise ubuntu-desktop based image
[02:45] <mwhudson> which means... yes?  i think so?
[02:45] <mwhudson> downloading the image now to poke at, but it's 600 megs compressed so...
[02:49] <slangasek> mwhudson: ack, with precise it should be a symlink.  Is it /etc/resolv.conf itself that disappears, or only the target of it?
[02:50] <mwhudson> slangasek: OperationFailed: executing 'cp -f /mnt/testrootfs/etc/resolv.conf /mnt/testrootfs/etc/resolv.conf.bak' failed with code 1
[02:50] <mwhudson> slangasek: which suggests the symlink is gone
[02:50]  * slangasek nods
[03:16] <bryceh> doko_, found a patch for the first package, looks like upstream just doesn't test 64-bit.  Contacted Debian as they may want the patch too.  The other two build failures are basically due to bug #950963; dunno what to do there, but I'll contact alberto.
[03:54] <pitti> Good morning
[05:53] <lifeless> ev: looks like [1] B. Babcock and C. Olston. Distributed top-k moni-
[05:53] <lifeless> toring. In Proc. of Intl. Conf. on Managment of Data
[05:53] <lifeless> (SIGMOD), pages 563–574, 2003.
[05:53] <lifeless> might be relevant
[05:53] <lifeless> ev:  Threshold Algorithm
[05:54] <lifeless> ev: appears to be what I off-the-cuffed, though I haven't read the details to be fully sure
[06:19] <diwic> @pilot in
[06:48] <pitti> cyphermox, stgraber: I just filed bug 1053236 after a friend's upgrade to precise got a bricked DNS; did that ever come up before? (I didn't find dupes)
[06:56] <dholbach> good morning
[06:56] <diwic> good morning dholbach
[06:56] <dholbach> hi diwic
[06:58] <diwic> dholbach, if a commit contains changes in the .pc directory, is that a valid needs-fixing complaint?
[07:06] <jibel> pitti, http://paste.ubuntu.com/1216255/ when I click on 'send' after running 'ubuntu-bug cloud-init' is it known ?
[07:06] <pitti> jibel: yes, I uploaded the fix an hour or so ago
[07:06] <jibel> pitti, ok, thanks.
[07:06] <pitti> sorry about that
[07:07] <jibel> pitti, no problem, I'll go the manual way
[07:08] <dholbach> diwic, no, not really - I think I'd just fix it myself and upload it - in most cases it's our tools' fault :-(
[07:08] <didrocks> pitti: wasn't that the secret solution for not having any new bug anymore? :)
[07:08] <pitti> jibel: or download python-apport from https://launchpad.net/ubuntu/+source/apport/2.5.2-0ubuntu4/+build/3800238
[07:09] <pitti> didrocks: *shht*
[07:09]  * didrocks hugs pitti
[07:09]  * pitti hugs didrocks back
[07:10] <diwic> dholbach, ah ok. Well, that could have made sense if I could upload...as such I will try to spend my patch pilot time on alsa/pulseaudio bugs with patches in them
[07:11] <dholbach> I guess you could just ask in the channel for somebody to upload it if it looks alright to you
[07:11]  * dholbach takes the dog for a walk - brb
[07:17] <jibel> all the autopackagetest runs will fail today (https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/) until I figure how to manually fix it. There is a bug in cloud-init 0.7.0~bzr659-0ubuntu1 that breaks the images we use as testbed.
[07:23] <pitti> that's actually not a bad test by itself :)
[08:21] <kyan> Hi, where should I ask a build error question?
[08:26] <xnox> !ask|kyan
[08:28] <kyan> xnox: okaaay, it's just that I've gotten blasted a few times for asking in the wrong channel.. Basically I'm trying to build Unity from source (via apt-get source --compile). When I'm building gettext, there's a missing operand error for the command cd debian/gettext/usr/lib && mv libgettextpo.so. ???
[08:29] <xnox> kyan: please use pastebin (there is nifty commandline package pastebinit) with full error log & version numbers
[08:29] <cjwatson> the source line for that is:
[08:29] <cjwatson>         cd debian/$@/usr/lib && mv libgettextpo.so $(DEB_HOST_MULTIARCH)
[08:30] <cjwatson> so that sounds like you're trying to build it on an older version of Ubuntu
[08:30] <cjwatson> pre-natty
[08:33] <cjwatson> kyan: ^- is that so?
[08:34] <kyan> cjwatson: I'm trying to build it outside of stock Ubuntu.
[08:34] <kyan> cjwatson: I'm using Wreathe (a Maverick fork) and trying to build Unity in it.
[08:35] <cjwatson> kyan: then the answer is probably not one you're going to like
[08:36] <kyan> xnox: Pastebin.com rejected it because it was too long; Pastebin.ca's server still hasn't replied
[08:36] <kyan> cjwatson: umm, off topic? *That's* why I asked where I should ask the question…
[08:36] <kyan> lol
[08:36] <cjwatson> no, that's not what I meant
[08:36] <kyan> cjwatson: oh?
[08:37] <cjwatson> kyan: maverick is sufficiently old that, even if you could build current packages on it, they wouldn't run because the linker there doesn't know about the current multiarch library path
[08:37] <kyan> cjwatson: Well how were the newer systems created? It seems that I'd need to update it to use the different library path.
[08:37] <cjwatson> kyan: the only ways to make this work are (a) manually reverse the steps of http://wiki.debian.org/Multiarch/Implementation where applicable for each package you're attempting to build (b) update to a newer base system
[08:38] <cjwatson> I would strongly recommend (b) if at all possible; (a) is not going to be even a little bit of fun
[08:38] <kyan> cjwatson: Well why not just update the base system to multiarch?
[08:38] <cjwatson> kyan: that's http://wiki.debian.org/Multiarch/Bootstrapping, but it is arduous
[08:39] <kyan> cjwatson: hmm…
[08:39] <xnox> kyan: pastebin.ubuntu.com should accept large output.
[08:39] <cjwatson> it would be easier to update to something based off a more recent version of Ubuntu rather than duplicating the (I think) man-weeks or more likely man-months of work involved there
[08:41] <kyan> cjwatson: Hmm. Couldn't one bootstrap off the later repos though? It seems like the work's already done, so it ought to be easy enough to just build each of the relevant packages in order from the new repos.
[08:41] <cjwatson> depends on how much you want to trust the directions above to be absolutely complete :)
[08:42] <cjwatson> sounds like a waste of effort to me, but you can try
[08:42] <cjwatson> you would probably want to start with natty rather than precise, but I don't recall any more whether there were bugs fixed in the interim that would be relevant ...
[08:43]  * ogra_ would just upgrade the base ... essentially backporting the packages you need will leave you already with a partitally upgraded system, why not wlak the full distance then ?
[08:43] <ogra_> *walk
[08:43] <kyan> cjwatson: Well I'm a little doubtful… given that I tried updating dpkg to 1.16 (for multiarch), but it requires a newer gettext (requires multiarch) to build dpkg. Chicken and egg.
[08:43] <cjwatson> we did this all iteratively in our archive; it would take a long time to reproduce the steps and you won't necessarily be able to jump over multiple ones
[08:44] <cjwatson> I would expect that the delta between maverick and wreathe is much smaller than the delta between maverick and natty (say)
[08:44] <cjwatson> so if you think of it that way, it should be easier to rebase wreathe on >=natty
[08:45] <kyan> ogra_: Well, basically all I want is Unity running simultaneously with the Wreathe Fusion Application Manager.
[08:45] <cjwatson> wreathe will have to update sooner or later anyway to continue getting security patches
[08:45] <ogra_> ++
[08:45] <kyan> cjwatson: That's quite possibly true.
[08:45] <ogra_> maverick starts to smell already
[08:46] <kyan> (WFMA=basically it's KDE Plasma and applications mashed up with GNOME 2 and a bit of LXDE).
[08:47]  * cjwatson looks at dpkg in natty
[08:47] <cjwatson> it only build-depends on gettext (>= 0.18), which maverick has
[08:47] <kyan> cjwatson: Hmm. Intriguing…
[08:47] <cjwatson> it's possible that apt-get source --compile tries to build all the build-deps without considering whether they're already available
[08:48] <kyan> I was using the dpkg from Quantal, so that might be a problem right there
[08:48] <cjwatson> or perhaps that if you install the build-deps before trying to build the package in question, that will help
[08:48] <cjwatson> you definitely won't be able to use dpkg from quantal; maverick's tools won't be able to parse the gettext:any build-dep in use there
[08:48] <cjwatson> don't try to skip over that much
[08:48] <cjwatson> we didn't build dpkg/quantal using a maverick build system, after all
[08:49] <ev> lifeless: cheers! I'll have a look
[08:49] <kyan> cjwatson: lol good point
[08:50] <cjwatson> at the very outside you should not expect to be able to skip over an LTS boundary; but in the special case of multiarch, extreme care is needed
[08:50] <kyan> cjwatson; Aight, let's see how natty sources do…
[08:51] <kyan> cjwatson: Hmm… :-P
[08:51]  * kyan is having his OS development crash course right now
[08:51] <kyan> XD
[08:53] <kyan> Huh. Building it from natty sources has dpkg give a bunch of test failures…
[08:55] <kyan> http://pastebin.com/gT38BYrx
[08:55] <kyan> That wasn't what I was expecting.
[08:58] <kyan> cjwatson: So I guess what it looks like is it doesn't know what the test results ought to be, for some reason or another…
[09:01] <cjwatson> kyan: I'm not sure what that is.  It might indicate that the dpkg-divert program there is broken for some other reason.
[09:02] <kyan> cjwatson: IDK either. I'm finding some missing development libraries (libbamf-dev wasn't available because of debhelper not being the right version), so I'm going to build them and hope they fix things.
[09:06] <cjwatson> kyan: libbamf-dev isn't in dpkg's build-dependency chan
[09:06] <cjwatson> *chain
[09:07] <kyan> cjwatson: hmm……
[09:07] <cjwatson> mvo: do you have some time to help me with apt and multiple signatures on a Release file?  I'm trying to upgrade the archive to sign with the new signing key as well, and I'm finding that if I only have the new key installed that gpgv refuses to process the signatures
[09:07]  * kyan is confused
[09:07] <kyan> then what was it showing up there for?? XD
[09:08] <kyan> cjwatson: Anyway I'm trying just bypassing the tests for now.
[09:08] <cjwatson> mvo: http://paste.ubuntu.com/1216392/
[09:08] <mitya57> will we sync new lintian when it's released?
[09:08] <cjwatson> kyan: perhaps you ought to build packages one by one using apt-get source and debuild -b; I'm not particularly sure what apt-get source --compile does these days
[09:09] <mitya57> (according to nthykier, it will happen after 2012-09-27, when the previous one migrates to testing)
[09:09] <kyan> cjwatson: ok. I haven't used that method before so it'll be a new experience :P
[09:09] <Laney> mitya57: probably
[09:10]  * mitya57 will now bump standards-version of his packages
[09:11] <Laney> who doesn't love a shiny new Standards-Version?
[09:13] <cjwatson> mvo: it does work if I have either both keys or only the old one, but this seems like anomalous behaviour
[09:13] <mitya57> ;)
[09:14] <mvo> cjwatson: yeah, that sounds wrong, does it matter if gpg or gpgv is used? or same result?
[09:15] <cjwatson> mvo: looks similar: http://paste.ubuntu.com/1216397/
[09:15] <cjwatson> mvo: and for completeness: http://paste.ubuntu.com/1216398/
[09:16] <cjwatson> mvo: I suspect this is a long-running issue - see e.g. http://lists.debian.org/debian-release/2009/06/msg00070.html
[09:17] <kyan> Now this is weird. grub-common in natty requires dpkg >= 1.15.4, or install-info, or dpkg <=1.14.25. According to gdebi-gtk, those dependencies are broken by updating to dpkg 1.16.0.
[09:17] <kyan> It seems to me that the dependencies are quite alright.
[09:18] <kyan> because 1.16.0 is undeniably >=1.15.4, and that *is*, after all, one of the options.
[09:19] <mvo> cjwatson: let me read the mail
[09:19] <cjwatson> mvo: oh, maybe it's because the new key uses a different digest algorithm from the old - see gnupg/g10/mainproc.c:2047-2061
[09:21] <cjwatson> old used SHA-1, new uses SHA-512
[09:21] <cjwatson> so I guess not really apt's fault - gpg just doesn't provide a way to do this
[09:21] <lifeless> ev: still digesting more of the stuff
[09:22] <mvo> cjwatson: right :/
[09:22] <kyan> ah, just a bug in gdebi-gtk. plain old dpkg handles it fine.
[09:23] <cjwatson> mvo: ah, here we go
[09:24] <cjwatson> mvo: if I force --digest-algo SHA1 when signing with the new key, it works
[09:24] <cjwatson> well, sort of
[09:24] <mvo> cjwatson: cool
[09:24] <cjwatson> I still get:
[09:24] <cjwatson> W: There is no public key available for the following key IDs:
[09:24] <cjwatson> 40976EAF437D05B5
[09:24] <mvo> :/
[09:25] <cjwatson> mvo: but it's non-fatal
[09:25] <cjwatson> i.e. the archive is still considered properly signed and I can install from it
[09:25] <mvo> cjwatson: funny coincidence, I was just reporting a upstream gnupg bug (or whishlist) for a --recv-key-strict that actually checks the keyid after the download
[09:26] <cjwatson> so I think a plan is: for <=precise, sign with only the old key; for quantal, sign with the old key plus the new key with --digest-algo SHA1; at some future point, sign only with the new key with the default digest algorithm for that key
[09:27] <mvo> cjwatson: right, sounds good
[09:27] <cjwatson> glad I tested this :-)
[09:27] <mvo> :)
[09:27] <mvo> and that you found the sha1 workaround
[09:28] <cjwatson> yeah.  I'll document it in commentary in lp:ubuntu-archive-publishing
[09:28] <kyan> cjwatson: wow. dpkg hates me. http://paste.ubuntu.com/1216417/
[09:30] <cjwatson> not a giant surprise.  use a chroot rather than building in your real system.
[09:31] <kyan> cjwatson: hehe.
[09:32]  * kyan asks, "best practices? what are those?!"
[09:34] <kyan> Anyway is it even possible to run gnome3/Unity and gnome2 simultaneously?
[09:34] <kyan> That somehow seems a little… wrong somehow
[09:46] <cjwatson> mvo: oh, hey, gpg supports using DSA keys (like the old one) with a SHA-512 hash
[09:46] <cjwatson> and it seems to work
[09:46] <cjwatson> I didn't know you could do that
[09:46] <mvo> woah
[09:46] <kyan> cjwatson: I'm running into this bug now: https://bugs.launchpad.net/compiz/+bug/1048964
[09:46]  * mvo will go and switch networks
[09:47] <kyan> cjwatson: I hit that trying to build compiz by itself a while ago.
[09:48] <cjwatson> ok, sorry, I've run out of time to help with this crazy project :)
[09:48] <cjwatson> but we've been using cmake on python 2.6 and 2.7 in Ubuntu for some time ...
[09:48] <kyan> cjwatson: np XD
[09:49] <kyan> cjwatson: I think the bug is because of a change in how the python version number is gotten by CMake.
[09:49] <cjwatson> oh, maybe that's a problem in compiz's cmakelists rather than in cmake itself, considering where the bug's filed
[09:49] <kyan> cjwatson: Yeah I think it is
[09:49] <cjwatson> again, I wouldn't try to build absolute current compiz on such an old base system
[09:50] <cjwatson> you are going to have to go step by step if you aren't willing to upgrade the base
[09:50] <kyan> hmm, well.. that was the whole point of this craziness :P
[09:51] <kyan> so basically the option is to upgrade to python2.7 (difficult, but I don't know why)
[09:53] <kyan> and unfortunately I now no longer have a control key.
[09:53] <kyan> wtf.
[09:54] <kyan> oh well... back to the drawing board
[09:58] <doko> tjaalton, bryceh: awake? bug #1053088 needs attention. looking into it now
[09:58] <tjaalton> doko: yes
[09:59] <doko> tjaalton, if you do, I won't
[10:00] <tjaalton> doko: looks like there should be a patch in fedora, I'll steal it
[10:00] <doko> ok, thanks
[10:15] <cjwatson> OK, I have told the archive to start signing with both old and new keys
[10:15] <cjwatson> for >= quantal
[10:15] <cjwatson> Hopefully my testing was sufficient :-)
[10:16] <cjwatson> I guess I'll find out in about half an hour ...
[10:22] <diwic> @pilot out
[10:29] <davmor2> hey guys is there meant to be a network-manager indicator for guest sessions?
[10:30] <davmor2> for me it showed up the first time I switch from my logged in user to guest, but from then on in it didn't show up
[11:13] <Daviey> bdmurray: hey, what did you do to avoid the regression on bug 1043725 ?
[11:16] <cjwatson> Daviey: he put the update-notifier dependency in update-manager rather than in update-manager-core
[11:19] <Daviey> cjwatson: thanks
[11:23] <dutchie> cjwatson: popey told me to poke you about a broken boot on a dual-boot machine after updates
[11:23] <dutchie> cjwatson: i have a grub rescue prompt, ls works, but that's about it
[11:23] <cjwatson> dutchie: https://www.gnu.org/software/grub/manual/grub.html#GRUB-only-offers-a-rescue-shell
[11:24] <popey> cjwatson, seems to affect dual-booters like dutchie and myself
[11:24] <cjwatson> dutchie: then after you get back into the system you should check 'dpkg-reconfigure grub-pc'
[11:24] <cjwatson> dual-boot systems are often misconfigured in how the boot loader is installed, for one reason or another
[11:25] <cjwatson> so they end up trying to load half of one boot loader and half of another at boot
[11:25] <cjwatson> this tends not to work so well
[11:25] <dutchie> the prefix and root appear to be set right, but "insmod normal" just gives me a file not found
[11:25] <cjwatson> you should make sure (in 'dpkg-reconfigure grub-pc') that only one of them thinks it owns the boot sector
[11:26] <cjwatson> you'll need to tell me more about the layout, and what prefix and root currently are, for me to be able to help any further
[11:28] <dutchie> layout is one disk with btrfs root, ext4 /boot on first disk, second disk with ext4 data (that happens to still have a bootable 12.04 install on it) and windows
[11:28] <dutchie> prefix is (hd0,msdos1)/grub, root is (hd0,msdos1)
[11:34] <dutchie> i have to go out now, but i'll leave irc on and have a look when i get back
[11:34] <dutchie> thanks
[11:38] <cjwatson> what is the exact file-not-found error message?
[11:39] <cjwatson> you should be able to 'ls $prefix' to see what that looks like - if this is GRUB 2.00 (quantal) then it should include i386-pc/ somewhere in there
[12:34] <smb> cjwatson, I believe to remember you doing installer testing in KVM VMs. Would you know why grub would think that qemu (Seabios) is a setup that should use EFI as a framebuffer. I am asking because I was looking at a problem resulting from that and wondering (as I have not heard of that being really used in anything else atm) why that is.
[12:34] <cjwatson> That sounds like a partial diagnosis; any chance of the original symptoms?
[12:35] <cjwatson> GRUB can only use EFI video if it's actually an EFI build
[12:36] <smb> I am not aware that my Precise host is using an EFI build. But the Quantal installation does bring up an EFI FB
[12:36] <cjwatson> So do you actually mean that Linux is using an EFI framebuffer?
[12:37] <smb> Which leads to problems because Quantal tries to kick that out and replace it with the cirrusdrmfb in a KVM environment
[12:37] <smb> cjwatson, yes
[12:37] <smb> Enabling the text only grub console prevents it and I could not find anything in the kernel deciding for efi fb beside that some info has been set up before
[12:38] <cjwatson> The only time GRUB will tell Linux to use an EFI framebuffer is if it is using one itself, which only happens if you're using grub-efi-* rather than grub-pc
[12:38] <cjwatson> Oh, it might be setting GRUB_VIDEO_LINUX_TYPE_SIMPLE
[12:38] <cjwatson> Which is 0x70
[12:39] <smb> Ah
[12:39] <smb> Yeah and I think to remember EFI value as 0x70, too
[12:39] <doko> pitti, GCC trunk (gcc-snapshot) now has libbacktrace, a library providing stack traces including source name and line number. it's not installed by default, so you would have to look at the sources and the build
[12:39] <Sweetshark> since there is talk about GRUB here right now:
[12:39] <Sweetshark> hmmm, installing the quantal daily CD (amd64) in VirtualBox fails to install the bootloader. known issue?
[12:40] <cjwatson> smb: But that's mostly been there for ages, in precise too I believe
[12:40] <pitti> doko: ah, interesting; does that also provide function arguments?
[12:40] <smb> Sweetshark, not that I know of... but I have not tried the daily today
[12:40] <cjwatson> Sweetshark: yes, bug 1053317
[12:41] <doko> pitti, didn't look, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54515 for an example traceback
[12:41] <cjwatson> smb: Normally, though, GRUB would be using VBE in qemu/kvm
[12:41] <smb> cjwatson, That is possible. The special drm driver for the cirrus card used in qemu just has been added with newer kernels
[12:42] <cjwatson> smb: Possibly the all_video work has meant that it ends up preferring cirrus ...
[12:42] <cjwatson> smb: Is this easily reproducible in kvm with quantal images and no funny business?
[12:43] <dutchie> cjwatson: i can see i386-pc, which contains a normal.mod file. the message is just "error: file not found"
[12:43] <Sweetshark> cjwatson: k, thanks.
[12:44] <smb> cjwatson, Relative. The fact that it races on replacing the fb happens not always and the result is sometimes you can get unity desktop running and sometimes it crashes
[12:45] <smb> cjwatson, Just because if it fails the cirrus X driver gets used (but that crashes), if not the modeset X driver gets used.
[12:45] <smb> cjwatson, You would see the failure by grepping for "cirrus" in dmesg
[12:45] <cjwatson> dutchie: I bet it says "GNU GRUB  version 1.99-something"
[12:45] <dutchie> it doesn't say gnu grub version anything
[12:46] <cjwatson> drat, maybe no version reporting if you get dumped to rescue mode
[12:46] <dutchie> just "Loading Operating System..." from the bios, then "error: file not found" and then the prompt
[12:47] <smb> cjwatson, If you are interested in the current status of it: bug 1038055
[12:47] <smb> (the LUKS reference is a red herring, probably should drop it from the description)
[12:47] <cjwatson> dutchie: well, "file not found" is a message from 1.99; 2.00 prints a more informative message including the file name
[12:47] <cjwatson> dutchie: so this indicates that the core image is 1.99 and is pointing to 2.00 modules
[12:48] <cjwatson> => misconfiguration
[12:48] <dutchie> right, so i have to get a live image to work somehow?
[12:48] <cjwatson> you might like to set root and prefix to the other installation on your second disk to get yourself going again
[12:48] <dutchie> ah, hadn't thought of that
[12:48] <cjwatson> since that's very likely where your core image comes from
[12:49] <cjwatson> smb: right, I just mean this scenario comes from a straight install?
[12:49] <cjwatson> smb: but that bug report predates GRUB 2.00; it's with more or less the same version of GRUB as was in precise
[12:50] <cjwatson> So it is not at all clear that this is a regression in 2.00; if it is, then there are multiple problems
[12:52] <smb> cjwatson, I would suspect it. Though I am reproducing it with an updated image. Let me check back with a precise image (whether efi fb is used). Though I am supecting the regression happens because the kernel suddenly has another fb driver
[12:54] <cjwatson> takes a while to check unfortunately since you have to actually do an install rather than rely on the live image
[12:58] <smb> cjwatson, It unfortunately will also take a while since I found the precise vm to be a bit behind on updates. Though at least with that there was no efifb lines to be found. But I want to get that updated to be sure.
[12:58] <dutchie> cjwatson: got back in, thanks
[12:58] <dutchie> did you say there was something else to do afterwards?
[13:08] <cjwatson> dutchie: 'sudo dpkg-reconfigure grub-pc' in both OSes and make sure exactly one of them is trying to install to wherever your firmware boots from
[13:18] <stgraber> pitti: nope, never heard of something like that. My understanding is that NM's DNS config writer is the same for all connections type so it should be writing into /run/resolvconf even when everything is statically configured...
[13:23] <obounaim> Please can anybody sponsor me: http://goo.gl/PijNl and http://goo.gl/QQAHD. Thanks in advance
[13:26] <mpt> ev, if you're having to update the graph manually, I guess bug 1039070 is fixed?
[13:27] <smb> cjwatson, Ok, so it is using efifb in Precise (with grub 1.99). So not a regression between grub versions. Probably lapse to not use VESA but we never noticed because there was not a drm driver for that virtual cirrus card.
[13:29] <cjwatson> smb: Right.  It's possible it's even deliberate, as Steve suggests; if efifb is given dimensions in the boot parameter block, it's not actually as tied to EFI as the name suggests.
[13:29] <ev> mpt: indeed, fixed
[13:30] <cjwatson> smb: See e.g. http://comments.gmane.org/gmane.linux.kernel/1027491, which I never did get round to pushing all the way up the hill
[13:30] <cjwatson> smb: But I *think* we intended to avoid efifb on BIOS systems in favour of KMS or whatever
[13:32] <smb> cjwatson, Ah I see. Yeah, there seems to be something done done for at least i915 based systems as I could not see the efifb show up on any netbooks/laptops I did look at
[13:32]  * smb notices word bouncing... maybe I should stop the coffee consumption...
[13:33] <cjwatson> On real hardware, GRUB will typically be using its VBE driver, so it won't pass 0x70 to Linux.
[13:37] <smb> If that would work with KVM instances, too it might avoid some issues right now. Not that it prevents us from having to look at the other issue at some time. Though somehow I doubt a bit that ripping out one fb and replace it by another one really helps the flicker free boot approach.
[14:02] <ahasenack> hi, I need a sponsor to upload #1053057 to quantal, the bug has a debdiff and the fix has been tested
[14:03] <cjwatson> psivaa: Did you manage to collect logs for bug 1052605?
[14:04] <psivaa> cjwatson, not yet, i have done a few ( about 4) with different precise being installed first and it did not occur lately
[14:04] <mvo> cjwatson: hm, that location looks wrong, it should look at the local dir instead of the system dir really :/
[14:04] <cjwatson> Hm
[14:05] <mvo> cjwatson: is that reproducable ?
[14:05] <cjwatson> mvo: Isn't removal_blacklist.cfg shipped in the package though?
[14:05] <cjwatson> Or do you mean the one in the dist-upgrader tarball?
[14:05] <cjwatson> mvo: Don't know :-)
[14:05] <mvo> cjwatson: it should also be part of the release-upgrader-tarball and that is what should get used during the upgrade
[14:06] <psivaa> it occured only once for me out of about 5 attmpts
[14:23] <ahasenack> hi, I need a sponsor to upload bug #1053057 to quantal, the bug has a debdiff
[14:23] <ahasenack> it's bugfix only, no other changes
[14:24] <ahasenack> hm, let me subscribe sponsors, I always forget that
[14:24] <ahasenack> that's ubuntu-sponsors, right?
[14:24] <geser> yes
[14:25] <ahasenack> done
[14:28] <brendand> bryceh, is there going to be a build of python-lpltk for precise and quantal?
[14:48] <doko> mterry, did you look at nvidia-settings-experimental-304 too?
[14:48] <mterry> doko, yeah briefly
[14:49] <doko> could you comment?
[14:49] <mterry> I thought I did..
[14:49] <mterry> I put as fix committed?
[14:49] <doko> no
[14:49] <mterry> oh...
[14:50] <mterry> doko, yeah, it's fix committed
[14:50] <mterry> I didn't leave a comment, just changed the status
[14:50] <doko> ohh, had to refresh. thanks
[14:54] <ev> mpt: http://poppy-dev.local/ - ignore the fact that the milestone lines don't perfectly line up yet. Am I to assume the missing grid lines and accompanying dates in your mockup means I should be getting rid of them?
[14:56] <mpt> ev, maybe not completely ... Try replacing them with dots where the horizontal and vertical grid lines currently cross?
[14:56] <mpt> so it's like the dotted graph paper :-)
[14:57] <ev> mpt: will you not rest until every interface looks like you drew it? ;)
[14:57] <ev> what about the dates along the x axis?
[14:58] <mdeslaur> someone should make an mpt gtk theme
[14:58] <mpt> ev, if you add tick marks to the dates, it will be clear what the grid dots are lining up with.
[14:58] <ev> okay
[14:58] <mpt> mdeslaur, totally
[14:58] <mdeslaur> :)
[14:58] <ev> and font!
[14:58] <mpt> ev, while you're at it, you could get rid of the years from the dates (at least until January)
[14:58] <ev> yes
[14:59] <ev> I was going to change the formatter to output "Sep 6"
[14:59] <ev> as you have in your mock up
[14:59] <mpt> good idea
[14:59] <mpt> oh, I do?
[14:59] <ev> yes :)
[14:59] <mpt> No wonder it's a good idea
[14:59]  * mpt flees
[14:59] <ev> :D
[15:04] <mpt> ev, and next step to extend the X axis to October 18?
[15:05] <ev> ah yes, good thinking
[15:05] <mpt> the finish line
[15:06] <ev> mpt: also, while I have you here. Any thoughts on what selecting the SRU most common problems table would look like? I vaguely recall us talking about this before
[15:06] <ev> is it just "most common errors for [ Ubuntu 12.04 SRU v]" or something like that?
[15:06] <mpt> ev, "SRU most common problems"? Is that -proposed?
[15:06] <ev> yes
[15:07] <ev> will probably just call it "12.04 proposed" instead of SRU
[15:07] <ev> as that doesn't get confused with -updates
[15:08] <mpt> ev, how about this? https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=99&rev1=98
[15:08] <mpt> or do you mean the table specifically?
[15:09] <ev> oh yes!
[15:09] <ev> that works
[15:09] <ev> thanks
[15:09] <ev> forgot you made that change
[15:10] <mpt> ev, no worries, I made the change after you asked the question
[15:26] <GrueMaster> I see slashdot is in an uproar about bug 966744.
[15:27] <GrueMaster> It may be of interest to some, but here at work, my Lenovo T61 has very similar issues, except I am running Windows 7 on it (forced to use, not a choice I made).
[15:28] <GrueMaster> It may be an acpi issue in the firmware.
[15:30] <psivaa> cjwatson, i have been able to reproduce bug 1052605 and the logs are attached to it now
[15:58] <mfisch> Does anyone know what happened to the Inhibit/Uninhibit DBUS calls that were supposed to prevent the system from suspending/screen blanking?  https://wiki.ubuntu.com/GnomePowerManagerInhibitSpec
[15:58] <mfisch> In Precise, I can't even find the dbus service
[15:59] <mfisch> which is supposed to be: org.freedesktop.PowerManagement.  Update Manager (and other code) still references the service and method
[16:06] <bdmurray> ev: do you know why version sorting and release mark up is strange on errors?
[16:08] <bdmurray> ev: on a bucket page that is
[16:15] <doko> is there really a reason to build qt4-x11 using GCC 4.6?
[16:16] <SpamapS> nostalgia?
[16:17] <doko> ahh, it's just the b-d
[16:19] <ev> bdmurray: what do you mean?
[16:20] <ev> oh, the sorting is busted, isn't it
[16:20] <ev> rubbish
[16:22] <bdmurray> ev: right and not every package version has a release by it - I wasn't sure if that was by design or not
[16:22] <sarnold> doko: b-d?
[16:22] <cjwatson> build-dependency
[16:22] <sarnold> thanks cjwatson :)
[16:23] <doko> started a local qt4-x11 build ...
[16:25] <micahg> doko: are you thinking to demote gcc-4.6?
[16:25] <doko> only if infinity starts building eglibc with 4.7 ;-P
[16:25] <cjwatson> grub2 as well, which I don't plan to change for quantal
[16:26] <cjwatson> GCC version bumps there have a habit of introducing size problems
[16:26] <micahg> heh, ok
[16:27] <ev> bdmurray: it doesn't have a release by it when we can't find that version published in any release
[16:28] <bdmurray> ev: ah so ones that have been superceded won't show up?
[16:29] <ev> bdmurray: ah yes
[16:29] <ev> because we say status=Published in launchpad.py
[16:30] <ev> so that would do it :)
[16:42] <doko> didrocks, unity-lens-shopping has files generate by vala 0.16. is this really wanted?
[16:42] <didrocks> doko: yeah, we usually do that with vala
[16:43] <didrocks> doko: because it's so unstable that we prefer to have the generated file rather than rerunning vala
[16:43] <doko> didrocks, yeah, but 0.16, not 0.18?
[16:43] <didrocks> doko: all lenses are on 0.16, 0.18 isn't working well with them
[16:44] <didrocks> doko: enjoy the world of vala instability :)
[16:44]  * doko accepts and runs away
[16:44] <didrocks> doko: ahah :)
[16:54] <doko> bryceh, mterry: how are the plans for mesa's st2c recommend?
[16:55] <didrocks> doko: can you binNEW them, please? (amd64 ready)
[16:55] <doko> tkamppeter, pitti: any news about the foomatic-db recommends in universe?
[16:57]  * mterry lets didrocks answer about st2c
[16:57] <didrocks> I think bryceh is the best to answer on the status
[17:02] <bryceh> doko, s2tc MIR is LP: #1053065.  Already added to quantal as LP: #1053029.  No plans for SRU at this time.
[17:03] <zyga> pitti, ping
[17:03] <doko> mterry, I'm away now for some hours, if needed today, please review
[17:04] <mterry> doko, sorry, please review the s2tc mir?
[17:29] <bdmurray> ev: how do you suggest we link https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fshare%2Fapport%2Fapportcheckresume%3AAssertionError%3A%3Cmodule%3E%3Amain%3Awrite%3A_assert_bin_mode to bug 1040353?
[17:48] <fginther> Can someone please help sanity check a merge proposal for a updated package in precise? https://code.launchpad.net/~fginther/ubuntu/precise/evemu/transitional-1051044/+merge/125214
[17:48] <fginther> I've added a transitional package and need to repeat this for more packages. I'd just like to know if I've done this correctly.
[17:49] <fginther> The MP shows more changes then it should, I only changed 2 files.
[18:08] <tkamppeter> doko, still there? I have prepared everything so that the foomatic-db binary can get demoted. I have commented appropriately in the bug report.
[19:09] <fginther> Can someone please help sanity check a merge proposal for a updated package in precise? https://code.launchpad.net/~fginther/ubuntu/precise/evemu/transitional-1051044/+merge/125214
[19:10] <fginther> I've also attached a debdiff to https://bugs.launchpad.net/ubuntu/+source/evemu/+bug/1051044
[22:04] <lifeless> ev: https://docs.google.com/viewer?a=v&q=cache:uI1lHPqS5P4J:crystal.uta.edu/~gdas/Courses/Courses/Spring2006/DBExploration/Arjun_Sushruth_fagin_ta.ppt+&hl=en&gl=nz&pid=bl&srcid=ADGEESgyf-tCOTGV7N93L35Sq3kmsdIXVm-vdGDks4fUIuehxfeXvm7qoqFr8v6BEk2XmnitikcZ0lLdvqXUuPIzFh-ANf5KG-UouzvGmf2EnztwtP8ZlzgZIJGUrrAHFLp3afmIHHIT&sig=AHIEtbQhRHF5CpZBgkXWgphpKenwj5MIPA
[22:04] <lifeless> seems like the shit
[23:16] <TheMuso> xnox: Revert which patch? We can either revert the patch in GTK, or apply the fix that I attached in bug 1053112 to at-spi2-atk, which is the proper fix.
[23:17] <xnox> TheMuso: sorry, I didn't refresh the web-page before commening.
[23:17] <xnox> TheMuso: your proposed patch is a better solution, please ignore my noise =)
[23:18] <TheMuso> Just awaiting the release team approval, I subscribed them at least. Do I need to do anything else to get it on their radar?
[23:19] <xnox> TheMuso: advertise the bug number on #ubuntu-release =) bribing #ubuntu-release channel with bird seeds also helps
[23:19] <TheMuso> xnox: heh ok thanks.
[23:19] <RAOF> Mmm, bird seed.
[23:19] <sarnold> some of that delicious delicious suet? with insects??
[23:34] <xnox> TheMuso: I have now hidden my confusing comment in shame ;-)
[23:35] <TheMuso> heh