[00:00] <wgrant> (and creating a new PPA won't force an already generated key to be reuploaded)
[00:00] <wgrant> The key clearly exists on the secure server that signs things, but I probably won't be able to grab it from there and reupload the public half to the keyservers until Monday
[06:10] <Lord-Kamina> wgrant, thanks for clearing it up.
[18:30] <nickoe> Hello
[18:30] <nickoe> Is it possible to download a mail archive from the lauchpad mailing list service?  such that it can be fed to patchwork sor something like tahat?
[19:18] <sdeziel> hello, I recently created a new team + PPA on LP (https://launchpad.net/~sdeziel.info/+archive/ubuntu/infra) but I cannot fetch the PPA's GPG key: https://keyserver.ubuntu.com/pks/lookup?fingerprint=on&op=index&search=0x0AA7234DBBF0E2111323F1E3631D7285D12F590A
[19:18] <sdeziel> they keyserver url sometimes return a 503 and sometimes a no result found
[19:25] <sdeziel> s/they/the/
[19:48] <sdeziel> I'm not alone apparently: https://answers.launchpad.net/launchpad/+question/670706
[23:37] <cjwatson> nickoe: We can give list admins an mbox on request: ask on https://answers.launchpad.net/launchpad/+addquestion


[04:15] <NonvocalScream> Is there anyway that a update can be released in Jaunty to address the vulnerability here https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/410297


[00:13] <pteague> anybody know of a quick way to copy all of the settings from 1 front end to another?
[01:01] <pteague> i can't seem to get the same style info & position osd on my desktop as i get on my normal front end... any ideas?
[01:11] <pteague> nm, finally found the spot for the config
[07:02] <Luna-Tick> Hi, is there a Nick here?
[07:02] <Luna-Tick> He has been helping me with a Mythbuntu LP question: https://answers.launchpad.net/mythbuntu/+question/61858/
[07:15] <rhpot1991> Luna-Tick: thats foxbuntu
[07:15] <rhpot1991> he may not be paying attention now though
[07:16] <foxbuntu> Luna-Tick, Hello
[07:16] <foxbuntu> rhpot1991, thanks for the ping, was away
[07:16] <rhpot1991> np foxbuntu
[07:16] <rhpot1991> foxbuntu: you don't happen to know where the heck the free space setting is?
[07:17] <rhpot1991> I thought it was in mythtv-setup>general, but I can't find it there
[07:17] <rhpot1991> hmmmpf
[07:17] <foxbuntu> rhpot1991, hmm, thats where I thought it was too
[07:17] <rhpot1991> let me check again
[07:18] <rhpot1991> ya its not there
[07:18] <Luna-Tick> Hi!
[07:19] <foxbuntu> Luna-Tick, so where are we at?
[07:19] <foxbuntu> rhpot1991, hmm...let me move down to the liar and I can look on my other machine
[07:19] <Luna-Tick> Well, I tried the pretty "Restricted Device Manager"/jockey interface to install the fglrx drivers and had the strange video issues.
[07:20] <Luna-Tick> So I ended up removing them and going back to ati
[07:20] <foxbuntu> Luna-Tick, you on Mythbuntu 8.10?
[07:21] <foxbuntu> ...with the 780G chipset right?
[07:21] <Luna-Tick> Yes, 8.10.  Is there going to be an advantage to video playback or CPU use by  changing from ati to fglrx?
[07:21] <Luna-Tick> Yes
[07:21] <foxbuntu> Luna-Tick, you generally get smoother frame rates from fglrx over the open source driver when dealing with the HDMI port
[07:21] <Luna-Tick> Just to catch up with where things are at, have the fancy new RadeonHD drivers not made it into Ubuntu yet?
[07:22] <Luna-Tick> Right.  At the moment I am back to the D-Sub as I had issues getting the sound to work over HDMI
[07:22] <foxbuntu> Luna-Tick, they are in Ubuntu main, but dont support the newer chipsets yet iirc
[07:22] <Luna-Tick> Right
[07:23] <Luna-Tick> I haven't had any issues installing non-Free drivers with Jockey before, so I was quite surprised at the seriousness of the problems.
[07:23] <Luna-Tick> I am using Myhtbuntu 64
[07:23] <foxbuntu> Luna-Tick, 64 wont make a difference here
[07:24] <foxbuntu> rhpot1991, frontend > Setup > Setup > TV > General
[07:25] <foxbuntu> 2nd page ish
[07:25] <Luna-Tick> I wouldn't have thought so, but I also get a "Mode not supported" from the TV during Usplash on startup and shutdown on the 64-bit version, but when I switched the HDDs back to the 32-bit installation to retrieve the database, the usplash works fine.  Not too important, but interesting.
[07:25] <foxbuntu> Luna-Tick, prob a bug in the usplash package, god knows its possible since I built it
[07:25] <foxbuntu> ;)
[07:25] <Luna-Tick> Haha
[07:26] <foxbuntu> ...anyways
[07:26] <Luna-Tick> Yeah.
[07:26] <foxbuntu> Luna-Tick, switch over to the dsub terminal
[07:27] <foxbuntu> then: sudo /etc/init.d/gdm stop
[07:27] <foxbuntu> sudo dpkg -l | grep ati
[07:27] <foxbuntu> what is the output?
[07:27] <Luna-Tick> There is heaps - anything with those three letters together
[07:27] <foxbuntu> Luna-Tick, ah right
[07:28] <foxbuntu> sudo dpkg -l | grep ^ati
[07:28] <Luna-Tick> But remember that I am back to using the ati driver now - I changed the xorg.conf to get back to a usable desktop
[07:28] <Luna-Tick> sure
[07:29] <Luna-Tick> Nothing
[07:29] <Luna-Tick> (What does the ^ do?)
[07:29] <foxbuntu> it should make it look for ati @ the start of the word
[07:29] <rhpot1991> foxbuntu: my 2nd page is db config page 2
[07:29] <rhpot1991> nothing on there at all
[07:29] <foxbuntu> rhpot1991, ?
[07:30] <rhpot1991> next page is audio
[07:30] <foxbuntu> rhpot1991, its on the AutoExpire options page
[07:30] <rhpot1991> ah there it is
[07:30] <rhpot1991> heh
[07:30] <foxbuntu> lol
[07:31] <rhpot1991> foxbuntu: I had it at 5gb, going to bump that and see if it helps me from getting 99% fragged
[07:31] <foxbuntu> rhpot1991, yeah, mine is a bit higher
[07:31] <foxbuntu> rhpot1991, I sitll get to 99
[07:31] <rhpot1991> what are you at?
[07:31] <rhpot1991> hmmm
[07:32] <foxbuntu> rhpot1991, you using XFS?
[07:33] <rhpot1991> foxbuntu: yepper
[07:33] <rhpot1991> foxbuntu: do you use openwrt?
[07:33] <foxbuntu> Luna-Tick, sudo dpkg -l | grep xserver-xorg-video-ati
[07:33] <foxbuntu> rhpot1991, no, I havent wanted to spend the time on it when I going to be switching to a real firewall soon
[07:34] <foxbuntu> going to cost me a bit, but I figure i better
[07:34] <Luna-Tick> That is there (no surprise, I manually reinstalled it)
[07:35] <foxbuntu> Luna-Tick, anything else show up?
[07:35] <foxbuntu> shouldnt
[07:35] <Luna-Tick> No
[07:35] <foxbuntu> sudo dpkg --purge xserver-xorg-video-ati
[07:35] <foxbuntu> let me know if errors pop up
[07:38] <Luna-Tick> I did that before and get an error about dependencies (xserver-xorg-video-all)
[07:38] <foxbuntu> Luna-Tick, whats the exact error?
[07:40] <Luna-Tick> dependency problems prevent removal of xserver-xorg-video-ati
[07:40] <foxbuntu> Luna-Tick, ok, do this then:
[07:40] <foxbuntu> sudo apt-get remove --purge xserver-xorg-video-ati
[07:41] <Luna-Tick> xserver-xorg-video-all depends on xserver-xorg-video-ati
[07:41] <foxbuntu> and when it asks to remove the depends, make note of which ones and then say yes
[07:42] <Luna-Tick> Um.... problem
[07:42] <Luna-Tick> I was doing that through an accessories terminal
[07:42] <foxbuntu> lol
[07:43] <Luna-Tick> Now I tried to switch to the Ctrl+Alt+F1
[07:43] <foxbuntu> you need to switch over
[07:43] <Luna-Tick> and get the "Mode Not Supported" error
[07:43] <foxbuntu> you attached to a tv?
[07:43] <foxbuntu> oh right
[07:43] <foxbuntu> duh
[07:43] <foxbuntu> anyways
[07:43] <Luna-Tick> That was working under the D-Sub with fglrx
[07:43] <foxbuntu> reboot, and then it should be fine
[07:44] <Luna-Tick> Reboot when?
[07:44] <Luna-Tick> I haven't removed that package yet
[07:44] <foxbuntu> oh
[07:44] <Luna-Tick> Do that first?
[07:44] <foxbuntu> well switch to dsub then
[07:44] <Luna-Tick> Sorry, I am not being clear
[07:44] <foxbuntu> ctrl+alt+f2
[07:44] <Luna-Tick> Same problem
[07:44] <foxbuntu> mode not supported?
[07:45] <foxbuntu> thats a resolution problem with the TV
[07:45] <Luna-Tick> It seems to work under D-Sub with fglrx, but not D-Sub under ati
[07:45] <Luna-Tick> But I get text when I boot (BIOS etc.)
[07:45] <foxbuntu> it shouldnt matter
[07:45] <Luna-Tick> It seems bizarre
[07:46] <Luna-Tick> It definitely worked under fglrx because that is how I changed xorg.conf back again - and it definitely isn't working now...
[07:47] <foxbuntu> well at any rate, you should be able to remove and replace the package from gnome
[07:47] <Luna-Tick> Why do I want to do that?
[07:47] <Luna-Tick> Just checking we're on the same page - my -ati driver is working properly
[07:48] <foxbuntu> to give you an attempt at getting HDMI audio work and to get better video performace
[07:49] <Luna-Tick> Oh sorry - so remove -ati and replace with -fglrx
[07:49] <foxbuntu> yes
[07:50] <Luna-Tick> Ok, so I'll do what you tell me ;).
[07:50] <Luna-Tick> sudo apt-get remove --purge xserver-xorg-video-ati
[07:50] <foxbuntu> you will need to reboot this time though, because gnome will hold onto the driver
[07:51] <foxbuntu> but before you reboot
[07:51] <foxbuntu> change your xorg
[07:51] <Luna-Tick> Right - ati and all are gone
[07:51] <foxbuntu> ok
[07:51] <Luna-Tick> Do I need to install fglrx?
[07:51] <foxbuntu> yes
[07:51] <foxbuntu> sudo apt-get install xorg-driver-fglrx (i think)
[07:52] <aniiena> do I get a desktop/cli with mythbuntu?
[07:52] <Luna-Tick> aniiena - yes, you do
[07:52]  * foxbuntu uses restraint to not make a smart remark
[07:52] <aniiena> do I need to redo xorf.conf everytime I connect a different TV/monitor?
[07:53] <foxbuntu> aniiena, no
[07:53] <foxbuntu> aniiena, when X starts up it will change accordingly
[07:53] <Luna-Tick> foxbuntu: It already has the latest version of that driver
[07:53] <foxbuntu> aniiena, you can simply reboot, or hads will tell you you can also just restart gdm
[07:54] <foxbuntu> Luna-Tick, of fglrx?
[07:54] <aniiena> alright, thanks
[07:54] <Luna-Tick> Yes. So I change xorg.conf to read "fglrx" instead of "ati"?
[07:54] <foxbuntu> Luna-Tick, yup
[07:54] <foxbuntu> Luna-Tick, then either ssh into the machine and restart X or reboot, either way should be fine
[07:55] <foxbuntu> Luna-Tick, brb
[07:55] <Luna-Tick> np
[07:57] <Luna-Tick> Same problem
[07:58] <Luna-Tick> The desktop loads fine, but then myhtfrontend starts and the screen is garbage
[07:58] <Luna-Tick> Once that has happened, changing to the other virtual desktop (Ctrl + Alt + Right) gives garbage as well.
[07:59] <Luna-Tick> But, strangely, the Ctrl + Alt + F1 does now work
[07:59] <Luna-Tick> (even if it shouldn't make a difference ;))
[08:05] <foxbuntu> Luna-Tick, give you give more details? a better description of what it looks like?
[08:06] <foxbuntu> Luna-Tick, can you give more details*
[08:07] <Luna-Tick> Will do
[08:13] <foxbuntu> Luna-Tick, ah resoultion is off
[08:13] <foxbuntu> Luna-Tick, likely the fglrx driver selected the wrong one
[08:13] <foxbuntu> Luna-Tick, Usually not a problem with Samsung TV though
[08:14] <foxbuntu> Luna-Tick, 1080p or 720p tv?
[08:14] <Luna-Tick> 720p
[08:14] <Luna-Tick> (unfortunately ;))
[08:15] <aniiena> welp
[08:15] <foxbuntu> Luna-Tick, yea, well unless your h.264, 720p is all your going to get anyways
[08:15] <aniiena> installing mythbuntu now
[08:15] <aniiena> wish me luck
[08:15] <foxbuntu> aniiena, should be pretty easy
[08:15] <foxbuntu> aniiena, thats what support people are for :)
[08:16] <foxbuntu> Luna-Tick, can you pastebin your current xorg.conf and I will edit it for you and send it back?
[08:16] <Luna-Tick> Hmmm....
[08:17] <Luna-Tick> That could be a challenge
[08:17] <Luna-Tick> I'll try
[08:17] <foxbuntu> Luna-Tick, nvm then
[08:17] <foxbuntu> Luna-Tick, I will just send you what you need to add/change
[08:17] <Luna-Tick> You really are excellent at this!
[08:18] <foxbuntu> Luna-Tick, I have been breaking my own stuffs for a long time and develing on this project since it started, I sure hope Im getting better
[08:18] <foxbuntu> !pastebin
[08:18] <Zinn> when pasting more than 5 lines of data please use http://mythbuntu.pastebin.com so you don't flood the channel.  Then please post the link in the channel.
[08:19] <foxbuntu> Luna-Tick, http://mythbuntu.pastebin.com/m549cfcf5
[08:19] <foxbuntu> Luna-Tick, make sure that the names for the monitor and device are the same, (they should be its the defaults)
[08:20] <foxbuntu> ie if your ati card is Named "Ati somecard" rather than "Generic Device" then change what I sent you to match
[08:20] <foxbuntu> the important parts is the resolution portion
[08:21] <foxbuntu> Luna-Tick, also: www.foxmediasystems.com
[08:21] <foxbuntu> ;)
[08:22] <Luna-Tick> Is there meant to be a " after the 720x$?
[08:23] <Luna-Tick> foxbuntu:
[08:23] <aniiena> best to format my usb stick to fat32 before using it with mythbuntu?
[08:23] <foxbuntu> Luna-Tick, oops
[08:23] <foxbuntu> thats just left overs from my term
[08:24] <foxbuntu> delete it
[08:24] <foxbuntu> make the last one "1024x768"
[08:24] <foxbuntu> delete the rest on that line
[08:26] <aniiena> silicon dust hdhomerun config utility
[08:26] <aniiena> what's that?
[08:27] <Luna-Tick> foxbuntu: Done
[08:27] <foxbuntu> aniiena, its a utility required if you have an HDHomeRun HD Tuner
[08:27] <Luna-Tick> Now what
[08:27] <foxbuntu> Luna-Tick, restart X again
[08:27] <aniiena> by default it wants me to diable tv-out
[08:27] <foxbuntu> ctrl+alt+bkspc
[08:27] <aniiena> I can easily enable it when I need it?
[08:27] <foxbuntu> aniiena, what output are you using?
[08:27] <aniiena> right now a monitor
[08:27] <aniiena> but at different times I plan to use different TV sets
[08:28] <foxbuntu> what type of connection is the goal?
[08:28] <aniiena> either hdmi or composite
[08:28] <foxbuntu> go ahead and unselect it
[08:28] <foxbuntu> wont hurt
[08:28] <foxbuntu> it will default to the connection thats plugged in at boot
[08:29] <foxbuntu> Luna-Tick, ctrl+alt+bkspc
[08:30] <Luna-Tick> Same issue
[08:30] <foxbuntu> still out of wack eh?
[08:30] <Luna-Tick> Yupp
[08:31] <foxbuntu> hrm
[08:31] <Luna-Tick> Hang on
[08:31] <foxbuntu> I have a machine with the same chipset
[08:33] <foxbuntu> which one I am not sure at this point
[08:34] <Luna-Tick> Nope
[08:34] <Luna-Tick> I just checked and it isn't working
[08:35] <Luna-Tick> It is so odd, because it is working fine until Mythfrontend starts and stuffs it
[08:35] <foxbuntu> try  full reboot
[08:35] <Luna-Tick> Will do
[08:37] <Luna-Tick> foxbuntu: same problem
[08:37] <foxbuntu> intresting
[08:38] <Luna-Tick> Can I send you a log or something?
[08:38] <foxbuntu> Luna-Tick, so if you ctrl+alt+bksp, it should go back to the login at first, is that screen off too?
[08:38] <Luna-Tick> No, that is fine
[08:38] <foxbuntu> Luna-Tick, so it really is Myth causing it, thats odd
[08:39] <Luna-Tick> Could it be something to do with those "Prescaled images" or something?
[08:39] <foxbuntu> or at least a QT/OpenGL app
[08:39] <foxbuntu> Luna-Tick, well it does that based on the res
[08:39] <Luna-Tick> Which hasn't changed
[08:40] <foxbuntu> Luna-Tick, ...im thinking, I have had similar issues in the past
[08:43] <foxbuntu> Luna-Tick, in your xorg.conf Device Section:
[08:43] <aniiena> under video capture card setup
[08:43] <aniiena> it's asking for my video device...
[08:44] <foxbuntu> aniiena, its your tuner, what kind do you have?
[08:44] <aniiena> hauppage
[08:44] <foxbuntu> Luna-Tick, add this: Option "VideoOverlay" "off"
[08:44] <aniiena> 1500
[08:44] <foxbuntu> Luna-Tick, also add this line same spot: Option "XAANoOffscreenPixmaps" "on"
[08:45] <aniiena> Analog V4L capture card?
[08:45] <foxbuntu> Luna-Tick, in the server layout section: Option "AIGLX" "on
[08:45] <foxbuntu> aniiena, no
[08:45] <foxbuntu> aniiena, 1500?
[08:45] <foxbuntu> aniiena, perhaps do you mean HVR-1600?
[08:45] <aniiena> err
[08:45] <aniiena> 150
[08:45] <foxbuntu> oh
[08:45] <foxbuntu> thats a great card
[08:46] <foxbuntu> aniiena, next tuner in the list
[08:46] <aniiena> mpeg capture card?
[08:46] <foxbuntu> I think, its the PVR-xxx card
[08:46] <foxbuntu> uh
[08:46] <Luna-Tick> foxbuntu: by the way, mine says "Configured Monitor" instead of "Generic Monitor" and Device is "Configured Video Device" - should I have changed those to match yours?
[08:46] <foxbuntu> look for the one with PVR in the name
[08:46] <aniiena> mpeg-2 encoder card (PVR-x50 etc)
[08:46] <foxbuntu> Luna-Tick, no
[08:46] <aniiena> what do I put in for video device?
[08:47] <foxbuntu> Luna-Tick, they are just names, really doesnt matter
[08:47] <Luna-Tick> Thought so
[08:47] <Luna-Tick> I'll make your changes
[08:47] <foxbuntu> aniiena, should have defaulted to /dev/video0 and Says PVR-150 tuner under neath
[08:47] <Luna-Tick> Do I add you changes outside the SubSection?
[08:47] <foxbuntu> Luna-Tick, yes
[08:48] <foxbuntu> Luna-Tick, in ServerLayout
[08:48] <foxbuntu> Luna-Tick, not in Screen
[08:48] <aniiena> actually
[08:48] <aniiena> I have a Win-TV-HVR-1250
[08:49] <foxbuntu> aniiena, well, thats a very different card
[08:49] <aniiena> I am coming to that realization
[08:49] <Luna-Tick> foxbuntu: I don't have a server layout section
[08:50] <foxbuntu> Luna-Tick, really?
[08:50] <Luna-Tick> Yeah
[08:50] <foxbuntu> not at the very top?
[08:50] <Luna-Tick> Nope - it starts with "Monitor"
[08:50] <Sharkonwheels> rhpot1991: you still around?
[08:51] <aniiena> I will just skip this part
[08:51] <foxbuntu> Sharkonwheels, I highly doubt it, its nearly 4A for him
[08:51] <foxbuntu> aniiena, no
[08:51] <Sharkonwheels> same here - near 4am :)
[08:51] <foxbuntu> aniiena, change the tuner to DVB
[08:51] <aniiena> http://ubuntuforums.org/showthread.php?t=1071021
[08:51] <aniiena> ok
[08:51] <Sharkonwheels> you folks are running XFS? I thot you weren't supposed to use a journaling fs for recording?
[08:52] <foxbuntu> Sharkonwheels, XFS is much faster than ext3 is the reason behind it
[08:52] <foxbuntu> Sharkonwheels, its not ideal for the frag factor
[08:52] <Luna-Tick> foxbuntu: I really appreciate your help, but it is getting quite late here and I need to go to bed, so I think that I will change it back to how it was and have it going again.
[08:53] <foxbuntu> Sharkonwheels, but I am looking at doing a test deploy of ext4 soon
[08:53] <Sharkonwheels> one of the docs mentioned corruption using a journaling fs, so i used ext3 for the OS, ext2 for the recording
[08:53] <foxbuntu> Luna-Tick, well I was going to paste the section
[08:53] <aniiena> could not get card info for card #0 Subtyp
[08:53] <Sharkonwheels> anyone you know doing SATA2 RAID5? Wonder what the write penalties are?
[08:53] <foxbuntu> Luna-Tick, but if your going to be, catch me again later if you are still having issues
[08:54] <Luna-Tick> foxbuntu: Do you think I can just add a "ServerLayout" section?
[08:54] <foxbuntu> Sharkonwheels, depends on your controlers
[08:54] <foxbuntu> Luna-Tick, yup
[08:54] <Luna-Tick> Okay - I'll hang in there for another try :)
[08:54] <Luna-Tick> Thanks
[08:54] <Sharkonwheels> erm, was looking at the Intel ICH10R onboard an MSI P45 Neo3-FR
[08:55] <foxbuntu> Luna-Tick, http://mythbuntu.pastebin.com/m41cb5832
[08:55] <Sharkonwheels> mainboard linkage:  http://www.msicomputer.com/product/p_spec.asp?model=P45_Neo3-FR&class=mb
[08:56] <foxbuntu> obviously again, make sure the screen name is the same as what is in your xorg
[08:56] <foxbuntu> Sharkonwheels, its consumer, essentialy is could be considerable depending on your i/o utilization
[08:56] <Sharkonwheels> was thinking of doing 4 or 5 500GB drives for a 1.5TB setup (1 parity, or 1 parity+1 online spare)
[08:57] <Luna-Tick> foxbuntu: Thanks - should I add those options above, or try without?
[08:57] <foxbuntu> Sharkonwheels, in my Day job, I have seen as much as 10-15% disk speed loss just to the controller firmware in the enterprise class of hardware
[08:58] <foxbuntu> Luna-Tick, at the top of the xorg should be fine
[08:58] <Luna-Tick> Yeah, sorry, I mean shall I add those overlay and XAA options to the pastebinned section
[08:58] <foxbuntu> no
[08:58] <Sharkonwheels> yeah, I know - see that all day long at work (Sun boxes, and HP Dl380 G3/G4's) and those are Ultra 320SCSI RAIDS, or SAS!
[08:59] <foxbuntu> Luna-Tick, the options I sent before go in the Device section
[08:59] <Luna-Tick> Oh... crap.
[08:59] <Luna-Tick> Sorry
[08:59] <foxbuntu> Sharkonwheels, ah yes, DL380 G4's
[09:00] <Sharkonwheels> but still, not bad - figger most we need is what? 3MBps per recording channel? If even? I'm getting 2.2GB per hour recording on this box through the HVR-1600's
[09:00] <foxbuntu> Sharkonwheels, I am a consultant and Deal with large banking/insurance clients on that hardware
[09:00] <foxbuntu> Sharkonwheels, yea, you wont bottle neck with that
[09:00] <Sharkonwheels> yep - decent enough boxes (we use them on our ships) I have G2's in place for over 5 years now!
[09:00] <foxbuntu> Sharkonwheels, I put in the note since I have 11 tuners and hammer my disks
[09:01] <Sharkonwheels> I remember starting with the P3 based 1850R's - now THOSE were junk - faulty cooling design, hence the name change to DL380 :)
[09:01] <foxbuntu> Sharkonwheels, oh, I dont let hardware get that old
[09:01] <foxbuntu> bad things happen when you do
[09:02] <Sharkonwheels> way the economy is, no choice - I'd have to replace, let's see, about 23 servers times 11 ships, average of about $7K per server...
[09:02] <foxbuntu> with my clients all the servers have 3 year life cycles
[09:02] <Luna-Tick> foxbuntu: Done
[09:02] <Luna-Tick> Shall I reboot
[09:02] <Sharkonwheels> we've starting migrating to VMware ESXi and Sun boxes
[09:02] <Luna-Tick> ?
[09:02] <Luna-Tick> Or restart X?
[09:02] <foxbuntu> Luna-Tick, restart X
[09:02] <Sharkonwheels> The Sun's really s*U*ck!
[09:03] <foxbuntu> Sharkonwheels, yes, I have not had to deal with them in a long time (thank god)
[09:03] <Luna-Tick> Same problem
[09:03] <foxbuntu> Luna-Tick, well, craps
[09:03] <Sharkonwheels> we have a setup that's, what, november timeframe? like 90-120 days old? 3 replacements so far...
[09:03] <foxbuntu> Luna-Tick, try this:
[09:03] <foxbuntu> Luna-Tick, install the ati catalyst control centre
[09:04] <foxbuntu> Luna-Tick, let me find the package name
[09:04] <Sharkonwheels> heh - get this: we hav eone ship (won't be in the fleet much longer) which still has the *BEIGE* Proliants!
[09:04] <foxbuntu> actually
[09:04] <Sharkonwheels> :o
[09:04] <foxbuntu> Luna-Tick, sudo aticonfig
[09:04] <foxbuntu> it will tell you what to install
[09:04] <Sharkonwheels> (as an aside, I got frustrated with the dang ATI drivers, and went out and bought an AGP Nvidia card. Been rocking since)
[09:04] <foxbuntu> Sharkonwheels, now those were rock solid machines
[09:04] <aniiena> how do I setup my remote?
[09:05] <foxbuntu> Sharkonwheels, takes me back to the days of being a Netware admin
[09:05] <foxbuntu> aniiena, what remote?
[09:05] <Sharkonwheels> yep - I started on 2.0a
[09:05] <Luna-Tick> foxbuntu: Thank you so much for all of your help, but I really have to get to bed.  I would really appreciate it if you could add the extra instructions to the LP answer, though.  I will save this xorg.conf as something else so I can go back to it
[09:05] <foxbuntu> Sharkonwheels, my first shop was 3.0 i think
[09:05] <Sharkonwheels> then 2.10, 2.12, then all the crazyness started - SFT, advanced, sheesh!
[09:06] <Sharkonwheels> 3.10/3.11/3.12 made it simple!
[09:06] <aniiena> doesn't have a product # on it
[09:06] <foxbuntu> Luna-Tick, sounds good, catch me back in here sometime
[09:06] <Sharkonwheels> brb
[09:06] <foxbuntu> aniiena, where did you get the remote? did it come with the tuner?
[09:06] <aniiena> yes
[09:06] <foxbuntu> prob an MCE remote then
[09:07] <foxbuntu> does the receiver for it use USB or plug into the card?
[09:07] <aniiena> plug into the card
[09:07] <foxbuntu> ok...
[09:07] <foxbuntu> one sec
[09:10] <foxbuntu> aniiena, hmm, im finding that there are issues with that style IR receiver because the drivers for the card dont implement it yet
[09:10] <aniiena> hum
[09:11] <aniiena> so my card isn't supported yet?
[09:11] <foxbuntu> aniiena, you might need to get a different receiver/remote or do some looking around
[09:11] <foxbuntu> aniiena, its supported, the IR on it just isnt quite ready yet
[09:11] <aniiena> ok well
[09:11] <aniiena> I have another remote
[09:11] <foxbuntu> aniiena, the HVR series cards are all very new to the game and support is there but still new
[09:12] <aniiena> it is a MCE Remote and Reciever
[09:12] <foxbuntu> thre you go
[09:12] <foxbuntu> those work 100%
[09:12] <foxbuntu> plug it in and I will tell you the easy way to set it up
[09:14] <Luna-Tick> foxbuntu: All is back to how it was (that's a relief), so the fiancee will not be too angry with me tomorrow ;).
[09:14] <foxbuntu> lol
[09:14] <foxbuntu> Luna-Tick, being married, I know exactly that problem
[09:14] <Luna-Tick> Thanks again for all of your help - people like you make a real difference to products like this
[09:14] <Sharkonwheels> I have a 1600, and it was braind0dead to install. PVR-x50 for analog side, DVB for HD side
[09:15] <foxbuntu> Luna-Tick, thanks, catch you later
[09:15] <Luna-Tick> I hope so - Thanks
[09:15] <aniiena> ok it's plugged in
[09:15] <foxbuntu> Sharkonwheels, yeah, however there are several versions of the 1600 for some reason
[09:15] <Sharkonwheels> when reconfiguring, though, I have to manually enter the device names. When I select <PVR-x50> it says not detected
[09:15] <foxbuntu> Sharkonwheels, do you have the QAM one?
[09:15] <Sharkonwheels> yep - xx041
[09:16] <Sharkonwheels> seems it started when I popped in 4 cards :)
[09:16] <Sharkonwheels> before, it was the 1 1600, and 1 Pinnacle PCTV (what a piece of junque)
[09:16] <foxbuntu> Sharkonwheels, hmm intresting, I cant get any signal on the QAM side of mine
[09:16] <Sharkonwheels> me neither :)
[09:16] <foxbuntu> do you get ATSC from it
[09:16] <foxbuntu> ?
[09:17] <Sharkonwheels> I had a lock a few days ago, and a few channels showed up in the scan, but I ran out of ports on the CATV splitter, so just wired up all the analog ports.
[09:17] <foxbuntu> aniiena, open up Mythbuntu Control Centre
[09:17] <Sharkonwheels> the PCTV shares the connector, but ain;t got HD on that one working yet, either. SUPPOSEDLY it has a better HD tuner/scanner
[09:18] <aniiena> ok it's open
[09:18] <foxbuntu> Sharkonwheels, isnt the ATSC/NTSC side of the card the same RG6 input?
[09:18] <Sharkonwheels> fox: I get no lock - tried cable/cable high with 8vsb (ATSC), QAM-64, 128, & 256 - got nada
[09:18] <foxbuntu> aniiena, select ir devices
[09:18] <aniiena> done
[09:18] <foxbuntu> Sharkonwheels, same here, its driving me nutz
[09:19] <Sharkonwheels> fox: HVR-1600's have 1 F connector for NTSC, 1 for HD. wiring NIGHTMARE!
[09:19] <aniiena> windows media center remotes?
[09:19] <foxbuntu> aniiena, enable the top one, then select the Windows MCE remote (new one)
[09:19] <foxbuntu> make sure Generate Dynamic Maps is checked
[09:19] <Sharkonwheels> the PCTV has 1 F-conn shared, but the fact it has no MPEG2 onboard absolutely SUCKS! was NOT worth the $10 savings :)
[09:19] <Sharkonwheels> I got the HVR's new at Circuit City for $50
[09:20] <aniiena> now when I plug in a USB memory stick
[09:20] <foxbuntu> Sharkonwheels, which is the HD?
[09:20] <Sharkonwheels> they both support HD
[09:20] <aniiena> will mythbuntu detect it, pull media from it and place that media on the appropriate directories?
[09:20] <Sharkonwheels> or u mean which connector?
[09:20] <foxbuntu> aniiena, nope
[09:20] <foxbuntu> Sharkonwheels, which connector
[09:20] <Sharkonwheels> top one - it's labelled "TV" I think
[09:20] <foxbuntu> there is FM, Ant, TV
[09:21] <foxbuntu> ok
[09:21] <Sharkonwheels> should be the top connector - think it sticks out a little more
[09:21] <Sharkonwheels> lemme check, brb
[09:21] <foxbuntu> Sharkonwheels, thats the bottom F conn
[09:21] <aniiena> what is the default directory for videos?
[09:21] <Sharkonwheels> sorry - BOTTOM F connector is HD.
[09:21] <Sharkonwheels> I read wrong/thought wrong. Top is Analog NTSC
[09:21] <foxbuntu> aniiena, uh, /var/lib/mythtv/videos/
[09:22] <foxbuntu> top as in the one below FM?
[09:23] <Sharkonwheels> erm, u lost me - HVR-1600's don't have FM
[09:23] <foxbuntu> Sharkonwheels, anyways, ATSC is Ant or TV?
[09:23] <foxbuntu> Shadow__X, mine does
[09:23] <foxbuntu> er
[09:23] <foxbuntu> Sharkonwheels,
[09:23] <foxbuntu> Sharkonwheels, like i said, several versions
[09:23] <Sharkonwheels> mine's model 1199, with remote
[09:24] <foxbuntu> nope, I have an OEM model
[09:24] <foxbuntu> er
[09:24] <foxbuntu> retail I mean
[09:24] <Sharkonwheels> yep - mine's a retail from CCity
[09:24] <foxbuntu> mine is through my distributor
[09:24] <Sharkonwheels> mine is labelled "TV" for the NTSC F connector, and "ATSC" for the HD connector
[09:25] <Sharkonwheels> below that is the SVideo
[09:25] <foxbuntu> yup
[09:25] <Sharkonwheels> then I think a sound-in jack, then the IR-Blaster jack
[09:25] <foxbuntu> i have one more f connector for FM
[09:26] <Sharkonwheels> the PCTV has FM, which isn't even connected anyways, so I won't miss the FM. Can MythTV do anything with the FM yet?
[09:26] <foxbuntu> Sharkonwheels, uh, idk, (who cares?)
[09:27] <foxbuntu> ;)
[09:27] <Sharkonwheels> I know - I either listen to CD's, or to the AM whackos or AM sports anyways :)
[09:27] <Sharkonwheels> Aiiena get the PVR working?
[09:28] <foxbuntu> Sharkonwheels, well I was more refering to the support of shoutcast
[09:28] <Sharkonwheels> seriously, I barely have enough time to even watch what I record!!
[09:28] <foxbuntu> Sharkonwheels, I know that feeling
[09:29] <Sharkonwheels> I finally watched a couple things I recorded on line 2/17!
[09:29] <foxbuntu> Sharkonwheels, its freaking 3:39A am I sitting here and working on my taxes and this, and my day job
[09:30] <Sharkonwheels> taxes? oh HECK no - I stopped that. I use an accountant/former client ( no time for consulting any more)
[09:30] <foxbuntu> Sharkonwheels, oh I have to get them preped for the accountant
[09:30] <Sharkonwheels> oh, the FUN part you mean :)
[09:30] <foxbuntu> Sharkonwheels, I own a small business (very small) and that is the crap I am dealing with
[09:31] <Sharkonwheels> the part where you barge into the accountants office with a grocery bag full of receipts
[09:31] <Sharkonwheels> and they look at you like you have 3 eyes
[09:31] <foxbuntu> yeah, something like that
[09:31] <foxbuntu> guy charges me a ton but always gets me lots of money back
[09:32] <aniiena> so I put a movie in /var/lib/mythtv/videos
[09:32] <aniiena> it doesn't show up in mythtv frontend
[09:32] <Sharkonwheels> is it a supported format?
[09:32] <aniiena> .avi?
[09:32] <Sharkonwheels> fox: do you have to do the <scan> function for it to update the db or something?
[09:33] <foxbuntu> Sharkonwheels, yes
[09:33] <foxbuntu> Utils / Setup > Video Manger
[09:33] <foxbuntu> in the mythtv menus
[09:34] <Sharkonwheels> main project today, was replacing the 7000RPM 60mm CPU fan - dang computer in the living room sounded like a DC-10
[09:34] <aniiena> ok there is goes
[09:35] <aniiena> I have to do Setup > Video Manager each time I add content?
[09:35] <foxbuntu> aniiena, yes
[09:35] <foxbuntu> Sharkonwheels, meh, I have an HP LT6000 sitting in my basement as a build server
[09:36] <aniiena> stop/pause aren't working
[09:36] <foxbuntu> aniiena, in the video you added?
[09:36] <aniiena> oh nevermind
[09:36] <aniiena> I was using the hauppage remote
[09:36] <aniiena> lol
[09:36] <foxbuntu> lol
[09:37] <Sharkonwheels> I now have like 3 of those as spares in the garage!
[09:37] <foxbuntu> Sharkonwheels, lol, they are loud bastards
[09:37] <Sharkonwheels> fox: any news on when the 2250's will have a driver? Those should rock. dual NTSC/ATSC, only 1 F connector, in 2 PCIe x1 slot
[09:38] <foxbuntu> Sharkonwheels, i havent heard anything on it
[09:38] <Sharkonwheels> fox: you have NO idea! This is on an old Athlon XP 2500+ 333FSB I've been running at 425FSB for a while
[09:38] <Sharkonwheels> the cooler is the Cooler Master HHC-001 - their very first heat pipe. that fan is THE loudest fan I have EVER heard in a PC case!
[09:38] <foxbuntu> Sharkonwheels, i used to do that, then I started by business and have new hardware all over
[09:39] <Sharkonwheels> all the reviews said it - when it was in my home office (given up to my kids years ago) it was fine, and cool. In the living room, dang it was annoying!
[09:39] <foxbuntu> Sharkonwheels, I have like 7-8k in MythTV dedicated hardware atm
[09:40] <Sharkonwheels> dang. I ain't even got $7-8 HUNDRED!
[09:40] <Sharkonwheels> quick MythTV arch. question.
[09:40] <foxbuntu> sure
[09:40] <Sharkonwheels> how's the client/server setup work? NFS/SAMBA? Or streaming front end?
[09:40] <Sharkonwheels> what kinda' bandwidth needed between clients and the back-end?
[09:41] <foxbuntu> streaming to the frontend
[09:41] <foxbuntu> Sharkonwheels, anything will do until you get into h.264 mp4
[09:41] <aniiena> alright
[09:41] <aniiena> remote is working, I will deal with the capture card/tv tuner tomorrow
[09:41] <Sharkonwheels> I have MPG's coming out of the HVR-1600's
[09:41] <aniiena> thanks for the help
[09:41] <foxbuntu> Sharkonwheels, then you should look at gig-e for everything if you plan to be pushing more than one stream
[09:42] <foxbuntu> aniiena, gl, gn
[09:42] <Sharkonwheels> aiiena: what's not working on the cad?
[09:42] <Sharkonwheels> er, card?
[09:42] <foxbuntu> Sharkonwheels, its not a 150, its a HVR-1250
[09:42] <foxbuntu> Sharkonwheels, they are kind of special case
[09:42] <Sharkonwheels> that the PCIe one?
[09:43] <foxbuntu> yeah
[09:43] <foxbuntu> I think so
[09:43] <foxbuntu> that and the 1800/2250
[09:44] <Sharkonwheels> the 2250 will be nice when drivers are done. dual HD/Analog tuners, 1 F-conn, in a PCIe X1 slot
[09:44] <foxbuntu> indeed
[09:44] <Sharkonwheels> man, but that Pinnacle PCTV was SUCH as waste of $$
[09:44] <foxbuntu> and it should support multirec too
[09:44] <aniiena> yeah it's the PCI express one
[09:45] <aniiena> I had a 150 spec'ed out, but I didn't know if it would fit into my case
[09:45] <Sharkonwheels> I didn't know at the time, rushed in there and bought blind, but knew they were both supported, just didn't realize the Hauppauge was SO much better with the MPEG2
[09:45] <foxbuntu> yes
[09:45] <foxbuntu> i have stuck to their cards for a long time
[09:46] <Sharkonwheels> the wiki doesn't mention difficulties, at least not with after-2.6.24 kernels...
[09:46] <foxbuntu> with what?
[09:46] <Sharkonwheels> my mythbuntu 8.10 came with 2.6.27-7
[09:46] <Sharkonwheels> with the 1250's
[09:47] <Sharkonwheels> wikie entry, the person said "I purchased this card, dropped it into my MythDora5 box running 2.6.25, and was capturing HD television within Myth from a pair of rabbit ears, with configuration taking 20 minutes."
[09:48] <Sharkonwheels> course, no NTSC yet, right?
[09:48] <foxbuntu> Sharkonwheels, ah, well much has changed then
[09:48] <foxbuntu> right
[09:49] <Sharkonwheels> one reason I'm glad I at least used Opera Mini on my BBerry while at CCity picking cards.
[09:49] <Sharkonwheels> I didn't realize that the HVR's had onboard MPEG2, which the PCTV's lacked, or the HUGE improvement!
[09:49] <Sharkonwheels> watching live TV on the PCTV, it skips evne when I use the remote to change volume!
[09:50] <Sharkonwheels> I have a REALLY old PCI WinTV, we're talking probably 1997-1998. This will not have PCI-passthrough audio right?
[09:50] <Sharkonwheels> I vaguely remember looping it into my sound-card line-in jack, I think...
[09:51] <Sharkonwheels> I never got the audio working, so i just went out and got the (1) HVR and (1) PCTV on Sunday.
[09:51] <Sharkonwheels> Then made a return trip Tuesday when I was disappointed in the PCTV and got (3) more HVR's
[09:52] <foxbuntu> ah
[09:52] <foxbuntu> I think I might need to start expiring shows
[09:52] <foxbuntu> crap
[09:52] <foxbuntu> I hadnt looked at storage for abit
[09:52] <Sharkonwheels> brb
[09:58] <Sharkonwheels> going back to the C/S arch.... I can't wire my house, as I don't have attic space/drop ceilings, so I'v ebasically been WiFi in here since 1998
[09:58] <Sharkonwheels> my first router/ap was a linksys for $300 - that's how far back it goes!
[09:59] <Sharkonwheels> is WiFi-N fast enough?
[10:00] <foxbuntu> Sharkonwheels, eh... Wireless-N is a can of worms atm
[10:00] <Sharkonwheels> what about the turbo-g's ?
[10:01] <foxbuntu> Sharkonwheels, there are 100M- FD adapters for Eth-to-Electrical now
[10:01] <foxbuntu> Sharkonwheels, actually one of our devs uses them
[10:02] <Sharkonwheels> will that work jumping circuits through the fusebox?
[10:02] <Sharkonwheels> or gotta be on same circuit?
[10:03] <foxbuntu> http://www.netgear.com/Solutions/HomeNetworking/PowerlineNetworking.aspx
[10:03] <foxbuntu> Sharkonwheels, doesnt matter it just turns all the elec. into network
[10:04] <Sharkonwheels> cool - checking it out now on newegg...
[10:04] <Sharkonwheels> I was thinking of playing with a box at work...
[10:04] <foxbuntu> watch the specs on them
[10:04] <foxbuntu> many are not 100M yet
[10:05] <Sharkonwheels> I have a DL380G4 4G RAM 2x Xeon 3.4, 6 x 146GB with 14 more 146G drives in an MSA500
[10:05] <foxbuntu> would make a nice BE server
[10:05] <Sharkonwheels> does Linux support the MSA500 and it's U320 controllers? does it support the multipathed setup?
[10:05] <foxbuntu> Sharkonwheels, prob in the server kernel
[10:06] <Sharkonwheels> we used it for a Win2003/SQL Server cluster - it got replaced by one of the ESXi setups
[10:06] <foxbuntu> Sharkonwheels, but you dont want to do server kernel with myth
[10:06] <Sharkonwheels> what's BE?
[10:06] <foxbuntu> backend
[10:06] <Sharkonwheels> ah
[10:06] <Sharkonwheels> duh!
[10:06] <Sharkonwheels> prob is, there's what? 2PCI slots? 1 used by the storage adapter?
[10:07] <Sharkonwheels> u remember the old-school HP LXe Pro's? the Dual PPro HUGE rolling boxes?
[10:07] <foxbuntu> iirc, yes
[10:07] <foxbuntu> nope
[10:07] <Sharkonwheels> had like 200 PCI slots :)
[10:07] <Sharkonwheels> and hot-swap!
[10:08] <foxbuntu> I started as a netware admin, nothing in netware needed that kind of hardware back then
[10:08] <Sharkonwheels> When I was at royal caribbean in the 90's, we deployed a ton of those on NT running Oracle 8g
[10:08] <Sharkonwheels> yeah - I still think netware is the fastest fileserver in the biz
[10:08] <Sharkonwheels> You ever get into the Unixware side?
[10:09] <foxbuntu> everyone using netware was using the proliant servers (it seemed anyways!)
[10:09] <foxbuntu> Sharkonwheels, only in the last 5 years or so
[10:10] <foxbuntu> Sharkonwheels, I really am the jack of all trades, its disgusting
[10:11] <Sharkonwheels> yeah - I know the feeling.
[10:11] <foxbuntu> Sharkonwheels, I do consulting in: security, infrastructure, large scale deployments, and then I have special skills like scripting and custom software authoring
[10:11] <foxbuntu> I do hardware and software essentially sums it up
[10:12] <Sharkonwheels> I've worked on everything from Linux, to FreeBSD, to BSDi, to SunOS and SOlaris, to Irix Non-Stop UX, HP-UX, little zOS/zVM/MVS
[10:12] <Sharkonwheels> makes us agile, though
[10:12] <foxbuntu> right now I am on a project writing a piece of software to Automate server and workstation management
[10:12] <foxbuntu> its a .Net 3.5 + AJAX web app
[10:13] <Sharkonwheels> scripting.... (reading back) hmm...what cards are you using? the HVR's?
[10:13] <foxbuntu> and I do coding for this project (mostly python, a little perl here and there)
[10:14] <foxbuntu> Sharkonwheels, well my primary cards are PVR-150s right now, along with the HDHR and waiting for .22 to go live to bring my HD-PVR into the mix in my production system
[10:14] <Sharkonwheels> do the PVR-150's have the same issue as my HVR-1600's? First analog access is garbled after booting up?
[10:15] <foxbuntu> no
[10:15] <Sharkonwheels> first access is garbled (either skipping, no audio, or both) and there's a script here:
[10:15] <foxbuntu> Sharkonwheels, there is a change for the mythtv-backend script that will fix that, its related to having multiple HVR cards
[10:16] <Sharkonwheels> I tried the script on the wiki page, but I can;t get it to actually work.
[10:17] <Sharkonwheels> I made another .sh scrip to call the main script 3 times, but 'tis ain't working...
[10:17] <Sharkonwheels> other issue I've been fighting, is sometimes on bootup, the order in which the cards are detected changes.
[10:18] <Sharkonwheels> before, the PCTV was video0, and the HVR's were video1-video3
[10:18] <Sharkonwheels> this last time I booted up, the HVR's were video0-video2, and the PCTV was video3!
[10:18] <Sharkonwheels> 'course, that just totally throws off the BE!
[10:19] <foxbuntu> Sharkonwheels, you need to create a udev rule to handle it
[10:19] <foxbuntu> Sharkonwheels, there is info out there on that too
[10:19] <foxbuntu> for that exact case
[10:20] <Sharkonwheels> what's a udev rule?
[10:21] <foxbuntu> its a rule that tells the kernel how to create the /dev nodes for devices
[10:21] <foxbuntu> because /dev/video0 is really a link to another hardware device in the kernel
[10:21] <foxbuntu> its just a human friend device node
[10:21] <foxbuntu> friendly
[10:22]  * Sharkonwheels has more homework to do, apparently :0
[10:23] <foxbuntu> Sharkonwheels, yeah, the kernel is a wonderful world of pure confusion at first
[10:45] <foxbuntu> well time for me to grab some b-fast
[10:46] <foxbuntu> catch you later Sharkonwheels
[11:12] <Sharkonwheels> l8r - crashing now :)
[16:39] <ipwnu> I am currently running knoppmyth and am considering changing to mythbuntu.  What is the best way to transition my database over so I don't lose all of my recordings / recording history etc.
[17:02] <rcopelan> hello, I installed Mythbuntu but am having probelms getting the audio from the PVR250 card to recordings or liveTV.  It works from the card audio out but is out of sync for LiveTV.   Routing via an external cable doesn't work.  Any ideas on where I need to look for a solution?
[20:35] <mib_3zz6qm> hi, I have a problem with mythbuntu 8.10 on an eee box where the screen goes dark (or white as I just noticed) after a while of playing video or live tv
[20:35] <mib_3zz6qm> I've posted to http://ubuntuforums.org/showthread.php?t=1076791
[20:35] <mib_3zz6qm> and I've put my logs in the pastebin here http://mythbuntu.pastebin.com/f12882a12
[20:36] <mib_3zz6qm> thanks for having a look
[20:45] <gizmobay> I'm using mythvodka and for some reason the entries in the db don't match the hulu.xml file. Does anyone know how I can clear out the db entries so I can retry?
[22:12] <Sharkonwheels> anyway to find out AFTER the fact, which tuner recorder which program? I have some recordings with "crackling" in the audio
[23:17] <Chaorain> Does anyone know if it possible to use the Samsung universal remote with MythTV?
[23:29] <Chaorain> !help remotes
[23:29] <Zinn> !help remotes For a  complete list of my knowledge visit: http://www.baablogic.net/Zinn.cgi  Other available commands: !status, !about, !bug [bug_number].
[23:30] <foxbuntu> Chaorain, only if it can code learn or is ir compatible with your receiver
[23:30] <foxbuntu> Chaorain, in all likelihood, no
[23:31] <Chaorain> it has a programable code index but where do I find a pc adapter?
[23:31] <foxbuntu> a pc adapter for what?
[23:31] <Chaorain> the remote
[23:31] <foxbuntu> you mean the receiver?
[23:31] <Chaorain> for the IR signals
[23:31] <Chaorain> yes
[23:31] <foxbuntu> yes
[23:32] <foxbuntu> well thats more difficult than it would seem, usually the receiver and remote are paired up
[23:33] <foxbuntu> Chaorain, your best option is to buy an WIndows MCE remote
[23:33] <Chaorain> hm
[23:33] <Chaorain> rather just keep my current remote
[23:33] <Chaorain> thanks for the advice
[23:33] <foxbuntu> Chaorain, then if you want a universal, go with something that can learn/emulate those codes (i.e. Logitech harmony)
[23:34] <foxbuntu> Chaorain, you should be able to find a remote with the ir receiver for ~$30
[23:35] <Chaorain> Samsung IR reciver is under Mythbuntu control center remotes
[23:36] <foxbuntu> Chaorain, yea, its supported, but you need a specific model
[23:36] <foxbuntu> Chaorain, you are likely to spend as much on that as an MCE remote combo, and the MCE has better support
[23:37] <Chaorain> all I need it for is my tv/mythbuntu
[23:38] <foxbuntu> Chaorain, let me put it this way, then you make your own informed decision:
[23:38] <Chaorain> k
[23:39] <foxbuntu> Chaorain, 1) Find Samsung IR Receiver supported by Lirc and configure that to work with Mythbuntu 2) Buy MCE remote and IR Receiver (combo) which has better support and is known to work better than any other remote
[23:40] <foxbuntu> Chaorain, your issue is not the specific remote, its the IR Receiver
[23:40] <foxbuntu> Chaorain, the reason for buying the MCE remote is due to gaining the IR Receiver packaged with it
[23:41] <Chaorain> any other reason for the MCE remote? I already have the Samsung one. Came with the TV.
[23:42] <foxbuntu> what do you mean, any other reason?
[23:43] <foxbuntu> Chaorain, what dont you understand about what I have told you?
[23:43] <Chaorain> nevermind I get it
[23:43] <foxbuntu> Chaorain, if you want to stick with the Samsung remote then go find the Samsung USB IR Receiver
[23:44] <Chaorain> hard to find
[23:44] <foxbuntu> exactly
[23:44] <Chaorain> ah
[23:44] <foxbuntu> MCE Remote with working IR Receiver and Configuration - Easy to find
[23:44] <Chaorain> oh MCE is easy to set up I take it
[23:45] <foxbuntu> http://www.google.com/products?hl=en&client=firefox-a&rls=com.ubuntu:en-US:unofficial&hs=wwi&q=mce+remote&um=1&ie=UTF-8&ei=buOhSe-OOYTUMc_f3MQL&sa=X&oi=product_result_group&resnum=1&ct=title
[23:45] <foxbuntu> Chaorain, yes, I would say its the most common remote
[23:46] <Chaorain> thanks for all the help


[17:30] <Deflinhec> hi
[17:30] <Deflinhec> anyone
[17:30] <Deflinhec> is there any way to install ubuntu without cd and usb


[17:26] <jmgalloway> can someone tell me what directory the images are stored in the walrus controller?
[17:27] <TeTeT> jmgalloway: /var/lib/eucalyptus/bukkits/
[19:29] <jmgalloway> how can I specify which ports to open when I launch a vm?
[20:29] <marrusl> jmgalloway, this is a great guide:  http://cssoss.files.wordpress.com/2010/06/book_eucalyptus_beginners_guide_uec_edition1.pdf
[20:29] <marrusl> jmgalloway, check chapter 8 for network security management.
[20:32] <marrusl> jmgalloway, and fwiw... this is the best place to go for UEC docs.... https://help.ubuntu.com/community/UEC/
[20:34] <jmgalloway> Thanks I will check it out
[20:34] <marrusl> and in no way was that a suggestion to rtfm.  ;-)  just a good link to have.
[20:35] <jmgalloway> I've used that manual a lot.  It has really good info
[20:36] <jmgalloway> I think I jumped ahead to fast and used hybridfox...I am learning to use uec from the command line now
[20:36] <marrusl> indeed.  but yes, the short version is you want to look into the "euca-authorize" command
[20:37] <marrusl> Yup, jmgalloway, I agree.  The best way to do it is the hard way at first and then switch to something like hybridfox.
[20:37] <jmgalloway> yeah, I've been using that, just not declaring a security group when I do
[20:37] <marrusl> when you know the internals, it's going to come in handy when things go wrong off the GUI
[20:37] <jmgalloway> that's true.  Even the uec gui has trouble some times
[20:38] <marrusl> Indeed, and of course, you soon find out that it's only a small fraction of the functionality.
[20:38] <jmgalloway> that's true
[20:38] <marrusl> for the most part, the only thing I do out of the GUI is, a) download my credentials and b) change the default instance sizes.
[20:39] <marrusl> There are other bits, but it has little to do with managing EMIs and managing instances.
[20:39] <jmgalloway> a question...so if I put a user in a security group with specific ports open..each time they launch a vm, only those ports will be open right?
[20:39] <marrusl> Hmm.  It's really the instance that belongs to the security group the way I look at it.
[20:40] <jmgalloway> yeah, ok I see that now.
[20:41] <jmgalloway> euca-run-instances emi-XXXXXXXX -k mykey -g webservers
[20:41] <jmgalloway> webservers is the security group
[20:43] <jmgalloway> is there a way to delete the default security group?
[20:44] <marrusl> Hmm... good question.  never tried. You can always leave it with nothing authorized if not.
[20:46] <jmgalloway> well the reason I ask is because I created 4 admin accounts, then created security groups for all of them.  I am returning back to a single admin account and want to clear those old groups.
[21:14] <marrusl> jmgalloway, sorry, I was away from the keyboard there for a few...  euca-delete-group is the command you are looking for.
[21:15] <marrusl> all the euca2ools are well documented and have good man pages, fwiw.
[21:29] <jmgalloway> yeah I've used that
[21:29] <jmgalloway> it doesnt delete the default groups
[21:33] <jmgalloway> where are the groups located...which directory?
[21:38] <marrusl> jmgalloway, Hm.  interesting.  not sure where that's stored.   you may be running into the same issue as this fellow:
[21:38] <marrusl> http://open.eucalyptus.com/forum/how-delete-removed-users-security-group
[21:38] <marrusl> nobody answered his question, but he's a  colleague of mine.
[21:39] <marrusl> if you ping me back on this channel tomorrow, I can see if he made any progress with that question.
[21:39] <marrusl> perhaps if you recreate the users and try to delete the groups again?  then redelete the users./
[21:41] <marrusl> jmgalloway, actually, he will be on this channel tomorrow probably, his nick is TeTeT.
[21:42] <jmgalloway> ok thanks


[00:03] <YokoZar> Who do I poke for a higher PPA size limit?
[00:11] <mwhudson> YokoZar: ask a question at answers.launchpad.net/soyuz i think
[01:04] <TheMuso> Is it just me, or is sbuild rather broken in natty?
[01:06]  * TheMuso notes he is not currently using a .sbuildrc
[01:08] <RAOF> Not broken, but certainly *seriously* chatty about debug_level
[01:09] <RAOF> Certainly not screen-reader friendly :)
[01:11] <TheMuso> heh right. I was wondering whether that had to do with why packages/essential build deps step is failing... Maybe my chroot is broken...
[01:11] <TheMuso> I.e essential build deps not being satisfied.
[01:11] <RAOF> Oh, that.
[01:11] <RAOF> I don't think I hit that brokenness because I use the aptitude resolver.
[01:11] <TheMuso> Ah.
[01:12] <RAOF> (Because I need to build against Debian experimental sometimes, and that requires the aptitude resolver to work properly)
[01:12] <TheMuso> Right.
[01:12] <TheMuso> How does one change that?
[01:12] <RAOF> $build_dep_resolver = 'aptitude'; in ~/.sbuildrc
[01:13] <TheMuso> Thanks, not mentioned in the example.
[01:15] <TheMuso> Ah much better. :)
[01:17] <TheMuso> Oh it failed because there are actually broken packages in the archive. :)
[01:19] <RAOF> Heh
[01:20] <ebroder> RAOF: following up from the conversation yesterday, do you think that delaying X from changing modes until g-s-d is up is something that could happen this cycle?
[01:20] <RAOF> ebroder: Yes, I think it could.
[01:21] <RAOF> I'll be walking through that code as a part of the multi-monitor experience stuff anyway.
[01:21] <ebroder> Cool. Do you know yet when you expect to be looking at it? (It looks like I may need to attempt to backport whatever you come up with for work)
[01:22] <RAOF> I was going to wait until we'd decided whether or not we were going to ship xserver 1.10; that'll be the beginning of December.
[01:23] <RAOF> I could re-order that, though, and just work on xserver master (+ possibly backporting) anyway.
[01:23] <ebroder> I don't want to make you go out of our way - I'm just making sure I know what to tell my boss when he asks :)
[01:59] <psusi> I have found the information in sysfs needed to decide that a disk is esata, and therefore udisks should auto mount it, but I'm a little confused and as a result, can't figure out how to have udev extract that information.  Specifically the disk device is a child of a scsi target, which is a child of a scsi host, and the scsi host has a scsi_host/hostN/ahci_port_cmd file with the bit that says it's eSATA.
[01:59] <psusi> but it seems that udev searches for attributes walking up the tree, but you have to go back down a level to reach that attribute... which I can't make sense of or figure out how to get udev to do
[02:01] <psusi> it seems like sometimes a subdirectory in sysfs means it is a new device that is a child of the parent, and sometimes subdirectories are... personalities, for lack of a better term, of the device, but I can't figure out how to tell the difference or how to get udev to look at the attributes of a personality
[02:38] <TheMuso> Ah. So thats why compiz is broken installability wise.
[02:39] <TheMuso> Hrm but the build log shows things correctly...
[02:42] <TheMuso> Hrm, mirror skew.
[02:42]  * TheMuso refreshes local mirror.
[04:16] <ebroder> How would people feel about SRUing the fix for bug #589487 to Lucid and Maverick?
[04:16] <ebroder> Sorry - that's Debian bug #589487, ubottu :)
[08:39] <pitti> Good morning
[08:40] <pitti> superm1: right, it uses optipng and advancecomp on those
[08:40] <pitti> superm1: yes, I did :)
[08:40] <dholbach> good morning!
[08:40] <pitti> superm1: http://launchpadlibrarian.net/58704226/optipng-check FYI
[08:41] <pitti> superm1: I used find /usr/share -name '*.png' | ./optipng-check
[08:50] <pitti> cjwatson: FYI, apt-listchanges should now work again as of yesterday evening; I tested it on a bunch of .debs (like on upower, which still has no changelog at all); but I couldn't get the apt-get dist-upgrade integration to work, not even with fully "normal" packages
[08:59] <pitti> cjwatson: bah - after having said that, it just worked for my current dist-upgrade
[09:54] <cjwatson> pitti: cool, thank you!  I haven't upgraded to natty yet
[09:55] <ion> apt-listchanges works fine in my natty. Upgraded from maverick a couple of days ago.
[09:57] <pitti> ion: it didn't show changelogs for packages which got their debian changelog completely stripped
[09:57] <pitti> that happened for a week
[10:05] <pitti> tkamppeter: won't coldplugging fail as well if there is no local unix socket?
[10:05] <pitti> tkamppeter: I made my patch so that it skips coldplugging in that case
[10:05] <pitti> tkamppeter: since it's very likely to fail
[10:06] <pitti> tkamppeter: and at that point (if you disable the local socket) you are on your own anyway IMHO
[10:06] <pitti> ah, I finally got cups to build with gcc 4.5
[10:08] <dholbach> lamont, how does the patch in bug 674199 - would you get it into debian too?
[10:08] <dholbach> ... err ... how does it "look to you"? :)
[10:12] <tkamppeter> pitti, cold-plugging only needs the presence of CUPS. CUPS is only accessed via system-config-printer (executables udev-configure-printer and udev-add-printer) and this also works if CUPS is configured for local access via localhost.
[10:13] <pitti> tkamppeter: it tries socket and localhost TCP?
[10:14] <tkamppeter> pitti, s-c-p does not nail down the access method. It simply uses libcups through the pycups byndings.
[10:20] <tkamppeter> pitti, why do you supply the upstart script as a patch? It is one file in debian/ and no change on upstream files, so it is much simpler to supply the file directly.
[10:20] <pitti> tkamppeter: can't, since then it would be used in Debian as well
[10:20] <pitti> well, I don't know the exact reason any more, but having both in debian/ breaks stuff
[10:21] <pitti> yep, apparently it was that
[10:22] <pitti> in debian we need the init.d script
[10:40] <htorque> hi everyone! i have a created a custom shortcut to 'gnome-screenshot --area' and it only works if i press it twice (fast). running the command from the terminal and via a panel launcher works fine. is this more likely a bug in gnome-screenshot or in gnome-settings-daemon?
[10:43] <ogra> cjwatson, would you object to build dpkg with dropped optimization for arm until the toolchain issue is fixed (so we can build images)
[10:52] <tkamppeter> pitti, thanks for the patches on the PDF filters so that they build under GCC 4.5.x. I have upstreamized the changes now.
[10:52] <cjwatson> ogra: I'd rather have actually analysed the problem first
[10:52] <cjwatson> nobody else's images work yet either :)
[10:52] <ogra> cjwatson, indeed, but i'd like to have something by A1
[10:52] <ogra> no hurry yet indeed
[11:17] <pitti> tkamppeter: oh, cool; thanks
[11:25]  * cjwatson promotes unionfs-fuse temporarily
[11:25] <cjwatson> (let's see if that helps)
[11:36]  * pitti takes a first look at oversizedness
[11:37] <pitti> so we added 23 MB of packages and some grew quite a bit (gnome-system-monitor 1.8 MB, linux-firmware 3.9 MB)
[11:38] <pitti> out of interest, why do we currently install two python versions by default?
[11:40] <pitti> oh, and we have libicu42 and 44, both 7 MB
[11:40] <pitti> an OO.o rebuild should get us rid of 32
[11:40] <pitti> 42, I mean
[12:18] <ogra_ac> pitti, how does the WI tracker handle the new spec namings, i.e. it currently mainly points to $team-$release_letter- will it automatically match $track-$teram-$release_letter- with that ?
[12:19] <ogra_ac> s/teram/team
[12:19] <pitti> ogra_ac: it doesn't care about spec names except for the contact point
[12:19] <ogra_ac> k
[12:19] <pitti> ogra_ac: it reads the specs targetted to natty
[12:19] <pitti> ogra_ac: and the contact point regexps over the names have been adapted
[12:20] <ogra_ac> well, i have 'canonical-mobile':         'mobile', in the teams list for my team
[12:20]  * pitti uploads a fixed pkgbinarymangler to reclaim the 1.8 MB that gnome-system-monitor has grown
[12:20] <ogra_ac> if i change the latter to arm that should just work ?
[12:21] <pitti>     'arm-'<EMAIL_ADDRESS>[12:21] <pitti> that's the contact point
[12:21] <ogra_ac> yes, that will go away
[12:21] <ogra_ac> linaro wont use arm- anymore
[12:21] <ogra_ac> thats reserved for ubuntu arm
[12:21] <pitti> ogra_ac: oh, I'm not sure about that "roadmap" thing, this is an apw-ism I believe
[12:22] <ogra_ac> i'm just concerned about the teams
[12:22] <pitti> ogra_ac: so please update the error_contact matches as appropriate
[12:22] <ogra_ac> yes, thats what i plan
[12:22] <ogra_ac> but i'm not clear about the teams stuff yet
[12:22] <pitti> ogra_ac: teams has to include all teams who we want to generate reports for
[12:22] <ogra_ac> yes
[12:22] <pitti> (other than the "all teams" report
[12:23] <ogra_ac> as i said above, my team currently uses the "mobile" tag
[12:23] <ogra_ac> for natty we properly switched to "arm"
[12:23] <ogra_ac> i was just wondering if that will properly match
[12:24] <ogra_ac> linaro will likely do its own thing and drop the 'arm' match from its setup
[12:26] <pitti> ogra_ac: error_contacts does match over the spec names, yes
[12:26] <ogra_ac> and teams ?
[12:26]  * pitti toddles off for lunch, bbl
[12:26] <pitti> ogra_ac: teams are not a match, they are a simple list
[12:26] <ogra_ac> ah, k
[12:26] <pitti> ogra_ac: I don't know what the "roadmap" bit is for, i. e. the values in the teams map
[12:26] <ogra_ac> then the header is wrong
[12:26] <ogra_ac>     # lp team                   # spec name match to show up in roadmap
[12:27] <pitti> ogra_ac: the value is presumably a spec name match
[12:27] <pitti> but not the keys
[12:27] <ogra_ac> k
[12:28] <ogra_ac> go to lunch :)
[13:47] <mterry> james_w, pkgme trunk has odd layout: pkgme/pkgme/* instead of pkgme/*
[14:09] <james_w> mterry, hmm, that's certainly not what I was intending
[14:10] <james_w> mterry, looks ok to me. Did you just check the branch out as pkgme?
[14:11] <mterry> james_w, just tried it again and it was fine.  I must have created a pkgme directory in the past without realizing it, and the branch created a subdirectory for me
[14:11] <mterry> whoops
[14:14] <james_w> mterry, np. How's the vala backend looking?
[14:15] <mterry> james_w, good...  I did some yak-shaving with vala-dep-scanner (which discovers dependencies)
[14:15] <james_w> cool
[14:16] <james_w> mterry, you might have seen that trunk now has ./bin/pkgme, and it will work on itself as there is a rudimentary python backend. My next task is to get it to write a changelog, as currently you can't build a source package from it.
[14:36] <mdeslaur> cjwatson: is it normal that tarballs on merges.ubuntu.com come with patches _already applied_ but no .pc directory?
[14:37] <ari-tczew> good occasion to ask about .pc files in patches created by MoM - can we avoid to not including .pc files?
[14:39] <Chipzz> ari-tczew: I assume you mean "avoid including .pc files". But why on earth would you want that?
[14:40] <ari-tczew> Chipzz: useless data. merges patched should be as clear as possible.
[14:42] <Chipzz> ari-tczew: I assume you mean patches which are shipped as a diff as part of the tarball should be applied before doing the diff?
[14:42] <Chipzz> "as part of the tarball" -> "as part of the debian diff"
[14:43] <Laney> You can use filterdiff to remove the .pc file from the diff you are looking at, but it's not useless data.
[14:43] <Laney> There was a discussion yesterday (I believe) about this
[14:43] <ari-tczew> Chipzz: dunno how, just I hate cutting MoM patches from .pc files.
[14:43] <ari-tczew> I just want to in diff: -x '.pc'
[14:43] <ari-tczew> .pc~
[14:44] <Chipzz> but...
[14:44] <Chipzz> .pc~ looks like a backup
[14:44] <cjwatson> mdeslaur: 3.0 (quilt), I assume?
[14:44] <mdeslaur> cjwatson: yeah :(
[14:44] <Chipzz> seriously, you should just have cleaned your shit up and removed stray backup files
[14:44] <cjwatson> the problem with just removing .pc is that people need to know how to operate on the quilt patches if you do that
[14:45] <cjwatson> I don't think this can be fixed solely in MoM - dpkg needs to be improved.  I filed a bug some time ago about that
[14:45] <cjwatson> I did think about simply removing .pc from MoM patches a while back, but concluded that it wasn't that simple
[14:46] <ari-tczew> Laney: I never heard about include .pc files in merges. Did I came back from moon?
[14:47] <Chipzz> ari-tczew: lets for a moment assume you meant .pc and not .pc~ ... what you're asking for is basically doing the patching (ie, a step of the build process) while diff'ing
[14:47] <Chipzz> and diff'ing has very little to do with building
[14:48] <ari-tczew> sorry, I have no strength to explain in detail what I mean. For me case is clear.
[14:49] <ogra_ac> doko, could you take a look at bug 674146 ? seems to be a toolchain issue
[14:50] <skkeeper> hi everyone, can someone tell me if its possible to drag a foreign window (firefox for example ) to my pygtk aplication?
[14:51] <Chipzz> skkeeper: wrong channel :)
[14:51] <skkeeper> shit
[14:51] <skkeeper> sry
[14:51] <doko> ogra_ac: isn't james hunt looking at this one?
[14:51] <skkeeper> i noticed
[14:51] <skkeeper> xchat changed on me
[14:51] <skkeeper> xd
[14:51] <Chipzz> and I don't think you can - not with arbitrary windows anyway
[14:51] <ogra_ac> doko, yes, but not at the toolchain stuff
[14:52] <ari-tczew> doko: did you read my mail about sync gcc-snapshot ?
[14:52] <doko> ogra_ac: are you sure that this is not due to the optimized memcpy?
[14:52] <doko> ari-tczew: why? there will be a new snapshot anyway
[14:53] <ogra_ac> doko, doesnt that live in the toolchain ?
[14:53] <cjwatson> doko: see my comment - I'm pretty certain it has nothing to do with memcpy, it's plain wrong assembler
[14:53] <Chipzz> cjwatson: why would you want to remove .pc files from patches? or do you mean .pc files which aren't shipped by upstream, but which are shipped by ubuntu?
[14:53] <cjwatson> Chipzz: sorry, I don't have time to go into this in more detail today again.  We had a longish discussion about it here just yesterday
[14:54] <Chipzz> cjwatson: np, just trying to understand the issue :)
[14:54] <ari-tczew> doko: hmm, I think about upload to Debian first and autosync to Ubuntu.
[14:57] <ari-tczew> Chipzz: are you familiar with merging?
[15:01] <mterry> james_w, how do I run the pkgme testsuite?
[15:02] <james_w> mterry, you can install testrepository and use "testr run"
[15:02] <james_w> and python-subunit too
[15:02] <james_w> mterry, I think setup.py test works as well
[15:03] <mterry> james_w, ah, it does now that I have the packages
[15:08] <mterry> james_w, do they pass for you?  I get errors like "AssertionError: Backend python (/home/mike/Projects/natty/pkgme/build/lib.linux-x86_64-2.6/pkgme/tests/../backends/python) has no 'want' script" and the backends don't seem copied to the build directory
[15:11] <james_w> mterry, ah, I haven't run them with setup.py yet. Seems setup.py is missing some of what we need.
[15:11] <mterry> james_w, testr run gives "ImportError: No module named Cheetah.Template", so maybe I'm missing something
[15:14] <mterry> and after installing python-cheetah and running 'testr init', I get AttributeError: 'module' object has no attribute 'test_backend' from testr run
[15:15] <pitti> cjwatson: heh, catching up with lucid fixes? :-)
[15:18] <cjwatson> pitti: yeah, a bit :)
[15:20] <pitti> ugh, that fuse upload has quite a diff
[15:21] <cjwatson> pitti: yeah, as I said in the SRU bug the three upstream patches I backported were so entangled and subtle I reckoned that if I tried to disentangle them I was likely to do more damage
[15:21] <pitti> *nod*
[15:21] <cjwatson> it was "add --no-canonicalise" "fix race condition [unclear if it was related]" "fix weird interaction between previous two"
[15:22] <Chipzz> ari-tczew: I've never actually done a merge, but I can imagine how it works, yes
[15:23] <psusi> pitti: just replied to your email... take a look and see if you can help me figure it out... or maybe involve someone more knowlegable about udev?
[15:24] <pitti> psusi: what I don't understand is why you so desperately need this in the udev db
[15:25] <pitti> psusi: why can't udisks check the sysfs attribute? it can then do some more elaborate checks of its parents and siblings
[15:25] <psusi> well, I guess it doesn't have to go there, it just seems to be a good place to put it once it's figured out... seems like what it's for
[15:25] <pitti> with the gudev interface
[15:25] <psusi> I suppose it could...
[15:25] <pitti> psusi: actually it's not; the udev db shouldn't really replicate stuff that's already in sysfs
[15:26] <pitti> we should add new information to it, like "this device is a camera" (ID_GPHOTO), or "don't show this for automount" (UDISK_PRESENTATION_HIDE) or so
[15:26] <psusi> but it seems like it might be better to keep udisks generalized to just checking a well known external attribute on the disk in the udevdb, and leave it to udev rules to figure out if the disk is external...
[15:26] <pitti> we _do_ replicate a few bits for convenience, like from usb_id
[15:26] <pitti> psusi: well, it's a valid approach as well
[15:26] <james_w> mterry, that will be another missing dependency. Probably python-fixtures, that I think is just in natty
[15:27] <pitti> psusi: you could just join #udev, explain the situation a bit, and then we'll discuss with davidz and kay
[15:27] <psusi> ok
[15:27] <pitti> psusi: i. e. the bit that we need to check is in the parental chain?
[15:28] <pitti> ah, no, nevermind; saw your mail
[15:28] <hallyn> james_w: barry: hi, ISTR a recent email about UDD talking about .pc/ inclusion.  Was there such an email, and what did it decide?
[15:28] <mterry> james_w, apt-cache search fixtures doesn't come up with anything named that, and the couple packages that it does hit don't make the testr run error go away (i'm in natty)
[15:29] <psusi> pitti: yea, up, but then back down another branch for some reason
[15:29] <ari-tczew> Chipzz: my advice: do some merges and then talk about .pc utility in patches.
[15:29] <james_w> hallyn, there was, it is on my to-reply list
[15:30] <james_w> mterry, hmm, maybe it's not landed in natty. I thought Rob uploaded it
[15:30] <james_w> barry, what's the best way for mterry to continue?
[15:30] <hallyn> james_w: ok, thanks.
[15:31] <ebroder> ari-tczew: the .pc files are a limitation of source format 3.0 (quilt)
[15:31] <BlackZ> cjwatson: as far as you know, is there any bug report about ubiquity not making the installation possible because of the user account chosen starting with a capital letter?
[15:32] <BlackZ> cjwatson: from what I seen it makes the installation not possibile without a warning; do you plan to add a warning for that?
[15:32] <ari-tczew> BlackZ: are you going to merge sbuild?
[15:32] <Chipzz> ari-tczew: no need to belittle me; I follow the conversations here closely, and I try to be aware of how things work
[15:33] <jdstrand> barry: hi!
[15:33] <mterry> james_w, I'm not blocked.  setup.py test works for me, as long as I copy the backends into place
[15:33] <Chipzz> ari-tczew: and IMO you're the one that's wrong; if ubuntu ships a .pc file that doesn't exist upstream, that IS an integral part of the diff
[15:33] <ari-tczew> Chipzz: I only show the way to the best understand.
[15:33] <Chipzz> ari-tczew: what if the .pc accidently gets dropped?
[15:33] <james_w> mterry, ok, great
[15:33] <BlackZ> ari-tczew: I'll merge it but if you want to, I don't mind :)
[15:34] <jdstrand> james_w: actually, I will 'hi' you too :)
[15:34] <ari-tczew> Chipzz: merges should include only really required changes.
[15:34] <james_w> hi jdstrand
[15:34] <ogra_ac> pitti, any idea who from the SRU team pushed alsa-utils to updates ? the fix is not done yet at all
[15:34] <jdstrand> barry, james_w: I am having trouble with udd. see http://paste.ubuntu.com/530751/
[15:34] <pitti> ogra_ac: it was verified..
[15:34] <ogra_ac> huh ?
[15:34] <ari-tczew> Chipzz: sorry, I don't have a time to explain how merge works if you didn't done any merge and you think that I;m wrong.
[15:34] <ogra_ac> i talk about bug 637947
[15:35] <jdstrand> james_w, barry: basically, with libvirt, we have been doing the whole 'quilt push -a ; bzr add' methodology
[15:35] <jdstrand> james_w, barry: but the tree with my commit yesterday for 0.8.5-0ubuntu1 totally blew apart with today's 'bzr update'
[15:35] <jdstrand> (a gagillion conflicts)
[15:35] <ogra_ac> pitti, it definitely wasnt verfied
[15:36] <ogra_ac> and its totally broken in -updates now
[15:36] <cjwatson> BlackZ: already fixed in natty - bug 555896
[15:36] <Chipzz> ^^
[15:36] <BlackZ> cjwatson: I thought that, thanks!
[15:36] <jdstrand> so I compared the apt-get source with what is in a newly checked out branch, and see that there are some slight differences... (as seen in the paste)
[15:37] <ari-tczew> BlackZ: no, just I'm amazed that you didn't take this one yet :) (I know that sometimes you can response quickly)
[15:37] <jdstrand> james_w, barry: ^ (this is a source format 3.0 (quilt)) package
[15:37] <ogra_ac> pitti, ugh, i see what heppened, seems lag just set it to fix released
[15:37] <ogra_ac> based on a totally unrelated comment in that bug
[15:37] <jdstrand> james_w, barry: is there an official sanctioned way to handle quilt source format 3.0 with udd?
[15:38]  * ogra_ac curses
[15:38] <jdstrand> james_w, barry: every time I try to do it with libvirt, it blows up and I waste a ton of time. I seem to be doing it wrong, though I've tried several different things...
[15:38] <BlackZ> ari-tczew: I'll merge it then; I noted that now
[15:38] <pitti> ogra_ac: so, do we need to pull that alsa-utils package from maverick-updates then, or follow up with a reversion? for armel? was it the kernel or alsa-utils which caused the regressinon?
[15:39] <ogra_ac> pitti, kernel is fine, alsa-utils isnt even near to be finished
[15:39] <ogra_ac> pitti, how hard is it to pull it ?
[15:39] <lag> ogra_ac, pitti: My bad :(
[15:39] <ogra_ac> i'll have a completed fix on monday
[15:40] <ogra_ac> lag, yeah, the conversation on that bug was quite confusing
[15:40] <pitti> ogra_ac: is 3.3 enough?
[15:40] <pitti> ogra_ac: we could upload a 3.5 which is 3.3
[15:41] <ogra_ac> pitti, i had uploads from ubuntu3 on, i'm not sure which one would unbreak
[15:41] <james_w> jdstrand, from your brief description it sounds like the right approach to me. I don't have enough info to be able to say straight away why you got the conflicts though.
[15:41] <ogra_ac> pitti, after all it only breaks on omap4, we could still leave it in but be fast with the next upload
[15:42] <jdstrand> james_w: so the correct approach ismake sure to use 'quilt push -a', 'bzr add', bzr ci?
[15:42] <BlackZ> ari-tczew: I seen right now that lool merged it
[15:42] <ogra_ac> pitti, if we can do a fast path for the actual 3.5 we shouldnt need to pull it
[15:42] <james_w> jdstrand, yes, I think so
[15:42] <jdstrand> james_w: right, so that is what I did :)
[15:43] <jdstrand> james_w: but if you look at the paste, there is a difference between the apt-get sourced package and the branch
[15:43] <ari-tczew> BlackZ: ok sorry then for messing your head :)
[15:43] <jdstrand> james_w: which presumably has to do with the quilt source format 3.0 stuff...
[15:43] <james_w> jdstrand, right, that may be different dpkg-dev versions?
[15:43] <pitti> ogra_ac: so looking at https://launchpad.net/ubuntu/maverick/+source/alsa-utils/+changelog it seems that all SRUs were omap4 related, so if it causes trouble, we could pull it; but I'd prefer a new version, as we can't otherwise get it off people's systems
[15:44] <ogra_ac> pitti, ok, then just leave it as is and i'll have a fix on monday
[15:44] <jdstrand> james_w: ugh. I'm on maverick, the package is natty and I don't know what udd used behind the scenes...
[15:45] <hallyn> and, you shouldn't have to (he mumbles)
[15:45] <cjwatson> james_w,jdstrand: I've found that I generally have to do 'bzr add .pc/new-patch-name.patch/*' or life is inconsistent
[15:45] <jdstrand> cjwatson: I did that
[15:45] <cjwatson> (and there's a udd bug about that, I blieve)
[15:45] <james_w> jdstrand, hardy with a backported dpkg-dev I think
[15:45] <cjwatson> *believe
[15:45] <hallyn> and, you shouldn't have to (he mumbles again)
[15:45] <cjwatson> hallyn: indeed not
[15:45] <jdstrand> cjwatson: well, much more generally, I just did 'bzr add'
[15:45] <james_w> hallyn, I absolutely agree, but bugs happen
[15:45] <pitti> ogra_ac: ok
[15:46]  * jdstrand can't decide on the most robust approach...
[15:46] <hallyn> james_w: my problem with keeping the patches applied is that when you refresh patches, bzr doesn't seem to want to do the right thing with updating .pc/ contents
[15:47] <james_w> hallyn, agreed
[15:47] <jdstrand> james_w: slight history, hallyn and I (and soren) are trying to coordinate our libvirt work with udd
[15:47] <hallyn> (and it complicates updates in general)
[15:48] <hallyn> but, ok, - i wanted to check whether 'keep the patches applied' is the accepted best practice
[15:48] <jdstrand> yeah. it hasn't worked right yet... I feel like we are doing it wrong cause people are obviously using it, but based on feedback just now, it seems we are using the recommended procedures
[15:48] <james_w> hallyn, it is, and it sucks
[15:48] <cjwatson> hallyn: we talked about this yesterday, and what I said, in brief, was that for my own 3.0 (quilt) packages in bzr I just don't revision-control .pc, and that for the most part this works better *except* that people have to know to run a magic command after checking out or (sometimes) updating the branch
[15:48] <littlegirl> Hey there, do any of you devs know when the 260 series of NVIDIA drivers will be made available via Ubuntu --> System --> Administration --> Hardware Drivers?
[15:48] <jdstrand> cjwatson: do you quilt pop -a or just bzrignore .pc?
[15:49] <cjwatson> I keep patches pushed, quite deliberately
[15:49] <cjwatson> I just don't check in .pc
[15:49] <jdstrand> hallyn: I guess we can try to bzrignore .pc
[15:49] <cjwatson> but this doesn't work well when the importer touches the branch (so I try to avoid that happening ...)
[15:50] <cjwatson> if the importer has already given you a .pc, you need to keep it consistent
[15:50] <cjwatson> an inconsistent .pc is worse than either other option
[15:50] <jdstrand> cjwatson: can you explain that last comment? how do we keep the importer from touching the branch?
[15:50] <littlegirl> Hey there, do any of you devs know when the 260 series of NVIDIA drivers will be made available via Ubuntu --> System --> Administration --> Hardware Drivers?
[15:50] <cjwatson> do absolutely everything in bzr, mark-uploaded before uploading, etc.
[15:51]  * jdstrand will need to read the latest on UDD
[15:51] <jdstrand> I think I am out of date...
[15:51] <cjwatson> littlegirl: have you searched the bug database to see if there's a thread there?  repeating your question here probably won't help
[15:52] <ebroder> Is there a way to search for LP bugs linked to a particular Debian bug?
[15:52] <cjwatson> ebroder: yes, but it's a bit obscure, one moment
[15:52] <littlegirl> cjwatson: The bug database contains the bug that lead to this question. I'm not asking about a bug. I'm asking when the latest version of the NVIDIA driver will be made available in Ubuntu. This seems like the most appropriate place to ask that question.
[15:53] <jdstrand> hallyn: I didn't "bzr mark-uploaded"
[15:53] <jdstrand> I was unaware of that command
[15:53] <cjwatson> littlegirl: I'm asking because if you have a bug number I might be able to interpret it better.  (I don't know anything about nvidia)
[15:53] <hallyn> jdstrand: i've never heard of it
[15:53] <jdstrand> james_w, cjwatson: thanks
[15:54] <jdstrand> hallyn: https://wiki.ubuntu.com/DistributedDevelopment/Documentation. specifically 'Uploading a package'
[15:54] <littlegirl> cjwatson: It's not about a bug. I am asking when the most recent NVIDIA driver will be made available via the Ubuntu --> System --> Administration --> Hardware Drivers interface that comes by default with Ubuntu. This has to be a bug in order for developers to help me with it?
[15:55] <cjwatson> ebroder: https://bugs.launchpad.net/bugs/bugtrackers/debbugs/<bugnumber>
[15:55] <ebroder> cjwatson: Awesome, thanks
[15:55] <cjwatson> littlegirl: well, I don't know the answer to that question.  If you happened to have a bug number I might have been able to make an intelligent guess.  And no, it's not usually best to just ask here - not all developers are on IRC, particularly not at any given time
[15:56] <cjwatson> it seems to be in 10.10 already; as for lucid, I don't know
[15:56] <cjwatson> (but I'm just looking at package versions here)
[15:56] <littlegirl> cjwatson: Here is the bug: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/629910 and here is the solution: http://www.nvnews.net/vbulletin/showthread.php?p=2314331 but the solution is not available via Ubuntu --> System --> Administration --> Hardware Drivers.
[15:56] <hallyn> i suspect #ubuntu-kernel is the place to ask?
[15:57] <littlegirl> cjwatson: If the developers cannot be contacted via IRC, how do I contact the developers that are in charge of the Hardware Drivers interface?
[15:57] <jcastro> or #ubuntu-x
[15:57] <cjwatson> you shouldn't contact the developers responsible for Hardware Drivers for this.
[15:57] <jdstrand> cjwatson: so, iiuc, I do a branch, I do my quilt work, I bzr add debian/patches (ie, ignore adding .pc), then bzr mark-uploaded, then bzr push.
[15:57] <littlegirl> Lucid is the LTS. Why is a fix that is in place in 10.10 not in place for the LTS?
[15:57] <cjwatson> the change wouldn't be made by changing that interface, it would be made by upgrading the nvidia-graphics-drivers package
[15:57] <jdstrand> cjwatson: (I forgot to commit in there, but you get the idea)
[15:58] <ebroder> littlegirl: We are probably not going to do a significant update like for an Ubuntu version that's already been released. However, there are generally newer versions of the proprietary NVIDIA and ATI drivers available at https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates
[15:58] <cjwatson> lots and lots and lots and lots and lots of changes are in later versions and not in the LTS - the LTS only gets high-priority changes
[15:58] <cjwatson> tseliot is the developer assigned to that bug
[15:58] <cjwatson> he's not here right now
[15:59] <cjwatson> but he would be the person to ask, I imagine
[15:59] <cjwatson> of course, that bug as such doesn't seem to apply to 10.04 - it's about a regression in nvidia 256.53, and 10.04's version is older than that (195.36.24, by the looks of things)
[16:00] <littlegirl> ebroder: Thank you for the link! If I add that PPA to my system, will the Hardware Driver interface offer me the latest driver or will I still have to add that manually?
[16:00] <cjwatson> jdstrand: this only works if the branch doesn't already have a .pc
[16:00] <ebroder> littlegirl: I honestly have no idea
[16:01] <littlegirl> Also, it is a very bad idea for you guys not to fix this in the LTS, since it *is* an LTS. This is a serious bug that affects text scrolling in everything (terminal and text programs) and I can't believe you would want to leave the LTS in such a condition.
[16:01] <jdstrand> cjwatson: the main point of my question isn't a rehash of UploadingAPackage but getting at your workflow for avoiding .pc breakage
[16:01] <littlegirl> ebroder: Well, thank you again anyway. That PPA will probably be a huge help. (:
[16:01] <jdstrand> cjwatson: hmm. so I guess we have to fiddle with .pc (it is already there)
[16:01] <cjwatson> littlegirl: "you guys" - the person who'd be involved isn't here so that's a rather misdirected comment
[16:02] <jdstrand> cjwatson: thanks
[16:02] <cjwatson> jdstrand: all of the 3.0 (quilt) packages I care about, I imported by hand myself from previous revision control systems
[16:02] <cjwatson> I don't have a good answer for such packages imported by the UDD importer
[16:02] <littlegirl> cjwatson: 10.04 has 195.36.24, which is way behind.
[16:03]  * jdstrand wonders if we should just ignore the importer branch...
[16:03] <cjwatson> littlegirl: it really is best to raise this kind of thing through the bug tracker, honestly
[16:03] <maco> !sru | littlegirl
[16:03] <littlegirl> cjwatson: It was a general comment regarding whatever the approach is to the LTS.
[16:03] <jdstrand> cjwatson: it would seem I could just bzr --remove .pc and commit and then be ok, no?
[16:03] <cjwatson> jdstrand: I don't know
[16:03] <maco> littlegirl: if you read that page, you'll see the policy reasons why "old" (ie stable)  things are kept around
[16:04] <cjwatson> it's possible the importer will try to put it back
[16:04] <littlegirl> maco: I understand about stable things. This is an unstable thing. (:
[16:04] <cjwatson> (note that these policy reasons are *not* "we don't want to fix important bugs")
[16:04] <jdstrand> james_w: who should I talk to about the importer and the libvirt branch? (I realize this isn't really your main focus these days)
[16:04] <maco> er...that bug just has a link to other stuff...
[16:06] <james_w> jdstrand, I'm happy to talk to you about it, I'm just in the middle of something OMFG URGENT right now, so if you can wait until later I'm happy to chat
[16:06] <jdstrand> james_w: sure. thanks
[16:07] <apw> cjwatson, have you heard of issues with 'all' of a users initramfs's becoming dammaged during an update?
[16:07] <jdstrand> cjwatson: thanks again to you too :)
[16:07] <apw> cjwatson, do we regenerate them all if the tools are updated ?
[16:08] <smb> apw, cjwatson Which was lucid in my case
[16:08] <smb> It was a bigger update though I did not pay attention on what changed
[16:09] <smb> Just seemed that three versions of initramfs were updated into an unusable state
[16:09] <smb> see bug 672964
[16:09] <jdstrand> hallyn: whenever I have my chat with james_w, I'll try to figure out a robust way to udd libvirt, commit my little patch and see how it goes. then I'll talk to you and soren about the new procedure. we can reevaluate if it doesn't work again
[16:10] <hallyn> jdstrand: awesome, thanks
[16:11] <hallyn> jdstrand: i'd like to listen in on yoru conversation, but i've got far less experience with udd than you, obviously - so i only have my blind unreasonable prejudices :)
[16:11]  * hallyn figures that makes him perfect for arguing on irc
[16:11] <jdstrand> hallyn: well, I think you are giving me too much credit. I've had many failures with udd. They are certainly experiences, but to say I have experience with it is probably overstated :)
[16:12] <jdstrand> hallyn: but I'll ping you
[16:13] <cjwatson> apw: not heard of such issues, no.  bootchart regenerates all initramfses, but I don't think other packages do
[16:13] <apw> cjwatson, the error on boot is this "udevadm trigger is not permitted while udev is unconfigured"
[16:13] <cjwatson> don't know, sorry
[16:14] <jdstrand> that isn't totally fair. I have had some successes outside of libvirt
[16:14] <apw> cjwatson, would udev updates not need to regen as well
[16:14] <cjwatson> no, most packages should only regenerate the *current* initramfs
[16:14] <cjwatson> by design
[16:14] <cjwatson> bootchart is a bit unusual because you're going to want to compare multiple kernel versions
[16:14] <apw> cjwatson, ok there was a udev update 3 days ago on lucid
[16:14] <cjwatson> that symptom sounds as though update-initramfs was run between udev unpack and configure
[16:14] <cjwatson> udev itself will not be directly at fault
[16:15] <apw> and as the message is the udev, .... i suspect that update has triggered the issue somehow
[16:15] <cjwatson> no
[16:15] <cjwatson> something else was doubtless upgraded at the same time as udev, and called update-initramfs at an inopportune point
[16:16] <cjwatson> but it's not udev's fault
[16:16] <apw> oh in parallel ... ick
[16:16] <cjwatson> however, udev could avoid the problem by making its initramfs hook more robust
[16:16] <cjwatson> -copy_exec /sbin/udevadm /sbin
[16:16] <cjwatson> +if [ -e /sbin/udevadm.upgrade ]; then
[16:17] <cjwatson> +    copy_exec /sbin/udevadm.upgrade /sbin/udevadm
[16:17] <cjwatson> +else
[16:17] <cjwatson> +    copy_exec /sbin/udevadm /sbin
[16:17] <cjwatson> +fi
[16:17] <ebroder> That still seems a little racy
[16:17] <cjwatson> [note: check that that copy_exec syntax actually works, in lucid as well as in more current releases]
[16:17] <smb> cjwatson, Maybe you would see more in dpkg.log. I updated the bug report with those
[16:17] <cjwatson> maintainer scripts are not going to race with commands inside the update-initramfs run
[16:18] <ebroder> Oh, I see. Yeah, that's fine
[16:18] <cjwatson> smb: grep 'initramfs.*all' /var/lib/dpkg/info/*
[16:19] <apw> cjwatson, the message the users are reporting at boot which is a udev.preinst message ... which seems very odd during boot
[16:19] <cjwatson> BTW, I think it's unlikely that this is a new bug or a regression
[16:19] <cjwatson> the probability is that you got unlucky with an existing latent bug
[16:19] <lamont> dholbach: I'll upload a new bind9 today
[16:19] <DktrKranz> could someone approve nomination for maverick in bug #642071 ? TIA
[16:19] <cjwatson> apw: that's because the temporary /sbin/udevadm wrapper got copied into the initramfs
[16:19] <cjwatson> apw: read udev.preinst
[16:20] <dholbach> lamont, sweet - thanks
[16:20] <apw> cjwatson, ahh now that makes sense
[16:20] <smb> cjwatson, http://pastebin.ubuntu.com/530770/
[16:20] <cjwatson> those are all false positives
[16:20] <cjwatson> so I don't understand why multiple initramfses were updated for smb, but aside from that I understand the problem completely
[16:22] <smb> Yes I think I remembered to have seen the issue a while before.
[16:22] <smb> Then diwic got hit by it too and today me
[16:23] <smb> I just was a bit quick in regenerating the ramdisks, I guess
[16:26] <cjwatson> should it remain assigned to sconklin, since it isn't a kernel bug?
[16:29] <smb> No I think it should get reassiged. probably also to a different package
[16:30] <smb> uh, actally it isnt
[16:30] <smb> never mind then
[16:30] <cjwatson> I already reassigned it to udev
[16:30] <smb> but I think sconklin will be more than happy when he isn't assigned to it
[16:32] <cjwatson> assign it to me then
[16:32] <smb> done
[16:34] <apw> cjwatson, is plymouth special?  that was also updated 3 days back
[16:34] <apw> (special in the sense it it triggers all initramfs's rebuilt)
[16:49] <cjwatson> apw: not as far as I know
[16:49] <cjwatson> it triggers the current initramfs, like most packages that ship initramfs components
[16:50] <cjwatson> the only package on my system that rebuilds all initramfses is bootchart
[16:50] <cjwatson> of course, upgrading a kernel package will rebuild its own initramfs
[16:58] <pitti> cjwatson: ah, nice catch, want me to take a look?
[16:58] <pitti> oh, you're already on it?
[17:06] <manjo> superm1, ping
[17:27] <cjwatson> pitti: yeah, have patch, just need a moment to test
[17:27] <pitti> cjwatson: ah, me too..
[17:27] <pitti> cjwatson: I added a test case to the bug
[17:28] <cjwatson> pitti: if you want to take over, I don't mind - http://paste.ubuntu.com/530793/ is my working tree
[17:28] <pitti> cjwatson: I have almost the same patch, except that I used -x
[17:28] <pitti> cjwatson: I tested that in a VM
[17:29] <pitti> cjwatson: sorry for the duplicate work, should've waited, I guess
[17:29] <cjwatson> that's ok, if you've tested you should probably keep going
[17:29] <cjwatson> I've been thoroughly distracted by hacking on plymouth
[17:30] <pitti> ok
[17:36] <RoAkSoAx> kirkland: still around?
[17:49] <pitti> cjwatson: ok, uploaded to lucid/maverick/natty; needs SRU review now
[17:52] <pitti> cjwatson: I also have a gnome-settings-daemon in the maverick queue which OEM is urging about, if you have a minute for that
[17:53] <superm1> manjo, whats up?
[17:54]  * pitti waves good night
[17:54] <manjo> pitti, don't bite the bug
[17:55] <mterry> james_w, OK, I have a vala backend done, except the hard part of the build_depends :)  Is it worth proposing for merging yet?  It is autoconf (only) based right now, and some of the autoconf bits are sharable with other autoconf-based backends.  Is there a mechanism for sharing that logic yet?
[17:56] <james_w> mterry, not yet, other than normal code sharing mechanisms
[17:57] <james_w> mterry, I have no problem with merging something which doesn't do the whole job
[17:58] <cjwatson> pitti: g-s-d done
[17:58] <mterry> james_w, https://code.launchpad.net/~mterry/pkgme/vala/+merge/40746
[17:59] <james_w> sweet
[18:02] <cjwatson> pitti: heh, exactly the same udev test case I would have proposed
[18:03] <cjwatson> pitti: udev accepted too
[18:04] <Eeyore-Jr> hi.  i'm looking at a gpsbabel-gui ppa and it's requiring dependencies for maverick that are not there
[18:05] <james_w> mterry, looks great at first glance. I'll go over it and merge later, thanks.
[18:05] <Eeyore-Jr> https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/gpsbabel/maverick
[18:05] <mterry> james_w, sure!
[18:05] <james_w> mterry, we should think of ways to make an autotools backend using the same code
[18:05] <mterry> james_w, yeah, some of that code is tricky, and very little (so far) of the vala backend is actually vala-specific
[18:06] <mterry> would be nice to reduce code for writing new backends
[18:08] <mterry> james_w, maybe some way to declare that you subclass a backend, and then a way of calling parent backend's version.  And fall-through to parent if child doesn't declare?  Else, a simpler way may just be to ship autoconf scripts in /usr/share/pkgme/autoconf that backends can call
[18:08] <mterry> maybe the latter is better in case a backend wants to support multiple build systems...
[19:04] <mathiaz> jdstrand: hi!
[19:05] <jdstrand> hey mathiaz :)
[19:05] <mathiaz> jdstrand: I'm merging openldap from debian and I'm wondering whether /etc/apparmor.d/force-complain is required to be shipped by packages
[19:05] <mathiaz> jdstrand: IIUC this was needed for supporting upgrades from pre-feisty
[19:06] <jdstrand> mathiaz: if the upgrade logic to force complain is not in there, no. you should still clean up /etc/apparmor.d/force-complain/usr.sbin.slapd and /etc/apparmor.d/disable/usr.sbin.slapd though (to be friendly)
[19:06] <jdstrand> mathiaz: well, more than friendly, you don't want to leave a dangling symlink on purge
[19:07] <jdstrand> mathiaz: I thought it used dh_apparmor these days?
[19:07] <mathiaz> jdstrand: yes it doesn
[19:07] <mathiaz> jdstrand: yes it *does*
[20:01] <dannf> what's the SRU versioning scheme? specifically, if there were an update to a 2.52-1 version of a package, what would it be - 2.52-1ubuntu1?
[20:02] <micahg> dannf: depends, usually 2.52-1ubuntu0.1
[20:04]  * dannf is trying to find a version in between - 2.52-1ubuntu0.1~foo1 (or 2.52-1ubuntu~foo1 maybe)
[20:04] <micahg> dannf: which package?
[20:04] <dannf> micahg: dnsmasq
[20:04] <micahg> dannf: the version I gave is correct in this case
[20:05] <dannf> right - i'm trying to do a private version that would upgrade to an SRU version if it occurred
[20:05] <micahg> dannf: then 2.52-1ubuntu0.1~ppa1?
[20:06] <dannf> micahg: yeah, that works - thx
[20:30] <mathiaz> jdstrand: hi - should the ufw profiles be sent to debian as well?
[20:31] <mathiaz> jdstrand: (openldap has a ufw profile)
[20:31] <jdstrand> mathiaz: sure. ufw is in Debian
[20:32] <ebroder> dannf: Daviey asked about a dnsmasq SRU in #ubuntu-motu - do you know if you're looking at the same bug? I was planning to sponsor it but if there's more than one SRU, it would be good to coalesce them
[20:32] <mathiaz> jdstrand: however apparmor is not - right?
[20:32] <jdstrand> mathiaz: not yet no
[20:32] <Daviey> o/
[20:48] <m4n1sh> pitti: Martin, will natty stick with libnotify 0.5 or will update to 0.7 in few months when it comes out? (AFAIK it's not out)
[20:57] <RoAkSoAx> kirkland: proposed a branch for merging into powernap, however i don't really need it to be merged just yet, but I'd like you to review it when you have the time.
[21:00] <jdstrand> wendar: ping re ARB security notes
[21:07] <kirkland> RoAkSoAx: cool, will do
[21:07] <kirkland> RoAkSoAx: not today, but maybe sunday
[21:08] <RoAkSoAx> kirkland: no prob. :) It don't really need an immediate review so whenever you can is fine ;)
[21:59] <ScottK> barry: python-lzma fails to build on Natty in what I suspect is some python2.7 specific way.
[22:52] <ebroder> Does unity's window maximization not work on amd64?
[22:53] <rmrfslash> can someone here help me disable nouveau once-and-for-all?
[22:54] <rmrfslash> little guy is persistent
[22:55] <rmrfslash> sudo apt-get remove --purge xserver-xorg-video-nouveau
[22:55] <rmrfslash> ?
[22:56] <rmrfslash> I've tried a few iterations to try and get rid of this thing... always shows up in lsmod
[22:57] <ebroder> rmrfslash: This isn't the right channel for support issues. Please ask for help in #ubuntu
[22:57] <rmrfslash> thx
[23:12] <wendar> jstrand: pong? (from a couple hours ago)
[23:12] <wendar> jdstrand, that is ^
[23:12] <jdstrand> wendar: hey, did you get me message yesterday?
[23:13] <jdstrand> s/me/my/
[23:13] <jdstrand> wendar: (on irc)
[23:14] <jdstrand> wendar: well, I'll just ask again. I had said that the security team could come up with some recommendations for ARB and add it to the wiki
[23:14] <jdstrand> wendar: (that was at UDS)
[23:14] <jdstrand> wendar: where is the right place to add that?
[23:19] <wendar> jdstrand: how about a new page https://wiki.ubuntu.com/PostReleaseApps/SecurityChecklist ?
[23:20] <jdstrand> wendar: sounds good. I'll add it sometime next week (about to go eow)
[23:20] <jdstrand> wendar: thanks
[23:20] <wendar> jdstrand: awesome, thanks!


[11:16] <xnox> infinity: does debian-installer need a rebuild in raring-proposed for the #1196946 ? since udeb list shows older libdebian-installer and from the affected users install.log an older kernel is being booted.
[17:13] <infinity> xnox: Might need more than just a rebuild.  I'm not sure how much they still care about raring, but I'll ask Rob when I bump into him today.
[17:13] <infinity> xnox: I certainly had to fix more than just libdi for midway enablement on saucy.
[17:19] <xnox> infinity: ack. please chat to him, i simply bump into unverified sru with a vague failure report.
[17:22] <infinity> xnox: It'll need at least a flash-kernel upload, not sure what else.  I'd have to track back through my saucy enablement.  But, yeah, if Calxeda doesn't actually care about raring (and I don't see why they would now), we might just be able to dump it from proposed.


[15:54] <penguin42> anyone know anything about cameras?  I'm trying to sell my dads cameras and dont have too much of a clue about expected prices
[15:56] <zxmpi> if it were me i'd make a list and search for each of the items on ebay to get a rough idea of what they are going for
[15:57] <penguin42> I'm finding that a very unreliable way of pricing stuff
[15:57] <penguin42> for a start, people ask silly prices on ebay, secondly ebay wrongly record the sold value if it was bought with an 'offer'
[15:58] <zxmpi> that doesn't help, isn't there a blue book for what a car of a given age is worth, is there such a thing or place for cameras?
[15:58]  * penguin42 points out the bit about me not having much clue about cameras
[15:59] <zxmpi> https://www.usedprice.com/items/camera/
[16:04] <zxmpi> lots of guides online but they are all of a worth whatever someone is willing to pay for it view
[18:05] <daftykins> penguin42: could be worth pal-ing up with a local photography shop if there's a trustworthy one
[18:44] <penguin42> hmmmm interesting idea
[18:44] <daftykins> a wealthy client of mine shifted his that way, as cameras have always been his vice
[18:45] <daftykins> although Guernsey Photographics is now long gone
[21:37] <zxmpi> market for optical and even digital cameras is far smaller market than it used to be
[23:08] <penguin42> nod
[23:08] <penguin42> like the valve rigs and 60ft tower I also need to get rid of