=== zeedo [n=zeedo@80.68.92.188]  has joined #ubuntu-devel
[12:10] <neuralis> Burgundavia, good start, i'll work on it when i get a chance
[12:12] <neuralis> Burgundavia, do you have mdy's e-mail address?
[12:13] <daniels> malcom.yates@canonical.com will almost certainly work
[12:13] <neuralis> daniels, thanks
[12:14] <mdke> his LP id is mdy
[12:14] <mdke> dunno if he'll have a redir
[12:14] <neuralis> yeah, checked, he doesnt have an address registered, and the wiki-page is empty
[12:14] <neuralis> daniels: that's malcolm.yates, isn't it?
[12:18] <daniels> yes
[12:18] <daniels> everyone has first.last@c.c
[12:19] <neuralis> daniels, yeah, you wrote malcom (no second 'l', was just checking).
[12:19] <daniels> i've not seen mallcom anywhere
[12:19] <neuralis> malcom vs malcolm.
[12:19] <daniels> oh
[12:20] <daniels> yeah
=== jsz [n=diego@59.Red-80-36-85.staticIP.rima-tde.net]  has joined #ubuntu-devel
[12:52] <Burgundavia> mdy@canonical.com also works
[12:55] <Burgundavia> neuralis, I might also have someone to help you with the coding of the server stuff
[12:56] <neuralis> Burgundavia, awesome, though i don't think it'll be necessary. it's looking to be one weekend of work.
[12:57] <Burgundavia> neuralis, for both the server and laptop backends?
[12:58] <Burgundavia> well, I guess would be a general hcl backend
=== blueyed [n=daniel@pdpc/supporter/active/blueyed]  has joined #ubuntu-devel
[12:59] <neuralis> Burgundavia, it's the exact same backend. there's a "hardware class" parameter, which lets you specify the input mask and data collected.
[12:59] <Burgundavia> ok
[01:00] <Burgundavia> I assume you have planned for different versions of ubuntu (both in de and in number)
[01:00] <sivang> hey Burgundavia , neuralis 
[01:00] <Burgundavia> salut sivang 
[01:00] <neuralis> hey sivang 
[01:01] <sivang> Burgundavia: how are you? how are thing?
[01:01] <sivang> err, things even
[01:01] <sivang> neuralis: Hi Ivan, what backend are you going to work on? :-)
[01:01] <Burgundavia> sivang, good. Just planning for the next installfest here in Victoria and the beginnings of the Ubuntu in library catalogues idea
[01:01] <neuralis> sivang, the hardware certification and community testing catalog
[01:02] <neuralis> Burgundavia, ubuntu version is just a dropdown in the input mask. reports from multiple versions are aggregated the same way as reports from multiple people: through the "alternate profiles" functionality.
[01:02] <Burgundavia> ah
[01:02] <sivang> neuralis: oh cool, does it have a spec?
[01:03] <Burgundavia> this going to be pygtk or webbased?
[01:03] <neuralis> sivang, TestingServerHardware and CommunityServerHardwareTesting
[01:03] <Burgundavia> and BetterLaptopTesting for that side
[01:04] <neuralis> Burgundavia, the backend is web-based for obvious reasons (we're testing servers, remember?). i envision someone will want to create a pygtk frontend for the laptop stuff eventually, but it'll still be posting to the same web backend.
[01:04] <Burgundavia> neuralis, my ideas exactly
[01:04] <sivang> neuralis: sounds cool, are you going to interface with each vendor's test suits or are we talking more in collecting data from users?
[01:06] <neuralis> sivang, it's in the spec - we're building our own test suite.
[01:07] <neuralis> sivang, vendors can only produce hardware test suites, but we care about how well *ubuntu* works on the hardware.
[01:09] <sivang> neuralis: Is the HCS and you doing that as a contribution to Ubuntu ?
[01:09] <neuralis> sivang, yes.
=== seth_k|lappy [n=seth@d-ip-129-15-213-40.wireless.ou.edu]  has joined #ubuntu-devel
[01:12] <sivang> neuralis: wow, rock on dudes! when you reach the p5 pServers part, ping me up - I may be able to help. I've been working with the beasties for the last year or so :-)
[01:12] <neuralis> sivang, sure thing, thanks.
[01:13] <sivang> neuralis: I also think DLPAR and LPAR tests are needed, to see if Ubuntu operates nicely under this environments
[01:13] <neuralis> p5 is not my area of expertise, but it's something we can certainly consider.
[01:14] <sivang> neuralis: I just happen to have a personal fetish for the beast ;)
[01:14] <neuralis> sivang, in that case, we'd be happy to have you help. that's dapper+1 material, however.
=== neuralis is an HP ProLiant guy
[01:15] <sivang> neuralis: ah I see, what platforms are going to be doing this for dapper?
[01:16] <neuralis> sivang, all three that we support -- i was talking about DLPAR and LPAR having to wait until dapper+1, not powerpc.
=== McFergus [n=frg@85-18-14-13.fastres.net]  has joined #ubuntu-devel
[01:16] <sivang> neuralis: the ProLiants are intel based?
[01:17] <neuralis> sivang, not all. xeons and opterons, depending on specific models.
[01:18] <sivang> neuralis: and I take it the HCS also has enough ppc's ? :)
[01:19] <neuralis> sivang, the certification process happens on hardware that vendors send us.
[01:22] <sivang> neuralis: ah
[01:22] <sivang> anyway, I'm way out of my timezone sleep time :) Laterz people, good night in the meanwhile.
[01:22] <sivang> neuralis: thanks for the discussion
[01:23] <neuralis> sivang, sure thing. g'night
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-devel
=== bmonty [n=bmontgom@wsip-68-15-230-31.om.om.cox.net]  has joined #ubuntu-devel
=== zul [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-devel
[02:12] <mdke> does anyone know if elmo managed to get planet synched with jdub's archive yet?
=== jamesh [n=james@203-59-207-160.dyn.iinet.net.au]  has joined #ubuntu-devel
=== [-Jarod-]  [n=jarod@lns-bzn-29-82-64-249-50.adsl.proxad.net]  has joined #ubuntu-devel
=== mae [n=mae@dpc674653178.direcpc.com]  has joined #ubuntu-devel
=== bmonty_laptop [n=bmontgom@wsip-68-15-230-31.om.om.cox.net]  has joined #ubuntu-devel
=== ikuyaLoqu [n=ikuya@gnulinux.good-day.net]  has joined #ubuntu-devel
=== SloMoSnail [n=slomo@p5487F688.dip.t-dialin.net]  has joined #ubuntu-devel
=== mxpxpod [n=bryan@unaffiliated/mxpxpod]  has joined #ubuntu-devel
=== psusi [n=phreak@103.202.33.65.cfl.res.rr.com]  has joined #ubuntu-devel
[03:38] <psusi> is there a way to enable debug messages for a specific kernel driver?  I see calls to printk that specify a debug level and driver name in the source, so I assume there is a way to turn those on
[03:39] <crimsun> generally yes. If it's modular, check via modinfo.
[03:39] <crimsun> otherwise you'll need to pass it as an option to the kernel command line
[03:40] <psusi> is there something like a file in /proc I can write to to turn on the printks in that module?
[03:40] <zul> not really it depends on the module
[03:43] <psusi> hrm... how so?  the module is making calls to printk... when it calls printk it specifies a debug level and the name of the calling module
[03:43] <psusi> so it looks like printk has some logic you can tune to filter messages on a per driver and level basis
[03:43] <crimsun> like chuck mentioned, it depends on the module
[03:44] <crimsun> for instance, ipw2200 has a 'debug' parameter
[03:47] <psusi> module sata_raid has no parameters according to modinfo -p
[03:47] <psusi> sata_via rather
=== psusi reads printk's source
=== LaserJock [n=LaserJoc@ppp-69-239-158-109.dsl.renocs.pacbell.net]  has joined #ubuntu-devel
=== kapputu [n=sg47@c-67-188-84-23.hsd1.ca.comcast.net]  has left #ubuntu-devel ["Leaving"] 
=== SEJeff [n=SEJeff@12-222-183-136.client.insightBB.com]  has joined #ubuntu-devel
=== psusi pokes SEJeff 
=== SEJeff rubs eye
[04:18] <SEJeff> psusi: hey
[04:22] <psusi> SEJeff, hey... how's it going?  do you happen to know how to enable all the nice debug printk's from a given module?  the module seems to pass printk a debug level and it's module name, so it looks like the idea is that printk somewhere can be told which ones to show and which ones to drop
[04:23] <SEJeff> psusi: use modinfo to see if the module has a debug param
=== psusi is trying to figure out why the sata_via driver bitches after suspend/resume
[04:23] <psusi> it doesn't... but I can see in the source it is calling printk, but I don't see those messages
[04:23] <SEJeff> psusi: Do you have xconsole open?
[04:24] <SEJeff> and do you look at dmesg?
[04:24] <daniels> echo 9 > /proc/sys/debug
[04:24] <psusi> well, when I'm interested in seeing the messages, it's at the console during suspend/resume... also checked dmesg and the syslog
[04:24] <SEJeff> /proc/sys/debug is a directory
[04:25] <SEJeff> Just /var/log/messages?
[04:25] <SEJeff> Or anything else
[04:25] <psusi> printk(KERN_INFO DRV_NAME "(%s): routed to hard irq line %d\n"
[04:25] <SEJeff> psusi, /var/log/debug maybe?
[04:25] <psusi> see, it gives it's name... so I would think you could filter on a per module basis
[04:26] <daniels> er, make that echo 9 > /proc/sys/kernel/printk
[04:27] <psusi> hrm... I'll try that
[04:28] <psusi> ok... going single user then suspending... bbiab
=== chmj_ [n=chmj@wbs-146-169-178.telkomadsl.co.za]  has joined #ubuntu-devel
=== LeeJunFan [n=junfan@s64-186-37-120.skycon.net]  has joined #ubuntu-devel
=== lamont [n=lamont@207.111.195.77]  has joined #ubuntu-devel
=== tkup [n=tkup@w-mob101-128-62-91-222.public.utexas.edu]  has joined #ubuntu-devel
=== kyncani2 [n=kyncani@lns-bzn-35-82-250-199-155.adsl.proxad.net]  has joined #ubuntu-devel
=== Xoff [n=mas01cr@gibbons.doc.gold.ac.uk]  has joined #ubuntu-devel
[05:17] <Burgundavia> for a good laugh --> http://www.ubuntuforums.org/showthread.php?t=89926
=== psusi [n=phreak@103.202.33.65.cfl.res.rr.com]  has joined #ubuntu-devel
[05:39] <psusi> the acpi scripts make calls to vbetool to save/restore the video state, only the lines to save it are commented out, and I can't find this vbetool on my system or in synaptic... anyone know where it is and why it was commented out?
[05:41] <bob2> ?
[05:41] <bob2> vbetool is the package name, too
[05:45] <psusi> searching for vbetool comes up with nothing
=== rob1 [n=rob@pdpc/supporter/student/rob-ubuntu]  has joined #ubuntu-devel
[05:48] <bob2> your sources.list is broken, packages.ubuntu.com/vbetool
[05:49] <psusi> ohh, it only exists for i386, strange
[05:49] <psusi> I'm running amd64
[05:50] <bob2> it runs real-mode code, iirc
[05:51] <psusi> why would that preclude amd64?
[05:51] <psusi> the processor supports real mode
[05:51] <psusi> or rather, v86 mode, which is where that would be run
=== tkup [n=tkup@w-mob101-128-62-91-222.public.utexas.edu]  has joined #ubuntu-devel
=== elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk]  has joined #ubuntu-devel
[05:53] <tkup> has anyone wrote code to deal with slowness of programs when coming back from suspend modes?
[05:54] <psusi> what do you mean?
[05:57] <tkup> well, when I turn on my laptop from hibernate mode, programs take a while to launch (reponse/interactivity). have you noticed anything?
[05:57] <bob2> everything is in swap
[05:58] <tkup> bob2, that's right. it's all on disk
[05:58] <psusi> that's because when you suspend, the filesystem cache is emptied... so everything you start up when you resume has to be read from disk fresh, just like after a clean boot
[05:58] <bob2> if you really care, swsusp2 restores it
=== psusi is still trying to figure out why suspend/hibernating with the acpi scripts borks his system, but echoing to /sys/power/state doesn't
=== uniq [n=frode@213.184.199.55]  has joined #ubuntu-devel
[05:59] <tkup> psusi, my T30 still freezes/locks every once in a while. unfortunately, the ubuntu bug hasn't been resolved
[06:01] <psusi> tkup, when I suspend/hibernate with the scripts, when the system comes back up, the disk driver complains about a register not being in the state it wants, and errors on the first IO, then usually seems to reset and recover
[06:01] <psusi> though the first sector that the IO error happens in, reiserfs seems to simply accept as unreadable and fail all IO to files that it needs that sector to find
[06:01] <psusi> rather than simply retry it... very annoying
[06:01] <psusi> but if I just echo mem or disk to /sys/power/state, it's fine
[06:01] <psusi> very odd
[06:01] <tkup> I guess I was talking about another problem, not related to yours...
[06:02] <Burgundavia> psusi, the best person to talk to about suspend/hibernate issues is mjg59 on #ubuntu-laptop
[06:02] <psusi> hrm... interesting
[06:02] <tkup> anyway, I wrote this program that makes your program as interactive as if you haven't really suspended/hibernated your laptop
[06:02] <tkup> you can checkit out at http://freshmeat.net/projects/shra
[06:02] <tkup> I guess I'll post it on ubuntu-laptop as well.
[06:03] <psusi> tkup, you probably would be better off with swsusp2
[06:04] <psusi> it saves/reloads more data so the system is more responsive after resume... though it takes longer to actually suspend/resume of course
[06:04] <tkup> psusi, never heard about swsup2..I'll read about it now
[06:04] <psusi> ther'es a howto posted on the ubuntu forums
=== blueyed_ [n=daniel@i5387D522.versanet.de]  has joined #ubuntu-devel
[06:13] <tkup> psusi, I just read about swsusp2 and it seems like it doesn't solve the problem I talked about earlier.
[06:14] <tkup> as far as I read, it only compresses the ram image to disk but it fails to solve the interactivity problem
[06:19] <psusi> tkup, it also allows you to save more data to disk instead of throwing it out
[06:19] <psusi> which increases the responsiveness after resuming
=== psusi wonders WTF this undocumented /usr/sbin/PowerManager is and how it is messing with the acpi scripts
[06:25] <tkup> psusi, does swsusp really throw data away on suspend. I thought that it only does that when disk_space < ram_image_size
[06:27] <psusi> tkup, as far as I could tell, swsusp allways throws out as much as it can... swsusp2 uses ram_image_size and other settings to decide how much it should keep or throw out
=== spstarr_home [n=sh0n@CPEdeadbeef0000-CM000039d4cc6a.cpe.net.cable.rogers.com]  has joined #ubuntu-devel
=== stub [i=stub@sweep.bur.st]  has joined #ubuntu-devel
=== daniels [n=daniels@amnesiac.heapspace.net]  has left #ubuntu-devel [] 
=== LeeJunFan [n=junfan@s64-186-37-120.skycon.net]  has joined #ubuntu-devel
=== hunger [n=hunger@p54A60855.dip0.t-ipconnect.de]  has joined #ubuntu-devel
=== viviersf [n=cain@rrba-146-120-32.telkomadsl.co.za]  has joined #ubuntu-devel
=== highvoltage [n=Jono@196.36.161.235]  has joined #ubuntu-devel
=== Aegir [n=richard@d220-238-142-16.dsl.vic.optusnet.com.au]  has joined #ubuntu-devel
=== JaneW [n=JaneW@wbs-146-178-134.telkomadsl.co.za]  has joined #ubuntu-devel
=== jane_ [n=JaneW@wbs-146-178-134.telkomadsl.co.za]  has joined #ubuntu-devel
=== zoe [n=zoe@gnulinux.good-day.net]  has joined #ubuntu-devel
=== lamont [n=lamont@207.111.195.77]  has joined #ubuntu-devel
[07:35] <lamont>   ubuntu-desktop: Depends: rss-glx but it is not going to be installed
[07:35] <lamont> ubuntu-live is _SO_ close
=== pitti [n=pitti@195.227.105.180]  has joined #ubuntu-devel
=== jane_ [n=JaneW@wbs-146-178-134.telkomadsl.co.za]  has left #ubuntu-devel ["Bye"] 
=== stub [i=stub@sweep.bur.st]  has joined #ubuntu-devel
=== herzi [n=herzi@d092190.adsl.hansenet.de]  has joined #ubuntu-devel
=== robitaille [n=robitail@ubuntu/member/robitaille]  has joined #ubuntu-devel
=== marilize [n=marilize@196.36.161.235]  has joined #ubuntu-devel
[07:58] <highvoltage> hi marilize. got any breezy cd's?
=== lbm [n=lbm@cpe.atm4-0-1301006.0x50a0824e.vgnxx6.customer.tele.dk]  has joined #ubuntu-devel
[08:02] <marilize> highvoltage: ? you want to order?
[08:03] <highvoltage> marilize: i'd like to borrow some of your copies, i work at 12 plein :)
=== Aegir` [n=richard@d58-104-23-98.dsl.vic.optusnet.com.au]  has joined #ubuntu-devel
[08:06] <marilize> highvoltage: heh, i'm just waiting for a load to be released by customs... should be here about tomorrow or wednesday
=== highvolt1ge [n=Jono@196.36.161.235]  has joined #ubuntu-devel
=== `anthony [n=anthony@ekorp-203-63-137-225.eoff.ekorp.com]  has joined #ubuntu-devel
[08:10] <highvolt1ge> sorry, battery ran out ther.
=== Valandil [n=chrys@dslb-084-056-084-129.pools.arcor-ip.net]  has joined #ubuntu-devel
=== Diablo-D3 [i=diablod3@pool-71-241-214-94.port.east.verizon.net]  has joined #ubuntu-devel
[08:17] <Diablo-D3> yargh
[08:18] <Diablo-D3> yesterday I asked about gimp printing
[08:18] <Diablo-D3> and I forgot the answer
[08:18] <Diablo-D3> which package is screwing up printing in gimp on dapper?
=== fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk]  has joined #ubuntu-devel
=== Seveas [n=seveas@ubuntu/member/seveas]  has joined #ubuntu-devel
[08:22] <viviersf> Kamion : ping
=== pitti_ [n=pitti@195.227.105.180]  has joined #ubuntu-devel
=== neuralis [n=ike@hagen.kdb.hr]  has joined #ubuntu-devel
=== carstenh [n=carstenh@mkfw.fh-trier.de]  has joined #ubuntu-devel
[09:12] <mdke> doko, you deleted the page ItalianRedirect on the wiki. 100 other pages redirect directly to it. Please don't do that! if deleting pages on the wiki, please ensure they are not linked to by any page by doing a full search on their name (click the page title) before you delete.
[09:21] <sivang> Good morning
=== sedak [n=fred@home.nenya.info]  has joined #ubuntu-devel
=== marilize [n=marilize@196.36.161.235]  has joined #ubuntu-devel
=== `anthony [n=anthony@220-253-1-71.VIC.netspace.net.au]  has joined #ubuntu-devel
[09:33] <Diablo-D3> is anyone having problems with kdesktop atm?
[09:36] <viviersf> Chmj : ping 
=== mdke_ [n=matt@81-178-237-3.dsl.pipex.com]  has joined #ubuntu-devel
=== pitti [n=pitti@195.227.105.180]  has joined #ubuntu-devel
[09:39] <viviersf> pitti, you have an idea where i can get the list of modules loaded by the debian installer ?
[09:39] <viviersf> *kernel modules
[09:40] <pitti> viviersf: you might change to vc2 and use 'lsmod'
[09:41] <viviersf> bleh
[09:41] <Diablo-D3> hrm
=== Simira [n=rpGirl@214.84-48-74.nextgentel.com]  has joined #ubuntu-devel
[09:41] <Diablo-D3> you know what would be a cool feature?
[09:42] <Diablo-D3> being able to tab complete apt-get install package=
[09:42] <viviersf> pitti, i dont mind the modules loaded by hotplug 
[09:42] <viviersf> cos the deb installer loads stuff like ide_generic etc
[09:43] <viviersf> im working on booting the impi cd
[09:43] <viviersf> :/
[09:43] <pitti> viviersf: hm, can you please ask Kamion about this?
[09:43] <viviersf> he is never here ;/
[09:43] <viviersf> but its cool
[09:44] <sivang> pitti: morning :)
[09:44] <neuralis> Diablo-D3, your shell can likely do that. zsh certainly can.
[09:44] <pitti> Hi sivang 
[09:44] <Diablo-D3> neuralis: it can, sure, it just doesnt. ;)
[09:45] <Diablo-D3> neuralis: I can tab complete the package name, but not the version
[09:45] <neuralis> Diablo-D3, there's something for you to hack on ;)
[09:46] <Diablo-D3> neuralis: no
=== Diablo-D3 is not taking on any more projects atm
=== vuntz_ [n=vuntz@volin.imag.fr]  has joined #ubuntu-devel
[09:49] <Simira> marilize: Shipit wants me to pay taxes for the Breezy-cd's :(
[09:49] <Diablo-D3> Simira: heh?
[09:49] <Diablo-D3> Simira: what country you in?
[09:50] <Simira> uhm, not Shipit... the Norwegian customs, of course...
[09:50] <Diablo-D3> theres a letter for that
[09:50] <marilize> simira: not us, customs, you can send them the customs letter on the website
[09:50] <Diablo-D3> yeah, what marilize said
[09:50] <Diablo-D3> I wish countries would quit doing that
[09:50] <Diablo-D3> they're only making themselves look stupid.
[09:51] <Diablo-D3> anyhow, kdesktop pisses me off
[09:51] <Diablo-D3> its crashing somewhere in a function in lib from libarts1c2
[09:52] <Diablo-D3> downgrading libarts1c2 to the one in breezy doesnt fix it
=== wjb [n=warren@c220-237-178-175.lowrp1.vic.optusnet.com.au]  has joined #ubuntu-devel
[10:02] <Kamion> viviersf: hi?
[10:03] <viviersf> ah you here
[10:03] <Kamion> viviersf: of course I wasn't here the last few times you asked, I was kinda busy travelling and recovering from jetlag
[10:03] <viviersf> :)
[10:03] <viviersf> its kewl
[10:03] <Kamion> viviersf: apt-get source hw-detect
=== ompaul [n=ompaul@213-202-166-21.bas503.dsl.esat.net]  has joined #ubuntu-devel
[10:03] <viviersf> kk
[10:05] <viviersf> im checking quick
[10:10] <Simira> marilize: the guy on the customs office were really bad, and claimed there's no way to get around it. I spoke to another guy on the post office's outland section though, and he was nice and told me to bring the letter so they could register an exception case. :)
=== freeflying [n=freeflyi@61.190.65.38]  has joined #ubuntu-devel
[10:15] <marilize> simira: yes, this is a problem for us, the best i can do is to email you a personalized letter, but unfortunately after that, not much we can do
=== seb128 [n=seb128@ANancy-151-1-29-104.w83-194.abo.wanadoo.fr]  has joined #ubuntu-devel
[10:17] <Simira> marilize: I'll give you feedback on it tomorrow, after fetching the cd's (hopefully). I'm also going to check out further possibilities to avoid those taxes-
[10:19] <marilize> simira: yes, let me know, thanx
=== mvo [n=egon@ip181.135.1511I-CUD12K-01.ish.de]  has joined #ubuntu-devel
=== Mithrandir looks at the init script for fetchmail and blinks.  Heavily.
[10:22] <Lathiat> Mithrandir: ??
[10:22] <Mithrandir> if ! id $USER >/dev/null 2>&1; then
[10:22] <Mithrandir> 	if [ "$USER" = "fetchmail" ] ; then
[10:22] <Mithrandir> 		adduser --system --ingroup nogroup --home [...] 
[10:22] <Mithrandir> adduser.  in an init script.
[10:22] <Treenaks> OMGWTF?
=== Treenaks dies
[10:23] <neuralis> Treenaks, ping
[10:23] <mvo> infinity: can you please kick the gksu build?
[10:23] <Treenaks> neuralis: ?
[10:23] <Lathiat> heh
[10:23] <Mithrandir> neuralis: pinging somebody who have said something less than a minute ago is kinda useless. :-P
[10:23] <pitti> mvo: infinity is not here until tomorrowish
[10:23] <pitti> mvo: I can kick it for you if you want
[10:24] <neuralis> Mithrandir, gives them the ability to say "can't talk, busy", though.
[10:24] <mvo> pitti: that would be great, please to it
[10:24] <neuralis> Treenaks, i'm writing an article on ubz for a local it professionals' magazine, getting us some media love. is there any chance you'd be willing to relicence some of your photos as attribution-SA without the NC clause?
[10:25] <neuralis> my camera, as it were, died shortly after i got to montreal.
[10:25] <Treenaks> neuralis: pm :)
[10:25] <Simira> Mithrandir: aren't you in interviews right now?
=== zakame [n=Josh@ubuntu/member/zakame]  has joined #ubuntu-devel
[10:26] <Mithrandir> Simira: I thought it was at 1000, but it's at 1100 instead.
[10:27] <pitti> mvo: hmm, sorry, no
[10:27] <Mithrandir> Simira: Amund and I've made some questions and stuff, though, so good I was a bit early in.
[10:27] <pitti> mvo: that has to wait for lamont, I'm afraid
[10:28] <Simira> Mithrandir: are you going to ask them about shoe sizes?
[10:28] <Mithrandir> Simira: no, that's just when interviewing people for the student society.
[10:30] <mvo> pitti: ok, thanks 
[10:31] <sivang> Mithrandir: what are you interviewing people for? :)
=== zyga [n=zyga@2-mi2-1.acn.waw.pl]  has joined #ubuntu-devel
[10:35] <mvo> lamont-away: could you please kick the gksu build?
=== jkbys [n=jkbys@gnulinux.good-day.net]  has joined #ubuntu-devel
[10:37] <zyga> morning
[10:38] <zyga> mvo: how is .deb click-to-install going?
[10:38] <mvo> zyga: good, I'm waiting for gksu to be build before I can upload a first version to universe
[10:39] <zyga> mvo: is it python based?
[10:39] <mvo> zyga: yes, python-{gtk,apt}
[10:39] <zyga> :-)
[10:40] <zyga> python is a nice tool indeed :>
[10:41] <Mithrandir> sivang: just helping out a bit at hardware.no, we're looking for a programmer.
=== freeflying [n=freeflyi@61.190.65.38]  has joined #ubuntu-devel
[10:46] <seb128> elmo: hi.gazpacho aalib pyorbit pxlib easytag (why is this one needed, that's -build2 version?) syncs please
[10:48] <pitti> Kamion: can you do syncs until elmo is back?
[10:48] <Kamion> pitti: theoretically yes, but there's some weirdness with queue/launchpad/ that I don't entirely know how to drive
[10:48] <seb128> lamont-away: could you give a retry to build libwpd ?
[10:48] <Kamion> pitti: I expect elmo to be back RSN anyway
[10:48] <pitti> Kamion: ok, thanks
=== _native_ [n=alpha@cpe-66-87-4-181.ut.sprintbbd.net]  has joined #ubuntu-devel
=== carlos [n=carlos@243.Red-83-47-24.staticIP.rima-tde.net]  has joined #ubuntu-devel
=== _native_ [n=alpha@cpe-66-87-4-181.ut.sprintbbd.net]  has left #ubuntu-devel [""An] 
[10:53] <zyga> carlos: hi
[10:53] <zyga> carlos: when is the next language pack sheduled?
[10:53] <pitti> zyga, carlos: hi
[10:53] <zyga> hey pitti :)
=== Jimb0b [n=jcape@c-67-175-222-235.hsd1.il.comcast.net]  has joined #ubuntu-devel
[10:56] <carlos> zyga, soon, but I don't know it exactly
=== martink [n=martin@p54B3A642.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[10:57] <zyga> carlos: will it include 'X-Ubuntu-Gettex-Domian' ?
[10:57] <seb128> hey carlos
[10:58] <seb128> carlos: are you going to clean all these xxx-deprecated po files this week? :)
[10:58] <carlos> zyga, I don't think so
[10:58] <carlos> that's a dapper feature
[10:59] <zyga> carlos: are you going to release the scripts that put the domain name?
[10:59] <zyga> I'd like to test this on breezy, dapper scared me untill release
=== freeflying [n=freeflyi@61.190.65.38]  has joined #ubuntu-devel
[11:00] <viviersf> Kamion, how do i run just hw-detect from the cd ?
[11:00] <viviersf> not using the debian installer
[11:00] <Kamion> viviersf: you don't unless you have the rest of the d-i infrastructure available, sorry
[11:00] <Kamion> hw-detect is a part of d-i; it's not designed for external use
[11:00] <viviersf> the d-i installer is present
[11:01] <viviersf> i just dont use it
[11:01] <Kamion> that's so horrible
[11:01] <viviersf> :/
[11:01] <viviersf> well the d-i takes long
[11:01] <Kamion> well, you could try running it with DEBIAN_FRONTEND=none
[11:02] <Kamion> (in the environment)
[11:02] <viviersf> kk lemme check
[11:02] <Kamion> I can't guarantee that won't break badly though
[11:02] <Kamion> you probably need to have loaded debconf templates first (see rootskel)
[11:02] <Diablo-D3> hey guys
[11:02] <Diablo-D3> we /are/ getting rid of bugzilla, right?
[11:02] <Kamion> Diablo-D3: yes
[11:02] <Diablo-D3> good.
=== koke [n=koke@ubuntu/member/koke]  has joined #ubuntu-devel
[11:03] <viviersf> Kamion, could you explain how the hw-detect scanning works ?
[11:03] <Diablo-D3> blah, has no one filed a bug on kdelibs before?
[11:03] <viviersf> or it just to much hassle ?
=== dholbach [n=daniel@ubuntu/member/dholbach]  has joined #ubuntu-devel
[11:03] <Kamion> viviersf: which scanning?
[11:04] <dholbach> U
[11:04] <dholbach> hellas
[11:04] <viviersf> ok udev / hotplug hw detection works fine
[11:04] <viviersf> then there loads modules such as ide_generic and ide_cd etc
[11:04] <viviersf> though the d-i
[11:04] <carlos> zyga, it will be an intltool patch
[11:05] <viviersf> and i just want to find out how the d-i knows those drivers need to be installed
[11:05] <carlos> zyga, so you will have it available, yes
[11:05] <Kamion> honestly, it's going to be quicker for you to read through the hw-detect shell script - it's really just a load of manual actions
[11:05] <mvo> elmo: please sync gmp from debian
[11:05] <viviersf> kk Kamion 
[11:05] <Kamion> ide-generic and ide-cd are just always loaded
[11:05] <Kamion> (if available)
[11:05] <viviersf> yeah
[11:06] <Kamion> ideally all that stuff would either be removed or move to udev
[11:06] <viviersf> and some scsi stuff 
[11:06] <Kamion> the SCSI stuff is conditional; search for the module names
[11:06] <Diablo-D3> https://launchpad.net/distros/ubuntu/+source/kdelibs/+bug/4435
=== freeflying [n=freeflyi@61.190.65.38]  has joined #ubuntu-devel
=== Robot101 [i=robot101@light.bluelinux.co.uk]  has joined #ubuntu-devel
=== HiddenWolf [n=HiddenWo@136.78.dynamic.phpg.net]  has joined #ubuntu-devel
=== olemke [n=olemke@iup.physik.uni-bremen.de]  has joined #ubuntu-devel
=== zakame [n=Josh@ubuntu/member/zakame]  has left #ubuntu-devel [] 
=== Xoff is now known as Xof
=== WaterSevenUb [n=WaterSev@azevedo.astro.up.pt]  has joined #ubuntu-devel
[11:33] <chmj> elmo: iptraf sync please, ubuntu override ok 
=== gilligan_ [i=gilligan@p549A9B2E.dip0.t-ipconnect.de]  has joined #ubuntu-devel
=== pitti [n=pitti@195.227.105.180]  has joined #ubuntu-devel
[11:41] <carlos> seb128, no, this week will still be there, but will try to have the patch ready for next production update next Tuesday (next week)
[11:42] <seb128> k, thanks
=== Chipzz [i=chipzz@noa.ulyssis.student.kuleuven.be]  has joined #ubuntu-devel
=== camilotelles [n=Camilo@20132194128.user.veloxzone.com.br]  has joined #ubuntu-devel
=== thesaltydog [n=fabio@host108-146.pool8253.interbusiness.it]  has joined #ubuntu-devel
=== womble [n=mpalmer@eth359.nsw.adsl.internode.on.net]  has joined #ubuntu-devel
=== seb128 [n=seb128@ANancy-151-1-29-104.w83-194.abo.wanadoo.fr]  has joined #ubuntu-devel
[12:09] <chmj> elmo: bluez-hcidump sync please, ubuntu override ok 
=== marcin [n=user@www.e-dev.tele2.pl]  has joined #ubuntu-devel
=== marilize [n=marilize@196.36.161.235]  has joined #ubuntu-devel
=== pitti_ [n=pitti@195.227.105.180]  has joined #ubuntu-devel
=== jinty [n=jinty@205.134.224.215]  has joined #ubuntu-devel
=== hunger_ [n=hunger@p54A640BD.dip0.t-ipconnect.de]  has joined #ubuntu-devel
=== JaneW [n=JaneW@wbs-146-180-209.telkomadsl.co.za]  has joined #ubuntu-devel
=== jane_ [n=JaneW@wbs-146-180-209.telkomadsl.co.za]  has joined #ubuntu-devel
=== enrico [n=enrico@debian/developer/enrico]  has joined #ubuntu-devel
=== zul [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-devel
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-devel
=== dredg [n=nsherida@80.169.137.162]  has joined #ubuntu-devel
=== codepoet [n=codepoet@cpe-66-68-46-68.austin.res.rr.com]  has joined #ubuntu-devel
=== gbon121 [n=chatzill@151.5.148.94]  has joined #ubuntu-devel
=== tvo [n=tobi@5354EA9B.cable.casema.nl]  has joined #ubuntu-devel
=== chmj_ [n=chmj@wbs-146-171-71.telkomadsl.co.za]  has joined #ubuntu-devel
[01:00] <Mithrandir> Kamion: what's the reason for a lot of non-latin1 locales as being listed as "type 1" in localechooser?  (type 1 is "ok to use in latin1-only environment")
[01:03] <Diablo-D3> ahh here comes the fun
[01:03] <Diablo-D3> https://launchpad.net/distros/ubuntu/+source/kdebase/+bug/4439
[01:04] <Kamion> Mithrandir: haven't looked at that much yet, you'd probably have to ask bubulle
[01:04] <Mithrandir> Kamion: 'k, thanks.
=== bmonty_laptop [n=bmontgom@wsip-68-15-230-31.om.om.cox.net]  has joined #ubuntu-devel
=== ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510
[01:05] <Kamion> (topicdiff: remove dapper CD links, which are a bit broken anyway)
[01:06] <Diablo-D3> wheres daniels
[01:07] <Diablo-D3> hrm, guess he doesnt hang out in here anymore
=== slomo [n=slomo@ubuntu/member/slomo]  has joined #ubuntu-devel
[01:13] <slomo> lamont-away, infinity: please give-back gtksourceview-sharp, gtksourceview-sharp2 and seahorse
[01:13] <slomo> elmo: please sync gmime2.1, ubuntu changes can be dropped
[01:14] <tepsipakki> kamion: it seems that d-i supports preseeding lvm-config, but how to enable that? Docs aren't updated
[01:18] <Kamion> tepsipakki: I was not aware that that was supported
[01:18] <Kamion> (not sanely, anyway)
[01:18] <tepsipakki> i'm not sure it is..
[01:18] <tepsipakki> there's partman-auto-lvm
[01:19] <Kamion> that doesn't support preseeding usefully; there have been no partman recipe format extensions for LVM as far as I know
[01:19] <tepsipakki> ok
=== lucas [n=lucas@alabama.imag.fr]  has joined #ubuntu-devel
=== tvo [n=tobi@5354EA9B.cable.casema.nl]  has joined #ubuntu-devel
[01:25] <slomo> elmo: please sync libextractor from debian/unstable... ubuntu changes can be dropped
=== kbrooks [n=kbrooks@unaffiliated/kbrooks]  has joined #ubuntu-devel
=== kbrooks pokes everyone
[01:34] <kbrooks> Attention please? Is a Ubuntu developer here?
=== pitti points kbrooks to the topic
[01:35] <pitti> kbrooks: this channel is full of them
[01:35] <kbrooks> Well.
=== kbrooks thinks hard 
[01:36] <kbrooks> okay. How do I get this addition of a init script for Subversion into breezy + 1 ?
[01:36] <Kamion> file a bug
[01:36] <kbrooks> OK
[01:37] <Kamion> if it makes sense to do so, you could also file the bug in Debian and we'll pick it up
[01:38] <kbrooks> Well, I'd have to check
[01:38] <poningru> question will xorg 7.0 be in backports? or is that too much work?
[01:39] <seb128> poningru: is there any interest to start backporting such stuff? you can as well use the new distro
[01:40] <kbrooks> I want to be a Ubuntu developer. ;)
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-devel
[01:41] <dholbach> kbrooks: #ubuntu-motu would be a good start for that
[01:41] <dholbach> :)
[01:41] <dholbach> hi BenC 
[01:41] <kbrooks> K
[01:42] <kbrooks> https://launchpad.net/people/cmpfixer/+filebug # hmmm
[01:42] <codepoet> seems you guys will be reading my bug reports on the ubuntu-devel mailing list haha
=== Hirion [n=Hirion@p5487F688.dip.t-dialin.net]  has joined #ubuntu-devel
=== hunger [n=hunger@p54A62458.dip0.t-ipconnect.de]  has joined #ubuntu-devel
=== otavio [n=otavio@unaffiliated/otavio]  has joined #ubuntu-devel
[02:00] <viviersf> hmmf
[02:01] <viviersf> i just cant get ahead
=== jkbys [n=jkbys@218-251-52-236.eonet.ne.jp]  has joined #ubuntu-devel
=== pitti_ [n=pitti@195.227.105.180]  has joined #ubuntu-devel
=== sanpera [n=sanpera@wls-21-226-196-65.tls.net]  has joined #ubuntu-devel
=== sanpera is now known as sanpera|indiana
[02:06] <Kamion> pitti: could you check MainInclusionReportGlew (I left the security section blank), please? I need it either approved and promoted, or declined and rss-glx modified to match, in order to get ubuntu-desktop installable
[02:08] <pitti_> Kamion: yes, I can take a look at it
[02:09] <Kamion> thanks
=== chuck_ [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-devel
=== zul [n=chuck@ubuntu/member/zul]  has joined #ubuntu-devel
=== sbalneav [n=sbalneav@mail.legalaid.mb.ca]  has joined #ubuntu-devel
[02:12] <DevinT> anybody ever talk to Mark Shuttleworth?
=== jinty_ [n=jinty@205.134.224.215]  has joined #ubuntu-devel
[02:13] <zul> couple of times
[02:15] <HiddenWolf> DevinT, sure, he's around, but it's a busy guy.
[02:15] <mvo> Kamion: aptitude needs a "libcppunit-dev" (unit-test framework) to build in the new 0.4.0 version. I assume I need to write a main-inclusion report for it? 
=== bob2 even met him once!
=== otavio is now known as otavio[off] 
[02:17] <DevinT> isn't he worth half a billion dollars?
[02:17] <chmj> O.o
[02:17] <HiddenWolf> DevinT, just check fortune. ;)
[02:17] <dholbach> mvo: i should think so
[02:18] <\sh> DevinT: why is this important?
[02:18] <Kamion> mvo: yes
[02:18] <seb128> pitti: are you taking care of this gtkmathview main promotion or should I do it so we get abiword again?
=== zakame [n=zak@ubuntu/member/zakame]  has joined #ubuntu-devel
[02:19] <pitti> seb128: hrmpftime
[02:19] <pitti> seb128: after I finished my current thingie, I'll look at Kamion's thingie
[02:20] <pitti> seb128: if you want to speed it up, feel free to create a wiki page and do the bug research already :)
[02:20] <seb128> pitti: same for me, but every daily build page has a good list of abiword and I know than some people use it
[02:20] <seb128> pitti: k, will do
[02:21] <BenC> dholbah: hey
[02:30] <mvo> pitti: let me know if I can (further) help with cppunit and it's main inclusion
[02:41] <pitti> Kamion: glew looks fine to me; do you want to promote it right away?
[02:41] <pitti> Kamion: if so, I directly put it into 'approved and promoted' in the queue
[02:42] <Kamion> pitti: promoted, thanks
=== freeflying [n=freeflyi@61.190.65.38]  has joined #ubuntu-devel
[02:42] <pitti> Kamion: yay, transitional postgresql package waits in anastacia for demotion
[02:43] <pitti> Kamion: can you demote it right away, so that we catch new packages which b-dep on postgresql-dev?
[02:44] <Kamion> pitti: done
[02:44] <pitti> merci
[02:44] <Kamion> de rien
=== ogra2 [n=ogra2@p5089EEDB.dip.t-dialin.net]  has joined #ubuntu-devel
=== eruin [n=eruin@unaffiliated/eruin]  has joined #ubuntu-devel
[02:48] <Nafallo> BenC: how broken could the new kernel be? should it be able to boot? :-)
[02:49] <zul> hmmm...wha?
=== Nafallo just read the changelog NOTE ;-)
[02:50] <Kamion> Nafallo: the binaries won't reach the archive for a while, until new udev is available
[02:50] <Nafallo> oh :-(
[02:51] <Kamion> well, at least they won't become the default until new udev is available
[02:51] <Kamion> because you need new udev in order to boot
[02:51] <Nafallo> lol. that means the new kernel won't boot then ;-)
=== Nafallo keeps away from those sources
[02:52] <pitti> mvo: mmmmm, C++ unit testing - how could  I say 'no'? :-)
[02:53] <bob2> hahaha
=== jk [n=jochem@jkossen.nl]  has joined #Ubuntu-devel
[02:55] <HiddenWolf> Kamion, any eta on that new udev?
=== dredg [n=nsherida@80.169.137.162]  has joined #ubuntu-devel
[03:00] <mvo> pitti: heh :) thanks
=== marga [n=marga@200.115.206.87]  has joined #ubuntu-devel
[03:01] <marga> mako_: ping?
[03:01] <BenC> Nafallo: it boots for me on my laptop and p4 system
[03:02] <BenC> Nafallo: but the rt2500pci driver is broken for my p4
[03:02] <Kamion> HiddenWolf: it's nothing to do with me; no idea
[03:02] <BenC> ran fine the whole week of ubz on my laptop though (sempron with airo wireless)
[03:04] <pitti> HiddenWolf: last week Scott told me that he had it ready more or less, just waiting for new kernel
[03:05] <HiddenWolf> pitti, let the breakage begin. ;)
[03:05] <pitti> HiddenWolf: I look forward to the new hotplug system *so much*
[03:05] <Kamion> fabbione: is the sparc buildd alive at all? I'd like to fix any debian-installer issues it has?
[03:05] <Kamion> s/\?$/./
[03:05] <BenC> Kamion: new kernel boots fine without new udev, it's just old kernels wont boot fine with new udev :)
[03:06] <HiddenWolf> pitti, fast, shiny, and easy too boot? ;)
[03:06] <BenC> Hidden: basically he's ripping out all the bad parts of udev
[03:07] <BenC> err, bad parts of hotplug
[03:07] <Kamion> BenC: oh, it does? ok
[03:07] <Kamion> will it boot all the way up to a normal full-functioning Ubuntu desktop, or just boot to a shell? :)
[03:08] <BenC> boots to desktop
=== OculusAquilae [n=bastian@p548D2F23.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[03:08] <Kamion> cool
[03:08] <Kamion> well, that's much better than I thought
[03:08] <BenC> on my laptop, everything worked fine, except that my cdrom didn't get mounted automaitically
[03:09] <BenC> but then, sound and accel video didn't work on my laptop to start with, so I can't tell if there are any regressions there :)
=== hunger [n=hunger@p54A63C66.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[03:09] <BenC> but hotplug pulled in all the modules that should have been there
=== slomo [n=slomo@ubuntu/member/slomo]  has joined #ubuntu-devel
=== dilinger [i=dilinger@mouth.voxel.net]  has joined #ubuntu-devel
=== gbon121 [n=chatzill@151.5.148.94]  has joined #ubuntu-devel
[03:15] <pitti> seb128: is there already a wiki page? otherwise I do it now
[03:16] <slomo> pitti: did you already request a openssl sync? i'm currently waiting for it ;)
[03:16] <pitti> slomo: yes, I did
[03:16] <slomo> ok, so let's wait :)
[03:16] <pitti> slomo: I did the tests last week and mailed elmo
[03:17] <slomo> pitti: is a rebuild for everything depending on it needed?
[03:17] <seb128> pitti: I'm doing it
[03:17] <pitti> slomo: yes
[03:17] <seb128> pitti: I've the wiki editor open
[03:18] <pitti> slomo: infinity wanted to do this wholesale with a script
[03:20] <Nafallo> hmm, looks like I will try the new kernel anyway then :-P
[03:20] <slomo> Nafallo: ?
[03:21] <Nafallo> slomo: you should get yourself a proxy with backlog functionality ;-)
[03:21] <pitti> seb128: security and packaging of gtkmathview look fine to me
=== Amaranth [n=travis@ubuntu/member/amaranth]  has joined #ubuntu-devel
[03:22] <slomo> Nafallo: tell me :P there's a new kernel but why do you want to try it _anyway_?
[03:22] <Nafallo> slomo: there is a big NOTE in the changelog ;-)
[03:22] <seb128> pitti: https://wiki.ubuntu.com/MainInclusionReportGtkmathview
[03:22] <slomo> Nafallo: oh well... i need 2.6.15 anyway :P
[03:23] <seb128> pitti: cool
[03:23] <pitti> seb128: thanks, I process it right away
[03:23] <Nafallo> slomo: and it seems it might have booted on one system :-)
[03:23] <seb128> pitti: thank *you* :)
=== sanpera|indiana [n=sanpera@wls-21-226-196-65.tls.net]  has joined #ubuntu-devel
[03:24] <Nafallo> pitti: could you please add MainInclusionReportLogcheck to your internal queue? :-)
[03:24] <slomo> Nafallo: hm, i hope ppc works... that's the one i need ;)
[03:24] <slomo> pitti: can you please add MainInclusionReportXSP to your queue too? ;)
[03:24] <Nafallo> slomo: gl ;-)
[03:24] <desrt> pitti; word on the street (and in my inbox) is that g-p-m won't accomidate our requests.  start writing code :)
=== desrt overruns pitti's queue :)
[03:25] <Nafallo> hehe
[03:25] <pitti> Hi desrt 
[03:25] <desrt> g'morn.
[03:26] <pitti> desrt: in terms of UI or architecture?
[03:26] <desrt> architecture... i didn't even touch on UI
[03:26] <seb128> you will make dholbach cry
[03:26] <pitti> desrt: given that upstream at least moves into our direction UI-wise, it does not seem too hard to let the daemon run as a system process, or is it?
[03:27] <pitti> desrt: s/given/if/
[03:27] <desrt> daniel is already crying.  he wants his christmas.  who can blame the boy?
[03:27] <seb128> ;)
=== Seveas [n=seveas@ubuntu/member/seveas]  has joined #ubuntu-devel
[03:27] <seb128> not me!
=== dholbach takes holidays until christmas
[03:27] <desrt> pitti; i'd guess it is.
[03:27] <desrt> :)
[03:28] <desrt> pitti; we're not only modifying it to not run as a user and not depend on gnome at all and not do all of the stuff it does in the session....
[03:28] <desrt> we have to modify how it performs its actions
[03:28] <desrt> due to your hal fascism :)
=== pitti thinks that writing a shallow UI around pmi is easier
[03:28] <highvoltage> oooh. hal fascism.
[03:28] <desrt> pitti; i pretty much agree
[03:29] <desrt> pitti; and i've done some of it already
[03:29] <desrt> does ubuntu have cvs/svn/whatever or am i expected to use this baz business?
[03:29] <pitti> desrt: given that mjg59 is on TB now, you have a fair chance to overrule me in terms of hal :)
[03:29] <dholbach> desrt: bzr rather :)
[03:29] <desrt> pitti; but i don't want to.
[03:29] <mjg59> Nngh.
[03:30] <desrt> uh oh
[03:30] <mjg59> I *still* haven't heard a good argument why fucking about with pmi stuff is supposed to be better than adopting the solution that upstream is likely to go with
[03:30] <mjg59> Especially since it's significantly less functional - we need a session daemon in any case
[03:30] <mjg59> As far as I can tell, the only issue is that hal will happily trigger a suspend no matter who asks it to
[03:31] <desrt> security problems, lack of working with [kx] ubuntu, lack of working at the login screen
[03:31] <pitti> mjg59: IMHO letting a wide open daemon like hal run as root and perform all sorts of system wide actions is wrong
[03:31] <mjg59> desrt: Other than the first, these are all trivially solvable
[03:31] <pitti> mjg59: it would become the centralized point of failure/attack
[03:31] <desrt> (this might just be my perception) it doesn't work half the time
[03:31] <mjg59> If there are bugs, we fix the bugs
[03:31] <desrt> right
[03:32] <mjg59> But the basic problem here is that hal is providing functionality
[03:32] <desrt> anyway.  suggest a fix for the security issues?
[03:32] <mjg59> And hal is running as root
[03:32] <mjg59> This is a problem that's only going to grow
[03:32] <pitti> mjg59: it's not
[03:32] <desrt> pitti; upstream disagrees
[03:32] <mjg59> pitti: To which bit?
[03:32] <pitti> hal       6696  0.0  0.3  17064  3972 ?        Ss   11:38   0:00 /usr/sbin/hald
[03:32] <desrt> the hal-as-root debate is heating up
[03:33] <pitti> mjg59: hal has never run as root in Ubuntu
[03:33] <mjg59> Hal is going to end up providing functionality that requires it to run as root
[03:33] <pitti> mjg59: no
[03:33] <desrt> it does some weird shit like mounting filesystems for you now (for the pmount-impaired?)
[03:33] <mjg59> Or, at the very least, spawning helper programs that do
[03:33] <pitti> mjg59: hal already has functionality to call separate binaries as callouts
[03:33] <mjg59> There's no other way for it to provide the functionality that people want it to do
[03:33] <mjg59> pitti: Ok. Replace "hal runs as root" with "hal runs stuff as root"
[03:33] <pitti> mjg59: providing suid root helper binaries with a small codenbase and a narrow interface is fine for me
[03:33] <Diablo-D3> why is hal as root shit bad?
[03:34] <mjg59> That's not an issue
[03:34] <mjg59> Diablo-D3: Because it's a large code base
[03:34] <Diablo-D3> ahh.
[03:34] <mjg59> (So is X, but still)
[03:34] <desrt> Diablo-D3; and because it has an awful lot of bugs in it
[03:34] <pitti> Diablo-D3: because it had a hell of a lot of buffer overflows in the past
[03:34] <Diablo-D3> so why not, say, give it a kernel module to do the fun stuff?
[03:34] <pitti> Diablo-D3: and the world can communicate to it
[03:34] <mjg59> The fundamental issue is that hal needs some form of authentication
[03:34] <pitti> mjg59: I think auth can be provided through dbus
[03:34] <Diablo-D3> authentication =/
[03:35] <pitti> mjg59: at least as long as we can define permissions in terms of users/groups
[03:35] <desrt> mjg59; no.  there really are two issues
[03:35] <mjg59> Arbitrary applications run by arbitrary users should not be able to request that hal suspend the system, or eject my CD, or whatever
=== pitti agrees
[03:35] <desrt> mjg59; and one of them is that the code in hal is -not- trustworthy yet
[03:35] <desrt> mjg59; the other is the auth issue
[03:35] <mjg59> Users at the console should be able to do all of these things
[03:35] <desrt> right.  we need a "am currently in control of the console" auth system
[03:36] <mjg59> Which is a basically solvable problem
[03:36] <desrt> and it needs to deal with userswitching
[03:36] <mjg59> Now, it's a solvable problem that may need some kernel support...
[03:37] <desrt> surely there's some ioctl on /dev/tty or something that can tell you what the current console is?
[03:37] <pitti> (like removing CAP_SYS_PTRACE from users, and similar stuff)
[03:37] <desrt> then check the system log
[03:37] <desrt> pitti; ??
[03:37] <mjg59> desrt: Yeah, utmp is supposed to be trustworthy
[03:38] <desrt> desrt    :0       -                16Oct05 ?xdm?  29:08m 19.59s x-session-manag
[03:38] <pitti> desrt: when processes can ptrace other processes, or inject into their ptys, telling apart console from remote logins does not make much sense
[03:38] <desrt> it doesn't say "tty7" >:|
[03:38] <mjg59> desrt: No, but that line is written by gdm
[03:38] <mjg59> We can fix that
[03:38] <desrt> pitti; users can only trace their own processes though
[03:38] <pitti> desrt: right
[03:39] <desrt> pitti; which means that in order to trick us they'd need to be in control of the console anyway
[03:39] <mjg59> desrt: Anyway, yeah - you can check what the foreground console is
[03:39] <pitti> desrt: I'm not talking about telling apart different uids, but telling apart processes which "own" a console, and processes which not
[03:39] <mjg59> See fgconsole
[03:39] <desrt> mjg59; ah.  nice.
[03:39] <desrt> Couldnt get a file descriptor referring to the console
[03:39] <desrt> pfah
[03:39] <desrt> need root?
[03:39] <mjg59> desrt: Needs root
[03:39] <desrt> i guess everything does these days....
[03:39] <mjg59> If you're in X, you don't own the tty - root does
[03:39] <mjg59> Works as a user at the console
[03:39] <desrt> 7!
[03:39] <Diablo-D3> I hate how X works
=== _jason [n=jason@dhcp0534.hrn.resnet.group.upenn.edu]  has joined #ubuntu-devel
[03:39] <desrt> ya.  X is -vile-
[03:39] <Diablo-D3> it needs to get rid of the fucking 2D driver bullshit
[03:40] <Diablo-D3> that shit belongs in the kernel
[03:40] <desrt> we need a single X server with multi-user support
[03:40] <mjg59> Diablo-D3: Why?
[03:40] <Diablo-D3> mjg59: because framebuffers belong in the kernel.
[03:40] <mjg59> The only thing that needs to be in the kernel is resource allocation and locking
[03:40] <mjg59> The rest can trivially be done in userspace
[03:40] <desrt> Diablo-D3; what you're discussing has some seriously negative performance implications
[03:40] <Diablo-D3> desrt: not true.
[03:40] <mjg59> And is, in fact, the model that X is moving towards
[03:41] <desrt> Diablo-D3; a syscall for every single primative graphics operation?
[03:41] <Diablo-D3> desrt: I didn't say that.
[03:41] <desrt> Diablo-D3; don't kid yourself into thinking that 2d videocards are framebuffers
[03:41] <Diablo-D3> desrt: I didn't say that either
[03:41] <desrt> ...
=== marga [n=marga@200.115.206.87]  has left #ubuntu-devel ["Terminando] 
[03:41] <Diablo-D3> desrt: thats like saying I need a syscall to upload every triangle in DRI.
[03:41] <desrt> i'm confused how you'd expect this to work
[03:41] <mjg59> Diablo-D3: The only way you get acceleration out of the framebuffer drivers is to do ioctls
[03:42] <Diablo-D3> what we need is sort of a DRI for 2D =/
[03:42] <mjg59> DRI works fine for 2D
[03:42] <Diablo-D3> mjg59: not in the way I was thinking.
[03:42] <mjg59> There's just no 2D drivers that use it
=== jsgotangco [n=jsg@ubuntu/member/jsgotangco]  has joined #ubuntu-devel
[03:42] <Diablo-D3> I mean, sure, exposing the gpu to do 2D work is quite fun
[03:42] <mjg59> pitti: Ok. So, basically, for certain operations hal should check that the user who requested that operation is at the console
[03:42] <desrt> mjg59; feel like convincing dbus upstream to integrate a 'console user' policy?
[03:42] <Diablo-D3> but thats not what I was thinking
[03:43] <pitti> mjg59: I'm not yet convinced that this can be done robustly
[03:43] <desrt> mjg59; hal defers the authentication problem entirely to dbus
[03:43] <mjg59> pitti: Why not?
[03:43] <pitti> mjg59: but for the sake of argument, let's say hal can check that
[03:43] <mjg59> desrt: Sure
[03:44] <pitti> mjg59: as I said, the current kernel/userspace allows processes to ptrace or tty-control other processes of the same uid
[03:44] <mjg59> pitti: Why's that a problem? If the user has console access, then...
[03:44] <Diablo-D3> why would you need an ioctl, though?
[03:44] <pitti> mjg59: so grouping an user's processes into 'has console', and 'is remote' doesn't work ATM
[03:44] <desrt> pitti; no... we don't group processes
[03:45] <desrt> pitti; we do the entire user
[03:45] <Diablo-D3> why can't you let the userspace encode instructions or whatever (like how the userland half of dri drivers do it)
[03:45] <pitti> mjg59: I'd rather assign a group membership to users who should be able to control power state
[03:45] <desrt> pitti; if desrt is logged in at the console than any of my processes have access
[03:45] <Diablo-D3> speaking of which
[03:45] <desrt> *then
[03:45] <Diablo-D3> X needs to quit 'owning' the dri stuff
[03:45] <desrt> pitti; that's an awful idea
[03:45] <desrt> sorry :)
[03:45] <mjg59> pitti: All users at the console should be allowed to control power state in many cases
[03:45] <Diablo-D3> I mean, in the way that the dri userland stuff 'comes with X'
[03:45] <pitti> mjg59: I agree
[03:45] <desrt> oh wait.  you mean globally assign group access
[03:45] <pitti> mjg59: since they have hardware access anyway
[03:45] <jsgotangco> hello
[03:46] <Diablo-D3> you know what
[03:46] <Diablo-D3> I give up
[03:46] <Diablo-D3> X sucks
[03:46] <Diablo-D3> hardware sucks
[03:46] <Diablo-D3> computers suck.
[03:46] <pitti> mjg59: do you know how sane RedHat's pam_console is?
[03:46] <mjg59> If a user is logged in at the console and also logged in remotely, why does it matter that the remote session can trigger events that the user could do anyway?
[03:46] <desrt> Diablo-D3; please
[03:46] <mjg59> pitti: It does what it tries to do fine, but it's not ideal
=== Diablo-D3 is just in a bad fucking mood right now
[03:46] <mjg59> pitti: Users can open devices when logged in and keep them open after they've logged out - then they can still access them remotely at some later point
[03:47] <pitti> mjg59: anyway, let's assume we have a way to define power ctl privileges for users
[03:47] <pitti> mjg59: right, that's what I meant
[03:47] <desrt> pitti; also... if you give a group to a user once, they have it forever
[03:47] <pitti> mjg59: this priv should be assigned to an uid
[03:47] <desrt> pitti; even across reboot
[03:47] <mjg59> Whereas checking whether a user is actually at a console is robust
[03:47] <pitti> desrt: sure, sgid binaries
=== hunger [n=hunger@p54A617A4.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[03:48] <pitti> mjg59: by checking if any process of that user has any /dev/tty open?
[03:48] <desrt> mjg59; it's worth noting that windows and mac os do not let unprivileged users modify the power settings
[03:48] <mjg59> pitti: By checking whether gdm has recorded that that user is on the foreground tty
[03:48] <Diablo-D3> mjg59: but that requires a dm.
[03:48] <Diablo-D3> not all users use dms.
[03:48] <mjg59> Diablo-D3: Sucks to be them.
[03:48] <pitti> mjg59: k, that sounds reasonable for Ubuntu
[03:48] <Diablo-D3> mjg59: how so?
[03:49] <hunger> What is a foreground tty?
[03:49] <desrt> mjg59; but in any case, adding a "can change power settings" group is a trivially additional layer on top of what we're discussing
[03:49] <mjg59> hunger: The tty that is displayed the system console
[03:49] <Diablo-D3> mjg59: what happens if the dm shits out? then you have no X.
[03:49] <mjg59> "on the"
[03:49] <pitti> hunger: just skip the foreground, it does not make sense anyway
[03:49] <mjg59> Diablo-D3: Yes. So?
[03:49] <Diablo-D3> mjg59: so I shouldnt require a dm to use X.
[03:49] <hunger> mjg59: The system console? Which one is that?
[03:49] <pitti> hunger: for me, asking gdm whether user X is logged in seems sane
[03:49] <Diablo-D3> dms are apart of the desktop environment, X doesnt require a desktop environment to run.
[03:49] <mjg59> hunger: The console that is plugged into the system.
[03:50] <hunger> mjg59: I have 4 Xsessions running at this time as 4 differnt users.
[03:50] <pitti> hunger: (although highly Ubuntu specific)
[03:50] <mjg59> hunger: There's a fringe case of multi-head machines, but you don't want power management in that case
[03:50] <desrt> Diablo-D3; please write a spec about how to fix it for dapper
[03:50] <Diablo-D3> desrt: easy
[03:50] <Diablo-D3> get rid of X
[03:50] <hunger> pitti: I do not even use gdm!
[03:50] <desrt> so go write a spec
[03:50] <desrt> please.  do us the favour
[03:50] <pitti> hunger: as I said, it would be highly specific, and maybe there is a more general approach
=== Kinnison ruffles desrt 
=== desrt is early-morning-ruffled
[03:50] <mjg59> pitti: Ideally, all DMs would record the tty in utmp
[03:51] <hunger> mjg59: This is a simple laptop, not multiheaded at all and definitly in need of PM.
[03:51] <desrt> mjg59; i think we might have other ways to find out
[03:51] <pitti> hunger: however, I'm the side that evaluates the security, not usability :)
[03:51] <Kinnison> desrt: it was a mid-afternoon ruffling, you have to wait 5 hours for it to cross the ocean
[03:51] <mjg59> hunger: So the foreground tty is the one that's currently being displayed
[03:51] <desrt> i see.
[03:51] <pitti> mjg59: right
=== Diablo-D3 thinks this conversation sucks.
[03:51] <hunger> mjg59: OK... and that may change PM settings?
[03:51] <mjg59> hunger: They may all change PM settings, but only the active user will be able to trigger them
[03:51] <pitti> mjg59: why should it matter whether a login session is displayed or not?
[03:52] <desrt> mjg59; look in the lastlog
[03:52] <mjg59> pitti: An idle user whose session isn't displayed shouldn't be able to trigger a suspend
[03:52] <hunger> mjg59: Ah, OK. I think that sounds sane enough:-)
[03:52] <desrt> mjg59; actually forget that.  it's useless if it has wrapped since
[03:52] <pitti> mjg59: erm, no user should actually
[03:52] <mjg59> desrt: Mm?
[03:52] <mjg59> pitti: Uh.
[03:53] <pitti> mjg59: I though we talk about *configuring* the power daemon
[03:53] <mjg59> pitti: Surely the entire point of this is to provide functionality for user-triggered suspends?
[03:53] <hunger> mjg59: What happens when the lid is closed without anyone being logged in?
[03:53] <desrt> mjg59; lastlog has the info but isn't promised to still have it since it may have been rotated
[03:53] <mjg59> hunger: That's a separate issue
[03:53] <mjg59> desrt: IRC lastlog?
[03:53] <desrt> mjg59; the system wtmp
[03:53] <mjg59> desrt: Oh - surely that's pseudo-ttys?
[03:54] <mjg59> I don't see my tty in there anywhere
[03:54] <pitti> mjg59: you want any user process be able to directly poweroff the machine?
[03:54] <mjg59> Oh, probably because it's wrapped
[03:54] <desrt> you're right.  i -am- an idiot :)
[03:54] <hunger> mjg59: I do not see the problem...
[03:54] <desrt> ok.  seriously though... does gdm even know?
[03:54] <desrt> it says to the X server "start"... and X picks a console
[03:54] <desrt> then gdm connects to :0
[03:54] <hunger> mjg59: Surely an idle user won't trigger a suspend anyway since he is idle:-)
[03:55] <mjg59> pitti: A hostile program can already delete all your files
[03:55] <desrt> gdm probably has no idea that it's on tty7
[03:55] <hunger> mjg59: Why shouldn't I be allowed to suspend from remote?
[03:55] <mjg59> pitti: And it can already tell gdm to halt the system
[03:55] <desrt> hey
[03:56] <desrt> what if we used the gdm machinary to do this?
[03:56] <mjg59> pitti: See gdm-signal
[03:56] <hunger> send a Wake-on-lan, do something, suspend the box again seems a valid use case to me.
[03:56] <mjg59> Breezy already allows arbitrary user processes to suspend things
[03:56] <pitti> mjg59: My main concern is not a DoS, but more a race between several processes who concurrently want to do power operations
[03:56] <mjg59> pitti: Then we need some sort of locking
[03:56] <pitti> mjg59: in the case of multiple logins
[03:56] <desrt> mjg59; surely only if they're currently logged in through gdm?
[03:57] <mjg59> pitti: If there are multiple logins, only the one in the foreground should be able to trigger anything
[03:57] <mjg59> desrt: Yes, but that's by far the most common use case
[03:57] <desrt> mjg59; but will it restrict all other users?
[03:57] <mjg59> desrt: ?
[03:57] <desrt> do non-logged-in-under-the-current-gdm-session-users get to use gdm-signal?
[03:57] <mjg59> I'm getting confused here. Shall I just write down what I think should happen ? :)
[03:58] <hunger> Please do not focus so much on gdm... there are enough other login managers around.
[03:58] <mjg59> hunger: It's trivially applicable to other dms
[03:58] <hunger> Would be a shame if things broke for me just because I am on kubuntu;-)
[03:58] <bob2> then their users can handle adding the hooks
[03:58] <mjg59> 1) User logs in. DM records the tty of the user.
[03:58] <desrt> 1a) if it knows it
[03:58] <mjg59> 2) User a switches to user b. DM records the tty of user B.
=== hunger fails to see the reason for tty recording.
[03:59] <mjg59> 3) User a's PM settings notice that he's been idle for 15 minutes. They ask for a suspend
[03:59] <desrt> hunger; we ioctl /dev/tty to determine the 'active' VT
[03:59] <desrt> hunger; then we see who is logged in there
[03:59] <desrt> hunger; and only they are allowed to change power settings
[03:59] <mjg59> 4) User A is not on the foreground console. The request is refused.
[03:59] <hunger> You will need to do locking anyway.
[03:59] <dholbach> i'm out for a walk... be back later
[03:59] <desrt> dholbach; cheerio
[03:59] <hunger> So why the foreground console magic?
[04:00] <mjg59> 5) User B explicitly asks for a suspend
[04:00] <mjg59> 6) User B is on the foreground console. The system suspends.
[04:00] <mjg59> That's how I imagine things working. Does any part of that seem insane?
[04:00] <hunger> mjg59: Why that distinction?
[04:00] <desrt> mjg59; it's not bad
[04:00] <desrt> mjg59; certainly handles my one use case of sharing your laptop with an evil sibling with a sick sense of humour
[04:00] <mjg59> hunger: Why what distinction?
[04:01] <hunger> mjg59: I think that is only useful on a single-userish box... and there will be only one user 99% of the time anyway.
[04:01] <hunger> mjg59: user on foreground tty and user somewhere else.
[04:01] <fabbione> Kamion: sparc is building stuff... i didn't give love to the buildd the last 2 days (been sleeping all time).. but it's catching up as we speak
[04:01] <fabbione> Kamion: i was way too sick to stay out of bed
[04:01] <desrt> mjg59; and hal runs as a locked-down user and shells out to setuid helpers?
[04:01] <mjg59> hunger: Dapper should have nice switch user functionality. If it has that, and if users are able to configure PM settings for idle timeouts, it's vital that the non-active user isn't able to suspend the machine from underneath the active user
[04:01] <mjg59> desrt: Yeah
[04:01] <desrt> mjg59; it's not bad
[04:02] <mjg59> Which lets us use g-p-m as is
[04:02] <pitti> desrt: I'd really like to see this as a dbus service instead of being tightly integrated into hal
[04:02] <hunger> mjg59: non-active timers need to be global to all users I think.
[04:02] <mjg59> hunger: Why?
[04:02] <Xof> I don't know where hunger gets his 99% statistic from, but I for one am in the 1%
[04:02] <desrt> mjg59; assuming you have other ways of addressing the kde-users-left-out-in-the-cold/login-screen problems
[04:02] <mjg59> desrt: I think the sensible thing in those cases is to run g-p-m and provide some other way to configure them
[04:02] <desrt> pitti; we've talked about two things....
[04:02] <desrt> 1) what should be done
[04:02] <desrt> 2) what can reasonably be done in dapper timeframe
[04:03] <hunger> mjg59: Do you want to suspend the box while someone is working on it via ssh?
[04:03] <mjg59> Unless gconf is considered unacceptable in Kubuntu
[04:03] <mjg59> hunger: Given that the user could press the power button, that's not an issue
[04:03] <hunger> mjg59: agreed:-)
[04:03] <mjg59> Remote users should, in most cases, not be able to trigger suspends
[04:03] <desrt> hunger; we don't need a voting system :)
[04:03] <desrt> "does everyone currently logged in agree to suspend?"
[04:04] <desrt> mjg59; unless of course the remote user is the local user :)
[04:04] <mjg59> It's quite important to have the power management as a session daemon, though. User apps need to be able to veto it.
[04:04] <hunger> mjg59: Given that the ssh user could run "shutdown -h now" the distinction is rather blurry.
[04:04] <desrt> mjg59; dbusdbusdbus
[04:04] <mjg59> If I'm running totem in full screen mode, it needs to tell g-p-m not to suspend
[04:04] <desrt> hunger; only if they're root
[04:04] <mjg59> desrt: Yeah
[04:05] <mjg59> Now, g-p-m already has this functionality. We're just missing the authentication layer.
[04:05] <hunger> desrt: Right:-) So why not have a group of users alowed to suspend.
[04:05] <mjg59> hunger: Why?
[04:05] <desrt> hunger; because that's not a good dynamic policy
=== jsz [n=diego@59.Red-80-36-85.staticIP.rima-tde.net]  has joined #ubuntu-devel
[04:05] <desrt> hunger; who we want to be able to suspend changes as users log in/out of the console
[04:05] <hunger> desrt: Maybe. But it is necessary in a multiuser setup anyway.
[04:06] <desrt> hunger; we already have a good mechanism worked out
[04:06] <hunger> desrt: In my uni we routinely had people sitting on "servers". They should never be shut down.
[04:06] <desrt> oh.  this.
[04:06] <hunger> desrt: Then don't let me keep you:-)
[04:07] <desrt> right
[04:07] <hunger> desrt: Granted: They could pull the plug.
[04:07] <mjg59> Server installs should have a different default policy
[04:07] <desrt> 09:49 <desrt> mjg59; but in any case, adding a "can change power settings" group is a trivially additional layer on top of what we're discussing
[04:07] <desrt> :)
[04:08] <desrt> mjg59; he's absolutely right.  some users should be unable to do power stuff, even at the console
[04:08] <hunger> mjg59: The destinction between client and server used to be blurry in my uni... users were sitting on boxes and worked there that were happily exporting drives to the entire department.
[04:09] <desrt> mjg59; think "internet sharing" in a library, for example
[04:09] <hunger> mjg59: No money for real servers, so we used what was there:-)
[04:09] <mjg59> desrt: Ok, I think that's a good argument for checking that the user is a member of a group (and in the default install, default to adding new users to that group)
[04:09] <pitti> desrt: how do you want to keep local users away from shutting down a machine?
[04:09] <desrt> mjg59; or "print server" in a library
[04:09] <mjg59> pitti: The machine may be in a locked box
[04:09] <desrt> pitti; in my hypothetical library, we have additional physical security
[04:09] <pitti> ok
[04:10] <hunger> pitti: Think internet caffee: monitor, keyboard and mouse are accessible, the rest is locked away.
[04:10] <mjg59> But that's no problem, it's just another lookup for the policy
[04:10] <desrt> *ahem* *alt-ctrl-f1* *ctrl-alt-del*
[04:10] <desrt> what about that one, EH?
[04:10] <mjg59> desrt: (Can be disabled in inittab)
[04:10] <hunger> desrt: /etc/inittab
[04:10] <sladen> except with X is crashing and keeps respawaning that doesn't work
[04:10] <desrt> mjg59; something we want to provide a UI for? :)
[04:11] <mjg59> desrt: A general lockdown UI might be nice
=== [-Jarod-]  [n=jarod@lns-bzn-25-82-251-206-224.adsl.proxad.net]  has joined #ubuntu-devel
[04:12] <desrt> do we have sysrq-hacking support enabled?
[04:12] <desrt> or magic sysrq key or whatever they call it
[04:12] <mjg59> desrt: Can be disabled through /proc
[04:12] <desrt> oh.  that's very nice indeed
[04:14] <mjg59> So, if gconf and glib are acceptable for kubuntu, that just leaves a UI and a light patch to KDM to make the Kubuntu case work
[04:14] <pitti> desrt: I'd rather try to find the power plug
[04:14] <desrt> pitti; that's not something we can fix
[04:14] <desrt> pitti; these other things are
[04:14] <mjg59> If not, then we need a configurable settings backend (not too much pain)
[04:14] <pitti> desrt: right :)
[04:15] <desrt> pitti; and generally speaking, for a given user (like a library) solving the logistics of making the machine physically secure is one heck of a lot more intuative to them than working out how to hack the OS
=== sanpera|indiana [n=sanpera@wls-21-226-196-65.tls.net]  has joined #ubuntu-devel
[04:16] <desrt> my ubuntu email address is not working >:|
[04:16] <desrt> elmo; ping?
[04:17] <Znarl> desrt : What part is not working?
[04:17] <desrt> when i send to it i get a bounce
=== mvo wonders if Znarl has a nick-highlight on "elmo" ;)
[04:18] <mjg59> pitti: desrt: So does this sound (a) achievable, and (b) broadly sane?
[04:18] <desrt> mjg59; you have to stick your fingers into a -lot- of places
[04:19] <mjg59> desrt: But it gives us a framework that works for other situations, too
[04:19] <desrt> mjg59; something tells me you're used to that, though :)
[04:19] <desrt> mjg59; ya.  that's true.
[04:19] <mjg59> It's not PM specific
[04:19] <pitti> mjg59: TBH I'm not totally convinced about the multiple userspace daemons, but I wouldn't veto against it
[04:19] <desrt> i have one marginal use case that your system breaks... but it's really marginal
[04:20] <pitti> mjg59: if we can solve the backend with a separate dbus service instead of integrating everything into hal, it works for me
[04:20] <mjg59> pitti: I think it simplifies matters to have per-user daemons
[04:20] <desrt> say we have a physically secured laptop (like library style)
[04:20] <desrt> but at the end of the day the librarian wants to be able to close it and have it go to sleep
[04:20] <mjg59> pitti: As far as I'm concerned, something should get the dbus signal and do something appropriate. At the moment hal has code to do that, but I don't have any religious beliefs here
[04:20] <desrt> ((no distinction between user-triggered actions and system-event-triggered actions))
[04:21] <pitti> mjg59: providing a simple dbus service on top of PMI should be easy
[04:21] <mjg59> pitti: Well, that's basically what hal does right now (except for the "simple" bit)
[04:21] <mjg59> desrt: Hrm. At the moment, that could be done through the gdm menu.
=== desrt pops out for some breakfast
=== desrt pops in a moment
[04:21] <desrt> hm?
[04:21] <pitti> mjg59: however, dbus currently only authenticates against uids or group membership
[04:22] <jsgotangco> good night =)
[04:22] <mjg59> desrt: System/logout/shutdown
[04:22] <mjg59> Oh, sleep
[04:22] <mjg59> Right. Hrm.
[04:22] <desrt> mjg59; we have to assume that we're going to deal with that
[04:22] <mjg59> desrt: gtksudo wrapper in that case?
[04:22] <mjg59> pitti: Yeah, the authentication thing needs to be sorted
[04:22] <desrt> mjg59; you close your laptop and a gksudo box pops up asking for your pw?
[04:23] <mjg59> desrt: Well, pressing the sleep key
[04:23] <desrt> hmmmmmm
[04:23] <mjg59> There's obviously no way of dealing with the case where if one user closes the lid it should suspend and not for another user
[04:23] <mjg59> Unless the librarian logs out and in again
[04:23] <desrt> well -- system daemon :)
[04:23] <desrt> ya.
[04:23] <desrt> that's a bit evil.
[04:24] <Znarl> desrt : What email address is bouncing?
[04:24] <desrt> we could expand the 'system actions' at the gdm menu to ask for a u/p of an admin user
[04:24] <desrt> (right now you need root)
[04:24] <desrt> Znarl; desrt@ubuntu.com
[04:24] <pitti> mjg59: your model would not work with closing the lid when no user is logged in, though
[04:24] <mjg59> desrt: Yeah
[04:24] <mjg59> pitti: Right. In that case, gdm should be running a daemon
=== ogra [n=ogra@p5089EEDB.dip.t-dialin.net]  has joined #ubuntu-devel
[04:24] <desrt> pitti; presumably we have something up where gdm invokves its own g-p-m
[04:24] <mjg59> And then kill it during login
[04:24] <pitti> that's soo crackful
[04:24] <Diablo-D3> heh
[04:25] <desrt> pitti; absolutely
[04:25] <mjg59> There's a tiny race where the gdm one is dead before the user one starts, but, well
[04:25] <desrt> pitti; but we don't have time to do it properly
[04:25] <pitti> right *shrug*
[04:25] <desrt> as i see it
[04:25] <desrt> post-dapper we're going to want to do something better
[04:25] <desrt> -much- better
[04:25] <Znarl> desrt : Yeah, that doesn't exist.  Can you create a RT job requesting it's creation please?
[04:26] <desrt> which probably means diverging from g-p-m again anyway (unless richard suddenly does an about-face and realises that his architecture is flawed)
[04:26] <desrt> Znarl; RT?
[04:26] <pitti> but if we are going for a system daemon in dapper+1 anyway, why bother with putting effort into anothers olution?
[04:26] <mjg59> Basically, nobody is trying to solve this problem at the moment. To solve it we're going to need to create new framework, and the best way of convincing people is to show them the code
[04:26] <desrt> pitti; this is my idea
[04:26] <desrt> pitti; use what we have now.  make it better.
[04:26] <mjg59> pitti: Because it's not much effort and it uses existing code
[04:26] <Znarl> desrt : rt@admin.canonical.com
[04:27] <desrt> Znarl; thanks.
[04:27] <mjg59> The only difficult bit here is the authentication stuff, and we almost certainly want that anyway
[04:27] <mjg59> As in, we'd want that even for the system daemon case
[04:28] <mjg59> So we might as well solve that now, and then push for it to be standardised cross-distros
=== dereks- [n=dereks@66.9.7.66]  has joined #ubuntu-devel
=== dereks- [n=dereks@66.9.7.66]  has left #ubuntu-devel [] 
[04:29] <desrt> so what.. ubuntupowerdaemon?
[04:30] <ogra> wasnt acpid once though for all this ?
[04:30] <mjg59> ogra: No
[04:30] <desrt> fwiw, pbbuttons is -definitely- more than enough
[04:30] <desrt> and pbbuttons runs on non-macs :)
[04:30] <mjg59> pbbuttons is more than enough, but...
[04:32] <desrt> pbbuttons has a bit of a problem right now in that it will take power management commands from arbitrary users
[04:32] <desrt> *ahem*
[04:33] <mjg59> desrt: Yeah. We end up having to solve the same problems, and we end up doing it in a way that integrates less nicely into the desktop
[04:33] <desrt> it uses poor-man's-dbus
[04:33] <mjg59> Yeah
[04:33] <mjg59> Let's get the framework implemented, and then worry about the future after that
[04:34] <mjg59> No matter what sort of decision we make, that needs to be done
[04:34] <desrt> right
=== pepito [n=pepe@7.Red-83-38-47.dynamicIP.rima-tde.net]  has joined #ubuntu-devel
[04:34] <pepito> hello
[04:34] <desrt> i wonder if redhat would accept the patch to dbus
[04:34] <desrt> that seems like a reasonable place for it
[04:35] <mjg59> We should speak to the dbus guys, yeah
[04:35] <mjg59> They'll probably just want to go with a pam_console solution, though
[04:35] <desrt> pam_console is vile
[04:35] <desrt> i always turn it off :)
[04:35] <mjg59> Which doesn't actually solve the problem
[04:35] <pepito> Im trying to get Ubuntus source packages used at boot-up for hardware detection and activation, could anyone let me know something about? thanks
[04:36] <mjg59> pepito: We just use hotplug
=== thesaltydog [n=fabio@host108-146.pool8253.interbusiness.it]  has joined #ubuntu-devel
[04:36] <desrt> blisfulyl, not for long
[04:36] <desrt> *blissfully
[04:36] <Diablo-D3> hrm
[04:36] <Diablo-D3> hey
[04:37] <mjg59> So, who wants to raise this with the dbus guys? :)
[04:37] <desrt> not me
[04:37] <Diablo-D3> why can't we use dbus to ask the kernel whos logged into a real terminal?
[04:37] <mjg59> Diablo-D3: The kernel doesn't know
[04:37] <pepito> mjg59 Im just trying to see some source code that helps me when setting up a mouse whether is usb, ps/2 or serial
[04:37] <desrt> i filed a bug against them "your supposedly-threadsafe library isn't" ages ago and have gotten very little reply :)
[04:37] <Diablo-D3> mjg59: why can't it?
[04:37] <mjg59> Diablo-D3: How should it?
[04:38] <mjg59> The kernel doesn't care
[04:38] <desrt> Diablo-D3; even if it had a concept of "who do the processes that are using this terminal belong to?" it would see that X belongs to root
[04:38] <Diablo-D3> I dunno, maybe our tty program should communicate with dbus?
[04:39] <mjg59> Nnnnnnnnnnnnnngh.
[04:39] <desrt> out come to the cocks
[04:39] <desrt> seriously though, i should eat breakfast
[04:39] <Diablo-D3> mjg59: isn't dbus the magic way to fix everything?
[04:39] <mjg59> No
[04:39] <Diablo-D3> wow, could have fooled me.
[04:40] <pepito> so mjg59, hotplug is used to recognize mouse at boot time?
[04:41] <pepito> could you let me know packages name?, sorry I just dont use ubuntu
[04:41] <Nafallo> hotplug
[04:42] <pepito> ok thanks, Ill look for it whithin your repository
[04:42] <Robot101> mjg59: what's the dbus issue?
[04:42] <Robot101> mjg59: /me is upstream now :D
[04:43] <Mithrandir> doko: would you mind if we synced zlib from Debian?  I think the only change we'll be missing out on is "Explicitely set -march/-mtune options for 64bit i386 build."
[04:43] <pitti> Mithrandir: oh, Debian has the multiarch bits now? nice
[04:43] <mjg59> Robot101: We want dbus to be able to authenticate events based on whether or not the user sending the request is the user with a login session on the foreground console
[04:43] <Mithrandir> pitti: yes, broonie merged them.
[04:44] <Robot101> mjg59: on the system bus?
[04:44] <mjg59> Robot101: Use case: User sends request to system bus saying "Please suspend the machine". If user is not on the foreground console, this request should be declined.
[04:45] <mjg59> (extend to requests like "Please eject the CD")
[04:45] <Diablo-D3> mjg59: these permissions can be changed, right?
[04:45] <Diablo-D3> like anyone who is root should be able to do this no matter where they're logged in, remote or not
[04:45] <mjg59> Diablo-D3: Dbus policy is configurable. See /etc/dbus
[04:46] <mjg59> See /etc/dbus-1, rather
[04:46] <mjg59> Robot101: Things like pam_console don't fix it, since multiple users may have that permission but you don't want them all to be able to suspend it (see gdm's switch user functionality)
=== mpt [n=mpt@tvwna-ip-a-1.princeton.org]  has joined #ubuntu-devel
[04:47] <pepito> Ok nafallo I got it, by the way, cose Im not an expert programmer, havent worked with hotplug before, do you know about any other resource I may look at in order to detect and activate a mouse at boot-time?. I havent found any, is just for a custom linux-from-scratch live-cd
[04:47] <mjg59> pepito: mdetect is used at X configuration time
[04:47] <mjg59> But not in normal boots
[04:48] <pepito> ahm, the thing is Ive developed ncurses apps, so I need to know mouse device in order to setup gpm as well
[04:48] <mjg59> pepito: Well, that's all we use
[04:49] <pepito> ok, but what do oyu mean with "not in normal boots"?
[04:49] <hunger> pepito: Just using /dev/input/mice and hoping for the best does not suffice?
[04:49] <mjg59> mdetect is run when X is configured. In general, it is not run.
[04:49] <pepito> no, cose if its usb the mouse?
[04:50] <pepito> should be /dev/input/mouse0, and if is a laptop /dev/input/mice probably
[04:50] <Robot101> mjg59: I suspect your best bet would be to make a service on the system bus which implemented this policy for you, you could give it something like the username and it would do whatever grubbing around was necessary and tell you if they were the current user
[04:50] <hunger> pepito: PS2 mice show up in /dev/input/mice as well.
[04:50] <hunger> pepito: So do Bluetooth mice. Dunno about serial mice.
[04:51] <Xof> mjg59: does nautilus display of newly-plugged-in usb filesystems also come into your current discussion?
[04:51] <mjg59> Robot101: It would be nice if it was a generalisable mechanism
[04:51] <Robot101> mjg59: you have ~0 chance of convincing havoc to include something that hairy (mapping X displays to users, yada) in the bus daemon itself
[04:51] <mjg59> Xof: Not really
[04:51] <pepito> dont know just not an expert, Im gonna look for mdetect
[04:51] <hunger> pepito /dev/input/mice is a "merging" of all mouse devices the kernel recognizes as such.
[04:52] <Robot101> mjg59: it is a generalised mechanism... org.freedesktop.DBus.ConsoleAuthentication can be called by anyone, and you use the security policy on the system bus to ensure the name is only taken by the real deal
[04:52] <mjg59> Robot101: Hmm. So we'd end up with a service that would basically scrub stuff and then rebroadcast?
[04:52] <Robot101> mjg59: no, upon recipt of a message that you wanted to authenticate came from the current console user, you'd ask the console authenticator service to say yea or nay
[04:52] <pepito> ah, didnt know that hunger, so if I user /dev/mice, independent of what kind of mouse would be, it is supossed to work?
[04:53] <mjg59> Robot101: Ah, I see
[04:53] <mjg59> Robot101: But that involves modifying every daemon that might want this sort of policy
[04:53] <hunger> pepito: It should.
[04:53] <Robot101> mjg59: they'd have to be modified somehow anyway
[04:53] <Robot101> mjg59: there are too many variables and system specific crap to try and implement this in the bus daemon itself, especially considering it's meant to be a secure and minimal message routing implementation
[04:53] <hunger> pepito: PS2/usb/bluetooth do, dunno about serial mice.
[04:54] <desrt> Robot101; can dbus take auth modules?
[04:54] <Robot101> mjg59: remember the message daemon itself runs as an unpriveledged user, it can't poke people's environment variables and stuff
[04:54] <mjg59> Robot101: Why? If we did the rebroadcast thing, the user could just request it from one service
[04:54] <pepito> aha, thanks anyway
[04:54] <desrt> mjg59; recall also that we need root to do the ioctl on /dev/tty
[04:55] <desrt> oh man this sucks
[04:55] <mjg59> desrt: Yeah, but that could be done by a helper app
=== desrt watches us spawn 23482938 small setuid helpers
[04:55] <Robot101> mjg59: rebroadcasting is ugh,it requires allowing an app to forge messages from something
[04:55] <Robot101> mjg59: which is understandably avoided
[04:55] <Robot101> mjg59: I do think that this helper app you want is a service in its own right that you interrogate for this information
[04:56] <mjg59> Robot101: Rebroadcast was possibly the wrong term. Basically, send the message and have a security policy that only allows the daemon to receive events from that service
=== desrt watches us spawn 23482938 small system dbus services :)
[04:56] <pepito> ok, got the mdetect in source & binary form, gonna boot-up & try, thanks very much everybody!
=== otavio[off]  is now known as otavio
[04:57] <mjg59> Robot101: Buggerit. Where are you right now?
[04:57] <desrt> mjg59; i think we patch dbus
[04:57] <desrt> mjg59; your original intuition was sufficiently sane
[04:57] <Robot101> desrt: please don't smoke crack
[04:57] <desrt> mjg59; and the dbus policy framework seems easy to mold
[04:57] <Robot101> mjg59: CB2, but working
[04:57] <Robot101> mjg59: we could discuss over beer later
[04:58] <mjg59> Robot101: Already booked up this evening. Tomorrow?
[04:58] <desrt> too much OOB data :)
[04:58] <desrt> ciao.
[04:59] <Robot101> mjg59: should be fine
[04:59] <\sh> doko: Do u want me to visit an asylum? 
[04:59] <mjg59> desrt: I get higher bandwidth if I discuss this with upstream face to face :)
[05:00] <Robot101> I'm still a reasonable n00b, but I'm learning from the master of punting on complex issues... Havoc :D
[05:02] <Robot101> mjg59: I worked out how to do that finding the system bus thing, you want a BusStation on the system bus for storing a registry of a user's session bus names
[05:03] <Robot101> bonus points if you can also include a bus conductor somewhere :)
=== zul_ [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-devel
[05:03] <seb128> Kamion: can you promote libgtkmathview-dev (it has been accepted for promotion by pitti) so abiword can build?
[05:04] <mjg59> BusStation. Excellent.
[05:08] <Mithrandir> elmo: please sync liboil, overriding ubuntu changes ok.
[05:11] <dilinger> Mithrandir: does that fix #12362
[05:11] <dilinger> ?
[05:13] <Nafallo> elmo: please sync kismet from debian/unstable (ubuntu override okey)
=== kyncani [n=kyncani@lns-bzn-40-82-251-169-227.adsl.proxad.net]  has joined #ubuntu-devel
[05:16] <Mithrandir> dilinger: I think so, yes.
=== HWolf [n=HiddenWo@136.78.dynamic.phpg.net]  has joined #ubuntu-devel
[05:18] <desrt> elmo; please sync /dev/hda1 from /media/iAudio (umount -l okay)
[05:20] <dilinger> Mithrandir: cool (new upstream is all that's needed)
=== zakame [n=zak@ubuntu/member/zakame]  has left #ubuntu-devel ["Leaving"] 
[05:24] <doko> Mithrandir: the sync should be fine, I hope lamont-away or infinity can fix gcc-opt soon
[05:24] <doko> \sh: ?
[05:25] <Mithrandir> doko: ok, thanks.
[05:25] <Kamion> seb128: done; please seed libgtkmathview-bin if you think those tools ought to be in main too
[05:25] <Mithrandir> elmo: please sync zlib from unstable; overriding Ubuntu changes is ok.
[05:26] <seb128> Kamion: k, thanks
[05:29] <doko> Mithrandir: hmm, but the build will fail then ...
[05:29] <doko> we still need the gcc-opt workaround
=== sanpera` [n=sanpera@wls-21-226-196-65.tls.net]  has joined #ubuntu-devel
[05:30] <Mithrandir> doko: gnnr, ok. :-/  Wouldn't it be better to just fix that then?
=== mpt [n=mpt@tvwna-ip-a-1.princeton.org]  has joined #ubuntu-devel
[05:31] <Kamion> pitti: libparse-debianchangelog-perl has a lot more dependencies listed in anastacia output without approved inclusion reports
[05:33] <doko> Mithrandir: sure, but it was delayed after breezy
[05:33] <Mithrandir> doko: it's after breezy now, so I guess we can harass lamont or infinity when they're around.
[05:37] <sbalneav> Mithrandir: I was interested in helping out with the X11 dbus backend.  I don't know much about dbus, but what you're looking at doing for the Dapper LTSP would be usable by us in the LTSP main, and I'd be interested in trying to sync the efforts.  What can I do to help?
[05:39] <mpt> Does anyone know why the Ubuntu Developers team has a maltese cross in a circle as their emblem?
[05:39] <mpt> Just wondering...
[05:40] <Mithrandir> sbalneav: that spec is assigned to Diziet, but basically it just needs to be written.  I discovered that there's a TCP transport already written, so just basing something around that would probably be the easiest.
[05:40] <pitti> Kamion: I'll take a look at them later (tomorrow probably), but most of the stuff is a no-brainer (just simple perl modules)
[05:40] <Kamion> pitti: yeah, I figured. no enormous rush, before Thursday is fine
[05:40] <sbalneav> Mithrandir: What's the spec name?
[05:41] <Mithrandir> sbalneav: ThinClientLocalDevices, iirc
[05:41] <Mithrandir> sbalneav: https://wiki.ubuntu.com/ThinClientLocalDevices
[05:42] <doko> Mithrandir: hmm, strange, I do have a merge zlib here, which I didn't yet upload ...
[05:43] <Diziet> Ooh, hello people.
[05:43] <Mithrandir> doko: well, if you've got it merged and nuked the duplication, just upload and close 19104?
[05:43] <sbalneav> Oh, so there's not a separate spec for the dbus + net then.  OK.  I already had the localdev spec.
[05:43] <Diziet> X11 dbus backend> Yes, we do need one of those.
=== BenC [n=bcollins@richmond-209-163-125-175.dynamic-dialup.coretel.net]  has joined #ubuntu-devel
[05:45] <Diziet> X isn't quite like TCP because it's made of messages rather than just a bytestream.  But the AF_UNIX and/or TCP driver would be a good template provided you remember to rip most of it out.
[05:47] <Kamion>      - Remove locale generation part from prebaseconfig
[05:47] <Kamion> Mithrandir: ^-- did you also move it to post-base-installer?
[05:47] <Diziet> I see the spec isn't quite finished.  Do we know if ogra is still working on the drafting ?
[05:47] <doko> Mithrandir: done
[05:48] <Mithrandir> Kamion: yes, it's there all right.
[05:48] <ogra> Diziet, he will...
[05:48] <Diziet> Ah, hello :-).
[05:48] <Mithrandir> Kamion: it was just the by-hand merge changes I had to do.  MOM did her work too.
[05:48] <ogra> Diziet, i'm just busy with some other stuff currently... but i will finish it
=== sanpera` [n=sanpera@wls-21-226-196-65.tls.net]  has joined #ubuntu-devel
[05:48] <Kamion> Mithrandir: cool, thanks
[05:49] <Diziet> Sure.  But even so, the dbus X11 transport is something that people seem to keep wanting for things.
[05:49] <ogra> its not bound to this particular spec
[05:51] <Mithrandir> Kamion: but we should really get bubulle to change to format of the languagelist file.
[05:51] <Mithrandir> it's insanely hard to read.
[05:51] <Kamion> mm, it does suck for merging
[05:51] <Kamion> all the ; and :
[05:51] <Mithrandir> even tab would be better.
[06:04] <Robot101> Diziet: you can send point to point messages between X clients? ICE?
=== Danten [n=danten@h171n10c1o1049.bredband.skanova.com]  has joined #Ubuntu-devel
=== OculusAquilae [n=oculus@p548D22BD.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[06:09] <Diziet> robot101: Yes, XSendMessage IIRC.
[06:09] <Diziet> XSendEvent, in fact.
[06:10] <Diziet> RTFM for details.  You need to know the Window to send it to, eg the Window belonging to the client.  But in X you can have special kinds of windows called `input-only' windows which don't have to appear on the screen, for purposes like this.
[06:10] <mjg59> Some applications ignore XSendEvent
[06:10] <Robot101> Diziet: would this be for the session bus or the system bus?
[06:10] <Diziet> mjg59: Yes, but that's not relevant at this point.
[06:11] <Diziet> robot101: System bus.
[06:11] <Diziet> (In this case.  Although a generalised dbus X transport could be used for either.)
[06:12] <Robot101> Diziet: for the remote desktop case, so that your local box can speak to remote apps running on the local X server?
[06:12] <Robot101> (and vice versa)
[06:12] <Diziet> Exactly.
[06:12] <Robot101> hmm
[06:12] <Robot101> does this solve the authentication problem though>
[06:12] <Diziet> Yes, in this case.
[06:13] <Diziet> Have you read https://wiki.ubuntu.com/ThinClientLocalDevices ?
=== wjb [n=warren@c220-237-178-175.lowrp1.vic.optusnet.com.au]  has joined #ubuntu-devel
[06:14] <Mithrandir> elmo: please sync heimdal from unstable.  Overriding Ubuntu changes is ok.
=== OculusAquilae [n=oculus@p548D22BD.dip0.t-ipconnect.de]  has joined #ubuntu-devel
=== sfeehan_ [n=sfeehan@132.198.90.91]  has joined #ubuntu-devel
[06:16] <mvo> Kamion: can you please kick the gksu build?
[06:18] <Diziet> dd if=/dev/zero of=/mount/point/make-filesystem-full> Zeno's reiserfs.
[06:19] <dholbach> http://wiki.ubuntu.com/Autodeb ... :(
[06:19] <Kamion> mvo: done
[06:21] <mvo> thanks!
[06:28] <Robot101> mjg59: I was thinking about the dbus auth thing, if you wanted to do it generically, you could make a pretty simple D-Bus interface for an authentication service
[06:28] <Robot101> mjg59: so the rule for talking to $service would be that $authservice that implements org.freedesktop.DBus.Auth said yes
=== OculusAquilae [n=oculus@p548D22BD.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[06:28] <mjg59> Ah
[06:29] <mjg59> Nifty
[06:29] <Robot101> mjg59: and pass it the relevant information about the message you're trying to authenticate
[06:29] <Robot101> mjg59: ie sender username, bus ID, etc
[06:30] <Diziet> The dbus X transport has the nice property that you can reuse the X authentication and not have to worry about it much more.  (If that's what you wanted, of course.)
[06:32] <Robot101> sure, it is a good way of exposing your session bus to remote apps. however, I'm not sure if it's desirable having the system bus daemon attempting to maintain connections to the X servers on the system, some kind of bridge that runs per X-session seems safer
=== LaserJock [n=LaserJoc@lambda.chem.unr.edu]  has joined #ubuntu-devel
[06:38] <Diziet> robot101: Oh, no, you misunderstand.  The LTSP server's system bus (if there even is one) would not be involved.
[06:38] <Robot101> Diziet: I mean the system bus on the machine you're sitting at
[06:38] <Robot101> Diziet: the goal is to make the clients on the remote box be able to talk to the system bus daemon on the local system
[06:38] <Diziet> Right, but that of course is just your LTSP think client.  So plumbing it through to your what your session thinks of as the system bus is right.
[06:39] <Robot101> Diziet: talking over X gets you to the right box, but how do you link the X server and the local box's system bus together?
[06:39] <Diziet> By `remote' you mean the LTSP server and by `local' the thin client ?
[06:39] <Diziet> robot101: Easy: the local box's programs talk to the local X server.
[06:40] <seb128> Lathiat: please ask here before mailing the list to say "I don't know where to send this mail so let's make some noise here" :)
=== Oculus [n=oculus@p548D361D.dip0.t-ipconnect.de]  has joined #ubuntu-devel
=== thierry [n=thierry@modemcable040.61-131-66.mc.videotron.ca]  has joined #ubuntu-devel
[06:41] <Diziet> I need a gizmo which teaches VM to decide what to put in my From: depending on what the message I'm replying to had in its To/CC.
[06:42] <Robot101> Diziet: but these are potentially priveledged system daemons like acpid or whatever
[06:42] <thierry> seb128 : at https://launchpad.net/malone/bugs/3947 by not forcing the extension do you mean I should only put the file name without like .xpm
[06:42] <Robot101> Diziet: you want them to maintain connections to the user-controlled X server?
[06:42] <seb128> thierry: yep
[06:42] <Robot101> Diziet: this seems a little concerning - the system bus daemon is meant to enforce the security policy
[06:42] <poningru> https://launchpad.net/distros/ubuntu/+spec/migrating-to-ubuntu
[06:43] <poningru> is anyone working on that?
[06:43] <thierry> seb128 : so every bug I opened should be like that too? 
[06:43] <Diziet> robot101: Sorry, I didn't make myself clear.  The system bus daemon would connect to the local X server so that it can communicate with the remote clients.
[06:43] <seb128> thierry: I've not looked on the other patches, but you should not force the extension right
[06:44] <Diziet> I'm not suggesting getting rid of the dbus daemon on the local end.
[06:44] <thierry> k... going to resend about 7 or 8 patch :(
[06:44] <Robot101> Diziet: right, I'm just wondering if that's sane or not... which local X server does it connect to. should you not start a 'connect this X server to the system bus' process for each X server?
[06:45] <Diziet> robot101: local display :0.  In a thin client configuration it doesn't make much sense for there to be several X displays.
[06:45] <thierry> could anyone tell me what is the use of the karma except to be like "Wohoo! 50 more karme points!"
[06:46] <Diablo-D3> thierry: its analogous to dick size.
[06:47] <thierry> ok I see... strange that malone has karma thing but has not anything to mark patch as obsolte or thing like that...
[06:47] <thierry> obsolete*
[06:48] <LaserJock> azeem: ping?
[06:48] <Diablo-D3> thierry: it probably does but its in a weird place
[06:49] <ogra> Robot101, there is no need for full duplex communication 
[06:49] <ogra> Robot101, the clients system bus shall only notify the servers session bus and initiate the mount
[06:50] <Robot101> ogra: you can't call it a system bus connection and not allow method invocations
[06:51] <Diziet> Right.  Methods like eject this, format that.
=== gilligan__ [i=gilligan@p549A82BF.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[06:52] <ogra> why ? 
[06:52] <azeem> LaserJock: pong
=== mdz [n=mdz@65.200.109.10]  has joined #ubuntu-devel
[06:52] <ogra> ltspfs cares for unmounting etc ...
[06:53] <LaserJock> azeem: Are you going to get the newly released ghemical into Debian?
[06:53] <azeem> LaserJock: yeah, but I was away for the weekend.  I'll try to do this tomorrow or so
[06:54] <LaserJock> azeem: Do you need any help for Ubuntu?
[06:55] <azeem> LaserJock: I'll let you know how it goes.  I'll try to build them for dapper before upload and get back to you in #ubuntu-motu if there are issues
[06:56] <doko> BenC: should a new subversion be built with db4.2, or is it safe to switch to db4.3 ?
[06:56] <LaserJock> azeem: cool
[06:56] <BenC> doko: honestly I don't mess with svn anymore other than using it for the odd project here and there, so I'm not sure what the build requirements are now
[06:57] <Mithrandir> Diziet: I have something like that for gnus.
=== Oculus [n=oculus@p548D361D.dip0.t-ipconnect.de]  has joined #ubuntu-devel
=== MagnusR [n=magru@85.194.14.142]  has joined #ubuntu-devel
[07:01] <Kamion> doko: talk to infinity; AFAIK he's on top of this already
[07:01] <Diziet> mithrandir: Ooh, where is it ?  Just a hacky thing in your .emacs or is it packaged ?  Care to pass it to me under the table ?
[07:01] <Diziet> I could probably bash it up so it works with VM.
[07:02] <Diziet> ogra: I think we disagree about how this will work.  We don't want to use ltspfs for eject and format and things like that.
[07:02] <Diziet> Obviously ltspfs does stuff with unmounting which is rather special.
=== Manny [n=chris@p5496B118.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[07:02] <Manny> hi :)
[07:02] <Mithrandir> Diziet: http://err.no/dotfiles/gnus, it's the part which starts with ("in-" in the gnus-posting-styles part.
[07:03] <Manny> how likely would you say that it is that Ubuntu will get the express installer as default for 6.04?
[07:03] <Diziet> online dotfiles> I approve :-).
[07:03] <Kamion> Manny: it's my top priority for the next six months
=== moyogo [n=moyogo@104pc104.ucu-vb.uu.nl]  has joined #ubuntu-devel
[07:03] <ogra> Diziet, ltspfs unmounts automatically if there was no device access for n seconds
[07:03] <poningru> Manny: considering that its THE critical priority
[07:03] <Manny> Kamion, excellent :)
[07:03] <Kamion> (after I get past this first round of stuff to merge)
[07:03] <poningru> I'd say very likely
[07:03] <Manny> Kamion, poningru: do you know whether gparted can resize ntfs partitions?
[07:03] <Mithrandir> Diziet: it's in svn+cvs, so it's just a cronjob which checks out every five minutes.  I'm lazy. :-)
[07:03] <poningru> Manny: lets take this to #ubuntu
[07:03] <poningru> but yes it can
[07:04] <Manny> poningru, excellent, thanks.
=== Diziet saves the URL for looking at some time.
[07:04] <poningru> make sure its not mounted
[07:04] <poningru> before messing around with it
[07:04] <Diziet> ogra: unmounting> Yes, and we want to keep that.  But only the mount/unmount is changed.
[07:04] <sivang> Mithrandir: do you have your .emacs setup for python there?
[07:05] <Mithrandir> sivang: I don't have any magic .emacs setup for python, but yes, my .emacs is available at (nearly) the same URL.  I'm sure you can figure out which transformation is needed. :-)
[07:06] <LaserJock> Diziet: I have a question about the DeveloperDocumentation spec
[07:07] <Diziet> laserjock: Sue.
[07:07] <Diziet> s/Su/&r
=== tvo [n=tobi@5354EA9B.cable.casema.nl]  has joined #ubuntu-devel
[07:08] <LaserJock> Diziet: how will the UDR be worked on, will be on a svn repo? 
[07:08] <LaserJock> Diziet: like how the doc team does it
[07:09] <Diziet> I was going to use hct if it was sufficiently stable by then; otherwise maybe bzr or maybe just directly editing the Debian package.
[07:09] <Kamion> LaserJock: (it would have to be something suitable for keeping track of changes to the DDR, so a separate svn repository wouldn't cut it)
[07:09] <Diziet> Documentation is an easier problem because it doesn't tend to be full of diffs that take a lot of time to comprehend.
[07:12] <LaserJock> Diziet: have you talked to the doc team about it much? There is a Ubuntu Packaging Guide project on https://wiki.ubuntu.com/DocteamProjects that I was going to work on but it seems somewhat redundant now
[07:12] <Diziet> I've not spoken to the docs team in any detail but it's somewhat orthogonal.
[07:13] <Diziet> I've not seen the Ubuntu Packaging Guide and there's no link to it on that wiki page or the corresponding launchpad page.
[07:13] <LaserJock> Diziet: I believe it was going to be the content from the  introdeveloperdocs  package mostly
[07:14] <Kamion> LaserJock: guides/tutorials are a different matter - there's still a valuable position for a reference work maintained by the development team
[07:14] <Diziet> What Kamion said.
[07:14] <Diziet> introdeveloperdocs is more of a tutorial/howto type thing.  There's room for those too but they tend to multiply because people have different views about how things should be done.
[07:15] <LaserJock> Diziet: Ok, well I just wanted to talk to you guys about it. I don't want to have a bunch or redundant work going on
[07:15] <Diziet> Sure.
=== lbm [n=lbm@x1-6-00-13-10-7a-d1-e4.k233.webspeed.dk]  has joined #ubuntu-devel
[07:16] <LaserJock> I will probably try to work on both (at least keep track) so that the overlap will be minimized
[07:17] <Diziet> You (or whoever is doing it) should update the https://wiki.ubuntu.com/UbuntuPackagingGuide wiki page to refer to introdeveloperdocs (if that's what it is).
[07:18] <LaserJock> yeah, I just found out by looking at your spec that that is what it is. I have been trying to track down what it was, because I am not the original author
[07:19] <Diziet> My Approver wanted me to take out that note about introdeveloperdocs.  I feel vindicated :-).
[07:19] <LaserJock> Diziet: good, it's funny because I am supposed to be working on it for the doc team and I didn't even know 
[07:21] <Diziet> We did have someone from the doc team in one or both of the bofs at ubz.  Are you on ubuntu-devel-announce ?
[07:22] <LaserJock> Diziet: Me? yes
[07:22] <seb128> infinity, lamont-away: please give a retry to libwpd
[07:24] <Diziet> The approved specs were all posted there IIRC.
[07:24] <Diziet> But, communications are something of a problem for us sometimes.
[07:25] <Diziet> I'm afraid I have to go now.  Feel free to email me (iwj@ubuntu.com) or witter here and I'll read scrollback or talk to me tomorrow.
[07:26] <LaserJock> Diziet: thanks, I just wanted to see if I should abandon the Ubuntu Packaging Guide
=== WaterSevenUb [n=WaterSev@azevedo.astro.up.pt]  has joined #ubuntu-devel
=== mvo goes to play hockey
[07:30] <ogra> Kamion, did you see #19407 ?
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-devel
[07:31] <ogra> looks like #15244
[07:32] <Kamion> ogra: I hadn't yet, but I would have done
[07:32] <Kamion> could be the same thing - I'm buried in trying to figure out why current CDs won't boot though
[07:33] <ogra> dont worry, i'll play with it... i think its the same issue
[07:33] <Kamion> sounds promising, certainly
[07:35] <Kamion> it's probably in one of the TCP *_WAIT states; netstat -a would say
[07:35] <Kamion> (netstat -an actually)
[07:35] <ogra> i'll check
=== lifeless_ [n=robertc@dsl-107.131.240.220.lns02-wick-bne.dsl.comindico.com.au]  has joined #ubuntu-devel
[07:39] <Kamion> hmm, sshd does use SO_REUSEADDR though
=== rob^^^ [n=rcaskey@cai17.music.uga.edu]  has joined #ubuntu-devel
[07:43] <Kamion> oh, I see, we don't use SO_REUSEADDR in x11_create_display_inet
[07:45] <Kamion> ... but that's probably good
=== wasabi_ [n=wasabi@207.55.180.100]  has joined #ubuntu-devel
[07:46] <Kamion> ogra: is it possible to get the remote end to close the X11 forwarding channel first, rather than killing sshd? I'm pretty sure that would solve the problem
[07:46] <Kamion> ogra: see http://hea-www.harvard.edu/~fine/Tech/addrinuse.html
[07:47] <Kamion> ogra: basically the problem is that if you kill the server, it has to send the first TCP FIN, which means that it ends up sitting in TIME_WAIT for two minutes
[07:49] <Kamion> though quite why it's apparently stopping at the first port it tries (6010) rather than continuing and trying the next one, I'm not quite sure
[07:50] <ogra> lets see... at least i can confirm that problem is gone with setting this option...
[07:50] <Kamion> which option?
[07:50] <ogra> limiting sshd to ipv4
[07:50] <ogra> (AddressFamily inet)
=== dereks- [n=dereks@66.9.7.66]  has joined #ubuntu-devel
=== dereks- [n=dereks@66.9.7.66]  has left #ubuntu-devel [] 
[07:52] <Kamion> hmm, it used to be that X11 forwarding sockets only worked on IPv4, IIRC; if that's still true, it could mean that it's falling back from IPv4 to IPv6 (rather than to the next IPv4 port) and then falling over somehow
[07:52] <Kamion> I'll ask the reports
[07:52] <Kamion> er, reporter
=== mdke [n=matt@ubuntu/member/mdke]  has joined #ubuntu-devel
=== Valandil [n=chrys@dslb-084-056-083-027.pools.arcor-ip.net]  has joined #ubuntu-devel
=== HiddenWolf [n=HiddenWo@136.78.dynamic.phpg.net]  has joined #ubuntu-devel
=== bigcx2 [n=bigcx2@157.182.194.245]  has joined #ubuntu-devel
=== lfittl [n=lfittl@83-65-243-186.dynamic.xdsl-line.inode.at]  has joined #ubuntu-devel
=== martinhj [n=martinhj@238.80-202-208.nextgentel.com]  has joined #ubuntu-devel
=== thesaltydog [n=fabio@ubuntu/member/thesaltydog]  has joined #ubuntu-devel
=== hunger [n=hunger@p54A6107A.dip0.t-ipconnect.de]  has joined #ubuntu-devel
=== sanpera [n=sanpera@wls-21-226-196-65.tls.net]  has joined #ubuntu-devel
=== doko_ [n=doko@dslb-084-059-074-245.pools.arcor-ip.net]  has joined #ubuntu-devel
=== mpt [n=mpt@tvwna-ip-a-1.princeton.org]  has joined #ubuntu-devel
=== sbalneav [n=sbalneav@mail.legalaid.mb.ca]  has left #ubuntu-devel ["Leaving"] 
[09:38] <\sh> doko_: ping
[09:51] <dieman> congrats on the db2 certification
[09:51] <dieman> now just need oracle ;)
=== gilligan_ [i=gilligan@p549A82BF.dip0.t-ipconnect.de]  has left #ubuntu-devel ["Leaving"] 
=== LeeJunFan [n=junfan@s64-186-37-120.skycon.net]  has joined #ubuntu-devel
=== magnon [n=co@cD9088834.sdsl.catch.no]  has joined #ubuntu-devel
=== cassidy [n=cassidy@f1-pc174.ulb.ac.be]  has joined #ubuntu-devel
=== Simira [n=rpGirl@214.84-48-74.nextgentel.com]  has joined #ubuntu-devel
[10:14] <sivang> dieman: they will come :)
[10:15] <sivang> dieman: I hope..
=== mvo [n=egon@ip181.135.1511I-CUD12K-01.ish.de]  has joined #ubuntu-devel
=== Danten [n=danten@h171n10c1o1049.bredband.skanova.com]  has joined #Ubuntu-devel
=== psusi [n=phreak@69.44.168.233]  has joined #ubuntu-devel
[10:24] <mpt> Kamion, ping
=== LeeJunFan [n=junfan@s64-186-37-120.skycon.net]  has joined #ubuntu-devel
=== lionel [n=lionel@ip-128.net-82-216-65.rev.numericable.fr]  has joined #ubuntu-devel
=== LeeJunFan [n=junfan@s64-186-37-120.skycon.net]  has joined #ubuntu-devel
=== _jason [n=jason@dhcp0534.hrn.resnet.group.upenn.edu]  has joined #ubuntu-devel
=== slomo [n=slomo@ubuntu/member/slomo]  has joined #ubuntu-devel
=== McFergus [n=frg@85-18-14-13.fastres.net]  has joined #ubuntu-devel
=== LeeJunFan [n=junfan@s64-186-37-120.skycon.net]  has joined #ubuntu-devel
=== Loevborg [n=loevborg@d4-84.dip.axsp.de]  has joined #ubuntu-devel
=== jlj [n=agp@207.67.194.249]  has joined #ubuntu-devel
=== zeedo [n=zeedo@80.68.92.188]  has joined #ubuntu-devel
=== janimo [n=jani@Home03207.cluj.astral.ro]  has joined #ubuntu-devel
[11:27] <janimo> if an upload got REJECTED (twice) because of errors and then got ACCEPTED is there anything else needed for it to get in the build?
[11:27] <janimo> the same version number was kept
[11:27] <seb128> no
[11:28] <janimo> are there two windows/hour when packages enetr the build?
[11:29] <slomo> janimo: :03 and :33
[11:29] <janimo> so I thought
[11:30] <janimo> and lamont's site is updated about when the build of a package finishes?
[11:31] <janimo> exo got accepted at ':50 but it did not appear in the build logs, so I am waiting tosee it so I can go to sleep :)
[11:31] <slomo> no idea... maybe every 15 minutes or something... i didn't get the real intervals yet ;)
[11:34] <sivang> night all
=== mdke_ [n=matt@81-178-255-187.dsl.pipex.com]  has joined #ubuntu-devel
=== LaserJock [n=LaserJoc@lambda.chem.unr.edu]  has joined #ubuntu-devel
[11:38] <bmonty_laptop> hi LaserJock 
=== LaserJock [n=LaserJoc@lambda.chem.unr.edu]  has joined #ubuntu-devel
=== marcin [n=user@www.e-dev.tele2.pl]  has joined #ubuntu-devel
=== boglot [i=chaas@gw.workaround.org]  has joined #ubuntu-devel
[11:47] <Kamion> janimo: ~lamont/buildLogs/ is updated every 20 minutes I think
=== mdke__ [n=matt@81-178-222-1.dsl.pipex.com]  has joined #ubuntu-devel