[00:01] <fta> no, ppa != dbgsym
[00:02] <fta> http://paste.ubuntu.com/45072/
[00:02] <asac> fta: dont you do a testcrun locally anyway? couldnt you preserve those -dbgsym for the tiome being?
[00:03] <asac> flashplayer ahoi ;)
[00:03] <asac> is that really a regression in latest firefox?
[00:03] <fta> today, i just did a minimal local test build
[00:04] <asac> fta: we need a name :(
[00:04] <asac> otherwise the 3.0.2 package will never enter intrepid :-D
[00:04] <fta> a name ?
[00:05] <asac> yeah something to replace webbrowser in 3.0.head branch;)
[00:05] <fta> oh
[00:06] <asac> i think suggestions were plain-webbrowser
[00:06] <asac> unbranded-webbrowser
[00:06] <asac> and whitebox-webbrowser (which was from me obviously ;))
[00:06] <asac> and pitti didnt mislike any of those
[00:06] <asac> plain webbrowser ... does that sound stupid?
[00:08] <asac> paranoia
[00:08] <asac> ;)
[00:08] <asac> paranoia-3.0 ;)
[00:08] <fta> unchained-browser
[00:08] <asac> hehe
[00:08] <asac> not that bad ;)
[00:09] <asac> unleashed ;)
[00:09] <asac> flying-browser ;)
[00:09] <asac> unique-webbrowser
[00:10] <asac> uni-browser ;)
[00:10] <fta> does it have to contain browser ?
[00:10] <kgoetz> *g* washed-fox
[00:10] <asac> everything else would again create a mark
[00:10] <fta> redpanda
[00:10] <asac> yeti-browser ;)
[00:11] <asac> a yeti is probably similar to an iceape ;)
[00:12] <asac> now i wonder why we (as in debian) didnt go for yeti-browser yet-mail, yeti-suite, yeti-cal ;)
[00:12] <fta> debrowser
[00:12] <asac> de like "the" ?
[00:12] <asac> or like .deb?
[00:12] <fta> like deb
[00:12] <asac> actually not that a bad idea
[00:13] <asac> just dbrowser ;)
[00:13] <fta> also the idea to remove/free
[00:13] <asac> who do you see remove/free presented in "debrowser"?
[00:14] <fta> de- privatif
[00:14] <asac> ok
[00:14] <asac> i think i know what you mean
[00:14] <fta> maybe more french than us
[00:14] <fta> dis-
[00:14] <asac> but wouldnt that more make it read like non-browser ?
[00:15] <asac> i like dbrowser
[00:15] <fta> or just brother
[00:15] <asac> especially how the d and b are mirrored ;)
[00:15] <asac> hehe
[00:16] <asac> bother ;)
[00:16] <fta> freendly
[00:16] <fta> already taken
[00:16] <asac> oh .... pitti said we need a proper noun ;)
[00:16] <asac> so bother wont fly
[00:17] <fta> rocket
[00:17] <asac> imo the name should reflect that we a) had to escape the "mark" b) couldnt use "webbrowser"
[00:17] <fta> lol
[00:18] <kgoetz> nomark-browser? :P (although it might sound like sabdfl isnt allowed to use it)
[00:18] <asac> i think debrowser or dbrowser would be a good name ;)
[00:18] <asac> kgoetz: ;)
[00:19] <asac> maybe "marked-browser ";)
[00:19] <fta> liberty
[00:19] <fta> liberated
[00:20] <asac> *sigh* how much i hate choosing names :(
[00:21] <kgoetz> asac: its bad enough when its a new computer system, let alone something other people need to like ;/
[00:21] <asac> its like banging your head against the wall. the harder you hit the more it hurts
[00:21] <kgoetz> is there a type of fox without foxy markings?
[00:22] <Jazzva> u-browser? :)
[00:22] <Jazzva> (I think I suggested that few days ago)
[00:22] <asac> kgoetz: i really dont want to create a new word that people would consider a mark when looking at it
[00:22] <fta> looks like micro to me
[00:22] <kgoetz> asac: ah, nod.
[00:22] <asac> the name should put an end on that thing
[00:23] <[reed]> asac: what's with the name choosing?
[00:23] <fta> eheh
[00:23] <[reed]> why not "firefox" ?
[00:23] <asac> [reed]: because firefox is already in use ;)
[00:23] <[reed]> what's this browser then?
[00:23] <asac> [reed]: no seriously. firefox will stay firefox ;) ... its just a branding package
[00:24] <[reed]> ah
[00:24] <fta> hm, someone referred to my ppa in there :S http://blogs.adobe.com/penguin.swf/2008/08/windowless_mode_fix.html#comment-1601061
[00:24] <asac> for those downstreams that cant or dont want to follow mozilla requirements
[00:24] <asac> further this effort helps us to fix the bug that its too hard to rebranding firefox in ubuntu
[00:25] <asac> which sometimes got thrown at us (and which is justified) when we complained about how mozilla handles trademarks ;)
[00:25] <asac> e.g. mozilla provides the --enable-branding switch
[00:25] <asac> what does debain/ubuntu provide for downstreams? not much
[00:26] <kgoetz> not sure about currently, but it used to provide a broken --enable-branding switch :P
[00:26] <asac> kgoetz: thats fixed since 2.0 afaict
[00:26] <kgoetz> asac: nod.
[00:27] <fta> bad ff3.1 taking 100% cpu after visiting a <video> page, bad red panda
[00:28] <asac> hehe
[00:28] <kgoetz> asac: so i can be sure i understand - theres goign to be a package with the bulk of 'firefox' in it, then a special package that holds the offical branding? (ala ubufox?)
[00:28] <asac> kgoetz: well. this is all not set in stone. but for now we have a package that holds everything except the branding and then two branding packages
[00:28] <asac> firefox-3.0-branding
[00:29] <asac> whateverwenamit-3.0-branding
[00:29] <asac> and meta packages to track
[00:29] <asac> firefox
[00:29] <asac> and whaeverwenamit
[00:29] <fta> younameit-browser
[00:29] <asac> kgoetz: the difficult thing is that we have two cases here
[00:29] <asac> kgoetz: 1. downstreams what clean sources
[00:30] <asac> kgoetz: 2. downstream wants clean binaries
[00:30] <asac> s/what/want/
[00:30] <kgoetz> fta: wenamedit-browser perhaps.
[00:31] <Jazzva> stripped-browser
[00:31] <asac> so when you reassemble a distro you can sync the binary packages and leave out the official branidng ones
[00:31] <asac> or  as you do, respin it
[00:31] <asac> kgoetz: i think for you the part that we have a branding by default in source package might be helpful
[00:31] <asac> kgoetz: but in general we need to make things more generic
[00:31] <asac> kgoetz: so i need your input on what you want actually
[00:33] <kgoetz> asac: i can tell you about gNS specifically, and what i'm ultimately (and slowly) trying to achieve there. a version of firefox that doesnt promote non-free software (eg, recomend you install adobe/macromedia flashplayer), and contains no non-free software. the first part is what i hope to be working on, the second part is fixed by ubuntus -nobinary packages
[00:34] <kgoetz> the promoting non-free software (and in the case of upstream source the blobs), not the artwork.
[00:34] <asac> kgoetz: the first part is already there
[00:34] <asac> kgoetz: well mostly
[00:34] <asac> kgoetz: there also is the icecat extension which we (like in ubuntu and gNS) might look into incorporating at some point
[00:35] <asac> kgoetz: anyway. the idea bout the first part is the plugin finder wizard for plugins
[00:36] <asac> kgoetz: the icecat idea is quite primitive. what you really want is our plugin finder wizard with just all the non-free stuff removed from the database
[00:36] <asac> kgoetz: on the extensions front we should look into contributing a filter feature for licenses to 3.1
[00:37] <asac> kgoetz: afaik AMO already has license information and we could leverage that somehow
[00:37] <kgoetz> asac: i've not looked at teh plugin finder wizard - is it in the main source package? (if so i can get it now and have a look)
[00:37] <asac> kgoetz: its in ubufox
[00:37] <kgoetz> *grabs a copy*
[00:39] <asac> kgoetz: if you have no flash installed, go to www.wetter.de
[00:39] <asac> if you click on the "install missing plugins ..." you should see three options: adobe, gnash, swfdec
[00:39] <asac> so thats the principal idea
[00:40] <asac> the only bad about all this (regardless of the pfs or icecat approach) is that most flash sites dont allow any of those approach to be effective
[00:40] <asac> as they use the flash detection kit
[00:40] <asac> so the final piece required is a anti-flash-detection-kit code :)
[00:41] <kgoetz> hehehe.
[00:41] <asac> kgoetz: i have part of that
[00:41] <asac> e.g. i can detect when flash-detection-kit does a probe for the kit
[00:42] <asac> what i didnt manage yet is to get the right even send to the browser instance
[00:42] <asac> so it pops up the install missing plugins ... notification
[00:42] <asac> s/for the kit/for the flash player/
[00:43] <kgoetz> i assume pfs is the plugin finder?
[00:43] <asac> yes
[00:47] <kgoetz> hm. ubufox doesnt work on lpia. i guess that or it doesnt need to be specially listed in the arches="
[00:47] <kgoetz> list
[00:47] <asac> kgoetz: it should be there
[00:47] <asac> its _all
[00:47] <asac> kgoetz: ^^
[00:48] <kgoetz> roger.
[00:48] <asac> kgoetz: bzr branch lp:ubufox; cd ubufox; sh build.sh; firefox ubufox.xpi
[00:49] <kgoetz> i'm looking at an `apt-get source` checkout
[00:49] <kgoetz> just fyi
[00:50] <asac> kgoetz: yeah. thats outdated
[00:50] <asac> kgoetz: 0.6 should have been uploaded already.
[00:50]  * kgoetz branches bzr
[00:50] <asac> anyway. the package should be good enough to get the point
[00:52] <kgoetz> bbs
[00:59] <asac> off
[00:59] <asac> night
[00:59] <kgoetz> asac: will ubufox work with FF2? i'm guessing its 3 only?
[01:00] <kgoetz> later mate
[01:10] <Jazzva> kgoetz, ubufox should work with FF2 too
[01:11] <Jazzva> (at least that's what Depends line says, I don't remember that I tested it lately in FF2)
[01:11] <kgoetz> Jazzva: cheers.
[01:11] <Jazzva> np :)
[01:12] <kgoetz> :)
[07:20] <kgoetz> fta_: \o/ nice work on motu (yeah. i'm a little behind ...)
[08:30] <asac> jtv: are all the .xpi things recovered by now?
[08:31] <asac> jtv: hi! ;)
[08:37]  * asac reboot
[08:39] <asac> hmm ... i guess that rebooting while backup is running is really a good idea ... so i'll wait a bit
[08:42] <jtv> asac: the XPI part is resolved, but now we're looking at some build problems.
[08:43] <asac> jtv: but thats not in production?
[08:44] <jtv> asac: it's not with the firefox/xulrunner stuff though
[08:44] <asac> jtv: ok. so to get it straight. the current export works and is in the "new" xpipo format?
[08:45] <asac> "new" aka new path format in the comments
[08:45] <jtv> asac: Yes
[08:45] <asac> jtv: point is that i still have to fix po2xpi and wonder if I can just grab an export and that its complete ;)
[08:46] <jtv> asac: here's a recent export you can test with: http://launchpadlibrarian.net/17397360/launchpad-export.tar.gz
[08:46]  * asac downloads
[08:47] <asac> jtv: thats just xul/ffox?
[08:47] <asac> seems quite small
[08:48] <jtv> asac: well, it's only xulrunner...  if you see anything concrete that looks like it's missing, please let me know!
[08:49] <asac> jtv: well
[08:49] <asac> jtv: its in the product export format
[08:49] <asac> jtv: which isnt compatible with po2xpi
[08:49] <asac> jtv: cant we unify those at some point?
[08:50] <asac> jtv: e.g. directory structure an file names
[08:51] <asac> jtv: anyway. on a first glance that looks good enough to adapt the bloody C code for the po2xpi transformer ;)
[08:52] <asac> but i would like to do a run against a full export before deploying those changes on rookery
[08:52] <jtv> asac: C code?  Really?
[08:52] <jtv> asac: what do you mean by "product" export format?
[08:52] <jtv> asac: you mean the directory layout?
[08:52] <asac> jtv: yes. the inner guts of po2xpi are C
[08:53] <asac> jtv: yes
[08:53] <jtv> asac: then that's because this *is* a product export.  :-)
[08:53] <asac> jtv: i know
[08:53] <asac> jtv: i wonder why we cannot unify both formats
[08:53] <asac> formats==dir-layouts
[08:54] <jtv> asac: I'd be interested in doing that, but I don't think I can give it a lot of priority.
[08:54] <asac> jtv: yeah. anyway, i cannot test the full po2xpi with product tarballs ... only the C transformer. but thats ok i think
[08:54] <asac> jtv: do the deltas contain the en-US.xpi's ?
[08:55] <asac> or are they still missing there?
[08:55] <jtv> asac: if they were missing before, I guess they still are.  Didn't know that was an issue.
[08:56] <asac> jtv: i didnt know either. just assumed that it was an issue ;)
[08:56] <asac> if the missing en-US.xpi were something else then it probably is not
[08:56] <asac> i will look later today
[08:56] <asac> jtv: thanks so far!
[08:56]  * asac reboots ;)
[08:56]  * jtv waves at asac
[11:43] <IntuitiveNipple> asac: update on LP bug #239952. The mozilla bug #444440 patch (v3) doesn't solve the issue, in fact, it makes it more confusing.
[11:43] <ubottu> Launchpad bug 239952 in xulrunner-1.9 "firefox - the associated helper application does not exist" [Medium,Confirmed] https://launchpad.net/bugs/239952
[11:43] <ubottu> Mozilla bug 444440 in File Handling "Unexpected application launched when $HOME/.mailcap contains an entry for the handled mime type" [Normal,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=444440
[11:44] <asac> IntuitiveNipple: opk thanks
[11:45] <IntuitiveNipple> I'll rework it so it can deal with both issues and post the update to the mozilla bug with the reasons for combining
[11:46] <asac> IntuitiveNipple: hmm
[11:46] <asac> IntuitiveNipple: ok.
[11:46] <asac> IntuitiveNipple: let me know when you have upped the tested patch. please try to reproduce and verify that the initial issue is still fixed
[11:47] <IntuitiveNipple> indeed :)
[11:47] <asac> IntuitiveNipple: oh. could you attach a patch on top of the v3 patch?
[11:47] <asac> and a combined if you really want
[11:47] <IntuitiveNipple> Well the v3 patch is bad so best to rework it, it hasn't been accepted yet
[11:47] <IntuitiveNipple> I'm about to post a regression update to 444440 so they know
[11:47] <asac> IntuitiveNipple: problem is that i am also responsible for security uploads in debian and the debian xulrunner maintainer who did that patch doesnt use a patch system
[11:48] <asac> so if the patch that he applied lands in a modified way i will have issues doing the security update
[11:48] <asac> IntuitiveNipple: but well. in the end i dont mind
[11:49] <asac> i already stepped down from xulrunner security releases because the maintainer doesnt have a path system anymore
[11:49] <asac> so go ahead
[11:49] <IntuitiveNipple> ahhh
[11:50] <IntuitiveNipple> okay, well I'll do it both ways then :)
[11:50] <IntuitiveNipple> get it working properly first, based on that patch, then produce a clean patch for upstream and a patch-on-patch for debian/ubuntu ?
[11:51] <IntuitiveNipple> If the canonical sysadmins would get off their fannies and simply correct the Content-Type settings in apache/zope, we'd be happy!
[12:10] <pmatulis> asac: weird stuff, after reproducing the "bug" 6 consecutive times, another 4 consecutive times do *not* exhibit it
[12:11] <IntuitiveNipple> asac: the solution to the LP bug is simply to 'remember' the helper chosen by the user, and use it in nsMIMEInfoBase/nsMIMEInfoUnix. From your knowledge of the code, do you foresee any issues if I implement it so that the 'chosen' helper is passed through to them, rather than them figuring out which to use independently? (thinking, make the system-default case the same as the user-chosen rather than rely on flags and duplicating t
[12:11] <IntuitiveNipple> he same discovery technique as the helper-chooser dialog)
[12:15] <asac> IntuitiveNipple: cant tell without actually looking at the patch
[12:16] <asac> IntuitiveNipple: sounds like its reasonable, but if it changes order/preference it might cause other issues
[12:16] <IntuitiveNipple> okay... don't worry about it... was just trying to avoid myself doing something counter to the intention of the original code :)
[12:16] <asac> IntuitiveNipple: well. the original code is buggy
[12:17] <IntuitiveNipple> It does seem daft though, asking the user to confirm the helper and then, later when the download is complete, using a totally different method to determine the helper :)
[12:17] <asac> so most likely a cleanup is needed. however, i cant forsee what upstream thinks. they sometimes have wierd attitudes
[12:17] <asac> IntuitiveNipple: if thats the case then it needs to be fixed
[12:17] <IntuitiveNipple> Let me be clear then - that v3 patch is in debian already (and presumably going to land in ubuntu) ?
[12:17] <asac> IntuitiveNipple: as long as the initial helper selection still uses the mailcap/gnomevfs/user-pref way it should be fine
[12:17] <asac> IntuitiveNipple: no
[12:18] <asac> IntuitiveNipple: nothing that is in debian gets to ubuntu usually
[12:18] <asac> IntuitiveNipple: because the debian maintainer does a good job of hiding his patches and i dont bother to run after him
[12:18] <IntuitiveNipple> asac: agreed, my idea is to just propagate the initial choice (whether it be 'user' or 'default').
[12:18] <IntuitiveNipple> I see... okay, that makes sense then
[12:18] <asac> IntuitiveNipple: so whatever you develop i will look at and if thats good get that into upstream
[12:19] <asac> and into ubuntu
[12:19] <IntuitiveNipple> yeah.. so I'll work from upstream and worry about that v3 patch later then
[12:19] <asac> IntuitiveNipple: dont worry about that patch. if it also fixes the issue v3 addresses its fine
[12:19] <IntuitiveNipple> Thanks... I'l let you know when the new patch is done.
[12:19] <asac> but not needed
[12:19] <asac> the issue you are after is more important
[12:20] <asac> IntuitiveNipple: you could look at debian changelog
[12:20] <asac> maybe he already has a patch for that
[12:20] <asac> which we didnt find in bugzilla
[12:20] <IntuitiveNipple> asac: right, will do
[12:20] <asac> i somehow doubt that he didnt see this bug
[12:20] <asac> while he worked on the other
[12:20]  * IntuitiveNipple thinks to himself, why would someone not use a patch system!?
[12:20] <asac> IntuitiveNipple: because he wants to stop ubuntu leeching on him
[12:20] <IntuitiveNipple> (rhetorical question, no answer required!)
[12:21] <asac> i dont bother ...e xcept that he kills the ability for me to provide security support in debian
[12:21] <asac> which de-facto means that debian will have no security support
[12:21] <IntuitiveNipple> kinda defeats the purpose of open-source really, doesn't it?
[12:21] <asac> IntuitiveNipple: well. his pov is probably that ubuntu does the same :)
[12:21] <asac> for all the other packages
[12:21] <asac> IntuitiveNipple: his official argument is that he can better do it in git
[12:22] <asac> which is a private git unfortunately
[12:22] <asac> IntuitiveNipple: and even then its completely unfeasible as long as you dont maintain topic-branches per patch
[12:22] <asac> mozilla accumulates a bunch of patches that interleave
[12:22] <asac> and figuring out later where you did a merge error is cumbersome
[12:22] <asac> but well
[12:22] <asac> i accepted that its that way ;)
[12:23] <IntuitiveNipple> Well, yes, I agree with the git statement (I important all source packages into git locally) *but* I use it to create the debian patches, by working in a test branch and then simply creating the debian patch with git-diff master >debian/patches/lpxxxxx.patch :)
[12:23] <IntuitiveNipple> s/I important/I import/
[12:23] <asac> IntuitiveNipple: git is ok if the package will have no long-lasting patches
[12:23] <asac> e.g. you can develop in git, even commit there
[12:23] <asac> as long as  either thats just a few patches or you submit it upstream and can backout on next sync
[12:24] <asac> but thats usualyl not the case. especially when the security-backports happen
[12:24] <IntuitiveNipple> I do all patching outside of master, as debian/patches/* - git actually makes the process easier!
[12:24] <asac> IntuitiveNipple: thats good ;)
[12:24] <IntuitiveNipple> also means I can cherry-pick commits or individual files from commits, really easily
[12:25] <asac> IntuitiveNipple: i use topic branches for "large" feature patches
[12:25] <asac> otherwise i just use quilt
[12:26] <IntuitiveNipple> I generally do a git-reset --soft HEAD^; edit; git-commit -a -C ORIG_HEAD; build_test process and when it works I do git-checkout debian-package (the branch), git-diff master..lpXXXXXX >debian/patches/lpXXXXXX.patch ...
[12:27] <IntuitiveNipple> and then update changelog and the patch control file, whatever system it uses, and then commit to the debian-package branch
[12:28] <IntuitiveNipple> makes debugging a wide variety of packages much easier, especially when it is over an extended time-period and I'm liable to forget what was going on
[12:30] <IntuitiveNipple> right, I'll stop bothering you until the patch is ready! I'm back off to slave over the soldering iron :)
[13:44] <hateball> Hello... I can see that status is undecided for https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/230011 but is there any chance a fix will be out soon?
[13:44] <ubottu> Launchpad bug 230011 in firefox "[HARDY] Firefox print failure, default papersize erroneously Letter in German install" [Undecided,New]
[13:45] <hateball> Actually... it's all Non-US installs
[15:39] <asac> fta_: Jazzva: there?
[15:40] <Jazzva> asac, yep
[15:41] <asac> fta_: Jazzva: after name discussion and a few more roundtrips we came to abrowser :)
[15:41] <Jazzva> good enough :)
[15:41] <asac> fta_: Jazzva: unless someone has any real objections i would take it ;)
[15:42] <asac> most likely we wont find anything better :(
[15:42] <Jazzva> well... maybe a-browser would be more readable
[15:42] <Jazzva> though, i'm still voting for u-browser :)
[15:42] <asac> Jazzva: this was turned down because of ubuntu
[15:43] <Jazzva> ah.. ok
[15:43] <asac> dbrowser was turned down because of debian
[15:43] <asac> even though ubrowser could mean unbranded browser and dbrowser "debranded"
[15:43] <asac> but well
[15:43] <Jazzva> stripped-browser :)
[15:43] <asac> ok. so no real objection from you ;)
[15:43] <Jazzva> nope :)
[15:44] <asac> kgoetz: ^^
[15:44] <Jazzva> btw, my provider decided to double d/u speed today :). 2048/256 at the moment :)
[15:45] <Jazzva> == faster pushes to bzr ;)
[15:46] <Kamping_Kaiser> asac, i cant think of a better name, if that helps ;) (so, no objection from me)
[15:53]  * Kamping_Kaiser -> bed
[16:02] <asac> Kamping_Kaiser: night
[16:02] <asac> thanks
[16:02] <Jazzva> asac, so it's official name?
[16:03] <asac> Jazzva: most likely. I am waiting for fta as well
[16:03] <Jazzva> mhm... i'll twitter it ;)
[16:06] <asac> Jazzva: if you blog or do anything about it, better wait till its final
[16:06] <asac> and get the facts right ;)
[16:06] <Jazzva> sure :)
[16:06] <asac> dont make it appear that we "rename" firefox
[16:06] <Jazzva> that's why I asked...
[16:07] <asac> its just that we provide a branding package
[16:26] <asac> @time
[16:26] <ubottu> Current time in Etc/UTC: September 10 2008, 15:26:14 - Next meeting: Ubuntu Mobile Team in 20 hours 33 minutes
[16:27] <armin76> asac: tested tracemonkey?
[16:27] <asac> no not yet
[16:28] <asac> @time
[16:28] <ubottu> Current time in Etc/UTC: September 10 2008, 15:28:09 - Next meeting: Ubuntu Mobile Team in 20 hours 31 minutes
[16:28] <asac> sorry. i am in meeting and unsure whether i am disconnected ;)
[16:28] <asac> so i use this as a ping :)
[16:29]  * armin76 kicks asac 
[16:29]  * armin76 kicks asac 
[16:29] <asac> armin76: you could also be my pingee
[16:29] <asac> ;)
[16:29]  * armin76 kicks asac 
[16:29] <asac> armin76: ping
[16:29] <asac> hehe
[16:29] <armin76> bumb
[16:37] <fta2> asac, ok for me too
[16:37] <asac> cool
[16:38] <asac> then we all the votes we need - finally :/
[16:59] <armin76> asac: bumb
[17:16] <asac> fta2: maybe https://bugs.edge.launchpad.net/ubuntu/+source/fontconfig/+bug/243130 is your lcd issue?
[17:16] <ubottu> Launchpad bug 243130 in fontconfig ""/etc/fonts/conf.d/53-monospace-lcd-filter.conf", line 17: invalid constant used : lcdfilterlegacy" [Low,Confirmed]
[17:16] <asac> but most likely its not
[17:28] <fta2> asac, it's kind of old
[17:32] <fta2> no it's not the one. the current problem is within cairo, lcd filter regressed upstream compared to our patch
[17:33] <asac> ok ... off travelling  bbiw
[21:47] <Jazzva> fta_, one telecommunication question... any good advice how to remember/learn all those error probabilities? :)
=== fta_ is now known as fta
[23:16] <fta> Jazzva, hm, what ?
[23:55] <Jazzva> fta, for example probability of wrongly transmitted bit, or energy of noise, or ... something like that... :)