=== cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk]  has joined #ubuntu-devel
=== cjwatson_ is now known as cjwatson
=== jml [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net]  has joined #ubuntu-devel
[12:43] <slangasek> cjwatson: but any indication yet what's deleting /etc/papersize?
[12:45] <cjwatson> slangasek: that would be ubiquity
[12:45] <cjwatson> I knew about *that* bit
[12:45] <slangasek> oh, ok
[12:45] <cjwatson> the question was why it wasn't getting restored, but it turns out the libpaper maintainer switched everything over to use ucf and I didn't notice] 
[12:45] <cjwatson> and ucf honours config file deletions
[12:45] <mathiaz> is the samba package installed on the livecd ?
[12:46] <cjwatson> mathiaz: http://cdimage.ubuntu.com/daily-live/current/ see the manifest files
[12:46] <mathiaz> cjwatson: thanks
[12:46] <cjwatson> slangasek: (ubiquity is just taking a preconfigured live filesystem and copying it, so it has to resort to some pretty nasty hacks to get everything properly configured afterwards)
[12:47] <slangasek> cjwatson: so the earlier behavior was that libpaper would recreate /etc/papersize unconditionally?
=== davmor2 [n=davmor2@82-47-39-199.cable.ubr04.wolv.blueyonder.co.uk]  has left #ubuntu-devel [] 
[12:47] <cjwatson> slangasek: right
[12:48] <cjwatson> the new behaviour is clearly more correct, or at any rate more consistent with dpkg
[12:48] <LaserJock> cjwatson: how long has this bug been around?
[12:49] <slangasek> well, libpaper1 seems to have been using ucf since etch at least
[12:49] <cjwatson> not entirely sure, just going to check
[12:49] <cjwatson> it's been using ucf for ages, but differently
[12:49] <slangasek> ok
[12:49] <cjwatson> in fact, I only wrote the code in ubiquity to configure /etc/papersize at all in early gutsy, so it can't have been long
[12:49] <cjwatson> and I know it worked then
[12:50] <LaserJock> what's the bug # for this, I got a few MOTU Science bugs that sound like dups
[12:50] <cjwatson> except I may have been on steaming crack, because the postinst hasn't changed since feisty
[12:51] <cjwatson> anyway, feisty didn't fiddle with papersize at all in desktop CD installs, so it can't have been any worse than that there
[12:52] <cjwatson> LaserJock: bug 104160 for feisty's lack of configuration; bug 128258 for the bug in how I did it in gutsy
[12:52] <ubotu> Launchpad bug 104160 in ubiquity "/etc/papersize incorrecly configured" [Medium,Fix released]  https://launchpad.net/bugs/104160
[12:52] <ubotu> Launchpad bug 128258 in ubiquity "/etc/papersize is not created" [High,Fix committed]  https://launchpad.net/bugs/128258
=== TomB_ [n=tomb@host86-145-195-250.range86-145.btcentralplus.com]  has joined #ubuntu-devel
=== tonyy [n=anthony@ubuntu/member/tonyyarusso]  has joined #ubuntu-devel
=== charlieS [i=charlie@serenity.cat.pdx.edu]  has left #ubuntu-devel [] 
=== PriceChild [n=pricechi@ubuntu/member/pdpc.supporter.student.PriceChild]  has joined #ubuntu-devel
=== l_ [n=l_@mix.mmjgroup.com]  has joined #ubuntu-devel
[01:26] <LaserJock> man these indexing services sure do chew up disk space. strigi is taking up 25% of my ~/
[01:32] <sladen> ...and only 75% of your CPU
=== bigon [i=bigon@ubuntu/member/bigon]  has joined #ubuntu-devel
[01:33] <ajmitch> that's a bit much
[01:46] <ion_> mvo: compiz fails to start now: Comparing resolution (1680x1050) to maximum 3D texture size (512): Failed.
[01:46] <ion_> Whoops, hes gone.
=== j_ack [n=j_ack@p508D80B1.dip0.t-ipconnect.de]  has joined #ubuntu-devel
=== tkamppeter [n=till@bl8-117-95.dsl.telepac.pt]  has joined #ubuntu-devel
=== mbiebl_ [n=michael@e180074129.adsl.alicedsl.de]  has joined #ubuntu-devel
=== j_ack_ [n=j_ack@p508D80B1.dip0.t-ipconnect.de]  has joined #ubuntu-devel
=== cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk]  has joined #ubuntu-devel
=== Jucato [n=jucato@124.106.176.60]  has joined #ubuntu-devel
=== printk [n=jayson@cpe-76-185-237-217.tx.res.rr.com]  has joined #ubuntu-devel
=== johanbr [n=j@blk-137-105-82.eastlink.ca]  has joined #ubuntu-devel
=== stub [n=stub@tetkyo012094.tkyo.te.ftth2.ppp.infoweb.ne.jp]  has joined #ubuntu-devel
=== rbrunhuber [n=Miranda@highway.mvi.de]  has joined #ubuntu-devel
=== zul_ [n=chuck@mail.edgewater.ca]  has joined #ubuntu-devel
[02:44] <calc> anyone seen this happen recently?
[02:44] <calc> Unpacking liba52-0.7.4 (from .../liba52-0.7.4_0.7.4-11_amd64.deb) ...
[02:44] <calc> Segmentation fault (core dumped)
[02:45] <calc> it seems to segfault on unpacking for any package
[02:45] <zul> uh...yeah i think there was a change to dpkg yesterday or something
[02:46] <calc> ah yea it was a bad apt version apparently
[02:46] <calc> i manually dpkg installed ubuntu10 and it fixed the issue
=== j_ack_ [n=j_ack@p508D80B1.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[02:47] <mjg59> Hm. The DVD playback experience is astonishingly poor.
[02:47] <mjg59> 1) Insert DVD
[02:47] <mjg59> 2) Get obscure error
[02:47] <mjg59> 3) Try playing it again
[02:47] <mjg59> 4) Get link to website that tells me to install codecs I already have installed
=== jsgotangco [n=JSG@ubuntu/member/jsgotangco]  has joined #ubuntu-devel
[02:48] <mjg59> Even running totem --debug doesn't give me any feedback
=== pkern [n=pkern@debian/developer/pkern]  has joined #ubuntu-devel
[02:51] <pkern> Hi there. Does anyone know if encrypted filesystems got implemented into gutsy's d-i?
[02:53] <cjwatson_> pkern: yeah, it's basically there, just needs a few more bug fixes; I only fixed cryptsetup to actually have the right library linkage for d-i today so I haven't had time to QA partman-crypto
=== cjwatson_ is now known as cjwatson
[02:54] <cjwatson> and by today, I mean since the last daily build
[02:54] <pkern> cjwatson: So it's broken in current tribe but will be fixed for Gutsy?
[02:54] <cjwatson> yes to the former, probably to the latter
[02:55] <pkern> cjwatson: Current build is 20070919.1. So from your side only QA on partman-crypto is lacking and it's possible that it works? If so I will try it out later.
[02:56] <cjwatson> pkern: I'm aware of what the current build is, since I built it
[02:56] <cjwatson> pkern: tomorrow's build should be interesting to test
[02:56] <pkern> cjwatson: Sorry, I thought they get built automatically. (:
[02:57] <cjwatson> they do except when they fail and one of us admins goes and pokes them
[02:58] <cjwatson> we had some network fun with cdimage's private archive mirror
[02:59] <pkern> cjwatson: Is the `.1' extension coming from the manual build?
[03:01] <cjwatson> yes, second and subsequent builds on any given day get that
[03:01] <cjwatson> the first build failed but we don't reuse the number because it corresponds to the log file
[03:01] <cjwatson> (sometimes I cheat and forcibly reuse numbers when I know they really don't matter, but I didn't bother in this case)
[03:02] <pkern> Ok, so I jigdo the current build and wait for the one built tomorrow?
[03:02] <pkern> (Or as in `later today'.)
[03:03] <pkern> (It's a bit bad that they are oversized as I want to try them out on a real machine.)
[03:03] <cjwatson> about six hours I guess
[03:03] <cjwatson> there are fixes for (at least most of) the oversizing in the pipeline
=== Shely [n=Sea@221.201.63.20]  has joined #ubuntu-devel
[03:17] <lamont> slangasek: btw, expect is very ugly code.  just FYI and all that.
=== lamont heads home, afk for an hour
=== jack_wyt_ [n=jack@123.115.242.154]  has joined #ubuntu-devel
[03:26] <slangasek> lamont: yes, I've seen that it build-depends on tcl8.4, no need to tell me :)
=== calc [n=ccheney@conr-adsl-209-169-124-200.consolidated.net]  has joined #ubuntu-devel
=== minghua [i=minghua@ubuntu/member/minghua]  has joined #ubuntu-devel
=== jdong [n=root@ubuntu/member/jdong]  has joined #ubuntu-devel
=== j_ack [n=j_ack@p508D80B1.dip0.t-ipconnect.de]  has joined #ubuntu-devel
=== slangasek [i=vorlon@dsl093-039-086.pdx1.dsl.speakeasy.net]  has joined #ubuntu-devel
=== jdong [n=root@ubuntu/member/jdong]  has joined #ubuntu-devel
=== minghua [i=minghua@ubuntu/member/minghua]  has joined #ubuntu-devel
=== tonyyarusso [n=anthony@ubuntu/member/tonyyarusso]  has joined #ubuntu-devel
=== bluekuja_ [n=andrea@host104-235-dynamic.1-79-r.retail.telecomitalia.it]  has joined #ubuntu-devel
=== IntuitiveNipple [n=TJ@alexandros.tjworld.net]  has joined #ubuntu-devel
=== gnomefreak [n=gnomefre@ubuntu/member/gnomefreak]  has joined #ubuntu-devel
=== asac [n=asac@debian/developer/asac]  has joined #ubuntu-devel
=== rnorwood [i=rnorwood@nat/redhat/x-eb5455a56bf6e30a]  has joined #ubuntu-devel
=== dAndy [i=dandy@serenity.cat.pdx.edu]  has joined #ubuntu-devel
=== pkl_ [n=phillip@unaffiliated/pkl/x-764568]  has joined #ubuntu-devel
=== Adri2000 [n=adri2000@ubuntu/member/adri2000]  has joined #ubuntu-devel
=== asw [n=asw@karuna.med.harvard.edu]  has joined #ubuntu-devel
=== stgraber [n=stgraber@ubuntu/member/stgraber]  has joined #ubuntu-devel
=== Martinp23 [n=martinp2@wikimedia/Martinp23]  has joined #ubuntu-devel
=== azeem [n=mbanck@ppp-88-217-38-77.dynamic.mnet-online.de]  has joined #ubuntu-devel
=== gouki [n=gouki@ubuntu/member/gouki]  has joined #ubuntu-devel
=== StevenK [n=stevenk@14.5.233.220.exetel.com.au]  has joined #ubuntu-devel
=== dobey [n=dobey@ip68-229-101-154.hr.hr.cox.net]  has joined #ubuntu-devel
=== caci_ [i=sk@andariel.informatik.uni-erlangen.de]  has joined #ubuntu-devel
=== pbn [i=pbn@wopr.geekshells.org]  has joined #ubuntu-devel
=== c1|freaky [i=alpha@team.code-1.de]  has joined #ubuntu-devel
=== siretart [i=siretart@ubuntu/member/siretart]  has joined #ubuntu-devel
=== RAOF [n=chris@123-243-65-41.tpgi.com.au]  has joined #ubuntu-devel
=== ion_ [i=ion@heh.fi]  has joined #ubuntu-devel
=== ccm [n=damokles@lilith.spinnenwerk.de]  has joined #ubuntu-devel
=== jrib [n=jrib@upstream/dev/jrib]  has joined #ubuntu-devel
=== mneptok [n=mneptok@canonical/support/mneptok]  has joined #ubuntu-devel
=== sbalneav [n=sbalneav@S0106000b6a5631f9.wp.shawcable.net]  has joined #ubuntu-devel
=== DreamThief [n=mathias@unaffiliated/dreamthief]  has joined #ubuntu-devel
=== paran [n=paran@cl-56.sto-01.se.sixxs.net]  has joined #ubuntu-devel
=== fdoving [n=frode@ubuntu/member/frode]  has joined #ubuntu-devel
=== geser [i=mb@ubuntu/member/geser]  has joined #ubuntu-devel
=== fnordus [n=dnall@24.84.160.227]  has joined #ubuntu-devel
=== sjoerd [n=sjoerd@tunnel3460.ipv6.xs4all.nl]  has joined #ubuntu-devel
=== Ng [n=cmsj@mairukipa.tenshu.net]  has joined #ubuntu-devel
=== Nafallo [n=nafallo@ubuntu/member/nafallo]  has joined #ubuntu-devel
=== syp|_ [n=syp@lasigpc9.epfl.ch]  has joined #ubuntu-devel
=== AndyP [n=andyp@ubuntu/member/welshbyte]  has joined #ubuntu-devel
=== Treenaks [n=martijn@thuis.foodfight.org]  has joined #ubuntu-devel
=== Toadstool [n=jcorbier@ubuntu/member/toadstool]  has joined #ubuntu-devel
=== sladen [i=paul@193.28.45.41]  has joined #ubuntu-devel
=== \sh_away [n=nnsherma@server3.servereyes.de]  has joined #ubuntu-devel
=== Mirv [n=tajyrink@pdpc/supporter/active/Mirv]  has joined #ubuntu-devel
=== Traxer [i=traxer@shell6.powershells.de]  has joined #ubuntu-devel
=== smurf [n=smurf@debian/developer/smurf]  has joined #ubuntu-devel
=== tritium [n=tritium@ubuntu/member/tritium]  has joined #ubuntu-devel
=== Riddell [i=jr@kde/jriddell]  has joined #ubuntu-devel
=== [PUPPETS] Gonzo [i=gonzo@80.69.47.16]  has joined #ubuntu-devel
=== bytee [n=byte@pentafluge.infradead.org]  has joined #ubuntu-devel
=== maswan [i=maswan@kennedy.acc.umu.se]  has joined #ubuntu-devel
=== jvw [i=jeroen@220pc220.sshunet.nl]  has joined #ubuntu-devel
=== lool [i=lool@debian/developer/lool]  has joined #ubuntu-devel
=== Gman [i=gman@nat/sun/x-63524b66ad8d9dbf]  has joined #ubuntu-devel
=== fnordus [n=dnall@24.84.160.227]  has joined #ubuntu-devel
=== tehk [n=tehk@c-69-249-157-157.hsd1.nj.comcast.net]  has joined #ubuntu-devel
=== holymoo [n=start@S01060016b6b53675.vf.shawcable.net]  has joined #ubuntu-devel
=== jtt [n=jtholmes@198.211.210.130]  has joined #ubuntu-devel
=== slangasek [i=vorlon@dsl093-039-086.pdx1.dsl.speakeasy.net]  has joined #ubuntu-devel
=== macd [n=d@cl-151.ewr-01.us.sixxs.net]  has joined #ubuntu-devel
[04:59] <cjwatson> hmm, that's an interesting idea
[04:59] <cjwatson> Vista's alt-tab handler includes the desktop as one of the "windows", and alt-tabbing to that minimises everything else
[05:02] <kylem> cjwatson, they probably patented that.
=== jdong laughs
[05:03] <jdong> and the pessimistic-outlook-on-features award goes to.... :)
[05:03] <mneptok> kylem: no, they just patented key combinations and went with the umbrella strategy
[05:03] <johanbr> I'm going to patent the concept of "bug". After that, Microsoft will be in for a world of hurt.
[05:04] <jdong> but anyway, yeah, cjwatson, that was one of the cooler things I noticed about vista too
[05:04] <jdong> apart from having an amazingly rock-solid filesystem against even the worst hard-reset scenarios.
[05:05] <mneptok> uh.
[05:05] <mneptok> it's NTFS, right?
[05:05] <kylem> transactional ntfs, yes.
[05:05] <jdong> yes
[05:05] <jdong> transational ntfs
=== jdong whines... when is linux gonna get an atomic filesystem?
=== EliasAmaral [n=dark@unaffiliated/EliasAmaral]  has joined #ubuntu-devel
[05:08] <mjg59> atomicity is difficult if you want a filesystem that's actually useful
[05:08] <mneptok> jdong: hint: a cow with a bra and eyliner is not a supermodel.
[05:09] <jdong> mneptok: you promised to lay down on the Oprah jokes....
[05:09] <jdong> back on topic, shows my ignorance then... I guess I just want something that stands up better to rough treatment
[05:10] <mneptok> jdong: i made no promises vis-a-vis Starr Jones
=== moquist [n=safe@pool-70-109-151-8.cncdnh.east.verizon.net]  has joined #ubuntu-devel
=== lando__ [n=lando@adsl-074-236-035-138.sip.mia.bellsouth.net]  has joined #ubuntu-devel
=== Knightlust [n=dax@ubuntu/member/knightlust]  has joined #ubuntu-devel
=== mdomsch [n=mdomsch@cpe-70-124-62-55.austin.res.rr.com]  has joined #ubuntu-devel
=== poningru` [n=poningru@ip24-250-142-109.ga.at.cox.net]  has joined #ubuntu-devel
=== lando [n=lando@adsl-074-236-035-138.sip.mia.bellsouth.net]  has joined #ubuntu-devel
=== shaya [n=spotter@pool-71-191-93-76.washdc.fios.verizon.net]  has joined #ubuntu-devel
[05:38] <shaya> any good reason why deskbar forces tracker to be installed?
[05:38] <shaya> one can want deskbar w/o the desktop search elements.  For instance, tracker is killing my PM-1.8ghz 2GB laptop
[05:42] <shaya> nevermind, I see what happened
[05:42] <shaya> it can be uninstalled
[05:42] <shaya> w/o removing deskbar applet
[05:44] <poningru> lol
=== loopylouie [i=loopylou@58.107.119.33]  has joined #ubuntu-devel
[05:50] <loopylouie> wassup
=== loopylouie [i=loopylou@58.107.119.33]  has left #ubuntu-devel [] 
=== DShepherd [n=dwight@72.252.133.113]  has joined #ubuntu-devel
=== DShepherd cheers on the ubuntu devs 
[05:52] <DShepherd> Just felt like saying thanks for all the hardwork you guys (and girls) do
[05:52] <DShepherd> no.. back to work!! :-)
[05:52] <DShepherd> now*
=== defcon [n=ion@71-36-162-68.phnx.qwest.net]  has joined #ubuntu-devel
=== stdin [i=stdin@pdpc/supporter/active/stdin]  has joined #ubuntu-devel
=== jetscreamer [n=jetscrea@unaffiliated/jetscreamer]  has joined #ubuntu-devel
[06:19] <mjg59> I've reverted the freetype, xft and cairo changes - the results were clearly worse than originally, and the code is basically unnecssary given the bytecode interpreter (which we use)
=== mkyo [i=hidden-u@218-251-52-59.eonet.ne.jp]  has joined #ubuntu-devel
[06:28] <desrt> mjg59; know anything about synaptic touchpads?
[06:29] <mjg59> desrt: Yes. Why?
[06:29] <desrt> i want to get a raw dump of events from the kernel... i only care about the hardware button
[06:29] <desrt> but since the touchpad is in software mode nothing is showing on the event devices
[06:29] <mjg59> You can't get a raw dump
[06:29] <desrt> crud :(
[06:30] <mjg59> Why do you want to?
[06:30] <desrt> i have this odd bug where ButtonRelease events often don't get delivered until the next mouse event
[06:30] <desrt> trying to decide what kind of an issue it is
[06:30] <mjg59> On Apple?
[06:30] <desrt> ya
[06:30] <mjg59> That's not a synaptics pad
[06:30] <desrt> oh.  ok
[06:30] <mjg59> Check the appletouch driver
[06:30] <desrt> well, [generic software pad] 
[06:31] <mjg59> I suspect the problem is it failing to sync the input events properly until it receives another event
[06:31] <desrt> ah... like the driver has it in its queue and is looking to match it up with another
=== desrt guessed it was occasionally dropping interrupts
[06:32] <mjg59> Yeah
=== desrt tries to find debugging support
[06:32] <mjg59> There's an input_sync() function that needs to be called
[06:32] <desrt> this appears to operate outside of the normal input device framework, though
[06:32] <desrt> it's not generating anything on /dev/input/event*
[06:32] <mjg59> No, it's a perfectly normal input device
[06:33] <desrt> not even anything on /dev/input/mice ...
[06:35] <desrt> ok.  i can see the events if i kill X.  i guess it's eating up all the events before i can get to them or something
[06:35] <desrt> it's not an X bug in any case
[06:42] <desrt> the place where it reports the button press is followed immediately by a sync
[06:44] <mjg59> Then maybe it's not getting the button up event for some reason?
[06:44] <desrt> if or if not the left button is pressed appears to be decided by a bit that is always sent on every event
[06:45] <desrt> so even if no explicit "button release" was sent it would still give a button release event as a matter of course as part of the next event
[06:45] <mjg59> If you haven't touched it for a while, we make it stop sending events
[06:45] <desrt> so it may not be like something getting stuck in the queue so much as disappearing
[06:48] <desrt> do you guys do that usb-autosuspend thing these days?
[06:49] <mjg59> No
[06:50] <desrt> the autosuspend file has '2' in it
[06:50] <mjg59> Possibly the logic in the pad reset is wrong
[06:50] <desrt> in any case it makes no difference... i still get it even when it is 0
[06:50] <mjg59> Oh, yeah, it's in the current binaries
[06:50] <mjg59> I suspect that you want to look at the idlecount block
[06:50] <mjg59> And not go into that if the mouse button is currently held down
[06:51] <desrt> the schedule_work thing?
[06:52] <mjg59> The block surrounding that, yes
[06:52] <desrt> tricky
[06:52] <mjg59> The current logic is "If we haven't had an x or y event for 10 packets, ask the pad to stop sending"
[06:52] <desrt> ok.  lemme hammer out a patch
[06:52] <desrt> brb
[06:52] <mjg59> Which probably ought to be "If we haven't had an x or y event and the button isn't down, ask the pad to stop sending"
[06:53] <sladen> ...might be more robust
=== `anthony [n=anthony@ekorp-60-242-130-196.eoff.ekorp.com]  has joined #ubuntu-devel
=== lucky_lucas [n=lucas@154-131.1-85.cust.bluewin.ch]  has joined #ubuntu-devel
=== holymoly [n=start@S01060016b6b53675.vf.shawcable.net]  has joined #ubuntu-devel
=== Hobbsee [n=Hobbsee@ubuntu/member/hobbsee]  has joined #ubuntu-devel
=== Igorot [n=dax@ubuntu/member/knightlust]  has joined #ubuntu-devel
[07:05] <desrt> mjg59; ok.  fixed
[07:05] <desrt> take a look at https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/141132
[07:05] <ubotu> Launchpad bug 141132 in linux-source-2.6.22 "[gutsy]  strange freeze-up until mouse moves" [Undecided,New] 
[07:07] <desrt> tbh: not really sure why i decided to keep button_down as state... would probably work the other way, too
[07:11] <mjg59> desrt: Hm, I don't think that's quite right
[07:11] <desrt> too much conditionalised?
[07:11] <mjg59> We want to stop reporting the fingers even if the button is pressed
[07:11] <desrt> right
[07:12] <desrt> think i should get rid of the state in the struct atp too?
[07:12] <mjg59> Yeah, easier to just check the bit
[07:12] <desrt> btw: idlecount is never reset to 0 except in the reinit handler
[07:12] <mjg59> I think just add the button check to the                 if (atp_is_geyser_3(dev)) {
[07:12] <desrt> is that a bug?
[07:12] <mjg59> Right, that's arguably a bug :)
[07:13] <desrt> k.  i'll fix that too :p
[07:13] <mjg59> Sleep now.
[07:13] <desrt> nite
=== XSource [n=XSource@41.201.224.148]  has joined #ubuntu-devel
=== _nand_ [n=ec4@129.202-128-194.unknown.qala.com.sg]  has joined #ubuntu-devel
=== nags [n=nags@125.16.129.16]  has joined #ubuntu-devel
=== dholbach [n=daniel@i59F76FD5.versanet.de]  has joined #ubuntu-devel
=== pitti [n=pitti@ubuntu/member/pitti]  has joined #ubuntu-devel
[07:32] <dholbach> good morning
[07:32] <dholbach> can somebody get gutsy-wallpapers out of new?
[07:33] <pitti> Good morning
[07:33] <pitti> dholbach: o/
=== dholbach hugs pitti
[07:34] <dholbach> ROCK ON :)
[07:34] <StevenK> Morning pitti
[07:34] <pitti> hey StevenK
[07:34] <dholbach> hey StevenK
=== maikmerten [n=chatzill@ls5appsrv05.cs.uni-dortmund.de]  has joined #ubuntu-devel
[07:42] <ajmitch> hey dholbach, pitti
[07:43] <dholbach> heya ajmitch
=== Lutin [n=Lutin@dunnewind.net]  has joined #ubuntu-devel
=== mr_pouit [n=mrpouit@ubuntu/member/mrpouit]  has joined #ubuntu-devel
=== Lutin_ [n=Lutin@dunnewind.net]  has joined #ubuntu-devel
=== Lutin [n=Lutin@dunnewind.net]  has joined #ubuntu-devel
=== holymoo [n=start@S01060016b6b53675.vf.shawcable.net]  has joined #ubuntu-devel
=== dholbach [n=daniel@i59F76FD5.versanet.de]  has joined #ubuntu-devel
=== sahin_h [n=ezaz@dsl5400DBAD.pool.t-online.hu]  has joined #ubuntu-devel
=== viviersf [n=cain@gw.impilinux.co.za]  has joined #ubuntu-devel
=== LaserJock [n=mantha@ubuntu/member/laserjock]  has joined #ubuntu-devel
=== Hobbsee [n=Hobbsee@ubuntu/member/hobbsee]  has joined #ubuntu-devel
[08:24] <dholbach> ArneGoetje: are you all set with the uploads you wanted to make?
=== ion_ thanks mjg59 from the heart.
[08:25] <Mithrandir> *sigh*, why does trackerd run when I've checked "disable indexing" and "disable watching"?
=== Hobbsee tries to figure out which switches to use rsync with, when rsyncing a daily iso
[08:25] <Mithrandir> Hobbsee: -a --progress -v
[08:25] <ion_> mithrandir: It still provides the generic metadata database. Unfortunately, programs have yet to begin to use it.
[08:25] <ArneGoetje> dholbach: it's currently on the way
[08:26] <Hobbsee> Mithrandir: you rock.
[08:26] <dholbach> ArneGoetje: ok great
[08:26] <ArneGoetje> dholbach: pitti is sposoring
=== Hobbsee hugs Mithrandir
[08:26] <Mithrandir> ion_: so there's no way to tell it to stay away and not come back short of removing the package or chmod 0-ing the binary?
=== ant30 [n=aperezar@38.Red-80-36-82.staticIP.rima-tde.net]  has joined #ubuntu-devel
[08:27] <ion_> mithrandir: You could disable the autostart from gnome settings.
[08:28] <ion_> It probably would still be started by dbus when someone queries it, though.
[08:28] <ion_> Uh. Something.
[08:28] <Mithrandir> *sigh*
[08:28] <Mithrandir> that's fairly broken.
=== Nicke [n=niclasa@ua-83-227-140-135.cust.bredbandsbolaget.se]  has joined #ubuntu-devel
[08:29] <ion_> If you dont want it, why not uninstall it?
[08:30] <Mithrandir> because this might not be a single-user machine?
[08:30] <Mithrandir> a user should be able to disable something like tracker without having root access.
[08:30] <LaserJock> yep
[08:33] <minghua> ArneGoetje: Thanks for fixing scim.
[08:34] <Treenaks> Mithrandir: the same happens with vino.. I have remote desktop access disabled, but still vino-session is running
[08:35] <ArneGoetje> minghua: just the quick and dirty fix...
=== Lure [n=lure@212.103.157.37]  has joined #ubuntu-devel
[08:36] <ArneGoetje> minghua: need to discuss with Riddell about the future of those package changes
=== Gasten [n=Gasten@h52n9c1o1095.bredband.skanova.com]  has joined #ubuntu-devel
[08:36] <minghua> ArneGoetje: Yeah, I really hope that library file move patch can be dropped.
[08:37] <minghua> ArneGoetje: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438647 is my take on the issue if you are interested.
[08:37] <ubotu> Debian bug 438647 in scim "[whislist]  how about move scim-helper-* from scim" [Wishlist,Open] 
[08:38] <ArneGoetje> minghua: well, as far as I understood him, the issue is that skim currently depends on gtk... any way to rewrite that library that it supports both, gtk and qt?
[08:38] <Mithrandir> Treenaks: well, same bug.  We should strive to fix those bugs, really.
[08:38] <Treenaks> Mithrandir: is there already a report, or should I open one?
[08:39] <minghua> ArneGoetje: No rewriting is needed, just repackaging.  But that needs better investigation and testing, not just blindly throwing two files to a different package.
[08:39] <minghua> ArneGoetje: Even in Ubuntu, skim still depends on scim nowadays, so that patch doesn't achieve anything.
=== Zdra [n=zdra@90.106-65-87.adsl-dyn.isp.belgacom.be]  has joined #ubuntu-devel
[08:39] <Mithrandir> Treenaks: I'm reporting one for tracker now
[08:41] <Mithrandir> or actually, it's bug 132320
[08:41] <ubotu> Launchpad bug 132320 in tracker "Tracker consumes more then 90% of CPU even when indexing is disabled" [Critical,Fix committed]  https://launchpad.net/bugs/132320
[08:42] <Treenaks> Mithrandir: it'll probably still be running
[08:42] <ArneGoetje> minghua: ok... so, this is a deeper issue. I will take a look into your approach
[08:42] <Treenaks> Mithrandir: (not doing anything else... except consume memory etc.)
[08:42] <Treenaks> Mithrandir: that bug only addresses CPU usage
[08:42] <minghua> ArneGoetje: Yeah, please follow up in Debian #438647.
[08:42] <ubotu> Debian bug 438647 in scim "[whislist]  how about move scim-helper-* from scim" [Wishlist,Open]  http://bugs.debian.org/438647
[08:44] <ArneGoetje> ok
[08:47] <pitti> asac: eek, problem: you introduced a new mozilla-firefox-locale-he without C/R/P'ing mozilla-firefox-locale-he-il
[08:47] <pitti> asac: preferably we just continue to use the old name
=== azeem_ [n=mbanck@ppp-88-217-18-117.dynamic.mnet-online.de]  has joined #ubuntu-devel
[08:50] <pitti> asac: same for -ka-ge -> -ka
[08:51] <pitti> asac: and -ro-ro
[08:53] <lucky_lucas> Anyone from the xorg team ?
[08:54] <pitti> asac: fixing...
=== cassidy [n=cassidy@host-85-27-68-188.brutele.be]  has joined #ubuntu-devel
[08:56] <bryce> lucky_lucas: yep
[08:57] <lucky_lucas> Is the ati driver v. ubuntu4 meant to resolve xorg rash while using compiz ?
[08:57] <lucky_lucas> crash
[08:58] <bryce> xorg-server 12ubuntu5 has a fix for a crash when using -nvidia or -fglrx with compiz, if that's what you mean
[08:59] <lucky_lucas> bryce: No I'm talking about the package xorg-server-video-ati 6.7.192 ubuntu4
[08:59] <bryce> the -ati driver update was to enable xrandr (multi-display) capabilities.
[08:59] <lucky_lucas> Ok
[08:59] <Treenaks> Is there any news on the 30 second delay when logging in when using a composite window manager
[08:59] <Treenaks> bryce: but it broke dpi :)
[08:59] <bryce> Treenaks: what?
[09:00] <lucky_lucas> bryce: So the compiz failure was caused by xorg-server itself and not by the drivers, sweet
[09:00] <bryce> afaik, upgrading to xorg-server 1.3 is what broke dpi, not driver upgrades.
[09:00] <Treenaks> bryce: Well, 6.7.192 thinks my display is 50x31cm, while it's 33x21cm
[09:00] <Treenaks> bryce: oh.. because adding DisplaySize doesn't help either
[09:01] <bryce> lucky_lucas: if it's the crash I was focusing on fixing, it was caused by ABI changes in xserver which caused failures with binary video drivers
[09:01] <lucky_lucas> B
[09:02] <lucky_lucas> bryce: which bug is it ?
[09:02] <bryce> Treenaks: the -ati update did not cause that breakage; that's due to the xserver upgrade from 1.2 to 1.3.  but it should be fixed now.
[09:02] <lucky_lucas> I have filled this bug https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/134578
[09:02] <ubotu> Launchpad bug 134578 in xserver-xorg-video-ati "Open source ati driver freeze with compiz" [Undecided,Confirmed] 
[09:03] <bryce> I also independently changed the default dpi in xserver from 75 to 100, around xserver 12ubuntu4 or 5
[09:03] <pitti> asac: new m-f-l-all uploaded
[09:04] <lucky_lucas> Bellow I said, that the failure happens also with nvidia-glx, so maybe your fix, resoled this too
[09:04] <lucky_lucas> I will try this afternoon
[09:04] <Treenaks> bryce: I have 2:1.3.0.0.dfsg-12ubuntu5 and my 150dpi screen reports as 96x96
=== RAOF admires Treenaks' LCD
[09:06] <bryce> lucky_lucas: unfortunately when people simply report "it freezes" that really isn't enough info to go on
[09:06] <Treenaks> RAOF: LaptopTestingTeam \o/
[09:06] <bryce> what really helps is to have logs, error messages, stack traces, etc.
[09:07] <RAOF> Treenaks: You get shiny, shiny laptops?  Cool.
[09:07] <Treenaks> RAOF: got
[09:08] <lucky_lucas> In fact I thought you were aware of something because when I installed, the tribe 5 the ati was blacklisted to use with compiz. After the update the blacklist was off and compiz is running, so I concluded that the problem was officially solved
[09:08] <bryce> heh, ati has a seemingly limitless number of bugs
[09:09] <bryce> lucky_lucas: actually I don't deal with the compiz blacklist
[09:10] <lucky_lucas> Anyone does it ?
=== Nuscly [n=nuscly@29-231.206-83.static-ip.oleane.fr]  has joined #ubuntu-devel
[09:22] <LaserJock> hmm, has mvo been around?
[09:24] <dholbach> LaserJock: not yet, it's 9:24 in germany and I think he's just come back from a trip in London, so it might take a while until he's here
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-devel
[09:25] <LaserJock> dholbach: ah, thanks
[09:25] <pitti> hey seb128
[09:26] <seb128> hello pitti
[09:26] <dholbach> hey seb128!
[09:27] <seb128> hello dholbach
=== Lure [n=lure@212.103.157.37]  has joined #ubuntu-devel
=== kagou [n=Patrice@78.113.223.103]  has joined #ubuntu-devel
[09:38] <siretart> hey folks!
=== pitti hugs siretart 
=== siretart hugs pitti back :)
[09:41] <siretart> seb128: have there been any further problems regarding live-{initramfs,helper}?
[09:42] <seb128> siretart: no, I've just been busy with GNOME 2.20 and didn't do archive admin work again yesterday, I'll do that this morning
[09:42] <siretart> seb128: no problem. was just curious
[09:48] <seb128> anybody from MOTU uvf team willing to accept that we sync louie as a new package from Debian? Rhythmbox upnp plugin requires it
=== garteck [n=garteck@189.156.15.199]  has joined #ubuntu-devel
=== Whoopie [n=Whoopie@unaffiliated/whoopie]  has joined #ubuntu-devel
=== jono [n=jono@ubuntu/member/jono]  has joined #ubuntu-devel
[09:51] <Whoopie> seb128: Hi, I now got 3 verifications that my nautlilus-sendto patch for thunderbird works.
[09:51] <seb128> Whoopie: hi, yeah I read the mails, I'll have a look again if I understand what it does
=== tormod [n=tormod@138.131.206.233]  has joined #ubuntu-devel
[09:53] <Hobbsee> seb128: hmm?
[09:53] <seb128> Whoopie: http://launchpadlibrarian.net/9194969/nautilus-sendto-0.12-thunderbird-2.patch <- this one?
[09:53] <Whoopie> seb128: yes
[09:54] <seb128> it's easier than the previous version ;)
[09:54] <Whoopie> hehe, yes
[09:54] <Whoopie> it's just escaping fixes.
[09:55] <Whoopie> seb128: it's easier because I could skip the file-roller check. In feisty, this was needed, but not in gutsy.
=== carlos [n=carlos@canonical/launchpad/carlos]  has joined #ubuntu-devel
=== marcel [n=marcel@wc-50.r-195-35-150.atwork.nl]  has joined #ubuntu-devel
[10:10] <seb128> Whoopie: I'm not convinced by the patch
[10:10] <seb128> asac: do you know what is the correct way to send several attachments using thunderbird?
[10:11] <seb128> thunderbird -compose to=email,attachment=file:///path/to/file,file:///path/to/anotherfile is correct?
=== doko [n=doko@161.116.111.2]  has joined #ubuntu-devel
[10:13] <gnomefreak> seb128: hes sleeping but that looks right im just not sure if its , or ;
[10:13] <gnomefreak> i havent used tbird from cli in a long time
[10:14] <seb128> gnomefreak: it's 10am local time it should be around the time he wakes up no? ;)
[10:14] <seb128> gnomefreak: is that correct to put the list attachments between ' '?
[10:14] <seb128> or " "?
[10:14] <gnomefreak> give him another hour or 2 and hell be up ;)
[10:15] <gnomefreak> that im not sure of
[10:15] <gnomefreak> i wanna say ' '
=== gnomefreak wonders something let me see if i cant find out real fast
=== Watersevenub [n=Watersev@azevedo.astro.up.pt]  has joined #ubuntu-devel
[10:18] <pitti> moquist, ogra: https://wiki.ubuntu.com/MainInclusionReportMoodle approved and promoted; with protest, but *shrug*, business goals and everything
=== Mithrandir waits for somebody to go on a trigger-rampage over texlive.
[10:18] <pitti> ogra: please seed it appropriately
[10:20] <pitti> doko: gcj-4.1 wants to go to universe, is that ok?
=== dexem [n=dani@14.Red-88-26-177.staticIP.rima-tde.net]  has joined #ubuntu-devel
[10:20] <doko> \o/
[10:21] <pitti> doko: I take that as a 'yes' :-)
[10:21] <StevenK> has
[10:21] <gnomefreak> seb128: its attachment='file:///c:/test.txt'
[10:21] <StevenK> Interesting. How did 'has' get into my cut buffer?
[10:21] <seb128> gnomefreak: and if you have several attachments?
=== rulus [n=ssh@82.134-244-81.adsl-dyn.isp.belgacom.be]  has joined #ubuntu-devel
[10:21] <gnomefreak> it doesnt say
[10:21] <seb128> gnomefreak: 'attachment','attachment'?
[10:21] <ion_> stevenk: Sorry, i wont do that again.
[10:22] <gnomefreak> give me another minute to see if i can find
[10:22] <seb128> gnomefreak: and should the path be escaped?
=== dholbach_ [n=daniel@i59F71208.versanet.de]  has joined #ubuntu-devel
[10:23] <doko> hmm, the last upgrade did break fonts in gnome-terminal, ridiculous small now ... just seeing a dot as prompt
[10:24] <Hobbsee> doko: and then got subsequently fixed...
[10:24] <gnomefreak> seb128: this is all ive found so far http://www.mozilla.org/docs/command-line-args.html#how
[10:24] <Hobbsee> unless it got broken again
[10:24] <seb128> gnomefreak: thanks
[10:24] <seb128> Hobbsee: hey
[10:24] <seb128> Hobbsee: <seb128> anybody from MOTU uvf team willing to accept that we sync louie as a new package from Debian? Rhythmbox upnp plugin requires it
[10:24] <gnomefreak> seb128: yw i wish it had more info though
[10:25] <Hobbsee> seb128: were you going to promote it?
[10:26] <Hobbsee> seb128: fine by me, assuming you've got time to review.
[10:26] <Hobbsee> seb128: at this point, we've stuck a blanket deny on any new packages, unless they're really important or interesting
[10:26] <seb128> Hobbsee: I don't think so, just have it available to universe so people stop whining about the upnp plugin not working
[10:26] <Hobbsee> seb128: fair enough
[10:26] <seb128> thanks
[10:26] <Hobbsee> seb128: which mdz then hijacked, but that's beside the point.
[10:27] <seb128> right
[10:27] <dholbach> doko: the last libgnome2 update fixed it, you need to re-login
[10:28] <doko> dholbach: thanks, can't dist-upgrade currently
[10:29] <dholbach> doko: then upgrade libgnome2 only
[10:30] <asac> seb128: i cannot find it atm i think its like: thunderbird mailto:seb128@ubuntu.com?subject="hello seb"&attachment="file:.."&attachment=...
[10:31] <seb128> asac: ok, thanks
[10:32] <gnomefreak> asac: the link showed using ' for attachments
=== tkamppeter [n=till@bl8-117-95.dsl.telepac.pt]  has joined #ubuntu-devel
[10:32] <asac> yeah ... might be true
[10:34] <tkamppeter> hi doko
[10:35] <Whoopie> seb128: thunderbird -compose to=email,"attachment='file:///path/to/file,file:///path/to/anotherfile'"
[10:36] <seb128> Whoopie: why the " before attachment?
[10:36] <evand> Anyone willing to sponsor an 11th hour upload of migration-assistant to main?
[10:36] <evand> http://people.ubuntu.com/~evand/upload/migration-assistant_0.5.0.dsc if you're interested
[10:36] <seb128> Whoopie: why not attachment="PATH"&attachment="OTHERPATH"?
[10:36] <evand> and thanks in advance
[10:37] <dholbach> evand: looking into it
[10:38] <Whoopie> seb128: http://www.mozilla.org/docs/command-line-args.html#Syntax_Rules
[10:38] <Whoopie> seb128: so, they also escape the to field with "
[10:38] <seb128> Whoopie: they put the " before the to
[10:39] <seb128> Whoopie: not before attachment
[10:39] <Whoopie> seb128: if we want to support more mail addresses, we need to escape the to values by '
=== giskard [n=giskard@213-140-22-74.fastres.net]  has joined #ubuntu-devel
[10:39] <dholbach> evand: uploaded
[10:40] <Whoopie> seb128: thunderbird -compose "to='test1@test.de,test2@test.de'","attachment='file:///path/to/file,file:///path/to/anotherfile'"
=== mc44 [n=mc44@unaffiliated/mc44]  has joined #ubuntu-devel
[10:40] <evand> dholbach: thanks a ton!
[10:40] <seb128> Whoopie: ok, seems to make sense
[10:40] <seb128> Whoopie: see that's why I asked you to explain in the bug so I can look what the patch is doing now ;)
[10:41] <dholbach> evand: de rien
[10:42] <Whoopie> seb128: sorry, it's:  thunderbird -compose "to='test1@test.de,test2@test.de',attachment='file:///path/to/file,file:///path/to/anotherfile'"
[10:42] <Whoopie> seb128: " for all values, and ' for the values inside the fields
[10:43] <seb128> Whoopie: ok
=== Treenaks [n=martijn@thuis.foodfight.org]  has joined #ubuntu-devel
=== Zdra [n=zdra@90.106-65-87.adsl-dyn.isp.belgacom.be]  has joined #ubuntu-devel
=== Demitar [n=demitar@c-212-031-182-147.cust.broadway.se]  has joined #ubuntu-devel
=== XSource [n=XSource@41.201.197.92]  has joined #ubuntu-devel
=== bigon [i=bigon@ubuntu/member/bigon]  has joined #ubuntu-devel
=== pochu [n=emilio@95.Red-83-32-161.dynamicIP.rima-tde.net]  has joined #ubuntu-devel
=== hunger [n=tobias@pd95b0676.dip0.t-ipconnect.de]  has joined #ubuntu-devel
=== hunger [n=tobias@pd95b0676.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[10:58] <tormod> what's up with the daily live cds? filesystem.squashfs is 2 days old.
[10:58] <pitti> dholbach: do we need libgtksourceviewmm-2.0-1 & friends in main at alll?
[10:59] <tkamppeter> hi pitti
[10:59] <pitti> hi tkamppeter
[11:00] <tkamppeter> pitti, have you already looked into my gutenprint and foomatic-db updates?
[11:00] <Hobbsee> tormod: on !i386, i take it?
[11:00] <tormod> Hobbsee: yes
[11:00] <Hobbsee> tormod: livefses wont be building.
[11:00] <Hobbsee> ubuntu-desktop is not installable.
[11:00] <Hobbsee> (from http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html )
[11:00] <pitti> tkamppeter: not yet, no time yet; will those 27 new drivers increase package sizes on CDs?
[11:01] <pitti> dholbach: ah, apparently not, nevermind
[11:01] <dholbach> pitti: no, we don't need them
[11:01] <tormod> Hobbsee: thanks. #ubuntu+1 should be warned in topic maybe.
[11:01] <tkamppeter> pitti, no, the PPDs are in openprinting.org-ppds-extra which is not part of the CDs, so it probably influences only DVDs.
[11:01] <pitti> tkamppeter: ah, ok
[11:02] <kagou> hi tkamppeter
[11:02] <Hobbsee> tormod: people usually dont try them - and it has various warnings about gutsy being broken
[11:02] <seb128> Whoopie: I've uploaded a new nautilus-sendto with your patch, thanks
[11:03] <tkamppeter> The changes in gutenprint should not add size, they add two new models and correct a third and thanks to PPD auto-generation there should be no visible size increase.
[11:03] <tkamppeter> hi kagou
[11:04] <Hobbsee> tormod: the main reason that it would be requiring someone to check every day, and update the topic as appropriate -and that people have better things to do - and more useful bugs to put there
[11:04] <ogra> whats the openssh-server seed ???
[11:04] <kagou> tkamppeter, last s-c-p is working great :)
=== spacey [n=herman@ubuntu/member/spacey]  has joined #ubuntu-devel
[11:07] <tormod> Hobbsee: I am not sure I agree that people don't try them. Since tribe6 fell out we have been encouraged to use them. The issue now is that a new daily seems to have been made, until you look at the contents...
=== baltix [n=administ@ctv-84-55-6-18.init.lt]  has joined #ubuntu-devel
[11:08] <Hobbsee> tormod: true - i've no idea why they get made, if the livefses fail - surely you hsould have no builds for the day.
[11:08] <baltix> hello
[11:09] <pitti> tormod: FWIW, I'm currently rebuilding *-meta, and then I'll trigger new CD builds; my goal today is to fix the oversizedness and get them generally installable (modulo the unionfs bug, of course)
[11:09] <Hobbsee> pitti: how long will that take?
=== Hobbsee wants to rsync in the next 5 hours.
[11:09] <pitti> Hobbsee: I'll spread it out over the day; I have no intention of staring at it all the time
[11:09] <baltix> pitti: I can tell you how to fix oversizing problems without removing any software :)
[11:09] <pitti> Hobbsee: 5 hours should be doable
[11:09] <Hobbsee> pitti: yay, ok
[11:09] <pitti> baltix: "use DVDs"? :-)
[11:10] <pitti> we have the new OO.o, and some font package reductions
[11:10] <baltix> pitti: no
[11:10] <pitti> let's see whether that already does the trick
[11:11] <baltix> pitti: lots of space is eaten by localized help files from gnome applications
[11:11] <pitti> baltix: right, that's on our long-term list, too
[11:12] <baltix> pitti: look at this specification - https://blueprints.edge.launchpad.net/ubuntu/+spec/help-for-each-languages
[11:13] <asac> network-manager needs to be given back on all but lpia/i386 ... who is in charge?
[11:14] <pitti> asac: can do
=== marting [n=martin@foo.stupids.org]  has joined #ubuntu-devel
[11:14] <asac> pitti: thanks!
[11:14] <pitti> asac: kicked
=== asac hugs pitti
[11:16] <soren> Could someone be pursuaded to merge this branch into the main one? https://code.edge.launchpad.net/~shawarma/ubuntu-seeds/ubuntu.gutsy.server-tasks
[11:16] <pitti> soren: oh, good timing; I am just updating *-meta
[11:17] <soren> pitti: \o/
=== MacSlow [n=mirco@unaffiliated/macslow]  has joined #ubuntu-devel
[11:17] <baltix> pitti: why excluding unneeded help files is only on long-term list ? It's very easy to do - just move subfolders by language names from /usr/share/gnome/help/ into separate packages - help-pack-gnome-pl, help-pack-gnome-fr, etc
=== Zdra [n=zdra@90.106-65-87.adsl-dyn.isp.belgacom.be]  has joined #ubuntu-devel
[11:19] <pitti> soren: hm, that changes quite a bit; does this have cjwatson's blessing? I'm not sure whether the STRUCTURE changes are correct
[11:19] <baltix> you are doing almost the same job with translations (.mo files from /usr/share/locale/ subfolders)
=== heno [n=henrik@ubuntu/member/heno]  has joined #ubuntu-devel
[11:19] <soren> pitti: Ah, I may have forgot to renmae the file-server thing in STRUCTURE.
[11:20] <soren> pitti: Other than that, I pretty much just copied the openssh-server thing.
[11:20] <pitti> soren: and shouldn't the packages in the new tasks be removed from the previous seed ('server' or so)?
[11:20] <pitti> soren: server-ship doesn't mention postgresql-server and mail-server either; that's not intended, I take it?
[11:20] <Hobbsee> heno!
[11:20] <soren> pitti: Hm... Gimme a few minutes.
[11:20] <heno> Hobbsee!
[11:21] <Hobbsee> :)
[11:21] <pitti> soren: hm, what about I upload *-meta now, you sort this out and get Colin's blessing, and then I merge and update again?
[11:21] <pitti> soren: I want to get the other CDs in shape ASAP
[11:21] <soren> pitti: Alright.
=== ..[topic/#ubuntu-devel:pitti] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | main frozen for Gutsy Beta release
[11:22] <ion_> I take it the fix for nvidia_supported in l-r-m didnt make it to the beta?
[11:24] <soren> pitti: Right, yes, that's entirely fine. I need Colin to do a new tasksel upload for this as well, so I have to bother him anyway :)
=== tormod [n=tormod@138.131.206.233]  has left #ubuntu-devel ["Ex-Chat"] 
=== jamesh [n=james@canonical/launchpad/jamesh]  has joined #ubuntu-devel
=== raphink [i=raphink@ubuntu/member/raphink]  has joined #ubuntu-devel
=== thekorn_ [n=thekorn@a89-182-4-127.net-htp.de]  has joined #ubuntu-devel
[11:35] <soren> How much space does a default desktop installation of gutsy occupy?
[11:36] <pitti> soren: something between 2 and 2.5 GB
[11:36] <soren> pitti: thanks
=== ogra hugs pitti 
[11:37] <ogra> seeds changed, thanks a lot :)
[11:37] <pitti> ogra: only supported? or ship/desktop?
[11:37] <pitti> ogra: (I just updated *-meta)
=== pitti sighs at http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html
[11:39] <pitti> fabbione: do you happen to have an idea why sparc has so many uninstallable packages? autobuilders don't keep up, or a broken basic library?
=== nags [n=nags@122.167.145.44]  has joined #ubuntu-devel
=== azeem [n=mbanck@ppp-88-217-15-128.dynamic.mnet-online.de]  has joined #ubuntu-devel
[11:40] <fabbione> pitti: no sorry. I haven't been a looking a sparc for ages. AFAIK pkl is supposed to do so
[11:40] <pitti> ah, ok
=== stub [n=stub@tetkyo012094.tkyo.te.ftth2.ppp.infoweb.ne.jp]  has joined #ubuntu-devel
[11:44] <Riddell> thanks for the merge pitti
[11:44] <ogra> pitti, -server
[11:44] <lucas> are sync requests going to be processed before the release? I have a pending sync request than fixes a bug (UVFe already granted)
[11:44] <pitti> ogra: I see; can you please update -meta again then when you are finished with the seeds?
=== azeem__ [n=mbanck@ppp-88-217-16-192.dynamic.mnet-online.de]  has joined #ubuntu-devel
[11:45] <ogra> indeed :)
[11:46] <baltix> btw, why foomatic-db-gutenprint was removed from main since edgy ? lots of printer's drivers now are missing in Ubuntu currently :(
[11:47] <pitti> infinity: can we do a mass-giveback on sparc?
=== jsgotangco [n=JSG@ubuntu/member/jsgotangco]  has joined #ubuntu-devel
=== Spads [i=spacehob@unaffiliated/spads]  has joined #ubuntu-devel
[11:52] <Whoopie> seb128: I thank YOU.
[11:52] <seb128> ;)
[11:53] <pitti> seb128: ah, seems that libmetacity0 is a major source of uninstallability on amd64; giving back package
[11:54] <seb128> pitti: might be, I looked yesterday to GNOME 2.20 builds and almost everything built, I asked some retries to lamont which seem to have worked correctly
[11:55] <seb128> pitti: the metacity build issue was due to libgnomeui uploaded almost in the same time and arch all any installability
[11:55] <Riddell> calc: is OO 2.3 going to get into beta? (I presume not)
=== XSource [n=XSource@41.201.197.92]  has joined #ubuntu-devel
[12:04] <pitti> seb128: who can we blame for the beagle FTBFS? Do you still think we should keep it in main at all, now that we have tracker?
[12:05] <seb128> pitti: there is a bzr branch which the new version which fixes the build issue
[12:05] <seb128> https://bugs.edge.launchpad.net/ubuntu/+source/beagle/+bug/134341
[12:05] <ubotu> Launchpad bug 134341 in beagle "beagle ftbfs" [High,Fix committed] 
[12:06] <seb128> pitti: keeping it to main, yes, some people use it and nautilus can use it at runtime only if builds with libbeagle
=== Fujitsu [n=fujitsu@ubuntu/member/fujitsu]  has joined #ubuntu-devel
[12:07] <pitti> seb128: bzr fix> ah, cool
=== pitti attacks http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_outdate.txt now
[12:08] <seb128> pitti: Riddell gave the approvel for the new version but I didn't manage to upload before my holidays, I'll have a look today
[12:08] <pitti> seb128: thanks
[12:09] <pitti> Mithrandir: can you please fix the bluez-utils b-deps? we don't have libbluetooth-dev 3.19
[12:10] <seb128> bah, freeze already in effect?
[12:11] <Spads> Yep
[12:11] <Spads> http://mid.gmane.org/20070920091544.GI6014@piware.de
[12:11] <pkern> And the topic FWIW...
[12:12] <seb128> that was not really a question
=== baltix [n=administ@ctv-84-55-6-18.init.lt]  has left #ubuntu-devel ["Ex-Chat"] 
[12:12] <seb128> rather a "doh, the freeze is already in effect"
[12:12] <pitti> cjwatson: d-i on sparc failed with "sparc64: Unrecognized architecture"; any idea about that?
[12:12] <seb128> I just read pitti's mail on the list
=== tritium_ [n=tritium@ubuntu/member/tritium]  has joined #ubuntu-devel
[12:17] <cjwatson> pitti: util-linux bug I suspect
[12:17] <pitti> cjwatson: lpia failed in an interesting way, too
[12:17] <cjwatson> nothing relevant in d-i has changed
[12:17] <cjwatson> lpia failures in debian-installer are not interesting :-)
[12:17] <pitti> cjwatson: ah, fabbione mentioned an util-linux bug, but hmm
[12:18] <cjwatson> pitti: I don't know if you saw, but fixes to the unionfs breakage are in git
[12:18] <pitti> oooh
[12:20] <cjwatson> and work for me
[12:20] <cjwatson> just waiting for Ben to wake up and upload them
=== jamiemcc [n=jamie@82-32-8-26.cable.ubr02.azte.blueyonder.co.uk]  has joined #ubuntu-devel
[12:21] <cjwatson> soren: so, none of file-server, postgresql-server, and mail-server are going on the server CD, is that correct?
[12:21] <cjwatson> soren: those seeds need to at least be inherited by supported
[12:23] <cjwatson> fabbione: I don't believe we ever agreed that pkl would handle general sparc build failures. We agreed certain specific things that he would take over and according to e-mail that wasn't one of them
[12:23] <cjwatson> General Sparc maintenance (to be spread amongst kernel, server and
[12:23] <cjwatson> distro teams)
[12:23] <pitti> mjg59: did you see the freetype FTBFS? will you fix it or should someone else care about it? (patch didn't apply)
[12:24] <pitti> cjwatson: FWIW, I'm currently on a give-back sprint, working from the grounds up (libgnomevfs stalls a lot of things)
=== kaptengu [n=kaptengu@c213-100-60-183.swipnet.se]  has joined #ubuntu-devel
[12:27] <Mithrandir> pitti: yes, I thought I uploaded bluez-libs too yesterday.  I'll fix it when I get into the office.
[12:28] <pitti> cjwatson: can I pick your brain about seeds for a moment?
[12:28] <pitti> cjwatson: component-mismatches has some troubles with Provides:, I think
[12:28] <pitti> cjwatson: e. g. it wants to promote libfile-temp-perl, but that's provided by perl-modules
[12:29] <pitti> cjwatson: similarly, links is provided by elinks
[12:29] <pitti> cjwatson: is there an override I can apply to the seeds? like "we explicitly don't want this in main and know it's available otherwise"?
[12:31] <cjwatson> pitti: you could try a ' * !libtemp-file-perl' entry to blacklist it though I'm not sure that'll do the right thing
[12:31] <cjwatson> pitti: a better option might simply be to explicitly seed perl-modules somewhere
[12:32] <pitti> cjwatson: oh, it does take provides from explicit seeds into account?
[12:32] <cjwatson> if a dependency is already satisfied, it won't try to follow provides to satisfy it
[12:32] <pitti> cjwatson: elinks is explicitly seeded, though
[12:33] <cjwatson> it might be seeded further out than whatever is pulling in links
[12:33] <cjwatson> the order is not entirely deterministic
[12:33] <pitti> right, it's only in server-ship
[12:33] <cjwatson> a blacklist might do the job
=== doko [n=doko@161.116.111.2]  has joined #ubuntu-devel
[12:33] <pitti> cjwatson: I wouldn't like to put elinks into desktop just because dictionaries-common b-deps on it, so I favour the blacklist idea
[12:34] <pitti> cjwatson: (alternatively, just ignoring it on the c-m output is a valid option for me, too)
[12:34] <pitti> there's a lot more to ignore anyway
=== _nand__ [n=ec4@138.202-128-194.unknown.qala.com.sg]  has joined #ubuntu-devel
=== Keybuk [n=scott@wing-commander.netsplit.com]  has joined #ubuntu-devel
[12:46] <pitti> hi Keybuk
[12:47] <Keybuk> heya
[12:52] <cjwatson> pitti: while catching up on mailing lists I noticed a discussion on debian-glibc about dpkg-preconfigure segfaulting when libc6 and libc6-i686 were upgraded out of sync
[12:53] <cjwatson> pitti: and I was wondering if this might account for the mysterious debconf segfaults we've been seeing
=== IntuitiveNipple [n=TJ@alexandros.tjworld.net]  has joined #ubuntu-devel
=== ogra is impressed, cjwatson you still read -users :)
=== ogra thought he was alone there
[12:54] <pitti> cjwatson: you mean libc6 and -i686 being out of sync, or prematurely upgrading both?
[12:54] <cjwatson> ogra: I did a *lot* of mailing list catchup recently
[12:54] <ogra> honeymoon leftover ? :)
[12:54] <cjwatson> pitti: I think I mean the former but I was reading it at a seriously unpleasant time of the morning so take with pinch of salt
[12:55] <pitti> hm, I would have expected a strict versioned dependency between them, but of course there's always a window in between
[12:55] <soren> cjwatson: No, they belong on the server cd. I've just updated STRUCTURE to reflect this.
[12:56] <pitti> cjwatson: however, the only solution that comes to my mind for this is to just merge the packages on i386, but that might be unpleasant for embedded, etc.
[12:56] <cjwatson> libc6-i686 Pre-Depends: libc6 (= 2.6.1-1ubuntu4)
[12:56] <cjwatson> I wonder if that's counterproductive - it widens the gap between the two being unpacked
[12:56] <cjwatson> this is all just wild conjecture though
[12:56] <ogra> is there any info anywhere what the openssh-server seed is supposed to do (apart from depending on openssh-server :) )
[12:56] <cjwatson> ogra: task
[12:56] <ogra> ah
[12:57] <cjwatson> as you can tell from the way it has Task-* headers at the top
[12:59] <pitti> Mithrandir: I put ubuntu-mobile-dev into universe for now, since it's uninstallable in main anyway
[01:00] <Mithrandir> pitti: sure
=== agoliveira [n=adilson@200.146.40.81.adsl.gvt.net.br]  has joined #ubuntu-devel
[01:08] <soren> cjwatson: Does the new STRUCTURE look better to you? pitti mentioned that the stuff in the new tasks should be removed from the server-ship seed, but I think I disagree. I can see why it logically makes sense, but the thing is that we in the tasks name specific binary packages, while server-ship refers to source packages, so if germinate can handle it, it's easier to manage this way.
[01:09] <pitti> soren: s/should/might/, as I said, I'm not sure about your changes; it was just a suggestion to verify that
[01:09] <soren> pitti: Right. Sorry :)
[01:11] <elmo> where's the bug about compiz breaking the ability to change the number of workspaces?
[01:14] <cjwatson> soren: what about mail-server?
=== boggle [n=spindler@modemcable178.77-70-69.static.videotron.ca]  has joined #ubuntu-devel
[01:14] <cjwatson> soren: but yeah, that's better
[01:14] <iwj> pitti: Merging the packages just shortens the window of vulnerability.  dpkg can't update more than one file at a time since this is a filesystem not a transactional database.
=== boggle is now known as TeTeT
[01:15] <pitti> iwj: right, but there shouldn't be any debconf actions and the like in between?
[01:15] <iwj> Well, yes, so you won't get the symptoms unless something goes wrong.
[01:15] <cjwatson> I suspect it's really just a libc bug that installing disparate versions of libc6 and libc6-i686 breaks
[01:15] <cjwatson> surely with all these versioned symbols and the like it can avoid that sort of thing
[01:16] <cjwatson> soren: I think, as you say, it's OK to leave them in server-ship; germinate can certainly handle that
[01:16] <iwj> Maybe I should write a robustness tester for essential packages, which does interrupted partial installs and then checks that the system still works.
[01:16] <pitti> seb128: hm, http://launchpadlibrarian.net/9411808/buildlog_ubuntu-gutsy-i386.inkscape_0.45.1-1ubuntu4_FAILEDTOBUILD.txt.gz might be an intltool bug/regression/weird feature?
[01:17] <pitti> seb128: did you happen to see this before by any chance?
[01:17] <iwj> Merging the packages reduces the window of vulnerability, certainly.
[01:17] <iwj> I should go and collect my bike now so I can have some lunch before the meeting.
[01:17] <soren> cjwatson: Yes, mail-server should be there, too. That must have slipped somehow.
[01:18] <Mithrandir> seb128: I have a weird bug with nautilus where it instist that all my icons must be on only one of my two screens.
[01:19] <Mithrandir> seb128: is this a known bug or should I report it?
=== lucky_lucas [n=lucas@154-131.1-85.cust.bluewin.ch]  has joined #ubuntu-devel
[01:26] <ogra> pitti, can you approve e-meta ?
[01:27] <pochu> some of my recent uploads have failed to build in some (but not all) archs, all of them because missing build-dependencies... is this expected to happen?
=== doko [n=doko@161.116.111.12]  has joined #ubuntu-devel
[01:28] <ogra> hppa seems to miss some libs
=== `anthony [n=anthony@203-214-72-189.dyn.iinet.net.au]  has joined #ubuntu-devel
[01:29] <seb128> pitti: I think I know how to fix the inkscape build issue, let me have a try
[01:30] <seb128> Mithrandir: not sure about the nautilus thing, there is some dualscreen bugs open but I tend to skip those usually since I don't have the setup to try
[01:31] <Mithrandir> seb128: we should get C to buy you a second monitor, the
[01:31] <Mithrandir> +n
[01:31] <seb128> and a videocard ;)
[01:32] <pitti> seb128: two 22" TFTs does sound kind of appealing :)
[01:32] <seb128> pitti: right ;)
[01:33] <Mithrandir> pitti: Lenovo is starting to ship some 22" ones with 1920x1200, for about 500
[01:33] <ion_> mithrandir: Whoa, nice
[01:33] <amitk> sweet
=== \sh [n=shermann@gw07.combots.com]  has joined #ubuntu-devel
[01:36] <Mithrandir> http://www.tcmagazine.com/comments.php?shownews=16091&catid=2
[01:46] <pochu> could anybody retry a build of gcalctool on hppa please? should work now
=== ryu [n=chris@unaffiliated/ryu]  has joined #ubuntu-devel
[01:49] <geser> pochu: afaik hppa needs some time till it's in a state you can start worrying about ftbfs there
[01:50] <seb128> sparc and hppa seem to not cope with uploads at the moment
[01:50] <pochu> geser: well, the wrong dependencies were libgconf2, and 2.20 built fine there
[01:50] <pochu> geser: forget it, 2.19 built fine too
[01:51] <seb128> build issues are due to arch all/any out of syncs due to too many uploads in a short time
[01:51] <seb128> mainly
[01:51] <seb128> I mean the GNOME build issues this week
[01:53] <pitti> seb128: I'm doing massive sparc give-backs from the ground up (libraries to higher libs to apps)
[01:53] <pitti> seb128: those fail mainly because of too lax build deps
[01:54] <pitti> seb128: I think I can get it under control soon, though
[01:54] <seb128> pitti: "too lax build deps"?
[01:54] <seb128> pitti: good ;)
[01:55] <seb128> I still get quite some build failure mails though
[01:55] <pitti> seb128: yeah, I need several attempts sometimes
[01:55] <pitti> seb128: I could figure it out more precisely, but that would cost me a lot of time
[01:55] <pitti> seb128: sorry for the spam
=== pitti wishes the publisher was faster :)
[01:56] <seb128> that's alright
[01:56] <Hobbsee> pitti: you forgot to feed it again!
=== pitti pedals faster
=== surak [n=surak@aopcao.uab.es]  has joined #ubuntu-devel
=== pedro [n=pedro@pc-26-217-44-190.cm.vtr.net]  has joined #ubuntu-devel
=== \sh [n=shermann@gw07.combots.com]  has left #ubuntu-devel [] 
=== jwendell [n=wendell@ubuntu/member/wendell]  has joined #ubuntu-devel
[01:59] <Keybuk> iwj, pitti, Mithrandir: ping
[01:59] <pitti> eek, that
=== kagou [n=Patrice@78.113.223.103]  has joined #ubuntu-devel
[02:01] <pitti> Keybuk: #meeting?
[02:01] <Keybuk> yup
[02:03] <agoliveira> seb128: Hi. I have a question for you about my request to upload evince: why put the configure.ac patch on 03_hildon_interface.patch and not 02_autoconf.patch as it is now?
[02:03] <seb128> agoliveira: autoconf as its name indicates is an autoconf run
[02:03] <seb128> agoliveira: it has no source change
[02:03] <seb128> agoliveira: the configure.ac changes are done in 01_lpi and 02_autoconf is a configure update by running autoconf
[02:04] <agoliveira> seb128: One could argue that the autoconf run would depend on the changes on .ac but I understand your logic. Changes on the way.
[02:05] <seb128> agoliveira: the autoconf run does depends of the configure.ac changes
[02:05] <seb128> agoliveira: the idea is to have one patch having the source changes done manually and one which is done running autoconf which will likely conflict in new version
=== cr3 [n=cr3@200-171-140-32.dsl.telesp.net.br]  has joined #ubuntu-devel
[02:05] <agoliveira> seb128: Got it.
[02:05] <seb128> agoliveira: that makes updates easier, usually the source changes apply or you want to fix conflicts
[02:06] <seb128> and the autoconf update is something you don't need to bother about, just run autoconf, remove autom4te.cache and you have your update
=== ogra_ [n=ogra@p548ACCC2.dip.t-dialin.net]  has joined #ubuntu-devel
=== _MMA_ [n=_MMA_@cpe-071-070-203-016.nc.res.rr.com]  has joined #ubuntu-devel
=== carlos_ [n=carlos@163.pool85-48-166.static.orange.es]  has joined #ubuntu-devel
[02:10] <agoliveira> seb128: Another thing, you said that it don't install evince-hildon-ui.xml but it does.the data/Makefile.{in|am} patch selects between evince-ui.xml and evince-hildon-ui.xml deppending on the interface selected.
[02:11] <seb128> agoliveira: so you changed the autoconf patch sementic to do something else than running autoconf without documenting it
[02:11] <agoliveira> seb128: Agreed there.
[02:11] <agoliveira> seb128: I'll comment it better.
[02:11] <agoliveira> seb128: Thanks.
=== ogra_ [n=ogra@p548ACCC2.dip.t-dialin.net]  has left #ubuntu-devel [] 
=== sahin_h [n=ezaz@dsl5400DBAD.pool.t-online.hu]  has joined #ubuntu-devel
[02:11] <seb128> Makefile.am changes are source modifications, they should not go in the autotools update one
[02:12] <seb128> you're welcome
=== finalbeta [n=viper@d54C6865D.access.telenet.be]  has joined #ubuntu-devel
=== dendrobates [n=dendroba@adsl-065-005-186-012.sip.asm.bellsouth.net]  has joined #ubuntu-devel
[02:14] <iwj> soren: So the problem is that sl-modem-daemon has stopped working since tribe 5.
[02:14] <TomaszD> BenC, hi. Do you plan to fix the ACX issue for gutsy? https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/+bug/118539
[02:14] <ubotu> Launchpad bug 118539 in linux-ubuntu-modules-2.6.22 "[regression]  acx does not load" [Medium,Confirmed] 
[02:14] <soren> iwj: Right. NO CARRIER for the lose..
[02:14] <TeTeT> iwj: yes, I'm around
[02:15] <iwj> soren: Ah, you've actually tried it already ?
[02:15] <soren> iwj: Yes, to see if pitti's restricted manager stuff worked.
[02:15] <soren> It responds just fine to simple AT commands, but as soon as it actually needs the dsp, it seems to b0rk.
[02:15] <iwj> TeTeT: The easiest test is probably to use cat.  Ie, get a current machine that's got one of the supported modems.
[02:15] <iwj> Install sl-modem-daemon.  Then
[02:16] <iwj>  cat /dev/modem &
[02:16] <iwj>  cat >/dev/modem
[02:16] <iwj> (in sudo).
[02:16] <iwj> You should be able to type AT and get OK.
[02:16] <iwj> Then (with no phone line connected) say  ATDT012345
[02:16] <iwj> What it should do is sit there for a bit and they say NO DIALTONE.
[02:16] <soren> I didn't spend much time on it, so I didn't instrument the code with more debug stuff, but it seemed to err out just after it asked the modem which codec's it supported.
[02:16] <iwj> What it does for me is say NO CARRIER right away.
[02:17] <TeTeT> iwj: works on my T40P
[02:17] <iwj> soren: codecs ?  Um.  There are codecs in the card ?  I thought it was just an ADC.
[02:17] <soren> iwj: No clue. That's just what the code said :)
[02:17] <iwj> TeTeT: In current gutsy ?  Oh.  Lovely.
[02:17] <TeTeT> iwj: the codec is needed for creating the sound for the modem
[02:18] <iwj> TeTeT: I'm afraid I don't understand what that sentence means.
[02:18] <iwj> Well, if it works on some hardware and not others then it's almost certainly a kernel regression.
=== tkamppeter [n=till@bl7-126-228.dsl.telepac.pt]  has joined #ubuntu-devel
[02:19] <soren> TeTeT: Do you actually have it plugged into something?
[02:19] <TeTeT> soren: not yet, but I can
[02:19] <soren> TeTeT: Don't bother.
[02:19] <TeTeT> iwj: let me walk over to the Toshiba M200 and test there
[02:20] <soren> TeTeT: So your's waits for a while and then says "NO DIALTONE"?
[02:21] <TeTeT> iwj: takes another two hours, the upgrade to gutsy is still running there
[02:21] <TeTeT> soren: no, at is acknowledged with OK, atdt 1111 gives no carrier, as expected
[02:21] <iwj> TeTeT: OIC, that was with some pre-gutsy.
[02:21] <iwj> TeTeT: "no carrier" means it isn't working.
[02:21] <soren> Ah, "NO CARRIER" immediately means it *doesn't* work.
[02:22] <iwj> It should wait.  After all, it's supposed to be waiting for dialtone.
=== chand [n=rsamson@linagoraberri.pck.nerim.net]  has joined #ubuntu-devel
[02:22] <soren> TeTeT: Could you try plugging it in and trying again?
[02:22] <soren> It's unlikely, but not impossible, that it actually does check if it's plugged in before doing anything at all.
[02:23] <soren> ...in which case, everything might be working fine anyhow.
=== alleeHol [n=ach@allee.mpe.mpg.de]  has joined #ubuntu-devel
[02:26] <TeTeT> what's the hayes syntax for waiting for a dial tone? I need to dial 9, then the number
[02:26] <IntuitiveNipple> ATD,
[02:26] <IntuitiveNipple> the comma
[02:26] <soren> W
[02:26] <IntuitiveNipple> ATD9,num usually
[02:27] <soren> Comma waits. W waits for a new dialtone.
[02:27] <IntuitiveNipple> ahhh, ok, slight difference :)
[02:27] <jdong> ATDW
[02:27] <soren> Either will probably work, yes :)
[02:28] <TeTeT> soren + iwj: atd9,15146597735 => NO CARRIER, ERROR
[02:28] <soren> Alright.
[02:29] <TeTeT> so broken it is - if you need me for another test, ping or call the number above :)
[02:29] <soren> :)
=== _MMA_ [n=_MMA_@cpe-071-070-203-016.nc.res.rr.com]  has joined #ubuntu-devel
[02:29] <cjwatson> iwj: at least some level of encrypted filesystem support in d-i may be in gutsy; I spent some time over the last few days fixing up cryptsetup-udeb so that it might actually work
[02:30] <soren> iwj: From l-u-m changelog:   * revert to stock snd-hda-intel code
[02:30] <cjwatson> oh. I've been meaning to check into that as it breaks sound on my laptop; I'm sure there was a reason for it
[02:30] <iwj> cjwatson: That's good to hear.
[02:30] <cjwatson> kylem: do you have a reference for the reversion of snd-hda-intel?
[02:30] <iwj> soren: Hmm.  that may be relevant.
[02:31] <iwj> TeTeT: Thanks.
[02:31] <tepsipakki> pitti: I have a new x-x-v-ati (6.7.193) ready for upload
[02:31] <pitti> tepsipakki: ah, I remember that approval bug
[02:32] <tepsipakki> pitti: yes, but it was for .192, this is new :)
[02:32] <pitti> tepsipakki: ah; bug#?
[02:32] <kylem> cjwatson, yes, it broke other hw.
[02:32] <cjwatson> I figured
[02:33] <kylem> s/broke/regressed
[02:33] <tepsipakki> pitti: bug 138987
[02:33] <ubotu> Launchpad bug 138987 in xserver-xorg-video-ati "[UVF]  new version, 6.7.192 + fixes from git master" [High,Fix released]  https://launchpad.net/bugs/138987
[02:33] <tepsipakki> oh
[02:33] <tepsipakki> I didn't file a new one
=== linuxemacs [n=jelly@123.115.213.118]  has joined #ubuntu-devel
[02:35] <tepsipakki> pitti: it's merged with debian, only the xserver-xorg-dev build-dep is lower because we have 1.3.0.0 not 1.4
[02:35] <pitti> tepsipakki: just point me to a diff, that's enough for me
[02:36] <linuxemacs> hi all
[02:37] <soren> kylem: If I'm not much mistaken, crimsun had added a substantial amount of quirks to that particular driver.. Was any effort made to implement those?
[02:37] <tepsipakki> pitti: http://users.tkk.fi/~tjaalton/dpkg/ati/ati.debdiff
[02:37] <pitti> tepsipakki: oh, this time I meant the "current gutsy - your version" debdiff
[02:37] <tepsipakki> ah, right
[02:37] <tepsipakki> a sec
=== rbrunhuber [n=Miranda@highway.mvi.de]  has joined #ubuntu-devel
=== lucky_lucas [n=lucas@18.96.76.83.cust.bluewin.ch]  has joined #ubuntu-devel
[02:39] <tepsipakki> pitti: ok, url refreshed
=== gouki [n=gouki@ubuntu/member/gouki]  has joined #ubuntu-devel
[02:41] <pitti> tepsipakki: why the removal of the ConstantDPI option? doesn't that potentially break upgrades?
[02:41] <lamont> cjwatson: could you remove sysvinit/hppa from gutsy?
[02:41] <pitti> lamont: can do, but that sounds a bit disruptive?
[02:42] <lamont> I thought it was replaced, no?
=== lamont does a little background work before saying more
[02:42] <tepsipakki> pitti: well, mergedfb isn't supported anymore, so it's related to that ("Remove more mergedfb cruft")
[02:42] <cjwatson> lamont: it's still there for all other architectures, so no
[02:42] <tepsipakki> pitti: because of randr-1.2 -support
[02:42] <pitti> lamont: btw, any idea about https://launchpad.net/ubuntu/+source/debian-installer/20070308ubuntu13/+build/385413? I was told that this is due to a recent util-linux regression
[02:44] <lamont> ah.  that was it.  hppa has dapper sysvinit == essential which plays havoc with dist-upgrades of the chroot atm.  and no build record for hppa/gutsy, so...  I could re-upload it, or we could just remove it for hppa for the time being (iz not fatal to the effort, because of -stage0)
[02:44] <pitti> tepsipakki: ok, go ahead
=== vix_yang [n=ianvix_t@61-64-156-62-adsl-chu.STATIC.so-net.net.tw]  has joined #ubuntu-devel
[02:44] <tepsipakki> pitti: thanks!
[02:45] <lamont> pitti: -5ubuntu1 fixed the ftbfs on sparc... sigh
=== lamont looks at the sparc64 binary
=== vix_yang [n=ianvix_t@61-64-156-62-adsl-chu.STATIC.so-net.net.tw]  has left #ubuntu-devel [] 
[02:45] <pitti> lamont: oh, great; /me tries a give-back then
[02:46] <lamont> pitti: it _SHOULD_ work with a give back.  if not, thwap me and I'll stare at it until I produce -6ubuntu1
[02:46] <cjwatson> lamont: we must have avoided this on every other architecture?
[02:46] <pitti> lamont: cheers
[02:47] <lamont> cjwatson: you built edgy and feisty on every other architecture
[02:47] <pitti> cjwatson: oops, sorry for the spam; I accidentally gave back d-i lpia, too
[02:47] <lamont> cjwatson: and the missing build records? see adam
[02:47] <cjwatson> it's only the seventh time that's tried to build
[02:47] <lamont> cjwatson: and here I thought third time was supposed to be the charm...
[02:50] <lamont> cjwatson: building the current sysvinit on hppa would fix the problem.  sadly, launchpad won't do that right now.
[02:50] <cjwatson> that needs to be fixed anyway, so ...
[02:51] <lamont> cjwatson: right. and it's on cprov's plate
[02:51] <lamont> which was being full of 1.1.9 signoff last I heard.
[02:55] <cjwatson> that should finish soon
[02:55] <pitti> seb128: hm, the pygtk FTBFS on sparc causes quite a few followup problems/ any idea about it?
[02:56] <seb128> pitti: looking
[02:56] <seb128> pitti: could you approve my inkscape upload? it fixes the ftbfs
[02:56] <pitti> seb128: ooh, thanks! sure
[02:56] <seb128> danke
=== seb128 hugs pitti
[02:56] <pitti> gnome-keyring-manager?
[02:57] <seb128> pitti: that's a contributor patch to make it uses launchpad integration, should be safe to accept
[02:59] <seb128> pitti: ok, so pygtk ftbfs is due to pygobject
[02:59] <seb128> pitti: quick summary
[03:00] <seb128> pygobject builds a -doc and a -dev in Ubuntu (and no -doc in Debian)
[03:00] <seb128> we had a bug which make that the -doc was empty, I fixed it
[03:00] <seb128> but the .xsl installed there are required to build the pygtk documentations
[03:00] <seb128> so the options are
[03:00] <seb128> - drop the -doc like Debian
[03:00] <pitti> hm, and that breaks the tests on sparc?
[03:00] <seb128> - install the .xsl in the -dev
[03:01] <seb128> or make pygtk Build-Depends on python-gobject-doc
[03:01] <seb128> I think that would break on any arch
[03:01] <seb128> other arches built before the pygtk "fix"
[03:01] <pitti> make[4] : *** No rule to make target `/usr/share/gtk-doc/html/pygobject/style.css', needed by `all-am'.  Stop.
[03:01] <pitti> oh, I was misreading the log; you are right of course
[03:02] <pitti> seb128: right, so we should fix it soon; build dep doesn't sound too bad, what do you prefer?
[03:02] <seb128> well, build dep would work fine
[03:02] <seb128> I was just considering if that was worth merging the -dev and -doc like Debian is doing
[03:02] <pitti> .css into -dev is the most elegant probably
[03:03] <pitti> but for beta we should prefer foolproof and easy solutions; lots of other bugs to work on, I figure
[03:03] <seb128> right
[03:03] <pitti> seb128: if we agree on merging the debian change (-doc -> -dev) in hardy, would that be too bad?
=== ogra_ [n=ogra@p548ACCC2.dip.t-dialin.net]  has joined #ubuntu-devel
[03:04] <seb128> I did the merge yesterday but didn't upload
=== spacey [n=herman@ubuntu/member/spacey]  has joined #ubuntu-devel
[03:04] <seb128> one issue is that python-gtk2-doc Depends on python-gobject-doc
[03:05] <seb128> pitti: let's upload pygtk with a Build-Depends on python-gobject-doc for now
[03:05] <seb128> I've it ready
[03:05] <pitti> seb128: you rock
[03:05] <pitti> darn, just too late for the publisher, but *shrug*
[03:06] <seb128> pitti: uploaded
=== ogra_ [n=ogra@p548ACCC2.dip.t-dialin.net]  has left #ubuntu-devel [] 
=== stdin_ [i=stdin@pdpc/supporter/active/stdin]  has joined #ubuntu-devel
=== rnorwood [i=rnorwood@nat/redhat/x-9b06c22d88dc78ab]  has joined #ubuntu-devel
=== ogra_ [n=ogra@p548ACCC2.dip.t-dialin.net]  has joined #ubuntu-devel
=== cprov [n=cprov@canonical/launchpad/cprov]  has joined #ubuntu-devel
[03:13] <pkern> Will 20070920.1 be able to install itself? And is cryptsetup/partman-crypto possibly fixed?
[03:13] <pitti> pkern: unsure, untested; it's still too big, I still need to sort that out
[03:13] <pitti> siretart: here?
[03:14] <siretart> pitti: howdy!
[03:14] <cjwatson> pkern: cryptsetup might be, I was just about to test that myself
[03:15] <pitti> siretart: cdrkit trouble - see http://launchpadlibrarian.net/9412163/buildlog_ubuntu-gutsy-sparc.debian-installer_20070308ubuntu13_MANUALDEPWAIT.txt.gz
[03:15] <pitti> siretart: (happens on all arches)
[03:15] <siretart> yay. cryptsetup in main/the installer :)
[03:15] <pkern> pitti: Will there be a reasonably sized build available later today?
[03:15] <pitti> siretart: packages build-depending on mkisofs are unbuildable now :(
[03:15] <pitti> pkern: I hope so
[03:15] <pkern> cjwatson: Ok.
=== ryu [n=chris@unaffiliated/ryu]  has joined #ubuntu-devel
=== siretart looks
[03:15] <pitti> pkern: we need to find something big to throw out
=== eggauah [n=daniel@201.82.45.179]  has joined #ubuntu-devel
[03:15] <ogra_> firefox ?
[03:16] <cjwatson> pitti: I can make d-i build-depend on genisoimage in my next upload, though obviously it's crap that it's unbuildable as it is
[03:16] <pitti> siretart: the most correct fix, of course, is to change d-i to change the build dep and the command name, but I don't know how intrusive that is; cjwatson?
[03:16] <cjwatson> it's not that bad
[03:16] <siretart> pitti: according to apt, there are 2 packages build depending on mkisofs: debian-installer and etherboot
[03:17] <cjwatson> <cjwatson@sarantium ~/src/ubuntu/debian-installer/debian-installer-20070308ubuntu14>$ wcgrep mkisofs | wc -l
[03:17] <siretart> pitti: I'd say let's fix them to use genisoiamge
[03:17] <cjwatson> 12
=== Kopfgeldjaeger [n=nicolai@p54AD627D.dip.t-dialin.net]  has joined #ubuntu-devel
[03:17] <pitti> siretart: hm, might be easier at that point, yes
[03:17] <pitti> I'm going to fix etherboot
[03:18] <Kopfgeldjaeger> hi
[03:19] <cjwatson> pitti: done in my tree
[03:19] <ogra_> pitti: shouldnt the fonts together with oo.o being fixed gain us enough ?
[03:19] <pitti> ogra_: apparently not, at least not for ubuntu; 20.1 already has those changes
[03:19] <siretart> pitti: I'm already on it
[03:19] <cjwatson> I'm waiting for new linux-ubuntu-modules first
[03:19] <siretart> etherbot
[03:19] <pitti> siretart: hm, so am I...
=== ogra_ looks
[03:19] <pitti> siretart: ok, I leave it to you; thanks!
=== ajmitch waits for pitti to suggest to throw out f-spot :)
[03:20] <siretart> currently testbuilding, will upload in a minute
[03:20] <pitti> I'm afraid OO.o as a whole grew quite much in one of the last uploads, when java got enabled again
[03:21] <ogra_> meh alternate 14M oversized ?
[03:21] <Fujitsu> What percentage of the desktop CD is OOo?
=== ogra_ fears for edubuntu
[03:21] <cjwatson> pitti: current daily-live doesn't have the fixed ooo deps
[03:21] <pitti> cjwatson: no, that's because -desktop was uninstallable for the last days, and I didn't manually rebuild live yet
[03:21] <jdong> lzma time! :D
[03:21] <pitti> cjwatson: should be installable again, but there's no point in rebuilding before I found something to throw out
[03:22] <cjwatson> pitti: nor does it have the fixed fonts
[03:22] <cjwatson> so I think there is absolutely a point in rebuilding to see where we start
[03:22] <cjwatson> stand
[03:22] <pitti> ok, *shrug*, triggering build
[03:23] <iwj> pitti: I've just uploaded glibc 2.6.1-1ubuntu6 which I think ought to be approved.  It's a cosmetic change which I've carefully inspected, debdiffed, and tested.
=== ogra_ is courious too, especially with the moodle stuff added now
[03:23] <moquist> pitti: thanks (re: Moodle approval)
[03:23] <pitti> ogra_: oh, want new edubuntus?
[03:24] <ogra_> if meta -42 is there already
[03:24] <pitti> ogra_: yes, it is
[03:25] <pitti> ogra_: 43 not, though, but that's just moodle; easy enough to mentally add to the size, I guess
[03:25] <pitti> ogra_: (and server CDs are fast to build)
[03:25] <elmo> could we pretty please fix the getaddrinfo() before beta?
[03:25] <pitti> bug#?
[03:26] <elmo> LP #138466
[03:26] <ubotu> Launchpad bug 138466 in glibc "getaddrinfo() sorts result - breaks round robin DNS" [Undecided,New]  https://launchpad.net/bugs/138466
[03:26] <ogra_> pitti: err 43, sorry
=== agoliveir1 [n=adilson@201.47.58.26.adsl.gvt.net.br]  has joined #ubuntu-devel
[03:27] <elmo> it should be possible to just change the default in /etc/gai.conf, tho I haven't confirmed that
[03:28] <siretart> pitti: genisoimage testbuilt and uploaded
[03:28] <pitti> siretart: genisoimage? I thought etherboot?
[03:28] <siretart> s/genisoimage/etherboot/ of course
[03:30] <pitti> elmo: any chance you could give this a try?
[03:31] <pitti> we could sneak it into iwj's upload to avoid two new glibc
[03:31] <pitti> ... uploads
[03:32] <elmo> pitti: well, there's a demo program in the bug report, but err, yeah, I guess I could
[03:32] <pitti> elmo: ah, cool
[03:32] <pitti> iwj: ^ do you have some minutes to take a look at this, and if it's easy game, sneak it in?
[03:34] <cjwatson> I think iwj is already familiar with the issue, judging by my debian-glibc mail folder ;-)
[03:34] <pitti> seb128: I have a beagle in unapproved, but it's a new version and lots of changes; is this the one which won't ftbfs? did you sponsor this for Kevin?
[03:34] <iwj> pitti: Ah, that.
[03:34] <seb128> pitti: right, I did sponsor it
[03:34] <iwj> I think I'm willing to do that.
[03:34] <seb128> pitti: as said it was approved some time ago, if you think that's too late we will need to fix it by some other way
[03:35] <seb128> pitti: but since beagle is not used anyway, only libbeagle is triggered by nautilus that would be easier to just accept it
[03:35] <pitti> iwj: thanks; I keep your glibc upload in unapproved then and reject it when appropriate
[03:35] <ogra_> cjwatson: remember we talked about squashing up /cdrom/pool in london ? it cuts off 15M
[03:35] <iwj> pitti: If that's more convenient for you.
[03:35] <ogra_> not really a big win
[03:35] <pitti> seb128: if you are fine with it, I am, too
[03:35] <seb128> mjg59: could you comment on http://bugzilla.gnome.org/show_bug.cgi?id=154029 and maybe attach the patch you used for Ubuntu if they are different?
[03:35] <ubotu> Gnome bug 154029 in mouse "Add configuration support for touchpads (synaptics)" [Enhancement,New] 
[03:35] <seb128> pitti: cool
[03:35] <elmo> iwj/piiti: oh, we apparently don't have a new enough glibc, to pull in the gai.conf option :(
[03:35] <pitti> iwj: just to avoid two consecutive uploads and builds
[03:35] <iwj> The difficulty with any glibc change is that builds take an age.
[03:36] <iwj> Are you happy to have this new one late today or even tomorrow ?
[03:36] <iwj> elmo: Oh, damn.
[03:36] <pitti> iwj: I am, yes
[03:36] <elmo> iwj: use ronne?
[03:36] <cjwatson> ogra_: sorry, remind me?
[03:36] <Mithrandir> iwj: uh, they take an age?  They shouldn't take more than 20 minutes or so?
[03:36] <Mithrandir> which while is a bit isn't glacial in any way.
[03:36] <iwj> Mithrandir: IME takes 2h with fully primed ccache and everything in RAM.
[03:36] <ogra_> cjwatson: making pool on the CD a squashfs image
[03:37] <ogra_> and loop mounting it from d-i
[03:37] <pitti> iwj: the current change looks good, so when I hear a "no dice with the dns sorting bug" from you, I'll accept it
[03:37] <iwj> pitti: Thanks, I'll get back to you.
[03:37] <cjwatson> ogra_: interesting though I'm concerned about decreased reliability
[03:37] <Mithrandir> iwj: 2:30 on the buildds, it seems.  I tend to build on faster machines. ;-)
[03:37] <iwj> elmo: Do you have any more references about that sorting bug ?  Is there a patch I can import ?
[03:37] <cjwatson> by necessity, squashfs blows up less recoverably when there are small errors on the CD
[03:37] <ogra_> cjwatson: well, i had hoped for more than 15M :)
[03:38] <iwj> You'll have seen from my Debian TC contributions that I have a strong view on this question ...
[03:38] <cjwatson> in d-i, you might well be able to get by anyway if you don't need the broken bits
[03:38] <cjwatson> ogra_: yeah, I don't think it really justifies it
=== jsgotangco [n=JSG@ubuntu/member/jsgotangco]  has joined #ubuntu-devel
[03:39] <elmo> iwj: 2.6.1-2 in Debian, introduced any/submitted-rfc3484-sortv4.diff which AIUI allows for a toggle swich in /etc/gai.conf to restore sane behaviour
=== ogra_ shrieks 
[03:39] <iwj> elmo: Investigating, thanks.
[03:40] <ogra_> 757M
=== ogra_ cries
=== agoliveir1 is now known as agoliveira
[03:40] <cjwatson> I see that having an add-on CD simply encourages bloat ;-)
[03:41] <ogra_> well
[03:41] <pitti> ogra_: hm, edubuntu-desktop is not installable on amd64 due to gobby, so the amd64 live CDs will be outdated (also size-wise); investigating...
[03:41] <ogra_> the bloat comes from mesa
[03:41] <cjwatson> (this is a semi-serious point actually. when your constraints are less tight, there's much more temptation to rush to fill them and then you have trouble later.)
[03:42] <ogra_> (or part of it)
[03:42] <cjwatson> shouldn't gobby be demoted again? IIRC there were never MIRs for its dependencies
[03:42] <ogra_> huh ?
[03:42] <ogra_> its fine in i386 since quite a while
[03:42] <ogra_> and the deps had MIRs
[03:42] <pitti> libobby-0.4-0 |    0.4.4-3 |         gutsy | i386, lpia
[03:42] <pitti> libobby-0.4-0 |    0.4.4-3 | gutsy/universe | amd64, hppa, ia64, powerpc
[03:42] <pitti> go, change-override
[03:43] <cjwatson> ah
[03:43] <cjwatson> ok, fair enough
[03:43] <cjwatson> I need to produce a report for that inconsistency
[03:43] <pitti> meh, it might be just me, but change-override.py is hideously inconsistent; if only I could see a pattern how it fails for a bug report
[03:43] <pitti> ogra: hopefully fixed now
[03:44] <ogra_> thanks
[03:45] <cjwatson> pitti: yeah, I've had a nagging concern for a while
=== AlinuxOS [n=vsichi@87.16.133.72]  has joined #ubuntu-devel
[03:47] <AlinuxOS> Hello asac
[03:47] <pkern> cjwatson: The MIRs for the deps were approved a year ago, but as Gobby wasn't in main and thus not seeded...
[03:48] <cjwatson> on the contrary it's been seeded for a long time
[03:48] <cjwatson> not in main does not imply not seeded
=== alex-weej [n=alex@cpc2-darl3-0-0-cust237.midd.cable.ntl.com]  has joined #ubuntu-devel
=== johanbr [n=j@JBrannlund.MathStat.Dal.Ca]  has joined #ubuntu-devel
[03:49] <cjwatson> though hmm, I might be wrong that it's been seeded for a long time, I don't see it in the history
[03:49] <cjwatson> but at any rate not in main doesn't mean not seeded, because promotions are only done by hand, they're not automatic after seeding
=== mathiaz [n=mathiaz@ubuntu/member/mathiaz]  has joined #ubuntu-devel
[03:51] <seb128> cjwatson: about bug #136665, do you know if there is a way to try this dialog easily from a "standard desktop"?
[03:51] <ubotu> Launchpad bug 136665 in gtk+2.0 "Installer not navigable from keyboard" [Undecided,New]  https://launchpad.net/bugs/136665
=== mthaddon [n=mthaddon@canonical/launchpad/mthaddon]  has joined #ubuntu-devel
[03:53] <seb128> cjwatson: ok, looks like that installing ubiquity works fine ;)
[03:55] <iwj> pitti: OK, I think that patch from elmo is good, and I've changed the default in it.  It'll probably be several hours building now, since my machine has been doing some other things since the last libc build.
=== tkamppeter [n=till@bl7-104-105.dsl.telepac.pt]  has joined #ubuntu-devel
[03:55] <iwj> elmo: ^
[03:55] <pitti> iwj: awesome, thanks
[03:55] <elmo> iwj: use ronne? :)
[03:56] <cjwatson> seb128: yeah, I was going to suggest exactly that
[03:57] <pitti> elmo: btw, do you know what's wrong with artigas? https://launchpad.net/+builds complains about a socket timeout
=== cjwatson once again giggles at the breezy goal "ExpandingUniverse"
[03:58] <asac> pitti: i see that i missed the ro-RO and he-IL locales from unavail ... but where the hell was the ka-GE locale hidden?
[03:58] <pitti> asac: xpi/ka.xpi -> xpi/ka-GE.xpi :)
[03:58] <cjwatson> o/~ so pray that there's intelligent life somewhere out in space, 'cos there's bugger-all down here on earth o/~
[03:58] <asac> its not in locales.list ... nor in unavail.
[03:58] <asac> pitti: why?
[03:59] <pitti> asac: because it has always been called like that
=== rnorwood [i=rnorwood@nat/redhat/x-9eaa71d057f56e0e]  has joined #ubuntu-devel
[03:59] <asac> pitti: but it wasn't in the locales.list file
[03:59] <pitti> asac: if you wnat to rename it, we need C/R/P and a transitional package, and I didn't think that was worth the effort
[03:59] <elmo> pitti: fixed
[03:59] <asac> pitti: no i don't want to rename
[03:59] <iwj> elmo: Yes, yes, but the faff involved will be much faffier with added faff.
[03:59] <pitti> elmo: cheers (I'm currently doing lots of give-backs on sparc to get it back into shape, so appreciated)
[03:59] <asac> pitti: i want to know why its not in the locales.list file of 2.0.0.1... that i have here
[04:00] <iwj> elmo: At least this way I can get on and do something else while the computer does the hard work.
[04:00] <elmo> iwj: *shrug* k
[04:00] <pitti> asac: they might have reintroduced the translations at some later time in 2.0.0.x?
[04:00] <iwj> My DSL uplink isn't good enough so I'd have to mess about with rsync.  Oh for a good distributed filesystem etc.
[04:00] <iwj> (rsync> or worse, patch)
=== sahin_h [n=ezaz@dsl5400DBAD.pool.t-online.hu]  has joined #ubuntu-devel
[04:01] <pitti> iwj: patch -p1 < debdiff FTW :)
[04:01] <iwj> elmo: Do you have an easy setup where you could test my libc for me ?  Or a test case ?  There are some in that TC thread but I'm not sure I quite believe them.
[04:01] <iwj> If you don't have anything then fine, I'll dig them out of that thread and review them.
=== AlinuxOS [n=vsichi@host72-133-dynamic.16-87-r.retail.telecomitalia.it]  has joined #ubuntu-devel
[04:03] <asac> pitti: thats really too strange for me to bother ... the version i have here is the version that was released before :/ ... 2.0.0.1ubuntu-1
[04:03] <pitti> asac: hm, I never really pay attention to that .list file
[04:04] <elmo> iwj: http://people.ubuntu.com/~james/tmp/test.c
[04:04] <asac> pitti: to what do you pay attention? there is not even a ka-..xpi in the source i have here
[04:04] <elmo> iwj: is what I'm using, it's from the bug report, and seems to demonstrate the broken behaviour on my gutsy laptop
[04:04] <asac> pitti: oh i think i see the source of this confusion
[04:04] <mjg59> seb128: Thanks for that
[04:04] <mjg59> pitti: Hrmph. I'll look into it.
[04:04] <pitti> asac: I just look at the files in xpi/, or rather, I look at the previous ones and rename them on-the-fly when downloading new ones
[04:05] <asac> pitti: i did that
[04:05] <asac> but ...
[04:05] <asac> pitti: feisty  2.0.0.1ubuntu-1 was released on 2007-02-06 ... while gutsy  2.0.0.1ubuntu-1  on 2007-04-20
[04:05] <asac> pitti: so it looks like you added more locales in the gutsy upload
[04:06] <asac> but let me check ;)
[04:06] <pitti> asac: no, I didn't add any new locales in today's upload
[04:06] <iwj> elmo: Yep, thanks.
[04:06] <iwj> (and adnshost proves to me my nameserver is doing the right thing)
[04:06] <pitti> asac: I just renamed those three back to their previous names and removed the two now existing ones from unavail.txt
[04:08] <asac> pitti: well thats fine ... lets not bother ... its just crazy that there is no sign of those locales here on my copy of 2.0.0.1ubuntu-1. thanks for fixing it.
[04:08] <pitti> asac: np (btw, I just did another followup upload to rescue -nn-no)
[04:08] <asac> ok
=== PriceChild [n=pricechi@ubuntu/member/pdpc.supporter.student.PriceChild]  has joined #ubuntu-devel
[04:08] <pitti> yay, stuff on sparc starts to become buildable
=== andrunko [n=andrunko@200.184.118.132]  has joined #ubuntu-devel
=== ivoks [n=ivoks@0-63.dsl.iskon.hr]  has joined #ubuntu-devel
[04:14] <asac> pitti: i found that ka-ge was an unavail language ... but it wasn't in unavail.txt
=== d33p__ [n=d33p@185.144.217.87.dynamic.jazztel.es]  has joined #ubuntu-devel
=== d33p__ is now known as luisbg_
=== lakin [n=lakin@S01060013101832ce.cg.shawcable.net]  has joined #ubuntu-devel
=== mbiebl [n=michael@e180074129.adsl.alicedsl.de]  has joined #ubuntu-devel
[04:20] <fabbione> cjwatson: ok well it was my understanding that pkl was going to take over. in any case somebody from distro should.
[04:21] <fabbione> cjwatson: sorry if i misunderstood or I just don't remember it righjt
[04:21] <cjwatson> fabbione: fortunately this was all carefully documented in e-mail :-)
[04:21] <fabbione> right even
[04:21] <cjwatson> my expectation was that this sort of thing would be absorbed as general distro work, not given to a single person
[04:21] <fabbione> cjwatson: oh yeah.. it's all ok with me. again. sorry if i didn't remember it right
[04:22] <pitti> mjg59: xft FTBFSed with patch apply failure, too
[04:22] <cjwatson> just as we don't (any more) have a single person responsible for amd64 build failures
[04:22] <mjg59> pitti: Sigh. I get confused by these patch systems.
[04:22] <mjg59> pitti: Sorry about that, I'm on it now
=== pitti hugs mjg59
[04:23] <pitti> mjg59: yay quilt
[04:23] <mjg59> That's odd. I seem to have fixed the cairo one. Maybe I uploaded the wrong package.
=== josephpiche [n=josephpi@65-23-165-162-host.drtel.net]  has joined #ubuntu-devel
[04:23] <alex-weej> mjg59: are you talking about the David Turner patches for LCD filtering in Xft/Freetype/Cairo?
[04:23] <alex-weej> it improves unhinted rendering considerably
=== towolf [n=towolf@f048011019.adsl.alicedsl.de]  has joined #ubuntu-devel
[04:24] <alex-weej> on your ubuntu-devel post
[04:24] <mjg59> alex-weej: That's fine, but if I enable sub-pixel rendering we default to full hinting
[04:24] <mjg59> So the unhinted case is somewhat less interesting
[04:25] <alex-weej> mjg59: well that's only because someone decided that "LCD" means "full hinting"
[04:25] <ScottK> Is network-manager seizing control if interfaces it didn't configure on upgrade by design or a bug?
[04:25] <alex-weej> if you actually configure hinting and AA settings individually it's definitely interesting
=== j_ack [n=j_ack@p508D808A.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[04:25] <alex-weej> see dpkg-reconfigure fontconfig-config :)
=== j_ack_ [n=j_ack@p508D808A.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[04:25] <mjg59> alex-weej: I'm concerned about the default case, not anything else
[04:25] <alex-weej> mjg59: LCD isn't the default case, is it?
[04:25] <alex-weej> "Best Shapes", no?
[04:26] <mjg59> Most people with TFTs will enable it
=== towolf [n=towolf@f048011019.adsl.alicedsl.de]  has joined #ubuntu-devel
[04:26] <alex-weej> mjg59: i thought the technique was patented anyway
[04:26] <mjg59> So's the bytecode interpreter, but.
[04:26] <alex-weej> hence why we've traditionally had to install third party packages to get it
[04:26] <alex-weej> hah!
[04:26] <alex-weej> Karl was trying to convince me that Ubuntu didn't ship the BCI
[04:27] <alex-weej> anyway...
[04:27] <alex-weej> is UDS before release?
[04:27] <towolf> mjg59: concerning your revert of the font patches,
[04:27] <cjwatson> alex-weej: no
[04:27] <Keybuk> what does the patch have to do with Hinting?
[04:27] <mjg59> alex-weej: No
[04:27] <towolf> I posted a comparison on the forums, that might illustrate the quality difference
[04:27] <Keybuk> Hinting is aligning fonts to fit the appropriate grid for the display
[04:27] <towolf> http://ubuntuforums.org/attachment.php?attachmentid=43910&d=1190296125
[04:27] <alex-weej> towolf: let's see
=== ryu [n=chris@unaffiliated/ryu]  has joined #ubuntu-devel
[04:28] <mjg59> towolf: It's unambiguously worse at rendering in a case we use by default
[04:28] <Keybuk> sub-pixel makes the grid have a resolution three times higher
[04:28] <towolf> the feisty rendering is on the right
[04:28] <alex-weej> it's all about this, right? http://www.grc.com/cttech.htm
[04:28] <Keybuk> mjg59: you're complaint is specifically about the look of Monospace fonts, no?
=== mdomsch [n=mdomsch@cpe-70-124-62-55.austin.res.rr.com]  has joined #ubuntu-devel
[04:28] <mjg59> Keybuk: No, my complaint is about vertical glyphs no longer being pixel-aligned
[04:29] <Keybuk> mjg59: that's because you turned on *sub*pixel hinting
[04:29] <towolf> mjg59: so in my image you would prefer the right column?
[04:29] <Keybuk> if you want them pixel-aligned, use a non-*sub*-pixel setting?
[04:29] <mjg59> Keybuk: Argh. No. We don't have a UI mechanism for controlling whether hinting is sub-pixel or not.
[04:29] <towolf> Keybuk: he seems to prefer "stem snapping"
[04:29] <mjg59> We only have a UI mechanism for controlling whether rendering is sub-pixel or not.
[04:29] <Keybuk> mjg59: hinting is irrelevant, this is about smoothing
[04:30] <Keybuk> you want a UI option that provides sub-pixel smoothing based on hinting done at pixel resolution?
[04:30] <mjg59> No, I want my fonts to work.
[04:30] <Keybuk> (which provides incredibly out-of-shape results, but happens to make Monospace look quite crisp)
[04:30] <towolf> Keybuk: when stems are snapped by the hinting mechanism, the filtering doesn't kick in on the stems
[04:30] <towolf> that why they are plain black
[04:30] <mjg59> Keybuk: So no, I haven't turned on subpixel hinting.
[04:30] <mjg59> How could I?
[04:31] <alex-weej> i don't even think there is such a thing
[04:31] <Keybuk> mjg59: what I'm concerned about is that you've reverted a change because you don't happen to like it
[04:31] <alex-weej> there is hinting, and there is subpixel AA
[04:31] <alex-weej> Keybuk: hold on a second
[04:31] <Keybuk> without any consideration to what effect is intended
[04:31] <mjg59> Keybuk: It's not a matter of "liking". It's a regression in a common use case.
=== calc [n=ccheney@conr-adsl-209-169-124-200.consolidated.net]  has joined #ubuntu-devel
[04:31] <mjg59> A week before beta
[04:31] <Keybuk> mjg59: it's a regression that our font rendering now matches that of Windows XP/Vista and Mac OS X ?
[04:31] <alex-weej> FWIW, subpixel AA looks terrible without Scott's patches, as curved edges (i.e. stems that can't be hinted) gain yellow tinges
[04:31] <cjwatson> Keybuk: in fairness there were a lot of complaints here that didn't seem to be addressed by anyone who knew about them
[04:31] <Keybuk> ie. a regression that we now have comparable font rendering to commerical products?
[04:32] <cjwatson> #ubuntu-devel yesterday was full of "my fonts are broken"
[04:32] <Keybuk> cjwatson: reviewing the logs, I saw one complaint by ion_
[04:32] <mjg59> Keybuk: It's a regression that my fonts become less readable and give me a headache (for the first time in five years), yes
[04:32] <cjwatson> hmm, I'm sure I remember a lot more than that
[04:32] <Keybuk> cjwatson: it was a very long complaint, repeated often
[04:32] <mjg59> Which is an indication that the change should actually be discussed, rather than uploaded at this short notice
[04:32] <seb128> I didn't like the way they were yesterday
[04:32] <seb128> they looked blurry
[04:32] <Keybuk> seb128: that's what anti-aliasing does
=== Skiessi [n=qwe@dsl-roibrasgw1-fe88fb00-133.dhcp.inet.fi]  has joined #ubuntu-devel
=== mgalvin [n=mgalvin@ubuntu/member/mgalvin]  has joined #ubuntu-devel
[04:32] <Keybuk> if you don't want blurred fonts, there's a "NO ANTI-ALIAS" option
[04:32] <towolf> mjg59: it get's a lot more interesting for fonts other than vera/dejavu, i.e., where you don't have clean vertical stems.
[04:33] <Keybuk> if you like a little bit of blur round the edges, there's a "Greyscale" option
[04:33] <seb128> Keybuk: well, default setup should look good for sure no?
[04:33] <towolf> mjg59: the old style is a hack, then
[04:33] <alex-weej> the old style did no filtering
[04:33] <towolf> mjg59: http://ubuntuforums.org/attachment.php?attachmentid=43911&d=1190296417
[04:33] <Keybuk> seb128: yes, I agree; and every single person I tried the patches on said that the usual non-monospace fonts looked *much* better with the patches than without
=== jack_wyt [n=jack@123.115.242.154]  has joined #ubuntu-devel
=== mgalvin [n=mgalvin@ubuntu/member/mgalvin]  has joined #ubuntu-devel
[04:34] <seb128> Keybuk: it's not easy to make a estimation of the number of people who like something or not
[04:34] <mjg59> Keybuk: At the point where the code is intelligent enough not to have a significant reduction in quality on a common use case amongst our developers, I'm happy with it
[04:34] <seb128> that needs some time for testing and some sort of pool to ask what users who tried prefer
[04:34] <cjwatson> Keybuk: did you tell them which one was your change?
[04:34] <Keybuk> the simple fact is that with the patches, the rendering of the fonts matches (to a few degrees anyway) the output on Mac OS X and Windows XP
[04:34] <seb128> and should not be made just before a freeze like that I think
[04:34] <cjwatson> (or indicate by non-verbal cues)
[04:34] <Keybuk> cjwatson: no
[04:34] <siretart> cprov: sorry, wrong channel, actually wanted to ask you here
[04:34] <towolf> alex-weej: yes, it did, just not on the stems, which cover the biggest area of a glyph
[04:35] <alex-weej> towolf: no, it did no *filtering* http://www.grc.com/cttech.htm
[04:35] <Keybuk> perhaps we need a middle option for "broken sub-pixel hinting"
[04:35] <cprov> siretart: np.
[04:35] <alex-weej> Keybuk: it's this: http://www.grc.com/cttech.htm
[04:35] <mjg59> Keybuk: Please don't imply that the behaviour I want is broken. It's unnecessarily emotive.
[04:35] <Keybuk> mjg59: the behaviour you want is caused by code being #ifdef'd out :p
[04:36] <mjg59> Keybuk: It's ifdefed out for a reason
[04:36] <alex-weej> it's ifdef'd out because of patent reasons
[04:36] <mjg59> alex-weej: It's ifdeffed out because cairo and xft upstream have not taken those patches yet
[04:36] <siretart> cprov: thanks!
[04:36] <alex-weej> it's the only way to equalise colour balance while maintaining subpixel positioning
[04:36] <alex-weej> and hence why people always whinge that "linux font rendering is worse than Windows/OS X"
[04:37] <alex-weej> you have an opportunity here to silence those people
[04:37] <mjg59> Keybuk: Keith believes that the rendering example I showed him is broken
[04:37] <mjg59> And he's Xft upstream
[04:37] <alex-weej> the hinting algorithm is broken i guess
[04:38] <Keybuk> mjg59: did you show keith the detailed papers explaining why it's rendered like that?
[04:38] <towolf> alex-weej: you're a bit confused, the old lcd mode, it filters, but not the stems
[04:39] <towolf> alex-weej: ftp://ftp.tuebingen.mpg.de/kyb/towolf/Bildschirmfoto-1.png
[04:39] <alex-weej> towolf: what do you mean by "filters"?
[04:39] <mjg59> Keybuk: I'm fundamentally uninterested in whether it's theoretically better or not. It quite clearly isn't in this case!
[04:39] <asac> pitti: actually ka-ge is now again "Transitional package for unavailable language  "
[04:39] <Keybuk> mjg59: to me it's incredibly clearly better
[04:39] <mjg59> Keybuk: I'm talking about once very specific case here
[04:39] <asac> pitti: in 2.0.0.7+1-0ubuntu1 (m-f-l-all)
=== ogra_ trusts his eyes and they tell me they see blurry fonts on all LCDs around now
[04:39] <alex-weej> towolf: what do you mean by "old", too? :P
[04:40] <Keybuk> what is the very specifc case?
[04:40] <mjg59> Keybuk: The case I end up using for most of the day, which is a small monospaced font
[04:40] <pitti> asac: really? not here...
[04:40] <towolf> alex-weej: the pre-patch era LCD filtering code in Xft and Cairo
=== alex-weej is being selfish and would like to not have to use third-party debs to get balanced subpixel AA
[04:40] <asac> pitti: https://edge.launchpad.net/ubuntu/+source/mozilla-firefox-locale-all/2.0.0.7+1-0ubuntu1
[04:40] <Keybuk> mjg59: I said right at the top, the only case I've ever seen where people have a complaint is a small monospaced font :p
[04:40] <Keybuk> <Keybuk> mjg59: you're complaint is specifically about the look of Monospace fonts, no?
=== ryu [n=chris@unaffiliated/ryu]  has left #ubuntu-devel ["Gone] 
[04:40] <pkern> Monospace AA on OS X is disgusting... so please don't put that up as an example. ;)
[04:40] <pitti> asac: I think that's a LP bug; apt-cache show DTRT here
[04:41] <mjg59> Keybuk: Right. And, in this specific case, the change is clearly a regression in functionality.
=== lamont [i=lamont@nat/hp/x-2a2c04d4d6cd0dac]  has joined #ubuntu-devel
[04:41] <Keybuk> mjg59: so we could tackle this quite simply, with a fonts.conf adjusting the hinting for monospace fonts, no?
[04:41] <alex-weej> pkern: everyone has their opinions
[04:41] <alex-weej> Keybuk: it has nothing to do with just monospace fonts
[04:41] <Keybuk> alex-weej: do you think non-monospace look worst?
[04:41] <mjg59> Keybuk: My /perception/ is that the other fonts have better shaping but lower readability now
[04:42] <alex-weej> Keybuk: any hinted text looks terrible to me.
[04:42] <ogra_> for me its all fonts
[04:42] <mjg59> But I spend much less time looking at that than the monospace case, so I haven't tried to quantify that in any way
[04:43] <alex-weej> http://img363.imageshack.us/img363/9960/screenshotfreenodeubuntno7.png
=== AlinuxOS [n=vsichi@host72-133-dynamic.16-87-r.retail.telecomitalia.it]  has joined #ubuntu-devel
[04:44] <towolf> mjg59: what's the problem, you know you can always enable BCI hinting without any AA?
[04:44] <towolf> like in the good old days.
[04:44] <mjg59> towolf: Because I want sub-pixel AA. It makes my fonts look nicer.
[04:45] <Keybuk> mjg59: you have proper sub-pixel AA now though
[04:45] <alex-weej> mjg59: do you have a rendering of how it was when it was "nicer"?
[04:45] <mjg59> Keybuk: No, I now have sub-pixel AA plus sub-pixel positioning
[04:45] <Keybuk> you want sub-pixel anti-aliasing with hinting done on a pixel grid?
[04:45] <mjg59> Previously, a fully hinted font would align to pixel boundaries. Now that's not the case.
[04:45] <towolf> mjg59: but it means we will go back to the right column in this screenshot: http://ubuntuforums.org/attachment.php?attachmentid=43911&d=1190296417
[04:45] <Keybuk> (the difficulty there is you then need another option, None/Slight/Medium/Full Hinting and [ ]  Hint on sub-pixel alignment)
[04:45] <alex-weej> towolf: btw earlier were you suggesting that the filter somehow doesn't apply to "stems"?
=== bddebian [n=bdefrees@63.81.56.182]  has joined #ubuntu-devel
[04:46] <alex-weej> mjg59: can you see the yellow tinges everywhere on the right column?
[04:46] <towolf> alex-weej: because xft and cairo activated snapping since the filter code was so broken that it leads to intense color fringing.
[04:46] <alex-weej> that's because there's no colour balancing
[04:46] <towolf> alex-weej: as you can see in the Cambria screenshot above
[04:47] <alex-weej> towolf: do you actually know what i am talking about when i say "filter"?
[04:47] <towolf> alex-weej: nowaqdays with the turner patch we do not need the stem quantization anymore
[04:47] <alex-weej> towolf: i mean the thing that spreads pixel intensity into 3 or 5 pixels around it
[04:47] <towolf> alex-weej: yes
=== superm1 [n=superm1@ubuntu/member/superm1]  has joined #ubuntu-devel
[04:47] <bddebian> Heya
[04:48] <alex-weej> towolf: where did you get that test app from?
[04:48] <towolf> alex-weej: its "ftdiff" from freetype-demos
[04:48] <alex-weej> cheers
=== ogra_ would just like to have fonts again that dont make his eyes tear after 20min of work, no matter what theories/techniques are involved
[04:48] <towolf> alex-weej: when the source glyph does not cover fractional pixels (it's blown up originally) then there is nothing to filter. and quantizaiton does this.
[04:48] <pitti> seb128: yay, pygtk built; I have a list of the ~ 15 rdepends which I'll give back on sparc once this gets published; thanks again
[04:49] <seb128> pitti: you're welcome
[04:49] <alex-weej> towolf: ok, sounds interesting but wrong as it sort of modulates a blur -- parts of your font look more blurry than others
[04:49] <Ng> aren't small fonts generally supposed to be excluded from AA anyway?
[04:49] <alex-weej> but I use unhinted anyway
[04:49] <alex-weej> Ng: on Windows XP.
=== dexem [n=dani@220.Red-83-52-31.dynamicIP.rima-tde.net]  has joined #ubuntu-devel
[04:49] <alex-weej> by default. (ugly)
[04:50] <mjg59> Ng: No
[04:50] <mjg59> AA can do a huge amount to improve the readability of small fonts
[04:50] <Keybuk> Ng: depends who you ask
[04:50] <ogra_> you could force that once in fontconfig iirc
[04:50] <Keybuk> (arguably small fonts benefit more from sub-pixel hinting since there's three times as much resolution available :p)
[04:50] <ogra_> (no AA for small fonts)
[04:50] <Keybuk> ogra_: yeah, I thought there was a conf.avail for that, but I can't see it right now
[04:51] <Keybuk> it exists for certain fonts, but not globally
[04:51] <Keybuk> (Bitstream Vera, notably)
[04:51] <alex-weej> towolf: how did you activate the "legacy LCD filter"?
[04:51] <Keybuk> uh, sorry, that's hinting it disables
=== Lure_ [n=lure@212.103.157.37]  has joined #ubuntu-devel
[04:52] <alex-weej> Keybuk: use dpkg-reconfigure fontconfig-config
[04:52] <alex-weej> oh wait sorry, it doesn't have an option for what you said nm
[04:52] <Keybuk> alex-weej: the debconf stuff symlinks from /etc/fonts/conf.avail to conf.d
[04:53] <towolf> alex-weej: "l" key
[04:53] <towolf> alex-weej:  "legacy LCD filter" is unpatched freetype, cairo and xft
[04:53] <alex-weej> yeah it looks bad
[04:54] <towolf> alex-weej: yes.
[04:54] <alex-weej> not quite as bad as unfiltered though
[04:54] <alex-weej> tbh that's be owned -- i didn't even know there was a legacy filter -- i thought it was unfiltered heh
[04:54] <towolf> err, on anytghing else than sanserif fonts it certainly does
[04:54] <ScottK> pitti: Would you please give poker-network 1.2.0-1ubuntu1 a push out the door.
[04:54] <towolf> and on fonts that don't have massive hinting tables
[04:55] <towolf> manual hinting tables
[04:55] <alex-weej> towolf: LCD filtering != hinting though, right?
[04:55] <towolf> alex-weej: yeah
[04:55] <alex-weej> so what do you mean?
[04:55] <towolf> alex-weej: it's two separate mechanisms
[04:55] <alex-weej> yes i know
=== mdomsch [n=mdomsch@cpe-70-124-62-55.austin.res.rr.com]  has joined #ubuntu-devel
[04:55] <towolf> alex-weej: that have to harmonize
[04:56] <alex-weej> wow
[04:56] <alex-weej> for hinted text it looks really bad actually
[04:56] <alex-weej> everything goes greenish
[04:56] <towolf> alex-weej: full (hint_strong), normal (hint_medium), do not go well with the turner patches
[04:56] <towolf> alex-weej: slight is best, IMO
[04:56] <alex-weej> i think my monitor's gamma is fubared though
[04:56] <pitti> ScottK: done
[04:57] <ScottK> pitti: Thanks.
[04:57] <alex-weej> for hinted vera @ 10pt/96dpi i can't tell the difference between light and default
[04:57] <alex-weej> nor the difference between legacy and unfiltered
=== Pici- [n=Pici@ool-4355be00.dyn.optonline.net]  has joined #ubuntu-devel
[04:57] <towolf> alex-weej: and, that's the crucial point: when GNOME's prefs are set to "slight", the autohinter with all it's splendor is activated automatically in hint_light mode
[04:57] <alex-weej> ew
[04:57] <alex-weej> autohinter is terrible
[04:58] <alex-weej> it fucks up our ligatures big style
[04:58] <towolf> alex-weej: the prefs dialog in "Appearance" is just badly designed.
[04:58] <Keybuk> isn't the autohinter supposed to be not-as-good as the bytecode intepreter?
[04:58] <alex-weej> towolf: +1
[04:58] <alex-weej> Keybuk: the autohinter is much more subtle with what it does
[04:58] <towolf> Keybuk: wrong, terribly wrong.
[04:58] <alex-weej> towolf: !?
[04:58] <Keybuk> I understood that the bytecode intepreter followed the instructions in the font files
[04:58] <pitti> mjg59: thanks for the fixes, accepted; I leave the eventual decision which renderer to use to the discussion between Keybuk and you, though :)
[04:59] <towolf> Keybuk:  the autohinter si a lot less aggressive  than the old win95 days manual hints.
[04:59] <towolf> Keybuk: say, arial, timesnewroman, etc
[04:59] <mjg59> pitti: Thanks
[04:59] <alex-weej> so FT quite clearly has an option for choosing a filtering type
[05:00] <alex-weej> as i am toggling it with ftdiff
[05:00] <towolf> Keybuk: they were made with monochrome rendering in mind.
[05:00] <Ng> fwiw, after using the cleartype-style rendering for a day, I think it's superior. Interestingly, I think it makes the most difference for my little monospace fonts (lucida typewriter 6.5pt @105dpi)
[05:00] <towolf> Keybuk: how windows looked for years.
[05:00] <towolf> Keybuk: nowadays both windows (wpf) and osx disregard the bci hints completely
[05:01] <alex-weej> towolf: that's a different argument, though. people get VERY attached to their way of font rendering
[05:01] <ion_> keybuk: I wasnt the only one complaining.
[05:01] <towolf> Keybuk: i'll make a waterfall example for you
[05:02] <towolf> alex-weej: yes, the old-school blur haters
=== agoliveira is now known as agoliveira_lunch
[05:02] <alex-weej> towolf: you don't mind a tiny drop in contrast for increased readability, but you still use the autohinter?
[05:02] <towolf> alex-weej: light autohinter with turner-style filtering is a very good middle-ground actually
[05:03] <towolf> alex-weej: OSX is really muddy
[05:03] <alex-weej> towolf: maybe. the autohinter screws up ligatures though and renders f differently to ff
[05:03] <towolf> alex-weej: what?
[05:03] <towolf> alex-weej: ligatures are perfect, here
[05:03] <mjg59> As I said, I'm not fundamentally opposed to the change. What I am opposed to is making a user-visible change of this magnitude with no discussion amongst the development community, shortly before release
[05:03] <Keybuk> mjg59: I made it shortly before *BETA*
[05:03] <mjg59> These patches aren't new. There's no reason for it to be done this late.
[05:03] <Keybuk> it's not a API or ABI change, so is less relevant to the development community
[05:03] <mjg59> Keybuk: So well after feature freeze
[05:03] <Keybuk> it's a visual change, which is more relevant to get opinion from the user community
[05:04] <Keybuk> Beta is the first release which our users tend to see
[05:04] <Keybuk> so this seems to be a perfect time to make the change
[05:04] <Keybuk> since there's still plenty of time to revert it before Release if our user opinion is overwhemlingly negative
[05:04] <Keybuk> (artwork, also visual, is rarely ready before Beta)
[05:04] <mjg59> And the immediate reaction is "It causes regressions"
[05:04] <alex-weej> mjg59: i'd guess a vocal minority
[05:04] <Keybuk> mjg59: really?  so far I'd say that there's a minority reaction against it
[05:04] <mjg59> I'm happy to admit that the developer base is likely to have a different view of this than our naive users
[05:05] <alex-weej> put it this way, those who really REALLY care about their fonts don't already use Ubuntu
[05:05] <Keybuk> mjg59: making this change at the beginning of the release cycle, or FF, wouldn't make a difference
[05:05] <towolf> mjg59: we have a history of mutlipage forum threads offering patched debs, to great acclaim, since edgy
[05:05] <Keybuk> since we'd still have to wait until after Beta to make the decision
[05:05] <mjg59> Keybuk: Which would give us plenty of time before beta to get it into a state where the developers aren't unhappy
[05:05] <towolf> mjg59: mlind has been providing those debs since then , and they've been welcomed by many
[05:05] <alex-weej> including me!
[05:05] <alex-weej> mlind is a god
[05:06] <mjg59> These fonts are genuinely giving me a headache right now
[05:06] <towolf> alex-weej: err, he is a deb compiler
[05:06] <alex-weej> towolf: same thing :P
[05:06] <alex-weej> mjg59: perhaps too much thinking about them is giving you a headache? :P
[05:06] <Kopfgeldjaeger> if, lets say, kernel 2.6.23 will be finished in 1 hour, will it get it into gutsy or is the KernelFreeze meant for the current *.22 kernel?
[05:06] <Keybuk> mjg59: ok, that counts as one negative vote ... 7,999,999 votes to go? :p
[05:06] <mjg59> Keybuk: No
[05:06] <towolf> mjg59: that might be because the vera fonta suck balls.
[05:06] <alex-weej> ask mr. shuttleworth, that's what it comes down to in the end, right?
[05:06] <mjg59> Ergh. Sorry.
[05:06] <mjg59> Kopfgeldjaeger: No.
[05:07] <mjg59> towolf: They're what we ship by default.
[05:07] <towolf> *fonts
[05:07] <towolf> mjg59: :-)
[05:07] <mjg59> So, that's the case we have to work with
[05:07] <cjwatson> alex-weej: no, the technical board. note that this is two members of the TB having an argument ...
[05:07] <Trewas> one users option about the font issue here: IMO the "new" cleartype-like font rendering is clearly worse than the old and I noticed the blur immediately... fwiw, at home I am using XP and feisty on the same computer and feisty has clearly better font rendering than xp's cleartype (though I am using microsoft fonts in feisty, not the default bitstream fonts, if that changes something)
[05:07] <Keybuk> mjg59: I argue that we keep these patches in for Beta, and evaluate at the first opportunity immediately after what the public reaction is to the fonts
[05:07] <towolf> mjg59: better fontconfig default will help, though.
[05:07] <Keybuk> (which was my plan)
[05:07] <towolf> mjg59: just patching with adjustments is not enough, and
[05:07] <cjwatson> Kopfgeldjaeger: we're shipping 2.6.22, it's far too late to move to a new upstream
[05:08] <towolf> mjg59: that is likely the source of your headache
[05:08] <Keybuk> I was also half way through a mail to ubuntu-devel explaining with screenshots the differences between the two when you reverted them <g>
=== `23meg [n=m@ubuntu/member/-23meg]  has joined #ubuntu-devel
[05:08] <alex-weej> it's already been reverted?
[05:08] <towolf> *without
[05:08] <alex-weej> oh yay, status freaking quo
[05:09] <mjg59> Keybuk: It's absolutely undeniable that this change reduces the legibility of a common (admittedly not the most common) font use case.
=== Hobbsee has found that whether it's good or bad depends entirely on the font.
[05:09] <Keybuk> mjg59: disagree, for me it improves the monospace font
[05:09] <Keybuk> it makes it quite a bit more readable for me
[05:09] <Keybuk> I can actually see "m" now, it's not a filled-in block :p
[05:09] <mjg59> Keybuk: No, there really isn't any argument over this. It reduces the definition and contrast.
[05:09] <ogra_>  Keat what resolution ?
[05:10] <Keybuk> mjg59: see also "anti-aliasing"
[05:10] <ogra_> Keybuk: at what resolution ?
[05:10] <Keybuk> for definition and contrast, see "no anti-aliasing"
[05:10] <Keybuk> ogra_: 125dpi
[05:10] <mjg59> Keybuk: No, you're introducing a false dichotomy.
[05:10] <towolf> Hobbsee: that's true
[05:10] <cjwatson> mjg59: I think arguing that there is no argument when you're busy having one is perhaps a little disingenuous
[05:10] <ogra_> it makes them blurry and badly readable on 1024x768 at 96 or 100 dpi
[05:10] <ogra_> for me
[05:11] <Keybuk> (and can we stop using words like "blurry" :p  anti-aliasing *is* blurring to fool the eye to think there's a curve there)
[05:11] <mjg59> Keybuk: Vertical lines are now blurred.
[05:11] <ogra_> it produces a quite visible blur which i didnt have before the update
[05:11] <Keybuk> mjg59: no, vertical lines now include a sub-pixel component either side in many cases
[05:12] <towolf> Luxi is a nice series, too bad it's in non-free.
[05:12] <mjg59> Keybuk: Right. They're blurred.
[05:12] <Keybuk> I don't think we're going to win any "pro" vs. "con" arguments here
[05:12] <Keybuk> the real decision is whether we use Beta as a time to get a wider opinion than yours and mine
[05:12] <mjg59> Keybuk: Anti-aliasing also introduces blurring, but it does so with the aim of introducing information that wasn't there before
[05:12] <towolf> Keybuk: when the outline of the glyph says it whould be as wide as it should be.
[05:12] <towolf> Keybuk: which gains us actual proportions between bold and non-bold
=== l_ [n=l_@mix.mmjgroup.com]  has joined #ubuntu-devel
[05:13] <towolf> and not jumpy, either 1px wide or 3 px wide rendering
[05:13] <towolf> err, 2px too
[05:14] <towolf> mjg59: AA and lcd-AA is the same thing with more sophistication
[05:14] <mjg59> towolf: This isn't about AA.
[05:14] <Keybuk> for me, "m" is now rendered as brown-blue-red-blue-orange-blue
[05:14] <towolf> mjg59: did you know that aa is lcd rendering with R=G=B, nowadays?
[05:14] <Keybuk> before it was rendered as black-dark grey-black-black-dark grey
[05:15] <Keybuk> so I utterly reject your assertion that this doesn't introduce information that wasn't there before
[05:15] <mjg59> Keybuk: That's not the behaviour I saw. My ms have always been rendered using sub-pixel information around the cruves.
[05:15] <Keybuk> mjg59: around the curves yes, not between the downward strokes of the "m"
[05:15] <Keybuk> which made it look like a shaded block with a bit of a bump on top
[05:15] <mjg59> Keybuk: Hang on, let me find a machine without this update.
[05:16] <towolf> Keybuk: just enable full hinting and you will get this quantization effect back.
[05:17] <Keybuk> towolf: ?
[05:19] <mjg59> Keybuk: Ok. The effect I have with ms on the old code was "white, black, white, black"
[05:19] <alex-weej> 2 stems?
[05:19] <mjg59> With the new code I have "Blue, pale blue, purple, pale blue, purple, pale blue"
[05:19] <alex-weej> mjg59: right, but that = positional information
[05:19] <alex-weej> as it goes through your RGB grid
[05:19] <Keybuk> http://people.ubuntu.com/~scott/Terminal-1.png
[05:19] <Keybuk> vs
[05:19] <Keybuk> http://people.ubuntu.com/~scott/Terminal-2.png
[05:20] <alex-weej> looks like -2 is unhinted...?
[05:20] <Keybuk> alex-weej: probably, since the sizes reduce
[05:21] <Keybuk> and meh, those came out really small; oops
=== mvo [n=egon@p54A66ADA.dip.t-dialin.net]  has joined #ubuntu-devel
[05:21] <mjg59> Keybuk: What size font are you using, and what's your DPI set to?
[05:21] <towolf> Keybuk: the stronger the hinting the less fractional positional info is present, and hence less "color".
[05:21] <towolf> Keybuk: hinting is a quantizing process.
[05:22] <cjwatson> iwj: do you have a list of targets for adding trigger support?
=== superm1 [n=superm1@ubuntu/member/superm1]  has joined #ubuntu-devel
=== MagnusR [n=magru@c83-252-222-139.bredband.comhem.se]  has joined #ubuntu-devel
[05:24] <dholbach> is somebody looking at getting DKMS out of NEW?
[05:25] <pitti> dholbach: what's the excuse for it?
[05:25] <iwj> cjwatson: What, a list of postinst thingumies to triggerise ?
[05:25] <iwj> No.
=== illovae_ [n=illovae@unaffiliated/illovae]  has joined #ubuntu-devel
[05:25] <Hobbsee> pitti: dell stuff
[05:25] <Keybuk> sorry, regenerated the pngs
[05:25] <Keybuk> I took them in the wrong terminal mode
[05:26] <dholbach> pitti: the kernel team wants it, it will make things easier wrt building kernel modules and soname bumps of the kernel
[05:26] <cjwatson> iwj: ok, I had been wondering if fc-cache was on it, but I guess that answers that question
[05:27] <Keybuk> mjg59: I think that we've clearly established that both of us have different opinions about the readability of the resulting output
=== XSource [n=XSource@41.201.235.82]  has joined #ubuntu-devel
[05:28] <Keybuk> the true argument should be when is not appropriate to test them?
=== ogra_ simply belives his eyes that start hurting pretty fast 
[05:28] <Keybuk> (and thus gain a wider, and thus more balanced, opinion on the results)
[05:28] <pitti> I thought so yesterday, too, but today I actually got used to it
[05:28] <mjg59> Keybuk: Uh. These terminals don't seem to be the same size?
[05:29] <cjwatson> Keybuk: it looks like the font you're using in Terminal-2 is bigger
[05:29] <mjg59> Or is one of them just clipped?
[05:29] <Keybuk> mjg59: they should both have a character size of 8px
[05:29] <cjwatson> the 'i's look distinctly different in size
[05:29] <Keybuk> cjwatson: it's smaller in point size actually
[05:29] <alex-weej> mjg59, Keybuk, FT config is telling it not to hint at that small size on the older configuration
[05:29] <mjg59> Keybuk: No, they're not the same size
[05:29] <Keybuk> (they were taken on different machines, so it's not an entirely fair test)
[05:29] <mjg59> Look at the height of the characters
[05:29] <alex-weej> er... on the newer
[05:30] <mjg59> Keybuk: The 's' in scott is five pixels tall on one, four pixels on the other
[05:30] <Keybuk> I propose the following:
=== Hobbsee is greatful that most of her apps are kde - so only the webbrowser and email are a problem - but with a different font, it's not so bad.
[05:30] <Keybuk>  - ship with the patches in Beta
[05:30] <Keybuk>  - evaluate the opinion afterwards to be one of
[05:30] <Keybuk>    1) overwhemlingly positive (keep)
[05:30] <Keybuk>    2) overwhelmingly negative (reject)
[05:31] <Keybuk>    3) largely positive but with issues (remove, and defer to Hardy for more testing)
[05:31] <cjwatson> 'i's are 5 pixels vs. 7 pixels
[05:31] <Keybuk> that way we at least know whether to consider the patches for hardy if there are continuous issues with more than a very vocal minority
[05:31] <cjwatson> Hobbsee: I thought this was all xft and freetype and the like, so common to both desktops
[05:31] <Keybuk> (I myself found the monospace output wrong for about the first 6 hours of using them, now it looks perfect)
[05:32] <Hobbsee> cjwatson: that's what i thought, too.  until i saw one lot of apps looking dramatically different from the other (where i think i'd played with the kde hinting before)
[05:32] <mjg59> cjwatson: We default to full hinting if you enable sub-pixel anti-aliasing, and we have the byte-code interpreter enabled. As a result, the behaviour will differ between fonts
[05:33] <cjwatson> mjg59: what comment of mine are you replying to?
[05:33] <mjg59> cjwatson: Whether it'd be common to both desktops. It depends on the default fonts used for both
[05:33] <cjwatson> ah
[05:33] <siretart> seb128: did you notice the reject of live-initramfs due to missing orig.tar.gz?
[05:34] <seb128> siretart: no, looks like sync-source is broken, I'm not sure of what I can do
[05:34] <seb128> pitti, cjwatson: ^
[05:34] <seb128> any idea?
[05:34] <pitti> seb128: *again*?
[05:34] <pitti> *sigh*
[05:34] <seb128> looks like other syncs I did yesterday got the same issue
[05:34] <pitti> oh, it's just for that particular package
[05:35] <pitti> seb128: hm, can you please talk to cprov in #soyuz directly? he made some cherrypick changes to unbreak it at least for the non-orig.tar.gz syncs
=== agoliveira_lunch is now known as agoliveira
[05:35] <seb128> ok, thanks
[05:35] <pitti> seb128: no idea how to fix that, sorry
[05:35] <pitti> seb128: except for asking people to sync it manually with http://people.ubuntu.com/~pitti/scripts/syncpackage
[05:37] <Keybuk> mjg59: do you have an argument why not to follow my proposal?
[05:37] <alex-weej> mjg59: btw you posted the thread to ubuntu-devel, which is moderated.
[05:37] <mjg59> Keybuk: Yes. It appears to give equal weight to all providers of feedback.
[05:37] <Keybuk> mjg59: why should we not give equal weight?
[05:38] <mjg59> Keybuk: If we lose 50% of our average users, we lose 50% of our market share. If we lose 50% of our developers, we lose ~100% of our market share.
[05:38] <cjwatson> alex-weej: good
[05:38] <mjg59> This is clearly inflated, but some users are more important to us than others
[05:38] <cjwatson> the fact that ubuntu-devel is moderated is precisely a reason to hold discussions there that might get heated
[05:38] <Keybuk> mjg59: I think that case is covered by (3) in my proposal; if we see issues of concern among more than just one or two people, then we defer
=== ogra_ [n=ogra@p548ACCC2.dip.t-dialin.net]  has joined #ubuntu-devel
[05:38] <mjg59> Keybuk: Well, we've already got three here
[05:38] <alex-weej> cjwatson: in light of what mjg59 just said i guess it makes sense.
[05:39] <Keybuk> note that there are quite notable developers in here who seem to prefer the change
[05:39] <Keybuk> I do not agree that we can judge the issue with a few hours between upload and a reversion
[05:39] <mjg59> Keybuk: It would be helpful if you could generate before and after images to show the issue you're describing, because I simply can't reproduce it here
[05:40] <Keybuk> the issue is that our font rendering sucks
=== coffeedude [n=coffeedu@216.254.62.194]  has joined #ubuntu-devel
[05:40] <Keybuk> it does not compare with commercial operating systems
[05:40] <Keybuk> these patches give us rendering very comparable to those operating systems
[05:40] <mjg59> Keybuk: Yes. I contend that for the case I'm most concerned about, the new code sucks significantly more.
[05:41] <Keybuk> the fact you prefer the older rendering is not for argument, since it's apparent :)
[05:41] <Keybuk> the argument should be about the right way to find out what is better
[05:41] <mjg59> But I can also demonstrate /why/ the new code produces what I believe to be less readable results
[05:42] <mjg59> And upstream agrees with me about that
[05:42] <Keybuk> it's clear that we're not going to reach a conclusion here
[05:42] <Keybuk> keith has different issues with the patches according to mailing list archives
[05:42] <Keybuk> and a member upstream *wrote* the patches!
[05:42] <Keybuk> so that's irrelevant
[05:42] <mjg59> Keybuk: No, that's freetype upstream, not xft upstream
[05:43] <mjg59> It's the xft case I'm concerned about
[05:43] <Keybuk> ?
[05:43] <mjg59> xft is responsible for actually getting these glyphs onto the screen with X
[05:44] <mdz> Hobbsee: pardon?
=== Lure [n=lure@212.103.157.37]  has joined #ubuntu-devel
[05:45] <mdz> Hobbsee: "upstream version freeze" has, by definition, never applied to new packages
[05:45] <Hobbsee> mdz: no, bu t new package freeze certainly does.
[05:46] <Hobbsee> (which is what bryce actually meant in the bug report)
=== alex-weej_ [n=alex@cpc2-darl3-0-0-cust237.midd.cable.ntl.com]  has joined #ubuntu-devel
[05:46] <mdz> Hobbsee: I am not prepared to remark on what he may have meant, only what he said
[05:47] <cjwatson> seb128: I'm just going through old Ubuntu goals looking for things to polish in hardy, and ran across dapper-desktop-plan
[05:47] <Hobbsee> ScottK: did you want to respond?  seeing as it was your complaint.
[05:47] <cjwatson> seb128: I noticed that it called for "Main Menu" and "Menu Bar" in "Add to Panel..." to have visually distinct icons expressing the difference between them
[05:47] <cjwatson> seb128: but that the current dialog just has an Ubuntu logo for both
[05:47] <cjwatson> seb128: what happened to that?
=== ScottK reads the backscroll.
[05:48] <seb128> cjwatson: whoever was on charge of the artwork was supposed to do that (jdub?) didn't do it so nothing
[05:48] <cjwatson> seb128: ok, so it should be on the list for polish
[05:48] <seb128> right
[05:49] <towolf> mjg59: may i provide a clean comparison of the use case you proposed?
[05:50] <towolf> mjg59: it is Vera Sans Mono at 8pt: ftp://ftp.tuebingen.mpg.de/kyb/towolf/screenshot1.png
[05:50] <ScottK> mdz: In MOTU we've been using the UVF exception process to cover both UVF exceptions and New package freeze exceptions, so asking for a UVFe for the new package was consistent with what we've been doing.
[05:51] <towolf> the right side is after your revert, the left side is before the revert, but with suboptimal settings. center is authinter light mode.
[05:51] <ScottK> Hobbsee and mdz: It's not clear to me from the backscroll what Hobbsee said that you were responding to.
[05:52] <Hobbsee> ScottK: the ati bug that you were complaining about earlier?
[05:52] <ScottK> Yes, but I was trying to get the exact context that led to "<mdz> Hobbsee: "upstream version freeze" has, by definition, never applied to new packages" and couldn't find it.
[05:52] <mdz> ScottK: ok. I think that's a bit confusing, and suggest that we clarify this as part of pitti's work on consolidating freezes
[05:53] <ScottK> mdz: I agree with it being confusing.
[05:53] <ScottK> If we consolidate the freezes it would certainly make it easier.
[05:53] <Hobbsee> ScottK: because there's no current version to compare the new upstream to, as it's new to ubuntu - so as mdz says, no possibility of regressions
[05:53] <mdz> ScottK: I was responding to:
[05:53] <mdz> <Hobbsee> seb128: at this point, we've stuck a blanket deny on any new packages, unless they're really important or interesting
[05:53] <mdz> <Hobbsee> seb128: which mdz then hijacked, but that's beside the point.
[05:53] <ScottK> Ah.
[05:54] <ScottK> Yes.  The reasons for new package freeze are entirely different.
[05:54] <mdz> Hobbsee: interestingly enough, NewPackagesFreezeUniverse is one of the minority of freeze states which lacks a rationale on https://wiki.ubuntu.com/UbuntuDevelopment
[05:54] <ScottK> As I understand it, primarily because the archive admins have other stuff to do late in the release.
[05:55] <alex-weej_> towolf: how do i log on to this ftp thing?
[05:55] <Mithrandir> ScottK: actually not.  It was institutionalised at the request of MOTU as a way of forcing the MOTUs to concentrate on what was already in the archive.
[05:55] <alex-weej_> ah it worked now, just took for-fucking-ever :P
[05:55] <ScottK> Mithrandir: Ah.  That would make sense too.
[05:55] <seb128> ScottK: the freeze period is not really the busy time for the archive admin work
[05:55] <mjg59> towolf: Thanks, that looks like the comparison I see
[05:55] <towolf> alex-weej_:  does it ask for a password?
=== nags [n=nags@122.167.135.201]  has joined #ubuntu-devel
[05:55] <seb128> ScottK: there is an higher number of sync requests and new packages when there is no freeze in action ;)
[05:55] <pitti> seb128: it's for me, anyway
[05:55] <alex-weej_> tbh for hinted text the legacy filter looks better to me anyway
[05:56] <towolf> mjg59: but which is best for your eyes? i'm curious.
[05:56] <seb128> pitti: how so?
[05:56] <alex-weej_> towolf: no it worked now
[05:56] <pitti> seb128: cleaning up the archive and beat it into consistency is a huge task
[05:56] <mjg59> towolf: Certainly not the middle one
[05:56] <pitti> seb128: just because before releases this has to be done
[05:56] <ScottK> seb128: Yes and that's even with the ones we said no about.
=== IntuitiveNipple [n=TJ@alexandros.tjworld.net]  has joined #ubuntu-devel
[05:56] <Hobbsee> mdz: seems to be on https://wiki.ubuntu.com/NewPackagesFreezeUniverse (linked from your report), as much so as the others are.
[05:56] <alex-weej_> the middle one is easily more readable than either of the others
[05:56] <mjg59> towolf: The left hand one has clearly better shaping, but I find the right hand one to be more readable
[05:56] <towolf> mjg59: okay, left or right?
[05:56] <Hobbsee> mdz: but i recall you saying to me - never put down to maliciousness what you can to disorganisation.
[05:56] <seb128> pitti: we sort of try to clean up for every milestone CD
[05:56] <pitti> seb128: right
[05:56] <towolf> mjg59: hmpf.
[05:57] <pitti> seb128: but the amount of churn that piles up is amazing
[05:57] <seb128> pitti: well we slacked on that during the rest of the cycle
[05:57] <alex-weej_> towolf, Keybuk: what is the technical difference between the old and the new filters?
[05:57] <alex-weej_> towolf: the new filter is doing nothing for hinted rendering other than making it blur with colour fringes
[05:57] <seb128> pitti: try to not process NEW nor sync request for a month during the busy time of the cycle, I think the backlog would be quite impressive
[05:58] <towolf> mjg59: comparisons at such point sizes are not realistic anyway.
[05:58] <pkern> Right, middle, left, in order of preference.
[05:58] <mjg59> towolf: I think the issue is accentuated with white on black, and I'm happy to admit that I really should get round to reconfiguring my applications to be black on white
[05:58] <alex-weej_> pkern: look at the M rendering
[05:58] <mdz> Hobbsee: what does?  that doesn't seem like a rationale.  I'm not questioning the usefulness of setting a deadline for new packages, but we should document the reason for it
[05:58] <pitti> seb128: right, but if people stop packaging new crazy stuff and start concentrating on bug fixes, there shouldn't be NEW churn in the first place
[05:58] <mdz> Hobbsee: also, that description merely says that new packages in the queue won't be accepted -- it doesn't say that they shouldn't be uploaded
[05:59] <seb128> pitti: right
[05:59] <mdz> Hobbsee: in which case, the sensible workflow would be upload -> request exception -> accept
[05:59] <pkern> alex-weej_: I dislike the m rendering of the middle one and the M rendering on the right one. But considering that a looks weird too on the right, hm...
[05:59] <Hobbsee> mdz: which then sticks more work on the archive admins, though.  and they have too much stuff to do as it is.
[06:00] <towolf> alex-weej_: http://lists.nongnu.org/archive/html/freetype/2006-04/msg00012.html
[06:01] <Hobbsee> mdz: the aim, from my POV, is to not let things even get thru to the archive admins without exceptions.  it's not their job to send it back, etc.
[06:01] <alex-weej_> towolf: no i've seen this before, this is just a change to the hinting algorithm, no?
[06:01] <mdz> Hobbsee: how does it create more work for the archive admins?
[06:01] <mdz> Hobbsee: as I understand it, they'll just stop looking at the queue at the appropriate time
[06:01] <alex-weej_> pkern: http://img529.imageshack.us/img529/6056/demott4.png
[06:01] <Hobbsee> mdz: to have to check if exceptions are granted for everything that's in their queue
[06:02] <Hobbsee> mdz: which makes them never deal with any exceptions, no?
[06:02] <towolf> mjg59: well, not necessarily, I'm quite happy with white-on-black
[06:02] <Hobbsee> mdz: then again, this is only for this release anyway.  who knows what will happen next release.
=== mc44 [n=mc44@unaffiliated/mc44]  has joined #ubuntu-devel
[06:02] <pkern> alex-weej_: Gutsy one looks like OS X, which I dislike heavily.
[06:02] <mdz> Hobbsee: presumably the archive admins are notified of exceptions, in which case they just accept the specific package which has been excepted. no need to look at anything else in the queue
[06:02] <pkern> alex-weej_: I hate working in terminals which this AA behaviour.
[06:02] <mjg59> towolf: The light blue blends into the white background much more readily than it does the black background
[06:03] <pkern> s/which/with/
[06:03] <towolf> alex-weej_: the difference is that turner implemented a several tap FIR filter
[06:03] <mdz> Hobbsee: they would act based on the exceptions, not the packages (which should be much lower volume)
[06:03] <towolf> mjg59: you forget that it is alpha blended
[06:03] <alex-weej_> towolf: but what was the OLD filter?
[06:03] <Hobbsee> mdz: currently, there's hte understanding that anything in the queue has an exception, so they dont need to check it.  however, your logic would work too.
[06:03] <ScottK> Agreed it's sensible, just not how we've been doing it.
[06:03] <pkern> alex-weej_: But it's personal preference, somehow. (:
[06:03] <Hobbsee> mdz: (and conversely, that anything *not* in the queue does nto have an exception)
[06:03] <mjg59> towolf: I see light blue aspects on the black backgrounds as well
[06:04] <alex-weej> pkern: i don't see how there is any difference between the two on the left
[06:04] <alex-weej> pkern: OS X doesn't hint
[06:04] <pkern> alex-weej: Probably I should just try it out (as soon as the new daily builds are done)...
[06:04] <cjwatson> Hobbsee: the archive team can't realistically act on the assumption that people are honouring all freeze states
[06:04] <mdz> Hobbsee: ideally, folks would go ahead and upload, and if they don't get an exception, their upload should automatically be redirected to the next release when it opens
[06:04] <pkern> alex-weej: You really don't see a difference between the two?
=== fedefede0101 [n=Fede@host30-83-dynamic.50-82-r.retail.telecomitalia.it]  has joined #ubuntu-devel
[06:04] <Hobbsee> cjwatson: if they cant follow the rules, then why do they have upload rights?
[06:04] <pkern> alex-weej: The chars all have green borders here.
[06:04] <alex-weej> pkern: other than a green tinge because my monitor is uncalibrated
[06:04] <Hobbsee> mdz: indeed, ideally.  although, then the changelog would be wrong, etc.
[06:04] <cjwatson> Hobbsee: if everyone followed all the rules, we wouldn't need archive admins
[06:05] <mdz> Hobbsee: "trust, but verify"
=== sooth [n=user@bas16-montreal02-1242357234.dsl.bell.ca]  has joined #ubuntu-devel
[06:05] <Hobbsee> cjwatson: yeah, well.  there is that.
[06:05] <mdz> Hobbsee: the changelog is already non-authoritative (e.g., syncs)
[06:05] <sooth> Is Gutsy in beta freeze now?
[06:05] <Hobbsee> mdz: true
[06:05] <Hobbsee> sooth: /topic
[06:05] <sooth> Hobbsee: Ah, sorry. Missed it.
[06:05] <sooth> Hobbsee: Thanks
[06:05] <cjwatson> mdz: although it's easy to tell in the case of syncs that it's non-authoritative, because the distribution doesn't match a valid Ubuntu one
[06:05] <towolf> mjg59: a really big factor is the actual lcd in front of you, and how far you are seated away.
[06:05] <mjg59> towolf: Right. I'm about a foot away from the screen, and can't really alter that
[06:05] <towolf> mjg59: maybe be visual acuity, too ;-)
[06:06] <cjwatson> mdz: with your proposal the property that if you see an Ubuntu release name then it probably means what it says would be greatly diluted
=== sooth [n=user@bas16-montreal02-1242357234.dsl.bell.ca]  has left #ubuntu-devel ["ERC] 
[06:06] <pkern> alex-weej: You are right, unhinted looks more like OS X, I'm sorry. Some time has passed since I used it.
=== Kmos [n=gothicx@unaffiliated/kmos]  has joined #ubuntu-devel
[06:06] <mdz> cjwatson: I'd argue that with PPA that's unavoidable anyway
=== PriceChild [n=pricechi@ubuntu/member/pdpc.supporter.student.PriceChild]  has joined #ubuntu-devel
[06:06] <mdz> the changelog has never been the right place for that information
[06:07] <mdz> the destination of the upload is independent of its contents
[06:07] <Hobbsee> mdz: s/ubuntu release name/ubuntu release name and ubuntu version/ then
[06:07] <cjwatson> but it is awfully convenient as such
[06:07] <towolf> mjg59: how about this snippet?
[06:07] <towolf> mjg59: ftp://ftp.tuebingen.mpg.de/kyb/towolf/screenshot3.png
[06:07] <cjwatson> I think PPA should be gutsy-ppa etc., in fact
[06:07] <alex-weej> towolf: can you use imageshack or something? the FTP connection takes ages
[06:08] <towolf> alex-weej: too lazy to put up with it.
[06:08] <cjwatson> mdz: it slows investigation down greatly if one has to go to the network all the time
[06:08] <mdz> cjwatson: what type of investigation?
[06:08] <iwj> pitti: I'm going to want to dump a new dpkg on you I'm afraid.
[06:08] <cjwatson> mdz: investigation of problems and roughly when they appeared, correlating with bug reports
[06:08] <pitti> iwj: sure, what does it change?
[06:09] <cjwatson> e.g. if a reporter says a problem appeared in feisty, you grep back for feisty in the changelog
[06:09] <iwj> In bug 137191 someone reported dpkg randomly getting EBADF on some file.
[06:09] <ubotu> Launchpad bug 137191 in update-manager "package update-manager 1:0.69 failed to install/upgrade: failed to fstat previous diversions file" [Undecided,Incomplete]  https://launchpad.net/bugs/137191
[06:09] <mjg59> towolf: Hm. Sorry, your server suddenly seems unenthusiastic about talking to me
[06:09] <Hobbsee> cjwatson: but hey, at least we've lost the binary mangling, i think.
[06:09] <Hobbsee> cjwatson: (on ppa's)
[06:09] <cjwatson> sure, I could go to Launchpad and ask for the exact versions, and sometimes I do that later
[06:09] <cjwatson> but the changelog is an incredibly convenient local cache which is much faster to search
[06:09] <iwj> I investigated and there were several error cases where an fd is closed twice, and worse during normal processing it closes the fsys archive pipe fd twice.
[06:09] <iwj> If you're lucky the second close (which happens quite late) gets EBADF.
[06:09] <lamont> pitti: et al: mind if I do a no-change upload of sysvinit to trigger the hppa build?
[06:09] <cjwatson> and I think it is useful to put some effort into maintaining it for that purpose
[06:09] <mdz> cjwatson: how about if the changelog for binary packages was generated at build to reflect where it was actually uploaded?
[06:10] <iwj> If you're unlucky that fd is now used for something else and things can go badly wrong.
[06:10] <pitti> lamont: fine for me
=== fedefede0101 [n=Fede@host30-83-dynamic.50-82-r.retail.telecomitalia.it]  has left #ubuntu-devel ["ciaociao..."] 
[06:10] <towolf> mjg59 alex-weej:sorry for that: http://img338.imageshack.us/img338/1012/screenshot3ij8.png
[06:10] <iwj> So I have a 200-line hard-to-review patch which fixes these things.
[06:10] <cjwatson> mdz: when I'm doing this kind of investigation I usually already want to have the source package in hand, so no, I'm afraid I would just find that hopelessly confusin
[06:10] <cjwatson> g
[06:10] <iwj> I'm going to build it and test a biggish upgrade run with it.
[06:10] <iwj> (tribe 5 -> current)
[06:11] <alex-weej> towolf: the new filter only seems to use 3 taps
[06:11] <mdz> cjwatson: I don't like the guessing game that folks have to play about whether the archive admins have time to process a new package
[06:11] <mdz> there should be a clear cutoff, and packages which meet the cutoff should be processed
[06:12] <Hobbsee> mdz: ..there is.
[06:12] <pitti> iwj: sounds like fun
[06:12] <cjwatson> mdz: I have no argument there, but I do not agree that the corollary of doing some weird automagic with whatever remains follows from that
[06:12] <mdz> Hobbsee: https://wiki.ubuntu.com/NewPackagesFreezeUniverse
[06:12] <Hobbsee> mdz: but there are exceptions for important stuff afterwards?
[06:12] <mdz> Hobbsee: "Note: This means you should upload new packages in time for them to get reviewed by the archive admins and moved into the archive before this day."
[06:13] <Hobbsee> mdz: yeah.  should.
[06:13] <cjwatson> I think the short-term benefits to uploaders of doing that are more than offset by the long-term detriment of confusion
[06:13] <alex-weej> towolf: i think if it used 5 taps it would be better
[06:13] <mjg59> towolf: That appears to be a render of the pre-revert behaviour?
[06:13] <Hobbsee> mdz: our sponsorship team isnt big enough to get everything reviewed ages before the freeze - particularly if we were to go thru sync requests, etc, by that time too.
[06:13] <towolf> alex-weej: 5-tap is in lcd-light
[06:13] <towolf> mjg59: yes
[06:14] <alex-weej> towolf: ahhhh!
[06:14] <mjg59> towolf: Ok, that precisely matches what I'm seeing
[06:14] <Hobbsee> mdz: certain people like floodbombing the sync queue.
[06:14] <towolf> mjg59: ok, then we hit the taste barrier. *discussion ends*
[06:14] <mdz> Hobbsee: once the deadline has passed, the archive admins should clear out the backlog and not process any requests received after the deadline
[06:14] <cjwatson> Hobbsee: in this case, I think the cutoff should be in terms of when the exception is granted and the package uploaded, not in terms of when it is processed
[06:14] <towolf> mjg59: de gustibus ...
[06:14] <iwj> pitti: Yers.
[06:14] <Hobbsee> cjwatson: indeed - and when are you proposing this cutoff?
[06:15] <Hobbsee> cjwatson: afaik, this already happens, for NPF.
[06:15] <iwj> pitti: The new triggers code makes it more likely that it bits because it has some extra fds that it opens.
[06:15] <iwj> s/bits/bites/
[06:15] <cjwatson> Hobbsee: the point where the new package freeze currently sits is fine
[06:15] <cjwatson> Hobbsee: it's just that the documentation makes it hopelessly unclear, and so we have to have the debate about what it means every release
[06:16] <Hobbsee> cjwatson: so in that case, the one that mdz ack'd last night - that should never go in?
[06:16] <Hobbsee> cjwatson: true.  hopefully it will get fixed near UDS>
=== jeromeg [n=jerome@gra94-2-82-66-142-60.fbx.proxad.net]  has joined #ubuntu-devel
[06:16] <mdz> Hobbsee: no, we're not talking about changing the process for exceptions, only about what happens at the cutoff
[06:16] <cjwatson> that sounds like an explicit exception granted by a member of the release team (or its superior, the technical board), to me
[06:16] <mdz> things submitted before the cutoff shouldn't be rejected due to lack of time
[06:16] <mdz> if there isn't enough time, the freeze should be moved earlier
[06:16] <alex-weej> towolf: it does seem like something is wrong...
[06:17] <Hobbsee> mdz: then more exceptions get filed about massively important packages (supposedly), and the problem is still there.
=== heno [n=henrik@ubuntu/member/heno]  has joined #ubuntu-devel
[06:17] <mdz> cjwatson: what that was was a correction of terminology which was interpreted as an exception because the terminology used was consistent with what the release team apparently expect
[06:17] <ScottK> Hobbsee: We just say no more then.
[06:17] <towolf> alex-weej: what is wrong?
[06:17] <Hobbsee> mdz: as far as i'm concerned, the NPF / UVF thing works fine.    it's just the number of exceptions that go thru.
[06:17] <alex-weej> towolf: http://img509.imageshack.us/img509/5721/screenshotfreetypetextpji1.png
[06:18] <ScottK> That and the undocumented exceptions.
[06:18] <Hobbsee> mdz: (modulo syncbombs)
=== unggnu [n=unggnu@unaffiliated/unggnu]  has joined #ubuntu-devel
[06:19] <cjwatson> Hobbsee: anyone in an exception-granting team who isn't comfortable saying no quickly shouldn't be in that team
[06:19] <unggnu> hi all
[06:19] <Hobbsee> cjwatson: indeed.  i dont think we have that problem
[06:19] <lamont> no
[06:19] <alex-weej> towolf: forgetting the fact that BCI sucks, in the event of a genuine 1 screen-pixel wide line, this is what we're getting
[06:19] <lamont> :-)
=== Hobbsee is starting to suspect that we're all arguing over different things.
[06:19] <towolf> alex-weej: pathological cases
[06:20] <unggnu> mjg59, Could you tell me what is wrong with the fix in this bug report https://bugs.launchpad.net/bugs/136380 please?
[06:20] <ubotu> Launchpad bug 136380 in acpi-support "[Gutsy]  sonybright.sh doesn't use the correct value range" [Undecided,New] 
[06:20] <towolf> alex-weej: test with flowing, normal english text instead.
[06:20] <lamont> Hobbsee: it sounded to me like you were grumbling about people mailbombing the sync queue
[06:20] <alex-weej> towolf: that's not the point...
[06:20] <alex-weej> towolf: actually what is very interestng
[06:20] <alex-weej> is that if i make all the text unhinted
[06:20] <ScottK> lamont: That happened.  We had 3 or 4 MOTUs working full time to clean up the mess left by one guy.
[06:20] <Hobbsee> lamont: that was a side issue.
[06:20] <lamont> pathological cases are _ALWAYS_ the more interesting
[06:20] <alex-weej> the "legacy" filter becomes the green one
[06:21] <Hobbsee> lamont: the guy has been roasted repeatedly, and if he dares to do it again next cycle....he's going to get officially roasted, or the sponsorship team will all stop processing things.  or something equally bad.
[06:21] <towolf> alex-weej: ah, that's the effect david turner talked about in that stem quantization email.
[06:21] <alex-weej> maybe i should read it again
[06:22] <alex-weej> i think we're going to have to concede defeat though
[06:22] <alex-weej> while people are using the BCI
[06:22] <alex-weej> it is just going to look better without the FIR
[06:22] <towolf> we should disable the BCI in LCD mode. simple.
[06:22] <towolf> at least in the default.
[06:22] <towolf> it is counterproductive
[06:22] <alex-weej> and i agree with you
[06:22] <alex-weej> but as i said earlier
[06:22] <lamont> cjwatson: expect makes me vomit
[06:23] <alex-weej> some people grow VERY attached to their font rendering
[06:23] <towolf> this is not the 90s anymore.
[06:23] <lamont> alex-weej: s/some/many/
[06:23] <mdz> Hobbsee: so if you leave the freeze where it is, but the admins agree to process the backlog, you shouldn't get any additional exception requests, and the confusion would be resolved
[06:23] <lamont> s/VERY/VIOLENTLY/
[06:23] <alex-weej> lamont: including myself, apparently
[06:23] <alex-weej> lol
[06:23] <Keybuk> towolf: you mean a patch to change the default hinting to Light with Subpixel?
[06:23] <towolf> alex-weej: ... the taste barrier
[06:23] <alex-weej> or just do the OSX thing and use unhinted
[06:23] <towolf> Keybuk: I have no idea how this fontconfig mess works.
[06:24] <alex-weej> it's not fc
[06:24] <lamont> towolf: to quote a friend "did they break fonts _AGAIN_ in [$distro] "
[06:24] <alex-weej> it's some hardcoded settings in gnome font properties i think
=== lamont pokes milli, just for giggles
[06:24] <Hobbsee> mdz: should not, yes.  is it actually always motu-uvf's call about whether the exceptions get granted, or can ubuntu release team, and yourself step in and grant exceptions at will?
[06:24] <Hobbsee> mdz: i think that's the real issue here
[06:24] <ScottK> mdz: We'll certainly get requests.  We'll just say no in virtually all cases.
[06:24] <towolf> Keybuk: The first step in gutsy+1 should be user interface changes in the preferences.
[06:24] <alex-weej> i can work on thaty
[06:25] <Keybuk> towolf: a patch for that was queued, but didn't get a chance before mjg59 reverted the others
[06:25] <towolf> Keybuk: david turner proposed a redesign of the fialog here: http://article.gmane.org/gmane.comp.lib.cairo/9347
[06:25] <ScottK> Hobbsee: I'd say that they can grant exceptions at will.  The question is more if they should.
[06:25] <alex-weej> we should have "Windows-style", "OS X-style" and custom preferences
[06:25] <cjwatson> Hobbsee: in the same way that ubuntu-core-dev can upload to universe and multiverse, the Ubuntu release team and technical board can make decisions about universe and multiverse (but will not normally do so since the routine practice is delegated)
[06:26] <towolf> alex-weej: unhinted bleeds out too much, in my eyes.
[06:26] <alex-weej> towolf: you got the number of taps ther wrong way around
=== milli wiggles
[06:26] <alex-weej> towolf: unhinted is the only way to scale reliably without having to re-layout
[06:26] <alex-weej> zoomable UI baby
[06:26] <Hobbsee> cjwatson: fair enough.  ScottK, i'd suggest you document that somewhere.
[06:27] <ScottK> Hobbsee: Suggestions on where?
[06:27] <ScottK> I agree with it too.
[06:27] <Hobbsee> ScottK: motu ML, perhaps.
=== Zic [n=Zic@ubuntu/member/zic]  has joined #ubuntu-devel
[06:28] <mdz> Hobbsee: it's a motu decision (apparently delegated to motu-uvf), which could be appealed to the release team or ultimately the tech board if there is contention
[06:28] <mdz> (or some other exceptional circumstances, like an urgent request when the right people are not available)
[06:28] <alex-weej> "- there is no point in having a "monochrome" rendering mode, like we  do currently, it just looks ugly unless you have activated native  TrueType hints, so make this explicit in the interface." i disagree with that
[06:28] <ScottK> Agree with that.  It just hasn't always happened that way.
[06:28] <alex-weej> high DPI
=== jeromeg [n=jerome@gra94-2-82-66-142-60.fbx.proxad.net]  has left #ubuntu-devel [] 
[06:29] <mdz> ScottK: it was not my intention to make a decision on the request; I was confused by the terminology
[06:29] <milli> ScottK: fwiw, _I_ vehemently care about _non_-anti-aliased fonts.
[06:29] <mdz> ScottK: which I think needs a lot of cleanup (hence my discussion with pitti about it)
[06:29] <Hobbsee> mdz: would have thought you'd give it 24+ hours and such.  but OK.
[06:29] <ScottK> mdz: Agreed on the fact that the current situation is confusing.
[06:30] <pitti> still waiting for some answers on the ML before I actually change it
[06:30] <Hobbsee> pitti: the freeze stuff?
[06:30] <Hobbsee> yes, i need to reply to that.
[06:30] <Hobbsee> (as the head of universe sponsorship queue
[06:30] <Hobbsee> )
[06:31] <ScottK> pitti: I also think that we need a documented spot for all of the distro release specific exceptions.
[06:31] <pitti> ScottK: agreed, and that's the plan already
=== bryce [n=bryce@c-67-169-207-142.hsd1.or.comcast.net]  has left #ubuntu-devel ["Ex-Chat"] 
=== jamesh_ [n=james@canonical/launchpad/jamesh]  has joined #ubuntu-devel
[06:32] <pitti> ScottK: once we agree to the set of freezes, the links behind them will give details
[06:32] <ScottK> OK.
=== bryce [n=bryce@c-67-169-207-142.hsd1.or.comcast.net]  has joined #ubuntu-devel
[06:32] <pitti> ScottK: and FreezeExceptionProcess, of course
[06:32] <ScottK> In particular, there is a set of packages for UME that has a standing exception.  Which packages those are won't be clear to people not involved in UME.
=== kalpik [n=kalpik@122.162.162.136]  has joined #ubuntu-devel
[06:37] <mathiaz> keescook: do you have testcases for avahi-daemon in your automatic testing suite ?
[06:38] <keescook> mathiaz: nope :(
[06:38] <keescook> wait
[06:38] <keescook> yes, minimal.
[06:39] <mathiaz> pitti: regarding the dhclient apparmor profile, I've got a minimal one but I still to test it more.
[06:39] <keescook> it tests registration.  so, really it's an mdns test, not a link-local test.
[06:39] <pitti> mathiaz: hm, I'm afraid it gets pretty late for that kind of change
[06:39] <mathiaz> pitti: yeah. So I think we should defer the change for hardy.
[06:40] <milli> alex-weej: fwiw, I have Feisty and use Monochrome, Smoothing = None, Hinting = Full, to get fonts to look _decent_
[06:40] <alex-weej> milli: and you have truetype fonts with hints designed for bilevel rasterisation
[06:40] <milli> I'll be very upset if monochrome disappears, or at least it's meaning, which is "don't anti-alias"
[06:40] <alex-weej> milli: i assume Tahoma or something
[06:40] <pitti> mathiaz: agreed
[06:41] <milli> alex-weej: yes
[06:41] <mathiaz> pitti: I've investigated the reason why the profile doesn't get applied on boot.
[06:41] <mathiaz> pitti: it seems that it's due to start-stop-daemon.
[06:41] <alex-weej> milli: i don't think it should disappear.
[06:41] <milli> alex-weej: there has always been a disconnect between what FontConfig has for options and what's in the Gnome properties sheet
[06:41] <alex-weej> totally
[06:42] <milli> alex-weej: ah, you were quoting someone else?  (just noticed the "'s)
[06:42] <alex-weej> hehe
[06:42] <alex-weej> i disagree because on a hypothetical 500dpi screen, you probably don't want AA at all
[06:42] <milli> Arial is the font I use pretty much everywhere
[06:42] <alex-weej> like printers
[06:43] <alex-weej> Arial's hinting is /aggressive/
[06:43] <alex-weej> totally different font for every point size
[06:44] <milli> I must say, and I've heard comments to this effect, if you can't render fonts _BEAUTIFULLY_, or at least up to par with Windows and OS X out of the box, it's an in-your-face kind of thing and a turn off.  It _will_ slow adoption of Linux on the desktop.  That has been the case for a long time.
[06:45] <milli> That's my rant about fonts.  I was so disappointed with Edgy because no combination of fonts or settings looked good in OpenOffice and I couldn't believe it got released like that.
[06:46] <alex-weej> OpenOffice does its own thing
[06:46] <milli> But only a handful of people screamed about it.
[06:46] <alex-weej> as does Gecko
[06:46] <milli> yes, I have since found out.
[06:46] <milli> and stopped screaming
=== dendrobates [n=dendroba@adsl-065-005-186-012.sip.asm.bellsouth.net]  has joined #ubuntu-devel
=== AlinuxOS [n=vsichi@host72-133-dynamic.16-87-r.retail.telecomitalia.it]  has joined #ubuntu-devel
=== ogra_ [n=ogra@p548AD919.dip.t-dialin.net]  has joined #ubuntu-devel
[06:48] <milli> alex-weej: w.r.t. AA, I find that all is does is make fonts look blurry, which gives me a headache.  It works for print media, not for screen IMHO.
[06:48] <alex-weej> print doesn't AA...
=== kagou [n=kagou@77.194.192.226]  has joined #ubuntu-devel
[06:48] <alex-weej> print draws at 720dpi :P
[06:48] <Keybuk> at 600dpi, you kinda don't need too :p
[06:50] <alex-weej> the real solution to all of this mess is to 1) stop doing hinting, 2) stop doing any form of anti-aliasing whatsoever, 3) render the entire desktop scene at 3nn oversampling, 4) filter the whole scene
[06:50] <milli> what I mean then, is brochure ware stuff, etc, created with Photoshop (or GIMP) where the fonts are blended / anti-aliased on the page..
[06:50] <alex-weej> fonts shouldn't be the only thing that get the benefit of subpixel positioning
=== ompaul [n=ompaul@freenode/staff/gnewsense.ompaul]  has joined #ubuntu-devel
[06:51] <alex-weej> milli: if you're doing print media in photoshop then you suck
[06:51] <milli> alex-weej: I'm not ;-)
[06:51] <alex-weej> :P
=== milli forgot what room he was in for sec
[06:51] <IntuitiveNipple> alex-weej: I think someone's doing that - couple of bug reports today about 'fuzzy' icons in Clearlooks that I see as sharp as a knife :p
[06:52] <milli> That should be ....  "GIMP (or Photoshop)"
[06:52] <alex-weej> IntuitiveNipple: no that's because 24px icons are being sized at 22px
[06:52] <IntuitiveNipple> alex-weej: I don't see the fuzzy ones and I've not changed anything - why would that be?
[06:52] <alex-weej> IntuitiveNipple: icon theme
[06:52] <alex-weej> Clearlooks mandates 22px toolbar icons
[06:53] <alex-weej> including the stuff in the main menu
[06:54] <IntuitiveNipple> I checked the theme based on what the bug-reporter said, and Clearview is using GNOME, and they are crisp and sharp with all today's updates.
[06:54] <alex-weej> mjg59: i just read your email -- the positioning of stems is the same with both filters
[06:55] <alex-weej> IntuitiveNipple: because GNOME Icon Theme is a tango-theme
[06:56] <alex-weej> i.e. it has 22px icons
[06:56] <alex-weej> Human, for example, has 24px
=== gicmo [n=gicmo@91.64.103.94]  has joined #ubuntu-devel
[06:57] <IntuitiveNipple> alex-weej: ok, maybe I'm confused, but I understood from the bug-reporter that is icons in use there, and he/she is seeing them fuzzy.
=== cromo [i=cromo@klej.net]  has joined #ubuntu-devel
[06:57] <alex-weej> yes that's because they are being resampled, and 24 does not divide by 22
[06:58] <IntuitiveNipple> alex-weej: I understand that; what I'm not clear on is why, if I've seemingly selected the same theme/Icons, why I appear to get a different result.
[06:58] <cromo> hi. I dist-upgraded from perfectly working feisty to gutsy and now experience weird hang ups. It will hang up after about 10 minutes after logging in from gdm, but it can't work for hours under console (like now) without problems.
[06:58] <alex-weej> maybe we're barking up the wrong tree, then.
[06:59] <cromo> sys-rq keys seems to work sometimes, sometimes they don't
[06:59] <alex-weej> cromo: graphics card overheating?
[06:59] <cromo> doubt so
[06:59] <cromo> it's radeon 9200
[06:59] <IntuitiveNipple> alex-weej: I don't play with theme customisations at all so my system is whatever the default installs are, which is why I thought to compare when I saw the bug-report
[06:59] <alex-weej> cromo: have you checked your kernel logs?
[06:59] <cromo> and the mouse pointer works fine
[06:59] <cromo> yes, nothing there
[06:59] <cromo> for me it looks like scheduler problem
[06:59] <alex-weej> tried a different driver?
[06:59] <cromo> but the mouse works? I guess it's not the graphics then
[06:59] <alex-weej> no
[07:00] <cromo> I mean, I can move it, but can't click on anything
[07:00] <alex-weej> have you tried vesa?
[07:00] <cromo> also, it alwyas hangs when the cpu is at 100% usage
[07:00] <cromo> I will
[07:00] <cromo> but I doubt that it will help
=== hunger grumbles. Now I have beagle, tracker and strigi installed... Could you please trim down the number of desktop searches a bit?
[07:02] <alex-weej> bbl simpsons
[07:02] <alex-weej> +food
[07:03] <cromo> ok, I run X with vesa driver
[07:03] <cromo> let's see...
=== macd_ [n=d@cl-151.ewr-01.us.sixxs.net]  has joined #ubuntu-devel
[07:05] <mathiaz> pitti: what about adding the dhcp client profile to the apparmor-profile package (which is in universe) ?
[07:05] <cromo> btw, these lockups happened for bopt .192 and .193 radeon driver
[07:05] <pitti> mathiaz: that's fine for me
[07:05] <pitti> mathiaz: if the profile works for the derooted client, too?
[07:05] <pitti> mathiaz: e. g. the derooted one needs cap_setuid
[07:06] <towolf> mjg59: whoa, just read your email. your whole argument hinges on an example that would rarely occur in real life. go up 4pt and the story looks entirely different.
[07:06] <mathiaz> pitti: that'S right.
=== frafu [n=frafu@ip-88-207-204-244.dyn.luxdsl.pt.lu]  has joined #ubuntu-devel
[07:06] <mathiaz> pitti: the profile is a little bit different (wrt the capabilities).
[07:06] <towolf> mjg59:  8pt has always been a corner case in displaying fonts.
[07:07] <mathiaz> pitti: but at least we can ship something and get it tested.
[07:07] <towolf> mjg59: there's always xterm at your disposal. or MGT if you prefer tabs.
=== frafu [n=frafu@ip-88-207-204-244.dyn.luxdsl.pt.lu]  has left #ubuntu-devel [] 
[07:09] <mjg59> towolf: "Your use case doesn't matter" is a poor argument
[07:09] <mjg59> Since it pretty clearly matters to me :)
[07:10] <mjg59> The aim should be to find ways of introducing changes like this /without/ upsetting people
[07:11] <mjg59> Which I believe to be achievable, just not in the amount of time we have
[07:11] <towolf> mjg59: so you sit 30cm away from the creen because your fonts are at 8pt?
[07:12] <towolf> mjg59: now i see ...
[07:12] <towolf> *screen
[07:12] <mjg59> towolf: No, I sit 30cm away from the screen because I use a laptop and work from bed
=== tehk [n=tehk@c-69-249-157-157.hsd1.nj.comcast.net]  has joined #ubuntu-devel
=== ogra1 [n=ogra@p548AD919.dip.t-dialin.net]  has joined #ubuntu-devel
[07:13] <unggnu> mjg59, hi, could you please say something to wrong sonybright.sh value range? https://bugs.launchpad.net/bugs/136380
[07:13] <ubotu> Launchpad bug 136380 in acpi-support "[Gutsy]  sonybright.sh doesn't use the correct value range" [Undecided,New] 
[07:14] <mjg59> unggnu: I haven't had time to test it
[07:14] <unggnu> Ok, thanks.
=== ant30 [n=ant30@85.136.35.228.dyn.user.ono.com]  has joined #ubuntu-devel
[07:16] <towolf> mjg59: my position would be: let's defer until a better GUI is available. freetype still ships with lcd_legacy in the code, and enabling it would better a matter of a drop-down combined with the proper fontconfig magic.
[07:16] <towolf> mjg59: it's not either or, both styles are possible. (at the cost of confusion potential)
[07:16] <mjg59> towolf: Right. Once we can handle these cases automatically, I've got no objection
[07:17] <mjg59> But we're not going to be able to do that in time for release
[07:18] <towolf> mjg59: i agree, but Keybuk's scheduling point had merit.
=== highvoltage [n=highvolt@dsl-243-59-26.telkomadsl.co.za]  has joined #ubuntu-devel
[07:18] <mjg59> towolf: No, if we push it into the beta then it looks bad if we remove it again
[07:18] <towolf> mjg59: and i can assure you that the patches would be a selling point of ubuntu. not a detractor.
[07:18] <mjg59> Because people will write stories about how it's going to be in the release
[07:18] <towolf> i see.
[07:19] <mjg59> Whereas if we get it working at the start of a cycle, there's a much lower probability of us having to remove it
[07:20] <mjg59> Is restarting NetworkManager on upgrade really necessary?
=== giskard [n=giskard@62-101-126-218.ip.fastwebnet.it]  has joined #ubuntu-devel
=== XSource [n=XSource@41.201.247.99]  has joined #ubuntu-devel
[07:26] <Ng> mjg59: ooi, is your gnome DPI set to your real DPI? If I set mine to roughly what the real DPI of the screen is, the colour hints on vertical parts of glyphs are much harder to see (which I kinda get the feeling should be obvious, and that anything sub-pixel should depend on really knowing where the pixels are)
[07:27] <mjg59> Ng: No, for an LCD running at native resolution the software knows where the pixels are regardless of what the DPI is
[07:27] <mjg59> Altering the DPI is effectively just altering the physical size of your screen while keeping the resolution the same
[07:27] <Ng> mjg59: but the gnome dpi setting demonstrably changes how freetype is rendering the fonts
[07:28] <mjg59> Ng: Because it tries to keep the fonts the same physical size, regardless of the size of the screen
[07:28] <towolf> Ng: could you demonstate that?
[07:28] <mjg59> Which will alter the width of the strokes, and hence also the way the font is rendered
[07:28] <mjg59> It's equivalent to just changing all your font sizes
[07:29] <cromo> alex-weej: ok, it was the radeon driver it seems. vesa works fine.
[07:30] <Ng> towolf: I'll see what I can knock up when I get home :)
[07:30] <cjwatson> mjg59: how about coupling it with an announcement to u-d-a that this is an experimental change, we are soliciting feedback, and may well revert it before release?
[07:30] <mjg59> cjwatson: I don't think that would help. People will review the beta without reading uda.
[07:30] <cjwatson> or even a note in the fonts dialog
[07:31] <Ng> either way my musings about DPI are irrelevant if we're going to hardcode everything to 96dpi :)
[07:31] <cjwatson> though I have to say I'm not sure I care about reviews of beta which assume it's final
[07:31] <mjg59> cjwatson: I don't think we should be putting anything in the beta unless we have no reason to think anything bad is going to happen
[07:32] <towolf> Ng: i don't think freetype cares about anything but target size. this dpi has to be this and that is a myth. unless proven.
[07:32] <mjg59> In this case, I think we have reason to feel that some users will be very unhappy with the change (and some users very happy)
[07:33] <mjg59> Given that we know what the concerns are already, we should introduce the change at a point when we have time to address those concerns - rather than either dismissing them or removing the feature
[07:33] <cjwatson> while I can see your point, I'm worried that it's the-perfect-is-the-enemy-of-the-good
[07:33] <cjwatson> i.e. we never introduce any change until it's perfect
[07:34] <mjg59> I'm happy introducing changes without them being perfect, as long as we think that they'll either be perfect or a decent approximation of it by the time we release the final product
[07:34] <cjwatson> the thing that seems unclear here is whether this change is "the good"
[07:34] <mjg59> We know that this change can't be perfect by release time
[07:34] <cjwatson> we do? I didn't think we had enough information
[07:34] <mjg59> There's nothing we can do to help the people it makes unhappy
[07:35] <cjwatson> somebody suggested an extra fonts-dialog option
[07:35] <cjwatson> modulo naming, would that work?
[07:35] <mjg59> cjwatson: No, not really
[07:35] <cjwatson> why not?
[07:35] <mjg59> That would just give the choice of enabling it or disabling it at a system-wide level
[07:35] <cjwatson> I think that's good enough
[07:35] <mjg59> And would require code changes to freetype, cairo and xft
[07:36] <Mithrandir> I think we are too trigger-happy about adding preferences at the moment, though that's slightly tangential.
[07:36] <mjg59> Which haven't been written yet
[07:36] <cjwatson> so does introducing or reverting the change
[07:36] <cjwatson> (require code changes, albeit written)
[07:36] <cjwatson> I would like to know how complicated those changes would be
[07:37] <mjg59> The UI would be fairly easy, though working out a way of making it make sense to users would be much harder
[07:37] <Keybuk> cjwatson: code easy, UI harder but possible
[07:37] <mjg59> Our existing font configuration is over-complicated already
[07:37] <Keybuk> though since this would appear under Advanced, that's less of an issue
[07:38] <cjwatson> AIUI this change only negatively affects users who have already gone into that dialog
[07:38] <cjwatson> is that true?
[07:38] <mjg59> cjwatson: No
[07:38] <cjwatson> doesn't it chiefly affect a mode which is not switched on by default?
[07:38] <Keybuk> s/chiefly/only/
[07:38] <mjg59> cjwatson: It affects anyone who's enabled sub-pixel anti-aliasing, which is not in the advanced dialog
[07:39] <mjg59> And the fact that we're not enabling sub-pixel anti-aliasing by default on TFTs is a bug anyway, but still
[07:40] <cjwatson> so why would this have to appear in Advanced?
[07:40] <towolf> my experience is, touch anything font-related /anytime/, and a very vocal group will stand up and protest. loudly. this is not contingent on the time of release.
[07:40] <cjwatson> there are already four options there
[07:40] <cjwatson> five doesn't seem a big deal
[07:40] <towolf> only options will appease linux font zelots.
=== unggnu [n=unggnu@unaffiliated/unggnu]  has left #ubuntu-devel ["Ex-Chat"] 
[07:41] <mjg59> cjwatson: Philosophically, because it's an option that shouldn't exist
[07:41] <Mithrandir> if so, we should replace the monochrome one, I'd say.  *hides*
[07:41] <mjg59> Realistically, because it's an option that nobody would understand
=== rulus_ [n=rulus_|@82.134-244-81.adsl-dyn.isp.belgacom.be]  has joined #ubuntu-devel
[07:41] <cjwatson> huh? I don't understand the four different options there right now
[07:41] <cjwatson> because I am not a font expert
[07:41] <cjwatson> I can see that they look different
[07:41] <cjwatson> and your precise concern is that they look different
[07:41] <mjg59> Oh, right
[07:42] <cjwatson> so I do not believe that that is a problem
[07:42] <towolf> cjwatson: because it doens't make sense, nor reflect reality namingwise.
[07:42] <mjg59> This option would be orthogonal to those four
[07:42] <Mithrandir> cjwatson: but they don't look different at that font size anyway?  Or not very much so, at least?
[07:42] <cjwatson> Mithrandir: different enough to see
[07:42] <iwj> pitti: New dpkg and libc for your delectation, delight and disaster.
[07:42] <towolf> mjg59: not orthogonal at all
[07:42] <cjwatson> and also it's instant-applyu
[07:42] <cjwatson> so you can simply see the effect on your desktop
[07:43] <mjg59> towolf: Subpixel positioning is orthogonal to the anti-aliasing method
[07:43] <cjwatson> so I entirely disagree that this would be incomprehensible
[07:43] <Mithrandir> cjwatson: can you see the difference between "best contrast", "best shapes" and subpixel?
[07:43] <towolf> mjg59: that sentence doesnt make sense to me.
[07:43] <iwj> elmo: that rfc3484 rule 9 disablement ought to be in the beta at this rate; my libc built and tested fine and it's currently awaiting archive admin approval.
[07:43] <cjwatson> Mithrandir: when it instant-applies to my desktop, yes
[07:43] <towolf> mjg59: we do not have subpixel positioning at all, yet
[07:44] <elmo> iwj: super, thanks
[07:44] <slangasek> iwj: default gai.conf that disables it, or patched the code?
[07:44] <iwj> slangasek: (b)
[07:44] <slangasek> spiff
[07:44] <iwj> slangasek: It's trivial; you just changed `no' to `yes' (or v.v) in the default config, and 0 to 1 (or was it v.v) in the code.
=== AlinuxOS [n=vsichi@host72-133-dynamic.16-87-r.retail.telecomitalia.it]  has joined #ubuntu-devel
[07:44] <mjg59> towolf: I thought the entire point of this code was that it altered the smoothing code to be more willing to align things to subpixel boundaries?
[07:44] <iwj> s/changed/change/
[07:44] <towolf> mjg59: no, yft and cairo don't allow that.
[07:45] <towolf> that's futuristic stuff.
[07:45] <towolf> *xft
[07:45] <mjg59> Ok, so I've misunderstood what changes it actually makes. In that case, why does it reduce the level of pixel alignment?
[07:45] <towolf> they just puzzle rectangles together
=== j_ack [n=j_ack@p508D808A.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[07:45] <towolf> because the rectangles change. but at 1px distances.
[07:46] <towolf> turner has an algorithm in the pipeline that calculates better side bearings, but that's neither subpixel.
[07:46] <towolf> the whole point of the patch is to improve shape while maintaining contrast.
[07:47] <mjg59> towolf: But it improves shape without maintaining contrast
=== ryu [n=chris@unaffiliated/ryu]  has joined #ubuntu-devel
[07:47] <towolf> the fun part of lcd filtering is that it tricks your visual apparatus, into veliving that.
[07:47] <towolf> (or not, in your case)
[07:47] <mjg59> It's turning what used to be white into grey - there's no way that that can improve contrast
=== ryu [n=chris@unaffiliated/ryu]  has joined #ubuntu-devel
[07:48] <towolf> not improve, retain some/much of it.
[07:48] <mjg59> Right. But it's a tradeoff - improved shapes at the cost of contrast
[07:49] <towolf> with a good enough ratio
[07:49] <mjg59> (and increased blurriness, but I'll admit that people make the same accusation against sub-pixel AA in general, so I'm not going to argue that one)
[07:49] <mjg59> towolf: That's purely subjective
[07:49] <towolf> see with increasing font sizes, the trongly hinted way can just flip from on pixel unit to the next
[07:49] <towolf> it's so ugly.
[07:49] <towolf> and 1995
[07:49] <mjg59> With the reduced hinting example you showed, the contast is massively reduced
[07:50] <towolf> at 8pt. no fair.
[07:50] <mjg59> But we have people using 8 point fonts
=== mc44 [n=mc44@unaffiliated/mc44]  has joined #ubuntu-devel
[07:50] <towolf> let them use xterm
[07:50] <mjg59> No. That's not an option.
[07:50] <mjg59> We don't break existing configurations.
[07:50] <slangasek> the discussion seems to be backsliding, we're back to arguing the subjective merits of the options which isn't going to get us anywhere
[07:51] <towolf> multi-gnome-terminal? my lab post-doc uses that
[07:51] <mjg59> What we should be focusing on is providing a solution that works for a wider range of cases, even if it's somewhat heuristic
[07:51] <Ng> towolf: that's gnome1 though, afaik :(
[07:51] <slangasek> mjg59: but you don't think there's time to craft such a solution before release?
[07:51] <towolf> you're right, we cannot change it just like that.
[07:52] <towolf> they will come with pitchforks.
[07:52] <mjg59> I agree that the new code is almost certainly a win at larger font sizes
[07:52] <towolf> and torches.
[07:52] <mjg59> slangasek: I suspect not
[07:52] <towolf> say browsing the web. (most important task at a pc). it's ahuge improvement.
[07:52] <mjg59> slangasek: I think it'd probably end up requiring quite a lot of tuning
[07:52] <slangasek> right
[07:53] <mjg59> Naively, we could just add fontconfig support to automatically disable this at low font sizes or for monospace fonts
[07:53] <mjg59> I suspect that would deal with most of the issues, but we'd need someone to step forwards and commit to writing that code *now*
[07:53] <Trewas> towolf: there are still very many low-dpi screens (like all 19" 1280x1024 lcds) where 8 pixel fonts are fine and needed to fit enough stuff to screen
[07:54] <towolf> Trewas: it's not the issue, we have options for that case. it's jut that out of a hunch mjg59 prefers one combination that is achievable otherwise.
[07:55] <mjg59> towolf: At the moment, we don't have options for that case
[07:55] <towolf> in the shot you posted, in my eyes the left option was largely compatible with the right side.
[07:55] <Trewas> towolf: anyway, shouldn't the new filtering method still retain sharpness (i.e. not be blurry) in fully hinted case?
[07:55] <pkern> vorlon is called differently here... that feels strange. :)
[07:56] <towolf> Trewas: yes, but there are some interactions that turn out not so great in the end.
[07:56] <towolf> Trewas: it just works best with the autohinter.
=== Skiessi [n=qwe@dsl-roibrasgw1-fe88fb00-133.dhcp.inet.fi]  has joined #ubuntu-devel
[07:57] <towolf> Trewas: the perception is the autohinter is inferior. that's not true.
[07:57] <towolf> Trewas: apple is the holder of the truetype hinting patent. guess what, they abandoned the technology completely.
[07:58] <towolf> there was a blog post by some luminary about safari on windows recently.
=== zenrox [n=zenrox@pool-71-115-208-222.spknwa.dsl-w.verizon.net]  has joined #ubuntu-devel
[07:58] <towolf> it spawned a sizeable flame-war.
[07:58] <towolf> this will happen with us, too.
[07:59] <mjg59> towolf: The issue is that we're trying to apply a "one size fits all" mentality to this. This isn't going to work.
[08:00] <Trewas> towolf: I read http://antigrain.com/research/font_rasterization/index.html and it seems that hinting is still a benefit with low-dpi screens, even if it is fine for high-dpi screens and scaling is easier
[08:00] <towolf> mjg59: i agree ;-)
[08:00] <mjg59> The requirements of a terminal application are very different to the requirements of a web browser. In one, precise definition of characters is more important than accurately depicting the character shapes. In the other, that's less true/
[08:00] <towolf> Trewas: i agree.
[08:01] <mjg59> My objection at the moment is that the change increases the aesthetics of the common case, but reduces the functionality of the corner case. I'm happy with one, but not the other
[08:01] <towolf> Trewas: i propose some amount of hinting too.
=== phanatic [n=phanatic@dsl5402820D.pool.t-online.hu]  has joined #ubuntu-devel
[08:02] <towolf> mjg59: i've been happily using the patch in my terminal usage since 2006. But my res is 129 dpi. and i use at least 12pt.
[08:02] <towolf> mjg59: what you call aesthetics is readability for me.
=== slomo [n=slomo@ubuntu/member/slomo]  has joined #ubuntu-devel
[08:03] <towolf> mjg59: for me it is significantly improved.
[08:03] <seb128> siretart: the sync tool is confused because the orig already exists in your ppa archive, could you do a fake sync using http://people.ubuntu.com/~pitti/scripts/syncpackage?
[08:03] <towolf> mjg59: if it weren't taseless i would cite a published study proving that (SR vs. monochrome)
[08:04] <towolf> (hint: it's a microsoft typography study)
[08:05] <slangasek> towolf: you don't appear to be arguing anything new or disputed though, you admit that you're using fonts >= 12pt which isn't the problem case?
[08:05] <mjg59> towolf: I'm not using monochrome, and nor have I argued that doing so improves readability
[08:05] <jwendell> seb128, a doubt: was the sound when we log in dropped along with splash screen too?
[08:06] <towolf> strong hinting ~ monochrome (for sufficiently fuzzy values of ~)
[08:06] <seb128> jwendell: no, splash screen is a gconf key change, the sound is due to upstream code changes
[08:06] <jwendell> seb128, ok, i just wanted to know if this is a new 'feature' for gutsy or a bug :)
[08:07] <towolf> slangasek: you can achieve readable fonts at 6pt with the new method. a size where all other methods are not readable at all)
[08:07] <seb128> jwendell: a bug and upstream is on it I think
[08:07] <towolf> slangasek: the issue is habituation.
[08:07] <jwendell> seb128, btw did you understand that question about vino-session?
[08:07] <seb128> jwendell: I don't really understand the vino session thing, why doesn't it register to the session the "normal" way?
[08:07] <towolf> slangasek: and the dishabituation will take some time.
[08:07] <seb128> jwendell: no
[08:07] <slangasek> "doctor, I'm getting a headache from my computer screen" "must be your habituation" :)
[08:08] <jwendell> seb128, indeed, there should be some way to run a executable by watching a gconf key
[08:08] <towolf> slangasek: doctor: here have a transferral receipt to the therapeut, ...
[08:09] <jwendell> seb128, d-bus is the right thing for 2.22
[08:09] <towolf> slangasek: for your phantom pain.
[08:09] <Trewas> towolf: in feisty full hinting with subpixel rendering seems very sharp (more so than non-antialiased case because curves are not blocky), with the new stuff in gutsy the same is quite blurry
[08:09] <slangasek> towolf: um, except it's not phantom pain
[08:09] <slangasek> actually, it's totally valid that one's expectations regarding the text appearance could contribute to greater eye strain
[08:10] <ogra1> a bit gto visible for being a phantom :)
[08:10] <ogra1> s/gto/to/
[08:10] <towolf> Trewas: a result of Vera family with suboptimal settings. it's not enough to just patch the libs.
=== DktrKranz [n=Luca@ubuntu/member/dktrkranz]  has joined #ubuntu-devel
=== towolf digs for the paper
[08:10] <Trewas> towolf: I am using verdana/tahoma (never liked how vera fonts look)
[08:10] <elmo> hey, all this talk about fonts is giving me a headache, who do I see about that?
[08:10] <elmo> \o/
[08:11] <ogra1> lol
[08:11] <Nafallo> :-)
[08:12] <towolf> the glyphologist
[08:12] <slangasek> towolf: anyway, I don't see that much weight should be given to a claim that "this is the only option that makes 6pt fonts readable" from someone who isn't /using/ 6pt fonts
[08:12] <towolf> slangasek: err, i tested this
[08:12] <slangasek> towolf: but you're not /using/ them
[08:12] <slangasek> which implies you don't actually find them desirable
[08:13] <ogra1> or are forced to use them
[08:13] <seb128> jwendell: well, there is this autostart spec, you just have to add a .desktop
[08:13] <slangasek> so if it makes 6pt fonts legible, but at the same time makes it so no one /wants/ to use anything smaller than 10pt...
[08:14] <seb128> jwendell: and you could make the vino server exit if the key is set
[08:14] <Keybuk> slangasek: it doesn't just make 6pt fonts legible, it changes the appearance of fonts at all sizes
[08:14] <Keybuk> (as is obvious from the fact people noticed the change <g>)
[08:14] <jwendell> seb128, sure, but i mean, some executable must be running in order to watch that key
[08:14] <jwendell> seb128, and who will run vino-server again?
[08:15] <slangasek> Keybuk: yes, I'm aware.  But towolf is trying to assert that the new behavior is better even for smaller fonts -- fonts smaller than anything he actually uses
[08:15] <Keybuk> the discussion should really just be about whether Beta is an appropriate time to test this on our users, or not
[08:15] <towolf> slangasek: screenshots coming up.
[08:16] <slangasek> towolf: then you're missing my point
[08:16] <Keybuk> since we'll just descend into an argument of biblical proportions otherwise :p
[08:17] <ogra1> towolf: screenshots totally dont matter, its a 100% subjective view if you lkike the change or not and if it bothers your eyes or not ... no paper or screenshots will change personal impression here
[08:17] <towolf> slangasek: i don't use small fonts because i like to sit at my computer with a relaxed posture, and not squit.
[08:17] <Keybuk> ogra1: it's also worth noting that people's views appear to change after a night's sleep
[08:18] <Keybuk> (mine certainly did)
[08:18] <cromo> alex-weej: disabling dri makes the ati driver work fine, too.
[08:18] <ogra1> Keybuk: yes, mine didnt yet but i noticed the comments
[08:18] <alex-weej> cromo: i'm sorry i didn't see what (if anything) you wrote before
[08:18] <alex-weej> cromo: ah, vesa works
[08:18] <alex-weej> cromo: ok, so have you filed a report on this?
[08:19] <alex-weej> and are you using Compiz?
[08:19] <seb128> jwendell: again? you have a .desktop it's run at every login
[08:19] <towolf> ogra1: wasn't the point that the new way doesn't work with small type, and i wanted to disprove that FUD?
[08:19] <seb128> jwendell: and you make vino-server exit on startup if the key is set
[08:20] <seb128> jwendell: that's not starting vino-server, looking the key value and returning that will load your box
[08:20] <mjg59> towolf: It depends what you mean by "work". It reduces contrast and definition, but improves the shaping.
[08:20] <seb128> jwendell: I'm away for dinner, be back later
[08:21] <ogra1> towolf: my personal as that my eyes start to tear after a while with these fonts ... no matter how big they are on my 1024x768 screen
[08:21] <ogra1> s/personas as/personal concern was/
[08:22] <Trewas> towolf: I think the new way makes smaller-than-usable fonts look legible (say 6 pixels) but actually hurts for small-but-still-usable case (say 8 pixels)
[08:22] <towolf> ogra1: but you are seasoned unix users, you have been using those fonts since decades. a change will unequivocally be wrong to you.
[08:23] <mjg59> towolf: No, that doesn't fit with me preferring the new code for the desktop applications
[08:23] <ogra1> towolf: i even used fonts when there wqas no antialiasing ... that doesnt make them appear less blurry to me though
[08:23] <towolf> ogra1: thanks for proving the point.
[08:24] <towolf> anyhow, after two nautilus crashes: ftp://ftp.tuebingen.mpg.de/kyb/towolf/screenshot4.png
=== mako_ [n=mako@bork.hampshire.edu]  has joined #ubuntu-devel
[08:24] <towolf> ftp://ftp.tuebingen.mpg.de/kyb/towolf/screenshot5.png
[08:24] <mjg59> towolf: None of those are readable at my screen resolution
[08:24] <towolf> for sufficiently small values of readable.
[08:24] <mjg59> Expanding them, the middle one is more legible
[08:24] <towolf> decipherable.
[08:25] <mjg59> But that's not the setting we were proposing to ship
[08:25] <slangasek> towolf: no, the point is that you, as someone who isn't using 8pt fonts, should not have more weight given to your opinion than the folks who are actually using fonts of that size, no matter how you try to bolster your opinion with screenshots or studies
[08:27] <towolf> slangasek: but that's why Keybuk proposed to throw the stuff into the wild, to have /all/ ubuntu users have a go at it, right?
[08:27] <slangasek> yes
[08:27] <slangasek> but that's not the discussion you're continuing to have here :)
[08:27] <towolf> slangasek: all includes my mom and dad, and of course ubuntu devs running terminals at 8pt.
[08:28] <mjg59> Anyway. I suspect strongly that it would be helpful for someone to work on an implementation for ensuring that the choice of method can be chosen at runtime, and then adding fontconfig support for changing it based on font families or size
[08:28] <mjg59> Is anyone going to volunteer to do that?
[08:28] <towolf> slangasek: no, you guys dragged me into the "it doesn't work at 8pt" discussion
[08:28] <ogra1> towolf: you shouldnt let your mom and dad run gutsy ;)
=== alex-weej [n=alex@cpc2-darl3-0-0-cust237.midd.cable.ntl.com]  has joined #ubuntu-devel
[08:28] <alex-weej> cromo: did you answer my q? sorry, i crashed
[08:29] <Keybuk> mjg59: if the guidelines of what people want are clear, I have no problem doing that
[08:29] <towolf> mjg59: let's hope someone with a good sense of HIG and humanity.
[08:29] <alex-weej> crashed loading towolf's links
[08:29] <Keybuk> having reviewed the code quite heavily already, I know where the bits need to go
[08:29] <mjg59> towolf: I suspect that it can be done without appearing in the user interface at all
[08:29] <towolf> mjg59: whoa, be careful with one-size fits all.
[08:30] <towolf> mjg59: the proposal by david turner on the cairo list i cited earlier seemed very reasonable.
[08:30] <mjg59> towolf: I agree that it's impossible to make everyone happy. The aim is to make enough people happy that a sufficiently small number of people want to change the option that there's no need to put it in the UI
=== boggle [n=spindler@modemcable178.77-70-69.static.videotron.ca]  has joined #ubuntu-devel
[08:30] <towolf> mjg59: it explicitely contained a truetype optimized option.
=== nnnegrooo [n=lcorrea1@200.70.97.65]  has joined #ubuntu-devel
[08:30] <towolf> mjg59: and a deactivate aa below x-pt.
=== nnnegrooo [n=lcorrea1@200.70.97.65]  has left #ubuntu-devel [] 
[08:31] <towolf> don't assume a point size to do that.
[08:31] <mjg59> Keybuk: My handwavy assertion is that, by default, we should automatically use the old method on monospace fonts below 9 points
[08:32] <mjg59> This is assuming that we stick to the current defaults, ie sub-pixel defaults to full hinting
[08:32] <Keybuk> 9pt at which dpi?  9pt at 200dpi is a somewhat larger glyph than at 96?
=== MacSlow [n=mirco@unaffiliated/macslow]  has joined #ubuntu-devel
[08:32] <mjg59> 9pt is 9pt
[08:32] <Keybuk> the existing fontconfig checks seem to be based on pixel size
[08:33] <mjg59> Ok. If it's pixel-sized, then that's easier
[08:33] <Keybuk> 9pt is 0.125" on the screen :)
[08:33] <mjg59> A quick play suggests 12 pixels would leave me happy
[08:35] <mjg59> Keybuk: Just to clarify - by "old method" I mean "the old sub-pixel colour filtering" and not "monochrome"
[08:35] <Keybuk> this would appear to mean setting the filter to "legacy" correct?
[08:36] <mjg59> Yes
[08:36] <mjg59> At least, that's my understanding
[08:36] <towolf> mjg59: we should not stick to full hinting. (saying this seems futile)
[08:36] <towolf> Keybuk: correct
[08:36] <mjg59> towolf: There's a sufficient decrease in contrast that reducing hinting for terminals is not a good idea
[08:37] <Keybuk> mjg59: depending on terminal colour?
[08:37] <mjg59> Keybuk: My /impression/ is that the new filter is perfectly reasonable at 10 pixels on non-monospace
[08:38] <towolf> i realized that you never posted a screenshot of your terminal, without magnification.
[08:38] <mjg59> towolf: It looked pretty much identical to the one you posted
[08:38] <towolf> okay
[08:38] <mjg59> towolf: Am I right in thinking that that used full hinting?
[08:38] <towolf> the one in your email?
[08:38] <mjg59> No
[08:39] <towolf> the white-on-black one?
[08:39] <mjg59> screenshot3
[08:39] <mjg59> Yes
[08:39] <towolf> no, didn't use full hinting.
[08:40] <towolf> would have entailed killing my x
[08:40] <mjg59> Ok, interesting. My fully hinted one looked almsot identical.
=== towolf thinks compiz is cool because the zoom is instant
[08:40] <towolf> mjg59: see? you're getting there. ..
[08:41] <mjg59> towolf: ftp://ftp.tuebingen.mpg.de/kyb/towolf/screenshot1.png clearly has reduced contrast on the unhinted version
[08:41] <towolf> smaller font.
[08:42] <towolf> smaller to a degree where the stems used a thickness of < 1px. below that the becvome gray.
[08:42] <towolf> because there's no hinting involved to flip them back to 1px.
[08:42] <mjg59> towolf: Right, exactly
[08:42] <mjg59> For small fonts we probably want hinting in order to keep the contrast high
[08:43] <mjg59> For larger fonts, the contrast will be good enough anyway and we can concentrate on shapes
[08:43] <towolf> mjg59: 1. yes, that should be possible, 2. we is not defined here
[08:43] <towolf> we as in "we"
[08:44] <mjg59> For certain applications, contrast is more important than shaping
[08:44] <towolf> because i am a lot more comfortable with reading the center in screenshot1.png
[08:45] <Keybuk> mjg59: ok, that patch seems possible
[08:45] <mjg59> Keybuk: Ok, I think that makes me massively happier
[08:45] <Keybuk> it would be in the form of a fontconfig option to set the lcd filter
[08:45] <mjg59> Yeah
[08:45] <Keybuk> you'd drop something in conf.d to set hinting=legacy when pixelsize <= 8
[08:45] <Keybuk> for example
[08:45] <mjg59> Right
[08:45] <Keybuk> (or 12 or whatever you like)
=== PriceChild [n=pricechi@ubuntu/member/pdpc.supporter.student.PriceChild]  has joined #ubuntu-devel
[08:45] <mjg59> I think we want to ship one of those by default
[08:46] <Keybuk> then cairo, xft, etc. would call FT_Library_SetLcdFilter with what fontconfig says, not FT_LCD_FILTER_DEFAULT
[08:46] <mjg59> Yes, that sounds appropriate
[08:46] <Keybuk> as you say, we can ship that by default maybe with a debconf option or something
[08:47] <mjg59> As I said, I /think/ it's primarily an issue with monospace
[08:47] <mjg59> So we could just default it there and leave the others
[08:47] <mjg59> I suspect that will avoid upsetting console-oriented people, and make desktop-oriented people happy at the same time
[08:47] <mjg59> Anyway -> shops
[08:47] <mjg59> Back in 10
[08:47] <Keybuk> mjg59: with that patch, you'd remove your objection to it being in beta?
[08:48] <Keybuk> slangasek: would release team be happy with the patches going in for beta (including the patch proposed by mjg59?)
[08:48] <towolf> mjg59: it's a problem with web browsers and all other apps too, actually.
[08:48] <lamont> slangasek: expect_5.43.0-13.1 uploaded to debian, you want the sync request now, or once it is in the archive?
[08:48] <towolf> mjg59: you're just more used to the terminal.
[08:48] <lamont> and I missed today's dinstall run
[08:49] <slangasek> Keybuk: as this resolves the main objection where we know ahead of time that some people are unhappy with the behavior change, yes
[08:51] <slangasek> lamont: no preference
[08:53] <Mithrandir> lamont: it won't be acted on until it's in the archive anyway. :-P
=== Spads [n=spacehob@unaffiliated/spads]  has joined #ubuntu-devel
=== BenC_ [n=bcollins@collinsap1.phunnypharm.org]  has joined #ubuntu-devel
=== mdz [n=mdz@c-71-198-147-65.hsd1.ca.comcast.net]  has joined #ubuntu-devel
=== josephpiche [n=josephpi@65-23-165-162-host.drtel.net]  has joined #ubuntu-devel
[08:57] <mjg59> Keybuk: I think so, yes
[09:00] <jamiemcc> seb128: any chance o3read could be promoted to main as its small and is needed by tracker to index openoffice files?
[09:02] <Mithrandir> jamiemcc: it needs a main inclusion report.
[09:02] <Mithrandir> https://wiki.ubuntu.com/MainInclusionProcess
[09:03] <pkern> slangasek: So you joined Canonical very recently?
[09:03] <jamiemcc> mithrandir: I know - but such decisions are discussed here?
[09:04] <towolf> i was able to get through the pay wall to get the readability paper. it looks not really exciting apart from the difference when italics are used.
[09:04] <towolf> did anyone mention that italics are a *lot* better with the new method?
[09:04] <Mithrandir> jamiemcc: they're quite often not really discussed, just carried out
[09:05] <jamiemcc> mithrandir: who does the inclusion reports?
[09:05] <seb128> jamiemcc: pitti usually
[09:05] <Mithrandir> whoever has an interest in getting the package into main writes it
[09:05] <seb128> jamiemcc: the easier is to file the wiki page
[09:05] <Mithrandir> it's reviewed by pitti and iwj
[09:05] <seb128> jamiemcc: the wiki page has the informations required to make a decision
[09:05] <evand> yay, the new nvidia driver potentially fixes the compiz black windows bug, finally.
[09:06] <pochu> jamiemcc: I could help a bit with the report
[09:06] <jamiemcc> seb128: ok should I write the report then?
[09:06] <seb128> jamiemcc: either do it or convince somebody to do it for you ;)
[09:06] <jamiemcc> thx - pochu are you familiar with the process?
[09:06] <pochu> jamiemcc: tracker's report looks good to take as an example: https://wiki.ubuntu.com/MainInclusionReportTracker :)
[09:07] <pochu> jamiemcc: I know how to do it, although I have never done it
[09:07] <pochu> jamiemcc: but there's always a first time, isn't there? ;)
[09:07] <jamiemcc> pochu: yeah - can you make a start on it? (im still fixing tracker bugs atm(
[09:08] <pochu> jamiemcc: sure thing!
[09:08] <jamiemcc> pochu: thx very much
[09:08] <pochu> np
=== agoliveira is now known as agoliveira_brb
=== andrunko [n=andrunko@200.184.118.132]  has joined #ubuntu-devel
[09:17] <slangasek> pkern: this week, yes
[09:18] <pkern> slangasek: As Ubuntu RM?
=== agoliveira_brb is now known as agoliveira
[09:21] <Keybuk> GTK+ font rendering is done through Cairo now, right?
=== DShepherd [n=dwight@port0002-abm-static-adsl.cwjamaica.com]  has joined #ubuntu-devel
=== dwatson [n=david@planetwatson.plus.com]  has joined #ubuntu-devel
=== _MMA1 [n=_MMA_@cpe-071-070-203-016.nc.res.rr.com]  has joined #ubuntu-devel
[09:32] <seb128> mjg59: could you look at bug #140485 some people still have gnome-settings-daemon crashing, might be due to the synaptic changes
[09:32] <ubotu> Launchpad bug 140485 in xserver-xorg-input-synaptics "gnome-settings-daemon not starting with 1:2.19.92-0ubuntu3" [Medium,In progress]  https://launchpad.net/bugs/140485
=== _MMA1 is now known as _MMA_
[09:33] <mjg59> seb128: Checking
[09:33] <seb128> mjg59: I think there is not enough information to have a good idea of the issue but maybe you know what to ask
[09:35] <mjg59> seb128: Hm, interesting. I have a suspicion.
[09:35] <alex-weej> pitti: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/120957/
[09:35] <ubotu> Launchpad bug 120957 in update-manager "UpdateManager fails to fetch dist-upgrade tarball" [High,Confirmed] 
[09:36] <mjg59> seb128: It's possible that they're machines with a synaptics driver entry but no synaptics pad
[09:36] <seb128> ok, if you could deal with it that would be nice ;)
[09:36] <mjg59> I'll see if I can reproduce
[09:37] <pochu> jamiemcc: could you check, specially point 5? I haven't touched that point (copy&paste from tracker report for it hehe) https://wiki.ubuntu.com/MainInclusionReportO3Read
[09:39] <jamiemcc> pochu: I think the deb for o3read compies with debian policy (the rest looks irrelevant)
[09:39] <bryce> where are the release notes for gutsy beta being compiled?  I've got an entry or two to add.
[09:39] <alex-weej> pitti: oops sorry on the phone and that was a bit rude
[09:39] <alex-weej> pitti: any ideas what's happening with that bug?
[09:39] <pochu> jamiemcc: ok, editing
=== Gman [i=gman@nat/sun/x-4193793578d07ecd]  has joined #ubuntu-devel
[09:41] <MacSlow> hi Gman, bryce
[09:41] <bryce> hi MacSlow
[09:41] <Gman> hey MacSlow
[09:42] <pochu> jamiemcc: the binary is lintian-clean, and the source has just a couple minor warnings, so I'd say it is
[09:42] <pochu> jamiemcc: updated, what do you think?
=== asac_ [n=asac@debian/developer/asac]  has joined #ubuntu-devel
[09:42] <jamiemcc> pochu: looks good - thanks
[09:42] <slangasek> pkern: yep
[09:44] <pochu> jamiemcc: cool, adding to the queue now
[09:44] <jamiemcc> pochu: thx
[09:44] <pitti> iwj: dpkg> thanks, I'll have a look; how bad was the libc patch in the end?
[09:44] <tepsipakki> Keybuk: I thought that cleartype is not used because of the MS patent?
[09:44] <pitti> alex-weej: no problem, looking
[09:45] <pitti> alex-weej: well, it says so in the bug, there are more imports needed
[09:45] <mjg59> Hrm. Ok, doesn't /seem/ to be that
[09:46] <Keybuk> tepsipakki: it wasn't used because we didn't know about it :)
[09:46] <pitti> jamiemcc: MIR> I'll have a look if it is urgent/important, but I prefer to not have too many changes any more
[09:46] <tepsipakki> Keybuk: right, ok :) I'm looking forward to that
[09:47] <mjg59> Is there anyone here who's suffering from #140485 ?
[09:47] <pochu> pitti: well, if it's ok to promote it, it isn't such a big change... :)
=== mbiebl [n=michael@e180071149.adsl.alicedsl.de]  has joined #ubuntu-devel
[09:47] <jamiemcc> pitti: yeah although some people are compalining tracker does not index Openoffice files - I guess it improves the user experience and o3read is tiny
[09:47] <pitti> jamiemcc: right
[09:48] <pochu> pitti: see bug 117307
[09:48] <ubotu> Launchpad bug 117307 in tracker "Tracker doesn't index openoffice.org files" [Undecided,Invalid]  https://launchpad.net/bugs/117307
[09:48] <pitti> jamiemcc: well, just assume it would crash for some reason, then we would have this crash installed for every tester of beta, and so on
[09:48] <pitti> pochu: that doesn't sound like 'invalid'
=== dpm [n=dpm@p54A13930.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[09:49] <jamiemcc> pitti: if it crashed it would be out of process so would not harm trackerd
[09:49] <pochu> pitti: well, it's a recommends, and we install recommends by default... that's why I closed it
[09:49] <pochu> pitti: when tracker wasn't in main yet
[09:50] <pitti> pochu: ah, I see; but we don't install it as part of -desktop
=== mjg59 fails to reproduce
[09:50] <pochu> pitti: o3read? right, I guess the bug is valid now...
=== pochu reopens it
[09:52] <stgraber> iwj: You may have received two e-mails from the Ubuntu QA Tracker, you can ignore them. That was just test e-mails that shouldn't have left my server :)
=== towolf [n=towolf@f048011019.adsl.alicedsl.de]  has joined #ubuntu-devel
[09:53] <towolf> mjg59: i have the persistent gsd crasher with synaptics here.
[09:54] <towolf> mjg59: i could test something
[09:54] <mjg59> towolf: Could you do gdb /usr/bin/gnome-settings-daemon
[09:54] <mjg59> break gdk_x_error
[09:54] <mjg59> run --sync
[09:55] <mjg59> and then, when it stops, do bt and give me the backtrace?
=== lbm [n=lbm@0x555373ab.adsl.cybercity.dk]  has joined #ubuntu-devel
[09:55] <towolf> mjg59: do i need something like -dbg?
=== manchicken [n=manckn@12-226-72-69.client.mchsi.com]  has joined #ubuntu-devel
[09:56] <mjg59> towolf: We don't build a debug package for it sadly, so no
[09:56] <mjg59> With luck there'll be enough information for me to get an idea about what's going on
[09:56] <towolf> mjg59: at the start it spews: Function "gdk_x_error" not defined.
[09:57] <mjg59> Yeah, that's fine
[09:57] <towolf> mjg59: then: (no debugging symbols found)
[09:57] <towolf> mjg59: (gdb) bt
[09:57] <towolf> No stack.
[09:57] <mjg59> Did it spit out the error?
[09:57] <towolf> mjg59: the stderr is not interesting, is it?
[09:57] <towolf> mjg59: no?
[09:58] <towolf> mjg59: yes, the output of the program, yes.
[09:58] <mjg59> towolf: You told it to make the breakpoint pending on future shared library load?
[09:58] <towolf> mjg59: hold on
[09:59] <towolf> mjg59: no stack, with y earlier.
[09:59] <mjg59> What caused it to break?
[10:00] <towolf> mjg59: and a couple times, "hit return to"
[10:00] <mjg59> Hit return to what?
[10:00] <towolf> mjg59: This?: Program exited with code 01.
[10:00] <towolf> (no debugging symbols found)
[10:00] <towolf> ---Type <return> to continue, or q <return> to quit---
[10:00] <mjg59> Ok. In that case the breakpoint didn't work
[10:01] <towolf> let's paste the entire thing somewhere
[10:02] <seb128> mjg59: we do build dbgsym for everything no?
[10:03] <mjg59> seb128: There doesn't seem to be a -dbg package for control-center
[10:03] <seb128> mjg59: you don't know about https://wiki.ubuntu.com/DebuggingProgramCrash ?
=== hunger [n=tobias@p54A71EE4.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[10:03] <seb128> mjg59: deb http://people.ubuntu.com/~ubuntu-archive/ddebs gutsy main universe
[10:04] <mjg59> Oh, yes.
[10:04] <seb128> mjg59: that source should have -dbgsym for every binary built
[10:04] <mjg59> Well, let's see if we can actually get a breakpoint first :)
[10:04] <Keybuk> http://people.ubuntu.com/~scott/fontconfig.patch
[10:04] <Keybuk>   (and libcairo.patch and xft.patch alongside)
[10:05] <towolf> mjg59: http://en.pastebin.ca/705069
[10:05] <towolf> mjg59: the Warnings are because i used to use evdev for my keyboard, but disabled it, just in case.
[10:06] <mjg59> towolf: Hrm.
[10:06] <mjg59> Try break gdk_x_error() ?
[10:06] <mjg59> Though I don't /think/ that makes any difference
[10:07] <pitti> iwj: your glibc upload doesn't mention the bug# in the changelog; you'll close it manually, I take it?
[10:08] <towolf> nope
[10:08] <mjg59> Sigh.
[10:09] <towolf> reminds me of the old evdev mouse driver gsd crash.
[10:09] <towolf> that was a pain to debug too
[10:09] <Keybuk> mjg59: is that the kind of patch you were after?
[10:09] <ScottK> pitti: I have a question about fixing the current FTBFS in sdl-mixer1.2.  There's a new Debian revision that solves the FTBFS plus other stuff.  At this point assuming both build (we're still testing), would you rather a sync or just the one patch: http://packages.debian.org/changelogs/pool/main/s/sdl-mixer1.2/sdl-mixer1.2_1.2.6-3/changelog
[10:11] <mjg59> Keybuk: Looks promising, yup
[10:11] <pitti> ScottK: judging by that changelog, I'd rather sync
[10:11] <Keybuk> mjg59: my only concern is that this adds a fair amount of new API to several libraries
[10:11] <ScottK> pitti: Thanks.  Assuming it tests out OK, we'll ask for a sync.
[10:12] <mjg59> Keybuk: Several? Surely it's one API addition to Fontconfig?
[10:12] <Keybuk> fontconfig gains the new lcdfilter option, yes
[10:12] <Keybuk> xft just needs to use that, so no biggy
[10:12] <Keybuk> though it does add an entry to an internal struct
[10:12] <seb128> mjg59: you might need the dbgsym to break on a symbol, not sure if it can resolve with a stripped version
[10:12] <Keybuk> cairo is the annoying one, since it has to grow cairo_lcd_filter_*
[10:13] <Keybuk> yay for every library wrapping the functions of the libraries they use which are functions wrapping other wrapper functions
[10:13] <towolf> seb128: installing dbgsym ...
[10:14] <mjg59> towolf: You might need the gdk ones as well, in that case
[10:14] <towolf> mjg59: package?
[10:14] <seb128> towolf: iinstall libglib2.0-0-dbgsym libgtk2.0-0-dbgsym gnome-control-center-dbgsym
[10:14] <mjg59> Keybuk: These are internal libraries?
[10:15] <towolf> ok, broke(sic?) at gdk_x_error
[10:15] <towolf> #0  gdk_x_error (display=0x808f100, error=0xbfb01608)
[10:15] <towolf>     at /build/buildd/gtk+2.0-2.12.0/gdk/x11/gdkmain-x11.c:614
[10:15] <towolf> #1  0xb714d655 in ?? () from /usr/lib/libbonoboui-2.so.0
[10:15] <towolf> #2  0x0808f100 in ?? ()
[10:15] <towolf> #3  0xbfb01608 in ?? ()
[10:15] <towolf> #4  0x00000000 in ?? ()
[10:16] <seb128> towolf: libbonoboui2-0-dbgsym
[10:17] <towolf> #0  gdk_x_error (display=0x808f100, error=0xbfe6b178)
[10:17] <towolf>     at /build/buildd/gtk+2.0-2.12.0/gdk/x11/gdkmain-x11.c:614
[10:17] <towolf> #1  0xb7156655 in bonobo_x_error_handler (display=0x808f100, error=0xbfe6b178)
[10:17] <towolf>     at bonobo-ui-main.c:58
[10:17] <towolf> #2  0xb7f47f50 in xkl_process_error () from /usr/lib/libxklavier.so.11
[10:17] <towolf> #3  0xb7837c4a in _XError () from /usr/lib/libX11.so.6
[10:17] <towolf> #4  0xb7839714 in _XReply () from /usr/lib/libX11.so.6
[10:17] <towolf> #5  0xb78f0b32 in XOpenDevice () from /usr/lib/libXi.so.6
[10:17] <towolf> #6  0x0805dcbb in ?? ()
[10:17] <towolf> #7  0x0808f100 in ?? ()
[10:17] <towolf> #8  0x00000001 in ?? ()
[10:17] <towolf> #9  0xbfe6b2c8 in ?? ()
[10:17] <towolf> #10 0xb7e2d337 in gconf_client_get_bool () from /usr/lib/libgconf-2.so.4
[10:17] <towolf> #11 0x0805ddb8 in ?? ()
[10:17] <towolf> #12 0x080a4758 in ?? ()
[10:17] <towolf> #13 0x0806ebdc in ?? ()
[10:17] <mjg59> Keybuk: Hm. I may be misunderstanding this. libcairo doesn't seem to actually use those functions you've added?
[10:17] <towolf> #14 0x00000000 in ?? ()
[10:17] <mjg59> towolf: Are you sure you have gnome-control-center-dbgsym ?
[10:18] <slangasek> Keybuk: so if it's an API addition to fontconfig, do you feel we should get buy-in from keithp before committing to that path?
[10:18] <towolf> mjg59:  *** 1:2.20.0-0ubuntu1 0 from people.ubuntu.com
[10:19] <seb128> towolf: you can use http://pastebin.ubuntu.com/ rather than the chan to copy backtraces
[10:19] <mjg59> seb128: Hm. Any idea why those symbols aren't resolving?
[10:19] <towolf> seb128: alright, what now?
[10:19] <seb128> towolf: you might want to install libxi6-dbgsym libxklavier11-dbgsym
[10:19] <towolf> seb128: on it.
[10:19] <seb128> and libx11-6-dbgsym
[10:19] <Keybuk> mjg59: it uses the set_lcd_filter one
[10:20] <mjg59> Sorry, you're right
[10:20] <seb128> mjg59: lacking dbgsym for some libraries like libx11, libxi, etc
[10:20] <mjg59> seb128: Ah, ok
[10:20] <mjg59> Keybuk: Hm. __ it?
[10:20] <Keybuk> mjg59: :)
[10:20] <slangasek> twitch
[10:20] <Keybuk> it shows up in a size change to cairo_font_options_t
[10:20] <mjg59> Oh, of course
[10:21] <Keybuk> but the contents of that struct are hidden
[10:21] <mjg59> Hmph.
[10:21] <mjg59> Yeah, less of a problem then
[10:21] <Keybuk> the headers only include a typedef for it
[10:21] <mjg59> And that's only used internally?
[10:21] <Keybuk> yeah
[10:22] <towolf> seb128: http://en.pastebin.ca/705091
[10:22] <mjg59> Still seem to be missing most of the symbols
[10:22] <slangasek> well, part of the backtrace looks wonky too
[10:23] <slangasek> #8  0x00000001 in ?? ()
=== lifeless [n=robertc@ppp245-86.static.internode.on.net]  has joined #ubuntu-devel
[10:23] <mjg59> Hm. Yeah.
[10:23] <mjg59> All the symbols that /do/ turn up are plausible
[10:23] <mjg59> I've got a pretty good idea of where it's falling over, I've just got no idea why
=== josephpiche [n=josephpi@65-23-165-162-host.drtel.net]  has joined #ubuntu-devel
[10:25] <Keybuk> mjg59: yup, works even if I make the function private
[10:25] <mjg59> Ok. I suspect we can work around this by surrounding the entire block in gdk_error_trap_push()/gdk_error_trap_pop(), but I'd prefer to know /why/ it's happening
[10:26] <josephpiche> sorry, i got disconnected. Is there a process for reviewing a spec/blueprint for decline?
[10:26] <pitti> good night everyone
[10:27] <seb128> towolf: can you "sudo apt-get install --reinstall gnome-control-center/gutsy"?
[10:27] <seb128> towolf: did you do a local build or something?
[10:27] <towolf> seb128: no
[10:28] <towolf> seb128:  do i have to quit gdb everytime?
[10:28] <seb128> yes
[10:28] <towolf> or can i just .. ok
[10:29] <seb128> "#6  0x0805dcbb in ?? ()" looks like something that should come from gnome-settings-daemon
[10:29] <towolf> seb128: ah...
[10:29] <seb128> I'm not sure why it has no debug information
[10:29] <seb128> usually that's because the package and the dbgsym don't come from the same build
[10:29] <towolf> seb128: whats this? You can only run one xsettings manager at a time; exiting
=== mdomsch [n=mdomsch@cpe-70-124-62-55.austin.res.rr.com]  has joined #ubuntu-devel
[10:30] <seb128> like a local build against a buildd one
[10:30] <towolf> seb128: shit, my bad
[10:31] <towolf> seb128: nah, same thing
[10:32] <towolf> seb128: only the numbers differ
[10:33] <seb128> towolf: if you do
[10:33] <seb128> $ gdb /usr/bin/gnome-settings-daemon
[10:33] <seb128> symbol-file /usr/lib/debug/usr/lib/gnome-control-center/gnome-settings-daemon
[10:33] <seb128> 
[10:33] <seb128> does it work?
[10:34] <towolf> seb128: oh.
[10:34] <seb128> ?
[10:35] <towolf> seb128: all this pasting takes a while. but there's more now. http://en.pastebin.ca/705105
[10:35] <seb128> mjg59: ^
[10:35] <seb128> here you go
[10:35] <seb128> ;)
[10:36] <mjg59> towolf: Can you type "up" until you're at the frame for set_tap_to_click ?
[10:37] <seb128> weird that gdb didn't get the debug symbols automatically, gnome-settings-daemon seems to have a .gnu_debuglink
[10:38] <towolf> mjg59: ang "bt"?
[10:38] <towolf> *and
[10:38] <mjg59> towolf: print devicelist[i] .name
[10:39] <towolf> mjg59: lokks like this: (gdb) print devicelist[i] .name
[10:39] <towolf> $1 = 0xb7fc8e73 "\203\024\211e\f"
[10:39] <towolf> mjg59: gibberish?
[10:39] <mjg59> Hm. That doesn't look right.
[10:40] <mjg59> How many times does the phrase "Synaptics Touchpad" appear in your /etc/X11/xorg.conf ?
[10:40] <seb128> towolf: you can try to "thread apply all bt full" to list also local variables in the backtrace
[10:40] <towolf> seb128: restart first?
[10:40] <seb128> yes
[10:40] <seb128> hum
[10:40] <seb128> no
[10:40] <seb128> no need in fact for that ;)
[10:41] <seb128> also maybe copy your xorg.conf somewhere
[10:42] <towolf> a'ight: new bt: http://en.pastebin.ca/705114
[10:43] <towolf> and xorg.conf: http://en.pastebin.ca/705115
[10:43] <ant30> Hi, I has reported a bug to update-notifier with the solution . It is for upgrade from feisty to Gutsy
[10:46] <towolf> mjg59: twice
=== lionel [n=lionel@ip-149.net-89-3-208.rev.numericable.fr]  has joined #ubuntu-devel
=== predius [n=predius@190.8.154.185]  has joined #ubuntu-devel
=== mako_ is now known as mako
=== jack_wyt [n=jack@123.115.242.154]  has joined #ubuntu-devel
[10:57] <towolf> seb128: i'll be having a visitor in 10min, anything else i can do?
[10:59] <towolf> mjg59: 
[10:59] <mjg59> towolf: Looking at it, but not having much joy so far
[11:00] <towolf> mjg59: i'm sorry for that ...
[11:00] <mjg59> No problem
[11:01] <seb128> towolf: maybe copy the backtrace and the xorg.conf on the bug
[11:01] <seb128> towolf: thanks for the work on it
[11:03] <ScottK> seb128: Do you ahve time to look at a sync that will fix a Main FTFBS?
[11:03] <seb128> ScottK: yes
[11:03] <ScottK> It's Bug #141351
[11:03] <ubotu> Launchpad bug 141351 in sdl-mixer1.2 "Please sync sdl-mixer1.2_1.2.6-3 from debian unstable main" [Medium,New]  https://launchpad.net/bugs/141351
[11:03] <ScottK> Thanks
[11:03] <seb128> you're welcome
=== YokoZar_ [n=scott@c-67-166-147-83.hsd1.ca.comcast.net]  has joined #ubuntu-devel
[11:04] <YokoZar_> Do the package.install and package.dirs files respect architecture flags?  ie, can I have usr/lib32 [amd64]  in debian/package.dirs ?
[11:04] <seb128> ScottK: I use your id for the sync, ok?
[11:05] <ScottK> seb128: If you want
[11:05] <ScottK> They guy that filed the bug did all the work.  I'm good either way.
[11:05] <seb128> ScottK: do you know him?
[11:05] <towolf> seb128:  done. signing off.
[11:05] <seb128> ScottK: I just want to get somebody responsive notified if the build fails
[11:05] <seb128> towolf: thanks
[11:05] <ScottK> I'll do for that then.
[11:06] <Keybuk> mjg59: \o/
[11:07] <mjg59> Keybuk: ?
[11:07] <seb128> ScottK: the guy is member of some teams already, I've used his account for the sync
[11:07] <ScottK> seb128: Fine by me
[11:07] <seb128> ScottK: bug closed ;)
[11:07] <ScottK> seb128: Thanks
[11:08] <YokoZar_> Do the package.install and package.dirs files respect architecture flags?  ie, can I have usr/lib32 [amd64]  in debian/package.dirs ?
[11:08] <YokoZar_> oops sorry for repost
[11:08] <ScottK> seb128: Do packages that were dep waiting on that one automatically get queued to build or do they need a manual shove?
[11:08] <seb128> ScottK: dep wait works automatically
[11:09] <ScottK> seb128: Cool.  Thanks.
[11:09] <seb128> YokoZar_: I don't think so
[11:09] <seb128> I'm not totally sure though
[11:09] <seb128> I didn't have to use that myself yet
[11:10] <Keybuk> mjg59: lcdfilter gets passed all the way from fontconfig up to gnome-terminal
[11:10] <Keybuk> now I just have to figure out how to get fontconfig to match the monospace font
[11:10] <Keybuk> for some reason, test name=family never works on monospace
[11:10] <YokoZar_> seb128: I'm just worried about my package making an empty /usr/lib32 directory on a 32 bit machine
[11:11] <seb128> YokoZar_: maybe that's the upstream makefile doing it?
[11:11] <seb128> YokoZar_: empty dirs usually don't hurt though
[11:11] <YokoZar_> no it's nothing upstream yet
[11:12] <slangasek> seb128: well, it's not supported by upstream debhelper anyway
=== Andy80 [n=ptlug@host97-200-dynamic.22-79-r.retail.telecomitalia.it]  has joined #ubuntu-devel
[11:13] <slangasek> YokoZar_: I would suggest conditionally setting a variable in debian/rules based on the host architecture, containing the list of "extra" directories you're adding, and then pass that as an argument to dh_installdirs
[11:14] <slangasek> (n.b., if this source package builds more than one binary package, you'll also want to use -p and -N options to make sure you don't add the dir to packages that don't need it)
[11:14] <slangasek> oh... also, if this is a /non/-empty dir in the package, you normally don't need to list it in .dirs at all...
[11:14] <YokoZar_> slangasek: it builds two binaries, one of which is dependent on the other (wine and wine-dev)
=== MacSlow [n=mirco@unaffiliated/macslow]  has joined #ubuntu-devel
=== Andy80 [n=ptlug@host97-200-dynamic.22-79-r.retail.telecomitalia.it]  has left #ubuntu-devel ["Sto] 
[11:15] <YokoZar_> slangasek: I'm also thinking about the install file
[11:15] <slangasek> yes, for the install file I have no good answers
[11:16] <YokoZar_> slangasek: if the install file points to something not there (say, usr/lib32/*.so.* on i386), will bad things happen?
[11:16] <slangasek> yes, you'll get a build failure
=== dwatson [n=david@planetwatson.plus.com]  has joined #ubuntu-devel
[11:16] <slangasek> one option: create two separate .install files, symlink to the right one during the build
[11:16] <YokoZar_> Something like wine.install.i386 and wine.install.amd64 ?
[11:17] <slangasek> yes
[11:17] <Keybuk> heh
[11:17] <Keybuk> because I'm not using Vera, but DejaVu
[11:18] <YokoZar_> slangasek: for some reason I think that which .install.arch file to use should be handled automagically, but it's probably just bad memory
[11:18] <Keybuk> mjg59: 12px?
[11:20] <mjg59> Keybuk: Sounds reasonable.
[11:20] <slangasek> YokoZar_: oh, actually it does
[11:20] <slangasek> right, I had a vague memory of that
[11:20] <YokoZar_> slangasek: oh, cool.  So all I should have to do is just have those files then, and no wine.install file
[11:20] <slangasek> YokoZar_: seems so, yes
=== rnorwood [i=rnorwood@nat/redhat/x-62e8ca646943a545]  has joined #ubuntu-devel
[11:22] <YokoZar_> slangasek: actually, I bet (hope) that the way it works is it calls the arch one first and then the general one.  So I'm supposed to put ones common to both in wine.install, and then amd64 specific ones (usr/lib32) into wine.install.amd64
[11:22] <slangasek> YokoZar_: nope, if it finds an arch one it ignores the general one
[11:22] <YokoZar_> slangasek: ahh ok
=== Pici [n=Pici@unaffiliated/pici]  has joined #ubuntu-devel
=== rawler_ [n=ulrik@c-be05e255.191-1-64736c11.cust.bredbandsbolaget.se]  has joined #ubuntu-devel
[11:29] <YokoZar_> slangasek: thank you so much, hopefully I'll have a good Wine package by beta time :)
[11:29] <rawler_> hey.. does anyone know anything about whether nvidia 100.14.19 will make it to Gutsy?
[11:35] <ajmitch> good morning
[11:36] <Keybuk> mjg59: 12px is perfect, my fonts are 13px high <g>
[11:36] <seb128> hey ajmitch
[11:36] <mjg59> Keybuk: Ha
[11:36] <Keybuk> (and since I've been using the new filter for the last few days, I've gotten used to it and now prefer it)
[11:36] <Keybuk> anyhoo
[11:36] <Keybuk> http://people.ubuntu.com/~scott/lcdfilter
[11:37] <Keybuk> source packages and debdiffs for your testing pleasure
[11:37] <Keybuk> works for me (tm)
=== didymo [n=ashley@CPE-61-9-197-223.static.nsw.bigpond.net.au]  has joined #ubuntu-devel
[11:39] <bryce> rawler_: it's too late; we've been in Upstream Version Freeze for a while
[11:39] <mjg59> Keybuk: What's the change to gnome-control-center?
[11:39] <Keybuk> mjg59: changes the top "subpixel" option to use hinting=Slight
[11:39] <Keybuk> which every single thing says is the right option
[11:39] <Keybuk> (with turner's patches)
[11:40] <rawler_> bryce: I kindof figured.. it's too bad.. it fixes a buttload of bugs..
[11:40] <bryce> rawler_: I'll probably make backport debs of it available at some point though once the dust has settled on gutsy
[11:40] <mjg59> Keybuk: Uh. No, I suspect not for the monospace case
[11:40] <Keybuk> mjg59: indeed, which is why the conf.d for the monospace case sets the hinting level :p
[11:40] <Keybuk> (as well as the lcd filter)
[11:40] <mjg59> Keybuk: Ah, ok :)
[11:41] <rawler_> bryce: sounds reasonable.. :) personally I'll resort to envy for now, but it just sucks having to do that for every nvidia-user i persuade into Ubuntu.. :)
[11:41] <mjg59> Slight hinting absolutely kills monospace at low font sizes
[11:42] <alex-weej> Keybuk: PPA? :)
[11:42] <Keybuk> mjg59: hinting gets disabled completely for monospace at low font sizes
[11:42] <mjg59> Now, or previously?
[11:42] <bryce> rawler_: would you be interested in helping with this driver?  A large reason we're not up to date is just manpower
[11:42] <Keybuk> previously and now
[11:42] <mjg59> Hm.
[11:42] <Keybuk> conf.d/20-unhint-small-vera.conf
[11:42] <mjg59> That doesn't fit what I see - altering the hinting settings changes my terminal
[11:42] <Keybuk> mjg59: you might be using DejaVu Mono instead?
[11:43] <bryce> rawler_: pop over to #ubuntu-x if you're interested
[11:43] <alex-weej> mjg59: /etc/fonts seems to change every distro upgrade
[11:43] <mjg59> I'm using whatever a default install gives you
[11:43] <Keybuk> (though they should include the instructions)
[11:43] <Keybuk> not really relevant anyway
[11:44] <mjg59> Ok, let me see how this turns out in a minute
[11:44] <Keybuk> funny: I was sure I'd got the patch wrong, since the fonts looked ... weird
[11:44] <Keybuk> but it turned out I was just so used to the new filter
[11:45] <rawler_> bryce: thanks for the invite, and yes I'd love NOTHING more than help developing Ubuntu, but until that pays my rent, I'm afraid I have to go to sleep to bear another mindless day at work tomorrow.. :)
[11:45] <ajmitch> bryce: what do you need with it? I tend to use nvidia on my gutsy desktop
[11:46] <rawler_> bryce: so, I'll drop by, go to bed and if I get some time I'll see what I can do for the weekend.. :)
[11:46] <bryce> ajmitch: aside from making new packaging (which I hope to automate away for Hardy), it involves just testing out new versions, riding herd on bugs, etc.
[11:46] <bryce> rawler_: cool
[11:47] <ajmitch> right
[11:47] <bryce> we've been using this approach for -fglrx in the forums, and have had some really nice successes there for gutsy
[11:48] <bryce> (not just -fglrx but also -ati and -radeonhd)
[11:52] <mjg59> Keybuk: Ok, playing with hinting seems to suggest that stuff Just Works
=== tormod [n=tormod@80-219-112-71.dclient.hispeed.ch]  has joined #ubuntu-devel
[12:00] <Keybuk> mjg59: your monospace appears with legacy lcd filtering?
[12:00] <mjg59> Keybuk: Yup
[12:01] <Keybuk> ok, seems that we're both happy now? :)
[12:01] <Keybuk> slangasek: are you happy for me to upload?
=== shaya [n=spotter@pool-71-191-93-76.washdc.fios.verizon.net]  has joined #ubuntu-devel
[12:04] <mjg59> Keybuk: Hm. No, I've got some very ugly rendering here with slight hinting
[12:04] <mjg59> Hang on, let me try to figure this out
[12:05] <mjg59> Ok. I'd say at the moment that this change plus full hinting seems to work fine
[12:05] <mjg59> Slight hinting is generating severe colour blurring
[12:05] <shaya> anyone suffer from a bug w/ clearlooks theme in gutsy?
[12:05] <Keybuk> mjg59: yeah, I've alternated between Full and Slight for a while ...
[12:05] <shaya> in pidgin, the tooltip info pop up doesn't always correspond to the right buddy
[12:05] <shaya> but if I switch to human, it works fine
[12:05] <Keybuk> I think the upload should not include the gnome-control-center change, and instead the mail should ask people to compare both and see which they like
[12:06] <mjg59> Keybuk: Yeah, I'd go with that for now
[12:08] <cjwatson> OK, tomorrow morning's CDs are going to be bust I'm afraid, despite my best efforts
[12:08] <cjwatson> I need to fall asleep and I don't have time to finish the last debian-installer change that needs to land for beta
[12:08] <Keybuk> cjwatson: :-(
[12:08] <pkern> ):
[12:08] <cjwatson> but I'll do it first thing tomorrow morning and rebuild CDs
[12:08] <pkern> cjwatson: Well, have a good night anyway. (:
[12:09] <Keybuk> cjwatson: g'night
=== manchicken [n=manckn@12-226-72-69.client.mchsi.com]  has joined #ubuntu-devel
=== Demitar [n=demitar@c-212-031-182-147.cust.broadway.se]  has joined #ubuntu-devel
[12:11] <mjg59> Keybuk: I wonder if the hinting setting interacts badly with the bytecode interpreter
[12:11] <Keybuk> mjg59: in theory, light hinting uses the autohinter
[12:11] <Keybuk> (so I'm told)
[12:11] <mjg59> Ok
[12:12] <cjwatson> actually, I can upload, because there are no udebs for the last thing I wanted - argh
[12:13] <Keybuk>         if ( mode == FT_RENDER_MODE_LIGHT             ||
[12:13] <Keybuk>              face->internal->ignore_unpatented_hinter )
[12:13] <Keybuk>           autohint = 1;
[12:14] <Keybuk> (though I'm not convinced :p)
[12:15] <Keybuk> ah, no, I see; the transition from FC_HINT_SLIGHT -> FT_RENDER_MODE_LIGHT is done by pango
[12:15] <cjwatson> Keybuk: uploading debian-installer; could you take care of accepting it when it's done *AND* libdebian-installer and hw-detect are in the accepted queue
[12:15] <cjwatson> ?
[12:15] <Keybuk> cjwatson: sure
[12:15] <cjwatson> Keybuk: the source needs to not be accepted before the latter happens or we all get to go round again :)
[12:15] <cjwatson> thanks
[12:16] <Keybuk> all three need to be accepted at once?
[12:16] <Keybuk> (as source)
[12:16] <cjwatson> ah, actually, they're in the accepted queue already, so that's not a problem
[12:16] <cjwatson> Keybuk: no, I meant the binaries
[12:16] <Keybuk> right
[12:16] <Keybuk> it should auto-accept now, no?
[12:16] <cjwatson> d-i needs the new binaries of its bits to be published <= its source
[12:17] <cjwatson> the binaries will, but the source will land in unapproved
[12:17] <cjwatson> sorry
[12:17] <cjwatson> the libd-i and hw-detect binaries will auto-accept
[12:17] <Keybuk> :)
[12:17] <cjwatson> the d-i source will land in unapproved
[12:17] <Keybuk> ok
[12:17] <Keybuk> so d-i just needs to be accepted once the upload is done
[12:17] <cjwatson> right, three minutes to process-upload
[12:18] <cjwatson> but Kirsten is going to kill me if I don't get moving now :)
[12:18] <cjwatson> (somewhat rightly so, I got four hours sleep last night)
[12:18] <cjwatson> Keybuk: the kernel's going to need some more NEW love; I did it for some architectures
[12:19] <cjwatson> i386 is still building
[12:19] <Keybuk> there are *some* advantages to your partner living and working in another city :p
=== Keybuk gets to hack late at night again now
[12:19] <cjwatson> hah
[12:19] <cjwatson> night
[12:19] <bryce> cya cjwatson
[12:31] <slangasek> Keybuk: if you and mjg59 are both happy, knock yourself out :)