[01:29] <bryce> keescook: I've successfully booted ume with the fix to patch 132
[01:30] <keescook> \o/
[01:30] <bryce> keescook: I need to do one more test with the proprietary bits enabled (it's missing flash), to be absolutely sure, but I think we can go ahead with an upload.
[01:31] <keescook> bryce: cool; let me know when you've got it ready, and I'll pull the lever
[01:31] <bryce> keescook: I'm generating a .dsc presently, which will include both that and the cve, and will let you know when they're baked.
[01:39] <bdmurray> keescook, bryce - you guys need to use the same analogy.  one of you seems to be in a factory the other in a bakery.
[01:40] <bryce> :-)
[01:40] <bryce> we be makin' loaves of steel here
[01:55] <bryce> kees, ok flash added, and the home apps came up ok
[01:57] <bryce> kees, mind uploading xorg-server from http://people.ubuntu.com/~bryce/Uploads/?
[01:58] <keescook> bryce: sure, one sec, finishing another upload atm
[02:01] <bryce> the xorg package there can upload too
[02:01] <bryce> I just finished verifying it still generates valid xorg.conf files, but with the wacom entries disabled
[02:03] <keescook> bryce: your changes file doesn't need the orig.tar.gz (you can leave off the -sa when building)
[02:04] <bryce> oh yeah
[02:08] <keescook> bryce: if you want 83860 to auto-close, the xorg changelog needs "LP: #83860" rather than "LP# 83860"
[02:08] <keescook> (same goes for the xorg-server, I had intentially not used LP: #xxx in my ppa changelog due to the ppa-auto-close bug
[02:09] <bryce> gota
[02:09] <bryce> well, I'll manually close them then
[02:10] <bryce> I need to search for other related bugs these close anyway
[03:28] <ion_> Argh, blurry fonts. :-(
[03:29] <ion_> (due to some new patch in freetype, i think)
[03:30] <RAOF> Oooh, cool.  The subpixel rendering patch.
[03:31] <ion_> It used to use subpixel rendering already. :-)
[03:31] <ion_> Now full hinting isnt full hinting anymore.
[03:33] <RAOF> Ugh, full hinting. :)
[03:34] <ion_> Yeah, a.k.a. non-blurry fonts.
[03:36] <RAOF> Or thin, anaemic looking strange fonts :).
[03:36] <RAOF> Yay perception.
[03:38] <Hobbsee> ooh, the fonts have even changed on kubuntu
[03:39] <RAOF> I don't seem to notice a difference, but that's probably my 130DPI laptop LCD's fault.
[03:40] <Hobbsee> well, in firefox on kubuntu
[03:41] <Hobbsee> oh, damn
[03:41] <Hobbsee> i forgot to stick my remote client back in last night.
[03:41] <RAOF> Oh, tell a lie.  It seems emacs-snapshot looks better :)
[03:43] <StevenK> Right. Someone remind me to hurt jdong for that nick change
[03:43] <ajmitch> gladly
[03:43] <jdong> just... returning to normal...
[03:43] <jdong> if that's even possible for me.
[03:44] <Hobbsee> !jdong | jdong
[03:44] <ubotu> jdong: jdong is Hobbsee: jdong: yes, but you're FULL OF CRACK!
[03:44] <Hobbsee> silly jdong.
[03:44] <jdong> :)
[03:44] <Hobbsee> RAOF: it's a feature.
[03:44] <ajmitch> RAOF: it's a feature
[03:44] <jdong> ha
[03:44] <jdong> jinx
[03:44] <Hobbsee> ajmitch: ^5
[03:44] <jdong> haha now you can't talk!
[03:45] <jdong> or something like that
[03:45] <ajmitch> :)
[03:46] <jdong> awww, you broke the rules!
[03:46] <jdong> I'm telling!
[03:46] <jdong> before I discovered the computer...
[03:47] <ion_> I miss those days of life *when* i discovered the computer.
[03:47] <ajmitch> hi Burgundavia
[03:47] <ajmitch> welcome back to the real world
[03:49] <Burgundavia> hey ajmitch
[03:53] <Burgundavia> Hobbsee: aren't they fun
[03:53] <Hobbsee> no, they arent
[03:53] <Hobbsee> and apparently we're at 46%, and the month started 12 days ago.
[03:53] <Burgundavia> 18, actually
[03:54] <ajmitch> ah yes, I hit 80% a couple of days ago
[03:54] <ajmitch> but luckily the billing cycle is over in 4 days for me
[03:54] <StevenK> Burgundavia: That would be a billing month
[03:54] <Burgundavia> ahh
[03:54] <Burgundavia> you poor aussies
[03:54] <StevenK> Burgundavia: Which looks to be from the 7th - 7th
[03:54] <Burgundavia> although I got a nasty taste of it in SA
[03:55] <johanbr> Is it some sort of rule to have usage caps if you're in the southern hemisphere? The bits naturally flow to the north, or something?a
[03:56] <Burgundavia> basically, yes
[03:56] <Hobbsee> johanbr: likely - being further away and such
[03:56] <ajmitch> johanbr: they have to swim further
[03:56] <Burgundavia> all those lovely bits are on servers in the US and Europe
[03:57] <StevenK> It's the nasty B word, and .au and .za don't have any
[03:57] <ajmitch> StevenK: you forget the other tri-nations team
[03:57] <StevenK> Oh, of course .nz
[03:58] <ajmitch> we've been promised ADSL2+ for the last couple of years
[03:59] <StevenK> It's slowly being picked up here.
[04:00] <ajmitch> makes uploading to the archive real fun
[04:00] <Burgundavia> I wish RB wasn't so crash-happy
[04:04] <Hobbsee> ajmitch: upload from a remote host.  problem solved.
[04:04] <ajmitch> got to get stuff to a remote host
[04:07] <Hobbsee> ways and means.
[04:12] <RAOF> Oh, man.  Look at all those bugs fixed in the new nvidia drivers.
[04:13] <ion_> URL, please.
[04:13] <johanbr> Is the "driver is closed source" bug fixed? :)
[04:14] <ion_> :-)
[04:14] <RAOF> johanbr: No.  But a lot of others are.
[04:14] <RAOF> ion_: http://www.nvidia.com/object/linux_display_ia32_100.14.19.html
[04:14] <ion_> Thanks
[04:14] <RAOF> Supposedly fixes essentially all the nvidia+compiz bugs.
[04:15] <Hobbsee> nice
[04:23] <ajmitch> I suspect they're already being looked at
[04:23] <sbalneav> Out of curiousity, what happened to gnome-terminal?  I almost had a heart attack! :)
[04:24] <Hobbsee> sbalneav: kde sabbotaged it.
[04:24] <sbalneav> heh
[04:24] <TheMuso> It was a fonts issue.
[04:24] <TheMuso> Something to do with the dpi setting.
[04:24] <sbalneav> One pixel fonts are awesome.
[04:24] <ajmitch> Hobbsee: those evil, nasty kde people
[04:25] <sbalneav> I had to break the glass on the front of the little box that holds /usr/bin/xterm, and put it back into service :)
[04:25] <Hobbsee> ajmitch: indeed.
[04:25] <Hobbsee> at least our systems actually work
[04:26] <ajmitch> they do? that's a good change :)
[04:26] <sbalneav> FIGHT FIGHT FIGHT FIGHT
[04:27] <mjg59> Ok, that's less bad than I was expecting
[04:27] <mjg59> Though the perception is certainly that the fonts are slightly more blurred than before
[04:27] <mjg59> (Well, the fonts /are/ slightly more blurred than before, but)

[04:28] <sbalneav> OW
[04:28] <ScottK> Hobbsee: Thrown from that far away the impact velocity would be pretty interesting.
[04:28] <mjg59> The spacing is clearly more consistent than it was before
[04:29] <Hobbsee> ScottK: there are ways and means.
[04:29] <sbalneav> SORDS
[04:29] <sbalneav> Sub Orbital Rock Delivery System
[04:29] <ScottK> Hobbsee: I wasn't doubting you, I was just going to enjoy the kinetic effects.
[04:30] <Hobbsee> sbalneav: :)
[04:30] <mjg59> The basic effect is that stuff that used to be white is now slightly dimmed in order to remove the harshness of the cutoff
[04:30] <mjg59> It's interesting to compare them in xmag
[04:31] <mjg59> Oh, I *see*
[04:32] <mjg59> subpixel in terms of subpixel alignment, not subpixel in terms of subpixel rendering
[04:32] <mjg59> That makes sense
[04:44] <bryce> kees, btw I got xserver patched, built, and tested on my laptop.  It's good to go:  http://people.ubuntu.com/~bryce/Uploads/
[04:44] <Hobbsee> bryce: does it break X?  :P
[04:45] <bryce> :-P
[04:45] <ajmitch> wouldn't that be fun, right before the beta release?
[04:45] <bryce> this makes it so compiz works with -nvidia, and fixes a CVE
[04:45] <ajmitch> fun
[04:45] <Hobbsee> ajmitch: well, apt was segfaulting yesterday...
[04:45] <ajmitch> Hobbsee: I know :)
[04:46] <ajmitch> thankfully I didn't get that upgrade
[04:46] <Hobbsee> so it's about the right time
[04:46] <ajmitch> I've put in all but 1 fix that's needed, so that should cause fun for people
[05:07] <ajmitch> Hobbsee: isn't that just delegation?
[05:07] <Hobbsee> ajmitch: not when i'm on both teams.

[05:07] <ajmitch> but you don't have to be the one to touch it, when you've got your slaves
[05:08] <Hobbsee> this is true
[05:09] <Hobbsee> bhale: did you have any opinion on the new beagle?
[05:12] <calc> Hobbsee: hi! :)
[05:12] <Hobbsee> hiya calc!
[05:12] <ajmitch> hey calc
[05:12] <Hobbsee> ajmitch: i dont have *enough* slaves :P
[05:12] <calc> ajmitch: hi
[05:15] <lifeless> mmmm slaves
[05:15] <Hobbsee> grr.  why do people keep wnating stacks of new packages?
[05:16] <lifeless> because
[05:16] <ajmitch> there's all this cool stuff that would just make ubuntu so much better
[05:16] <ajmitch> except we don't have time
[05:16] <Hobbsee> ajmitch: indeed.
[05:17] <Hobbsee> ScottK: FYI, i want to put a blanket NO to all new packages at this point - we're a month from release, and the release team is attempting to get a beta together.  the archive team is either working busily on the beta stuff, or is working busily on getting their fixes in.
[05:20] <Hobbsee> bddebian: how well does awn actually work?  (https://bugs.edge.launchpad.net/ubuntu/+bug/118589)
[05:20] <ubotu> Launchpad bug 118589 in ubuntu "[needs-packaging]  Avant Window Navigator" [Wishlist,Incomplete] 
[05:21] <bddebian> me?
[05:21] <StevenK> Hobbsee: Agreed.
[05:22] <Hobbsee> bddebian: yes, you
[05:22] <Hobbsee> StevenK: perhaps modulo the awn, as that's been requested a lot
[05:22] <Hobbsee> StevenK: please look thru the bugs, if you can get the time off wokr :P
[05:23] <StevenK> Hobbsee: I'll try.
[05:23] <Hobbsee> StevenK: thanks
[05:23] <bddebian> Hobbsee: How the heck would I know?
[05:23] <Hobbsee> bddebian: you advocated it.
[05:24] <bddebian> I did? Hmm
[05:24] <StevenK> Ha!
[05:24] <StevenK> Hobbsee: Note, let's not +1 anything bddebian touched.
[05:24] <StevenK> :-P
[05:24] <bddebian>  "I was not able to do an install or execution test so I cant comment on that portion. Thanks for your contribution!"
[05:25] <bddebian> I had no Gutsy box at that point, I merely advocated the packaging itself
[05:27] <Hobbsee> bddebian: ok, then please test it in a gutsy box now then :)
[05:27] <ajmitch> Hobbsee: so I'm not allowed to dump some new packages in a week before release?
[05:27] <ajmitch> how unfair
[05:27] <LaserJock> Hobbsee: what are you WONTFIX'ing
[05:27] <LaserJock> ?
[05:28] <Hobbsee> LaserJock: a bug that wants to sync ~5 packages, add more, and do a whole stack fo rebuilds
[05:28] <Hobbsee> ajmitch: :P
[05:28] <ajmitch> hey LaserJock
[05:28] <Hobbsee> StevenK: can you ack https://bugs.edge.launchpad.net/debian/+source/youtube-dl/+bug/137350 as well please?
[05:28] <ubotu> Launchpad bug 137350 in youtube-dl "Please sync youtube-dl (universe) from Debian unstable (main)" [Undecided,New] 
[05:28] <LaserJock> Hobbsee: you can't wishlist?
[05:28] <bddebian> Aye, why are we looking at/considering new packages?
[05:28] <Hobbsee> LaserJock: it's already a wishlist.  i'm doing this with my motu-uvf hat on.
[05:28] <LaserJock> oh, it's a UVF
[05:29] <Hobbsee> bddebian: because people are attemtping to file new package freeze exceptions for them
[05:29] <bddebian> OK, let me rebuild and test
[05:29] <Hobbsee> bddebian: if you care about it at all, that is
[05:29] <bddebian> No more or less than any of the other worthless work I do :-)
[05:29] <StevenK> Hobbsee: Done.
[05:30] <Hobbsee> StevenK: great, thanks
[05:32] <ScottK> Hobbsee: Agreed on New packages.  The only exception I think we should consider is the lightening lanuage packs as translation is something that's supposed to be being done right now.
[05:32] <Hobbsee> ScottK: modulo anything of great importance, yes.
[05:32] <Hobbsee> ScottK: i'm thinking of the random crack on there, which i'm slowly going thru.
[05:33] <ScottK> Hobbsee: Agreed.
[05:33] <bddebian> So look at awn or no?
[05:33] <Hobbsee> bddebian: if you care enough.  it's a reasonably wanted package - if it works, then i'm inclined to think about accepting it
[05:33] <Hobbsee> (from teh forums, anyway)
[05:37] <Hobbsee> ScottK: any objection to me shunting the ddclient bug to dholbach to decide on?  he wants kmos to contribute, and i dont have the motivation to audit the code, when i've seen the previous incarnations of the bug.
[05:38] <Hobbsee> it's either that, or i'll mark it as wontfix, for the above reason.
[05:38] <Hobbsee> StevenK: ^ ?
[05:38] <ScottK> Hobbsee: I've gone to great lengths to avoid thinking about that bug.
[05:38] <ScottK> I intend to continue.
[05:38] <Hobbsee> ScottK: hehe :)
[05:38] <ScottK> If someone wants to look into it and ack it, I've no objections.
[05:38] <ScottK> His other one should be won't fixed.
[05:39] <Hobbsee> ajmitch: i'm happy to delegate it to you, if you want it.
[05:39] <Hobbsee> ajmitch: i just dont want to touch the damned thing.
[05:39] <StevenK> Hobbsee: Throw ddclient at dholbach
[05:39] <Hobbsee> StevenK: yes, i think that's a good idea.  he's trying to get kmos to contribute again, so...
[05:40] <ajmitch> I keep getting other bugs for me to fix thrown at me anyway
[05:40] <ScottK> ajmitch: Did you get your FAI UVFe approved?
[05:40] <ScottK> I don't recall.
[05:40] <ajmitch> ScottK: that was siretart
[05:40] <Hobbsee> ScottK: yeah, well.
[05:40] <ScottK> Ah.  Sorry.
[05:41] <ajmitch> I haven't been touching universe much
[05:41] <ajmitch> thought I need to file a sync requst for phpgw, which you approved on irc
[05:44] <Hobbsee> ScottK: here you go, https://bugs.edge.launchpad.net/ubuntu/+source/ddclient/+bug/132694/
[05:44] <ubotu> Launchpad bug 132694 in ddclient "Please merge ddclient (3.7.3-2) from Debian unstable" [Undecided,New] 
[05:44] <bddebian> So leave psi broken eh? :-)
[05:44] <Hobbsee> bddebian: qca is still messed.
[05:44] <Hobbsee> afaik
[05:44] <ScottK> Hobbsee: Why do I want to click on that link?
[05:45] <Hobbsee> ScottK: to see my last comment.
[05:45] <bddebian> Hobbsee: Wouldn't surprise me :-)
[05:45] <ScottK> Ah
[05:45] <Hobbsee> sorry, i'm defaulting to edge atm.
[05:46] <ScottK> Hobbsee: I'm good with your comment.
[05:46] <Hobbsee> ScottK: :D
[05:46] <Hobbsee> ScottK: 4th incarnation.  quite good, really
[05:46] <ScottK> Yes.
[05:46] <ScottK> I definitely lack confidence in that being correct, so yes.  A good comment.
[05:47] <Hobbsee> ScottK: fine to WONTFIX https://bugs.edge.launchpad.net/ubuntu/+bug/134504 ?
[05:47] <ubotu> Launchpad bug 134504 in debian "[needs-packaging]  tapioca-glib" [Unknown,Fix released] 
[05:47] <bddebian> Gah, awn needs compiz
[05:48] <bddebian> will compiz --replace work for just this session or permanently replace?
[05:48] <ajmitch> Hobbsee: it's a sync request, but could you note on https://bugs.edge.launchpad.net/ubuntu/+source/phpgroupware/+bug/140859 that it was approved for UVFe on irc? :)
[05:48] <ubotu> Launchpad bug 140859 in phpgroupware "Please sync phpgroupware (universe) from Debian unstable (main)" [Undecided,Confirmed] 
[05:49] <Hobbsee> ajmitch: done
[05:49] <Hobbsee> Tapioca is a library that abstracts away the D-Bus details and presents
[05:49] <Hobbsee> the developer a native object structure, very similar to its Telepathy
[05:49] <Hobbsee> counter-parts. The D-Bus mechanism of request-reply is presented as
[05:49] <Hobbsee> methods and callbacks in the local language/toolkit used.
[05:49] <Hobbsee> hum.
[05:50] <ajmitch> Hobbsee: thanks
[05:50] <Hobbsee> ajmitch: no problem.
[05:51] <ajmitch> does it fall under the ubuntu mobile area?
[05:51] <Hobbsee> ajmitch: i'm presuming the world wont break by me declining it?
[05:51] <Hobbsee> ajmitch: i have no idea.  Mithrandir didnt mention it.
[05:51] <Hobbsee> so i dont think so
[05:52] <Hobbsee> besides, it's new to ubuntu, and a u-m person hastn filed it.
[05:52] <YokoZar_> hehe https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/140862
[05:53] <ubotu> Launchpad bug 140862 in gnome-games "Nibbles with more than 1 human player causes invincible zombie worms" [Undecided,New] 
[05:53] <bddebian> OK, awn seems to work, though I don't see anything great about it
[05:53] <Burgundavia> Hobbsee: tapioca is used by the QT/KDE wierdos for Telepathy stuff
[05:53] <Burgundavia> :)
[05:53] <ajmitch> Hobbsee: I don't know enough about it to comment :)
[05:53] <Hobbsee> Burgundavia: heh.  so, seeing as claerly nothing uses it now...
[05:54] <ajmitch> Hobbsee: depends, what's the bug?
[05:54] <ajmitch> we already have some tapioca stuff in the archive
[05:54] <Hobbsee> ajmitch: https://bugs.edge.launchpad.net/ubuntu/+bug/134504
[05:54] <ubotu> Launchpad bug 134504 in debian "[needs-packaging]  tapioca-glib" [Unknown,Fix released] 
[05:55] <ajmitch> right, and he's been doing much of the telepathy-related stuff lately, I think
[05:56] <Hobbsee> bddebian: be useful and upload https://bugs.edge.launchpad.net/ubuntu/+source/xournal/+bug/137934 please (check the code first, etc)
[05:56] <ubotu> Launchpad bug 137934 in xournal "Please sponsor xournal 0.4.1" [Undecided,Confirmed] 
[05:56] <bddebian> Hobbsee: When/if this boson build ever finishes, I'll be glad to
[05:57] <Hobbsee> StevenK: ScottK: after the discussions, what's your opinion on https://bugs.edge.launchpad.net/ubuntu/+source/libtelepathy/+bug/137953 and https://bugs.edge.launchpad.net/ubuntu/+source/telepathy-gabble/+bug/137955
[05:57] <ubotu> Launchpad bug 137953 in libtelepathy "[UVFe]  Please sync libtelepathy from debian (main)" [Undecided,Incomplete] 
[05:57] <Hobbsee> (and yes, i will write that mail eventually)
[05:57] <Hobbsee> calc: ooo 2.3 is already in gutsy, no?
[05:58] <Hobbsee> some nutter has filed a bug for it, and subscribed motu-uvf - and hasnt touched the packaging.
[05:58] <ajmitch> hehe
[05:58] <ajmitch> they're at least trying to follow the process :)
[05:58] <Hobbsee> oh, still the rc1 in gutsy
[05:59] <Hobbsee> ajmitch: they've missed the lesson on main and universe, though.
[05:59] <Hobbsee> ajmitch: https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/140703
[05:59] <ubotu> Launchpad bug 140703 in openoffice.org "UVF exception:  OpenOffice.org 2.3.0 (gutsy)" [Undecided,New] 
[05:59] <ajmitch> did they attach a build log? :)
[05:59] <Hobbsee> nope
[06:00] <Hobbsee> didnt even attach a diffstat
[06:00] <ajmitch> that's a shame
[06:05] <ScottK> Hobbsee: The telepathy packages have a blanket UME handwave according to some as yet (AFAIK) undocumented release team decision.  Who am I to have an opinion.
[06:06] <ScottK> Hobbsee: I'd say assign it to calc and unsub motu-uvf.
[06:06] <Hobbsee> ScottK: or just say "we're tracking this in other ways" and mark as invalid.
[06:07] <ScottK> Whatever.
[06:07] <ScottK> Assign to calc will make the reporter feel better about their contribution.
[06:07] <Hobbsee> oh, sigh.  are you more bitter at the release team or LP now?
[06:07] <ajmitch> or just plain bitter?
[06:07] <ScottK> Depending on who it is, that woulc be good or bad.
[06:08] <ScottK> I'm more bitter at LP.
[06:08] <bddebian> heh
[06:08] <ajmitch> that's a surprise
[06:08] <ScottK> I do think it a substantial process failure that there is still no documentation of a general waiver of a whole raft of packages.
[06:08] <ScottK> The release team thing will pass.  LP is a long term bitter.
[06:08] <Hobbsee> ScottK: well, the release manager is changing.  wait a bit, and hopefully it'll all start making more sense. :P
[06:10] <ScottK> Hobbsee: Since you were in on the release team thing, I'd suggest you mark them approved.
[06:10] <bddebian> Uhm, where am I getting xournal 0.4.1 from?
[06:11] <Hobbsee> done
[06:11] <ScottK> Hobbsee: I'm leaning no on the mod-wsgi thing.
[06:11] <ScottK> Said so in the bug.
[06:12] <ScottK> It's gonna be a big thing someday isn't a great rationale at this point IMO.
[06:12] <Hobbsee> ScottK: noted, please mark as wontfix.
[06:13] <ScottK> DOne
[06:13] <Hobbsee> cool
[06:15] <ScottK> Hobbsee, StevenK, zul, soren: Any objection to me won't fixing Bug #118589
[06:15] <ubotu> Launchpad bug 118589 in ubuntu "[needs-packaging]  Avant Window Navigator" [Wishlist,Incomplete]  https://launchpad.net/bugs/118589
[06:15] <bddebian> Hobbsee: Where is xournal supposed to come from?  I'm not following that bug and I don't see a 0.4.1 on his ppa
[06:15] <StevenK> ScottK: Fixing it how?
[06:15] <ScottK> StevenK: "Won't Fix"ing it.
[06:15] <Hobbsee> bddebian: i thought it was there.
[06:15] <ScottK> As it we won't include it in Gutsy.
[06:16] <Hobbsee> ScottK: only that a lot of people want it.  but, it hasnt been approved, and the arhcive admins have only got 4 weeks.
[06:16] <ScottK> They can get it from his PPA.
[06:16] <bddebian> Hobbsee: His 0.4.0.1 is there.  Am I missing something?
[06:17] <StevenK> Is Avant Window Navigator related to what bddebian is looking at for Hobbsee?
[06:17] <ScottK> Hobbsee and bddebian: IIRC, bluekaja was going to take care of that one.
[06:17] <ScottK> StevenK: No
[06:17] <Hobbsee> StevenK: no, althouhg i'd asked him to before.
[06:17] <bddebian> ScottK: xournal?
[06:17] <ScottK> Yeah
[06:18] <bddebian> Ah, OK
[06:18] <bddebian> StevenK: I built and ran it earlier.  Seems to work, though nothing special to me but what the hell do I know? :-)
[06:18] <bddebian> Though i do think it should probably depend or at least suggest compiz
[06:20] <LaserJock> ScottK, Hobbsee: are the bugs you're WONTFIX'ing specifically FFe bugs?
[06:20] <ScottK> LaserJock: Yes.
[06:21] <ScottK> UVFe or New package exception
[06:21] <LaserJock> so you're leaving the "needs-packaging" bug?
[06:21] <ScottK> It's the same bug.  Not sure what else to to.
[06:21] <LaserJock> I think we should do it differently
[06:22] <LaserJock> a WONTFIX on a "needs-packaging" bug indicates that we aren't going to include it *ever*
[06:23] <LaserJock> there should be a different bug files for the FFe or UVFe
[06:23] <Hobbsee> LaserJock: i'm wontfixing the uvfe bugs, and tryign to remember to just unsub the n-p bugs.
[06:23] <Hobbsee> LaserJock: but i think i missed a couple.
[06:23] <LaserJock> k
[06:24] <LaserJock> I just don't think we should WONTFIX stuff that's just "won't fix for gutsy"
[06:24] <Hobbsee> LaserJock: yeah, just hte uvfe's.  or at least, that's hte plan
[06:25] <LaserJock> that makes sense since you're dealing with a specific exception request
[06:27] <RAOF> bddebian: It doesn't actually *need* compiz.  It (should) work with xcompmgr, too.  And kwin.
[06:28] <bddebian> Ah, I didn't look that closely, just noticed that when it failed to run it said it wanted compiz :-)
[06:31] <RAOF> Yeah.  Because compiz is obviously the only composite manager around :(.
[06:32] <bddebian> heh
[06:32] <ajmitch> Hobbsee: more fun at uni?
[06:32] <Hobbsee> ajmitch: no, it's uni break.  work.
[06:33] <ajmitch> ah, unfortunate
[06:33] <Hobbsee> ajmitch: so i'm using this time to figure out what i want to step down from, ubuntu-wise, and will likely put that into action after the break.
[06:33] <Hobbsee> ajmitch: very much so - regional high up manager is in tomorrow, so it all has to be perfect.  *shudder*
[06:33] <bddebian> Nooo :-(
[06:33] <ajmitch> ouch :(
[06:34] <Hobbsee> ajmitch: probably other important people too, due to the takeover
[06:35] <bddebian> Hobbsee: You aren't allowed to step down from anything :-(
[06:35] <ajmitch> you're working for a different company now?
[06:35] <LaserJock> some days I do like being a career student ;-)
[06:35] <Hobbsee> ajmitch: we're under as coles - we now have lots of coles stuff - but wesfarmers is buying otu coles.
[06:35] <ajmitch> hehe
[06:35] <Hobbsee> hm.  maroon != black.
[06:36] <ajmitch> close enough
[06:36] <Hobbsee> yeah, well.  that tends to work better if i'm the highest person in the store, or the second highest, where the highest doesnt give a damn.
[06:37] <Hobbsee> (there was no customers anyway, it was late at night)
[06:38] <Hobbsee> bddebian: tough.  i'm working a fair bit, and i need to concentrate on uni.
[06:38] <bddebian> Sheesh, none of you are any fun anymore :-)
[06:38] <Hobbsee> and i actually need reasonable amounts of sleep, etc.
[06:39] <ajmitch> bddebian: I think it's a good idea for people to step back when necessary
[06:39] <bddebian> I'm kidding for gosh sakes, it's just not the same these days
[06:39] <ajmitch> Hobbsee: I expect that after exams you'll be around a bit more
[06:39] <ajmitch> unless you're planning to do stuff at uni over summer?
[06:42] <Hobbsee> ajmitch: now there's a good question.
[06:42] <Hobbsee> ajmitch: i have no idea
[06:43] <Hobbsee> bddebian: i was saying all of that with a :P, btw.
[06:43] <ajmitch> bye Hobbsee
[07:26] <pitti> Good morning
[07:27] <StevenK> Morning pitti
[07:27] <ajmitch> morning pitti
[07:28] <LaserJock> morning pitti
[07:30] <pitti> yummy!
[07:34] <ajmitch> pitti: opinions on whether enabling the cups options in the [globals]  section is a good thing? details on bug 133932
[07:34] <ubotu> Launchpad bug 133932 in samba "Samba is not configured for using CUPS by default" [Medium,Confirmed]  https://launchpad.net/bugs/133932
[07:35] <slangasek> ajmitch: as opposed to removing the Debian-specific patch that disables CUPS by default?
[07:36] <ajmitch> slangasek: figures that there'd be something like that
[07:36] <pitti> hey slangasek
[07:36] <slangasek> (which I think we should probably drop for lenny too, fwiw, the only question there is whether cups will swap priorities with lpr)
[07:36] <slangasek> pitti: hi-ho
[07:36] <pitti> ajmitch: makes me a little nervous TBH (FF and all that)
[07:37] <pitti> ajmitch: one question is: how does samba printer configuration look nowadays?
[07:37] <pitti> ajmitch: i. e. is there anything we can break in the first place? :)
[07:38] <ajmitch> heh
[07:40] <ajmitch> it's reported to work - I don't have a printer attached so I can't really give an answer there
[07:43] <slangasek> well, there are some behavior differences when using the cups support, last time I used it there was some raciness on startup because cups would accept connections and provide printer lists to smbd queries before it had finished loading its own list of printers
[07:44] <slangasek> but that was years ago, I have no idea if that's a current issue or if there are other issues taking its place
[07:56] <dholbach> good morning
[07:58] <pitti> slangasek: speaking about cups, WDYT about bug 140877?
[07:58] <ubotu> Launchpad bug 140877 in cupsys "new upstream bugfix release 1.3.2 available" [Undecided,New]  https://launchpad.net/bugs/140877
[08:08] <dholbach> tracker is still slowing the machine down too much :-(
[08:18] <slangasek> pitti: do either of the microreleases fix my bug? ;D
[08:18] <pitti> slangasek: nope, I didn't report it upstream yet
[08:18] <slangasek> aw
[08:18] <pitti> but they fix mines :)
[08:18] <pitti> mine, even
[08:19] <dholbach> slangasek: can you change the importance of bugs already?
[08:20] <slangasek> dholbach: I think so, haven't tried it yet :)
[08:20] <dholbach> you're not on the ubuntu-qa team, that's why I thought you might not be able to
[08:20] <dholbach> I can tell heno and/or bdmurray to add you to that team
[08:21] <slangasek> ok, no I can't
[08:21] <dholbach> bdmurray: can you add slangasek to ubuntu-qa?
[08:25] <slangasek> pitti: this change looks like it might need a closer look?: cupsLangDefault() did not attempt to return a language that was supported by the calling application.
[08:26] <StevenK> slangasek: Hey. Why the non-vorlon nick?
[08:26] <slangasek> StevenK: I'm incognito
[08:27] <StevenK> Not very, since I was able to pick you out of the lineup. :-)
[08:27] <slangasek> :-)
[08:30] <pitti> slangasek: just checked this; it only touches appleLangDefault() which we do not even compile
[08:30] <slangasek> pitti: ok then :)
[08:31] <pitti> slangasek: version is running happily here, BTW (I am just uploading it to Debian)
[08:33] <pitti> slangasek: can you please write your formal ack to the bug?
[08:33] <pitti> (or further questions)
[08:35] <linuxemacs> does anyone have the typing in caps characters problem?(ubuntu 7.04). i couldn't type caps characters in tty mode.
[08:36] <linuxemacs> the caps lock led is light, but i couldn't type caps characters.
[08:37] <linuxemacs> is it a bug of ubuntu 7.04?
[08:38] <linuxemacs> does anyone can help me?
[08:40] <dholbach> linuxemacs: I guess you better try #ubuntu+1
[08:40] <dholbach> hey thekorn!
[08:40] <linuxemacs> thx though
[08:41] <thekorn> hi dholbach
[08:41] <StevenK> dholbach: Why, it's 7.04...
[08:42] <dholbach> StevenK: good point
[08:42] <dholbach> linuxemacs: maybe try #ubuntu too
[08:43] <kagou> Good morning
[08:43] <linuxemacs> thanks:)
[09:29] <pitti> wow, the new font rendering after dist-upgrade looks really "wow!"
[09:30] <StevenK> Wow, bad, or wow, good?
[09:30] <pitti> good
[09:30] <pitti> hey seb128
[09:30] <dholbach> heya seb128
[09:45] <TomaszD> pitti, hi, carlos told me there's a new URL for gutsy daily language packs, however I cannot find any information on it, could you tell me the URL?
[09:46] <pitti> TomaszD: they are uploaded straight into gutsy proper
[09:47] <TomaszD> pitti, ah, thanks.
[09:55] <carlos> pitti: TomaszD just told me that restricted-manager needs an update in rosetta given that it just changed a string with its latest update
[09:55] <TomaszD> not *a* string, a hell lot of strings :] 
[09:56] <seb128> pitti: is that ok if we update libthai 0.1.8 to 0.1.9 (the new version is already in Debian)? The new pango1.0 configure requires 0.1.9
[09:56] <pitti> seb128: upstream changelog?
[09:56] <seb128> pitti: I didn't look yet, let me get the version, changelog, debdiff, etc
[09:56] <pitti> TomaszD, carlos: last r-m did not change any string
[09:56] <seb128> pitti: I just know that pango can't be updated and that Debian has the new version
[09:57] <seb128> I'll do that later when I'm done with GNOME 2.20
[09:57] <carlos> pitti: so the update we did on Monday included already those changes?
[09:57] <TomaszD> pitti, so why do I have r-m completely in English apart from the deskop entry
[09:57] <TomaszD> maybe it's just a langpack delay
[09:57] <carlos> TomaszD: I guess that, yes
[09:58] <TomaszD> but if the strings haven't changed a bit...
[09:58] <TomaszD> I don't get it at all now
[09:59] <TomaszD> is there a public place where I can look up the next langpack upload date?
[09:59] <pitti> TomaszD: gutsy is auto-updated every Sunday and Wednesday
[10:00] <pitti> right, current langpacks don't have r-m strings
[10:00] <TomaszD> Wednesday you say, so today, alright, we'll see if the update contains r-m
[10:01] <TomaszD> ahh, something to do with main -> restricted move pitti right?
[10:01] <pitti> yes, that gave some trouble
[10:01] <TomaszD> this is a serious issue :P
[10:01] <pitti> oh, bleh
[10:01] <pitti> rosetta-gutsy-updates.tar.gz -> rosetta-gutsy-2007-09-14.tar.gz
[10:01] <pitti> carlos: ^
[10:01] <pitti> carlos: it should point to -18
[10:01] <TomaszD> doh!
[10:01] <pitti> carlos: however, rosetta-gutsy-2007-09-18.tar.gz does not have restricted-manager either
[10:03] <carlos> isn't it still updating the link?
[10:03] <carlos> :-(
[10:03] <carlos> grr...
[10:03] <TomaszD> :[
[10:03] <TomaszD> well at least you know where the issue is lying
[10:03] <carlos> ok, I will review it today and make sure it includes that
[10:05] <TomaszD> another day saved by carlos and pitti, my heroes!
[10:05] <TomaszD> bbl
[10:08] <ion_> channel.find_all {|user| user.pirate? }.each {|user| user.yarr! }
[10:08] <StevenK> ion_: Yarr, walk the plank, ye landlubbing varmit!
[10:08] <StevenK> *cough* Or something
[10:09] <maikmerten> (this pirate movie was rated "ARRRRRR!!!")
[10:09] <StevenK> maikmerten: Booo, hiss!
[10:09] <maikmerten> :)
[10:33] <pitti> Keybuk: mmmm new smooth fonts :)
[10:34] <ion_> Ew! Ew! Ew!
[10:34] <ion_> Blurry fonts. :-(
[10:34] <ion_> The full hinting setting isnt respected anymore.
[10:35] <Keybuk> ion_: check /etc/fonts/conf.d to make sure you haven't hard-nailed it anywhere
[10:37] <ion_> keybuk: The setting in my Font settings should override that, shouldnt it? Its set to full
[10:37] <ion_> The fonts looked perfect until last nights updates.
[10:37] <Keybuk> ion_: not that I know of
[10:37] <Keybuk> afaik, the conf.d overrides everything
[10:37] <ion_> Anyway, i havent modified anything in /etc/fonts
[10:38] <Keybuk> check your dpi is right, set sub-pixel (LCD) and either Full or Slight hinting, depending on personal preference
[10:40] <ion_> All of that should be correctly set. And if i set hinting off, the change from the current state to no hinting is clearly visible.
[10:40] <Keybuk> can you nopaste me an ls of /etc/fonts/conf.d
[10:40] <ion_> Currently it seems like hinting is full using subpixel boundaries, instead of pixel boundaries. Thus, fonts are more blurry than before.
[10:41] <Keybuk> ion_: that sounds like Subpixel smoothing to me?
[10:42] <Keybuk> for me, when Subpixel (LCDs) is selected, each of the Hinting options (None thru Full) looks different from the other
[10:42] <ion_> I definitely agree with using subpixel antialiasing, but not with subpixel hinting.
[10:42] <pitti> right, here too; they are much smoother, but a bit blurry
[10:42] <Keybuk> and each looks different from when Smoothing = none
[10:42] <Keybuk> ion_: uh, there's no such thing as Subpixel hinting
[10:42] <hunger> Any progress on the open-vm-tools front? It would rock for me to have ubuntu work in a VMware VM out of the box with all the additional magic;-)
[10:43] <soren> hunger: I've started on the packaging, but there's still a bit of work to do.
[10:43] <soren> hunger: It's too late for gutsy anyway.
[10:44] <hunger> soren: I know you started, I am using your debs:-)
[10:44] <ion_> keybuk: http://pastebin.ca/703001
[10:44] <soren> hunger: Oh, right :)
[10:44] <hunger> soren: The modules are missing, but that was to be expected:-)
[10:44] <soren> hunger: Yes, that's the bit I'm missing.
[10:45] <soren> hunger: It's waaay to late to build them into l-u-m, but some module-assistant goodness would be a good start.
[10:45] <Keybuk> ion_: can you take screenshots of the font appearance dialog with each of the options selected for comparison?
[10:46] <ion_> keybuk: Heres a screenshot of the current fonts: http://heh.fi/tmp/fonts
[10:46] <soren> hunger: Indeed it would. vmware should stop releasing such things so late in our development cycle :)
[10:46] <Keybuk> ion_: that looks right to me?
[10:47] <Keybuk> ion_: the fonts look well-rounded and subpixel anti-aliased
[10:47] <hunger> soren: Any chance of fixing the xorg-config thingy wrt. the mouse driver? It does set up the display driver properly already.
[10:47] <Keybuk> with an order of RGB
[10:47] <ion_> keybuk: When zooming to that, its obvious vertical lines arent distorted to pixel boundaries.
[10:47] <Keybuk> ion_: ?  zooming in on the L I see
[10:47] <Keybuk>   <slight red> <black> <slight blue>
[10:47] <ion_> They bleed to the adjacent subpixels.
[10:47] <ion_> Thus, blurriness.
[10:47] <hunger> And the vmmouse driver is already shipped with ubuntu for ages.
[10:47] <ion_> Ineed. There should be just <black>
[10:47] <Keybuk> no
[10:47] <ion_> indeed
[10:47] <ion_> Thats how it was yesterday.
[10:47] <Keybuk> there should be what you see
[10:47] <soren> hunger: I have no clue about that.
[10:47] <Keybuk> if you want just <black>, you should select greyscale instead
[10:48] <Keybuk> what you've got there is what subpixel is *supposed* to look like
[10:48] <ion_> No, i definitely want diagonal and round lines be subpixel antialiased.
[10:48] <soren> hunger: I've spent very little time on it. If you want to help out, you can start by creating man pages for the binaries in the package.
[10:48] <hunger> soren: I'll file a bugreport and see what will happen:-)
[10:48] <ion_> Horizontal and vertical lines should contain *no* pixels with slight colors.
[10:48] <ion_> Thats full hinting.
[10:49] <Keybuk> ion_: that's not what the papers on font hinting says
[10:49] <Keybuk> http://en.wikipedia.org/wiki/ClearType
[10:49] <Keybuk> esp. see "The word 'Wikipedia' rendered using ClearType"
[10:49] <Keybuk> note that it as the same lines either side as you suggest
[10:49] <ion_> Ive always liked what Linux had much more than ClearType.
[10:49] <ion_> ClearType used to look more blurry.
[10:50] <hunger> What package should I report a bug against when my xorg.conf is suboptimal?
[10:50] <Keybuk> ion_: *shrug* Linux rendered fonts wrong before :p
[10:51] <hunger> Keybuk: The annoying thing is not that the fonts are rendered wrong, but that ubuntu keeps changing the wrongness all the time;-)
[10:52] <Keybuk> ion_: you actually really probably just want greyscale
[10:52] <ion_> I definitely dont want that.
[10:52] <Keybuk> you do
[10:52] <ion_> No. :-)
[10:54] <soren> I have to agree with ion_.. My terminal fonts look slightly blurrier after my reboot. Everything else looks great, though.
[10:54] <ion_> Horizontal and vertical lines were fully distorted to pixel boundaries, thus there was no blurriness since there were no slight pixels or subpixels between the background and the foreground. Diagonal and curved lines were rendered using subpixel antialiasing. Best of both worlds.
[10:55] <ion_> Id just like to have a setting to get that back. I dont care if its the default.
[10:55] <Keybuk> ion_: for a personal preference value of "Best"
[10:55] <ion_> Indeed.
[10:55] <Keybuk> we evaluated this by comparing the rendering with other font renderers (ie. PC and Mac)
[10:55] <ion_> Thus, this is a regression in my personal preference.
[10:55] <pitti> soren: I tend to agree; however, in terminals I usually prefer 'pixelized and sharp' over 'smooth and blurry', whereas in apps I prefer smooth; but I might just be weird :)
[10:55] <ion_> The fonts in MacOSX are abominable.
[10:55] <Keybuk> this now makes fonts look like what they're supposed to look like
[10:56] <Keybuk> it's not a Terminal so much
[10:56] <Keybuk> it seems to particularly affect the default Monospace font
[10:56] <Keybuk> which I agree looks a little too smudged
[10:56] <pitti> firefox looks absolutely awesome now
[10:57] <ion_> I really dont care about what a paper says about what fonts are supposed to look like. Id like to have a setting to get the font rendering i had yesterday, thats all.
[10:57] <Keybuk> adding a setting is almost impossible, since that's a *massive* API change
[10:57] <ion_> :-(
[10:58] <soren> pitti: You'd rather be entirely without antialiasing in your terminal?
[10:58] <ion_> Hopefully someone implements the former rendering algorithm with the new API.
[10:58] <pitti> soren: I'm not sure, I'm a font noob
[10:58] <soren> pitti: :)
[10:58] <pitti> soren: I just know which fonts strain my eyes and which don't
[10:58] <Mithrandir> soren: my terminal is perfectly happy with pure bitmap fonts.
[10:58] <Mithrandir> -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 is nice
[10:59] <ion_> On TFTs, using yesterdays font rendering algorithm is actually sharper than using no antialiasing, since it uses subpixel rendering.
[10:59] <pitti> and slightly pixelized and sharp seems to be less straining for me
[10:59] <pitti> when I look at the terminal font now, I have the impression to see red/green glow
[10:59] <soren> Mithrandir: Which xterm variant do you use?
[10:59] <Mithrandir> soren: pterm
[10:59] <soren> Mithrandir: Oh, I see.
[11:00] <soren> Mithrandir: And that deals well enough with utf8?
[11:01] <cjwatson> linuxemacs: known bug unfortunately; run 'sudo setupcon' at a virtual console and that will fix it until the next reboot
[11:01] <Mithrandir> soren: yes.  iso10646-1
[11:01] <cjwatson> linuxemacs: should be fixed in gutsy
[11:01] <soren> Mithrandir: Oh, right.
[11:02] <Mithrandir> soren: I switched from Eterm to pterm partially because the latter dealt with utf8 and the former didn't.
[11:02] <cjwatson> somebody needs to figure out pterm font handling in the gtk2 branch though
[11:02] <cjwatson> ideally it would be possible to use both server-side and client-side fonts
[11:02] <ion_> In this image, its obvious horizontal lines are as sharp as when using no antialiasing, but vertical lines are blurry. http://en.wikipedia.org/wiki/Image:ClearTypePixels.svg
[11:03] <soren> Mithrandir: I just remember back when I was experimenting with different terms, I found a few that actually rendered them just fine, but most messed up when deleting them again (i.e. removed a byte at a time rather than a character at a time).
[11:03] <ion_> Diagonal and curved lines are as they should be.
[11:03] <Keybuk> ion_: random question; did you try changing the subpixel order to match your laptop screen? :p
[11:03] <pitti> hi tkamppeter
[11:03] <ion_> keybuk: Its correct.
[11:03] <cjwatson> linuxemacs: bug 84156
[11:03] <ubotu> Launchpad bug 84156 in console-setup "Caps Lock not working on TTYs/terminals" [Undecided,Fix released]  https://launchpad.net/bugs/84156
[11:03] <hunger> Keybuk: How do you find out which order is the proper one?
[11:04] <Keybuk> hunger: magnifying glass is a good trick
[11:04] <pitti> mvo: yay, I just (more or less accidentally) enabled compiz again; although it still destroyed my workspace layout, it now at least allows me to manually restore it as I want. That's progress :)
[11:04] <hunger> Keybuk: My screen has 130dpi... even with a magnifying glass it is pretty hard to detect the proper order;-) So I just turned the whole thing off;-)
[11:04] <mvo> pitti: oh, what gnome-control-center versin do you have?
[11:05] <Keybuk> ion_: that image explains quite nicely *why* subpixel smoothing has the lines either side of the black line :p
[11:05] <mvo> pitti: the 2.20 version should include a patch to get it correct when the apperance capplet is used
[11:05] <pitti> mvo: 1:2.20.0-0ubuntu1
[11:05] <ion_> keybuk: In real life, there are thin black bars around pixels. That image doesnt show it.
[11:06] <pitti> mvo: eek, except that it seems to have killed my custom starter in the panel ('offlineimap' -> '-e')
[11:06] <ion_> Id guess that emphasizes the blurriness.
[11:06] <pitti> mvo: s/killed/broke/
[11:07] <mvo> pitti: could you please comment on #116806 on the layout issue? it is supposed to do the right thing now
[11:07] <mvo> pitti: like what layout you had before and what after :)
[11:07] <mvo> pitti: eh, it does not do anyhting with panel launchers, in what way did it break?
[11:07] <pitti> mvo: that's not the same thing
[11:08] <pitti> mvo: I had 4 workspaces before and after the switch, but when enabling compiz, all my apps are moved to space 1 and I manually have to move them back
[11:08] <mvo> pitti: but the layout is preserved?
[11:09] <Keybuk> ion_: having the dpi set wrong also does; if your screen is 117, 125 or higher dpi and you have it set to 96, for example
[11:09] <tkamppeter> hi pitti
[11:09] <ion_> keybuk: My screens DPI is set correctly using the DisplaySize setting in xorg.conf.
[11:10] <pitti> mvo: the position within the workspace, yes
[11:10] <Keybuk> ion_: what's it set to?
[11:10] <ion_>         DisplaySize     472 295
[11:10] <ion_> (**) NVIDIA(0): DPI set to (90, 90); computed from "DisplaySize" Monitor
[11:11] <Keybuk> you have an 18.6" monitor?
[11:11] <ion_> % units 'sqrt((472mm)^2+(295mm)^2)' inch * 21.913578
[11:11] <ubotu> valid types: mass, length, time, scheduling, temperature, temp. diff., current, charge, potential, resistance, conductance, capacitance, magn. flux, inductance, flux density, molecular qty, size of a mol, lum. intens., luminous flux, illuminance, luminance, angle, solid angle, data, data transfer, quantity, interest rate, concentration, force, area, volume, velocity, rot. velocity, fluid flow, gas flow, pressure, (1 more message)
[11:11] <ion_> Whoops, irssi merged the lines. * 21.913578 was the output.
[11:12] <Keybuk> that's still an odd size <g>
[11:12] <ion_> 22?
[11:12] <mvo> pitti: ok, thanks. we currently do not support preserving the workspace on switching from metacity<->compiz
[11:12] <Keybuk> LCD are usually exactly the right size <g>
[11:13] <pitti> mvo: hmkay
[11:13] <pitti> mvo: as long as session saving etc. still works, that's good enough
[11:13] <Keybuk> ion_: so you're using a res of 1600x1000 ?
[11:13] <mvo> pitti: yeah, session-saving workspaces/viewport layout should all be good now
[11:13] <ion_> 16801050
[11:13] <mvo> pitti: but testing is welcome of course :) its just the initial switch that causes this behvaiour, from then on it should be fine
[11:14] <Keybuk> close enough
[11:14] <pitti> mvo: hm, my firefox scrollbar (maximized window) does not work
[11:14] <Keybuk> *shrug*
[11:14] <pitti> mvo: or, rather, if I grab it on the right hand side (at the edge of the screen) it doesn't
[11:14] <pitti> that's quite disturbing
[11:14] <mvo> pitti: but if you have a tiny bit away from the side it does work?
[11:15] <ion_> keybuk: Just adding one or two millimeters to both measurements makes it 22. There could easily have been such a measurement error.
[11:15] <ion_> That shouldnt really matter.
[11:16] <pitti> mvo: not a tiny bit, but if I grab it on the left part of the scrollbar, it works
[11:16] <pitti> mvo: hm, 5 pixels maybe
[11:16] <pitti> mvo: i. e. "move mouse to the right", "move it left until the ends of the scrollbars turn orange"
[11:17] <pitti> mvo: we had a similar bug with the top edge and the Applications menu, didn't we?
[11:17] <mvo> pitti: oh, that is interessting. out of curiosity, can you reproduce if you login again (so that no metacity->compiz siwthc happend before)?
[11:17] <pitti> trying
[11:18] <mvo> pitti: we had a problem that a one pixel area of the screen was always eating events, but that got fixed some weeks ago
[11:19] <pitti> mvo: it didn't restore my desktop completely (all the terminals are missing)
[11:19] <pitti> mvo: eek, and resizing windows now neither shows the content (only a blue rectangle) nor snap to borders
[11:19] <mvo> pitti: the blue rectangle is a feature
[11:20] <pitti> ??
[11:20] <pitti> pidgin wasn't restored from the session either
[11:20] <mvo> pitti: it eliminates a lot of repaint events
[11:21] <pitti> mvo: ok, the panel starter iz gtk bug (I cannot start mutt with Alt+F2 in a terminal any more either)
[11:21] <pitti> mvo: but resizing worked just right with metacity
[11:22] <mvo> pitti:  hm, let me test that session-managment stuff
[11:22] <pitti> mvo: I'll do a gnome-session-save and check again
[11:22] <mvo> pitti: it does work under compiz too (resize) but it is slow on some systems
[11:23] <pitti> mvo: right, on mine for example :) (I filed a bug about that)
[11:24] <pitti> mvo: no, sorry
[11:25] <pitti> mvo: after another gnome-session-save, *both* the workspace *and* the positions are wrecked
[11:27] <mvo> pitti: I'm back, I just tested it and I can reproduce session save problems
[11:28] <pitti> mvo: did you get my scrollback?
 mvo: after another gnome-session-save, *both* the workspace *and* the positions are wrecked
[11:28] <pitti> mvo: and the major problem with resizing windows with just the blue border instead of the window itself is that I cannot see through the original window to see where I should move it to (when making windows smaller)
[11:29] <ion_> Perhaps the window should be translucent while resizing with the border.
[11:29] <pitti> that would help
[11:30] <pitti> and I really miss window/desktop edge snapping
[11:30] <ion_> Me, too.
[11:30] <TomaszD> can anyone tell me what else can I do in order to push this bug down the pipe https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/92806 ?
[11:30] <ubotu> Launchpad bug 92806 in linux-source-2.6.20 "N340S8 laptop needs to have ACPI enabled" [Undecided,Confirmed] 
[11:31] <TomaszD> I've given all the required information
[11:31] <TomaszD> maybe I should assign a person who is responsible for acpi, but then I don't know who that may be
[11:35] <mvo> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/140913
[11:36] <ubotu> Launchpad bug 140913 in compiz "session save/restore does not work" [High,Confirmed] 
[11:36] <pitti> mvo: ah, thanks
[11:48] <pitti> mvo: ah, seb told me why my starter and alt+f2 is broken now, compiz unsets the 'terminal emulator' gconf key; I file a bug
[11:52] <pitti> mvo: bug 140917
[11:52] <ubotu> Launchpad bug 140917 in compiz "enabling compiz unsets the "terminal emulator" gconf key" [Undecided,New]  https://launchpad.net/bugs/140917
[11:53] <mvo> pitti: thanks, its a roller coaster ride
[11:53] <seb128> pitti: ah, you found it ;)
[11:54] <seb128> ah, no, you opened a new bug
[11:54] <pitti> seb128: I didn't find an existing one, I'm happy to make mine a dup
[11:54] <seb128> pitti: bug #135484
[11:54] <ubotu> Launchpad bug 135484 in compiz "Failed to execute child process "-x" (No such file or directory)" [Medium,New]  https://launchpad.net/bugs/135484
[11:55] <seb128> pitti: I knew there was one ;)
[11:55] <seb128> mvo already commented on it
[11:55] <mvo> seb128: I think I said "meeehhhh"
[11:56] <pitti> mvo: ok, that looks like a dup indeed; I'll dup mine
[11:57] <pitti> however, I never deliberately fiddled with the settings; 135484 sounds a bit diffenent, but it's most likely the same cause
[11:58] <seb128> pitti: already duped it ;)
[11:59] <seb128> pitti: the guy didn't change his setting neither, he basically says to unset those to be back to a stock config, enable compiz and stop it
[11:59] <seb128> or it looks like the steps are basically doing that
[11:59] <seb128> anyway iz compiz bog ;)
[12:08] <Keybuk> seb128: happily, iz compiz sprint too :)
[12:10] <seb128> ;)
[12:12] <siretart> seb128: hi
[12:12] <seb128> hey siretart
[12:12] <siretart> seb128: I don't understand the bugtrails correctly. Did you sync live-{helper,initramfs}?
[12:12] <cjwatson> wah, that's not a good plan
[12:13] <cjwatson> live-initramfs is casper renamed for no reason. the changes should be merged back into casper
[12:13] <cjwatson> (where appropriate)
[12:13] <siretart> cjwatson: I talked to daniel, and he dropped the 'casper' package
[12:13] <cjwatson> nevertheless, it's duplication
[12:13] <siretart> so there should be no problem packaging wise
[12:14] <siretart> cjwatson: err, we had this discussion a few months ago, you remember?
[12:14] <Keybuk> cjwatson: well, casper does only really exist in spirit now
[12:14] <cjwatson> there should not be two things in the archive that are basically the same
[12:14] <seb128> siretart: no, you ask for versions which have replaced since
[12:14] <seb128> siretart: does the request still stand for the new versions?
[12:14] <cjwatson> Keybuk: casper still has a lot of code in it. it's totally different from what it used to be, but it's still significant
[12:14] <cjwatson> siretart: and I never really agreed with you then
[12:14] <siretart> cjwatson: well, fai does not work with casper. I have been working for over a week testing fai in ubuntu, and that version really needs live-initramfs
[12:14] <cjwatson> so merge the relevant changes back into casper ...
[12:15] <cjwatson> live-initramfs is not supported on Ubuntu
[12:15] <siretart> cjwatson: I agree with you that the 2 branches should be merged. however daniel told me that he didn't find anyone intereted on the ubuntu side to work with
[12:15] <siretart> cjwatson: last time you agreed to talk to him
[12:15] <cjwatson> you seem to be interested, and you're in ubuntu-core-dev
[12:15] <cjwatson> I have no time
[12:15] <siretart> right
[12:15] <siretart> and I won't have enough time to do that for gutsy.
[12:15] <cjwatson> but you have time to create duplication that will be confusing and create an upgrade problem later
[12:16] <siretart> O'
[12:16] <siretart> err
[12:16] <cjwatson> what happens when some other feature works in casper but not in live-initramfs?
[12:16] <siretart> I'm using packages which are tested and working in debian
[12:16] <cjwatson> for example, I bet live-initramfs doesn't deal with certain changes that were made in gutsy and required workarounds in casper
[12:17] <siretart> cjwatson: right. daniel has basically stripped out the ubiquity hooks
[12:18] <siretart> because he is not interested in that. he focuses  on live-helper
[12:18] <siretart> a reimplementation of root-live, becuase it was not available
[12:19] <siretart> cjwatson: how do you envision collaboration with daniel?
[12:19] <cjwatson> siretart: I envision somebody who isn't me but who is in ubuntu-core-dev becoming interested
[12:19] <siretart> in the past, he complained that nobody was answereing him, so he list interest
[12:20] <cjwatson> at least, somebody who is having trouble with the split ought to help out by merging at least some of the relevant changes
[12:20] <siretart> cjwatson: I have not really a clue about the inner works of caser/live-initramfs. I'd prefer to focus on fai, which uses what is in debian.
[12:20] <cjwatson> that's the obvious starting point
[12:20] <pitti> soren: I think I didn't exaggerate (much)
[12:20] <cjwatson> I'm afraid I think it is utterly wrong to have live-initramfs in Ubuntu at this point, because it's such clear duplication
[12:20] <siretart> you are now preventing me from doing fai work in ubuntu :(
[12:20] <cjwatson> no, I am not
[12:20] <cjwatson> I'm asking you not to do something that's wrong
[12:21] <siretart> look,
[12:21] <cjwatson> please don't make this out as me blocking a specific project
[12:21] <siretart> I have fai packages ready, which work with newer versions of live-initramfs
[12:21] <cjwatson> (and in any case I am but one archive admin and not really speaking as one; I'm speaking as a casper hacker)
[12:21] <soren> pitti: :)
[12:21] <siretart> I'd like to share my work of the last 2 weeks with our users
[12:22] <siretart> now you say that I need to work on casper as well, because of code duplication
[12:22] <cjwatson> I understand, but I would like to avoid a situation where some users have to use casper and some have to use live-initramfs and neither really works properly
[12:22] <cjwatson> that seems just obviously wrong
[12:22] <siretart> this means that fai won't be ready in time for gutsy
[12:23] <StevenK> Hum. Does the installer (on sparc) default to serial console?
[12:23] <siretart> cjwatson: would you accept the following compromise: let's have a FAI bof in boston, where we discuss casper/live-initramfs matters. for gutsy, lets accept the duplication with the intention to fix that for hardy
[12:23] <cjwatson> siretart: if live-initramfs goes into Ubuntu, a critical bug should be filed on it saying that it shouldn't exist
[12:23] <soren> Keybuk: hm?
[12:23] <cjwatson> siretart: on the condition that live-initramfs doesn't go into main
[12:23] <siretart> cjwatson: that's fine for me, as long we don't need to fix it for gutsy
[12:24] <cjwatson> ok
[12:24] <siretart> cjwatson: of course
[12:24] <siretart> cjwatson: fai is universe only anyway
[12:24] <cjwatson> ok
[12:24] <Keybuk> soren: Yarr, it be talk like a pirate day
[12:25] <soren> Shiver me timbers, so it is. Yarr..
[12:25] <siretart> seb128: can't you sync from snapshot.debian.net then?
[12:25] <siretart> or from the morgue mirror on merkel?
[12:25] <cjwatson> we can sync from anything
[12:26] <seb128> siretart: we can sync from anything, I was asking if you want to the new version or the old one
[12:26] <seb128> siretart: if you want the old one please provide a url to the dsc
[12:26] <siretart> seb128: I'm pretty confident that the newer version in unstable still work
[12:26] <cjwatson> StevenK: AIUI (and the installation guide agrees) the kernel's normally supposed to autodetect serial console presence, but if you also have a normal console attached you might have to pass console=ttyS0 to the kernel
[12:26] <siretart> so I'd vote for getting the currently up-to-date versions. it's just that I haven't tested them, but the diffs look sane to me
[12:27] <cjwatson> or maybe ttya or ttyb
[12:29] <StevenK> cjwatson: Ah. I don't want it to use serial console - OpenBoot and 'boot cdrom' works with the screen and keyboard, but as soon as the kernel boots, the monitor goes into standby mode, which makes me suspicious.
[12:30] <cjwatson> StevenK: I'm not sure what the reverse override is
[12:30] <siretart> seb128: would you agree to sync the up-to-date versions? I promise to look after breakages
[12:31] <seb128> siretart: well, we are in UVF period now, I would prefer to have pitti to approve those
[12:31] <seb128> or somebody else from r-t
[12:31] <siretart> seb128: both are universe, and I have exception from the motu-uvf team
[12:31] <seb128> ok, good enough then
[12:31] <StevenK> cjwatson: Appending 'console=tty0' had no effect, either. :-/
[12:31] <cjwatson> Riddell: I'm rebuilding some CDs now to cope with some mirror sync lock failures
[12:31] <seb128> siretart: can you add a comment on the bug saying we should sync the new version?
[12:33] <siretart> seb128: done
[12:33] <seb128> siretart: thanks
[12:33] <siretart> seb128: thank you for syncing them!
[12:37] <cjwatson> asac: bug 139403> so this is agreed to be the best route? how are we handling upgrades?
[12:37] <ubotu> Launchpad bug 139403 in network-manager "network-manager should stop managing any interface configured in /etc/network/interfaces" [High,Confirmed]  https://launchpad.net/bugs/139403
[12:37] <asac> cjwatson: its in the bug
[12:37] <asac> cjwatson: i discussed with mvo
[12:38] <asac> cjwatson: the most reasonable practice appears to be to assume that users that had network-manager installed with auto dhcp interfaces
[12:38] <asac> cjwatson: want those interfaces to be managed through nm
[12:39] <cjwatson> asac: commenting out the iface lines seems like an odd approach; that means you can no longer work around n-m problems using ifup/ifdown by hand
[12:39] <cjwatson> why not comment out the auto lines instead?
[12:39] <mjg59> Riddell: What's supposed to handle brightness changes in Kubuntu?
[12:40] <asac> cjwatson: because then those interfaces are not nm managed
[12:40] <asac> cjwatson: we could have that by just migrating nothing
[12:40] <tkamppeter> pitti, seems that Mike Sweet has replaced my perfectly working workaround by a totally broken fix (bug 140887)
[12:41] <ubotu> Launchpad bug 140887 in cupsys "system-config-printer.py crashed with ValueError in reinit()" [High,Confirmed]  https://launchpad.net/bugs/140887
[12:41] <asac> cjwatson: but that would be a regression for all users that currently use the auto line + nm combination
[12:42] <pitti> tkamppeter: is the fix itself not working? or is it just causing the s-c-p crash?
[12:42] <asac> cjwatson: imo its the most unintrusive migration path we can provide ... its a damn good point to assume that people with network manager + auto dhcp lines currently use nm for those interfaces successfully
[12:43] <fabbione> cjwatson: what's the perl equivalent for if [ -d /boot ] ; then.... ?
[12:44] <cjwatson> asac: hmm, well, we can try it out for beta and see how many people scream
[12:45] <cjwatson> fabbione: if (-d "/boot") { ... }
[12:45] <fabbione> cjwatson: thanks a lot
[12:47] <cjwatson> asac: so, just to be sure, I should not write out either auto lines or iface stanzas for things that are going to be auto dhcp?
[12:49] <asac> right ... installs that come up with network-manager installed by default should stop shipping those
[12:49] <cjwatson> ah yes, hmm, that's the slightly tricky bit
[12:49] <cjwatson> should be possible though
[12:49] <tkamppeter> pitti, the fix itself I did not test. I am now making a new cupsys package with the fix unrolled and my workaround put back. Then I will try whether it works.
[12:50] <Riddell> mjg59: nothing.  kmilo is our special key handler but it doesn't have anything for
[12:50] <Riddell> brightness
[12:50] <pitti> hi Riddell
[12:51] <Riddell> hi pitti, are you doing release management?
[12:51] <cjwatson> asac: netcfg (in d-i) asks for the wireless ESSID; I guess all that does now is influence what happens during the installer, and then it gets discarded
[12:51] <cjwatson> asac: how about if netcfg has asked for a WEP key?
[12:51] <cjwatson> does the user just have to re-enter that later?
[12:51] <cjwatson> 11:51 <cjwatson> asac: netcfg (in d-i) asks for the wireless ESSID; I guess all that does now is influence what happens during the installer, and then it gets discarded
[12:51] <cjwatson> 11:51 <cjwatson> asac: how about if netcfg has asked for a WEP key?
[12:51] <cjwatson> 11:51 <cjwatson> does the user just have to re-enter that later?
[12:52] <mjg59> Riddell: Ok. That kind of needs fixing.
[12:52] <pitti> Riddell: together with slangasek for beta
[12:52] <asac> cjwatson: yes ... unless you are smart and add that info to gconf ;)
[12:52] <mjg59> Riddell: Lots of machines won't do anything without an agent handling that
[12:52] <Riddell> mjg59: what happens in gnome?
[12:53] <Riddell> pitti: is dapper.2 happening?
[12:53] <asac> cjwatson: but i am not sure if we want this ;)
[12:53] <cjwatson> sounds nasty
[12:53] <mjg59> Riddell: gnome-power-manager handles it
[12:53] <pitti> Riddell: -> /query
[12:53] <Riddell> mjg59: are you coming to UDS?  can we spec it there?
[12:53] <mjg59> Riddell: Yeah, but it's going to be broken for people in gutsy
[12:53] <asac> cjwatson: i think adding the essid together with the key would make nm autoconnect to that network when its available
[12:54] <asac> (to gconf)
[12:54] <cjwatson> asac: actually, if you put that ifblacklist_migrate script in network-manager, I could just have the installer run it
[12:54] <cjwatson> which would do the job in d-i without having to rewrite all that code
[12:55] <cjwatson> thing is I can't easily tell at the point when /etc/network/interfaces is first being written whether network-manager is going to be installed
[12:55] <Riddell> mjg59: but not more so than in past releases presumably
[12:55] <cjwatson> so I basically have to do a migration anyway
[12:55] <mjg59> Riddell: Yeah, due to (a) more machines now implementing the ACPI video extension, and (b) us no longer changing it automatically in-kernel (because that just ends up breaking things in stupid ways)
[12:56] <asac> cjwatson: ok, thats sane.
[12:56] <cjwatson> asac: can I rely on /usr/lib/network-manager/ifblacklist_migrate.sh?
[12:56] <asac> cjwatson: however if you add an option to the interface entry, the script will not comment it
[12:56] <asac> e.g. for wep-key case
[12:56] <cjwatson> or indeed essid
[12:56] <asac> cjwatson: otherwise your script should be as simple as commenting out every line ;)
[12:57] <asac> cjwatson: if you want i can provide that ;)
[12:57] <StevenK> Hum, bugger.
[12:57] <cjwatson> that will be present for all installs where wireless was the primary interface
[12:57] <cjwatson> so I think you need to handle that anyway ...
[12:57] <cjwatson> maybe *you* need to do the gconf migration :-)
[12:57] <asac> ouch :) ... but please not for beta
[12:57] <StevenK> console=tty0 has no effect
[12:58] <cjwatson> asac: I think I'll just call ifblacklist_migrate.sh and you can deal with further migrations as necessary
[12:58] <cjwatson> ubiquity will just leave out the stanzas entirely, or only write them out commented out
[12:58] <cjwatson> so it won't affect desktop CD installs
[12:58] <asac> cjwatson: ok ... please set an env INSTALLER_MODE or something
[12:58] <cjwatson> asac: I'll set NETCFG=1
[12:59] <cjwatson> since that's the name of the installer component
[12:59] <asac> ok fine.
[12:59] <cjwatson> asac: why 'sh /usr/lib/network-manager/ifblacklist_migrate.sh'? Why not just make it executable?
[12:59] <asac> cjwatson: well :) ... its not ment for public use, so i didn't bother about that
[01:01] <asac> cjwatson: do you want it executable?
[01:03] <cjwatson> asac: don't mind, just seems like an obvious thing to do
[01:03] <cjwatson> I generally think programs shouldn't have implementation-specific extensions and shouldn't be called with explicit interpreters, so that if you want to rewrite them in another language then you can
[01:03] <asac> cjwatson: yeah ... if i make it executable i should also drop .sh
[01:07] <cjwatson> asac: hang on, I just realised I don't need to do anything at all in d-i
[01:08] <asac> huh?
[01:08] <asac> yes right :) ... i can use NETCFG
[01:08] <cjwatson> asac: we copy /etc/network/interfaces in before the base system install starts; you run ifblacklist_migrate on network-manager configure with a condition that includes being installed from scratch
[01:08] <asac> cool
[01:08] <cjwatson> no, netcfg doesn't need to change at all
[01:08] <cjwatson> you just do it all yourself, which is exactly how I like packages to behave
[01:08] <asac> cjwatson: yes, thats the INSTALLER_MODE env i referred to above
[01:09] <cjwatson> nope
[01:09] <cjwatson> don't need that either
[01:09] <cjwatson> if you need anything like that, just check whether you're being installed from scratch
[01:09] <asac> cjwatson: you mean if no version was installed before?
[01:09] <cjwatson> dpkg --compare-versions "$2" "<<" 0.6.5-0ubuntu12 is true in the installer because no version was previously installed
[01:10] <cjwatson> so network-manager will run ifblacklist_migrate.sh all by itself
[01:10] <asac> cjwatson: maybe thats a bug ... i don't know if thats what we want ... if people install network-manager later it shouldn't touch /e/n/i
[01:11] <asac> cjwatson: don't you thinks so?
[01:11] <jsgotangco> aarrrrr mateys
[01:12] <mvo> have fun Riddell
[01:12] <asac> cjwatson: i just want to migrate people away from buggy behaviour ... not force network-manager on previously configured devices.
[01:13] <cjwatson> asac: hmm, well, if you need to check whether the installer is running, maybe check whether the MENU environment variable is set?
[01:14] <asac> hmm ... that env sounds a bit ambiguous ;)
[01:14] <asac> no idea if any other application uses
[01:15] <soren> cjwatson: Does ubuntu-seeds.pl from tasksel not support multi-lined extended descriptions?
[01:16] <asac> cjwatson: any other env var available ;)? otherwise i would go for MENU now. is that available in both: alternate and ubiquity?
[01:16] <cjwatson> soren: doubt it, feel free to make it
[01:16] <cjwatson> asac: ubiquity isn't relevant; network-manager's postinst is not called by ubiquity
[01:16] <soren> cjwatson: Theme of the day, it seems :)
[01:16] <mvo> ogra: you have a ati 200m or something, right?
[01:16] <mvo> ogra: I would need some compiz testing on this .) ?
[01:17] <asac> cjwatson: ok so this discussion is just about alternate?
[01:17] <cjwatson> asac: problem is that most of the other relevant ones are also used by debconf
[01:17] <cjwatson> asac: yeah
[01:17] <cjwatson> ubiquity's easy, not concerned about that
[01:17] <asac> cjwatson: any ideas for ubiquity install?
[01:17] <asac> cjwatson: oh ok.
[01:17] <asac> cjwatson: can you give a hint so i can summarize our findings in the bug?
[01:18] <cjwatson> asac: I mean, you could check [ "$DEBIAN_FRONTEND" = passthrough ] , but that's not really terribly accurate
[01:18] <asac> cjwatson: maybe we can set a more distinct env? or do you consider that too much for _just_ network-manager tweakage?
[01:19] <cjwatson> I sort of dislike the notion of postinsts knowing they're running in the installer
[01:19] <cjwatson> it opens up possibilities of difficult-to-reproduce behaviour
[01:19] <asac> thats true, then back to square 1 ;)
[01:19] <cjwatson> ok, how about you change that << to lt-nl then, and I make netcfg call ifblacklist_migrate.sh
[01:20] <ion_> Back to 1
[01:22] <asac> cjwatson: ok ... so i test for NETCFG?
[01:22] <cjwatson> what are you going to do within that test that isn't appropriate for general use?
[01:22] <asac> cjwatson: what do you mean by general use?
[01:22] <cjwatson> being run on upgrades
[01:23] <ogra> mvo, oki, give me some time to finish here (guessing i need to log out
[01:23] <ogra> )
[01:23] <asac> cjwatson: i disable auto dhcp interfaces?
[01:23] <cjwatson> err, but don't you do that anyway on upgrades?
[01:24] <cjwatson> asac: I think there may be some confusion about what's happening when
[01:24] <asac> cjwatson: i only migrate when upgrading from a version that managed auto dhcp
[01:24] <cjwatson> asac: my proposal is that your postinst is changed to only run the migrate script on upgrades, not on fresh installs; then at a *later* point in the installer I separately run the migrate script
[01:24] <asac> ok
[01:25] <cjwatson> so you only need to have a special test if the migrate script is going to do something different on fresh installs than on upgrades
[01:25] <cjwatson> not for whether it's to be called at all
[01:26] <asac> yes, thats what i understood from: "change that << to lt-nl"
[01:26] <cjwatson> asac: ok, so given that we arrange for the migrate script to be called in both cases, does it need to act differently on fresh installs than on upgrades
[01:27] <cjwatson> ?
[01:28] <asac> oh ... right ;)
[01:28] <asac> yes, just postinst is changed to not run it on fresh installs
[01:30] <asac> cjwatson: 1. use lt-nl in postinst to test whether to run script; 2. run migrate script in netcfg -> done.
[01:30] <asac> cjwatson: is that what you mean?
[01:30] <ion_> Whee, a new version of openoffice.org-voikko in the updates. Its postinst actually succeeded. :-)
[01:32] <cjwatson> asac: exactly. This is the netcfg change: http://codebrowse.launchpad.net/~ubuntu-core-dev/netcfg/ubuntu/revision/606?start_revid=605
[01:32] <Keybuk> grr, silly network
[01:32] <cjwatson> (except you need to click through to see the new finish-install script)
[01:32] <cjwatson> http://codebrowse.launchpad.net/~ubuntu-core-dev/netcfg/ubuntu/annotate/606?file_id=finishinstall-20070919112720-34axn8w2kk8li73w-1
[01:33] <asac> cjwatson: for now that would be fine ... only point is see is that i might want to do something special during install for essid/wepkey ... like discussed above
[01:33] <cjwatson> asac: ok, I'll set NETCFG=1 in that finish-install script then
[01:33] <asac> cjwatson: but actually i can do the negative test. e.g. postinst script sets a special environment ... not the installer
[01:34] <asac> cjwatson: so no need to set NETCFG=1 if its not set anyway.
[01:34] <cjwatson> well, I just committed it ...
[01:34] <asac> ;)
[01:34] <cjwatson> but I can revert it if you prefer it that way :)
[01:34] <cjwatson> TBH I think you should probably do the ESSID/WEPkey thing on upgrade too
[01:34] <cjwatson> it seems obviously useful
[01:35] <asac> cjwatson: why? people that have that atm, don't use network manager for those interfaces
[01:35] <asac> just migrating them to network-manager would be a regression imo
[01:36] <cjwatson> hmm, ok
[01:36] <cjwatson> I'll just upload this with NETCFG=1 in; if you prefer to set an environment variable in your postinst, please just do that and let me know
[01:40] <asac> ok thanks.
[01:43] <asac> cjwatson: fyi, when this is done, we can finally fix bug 128316 in a clean fashion
[01:43] <ubotu> Launchpad bug 128316 in network-manager "n-m should not tear down interfaces during shutdown" [Medium,Triaged]  https://launchpad.net/bugs/128316
[01:43] <ogra> pitti, ping
[01:44] <pitti> hey ogra
[01:51] <tkamppeter> pitti, I have made new CUPS packages now where I went back to my workaround. See bug 140887
[01:51] <ubotu> Launchpad bug 140887 in cupsys "system-config-printer.py crashed with ValueError in reinit()" [High,In progress]  https://launchpad.net/bugs/140887
[01:52] <pitti> tkamppeter: oh, if you think that's the best solution?
[01:52] <seb128> pitti: http://people.ubuntu.com/~seb128/libthai.debdiff http://people.ubuntu.com/~seb128/libthai.diffstat http://people.ubuntu.com/~seb128/libthai.ChangeLog
[01:52] <pitti> tkamppeter: certainly good for me as a workaround, but Tim's plan sounds better to me in the long run
[01:53] <seb128> pitti: the package has already migrated to testing in Debian
[01:53] <seb128> pitti: and pango wants 0.1.9
[01:53] <cjwatson> asac: all my bits of it are uploaded now
[01:54] <tkamppeter> pitti, yes, assuming that Mike's change is really correct. And independent of this Tim's changes will stabilize systemn-config-printer against possible inconsistencies in CUPS.
[01:54] <pitti> tkamppeter: I agree, it's a good enough workaround for gutsy
[01:54] <ogra> mvo, so what do you need from me ?
[01:55] <mvo> ogra: the .xsession-erros output of it if you try to start compiz
[01:55] <mvo> ogra: compiz --replace
[01:55] <mvo> ogra: the output of this
[01:55] <mvo> ogra: but its not urgent, you can do it after the meeting of course
[01:55] <pitti> seb128: looks quite intrusive, but since saying 'no' is not really an option, we should rather test it before; ArneGoetje, asac, you use libthai in your projects, right?
[01:55] <tkamppeter> pitti, my new CUPS package also contains another fix. The HP LaserJet 2600n was not discovered. As it is a cheapo color laser it does not support SNMP, only mDNS/DNS-SD/Zeroconf.
[01:57] <tkamppeter> I have written a little Perl program which discovers such printers scanning via DNS-SD. I have added it to my new cupsys packages and now the CLJ 2600n gets discovered perfectly.
[01:57] <ogra> mvo, http://paste.ubuntu-nl.org/37898/
[01:57] <pitti> tkamppeter: just keep in mind that we are in feature freeze :)
[01:58] <mvo> ogra: could you please also pastebin the output of lspci?
[01:58] <mvo> ogra: that looks good btw :)
[01:58] <pitti> seb128: Debian PTS looks reasonable though, so please go ahead and sync it
[01:58] <mvo> ogra: and lspci -n
[01:59] <seb128> pitti: thanks
[01:59] <tkamppeter> The backend should not break anything, as it is only run when creating a new queue, not when printing. And the old SNMP backend I did not disable, just in case there is an old printer with SNMP but without DNS-SD.
[01:59] <ogra> mvo, http://paste.ubuntu-nl.org/37899/
[01:59] <ogra> mvo, it behaves like it should
[02:00] <mvo> ogra: thanks a lot, that makes me happy
[02:00] <ogra> me too :)
[02:01] <ogra> i only saw it misbehaving very recently before one of the last upgrades ... beyond that i didnt have probs for the whole release :)
[02:01] <asac> pitti: seb128 whats the case with libthai?
[02:01] <pitti> asac: we need the new version from unstable/testing
[02:01] <pitti> asac: 0.1.9
[02:02] <pitti> asac: so it would be nice if you could give this a test (you needed it for tbird AFAIR?)
[02:02] <seb128> asac: libpango 1.18.2 requires 0.1.9 and we have 0.1.8 at the moment
[02:02] <asac> pitti: ffox needs it
[02:02] <TomaszD> bryce, remember me yesterday with the sis driver issue? I noticed that there was the same *exact* issue when moving from... wait for it... hoary to breezy!
[02:03] <TomaszD> http://ubuntuforums.org/showthread.php?t=95771
[02:03] <asac> seb128: ok ... i will take a look
[02:03] <pitti> asac: thanks
[02:04] <seb128> asac: thanks
[02:04] <pitti> tkamppeter: ok for the replacement of the patch, but dnssd is too much of a new feature for my taste
[02:04] <TomaszD> "SiS DRI driver expected DDX version 0-0.8.x but got version 0.7.0", now it's 0.7.1
[02:04] <pitti> tkamppeter: I'm happy to commit the change to Debian, though, so that it doesn't get lost
[02:04] <TomaszD> I really wish this would work ...
[02:10] <bigon> hi, are build attempts with the Chroot problem status tried again later?
[02:12] <mvo> pitti: I think I have a patch for the gnome-terminal problem thing, if you can still reproduce it, I would be happy if you could test a new pacakge
[02:13] <pitti> mvo: off for lunch, but I'm happy to give it a try when I'm back *hug*
[02:14] <tkamppeter_> pitti, so take only the DNS-SD stuff into Debian, and leave the patch rollback alone. For DNS-SD discovery in Ubuntu Gutsy it is too late. Let's see whether Mike has a solution in 6 months (CUPS 1.4?) and if not, how my scripts is working in all the other distros which will come out and put all this experience in. Perhaps we will even have to look into a hybrid "network" backend taking together all network scanning methods to avoid du
[02:14] <tkamppeter_> plicate entries in the output.
[02:15] <pitti> tkamppeter_: sounds like a plan
[02:15] <tkamppeter_> pitti, Tim Waugh has already done the fix on the s-c-p side and I will package this now. For Ubuntu consider cupsys-1.3.2-1ubuntu1 as final-
[02:16] <asac> pitti: seb128: appears to be compatible as a drop-in replacement (ABI) ... will do a rebuild of firefox with the new -dev to be sure; but looks good so far.
[02:17] <seb128> asac: cool, thanks
[02:18] <asac> seb128: ok ... its building ... so after lunch i will have results ;)
[02:18] <Kopfgeldjaeger> hi
[02:27] <cjwatson> bigon: they need to be given back by hand, but typically buildd admins sort this out on their own, yes
[02:27] <bigon> cjwatson: thx
[02:29] <TomaszD> bryce, I'm currently compiling the git version of the driver and we'll see how it goes from there
[02:31] <cjwatson> argh libgcrypt pain and suffering
[02:32] <TomaszD> bryce, current git version of xorg-video-sis fixes the issue, I have working DRI in gutsy now
[02:32] <TomaszD> sweet
[03:11] <asac> seb128: pitti: libthai 0.1.9 looks good here
[03:13] <bddebian> Heya
[03:13] <bddebian> seb128: Thanks for the syncs
[03:15] <Lure> mjg59: what is missing for brightness in kde? I could look into it, but do not have HW for testing
[03:16] <bddebian> seb128: For toshutils though, I was just trying to get the FTBFS fixed without bringing over a new version this close to release.  Do I need to bring over the new version? Thx
[03:29] <soren> cjwatson: My perl-fu is weak. Could you take a peek at http://people.ubuntu.com/~soren/multiline-ext-desc.diff ?
[03:32] <siretart> cjwatson: ok, I've just had a phone conversation with daniel about a potential casper/live-initramfs merge
[03:33] <siretart> cjwatson: he is willing to cooperate, but is strongly suggesting to merge casper into live-initramfs, becuase of several issues
[03:33] <cjwatson> soren: looks fine to me
[03:34] <cjwatson> siretart: we can't possibly do that for gutsy, and I still object to the spurious renaming
[03:34] <siretart> cjwatson: I'll investigate his arguments and will compare the two packages
[03:34] <siretart> cjwatson: then we can consider which way we want to go for hardy
[03:34] <cjwatson> ok
[03:34] <siretart> cjwatson: of course, I'm talking about hardy, not gutsy
[03:35] <soren> soren: Alright, I'll assume that's what we'll do then in the tasks I'm finalising right now. Will you roll the patch into the next tasksel upload? (Don't bother with it just yet, as I hope to add some tasks later today.)
[03:35] <siretart> .oO( soren talking to himself? )
[03:35] <soren> arh, fsck
[03:35] <siretart> ;)
[03:36] <soren> cjwatson: Alright, I'll assume that's what we'll do then in the tasks I'm finalising right now. Will you roll the patch into the next tasksel upload? (Don't bother with it just yet, as I hope to add some tasks later today.)
[03:36] <soren> siretart: Too much stuff going on :)
[03:40] <cjwatson> soren: sure, will do
[03:40] <soren> cjwatson: rock, thanks.
[03:40] <cjwatson> just testing it
[03:44] <pitti> asac: libthai> thanks for testing
[03:46] <superm1_> mvo, during an update-manager -d -c, have you considered exporting a noninteractive debian frontend?
[03:47] <superm1_> on a fresh feisty install, its appearing like several items wanted input in the "terminal" part of the dist-upgrade window
[03:47] <soren> cjwatson: I've used it here: http://codebrowse.launchpad.net/~shawarma/ubuntu-seeds/ubuntu.gutsy.server-tasks/annotate/soren%40ubuntu.com-20070919131654-yctbc5zs972cc1eu?file_id=postgresqlserver-20070919110454-e6hey8hrnau5s8g0-1
[03:48] <soren> loggerhead url's for the lose :(
[03:48] <cjwatson> you can replace the ids by revision numbers by hand and it still works
[03:48] <cjwatson> the problem is that it doesn't use them by default
[03:50] <Kano_ubuntu> hi, just found a simple workaround for my X700 SE card. the ati driver does not work for it, but you could add a line to use radeon directly
[03:52] <soren> cjwatson: oic
[03:52] <Kano_ubuntu> 01:00.0 0300: 1002:5e4f
[03:52] <Kano_ubuntu> ATI Technologies Inc RV410 [Radeon X700
[03:52] <Kano_ubuntu> the pci.ids is not fully correct, it is X700 SE
[03:53] <Kano_ubuntu>         10025e4f        video   Server:XFree86(ati)     RV410 [Radeon X700] 
[03:53] <Kano_ubuntu> change this to radeon please
[03:53] <Kano_ubuntu> discover1-data, pci.lst
[03:58] <tormod> Kano_ubuntu: that would be a bug in the ati driver
[03:58] <mvo> superm1_: no, I export gnome as the frontend
[03:58] <superm1_> mvo, that's odd, i'll have to file a bug.  it was for sure coming as a dialog frontend
[03:59] <mvo> superm1_: ok, please do that I would like to investigate that
[04:00] <superm1_> mvo, one more thing: i noticed that the app i was looking for from that previous email to you (mythbuntu-control-centre) got added to the list in g-a-i, but so did an unwanted app (ubiquity-frontend-mythbuntu).  how can I get that off the list in there?
[04:00] <hunger> Would you please keep tracker a recommends? It gets started in addition to strigi in a kubuntu system with ubuntu-desktop added and running two search thingies is really expensive.
[04:00] <mvo> superm1_: that was a oversight by me, I can fix that now
[04:00] <hunger> And I can no longer just uninstall it:-(
[04:01] <superm1_> mvo, okay cool thanks.  i'm going to let this dist-upgrade finish with the dialog issue before filing a bug.  any particular logs you're looking for?
[04:01] <Kano> btw. why dont you switch to aufs? your last daily amd64 live from kubuntu is fully broken
[04:02] <mvo> superm1_: generally everything that is in /var/log/dist-upgrade/*
[04:02] <mvo> superm1_: thanks, ubiquity-mythbuntu.desktop  removed now
[04:06] <hunger> Hmmm... why are all the libs I updated since yesterday all of a sudden marked as manually installed in aptitude?
[04:15] <tkamppeter> pitti, I have now packaged Tim's fixes for bug 140887
[04:15] <ubotu> Launchpad bug 140887 in system-config-printer "system-config-printer.py crashed with ValueError in reinit()" [High,Fix committed]  https://launchpad.net/bugs/140887
[04:19] <asac> pitti: found some time to verify ifupdown?
[04:19] <pitti> tkamppeter: ah, great! I'll look at it and sponsor it
[04:19] <pitti> asac: oh, right; will do
[04:23] <cjwatson> soren: committed your tasksel patch
[04:50] <pitti> Keybuk: system -> printing should offer you one
[04:50] <pitti> Keybuk: alternatively, cups' web interface
[04:50] <Keybuk> it doesn't
[04:50] <pitti> uh?
[04:50] <Keybuk> in fact, system -> printing doesn't exist
[04:50] <pitti> well, system -> admin -> printing
[04:50] <ogra> it exists for me
[04:50] <pitti> aka system-config-printer
[04:50] <Keybuk> that gives me a tree on the left with three options
[04:50] <ogra> but i dont get any details about my tw configured printers
[04:50] <Keybuk>   Server Settings
[04:51] <ogra> *two
[04:51] <Keybuk>   + Local Printers
[04:51] <Keybuk>     WorkCentre-7245
[04:51] <Keybuk> on the right is a pane with "Basic Server Settings"
[04:51] <Keybuk> clicking on anything in the tree on the left seems to have no effect
[04:51] <ogra> right, same here
[04:51] <pitti> Keybuk: right; the printer should be selected by default, and there should be a "test page" button
[04:51] <Keybuk> nope
[04:51] <Keybuk> server settings was selected by default
[04:51] <ogra> not here either
[04:52] <ogra> navigating the treeview has no effect at all
[04:52] <pitti> tkamppeter: ^ hmm
[04:52] <ogra> should anything in the server settings be checked ?
[04:53] <ogra> i have not one checkmark
[04:53] <pitti> it works just fine here
[04:53] <pitti> ogra: not by default
[04:53] <ogra> ok
[04:53] <pitti> ogra: but I enabled sharing/browsing here
[04:54] <ogra> ugh
[04:54] <ogra> now it crashed
[04:54] <pitti> http://people.ubuntu.com/~pitti/tmp/scp.png
[04:55] <pitti> Keybuk: ^ that's what I see when I start s-c-p
[04:55] <ogra> if i check the first option "Zeige freigegebene Drucker anderer systeme"
[04:55] <ogra> is that browsing ?
[04:55] <ogra> if i check that and click apply it crashes
[04:55] <pitti> ogra: right
[04:55] <pitti> well, I have the very latest cups/s-c-p/python-cups crack here
[04:55] <Keybuk> pitti: that's not what I see
[04:56] <pitti> the previous s-c-p just crashes right on start, due to a slightly changed behaviour of cups
[04:56] <tkamppeter> pitti, what do you mean with your last message to me?
[04:56] <ogra> i updated my system when mvo asked for compiz tests
[04:56] <pitti> tkamppeter: have you ever heard this behaviour?
[04:56] <pitti> ogra, Keybuk: do you have cups 1.3.0 or 1.3.2?
[04:56] <Keybuk> pitti: http://people.ubuntu.com/~scott/scp.png
[04:56] <ogra> (two hours ago according to the backlog)
[04:56] <Keybuk> pitti: 1.3.2
[04:57] <tkamppeter> pitti, I will test this one.
[04:57] <ogra> ah, this time it didnt crash
[04:57] <seb128> asac: thanks
[04:57] <seb128> bddebian: what?
[04:58] <Keybuk> pitti: 1.3.0 got upgraded today?
[04:58] <pitti> Keybuk: can you please test with the new python-cups and s-c-p on http://people.ubuntu.com/~pitti/tmp/ ?
[04:58] <ogra> hmm, trying to disable it crashes again
[04:58] <Keybuk> I haven't logged out or rebooted since then
[04:58] <pitti> Keybuk: cups was upgraded yesterday
[04:58] <tkamppeter> And note that there is the Printing Summit next week, so stop finding bugs in s-c-p until the end of this week. I will also meet Mike Sweet on the Summit, and hope this does not make CUPS-1.3.2-debugging Summit out of it.
[04:58] <davmor2> pitti: Keybuk ogra I just logged on to say it is broke completely here s-c-p
[04:58] <pitti> Keybuk: no need to reboot or logout
[04:58] <Keybuk> pitti: I mean to say that I *got* the update today
[04:59] <pitti> davmor2: known, bug 140887
[04:59] <ubotu> Launchpad bug 140887 in system-config-printer "system-config-printer.py crashed with ValueError in reinit()" [High,Fix released]  https://launchpad.net/bugs/140887
[04:59] <pitti> davmor2: (I assume)
[04:59] <Keybuk> pitti: I cannot test the python-cups at that URL
[04:59] <pitti> Keybuk: hm, i386?
[04:59] <Keybuk> aye
[05:00] <pitti> http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/python-cups/binary/python-cups_1.9.27-0ubuntu1_i386.deb
[05:00] <davmor2> pitti: different traceback but certainly sounds the same
[05:00] <davmor2> I'm on 64bit
[05:00] <pitti> davmor2: feel free to test above packages, too
[05:01] <pitti> tkamppeter: stop finding bugs> we'll do our best :)
[05:01] <ogra> pitti, works
[05:01] <pitti> ogra: \o/
[05:01] <ogra> :)
[05:01] <pitti> tkamppeter: anyway, if we find something small, s-c-p is not exactly hard code; I think I can manage
[05:01] <ogra> i still find the UI scary though
[05:02] <davmor2> pitti: is there a 64 bit version there too?
[05:02] <Keybuk> pitti: new packages worked
[05:02] <pitti> davmor2: http://people.ubuntu.com/~pitti/tmp/
[05:02] <Keybuk> though the default selection was still Server Settings
[05:02] <Keybuk> but clicking on the printer gave me a useful right pane this time
[05:02] <pitti> davmor2: python-cups_1.9.27-0ubuntu1_amd64.deb  and system-config-printer_0.7.75+svn1557-0ubuntu1_all.deb
[05:03] <pitti> Keybuk: hm, can you please file a bug about the default selection, with your /etc/cups/printers.conf? it's supposed to work
[05:04] <Keybuk> pitti: ok
[05:04] <davmor2> pitti: That's working :)
[05:04] <pitti> awesome
[05:06] <tkamppeter> pitti, for me the newest s-c-p and your cupsys 1.3.2-1ubuntu1 work perfectly together. My default printer (on a remote server, broadcasted to my local box) is selected and clicking on a printer I get immediately the printer properties on the right. I also do not get crashes when changing the server settings.
[05:07] <pitti> tkamppeter: likewise here
[05:11] <davmor2> pitti: My wife's feisty machine still can't locate the printer.  I've checked on my gutsy laptop too and it's not showing up there either
[05:13] <pitti> davmor2: but you did enable the sharing/
[05:13] <pitti> ?
[05:13] <davmor2> Yes do I need to re-enable it the tick boxes are all ticked
[05:14] <pitti> davmor2: all? really? that's a bit much
[05:15] <davmor2> just switch some of them off :) I was just making sure that I covered all the bases
[05:15] <pitti> asac: ifupdown> quite a complex change; it isn't enough to hardwire the '100' default somewhere?
[05:15] <pitti> davmor2: the first two should be enabled, the others are crack
[05:16] <asac> pitti: its not that complex ... it just honours if you have metric manually configured
[05:16] <davmor2> pitti: done
[05:16] <pitti> asac: right, but the code for that should already be there surely?
[05:16] <pitti> asac: after all, 'metric 500' should work with the current version?
[05:16] <asac> pitti: unfortunately not
[05:16] <asac> pitti: there is no default mechanism
[05:17] <asac> pitti: in code ... so i tried to implement that as unintrusive as possible (e.g. going through all set options and see if a metric is configured)
[05:17] <davmor2> pitti right got it now :)#
[05:17] <asac> pitti: what do you mean with metric 500?
[05:18] <pitti> asac: I mean, there is certainly code to set the metric if it is explicitly set, and I assume it uses a variable; can't we just pre-set this variable?
[05:18] <pitti> asac: metric 500> just an example of a nonstandard setting in /e/n/i
[05:18] <davmor2> pitti: will that updated package make it in before beta testing starts?
[05:18] <pitti> davmor2: sure, I uploaded it 30 minutes ago
[05:18] <davmor2> pitti: cool
[05:19] <asac> pitti: the option parsing is generated by perl ... we would need to extend that in a general fashion (e.g. allow to configure default options) ... which is currently not implemente
[05:19] <pitti> asac: ooh, I see
[05:19] <asac> pitti: so in the end the change i do is less-intrusive imo
[05:19] <pitti> asac: right, just trying to understand the approach; it looks good, I was just curious whether it's possible to simplify it
[05:20] <pitti> dhclient3 [[-e IF_METRIC=%metric%] ] 
[05:20] <asac> pitti: but granted, i am not a web guru ... but it parses the perl parses option description
[05:20] <pitti> asac: what does that syntax do?
[05:20] <asac> from what i understand it will omit that block if %metric% is not set
[05:20] <davmor2> pitti: what exactly does the refresh button do?  I had to restart cups from cli for it to register.
[05:20] <asac> pitti: same as for the static variant
[05:21] <pitti> davmor2: not 100% sure, but I guess it re-queries cups for new printers and manually changed options
[05:22] <davmor2> pitti: right so it doesn't refresh the server then?  It is a little odd it being next to the server button then :(
[05:22] <pitti> davmor2: no, it just reloads the values in s-c-p from the server; "apply changes" reloads the server
[05:24] <davmor2> pitti: in that case it isn't as soon as I did sudo /etc/init.d/cups restart the printer showed up on the laptops until then nothing.
[05:25] <davmor2> pitti: or does it update the server without restarting it?
[05:26] <pitti> davmor2: it does, it uses the equivalent of /etc/init.d/cupsys reload
[05:26] <pitti> davmor2: NB that printers are only broadcast out every 30 seconds, so it might take a while
[05:26] <bryce> tormod: I ran across a similar issue yesterday - the problem was blamed on mixing packages from Ubuntu with ones locally compiled
[05:28] <pitti> 0.0.0.0         10.28.130.1     0.0.0.0         UG    100    0        0 eth0
[05:28] <pitti> asac: ^ yay
[05:28] <asac> pitti: you have a wireless in proximity?
[05:28] <pitti> asac: not on my desktop
[05:28] <asac> so you can test how well it takes over your route, while you are still connected?
[05:28] <asac> oh ok
[05:28] <pitti> asac: let me build this stuff on my laptop and try it there with wifi+eth
[05:28] <asac> yep
[05:29] <tkamppeter> pitti, the "Apply" button on the server settings page sends an IPP request for the option changes to the CUPS server, the same as the cupsctl command does. The scheduler changes the options in the config files then and re-initializes itself.
[05:29] <pitti> asac: unfortunately I can't get wired and wireless at the same place :/ (signal is too weak at my desk)
[05:29] <asac> pitti: is obvious ... for now keep some bogus option or static for eth ... so its not nm managed ;)
[05:29] <asac> pitti: hmm
[05:29] <tkamppeter> The "Refresh" button simply re-reads the server options and the list of available printers.
[05:29] <pitti> asac: ah, right, and set a gateway there
[05:30] <asac> pitti: you can use iface eth0 inet dhcp
[05:30] <asac>    bogusoption
[05:30] <asac> as well
[05:31] <tkamppeter> To be allowed to use the "cupsctl" command or to change the server settings with s-c-p it is enough to be in the "lpadmin" group.
[05:31] <davmor2> pitti: Right okay thanks again
[05:32] <pitti> asac: 'metric 499' in /e/n/i also works fine here
[05:32] <seb128> pitti: so we can sync libthai, right?
[05:32] <pitti> seb128: yep
[05:32] <seb128> thanks
[05:33] <asac> seb128: for me its ok
[05:33] <seb128> asac: thanks for testing
[05:35] <tormod> bryce, what issue? sorry I lost the context
[05:35] <adnarim> hi
[05:36] <bryce> tormod: ah sorry, that was for TomaszD; bad tab complete.  nevermind.
[05:36] <adnarim> is any Ubuntu-developer here? especially kernel division?
[05:36] <jdong> adnarim: #ubuntu-kernel
[05:37] <adnarim> thx jdong
[05:37] <tormod> bryce, anyway, we continued the discussion with TomaszD on #ubuntu-x
[05:42] <cjwatson> pitti: what's happening with libterm-readkey-perl? it's in universe and blocking apparmor-utils installation
[05:42] <cjwatson> pitti: but the source is in main so it looks like it may be in universe by accident?
[05:42] <adnarim> noone in ubuntu-kernel is answering so I hope somene here can or at least point me to a place where I can find the answer to my problem:
[05:42] <adnarim>  I searched the whole net but couldn't find any answers about this. Is the Ubuntu-kernel not supporting the syscall macros? they should be in unistd.h but are not there !?!
[05:42] <iwj> cjwatson: I decided I should test that ldconfig wrapper script change (even though it's trivial) so I have to wait for a glibc build.
[05:44] <adnarim> they are important for accessing syscalls within C like described here: http://www.ibm.com/developerworks/linux/library/l-system-calls/
[05:44] <pitti> cjwatson: it's supposed to be in main; change-override.py might have fooled me again
[05:44] <pitti> cjwatson: moved again *hopes for the best*
[05:44] <pitti> cjwatson: hm, it was in main on hppa and lpia; yay
[05:46] <seb128> pitti: is change-override buggy?
[05:46] <pitti> seb128: sometimes I have that feeling...
[05:48] <seb128> pitti: looks like it doesn't change outdated versions, no?
[05:48] <seb128> libgbf-1-dev |    0.1.2-4 | gutsy/universe | hppa
[05:48] <seb128> libgbf-1-dev |    0.1.7-1 | gutsy/universe | amd64, i386, ia64, lpia, powerpc, sparc
[05:48] <pitti> seb128: that might be it, yes
[05:49] <Hobbsee> pitti: was it you doing the archive run?
[05:49] <pitti> Hobbsee: define archive run?
[05:50] <Hobbsee> pitti: sync requests
[05:50] <pitti> Hobbsee: seb
[05:50] <Hobbsee> pitti: right, thanks.
[05:51] <Hobbsee> seb128: when it's a sponsored upload, are you intending to put the name of the approver, rather than the name of the sync filer, in the maintainer field of the changes mail?
[05:52] <seb128> Hobbsee: we had a discussion about that this morning, I usually put the name of whoever I feel should be responsive for issues on the upload
[05:53] <seb128> I usually put the approver
[05:53] <Hobbsee> seb128: oh right.  i'm presuming you're going to write a mail to u-d & u-motu to actually tell us this.
[05:54] <Hobbsee> seb128: imo, the person who has done the work should be listed as the maintainer - who is the one who has done the merge request, etc.
[05:54] <seb128> Hobbsee: I'm not going to mail anybody
[05:55] <Hobbsee> right then.
[05:55] <seb128> Hobbsee: I'm not sure what is your issue
[05:55] <seb128> sorry if I picked your name for a sync of a bug you approved
[05:56] <Hobbsee> seb128: oh, i just thought it was misdirected credit - they who does the work should surely get the credit.
[05:57] <Hobbsee> seb128: and also, if i'm now responsible for any issues of the upload - for everything that i happen to sponsor...that's sticking a whole bunch of extra load on me, or anyone else going thru the sponsorship queue.
[05:57] <seb128> Hobbsee: right
[05:57] <Hobbsee> as in, i still dont know the codebase in particular, beyond knowing tha tthere's nothing of crack in the diff
[05:58] <Hobbsee> as for bug fixing from the upload - i would have thought that was still the responsibility of the diffmaker - even though the uploader has some responsibility.
[05:58] <Hobbsee> but the primary point of contact for anything wrong?  i think that's a bit much
[05:59] <seb128> Hobbsee: well, the uploader information is mainly administrative detail at the moment
[05:59] <pitti> asac: works just fine here
[05:59] <Hobbsee> (particularly as the primary point of contact will usually be mailed about anything wrong with the package, not just the diff they uploaded)
[05:59] <seb128> Hobbsee: the mail on -changes is from Ubuntu Installer
[05:59] <geser> who gets the mail for failed builds?
[05:59] <asac> pitti: thanks
[05:59] <Hobbsee> seb128: true, but it mirrors to LP, iirc
[05:59] <seb128> Hobbsee: and that doesn't subscribe you to the package or anything
[05:59] <Hobbsee> geser: i got one for failed upload
[05:59] <asac> lets keep our eyes open during freeze then
[05:59] <asac> will upload
[05:59] <pitti> asac: bug updated
[06:00] <Hobbsee> seb128: true - but it does give the expectation that you are.
[06:00] <seb128> geser, Hobbsee: the question is also to know if some random people come, goes through sponsoring, get its upload processed and vanish, who should be responsive?
[06:00] <Hobbsee> imo, at least.
[06:00] <Hobbsee> seb128: that's a good question.
[06:01] <seb128> geser, Hobbsee: ideally whoever did the work, but the approver sponsor is also somewhat responsive since he authorized the upload
[06:01] <Hobbsee> seb128: i suspect it becomes a case of "the uploader becomes responsible if they who did the work does not respond"
[06:01] <seb128> right
[06:01] <asac> pitti: gratias
[06:01] <Hobbsee> seb128: and beyond that, the MOTU team in general, as it's team packaging.
[06:02] <Hobbsee> for telepathy*, it becomes the telepathy team, i suspec.t
[06:02] <pitti> asac: great work! let's just hope it doesn't introduce strange regressions
[06:02] <seb128> Hobbsee: I would be happy enough to use whoever did the work if he's known (core dev, motu, etc) or the approver if that's a new comer
[06:02] <seb128> Hobbsee: would that work?
[06:02] <Hobbsee> seb128: conversely, we're not debian.  packages are broken, and we dont have resources to fix them all - so there will be some level of breakage.  of course, us adding to it is not good.
[06:03] <Hobbsee> seb128: sec.
[06:03] <seb128> Hobbsee: well that's for freezes, whoever grant a freeze breakage approval should know about consequences
[06:03] <seb128> Hobbsee: no?
[06:04] <Hobbsee> seb128: no, that doesnt work.
[06:04] <geser> yeah, motu-uvf will be responsible then for all broken uvfe
[06:04] <Hobbsee> seb128: one of the ways we look for contributions to packaging is looking at hte person's +packaging page on LP.  if you put me as the maintainer, they go to mine, not the newcommers
[06:05] <Hobbsee> seb128: which is...inconvenient, to say the least.
[06:05] <Hobbsee> seb128: i know there's a back issue here - who's responsible, if no one has particular time to do everything they want, plus fix any and all regressions for anything they sponsor.
[06:05] <asac> pitti: pressing-thumbs ;)
[06:06] <Hobbsee> seb128: MOTU is almost all volunteer run, and such.
[06:06] <seb128> Hobbsee: ok, I'm busy enough with GNOME 2.20 for now, let's have that rant^Wconversation later
[06:06] <Hobbsee> seb128: ah, thought you'd got that built.  good luck with it :)
[06:06] <seb128> beta freeze is tomorrow and I've work to get done
[06:06] <seb128> Hobbsee: almost but I've to chase some build issue, ask for some retries, etc
[06:07] <Hobbsee> seb128: right.  do you want me to find another archive admin to deal with some sync-script breakage?
[06:07] <seb128> Hobbsee: you have a fair point about the syncs, I'll use the person who did the work for the next ones
[06:07] <Hobbsee> seb128: thanks.
[06:08] <seb128> Hobbsee: that's not a breakage, looks like other archive admin usually use whoever did the work
[06:08] <geser> btw is there some list of packages FTBFS on LP (or somewhere else)? looking on the ftbfs in the buildd's history isn't feasible
[06:08] <Hobbsee> Rejected:
[06:08] <Hobbsee> Unable to find libtelepathy_0.0.57.orig.tar.gz in upload or distribution.
[06:08] <Hobbsee> Files specified in DSC are broken or missing, skipping package unpack verification.
[06:08] <cjwatson> it should do ...
[06:08] <Hobbsee> seb128: ^ looks like sync script borkage?
[06:08] <seb128> Hobbsee: looks like
[06:08] <Hobbsee> (tentative guess, as i've only heard references to the script in question)
[06:13] <tkamppeter> pitti, I have a little Apport problem. See bug 135321
[06:13] <ubotu> Launchpad bug 135321 in system-config-printer "system-config-printer.py crashed with SIGSEGV" [Medium,Confirmed]  https://launchpad.net/bugs/135321
[06:14] <tkamppeter> There is no useful info and asking for a retrace does not work. Tim Waugh is asking whether there are things like debuginfo packages (would need especially one for python-cups.
[06:18] <pitti> tkamppeter: yes, we have debug symbol pacakges
[06:20] <tkamppeter> How to proceed to get more info to solve bug 135321?
[06:20] <ubotu> Launchpad bug 135321 in system-config-printer "system-config-printer.py crashed with SIGSEGV" [Medium,Confirmed]  https://launchpad.net/bugs/135321
[06:29] <mathiaz> keescook: About bug 140626, are you running x86-64 ?
[06:29] <ubotu> Launchpad bug 140626 in apparmor "apparmor Segmentation fault" [Undecided,Incomplete]  https://launchpad.net/bugs/140626
[06:29] <pitti> tkamppeter: I'll have a look later, busy ATM
[06:32] <keescook> mathiaz: I do run x86-64, yeah.  I haven't seen that.  However, I haven't rebooted in a while.  I can try it.
[06:37] <geser> mathiaz: I've tried to reproduce the bug but no success (apparmor and apparmor-profiles 2.1+993-0ubuntu1)
[06:37] <geser> doesn't segfault here (amd64)
[06:39] <mathiaz> geser: thanks.
[06:54] <ion_> mvo: In compiz-manager, theres 8086:29a12 listed in the PCI IDs. Thats probably a typo.
[06:54] <mvo> ion_: yes, thanks! we just noticed
[06:55] <ion_> mvo: Btw, does it look like hw-connected isnt going to be used? I noticed that the mention of it at the compiz sprint wiki page had been moved under resolved issues.
[07:00] <mjg59> ogra: Freetype
[07:00] <ogra> yeah, indeed
[07:01] <ion_> ogra: Some paper says its the right way to render fonts, so seems like thats what we have to tolerate from now on.
[07:01] <ogra> eek
[07:01] <ogra> really ?
[07:02] <ion_> ogra: I was told the API change is so big that it isnt possible to offer both rendering methods as settings.
[07:02] <ogra> gah
[07:02] <ogra> but tat looks crappy on LCDs
[07:02] <ogra> *that
[07:03] <ogra> at leats on the two i have tried it yet
[07:03] <ion_> ogra: Yes, it does. Horizontal lines arent hinted to pixel boundaries, so there are faint subpixel lines around the lines which cause blurriness.
[07:03] <mvo> ion_: we now use the compiz-manager script that is part of upstream git and upstream does not (currently) want to depend on hw-connected as its not yet widely available
[07:03] <ion_> ogra: And a paper says its the right way, so thats what we have to obey.
[07:04] <ion_> mvo: Alright.
[07:04] <ogra> ion_, well, it worked before ....
[07:05] <ion_> ogra: It did, but a paper says what it did before is wrong, thus we have to obey.
[07:05] <ogra> tel that to my optician :P
[07:05] <ogra> what it did before worked ...
[07:05] <ogra> what it does now doesnt
[07:06] <ogra> and given the amount of LCD displays out there thats a very bad move imho
[07:08] <ion_> mvo: Im fine with any decision, but id still like to point out that since hw-connected is a small C program and its dependencies are installed in every Linux box, it wouldnt be a big impact even to include it in the compiz source for now.
[07:08] <cjwatson> may I suggest talking to the people who made the change rather than speculating?
[07:09] <\sh> hmm...X is not coming up again...
[07:11] <ion_> mvo: (The only hard dependency is libc. It only needs /sbin/modinfo if the -m parameter is used.)
[07:13] <\sh> oh god...something is really strange here...
[07:14] <Ng> firefox does some interesting things in the new font order, selecting text in a multi-line edit box makes the glyphs change shape, so the lines move around
[07:14] <\sh> anyone saw not correct installed binaries, who are segfaulting, and then after apt-get --reinstall install <package> it works again?
[07:14] <bryce> sh, X issues?
[07:14] <\sh> bryce, I don't think so..but it looks like that something happens to my XFS fs...it's sometimes not installing the whole package, or just some bits of a binary...
[07:15] <ion_> XFS... nuff said. ;-)
[07:15] <\sh> those binaries segfaulting now, and --reinstalling helps
[07:15] <\sh> ion_, well, I'm running XFS on several hundreds servers, and nothing went wrong
[07:16] <\sh> I wonder if it's the laptop itself (broken disk or ram or cpu or whatever can change the data on disk or in memory)
[07:18] <jdong> \sh: have you ever had a hard hang or unclean shutdown on the filesystem?
[07:19] <jdong> that is like a 75% death sentence to data integrity on XFS... :(
[07:19] <ion_> Yeah, as long as the hardware works *perfectly*, XFS is fine.
[07:19] <Skif> A co-worker pointed this out to me: there are several GUI packages that deliver menu files, but not .desktop files.  This is confusing, because sometimes when you install a package, it shows up in your menus, and other times, it doesn't, and there is no obvious (to the user) reason why.
[07:19] <jdong> ion_: that's my epxerience too
[07:20] <\sh> jdong, yepp...and until today...I'm happy that nothing disappeared or was broken...I had all the time problems with reiser3 or ext3...
[07:20] <Skif> I have written a quick script that greps through Contents.gz, and tells which packages have menu files, but not desktop files.  Is this appropriate for a mass bug filing?
[07:20] <dholbach> pitti: can you wave through gutsy-wallpapers?
[07:20] <Skif> So far I have 403 packages for main, and 2909 total (including main, multiverse, universe)
[07:20] <\sh> Skif, file the bugs with the .desktop file attached :)
[07:20] <jdong> \sh: I'm 100% confident that one of those unclean dismounts is to blame.... There's a reason I do weekly xfsdumps on my XFS drive...
[07:20] <Skif> \sh for < 100, I might. :)
[07:21] <dholbach> pitti: I'll make ubuntu-artwork depends on it
[07:21] <pitti> dholbach: looking
[07:21] <Skif> \sh: seriously, you know of an automatic converter?  I'd be happy to.
[07:21] <\sh> jdong, oh you mean now? no...the laptop is all the time shutdowned correctly
[07:22] <LaserJock> Skif: please feel free to send a list to the ubuntu-devel mailing list
[07:22] <Skif> LaserJock: Sure, no problem.
[07:24] <\sh> Skif, much better when you can divide the list for all sections (main, universe,multiverse) and send it in CC to ubuntu-motu@l.u.c
[07:24] <Skif> \sh: that's pretty trivial, thanks to grep.
[07:24] <mhb> hi folks, sorry to bother with translation-related matters ... does anyone know how to integrate fresh d-i translations into ubiquity so one can test the fresh translations?
[07:25] <Skif> I don't have to be subscribed to ubuntu-motu, to CC: it, do I?
[07:27] <LaserJock> Skif: I think it'll just get moderated
[07:27] <Skif> Ah, no problem, then.
[07:27] <LaserJock> Skif: but you want to be subscribed to ubuntu-motu anyway ;-)
[07:27] <Skif> LJ: Right, because disk space on my mailhost is free. :)
[07:38] <pitti> dholbach: gutsy-wallpapers> warty-final-ubuntu.png ??
[07:39] <dholbach> pitti: don't ask
[07:39] <dholbach> pitti: that's the filename we have in there for ages
[07:39] <dholbach> to 'automatically update to the next wallpapers vision'
[07:39] <ogra> pitti, rest ?
[07:39] <dholbach> I'll leave that for somebody else to fix in next release
[07:39] <ogra> mine is still pretty busy :)
[07:40] <pitti> dholbach: ok, NEWed
[07:40] <dholbach> pitti: thanks a lot
[07:41] <dholbach> pitti: ubuntu-artwork is uploaded which will depends on it
[07:41] <pitti> dholbach: please poke someone else for binary NEW (or wait until tomorrow morning), since I am about to leave
[07:41] <dholbach> pitti: I'll leave soon too
[07:41] <dholbach> pitti: thanks for doing that
[07:42] <dholbach> hehe
[08:05] <charlieS> 67307 - USB devices don't work for non-local users since edgy. Has anyone seen this? :)
[08:47] <seb128> infinity, lamont, Mithrandir: could you give a buildd retry to gedit on amd64?
[08:48] <lamont> seb128: on it
[08:48] <seb128> lamont: thanks
[08:50] <lamont> seb128: and I retried sparc/ia64 as well, just for giggles.
[08:51] <seb128> lamont: thanks
[09:07] <elmo> is it known that some gnome tools are still searching for esd?
[09:10] <seb128> elmo: they should display a message about it once and that's about it
[09:10] <torkel> elmo: I think they use esd if it is installed, but fallback to aplay
[09:11] <elmo> seb128: ok
[09:14] <Halcy0n> What would be the most sane way for me to generate a nightly package?  I'd like the version to contain a date string, but I don't like the idea of having to put them all into the changelog.  Is there any way I can override it, or fake it?
[09:17] <seb128> lamont: can you also give a retry to gnome-applets on sparc powerpc hppa?
[09:18] <seb128> lamont: same for gtkhtml3.14
[09:20] <tormod> Halcy0n: maybe take a look at "man dch"
[09:21] <lamont> gnome-applets, gtkhtml3.14 done
[09:21] <lamont> (hppa sparc ppc lpia)
[10:32] <cjwatson> lamont: could you take 137837, please?
[10:32] <cjwatson> bug 137837
[10:32] <ubotu> Launchpad bug 137837 in expect "expect ftbfs on ia64" [High,Confirmed]  https://launchpad.net/bugs/137837
[10:32] <lamont> cjwatson: yeah
[10:32] <cjwatson> thanks, assigned to you
[10:33] <seb128> lamont: could you give a buildd retry to gnome-system-monitor epiphany-browser epiphany-extensions on amd64 (and the other arches that didn't build maybe)?
[10:33] <lamont> seb128: ok.
[10:33] <seb128> thanks
[10:33] <lamont> dear launchpad.  could I please have something less than 2 buttons to reschedule a single build/arch?  kthxbye>?
[10:33] <lamont> s/>?$/./
[10:34] <lamont> dear expect, there are include files to define libc functions for a reason.
[10:35] <lamont> cjwatson: it'll require iteration - I'll hack on it tonight
[10:36] <lamont> seb128: I'm not bothering to score these high, so they might take a bit before they build... OTOH, most archs are rather idle mostly
[10:36] <slangasek> cjwatson: I talked to pitti about 137837 earlier, he said it also shouldn't be milestoned because it's ia64, is that right?
[10:37] <cjwatson> slangasek: it shouldn't have Canonical resources assigned to it, at any rate, and it's top of the list for deferral
[10:37] <seb128> lamont: ok
[10:38] <lamont> slangasek: if it's milestoned, I'm more likely to notice, especially since cjwatson will thwap me with it
[10:38] <cjwatson> slangasek: it may certainly make sense to unmilestone it in order to make your list manageable
[10:38] <slangasek> ok :)
[10:38] <slangasek> lamont: well, my plan had been to thwap you with it and then un-milestone it :)
[10:38] <cjwatson> :-)
[10:39] <lamont> that'll work.  please at least assign them to me when you unmilestone them. thwapping optional
[10:39] <lamont> seb128: gsm amd64, eb amd64/sparc
[10:39] <cjwatson> bug 131209 - shit, I should finish that
[10:39] <ubotu> Launchpad bug 131209 in casper "kubuntu verify CD just boots live system" [Medium,Triaged]  https://launchpad.net/bugs/131209
[10:40] <lamont> seb128: and ee amd64/sparc
[10:41] <seb128> lamont: thanks
[11:15] <elmo> sweet
[11:15] <elmo> my /var/lib/dpkg/status is corrupt
[11:15] <ion_> How about status-old?
[11:16] <jdong> that's always a joy, elmo :)
[11:16] <elmo> that's fine
[11:17] <elmo> well, as in , doesn't have this particular corruption
[11:18] <lamont> cjwatson: 137837 - I suppose you care if I want to go to -13.1 after I NMU debian, right?  (it's -11 in gutsy)
[11:18] <lamont> s/cjwatson/slangasek/
[11:19] <lamont> heh.  -12 and -13 are ijw patches
[11:21] <lamont> cool.  -13 == -11ubuntu1
[11:25] <slangasek> lamont: ok, then feel free to bump the version number when uploading :)
[11:26] <mathiaz> kylem: did you get a chance to merge the apparmor patch for the audit messages ?
[11:26] <lamont> slangasek: heh
[11:26] <kylem> mathiaz, no, oops.
[11:28] <mathiaz> kylem: will there be a new upload of l-u-m before beta ?
[11:28] <kylem> unlikely before beta.
[11:28] <kylem> but check with Ben.
[11:29] <mathiaz> kylem: ok. Thanks.
[11:29] <kylem> lum is short to build, i imagine it's not too much trouble to respin.
[11:30] <mathiaz> kylem: the current situation with apparmor is that the tools used to parse the audit messages don't work correctly.
[11:30] <mathiaz> kylem: so the profiles cannot be updated with the tools.
[11:31] <mathiaz> kylem: but it doesn't break apparmor itself.
[11:33] <elmo> so, my /var/lib/dpkg/status lost it's ^@ corruption on reboot.  s2ram FTW \o/
[11:33] <mjg59> elmo: What sata driver?
[11:34] <ion_> elmo: XFS?
[11:34] <elmo> mjg59: looks like ahci?
[11:34] <Halcy0n> Anyone here that has access to the upload queue?
[11:34] <elmo> ion_: ha  ha ha.  no.
[11:34] <mjg59> Hrm.
[11:35] <jdong> 17:37 < elmo> ion_: ha  ha ha.  no.
[11:35] <jdong> best response I've heard
[11:37] <elmo> mjg59: it was like 2-4 bytes in one file too, very specific
[11:37] <elmo> (well, in one file, that I know about ...)
[11:50] <elmo> mjg59: (also, I'd just done a dist-upgrade prior to sleeping, so it may relatively reproducible)
[12:19] <cjwatson> Halcy0n: what's up?
[12:23] <IntuitiveNipple> Any ETA on fixing the unionfs BUG - I've not even been able to install Gutsy for testing on the Vaio notebooks as a result... time is pressing :)
[12:23] <cjwatson> IntuitiveNipple: no ETA, sorry, only my word that it's the highest priority
[12:23] <cjwatson> a kernel developer is working on it (AFAIK) full-time
[12:24] <IntuitiveNipple> lol no problems!
[12:24] <IntuitiveNipple> cjwatson: btw I'm the "TJ" that reported the GID issue... fully debugged and explained in Bug #141067
[12:24] <ubotu> Launchpad bug 141067 in shadow "Group GIDs 1-99 not shown in Groups Settings dialog" [Undecided,New]  https://launchpad.net/bugs/141067
[12:25] <cjwatson> IntuitiveNipple: yep, I recognised you - thanks
[12:26] <cjwatson> IntuitiveNipple: I commented - I think the shadow task ought to be rejected
[12:26] <IntuitiveNipple> ahh ok... thanks
[12:26] <IntuitiveNipple> I put that up to make clear the two points of contact at issue
[12:26] <cjwatson> Not replacing deleted config file /etc/papersize
[12:26] <cjwatson> hah, that explains a lot
[12:27] <ion_> Is there a VCS branch for linux-restricted-modules?
[12:27] <IntuitiveNipple> So I guess I should open a task against system-tools-backend then