=== Kopfgeldjaeger is now known as Kopfi|offline
=== superm1 is now known as superm1|away
[00:24] <slangasek> cody-somerville: from where I sit, I'm not sure how an ongoing report like that would be useful to us; I'm sure it would be useful to look at if and when we're attempting to harmonize the two builds?
=== asac_ is now known as asac
=== superm1|away is now known as superm1
[03:52]  * slangasek ponders the latest Hug Day announcement.  "This week's target is TARGET"?
[03:53] <ion_> They must be using the $TEMPLATING_ENGINE templating engine.
[03:53] <slangasek> That %unpleasant verb%
[03:57] <LaserJock> slangasek: it looked to me like TARGET=casper, perhaps it was a bit hard to see
[03:58] <slangasek> hum, ok
[03:58] <LaserJock> if you go to the wiki page it says casper
[03:59] <LaserJock> I'm guessing that's the correct one and not the previous one
[04:01] <ScottK> It's a good $TARGET in any case.
[04:01] <ScottK> ;-)
[04:45] <superm1> kirkland, ping
[04:45] <kirkland> superm1: hiya mario, what's up
[04:46] <superm1> hey dustin.  i wanted to ask you about some recommends on mysql-server-5.0
[04:46] <superm1> i noticed it has mailx as a recommend which is pulling in exim4
[04:46] <kirkland> superm1: hmm, interesting, there should be viable alternatives to mailx
[04:47] <superm1> wouldn't something like that be more sensible as a separate task for a mail server?
[04:47] <lifeless> exim4 FTW
[04:47] <kirkland> superm1: i think so...  what does it need it for?
[04:47] <superm1> kirkland, well moreso that i'm sure not everyone who is installing mysql-server-5.0 will want something to be handling mail getting installed too
[04:48] <kirkland> superm1: sorry, i'm way more familiar with postgresql in my own installations.....
[04:48] <superm1> kirkland, well i bring this up because i'm looking at mythbuntu disks which gained about 200 megs by recommends
[04:48] <kirkland> superm1: yikes, that's no good :-/
[04:48] <superm1> and i'm trying to see where that space can be reclaimed, and what happened
[04:48] <superm1> and this is one of them
[04:49] <kirkland> superm1: i can take a look at it tomorrow, if you like
[04:49] <superm1> kirkland, yeah if you can, that'd be great
[04:49] <kirkland> superm1: i'll likely have to chat with zul and mathiaz
[04:49] <kirkland> superm1: they work on mysql quite a bit too....
[04:49] <superm1> kirkland, okay sounds good
[04:54] <kirkland> superm1: would a smaller sql database be an option?
[04:54] <superm1> kirkland, well there is no support in mythtv for anything but mysql at this point
[04:54] <superm1> i wish postgresql was supported
[04:54] <kirkland> superm1: oh, that's too bad...  there are some really trimmed down databases out there
[04:54] <superm1> or even better if it had support for sqlite internally
[04:55] <StevenK> superm1: Postgres support for Myth sounds good to me.
[04:55] <superm1> kirkland, but exim4 & mailx are only contributing about 10 or the 200 meg increase from recommends, so still need to track down what else happened
[04:58] <kirkland> superm1: how bad is Xubuntu over the limit at the moment?
[04:58] <superm1> kirkland, not too sure, cody-somerville ?
[04:59] <kirkland> superm1: and how many of the pluggins ship on the CD?
[04:59] <kirkland> superm1: myth-*
[04:59] <superm1> kirkland, normally all of them do
[04:59] <superm1> they have for the last two releases
[04:59] <kirkland> superm1: i know it's not ideal, but some of those could be left for internet download/installation
[05:00] <kirkland> superm1: do you have any way of gauging which plugins are more popular?  popcon.ubuntu.com perhaps?
[05:00] <superm1> kirkland, well the CDs aren't "oversize" persay yet for mythbuntu, just they have increased in size
[05:00] <kirkland> superm1: personally, i only use MythVideo and MythWeb nowadays....  fwiw....
[05:00] <superm1> i'm afraid this is just a lot of cruft though
[05:00] <kirkland> superm1: ohhhhh, okay
[05:00] <superm1> because the installs got along fine before and never got requests for adding other things in
[05:01] <kirkland> superm1: that's a different story... I thought you were 200M over a 700M iso !
[05:01] <superm1> kirkland, well we have some high res artwork coming around, so its very possible we will go over soon too
[05:01] <ScottK> Personally, I don't think a mail server meets the definition for recommends for a database.
[05:02] <ScottK> I'd drop it to suggests postfix|mail-transport-agent and be done with it.
[05:03] <kirkland> superm1: fwiw, i've been messing with mdadm quite a bit lately...  it has mail-transport-agent as a Recommends, so that mdadm can mail you status information about degraded RAIDs
[05:04] <superm1> kirkland, i'm not sure i agree with that for a recommends there either
[05:04] <superm1> kirkland, but this should be up to your team to decide i suppose :)
[05:05] <superm1> mostly because you still have to configure that mail application to use it, so its not entirely useful until you configure it
[05:05] <superm1> if you are having  to go out of your way to configure it, why is it installed by default
[05:06] <kirkland> superm1: right, i'll dig deeper tomorrow
[05:07] <ScottK> kirkland: I'm not sure it makes sense there either, but I think the case is better for mdadm than for sql.
[05:07] <kirkland> superm1: explicitly needing exim4 doesn't immediately make sense to me, at the moment
[05:10] <kirkland> ScottK: my point is that recommending "mail-transport-agent" is more reasonable than explicitly requiring "mailx"
[05:10] <ScottK> Yes, but it needs to be a specific one|mail-transport-agent.
[05:11] <ScottK> If we're going to touch this stuff, may as well make it postfix|mail-transport-agent all the way around.
[05:12] <kirkland> ScottK: I don't disagree with that
[05:12] <lamont> make it default-mail-transport-agent|mail-transport-agent and have default-mail-transport-agent be a metapackage that Depends: postfix
[05:12] <lamont> then we push all that back upstream to debian
[05:12] <lamont> and they can make it exim4
[05:12] <kirkland> and lamont's suggestion is an excellent one
[05:13] <ScottK> soren has brought it up on debian-devel before and didn't really get anywhere.
[05:13] <kirkland> except for the exim4 bit :-P
[05:13] <ion_> kirkland: :-)
[05:13] <ScottK> It pretty well devolved into a 'which MTA do we want for default' discussion.
[05:13] <kirkland> but lamont's point is a good one...  a metapackage gives us that flexibility
[05:13] <lamont> I'm happy to work with zugschlus on making it all pretty between the two of us
[05:14] <kirkland> okay, i gotta call it a night
[05:14] <lamont> for that matter, it doesn't actually have to be a real package, as long as only one MTA Provides it on each distro. :-)
[05:14] <lamont> OTOH, that way lies madness
[05:15]  * lamont realizes it's way past when he said he was going to bed as well
[05:15] <lamont> g'night
[05:17] <ScottK> Good night lamont who never looks at my scripts.
[05:17] <ScottK> ;-)
[05:18] <lamont> 2.5.4 kinda chewed up all of my brain last night
[05:18] <lamont> very sleep deprived day today
[05:19] <ScottK> Understand.
[05:19] <ScottK> Just poking a little fun.
[05:19] <ScottK> That was certainly more important.
[05:19] <ScottK> lamont: Do we need postfix packages for dapper/feisty/gutsy/hardy?
[05:19] <lamont> esp since I thought the announcement was friday until about 6 hours pre-release last night
[05:20] <lamont> -security already has them, albeit maybe not unembargoed
[05:20] <ScottK> OK.
[05:20]  * lamont uploaded a total of 9 postfix packages between last night (embargoed) and this morning (post-announce to sid/experimental and a sync req)
[05:20] <ScottK> Yahoo.
[05:21] <lamont> including backporting the *&*^_ fix from 2.3 to 2.2 for dapper.  which required src/util/safe_basename.* or such
[05:22] <lamont> and then that seems to have been compilcated by either kees' scripts, or by feisty/gutsy not liking an attribution in changelog when there's only one
[05:22] <ScottK> I wondered about that since I say Upstream didn't do you the favor of a patch for 2.2
[05:22] <lamont> the patch applies cleanly, it just calls a function that isn't in 2.2
[05:22] <lamont> fortunately, src/util is _VERY_ modular and isolationist between files
[05:22] <lamont> src/global less so
[05:23] <ScottK> Kewl.  The best kind of patch.  Applies cleanly, but absolutely fails to work.
[05:23] <lamont> FTBFS
[05:23] <lamont> which is much nicer than builds-and-fails
[05:24] <ScottK> Yeah.
[05:24] <lamont> note that for the bug to be usable by an attacker, there needs to be a root-owned symlink to somewhere useful on the same filesystem as somewhere that postfix will naturally deliver to, in a directory where the attacker has write perms
[05:25] <ScottK> Right.  There's a reason I didn't rush out and roll my own packages with the patch ...
[05:25] <lamont> --> "oh.  we need to fix that." not "ZOMG SKY FALLING"
[05:25] <ScottK> Yes.
[05:25] <lamont> and 2937 is where we all laugh and  point at 1777 /var/mail machine
[05:25] <lamont> s
[05:26] <ScottK> Yeah.  All I had this morning was the opensuse email mentioning it, my phone for a web browser, and I was at the customer site.  I figured better safe the sorry and mailed you.
[05:28] <lamont> heh
[05:32]  * ScottK is off to bed.
[05:33] <emgent> moin
=== thegodfather is now known as fabbione
[06:09] <dholbach> good morning
[06:09] <ion_> iŋ
[06:10] <kirkland> dholbach: howdy :-)  you turned about 5 of my channels "red"
[06:12] <dholbach> hi kirkland! :)
[06:12] <dholbach> kirkland: I'm glad I didn't turn you red :)
[06:12] <kirkland> dholbach: :-P
[06:13]  * Hobbsee turns purple
[06:15]  * ion_ turns röntgen
[06:15]  * Mithrandir shakes the little purple alien.
[06:16] <Hobbsee> eep!
[06:16]  * Hobbsee turns orange
[06:18]  * kirkland turns in for the night
=== jarson is now known as bill-barriere
[06:28] <pitti> Good morning
[06:29] <pitti> tkamppeter: I got your mail, will do
[06:29] <dholbach> hi pitti
[06:31] <ion_> pitti: Did you notice my message?
[06:31] <pitti> ion_: /tmp/ is 403, and I cannot figure out the full URLS (without suffix, .patch, or .dpatch)
[06:31] <pitti> ion_: yep, I was just looking at it
[06:32] <ion_> pitti: The latest message. :-) I put the patches to http://heh.fi/tmp/cups/
[06:32] <pitti> aah
[06:32] <ion_> pitti: Patch 05 probably shouldn’t go in just yet (i’m the only one who has tested that functionality so far), but the ones before it should be okay.
[06:33] <TheMuso> Morning pitti.
[06:33] <pitti> ion_: I usually keep track of where they got sent upstream in the patch header; do you have some STRs etc. for them?
[06:33] <Hobbsee> pitti!
[06:33] <pitti> ion_: hm, patching debian/local/ with patches?
[06:34] <ion_> pitti: Those are debdiffs
[06:34] <ion_> pitti: I haven’t got around to posting anything to upstream yet.
[06:36] <pitti> ion_: so I apply 1 to 4, and you'll discuss 05 with tkamppeter, and maybe he commits it when he's ok with it? (my last day today, I'll be on holiday from tomorrow on)
[06:36] <ion_> pitti: Sounds good
[06:36] <tkamppeter> Ion_, thanks for all the patches, but did you test whether OOo prints correctly, especially with options?
[06:37] <ion_> tkamppeter: Yes, i did. It respected the options to my surprise.
[06:39] <tkamppeter> Ion_ then OOo perhaps has changed with the time, great.
[06:42] <tkamppeter> pitti. if I find CUPS bugs (or apply #5) during your vacation, should I simply upload a 1ununtu1 into Ubuntu and you resync afterwards?
[06:42] <ion_> tkamppeter: Now that i look at cups/error_log, the print from OOo never used oopstops, the entire chain was pstopdf → pdftopdf → cpdftocps.
[06:42] <pitti> tkamppeter: yes, please do that
[06:43] <pitti> tkamppeter: but please don't commit the UNREELASED -> xubuntuy changelog changes to the svn
[06:44] <ion_> tkamppeter: D [15/Aug/2008:08:43:49 +0300] [Job 236] argv[5]="Resolution=600x600dpi HPHalftone=Standard HPEconoMode InputSlot=Auto Smoothing=Off PageSize=Letter job-uuid=urn:uuid:3c87b758-557c-3db9-72c3-c82bf647a1b3"
[06:44] <ion_> tkamppeter: OOo put the ppd options there correctly.
[06:46] <pitti> tkamppeter: ttf-freefont should really be a Recommends:, will change that
[06:47] <ion_> texttopdf probably doesn’t work at all without it, unless i’m mistaken.
[06:48] <pitti> right, but you don't need it very often?
[06:49] <ion_> Yeah, most users probably won’t. Perhaps texttopdf should be changed to tell the user to install ttf-freefont if it’s not installed.
[06:53] <pitti> ion_: erk, thanks; debian/filters/pstopdf is (was) a mess..
[06:56] <ion_> Fixing it was a prerequisite for being able to get patch 05 to work. :-)
[06:57] <pitti> tkamppeter, ion_: can one of you send ion_'s patches to the new filters to those Japanese gys?
[06:57] <pitti> guys
[06:59] <ion_> I didn’t really edit any of the new filters from them, only changed their costs in #05. I wrote a new filter for the application/vnd.cups-pdf → application/vnd.cups-postscript conversion, though.
[06:59] <pitti> the patch to change the font names, for example
[06:59] <ion_> Ah, right
[07:03] <emgent> moin
[07:04] <pitti> ion_: ok, applied 1 to 4 to svn
[07:04] <pitti> tkamppeter: ^
[07:04] <pitti> ion_: thanks!
[07:05] <ion_> Thanks
[07:10] <tkamppeter> pitti, ttf-freefont is required by texttopdf, so we have to require it. But fortunately, also ubuntu-desktop requires it, which means that it is already on the CDs.
[07:10] <ion_> Heh, i created patches to a svn repo with git, and pitti commits them to the repo with bzr. :-)
[07:11] <pitti> tkamppeter: right, that's why it should be a recommends; texttopdf is not an absolutely critical part, thus people could uninstall ttf-freefont in embedded environments if they want
[07:12] <tkamppeter> And I deal with upstream repos of all 4 RCSs (git, bzr, svn, cvs) and always use the client of trhe appropriate system.
[07:13] <ion_> tkamppeter: Had i wanted to use the svn client, i couldn’t have made the patches as separate commits anyway because of this bug known as “commit access”. :-)
[07:15] <tkamppeter> pitti, OK. As apt-get installs Recommends now, the usual desktop user will have the fonts. And so his right-click+Print of a text file in a file manager should work.
[07:15] <pitti> tkamppeter: exactly
[07:15] <pitti> ion_, tkamppeter: btw, dropping this silly svn repo and moving to bzr is on my short-term todo list
[07:15] <pitti> especially for contributors like ion, for times when we have experimental/unstable/intrepid branches, etc.
[07:16] <ion_> Nice
[07:16] <pitti> svn sucks
[07:16] <ion_> Amen, brother
[07:16] <tkamppeter> pitti, is there a general planning of Debian to move to a modern RCS (bzr or git)?
[07:17] <pitti> as a matter of fact, I have used bzrsvn with the cups branch so far :)
[07:17] <ion_> Yes, i noticed.
[07:17] <pitti> tkamppeter: that's up to indidivual maintainers
[07:17] <tkamppeter> so Debian offers all the 4?
[07:17] <pitti> all four pakcages are in debian, if you mean that
[07:18] <tkamppeter> No, I mean the RCS server of Debian.
[07:18] <pitti> DDs use all kinds of weird VCSs, some even still use tla/baz *cough*
[07:18] <pitti> tkamppeter: alioth supports a lot, svn, cvs, bzr, at least (probably more)
[07:18] <tkamppeter> tla/baz is older than CVS?
[07:18] <pitti> but FSVO "support"
[07:18] <pitti> you can store branches, but not browse them, etc.
[07:19] <StevenK> tkamppeter: CVS has been around for decades.
[07:19] <StevenK> tkamppeter: tla hasn't been around nearly as long, but quite a bit longer if you're Tom Lord.
[07:20] <tkamppeter> StevenK, CVS is the first I used, when I started to get into free software, CVS was the only commonly used one.
[07:21] <pitti> tkamppeter, ion_: cups uploaded to experimental and intrepid
[07:22] <tkamppeter> pitti, thanks.
[07:22] <pitti> tkamppeter: (without ion_'s patch 05)
[07:24] <ion_> Patch 01 now. :-) I stgit-rebased the patch stack to the svn HEAD and re-exported the stack to the same web path.
[07:24] <tkamppeter> ion_, you fifth patch is missing something: You are changing a conffile /etc/cups/mime.convs. dpkg will only install this change if the user did not modify the original by hand. If you want to impose this change to everyone, you have to do the same sed command also in the cups.postinst script, and tyhis only for the transition from the current CUPS package and older to your CUPS package.
[07:25] <ion_> tkamppeter: It would be nice if /etc/cups/mime.convs were in /usr/share/cups in the first place. The file tells users to make local changes to local.convs anyway.
[07:26] <ion_> tkamppeter: But yeah, i’ll do that change.
[07:27]  * pitti freaks out, sed? on conffiles?
[07:27] <ion_> True. :-)
[07:27] <pitti> nonononononono
[07:28] <StevenK> sed on conffiles == bad
[07:28] <StevenK> sed on conffiles == pitti beating you with a stick at UDS
[07:28] <ion_> I better let the user handle it. dpkg will inform about the changed conffile anyway.
[07:32] <ion_> If it only did a three-way merge. :-)
[07:41] <liw> . o O (/etc/sed.conf)
[07:42] <tkamppeter> Ion_, and CUPS 1.4 moves /etc/cups/mime.* even to /usr/share/cups/mime.
[07:42] <ion_> tkamppeter: Nice
[07:43] <tkamppeter> pitti, or should we move already all /etc/cups/*.{types|convs} files to /usr/share/cups/mime ?
[07:43] <pitti> tkamppeter: with the old patch I had to move one back
[07:43] <pitti> tkamppeter: but I don't know what's better, if upstream does it in 1.4, I'm fine with backporting that
[07:44] <tkamppeter> pitti, the patch for /usr/share/cups/mime I have already replaced by the CUPS 1.4 version. So our CUPS is capable of having everything in /usr/share/cups/mime.
[07:44] <pitti> right
[07:48] <tkamppeter> ion_, I have found a bug in your cpdftocps filter: You are searching for CUPS options always with "<option name>=". Boolean options can also appear as "<option name>" or "no<option name>".
[07:49] <ion_> tkamppeter: Ah, right. Will fix.
[07:49] <ion_> tkamppeter: Is the ‘no’ in no<foo> case-sensitive?
[07:51] <tkamppeter> ion_, I think it is lowercase.
[07:51] <tkamppeter> ion_, Duplex is not a CUPS option, it should not get filtered out.
[07:56] <tkamppeter> ion_, have you also taken into account that application/cups-pdf can be PDF with JCL around it? If so, this JCL need to be saved by cpdftocps before it converts to PS and embeds the options and afterwards be merged with JCL added by pstops (or simply re-added in case pstops does not add extra JCL).
[07:57] <tkamppeter> You should test whether pdftopdf applies the JCL options of the PPD. If it does so you can run pstops with the "emit-jcl=False" option. If pdftopdf does not apply JCL options of the PPD, you have to run pstops with "emit-jcl=True".
[07:58] <tkamppeter> Any user or system-supplied "emit-jcl" you have to filter out in the cpdftocps filter.
[08:07] <ion_> Ok, i’ll do the JCL stuff later.
[08:08] <dholbach> hi mvo
[08:10] <mvo> hey dholbach!
[08:15] <ion_> tkamppeter: Updated http://heh.fi/tmp/cups/01-pdf-filter-chain, still no JCL handling.
[08:16]  * StevenK plots and schemes to get a Dapper server upgraded.
[08:28] <ion_> tkamppeter: Anything to fix with the current option masking?
[08:46]  * pitti blinks at the cups FTBFS and the various interesting "gcc OMG" errors and stares at doko
[08:48] <tkamppeter> ion_, I am in doubt whethert it is such a good idea to replace Courier by FreeMono in texttopdf. For me texttopdf works without this change and the change would prevent using other fonts by means of the charsets/pdf.utf-8 file.
[08:48] <tkamppeter> ion_, I think it is better to back that patch out.
[08:51] <tkamppeter> Ion_, for me it looks like that fontconfig does the needed substitutions here.
[08:52] <tkamppeter> pitti, I am currently replacing the texttopdf.c file by a bugfixed version from upstream.
[08:52] <ion_> tkamppeter: I don’t know really about anything else than that you added FreeFont to the packaging along with texttopdf, and texttopdf crashed because it tried to load Courier because it wasn’t a TTF font, hence my patch. A better solution would be welcome, of course. :-)
[08:54] <tkamppeter> Ion_, for me texttopdf did not crash when using the ttf-freemono fonts with the pdf.utf-8.simple file, without any patches on texttopdf.c or any other C file.
[08:55] <tkamppeter> For me it creashed when used with pdf.utf-8.heavy, as that one contains fonts which are not in the distro (*.TTF).
[08:56] <ion_> tkamppeter: Darn, perhaps i screwed up something with the charset files. Now that i think of it, i might have not had them installed while testing texttopdf for the first time and noticing the crash.
[09:02] <tkamppeter> ion_, the important thing are also the links to the fonts files in /usr/share/cups/fonts/.
[09:06] <ion_> tkamppeter: Perhaps defoma should be configured to maintain such links for all installed fonts?
[09:10] <tkamppeter> ion_, I do not really know how defoma works and whether it would kick in here.
[09:11] <tkamppeter> According to ldd texttopdf does not use libfontconfig.
[09:12] <ion_> tkamppeter: See for instance /usr/share/defoma/scripts/gs.defoma and /var/lib/defoma/gs.d/dirs/fonts
[09:14] <tkamppeter> ion_, if you can make texttopdf using defoma without modifying texttopdf by default, patches are welcome.
[09:17] <tkamppeter> pitti, new upstream texttopdf.c with FreeMono patch backed out is on SVN now.
[09:19] <pitti> tseliot: FYI, http://bazaar.launchpad.net/~ubuntu-core-dev/jockey/ubuntu/revision/206 is what came out of the python-apt stuff; quite a bit smaller
[09:19] <tkamppeter> ion_, please do not worry about the fonts for now, this works. Please sort out the JCL problem in the cpdftocps filter.
[09:20] <ion_> tkamppeter: Yeah, i’ll investigate the JCL thing after sleep.
[09:21] <tkamppeter> ion_, what is the time for you now (where are you located)? When will you be back again?
[09:23] <ion_> tkamppeter: It’s 11:22 (AM), but i was awake during the night. :-) I’ll probably fall asleep soon. I assume i’ll be back no later than ten hours from now.
[09:24] <tkamppeter> ion_, OK
[09:25] <tseliot> pitti: yes, it looks better now. Passing the function instead of the object is simpler and there's no need to subclass Cache.
[09:27] <tseliot> pitti: which branch should I use to add the "recommended version" feature?
[09:29] <tseliot> pitti: the changes in handlers and in the 2 GUIs won't affect other drivers in any way unless they support the "recommended" feature
[09:35] <tseliot> pitti: maybe trunk for handlers and the guis while ubuntu for nvidia.py?
[09:54] <mdz> pulseaudio certainly seems to wake up a lot
[09:55] <mdz> hmm, only when my USB headset is connected
[10:22] <lifeless> mdz: doing some power analysis?
[10:23] <pitti> tseliot: right, the recommended feature should land in trunk
[10:24] <tseliot> pitti: ok
[10:36] <tkamppeter> pitti, I have found a solution for the JCL problem of cpdftocps which ion_ talked about:
[10:37] <tkamppeter> pitti, pdftopdf adds JCL headers and footers according to the PPD file and to the options supplied on the command line (or the PPD defaults for not supplied options).
[10:38] <tkamppeter> pitti. pstops does the same thing.
[10:38] <tkamppeter> pitti, and pdftops does not care about JCL. It throughs the JCL away and makes PS out of the PDF part.
[10:41] <tkamppeter> pitti, so we simply let the cpdftocps filter use the general setting of the emit-jcl option, not changing it, not masking it out and not adding it, so that pstops adds JCL the same way as pdftopdf did. So the JCL lost by pdftops gets re-added by pstops.
[10:42] <pitti> I can't really follow, but if you understand the bug, and have a solution, great ;)
[10:42] <tkamppeter> pitti, this means: No changes required on http://heh.fi/tmp/cups/01-pdf-filter-chain.
[10:45] <ion_> I’ll add a comment about that to cpdf2ps and refresh the patch, a moment. (Didn’t manage to fall asleep yet, thanks to the caffeine i drank a few hours ago.)
[10:46] <mdz> lifeless: it's enough that I notice it in top
[10:46] <lifeless> mdz: wheeee
[10:52] <tkamppeter> pitti, so I will add the patch and commit it if it does not reveal new bugs.
[10:57] <ion_> tkamppeter: Added some comments, http://heh.fi/tmp/cups/01-pdf-filter-chain
[11:01] <tkamppeter> ion_, thanks
[11:02] <tkamppeter> ion_, seems that you will not be able to sleep until the PDF workflow is ready.
[11:02] <ion_> Heh
[11:03] <tkamppeter> ion_, your last change are only comments in cpdftocps?
[11:03] <ion_> tkamppeter: Yes
[11:04] <tkamppeter> Ion_, small bug in cpdftocps: pdftops "$@" must be pdftops $@, otherwise you feed all the options into the queue name field.
[11:05] <ion_> tjaalton: No, "$@" expands to "$1" "$2" "$3" etc.
[11:05] <ion_> tjaalton: Sorry. tkamppeter
[11:05] <tkamppeter> ion_, OK, reverting it.
[11:06] <ion_> tkamppeter: On the other hand, "$*" expands to "$1$IFS$2$IFS$3" etc.
[11:06] <ion_> tkamppeter: I noticed a typo in the comments: # → cpdftops (runs pdftops → pstops) (s/cpdftops/cpdftocps/)
[11:07] <ion_> Shall i fix it and update the patch?
[11:08] <ion_> Already did. :-)
[11:08] <tkamppeter> ion_, you tell "$@" is correct, so there is nothing to fix.
[11:09] <ion_> tkamppeter: The typo in the comment.
[11:10] <ion_> % (set -- a b c d e; printf "|%s|" "$@"); printf '\n'
[11:10] <ion_> |a||b||c||d||e|
[11:10] <tkamppeter> ion_, there is another problem: CUPS defines an optional 6th command line argument for filters which is the input file name. cpdftocps does not support that.
[11:11] <ion_> tkamppeter: It does. It goes to pdftops within "$@"
[11:11] <ion_> tkamppeter: But intentionally not to pstops, of course.
[11:12] <tkamppeter> ion_, yes, you are right.
[11:13] <bigon> I'm the only one who cannot reboot/shutdonw using the shutdown dialog in gnome (intrepid) ?
[11:13] <ion_> bigon: I only get a switch user/cancel/logout dialog.
[11:14] <bigon> ion_, the dialog appears but when clicking shutdown nothing happends
[11:16] <bigon> oh I get http://pastebin.be/13183
[11:16] <seb128> bigon: no, that's a known issue
[11:16] <seb128> bigon: #250506
=== dholbach_ is now known as dholbach
[11:17] <bigon> seb128, thx
[11:27] <tkamppeter> ion, I have tried to print but have a problem: The Resolution option is set to 1200x1200dpi but the printout comes out with crappy 150dpi, perhaps broken down to that by the pstopdf filter in the beginning.
[11:30] <tkamppeter> ion_, I have tested with the CUPS test page. It says 150x150dpi in the left box.
[11:31] <ion_> tkamppeter: Hmm. The DPI setting worked for me. What’s the job’s argv[5] in cups/error_log?
[11:32] <tkamppeter> ion_, it comes from pstopdf, as when I do
[11:32] <tkamppeter> /usr/lib/cups/filter/pstopdf 1 2 3 4 5 /usr/share/cups/data/testprint.ps > testprint.pdf
[11:33] <tkamppeter> and then display testprint.pdf, it says 150x150dpi.
[11:33] <ion_> Ah. That’s probably some default value because it doesn’t read a PPD.
[11:33] <ion_> Try PPD=/path/to/some/ppd /usr/lib/cups/filter/pstopdf ...
[11:34] <tkamppeter> On real print jobs the 1200x1200dpi are not in the fifth command line argument, as I have set this value as PPD default.
[11:34] <tkamppeter> ion_, probably this will not work, as I had the same observation with a real print job.
[11:36] <tkamppeter> The filter is a script and it has hardcoded "-r150" in it. I will remove it and try again.
[11:36] <ion_> Ah
[11:38] <tkamppeter> Running the script manually it gives 720dpi now.
[11:39] <ion_> I wonder how to make it grab the DPI value from the active PPD properly...
[11:40] <ion_> I also wonder whether it’s relevant, i.e. whether it affects the actual PDF output. :-)
[11:41] <ion_> Vector graphics won’t suffer for sure, but pstopdf could theoretically downscale embedded bitmaps.
[11:45] <tkamppeter> The pstopdf conversion is OK when one looks at the page in acroread.
[11:47] <tkamppeter> When I look at the printouts the only thing where it suffers is how the colors of the color wheel are rendered into bw.
[11:47] <tkamppeter> ion_, there appears a coarse pattern and no grays.
[11:49] <tkamppeter> ion_, the "-rXXX" in pstopdf has no influence on this.
[11:50] <ion_> Hmm, ok...
[12:00] <ion_> tkamppeter: I printed /usr/share/cups/data/testprint.ps using pstops and then pstopdf→pdftopdf→cpdftocps. I can see no difference at all in their quality.
[12:03] <tkamppeter> ion_, sorry, I have tracked down the problem. It was the printer itself. I had to set it to Enhanced grayscale.
[12:04] <tkamppeter> Now it works perfectly.
[12:04] <ion_> Cool
[12:04] <tkamppeter> ion_, but I will take the "-r150" out of the pstopdf filter anyway.
[12:05] <ion_> Yeah
[12:05] <ion_> I’d guess the setting’s only relevant when using ghostscript to render postscript to a bitmap.
[12:13] <tkamppeter> ion_, I think so, too. And as the filter does not do this, I have removed the option.
[12:13] <pitti> mpt: I'd like to discuss some jockey UI changes with you, do yuo have some minutes?
[12:13] <pitti> tkamppeter: FYI, cups failed to build, seems the new gcc doesn't like me or so
[12:15] <tkamppeter> pitti, yesterday it still built and today it stopped?
[12:15] <ion_> Worksforme™
[12:15] <ion_> I built it just a couple of hours ago.
[12:15] <mpt> pitti, not at the moment sorry, I'm about to head out
[12:15] <mpt> pitti, how about in 3 hours?
[12:15] <pitti> mpt: works for me, thanks
[12:15] <mpt> ok
[12:16] <tkamppeter> ion_, then do not try "sudo apt-get update; sudo apt-get dist-upgrade", this will give you a bad gcc.
[12:16] <ion_> Heh, alright :-)
[12:46] <tkamppeter> pitti, ion_'s patch works correctly now for me. With some little corrections I have a perfectly working PDF workflow now. Should I commit it?
[12:47] <asac> Ng: you have openvpn right?
[12:47] <asac> Ng: can you test the latest packages from network-manager PPA?
[12:47] <asac> (and remember to restart your system after upgrade)
[12:47] <tkamppeter> pitti, please do not commit by yourself, as I have done several small corrections.
[12:49] <ion_> Hm. After a print job, cups sets the RDYMSG as "READY", but IIRC it should be set as "" according to the PJL spec, so that the printer returns the display to its default view. I’ll make a patch.
[12:50] <ion_> First i’ll check the spec. :-)
=== Kopfi|offline is now known as Kopfgeldjaeger
[12:51] <NCommander> seb128, morning
[12:54] <Chipzz> NCommander: seb128 has a day off
[12:55] <NCommander> wow, amazing concept :-P
[12:55] <NCommander> I was just going to ask if he had any more packaging work for me
[13:17] <ion_> tkamppeter: http://heh.fi/tmp/cups/02-pjl-messages (didn’t test yet, still building)
[13:18] <Ng> asac: sure can
[13:19] <Ng> asac: do I really really need to restart? won't just restarting NM do the trick? :)
[13:31] <ion_> tkamppeter: Ok, i tested the patch, it works.
[13:35] <pitti> tkamppeter: sure, go ahead
[13:35] <pitti> tkamppeter: cups is all your's in the next two weeks :)
[13:54] <ScottK> Did I get fired and no one told me? "Your message to ubuntu-devel awaits moderator approval - Post by non-developer to moderated list."
[13:54] <ScottK> I checked and the From address is the one that's subscribed.
[13:55] <tkamppeter> ion_, thanks for the patch, please report all upstream CUPS bugs (for now this patch and also the path typo) at http://www.cups.org/str.php, with attached patches.
[13:57] <ion_> tkamppeter: Yeah, i’ll try to get around to reporting them.
[14:00] <tkamppeter> pitti, I have committed all that. If you want to do a last synced Debian/Ubuntu upload before your vacation ...
[14:02] <persia> ScottK: I got that today too.
[14:04] <ScottK> Is this perhaps a question for #canonical-sysadmin then?
[14:04] <ScottK> Other suggestions?
[14:06] <persia> Do they manage the whitelist?  According to the information I saw, cjwatson managed the list.
[14:07] <ScottK> I have no idea.
[14:09]  * Hobbsee offers virtual gummy bears to whoever fixes listadmin
[14:11] <Hobbsee> ah good, there's already a patch for it in debian.
[14:18] <ion_> tkamppeter: Please see my private message. :-)
[14:19] <asac> Ng: restarting the NetworkManager ... and restarting the nm-applet
[14:19] <asac> Ng: should be ok
[14:19] <asac> maybe reloading dbus config
[14:19]  * NCommander sighs
[14:20] <NCommander> morning Hobbsee
[14:20] <Hobbsee> hey NCommander
[14:20] <NCommander> Hobbsee, how goes your morning?
[14:21] <Ng> asac: ok
[14:21] <Hobbsee> my morning?  it's evening here, and i'm glad that work's over :P
[14:23] <NCommander> Hobbsee, lucky, my morning began with one of my favorite ports being dropped from Debian
[14:23] <NCommander> And the resulting flamewar on d-devel
[14:23] <Hobbsee> awww
[14:23] <NCommander> The worst part?
[14:23] <NCommander> I'm a hurd/m68k porter :-P
[14:23] <NCommander> I'm not sure the FD will approve me if those architectures get dropped -_-;
[14:28] <mvo> I noticed that cups-pdf got demoted to universe in intrepid, out of curiosity, does cups itself provide this functionatliy now?
[14:28] <seb128> hey NCommander
[14:29] <NCommander> Morning seb128
[14:29]  * NCommander is enjoying a nice hot cup of d-devel flamewar
[14:30] <seb128> NCommander: want to look at getting the pygobject building?
[14:31] <NCommander> why is it FTBFSing?
[14:31] <NCommander> (usually an importing first question)
[14:31] <seb128> NCommander: the debian and ubuntu packages are doing builds for multiple python versions
[14:32] <seb128> NCommander: and the new version has a lib which doesn't play well with that
[14:32] <seb128> NCommander: doko started doing changes to get the lib versionned by that doesn't build
[14:32]  * NCommander twichs
[14:32] <NCommander> Is it already packaged, and just FTFBS, or do I get the honour of packaging the new version ontop of everything else?
[14:33] <doko> seb128: I thought you did finish that :)
[14:33] <NCommander> morning doko
[14:33] <seb128> doko: I've been too busy to look at it
[14:33] <doko> ahh
[14:33] <NCommander> seb128, well, I just finished repackaging glibc for m68k, so I can probably take a look at it
[14:34] <NCommander> though my brain is fried
[14:35] <seb128> NCommander: one sec
[14:35] <seb128> NCommander: http://people.ubuntu.com/~seb128/pygobject/ the current version there
[14:36] <mvo> tkamppeter: you probably know about cups-pdf, right? what is the status of this? it got demoted to universe, does that mean that there is something in stock cups now that provides this functionatliy?
[14:37] <seb128> mvo: gtk does printing to pdf just fine no?
[14:37] <seb128> mvo: if you select "print to file", you have the choice between ps and pdf usually
[14:38] <tkamppeter> KDE 3.x apps all the time offered a "print to PDF" entry in their print dialog which opened a "Save as ..." for the PDF.
[14:38] <mvo> seb128: aha, ok. and kde probably has something similar? it would just be useful for commandline users nowdays?
[14:39] <tkamppeter> If this is not there any more in KDE 4, a simple "Print to file" should work as KDE apps send print jobs in PDF now.
[14:39] <mvo> tkamppeter: ok, so the cups-pdf package is only useful for commandline users these days?
[14:39] <tkamppeter> OOo has an "Export to PDF ..." entry in its "File" menu.
[14:40] <doko> seb128: is this the one with my changes
[14:40] <seb128> doko: 0ubuntu2 is your version yes
[14:40] <seb128> I tried and it didn't build
[14:40] <seb128> and I've been too busy to debug why
[14:41] <tkamppeter> seb128, by the way, the PDF printing workflow (https://blueprints.edge.launchpad.net/ubuntu/+spec/pdf-as-standard-print-job-format) is now completed on the server side and for KDE apps, as GTK apps can do "Print to file" with selectable PS or PDF, is there no simple possibility to let normal print jobs to be sent out in PDF?
[14:43] <seb128> tkamppeter: I've no clue, as already said I don't know this code, you are welcome to look at the issue though
[14:44] <pitti> tkamppeter: cups -4 FTBFSes on various architectures, e. g. sparc now, see debian bug 495220
[14:44] <ubottu> Debian bug 495220 in cups "cups_1.3.8-4(sparc/experimental): FTBFS: unrecognized command line" [Serious,Open] http://bugs.debian.org/495220
[14:46] <pitti> tkamppeter: that is a new CPPFLAG introduced in the local filters, and obvioously bogus for !i386
[14:46] <pitti> tkamppeter: can you please fix that before I upload -5?
[14:47] <pitti> tkamppeter: this affects a lot of Ubuntu arches, too
[14:51] <pitti> tkamppeter: -Wall -g are not even appropriate CPPFLAGS (but CFLAGS), and -march even less so
[14:51] <jcristau> pitti: err. -Wall -g in CPPFLAGS should be just fine.
[14:51] <pitti> jcristau: but what for?
[14:52] <jcristau> same as in CFLAGS, except for c++ instead of c
[14:52] <pitti> that's CXX, not CPP
[14:52] <pitti> CPP is preprocessor
[14:52] <jcristau> ignore me
[14:52] <jcristau> yeah, i know. but it seems 2 cups of coffee weren't enough
[14:52] <pitti> tkamppeter: let me commit that myself
[14:53] <pitti> jcristau: no number of coffee cups suffices to master cups
[14:53] <jcristau> pitti: :)
[14:53] <tkamppeter> pitti, done and committed
[14:54] <pitti> tkamppeter: ah, you beat me to it, thanks
[14:54] <tkamppeter> pitti, texttopdf contained a hardcoded -march=pentium
[14:54] <tkamppeter> I have deleted it.
[14:54] <pitti> tkamppeter: I'll add a changelog for it to close the bug and upload
[14:56] <poningru> I had a quick question: https://help.ubuntu.com/community/LiveCDCustomization following that for live cd creation, but does the install get any changes I make as well?
[14:57] <poningru> as in if I were to create a live cd changes with a different kernel and few gconf changes will the changes show up in the install as well?
[14:59] <poningru> and where does one go for general downstream help?
[15:01] <persia> poningru: If you've defined matching meta-packages, it should, and probably the Ubuntu derivatives team.
[15:01] <persia> (or rather, a matching manifest, I believe, but I may be mistaken)
[15:03] <pitti> tkamppeter: -5 uploaded to intrepid and experimental
[15:03] <poningru> searching
[15:13] <asac> Ng: did it work?
[15:16] <ScottK> pitti: Would you have time to attend to a sync that's blocking a further upload?
[15:16] <pitti> ScottK: sure, shoot
[15:16] <ScottK> pitti: It's in Bug #258160
[15:16] <ubottu> Launchpad bug 258160 in sip4-qt3 "Please sync sip4-qt3 4.7.7-1 from Debian Experimental (Main)" [Wishlist,Confirmed] https://launchpad.net/bugs/258160
[15:16] <ScottK> Thanks.
[15:16] <tkamppeter> pitti, great, thanks.
[15:18] <pitti> ScottK: swoosh, there
[15:18] <ScottK> Thanks.
[15:23] <Ng> asac: I restarted NetworkManager and nm-applet, but it's segfaulting in nm-openvpn-auth and logging an error about not being able to get connection secrets (of which there should be none, the key is passwordless)
[15:23] <Ng> asac: it's possible I've set it up wrong, the new config stuff is quite a lot more verbose than before, but I don't think so
[15:24] <Ng> asac: http://pastebin.ubuntu.com/37730/
[15:28] <tkamppeter> Anyone here is familiar with the GTK code?
[15:28] <Ng> asac: interestingly, I get a similar thing if I try to export the settings for it :/
[15:36] <asac> Ng: is there a way i can test  openvpn?
[15:36] <asac> e.g. do we have a VPN?
[15:38] <Ng> asac: not that I can quickly/easily hook you up with. It's not too bad to configure, and then you just need to make a CA and some keys, which they have some docs for
[15:38] <asac> Ng: ok. ill try over weekend
[15:38] <Ng> asac: http://openvpn.net/howto.html and http://openvpn.net/index.php/documentation/miscellaneous/rsa-key-management.html are pretty good, and I think I did it originally with something I dug out of google, but I don't seem to have a record of it unfortunately
[15:39] <asac> Ng: ok. thanks. noted.
[15:40] <asac> Ng: if i dont manage to set that up, ill come back with more debug instructions ;)
[15:40] <Ng> unfortunately their Import thing doesn't seem to like importing native openvpn config files. It gets some of the values, but the connection editor segfaults when you start poking around ;)
[15:40] <Ng> sure
[15:49] <lamont> pitti: any chance you (or any $ARCHIVEGOD) could slap bug 257893 around for me?
[15:49] <ubottu> Launchpad bug 257893 in postfix "Please sync postfix 2.5.4-1 (main) from Debian incoming/unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/257893
[15:50] <pitti> lamont: slapped appropriately
[15:51] <lamont> ta
[15:53] <BenC> Is there any known bugs concerning IPP printing?
[15:53] <BenC> I'm not sure if it's me or if ipp in cups is just broken
[15:54] <BenC> (intrepid of course)
[15:55] <pitti> BenC: can you try "sudo aa-disable cups", restart cups, and try again?
[15:55] <BenC> pitti: ok
[15:57] <BenC> pitti: I don't have a program called aa-disable on my system
[15:57] <pitti> BenC: sorry, "aa-complain"
[15:57] <pitti> BenC: "sudo rm -r /" should help as well
[15:58] <BenC> pitti: I've heard that command works really well...I'll try it!
[15:58] <pitti> let's check how many people actuall run my sudo commands over IRC without checking :-P
[15:58] <pitti> "r"ead"m"ail -"r"eally"f"ast *
[15:58] <BenC> at least we're not in #ubuntu
[15:58] <pitti> BenC: insta-bugzap
[16:02] <BenC> pitti: actually, I got a crash in applet.py...didn't match any other bug reports, so I let apport file it
=== brandon|work is now known as brandonperry
[16:03] <pitti> mvo: can I ask python-apt to just read one particular repository, not the entire sources.list{,.d/*.list} ?
[16:03] <mvo> hey pitti
[16:03] <BenC> pitti: KeyError 61 in update_job() in jobviewer.py
[16:03] <mvo> pitti: not right now, what is your use-case for this?
[16:04] <pitti> mvo: a driver db gives me a package repository and a package name in it
[16:04] <pitti> mvo: just a strawman idea, nothing serious so far
[16:04] <mvo> pitti: and you want to check if its from that repository? or you want to do a apt-get update that just updates  this repository (or both :) ?
[16:05] <pitti> mvo: the latter, just to save some time
[16:05] <mvo> pitti: I like the idea!
=== superm1 is now known as superm1|away
[16:07] <pitti> mvo: apt.Cache() rightfully stumbles over a malformed deb line, but apt.Cache().update() doesn't fail on an invalid URL ("deb http://foo /"); shouldn't something detect that as well?
[16:08] <mvo> pitti: you don't get a exception that some package could not be downloaded if you give it a non-existing repo?
[16:08] <mvo> pitti: that sounds like a bug
[16:08] <pitti> mvo: so far I just added that deb http://foo to /etc/apt/sources.list.d/jockey.list and did "c = apt.Cache(); c.update()"
[16:08] <pitti> I didn't try to install anything yet
[16:09] <pitti> I just expected c.update() to freak out on an invalid source
[16:09] <pitti> but it might make sense that it doesn't, I don't know
[16:09] <pitti> it's perhaps more like a warning kind of situation
[16:10] <mvo> oh, right. I think this is a side effect of a change that we did not make apt more happy when no networks are available, network errors like "resolvefailure" are ignored by default
[16:10] <mvo> hm, I guess it should do something about it, what would be best? a exception with the repos that didn't work?
[16:10]  * pitti scratches head
[16:12] <BenC>  def update_job (self, job, data):
[16:12] <BenC>         store = self.store
[16:12] <BenC>         iter = self.jobiters[job]
[16:12] <BenC> pitti: it crashes on that last line
[16:12] <pitti> BenC: what's that from?
[16:13] <pitti> mvo: it just returns 1/0 so far, right? an exception might be too heavy
[16:13] <BenC> pitti: jobviewer.py
[16:14] <pitti> BenC: oh, that's from s-c-p; /me directs BenC to tkamppeter
[16:14] <pitti> BenC: an apport crash report should be fine
[16:16] <BenC> pitti: already done...but I need to be able to print :)
[16:16] <BenC> tkamppeter: ping ^^
[16:16] <pitti> BenC: the applet shouldn't stop you from it, it's just GUI sugar
[16:16] <pitti> BenC: did the aa-complain help, btw?
[16:18] <BenC> pitti: I'm not sure what I am looking for with that...dmesg didn't show anything weird
[16:18] <BenC> pitti: and it still doesn't print
[16:18] <pitti> BenC: ok, I thought because of the various apparmor violations cups spits out nowadays for various "funny" network protocols
[16:18] <BenC> pitti: connecting to the ipp, I can directly print a test page, but cups isn't sending data
[16:19] <pitti> BenC: anythign helpful in /var/log/cups/error_log? anyway, tkamppeter is the guru
[16:19] <BenC> E [15/Aug/2008:11:19:11 -0400] cupsdAuthorize: Local authentication certificate not found!
[16:19] <MacSlow> seb128, intrepid (GNOME) is not going to be using gnome-session 2.23.x or is it?
[16:19] <BenC> just that
[16:19] <seb128> MacSlow: not decided yet, why?
[16:20] <BenC> E [15/Aug/2008:00:20:16 -0400] PID 19889 (/usr/lib/cups/backend/ipp) crashed on signal 9!
[16:20] <BenC> oooh, there's a good one
[16:21] <StevenK> Blink? What SIGKILL'd it?
[16:21] <BenC> I wonder if that was me pausing/resuming the printer queue
[16:21] <MacSlow> seb128, there's a nice simplification introduced in gdm upstream that would make part of my work a bit easier (namely the greeter to use is simply controled by a .desktop file in /usr/share/gdm/autostart/LoginWindow... before it was hardcoded and requires a considerable amount of boiler-plate code)
[16:22] <MacSlow> seb128, if it's not decided yet... just take that as a pro-argument for using the new gnome-session :)
[16:22] <seb128> MacSlow: that doesn't seem to be a gnome-session thing but a gdm one
[16:23] <MacSlow> seb128, it's both sort of as the new change in gdm upstream uses the new gnome-session for session-managment
[16:23] <seb128> MacSlow: the new gdm uses the autostart dir you mentionned for a while
[16:24] <MacSlow> seb128, but not for the selection of the greeter to use... at least until yesterday it did not
[16:24] <seb128> ok
[16:24] <seb128> MacSlow: we are not likely to ship the new gdm anyway so it's not really revelant there
[16:25] <MacSlow> on that regard you're right
[16:26] <nxvl> MacSlow: when are we having the new gdm in intrepid?
[16:26] <nxvl> MacSlow: or we need to wait one more release cycle?
[16:26] <nxvl> i was the video, it look amazing
[16:26] <nxvl> s/was/saw/
[16:28] <MacSlow> nxvl, atm it looks like we're not going with the new gdm by default... nevertheless I'll keep working on the graphical-greeter
[16:28] <nxvl> :(
[16:30] <johanbr> MacSlow: is there any chance of having it as an optional package?
=== superm1|away is now known as superm1
[16:31] <MacSlow> johanbr, that's the plan
[16:31] <johanbr> Excellent. Thanks.
[16:32] <mpt> pitti, ready when you are
[16:33] <pitti> mpt: hi
[16:33] <pitti> mpt: so, you roughly know the current jockey main window, right?
[16:34] <pitti> mpt: we will gradually add features to support "third-party driver databases"
[16:34] <pitti> mpt: like printer drivers from openprinting.org, etc.
[16:34] <mpt> ok
[16:34] <pitti> or community people's PPAs, and whatnot, through some QAification process
[16:34] <pitti> mpt: I would like to disable them by default and limit drivers to the ubuntu archive
[16:35] <pitti> but I think there should be some discoverable way to enable them
[16:35] <pitti> like a checkbox "Check for unsupported community drivers" or so
[16:35] <mpt> This is sounding more and more like it should be part of the same interface as package management
[16:36] <pitti> indeed it uses the package manager as its underpinnings, sure
[16:36] <pitti> but it provides a per-hardware component centric view on it, and provides the driver db lookup, etc.
[16:37] <mpt> I meant part of the same human interface
[16:37] <pitti> like g-a-i?
[16:37] <mpt> yes
[16:37] <mpt> anyway, where would it look, precisely?
[16:38] <mpt> I assume it wouldn't look through all the PPAs that exist on Launchpad :-)
[16:38] <pitti> mpt: for now it can consult openprinting.org and fetch packaged PPD files and the like
[16:38] <pitti> mpt: hell, no :)
[16:39] <pitti> mpt: and ATM we are working on an "Ubuntu driver database" where we could add QA-blessed third-party repos to, but that's still in the design phase
[16:39] <pitti> that is, the client side is done, but the server doesn't exist yet
[16:40] <mpt> The client side is done?
[16:40] <mpt> What does it look like?
[16:40] <pitti> just the machinery
[16:40] <mpt> oh
[16:40] <pitti> no UI yet
[16:40] <pitti> which is the bit I'm thinking about right now
[16:40] <pitti> mpt: the UI doesn't look any different in the end
[16:40] <mpt> How do you know if the machinery is done, if the HI isn't designed yet? :-)
[16:40] <pitti> "dude, you plugged in hardware, you need that driver" *click* "ok"
[16:41] <mpt> hm
[16:41] <pitti> mpt: the code has all the bits to look up hardware, query the driver db (the protocol is finalized), create handlers for it, etc.
[16:41] <mpt> Why would you not want to install drivers for hardware that you've just connected?
[16:41] <pitti> so where your nvidia card appears today, in some months there could be your updated wifi driver from dell, or whatnot
[16:42] <pitti> mpt: if these drivers are in the ubuntu repo, there should be no question, and that's what we do ATM
[16:42] <pitti> mpt: but e. g. openprinting.org is not under our control, so we cannot say in advance that we can fully support it, or give guarantees whether they will actually work
[16:43] <pitti> or community drivers
[16:43] <mpt> hmmm, ok
[16:43] <pitti> mpt: e. g. some weeks ago I packages an updated driver for DVB-T cards for hardy
[16:43] <pitti> which is in my ppa
[16:43] <pitti> it would be nice to make those available somehow to folks, but not by default
[16:43] <mpt> I think we should avoid explicitly asking people to choose between unsafe drivers and their hardware not working at all
[16:43] <mpt> so, no confirmation alerts hopefully
[16:44] <pitti> mpt: maybe, instead of making a global choice, we could show these drivers in the list, but warn when enabling them?
[16:44] <pitti> when someone clikcs on a driver he'll get the confirmation dialog with the detailled descrption and rationale, etc. anyway
[16:44] <mpt> Then we should find some way that doesn't involve a confirmation dialog
[16:45] <mpt> For example, yesterday I suggested having the description of the selected driver in a second pane, underneath the list of drivers
[16:45] <pitti> mpt: you mean you want to get rid of the already existing one as well? (which shows the driver details)
[16:46] <pitti> that would probably work, too
[16:46] <mpt> If we did that, and had an "Apply Changes" button at the bottom, that would do the same job as a confirmation alert, without the annoyance of a confirmation alert
[16:46] <pitti> there we can also have some fields/buttons for license and rationale
[16:46] <mpt> Ok, so what information do we need to show?
[16:47] <mpt> What kinds of license are there?
[16:47] <pitti> for now, I have:
[16:47] <pitti>  * license status: free/ not free (and in the latter case, a button or link to the full text)
[16:47] <pitti>  * description and rationale
[16:47] <pitti>  * support status: official Ubuntu driver or community
[16:48] <mpt> Can you give an example of what you mean by "rationale"?
[16:49] <pitti> e. g. for nvidia, "You need this driver to be able to use desktop effects and 3D applications"
[16:50] <pitti> (the actual strings are a bit more wordy, but that's the idea)
[16:51] <mpt> ok
[16:51] <mpt> By "support status" do you mean whether Canonical maintains it (as in PackageMaintainednessPresentation), or something else?
[16:51] <pitti> s/Canonical/Ubuntu/
[16:52] <pitti> mostly "official Ubuntu driver" vs. "third-party contribution"
[16:53] <mpt> so a driver that's in Universe is an "official Ubuntu driver"?
[16:53] <pitti> we can further divide the status if we need
[16:54] <pitti> we have gradually less control and QA over main >> universe >> third-party repo
[16:54] <pitti> if the entire idea is bogus, please tell me, then we forget about the third-party repos and just include drivers which we QAed ourself
[16:55] <mpt> It's probably not bogus, I'm just not sure what you mean by "we"
[16:55] <pitti> but so far people use google and some crackful recipes to install whatever drivers they need, so anything that makes that a bit more structured and controlled is a win, IMHO
[16:56] <pitti> mpt: 'we' in the sense of 'divide the status' -> mostly me, with your input
[16:58] <ScottK> pitti: Probably the most important part of the idea is the qualification process for 3rd party repos.  Get that right, and I think it's good.  Get it wrong and it's possibly quite dangerous.
[16:59] <pitti> ScottK: agreed
[16:59] <mpt> pitti, sorry, I was unclear. I mean, who's "we" in "drivers we QAed ourself"?
[16:59] <pitti> an indeed, the idea is not really that users should be scared about trying a driver
[16:59] <pitti> but rather to tell them "if it doesn't work, Ubuntu cannot fix it, but it's someone else's fault"
[17:00] <pitti> mpt: that's a little blurry indeed, and heavily depends on how we advertise it
[17:01] <pitti> mpt: if we say "this thing Just Works(tm)", we need our hw certification and QA team
[17:01] <pitti> if we just say "it doesn't break your system and is properly packaged", it could be ubuntu-motu
[17:01] <pitti> so the certification "level" should map to the set of people allowed to add it to the driver db
[17:01] <pitti> mpt: as I said, the only real DB right now which we have is opeprinting.org, which is mainly tkamppeter's work
[17:02] <pitti> the rest is drawing board
[17:02] <mpt> Do we currently have drivers in Universe at all?
[17:02] <pitti> (and not at all something for intrepid)
[17:02] <pitti> mpt: yes, e. g. the virtualbox kernel modules
[17:03] <pitti> and since we have dkms now, non-kernel-packaged drivers actually started to make sense again, so I expect we'll have more in the future
[17:03] <pitti> until now it was virtually useless to have a separately packaged kernel driver, due to our numerous ABI changes
[17:03] <mpt> ok, so maybe something like:
[17:04] <mpt> "This driver has been tested by Ubuntu core developers."
[17:04] <mpt> "This driver has been tested by Ubuntu community developers."
[17:04] <mpt> "This driver has not been tested by Ubuntu developers."
[17:04] <mpt> There are probably half a dozen things wrong with that, tell me what they are. :-)
[17:04] <pitti> that's actually pretty much what it comes down to
[17:06] <ScottK> We also have the drivers for envy-ng in Multiverse
[17:06] <pitti> right
[17:06] <pitti> that would fit into the "Ubuntu community" class
[17:06] <mpt> Have the openprinting.org drivers been tested by anyone?
[17:06] <pitti> and I think envy-ng and jockey will merge some day
[17:07] <pitti> mpt: by default, no; ATM I am trying to convince tkamppeter to provide packaged PPDs, which are relatively uncritical
[17:07] <pitti> but there are also packages with real code in them, which are a bit more sensitive
[17:08] <pitti> they are still much saner to the stuff printer manufacturers offer at their websites, though
[17:08] <pitti> (anyone still remember the "printer driver set openoffice to setuid root" bug?)
[17:11] <tkamppeter> pitti, and such driver packages we will not accept.
[17:11] <pitti> hehe :)
[17:11] <mpt> pitti, do you need anything more than that at the moment?
[17:11] <pitti> mpt: I think I made up my mind, thanks a lot
[17:11] <mpt> e.g. do you want a sketch of the two panes or whatever
[17:12] <pitti> now I have 14 days of vacation to think about it :)
[17:12] <mpt> ok
[17:12] <mpt> enjoy it :-)
[17:12] <pitti> mpt: I think I'll do a glade mockup and run it by you
[17:12] <pitti> mpt: thanks
[17:12] <tkamppeter> pitti, I was very much occupied with getting the PDF workflow into intrepid, the scripting for automatic generation of PPD file packages I will do in the beginning of September (it is not in Intrepid itself, so it does not need to meet the FF).
[17:13] <pitti> tkamppeter: oh, cool! so in general you like the idea?
[17:13] <pitti> tkamppeter: yes, it's not tied at all to Ubuntu releases
[17:13] <pitti> so, I'm going to leave now, still have to do some preparation for tomorrow's wedding of my friend, and for our holiday trip
[17:14] <pitti> have fun everyone, cu in two weeks!
[17:21] <ScottK> Right, so I just missed pitti.
[17:22] <ScottK> If there's an archive admin in the house, I'd appreciate them accepting the backports in Bug #258193 (source backports just uploaded) since it has a CVE fix in it.
[17:22] <ubottu> Launchpad bug 258193 in gutsy-backports "Please backport postfix 2.5.4-1 to Gutsy/Feisty/Dapper" [Medium,In progress] https://launchpad.net/bugs/258193
[17:54] <agy> I will be performing maintenance on wiki.ubuntu.com in 20 minutes. During this time the wiki will be placed in read-only mode. Please save your edits before this time. The maintenance is expected to last 15 minutes.
[17:59] <zul> slangasek: ping any idea when samba 3.2.1 is going t be uploaded to unstable?
[18:00] <slangasek> zul: approximately yesterday
[18:00] <zul> slangasek: ah good :)
[18:01] <zul> slangasek: I guess it will be kind of a monday morning kind of thing to do then
[18:10] <ScottK> slangasek: Thanks for the postfix backport acceptances.
[18:10] <slangasek> ScottK: n/p
[18:11]  * ScottK would like to note for the record for those who wonder if *-backports gets security coverage or not, that this particular issue is fixed in *-backports before *-security.
[18:16] <persia> ScottK: Does everything in -backports get that level of security support?
[18:16] <ScottK> persia: No.
[18:17] <ScottK> There seems to be a common assumption that "Not always"  == "Never" and that's not correct.
[18:20] <persia> Ah, yes, that would not be correct.
[18:24] <slangasek> nonnumquam
[18:26] <persia> superm1: Unfortunately, there appears to be a real package named "gdm-themes".  Any ideas for a good name for a virtual package?
[18:27] <superm1> persia, why not just gdm-theme?
[18:27] <superm1> or default-gdm-theme
[18:27] <agy> Maintenance on wiki.ubuntu.com has been successfully completed.
[18:27] <persia> I don't like default-gdm-theme because it makes me thing someone would have to mess around with alternatives.
[18:28] <persia> (or is that already being done?)
[18:28] <superm1> well in order to use a different gdm theme you need to use  gdm-cdd.conf
[18:28] <superm1> which is what mythbuntu does; not sure about xubuntu or studio
[18:28] <persia> edubuntu has the issue as well.
[18:29] <_MMA_> Studio uses gdm-cdd.conf.
[18:30] <persia> cody-somerville, ogra: what do you use?  Any thoughts on a virtual package name?
[18:31] <cody-somerville> persia, whats the question?
[18:32] <persia> cody-somerville: RIght now, gdm Recommends: a closed set of gdm themes.  I think it makes more sense to follow the practice of usplash, and recommend a virtual package so that any of the flavours that use gdm can have their own splash screen.
[18:32] <persia> So, the question is whether the gdm-themes portion of xubuntu-default-settings uses gdm-cdd.conf to set the gdm theme.
[18:33] <persia> s/splash screen/theme collection/
[18:33] <_MMA_> cody-somerville: Bug 258091
[18:33] <ubottu> Launchpad bug 258091 in gdm "gdm should not recommend ubuntu-artwork" [Wishlist,Confirmed] https://launchpad.net/bugs/258091
[18:35] <ogra> persia, gdm-cdd.conf
[18:36] <cody-somerville> Xubuntu just has a gdm.conf
[18:36] <slangasek> kees: so have you talked to YokoZar about your sigsegv madness? :)
[18:36] <persia> Right.  Based on that, I'll recommend xubuntu switch to using gdm-cdd.conf to match everyone else :)
[18:36] <ogra> cody-somerville, oh ? since when ?
[18:37] <ogra> i remeber jani and i worked out he gdm-cdd.conf setup
[18:37] <cody-somerville> ogra, Lets take a step back.
[18:37] <ogra> simply because we could set ut through alternatives if wanted then
[18:37] <cody-somerville> Whats a gdm-cdd.conf? :]
[18:37] <ogra> gdm.conf for a cdd (custom debian derivative)
[18:38] <persia> (cdd is Debianese for flavour)
[18:39] <ogra> right
[18:39] <cody-somerville> Okay, we do have a cdd setup
[18:39] <persia> OK.  So, is everyone happy with changing gdm to Recommend: ubuntu-gdm-themes | gdm-theme ?
[18:40] <superm1> yeah that's fine with me
[18:40] <seb128> persia: that's basically what it's doing now
[18:40] <superm1> i'll have our theme provide that
[18:40]  * cody-somerville nods.
[18:40] <persia> This means theme providers will need to Provide: the package name.
[18:40] <seb128> persia: just not using a provide but listing alternatives
[18:40] <seb128> persia: that's going away in the new gdm anyway
[18:40] <slangasek> kirkland: so kees didn't manage to get this grub stuff uploaded before alpha-4?  I saw him working oni t
[18:40] <slangasek> on it
[18:40] <kirkland> slangasek: pitti did the upload
[18:40] <persia> seb128: Is it going away for intrepid?
[18:41] <seb128> persia: not decided yet
[18:41] <kirkland> slangasek: i think he chose to not put it in alpha-4
[18:41] <slangasek> kirkland: I don't see that an upload has happened
[18:41] <persia> seb128: Any objections to using the virtual package model for now, to br dropped later if it is decided?
[18:42] <seb128> persia: I'm not convinced it's of any use but no
[18:42] <seb128> since we list the known derivatives there already
[18:42] <superm1> seb128, it will solve the problem for all of these derivatives that don't want any of  the ubuntu normal gdm themes (and future entrants too)
[18:42] <seb128> and that's only a recommends
[18:42] <seb128> superm1: that's only a recommends, don't install it?
[18:42] <persia> seb128: Means mythbuntu and ubuntustudio don't pull ubuntu-artwork, and provides a cleaner model for ubuntume if they want to follow and we don't switch for intrepid.
[18:42] <superm1> seb128, we have CDs that it gets installed by
[18:42] <kirkland> slangasek: hmm, this is confusing....
[18:43] <superm1> seb128, during the CD build process
[18:43] <persia> seb128: recommends-by-default, no?
[18:43] <kirkland> slangasek: basically, pitti and benc had uploaded directly to grub, bypassing the bzr tree
[18:43] <kirkland> slangasek: i pinged pitti about it, and he fixed it, in retrospect
[18:43] <seb128> persia: there was some discussions about being able to list recommends which should not be on the cd
[18:43] <kirkland> slangasek: now, i'm trying to see where my code fell....
[18:44] <seb128> but anyway having a provide should not hurt either
[18:44] <slangasek> kirkland: right - he fixed the fact that things were not committed to bzr
[18:44] <slangasek> kirkland: but there's not yet an upload of your new code
[18:44] <persia> seb128: There's the possibility to blacklist stuff in the seeds, but it gets messy if someone later changes things.
[18:44] <slangasek> kirkland: so, time for me to do a final review and upload? :)
[18:44] <kirkland> slangasek: sure
[18:45] <kirkland> slangasek: https://code.launchpad.net/~kirkland/grub/33649b
[18:45] <_MMA_> seb128: There's also the issue on upgrading.
[18:45] <seb128> ok, enough noise, I'm no supposed to work today
[18:45] <cody-somerville> So....
[18:46] <cody-somerville> I'm going to upload xubuntu-default-settings now, mmkay?
[18:46] <superm1> so he is implementing it or not?
[18:48] <_MMA_> Looks like yes.
[18:48] <kirkland> slangasek: hold on....
[18:48] <kirkland> slangasek: https://code.launchpad.net/~ubuntu-core-dev/grub/ubuntu
[18:48] <kirkland> slangasek: see rev 847
[18:49] <slangasek> yes
[18:49] <slangasek> been looking there already :)
[18:49] <kirkland> slangasek: looks like it's in the branch, just didn't get pushed to the cd?
[18:49] <slangasek> it has to be uploaded as a source package to get onto the CD, yes
[18:49] <kirkland> slangasek: ah, or an upload of the source package
[18:51]  * slangasek notes that this is what he meant when he referred to "upload" above :)
[19:06] <kirkland> slangasek: gotcha.   bzr-based vcs control requires 1) push to the branch, then 2) upload of the source package...  is that the right vocabulary?
[19:06] <kirkland> s/the branch/the main branch/
[19:08] <seb128> persia: the recommend would be "gdm-themes" then? what about the gtk and icons theme?
[19:08] <persia> seb128: Does gdm need those?  I thought it only needed the gdm-theme.
[19:09] <seb128> there is a gtk theme specified in the gdm.conf too
[19:09] <persia> ubuntu-desktop depends on ubuntu-artwork anyway, so I'm not worried in that case.
[19:09] <persia> Hmm.
[19:09] <persia> superm1: ?
[19:09] <seb128> icon theme is probably not really required but it's nicer to have icons matching the theme used
[19:09] <slangasek> kirkland: yes
[19:11] <persia> seb128: I agree it ought look pretty: I'm just following comments in the bug.  On the other hand, do you imagine many cases where gdm is installed without any $(flavour)-desktop?
[19:11] <kirkland> slangasek: cool.  are you still reviewing it?
[19:11] <seb128> not really but technically the depends and recommends should get you something which doesn't complain that about the theme used in the config not being available
[19:12] <kirkland> slangasek: also, how's the pam-config-tool thingy coming?
[19:12] <slangasek> kirkland: still reviewing it; pam thingy coming late today, I believe
[19:12] <persia> seb128: Hmm.  What do you think it should be then?  ubuntu-artwork | ?
[19:12] <kirkland> slangasek: cool, thanks on both accounts.
[19:17] <_MMA_> seb128: I'm unsure why it needs anything Ubuntu-specific? Just have the Ubuntu one work the way the other flavors do.
[19:17] <persia> _MMA_: It needs a default when using a virtual package, and it makes sense to have the default be Ubuntu.
[19:18] <_MMA_> If GDM just depended on the default GNOME themes this wouldnt be an issue.
[19:18] <_MMA_> But the GDM package is changes to look for the Human theme. I dont see why it should.
[19:18] <persia> Yes, but surely it's better for Ubuntu GDM to recommend the Ubuntu gdm theme as defaiult, no?
[19:19] <_MMA_> Ubuntu GDM in what sense? The GDM package *in* Ubuntu? I think that ought to be flavor agnostic.
[19:21] <_MMA_> persia: The flavors have to override the conf in the GDM package. To me, it shouldn't have to override Human, but Circles, or whatever.
[19:23] <persia> _MMA_: Hmm.  Ubuntu Desktop isn't really set up with all the cdd stuff, so I'm not sure that would work, without rather more testing time than is available between now and FeatureFreeze.
[19:24] <_MMA_> persia: Sure. Ideally, that's how I would like it as it would cause less headache in the end for the flavors. But I realize the time constraints.
[19:56] <mvo> BenC: is bug #257162 releated to the new last-known-good kernel feature?
[19:56] <ubottu> Launchpad bug 257162 in linux "error while upgrading to linux-image-2.6.24-19.34 " [Medium,Incomplete] https://launchpad.net/bugs/257162
[19:58] <superm1> persia, seb128 i think that if other piece are needed to make a particular gdm theme work, they should be dependencies of the theme itself
[19:59] <persia> superm1: Works for me, or perhaps recommendations, depending on the urgency of having them present.
[20:02] <tkamppeter> seb128, I have good news!
[20:03] <tkamppeter> seb128, I succeeded to patch GTK so that GTK apps output PDF instead of PostScript for print jobs. The patch is very simple.
[20:04] <tkamppeter> gedit and gimp (standard print dialog, not the Gutenprint one) output PDF with the patch.
[20:06] <YokoZar> slangasek: sigsegv?
[20:06] <slangasek> YokoZar: kees has an alternative solution for wine 16-bit apps that doesn't involve reducing kernel security
[20:07] <YokoZar> oooh
[20:08] <slangasek> YokoZar: still a work in progress, and it's very evil, and it will make 16-bit apps somewhat slower; but ultimately it's a reliable solution that doesn't depend on fiddling with sysctl
[20:09] <YokoZar> slangasek: I take it that it generalizes beyond Wine then
[20:10] <slangasek> YokoZar: nothing beyond wine needs to mmap 0, AFAIK
[20:10] <YokoZar> slangasek: I believe dosbox and something else have similar problems (see Dan Kegel's post in the Wine bug report)
[20:10] <slangasek> it's not general, no - it's a sigsegv handler that would have to be added to any process that thinks it needs to access memory at address 0x0
[20:11] <slangasek> right, so the same would need to be applied to dosbox
[20:11] <emgent> evening
[20:17] <psusi> packages.ubuntu.com is doing something screwwy... am I doing something wrong or is it broken?  When I look up the linux-image-2.6.24-19-generic package in hardy and click on the list of files link it tells me "No such package in this suite on this architecture"
[20:18] <seb128> tkamppeter: can you open a bug and attach the patch there?
[20:18] <seb128> superm1: that's not the theme which depends on the gtk theme but the gdm configuration
[20:20] <superm1> seb128, then similar virtual package type things could be done i suppose, but I don't believe that gdm complains if it can't find the right gtk theme does it?  It just falls back to a known one
[20:20] <seb128> superm1: probably not but it means that a sudo apt-get install gdm would not give what the user expect
[20:23] <superm1> seb128, is that expectation actually pre-determined though?
[20:25] <seb128> superm1: what do you mean? gdm has a configuration, the expectation is to have it working when gdm is installed
[20:25] <seb128> the new gdm will make things easier since it uses gconf for its configuration
[20:25] <_MMA_> seb128: I would expect that any user at a point where they're installing GDM would be happy with a default GNOME theme like circles.
[20:27] <slangasek> tkamppeter: taking a look inside the fonts from gsfonts and ghostscript-fonts, the ones bundled in ghostscript-fonts are an earlier version of the URW fonts and should /not/ supersede the fonts from gsfonts
[20:27] <slangasek> kirkland: grub 0.97-29ubuntu35 uploaded
[20:27] <slangasek> kirkland: funny how the newer patch is simpler :)
[20:28] <_MMA_> seb128: The issue is that the default GDM package looks for Human. Not a GNOME default. This will be something I hope we can change for +1 as I know what time we have left and your workload.
[20:30] <_MMA_> Or actually, this wont be an issue in +1 because of new GDM. :)
[20:31] <seb128> _MMA_: Ubuntu users who install gdm expect to get the ubuntu theming and not the GNOME one
[20:33] <seb128> _MMA_: but right having a way to change the configuration by installation an another package would be nice
[20:33] <_MMA_> seb128: Ubuntu users that dont have GDM installed are advanced users usually installing over top of a CLI system. The can handle installing the Human theme.
[20:33] <seb128> _MMA_: or users who installed some (*)ubuntu and decide to try GNOME
[20:34] <_MMA_> Sure. Having the Human theme installed the way the flavors do would be best, but this all might be besides the point.
[20:34] <_MMA_> SInce things change in the new GDM.
[20:35] <seb128> the issue is that the current gdm config doesn't allow to set priorities for the configuration to use
[20:35] <seb128> so we just do "if extra config installed use that other use the gdm one"
[20:35] <_MMA_> All the other *buntu's use GDM besides Kubuntu and then GDM would conflict with KDM right?
[20:35] <seb128> which doesn't allow do no (*)ubuntu > ubuntu > default
[20:35] <seb128> so we have to change default
[20:36] <seb128> if we had a gdm custom config for ubuntu that would conflict with derivatives configs
[20:38] <_MMA_> But all still pointless discussing since we have a solution now and things will change yet again in the next release. :) Go enjoy your Friday evening.
[20:38] <seb128> right
[20:38] <seb128> thanks, you too ;-)
[20:42] <slangasek> GDM should not need to conflict with KDM
[20:43] <tkamppeter> seb128, will do so
[20:43] <YokoZar> slangasek: would adding some sort of code to wineserver (which translates signals into Windows exceptions) be helpful here?
[20:43] <slangasek> YokoZar: no
[20:43] <tkamppeter> slangasek, should I replace the OR dependency by a simple dependency on gsfonts then?
[20:43] <_MMA_> slangasek: Sure. I was just askin'. But wouldn't their be a issue there? What would handle logon?
[20:44] <_MMA_> If both were installed that is.
[20:44] <slangasek> tkamppeter: I'm not sure; I haven't established that all of the fonts in ghostscript-fonts are also present in gsfonts, or if some of them originate elsewhere
[20:44] <slangasek> _MMA_: there's a long-existing mechanism for deciding which one should be used, which has a debconf interface and a "sensible" default
[20:47] <_MMA_> Ahh..
[20:49] <ion_> tkamppeter: echo foo >foo; cupsfilter -m application/vnd.cups-postscript foo >/dev/null fails for me: texttopdf (PID 9462) crashed on signal 11
[20:49] <ion_> tkamppeter: I have the 1.3.8-5 debs installed from the archive.
[20:51] <BenC> mvo: checking on that bug
[20:53] <BenC> mvo: No, that bug looks like either corrupted fs, or his /boot is read-only
[20:53] <mvo> BenC: ok, thanks.
[20:53] <BenC> mvo: the error is from dpkg itself, plus it's a hardy only upgrade (nothing about intrepid in there, so no last-good-boot around)
[20:56] <ion_> tkamppeter: http://heh.fi/tmp/cups/strace.texttopdf
[21:03] <slangasek> tkamppeter: ok, the fonts that aren't present in gsfonts are Dingbats and StandardSymL; for all others, the gsfonts version should be used
[21:05] <mvo> BenC: oh, I overlooked that, thanks for clarifying
=== Seeker`_ is now known as Seeker`
[21:21] <warren> Can anybody reproduce this on firefox-3.0.1 on Ubuntu with flash-plugin-10.0.0.569?  (no nspluinwrapper)
[21:21] <warren> https://bugzilla.redhat.com/show_bug.cgi?id=459297
[21:21] <ubottu> bugzilla.redhat.com bug 459297 in firefox "Firefox crash during Flash 10 teardown" [Medium,New]
=== moquist_ is now known as moquist
[21:30] <soreiser> hi there, i would like to know why "all_generic_ide" is not working with hardy. i really need it to make my old pc working. thanks
[21:31] <soreiser> i mean the kernel string parameter
[21:31] <soreiser> it was working with 7.10 (i tried xubuntu) but it is not with ubuntu-server/ubuntu 8.04 :-/
[21:32] <soreiser> please can anyone help me out to solve this?
[21:34] <LaserJock> soreiser: have you looked for open bugs about it?
[21:34] <soreiser> LaserJock i've made a bug-report by myself but i'm not so expert so i was not sure it is a bug. is it really a bug, then?
[21:35] <LaserJock> I really have no idea
[21:35] <LaserJock> but in general it safer to report a bug than to not
[21:35] <soreiser> is there anyone here could i ask for this?
[21:35] <LaserJock> soreiser: you might also ask  #ubuntu-kernel
[21:36] <soreiser> LaserJoke ok i go there and i try to ask
[21:36] <soreiser> thanks for support, i didn't know about that channel :)
[21:42] <kirkland> slangasek: saw the grub patch applied \o/  thanks!
[21:48] <LaserJock> "LaserJoke" heh, that's a new one
[21:51] <emgent> hahah
[21:51] <emgent> heya kirkland !
[21:51] <kirkland> emgent: hiya
[21:52] <kirkland> emgent: cool video on Italy, btw, i enjoyed it
[21:53] <emgent> I was in Genova this day
[21:55] <emgent> italian police == mafia.
[22:08] <kirkland> emgent: i suppose "enjoyed" isnt the right word
[22:08] <kirkland> emgent: "informative"
[22:35] <tkamppeter> ion_, bug forwarded to the upstream author, thanks for reporting.
=== superm1 is now known as superm1|away
=== Kopfgeldjaeger is now known as Kopfi|offline
=== Kopfgeldjaeger is now known as Kopfi|offline