[02:09] <bud32> Hi :) ﻿what means "intelfb: cannot reserve FB region" ? This message appears on system boot. I have a custom config for this kernel. I saw the code... drivers/video/intelfb/intelfbdrv.c:568, does cleanup() then return means that the intelfb is not actually used / completely initialized? I tried without the driver, but I couldn't use tty's.
[03:23] <atrus> at some point I used to be able to put a script into /etc/acpi/resume.d (in particular 99-xrandr.sh), and have it run when I resume from suspend, but now that doesn't seem to happen. Has that behavior changed, or am I doing something wrong?
[03:23] <J-Unit> atrus: yeah it's now /etc/pm.d/suspend.d or somethig of that sort
[03:24] <atrus> J-Unit: hmm. /etc/pm.d has nothing but 3 empty subdirectories.
[03:25] <J-Unit> atrus: yeah.... I wish I remember the correct format off the top of my head
[03:25] <J-Unit> but currently I'm on a RHEL box and can't check
[03:25] <J-Unit> ubuntu land is suffering a power outage ;-)
[03:25] <atrus> heh. well, it gives me something else to google for anyways :)
[03:26] <J-Unit> it's the standard pm-utils script format
[03:26] <J-Unit> list the contents of pm-utils
[03:26] <J-Unit> and in /usr/share you should see similar formatted scripts
[03:26] <J-Unit>  the /etc/ location is simply a supplement to those
[07:26] <TheInfinity> blaxun1st
[08:14] <bain> Good morning.
[08:17] <bain> Is there currently any plans for an integrated user desktop backup application ?
[08:19] <persia_ume>  What would it backup up?  To what media?  On what conditions?  There are several tools to facilitate this, with different answers to those questions available.
[08:22] <bain> persia_ume: I'm talking about an easy way to backup your desktop to usb to migrate a desktop to another machine ? medium would likely be usb since it's portable. I'm really thinking of something aimed at a newby ubuntu user
[08:41] <persia_ume> bain: Hmmm...  I suspect you're looking for something based on sbackup or hubackup, but I'm not sure.
[08:49] <jscinoz_> Is it planned to migrate to Grub2 at some point?
[08:49] <jscinoz_> as the default bootloader
[09:33]  * pitti takes a stab at the xargs b0rkage in intrepid
[10:03] <stgraber> pitti: where are you ? :) I don't see you at the 3rd floor (or you are behind me)
[10:03] <pitti> stgraber: I'm in my room; is there wifi still?
[10:03] <stgraber> yep
[10:04] <stgraber> I guess we are like 20 here using the fosscamp wifi, it's still really fast and working just fine
[10:06] <pitti> coming down then
[10:44] <pitti> StevenK: I shouldn't have said it so loud ... http://launchpadlibrarian.net/14584191/buildlog_ubuntu-intrepid-i386.findutils_4.4.0-2ubuntu2_CHROOTWAIT.txt.gz
[10:45] <pitti> infinity: so, my new upload of findutils to fix the xargs b0rkage doesn't build, because it fails with that very xargs crash; that requires some manual building, I figure?
[10:48] <pitti> lamont: ^
[11:01] <kahrytan> What is being done to prevent what happened with SSH keys  in debian/ubuntu to never happen again?
[11:02] <jdavies> !libsslbug > kahrytan
[11:02] <pitti> kahrytan: that's one of the bad things in the world, you can only defend against catastrophes that already happened; but there are infinitely many more ways to break something
[11:03] <pitti> kahrytan: but this certainly helped to raise awareness and caution a lot
[11:03] <kahrytan> Was that package only managed by 1 person?
[11:05] <pitti> two at the moment
[11:05] <kahrytan> At the time of issue?
[11:06] <RAOF> tjaalton: You were the person interested in putting nouveau into experimental, right?  I'm currently playing around with module-assistant-ing the drm modules, which may make that easier/possible.
[11:06] <kahrytan> This just proves that two or more people needs to over see code before it comes mainstream.
[11:06] <tjaalton> RAOF: right, it was discussed recently on debian-x@
[11:07] <RAOF> tjaalton: Ah.  I'm obviously not subscribed to that; is there a one line summary?
[11:07] <tjaalton> RAOF: "hard" :)
[11:08] <tjaalton> to maintain, at least
[11:08] <RAOF> Right.  Because you sometimes need new snapshots of libdrm for new snapshots of nouveau.
[11:08] <tjaalton> yep..
[11:08] <RAOF> And you want to keep reasonably current with nouveau, so...
[11:09] <RAOF> Well, after I've tested this, it'll be possible to point debian people at my source packages, at least.
[11:09] <tjaalton> there really ought to be a new libdrm release soon, since X 7.4 basically can't release without it
[11:09] <RAOF> Oh, DRI2.
[11:09] <tjaalton> right
[11:10] <tjaalton> unless they demote it as experimental
[11:10] <kahrytan> pitti,  The funny thing about this.. this was one my parents worest fears about linux. What is stopping coders from putting backdoors/security holes in code?
[11:10] <pitti> kahrytan: that's not a linux specific problem
[11:10] <RAOF> tjaalton: By 'they', you mean Debian-X?  Or upstream?
[11:11] <kahrytan> pitti,  but it's easier to do for a hacker in oss.
[11:11] <soren> kahrytan: Err? Why?
[11:11] <pitti> kahrytan: there was one such case in Debian that I faintly remember, and it was discovered pretty fast and the code got a big audit
[11:11] <ivoks> kahrytan: how? other hackers could check source
[11:11] <kahrytan> pitti,  Yet, ths ssh one didnt get discovered for awhile
[11:11] <ivoks> kahrytan: that's much easier to do in closed source; no one but you could check the source
[11:11] <tjaalton> RAOF: upstream
[11:11] <pitti> kahrytan: no, you can't "just do" it, you need to earn credibility and permissions first
[11:12] <soren> kahrytan: If there's a backdoor in a closed source product, noone will discover it. In free software, eventually someone will discover it.
[11:12] <ivoks> kahrytan: do you know how many of those are in closed source world? :)
[11:12] <RAOF> tjaalton: That would suck.  DRI2 brings world peace.  It'd be nice to have in Intrepid :)
[11:12] <kahrytan> ivoks,  How many people work for close source developer?
[11:12] <ivoks> kahrytan: a lot less than on open source
[11:13] <virtuald> were the other vulns in that dsa from debian or wideopenbsd?
[11:13] <kahrytan> I just know if this happens again, it will hurt OSS more then anyone realizes.
[11:13] <tjaalton> RAOF: yeah..
[11:14] <ivoks> kahrytan: it might seem like that, yes... but you have to wonder... are you sure this kind of thing never happend anywhere else?
[11:14] <pitti> kahrytan: I'm undecided on that; on the one hand it proves transparency, on the other hand you always lose a big chunk of trust on those
[11:14] <ivoks> we aren't silent about our problems, closed source vendor are
[11:14] <kahrytan> ivoks,  On the one hand,  It didnt take long to fix it.  M$ would have waited til patch Tues.
[11:14] <ivoks> kahrytan: MS wouldn't patch that at all
[11:15] <pitti> closed source devs aren't invincible against making stupid errors either, we are all just humans
[11:15] <ivoks> at least, not the way we did
[11:15] <kahrytan> They would patch it but not tell anyone
[11:15] <virtuald> how do you define aren't silent?
[11:15] <pitti> under that assumption, the OS/CS quality wrt. to those incidents doesn't make much of a difference
[11:15] <virtuald> In addition to this critical change, two other vulnerabilities have been fixed in the openssl package which were originally scheduled for release with the next etch point release: OpenSSL's DTLS (Datagram TLS, basically "SSL over UDP") implementation did not actually implement the DTLS specification, but a potentially much weaker protocol, and contained a vulnerability permitting arbitrary code execution (CVE-2007-4995). A side channel attack i
[11:15] <ivoks> kahrytan: yes, and leave vul. key to work
[11:16] <kahrytan> ivoks, I hope Debian community something from this.
[11:16] <ivoks> virtuald: we exposed the problem, made a patch and made those vul. keys unusable
[11:16] <kahrytan> *learned something
[11:16] <ivoks> ms would probably do all of that, except making vul keys unusable
[11:16] <ivoks> cause that would produce a lot bad publicity
[11:17] <ivoks> ...a lof of bad...
[11:17] <pitti> ivoks: that's pure speculation, though
[11:17] <kahrytan> How is Ibex progressing?
[11:17] <ivoks> pitti: of course...
[11:17] <virtuald> :>
[11:18] <ivoks> kahrytan: smart people learn while they live...
[11:18] <kahrytan> ivoks,  and the idiot people ...?
[11:18] <ivoks> kahrytan: stop learning when they finish their school
[11:19] <kahrytan> ivoks,   Smart people learn while they live, avg people forget what they learned, and idiot people dont bother to learn.
[11:19] <kahrytan> but i dont mean it
[11:20] <ivoks> pitti: anyway... i found out where the problem was with pgsql; pebkac :/
[11:21] <kahrytan> Has anyone bother to make Ubuntu Installer import existing preferences on an existing install?
[11:21] <tjaalton> kahrytan: debconf-get-selections --installer > foo
[11:21] <kahrytan> Thats nice. Now does Ubuntu installer do it automatically?
[11:21] <ivoks> this, of course, isn't support channel
[11:22] <pitti>  kahrytan: we also have this "migration assistant" in the installer which keeps some settings (or the partitioner keeping your /home dir)
[11:22] <kahrytan> ivoks,  just showing some feature seeds. :-P
[11:22] <ivoks> pitti: right, it can even import your windows settings :)
[11:22] <kahrytan> pitti,  You mean the migration assistant for windows prefs?
[11:23] <kahrytan> The same assistant that failed to work in Ubuntu 8.04?
[11:23] <ivoks> kahrytan: file a bug
[11:23] <pitti> kahrytan: it also imports Firefox/Pidgin from Linux installs
[11:23] <pitti> but I haven't used it much, I just keep my /home forever
[11:24] <kahrytan> It's supposed to do that import from prev installs?
[11:24] <pitti> you can tell it to
[11:24] <kahrytan> Wouldnt know how to.
[11:25] <kahrytan> I just thought no one tried to add it since either of install screens asked about it.
[11:40] <evand> It's not shown if it cannot do anything, such as when you're overwriting the partition in question.
[11:41] <evand> err, the partition that you would be importing from.
[12:57] <Samsemilia> ,seen mvo
[12:58] <Samsemilia> !seen mvo
[12:59] <Hobbsee>  /msg seenserv seen mvo...
[13:03] <Keybuk> Preparing to replace debconf 1.5.20 (using .../debconf_1.5.21_all.deb) ...
[13:03] <Keybuk> xargs: xargs.c:443: main: Assertion `bc_ctl.arg_max <= (131072-2048)' failed.
[13:03] <Keybuk> EPIC.
[13:03] <Keybuk> FAIL.
[13:04] <TheMuso> eh
[15:33] <lamont> pitti: that or an upload that builds without needing xargs...
[16:40] <pitti> lamont: that's hard, since debconf is already in the chroot, and it fails to upgrade; there's no way how to fix it with dropping build deps
[16:41] <pitti> lamont: I guess one would need to download the chroot, hit debconf over the head to install properly, save it, and upload it back?
[17:00] <lamont> pitti: ew
[17:29] <amitk> Keybuk: https://edge.launchpad.net/~kernel-ppa/+archive
[17:32] <Keybuk> amitk: ah, thanks
[17:32]  * Keybuk kills the heater
[17:56] <infinity> pitti: Probably, yeah.
[18:43] <dondelelcaro> hey; is there a UDS specific channel?
[18:49] <KristianL> yeah, #ubuntu-devel-summit
[18:52] <dondelelcaro> ah, thanks
[20:04] <emgent`UDS> heya
[20:25] <pitti> hey emgent
[20:28] <emgent> hey pitti :)
[20:28] <emgent> fosscamp AP r0cks!