[00:39] <Cyber-Kun> yO
[00:39] <Cyber-Kun> Damn it.
=== bryyce is now known as bwh
[01:12] <bwh> o_O ?  The following packages have unmet dependencies:
[01:12] <bwh>   xserver-xorg-video-nouveau: Depends: xserver-xorg-core (>= 2:1.6.2) but it is not going to be installed
[01:34] <LLStarks> bryce. you're never around when i need you.
[01:34] <LLStarks> anyone here?
=== bwh is now known as bryceh
[02:04] <LLStarks> bryceh, sup.
[02:14]  * bryceh waves
[02:14] <LLStarks> bryceh, did you get my pm about vbe blanking and unblanking?
[02:15] <bryceh> nope
[02:15] <LLStarks> https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/496842
[02:15] <ubottu> Ubuntu bug 496842 in gnome-power-manager "gpm lacks proper vbetool blanking and unblanking" [Undecided,Confirmed]
[02:15] <LLStarks> this problem was present in karmic and is still present in lucid.
[02:16] <bryceh> do you have a patch?
[02:16] <LLStarks> nope.
[02:16] <LLStarks> sorry.
[02:16] <LLStarks> with the semester starting, this bug will piss me off continually.
[02:17] <LLStarks> if i close my lid, i have to reboot.
[02:17] <LLStarks> it's a system-crippling bug.
[02:17] <LLStarks> unless you can access a terminal and do a manual vbetool unblank without a working display
[02:21] <LLStarks> bryceh, what i would like to know is if there is any additional information that bug report might need that would aid in it getting fixed.
[02:21] <LLStarks> i'd be happy to provide.
[02:27] <bryceh> well one problem is you've stated a solution rather than a problem
[02:27] <LLStarks> i question it's viability as a solution.
[02:28] <LLStarks> unblanking is still spotty with that code snippet
[02:28] <bryceh> I don't think you care whether gpm has vbetool blanking, if there was some other fix that solved your issue you'd be happy with that
[02:28] <bryceh> so first fix the title
[02:28] <bryceh> secondly, you've filed it against gpm but who knows if it's actually a bug in gpm.  could be (likely) a kernel bug
[02:28] <LLStarks> "Ubuntu lacks proper vbetool blanking and unblanking"?
[02:29] <bryceh> I am guessing since you are here in the X channel you also wonder if X might be involved (maybe, although most blanking bugs end up needing kernel fixes in my experience).  Anyway, whenever you think X may be involved, attach all the usual X debug files
[02:30] <LLStarks> Xorg.0.log and what else?
[02:31] <bryceh> LLStarks, you're thinking too much there - state the nature of the problem.  "Inspiron 640m won't unblank after a lid close unless dpms is turned off
[02:31] <bryceh> LLStarks, wiki.ubuntu.com/X/Reporting
[02:31] <bryceh> LLStarks, or use apport
[02:31] <bryceh> (man apport)
[02:31] <LLStarks> heh. i can do x collection.
[02:32] <LLStarks> how convenient
[02:32] <bryceh> probably you should talk to ogasawara or one of the kernel team people, they're the ones with expertise on debugging lid close bugs
[02:32] <bryceh> -> #ubuntu-kernel
[02:32] <bryceh> and you should at least test with a lucid livecd; few developers will bother looking at your bug until they know it also exists on lucid, since that's what they're working on.
[02:36] <LLStarks> i have confirmed it on a fresh alpha 2
[02:36] <LLStarks> live environment included
[02:37] <LLStarks> also afflicts lucid with latest packages or with xorg-edgers
=== jldugger is now known as pwnguin
[07:27] <RaiN88> Hi everyone, I had thist problem: 
[07:27] <RaiN88> When I click restart, then my laptop process to restart and flikering lines appears (Flikering Lines also appears when I Shut Down before it's totally Turn Off.), but when it should be restarted it just stay's there with Blank black screen, ready to reboot but it wont.Then I have to actually hold the power button in to shut it off and boot it again. It is so very annoying. Laptop : Asus X80n, 1GB RAM, 160GB HDD, Nvidia Geforce 700m = 256mb, Ubuntu 9.10 fu
[07:27] <RaiN88> lly updated. I hope you can able to help me solve this problem. Kind regards, and thanks in advance,
=== ripps_ is now known as ripps
[08:01] <vish> hmm , if anyone wants to have a look at the aboe problem the user wrongly filed the bug in irc bots >  https://bugs.launchpad.net/ubuntu-bots/+bug/513056
[08:01] <ubottu> Ubuntu bug 513056 in ubuntu-bots "Won't Restart" [Undecided,Invalid]
[09:57] <knittl> do i have to blacklist any modules to make standby work with nvidia cards?
[09:57] <knittl> i tried nvagp in xorg conf and blacklisted agpgart and amd64_agp, but my pc still won't wake up properly
[09:59] <RAOF> knittl: What driver are you using?
[10:00] <knittl> nvidia-current
[10:00] <knittl> when waking up i only see colorful squares on my screen
[10:01] <knittl> my laptop stays responsive, i can even kill x with ctrl-alt-x
[10:01] <knittl> but that's not a real solution …
[10:01] <knittl> * ctrl-alt-backspace
[10:04] <RAOF> Hm.  I dunno.
[10:04] <knittl> i'm also willing to troubleshoot, if i only knew how
[10:05] <RAOF> If it were nv I'd be able to say “yes, that's expected”, but it's pretty easy to tell if you're not using the binary blob - you don't get 3d :)
[10:05] <knittl> no, it's nvidia-current
[10:09] <RAOF> Has this worked on any prior Ubuntu release?
[10:09] <knittl> yes
[10:09] <knittl> oh
[10:10] <knittl> i'm talking about lucid here
[10:10] <knittl> the problem exists since i upgraded to lucid
[10:10] <RAOF> Yeah, I could tell - you're using nvidia-current, which only exists in Lucid :)
[10:10] <knittl> thought i'd mention it anyway, in case you didn't notice ;)
[10:11] <RAOF> I don't think I know of anyone else having this problem; it might be a bug in the new nvidia driver?
[10:12] <knittl> i searched for the problem, and didn't find any similar reports for lucid yet
[10:12] <knittl> so yes, it might only be me …
[10:12] <RAOF> The binary drivers are always a bit... fun.
[10:13] <RAOF> Fine when they work... :)
[10:13] <knittl> yup :D
[10:13] <knittl> my "only" problem is, that the screen doesn't come back after standby
[10:13] <knittl> everything else works
[10:13] <knittl> so maybe it's a problem with re-initializing?
[10:13] <RAOF> Why don't you pastebin the output of lsmod; maybe I'll see something obviously wrong.
[10:14] <knittl> http://paste2.org/p/635105
[10:14] <RAOF> That would seem to be the obvious candidate for problems, yeah.
[10:14] <knittl> agpgart and amd64_agp are blacklisted, nvagp is set to 1 in xorg
[10:15] <RAOF> You know, I wonder if vga16fb could have anything to do with this.
[10:16] <knittl> dunno
[10:17] <RAOF> Feel like trying a little experiment?  Move the vga16fb module out of /lib/modules/$KERNEL and rebuild your initramfs; then reboot.
[10:17] <knittl> why not blacklist it?
[10:17] <knittl> and yes, i feel like experimenting :)
[10:18] <knittl> gotta go home now from university, bb in a few minutes, then i'll try and tell the results
[10:18] <RAOF> knittl: You could blacklist it, but I'm not sure if the blacklist makes it into the initramfs; the framebuffer is loaded pretty early.
[10:19] <knittl> ok, i'll move it then
[10:31] <knittl> RAOF: i can't see the file in /lib/modules
[10:32] <knittl> i did a find -name '*vba16fb*' and no results
[10:32] <jcristau> vga, not vba
[10:35] <knittl> wops
[10:36] <knittl> ok, rebooting
[10:36] <knittl> no wait
[10:36] <knittl> what about nvagp and blacklisted modules?
[10:36] <knittl> agpgart and amd64_agp respectively
[10:40] <RAOF> If you didn't blacklist them before Lucid, don't worry about them.
[10:40] <RAOF> IIRC, loading vga16fb is something new in Lucid (to support plymouth, I think).
[10:43] <knittl> ok, then i'll remove the blacklist stuff
[10:43]  * knittl reboots
[10:44] <RAOF> It won't hurt t ohave them blacklisted (although given that you've got intel_agp loaded, blacklisting amd64_agp probably won't do anything :))
[10:52] <tseliot> RAOF: right that's exactly why we have vga16fb
[10:53] <knittl> i can resume from standby
[10:53] <knittl> but it does not work 100 %
[10:53] <knittl> i have to turn the screen on with one of the fn-keys (crt/lcd or widescreen/4:3)
[10:54] <knittl> and my desktop wallpaper is cyan, instead of a beautiful red flower
[11:02] <fmarl> knittl, do the same thing to vgastate.ko
[11:03] <fmarl> I'm doing this while testing the nouveau driver.
[11:04] <knittl> okaydokay
[11:06] <knittl> then rebooting another time :)
[11:07] <RAOF> fmarl: Nouveau isn't providing its own framebuffer driver for you?
[11:09] <RAOF> We'll be getting 2.6.33's nouveau kernel stack in linux-backport-modules soon; it's time for me to update the DDX & make noises about nouveau-firmware.
[11:13] <fmarl> RAOF, nouveau provide its nice framebuffer but these two drivers break nouveau badly
[11:14] <jcristau> does vgastate get autoloaded?  i'd expect it to only get loaded as a dependency for another module
[11:15] <fmarl> jcristau, yep, vga16fb load vgastate (?)
[11:18] <jcristau> right so blacklisting vga16fb should be enough
[11:20] <RAOF> Why is vga16fb getting loaded?
[11:20] <RAOF> It doesn't for me.
[11:22] <RAOF> Where are you getting nouveau from?
[11:22]  * RAOF is fairly sure that the xorg-egders nouveau should be adding an initramfs hook that'll get nouveau up and running before it attempts to load vga16fb
[11:26] <fmarl> RAOF, I'm not using the packages, compiling from source.
[11:29] <knittl> still no luck
[11:29] <knittl> removing both modules seem to work the least
[11:32] <knittl> with only vga16fb disabled my cpu goes crazy when fading the screen out before the screensaver activates
[11:32] <RAOF> fmarl: Ah.  Ensuring nouveau.ko is in your initramfs should make vga16fb go away.
[11:37]  * hyperair wonders if those strange GPU-switching notebooks are supported on linux.
[11:42] <RAOF> I seem to recall mjg poking at the ACPI tables required to switch.
[11:42] <hyperair> =O
[11:43] <hyperair> but does X support such a thing?
[11:44] <RAOF> Maybe not.
[11:44] <RAOF> I dunno; I'd guess the macbook nvidia/nvidia switch could fly.
[11:47] <hyperair> hmm
[11:49] <RAOF> That's probably easier than the intel/nvidia combos some laptops have.
[11:51] <tseliot> no, X doesn't support that yet
[12:59] <vish> ... i'm noticing this repeat error in the gdm log files> http://paste.ubuntu.com/363843/ there are two files now nearly 2.7GB in size with those errors.. 
[13:00] <vish> seems to have started somewhere around the 19/20th , probably with updates xserver-xorg-core (2:1.7.3.902-1ubuntu8) to 2:1.7.3.902-1ubuntu9 ???
=== ara_ is now known as ara
[13:03] <vish> xorg logs show nothing of the sort :s
[13:44] <tseliot> vish: it looks more like radeon issue to me i.e. xserver-xorg-video-ati
[13:46] <vish> tseliot: hmm , but last xserver-xorg-video-ati update was around 12th.. this seems to be since somewhere around the 19/20... earlier gdm logs are clean
[13:47] <jcristau> did you restart X in the mean time?  and used Xv?
[13:48] <vish> X has been running for 6days .. just now restarted the system
[14:10] <tseliot> vish: I can't reproduce the problem here (but I'm using r600 instead of r500). Does the X log say anything interesting?
[14:12]  * vish checks
[14:18] <vish> tseliot: i dont think there is any mention  ,  Xorg.log>  http://paste.ubuntu.com/363891/ , Xorg.1.log> http://paste.ubuntu.com/363889/
[14:19] <vish> it maybe something from the time i used , gnome-shell? [i think i was using it during that time]
[14:19] <tseliot> (EE) RADEON(0): Kernel modesetting setup failed
[14:20] <tseliot> the other file looks good though
[14:20] <tseliot> vish: maybe dmesg can help^
[14:25] <vish> tseliot: dmesg.0.log >  http://paste.ubuntu.com/363897/  , not sure if it is the same time frame though
[14:29] <tseliot> there's nothing wrong in it
[14:29]  * vish digs into older dmesg
[14:40] <vish> tseliot: what should i be looking out for in the dmesg? [things got a little dizzy here :s]
[14:40] <tseliot> vish: errors ;) ?
[14:41] <vish> ;)
[14:41] <tseliot> vish: BTW in what log did you find those weird errors about textured video?
[14:42] <vish> tseliot: gdm logs > /var/log/gdm/:0.log [was 2gb, just deleted right now] , /var/log/gdm/:0.log.3
[14:44] <tseliot> vish: so it was the X log. Weird...
[14:45] <vish> yeah.. i'v restarted the session , log seems quiet .. will check if it kicks in again
[14:52] <vish> tseliot: hmm , i also was earlier having this gdm related X error > Bug #506510  where X kept crashing... anyways , will try to notice when it starts again
[14:52] <ubottu> Launchpad bug 506510 in xorg-server "Xorg crashed with SIGSEGV in FatalError() when using guest session" [High,Fix released] https://launchpad.net/bugs/506510
[14:52]  * vish hasnt tried guest session for a couple of days due to those errors 
[14:53] <tseliot> vish: maybe try booting without the "splash" parameter
[14:54] <vish> ok.. will do that in a few
=== yofel_ is now known as yofel
[19:34] <Sarvatt> where is this nouveau kernel at? whats the versioning on it? want a xserver-xorg-video-nouveau with nouveau-kernel-source | linux-image-2.6.32-x dependency? libdrm needs a few commits past 2.4.17 to work with the current ddx also. was just nouveau added or did they pull in all of drm-core-next that'll mess with radeon as well (r600+ wont work without additional firmware if so)?
[19:36] <bryceh> hi sarvatt
[19:36] <Sarvatt> heyo!
[19:37] <bryceh> Sarvatt, apw made me a backports module thingee for us
[19:37] <bryceh> I'm using the -nouveau &tc. from edgers
[19:38] <bryceh> although I booted and the screen's scrambled so something's still not right
[19:38] <apw> bryceh, whats with the rotating nicks?
[19:38] <Sarvatt> that ddx brings nouveau-kernel-source in with it and overwrites the other though
[19:38] <apw> bryceh, hows the testing with that ?
[19:38] <Sarvatt> (just something to watch out for)
[19:38] <bryceh> apw, eh, I lost 'bryce' over the holidays so am trying out a new nick
[19:39] <bryceh> Sarvatt, yeah that's what I suspect
[19:39] <apw> lost it?  someone else stole it?  annoying
[19:39] <jbarnes> bryceh: why don't you register with nickserv?
[19:39] <bryceh> apw, do I need to do anything special to get your backport nouveau module loaded?
[19:39] <bryceh> jbarnes, actually I did
[19:39] <bryceh> jbarnes, so I'm not sure why the nick got taken.  very frustrating.
[19:40] <jbarnes> bryceh: lame
[19:40] <tseliot> bryceh: you can recover your username then
[19:40] <apw> those who have the h/w have said they had to blacklist nv
[19:40] <bryceh> apw, ah
[19:40] <Sarvatt> purge all the nouveau stuff, grab the xserver-xorg-video-nouveau source, install libdrm from edgers, change the nouveau-kernel-source dep to whatever the backport thingy is called from the ddx and rebuild and reinstall the backport would work
[19:41] <tseliot> bryceh: http://docs.dal.net/docs/nickserv.html#4.2
[19:41] <Sarvatt> backports isnt installed by default though, what does it gain doing it that way over just keeping nouveau-kernel-source?
[19:43] <bryceh> tseliot, doesn't appear to work
[19:43] <bryceh> tseliot, just get "invalid command"
[19:44] <bryceh> Sarvatt, btw here's apw's ppa with the nouveau stuff https://edge.launchpad.net/~apw/+archive/blue/+packages
[19:45] <tseliot> bryceh: try with "/msg NickServ" command
[19:45] <tseliot> instead of "/nickserv" command
[19:46] <bryceh> tseliot, same thing
[19:46] <tseliot> weird
[19:50] <bryceh> I like 'bryyce' but got no end of questions about it.  bwh seems logical but no one would guess that to be me (not sure yet if that's a pro or a con). 
[19:51] <tseliot> bryceh: this is what freenode says: "if you don't sign onto the network for at least 60 days, or you don't identify to nickserv for at least 60 days, the nick is considered expired"
[19:51] <jcristau> bwh is one of the debian kernel guys on oftc :)
[19:51] <bryceh> jcristau, great...
[19:51] <tseliot> bryceh: and I don't think I've ever seen you far from irc for so long
[19:52] <tseliot> bryceh: therefore maybe you simply have to use the "ghost" command?
[19:52] <tseliot> i.e. "/nickserv ghost nickname [password]"
[19:53] <tseliot> and then just identify as usual
[19:53] <tseliot> (after changing your nick)
=== bryceh is now known as bryce
[19:54] <tseliot> :-)
[19:54] <tseliot> bryce: was it the ghost command?
[19:55] <bryce> no
[19:55] <tseliot> hmm
=== bryce is now known as bryceh
[19:56] <bryceh> what's annoying is that you can't change your password back if you're logged into registered channels.
[19:57] <bryceh> feh, anyway, freenode is annoying.
[19:57] <tseliot> ;)
[21:31] <RAOF> apw: Thanks for the nouveau kernel PPA.
[21:32] <RAOF> Sarvatt: l-b-m means we get to build the package, rather than have it built locally.  That bypasses a bunch of possible bugs.
[21:38] <Sarvatt> oh good point, didn't think about that. what to do about the firmware is the next question then
[21:39] <RAOF> Yes.
[21:40] <RAOF> I'm not really sure what to do about it, really.
[21:44] <RAOF> We've (implicitly) had that firmware in the repository for a couple of releases, now.
[22:00] <Sarvatt> another pro for lucid+1, firmware wouldnt be needed by then most likely :D
[22:02] <RAOF> If we really wanted to we could not need firmware for < geforce9 cards.
[22:12] <Sarvatt> ya mean < geforce 8xxx?
[22:13] <RAOF> No; the 2.6.33 code already has voodoo generators for < geforce8; if we wanted to, we could pull in the ctxprog generators for geforce8 and a bunch of nvAx cards that (mostly?) work :)
[22:20] <bryceh> heya RAOF
[22:20] <RAOF> Howdie bryceh.
[22:20] <RAOF> Sexy “h” you've got there ;)
[22:21] <bryceh> heh
[22:21] <bryceh> like it better than my yy's?
[22:22] <RAOF> yys have a certain charm, too.
[22:22] <bryceh> anyway, so what's our next step for nouveau?  are there changes needed to the xorg-edgers ddx bits to get them to load on top of apw's kernel bits?
[22:23] <RAOF> There are, yes.  We basically need to not depend on nouveau-kernel-source anymore.
[22:23] <RAOF> I'll prepare an update to the DDX in the archives & upload that to the xorg-edgers PPA.
[22:24] <RAOF> We also need to work out what to do about the ctxprogs/ctxvals firmware-like stuff.
[22:24] <RAOF> Writing the debian/copyright for that package will be... interesting.
[22:26] <bryceh> heh
[22:26] <bryceh> RAOF, ok I stand ready to test.  Are there other things I can do to help you right now?
[22:27] <jcristau> 'this stuff is copyright nvidia.  we may have the right to distribute it.  or not.  maybe.'
[22:27] <jcristau> archive admins would love it
[22:27] <bryceh> what's the license on it?  is it at least distributable?
[22:27] <RAOF> jcristau: We're not even sure if it actually _is_ copyright nvidia; it's not necessarily copyrightable.
[22:28] <RAOF> bryceh: There is no licence on it; it's been extracted from mmio traces of how the binary driver prods the cards.
[22:29] <bryceh> hmn
[22:30] <bryceh> kees, thoughts on the last ~10 lines in the backlog?
[22:31] <RAOF> It's also possible to programatically generate the voodoo; 2.6.33 includes a generator for nv4x cards, and there's a guy who's got a mostly-working generator for nv5x+.
[22:32] <bryceh> that sounds like more the way to go
[22:32] <bryceh> I've added a todo to doublecheck on the licensing
[22:33] <RAOF> Absolutely.  That's the way it is going, but I don't know if it'll be ready for Lucid.
=== RAOF is now known as RAOF_
[22:34] <bryceh> ok, I've noted to bring it up as an issue when I meet with the kernel team next week
[22:35] <kees> bryceh: where does the firmware exist normally?  on the chip?
[22:35] <kees> bryceh: or do windows drivers load it?
[22:35] <kees> why do we need to ship firmware, I guess is my question?
=== RAOF_ is now known as RAOF
[22:36] <bryceh> kees, I assume it's loaded from the hw.  RAOF?
[22:36] <bryceh> <kees> bryceh: where does the firmware exist normally?  on the chip?
[22:36] <bryceh>  bryceh: or do windows drivers load it?
[22:36] <bryceh> <kees> why do we need to ship firmware, I guess is my question?
[22:36] <bryceh> RAOF ^
[22:36] <RAOF> It's actually a program to make hardware context switching work.
[22:36] <RAOF> Without the context switching you lose all acceleration, but nouveau will work.
[22:37] <kees> so where did it come from originally?
[22:37] <RAOF> From watching what the binary driver does to the card when it brings it up.
[22:37] <bryceh> kees, reverse engineered from the -nvidia driver using a capture tool
[22:37] <RAOF> It's lifted from the mmio traces of the binary driver initialising the card.
[22:39] <RAOF> We *can* ship without it, and we'll still get KMS out of nouveau, but a totally unaccelerated driver is hella slow.
[22:40] <kees> okay, so the code representing the firmware lives in the proprietary driver?
[22:40] <kees> then it should have the same redistribution rules as the driver itself.
[22:40] <kees> (in the worst case)
[22:41] <RAOF> Actually, we think that the code represeting the firmware *generator* lives in the proprietary driver, but apart from that, yeah.
[22:42] <bjsnider> RAOF, you talkin' about the nouveau microcode?
[22:43] <RAOF> Yes.
[22:43] <bjsnider> i thought they wrote new microcode
[22:44] <RAOF> I haven't checked their git logs in the last week or so, but last I checked they didn't have a voodoo generator that'd drive cards newer than geforce8
[22:48] <RAOF> Yeah.  Unless they've sneaked it in under a strange commit log message there still isn't a ctxprog generator for nv5x+ in their kernel tree.
[22:49] <bjsnider> my thinking is that if it's pushed out and enough people use it, nvidia couldn't really do anything to stop it
[22:49] <RAOF> Whatever give you that idea?
[22:49] <RAOF> s/give/gives/g
[22:49] <bjsnider> after some period of time the cat would be out of the bag
[22:50] <RAOF> As I understand it, copyright isn't like trademarks - you don't lose it because you haven't sued the pants of infringers yet.
[22:50] <RAOF> They could quite happily stop us from distributing it.
[22:51] <bjsnider> but who would you take legal action against, and how much would it cost, and how long would it take to win,a nd what would be the aftereffects of winning, ie. bad realtionship with redhat, linus, linux community etc.
[22:53] <RAOF> You'd take legal action against Canonical; after all, they'd be distributing your stuff without a license.  But we don't distribute things that we don't have a license to distribute.
[22:53] <bjsnider> fedora is
[22:53] <bjsnider> which is red hat
[22:53] <bjsnider> does nvidia really want a contentious relationship with red hat?
[22:57] <RAOF> You're right that nvidia probably doesn't care (now).  Still, we don't ship things because we don't think we'll get sued over them; we ship things that we've got a clear license to ship.
[22:58] <bjsnider> well, red hat obviously has more confidence that nvidia won't bother them about it
[22:59] <RAOF> We're more strict about licensing than RH :)
[22:59] <jcristau> or they have confidence that they can remove stuff from fedora easily if nvidia asks
[22:59] <jcristau> it's not like they're shipping that stuff in rhel
[22:59] <RAOF> Right.
[22:59] <bjsnider> no, but they're responsible for fedora
[23:00] <bjsnider> hasn't anybody asked nvidia about this?
[23:00] <jcristau> pretty sure a c&d from nvidia is all it would take for fedora to drop that stuff
[23:00] <bryceh> do you guys want me to approach nvidia about it?
[23:01] <bjsnider> yeah but hasn't somebody already approached them?
[23:01] <bjsnider> this is what airlie and the rest of them said was blocking it from going into the kernel
[23:01] <RAOF> A statement from nvidia would make the status of the firmware-ish stuff clearer.
[23:02] <jcristau> it involves lawyers, which usually means it takes some time
[23:02] <RAOF> If it's easy to ask, sure.
[23:02] <bryceh> alright, I'll add this to my todo list as well, but will wait to do it until after I've spoken with the kernel team
[23:03] <bjsnider> could someone approach adobe about distributing the amd64 flash alpha? or tell me who to talk to?
[23:03] <bryceh> bjsnider, kees might be able to answer that one
[23:04] <bryceh> RAOF, ok, so leaving aside the blob licensing, anything else I can help with?
[23:05] <RAOF> bryceh: I don't think so, until it comes time to move stuff to main.
[23:05] <RAOF> bryceh: If I run into something I'll give you a ping.
[23:05] <bryceh> RAOF, okie great
[23:10] <kees> bjsnider: you need to convince asac
[23:11] <bjsnider> convince him to what?
[23:11] <bjsnider> talk to adobe?
[23:11] <kees> use the 64bit flash
[23:11] <bjsnider> no, you misunderstand
[23:11] <kees> ah, sorry.  what did you mean?
[23:12] <bjsnider> i just need approval to distribute it as a package in a ppa, not in the main archive
[23:12] <bjsnider> i need to know that adobe isn't going to send goons after me
[23:13] <kees> avoid it by downloading it from adobe; that's what I do with my flashplugin-nonfree in my PPA that uses the 64bit flash plugin.
[23:14] <bjsnider> you mean it's 100% ok to distribute it as long as the package downloads the plugin from adobe's website?
[23:14] <jcristau> if the package downloads stuff from adobe, you're not distributing the plugin
[23:17] <bjsnider> kees, how does yours work? i suspect it's practically the same as mine
[23:17] <bryceh> bjsnider, I've been running his on my 64-bit system and it works acceptably well
[23:18] <bryceh> I think it gets tripped up by pulseaudio sometimes, but restarting firefox seems to be enough to make it sane again
[23:18] <bryceh> also, frequently after doing a system upgrade I have to reinstall kees' package.  Probably don't have it pinned right or something.
[23:19] <kees> bjsnider: https://edge.launchpad.net/~kees/+archive/ppa/+packages
[23:20] <bjsnider> i found it earlier
[23:20] <bjsnider> but i designed one myself awhile back
[23:20] <kees> cool
[23:20] <bjsnider> it cuts out nspluginwrapper and uses the alpha
[23:20] <bjsnider> so i wondered if that's what you've done here
[23:22] <kees> yeah, I really don't like nspluginwrapper