[00:02] <bryceh> @pilot out
[02:43] <sladen> jdstrand: are you happy with the one-word fix for bug #697181
[03:59] <EagleScreen> is powerpc arch supported in natty?
[04:02] <micahg> EagleScreen: I think it's community supported ATM
[04:02] <EagleScreen> oh I thought it was going to be official in natty
[04:02] <micahg> oh, maybe
[04:03] <EagleScreen> but currently pbuilder doesn allow me to create a root for powerpc
[04:11] <JanC> why would PPC become official again?
[04:11] <TheMuso> its still community.
[04:59] <JackyAlcine> Guys, I have a question regarding Boolean algerba and C++
[05:04] <sladen> JackyAlcine: just ask!
[05:04] <JackyAlcine> It deals with int enums.
[05:04] <JackyAlcine>  Like let's say you have an enum {a = 0, b, c, d, j, k, l, m} would b & l give the same int value as a & m?
[05:09] <JackyAlcine> ?
[05:10] <sladen> JackyAlcine: && is logical;  & is bitwise.  Which are you after?
[05:10] <JackyAlcine> I think bitwise, I'm trying to create a field to a class that uses the enum as flags, and I want the flags to incorporate a bunch of them.
[05:11] <JackyAlcine> I think I should just use a vector<string>, lol.
[05:12] <sladen> JackyAlcine: you might have  enum {a = 0x1, b = 0x2, c = 0x4, d=0x8, e=0x10, ...;}   and test an integater flag field with that?
[05:12] <sladen> integer
[05:16] <sladen> JackyAlcine: but yes, strings would stop you running out of bits and easier for a human to debug
[05:19] <micahg> strings will also increase the amount of memory for each operation
[05:21] <JackyAlcine> That's what I'm trying to avoid, micahg; this field's going to be accessed very often.
[06:58] <kees> doko_: can you apply the patch in 691722 to the next upload of gcc-4.5 in natty?
[07:22] <dholbach> good morning
[07:24] <micahg> dholbach: good morning, I have a fix for gnome-python-extras coming in a few minutes, would you be able to upload it?
[07:25] <dholbach> micahg, I can take a look at it but might not be the best person to judge it
[07:25] <micahg> dholbach: ok, I can ask someone from the -desktop team, thanks
[07:35]  * nixternal hugs dholbach 
[07:36]  * dholbach hugs nixternal back :)
[07:41] <tkamppeter> pitti, hi
[08:16] <didrocks> good mornning
[08:26] <pitti> good morning
[08:26] <pitti> tkamppeter: hey
[08:28] <pitti> tkamppeter: thanks for the announcement :)
[08:32] <pitti> tkamppeter: btw, perhaps you can update the paragraph about trusted paths?
[08:32] <pitti> tkamppeter: as distro developers now don't need to manually download and verify the key, jockey does that automatically now
[08:36] <fta2> d'oh! the last kernel update doesn't like the nvidia driver. bug 698327
[08:54] <pitti> cnd, bryceh: you both uploaded an xorg-server package to maverick-proposed; can you please upload the latest one with an appropriate -v to include the two proposed versions, or better yet, just upload a 2:1.9.0-0ubuntu7.2 which has both changes?
[09:43] <cjwatson> @pilot in
[09:43] <pitti> cjwatson: happy piloting!
[09:45]  * dholbach hugs cjwatson
[09:51] <tkamppeter> pitti, great work.This completes one of the main projects of OpenPrinting, at least from the infrastructure side. I hope this motivates more manufacturers to create LSB-based printer driver packages (and then also more distros to automatically download and install them).
[09:51] <cjwatson> (I have to go out in a bit under an hour, but will resume after that)
[09:55] <tkamppeter> pitti, can you give me the link to the upstream home page of Jockey, so that I can reference to Jockey on the OpenPrinting page which describes the driver packaging?
[09:56] <pitti> tkamppeter: https://launchpad.net/jockey
[09:56] <tkamppeter> pitti, thanks.
[09:56] <pitti> tkamppeter: the upstream version provides all the building blocks for GPG etc.; but the distro implementation actually needs to call them (as adding repositories and installing GPG keys is package system dependent)
[09:56] <pitti> tkamppeter: i. e. the apt bits are only in the Ubuntu branch; on an RPM based distro you need to implement it differently
[09:59] <pitti> tkamppeter: I'll try to fix the long hang of the progress dialog today
[10:09] <tkamppeter> pitti, can you send me a text piece to add to the "Build a trusted path to distributions" section of the OpenPrinting packaging documentation to tell how it works if Jockey is used and in which cases Jockey is ready to be used and what Jockey is still missing?
[10:18] <directhex> oh, what's the right way to say "there are ppds missing" to the openprinting folks these days?
[10:21] <pitti> tkamppeter: something like this? http://paste.ubuntu.com/551431/
[10:28] <tkamppeter> pitti, thanks. will merge it into the site.
[10:30] <cjwatson> mvo: looking at bug 677516 - is it just me or is the proposed fix of making unattended-upgrades-shutdown setuid daemon extremely worrying?
[10:31] <cjwatson> mvo: I don't quite understand why unattended-upgrades-shutdown isn't just started with the privileges it needs to talk to plymouth
[10:31] <cjwatson> mvo: seeing as it's only run from pm-utils or an init script, and both of those run as root ...
[10:32] <mvo> cjwatson: that branch slipped through under my radar, we definiely do not want to make it setuid something
[10:32] <cjwatson> I wonder if it's something like plymouthd running as uid daemon and explicitly refusing messages that come from root
[10:33] <cjwatson> except plymouthd has code to explicitly refuse messages from non-root
[10:33] <cjwatson> (look for ply_boot_connection_is_from_root)
[10:33] <cjwatson> so I'm thoroughly confused about the whole thing
[10:35] <cjwatson> I've posted my confusion on the merge review
[10:35] <mvo> thanks cjwatson, I will poke it a bit
[10:36] <mvo> cjwatson: I'm pretty sure it worked at some point when I tested it
[10:36] <mvo> cjwatson: the other thing is that it keeps posting the message but the bugreport claims that it dosn't and need to do it in a loop (which it does)
[10:36] <mvo> already
[10:38] <cjwatson> @pilot out
[10:38] <cjwatson> temporarily
[10:38]  * cjwatson -> optician
[10:40] <tkamppeter> pitti, documentation on OpenPrinting is updated now.
[10:40] <pitti> tkamppeter: nice
[10:47] <tkamppeter> pitti, in bug 465916 many users are asking for a Lucid (LTS) SRU, as the DNS-SD broadcasting in CUPS worked in 8.04, only the patch is rather big. Should we really do that?
[10:48] <pitti> tkamppeter: given how many rounds it needed in natty, I'd give it some more testing in natty first
[10:48] <pitti> tkamppeter: and it's very intrusive indeed, and might cause regressions
[10:48] <tkamppeter> pitti, OK.
[10:58] <mvo> cjwatson: I also added a comment into the bug with instructions how to trigger the screen
[11:31] <janimo> is this the link to packages pending in NEW? http://people.canonical.com/~ubuntu-archive/queue/natty/
[11:32]  * janimo wonders id he did something stupid again or openmpi armel debs are in NEW
[11:32] <tumbleweed> janimo: https://launchpad.net/ubuntu/natty/+queue
[11:32] <janimo> tumbleweed, thank you
[11:45] <hrw> hi
[11:48] <JackyAlcine> Hey hrw
[11:49] <hrw> can someone check bugs 698230 699710 699779? they looks like duplicates
[12:01] <JackyAlcine> bug 698230
[12:01] <JackyAlcine> bug 699710
[12:01] <JackyAlcine> bug 699779
[12:27] <doko_> wgrant: ping
[12:30] <doko> wgrant: would it be possible to set up an ubuntuwire.com/ftbfs for https://launchpad.net/ubuntu/+archive/test-rebuild-20110107 ?
[12:48] <wgrant> doko: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110107-natty.html
[12:49] <wgrant> doko: Currently running on an old version of the script, but I'll merge the latest version tomorrow.
[12:49] <doko> wgrant: cool, thanks!
[12:50] <ogra> doko, could you approve bug 692613 ? asac is doing pre-sprint errands and i need u-boot-tools in main today (preferably directly with the binary NEWing)
[12:50] <doko> ok
[12:50] <ogra> thanks
[12:52] <ogra> jdstrand, can you let u-boot-tools and uboot-mkimage (transitional package) out of binary NEW and into main please (its a tad urgent, armel image builds depend on them)
[13:05] <cjwatson> @pilot in
[13:23] <jdstrand> sladen: re bug #697181, possibly but I've not looked at it. sbeattie is actively working on it
[13:24] <jdstrand> sbeattie: fyi, I went ahead and assigned you to the stable release tasks of that bug. feel free to fix natty too if someone else doesn't get to it :)
[13:24] <elif> cjwatson: if I want to load a disk driver in a preseed instalation, is it possible to say to preseed.cfg ?
[13:24] <jdstrand> ogra: re deNEW> sure thing
[13:24] <ogra> merci ! :)
[13:26] <cjwatson> elif: load it in a partman/early_command script
[13:26] <elif> cjwatson: thks.
[13:29] <jdstrand> ogra: did someone already do them?
[13:30] <jdstrand> hmm, seems no... where are they...
[13:32] <ogra> jdstrand, hmm, doko approved the main inclusion but for the former version
[13:32] <ogra> not sure he also processed the queue
[13:32] <doko> I did
[13:33] <ogra> oh, thanks then
[13:33] <ogra> jdstrand, ignore the request then ;)
[13:33] <jdstrand> ok
[13:34] <jdstrand> ogra: fyi, I didn't see them at https://launchpad.net/ubuntu/+source/uboot-mkimage or https://launchpad.net/ubuntu/+source/u-boot-tools though
[13:34] <cjwatson> mvo: lp:~mterry/unattended-upgrades/691886 looks sensible to me - perhaps you could investigate/merge?
[13:39] <mvo> cjwatson: thanks, will do
[13:49] <doko> ogra: where should uboot-mkimage live?
[13:49] <ogra> main
[13:50] <ogra> u-boot-tools and uboot-mkimage need to be in main
[13:50] <doko> and u-boot-tools too?
[13:50] <ogra> the rest i dont care
[13:50] <doko> ahh, the rest ...
[13:50] <ogra> yeah, u-boot has bootloaders we dont use (no kernels)
[13:50] <ogra> (the binary i mean)
[13:51] <ogra> thats why asac requested the split
[13:57] <ScottK> pitti or cjwatson: Would you please rescore kde4libs (only affects powerpc) - It'll avoid a bunch of KDE FTBFS/retries later if we can build kde4libs nowish.
[13:58] <pitti> ScottK, cjwatson: sure, doing
[13:58] <ScottK> pitti: Thanks.
[13:59] <janimo> in what cases do only amd and i386 builds show up? ex: https://launchpad.net/ubuntu/+source/haskell-syb-with-class/0.6.1-2build1
[14:01] <Laney> janimo: it's in P-a-s
[14:01] <Laney> %haskell-debian: amd64 i386 kfreebsd-amd64 kfreebsd-i386 powerpc      # Requires threaded Haskell runtime
[14:01] <Laney> erm, %haskell-syb-with-class: amd64 i386 kfreebsd-amd64 kfreebsd-i386      # [ANAIS] needs template haskell
[14:01] <janimo> P-a-s ?
[14:02] <Laney> Packages-arch-specific, list of packages which should only be built on certain arches
[14:02] <janimo> hmm, then build-deps on them need to be made conditional
[14:02] <janimo> I got to them becsuse they lead to armel FTBFS in others
[14:02] <janimo> Laney, thanks, I'll look into correcting those then
[14:03] <Laney> please do it in debian
[14:03] <janimo> Laney, ok
[14:03] <Laney> ty
[14:03] <janimo> Laney, someone retried the ghc6 build and this time it succeeded without other changes
[14:03] <Laney> they should ideally just go into dep-wait if there are missing build deps
[14:03] <mterry> cjwatson, hello!   I noticed glib2.0 wasn't in the desktop set.  I could see an argument for it not being (cross DE, pretty 'core'), just wanted to make sure if it was intentional
[14:03] <cjwatson> mterry: I think that's intentional, yes
[14:03] <Laney> so not require any changes
[14:03] <janimo> Laney, yes, dep-wait indeed
[14:04] <Laney> that's not a problem
[14:04] <Laney> you can leave that
[14:04] <mterry> cjwatson, cool, makes sense
[14:04] <Laney> about ghc6/armel: good & bad I guess...
[14:04] <Laney> did you check if it works?
[14:05] <janimo> Laney, it builds packages in the archive, but other than that I did not check
[14:05] <Laney> that's a good start because it was failing to do that before
[14:05] <Laney> i will try to merge 6.12.3 from experimental at the weekend
[14:06] <Laney> and then update to the latest haskell platform in Debian
[14:06] <janimo> Laney, for instance some happstack packages build dep on syb-class, this makes hapstack arch specific as well I guess
[14:06] <janimo> since it waits on those on armel
[14:07] <Laney> yep, that's sadly expected
[14:08] <Laney> it's the same for ppc too
[14:08] <janimo> so happstack is not that portable?
[14:09] <Laney> due to ghc6 → syb not being available, yes indeed
[14:37] <hallyn> Daviey: around?
[14:47] <pitti> tkamppeter: I uploaded a new jockey with much faster installation now, and a working progress bar
[14:55] <micahg> hi cjwatson, are you comfortable sponsoring bug 695728?
[14:57] <cjwatson> looking
[14:58] <cjwatson> micahg: yeah - is there a branch anywhere I should merge?
[14:58] <micahg> cjwatson: no, I just added a debdiff, would you prefer a branch?
[14:58] <cjwatson> (I'm checking out the vcs-bzr now)
[14:58] <cjwatson> micahg: no, a patch is fine
[14:59] <cjwatson> just checking for housekeeping purposes
[15:00] <micahg> ah, I see the desktop team has a branch that I should've used, sorry
[15:01] <cjwatson> micahg: done, thanks
[15:02] <micahg> cjwatson: thanks
[15:03] <pitti> cjwatson: got an ubiquity crash about "DebconfError console-setup/codeset doesn't exist"; already known, or want a bug?
[15:03] <pitti> cjwatson: (OTTOYH, I'll check LP, too)
[15:04] <cjwatson> pitti: bug, ideally with ubiquity -d
[15:04] <pitti> ah, bug 699829
[15:04] <cjwatson> I did test ubiquity before uploading :-/
[15:04] <pitti> cjwatson: I'll get you a -d output
[15:05] <cjwatson> I think I see the problem
[15:05] <pitti> ok, thanks
[15:06] <cjwatson> I WISH Anton hadn't gone and renamed all those templates
[15:06] <cjwatson> it was gratuitous
[15:12] <davmor2> Hey guys,  I'm getting a kernel panic from the latest alternate and live cds.  It's on an amd 64bit system with builtin nvidia gfx.  Works flawlessly under maverick.
[15:13] <tkamppeter> pitti, thanks for resolving tyhe progress bar issue in Jockey. Why is it not in upstream Jockey? Is the package installation GUI also Ubuntu-only?
[15:16] <pitti> tkamppeter: no, the GUI is generic
[15:16] <pitti> tkamppeter: upstream jockey uses packagekit
[15:17] <pitti> tkamppeter: since all the apt specific stuff isn't appropriate for upstream
[15:17] <pitti> but at least our packagekit isn't powerful enough to do stuff like "add a trusted GPG key"
[15:18] <pitti> or even just adding a repo (the API exists, I think, but is unimplemented)
[15:18] <pitti> I guess it's much more complete on Fedora
[15:18] <pitti> so if someone is interested to do that on an RPM based distro, I'm glad to assist, but I don't feel the urge to do it myself
[15:18] <pitti> especially since Fedora reinvented that wheel already anyway
[15:19] <pitti> (not the printing part, though; they don't have any solution to that)
[15:19] <pitti> brb
[15:45] <cjwatson> @pilot out
[15:57] <hallyn> cjwatson: ok, so for multipath-tools merge, like an idiot i did 'bzr merge lp:ubuntu/natty/multipath-tools' from debian/experimental, instead of the other way around.  I take it that is insufficient?  (though I'd assume both histories are inherited either way...)
[15:58] <cjwatson> mm, yeah, that would be really pretty confusing, but it should be easy to revert and do it the other way
[16:00] <jdstrand> Riddell: hi! does kde have an autostart directory ala ~/.config/autostart ?
[16:01]  * Amaranth thought the autostart stuff came from kde
[16:01] <Riddell> jdstrand: yes, ~/.config/autostart or ~/.kde/Autostart/
[16:01] <jdstrand> Riddell: thanks!
[16:01] <Riddell> Amaranth is right indeed
[16:02] <jdstrand> *shrug*
[16:02] <mvo> doko: could you please look at bug #699881 (and the attached patch). if it looks good I will upload, pycentral crash on upgrade
[16:02] <jdstrand> I don't know where it came from, but glad to know what it is :)
[16:02] <jdstrand> s/what/where/
[16:04] <hallyn> cjwatson: (ok, thanks, i suppose another merge will help make it all less magic than it was the first time :)
[16:06] <doko> mvo: it surely a hack, we should at least know which package doesn't byte-compile for 2.7 ...
[16:08] <cjwatson> doko: the second example under "How to Fix a Problem" in https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition looks odd.  Surely it would almost never be correct to have -l<stuff> foo.c?
[16:11] <doko> cjwatson: yes. I'm not sure that I like the mixing of the error messages for the different bugs. but it's difficult for other to distinguish these
[16:13] <mvo> doko: I don't mind if its fixed in a different way, but the current failure condition is that half the wold fails (becasue python-minimal can't be configured)
[16:13] <jdstrand> Riddell: also, where does kmail store its mail and passwords?
[16:14] <doko> mvo: do what you think works, I'm offline in a few minutes and travelling tomorrow
[16:15] <Riddell> jdstrand: mail should be somewhere in  ~/.kde/share/apps/kmail
[16:15] <Riddell> jdstrand: settings in .kde/share/config/kmail
[16:15] <jdstrand> Riddell: great, thanks! :)
[16:15] <Riddell> jdstrand: password in kwallet which should be in .kde/share/apps/kwallet/
[16:16] <jdstrand> ah, perfect
[16:16] <Riddell> actually settings in .kde/share/config/kmailrc
[16:17] <geser> mvo: do you how I can fix this? http://paste.ubuntu.com/551527/
[16:18] <mvo> geser: sure, feel free
[16:19] <geser> mvo: how? (not if)
[16:20] <dholbach> cjwatson, good work!
[16:21] <cjwatson> ta
[16:22] <mvo> geser: oh, sorry. it looks like a bug in xapian index, does it prevent synaptic from starting?
[16:22] <mvo> geser: it shouldn't really
[16:23] <geser> mvo: no, synaptic works but will the search with apt-xapian work reliable if the apt-xapian database doesn't get updated?
[16:25] <mvo> geser: hm, I need to leave for a couple of minutes but I can have a look afterwards.
[16:25] <mvo> geser: I can not reproduce it fwiw here yet
[16:26] <geser> mvo: sure, no hurry; hmm, then I wonder what package I'm missing (again)
[16:27] <cjwatson> mvo: there's a new grub2 in the archive now that should fix your btrfs bug
[16:27] <cjwatson> it ought to cleanly upgrade and boot OOTB
[16:29] <tkamppeter> Can someone look into bug 691533? It is the MIR for jbig2dec and I have now uploaded the Ghostscript package which needs it.
[16:30] <tkamppeter> It is still in "no one has seen it yet" state.
[16:53] <mvo> cjwatson: yeah, installs/boots fine now, just complains that "sparse files are not allowed", but continues anyway with the boot
[16:54] <cjwatson> mvo: hm, I don't think that comes from GRUB
[16:55] <cjwatson> I can't find it in the kernel or btrfs-tools either ...?
[16:56] <mvo> cjwatson: "error: sparse file not allowed" to be precise, its a vm so I had to type
[16:57] <mvo> cjwatson: 100% reproducable for me, I'm happy to debug after dinner further
[16:57] <mvo> (in this vm)
[16:58] <cjwatson> ah, now I see it
[16:58] <cjwatson> ./grub-core/commands/loadenv.c:234:      return grub_error (GRUB_ERR_BAD_FILE_TYPE, "sparse file not allowed");
[16:59] <cjwatson> it shouldn't be sparse, so that does suggest a grub bug
[16:59] <cjwatson> mvo: don't worry, we can poke at it next week
[17:08] <Keybuk> FFS Thunderbird
[17:08] <Keybuk> apparently if you click archive on a mail, all replies to that are archived too
[17:21] <glatzor> hello mvo
[18:35] <smoser> cjwatson, around ? bug 697493
[18:35] <smoser> obviously there is a bad free somewhere, but i'm wondering if you suggest that I should have /proc mounted anyway
[18:36] <smoser> (which never was needed before)
[18:37] <cjwatson> smoser: I don't *think* it should be necessary if you've inserted a fake grub-probe; although I can't promise it won't be needed for update-grub in the future
[18:37] <cjwatson> smoser: but as you can see, I've committed a fix
[18:37] <cjwatson> or at least I think I have
[18:38] <cjwatson> that's the only direct use of /proc that I can see in GRUB's C code
[18:41] <smoser> cjwatson, where is the branch "butter" ?
[18:41] <cjwatson> smoser: http://bzr.sv.gnu.org/r/grub/branches/butter/
[18:42] <smoser> thanks.
[18:42] <cjwatson> smoser: also http://bzr.debian.org/scm/loggerhead/pkg-grub/trunk/grub/revision/2279
[18:45] <MattJ> Is there any work planned or in progress to integrate PulseAudio into Gnome/Ubuntu further? e.g. a shinier pavucontrol
[18:57] <Quintasan> doko: ping
[19:00] <Quintasan> doko: well, bug #699974, I wanted to know if we can discard delta, I have no idea about this and I was told you could help me confirming it
[19:10] <ScottK> Quintasan: Needs a merge.
[19:10] <Quintasan> ScottK: heh, sounds like more work, I'll look into it
[19:14] <ScottK> doko: Do we want our default Python3 to be 3.1 or 3.2 now?
[19:14] <ScottK> Quintasan: ^^^ If the answer is 3.2, then it can be synced.
[19:15] <Quintasan> ScottK: oh, I see. Thanks for helping out. I was about to grab the source :)
[19:53] <RoAkSoAx> doko: ping?
[19:56] <RoAkSoAx> I have a quick question. There's a FTBFS because of the --as-needed. I'm patching the Makefile.am like http://pastebin.ubuntu.com/551595/. (Note that some for some of the *_LDADD a library is added, for a few, 3, the new lib is not added). Would it be better to add the lib to COMMONLIBS instead of adding it to each *_LDADD?
[20:02] <doko> RoAkSoAx: most likely the common libs has to appear after the internal lib
[20:03] <doko> RoAkSoAx: it's better to look at the Makefile.in if there are macros for the other libs and use these instead
[20:08] <RoAkSoAx> doko: i was planning to patch both given that the package does not autoreconf.
[20:09] <RoAkSoAx> doko: so I should add that lib to each of the binaries built, instead of adding it only to COMMONLIBS?
[20:15] <doko> RoAkSoAx: it's your choice. I would only add it for the ones where it's needed
[20:18] <RoAkSoAx> doko: ok yhen, thanks :)
[20:50] <soreau> How is it that libwxbase2.8 installs /usr/include/wx2.8/wx/wx.h while /usr/include/wx/wx.h does not exist yet the source finds it?
[21:43] <ScottK> doko: Did you see my ping about Python3 default?  Do we want 3.1 or 3.2?
[21:46] <doko> ScottK: we already have 3.2
[21:47] <ScottK> oK.
[21:48] <ScottK> doko: actually we don't.
[21:49] <ScottK> default-version = python3.1
[21:49] <doko> huh? maybe I didn't upload
[21:49] <ScottK> it's 3.2 in Debian experimental.
[21:49] <doko> but I did announce it =)
[21:49] <ScottK> doko: We can just synch from experimental.
[21:49] <ScottK> Yes.  You did.
[21:49] <doko> sure
[21:49] <ScottK> Riddell: ^^^ We can sync python3-defaults.
[21:50] <Riddell> ScottK: groovy
[21:50] <doko> Riddell, ScottK: please fix the cmake b-d
[21:51]  * ScottK looks at Riddell for that one.
[21:51] <Riddell> doko: yes sorry I'll look into it but been too busy
[21:52] <doko> soreau: I assume alternatives are used
[21:53] <Quintasan> ScottK, Riddell: thanks
[21:53] <Quintasan> doko: Thanks as well :)
[21:59] <soreau> doko: I see it figures it out at config time
[22:15] <Datz> Hi, I have a feature request, is this the place?
[22:32] <bryceh> Datz, http://brainstorm.ubuntu.com
[22:34] <Datz> bryceh: thanks, just submitted :)
[22:34] <Datz> http://brainstorm.ubuntu.com/idea/26910/
[22:35] <bryceh> Datz, totally, I'd get a lot of use out of such a feature myself
[22:36] <bryceh> Datz, also it's not possible afaik to blank one screen but not the other, which would be another useful feature
[22:38] <Datz> ah, yea that too :)
[22:38] <ebroder> bryceh: hmm...if you added a "do nothing" option, and made it so that closing the lid automatically "disconnected" the internal display...
[22:38] <ebroder> (which for all i know could happen already)
[22:41] <bryceh> ebroder, yeah that'd be nice to.  It doesn't do that currently