[12:07] <elmo> it's using 37M and I only killed it last week
[12:07] <Keybuk> yeah
[12:07] <Burgwork> elmo, there is a thread on planet gnome about just that
[12:09] <elmo> 45406
[12:09] <elmo> or #45406 or LP#45406 or whatever gets the stupid bot to trigger
[12:09] <Keybuk> bug #45406
[12:09] <Ubugtu> Malone bug 45406 in gnome-cups-manager "memory leak in gnome-cups-icon" [Medium,Confirmed]  http://launchpad.net/bugs/45406
[12:10] <Keybuk> it actually goes to 128MB or so instantly for me
[12:11] <Keybuk> though, curiously, I can't see why in the pmap
[12:20] <BenC> jdub: pong
[12:27] <Burgwork> BenC, jdub was talking about an atheros module issue, don;t know if that is why he pinged you
[12:30] <jdub> BenC: i had to do some insmodding to get the ath_pci driver dependencies to load correctly - looked like new_wlan was being loaded, which stops (the correct module) wlan and ath_pci from loading
[12:31] <BenC> new_wlan?
[12:31] <BenC> this is all linux-restricted-modules?
[12:32] <jdub> new_* are madwifi-ng
[12:32] <BenC> jdub: is this on edgy or dapper?
[12:32] <jdub> the only lrm stuff is (new_)ath_hal
[12:32] <jdub> edgy 2.6.17
[12:32] <BenC> ok, weird, nothing changed in lrm for 2.6.17
[12:51] <anibal> how can I add an edgy spec about NFSv4?
[12:52] <LaserJock> anibal: https://launchpad.net/distros/ubuntu/+specs ?
[12:54] <anibal> LaserJock, thank you
[12:58] <Seveas> anibal, it's too late for edgy specs, final round of approvals will be in <48 hours
[12:58] <Seveas> (doesn't mean you can't work on it for edgy though ;))
[12:58] <neuralis> Seveas: it's not too late for uncontroversial specs.
[12:58] <Seveas> neuralis, true
[12:59] <Seveas> nfsv4 would be a nice thing to have
[01:16] <anibal> Seveas, https://launchpad.net/distros/ubuntu/+spec/nfsv4
[01:16] <anibal> Seveas, all the package are already in edgy
[01:16] <anibal> packages
[01:16] <Seveas> anibal, then why a spec?
[01:17] <anibal> because it will be a good feature for the next release
[01:18] <Keybuk> I'm confused
[01:18] <Keybuk> is the spec implemented?
[01:18] <Seveas> apparently yes
[01:18] <anibal> Keybuk, yep
[01:19] <Seveas> anibal, specs generally are use for tracking implementation, writing them after all is done is not too useful 
[01:19] <Keybuk> anibal: probably doesn't really need one then
[01:19] <Keybuk> we tend to use a spec for when we have to do something hard
[01:19] <anibal> should I remove my spec then?
[01:21] <Burgwork> Keybuk, the droppage of all the python stuff from -meta. Was that due to the python migration or a policy decision?
[01:22] <Keybuk> policy decision
[01:23] <Keybuk> edgy will include a standard python runtime environment, rather than everything python related
[01:23] <Keybuk> in practice, this is sufficient for everything
[01:23] <Keybuk> (and deps drag in anything with synaptic anyway)
[01:24] <LaserJock> too bad, I enjoyed the "WTF is all of python doing on the install CD" threads ;-)
[01:26] <Burgwork> Keybuk, ok, just wondering
[01:28] <Keybuk> lifeless: biff (sorry it took ages :p  wanted to give the e-mail some brain time)
[01:36] <jsgotangco> good morning
[01:57] <neuralis> robertj: ping
[01:57] <robertj> pong
[01:57] <robertj> afk for 60 seconds though
[01:58] <neuralis> what of the avahi tree actually runs as a server?
[01:58] <neuralis> just avahi-daemon?
[01:59] <Riddell> it's not really a server
[01:59] <neuralis> Riddell: by "server", i mean "listens on a port". i'm being lazy, and don't want to read the whole source.
[02:00] <Riddell> yes, only avahi-daemon
[02:00] <Riddell> and it doesn't listen on a port such that nmap will find it, for example
[02:00] <robertj> neuralis: that's my understanding of it
[02:25] <neuralis> robertj: do you know if any developers are online?
[02:25] <robertj> neuralis: nope, I'd suppose there is probably an #avahi somewhere
[02:27] <neuralis> robertj: i spent half an hour looking at the code. i have some questions, but i'm largely satisfied with what i've seen.
[02:28] <neuralis> robertj: if my concerns were addressed (or shown invalid), i would not oppose a policy exception on security grounds.
[02:29] <robertj> any thoughts about the spec itself?
[02:29] <neuralis> let me look..
[02:29] <robertj> https://launchpad.net/distros/ubuntu/+spec/zeroconfpolicy
[02:30] <neuralis> yeah, i have the link.
[02:31] <neuralis> points 1 and 3 of the implementation plan are debatable.
[02:32] <Keybuk> I would *highly* recommend your spec includes an alternate plan that did not require an open port policy exception
[02:32] <Keybuk> otherwise your spec is almost certainly likely to be rejected
[02:32] <robertj> Keybuk: that's the whole point of the spec though, there are other non-policy specs out there
[02:33] <neuralis> Keybuk: i'm actually warming up to the idea. it's very likely that there's no reason to not grant an exception on security grounds, in which case only things like the slippery slope argument, etc, apply. those are still valid, obviously, but far less potent than a "this is insecure" argument.
[02:35] <Keybuk> neuralis: of the three people whose ultimate decision it is, two are unhappy that dhcp requires an open port and would rather that was fixed ... so I really don't think avahi will be granted an exception
[02:35] <tseng> its easy enough to start avahi
[02:35] <tseng> this is like the openssh debate all over again
[02:36] <Keybuk> right ;)  we don't give the most audited, and self-proclaimed most secure piece of software in the known universe an open port :p
[02:36] <neuralis> Keybuk: openssh's security record is terrible.
[02:36] <tseng> haha
[02:36] <tseng> because people audit it non-stop
[02:36] <Keybuk> neuralis: note "self-proclaimed"
[02:36] <Keybuk> and that's not a bad thing
[02:36] <Keybuk> avahi has no security record
[02:36] <Keybuk> NONE
[02:37] <neuralis> Keybuk: pitti and i independently did brief audits, and were both happy; remember that avahi is a non-root listener running in a chroot with explicitly dropped capabilities.
[02:37] <Keybuk> giving avahi an open port is like wandering into a public toilet, kneeling on the floor, dropping your pants, and *hoping* it's not one of the dodgy ones
[02:38] <Keybuk> neuralis: it communicates with things outside of the jail ... so there is a risk
[02:38] <sladen> neuralis: I think you need to right the spec on the basis that the exception will /not/ be granted.  And provide a Plan B, in case an exception /is/ granted.
[02:38] <sladen> s/right/write/
[02:38] <neuralis> sladen: it's not my spec. i don't care.
[02:38] <neuralis> sladen: i don't use avahi.
[02:38] <Keybuk> sladen: it's robertj's spec
[02:39] <sladen> robertj: I think you need to right the spec on the basis that the exception will /not/ be granted.  And provide a Plan B, in case an exception /is/ granted.
[02:39] <sladen> s/right/write/
[02:39] <neuralis> Keybuk: the communication is apparently one byte in either direction; i just audited that region of source, and so did pitti some time ago. we were both satisfied.
[02:39] <neuralis> Keybuk: in any case, i'll post a summary of my audit to -devel, and after that, i really don't much care.
[02:39] <Keybuk> neuralis: it does the entire functionality, announcing all shares, etc. in just one byte?
[02:40] <sladen> robertj: at UDS, I AFAICT, the decision from the BOF was to provide a checkbox in the network config to "[x]  Enable Zeroconf on this interface"
[02:40] <Keybuk> that's a hell of a compression ration
[02:40] <Keybuk> 30GB of advertised rhythmbox mp3s ... in one byte? :p
[02:40] <neuralis> Keybuk: please read carefully. i'm talking about communication with the helper that lives outside the chroot.
[02:41] <Keybuk> neuralis: right, and I'm saying that makes zero sense given what the implementation does
[02:41] <Keybuk> either the helper has access to the network
[02:41] <sladen> robertj: and a policy that if an application wanted Zeroconf, it cause a dialogue appear offering to enable zeroconf for either "This Session" or "Forever"
[02:41] <Keybuk> or all network-potential traffic has to pass between them
[02:41] <Keybuk> in which case, there's an escape from the jail
[02:41] <neuralis> Keybuk: dude, are you always this impatient? :)
[02:41] <sladen> Keybuk: read, it again.
[02:42] <sladen> Keybuk: carefully this time
[02:42] <Keybuk> sladen: read which?  I'm still reading, and still not seeing anything
[02:42] <Keybuk> neuralis: yes :P
[02:42] <neuralis> Keybuk: the helper will optionally return a R/O fd into the chroot process, which points to one of the static introspection/PID files. other than that, all communication between the two is one-byte commands and one-byte responses.
[02:43] <neuralis> Keybuk: the introspection files are likely movable into the chroot, so that portion of the code can be likely dropped outright.
[02:43] <Keybuk> so it's a reasonably secure network daemon
[02:43] <Keybuk> that does not grant it an open port
[02:43] <Keybuk> because we grant *nothing* an open port
[02:44] <sladen> Keybuk: AFAICT, the chroot'ed deamon only speaks DBUS and DNS;  and the help outside with godmode only hands in open file-descriptors to the deamon
[02:44] <Keybuk> sladen: I thought the chroot'd bit did not do dbus?
[02:44] <neuralis> no, it does dbus, if you configure it to do dbus.
[02:45] <Keybuk> so an attacker can compromise the daemon and issue arbitrary dbus commands?
[02:45] <neuralis> not if you tell it to not use dbus.
[02:45] <Keybuk> why would you tell it to use dbus?
[02:45] <tseng> uh?
[02:45] <neuralis> Keybuk: i didn't see a good reason for it, but that's for an avahi developer to answer.
[02:45] <Keybuk> anyway, this is an increasingly boring conversation
[02:45] <Keybuk> given that avahi is *not* getting an open port
[02:46] <sladen> Keybuk: strong words.  never say never.  
[02:46] <neuralis> Keybuk: hey, i was going to post my findings to devel and wander off. you pressed the issue.
[02:46] <sladen> Keybuk: at least keep people hanging on with a thread of hope for as long as possible before politely shafting them
[02:47] <Keybuk> neuralis: I just suggested the spec be altered to allow it to have a hope of being approved :)
[02:48] <sladen> so, regarding this dbus thing.  Does avahi actually have any point if you can't talk to it.  I was under the impression that that was how one told avahi to do things
[02:49] <neuralis> Keybuk: quite honestly, avahi provides (in terms of functionality) a level of convenience that's indispensable to many users; it's not unlike dhcp in that regard. the issue needs to be seriously thought through, especially if security doesn't factor in particularly strongly.
[02:49] <Keybuk> security does factor into this though
[02:49] <Keybuk> and as you see, it's a convenience
[02:50] <Keybuk> users can turn it on if they want it
[02:50] <neuralis> Keybuk: so i'm writing my security mail now, and then you and the rest of the tb bunch can do the thinking, and robertj can do the fanboying. 
[02:50] <Keybuk> we have a spec for that
[02:50] <robertj> I think I'm done with my chearleeding
[02:52] <Lathiat> *reads up*
[02:55] <sladen> robertj: realistically, for Zeroconf we're going to end up with a tick box along the same lines as for Remote Desktop.  "[x]  Share my services"
[02:55] <Lathiat> if you cant talk to avahi on dbus
[02:56] <sladen> robertj: or something similar.  The spec needs writing with that in mind, and how exactly to address that in a cross-desktop way
[02:56] <Lathiat> its relatively useless for a deskto papplication
[02:57] <neuralis> Lathiat: then the security breakdown doesn't make sense; the helper should be doing the dbus brokering, and passing in information into the chroot process.
[02:57] <Lathiat> and it would do that with what?
[02:57] <Lathiat> something like d-bus? ;)
[02:58] <neuralis> Lathiat: uh, exactly how you currently pass in information from the helper?
[02:58] <Keybuk> neuralis: and then you still have an IPC protocol that the compromised chrooted process can talk to something outside of the chroot
[02:58] <Lathiat> neuralis: the daemon basically does 99.9% of the work
[02:58] <Lathiat> the helper just does a few extra bits
[02:58] <neuralis> Keybuk: not if it's one-way, or mostly one-way.
[02:59] <neuralis> anyway, i really don't care about avahi nearly enough to continue this discussion. :)
[02:59] <Lathiat> but avahi *isnt* one-way
[02:59] <Lathiat> or mostly one way
[02:59] <Lathiat> its very 2 way
[02:59] <Keybuk> neuralis: but it's not, it's very bi-directional
[03:00] <neuralis> Keybuk: yes, clearly, but if the helper is doing the dbus brokering, then it can enforce extremely strict validation on what goes out over dbus, rendering the "someone can do crazy shit on dbus if they break into the chroot daemon" argument moot.
[03:00] <Keybuk> neuralis: but the helper isn't doing the dbus brokering
[03:00] <Lathiat> well
[03:00] <Lathiat> dbus hsa escurity policies
[03:00] <Lathiat> avahi is only allowed to speak on the avahi interface, etc
[03:01] <Lathiat> so you cant go sending other dbus messages
[03:01] <neuralis> Keybuk: yes, that's why i told lathiat that the current security model isn't right.
[03:01] <Keybuk> neuralis: also, more to the point, because there is a communication path from the daemon to the helper ... you're now at risk of the helper having an exploit too
[03:01] <Lathiat> sounds more complicated and your putting more exploitable code outside the chroot
[03:01] <Lathiat> where its "less safe" 
[03:02] <Keybuk> so while chroot, etc. are useful for reducing the security risk; this is certainly not in the "LA LA LA! NO SECURITY RISK HERE! CURVE AROUND THE SCENE OF THE CRIME!"
[03:02] <sladen> Lathiat: the separation is that you are protecting  *everything*  from stuff hitting the  *network port*.  Everything not coming from the network port wants to stay outside of the process that is talking to the network port.
[03:03] <neuralis> what sladen said.
[03:03] <Lathiat> ah, i see
[03:04] <Keybuk> I'm not passing any judgements on the design of avahi itself, I'm just saying that your comments above that security doesn't factor is completely bogus -- this is a daemon with a high bi-directional interaction with other processes -- no matter how isolated you make it, it is never completely isolated because it can't be by design -- so security *is* a factor
[03:05] <sladen> so, the if a daemon *really must* talk to the network, it should do that, and nothing else.  Unfortunately, this makes the daemon a bit useful since that wouldn't include talking to the local machine...
[03:05] <sladen> useless
[03:05] <Lathiat> i just dont see how some other home cookd IPC mechanism is any better than d-bus which has restrictions on what interface it can talk on
[03:06] <neuralis> Keybuk: i wasn't contending that security isn't a factor because there's no risk, but because i, after a hand audit, find the dedication to, and design of, the security systems in place fully adequate. 
[03:06] <Keybuk> you'd have to djb it, split it into very small processes that each have a particular job and communicate over a strict protocol to a companion process in a different "security zone"
[03:06] <Lathiat> assuming d-bus is secure, but any home grown protocol is likely to get bugs too
[03:06] <Lathiat> Keybuk: hehe...
[03:06] <Lathiat> mm djb, dont get me started on djb :)
[03:06] <neuralis> Keybuk: you're allowed a fully different definition of adequate, and thus ymmv.
[03:06] <Keybuk> neuralis: except that in your audit, you appear to have not noticed that the chroot'd daemon needs to talk dbus ... which puts my faith in your audit as very low, I'm afraid
[03:06] <Keybuk> and, note, that no piece of djb software has been granted an open port either ... because we don't do open ports around here
[03:07] <neuralis> Keybuk: bah. still not my spec, still don't care about avahi. i was asked to audit the bigger picture, after pitti audited the lower-level primitives, and i did. in the end, i don't use avahi, and couldn't care less about it being enabled.
[03:08] <sladen> Lathiat: "assuming D-Bus is secure".  Bzzzt.  Bad assumption
[03:08] <Lathiat> sladen: see following comment
[03:09] <sladen> Lathiat: okay :)
[03:09] <neuralis> Keybuk: the audit noticed dbus fine, but no developers were around for me to ask specific questions about how and why the design was the way it was.
[03:09] <Lathiat> neuralis: avahi developers?
[03:09] <neuralis> Lathiat: yes.
[03:09] <Lathiat> neuralis: im around now :)
[03:10] <neuralis> Lathiat: well, i've already inferred the answer to the dbus question; you felt that it's better than a homebrew ipc protocol, and you also thought it's better to keep the dbus stuff chrooted (which, i believe, is approaching the separation incorrectly.)
[03:10] <neuralis> Lathiat: the remaining question was why not move the introspection files into the chroot instead of passing them around via the helper.
[03:11] <Lathiat> thats a question i dont know the answer to 
[03:11] <Lathiat> lennart did that
[03:11] <Lathiat> i'd have to ask him
[03:11] <Lathiat> he doenst seem to be around atm tho (is guadec still on?)
[03:14] <neuralis> Lathiat: it's something to ask him later.
[03:16] <Lathiat> thanks for the chat :)
[03:16] <Lathiat> whats the fireworks for?
[03:16] <neuralis> http://en.wikipedia.org/wiki/Independence_Day_%28United_States%29
[03:16] <Lathiat> ah right
[03:17] <robertj> Didn't know you Harvard Commies still celebrated the 4th ;)
[03:17] <neuralis> robertj: we don't, that's why i'm going to killian court :P
[03:17] <neuralis> robertj: (those commies, on the other hand..)
[03:27] <bddebian> Heya
[03:27] <Burgundavia> hey bddebian
[03:28] <bddebian> Hi Burgundavia
[03:37] <Hobbsee> hi all
[03:37] <LaserJock> hi Hobbsee 
[03:37] <Chipzz> hi
[03:38] <Hobbsee> hi LaserJock and Chipzz 
[03:38] <zul> hey Hobbsee 
[03:38] <Chipzz> at least on an international channel most of the time someone is awake ;P
[03:38] <Hobbsee> hi zul 
[03:38] <Hobbsee> Chipzz: hehe, true
[03:39] <Hobbsee> jdub: awake today?
[03:58] <Hobbsee> Chipzz: it's gone, i drank it.
[04:00] <Chipzz> Hobbsee: I live in Belgium, the country of beer ;)
[04:01] <Chipzz> there is no such thing as "no beer" in Belgium ;)
[04:01] <Hobbsee> Chipzz: hehehe
[04:02] <Chipzz> there IS such a thing as "no-one awake" though ;P
[04:03] <Hobbsee> true
[04:03] <Hobbsee> because they've all passed out due to being drunk.
[04:04] <Chipzz> heh :P
[04:04] <Chipzz> they just have better things to do than to be on irc ;P
[04:07] <Hobbsee> Chipzz: you mean there are better things than being on irc?
[04:07] <Hobbsee> Chipzz: actually, i agree with you -in a hack session with some of the other devs, and chatting on irc like that - and being able to watch the responses to what you type.  now *that's* fun!
[04:08] <Chipzz> 03:27 < Chipzz> wa doet gij nog zo laat op om te beginnen? :)
[04:08] <Chipzz> heh ;)
[04:08] <Chipzz> and I thought *I* was a nerd ;P
[04:09] <Chipzz> ;)
[04:09] <Chipzz> (no offence meant ;))
[04:10] <Hobbsee> hehe
[04:10] <Hobbsee> Chipzz: actually, irc is the communication medium to meet up with people - which is why i logged on before breakfast.
[04:11] <Chipzz> Hobbsee: but is it a medium to meet people you work with, or to make new social contacts?
[04:12] <Chipzz> after having been on irc for 10 years, I'm more and more convinced it's mostly the former
[04:12] <Chipzz> also the latter
[04:13] <Chipzz> but for a large part the former
[04:17] <profoX`> Chipzz: belgian beer ftw
[04:18] <Chipzz> profoX`: FTW?
[04:19] <Lathiat> for the win? :)
[04:19] <Lathiat> ..dows
[04:19] <Chipzz> is there any winning to be done then, really? :)
[04:19] <profoX`> Lathiat: is right
[04:19] <profoX`> please guys, you ruin the... eh.. acronym
[04:19] <profoX`> :P
[04:19] <Chipzz> profoX` ;)
[04:19] <profoX`> what i meant to say was: belgian beer = good
[04:20] <profoX`> Duvel+
[04:20] <Chipzz> profoX`: yes, but WHICH belgian beer? ;)
[04:20] <profoX`> Duvel, of course :D
[04:20] <Chipzz> which one of the more than 100 belgian beers? ;P
[04:20] <Chipzz> duvel gives me stomach gasses :P
[04:20] <profoX`> tss...
[04:21] <profoX`> :)
[04:21] <profoX`> what do you drink then
[04:21] <profoX`> jupiler ?
[04:21] <Chipzz> kriek lindemans is very nice
[04:22] <Chipzz> geuze
[04:22] <profoX`> kriek lindemans is okay for once, but i'd rather have my duvel ;P
[04:22] <Chipzz> some people think it is *too* sweet
[04:23] <Chipzz> I was drinking jupiler earlier :)
[04:23] <Chipzz> stella was all gone :/
[04:23] <Hobbsee> Chipzz: the former, mostly.
[04:23] <profoX`> Chipzz: it is too sweet to be considered real beer :P
[04:24] <Chipzz> profoX`: also, rodenback grand crue
[04:24] <Chipzz> rodenbach is crap, but the grand crue is great :)
[04:24] <profoX`> never drank that
[04:24] <Chipzz> Hobbsee: you into sweet things?
[04:25] <Hobbsee> Chipzz: depends what sort of things
[04:27] <profoX`> lol
[04:28] <Chipzz> she really is not ;P
[04:30] <bluefoxicy> Here's a thought.
[04:31] <bluefoxicy> I recently installed Ubuntu Dapper on a 350MHz K6-2 with 192 megs of ram
[04:31] <bluefoxicy> it took some fighting; I had to kill GDM and then startx with xterm in my .xinitrc, just to get enough ram free for the damn thing to not lock up totally during install
[04:32] <bluefoxicy> (as to why the OOM didn't stab things to death I have no idea)
[04:32] <Chipzz> bluefoxicy: use the altnerative install cd?
[04:32] <bluefoxicy> Once it's installed, it works.  A little sluggish, takes about 3 minutes to open up openoffice.org, not yet swapping.
[04:32] <bluefoxicy> Well, my question is this
[04:32] <bluefoxicy> 486 stops at 66MHz.  No.  Freaking.  Way.
[04:33] <Chipzz> my question is this: who is as machosist as to run OO.o on a 192MB machine? ;)P
[04:33] <bluefoxicy> Is there ANY benefit to building the whole system as 586 or 686 (I have been looking for a list of instructions introduced in those processor lines with no luck), or should we not care?
[04:33] <Chipzz> bluefoxicy: and 486 stops at DX4 120Mhz
[04:34] <bluefoxicy> Chipzz:  okay, I've never physically seen more than 33MHz but heard of 66.  120, that's ... still... not going to be fun.
[04:34] <Chipzz> and I do not think that there is much substantial benefit as to build for i586
[04:35] <bluefoxicy> Me either, it's just a thought.  It's between "is anyone going to ever run this on a 486?" and "Is there a practical benefit to going 586?"; I don't see a practical benefit, even if there's no real way anyone is running this thing on a 486
[04:35] <Chipzz> much of the stuff that makes stuff fast is either pure ordering of instructions (386 <-> 486) or use of a particular extensions, like MMX(2), or SSE(2)
[04:35] <bluefoxicy> heh.  Don't get me started on SSE
[04:36] <Chipzz> MMX and SSE for making string instructions faster
[04:36] <bluefoxicy> using that as a general math coprocessor is slooooooooow.
[04:36] <bluefoxicy> (there's apparently a gcc optimization that uses sse for math!)
[04:36] <bluefoxicy> (a lot of gentoo people were using it @_@)
[04:37] <Chipzz> iirc sse can be faster for string copy stuff than integer stuff is
[04:37] <bluefoxicy> SSE is faster for repeatedly computing on the same data set
[04:37] <Chipzz> or maybe that's just MMX; dunnow
[04:38] <Chipzz> so SSE would also be faster for doing the (null) computation on the same data set?
[04:38] <Chipzz> ie strcpy?
[04:38] <bluefoxicy> like if you want to calculate a particular value and it starts with 4 variables A B C D and does A % B -> ab , C / ab -> N, N * AB -> Z ..... for like a 70 step pipeline, it's faster
[04:38] <Chipzz> or am I mistaken with mmx?
[04:38] <bluefoxicy> sse won't do anything for strings
[04:38] <bluefoxicy> it's for like, math stuff
[04:39] <bluefoxicy> I'm told it takes 17 cycles to load a value into an SSE register, and 17 to get it back out
[04:39] <bluefoxicy> (slow)
[04:39] <Chipzz> then I'm probably mistaking with mmx
[04:39] <bluefoxicy> but then when you do a string of math instructions it executes like a jillion of them a cycle
[04:40] <bluefoxicy> hence if you have really, really long mathematical computations it's super fast
[04:40] <bluefoxicy> but that's EXTREMELY special cased
[06:08] <wasabi> Weird bug: System > Quit.  GDM "Choose Server" box appears (I have two X servers configured), but right when the box appears, the screen fades out and gnome-screensaver locks.
[06:09] <wasabi> Apparently the case of having GDM prompt wasn't considered.
[07:13] <fabbione> morning
[07:22] <jsgotangco> hello fabbione
[07:22] <fabbione> yo
[07:53] <Mithrandir> fabbione: any chance you could review https://launchpad.net/distros/ubuntu/+spec/live-cd-share-live-cd for me?
[07:53] <fabbione> Mithrandir: yeps.
[07:53] <fabbione> Mithrandir: i will need to bother you later for sparc
[07:54] <fabbione> (but not now. i still need to do them)
[07:58] <Mithrandir> fabbione: thanks
[07:58] <fabbione> Mithrandir: see /msg
[08:46] <pitti> Good morning
[08:46] <ivoks> 'morning
[08:49] <ivoks> pitti: care to upload something to dapper-updates? :)
[08:50] <ivoks> pitti: fix for bug 45406
[08:50] <Ubugtu> Malone bug 45406 in libgnomecups "memory leak in gnome-cups-icon" [Unknown,Unknown]  http://launchpad.net/bugs/45406
[08:52] <pitti> ivoks: ah, that one; yes, it's in my mbox so far, but I'm not sure whether it's worth the trouble
[08:54] <ivoks> pitti: i've fixed it
[08:54] <ivoks> pitti: (applied debian patch)
[08:55] <ivoks> pitti: it's on http://www.grad.hr/~ivoks/ubuntu/libgnomecups
[09:01] <pitti> ivoks: can you please attach the debdiff to the bug, so that mdz has something to look at for approval?
[09:01] <ivoks> sure
[09:03] <jamesh> ivoks: btw, I updated my ipplib.py + printerlist.py demo to work with current CUPS (and fixed an issue with encoding multiple values for an attribute)
[09:03] <jamesh> if you were still interested in it.
[09:03] <ivoks> sure I am
[09:27] <\sh> moins
[09:31] <jsgotangco> hello sabdfl
[09:54] <sivang> morning!
[09:54] <lifeless> seb128: steve would like to speak to you, as me
[09:54] <seb128> lifeless: about?
[09:55] <jsgotangco> morning sivang
[09:58] <dholbach> good morning
[09:59] <sivang> morning jsgotangco , dholbach 
[09:59] <dholbach> hey sivang
[10:06] <sabdfl> hi jsgotangco... i see everyone's in https://launchpad.net/distros/ubuntu/edgy/+specs "get cracking" mode
[10:07] <jsgotangco> =D
[10:10] <crimsun> w/ 2.6.17-4.6?
[10:10] <fabbione> hunger: please file a bug in LP
[10:10] <fabbione> hunger: add all the OOPS
[10:10] <slomo_> hunger: bug #51308 maybe?
[10:10] <Ubugtu> Malone bug 51308 in linux-source-2.6.17 "linux-image-2.6.17-[34] -686 doesn't boot, libata error" [Untriaged,Confirmed]  http://launchpad.net/bugs/51308
[10:11] <hunger> fabbione: I did... #51384v
[10:12] <crimsun> that should be fixed in 2.6.17-4.6.
[10:12] <hunger> fabbione: I am afraid that will get lost as a duplicate of the hd->sd bug.
[10:12] <fabbione> hunger: then please wait...
[10:12] <hunger> crimsun: Oh, great!
[10:13] <hunger> fabbione: I will. but since the bug was marked as a duplicate of the hd->sd thing before, I was afraid it would fall through the cracks.
[10:18] <sivang> hunger: I also have this bug , and non of the edgy kernels have ever booted for me
[10:37] <Kamion> ogra: in practice you want to support gcompris-sound-* for edubuntu, don't you?
[10:37] <Kamion> (just dealing with NEW and figuring out which components stuff goes in)
[10:37] <Kamion> ogra: at present gcompris-sound-eu and gcompris-sound-hu are in universe and all the rest in main, which seems a bit ranom
[10:38] <Kamion> random
[10:45] <jhemono> Hello. I've written a spec a long time ago and I recently posted it on ubuntu-devel mailing-list. I saw a meeting have been planned for reviewing specs at july 6th 2000 UT. Herre it's wiki page : https://launchpad.net/distros/ubuntu/+spec/automated-localization-download . Do you think I sould register it for reviewing at the meeting ? I
[10:53] <simosx> jhemono: I have the impression that when you install Ubuntu 6.06 and you have chosen a language during the CD booting, you get the basic localisation from the CD. However, when you setup the system and the network connection, AFAIK apt considers that the localisation packages for Firefox, OOO, etc are pending and asks you to install them.
[10:55] <jhemono> yes ....
[10:59] <jhemono> In my mail to the mailing list we are discussing about how to tell the user that full localization is avaiable : a notification would be too pervasive said someone and an icon would'n be pervasive enough i said. so do you think I have to register it for the meeting for more brains think to it ?
[11:00] <mdke> hey Seveas, can you get my cloak back? it has disappeared. Lemme know if you want an email about it
[11:01] <Seveas> one sec
[11:23] <jhemono> up
[11:24] <jhemono> So, what do think of it ?
[11:25] <Seveas>  -:NickServ!NickServ@services.- +Cloak for [mdke]  has been toggled [ON]  and changed to [ubuntu/member/mdke] 
[11:27] <mdke> Seveas: thanks. did i disactivate it myself by accident?
[11:27] <Seveas> no idea
[11:27] <Seveas> maybe a subspace rift caused it
[11:28] <mdke> Seveas: ok. cheers
[11:28] <Treenaks> Seveas: a twist in the fabric of space where time becomes a loop!
[11:32] <ogra> Kamion, yes, i need to sort the seeds
[11:32] <Hobbsee> hi ogra 
[11:35] <jdub> Kamion: could you please s/python-sqlite/python-pysqlite2/ in the python seed?
[11:37] <ogra> hey Hobbsee 
[11:46] <dholbach> could somebody give back gksu?
[11:48] <Kamion> ogra: I can do it now if you want - I already have the local chance
[11:48] <Kamion> change
[11:48] <Kamion> dholbach: you need Keybuk
[11:48] <dholbach> Kamion: ok... thank you.
[11:48] <dholbach> Gloubiboulga: i just deleted my work on goffice and gnumeric merge
[11:48] <dholbach> Gloubiboulga: i'll restart on it (they're both in debian experimental already)
[11:49] <Gloubiboulga> dholbach, I can take care of this if you want
[11:50] <dholbach> Gloubiboulga: that'd be lovely - you know the *-gtk-* build parts a bit better
[11:50] <dholbach> Gloubiboulga: if you're done i can have another look at it and upload it
[11:50] <Gloubiboulga> dholbach, ok, I'll try to get this done this evening (fighting with xfce4-terminal for the moment)
[11:51] <dholbach> Gloubiboulga: merging? or the rebuild for vte?
[11:51] <Gloubiboulga> dholbach, packaging a svn snapshot, I don't even know how the package in dapper has been built or how it works
[11:52] <Kamion> jdub: if you mean s/python-sqlite2/python-pysqlite2/, I did that on 21 June
[11:52] <jdub> Kamion: ah, ok
[11:52] <jdub> Kamion: thanks
[11:52] <Kamion> jdub: oh, apparently python-sqlite is still there. you want me to drop that then?
[11:52] <Kamion> can I have a rationale for the bzr log?
[11:53] <jdub> Kamion: uses old, buggy sqlite 1.x, not desireable or recommendable
[11:53] <Kamion> sqlite 2 according to dpkg -I
[11:53] <ogra> dholbach, evo crashing isnt gpg related
[11:53] <Gloubiboulga> has anyone seen janimo lately? I haven't seen him on irc or MLs since the Paris uds
[11:53] <Kamion> interestingly, we currently have both sqlite 2 and 3 in main
[11:53] <ogra> (happens as well if i switch off gpg completely)
[11:53] <Kamion> libsqlite0 | 2.8.17-0ubuntu1 |          edgy | amd64, hppa, i386, ia64, powerpc, sparc
[11:53] <Kamion> libsqlite3-0 |  3.3.5-0.2 |          edgy | amd64, i386, ia64, powerpc, sparc
[11:53] <dholbach> Gloubiboulga: me neither... i wondered about that too. didn't he want to travel now?
[11:54] <dholbach> ogra: you have a backtrace?
[11:54] <Kamion> is there any prospect of getting rid of libsqlite0?
[11:54] <Gloubiboulga> dholbach, no idea... I mailed him a few hours ago, I hope he'll reply soon
[11:54] <Kamion> (if not, surely we should keep its bindings)
[11:54] <ogra> dholbach, not yet... in the state my system is that takes some effort (i cant even type properly and the linux-image fix that adds keyboard support for me is still MIA)
[11:55] <Kamion> jdub: ^--
[11:58] <ogra> dholbach, i have a bug buddy backtrace, but i cant copy and paste apparently ...
[11:58] <dholbach> it has a "save" button
[11:59] <Kamion> ok, the seeds now require germinate 0.19 / 0.11ubuntu1 kthxbye
[11:59] <ogra> dholbach, only if the "show details" button works .... damned
[12:00] <ogra> upgradinbg to edgy with inly one laptop around was the worst idea evah
[12:00] <dholbach> gdb -p $(pidof evolution)
[12:00] <dholbach> or evolution-2.8 (whatever process is running now)
[12:01] <ogra> dholbach, i cant copy and paste and i cant send mail, how would i get that to you ? :)
[12:01] <ogra> i'll record it for later
[12:03] <dholbach> ogra: https://wiki.ubuntu.com/Backtrace
[12:04] <dholbach> is somebody aware of the wiki being a bit broken? like links going to help.ubuntu.com/community/<something> and are empty and stuff?
[12:05] <ogra> i noted the extreme slowness through the forwarding, but i havent been forwareded to empty pages yet
[12:05] <dholbach> http://wiki.ubuntu.com/DebuggingProgramCrash -> click on "Backtrace"
[12:06] <Kamion> ogra: (done gcompris-sound-* seed change)
[12:06] <ogra> Kamion, thanks
[12:07] <ogra> dholbach, right, none of the subpages are there
[12:13] <Kamion> damn, my germinate change wasn't *quite* right
[12:14] <Kamion> it's randomly not grabbing some bits from extra
[12:17] <Kamion> oh, I bet some bits don't realise that build-depends -> supported ...
[12:39] <sivang> do we have a python roadmap for edgy? e.g., which versions we are going to support, transistions we process from debian etc?
[12:39] <pitti> sivang: we should be almost back in sync with debian now
[12:41] <sivang> pitti: I see, thanks, what is going to be 
[12:41] <sivang> pitti: "the" python version for us?
[12:41] <sladen> pitti_laptop: -dbgsym.ddeb or -dbgsym.deb ?
[12:41] <sivang> (2.5 ?)
[12:41] <pitti_laptop> sladen: .ddeb
[12:41] <pitti_laptop> sladen: did I write a typo in my announcement?
[12:43] <sladen> pitti_laptop: you wrote ".ddeb", and my instant reaction was kwtf, that must be a type, somebody would have to be utterly nuts to use a brand-new extension
[12:43] <sladen> typo
[12:43] <pitti_laptop> sladen: .ddeb was on purpose, see the spece
[12:43] <pitti_laptop> s/e$//
[12:44] <sladen> pitti_laptop: yeah, I found that
[12:44] <elmo> pitti: you realise these can not possibly go on archive.ubuntu.com right?
[12:45] <pitti_laptop> elmo: my original plan was to use .deb, but the soyuz guys and infinity convinced me that a separate extension/namespace was better
[12:45] <elmo> pitti: I don't care about the extension
[12:45] <pitti_laptop> elmo: we need a separate namespace to not kill the mirrors
[12:45] <elmo> pitti: I care about the fact that archive.ubuntu.com even with only supported architectures is 160Gb
[12:45] <elmo> you need a separate MIRROR to not kill the mirrors
[12:45] <elmo> expecting hundreds of mirrors to add --exclude="*.ddeb" is utter crack
[12:46] <sladen> pitti_laptop: the .ddeb is going to be a PITA though, lots of things are already set to see 'ahh .deb', I know what mimetype to serve that with and tools that assume that the file they are working with ends in .deb
[12:46] <pitti_laptop> elmo: they will live somewhere else anyway AFAIU
[12:46] <sladen> pitti_laptop: valid point, the application is probably broken if it is hard-coded to always append .deb
[12:46] <Kamion> elmo: sorry, I'm going to need another germinate upgrade on drescher in a bit - trying to nail down the fix for the bug now
[12:47] <elmo> pitti: ok - but just in case, I am going to add --exclude "*.ddeb" to our top levels :-P
[12:47] <elmo> Kamion: k
[12:47] <Seveas> pitti, how about s/-debugsym.ddeb/.debug.deb/ ?
[12:47] <sladen> .udeb, .ddeb, .fudeb, .ubudeb
[12:47] <pitti_laptop> elmo: I am sorry that I do not know the soyuz details; but the guys are aware that we must not silently push them to the mirros
[12:48] <pitti_laptop> Seveas: it would make it hard to exclude the .ddebs from Packages.gz
[12:48] <elmo> a new extension really isn't a problem
[12:48] <elmo> any more than .udeb was for, err, udebs
[12:48] <pitti_laptop> Seveas: also, since they do not appear in debian/control, dpkg-genchanges and soyuz will cry out
[12:48] <Seveas> just add .ddeb to the mime databasses in standard ubuntu programs (so they eg still open with gdebi)
[12:49] <sladen> pitti_laptop: find -name \*.deb -a \! -name \*.debug.deb
[12:49] <pitti_laptop> sladen: btw, the intention is not that users actually install them, btw
[12:49] <pitti_laptop> sladen: having a .deb-like file makes it convenient for developers, though
[12:50] <Kamion> Seveas: if it's a different enough kind of thing (as pitti suggests) to deserve a separate extension, it should be properly separate rather than .debug.deb
[12:51] <Seveas> Kamion, fair enough
[12:59] <pitti_laptop> Seveas: hm, teaching our tools to append .debug everywhere would be even more invasive, I think
[01:00] <pitti_laptop> although, no, forget that
[01:03] <sladen> pitti_laptop: presumebly these packges Extend: the real one, or are they completely separate?
[01:04] <pitti_laptop> sladen: right now, the .ddeb depends on the exact version of the .deb, nothing else
[01:04] <pitti_laptop> sladen: I'm open to suggestions for improvements
[01:04] <pitti_laptop> sladen: Extend:? There is an Enhances: AFAIK
[01:04] <sladen> nod
[01:32] <elmo> what on dapper renames my eth<n>'s?
[01:32] <Mithrandir> udev
[01:33] <elmo> ok, so any idea why it would rename a machine with two onboard nics, to eth2/3 on upgrade from breezy?
[01:33] <Lathiat> does /etc/iftab apply?
[01:33] <Lathiat> elmo: it could be one of those conflict things
[01:34] <Lathiat> that causes them to jump up
[01:34] <Lathiat> actualy i wouldnt have thought youd end up with 2/3
[01:34] <giftnudel> I can confirm this on my Desktop, btw
[01:35] <elmo> giftnudel: the random NIC renaming?
[01:35] <giftnudel> not random, but +1
[01:36] <giftnudel> when I upgraded to dapper
[01:36] <sladen> elmo: /etc/udev/rules.d/25-iftab.rules
[01:37] <sladen> elmo: bitch to keybuk about it, I think that is his crack
[01:43] <elmo> hmm, the /etc/iftab was entirely disconnected from reality
[01:56] <Kamion> gnomefreak: please don't mark ubiquity bugs as duplicates until you have read and understood http://wiki.ubuntu.com/DebuggingUbiquity
[01:58] <Kamion> "you must not mark bugs as duplicates on the basis that they both contain a traceback such as this"
[01:58] <Kamion> also if you use my standard texts from that page then you won't forget to ask for one of the log files I need :-)
[02:06] <Toadstool> nice, I didn't know of this wiki page, makes ubiquity bugs triaging a piece of cake :)
[02:06] <Toadstool> hi devs
[02:14] <ogra> where is make-kpkg supposed to put my kernel package ? i just built my own kernel to get keyboard support back, but i cant find the package now
[02:16] <Mithrandir> in .., usually
[02:16] <ogra> meh, then i did something wrong
[02:16] <ogra> *sigh*
[02:18] <Mithrandir> Keybuk: would it be possible to have a list of merges mom skipped due to blacklisting in a BLACKLISTED directory or something like it?
[02:19] <Keybuk> Mithrandir: mom doesn't have a blacklist
[02:19] <Keybuk> which merge is missing?
[02:20] <Mithrandir> Keybuk: x11proto-composite was, at least.
[02:20] <rodarvus> most X packages are missing - but due to different package naming
[02:20] <fabbione> Keybuk: all x11proto stuff was missing but it might be becuase of unmatching md5sum for the orig.tar.gz
[02:21] <fabbione> Keybuk: perhaps it's just exploiting a bug in MoM
[02:21] <Keybuk> let me look
[02:21] <fabbione> Keybuk: you can try x11proto-xinerama
[02:21] <fabbione> not the merge i already did, but using an older version
[02:21] <Keybuk> DEBUG:root:x11proto-xinerama: ubuntu is 1.1.2-3ubuntu1
[02:21] <Keybuk> DEBUG:root:x11proto-xinerama: debian is 1.1.2-3
[02:21] <Keybuk> DEBUG:root:x11proto-xinerama: base is 1.1.2-3 (1.1.2-3 wanted)
[02:22] <Keybuk> so there's nothing to merge there
[02:22] <zul> hey
[02:22] <Keybuk> our "base version" is the current version in Debian, as far as mom is concerned
 not the merge i already did, but using an older version
[02:22] <Keybuk> fabbione: do you have an example of something you haven't done yet
[02:23] <fabbione> Keybuk: yes.. give me a minute to find one
[02:23] <Keybuk> s'ok, found x11proto-xinerama in an earlier log
[02:23] <Keybuk> i:Exit  -:PrevPg  <Space>:NextPg v:View Attachm.  d:Del  r:Reply  j:Next ?:Help
[02:23] <Keybuk> DEBUG:root:x11proto-xinerama: ubuntu is 1.1.2-0ubuntu2
[02:23] <Keybuk> DEBUG:root:x11proto-xinerama: debian is 1.1.2-3
[02:23] <Keybuk> (note, no base)
[02:23] <Keybuk> so there's never been a version in Debian prior to 1.1.2-0ubuntu2
[02:23] <fabbione> x11proto-record
[02:23] <Keybuk> DEBUG:root:x11proto-record: ubuntu is 1.13.2-0ubuntu2
[02:23] <Keybuk> DEBUG:root:x11proto-record: debian is 1.13.2-3
[02:24] <Keybuk> same problem, never been a version in Debian < 1.13.2-0
[02:24] <fabbione> Keybuk: they have different md5sum for the orig.tar.gz in Debian and Ubuntu
[02:24] <fabbione> that's all it matter
[02:24] <fabbione> we had more history than debian
[02:25] <Keybuk> fabbione: I don't think mom especially cares about that
[02:25] <Kamion> perhaps it would be possible for MoM to output a list of packages that are in both Debian and Ubuntu but that have no common base
[02:25] <Keybuk> it will do the merge with the Debian orig.tar.gz
[02:25] <Kamion> in some of those cases it's worth our while trying to merge (most notably X but there might well be one or two others)
[02:25] <Keybuk> Kamion: yeah, i can do that ... gimme a sec
[02:27] <Keybuk> the interesting thing is that we have "Ubuntu Patches" for those
[02:27] <Keybuk> they'd be at least useful for a manual merge
[02:34] <seb128> does anybody know what is going on with the pango1.0 build?
[02:34] <Keybuk> seb128: ask me in a minute
[02:34] <seb128> ok
[02:34] <fabbione> Keybuk: BenC was asking for a give-back of the kernel all over
[02:41] <bddebian> Heya folks
[02:42] <Keybuk> fabbione, Mithrandir:
[02:42] <Keybuk> http://merges.ubuntu.com/main-manual.html
[02:42] <Keybuk> http://merges.ubuntu.com/universe-manual.html
[02:42] <Keybuk> that is the list of things MoM was not able to find a base version in Debian for
[02:43] <Keybuk> each one is linked to the patch from the Debian -1 if it exists
[02:43] <bddebian> whew, I only have 1 on that list :-)
[02:43] <Keybuk> in a few cases (like xorg) the patch won't exist ... so that will need to be a truly manual merge
[02:44] <fabbione> Keybuk: thanks
[02:45] <Keybuk> ok, kernel given back
[02:45] <Keybuk> seb128: yes?
[02:45] <Keybuk> seb128: no builds recorded .. right
[02:45] <Keybuk> probably needs me to shove my arm into the queue builder again
[02:47] <Keybuk> yes, we're still in publish-distro ... the days are too long
[02:52] <seb128> Keybuk: is there any public queue order or something like that?
[02:53] <Keybuk> https://launchpad.net/distros/ubuntu/+builds?build_state=pending
[02:53] <seb128> https://launchpad.net/distros/ubuntu/+builds?build_state=pending&build_text=pango
[02:53] <Keybuk> you'll note there's nothing in the queue
[02:53] <seb128> not listed
[02:53] <seb128> right
[02:53] <seb128> what does that mean?
[02:54] <Keybuk> it means I need to do this
[02:54] <ogra> *shudder*
[02:54] <bddebian> hmm
[02:54] <seb128> Keybuk: thank you ;)
[02:55] <bddebian> Hehe, response from Debian Developer:  "What is a desktop file" :-)
[02:55] <ogra> seb128, i cant right click and suspect the main menu to be at fault for gnome-panel taking up 65% CPU, do you know of any key combo to remove an applet ?
[02:55] <Keybuk> seb128: basically, the problem is that the buildd queue builder (which finds all the new sources that need building) cannot run during the publisher's cron.daily
[02:56] <Keybuk> and right now, for various reasons, cron.daily is taking the full hour
[02:56] <Keybuk> so there's no time for the queue builder to run
[02:56] <Keybuk> unless it's run manually
[02:56] <Keybuk> which is what I've just done
[02:56] <seb128> ogra: gconf-editor? :)
[02:56] <ogra> ah, thanks ...
[02:56] <seb128> Keybuk: ah, ok
[02:56] <Keybuk> so now we have another 300 things in the build queue
[02:56] <Keybuk> and one of them is pango1.0
[02:56] <Keybuk> https://launchpad.net/distros/ubuntu/+source/pango1.0/1.13.2-1ubuntu1
[02:57] <Keybuk> ^ has a "Builds of pango1.0" portlet
[02:58] <bddebian> Anyone happen to know when Debian is going to make the move to Python 2.4?
[02:58] <seb128> right
[02:58] <seb128> Keybuk: thank you :)
[02:58] <seb128> bddebian: some weeks ago?
[02:59] <tseng> bddebian: there is a new policy
[02:59] <tseng> bddebian: python2.4-foo is not the way to go apperantly
[03:01] <Amaranth> i think doko would be the person to ask about that
[03:02] <ogra> seb128, yay
[03:02] <ogra> seb128, i can reliably report the main menu in gnome is proken in current edgy on ppc :)
[03:02] <ogra> *broken as well
[03:03] <fabbione> ogra: you just destroyed my theory
[03:03] <seb128> ogra: don't use edgy then
[03:03] <ogra> fabbione, which was ?
[03:03] <ogra> seb128, :P
[03:03] <fabbione> ogra: edgy is bugless
[03:03] <Amaranth> heh
[03:04] <ogra> fabbione, well, apart from not having a keyboard driver in the kernel for my ibook and from the panel eating 65% CPU and the main maenu flickering wildly .... it *is* bugfree :)
[03:04] <bddebian> tseng: ?
[03:05] <fabbione> ogra: ok, then please go and fix bgu #51923
[03:05] <fabbione> bug even
[03:05] <jsgotangco> lol
[03:05] <ogra> bug 51923 ?
[03:05] <Ubugtu> Malone bug 51923 in Ubuntu "Please package footiefox (FireFox extension)" [High,Confirmed]  http://launchpad.net/bugs/51923
[03:05] <ogra> haha
[03:05] <bddebian> footiefox? Hehe
[03:06] <Amaranth> high?
[03:06] <fabbione> Amaranth: read the bug
[03:06] <pitti> Hi Keybuk
[03:06] <ogra> fabbione, only high ? 
[03:06] <Amaranth> ah, football
[03:06] <Amaranth> germany lost :/
[03:06] <ogra> fabbione, well, you guys play the final ... so do something for it :P
[03:06] <fabbione> ogra: i am sure you will get to critical.. you play saturday :)
[03:06] <jsgotangco> hahaha
[03:06] <ogra> i wonder if they willl put any effort into that game :)
[03:07] <jsgotangco> i bet it was painful
[03:07] <fabbione> jsgotangco: very!
[03:08] <ogra> fabbione, you must admit, for a team that was completely new and partially players were even added weeks before the championship started they did very very well
[03:08] <jsgotangco> beginner's luck!
[03:08] <ogra> if they stay like that and just train over the next years they'll kick your butts next time :)
[03:08] <fabbione> ogra: i didn't criticize at all how Germany did play.. it was a very balanced match
[03:08] <ogra> yep
[03:09] <fabbione> i still did suffer till the end
[03:09] <bddebian> Goddamn I hate active stupid users...
[03:09] <ogra> i found it impressing ... i wouldnt even have expected them to be that good
[03:09] <fabbione> scoring 2 goals in the last 90 secs was well.. good
[03:09] <\sh> ogra: germany never won against italy during a World/European Championship. but the statement: "Germany never lost a game in Dortmund" is now wrong
[03:09] <ogra> luck ;) both teams deserved to win imho ...
[03:10] <bddebian> fabbione: Hey, what's all this X crap from you? :-)
[03:10] <fabbione> bddebian: helping the new X guy to stretch his wings
[03:10] <ogra> bddebian, he leads us to new edgys :)
[03:10] <fabbione> but as you said.. it's crap..
[03:10] <Amaranth> stretch his legs?
[03:11] <fabbione> they are barely include headers
[03:11] <fabbione> Amaranth: no wings... X have angels...
[03:11] <fabbione> Hell Angels
[03:11] <Amaranth> they ride motorcycles? :P
[03:11] <fabbione> Amaranth: yes here in dk they do. they are one of the most dangerous group of people around
[03:12] <bddebian> ogra: Well fabbione, swore to me he wasn't touching X ;-)
[03:12] <ogra> so can i find any reviewer to take a look at https://wiki.edubuntu.org/StudentControlPanelCompletion =
[03:12] <ogra> ?
[03:12] <fabbione> bddebian: and i am not touching it
[03:12] <Amaranth> grr, kernel set the boot line to hda1 again
[03:12] <fabbione> i am only merging it to help somebody that will do my job :)
[03:13] <fabbione> bddebian: or do you expect us not to pass the cluebat
[03:13] <fabbione> ?
[03:13] <bddebian> fabbione: Of course not, isn't it "you are on your own fool.."? ;-)
[03:14] <bddebian> Of course, before you yell at me, you know I am kidding :-)
[03:16] <zul> mmm...clue bat
[03:17] <fabbione> i am melting
[03:17] <fabbione> later
[03:18] <ogra> fabbione, take a printout of https://wiki.edubuntu.org/StudentControlPanelCompletion with you and review it ;)
[03:20] <jpatrick> ogra: "he is able to monitor the students desktops via vnc to see if his suspicion is true." sneaky :(
[03:21] <bddebian> ogra: Persistent aren't you? :-)
[03:21] <ogra> :)
[03:21] <bddebian> I wonder how many DDs I can annoy today..
[03:22] <zul> i awy atleast 2 :)
[03:22] <bddebian>  awy? :)
[03:23] <azeem> who's the new X guy?
[03:24] <bddebian> azeem: rodarvus
[03:25] <jsgotangco> hail our the new xorg czar
[03:26] <jsgotangco> but aren't czars end up being beaten up by a mob?
[03:26] <jsgotangco> heh
[03:26] <bddebian> jsgotangco: Oh, I am sure he will :-)
[03:27] <zul> jsgotangco: actually they wound up being shot :)
[03:27] <jsgotangco> lol
[03:34] <bddebian> Don't do it ;-)
[03:34] <rodarvus> bad fabbione
[03:36] <ogra> rodarvus, if fabbione is bad he turns into pinhead :)
[03:37] <ogra> that was still the calm fabbione :)
[03:37] <jsgotangco> scary
[03:49] <bddebian> I packaged up a newer version of attal and pinged the Debian folks weeks ago and have heard nothing back.  Should I upload it?
[03:52] <TheMuso> If anybody on the spec review team could give one final glance over spoken-boot that would be great. It was approved, but wasn't set as an edgy goal. I changed that and set it back to review just to make sure this is ok. Thanks in advance.
[04:05] <ogra> Keybuk, dpkg-source: error: file kdeedu_3.5.2.orig.tar.gz has size 32344987 instead of expected 29849290
[04:05] <ogra> i just try to build the original debian package, got all three files from mom
[04:06] <pitti> ogra: then we have a different orig.tar.gz with the same name
[04:07] <ogra> pitti, hmm
[04:07] <ogra> thats evil
[04:07] <pitti> ogra: you need to apply the diff.gz manually then
[04:07] <pitti> ogra: (Debian's)
[04:07] <ogra> pitti, yes, i know
[04:07] <pitti> ogra: and chmod 755 debian/rules
[04:07] <pitti> ogra: yes, it's evil :/
[04:07] <ogra> i was just wondering why i got that error
[04:07] <ogra> but indeed mom can only use one orig.tar.gz :)
[04:29] <seb128> when is the next autosync from Debian run?
[04:29] <Riddell> ping ubuntu-reviewers, kubuntu specs to be reviewed: adept-usability kde-kiosk-profiles kubuntu-accessibility kubuntu-printer-sharing kubuntu-system-settings-usability kubuntu-edgy-package-manager
[04:29] <seb128> we need to the new pycairo to fix pygtk apps non running atm
[04:30] <ogra> hrm, gtk2-perl is broken again ...
[04:40] <ogra> pitti, hmm, how does mom get a orig.tar.gz for a package that *is* not in ubuntu yet ... kdeedu has no 3.5.2 in ubuntu 
[04:40] <ogra> Keybuk, ^^^ ?
[04:41] <ogra> so it must be the debian orig.tar.gz
[04:44] <Riddell> ogra: is touch broken for you on amd64 in edgy?  it doesn't want to set timestamps for me
[04:44] <ogra> Riddell, mount /proc :)
[04:45] <Riddell> bah, more chroot hassle
[04:47] <fabbione> ogra: sorry i managed to close myself inside the fridge
[04:48] <fabbione> ogra: do you still need review for that spec?
[04:50] <bddebian> fabbione: Nice, are you cooler now? :-)
[04:51] <fabbione> bddebian: it depends what part of my body you are referring to
[04:51] <bddebian> Hmm
[04:54] <ogra> fabbione, yep
[04:54] <fabbione> ogra: 
[04:54] <fabbione> ogra: ok
[04:54] <ogra> wow, thanks 
[04:55] <fabbione> ogra: ok i will review it
[04:55] <ogra> i think its pretty straight forward ...
[04:55] <fabbione> just gimme a few minutes
[04:57] <bddebian> Are we going to have libgl1-mesa-swx11-dev in Edgy?
[04:59] <Kamion> it's in Debian unstable, so ...
[04:59] <bddebian> Damnit, another blocked merge..
[05:00] <bddebian> I guess I'll just wait till UVF to merge everything.. ;-P
[05:01] <Kamion> \sh: the subject lines of bug 51976 and bug 51978 do not match the package names you've assigned them to; please clarify
[05:01] <Ubugtu> Malone bug 51976 in libsdl-sge "[Edgy MoM]  sync libxbase 2.0.0-8 from unstable" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/51976
[05:01] <Ubugtu> Malone bug 51978 in livehttpheaders "[Edgy MoM]  sync libhttpheaders 0.12-2 from unstable" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/51978
[05:03] <fabbione> ogra: Anselmo <- WORST NAME EVAR
[05:03] <bddebian> heh
[05:03] <bddebian> ogra: Put him back in the fridge ;-P
[05:03] <Kamion> 16:03 < Kamion> Would someone who's experienced in writing specifications mind writing some use cases for https://wiki.ubuntu.com/UbuntuServerTasks? I've done the rest of the specification, but I couldn't
[05:03] <Kamion>                 quite face the use cases ...
[05:03] <Kamion> 16:03 < Kamion> some way to make them not just effectively a copy of the design would be nice
[05:03] <Kamion> neuralis: ^-- maybe you could?
[05:03] <tseng> bddebian: ?
[05:04] <ogra> fabbione, feel free to put a new one in, its a wiki ;)
 bddebian: python2.4-foo is not the way to go apperantly <-- ?
[05:04] <tseng> what part was confusing
[05:04] <Kamion> see debian-devel-announce@
[05:05] <bddebian> tseng: All of it?
[05:05] <Kamion> one of the more recent posts has a link to the new python policy
[05:05] <tseng> in the previous line i mentioned there was a new policy
[05:05] <bddebian> Aye
[05:05] <tseng> they were meant to be read as a pair
[05:05] <fabbione> ogra: "/usr/share/doc/student-control-panel" is not policy compliant either and all that section is not clear at all
[05:06] <bddebian> tseng: Ah, OK
[05:06] <bddebian> Kamion: OK
[05:07] <fabbione> ogra: otherwise it looks ok to me
[05:07] <ogra> fabbione, hmm, you want the script there (it will be a five liner calliing chroot $LTSPROOT apt-get install x11vnc)
[05:07] <ogra> ?
[05:07] <fabbione> ogra: no, the script can't be in share/doc
[05:07] <fabbione> ogra: share/$pkg/ is fine
[05:08] <fabbione> ogra: plus you could install the package in the chroot without a script
[05:08] <fabbione> ogra: iirc you still create the chroot on the server to boot
[05:08] <neuralis> neuralis: i'll take care of it
[05:08] <neuralis> er.
[05:08] <ogra> fabbione, yes, thats the plan but i cant call it from postinst
[05:08] <neuralis> Kamion: i'll take care of it.
[05:08] <Kamion> neuralis: thanks!
[05:08] <fabbione> ogra: you need to explain me what you are trying to do. it's not clear from the spec
[05:08] <ogra> and you could also use it on ubuntu with no existing client chroot
[05:09] <ogra> ok
[05:09] <ogra> i'll change that section
[05:09] <Gloubiboulga> dholbach, you want to merge the experimental packages for goffice and gnumeric, right?
[05:09] <fabbione> ogra: ok and expand it if required. it doesn't need to be in one long sentence :)
[05:09] <bddebian> dholbach?  Where is dholbach? :-)
[05:09] <fabbione> ogra: you are allowed to use 2/3 of them :P
[05:09] <ogra> heh, yep, will do :)
[05:09] <Gloubiboulga> bddebian, he's everywhere
[05:12] <bddebian> Gloubiboulga: Aye, just haven't "seen" him lately
[05:13] <iwj> Ahhh, it's not finding the chrome _at all_.
[05:13] <ogra> iwj, xulrunner doesnt need chrome :P
[05:13] <dholbach> Gloubiboulga: yeah, that was the plan
[05:13] <dholbach> bddebian: hellas :)
[05:14] <Gloubiboulga> dholbach, ok
[05:14] <neuralis> Kamion: some of these tasks look suspicious.. should xen really be a task?
[05:14] <bddebian> Daniel!!
[05:14] <dholbach> Barry!!!1111!! :)
[05:15] <tseng> dholbach!!!!
[05:15] <dholbach> hey tseng
[05:15] <dholbach> rodarvus: congratulations to your first upload! :-)
[05:16] <bddebian> heh
[05:16] <rodarvus> dholbach, thanks! glad you noticed :)
[05:16] <Kamion> neuralis: dunno, I was just going off the BoF minutes, I was kinda tuned out during that
[05:17] <Kamion> neuralis: I'm not hugely convinced by that one, no
[05:17] <rodarvus> pitti, praise fabbione and Mithrandir :)
[05:17] <neuralis> Kamion: yeah, the same for some of the other tasks. i'll take a cluebat to it.
[05:17] <Hobbsee> jdub: oh *crap*
[05:18] <Hobbsee> anyone got anywhere i can escape to in the next few days?
[05:18] <pitti> rodarvus: I do! :)
[05:18] <tseng> only if you can make it as far as Philly
[05:18] <bddebian> hehe, I was going to say that
[05:18] <Kamion> neuralis: ta
[05:18] <tseng> pretty long trip
[05:18] <bddebian> Hi Hobbsee
[05:18] <Hobbsee> hi bddebian 
[05:18] <Hobbsee> tseng: damn.
[05:19] <tseng> ?
[05:20] <Hobbsee> tseng: i got home about 1am, curfew was 12.
[05:21] <zul> oh oh..
[05:21] <Hobbsee> tseng: i was supposed to be home by a specific time, and couldnt be.
[05:21] <tseng> yes?
[05:22] <Hobbsee> so mum's not happy
[05:22] <pitti> Hobbsee: then come home at 4am, then nobody will be angry any more; instead they'll be happy that you got back :)
[05:22] <ogra> Hobbsee, offer lawn mowing or car washing to her :)
[05:22] <Hobbsee> pitti: heh, i wish it worked like that.  i chose not to drive earlier cos i was tired.  but she'll still whinge, as that's twice in one week.
[05:22] <Hobbsee> ogra: heh
[05:23] <\sh> Kamion: sorry...
[05:23] <Hobbsee> no, she'll just get utterly and totally pissed off and lecturing, i think.
[05:23] <\sh> Kamion: the power of autocompletion :(
[05:27] <\sh> Kamion: sync request for livehttpheaders corrected, #51976 rejected and sync request libxbase newly created 
[05:28] <ogra> Keybuk, ping
[05:28] <Yagisan> Hobbsee: you poor thing. Want me to pop over and give your mum the wrong idea ;)
[05:29] <dholbach> tseng: thanks for pushing me
[05:29] <tseng> dholbach: np
[05:29] <Hobbsee> Yagisan: you know, i'd avoided comments like that *all* night - it felt so odd.  pity it didnt work this mornign too.
[05:30] <Kamion> \sh: in future, no need to reject, just change the package name
[05:31] <\sh> Kamion: right, k
[05:33] <fabbione> morning mdz
[05:34] <Keybuk> ogra: pong
[05:34] <Hobbsee> hi fabbione 
[05:35] <fabbione> hey Hobbsee 
[05:35] <ogra> Keybuk, where does the orig.tar.gz in the kdeedu merge come from ? 
[05:35] <ogra> (th eone for 3.5.2)
[05:36] <Keybuk> please be more specific
[05:36] <Keybuk> which orig.tar.gz, for which part of the merge (base, ubuntu or debian)
[05:36] <ogra> i cant build the debian package thats on mom
[05:36] <Keybuk> then it is likely the Ubuntu one
[05:36] <ogra> hmm, i thought there was no 3.5.2 in ubuntu yet
[05:36] <Keybuk> if Debian and Ubuntu have a different orig.tar.gz, you get whichever gets copied into the directory second ;)
[05:36] <ogra> in any case its not the upstream one ...
[05:37] <ogra> hm
[05:37] <Keybuk> ubuntu: 4:3.5.2-0ubuntu9
[05:37] <Keybuk> ubuntu had 3.5.2 to begin with
[05:37] <ogra> gah, i'm blind
[05:37] <Keybuk> given the resulting merge is also 3.5.2, you'll need to upload with the Ubuntu orig.tar.gz
[05:37] <ogra> well, the merge is completely broken
[05:38] <Keybuk> you can grab the Debian tarball from Debian directly, or casey:/srv/patches.ubuntu.com/pool/debian/k/kdeedu
[05:38] <ogra> yep, did that, buiuld is running
[05:38] <Keybuk> ogra: how is it "completely broken" ?
[05:38] <ogra> but the upstream source is different
[05:38] <ogra> it isnt buildable ..
[05:38] <Keybuk> right, there isn't anything mom can do in that circumstance
[05:38] <Keybuk> manual merge time
[05:38] <ogra> there seem to be pieces missing etc
[05:38] <ogra> (from the tarball)
[05:38] <Keybuk> that I doubt
[05:39] <seb128> Keybuk: when is the next standard sync from Debian going to be done (ie: for packages already in sync)?
[05:39] <Keybuk> I suspect you will find that the merge makes perfect sense if you compare the three source packages
[05:39] <ogra> Keybuk, dpkg-source: error: file kdeedu_3.5.2.orig.tar.gz has size 32344987 instead of expected 29849290
[05:39] <ogra> dpkg agrees with me :)
[05:39] <Keybuk> ogra: now you're just being silly :)
[05:39] <Keybuk> obviously the Debian source can't be unpacked ... the wrong orig.tar.gz is in the directory
[05:39] <seb128> Keybuk: we need pycairo 1.2.0-1 to fix pygtk, if somebody could force a sync now instead of waiting on the next (daily?) run... :)
[05:40] <Keybuk> seb128: I'll do it now
[05:40] <ogra> Keybuk, the upstream tarball is missing stuff ... 
[05:40] <ogra> (ours)
[05:40] <seb128> Keybuk: thank you
[05:40] <Keybuk> ogra: then that's our fault, not mom's :p
[05:40] <ogra> Keybuk, yes, i didnt blame mom for it :)
[05:40] <Riddell> ogra: what's it missing?
[05:40] <Keybuk> probably worth uploading a new 4:3.5.2.0 or something with the Debian .orig.tar.gz
[05:41] <Riddell> or just move to 3.5.3
[05:41] <ogra> is there a 3.5.3 in debian 
[05:41] <Riddell> packages.d.o says no
[05:44] <ogra> Riddell, 
[05:44] <ogra> ogra@edubuntu:/mnt/devel/packages$ rm -r kdeedu-3.5.2/debian
[05:44] <ogra> ogra@edubuntu:/mnt/devel/packages$ rm -r kdeedu-3.5.2-1ubuntu1/debian
[05:44] <ogra> ogra@edubuntu:/mnt/devel/packages$ diff -ruN kdeedu-3.5.2/ kdeedu-3.5.2-1ubuntu1/|wc -l
[05:44] <ogra> 1050367
[05:44] <ogra> there is missing a lot ...
[05:45] <bddebian> eeks
[05:46] <Riddell> ogra: anything important, i.e. not created by buildprep?
[05:46] <Keybuk> TheMuso: ping
[05:46] <ogra> Riddell, thats the unpacked source tarball ... no debian/ubuntu changes
[05:47] <ogra> the upstream sources differ ...
[05:47] <ogra> i have no idea how to merge that apart from doing a completely new package based on the debian version ...
[05:48] <Riddell> well you should start by getting 3.5.3
[05:48] <ogra> (well, we could carry around a 1050367 lines long patch ...)
[05:49] <ogra> Riddell, but then we'll have that case again next time we'll merge ...
[05:49] <Riddell> then copy the latest debian packaging, copy the kubuntu patches in debian/patches and debian/patches/common and make sure any changes in KUBUNTU-DEBIAN-CHANGES are included and voila
[05:49] <ogra> unless i can be 100% sure the upstream tarball doesnt change before debian builds it
[05:50] <Riddell> merge the changelogs too of course
[05:51] <ogra> still, how can i be sure thats mergeable next time if we dont use the debian packages at some point ?
[05:51] <Riddell> we can't use the debian packages, they're a version behind
[05:51] <ogra> kdeedu is a hell of a package ... i wouldnt want to touch it again if there is *any* way to sync it
[05:52] <ogra> phew, ok
[05:52] <Riddell> the only part you need to care about is the debian directory, anything outside that is automake stuff
[05:52] <ogra> sure
[05:53] <ogra> i still dont undestand why our upstream tarball is 3M smaller than debians though ...
[05:55] <sladen> ogra: if you unzip the tarballs, how does the size of the tars compare?
[05:56] <pitti> ogra: gzip -9?
[05:57] <ogra> ogra@edubuntu:/mnt/devel/packages$ ls -lh kdeedu*.tar
[05:57] <ogra> -rw-r--r-- 1 ogra ogra 94M 2006-07-04 12:43 kdeedu_3.5.2-1ubuntu1.src.tar
[05:57] <ogra> -rw-r--r-- 1 ogra ogra 29M 2006-03-30 13:47 kdeedu_3.5.2.orig.tar
[05:58] <ogra> well ... wait ...
[05:59] <Riddell> ogra: the debian packager has done it as bz2 inside .orig.tar.gz
[06:02] <ogra> Riddell, yep, looks like it ...
[06:03] <Riddell> ogra: however it looks like debian has changed to cdbs so you should just start by coping over their latest packaging (to kdeedu 3.5.3)
[06:03] <ogra> yep
[06:13] <neuralis> Kamion: done, let me know if you need anything else
[06:15] <mdz> pitti: regarding bug 45406, should I review what is there or are you going to revise it based on the comments?
[06:15] <Ubugtu> Malone bug 45406 in libgnomecups "memory leak in gnome-cups-icon" [Unknown,Fix released]  http://launchpad.net/bugs/45406
[06:16] <mdz> oh, I see a new one has been attached, though I didn't receive mail about it. odd
[06:16] <pitti> mdz: hm, I didn't get the last one as mail either; but maybe it'll still arrive
[06:17] <ivoks> hi
[06:17] <ivoks> new one is better
[06:17] <bddebian> Heya ivoks
[06:17] <ivoks> mdz: i add it couple of minutes ago
[06:18] <ivoks> bddebian: hello, what's up?
[06:20] <Riddell> carlos: are you able to take ownership of a l10n team?
[06:20] <rodarvus> mdz, do you think you'll be able to review fully-automatic-swap-server and ltsp-login-and-session-handling today, or should I ask someone else on the ubuntu-reviewers group?
[06:20] <carlos> Riddell: no, I don't have such rights, but we can ask an admin
[06:21] <Riddell> carlos: who's one of them?
[06:21] <carlos> Riddell: is there any abuse of the system?
[06:21] <Riddell> carlos: nope, just the en-gb admin is without internet
[06:21] <rodarvus> s/be able/have time/
[06:21] <Keybuk> rodarvus: I'll take the first one
[06:21] <rodarvus> Keybuk, thanks!
[06:21] <carlos> Riddell: https://launchpad.net/people/admins
[06:23] <mdz> rodarvus: ubuntu-reviewers
[06:23] <rodarvus> mdz, I'll ask them, thanks!
[06:24] <bddebian> ivoks: Not much thanks, you?
[06:25] <mdz> why do people keep trying to subscribe to the technical-board list?
[06:25] <mdz> I wonder if it should be hidden from the index
[06:25] <Riddell> do I really needs to ask all the ubuntu-reviewers to look at all the kubuntu specs still to be reviewed?
[06:26] <ivoks> bddebian: same here :)
[06:26] <mdke> mdz: the CC list is hidden
[06:27] <mdz> mdke: good point, I'll do the same for TB then
[06:27] <mdke> rather more surprisingly, so is ubuntu-server
[06:27] <Keybuk> mdz: I just did already :p
[06:27] <mdz> Keybuk: yes you did
[06:40] <adamant1988> can anyone tell me what kind of packages will be included in the commercial repos?
[06:40] <Keybuk> commerical ones
[06:41] <adamant1988> nice.  But i mean would a DVD play back program that allows for DMCA compatible dvd playback be in there?
[06:43] <Keybuk> if there was a piece of commerical software that did that for Linux and was appropriately licenced to allow distribution (which I believe is not possible)
[06:43] <ogra> adamant1988, if you have to offer one we're alloed to distribute by your company, we could put it in there, yes
[06:43] <ogra> Keybuk, sure, why shouldnt it be licensed appropriate ... if the company that offers it pays for all the patents etc ...
[06:43] <adamant1988> keybuk, it's possible.  Linspire offers LEGAL dvd playback
[06:44] <seb128> adamant1988: they probably pay for it
[06:44] <Keybuk> ogra: company has to pay for patent per-seat, no?
[06:44] <Keybuk> adamant1988: you pay for linspire, it's not freely downloadable
[06:44] <adamant1988> i'd pay for the program
[06:45] <ogra> Keybuk, and ? then you need a key to activate the proggy ...
[06:45] <lukaswayne9> After latest edgy updates, X.org redraws things VERY slowly.  Should I report a bug, or is too early in the release cycle?
[06:45] <Keybuk> lukaswayne9: X is very much being changed atm
[06:45] <lukaswayne9> Keybuk: may I ask what changes are happening?  7.1 transition?
[06:46] <Keybuk> lukaswayne9: sync with debian
[06:47] <lukaswayne9> Keybuk: I guess I'll wait a bit to report a bug, things will probably get flushed out once the sync finishes
[06:47] <ogra> lukaswayne9, give it until UVF to stabilize :)
[06:50] <seb128> Keybuk: could you run the buildd queue builder? Would be nice to have GTK 2.10 planned for build :)
[06:50] <Keybuk> seb128: cron.daily is still running
[06:51] <Keybuk> and, dude, you've only just UPLOADED the frickin' thing
[06:51] <Keybuk> it hasn't even had the source published yet
[06:51] <bddebian> heh
[06:51] <Keybuk> the buildds don't pick source off your hard drive, you know
[06:52] <seb128> Keybuk: I've uploaded like half an hour ago I think
[06:52] <pitti> Keybuk: that'd be even better than building from accepted :)
[06:52] <Keybuk> seb128: so you missed a cron.daily run
[06:52] <Keybuk> it'll be published tomorrow
[06:52] <Keybuk> then built the day after
[06:52] <Keybuk> and then the binaries published the day after that
[06:52] <ogra> Keybuk, we could do that with zeroconf :)
[06:53] <seb128> Keybuk: right, but I just would like to be around when the package becomes available so I can fix any issue with it without letting it b0rked until tomorrow morning :)
[06:53] <robertj> (worst thread ever)
[06:53] <seb128> Keybuk: anyway, no hurry, I'll wait the some "days" required for it :)
[06:54] <pitti> seb128: before I want python-defaults to be built, which is sitting in needs-build since this morning :)
[06:54] <Keybuk> of course
[06:54] <Keybuk> we won't get a build queue run today anyway
[06:54] <seb128> pitti: doesn't look like
[06:54] <Keybuk> pitti: no, the build queue is empty
[06:55] <Keybuk> pitti: python-defaults built 3 minutes ago <g> -- https://launchpad.net/+builds/+build/221939
[06:55] <pitti> Keybuk: oh, whoa, it must have been built in the last 10 minutes
[06:55] <pitti> Keybuk: \o/
[06:55] <bddebian> pitti: :-)
[06:56] <pitti> argh, mvoooooo!
[06:56] <pitti> el: Encountered a section with no Package: header
[06:56] <Keybuk> oh,
[06:56] <pitti> breaks apt and goes to holiday *sigh*
[06:56] <Keybuk> this could be fun
[06:56] <Keybuk> cron.daily has so far been running for 52 minutes
[06:56] <pitti> s/el:/E:/
[06:56] <Keybuk> and hasn't even reached publish-distro yet
[06:56] <Keybuk> !!!!
[06:56] <seb128> pitti: that's your languagepack source, right?
[06:56] <pitti> seb128: indeed
[06:56] <seb128> hehe :)
[06:57] <pitti> 'Problem with MergeList /var/lib/apt/lists/people.ubuntu.com_%7epitti_langpacks_daily_dapper-updates_._Packages'
[07:00] <crimsun> pitti: hi, how how does -security handle GPG key retrieval for keys used to sign uploads? I presume my uploads of openvpn to breezy-security have failed due to a key expiration (since I've received no accept or reject e-mail), which seems odd because the precise key used to sign the upload is accepted for Edgy uploads.
[07:02] <bddebian> Heya crimsun
[07:02] <bddebian> Did mine not go through either?
[07:03] <pitti> crimsun: -security is on a different host (jackass); you need to ping elmo to refresh your key there, I assume
[07:03] <pitti> bddebian: what did you upload?
[07:03] <crimsun> bddebian: I presume you uploaded to security.upload.ubuntu.com?
[07:03] <pitti> crimsun: let me look into the log
[07:03] <bddebian> crimsun: Yes
[07:03] <pitti> crimsun: indeed, it's expired
[07:04] <crimsun> pitti: ok, thanks much
[07:06] <crimsun> elmo: please refresh 0xC88ABDA3 for -security uploads, thank you  [context: < pitti> crimsun: -security is on a different host (jackass); you need to ping elmo to refresh your key there, I assume] 
[07:09] <mdz> sivang: why do you want to have two separate menu items for backups?  seems confusing
[07:28] <wasabi_> I'd sure like to see swapd work at some point.
[07:29] <fabbione> wasabi_: why?
[07:30] <wasabi_> I think it's much more flexible than a static swap partition.
[07:30] <wasabi_> And can handle situations better, such as extending the swap on the fly.
[07:30] <wasabi_> (with the posibility of raising an event to the user that it happened)
[07:37] <pygi> mdz, poke?
[07:37] <mdz> pygi: yes?
[07:37] <pygi> there isn't library for burning, but we agreed to work on that for edgy+1
[07:37] <pygi> feature freeze for edgy is too soon
[07:38] <ogra> pygi, ?
[07:38] <ogra> pygi, what about the libburn stuff ?
[07:39] <fabbione> wasabi: it's something you can do even now, if you install your machine properly with lvm 
[07:39] <fabbione> wasabi: or use loop files to achieve that
[07:39] <fabbione> wasabi: nothing stops you to add a loop device as partition
[07:39] <fabbione> s/partition/swap &/
[07:40] <pygi> ogra, any python bindings for that?
[07:40] <ogra> i dont think so, but they should be easier to add than to write a burn lib from scratch
[07:40] <ogra> and you dont need cdrecord
[07:41] <pygi> ogra, right :)
[07:41] <wasabi_> fabbione: Sure, mostly what I mean, is swapd does it "automatically".
[07:41] <wasabi_> Creating loop swap files as needed.
[07:41] <wasabi_> I think there's a value in having that easily apt-get installable and Just Work.
[07:43] <rodarvus> Keybuk, ping
[07:44] <Keybuk> rodarvus: heyhey
[07:44] <rodarvus> did you had time to review fully-automatic-swap-server?
[07:44] <Keybuk> I have had no time yet
[07:44] <Keybuk> it's on my list
[07:44] <rodarvus> I ask because I have two others I need to find someone to review :)
[07:44] <bddebian> Oh no, one of my Debian BTS submissions went to lamont :)
[07:45] <rodarvus> edubuntu-xfce-desktop and ltsp-login-and-session-handling
[07:52] <mdz> rodarvus: edubuntu-xfce-desktop should probably say something about how the seed will be maintained.  presumably it needs to be kept in sync with xubuntu-desktop
[07:52] <mdz> rodarvus: also, how will it differ from xubuntu-desktop?  does it need to?
[07:52] <ogra> mdz, the idea was to only have xfce
[07:52] <ogra> we have nautilus on the CD already, no need for a different filemaneger for example
[07:52] <mdz> ogra: and no applications at all?
[07:53] <rodarvus> it will only need to be different from xubuntu-desktop if we need to create extra packages with different configuration, specific for Edubuntu
[07:53] <ogra> well, sure applications as well, but the main complaint iss that there is no light desktop in edubuntu ...
[07:53] <ogra> the CD has all other bits ...
[07:53] <mdz> ogra: I'm asking why you can't use xubuntu-desktop instead of creating a new seed and metapackage
[07:54] <ogra> i dont want to use up the CD space we have now with xubuntu packages
[07:54] <mdz> because the spec doesn't say how it will be different
[07:54] <ogra> i think highvoltage wanted edubuntu branding for it
[07:54] <highvoltage> mdz: another reason is that xfce needs to be aware of edubuntu specific things, ie. use the same wallpaper, similar menus, etc
[07:54] <bluefoxicy> heh
[07:54] <ogra> highvoltage, ?
[07:55] <mdz> don't tell me; write it in the spec
[07:55] <bluefoxicy> ogra:  I had a silly thought earlier to split out the gnome/xfce desktops from *-desktop
[07:55] <ogra> :)
[07:55] <bluefoxicy> ogra:  so that it'd be ubuntu-minimal ubuntu-standard ubuntu-gnome (workable GNOME desktop) ubuntu-desktop (a bunch of GNOME applications like gimp, ekiga...)
[07:55] <bluefoxicy> and similar with XFCE
[07:56] <highvoltage> strange, i thought i had that in the rationale, but i don't :/
[07:56] <ogra> well, there is no real need for that ... 
[07:56] <ogra> why would you split the desktop package ? 
[07:56] <pygi> sivang, poke? :)
[07:56] <bluefoxicy> ogra:  If you're going to fork something off xubuntu-desktop but try to stay in sync with them, that may be a bit easier, since the common packages would be in one meta-package instead of two.  Then again, you would have ANOTHER meta-package to keep track of.
[07:57] <bluefoxicy> ogra:  so, just a thought.
[07:57] <ogra> bluefoxicy, thats donnr on a bzr level ... no need for changes on the toplevel
[07:57] <ogra> *done
[07:57] <bluefoxicy> bzr?
[07:57] <bluefoxicy> BZflag Reloaded?
[07:57] <ogra> bazaar
[07:58] <bluefoxicy> .... I like my idea better.  bzflag is fun.  :)
[07:58] <bluefoxicy> anyhow.  *slips off*
[07:58] <shawarma> does anyone know when infinity will be back from his holidays?
[07:58] <fabbione> shawarma: sometimes next week i think
[07:59] <fabbione> anyway i need to get out of here
[07:59] <fabbione> later
[07:59] <shawarma> fabbione: Thanks.
[07:59] <mdz> doko: why do we want an i386->amd64 cross compiler?
[08:05] <doko> mdz: a) a faster compiler for i386 only, b) correct code for -m64. I don't know if the latter is still valid. need to find some other people to validate that
[08:09] <mdz> doko: reviewed with comments
[08:11] <bluefoxicy> i386->amd64 is faster?  I thought an amd64 compiler building i386 code would be faster... o.o
[08:12] <bluefoxicy> (no, really, with 8 more GPRs and the freaking lot of work the compiler does shifting shit around, there should be a substantial speed gain here >.>)
[08:12] <bluefoxicy> Hey does anyone know when abouts I should expect Edgy to explode horribly-- I mean, get Xorg 7.1?
[08:13] <tseng> bluefoxicy: can you please troll somewhere else?
[08:14] <bluefoxicy> troll what?
[08:14] <bluefoxicy> Where else is there to ask that?
[08:15] <tseng> it wasnt the question, it was the horrible signal/noise, and the attitude
[08:16] <wasabi_> Linux memory confuses me.
[08:16] <wasabi_> What the heck does this figure in "top" "cached" refer to.
[08:16] <tseng> wasabi_: i think that refers to some kind of system cache for recently used files
[08:16] <bluefoxicy> wasabi_:  disk cache, every time a file is read it's stored in memory so you don't have to toy with the disk every 10mS and lag like hell.
[08:17] <wasabi_> Not exactly. Because the OOM killer kills a program vs sacrificing it.
[08:17] <wasabi_> Which suggests a different purpose.
[08:17] <\sh> re
[08:17] <bluefoxicy> or just a bug in the OOM killer.
[08:18] <wasabi_> True... but I doubt it.
[08:18] <bluefoxicy> I have seen Linux OOM kill things when I have a gig and a half of free swap
[08:18] <bluefoxicy> trust me it can have bugs.
[08:18] <wasabi_> Well, I turned my swap off, to try to understand what it's doing.
[08:19] <wasabi_> free shows 2048MB total, used 2020MB, cached 1515MB.
[08:20] <wasabi_> Which, from my original understanding meant that there was very small amounts of ram actually "used"... ie data that wasn't directly from a disk.
[08:20] <wasabi_> basically used - cached
[08:20] <bluefoxicy> yes
[08:20] <wasabi_> mmaped files. Where do they fall.
[08:21] <wasabi_> I'm guessing they don't show in used, but show in cached.
[08:26] <\sh> moins slomo
[08:27] <slomo> hi \sh 
[08:27] <\sh> guys I'm happy to be back in action :)
[08:28] <bddebian> And we are happy to have you ;-)
[08:28] <LaserJock> we are happy you are back in action too
[08:37] <ogra> fabbione, still around ? i fixed https://wiki.edubuntu.org/StudentControlPanelCompletion
[08:42] <slomo> hm, why is dash the default shell now?
[08:43] <ogra> slomo, beacuse its way faster and smaller
[08:43] <slomo> ok, good reason :)
[08:43] <ogra> no need for a user shell for script execution
[08:43] <ogra> adduser still uses bash for user accounts
[08:44] <\sh> woot? you mean I have to adjust my default shell from dash to bash?
[08:44] <ogra> nope
[08:44] <slomo> \sh: no but /bin/sh is now dash
[08:45] <ogra> the system uses dash ... but all users go on using bash
[08:45] <crimsun> thank god
[08:45] <crimsun> dash++
[08:45] <\sh> how compatible is dash to bash?
[08:45] <ogra> yeah
[08:46] <slomo> \sh: dash is 100% posix compliant and only supports that, nothing else
[08:47] <\sh> because I have to be careful then with all my shell scripts which are using bash style ;)
[08:49] <\sh> rodarvus: do you know why libxext-dev is not in x-dev? 
[08:54] <Kamion> neuralis: thanks! will look over it post-karate-training
[08:56] <rodarvus> \sh, x-dev is a dead package
[08:56] <rodarvus> X >= 7.0 is modular
[08:56] <\sh> rodarvus: ok...I just wondered why we are behaving differently from debian
[08:56] <rodarvus> we aren't
[08:57] <rodarvus> they have libxext-dev on a separate package too
[08:57] <Kamion> xorg-dev will have that sort of stuff
[08:57] <Kamion> it's a metapackage in Debian
[08:57] <Kamion> x-dev was only ever the core protocol headers
[08:57] <\sh> rodarvus: right, but I just had a package which had only libx11-dev, x-dev as build-dep but I had to add libxext-dev to it
[08:58] <Kamion> (and it'll be called x11proto-core-dev in edgy)
[08:58] <Kamion> \sh: x-dev isn't a metapackage, it's the core protocol. if you need X extension headers then you need to build-dep on libxext-dev
[08:59] <Kamion> oops, late, gotta run
[08:59] <\sh> Kamion: yeah, but I wonder why debian just used libx11-dev and x-dev as build-dep ... 
[09:12] <Burgwork> slomo, do you have any plans with tomboy or beagle for edgy?
[09:13] <slomo> Burgwork: for beagle ask tseng... for tomboy no idea yet... we'll see. but would be nice to have it installed by default
[09:14] <Burgwork> slomo, ok, just wondering. tomboy might make it upstream as well
[09:15] <slomo> Burgwork: what do you mean with upstream?
[09:15] <Burgwork> slomo, gnome is considering tomboy for .16
[09:16] <crimsun> hmm, what is polypaudio's new name [if it has one] ?
[09:16] <slomo> Burgwork: oh, cool. that would be nice :) is it likely or will it probably fail because "mono is evil"?
[09:16] <jdub> eek
[09:16] <jdub> whoa
[09:16] <Burgwork> crimsun, pulse
[09:16] <slomo> crimsun: pulse audio iirc
[09:17] <jdub> vim in edgy has all the crack on by default
[09:17] <jdub> like folding in changelogs
[09:17] <Burgwork> slomo, it might fail, there was some discussion of that
[09:17] <jdub> whoooa
[09:17] <ogra> jdub, yeah its hefty :)
[09:17] <Keybuk> jdub: :se nofoldenable
[09:17] <crimsun> Burgwork: / slomo: danke
[09:17] <Keybuk> vim7 has some serious arse-wobble going on
[09:17] <jdub> Keybuk: not sure i don't like it yet, but it was surprising. it also has shiny paren matching.
[09:18] <Keybuk> "you're editor's so FAT ..."
[09:18] <dieman> oooo. i got my stickers and cds today
[09:18] <jdub> "your" :)
[09:18] <Keybuk> yes, that too
[09:18] <jdub> hrm, i should set up pbuilder again
[09:18] <slomo> Keybuk: hi :) can you move libvisual to main (report approved by pitti a few days ago), give-back gst-plugins-base0.10 (after libvisual is in main) and gtk-sharp2? ;)
[09:18] <Burgwork> slomo, http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00457.html
[09:18] <ogra> jdub, merges.ubuntu.com :)
[09:18] <crimsun> I thought you were an emacs user, Keybuk (perhaps wrongly assumed from the u-d-a post regarding package maintenance in bzr)
[09:19] <Burgwork> slomo, and http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00253.html
[09:19] <jdub> ogra: hrm?
 hrm, i should set up pbuilder again
[09:19] <LaserJock> jdub: a good workout for you pbuilder :-)
[09:19] <slomo> Burgwork: thanks :)
[09:19] <Keybuk> crimsun: I am
[09:20] <jdub> ogra: didn't see the connection
[09:20] <Keybuk> slomo: no.
[09:20] <ogra> jdub, well, give it something to do :)
[09:20] <jdub> ogra: i want to test my own packages! (i'm lazy with build-deps withotu pbuilder)
[09:20] <jdub> does our pbuilder have ubuntu love by default?
[09:21] <ogra> if you create one in edgy, it will be an edgy pbuilder for ubuntu ...
[09:21] <Keybuk> crimsun: what about that post implied emacs user?
[09:22] <jdub> has X broken in amusing ways yet?
[09:23] <crimsun> Keybuk: sorry, not that post but one of myriad ones related where you mentioned an emacs mode?
[09:23] <crimsun> Keybuk: (my memory's pretty bad)
[09:23] <zul> are we using mdadm by default now or have we always been using it?
[09:23] <ogra> jdub, just starting 
[09:24] <ogra> i guess next week will be the fun week :)
[09:24] <jdub> as in, the latest uploads are broken?
[09:24] <ogra> no idea, after i lost my top panel and my keyboard on the ibook i got careful about upgrades for now ;)
[09:25] <Keybuk> slomo: (verbose answer; I'll move libvisual to main when there's not a publisher run going on ... gst-plugins-base0.10 doesn't need a give-back because it's already in dep-wait ... gtk-sharp2 failed for other reasons)
[09:25] <slomo> Keybuk: it failed because libbonobo was broken at that time... i fixed it yesterday. with current edgy the latest gtk-sharp2 package build just fine
[09:26] <^robertj> ogra: btw, does your ibook smell?
[09:26] <slomo> Keybuk: for gst-plugins-base0.10... nice that auto-dep-wait-removal is now implemented :)
[09:26] <Keybuk> slomo: ok, gtk-sharp2 given back
[09:27] <Keybuk> slomo: dep-wait removal has always been implemented, afaik
[09:27] <Keybuk> it just takes a couple of days
[09:27] <^robertj> ogra: I was wondering if there is some mis-calibration of some software controlled fan in there...mine stinks and other people have had issues where the fan stops spinning properly, the bottom of the keyboard starts to melt, and the whole thing smells rather putrid
[09:28] <ogra> the bottom gets very hot, yes ... but i have no probs with the fan ... and i wouldnt smell if it stinks, i'm a strong smoker
[09:28] <tseng> Keybuk: thanks
[09:29] <slomo> Keybuk: thanks :)
[09:30] <jdub> "my ibook has no nose!"
[09:30] <ogra> how does it smell ? 
[09:30] <Keybuk> well, it _looks_ like a toilet seat
[09:30] <ogra> hehe
[09:30] <highvoltage> my thinkpad has no mouth, but it can scream
[09:38] <bluefoxicy> tseng:  Not including -DFORTIFY_SOURCE in Edgy?
[09:39] <bluefoxicy> (no, I don't have an analysis or opinion on why/how/if this would/wouldn't help)
[09:39] <tseng> well, please get one :)
[09:42] <bluefoxicy> it does compile time checks (nice) and replaces strcpy() et al (I'm wary of screwing with this...) with functions that do checks where we know the buffer size and length of the data to be copied at run time but not compile time.  Obviously that has some gains in some places, not sure how significant it can be when SSP is already trapping "before any damage can be done" or how much of a trade-off this is WRT stability
[09:42] <tseng> right so SSP has a strong heuristic for writing into a buffer
[09:42] <tseng> not "these 3 functions that we dont think are safe"
[09:42] <tseng> right?
[09:43] <bluefoxicy> SSP will trap ANYTHING before a 'ret' happens, but after memory space is destroyed
[09:43] <bluefoxicy> fortify source will trap a few choice functions before memory space is destroyed, but still abort
[09:43] <tseng> well, i am thinking of the difference between -fstack-protector and -fstack-protector-all
[09:43] <tseng> if there is still such a thing
[09:43] <bluefoxicy> nicely, it'll also look at things like 'char a[4] ; strcpy(a, "this is too long")' and go "No, I'm not compiling this crap"
[09:44] <tseng> sounds nice
[09:44] <bluefoxicy> yeah.  I'm not sure if there's a way to do the compile time checks without the code replacement though
[09:45] <bluefoxicy> if fortify_source sees something like "char a[5] ; strcpy(a, passed_string);" it'll replace strcpy() with some sort of _internal_strcpy(a, passed_string, 5) and then check if strlen(passed_str) < 5
[09:46] <bluefoxicy> Which to me is minimally useful.  It won't do jack if you use glib, for example.
[09:46] <tseng> that adds nothing with ssp
[09:46] <bluefoxicy> I know.
[09:47] <bluefoxicy> oh
[09:47] <bluefoxicy> it'll also check a strcpy() if it's copying to a buffer that was JUST allocated in the same scope
[09:47] <bluefoxicy> (i.e. malloc() ... heap protection)
[09:47] <bluefoxicy> which is not that spectacular.  glib will break this again.
[09:48] <tseng> why dont you spend your time getting things to work with ssp rather than futzing with fortify_source then?
[09:49] <bluefoxicy> my regression test suite says the current edgy gcc is spitting out SSP'd code by default.
[09:49] <tseng> most of the problems in HG were from -fstack-protector-all
[09:51] <\sh> Keybuk: are syncs not removed from the merge pages?
[09:51] <bluefoxicy> personally I don't like -all; I guess it protects var_args functions, or so I've been told, but those are far and few and I would rather not sacrifice performance in a lot more places for gains in a number of places countable on one hand
[09:52] <Keybuk> \sh: they should be
[09:53] <Keybuk> \sh: assuming the sync has been published
[09:53] <Keybuk> \sh: which has not been removed?
[09:54] <\sh> I have a look...
[09:54] <bluefoxicy> tseng:  Xorg doesn't have a problem with -fstack-protector anymore right?  I can't remember if that was pie or SSP... or if it was fixed ages ago (I remember it was 'fixed' 10 times and kept still being busted)
[09:55] <tseng> it was NX
[09:55] <bluefoxicy> I mean libbitmap.a/la
[09:55] <tseng> oh, that was ssp I think
[09:55] <bluefoxicy> it would scream about duplicate symbols.
[09:55] <tseng> and I definately remember fixing it
[09:55] <tseng> yes?
[09:55] <bluefoxicy> thought so
[09:55] <tseng> maybe i just used filter-flags
[09:57] <bluefoxicy> 	ALLOWED_FLAGS="-fstack-protector -march -mcpu -mtune -O -O0 -O1 -O2 -O3 -Os"
[09:57] <bluefoxicy> tseng:  I guess you fixed it.  It definitely worked last I was on Gentoo.
[09:58] <\sh> Keybuk: e.g. alps-light1
[09:58] <tseng> -fPIE -fPIC are notably missing
[09:58] <tseng> but they arent in ubuntu, anyway
[09:58] <\sh> Keybuk: https://launchpad.net/bugs/51608
[09:58] <Ubugtu> Malone bug 51608 in alps-light1 "[not dev]  sync request of alps-light1_1.2.2-2 from debian unstable" [Untriaged,Fix released]  
[09:58] <Keybuk> \sh: looks like the sync never happened
[09:58] <tseng> -fPIE is scary
[09:58] <Keybuk> a couple went messing
[09:58] <Keybuk> I'll do it again
[09:59] <bluefoxicy> tseng:  -fPIE is nice though, if you have code in the kernel to randomize the executable and brk() base
[09:59] <\sh> Keybuk: ah ok...yeah I see it now on the source package LP page
[09:59] <bluefoxicy> Computers are so violent, executing tons of poor, innocent programs every day.
[10:00] <Keybuk> whooo
[10:00] <Keybuk> a smidgen under 2 hours for a daily
[10:00] <Keybuk> that's juuuust enough time to run the queue builder
[10:05] <bluefoxicy> tseng: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html  I can't understand this, it's muddled.  It looks like -DFORTIFY_SOURCE=1 turns on compile checking and -DFORTIFY_SOURCE=2 modifies code... maybe.  I haven't a clue and I can't find 'FORTIFY' in the body of the damn patch.
[10:07] <bluefoxicy> you know what.  Jelinek wrote it, I'll ask him.
[10:15] <crimsun> is $() preferred over ``  [for commands]  in sh?  (considering the transition to dash in Edgy)
[10:15] <elmo> both are POSIX, so it's moot
[10:16] <crimsun> elmo: ok, thanks
[10:17] <Keybuk> they just have different quoting semantics
[10:19] <wasabi_> I like $() too. Shows "containment" much better.
[10:19] <wasabi_> Also nestable.
[10:43] <wasabi_> So has anybody considered swapd in Ubuntu, vs a swap partition?
[10:43] <wasabi_> Would love to read some opinion on pros/cons
[10:44] <wasabi_> Maybe with some tuning, etc.
[10:44] <bluefoxicy> swapd never seems to de-allocate swap; and OOM's a lot.
[10:45] <bluefoxicy> it's insensitive to disk cache vs swappiness as well
[10:45] <bluefoxicy> plus linux allows like 8 swaps to be active
[10:45] <wasabi_> How so?
[10:45] <wasabi_> Curious about the swappiness problem. What's that mean?
[10:45] <bluefoxicy> wel
[10:45] <bluefoxicy> if you have a 2 gig swap partition
[10:46] <bluefoxicy> you may wind out with 300 megs used in swap, 700 megs of ram used, and 300 megs of disk cache (vm.swappiness = 60)
[10:47] <bluefoxicy> if you have no swap partition and 32 meg swap files in swapd, you may hit 950 megs of RAM used and 2 32 meg swap partitions holding 50 more megs of memory
[10:47] <bluefoxicy> leaving about 50 megs of disk cache (kernel will keep around 5-10 megs free though, so more like 40 megs)
[10:47] <bluefoxicy> oddly enough, this is less efficient.
[10:48] <wasabi_> Not understanding why. ;0
[10:53] <wasabi_> Does the kernel see the available swap as a factor in it's decision on when to cache?
[10:54] <wasabi_> Also the OOM thing, would it not be proper for swapd to be notified before the OOM killer runs, in order to expand instantly?
[10:54] <wasabi_> vs polling
[11:09] <wasabi_> Also, it might make sense to have a minswaps option for swapd, which always forces the creation of at least one swap file.
[11:10] <wasabi_> Or maybe "auto" options, which adjusts the size of swap files based on available core.
[11:29] <ogra> mdz, get off the idea of writing everything into the client chroot in ltsp :P
[11:31] <ogra> we need to get to a poiunt where ldap auth is possible and you can select between multiple servers in the network on login in the future ...
[11:32] <Burgwork> ogra, isn't that what ajmitch is working on?
[11:32] <ogra> Burgwork, yeps
[11:32] <ogra> Burgwork, i was commenting on a spec comment mdz made ...
[11:50] <pygi> sivang, poke? :)
[12:00] <TheMuso> Keybuk: pong
[12:00] <Keybuk> TheMuso: any particular reason you unapproved your own spec?
[12:01] <TheMuso> Well I thought that since it wasn't targeted for edgy, and since I wanted it to be as such, that I should run it by you guys first.
[12:01] <Keybuk> I approved it
[12:01] <Keybuk> and I marked it as proposed for edgy
[12:02] <TheMuso> I know you approved it, but I didn't see anything for it to do with edgy.
[12:02] <Keybuk> I was surprised that you marked it as "needs review" again, without making any changes
[12:03] <Keybuk> so, what would you like to do with that spec?
[12:03] <Keybuk> would you like it reviewed again?
[12:03] <Keybuk> would you like to alter it?
[12:03] <Keybuk> would you like it to be approved and targeted for edgy?
[12:03] <Keybuk> would you like it to be approved and targeted for a later release?
[12:03] <TheMuso> Yeah please
[12:03] <TheMuso> Approved for edgy if possible.
[12:03] <Keybuk> to which? :p
[12:04] <Keybuk> I see espeak is already in NEW, and the other bits should be in place for other reasons, I don't see why it wouldn't make it for edgy with your help
[12:04] <Keybuk> so approved
[12:04] <Keybuk> (again)
[12:04] <TheMuso> ok thanks, and apologies. :)
[12:05] <TheMuso> BTW how is boot message logging getting on?
[12:05] <Keybuk> no worries
[12:05] <Keybuk> I haven't started it yet
[12:05] <Keybuk> we're still doing merges until upstream version freeze next week
[12:05] <Keybuk> and then I'll begin working on specs