[12:17] <ajmitch> morning
[12:17] <ajmitch> Hobbsee: you're up far too early
[12:18] <Hobbsee> morning all
[12:18] <Hobbsee> ajmitch: i'm at uni, too
[12:18] <Hobbsee> yay for 20 min drives that take 40.
[12:18] <ajmitch> wonderful
[12:49] <LaserJock> wahoo, I've got -1% battery left :-)
[12:49] <Hobbsee> LaserJock: hah!
[12:49] <Hobbsee> LaserJock: find a powerpoint?
[12:49] <LaserJock> hm?
[12:50] <Hobbsee> if you've got -1% battery left?
[12:50] <ajmitch> LaserJock: plug your laptop in
[12:51] <LaserJock> it is
[12:51] <LaserJock> it hibernated
[12:51] <LaserJock> and now it says fully charged
[12:51] <LaserJock> weird
[01:00] <bluefoxicy> I still don't have DMA... does anyone else not have DMA?
[01:00] <bluefoxicy> erf.
[01:28] <DarkMageZ> hmm anyone got any idea on this? http://paste.ubuntu-nl.org/21246 i had permissions set to 777 and it still happened :(
[01:30] <TLE> Hi, I'm tring to patch metacity following the guidelines in MOTU School https://wiki.ubuntu.com/MOTU/School/PatchingSources. But the debian/rules file in metacity has no patch section, it does however include this file /usr/share/cdbs/1/rules/simple-patchsys.mk which have "post-patches, apply-patches and debian/stamp-patched" sections, which one of these should I use instead ?
[01:31] <ajmitch> TLE: you don't need to modify debian/rules since it's alreayd using a patch system
[01:33] <TLE> ok, but then, can I apply them manually or should I use one of the patch managing tools ?
[01:34] <ajmitch> you can use cdbs-edit-patch for creating it
[01:34] <TLE> thanks
[01:56] <\sh> moins
[01:56] <ajmitch> hi \sh
[01:57] <ajmitch> back later :)
[01:57] <LaserJock> hi \sh
[01:58] <\sh> oh wow...I need to get up in one hour...
[01:59] <zul_> hey/bye ajmitch
[01:59] <hub> hey \sh
[02:00] <\sh> moins hub, how's life?
[02:01] <hub> \sh: it is ok
[02:01] <hub> could be better
[02:03] <\sh> hub: agreed :)
[02:26] <fbond> bddebian, hi
[02:27] <fbond> bddebian: I'm using dh_installdebconf, shouldn't that take care of any debconf-related stuff?  It was before...
[02:34] <TLE> Does any of you have time for a newbie source code patching question?
[02:49] <bddebian> TLE: Ask away, we'll give it a shot
[02:49] <bddebian> fbond: It should but lintian is still complaining :-(
[02:49] <bddebian> Heya welshbyte
[02:50] <fbond> bddebian, got it sorted: I was running dh_installdebconf after dh_installdeb
[02:50] <hub> is there a way to tell pbuilder to grab packages without setting up an apt repository?
[02:50] <welshbyte> ello bddebian
[02:50] <bddebian> fbond: Ah, nice
[02:51] <fbond> hub: don't think so, although setting up a simple local repo will only take you ... an hour or two
[02:51] <bddebian> hub: ?
[02:51] <fbond> unless you've done it before
[02:51] <bddebian> Oh
[02:51] <hub> fbond: an hour or two. gotcha
[02:51] <fbond> :)
[02:51] <fbond> maybe not, if you read fast
[02:52] <hub> bddebian: yeah, I'm packaging a package that needs a library I have packaged but that is not yet in the archive
[02:52] <bddebian> hub: Aye, sorry, I misunderstood you at first :)
[02:52] <hub> http://revu.tauware.de/details.py?upid=2905 <- that one I need to provide
[02:52] <fbond> bddebian, still one issue that i haven't managed to dodge: lintian complains about no-debconf-config
[02:53] <fbond> i'm not sure what a debconf config would contain, or the name of the file that would contain it...
[02:55] <bddebian> fbond: Hmm.  I'm not fluent at all in debconf stuff :-(
[02:56] <fbond> yeah, I've never messed with it before either...
[03:01] <fbond> ahh...
[03:06] <bddebian> Ack, diacanvas2 is broken
[03:10] <fbond> bddebian, ok, all debconf issues should be sorted now, sorry about that
[03:10] <fbond|away> I'll check back in at revu tomorrow
[03:10] <fbond|away> good night
[03:10] <fbond|away> :)
[03:15] <TLE> ok. I'm trying to create a true patch for metacity using cdbs-edit-patch. When I run it with "cdbs-edit-patch 020-twinview-modification.patch" it completes alright, and I get to the edit subshell, but it also gives this error "make[1] : *** No rule to create target 'distclean'." (Maybe not exact wording I'm translating it from Danish). Is that something I should worry about and if so, do you any idea of what the problem is ?
[03:26] <bddebian> fbond|away: Don't be sorry, there is a lot I don't know man :)
[03:31] <Burgundavia> hub: this dcraw upload got anything new and interesting?
[03:31] <hub> yeah
[03:31] <hub> -e to get the previews
[03:31] <hub> digikam 0.9 needs it
[03:31] <hub> and more camera supporteds
[03:38] <Burgundavia> hub: can you add it to https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue11 under new apps in edgy?
[03:40] <hub> Burgundavia: they are updated
[03:40] <hub> ufraw too
[03:40] <Burgundavia> hub: can you add a little section on photo stuff?
[03:41] <hub> yeah
[03:41] <hub> hugin is still in the queue. when it goes thru it will be a new app
[03:41] <Burgundavia> very cool
[04:04] <bddebian> Hmm, it appears that diacanvas2 might not have been moved to the new policy properly
[04:04] <bddebian> TLE[Sleeping] : Crap, sorry, I missed your question :-(
[04:04] <TLE[Sleeping] > I'm still here
[04:05] <bddebian> TLE[Sleeping] : Don't worry about that error, just make your changes and then exit
[04:06] <TLE[Sleeping] > bddebian: Ok great. Planning to provide that patch in a howto, so I'd just like be sure sure that everything is as it is supposed to be. Thanks
[04:25] <bddebian> Why would this be in python-diacanvas2.files:  usr/lib/python2.2 ?
[04:25] <crimsun> a merge? because it was never updated?
[04:25] <bddebian> crimsun: This is a sync from Debian afaict
[04:25] <crimsun> then it just wasn't updated
[04:25] <bddebian> The Debian maintainer moved it to python-support but it's broken
[04:25] <crimsun> easily fixed, debdiffed, and gotten on with life.
[04:26] <bddebian> Should it be /usr/lib/python-support ?
[04:26] <crimsun> I wouldn't even use .files
[04:27] <bddebian> aye
[04:35] <bddebian> Man this thing is all broken
[04:35] <bddebian> Ahhhh MAXPATHLEN
[04:35] <bddebian> whoops, wrong chan, sorry :-)
[05:05] <bddebian> crimsun: Still around?
[05:05] <crimsun> sort of. I'm meeting with the chair atm.
[05:05] <bddebian> Heh
[05:06] <bddebian> crimsun: Well if you get a sec and don't mind, could you look at:  http://pastebin.us/3488
[05:11] <bddebian> Heya Hobbsee
[05:11] <Burgundavia> hey Hobbsee
[05:11] <joejaxx> good cross platform svn ide client ? anyone know of one?
[05:12] <joejaxx> Hobbsee: ! :)
[05:12] <Burgundavia> Hobbsee: uwn has very little KDE/Kubuntu content. Care to provide some for next week?
[05:12] <Hobbsee> hi bddebian
[05:12] <Hobbsee> hi everyone else
[05:12] <Hobbsee> hi Burgundavia, joejaxx
[05:12] <Hobbsee> Burgundavia: define "next week" - how many days?
[05:13] <Burgundavia> Hobbsee: this saturday, midnight Pacific time is your deadline
[05:14] <Hobbsee> Burgundavia: cool.  hopefully we'll have amarok 1.4.2 by then, depending on mdz, and when they actually release the thing
[05:14] <Burgundavia> Hobbsee: you make my heart sing
[05:14] <joejaxx> does anyone here work with svn?
[05:15] <bddebian> Damn I hate days where nothing is going my way :-(
[05:15] <joejaxx> hmm maybe not lol
[05:17] <Burgundavia> joejaxx: some, what is the issue?
[05:18] <joejaxx> Burgundavia: i was wondering what a good cross platform svn ide was
[05:19] <Burgundavia> joejaxx: you asking me about Windows and OS X? sorry, canna help you
[05:19] <Burgundavia> I use gedit
[05:19] <joejaxx> Burgundavia: for svn?
[05:19] <joejaxx> they have a plugin for it?
[05:20] <Burgundavia> no, I just use the command line
[05:24] <hub> joejaxx: svn
[05:24] <hub> joejaxx: the command line tool
[05:25] <joejaxx> hub: cross platform :\
[05:25] <hub> again
[05:25] <hub> svn in command line
[05:26] <hub> works the same EVERYWHERE
[05:28] <joejaxx> hub even on windows?
[05:28] <hub> as far as I know
[05:28] <hub> I don't use windows
[05:28] <hub> so I don't care
[05:28] <Burgundavia> hub: does it need cygwin?
[05:28] <hub> Burgundavia: don't ask too many questions
[05:29] <hub> Burgundavia: again: I don't do Windows
[05:29] <hub> I just know that it works
[05:29] <hub> worst case scenario just use tortoiseSVN
[05:30] <Burgundavia> true, tortiose is quite nice
[05:31] <hub> doesn't emacs have a svn mode?
[05:41] <bddebian> Any python experts awake?
[05:42] <Burgundavia> bddebian: no, but I watched Snakes on a Plane last night
[05:42] <bddebian> Heh.  Was it any good?
[05:42] <Burgundavia> very very bad.  That is what made it funny
[06:02] <AnAnt_> lionelp: you awake ?
[06:16] <crimsun> bddebian: looks like a pygobject bug anyhow.
[06:17] <bddebian> Aye
[06:18] <bddebian> Hmm, it seems to be there though..
[06:18] <bddebian> root@bdubuntu1:/var/lib/python-support/python2.4/gtk-2.0# grep -r write_source *
[06:18] <bddebian> dsextras.py:        from codegen import register_types, write_source, FileOutput
[06:18] <bddebian> dsextras.py:        write_source(dp,
[06:18] <bddebian> Binary file dsextras.pyc matches
[06:19] <bddebian> Unless pygtk itself is broken
[06:22] <crimsun> bddebian: it would be a pygobject bug.
[06:29] <bddebian> Is there a way to run python setup.py interactively so I can see what it's doing?  It seems to work from the command line
[06:52] <bddebian> Gnight folks
[07:00] <Arbiter> yawn
[07:01] <Arbiter> hi folks
[07:46] <Arbiter> heya Hobbsee
[07:46] <Arbiter> :)
[07:49] <Hobbsee> hey Arbiter
[07:51] <Arbiter> Hobbsee: would you review kdocker? :D
[07:52] <Arbiter> http://revu.tauware.de/details.py?upid=2907 :D
[07:52] <Hobbsee> Arbiter: wasnt that already in the archives?  i thought it got advocated ages ago?
[07:53] <Arbiter> no... there was a building problem with updated edgy packages
[07:53] <Hobbsee> Arbiter: bddebian replied to it again
[07:53] <Arbiter> no
[07:54] <Arbiter> it didn't hit the archives :D
[07:54] <Hobbsee> Arbiter: it takes a while for packages to get thru NEW
[07:54] <Arbiter> i've alredy looked for it in NEW queue
[07:54] <Arbiter> and it's not in NEW queue :P
[07:54] <Hobbsee> ah right
[07:55] <Arbiter> ;)
[07:57] <Hobbsee> Arbiter: does it happen to need dh_iconcache, btw?
[07:58] <Arbiter> hm...
[07:59] <Arbiter> why?
[07:59] <Arbiter> (it needs dh_iconcache)
[08:00] <Hobbsee> it does?
[08:00] <Hobbsee> hmm, it doesnt seem to install files to those directories
[08:01] <Hobbsee><EMAIL_ADDRESS>[08:02] <Arbiter> Hobbsee: i think it's not needed (dh_iconcache)
[08:02] <Hobbsee> Arbiter: cool, ok
[08:03] <unix_infidel> hey guys, quick question, after upgrading and doing a fresh install to dapper i've noticed that when after i've installed vim-gnome vim-gtk, there are no options for colorscheme in the menu and appending the gvimrc file correctly displays an error.
[08:03] <unix_infidel> did the maintainers take out that option from the package.
[08:03] <unix_infidel> (it was available in breezy)
[08:04] <Hobbsee> Arbiter: looks good to me.   test building
[08:08] <unix_infidel> erm, anyone?
[08:08] <Fujitsu> What do you wish to know?
[08:08] <Arbiter> Hobbsee: alredy tested with an updated pbuilder
[08:09] <Arbiter> Hobbsee: i always test my packages with pbuilder
[08:09] <unix_infidel> Fujitsu: whether the maintainers took out colorscheme with the new vim packages.
[08:09] <Hobbsee> Arbiter: cool.  but i'm paranoid :)
[08:09] <Arbiter> my old pbuilder built the package with no problems
[08:09] <Arbiter> two days ago i try to build the package with an updated pbuilder and... BOOOM
[08:09] <Arbiter> build errors :D
[08:10] <Arbiter> (that i never had before :P)
[08:10] <Fujitsu> Have you checked the changelog, unix_infidel?
[08:10] <unix_infidel> Fujitsu: for the package for or the vim software?
[08:10] <Fujitsu> The package.
[08:10] <unix_infidel> let me give it a gander
[08:11] <Hobbsee> Uploading via ftp kdocker_1.3-0ubuntu1.dsc: done.
[08:11] <Hobbsee> Uploading via ftp kdocker_1.3.orig.tar.gz: done.
[08:11] <Hobbsee> Uploading via ftp kdocker_1.3-0ubuntu1.diff.gz: done.
[08:11] <Hobbsee> Uploading via ftp kdocker_1.3-0ubuntu1_source.changes: done.
[08:11] <Hobbsee> Arbiter: ^
[08:11] <unix_infidel> Fujitsu: nothing of significance there.
[08:12] <Fujitsu> unix_infidel, you sure it wasn't removed from upstream?
[08:12] <Arbiter> Hobbsee: huh?
[08:12] <unix_infidel> Fujitsu: it mentions that "    + 6.1.065: VMS: The colorscheme, keymap and compiler menus are not
[08:12] <unix_infidel>       filled in.
[08:13] <Arbiter> ahhh understood :D
[08:13] <unix_infidel> which seems as if they mean to say that the menu's are not aviailable, but the option in the gvimrc should be valid no?
[08:13] <Fujitsu> unix_infidel, probably.
[08:13] <Fujitsu> I really don't know.
[08:13] <Hobbsee> Arbiter: means that it's been uploaded to the archives
[08:13] <unix_infidel> argh!
[08:13] <unix_infidel> :(
[08:13] <Arbiter> Hobbsee: yup :)
[08:14] <Arbiter> thanks Hobbsee :)
[08:14] <Hobbsee> Arbiter: not a problem
[08:14] <Arbiter> ah Hobbsee...
[08:14] <Arbiter> would you sponsor me for tomorrow's CC? :D
[08:14] <Arbiter> (i wanna apply for membership ;) )
[08:14] <Hobbsee> Arbiter: is it at 6am?
[08:14] <Arbiter> 6pm here :D
[08:14] <Hobbsee> 2000UTC?
[08:16] <Arbiter> yup
[08:16] <bluefoxicy> has anyone figured out what xchat-gnome does with the paste buffer?
[08:16] <bluefoxicy> it seems to have ADHD
[08:17] <Hobbsee> Arbiter: but not at 2am
[08:18] <Arbiter> Hobbsee: awww no problem then :D
[08:18] <unix_infidel> anyone know who the maintainer(s) for the vim packages are?
[08:18] <Arbiter> i'll ask Gloubiboulga when he connects :)
[08:18] <Fujitsu> unix_infidel, apt-cache show vim
[08:18] <unix_infidel> erm, nvm.
[08:18] <Arbiter> Hobbsee: kdocker is in NEW queue :) thanks again
[08:19] <Hobbsee> Arbiter: yay :)
[08:19] <unix_infidel> Fujitsu: yea, maybe the better question is if ANYONE of them in here.
[08:19] <Fujitsu> unix_infidel, doubtful, this isn't a Debian channel.
[08:19] <unix_infidel> Fujitsu: hrm.  Thanks.
[08:19] <unix_infidel> I'll ask in #debian then, thanks a lot man.
[08:20] <unix_infidel> appreciate it.
[08:20] <Fujitsu> No problem, I hope you have some luck.
[08:46] <ttyfscker> is there anyone in here that has any authority over this gnomefreak guy?
[08:47] <Hobbsee> ttyfscker: any of the ops, see #ubuntu-ops
[08:47] <ttyfscker> Hobbsee:: thanks
[09:01] <bluefoxicy> Yagisan:  which
[09:02] <Yagisan> bluefoxicy, u-d where you tell me you don't care about k8
[09:02] <bluefoxicy> Jones?
[09:02] <Yagisan> bluefoxicy, that's great, but not what I asked
[09:03] <Yagisan> bluefoxicy, that's me. btw, no need to CC in future - I've been here a long time ;)
[09:03] <bluefoxicy> yeah, K8 kernels generally break things, or don't use K8 instructions (the k8 doesn't bring any added insns in 32-bit mode)
[09:03] <Yagisan> bluefoxicy, I'm talking about the *hardware* I have to test
[09:03] <bluefoxicy> oh
[09:04] <bluefoxicy> I thought you meant K7/K8 kernels on K7/K8 boxes
[09:04] <bluefoxicy> not i686 on K8
[09:04] <Yagisan> bluefoxicy, I doubt there is much difference, but, I'd rather not see a decision based on 2 Intel boxes that may or may not be typical
[09:05] <bluefoxicy> Yagisan:  nods.  Do you know if they're assulting the kernel or if they're testing real-world user programs?
[09:06] <bluefoxicy> overall the kernel accounts for 18% of CPU time
[09:06] <bluefoxicy> (including syscalls, scheduling, mm, etc-- anything in kernel mode)
[09:07] <bluefoxicy> so if they're assulting the kernel, multiply the numbers by 0.18 to get the real world impact.  :)
[09:08] <bluefoxicy> if they're relying on a "typical program" then all bets are off; there's no telling how much time it spends in the kernel versus how much time it spends in userspace
[09:08] <Yagisan> bluefoxicy, I suspect a kernel assult, but, I need a monkeys guide to reproduce it. I'm a monkey
[09:08] <bluefoxicy> I would imagine this would average 18%, but I don't have a standard deviation ;)
[09:08] <bluefoxicy> Yagisan:  nods
[09:08] <Yagisan> my real worls apps hardly match a standard desktop though
[09:09] <bluefoxicy> i need to sleep now
[09:09] <bluefoxicy> it's 3am
[09:09] <bluefoxicy> keep in mind I am  mostly full of conjecture, some of which is based on numbers I've measured
[09:10] <bluefoxicy> (for example I've used a full oprofile of my system to find out PIC vs main executable vs kernel CPU time)
[09:40] <Fujitsu> Any MOTUs here that can check/upload 6 merges for me?
[09:40] <Fujitsu> Aha
[09:40] <StevenK> I'm here, but I don't have the time at the moment.
[09:40] <ajmitch> if you want, I can look later
[09:41] <Fujitsu> OK, they're at http://people.ubuntu.com.au/~fujitsu/merges/
[09:41] <ajmitch> ok
[09:41] <ajmitch> ask me later when I'm back :)
[09:41] <Fujitsu> OK, I shall.
[09:42] <Fujitsu> Thanks :)
[09:48] <Gloubiboulga> morning MOTU world
[09:49] <Hobbsee> hi Gloubiboulga
[10:00] <Goshawk> ji
[10:00] <Goshawk> hi
[10:19] <Plug> If VISUAL and EDITOR are both set to vim, why does dch run nano?
[10:20] <imbrandon> Plug: you can change it via update-alteritives but i think it should hounor EDITOR
[10:20] <Plug> yeah, I just thought of that
[10:20] <Plug> it runs 'sensible-editor'
[10:21] <imbrandon> sudo update-alternatives --config editor
[10:21] <imbrandon> ;)
[10:21] <Plug> yay
[10:21] <Plug> cheers
[10:22] <ajmitch> evening Plug
[10:22] <Plug> hi
[10:22] <imbrandon> heya ajmitch
[10:23] <ajmitch> Plug: fixed the version?
[10:24] <Plug> yeah
[10:28] <imbrandon>  /stats p
[10:28] <imbrandon> erm
[10:29] <Fujitsu> Are you back, ajmitch?
[10:29] <ajmitch> sort of
[10:29] <Fujitsu> ie. no.
[10:30] <ajmitch> ie I have food now & am eating it :)
[10:32] <Fujitsu> Good evening, Mithrandir.
[10:32] <Nafallo> Mithrandir: yay! you're alive :-)
[10:32] <Mithrandir> hiya Fujitsu
[10:32] <Nafallo> Mithrandir: how are you? except you should have sucky connection atm :-P
[10:32] <Mithrandir> Nafallo: yeah, been on vacation.
[10:32] <Mithrandir> the connection is quite sucky.
[10:33] <Fujitsu> :(
[10:33] <Fujitsu> Hey, mine is 28.8kbps, but stable.
[10:33] <Nafallo> hmm
[10:33] <Nafallo> mine is stable at 10240/1024kbps ;-)
[10:34] <Fujitsu> 1024/1024, or 10240/1024?
[10:35] <imbrandon> mine is a nice stable 8192/1024kbps ;)
[10:36] <Mithrandir> we're sharing a wireless 2Mbit here.
[10:36] <imbrandon> Mithrandir: better than dialup i guess ;)
[10:36] <Plug> When should you have an orig.tar.gz ?
[10:36] <imbrandon> Plug: for every package
[10:42] <Nafallo> 10/1Mbit
[10:43] <Nafallo> Mithrandir: huga! you should check out the FON maps for something faster wireless then. or atleast stable :-).
[10:44] <Plug> ajmitch: take that!
[10:44] <Plug> (if REVU updates)
[10:53] <Plug> REVU never emailled me either, if anyone can help with that
[11:10] <Plug> right
[11:11] <Plug> who wants to review my package! :)
[11:11] <Nafallo> Plug: ajmitch :-)
[11:27] <Fujitsu> Any MOTUs suitable for checking/uploading merges around?
[11:28] <imbrandon> Fujitsu: i'm busy atm but in an about 2 hours i can spend some time on it if you give me a url or shoot me an email
[11:30] <imbrandon> Fujitsu: also do you know about the LP universe sponsors team ? find the bug report ( or file one ) and attcahe the debdiff then subscribe ( not assign ) the team
[11:30] <imbrandon> that way MOTU's can get to it when they have time if you are not on irc or if they dont come onto irc
[11:30] <Fujitsu> I'd seen the email on that, yes.
[11:30] <Fujitsu> True.
[11:30] <Fujitsu> I'll do that, I think.
[11:30] <imbrandon> ;)
[11:30] <Fujitsu> debdiff between Debian current and the new Ubuntu one?
[11:31] <imbrandon> between ubuntu current and the new one
[11:31] <imbrandon> since thats what will be uploaded
[11:31] <Fujitsu> Ah, OK.
[11:32] <Fujitsu> OK.
[11:32] <imbrandon> i would mention the url to the MoM report also for merges
[11:32] <Fujitsu> Shall do.
[11:33] <Fujitsu> Thanks :)
[12:12] <Nafallo> siretart: ping
[12:15] <Nafallo> hmm
[12:15] <Nafallo> the ubuntu branch of pbuilder is out of date :-P
[12:36] <imbrandon> heh
[02:59] <welshbyte> good afternoon
[02:59] <zul> morning
[03:48] <bddebian> Heya gang
[03:48] <Nafallo> bddebian: morning
[03:50] <bddebian> Hi Nafallo
[03:53] <bddebian> crimsun: You actually here?
[04:11] <crimsun> bddebian: I won't be, no. I can check back in 4 hours after today's lectures.
[04:14] <bddebian> crimsun: NP, thx
[04:23] <Goshawk> hi, howto obtain the REVU password? the lostpw.py script seems to be bugged
[04:32] <Nafallo> hehe
[04:32] <Hobbsee> hi dholbach
[04:32] <Nafallo> rothera should be unavailable for some hours now I guess ;-)
[04:32] <Hobbsee> dholbach: arent you on holidays?
[04:32] <dholbach> Hobbsee: i'm back again
[04:32] <Nafallo> Hobbsee: look at his cloak to know where he is ;-)
[04:32] <dholbach> Hobbsee: on the distro sprint
[04:33] <Hobbsee> dholbach: nice :)
[04:33] <Hobbsee> Nafallo: true that
[04:33] <Hobbsee> dholbach: so is this the distro sprint where you sprint to get to the beer?
[04:33] <Nafallo> haha
[04:33] <dholbach> to get to the beer?
[04:34] <tseng> Hobbsee: have you been to a conference?
[04:34] <Hobbsee> s/beer/whatever alcoholic beverage you prefer/
[04:34] <tseng> Hobbsee: you don't get to any beer until after 10pm
[04:34] <Hobbsee> tseng: no.  if i had, i suspect you would have remembered me.
[04:34] <tseng> oh, I am not a regular attendee
[04:34] <Hobbsee> true - but you would likely recognise a weird alien face from photos of them
[04:35] <tseng> oh
[04:35] <Hobbsee> Mithrandir: how'd the wedding go?
[04:35] <Mithrandir> Hobbsee: excellent.  Everything went smoothly and just as planned.
[04:35] <Hobbsee> Mithrandir: yay :)
[04:35] <azeem> w34
[04:35] <azeem> eh.
[05:02] <hub> *sigh*
[05:02] <hub> what is upstream tarball has CVS files?
[05:03] <Nafallo> hub: then bug the hell out of them :-)
[05:05] <azeem> hub: if you want, you can repackage it, but using the prestine upstream tarball might outweigh having those files in it
[05:05] <hub> azeem: I already have to bz2 -> gz
[05:05] <azeem> ah, ok
[05:05] <azeem> (Ubuntu supports bz2 I think)
[05:05] <hub> but I do that with a bzcat | gzip -9c
[05:06] <hub> azeem: Debian does not
[05:06] <azeem> yeah
[05:06] <hub> no biggie
[05:07] <hub> my biggest problem is to actually build the thing
[05:07] <hub> I don;t have enough RAM to *build*
[05:07] <Hobbsee> hub: ssh to someone else's machine that *does*
[05:07] <hub> Hobbsee: easier to say than to do
[05:08] <hub> Hobbsee: the only machines I have with 1gb are:
[05:08] <Hobbsee> hub: true
[05:08] <hub> 1/ the work laptop: runs Xandros
[05:08] <Mithrandir> or use swap.
[05:08] <hub> 2/ the MacMini: runs MacOS X
[05:08] <hub> Mithrandir: yeah right, that is actually what happens
[05:08] <azeem> hub: you could build in a chroot on your xandros box
[05:08] <Mithrandir> hub: use a chroot on the xandros box?
[05:08] <hub> Mithrandir: gcc does not like that
[05:08] <hub> azeem: I need ot deboostrap it
[05:08] <hub> azeem: even the work desktop only have 512MB
[05:09] <hub> I have one runnin Edgy
[05:09] <hub> amd64
[05:09] <Mithrandir> 512 MB of memory.  Those were the days.
[05:10] <hub> Mithrandir: 4 of the source files need over 300MB just for gcc
[05:10] <hub> don't try that swapping
[05:40] <hub> fsck
[05:40] <hub> I have to get ubuntu debootstrap script?
[05:40] <azeem> probably
[05:41] <hub> *sigh*
[05:41] <hub> and I guess Debian will never include them in the upstream deboostrap
[05:42] <azeem> hub: well, it has warty and hoary
[05:42] <azeem> debootstrap in Debian hasn't been updated for half a year or so
[05:42] <azeem> actually, there's breezy as well, my bad
[05:43] <hub> azeem: not the one from sarge
[05:43] <hub> :-/
[05:43] <azeem> sure :)
[05:43] <azeem> Ubuntu almost didn't exist back then
[05:43] <hub> it did
[05:44] <azeem> right, but debootstrap was in some sort of maintenance mode
[05:44] <hub> like the whole debian
[06:34] <engla> so this is a question, if I want to package applications for ubuntu, do I sign up for long-term maintainership?
[06:34] <LaserJock> not really
[06:34] <LaserJock> we have a team maintainership style in Ubuntu
[06:35] <LaserJock> but we would rather people hang around as much as they can :-)
[06:35] <engla> I'd like to try to package two apps for ubuntu. One I myself wrote and one 3rd party I like
[06:36] <engla> I've already made buildpackage debs, the only thing I don't know how to handle is pbuilder
[06:38] <bddebian> LaserJock: You're a Python expert now right? ;-)
[06:38] <bddebian> Hi BTW :-)
[06:39] <LaserJock> bddebian: haha
[06:39] <LaserJock> engla: have you seen the Ubuntu Packaging Guide, there is a pbuilder section in there
[06:39] <LaserJock> help.ubuntu.com is the place to find it
[06:39] <LaserJock> bddebian: what do you need?
[06:40] <bddebian> LaserJock: I need to know why this: http://pastebin.us/3488  happens
[06:40] <engla> LaserJock: thanks
[06:43] <LaserJock> bddebian: sorry, I really haven't a clue
[06:43] <LaserJock> bddebian: do you know if it works outside pbuilder?
[06:44] <bddebian> LaserJock: Dunno but I can run python setup.py without errors inside of a pbuilder login
[06:45] <LaserJock> weird
[06:48] <bddebian> Aye
[06:50] <fbond|away> bddebian, it's probably the environment variables that are being defined
[06:50] <fbond|away> try separating build and install
[06:50] <fbond|away>  ... maybe?
[06:50] <bddebian> I wondered about that.  The line in debian/rules looks a little funky
[06:51] <fbond|away> exporting those vars I believe affects where things are installed as well as where things are searched for ...
[06:51] <fbond|away> that could cause the import to fail
[06:52] <bddebian>         cd python && LIBRARY_PATH=../debian/tmp/usr/lib PKG_CONFIG_PATH=../debian/tmp/usr/lib/pkgconfig $(subst $(PYDEF),python,$*) setup.py install --no-compile --root=../debian/python-diacanvas2
[06:52] <bddebian> whoops, that's mine, I removed the xfvb run thing
[06:56] <fbond|away> is the codegen module part of the package you are working with?
[07:06] <bddebian> fbond|away: No, it gets imported from gtk
[07:07] <bddebian> Well pygtk
[07:25] <fbond|away> bddebian, heads up pygtk does weird magic to load codegen, which really sites in /usr/share/pygtk/2.0/codegen/, and debian's python-support infrastructure is probably not a good combination
[07:28] <bddebian> fbond|away: You think pycentral would be better or just screwed either way?
[07:37] <fbond|away> bddebian, not sure, I'm not really clear on what pycentral, pysupport are supposed to be providing ... ?
[07:38] <crimsun> bddebian: doubtful, since pyg{object,tk} use pysupport [unless you plan on changing those source packages, too?]
[07:38] <bddebian> Sure, why not.. ;-P
[07:39] <fbond|away> crimsun, what good do pysupport, pycentral do ? i.e. why not just dh_python ?
[07:39] <LaserJock> crimsun: hmm, maybe whe really should have him doing documentation ;-)
[07:39] <LaserJock> fbond|away: check out the new Python Policy
[07:40] <fbond> all these new-fangled policies ...
[07:40] <LaserJock> fbond: it's about dealing with multiple python versions
[07:40] <tseng> the old python helpers were bound to a single python version
[07:40] <tseng> LaserJock: sweet lasers on discovery channel last night
[07:40] <tseng> Star Wars (1980) type stuff
[07:40] <LaserJock> neato
[07:40] <tseng> yeah
[07:40] <tseng> ICBM killers
[07:41] <LaserJock> everybody thinks I use these "cut a person in half" kind of lasers
[07:41] <fbond> oh, I already read the relevant python policy stuff earlier ...
[07:41] <fbond> not very useful: http://www.debian.org/doc/packaging-manuals/python-policy/ap-packaging_tools.html
[07:41] <azeem> LaserJock: don't cross the streams!
[07:41] <bddebian> hehe
[07:41] <LaserJock> heh
[07:42] <bddebian> crimsun: I don't think this is a pyobjects problem but I'm stumped :-(
[07:42] <LaserJock> fbond: maybe http://wiki.debian.org/DebianPython/NewPolicy is better
[07:42] <crimsun> bddebian: it's possible that pysupport broke it, but I don't have time to drill down
[07:48] <LaserJock> bah, were's lucas
[07:48] <tseng> i wanted to dispute him as well
[07:49] <LaserJock> dispute?
[07:49] <tseng> his recent blog
[07:49] <LaserJock> I just want to know what's up with multi distro tools
[07:49] <tseng> oh
[07:50] <LaserJock> I really wish he would get it into universe or something
[07:51] <LaserJock> I always have to build the packages myself, which isn't a huge thing
[07:51] <LaserJock> but when I just need to have it there...
[07:51] <sladen> it is however unproductive hassle
[07:53] <LaserJock> he did some good work with the scripts, I find them quite useful
[07:53] <LaserJock> but they kinda fizzled out
[07:53] <LaserJock> he seems to be rather conducting Xchat polls ;-)
[07:54] <LaserJock> maybe I was the only one who found them useful, but I can't imagine that
[07:55] <LaserJock> I'd like to have the ruby stuff ported to python though as I don't know any ruby
[07:55] <LaserJock> or maybe I should just learn  ruby ;-)
[07:56] <zul> LaserJock: it looks like he is stirring up more than proving anything useful
[07:56] <LaserJock> I really don't know the point
[07:57] <LaserJock> he keeps this unstable vs dapper or edgy thing
[07:58] <zul> its like comparing apple and oranges..
[07:59] <Nafallo> well, atleast both are round :-)
[08:00] <Nafallo> what are you guys talking about? :-)
[08:00] <LaserJock> http://www.lucas-nussbaum.net/blog/?p=206
[08:00] <tseng> LaserJock: ruby is love
[08:01] <LaserJock> tseng: but I haven't even figured out python yet :/
[08:01] <tseng> LaserJock: I skipped python
[08:02] <LaserJock> hmm, I don't think I better do that
[08:02] <fbond> ruby is more powerful but has less natural (IMO) syntax (and is only marginally more powerful)
[08:03] <LaserJock> but maybe I can learn enough ruby to at least be able to get around in lucas' scripts
[08:03] <tseng> I read the pickaxe book in a matter of days
[08:03] <Goshawk> hi, i've problem finding my password on revu, the script to get it seems broken, can someone fix it or mail me that python script (i can spend time on it...)?
[08:03] <tseng> how's your OO
[08:03] <tseng> Goshawk: does it spit out gpg encrypted text?
[08:03] <LaserJock> I started programing with Fortran, you can guess the rest ;-)
[08:03] <tseng> Goshawk: i don't think its broken
[08:04] <Goshawk> tseng: i don't see any gpg text
[08:04] <tseng> hm i guess it is
[08:04] <tseng> blame siretart
[08:04] <LaserJock> yeah, people get that know and then
[08:04] <LaserJock> it seems random to me
[08:04] <Goshawk> ok...
[08:04] <LaserJock> but maybe it isn't
[08:05] <tseng> i either get a) nothing but help text
[08:05] <Goshawk> \query siretart
[08:05] <tseng> b) exception
[08:05] <Goshawk> ops sorry
[08:05] <tseng> it should use the launchpad password, I wish
[08:10] <LaserJock> tseng: REVU2, we promise :-)
[08:16] <LaserJock> tseng: ack, how do I even install ruby on edgy?
[08:17] <tseng> LaserJock: apt-get install ruby1.8?
[08:19] <LaserJock> tseng: ah found it, I could only find ruby1.6 and ruby1.9
[08:41] <bddebian> Heya lfittl
[08:42] <lfittl> hey bddebian
[08:44] <bddebian> Damnit, scourges forum site is down today
[08:44] <tseng> sounds like a huge loss
[08:45] <lfittl> bddebian: was there any reply to your post before that?
[08:48] <lfittl> bddebian: hmm, forum works for me
[08:51] <bddebian> lfittl: I can't get to it.  Any replies?
[08:51] <lfittl> bddebian: ben replied, basically saying welcome, and telling that one of the people who could know something is on vacation
[08:52] <bddebian> Heh, OK, thx
[08:52] <lfittl> and that he thinks its great to have an ubuntu package :)
[08:52] <nicolaw> i'm told this is a good place to gauge the possibility of getting a package added to ubuntu
[08:52] <lfittl> s/its/it\ would\ be/
[08:53] <bddebian> nicolaw: Have you already packaged it?
[08:53] <nicolaw> no - it's a CPAN package
[08:54] <nicolaw> it is a case of packaging up myself and taking it from there?
[08:54] <LaserJock> well, it sort of depends
[08:54] <bddebian> nicolaw: The ideal solution would probably be to package it up and post it on REVU, if possible
[08:55] <LaserJock> if you *want* to package it yourself then we can help you do that
[08:55] <imbrandon> LaserJock: did you goto ubucon ?
[08:55] <LaserJock> imbrandon: yes
[08:55] <imbrandon> hehe nice lemme PM ya
[08:55] <zul> LaserJock: how was it?
[08:55] <LaserJock> good
[08:55] <LaserJock> about 60 people
[08:56] <LaserJock> mdz, janes, and a couple other Canonical people showed up
[08:56] <zul> LaserJock: heh it looks like you get to go to all of the fun places this year
[08:56] <LaserJock> perhaps, I can't take to much of it
[08:56] <nicolaw> i'm not really fussed who packages it to be honest, although if other people thing it's worthy of inclusion then it would be nice for the packaging to be owned by someone else ... although having said that i'm the author so ..
[08:56] <LaserJock> and my boss is sure to get suspicious
[08:57] <nicolaw> is RRD::Simple http://search.cpan.org/~nicolaw/RRD-Simple/ something that is likely to be included if i packaged up and posted it on REVU (what's REVU)?  :)
[08:59] <gnomefreak> nicolaw: i think you would have to package it before that can be answered. if it doesnt build right it cant be added.
[08:59] <nicolaw> ok, fair comment
[09:00] <nicolaw> is there a specific guide somewhere that you can point me to that I should follow to package it up?
[09:01] <imbrandon> !packaginguide
[09:01] <ubotu> Sorry, I don't know anything about packaginguide - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[09:01] <imbrandon> !packagingguide
[09:01] <ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html Other developer resources are at https://wiki.ubuntu.com/DeveloperResources
[09:01] <LaserJock> imbrandon: shesh, get it right ;-)
[09:01] <nicolaw> thank you :)
[09:01] <imbrandon> ;)
[09:01] <gnomefreak> ah i was looking for it
[09:02] <imbrandon> i think !packaging works too
[09:02] <LaserJock> it's also in System->Help->System Documentation on a dapper box
[09:02] <imbrandon> *shrugs*
[09:02] <Nafallo> !packguide anyone? ;-)
[09:02] <ubotu> Sorry, I don't know anything about packguide anyone? ;-) - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[09:02] <micahcowan> It's currently linked to on the front doc page.
[09:02] <lfittl> which would be the right package to add udev rules for smartcard readers? (gnupg would be my guess, but I am afraid that such a change to an important main package won't be accepted)
[09:02] <gnomefreak> yep it does imbrandon :)
[09:03] <imbrandon> !packguide is <alias> packagingguide
[09:03] <ubotu> I'll remember that, imbrandon
[09:03] <imbrandon> there ya go Nafallo
[09:03] <imbrandon> ;)
[09:04] <Nafallo> much easier to spell :-)
[09:04] <micahcowan> Perhaps also add the misspelled version as well?
[09:04] <imbrandon> !find package
[09:04] <ubotu> Found: kernel-package, arch-buildpackage, cvs-buildpackage, darcs-buildpackage, jpackage-utils (and 9 others)
[09:04] <imbrandon> !more
[09:04] <ubotu> Sorry, I don't know anything about more - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[09:04] <imbrandon> erm
[09:05] <imbrandon> !find more
[09:05] <ubotu> Found: xmore, libcarp-assert-more-perl, liblist-moreutils-perl, xlockmore, xlockmore-gl
[09:05] <imbrandon> gah forget it
[09:05] <imbrandon> heh
[09:05] <Nafallo> hehe
[09:05] <imbrandon> !info xmore edgy
[09:05] <ubotu> xmore: X client - xmore. In component main, is optional. Version 1:1.0.1-0ubuntu1 (edgy), package size 6 kB, installed size 80 kB
[09:05] <imbrandon> that was for packages anyhow
[09:05] <imbrandon> lol
[09:05] <imbrandon> !search package
[09:06] <imbrandon> gah oh well
[09:15] <gnomefreak> !info nvidia edgy
[09:15] <ubotu> Package nvidia does not exist in edgy
[09:15] <gnomefreak> is there any info on when nvidia will release the x7.1 drivers?
[09:16] <micahcowan> I've heard there aren't even beta drivers avail yet... :(
[09:16] <gnomefreak> yuck
[09:16] <gnomefreak> its getting a bit late:(
[09:16] <gnomefreak> micahcowan: me too but no 3d acc
[09:16] <gnomefreak> im using vesa atm
[09:16] <micahcowan> yeah: It's looking very much like there won't be 3d accel for nvidia in edgy, until sometime after release.
[09:17] <micahcowan> I'm using nvidia, but with the accel disabled (it does work for me: apparently not for all).
[09:18] <tseng> sigh
[09:20] <zul> nvidia/ati blows
[09:21] <tseng> yeah, I don't see why no one recognizes that
[09:21] <tseng> and goes about their business
[09:21] <micahcowan> I honestly don't really need the accel often on Linux: the card is pretty much so I can play the games I want on my Windows boot :-/
[09:22] <zul> i have a seperate computer to play games and its only really one game these days
[09:22] <asimon> I have a very old nvidia gforce1 card here and it works great under Edgy with nv legacy drivers and with 3d accel.  ;-)
[09:23] <micahcowan> zul, ooc, what game? :)
[09:24] <zul> unreal tournament
[09:24] <zul> i dont play much games
[09:24] <asimon> zul: that works great under linux too.
[09:25] <zul> meh...works for me right now
[09:57] <phanatic> evening
[09:59] <bddebian> Heya phanatic
[10:00] <phanatic> hey bddebian
[10:04] <lfittl> hey phanatic :)
[10:04] <phanatic> hey lfittl :)
[10:06] <lfittl> phanatic: I suppose you didn't have time yet to look at bzr-wmt? (no problem, gives me more time to improve it :))
[10:08] <phanatic> lfittl: not yet, sorry. i'm currently busy with finishing the code for SoC... i'll do a release soon ;)
[10:09] <lfittl> phanatic: ah, right, you were working on olive as a SoC project :)
[10:09] <phanatic> lfittl: exactly :)
[10:09] <lfittl> did you have enough time to implement the things you planned?
[10:11] <phanatic> yes, the planned features are mostly implemented (i'd say 95%)
[10:11] <LaserJock> bddebian: I see scilab 4.0 in Debian!!
[10:11] <lfittl> nice
[10:11] <phanatic> i'll do some bundle related things in the next weeks
[10:12] <phanatic> but it's been self-hosting for weeks now ;)
[10:12] <lfittl> :)
[10:17] <bddebian> LaserJock: Aye, I thought I had asked for a sync of it? Hmm
[10:18] <LaserJock> hmm, well it could be, my brain is fried
[10:18] <bddebian> I don't see it in Edgy
[10:19] <crimsun> of course it's not in Edgy. There's no bug report w/ u-a subscribed requesting a sync.
[10:45] <phanatic> the new debian python policy is the standard for edgy, right?
[10:45] <tseng> yes
[10:46] <bddebian> Damnit, nothing is working for me lately...
[10:46] <phanatic> tseng: thanks
[10:47] <LaserJock> bddebian: you'll be alright :-)
[10:51] <Plug> ...no one loves me :(
[10:51] <Plug> (ajmitch, get out of bed, this means you ;)
[10:52] <bddebian> plug: What's on REVU
[10:52] <Plug> my very first (shared) Ubuntu package
[10:52] <Plug> http://revu.tauware.de/details.py?upid=2918
[10:53] <lfittl> Plug: there should be only one initial changelog entry (instead of the 3 you have now)
[10:54] <ajmitch> Plug: slacker I've been out of bed for awhile
[10:54] <Plug> Yep, I cocked up the version numbers initially :)
[10:54] <bddebian> heh
[10:54] <Plug> what defines 'initial' ?
[10:54] <Plug> ie, am I allowed a new one for each version?
[10:55] <ajmitch> I don't know why people think it *has* to be pruned
[10:55] <Nafallo> initial is the first, after that it's "new upstream release" ;-)
[10:55] <lfittl> ajmitch: because a shorter changelog makes it easier to find something
[10:55] <Plug> so in that case, only the first one is initial!
[10:56] <ajmitch> lfittl: not really
[10:56] <Nafallo> Plug: yes :-)
[10:57] <lfittl> ajmitch: why? only the changes that made it into the archive are interesting, at least for searching "where was bug #xxx fixed", so why keep entries that often only say new cvs checkout (as with the second one in this case)
[10:58] <Plug> Well, in that case, the version number was bumped
[10:58] <lfittl> ajmitch: I don't see it as MUST be, but as nice to have ;)
[10:58] <Plug> so either you lose the previous entry, or you create a new one
[10:58] <ajmitch> because I'm not the sort of person that likes to throw away the history of changes in the package, which often document why something was done
[10:58] <Plug> lfittl: that is easy to change/condense though
[10:59] <lfittl> ajmitch: but often (if we talk about packages at REVU) these are just simple fixes like adjust version number to match ubuntu versioning, I don't see what this should document
[10:59] <lfittl> but discussing this leads to nothing ;)
[11:01] <lfittl> Plug: I won't be the one wo can upload/approve your package, do that what you consider best (as it doesn't make a big difference)
[11:02] <Plug> I can fix it, thanks for the pointer
[11:02] <Plug> any other comments are welcomed
[11:02] <Plug> (be gentle)
[11:03] <lfittl> Plug: another cleanup thing, you could remove the commented dh_* stuff in debian/rules, as it isn't needed
[11:04] <lfittl> Plug: changelog distribution should be edgy instead of dapper
[11:06] <asimon> Regarding changelog distribution, when doing a debdiff for a dapper bug, I use dapper-updates instead of dapper, right?
[11:06] <Plug> well, *ahem* at this case, its a dapper package
[11:07] <lfittl> asimon: yep
[11:07] <Plug> I haven't tried building it for edgy yet
[11:07] <asimon> lfittl: ok, thanks
[11:08] <lfittl> Plug: ah, k (you might want to create an edgy pbuilder for packaging stuff, this way you can at least test if it builds without a problem)
[11:09] <lfittl> will do a quick test build here on edgy
[11:10] <Plug> I know the version of NM has gone up a couple
[11:11] <lfittl> does it require a specific NM version?
[11:16] <Plug> lfittl: good point, it requires > 0.6.0 I believe, and less than HEAD
[11:16] <Plug> edgy has 0.6.3 or 0.6.4 so it should be OK
[11:16] <lfittl> Plug: you might want to do a versioned build dependency on network-manager-dev then, just to be on the safe side
[11:22] <lfittl> Plug: you are missing a build-dependency on dpatch
[11:22] <lfittl> have you tried to build this in a pbuilder?
[11:22] <Plug> no.  I have created a pbuilder but I needed to update it and havent done so yet
[11:23] <lfittl> Plug: k, best would be to do the pbuilder testing before asking for reviews here / uploading to REVU ;)
[11:24] <Plug> see, if I hadn't asked for a review here, I'd not have found that out! :)
[11:24] <lfittl> :)
[11:27] <bddebian> Later gang
[11:27] <lfittl> later bddebian
[11:30] <lfittl> Plug: another missing build-dep: ppp-dev
[11:40] <lfittl> Plug: building seems to work fine under edgy, can't test the package because I don't have PPTP, sry
[11:41] <lfittl> Plug: but if you fix the stuff (most important the build-deps) I pointed out, it is easier for the next one to review ;)
[11:43] <Plug> will do asap
[11:44] <Plug> thanks for your help and suggestions
[11:44] <lfittl> no problem :)
[11:44] <lfittl> have to get some sleep, gn8 everybody


[09:16] <smb> cking, have you insight into the acpi processor declaration?
[09:16] <cking> smb: acpi processor declaration - only what the ACPI handbook says, and from memory, zilch, zero.
[09:17] <cking> what's required?
[09:17]  * apw notes the mtrr conv is still there in scroll back ... i think i have found the change which might make that come back, building a test kernel now
[09:17] <smb> I am revisiting a bug about these pause-until-keypress on boot. And some guy seems to be able to fix it for him with a custom dsdt.
[09:17]  * apw wonders if he told you what he changed
[09:17] <smb> beside other things in there, this looks a bit suspicious
[09:18] <smb> -    Scope (\_PR)
[09:18] <smb> +    Scope (_PR)
[09:18] <smb>      {
[09:18] <smb> -        Processor (CPU0, 0x00, 0x00001010, 0x06) {}
[09:18] <smb> -        Processor (CPU1, 0x01, 0x00001010, 0x06) {}
[09:18] <smb> +        Processor (CPU0, 0x00, 0x00000000, 0x06) {}
[09:18] <smb> +        Processor (CPU1, 0x01, 0x00000000, 0x06) {}
[09:18] <smb>      }
[09:18] <cking> OK - me looks at manual
[09:18] <smb> In the book it only says the number is the processor block address
[09:19] <apw> but what is the processor block ...
[09:19] <smb> exactly
[09:19] <cking> how can that change fix the bug?(!)
[09:19]  * apw connects a tap to cking's acpi brain centre
[09:20] <apw> if the processor block describes the processor, then it might change the capabilities of the cpus
[09:20] <cking> cking's acpi brain centre is in need of coffee + some reading of the spec
[09:20] <smb> apw, That is my wild guess
[09:20]  * apw couriers over some freshly ground beans
[09:20] <smb> The rest of the changes mostly consist in using One instead of 0x01
[09:21] <smb> and Zero instead of 0x00 and renames like \_PR to _PR (which looks slightly wrongish to me)
[09:23] <cking> I'm googling for some info..
[09:28]  * apw plays the countdown clock tune in the backgroun
[09:32]  * cking is now reading some pdfs..
[09:34] <hughhalf> o
[09:38]  * smb is scared of what he has done...
[09:43] <smb> Actually 0x0 could mean nothing which would be slightly contradicting the 0x06 length but on the other hand there was a little sentence somewhere else about ignoring those definitions...
[09:43] <cking> From my limited googling know-how, the address refers to the PBLK address which allows inter processor communication some how - if set to zero it essentially states there is no PBLK. I assume the hang is because something is borked on the interprocessor communication.
[09:43] <cking> Is this an AMD processor?
[09:46] <smb> Its one of those bugs with 320 comments... I believe yes, some with MCP67 based hardware...
[09:46] <cking> smb: acpi_processor_get_power_info_fadt() checks the PBLK - and probably this is used when the system goes idle. I've seen some comments that this may be broken on some AMD cpus
[09:47] <cking> Is than enough to get ones teeth into?
[09:47]  * smb notes that down
[09:47] <smb> That is a pointer to look at. Thanks
[09:47] <apw> smb did we ask them to try idle=foo type selectors?
[09:48] <smb> apw, I don't think so. Hard to tell under that pile of comments... nope, does not look like it
[09:49] <smb> bug 272247
[09:49] <ubot3> Malone bug 272247 in linux "System freezes during boot, unless I hold a key down" [High,Confirmed] https://launchpad.net/bugs/272247
[09:49] <smb> wear your danger-sensitie-googles
[09:49] <apw> smb, damn i think we talked about putting a list of options to try together for them, seems we talked and failed to act
[09:50] <smb> Yeah, and in the mean time some of those just gather a lot of other drifts
[09:52] <apw> you just know its going to be a 2 line quirk once its found
[09:53] <smb> apw, most of the affected in that report seem to be hp pavilion laptops. but I just look at one stating he got a P4 moile with an intel chipset...
[09:53] <smb> Toshiba Satellite A30
[09:53] <apw> hrm ...
[09:53] <apw> though many people see the same bug when it cannot be the same
[09:54] <smb> HP Pavilion dv6646us, AMD turion64x2, nVidia, Broadcom.
[09:54] <smb> yeah, at this point it is hard to make out any real issue
[09:55] <smb> It can be the same or various things
[09:56] <smb> I would think the essence is that for some reason the system ends up in a sleep state without a wake up trigger. That could be some timer issue or processor definition...
[09:57] <smb> Best action is to try to dig into that with that one system I got with that problem...
[09:58]  * cking agrees
[10:00] <smb> Ok, that would be a system which defines a register block only for CPU0 (on a amd dual core)
[10:04] <smb> So I could both try the idle= and the modified dsdt
[10:04] <smb> This one is special though, as it only has problems with C1E enabled
[10:04] <cking> smb: maybe this has some background hints - https://bugzilla.redhat.com/show_bug.cgi?id=465637
[10:04] <ubot3> bugzilla.redhat.com bug 465637 in kernel "C1 state unsupported on modern AMD mobiles" [Medium,Closed: cantfix]
[10:05] <smb> cking, Thanks for that link. Will have a read on that
[10:05] <cking> it may be related, hope it does not waste your time.
[10:05] <smb> The beginning sounds intresting anyway
[10:06] <cking> I like the comment "I will never again buy any AMD product "
[10:09] <cking>  states are processor power states. C1 is mandantory and reached on IA32 compatible processors using the HLT instruction, C2 and C3 are optional and must be configured.
[10:09] <cking> C states can be configured in ACPI using two methods:
[10:09] <cking>    1. by defining the P_BLK base address in the Processor() Definition, and P_LVLx_LAT values in the FADT
[10:09] <cking>    2. using the _CST object
[10:09] <cking> P_BLK is easier to configure, if the hardware supports that method. ACPI defines that there must be two registers at P_BLK+4 and P_BLK+5 that initiate a transition to C2 or C3 when the register is read. After sleep, the read returns 0. P_LVLx_LAT define the worst case latency of the state transition.
[10:10] <cking> _CST is necessary if you want to support more than 3 C states, or if the transition procedure doesn't follow the ACPI requirement.
[10:10] <cking> smb: ^^ may be worth checking the P_LVLx_LAT values in the FADT too
[10:12] <smb> The system does not seem to define any C2 or C3, so be compliant what I take from glancing over the comments.
[11:48] <Chrom_> hi all
[11:49] <Chrom_> hey guys, did anybody try to dist-upgrade jaunty today? there-s a leftover package that prevents linux-restricted-modules-generic to be installed
[12:19] <gigasoft>  i have problem with Workspace Switcher, how to reinstall it or install another one
[12:21] <amitk> gigasoft: and how is that related to the kernel? :)
[12:21] <ogra> amitk, modprobe new-workspace.ko :P
[12:21] <amitk> please try #ubuntu
[12:21] <gigasoft> i do not know
[12:21] <ogra> yeah
[12:22] <ogra> #ubuntu for support is the right place
[12:22] <gigasoft> thanks anyway
[12:22] <gigasoft> bue
[12:22] <gigasoft> bye
[12:27] <_ruben> heh
[13:07] <apw> ikepanhc, you about today?
[13:07] <ikepanhc> apw: what?
[13:08] <apw> hi, was just looking at a bunch of intel graphiscs issues, and see you have the A17 swizzle bug.  wondering what you are doing with it, which patch you are going to propose for sru
[13:10] <ikepanhc> eh, bad, I almost forget that. sorry. Do it as highest priority
[13:10] <apw> ikepanhc, no problem.  i can just as easily do it if you arn't activly doing it now
[13:11] <ikepanhc> Thanks, I think I can do it today
[13:12] <apw> i assume you were going to propose this patch: http://launchpadlibrarian.net/24790669/i915-gem-disable.patch
[13:13] <ikepanhc> eh? I prepare to cherry-pick from upstream: 280b713b5b0fd84cf2469098aee88acbb5de859c
[13:13] <apw> that is a pretty huge commit ...
[13:14] <ikepanhc> Yes it is :-(
[13:15] <apw> from what i read the alternative is to allow gem to be disabled, using that other patch.  that might be more appropriate for sru
[13:15] <ikepanhc> I think I shall look at the thread again
[13:15] <apw> ok
[13:16] <ikepanhc> Last time I look at the thread, they said the mainline build which has the commit works fine.
[13:17] <apw> yeah, but the patch doesn't just cherry-pick, and its pretty big.  your call if you think its worth trying the backport
[13:17] <ikepanhc> But we need the shortest commit, am I right?
[13:17] <apw> smaller means less risk of regressions, and regressions for previously unaffected users are something to avoid for sure
[13:19] <ikepanhc> Hmmm, checking the thread again.
[13:44] <ikepanhc> apw: so, we have a huge commit with proper fix and another simple patch but not proper fix
[13:45] <apw> yep thats the one
[13:45] <ikepanhc> ya, I think simple is the best :-D
[13:56] <apw> smb, you wanted to have a link to the mtrr test kernels, they can be found here: https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/linux/+bug/314928/comments/54
[13:56] <ubot3> apw: Error: Could not parse data returned by Malone: The read operation timed out
[13:56] <smb> apw, cool, will test
[13:56]  * apw spanks ubot3
[16:13] <apw> smb, i am going a bit mad ... any idea which damn applet does volume?
[16:13] <apw> ie which one converts alsa changes into an OSD?
[16:14] <smb> no, sorry no idea. I would try #ubuntu-devel...
[16:22] <johanbr> I don't think that's an applet. That's just some core component of gnome (gnome-settings-daemon?).
[20:24] <awe> sconklin: ping
[20:25] <sconklin> awe: hello
[20:25] <awe> hey was wondering if you saw rtg's reply to my SRU for the broadcom wl driver.  are we going to create netbook-lpia branches for the lrm git trees?
[20:26] <rtg> awe: haven't the ABI's already diverged?
[20:27] <sconklin> hmm. Was that request for the driver to go into lrm? The way the request was made it would apply to the main hardy distro kernel
[20:27] <awe> rtg: I think so, but I didn't check...
[20:28] <sconklin> I think it should go into lrm.
[20:28] <awe> sconklin: yes, since cking and I get notified whenever a new version is released, I decided I'd handle it across all releases.
[20:28] <awe> sconklin: it's already in lrm, this is an update
[20:28] <rtg> sconklin: drop it on master, SRU it, then cherry-pick to netbook-lpia ?
[20:28] <awe> sconklin: I still need to do an SRU for intrepid and jaunty
[20:29] <sconklin> rtg: that's what I assumed when you pointed him at srb, but I wanted to make sure
[20:29] <awe> rtg: OK, so if I handle the SRUs, then sconklin can cherry pick?
[20:29] <sconklin> awe: yes
[20:29] <awe> cool
[20:29] <rtg> awe: yeah, what sconklin said
[20:30] <sconklin> awe: but it never hurts to bug me and make sure I don't miss it
[20:30] <awe> rtg: also, one other thing that concerns me is that our change to using git has made the process of upgrading to a new version more error prone.
[20:31] <awe> rtg: the ACK process alone doesn't really ensure that I haven't made a mistake in untar'ing / manual manipulation required
[20:31] <sconklin> awe: on another topic . . . when can we sync up your dennis branch in lum into our repo, and possibly combine it with the netbook-lpia branch?
[20:31] <awe> rtg: perhaps I should ask someone like cking to verify out-of-band that it looks right?
[20:32] <rtg> awe: thats a good idea, though I don't see how git could but help. you can at least see whats changed.
[20:33] <awe> rtg: it doesn't help...  colin would need to validate the git tree against the zip from broadcom
[20:33] <awe> sconklin: it's on my list.  I promise I'll get the patch requests sent out before next week's kernel mtg.
[20:34] <sconklin> awe: as long as you're on it - you're the one mostly affected, and you are aware of the (6 or so patches) delta between your branch and ours.
[20:34] <awe> sconklin: I'm actually working on the desktop team for the karmic cycle, and am still trying to get my bearings
[20:34] <sconklin> awe: I completely understand
[20:34] <awe> sconklin: I am aware of it, and it's at the top of my list post updating the wl driver
[20:35] <rtg> awe: we've unrolled the zip in Hardy LRM. I'm not sure wherein lie your concerns.
[20:35]  * awe beats himself over the head for volunteering to upgrade the 'wl' driver
[20:36] <rtg> awe: c'mon, it can't take 10 minutes.
[20:40] <awe_> rtg: sorry 'bout that... !@#% X lockup/crash...
[20:40] <awe_> rtg: anyways. ot
[20:40] <awe_> it's not the simple.  we used to be able to just copy the new tarballs in place and tweak the rules
[20:41] <awe_> now, since any patches we have are applied as commits, we have to untar, re-apply the patches ( MODULE_LICENSE / Makefile )
[20:41] <awe_> ...then copy the architecture-specific binary files into place ( they're now suffixed with the arch )
[20:42] <awe_> it's not hard, just alot of manual steps...which makes it error prone
[20:42] <rtg> awe: what about carrying the patches in the patches directory like we used to?
[20:43] <rtg> that seems to have disappeared. hmm
[20:43] <awe_> yup
[20:43] <rtg> awe: I see your point.
[20:43] <awe_> ;)
[20:43] <rtg> lemme annoy smb about it a little.
[20:44] <awe_> OK, should I hold off on the SRU for intrepid / jaunty then?
[20:44] <rtg> yeah, lets get that sorted first.
[20:45] <awe_> sounds good
[20:45] <sconklin> awk has damaged me
[20:47] <awe> isn't that a song by your buddies from brooklyn?  ;)
[20:48] <sconklin> awe: something like that. they damaged me too :)
[21:07] <rtg> awe: what patches are we carrying 'out-of-band' for Broadcom wl?
[21:08] <awe> there's used to be a Makefile patch and a vlan patch ( which also included the MODULE_LICENSE update )
[21:08] <rtg> awe: i think the vlan patch was eventually accepted by Broadcom
[21:09] <awe> vlan has been fixed in the driver, however the MODULE_LICENSE still needs to be set, so that should get rolled into it's own patch
[21:10] <rtg> awe: do you have the MODULE_LICENSE patch somewhere?
[21:10] <awe> I applied it directly as a commit in my tree referenced in the SRU request
[21:11] <rtg> awe: k, lemme look
[21:11] <awe> hmmm...actually maybe it wasn't a separate commit
[21:11] <rtg> awe: it would help if it was. could you extract it?
[21:11] <awe> I do have a version of the patch for our dennis-specific lrm
[21:22] <pace_t_zulu> anyone running karmic as a virtual machine experiencing lockups since 2.6.30 was installed?
[21:51] <rtg> awe: I've responded to your LRM patch request. I'm outta here. beers await.
[21:53] <awe> rtg: thanks dude.  sake for me shortly...  ;)
[21:55] <samourai_41> Slt