[12:31] <terlmann> Is Michael Vogt(michael.vogt@ubuntu.com) here ?
[12:32] <jdong> terlmann: that's nickname mvo, and he is not here right now
[12:34] <terlmann> yea,what would you guys think about a new package managment system(frontend+core) for debian ubuntu 6+1? and how about naming it "Stymie"?
[12:42] <terlmann> What would you guys think about a new package managment system(frontend+core) for debian ubuntu 6+1? and how about naming it "Stymie"?
[12:44] <Chipzz> terlmann: there allready is talk about using smart
[12:44] <Chipzz> terlmann: and michael vogt is here during the day
[12:45] <terlmann> could it be named Stymie?
[12:45] <terlmann> It is the "day" here.
[12:45] <Chipzz> no?
[12:46] <Chipzz> why would you get to name something other people created?
[12:47] <Chipzz> it's 0:46 here; he will be here in aproximately little over 8 hours
[12:47] <Chipzz> and his nick is mvo
[12:49] <terlmann> No,just it would be a better name than spmngr or spmanager or spm. stymie update && stymie dist-update .... it starts with s ... like spm ... and like synaptic... but better name ,don't you think? I did ask vogt to take a look at it.
[12:49] <terlmann> I have created a launchpad page.
[12:51] <terlmann> Apt & it's Gui frontend,Synaptic, were GREEEAATT for their time,but no more.with the size of files & the number of downloads worldwide,a new system needs to be used.something that can pause& resume updating.
[12:51] <terlmann> something that more efficiently handles the need for servers to be nearby,decreasing download times.something that might be called Stymie .
[12:51] <shackan> people don't care about names
[12:52] <Chipzz> terlmann: you DO realize apt can pause and resume updating?
[12:52] <Chipzz> and you DO realize that you can use <country-code>.archive.ubuntu.com ?
[12:54] <Chipzz> apt-get update ; apt-get upgrade -y ... ctrl-c ... apt-get upgrade -y
[12:55] <Chipzz> I know that's a poor mans solution to pausing
[12:55] <terlmann> it is.and it is command line only.
[12:55] <Chipzz> but there is really fundamentally little that does prevent apt pausing
[12:55] <Chipzz> 00:51 < terlmann> Apt & it's Gui frontend,Synaptic
[12:55] <Chipzz> 00:55 < terlmann> it is.and it is command line only.
[12:55] <Chipzz> ? :P
[12:56] <Chipzz> no matter
[12:56] <Chipzz> you also do realize that you can have apt download the files in the background?
[12:56] <Chipzz> and that when you disconnect, it is possible to resume that download?
[12:57] <Chipzz> (well actually update-manager does that)
 apt-get update ; apt-get upgrade -y ... ctrl-c ... apt-get upgrade -y 
[12:57] <terlmann> ?
[12:58] <Chipzz> mvo would probably have a few reasons why apt is bad
[12:58] <Chipzz> but I can't see your arguments being good ones
[12:59] <theine> Hi, which wiki engine does http://wiki.ubuntu.com actually use? And would that engine be in main?
[01:00] <Mithrandir> theine: moin and yes.
[01:00] <theine> Mithrandir: What package is this?
[01:01] <Chipzz> python-moinmoin - Python clone of WikiWiki - dummy library package
[01:01] <Chipzz> ?
[01:01] <Chipzz> just a wild guess
[01:01] <Mithrandir> soudns right
[01:01] <Mithrandir> anyway, I'm off to bed.
[01:01] <theine> the "dummy library part" irritated me a bit
[01:01] <Chipzz> theine: try apt-cache search moin ?
[01:02] <Nafallo> s/search/show/
[01:02] <theine> yes, it seems there are pretty much only library packages related to moin in main
[01:02] <Chipzz> Nafallo: no, search
[01:03] <Chipzz> root@Reel:~# apt-cache show moin
[01:03] <Chipzz> root@Reel:~#
[01:03] <Nafallo> ah. python2.4-moinmoin
[01:04] <Nafallo> and moinmoin-common ;-)
[01:11] <terlmann> apt is only a native command line app,like yum. the .deb spec is what makes it better.
[01:34] <Chipzz> terlmann: heh?
[01:35] <Chipzz> I would say rather the contrary, that deb as a package format is inferior to rpm
[01:39] <HrdwrBoB> Chipzz: that's a pointless thing to say
[01:40] <HrdwrBoB> and not on topic for this channel anyway
[01:45] <Chipzz> HrdwrBoB: maybe I understood him incorrectly, but he seemed to be arguing for .deb as a package format:
[01:45] <Chipzz> 01:11 < terlmann> apt is only a native command line app,like yum. the .deb spec is what makes it better.
[01:46] <terlmann> hah.chipz,.deb beats .rpm hands down. and yum itself sucks compared to apt.but you just want to argue.not promote creative thinking.Am I right? (of course I am right |his kind always says that "it really can""but there is really fundamentally little that does prevent"and "you also do realize".this argument is over.we need a new revolution to keep the thoughts going around and around.so you do it.and I wont complain.only if it is n
[01:46] <Chipzz> terlmann: no, you are just plain clueless
[01:46] <terlmann> you are clueless.
[01:46] <HrdwrBoB> rpm is a very good format, it's POLICY that makes deb packages good
[01:46] <Chipzz> terlmann: I did over 2 years of packaging rpm's. go fuck yourself or something
[01:47] <ajmitch> Chipzz, terlmann: stop the bickering now
[01:47] <Chipzz> I do know what I am talking about
[01:47] <Chipzz> ajmitch: yeah, probably should do that
[01:50] <terlmann> so do i. I have rpm'd. It is policy. I AM NOT DENYING THAT! .deb DOES that,rpm doesnt.period.so go code.or something.
[01:51] <zul> mind taking it to offtopic
[01:51] <terlmann> sure.
[01:52] <terlmann> whats the name?
[01:52] <terlmann> ubuntu-offtopic?
[01:53] <terlmann> (and this problem is ubuntu development orientated,mind you.)
[01:53] <zul> not directly
[02:14] <Chipzz> what is the component to look for bugs for the rebuilding of a package?
[02:14] <Chipzz> "archive" or something?
[02:15] <Chipzz> rebuilding -> syncing
[02:15] <infinity> sync bugs should be filed against the package in question, and ubuntu-archive should be subscribed to the bug.
[02:16] <infinity> Chipzz: https://wiki.ubuntu.com/DeveloperResources <-- See the "Syncs" section.
[02:17] <Chipzz> infinity: I'm not a developer myself; I guess I can't subscribe ubuntu-archive?
[02:18] <infinity> Anyone can.
[02:18] <infinity> But if you aren't going to check the package thoroughly (ie: if you're not prepared to go through the process listed on DeveloperResources), you should get a developer to poke through it and then do the sync request.
[02:20] <Chipzz> infinity: I'm not 100% sure a sync request is what's needed, but quite sure though
[02:20] <infinity> If not 100% sure, then don't subscribe us, file the bug and get someone else to look at it first.
[02:20] <Chipzz> infinity: mythtv got synced to version 0.20, while mythplugins is still at 0.18
[02:20] <Chipzz> I think that would qualify, no?>
[02:21] <infinity> That would need a UVF exception as well.  Best to talk to #ubuntu-motu about it.
[02:21] <infinity> But it's probably a no-brainer.
[02:21] <Chipzz> mythplugins is useless as is now
[02:22] <tseng> you're appealing to the wrong guy
[02:22] <Chipzz> should I just go ahead and subscribe ubuntu-archive?
[02:22] <tseng> no.
[02:22] <tseng> you need dholbach, slomo, or siretart (pick 2) to approve it
[02:22] <crimsun> please complete bug 61332
[02:22] <Ubugtu> Malone bug 61332 in mythplugins "Needs a sync for mythtv 0.20" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61332
[02:23] <Chipzz> crimsun: that's exactly the bug I just filed, and which I'm arguing about weither I should subscribe ubuntu-archive or not
[02:23] <Chipzz> crimsun: what additional info is needed?
[02:24] <crimsun> see https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-August/000181.html
[02:26] <Chipzz> crimsun: I lack the needed information, though I guess I can find it by digging around a bit; shall I do that, or let the maintainer complete it?
[02:27] <crimsun> Chipzz: generally it's quite helpful to provide all the relevant information up front.
[02:28] <infinity> crimsun: Tell me that you know the ruby codebase inside out and backwards.
[02:28] <infinity> crimsun: Even if it's a lie, tell me that anyway, so I can offload something on you. :P
[02:28] <Chipzz> crimsun: I would agree; but the reason I filed this bug is more as a reminder to the maintainer, as I'm sure he is aware that mythtv needs to stay in sync with mythplugins
[02:28] <Chipzz> unless that package doesn't have a maintainer in ubuntu and just gets synced blindly
[02:29] <crimsun> infinity: I'm trying to decrease my misery, not increase it
[02:29] <infinity> crimsun: Damn.  I just wanted to ping "ruby1.8 is broken on ppc64" on you, since it's causing one of your uploads (ruby-gnome2) to FTBFS on powerpc. :)
[02:30] <infinity> s/ping/pin/
[02:30] <crimsun> hmm, I think Lucas sent an e-mail about that
[02:31] <slomo> infinity: did you see what i've written about apache2-dev? :)
[02:31] <infinity> slomo: yeah, someone synced apache1.3 without me noticing, so apache-dev and apache2-dev aren't co-installable anymore.  I'll fix it.
[02:31] <crimsun> [https://lists.ubuntu.com/archives/ubuntu-devel/2006-September/020769.html] 
[02:32] <infinity> Yeah, I know.  The reason it "builds fin in Debian" is because the Debian powerpc buildd is a 32-bit system.
[02:32] <slomo> infinity: thanks... just give-back mod-mono afterwards :) and we probably need a buildd only for openoffice :P i hate always waiting for other stuff to finish for > 12 hours ;)
[02:32] <infinity> slomo: You and me both. :/
[02:33] <infinity> "doko upload days" make me sad.
[02:35] <Chipzz> crimsun: any better now?
[02:35] <crimsun> Chipzz: sure.
[02:35] <crimsun> I'll do the grunt work, then.
[02:36] <Chipzz> that's as much information as I have
[02:36] <Chipzz> without rebuilding it myself
[02:36] <Chipzz> which I can do, if you want
[02:36] <crimsun> that would be helpful, yes.
[02:36] <Chipzz> but that would be something for tomorrow then
[02:37] <Chipzz> allright with you?
[02:37] <crimsun> sure
[02:38] <Chipzz> thx for the instructions crimsun :)
[02:39] <doko_> infinity: http://librarian.launchpad.net/4315512/buildlog_ubuntu-dapper-powerpc.openoffice.org_2.0.3-6dapper3_FAILEDTOBUILD.txt.gz
[02:40] <infinity> doko_: Ugh.  Will fix.
[02:41] <infinity> /dev/md0               74G   48G   27G  65% /srv
[02:41] <infinity> No space, my ass.
[02:41] <infinity> Oh, wait.
[02:41] <infinity> That's not royal, I'm retarded.
[02:42] <doko_> I'm currently clueless for the sparc fai?ure 
[02:53] <jdub> man
[02:53] <jdub> server bootups are pretty surreal now
[02:54] <jdub> grub spew... (minor initramfs spew, won't be there forever)... login:
[02:54] <Gman> almost like you were running solaris...
[02:55] <mjg59> Nngh grah kernel
[02:55] <jdub> Gman: more like AIX with the console font we're using
[02:55] <Gman> :)
[02:56] <jdong> oh god, a new dbus update... will my hotplugging break this time? :)
[02:57] <mjg59> jdub: It's *bad*, isn't it?
[02:57] <jdub> mjg59: i quite like it 8)
[02:57] <mjg59> Hm.
[02:57] <mjg59> So.
[02:57] <mjg59> If I hack out one line, the kernel boots
[02:57] <mjg59> But
[02:57] <jdub> i guess the only problem with it is that it's not as contrasty as the previous one
[02:57] <mjg59> The code is identical on amd64, and that one boots /with/ that line
[02:58] <slomo> jdong: i doubt it ;)
[02:58] <jdong> slomo: oh, but you know my luck with dbus recently :)
[02:58] <jdong> slomo: my bugs tend not to be reproducable by anyone else
[02:59] <jdong> like mjg59, you were there yesterday when I said ubiquity bombs out in knot 3 amd64, right?
[02:59] <jdong> I can't get it to happen again
[03:00] <jdong> I just tried for a good hour
[03:01] <mjg59> CMOS_WRITE(save_control | RTC_PIE, RTC_CONTROL);
[03:01] <mjg59> I wonder what this actually /does/
[03:03] <jdub> maybe going greenscreen would help with the console font contrast issues
[03:04] <infinity> doko_: powerpc rescued.
[03:05] <infinity> doko_: Want me to retry sparc to see if that ICE was cosmic rays?
[03:05] <mjg59> Any old-school x86 people around?
[03:11] <bddebian> Howdy
[03:12] <LaserJock> old-school?
[03:13] <bddebian> old-school?
[03:14] <jdong> bddebian: <mjg59> Any old-school x86 people around?
[03:14] <jdong> before you hopped in
[03:15] <bddebian> Ah
[03:15] <bddebian> I'm just old, not "old-school" :-(
[03:15] <mjg59> LaserJock: As in, knows what writing to various bits of hardware actually /does/
[03:16] <bddebian> stuff? :)
[03:16] <mjg59> Oh man
[03:16] <mjg59> This is totally unfair
[03:16] <mjg59> Upstream kernel works fine
[03:18] <ajmitch> mjg59: that console font we use has a certain style, really.. :)
[03:18] <zul> mjg59: what borked?
[03:19] <mjg59> zul: unlock_ExtINT_logic on x86 is broken
[03:19] <mjg59> in arch/i386/kernel/io_apic.c
[03:19] <zul> ah ok
[03:19] <mjg59> Hangs when it hits CMOS_WRITE(save_control | RTC_PIE, RTC_CONTROL);
[03:20] <bddebian> apic is just broken in general :-)
[03:20] <mjg59> Yeah, utterly unlike xtpic
[03:20] <mjg59> Oh, no, wait
[03:21] <zul> mjg59: something to do with the real time clock?
[03:21] <mjg59> zul: Yeah
[03:21] <zul> edgy right?
[03:21] <mjg59> Yup
[03:25] <zul> well according to rtc.h RTC_PIE is the periodic interrupt enable
[03:25] <mjg59> yeah
[03:26] <mjg59> But why would enabling that instantly hang the machine?
[03:26] <zul> no idea
[03:27] <bddebian> Heya Hobbsee
[03:28] <mjg59> Bastard.
[03:29] <Hobbsee> hey bddebian 
[03:29] <Hobbsee> mjg59: what's happened?
[03:29] <mjg59> Narrowed down to one of two lines, neither of which looks obviously wrong
[03:30] <ajmitch> hello Hobbsee 
[03:30] <Hobbsee> hey ajmitch 
[03:35] <mjg59> Ooooooooooooooooooooooooooh
[03:35] <mjg59> I see
[03:38] <Keybuk> OUTER SPACE
[03:40] <mjg59> Now that is *really* odd
[03:41] <mjg59> I can find the a git commit with that line and one without
[03:41] <mjg59> But I can't find the commit that added it
[03:41] <zul> have you tried in linus's tree?
[03:41] <mjg59> Oh, no, here it is
[03:42] <mjg59> No...
[03:43] <mjg59> Sigh.
[03:43] <mjg59> Dunno where it came from, but I'll send the fix
[03:45] <mjg59> desrt: Around?
[03:46] <AlinuxOS> Hehe Great: http://www.alinux.netsons.org/wp-content/writer.jpeg For first time here it is Georgian OO.org ;)
[03:46] <AlinuxOS> http://www.alinux.netsons.org/wp-content/calc.jpeg  ;)
[03:46] <AlinuxOS> http://www.alinux.netsons.org/wp-content/base.jpeg
[03:47] <AlinuxOS> http://www.alinux.netsons.org/wp-content/impress.jpeg
[03:47] <AlinuxOS> yuppy!
[03:47] <LaserJock> wow, quite cool
[03:47] <AlinuxOS> LaserJock, ;) Yeah!
[03:48] <LaserJock> I've never seen Georgian before
[03:49] <mjg59> No, seriously, this is mad
[03:49] <mjg59> I genuinely can't work out where this line came from
[03:50] <mjg59> Oh, I see
[03:51] <mjg59> Still can't work out where it is in git, but still
[03:51] <mjg59> I think I'm getting confused by how gitweb represents merging
[03:51] <jdong> mjg59's state of enlightment can be modeled using a sine wave....
[03:52] <AlinuxOS> LaserJock, hehe Ubuntu is the first distribution that supports it ;)
[03:53] <AlinuxOS> http://ka.wikipedia.org/wiki/%E1%83%9A%E1%83%98%E1%83%9C%E1%83%A3%E1%83%A5%E1%83%A1%E1%83%98%E1%83%A1_%E1%83%93%E1%83%98%E1%83%A1%E1%83%A2%E1%83%A0%E1%83%98%E1%83%91%E1%83%A3%E1%83%A2%E1%83%98%E1%83%95%E1%83%94%E1%83%91%E1%83%98#Ubuntu_Linux
[03:53] <AlinuxOS> LaserJock, some other screenshots.
[03:53] <AlinuxOS> + Info of course in Georgian.
[03:54] <jdong> AlinuxOS: if I saw that URL in my apache logs, I'd issue out an IP ban ;-)
[03:54] <jdong> j/k
[03:54] <AlinuxOS> jdong, :)
[03:55] <mjg59> Yay I win
[03:55] <bluefoxicy> oh
[03:55] <jdong> note to self: mjg59 wins
[03:55] <bluefoxicy> georgian is some kind of hebrew, ok
[03:56] <AlinuxOS> bluefoxicy, :) Not at all ;) It's Caucasian language with non Indoeuropean roots.
[03:56] <jdong> so it's nobrew of hebrew?
[03:56] <LaserJock> haha
[03:56] <bluefoxicy> AlinuxOS:  yes but my point was I thought you meant Georgian == Georgia
[03:56] <bddebian> yuck yuck
[03:57] <bluefoxicy> I expected something like Redneck in BzFlag :P
[03:57] <LaserJock> Georgia is a country too bluefoxicy 
[03:57] <bluefoxicy> I did not know that
[03:57] <bluefoxicy> I'm american, I don't care about the rest of the world wtf?  :P
[03:57] <AlinuxOS> bluefoxicy, I don't really know what you are talking about :) I don't have 3d support on my computer :) So I can't play :)
[03:58] <bluefoxicy> ah
[03:58] <bluefoxicy> I'll find a screen
[03:58] <AlinuxOS> bluefoxicy, Rep. Georgia.
[03:58] <LaserJock> I'm american too but I remember a little from my college geography class ;-)
[03:58] <LaserJock> and that isn't Representative Georgia either bluefoxicy ;-)
[03:59] <bluefoxicy> haha
[04:00] <AlinuxOS>   Here you are, a georgian complete modern alphabet :)
[04:01] <AlinuxOS> we are small population, only 4 milions :)
[04:01] <bluefoxicy> ah, that's like my state
[04:01] <mjg59> Keybuk: Uhm.
[04:01] <AlinuxOS> So it's normal that someone donn't knows about :)
[04:01] <mjg59> Keybuk: As far as I can tell, current behaviour with usplash is to switch to vt 1, see the font change and then switch to gdm
[04:01] <mjg59> Keybuk: I thought you said that had been fixed?
[04:02] <bluefoxicy> mjg59:  is there a mode that makes Ubuntu display random cryptic messages during boot?
[04:02] <AlinuxOS> And mjg59 :) Is a first Georgian font packager :p
[04:02] <bluefoxicy> mjg59:  Smoothing landscape, rheticulating splines, etc
[04:02] <Keybuk> mjg59: I think it still does that, yes
[04:03] <Keybuk> don't think it switches to vt1 though?
[04:03] <bluefoxicy> </simcity 2000)
[04:03] <mjg59> Keybuk: That's why the clear statement was there
[04:04] <Keybuk> right, but that clear statement clears whatever is on vt1 :p
[04:04] <Keybuk> ie. getty
[04:04] <Keybuk> why does it switch at all?
[04:04] <mjg59> Keybuk: Because it's been asked to quit
[04:04] <mjg59> And because you can't set the console font when the VT is in graphics mode
[04:04] <Keybuk> looking at the current init script, it only switches to vt1 after it's set up the font
[04:05] <Keybuk> assumedly to put it on the console with the getty in case gdm doesn't start
[04:05] <mjg59> The font can't be set until usplash has exited
[04:05] <Keybuk> right
[04:05] <Keybuk> look at the init script
[04:05] <Keybuk> I have 0.4-25 here
[04:06] <Keybuk> it does usplash_write QUIT, loops until usplash's pid vanishes, then calls setupcon ($CONSOLE_SCREEN) and only then does it switch to vt1 if the fgconsole is 8
[04:06] <Keybuk> you don't need to be on vt1 to change the font, just a text vt (which it is, because usplash has quit)
[04:06] <mjg59> Keybuk: So usplash is asked to quit, and in the process changes to vt 1
[04:06] <mjg59> Because that's the behaviour we generally want
[04:07] <mjg59> Where "vt 1" is actually "whatever vt it started on"
[04:07] <mjg59> s/it/it was/
[04:07] <Keybuk> ah
[04:07] <Keybuk> usplash doesn't change to vt 1 when it quits ;)
[04:07] <Keybuk> should delete that code really, it's a total no-op
[04:09] <Keybuk> switch_console () doesn't work in usplash
[04:09] <mjg59> Keybuk: Mm?
[04:09] <Keybuk> for one very good reason
[04:09] <Keybuk> it opens /dev/tty1 ... which doesn't exit
[04:09] <Keybuk> uh, exist
[04:09] <mjg59> In what way "doesn't exist"?
[04:09] <Keybuk> usplash is run from the initramfs
[04:09] <Keybuk> in the namespace of the initramfs
[04:09] <mjg59> Yes
[04:09] <Keybuk> /dev in the initramfs is a tmpfs that is moved to the real root filesystem
[04:09] <Keybuk> at which point it briefly exists as /root/dev/...
[04:10] <Keybuk> before the initramfs is recursively deleted to free up memory
[04:10] <mjg59> Oh
[04:10] <Keybuk> so when usplash does it's final switch_console (saved_vt) thingy
[04:10] <Keybuk> it actually does sod all, because open returns ENOENT :p
[04:10] <mjg59> So what you mean is "switch_console() doesn't work after initramfs has gone away"
[04:10] <Keybuk> right
[04:10] <mjg59> Rather than "switch_console() doesn't work"
[04:11] <Keybuk> so nothing switches to vt1 before the console is setup
[04:11] <Keybuk> and this doesn't matter
[04:11] <mjg59> Keybuk: Except that I end up on vt 1 before the console is setup
[04:11] <Keybuk> at the point the font is changed, the current tty is tty8 (usplash's), but usplash has quit and reverted that console to text mode
[04:11] <Keybuk> so setupcon works fine
[04:11] <Keybuk> mjg59: you see the font change?
[04:12] <mjg59> 03:01 < mjg59> Keybuk: As far as I can tell, current behaviour with usplash is  to switch to vt 1, see the font change and then switch to gdm
[04:12] <Keybuk> that surprises me
[04:12] <Keybuk> where is the "switch to vt1" coming from?
[04:13] <mjg59> Just let me make sure I'm running the latst version of all this sutff
[04:13] <Keybuk> (there'd actually be a terrible race if that code worked, btw ... people with fast machines would have usplash switch *away* from gdm, no?
[04:14] <mjg59> No
[04:14] <Keybuk> why not?
[04:14] <mjg59> gdm wouldn't be able to change until usplash had released the lock
[04:14] <Keybuk> what lock?
[04:14] <mjg59> The vt switching madness
[04:14] <mjg59> It's handled inside bogl or svgalib, depending
[04:14] <Keybuk> except gdm does switch away, no?
[04:14] <Keybuk> otherwise gdm wouldn't appear until the end of the boot process
[04:14] <Keybuk> and it definitely appears long before that
[04:14] <mjg59> Only after usplash has shut itself down
[04:15] <Keybuk> how does usplash know to shut itself down?
[04:15] <mjg59> Either the quit or the vt switch request
[04:15] <Keybuk> ah, it gets a signal when gdm causes the vt to switch?
[04:15] <mjg59> Yes
[04:15] <Keybuk> right
[04:15] <Keybuk> where is that code?
[04:15] <Keybuk> I can't see it
[04:15] <Keybuk> the only signal it appears to act on is SIGALRM
[04:16] <Keybuk> inside bogl I guess?
[04:16] <mjg59> In either bogl or svgalib
[04:16] <mjg59> Yeah
[04:16] <mjg59> You don't really want to go there unless you need to
[04:16] <mjg59> Ok
[04:16] <mjg59> Hm
[04:16] <mjg59> That's interesting
[04:16] <Keybuk> and that causes usplash to exit without switching the console back?
[04:16] <Keybuk> (the interesting thing, of course, is that setupcon *must* work with a graphical tty, because it works just fine underneath X :p)
[04:17] <mjg59> Keybuk: The kernel doesn't allow that
[04:17] <mjg59> Hm.
[04:17] <mjg59> so now I'm not seeing the font change, but I *am* seeing VT 1
[04:18] <Keybuk> doesn't allow which?
[04:18] <mjg59> Keybuk: Changing the console font
[04:18] <Keybuk> it must do ...
[04:18] <Keybuk> my console font is changed, and at no point do I see VT 1 during boot
[04:18] <mjg59> Then conceivably it's doing it to vt 8
[04:19] <mjg59> Nope, just saw the font change again
[04:19] <Keybuk> oh, hmm, maybe I do see the font change
[04:19] <Keybuk> it's just so fast that it's almost subliminal
[04:20] <Keybuk> it's as gdm starts
[04:20] <mjg59> Yes
[04:20] <Keybuk> ahh
[04:20] <Keybuk> gdm's init script runs the usplash init script!
[04:20] <Keybuk> which calls setupcon;chvt 1
[04:20] <mjg59> But we're on vt 1 before setupcon completes itself
[04:21] <mjg59> Otherwise there'd be no visible change
[04:21] <Keybuk> maybe setupcon isn't immediate?
[04:21] <Keybuk> I remember Colin saying it forks off processes to do stuff
[04:21] <Keybuk> if it doesn't wait() on those, it's entirely possible that setupcon exits before the font is properly set
[04:24] <Keybuk> ah, it's just a shell script
[04:24] <mjg59> Keybuk: static int con_font_set(struct vc_data *vc, struct console_font_op *op)
[04:24] <mjg59>         if (vc->vc_mode != KD_TEXT)
[04:24] <mjg59>                 return -EINVAL;
[04:24] <Keybuk> mjg59: ok, I believe you :p
[04:25] <mjg59> I've had this argument with Otavio after he bitched to Newsforge about usplash "fixing things the wrong way"
[04:25] <Keybuk> surely that's not the current vt though, but any specified vt?
[04:25] <Keybuk> there must be code like
[04:25] <mjg59> Keybuk: Give me a sec
[04:27] <mjg59> Hm.
[04:27] <mjg59> Maybe that /does/ work
[04:27] <mjg59> Oh, no
[04:27] <mjg59> Keybuk: Doing so corrupts X
[04:28] <mjg59> Actually, that's something of a point
[04:28] <mjg59> /something/ is corrupting usplash around the time that gdm starts
[04:30] <Keybuk> for (i = 1; i < 10; i++)  con_font_set (vt(i), ...)
[04:31] <Keybuk> ie call con_font_set on all the vts
[04:31] <Keybuk> or is the vt always the process-current vt?
[04:31] <Keybuk> or is the vt always the kernel-current vt?
[04:31] <Keybuk> (mmm.... vts are so complicated)
[04:32] <Keybuk> X gets corrupted by a lot of things :)  never call TIOCSCTTY on /dev/console when X is running
[04:32] <Keybuk> for some unknown reason, it gets upset by that
[04:34] <mjg59> I have a feeling it might be the process-current vt
[04:34] <mjg59> But I'll check now
[04:40] <fabbione> morning guys
[04:40] <Hobbsee> hi fabbione 
[04:41] <ajmitch> hi fabbione 
[04:43] <Keybuk> morning fabio
[04:44] <mjg59> Keybuk: So the default behaviour of consolechars is to do it to the current vt, but it seems like it might work on others
[04:44] <Keybuk> that doesn't need to be vt 1 though?
[04:45] <Keybuk> when usplash exits is restores vt8 to be KD_TEXT, no?
[04:45] <mjg59> Should do, yeah
[04:45] <Keybuk> that's almost empty
[04:46] <Keybuk> if gdm's init script called "DO_NOT_SWITCH_vt=y usplash start" and that stopped the chvt, that'd probably stop the font change being shown
[04:46] <Keybuk> I imagine the only reason you see the font change is that it doesn't take effect immediately
[04:46] <Keybuk> I'm guessing here though
[04:47] <fabbione> Keybuk: hey dude
[04:47] <jdub> fabbione: reboot successful!
[04:47] <fabbione> jdub: score
[04:48] <jdub> fabbione: thanks :-)
[04:48] <fabbione> jdub: you should thanks Keybuk .. i only tested his fix and uploaded
[04:49] <jdub> Keybuk: thanks!
[04:49] <Keybuk> jdub: what did I unwittingly fix?
[04:49] <bddebian> heh
[04:49] <Keybuk> o/~ pia waugh / pia waugh / pia pia pia waugh
[04:49] <jdub> Keybuk: you gave fabbione a fix for md/uuid
[04:50] <Keybuk> so I did, aren't I clever?
[04:52] <Keybuk> when doing readahead testing, the last thing you want is a laptop that doesn't reboot properly because it powers itself off
[04:52] <Keybuk> NEVER BUY A LAPTOP WITH AN ATI CHIPSET
[04:56] <fabbione> humpf.. waking up at 4am isn't exactly love
[04:56] <bddebian> heh
[04:57] <Keybuk> fabbione: depends how you're being woken up, I find
[04:58] <fabbione> Keybuk: by a very hungry screaming little boy :)
[04:58] <Keybuk> you've met David, right? :p
[04:58] <fabbione> yeps :)
[04:59] <Keybuk> is scary now, less than two weeks until he moves in
[04:59] <Keybuk> my batchelor-hood is in its final days
[04:59] <mjg59> Keybuk: So suspend now works on almost every machine. Except yours.
[05:00] <Keybuk> mjg59: *cry*
[05:00] <Keybuk> mjg59: could I have one of your spare laptops/ :p
[05:01] <mjg59> I thought you had a newer one now?
[05:01] <Keybuk> no, still the nc4010
[05:01] <Keybuk> have started saving for a new one, but will be a year before I can afford it
[05:08] <desrt> mjg59; or am i meant to see you here?
[05:09] <Keybuk> someone needs to beat up smurfix
[05:09] <Keybuk> it looks like he's got an autoresponder that replies to mailing list posts
[05:10] <Keybuk> To: 	ubuntu-devel@lists.ubuntu.com, Ubuntu Installer <archive@ubuntu.com>
[05:10] <Keybuk> is kinda worrying
[05:11] <Fujitsu> Keybuk, somewhat.
[05:11] <Fujitsu> I'm sure the archive is liking getting those responses :P
[05:12] <Keybuk> in fact
[05:12] <Keybuk> it looks like it's responding to edgy-changes mails!
[05:12] <Fujitsu> Terrific!
[05:13] <Fujitsu> Absolutely fantastic.
[05:13] <Keybuk> or perhaps dapper-changes
[05:13] <Fujitsu> archive actually has a mailbox?
[05:13] <Hobbsee> Fujitsu: sure, it points to /dev/null
[05:13] <Fujitsu> Ha. Ha.
[05:14] <Fujitsu> Heya Hobbsee.
[05:14] <Hobbsee> heya
[05:15] <Keybuk> Fujitsu: amusingly his responder appears to obey Reply-To
[05:15] <Keybuk> and is thus sending them to ubuntu-devel
[05:15] <Fujitsu> I noticed a couple of them appeared there.
[05:15] <mjg59> desrt: Can't remember. Did you try pristine upstream sources for your timing problem?
[05:16] <desrt> no
[05:16] <Fujitsu> It's somewhat silly of smurfix to do such things...
[05:16] <desrt> intuition tells me that it'll still be a problem though
[05:16] <mjg59> desrt: Can you try Ubuntu sources with the patch from 53910?
[05:16] <Keybuk> autoresponders don't, afaik, violate any RFC
[05:16] <Keybuk> they're just stupid
[05:16] <Fujitsu> Darn.
[05:16] <Fujitsu> It'd be nice if they did.
[05:16] <desrt> bug 53910
[05:16] <Ubugtu> Malone bug 53910 in linux-source-2.6.17 "Can't boot: mp-bios bug timer not connected to io-acp" [Untriaged,Fix committed]  http://launchpad.net/bugs/53910
[05:16] <mjg59> It won't actually fix things, but it might let you boot
[05:17] <mjg59> (well, fix the fundamental issues)
[05:17] <desrt> mjg59; NO
[05:17] <desrt> mjg59; no no no
[05:17] <desrt> wrong fix.
[05:17] <mjg59> desrt: In what way? That's what upstream actually looks like.
[05:18] <desrt> that's like taking the canary out of the cave because the damn thing keeps dieing
[05:18] <mjg59> The bogomips figure will be recalculated later on anyway
[05:18] <desrt> only for the other CPU
[05:18] <mjg59> But the fact that we had that code was a bug
[05:19] <desrt> so
[05:19] <desrt> we accept that it's ok to have delay loops that run 4x faster than they're supposed to
[05:19] <desrt> and we end up with really odd hardware driver bugs
[05:19] <desrt> but at least your system boots....
[05:20] <desrt> mjg59; that patch will definitely fix the symptom.  i had a patch like that in my kernel a month or two ago when i was trying to find the source of the problem
[05:20] <mjg59> desrt: As I said, that's what upstream looks like
[05:20] <mjg59> It's also what amd64 looks like
[05:21] <desrt> what patch did this come in with?
[05:21] <mjg59> An earlier fix for the ATI IGP200 chipsets defaulting to routing the timer interrupt via the 8259 and the APIC
[05:22] <desrt> well... kill it off if you like
[05:22] <mjg59> Well, it's dead
[05:22] <desrt> but we should probably also fix the problem
[05:22] <mjg59> Since it breaks the ATI systems
[05:22] <mjg59> And much as I'd like to break them, since they're really, really horrible...
[05:22] <ScreaminIke> i have a question... can i make a feature request from here?
[05:23] <desrt> mjg59; i thought the patch was introduced to _fix_ them :p
[05:23] <mjg59> desrt: It did, then they got fixed differently and we didn't revert the entirity of the patch
[05:23] <desrt> ok.
[05:23] <desrt> well
[05:24] <desrt> there are clearly places in the kernel that assume that a mdelay() and friends will correspond to jiffies in some way or another
[05:24] <mjg59> Yes
[05:24] <desrt> i think the atheros driver might be one of them
[05:24] <desrt> it used to randomly lock up my keyboard
[05:24] <mjg59> But
[05:25] <desrt> since i set the bogomips override it hasn't
[05:25] <mjg59> bogomips get recalculated when CPU frequency changes
[05:25] <desrt> so maybe we could force a step up/down on boot?
[05:25] <mjg59> Well, it's likely that it gets done when the cpufreq driver is loaded
[05:25] <Keybuk> I can never understand why you can't edit the BIOS options from VMware
[05:25] <Keybuk> and why you have to boot the damned vm to do it
[05:26] <desrt> mjg59; i always wondered how that worked
[05:26] <mjg59> But it would be interesting to see whether the calculation continues to have errors
[05:26] <mjg59> After booting
[05:26] <desrt> mjg59; you can see the log message for cpu#1 being calibrated
[05:26] <ScreaminIke> uhm... i don't know where else to air this... but i put in the edgy release today and did a dry run of the system install... and there is no option in the keyboard layouts for dvorak... can that be integrated?
[05:26] <desrt> mjg59; it always gets it right
[05:26] <desrt> it's just cpu0 that has the wrong value
[05:27] <mjg59> Yeah
[05:27] <desrt> so maybe by the time cpu1 comes up the system has gotten to a saner state
[05:27] <desrt> or maybe it's just that SMIs are always done on cpu0
[05:27] <mjg59> Well, SMM code will always run on CPU 0
[05:27] <desrt> well
[05:27] <mjg59> But I don't know if the rest of the system is blocked while that's happening
[05:27] <desrt> that doesn't make much sense to me
[05:28] <desrt> if an SMM is launched to emulate a port access then that has to happen on the CPU that initiated
[05:28] <mjg59> No, the southbridge just has to give back the value that the processor requested
[05:28] <desrt> so it executes the SMI on cpu0 while causing cpu1 to fly a holding pattern?
[05:28] <mjg59> That's what I'd assume, though it's always possible that cpu 1 carries on executing code
[05:29] <mjg59> I haven't checked the specs for that situation
[05:30] <desrt> oh.  execiting
[05:30] <desrt> bogomips are in /proc/cpuinfo
[05:30] <desrt> let's check this out
[05:31] <mjg59> Hm. Actually, maybe it just multiplies or divides the existing value.
[05:31] <mjg59> How irritating.
[05:31] <desrt> i think you're right
[05:31] <desrt> i bugged teh calibration routine to dump some info to me at KERN_CRIT
[05:31] <desrt> i see nothing
[05:31] <mjg59> Well, the calibration routines are __init
[05:31] <desrt> just the initial reading for each cpu
[05:32] <desrt> ya... that too
[05:32] <desrt> so either cpufreq reinvented the wheel as a better alternative to removing a couple of __init tags
[05:32] <desrt> or you're right
[05:32] <desrt> btw -- new console font looks really nice
[05:34] <desrt> i think SMIs run on CPU1
[05:34] <desrt> my reasoning is a bit handwavy but it goes as follows:
[05:34] <desrt> actually.  i retract my argument.  it doesn't work
[05:34] <desrt> nm.
[05:35] <desrt> in any case something slows CPU#1 down vs CPU#0
[05:36] <Keybuk> WHY is there a bootchart udeb!!
[05:36] <desrt> what is a udeb?
[05:36] <AlinuxOS> guys, I can't see my Ubuntu booting
[05:36] <Fujitsu> Why not, Keybuk?
[05:36] <mjg59> desrt: Microdeb
[05:36] <AlinuxOS> usplash dosen't work.
[05:36] <mjg59> Packages used in the installer
[05:37] <Fujitsu> !doesn't work
[05:37] <Fujitsu> Darn, no ubotu in here.
[05:37] <desrt> mjg59; maybe we can force recalibration after the bootup is in full swing or something
[05:37] <Fujitsu> AlinuxOS, what do you mean it doesn't work>
[05:37] <AlinuxOS> title           Ubuntu, kernel 2.6.15-25-686
[05:37] <AlinuxOS> root            (hd0,4)
[05:37] <AlinuxOS> kernel          /vmlinuz-2.6.15-25-686 root=UUID=295e49f4-e2ab-4b75-804e-e02a6e95e23e ro quiet splash vga=0x342
[05:37] <AlinuxOS> initrd          /initrd.img-2.6.15-25-686
[05:37] <AlinuxOS> savedefault
[05:37] <AlinuxOS> boot
[05:37] <Fujitsu> Please don't paste!
[05:37] <desrt> mjg59; but otherwise i think we should just detect the stupid ICH7 and kill off SMI_USB_EN during boot
[05:37] <AlinuxOS> Fujitsu, that I se somtimes green lines ;)
[05:38] <desrt> mjg59; as an alternative, we could encourage the upstream kernel guys to kill off the idea of bogomips
[05:38] <desrt> because, really, if you have a TSC, bogomips and approximate delay loops are just a really dumb idea
[05:39] <bluefoxicy> whoops
[05:39] <bluefoxicy> oopsed my kernel
[05:39] <AlinuxOS> Fujitsu, with Dapper usplash worked...but after upgrade I can't even switch in terminal mode.
[05:39] <bluefoxicy> by killall'ing apport while it was trying to collect data
[05:39] <AlinuxOS> Alt + F1
[05:39] <Fujitsu> AlinuxOS, what type of video card?
[05:39] <desrt> mjg59; with things like SMI's going off at random times you cannot assume that a delay loop run now will take the same number of ticks as a delay loop run later
[05:39] <desrt> mjg59; which is the very basis of bogomips, unfortunately :(
[05:40] <AlinuxOS> Fujitsu, 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP 330M/340M/350M
[05:40] <mjg59> desrt: It's hardly limited to ICH7
[05:40] <Fujitsu> Ah, ATI...
[05:40] <AlinuxOS> Fujitsu, yes ATI :)
[05:41] <AlinuxOS> Fujitsu, my new hardware configuration will be NVIDIA finally! :)
[05:41] <AlinuxOS> but on laptop I have ATI card.
[05:41] <Fujitsu> Urgh, Nvidia.
[05:41] <desrt> mjg59; how easy do you figure it would be to replace the delay loop with an accurate equivlent of itself that requires no calibration?
[05:42] <Keybuk> mjg59: interestingly, the vt switch does not come from the usplash init script
[05:42] <Keybuk> mjg59: could setupcon be doing that itself?
[05:42] <desrt> any system which abuses SMM to the extent that my macbook does would have TSC
[05:43] <AlinuxOS> Fujitsu, so which one ?
[05:44] <AlinuxOS> I would like to use compiz XGL things :)
[05:44] <Keybuk> mjg59: nope, that's not it either
[05:44] <Fujitsu> My Intel thing works fine, but I don't like Xgl-ish stuff.
[05:45] <AlinuxOS> Fujitsu, I understand.
[05:45] <AlinuxOS> Fujitsu, some people said that gnome 2-16 includes some visual effects...but I can't see anything :)
[05:46] <AlinuxOS> maybe it's my card issue.
[05:47] <AlinuxOS> good night chanel!;)
[05:49] <Keybuk> mjg59: ooh, S4 actually appears to work on my laptop now \o/
[05:51] <fabbione> slomo: ping?
[05:54] <Keybuk> don't suppose anyone knows off-hand the mkisofs runes to turn an ubuntu cd tree into a bootable iso?
[05:54] <Keybuk> (i386)
[05:54] <fabbione> oh it was on the wiki
[05:58] <Keybuk> ah, found it on kubuntu stuff
[05:58] <Keybuk> well, let's see if this works
[05:59] <Keybuk> mjg59: no joy with S3 :(
[05:59] <Keybuk> mjg59: on resume from S4, the fan state seems screwed.
[05:59] <Keybuk> mjg59: they're all off, but /proc/acpi/fan/*/state say they're all on
[06:05] <ScreaminIke> check? check one? check one two...
[06:06] <ScreaminIke> anyone out there?
[06:06] <infinity> ScreaminIke: Yes, but you probably don't need to do a mic test to determine that.
[06:07] <ScreaminIke> :) alright. can i make feature requests here? is there a mailing list for that?
[06:07] <ScreaminIke> it's kind of important, and oct 1st is coming fast... so i wanted to know the easiest way to request something...
[06:08] <infinity> We're way past feature freeze.
[06:08] <Keybuk> what happens on oct 1st?
[06:08] <infinity> Keybuk: I turn into a pumpkin.
[06:08] <infinity> No, wait, that's the 31st.
[06:08] <infinity> I have no idea, then.
[06:09] <ScreaminIke> well... it's just that the installer ... i tried it out earlier in a dry run, and it doesn't have my kbd layout in it
[06:09] <ScreaminIke> i use dvorak... 
[06:09] <fabbione> ScreaminIke: then file a bug in launchpad
[06:09] <ScreaminIke> it has been in past releases... 
[06:09] <ScreaminIke> ok
[06:09] <ScreaminIke> will do
[06:09] <fabbione> it's a regression, not a feature in this case
[06:10] <fabbione> infinity: are you busy now or can we check a few things together?
[06:11] <infinity> fabbione: A bit busy, but if it's something quick (or something I can think about while working on other stuff), hit me. :)
[06:12] <fabbione> infinity: just curious about sparc livecd.. is it done the same way as other primary arches or did we still need to do the transition for it?
[06:12] <fabbione> infinity: do we actually do it at all ?
[06:15] <infinity> fabbione: We've not been building it at all recently, though I'll turn it back on for testing before beta, if you really want to play with it.
[06:15] <infinity> fabbione: And it'll be squash+union, same as the others, cloop is long dead.
[06:16] <fabbione> infinity: i would like to give it a shot.. can you let one build now?
[06:16] <infinity> Sure, I can do a 1-off build right now.
[06:16] <infinity> Do you want a whole desktop, or are you just testing the theory?  (if the latter, I'll just build the "base" livecd)
[06:17] <fabbione> base is enough
[06:17] <fabbione> i want to see if it can boot
[06:17] <infinity> Oh, crap.  Someone mentioned pizza, and instantly I'm both craving and starving.
[06:17] <infinity> Ngh.
[06:17] <fabbione> hmm pizza.. at 6am
[06:18] <fabbione> no way i can get it here
[06:18] <infinity> Can't order any here either, I'd have to go out.
[06:18] <infinity> Uncivilised wasteland.
[06:18] <infinity> No one starts delivering until dinner.
[06:19] <infinity> Fujitsu: If you did, I'd love you...
[06:19] <Fujitsu> Unfortunately, I'm stuck at school :P
[06:19] <Fujitsu> What, I never said that? :P
[06:19] <infinity> Or was that some other Melbournian?  Hrm.
[06:20] <Fujitsu> You're eastern suburbs, aren't you?
[06:20] <Hobbsee> infinity: hehe, it's still 6 weeks to go till release, he's got time
[06:20] <infinity> Hobbsee: No, it was during the dapper release that this conversation happened. :)
[06:20] <Hobbsee> ahhh :P
[06:20] <Hobbsee> he's been too busy filing merges, i expect
[06:20] <infinity> Hobbsee: I was somewhere in the middle of a 72-hour day, and a bit hungry at 3am. :)
[06:20] <infinity> Fujitsu: Armadale.
[06:20] <Hobbsee> hehe
[06:20] <Fujitsu> More syncs than merges, Hobbsee :P
[06:20] <Fujitsu> infinity, I thought so.
[06:21] <Hobbsee> them too
[06:21] <Fujitsu> And a couple of bugfixes.
[06:24] <infinity> Fujitsu: Sweet Jesus.  That *is* the middle of nowhere (I just looked at a map)
[06:25] <ajmitch> to think that even I've been there
[06:25] <Fujitsu> ajmitch, did I miss you? :(
[06:25] <fabbione> ajmitch: to what email address should i flood you with build logs?
[06:25] <infinity> Aren't there wild animals and other such things that far out?
[06:25] <ajmitch> Fujitsu: I was only there for a couple of days in july
[06:25] <Fujitsu> fabbione, that's actually happening?
[06:25] <ajmitch> in ringwood
[06:25] <Fujitsu> infinity, not quite :P
[06:25] <ajmitch> fabbione: ajmitch@ubuntu.com
[06:26] <infinity> Fujitsu: No, seriously.  By the time I zoomed the map out far enough that I could see the bay on the left, I could also see New Zealand on the right.
[06:26] <fabbione> infinity: you should still be able to access the IMAP folder on my server.. want to check or should i forward?
[06:26] <fabbione> Fujitsu: no, this is only for a local test run on sparc
[06:26] <Fujitsu> infinity, ha ha.
[06:27] <Fujitsu> fabbione, OK.
[06:27] <infinity> fabbione: Pretty sure I deleted that account from my tbird setup.  Easier to just forward, and I can procmail it to somewhere.
[06:27] <fabbione> infinity: favourite email?
[06:27] <infinity> fabbione: adconrad@0c3.net, to avoid bouncing it through 12 other mail servers before it lands there anyway. :)
[06:27] <fabbione> ok done
[06:28] <fabbione> you might get a few spam mails while i make the system start up
[06:28] <infinity> ajmitch: You may want to do the same, so you're not passing a few gigs of logs through fiordland for no good reason.
[06:28] <ajmitch> true
[06:28] <Fujitsu> infinity, I was thinking that might be advisable.
[06:28] <infinity> fabbione: What's going to be the From: address, I'll procmail it now.
[06:28] <fabbione> infinity: something like sparcbuildd@fabbione.net or very close to that
[06:28] <infinity> "or very close to that"...
[06:28] <infinity> Helpful.
[06:28] <ajmitch> ajmitch@tauware.de might be better, it won't overflow as fast :)
[06:29] <fabbione> i don't remember :)
[06:29] <fabbione> ah there it is
[06:29] <infinity> :0
[06:29] <infinity> * ^From:.*sparcbuildd@fabbione.net.*
[06:29] <infinity> sparc-rebuild
[06:29] <fabbione> From: Buildd user <buildd*@sunfire.int.fabbione.net>
[06:29] <infinity> procmail needs an "or something like that" option.
[06:30] <fabbione> mind the * there will be about 24 buildd users running
[06:30] <Fujitsu> infinity, precisely.
[06:30] <Fujitsu> 24!?
[06:30] <Fujitsu> Over how many machines?
[06:30] <infinity> Fujitsu: One for each CPU.
[06:30] <fabbione> Fujitsu: one machine
[06:30] <infinity> (Well, for each core/thread)
[06:30] <Fujitsu> ....
[06:30] <Fujitsu> Most impressive.
[06:30] <fabbione> unfortunatly i will get the 64 CPU only next year
[06:30] <fabbione> 64 or 128
[06:30] <infinity> Only impressive when they're all running.  Each individual one is kinda sad. :)
[06:30] <Fujitsu> How long would a complete build like that take?
[06:30] <fabbione> not sure yet
[06:30] <Fujitsu> fabbione, why do you have such machines at your disposal?
[06:30] <fabbione> Fujitsu: about 48 hours for all of archive
[06:31] <fabbione> Fujitsu: because i am a developer?
[06:31] <infinity> fabbione: Okay, procmail happy.
[06:31] <Fujitsu> That really is quite impressive!
[06:31] <jdub> Fujitsu: also he has no heating. in demark.
[06:32] <fabbione> infinity, ajmitch: ignore the first few emails you will get.. they will be mostlikely crap from wanna-build and one/two build tests to ensure that the chroots and the * are happy
[06:32] <infinity> fabbione: *nod*
[06:32] <fabbione> infinity:  i didn't run this in the last 6 months.. and i need to restore the setup..
[06:33] <infinity> fabbione: Understood.  I always spend a few minutes fiddling with a new w-b/buildd setup too. :)
[06:33] <fabbione> infinity: ehhe
[06:33] <infinity> fabbione: But usually, no one else gets the logs, so I get to look all-knowing and unfailing.
[06:33] <fabbione> infinity:  i know :)
[06:33] <fabbione> i might just remove your forward while i do that.. but i am lazy :)
[06:34] <fabbione> lazy as any other sysadm in this world
[06:34] <infinity> I'm pretty sure I define lazy in the sysadmin world these days.
[06:34] <infinity> I have a "new" colo box I started setting up a year ago.. And then never finished.
[06:34] <Fujitsu> Fantastic!
[06:35] <infinity> And i think it's been a couple of months since I've attacked the freedesktop.org sysadmin backlog, though we have enough people to share that load that I can pretend I don't feel guilty.
[06:36] <mjg59> Keybuk: Ought to be fixed in -8
[06:37] <mjg59> If not, I'll take a look into it
[06:40] <Keybuk> mjg59: -8 ?
[06:41] <Keybuk> kernel ?
[06:41] <Hobbsee> likely
[06:43] <infinity> vivies needs to be faster, so it'll fail quicker...
[06:45] <mjg59> Keybuk: Yeah
[06:45] <mjg59> Keybuk: If you want mad crack, install uswsusp
[06:45] <mjg59> It ought to be quite a bit faster. It's certainly prettier.
[06:51] <lifeless> mjg59: will that ever be in our default config ?
[06:54] <fabbione> Keybuk: nice shot with readahead
[06:56] <pitti> Good morning
[06:57] <ajmitch> morning pitti 
[06:59] <mjg59> lifeless: +1, I hope
[06:59] <Keybuk> 'Could not find the frame base for "main".' ?!
[06:59] <Keybuk> WTF ?!
[07:02] <Hobbsee> hi pitti 
[07:02] <jdong> Keybuk: you did bump up usplash_timeout for foreground readaheading, right?
[07:03] <Keybuk> jdong: no, didn't think of it
[07:03] <jdong> Keybuk: yeah... that's kinda necessary, especially for slower hd's
[07:04] <_ion> Great, new xmoto (0.2.1) in universe.
[07:05] <Fujitsu> _ion, yup :)
[07:06] <Fujitsu> Hm.. I did the sync before that, not that one. :(
[07:07] <Hobbsee> :)
[07:07] <pitti> hey Keybuk 
[07:07] <pitti> Keybuk: wow, so early today? :)
[07:07] <Keybuk> pitti: late :p
[08:51] <dholbach> good morning
[09:07] <Mithrandir> iwj: can I get firefox to resize tabs rather than adding the scroll thingies at the ned of the tab bar?
[09:10] <Chipzz> Mithrandir: there is a minimal tab width in about:preferences
[09:10] <Chipzz> which will give you more tabs
[09:11] <Chipzz> but it will still give you the scroll thingies given enough tabs
[09:12] <Mithrandir> Chipzz: ah, thanks.  Seems to have helped.
[09:13] <Mithrandir> (browser.tabs.tabClipWidth = 1 , browser.tabs.tabMinWidth = 1)
[09:53] <enrico> Hi.  Who's in charge on i18n these days?
[09:54] <Chipzz> Mithrandir: you're welcome ;)
[09:56] <pitti> enrico: mostly me
[09:57] <pitti> enrico: will come back shortly, I need a quick reboot
[10:13] <sabdfl> doko: anybody else seeing openoffice crash-on-save?
[10:14] <fabbione> sabdfl: known issue
[10:14] <fabbione> sabdfl: they are working on it
[10:14] <Hobbsee> any reports of X breaking with the -8 kernel?
[10:16] <carlos> sabdfl: https://launchpad.net/distros/ubuntu/+source/openoffice.org/+bug/58508
[10:16] <Ubugtu> Malone bug 58508 in openoffice.org "cant save under edgy" [High,In progress]  
[10:18] <Hobbsee> hey Mithrandir 
[10:22] <Mithrandir> hiya Hobbsee
[10:38] <seb128> doko, doko_: ping?
[10:38] <seb128> I don't know which one to /query :p
[10:43] <doko_> seb128: pong
[10:45] <seb128> doko_: https://launchpad.net/distros/ubuntu/+source/pygobject/+bug/61323 ... do you have any idea on the topic?
[10:45] <Ubugtu> Malone bug 61323 in pygobject "[Edgy]  python-gobject is missing a Conflicts[/Replaces]  python-gtk-1.2" [Untriaged,Confirmed]  
[10:46] <seb128> doko_: looks like a python-support issue no?
[10:51] <mvo> mako: GREAT blogpost!
[10:52] <doko_> seb128: get rid of python-support ...
[10:52] <seb128> doko_: I've nothing against that, I would appreciate a quicker resolution for now though ;)
[10:57] <dholbach> seb128: pysupport -> pycentral should be quick enough ;-p
[10:57] <seb128> dholbach: feel free, I'm assigning those bugs to you then ;)
[10:57] <dholbach> don't even think about it
[10:57] <seb128> dholbach: and do that quick freeze for beta is tomorrow, thank you
[10:57] <enrico> uhm, who's in charge of im-switch?  http://packages.ubuntu.com/dapper/x11/im-switch doesn't say (and BTW, links to the warty BTS :)
[10:57] <seb128> dholbach: so don't tell me it's quick enough :p
[10:58] <seb128> enrico: we don't really have people "in charge" for it I think, what is your issue?
[10:58] <enrico> the scim-chewing upstream would like to discuss packaging issues
[10:58] <enrico> seb128: ^
[10:58] <mvo> hey enrico!
[10:58] <enrico> mvo: hi!!
[10:59] <enrico> mvo: did you see my wxssearch?
[10:59] <mvo> enrico: no, do you have a link?
[10:59] <seb128> enrico: feel free to discuss those here
[10:59] <mvo> enrico: or in #ubuntu-l10n :)
[10:59] <seb128> mvo is what is the nearer or a im-switch maintainer here I think ;o
[10:59] <enrico> mvo: sure I do: svn co svn://svn.debian.org/debtags/python
[10:59] <seb128> mvo: I've not on that chan :p
[11:00] <seb128> s/I've not/I'm not
[11:00] <mvo> seb128: its easy to join :P
[11:00] <seb128> oh, "click on a chan to join" is broken
[11:02] <enrico> mvo: also read http://lists.alioth.debian.org/pipermail/debtags-devel/2006-August/001324.html
[11:02] <seb128> doko_, dholbach:
 seb128: it seems to be due to the alternatives, and the current consensus is that we should remove the alternatives and use diversions instead
[11:03] <seb128> lool: thank you ;)
[11:06] <mvo> enrico: nice tool! and AFAICS all python :)
[11:06] <Mithrandir> mjg59: is usplash supposed to use tabs or spaces?  Its coding style could use a bit of.. unification.
[11:10] <enrico> mvo: yes, all python.   If  youw ant to borroww... :)
[11:10] <enrico> as much as I don't fancyy python that much, it's  the only languaeg I know whicch has nattive sest (beyoond  C++, of ccourse)
[11:21] <minghua> enrico: by scim-chewing upstream do you mean Andrew Lee?
[11:21] <minghua> enrico: I know something about im-switch but am not familiar about how Ubuntu uses it
[11:23] <enrico> minghua: yes, I'm talking with him.  Appearently, Ubuntu has a patch on top of debian's im-switch that break things
[11:24] <StevenK> enrico: That should be easily determinable using http://patches.ubuntu.com/
[11:24] <seb128> enrico: what about telling him to join the chan on telling here what is wrong?
[11:25] <minghua> StevenK: not really when you look at a 443K patch :-(
[11:27] <minghua> for those interested: we are talking about bug #57081
[11:27] <Ubugtu> Malone bug 57081 in scim-chewing "scim-chewing cannot enter any Chinese character" [Untriaged,Confirmed]  http://launchpad.net/bugs/57081
[11:31] <mvo> enrico: or can we join the channel where he is hanging out?
[11:31] <Kamion> mjg59: uh, re that conversation with Keybuk - I already fixed the business where usplash can't switch back to tty1 because /dev/tty1 doesn't exist, by just holding the fd open
[11:31] <Kamion> also, I hate C++
[11:32] <lifeless> anything specific, or just its existence ?
[11:33] <Kamion> lifeless: I have an excellent rant on this subject, but this IRC channel is too narrow to contain it
[11:33] <Kamion> I think "Note that the definition of operator[]  is extremely simple: m[k]  is equivalent to (*((m.insert(value_type(k, data_type()))).first)).second." kind of sums it up
[11:34] <Kamion> SIMPLE AS OPPOSED TO *(m+k), YOU FREAKING LOONS
[11:34] <enrico> mvo: we /msg
[11:36] <lifeless> Kamion: heh. its kindof like having the implementation of a functional language shoved up your nose, without type inferencing
[11:36] <hunger> Kamion: You are aware that you can code m[k]  as k[m]  just as well? :-)
[11:36] <lifeless> Kamion: so I can see that
[11:36] <Kamion> hunger: yes
[11:36] <lifeless> hunger: in c++ m[k]  is also the syntax for inserting into a set
[11:36] <Kamion> hunger: although not in C++
[11:36] <lifeless> hunger: aka dictionary
[11:36] <Kamion> hunger: this is std::map
[11:37] <lifeless> hunger: so they are not isomorphic for that case.
[11:37] <Mithrandir> hunger: that follows trivially from *(m+k) given that + tends to be communicative.
[11:37] <hunger> Kamion: Oh, yes, that dirty little trick to increase job security does not work with maps.
[11:37] <lifeless> hunger: also, I'd note that just because you *can* do something, does not mean you *should* do something
[11:38] <pitti> Mithrandir: mmm, communicative addition :)
[11:38] <hunger> lifeless: There is a excelent HOWTO on writing unmaintainable code...
[11:38] <pitti> definitively worth discussing in our commutation channels
[11:38] <Mithrandir> pitti: addition, not addiction. :-P
[11:39] <lifeless> hunger: I really hope its a 'DONTDO' not a "HOWTO"
[11:39] <minghua> Oh, sorry, it seems I was wrong, enrico was not talking about bug #57081
[11:39] <pitti> Mithrandir: of course, I'm not under the alcafluence of incahol that some thinkle peep I am
[11:39] <Ubugtu> Malone bug 57081 in scim-chewing "scim-chewing cannot enter any Chinese character" [Untriaged,Confirmed]  http://launchpad.net/bugs/57081
[11:39] <pygi> pitti: libburn is almost release ready, ahead of schedule ;)
[11:39] <hunger> lifeless: It is a good read (and pretty hilarious in places) and demonstrates all kinds of stupid ideas:-)
[11:40] <pitti> pygi: cool
[11:40] <hunger> lifeless: http://thc.segfault.net/root/phun/unmaintain.html
[11:43] <hunger> lifeless: The scary part is how much of that HOWTO made it into a best practice in the windows world.
[11:44] <Hobbsee> i'm sad to say that our comp lecturer does something close to that
[11:45] <ajmitch> hunger: yes, something I should pin up at work
[11:45] <Hobbsee> read string and write sting
[11:45] <shining> nice one, + is a communicative addiction
[11:46] <minghua> mvo, enrico: I talked briefly with Andrew Lee (in Chinese), but he had to leave
[11:47] <minghua> mvo, enrico: my understanding is that he thinks it's wrong for the scim-chewing package in ubuntu to provide its own im-switch settings 
[11:47] <pitti> minghua: btw, I'm just talking with AndrewLee about scim stuff, but I don't know anything about it
[11:47] <pitti> minghua: ok to forward him to you?
[11:47] <hunger> Hobbsee: One of my coworkers keeps writing "ressource":-)
[11:47] <Hobbsee> heh
[11:47] <minghua> scim-chewing should just use the im-switch settings provided by scim
[11:48] <shining> hunger: that's how it's written :)
[11:48] <minghua> pitti: I think I know most of his opinions, but sure, forwarding won't hurt, minghua-list@sbcglobal.net
[11:48] <hunger> shining: Yeap... but not in english.
[11:48] <shining> hunger: oh :)
[11:49] <minghua> pitti: I roughly know how scim works in Debian, but unfortunately Ubuntu uses a quite different system
[11:49] <hunger> shining: It is the one place where german spelling shines through in the app.
[11:49] <mvo> pitti, minghua: what should it do instead (scim-chewing)? just provide the default scim setting in im-switch?
[11:49] <shining> hunger: french too
[11:50] <hunger> shining: Well, basically all proper languages spell ressource right;-)
[11:50] <minghua> mvo: I can't say for sure.  but Andrew Lee (scim-chewing's Debian maintainer) thinks it should USE the im-switch settings provided by scim package
[11:51] <caleb-> mvo: im-switch in edgy/sid provides all_ALL for default, so it can support all locales. Dapper's im-switch has not all_ALL, so every scim engines has its own setting.
[11:51] <minghua> mvo: im-switch is just a framework, it doesn't provide any settings for particular input method by its own
[11:52] <mvo> caleb-, minghua: thanks. so we should probably change this in edgy because we have a newer scim there
[11:52] <mvo> im-switch I mean
[11:52] <minghua> mvo: good, it seems caleb- knows more about im-switch than I do :-)
[11:52] <shining> hunger: I didn't know such a thing existed
[11:52] <shining> hunger: proper language, I mean
[11:58] <\sh> any schedule when sync requests for universe are processed? :)
[11:58] <freeflying> mvo: minghua caleb-  as to the im-switch and scim, can we talk in #ubuntu-l10n
[12:02] <tkamppeter> doko_, I have answered to the two OOo bugs which appeared now in the list of subscribed bugs for the printing team
[12:02] <tkamppeter> They both seem to be really problems of OOo.
[12:03] <doko_> tkamppeter: thanks, unfortunately that were the only printing related OOo reports ;)
[12:04] <tkamppeter> doko_, "unfortunately"? I think it is a good result having only these few problems in such a big project. The OOo printing part seems to be one of the best printing facilities in applications.
[12:04] <doko_> tkamppeter: no,  in the sense, that I have to care about the remaining bugs mysel =)
[12:05] <pygi> doko_: could you please report our SoC results to soc-admin mailing lists? We want to be in good connection with Google folks ^_^
[12:05] <doko_> f
[12:05] <tkamppeter> General question about bug reports: On many the original poster did not answer our questions for months, should I reject them?
[12:05] <doko_> pygi: it's on my list
[12:05] <pygi> doko_: oki, thanks
[12:06] <tkamppeter> Mike Sweet, upstream maintainer of CUPS, rejects unanswered bug reports after two weeks.
[12:07] <doko_> tkamppeter: I think sfllaw did want to document a howto on these.
[12:14] <dholbach> tkamppeter: yes, the desktop team rejects them after four weeks of inactivity
[12:14] <dholbach> tkamppeter: you can grab a standard response from http://wiki.ubuntu.com/Bugs/Responses, if you like
[12:15] <Kamion> it's somewhat package-specific, of course. There are many ubiquity bugs I reject after a month (when I get round to it), but sometimes other people have asked for information which I don't really need ...
[12:15] <Kamion> so I don't let other people do the rejecting
[12:17] <Kamion> hal 0.5.7.1-0ubuntu11 produces uninstallable binaries:
[12:17] <Kamion>   * hal-device-manager (amd64 i386 powerpc)
[12:17] <Kamion> is that being worked on?
[12:17] <pitti> Kamion: I'm just hacking at hal
[12:17] <pitti> Kamion: so I can look into it; any way to find out why it's uninstallable?
[12:18] <ajmitch> Kamion: too late to get UVF exception for f-spot 0.2.1, I presume?
[12:18] <Kamion> only trying to install it in a clean system
[12:18] <Kamion> ajmitch: that depends, you can send mail and see
[12:18] <ajmitch> ok, I'll give it a go then
[12:19] <slomo_> fabbione: pong?
[12:20] <fabbione> slomo_: mplayer foo.mpg
[12:20] <fabbione> mplayer: symbol lookup error: mplayer: undefined symbol: a52_resample
[12:20] <fabbione> i need to run away 10 minutes
[12:20] <fabbione> bbl
[12:21] <slomo_> fabbione: known problem... Nafallo was working on it
[12:21] <fabbione> ok
[12:21] <fabbione> thanls
[12:21] <fabbione> thanks
[12:26] <pitti> Kamion: ah, I just saw that infinity uploaded a new hal this morning; infinity, was that to solve uninstallability?
[12:26] <pitti> infinity: can you please put that change into the bzr?
[12:28] <pitti> ogra: I just uploaded a new g-v-m which fixes the 'unsafe removal' warning for me; can you please test again?
[12:29] <pitti> Kamion: indeed, I tried it in a clean pbuilder, and infinity's patch fixes it
[12:31] <ogra> pitti, will do ...
[12:33] <doko_> Kamion, mvo, iwj: can dapper's dpkg handle bzip2 compression?
[12:33] <pitti> infinity: (I'm fixing the bzr for your hal version now)
[12:36] <fabbione> pitti: yes it was to solve the installability issue
[12:37] <Kamion> doko_: yes, we did that eons ago
[12:37] <Kamion> pitti: ok, thanks
[12:38] <Kamion> doko_: hoary's dpkg has that
[12:41] <doko_> Kamion: trying to keep OOo at the same size as it was for the dapper release ...
[12:41] <realist> Can anyone explain, or point me towards an explaination as to why the lynx patch wasn't applied to either breezy/etch?
[12:41] <pitti> ah, the lynx patch
[12:42] <pitti> realist: -v?
[12:42] <thom> _the_ lynx patch
[12:42] <pitti> thom: aaah, that one!
[12:42] <realist> pitti: ?
[12:42] <tseng> realist: --verbose
[12:42] <pitti> realist: which lynx patch do you talk about?
[12:45] <realist> pitti: just the person to field this question; https://launchpad.net/distros/ubuntu/+source/lynx/+bug/60879
[12:45] <Ubugtu> Malone bug 60879 in lynx "lynx gets stuck in infinite loop rendering invalid HTML" [Medium,Confirmed]  
[12:45] <pitti> realist: ah; well, I want to have it fixed in edgy, of course, just ENOTIME yet
[12:45] <realist> Does this fix belong elsewhere? And if so, where?
[12:46] <realist> I see, thanks :-)
[12:46] <pitti> realist: I'm grabbing the bug and mark it so that I'll fix it ASAP in edgy
[12:46] <pitti> realist: no, it's not something we will backport to stable releases; it's a simple bug only after all
[12:47] <realist> It should still be considered a security/stability issue, imho.
[12:47] <pitti> realist: why a security issue?
[12:47] <pitti> realist: stability, granted
[12:48] <realist> Software security _should_ also encompass 'availability'
[12:48] <pitti> infinity: for the record, I'll fix the krb5 FTBFS now
[12:48] <caleb-> realist: Once it is fixed, you may request a backports if you want. :-)
[12:49] <pitti> realist: right
[12:49] <pitti> realist: for a daemon or server a DoS is an issue
[12:49] <pitti> realist: but not for a client-side program that you run
[12:49] <pitti> realist: otherwise every application crash would be a security issue
[12:49] <realist> If one users process swallows 100% cpu, wouldn't that be an issue for the other users?
[12:49] <pitti> realist: that can't be fixed in packages like lynx
[12:50] <pitti> realist: you have to have pam limits and kernel support for resource limiting
[12:50] <realist> I suppose, it's just my personal opinion after all :-)
[12:50] <pitti> cat /dev/zero > /dev/null, there you go :)
[12:51] <dholbach> realist: that'd be so lovely - we could assign all our bugs to pitti that way
[12:51] <pitti> realist: the point is, it is unrealistic to fix all simple application crashes in stable releases
[12:51] <pitti> it would make the stable release unstable and would hide real vulns behind a ton of bogus fixes
[12:51] <realist> I wouldn't have thought so, in this case.
[12:56] <realist> Just found a similar bug in 'vim' actually
[01:05] <Kamion> er
[01:05] <Kamion> I'm going to add an installer-mode-only option that lets ubiquity fake its idea of what filesystem is on a partition
[01:06] <Kamion> hopefully that should let me avoid a large number of the bugs of the form "I pressed Back and now the partitioner has gone all weird on me"
[01:16] <ogra> urgh, beta freeze is tomorrow ? what made me think its on the 28th ?
[01:16] <StevenK> ogra: Your dealer.
[01:16] <StevenK> ogra: Well, more correctly, what he sells you. :-P
[01:16] <ogra> shit, i thought i'd have time to at least recoiver a bit and get some sleep ...
[01:17] <StevenK> ogra: Plenty of time for that after the 26th of October.
[01:17] <StevenK> Hrm. I wonder how much No-Doz Kamion and Keybuk have already bought.
[01:17] <ogra> :(
[01:17] <StevenK> ogra: Seriously though, want a hand with something?
[01:18] <Mithrandir> oh, jay.  I fixed the usplash-jumps-around-bug in casper-md5check.
[01:18] <pitti> Mithrandir: do floats behave differently in other languages?
[01:19] <ogra> StevenK, no, i need to fix one thing in ltsp that i prepared in detroit the last week (printing) and need to extensively test the last uploads i did ... and some finalization in edubuntu-artwork i didnt get yet ...
[01:19] <ogra> nothing someone else could really help with
[01:19] <ogra> (unless you have an ltsp lab)
[01:20] <StevenK> ogra: Not so much, no.
[01:20] <Mithrandir> pitti: in perl, they do, yes.
[01:20] <Mithrandir> : tfheen@xoog ~ > perl -le '$a = 5; $b = 7; print $a / $b;'
[01:20] <Mithrandir> 0.714285714285714
[01:20] <Mithrandir> in python, they don't.
[01:20] <pitti> Mithrandir: ah, you mean perl automatically converts ints to floats on division
[01:21] <Mithrandir> pitti: yeah, while C forces me to cast, or it gives me overflows.
[01:21] <Mithrandir> 100*$around_650_mb / 700mb doesn't work as you expect. :-P
[01:21] <StevenK> >>> 5.0/7.0
[01:21] <StevenK> 0.7142857142857143
[01:22] <Mithrandir> StevenK: stat(2) doesn't return float values.
[01:22] <pitti> StevenK: 5 != 5.0 :)
[01:22] <Mithrandir> (for size, etc)
[01:22] <StevenK> Then float() them
[01:22] <pitti> no, just divide by 70000000.
[01:22] <pitti> i. e. append a '.'
[01:23] <Mithrandir> well, this is C.  I don't think we want python in the initramfs.
[01:23] <StevenK> Mithrandir: It's already Essential: yes, why not? :-P
[01:23] <Mithrandir> StevenK: put the crack pipe down.  now.  slowly.
[01:23] <Fade> 'cause a statically linked python is enormous? :)
[01:24] <StevenK> Mithrandir: Hrmm. I can't seem to get my fingers to uncurl.
[01:25] <minghua> Mithrandir: so did you use long int or float in the end? :-)
[01:26] <thom> doko_: any chance you're gonna sync buildbot from debian? (and get 0.7.4 preferably)
[01:26] <Mithrandir> minghua: long double.
[01:26] <ajmitch> thom: bug 62358
[01:26] <ajmitch> hm
[01:26] <ajmitch> bug 61358
[01:26] <Ubugtu> Malone bug 61358 in buildbot "please sync buildbot 0.7.4-1 from Debian unstable (main)" [Wishlist,Confirmed]  http://launchpad.net/bugs/61358
[01:26] <Fade> Mithrandir: did you ever have a chance to look at my xemacs bug?
[01:27] <ogra> rodarvus, any news on the via issue ? according to mdz's mail beta freeze is tomorrow ...
[01:27] <Mithrandir> Fade: I fixed it in emacs as least.. can you try building xemacs with -fno-stack-protector added to cflags?
[01:28] <rodarvus> ogra, I have the package ready since two days, was just waiting for your nod to upload it
[01:28] <Fade> Mithrandir: okay
[01:28] <rodarvus> (ie, did it work on *all* machines at the LTSP hackfest?)
[01:28] <ogra> rodarvus, well, it makes all thin clients here work, but i actually have no other via based HW 
[01:28] <rodarvus> no regressions caused by the test package I sent you?
[01:28] <rodarvus> oh
[01:28] <ogra> nope
[01:29] <doko_> thom: yes, have to fix the login shell first
[01:29] <rodarvus> ok, I'll upload it *now*
[01:29] <ogra> the fact that xserver-xorg doesnt respect VideoRam preseeding is kinda odd though ...
[01:29] <rodarvus> done
[01:29] <ogra> one of the vias i have needs 16384 set ...
[01:29] <thom> cool
[01:30] <thom> oh well, i just backported it to dapper
[01:30] <slomo_> rodarvus: and i read that a new radeon driver is on it's way that should fix some crashers with older radeons
[01:30] <ogra> but i can work around that with a static xorg.conf though ... not elegant but i can write a howto if the bug i filed is not seen as RC
[01:31] <slomo_> rodarvus: http://airlied.livejournal.com/32609.html   will we get this for edgy?
[01:31] <rodarvus> ogra, video card detection, and generically speaking, xorg.conf creation *really* could use some love, but I guess that will have to wait for our full time X hacker (when we find one :) )
[01:31] <Mithrandir> mjg59: is it on purpose that we don't display failures any more?
[01:31] <ogra> (its always been a prob with that specific via board)
[01:31] <rodarvus> slomo_, I've just seen this blog entry, was about to check what it is all about on git
[01:31] <ogra> rodarvus, well, that specific bug just needs someoune with decent dbconf knowledge
[01:32] <slomo_> rodarvus: perfect, thanks :)
[01:32] <Mithrandir> mjg59: and would you like me to extend TEXT or have an TEXT-URGENT command?
[01:32] <ogra> rodarvus, apparently xdebconfigurator fully supports it ... i wonder if we shouldnt sync that alongside with the debian packages ...
[01:32] <rodarvus> ogra, the thing is we have quite a few failures and misdetections happening: xresprobe needs love, 'xorg' (package) needs love
[01:33] <ogra> well, debian uses xdebconfigurator for all x detection ...
[01:33] <ogra> they dont have such a thing like our postinst for xserver-xorg afaik
[01:34] <Kamion> ogra: that's totally not true
[01:34] <Kamion> our postinst comes from Debian and is still used there
[01:34] <rodarvus> indeed, they don't use xdebconfigurator (at least not anymore)
[01:34] <rodarvus> don't know in the past
[01:34] <Kamion> never did as far as I know
[01:35] <Kamion> not in the standard installer flow, anyway
[01:35] <Kamion> as far as I know> i.e. in the last five years
[01:35] <rodarvus> ogra, ubuntu changes to 'xorg' package are reasonably small
[01:35] <ogra> ok
[01:35] <rodarvus> and could be smaller if they were willing to collaborate with us instead of insisting in rolling their stuff all the time :D
[01:35] <Kamion> debian-edu may do different things
[01:36] <ogra> Kamion, yes, that might be it ... since petter and vagrantc told me it is like that 
[01:37] <ogra> and they both are rather -edu guys
[01:37] <azeem> xdebconfigurator was written by a skolelinux/debian-edu guy I think
[01:37] <mjg59> Mithrandir: Just run indent over it
[01:38] <mjg59> Mithrandir: And I'm easy over whether TEXT is extended or whether there's a specific command
[01:38] <Kamion>  Package: xdebconfigurator
[01:38] <Kamion>  Maintainer: Debian Edu Developers <debian-edu@lists.debian.org>
[01:38] <Kamion> yeesh, it still provides a base-config menu item
[01:39] <Kamion> I wonder when they'll discover 2006 :)
[01:39] <ogra> heh
[01:39] <Mithrandir> mjg59: it's trivial to add new commands, so I think I'll just have it be TEXT-URGENT.
[01:39] <ogra> but it works :) at lest for stuff like VideoRam :)
[01:40] <Mithrandir> mjg59: and I'll do the indent, yes.  Do you have a preference to what coding style it should use?
[01:40] <ogra> we're missing so many options in our postinst ...
[01:41] <Mithrandir> ogra: you're aware that specifying options in xorg.conf should generally be avoided?  Let the X server probe as much as possible.
[01:43] <ogra> Mithrandir, right ... but if i have certain combos that only work with options like "VideoRam 16384" at least the preseedability should be there 
[01:43] <ogra> like we added one for DefaultDepth
[01:43] <Mithrandir> ogra: and that's impossible to detect?
[01:44] <shining> couldn't it be just commented ?
[01:44] <ogra> well, we could probably hardcode it somewhere ... "if certain chipset in certain HW combination then ..."
[01:44] <ogra> shining, that wont help ltsp 
[01:44] <ogra> nor the liveCD on such HW ... 
[01:45] <ogra> most ltsp clients have these miniITX epia boards and some of them need such options ...
[01:45] <mjg59> Mithrandir: I tend to use kernel style
[01:45] <ogra> its a corner case in the software that affcts many users 
[01:46] <Mithrandir> mjg59: ack, willdo
[01:46] <ogra> rodarvus, thanks for the upload !
[01:46] <rodarvus> ogra, thank YOU for the report!
[01:47] <ogra> there goes a funny story with redhat alongside i'll tell if i have more time to chit chat ;) (we had warren from redhat/fedora at the hackfest)
[01:48] <ogra> (who has the same prob but didnt get it fixed, but it wroked when he copied our binary from te modules dir into his)
[01:48] <Kamion> "certain chipset in certain hardware combination"> that's what a lot of X hardware detection is like already. :)
[01:49] <ogra> Kamion, right ... but i'll not be able to look deeper into it before beta ... so the question is if the bug is RC or not 
[01:51] <ogra> is the "Go" button in ff for anyone else ridiculous big ? 
[01:51] <ogra> makes my url field quite small here 
[01:52] <_ion> I hate the button. I hope there's a way to hide it. (I skimmed through the preferences window, but didn't look at about:config yet.)
[01:52] <Kamion> ogra: yes
[01:53] <ogra> pitti, why is cryptosetup not in main ? (i know youre an extensive user of it)
[01:53] <ogra> *cryptsetup
[01:54] <ogra> Kamion, yes == its an RC bug ? 
[01:54] <slomo_> ogra, pitti: it needs some upstart love for the password in the init script... but apart from that i want to see it in main too ;)
[01:54] <pitti> ogra: I just never got to it
[01:55] <ogra> ok, then there is no technical reason, thats cool :)
[01:59] <johnl> hi.  the latest ekiga package in edgy hasn't been built since it was uploaded (14 days ago) due to a dependency problem: https://launchpad.net/distros/ubuntu/edgy/+source/ekiga/+builds
[02:00] <johnl> is this something I should report? and who to?
[02:03] <dholbach> in fact that's a ftbfs because pwlib failed to build: http://librarian.launchpad.net/4293008/buildlog_ubuntu-edgy-i386.pwlib_1.10.2.dfsg-0ubuntu1_FAILEDTOBUILD.txt.gz
[02:03] <dholbach> dpkg-deb: building package `libpt-plugins-alsa-dbgsym' in `../libpt-plugins-alsa-dbgsym_1.10.2.dfsg-0ubuntu1_i386.ddeb'.
[02:03] <dholbach> objcopy: debian/libpt-1.10.0/usr/lib/debug//usr/lib/libpt.so.1.10.2: Invalid operation
[02:03] <dholbach> dh_strip.pkg-create-dbgsym: command returned error code 256
[02:03] <slomo_> pitti: ^----
[02:03] <dholbach> pitti: ^ do you know what happened there?
[02:04] <seb128> dholbach: iz pkg-create-dbgsym bog
[02:04] <pitti> dholbach: will take a look at it after lunch
[02:04] <dholbach> rock and roll
[02:04] <pitti> dholbach: most probably yet another corner case pkg-create-dbgsym doesn't handle
[02:04] <dholbach> seeya
[02:05] <Kamion> ogra: yes == the go button in firefox is ridiculously big for me too
[02:08] <Kagou> hey iwj, doing now a fresh daily install to (i hope) close the fontconfig-config bug ;) (yesterday iso didn't include the last version of fontconfig-config)
[02:08] <tkamppeter> Thanks for the help regarding the old bug reports.
[02:08] <tkamppeter> pitti, doko_, now I have another problem:
[02:09] <elmo> who are our resident freenode staffers?
[02:10] <tseng> seveas has connections if he isnt a staff himself
[02:10] <tkamppeter> I want to update foomatic-db to today's state. For that I have downloaded the most recent unstable source of Debian (foomatic-db-20060822) to update it to today's snapshot with ""uupdate".
[02:10] <elmo> he claims not to be staff, I forget who is, one of the  #ubuntu ops, IIRC
[02:11] <tkamppeter> The uupdate works fine, I get a new directory with the ready to build source tree for 20060819.
[02:11] <Kamion> nalioth IIRC
[02:11] <Kamion> elmo: ^--
[02:11] <Kamion> 13:11 [Freenode]  -!- nalioth [i=nalioth@freenode/staff/ubuntu.member.nalioth] 
[02:11] <elmo> Kamion: ah, yeah, good call, thanks
[02:11] <Kamion> there may be others
[02:11] <Hobbsee> elmo: nalioth, rob, 
[02:11] <tkamppeter> But if I build I get an error which lloks like that building on Debian and on Ubuntu are not compatible.
[02:11] <Hobbsee> elmo: sometimes hedgemage
[02:12] <elmo> Hobbsee: "sometimes"? :)
[02:12] <Hobbsee> elmo: they're the current ones
[02:12] <Hobbsee> elmo: as in, she's sometimes around the #ubuntu channels - she's not around all the time like the other two are
[02:12] <elmo> ah
[02:12] <tkamppeter> So I tried also to rebuild 20060822 in the old directory and got the same error there. See the log of the build process in
[02:13] <tkamppeter> http://www.freestandards.org/~till/tmp/ubuntu/edgy/foomatic-db/foomatic-db-20060822-rebuild.log
[02:13] <Kamion> Hobbsee: rob?
[02:13] <tkamppeter> and the source package used for that build in
[02:13] <tkamppeter> http://www.freestandards.org/~till/tmp/ubuntu/edgy/foomatic-db/
[02:13] <Kamion> tkamppeter:           install -d //usr/share/cups/model; \
[02:13] <Kamion> looks like DESTDIR isn't set?
[02:13] <Kamion> or that the Makefile isn't honouring it
[02:14] <Kamion> (DESTDIR's the conventional name, anyway)
[02:14] <Hobbsee> Kamion: yes.  doesnt look to be around at the moment though - he usually is.
[02:14] <Hobbsee> elmo: if you're looking for the various op type people, check #ubuntu-ops
[02:14] <tkamppeter> And how did they get it building under Debian then?
[02:14] <Hobbsee> the ubuntu + staffer people hang out there
[02:14] <Kamion> we're not incompatible at that level. Let me look at the source
[02:15] <Kamion> wah, foomatic-db upstream ship their own debian/rules? how confusing
[02:16] <tkamppeter> I have once given write access to the repository to Chris Lawrence and he has maintained Debian directories in the foomatic subpackages for some time.
[02:16] <tkamppeter> I never touched these Debian directories.
[02:17] <Kamion> I see - I guess it's up to Chris then
[02:17] <tkamppeter> And I doubt that the write access for Chris is still active, perhaps I better delete all debian directories from the upstream repositories.
[02:17] <Kamion> best talk to Chris first
[02:17] <elmo> Hobbsee: thanks
[02:20] <tkamppeter> For the Mandriva RPM I install with
[02:20] <tkamppeter> make PREFIX=%{_prefix} DESTDIR=%buildroot install
[02:20] <Hobbsee> elmo: not a problem
[02:21] <Kamion> tkamppeter: I have no idea why/how it worked on Debian, but debian/rules is wrong (or arguably the Makefile)
[02:21] <doko_> tkamppeter: did you look for patches in the diff.gz? I never used uupdate
[02:21] <Kamion> this isn't an incompatibility, it's just weird shit
[02:21] <Kamion> tkamppeter: setting PREFIX does nothing. it's set but never references
[02:21] <Kamion> referenced
[02:22] <tkamppeter> Where %{_prefix} is /usr and %buildroot is the temporary directory for the directory tree which should be installed into the system when one installs the binary RPM. So DESTDIR in the upstream package should work/
[02:22] <doko_> I think, changes in the diff.gz are not applied automatically, so you have to do that by hand
[02:22] <Kamion> doko_: uupdate applies the Debian diff
[02:22] <Kamion> that's kind of the point
[02:22] <desrt> yay.  -8.
[02:22] <Kamion> tkamppeter: debian/rules should be changed as follows, I think:
[02:22] <desrt> happy -8, everyone.
[02:22] <Kamion> -        $(MAKE) install prefix=$(CURDIR)/debian/foomatic-db/usr
[02:23] <Kamion> +        $(MAKE) install DESTDIR=$(CURDIR)/debian/foomatic-db
[02:23] <tkamppeter> So then the " PREFIX=%{_prefix}" is some cut'n'paste noise.
[02:23] <pina> hi
[02:23] <pina> doesnt ubuntu work with kerberos/ldap out of the box?
[02:24] <Kamion> tkamppeter: oh, it probably worked for Chris because he already had the package installed, so /usr/share/cups/model was already there
[02:24] <tkamppeter> Kamion, yes, this is how it is intended by my upstream Makefile.
[02:24] <Kamion> although how 'ln -sf $(LIBDIR)/db/source/PPD $(DESTDIR)$(CUPS_PPDS)/foomatic-db-ppds' worked I'm not sure
[02:24] <Kamion> maybe he built it as root :-/
[02:24] <pina> anyone
[02:25] <tkamppeter> But then Chris must either have /usr/share/cups/model world-writable or he must have run dpkg-build as root.
[02:25] <Kamion> tkamppeter: note that the db/source/PPD symlink is missing from the Debian binary package
[02:25] <tkamppeter> Both are not good ideas, you can mess up your system or you can take a mess of your system into the package.
[02:25] <Kamion> so I reckon he built it as root and never noticed
[02:25] <Kamion> indeed, you aren't meant to build Debian packages as root
[02:26] <Kamion> oh, hmm, there's stuff in debian/rules that futzes around with db/source/PPD
[02:26] <tkamppeter> Yes, I usually do not build packages as root, neither Debian nor RPM. All have to install into a temporary directory.
[02:26] <Kamion> who knows ...
[02:26] <pina> anyone just clue me in on the ldap issue
[02:28] <tkamppeter> Did the Ubuntu maintainer of foomatic-db really rebuild it before uploading it into Ubuntu? Or did he simply copy Debian's binary packages?
[02:29] <tkamppeter> Therefore perhaps foomatic-db is such outdated.
[02:30] <Kamion> tkamppeter: we never under any circumstances copy binary packages. We often copy source packages.
[02:31] <doko_> tkamppeter: we ususally just sync from unstable.
[02:31] <Kamion> tkamppeter: the last version of foomatic-db was a direct copy of the Debian source package (a sync), not actually uploaded by an Ubuntu maintainer as such.
[02:31] <doko_> tkamppeter: there's no "Ubuntu maintainer".
[02:35] <Kagou> iwj: sorry to say that today iso don't contain last fontconfig package. Kamion is it normal that today iso do not contain a 2/3 days old package ?!
[02:38] <Kamion> Kagou: desktop or alternate?
[02:38] <Kamion> we build many CD images on a daily basis, and you must be specific
[02:40] <Kamion> infinity: please re-enable the livefs cron jobs
[02:40] <Kamion> Kagou: ^-- if you mean the desktop CD, then the above is the problem.
[02:40] <Kagou> Kamion: desktop
[02:41] <Kagou> Kamion: if i take alternate cd, it will contain more uptodate packages ?
[02:42] <Kamion> Kagou: yes, today
[02:42] <Kamion> the desktop CD will be fixed at some point after infinity is next awake to see my request above
[02:42] <Kagou> ok Kamion . Thanks so i will do an alternate install to close a bug. :)
[02:48] <tkamppeter> Kamion, and from where is the binary package?
[02:49] <_ion> Yay. "lists are sorted into block order on each boot, rather than when generated", "readahead is run in the foreground"
[02:50] <tkamppeter> According to the information which you see in the lower left of the bug 59829 web page, doko_ must have built our stone-old binary package.
[02:50] <Ubugtu> Malone bug 59829 in foomatic-db "No driver for Samsung ML-1610 printer" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59829
[02:52] <Kamion> tkamppeter: we rebuild the binary package on our buildds
[02:52] <pitti> dholbach: ah, pwlib's debian/rules has a wrong logic for dh_strip, shall I just fix that/
[02:52] <pitti> ?
[02:53] <Kamion> tkamppeter: that information is about the source package, NOT the binary package; furthermore in this case it merely means that doko requested the sync of the source package from Debian
[02:53] <Kamion> note that the heading of the box you're looking at is ""foomatic-db" source package in ubuntu:"
[02:57] <pitti> slomo_, dholbach: Fixed pwlib uploaded
[02:58] <pitti> slomo_, dholbach: debian/rules just erroneously used 'ifndef' when it wanted 'ifdef' :)
[02:58] <pitti> Hi Yagisan 
[02:58] <slomo_> pitti: thanks :)
[02:58] <Yagisan> G'day pitti 
[03:02] <_ion> Hmm. Why is there a readahead package in both main and universe?
[03:02] <zul> hi pitti 
[03:02] <dholbach> pitti: thanks - I'll talk to kilian about that
[03:02] <_ion> A source package that is.
[03:03] <pitti> _ion: apparently the old readahead source was superseded by the readahead-list source
[03:04] <_ion> Whoops, i misread apt-cache's output.
[03:17] <tepsipakki> doko: could you backport the fix for debian bug #368583 to dapper-updates? It would also fix malone #48244
[03:17] <Ubugtu> Debian bug 368583 in eclipse "eclipse: Does not work with sun-java5-bin package" [Grave,Open]  http://bugs.debian.org/368583
[03:17] <Ubugtu> Malone bug 48244 in eclipse "eclipse does not locate java-1.5.0-sun" [Low,Confirmed]  http://launchpad.net/bugs/48244
[03:21] <piratepenguin> anyone here know how the OpenCD bit on the ubuntu cd works/was developed? Where did Launch.exe come from?
[03:25] <slomo_> infinity: please give-back tomboy on sparc
[03:31] <doko_> Kamion, infinity: are there any plans to remove libdb4.3 from the CD's? remaining rdepends are iproute, libpam-modules, libsasl2, libwvstreams4.2-extra
[03:38] <Kagou> iwj: it's ok for fontconfig-config :) so i close the bug Nice
[03:41] <_ion> I quite like the fact that sulogin respawns until e.g. 'telinit 2' is executed.
[03:46] <terlmann> will the 6.10 beta iso be out tomorrow or today?
[03:47] <sbalneav> ogra: Hey!  Make it back safe?
[03:47] <tseng> no
[03:47] <dholbach> terlmann: it's the beta freeze, not the release of a cd
[03:47] <tseng> https://wiki.ubuntu.com/EdgyReleaseSchedule
[03:47] <ogra> sbalneav, 
[03:47] <ogra> yes
[03:47] <sbalneav> Excellent!
[03:47] <ogra> but discovered that i missed out on a freeze date ... 
[03:47] <terlmann> the beta release said thursday!
[03:47] <tseng> terlmann: no, it doesnt
[03:47] <dholbach> terlmann: where does it says something like that?
[03:47] <ogra> s no sleep for me until tomorrow
[03:47] <ogra> *so
[03:48] <tseng> terlmann: read the link i just gave
[03:48] <sbalneav> lol!  Anything I can help with?
[03:48] <tseng> this is the official schedule
[03:48] <terlmann> will it be up on the servers tonite?
[03:48] <tseng> goodness
[03:48] <tseng> no.
[03:48] <piratepenguin> beta release next week
[03:48] <terlmann> not
[03:49] <dholbach> terlmann: freeze date != release data
[03:49] <tseng> the release will be prepared on or around Sept 28
[03:49] <tseng> and will be announced on all the usual channels
[03:49] <ogra> sbalneav, i need the final stuff for ldm
[03:49] <terlmann> the wiki says tommarow and the freeze is today.
[03:50] <tseng> terlmann: please show us where you are seeing that
[03:50] <tseng> because it isnt true
[03:50] <terlmann> rats.
[03:50] <terlmann>  14     September 21st 
[03:50] <tseng> 15    Septermber 28th
[03:51] <tseng> this is not "the next day"
[03:51] <terlmann>  *15*     September !28th! i thought wrong... 
[03:51] <tseng> by any means
[03:51] <sbalneav> ogra: Has matt approved the ltspfs changes?
[03:51] <tseng> when it is release you will know :)
[03:52] <tkamppeter> pitti, doko_, mdz: The new foomatic-db (20060918) is now uploaded to my web space:
[03:52] <tkamppeter> http://www.freestandards.org/~till/tmp/ubuntu/edgy/foomatic-db/
[03:53] <ogra> sbalneav, see pm
[03:53] <tkamppeter> And the binary packages to
[03:53] <tkamppeter> http://www.freestandards.org/~till/tmp/ubuntu/edgy/foomatic-db/binary/
[03:53] <tkamppeter> Note that they have a Ubuntu release number now, as I had to to fixes on the packaging.
[03:53] <terlmann> someone inform me at terlmann@yahoo.com the "Moment" I can get a beta alt. iso cd image......  and is their any proposals floating around about ubuntu on a dvd?
[03:54] <dholbach> terlmann: please subscribe to ubuntu-devel-announce@lists.ubuntu.com
[03:54] <dholbach> terlmann: and Ubuntu on DVD exist since the beginning of Ubuntu :)
[03:55] <terlmann> where?
[03:55] <dholbach> the place you get the CDs too
[03:55] <dholbach> http://cdimage.ubuntu.com/
[03:55] <iwj> Kagou: Excellent, thanks.
[03:56] <terlmann> where can i get a edgy knot 3 delta dvd iso?
[03:56] <dholbach> And that's more of a #ubuntu question, sorry.
[03:57] <terlmann> ok got it. that's more of? what purpose is chatting except to ask questions?
[03:57] <dholbach> we should have something about "chatting" in the topic :)
[03:57] <tseng> dholbach: you are unshakeable
[03:58] <dholbach> tseng: how do you mean?
[03:58] <tseng> dholbach: staying polite
[03:59] <dholbach> ahh good - I thought you were going to say I should have been more patient :)
[04:01] <Kagou> iwj: your welcome
[04:02] <gnomefreak> add to topic something like instead of (not support, even with edgy) use something like "for all support related questions join #ubuntu" " this channel is for development support only"?
[04:02] <gnomefreak> not like people read topics :(
[04:02] <tseng> thats awfully long, and no one reads anyway
[04:03] <gnomefreak> its already in the topic anyway
[04:03] <Chipzz> gnomefreak: s/development support/development OF ubuntu/
[04:04] <Chipzz> or else you'll have people asking for support about developping WITH ubuntu
[04:04] <gnomefreak> true
[04:04] <imbrandon> infinity: ping
[04:22] <tkamppeter> pitti, doko_, mdz: New foomatic-filters on http://www.freestandards.org/~till/tmp/ubuntu/edgy/foomatic-filters/, UVF ER sent out -> biff.
[04:25] <dandrader> hi all
[04:25] <dandrader> I'm experiencing a weird bug in my package building (actually, inside SCons) which only happens on those ubuntu package building boxes
[04:25] <slomo_> doko: why is the -l10n package of openoffice separate although both are building a complete openoffice anyway? what am i missing? ;)
[04:26] <dandrader> Is there a way to reproduce the building environment used on them?
[04:26] <dandrader> So that I can track down that bug on my own box
[04:26] <tseng> dandrader: https://wiki.ubuntu.com/PbuilderHowto
[04:26] <tseng> dandrader: check that out
[04:27] <jdong|laptop> infinity or Kamion, ping
[04:27] <dandrader> tseng:  hmm... but it works fine on a regular pbuilder
[04:27] <slomo_> dandrader: talk to infinity about it... iirc he knows about some weird failures with scons ;)
[04:27] <tseng> dandrader: oh I see
[04:27] <tseng> dandrader: then you probably need to talk to a real live build-admin
[04:27] <slomo_> dandrader: it's not the first time that scons fails on the buildds but nowhere else... afaik it never worked
[04:28] <dandrader> oh... so that's a kind of "known bug"
[04:29] <tseng> sortof but you should pursue it
[04:29] <dandrader> tseng:  yeah, I would like to
[04:30] <dandrader> infinity:  ping
[04:35] <Hobbsee> dandrader: infinity is likely asleep
[04:35] <tseng> Hobbsee: as you should be
[04:35] <Hobbsee> tseng: yeah well...
[04:35] <Hobbsee> i'm being lazy, and on holidays
[04:40] <`ph8> Mithrandir: ping :)
[04:40] <`ph8> Mithrandir: happen to know if the kernel made it in today? i'll be home in a couple of hours
[04:41] <crimsun> jdong|laptop: in the future, please don't randomly approve backport requests without first poking the person listed most recently in Changed-By
[04:41] <jdong|laptop> crimsun: duly noted, sorry....
[04:56] <mako> mvo: glad you appreciated it :)
[04:57] <seaLne> mvo: is the new python-defaults related to these errors: http://rafb.net/paste/results/BLDqIf81.html ?
[04:57] <mvo> seaLne: yes
[04:58] <seaLne> cool, just discovered it on trying to upgrade a machine that hadn't been updated fro a few weeks
[04:58] <mvo> seaLne: the update should fix that 
[04:58] <seaLne> thanks
[04:59] <mvo> seaLne: let me know if the issue is fixed for you once the new python-defaults is available
[05:00] <seaLne> yep, not in the archive yet
[05:14] <Hobbsee> doko: ping?
[05:15] <Hobbsee> hey sabdfl 
[05:15] <Hobbsee> doko: https://launchpad.net/distros/ubuntu/+bug/61453 <-- i suspect that wasnt quite what you intended to do
[05:15] <Ubugtu> Malone bug 61453 in Ubuntu "sync request" [Untriaged,Unconfirmed]  
[05:17] <slomo_> BenC: /usr/include/asm-i386/io.h seems to be broken... http://librarian.launchpad.net/4354262/buildlog_ubuntu-edgy-i386.irda-utils_0.9.16-11ubuntu3_FAILEDTOBUILD.txt.gz
[05:18] <BenC> slomo_: it's probably another case of "don't use l-k-h/libc-linux-dev to get to kernel internals", but I'll check
[05:18] <slomo_> BenC: thanks :)
[05:19] <BenC> slomo_: that header doesn't seem broken, but I suspect that smc.c really wants to include sys/io.h instead of asm/io.h anyway
[05:19] <BenC> err, does seem broken
[05:19] <BenC> slomo_: can you file a bug?
[05:20] <slomo_> BenC: i have no idea, i only uploaded a fix for the init script ;) i'll test it with sys/io.h later
[05:20] <slomo_> about the broken header? sure...
[05:20] <BenC> thanks
[05:20] <iwj> Yay, printf-debugging with a program that takes 30m to build.
[05:21] <bluefoxicy> damnit, why is killall -9 not killing gksu
[05:22] <slomo_> BenC: bug #61455
[05:22] <iwj> gksu is set-id so you have to sudo killall
[05:22] <tkamppeter> pitti, doko_, mdz: New foomatic-db-hpijs corresponding to HPLIP 1.6.7 on http://www.freestandards.org/~till/tmp/ubuntu/edgy/foomatic-db-hpijs/, Added to HPLIP UVF ER -> biff.
[05:22] <Ubugtu> Malone bug 61455 in linux-source-2.6.17 "asm-i386/io.h includes non-existing header file" [High,Unconfirmed]  http://launchpad.net/bugs/61455
[05:22] <Fade> Mithrandir: the stack trace from the segfault is a lot shorter now.
[05:22] <doko_> tkamppeter: did you update the hplip package as well?
[05:22] <bluefoxicy> pitti:  apport was gathering data on stratagus and I didn't care so I killlall'd apport
[05:22] <pitti> tkamppeter, doko_: I'm currently on modem (broken main network connection), sorry; doko_, can you handle this?
[05:22] <bluefoxicy> pitti:  my kernel oops'd
[05:23] <pitti> bluefoxicy: can you please file a kernel bug and discuss that with BenC?
[05:23] <tkamppeter> doko_, yes, last week, get it from http://www.freestandards.org/~till/tmp/ubuntu/edgy/hplip/
[05:23] <bluefoxicy> the constant dialog to the face is more annoying than helpful :|
[05:23] <BenC> pitti: we need to talk about that bug
[05:23] <BenC> bluefoxicy: one is already filed, so if you want, just sub to it
[05:23] <pitti> BenC: which one?
[05:24] <BenC> pitti: killing apport causing an oops
[05:24] <bluefoxicy> BenC:  I don't really care as long as you got it already.  Is there an OOPS paste from dmesg or should I throw one up?
[05:24] <pitti> BenC: yeah, I meant the bug number
[05:24] <BenC> there's one
[05:24] <BenC> bluefoxicy: it crashes in filp_close, right?
[05:25] <Kamion> doko_: we probably should, although db versions have historically been hard work to migrate. Do you know if the on-disk formats are compatible?
[05:25] <tkamppeter> doko_, mdz has approved following UVF ERs: HPLIP 1.6.7, Gutenprint 5.0.0 final, foomatic-db 20060918
[05:25] <Kamion> jdong|laptop: yes?
[05:25] <bluefoxicy> [17302895.720000]  EIP is at mutex_unlock+0x1/0x10
[05:25] <jdong|laptop> Kamion: can you do a flashplugin ~ubuntu2 backport real fast?
[05:25] <jdong|laptop> Kamion: to fix breakage, my fault, really sorry
[05:25] <Kamion> sure - what's the rush?
[05:25] <Kamion> ok
[05:25] <Kamion> is there a bug to close when I do?
[05:26] <BenC> pitti: #60183
[05:26] <doko_> Kamion: only asked infinity. he says yes. although we may need to look at the packages which use transactions
[05:26] <jdong|laptop> Kamion: yeah, let me get it for you
[05:26] <jdong|laptop> Kamion: bug 61404
[05:26] <Kamion> jdong|laptop: it's ok, I'll find it
[05:26] <Ubugtu> Malone bug 61404 in dapper-backports "Flashplugin-nonfree in backports fails to install" [High,Confirmed]  http://launchpad.net/bugs/61404
[05:26] <tkamppeter> ubugtu has a bug, see his answer to my announcement of foomatic-db-hpijs
[05:26] <Kamion> ok, thanks
[05:26] <BenC> hmm, not that one
[05:26] <doko_> tkamppeter: ok, I'll fetch the packages and upload. which packages are missing UVF exceptions?
[05:27] <Kamion> tkamppeter: that wasn't a reply to you, it was a delayed reply to slomo a couple of lines above
[05:27] <jdong|laptop> Kamion, crimsun, I'm really sorry about this one.... I mislabeled my edgy chroot as a dapper one, so that did little good in terms of testing... :(
[05:27] <BenC> pitti: I can't find the actual one right this second, but the basic problem is that it crashes when you kill apport... fixed the bug where it sometimes would crash while it was running (caused by some issues in vfs_unlink())
[05:27] <Kamion> jdong|laptop: ~ubuntu2 isn't in the archive; nothing to backport
[05:28] <Kamion> unless it's publishing right now or something
[05:28] <tkamppeter> Still waiting for approval is foomatic-filters, foo2zjs, foomatic-db-hpijs
[05:28] <jdong|laptop> Kamion: well it was very recently uploaded
[05:28] <BenC> pitti: The bug is concerning me a little because it's obviously a security issue at this point, anyone can crash the machine
[05:28] <slomo_> Kamion: which reply for me?
[05:28] <pitti> BenC: right
[05:28] <Kamion> jdong|laptop: right, I'll need to wait until it's published
[05:28] <pitti> BenC: is it just an oops, or does it have any negative system impact?
[05:28] <jdong|laptop> Kamion: ok, then, thanks so much for you quick response
[05:28] <Kamion> slomo_: 16:22 < slomo_> BenC: bug #61455
[05:28] <Ubugtu> Malone bug 61455 in linux-source-2.6.17 "asm-i386/io.h includes non-existing header file" [High,Unconfirmed]  http://launchpad.net/bugs/61455
[05:28] <pitti> BenC: anyway, from your question I infer that it's nontrivial to fix?
[05:28] <tkamppeter> But I have already asked for approval for foomatic-db-hpijs together with HPLIP, I think you can consider this one as also approved.
[05:29] <Kamion> of course this triggers Ubugtu again so we go round in circles ;)
[05:29] <BenC> pitti: just an oops in the kernel thread that called apport
[05:29] <BenC> pitti: it's non-trivial, and the only thing I can think of is making the fork that exec's apport non-killable
[05:29] <slomo_> Kamion: ah ok... as it's your archive day tomorrow... is bug #56073 ok as a sync request or shall i file a separate bug for this?
[05:29] <Ubugtu> Malone bug 56073 in xfsprogs "Include XFS corruption fix from 2.6.17.7" [Medium,Confirmed]  http://launchpad.net/bugs/56073
[05:29] <BenC> slomo, Kamion: thanks
[05:30] <Kamion> slomo_: actually my archive day is Friday
[05:30] <bluefoxicy> pitti:  may have negative system impact
[05:30] <Kamion> slomo_: yes, that's fine
[05:30] <bluefoxicy> oopsen do strange things, right now I can't kill -9 some hanging gksu processes.
[05:30] <slomo_> BenC: builds fine with sys/io.h btw
[05:30] <BenC> slomo_: good deal
[05:30] <Kamion> I'll do main syncs a bit sooner than that though to avoid beta freeze
[05:30] <bluefoxicy> stuff like this is probably related :/
[05:30] <pitti> BenC: what does it actually expect from apport?
[05:30] <tkamppeter> Should I switch all bugs fixed by my packages to "Fix committed" or only for the packages where the UVF ER was approved?
[05:31] <pitti> BenC: i. e. it seems to expect that the apport process terminates normally rather than due to a signal?
[05:31] <pitti> tkamppeter: the latter is better for now, since only approved packages can actually be uploaded now
[05:32] <BenC> pitti: I'm not sure exactly what the problem is, the crash happens in filp_close(), which is odd because that's called on the core file before we invoke apport
[05:32] <Kamion> you know, I'd be a lot more pleased with firefox's "Restore Session" thing after a crash if it ACTUALLY WORKED
[05:32] <BenC> the only thing happening after apport returns is the unlink of the core in cases where it isn't supposed to be left around
[05:33] <Kamion> beta2 is crashier than a very crashy thing
[05:33] <BenC> pitti: I fixed the vfs_unlink() I had to do that, to use inode->i_op->unlink() instead, since that is more appropriate, so maybe it fixes this problem too
[05:34] <BenC> pitti: I'm trying to see if I can reproduce the problem, and test the fix today
[05:34] <pitti> BenC: cool, thanks
[05:34] <BenC> pitti: but just wanted you to know we have a serious blocker for apport at the moment
[05:35] <BenC> last thing I want is a major security whole that is specific to ubuntu and code that I wrote :)
[05:35] <BenC> s/whole/hole/
[05:35] <BenC> I'll try caffeine and cigarettes to start
[05:36] <pitti> BenC: multivitamine juice helps as well :)
[05:36] <BenC> just doesn't have the same kick :)
[05:41] <bluefoxicy> ugh something tells me I should rm preload
[05:43] <_ion> ...or just move the job to a more suitable time.
[05:43] <bluefoxicy> It would probably help if I had DMA and 32-bit IO again though.  Maybe that will be fixed by Edgy+1.
[05:44] <bluefoxicy> _ion:  huh?  It's constant
[05:44] <_ion> Oh. I though prelink was supposed to have an exactly reverse effect.
[05:44] <bluefoxicy> no, preload o.o
[05:45] <bluefoxicy> it watches processes starting and reads files it thinks they'll use
[05:45] <_ion> Oops, i misread.
[05:45] <bluefoxicy> by watching them run and making note of what files get read
[05:45] <bluefoxicy> all I'm getting is massive disk access
[05:45] <bluefoxicy> but it WOULD help if I ever got DMA back... somewhere in the middle of Edgy I lost that
[05:50] <seaLne> mvo: didn't fix it...
[05:50] <pygi> pitti, it's out ;)
[05:51] <pygi> it even works, hehe 
[05:51] <pygi> will brb in sec
[05:53] <pygi> pitti: so it's out, the first release ^_^
[05:53] <pygi> complete libisofs rewrite, a lot of major changes in libburn and cdrskin, sweet
[05:53] <pygi> libburn is now actually usable, as opposed to 0.2.0 :)
[06:08] <Kamion> aha, purging mozilla-plugin-gnash fixes the worst of my firefox crashes
[06:12] <iwj> OK, this other crash seems to be an unrelated bug in yelp.
[06:21] <lucas> hi
[06:21] <lucas> ubuntu ships with SELINUX enabled in the default kernel, which prevents me from reading /proc/kcore to find some data I just lost by mistake
[06:22] <lucas> any idea on how to allow me to "cat /proc/kcore" ?
[06:23] <Lathiat> write a kernel module? ;)
[06:23] <Lathiat> dont panic it ;)
[06:24] <Lathiat> u sure selinux is doing that?
[06:24] <Lathiat> it says disabled at boot
[06:24] <Kamion> er, that's not selinux
[06:24] <mjg59> lucas: We don't set any selinux policies
[06:24] <Kamion> static int open_kcore(struct inode * inode, struct file * filp)
[06:24] <Kamion> {
[06:24] <Kamion>         return -EPERM;
[06:24] <Kamion> }
[06:24] <Kamion> in fs/proc/kcore.c
[06:24] <ssh_> Question: Where can I found the installer translations for edgy desktop live CD, I would like to help to review the translation.
[06:24] <lucas> erm
[06:25] <Kamion> ssh_: https://launchpad.net/distros/ubuntu/edgy/+source/debian-installer/+translations but they probably aren't quite ready to go yet
[06:25] <lucas> Kamion: is that an ubuntu specific change ?
[06:25] <ssh_> Kamion: but debian-installer is text install messages  
[06:25] <Kamion> lucas: http://www.redhat.com/archives/nahant-list/2006-February/msg00125.html
[06:26] <Kamion> ssh_: take my word for it
[06:26] <Kamion> ssh_: for the purposes of translation, they're merged
[06:26] <lucas> great.
[06:26] <ssh_> Kamion: hmm 
[06:26] <mjg59> lucas: It's not Ubuntu-specific, but it is different to upstream
[06:26] <Kamion> lucas: it's an Ubuntu patch, but not unique to us
[06:27] <lucas> ok...
[06:27] <lucas> and what about this one:
[06:27] <lucas> # cat /proc/21805/mem 
[06:27] <lucas> cat: /proc/21805/mem: No such process
[06:28] <agutierr> hi all. I have a question. What is exactly ubiquity-casper? I dont find so much information about this.
[06:29] <Lathiat> agutierr: "apt-cache show ubiquity-casper"
[06:29] <Kamion> agutierr: it's a collection of hooks exported by casper to replicate stuff that it does on live CD boot after ubiquity does the install
[06:29] <agutierr> Umm
[06:29] <agutierr> I have another question :-)
[06:29] <agutierr> This system replaces debian preseeds?
[06:30] <Kamion> agutierr: no
[06:30] <Kamion> it's orthogonal to preseeding
[06:30] <agutierr> But, its a similar system ?
[06:30] <Kamion> no
[06:30] <Lathiat> "I've had similar situation before. Just coded a small app that eat up enough of ram to push the -- otherwise inactive -- konqueror to swap space, sync()'ed /dev/hda and rebooted.
[06:30] <Kamion> it's totally unrelated
[06:30] <agutierr> Ok
[06:30] <Lathiat> lucas: 
[06:30] <mjg59> lucas: Looks like you get that if you have no ability to ptrace the process
[06:31] <lucas> why would it be like this ? I also get it for:
[06:31] <lucas> # cat /proc/$$/mem
[06:31] <lucas> cat: /proc/26648/mem: No such process
[06:40] <bddebian> Heya folks
[07:01] <kmr> with edgy about to be released, is their a place to bug a maintainer about incorporating an imporant patch. The patch has been accepted by the debian ackage, but messages send directly to the ubuntu maintainer have one unanswered: https://launchpad.net/distros/ubuntu/+source/imagemagick/+bug/44307
[07:01] <Ubugtu> Malone bug 44307 in imagemagick "Assertion failure processing ICC profiles with perlmagick" [Unknown,Fix committed]  
[07:02] <Kamion> what Ubuntu maintainer? I don't think we have anyone explicitly caring about imagemagick
[07:02] <kmr> does ubuntu have bug-smashing parties to encourage fixes of open bugs and unapplied patches?
[07:02] <Kamion> yeah
[07:03] <Kamion> I'll get that patch merged
[07:03] <kmr> Ryuichi Arafune is the maintainer listed on malone
[07:03] <Kamion> that's just the Maintainer field inherited from Debian
[07:03] <kmr> Kamion: that'll be great. it'll be one lesss package that I have to maintain in local repository -- thanks!
[07:03] <ogra> thats sadly the debian maintainer
[07:04] <kmr> Kamion: oh, that's right, ubuntu doesn't have the strong maintainer roles that debian has, is that correct?
[07:04] <ogra> so he might not be happy being mailed directly 
[07:04] <Kamion> kmr: correct
[07:04] <Kamion> kmr: erm, I'm confused
[07:04] <Kamion> kmr: the changelog in our current package has a 6:6.2.4.5-0.7 version, but it's not the same as the one you cite in that bug
[07:05] <Kamion> kmr: is it possible that the Debian maintainer dropped your NMU?
[07:05] <kmr> ogra: well, that's okay, I first filed a debian bug about 4 months before filing the ubuntu bug
[07:05] <ogra> but he fixed it in debian 
[07:05] <Kamion> actually, it's an upload from Daniel Kobras several months before your NMU
[07:05] <ogra> and might not care about ubuntu
[07:05] <kmr> ogra: yes, on Sep 10.
[07:05] <kmr> I sent email to hive back in May
[07:06] <Kamion> anyway, I've got to go and do yet more house-moving, but I'll see about figuring out what happened and merging the fix when I get back
[07:06] <ogra> Kamion, i feel with you ...
[07:06] <kmr> Kamion: I never did a nmu. Looking at the debian changelog looks like it was fixed Sept 11 someone else doing an NMU 
[07:07] <Kamion> kmr: oh, I *see*
[07:07] <kmr> Kamion: the patch I submitted was several versions ago. imagemagick has had a number of security updates.
[07:07] <Kamion> that makes sense then
[07:07] <kmr> for myself, I've been backporting my patch to each security update and storing it in alocal repository. a bit of a pain
[07:08] <kmr> Kamion: good luck with the moving. it's only a 3-line patch
[07:08] <Kamion> yeah, just need to see whether we should take the other patches in that upload too
[07:08] <kmr> removes the double freeing of strings as verify by upstream on the imagemagick-devel list
[07:08] <Kamion> we're in feature freeze so I need to be reasonably careful
[07:08] <kmr> Kamion: makes sense, appreciate your efforts
[07:09] <Kamion> your patch looks entirely unproblematic
[07:09] <micahcowan> mvo, you know python-central's broken, right?
[07:09] <Kamion> thanks for letting us know
[07:09] <kmr> Kamion: there's a careful test case Iposted on the debian bug list if you want to exercise the current bug yourself. but, I spent many hours tracking it down and verifying with upgrade
[07:09] <kmr> Kamion: thans for listening!
[07:10] <Kamion> I can probably follow through the XS well enough - it's been a few years, but :)
[07:10] <kmr> er, verifying with upstream
[07:10] <Kamion> right, I need to wait for a gparted build anyway, so time to move the tumble-dryer
[07:11] <kmr> Kamion: looking through the XS you can find where the string is freed once down deep, and then twice in the enclosng function
[07:16] <svu_tv> who would be the person to talk about edgy kernels?
[07:17] <Nafallo> svu_tv: BenC 
[07:17] <seb128> svu_tv: #ubuntu-kernel or BenC
[07:41] <jdong> Kamion: nudge, maybe flashplayer is ready now?
[07:58] <Zdra> Is there a way to have -dbg package for libnotify ? I heared there was work done to get debug symbols in stack traces in ubuntu in a new way but I don't know how...
[07:59] <Zdra> s/heared/heard/
[08:03] <svu_tv> seb128, thanks
[08:04] <elmo> zul: ping?
[08:05] <zul> elmo: pong
[08:06] <zul> elmo: whats up
[08:07] <elmo> zul: just wondering why our xen is targeted at 2.6.16 still?
[08:08] <zul> elmo: because xen-unstable is still using 2.6.16 and i havent had the chance to port it yet
[08:08] <elmo> zul: how are the debian guys producing 2.6.17 debs?
[08:08] <zul> they have it in their kernel not as s a seperate package
[08:08] <elmo> ok - but would their patch for the kernel not be usable for us?
[08:09] <elmo> I'm just kind of keen to get rid of the version desync - supporting two kernel versions is going to be a nightmare
[08:10] <zul> elmo: tell me about it, but thats the way we went because of the headaches at the beinging of the edgy cycle with alt-smp if i remmeber correctly
[08:10] <elmo> hmm
[08:11] <elmo> zul: is it too late to fix this?
[08:11] <zul> elmo: i believe so, but you would have to talk to BenC 
[08:11] <zul> i can get a 2.6.17 working this weekend though for xen
[08:12] <elmo> zul: sorry, I don't mean merged into our main kernel
[08:12] <elmo> zul: I just mean the xen kernel source being brought up to 2.6.17
[08:12] <elmo> but still being a separate + distinct copy
[08:12] <zul> elmo: i can do it this weekend
[08:12] <zul> and starting tonight of course
[08:13] <elmo> I more meant in terms of freezes and stuff, sorry I wasn't trying to pressure you or anything
[08:13] <elmo> but I guess since Xen is still in universe, that's less of/not an issue
[08:13] <zul> no problem..
[08:13] <zul> yeah the universe freeze is on the 28th i believe
[08:13] <zul> still plenty of time
[08:14] <zul> elmo: ill keep you updated ok?
[08:15] <elmo> zul: super, thanks a lot
[08:15] <zul> nop
[08:32] <BenC> elmo: I would be willing to guess that the debian guys are only applying the xen patch for the actual xen build of the kernel, not normal buids
[08:33] <BenC> elmo: The reason I don't have it in ours is because non-xen builds with the xen patch applied are broken and non-booting
[08:33] <elmo> BenC: yeah, sure, I appreciate that
[08:33] <elmo> BenC: I wasn't pushing for us to build Xen from our mainline kernel sources
[08:33] <BenC> just for 2.6.17?
[08:34] <elmo> BenC: I just wanted the separate Xen-kernel-sources to be 2.6.17
[08:34] <elmo> that way I only have to track security stuff in one kernel version
[08:34] <BenC> it would actually be nice of the xen build build-dep'd on linux-source-2.6.17, cp'd it and applied the xen patch for the build
[08:35] <BenC> s/cp/untar/
[08:35] <elmo> BenC: yeah, I agree, that'd be wonderful
[08:35] <zul> i could try :)
[08:35] <BenC> zul: you're the man, you can do it :)
[08:35] <zul> but i always updated it from the stable trees from kernel.org/git
[08:35] <BenC> or at least I think you're just crazy enough to get it working
[08:36] <zul> done it before...will do it again
[08:36] <zul> thanks though :)
[08:37] <BenC> that would be xen would be added to the ever growing list of things that need to be rebuilt when the main kernel is uploaded
[08:37] <BenC> xen would be an "always" rebuild, even for non-abi-bump uploads
[08:37] <elmo> eventually, we should just rebuild thearchive when we upload the kernel
[08:37] <elmo> \o/
[08:38] <zul> elmo: but if im bald in the next couple of days im blaming you ;)
[08:39] <zul> BenC: we still have the alt-smp stuff in edgy right?
[08:45] <BenC> zul: yeah
[08:45] <zul> greeeat...
[08:45] <fabbione> the smp-alt has been dropped from .18
[08:45] <elmo> zul: hahaha
[08:45] <fabbione> because it gives issues on some compilers
[08:46] <elmo> dropped upstream?
[08:46] <fabbione> it was merged in .17 and reverted shortly before .18 release
[08:46] <fabbione> some compilers don't like it
[08:46] <fabbione> it might go back later on with more testing
[08:46] <elmo> ah, ok
[08:47] <fabbione> xen security wise is a pain to track
[08:47] <fabbione> have been there before
[08:47] <BenC> odd that smp-alt caused problems when the core functionality has always been there
[08:47] <BenC> it's just a separate table for swapping stuff
[08:47] <fabbione> anything that touches arch/i386 or include/* will need porting and propagation
[08:48] <fabbione> BenC: according to what i read it's a compiler issue
[08:48] <fabbione> not the patch in itself
[08:49] <BenC> I guess I need to get this kernel uploaded tonight before the beta freeze
[08:50] <BenC> someone remind me when the dev meeting is this week
[08:50] <zul> 11am tomorrow
[08:50] <BenC> zul: our time?
[08:50] <zul> yep
[08:50] <BenC> thanks
[08:52] <fabbione> speaking of which.. i need to push to rookery
[08:53] <fabbione> BenC: can you give me 2 minutes to commit and push?
[08:53] <fabbione> stuff is already tested
[08:53] <fabbione> i just forgot the most interesting bits for you
[08:55] <BenC> sure thing
[09:01] <fabbione> BenC: done.. you can pull from me (edgy branch)
[09:01] <fabbione> commit e86c55006a692292bf93c44ea4373f57d44f92f4
[09:01] <fabbione>     [UBUNTU:fs/gfs2]  Update for gfs2
[09:01] <fabbione> and
[09:01] <fabbione> commit ed1c788a9576a6a99db200fc1818e26540796382
[09:01] <fabbione>     [UBUNTU: include/linux]  Export lm_interface.h
[09:01] <fabbione> they are both upstream
[09:01] <fabbione> our delta is down to 3 liners now :)
[09:06] <Seveas> sabdfl, ping
[09:07] <Seveas> Anyone around who knows where sabdfl physically is? He's supposed to chair a BOF at EuroOscon right now
[09:09] <Seveas> mdz, Kamion ?
[09:09] <Seveas> (I hate poking people, but there are a lot of people here wondering where Mark is)
[09:10] <elmo> Seveas: AFAIK he's still in London
[09:11] <Seveas> elmo, righhht...
[09:11] <Seveas> and no one notified EuroOscon?
[09:11] <elmo> I thought they had, but there's been lots of flip-flopping, and I haven't actually been involved, just overhearing stuff in the office
[09:11] <elmo> I'm not sure tho - I'll txt him
[09:12] <Seveas> thank you
[09:14] <mdz> Seveas: afaik he was scheduled to go there tomorrow
[09:16] <BenC> fabbione: done
[09:17] <elmo> Seveas: what mdz said.  He's coming tomorrow, definitely won't be there tonight.  Sorry if communication wires got crossed
[09:18] <Seveas> elmo, ok, thank you, I'll disappoint the people here 
[09:18] <elmo> Seveas: guess so, thanks
[09:57] <trappist> is there a bug to be filed if there's a gpl package in multiverse?
[09:58] <crimsun> which package?
[09:59] <trappist> xaralx
[09:59] <Burgwork> trappist, depends on a non-free rendering engine
[09:59] <trappist> ah.
[10:00] <Burgwork> multiverse is a combo of non-free and contrib from debian
[10:00] <trappist> I don't think I've run across that piece of info before
[10:01] <trappist> thanks
[10:01] <Burgwork> http://www.ubuntu.com/ubuntu/components
[10:01] <Burgwork> file a bug against the website to add that information to that page
[10:01] <trappist> can do
[10:02] <Burgwork> thanks
[10:04] <trappist> done.
[10:04] <Burgwork> cheers
[10:12] <Seveas> elmo/mdz: I chaired the BOF and it went pretty decent, people weren't too disappointed 
[10:20] <mjg59> Ok, so doing iwconfig foo power on saves a ridiculous amount of power
[10:26] <jdong> mjg59: does it? what kind of wireless?
[10:27] <mjg59> jdong: ipw2100
[10:27] <jdong> fascinating
[10:27] <jdong> on my ip3945, the difference between on and off is only like 10-20 minutes of battery life, tops
[10:29] <Burgwork> jdong, that would be half my battery life
[10:29] <jdong> note to self: get Burgwork a new battery for christmas
[10:29] <Burgwork> mjg59, how can I usefully debug why I only have 40 minutes of battery life and my laptop is brand new and gpm reports my battery is still charging to factory full
[10:30] <Burgwork> jdong, no, the sad part is: I am charge to the factory max, at least according to gpm
[10:30] <jdong> Burgwork: that means nothing if your acpi implementation is subpar 
[10:30] <jdong> Burgwork: my 4 year old toshiba claims it charges to factory max
[10:30] <Burgwork> right
[10:30] <mjg59> Burgwork: With difficulty
[10:30] <mjg59> What hardware?
[10:30] <Burgwork> toshiba tecra a5
[10:31] <jdong> hehe, toshiba, how'd I guess?
[10:31] <jdong> have I ever mentioned my factory BIOS revision didn't even report batteries to ACPI?
[10:31] <Burgwork> jdong, ouch
[10:31] <Treenaks> jdong: sounds like my Acer
[10:31] <Treenaks> which has a 'smart battery'
[10:32] <jdong> Treenaks: ouch... smart battery :-/
[10:32] <jdong> Treenaks: fortunately acer stopped doing that now :)
[10:32] <Treenaks> jdong: it works now...
[10:32] <mjg59> The Tecras are generally fine
[10:32] <Burgwork> jdong, I have an open bug that apparently my latop does not report any useful information when about half my fn keys are hit
[10:32] <mjg59> Burgwork: When on battery, what does /proc/acpi/battery/* look like?
[10:32] <Burgwork> I will check when I get home
[10:32] <mjg59> Burgwork: And yes, Toshiba changed the way their hotkeys work. We have no idea how to drive the new ones.
[10:33] <Burgwork> I got the first of the new models
[10:33] <jdong> mjg59: oh btw, do you have any idea why gpm is reporting bogus percentages to me?
[10:33] <mjg59> jdong: No
[10:34] <jdong> well that solves that problem :)
[10:34] <Burgwork> mjg59, what I am looking for in /proc/acpi/battery/* ?
[10:34] <mjg59> Burgwork: Battery rate, manufacturer values, that sort of thing
[10:34] <tseng> jdong: gpm gets them from hal
[10:34] <jdong> tseng: hal is reporting bogus
[10:34] <tseng> jdong: hal mostly gets them from your hardware
[10:35] <tseng> jdong: which is often bogus
[10:35] <jdong> tseng: /proc/acpi is correct
[10:35] <jdong> tseng: acpi -V is also correct
[10:35] <jdong> just hal is wrong
[10:35] <tseng> file a hal bug, then
[10:35] <jdong> hal used to be right before the recent hal update
[10:35] <jdong> I filed bug 60989 on this
[10:35] <Ubugtu> Malone bug 60989 in hal "HAL reports incorrect battery percentages" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60989
[10:35] <tseng> there you go, see, you know more than anyone here.
[10:36] <jdong> hal and acpi's discrepancies confuse me
[10:36] <jdong>      Battery 1: discharging, 96%, 02:33:40 remaining
[10:36] <jdong>   battery.charge_level.percentage = 100 (0x64) (int)
[10:36] <jdong> same point in time, same laptop :)
[10:36] <ph8`> Mithrandir: around? wondering if that kernel patch made it in to today's build.. because it's not working :s
[10:36] <Treenaks> jdong: multiple laptops?
[10:37] <Treenaks> jdong: uhr, multiple batteries?
[10:37] <mjg59> ph8`: Which kernel patch?
[10:37] <Treenaks> jdong: I blame the wine :P
[10:37] <jdong> Treenaks: nope, single battery :)
[10:37] <Mithrandir> ph8`: no idea; you can check the list of packages used for each cd on cdimage.ubuntu.com
[10:38] <zul> mjg59: jmicron
[10:38] <mjg59> Oh, today's build of the CD
[10:38] <wasabi__> Hmm. CUps isn't letting me login, even though I am in lpadmin
[10:38] <mjg59> Sorry, that makes more sense
[10:38] <wasabi__> pam error.
[10:39] <mjg59> present rate:            8895 mW
[10:39] <mjg59> Not bad
[10:39] <ph8`> Mithrandir: HI, here? -> http://cdimage.ubuntu.com/daily/20060920/source/edgy-src-1.list
[10:41] <ph8`> i can't find anything with kernel in the name
[10:41] <shining> isn't it linux-image ?
[10:42] <ph8`> good point, nothing with '-image' in it though either, apart from 3 unrelated pkgs
[10:42] <Mithrandir> ph8`: why are you looking at the lists for the source images?
[10:42] <Mithrandir> http://cdimage.ubuntu.com/daily/20060920/edgy-alternate-i386.list is more likely what you want
[10:43] <ph8`> because that was the only list that might resemble what i'm after? ;)
[10:43] <shining> there is linux-source
[10:43] <ph8`> cheers
[10:43] <ph8`> so..
[10:43] <ph8`>  /pool/main/l/linux-source-2.6.17/linux-image-2.6.17-8-generic_2.6.17-8.22_i386.deb
[10:43] <ph8`>  /pool/main/l/linux-source-2.6.17/linux-image-2.6.17-8-386_2.6.17-8.22_i386.deb
[10:43] <ph8`> wondering how to find whether that's meant to contain the bugfix i'm after or not
[10:44] <mjg59> -8 contains the code
[10:44] <mjg59> -7 doesn't
[10:44] <ph8`> so, if i'm using the alternate img..
[10:44] <ph8`> that should also contain the jmicron 'fix'?
[10:45] <ph8`> or will it for some bizarre reason only be on i386?
[10:45] <mjg59> It should, yes
[10:45] <ph8`> unfortunately the fix doesn't work then
[10:45] <mjg59> You'll need to check the amd64 data to be sure
[10:45] <ph8`> bugger.
[10:45] <ph8`>  /pool/main/l/linux-source-2.6.17/linux-headers-2.6.17-8_2.6.17-8.22_amd64.deb
[10:45] <ph8`> :(
[10:46] <ph8`> oh that's mega-rubbish
[10:46] <ph8`> i'll see about reopening the bug or something
[10:46] <Keybuk> version recommends are still useless, aren't they?
[10:51] <wasabi__> Looking at a package published in dapper-updates through launchpad. There anyway to find the changelog?
[11:18] <micahcowan> wasabi, if you're looking at a source package, the changelog is available at the top of the left-hand column.
[11:18] <micahcowan> Check https://launchpad.net/distros/ubuntu/edgy/+source/opie for example
[11:20] <jdong> Keybuk: poke?
[11:22] <jdong> Keybuk: when you get a chance, can you do the backport in bug 61404?
[11:22] <Ubugtu> Malone bug 61404 in dapper-backports "Flashplugin-nonfree in backports fails to install" [High,Confirmed]  http://launchpad.net/bugs/61404
[11:22] <jdong> Keybuk: the ~ubuntu2 edgy release should be there by now
[11:34] <Keybuk> jdong: no, I disagree with that
[11:35] <Keybuk> the ubuntu2 in edgy should be reverted
[11:35] <Keybuk> bugs in dapper-backports should not be worked around in edgy
[11:35] <jdong> Keybuk: ok, then should a manual upload be done instead?
[11:50] <Keybuk> jdong: then that's not a backport, no?
[11:52] <jdong> Keybuk: can we just fix this one this way for now, since it's already been done?
[11:52] <jdong> Keybuk: before I break too many people's flash
[11:53] <Keybuk> sure, but at this point it's probably worth discussing improvements to your "ok for backporting" procedure
[11:53] <Keybuk> as that didn't pick this up
[11:54] <jdong> Keybuk: yeah, my stupidity is to blame for this one :(
[11:56] <Nafallo> Keybuk: want to sync erlang and ejabberd while you're at it? :-)
[11:57] <Keybuk> Nafallo: there's no request for those
[11:57] <Nafallo> 6116[79] 
[11:58] <Nafallo> there are :-). the bugs above.
[11:58] <Keybuk> ubuntu-archive has not been subscribed to those bugs
[11:58] <Nafallo> aha, subscribed.
[11:58] <Nafallo> I was told assign.
[11:59] <Keybuk> yes, the policy says subscribed
[11:59] <Keybuk> it explicitly says "do not assign"
[12:00] <Nafallo> oh? I can't find that in the mail to ubuntu-devel-announce.
[12:01] <Nafallo> I've subscribed them now though.
[12:01] <Kamion> Keybuk: are you doing flashplugin-nonfree then?
[12:01] <Kamion> as I was about to
[12:01] <Kamion> Nafallo: http://wiki.ubuntu.com/DeveloperResource
[12:01] <Kamion> s
[12:01] <Kamion> sorry, dicky s key
[12:02] <Nafallo> aha.
[12:02] <Nafallo> didn't know that this time, will do next time :-)
[12:02] <Kamion> which was the originally-announced sync policy post-soyuz
[12:02] <Kamion> we've tweaked it a bit since, but ...
[12:02] <Keybuk> Kamion: have done it
[12:03] <Kamion> ok
[12:03] <Nafallo> I was working after that, I only just found time to get back now :-).
[12:03] <Nafallo> anyway. will you do them Keybuk? :-)
[12:03] <Keybuk> Nafallo: no, not today
[12:04] <Nafallo> okidoki.
[12:04] <Keybuk> I doubt I will have sufficient round tuits
[12:04] <Nafallo> hmm, is it just me or has the wiki become awfully slow lately?
[12:04] <Keybuk> it has
[12:06] <Fujitsu> Like, really really slow.
[12:06] <Fujitsu> Any idea why?
[12:06] <Keybuk> probably LP authentication related
[12:06] <Keybuk> (random guess)
[12:07] <Fujitsu> When in doubt, blame LP :P
[12:07] <Keybuk> exactly
[12:07] <Nafallo> hehe
[12:07] <Fujitsu> Probably right, LP is the source of everything that goes wrong :P