[12:48] <slomo> damn... does someone know how to workaround a bzr bug with unicode chars in the name? :(
[12:54] <lifeless> slomo: whats the bug
[12:55] <lifeless> slomo: also, #bzr is MUCH more likely to have an answer.
[01:11] <karim18> hey guys, how are you all doing today?
[01:12] <bddebian> Hello karim18
[01:12] <infinity> karim18: Do you really want to know? :)
[01:12] <karim18> do you guys know where I can get GOOD technical documentation on Ubuntu?
[01:12] <karim18> infinity: Sure, why not :P
[01:13] <karim18> in Asia infinity?
[01:13] <HrdwrBoB> karim18: 'on ubuntu' ?
[01:13] <infinity> karim18: Australia.
[01:13] <karim18> yeah, i.e. Docs on Development, etc..
[01:13] <tritium> infinity: is this not something you do every week day?
[01:13] <bddebian> Well good morning then infinity :-)
[01:13] <infinity> tritium: I tend to roll out of bed at 9 or 10 most days. :)
[01:13] <karim18> Mornin infinity, well then, I'm drinking at 6 am in mornin australia time
[01:14] <tritium> infinity: wow!  I envy you :)
[01:14] <infinity> tritium: Combine that with the fact that I didn't get to sleep until about 3am, do the math, and you can understand the grump.
[01:14] <infinity> karim18: It's 9am, now.
[01:14] <karim18> lol, ok, So I'm sipping some red wine at 9 am australia time
[01:14] <infinity> tritium: Don't envy too much.  I may roll out of bed at 10, but then I work until 2am.
[01:14] <karim18> ;)
[01:14] <tritium> infinity: fair enough :)
[01:15] <bddebian> Hmm, third time in a row, no response from infinity, maybe I'm on ignore..
[01:15] <infinity> bddebian: Hrm?  No, not intentionally at any rate.
[01:15] <infinity> bddebian: Also, hi.
[01:15] <bddebian> :-)
[01:16] <tritium> hi bddebian 
[01:16] <bddebian> Heya tritium
[01:17] <LaserJock> karim18: help.ubuntu.com has a Packaging Guide and wiki.ubuntu.com also has a fair amount of development related documentation
[01:18] <karim18> LaserJock: Thanks ;)
[01:19] <tritium> karim18: also http://www.debian.org/devel/
[01:19] <tritium> handy for policies, etc.
[01:19] <LaserJock> yes that is also very good, especially the Debian Policy
[01:20] <karim18> tritum: thanks man ;)
[01:20] <karim18> I appreciate the help guys :)
[01:21] <tritium> :)
[01:31] <jadaz87> tritium: may i pm you?
[01:31] <tritium> jadaz87: okay
[03:03] <lprofil> good evening
[03:04] <lprofil> i have a small prob with compiling cinelerra from cvs-sources 
[03:04] <crimsun> please ask in #ubuntu
[03:05] <lprofil> ok
[03:05] <lprofil> actually there is a dependecy prob with the libaries i try to install 
[03:06] <lprofil> i think this is developer related
[03:06] <lprofil> isn't it ?
[03:06] <LaserJock> not particularly
[03:06] <LaserJock> if it's a bug it should probably be filed on Launchpad
[03:07] <lprofil> i filed it allready
[03:07] <LaserJock> ok
[03:07] <lprofil> i have trouble to install "libfaac-dev:"
[03:07] <lprofil> "libfaac-dev"
[03:07] <lprofil> can you merge it into your dapper system ?
[03:07] <crimsun> please, this is not Ubuntu-centric. I'm happy to help in either #ubuntu or #ubuntu-motu.
[03:07] <lprofil> via apt-get ...
[03:08] <lprofil> ok
[03:08] <lprofil> i'll try there
[03:09] <lprofil> anyway, thank you for beeing kind if i might have annoyed you 
[03:09] <lprofil> bye
[04:18] <fabbione> morning
[04:19] <Hobbsee> hi fabbione!  you're on early!
[04:21] <fabbione> Hobbsee: same reason as last week
[04:22] <Hobbsee> fabbione: hmmm okay, your wife, or something else?
[04:23] <fabbione> heat
[04:23] <Hobbsee> ahh...
[04:24] <Hobbsee> yes, right, i remember now :P
[05:05] <bddebian> fabbione: Do you care if I hit afbinit merge?
[05:09] <fabbione> bddebian: is that the sparc fb fw loader?
[05:12] <bddebian> 3D Framebuffer Firmware INitializer, but it FTBFSs anyway
[05:15] <fabbione> go ahead and fix it if you know how
[05:15] <fabbione> it might be because of l-k-h
[05:16] <fabbione> why should be FTBFS?
[05:16] <fabbione> i don't see any build log
[05:16] <fabbione> (from edgy at least)
[05:17] <bddebian> fabbione: No, the Debian package FTBFSs
[05:17] <bddebian> afbinit.c:272: warning: incompatible implicit declaration of built-in function 'exit'
[05:17] <bddebian> as: unrecognized option `-Av9a'
[05:17] <bddebian> make[1] : *** [afbinit]  Error 1
[05:18] <fabbione> that's broken toolchain
[05:18] <fabbione> or broken B-D
[05:19] <fabbione> bddebian: if you don't have a sparc to test, don't bother. i can take it
[05:19] <bddebian> OK, sorry, I was just trying to clean up the manual merges :-(
[05:19] <bddebian> I wish I had a sparc
[05:19] <fabbione> nothing to be sorry
[07:17] <pitti> Good morning
[07:18] <ajmitch> morning pitti 
[07:21] <Hobbsee> hi pitti 
[07:23] <joejaxx> Hobbsee: :)
[08:20] <fabbione> feh
[08:28] <Hobbsee> fabbione: hmmm?
[08:59] <dholbach> good morning
[09:04] <pitti> hey dholbach, moin mvo
[09:04] <mvo> good morning pitti, *
[09:04] <dholbach> hey pitti
[09:07] <dholbach> ogra: a new gnome-power-manager for you!
[09:36] <pitti> moin ivoks 
[09:36] <ivoks> hi pitti 
[09:36] <ivoks> greettings from adria :)
[09:39] <dholbach> hey ivoks
[09:39] <dholbach> you're having a good time? :)
[09:40] <dholbach> hellas seb128!
[09:40] <seb128> hey dholbach
[09:40] <ivoks> well, not this week, i'm babysitting my little sister
[09:40] <ajmitch> morning seb128 
[09:40] <seb128> still sleeping in front of IRC? :)
[09:40] <pitti> bonjour monsieur seb128
[09:40] <dholbach> sleeping?
[09:40] <seb128> hi ajmitch pitti
[09:40] <dholbach> not really :)
[09:40] <seb128> dholbach: it takes your about 4 seconds to notice when I join
[09:41] <seb128> so my bet is that your spend your time in front of IRC waiting for me to join :p
[09:41] <dholbach> i just waited for you :-p
[09:42] <seb128> what I was saying :p
[09:42] <Hobbsee> seb128: irc client notifications?
[09:43] <seb128> Hobbsee: he's not using that
[09:43] <Hobbsee> ha
[09:43] <seb128> Hobbsee: that's sort of "private joke", don't bother
[09:43] <Hobbsee> *ah.  right
[09:45] <ivoks> pitti: i see you have plans for cups web interface
[09:45] <pitti> ivoks: yep
[09:46] <ivoks> pitti: how?
[09:47] <pitti> ivoks: I'll add a sgid shadow helper program 'check_user_password' (or so) to passwd or whereever
[09:47] <pitti> ivoks: and cups will use that instead of directly reading /etc/shadow
[09:47] <pitti> ivoks: this might be useful to other programs as well
[09:47] <ajmitch> pitti: yes, Amaranth was asking about something similar for his proxy
[09:47] <ivoks> pitti: i see...
[09:48] <ivoks> pitti: that would solve other problems in cups too
[09:48] <pitti> ivoks: wait for the next edgy release, this will be a bug killer :)
[09:48] <ivoks> :)
[09:48] <Amaranth> pitti: heh, i was just looking for a sane way of doing something like the cups web interface
[09:48] <pitti> ivoks: and 1.2.2 will go into dapper, too, unless it shows regressions
[09:48] <ivoks> pitti: sorry, i'm on vacation, so i didn't do any work these days :/
[09:49] <pitti> ivoks: heh, no need to excuse :)
[09:49] <ivoks> pitti: well, i'll work on gtk interface
[09:49] <Amaranth> verify a login against the system account info and check to see if the user is either root or has sudo access
[09:49] <ivoks> pitti: but i doubt there will be anything for edgy
[09:49] <Amaranth> would your stuff work for that?
[09:50] <pitti> ivoks: there will be *definitively* nothing to check if an user is a sudoer
[09:50] <Amaranth> <--
[09:50] <pitti> Amaranth:  'groups | fgrep -w admin' must be a good enough approximation
[09:50] <Amaranth> so i should just check to see if they're in the admin group like you do in gnome-menus?
[09:50] <Amaranth> yeah
[09:51] <Amaranth> that's what i have written down in my "how to make this work" note
[10:03] <ivoks> bye all
[10:03] <pitti> ivoks: bye, enjoy your holiday
[10:03] <ivoks> thanks
[10:11] <mvo> pitti: will a new main inclusion report for libgksu2 be required? it is in universe right now and blocks the build for the latest gksu
[10:12] <pitti> mvo: is that just a renamed source pacakge from libgksu? (since that already builds libgksu2-0)
[10:12] <mvo> pitti: yes, renamed+new features+api change
[10:13] <pitti> mvo: then I don't need a MIR
[10:13] <mvo> pitti: thanks, then I will ask kamion to promote libgksu2 to main
[10:35] <Kamion> pitti: check_user_password> surely unix_chkpwd
[10:35] <pitti> Kamion: the latter only checks for the current user
[10:35] <Kamion> pitti: or PAM, but I guess you don't want to go to that much effort
[10:35] <Kamion> oh
[10:35] <pitti> Kamion: but we need to check the password of an arbitrary user
[10:35] <pitti> Kamion: and do that in a sane way, e. g. with a mandatory sleep(1) or so
[10:36] <Kamion> perhaps it could be executable only by CUPS
[10:36] <pitti> Kamion: for now I think I'll just add that to cupsys itself, and make it executable only for cupsys
[10:36] <pitti> heh, right :)
[10:36] <Kamion> I'd be concerned about the new ability for a user to just set a job going for monts
[10:36] <Kamion> months
[10:36] <pitti> Kamion: if we notice that it will be useful for other daemons, we can still extend it
[10:37] <pitti> Kamion: cupsys:shadow 2744 should be okay for now
[10:39] <dholbach> Kamion: did you have the time to check jokosher?  if so, I hope it was ok this time :)
[10:39] <Kamion> I've only just "got in"
[10:40] <dholbach> i know... you said "tell me, when you uploaded it again" and i didn't notice you vanishing on friday, that's why i asked -- take all the time you need :)
[10:40] <slomo> dholbach: do you also plan to update the gstreamer python bindings? iirc jokosher wants something from the 0.10.5 release
[10:41] <imbrandon_> weekend ? they have those in FOSS ? /me ducks ( just kiddin guys )
[10:41] <dholbach> slomo: it wants the new gnonlin and new gstreamer - i didn't look at pygst yet
[10:41] <slomo> dholbach: ok, if you look at it merge with debian... they have a different source package name than we have (but fortunately the same binary package names)
[10:42] <dholbach> grrrrr :(
[10:42] <dholbach> seb128: did you know about pygst having a different source package name in debian and all?
[10:43] <seb128> any reason to keep it different?
[10:43] <seb128> dholbach: nop
[10:43] <seb128> we packaged it first
[10:43] <slomo> seb128: nope... it only happened because we pacakged it first
[10:43] <seb128> and the maintainer didn't care looking at what we did :p
[10:43] <slomo> i already requested a sync and removal of our old one but if daniel wants to update to 0.10.5 the sync could just be skipped ;)
[10:44] <dholbach> i didn't intend to do the update (i didn't even know it had an update)
[10:47] <Kamion> imbrandon_: it's a bit different if you're employed to work on it ...
[10:48] <Kamion> happy to do the sync/removal shortly
[10:48] <Kamion> (gst)
[10:50] <slomo> Kamion: thanks :) regarding the removal requests of the several, old binary packages... mplayer is another case where and older version is superseded but not removed although newer ones were removed correctly
[10:51] <Kamion> slomo: we have a report listing all of those automatically - no need to tell us about them unless they're urgent for some other reason
[10:51] <Kamion> (which it sounds like the python2.4-* ones are, so thanks, but it doesn't sound like mplayer is)
[10:53] <slomo> Kamion: ok... i guess i misinterpreted your comment to the bug yesterday then :) i thought you meant it was confusing because it should've already been removed because newer "old" version were already
[10:56] <Gloubiboulga> Kamion, could you please reject the colorscheme package in the NEW queue (maybe you already read the logs, but we never know)?
[10:56] <Kamion> slomo: no, I meant your bug was confusing because you were talking about removing old sources whereas what's actually needed is for the NBS binaries to be removed (and then the old source versions will be automatically garbage-collected)
[10:57] <pitti> moin mdz
[10:58] <Kamion> Gloubiboulga: would be done except that Launchpad hates me
[10:58] <Kamion> (i.e. bug)
[10:58] <Gloubiboulga> Kamion, ok :)
[10:59] <Kamion> bug 53871
[10:59] <Ubugtu> Malone bug 53871 in soyuz "can't reject source package from NEW" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53871
[10:59] <Arbiter> o.O
[11:02] <mdz> pitti: morning
[11:32] <ogra> morning Keybuk 
[11:32] <Kamion> TheMuso: lsr needs to be fixed to follow the new python policy
[11:32] <Keybuk> morning
[11:32] <Kamion> TheMuso: see http://people.debian.org/~piman/python-policy/ and http://wiki.debian.org/DebianPython/NewPolicy
[11:33] <TheMuso> Kamion: Ok thanks for the heads up.
[11:47] <mdke> Znarl: around?
[11:48] <Znarl> mdke : Hi.
[12:04] <slomo> infinity, Keybuk: please give-back service-discovery-applet. builds fine now :)
[12:09] <ogra> dholbach, seb128, is it allowed for gnome people to rewrite half of the code during a freeze ? g-p-m changed majorly ...
[12:10] <seb128> ogra: what freeze?
[12:10] <seb128> ogra: ABI, API, UI and feature freezes start after 2.15.90
[12:11] <ogra> ah, k
[12:11] <ogra> so i dont have to expect that i have to rewrite all patches after this time ? 
[12:11] <seb128> correct
[12:11] <ogra> ok
[12:11] <dholbach> ogra: you don't want to set upstreams rules :)
[12:12] <ogra> dholbach, i want to know what they mean :)
[12:12] <ogra> i dont want to set them ...
[12:12] <ogra> i thought i had seen the announcement for the freezy on friday already ... but the release schedule proves me wrong :)
[12:12] <seb128> announcement yep
[12:12] <seb128> tarball are due on monday
[12:13] <ogra> yup
[12:13] <seb128> and the freeze take effect from that
[12:13] <seb128> after, not before 2.15.90
[12:13] <ogra> got it now ... i'm so spoiled with our announcement policy to send them afterwards :)
[12:13] <seb128> that's like "if you have changes you want to ship do them before rolling your tarball because freeze is coming"
[12:13] <ogra> (or at the day it takes effect)
[12:13] <seb128> k
[12:14] <ogra> yup, i understand ...
[12:28] <ogra> Keybuk, Kamion, can either of you un-NEW wilowng please ?
[12:28] <ogra> *willowng
[12:36] <Kamion> ogra: rejecting, it's using DEB_AUTO_UPDATE_DEBIAN_CONTROL; see http://ftp-master.debian.org/REJECT-FAQ.html
[12:36] <Kamion> it also doesn't appear to be following the new python policy
[12:36] <ogra> oki, i'll tell Amaranth 
[12:37] <ogra> Kamion, thanks
[12:37] <Kamion> I'll mail hiim
[12:37] <Kamion> him
[12:38] <ogra> thanks again :)
[12:39] <geser> does anybody know if the Teardown spec will also support file-rc? or is sysv-rc the only supported package?
[12:52] <Keybuk> geser: file-rc has never been supported on Ubuntu
[12:53] <geser> it is in universe and it could be installed till now
[12:53] <Keybuk> in universe => not supported
[12:53] <Keybuk> it's your machine, and obviously you can install anything you like on it; but if it breaks, you need to support it yourself
[12:54] <geser> it's clear
[12:54] <geser> but now file-rc isn't installable anymore as some packages depend on sysv-rc and file-rc and sysv-rc conflict
[12:54] <Keybuk> right, that's not surprising
[12:55] <geser> so I have to switch back to sysv-rc?
[12:55] <Keybuk> you could also patch file-rc to support the changes to update-rc.d
[12:55] <Keybuk> though if you're going to give it love, you should almost certainly also patch it to support things like usplash
[12:56] <Keybuk> packages could then Depend: sysv-rc (>= 2.86.ds1-14ubuntu2) | file-rc (>= 0.8.10ubuntu1)
[12:57] <geser> I will see if I can produce a patch for file-rc for the recent changes in update-rc.d
[12:58] <StevenK> Keybuk: I noticed your latest upload of n-m failed to build, so I've gone ahead and pulled it up to 0.6.4 along with fixing the patch so it applies.
[01:01] <Keybuk> StevenK: no, please don't
[01:02] <StevenK> 0.6.4 is a bugfix release, and I suspect the patch I had to fix will apply to 0.6.3 anyway.
[01:02] <Keybuk> if it's a bug fix release, provide the changelog and diff to the release team
[01:02] <StevenK> Aye
[01:17] <shenki> on the subject of networkmanager, I would like to see the vpn plugins make it into edgy (they're a part of n-m, but not the main tarball, and hence weren't in dapper)
[01:17] <shenki> I had no idea about how to go about it, so I wrote https://wiki.ubuntu.com/CompleteNetworkManager - any hits/tips/go-aways?
[01:18] <Keybuk> shenki: all suitable for universe
[01:19] <ogra> its already on revu since some time iirc
[01:19] <shenki> Keybuk: yep, that's what I thought. who would be a good person to talk to about it? I've brought it up in -motu a few times, but no one was around who could give me the right kind of advice
[01:20] <Keybuk> what do you need to talk about?
[01:21] <jono> hey
[01:21] <Keybuk> hey jono
[01:21] <ogra> looks like the package was never finished and has only one advocate yet
[01:21] <jono> hey Keybuk :)
[01:22] <shenki> Keybuk: doing whatever needs to be done to make sure it gets in edgy
[01:22] <Keybuk> shenki: do it then ;)
[01:22] <ogra> shenki, http://tiber.tauware.de/details.py?upid=2283
[01:22] <shenki> heh
[01:22] <shenki> that's the plan
[01:22] <shenki> lacking a little on the knowhow at this point though
[01:22] <ogra> best to talk to tonio i guess
[01:23] <shenki> okay. thanks
[01:24] <shenki> had no idea about how/what/where revu was before a few minutes ago
[01:24] <shenki> so cheers for the pointers
[01:30] <shawarma> shenki: I'm going to  work on networkmanager, too.
[01:31] <shawarma> shenki: I hope to fix it enough to even make Keybuk happy. :-)
[01:31] <shenki> shawarma: what aspect of it? did you read the wiki page I wrote?
[01:31] <shenki> heh, what will that take?
[01:31] <shawarma> shenki: Yes.
[01:31] <shawarma> shenki: voodoo.
[01:31] <shenki> intresting
[01:31] <Keybuk> shawarma: in what kind of direction, ooi?
[01:32] <shawarma> shenki: Well, mostly it has to do with the way it handles DNS.
[01:32] <Keybuk> my thoughts have been to make network-manager conflict with ifupdown entirely, so once you install it, it forces you to rely on it
[01:32] <shenki> shawarma: well, let me know if you want any help or testing. also, Fujitsu mentioned to me he's going to package pam_keyring
[01:32] <shawarma> shenki: Right now, it doesn't, but I'd like it to.
[01:32] <Keybuk> which takes away a lot of the interaction bugs
[01:33] <Fujitsu> Keybuk, that's probably a good idea.
[01:33] <shenki> Keybuk: you'd really need to wait until 0.7 to do that, because what you're suggesting would make the system unable to be online without logging into your desktop
[01:33] <shawarma> Keybuk: IIRC your main concern was how to deal with network manager changing resolv.conf, but applications not knowing about it.. The NM guys "fix" this by depending on bind, which sucks.
[01:34] <shawarma> Keybuk: What if we made it depend on one of the DNS proxies already in main. One of the tiny ones, of course.
[01:34] <shawarma> shenki: the pam_keyring thing is totally separated.
[01:35] <shawarma> Mithrandir: well.. It'd make sense for the networkamanger daemon to set it to point at 127.0.0.1 at boot and then never touch it again.
[01:35] <shenki> shawarma: seperated from networkmanager? yeah, i realise that. but it's essential for making network manager user friendly, unless 0.7 makes it into edgy (haha)
[01:35] <Mithrandir> shawarma: why do you think so?
[01:35] <shawarma> shenki: i suppose. I've never found that particular part very annoying. :-)
[01:36] <shenki> shawarma: do you have to type your password into that bloody login box every time you turn on your laptop?
[01:36] <Keybuk> shawarma: then n-m would end up in universe
[01:36] <shawarma> Mithrandir: Well, that way there can be a dns proxy (whose settings can be altered at any point in time by nm), and we won't need to notify any apps of any change.
[01:36] <Keybuk> why do you need to notify apps of the change to resolv.conf?
[01:37] <Mithrandir> shawarma: we don't need to notify apps anyway.
[01:37] <Keybuk> we patch libc so that apps reload resolv.conf if it changes mtime
[01:37] <shawarma> Keybuk: Because some apps don't use libc for doing dns lookups and not all of them are clever enough to notice when something changes in resolv.conf
[01:37] <Keybuk> shawarma: *shrug*
[01:37] <Mithrandir> shawarma: then they should be patched.  *shrug*.
[01:37] <shawarma> Keybuk: firefox springs to mind..
[01:37] <Keybuk> Mithrandir++
[01:38] <Mithrandir> shawarma: firefox handles resolv.conf changing just fine.
[01:38] <Keybuk> we're not putting any kind of DNS daemon in ubuntu-desktop
[01:38] <shawarma> Mithrandir: ok.
[01:38] <Keybuk> it'd conflict with people running their own DNS server of choice
[01:38] <shawarma> Mithrandir: But it's one of those apps that doesn't use libc for it.
[01:38] <shawarma> Keybuk: Sure. But those people are probably not the people using networkmanager.
[01:38] <Kamion> oh, BLOODY HELL, dash as /bin/sh breaks debconf escaping
[01:39] <Keybuk> shawarma: but that'd prevent anyone from using n-m
[01:39] <Keybuk> Kamion: eww, I assumed at least that debconf was bashism free
[01:39] <Kamion> uses echo
[01:39] <shawarma> Keybuk: Huh? What would?
[01:39] <Mithrandir> shawarma: can you come up with an app that breaks?
[01:39] <shawarma> Mithrandir: I can make on in a few minutes. :-D
[01:40] <Keybuk> shawarma: depending on a DNS daemon prevents people from installing their own DNS daemon without uninstalling n-m
[01:40] <Keybuk> shawarma: thus if n-m was in ubuntu-desktop, people with an ubuntu desktop can't run a DNS daemon
[01:40] <Keybuk> we don't want that
[01:40] <shawarma> Mithrandir: but fine, let's leave the dns proxy out then. Why would it not be alright for nm to edit resolv.conf?
[01:40] <Keybuk> so if n-m depends on a DNS daemon, n-m cannot be installed by default
[01:40] <Kamion> Keybuk: ("echo 'foo\nbar'" behaves differently in bash and dash)
[01:40] <Keybuk> shawarma: dhclient edits resolv.conf already
[01:41] <shawarma> Keybuk: Yes, you've mentioned. :-) However, other things might have valuable information that belongs in there. In particular the vpn plugins.
[01:41] <Keybuk> shawarma: those things can edit resolv.conf
[01:41] <Mithrandir> shawarma: there's no more reason for it to edit resolv.conf than there is for it to edit /etc/passwd.
[01:41] <Keybuk> tbh, my ideal n-m situation would be:
[01:41] <Keybuk> - conflicts with ifupdown
[01:41] <shawarma> Keybuk: If THEY can why can't nm?
[01:42] <Keybuk> shawarma: why does nm need to?
[01:42] <shawarma> because you often use different DNS settings when you're on VPN.
[01:42] <Keybuk> shawarma: right, I just said the vpn plugins could cause resolv.conf to change ...
[01:42] <Fujitsu> We need a resolve.conf.d :P
[01:42] <ogra> eek
[01:42] <shawarma> If each vpn plugins implements it's own, that's (currently) three extra places things can go wrong as opposed to one if we let nm do it.
[01:43] <Keybuk> Fujitsu: tbh, we need resolv.conf to be a symlink to /var/run/resolv.conf or something
[01:43] <Keybuk> to stop people thinking that they can edit it and have their chnages saved
[01:43] <StevenK> Keybuk: If n-m conflicts with ifupdown, what do you do about people who use n-m to run the ifupdown hooks?
[01:43] <Keybuk> shawarma: I don't care where the function itself goes
[01:43] <Fujitsu> Keybuk, yeah, that's a bit of a danger.
[01:43] <Keybuk> StevenK: n-m runs them itself using run-parts
[01:44] <Keybuk> /usr/share/NetworkManager/dispatcher.d/01ifupdown
[01:44] <StevenK> Oh, duh, so it does.
[01:44] <shawarma> Keybuk: So the function can be in nm, but the vpn plugins should call it? That's the way it works if we let nm change resolv.conf.
[01:44] <Keybuk> shawarma: indeed
[01:44] <shawarma> Keybuk: but.. ?
[01:44] <Keybuk> but nothing
[01:44] <Mithrandir> shawarma: apart from the fact that the backends will have to be able to edit resolv.conf _anyway_ if they're to function without NM?
[01:45] <shawarma> Mithrandir: The backends? the VPN plugins?
[01:45] <Mithrandir> shawarma: the VPN plugins probably talk to openvpn or similar, right?
[01:45] <shawarma> Mithrandir: Well... Yes.
[01:46] <Mithrandir> shawarma: and openvpn (or whatever) will have to be able to edit resolv.conf whether you use NM or not, right?
[01:46] <Keybuk> and openvpn/pppd/etc. usually write resolv.conf themselves anyway
[01:46] <shawarma> Keybuk: But nothing? Then why have we set it to NOT allow it to edit it?
[01:46] <Keybuk> shawarma: because then it does something very stupid
[01:46] <Keybuk> dhclient writes resolv.conf from the DHCP response
[01:46] <Keybuk> n-m parses dhclient's log, and overwrites resolv.conf again
[01:46] <Keybuk> which is just wrong
[01:46] <Keybuk> n-m doesn't need to do anything!
[01:47] <Keybuk> likewise for things like openvpn and ppp, they write resolv.conf themselves *anyway*
[01:47] <Keybuk> n-m shouldn't get involved
[01:47] <Mithrandir> Keybuk: NM also changes my domain search path, which is wrong.
[01:47] <shawarma> Keybuk: Right, in the case of dhclient. 
[01:47] <Keybuk> shawarma: it's true in the case of almost everything n-m uses
[01:47] <Keybuk> Mithrandir: right, it rewrites it wrong
[01:47] <shawarma> Keybuk: vpnc for instance only alters resolv.conf if resolvconf is installed (the package).
[01:48] <Keybuk> shawarma: that sounds like a bug in vpnc
[01:48] <Keybuk> it should write resolv.conf anyway
[01:48] <Mithrandir> Keybuk: yes and no.  There's no way for me to tell it to keep away from changing that part of the file.  It's trivial to get dhclient to behave correctly.
[01:48] <zul> hi
[01:48] <Keybuk> Mithrandir: to be fair, if you're using n-m, you shouldn't care what's in that file
[01:48] <Keybuk> which is why I want n-m to cause the removal of anything you had to care about
[01:48] <shawarma> Mithrandir: Will that be any better if we let the different vpn backends change resolv.conf?
[01:48] <pitti> Riddell: does Kubuntu use libnotify?
[01:49] <pitti> Riddell: (and notification-daemon)
[01:49] <Riddell> pitti: nope
[01:49] <Kamion> Keybuk: it's Debian #306134, if you're keeping bashism score
[01:49] <Ubugtu> Debian bug 306134 in debconf "Subject: /usr/share/debconf/confmodule usage of echo to communicate with debconf breaks values containing \\" [Normal,Open]  http://bugs.debian.org/306134
[01:50] <Mithrandir> Keybuk: domain search path is a completely legal thing for the user to change, IMNSHO.
[01:50] <pitti> Riddell: I will start our mini-frontend for crash reports soon and pondered about a simple inotify -> libnotify app (just to display that there's a new report, asking to file a bug)
[01:50] <pitti> Riddell: so we'll need a -gtk and a -kde version
[01:50] <Mithrandir> I like "ssh aine" and "http://aine" to go to the right box no matter what network I'm on.
[01:50] <shawarma> Mithrandir: What if network-manager had a configuration option to let you prepend certain things to your domain search path?
[01:51] <Mithrandir> shawarma: I don't want to prepend.  I want to keep my search path in a particular way.
[01:51] <shawarma> don't get me wrong here guys. I'm not a nm fan boy. :-) I just think nm does exactly what most of our potential users want it to and I want to give it to them. If that steps on someone else's toes, I'll try to fix it as best I can. I just need to know.
[01:52] <shawarma> Mithrandir: Ok.. so if you could do that, would you be a happy man?
[01:52] <Mithrandir> shawarma: mostly, yeah.
[01:54] <shawarma> So.. I agree that the different vpn backends probably know how to fix resolv.conf themselves, but in order to ensure a consistent handling of it (e.g. keeping the right search path) it's a helluva lot easier if only ONE thing changes it (e.g. network manager).
[01:54] <Riddell> pitti: gnome-cups-manager needs to depend on gksudo
[01:55] <pitti> Riddell: oh, good point; Recommends: at least
[01:56] <Riddell> pitti: I'd say depends, it's quite disconcerting clicking a menu item and nothing happening unless you look at stdout
[01:58] <pitti> Riddell: true
[01:58] <pitti> Riddell: ok, I wanted to apply an old patch anyway, good opportunity to fix this as well
[01:59] <Riddell> pitti: are you going to add an Enable Sharing option?
[01:59] <pitti> Riddell: exactly that
[02:07] <Keybuk> going into vmware for a bit to test migration and resume-by-uuid
[02:08] <infinity> slomo: Done.
[02:09] <ogra> seb128, do we have the pango ottest tool packaged anywhere or do i need the source ? (gvim is complaining a lot about GPOS table)
[02:09] <seb128> ogra: "ottest"?
[02:10] <ogra> a tool to parse the OpenType tables in all fonts ... it should be in the pango source
[02:10] <seb128> it's not packaged afaik
[02:11] <ogra> thanks ...
[02:11] <ogra> hmm, locate doesnt show any .otf fonts either ... i wonder why it complains then
[02:11] <seb128> ogra: the static build has it apparently but it's not shipped
[02:12] <ogra> well, the GPOS error should only show up for otf fonts, which i dont even have ... weird
[02:12] <seb128> ogra: on what font do you want to run ottest?
[02:13] <ogra> seb128, i'd run it over all of them to find the gulty one ...
[02:13] <ogra> *guilty
[02:13] <ogra> but i dont have any otf fonts installed ... so that error is nonsense
[02:14] <seb128> why do you look for an otf?
[02:14] <seb128> "(vim:378): Pango-WARNING **: Error loading GPOS table 4097"?
[02:14] <seb128> you get that?
[02:14] <ogra> GPOS is a class of tables in OpenType fonts
[02:14] <ogra> yes
[02:41] <ogra> pitti, did you think about adding a requirement for lsb_init to the MIR requirements ? for packages with initscripts ?
[02:50] <pitti> ogra: that is already a requirement, however, not mentioned in the template
[02:50] <pitti> ogra: good point, I'll add that
[02:51] <ogra> thanks :)
[03:08] <tseng> Kamion: is there an official process/queue for proposing changes to the desktop seed?
[03:09] <tseng> Kamion: I'm aware that I can "just do it", but I'd normal expect to run such things past you/mdz
[03:09] <schasi> hi there
[03:10] <mdz_> tseng: hmm?
[03:10] <mdz_> tseng: oh, yes
[03:10] <mdz_> tseng: we don't have an official process really, no.  what is it you'd like to discuss?
[03:10] <tseng> f-spot, tomboy to desktop seed
[03:10] <tseng> possibly deprecating gthumb
[03:11] <ogra> ugh
[03:11] <tseng> with an appropriate migration path.
[03:11] <schasi> Is there some documentation about /etc/debian_version and why it contains testing/unstable?
[03:11] <ogra> tseng, any idea how much space that will eat with all its deps ? 
[03:11] <tseng> ogra: last I looked at f-spot it was about 10mb on x86
[03:11] <ogra> no way for edubunt then
[03:11] <tseng> tomboy uses the same deps
[03:11] <ogra> *edubuntu
[03:12] <slomo> ogra: including mono runtime etc... with the splitted runtime library it should be even less
[03:12] <tseng> slomo: thats true.
[03:12] <ogra> slomo, everything above 1-2M is to much
[03:12] <seb128> ogra: the python cleanup didn't win you some space?
[03:12] <ogra> it did ... we've eaten up 10 of the 20 already ...
[03:13] <seb128> anyway we can't stop on making changes that make sense for Ubuntu because edubuntu has no CD space
[03:14] <ogra> seb128, i understand ... but i wont be able to include stuff that makes the CD grow ... which means we need to keep gthumb in main :(
[03:15] <seb128> ogra: no big deal, that's not a high-maintenance cost package
[03:16] <ogra> seb128, well, its one more on my plate thats edubuntu specific :)
[03:16] <seb128> ogra: right
[03:20] <ogra> why the heck cant he do such changes at the beginning of a dev cycle ... grmbl
[03:20] <Riddell> pitti: could I see your sharing patch?  I was wanting to steal the warning string for KDE
[03:21] <tseng> mdz: sorry, I didnt address that to you specifically above.. all the recent discussion was related.
[03:22] <mdz> tseng: I'd like to ship them
[03:23] <tseng> mdz: cool.. I can edit the seeds when I am at a PC with crypto keys and then heat up the gthumb migration discussion. thanks!
[03:29] <seb128> tseng: are you subscribed to the ubuntu-desktop list?
[03:30] <bddebian> Hello folks
[03:30] <seb128> tseng: there is a discussion about f-spot and gthumb from one week ago on it, maybe you could participate on that one instead of starting a new one?
[03:30] <seb128> bddebian: hi
[03:30] <bddebian> Hello seb128
[03:30] <seb128> bddebian: so, what is your issue with launchpad-integration and what should be better communicated?
[03:31] <bddebian> seb128: I guess nothing, just my own ignorance
[03:31] <seb128> bddebian: I would think so but you added a comment saying we could let people know about such changes or something like that
[03:35] <bddebian> I was having a rough week. Colin had a good point that I should have caught it on the diff.
[03:35] <seb128> ok, no problem then :)
[03:36] <bddebian> I do feel like those of us living in Universe are a little in the dark at times.  We really have no centralized "leadership"
[03:37] <seb128> bddebian: lpi is only used for the desktop, not for universe ... :)
[03:38] <bddebian> Oh crap, I didn't even catch that gcalctool was main...  Now I feel even worse.. :'-(
[03:39] <slomo> seb128: oh, shall i remove the lpi patch from xchat then now that it is in universe?
[03:39] <seb128> bddebian: it's the official GNOME calculator ... :)
[03:39] <seb128> slomo: it doesn't hurt but I'm not sure there is a real point to keep it neither
[03:40] <seb128> slomo: we modify xchat anyway for the list of chans, etc so you can as well keep it
[03:41] <slomo> seb128: ok... it's a fairly small diff anyway and applied the past versions without any necessary changes :)
[03:42] <Gloubiboulga> slomo, will you package the last xchat release or wait for debian to do it?
[03:43] <bddebian> Congrats Gloubiboulga :)
[03:43] <Gloubiboulga> (I've quickly packaged it for me using libsexy, it works fine :) )
[03:44] <Gloubiboulga> hi bddebian, and thanks... but congrats for what? :)
[03:44] <seb128> co-leading xubuntu probably
[03:44] <Gloubiboulga> oh yes...
[03:45] <mdz> Mithrandir: ping
[03:45] <Mithrandir> mdz: hi
[03:45] <Gloubiboulga> I need to become a core-dev first ;)
[03:45] <seb128> Gloubiboulga: you already forgot about it? :p
[03:46] <Gloubiboulga> seb128, no I didn't ;)
[03:47] <bddebian> Gloubiboulga: Aye, xubundu
[03:48] <bddebian> Gloubiboulga: Well you get a +1 from me.  Unfortunately my opinion is worthless around here :-)
[03:49] <Gloubiboulga> bddebian, thanks :)
[03:53] <Kamion> schasi: no documentation as far as I know, but for Ubuntu you should use lsb_release; the reason we keep /etc/debian_version is that it means that code that looks at the version of the distribution to try to figure out how to behave will generally do roughly the right thing if it doesn't specifically know about Ubuntu
[03:57] <pitti> Riddell: we still have to dig it out again
[03:58] <bddebian> Hobbsee: I dont think it, I KNOW it :)
[03:58] <Hobbsee> bddebian: dont know it either.  it's stupid to believe things that are wrong.
[03:58] <schasi> Kamion:  Thx. Someone guessed it was for compatibility reasons
[03:59] <schasi> And someone else guessed it was just forgotten by the developers
[03:59] <Kamion> the first person is correct; the second person is wrong
[04:00] <slomo> Gloubiboulga: i've already updated it... :P
[04:01] <Gloubiboulga> slomo, xchat 2.6.6?
[04:01] <slomo> Gloubiboulga: yes
[04:02] <Gloubiboulga> nice :)
[04:04] <Hobbsee> *back
[04:09] <tseng> seb128: i am not on that list
[04:10] <tseng> seb128: corey told me about it when he posted and i read it, no one was saying anything useful at the time
[04:10] <Kamion> slomo:  cli-common (0.4.3ubuntu1) unstable; urgency=low
[04:10] <Kamion> ^-- wrong distribution
[04:11] <seb128> tseng: not sure of what would be "useful" to a discussion about changing the default software, that's sort of people arguing
[04:11] <slomo> Kamion: oh, thanks for noticing :)
[04:11] <HiddenWolf> You'd always be bogged down in "I like X vs I like Y"
[04:13] <Hobbsee> HiddenWolf: you forgot the "BUT I LIKE Z, GIVE IT TO ME NOW!!!!!"
[04:14] <HiddenWolf> Hobbsee or "I'll run screaming to gentoo if you don't do it!"
[04:14] <Hobbsee> HiddenWolf: true
[04:17] <mdke> elmo: around?
[04:18] <Kamion> Seveas: could you please mark bugs "Needs Info" when you're asking for more information on them (you always seem to forget to do that with ubiquity bugs)?
[04:19] <ThunderStruck> is there any plan to update "reportbug" to stop using ubuntu-users?
[04:20] <Kamion> yeah, there's an xmlrpc filebug API to Malone now, so reportbug can be fixed
[04:20] <ThunderStruck> Kamion: im looking at a bug on it right now
[04:20] <ThunderStruck> thats why i asked
[04:20] <elmo> mdke: ?
[04:21] <mdke> elmo: the doc-commits email list doesn't seem to be working
[04:21] <mdke> any ideas?
[04:24] <Kamion> ThunderStruck: there are several very old bugs about it, yes
[04:25] <ThunderStruck> ok ty Kamion 
[04:28] <bddebian> Hobbsee: Can't be any worse than mine :-)
[04:29] <Hobbsee> bddebian: i meant in number.
[04:29] <elmo> mdke: when was the last commit you know off?
[04:29] <bddebian> Hobbsee: I know
[04:32] <Kamion> Hobbsee: they're called syncs :-)
[04:32] <Hobbsee> Kamion: oh bleh.  i blame the incredible amount of boring material to be read at work.  i do know they're syncs, really...i think...
[04:33] <bddebian> Wasn't me or I'd have one now ;-)
[04:33] <Mithrandir> oh, sorry
[04:33] <ogra> yippidy ... finally a g-p-m build that survived ... now ... may it not crash ...
[04:33] <Hobbsee> Mithrandir: oh thankyou.  much appreciated.
[04:33] <maswan> oh
[04:33] <Mithrandir> maswan: more brane for me to eat?  yummy.
[04:34] <Hobbsee> hehe
[04:34] <Hobbsee> Mithrandir: how'd my brain taste?
[04:34] <maswan> Mithrandir: I saw two zombie movies last night. :)
[04:34] <Mithrandir> Hobbsee: a bit spongy.
[04:34] <Mithrandir> maswan: I saw Grease and Dirty dancing last night. :-)  Also quite good.
[04:34] <Hobbsee> Mithrandir: heh.  what, that means they're stuff there, or not?
[04:35] <Mithrandir> Hobbsee: absolutely.  Lots of stuff in your brain.
[04:35] <maswan> Mithrandir: Did they eat lots of braaaains?
[04:36] <Mithrandir> maswan: no, no brains, but lots of cool dancing which is good too.
[04:36] <Hobbsee> Mithrandir: ahh..good...interesting stuff?
[04:36] <Mithrandir> Hobbsee: I wouldn't know when I'm just chewing.
[04:36] <Hobbsee> Mithrandir: heh
[04:36] <maswan> Mithrandir: Ah, I guess that could work, if you swing that way.
[04:39] <pitti> can some ftp master please free cupsys and apport from NEW?
[04:42] <mdke> elmo: yesterday, rev 3183
[04:42] <mdke> elmo: Last Changed Date: 2006-07-23 04:47:23 +0100 (Sun, 23 Jul 2006)
[04:44] <elmo> mdke: hmm, no can't see why offhand - can you mail it to rt, and I'll get someone to investigate?
[04:44] <mdke> elmo: certainly, thanks.
[04:45] <bddebian> Did ivman get demoted to Universe in Edgy?
[04:45] <bddebian> Never mind
[04:46] <mdke> elmo: done, ticket #15016
[04:52] <mdke> jdub: can you re-add me to planet ubuntu? I'm not in the list of feeds
[04:53] <Hobbsee> mdke: he's likely to be asleep, FYI
[04:54] <mdke>  /away is so underused nowadays
[04:54] <mdke> Hobbsee: thanks
[04:54] <Hobbsee> mdke: heh, true.  it's almost 1am here
[04:58] <bddebian> So what the heck do with do with a package that looks like it has been completely maintained seperately in Ubuntu?
[05:02] <tseng> bddebian: talk to the person in ubuntu who ddi that?
[05:02] <tseng> and find out why.
[05:03] <bddebian> tseng: Several people have touched it.  Riddell, janimo, and others
[05:03] <zul> who was the last one?
[05:04] <bddebian> Someone I have never heard of: Daniele Favara
[05:04] <tseng> maybe thye packaged it first for ubuntu, and debian came later
[05:04] <tseng> like happened with Beagle
[05:04] <tseng> I have since reconciled these changes
[05:04] <bddebian> I would have thought so too but every release in ubuntu seems to be an ubuntu one
[05:05] <tseng> only persons who know are in that changelog
[05:06] <Riddell> bddebian: what's the package?
[05:06] <bddebian> Riddell: ivman :-)
[05:07] <bddebian> Looks like it was kubuntu, now xubuntu
[05:07] <Riddell> bddebian: that was used in the first kubuntu, then kde didn't need it any more but it get used by xubuntu
[05:07] <Riddell> Gloubiboulga: do you know if xubuntu still uses ivman?
[05:30] <Gloubiboulga> Riddell, it doesn't
[05:30] <bddebian> Gloubiboulga: So you think we can just sync from Debian?
[05:32] <Gloubiboulga> bddebian, I'll look at this
[05:32] <Gloubiboulga> but I think that it can be synced
[05:33] <bddebian> Gloubiboulga: Well I can test the package to see if it can build
[05:38] <Gloubiboulga> bddebian, actually I've already tested the build a few days ago nad it FTBFSed, but it should be fixed with the last debian package
[05:38] <bddebian> Oh, hmm
[06:07] <wasabi_> I guess swapd isn't really maintained actively anymore.
[06:36] <iwj> Can anyone here tell me this, in pitti's absence: if I upload to hoary-security, I trust someone will get a chance to review and perhaps ditch my upload, if they feel like it ?
[06:40] <pitti> iwj: not ditch, but I can decide to not upload it
[06:40] <pitti> iwj: s/upload/publish/
[06:40] <iwj> Right.
[06:40] <pitti> iwj: so if you do another upload with a higher version number, all will be fine
[06:40] <iwj> Since you're here, see my comments in msg.
[06:49] <Spads> mdke: ping
[07:11] <LaserJock> iwj: have a sec to discuss developer's reference?
[07:11] <iwj> LaserJock: Sure, but it'll have to be very quick.
[07:12] <iwj> I have to go for dinner within a few minutes ...
[07:27] <Petaris> ajmitch: ping
[07:28] <Petaris> ajmitch: Have a minute to talk about AD integration?
[07:28] <Hobbsee> Petaris: wrong time of night, i expect
[07:29] <Petaris> Hobbsee: darn, your right
[07:29] <Petaris> I forgot that its insanly early there
[07:29] <Hobbsee> :P
[07:29] <Hobbsee> well, 2 hours behind
[07:29] <Petaris> Is there anyone else working on the AD integration that you know of?
[07:30] <mvo> Kamion: can you please promote libgksu2 to main?
[07:31] <Hobbsee> Petaris: no idea
[07:32] <Petaris> Hobbsee: bummer
[07:32] <Petaris> maybe ogra knows
[07:33] <ogra> nope ... only ajmitch is working on it afaik...
[07:34] <Petaris> :/
[08:35] <mdke> Spads: pong
[08:35] <Spads> oh hey, mdke 
[08:35] <mdke> howdy
[08:36] <mdke> doc-commits seems to be catching up, thanks!
[08:36] <Spads> well
[08:36] <Spads> I have bad news for you
[08:36] <mdke> ah
[08:36] <Spads> those are being manually run by us to test things
[08:36] <mdke> fine, fine.
[08:36] <Spads> mdke: so i'd like it if you could make a test commit
[08:37] <mdke> hang on
[08:37] <Spads> just make a whitespace change or something
[08:38] <mdke> Spads: right, done
[08:39] <Spads> thanks
[08:40] <Spads> https://lists.ubuntu.com/archives/ubuntu-doc-commits/2006-July/002700.html <-- is this it?
[08:40] <mdke> Spads: yep :)
[08:41] <Spads> marvelous
[08:41] <mdke> Spads: thanks! And nice to meet you, virtually speaking
[08:43] <Spads> mdke: the pleasure is mine!
[08:43] <Spads> happy to be of service
[08:45] <Spads> mdke: do you want me to run the missing commits so that they appear in the list?
[08:45] <mdke> Spads: if it's easy to do so, that would be great. Otherwise, don't worry
[08:46] <Spads> yeah, it's pretty easy
[08:46] <Spads> hangon
[09:23] <linuxboy> highvoltage
[09:23] <highvoltage> :)
[09:34] <Vhata> why has Ubuntu (or did it come from Debian?) filled up /etc/skel/.bashrc with so much cruft?  Surely the skeleton files should be kept to a bare minimum so that sysadmins can override them from /etc/{profile,bash.bashrc}, and then ricer users can override *those* settings in their own files if they want?
[09:36] <Vhata> PS1, for example, shouldn't be set in there
[09:36] <crimsun> that's irrelevant in Edgy, since bash is no longer the system shell.
[09:36] <Vhata> I'm more questioning the policy, I suppose
[09:37] <mjg59> Because applications should have sensible defaults
[09:38] <Vhata> and those defaults should be set system wide in /etc/whateverrc, not per-user in ~/.whateverrc
[09:38] <mjg59> I guess you could argue they should be in /etc/profile or whatever instead, but then upgrades would change behaviour for users and scripts may break
[09:39] <mjg59> Bash should just use gconf for settings. Then the world would be better.
[09:39] <Vhata> that's true.  But surely pushing the behaviour to the edge (i.e. per-user) isn't a good way to solve that?
[09:39] <Vhata> heh
[09:39] <mjg59> Making it per-user means that the experience for any one user is consistent, which is arguably the lesser of two evils
[09:40] <mjg59> Traditional unix config doesn't really deal with this sort of situation terribly well
[09:40] <Vhata> *nod*
[09:40] <Keybuk> crimsun: umm, bash is still the default user shell
[09:41] <crimsun> Keybuk: right, but I don't think that's much of an issue for users, no?
[09:41] <Keybuk> crimsun: everything Vhata said only affects users
[09:41] <crimsun> ok, I concede that
[09:45] <Keybuk> so, question time
[09:45] <Keybuk> does anybody here have a Broadcom wireless card and uses the bcm43xx driver?
[09:45] <slomo> Keybuk: i have one
[09:46] <Keybuk> slomo: do you use it with ifup or network manager?
[09:47] <Keybuk> do you find that it doesn't load its firmware until it's ifconfig'd up?
[09:47] <slomo> yes, that's normal for the driver
[09:47] <Keybuk> ie. iwlist scan won't work
[09:47] <Keybuk> *nods*
[09:47] <Keybuk> right
[09:47] <slomo> i use it with ifup btw... n-m never worked good for me
[09:49] <geser> Keybuk: I've prepared a patch for update-rc.d from file-rc. It's bug 53894. Can you give it a look?
[09:49] <Ubugtu> Malone bug 53894 in file-rc "add support for multiuser in update-rc.d" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53894
[09:50] <Keybuk> geser: yup, seems reasonable to me
[09:50] <Keybuk> did you also patch file-rc to support usplash?
[09:50] <geser> not yet
[10:07] <bluefoxicy> Keybuk:  I've noticed weirdness with wireless drivers like that a lot... re http://rafb.net/paste/results/AhgL3X53.html for a linksys WUSB54GC, the machine immediately recognizes it's a wireless NIC but doesn't really know how to operate it.
[10:43] <bigcx2> hey all
[10:43] <bigcx2> i have a question about kernel-patch packages in general
[10:44] <bigcx2> is the running kernel patched by default, on a reboot, or does it have to be manually done?
[10:44] <Petaris> ajmitch: ping
[10:45] <tseng> the running kernel is certainly not patched
[10:45] <Petaris> ajmitch: Have a minute to discuss AD integration?
[10:45] <bigcx2> alright
[10:45] <bigcx2> what about the other two tseng
[10:45] <tseng> what other two?
[10:46] <tseng> patches are not magic, they apply to a directory full of source code
[10:46] <bigcx2> does it get patched on a reboot? or does it have to be done manually after package installation
[10:46] <tseng> you build the patched code and finally run it
[10:46] <tseng> in the case of the kernel that means booting it
[10:46] <tseng> this is one of those times when the addage applies
[10:47] <tseng> "if you don't know what you are doing, you are better off not doing it"
[10:47] <bigcx2> right, but my question is in terms of packaging
[10:47] <bigcx2> so
[10:47] <tseng> the package installs patches to /usr/src or something like this
[10:47] <bigcx2> for example i install kernel-patch-uml
[10:47] <bigcx2> correct
[10:47] <tseng> it doesnt do anything with them.
[10:47] <tseng> thats up to you
[10:48] <bigcx2> ok, whats the proper way to go about patching it once its installed
[10:48] <bigcx2> theres no docs in /usr/share/doc
[10:48] <tseng> as I said before, if you dont know how to use patch or build a kernel, you are probably going to end up in a bad place
[10:49] <tseng> if you really want to continue you can read up on man patch
[10:49] <bigcx2> tseng: i'm doing this on a virtual machine to learn....
[10:49] <tseng> also look at kernel-package
[10:52] <bigcx2> look, that has nothing to do with patching in the context of which i'm talking about
[10:52] <bigcx2> all i want to know is how to enable a patch already packaged under ubuntu
[10:57] <bddebian> heh
[11:33] <pygi> rraphink, hey hey
[11:33] <rraphink> hi pygi
[11:37] <lucas> who should I bug for a mailing list creation ?
[11:38] <tseng> jdub
[11:38] <elmo> no
[11:38] <pygi> sivang, poke
[11:38] <elmo> mail mailman@lists.ubuntu.com, not jdub
[11:40] <bluefoxicy> So you guys read this right  http://lwn.net/Articles/192214/  (yes this is a dumb question)
[11:41] <tseng> bluefoxicy: I might have read something about if i had any idea what that page is
[11:43] <lucas> thx
[11:43] <bluefoxicy> tseng: uh, it's a LWN article about how slow and inefficient crap in userspace is, i.e. hal opening several thousand files, gnome-cups-icon polling cups for new printers multiple times a second, etc..
[11:43] <tseng> wow, top story
[11:44] <tseng> strace at 11
[11:44] <bddebian> hehe
[11:45] <crimsun> bluefoxicy: (it's subscriber-only presently)
[11:45] <bluefoxicy> ah
[11:45] <bluefoxicy> crud.  crimsun:  You're not a Debian developer as well?
[11:45] <crimsun> bluefoxicy: no.
[11:46] <crimsun> (I'm an LWN subscriber, so I've read it.)
[11:46] <bluefoxicy> ok (all those guys have a group account, donated by HP)
[11:49] <Keybuk> tseng: yeah, it's a nice talk
[11:49] <Keybuk> it's all irrelevant if you use initng of course, which is TONS FASTER!
[11:53] <doko> pitti, I'll kill you!
[11:53] <doko> pkgstriptranslations: The following PO/POT files are empty. This is known to
[11:53] <doko> cause trouble in the translation importer and generally indicates a package
[11:53] <doko> bug:
[11:53] <doko> [...] 
[11:53] <doko> dh_builddeb: command returned error code 256
[12:03] <zul> hey