[10:47] <edgy> HI, cannot install nvidia-current $ apt-cache policy nvidia-settings nvidia-current |grep Candidate
[10:47] <edgy>   Candidate: 295.33-0ubuntu1
[10:47] <edgy>   Candidate: 302.17-0ubuntu1
[10:47] <edgy> is this a known bug?
[12:32] <BluesKaj> Hey all
[12:32] <penguin42> Hi BK
[12:46] <BluesKaj> hey penguin42
[12:48] <BluesKaj> got black/blank screen here for 10secs or so, after grub and before the login scrn. I haven't seen that before.
[12:51] <penguin42> ah, same as I was saying yesterday?
[12:52] <penguin42> my bug 1019579
[13:25] <penguin42> Wah! Synergy broke again
[14:13] <lupintheethird> Is there anything I need to do other than apt-get upgrade to go from 12.10 alpha 1 to 2
[14:13] <penguin42> nope
[14:13] <penguin42> well, dist-upgrade is normally best
[14:14] <lupintheethird> okay ill give it a shot quick and make sure
[14:14] <lupintheethird> says command not found?
[14:14] <penguin42> just keep it upto date like you would a normal system and it should pick most things up; although sometimes if something was broken by a previous version it may need some hand holding - apt-get dist-upgrade
[14:15] <lupintheethird> alright appreciate it, are you getting a few packages that refuse to install and are grayed out?
[14:15] <lupintheethird> The following packages have been kept back:
[14:15] <lupintheethird>   nvidia-current nvidia-current-updates update-notifier update-notifier-common
[14:15] <lupintheethird>   winetricks
[14:37] <IdleOne> I have 165+ 5 new packages waiting to be installed. What concerns me here is that nvidia-current is going to be removed, not sure what to do. Will removing nvidia-current mean I'll be left with no way to access GUI?
[14:38] <IdleOne> Ah, hell with it. jumping in head long
[14:38] <IdleOne> Will see what's in the deep end :)
[14:40]  * penguin42 hands IdleOne a snorkel
[14:41] <IdleOne> heh, this is not a good sign :)
[14:41] <IdleOne> penguin42: I have faith that the universe will provide.
[14:43] <penguin42> IdleOne: I knew there had to be an optimist somewhere
[14:44] <BluesKaj> IdleOne, I had the same dilemma yesterday , it all woked out except for the 10-15 sec delay between grub and the login now
[14:45] <IdleOne> if it is only an added 10-15 secs bootup. I can live with it
[14:46] <IdleOne> Think I should try a reboot and see what happens?
[14:50] <BluesKaj> IdleOne, nvidia-current is now listed as the 302.17 driver in the repos /synaptic , my default driver in addational drivers is the 295.33-0ubuntu1
[14:50] <penguin42> BluesKaj: But I'm getting that delay with ATI - so it's not an nvidiasm
[14:51] <BluesKaj> the 302 driver suffers from dependency probs so that's proby why it's being removed
[14:52] <BluesKaj> penguin42, yeah , i didn't think the graphics drivers have anything to do with delay either , sheer coincidence i guess
[14:52] <IdleOne> nvidia-current : Depends: xorg-video-abi-11 but it is not installable                  Recommends: nvidia-settings (>= 302.17) but 295.33-0ubuntu1 is to be installed
[14:52] <IdleOne> there is the issue
[14:53] <BluesKaj> IdleOne, yes , that'why I install ed the nvidia/riva in additional drivers
[14:53] <BluesKaj> it's the 295
[14:55] <bjsnider> the xorg-video-abi-11 thing means the blob needs to be rebuilt for quantal
[14:59] <BluesKaj> IdleOne, run dpkg -l | grep nvidia to see which driver you have now
[15:02] <IdleOne> BluesKaj: http://paste.ubuntu.com/1069529/
[15:03] <bjsnider> IdleOne, is there a major xorg update in the group of packages
[15:03] <IdleOne> bjsnider: yes, many xorg packages were updated
[15:04] <bjsnider> that's the issue
[15:04] <bjsnider> they're newer thant he blob, so it must be removed
[15:04] <bjsnider> you can mv the /etc/X11/xorg.conf file to a .bak or whatever and use nouveau
[15:05] <BluesKaj> bjsnider, the 295 works fine , why nouveau
[15:06] <BluesKaj> ?
[15:06] <bjsnider> because it's being forced out, he said
[15:07] <BluesKaj> the 302 was previosly desginated as nvidi-current , but due to dependency porobs it's to be removed and replaced by the 295
[15:07] <BluesKaj> 'scuse my poor typing skills
[15:08]  * BluesKaj suffers from phat phinger syndrome
[15:09] <bjsnider> where is the 295 coming from?
[15:09] <BluesKaj> additional drivers
[15:09] <bjsnider> that's no answer
[15:10] <BluesKaj> it's theonly nvidia driver listed there
[15:10] <BluesKaj> nvidia riva
[15:11] <BluesKaj> that works , all the others will give the dpkg dependency error
[15:13] <bjsnider> additional drivers is just the jockey app
[15:13] <bjsnider> you shouldn't have access to the 295
[15:13] <bjsnider> it has been replaced by the 302
[15:14] <bjsnider> open up synaptic, and look at the properties for nvidia-current, and thent he versions tab
[15:36] <IdleOne> bjsnider: How do I check to see what graphics driver is currently in use?
[15:42] <bjsnider> IdleOne, lspci -v
[15:43] <bjsnider> look for the vga device
[15:46] <IdleOne> Kernel driver in use: nvidia
[15:46] <IdleOne>         Kernel modules: nouveau, nvidiafb
[15:46] <IdleOne> so it is using nouveau now?
[15:47] <bjsnider> the second line is modules that can also handle that device, but the blob is currently handling it
[15:47] <IdleOne> hmm, ok.
[15:48] <IdleOne> everything seems to be working good except that it changed the font to microscopic
[15:48] <IdleOne> :)
[15:49] <bjsnider> well, you could do a lot worse
[15:49] <IdleOne> yup
[17:02] <BluesKaj> I guess the nvidia riva driver is the same as the nouveau , if it's not then I'm confused , because this is the result of " glxinfo | grep OpenGL" : http://paste.ubuntu.com/1069736/
[17:06] <mwozniak00> hi, somebody else have problem with dependencies of nvidia close driver on ubuntu 12.10 alpha2 ?
[17:06] <trism> mwozniak00: nvidia needs a rebuild for the new xorg, bug 1019079
[17:35] <bjsnider> BluesKaj, do a lspci -v and look for the vga compatible controller entry. it will say what driver is being used
[17:36] <BluesKaj> bjsnider, just as i suspected . nouveau
[17:37] <bjsnider> nothing wrong with that
[17:37] <bjsnider> nouveau is a good driver
[17:37] <bjsnider> no kittens were strangled in producing it
[17:38] <trism> if you don't mind your fan running at 100% all the time
[17:38] <BluesKaj> think I might try the xedgers 302 driver built for Quantal
[17:38] <bjsnider> trism, get a card that doesn't have or need a fan
[17:42] <bjsnider> BluesKaj, what is wrong with nouveau?
[17:43] <mwozniak00> hmmm on 12.10 my sda have hot -> 55C
[17:45] <Daekdroom> !schedule
[18:09] <BluesKaj> bjsnider, installed the 302 driver from xedgers ppa  ...seems much faster than nouveau
[18:28] <bjsnider> BluesKaj, using xorg-edgers over a long term period of time is probably a bad idea
[18:28] <bjsnider> so i would ppa-purge it when alberto rebuilds the 302
[18:28] <bjsnider> although nouveau is fine
[18:31] <BluesKaj> bjsnider, well it works here , and untill it starts to act up I'll stick with it ...if alberto is still dev'ing perhaps he could also fix the depends for 295.53
[18:32] <bjsnider> i'd like to point out that you didn't seem to have a problem with nouveau until you found out that's what was driving your card
[18:32] <bjsnider> unless i'm reading the situation wrong
[18:32] <BluesKaj> bjsnider, correct , the nouveau is ok , just slow
[18:33] <bjsnider> or maybe kde is slow
[18:33] <bjsnider> i used nouveau on gnome and didn't notice any loss of speed
[18:34] <penguin42> hmph, muon has stopped allowing upgrades - 'This operation cannot continue since proper authorisation was not provided'
[18:34] <BluesKaj> if kde is slow , how would I notice the diff , bjsnider
[18:34] <bjsnider> well, the blob replaces the whole mesa side of things with its own proprietary opengl code
[18:35] <bjsnider> so that may be propping kde up a bit
[18:35] <BluesKaj> and there is a difference , a significant one at that
[18:36] <penguin42> can someone just check something for me -  do they still have packagekit installed on qq?
[18:37] <yofel> if you mean on kubuntu - no, it shouldn't be installed usually
[18:37] <penguin42> yofel: I do, hmm - ok, so what does muon use to auth that it can do package installation?
[18:37] <penguin42> should that be some bit of polkit?
[18:38] <yofel> polkit (polkit-kde-1)
[18:39] <yofel> do you have a 'polkit-kde-authentication-agent-1' running?
[18:39] <penguin42> hmm, well that's installed and polkitd is apparently running
[18:39] <penguin42> no I don't
[18:39] <yofel> you should
[18:39] <penguin42> I have a polkitd running and I have a /etc/xdg/autostart/polkit-kde-authentication-agent-1.desktop
[18:39] <yofel> maybe it crashed?
[18:41] <penguin42> hmm actually - this probably also explians why it wouldn't shut down last night
[18:41] <penguin42> yofel: Does it show up for you on KDE Services Configuration
[18:42] <penguin42> I can't see it listed in mine
[18:42] <yofel> hm, can't see it - the process is running though
[18:43] <penguin42> as you?
[18:43] <yofel> yofel     2998  0.0  0.2 375800 16428 ?        Sl   Jun30   0:00 /usr/lib/kde4/libexec/polkit-kde-authentication-agent-1
[18:44] <penguin42> I have /etc/xdg/autostart/polkit-kde-authentication-agent-1.desktop and /usr/lib/kde4/libexec/polkit-kde-authentication-agent-1
[18:45] <penguin42> hmm - what would you expect xdg-open to do when running a .desktop file ? It gives me 'No running instance of xfce4-panel was found'
[18:47] <yofel> o.O
[18:47] <yofel> you should have a /usr/share/autostart/polkit-kde-authentication-agent-1.desktop btw. - that's what the package ships
[18:47] <yofel> (and I would believe xdg-open should look at the Exec line and not do what it did there...)
[18:47] <penguin42> yes I do
[18:48] <yofel> the service should be started at login, but I don't know what happens if it crashes or whatever
[18:49] <penguin42> nod
[18:49] <penguin42> hmm, xdg-open runs kde-open and it's kde-open that gives that error
[18:51] <yofel> ah, fun
[18:51] <penguin42> bah, and that's binary
[18:57] <penguin42> hmm, so that's coming from /usr/share/applications/panel-desktop-handler.desktop
[18:58]  * penguin42 defenestrates xfce4-panel
[19:00] <penguin42> yofel: Well, manually starting polkit-kde-authentication-agent-1 seems to fix muon - now as to why it wasn't started, hmm
[19:00] <yofel> look for a crash message in dmesg maybe - otherwise I don't know why that would happen.
[19:06] <penguin42> doesn't look like it crashed
[20:51] <litropy> I have an iMac running Intel(R) Core(TM)2 Duo CPU     T7700  @ 2.40GHz. I imagine, but I want to make sure here, that I should go with the PC (Intel x86) desktop CD, and not 64-bit Mac (AMD64) desktop CD, correct? cat /proc/cpuinfo: http://pastebin.com/Wj2JawUC
[21:54] <MrChrisDruif> litropy; I think you could better ask support questions in #ubuntu, but if you must know: Core 2 Duo has support for 64-bit (AMD64). I'm not sure if you have to use the more specific amd64+mac builds, but I'm sure they know in that other channnel
[21:55] <MrChrisDruif> This channel is for the development release of Ubuntu, currently 12.10 Quantal Quetzal litropy
[21:58] <litropy> MrChrisDruif, Thank you for your input. I asked here because I was referring to the 12.10 download page http://cdimage.ubuntu.com/releases/quantal/alpha-2/
[21:58] <MrChrisDruif> Ow, you want to use the development release? I guessed you ask advice for the normal release ^_^
[21:59] <litropy> Haha, no prob
[22:10] <MrChrisDruif> litropy; you're on a mac?
[22:11] <litropy> MrChrisDruif, yes.
[22:11] <litropy> http://www.everymac.com/ultimate-mac-lookup/?search_keywords=iMac7,1
[22:11] <litropy> MrChrisDruif, ^
[22:11] <MrChrisDruif> Then you need either this one: http://cdimage.ubuntu.com/releases/quantal/alpha-2/quantal-desktop-amd64+mac.iso or if you want to torrent: http://cdimage.ubuntu.com/releases/quantal/alpha-2/quantal-desktop-amd64.iso.torrent
[22:12] <litropy> MrChrisDruif, Thanks bud.
[22:12] <MrChrisDruif> 20" or 24"?
[22:12] <litropy> 20": http://www.everymac.com/systems/apple/imac/specs/imac-core-2-duo-2.4-20-inch-aluminum-specs.html
[22:13] <MrChrisDruif> Because as it is stated on that same Alpha 2 page: "Choose this to take full advantage of computers based on the AMD64 or EM64T architecture (e.g., Athlon64, Opteron, EM64T Xeon). If you have a non-64-bit processor made by AMD, or if you need full support for 32-bit code, use the Intel x86 images instead. This image is adjusted to work properly on Mac systems."
[22:14] <MrChrisDruif> I do love how Mac's look...it's just their business ethnics and pricing that is putting me off! =)
[22:14] <litropy> MrChrisDruif, See, that's the thing ... it's an Intel, implying x86, but it's 64-bit, and a mac ...
[22:15] <litropy> MrChrisDruif, Ya, it's quite a dilemma about macs. I'd love to upgrade my GPU/CPU, but can't.
[22:15] <MrChrisDruif> litropy; http://en.wikipedia.org/wiki/Core_2_duo#64-bit_Core_microarchitecture_based
[22:16] <MrChrisDruif> (P.s.: I'm running 64bit atm on a normal laptop with core 2 duo
[22:16] <MrChrisDruif> Intel® Core™2 Duo CPU P8400 @ 2.26GHz × 2
[22:17] <litropy> MrChrisDruif, still no mention of AMD in that link. But if you know what you're sure, I'll trust ya.
[22:18] <MrChrisDruif> EM64T = from Intel
[22:18] <MrChrisDruif> EM64T Xeon (I don't recall any AMD cpu's to be named Xeon)
[22:18] <MrChrisDruif> (It's from that same line I copied)
[22:20] <FernandoMiguel> MrChrisDruif: xeon is from intel
[22:20] <FernandoMiguel> which is an EM64T
[22:20] <MrChrisDruif> litropy; and if you want to have a good read about AMD64 (or to be more precise x86-64), have a look here: http://en.wikipedia.org/wiki/X86-64
[22:20] <MrChrisDruif> FernandoMiguel; tell that to litropy ;-)
[22:21] <MrChrisDruif> I already know that amd64+mac is the iso he needs for his iMac ( http://www.everymac.com/systems/apple/imac/specs/imac-core-2-duo-2.4-20-inch-aluminum-specs.html )
[22:21] <Daekdroom> It's called AMD64 because AMD was the first to implement it.
[22:21] <Daekdroom> But Intel calls it EMT64.
[22:21] <Daekdroom> Both are the same as x86_64
[22:22] <Daekdroom> (and know I notice that all that has been said already)
[22:22] <litropy> Thanks, MrChrisDruif, FernandoMiguel, Daekdroom
[22:23] <Daekdroom> *now
[22:23] <FernandoMiguel> o/
[22:23] <MrChrisDruif> But backup is always appreciated Daekdroom =)
[22:24] <MrChrisDruif> Daekdroom; on the Alpha 2 page it says EM64T, should that be EMT64?
[22:24] <Daekdroom> Hm.
[22:24] <Daekdroom> Let me check.
[22:25] <Daekdroom> It's EM64T indeed. I mixed it up.
[22:26] <MrChrisDruif> Alright, didn't want to go through that whole wikipedia page, just to check that ;-)
[22:27] <MrChrisDruif> Btw, how is everybody liking Quantal so far?
[22:32] <Daekdroom> My Quantal VM is so slow to upgrade packages I haven't bothering running it.
[22:33] <FernandoMiguel> Daekdroom: I know how you feel
[22:34] <FernandoMiguel> my office laptop with HD is the same
[22:34] <FernandoMiguel> miss my SSD a lot
[22:34] <litropy> Just a note: after upgrading my RAM, I figured out that since I have 32-bit installed, I only have use of about 3GBs. So now, I'm gonna have to go through the long and arduous process of clean installing 64-bit, then restoring my system back to its custom setup. All my fault.
[22:34] <litropy> I figured why not go alpha during the process.
[22:35] <litropy> There are a few guides as to how to "upgrade" from 32 to 64, but meh ... too finicky.
[22:37] <FernandoMiguel> litropy: or you try a PAE kernel
[22:37] <FernandoMiguel> I think it's server edition kernel that has it now
[22:37] <FernandoMiguel> !pae
[22:42] <litropy> FernandoMiguel, I looked into that only briefly ... I need to do further research to see the pros and cons ... it sounds like going full 64-bit would be more economical for my system resources, no?
[22:43] <Daekdroom> The -generic kernel has PAE in quantal.
[22:43] <Daekdroom> In the past you'd have to use -generic-pae, now it's a 32-bit default for Ubuntu.
[22:44] <litropy> Good to know, Daekdroom
[22:45] <Daekdroom> Not everyone thinks it's that good because starting from Quantal people with older machines won't be able to boot Lubuntu.
[22:45] <litropy> So, if I determined there wouldn't be much of a difference in performance between 32-bit with PAE and full 64-bit, I could just apt-get dist-upgrade and have pae installed?
[22:45] <jtaylor> it depends
[22:46] <jtaylor> amd64 is faster due to its more modern instruction set and more registers
[22:46] <Daekdroom> But it can be slower due to higher RAM usage.
[22:46] <jtaylor> but i386 has smaller pointers and thus better cache performance
[22:46] <jtaylor> so its hard to say what is faster, it depends on the application
[22:47] <jtaylor> i386 is certainly better for ram usage
[22:47] <Daekdroom> iirc enconding, decoding and compiling benefit from 64-bit
[22:47] <litropy> This includes video/audio/image codecs?
[22:49] <Daekdroom> Depends on how they were compiled.
[22:49] <litropy> This is mainly a media center. I do some scraping of Google Maps, but that's while I'm asleep.
[22:49] <jtaylor> if your adventerous you could install gentoo with x32 :)
[22:49] <jtaylor> its the best of both worlds
[22:49] <litropy> Plus, I enjoy working with you guys in debugging.
[22:50] <litropy> jtaylor, hah ... I'll stick with what I (kind of) know.
[22:50] <Daekdroom> jtaylor, do you know whether it's possible to use x86 packages in x32 through multiarch?
[22:51] <jtaylor> with a little luck we'll get the base infrastructure for x32 in quantal already
[22:51] <jtaylor> but more likely only q+1 :/
[22:51] <litropy> Anyhow, apt-get dist-upgrade will automatically install pae?
[22:51] <Daekdroom> Yes.
[22:51] <jtaylor> glibc with support for it was only released a couple of days ago
[22:51] <litropy> Sweet. I'll hold off from 64, then.
[22:52] <litropy> And, there we go. The OS is now ripping itself apart only to put itself back together again.
[22:53] <litropy> ... While it's running. That will never fail to impress me.
[22:53] <jtaylor> until you get a powercut while its replacing libc or the kernel ;)
[22:53] <litropy> Hah
[22:53] <jtaylor> though even that is repairable
[22:54] <Daekdroom> Is it?
[22:54] <litropy> Wayland yet?
[22:54] <jtaylor> dpkg is atomic, so you have either one or the other on disk but not broken in between state but you still need to manually fix it to the correct state
[22:55] <jtaylor> which is probably not easy
[22:58] <MrChrisDruif> Daekdroom; x86 = 32bit right? ;-)
[22:58] <Daekdroom> Yes.
[23:00] <MrChrisDruif> "do you know whether it's possible to use x86 packages in x32 through multiarch?"
[23:00] <MrChrisDruif> I think yes ;-)
[23:00] <jtaylor> x32 != x86
[23:01] <Daekdroom> And I believe that points out how inconvenient it was to name it x32.
[23:01] <MrChrisDruif> What is x32 then? I never heard of that..
[23:01] <jtaylor> its a new abi for 32 bit aps on x86_64
[23:01] <Daekdroom> It's something between x86 and x86_64.
[23:01] <Daekdroom> Gives us the benefits of both, but breaks compatibility. :(
[23:01] <psusi> 64 bit except for memory pointers are still 32
[23:02] <psusi> so gives most of the beneifts of x64, without one drawback: more memory used to hold pointers
[23:03] <MrChrisDruif> Oh dear lord, not again?
[23:03] <MrChrisDruif> Do we ever do stuff the right way?
[23:03] <jtaylor> ?
[23:03] <Daekdroom> x32 will eventually become obsolete because applications are still limited to 4GiB RAM in it.
[23:03] <Daekdroom> (but the entire system is not)
[23:04] <jtaylor> no x32 will make i386 obsolete
[23:04] <psusi> the vast majority of applications have no need for more ram
[23:04] <Daekdroom> True.
[23:04] <MrChrisDruif> Just my webbrowser ^_^
[23:04] <jtaylor> 99.9% of apps don't need more than 4gb of ram
[23:04] <psusi> hence, the idea goes, why should they have to pay for it with increased pointer size?
[23:05] <psusi> in theory it isn't a bad idea... I'm still not sure it will make much difference in practice though
[23:05] <jtaylor> likely not, its probably more useful for memory limited embedded cases
[23:05] <MrChrisDruif> Apps should just use the memory they need and not more
[23:05] <jtaylor> which is so far I know the main driver behind it
[23:06] <psusi> MrChrisDruif, that's neither here nor there... the question is how much memory they need to hold a pointer
[23:06] <jtaylor> also it helps solve the 2038 problem
[23:06] <jtaylor> time_t is still 64 bit in x32
[23:06] <jtaylor> with it we can abolish i386 and get rid of the problem
[23:07] <jtaylor> for 64 bit cpu's at least
[23:07] <MrChrisDruif> I'm gonna read this when I get back. I'm off to bed, but I'll have some scrollback
[23:08] <FernandoMiguel> can we have 256 bits CPU/archs now? :D
[23:08] <psusi> I think that it is a rare application that spends a significant amount of its memory holding pointers though, so reducing the pointer size won't help much
[23:08] <jtaylor> I'm sure that already exists
[23:08] <jtaylor> well high level languages tend to make massive use of pointers
[23:08] <jtaylor> e.g. python
[23:09] <jtaylor> every object holds many pointers
[23:09] <Daekdroom> Does Arch Linux support x32 already?
[23:10] <Daekdroom> and now a question that is fit for this channel.
[23:10] <Daekdroom> Should I ppa-purge xorg-edgers before trying to upgrade to quantal?
[23:11] <jtaylor> its probably a good idea to do that
[23:15] <Daekdroom> I'm glad I tried to purge it first because it's breaking my system :P
[23:15] <Daekdroom> If I were using the upgrade manager, I probably would not notice that.