[00:00] <nxvl> TheMuso: the problem is, it is an orca or a bluethooth wizard bug
[00:00] <TheMuso> nxvl: I'd say the latter.
[00:01] <TheMuso> Ok, so I choose forward in the wizard, and it asks me for a device to set up, yet there is nothing listed.. Has something gone wrong somewhere.
[00:01] <nxvl> heh, kees twittered parts of the conversation
[00:01] <TheMuso> s/./?/
[00:01] <nxvl> :D
[00:02] <TheMuso> and this is after a reboot mind you, so everything is running.]
[00:04] <superm1> TheMuso, can this be caused by the translation system in use for the wizard?
[00:04] <TheMuso> superm1: I wouldn't think so, but am unsure.
[00:05] <superm1> TheMuso, the source is pretty small for that wizard (single file), in ./wizard/main.c
[00:05] <superm1> TheMuso, so if you've seen this happen before and recognize it
[00:05] <TheMuso> superm1: I haven't seen it, but I'll have a dig.
[00:05] <TheMuso> The preferences applet is also not entirely accessble, in that the device visability doesn't appear to be available in the tab order.
[00:05] <TheMuso> visability
[00:05] <TheMuso> visibility damn typing
[00:06] <kees> nxvl: cjwatson totally cracked me up on the corkscrew quote.
[00:06] <nxvl> kees: heh
[00:06] <nxvl> :D
[00:06] <nxvl> been there
[00:06] <kirkland> superm1: okay, i've successfully associated both my treo and a wireless headset via bluetooth
[00:07] <kirkland> superm1: i'm trying to do something useful with that now.....
[00:07] <TheMuso> ok I have set my notebook bluetooth to always be visible, yet my phone can't find it.
[00:08] <kirkland> i used the bluetooth-applet to send a simple test.txt file to my phone, and the phone turned on, like it was going to do something, but nothing happened
[00:08] <cody-somerville> TheMuso, it might not be offering a service your phone knows how to interact iwht
[00:09] <TheMuso> cody-somerville: Right.
[00:09] <kirkland> i also paired my BT headset, and expected to see new alsa devices
[00:09] <kirkland> not yet, though
[00:10] <kirkland> on the bluetooth-applet preferences page, what's the blue "i" information looking icon do?
[00:14] <superm1> kirkland, you wont see a new alsa device
[00:14] <TheMuso> hrm ok trying to run hcitool scan gives me a connection timed out, even though there is a device in range thats visible.
[00:14] <kirkland> superm1: okay, how can i test something useful, now that i've paired a couple of devices?
[00:15] <superm1> kirkland, so audio devices, aplay -D headset FILE
[00:15] <superm1> headset is the name of the device made by the ALSA plugin that isn't enumerated
[00:15] <superm1> TheMuso, multiple scans back to back will cause that i believe
[00:15] <TheMuso> superm1: this is the first one after a fresh reboot
[00:15] <superm1> TheMuso, then your bluetooth device might need to be reset
[00:16] <superm1> a lot do (this means a small kernel quirk is necessary too)
[00:16] <TheMuso> right
[00:16] <superm1> hcitool reset should do the trick i think
[00:16] <TheMuso> ok will try that in a sec.
[00:16] <kirkland> superm1: where do i find that device name?
[00:16] <superm1> kirkland, for sending it to your phone, your phone needs to be expecting the transfer generally
[00:16] <superm1> kirkland, that "is" the device name
[00:16] <superm1> headset
[00:17] <superm1> it's hardcoded in /usr/share/alsa/bluetooth.conf
[00:17] <kirkland> hrm, that's not working
[00:17] <apachelogger> slangasek: Riddell told me to go ahead with upload, I guess he was going to grant FFe. As for the LP bugs, I have to have a talk with upstream about bugs affecting ubuntu packages and bugs affecting upstream projects, but yes, in general closing them in the changelog would have been healthy ;-)
[00:17] <TheMuso> superm1: what referrs to /usr/share/alsa/bluetooth.conf in terms of making sure that file gets included?
[00:18] <superm1> TheMuso, /usr/share/alsa/alsa.conf
[00:18] <kirkland> superm1: okay, i gotta run...  i'll be back online later tonight and try some more
[00:18] <TheMuso> superm1: ah.
[00:18] <superm1> TheMuso, alsa-lib was one of  the patched apps on the PPA
[00:18] <TheMuso> well I didn't get it.
[00:19] <TheMuso> Ah I know why, I am running a test version of libasoudn2.
[00:19] <superm1> TheMuso, should have seen 1.0.17a-0ubuntu4~ppa1
[00:19] <TheMuso> libasound2
[00:19] <superm1> ah there you go
[00:20] <TheMuso> Yeah testing a fix that I will be likely uploading in the next day or so.
[00:23] <TheMuso> superm1: hrm ok, a hcitool reset made no difference. still connection timeout for hcitool scan, and it also seems looking more closely that I can't set the visibility in the preferences...
[00:23] <TheMuso> I haven't tried any of this with the old stack either, so wasn't sure if it was working prior to this or not.
[00:23] <superm1> TheMuso, do you have a tray icon present?
[00:23] <TheMuso> superm1: Yes.
[00:23] <superm1> TheMuso, hum.  if you want to look a little closer, try stopping the service and  running sudo bluetoothd -nd
[00:24] <superm1> you can see if there are errors from the daemon
[00:24] <TheMuso> superm1: ok.
[00:26] <TheMuso> bluetoothd[7370]: Can't set link policy on hci0: Device or resource busy (16)
[00:26] <TheMuso> bluetoothd[7368]: Can't read class of adapter on /org/bluez/hci0: Input/output error (5)
[00:26] <superm1> TheMuso, that would sound to me like problems directly with your device then
[00:26] <superm1> TheMuso, there is a handful of quirks to experiment with btusb (see modinfo btusb)
[00:26] <TheMuso> superm1: Right. What device nodes are usually used? USB nodes directly?
[00:27] <TheMuso> superm1: ok will ahve a play.
[00:27] <superm1> TheMuso, there is no /dev node made afaik.
[00:27] <TheMuso> right
[00:27] <superm1> (or used for that matter)
[00:28] <superm1>  okay i'm taking off for a bit, if you've got some other questions kirkland or TheMuso, feel free to leave some more pings
[00:28] <TheMuso> ok.
[00:29] <RAOF> Aha.  Bluetooth mice don't like being paried with two systems at once, it seems :)
[00:30] <kirkland> superm1: no prob, i'll be back online around 9 or 10 pm
[00:40] <slangasek> Riddell: ping (re: kgrubeditor upload mentioned up there ^^)
[01:53] <slangasek> bryce: s/Standby/Stand by/
[01:53] <bryce> slangasek: huh?
[01:53] <slangasek> bryce: the xorg patch
[01:53] <slangasek> debdiff, rather
[01:54] <slangasek> "Standby" is not a verb :)
[01:54] <bryce> still not sure what you're referring to
[01:54] <slangasek> bryce: the new zenity line in the just-unblocked xorg upload
[01:55] <bryce> ah, alright I'll put that on my todo to fix
[01:55] <slangasek> ok :)
[01:55] <bryce> that's a pretty old patch ;-)
[01:55] <bryce> er old upload
[01:56] <slangasek> heh
[02:06] <bryce> slangasek: pushed to git
[02:06] <slangasek> ok :)
[02:15] <Hobbsee> you know, there's only one problem in posting the beta in the same calendar month as the final.
[02:15] <Hobbsee> it really is quite poor planning.
[02:16] <slangasek> ?
[02:17] <Hobbsee> you can't use up the monthly bandwidth on torrenting, twice.
[02:17] <slangasek> oh, yes
[02:18] <Hobbsee> last cycle, i'm fairly sure we had the beta the month before.
[02:18] <slangasek> yes, we did; the last Thursday of the month falls late this month
[02:18] <Hobbsee> ahhh
[03:08]  * jdong caps his ubuntu beta torrents at a more neighbor-friendly 1MB/s
[03:09] <Hobbsee> jdong: i'm jealous.
[03:09] <slangasek> you mean your neighbors aren't all torrenting it from you?!
[03:09] <jdong> slangasek: hehe they probably are, but I feel bad for using 7.5MB/s of upstream...
[03:17] <Adri2000> slangasek: time to take a look at an sru?
[03:43] <Adri2000> slangasek: if you do, it's vsftpd
[03:44] <Adri2000> now, I need to get some more sleep during the couple of hours left in the night :)
[05:06] <slangasek> bryce: how does it work that xserver-xorg-video-ati adds one patch file and mentions one patch in the changelog, and has three new entries in debian/patches/series?  Is this going to FTBFS as soon as I unblock it? :-)
[05:07] <bryce> slangasek: yeah those extra two can be removed.  I wasn't able to get validation on them
[05:08] <slangasek> bryce: ok; expect build failure mails soon, I guess :)
[05:08] <bryce> although I still think they're good fixes
[05:11] <StevenK> slangasek: It might take a while on i386, there's nearly 1,000 builds in the queue
[05:11] <slangasek> yeah, but those are langpacks
[05:35] <ScottK> slangasek: The firefox3.0 package in Gutsy is not being updated by mozillateam.  It's in Universe, so it's not technically required, it is still sitting there with known vulnerabilities.  Given the licensing restrictions on Firefox, I do not think that package is supportable by MOTU.  What are the odds of getting it removed?
[05:39] <slangasek> ScottK: would pulling in 3.0.3 from hardy-updates (as a backport, or just pulling the upstream tarball) not work?  That seems straightforward to me and doesn't fall afoul of any license restrictions, assuming those apply to the gutsy version, and as we don't have a general policy of pulling packages post-release (for lack of security support or otherwise), I think that ought to be investigated first
[05:40] <slangasek> on a technical level, I'm not sure what it takes to actually get a package removed from the release pocket
[05:40] <ScottK> slangasek: jdong said he was going to look into updating the backport in Gutsy.
[05:41] <ScottK> So if 3.0.3 is backportable, it's presumably updatable.
[05:41] <ScottK> I just don't think it's reasonable to ask MOTU to deal with the Mozilla corp 'mother may I' restrictions.
[05:42] <ScottK> That and I find the multiple presentations of the "Known your rights" pop-up annoying, but that's an separate issue.
[05:43] <slangasek> I'm not convinced those restrictions are a problem in practice if all we're doing are security updates; but is there something else we should be doing pre-release to ensure we don't wind up with packages in universe for a release that are explicitly unsupported by MOTU?
[05:44] <ScottK> slangasek: Fundamentally there is a process for getting patch approval that is not supportable by the general MOTU community.
[05:44] <ScottK> I did get a committment from asac to support firefox (the 2.0 one) in Universe for Hardy when it was added back.
[05:45]  * ScottK goes to look at that one.
[05:45] <ScottK> Yep.  That one is updated.
[05:46] <kirkland> superm1: i'm still struggling to sync my treo via bluetooth
[05:46] <ScottK> We did not get a similar agreement on firefox-3.0 in Gutsy since it wasn't added in a FFe period where I had leverage.
[05:47] <ScottK> slangasek: We probably ought to remove firefox before Intrepid releases for one thing.
[05:47]  * ScottK files a bug.
[05:47] <slangasek> ScottK: file a bug, subscribe mozilla-team and ubuntu-archive?
[05:47] <ScottK> Sure thing.
[05:48] <ScottK> It's FTBFS now in any case.
[05:48] <ScottK> I'll do something similar on Gutsy for firefox-3.0
[05:57] <nxvl> slangasek: you must know, the actual intrepid's wallpaper is the final one?
[05:57] <slangasek> oh, I /must/ know? :-)
[05:57] <slangasek> I haven't been told that it isn't final - but that doesn't mean I know that it is :)
[05:57] <nxvl> you are the release manager
[05:57] <nxvl> :D
[05:57] <superm1> kirkland, what sort of struggles now?
[05:57] <nxvl> i hate it :D
[05:58] <kirkland> superm1: i'm just trying to sync my treo to my laptop, which I've ***always*** accomplished via dund
[05:58] <kirkland> superm1: what is dund's replacement?
[05:58] <superm1> syncing via dund?  dund is for creating a dial up connect?
[05:58] <slangasek> did dund even work/exist in intrepid?
[05:59] <kirkland> superm1: they each get a private ip address, and it syncs
[05:59] <superm1> kirkland, you mean setting up a pan?
[05:59] <slangasek> man, bluetooth is the shop of 31 different flavors of crack
[05:59] <kirkland> superm1: http://elijah.pinoguin.com/blog/blog-view/article/sync-treo-650-on-ubuntu-linux.html
[05:59] <superm1> kirkland, look at ifconfig pan0
[05:59] <kirkland> superm1: k
[05:59] <superm1> you should have a pan device that you can do such things if you wanted
[06:00] <superm1> slangasek, the biggest problem is that it has changed SO much over the last revisions and no one's documentation accounts for changes from revision to revision
[06:00] <ScottK> slangasek: Done in Bug 277401 and Bug 277403.
[06:01] <slangasek> superm1: I was referring to the umpteen bazillion ways to implement syncing
[06:06] <ScottK> slangasek: I also subscribed ubuntu-security since ultimately that's the only reason it's a concern.
[06:07] <slangasek> ok
[06:10] <kirkland> superm1: on the plus side, i was able to send files from my laptop to my palm
[06:11] <superm1> kirkland, if pan0 isn't doing to do the trick, http://wiki.bluez.org/wiki/HOWTO/SerialConnections
[06:12] <superm1> that bottom one is the proper way to generate a new serial device that does dun specifically
[06:12] <superm1> kirkland, very good
[06:13] <kirkland> superm1: ooooh, let me try that
[06:14] <superm1> kirkland, and if all else fails, we do have a final alternative to have a bluez-compat package that is not installed by default that provides the legacy dund pand and hidd, but i'm not sure how well they operate with the 4.x stuff
[06:17] <milli> fglrx not supported in the beta?  (selecting it in apt marks xserver-xorg-core as broken)
[06:18]  * milli noticed fglrx is gone from linux-restricted-modules too
[06:19] <ScottK> milli: There was a new X uploaded just after the beta released.  Do you have that?
[06:19] <superm1> fglrx is not supported in beta milli
[06:20] <milli> ScottK: 7.4~2ubuntu5 ?
[06:20] <milli> superm1: alright.
[06:20] <superm1> bug 247376
[06:20] <milli> using radeonhd for the time being, works ok
[06:20] <ScottK> There you go.
[06:21] <superm1> milli, it's completely outside the control of ubuntu developers.  AMD has to update fglrx to work with intrepid
[06:21] <milli> however, I have to keep flashplugin-nonfree at 9.0.124.xxx as the 10.0.1.218.xxx driver sucks all (of one) CPU when flash is active...
[06:21] <milli> superm1: nod
[06:23] <kirkland> superm1: http://pastebin.ubuntu.com/53366/
[06:23] <kirkland> superm1: that's running the python script to create the serial device
[06:24] <ScottK> milli: There are issues with getting flash updated that are being worked.
[06:25] <superm1> kirkland, hum interesting.  it looks like even that document is outdated now
[06:25] <milli> just thought I'd mention it, even though flashplugin-nonfree is, well, not in main
[06:25] <superm1> i looked at doc/manager-api.txt and it' doesn't mention ActivateService
[06:25] <kirkland> superm1: yeah, i'm desperately trying to find the 'right' way to do this
[06:25] <kirkland> superm1: i'd hate to fall back on dun, if there's a more modern way
[06:26] <superm1> kirkland, and then "document" said right way :)
[06:26] <superm1> yeah
[06:26] <kirkland> superm1: the docs are just lacking
[06:27] <superm1> kirkland, so open up doc/
[06:27] <superm1> look at serial-api.txt
[06:27] <kirkland> superm1: where is this doc?
[06:28] <superm1> kirkland, ah it's not installed in the right binary package
[06:28] <superm1> i'm looking in the source
[06:28] <kirkland> oh, okay
[06:28] <superm1> i'll fix that to be installed as part of libbluetooth-dev
[06:28] <kirkland> superm1: which source?
[06:28] <superm1> but for now apt-get source bluez
[06:30] <superm1> kirkland, although i'm betting you might be able to just use the same rfcomm stuff that you normally use for the DUN service itself
[06:30] <superm1> like i showed you before
[06:30] <kirkland> superm1: i've been trying /dev/rfcomm0
[06:30] <kirkland> superm1: that dev exists
[06:30] <kirkland> superm1: perhaps i need to setup that device
[06:31] <superm1> kirkland, /etc/bluetooth/rfcomm.conf
[06:32] <kirkland> superm1: yup, that's set up correctly
[07:19] <sbeattie> TheMuso: you probably ought to look at bug 275233
[08:24] <Burgundavia> asac: you should post to upstream projects using your canonical or ubuntu addy
[08:24] <Burgundavia> http://mail.gnome.org/archives/networkmanager-list/2008-October/msg00006.html
[08:24] <Burgundavia> in case somebody decides to parse mailing lists to attack us (ugh)
[08:26] <persia> Why?  If someone has an established identity within a community, is it worth changing that for mail archive scanning trolls?
[08:27] <persia> Is it not enough that we have an average of about 2 patched packages per active uploader, and try to keep that even lower: that statistic ought speak for itself in terms of pushing upstream.
[08:29] <liw> persia, er, that we have few packages with changes from upstream does not necessarily sound to me like we're pushing stuff upstream, it might also be that we don't change anything
[08:30] <persia> liw: Sure, in that case, why complain that we don't push anything.
[08:32] <liw> persia, since part of the complaint is that Ubuntu doesn't help upstream, saying that we don't have anything to give them isn't really a good defense :)
[08:34] <persia> liw: It's about positioning.  Saying "We're just users: we don't have code.  Our role is to provide you with millions of users, and try to filter the bug reports into something you can handle" is a positive statement.  Saying "This 500 people wrote these 25,000 lines of code, and these 15,000 were pushed to upstream projects" is a reactive defence.
[08:35] <persia> Asking other people why they don't have more effective measures in place to coordinate user input might be an interesting counterpoint question.
[08:35] <persia> Remember, the winner in any debate is usually the speaker who can establish the terms of the debate, rather than the speaker with the strongest arguments or the strongest evidence.
[08:36] <persia> (also known as the reason no diplomat will either answer a simple question simply, or provide a definitive positive statement about anything : it's just safer that way)
[08:41] <liw> persia, skipping the meta discussion... I'll just say that I don't think the "We're just users..." thing is a positive statement
[08:41] <persia> liw: Fair enough.  Perhaps this is why I'm not part of the marketing team :)
[08:41] <liw> :)
[08:42] <liw> I do agree that anyone relying on e-mail addresses to assign credit to employers is a) [deleted by CoC filter] and b) in need of some statistics tutoring
[08:44] <wgrant> But all the cool people are doing it.
[08:44] <persia> Yeah, but it's durned difficult to find any reliable tool to match employers and email addresses.
[08:46] <persia> Plus, any claims related to specific employers ignore the fact that the majority of Ubuntu developers aren't employed by the primary sponsor.
[08:46] <wgrant> But then how are they going to attack Canonical?
[08:49] <liw> hmm. upgrading my desktop machine to intrepid just ended in a crash, doesn't even react to ping. the gdm screen is all garbled (I was doing the upgrade via ssh)
[08:49] <wgrant> liw: Lovely. What kind of video card?
[08:50] <liw> something by ATI, iirc
[08:50] <wgrant> Ah. Them.
[08:50] <sifunk> mine went all screwy with the nvidia drivers for a bit, but i've got it back now with glx enabled
[08:52] <liw> I doubt it was related to graphics hardware, though, it wasn't updating anything graphics related recently
[08:52] <liw> also, when I reboot, the kernel can't mount the root fs
[08:52] <persia> This doesn't exactly sound promising.
[08:53]  * wgrant has to agree with persia.
[08:54] <persia> I have an intrepid box, and it runs great.  I have a box I reinstall every couple days, and it works pretty good, except that there's no support for the video hardware except with vesa.
[08:54] <persia> I have a hardy box with LVM and encryption and stuff, and now I'm all worried.
[08:57] <liw> moving the root disk to another computer (it's a usb stick just for this reason), ext3 finds rahter a large number of unreferenced inodes, hmm
[08:57] <sbeattie> bah, I just did an install, and stuff's failing because /dev/null is mode 600.
[08:57] <sbeattie> gdm won't run because of it.
[08:58] <liw> sbeattie, what, again? how on earth does that bug recur so often
[08:58]  * persia is surprised that none of these issues were encountered *yesterday*
[09:00] <sbeattie> persia: no kidding.
[09:00] <liw> persia, I did upgrade tests yesterday, no problems found...
[09:00] <persia> Yeah.  I know.  That's the odd bit.
[09:01] <sbeattie> liw: know how to solve it? it looks like it's supposed to be set up properly based on /etc/udev/rules.d/40-permissions.rules
[09:02] <liw> sbeattie, it's a symptom of a number of different problems, historically; there was at least one bug where some postinst script accidentally deleted /dev/null and then the first script to redirect things to /dev/null created a file
[09:03] <sbeattie> mmm, that's not this situation, it's a character device.
[09:03] <liw> sbeattie, can you verify that your /dev is really managed by udev?
[09:06] <liw> hmph, it would have been such a nice solution to my problem if the usb stick was broken, but no, it's good
[09:07] <liw> and GiBs of disk space
[09:07] <liw> sbeattie, with "that bug" I actually meant all the bugs that wreck up /dev/null
[09:08] <liw> oh, the syslog from the crashed machine has fglrx entries as the last thing
[09:08] <liw> why does it have that? I wasn't using fglrx earlier
[09:22] <sbeattie> liw: umm, probably not. I somehow have a fake /sbin/start-stop-daemon
[09:23] <liw> sbeattie, that is very... interesting
[09:24] <wgrant> sbeattie: How fake is it?
[09:27] <sbeattie> wgrant: it's a 3 line shell script that echos that it's a fake script and does nothing.
[09:27] <wgrant> sbeattie: Uh... nice.
[09:27] <liw> sbeattie, that makes me think of something related to automated testing
[09:28] <liw> or something that builds chroots
[09:28] <liw> since it can be necessary for those to prevent daemons from being started
[09:28] <wgrant> Is there a diversion?
[09:28] <wgrant> It should be owned by dpkg.
[09:29] <sbeattie> that's what dpkg -S claimed, that it was owned by dpkg
[09:50] <C0p3rn1c> Suggestion: Maybe it's possible to incorperate PowerTOP, LatencyTOP to boost ubuntu's performance
[09:53] <siretart> C0p3rn1c: patches welcome. try elaborating your ideas at http://brainstorm.ubuntu.com
[09:54] <C0p3rn1c> siretart, I'm really no expert, I was just reading about this amaizing article on slashdot that apparently makes it possible to boot linux in 5 seconds http://linux.slashdot.org/article.pl?sid=08/10/02/1933206
[09:55] <persia> C0p3rn1c: powertop is in Ubuntu: you can use it on your own system.  That particular machine was hacked in a number of ways, and while the result was linux, it wasn't a full Ubuntu Desktop.
[09:56] <Ng> (and latencytop is in the upcoming Intrepid release)
[09:56] <C0p3rn1c> ok thats great, thx guys
[10:02] <C0p3rn1c> Also, I know it's not really your distro but maybe it would be good idea to promote ubuntu ultimate edition a bit more, I imagen this could boost the populairity of linux in general because it's pretty impressive and or "cool" for the recreational linux user
[10:07] <cjwatson> sbeattie: that sounds like the installer broke halfway through - the installer does that temporarily
[10:07] <cjwatson> C0p3rn1c: we'd rather improve Ubuntu! :-)
[10:10] <C0p3rn1c> cjwatson: ubuntu ultimate edition is still ubuntu, they just copy your distro and add popular software in the default install :)
[10:12] <cjwatson> I know, but we control our default install and should be improving it whenever possible
[10:12] <cjwatson> and when we think it makes sense
[10:12] <wgrant> UUE is pure evil.
[10:13] <wgrant> It comes from the creator of Ultamatix, doesn't it?
[10:13] <cjwatson> also I'm not terribly happy with the implication of the "Ubuntu Ultimate Edition" name
[10:13] <siretart> what is "Ubuntu Ultimate Edition"?
[10:13] <wgrant> cjwatson: Neither.
[10:14] <C0p3rn1c> siretart: http://ultimateedition.info/
[10:14] <cjwatson> anyhow, much rather advertise our own product than somebody else's
[10:14] <wgrant> siretart: A misleadingly named Ubuntu derivative created by the creator of an Automatix derivative. You can work out the rest.
[10:14] <siretart> wgrant: OMG!
[10:14]  * siretart runs away. screeming
[10:14] <norsetto> ultimate, hmmm, that also mean final ...
[10:14] <mpt> Gutsy Gibson? Is that a guitar?
[10:14] <C0p3rn1c> hehe
[10:16] <wgrant> It also seems that none of UUE's subpage links work.
[10:16] <wgrant> I want them powering my distro.
[10:16] <C0p3rn1c> Maybe UUE is evil, but so is the recreational user, we are all downloading mp3's , illegal movies, etc...
[10:16] <wgrant> What does UUE actually do?
[10:16] <wgrant> Other than break?
[10:16] <wgrant> And mislead?
[10:16] <wgrant> Their website isn't too informative.
[10:17]  * norsetto sits down and opens the chips bag
[10:17] <mpt> That's explained about 1/4 the way down
[10:17] <C0p3rn1c> like I said, it just adds popular software to the default install
[10:17] <wgrant> mpt: Ahhh, I tried to avoid looking at the page too much.
[10:17] <siretart> C0p3rn1c: I can play them with stock ubuntu, FWIW. no need for automatic or other 'ultimate' add-ons
[10:17] <C0p3rn1c> I havent installed it yet
[10:18] <wgrant> ... it also has Beryl.
[10:18] <C0p3rn1c> siretart: sorry I can't really follow, stock ubuntu?
[10:18] <cjwatson> C0p3rn1c: as siretart alludes to, we've put quite a bit of effort into ensuring that standard Ubuntu can meet those needs, and will continue to do so
[10:18] <wgrant> siretart: It's too difficult to click "Search", I'm afraid.
[10:19] <cjwatson> in ways that don't risk our ability to distribute Ubuntu legally
[10:19] <norsetto> thats cool, its got hardinfo too
[10:19] <wgrant> And iPod support.
[10:19] <cjwatson> UUE can probably get away with more since it doesn't have major commercial backing, but we can't necessarily take the same risks
[10:19] <wgrant> Doesn't Rhythmbox do that?
[10:20] <persia> Yes.
[10:20] <cjwatson> however, the standard movie player in Ubuntu can prompt you to download additional codecs as needed (provided they're legal in your jurisdiction)
[10:20]  * wgrant wonders why these people don't just help us.
[10:21] <C0p3rn1c> cjwatson: I'm not asking to become them, I just would like to see it grow more popular, to boost the growth of the ubuntu community
[10:21] <norsetto> wgrant: neah, too much work
[10:22] <wgrant> I don't see how that would help grow the Ubuntu community.
[10:22] <C0p3rn1c> cjwatson: it would put more pressure on the hardware vendors to support linux
[10:23] <cjwatson> C0p3rn1c: we'd rather do that with Ubuntu
[10:23] <cjwatson> and we will continue to do that, including learning from Ubuntu derivatives
[10:24] <cjwatson> there are certainly plenty of cases where we can and do work directly with Ubuntu derivatives, but that requires them coming and working with us
[10:24] <C0p3rn1c> cjwatson: like you said you are restricted with your commercial backing responsibilities
[10:24] <cjwatson> gotta be a two-way street
[10:24] <cjwatson> to my knowledge UUE hasn't come to us
[10:24] <cjwatson> C0p3rn1c: which is one good reason we can't reasonably be expected to support UUE
[10:25] <C0p3rn1c> cjwatson: I'm sure they would like this, it's in there best intrest
[10:25] <lool> "we are all downloading mp3's , illegal movies, etc..." err
[10:25] <liw> C0p3rn1c, it's not because Ubuntu has commercial backing, it's because Ubuntu is a target with enough money that it's worthwhile to sue us that we need to be careful not to do legally controversial things
[10:25] <cjwatson> C0p3rn1c: then they're entirely welcome to come and talk with us about what we can do to help
[10:26] <cjwatson> but we aren't going to advertise something we didn't build; it's just not in our interests
[10:26] <cjwatson> certainly not in preference to Ubuntu itself
[10:26]  * Hobbsee is surprised the trademark people haven't hit it yet
[10:26] <C0p3rn1c> cjwatson: I just thought it would be in your intrest to gain a linux user boost
[10:27] <norsetto> is negerpunk really a music genre (at least in Germany)?
[10:27] <Hobbsee> C0p3rn1c: as would it be for them.  Let the smaller distro go to the bigger distro, no?
[10:27] <Hobbsee> C0p3rn1c: besides, there's a release on here at the moment.
[10:27] <lool> norsetto: http://en.wikipedia.org/wiki/Negerpunk
[10:28] <lool> norsetto: a joke it seems
[10:28] <norsetto> lool: ah ok, somebody seems to be taking it seriously though
[10:28] <cjwatson> C0p3rn1c: it's our opinion that our efforts are best placed doing that with Ubuntu
[10:29] <C0p3rn1c> I really like ubuntu or linux in general, it's clearly the most advanced OS out there, it just hasnt got a big enough public to force the hardware vendors to support linux
[10:31] <C0p3rn1c> I recently switched to ubuntu but I'm experiancing really alot of problems because of the lack of support from these hardware vendors like DELL, Nvidia ,...
[10:31] <cjwatson> yes, we're working directly with hardware vendors on that
[10:32] <cjwatson> which I think is a more appropriate use of energy :-)
[10:34] <C0p3rn1c> to support UUE doesnt take any energy it's just a moral issue it seems
[10:35] <C0p3rn1c> what was the evil part again, I mean that really violates your beliefs ?
[10:36] <Hobbsee> C0p3rn1c: define support, then, if it takes no energy?
[10:37] <persia> C0p3rn1c: Well, "evil" is perhaps the wrong word.  The way that things are done breaks several things, and can cause a number of awkward situations for end users.
[10:37] <persia> For most of the predecessors (Easy Ubuntu, Automatix, etc.), there has been dialog with the creators, and the features requested have been added to Ubuntu.
[10:38] <wgrant> Its legality is somewhat questionable, it has a misleading name, significant ties with Ultamatix, an Automatix derivative, etc., etc.
[10:38] <C0p3rn1c> Hobbsee: well you can decide yourself how far you will go with this support, publicity is also a way to support some distro
[10:38] <liw> debugging my intrepid upgrade crash... fglrx is a kernel module, right? if I'm using it, lsmod should tell me, right?
[10:38] <persia> As has been said previously, if the UUE people wish to be involved, they are welcome, and it's likely there is a policy-compliant way to address the use cases they are solving.
[10:38] <wgrant> C0p3rn1c: Why would Ubuntu be likely to publicise a competing, misleading and likely illegal in many jurisdictions distribution?
[10:40] <liw> competing is not so bad, but unco-operating is
[10:40] <wgrant> liw: Right.
[10:42] <cjwatson> C0p3rn1c: I certainly never said evil (that's a strong word), simply that we'd rather improve Ubuntu than advertise something that will take testing resources away from Ubuntu itself and divert them where it's harder for us to respond to them
[10:42]  * wgrant admits to calling it evil initially.
[10:42] <cjwatson> if UUE were actively cooperating with Ubuntu, that probably wouldn't be an issue since we'd get testers coming straight through (as we do with Kubuntu etc.)
[10:43] <wgrant> Some derivatives end up integrating rather well with Ubuntu, but they really need to start the integration.
[10:43] <cjwatson> C0p3rn1c: but, for the time being, the answer is that we are happy to advertise derivatives that work with us directly, but ones that don't can fend for themselves. I think that's fair
[10:44] <C0p3rn1c> don't can fend?
[10:44]  * liw notes that this UUE discussion is already diverting energy _away_ from solving an Ubuntu upgrade problem ;-)
[10:44] <C0p3rn1c> Excuse me but I don't understand what you mean with that
[10:44] <cjwatson> you misparsed my sentence
[10:45] <cjwatson> "but the ones that don't - those derivatives can fend for themselves"
[10:45] <cjwatson> that's awkward phrasing but perhaps it helps
[10:45]  * C0p3rn1c speaks dutch natively
[10:45] <broonie> "fend for" ~= "look after"
[10:45] <C0p3rn1c> ic
[10:46] <C0p3rn1c> well I'll email this discussion to them, and see if it can start a dialog
[10:48] <C0p3rn1c> I'm also of the opinion that there should be more unity in the linux community instead of going our seperate ways by splitting up in so many distro's
[10:49] <cjwatson> I used to think that, but actually I don't think there's any harm at all in small groups experimenting with different ideas, as long as the results ultimately get fed back into the mainstream if they're good
[10:49] <davmor2> Guys when you click on n-m applet you get current connections.  Also you get VPN Connections.  If you click on that then click on Configure VPN it opens up Network Connections with the VPN tag at the top.  However the all the buttons are greyed out how do you add one?
[10:49] <wgrant> davmor2: Install network-manager-<sometypeofvpn>
[10:49] <wgrant> Where <sometypeofvpn> is vpnc, pptp or openvpn.
[10:50] <wgrant> This should probably be explained somewhere, as a lot of people are confused by it.
[10:50] <liw> I think I am seeing what happened with my upgrade crash: I have linux-restricted-modules-*-generic installed, but fglrx not loaded; when upgrading, the modules package gets uploaded, and this triggers fglrx to be loaded into the kernel, killing it
[10:50] <C0p3rn1c> ok thanks for your time so far,I'm sorry for distracting you guys from your work :)
[10:50] <davmor2> wgrant: I agree
[10:51] <wgrant> liw: Hmm, there aren't fglrx modules any more, are there?
[10:51] <wgrant> There is a DKMSified version, but I don't think that builds with 2.6.27.
[10:52] <liw> wgrant, well, syslog shows it to be loaded just before the system crashes hard
[10:52] <liw> Oct  3 10:42:54 gytha kernel: [44538.401449] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.
[10:52] <wgrant> liw: I guess it could have been from the old l-r-m.
[10:53] <liw> hmm, but those files should have been removed already, surely?
[10:53] <wgrant> liw: No. Different package names.
[10:53] <liw> oh, right
[10:53] <wgrant> l-r-m is named (not just versioned) by kernel version, ABI and flavour.
[10:54] <wgrant> So it looks like l-r-m triggers a reload of kernel modules even if it's not installing modules for the running kernel?
[10:54] <liw> it's not a reload, since the fglrx module was not in the kernel; it loads a completely new module
[10:54] <liw> which is suspicous, to say the least
[10:55] <wgrant> Hmmm.
[10:55] <wgrant> Why wasn't fglrx loaded?
[10:56] <liw> because I don't use it?
[10:57] <wgrant> I know why you don't want it loaded, but what was stopping it from being loaded?
[10:57] <liw> more importantly, what triggered it to be loaded?
[10:57] <wgrant> Working out why it wasn't loaded before might help.
[10:59] <liw> I'm not sure if I did anything special to prevent it; I can't remember it happening, I remember just being happy that the "radeon" driver was being used by X
[11:00] <liw> liw@gytha$ sudo modprobe fglrx
[11:00] <liw> Not loading fglrx module; not used in /etc/X11/xorg.conf
[11:00] <wgrant> Aha.
[11:00] <liw> that's with the same system, rolled back to hardy (that's why it's running off a USB stick: easy to roll back :)
[11:01]  * wgrant has no idea now.
[11:01] <liw> in the xorg.conf from the crashed system, there is still no fglrx mentioned
[11:02] <liw> indeed, the files are identical
[11:03] <tseliot> liw: can you upload your /var/log/Xorg.0.log and your /var/log/Xorg.0.log.old somewhere?
[11:03] <liw> hmm, kvm-source was installed a second before the fglrx module was loaded
[11:03] <liw> tseliot, from the hardy version or the crashed, half-upgraded-to-intrepid version?
[11:04] <tseliot> liw: the latter should be enough
[11:05] <liw> tseliot, http://files.liw.fi/temp/
[11:08] <tseliot> liw: hmm... there's no trace of fglrx in either log
[11:08] <liw> tseliot, yeah, but for whatever reason, there is in syslog
[11:09] <tseliot> liw: can I see it?
[11:09] <liw> sure, just a moment
[11:10] <liw> tseliot, same location; I put dpkg.log there, too
[11:11] <davmor2> wgrant: I documented it in https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/277496
[11:12] <tseliot> liw: What does this say? sudo updatedb && locate fglrx.ko
[11:13] <liw> tseliot, on the hardy or intrepid version?
[11:14] <tseliot> liw: on the version the syslog you posted belongs to
[11:15] <liw> I can't run the intrepid version right now, so I'm doing a "sudo find /mnt -name '*fglrx.ko*'" instead (the intrepid filesystem being mounted on /mnt)
[11:15] <liw> and that returned nothing
[11:20] <davmor2> query on tracker why is the tracker applet enabled in sessions?
[11:20] <persia> liw: Can you chroot into it to access local binaries?
[11:21] <liw> persia, sure
[11:21]  * liw moves stick to desktop from laptpo
[11:21]  * persia doesn't think locate is better than find, but does think this may be a sensible proxy for booting the system when debugging
[11:22] <tseliot> liw: if fglrx were the cause of the problem it would have been mentioned in one of the Xorg logs. What happens on Intrepid, exactly? What are the symptoms of the problem?
[11:22] <liw> tseliot, gdm's screen gets garbled, no response to keyboard, mouse, network, power button (unless I keep it pressed for five seconds to force a poweroff)
[11:23] <liw> tseliot, if X was not restarted after the fglrx module was loaded into the kernel, why would it be in the X logs?
[11:23] <liw> persia, is there something in particular you wanted me to run?
[11:24] <persia> liw: No, just trying to solve your " I can't run the intrepid version right now, so I'm doing a "sudo find /mnt -name '*fglrx.ko*'" instead" issue so you can get to the meat of it.
[11:24] <liw> also, I have backups of the desktop, and I can easily get back to the working hardy system, so I can do any debugging that is necessary
[11:25] <liw> I'm just too ignorant about kernel modules and proprietary drivers to be good at debuggning this
[11:25] <tseliot> liw: can I see your xorg.conf? And BTW the fglrx module can't be loaded as it's incompatible with the Xorg ABI
[11:26] <liw> tseliot, http://files.liw.fi/temp/xorg.conf
[11:27] <tseliot> liw: try leaving only the Device section in your xorg.conf and get rid of the rest
[11:28] <liw> tseliot, I will do that when I next try the upgrade (it takes several hours, so I'd rather look at other things first)
[11:29] <wgrant> tseliot: How can Xorg stop the kernel module from loading?
[11:29] <liw> hm, I can't find any trace of fglrx on the intrepid version
[11:30] <tseliot> wgrant: I said that Xorg won't use something which is not compatible with its ABI
[11:31] <tseliot> wgrant: it can try to use it anyway if you pass it IgnoreABI (but that won't still work)
[11:32] <tseliot> wgrant: a more interesting question is how can you load a module that doesn't exist? ;)
[11:32] <wgrant> tseliot: Indeed, that is probably a better question.
[11:32] <liw> hmm. the hardy version of fglrx has the date that is in syslog
[11:32] <liw> (Feb 25 2008)
[11:33] <wgrant> Could it have crashed before it synced the newly-installed module to disk? Not likely, I guess.
[11:33] <liw> wgrant, quite possible, though
[11:33] <liw> where is fglrx in intrepid? i.e., which package?
[11:34] <wgrant> It doesn't actually build in Intrepid, does it, tseliot?
[11:34] <tseliot> liw: xorg-driver-fglrx
[11:34] <liw> tseliot, even the kernel module?
[11:34] <tseliot> wgrant: it builds but can't be installed
[11:35] <wgrant> tseliot: I speak of the kernel module, which seems to be the issue here.
[11:35] <tseliot> wgrant: because of the video abi specified in the package
[11:35] <tseliot> wgrant: fglrx-kernel-source then
[11:36] <tseliot> liw: fglrx-kernel-source contains the source and the DKMS stuff
[11:36] <tseliot> there's no precompiled module though
[11:36] <liw> what's the source package for that? I can't find it in my mirror
[11:38] <liw> aha, fglrx-installer
[11:39] <tseliot> yep
[11:55] <liw> ok, as far as I can determine, the intrepid version of fglrx is from Sep 8 2008, and if that's true, the kernel module that was loaded was the hardy one
[11:57] <persia> Shouldn't that fail to load because of the significant ABI skew?
[11:57] <liw> persia, version skew compared to what?
[11:57] <persia> kernels.  2.6.24 vs. 2.6.27
[11:57] <persia> Or did it blow up pre-reboot?
[11:57] <liw> the crash happened during the upgrade, so the old kernel was still running
[12:06] <tseliot> liw: aah, so the crash happened during the upgrade. Was the screen saver disabled? If some 3D screen saver was activated that might have caused problems
[12:07] <liw> tseliot, the screen was showing gdm, which doesn't have screen savers apart from blanking or dpms off, as far as I know
[12:07] <liw> but what do I know :)
[12:07] <liw> I was doing the upgrade over ssh, that is
[12:08]  * tseliot scratches head
[12:09] <liw> can upgrading of gtk theme engines cause something like this?
[12:10] <tseliot> hmm... I wouldn't know
[12:11] <tseliot> Riddell: is there a KDE equivalent for yelp?
[12:14] <IntuitiveNipple> Has anyone had success with the desktop amd64 daily installing in a kvm guest (I'm seeing a busybox prompt) ?
[12:14] <liw> hmm, my dpkg.log shows 19 lines showing dkms being unpacked, same version... why so many?
[12:14] <Mithrandir> because dpkg is an interesting beast.
[12:16] <persia> IntuitiveNipple: Which daily?  The beta worked for me.
[12:16] <IntuitiveNipple> " uvesafb: failed to execute /sbin/v86d" - does this make sense running the amd64 desktop CD (the file isn't there) ?
[12:16] <IntuitiveNipple> persia: 2008-10-01 (downloaded this morning)
[12:16] <persia> I downloaded and tested and deleted mine yesterday, but intrepid-desktop-amd64.iso ?
[12:17] <IntuitiveNipple> yes
[12:17] <cjwatson> v86d> known
[12:18] <IntuitiveNipple> cjwatson: thanks :) That'll save me thinking I've messed it up
[12:18] <Riddell> tseliot: khelpcentre
[12:19] <tseliot> Riddell: thanks a lot
[12:20] <IntuitiveNipple> cjwatson: Are there other problems with that? I exit-ed busybox and the got stuff like "Target filesystem doesn't have /sbin/init." and missing directories? I'm wondering if those errors are a by-product of the original issue, or are part of the main problem
[12:20] <cjwatson> IntuitiveNipple: the v86d error is essentially harmless (unless you end up with a corrupted framebuffer). You have some other problem
[12:21] <IntuitiveNipple> cjwatson: Hmmm
[12:21] <cjwatson> IntuitiveNipple: /casper.log and dmesg might have more information for a bug report
[12:21] <cjwatson> IntuitiveNipple: your problem is indicative of failing to mount the CD
[12:23] <IntuitiveNipple> cjwatson: "Unable to find a medium containing a live file system"
[12:24] <cjwatson> yes, as I said
[12:24] <cjwatson> if the kernel fails to detect your CD drive then you'll get that symptoms
[12:24] <cjwatson> s/s$//
[12:25] <IntuitiveNipple> cjwatson: this *should* be it, I think (it has already booted the ISO image) "scsi 1:0:0:0: CD-ROM            QEMU     QEMU DVD-ROM     0.9. PQ: 0 ANSI: 5"
[12:27] <cjwatson> IntuitiveNipple: I'd rather not be the guy who debugs this with you - was just giving you a pointer
[12:27] <cjwatson> IntuitiveNipple: #ubuntu-kernel is a better place to follow up if you don't want to file a bug right away
[12:27] <liw> anyone here know how dkms works?
[12:27] <cjwatson> (you've run off the end of my expertise)
[12:28] <IntuitiveNipple> cjwatson: I wasn't suggesting you do, but that would be an expected report wouldn't it? The only thing I can see is that "mounting root file system..." occurs about 3/4 second *before* the kernel logs finding the CD drive
[12:28] <IntuitiveNipple> liw: Yes, I di
[12:28] <IntuitiveNipple> s/di/do/
[12:29] <liw> IntuitiveNipple, would you happen to be able to understand what the packages when upgrading from hardy (where fglrx was not under dkms) to intrepid (where it is)? is there a chance that, say, /etc/init.d/dkms_autoinstall has a bug that triggers the fglrx module in hardy to be loaded into the hardy kernel during an upgrade?
[12:32] <IntuitiveNipple> liw: I can imagine that happening, yes, since dkms is linked in via "/etc/kernel/postinst.d/dkms"
[12:33] <liw> IntuitiveNipple, yeah, I got that far, but reading the init.d script made me want to take a break :) my problem is that it seems that loading the old fglrx module into the kernel crashes it
[12:33] <liw> hm, perhaps I can test this by upgrading only dkms
[12:34] <IntuitiveNipple> dkms should check at boot-time if the module is available, and build a new one for the running kernel if it isn't there already
[12:37] <IntuitiveNipple> Don't forget, "dkms status" will show you which modules are built and installed for each kernel version
[12:43] <liw> hm, merely upgrading dkms did not reproduce the problem
[12:58] <IntuitiveNipple> liw: Mario has made some significant improvements to DKMS since the hardy version; maybe the cause is the timing of the dkms update - if it is after other dkms modules it has a problem, but if before, it might be okay?
[13:03] <liw> IntuitiveNipple, see logs at http://files.liw.fi/temp/
[14:10] <jdong> slangasek: I'm gonna rebase the gutsy backport of firefox/xulrunner against the hardy-updates release today...
[14:11] <elmo> Ubuntu ftpmaster (drescher) is being migrated to a new (faster) box with more disk; publishing won't be happening, and uploads won't be accepted till DNS propagates
[14:11] <elmo> (PPAs are unaffected)
[14:11] <Hobbsee> sweet!
[14:13] <Hobbsee> pitti: oh dear.  Have you seen https://bugs.edge.launchpad.net/ubuntu/+source/jockey/+bug/277419 yet?
[14:14] <Hobbsee> or is that a tseliot bug?
[14:17] <tseliot> Hobbsee: I work on both the Nvidia packages and Jockey, therefore either way you're right
[14:17] <Hobbsee> tseliot: cool.  Get fixing :)
[14:17] <tseliot> yes, I'm reading the report
[14:21] <kirkland> persia: regarding bug #277517, are you wanting this for intrepid, or is that just a placeholder for Jaunty?
[14:22] <persia> kirkland: Well, I'd like it for intrepid, and it fixes two FTBFS issues, but I'm not sure how many users with that HW have vmx support.
[14:22] <persia> works for me on some lpia HW, but other lpia HW doesn't have vmx.
[14:22] <persia> I don't have ia64, so I'm just trusting IntuitiveNipple
[14:32] <persia> kirkland: Do you have concerns about the patch, or a preference for intrepid/jaunty?
[14:35] <superm1> tseliot, I had thought -96 and -71's modaliases were going to be removed as depends from jockey
[14:35] <superm1> and nvidia common
[14:35] <superm1> since they are not functional ?
[14:37] <tseliot> superm1: removing them from nvidia-common will be enough
[14:38] <tseliot> superm1: I'll talk to pitti about this next week
[14:39] <superm1> tseliot, and of course if ever they are made functional by another release from nvidia, it's an SRU away
[14:41] <kirkland> persia: no direct concerns, just a lack of testing on those platforms over the rest of the dev cycle
[14:41] <ScottK> At least the chances of regression are low.
[14:41] <kirkland> persia: i was hoping for soren's take on it
[14:41] <kirkland> ScottK: :-P
[14:41] <tseliot> superm1: yes, right
[14:42] <persia> kirkland: Makes sense.  As much as anything, it's an archive-consistency concern for me.  To be honest, I don't ever expect to use KVM on the lpia device I have that supports it (it has a 5" screen)
[14:42] <kirkland> persia: ;-)
[14:43] <soren> kirkland: I don't mind an lpia build of kvm. I just didn't think the lpia kernels had kvm support.
[14:46] <kirkland> soren: ia64?
[14:48] <RainCT> mdz: Hey. Note that you've added genisoimage as a Depends instead of a Recommends to ubuntu-dev-tools (and I'd prefer if it was a Suggests, anyway :P). I also wanted to ask you to add copyright information for it to the script's header and debian/copyright
[14:49] <soren> kirkland: I'm not sure it builds on IA64? I know KVM has support for it in git, but I wans't sure about the release tarballs.
[14:49] <persia> IntuitiveNipple: Can you share your experience with ia64?
[14:50] <RainCT> mdz: (well, thinking about it again, nevermind about it being a Suggests -as other similarly important dependencies are also Recommends and not Suggests-, but it's still in the wrong line)
[14:50] <kirkland> soren: this discussion hinges on persia's comments in that bug
[14:50] <mdz> RainCT: why suggests?  all of the other optional dependencies are recommends
[14:50] <mdz> RainCT: GMTA :-)
[14:51] <mdz> RainCT: my mistake of course; it doesn't even match the changelog.  I've fixed it now
[14:53] <RainCT> mdz: OK, thanks :)
[14:53] <mdz> RainCT: I've also added the copyright info now
[14:55] <soren> kirkland: Ah, I suppose I should actually read the bug.. :)
[14:56] <soren> kirkland: I'm not convinved ia64 is present in the kvm-72 tarballs. I think it popped up later than that.
[14:57] <kirkland> soren: right, persia says he backported it from 74 to 72
[14:57] <persia> Yeah.  I don't understand why the patch works even, to tell the truth, but it builds and installs and runs, which made me think it was probably worth it.
[15:01] <kirkland> I have neither ia64 nor lpia hardware
[15:05] <soren> persia: You have IA64 hardware?
[15:05] <persia> No.
[15:05] <soren> How do you know that it runs, then?
[15:05] <persia> I have lpia, including lpia with vmx, but no ia64.
[15:05] <persia> I don't, as I said in the bug.
[15:05] <soren> But you just said now?
[15:06] <persia> That's also why I asked for IntuitiveNipple's input.
[15:06]  * soren goes to look at the bug again..
[15:06] <persia> Oh, right.  insert a "on lpia" in my previous statement.
[15:07] <soren> Ah.
[15:07] <soren> IntuitiveNipple has IA64 hardware?
[15:07] <persia> Dunno.  IntuitiveNipple wrote the patch.
[15:08] <soren> IntuitiveNipple: ping
[15:08] <Riddell> mdz, Keybuk: motu council are blocking on a core-dev application, can the relevant person just turn up at the next tech board meeting?
[15:12] <mdz> Riddell: I don't see why not, but I'd like to know why the council is blocked on it
[15:13] <mdz> Riddell:  have you asked them? (half of them are here right now)
[15:14] <Riddell> mdz: I have, a couple have answered and don't know why it hasn't been processed
[15:14] <soren> Riddell: I have a few outstanding applications that I intend to look at before I punch out today.
[15:14] <soren> Riddell: apachelogger's being one of them, apparantly.
[15:14] <apachelogger> \o/
[15:15] <Riddell> soren: a month is far too long for this to take
[15:17] <soren> Riddell: I agree.
[15:17] <soren> Riddell: We've been discussing ways to improve this process extensively over the last couple for weeks.
[15:18] <Riddell> mdz: when is the next tech board meeting?  I can't see it on fridge
[15:26] <mdz> Riddell: we've asked again and again for that to be fixed :-(
[15:26] <mdz> Riddell: it's next Tuesday at 14h UTC
[15:27] <Riddell> nixternal: can you add that to fridge ^^
[15:30] <siretart> mdz: will ffmpeg be on the agenda? or do you prefer to discuss this after release?
[15:33] <mdz> siretart: apologies for not getting back to you sooner on that; I read the email but didn't have a ready answer and have neglected it
[15:33] <mdz> siretart: assuming we have a quorum, we can certainly talk about it at the meeting
[15:34] <mdz> siretart: could you add it to TechnicalBoardAgenda?
[15:36] <siretart> mdz: I'm not sure if I'll be able to make it to the meeting, but sure!
[15:37] <siretart> mdz: but perhaps you could answer me in advance a short question: I now have a unstripped replacement package ready in ~motumedia that works on at least one tester system. I'd like to upload it to multiverse now
[15:38] <siretart> mdz: since we have stuff in multiverse like x264 and similar, I wouldn't expect patent problems here, but I wanted to check in advance to avoid further confusion here
[15:43] <mdz> siretart: isn't that the same question?
[15:44] <siretart> mdz: not necessarily. I'd consider having a seperate source package with the encoders as a bad workaround I'd rather avoid
[15:46] <mdz> siretart: you're asking whether it's OK to have the codecs in Ubuntu, right?  It doesn't matter much which package they're in
[15:46] <siretart> mdz: we already have these codecs in ubuntu. this question is if there are other than patent concerns in ffmpeg that you were aware of
[15:47] <nixternal> mdz: tech board is the 7th or 14th?
[15:48] <mdz> nixternal: 7th, 21st, ...
[15:49] <mdz> siretart: assuming the copyright file is correct, I don't see anything to worry about
[15:49] <mdz> siretart: I'm preparing a response to your email though
[15:51] <nixternal> mdz: roger that...adding it to the fridge
[15:51] <siretart> mdz: thanks!
[15:52] <mdz> nixternal: thanks very much
[15:57] <nixternal> mdz: do you all have an agenda on the wiki or no?
[15:59] <mdz> nixternal: TechnicalBoardAgenda
[15:59] <nixternal> groovy
[16:03] <nixternal> added the 7th and 14th, 14:00 to 16:00 UTC...before I add a few more every 2nd week thereafter, those time frames are correct?
[16:03] <nixternal> mdz: ^^
[16:04] <mdz> nixternal: it is every two weeks from the 7th
[16:04] <mdz> nixternal: ie. no meeting on the 14th
[16:04] <nixternal> err, gotcha
[16:14] <duskyink> hi all, I am new to Open source and have made a small change to gedit and compiled. Where does my output program get saved?
[16:18] <siretart> duskyink: file a bug in the gnome bugzilla and describe your modifications there
[16:28] <cjwatson> duskyink: you mean where did the compiler put it?
[16:39] <Adri2000> cjwatson: time to take a look at an sru?
[16:59] <munckfish> cjwatson: got a sec re #274854?
[17:00] <munckfish> LP: #274854
[17:00] <munckfish> https://bugs.launchpad.net/ubuntu-ps3-port/+bug/274854
[17:01] <munckfish> I think it uncovers a more general issue - domount in /lib/init/mount-functions.sh check /proc/filesystem to see if the requested filesystem type is supported
[17:01] <munckfish> however for filesystems compiled into the kernel as modules
[17:01] <munckfish> they won't be listed
[17:01] <munckfish> e.g. take ext2
[17:02] <munckfish> that doesn't get used on boot on my desktop system
[17:02] <munckfish> consequently it isn't listed
[17:11] <munckfish> I think it's being too careful - running mount will cause the kernel to search for a matching module if one isn't loaded
[17:11] <munckfish> So I think this check isn't helpful
[17:24] <cjwatson> Adri2000: not at the moment, sorry
[17:25] <cjwatson> munckfish: hmm, I'd sort of like to know why it was added in the first place
[17:25] <cjwatson> munckfish: I agree it looks unnecessary but I usually like to find out the reasoning before deleting code
[17:25] <munckfish> cjwatson: ok I'll go hunt
[17:26] <cjwatson> munckfish: it's worth noting that domount will exit zero if the filesystem is entirely unavailable, while mount will exit non-zero
[17:26] <cjwatson> which might be the distinction it's trying to achieve (speculating)
[17:27] <munckfish> well surely just interpreting mount's exit codes would do the trick?
[17:27] <munckfish> as long as we're careful not to upset set -e
[17:28] <cjwatson> does it have a reliably distinct exit code for "filesystem not supported"? the manual page doesn't document that
[17:30] <munckfish> cjwatson: seems to be returned 32 for various errors
[17:30] <munckfish> I'll check the source
[17:34] <soren> "mount -t thisisnotavalidfilesystem /dev/null /mnt" returns 32.
[17:36] <cjwatson> ok, but what else returns 32?
[17:36] <cjwatson> 'sides, that's only a hypothesis, might not have been the original reason
[17:37] <soren> ./sundries.h:#define EX_FAIL	       32	/* mount failure */
[17:37] <soren> Anything.
[17:37] <munckfish> The 32 is the default fail
[17:37] <munckfish> oh you got there first
[17:38] <munckfish> So if we let the kernel do the searching and loading
[17:39] <munckfish> then we can only report if the mount failed or not
[17:39] <munckfish> or
[17:39] <munckfish> let mount's own message echo out
[17:40] <munckfish> which wouldn't be so neat
[17:44] <munckfish> cjwatson: ok I'll spend some time on this later see if I can find out who wrote the code and why it needed to be that way
[17:45] <munckfish> and I'll see if I can propose and alternative
[17:45] <cjwatson> ok
[17:45] <cjwatson> thanks
[17:45] <cjwatson> an obvious workaround would be to special-case spufs
[17:45] <munckfish> yeah I already have a patch waiting like that
[17:45] <munckfish> but then I realised this more general issue
[17:45] <cjwatson> (crappy, but it would work)
[17:45] <munckfish> exactly
[17:46] <munckfish> actually the patch was to call modprobe spufs in mountkernfs.sh if the module isn't listed in the output of lsmod
[17:46] <munckfish> actually there's a thought (ding!)
[17:47] <munckfish> cjwatson: the kernel code which loads the filesystem modules if they aren't already loaded
[17:47] <munckfish> uses the filesystem name as the module name
[17:47] <munckfish> maybe we should be checking lsmod instead of /proc/filesystems ?
[17:48] <cjwatson> certainly wouldn't work for everything
[17:48] <cjwatson> <cjwatson@sarantium ~>$ lsmod | grep tmpfs
[17:48] <cjwatson> <cjwatson@sarantium ~>$ grep tmpfs /proc/filesystems
[17:48] <cjwatson> nodev   tmpfs
[17:48] <cjwatson> well, tmpfs is special-cased, but try sysfs
[17:49] <cjwatson> the sorts of filesystems mounted using domount are predominantly special ones like that
[17:49] <munckfish> see get_fs_type(...) in fs/filesystems.c
[17:49] <munckfish> oh darn of course this is the opposite of the first problem
[17:49] <cjwatson> sure, doesn't change the fact that sysfs isn't a module
[17:49] <munckfish> if a filesystem isn't compiled as a module it won't be listed
[17:49] <cjwatson> oh, also, domount supports trying one filesystem and falling back to the next
[17:50] <cjwatson> honestly I'm beginning to think special-casing spufs is actually sane
[17:50] <munckfish> that's ok though
[17:50] <munckfish> You try one filesystem type (check /proc/modules || check lsmod)
[17:50] <cjwatson> more expensive to call mount than to grep /proc/filesystems, and speed matters in the boot process
[17:50] <munckfish> if that fails both those checks you do the same checks for the second type
[17:51] <cjwatson> dude, basically none of the filesystems on which domount is typically called are modules
[17:51] <cjwatson> /proc/modules is not going to make things better
[17:51] <cjwatson> you'll end up having to call mount anyway and suffer the speed penalty for things that fall back from one filesystem to another
[17:52] <munckfish> Actually I was starting to think checking both /proc/filesystem and lsmod that way we don't call mount
[17:52] <munckfish> anyway
[17:52] <cjwatson> but in your case /proc/modules won't help
[17:53] <munckfish> for spufs it will
[17:53] <cjwatson> because if the module isn't loaded, it's not in /proc/filesystems
[17:53] <cjwatson> only if spufs is already loaded :)
[17:53] <munckfish> groan :( - doh doh doh doh
[17:53]  * munckfish slaps himself on the forehead
[17:53] <munckfish> Ok
[17:54] <cjwatson> you'd have to try modinfo or something, which walks the filesystem
[17:54] <munckfish> So you'd rather see a special case for spufs in domount
[17:54] <cjwatson> I don't like it, but I don't see a much better alternative
[17:54] <cjwatson> it's not like this stuff is used for general filesystem mounting, it's all special cases anyway
[17:55] <cjwatson> maybe we could move the [ -d /spu ] && grep -qs '^cpu.*Cell' /proc/cpuinfo check into mount-functions and simplify mountkernfs
[17:55] <cjwatson> dunno
[17:58] <munckfish> cjwatson: interesting idea
[17:59] <munckfish> cjwatson: ok let me think thru all of this and get back to you
[17:59] <mib_rjshf4> hi, anyone here more or less familiar with the e1000e bug? and updated about the situation?
[18:00] <munckfish> mib_rjshf4: I think I saw something about it in one of the mailing lists today
[18:01] <munckfish> 1 sec
[18:01] <cjwatson> mib_rjshf4: https://lists.ubuntu.com/archives/intrepid-changes/2008-October/007851.html and https://lists.ubuntu.com/archives/intrepid-changes/2008-October/007852.html (i.e. fix on its way)
[18:02] <munckfish> mib_rjshf4: there's some discussion of it here https://lists.ubuntu.com/archives/kernel-team/2008-October/003219.html
[18:04] <mib_rjshf4> cjwatson, munckfish, thanks, I'll read the pages :)
[18:04] <munckfish> cjwatson: one other avenue I can explore is whether the kernel team would mind spufs being a builtin
[18:05] <munckfish> in the powerpc64-smp kernel
[18:05] <munckfish> that would be a single character fix in one file
[18:09] <cjwatson> mib_rjshf4: the binaries are on their way into the archive now
[18:09] <cjwatson> munckfish: sure, that sounds possible too
[18:10] <munckfish> I've just asked Ben now waiting to see what he says
[18:10] <mib_rjshf4> Read the pages, nothing new about the true cause of the problem. I have an Ethernet Adapter RTL8101E on an ICH8 platform. Supposedly I'm safe, I'm just uncomfortable because of that guy with a non-ICH8 but with a RTL8101E who also got it's firmware with all 0xFF -- http://lkml.org/lkml/2008/9/24/133 . On the other hand, I can't dump my Ethernet's card EEPROM because the "Opperation is not supported", so writing to
[18:12] <cjwatson> you asked about the situation, I thought "fix on its way" was kind of what you were looking for
[18:12]  * cjwatson <- just an archive administrator not a kernel hacker
[18:12] <mib_rjshf4> cjwatson: yes, and thanks for the info :)
[18:12] <mib_rjshf4> cjwatson: I'm not complaining, just explaining the full situation
[18:13]  * cjwatson nods
[18:13] <mib_rjshf4> cjwatson: I thought it could be avoided me having to dump all the details if someone had found the real issue, which didn't happen, and as such, I had to expose my rationale :)
[18:14] <mib_rjshf4> anyway, upgrading now lol, if my Ethernet dies I'll come here and cry
[18:19] <munckfish> cjwatson: do you happen to know when the next daily live build will be? I'm waiting for that as the beta for PS3
[18:20] <munckfish> and I note the last one for ports was 30 Sep
[18:21] <cjwatson> munckfish: slangasek turned the cron jobs off for beta, I assume he'll turn them back on soon
[18:21] <cjwatson> mib_rjshf4: err, if you're concerned, you should WAIT until the fixed binaries hit the archive
[18:21] <cjwatson> mib_rjshf4: wait a day
[18:22] <munckfish> cjwatson: ok thx. Logging off now speak later
[18:39] <slangasek> yes, CD cronjobs re-enabled now
[18:42] <asomething> Could a core-dev/main-sponsor please take a quick look at Bug #209173 and tell me if my proposed course of action is acceptable?
[18:48]  * iulian is looking for an archive admin to sync a package - bug 274276
[18:58] <asomething> or i suppose anyone that could give me some direction
[19:00] <sbeattie> slangasek: FYI, bug 258985 looks to be a regression (specific to some hardware) introduced by the hardy-proposed kernel.
[19:04] <james_w> asomething: makes sense to me
[19:05] <asomething> james_w: thanks. the debian maintainer said the new rev would be uploaded when the old one hits testing, and that happened today, so i think it should work out
[19:35] <slangasek> bryce: is bug #272157 on your radar?  someone sent a comment to the release team blog about it; it appears to be fixed upstream
[19:44] <bryce> slangasek: thanks I'll take a look
[20:00] <bdmurray> Is there any easy way to switch back from using a ppa version of a package?
[20:00] <bdmurray> Or packages rather
[20:01] <slangasek> with a manageable list of affected packages?
[20:03] <Riddell> hmm, my uploads don't seem to be being accepted
[20:03] <bdmurray> slangasek: maybe
[20:05] <slangasek> bdmurray: disable the ppa in your sources.list, run apt-get update, then apt-get install $p1/intrepid $p2/intrepid [...]
[20:05] <slangasek> alternatively, if you do the first two steps, update-manager may offer to downgrade them for you, I don't remember
[20:05] <slangasek> (and assuming these are downgrades, it's not guaranteed that this will work - packages don't always support downgrading)
[20:06] <superm1> bdmurray, the other GUIish way is to open synaptic, find your package and hit "ctrl-e"
[20:07] <superm1> lets you pick the version you want to install from those in the repositories you have in sources.list
[20:07] <ion_> One can do an aptitude search for non-Ubuntu packages.
[20:07] <IntuitiveNipple> bdmurray: I'm pretty sure I've done that using apt-get --reinstall install <pkg> -t <release>
[20:07] <ion_> installed ones, that is.
[20:07] <bdmurray> thanks everyone!
[20:08] <IntuitiveNipple> bdmurray: or, maybe it was apt-get --reinstall install <pkg>=version-string
[20:09] <bdmurray> I went the synaptic way, but downgrading isn't nearly as easy as testing a ppa
[20:19] <emgent> heya
[20:30] <Adri2000> Keybuk: is there a chance we get MoM patches merged for the beginning of the jaunty dev cycle?
[20:48] <bryce> slangasek: where's the release team blog btw?
[20:48] <slangasek> release-blog.ubuntu.com, syndicated on planet
[20:49] <slangasek> (I didn't approve the comment, if that's what you're looking for)
[20:49] <bryce> ah ok
[20:49] <slangasek> it's the first legitimate comment there's been, and I haven't decided whether we really want to take comments there
[21:15] <superm1> slangasek, at what point do you want to make a call on the bluez 4.x stuff?  A majority of the issues being reported have been broken for the earlier release too.
[21:16] <slangasek> superm1: I was going to install it myself and get a first-hand impression this weekend :)
[21:16] <superm1> slangasek, OK :)
[21:27] <psusi> Keybuk: was wondering if you have a moment to help me understand the revision history of upstart... I'm trying to learn bzr and am a bit confused trying to follow the branch/merge paths in upstart
[21:37] <nxvl> slangasek: is the new kernel waiting in some kind of queue?
[21:37] <slangasek> no
[21:37] <slangasek> linux-restricted-modules is; I'll push that through
[21:39] <nxvl> mm
[21:39] <nxvl> odd
[21:40] <nxvl> for some reason my kernel wasn't updating
[21:40] <nxvl> i was still having linux-image-4
[21:40] <nxvl> linux-image-2.6.27-4*
[21:40] <slangasek> the metapackage isn't uploaded yet; you won't get an automatic update
[21:40] <slangasek> (the metapackage gets uploaded after lrm)
[21:40] <nxvl> oh
[21:40] <nxvl> that's the why
[21:42] <nxvl> i will wait then
[21:48] <cody-somerville> bug #262156
[21:57] <kirkland> slangasek: am I correct in assuming it's too late for musica to be added to the intrepid archive?  https://launchpad.net/ubuntu/intrepid/+queue
[21:57] <turtle_> whats musica?
[21:57] <slangasek> kirkland: it's possible one of the archive admins will process it; I've been jumping over the sourcefully new stuff myself
[21:58] <kirkland> slangasek: is there anything i could do to help it along?
[21:58] <superm1> tseliot, for intrepid, are you still going to be supporting envy-ng and the appropriate binary packages that go with it?
[21:58] <slangasek> kirkland: um... find an archive admin who's not me that might process it :)
[21:59] <kirkland> slangasek: ;-)
[22:00] <kirkland> infinity: any desire to wield archive-admin powers and add a package to the universe archive for me?  :-)
[22:00] <tseliot> superm1: only envyng-core and envyng-qt
[22:00] <superm1> tseliot, may i make a suggestion then for it?
[22:00] <tseliot> superm1: shoot
[22:01] <nxvl> kirkland: btw, why you didn'y give it the 2nd ACK after getting motuship?
[22:01] <superm1> tseliot, perhaps don't use the exact same package names that already provide nvidia and fglrx, but for new versions just expect them to come through the backports pocket
[22:01] <superm1> tseliot, so envy would instead just grab stuff from backports to add on
[22:02] <kirkland> nxvl: b/c i didn't want to ack myself :-)
[22:02] <kirkland> nxvl: thought it would look better to have 2 other MOTU ack it
[22:02] <kirkland> nxvl: is self ack'ing even legal on REVU?
[22:03] <tseliot> superm1: yes, I guess it's doable. I have to think about the package names though
[22:03] <nxvl> kirkland: yes it is
[22:03] <superm1> tseliot, it would cause less churn I think, and then people who don't use envy will still be able to benefit from it being in the backports pocket
[22:03] <kirkland> nxvl: that's dirty!
[22:04] <nxvl> kirkland: since you are a motu, you are supposed to package your stuff in a good way
[22:04] <nxvl> kirkland: no, you need ack from 2 MOTU's and you are one, so why not?
[22:04] <sourcemaker> Are you having problems on your webpage (http://www.kubuntu.org)?
[22:04] <tseliot> superm1: yes, I see your point, I don't know if we really want to use different package names, that's all
[22:05] <nxvl> kirkland: the idea es that any motu should be technically enough to decide that, so it's assumed that if a MOTU packages something it is in a good shape
[22:05] <kirkland> nxvl: okay, that sounds reasonable
[22:05] <tseliot> superm1: it's something we should plan carefully
[22:05] <superm1> tseliot, well what argument is there toward using different package names for envy stuff?
[22:06] <tseliot> superm1: I don't do that any more in Intrepid
[22:06] <sourcemaker> I am able to download php files... I am not just but that sound's not good for me... http://www.kubuntu.org/doc/index.php... just for you information...
[22:07] <superm1> tseliot, oh what do you currently do in intrepid then?  I haven't actually looked at the implementation yet?
[22:07] <superm1> tseliot, perhaps you already have done what i'm proposing then
[22:07] <tseliot> superm1: I simply install the packages in main, as Jockey does. Actually I'm working on Jockey too
[22:10] <superm1> tseliot, oh then there isn't much of a point to envy being around at all then is there?
[22:11] <tseliot> superm1: there's still some use-case but we'll discuss this with pitti at the next UDS (if I'm invited...)
[22:12] <superm1> tseliot, right the use case i see is just the newer versions (ala my backports suggestion)
[22:14] <tseliot> superm1: and the textual interface and the level to which we can customise installations for different cards
[22:14] <tseliot> and so on
[22:14] <superm1> tseliot, ah didn't realize there was a text interface
[22:14] <superm1> cool
[22:15] <tseliot> superm1: yes, envyng-core
[22:15] <superm1> but yeah this will be a good discussion for UDS
[22:15] <tseliot> superm1: envyng -t
[22:15] <tseliot> superm1: right
[22:15] <norsetto> tseliot: btw, are the new packages ready?
[22:16] <tseliot> norsetto: you can apply the debdiffs which I attached for envyng-core and envyng-qt and ignore the gtk one
[22:17] <norsetto> tseliot: we are not sponsoring, we only have to assess if you can get an exception
[22:19] <tseliot> norsetto: is there anything else I can do? Maybe add the output of diffstat?
[22:19] <tseliot> norsetto: or am I missing the point?
[22:21] <norsetto> tseliot: you just have to confirm that your package will only ship a transitional -gtk binary (which will not depend on the -qt one) so that you get your exception and then you may proceed with sponsoring
[22:23] <tseliot> norsetto: ok, so would something like a transitional package with "Depends: envyng-core" be ok?
[22:25] <tseliot> norsetto: envyng-core contains the main libraries and the textual interface
[22:25] <norsetto> tseliot: yes, but make sure also that the description is updated
[22:27] <tseliot> norsetto: yes, sure. I'll fix it tomorrow and attach the new debdiff to the bug report
[22:27] <norsetto> tseliot: perfect, thanks
[22:28] <tseliot> norsetto: thank you ;)
[22:28] <norsetto> tseliot: or rather, thanksissimo
[22:28] <tseliot> hehe
[22:37] <turtle_> if I installed snes9x-x, where should it be located
[22:37] <turtle_> ?
[22:37] <cjwatson> dpkg -L snes9x-x
[22:37] <cjwatson> also, #ubuntu ;-)
[22:38] <turtle_> that opens it from the terminal?
[22:40] <mneptok> turtle_: support questions in #ubuntu, if you please. :)
[22:42] <turtle_> sorry, forgot i was in here
[22:43] <mneptok> i feel that way every day when i wake up.
[22:51] <bryce> hey slangasek, with -ati I'm finding that I'm needing to pull in most of the recent changes to the git driver to solve various bugs in launchpad.  I'm wondering about just putting in a newer git snapshot that has all the changes.  Do you have an opinion?
[22:51] <slangasek> bryce: are the changes all bugfixes, or are there a lot of structural changes or features?
[22:52] <bryce> pretty much all bug fixes
[22:52] <bryce> no structural changes or features
[22:53] <slangasek> then I'm happy for you to upload, if you think the risk of regression is reasonable
[22:54] <cody-somerville> slangasek, do you run an ATI card?
[22:55] <slangasek> no
[22:55] <slangasek> am I required to commiserate before suggesting bryce upload? :)
[22:56]  * cody-somerville shrugs.
[22:56] <cody-somerville> I run nvidia
[22:56] <cody-somerville> bryce, regress as you see fit
[22:56] <slangasek> er, what
[22:57] <cody-somerville> slangasek, as long as we good nvidia goodness, ati doesn't matter much :P
[22:58] <cody-somerville> bryce, Is the failsafex stuff not finished? When I click ok with almost any of the different options, the screen just goes away and comes back.
[22:58] <bryce> cody-somerville: no all that should work
[22:58] <cody-somerville> bryce, its all broken for me :(
[22:58] <bryce> cody-somerville: it's pretty simple bash stuff so if you want to poke into it you might be able to figure out what's going wrong
[22:59] <cody-somerville> bryce, Also, I noticed installing the nvidia restricted drivers installs nvidia-settings
[22:59] <cody-somerville> bryce, although it provides a lot of nice functionality, it never writes an xorg.conf file that whatever version of X we have in Intreprid understands.
[23:00] <superm1> cody-somerville, it's open source..... ;)
[23:00] <cody-somerville> superm1, nvdia-settings?
[23:00] <superm1> yup
[23:00] <PovAddict> I think I found a package dependency problem... I installed libasio-dev, included one of its headers from my program, and I get this compiler error:
[23:00] <PovAddict> /usr/include/asio/detail/epoll_reactor.hpp:29:59: error: boost/date_time/posix_time/posix_time_types.hpp: No such file or directory
[23:01] <PovAddict> which would probably be solved if I install libboost-date-time-dev
[23:01] <PovAddict> shouldn't libasio-dev depend on it?
[23:03] <slangasek> PovAddict: yes, it should; please file a bug
[23:04] <PovAddict> ah looks like it depends on libboost-dev
[23:04] <PovAddict> and libboost-dev recommends libboost-date-time-dev
[23:04] <PovAddict> so if the maintainer has his package manager set to auto-install recommended packages, he wouldn't notice the problem :)
[23:05]  * PovAddict makes a launchpad account
[23:19] <LaserJock> bryce: around?
[23:19] <bryce> yep
[23:21] <LaserJock> bryce: I put in a new .fdi file in /etc/hal/fdi/policy and restarted hal but to no effect
[23:22] <LaserJock> bryce: has something changed?
[23:24] <bryce> not afaik
[23:25] <LaserJock> hmm
[23:25] <LaserJock> well that .fdi used to work (it's the one I put on the wiki page)
[23:26] <wtgee> Howdy all....my /etc/hosts file keeps getting overwritten as of todays updates.  Am I supposed to enter a host alias somewhere else now?
[23:26] <wtgee> Overwritten after each reboot I should say
[23:31] <slangasek> wtgee: this is a network-manager bug
[23:32] <slangasek> it's been discussed over the past few days; I'm not sure if there's an open bug report
[23:33] <wtgee> slangasek: I thought I read something about it somewhere but of course didn't think it applied to me so I didn't pay attention.
[23:33] <wtgee> slangasek: But I thought I had read that they would be handled via the network manager but I don't see anywhere to do that.   thanks for the info though.
[23:36] <LaserJock> bryce: ok, well, I restarted X and it still doesn't take it
[23:36] <slangasek> wtgee: the bug is that there's no reason at all for n-m to manage /etc/hosts by default
[23:36] <LaserJock> bryce: looking in the X log it looks like *again* there are two devices set up and my configuration is getting overriden
[23:37] <LaserJock> so how exactly is a person supposed to configure their devices? :-)
[23:37] <LaserJock> oh wait
[23:38] <LaserJock> the touchpad tab is back in the mouse configuration tool, sweet
[23:39] <wtgee> slangasek: That's sort of what I was confused about.  Upon further reflection I think what I read was the the network manager was clobbering /etc/network/interfaces and that one shouldn't manually edit that file.  That is fine with me as I would expect that, but not /etc/hsots
[23:39] <wtgee> or /etc/hosts
[23:39] <slangasek> right
[23:40] <slangasek> the /etc/network/interfaces incompatibility was present in beta, and fixed in the same upload that started fiddling with /etc/hosts
[23:40] <wtgee> I'm looking through the tracker now to see if it is reported yet and will report if not
[23:42] <LaserJock> bryce: btw, is there any transition possibility for all the people who used xorg.conf to set up their touchpads?
[23:43] <LaserJock> it seems like it'd be a fairly big "OMG, Ubuntu killed my devices" moment :-)
[23:54] <wtgee> slangasek: Should I file it as a network-manager bug or unknown?
[23:55] <slangasek> network-manager, there's nothing unknown :)
[23:55] <wtgee> slangasek: My first bug report! Woohoo! Thanks for the info.