[12:22] <wasabi__> shell script pros: Looking for a trick to make a script process lines from a command as they come in. easy enough with a while read line pipe or otherwise. I want a timeout though. If the while loop doesn't exit within 30 seconds, I want it to break out.
[12:23] <wasabi__> Various ideas have popped up: fork sleep 30 && kill $$. That sucks. ;)
[12:32] <xav> wasabi__: man read maybe
[12:35] <xav> wasabi__: help read rather, but finally I don't think it'll help you, sorry
[12:38] <Jones_> The one thing that doesn't work on my system is video. Something wrong relating to libxv1 I believe. flash plugin works with youtube etc. But videos don't work. mplayer/vlc/totem all included. If I do, mplayer -fs -vo x11 -zoom; it plays. But I can't just click on a video and play it, totem just shows a black screen.(the audio works fine on all players)
[12:39] <Jones_> Are there any bugs relating to this for edgy? I couldn't find any...I wanted to make sure before I file a bug report.
[12:39] <Jones_> I'm not really sure what to say on the bug report, just that video doesn't work I guess? I don't know exactly what the problem is.
[12:39] <xav> what does xvinfo say?
[12:39] <Jones_> I did apt-get build-dep libxv1; apt-get source libxv1; and I recompiled it from orig, but still doesn't work.
[12:40] <xav> what error do you get when usin mplayer?
[12:40] <Jones_> xav: http://www.rafb.net/paste/results/Uknu2r25.html
[12:41] <Jones_> http://www.rafb.net/paste/results/F7g6AU40.html (mplayer error)
[12:41] <Jones_> I tried to play $HOME/Examples/Experience\ ubuntu.ogg
[12:42] <Jones_> Doesn't work in Totem/vlc/mplayer.
[12:43] <xav> did you try xv with another video?
[12:43] <Jones_> yes, I tried an mpeg-1 video, and xvid(ogm) video.
[12:44] <grexk> morning everyone
[12:48] <treitter> how does the kernel versioning work?  (ie, in linux-image-2.6.15-26.46, what are the numbers "26" and "46" for, exactly?)
[12:48] <xav> in which place is it morning?
[12:48] <Fujitsu> xav, Australia.
[12:48] <Jones_> I'm thinking it might be because I dist-upgraded from dapper to edgy a couple days ago. And I should have just done a clean edgy install. So maybe I'll format when knot3 comes on in a few days, and if the problem is still there I'll file a bug.
[12:49] <grexk> xav, Philippines
[12:49] <xav> ah yep
[12:49] <xav> ok :)
[12:51] <xav> Jones_: that would be odd
[12:51] <jdong> treitter: 2.6.15 is the upstream kernel version number, 26 is the Ubuntu ABI, 46 is the number of revisions ubuntu has made since the 2.6.15 package
[12:51] <treitter> jdong: great! Thanks
[12:51] <jdong> treitter: 26 is changed every time a kernel change is made that would break binary compatability
[12:51] <Jones_> xav: Well I can't figure it out. I don't know what is wrong with libxv1
[12:52] <treitter> jdong: is this documented somewhere? I had no luck finding it on my own
[12:52] <jdong> treitter: I'm not sure if it's documented somewhere; good question
[12:52] <jdong> treitter: http://kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git
[12:52] <xav> Jones_: are you sure the problem is with libxv1 ?
[12:52] <jdong> that's a live browser of what goes into Dapper's kernel
[12:53] <jdong> treitter: in reality it's A LOT more than just a 2.6.15 kernel ;)
[12:53] <Jones_> xav: no
[12:57] <treitter> jdong: so I hear :)
[12:57] <treitter> jdong: do the numbers start at 1?  (ie, was the first 2.6.15 kernel 2.6.15-1.1?)
[12:58] <jdong> treitter: yep.
[12:58] <treitter> jdong: cool, thanks
[12:59] <treitter> jdong: is the git repo you pointed me to documentation, or an actual kernel?
[12:59] <treitter> jdong: it'd have to be worth it to install git to check it out :)
[12:59] <jdong> treitter: it's the git branch; I find the changelog really informative
[12:59] <jdong> treitter: there is documentation on the wiki for checking out git branches of ubuntu kernels
[01:00] <Jones_> xav: What else could it be do you think?
[01:05] <xav> Jones_: the driver
[01:06] <Jones_> I'll reboot into vesa and see how that does.
[01:08] <xav> Jones_: I didn't think that worked, but I've no clue
[01:10] <Jones_> xav: hmm, yea things work in vesa
[01:10] <Jones_> They're kind of slow/choppy when I play video and resize things
[01:10] <Jones_> I wonder what is wrong with x.org's ati driver
[01:12] <xav> ah, didn't know xv was possible with vesa
[01:25] <roico> is the common customization spec going to be implemented till edgy?
[01:34] <Keybuk> roico: I suspect you mean "by edgy" :p
[01:34] <roico> well yeah, english is not my native, sorry... =\
[01:34] <Keybuk> oh, meh, whoever registered that can't spell customisations :p
[01:35] <Keybuk> by the status, it would appear that it will be at least partially implemented for edgy
[01:36] <roico> didn't we pass the feature freeze?
[01:36] <Keybuk> yes, and it hasn't been marked as deferred
[01:36] <roico> whats deferred?
[01:36] <HrdwrBoB> put away until later
[01:37] <Keybuk> though it wasn't mentioned in the FF meeting
[01:37] <d1sc0rd> anybody using ndiswrapper on edgy in here
[01:38] <Burgwork> Keybuk, licensing of tcl files. Know anything abou tthat?
[01:38] <Keybuk> Burgwork: uhh?
[01:38] <Keybuk> -v
[01:39] <Burgwork> Keybuk, I have some code here that I need to attach the GPL to
[01:39] <Keybuk> err?
[01:39] <Keybuk> -v
[01:39] <Keybuk> -v
[01:39] <Keybuk> -v
[01:39] <Keybuk> :p
[01:39] <sivang> re
[01:40] <Keybuk> I'd quite like to attach the GPL to the Windows source code ... doesn't mean I can <g>
[01:40] <sivang> Keybuk: heh
[01:40] <Burgwork> right, this is code  my company wrote
[01:40] <Keybuk> ok, so they own it
[01:41] <Burgwork> my new job as "Open Source Community Manager" at Userful means I get to cleanup the code to get it read to actually have code to build a community around
[01:41] <sivang> Keybuk: http://www.reactos.org/xhtml/en/index.html
[01:41] <Burgwork> sivang, indded
[01:42] <Burgwork> so I have a bunch of .tcl files. Do I need to append the "this is under the GPL" to all of them?
[01:42] <Keybuk> ok...
[01:42] <Keybuk> have you read the GPL? :p
[01:42] <Burgwork> yes, and this http://www.gnu.org/licenses/gpl-howto.html
[01:42] <Jones_> Burgwork: join the debian-legal mailing list
[01:42] <Burgwork> Jones_, I value my eyes and brain
[01:43] <sivang> Burgwork: quite nice to see something like that going on.
[01:43] <Keybuk> ok
[01:43] <Burgwork> sivang, trying hard to make sure it is code thrown over the wall
[01:43] <Keybuk> Burgwork: that kinda tells you the answer :p
[01:43] <Burgwork> Keybuk, in this instance, each tcl file is considered source?
[01:45] <Keybuk> I wouldsay so
[01:45] <Burgwork> ok, thank you
[01:45] <Burgwork> let me buy you a drink at the next develops summit
[01:47] <sivang> Burgwork: ;-)
[02:11] <jdong_> ack, is dbus misbehaving with permissions for anyone else?
[02:12] <bddebian> Heya
[02:37] <Seveas> mjg59, ping
[02:40] <mjg59> Seveas: Hi
[02:42] <Seveas> mjg59, would it be possible to add one more field to struct usplash_theme? I'd want a char* name in there, which can be used by a frontend I want to develop for edgy+1 but like to test on edgy systems -- I'll provide patches for the 4 existing themes
[02:42] <mjg59> Seveas: Wurgh.
[02:43] <Seveas> mjg59, an often asked question is how to switch between themes, so I thought: who not make it easy and learn some gtk along the way ;)
[02:45] <mjg59> Heh.
[02:45] <mjg59> Ok
[02:45] <mjg59> Put it in the themes first
[02:45] <mjg59> Actually, no, that's difficult
[02:46] <Seveas> yeah
[02:46] <mjg59> Put it in the .h but don't use it in the client
[02:47] <mjg59> That way it won't care about the format of the themes changing
[02:47] <mjg59> Providing the char* is at the end
[04:34] <bluefoxicy> Can someone tell me when makedepend and imake will be gone?
[04:35] <bluefoxicy> they've been obsolete for the past couple months but removing them removes damn near everything on my system
[04:36] <Fujitsu> They'll be gone when the packages which depend on them have been fixed.
[04:37] <bluefoxicy> how vague
[04:37] <mjg59> If there are dependencies on them, that implies that they're not obsolete
[04:37] <bluefoxicy> anyway I have to test this new via driver and see if it kills my system, i'll reboot too.
[04:37] <bluefoxicy> mjg59:  they don't seem to be in the repos, says synaptic
[04:39] <wasabi> What bluefoxicy says is accurate. They're sitting on my system too.
[04:39] <bluefoxicy> driver check.
[04:40] <mjg59> Oh
[04:40] <mjg59> Because you still have transitional packages installed
[04:41] <mjg59> apt is poor at dealing with that situation
[04:41] <Fujitsu> It does that.
[04:42] <wasabi> Which are the transitional packages?
[04:43] <bluefoxicy> Works.
[04:43] <wasabi> oh crap. everything that touches my disk is now getting IO errors.
[04:43] <wasabi> uh oh!
[04:44] <rodarvus> wasabi, 'dpkg --list | grep transitional'
[04:44] <wasabi> wasabi@kyoto:~$ ls
[04:44] <wasabi> bash: /bin/ls: Input/output error
[04:44] <wasabi> Yeah I probably won't be here long.
[04:44] <wasabi> Heh gtk icons are disappearing all over
[04:45] <wasabi> bbl. =(
[04:46] <Fujitsu> :(
[04:46] <Fujitsu> Good luck!
[04:48] <wasabi> somehow it is now fixed. =/ that's scarey
[04:59] <mjg59> https://launchpad.net/bugs/59997 - this has to win some sort of prize for the most amusingly misdirected bug
[04:59] <Ubugtu> Malone bug 59997 in xen-3.0 "[edgy]  xen fails to run" [Untriaged,Unconfirmed]  
[04:59] <mjg59> Oh, that's interesting
[04:59] <mjg59> I just got mail telling me it had been filed against usplash
[04:59] <ajmitch> mjg59: I reassigned already
[05:00] <ajmitch> since he also filed bug 59998 which I closed as duplicate
[05:00] <Ubugtu> Malone bug 59998 in xen-3.0 "[edgy]  xen fails to run" [Untriaged,Rejected]  http://launchpad.net/bugs/59998
[05:00] <mjg59> ajmitch: I kiss you
[05:04] <wasabi> oh crap. my system is doing this io error stuff over and over again
[05:04] <wasabi> might be new kernel
[05:08] <jamadagni> hello is mithrandir here?
[05:12] <mjg59> jamadagni: It's 05:12 his time
[05:14] <Hobbsee> mjg59: freeze cant be in place yet then :P
[05:16] <Hobbsee> which is good.  i want to test this fix to see that it really works, before getting a sponsor.
[05:17] <wasabi> Heh. Corruptex XFS. Big time.
[05:18] <HrdwrBoB> wasabi: I did that
[05:18] <wasabi> Oh?
[05:18] <HrdwrBoB> 32->64 bit OS change, destroyed it
[05:19] <wasabi> I thought XFS was arch neutral
[05:19] <HrdwrBoB> allegedly
[05:19] <wasabi> ahh fuck. I just repaired it in a 64bit livecd.
[05:19] <HrdwrBoB> well, it is
[05:19] <wasabi> I have probably just destroyed it
[05:19] <HrdwrBoB> wasabi: haha
[05:19] <HrdwrBoB> yes
[05:19] <HrdwrBoB> I'm sorry, but.. yes
[05:19] <HrdwrBoB> if you have a dirty log
[05:19] <wasabi> god damnit.
[05:19] <HrdwrBoB> and you use it in a 64bit sytem
[05:19] <HrdwrBoB> it eats it
[05:19] <wasabi> it just moved a shit ton of inodes to lost+found
[05:19] <HrdwrBoB> yes, and even those are screwed
[05:20] <wasabi> Well, I'll be mightily disappointed if so
[05:20] <HrdwrBoB> well, that's exactly what happened to me
[05:20] <HrdwrBoB> and the data was all gone
[05:21] <HrdwrBoB> there's data THERE
[05:21] <HrdwrBoB> but it's not the same data you had before
[05:21] <wasabi> Probably going to mount empty, with nothing except a lost+found
[05:21] <HrdwrBoB> yep
[05:22] <HrdwrBoB> there's lots of stuff in lost and found
[05:22] <HrdwrBoB> but files aren't the same data
[05:22] <HrdwrBoB> this is fixed in the latest XFS releases
[05:22] <bluefoxicy> right
[05:22] <bluefoxicy> don't use glxinfo.
[05:22] <HrdwrBoB> I lost 1.4tb of data
[05:23] <wasabi> how can i run xfs_repair twice and have it fix things both times.
[05:23] <wasabi> bah
[05:24] <HrdwrBoB> wasabi: I know you want to make sure for yourself
[05:24] <HrdwrBoB> but your data is toast
[05:25] <HrdwrBoB> restore from backups (you have backups right?)
[05:25] <wasabi> I keep my Big FIles on a seperate partition.
[05:25] <wasabi> Which, hopefully, isn't fucked up.
[05:25] <HrdwrBoB> unless you mounted it, it should be fine
[05:25] <wasabi> There was some important stuff on /. We'll see.
[05:26] <wasabi> My other partition is 800GB. No way to back it up.
[05:26] <HrdwrBoB> yeah, that's my problem
[05:27] <HrdwrBoB> this is why i now use LVM and make a snapshot daily
[05:27] <wasabi> I'm getting close to giving up on XFS.
[05:27] <johanbr> Lots of people seem to have trouble with XFS, like Martin Krafft: http://blog.madduck.net/geek/2006.08.09-through-with-xfs
[05:27] <HrdwrBoB> prevents against accidental deletion and fs screwups
[05:27] <wasabi> I like it a lot, but it's screwed up in various ways 3 times now.
[05:28] <HrdwrBoB> XFS is a very large speed win for my large array with large files, so I stick with it, however for regular usage, it's not worth the hassle
[05:28] <wasabi> Well, the LVM idea sounds good. Do a LVM snapshot + xfs_repair once a day... if xfs_repair finds ANYTHING, copy new files off and revert.
[05:29] <HrdwrBoB> well, a snapshot isn't going to be clean unless you unmount, snapshot, remount
[05:29] <wasabi> Yeah. That's fine, for my big data drive.
[05:29] <wasabi> All movies.
[05:31] <wasabi> Hmm. THere are files left.
[05:32] <HrdwrBoB> try playing them, they will be jumpy and corrupted
[05:49] <wasabi> So... any suggestions on a better / fs? Guess I could just go back to ext3 like everybody else.
[05:50] <HrdwrBoB> I use XFS still on my large array
[05:50] <HrdwrBoB> however I just use ext3 on most things
[05:50] <HrdwrBoB> it Just Works
[05:54] <wasabi> Well, since I'm reformatting, I mine as well install a 64 bit OS this time.
[06:03] <Hobbsee> Kamion: ping?
[06:17] <RnB-Tunes> http://www.RnB-Tunes.dl.am << new RnB, Hip Hop, Dancehall Tracks!!! free Download... CHECK IT!!!!
[06:31] <mneptok> shake 'em on down!
[07:22] <fabbione> morning guys
[07:23] <mneptok> hey sexy.
[07:30] <Hobbsee> hi fabbione 
[07:30] <fabbione> hi Hobbsee 
[07:37] <Kagou> good morning
[07:45] <zyga> morning
[08:33] <Mithrandir> Riddell: there seems to be some qt4 uninstallability issues in the kubuntu world today, but they don't seem to affect -desktop installability.  Just a heads-up.
[08:59] <pitti> Good morning
[08:59] <Burgundavia> morning pitti, marilize
[09:00] <mneptok> Burgundavia: encountered your name earlier when looking through open GNOME Foundation tickets :)
[09:01] <Burgundavia> mneptok: cool. If you process it quickly I will buy you alcohol in Boston
[09:02] <HiddenWolf> pitti: wasn't bug-buddy supposed to be disabled by apport?
[09:02] <mneptok> Burgundavia: i'm not on the Membership Committee
[09:03] <mneptok> (sorry)
[09:03] <pitti> HiddenWolf: no, until we have proper debug symbols, seb128 wants b-b to be enabled by default
[09:03] <Burgundavia> mneptok: oh, too bad
[09:04] <Kagou> good morning
[09:04] <Burgundavia> pitti: can apport back into bug-buddy by default? It seems insane to me to maintain a seperate UI
[09:04] <HiddenWolf> pitti: ah. that bug that I asked about yesterday was bugbuddy then. :)
[09:04] <pitti> Burgundavia: how do you mean?
[09:05] <pitti> Burgundavia: in the long term we want apport only, but for that we need the possibility to produce good backtraces (to win something over b-b) and easy upstream bug forwarding
[09:06] <Burgundavia> pitti: it me, carrying deltas from upstream is a little nuts, unless the work justifies it. Would it not be easier to modify bug-buddy and thus have less code of our own laying around?
[09:06] <whiprush> as an aside, a ubuntu-dbg thing could be nice. I've had three things crash on me this week and I have no decent data to send back
[09:06] <whiprush> er, maybe more an ubuntu-desktop-dbg
[09:08] <Burgundavia> it seems that every distro builds it delta with upstream slowly, without a concerted effort to truly reduce it
[09:11] <Mithrandir> Burgundavia: (re /EdgyEft/Knot3): thanks; I didn't know it was a -marketing thing now; nobody told me. :-)
[09:12] <Burgundavia> Mithrandir: no worries. Marketing didn't really exist last cycle and given that nixternal and myself did the Knot2 and we are active in both teams, it really didn't matter
[09:32] <pitti> aah, hal 0.5.8
[09:33] <Treenaks> pitti: what's so cool about it? :)
[09:33] <pygi> morning all
[09:34] <pitti> Treenaks: I didn't yet wade through the detailled changelog, since it's not for edgy anyway
[09:34] <pitti> Treenaks: but it's nice that there finally is a new stable release
[09:34] <freeflying|away> pitti: hi
[09:35] <pitti> hi freeflying|away 
[09:36] <Burgundavia> pitti: PolicyKit, crack or not?
[09:36] <mneptok> "when he was waking up beside the bed he found clumps of hair. the last paulene wouldn't cooperate. she wasn't what you'd call living, really. but she was still awake. johnny hit and run paulene!"
[09:38] <pitti> Burgundavia: optional in this release
[09:39] <Treenaks> mneptok: do we want to know what kind of stories you're reading?
[09:39] <dholbach> good morning
[09:39] <Burgundavia> pitti:  and +1?
[09:39] <Burgundavia> morning dholbach
[09:40] <dholbach> hi Burgundavia
[09:41] <mneptok> Treenaks: listening to seminal American punk band X
[09:42] <pygi_> morning dholbach 
[09:43] <pitti> Burgundavia: +1 to what?
[09:43] <freeflying|away> pitti: I'm trying reproduce the bug you mentioned
[09:43] <dholbach> hi pygi_
[09:43] <Burgundavia> pitti: sorry, edgy+1, what are the plans?
[09:44] <pitti> Burgundavia: oh, no concrete plans so far, but I guess we'll need PolicyKit anyway for gnome-system-tools
[09:44] <pitti> Burgundavia: so, I'll take a look at it
[09:44] <Burgundavia> right
[09:44] <Burgundavia> pitti: ok, just wondering
[09:44] <pitti> right now the g-s-t implementation is less than ideal
[09:55] <Kamion> Hobbsee: yes?
[09:56] <Hobbsee> Kamion: why are you requiring people from ubuntu-dev to approve sync requests, when the package was last synced from unstable anyway?
[09:56] <Hobbsee> Kamion: ie, there are no ubuntu changes, due to the version number?
[09:56] <Kamion> Hobbsee: syncs aren't always harmless - I'd like somebody to check for major compatibility problems, etc.
[09:56] <Kamion> even if there are no Ubuntu changes to discard
[09:56] <Hobbsee> oh, and i'm seeing why you're requiring lists of changes - i've seen some very crazy stuff try to be put through.
[09:56] <Hobbsee> Kamion: right, okay
[09:57] <Kamion> Hobbsee: sometimes I do the check myself and don't bother asking, if it's trivial and I'm not too overworked
[09:57] <Hobbsee> Kamion: yeah, fair enough
[09:57] <Kamion> dies?
[09:57] <Kamion> playing nethack? :)
[09:57] <Hobbsee> who's Matthew Revell  on irc?
[09:57] <Hobbsee> Hi Sarah,
[09:57] <Hobbsee> Any chance I could interview you, for the Fridge, about your new Kubuntu role? 
[09:57] <Hobbsee> i just read my email :P
[09:58] <imbrandon> Hobbsee, he is mattrevelle ( in #ubuntu-fridge and of LR fame ;P )
[09:58] <Hobbsee> imbrandon: ahh right...
[09:59] <Hobbsee> imbrandon: i think i finished building on your machine for a little bit :P
[09:59] <imbrandon> heh
[09:59] <imbrandon> i've still got it chugging away ;)
[10:00] <Hobbsee> imbrandon: if you dont want me to build on your machine, it would be nice if you'd warn me when, and for how long, you know :P
[10:00] <Hobbsee> imbrandon: rather than just having a go at me in -motu
[10:01] <imbrandon> hahaha okies ;)
[10:01] <imbrandon> was no big deal, i was realy just teasin you, sorry if you dident take it that way ;)
[10:01] <imbrandon> Hobbsee, ^^
[10:02] <Hobbsee> ok
[10:03] <infinity> Kamion: A give-back of d-i failed the same way, BTW.  Something sketchy in udeb publishing or something?
[10:04] <Mithrandir> Kamion: console-setup still asks questions for me.
[10:04] <Mithrandir> Kamion: do you want a DEBCONF_DEBUG=developer trace?
[10:05] <Kamion> Mithrandir: yes please.
[10:06] <Kamion> infinity: hmm, will investigate, thanks
[10:06] <Mithrandir> Kamion, added info to https://launchpad.net/distros/ubuntu/+source/console-setup/+bug/59883
[10:06] <Ubugtu> Malone bug 59883 in console-setup "Asks questions on installation" [Medium,Confirmed]  
[10:07] <Kamion> Mithrandir: what I want to know is how come console-setup/layout isn't seen
[10:07] <Kamion> Mithrandir: as in, isn't already marked as seen
[10:07] <Kamion> since you obviously have /etc/default/console-setup there already
[10:08] <Kamion> Mithrandir: ... oh. I see the problem. There are some places where we bypass the layout question but don't mark it as seen ...
[10:08] <Kamion> ok, I'll sort this out later
[10:08] <Mithrandir> ok
[10:09] <Mithrandir> I'll keep the system "broken" for now so we can try reproducing with a later version
[10:09] <Mithrandir> this is post-knot material anyway
[10:09] <doko> good morning
[10:39] <Kamion> infinity: could you check whether libconsole is already installed in those chroots, please?
[10:39] <Kamion> infinity: (re debian-installer build)
[10:39] <Kamion> infinity: and if not, why not? :) it's in base ...
[10:42] <Mithrandir> Kamion: is this d-i build something we'd want for knot, by any chance?
[10:43] <Kamion> Mithrandir: considering bug 59938, yes
[10:43] <Ubugtu> Malone bug 59938 in debian-installer "edgy alternate installer: No kernel modules were found" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59938
[10:43] <Kamion> the word "mandatory" comes to mind
[10:43] <Mithrandir> Kamion: indeed.
[10:44] <Mithrandir> just alternate, or do you need live too?
[10:44] <Kamion> it builds fine in my debootstrap+build-essential chroot ...
[10:44] <fabbione> Mithrandir: when is knot-3 planned?
[10:44] <Kamion> Mithrandir: d-i doesn't block the live CDs, if that's what you mean
[10:44] <Mithrandir> fabbione: Thursday
[10:45] <fabbione> Mithrandir: ok thanks.
[10:45] <fabbione> actually
[10:45] <fabbione> i also need to rsync edgy images
[11:17] <xav> what was the md bug someone mentionned yesterday ?
[11:30] <pitti> hey sabdfl 
[11:31] <mneptok> sabdfl: http://www.cnn.com/TECH/
[11:32] <pygi> pitti, you have a sec for me'
[11:32] <pygi> ?
[11:32] <pitti> pygi: hi; sure
[11:33] <pygi> pitti, any chance libburn, libisofs, and cdrskin can be packaged & put into universe before the freeze if we release them on September, 26?
[11:35] <pitti> pygi: yes, if packaging doesn't take too long
[11:35] <pitti> pygi: universe freeze is Sept 28
[11:35] <pygi> pitti, well, I know :P Release was supposed to be on October, 1 but I moved it 'cause of the freeze
[11:35] <shenki> mneptok: "...local language versions would curry favor with the government."
[11:36] <pygi> pitti, I'd really like that we get it in edgy
[11:36] <mneptok> mmmm .... curry
[11:37] <pitti> pygi: that would indeed be nice
[11:38] <pygi> pitti, so we can promote it to main in edgy+1 or +2 at least ^_^
[11:40] <carlos> Riddell: hi, around?
[11:41] <Hobbsee> carlos: havent seen him around yet today
[11:41] <carlos> Hobbsee: ok, thanks
[11:44] <mneptok> uhhh
[11:46] <fschoep> Mithrandir: ping
[11:46] <Mithrandir> fschoep: pong
[11:46] <fschoep> OK, good morning
[11:46] <fschoep> Where's the Knot3 freeze at?
[11:47] <Mithrandir> ?
[11:47] <pitti> carlos: is there any chance of searching for a particular msgid in Rosetta?
[11:47] <pitti> carlos: gnome-applets has 985 strings, and I just need to fix one particular string
[11:47] <fschoep> Mithrandir: I thought you were coordinating the "freeze" of packages for Knot 3?
[11:48] <Mithrandir> fschoep: yes, but a "where" question doesn't make any kind of sense.
[11:48] <fschoep> Mithrandir: I meant to ask what the current status was - "where it's at"
[11:49] <fschoep> Mithrandir: sorry for the confusion
[11:49] <carlos> pitti: not yet, we are going to implement such feature
[11:49] <carlos> pitti: danilos will work on it
[11:49] <Mithrandir> fschoep: we're frozen and I at least am testing the live images.  You're welcome to help out.
[11:49] <pitti> carlos: or any way to display more than 10 strings?
[11:49] <Mithrandir> Riddell: you might want to start testing the kubuntu desktop images.
[11:49] <Mithrandir> ogra: you might want to start testing too
[11:50] <carlos> pitti: change batch=SIZE_YOU_WANT
[11:50] <fschoep> Mithrandir: OK, I see - testing like in downloading and running the CD?
[11:50] <carlos> pitti: but I should warn you that if you put there an high number, launchpad/rosetta will give you a timeout
[11:50] <Mithrandir> fschoep: yes.
[11:50] <fschoep> I can do that
[11:50] <fschoep> The link is probably somewhere obvious, right?
[11:51] <pitti> carlos: thanks, batch=100 seems to work fine
[11:51] <Mithrandir> fschoep: cdimage.ubuntu.com/daily-live/current
[11:52] <fschoep> I see, thanks - I'll give it a spin
[11:53] <carlos> pitti: you are welcome
[11:54] <carlos> pitti: another thing to do that is download a .po file and look for the string there
[11:54] <pitti> carlos: I did, but how does that help me?
[11:54] <pitti> carlos: you mean fixing the .po and uploading it?
[11:54] <carlos> you can find the msgid that way and later, yes, you can upload it fixed
[11:55] <carlos> is the easier workaround for that use case until the search feature is implemented
[12:00] <ogra> Mithrandir, later this evening, i have to help with a move and need to prepare stuff for my travel ...
[12:00] <Mithrandir> ogra: ok.
[12:00] <ogra> but i have made up a testing plan for the community, hopefully someone uses it :)
[12:00] <ogra> ciao ...
[12:04] <Mithrandir> Gloubiboulga: you might want to get Xubuntu testing started.  Note that we need a new alternate cd first, so just live for now.
[12:04] <Mithrandir> Kamion: how's the d-i bugfix coming along?
[12:06] <Mithrandir> dholbach: gnome-settings-daemon fails to start on the live cd because of a timeout.  I've discussed this before with Seb and I think we need to increase the timeout.
[12:08] <dholbach> Mithrandir: I need to take a look at it - I'm not aware of the problem yet.
[12:12] <Kamion> Mithrandir: need that information from infinity, really :(
[12:13] <Kamion> but looks like he's gone to bed
[12:13] <dholbach> Mithrandir: which kind of timeout was that? or do you have any stray bits of info that help me looking for the failure?
[12:14] <Kamion> oh, hmm, maybe it's a console-tools-udeb packaging bug
[12:14] <Mithrandir> dholbach: I don't have the exact message here, but it's an error which happens when gnome-settings-daemon uses too long to start.
[12:15] <Kamion> Mithrandir: ok, I understand the problem, working on it
[12:15] <Mithrandir> dholbach: actually, the problem is probably that gnome uses dbus to activate g-s-d and dbus takes too long.
[12:17] <Riddell> carlos: you pinged?
[12:17] <carlos> Riddell: hi, yes
[12:17] <carlos> Riddell: https://launchpad.net/bugs/60049
[12:17] <Ubugtu> Malone bug 60049 in kde-i18n "Import of translations for KDE's desktop-* failed" [Untriaged,Unconfirmed]  
[12:18] <carlos> Riddell: seems like upstream doesn't include the .po files with the .desktop translations because they release the .desktop files including such translations
[12:19] <carlos> Riddell: so Rosetta has 0 translations for them while upstream has most of them full translated.
[12:20] <Riddell> hmm, tricky part is how to include the desktop-*.po files in an upload
[12:22] <carlos> Riddell: either as new packages or merging two tarballs....
[12:23] <carlos> Riddell: would that be too difficult?
[12:23] <carlos> noting the version as the snapshot date
[12:23] <Riddell> carlos: not too difficult, I just have to think of the best way to do it
[12:23] <carlos> Riddell: ok
[12:23] <carlos> thanks
[12:24] <Riddell> carlos: it'll be after knot 3 anyway
[12:28] <carlos> knot 3 ?
[12:31] <Riddell> carlos: testing CD we'll be releasing now
[12:32] <carlos> ok
[12:32] <carlos> Riddell: thanks
[12:32] <Riddell> nowish
[12:32] <Mithrandir> grr.
[12:32] <Mithrandir> the launchpad-integration stuff is broken with a new-ish casper.
[12:36] <Mithrandir> hmm, this is icky.  /proc/$pid/exe points to /casper/filesystem.squashfs/$whatever rather than $whatever.
[12:44] <Riddell> Mithrandir: would you allow in some updates to ubiquity to get the kd frontend synced with the gtk frontend
[12:46] <Mithrandir> Riddell: Can you run the diffs by Colin, as he knows the code better than I do?
[12:46] <Mithrandir> Riddell: if he's happy with them, I'm ok with them too.
[12:47] <Riddell> Kamion: please look at the branch at http://kubuntu.org/~jriddell/bzr/ubiquity/ubuntu/ and merge/upload if you think it's ok
[12:48] <Kamion> ok, will do
[12:55] <dholbach> Mithrandir: I just booted into i386 live cd, no gnome-control-center breakage
[12:57] <Mithrandir> dholbach: depends on the speed of your CD ROM.
[12:57] <dholbach> hmhmmhhm
[01:00] <Kamion> Riddell: I still think you should remove the distro logo entirely; ubiquity's policy is to not require branding
[01:00] <Kamion> Riddell: anyway, I'm moving it to kde-distro-logo.png, since it's specific to the KDE frontend
[01:01] <Kamion> the rest looks fine, thanks; merged
[01:02] <Kamion> Mithrandir: there's also a change in my ubiquity branch to remove /etc/popularity-contest.conf and reconfigure popularity-contest after copying, so that everyone doesn't end up with the same popcon UUID; are you OK with that?
[01:02] <Mithrandir> Kamion: sounds sane.
[01:02] <Mithrandir> Kamion: (cleared for upload)
[01:02] <Kamion> I haven't had time to test it yet, so if you want to review the code, feel free
[01:02] <Mithrandir> the diff is in your branch?
[01:02] <Kamion> but it's pretty simple and I stuck try/except around it to try to reduce the likelihood of breakage
[01:03] <Kamion> Mithrandir: yes, r1539
[01:03] <Mithrandir> I guess that means we'll need new livefs-es. :-/
[01:04] <Mithrandir> Kamion: remind me of the URL again?  I seem to have cleaned my ~ a bit aggressively and it's not referred to in the source package
[01:07] <Kamion> Mithrandir: sure is, in debian/copyright
[01:07] <Kamion> Mithrandir: http://people.ubuntu.com/~cjwatson/bzr/ubiquity/ubuntu/
[01:08] <Mithrandir> Format <RepositoryFormat6> for http://people.ubuntu.com/~cjwatson/bzr/casper/ubiquity/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance
[01:08] <Mithrandir> JFYI
[01:09] <Mithrandir> uh
[01:09] <Mithrandir> that was casper, so much for reading urls
[01:09] <fabbione> ROFL
[01:15] <Mithrandir> Kamion: and the reconfiguration bit doesn't fall over if popcon isn't installed?
[01:16] <Kamion> Mithrandir: correct - chrex just returns false
[01:16] <Mithrandir> Kamion: ok, I'm fine with you uploading that, then
[01:28] <Kamion> Mithrandir: also fixing #60045
[01:28] <Mithrandir> bug 60045
[01:28] <Ubugtu> Malone bug 60045 in ubiquity "Installer crashed for Kubutu, daily 11.09.2006" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60045
[01:31] <Mithrandir> Kamion: sounds good
[01:37] <shawarma> Is MoM still running?
[01:38] <Kamion> Mithrandir: one mistake neither of us caught - /etc/popularity-contest.conf -> /target/etc/popularity-contest.conf :-)
[01:38] <Mithrandir> true
[01:56] <Kamion> Mithrandir: ok, all source should be uploaded now; we'll see if debian-installer builds this time round
[02:09] <pitti> infinity: ping
[02:22] <Lathiat> http://releases.ubuntu.com/ubuntu-server/ still says Release Candidate for dapper
[02:23] <imbrandon> yup and it seems 6.10 and 6.10.1 are missing from the dir listing ;)
[02:25] <jdub> how's nm on iw3945?
[02:28] <Kamion> Lathiat: updated; how's that
[02:28] <Kamion> ?
[02:28] <Kamion> imbrandon: there is no 6.10.1 (yet)
[02:28] <Kamion> nor is there a 6.10 yet of course but at least we know what that will be :)
[02:28] <pitti> Mithrandir: ok to upload a new pkgbinarymangler with two small bug fixes? (not stripping backports and manpage updates)
[02:29] <Mithrandir> pitti: any reason you can't hold it off until knot 3 is out?
[02:29] <fabbione> who is the initramfs god as of today?
[02:29] <Lathiat> Kamion: better cheers :)
[02:30] <imbrandon> err 6.06.1 Kamion, typo ;)
[02:30] <Lathiat> 'and newer'
[02:30] <Kamion> Lathiat: yes, I don't want to have to remember it later
[02:30] <Kamion> Lathiat: besides, 6.06.1 is newer than 6.06
[02:30] <Lathiat> Kamion: that was my point :)
[02:31] <Fujitsu> jdub, it's very similar to ipw2200, which works fine..
[02:33] <mjg59> jdub: Fine
[02:34] <pitti> Mithrandir: no particular one, just to not forget about it
[02:34] <mneptok> jdub: Works For Me(tm)
[02:34] <Mithrandir> pitti: we should have a delayed queue. :-P
[02:35] <rodarvus> jdub, I use nm on ipw3945 on a daily basis
[02:35] <rodarvus> works great, as mjg59 mentioned
[02:40] <jdub> thanks dudes
[02:40] <pitti> infinity: FYI, I locally modified pkgbinarymangler, pending upload until after knot freeze
[02:52] <rodarvus> Kamion, do you think it will be possible to get xserver-xorg-video-amd, xserver-xorg-input-vmmouse and xserver-xorg-video-unichrome out of NEW in time for knot 3? (I'd like to ask people to test -unichrome soon)
[02:54] <Kamion> rodarvus: oh, hmm
[02:54] <Kamion> Mithrandir: ?
[02:55] <rodarvus> they can be accepted into universe - would that affect knot 3?
[02:55] <rodarvus> -amd and -vmmouse is more for completeness sake (since they became available recently)
[02:56] <jdub> hrm!
[02:56] <rodarvus> -unichrome is an alternate driver for via boards - which in theory works a lot better for various via boards
[02:56] <jdub> so if i have auto eth1 auto eth0 in /e/n/i
[02:56] <jdub> bootup takes ages
[02:56] <jdub> but if i don't, nm won't own them
[02:57] <Kamion> rodarvus: sure, I can dump them in universe
[02:57] <rodarvus> Kamion, nice, thanks!
[02:57] <jdong> jdub: really? nm owns my cards just fine without them
[02:58] <jdub> what's an example stanza from your /e/n/i ?
[02:58] <jdong> jdong@jdong-laptop:/tmp$ cat /etc/network/interfaces 
[02:58] <jdong> auto lo
[02:58] <jdong> iface lo inet loopback
[02:58] <jdong> :)
[02:58] <jdub> not lo...
[02:58] <jdong> that's it
[02:58] <jdong> that's the whole file
[02:58] <jdub> oh right
[02:58] <jdong> I have eth0 (wired) and eth1 (wireless)
[02:58] <jdub> i can just remove them entirely
[02:58] <jdub> righto
[02:58] <jdong> yep
[02:59] <jdub> good point - thanks!
[02:59] <jdong> no prob
[03:01] <Kamion> rodarvus: source accepted, will do binaries later if Keybuk doesn't beat me to it
[03:02] <Kamion> Mithrandir: can I accept these language pack updates in NEW?
[03:02] <jdong> oh, that is freaking sweet... vmware mouse driver :)
[03:03] <rodarvus> Kamion, thanks again!
[03:03] <rodarvus> jdong, don't forget to tell us if the driver works fine ;)
[03:04] <jdong> rodarvus: trust me -- I complain pretty loudly when something doesn't work ;)
[03:04] <jdong> ask everyone here :P
[03:04] <Hobbsee> heh
[03:04] <Mithrandir> Kamion: yeah, sure
[03:05] <Kamion> oh, damn, forgot to use the no-mails option
[03:05] <Kamion> oh well, some more junk for everyone on -changes
[03:05] <Mithrandir> Kamion: also, accepting the vmware stuff into universe is totally unproblematic
[03:05] <Kamion> oh, I just thought of something
[03:06] <Kamion> we'd better include the new Ubuntu usplash, hadn't we ...
[03:06] <marseillai> hi
[03:06] <Hobbsee> Kamion: nah....that'd be overrated.
[03:06] <marseillai> is there a replacement to alsaconf ? i can't find it and i need it to configure my sound card to mke it use my new 5.1 system
[03:07] <Kamion> edubuntu-artwork-usplash - edubuntu artwork for usplash
[03:07] <Kamion> kubuntu-artwork-usplash - kubuntu artwork for usplash
[03:07] <Kamion> usplash-theme-ubuntu - Usplash theme for Ubuntu
[03:07] <Kamion> xubuntu-artwork-usplash - Xubuntu usplash image
[03:08] <Hobbsee> pathetic.  change the ubuntu one?
[03:08] <jdong> Hobbsee: lol, yep, ubuntu's fault :)
[03:08] <Hobbsee> jdong: definetly, they're such rebels!
[03:09] <mneptok> it could be that there is a failure to follow the example ;)
[03:09] <Kamion> (his package)
[03:10] <Hobbsee> Kamion: so it's time to blame Seveas this week?  oh good!
[03:10] <Seveas> blame the artwork people
[03:10] <Seveas> they shoved the task to me around 4 hours before their deadline
[03:11] <Seveas> when I was supposed to be out
[03:11] <Kamion> Mithrandir: I'm going to need to upload ubuntu-meta, I'm afraid
[03:11] <mneptok> can't i blame an international zionist conspiracy?
[03:11] <mneptok> or maybe freemasonry?
[03:11] <Kamion> Seveas: nod
[03:12] <mneptok> i know! UFOs!
[03:13] <Hobbsee> mneptok: that can be worth the next 3 weeks of blame.
[03:14] <fabbione> Kamion: if you upload ubuntu-meta, could you please make sure that we use sysvinit for sparc?
[03:14] <fabbione> Kamion: upstart is somewhat broken
[03:14] <jdub> ah, steganography - that explains why the new gdm theme has to be so ugly :-)
[03:15] <pygi> jdub, lol
[03:15] <Seveas> jdub, usplash theme is worse ;)
[03:16] <Fujitsu> The new GDM theme isn't bad.
[03:16] <Kamion> fabbione: uh, ubuntu-meta is an automatic update from the seeds. I'm not going to hack it by hand.
[03:16] <Kamion> fabbione: if you want the seeds changed, you know where they are
[03:17] <fabbione> Kamion: ok. i was hoping in a last minute hack :)
[03:17] <fabbione> Kamion: no big deal
[03:17] <fabbione> hopefully Keybuk can fix upstart
[03:17] <Kamion> does that mean you are going to change the seeds, or you aren't?
[03:17] <fabbione> no i am not.. go ahead
[03:17] <Kamion> oh, actually, it's a no-go anyway
[03:17] <Kamion> we don't have per-package priorities in the archive
[03:17] <Kamion> so I can't make it use sysvinit on one architecture and upstart on another, sorry
[03:18] <fabbione> ok
[03:18] <fabbione> i guess Scott will need to fix upstart soon
[03:18] <elmo> Kamion: erm, what?
[03:18] <elmo> Kamion: do you mean per-architecture?
[03:18] <Kamion> elmo: er, sorry, yes :-)
[03:18] <elmo> ah, right
[03:18] <Riddell> Mithrandir: we have three packages to upload for kubuntu then we're ready for knot 3.  artwork fixes in kdelibs and kubuntu-default-settings, and bug fixes in kdebase
[03:24] <Kamion> Seveas: the usplash-theme-ubuntu progress bar seems wonky, BTW; it seems to be filling up in pixel rows left-to-right and then top-to-bottom
[03:24] <Kamion> (that's the best description I can find)
[03:25] <Kamion> this is on powerpc, so it could be specific to that architecture, but everything else on powerpc is now working
[03:26] <Seveas> Kamion, works fine on x86
[03:27] <Kamion> might well be brokenness in the bogl backend then
[03:27] <Kamion> I'll try to investigate
[03:27] <Seveas> the edubuntu one is wonky, I'm almost sure that there's a palette mismatch between background an progressbar 
[03:27] <Seveas> (didn't look at the code yet, but have seen the symptoms too often :))
[03:39] <Kamion> Seveas: there doesn't seem to be any correction for bytesperpixel in usplash_put or usplash_put_part in the svga driver. Isn't that a bug?
[03:39] <Seveas> no
[03:39] <Kamion> why not?
[03:40] <Kamion> not all the SVGA modes usplash uses are one-byte-per-pixel
[03:40] <Seveas> the palette is initialized earlier on 
[03:40] <Kamion> but you're doing a memcpy ...
[03:40] <Kamion>         memcpy(part + i * width, start + i * pixmap->width, width);
[03:41] <Kamion> surely that needs to take into account that the data is longer if bytesperpixel != 1
[03:41] <Kamion> compare __svgalib_driver16_getbox which does:
[03:41] <Kamion>         __memcpy(bp, vp, w * 2);
[03:41] <Seveas> hmmmm
[03:42] <Kamion> see also vga_putbox(3)
[03:42] <Kamion>        Pixmaps are in row-major order. The source pixmap memory has the size w * h * BYTESPERPIXEL.
[03:42] <mjg59> Kamion: None of the svga modes usplash uses will be /more/ than one byte-per-pixel
[03:42] <Kamion> mjg59: that's not true
[03:42] <Kamion> I checked
[03:42] <mjg59> Uh.
[03:42] <Kamion>         { 1152, 864, 39 },
[03:42] <Mithrandir> Kamion: ubuntu-meta> ok, nothing big I hope?
[03:42] <mjg59> It's got a hard-coded list of modes it'll set, all of which are 256 colours
[03:42] <Kamion>         { 1600, 1200, 45 },
[03:42] <Kamion> those two are 2 bytes per pixel
[03:42] <mjg59> Oh, are they?
[03:43] <mjg59> Sounds like my error
[03:43] <mjg59> Sorry about that
[03:43] <Mithrandir> Riddell: feel free; it just touches Kubuntu so I'm fine with you just doing it yourself.
[03:43] <Riddell> Mithrandir: thanks
[03:43] <pygi> sivang, poke? :)
[03:43] <Kamion> er, unless I'm miscounting, one moment
[03:43] <Hobbsee> Mithrandir: is that the rationale of "if we kill our own cd's, it's our fault?"
[03:43] <mjg59> Kamion: Hm. 45 is a 256 colour format.
[03:43] <Mithrandir> Hobbsee: "if you break the kubuntu cds, you get to keep both halves", yes.
[03:44] <mjg59> So is 39
[03:44] <mjg59> (see /usr/include/vga.h)
[03:44] <Hobbsee> Mithrandir: hehe.  right
[03:44] <Kamion> mjg59: oh, sorry, I just can't count evidently
[03:44] <Kamion> yes, you're right. I could have sworn I'd double-checked that
[03:44] <mjg59> Ok, that makes me feel better :)
[03:44] <mjg59> That was a deliberate decision - vesa slows down once you get above 256 colours
[03:44] <Kamion> yeah
[03:45] <Kamion> I do think this is where the error is in the bogl backend, though
[03:45] <mjg59> Right, the mode that OF gives you may well not be single byte per pixel
[03:45] <Kamion> the pcfb and tcfb backends are both int-per-pixel, I think
[03:45] <mjg59> Having thought about it, it may well be necessary to include the bogl backend in the x86 version anyway
[03:46] <mjg59> Otherwise people using framebuffers lose
[03:46] <Kamion> in fact I think all of them are int-per-pixel
[03:46] <mjg59> Since we forcibly switch back to VGA text mode in the svgalib backend
[03:46] <Kamion> Mithrandir: adding usplash-theme-ubuntu
[03:47] <Mithrandir> Kamion: sounds trivial enough, so please do just go ahead
[03:47] <jdub> mjg59: transitions in current startup are a bit rough
[03:48] <Kamion> done
[03:49] <Mithrandir> mjg59: do you have an usplash that works on amd64 (or a plan on how to fix it) yet?
[03:49] <mjg59> Mithrandir: It works on amd64. It doesn't work on nvidia hardware on amd64.
[03:50] <mjg59> It's actually an x86emu backend issue rather than an amd64 one
[03:50] <mjg59> jdub: We need to forcibly set the screen back to text mode, otherwise X get horribly confused when you switch back to console VTs
[03:51] <mjg59> Given current X, I'm afraid that's unavoidable
[03:51] <mjg59> Mithrandir: I'm at something of a loss as to what the problem is. Any help there greatly appreciated.
[03:52] <Mithrandir> mjg59: hmm.  Do you have a useful point to start debugging?
[03:52] <mjg59> Mithrandir: Nope.
[03:53] <mjg59> You can duplicate the failure using vbetool
[03:53] <mjg59> The vbestate calls fail on nvidia kit
[04:02] <Kamion> oh, no, bogl isn't int-per-pixel after all, I'm just on crack. I wonder what's really going on, then
[04:03] <Mithrandir> mjg59: vbetool vbestate save made my second monitor unhappy, too. :-/
[04:27] <mvo_> Mithrandir: would it be possible to do a update-manager upload? or is knot too deeply frozen already? it contains a bunch of fixes/smallish UI improvments
[04:38] <Mithrandir> mvo_: I'd rather not if it's only small things.
[04:41] <mvo_> Mithrandir: ok
[04:53] <Kamion> mjg59: gotcha - it was just wrong width and height being set in the bogl_pixmap
[04:54] <mjg59> Kamion: Ah
[04:54] <mjg59> Excellent
[04:54] <Kamion> Mithrandir: can I upload sftp://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu/ ? fixes incorrect progress bar display on powerpc
[04:55] <bluefoxicy> by the by
[04:56] <bluefoxicy> should I not be using e-mail to put comments on bugs?
[04:56] <mjg59> Why not?
[04:56] <Kamion> no, it's fine, just attachments don't work that way
[04:56] <bluefoxicy> it's not that
[04:56] <bluefoxicy> my comments are like
[04:56] <bluefoxicy> --- BEGIN PGP SIGNED MESSAGE ---
[04:56] <bluefoxicy> a*##
[04:56] <bluefoxicy> Hello.  Yes this works
[04:56] <bluefoxicy> -- BEGIN 50 lines of SIGNATURE --
[04:56] <mjg59> So don't send signed messages
[04:56] <Mithrandir> Kamion: ok.
[04:56] <Kamion> you don't need to sign random comments - only if you're sending control messages
[04:56] <Kamion> AFAIK
[04:57] <bluefoxicy> yeah, I figured that malone would strip the signature
[04:57] <Kamion> and in any case, the fact that that isn't stripped for display on the web is a launchpad bug
[04:57] <mjg59> Ideally it would strip them, but there's little point in validating it
[04:57] <Mithrandir> Kamion: I'm off for a bit, so please just use your judgement (or call me if you're indecisive) for a bit.
[04:57] <Kamion> https://launchpad.net/distros/ubuntu/+source/debian-installer/20060711ubuntu10 woo
[04:57] <Kamion> Mithrandir: ok
[04:57] <bluefoxicy> also
[04:59] <Kamion> Mithrandir: oh, what's the CD build status? do you want me to do anything there?
[05:02] <bluefoxicy> mm.
[05:02] <bluefoxicy> I never filed bugs on packages demanding x86-64 libs on x86
[05:03] <SEJeff> Keybuk is working on upstart, correct?
[05:03] <bluefoxicy> QUESTION:  How hard is it going to be to make an argument to remove things like libc6-amd64 from i386 ubuntu?
[05:03] <bluefoxicy> hm.  This is odd.
[05:04] <bluefoxicy> they'll remove clean, how did they get installed in the first place then
[05:04] <SEJeff> bluefoxicy: check your spec RapidReboot, I'm looking to work on implementing it with some guidance from the upstart team
[05:04] <SEJeff> SEJeff == Jeff Schroeder
[05:04] <fabbione> SEJeff: yes, right.. he is upstart *
[05:06] <SEJeff> BenC: ping
[05:06] <BenC> SEJeff: pong
[05:06] <bluefoxicy> SEJeff:  nice.  Are you going to do any of the "Quick Reboot" shutdown menu hacks?
[05:07] <bluefoxicy> I favor having the icons change when you press shift myself; windows 9x did a fast reboot if you held shift and hit shutdown (it exited win.exe and reloaded it), but it didn't change the text to say "Fast Restart" when shift was held
[05:08] <SEJeff> BenC: Being the kernel guru you are, you would likely know about kexec. Is it in a state for *possibly* implementing RapidReboot for edgy+1. If so, I would like to work with Keybuk on it and integrating it into upstart
[05:08] <bddebian> Howdy folks
[05:08] <bluefoxicy> easily discoverable and non-invasive
[05:08] <SEJeff> bluefoxicy: Icons changing is against the HIG though
[05:08] <bluefoxicy> ah, true.
[05:08] <bluefoxicy> Text under the icons?
[05:09] <BenC> SEJeff: it is there and enabled
[05:09] <SEJeff> bluefoxicy: there was a rant on planet gnome recently by behdad about evolution and the excess number of buttons. It was brought up that changing buttons contextually is anti-HIG
[05:10] <bluefoxicy> SEJeff:  the alternative is to pack yet another button onto the interface.  I would argue that having 6 buttons, 2 of which do about the same thing, is probably worse but possibly HIG-conformant
[05:11] <SEJeff> BenC: I've been following the dev meetings and edgy pretty closely. How would I go about proposing RapidReboot for acceptance in edgy+1? I would like to do it
[05:11] <bluefoxicy> SEJeff:  (well, the other alternative is to not allow the user to manually initiate a fast reboot)
[05:11] <SEJeff> bluefoxicy: I agree with you entirely. Maybe just have the quick reboot implemented from the notification icons
[05:11] <BenC> SEJeff: launchpad's spec system is what you need to look into
[05:11] <BenC> SEJeff: that's where all new features are proposed
[05:12] <SEJeff> BenC: https://features.launchpad.net/distros/ubuntu/+spec/rapid-reboot it is already there
[05:12] <bluefoxicy> Edgy+1 isn't open yet so I don't think the spec system lets [mortals]  propose a spec for Edgy+1
[05:12] <SEJeff> bluefoxicy: I realize this, but I would like to start planning seeing as how I want to try and work on it
[05:12] <bluefoxicy> Yes I know :)
[05:14] <SEJeff> bluefoxicy: RapidReboot would also compliment the teardown spec already implemented
[05:14] <bluefoxicy> (there's a similar set of hacks for the LiveCD I want to try... which I'll go spec out now)
[05:14] <bluefoxicy> teardown?
[05:14] <SEJeff> https://wiki.ubuntu.com/Teardown
[05:18] <bluefoxicy> ah, nice.
[05:18] <dholbach> hum, how can I extract the core file part out of a apport report and feed it into gdb?
[05:23] <BenC> http://www.watchguard.com/products/x2500.asp
[05:23] <BenC> that's my new Ubuntu Edgy Server box :)
[05:23] <bluefoxicy> SEJeff:  good luck on that.  I have to go to class soon, and then move the Nano/Pico-Tier stuff into the main design for my allocator, since I set feature freeze for friday (I will creep new features in every 3 days for the next 5 years ...)
[05:24] <dholbach> BenC: What do you need 275+/300+ Mbps for - I thought your internet connection was dying all the time ;-P
[05:24] <SEJeff> have fun
[05:24] <bluefoxicy> SEJeff:  do you know when discussion on Edgy+1 Toolchain is going to happen?  I really want to be there.
[05:24] <SEJeff> no
[05:24] <janimo> bluefoxicy: I think that happened already in paris
[05:24] <bluefoxicy> janimo:  oh damn.
[05:25] <BenC> dholbach: Gives me room to upgrade to multi-T3 :P
[05:25] <janimo> bluefoxicy: unless you mean a specific discussion that was planned these days
[05:25] <bluefoxicy> There's a couple can't-miss optimizations that need to be done and one we-really-shouldn't-but-if-you-want-to-go-for-it
[05:25] <dholbach> BenC: riiiiight :)
[05:26] <bluefoxicy> janimo: eh.  I thought the tech board meetings or dev team meetings focused on this stuff some time nearing the release of Edgy
[05:26] <janimo> bluefoxicy: the spec for a cycle is planned at the start of the one before it since the transition happens in the weeks after release, before the conference. So it needs to be discussed earlier
[05:27] <bluefoxicy> janimo:  ah.  That means what, in english?
[05:27] <janimo> bluefoxicy: I read that myself after sending and asked the same question :)
[05:27] <bluefoxicy> haha
[05:28] <janimo> the toolchain specification ofr a release happens one cycle earlier, as the transition from one toolchain to another can be thought of as part of the previous cycle.
[05:28] <bluefoxicy> yes but when is it frozen
[05:28] <bluefoxicy> <-- not a dev
[05:28] <janimo> as soon as edgy opens (well one or two weeks after) the new toolchain needs to be uploaded os it can be tested as much as possible
[05:29] <janimo> so it is discused months ahead, along with the specs affecting the just released version
[05:29] <bluefoxicy> so the edgy+1 toolchain has been in testing since June?  o_O
[05:29] <janimo> bluefoxicy: not in testing (I don;t know for sure) but settled on AFAIK
[05:29] <tseng> planned is al
[05:29] <tseng> all
[05:30] <janimo> but there are people who know for sure (doko, jbailey)
[05:30] <bluefoxicy> I noticed a while back that --hash-style wasn't on the spec so stuck it in :o
[05:30] <bluefoxicy> was that a bad idea?
[05:30] <bluefoxicy> (it's in the newer binutils since around June-July)
[05:31] <janimo> I don;t know so I'll shut up instead of possibly misguiding you
[05:31] <bluefoxicy> tseng:  who do I have to blow to find out what the buildd looks like?  I've had 5 different people tell me 5 different things about -Wl,-O1
[05:32] <Kamion> bluefoxicy: infinity is the authority
[05:32] <bluefoxicy> either Keybuk or Kamion said that it's only applied to GNOME packages, someone else said it was applied globally in LD_FLAGS, no one seems to really have solid documentation
[05:32] <bluefoxicy> Kamion:  ah, then I'll stop bugging every random person :)
[05:33] <Kamion> bluefoxicy: the buildd is not doing *anything* special to toolchain options
[05:33] <Kamion> bluefoxicy: the only thing that's happening is that some packages apply options in their own build scripts. You can look for those yourself.
[05:33] <slomo> bluefoxicy: most gnome packages use it, right... but it's done per-package in debian/rules
[05:33] <Kamion> feel free to confirm that with infinity if you like
[05:33] <bluefoxicy> Kamion:  yeah, I saw it was in some gnome debian/rules
[05:34] <Kamion> bluefoxicy: with regard to editing specifications, please refrain from editing specifications that are already approved except to add comments in a separate section at the bottom
[05:34] <bluefoxicy> Kamion, slomo:  There's some things worth doing globally, like --hash-style=both (approximately 50% speedup for dynamic linking, apps load faster)
[05:34] <Kamion> bluefoxicy: anything we want to do globally should be in the gcc specs file; it shouldn't be done at the buildd level
[05:35] <Kamion> you need to talk to the toolchain maintainers about that
[05:35] <bluefoxicy> nods.
[05:35] <bluefoxicy> that would be doko/infinity/who else?
[05:36] <Kamion> primarily doko
[05:36] <bluefoxicy> (meanwhile I'll move the stuff I put on the spec down into the comments)
[05:36] <bluefoxicy> ah.. his schedule was what?
[05:36] <bluefoxicy> is he gonna be here when i get back from school in about 4 hours?
[05:37] <Kamion> I have no idea. You know where your mail client is :)
[05:37] <bluefoxicy> nobody I e-mail here ever mails me back :)
[05:37] <bluefoxicy> well, mdz does
[05:38] <jdong> bluefoxicy: they get lots of e-mails... it's indeed hard to get ahold of them :)
[05:38] <bluefoxicy> jdong:  easier to pester them on IRC ;)
[05:38] <jdong> bluefoxicy: exactly :)
[05:39] <bluefoxicy> grah.  I can only see the immediate prior revision on the wiki!
[05:41] <mdz> dholbach: is 52405 actually fixed?
[05:44] <hunger> How do i
[05:44] <hunger> How do I work around the upstart problem with cryptdisks again?
[05:45] <hunger> The last upgrade has again broken my boot process:-(
[05:45] <jdong> hunger: doesn't look like keybuk's around :-/
[05:47] <dholbach> mdz: I just deinstalled menu and menu-xdg and restarted - it's fine for me -- do you still have the problem?
[05:51] <_ion> hunger: Add the line "console owner" to /etc/event.d/rcS
[06:01] <tkamppeter> pitti, I have problems with the build of GutenPrint 5.0.0 final
[06:03] <xav> dholbach: how is that a fix ? it's a workaround, there are many described
[06:04] <dholbach> xav: I had menu installed previously as a workaround, now I *de*installed it again, restarted my session
[06:04] <dholbach> xav: and I tested a live cd today which didn't expose the problem either
[06:05] <xav> dholbach: oh ok then but
[06:05] <dholbach> but?
[06:05] <xav> dholbach: it's the package who got fixed, or the real bug ?
[06:05] <dholbach> To be honest, I'm not quite sure which fix finally solved the problem.
[06:05] <janimo> tkamppeter: is there a preferred way of storing default printer? ~/.cups/lpoptions vs /etc/cups/printers.conf
[06:05] <dholbach> xav: do you still have the problem?
[06:05] <xav> dholbach: problem with the packages is that there were a broken symlink
[06:06] <dholbach> that I know
[06:06] <xav> dholbach: I've no clue, I'm on edgy but didn't reinstall gnome
[06:06] <janimo> tkamppeter: I see gnome-cups-manager uses the first the RH config UI the second
[06:06] <xav> dholbach: is it still there?
[06:06] <dholbach> xav: I didn't reinstall it either?
[06:06] <pitti> tkamppeter: hi! (I just replied to your mail)
[06:07] <dholbach> xav: I don't face the problem on any of my machines
[06:07] <mdz> dholbach: I am subscribed to the bugs and saw someone mark it Fix released and claim it fixed, but I think it very much still exists
[06:07] <dholbach> mdz: oh?
[06:07] <tkamppeter> /etc/cups/printers.conf can only mark locally defined printers as default, whereas /etc/cups/lpoptions can also mark broadcasted printers from other machines as default.
[06:07] <mdz> dholbach: as always, it only happens if there's a broken symlink, but we either need to fix the broken symlink (as a workaround) or fix the bug
[06:08] <tkamppeter> ~/.cups/lpoptions is like /etc/cups/lpoptions, but a for personal settings of the user.
[06:08] <dholbach> ok, I'll try to reproduce it...
[06:08] <xav> so the broken symlink is still there?
[06:08] <pitti> tkamppeter: ok, so far that's clear
[06:08] <tkamppeter> janimo, printerdrake uses both.
[06:08] <janimo> tkamppeter: so the latter is preferred then? Since both are used by CUPS is one of them supposed to obsolete the other or both can be used?
[06:08] <xav> how did an upgrade manage to fix it?
[06:09] <pitti> tkamppeter: I believe we use ~/.lpoptions by default (gnome-cups-mgr does that)
[06:09] <pitti> tkamppeter: back in 15 minutes, I'm grabbing a bite
[06:09] <dholbach> mdz: so you still have the problem on an up-to-date edgy?
[06:09] <janimo> tkamppeter: what cat printers.conf do that cannot be done in lpoptions then?
[06:09] <janimo> s/cat/can/
[06:10] <mdz> dholbach: I did the last time I looked, and I have no reason to believe it's been fixed. do you?
[06:10] <ivoks> tkamppeter: need a help?
[06:11] <tkamppeter> Note that ~/.lpoptions or ~/cups/.lpoptions is personal to the user. A printer setup tool which sets up system-wide print queues should also set up a system-wide default printer.
[06:11] <ivoks> tkamppeter: ~/.cups/lpoptions :)
[06:12] <xav> dholbach: sorry, I may be a little slow but I still don't understand. do you have this file : /etc/xdg/menus/debian-menu.menu and is it a broken symlink?
[06:12] <janimo> tkamppeter: I understand the user vs systemwide difference. BUt I wonder what is the diff between /etc/cups/lpoptions and /etc/cups/printers wrt default system wide printer setting
[06:12] <tkamppeter> Note also that a default printer set in /etc/cups/lpoptions in a CUPS 1.1.x environment is not propagated into the network. With a CUPS 1.2.x network it is possible that it gets propagated, but I am not absolutely sure.
[06:13] <dholbach> mdz, xav: I just made /etc/xdg/menus/debian-menu.menu a broken symlink and after restarting the panel behaves fine
[06:13] <tkamppeter> So the advantage of /etc/cups/printers is that the default printer setting gets for sure propagated into the network. At least to clients which do not have their own default printer setting.
[06:14] <mdz> dholbach: er
[06:14] <mdz> dholbach: I fixed it ;-)
[06:14] <tkamppeter> printers.conf and lpoptions are different
[06:14] <dholbach> mdz: YOU ROCK! How? :-)
[06:14] <mdz> dholbach: /usr/share/doc/menu-xdg/changelog.gz
[06:15] <mdz> dholbach: I implemented the workaround I was just talking about, but I forgot about it
[06:15] <xav> lol
[06:15] <tkamppeter> printers.conf is configured by the lpadmin command by an admin and is always system-wide. It has no personal counterpart.
[06:15] <dholbach> :-)
[06:16] <tkamppeter> It defines print queues and the queue's properties. One queue can be marked as the default.
[06:16] <mdz> dholbach: I forgot to update the bug with that information; I've done so now
[06:17] <tkamppeter> The actually available queues can come from printers.conf, from classes.conf (printer classes, queues clustered together), or can be picked up from external CUPS server's broadcasts
[06:17] <dholbach> mdz: I don't have that version of the package installed
[06:17] <janimo> tkamppeter: so the default server can be set in both places with slightly different goals?
[06:18] <janimo> default printer I mean
[06:18] <tkamppeter> In printers.conf OR classes.conf NO or ONE local queue can be set as default queue.
[06:18] <dholbach> mdz: and I just installed a broken symlink for gnome-panel/gnome-menus/gamin/whatever to stumble over ... so I'm a bit unsure
[06:19] <tkamppeter> lpoptions is configured by the lpoptions command, if root runs the lpoptions command, /etc/cups/lpoptions is modified, if a normal user runs the lopoptions command, the file ~/.cups/lpoptions is modified.
[06:19] <tkamppeter> janimo, the default printer, not the default server.
[06:21] <jamadagni> hello is mithrandir here/
[06:22] <janimo> tkamppeter: Still, which has priority, lpoptions or printers.conf as both can be set systen wide and contain a default printer
[06:22] <tkamppeter> To get the best transparence for an admin using a printer setup tool I recommend that the tool sets the default printer in BOTH printers.conf/classes.conf (sudo lpadmin -d <queue>) AND /etc/cups/lpoptions (sudo lpoptions -d <queue>). If you set the default CUPS printer with "sudo foomatic-configure", it is done so.
[06:23] <janimo> tkamppeter: but why are ther two places for the same setting?
[06:23] <tkamppeter> if printers.conf/classes.conf and lpoptions has different default printers, lpoptions has priority.
[06:23] <janimo> tkamppeter: ah,ok. thanks
[06:23] <ivoks> tkamppeter: hm?
[06:23] <tkamppeter> If a user has a personal lpoptions, this overrides any system-wide default.
[06:23] <ivoks> tkamppeter: i had default in lpoptions and in printers.conf
[06:23] <pitti> tkamppeter: I'm back now, btw; how can I help you with gutenprint?
[06:23] <ivoks> tkamppeter: but default was from printers.conf
[06:24] <pitti> tkamppeter: btw, you didn't get my /msg?
[06:24] <janimo> tkamppeter: I knew it overrides lpoption from system wide but was not sure of printers,coinf as it's a separate file format and option 
[06:25] <tkamppeter> pitti, I have now the Debian package, where all dpatches are flattened out into the general diff.gz file. So all info about their changes is definitely lost and a private secret of Roger Leigh (and I thought we work with free software)
[06:25] <pitti> tkamppeter: right, that's what I answered in my mail
[06:25] <pitti> tkamppeter: the short form: we don't need to care
[06:26] <tkamppeter> But anyway, I can still re-add the Ubuntu patches with dpatch.
[06:26] <pitti> tkamppeter: that would be appreciated, it makes merges a lot easier
[06:26] <tkamppeter> I would at first make sure that dpatch.mk is in debian/rules, re-adding it if needed.
[06:26] <pitti> tkamppeter: do we actually have relevant changes that still apply to 5.0-2?
[06:26] <pitti> tkamppeter: right
[06:27] <pitti> tkamppeter: ideally we could send the remaining diff to Debian and sync in the future
[06:27] <pitti> tkamppeter: until then dpatch should do fine
[06:27] <tkamppeter> Then I have seen that the Debian package still has the "model" hard-coded into the PPD path.
[06:27] <pitti> tkamppeter: btw, we don't patch files in debian/ (they are modified directly)
[06:28] <tkamppeter> So the build system still needs to be patched that we can add out /usr/share/ppd (and all other future standard paths of LSB 3.2).
[06:29] <tkamppeter> Note that the debian diff.gz file does not only contains hunks in debian/ but 30 or 40 files also outside the debian, it seems that it is parts of our 10-.... patch mixed with other patches.
[06:29] <pitti> tkamppeter: yeah
[06:30] <pitti> tkamppeter: I wonder why Debian didn't adopt the /usr/share/ppd policy yet
[06:30] <pitti> tkamppeter: it was discussed months ago and we implemented it pretty quickly
[06:31] <tkamppeter> So I have loaded the Debian source with dpkg-source -x and then I have manually edited only the configure.ac file accordint to our 10-... patch. I did not modify anything else.
[06:32] <tkamppeter> Then I typed autoreconf and it complained about missing m4local directory, mkdir'ed that and again autoreconf. then this:
[06:32] <pitti> tkamppeter: if Debian already modified configure.ac in the diff.gz and called autoreconf (with those changes being inline as well), then it might be better to just do the same in Ubuntu and documetn it in the changelog
[06:32] <pitti> tkamppeter: otherwise we would have two big patches, which doesn't make sense
[06:33] <Kamion> mdz: FYI, kwwii is now sorted for using usplash on his system
[06:33] <tkamppeter> aclocal: configure.ac: 382: macro `AM_PATH_GTK' not found in library
[06:34] <tkamppeter> aclocal: configure.ac: 739: macro `AM_PATH_GTK' not found in library
[06:34] <tkamppeter> aclocal: configure.ac: 743: macro `AM_PATH_GTK' not found in library
[06:34] <tkamppeter> aclocal: configure.ac: 743: macro `AM_PATH_GLIB' not found in library
[06:34] <tkamppeter> autoreconf: aclocal failed with exit status: 1
[06:34] <pitti> tkamppeter: maybe dholbach can help you with that
[06:34] <tkamppeter> But for this autoreconf has to run anyway, and I do not get it working.
[06:34] <pitti> tkamppeter: I'd assume you are missing some gtk-dev package
[06:35] <janimo> Kamion: can you take python-cups out of NEW or is it Keybuk's day? 
[06:35] <dholbach> tkamppeter: which package did you try to autoreconf? gnome-cups-manager?
[06:35] <Kamion> janimo: it's Keybuk's day, but I haven't seen him ...
[06:35] <Kamion> janimo: is it destined for main?
[06:35] <pitti> dholbach: gutenprint
[06:35] <dholbach> ok
[06:35] <tkamppeter> The error messages seem to be caused by missing libgtk1.3-dev, but I cannot install it as apt-get tells me it conflicts with libgtk2-dev
[06:36] <pitti> argh, 1.3?
[06:36] <pitti> *shudder*
[06:36] <janimo> Kamion: it may be, I'd like to get it tested by some more people first though
[06:36] <mjg59> libgtk1.3 was the development tree for libgtk2
[06:36] <tkamppeter> and libgtk2-dev is also needed for this autoreconf
[06:36] <mjg59> If anything depend son it, it's broken
[06:36] <dholbach> tkamppeter:    sudo apt-get build-dep gutenprint     should have all you need
[06:36] <tkamppeter> I am fighting with gutenprint
[06:37] <tkamppeter> dholbach, I have done this, and for autoreconf I had even to install more packages
[06:37] <tkamppeter> So do I need another libgtk1-dev?
[06:38] <ivoks> umm...
[06:38] <Kamion> janimo: python-cups doesn't seem to follow the new python policy; it should be using one of python-central or python-support, surely
[06:38] <ivoks> didn't we disable gtk1 in our packages?
[06:39] <pitti> ivoks: we must have, since gtk1 is in universe
[06:39] <pitti> tkamppeter: no, that would be wrong
[06:39] <tkamppeter> ivoks, seems so, as apt-get does not find a package named libgtk1-dev
[06:39] <ivoks> pitti: debian/rules, debian/control.in: Drop libgtk1.2-dev build dependency
[06:39] <janimo> Kamion: when I uploaded it I asked doko and he said it was not mandatory. Since then pyton 2.5 got in so this may have changed
[06:39] <tkamppeter> Universe is activated in my /etc/apt/sources.list
[06:39] <janimo> I guess I'll use one of those two options in the next upload then
[06:39] <ivoks> tkamppeter: no main package can depend on universe package
[06:39] <Kamion> janimo: not mandatory to use python-{central,support}, or not mandatory to follow the new python policy?
[06:40] <pitti> tkamppeter: you might try libgtk1.2-dev
[06:40] <janimo> Kamion: to use the two
[06:40] <pitti> oops, gtk1.2 is still in main
[06:40] <pitti> we couldn't throw it out, as it seems
[06:40] <pitti> so, I lied, sorry
[06:41] <Kamion> janimo: I guess it is possible to comply with the new python policy and not use python-{central,support}, but you'd need to use a number of workarounds, which you don't seem to be doing
[06:41] <tkamppeter> all gutenprint binary packages do not depend on GTK1, nor the build process, but as Gutenprint has legacy support for GTK1, autoreconf for gutenprint needs GTK1.
[06:41] <janimo> Kamion: as for policy with only python-2.4 as the supported version it looked ok. It may not be ok now with pyversions -s saying both 2.4 and 2,5
[06:41] <janimo> I need ottest
[06:41] <Kamion> janimo: from our perspective as archive admins, following the new python policy is definitely mandatory
[06:41] <Kamion> janimo: yes, please; I'll reject it for now
[06:41] <Kamion> the point of the new policy is to gracefully handle the move to python2.5 and later
[06:42] <ivoks> we changed rules to not build against gtk1
[06:42] <tkamppeter> Installing libgtk1.2-dev ...
[06:42] <ivoks> no...
[06:42] <ivoks> :)
[06:42] <Kamion> janimo: http://wiki.debian.org/DebianPython/NewPolicy describes how to do it
[06:42] <dholbach> ivoks: you seem to need to have libgtk1.2-dev installed to autoreconf -i
[06:43] <tkamppeter> At least I get to another error now ...
[06:43] <ivoks> this is in debian testing?
[06:44] <janimo> Kamion: thanks, I'll reread that.
[06:45] <dholbach> ivoks: because of the error that tkamppeter just quoted: AM_PATH_GTK, AM_PATH_GLIB - check configure.ac -> AM_PATH_GTK(1.2.0, ...
[06:45] <dholbach> tkamppeter: with libgtk1.2-dev installed   ./autogen.sh  at least runs through for me again
[06:47] <ivoks> hm
[06:47] <ivoks> you are trying to build debian package.. or?
[06:47] <ivoks> plain source?
[06:47] <tkamppeter> Here are my autoreconf errors:
[06:47] <tkamppeter> http://www.freestandards.org/~till/tmp/ubuntu/edge/gutenprint/autoreconf1.log
[06:47] <dholbach> ivoks: it seems that tkamppeter needs to run  autoreconf -i  for a patch of his to apply
[06:48] <dholbach> (if I didn't get the situation wrong=
[06:48] <ivoks> (couse i can build debian package without libgtk1.2-dev)
[06:48] <ivoks> ok
[06:50] <tkamppeter> dholbach, autogen.sh runs also for me, it even runs configure afterwards, but try make after that. This fails for me.
[06:50] <dholbach> urg
[06:50] <pitti> tkamppeter: any chance to fix the PPD path without messing with autobreak tools?
[06:50] <dholbach> I wonder how upstream rolled their release tarball then
[06:51] <pitti> tkamppeter: a two-line patch in one file seems easier to handle than touching all the auto stuff
[06:51] <tkamppeter> pitti, that is probably the only solution. Perhaps I should try things which I often did in Mandriva packaging, like
[06:51] <pitti> tkamppeter: alternatively, if you just fix a path in configure.ac, just do the same change in configure
[06:51] <pitti> and don't bother with autoreconf
[06:52] <tkamppeter> perl -p -i -e 's:/usr/share/cups/model:/usr/share/ppd:g' * */* */*/*
[06:52] <tkamppeter> or similar
[06:52] <pitti> tkamppeter: yeah, that's what I mean :)
[06:52] <pitti> tkamppeter: find -name '*.c' -o -name '*.h' | xargs sed -i 's/oldpath/newpath/g' or so
[06:53] <pitti> and then check the diff
[06:53] <tkamppeter> Perhaps it is enough to apply the perl command only to the configure script
[06:53] <ivoks> find has an -exec :)
[06:53] <pitti> ivoks: too clumsy for my taste, and xargs is more efficient in the general case :)

[06:54] <ivoks> well, pitti fwiw, i wouldn't use sed, but vim -c :)))
[06:54] <tkamppeter> Perhaps I run the perl or whatever out of debian/rules and so I can avoid a patch
[06:54] <pitti> tkamppeter: oh, please don't
[06:54] <pitti> tkamppeter: if you do that, then you cannot build the source package after buliding the binary package any more
[06:54] <pitti> tkamppeter: rather do it statically, that's more robust
[06:54] <tkamppeter> So I better run the perl in my shell to generate a patch?
[06:54] <pitti> tkamppeter: but putting the command in the changelog would be helpful
[06:55] <pitti> tkamppeter: yes, as long as it's not too big (I doubt that it is big), doing the modifications in a dpatch is better
[06:55] <tkamppeter> Yes, this is a good idea.
[06:55] <mdz> dholbach: maybe it's not so easy to reproduce
[06:55] <pitti> tkamppeter: it would surprise me if the path was hardcoded in more than handful of places
[06:55] <dholbach> mdz: I'll try on other boxes
[06:55] <tkamppeter> In my Mandriva RPMs I tried to avoid patches as much as possible. They contain a lot of perl magic
[06:56] <pitti> tkamppeter: btw, /msg still doesn't work for you?
[06:56] <ivoks> well, so long guys, i have exam tomorrow :/
[06:56] <pitti> ivoks: /me crossing fingers, good luck!
[06:56] <ivoks> thanks
[06:56] <dholbach> tkamppeter: ./autogen.sh && autoreconf && make   builds it (not sure what your changes are, though)
[06:59] <tkamppeter> autoreconf after autogen.sh fails for me, a "make" after that re-runs configure and fails then.
[06:59] <tkamppeter> pitti, what do you mean with /msg
[06:59] <pitti> tkamppeter: private conversation
[06:59] <pitti> tkamppeter: try '/msg pitti ping'
[07:00] <tkamppeter> pitti, I have seen that you have opened a private coversation now.
[07:02] <Kamion> Am I going mad? Are file-scoped static variables trashed before registered atexit() handlers are called?
[07:04] <o_cee> hrm, Compiz settings manager, why doesn't it apply changes? strange..
[07:20] <Kamion> mjg59: valgrind is telling me very weird things about usplash
[07:20] <Kamion> mjg59: it's saying that saved_vt is uninitialised when usplash_restore_console is called
[07:20] <mjg59> Kamion: I can well believe it
[07:20] <mjg59> Erm.
[07:20] <Kamion> but it's static and initialised
[07:20] <mjg59> Yes
[07:20] <mjg59> What if you make it non-static?
[07:20] <Kamion> I'm wondering if there's something very weird about static objects and atexit()
[07:21] <mjg59> Could be
[07:21] <Kamion> except this isn't even called from atexit(), so it's not that
[07:22] <Kamion> no, that doesn't help
[07:23] <Kamion> the reason I'm looking at this is that I'm working on a change to properly test the framebuffer mode before applying it, as you're supposed to
[07:23] <Kamion> this pretty much necessitates saving the whole fb_var somewhere
[07:23] <Kamion> and the fb_var is getting corrupted somewhere in the middle of proceedings, so I'm trying to figure out why
[07:23] <zyga> hey
[07:24] <zyga> mvo: ping, how is progress?
[07:24] <mjg59> Kamion: Bear in mind that not all framebuffers will support modesetting
[07:25] <mjg59> Kamion: If they don't, that shouldn't be a failure - we should just return the size that we do get back
[07:26] <Kamion> mjg59: hmm, ok; shouldn't their FB_ACTIVATE_TEST mode then tweak the mode you supply to the closest thing it can manage?
[07:26] <mjg59> Kamion: I'm not sure
[07:26] <Kamion> (perhaps the current mode)
[07:26] <mjg59> Kamion: But at some stage we need to feed the resolution back to usplash, and it needs to be the resolution we ended up getting rather than the one it requested
[07:27] <Kamion> mjg59: right. the change I'm working on is getting much closer to that
[07:27] <Kamion> although it isn't all the way there yet
[07:27] <Mithrandir> Kamion: I've been waiting for your d-i and ubiquity fixes to get into the archive, so I haven't built livefs-es or anything.  Is everything you want in in now?
[07:27] <Kamion> doing FB_ACTIVATE_TEST intrinsically involves accepting possibly a slightly different mode than the one you asked for
[07:28] <Kamion> Mithrandir: yes, should be
[07:28] <o_cee> oh my. xgl with cgwd is just.. wonderfully beautiful..
[07:28] <Kamion> Mithrandir: oh, usplash 0.4-24 isn't there yet
[07:28] <Mithrandir> Kamion: I'll twiddle my thumbs until the new usplash's there, then.
[07:29] <Kamion> should be there RSN
[07:29] <mjg59> Kamion: Ok. Once you've committed, I'll test it against vesafb
[07:29] <Kamion> Mithrandir: it's in this publisher run
[07:31] <Kamion> mjg59: might be a while, as I have no ideas currently about what might be trashing my saved copy of fb_var
[07:31] <mjg59> Kamion: Ok
[07:37] <mvo> zyga: hello! how was your exam? the data-extraction did run, I'm integrating them now
[07:47] <zyga> mvo: bad, I failed --- again :/
[07:47] <zyga> mvo: cool, how many ERRORs did you get?
[07:48] <mvo> zyga: oh :( sorry for that :(
[07:50] <zyga> mvo: bah, I was not prepared as usual
[07:51] <mvo> zyga: the new data is more better, I will do a upload of it (i386 only for now)
[07:51] <zyga> I'm angry with myself but that'll pass
[07:51] <zyga> why i386 only?
[07:51] <mvo> zyga: I meant only the i386 db
[07:52] <zyga> yeah, but why?
[07:52] <mvo> the -universe databases are ~4Mb each
[07:52] <mvo> so for a full upload it would be a 12mb source package. its not that bad, but it is not really needed either IMO
[07:53] <zyga> so we'll assume that any-arch == i386?
[07:53] <zyga> ah, the data needs to be in the source package
[07:53] <zyga> how about taking the raw scan.log
[07:53] <zyga> bzipping it away and making the build process do the rest?
[07:53] <zyga> will that be smaller?
[07:53] <mvo> and build the database on compile time? yeah, that should work
[07:54] <zyga> mvo: how big is scan log?
[07:54] <mvo> yeah, that sounds like the right solution
[07:54] <mvo> the logfile is immense, the scan.data is ~5,5mb
[07:55] <zyga> right
[07:55] <mvo> zyga: scan.log: 220MB(!)
[07:55] <zyga> the log file is irrelevant for the source package :)
[07:55] <mvo> I know :)
[07:55] <zyga> but uploading scan.data.bz2 will make it a good source package and a small one as well :)
[07:55] <zyga> mvo: I'll grep my scan log at home :)
[07:56] <shaya> does any suffer from a bug w/ "Loading Hardware Drivers...." where it just hangs?
[07:56] <shaya> edgy of course
[07:56] <shaya> pitti: btw, did I answer your quesiton about my vino patch?
[07:57] <mvo> seb128: HAPPY BIRTHDAY
[07:57] <seb128> hi
[07:57] <seb128> mvo: thank you
[07:57] <dholbach> seb128: BONNE ANNIVERSAIRE!
[07:57] <seb128> Mithrandir: is main frozen, frozen?
[07:57] <seb128> dholbach: "BON", anniversaire est masculin ;)
[07:57] <dholbach> seb128: ah ah :-)
[07:57] <thom> happy birthday seb!
[07:58] <seb128> thom: thank you
[07:58] <Mithrandir> seb128: veeeeery cold, yes.
[07:59] <Mithrandir> seb128: I was going to start building livefs-es and cds now; is there anything particular you need?
[08:00] <mvo> zyga: please merge from http://people.ubuntu.com/~mvo/bzr/command-not-found/mvo  (only changelog updates for now)
[08:00] <zyga> mvo: merging
[08:00] <mvo> zyga: and add everything to the changelog that I forgot :)
[08:02] <seb128> Mithrandir: I've a libgnomeui patch ready to upload
[08:02] <xav> hey, mine was 3 days ago :p maybe all french are born in september
[08:02] <seb128> Mithrandir: it fix the GTK fileselector hanging apps like rhythmbox or evince
[08:03] <pitti> shaya: I didn't yet look at it, sorry
[08:03] <Mithrandir> seb128: hmm.  Trivial patch?
[08:04] <seb128> Mithrandir: http://cvs.gnome.org/viewcvs/libgnomeui/file-chooser/gtkfilesystemgnomevfs.c?r1=1.82&r2=1.83&makepatch=1&diff_format=u
[08:04] <seb128> Mithrandir: pretty simple yep
[08:04] <seb128> Mithrandir: and already commited to upstream stable branch
[08:04] <zyga> mvo: looks great, thanks :)
[08:05] <zyga> mvo: merged and pushed
[08:05] <Mithrandir> seb128: ok, upload it then.
[08:05] <seb128> Mithrandir: thank you
[08:06] <zyga> mvo: I guess it's time to blog about it because it's quite good now :)
[08:07] <MrFaber> hi all
[08:08] <pitti> zul: do you have any clue about the failed breezy kernel?
[08:08] <MrFaber> What is the most common reason for sporadic kernel syncing errors? What is more likely, hardware or software bug? The mem is ok according to mem check. I am useing Dapper with latest amd64 server kernel.
[08:08] <simira> mvo: had a look on u-m when I got home just now (I was out when you asked). Right now, it just asked for my password, and then failed to start...
[08:11] <zul> pitti: not yet..
[08:11] <zul> ill get it fixed tonight though
[08:11] <pitti> Mithrandir: ok to upload libxfont security update to edgy? It just got un-embargoed
[08:12] <pitti> Mithrandir: I tested the package for over a day now, no visible regressions and straightforward patches
[08:12] <Mithrandir> pitti: yes
[08:13] <pitti> thanks, I'll upload now
[08:13] <mvo> zyga: totally
[08:13] <mvo> zyga: please merge again, I made the generation current-arch + "all" (by default)  now so that it can be integrated into the build process. once that is finished, we can upload (but I need to go and do some washing first now :)
[08:14] <zyga> mvo: okay
[08:14] <zyga> mvo: update-manager looks nicer with 'Updates of Ubuntu' banner on top :)
[08:14] <Kamion> I hope that's not hardcoded branding?
[08:14] <zyga> mvo: thanks, I could not do it without you :)
[08:15] <zyga> Kamion: I don't know but I doubt it, probably a channel
[08:15] <Kamion> seems unfortunate for Kubuntu, Edubuntu, and Xubuntu
[08:15] <Kamion> since the channel will be "Ubuntu" for all three, probably?
[08:16] <zyga> all three?
[08:16] <zyga> ah
[08:16] <zyga> hmm, I don't know
[08:16] <zyga> but it's unfortunate :/
[08:16] <zyga> mvo?
[08:36] <punkmexic> hello
[09:10] <sivang> re
[09:16] <seanh> Hi ubuntu-devel, I have ubuntu setup in a cafe and want something to automatically clean up files that users leave around, without touching my desktop shortcuts or the users config files. Was thinking of an rsync script. Any advice?
[09:21] <Burgwork> seanh, are users allowed to save files?
[09:21] <seanh> Well.... users can save files to the homedir to work on them, yes, but they shouldn't assume the files will be there when they come back next time
[09:22] <Burgwork> how do they login?
[09:22] <seanh> There is one 'public' user account that is shared by all visitors
[09:22] <seanh> that account is set to automatically login
[09:22] <seanh> it uses the Desktop user profile
[09:22] <Burgwork> here is what I would do: create a sabayon profile, link the user to it
[09:22] <seanh> I'm using Sabayon and Pessulus to prevent users from changing some things
[09:23] <Burgwork> upon logout, wipe out the user, including their home dir, recreate on login
[09:24] <seanh> What do you mean wipe out the user? Simply delete their homedir, or do I have to remove the username from the system somehow?
[09:24] <Burgwork> no, you can just wipe the idr
[09:24] <ivoks> right
[09:24] <ivoks> and with PAM recreate
[09:24] <seanh> And sabayon will recreate the homedir on each login?
[09:24] <ivoks> PAM will
[09:24] <seanh> PAM?
[09:25] <Burgwork> ivoks, hmm, PAM, not thought of that
[09:25] <ivoks> seanh: Plugable Authentication Module
[09:25] <ivoks> seanh: you use it every time you login
[09:25] <ivoks> seanh: it has a modul which can create user's home dir upon user login
[09:25] <Kamion> pam_mkhomedir
[09:26] <ivoks> seanh: very handy in LDAP installations, but would also work great in your situation
[09:26] <ivoks> Kamion: right
[09:26] <Burgwork> ivoks, for edgy+1, we would create a profile, etc, for this, so people can just install it
[09:26] <ivoks> Burgwork: that would be fairly easy
[09:27] <ivoks> Burgwork: but that should be part of the bigger master plan; ubuntu-caffe :)
[09:27] <Burgwork> indeed
[09:27] <seanh> How do I run a script on logout anyway?
[09:27] <Burgwork> currently all the "session-clearing" kiosk cds use livecd, which suck
[09:27] <ivoks> seanh: i have an idea
[09:28] <ivoks> ups... better not via skel :)
[09:28] <seanh> Okay folks, I just had an update go bad and need to leave X right now, sorry. Thanks for the advice though, will look into it
[09:29] <ivoks> Burgwork: if you are interested, we could work on that
[09:50] <Burgwork> can you create closed source PAM modules?
[09:50] <_ion> I hope not. :-)
[09:51] <ivoks> it's GPL
[09:51] <Kamion> PAM itself is dual-licensed BSD/GPL
[09:51] <Burgwork> right, so you can
[09:51] <ivoks> right
[09:51] <Kamion> Burgwork: not necessarily
[09:51] <Lathiat> does pam link with any GPL stuff on a linux system?
[09:51] <Kamion> Burgwork: bear in mind that applications distributed on the system might be GPLed
[09:51] <Burgwork> such as gdm?
[09:51] <Kamion> for example su contains GPLed code
[09:52] <Kamion> yes, gdm is GPLed
[09:52] <Burgwork> ok, licensing official sucks
[09:52] <Kamion> ... if you're trying to produce closed-source software, sure
[09:53] <Kamion> ;-)
[09:53] <Burgwork> hey, I don't produce it, I just sell it
[09:53] <ivoks> then you are evil man :)
[09:55] <Burgwork> I want to see if my company misstepped, as we have one of those closed-source PAM modules
[09:55] <mdz> mjg59: are you available for TB?
[09:55] <mjg59> mdz: Yes
[09:55] <mdz> excellent, because I don't think anyone else is
[09:55] <mjg59> Scott certainly isn't
[09:56] <ivoks> ttg bye
[09:57] <Kamion> Burgwork: it's probably a bit debatable. If you're distributing a system that contains gdm (or another GPLed program linked to PAM) plus your proprietary module as a work as a whole, then you're violating the gdm licence; but if you're just distributing the module on its own and letting users decide what to do with it, you're probably OK
[09:57] <Kamion> IANAL, etc. Consult a lawyer if you're unsure.
[09:58] <Burgwork> Kamion, we are certainly not doing the latter, so I will chat with the company president about it
[09:59] <desrt> see also: proprietary gstreamer plugins
[10:01] <Burgwork> desrt, indeed
[10:01] <Burgwork> should I be worried when our chief developer has no idea about the license of a significant chunk of code the company has written?
[10:02] <Lure> Burgwork: yes
[10:05] <Burgwork> I want to work for a sane company!
[10:05] <Nafallo> Burgwork: glhf :-)
[10:05] <Burgwork> Nafallo, glhf?
[10:05] <Kamion> hmm, maybe it's just me, but you're brave saying all this in a public channel whose logs are on the web
[10:06] <Burgwork> Kamion, I realize that
[10:06] <Nafallo> yes. good luck, have fun. in the sense of finding one that is :-)
[10:17] <neuralis> is anyone who can correct posts on the fridge present?
[10:18] <simira> neuralis: try #ubuntu-fridge ?
[10:23] <bluefoxicy> doko:  are you here
[10:23] <bluefoxicy> nope he's not
[10:23] <bluefoxicy> I'm gonna go vote, brb.
[10:30] <SlicerDicer-> who or where would I talk to find out information about ubiguity?
[10:30] <SlicerDicer-> I want to do some modifications
[10:33] <Burgwork> SlicerDicer-, Kamion is the person you need to talk to
[10:35] <SlicerDicer-> Burgwork: thanks
[10:35] <Burgwork> SlicerDicer-, what are you planning?
[10:35] <Burgwork> SlicerDicer-, we are past feature freeze for edgy, so stuff would be edgy+1 stuff
[10:36] <SlicerDicer-> well I want to modify it to lay out the disks differnetly by default, user creation etc
[10:36] <SlicerDicer-> custom livecd
[10:37] <SlicerDicer-> I doubt what I would do would ever make it into a release but what I am going to use it for would be extremely useful for what I am wanting to do anyway
[10:48] <pitti> Mithrandir: ok to upload a mailman security update to edgy?
[10:48] <Mithrandir> pitti: that's not on the CDs is it?
[10:49] <pitti> no, I don't believe so; I can check
[10:49] <Nafallo> if you're building server that is...
[10:49] <Mithrandir> Nafallo: we are
[10:49] <pitti> Mithrandir: yeah, what Nafallo says; it's not on the desktop/alternate CDs
[10:50] <administrator> Kamion: may i pm you?
[10:50] <Mithrandir> pitti: ok, upload away.
[10:50] <pitti> Mithrandir: it's a remote DoS, not *terribly* urgent, but trivial to exploit
[10:50] <pitti> alright, thanks
[10:50] <ogra> Mithrandir, can i have a general exception for edubuntu-artwork ?
[10:50] <bluefoxicy> Anyone else handle toolchain besides doko?
[10:51] <ogra> so i dont need to ask if i work until 5am :)
[10:51] <Mithrandir> ogra: sure.  It's edubuntu and nothing else which breaks, which makes me slightly less worried. :-)
[10:52] <ogra> right
[10:52] <ogra> :)
[10:52] <Nafallo> hehe
[11:02] <Lathiat> pitti: ping?
[11:02] <pitti> Lathiat: hello
[11:02] <Lathiat> pitti: hrm nevermind figured out i needed to scroll down further to find universe in cve/unfixed :)
[11:03] <pitti> pygi: me too, sometimes :)
[11:03] <pygi> pitti, it refuses to do what it's supposed to do :P
[11:03] <pygi> I want scons back :)
[11:03] <pitti> pygi: why don't you use scons?
[11:04] <pygi> pitti, because this is a system library, and I don't want to impose need of python on such a library for building system
[11:05] <pitti> pygi: don't you have python bindings anyway?
[11:06] <pygi> pitti, well, will do, yes, but that'll be as separate build
[11:13] <mdz> pitti,imbrandon: I saw that in bug 58164 there was a misunderstanding about the security process for universe.  what do you think we can do to improve awareness of the policy there?
[11:13] <Ubugtu> Malone bug 58164 in dapper-backports "firestarter backport" [High,Rejected]  http://launchpad.net/bugs/58164
[11:16] <pitti> mdz: FYI, I filed bug 60135 for keeping track of the nvidia/usplash bug and sub'ed you
[11:16] <Ubugtu> Malone bug 60135 in usplash "does not work at all on amd64 with nvidia card" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60135
[11:16] <pitti> mdz: our policy with that has been fairly consistent, but not documented, I believe
[11:16] <pitti> mdz: I'd add it to SecurityUpdateProcedures
[11:16] <mdz> pitti: please do, thanks. is that linked from DeveloperResources?
[11:17] <pitti> yes, it is
[11:17] <pitti> if appropriate, I'll also add a note there
[11:17] <imbrandon> mdz, i think alot of that has to do with they ( jdong in this case ) dont know where to poke -security updates 
[11:18] <imbrandon> pitti, yea +1 , i think that would solve it
[11:18] <pitti> imbrandon: well, 'poking' doesn't fit here
[11:18] <pitti> I usually know which stuff is outstanding in universe
[11:18] <pitti> but I can't possibly fix them all
[11:18] <mdz> imbrandon: did you find SecurityUpdateProcedures when looking?  if so, updating that would likely solve it
[11:18] <mdz> imbrandon: if not, tell us where you looked and maybe it needs more links
[11:19] <imbrandon> i dident look as i knew the proceedure, that was filed by jdong and i commented on that it dident belong in -backports as backports isnt on by default
[11:19] <imbrandon> and pointed jdong to pitti
[11:20] <imbrandon> but a standard wiki would be nice to point and future occurances , as security fixes get requested in -backports quite a bit
[11:20] <imbrandon> s/point/point to/
[11:24] <ogra> pitti, g-v-m is never happy with me removing my usbdisk :/
[11:24] <pitti> ogra: even if you unmount it before pulling out?
[11:25] <ogra> seems it doesnt like ext3 formatted devices and even complains if i eject properly
[11:26] <pitti> mdz, imbrandon: I added a stanza to https://wiki.ubuntu.com/SecurityUpdateProcedures (language fixes appreciated)
[11:26] <ogra> at least i guess its caused by ext3
[11:26] <pitti> ogra: I'll try to reproduce that with ext3
[11:27] <ogra> ok
[11:27] <ogra> i cant dig further now (knot3 test ahead) but tomorrow 
[11:30] <pitti> ogra: I can reproduce it, thanks for pointing this out
[11:30] <ogra> ok ...
[11:30] <ogra> i'm off for knot testing ... bbl
[11:31] <Nafallo> knot already? :-)
[11:31] <mdz> pitti: I simplified it a bit, please review
[11:31] <imbrandon> pitti, thanks
[11:32] <pitti> mdz: sounds much smoother, thanks
[11:32] <LaserJock> we should replace python2.4 deps, correct?
[11:33] <pitti> 'Updates prepared directly by the security team should be peer-reviewed.' *cough*
[11:33] <bddebian> SHould be python policy :)
[11:34] <LaserJock> bddebian: mhm
[11:34] <ajmitch> pitti: yes, I have a universe update to get to you soon :)
[11:34] <ajmitch> and I still have to sort out libgphoto2 after knot3 
[11:34] <pitti> yay, I don't need a visa for the US
[11:35] <imbrandon> pitti, looks great thanks
[11:35] <pitti> cool
[11:39] <yveslu> hi, any plans to get fontconfig 2.4 into edgy? it should improve perf. and reduce memory usage
[11:40] <sladen> yveslu: we're in FeatureFreeze, and long in UpstreamVersion Freeze
[11:42] <pitti> hi zul
[11:42] <yveslu> sladen: it's a pity... btw it has been packaged for debian experimental and these packages seem to run fine in sid. 2.4 is also abi and api compatible to 2.3
[11:42] <Burgwork> yveslu, the issue more is getting enough testing this late in the freeze
[11:43] <yveslu> ok... just wanted to ask and share my experience with sid. they will surely end up in edgy+1 though... :)
[11:43] <yveslu> sladen: fyi http://fontconfig.org/wiki/2_2e4_20release_20notes
[11:58] <ogra> hmm
[12:05] <ogra> nixternal, so you see it on ubuntu as well ? 
[12:05] <nixternal> on kubuntu i did with the latest
[12:05] <nixternal> as well as ubuntu
[12:05] <Burgwork> ogra, I saw somebody mentioning that a day or so ago, with ubuntu alt
[12:05] <nixternal> and edubuntu yes
[12:05] <ogra> ok
[12:05] <nixternal> and xubuntu on my lappy
[12:06] <ogra> then i'm fine ... i thought i broke the seeds or something :)
[12:06] <ogra> intrestingly it mentions 2.6.17-7-* in all seeds here
[12:06] <nixternal> my lcd does not like the new ubuntu splash
[12:07] <sladen> nixternal: nvidia drivers?  external flatscreen?
[12:07] <nixternal> yes and yes