[00:01] <nxvl> kirkland: thank you
[00:06] <nxvl> sponsoring stuff is fun
[00:06] <nxvl> :D
[00:08] <directhex> so is guitar hero
[00:10] <RAOF> Hm.  update-grub seems to have eaten my grub.cfg.  Yay.
[00:12] <nxvl> to sponsor a sync
[00:12] <nxvl> i need to ACK it and suscribe ~ubuntu-archive, don't i?
[00:12] <RAOF> Yup.
[00:12] <Laney> and set it to confirmed
[00:13] <Laney> and unsubscribe u-u-s!
[00:13] <nxvl> Laney: that's the first thing i did
[00:13] <RAOF> Always with the unsubscribing, yes.
[00:13] <nxvl> :D
[00:21] <RAOF> !!!
[00:21] <RAOF> Where did /boot go?
[00:21] <directhex> sorry, i was hungry
[00:22] <RAOF> This is probably why grub-probe is somewhat confused.
[00:25] <RAOF> You know, I should probably merge grub-pc if I'm gonna use it; it seems debian's newer snapshot is full of "please don't die" bugfixes.
[00:29] <RAOF> Oh.  I think I know what ate my /boot.  Stupid parallel fsck!
[00:29]  * wgrant spits out /boot's bones.
[00:30] <RAOF> Nothing says "I love you" more than having a mount point not exist every now and then.
[00:42] <james_w> I have "intltool-update.in -> /usr/share/intltool/intltool-update.in" in a couple of packages, which fail to build in Intrepid as that file is not available, even in the intltool package, has anyone else seen this?
[00:43] <james_w> anyone know where they went?
[00:46] <RAOF> james_w: I believe that's a change in the new intltool.
[00:47] <RAOF> james_w: I hit that packaging Do; I believe intltool would now like to be run as a part of ./configure
[00:50] <directhex> how nice for it
[00:50] <directhex> isn't it a little bit late in the day for intrepid for intltool to break everyones' packages?
[00:51] <james_w> RAOF: thanks, do you know what I need to change?
[00:52] <james_w> it's ./configure where it bombs out
[00:52] <emgent> kirkland: your ecrypfs r0cks. i fixed my system problem
[00:52] <emgent> now work very nice.
[00:52] <kirkland> emgent: thanks, dude.  what was your problem?
[00:52] <RAOF> james_w: From memory, with Do I acually added the intltools stuff to configure.ac and re-autogen'd
[00:54] <emgent> kirkland: in the first step i dont put same password in login and ecryptfs, after that more problem (you know). i removed all an i start new clean setup. now work fine.
[00:54] <kirkland> emgent: very good...  i wonder if i should improve the documentation/prompts somehow?
[00:55] <kirkland> i wish there were an easy way for me to validate that password
[00:55] <emgent> kirkland: documentation is very good, you wrote (add same login system password), It was my mistake
[00:55] <kirkland> emgent: okay, thanks
[00:55] <emgent> kirkland: no thanks to you! :)
[00:57] <emgent> kirkland: do you have a launchpad branch for ecryptfs ?
[00:58] <kirkland> emgent: no, it's managed in git.kernel.org
[00:58] <emgent> i'm asking about tool
[00:58] <emgent> ecryptfs-setup-private ecc..
[00:59] <kirkland> emgent: i have passed ALL of the code I've written to the upstream ecryptfs-utils project
[00:59] <emgent> okkay great! :)
[00:59] <kirkland> emgent: http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=summary
[01:00] <kirkland> emgent: i send my patches to the mailing list, and Mike applies them
[01:02] <emgent> http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=blob;f=src/utils/ecryptfs-setup-private;h=1aa6bf56ca5f88a41be8bd68903166b87c63f337;hb=HEAD
[01:02] <emgent> yeah nice work, thanks kirkland !
[01:03] <kirkland> emgent: that's it :-)
[01:03] <kirkland> emgent: i think i'm going to add a check, if you've previously run ecryptfs-setup-private, and if so, error out, and tell you that you have to use a "-f" option to force it
[01:04] <emgent> nice i can remove flashusb for .ssh .gnupg .mozilla-thunderbird and .mozilla
[01:04] <kirkland> emgent: I also want to add a "--undo" option too
[01:04] <emgent> now i can use this stuff.
[01:04] <kirkland> emgent: ;-)
[01:04] <emgent> very good :)
[01:05] <emgent> argh we are in -motu.. i think that we can switch to -server
[01:05] <emgent> we are OT.
[05:33] <emgent> moin
[06:09] <dholbach> good morning
[06:16] <stefanlsd> morning
[06:52] <stefanlsd> nhandler: just worked thru your lesson. thanks. was great!   (you explained the .patch files well. was missing that...)
[07:04] <emgent> moin
[07:04] <bhavi_> emgent, howdy mate
[07:05] <emgent> bhavi_: moin
[07:11] <tuxmaniac> heya gang
[07:41] <Hew> can someone from u-u-s look at the prboom sync request bug 231811
[07:59] <Laney> Hew: You should retitle the bug
[08:00] <Hew> Laney: Thanks, will do
[08:00] <Laney> Please sync <package> <version> (<Ubuntu component>) from Debian <release> (<Debian component>)
[08:06] <Hew> done
[08:08] <Hew> I've gotta head off now so I'll check on it later. Thanks again.
[12:47] <coolbhavi> hello I m getting this error please help http://pastebin.com/f25de910
[12:58] <effie_jayx> coolbhavi, ./dhelp-0.6.12ubuntu1/debian/control at line 27: block lacks a package field <----
[12:58] <effie_jayx> did you change debian/control and erased the package field?
[12:58] <coolbhavi> effie_jayx, no
[12:59] <effie_jayx> coolbhavi,  did you change anything in debian control?
[12:59] <persia> Looks to me like the upstream makefile doesn't have a clean rule.
[13:00] <ogra> that shouldnt really matter, can you pastebin your debian/control as well ?
[13:00] <coolbhavi> effie_jayx, yes a min please I ll paste it
[13:01] <coolbhavi> effie_jayx,  http://pastebin.com/d27eb5a04 <---- control file
[13:02] <persia> coolbhavi: Remove the blank line 14.
[13:02]  * persia thinks we'll see a different error now
[13:03] <coolbhavi> a min please
[13:05] <sebner> persia: he hasn't answered yet (almanah) but on debian mentors is a new revision with my manpage in it :\
[13:06] <persia> sebner: Progress is being made.
[13:06] <coolbhavi> persia, you are a magician it worked!
[13:07] <sebner> persia: sure but this isn't the collaboration I want to see ;)
[13:07] <persia> yeah :/
[13:11] <sebner> persia: btw, nearly forgot to ask. any progress with qmasters?
[13:11] <sebner> uqm ^^
[13:12] <persia> sebner: Not at all.  Thanks for the poke.  I'll push the merge into Ubuntu, as Debian is frozen.
[13:12] <sebner> persia: kk :)
[13:13] <sebner> persia: wait, It needs an update to -8ubuntu1
[13:14] <persia> sebner: Indeed it does.  Do you want to do that?
[13:14] <sebner> persia: sure ;)
[13:14] <sebner> persia: urgent?
[13:28] <sebner> persia: updated :), I'm off for now. Bad thunderstorm /here
[13:28] <persia> sebner: Thanks.  I've been organising my review queue today, and expect to push it.
[13:41] <mok0> Shouldn't intrepid be available to hardy's debootstrap?
[13:42] <mok0> ... at least in backports
[13:45] <jpds> mok0: It is as of 1.0.9~hardy1.
[13:45] <mok0> jpds: huh? I have 1.0.8
[13:46] <mok0> jpds: ah, I thought I had backports enabled, bummer!
[13:46] <jpds> mok0: https://edge.launchpad.net/ubuntu/hardy/+source/debootstrap/1.0.9~hardy1
[13:46] <mok0> thx
[13:56] <ScottK> mok0: I saw you were trying to ping me yesterday.
[13:56] <mok0> ScottK: yes, thanks for looking at gamgi
[13:56] <mok0> ScottK: but please see my comment
[13:57] <ScottK> mok0: Link please?
[13:57] <mok0> ScottK: http://revu.ubuntuwire.com/details.py?package=gamgi
[13:58] <ScottK> Looking
[13:58] <elkbuntu> right. is there any known bug where booting into a red flashing screen will cause your grub to turn into pastebin.ca/1172892 ?
[13:59] <elkbuntu> yes, it is the right pastebin
[13:59] <ScottK> mok0: I still thing it needs a man page.  I think every executable in /usr/bin is supposed to have one.
[13:59] <mok0> ScottK: But the user should not know about this
[14:00] <ScottK> mok0: What does Debian Policy say?
[14:00] <mok0> ScottK: the user will execute the program "gamgi"
[14:00] <ScottK> Right.  Once you read policy, the answer will be a short man page that says don't excute this.
[14:00] <ScottK> I could be wrong.
[14:00] <mok0> ScottK: It says that when a program needs environmental variables, a wrapper script should set them up
[14:01] <mok0> ScottK: So, for the convenience of the user, the wrapper script is called "gamgi" and the binary is called "gamgi.real"
[14:02] <ScottK> Right, what about the Policy about man pages?
[14:02] <mok0> ScottK: let me check that
[14:03] <ScottK> Should be policy 12.1
[14:04] <persia> mok0: Note that you can probably get away with a single manpage for both, with a symlink.
[14:04] <mok0> I don't see anything concerning wrapper scritps
[14:05] <mok0> The environment thing is in 9.9
[14:05] <mok0> persia: allright, but I think it's silly
[14:05] <persia> mok0: Well, some user might get clever :)
[14:07] <mok0> persia: heh. Well I see that there are no man pages for "uncompress.real"  or "ldconfig.real"
[14:07] <persia> mok0: Sure: not every package is policy compliant.
[14:08] <mok0> persia: You are right
[14:08] <mok0> ... and there _is_ a manpage for uncompress.real, so that settles it
[14:16] <mok0> persia: otoh, using a link to the manpage is not good, because people should not run the ".real" program, so the manpage should say that
[14:17] <persia> mok0: No reason the manpage for gamgi can't mention the existence of gamgi.real, and that one should use /usr/bin/gamgi
[14:17] <persia> alternately, shove it in /usr/lib/gamgi/gamgi.real
[14:17] <mok0> persia: yes... does that change the requirement for a manpage?
[14:18] <persia> It does: policy requires a manpage for everything in /bin, /sbin, /usr/bin, /usr/sbin, and /usr/games
[14:19] <mok0> persia, I don't see that. I only see "Each program, utility, and function should have an associated manual page included in the same package"
[14:20] <persia> Hmm..  I guess it depends on one's interpretation of policy.  I always felt that everything in the path, and everything not in the path that users were expected to execute should have a manpage.  I may be mistaken.
[14:20] <mok0> What do you think, ScottK?
[14:21] <mok0> persia: I agree that putting the exe file in /usr/lib/... is better
[14:22] <persia> I don't think it's better, it's just an option.
[14:22] <ScottK> mok0: I believe that what persia is giving you is the traditional interpretation.  This policy requirement is mechanized in Lintian, so for a real anwer, I'd suggest consulting the Lintian source.
[14:22] <mok0> ScottK: good idea
[14:23] <mok0> persia: It is better, because it will prevent users from running the binary without environmental variables set up (unless they are clever)
[14:24] <persia> mok0: I guess that makes some sense.
[14:25] <mok0> ScottK, persia, thanks for the input! I will go ahead and fix the package
[15:09] <emgent> nxvl: o/
[15:09] <nxvl> emgent: hi!
[15:17] <mok0> Hmm, just created a new sbuilder, but it is missing apt???
[15:17] <mok0> intrepid sbuilder, that is
[15:18] <emgent> argh another issue on drupal..
[15:22] <mok0> emgent: what's up with drupal?
[15:24] <emgent> more security issue
[15:24] <mok0> uhuh
[15:24] <emgent> committed intrepid now, i'm working to test backport fix for hardy.
[15:29] <mok0> emgent, what version of drupal is this?
[15:29] <emgent> 5.X and 6.X
[15:29] <mok0> emgent: ah, finally, version 6! :-)
[15:29] <emgent> 6.X it`snt in intrepid yet
[15:30] <mok0> emgent: will be I hope
[15:30] <emgent> i'm waiting for bump it in Ubuntu
[15:30] <Hobbsee> emgent: thanks for the warning.  upgraded drupal, and actually subscribed to the rss feed now!
[15:31] <emgent> mok0: dont know.. i will see first to 28 August
[15:31] <emgent> Hobbsee: hehe np, the real problem is that all LoCo Team use it, but not with ubuntu repo..
[15:31] <emgent> manual installation.. :-|
[15:31] <Hobbsee> mine's manual too
[15:31] <Hobbsee> it took about 2 minutes.
[15:32] <emgent> and not all LoCo upgrade it..
[15:32] <emgent> (of apply the fix)
[15:32] <Hobbsee> true
[15:32] <emgent> and box dont run mod_security for try to exclude this attack
[15:33] <mok0> Ydrk, getting a compile error in intrepid (but not earlier):  'struct hostent' has no member named 'h_addr'
[15:34] <mok0> Ydrk, it's now wrapped in ifdefs
[15:35] <emgent> i think that we should write a census for CMS used by loco.. and try to send auto-notice when vuln is out.
[15:35] <emgent> (with attached fix)
[15:37] <emgent> anyway i will talk about it in the next security team meeting
[15:44] <nxvl> with wich command is that i saw that packages depend on $package?
[15:49] <mok0> apt-rdepends
[15:52] <persia> I tend to use apt-cache rdepends, as apt-rdepends is a little funny (or at least I can't get it to use --follow right)
[15:54] <nxvl> persia: yeah, i'm using rdepends, i have just tried the 2 of them and apt-cache is more what i was looking for
[15:54] <nxvl> thank you!
[15:54]  * nxvl HUGS mok0 and persia 
[15:55] <mok0> persia: did you file a bug report? :-D
[15:55] <emgent> heya persia :)
[16:00] <persia> mok0: Not yet: I've yet to determine it's not me (I keep getting distracted by something else when using apt-rdepends)
[16:01] <persia> That said, the manpage says it doesn't quite emulate apt-cache, so except where one needs recursion, I think apt-cache is a better tool.
[16:33] <nxvl> bobbo: around?
[16:50] <vorian> dholbach: ping :)
[16:52] <vorian> nxvl: congrats man!
[16:52] <bobbo> nxvl: hey
[16:53] <nxvl> vorian: thank you
[16:53] <nxvl> bobbo: nevermind i just uploaded it
[16:53] <bobbo> nxvl: ok :)
[17:31] <cherva> should I register a blueprint for Intrepid on launchpad if I'm not going to assign myself to it ? if they find it as a stupid idea they will remove it right ?
[17:34] <persia> cherva: There's no good way to remove blueprints, and blueprints for intrepid were discussed in May, so the timing is a little awkward.
[17:34] <persia> The next round of blueprinting will be for intrepid+1, for discussion in December at UDS.
[17:35] <cherva> persia: so it is too late to proppose to make nautilus edit id3 tags of mp3 via properties->sound tab ?
[17:36] <persia> cherva: There's only two weeks until FeatureFreeze, and nautius tends to follow upstream very closely.  You'd do best to either work to get that into GNOME or put it on brainstorm.
[17:37] <cherva> persia: it is on brainstorm
[17:39] <persia> cherva: OK.  From brainstorm, the next step is to organise the implementation, and get some PoC stuff together.  Often a wiki page is used for this, and written in Specification format.  Has that been done?
[17:42] <cherva> persia: http://brainstorm.ubuntu.com/idea/3888/ there is no wiki, strage this idea is from  8 Mar '08 where can I see the discussed blueprints for the ibex?
[17:43] <persia> cherva: I don't know that they are organised in their entirety anywhere.  Most of the teams have individual listings of blueprints interesting to them.
[17:43] <cherva> persia: I guess I'll wait for the interpid+1 discussion :)
[17:44] <superm1> persia, do you have a good methodology for how you are tracking down the extras that get added in in the studio stuff?  _MMA_ showed me some 300 megs that got added
[17:46] <persia> superm1: Not really.  I've been fiddling with `apt-rdepends --show=Depends,Recommends`.  I've yet to figure out how --follow works.  Also: https://lists.ubuntu.com/archives/ubuntu-studio-devel/2008-August/000822.html
[17:46] <persia> cherva: That or get inolved in implementing it yourself: generally those specs that are almost there are more likely to get included than those that are more a description of something someone else should do.
[17:47] <superm1> persia, ah okay fairly similar to how i started to look at some of the mythbuntu stuff that is depending on too much.
[17:48] <superm1> our live cd image is some 200 megs bigger (That includes compression.....)
[17:48] <superm1> and from what i've seen so far, we dont want any of it
[17:48] <cherva> persia: I don't think my code will be good for implementing it ANYWHERE :)
[17:49] <persia> Well, there's some stuff we want: I just added libpam-ck-connector to -desktop today.  On the other hand, we were pulling all of KDE, which is a bit odd for a GNOME-based desktop.
[17:49] <persia> cherva: Proof-of-concept.  Then present that to known nautilus hackers, and watch it change into real, useful, code.
[17:51] <cherva> persia: I don't know gtk :) just a little qt4 I'll just leave it for now
[17:51] <persia> cherva: OK.  If you really want it, maybe you can find someone else who both knows GTK and also wants it?
[17:52] <cherva> no I just wanted to ask what will happen if i register a blueprint and I know now thanks :)
[17:53] <goshawk> h
[17:53] <goshawk> hi
[17:53] <goshawk> if someone have free time please see :http://revu.ubuntuwire.com/details.py?package=dsss
[17:57] <persia> goshawk: What is dsss?
[17:58] <goshawk> persia: it's like python eggs
[17:58] <goshawk> but for D programming language
[17:58] <goshawk> dsss net install application
[17:58] <goshawk> downloads compiles and installs the application
[17:59] <persia> Ah.  Considering how much time we spend patching that out of python apps, I'm unsure how much we want it for other programming languages
[17:59] <goshawk> you're right
[17:59] <goshawk> but sometimes it could be good
[17:59] <goshawk> expecially for not packaged application
[17:59] <goshawk> and, now, in the D world
[18:00] <persia> Well, I don't think it's good for not-packaged applications, as they ought be packaged.  It might make things more convenient for D developers though.
[18:00] <goshawk> they are a lot (that are not packaged i mean)
[18:00] <persia> (but not much more convenient for D developers who wanted to have their applications in Ubuntu)
[18:00] <goshawk> persia: it's also the "make" equivalent for D applications
[18:00] <persia> Oughtn't they be packaged then, if they are useful?
[18:01] <persia> Oh.  If it's "make" equivalent, than we do need it.
[18:01] <persia> I don't suppose you've packaged it in a way that tries to pull libraries from the repositories, rather than the net, have you?
[18:01] <goshawk> persia: it's mainly a make equivalent
[18:01] <goshawk> the "net" module get sources from net and compile it
[18:01] <goshawk> for example
[18:01] <goshawk> dsss build
[18:01] <goshawk> in a D source tree
[18:02] <goshawk> compiles and generate executables
[18:02] <goshawk> persia: it's a coded from scratch application
[18:02] <goshawk> it uses just C libs
[18:02] <goshawk> and D ones
[18:02] <goshawk> (using gdc the gnu d compiler that is in the ubuntu repo)
[18:03] <goshawk> it does not use the net to build
[18:03] <goshawk> itself
[18:03] <goshawk> all the libraries are in the repo
[18:04] <persia> Right.  I'm just considering the future popularity of this for D developers, and think that if you haven't, you might want to see if you can stub out the net module to pull libraries from the repositories, pehaps if a certain siwtch is provided.  That then makes it easy to package D code that build-depends on dsss
[18:05] <goshawk> you can't use the net module while using dsss like "make"
[18:05] <goshawk> except you do dirty things in makefiles
[18:05] <persia> goshawk: OK.  Now I'm confused.
[18:05] <goshawk> persia: i'll explain better
[18:05] <goshawk> D applications have a makefile called dsss.conf
[18:06] <goshawk> it's readed by dsss
[18:06] <goshawk> to build sources
[18:06] <goshawk> dsss has a net module too
[18:06] <goshawk> to get and compile sources
[18:06] <goshawk> but the net module is not accessible by dsss.conf
[18:07] <goshawk> it has no sense for a dsss.conf to get
[18:07] <goshawk> the net module
[18:07] <goshawk> since
[18:07] <goshawk> the net module just get sources from the net
[18:07] <goshawk> and open them
[18:07] <goshawk> then it goes in the source dir and do "dsss build"
[18:07] <goshawk> and dsss install
[18:08] <goshawk> is it now more easy to understand?
[18:09] <persia> OK.  So there's no easy way for a developer to configure dsss to pull build-dependencies from the net as part of a call to dsss build ?
[18:10] <goshawk> no, dsss does not solve dependencies, it's like make
[18:10] <goshawk> dsss net module is able to
[18:11] <goshawk> but you can't call it from dsss.conf
[18:11] <persia> OK, so `dsss build` can't pull from the net?
[18:11] <goshawk> yep right
[18:11] <goshawk> dsss build just builds
[18:11] <goshawk> according to specifications in dsss.conf
[18:12] <persia> OK.  Added to my list of packages to review.
[18:12] <goshawk> :) thanks
[18:16] <sebner> persia: after uqm of course :P
[18:17] <persia> sebner: Indeed.  It's a FIFO queue.
[18:17] <goshawk> D:
[18:17] <goshawk> :D
[18:17] <sebner> persia: nice to hear =)
[19:45] <devfil> Someone can take a look at http://revu.ubuntuwire.com/details.py?package=ircp-tray ?
[20:11] <emgent> evening
[20:41] <ethana2> on ubuntu 8.10 alpha 4, the version of miro that ships is 1.2.3, current from miro apt is 1.2.6
[20:41]  * ethana2 checks code freeze date
[20:43] <ethana2> ok, we haven't even hit feature freeze
[20:43] <ethana2> http://www.getmiro.com/download/
[20:44] <devfil> ethana2: can you open a bug (if it doesn't exists yet)?
[20:44] <ethana2> launchpad?
[20:45] <devfil> ethana2: yes
[20:46] <nellery> ethana2, this will help https://help.ubuntu.com/community/ReportingBugs
[20:46] <ethana2> ok
[20:46] <ethana2> well i report bugs all the time
[20:46] <ethana2> a few others this week-- but how do you file a 'package needs to be updated' bug?
[20:48] <nellery> Have a look at the many examples https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=upgrade
[20:48] <nellery> ethana2, make sure you add the tag 'upgrade'
[20:48] <ethana2> got it
[20:51] <ethana2> ok, how to i add tags?
[20:51] <ethana2> is that after submitting?
[20:54] <ethana2> ok  yes
[20:55] <ethana2> https://bugs.launchpad.net/ubuntu/+source/miro/+bug/258401
[21:08] <ethana2> oh hey, while i'm here, i'd like to see this maybe get resolved in a timely manner
[21:08] <ethana2> https://bugs.launchpad.net/bugs/258058
[21:08] <cody-somerville> ...
[21:08] <ethana2> particularly because not only is this bug extremely annoying to me, but the solution should be somewhat simple
[21:09] <cody-somerville> ethana2, I look forward to receiving your patch then
[21:09] <ethana2> i don't know if i have the ability to help fix this bug myself
[21:09] <ethana2> ok, how do i do this?
[21:09] <cody-somerville> Well, you fix it
[21:09] <cody-somerville> then you compare the the old and the fixed version
[21:09] <ethana2> right, i have the .deb files for all the right drivers
[21:10] <ethana2> is there a driver index file somewhere i can insert this stuff in?
[21:10] <ethana2> anyone familiar with the printing subsystem want to help me out?
[21:11] <ethana2> i'm expecting the fix to involve maybe a few lines of text, but i don't know where the file is that the text needs to be added to
[21:12] <ethana2> ok here, how do i found the launchpad maintainer of a given project?
[21:12] <cody-somerville> Well, you could determine what binary is launched when you plug in your printer
[21:12] <ethana2> once i know that i can just ask him
[21:12] <cody-somerville> Then determine which package that belongs to
[21:12] <ethana2> i've got that already
[21:12] <ethana2> i think
[21:12] <ethana2> alright, i should be absolutely sure i guess
[21:13] <cody-somerville> "apt-get source <package name>" to get the source code
[21:13] <ethana2> how do i see what's being launched as i plug stuff in?
[21:13] <ethana2> ah yeah, when i apt-get source, does it just dump it wherever i'm at like svn, or does it put it in some source directory?
[21:14] <cody-somerville> It will download three files to you current working directory
[21:14] <cody-somerville> and extract the source into a sub directory
[21:14] <ethana2> ah, ok
[21:16] <ethana2> ok, got it, now to figure out where it stores the printer/driver index
[21:20]  * ethana2 is asking on ##cups
[21:33] <ethana2> Ok, this is confusing--what I may do is get a livecd of the latest suse and fedora and add those to the bug report on launchpad if they're affected
[21:37] <ethana2> well, thanks for the help-- time to see how the intrepid radeon driver performs in tremulous