[01:00] <doko> elmo: please sync gdb, overwriting ubuntu changes
[02:38] <paulproteus> Out of curiosity, do you guys plan to stop using an expired SSL certificate, and/or ship the SSL certificate for the Ubuntu Wiki and Bugzilla with Ubuntu?
[02:38] <paulproteus> 'Cause that'd make life convenient if you would do both. :)
[03:18] <ispiked> paulproteus: hahah.
[03:19] <paulproteus> I mean, neither seems very hard, right?  And it makes Ubuntu look so unprofessional the way it is now.
[04:48] <psusi> it's a self signed certificate anyhow... having it be expired is just silly
[04:48] <psusi> the site admin needs to just reissue it
[05:06] <Jimbob_> psusi: Didn't Shuttleworth found Thawte?
[05:06] <daniels> yes
[05:08] <Jimbob_> :-)
[05:09] <ispiked> haha.
[05:10] <paulproteus> Jimbob_: Hah, you're right. :-)
[05:11] <paulproteus> psusi: They could ship the server certificate with Ubuntu so at least Ubuntu users wouldn't be annoyed with the certificate message each time.
[05:20] <psusi> I have no idea who shuttleworth is
[05:20] <psusi> paulproteus, even if shipped, if it is expired, the browser still complains
[05:20] <psusi> having the cert already installed as trusted just makes it not complain that it isn't signed by a trusted CA
[05:21] <paulproteus> psusi: Mark Shuttleworth founded Canonical, the company that funds Ubuntu development.
[05:21] <psusi> ohhh... that guy ;)
[05:21] <paulproteus> psusi: Right, I know.  That complaint is a pain.  It being expired makes another complaint, it's true.  I figure they could easily solve this problem by (1) shipping the cert as trusted and (2) renewing the server cert.
[05:22] <psusi> shipping it of course, would only solve the problem for people already using ubunu ;)
[05:23] <paulproteus> psusi: "Use our distro!  Going to our web site sucks less using our distro!" :)
[05:24] <psusi> lol
[07:33] <Keybuk> GOOD MORNING! :D
[07:35] <jsgotangco> morning
[07:37] <highvoltage> morning.
[07:37] <highvoltage> Keybuk: please, not so loud on a monday morning ;)
[07:41] <Keybuk> appreciately, I trust?
[07:41] <desrt> heck no
[07:42] <desrt> i'm marking.  i've had enough
[07:42] <desrt> most people are failing
[07:42] <Keybuk> marking?
[07:42] <desrt> i need to go to bed
[07:42] <desrt> exams
[07:42] <desrt> the class did bad on the last 2 exams
[07:42] <Keybuk> ahh
[07:42] <desrt> so we made the test really easy this time
[07:42] <desrt> and they're still failing :(
[07:43] <desrt> 45% average so far overall
[07:45] <Keybuk> I'd've been happy with 45% when I was at school ;)
[07:46] <highvoltage> ah, so there's hope for me then :)
[07:46] <highvoltage> and..
[07:47] <Keybuk> I got 17% for Computer Science
[07:48] <desrt> the question worst done thus far is the big coding question
[07:48] <desrt> "Design and implement a function that splits a list into two sub-lists, one containing all the even numbers from the original list, and the other all the odd numbers from the original list (both in ascending order).  Carefully document the function interface."
[07:48] <desrt> (given datatypes for linked lists of integers)
[07:48] <desrt> 36% average on this :)
[07:49] <Keybuk> sorted(num for num in list if not num % 2), sorted(num for num in list if num % 2)
[07:49] <Keybuk> easy :p
[07:50] <desrt> you have that your input list will be sorted
[07:50] <desrt> (the datatype declarations have a comment saying that lists of this type shall -always- be sorted)
[07:50] <Keybuk> that's even easier then
[07:50] <desrt> indeed
[07:50] <Lathiat> desrt: wahh
[07:50] <Lathiat> how is that hard?
[07:51] <desrt> haskell: split list = (filter even list, filter odd list)
[07:51] <desrt> Lathiat; it's not
[07:51] <jamesh> desrt: Keybuk's routine without the sorted() calls will be equivalent to the haskell
[07:52] <jamesh> desrt: since it uses generator expressions, it should also work with lists of infinite length :)
[07:52] <desrt> jamesh; as will the haskell version :)
[07:52] <jamesh> that's what I mean by it being equivalent
[07:52] <Keybuk> hell, it's a C one-liner too, depending on the list API;  for (num = FIRST(list); num; num = NEXT(list, num)) ADD(num % 2 ? even_list : odd_list, num);
[07:52] <desrt> cheap.
[07:53] <Lathiat> Keybuk: now, carefully document that ;)
[07:53] <Lathiat> and remember it must have at least 3 classes
[07:53] <jamesh> Keybuk: that won't work for infinite length lists though ...
[07:53] <desrt> if someone wrote that i'd have failed them :p
[07:53] <Keybuk> Lathiat: I said C, not C++
[07:53] <Keybuk> jamesh: why not?
[07:53] <Lathiat> Keybuk: then it needs to have at least 3 functions :)
[07:53] <Lathiat> i hate it when my uni does that
[07:53] <Lathiat> makes me pointlessly split things up
[07:53] <Keybuk> Lathiat: this is probably why I failed compsci
[07:53] <jamesh> Keybuk: because it won't finish
[07:53] <Lathiat> just so its 'modularized'
[07:53] <desrt> incidentally, they can do it all in one function
[07:54] <Keybuk> jamesh: nor will the Python
[07:54] <desrt> and the best solution i've seen was like that
[07:54] <desrt> but most of the 'working' solutions have a simple 'split' function and an auxiliary (sorted) 'insert' or 'append' function
[07:54] <jamesh> Keybuk: the generator expression will return as many elements as you ask for
[07:54] <desrt> one person (attempted to) use cons and reverse
[07:55] <ajmitch> hi pitti 
[07:55] <desrt> hi ajmitch 
[07:55] <pitti> Good morning everybody
[07:55] <siretart> good morning, Martin!
[07:55] <pitti> Hi desrt
[07:55] <desrt> good night for me :)
[07:56] <ajmitch> hello desrt :)
[07:56] <desrt> pitti; you missed my beautiful rant about how the youngin's these days don't know their respect
[07:56] <desrt> and by respect i mean "c"
[07:56] <pitti> desrt: meh?
[07:56] <dholbach> good morning
[07:56] <desrt> pitti; marking exams.  it's not going well :p
[07:56] <pitti> Hi dholbach 
[07:56] <desrt> i want christmas
[07:56] <desrt> g'morn daniel
[07:56] <dholbach> hi pitti 
[07:57] <dholbach> :)
[07:57] <dholbach> woohoo :)
[07:57] <dholbach> how are you all?
[07:57] <desrt> woh.  hug party.
[07:57] <dholbach> this is the HUG day :)
[07:57] <siretart> lol
[07:58] <siretart> conditional hugs, intersting approach ;)
[07:58] <desrt> no lapdance either
[07:58] <Keybuk> desrt: I did sign it :)  you need to recv-key
[07:58] <slomo_> gn8 desrt ;)
[07:58] <desrt> oh.  elite.
[07:58] <highvoltage> why is it hugday?
[07:59] <Keybuk> because hugging rules?
[07:59] <desrt> Keybuk; against which keyserver?
[07:59] <desrt> keyserver.ubuntu.com says key afaa6ff6 is unchanged
[08:00] <desrt> anyway.  we're short on time here since i really do need to sleep
[08:00] <desrt> 'n8' everyone.
[08:00] <dholbach> night ryan
[08:01] <Keybuk> ya know how we have days and weeks where we turn off mom and let everyone catch up?
[08:01] <Keybuk> we should do the same for Bugzilla
[08:01] <dholbach> yeah
[08:01] <dholbach> we'll have a bug day on thursday
[08:02] <Keybuk> let's have a hug day instead
[08:02] <siretart> woah, new xserver-xorg upload! :)
[08:02] <siretart> lets check the buildlog..
[08:04] <siretart> damn. still ftbfs, but this time because of syntax errors, not because of missing includes. (improvement?)
[08:08] <nomed> hi all
[08:08] <nomed> where can i find infos about how to report a bug?
[08:09] <jsgotangco> nomed, bugzilla.ubuntu.com
[08:09] <nomed> and what's the best way of fill a bug?
[08:09] <dholbach> http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
[08:09] <nomed> jsgotangco, should i include a patch?
[08:10] <nomed> mkiniramfs is brocken
[08:10] <dholbach> nomed: if you can, that's excellent
[08:10] <jsgotangco> https://wiki.ubuntu.com/BugReports
[08:11] <Keybuk> nomed: be sure to document what's wrong with it, rather than "is broken" ... sometimes even a patch doesn't make it obvious what was wrong; usually a paragraph saying what mkinitramfs did, and what you expected it to do first, suffices
[08:12] <nomed> "if [ ! d "${CONFDIR}" ] ; then" ... in /usr/sbin/mkinitramfs
[08:13] <nomed> is there any "TUT" that explain step by step the best way to fill a bug?
[08:13] <Keybuk> that's already fixed in dapper is it not?
[08:13] <Keybuk> yes, that one's already known and fixed
[08:13] <nomed> ok
[08:13] <nomed> thanks
[08:14] <nomed> i would then request a fetaure .. is it possible? or ..
[08:14] <Keybuk> features are always possible
[08:14] <nomed> should i contact the maint .. or there is an http place where to ask this?
[08:15] <Keybuk> bugzilla I guess currently
[08:15] <nomed> k
[08:15] <Keybuk> we don't really have "maintainers"
[08:15] <nomed> thanks
[08:15] <Keybuk> or you could just ask on here
[08:15] <Aegir> Quick question, how quickly between when somthing appears on dapper-changes mailing list and when it makes its way to the repository?
[08:15] <Keybuk> Aegir: $TIME
[08:15] <Aegir> Keybuk: Fair enough
[08:15] <Keybuk> Aegir: ie. however long it takes ... usually to build
[08:16] <nomed> wouldn't it be nice to use "-d confdir" to specify even scrpts/dir to include in initramfs?
[08:16] <Aegir> Ahh, no worries. Was just curious. Saw the xorg pop up in my mailbox and quickly rushed to update my sources
[08:16] <nomed> actually i need to copy scripts/* to /etc/mkinitramfs/scripts
[08:17] <nomed> it just reads iniramfs.conf + modules from -d confdir
[08:17] <Keybuk> nomeata: that's probably a bug ... I can't see why it does that
[08:18] <Keybuk> the CONFDIR stuff was just bolted on at the last minute and never tested, I suspect a patch to replace any occurance of /etc/mkinitramfs with ${CONFDIR} would be the right thing
[08:18] <Keybuk> Aegir: I think xorg FTBS ... so it may never show up
[08:19] <Aegir> Righto
[08:20] <Aegir> I think I know what you mean by FTBS, but what specifically does it stand for?
[08:20] <Keybuk> Failed To Build From Source
[08:20] <Aegir> Right, seems logical. Anyways, thanks for the answers, I'll go lurk in the corner again ;)
[08:21] <dholbach> sudo apt-get install bsdgames && wtf ftbfs
[08:21] <zakame> hi all
[08:21] <zakame> haha dholbach 
[08:28] <Mithrandir> pitti: pong
[08:30] <pitti> Hi Mithrandir 
[08:30] <pitti> Mithrandir: ah - do you know a bit about krb4?
[08:30] <pitti> Mithrandir: krb4 is the only source package that keeps libdb4.1 in main
[08:31] <pitti> Mithrandir: 1) we want to eliminate dups, and 2) it breaks some packages I want to update to a newer mysql
[08:31] <pitti> Mithrandir: it would be great to build krb4 against db4.3
[08:31] <pitti> Mithrandir: but these are only compatible as long as no transactions are used
[08:32] <slomo_> elmo: please sync prelink from debian/unstable... ubuntu changes can be dropped
[08:32] <Mithrandir> pitti: what depends on it?  I'd relaly like to just get rid of it.
[08:33] <pitti> Mithrandir: cyrus-sasl2, evolution-data-server, heimdal, sasl2-bin
[08:34] <Mithrandir> problem with migrating it is probably to handle upgrades from the 4.1 stash with all the users etc.
[08:35] <pitti> Mithrandir: the actual data format is the same, just the log format changed
[08:35] <pitti> Mithrandir: does krb4 use transactions?
[08:36] <Mithrandir> pitti: no idea.  Probably not.
[08:36] <pitti> Mithrandir: Friday I tried to build cyrus-sasl2 against the latest mysql, which breaks because of libdb4.1-dev vs. 4.2-dev
[08:36] <pitti> (build-dep conflict)
[08:38] <Mithrandir> does mysql depend on db4.2?
[08:38] <infinity> pitti : BTW, I'm this --><-- close to declaring MySQL 5.0 "not completely teh suck" and dumping 4.1 altogether.
[08:38] <pitti> infinity: I thought about the same
[08:38] <pitti> Mithrandir: indirectly, yes
[08:38] <Mithrandir> infinity: does it blow (up) in interesting ways?
[08:39] <Mithrandir> pitti: crack. :-)
[08:39] <ajmitch> do people still use krb4?
[08:39] <pitti> Mithrandir: hey, mysql needs a real database backend :) 
[08:39] <Mithrandir> pitti: anyway, if the data store is the same, we could just transition it.  Any idea what the popcon stats are for krb4?
[08:39] <pitti> no
[08:39] <Mithrandir> pitti: hahahha, well, I guess libdb is better than myisam..
[08:40] <Mithrandir> ajmitch: I don't know.  People thinking retro is cool, possibly?
[08:40] <infinity> Mithrandir : Not in any ways I've managed to tickle it.  I need to look into Debian #339740, but since the reporter claims that upstream's binaries are okay, I'm confident it's something we can track down.
[08:40] <ajmitch> ah, a thread about dropping krb4 support from heimdal
[08:41] <Mithrandir> pitti: I wonder if we can just nuke it from all of those.. I can't think of any reason to run krb4 five years ago, not to mention today.
[08:59] <pitti> Mithrandir: re nuke> can apps just be recompiled against krb5? (I don't know anything about krb)
[09:04] <Mithrandir> pitti: all of the apps above have krb5 bindings in addition to krb4 ones, so we'd just disable krb4.
[09:04] <pef> hello
[09:04] <Mithrandir> pitti: heimdal might need a little bit of hammering, but not too bad, I think.
[09:28] <pitti> Hey seb128, hi mvo
[09:28] <seb128> hi
[09:31] <\sh> moins pitti seb128 mvo 
[09:31] <Keybuk> seb128: you know that totem/mozilla plugin crash?  I was wondering, could it have something to do with the CPU of the machine in question?
[09:31] <Keybuk> was just reading the bugs, and they're all on a similar class of machine
[09:31] <Keybuk> and similar to mine, and I get the crash every damned time
[09:32] <seb128> Keybuk: yeah, maybe. It doesn't crash for me but it seems to do for a lot of people, it's just crappy :/
[09:33] <pitti> Hi \sh
[09:36] <Keybuk> I have another odd one :)  mplayer consistently doesn't work on my laptop, crashes every time
[09:36] <Keybuk> but exactly the same packages work fine on my desktop
[09:38] <\sh> hmmm...totem is crashing on all laptops i have...but mplayer, xine etc. are running
[09:48] <pitti> infinity: just found another worthwile dup: ucd-snmp
[09:48] <pitti> infinity: I add it to the wiki page
[10:01] <SteveA> mjg59: hello.  i'm getting a really weird problem with my laptop suspending when i do dhclient eth1.  interested in looking into it?
[10:06] <\sh> infinity: can it be, that the buildds are in a bad state somehow? i have problems with some kde stuff (amarok, kdiff3 etc.) which are building in a local pbuilder or chroot bot failing on the buildds because of missing kde build deps
[10:07] <infinity> \sh : I'm out to dinner, can you ping me about it in about 2 or 3 hours?
[10:07] <\sh> infinity: for sure :) 
[10:07] <Mithrandir> Keybuk: hmm, I think I need a bootchart udeb.  Could you make me one or would you prefer a patch?
[10:08] <Keybuk> udeb ?! :)
[10:08] <Keybuk> you want to profile the installer?
[10:08] <Kamion> I wouldn't complain ...
[10:08] <Mithrandir> no, I want to profile the live cd boot.
[10:08] <Mithrandir> we'd get profiling of the installer as well, but that's not what I'm interested in, really.
[10:08] <Keybuk> you'd need two things
[10:09] <Keybuk> 1) a place to hook the start script so that it runs throughout the process (we do this in initramfs for the main system)
[10:09] <Keybuk> 2) somewhere for the monitoring to live (a jail in /dev for the main system)
[10:09] <Keybuk> 3) a place to hook the stop script to shut it down again
[10:09] <Mithrandir> that's three things. :-P
[10:09] <Keybuk> damn, spotted :p
[10:09] <Mithrandir> the 2) will be interesting, since we have a pivot_root in the middle.
[10:09] <Keybuk> indeed
[10:10] <Mithrandir> it should actually be easy enough, just a casper pre script.
[10:10] <Keybuk> we have the same in the real system too, (pivot from initramfs to the root-fs)
[10:10] <Keybuk> but the /dev partition survives that, so we live inside that
[10:11] <Kamion> pivot_root> not once simplified-live-cd is implemented ...
[10:11] <Kamion> but yeah, /dev is a tmpfs in d-i so you can use that
[10:11] <Keybuk> patches welcome anyway, it'd be useful I suspect
[10:12] <Mithrandir> Keybuk: do you have it in bzr/bazaar or should I just pull what's in the archive?
[10:12] <teuf> hi
[10:12] <seb128> hey teuf
[10:12] <seb128> pitti: that's for you I guess :p
[10:12] <Keybuk> Mithrandir: no, just grab the source from people.uc/~scott/packages
[10:12] <pitti> Hi teuf
[10:12] <Kamion> for startup, I'd include a /lib/debian-installer-startup.d/ script and rebuild debian-installer with bootchart-udeb in build/pkg-lists/base
[10:13] <teuf> seb128, of course, nobody would come here for you ;)
[10:13] <Kamion> that way we'd get installer profiling as you say
[10:13] <teuf> hi pitti 
[10:13] <Mithrandir> Kamion: yeah, that was my thought too.
[10:13] <pitti> teuf: somebody already tested the python script, but you are welcome to confirm it :)
[10:13] <teuf> pitti, yeah, I just did
[10:13] <Mithrandir> Kamion: it'd be interesting to profile cdebconf, I don't think anybody has looked at its performance at all?
[10:14] <teuf> pitti, and I'm getting exactly the same results
[10:14] <Kamion> Mithrandir: not a lot
[10:14] <nomed> Kamion, will ubuntu livecd use unionfs?
[10:15] <Mithrandir> nomed: it will be an option.
[10:15] <Mithrandir> at least when doing development
[10:15] <Kamion> Mithrandir: I think the biggest win would come from http://bugs.debian.org/329743
[10:15] <teuf> pitti, maybe a strace from a successful eject call would help ?
[10:15] <Kamion> nomed: https://launchpad.net/distros/ubuntu/+spec/livecd-unionfs
[10:15] <nomed> well i'm using it ... there are some issues with some scripts ..
[10:15] <viviersf> whats the improvement on using unionfs rather than squashfs ?
[10:15] <nomed> for ex adduser ...
[10:16] <Mithrandir> viviersf: those are orthogonal.
[10:16] <Kamion> viviersf: they're complementary, not contradictory. https://launchpad.net/distros/ubuntu/+spec/livecd-squashfs
[10:16] <pitti> teuf: strace does not help us any more
[10:16] <nomed> i filled a bug to unionfs list ...i hope they'll fix this ..
[10:16] <viviersf> kk thx Kamion 
[10:16] <pitti> teuf: we already isolated the problematic ioctl
[10:17] <pitti> teuf: I'll do the rest with BenC when he has some time
[10:17] <Kamion> nomed: what's the adduser issue?
[10:17] <pitti> teuf: maybe we need to add some printk()s to the code and build a debug kernel
[10:17] <Mithrandir> Kamion: evil hack suggestion, but quite cool in that bug, yes.  Could be done fairly easily with accessor functions, and we do have that already, don't we?
[10:17] <teuf> pitti, I mean, eject /dev/sdb2 works properly here, so I was suggesting looking at a strace from that
[10:18] <nomed> Kamion, "Hard link count is wrong for" etc/skel/dotdirs
[10:18] <nomed> it fails when trying to cp /etc/skel/ .... to /home/$USERNAME
[10:18] <nomed> i needed to use useradd -m
[10:19] <nomed> mainly it seems something related to "find"
[10:19] <pitti> teuf: I know, but there the CDROMEJECT ioctl will succeed, and it will fail with EIO on the other device
[10:20] <teuf> pitti, sorry, I don't get what you mean 
[10:20] <nomed> Kamion, http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2005-November/001427.html
[10:21] <pitti> teuf: the problem is that the CDROMEJECT ioctl succeeds sometimes, and sometimes not
[10:21] <pitti> teuf: but we have to debug the actual kernel function for that
[10:21] <pitti> teuf: strace will only display the ioctl, not the code that is executed in the ioctl function
[10:22] <pitti> teuf: all I wanted to know from the python script was that the ioctl is indeed the culprit
[10:22] <pitti> teuf: and not some other commands issued by eject
[10:22] <pitti> Hi carlos!
[10:22] <teuf> pitti, ok
[10:22] <carlos> morning
[10:22] <Kamion> Mithrandir: it wasn't easy enough for me to do in the afternoon I spent looking at it
[10:22] <pitti> teuf: does the device where it fails happen to be USB 2.0?
[10:22] <Kamion> Mithrandir: but not intractable, certainly
[10:23] <teuf> pitti, the device is an ipod, and it's plugged in an usb2 capable port
[10:23] <teuf> I'm not 100% sure the ipod is usb2, but it probably is
[10:23] <seb128> pitti: this eject bug happens with CDs too, no?
[10:24] <pitti> teuf: hmm, that thought was wrong, it works here with an usb2.0 memory stick
[10:24] <pitti> seb128: no idea, does it?
[10:24] <teuf> pitti, the CDROMEJECT ioctl also fails when I call eject, but then there are 3 more successful SG_IO ioctls, dunno if those are used to work around CDROMEJECT not working ?
[10:25] <seb128> pitti: #5049 starts speaking of CDs
[10:25] <pitti> teuf: actually yes
[10:25] <pitti> teuf: the 'invalid argument' is just from the last one (tape?), misleading, but harmless
[10:25] <teuf> ah ok
[10:25] <Mithrandir> Kamion: but that'll only make lowmem installs quicker, not general ones, right?
[10:26] <pitti> teuf: successful? but if they were, the others would not be tried any more
[10:26] <Mithrandir> Kamion: anyway, using the file backend uses less memory, since it loads them on demand.
[10:26] <teuf> the last one is BLKRRPART, google seems to indicate it triggers partition table reloading
[10:27] <pitti> teuf: ah, ok, so that's got nothign to do with ejection
[10:27] <teuf> pitti, the end of strace eject /dev/sdb2 is http://pastebin.com/435400
[10:30] <Kamion> Mithrandir: reducing memory consumption and malloc churn should help everyone out a bit, I'd think
[10:31] <Mithrandir> possibly
[10:31] <nomed> Kamion, where can i follow the livecd development .. i think i can share some experience i have on this field ... mainly possible issues you could find
[10:31] <Mithrandir> nomed: most stuff is discussed in here
[10:32] <nomed> ok thanks
[10:41] <Keybuk> hmm, I should probably "package" bootchart 0.9, fix the update-initramfs bug and then upload it to the real archive
[10:41] <Mithrandir> Keybuk: what update-initramfs bug?
[10:41] <fabbione> shawarma: ping?
[10:42] <Keybuk> Mithrandir: bootchart's postinst calls update-initramfs, which promptly refuses to update the initramfs because the kernel doesn't use update-initramfs to make them :)
[10:42] <Mithrandir> ah, ok.
[10:42] <fabbione> Keybuk: i suggest you talk with BenC or fix kernel-package for that
[10:43] <Keybuk> well, yes, I think that's the actual plan :)
[10:43] <fabbione> i know Ben plan to upload the kernel today
[10:43] <Keybuk> I'm still waiting for BenC to move all the firmware into /lib/firmware too though <g>
[10:43] <fabbione> so perhaps we can get it in one shot
[10:43] <fabbione> i tought they were there already
[10:43] <Keybuk> 15-3 still puts them in /lib/hotplug/firmware
[10:43] <fabbione> apparently no
[10:43] <fabbione> yeah i can see that
[10:45] <fabbione> Keybuk: i think #9394 would be better handled by you
[10:46] <fabbione> since you are working directly on iyt
[10:46] <fabbione> it even
[10:46] <Keybuk> fabbione: ? RESOLVED FIXED
[10:47] <fabbione> Keybuk: hmmm i just noticed the mail from bugzilla..
[10:47] <fabbione> it must be old...
[10:47] <fabbione> sorry
[10:47] <Keybuk> I have #19200 already assigned to me (same thing)
[10:47] <fabbione> roger :)
[10:48] <Keybuk> isn't 9394 well within the WARTY range of bugs? :p
[10:48] <fabbione> possibly
[10:49] <Keybuk> have fun
[10:49] <fabbione> thanks
[10:52] <Keybuk> Kamion: would you have any objection to trying to slowly shove initrd-tools and modutils into universe?
[10:54] <BockBilbo> hello
[10:55] <freeflying> how can download the package from revu  ftp what I've uploaded
[10:56] <BockBilbo> im about to write a wishlist bug in bugzilla but first i wanted to know if you guys think it is worth
[10:56] <Keybuk> freeflying: try #ubuntu-motu
[10:57] <Keybuk> BockBilbo: it may be better off discussing it on the ubuntu-users mailing list first, and then mailing the summary of the discussion to ubuntu-devel if it's broadly favourable
[10:57] <BockBilbo> i see
[10:58] <BockBilbo> it is related to WepLab http://weplab.sourceforge.net/
[10:58] <BockBilbo> a wep key cracking program
[10:58] <Keybuk> that isn't packaged
[10:58] <dholbach> BockBilbo: you may want to add it to http://wiki.ubuntu.com/UniverseCandidates
[10:58] <BockBilbo> i know
[10:59] <BockBilbo> Keybuk, it isnt on the repositories yet, so i was thinking on suggesting it for drapper
[10:59] <BockBilbo> thanks dholbach :)
[10:59] <dholbach> de rien
[10:59] <dholbach> brb
[11:00] <Kamion> Keybuk: not at all; to get initrd-tools into universe, fix initramfs-tools to work on hppa and ia64 to lamont's satisfaction
[11:01] <BockBilbo> *dapper
[11:02] <Keybuk> remind me, if I _remove_ something from a seed, that shows up in anastacia, right?
[11:03] <Kamion> yes
[11:03] <Kamion> provided that you merge it to all the seeds
[11:03] <Kamion> and that nothing depends on the removed thing
[11:04] <Keybuk> yeah
[11:04] <Kamion> (latter for completeness, I know you know this already ...)
[11:06] <BockBilbo> dholbach, but.. i need a deb package build by myself in ubuntu in order to add it to https://wiki.ubuntu.com/UniverseCandidates
[11:06] <BockBilbo> right?
[11:10] <pef> BockBilbo: #ubuntu-motu :)
[11:11] <BockBilbo> ok
[11:11] <BockBilbo> :)
[11:11] <sivang> morning all
[11:37] <nomed> is it possible to use pivot_root within iniramfs?
[12:16] <\sh> elmo / kamion: please sync icewm from unstable, dropping ubuntu changes ok, thx
[12:17] <Kamion> s, / kamion,,
[12:19] <\sh> whoever has time to do it :) no rush
[12:20] <Kamion> it's not about time; only elmo does syncs (nowadays), so please don't ask me
[12:21] <\sh> Kamion: ok :)
[12:23] <infinity> \sh : So, what were you asking me about earlier?
[12:26] <viviersf> Kamion, you know if grub has any issues with phoenix bios's 
[12:26] <viviersf> ?
[12:30] <Kamion> viviersf: no idea, sorry
[12:30] <viviersf> kk
[12:30] <viviersf> BenC, you know by any chance ?
[12:32] <Mithrandir> Kamion: hmm, any thoughts on bumping the size of /dev?  5MB is a bit too tight, since I need libc and stuff in there as well.
[12:33] <Keybuk> does the installer still fix the size of it?
[12:33] <Keybuk> we stopped doing that in the main distro
[12:33] <Treenaks> libc in /dev?
[12:33] <Keybuk> you'll need the bootchart output in there too, which is about 30MB I think
[12:33] <Keybuk> Treenaks: did you not look at the evil things I did to make bootchart work? :p
[12:34] <HiddenWolf> Keybuk, ew
[12:34] <ogra> Keybuk, did infinity notify you about dropping the "sleep 3" from initramfs' nfs script ? 
[12:34] <Treenaks> Keybuk: ...
[12:35] <Mithrandir> Keybuk: ok, I guess I can just remove the fixed sizee.
[12:35] <Keybuk> ogra: not yet, though if it's the sleep I think it is, I'll probably drop that myself when I go through
[12:35] <Mithrandir> Treenaks: it's the New World Order and /dev is the new lib.
[12:35] <Keybuk> /dev is the handiest place to stash things that need to survive a pivot_root
[12:35] <ogra> Keybuk, it was for debuigging a klibc timeout, its useless ... would be nice if you could throw it out ..
[12:36] <Keybuk> oh right, no, wasn't the one I was thinking of then
[12:36] <Kamion> Mithrandir: will go away with new udev + new rootskel
[12:36] <pitti> Mithrandir: wow, only 2 packages left that use readline4 - thanks :)
[12:36] <ogra> Keybuk, line 36 in /usr/share/initramfs-tools/scripts/nfs
[12:37] <Mithrandir> Kamion: ok, goodie.  I'll just work around it for now.
[12:37] <Kamion> Mithrandir: new rootskel uses the init script from udev-udeb, so as long as that doesn't hardcode it ...
[12:37] <Mithrandir> Kamion: \o/ :-)
[12:37] <Mithrandir> pitti: which are left, again?
[12:37] <pitti> Mithrandir: lua50 and quagga
[12:38] <Mithrandir> pitti: ok, I'll see if I can complete those later today. A bit busy with the live cd bootchart stuff now.
[12:38] <pitti> sure, no problem
[12:39] <pitti> Mithrandir: that wasn't meant to hurry you, just a thank you
[12:39] <Mithrandir> pitti: np :-)
[12:40] <infinity> ogra : Keybuk's not actually the initramfs-tools maintainer, he's just pretending to be for a week or two while he works on the udevHardwareActivation stuff. :)
[12:40] <ogra> infinity, oh, youre around ...
[12:40] <infinity> ogra : Lies.
[12:41] <ogra> infinity, i just saw him doing all these uploads :)
[12:41] <Keybuk> of course, by the time I give it back, infinity might not want to be the maintainer anymore
[12:41] <ogra> lol
[12:42] <Mithrandir> bootchart is DoS-ing my qemu
[12:43] <infinity> Keybuk : If you do evil things to jbailey's pretty and readable shell, I'll hit you.
[12:43] <Keybuk> nah, my shell is equally pretty and readable
[12:43] <Keybuk> Mithrandir: did you forget to put nanosleep somewhere?
[12:43] <Mithrandir> Keybuk: no, but qemu's I/O sucks.
[12:43] <Keybuk> . o O { we may want to put that in initramfs-tools, as it's much more useful than the busybox sleep }
[12:44] <Mithrandir> just fix busybox sleep to nanosleep instead.
[12:44] <infinity> Keybuk : There's nothing wrong with busybox, I'm assured it's kloibc that's at fault.
[12:45] <infinity> Oh, wait, maybe I'm confusing two different conversations.
[12:45] <infinity> But making busybox's sleep take float arguments should be trivial.
[12:46] <\sh> infinity: ok...I saw some glitches on the buildd for kde stuff...amarok e.g. or kdiff....
[12:46] <\sh> infinity: http://people.ubuntu.com/~lamont/buildLogs/a/amarok/2:1.3.6-1ubuntu1/amarok_2:1.3.6-1ubuntu1_20051120-1846-i386-failed.gz
[12:47] <infinity> \sh : I'm failing to see how "the archive is broken" is a buildd problem...
[12:49] <zakame> hmmm, let me second \sh on that
[12:49] <\sh> infinity: well...the archive works...because I checked with a complete new pbuilder and removing all packages from the package cache, that's why I thought the buildds are behaving not normal
[12:49] <Keybuk> there shouldn't be any I/O, it's just tmpfs stuff
[12:49] <Keybuk> you may be hitting the busybox fork-bomb, of course
[12:49] <Kamion> \sh: libssl0.9.7 was certainly missing from the archive for a period of time.
[12:49] <zakame> gnubiff ftbfs on all archs, while I can build so on my own chroot: http://people.ubuntu.com/~lamont/buildLogs/g/gnubiff/2.1.7-1ubuntu1/gnubiff_2.1.7-1ubuntu1_20051120-1014-i386-failed.gz
[12:49] <Keybuk> infinity: sleep comes from klibc, so yeah, would be trivial -- nanosleep is exactly what you'd replace the klibc sleep with
[12:50] <Keybuk> (it was written by copying sleep.c and modifying it <g>)
[12:50] <Kamion> \sh: (I know, because I restored it over the weekend)
[12:50] <\sh> infinity: but to be sure, I'd ask you :)
[12:50] <Kamion> zakame: same problem, libssl0.9.7 was missing
[12:50] <Kamion> which rendered python uninstallable, etc.
[12:50] <zakame> Kamion: should I then adjust to libssl0.9.8 ?
[12:51] <zakame> or keep it that way?
[12:51] <Keybuk> busybox is evil, it does "exec /bin/busybox $cmd" for everything that should be a shell built-in
[12:51] <Kamion> zakame: yes, but that's irrelevant!
[12:51] <Keybuk> so you get a fork/exec hit for things like echo, test, etc.
[12:51] <Kamion> zakame: the point is that *python* depended on libssl0.9.7
[12:51] <zakame> Kamion: ah, ok
[12:51] <Kamion> Keybuk: no it doesn't, it execs things that *aren't* shell built-ins
[12:51] <Kamion> (in busybox)
[12:52] <Kamion> it doesn't exec its own builtins, obviously, or half of them wouldn't work
[12:52] <infinity> \sh : At any rate, python's happier now, so all that stuff will get given-back.
[12:52] <Keybuk> Kamion: yes, things that _should_ be
[12:52] <Keybuk> it does exec itself for echo :(
[12:52] <Kamion> Keybuk: things that _may_ be, if you read the standard ;)
[12:52] <Keybuk> I couldn't work out why, if it's the same binary, it doesn't just do it internally
[12:52] <Kamion> Keybuk: there's progress on that upstream for the embedded guys
[12:52] <\sh> infinity: k...thx 
[12:52] <Kamion> but we've had this conversation before ...
[12:53] <Keybuk> not with me?
[12:53] <Kamion> yes, with you
[12:53] <Keybuk> oh, when was that?
[12:53] <Kamion> a month or so ago I think
[12:53] <Keybuk> ah, I have little memory of anything before UBZ :)
[12:54] <\sh> elmo: please sync klibido from unstable, dropping ubuntu changes ok, thx
[12:54] <Kamion> hmm, might have been in /msg though, can't find it in the irclogs
[12:54] <infinity> Anyone with a large set of danglies feel like merging PAM?
[12:54] <Kamion> "personal communication"
[12:54] <Mithrandir> ah, nanosleep 1.0 instead of 0.2 was _a lot_ better.
[12:55] <Kamion> infinity: hah, PAM is on my bug list ...
[12:55] <Kamion> ok, will investigate
[12:55] <Kamion> today is my "hard merges" day
[12:55] <infinity> Kamion : Ahh, lucky you.  It's just on my "last thing keeping db3 in chroots" hitlist.
[12:55] <Keybuk> heh
[12:56] <Keybuk> there aren't any easy ones left, iirc.
[12:56] <Keybuk> where easy ~= no dropped
[12:58] <Mithrandir> hmm, the live cd tells me I have no HD.  Silly thing.
[12:58] <infinity> It wouldn't lie, you must have removed it.
[12:58] <infinity> Of course, kernel 2.6.15 thinks I don't have a CD drive, so I feel your pain.
[12:59] <Mithrandir> well, I'm running it through qemu, so I don't mind.  much.
[12:59] <Mithrandir> I mind more that it sends a SIGKILL to localedef
[01:02] <Keybuk> Kamion: uh, how did bootchart go straight to ACCEPTED ?
[01:03] <zyga> morning
[01:03] <Kamion> Keybuk: bootchart_0.8-3_source.changes
[01:03] <Kamion> NEW to dapper
[01:03] <Kamion> Changes: bootchart (0.8-3) unstable; urgency=low
[01:03] <Kamion> (was synced from unstable earlier)
[01:03] <Keybuk> heh
[01:03] <Keybuk> how much earlier?  it doesn't show up in my packages lists at all
[01:03] <Kamion> 25 Oct
[01:04] <Keybuk> weird, which component?
[01:04] <Keybuk> ah, it's never built
[01:04] <Kamion> universe
[01:05] <Keybuk> rookery scott% madison-lite bootchart
[01:05] <Keybuk>  bootchart |      0.8-3 | dapper/universe | source
[01:05] <Keybuk> it's, of course, entirely possible that might won't build either as it depends on evil java crud, but it might
[01:05] <infinity> i386 / bootchart
[01:05] <infinity>   Version             : 0.9-0ubuntu1
[01:05] <infinity>   Builder             : buildd+terranova
[01:05] <infinity>   State               : Uploaded
[01:05] <Keybuk> sweet
[01:16] <nomed> what can be the reason for which usplash picture disappears after run-init cmd in initramfs?
[01:18] <Kamion> infinity: pam uploaded
[01:18] <infinity> Kamion : Rock.
[01:18] <infinity> nomed : timeout, or vc switch are the only things that will kill it.
[01:19] <infinity> (Well, that and killing it)
[01:19] <jbailey> infinity: Depend on killing it.
[01:19] <jbailey> infinity: On a segfault it simply doesn't go away, =)
[01:20] <infinity> FEATURE.
[01:20] <nomed> i think it was the 128Mb of ram machine
[01:20] <nomed> is it possible?
[01:21] <nomed> ummm ... it seems not
[01:22] <nomed> well thanks ... i'll check what's killing it
[01:30] <\sh> doko: when the new gcc is ready to install...we can start with the renaming of the libs? 
[01:30] <dholbach> \sh: the new compiler hasn't built yet, but we can prepare packages already
[01:30] <\sh> dholbach: well...http://people.ubuntu.com/~lamont/buildLogs/g/gcc-4.0/4.0.2-4ubuntu1/gcc-4.0_4.0.2-4ubuntu1_20051121-0317-amd64-successful.gz
[01:31] <dholbach> \sh: does this include the changes we need?
[01:31] <Kamion> <cjwatson@cairhien ~/src/ubuntu/base-config>$ dscdiff base-config_2.73.dsc base-config_2.73ubuntu2.dsc | wc -c
[01:31] <Kamion> 1865092
[01:31] <Kamion> <cjwatson@cairhien ~/src/ubuntu/base-config>$ dscdiff base-config_2.74.dsc base-config_2.74ubuntu1.dsc | wc -c
[01:31] <Kamion> 161159
[01:31] <Kamion> woo
[01:32] <\sh> dholbach: i could tell you...when my evolution is not fcking around with me
[01:32] <pitti> Kamion: hopefully most of the diffs are translations?
[01:32] <Kamion> pitti: right
[01:34] <doko> \sh: no, it's not ready, FTBFS on ia64 and powerpc
[01:34] <\sh> doko: yes...but if all archs are build...it's the one compiler we are waiting for, right?
[01:37] <doko> yes
[01:38] <Keybuk> \o/ only 2,000 unread bugs now
[01:46] <Kamion> pitti: could you please review MainInclusionReportPcmciautils? I did the packaging so I'm not qualified to review it
[01:47] <pitti> Kamion: in 30 minutes?
[01:49] <Kamion> sure
[01:50] <dholbach> i'm out for food... see you later
[01:54] <Kinnison> walls!
[01:55] <Keybuk> a little more today, I think, nurse
[01:56] <Kinnison> You give me so much at one time.
[01:58] <carstenh> pitti: ping
[02:06] <Nafallo> Mithrandir: it didn't before?
[02:06] <Mithrandir> Nafallo: nah, it dies when init started.
[02:07] <Keybuk> http://www.thegoth.force9.co.uk/malcsimg/tescomum.JPG
[02:07] <Mithrandir> s/dies/died/
[02:07] <Keybuk> *giggle* ... "stoned server"
[02:08] <Keybuk> that program really shows the age of the author
[02:08] <Nafallo> Keybuk: grotesque picture! :-P
[02:08] <Keybuk> "Ping Timeout" would be far more useful
[02:12] <sivang> Kamion, fabbione : do you know if when resinstalling ubuntu, I  shold be able to remount my LVM managed PV/LVs ?
[02:14] <\sh> brb
[02:15] <Kamion> sivang: sure, you just have to go through the LVM configurator in partman once to get it to recognise them
[02:16] <pef> elmo: can you please sync ktorrent from Debian ? thanks !
[02:18] <sivang> Kamion: cool, so it's easy as pie to have them recognized again after wiping current isntallation?
[02:19] <sivang> Kamion: and are we doing that in the Installer, or will it require "manual" intervention after system has been installed?
[02:20] <Robot101> ktorrent kthanks
[02:21] <Mithrandir> Kamion: any idea what kills bootchart approximately when casper runs?  That is, it looks like it's killed during casper's postinst, or something like that.
[02:22] <Kamion> sivang: it's in the installer. please just try it :)
[02:23] <Kamion> Mithrandir: not offhand, unless bootchart is pid 1
[02:23] <sivang> Kamion: Will do, terribly sorry for the noise though. thanks!
[02:23] <Mithrandir> Kamion: it's not.  It's 1998 or thereabouts, iirc
[02:28] <sivang>  n.
[02:28] <sivang>    A sullen protrusion of the lips; a fit of sullenness. "Jack's
[02:28] <sivang>    in the pouts." --J. & H. Smith.
[02:28] <sivang> hrm
[02:28] <sivang> EWCHANNEL
[02:48] <Keybuk> bugs: 33280 total, 0 unread
[02:48] <Keybuk> \o/
[02:48] <pitti> carstenh: pong
[02:57] <marseillai> hi
[02:57] <marseillai> does anyone could tell me if gnome-power-management use "pmi action hibernate" command to hibernate a laptop or something else ?
[03:13] <Simza> Mithrandir : you can scratch my back instead
[03:16] <Diziet> Well, it almost certainly doesn't compile on dapper (haven't tried) and it doesn't install on breezy without removing the locale support package.  But I think I shall upload it anyway.
[03:16] <Diziet> (firefox, finally)
[03:18] <siretart> hey mark!
[03:18] <siretart> Diziet: you mean, first blood on firefox 1.5? ;)
[03:20] <Mithrandir> I have _no idea_ what kills bootchart.  Apparently, lots of stuff is killed when doing pivot_root.
[03:20] <Diziet> siretart: Yes, I have a package which is only about 2500 lines away from Debian's and seems to work at least a little bit.
[03:22] <siretart> Diziet: great! :)
[03:29] <Diziet> Hrm, the debian/rules clean needs a bit of tidying or I'll upload something with lots of junk in the diff.
[03:51] <Diziet> diff of two mozilla trees down from about 1ks to about 5s.
[03:52] <doko> seb128: iz gtk bug
[03:53] <seb128> doko: which one? :)
[03:54] <doko> seb128: gcc-4.0 build failure
[03:54] <doko> :)
[03:54] <seb128> ah :p
[03:54] <seb128> brb
[04:20] <mvo> Kamion: is #19853 a problem in apt-setup ?
[04:32] <\sh> elmo: please sync gabber2 from unstable, dropping ubuntu changes ok
[04:40] <mdz> morning
[04:41] <\sh> good evening mdz :)
[04:43] <mvo> good morning mdz 
[04:44] <seb128> hi mdz
[04:45] <elmo> sh: done
[04:45] <elmo> sh: gnome-theme-extras can't be done, orig.tar.gz mismatch
[04:46] <\sh> elmo: hmmm....same problem as with gajim...
[04:47] <\sh> elmo: lets see what I can do 
[04:49] <elmo> Kamion: little is yellow-lining WRT disk space
[04:50] <elmo> Kamion: still 100G free tho - do you want me to reset the warn/critical paramters to some lower value?
[05:00] <\sh> ok..going home...cu laters
[05:04] <Kamion> mvo: yes, but apt-setup is about to die and be replaced by a rewritten version, so ...
[05:05] <Kamion> I'll take the bug anyway
[05:05] <mvo> Kamion: ok, thanks
[05:10] <Keybuk> hey, that's been my response to bugs for the last few weeks
[05:10] <Keybuk> you can't steal it
[05:12] <Kamion> Keybuk: heh
[05:12] <Kamion> elmo: nah, I'll take the opportunity to free up a bit of space. What's the current yellow-line?
[05:13] <Keybuk> ok, fog at sunset is officially creepy
[05:13] <Keybuk> it's like there's this alien red mist hanging around
[05:14] <Kinnison> Keybuk: it *is* alien red mist
[05:14] <Kinnison> Keybuk: the WoW machines are attacking
[05:15] <Keybuk> I was just thinking "ullah"
[05:21] <Kamion> elmo: it's sort of tempting to come down to the datacentre one day with a few spindles of CD-Rs and take official archival copies of all the old images lying around on little
[05:21] <elmo> Kamion: yello is 20%
[05:22] <Znarl> Kamion : I could help you with that, if you like.
[05:22] <Kamion> thanks. might be worth it some day when we're all bored.
[05:23] <Znarl> Kamion : Play escort that is, not changing CDs for you.
[05:23] <Znarl> ...otherwise Elmo will kick my butt.
[05:24] <Kamion> heh
[05:24] <Kamion> I suspect mdz might kick my butt at spending a day changing CDs before ubuntu-express works, though
[05:26] <Kamion> elmo: I've got it up to 22% used, but, believe it or not, any more is hard without purging old images. Can you reset the yellow line to 10% free?
[05:26] <Kamion> or, actually, make that 15%
[05:26] <elmo> Kamion: sure
[05:26] <Kamion> 5% of little is still lots
[05:27] <elmo> done
[05:33] <seb128> Diziet: did you try to run apps using firefox (epiphany-browser, yelp, galeon, ...) with the 1.5 package?
[05:40] <Diziet> seb128: No.  Are they hideously broken, or just broken ?
[05:40] <seb128> Diziet: I've no idea, I'm just waiting on firefox build to try :)
[05:41] <Diziet> I just upgraded my build system to dapper and am checking to see if the 1.5 package I just uploaded builds on it.
[05:42] <elmo> aspell-ukr (0.51-0-4/0.51-0-4): in main - skipping.
[05:42] <elmo> bonobo-activation (1:2.4.0-4/1:2.4.0-4): in main - skipping.
[05:42] <elmo> db4.1 (4.1.25-19/4.1.25-18ubuntu1): in main - skipping.
[05:42] <elmo> tix8.1 (8.1.4-8/8.1.4-8): in main - skipping.
[05:42] <elmo> anyone want to vouch for the removal of any of those?
[05:43] <doko> elmo: tix8.1 can be removed, but tix has to be promoted to main instead
[05:43] <elmo> doko: can you deal with the seeds then?
[05:43] <seb128> elmo: remove bonobo-activation please
[05:44] <elmo> seb128: done, thanks
[05:44] <doko> elmo: not necessary, it's a dependency of python2.4-tk
[05:44] <seb128> np
[05:45] <elmo> ** evolution-exchange has an unsatisfied build-dependency: libdb4.1-dev
[05:45] <elmo> ** krb4 has an unsatisfied build-dependency: libdb4.1-dev
[05:47] <seb128> elmo: I'll fix the evolution-exchange one
[05:47] <elmo> seb128: cool, thanks
[05:49] <seb128> are the seeds still using baz, or can we get them with bzr?
[05:49] <elmo> you have to use bzr now, AFAIK
[05:51] <ogra> seb128, see the SeedsManagement wikipage, colin has updated the content
[05:52] <seb128> ogra: I've this page open atm, and no, there is no mention of bzr
[05:52] <ogra> at the bottom
[05:52] <seb128> no bzr mention on the page
[05:52] <seb128> according to my browser
[05:52] <seb128> grumpf
[05:52] <seb128> EWIKI
[05:52] <ogra> seb128, see it ? 
[05:53] <seb128> I was using the canonical wiki
[05:53] <ogra> heh
[05:53] <seb128> the page should be removed from here
[05:53] <desrt> elmo; ping
[05:53] <seb128> and point to the other wiki if we switched
[05:53] <ogra> seb128, while youre here ...
[05:53] <ogra> Gnome-CRITICAL **: gnome_program_get_app_id: assertion `program != NULL' failed
[05:53] <elmo> desrt: ?
[05:54] <desrt> elmo; https://launchpad.net/products/launchpad/+bug/3996
[05:54] <Amaranth> ogra: what app, what did you do to get that, etc
[05:54] <ogra> seb128, why do i get this message in a pygtk program... indeed i havent set "program" to anything ...
[05:54] <Amaranth> it doesn't look fatal
[05:54] <elmo> desrt: *shrug* why are you telling me?
[05:54] <ogra> but i havent imported gnome either
[05:54] <Amaranth> ogra: what have you imported?
[05:54] <seb128> ogra: maybe you have imported something which import gnome
[05:54] <desrt> elmo; you replied to my RT request asking me to sign the code of conduct.  i am explaining why i can not.
[05:55] <ogra> gtk and gtk.glade
[05:55] <Amaranth> o_O
[05:55] <ogra> nothing more
[05:55] <ogra> import gtk
[05:55] <ogra> import gtk.glade
[05:55] <ogra> import os
[05:55] <ogra> import sys
[05:55] <ogra> import string
[05:55] <ogra> import socket
[05:55] <ogra> import fcntl
[05:55] <ogra> import struct
[05:55] <seb128> stop flooding
[05:55] <elmo> desrt: that's nice.  but until you do, you don't get an ubuntu.com email.  sucks to be you.
[05:55] <ogra> i dounbt anything imports gnome ...
[05:55] <desrt> quite.
[05:55] <Amaranth> how does that launchpad-integration stuff work, anyway?
[05:56] <\sh> Amaranth: as a hook 
[05:56] <seb128> Amaranth: what do you want to know?
[05:56] <\sh> Amaranth: python example check gajim
[05:56] <Amaranth> you have to add it to the program manually?
[05:57] <seb128> you have 2 functions to call
[05:57] <Amaranth> ok, all i needed to know
[05:57] <Amaranth> i thought it hooked into gtk or something
[05:58] <Keybuk> Kamion: does your powerpc have a /proc/device-tree thingy?
[05:58] <Kamion> Keybuk: yes, all PowerMacs have
[05:59] <Keybuk> Kamion: ok, can you pick something in there and see what /proc/device-tree/.../device_type contains
[05:59] <Keybuk> and more particularly, does $(cat PATH) give something useful
[05:59] <desrt> elmo; thanks for the info.  cheers.
[06:01] <Kamion> $ cat /proc/device-tree/pci\@f0000000/device_type; echo
[06:01] <Kamion> pci
[06:01] <Kamion> Keybuk: ^--
[06:02] <Keybuk> ok, cool
[06:02] <\sh> Amaranth: into a gtk menu it's been hooked 
[06:02] <stub> desrt: Your example doesn't hold anyway. Just because there is a signature that matches a document, it isn't suddenly legally binding or anything. You need to knowingly sign it, and not be under duress.
[06:02] <Kamion> Keybuk: cat PATH> eparse?
[06:02] <desrt> stub; but then you can argue that all signatures are meaningless anyway
[06:02] <desrt> stub; so why even bother?
[06:02] <Keybuk> Kamion: can you do "find /sys -name devspec | xargs grep pci@f0000000" and check something contains that
[06:03] <Kamion> /sys/devices/pci0000:00/0000:00:10.0/devspec:/pci@f0000000/ATY,JasperParent@10
[06:03] <Kamion> /sys/devices/pci0000:00/0000:00:0b.0/devspec:/pci@f0000000/uni-north-agp@b
[06:03] <stub> desrt: They can be argued that way. Lawyers do it all the time. Depends on what other supportive evidence there is.
[06:03] <Keybuk> ok, grab http://people.ubuntu.com/~scott/vio_type ... and check that "vio_type /devices/pci0000:00/0000:00:10.0/devspec:/pci@f0000000/ATY,JasperParent@10" returns something like VIO_TYPE=...
[06:04] <desrt> i didn't expect an argument in the form of "but pgp signatures can be meaningless anyway...." :)
[06:04] <Keybuk> . o O { must buy myself a cheap mac for xmas }
[06:04] <desrt> i expected one of the form of "your attack is impossible"
[06:05] <\sh> Keybuk: cheap mac?
[06:05] <Keybuk> \sh: figure something off ebay for testing shit on
[06:05] <Diziet> desrt: Generate a key which exists only for your Ubuntu stuff.
[06:05] <desrt> Diziet; i'm considering that... but it seems underhanded
[06:05] <Diziet> Why ?  It just seems sensible to me.
[06:05] <desrt> Diziet; i also have a key that i plan to revoke soon... considering using that one
[06:05] <Diziet> Don't do that, that's just silly.
[06:06] <stub> desrt: Digital signatures suffer exactly the same draw backs as real signatures but on a lesser scale (ie. it is easier to forge a pen-and-paper signature than a digital one). 
[06:07] <Diziet> Anyway, birthday attacks are not a real possibility with SHA-1, unless you think Ubuntu can carry out an 80-bit search.
[06:07] <\sh> Keybuk: I thought about buying a pegasos 
[06:07] <Diziet> The real cryptographic problem is that SHA-1 is broken and you're acting as a signing oracle, which nowadays you ought not to do.
[06:08] <desrt> sha-1 isn't substantially broken
[06:08] <Keybuk> Kamion: any luck?
[06:08] <desrt> but that's a good enough point
[06:08] <Diziet> Collisions have been found.  That's broken.
[06:08] <Diziet> But the only risk is that Ubuntu can force you to sign some other file.  This will have no deleterious effect other than on Ubuntu if you use a key you make specifically for Ubuntu.
[06:08] <desrt> they have full-algorithm sha1 collisions?!
[06:08] <desrt> crikey!
[06:09] <Diziet> http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
[06:09] <Diziet> (top hit for google sha1 broken)
[06:09] <desrt> man
[06:09] <desrt> is nothing sacred?
[06:09] <Diziet> But it's only collisions, not second-preimage, so in practice you're still OK if you don't have a blessing oracle.
[06:10] <desrt> uhm.
[06:10] <desrt> ok.  so refuse to act as an oracle still
[06:10] <desrt> but i don't see two files that i can download and hash
[06:11] <Diziet> FWIW I wouldn't sign the code-of-conduct exactly as provided with a non-Ubuntu-specific key.
[06:11] <desrt> i just see a reduction of complexity from theoretical birthday attack on sha1 to "still harder to attack than md5 via birthday attack"
[06:11] <Diziet> So you have a point.  But just generate a different key already :-).
[06:12] <desrt> well
[06:12] <desrt> by the same token i'm just as happy to wait
[06:12] <Diziet> The collision-finding complexity is down to 2^69 which is within reach.
[06:12] <desrt> it's not like i have a critical need for my ubuntu.com email address to work
[06:12] <Diziet> To wait for what ?
[06:12] <desrt> for them to fix launchpad
[06:13] <Diziet> They're not going to fix it.  Just get a grip and generate a different key.
[06:13] <desrt> you might be wrong and i have nothing to lose by waiting :)
[06:13] <Diziet> Sure. 
[06:14] <desrt> oh.  you're ian
[06:14] <desrt> hi :)
[06:14] <Diziet> Hello :-).
[06:14] <desrt> (we talked at ubz about crypto stuff too)
[06:15] <desrt> specifically, key revocation policy
[06:18] <Diziet> Lame, isn't it ?
[06:19] <Diziet> I could have cut-and-pasted the README.Ubuntu but that's even crapper.  I really wanted to get a package out there to give people something to work with.
[06:19] <mdz> are there reasons other than the freetype breakage why it won't build on dapper?
[06:19] <Diziet> Not AFAIAA but I hadn't tried it.  I haven't fixed the freetype breakage because I didn't want to interrupt merging by updating my build system to dapper and blowing away my ccache.
[06:20] <Diziet> It's still building here.
[06:28] <Kamion> Keybuk: sure those arguments are right?
[06:29] <Kamion> ah, you cut-and-pasted dodgily :)
[06:29] <Kamion> $ DEVPATH=/devices/pci0000:00/0000:00:10.0 ./vio_type
[06:29] <Kamion> VIO_TYPE=ATY,DDParent
[06:29] <Kamion> $ DEVPATH=/devices/pci0000:00/0000:00:0b.0 ./vio_type
[06:29] <Kamion> VIO_TYPE=uni-north-agp
[06:30] <marseillai> does anyone could tell me if gnome-power-management use "pmi action hibernate" command to hibernate a laptop or something else ?
[06:30] <Keybuk> ok, that looks good
[06:30] <marseillai> i ask this because it seems that on my laptop hibernation works with ubuntu but not kubuntu!
[06:30] <mjg59> marseillai: Yes, it uses pmi
[06:30] <ogra> marseillai, in breezy it does
[06:31] <marseillai> ogra: do you know what is used in horay ?
[06:31] <marseillai> because with gnome in hoary it works
[06:31] <marseillai> but kde and breezy it doesn't
[06:31] <marseillai> kde and dapper nor
[06:32] <ogra> mjg59, i'm not sure how we want to go on with this ... seems we'll need to keep the PowerManager backend daemon and patch g-p-m to talk to it
[06:32] <Diziet> Woah, it built!
[06:32] <Keybuk> uhhhh, Diziet, what the hell have you broken?
[06:32] <mjg59> ogra: Either that, or we add a suid helper for hal
[06:32] <ogra> marseillai, there is no gnome-power-manager in hoary
[06:32] <Keybuk> I've somehow got a system with a conffile owned by two packages at the same time
[06:32] <Keybuk> with different md5sums!
[06:32] <ogra> mjg59, with the likely chance that pitti kills us both ? 
[06:33] <mjg59> ogra: For which? I've discussed this with pitti
[06:33] <ogra> oh, ok
[06:33] <ogra> didnt know that
[06:33] <Keybuk> can anyone else on dapper do this for me:  grep "/etc/modprobe.d/isapnp" /var/lib/dpkg/status
[06:33] <ogra> but the current package i have here is completely useless...
[06:33] <ogra> (i have 0.3.0 locally)
[06:34] <thierry> seb128 : look at malone bug 3951 , you said it had specs problem with the .desktop file... should I open a new bug to fix that?
[06:34] <mvo> Keybuk: I have two entries as well
[06:34] <mjg59> ogra: Because our hal doesn't do anything useful?
[06:34] <Riddell> marseillai: does it work in ubuntu breezy gnome?
[06:34] <\sh> Keybuk: 
[06:34] <\sh> shermann@r200-shermann:~$ grep "/etc/modprobe.d/isapnp" /var/lib/dpkg/status
[06:34] <\sh>  /etc/modprobe.d/isapnp 33fc47be83e43dd0450748b3e4700332
[06:34] <\sh>  /etc/modprobe.d/isapnp 33fc47be83e43dd0450748b3e4700332
[06:34] <ogra> mjg59, even with --retain-privileges
[06:34] <mjg59> ogra: Oh? Why?
[06:34] <marseillai> Riddell: it seems yes but it's not me who test but someone with the same laptop!
[06:34] <Keybuk> mvo: do yours have the same, or different md5sums?
[06:35] <ogra> mjg59, havent debugged yet ... but i think hal must be taught to talk to pmi ...
[06:35] <mvo> Keybuk: different ones
[06:35] <mvo> interessting!
[06:35] <ogra> Keybuk, gra@honk:~/Desktop/willowgui $ grep "/etc/modprobe.d/isapnp" /var/lib/dpkg/status
[06:35] <ogra>  /etc/modprobe.d/isapnp 5be3edbb3cd6290636ac3e6d653e5076
[06:35] <ogra>  /etc/modprobe.d/isapnp 33fc47be83e43dd0450748b3e4700332
[06:36] <mvo> /etc/modprobe.d/isapnp 5be3edbb3cd6290636ac3e6d653e5076
[06:36] <mvo>  /etc/modprobe.d/isapnp 33fc47be83e43dd0450748b3e4700332
[06:36] <marseillai> Riddell: i've thought it was a problem with the swap partition but i've try with resume=swap: /dev/hda5 kernel parameter and it doesn't work anymore
[06:36] <seb128> thierry: what issue. Don't bother for the "value of key "Categories" is a list of strings and must end with a semicolon" ones
[06:37] <thierry> seb128 : yeah but there's no encoding and stuff like that...
[06:37] <Diziet> keybuk: This is probably my fault, indeed.
[06:37] <seb128> thierry: what file?
[06:38] <thierry> /usr/share/applications/gksu.desktop
[06:38] <Keybuk> dholbach: that post probably shouldn't go to devel-announce, but to ordinary announce ... devel-announce is supposed to be "upcoming changes", rather than general announcements.  do you want to resend it?
[06:38] <thierry> seb128 : my patch was fixing that by the way... maybe I could take a part of it and send it in a new bug?
[06:39] <dholbach> Keybuk: hrm... none of my mails went through to ubuntu-announce@
[06:39] <dholbach> Keybuk: they were silently rejected :)
[06:39] <seb128> thierry: #3951 is about gnome-system-tools, not gksu and is really broken, you dropped the translations
[06:39] <Keybuk> dholbach: that is to say that it should _also_ go to
[06:40] <Keybuk> ie. don't "expect" anyone else but the core team to be subscribed
[06:40] <dholbach> is ok
[06:40] <Keybuk> rejected?  or jdub just hasn't woken up yet?
[06:40] <dholbach> no, i didnt send it there this time :)
[06:41] <thierry> seb128 : sorry about that
[06:41] <seb128> thierry: np
[06:42] <mdz> dholbach: ubuntu-announce is moderated
[06:42] <dholbach> mdz: yeah, i know... i experienced it :)
[06:42] <mdz> dholbach: that is different from being silently rejected
[06:42] <plutonium> Hello marseillai 
[06:43] <plutonium> I'm gonna translate in marseillais langage for certain people in this chan
[06:45] <plutonium> vazy carlos sort une blague
[06:45] <plutonium> chuck_, OUAWW !! Chuck Norris is present on this chan !!
[06:46] <zul> ummm..ok
[06:51] <pitti> Hi
[06:51] <pitti> My main network has been down for some hours (and is still) - anything urgent for me?
[06:52] <Keybuk> Diziet: I think you can be let off the hook, it doesn't look as though it was broken with your recent conffile changes
[06:52] <Keybuk> it looks like it's been ALWAYS broken
[06:52] <Diziet> Really ?  How exciting.
[06:52] <ajmitch> Diziet: interesting firefox changelog entry
[06:52] <Diziet> Do explain, if you feel like it ...
[06:52] <Mithrandir> Keybuk: did marga look at it?
[06:52] <Diziet> ajmitch: Quite so.
[06:52] <Diziet> It turns out that it _does_ build.
[06:52] <ajmitch> that's good
[06:52] <Diziet> Tomorrow I will upload an rc3-based one with a sensible changelog.
[06:53] <seb128> bzr: ERROR: unknown command 'push'
[06:53] <seb128> hum
[06:53] <Mithrandir> seb128: install bzrtools?
[06:53] <seb128> Mithrandir: thanks
[06:54] <seb128> bzr: ERROR: Rsync could not use the specified location.
[06:54] <seb128> grumpf
[06:54] <pitti> seb128: hmm, recent versions of bzr have push
[06:54] <\sh> elmo: please sync krusader from unstable, dropping ubuntu changes ok
[06:54] <Mithrandir> we've switched to bzr for the seeds now?
[06:54] <pitti> seb128: use jbailey's latest crack
[06:55] <elmo> Mithrandir: yes
[06:55] <\sh> elmo: and I don't know if you missed another sync request of "grip" (also from unstable, dropping ubuntu patches ok)
[06:55] <seb128> pitti: works better, thanks
[06:57] <seb128> elmo: you can remove smeg it's replaced by alacarte
[06:57] <pitti> Hi elmo
[06:57] <elmo> sh: no, I synced grip already
[06:57] <elmo> sh: krusader done
[06:57] <pitti> elmo: what is required to get current dapper's pmount into breezy-backports/
[06:57] <pitti> ?
[06:58] <pitti> elmo: many folks are crying for it, since it fixes floppy mounting
[06:58] <elmo> seb128: does alcarte provide smeg?
[06:58] <Keybuk> Diziet: I don't have an explanation, just bafflement that it can go on-noticed for so long
[06:58] <\sh> elmo: sorry then I missed it in my inbox...see it now...thx :)
[06:58] <elmo> pitti: it's already in breezy-backports, it's waiting on buildd enablement
[06:58] <Keybuk> basically package A provides conffile, package B doesn't ... then B gets upgraded, (partially) replaces A, and also provides that conffile
[06:58] <seb128> elmo: it does
[06:58] <Keybuk> now the conffile is owned by both A and B, rather than just B
[06:58] <seb128> elmo: why?
[06:58] <elmo> sh: also can you please fix quintuple agent?  it's build-depends line is broken, []  isn't valid
[06:58] <pitti> elmo: oh, great
[06:59] <elmo> seb128: the removal program was complaining that a bunch of stuff still depended on smeg
[06:59] <elmo> seb128: done
[06:59] <seb128> elmo: that should be the -desktop packages only and I've just updated the seed
[06:59] <seb128> thanks
[06:59] <Riddell> dholbach: thanks for sending that to ubuntu-devel-announce, I'd never have seen it otherwise
[06:59] <\sh> elmo: sure
[07:00] <ajmitch> elmo: is my gpg key still somewhere in your queue?
[07:00] <elmo> ajmitch: for ubuntu?  yes
[07:00] <elmo> ajmitch: I did debian last night
[07:00] <ajmitch> ok, thanks
[07:01] <\sh> elmo: u mean this one: libcap-dev [@linux-gnu@]  ?
[07:01] <elmo> \sh: yes, it ends up as "[] " in the .dsc and Sources.gz
[07:02] <seb128> type-handling is great :p
[07:02] <\sh> elmo: yeah...debian/rules tries to do a s/@linux-gnu@/`type-handling any linux-gnu`/
[07:02] <Keybuk> Diziet: ok, no, it's even stranger than that
[07:02] <Keybuk> you did partially break it
[07:03] <Keybuk> which is why it's never been spotted before
[07:03] <Keybuk> with unpatched dpkg, the conffile appears twice in status, but only once in *.list
[07:03] <Keybuk> with patched dpkg, the conffile both appears twice in status and twice in *.list
[07:09] <Keybuk> actually, no, that's wrong too
[07:09] <Keybuk> with patched dpkg, it appears in the wrong list
[07:09] <\sh> seb128: well...seeing the output now, it gives me all archs for linux-gnu anyways...so actually it's useless
[07:10] <seb128> we don't use it for main
[07:10] <\sh> seb128: I removed the control.in joke now ,)
[07:10] <\sh> strange that it worked in pbuilder...
[07:11] <\sh> seb128: while u are here :) can u have a look on this http://people.ubuntu.com/~lamont/buildLogs/g/grip/3.3.1-4/grip_3.3.1-4_20051119-1529-i386-failed.gz ... and tell me what's wrong with it..and if it's actually fixed :) thx :)
[07:12] <dholbach> Riddell: maybe you can then start gathering kde people, who want to help out :)
[07:12] <Keybuk> hmm, they both did things in the same order
[07:12] <Keybuk> Diziet: yup, you broke conffile replaces
[07:12] <Riddell> dholbach: I'll give it a shot
[07:12] <dholbach> :)
[07:13] <seb128> \sh: no idea of what's wrong
[07:13] <\sh> gnomevfs stuff should work, or?
[07:14] <seb128> maybe a Depends broken on the way
[07:14] <seb128> just use a pbuilder and try to install it
[07:14] <\sh> seb128: i'll do it just now...because it compiled here already...I wouldn't sync a package without testing
[07:15] <\sh> even armagetron i tested the debian package..and it build and worked ...
[07:16] <seb128> that's not an issue with the package
[07:16] <seb128> that's an uninstability somewhere
[07:16] <seb128> may be a soname change of whatever lib
[07:18] <\sh> seb128: i'll check
[07:19] <\sh> bah...I'm now in this "typing with a uk keyboard", that I can't use a german keyboard anymore 
[07:21] <\sh> mvo: have fun :)
[07:25] <pitti> Kamion: here?
[07:26] <\sh> well....
[07:26] <\sh> it's dapper not breezy *grmpf*
[07:27] <\sh> dilinger: fix it :)
[07:27] <Nafallo> dieman: http://revu.tauware.de/~sistpoty/MoM/ :-)
[07:27] <Nafallo> baah
[07:27] <Nafallo> s:dieman:dilinger:
[07:28] <dilinger> \sh: will do
[07:30] <Keybuk> Nafallo: ... you know if you want any "useful" output from mom, you can ask for it, right? :p
[07:32] <Nafallo> Keybuk: I will always bug you when I need something from her indeed :-).
[07:32] <Keybuk> you don't have to grep the log files, if you want I can add code to do things when universe merges are made
[07:33] <Keybuk> ie. poke things with a stick so you can update lists, etc.
[07:33] <Nafallo> oh, you probably want to talk to sistpoty. I'm just using the system :-).
[07:34] <Nafallo> yay! firefox built finally :-)
[07:36] <slomo_> lamont-away, infinity: please remove passepartout and pinball from dep-wait... should be fine now
[07:38] <pitti> Mithrandir: do you think you can handle #19890?
[07:38] <Mithrandir> pitti: what was the argument against getting rid of krb4?
[07:39] <pitti> Mithrandir: none actually
[07:39] <Keybuk> removing-duplication-in-main?
[07:39] <pitti> Mithrandir: but removing the package would mean that krb4 needs a fix anyway
[07:39] <mdz> Kamion: are the daily CD builds intentionally disabled?
[07:39] <pitti> Keybuk: yep
[07:40] <pitti> Mithrandir: I'm not sure whether elmo meant 'remove from archive' or 'remove from main'
[07:40] <pitti> Mithrandir: I can rebuild it against db4.3 myself of course, but I don't have any krb fu
[07:40] <Mithrandir> pitti: I have no krb4-fu, I just know some krb5 stuff
[07:41] <pitti> Mithrandir: ah, ok. Nevermind then
[07:41] <\sh> seb128: hmmm...grip is just building fine
[07:41] <Mithrandir> pitti: but sure, I can recompile it and upload if you don't want to.  No sane way to really test it though.
[07:41] <seb128> cool, just need a retry so
[07:41] <\sh> infinity: ping
[07:41] <Mithrandir> pitti: and as I said earlier, krb4 is dead.
[07:41] <pitti> Mithrandir: ok, then we can operate on a similar basis :)
[07:41] <pitti> Mithrandir: then nobody will notice it anyway
[07:41] <pitti> :)
[07:42] <Mithrandir> pitti: heh. :-)
[07:43] <Keybuk> oh, wow, dpkg corner case
[07:43] <Keybuk> A depends FOO, B replaces/conficts FOO
[07:43] <pitti> elmo: speaking about libdb removal, when gnome1 is demoted to universe, there are only about 3 packages left which use libdb3
[07:43] <pitti> elmo: (in main)
[07:43] <Mithrandir> Keybuk: doesn't dpkg consist of corner cases?
[07:43] <Mithrandir> Kamion: what's the eta on initramfs stuff in d-i?
[07:44] <\sh> seb128: a give back or just a rebuild?
[07:44] <Keybuk> (where A and B are two versions of the same package)
[07:45] <seb128> \sh: buildd kick
[07:45] <\sh> seb128: ok...
[07:45] <Keybuk> the only way I can describe the result of that is "a sulk"
[07:46] <\sh> infinity: please kick grip, amarok, kdiff3 again and please have a look on armagetron, it should build, but it's somehow strange that it's in dep-wait...(shouldn't be)..if you are ok with it, please kick it as well :) thx :)
[07:48] <elmo> pitti: add it/that info the wiki page?
[07:49] <pitti> elmo: yes (it should already be there in some way, but I check again)
[07:52] <mdz> neuralis: community-server-hardware-testing needs to be kept absolutely simple; it shouldn't block on having any kind of automated test suite, or a database for recording the results.  What I had in mind was a wiki-based record based on a human-driven test plan, much as we are building for desktop testing
[07:55] <neuralis> mdz: this is news to me. it was decided, at the bof, to try and do community testing as similarly as possible to certification.
[07:55] <mdz> neuralis: community testing has different goals and a different timeline
[07:56] <neuralis> mdz: are you worried about the test suite and catalog being available on time, or do you think a wiki-based record is a good long-term solution?
[07:56] <mdz> neuralis: there are presently no developer resources allocated for creating such a test suite or catalog
[07:57] <mdz> neuralis: and it is often a mistake to engineer for a long-term solution without real-world experience about how the application will be used,which is why we prototype with general-purpose tools like the wiki, to learn what our needs are
[07:57] <neuralis> mdz: how so? the test suite is assigned to BenC, and it's a high-priority spec; as the specs state, i'll develop the catalog.
[07:58] <mdz> neuralis: it was not intended in the first place (when BenC was assigned) that this spec involve writing a database application, or any software at all for that matter
[07:59] <neuralis> mdz: i understand what you're saying, but it's radically different than what was discussed at the bof, as far as i can tell.
[07:59] <mdz> we've learned through past experience that we need to set concrete, simple, achievable initial goals for projects like this, and not to overengineer from the start
[07:59] <pitti> doko: ping
[07:59] <mdz> neuralis: yes, that's the problem which I raised during the review process.  The intent of the spec was to create a community testing program for servers, but it was sidetracked to discuss certification instead
[08:00] <mdz> neuralis: and now you seem to be considering community testing as an offshoot of certification
[08:00] <BenC> mdz: will it involve a new wiki, or is there some way to apply this to the current wiki without a lot of pollution to the namespace?
[08:00] <mdz> BenC: see LaptopTesting for an example
[08:01] <neuralis> mdz: right, but then most of the bof was pretty misguided.
[08:01] <BenC> it's been a couple of weeks, and the bofs started running together in my brain, so maybe I'm just not thinking right :)
[08:02] <neuralis> BenC: because it wasn't -- we mentioned it in three sentences at the end, saying "once we have this test suite developed, we'll just have people run it and post their results unofficially to a central location"
[08:02] <mdz> right, but that's precisely the reverse of what I had intended
[08:03] <mdz> BenC: the original summary for server testing said that we should "encourage and coordinate" testing, meaning within the community
[08:03] <mdz> BenC: rather than carrying out testing ourselves, which is certification
[08:03] <neuralis> mdz: i'm not at all opposed to bringing this in sync with your intentions, please don't misunderstand me, i'm simply trying to figure out where things got off track.
[08:03] <Keybuk> mdz: do you know off the top of your head whether apt passes "--auto-deconfigure"/"-B" to dpkg?
[08:04] <mdz> Keybuk: I don't think so
[08:04] <neuralis> mdz: the bof discussed writing a test suite, which i've reduced to a rather uncomplicated process in the rewritten spec: essentially, writing a tiny ui.
[08:04] <BenC> we have an Ubuntu Server Team? :)
[08:04] <Keybuk> I wonder how the hell this upgrade worked in Debian ...
[08:05] <Keybuk> udev 060 depends on hotplug, but udev 075 needs to replace/conflict it
[08:05] <neuralis> mdz: if you don't want to allocate developer resources for that, i'm happy to write a text-only front-end to the chosen tools myself, as long as you want to take care of adding the appropriate "test suite" boot option to the CD, and land me in a shell.
[08:05] <Keybuk> and dpkg won't do that
[08:05] <BenC> oh, I'm not even part of that spec
[08:05] <mdz> BenC: yes, we do
[08:06] <neuralis> mdz: i'll also be writing the catalog myself, so i'm not sure i understand your concerns.
[08:06] <mdz> neuralis: the tool described in that spec is for burn-in, which may be somewhat interesting for certification purposes, but isn't relevant to the process of determining whether the hardware is properly supported (which is what the intent was)
[08:06] <pitti> elmo: can you please sync libgda2?
[08:07] <mdz> neuralis: if that's something you would like to develop, I have no concerns about it.  however, that won't fulfill the need that I originally laid out for Dapper
[08:07] <BenC> mdz: can I get one of the Sun Ultra 15k's that is shown for the logo on the Ubuntu Server Team page? :)
[08:08] <BenC> I don't mind sharing it, just need to reinforce my floor joists to support it
[08:08] <mdz> Keybuk: that doesn't sound like a problem; hotplug can be removed before the upgrade
[08:09] <elmo> what would be the right package to file a bug about the 'lock screen' menu entry?
[08:09] <elmo> pitti: done
[08:09] <ogra> elmo, eek
[08:09] <neuralis> mdz: i understand. let's deal with this in chunks. are you satisfied with the certification spec? 
[08:09] <ogra> elmo, dapper or breezy ? 
[08:09] <elmo> ogra: breezy
[08:09] <Keybuk> mdz: would it be though?
[08:09] <mdz> neuralis: don't misunderstand; I won't argue with your desire to implement whatever you like, but we need to be clear on what the original need was for Ubuntu as a project, and how it differs from that
[08:09] <elmo> but I can't imagine this bug has been fixed in dapper yet
[08:09] <ogra> elmo, breezy xscreensaver
[08:10] <neuralis> mdz: no worries, i see where you're coming from, i'm just trying to get it across that this people at the bof seemingly had little understanding of your intentions.
[08:10] <elmo> ogra: uh, really?
[08:10] <neuralis> s/this/the/
[08:10] <ogra> elmo, it wont, we'll switch to gnome-screensaver (except its a bug in a hack indeed)
[08:10] <elmo> ogra: it's specifically about the 'lock menu' bit in the gnome menu bar tho
[08:10] <ogra> elmo, oh, thats rather gnom epanel i guess seb128 ?
[08:11] <Keybuk> mdz: I guess if apt does premature removal of conflict+provide that's ok ... wasn't sure whether it did or didn't
[08:11] <mdz> neuralis: yes, unfortunately I am limited to being in one place at a given time, and was not able to attend the sessions
[08:11] <mdz> neuralis: and other folks had different agendas
[08:11] <neuralis> mdz: i'm happy to revise the community-testing spec to include a stage1 setup where we simply do a wiki-based record like we do now for LaptopTesting, and then use a centralized catalog as a later stage2. would that be closer to what you're after?
[08:12] <mdz> neuralis: what I'm after is a formal process which allows the community to provide us with standardized feedback about whether Ubuntu works on their server systems
[08:12] <doko> pitti: pong
[08:12] <neuralis> mdz: incidentally, the laptop testing folks got excited about the server testing spec, and are asking me already about using the catalog for laptops as well *instead* of the wiki-based record which they find messy.
[08:12] <pitti> doko: it looks as if we could sync db4.3, I checked changelogs and diffs
[08:13] <pitti> doko: however, I'm on modem ATM and can't do a test build
[08:13] <dholbach> elmo: gnome-session, afaik
[08:13] <mdz> neuralis: of course they are; the long-term plan has always been to store this information in a database.  It just happens that the design of said database is a lot more complicated than it seems at first, and would have been quite difficult to get right without having actually done any testing yet
[08:13] <pitti> doko: does anything get into your mind that is still Ubuntu-specific and must not be overwritten?
[08:14] <mdz> neuralis: which is why we didn't do it that way
[08:14] <Kamion> mdz: whoops. deliberately disabled for flight 1, but not deliberately left that way. fixed now.
[08:14] <neuralis> mdz: okay, i'd be happy to outline such a formal process, but with a wiki-based backend, as a stage1 and a primary dapper goal, with anything else being "if we get around to it". would that suit?
[08:14] <Kamion> Mithrandir: no ETA unless (a) there's a concrete need for it (b) Debian switch by default
[08:14] <ogra> Kamion, can you enable edubuntu builds as well ? 
[08:15] <Kamion> ogra: I already have, but they failed due to a bug which bit Kubuntu as well and was fixed just before Flight 1; the next build should work
[08:15] <mdz> neuralis: sure, but it needs to be specific in terms of defining the test plan for evaluating hardware support (which is the key element).  the certification spec, by contrast, glosses over that part of the process
[08:16] <ogra> Kamion, thanks ... what do i need to do additionally to have a liveCD build ? 
[08:17] <mdz> neuralis: the issue which spawned this project was that Ubuntu was unusable on some popular server platforms because of basic issues like support for their RAID controllers, NICs, etc.
[08:17] <doko> pitti: I'm looking ...
[08:17] <neuralis> mdz: it glosses over it because the bof glossed over it. what did you have in mind? would a simple checklist, such as that for LaptopTesting suffice, or were you after more complicated solutions?
[08:17] <mdz> neuralis: something along the lines of LaptopTesting and FormalTestPlans is what I had in mind
[08:18] <Kamion> ogra: make sure your live seed and edubuntu-live metapackage work, then talk to lamont/infinity about getting live filesystems built
[08:18] <Kamion> ogra: after that it's relatively straightforward for me to enable
[08:18] <mdz> neuralis: given a written test plan, we can refine it throughout the testing process, and perhaps later encapsulate some of it in a UI
[08:18] <Kamion> mdz: FYI I'm adding pcmciautils to the minimal seed
[08:18] <Kamion> we're going to need it for 2.6.15
[08:18] <mdz> Kamion: right, thanks
[08:18] <ogra> Kamion, whats needed to make the -live package work ? its the same as ubuntu-live currently with s/ubuntu-live/edubuntu-live/
[08:19] <mdz> Kamion: can we drop pcmcia-cs as well?
[08:19] <Kamion> not yet - it still provides /etc/pcmcia/config.opts
[08:19] <Kamion> I'm talking to folks in Debian about how to best move that to a common package
[08:19] <doko> pitti: no, looks fine
[08:19] <mdz> ogra: in this context, "works" ~= "can be used to successfully create a livefs"
[08:19] <Kamion> we can get by for the meantime with pcmcia-cs and pcmciautils coexisting (which they do), but yes pcmcia-cs should go away eventually
[08:19] <pitti> doko: ok, thanks for checking
[08:20] <ogra> mdz, heh, yes, i got that, but assuming the ubuntu-live package work, my package should work as well in this context ... 
[08:20] <ogra> s/work/works
[08:20] <neuralis> mdz: i'm happy to develop such an outline and have you look at it again, but i fear it'll be very minimalistic.
[08:21] <mdz> ogra: if it's identical, yes, it should
[08:21] <Kamion> ogra: that should be fine for now; my comment was general. however please upload edubuntu-meta to account for your seed change, since edubuntu-live currently depends on ubuntu-live
[08:21] <ogra> yup
[08:21] <ogra> i was waiting unitil the flight 1 dust settled :)
[08:22] <mdz> neuralis: if your interest is in certification testing, then you are of course free to focus your efforts on that, and leave the community testing side of things to someone else
[08:22] <neuralis> mdz: that's not what i'm saying -- we can ask a user if they get video, if their drives are detected properly, and if they can use the network. what else can be easily verified by a community server user?
[08:22] <mdz> neuralis: I see them as mostly orthogonal
[08:23] <\sh> elmo: please sync kiosktool from unstable overriding ubuntu changes ok
[08:23] <neuralis> mdz: laptop testing, by contrast (and by virtue of having a full desktop system), has all sorts of bells and whistles we can have people test and put in a checklist. not so for servers.
[08:24] <mdz> neuralis: there is no limit to how it could be extended (testing functionality of popular server applications, etc.), but as an initial target, our goal is to enable them to answer "does it work?" at a meaningful level of detail
[08:25] <mdz> neuralis: because currently we don't even have that, and that would be a huge improvement
[08:25] <elmo> \sh: done, and thanks for fixing quintuple-agent
[08:25] <zyga> hi
[08:25] <mdz> neuralis: having the infrastructure in place to enable coordinated community participation is 90% of the problem
[08:25] <zyga> I need to get all .debs from main in breezy
[08:25] <zyga> what is the easiest way to do that?
[08:26] <zyga> !
[08:26] <zyga> the cd :>
[08:26] <mdz> neuralis: once that's in place, we can parallelize the rest of the effort throughout the community
[08:26] <zyga> sorry no issue
[08:26] <neuralis> mdz: right. i'm pointing out that a meaningful level of detail for servers, and from a hardware point of view, is rather small, but i'd still be happy to put it together and have you comment on it specifically.
[08:26] <\sh> elmo: thx...and fixing the package was my duty, when I read the changelog  :)
[08:26] <neuralis> mdz: well, i aimed for the catalog to become exactly that infrastructure.
[08:26] <mdz> neuralis: it will certainly be smaller than the equivalent test plan for a desktop
[08:26] <mdz> neuralis: I don't think it will be a strict subset, though
[08:26] <mdz> neuralis: for example, a server test plan would include things like serial console installation
[08:28] <mdz> neuralis: for systems with hot-swap capability, that would be included as well
[08:29] <crimsun> elmo: please sync mpd from Sid
[08:29] <crimsun> elmo: (ok to override Ubuntu changes)
[08:29] <neuralis> mdz: right. my point was that, outside of drives/nic/video (and subcategories, such as hot-swap), there isn't too much to ask about.
[08:30] <mdz> neuralis: apart from the things which are important for servers, there isn't much to talk about.  fortunately, that'll incorporate the things we're interested in :-)
[08:31] <neuralis> mdz: let's figure out how to proceed. i will revise community-testing and write up a simple process like that in LaptopTesting, which you can then comment on specifically before approving the spec. i'll leave the catalog in as a stage2. alternatively, if there's someone else you'd prefer to take over, i have no problem giving up the spec. 
[08:32] <mdz> neuralis: sounds fine.  do you feel that you have a clearer idea of what I meant?
[08:32] <Nafallo> seb128: ping :-)
[08:33] <seb128> Nafallo: pong
[08:33] <elmo> crimsun: done
[08:33] <crimsun> elmo: thanks!
[08:33] <neuralis> mdz: yes. as long as you're okay with another iteration or two of review, it should be fine.
[08:34] <mdz> BenC: are you clear as well on the scope of community server testing?
[08:34] <Nafallo> seb128: http://paste.ubuntulinux.nl/4838 I'll get this when I send mail. seems to stop the mails from getting moved from outbox to sent. anything you recognise from somewhere or know what could cause it?
[08:34] <elmo> ajmitch: done now, sorry for the delay
[08:35] <seb128> Nafallo: the sent you have selected from the account properties is a correct one?
[08:35] <ajmitch> elmo: thanks for that :)
[08:35] <Nafallo> seb128: yes
[08:35] <seb128> Nafallo: I think we had some bug about guys setting a folder and removing it
[08:35] <seb128> so I don't know
[08:35] <seb128> feel free to open a bug with a backtrace, describe what kind of account do you use and what folder you picked for sent mails
[08:36] <neuralis> mdz: community-testing aside, do you have any thoughts on the certification spec?
[08:36] <crimsun> seb128: thanks for the libxklavier fix :)
[08:36] <Nafallo> oki, I will if I don't narrow it down :-)
[08:36] <mdz> neuralis: it's in my queue
[08:36] <seb128> crimsun: np. Does it work for you?
[08:36] <Nafallo> started doing this after changing ssl-cert.
[08:36] <mdz> I haven't read the latest draft ye
[08:36] <mdz> t
[08:36] <crimsun> seb128: yes
[08:36] <seb128> crimsun: cool :)
[08:37] <neuralis> mdz: ah, no problem, i figured you read them together. i'll revise community-testing in the next few days and ping you again with it.
[08:39] <elmo> HATEFUL BUGZILLA
[08:39] <elmo> seb128: dude, did you see my annoying user question? (namely: I want to report a bug about the 'lock screen' entry, what should I report it against?)
[08:40] <\sh> xscreensaver? gnome-screensaver?
[08:40] <ogra> \sh, gnome-session :)
[08:40] <elmo> I've had like 4 different answers now
[08:40] <elmo> 'xscreensaver, gnome-panel, gnome-screensaver, gnome-session, gnome-menus' :-P
[08:40] <seb128> elmo: the menu item is gnome-panel code
[08:41] <elmo> seb128: thanks
[08:41] <seb128> np
[08:41] <vuntz> what's the bug?
[08:41] <seb128> and vuntz is upstream for this code :)
[08:41] <seb128> hey vuntz :p
[08:41] <seb128> be back in a few min
[08:41] <elmo> vuntz: when you click 'lock screen' and your xscreensaver has died, it just does nothing
[08:41] <elmo> ogra: good guess
[08:41] <vuntz> ah
[08:41] <ogra> :)
[08:41] <elmo> but this just bit sabdfl, so I get to be bug proxy boy
[08:42] <vuntz> I think we already have this upstream
[08:43] <vuntz> http://bugzilla.gnome.org/show_bug.cgi?id=130605
[08:44] <elmo> hum, ok - is it worth reporting in our bugzilla and linking to that, or not?
[08:44] <ogra> elmo, i think there already is one ... but filed against xscreensaver ...
[08:45] <Nafallo> seb128: thanx :-). we changed from mail.domain to ogre.domain and didn't specify the sent folder again (thought that didn't depended on what server we used). all this on imap.
[08:45] <Nafallo> seb128: I just selected the same folder again and it works :-P.
[08:45] <pitti> elmo: can you please install the following packages into concordia's dapper dchroot: libtool libncurses5-dev libreadline5-dev gcj gobjc cdbs quilt
[08:46] <ogra> vuntz, wouldnt it solve itself if gnome-screensaver/xscreensaver registered the daemon with respawn in gnome-session ?
[08:46] <pitti> elmo: (gdb build deps minus type-handling)
[08:46] <jbailey> gdb depends on type-handling now?  Scary.
[08:46] <vuntz> ogra: well, this would solve the problem if the screensaver dies
[08:47] <\sh> elmo: please sync ktrack and kxdocker from unstable, overriding ubuntu changes ok, thx
[08:47] <vuntz> ogra: but not if the user disabled the screensaver in xscreensaver properties
[08:47] <ogra> vuntz, thats enough i guess ...
[08:47] <ogra> hmm
[08:47] <vuntz> well, for you maybe :-)
[08:47] <vuntz> not for me, though
[08:47] <elmo> pitti: RTed?
[08:47] <vuntz> this is what the upstream bug is about :-)
[08:47] <pitti> elmo: oh, not yet, but I can do that
[08:47] <ogra> vuntz, yes, but the patch is odd...
[08:48] <elmo> pitti: please do - installing now
[08:48] <pitti> elmo: mail sent, thanks!
[08:48] <vuntz> ogra: well, it reports an error if the screensaver is not running
[08:49] <vuntz> :-)
[08:49] <ogra> vuntz, it should start it instead ... or the icon should be hidden if i disable the screensaver
[08:49] <ogra> adding popup clutter isnt the solution ;)
[08:50] <seb128> Nafallo: so you did use a folder not available :)
[08:51] <jbailey> elmo: Should chroot requests generally go to RT now?
[08:51] <elmo> jbailey: they should always be in RT, I'm happy to be pestered simultaneously on IRC tho
[08:51] <Nafallo> seb128: seems like it. must have defaulted to Sent instead of my properly configured Skickat ;-).
[08:51] <vuntz> ogra: that's why the patch is "needs-work" :-)
[08:51] <vuntz> and not accepted
[08:51] <ogra> yup
[08:52] <seb128> Nafallo: you have edited an account, not created a new one, right?
[08:52] <jbailey> elmo: 'kay.  When we pester you on IRC, should we give you the ticket number at the same time?
[08:52] <seb128> Nafallo: but right, it should not crash when it's not set correctly ... either said so or default to Sent
[08:52] <elmo> jbailey: nah, no need, as long as it's in RT, I'll clean it up later.  the RT thing is mostly about logging
[08:53] <jbailey> elmo: Otherwise known as "please install devscripts in dapper-i386 on concordia", ticket 894 =)
[08:53] <jbailey> elmo: 'kay,. cool.
[08:53] <Nafallo> seb128: yes, changed smtp- and imapserver (only address, it's the same server :-P).
[08:53] <ogra> vuntz, another option would be to strike out the icon with a red X if the screensaver isnt running and make it non sensitive ...
[08:54] <vuntz> ogra: I'm not sure about the red X, but insenstive makes sense
[08:54] <ogra> together with the respawning that should work fine
[08:54] <vuntz> ogra: iirc, that's what markmc suggests in the bug
[08:54] <Nafallo> so it should still use the values I've entered for the rest of everything :-)
[08:54] <seb128> Nafallo: I'm not convinced about that, it should rather say you change other stuff and ask if you want to update this one
[08:54] <seb128> Nafallo: you may want to keep using your previous Sent folder
[08:55] <seb128> user choice should not be changed without asking
[08:55] <vuntz> ogra: ideally, I should be able to lock the screen without having screensaver running in the background, though
[08:55] <ogra> vuntz, not really, he fights for the popup solution
[08:55] <vuntz> ogra: eg, if I usually don't want to have the screensaver, but suddenly I want to lock my screen
[08:56] <elmo> jbailey: done
[08:56] <ogra> hmm, but isnt gnome-screensaver intended to be shipped in gnome anyway ? why duplicate functionality ? 
[08:56] <dredg> the best kind of joy is when you have a policy for locking screens, and the user picks a screensaver that manipulates an image of what's on their screen
[08:56] <Nafallo> seb128: yea, now it changed an option that I didn't change in an existing account and didn't tell me about it. what it should have done is not change ANYTHING I didn't change :-).
[08:57] <vuntz> ogra: gnome-screensaver might help, indeed :-)
[08:57] <Nafallo> seb128: shouldn't even have asked me. that's an extra question that I already configured :-).
[08:58] <seb128> yeah
[08:59] <Nafallo> anyway, thanx for letting me and my girlfriend stop bashing our heads against the wall and me from sending debian 3 identical bugs again ;-)
[09:00] <BenC> mdz: community-server-testing: yes, I'm clear on it now, thanks
[09:05] <neuralis> BenC: i'll write up checking nic detection, drive detection, hot-swap, serial console. what else that comes to mind, hardware-wise?
[09:06] <BenC> neuralis: storage systems (for installing utils that may be needed)
[09:06] <\sh> grmpf
[09:07] <\sh> because of the different cxx transition in debian we will get a lot of unmet deps 
[09:07] <mdz> neuralis,BenC: note that fabbione has made some efforts through server-candy to collect information about the tools for storage management etc.
[09:07] <BenC> mdz: excellent
[09:07] <mdz> neuralis,BenC: so I suggest checking with him and figuring out what we can package, and work with mdy to open a dialog with the vendor in cases where we can't ship it
[09:08] <BenC> also need something about memory layouts, and cpu systems (numa, etc.)
[09:08] <seb128> Nafallo: do you use dapper?
[09:09] <BenC> right now my base server kernel is a generic, need to find out if that's good enough, or do we need seperate numa/bigsmp/whatever kernels
[09:10] <\sh> elmo: thx
[09:10] <Nafallo> seb128: yepp, and my girlfriend 5.10 :-).
[09:10] <seb128> Nafallo: you have this crash with dapper?
[09:10] <seb128> grumpf
[09:10] <seb128> it does:
[09:10] <neuralis> mdz: great, i'll talk to fabio about it.
[09:10] <seb128> " IMAP command failed: [TRYCREATE]  Must create mailbox before append
[09:10] <seb128> Appending to local `Sent' folder instead."
[09:10] <seb128> here
[09:10] <seb128> and doesn't crash
[09:11] <Nafallo> hm
[09:13] <Nafallo> odd
[09:20] <seb128> Nafallo: http://bugzilla.gnome.org/show_bug.cgi?id=315987
[09:27] <\sh> yahoo...
[09:27] <\sh> Setting up debtags (1.5.2) ...
[09:27] <\sh> /var/lib/dpkg/info/debtags.postinst: line 22: 17024 Segmentation fault      debtags update
[09:27] <\sh> dpkg: error processing debtags (--configure):
[09:27] <\sh>  subprocess post-installation script returned error exit status 139
[09:28] <enrico> \sh: cool! :(
[09:28] <enrico> \sh: mind keeping me in the loop for what happened?
[09:30] <\sh> hmmm..debtags update is segfaulting
[09:30] <enrico> \sh: sure.  any gdb trace?
[09:30] <enrico> (we can move to /msg if you want)
[09:31] <\sh> enrico: aehmm....not right now...
[09:31] <enrico> ok.  Keep me posted if you don't mind: enrico@debian.org
[09:31] <\sh> enrico: I just made a dist-upgrade...the last autosync is a bit  faulty...
[09:32] <\sh> enrico: lets see what gdb is saying
[09:32] <\sh> enrico: for sure...I'll mail u
[09:35] <\sh> enrico: http://paste.ubuntuusers.de/571
[09:36] <enrico> \sh: looks nasty.  Repeatable?
[09:37] <\sh> enrico: yepp
[09:37] <enrico> and that is debtags update ???
[09:37] <\sh> jepp
[09:37] <\sh> enrico: and it's much more nasty because postinst is calling debtags update as last command :)
[09:37] <enrico> too weird.  Maybe we should move to #ekhis (always on freenode)
[09:38] <enrico> \sh: could you please /join #ekhis?
[09:38] <\sh> but it can also be, that the new libstdc++ is somehow causing it?
[09:38] <\sh> doko: ping
[09:39] <enrico> \sh: all is possible: that segfault seems to have happened in code that is only called during make check :)
[09:39] <enrico> (see the tut::test_object part)
[09:39] <dholbach> have a nice evening... i'm off
[09:39] <ajmitch> bye dholbach 
[09:40] <\sh> cu daniel
[09:40] <dholbach> bye \sh, ajmitch 
[09:44] <zyga> can anyone suggest a easy-to-use big-mmapped hash-table library?
[09:44] <zyga> (apart from gettext)
[09:45] <neuralis> zyga: google makes a couple of different hashtable implementations available for c++, if that helps.
[09:49] <zyga> neuralis: for big on-disk data?
[09:52] <neuralis> zyga: yes, look at the sparse hash map.
[09:52] <zyga> got it
[09:52] <zyga> neet
[10:02] <jcole> i want to change one simple parameter in a kernel .config asnd recompile... can i just "apt-src build linux-source-2.6.12" with a parameter to a config file??
[10:02] <jcole> oops, my bad, devel only...
[10:07] <lamont> gdb needs type-handling hate applied to it...
[10:07] <pitti> lamont: too late, I was faster
[10:07] <lamont> kewl
[10:07] <\sh> hey lamont :)
[10:07] <lamont> \sh: yo
[10:08] <\sh> elmo: please sync kq from debian unstable, dropping ubuntu changes ok
[10:08] <\sh> don't update debtags today :) apt needs mvo libstdc++ love...I don't touch apt ,)
[10:11] <elmo> \sh: done
[10:12] <\sh> elmo: thx
[10:46] <jbailey> elmo: Can you pls. install less nito dapper-i386 on concordia (rt896)
[10:51] <OgMaciel> smurf: hi... are you busy?
[10:57] <elmo> jbailey: done
[10:57] <jbailey> elmo: Thanks
[10:57] <jbailey> !
[11:00] <OgMaciel> Seveas: sup?
[11:01] <Seveas> OgMaciel, hi
[11:01] <OgMaciel> Seveas: how is everything?
[11:02] <Seveas> busy as usual :)
[11:02] <OgMaciel> hehe
[11:02] <OgMaciel> I bet
[11:02] <OgMaciel> am connected from Brazil
[11:02] <lucas> is there a way to get the current name of the development branch of ubuntu ?
[11:02] <OgMaciel> hope the internet will hold for tomorrow] s meeting
[11:02] <lucas> (same for the "stable" branch)
[11:02] <lucas> (I mean: in a script)
[11:03] <OgMaciel> Seveas: I think Rosetta is going nuts... my karma keeps going down no matter what I do
[11:04] <mdke> OgMaciel, you must be doing bad things
[11:04] <OgMaciel> mdke: such as?
[11:04] <mdke> OgMaciel, thinking bad thoughts?
[11:04] <OgMaciel> mdke: been approving translations and such
[11:04] <OgMaciel> mdke: hehehe
[11:04] <mdke> OgMaciel, you can ask in #launchpad, not here though
[11:04] <Pygi> #join #launchpad
[11:05] <OgMaciel> mdke: cool... but I didn't really ask anything
[11:05] <OgMaciel> it was just a comment
[11:05] <OgMaciel> bt thanx
[11:05] <OgMaciel> but
[11:05] <mdke> OgMaciel, ok, i'll rephrase, you can chat about rosetta in #launchpad
[11:05] <OgMaciel> mdke: understood
[11:07] <pitti> elmo: please sync db4.3
[11:16] <elmo> pitti: done
[11:16] <pitti> danke
[11:34] <slomo> infinity, lamont: please remove passepartout and pinball from depwait... should be fine now everywhere
[11:34] <sistpoty> hi slomo
[11:35] <slomo> hi sistpoty :)
[11:38] <sistpoty> elmo: thx for adding me to the keyring :)
[11:52] <sistpoty> lamont, infinity: is nvtv p-a-s? if so could you please clear it (newest version does have Architecture: i386 amd64)?