=== gnomefreak [n=gnomefre@ubuntu/member/gnomefreak]  has joined #ubuntu-devel
=== j_ack [n=nico@p508DA12E.dip0.t-ipconnect.de]  has joined #ubuntu-devel
=== aigarius [n=aigarius@82.152.74.5]  has joined #ubuntu-devel
=== aigarius [n=aigarius@82.152.74.5]  has joined #ubuntu-devel
=== Mithrandir [n=tfheen@c5100BC63.inet.catch.no]  has joined #ubuntu-devel
[12:38] <Keybuk> hey Tollef
[12:47] <\sh> Keybuk: it's ok for you (for sync request) if one motu is saying that "it's ok to sync"?
[12:47] <Keybuk> yup
[12:48] <\sh> Keybuk: kk..you got them :)
=== raphink [n=raphink@ubuntu/member/raphink]  has joined #ubuntu-devel
=== bddebian [n=bdefrees@71.224.172.103]  has joined #ubuntu-devel
[01:04] <Keybuk> \sh: is just a "sponsor" formality basically
=== RadiantFire [n=ryan@c-69-180-43-27.hsd1.ga.comcast.net]  has joined #ubuntu-devel
[01:05] <bddebian> Howdy
[01:05] <\sh> Keybuk: no problem :) I just working on some merges and syncs while I'm bored ;)
[01:05] <\sh> Preparing to replace libc6 2.4-1ubuntu4 (using .../libc6_2.4-1ubuntu6_i386.deb) ...
[01:05] <\sh> touch: setting times of `/etc/ld.so.nohwcap': Function not implemented
[01:05] <\sh> dpkg: error processing /var/cache/apt/archives/libc6_2.4-1ubuntu6_i386.deb (--unpack):
[01:05] <\sh> hmmm...known ?
[01:06] <\sh> or is my chroot broken?
[01:06] <Keybuk> dunno, what filesystem?
[01:06] <bddebian> Keybuk: Sorry about the sync requests, apparently I have a pbuilder problem :-(
[01:06] <\sh> Keybuk: xfs
[01:07] <Keybuk> bddebian: which ones?
[01:07] <\sh> moment...recreating chroot
[01:07] <bddebian> gnome-build and gdl
[01:07] <Keybuk> bddebian: I don't tend to look at the name unless it works :p
[01:07] <Keybuk> ah, yeah
[01:10] <bddebian> OK, so how do I figure out where this .la file dependency coming from?  I don't see it in ltmain.sh
[01:10] <Keybuk> "la file dependency" ?
[01:11] <bddebian> Sorry.  ajunta is looking for /usr/lib/libwnck.la which is no longer in the libnwck-1-dev package
[01:12] <Keybuk> then another library it uses has libwnck as a dependency
[01:12] <Keybuk> grep "libwnck" /usr/lib/*.la
[01:12] <bddebian> But the only place I can find reference to it is in another .la
[01:12] <Keybuk> right
[01:12] <\sh> bddebian: that's the bugger then ;)
[01:12] <bddebian> Keybuk: I did that but the .la files are generated are they not?
[01:12] <Keybuk> they're generated when the package is built
[01:12] <Keybuk> so if a dependency of anjuta's hasn't been rebuilt, it may still be depending on libwnck
[01:12] <\sh> bddebian: mostly a rebuild of the broken package which has the wrong .la does help
[01:13] <bddebian> Grrr
[01:13] <bddebian> The ajunta author doesn't even build-dep libwnck
[01:13] <Keybuk> there should be a way to store dependencies inside .a files
[01:13] <Keybuk> then we wouldn't need .la files
[01:13] <Keybuk> bddebian: he almost certainly doesn't need to
[01:13] <bddebian> No?
=== DaSkreech [n=skreech@port0002-abm-adsl.cwjamaica.com]  has joined #ubuntu-devel
[01:14] <DaSkreech> Whats up with libcairo2?
[01:14] <Keybuk> DaSkreech: why don't you tell us?
[01:14] <DaSkreech> It's set to be upgraded but doing so breaks my system
[01:14] <Keybuk> how does your system break?
[01:14] <DaSkreech> Should it be set to upgradeable if it's breaky?
[01:15] <DaSkreech> Adept freaks
[01:15] <Keybuk> "freaks"
[01:15] <DaSkreech> It complains about package conflicts
[01:15] <Keybuk> edgy right?
[01:15] <DaSkreech> Unfortunately no
[01:15] <DaSkreech> I'm on Dapper
[01:15] <Keybuk> what's the conflict?
[01:15] <bddebian> \sh: ajunta is the broken package but it looks for /usr/lib/libnwck.la
[01:15] <Keybuk> we need explicit, accurate, verbose, details
[01:16] <DaSkreech>  And it's jumping from version 1.1 to 1.2
[01:16] <Keybuk> not wishy-washy hand-wavy things like "freaks" and "breaks"
[01:16] <DaSkreech> I'm looking it up now
[01:16] <DaSkreech> :-) I just wanted to know if it was a known thing :)
[01:16] <\sh> bddebian: as I said, someone else depends on libnwck and it wasn't rebuild
[01:17] <bddebian> \sh: Sorry, I don't understand that
[01:17] <Keybuk> bddebian: just accept it
[01:17] <Keybuk> you don't need to understand it
[01:17] <bddebian> I don't?
[01:17] <\sh> bddebian: if libwnck.la is not there anymore, and it shouldn't be there, there is another build-dep of anjuta, which is not rebuild, because it points to this .la file
[01:18] <bddebian> Ahhh, OK
[01:18] <\sh> bddebian: now, cd /usr/lib/ ; grep "libwnck.la" *.la
[01:18] <\sh> and you will find this lib which is using still "libwnck.la", then try to rebuild the package which provides this .la and try again
[01:19] <bddebian> No, it's an .la inside ajunta, I already know that
[01:19] <bddebian> devhelper.la or some such
[01:19] <Keybuk> oh, and libtool's picking up the installed anjuta's .la file? :p
[01:20] <Keybuk> and using it when rebuilding anjuta itself
[01:20] <bddebian> No libtool is failing becuase it isn't install either :-)
[01:20] <Keybuk> eh?
[01:20] <\sh> bddebian: give me a few minutes, and I have a look at it. ok_
[01:20] <Keybuk> now you're flat-out making no sense
[01:20] <\sh> ?
=== \sh missed all that
[01:20] <bddebian> Keybuk: sed: /usr/lib/libwnck.la no such file or directory
[01:21] <bddebian> then libtool: command not found
[01:21] <Keybuk> ?!  why you using sed?!
[01:21] <Keybuk> \sh asked you to use grep!
[01:21] <bddebian> I am not
[01:21] <bddebian> Ohh, I am talking about the package
[01:21] <Keybuk> we've already told you, it's nothing to do with anjuta
[01:21] <\sh> bddebian: forget anjuta for a moment...use a chroot and install all build-deps of anjuta
[01:21] <Keybuk> anjuta is just linking to a broken library
[01:21] <Keybuk> it's that broken library that needs to be fixed
[01:21] <Keybuk> then anjuta will work
[01:21] <Keybuk> so ignore anjuta
[01:21] <bddebian> And I am telling you it is a .la in anjuta itself
[01:22] <bddebian> I have the build deps and no .la files in /usr/lib use libwnck.la
[01:22] <Keybuk> no it's not
[01:22] <Keybuk> if you're not going to listen, I'm not going to help you any more
[01:22] <\sh> bddebian: but you told us, that anjuta doesn't depend on anything which is libwnk
[01:22] <bddebian> \sh: No, I said the author doesn't build-dep libwnck
[01:22] <bddebian> It is a bug on BTS
[01:22] <\sh> bddebian: there...
[01:23] <bddebian> plugins/devhelp/libanjuta-devhelp.la:dependency_libs=
[01:23] <bddebian> Keybuk: I'm not trying to be difficult
[01:23] <Keybuk> bddebian: shut up
[01:23] <Keybuk> yes you are
[01:24] <Keybuk> you're asking for help, and not listening to people who are trying to help you
[01:24] <bddebian> Well I'm trying to but apparently not explaining myself well
[01:25] <Keybuk> you're explaining yourself just fine
[01:25] <Keybuk> we just know better than you
[01:25] <Keybuk> but you won't let us teach you
[01:25] <bddebian> OK
=== bddebian shuts up
[01:25] <Keybuk> good
[01:25] <Keybuk> now; grep "libwnck" /usr/lib/*.la
[01:25] <bddebian> I did.  No hits
[01:26] <Keybuk> ok, grep -r "-lwnck" .
[01:26] <Keybuk> (in the anjuta source tree)
[01:26] <bddebian> Yields the file I posted above
[01:26] <bddebian> plugins/devhelp/libanjuta-devhelp.la:dependency_libs=
[01:26] <Keybuk> no
[01:26] <Keybuk> it's not that file
[01:26] <Keybuk> another one
[01:27] <Keybuk> keep looking
[01:27] <Keybuk> actually, also grep "-lwnck" /usr/lib/*.la
[01:27] <Keybuk> you'll have to grep -- "-lwnck" obviously
[01:28] <Keybuk> any hits?
[01:28] <bddebian> Nothing matches -lwnck unless I am doing something majorly incorrect
[01:28] <Keybuk> right
[01:28] <Keybuk> hmm
[01:28] <Keybuk> grep "wnck" /usr/lib/*.la
[01:28] <Keybuk> any hits for that?
[01:29] <\sh> I'm checking
[01:29] <bddebian> Oh, glad maybe
[01:29] <bddebian> /usr/lib/libdevhelp-1.la:
[01:30] <Keybuk> aha
[01:30] <Keybuk> that's a good candidate
[01:30] <bddebian> shit, bbias, sorry
[01:31] <\sh>  /usr/lib/libdevhelp-1.la:dependency_libs=' -R/usr/lib/firefox -L/usr/lib/firefox /usr/lib/libglade-2.0.la /usr/lib/libxml2.la /usr/lib/libpangoxft-1.0.la /usr/lib/libpangox-1.0.la /usr/lib/libxml2.la /usr/lib/libwnck-1.la /usr/lib/libgtk-x11-2.0.la /usr/lib/libstartup-notification-1.la -L/usr/X11R6/lib -lSM -lICE -lXRes /usr/lib/libgtk-x11-2.0.la /usr/lib/libgdk-x11-2.0.la /usr/lib/libatk-1.0.la /usr/lib/libgdk-x11-2.0.la /usr/lib/libpangocairo
[01:31] <\sh> a /usr/lib/libatk-1.0.la /usr/lib/libgdk_pixbuf-2.0.la /usr/lib/libpangocairo-1.0.la /usr/lib/libcairo.la /usr/lib/libpangoft2-1.0.la /usr/lib/libpango-1.0.la -lXext -lXinerama -lXi -lXrandr -lXcursor -lXfixes /usr/lib/libpango-1.0.la /usr/lib/libcairo.la -lXrender -lX11 -lpng12 -lfontconfig /usr/lib/libfreetype.la -lz /usr/lib/libgobject-2.0.la /usr/lib/libgconf-2.la /usr/lib/libORBit-2.la /usr/lib/libORBit-2.la /usr/lib/libgmodule-2.0.la /usr/
[01:31] <\sh> .0.la /usr/lib/libgthread-2.0.la -lm /usr/lib/libgmodule-2.0.la /usr/lib/libgthread-2.0.la /usr/lib/libglib-2.0.la /usr/lib/libglib-2.0.la -lgtkembedmoz -lxpcom -lplds4 -lplc4 -lnspr4 -lpthread -ldl'
[01:31] <\sh> first hit ;)
[01:32] <\sh> libdevhelp-1-dev: usr/lib/libdevhelp-1.la
[01:32] <\sh> try to rebuild this first ;)
=== jsgotangco [n=jsg123@ubuntu/member/jsgotangco]  has joined #ubuntu-devel
=== freeflying [n=freeflyi@ubuntu/member/freeflying]  has joined #ubuntu-devel
=== human_blip [n=mike@220.157.65.29]  has joined #ubuntu-devel
[01:40] <bddebian> Gah devhelp is in main
[01:40] <\sh> bddebian: doesn't matter...did the rebuild worked?
[01:42] <\sh> devhelp needs to be merged anyways
[01:43] <\sh> Keybuk: when is mom running and updating the stats pages?
[01:43] <jsgotangco> good morning
[01:43] <\sh> hey jsgotangco
[01:43] <Keybuk> \sh: hourly
[01:43] <jsgotangco> hi \sh!
[01:45] <\sh> Keybuk: I just ask because e.g. afterstep is gone from the merges page, but doesn't show up in the "updated merges" section
[01:45] <Keybuk> is there a new Debian upload then?
[01:46] <Keybuk> ah, maybe there's confusion
[01:46] <Keybuk> the top list ("outstanding merges") is things which haven't seen an upload to edgy yet
[01:46] <Keybuk> so probably haven't been merged ever
[01:46] <Keybuk> the things in the "updated merges" list HAVE had uploads to edgy
[01:46] <Keybuk> so have probably been merged
[01:46] <\sh> Keybuk: afterstep was in the list, I did the merge today, and bddebian uploaded for me :)
[01:46] <Keybuk> right
[01:47] <Keybuk> so his upload would have cancelled the need for a merge
[01:47] <Keybuk> Ubuntu is "up to date"
[01:47] <\sh> Keybuk: ah you mean, the lower section is "uploaded already just before mom was running"
[01:47] <Keybuk> when a new Debian upload happens (Ubuntu is out of date) then it'll appear in the "Updated Merges" list
[01:47] <Keybuk> it's especially important for main
[01:48] <Keybuk> everything must be merged at least once
[01:48] <Keybuk> so we want to clear the top list
[01:48] <Keybuk> and then review the second list for anything important (looking at the version skew)
[01:48] <Keybuk> and do that list if we have time
[01:48] <Keybuk> it's impossible to have zero merges, after all :p
[01:48] <\sh> Keybuk: ah .. now I understand :) 
[01:48] <\sh> well...some of the main merges are still on my laptop...
[01:48] <Keybuk> cause if we managed to get them to zero
[01:49] <Keybuk> then Debian would do some updates that day, and there'd be merges again! :D
=== imbrandon [n=brandon@ubuntu/member/pdpc.active.imbrandon]  has joined #ubuntu-devel
=== [PUPPETS] Gonzo [i=gonzo@80.69.47.16]  has joined #ubuntu-devel
=== Amaranth [n=amaranth@ubuntu/member/amaranth]  has joined #ubuntu-devel
=== Hobbsee [n=Hobbsee@ubuntu/member/hobbsee]  has joined #ubuntu-devel
[02:05] <Hobbsee> morning all
[02:09] <\sh> uh...NMU from debian is wrong 
[02:09] <licio> here is night :)
[02:10] <\sh> here is morning...early morning ;)
[02:10] <Hobbsee> 10am here - monday
[02:10] <licio> :)
[02:11] <licio> 21pm here - sunday
[02:11] <licio> :)
[02:11] <licio> I'm sleepy
[02:12] <\sh> 02:11am here - monday
[02:13] <licio> bye all
[02:13] <licio> I'm going to bed 
[02:14] <Hobbsee> night licio 
[02:14] <licio> Hobbsee, morning :)
=== bmonty [n=bmontgom@ubuntu/member/bmonty]  has joined #ubuntu-devel
=== FliesLikeABrick [n=Ryan@about/rpi/rawdor]  has joined #ubuntu-devel
=== rpedro [n=rpedro@87-196-36-6.net.novis.pt]  has joined #ubuntu-devel
=== gnomefreak [n=gnomefre@ubuntu/member/gnomefreak]  has joined #ubuntu-devel
=== _human_blip_away [n=mike@220.157.65.29]  has joined #ubuntu-devel
=== rpedro [n=rpedro@87-196-36-6.net.novis.pt]  has joined #ubuntu-devel
=== ogra [n=ogra@ubuntu/member/ogra]  has joined #ubuntu-devel
=== Amaranth [n=amaranth@ubuntu/member/amaranth]  has joined #ubuntu-devel
=== catinsnow [n=snow@218.79.240.131]  has joined #ubuntu-devel
=== freeflying [n=freeflyi@ubuntu/member/freeflying]  has joined #ubuntu-devel
=== asac_ [n=asac@debian/developer/asac]  has joined #ubuntu-devel
=== asac_ is now known as asac
=== bmonty is now known as bmonty_away
=== Burgundavia [n=corey@ubuntu/member/burgundavia]  has joined #ubuntu-devel
=== tadpole [n=tadpole@ip68-111-223-211.sd.sd.cox.net]  has joined #ubuntu-devel
=== holycow [n=a@mail.wjsgroup.com]  has joined #ubuntu-devel
=== gnomefreak [n=gnomefre@ubuntu/member/gnomefreak]  has joined #ubuntu-devel
=== Amaranth [n=amaranth@ubuntu/member/amaranth]  has joined #ubuntu-devel
[04:22] <Burgundavia> \sh: flue is a part of the chimney. Flu is the sickness :)
[04:22] <bddebian> heh
=== j_ack [n=nico@p508DA12E.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[04:42] <\sh> Burgundavia: oh damn
[04:43] <\sh> you see I'm sick ;)
[04:43] <\sh> fixed
=== freeflying [n=freeflyi@ubuntu/member/freeflying]  has joined #ubuntu-devel
=== msw [n=msw@rdu-nat.rpath.com]  has joined #ubuntu-devel
[04:58] <Burgundavia> \sh_away: no worries
=== lnxkde [n=lnxkde@206.248.108.98]  has joined #ubuntu-devel
=== wasabi [n=wasabi@ubuntu/member/wasabi]  has joined #ubuntu-devel
=== stub [n=stub@ppp-58.8.1.252.revip2.asianet.co.th]  has joined #ubuntu-devel
=== freeflying_ [n=freeflyi@221.221.161.252]  has joined #ubuntu-devel
=== TTT_Travis [n=Travis@208.157.173.225]  has joined #ubuntu-devel
[06:09] <TTT_Travis> I am trying to compile and this is the error I get after about an hour: http://pastebin.ca/77532
[06:10] <Lathiat> TTT_Travis: This is the wrong channel for support with that, try #ubuntu
[06:11] <TTT_Travis> ok
[06:11] <TTT_Travis> thanks
=== TTT_Travis [n=Travis@208.157.173.225]  has left #ubuntu-devel ["Leaving"] 
=== Xoff [n=mas01cr@158.223.59.22]  has joined #ubuntu-devel
=== ctd [i=ctd@creep.bur.st]  has joined #ubuntu-devel
=== raphink [n=raphink@ubuntu/member/raphink]  has joined #ubuntu-devel
=== robitaille [n=daniel@ubuntu/member/robitaille]  has joined #ubuntu-devel
=== pitti [n=pitti@ubuntu/member/pitti]  has joined #ubuntu-devel
[07:19] <pitti> Good morning!
[07:20] <jsgotangco> hi pitti!
=== catinsnow_ [n=snow@218.81.223.187]  has joined #ubuntu-devel
[07:28] <pitti> hi jsgotangco 
=== stub [n=stub@ppp-58.8.1.252.revip2.asianet.co.th]  has joined #ubuntu-devel
[07:34] <crimsun> 'morning pitti. When you're less busy, please check the openvpn debdiff on security-review in may 2006 (malone bug 45827)
[07:34] <Ubugtu> Malone bug 45827 in openvpn "openvpn old security problems (Breezy)" [Medium,In progress]  http://launchpad.net/bugs/45827
[07:37] <pitti> crimsun: https://lists.ubuntu.com/archives/security-review/2006-May/000405.html ? That looks empty
[07:37] <pitti> crimsun: and I do not have that in my mailbox for some reason
[07:37] <pitti> crimsun: maybe you can attach the debdiffs to the bug?
[07:38] <crimsun> pitti: I'll resend inline (again)
[07:39] <crimsun> err, attach I mean
[07:40] <crimsun> sent.
[07:45] <fabbione> morning
=== cjb [n=cjb@pool-141-154-73-247.bos.east.verizon.net]  has left #ubuntu-devel ["ERC] 
[07:52] <whiprush> jdub: awake?
[07:53] <Burgundavia> hey whiprush, shouldn't you be asleep?
[07:53] <whiprush> Burgundavia: yeah, but it's a holiday here, so long nites, lots of beer, etc. etc.
[07:54] <Burgundavia> whiprush: ah, you lucky thing. I just left the US, just before the 4th and after the 1st (our holiday) :(
[07:54] <whiprush> I just picked up the Ubuntu Hacks book (which is excellent btw), and I wanted to blog about it, but I think I'm broken on planet.u.c. :-/
=== catinsnow_ is now known as catinsnow
=== highvoltage [n=jono@196.36.161.235]  has joined #ubuntu-devel
[07:58] <fabbione> crimsun: ping?
=== Lure [n=lure@ubuntu/member/lure]  has joined #ubuntu-devel
=== Fujitsu [n=Fujitsu@c211-28-181-26.eburwd7.vic.optusnet.com.au]  has joined #ubuntu-devel
=== nikola [n=pygi@83-131-246-169.adsl.net.t-com.hr]  has joined #ubuntu-devel
=== pygi [n=pygi@83-131-246-169.adsl.net.t-com.hr]  has joined #ubuntu-devel
[08:10] <crimsun> fabbione: pong (sorry, phone)
[08:11] <fabbione> crimsun: did you coordinate your xorg-server upload to dapper-updates with somebody from the x team?
[08:11] <crimsun> fabbione: that was an accidental upload, and I asked for it to be rejected
[08:11] <fabbione> ok
[08:12] <crimsun> fabbione: the correct one was for xserver-xorg-input-mouse, which mdz approved in bug 38272
[08:12] <Ubugtu> Malone bug 38272 in xserver-xorg-input-mouse "option EmulateWheelTimeout not working" [Medium,Fix released]  http://launchpad.net/bugs/38272
[08:13] <fabbione> okydoky
=== viviersf [n=cain@196.44.1.98]  has joined #ubuntu-devel
=== simira [n=simira@tellus.err.no]  has joined #ubuntu-devel
=== robitaille [i=robitail@ubuntu/member/robitaille]  has joined #ubuntu-devel
=== carlos [n=carlos@gandalf.pemas.net]  has joined #ubuntu-devel
=== Gloubiboulga [n=gauvain@ubuntu/member/gloubiboulga]  has joined #ubuntu-devel
=== Lure_ [n=lure@BSN-77-152-53.dsl.siol.net]  has joined #ubuntu-devel
=== luka74 [n=lure@BSN-77-152-53.dsl.siol.net]  has joined #ubuntu-devel
=== marilize [n=marilize@196.36.161.235]  has joined #ubuntu-devel
=== Kagou [n=Kagou@84.6.132.187]  has joined #ubuntu-devel
=== Lure_ [n=lure@BSN-77-152-53.dsl.siol.net]  has joined #ubuntu-devel
=== Lure_ [n=lure@BSN-77-152-53.dsl.siol.net]  has joined #ubuntu-devel
=== rpedro [n=rpedro@87-196-64-121.net.novis.pt]  has joined #ubuntu-devel
=== Fujitsu [n=Fujitsu@c211-28-181-26.eburwd7.vic.optusnet.com.au]  has joined #ubuntu-devel
=== ealden [n=ealden@203.177.221.62]  has joined #ubuntu-devel
=== luka74 [n=lure@BSN-77-152-53.dsl.siol.net]  has joined #ubuntu-devel
=== raphink [n=raphink@ubuntu/member/raphink]  has joined #ubuntu-devel
[09:14] <pitti> siretart: ping
=== luka74 [n=lure@BSN-77-152-53.dsl.siol.net]  has joined #ubuntu-devel
[09:21] <siretart> pitti: morning!
[09:22] <pitti> siretart: I test and upload the new cdbs now
[09:22] <pitti> siretart: I just saw that you already merged
[09:22] <pitti> we need it as build-dep for e. g. pyxdg
=== Lure_ [n=lure@external-7.hermes.si]  has joined #ubuntu-devel
[09:23] <siretart> pitti: it didn't build for me for some reason why I merged it, but I was quite sure that it wasn't because of the merge
[09:23] <siretart> pitti: anyway, I didn't want to upload untested stuff, which didn't work for me
[09:23] <siretart> pitti: if it does for you, just upload whats in the bzr branch
[09:23] <pitti> siretart: I'll do some test builds anyway
=== lukketto [n=lukketto@host173-157.pool8710.interbusiness.it]  has joined #ubuntu-devel
[09:24] <pitti> siretart: all tests passed and the package builds; what failed for you?
[09:25] <Kagou> hi pitti :) the new print system included in gtk2.10 will be used for edgy ?
=== lukketto [n=lukketto@host173-157.pool8710.interbusiness.it]  has left #ubuntu-devel [] 
[09:25] <pitti> Kagou: well, the gnome apps certainly will
=== mvo [n=egon@p54A678E7.dip.t-dialin.net]  has joined #ubuntu-devel
[09:26] <Kagou> pitti: we will continu using g-c-m  ?
=== lukketto [n=lukketto@host173-157.pool8710.interbusiness.it]  has joined #ubuntu-devel
[09:27] <pitti> Kagou: if someone comes along and adapts redhat's tool to Ubuntu, we'll gladly use it
[09:27] <Kagou> ok :)
=== ivoks [n=ivoks@ubuntu/member/ivoks]  has joined #ubuntu-devel
=== lukketto [n=lukketto@host173-157.pool8710.interbusiness.it]  has left #ubuntu-devel [] 
[09:28] <fabbione> hey mvo
[09:28] <pitti> hi ivoks 
[09:28] <siretart> pitti: the testcase failed in 2 or 3 tests
[09:28] <fabbione> mvo: you should be good to re-enable selinux support in device-mapper and lvm2
[09:28] <ivoks> hi pitti 
[09:28] <siretart> pitti: I didn't have the time to investigate the failure, wanted to do it this weekend, but forgot it. sorry :(
[09:28] <mvo> fabbione: ok, will do
[09:28] <fabbione> mvo: you want to do dm first, and lvm2 later with a versioned B-D
[09:29] <fabbione> mvo: to make sure to build with the right dm
[09:29] <fabbione> mvo: great thanks
[09:29] <siretart> pitti: s/testcase/testsuite/
[09:30] <pitti> siretart: hm, not here; and g-v-m builds fine, doing two other test builds here
[09:30] <pitti> s/here$/now/
[09:31] <pitti> doko_: ping
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-devel
[09:35] <siretart> anyone knows how often NEW packages from debian are synced to ubuntu/edgy?
[09:36] <siretart> I know about a package in debian which I'm waiting to appear in edgy for quite some days...
[09:43] <pitti> siretart: hm, indeed, with the old cdbs installed, the testsuite passes, now with the new one isntalled it fails 3 cases
=== pounk [n=pounk@142-217-81-161.telebecinternet.net]  has joined #ubuntu-devel
[09:50] <siretart> pitti: now I'm a bit confused, because doesn't the cdbs testsuite use the cdbs classes from inside the package?
[09:50] <pitti> siretart: actually yes
[09:50] <pitti> siretart: and I just noticed that I installed my debug symbol stripper wrapper; this could cause the regressions
=== dholbach [n=daniel@i577B3029.versanet.de]  has joined #ubuntu-devel
[09:52] <pitti> dholbach! Guten Morgen, Alter! :-P
[09:52] <pitti> siretart: ah, that was it. panic mode off then :)
[09:52] <dholbach> good morning!
[09:52] <dholbach> hey pitti, ALTER!
[09:53] <doko> pitti: pong
[09:53] <dholbach> hey doko
=== tortoise_ [n=tortoise@81-86-105-156.dsl.pipex.com]  has joined #ubuntu-devel
=== hunger [n=tobias@p54A64679.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[09:55] <pitti> doko: will you merge python-support soon? it's required as build-dep of e. g. pyxdg
[09:55] <pitti> siretart: ok, works fine here with test suite, postgresql, g-v-m, and my debug strip test suite. away with it! :)
[09:55] <siretart> pitti: excellent
[09:56] <pitti> siretart: (also tested with dash and bash)
=== siretart begins to fall in love with bzr mantained packages :)
[09:56] <crimsun> they are nice
[09:57] <doko> pitti: hmm, thought mvo would do it ...
[09:57] <doko> pitti: anyway, I can do it. 
[09:57] <pitti> doko: the only difference is that we do not build 2.3 stuff, right?
[09:58] <pitti> doko: (diff to Debian)
[09:58] <mvo> doko: oh, that was a misunderstanding, I was asking for it
[09:59] <pitti> gar, why did I end up having to do the mesa merge?
[09:59] <Yagisan> pitti: you like the pain ?
[10:00] <pitti> hi Yagisan 
=== el [n=konversa@u40-30.dsl.vianetworks.de]  has joined #ubuntu-devel
[10:00] <Yagisan> G'day pitti. for the -ssp arch. Is is up yet ?
[10:00] <pitti> wow, and an 1.1 MB ubuntu patch
[10:00] <pitti> Yagisan: YES!!!!1!!! :-)
[10:01] <pitti> Yagisan: packages build with ssp on since Friday
[10:01] <Yagisan> pitti: ok. all packages ?
[10:01] <pitti> yes, it was globally turned on in gcc
[10:01] <siretart> pitti: how do you coordinate merges?
[10:01] <Yagisan> pitti: ok. Could you pm me details, I'll put it on  a production web server
[10:01] <pitti> siretart: the default claimer is the name on the {main,universe}.html page
[10:02] <pitti> siretart: if you want to merge something else, ping the default claimer before
[10:02] <siretart> pitti: so basically the last uploader. I see
[10:02] <siretart> I was wondering how we'll manage universe
=== trulux [n=echo@unaffiliated/trulux]  has joined #ubuntu-devel
=== apokryphos [n=apokryph@host-87-74-66-37.bulldogdsl.com]  has joined #ubuntu-devel
[10:05] <crimsun> siretart: pretty much the same way, no? I've been going through the ones with my name beside it
[10:05] <siretart> pitti: thanks for sponsoring ;)
[10:06] <siretart> crimsun: Let's do so for now, and look in the last week for missing merges
[10:06] <siretart> crimsun: I fear that there may be poeple less active in edgy than in dapper
[10:10] <\sh> siretart: I'm doing my merges first, from last time, and then working from top to bottom
=== sean_ [n=sean@71-214-90-191.ptld.qwest.net]  has joined #ubuntu-devel
=== chmj [n=chmj@196.44.1.98]  has joined #ubuntu-devel
=== phanatic [n=phanatic@ubuntu/member/phanatic]  has joined #ubuntu-devel
=== luka74 [n=lure@BSN-77-152-53.dsl.siol.net]  has joined #ubuntu-devel
[10:22] <tseng> morn pitti 
[10:22] <pitti> hi tseng 
=== freeflying_ [n=freeflyi@221.221.159.138]  has joined #ubuntu-devel
[10:22] <tseng> can you please look at the inclusion report for XSP again?
[10:23] <tseng> whenever you can.. and tell me if you still want it split up
[10:23] <pitti> tseng: uh, you really want the web server in main?
[10:24] <fabbione> uh?
[10:24] <tseng> not really, no
[10:24] <pitti> there was a recent vulnerability in it, was that fixed?
[10:24] <tseng> yes.
[10:24] <Kamion> crimsun: rejected xorg-server from dapper-updates per request
[10:24] <tseng> I can fight with Debian about where to put the script, then.
[10:25] <tseng> discuss nicely, I mean
[10:25] <pitti> tseng: :)
[10:27] <crimsun> Kamion: thank you
[10:28] <Kamion> (and accepted xserver-xorg-input-mouse)
[10:28] <crimsun> (thank you!)
=== marilize [n=marilize@196.36.161.235]  has joined #ubuntu-devel
=== pygi [n=pygi@83-131-237-137.adsl.net.t-com.hr]  has joined #ubuntu-devel
[10:40] <\sh> Kamion: thx for the sync
[10:40] <\sh> s
[10:40] <pitti> mjg59: ping
[10:41] <phanatic> Kamion: ping
=== Seveas [n=seveas@ubuntu/member/seveas]  has joined #ubuntu-devel
[10:42] <mjg59> pitti: Hi
[10:42] <pitti> mjg59: do you know a bit about mesa? the current MoM merge is nothing but a mess
=== Lure_ [n=lure@external-7.hermes.si]  has joined #ubuntu-devel
[10:43] <Kamion> phanatic: hi
[10:43] <pitti> Kamion: do you care about libsdl1.2debian-udeb?
=== Seveas [n=seveas@ubuntu/member/seveas]  has joined #ubuntu-devel
[10:43] <pitti> Kamion: in Debian, it builds a directfb video backend and not much else
[10:43] <pitti> probably for a graphic installer
[10:43] <fabbione> pitti: g-i
[10:43] <Kamion> pitti: not at present, but the graphical installer will eventually want it
[10:43] <Kamion> should go to universe for now
[10:43] <pitti> Kamion: so, ok if I disable the package for now?
[10:43] <Kamion> pitti: sure
[10:44] <pitti> or universe, works for me as well
[10:44] <Kamion> I guess you can't build it in main, can you?
[10:44] <pitti> Kamion: I removed the directfb build-dep
[10:44] <Kamion> I wouldn't mind sucking the build-deps into main, if we can do that reasonably
=== Seveas [n=seveas@ubuntu/member/seveas]  has joined #ubuntu-devel
[10:44] <pitti> Kamion: so the udeb is fairly useless for now
[10:44] <phanatic> Kamion: hi, i had a sponsored upload by siretart to dapper-updates (sysinfoi package) a few weeks ago, but it wasn't approved. is something missing?
[10:44] <seb128> pitti: what are you trying to kick to universe? directfb?
[10:44] <pitti> seb128: it's already in universe
[10:45] <seb128> pitti: because new libcairo and GTK 2.10 I'm about to package needs it
[10:45] <pitti> oh, ok
[10:45] <fabbione> pitti: i am afraid it's a useless attempt
[10:45] <seb128> GTK has a directfb backend now
[10:45] <fabbione> sooner or later we will suck in g-i
[10:45] <pitti> alright
[10:45] <fabbione> and all its dependencies
[10:45] <Kamion> seb128: I'd very much like that in main; then we can start syncing cdebconf rather than merging it
[10:45] <pitti> then we'll move directfb into main and I build the sdl udeb
[10:45] <Kamion> phanatic: looking
[10:45] <siretart> Kamion: Keybuk said that ubuntu-archive wouldn't know how to sync to dapper-backports, is that right?
[10:45] <seb128> pitti: could you take care of the main promotion? :)
=== doko [n=doko@dslb-088-073-107-200.pools.arcor-ip.net]  has joined #ubuntu-devel
=== el [n=konversa@u40-30.dsl.vianetworks.de]  has joined #ubuntu-devel
[10:46] <phanatic> Kamion: thanks
[10:46] <pitti> seb128: seems to be fairly harmless anyway
=== carlos [n=carlos@208.Red-83-33-192.dynamicIP.rima-tde.net]  has joined #ubuntu-devel
[10:50] <Kamion> phanatic: it appears to have been manually rejected
[10:50] <Kamion> phanatic: did neither you nor siretart get mail about it?
[10:50] <phanatic> Kamion: no, at least i did not
[10:50] <phanatic> Kamion: why was it rejected?
[10:51] <Kamion> siretart: I know how to do it, but the script in question has not yet been ported to soyuz; I began work on that last night
[10:51] <Kamion> phanatic: I don't know; rejects don't have reasons attached to them in the database at present - that's why I was hoping you'd have got mail
[10:51] <Kamion> mdz: did you reject sysinfo from dapper-updates?
[10:51] <mjg59> pitti: What's the Debian version now?
[10:52] <mjg59> pitti: We can probably drop all Ubuntu patches
[10:52] <pitti> mjg59: 6.4.2-1
[10:53] <mjg59> Oh, argh. That's going to be awkward.
[10:53] <pitti> mjg59: even our binary package names do not match
[10:53] <Kamion> phanatic: try sending mail to ubuntu-archive@lists.ubuntu.com to see if any of the other archive admins know
[10:53] <mjg59> pitti: You'll want to talk to Daniel about binary package names
[10:53] <pitti> right
[10:53] <Kamion> phanatic: feel free to cite this conversation
[10:53] <phanatic> Kamion: thanks, i'll do that
[10:53] <pitti> eventually we need to get back in sync with Debian wrt. X
[10:53] <mjg59> Any of the patches I added can be dropped
[10:53] <fabbione> pitti: is that for mesa?
[10:54] <pitti> mjg59: ah, good to know; thanks!
[10:54] <pitti> fabbione: yes
[10:54] <mjg59> We'll fix those up again afterwards
[10:54] <fabbione> pitti: better you leave it to infinity
[10:54] <pitti> fabbione: the merge is assigned to me since I added a pot file as last uploader
[10:54] <pitti> fabbione: I'd love to get rid of it :)
[10:54] <fabbione> pitti: yeah but it doesn't mean you are forced to do it NOW. coordinate it with adam because he was already looking at it
[10:54] <pitti> but this package needs to be merged together with the rest of X
[10:55] <Kamion> Adam is on vacation this week, and X needs to be got out of the way
[10:56] <fabbione> Kamion: yes i am aware of Adam vac. mesa has been source of different troubles due to excessive renaming of pkgs
[10:56] <fabbione> that's why i was suggesting to let it to Adam.
[10:56] <fabbione> he did most of those transitions with daniels
[10:57] <Kamion> as I say, I think we are running short on time and need to get this at least started before Adam gets back
[10:57] <siretart> Kamion: ah, so I was right about the procedure how to request syncs to dapper-backports
[10:57] <Kamion> I do not think we can afford to wait a week
[10:57] <Mithrandir> Kamion: I'd really like to have a bootable and somewhat-working -desktop in about a week too, for the first knot.
[10:57] <siretart> keybuks mail made me wonder if I missed something
[10:57] <Kamion> indeed
[10:58] <Kamion> siretart: since elmo stopped doing archive maintenance, there's never been a defined procedure
[10:58] <Kamion> siretart: filing bugs and ccing ubuntu-archive is as good as any other procedure one might invent, I think
[10:59] <siretart> Kamion: at the TB meeting I asked mdz, and he confirmed that this would be a job for ubuntu-archive. and that we could upload directly now to dapper-backports if needed..
[10:59] <Kamion> siretart: I'd like to have a little time to see if the script is easy to port to soyuz
[11:00] <pitti> siretart: directly upload to d-backports? that sounds evil
[11:00] <Kamion> I'm certainly less comfortable with that myself
[11:01] <tseng> I am told coredev has that power now
=== slomo [n=slomo@ubuntu/member/slomo]  has joined #ubuntu-devel
[11:01] <siretart> pitti: only core-dev, and only for very small changes like updated build-dependency and such
=== el [n=konversa@u40-30.dsl.vianetworks.de]  has joined #ubuntu-devel
[11:01] <Kamion> tseng: technical power yes, but it still has to go through archive admins for approval, and (as far as I'm concerned) it won't get that until we've at least made a token attempt to port the backporting script
[11:01] <siretart> Kamion: take your time
[11:02] <pitti> slomo: I'm currently merging sdl, btw
[11:03] <slomo> pitti: ok, np :) why don't you wait for directfb?
[11:03] <pitti> slomo: you mean directfb needs to be merged as well?
[11:03] <dholbach> pitti: mvo asked for a sync
[11:03] <pitti> slomo: no, we have the latest debian version
[11:03] <slomo> pitti: no... directfb in main
[11:04] <fabbione> pitti: should we take a look at that dovecot thingy?
[11:04] <Kamion> dholbach: that got processed a while back
=== Huahua [n=hua_@222.50.183.241]  has joined #ubuntu-devel
[11:05] <dholbach> Kamion: yeah, I should have said "there's no merge to do" :-)
[11:05] <dholbach> Kamion: how are you?
[11:06] <Kamion> dholbach: a touch hungover but otherwise ok :)
[11:06] <Kamion> importing base-installer into bzr pre-merge
[11:06] <dholbach> :-)))
[11:06] <dholbach> nice
=== ChipX86 is now known as ChipX86|Sleep
[11:12] <pitti> slomo: yes, see discussion above, we need it anyway
[11:13] <pitti> fabbione: can you give me another 30 minutes or so?
[11:13] <fabbione> pitti: yes, i am looking at how upstream broke in the meantime
[11:13] <slomo> pitti: joined only 13 minutes ago ;) can you paste me the discussion?
[11:16] <tseng> slomo: the summary was
[11:16] <tseng> pitti: kamion: do you care about directfb udeb; kamion: no; pitti: ok i will stop building it (or move to universe)
[11:16] <slomo> tseng: thanks
[11:16] <Kamion> erm
[11:17] <Kamion> to clarify, pitti asked me about libsdl1.2debian-udeb, not directfb-udeb
=== ToadZzZztool is now known as Toadstool
[11:17] <tseng> oh right, off by one
[11:22] <seb128> can anybody tell me what is happening to evolution-data-server 1.7.3 build?
[11:23] <seb128> according to the corresponding launchpad page it's neither built, nor building, nor waiting for build
[11:23] <seb128> nor listed by any other category
[11:25] <tseng> https://launchpad.net/distros/ubuntu/edgy/+queue?queue_state=3&queue_text=evolution
[11:25] <tseng> according to this it is "done"
[11:26] <tseng> unclear on what that means
[11:27] <seb128> tseng: if you click on "View Builds", it's not listed though
[11:28] <tseng> right
[11:28] <fabbione> tseng: evolution != evolution-data-server ?
[11:28] <tseng> fabbione: its a search
[11:28] <tseng> WHERE foo LIKE "%mysearch%"
[11:28] <fabbione> oh ok
[11:34] <crimsun> doko: ping, is Ubuntu's lib32asound2 supposed to conflict with ia32-libs (<< 1.9) ?
=== spacey [n=herman@ubuntu/member/spacey]  has joined #ubuntu-devel
=== ogra [n=ogra@ubuntu/member/ogra]  has joined #ubuntu-devel
[11:37] <pitti> hi ogra 
[11:37] <pitti> ogra: I just finished merging dhcp3, and it seems to work fine
[11:38] <pitti> ogra: I also left revert-next-server.dpatch
[11:38] <pitti> ogra: s/left/kept/
[11:39] <fabbione> pitti: i am writing to the debian maintainer and dovecot upstream
[11:40] <fabbione> we should take the same direction here to fix it all over
[11:40] <pitti> fabbione: the DD is quite responsive
[11:40] <fabbione> otherwise it will be a mess
[11:40] <pitti> right
[11:43] <\sh> hmmm
[11:43] <\sh> I think I found a really strange but
[11:43] <\sh> bug
[11:44] <\sh> create a /var partition and everything what needs /var/run (most of the init scripts) are failing
[11:44] <\sh> I just rechecked, and removed the /var partition and everything works
[11:44] <\sh> (dapper it is)
[11:45] <ogra> pitti, yay, thanks :)
[11:45] <pitti> fabbione: ok, I'm done so far; shall I still look into anything?
[11:46] <fabbione> pitti: your inbox for now.
[11:46] <pitti> ok
[11:47] <\sh> yes, it doesn't mount /var/run as tmpfs and failes completly...
[11:47] <fabbione> pitti: if you feel like looking at the code, it is clear how the thing went all downhill
[11:47] <fabbione> pitti: 0.99.14 had one and only one declaration of SUBSCRIPTIO_
[11:47] <fabbione> SUBSCRIPTION_FILENAME
[11:47] <fabbione> while it has been broken down in different storage libs in 1.0
[11:47] <fabbione> becoming inconsistent
[11:50] <pitti> fabbione: thanks for the heads-up; I basically agree to your proposal
[11:51] <\sh> https://launchpad.net/distros/ubuntu/+source/initscripts/+bug/51452 
[11:51] <Ubugtu> Malone bug 51452 in initscripts "missing /var/run in root partition fails many services" [Untriaged,Confirmed]  
=== pvanhoof [n=pvanhoof@mailhost.newtec.be]  has joined #ubuntu-devel
=== ploum [n=ploum@ubuntu/member/ploum]  has joined #ubuntu-devel
[11:56] <fabbione> Kamion: 45523 -> rejected. He didn't create a separate /boot and none of our booloaders can boot from lvm
[11:56] <fabbione> not lvm2 at least
[11:57] <\sh> hmmm..how can I see the last uploader of a package in LP?
[11:57] <\sh> hmpf...keybuk is not here :(
[11:58] <fabbione> pitti: score.. upstream is doing it for us :)
[11:59] <dholbach> did anybody remove UniverseFreeze from EdgyReleaseSchedule and the UniverseFreeze wiki page?
=== seb128 [n=seb128@ANancy-151-1-80-237.w81-50.abo.wanadoo.fr]  has joined #ubuntu-devel
=== pounk [n=pounk@142-217-81-161.telebecinternet.net]  has joined #ubuntu-devel
[12:02] <dholbach> ok, the UniverseFreeze page was still there, I linked it from EdgyReleaseSchedule again
[12:06] <Kamion> fabbione: well he says it works fine if he installs the bootloader by hand
[12:06] <Kamion> fabbione: so no, I think rejected would be inappropriate
[12:07] <Kamion> \sh: e.g. https://launchpad.net/distros/ubuntu/+source/sysvinit and look at the "Creator" field
[12:08] <Kamion> it's badly named, but it means "last uploader"
[12:08] <Kinnison> Kamion: No, it means "last person listed in changelog" really
[12:08] <fabbione> Kamion: he is forcing lilo. It will break at the first upgrade. iirc we went trough this in breezy already.
[12:09] <fabbione> (kernel upgrade that's it)
[12:09] <Kinnison> Kamion: the dscsigningkey indicates the uploader really
[12:09] <Kamion> fabbione: *shrug* it's only a matter of re-running lilo. sure, it's not perfect, but I do not think it justifies going around rejecting all bugs about it
[12:09] <Kamion> Kinnison: oh, right, true
[12:10] <Kamion> fabbione: I talked with Adam about that at UDS-Paris, and we noted that folks who've been using lilo forever tend to paranoidly rerun lilo -v after every upgrade anyway, so it's no big deal for them if the kernel upgrade doesn't do it for them
[12:11] <fabbione> Kamion: oh the problem is lilo not understanding a bunch of LVM2 things and break
[12:11] <fabbione> Kamion: but ok.. if you are sure it will work, i am ok with that
=== fabbione -> food
[12:11] <\sh> hmmm..I think in /lib/init/functions.sh: function domount ... the "if mountpoint -q $2" is the problem...
[12:11] <Kamion> well the submitter reckons it works for him once he sets it up by hand ...
[12:12] <Kamion> so I don't really need to be sure :)
[12:12] <pitti> fabbione: wow, that was fast
=== _human_blip_ [n=mike@220.157.65.29]  has joined #ubuntu-devel
=== sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl]  has joined #ubuntu-devel
=== freeflying|away [n=freeflyi@ubuntu/member/freeflying]  has joined #ubuntu-devel
[12:16] <pitti> hey sabdfl!
[12:16] <\sh> moins sabdfl
[12:17] <thom> sabdfl: your talk at AC seems to have gone down well!
=== Zomb [n=eb@x118.rhrk.uni-kl.de]  has joined #ubuntu-devel
[12:17] <tseng> lo thom 
[12:18] <thom> heyhi
[12:18] <\sh> anyone interested in fixing #51452 with me?
[12:19] <pitti> \sh: how did you manage to get /var/run removed?
[12:19] <\sh> pitti: no..I created a separate /var partition....and /var/run is not being mounted at all...
=== Zomb [n=eb@x118.rhrk.uni-kl.de]  has joined #ubuntu-devel
[12:19] <\sh> pitti: if I partition without a separate /var partition everything works fine
=== Hobbsee [n=Hobbsee@ubuntu/member/hobbsee]  has joined #ubuntu-devel
[12:19] <pitti> \sh: ah, ok. Well, that sounds like PEBCAK then - you'll miss /var/lib etc, too
[12:20] <pitti> \sh: ah, I see
[12:20] <pitti> \sh: you created /var in the installer, not in the isntalled system
[12:20] <sabdfl> moin moin \sh, pitti
[12:20] <pitti> bug 51452
[12:20] <Ubugtu> Malone bug 51452 in initscripts "missing /var/run in root partition fails many services" [Untriaged,Confirmed]  http://launchpad.net/bugs/51452
[12:20] <sabdfl> thom: thanks! i didn't get many questions so was a little worried that i put them all to sleep
[12:21] <sabdfl> or didn't fully wake them up after the night before :-)
[12:21] <thom> sabdfl: lots of interest on planetapahce.org 
[12:21] <thom> heh
=== Hobbsee [n=Hobbsee@ubuntu/member/hobbsee]  has joined #ubuntu-devel
[12:22] <\sh> pitti: what I don't understand is the first term in /lib/init/functions.sh: domount() ==> >> if [ ! -d $2 ]   then return fi << means to me, if the directory /var/run does not exists, return to caller. But wouldn't it be better to just create the missing directory then?
[12:23] <pitti> \sh: where is this function called?
[12:23] <\sh> pitti: in mountvirtfs
[12:24] <\sh>  /etc/init.d/mountvirtfs
[12:24] <\sh> # /var may be on another drive so create /var/run if we need to
[12:24] <\sh>         domount tmpfs /var/run "-o mode=0755"
[12:24] <pitti> \sh: hm, but domount is also used for /proc and /sys
[12:24] <pitti> \sh: and an admin might not want these
[12:24] <ogra> \sh, you need to move the data over ... just creating the dir might not be enough ...
[12:25] <pitti> \sh: so instead of changing this in domount(), I'd rather stick a mkdir -p /var/run into it
[12:25] <\sh> ogra: there no data actually, it's while booting the system
[12:25] <pitti> \sh: so the comment clearly doesn't match the code :)
[12:25] <ogra> i.e. /var/run is created in initramfs ... then your kernel boots and fstab is executed and /var is mounted on top of that
[12:25] <ogra> then everything in /var/run that was created before is lost ...
[12:26] <ogra> i thought keybuk had adressed that
[12:26] <\sh> ogra: I don't boot with initramfs...
[12:26] <ogra> that might be your prob then :)
[12:26] <\sh> but it does the same when I used the default kernel
[12:26] <\sh> which I'm doing right now actually ;)
[12:27] <\sh> 2.6.15-23-amd64-server
[12:28] <\sh> pitti: I did "if [ ! -d $2 ]  then mkdir -p $2 fi but it didn't help.
[12:29] <pitti> \sh: (I hope that's a copy&paste bug)
[12:29] <\sh> forget the " and put some \n in ;)
[12:29] <pitti> \sh: hm, if that's a bug in the initramfs stuff, then Keybuk might be the best person to talk to
[12:30] <ajmitch> evening all
[12:30] <pitti> hey ajmitch 
[12:31] <\sh> pitti: the question is, what if I don't use a kernel with initramfs, because I need to use a selfmade kernel, where most of the stuff we need is compiled in...and we don't want to use an initrd.
[12:31] <pitti> \sh: hm, then I don't understand why the mkdir -p doesn't work
[12:32] <sivang> morning
[12:33] <\sh> pitti: well yes, I'm totally confused...think I'll have a smoke and a cup of coffee...and then another try..need to fix it
=== Hobbsee [n=Hobbsee@ubuntu/member/hobbsee]  has joined #ubuntu-devel
=== Hobbsee [n=Hobbsee_@14.5.233.220.exetel.com.au]  has joined #ubuntu-devel
[12:35] <pitti> slomo: libvisual approved
[12:35] <slomo> doko: will you upload python-stdlib-extensions to ubuntu soon or request a sync? we need python-gdbm back ;)
[12:35] <slomo> pitti: thanks :)
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-devel
[12:37] <doko> slomo: it should be automatically synced, there's no ubuntu version
[12:37] <\sh> pitti: I'm installing the machine with another kernel (selfmade)..takes only 30 seconds ;)
[12:37] <slomo> doko: hm, for two other NEW packages i had to file a sync request because they weren't synced automatically
[12:38] <Kamion> it's semi-automatic
[12:38] <Kamion> we have a report on the missing ones
[12:39] <Kamion> nudge Keybuk about it next time he's aroundd
[12:40] <slomo> ok, thanks
=== ealden [n=ealden@203.177.221.62]  has joined #ubuntu-devel
=== ivoks [n=ivoks@ubuntu/member/ivoks]  has joined #ubuntu-devel
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus]  has joined #ubuntu-devel
[12:41] <pitti> hi rodarvus 
[12:42] <rodarvus> good morning
[12:42] <rodarvus> hi pitti
=== irvin [n=ipp@ubuntu/member/irvin]  has joined #ubuntu-devel
=== sabdf1 [n=mark@217.205.109.249]  has joined #ubuntu-devel
=== sabdf1 [n=mark@217.205.109.249]  has left #ubuntu-devel [] 
=== Chipzz [n=chipzz@ace.ulyssis.student.kuleuven.be]  has joined #Ubuntu-Devel
[12:55] <irvin> mvo, can i bother you for a few minutes?
[12:56] <sivang> hey pitti 
[12:56] <pitti> hi sivang 
[12:57] <mvo> irvin: hello, yeah, go ahead
=== netgrabber [i=Baq7J5cq@host237-61.pool8248.interbusiness.it]  has joined #ubuntu-devel
=== Gman [n=gman@nwkea-socks-1.sun.com]  has joined #ubuntu-devel
[01:02] <mdke> pitti: seems that cups-pdf doesn't work out of the box without doing "sudo chmod +s /usr/lib/cups/backend/cups-pdf", do you know if this is easy to solve? (bug #42147)
[01:02] <Ubugtu> Malone bug 42147 in cups-pdf ""PDF Printer" does no not show up in "existing printers" (Dapper)" [Untriaged,Confirmed]  http://launchpad.net/bugs/42147
[01:02] <pitti> mdke: not really, unless you create a directory in your ~ that the cupsys user can write into
[01:02] <mdke> pitti: so chmod +s is a bad solution?
[01:03] <pitti> mdke: well, it's good enough if you know what you are doing
[01:03] <mdke> pitti: what knowledge does it need?
[01:03] <\sh> pitti: it doesn't work either with a selfmade kernel, without initrd and initramfs
[01:03] <pitti> mdke: but I never audited cups-pdf whether it's suitable for suid root operation
=== Lure_ [n=lure@external-7.hermes.si]  has joined #ubuntu-devel
[01:03] <mdke> so we shouldn't really recommend that solution in documentation?
[01:06] <pitti> mdke: hm, no idea, really. If you really need it and don't use gnome apps or OO.o (which can do PDF natively), then, well, it's a good workaround
[01:08] <mdke> pitti: right.
[01:10] <mdke> pitti: thanks!
[01:14] <pitti> Kamion: ok, directfb and libmpeg3 approved for main
[01:15] <mjg59> What are we doing with directfb?
[01:15] <jdub> (*and*... why is libmpeg* still in main?)
[01:16] <fabbione> mjg59: coffee, the and biscuits? ;)
[01:17] <pitti> jdub: libsdl1.2, graphical d-i, gtk 2.10
[01:17] <pitti> mjg59: ^ 
[01:18] <ogra> jdub, ask KDE :P
[01:18] <pitti> jdub: libmpeg3 was in main in hoary, and in universe since then
[01:18] <pitti> jdub: now it comes back due to directfb
[01:18] <ogra> oh, right that was libmad
[01:18] <pitti> jdub: libmpeg3 bad?
[01:20] <mjg59> Ah, right
[01:22] <jdub> some day, graphical d-i will be sane and use kdrive/similar
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-devel
[01:22] <jdub> pitti: patent-encumbered up the wazoo
[01:22] <fabbione> jdub: you really should maintain X a bit before saying somthing like that :)
[01:23] <mjg59> kdrive is pretty straightforward
[01:23] <mjg59> And we've already got it in the archive
=== raphink [n=raphink@ubuntu/member/raphink]  has joined #ubuntu-devel
[01:23] <fabbione> mjg59: how portable is it?
[01:23] <pitti> jdub: so, shall I un-approve libmpeg3, and instead try to build directfb without it?
[01:23] <jdub> and it's not evil/slow/yuck
[01:23] <jdub> pitti: that'd be rad - for edgy, i'd like to get rid of all of them
[01:24] <pitti> ok
[01:25] <ogra> jdub, you cant get rid of libmad as long as KDE is in main
=== Gloubiboulga [n=gauvain@ubuntu/member/gloubiboulga]  has joined #ubuntu-devel
[01:25] <jdub> ogra: we've did it before (fixing xine)
[01:25] <ogra> its deeply woven in ...
=== Fujitsu snips the threads and de-weaves it.
[01:26] <fabbione> ogra: i am pretty sure you can build KDE without libmad
[01:26] <ogra> fabbione, not according to the KDE people i spoke to (i havent looked myself yet)
[01:26] <mjg59> fabbione: Uses framebuffer
[01:26] <slomo> jdub: you will be my hero when you get all the ugly stuff out of main for edgy :)
[01:26] <jdub> if we have to fix a broken KDE attitude towards putting their distributors in jail, then that's what we have to do :-)
[01:27] <Kamion> mjg59: that's much slower though, right? the directfb advocates note that it makes much better use of hardware acceleration
[01:28] <jdub> Kamion: it's all bollocks (based on benchmarks i read last week)
[01:28] <Kamion> and I don't want an X-a-like in d-i any more than the last seventeen times we've talked about this, personally
[01:28] <mjg59> We don't use accelerated framebuffers anyway
[01:28] <jdub> Kamion: up to 10 times slower than GTK+ on X
[01:28] <Kamion> jdub: interesting
=== pitti goes to un-libmpeg3-ify directfb
[01:28] <jdub> Kamion: (and down to 4 times slower, roughly)
[01:29] <Kamion> but anyway, if you want d-i to change, go upstream - I'm not involved in graphical d-i any more, to a good first approximation
[01:29] <jdub> Kamion: (none of the gtk+/gnome embedded folks are planning to use it, based on quite a few independent benchmarks)
[01:29] <mjg59> Kamion: Directfb doesn't support vga16 (so we have problems with compatibility), vesafb is not usefully accelerated, and the specific framebuffers don't tend to work usefully on modern hardware
=== thotz [n=thomas@N848P002.adsl.highway.telekom.at]  has joined #ubuntu-devel
[01:32] <fabbione> do we really care so much about speed in the installer?
[01:33] <fabbione> i mean.. it's not like we are playing quake 4 while we wait
[01:33] <pitti> fabbione: you don't?
[01:33] <pitti> fabbione: just throw a grenade at packages you want installed :)
[01:33] <fabbione> pitti: ahah
[01:34] <fabbione> hmm that would be fun. your system install better as you hit more enemies
[01:34] <fabbione> each time you die a random package is purged
[01:34] <pitti> 'meet the Ubuntu devs in the Quake arena!'
[01:42] <Kamion> fabbione: yes; it's pretty noticeable if the screen takes a large fraction of a second to redraw
=== thotz [n=thomas@N848P002.adsl.highway.telekom.at]  has left #ubuntu-devel [] 
=== WaterSevenUb [n=WaterSev@azevedo.astro.up.pt]  has joined #ubuntu-devel
[01:46] <crimsun> Kamion: is there a failed upload of openvpn for breezy-security?
[01:47] <fabbione> Kamion: yes but again installer is not glxgears ;)
[01:47] <Kamion> fabbione: it's actually pretty noticeable on some hardware even at the moment, and I get bug reports about it
[01:47] <Kamion> though admittedly certain vmware versions are the worst hit - but still
[01:48] <mjg59> Kamion: There's a tradeoff - using vesafb provides other amusing issues
[01:48] <Kamion> crimsun: Rejected: The key used to sign openvpn_2.0.2-1ubuntu0.1_source.changes has expired.
[01:48] <Kamion> mjg59: suspend/resume in the installer is not terribly important :-)
[01:49] <mjg59> Kamion: I thought the reason we used vga16 in the installer was that vesa didn't work on all hardware?
[01:50] <mjg59> At least, I'm sure (you?) gave that as the reason at some stage
[01:50] <Kamion> mjg59: we use either in the installer, depending on vga= parameters
[01:50] <mjg59> Right
[01:50] <Kamion> but yes we do default to vga16fb
[01:50] <mjg59> But directfb forces vesafb
[01:50] <crimsun> Kamion: ok, is there a second upload (also failed)? I signed with my current key for the second upload approximately 16 minutes ago (the previous upload was signed in late May)
[01:50] <Kamion> for the graphical installer, that's not necessarily too much of a problem; the text mode would remain available
[01:50] <mjg59> So we have to invert the current logic
[01:51] <mjg59> Defaulting to vesafb for the installer is arguably saner than defaulting to vga16fb, but I think we need to recheck why that decision was made in the first place
[01:52] <Kamion> I think vga16fb is right for the text mode
[01:52] <mjg59> Why?
[01:53] <Kamion> given the change to 640x400
[01:53] <Kamion> most compatible
[01:53] <mjg59> vga16fb doesn't work on some SIS hardware and is weird on a couple of other machines
[01:54] <Kamion> you lose either way in corner cases, but my impression remains that vga16fb is a better default, particularly as it's what we default to in the installed system and thus gets more testing
[01:54] <mjg59> Yeah
[01:55] <mjg59> I guess supporting graphical d-i at all just seems a bit odd to me, given that we've got Ubiquity
[01:55] <Kamion> I'd like the two to converge in the long run
[01:55] <mjg59> The easiest way of doing that would seem to be to just run Ubiquity in an X session :)
[01:55] <mjg59> As the only client, I mean
[01:55] <jdub> :-)
[01:55] <Kamion> not really, ubiquity isn't internally as flexible
[01:56] <mjg59> Yeah
[01:56] <Kamion> by design, it can't do half the stuff d-i can do
[01:56] <Kamion> hence "converge" rather than "replace"
[01:56] <Kamion> anyway, I don't actually plan to present graphical d-i at least for the next couple of Ubuntu releases
[01:57] <Kamion> but I would like to avoid the merge pain caused by not being able to build core bits of d-i in main
[01:57] <Kamion> having to merge cdebconf all the time is silly
[01:57] <mjg59> Yes, that sounds like a pretty convincing argument
[01:57] <fabbione> Kamion: only for curiosity. what is the status of g-i in Debian?
[01:58] <mjg59> Hm. How hard would it be to hack up a mode for the live CD where it just launches ubiquity in the session rather than a full gnome session?
[01:58] <mjg59> It would help the low-memory case
[01:58] <Kamion> more convincing to me than to anyone else, I suppose, since it's me (or Tollef) who gets to do the work
[01:58] <Kamion> mjg59: yeah, it's been suggested, probably not too difficult; though I know Mark wouldn't want it to be the default
[01:58] <seb128> who is doing syncs nowadays?
[01:58] <Kamion> seb128: me/Keybuk
[01:59] <mjg59> Kamion: Sure
[01:59] <Kamion> fabbione: functional but not polished
[01:59] <seb128> I would appreciate a libcairo 1.2.0 sync from Debian incoming, it's required to package GTK 2.10 which has been rolled this morning
[01:59] <Mithrandir> mjg59: it's quite trivial.
[01:59] <fabbione> Kamion: ok thanks.
[01:59] <seb128> Kamion: should I open a bug about it?
[01:59] <Kamion> seb128: see DeveloperResources for how to request syncs these days
[01:59] <Kamion> yes, please
[01:59] <mjg59> Kamion: Could we put logic in gfxboot to check available RAM and prompt the user for whether they want to install or run a live session?
[01:59] <Kamion> we do syncs in batches
[02:00] <seb128> Kamion: I know, I just have no idea on how fast is the queue processing nowadays and I want to do GTK 2.10 today ... anyway, filling the bug now :)
[02:00] <Kamion> seb128: measured in hours
[02:00] <seb128> cool
[02:00] <seb128> thanks Kamion
[02:00] <Kamion> mjg59: yeah, should be possible
=== Seveas [n=seveas@ubuntu/member/seveas]  has joined #ubuntu-devel
[02:01] <Kamion> though I'm not sure exactly how reliable gfxboot's memory detection is - haven't used it much in anger
=== eggauah [n=daniel@150233.cps.virtua.com.br]  has joined #ubuntu-devel
=== ivoks [n=ivoks@ubuntu/member/ivoks]  has joined #ubuntu-devel
[02:09] <Chipzz> pitti: seriously, I once heard about a quake mod where you could kill processes by shooting them ;)
[02:09] <pitti> Chipzz: heh, me too :)
[02:09] <pitti> 'stand still, damn apache!'
[02:09] <Chipzz> .o0O( Where's that fucking eggdrop hiding? Fucking camper ) ;)P
[02:10] <thom> Chipzz: http://psdoom.sourceforge.net/
[02:18] <sivang> thom: wow
=== Keybuk [n=scott@quest.netsplit.com]  has joined #ubuntu-devel
[02:19] <ogra> hey Keybuk 
=== Hirion [n=hirion@draugr.de]  has joined #ubuntu-devel
[02:21] <Keybuk> heyhey
[02:25] <jdub> mjg59: cool idea
[02:26] <jdub>    * debian/control: Remove libmpeg3-dev build-dependency and dependency to
[02:26] <jdub>      keep jdub out of the jail.
[02:26] <jdub> ha ha
[02:26] <ogra> *g*#
[02:26] <jdub> pitti: thanks for putting my fingerprints *all over it*
[02:29] <fabbione> ahhaha
=== licio [n=licio@ubuntu/member/licio]  has joined #ubuntu-devel
=== lukkett1 [n=lukketto@host173-157.pool8710.interbusiness.it]  has joined #ubuntu-devel
[02:32] <\sh> ah Keybuk
[02:32] <\sh> the man I need
[02:32] <Keybuk> oh aye?
[02:32] <\sh> Keybuk: https://launchpad.net/distros/ubuntu/+source/initscripts/+bug/51452 
[02:32] <Keybuk> it's nice to be needed
[02:32] <Ubugtu> Malone bug 51452 in initscripts "missing /var/run in root partition fails many services" [Untriaged,Confirmed]  
[02:33] <Keybuk> yeah, I saw that one this morning
[02:33] <Keybuk> how did you install dapper?
[02:33] <\sh> Keybuk: via FAI ;)
[02:33] <Keybuk> then it's likely an FAI bug
[02:33] <\sh> Keybuk: I don't know how the reporter installed dapper
=== lukkett1 [n=lukketto@host173-157.pool8710.interbusiness.it]  has left #ubuntu-devel [] 
[02:34] <Keybuk> \sh: aye, just asked him
[02:34] <\sh> Keybuk: but what really bugs me is : if [ ! -d $2 ]  then return fi
[02:34] <Keybuk> the simple answer is that we do make /var/run and /var/lock
[02:34] <Keybuk> the installer makes them
[02:34] <Keybuk> and initscripts postinst makes them on upgrade
[02:35] <\sh> Keybuk: so, creating /var first, then mkdir -p /var/{run,lock} and then installing could solve the problem?
[02:35] <Keybuk> right
[02:35] <Keybuk> that's what we normally do
[02:35] <\sh> thx :)
[02:35] <\sh> as I said, the man I need :)
[02:35] <Keybuk> why does that if statement bug you?
[02:37] <\sh> because if it's not there, it returns to the caller (in this case mountvirtfs) 
[02:37] <Keybuk> right?
[02:37] <\sh> but mountvirtfs should complain in this case
[02:37] <Keybuk> -v please :p
=== epx [n=epx@200.249.192.132]  has joined #ubuntu-devel
[02:38] <Keybuk> why should it complain?  nothing the user can do about it at that point
[02:38] <Keybuk> the complaint will speed past so fast, etc.
[02:38] <\sh> Keybuk: but gives errors later on, e.g. not starting simple networking 
[02:38] <Keybuk> right
[02:39] <Keybuk> what we should have is the error that causes networking not to start to be logged as "/var/run not writable" or something
[02:39] <Keybuk> which makes it doubly obvious what happened
[02:39] <\sh> Keybuk: in my POV it would be better to do a "mkdir -p $2" in this if clause, but this doesn't work when I tested it
[02:40] <Keybuk> root filesystem isn't writable :)
[02:40] <ogra> that at least slows down booting
[02:40] <Keybuk> which is precisely _why_ we have these tmpfs's in the first place
=== holycow [n=a@mail.wjsgroup.com]  has joined #ubuntu-devel
[02:40] <ogra> and what Keybuk said :)
[02:40] <\sh> Keybuk: argh...you are right...
[02:40] <\sh> we aren't at the stage of remounting root rw
[02:40] <StevenK> ogra: Um, I did.
[02:40] <StevenK> ogra: (the windowlab merge)
[02:40] <Keybuk> if the filesystem was writable that early in the boot, we wouldn't need a separately writable /var/run
[02:41] <StevenK> ECHAN
[02:41] <ogra> StevenK, yeah, you missed to change the address in the changelog :)
[02:41] <StevenK> DOH!
[02:41] <ogra> nobody injured :)
[02:41] <\sh> Keybuk: yeah...I missed that...let me check if I can work around that :)
[02:41] <StevenK> Just proves I'm a bozo.
[02:41] <StevenK> ;-)
[02:42] <Keybuk> \sh: you could do a unionfs mount on /var with a tmpfs, make /var/run and /var/lock under that and then mount /var over the top again later
[02:42] <Keybuk> ...oh dear, I appear to be chanelling Tollef <g>
[02:43] <\sh> Keybuk: well, it's easier for me, to create /var/{run,lock} after the partitioning and formatting...
[02:43] <Mithrandir> Keybuk: oh shiny.  You think that'd work? ;-P
[02:43] <Mithrandir> Keybuk: also, unionfs gets very confused if you touch files in the file systems underneath it.
[02:43] <Keybuk> \sh: I believe u6y creates it after formatting, yes
=== fabbione disables crack detector to void extra bans on Keybuk and Mithrandir 
[02:44] <\sh> Keybuk: yes...and my luck is, that the target partitions are mounted rw during install
[02:44] <Keybuk> one would hope the targets were writable during install
[02:44] <Keybuk> otherwise you'd have different problems <g>
[02:44] <\sh> Keybuk: they are :) 
[02:45] <Kamion> Keybuk: yes, it does
[02:45] <Kamion> by virtue of using partman
[02:45] <Kamion> oh, hmm
[02:45] <\sh> Keybuk: and if I solve this little problem, I can get an ubuntu install (desktop) in less then 80seconds :)
[02:45] <Kamion> the KDE frontend does not use partman for everything in the same way that the GTK frontend does - it's possible it doesn't make the directories
[02:46] <Kamion> this is a bug in the KDE frontend
=== \sh hugs Keybuk for opening his blind eyes...
[02:47] <Keybuk> Kamion: interesting ... will see if the bug reporter was using KDE
[02:47] <\sh> I'll ask him 
=== gezenti [n=HRCLITE6@88.229.114.90]  has joined #ubuntu-devel
[02:48] <Keybuk> Lathiat: ping
=== Norgz [n=eroux@maisel-gw.enst-bretagne.fr]  has joined #ubuntu-devel
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-devel
=== nikola [n=pygi@83-131-237-137.adsl.net.t-com.hr]  has joined #ubuntu-devel
=== pygi [n=pygi@83-131-237-137.adsl.net.t-com.hr]  has joined #ubuntu-devel
[02:59] <pitti> jdub: SCNR :)
=== pitti hugs jdub 
[02:59] <Lathiat> Keybuk: pong
[03:00] <Keybuk> Lathiat: was just curious to a bit more technical detail of how the mdns stuff works
[03:01] <Lathiat> Keybuk: shoot
[03:01] <Lathiat> or do you want a general rundown?
[03:01] <Lathiat> or have specific queries?
[03:01] <Keybuk> yup, general rundown of the major components
[03:01] <Keybuk> and how they play together
[03:01] <Lathiat> Well its made up of two things
[03:02] <Lathiat> Multicast DNS and DNS-based service discovery
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net]  has joined #ubuntu-devel
[03:02] <Lathiat> both are basically independant, but complement each other
[03:02] <Lathiat> multicast dns is fairlylike normal dns where
[03:02] <Lathiat> you send a UDP query, in the same format
[03:02] <Lathiat> askign for reecords for a name
[03:02] <Lathiat> and you get replies
[03:02] <Lathiat> the major difference is that instead of asking one serve,r you multicast the request
[03:02] <Lathiat> and everyone with a reply multicasts back
[03:03] <Lathiat> so theres no authorative zone its just an adhoc hi i want this, hi i have that
[03:03] <jdub> pitti: SCNR?
[03:03] <Keybuk> so that is "show me all blah on the network" ?
[03:03] <Lathiat> well that dies into dns-sd
[03:03] <Lathiat> so dns-sd is a method of describing services in DNS
[03:03] <Lathiat> it can run over normal dns too
[03:03] <Lathiat> basically you have records like
=== jdub has unicast dns-sd records on his home domain
[03:04] <Keybuk> is that like the SRV records?
=== Keybuk has a _sip._udp.netsplit.com SRV record
[03:04] <Lathiat> yep
[03:04] <Lathiat> thats _exactly_ the same
[03:04] <Lathiat> thats dns-sd over unicast dns
[03:04] <Lathiat> just you request them over multicast dns in an avahi environment
[03:04] <Lathiat> your _sip._udp would SRv to like
[03:04] <Lathiat> keybuk's phone._sip._udp.netsplit.com
[03:05] <Lathiat> which can also have TXT records and other data
[03:05] <Lathiat> theres also some magic for discovering all types of services running on a network
[03:05] <Lathiat> basically once you start publishing _sip.-udp
[03:05] <Keybuk> right
[03:05] <Keybuk> so how does that work over multicast?  what domain do you use?
[03:05] <Lathiat> you start publishing
[03:05] <Lathiat> _services._dns-sd._udp.local which PTRs to _daap._tcp.local
[03:06] <Lathiat> _workstation._tcp.local etc
[03:06] <Lathiat> bu thats not require in the spec
[03:06] <Lathiat> bu tits usefull for avahi-browse etc
[03:06] <Lathiat> Keybuk: .local is the default
[03:06] <Lathiat> its not restricted to that but thats basically what everyone uses
[03:06] <Keybuk> ok
[03:06] <Lathiat> so over multicast dns you go
[03:06] <Lathiat> "please give me SRVs for _daap._tcp.local"
[03:06] <Lathiat> and all the nmodes respond with
[03:06] <Lathiat> _daap._tcp.local IN PTR lathiat's music._daap._tcp.local
[03:07] <Lathiat> and then you query lathiat's music._daap._tcp local and you get for example
[03:07] <Lathiat> Lathiat\039s\032Music._daap._tcp.local  IN      SRV 0 0 3689 chiana.local ; ttl=120
[03:07] <Lathiat> Lathiat\039s\032Music._daap._tcp.local  IN      TXT "org.freedesktop.Avahi.cookie=4255070712" ; ttl=4500
[03:07] <Lathiat> which basically says its on port 3689 of chiana.local and the TXT data is some extra info
[03:07] <Lathiat> you can put some auxillary info in there that may be usefull at discover time
[03:07] <Lathiat> rather than conneting to the host
[03:07] <Lathiat> for example ichat puts your status in their
[03:07] <Lathiat> away, online, etc
[03:07] <Lathiat> yo udont want to have to connet to just find that out
[03:08] <Keybuk> ok
[03:08] <Keybuk> so how does this tie in to avahi and mdns*, etc.
[03:08] <Lathiat> the cookie is avahi's magical way of determining if two services on different interfaces and/or protocols (ipv4/ipv6) are the same
[03:08] <Lathiat> Keybuk: well avahi is basically what i just described above
[03:08] <Lathiat> rhythmbox asks avahi for _daap._tcp
[03:08] <Lathiat> it broadcasts a query for _daap._tcp.local via mdns
[03:08] <Lathiat> gets the results and passes them back to rhythmbox
[03:08] <Lathiat> it can then choose to go query the indiivudla servers for their SRV/TXT records
[03:08] <Lathiat> etc
[03:08] <Lathiat> you dont need to do that to start tho, e.g.to display a list of shares all you need to do is get the SRVs
[03:09] <Lathiat> as the first label (Lathiat's Music) is the service name
[03:09] <Lathiat> its only once i click on it i need to get the SRV record etc
[03:09] <Lathiat> that saves network traffic et al
[03:09] <Lathiat> in reality theres more in the background like it actually announces when a service comes online
[03:09] <Lathiat> and defends collisions and whatnot
[03:09] <Lathiat> but thats just implementation detail
[03:10] <Keybuk> ok, so avahi does the "discover" part of this?  it's what applications use to find out what's on the network?
[03:10] <Lathiat> yep
[03:10] <Lathiat> avahi-daemon runs and basically proxies between the app and the network
[03:10] <Lathiat> it sends queries and announces its own services
[03:11] <elmo> tuna 14:11 ~ % apt-cache show libgd2-noxpm | grep libxpm
[03:11] <elmo> Depends: libc6 (>= 2.3.4-1), libfreetype6 (>= 2.1.10-1), libjpeg62, libpng12-0 (>= 1.2.8rel), libx11-6, libxpm4, zlib1g (>= 1:1.2.1)
=== Dr4g [n=Dr4g@82-40-234-163.cable.ubr06.uddi.blueyonder.co.uk]  has joined #ubuntu-devel
[03:11] <tortoise_> Does anyone have any tips on how to package python apps?
[03:11] <Keybuk> Lathiat: ah, so what does mDNSresponder do?  or is that the old stuff?
[03:11] <Lathiat> Keybuk: mDNSResponder does the same thing
[03:11] <Lathiat> its just apples versiojn
[03:11] <Keybuk> right
[03:11] <Lathiat> avahi-daemon is what we called ours
[03:12] <Keybuk> so I'm thinking about the whole discoverable/discovery thing
=== jsgotangco [n=jsg123@ubuntu/member/jsgotangco]  has joined #ubuntu-devel
[03:12] <Keybuk> would it be possible to tell avahi-daemon to service application's requests, but not service network requests?
[03:12] <Lathiat> how so?
[03:13] <Lathiat> to query the network but not respond?
[03:13] <Keybuk> exactly
[03:13] <Lathiat> you can tell avahi to disallow publishing
[03:13] <Dr4g> Is most of the Ubuntu development in C ?
[03:13] <Keybuk> so rhythmbox can still look for nearby shares, without actually announcing your own
[03:13] <Lathiat> root@chiana:/etc/avahi# grep disable avahi-daemon.conf
[03:13] <Lathiat> #disable-publishing=no
[03:13] <Lathiat> #disable-user-service-publishing=no
[03:13] <Dr4g> Any C++/python..etc
=== Lathiat nods
[03:13] <Dr4g> Lathiat:: nodding to me ?
[03:13] <Keybuk> when that's disabled, and when applications haven't requested anything, is there a network port open?
[03:13] <Lathiat> Dr4g: no, sorry, keybuk
[03:13] <Lathiat> Keybuk: yes
[03:14] <Lathiat> for avahi to do anything
[03:14] <Lathiat> it has to talk on the network
[03:14] <Dr4g> Okay :o)
[03:14] <Lathiat> its the same as real dns 
[03:14] <Keybuk> right, but why doesn't it open that port when the application makes the request, and then close it after?
[03:14] <Lathiat> when your doing a query port 53 udp is open
[03:14] <Lathiat> :)
[03:14] <Lathiat> Keybuk: because then you miss out on all of the caching etc that makes mdns effecient
[03:14] <Lathiat> and
[03:14] <Lathiat> requests arent 1-time
[03:14] <Keybuk> true, but once you've finished doing the query, the port closes again
[03:14] <Lathiat> they are long term queries
[03:14] <Lathiat> mdsn updates
[03:14] <Lathiat> hosts comes and go etc
[03:14] <Lathiat> thats all handled by listening to the announcements
[03:14] <Lathiat> and goodbyes
[03:15] <Lathiat> and theres no time you can say "you've got all the services now"
[03:15] <Lathiat> you can guess tho
[03:15] <Keybuk> we have "policy exceptions" for DNS and DHCP already
[03:15] <Keybuk> trying to decide whether avahi deserves one or not
[03:15] <Lathiat> for avahi to operate
[03:15] <Lathiat> it raelly needs to be listening all the time
[03:15] <Keybuk> the trouble is, I don't think we can trust avahi's code as much as we can trust libc and dhclient -- which have been around for years
[03:15] <Lathiat> Keybuk: sure
[03:15] <Lathiat> avahi has some advantages in security
[03:15] <Lathiat> chroot(), unprivd user
[03:16] <Lathiat> but that still doesnt stop you from doing things
[03:16] <Lathiat> just helps minmize the damage
[03:16] <Lathiat> we've had 2 issues so far that could have been potentially exploitable iirc
[03:16] <Keybuk> which implies that we should ship with all service discovery off by default
[03:16] <Keybuk> and have a set of options
[03:16] <Keybuk> "discover network services" and "be discoverable yourself"
[03:17] <Lathiat> i mean
[03:17] <Lathiat> theres two issues here
[03:17] <Lathiat> security wise, theres not alot of difference between the two
[03:17] <Lathiat> information disclosure wise, there is
[03:17] <Keybuk> exactly
[03:17] <Lathiat> as i highlighted in my email which i see you read
[03:18] <Lathiat> i guess that would be a resaonable set of options
[03:18] <Lathiat> just promise me no mac-specific allowances or something ;)
[03:19] <Lathiat> i think ekiga advertises without asking
[03:19] <Lathiat> in rhythmbox you have to specifically allow it
[03:19] <Lathiat> i guess a desktop wise setting could be usefull
[03:19] <Lathiat> i wonder if avahi will pay attention to a change in the disable-publishing option and reset all services published
=== Lathiat tries
[03:21] <Keybuk> yeah, from a code-security POV, I don't think we can yet give avahi the same level of trust we give to libc's resolver and dhclient
[03:21] <Keybuk> it just hasn't been around long enough
[03:21] <Keybuk> which leads me to believe we need to be able to turn the network port on and off -- which implies having the daemon on/off
[03:22] <Keybuk> and also from an information-disclosure POV, I think we should give people the option to discover, but not be discoverable themselves
[03:22] <Keybuk> which implies a daemon configuration
[03:22] <jdub> Keybuk: are you analysing nss-mdns (with or without avahi) at this point, too?
[03:22] <Chipzz> Keybuk: avahi is run in a chroot iirc
[03:22] <Keybuk> btw, if an app like rhythmbox decides to do discovery, does the daemon get started anyway?
[03:22] <Keybuk> jdub: not yet, will get onto that later
[03:22] <Keybuk> Chipzz: chroots, nobody users, etc. can all be broken
[03:23] <Lathiat> brb call
[03:23] <sivang> I guess some pycentral breakage is inevitable.
[03:23] <sivang> Setting up python-logilab-common (0.16.1-2) ...
[03:23] <sivang> pycentral: pycentral pkginstall: already exists: /usr/lib/python2.4/site-packages/logilab/common/ureports/__init__.py
[03:24] <sivang> pycentral pkginstall: already exists: /usr/lib/python2.4/site-packages/logilab/common/ureports/__init__.py
[03:24] <sivang> known ?
[03:24] <Keybuk> sivang: file a bug
[03:24] <sivang> Keybuk: sure, I have some more stuf from last night's dist-upgrade, care to let me know which ones are worth a bug or should I just file them all?
[03:24] <Keybuk> sivang: any breakage is worth a bug
[03:25] <sivang> k,
[03:25] <sivang> something I wanted to ask you about yesterday, was:
[03:25] <sivang> Setting up liblockdev1 (1.0.3-1) ...
[03:25] <sivang> /var/lib/dpkg/info/liblockdev1.postinst: line 3: [: : integer expression expected
[03:25] <sivang> cpio: ./lib/udev/path_id: No such file or directory
[03:25] <Keybuk> two bugs there
[03:25] <sivang> (this is how it appeared while I dist-upgraded)
[03:25] <Keybuk> <sivang> /var/lib/dpkg/info/liblockdev1.postinst: line 3: [: : integer expression expected
[03:25] <Lathiat> one of the thigns i want to look at sending patches for
[03:25] <Keybuk> ^ bug in liblockdev1's postinst
[03:25] <Lathiat> is that if avahi is started
[03:25] <Keybuk> <sivang> cpio: ./lib/udev/path_id: No such file or directory
[03:25] <Lathiat> most of the apps arent starting to use it
[03:25] <Keybuk> ^ bug in udev (filed)
[03:25] <Lathiat> avahi has the functionality to wait aroudn for the daemont o start
[03:26] <Lathiat> and start advertising/querying when it does
[03:26] <Lathiat> including if its restarted
[03:26] <Lathiat> thatd be fairly essential to making this work for us
[03:26] <sivang> Keybuk: okay, so I'll only file the one agaisnst liblockdev1 ?
[03:26] <Keybuk> sivang: yup
[03:26] <sivang> k, thanks
[03:26] <Lathiat> unless we want to say "reboot for service discovery to be enabled" :)
[03:26] <Keybuk> Lathiat: I don't think we do :p
[03:26] <Lathiat> sure? i'm sure its the easy way out... :)
[03:27] <Keybuk> rebooting is bad
[03:27] <Keybuk> so, all this works provided you have an IP address on the network?
[03:28] <jdub> *yay d-bus!*
[03:28] <Keybuk> how does it work when you don't?
[03:28] <Lathiat> hrm changing the disable user publishing option 
[03:28] <Lathiat> doesnt work until the daemon is restarted
[03:28] <Keybuk> what assigns the link-local IP?
[03:28] <Lathiat> Keybuk: avahi doesnt
[03:28] <Lathiat> that needs to be done by somethign else
[03:28] <Lathiat> network-manager for example
[03:28] <jdub> zeroconf has improved
[03:28] <Lathiat> or if the interface is up, ipv6 :)
[03:28] <Lathiat> or zeroconf
[03:28] <Keybuk> I've yet to find the code in n-m that actually does link-local :p
[03:28] <Keybuk> ah, yeah, I was going to ask that
[03:28] <Lathiat> it works, i knwo that much
[03:28] <Keybuk> does this work over IPv6 ?
[03:28] <Lathiat> :)
[03:28] <Lathiat> yes
[03:28] <Lathiat> it does
[03:28] <Lathiat> its off on ipv6 by default tho
[03:29] <Keybuk> because IPv6 gives you link-local for free
[03:29] <Lathiat> thats true, buttt
[03:29] <Lathiat> a) the application needs to support it
[03:29] <Lathiat> b) applications that support ipv6 in general will often fail with link local
[03:29] <Lathiat> because
[03:29] <Lathiat> you need to specifically specify the interface to bind to
=== jdub upgrades to IT2006 final
[03:29] <Lathiat> which most apps dont do
[03:29] <Lathiat> altho, you can get that information from avahi
=== j_ack [n=nico@p508DA0E3.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[03:29] <Lathiat> so is supportable in theory
[03:30] <Lathiat> (because the same link local range is on all interface,s by default linux has no idea which one you want)
[03:30] <Lathiat> try ping an ipv6 link local address without -I
[03:30] <Lathiat> and with -I
[03:30] <Lathiat> and you'll see what i mean
[03:30] <Lathiat> it2006?
[03:31] <Keybuk> right
[03:31] <Lathiat> ah
[03:31] <Lathiat> n770 stuff
[03:31] <jdub> Lathiat: 770 foo
[03:31] <Keybuk> jdub: what's new?
[03:31] <Lathiat> who wants to give me a 770? :)
[03:31] <jdub> Keybuk: it's final, so quite a few bugfixes and so on
[03:31] <Keybuk> jdub: I still only see Beta 2
[03:32] <jsgotangco> jdub!
[03:32] <Keybuk> jdub: did they get SIP support yet? :p
[03:32] <jdub> Keybuk: it's behind the maemo download page (ignore the front bits)
[03:32] <jdub> Keybuk: don't think so
[03:32] <Keybuk> meh, will do it later, can't remember its MAC address <g>
=== stub [n=stub@ppp-58.8.1.252.revip2.asianet.co.th]  has joined #ubuntu-devel
[03:33] <jdub> it'll be in your daemon.log :)
=== jsgotangco can only dream for the 770 being available in his place
=== fimbulvetr [n=danv@host-74-28-220-24.midco.net]  has joined #ubuntu-devel
[03:41] <iwj> Keybuk: Would it be possible to make MoM a bit smarter about changelogs which have tails not in standard Debian changelog format ?  ATM it removes blank lines.
=== pounk [n=pounk@142-217-81-161.telebecinternet.net]  has joined #ubuntu-devel
=== jjesse [i=user@69-87-140-127.async.iserv.net]  has joined #ubuntu-devel
[03:43] <jjesse> s
[03:44] <Keybuk> iwj: that should be fixed
=== ploum [n=ploum@ubuntu/member/ploum]  has joined #ubuntu-devel
[03:46] <Keybuk> iwj: oh, hmm
[03:46] <Keybuk> so it's keeping the tail, but removing blank lines from it?
[03:46] <Keybuk> (it used to just drop the tail entirely)
[03:48] <iwj> Yes.
[03:48] <iwj> It's not a huge problem, but it would save a bit of faff fixing it up if it didn't mangle it :-).
[03:48] <Keybuk> will look into it
[03:49] <Keybuk> (have a few bits of "real work" to do first today -- several large merges :-/)
[03:49] <iwj> Fun fun.
[03:49] <iwj> See for example the psutils merge.
[03:49] <iwj> (Nice simple case where the generated package would have been just right otherwise.)
[03:51] <Keybuk> it's pretty easy to fix though -- you have the other source next to you, so can just copy the end of the changelog in
[03:51] <Keybuk> but yes, it's unwanted faff
[03:51] <iwj> Yes, indeed.
[03:52] <Kamion> mjg59: mind if I merge gnu-efi?
[03:52] <Kamion> or possibly sync, still checking
[03:53] <Keybuk> jdub: so, the location for next year's GUADEC is decided?
[03:53] <jdub> Keybuk: b'ham
[03:53] <Kamion> mjg59: indeed, it's a sync
=== ivoks [n=ivoks@ubuntu/member/ivoks]  has joined #ubuntu-devel
[03:54] <Keybuk> jdub: not sure I'll make that one ... it's SO FAR to travel :-/
[03:54] <jdub> heh
[03:57] <Seveas> Keybuk, MoM screw up greek .po files - they look like rubbish in .patch but look good in .diff.gz
[03:57] <Keybuk> Seveas: s/MoM/msgmerge/ :p
[03:57] <Seveas> (see the apollon merge for an example)
[04:07] <seb128> Kamion: do you know if evolution-data-server 1.7 is waiting to NEW or something like that?
[04:07] <ogra>  rss-glx (0.8.0-4) unstable; urgency=low
[04:07] <ogra>  .
[04:07] <ogra>    * I am an idiot. (Closes: #350985)
[04:07] <tseng> seb128: you can see NEW now on launchpad
=== marilize [n=marilize@196.36.161.235]  has joined #ubuntu-devel
[04:07] <seb128> tseng: URL?
[04:07] <tseng> moment
[04:07] <ogra> wow, i didnt know the debian bts has such cool features :)
[04:07] <tseng> its hard to find :P
[04:08] <tseng> https://launchpad.net/distros/ubuntu/edgy/+queue
[04:08] <seb128> tseng: thank you
[04:08] <tseng> np
[04:09] <iwj> Glargh.  The psutils Debian maintainer copied the changelog entry from the patch I sent but forgot to actually apply the change to the source.
[04:09] <Keybuk> ogra: ?
[04:09] <ogra>  rss-glx (0.8.0-6) unstable; urgency=low
[04:09] <ogra>  .
[04:09] <ogra>    * I'm still an idiot. (Closes: #356971)
[04:09] <ogra>  .
[04:09] <ogra> hehe, another one 
[04:10] <ogra> Keybuk, well, bugs that are closed by stating youre an idiot :)
[04:10] <tseng> the feature is Closes:
[04:10] <tseng> not I'm an idiot
[04:10] <Keybuk> tseng: heh, that still has the same bugs as the tool we get :-/  doesn't say what's NEW and confuses i386 and all
[04:11] <tseng> it does say what is NEW
[04:11] <tseng> no?
[04:11] <seb128> could somebody process the new e-d-s then? :)
=== tseng bribes Keybuk to process NEW
[04:12] <Keybuk> tseng: no, just says "here's a changes file with 30 binaries in it"
[04:12] <Keybuk> doesn't tell you which one is the new one
[04:12] <tseng> Keybuk: ah
[04:12] <tseng> right, new binary
=== Keybuk opens up NEW :-/
[04:13] <tseng> dholbach: so, very shortly beagle will ship python2.4-beagle not python-beagle
[04:13] <seb128> Keybuk: e-d-s has a new -common
[04:13] <Keybuk> tseng: for my bribe, I'd like avahi and mono installed by default in edgy please <g>
[04:13] <Kamion> tseng: isn't that going in the opposite direction to current python policy?
[04:13] <Kamion> (see recent debian-devel-announce)
[04:13] <tseng> Kamion: it changed again?
[04:13] <dholbach> tseng: thank you
[04:13] <iwj> Oh, no, I'm wrong, it's using some hideous patch system.
[04:13] <Kamion> tseng: yes, much saner now
[04:14] <iwj> And psutils _has no upstream_ !
[04:14] <tseng> Kamion: goodness, ok.
[04:14] <Kamion> though the changes are a little complex to get your head around at first - but the result is better
[04:14] <Keybuk> iwj: most stuff close to the kernel doesn't
[04:14] <Keybuk> iwj: suggest to jon masters that it should be added to kerneltools.org ?
[04:14] <iwj> No, psutils, not procps.
[04:14] <tseng> Kamion: will review with debian beagle maintainer
[04:14] <Keybuk> iwj: oops :p
[04:14] <Keybuk> iwj: my brain read "ps" and stopped
[04:15] <tseng> Kamion: thanks for the tip
[04:15] <iwj> The maintainer is going to hate me now for messing with this bug and so on.
[04:15] <ogra> isnt procps supposed to die since 2.6 started ? 
[04:15] <ogra> as well as /proc ?
[04:16] <tseng> Keybuk: it sounds like there is a concensus to desktop seed at least f-spot
[04:16] <Keybuk> ogra: no, /proc will always retain the /proc/$PID functionality
[04:16] <ogra> ah
[04:16] <Keybuk> ogra: it's just /proc/$PSEUDO_SYSCTL that's getting phased out
[04:16] <Keybuk> well, actually, what I mean it
[04:16] <Keybuk> /proc/$JUNK
[04:16] <ogra> yep in favor of sysfs
[04:17] <Keybuk> /proc/sys (which is the sysctl interface) might stay
[04:17] <ogra> isnt that just redundant to /sys ? 
=== siriusnova [n=siriusno@r05taknnc.desktop.umr.edu]  has joined #ubuntu-devel
[04:17] <dholbach> who's going to do the gnome-power-manager update?
[04:17] <Keybuk> no, sysctl is things like sys.vm.overcommit_ratio, etc.
[04:18] <ogra> ah
[04:18] <tseng> dholbach: is it simple? :)
[04:18] <Keybuk> /sys is the kernel's kobject tree
[04:18] <dholbach> tseng: look at it :)
[04:18] <tseng> dholbach: i have been running CVS
=== ogra looks for more packages from ari pollack, these changelogs are entertaining :)
[04:18] <dholbach> tseng: you should do the package then :)
[04:18] <tseng> ok we'll see
[04:19] <tseng> can I drop these silly icons?
[04:19] <tseng> upstream has tango
[04:19] <ogra> tseng, you mean the beutiful ones ?
[04:19] <dholbach> tseng: ask Mark
[04:19] <tseng> oh goodness
[04:19] <tseng> I knew there was a catch
[04:20] <dholbach> tseng: does it use proper gtk icon theme support now?
[04:20] <tseng> hm I dont think
=== tseng looks
[04:20] <dholbach> tseng: if so, I can move them to the yet to come human-icon-theme package
[04:20] <dholbach> they shouldn't use hardcoded icons
[04:20] <tseng> should have thought of that last week
[04:20] <tseng> when i could have punched hughsie in the arm
[04:23] <tseng> dholbach: 
[04:23] <tseng> dholbach: /usr/share/icons/hicolor/16x16/apps/gpm-ups-100-charging.png
[04:23] <tseng> /usr/share/icons/hicolor/24x24/apps/gpm-ups-100-charging.png
[04:23] <tseng> looks nice!
[04:25] <dholbach> tseng: then it should be fine to drop them, I'll add them to human (probably) next week
[04:25] <tseng> ok
[04:26] <tseng> alot of patches here to figure out as well
[04:26] <ogra> tseng, could you make a tgz of them and mail them to me ? i'd like to habve them in the gartoon package for edubuntu 
[04:26] <tseng> ok
[04:27] <dholbach> ogra: which ones? the Human ones or the Tango ones?
[04:27] <dholbach> ogra: seems the OLD are lost
[04:27] <ogra> NOOOO !
[04:27] <dholbach> ogra: or somewhere in an old package
[04:27] <dholbach> ogra: or in cvs
=== ogra cries about the beautiful icons
[04:27] <ogra> yeah
[04:27] <ogra> i'll grab them from the breezy package :P
[04:28] <tseng> it is in tseng.ath.cx/~brandon/gpm-icons.tar.gz
=== glatzor [n=sebi@ppp-82-135-72-134.dynamic.mnet-online.de]  has joined #ubuntu-devel
=== gnomefreak [n=gnomefre@ubuntu/member/gnomefreak]  has joined #ubuntu-devel
=== gnomefreak [n=gnomefre@ubuntu/member/gnomefreak]  has joined #ubuntu-devel
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-devel
[04:44] <ogra> tseng, thanks a lot, but these are the new ones already ...
[04:45] <dholbach> doko: do you still know why we wanted to use mcpp for libidl?
[04:45] <pitti> Mithrandir: wrt mailman, I would do the merge now to get it off my list, unless you want to grab it
[04:46] <Mithrandir> pitti: feel free
[04:46] <doko> dholbach: to remove cpp from the live and install CD
[04:47] <dholbach> doko: I see
=== lfittl [n=lfittl@83-65-242-161.dynamic.xdsl-line.inode.at]  has joined #ubuntu-devel
[04:49] <tseng> dholbach: can you help me with this?
[04:50] <tseng> dholbach: i have fixed a few patches already
[04:50] <tseng> 90 is scary, the upstream file is very different
=== freeflying [n=freeflyi@ubuntu/member/freeflying]  has joined #ubuntu-devel
[04:50] <dholbach> tseng: hum, i never looked at it
=== tseng looks who wrote it in the first place
[04:50] <dholbach>  :-)
[04:50] <tseng> Daniel Silverstone
[04:51] <tseng> ugh
=== Arrogance [n=aks@ottawa-hs-206-191-33-120.d-ip.magma.ca]  has joined #ubuntu-devel
[04:52] <tseng> some of these 9x patches are hard to tell since upstream is moved so much
[04:52] <tseng> what do you think?
[04:52] <tseng> i dont want to drop them and piss someone off
[04:52] <ogra> tseng, also note that there might be corresponding patches in gnome-screensaver for some of the g-p-m patches
[04:52] <dholbach> tseng: Kinnison and mjg59 might know better than me
[04:53] <tseng> maybe Kinnison should update it then
[04:53] <tseng> i have merged the gconf patches
[04:53] <tseng> but the C has moved too much for me to do a merge
[04:53] <tseng> bits are entirely gone/changes
[04:54] <dholbach> doko: trying to merge it, it gives 'configure: error: C preprocessor "mcpp" fails sanity check' in pbuilder :-(
[04:54] <tseng> I have it all done besides 9x patches
[04:55] <tseng> if that is useful at all to anyone
[04:55] <tseng> btw
[04:55] <tseng> what is gpm_screensaver_poke called again now?
[04:55] <dholbach> doko: just try to build the dapper version in a edgy pbuilder
[04:55] <tseng> we need a patch for that as well
[04:55] <dholbach> gnome-screensaver-command --poke   ?
[04:56] <tseng> i seem to recall that the name of the function changed recently
[04:56] <sivang> so, I have this merge I'm doing for bittornado, I have one question: One of the build-deps is  python-support (>= 0.3) , and we have in edgy 0.2.3ubuntu1 , should I upload the source with the new dependency , assuming we are anyways getting to python-support (>= 0.3) part of merging from upstream? (debian)
[04:56] <tseng> ioh, that is internal anyway
[04:57] <tseng> if someone wants my WIP let me know, I can't do anything with 9x patches
=== dholbach hugs tseng
[04:57] <tseng> *hugs*, sorry
[04:58] <tseng> a good case for why patches should go upstream
=== Hobbsee [n=Hobbsee@ubuntu/member/hobbsee]  has joined #ubuntu-devel
[05:02] <pitti> sivang: doko wanted to look into merging the newer version, so just hold back the upload for now
[05:03] <mdz> phanatic: pong
[05:03] <mdz> anibal: pong
[05:05] <phanatic> mdz: i just wanted to ask about the thing i posted to the ubuntu-archive list
[05:05] <phanatic> (sysinfo vs. dapper-updates)
=== aitortxo [n=ccpsoeta@sipc87.si.ehu.es]  has joined #ubuntu-devel
=== aitortxo [n=ccpsoeta@sipc87.si.ehu.es]  has left #ubuntu-devel [] 
=== j_ack [n=nico@p508DA0E3.dip0.t-ipconnect.de]  has joined #ubuntu-devel
=== simosx [n=simosx@134.219.176.73]  has joined #ubuntu-devel
=== lbm [n=lbm@82.192.173.92]  has joined #ubuntu-devel
[05:14] <ogra> mdz, i renamed the ltsp upstream branch, can you point https://launchpad.net/people/mdz/+branch/ltsp/ubuntu-main to http://people.ubuntu.com/~ogra/bzr-archive/ltsp/mainline/ ?
[05:14] <Keybuk> phanatic: how many explanations do you need?  you've had three already
=== jpatrick [n=patrick@ubuntu/member/jpatrick]  has joined #ubuntu-devel
=== zenrox [n=zenrox@71.115.198.118]  has joined #ubuntu-devel
[05:15] <phanatic> Keybuk: excuse me, i've pinged mdz before Kamion told me to write to ubuntu-archive. i understand the situation now...
[05:16] <mdz> Keybuk: I was responding to a ping from over the weekend
[05:16] <mdz> ogra: I don't see why I should?  I'll just rename it so that it doesn't say mainline
=== Hobbsee waves to the room
[05:16] <ogra> mdz, ah, so i register a new one then, ok
=== pitti waves to Hobbsee 
[05:17] <lbm> slomo: ping
[05:17] <Hobbsee> hey pitti :)
[05:20] <phanatic> btw is there a dapper-updates approval howto? maybe a wiki page or something like that which describes the process?
=== ompaul [n=ompaul@ubuntu/member/ompaul]  has joined #ubuntu-devel
[05:23] <Keybuk> iwj: coreutils is incorrectly marked as an "Updated Merge" ... could you make sure that one isn't forgotten?
=== MagnusR [n=magru@c83-250-59-127.bredband.comhem.se]  has joined #ubuntu-devel
[05:26] <Hobbsee> phanatic: there might be something in developer resources, in the topic, but they rarely seem to accept updates to the stable version
[05:27] <iwj> Keybuk: noted
[05:27] <Hobbsee> wow, only 759 universe merges to go - that's not really so many
[05:28] <Seveas> Hobbsee, minus a few dozen that I just found out are syncs :0
[05:28] <Hobbsee> Seveas: yeah, exactly, minus the few that we killed off tonight.
[05:28] <Seveas> and minus the hundreds to kill today ;)
[05:29] <phanatic> Hobbsee: thanks. then i'll stop bugging the people and focus on edgy :)
[05:29] <Hobbsee> phanatic: usually a good idea, yeah
[05:30] <Hobbsee> Seveas: yeah, yeah, of course.
[05:31] <jdub> Hobbsee: going to do all 759 before bed time?
[05:31] <Hobbsee> jdub: nah, i dont think so - it wouldnt be a great idea to piss the parents off more than they  already are - which is a lot
=== Hobbsee looks at the rest listed under her.
[05:32] <Hobbsee> bleh.
=== Hobbsee will need to find someone else to upload more of her stuff, in order to do much.  or file sync requests.
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-devel
=== pygi [n=pygi@83-131-234-170.adsl.net.t-com.hr]  has joined #ubuntu-devel
=== KaiL [n=KaiL@p548F57E3.dip.t-dialin.net]  has joined #ubuntu-devel
=== fimbulvetr [n=danv@host-74-28-220-24.midco.net]  has joined #ubuntu-devel
=== Sp4rKy [n=max@lns-bzn-22-82-249-112-229.adsl.proxad.net]  has joined #ubuntu-devel
=== wasabi_ [n=wasabi@ubuntu/member/wasabi]  has joined #ubuntu-devel
=== bmonty_away is now known as bmonty
[05:49] <Hobbsee> jdub: evil.  tempting me with something like doing more merging etc before sleeping.
[05:53] <mjg59> Kamion: Feel free
=== freeflying-g4 [n=freeflyi@221.221.159.138]  has joined #ubuntu-devel
=== Sp4rKy [n=max@lns-bzn-22-82-249-112-229.adsl.proxad.net]  has joined #ubuntu-devel
[06:00] <sivang> pitti: sure thing, thanks
=== Burgwork [n=corey@d66-183-174-128.bchsia.telus.net]  has joined #ubuntu-devel
=== lukaswayne9 [n=lukas@c-68-84-69-12.hsd1.nj.comcast.net]  has joined #ubuntu-devel
=== robertj [n=robertj@66-188-77-153.dhcp.athn.ga.charter.com]  has joined #ubuntu-devel
[06:10] <doko> pitti: Setting up libgphoto2-2 (2.2.1-1ubuntu1) ...
[06:10] <doko>  /var/lib/dpkg/info/libgphoto2-2.postinst: line 21: /usr/share/hal/fdi/preprobe/10osvendor/20-libgphoto2.fdi: No such file or directory
[06:10] <doko> dpkg: error processing libgphoto2-2 (--configure):
[06:10] <doko>  subprocess post-installation script returned error exit status 1
[06:11] <dholbach> doko: any idea how to fix libidl regarding mcpp?
=== ivoks [n=ivoks@ubuntu/member/ivoks]  has joined #ubuntu-devel
[06:14] <doko> dholbach: does the current package build?
[06:15] <dholbach> doko: no, as i said: if you grab the current source and build it in edgy pbuilder it ftbfs
[06:15] <dholbach> 'configure: error: C preprocessor "mcpp" fails sanity check'
=== Sp4rKy [n=max@lns-bzn-22-82-249-112-229.adsl.proxad.net]  has left #ubuntu-devel ["Quitte"] 
[06:19] <ogra> Keybuk, Kamion, 
[06:19] <ogra> <Gadi> I have this issue with an adaptec raid card - seems the install cd used i2o_core and friends, while the installed initramfs wants to load dpt_i2o first
[06:19] <mdz> Keybuk: why shouldn't edgy-artwork be informational?  the actual artwork targets are in separate specs, and the artwork plan is a process document
[06:19] <ogra> do we have a bug open for that  ?
=== Lure [n=lure@ubuntu/member/lure]  has joined #ubuntu-devel
=== cassidy [n=cassidy@153.201-136-217.adsl.skynet.be]  has joined #ubuntu-devel
[06:21] <Keybuk> mdz: umm, it should?
[06:21] <Keybuk> mdz: and it is
[06:22] <pitti> doko: oh, oops; thank you for pointing out
[06:22] <Keybuk> are you confusing edgy-artwork and update-manager-edgy ?
[06:22] <Keybuk> ogra: probably at least a dozne
[06:22] <ogra> oki
[06:22] <ogra> then i wont tell him to file one ;)
[06:22] <pitti> doko: this was a fresh install? this works on dapper upgrades
[06:22] <ogra> Keybuk, thanks
[06:23] <mdz> Keybuk: yes, I confused those emails
[06:23] <Keybuk> mdz: Mark's been annoying and changed the approver on everything
[06:23] <doko> pitti: see the openoffice.org build log
[06:23] <Keybuk> so I don't get e-mails anymore
[06:23] <Keybuk> *sulk*
[06:23] <Hobbsee> Keybuk: you dont get enough emails as it is?  :P
[06:24] <pitti> doko: ah, ok; since the directory is shipped by hal
[06:24] <pitti> doko: but hal is not a dependency; will fix now
=== bmonty is now known as bmonty_away
[06:25] <doko> dholbach: checking how to run the C preprocessor... mcpp
[06:25] <doko> checking if C preprocessor likes IDL... yes
[06:25] <doko> checking if C preprocessor can read from stdin... yes
[06:25] <doko> checking how to ignore standard include path... -I-
[06:26] <seb128> could anybody promote libdirectfb-dev and give a retry to libcairo 1.2.0 build?
[06:26] <iwj> Aaargh I hate patch systems.  They make merges such a PITA.
[06:26] <seb128> that's blocking pango 1.13, GTK 2.10 and most of GNOME 2.15
[06:26] <Kamion> seb128: I'm going to promote it after this publisher run
[06:26] <seb128> Kamion: thank you
[06:26] <doko> works for me, could you have a look at the config.log file of a failed build?
[06:26] <Kamion> Keybuk will need to prod the libcairo build though
[06:27] <iwj> Keybuk: Did you send debian/patches/60_ubuntu-force-clobber-specials.patch (coreutils 5.93-5ubuntu2) upstream to Debian ?  I can't seem to find it in the Debian BTS.
[06:27] <dholbach> doko: hum, I double-check
[06:27] <seb128> I'll ping him when directfb has been promoted :)
=== Tonio_ [n=tonio@tonio.planetemu.net]  has joined #ubuntu-devel
[06:27] <dholbach> doko: did you try in edgy pbuilder?
[06:27] <Keybuk> iwj: I sent it directly to the coreutils list, ages ago
[06:27] <Tonio_> hey
[06:27] <dholbach> doko: i tried on amd64 (if that matters) *try on i386*
=== shackan [n=shackan@85-18-14-13.fastres.net]  has joined #ubuntu-devel
[06:27] <iwj> Keybuk: Aha.
[06:28] <Keybuk> in general, I tend to send patches upstream than to Debian
[06:28] <iwj> Keybuk: IC.  Do you know if they took the patch ?
[06:29] <Keybuk> I never got a reply to the mail, so I guess not
[06:29] <iwj> OK.  I'll chase it up.  Thanks.
[06:30] <iwj> Let me just check the code first ...
[06:30] <Keybuk> iirc, that was the distro sprint patch to fix the fact -f didn't do what it seemed like it should
[06:31] <iwj> Yes.  AFAICT your patch only fixes it for devices and not for fifos.
[06:31] <Keybuk> yeah, I suspect we did "fix the bug, and not other cases"
[06:33] <pitti> doko: libgphoto2 fix uploaded
=== Zdra [n=zdra@159-31.241.81.adsl.skynet.be]  has joined #ubuntu-devel
[06:41] <iwj> Keybuk: I think your patch is quite wrong, really.  It is as if you always said --remove-destination whenever the object to be created is a device.
[06:44] <Keybuk> then you'd need to patch busybox to support --remove-destination
[06:44] <Keybuk> which isn't specified by POSIX
[06:44] <iwj> Err, what ?
[06:45] <Keybuk> the patch was written to fix a problem
[06:45] <iwj> I mean, the supposed behaviour of coreutils cp is fairly clear I think.
[06:45] <Keybuk> we decided the behaviour was wrong
[06:45] <iwj> Eg, if you say    cp -a /dev/null /dev/zero   it ought to refuse.
[06:45] <Keybuk> right, but if you so cp -a -f /dev/null /dev/zero it should not refuse
[06:45] <iwj> If you say    cp -af /dev/null /dev/zero  or   cp --remove-destination /dev/null /dev/zero    it ought to unlink /dev/zero first.
[06:46] <Keybuk> right
[06:46] <Keybuk> that's what the patch does
[06:46] <Keybuk> it makes the former work
[06:46] <iwj> Really ?
[06:46] <Keybuk> which doesn't without the patch
[06:46] <iwj> Yes, but the behaviour doesn't seem to depend on -f.
[06:46] <iwj> And -f means `try again with an unlink if it fails', not `always unlink it'.
[06:47] <Keybuk> it only comes into play with -f, due to some random flow through that code
[06:47] <iwj> (I'm not sure why there are two different options.)
[06:47] <iwj> Joy.
=== gnomefreak [n=gnomefre@ubuntu/member/gnomefreak]  has joined #ubuntu-devel
[06:47] <Keybuk> without -f, it never reaches that bit anyway
=== thesaltydog [n=fabio@ubuntu/member/thesaltydog]  has joined #ubuntu-devel
[06:52] <iwj> Keybuk: Not quite true.  There's a race.  If you    cp -a /dev/null foo & cp -a /dev/null foo   then both can succeed.
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-devel
=== imbrandon [n=brandon@ubuntu/member/pdpc.active.imbrandon]  has joined #ubuntu-devel
=== highvoltage [n=jono@mtngprs7.mtn.co.za]  has joined #ubuntu-devel
=== ivoks [n=ivoks@ubuntu/member/ivoks]  has joined #ubuntu-devel
[07:13] <iwj> ogra: coreutils patch 99a_fix_cp_manpage in 5.93-5ubuntu3 edits cp.1 but cp.1 is an output file.  Did you know that ?  The thing you were trying to fix seems to be addressed in Debian #351601.
[07:13] <Ubugtu> Debian bug 351601 in coreutils "Subject: coreutils: minor formatting issue in the mv an cp manpages" [Minor,Open]  http://bugs.debian.org/351601
=== OculusAquilae [n=oculus@pD9509CE3.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[07:14] <ogra> iwj, if debian adresses it, feel free to drop it :)
[07:14] <iwj> Yes, I will :-).  But I thought I should point out your mistake in a spirit of education :-).
[07:16] <highvoltage> :)
[07:19] <iwj> Anyway, I have to go and have dinner.
=== j_ack [n=nico@p508DA0E3.dip0.t-ipconnect.de]  has joined #ubuntu-devel
[07:20] <dholbach> me too
[07:42] <Kamion> The localechooser merge is making me lose my sanity. I'm off for dinner before it all disappears entirely.
[07:42] <Keybuk> swap you for sysvinit :p
[07:43] <Kamion> no deal
[07:44] <thom> Keybuk: you have no sanity left to lose, colin is a more serious matter 
[07:44] <thom> ;-)
[07:44] <highvoltage> colin is sanity personified.
[07:45] <mdz> ogra: you should make yourself a bug contact for fuse
=== ChipX86|Sleep is now known as ChipX86
[07:45] <Keybuk> I reckon jdthood examined our changes carefully, and then deliberately changed the Debian package in ways that would make this merge annoying <g>
[07:45] <Keybuk> like he's reindented a bit we changed, for no other readily apparent reason
[07:46] <ogra> mdz, will do
[07:51] <ogra> ugh, how did that makedev rubbish get in there .... 
=== RadiantFire [n=ryan@c-69-180-43-27.hsd1.ga.comcast.net]  has joined #ubuntu-devel
[08:02] <Keybuk> oh, that's kinda annoying
[08:02] <Keybuk> new-mom drops an Ubuntu change to a file Debian removed, rather than flagging it
=== sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl]  has joined #ubuntu-devel
=== sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl]  has left #ubuntu-devel [] 
=== jdub sucks down edgy
[08:09] <crimsun> Keybuk: out of curiosity, do -security pull from a different keyserver? My uploads to breezy-security are failing due to key expiration, but I'm using the same key that I use to sign uploads to Edgy (which are accepted).
[08:10] <Keybuk> crimsun: not sure, -security goes down a different path
=== siriusnova [n=sirius@r05taknnc.desktop.umr.edu]  has joined #ubuntu-devel
[08:12] <siriusnova> hello
=== shackan [n=shackan@85-18-14-13.fastres.net]  has joined #ubuntu-devel
=== shackan [n=shackan@85-18-14-13.fastres.net]  has joined #ubuntu-devel
=== raphink [n=raphink@ubuntu/member/raphink]  has joined #ubuntu-devel
[08:40] <crimsun> fabbione: anibal has prepared merged nfs-utils at http://users.monash.edu.au/~anibal/ubuntu/nfs-utils/ . They look sane to me.
=== RadiantFire [n=ryan@c-69-180-43-27.hsd1.ga.comcast.net]  has joined #ubuntu-devel
=== pounk [n=pounk@142-217-81-164.telebecinternet.net]  has joined #ubuntu-devel
=== beezly [n=andy@83.148.168.219]  has joined #ubuntu-devel
=== johanbr [n=j@d154-20-189-105.bchsia.telus.net]  has joined #ubuntu-devel
[09:07] <ogra> Kamion, mind if i merge makedev (its only 3 lines in postinst to merge)
=== lucas [n=lucas@ubuntu/member/lucas]  has joined #ubuntu-devel
=== ubijtsa [n=ubijtsa@karlsson.force9.co.uk]  has left #ubuntu-devel ["leaving"] 
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net]  has joined #ubuntu-devel
=== mdke [n=matt@unaffiliated/matt/x-000000001]  has joined #ubuntu-devel
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-devel
[09:25] <Laser_away> can a reviewer please look at https://launchpad.net/distros/ubuntu/+spec/edubuntu-dynamic-menus ? Thanks
[09:26] <Burgwork> Laser_away, I will look at it, but I am not a reviewer
[09:29] <Burgwork> Laser_away, "A standard location/format for determining the user -> group mapping will be used so both Gnome's sabayon and KDE's kiosk tool frontends can access the same groups."
[09:29] <Burgwork> Laser_away, that part is not clear to me
[09:30] <Riddell> Laser_away: kisoktool spelt wrong
[09:31] <Burgwork> Riddell, to the sharks, eh?
[09:31] <Riddell> "A standard location/format.." that would require quite major and incompatible changes to kiosk
[09:32] <crimsun> unless he means to develop a proxy...do you?
[09:33] <Burgwork> how does kiosk work?
[09:33] <Burgwork> does it set keys in kconfig?
[09:33] <Riddell> Laser_away: you might also be interested in https://wiki.kubuntu.org/KubuntuKioskProfiles
[09:33] <Riddell> Burgwork: it does indeed
[09:33] <Laser_away> Riddell: well, I talked to aaron about it
[09:33] <Burgwork> is that not a stand place?
[09:33] <Burgwork> if for no other reason, gconf and kconfig should be merged because of all the duplicate lockdown stuff
[09:34] <Riddell> Burgwork: the use to profile mapping is done in /etc/kderc, presumably sabayon doesn't use that file
=== slomo [n=slomo@ubuntu/member/slomo]  has joined #ubuntu-devel
[09:34] <Riddell> user to profile
[09:34] <Burgwork> it uses a .zip based format to define keys within it
[09:35] <tseng> hi Burgwork 
[09:35] <Burgwork> hey tseng 
[09:36] <Burgwork> you know what is really sad? My company has 4+ years of experience with locking down linux public computers and yet we are unwilling to share
[09:39] <Laser_away> well, the idea was to at least allow kiosktool and sabayon to be able to share user->group/profile mappings
[09:40] <Laser_away> what we want is for Edubuntu to be able to have group driven menus
[09:40] <Burgwork> Laser_away, just the mappings, not the actual settings?
[09:40] <Laser_away> sabayon seems to be the way to do that
[09:41] <Laser_away> at least mappings
=== dholbach_ [n=daniel@i577B3070.versanet.de]  has joined #ubuntu-devel
[09:41] <Burgwork> to me, the implementation is still not very clear
[09:41] <Laser_away> settings might depend on DE if it is more than just menus
[09:41] <Burgwork> maybe but that stuff there about what exactly needs to be common and what can't be/shouldn't be
[09:42] <Burgwork> Laser_away, you should also chooose profiles or .menus. I don;t know if you have, but the spec seems to indicate that the decision was still up in the air
=== beezly [n=andy@83.148.168.219]  has joined #ubuntu-devel
=== pvanhoof [n=pvanhoof@d54C0E27E.access.telenet.be]  has joined #ubuntu-devel
=== pygi [n=pygi@83-131-242-202.adsl.net.t-com.hr]  has joined #ubuntu-devel
=== HiddenWolf [n=HiddenWo@136.184.dynamic.phpg.net]  has joined #ubuntu-devel
[09:58] <Kamion> ogra: Mithrandir said he was doing makedev
[09:59] <Kamion> he said "I've prodded bdale to take our final change to makedev, so you don't need to think about that merge."
[10:00] <Kamion> feel free to do it if you just want to get it off the list though - but sounds like it should turn into a sync
[10:01] <ogra> yeah, if bdale added the change ... its just that fuse seems to need a newer one ...
=== ivoks [n=ivoks@ubuntu/member/ivoks]  has joined #ubuntu-devel
[10:05] <Keybuk> oh, joy
[10:05] <Keybuk> I just accidentally wiped a merge that's taken me most of the afternoon
[10:05] <Keybuk> *sigh*
[10:05] <pygi> Keybuk, :-/
[10:06] <Keybuk> oh well, hopefully my brain is still fresh and I can resurrect it from memory
[10:07] <mjg59> Do we have magic OLPC images anywhere?
[10:08] <rodarvus> what are magic OLPC images?
[10:09] <mjg59> One Laptop Per Child
[10:10] <mjg59> Someone's looking at customising Ubuntu for the boards, but I don't know how far things have got
[10:11] <rodarvus> I know what OLPC means :)
[10:12] <rodarvus> afaik, no one is working on an Ubuntu OLPC image - yet
[10:13] <rodarvus> a few Ubuntu developers (me included) have subscribed to the developer program
[10:14] <Kamion> ogra: feel free to go ahead then
[10:14] <mjg59> rodarvus: Yes, I have one of the boards
[10:14] <rodarvus> mjg59, nice!
[10:15] <rodarvus> mjg59, do you have other plans for it, or want to have Ubuntu running on the board?
[10:15] <mjg59> I'm doing power management stuff on it
[10:17] <sladen> all of the power-management?
[10:18] <mjg59> Well, that sort of depends what already works...
[10:18] <Burgwork> rodarvus, you are doing X stuff for Canonical, no?
[10:19] <rodarvus> Burgwork, right
[10:19] <Burgwork> ah, cool
[10:20] <ogra> Kamion, done, thanks for all the info
=== bluefoxicy [n=bluefox@c-68-33-112-13.hsd1.md.comcast.net]  has joined #ubuntu-devel
[10:21] <Kamion> Keybuk: I'm trying to grok the bit in replacement-init about level events
[10:21] <Kamion> "Level events are just edge events that have a string value associated with them, e.g. "up" and "down". Any change in the value triggers an edge event of the same name."
[10:21] <Kamion> Keybuk: shouldn't that be "triggers a level event" - or am I missing something?
[10:22] <Keybuk> hmm, not describing that very well there
[10:23] <Kamion> Keybuk: where does the init daemon's event socket reside?
[10:23] <Kamion> presumably has to be somewhere guaranteed to be on /
[10:23] <Keybuk> Kamion: undecided, might just use a named unix socket
[10:23] <Kamion> '
[10:23] <Kamion> k
[10:23] <Kamion> I hate my k key
[10:24] <Keybuk> ok, tweaked that paragraph
[10:24] <Keybuk> "Level events are just like edge events, except that they also have a string value associated with them, e.g. "`up`" and "`down`". Any change in the value triggers the level event with that value associated, and an edge event of the same name (without any value)."
[10:25] <Kamion> ah ok, though I wonder how useful such edge events would be in practice
[10:25] <Keybuk> e.g. "on power" (whenever power state changes) vs. "when power is battery" or something
[10:25] <Kamion> fair enough
[10:25] <Keybuk> they're most useful for the associated stop events
[10:26] <Keybuk> start when power is battery ... stop on power  (whenever it changes to something else)
[10:26] <Keybuk> which is just "while power is battery" <g>
[10:26] <Kamion> the fs repair console case is interesting - might want to provide for a way to make init stop reacting to events while the repair console is active
[10:26] <Kamion> I'd be a bit freaked out if I were trying to put my system back together from sulogin and init started randomly doing stuff
[10:26] <Keybuk> yeah, that's special-case'd in ordinary init too
[10:27] <Kamion> your XML config file example has unbalanced tags ;)
=== Keybuk hates XML
[10:27] <Kamion> ich auch
[10:28] <Kamion> it occurs that having "reload"/"restart" or whatever in addition to "start" and "stop" might be useful in the future
[10:28] <Keybuk> restart is actually in there, I think
[10:28] <Keybuk> yeah it is
[10:29] <Keybuk> mentioned under the state machine description
[10:29] <Kamion> "restart dhcpd whenever list of interfaces change"
[10:29] <sladen> Keybuk: "edge events just show change, level events show change to a _particular state_ which is provided as an accompanying string such as 'up' or 'down'."
[10:29] <Kamion> ah, ok, hadn't got that far yet
[10:29] <bluefoxicy> Keybuk or Kamion, which one of you knew the linker intimately, and are you going to be not busy enough to talk to me in #-offtopic when I get back from mcdonalds?
[10:30] <Keybuk> bluefoxicy: not right now, maybe later
[10:30] <sladen> bluefoxicy: it might be useful to say what you're actually trying to do
[10:30] <bluefoxicy> sladen:  Offtopic stuff, I'm writing an article on prelink and want to make sure I've described things like the relocation process properly et al, hence why #-offtopic
[10:31] <Kamion> bluefoxicy: not me
[10:31] <bluefoxicy> anyway there's real work going on so I'm gonna go for a bit, maybe later.
[10:31] <sladen> bluefoxicy: then post a link to the wiki page
[10:31] <bluefoxicy> sladen:  it's not on the wiki
[10:32] <sladen> bluefoxicy: then how are you going to show people to ask for comments?
=== bluefoxicy slips out for a few
=== Zdra [n=zdra@223-24.241.81.adsl.skynet.be]  has joined #ubuntu-devel
[10:40] <sivang> Since it's getting close to spec approval dead line, I'd like to know about my two specs, home-user-backup, and make-free-space-wizard. Are they still pending in the reviewers queue ?
[10:40] <Kamion> Keybuk: your state machine is missing transitions for Waiting->Starting and Waiting->Stopping (I'm assuming the former is == Stopped->Starting and the latter is a no-op); also I think your Stopped->Waiting transition is bogus
[10:41] <Keybuk> let me check
[10:42] <Keybuk> heh
[10:42] <Keybuk> I must have badly C&P'd that
[10:42] <Kamion> Keybuk: with regard to non-root user events it might be worth referring people to userv if they want cross-user functionality (or studying the measures it takes if you want to do it in upstart)
[10:42] <Keybuk> I was fighting moin's formatting for that bit
[10:42] <Keybuk> Waiting->Stopping is definitly a no-op
[10:42] <Kamion> presumably also Stopping->Stopped
[10:42] <Keybuk> aha!
=== ompaul [n=ompaul@ubuntu/member/ompaul]  has joined #ubuntu-devel
[10:43] <Keybuk> first thing is supposed to be Waiting to Starting
[10:43] <Keybuk> (starting->waiting is a no-op)
[10:43] <Kamion> in particular I remember that userv is very careful to sanitise file descriptors
[10:44] <Kamion> you mention file descriptors being left open in one of your use cases, but don't address what you're going to do about it
[10:44] <Keybuk> Kamion: that's more an edgy+1 fix
[10:45] <Kamion> ok, wanna note that?
[10:45] <Keybuk> trying to split a spec across multiple releases, while retaining enough to describe the intent is hard :p
[10:45] <Kamion> understood
[10:45] <Kamion> it's just 'cos it's in the use cases
[10:45] <Kamion> your configuration file format reminds me of fetchmail ;-)
[10:46] <Keybuk> yes
[10:46] <Kamion> (whether this is a good thing or a bad, I'm not sure)
[10:46] <Keybuk> it's actually just supposed to be a pseudo-format in the spec, to give you an idea of the functionality, rather than the actual format -- because I haven't yet put too much thought into that; as the edgy package will just ship set config files anyway and no other package will
[10:46] <mdz> Keybuk: I'm seeing .po file changes I can't attribute in MOM output (e.g., netbase)
[10:46] <Keybuk> but it did come out looking very fetchmailish
[10:47] <Kamion> yeah, you'd want to deal with stuff like quoting of 'end script'
[10:47] <Kamion> but noted that it's pseudo
[10:47] <mdz> it seems unlikely that we would have messed with those at all, but there's a delta
[10:47] <mdz> it's not in netbase_4.24ubuntu3.patch, so I don't think it came from the package itself
[10:47] <mdz> something with the .po file merging?
[10:48] <Keybuk> mdz: msg* likes to reflow strings
=== givre [n=flo@APuteaux-152-1-53-214.w82-120.abo.wanadoo.fr]  has joined #ubuntu-devel
[10:49] <Kamion> I think --no-wrap suppresses that although I suspect if you passed that to everything it would *never* wrap even though it should
[10:49] <Kamion> don't think there's a way to say "wrap iff it was already wrapped"
[10:50] <sivang> mdz: should I be waiting for review feedback to come about my two specs, or am I missing some info  on the LP spec page for it to be reviewed? (I applied all fixes as noted by previous reviews)
[10:51] <Kamion> damn, I'd better finish ubiquity-advanced-partitioner
[10:53] <Keybuk> the spec, or the code? :p
[10:53] <Kamion> the spec - haven't started yet
[10:53] <Kamion> (on the code)
=== sivang hopes he's not bugging, it's just that spec approval dead line is getting closer, and he would like to know the fixes he needs to apply sooner then later.
[10:58] <gnomefreak> the issues with ubiquity is from python2.4-* (biggest issue) right?
[11:00] <Kamion> gnomefreak: no
[11:01] <Kamion> I'm not even sure what that might mean :)
[11:01] <gnomefreak> oh ok 
[11:02] <Kamion> gnomefreak: are you extrapolating from all the crashes being python tracebacks?
[11:02] <gnomefreak> yes
[11:02] <Kamion> gnomefreak: ubiquity is written in python, so of course all its crashes will be python tracebacks
[11:02] <gnomefreak> and im connected that with the python changes
[11:02] <gnomefreak> ah
[11:02] <Kamion> that doesn't mean it's python's fault
[11:02] <gnomefreak> didnt know it was python code
[11:03] <Kamion> at any rate the frontend is python, if not all of the backend
[11:03] <Keybuk> whew
[11:03] <Keybuk> had enough brain-state to redo the merge in just an hour
[11:04] <Kamion> if somebody would like to review ubiquity-advanced-partitioner, that'd be welcome
[11:05] <Keybuk> sure
[11:05] <Kamion> the UI description is unfortunately in text but I think my textual description of a UI will actually be more legible than any drawing I might try to produce :)
=== pitti [n=pitti@ubuntu/member/pitti]  has joined #ubuntu-devel
=== Cran1988 [n=Cran1988@ppp047-077.dsl.hol.gr]  has joined #ubuntu-devel
=== Cran1988 [n=Cran1988@ppp047-077.dsl.hol.gr]  has left #ubuntu-devel ["Leaving"] 
[11:14] <dholbach> good night
[11:14] <sivang> night dholbach 
[11:14] <dholbach> night sivang
[11:28] <LaserJock> Keybuk: ping?
[11:29] <LaserJock> anybody know if new packages in Sid are being automatically included still?
[11:30] <Kamion> Keybuk: would appreciate sanity-check of seed-cleanup too
[11:30] <Kamion> LaserJock: yes, semi-automatically
[11:30] <Keybuk> LaserJock: they have never been automatically included
[11:30] <Kamion> there's a script that tells us which ones are new
[11:30] <Keybuk> unless you could me (and previously, elmo) being an automated process <g>
[11:30] <LaserJock> Keybuk: I do ;-)
[11:31] <Keybuk> Kamion: there WAS a script <g.
[11:31] <Keybuk> rm $VAR_* is dangerous, m'kay
[11:31] <LaserJock> until Paris I has serious concerns that you and elmo were cron jobs ;-)
[11:31] <LaserJock> just kidding
[11:31] <Keybuk> the script was just taken out of my .bash_history anyway
[11:32] <LaserJock> how often are the new ones included? I got an email from a DD that wants to make sure his new packages are included in Edgy
[11:32] <Kamion> Keybuk: d'oh
[11:32] <Kamion> can you put it back in a less dangerous directory? :)
[11:32] <Kamion> like, er, ~/bin
[11:32] <Keybuk> Kamion: yeah
[11:34] <Keybuk> put it back now :p
[11:34] <Keybuk> I've moved sync-source into ~/bin as well
[11:34] <Kamion> ta
[11:35] <Kamion> hmm, duh, just occurred to me that germinate would probably be a whole lot faster if I made stuff like self.all be sets rather than lists
[11:35] <Keybuk> LaserJock: I haven't done new stuff in a week or so though
[11:35] <Keybuk> there's a bunch of crap in there I need to get my head around
[11:36] <Keybuk> was waiting for some merges to happen too
[11:36] <LaserJock> yeah, I can imagine
[11:36] <Keybuk> and almost a third of it is X
[11:36] <LaserJock> fun
[11:36] <Keybuk> I may just forcibly sync X, to see if it motivates anyone into caring about it <g>
[11:37] <Keybuk> (actually, I plan to do some of it myself)
=== Dr4g [n=Dr4g@82-40-234-163.cable.ubr06.uddi.blueyonder.co.uk]  has joined #ubuntu-devel
[11:59] <Keybuk> holy fuck, what happened to vim?!
[12:00] <Kamion> let me guess, you ran into debchangelog folding?
[12:00] <Keybuk> yes
[12:00] <Keybuk> how do I make it not do that?
[12:00] <Kamion> au BufEnter * if &filetype == "debchangelog" | setlocal foldlevel=1000 | endif
[12:00] <Kamion> not sure that's perfect but it's what I have
=== ChipX86 [n=chipx86@galago/ChipX86]  has left #ubuntu-devel [] 
[12:01] <pitti> autocmd FileType debchangelog :set nofoldenable
[12:01] <pitti> Kamion, Keybuk: ^
[12:01] <pitti> (my solution, looks a bit cleaner)
[12:01] <Kamion> hmm, yeah, that would work too
[12:01] <pitti> but I feel this should be the default
[12:02] <pitti> right now it's horribly confusing OOTB
[12:02] <pitti> (IMHO)
=== Hirion [n=hirion@draugr.de]  has left #ubuntu-devel [] 
=== dborg [n=daniel@e182052196.adsl.alicedsl.de]  has joined #ubuntu-devel
=== jono [n=jono@88-107-12-0.dynamic.dsl.as9105.com]  has joined #ubuntu-devel
[12:05] <jono> hey
[12:06] <Keybuk> hey Mr O'Bacon!
[12:06] <Keybuk> how was GUADEC?
=== givre_ [n=flo@APuteaux-152-1-17-224.w82-120.abo.wanadoo.fr]  has joined #ubuntu-devel