[12:14] <Keybuk> I knew there was something I was supposed to do today
[12:15] <LarstiQ> replace shutdown by upstart?
[12:15] <Keybuk> right
[12:23] <Keybuk> jdong|coreduo: you'll need a libc update
[12:23] <Keybuk> it only builds on edgy
[12:23] <jdong|coreduo> aww :(
[12:23] <jdong|coreduo> Keybuk: you're ruining all my fun :)
[12:24] <jdong|coreduo> excuse my complete lack of knowledge about upstart, but will all existing sysv init scripts need to be rewritten?
[12:25] <Burgwork> jdong, no
[12:25] <Burgwork> jdong, before you ask any further questions, I suggest you read Keybuk's rather extensive blog post
[12:25] <Burgwork> this weeks UWN covers it
[12:26] <Keybuk> "need", no
[12:28] <jdong|coreduo> would upstart result in any kind of bootup/shutdown speed improvement?
[12:40] <Keybuk> jdong|coreduo: eventually, yes
[12:40] <Keybuk> though that isn't its goal
[12:40] <jdong|coreduo> k, gotcha
[12:41] <Burgwork> Keybuk, would it be fair to say that the archiecture makes such improvements easier to implement?
[12:42] <Keybuk> Burgwork: yes
[12:43] <ogra> Keybuk, i have a weird problem with my ltsp here ... apparently the NIC always starts in half duplex mode ... do you know how evil it would be to run  mii-tool -F 100base-Tx-FD in my initscript of the client ? would NICs that dont have 100base-Tx-FD support break on that or just gracefully fall back to something sane
[12:43] <Burgwork> right. I am going to writing something about upstart as part of the Knot2 release thingy
[12:44] <ogra> i.e. how forcefully is the force switch ? :)
[12:45] <Keybuk> ogra: they'd break
[12:45] <ogra> gah
[12:45] <Keybuk> in particular, you'd break any NIC plugged into a hub
[12:45] <ogra> right
[12:45] <ogra> oh
[12:45] <Keybuk> as you'd force it into 100base-Tx-FD overriding whatever it had auto-sensed
[12:45] <ogra> RIGHT
[12:45] <Keybuk> (hubs are almost never FD :p)
[12:45] <ogra> i'm plugged into a hub
[12:45] <ogra> <- heavy headdesking
[12:45] <Keybuk> are you sure that it really should be at FD ?
[12:46] <Keybuk> if you're plugged into a hub, it would not surprise me that HD is the best you can get
[12:46] <Keybuk> if you set it to FD, do you get lots of errors?
[12:47] <ogra> well, if i force it to FD i can import my 10Gig of music from the usb disk on the thin client to rhythmbox and my session doesnt die ...
[12:47] <ogra> in HD that doesnt work
[12:48] <Keybuk> why doesn't it work?
[12:48] <ogra> the network gets saturated and the ssh session dies (locks up)
[12:49] <Keybuk> hmm
[12:49] <ogra> usually after 10-20 mins
[12:50] <ogra> i switched to FD more than 1h ago and the music still plays fine ... desktop is responsive etc
[12:50] <Keybuk> what's the error count in ifconfig?
[12:50] <ogra> RX: 1597
[12:50] <ogra> the rest 0
[12:51] <ogra> hmm
[12:51] <ogra> rising
[12:51] <ogra> 1601 now
[12:52] <Keybuk> then something isn't doing FD properly ;)
[12:52] <Keybuk> errors should always be 0 on a wired interface
[12:52] <mjr> well, close to it anyway
[12:56] <ogra> right
[01:07] <ogra> yay, finally ... 6M to go on i386 ....
[01:26] <zul> hey ogra
[01:27] <ogra> hey zul
[01:28] <profoX`> hey guys -- i wanted to apologise for not coming to the TB meeting yesterday -- i made a point on the agenda, but it slipped my mind (just wanted to say that)
[02:08] <Kr4t05> Hey, guys.
[02:08] <Burgwork> hey k4
[02:08] <Kr4t05> I have a question about Edgy+1. Are there any plans to merge InitNG into Ubuntu?
[02:08] <Kr4t05> Or, is that in line for Edgy?
[02:08] <tseng> no.
[02:08] <Burgwork> no
[02:08] <Kr4t05> Mkay.
[02:09] <Kr4t05> Just thought I would ask. :)
[02:09] <Burgwork> Kr4t05, got a link for you, just a sec
[02:09] <Kr4t05> Allright.
[02:09] <Burgwork> Kr4t05, http://www.netsplit.com/blog/work/canonical/upstart.html
[02:09] <Burgwork> read that
[02:09] <Burgwork> it was answer all your initng questions
[02:11] <Kr4t05> Ah, even from the intro, it sounds awesome. :)
[02:15] <Kr4t05> Ok, thanks. :)
[02:15] <Kr4t05> So, is this upstart going to be seen any time soon?
[02:15] <Kr4t05> Oh, oops.
[02:16] <Kr4t05> Oh, neat. :)
[02:16] <Kr4t05> Thanks.
[02:16] <Burgwork> when you are done reading, then ask questions
[02:16] <Burgwork> or not
[02:16] <HrdwrBoB> I think he's done :)
[02:16] <Burgwork> which is good
[02:17] <sladen> ogra: forcing full duplex assumes that the other end is directly connected to a wire-speed non-blocking device;  a modern switch or direct PC<->PC connection
[02:18] <Burgwork> think I should add the upstart link to the topic?
[02:23] <sladen> Burgwork: as long as if that is done, the answer isn't RTFM
[02:24] <Burgwork> yep
[02:26] <Burgwork> sladen, have you installed the LAMP option?
[02:26] <Burgwork> https://launchpad.net/products/ubuntu-website/+bug/58161
[02:26] <Ubugtu> Malone bug 58161 in ubuntu-website "http://www.ubuntu.com/server incorrectly only mentions PHP for LAMP" [Untriaged,Unconfirmed]
[02:27] <infinity> Burgwork: The bug is invalid.  We don't install mod_python or mod_perl, only mod_php, so the website is correct.
[02:27] <Burgwork> infinity, that is what I thought
[02:27] <infinity> And, 3rd party definitions don't much matter in this case. :)
[02:28] <Burgwork> yep. Rejected with extreme prejudice
[02:28] <infinity> LAMP used to stand for Linux/Apache/MySQL/PHP originally.  Now it may be Linux, Apache and Many Possible database and scripting options.
[02:28] <infinity> But that's not what we install. :)
[02:29] <sladen> Burgwork: I haven't installed the LAMP option.  Haven't got a clue how to---it never seemed to actually get mentioned.  I presume it's a meta-package
[02:29] <infinity> sladen: It's (currently) a book option on the server CD.  Will be a task in edgy.
[02:29] <infinity> s/book/boot/
[02:30] <lifeless> infinity: I thought LAMP meant perl ;)
[02:30] <HrdwrBoB> lifeless: it used to
[02:31] <HrdwrBoB> many years ago
[02:31] <infinity> lifeless: I'd be cool with that, mod_perl is great to use.  But it's not what the average user who'd pick a "LAMP install" blindly is likely looking for either. :)
[02:33] <infinity> Anyhow, wikipedia claims the term was coined in a c't article in 1998, and that article claims it was PHP, so I win. :P
[02:33] <Burgwork> infinity, and wikipedia also claims elephant numbers are increasing...
[02:34] <infinity> Clearly visible by visiting a goth club.
[02:34] <Burgwork> or any fast food joint
[02:36] <sladen> it was probably mSQL instead of MySQL aswell...
[02:36] <infinity> sladen: Not according to the article in question, anyway.
[02:36] <JanC> trappist: seems like I missed your last message on bug 58002 before posting my comments; my second one might be a more general solution provided it causes no other problems...?
[02:36] <Ubugtu> Malone bug 58002 in vim "vim should populate skel/.viminfo so ownership is not affected by initial sudo" [Wishlist,Confirmed]  http://launchpad.net/bugs/58002
[02:39] <sladen> JanC: simple question.  what command would you run to edit /etc/apt/sources.list ?
[02:40] <JanC> 'sudo -e /etc/apt/sources.list' ?
[02:41] <Burgwork> why do we even ship vim and emacs?
[02:41] <Burgwork> aside from the screaming if we didn't?
[02:41] <HrdwrBoB> because people use them all the time?
[02:42] <HrdwrBoB> emacs you could potentially lose
[02:42] <HrdwrBoB> since it's massive
[02:42] <Burgwork> "people" use irc all the time and we dropped that
[02:42] <sladen> JanC: okay, most people (including me) would do  sudo emacs ...  and we have to cope with that (even if  export EDITOR=... and sudo -e  would be better)
[02:42] <JanC> vim is massive too  ;)
[02:42] <HrdwrBoB> and people who use it are all insane
[02:42] <Burgwork> in fact, I would say that more people used xchat than vim or emacs
[02:43] <Burgwork> infinity, what is your gut feeling? should I suggest we not ship them?
[02:43] <HrdwrBoB> I know less than a handful of people who use emacs
[02:43] <sladen> Burgwork: vim: so that people can edit files.  Emacs is not installed by default, but it is a programmers editor and normally the first thing I install
[02:43] <JanC> sladen: but my second message was about the 'always_set_home' flag in sudoers
[02:43] <HrdwrBoB> I know MANY people that use vim
[02:43] <HrdwrBoB> people that use emacs are *ALL* "hardcore"
[02:43] <Burgwork> sladen, umm, nano?
[02:43] <HrdwrBoB> not all people that use vim are
[02:43] <Burgwork> vim is awful to use
[02:44] <Burgwork> if you *just* need to edit a text file to get up and running again, you can use nano
[02:44] <infinity> Burgwork: We'r enot going to stop shipping some vi variant in -minimal.
[02:44] <sladen> Burgwork: Ubuntu is "awful" to use if you've used DOS all your life.  People are comfortable using what they are familiar with...
[02:44] <infinity> Burgwork: It belongs there.
[02:44] <Burgwork> ok
[02:44] <Burgwork> then at least lets ship the smallest bloody vim we can
[02:44] <infinity> We've talked about vim-tiny, but it's still undecided.
[02:44] <infinity> I'd be happy with nvi, personally, but whatever.
[02:45] <HrdwrBoB> yeah
[02:45] <HrdwrBoB> tbh as long as it came with 'viu'
[02:45] <JanC> I use 'nano' to add universe so I can install 'joe'  :)
[02:45] <HrdwrBoB> 'vi'
[02:45] <HrdwrBoB> most people wouldn't care that vim had to be installed
[02:45] <sladen> Burgwork: that's a proposal/spec worth making.  If I'm not getting my 'emacs' by default I want to ensure that the 'vi' nutters are penalised aswell
[02:45] <Burgwork> aside from infinity's "it belongs there" arguement. Why do we need it? I am not trolling. I am asking a serious question from a non0technical users standpoint
[02:45] <HrdwrBoB> 'vim' not 'vi'
[02:45] <HrdwrBoB> vi is a core unix util which has a reasonable expectation of being their
[02:46] <HrdwrBoB> vim is not
[02:46] <sladen> HrdwrBoB: this is a valid point, can you write a spec?
[02:46] <Burgwork> are things going to break if it is not included? it is easily apt-getable?
[02:46] <Burgwork> I can see if somebody writes vim/vi into a script and thus it would silently fail, but I just don't see someone doing that
[02:47] <lifeless> they'd use ed to do that
[02:47] <infinity> Burgwork: Nothing breaks, except the brains of thousand of old UNIX hacks.  A small vi is not a size hit, and people who don't know what vi is will never rnu it, so there's no harm in having it there to satisfy old farts like me.
[02:47] <HrdwrBoB> sladen: I can do that, can you point me in the right direction
[02:48] <Burgwork> infinity, ok. Installed size is 1.5mb
[02:49] <infinity> Burgwork: For vim?  Bigger than that, you're missing vim-runtime and other scariness.
[02:49] <Burgwork> yes, I just saw vim-common at 21mb
[02:49] <sladen> HrdwrBoB: https://features.launchpad.net/distros/ubuntu/+addspec is a good place, it'll guide you through the specificaiton registration and give you the templated wiki page to fill in
[02:49] <Burgwork> at 21mb, that is insane
[02:49] <HrdwrBoB> sladen: cheers
[02:49] <sladen> that is BIGGER.  THAN.  EMACS
[02:50] <Burgwork> HrdwrBoB, point me at the spec wiki page and I will add some commentary
[02:50] <Burgwork> anyway, got to go home
[02:50] <infinity> Burgwork: vim-tiny is small, though, and nvi is even smaller.
[02:51] <HrdwrBoB> infinity: what does vim-tiny offer someone that they wouldn't install vim anyway
[02:51] <bddebian> Howdy folks
[02:51] <infinity> HrdwrBoB: A useable 'vi'?
[02:51] <tseng> HrdwrBoB: it offers vi in significantly less space?
[02:51] <HrdwrBoB> tseng: um
[02:52] <HrdwrBoB> what I mean is if you install vim-tiny instead of nvi
[02:52] <HrdwrBoB> would people actually care
[02:52] <tseng> that isnt what you said
[02:52] <HrdwrBoB> or are all 'vim people' going to isntall vim anyway
[02:52] <tseng> I am
[02:52] <HrdwrBoB> in which case, vim-tiny is not useful
[02:52] <tseng> but if i have no vi at all, I will be pissed
[02:52] <infinity> HrdwrBoB: vim-tiny sucks a bit less than nvi.  Fewer irritating misfeatures (like resetting the editor mode when you hit the beginning of a line) and such.
[02:52] <tseng> this applies to 1000s of people
[02:53] <HrdwrBoB> absolutely
[02:53] <HrdwrBoB> which is why you would have nvi
[02:53] <HrdwrBoB> you can't not have vi
[02:53] <bddebian> nano-tiny!! :-)
[02:55] <crimsun> Keybuk: ping
[02:55] <sladen> dpkg -L vim vim-common vim-runtime | xargs -I'{}' find '{}' -type f -maxdepth 0 | xargs du -sch   23MB ...
[02:55] <JanC> bddebian: you mean we have to replace nano with nano-tiny to save some 100 KiB of disk space ?   ;-)
[02:56] <infinity> sladen: Yes, this isn't news.
[02:57] <jdong> are dependency waits automatic or require intervention?
[02:57] <infinity> jdong: automatic
[02:57] <jdong> i.e. amarok backport needs libtunepimp3 backport
[02:57] <jdong> will amarok try again once libtunepimp3 is ready?
[02:57] <infinity> jdong: Assuming the build-deps are correctly versioned.
[02:57] <sladen> infinity: yeah, I doubled-checked it as I couldn't believe  ^Installed-Size:
[02:58] <infinity> jdong: Yeah, looks like it did it right.  Should work fine.
[02:58] <jdong> k, cool
[02:59] <infinity> jdong: I'll push all the libtunepimp stuff through dapper's NEW queue once powerpc has caught up.
[02:59] <bddebian> JanC: Yep ;-P
[02:59] <jdong> cool, thanks for everything, infinity :)
[03:00] <bddebian> Or you could alway just remove emacs from the archive and save even more space
[03:00] <HrdwrBoB> hahaha
[03:00] <Lathiat> haha
[03:00] <jdong> bddebian: lol, you duck quite a bit :)
[03:00] <sladen> bddebian: we don't installed emacs by default "because it's too big"
[03:00] <JanC> bddebian: we could remove all editors except 'ed'  ;-)
[03:00] <bddebian> I know, I was being sarcastic sorry :-)
[03:00] <jdong> world bandwidth conservation day... :)
[03:01] <infinity> JanC: Why use ed, when you can just use dd?
[03:01] <bddebian> JanC: I like it :-)
[03:01] <infinity> JanC: Seek for characters in a reference file and construct the target.
[03:01] <infinity> JanC: Alternately, there's always shipping tiny magnets and magnifying glasses alongside the shipit CDs.
[03:01] <infinity> And perhaps a screwdriver.
[03:02] <JanC> hm, at least that magnifying glass & screwdriver sound useful  :-)
[03:06] <Keybuk> crimsun: 'sup?
[03:06] <crimsun> Keybuk: hi, do you mind if I merge alsa-driver? I'd like to close bug 46996 and its dupes.
[03:06] <Ubugtu> Malone bug 46996 in alsa-driver "Hotplugged sound devices get sound card index of 0 instead of PCI card" [Wishlist,In progress]  http://launchpad.net/bugs/46996
[03:07] <Keybuk> crimsun: will you need a UVF?
[03:08] <crimsun> Keybuk: for 1.0.11-3ubuntu1 -> 1.0.11-5ubuntu1 ? No, unless I misunderstand the exception process utterly.
[03:08] <zul> hey Hobbsee
[03:08] <Keybuk> no, you don't then
[03:08] <Hobbsee> hey all
[03:08] <Keybuk> go for it
[03:08] <crimsun> Keybuk: thanks.
[03:11] <Hobbsee> woo!  syncs got done again :)
[03:11] <jdong> Hobbsee: yeah :)
[03:11] <Hobbsee> jdong: backports too?
[03:11] <jdong> yeah
[03:11] <jdong> keybuk's been busy today :)
[03:12] <Hobbsee> indeed :)
[03:16] <HrdwrBoB> https://features.launchpad.net/distros/ubuntu/+spec/large-text-editor-removal
[03:17] <HrdwrBoB> it's not complete, but it's a start
[03:18] <Hobbsee> remove nano :P
[03:18] <bddebian> Nooooo
[03:19] <Hobbsee> as long as we keep vi..
[03:19] <HrdwrBoB> hangon let me get this straight
[03:19] <HrdwrBoB> vim/emacs is in a default install? or just on the CD
[03:19] <bddebian> I'm too stupid for a "real" editor, I need my nano ;-P
[03:19] <zul> Hobbsee: i totally agree
[03:19] <Hobbsee> HrdwrBoB: vi at least is in the default install
[03:20] <bddebian> jdong: You can do the fix on firestarter for me
[03:20] <HrdwrBoB> Hobbsee: not vi, vim
[03:20] <bddebian> It's a security issue
[03:20] <jdong> bddebian: we really shouldn't be using dapper-backports for security issues :-/
[03:20] <Hobbsee> HrdwrBoB: true that.
[03:20] <jdong> but it sounds like it needs source changes anyway :)
[03:21] <jdong> bddebian: is it the version in edgy?
[03:22] <bddebian> jdong: It is now
[03:22] <bddebian> jdong: Should be same as dapper + some changes
[03:22] <jdong> !info firestarter edgy
[03:22] <jdong> firestarter (1.0.3-1.2ubuntu2) edgy; urgency=low
[03:23] <jdong> that one?
[03:24] <bddebian> Yessir
[03:24] <Hobbsee> hey Burgundavia
[03:24] <bddebian> Heya Burgundavia
[03:24] <jdong> I'd like to take this moment to complain a bit about why archive.ubuntu.com is so slow?
[03:25] <jdong> 5-20kb/s
[03:25] <Burgundavia> hey Hobbsee, bddebian
[03:25] <Burgundavia> jdong: the DC in london is having issue, afaik
[03:25] <jdong> ah, fascinating
[03:25] <Burgundavia> HrdwrBoB: this yours: https://wiki.ubuntu.com/TextEditorCDRemoval
[03:26] <HrdwrBoB> Burgundavia: yes
[03:26] <Burgundavia> cool
[03:26] <Burgundavia> ping me when you are done with it
[03:26] <HrdwrBoB> I'm done with it for the moment
[03:26] <HrdwrBoB> I have some actual work to do :)
[03:26] <Burgundavia> right, will dig away
[03:27] <HrdwrBoB> cool, cheers
[03:29] <jdong> bddebian: merry christmas, bug 58164
[03:29] <Ubugtu> Malone bug 58164 in dapper-backports "firestarter backport" [High,Confirmed]  http://launchpad.net/bugs/58164
[03:29] <bddebian> jdong: Thx!
[03:29] <bddebian> Wow, all those syncs brought down the merge list a little :-)
[03:33] <lifeless> write barriers?
[03:33] <jdong> lifeless: yeah, flushing that annoying write cache to make sure nothing gets lost in abrupt shutdown
[03:34] <jdong> without it, even journaling FS'es can corrupt during bad shutdowns
[03:34] <jdong> XFS's aggressiveness makes it exceptionally vulnerable to this
[03:34] <lifeless> ah
[03:34] <jdong> so, safety at the cost of performance :-/
[03:34] <lifeless> when does it flush now ?
[03:34] <lifeless> not every write ?
[03:34] <HrdwrBoB> it works ok for me :)
[03:35] <jdong> right now the hd is responsible for flushing its own cache
[03:35] <HrdwrBoB> (though I have XFS setup with an external journal and my disks have a large write cache)
[03:35] <jdong> HrdwrBoB: extern journal turns off barriers on XFS
[03:35] <HrdwrBoB> yeah
[03:35] <jdong> in 2.6.17, XFS team turned on write barriers by default
[03:36] <jdong> so the filesystem keeps track of what's currently in the hd's cache
[03:36] <lifeless> ah, I see
[03:36] <jdong> from what I've heard, ext3 has been doing this for some time now
[03:36] <jdong> the goal was to address the xfs_repair-after-shutdown issues people have been complaining about
[03:36] <lifeless> yeah, writing over whats in cache in the hd would be failure prone
[03:37] <HrdwrBoB> writing over?
[03:37] <jdong> until now, the XFS team has been just blaming it on cheap PC hardware :P
[03:37] <jdong> lifeless: it's not writing over as much as it is losing...
[03:37] <HrdwrBoB> not really, the cache is gone after no power
[03:37] <HrdwrBoB> jdong: which realistically is fair, since XFS was designed to run on real hardware
[03:37] <HrdwrBoB> with persistant write buffers
[03:37] <jdong> HrdwrBoB: right, but I own cheap hardware but still want to run XFS :)
[03:38] <jdub> HrdwrBoB: it was also designed to run with a real operating system... ;-)
[03:38] <jdong> torrenting really blows on ext3/reiserfs
[03:38] <HrdwrBoB> they also suck a lot for large filesystems
[03:38] <HrdwrBoB> however, xfs delete times are awful.
[03:38] <jdong> I agree
[03:39] <HrdwrBoB> so you can't win
[03:39] <jdong> a large journaling area + logbufs=8 helps a bit
[03:39] <jdong> but that's just a band-aid
[03:39] <HrdwrBoB> I'm talking about a few hundred thousand files
[03:39] <jdong> I know, I feel the pain of cleaning out pbuilders every few hours
[03:39] <jdong> for what I gain from XFS, it's a trade-off I am willing to make
[03:40] <jdong> ext3 just simply does not work out for me
[03:40] <HrdwrBoB> I use rsync+hardlinks to do backups
[03:40] <HrdwrBoB> so I end up with LOTS of files
[03:40] <jdong> and after trying to repair two different reiserfs corruptions, I've learned that fsck.reiserfs might as well be symlinked to mkfs.reiserfs :)
[03:41] <jdong> lifeless: btw, bzr is just rocking recently.... handling my kernels superbly
[03:41] <lifeless> thats fantastic nes
[03:41] <lifeless> *news*
[03:41] <HrdwrBoB> jdong: though I screwed XFS by trying to use it on an amd64 kernel
[03:41] <HrdwrBoB> when it was made/used by a 32bit kernel
[03:41] <jdong> HrdwrBoB: ouch... yeah, that's a tough lesson to learn
[03:42] <jdong> HrdwrBoB: did you dodge the <IP_ADDRESS>/7 directory corruption thing?
[03:42] <jdong> that sucked for XFS's reputation :-/
[03:42] <HrdwrBoB> yeah I managed to get around that, fortunately
[03:43] <jdong> :)
[03:44] <jdong> the other good thing about xfs, it provides me with xfs_fsr to entertain me when I'm bored
[03:44] <jdong> I can fit in with Windows users and say that I defrag my filesystem :P
[03:45] <HrdwrBoB> heh
[03:47] <jdub> HrdwrBoB: xfs doesn't work with 64 bit kernels, or is it a filesystem portabiity issue?
[03:48] <jdong> jdub: a xfs volume made in a 32-bit arch can't be used on a 64-bit arch
[03:49] <jdong> if you mount it, you'll corrupt it
[03:49] <jdub> that is so much bong
[03:49] <jdong> no kidding :-/
[03:49] <jdub> is that a linux port issue, or an xfs-in-general issue? i can't imagine why xfs would have portability problems... crazy!
[03:50] <HrdwrBoB> jdub: portability
[03:50] <HrdwrBoB> yeah
[03:50] <HrdwrBoB> linux port issue afaik
[03:50] <maswan> jdong: that's interesting, considering that I'm fairly sure I run that
[03:50] <maswan> (or did I run a 64-bit kernel all the time on that host perhaps?)
[03:50] <jdong> maswan: I've mounted one of my 32-bit xfs partitions under amd64 before, and it didn't seem to mess up
[03:51] <jdong> but so many people have reported problems and the XFS team has said not to do it... so.... yeah
[03:51] <jdub> "doctor, it hurts if i hold my hand above my head!"
[03:51] <jdub> "well, don't do that"
[03:51] <jdub> *bzzt*
[03:52] <jdong> jdub: i saw my doctor about something like that a week back
[03:52] <jdong> he sent me home with a bottle of vicodin
[03:52] <jdub> heh
[03:53] <HrdwrBoB> the problem is, it's not obvious
[03:53] <HrdwrBoB> and the documentation on it is sparse
[03:53] <maswan> no mention of it in the faq either
[03:53] <HrdwrBoB> I didn't realise that was the problem until I found an xfs mailing list post saying "my data is toast!"
[03:54] <jdong> there's mention in XFS's wikipedia article
[03:54] <HrdwrBoB> #
[03:54] <HrdwrBoB> # On the Linux XFS implementations, compatibility issues between 64-bit and 32-bit environments exist.
[03:55] <HrdwrBoB> that's a far cry from "you will frag all your data if you change to 64 bit"
[03:55] <jdong> I know, very vague and not the red bold warning it deserves
[03:55] <jdub> that's why wikipedia is a wiki tho :)
[03:56] <maswan> ah, reading some ml stuff, there are mentions of things like patches to fix log replay when changing bitness and so
[03:56] <HrdwrBoB> maswan: yeah very recently iirc
[03:57] <maswan> so it might only be a "frag all data if you have change to 64 bit while having a dirty log"?
[04:00] <HrdwrBoB> could be
[04:00] <jdong> any firestarter "experts" in here?
[04:00] <maswan> I like starting fires, but that's probably not what you're asking about.
[04:01] <bddebian> heh
[04:01] <jdong> nvm, pseudo-answered my own question
[04:01] <jdong> when you open a port, it opens both tcp/udp
[04:01] <jdong> I was wondering why it didn't ask me which
[04:01] <jdong> good old iptables -L
[04:02] <jdong> but either way, the backport looks good, bddebian
[04:02] <bddebian> jdong: Well I might duck a lot but you grumble alot ;-P
[04:02] <jdong> :)
[04:04] <bddebian> jdong: I'm going to try to look tomorrow but it may be over my head and I don't want doko kicking my ass :-)
[04:04] <jdong> lol
[04:04] <jdong> but think of it this way: it can't be any less usable than the current azureus package that he made
[04:05] <bddebian> Well that's what everyone always says until I upload something ;-)
[04:06] <jdong> lol
[04:09] <jdong> well, I'm calling it a night. take care, everyone :)
[04:09] <Hobbsee> jdong: feel free to fix it :)
[04:09] <bddebian> Gnight jdong, thanks again
[04:15] <slomo> infinity: ping? :) could you please accept dbus from binary NEW for all archs?
[04:29] <jdub> mako: ping (planet debian)
[04:38] <mako> jdub: yes
[04:39] <jdub> mako: howdy - you should upgrade planet debian to planet 2.0 when you have a minute. it is much nicer, and handles some weird feeds better.
[04:41] <robertj> jdub: does planet 2 fix the phenomena by which broken feeds get almost every post reposted sequentially?
[04:42] <jdub> robertj: that was fixed much earlier than 2.0
[04:42] <robertj> I just seem to recall seeing it alot on p.g.o.
[04:42] <jdub> robertj: not for aaaaaaages
[06:20] <wubrgamer> which user owns the apache daemon by default ? on ubuntu ?
[06:31] <dcstimm_> hey guys, what is the difference between the 6.06.1 livecd and the 6.06 livecd for ppc? does it fix any of the imac issues?
[06:33] <LaserJock> dcstimm_: imac issues?
[06:33] <dcstimm_> yeah the isight imac g5 boots to black video
[06:34] <dcstimm_> the imac pre ALS goes crazy when you boot it up and the fans go on high and the console is broken
[06:34] <dcstimm_> imac g4s do not boot and have graphic issues with usplash
[06:35] <dcstimm_> so I was wondering the change log for 6.06.1 to see if anything was fixed
[06:39] <dcstimm_> anyone know?
[06:39] <LaserJock> well, do you have a fully upgraded Dapper
[06:40] <LaserJock> i.e. are you using the dapper-security and dapper-updates repositories?
[06:41] <dcstimm_> im talking about the livecd
[06:42] <LaserJock> hmm, well you could check for bug reports on Launchpad and see if they say anything
[06:42] <LaserJock> I just don't know of that specific problem
[06:43] <dcstimm_> LaserJock, i am just looking for a changelog
[06:43] <dcstimm_> there must be a change log between 6.06 and 6.06.1
[06:43] <dcstimm_> isnt there?1
[06:43] <LaserJock> hmm, not sure
[06:45] <dcstimm_> standard documentation shouldnt be this hard to find
[06:45] <LaserJock> dcstimm_: the release announcement is at https://lists.ubuntu.com/archives/ubuntu-announce/2006-August/000088.html
[06:47] <LaserJock> I don't see anything about imacs but again, a bug report might be more useful
[06:49] <LaserJock> I see a few bug reports about g5 imacs having boot problems
[08:14] <Mithrandir> Seveas: why do you think that aiglx in 58015 comes from an unsupported repo?
[09:22] <Gloubiboulga> hello
[09:23] <Hocko> Hi
[09:23] <Hocko> I have found a major bug in ubuntu that renders it useless.
[09:25] <mdke> Hocko: please report it at http://bugs.ubuntu.com
[09:26] <infinity> Hocko: That might be a bit dramatic.  It's certainly not useless to everyone.
[09:26] <Hocko> Well the bug is when my wife hogs the computer I cant use it!!!!!!!! and she wont get off.
[09:26] <mdke> definitely a major one
[09:27] <HrdwrBoB> Hocko: get another PC
[09:27] <Hocko> come on that is some funny shit
[09:27] <Hocko> lol
[09:28] <HrdwrBoB> alternateively, use multi-seat ubuntu.
[09:28] <HrdwrBoB> *alternatively.
[09:28] <HrdwrBoB> but first, please take this discussion to #ubuntu-offtopic
[09:29] <Burgundavia> mdke: remove vim from the default install: queue flamewar
[09:29] <mdke> sounds like a plan to me, although that one wasn't my suggestion
[09:30] <Burgundavia> somebody else just suggested on the cd thread
[09:30] <mdke> yeah, I read it
[09:30] <mdke> is a good idea, I think. People who like vim can install it, nano/gedit/kate are provided by default.
[09:30] <HrdwrBoB> exactly
[09:30] <mdke> but doesn't sabdfl use vim?
[09:31] <HrdwrBoB> sabdfl can't use apt-get?
[09:31] <HrdwrBoB> I use gvim, that's not installed by default either
[09:33] <Burgundavia> regardless of specific people: do the majority of ubuntu users (or even a very large minority) use vim
[09:33] <jdub> sysadmins the world over will hurt you
[09:33] <Burgundavia> I doubt the answer to that is yes
[09:33] <mdke> maybe a significant majority
[09:33] <mdke> whoops, *minority
[09:33] <mdke> jdub: they can install it too
[09:33] <Burgundavia> jdub: then vim can survive on a -server seed
[09:34] <Burgundavia> personally, I am not afraid of sysadmins
[09:34] <mdke> heh
[09:34] <Burgundavia> us desktop users outnumber them
[09:35] <jdub> the package sizes are not that huge anyway
[09:35] <Burgundavia> vim is almost 20 mb installed
[09:35] <HrdwrBoB> sysadmins needs to stop whinging so damn much and get on with their lives
[09:35] <jdub> installed vs. packages
[09:36] <Burgundavia> jdub: installed is what counts on the cd
[09:36] <HrdwrBoB> (I say that as a sysadmin)
[09:36] <jsgotangco> Burgundavia: we sysads can just make the whole internet stop and make you desktop users cry
[09:36] <jsgotangco> :D
[09:36] <jdub> jsgotangco: score.
[09:36] <jsgotangco> bye bye MMORPG
[09:36] <Burgundavia> nah, I will just recruit the emacs users to keep it running
[09:37] <jsgotangco> lol
[09:37] <Burgundavia> as they will be pleased we stopped shipping vim
[09:37] <jdub> vim-tiny -> desktop; vim -> server
[09:37] <infinity> jdub: s/desktop/minimal/
[09:37] <jdub> infinity: yeah
[09:37] <infinity> jdub: But, yes, Colin and I were discussing that yestersay.
[09:38] <infinity> yesterday, too.
[09:38] <HrdwrBoB> jdub: why vim tiny?
[09:38] <HrdwrBoB> and not nvi
[09:38] <jdub> at least that solves the problem without punching too many people in the face
[09:38] <jdub> HrdwrBoB: vim is at least vim, not vi
[09:39] <infinity> nvi has some annoying misfeatures that driveme batty.
[09:39] <infinity> Otherwise, I couldn't care less which one we choose.
[09:39] <HrdwrBoB> I contended earlier that people who want vim will insteal real-vim
[09:39] <infinity> nvi isn't THTA much smaller, though.
[09:39] <jdub> infinity: misfeatures like... being vi? ;)
[09:40] <infinity> jdub: Like dropping out of insert mode when you hit the beginning of a line, stuff like that.
[09:41] <Seveas> Mithrandir, because quinn storms recent updates og the -i810 driver and aiglx have caused problems for more people
[10:01] <bluefoxicy> It is 4am
[10:01] <bluefoxicy> I leave you with this thought, because I do not have time or really care
[10:02] <bluefoxicy> Someone in #svn brought up that if you compress an input with gzip, then bzip2, you get significant gains
[10:02] <bluefoxicy> this is also said to work with bzip2 and then gzip
[10:03] <bluefoxicy> I'm not sure why; my best hypothesis is that compression leaves characteristics of the input stream in the output stream (after all, input is simply redundancy-eliminated and character encoded; patterns not affected by the algorithm will carry), and so rolling a different compression methodology past it allows the second pass to freely operate on those properties.
[10:04] <bluefoxicy> This is only conjecture; but for similar concept, look into electronic codebook encoding with block ciphers.  Here is an encrypted picture of Tux:  http://en.wikipedia.org/wiki/Image:Tux_ecb.jpg
[10:04] <thom> bluefoxicy: is this going to become relevant any time soon?
[10:04] <bluefoxicy> And with that I leave you for the night.  (lzma debs vs gzip/bz2 vs gzip/bz2/lzma?)
[10:05] <bluefoxicy> thom:  no clue; but at least the thought is circulating.
[10:06] <thom> there's a reason that whilst we _can_ do bzip2 debs very, very few are. the relatively small gain is not worth the overhead
[10:06] <bluefoxicy> thom:  personally I don't care.  I have a memory allocator to write in an attempt to solve a flaw in heap based management and reduce memory usage massively.
[10:06] <bluefoxicy> thom:  no, I mean input -> gzip -> bzip2
[10:07] <bluefoxicy> someone brought up that, strangely, the fact that it's gzipped already doesn't stop bzip2 from also causing a 20% reduction if it would have caused a 20% reduction on the input stream, or some such nonsense
[10:08] <bluefoxicy> thom:  I have no answer for A) if it really works that way; B) if so, why it works that way; or C) If it's significant enough that anyone cares.  Regardless, such things are interesting; if everyone kept their ideas to themselves where would we be?
[10:08] <thom> on topic?
[10:08] <bluefoxicy> normally I'd prove it and give a stronger argument but I'm tired, it's 4am, and I have class tomorrow,
[10:12] <dholbach> good morning
[10:12] <Hobbsee> hey dholbach
[10:12] <dholbach> hey Hobbsee
[10:16] <Chipzz> hrrrrm
[10:17] <Chipzz> anyone knows if something broke in ssh (the client) recently?
[10:25] <Tonio_> hello
[10:34] <Kamion> HrdwrBoB: nvi has crappy undo, vim-tiny doesn't. that alone is enough to recommend vim-tiny
[10:34] <Kamion> and honestly, I'll revert any seed change that removes vim altogether
[10:34] <Kamion> sorry, that removes vi altogether
[10:35] <Kamion> I'd merely protest very loudly about replacing it with nvi
[10:35] <seb128> Kamion: hi. Did you get the UVF mail about gimp?
[10:35] <HrdwrBoB> removing vi is stupid and not an option :)_
[10:35] <HrdwrBoB> I 100% agree
[10:36] <Kamion> HrdwrBoB: right, but Burgundavia doesn't
[10:37] <Kamion> seb128: I think so, will check later
[10:37] <Kamion> Chipzz: perhaps you could give some detail?
[10:37] <seb128> Kamion: ok, no hurry ;)
[10:37] <Chipzz> Kamion: ssh dsa keys take forever to login
[10:37] <Chipzz> rsa keys work
[10:38] <Kamion> Chipzz: nothing in the client has changed in that regard
[10:38] <Chipzz> Kamion: could just as well be the server though
[10:38] <Kamion> use -vvv (or -ddd on the server) to diagnose exactly where the slowness is
[10:40] <sivang> morning
[10:41] <Chipzz> Kamion: it accepts my first 2 (non-dsa) keys, whihc are not authorized, but it never gets around to accepting the third key
[10:41] <Lathiat> i've noticed that
[10:42] <Lathiat> it'd just sit there on a key forever
[10:42] <Lathiat> never figured out why had to SSG_AGENT=""
[10:43] <Kamion> happy to try to diagnose further given a bug with a -vvv trace
[10:43] <Lathiat> yeh if im able to reproduce it again i'll let you know
[10:43] <Lathiat> iirc it sat on the trying private key bit
[10:43] <Lathiat> but yeh i'll get a -vvv next stime i see it
[10:43] <Lathiat> else maybe Chipzz can get one :)
[10:46] <Kamion> revno: 785
[10:46] <Kamion> message:
[10:46] <Kamion>   replace vim with vim-tiny in minimal; move vim to ship
[10:50] <Mithrandir> Kamion: do you know how I mark edgy as frozen?
[10:50] <sivang> Mithrandir: is there a knot planned ?
[10:50] <Mithrandir> sivang: yes, don't you read u-d-a?
[10:51] <sivang> Mithrandir: been out of date lately...should come to terms with my exploding mbox soon.
[10:51] <Kamion> Mithrandir: hmm, you might need to be in ubuntu-drivers - let me have a look
[10:53] <Kamion> hmm, I *used* to be able to make that change - I know I made it for dapper
[10:53] <Kamion> Mithrandir: ask Keybuk, see if a member of the tech board can do it
[10:53] <Kamion> failing that, ask #launchpad
[10:54] <Kamion> Mithrandir: so, it would be nice to figure out why gparted is popping up dialogs behind ubiquity
[10:54] <sivang> Mithrandir: uploads wil be resumed afterwards right?
[10:55] <Tonio_> is the knot 2 freeze ended, or should I wait a bit to upoad ?
[10:55] <Mithrandir> Kamion: uh, when did it start doing that?
[10:55] <Kamion> Tonio_: it only just started
[10:55] <Kamion> Mithrandir: after the initial merge from Debian in edgy
[10:55] <Mithrandir> Tonio_: it started just now, so if you want to upload to main, you'll need to hold off.
[10:55] <Tonio_> kamnion, let's wait a bit then :)
[10:55] <Kamion> I've never been able to figure out why
[10:55] <Tonio_> s/kamnion/Kamion
[10:55] <Kamion> I meant to get a couple of gtk hackers to investigate at the sprint, but forgot
[10:56] <Mithrandir> sivang: yes, we'll be in UVF, getting close to FF afterwards.
[10:56] <Mithrandir> Kamion: he doesn't seem to be around, though.  I'll drop him a mail.
[10:56] <sivang> Mithrandir: k, thanks.
[10:56] <Kamion> Mithrandir: I have two more pieces of no-more-devfs to upload (just merges). Can I do that?
[10:57] <Kamion> specifically nobootloader and partman-target
[10:57] <Mithrandir> Kamion: you're confident in them?  If so, upload away.
[10:57] <Kamion> Mithrandir: as confident as I am in the other bits of no-more-devfs that are already in the archive
[10:57] <Kamion> which is a slightly weasel answer :)
[10:57] <Mithrandir> Kamion: go ahead, then. :-)
[10:58] <Kamion> I'd rather fix the whole thing than just most of it
[10:58] <Mithrandir> yeah
[11:08] <Chipzz> Kamion: just checked, logging in with the same key from another host worked
[11:08] <Tonio_> Hobbsee: http://wiki.thekatapult.org.uk/Download
[11:09] <Tonio_> latest source tarball is more recent than our version ;)
[11:09] <Tonio_> I'm trying to upgrade
[11:09] <Hobbsee> Tonio_: wish you'd seen that about an hour ago.
[11:09] <Hobbsee> oh, wait, we'd need a UVF for it anyway.  damn
[11:09] <Tonio_> Hobbsee: yes, but if it closes 2 bugs that'll be okay ;)
[11:10] <Hobbsee> true that
[11:16] <Kamion> it does work
[11:17] <Kamion> you have to sign it and provide an 'affects' line
[11:18] <Hobbsee> ah, right
[11:18] <Hobbsee> i'll remember that :)
[11:18] <Tonio_> Kamion: thanks for the tip, that'll help :)
[11:20] <Kamion> there's documentation on the web somewhere for affects lines
[11:20] <Hobbsee> true that
[11:20] <Hobbsee> i just couldnt remember what it actually says
[11:47] <infinity> Is it sad that I can identify source packages base on only seeing their Build-Depends lines?
[11:48] <infinity> I suspect this may be a sign that I've descended into complete insanity.
[11:48] <infinity> s/base/based/
[11:49] <Hobbsee> infinity: you mean you werent insane before?
[11:50] <infinity> Mithrandir: I can mark edgy as frozen.
[11:50] <infinity> Hobbsee: I was, but perhaps only partially.
[11:50] <Hobbsee> infinity: ahhh...right
[11:50] <Mithrandir> infinity: please do so.
[11:50] <Mithrandir> infinity: I wonder why you can and I can't, though.
[11:50] <infinity> Mithrandir: Because I have a rubber duckie next to my name.. *cough*
[11:51] <infinity> Mithrandir: Done.  You're frozen.
[11:51] <Mithrandir> infinity: thanks.
[11:52] <infinity> I suspect that's something we might want the -release team to be able to do.
[11:52] <Mithrandir> yeah, it'd be kinda useful.
[11:52] <infinity> Anyhow, until they take away my duck again, I can do it for now.
[11:54] <mjg59> Does that make it Ben's problem now?
[11:55] <dholbach> infinity: they took your duck away?
[11:55] <infinity> mjg59: In theory, LRM has been Ben's problem since edgy opened.  I just have a hard time keeping from meddling.
[11:55] <infinity> dholbach: They took it away, then gave it back when it was determined that I couldn't yet do my job without it.
[11:56] <dholbach> infinity: I hope you'll be able to keep it this time
[11:56] <infinity> dholbach: I don't really want it.  Being an LP admin means getting mail from all sorts of odd people with strange questions.  Doubly-so, because I'm the first name in the team list, due to being alphabetically challenged. :)
[11:57] <infinity> dholbach: But it's nice to be able to poke a few buttons that we, as a team, should be able to poke, but can't yet.
[11:57] <Hobbsee> infinity: hah.  i've found that with being a team leader on LP too.  emailed about everything, and poked into actually doing something.
[11:57] <dholbach> Urg... ok, I understand :-)
[11:57] <Hobbsee> infinity: try changing your name to Zaphod or something.
[11:58] <seb128> at what time is the meeting tomorrow? did we shifted or skipped the 7am meeting?
[11:59] <Seveas> @schedule paris
[11:59] <Seveas> hmm, not on in here
[11:59] <Seveas> @config channel plugins.webcal.url http://fridge.ubuntu.com/event/ical
[11:59] <dholbach> "31 Aug 17:00: Ubuntu Development Team"
[12:00] <Seveas> @config channel plugins.webcal.filter #ubuntu-meeting
[12:00] <seb128> dholbach: the fridge is not really a reference to me :p
[12:00] <Seveas> @config channel plugins.webcal.dotopic
[12:00] <Ubugtu> False
[12:00] <seb128> dholbach: and I would prefer 9am better ;)
[12:00] <dholbach> seb128: then ask sfllaw
[12:00] <seb128> dholbach: that's why I ask on that chan ...
[12:00] <seb128> dholbach: not to be pointed to the fridge :p
[12:01] <dholbach> there's not other "official" information atm and I can't remember a discussion about it
[12:01] <seb128> ok
[12:02] <Seveas> dholbach, according to the fridge it's hug day today
[12:03] <dholbach> sfllaw: ^^ did you announce it to the fridge, but didn't send an announce mail?
[12:03] <seb128> I think every wednesday is a hug day according to the fridge
[12:10] <Mithrandir> ogra: are you working on fixing edubuntu's size problem?
[12:10] <ogra> yes
[12:11] <Mithrandir> Gloubiboulga: xubuntu alternate CDs are oversized, you're aware of that?
[12:11] <ogra> i was hoping for Kamion to probably make the vim switch :)
[12:11] <Gloubiboulga> Mithrandir, yep
[12:11] <Mithrandir> he already did.
[12:11] <ogra> apart from 6M on i386 i'm fine
[12:11] <ogra> oh
[12:11] <ogra> then i need to check size again :)
[12:11] <Kamion> it's not active yet
[12:12] <ogra> ah
[12:12] <Kamion> Mithrandir: can I upload ubuntu-meta to change that?
[12:12] <Mithrandir> Kamion: please do.
[12:12] <Kamion> needs a priority change on the archive as well
[12:12] <Kamion> ogra: you'll probably want to drop vim from your ship
[12:14] <ogra> right
[12:15] <Gloubiboulga> Mithrandir, Jani has modified the seeds, could you rebuild the alternate isos?
[12:16] <Mithrandir> Gloubiboulga: the new seeds have been uploaded too?
[12:16] <mvo> doko: around?
[12:16] <Kamion> can you wait for the ubuntu-minimal change?
[12:16] <doko> mvo: yes
[12:16] <Gloubiboulga> Mithrandir, yes
[12:17] <Mithrandir> Kamion: if that "you" was me, sure.
[12:17] <Kamion> mostly to Gloubiboulga
[12:17] <Gloubiboulga> Kamion, I can wait :)
[12:18] <Mithrandir> *sigh*; alternate ppc is still oversized.
[12:19] <Kamion> oh, hmm, it will take a little while
[12:19] <Mithrandir> I'll need to rebuild ubuntu alternate too.
[12:19] <Kamion> need to wait for the override change I just applied to vim-tiny to appear in a publisher run
[12:19] <Kamion> so go ahead and rebuild xubuntu if there are other things to be tested
[12:19] <Kamion> hmm, what to do about powerpc I wonder
[12:20] <Mithrandir> Kamion: old image, it looks like.  It includes *-ppds still
[12:20] <Mithrandir> I'll do it after xubuntu alternate
[12:20] <Kamion> oh, what happened to this morning's build?
[12:20] <Mithrandir> I disabled it. :-P
[12:20] <Mithrandir> (so much for checklists, sorry)
[12:20] <Kamion> oh
[12:20] <Kamion> ok :)
[12:21] <mvo> Mithrandir: permission to upload a fix to hplip? it fixes a upgrade issue and is only a two-line change in the rules file
[12:21] <Kamion> you needed to rebuild alternate for partman-target anyway
[12:21] <Mithrandir> Kamion: oh, sure.
[12:21] <Kamion> which is on its way shortly
[12:21] <Mithrandir> mvo: what kind of upgrade issue?  As in, is it useful for knot?
[12:21] <infinity> Mithrandir: BTW, don't bother building ia64/sparc images for knot-2. Not worth the pain, they won't be functional anyway (at least, not live images)
[12:22] <mvo> Mithrandir: people upgrading from dapper->edgy will be bitten by it, its a postinst failure. I can put up a debdiff if you want
[12:22] <Mithrandir> mvo: yes, please.
[12:25] <mvo> Mithrandir: http://people.ubuntu.com/~mvo/hplip_0.9.11-2ubuntu5.debdiff (a similar change is in the latst debian package)
[12:25] <Kamion> ok, I'm going to grossly fudge ubuntu-meta to speed things up
[12:25] <Kamion> partman-target uploaded
[12:25] <Mithrandir> Kamion: thanks.
[12:26] <Mithrandir> mvo: ok, upload away.
[12:26] <mvo> Mithrandir: thanks
[12:36] <Gloubiboulga> hum, xubuntu alternate isos still have the same size
[12:52] <seb128> Mithrandir: is that ok to upload a nautilus with a Conflicts version updated to fix bug #56985 ?
[12:52] <Ubugtu> Malone bug 56985 in nautilus "nautilus-data missing Replaces: nautilus" [High,Confirmed]  http://launchpad.net/bugs/56985
[12:53] <Mithrandir> seb128: no other changes?  Go ahead.
[12:53] <seb128> nop, no other change
[12:53] <seb128> ok, thank you
[12:55] <janimo> Gloubiboulga: hi
[12:55] <Kamion> seb128: argh, why conflicts?
[12:56] <Kamion> seb128: if a file moves, you should use Replaces
[12:56] <janimo> Gloubiboulga: I wonder what grew so much since dapper in the alternates
[12:56] <Kamion> Conflicts makes upgrades unnecessarily hard for the package management tools
[12:56] <janimo> Gloubiboulga: I'd prefer keeping full vim if we can though
[12:56] <seb128> Kamion: I do use some Replaces, some Debian guys use Conflicts, in that case the change come from Debian I just updated the version
[12:57] <Kamion> can you get that changed in Debian please?
[12:57] <seb128> Kamion: ok, will do
[12:57] <Kamion> thanks
[12:57] <seb128> np
[01:01] <seb128> Mithrandir: ok to update Replaces version for gnome-menus (bug #56984)
[01:01] <Ubugtu> Malone bug 56984 in gnome-menus "python-gmenu package missing "Replaces: gnome-menus"" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/56984
[01:02] <Mithrandir> seb128: ok.  Do you have many more similar replaces/conflicts bugs?
[01:02] <seb128> Mithrandir: no, that was only nautilus and gnome-menus
[01:02] <Mithrandir> seb128: I'm fine with a few of them, but I'd really like us not to end up with having to rebuild half of gnome.
[01:02] <Mithrandir> seb128: ok, that's fine then. :-)
[01:02] <seb128> yeah, sure
[01:02] <seb128> thank you ;)
[01:03] <seb128> rebuild of GNOME is for next week :p
[01:03] <seb128> (GNOME 2.16.0 tarballs on monday)
[01:03] <Gloubiboulga> janimo, ok for vim, I guess that we can remove a bunch of language packs
[01:04] <Kamion> janimo: moving from vim to vim-tiny in minimal was a change that affected all derivatives, btw
[01:04] <Mithrandir> seb128: that's fine since we'll be a bit away from a knot at that time.
[01:04] <seb128> right
[01:04] <Kamion> janimo: if you want to keep vim in your default installation, that would need to be done by adding it to your desktop
[01:04] <seb128> anyway lunch time for now, bbl
[01:04] <Mithrandir> Gloubiboulga: oh, xubuntu built a bit of time ago.
[01:04] <janimo> Kamion: ok thanks
[01:04] <Gloubiboulga> Mithrandir, yep I've seen this, thanks
[01:04] <Mithrandir> I'll do a ubuntu build now to make sure ppc is fine, size-wise.
[01:05] <Gloubiboulga> Mithrandir, I'll certainly poke you later for an other build (size issues again)
[01:05] <Mithrandir> Gloubiboulga: sure.
[01:11] <janimo> Kamion: is this correct syntax in seeds * language-support-${Languages} [i386]
[01:11] <janimo> I am trying to move all but English language supports only to i386 for now
[01:12] <Kamion> janimo: yes, that's right
[01:13] <janimo> Kamion: so what's in ship goes to the alternate CD and live seed to the desktop. These are the two places where Languages appear. This is what I assumed so far but want to make sure
[01:14] <Kamion> janimo: right
[01:14] <Kamion> I should write up a README at some point
[01:16] <janimo> ok, thanks I wasn't sure if the relatively recent ship-live changed what I knew in dapper
[01:17] <Kamion> packages in ship-live end up on the desktop CD as .debs, rather than being installed in the live filesystem
[01:17] <Kamion> so you get /casper/filesystem.squashfs containing boot+minimal+standard+desktop+live, and /dists/ and /pool/ containing ship-live
[01:18] <Seveas> Kamion, 'added vim-tiny to...' -- vim conflicts with vim-tiny, so installing vim whill remove ubuntu-minimal, right?
[01:19] <Kamion> Seveas: vim Conflicts: vim-tiny (<< 1:6.4-001+3)
[01:19] <Kamion> Seveas: current vim-tiny is 1:7.0-035+1ubuntu2
[01:19] <Seveas> ah
[01:23] <janimo> Kamion: I wonder if  debs on the liveCD copuld be used to install xubuntu-at- packages we talked about yesterday?
[01:23] <janimo> what is that ship-live repo used for now?
[01:24] <Kamion> janimo: it's possible, but would require a certain amount of head-scratching in ubiquity. :-)
[01:24] <Kamion> janimo: basically to make stuff like build-essential available
[01:24] <janimo> Kamion: to make sure they don't get installed on the disk you mean?
[01:24] <Kamion> and various network access packages
[01:24] <Kamion> janimo: no, just to do the installation at all
[01:25] <Kamion> it's all just glue, nothing massively complicated, but would need to be done ...
[01:26] <janimo> I'll have to take a look I guess if there is no other solution which lets gnome AT tools be installed on the CD but only optional on the final install
[01:26] <Kamion> the other solution is live-cd-stacked-filesystems, as I said yesterday
[01:27] <Kamion> having the accessibility packages be a layer stacked just above the desktop
[01:27] <Kamion> so ubiquity could choose to copy just the desktop bit or desktop+accessibility
[01:27] <Kamion> yet another alternative is just teaching ubiquity to manually remove the AT packages
[01:27] <janimo> right. Is that done already? Is it to be used by ubiquity for something else?
[01:27] <janimo> right I was thinking of the manual removal as it happens with languages
[01:27] <Kamion> it's to be used by ubiquity in place of its current remove-lots-of-packages hacks; I think it's mostly done
[01:28] <janimo> ok
[01:28] <elmo> Kamion: ehm, dude
[01:28] <elmo> Kamion: cdimage is up to 479GB
[01:28] <elmo> pls to be reigning it in
[01:28] <janimo> Gloubiboulga: committed modified seeds with only En on amd64 and ppc
[01:28] <Kamion> elmo: ok, I'll have a look. you mean the bit that's mirrored?
[01:29] <janimo> but I'd like to wait a bit until I upload x-system-tools before a respin ok?
[01:29] <elmo> Kamion: yes
[01:29] <Kamion> I'll just nuke the point-release dapper builds
[01:30] <Gloubiboulga> janimo, ok
[01:30] <janimo> Gloubiboulga: did you ./update from xubutu-meta for the upload?
[01:31] <infinity> Kamion: Not sure we can do that, since it gives us some undefined behaviour.
[01:31] <Kamion> infinity: ?
[01:31] <janimo> I wonder why my subsequent upload of today deleted the two xfce plugins for HPPA, and they were ok when you uploaded
[01:31] <infinity> Kamion: live-cd-stacked-filsystem assumes a linear 1+2+3 growth in filesystem stacking.
[01:31] <Kamion> infinity: I'm not sure what that means
[01:31] <infinity> Kamion: So, if we're doing base+desktop+live+live-dvd, where does live-at fit?
[01:32] <Kamion> infinity: base+desktop+live-at+live+live-dvd
[01:32] <infinity> Kamion: (We're overlaying a new dpkg status file each time, so we can't really do anything nonlinear)
[01:32] <Kamion> right, seems pretty linear to me though
[01:32] <Gloubiboulga> janimo, I didn't
[01:32] <infinity> Kamion: Okay, so live-at will always be there, check.  Then that's fine.
[01:32] <janimo> Gloubiboulga: you wrote the changelog by hand?
[01:32] <infinity> Kamion: I wasn't really following the above well enough to catch that, I guess.
[01:33] <Kamion> elmo: down to 376GB - is there anywhere else I can put stuff like the archival copy of dapper.0?
[01:33] <Gloubiboulga> janimo, yes, I need to use the tools wa have next times ;)
[01:34] <janimo> Gloubiboulga: ok :). So after you commit to the seeds, just run ./update from the most recent xubuntu-meta, and it will generate the new version with automated changelog
[01:34] <elmo> Kamion: public or for backup/storage?
[01:34] <Kamion> elmo: dapper.0 probably still ought to be public
[01:35] <Kamion> elmo: you could backup old-releases/{warty,.pool/warty*} non-publicly now, though
[01:35] <Kamion> that's only 2.3GB though
[01:37] <Kamion> you know, I'm just going to stop keeping two DVD builds
[01:37] <elmo> Kamion: we could put them on hutte I guess - got any suggestions for a hostname?
[01:37] <Kamion> elmo: old-releases.ubuntu.com?
[01:38] <elmo> ok
[01:38] <elmo> I'll setup an RT ticket - where should we copy the stuff from?
[01:38] <Kamion> for warty or dapper?
[01:41] <Kamion> elmo: /srv/cdimage.ubuntu.com/www/full/{,ports/,kubuntu/,edubuntu/,xubuntu/}dapper/release/
[01:41] <elmo> blink
[01:41] <elmo> that's old releases?
[01:41] <Kamion> that's dapper.0
[01:41] <Kamion> except make that /srv/cdimage.ubuntu.com/www/full/{,ports/,kubuntu/,edubuntu/,xubuntu/}releases/dapper/release/
[01:42] <elmo> hmm, ok
[01:42] <Kamion> the archival copies of warty and hoary are in /srv/cdimage.ubuntu.com/www/full/old-releases/
[01:42] <Kamion> I guess all of that can be moved
[01:42] <lifeless> infinity: - has evms changed in the dapper at all ?
[01:43] <lifeless> infinity: I have a sick home server, I powered it off by mistake, but its claiming
[01:43] <lifeless> device-mapper: unknown target type
[01:43] <Mithrandir> lifeless: with a stock kernel?
[01:43] <infinity> lifeless: Not that I know of...
[01:44] <lifeless> Mithrandir: yes, I'm booting off a 6.06lts livecd right now, and evmsn sees the volumes, bu refuses to activate with that error
[01:44] <lifeless> doing evms_activate in busybox - when it fails to boot off hard disk - gives the same spew
[01:45] <lifeless> I'm trying to find the bug I filed in launchpad that was related to this -
[01:45] <lifeless> when evms was broken during the dapper development cycle
[01:52] <lifeless> ahem, faq-like question from moi:
[01:52] <lifeless> http://evms.sourceforge.net/faq.html
[01:52] <lifeless> the 'volume activation' entry there matches my symptoms.
[01:53] <lifeless>  - do we have that patch installed ? (yes, I know I should look myself, but my network access is rather curtailed with my main machine down)
[01:54] <Mithrandir> yes, we have always have had that applied
[01:54] <lifeless> thanks
[01:55] <Riddell> Kamion: ubiquity fails on today's kubuntu CD https://launchpad.net/distros/ubuntu/+source/ubiquity/+bug/58199
[01:55] <Ubugtu> Malone bug 58199 in ubiquity "Fails at apt-setup on kubuntu 20060830" [Untriaged,Unconfirmed]
[01:57] <Kamion> thanks, I'll check; I think that's a dupe
[01:58] <mvo> Kamion: I will need some files on a ubuntu-alternative CD for the cdrom-dist-upgrades spec. what is the best way to learn more aobut the CD building and how I can integrate my stuff?
[01:58] <Kamion> mvo: grab http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/, or just file a bug on /products/ubuntu-cdimage
[01:59] <Kamion> mvo: how much space are we talking about here?
[02:00] <mvo> Kamion: about 1,6mb (1,4 of this are mo files)
[02:01] <Simira> Riddell: do you know if anything is done with kmail/kontact? they're setting new records of number of crashes at work today
[02:01] <mvo> Kamion: so if we only do the supported languages it should be no more than ~400k
[02:02] <Kamion> ok
[02:04] <Riddell> Simira: I'm not sure what you're asking
[02:08] <Kamion> Riddell: found the problem, fixing
[02:14] <elmo> Kamion: any chance you could move everything you want on old-releases to a new subdir of www/ ?
[02:15] <elmo> Kamion: we could do it if you like, of course, but it seems safer/saner if you guys do
[02:18] <lifeless> Mithrandir: are you running evms ?
[02:18] <lifeless> Mithrandir: can you do 'dmsetup targets' and show me the output ?
[02:21] <Kamion> elmo: sure, I'll do so once I've finished with this ubiquity bugfix
[02:21] <Simira> Riddell: do you know anything about kmail/kontact bugs and how fast they are being fixed? kmail seems to crash a lot
[02:22] <sfllaw> dholbach: The ones on fridge are pre-scheduled.  Last week's fell in between two of them.
[02:22] <Riddell> Simira: I don't know, I'd guess developmen will be focusing on kde 4
[02:22] <mvo> Kamion: can we use "CDROM_ROOT/upgrade/" as the place for the dist-upgrader? or is that not-so-good because it was used in older debian releases to put packages in that needed upgrading before the install?
[02:23] <elmo> Kamion: thanks
[02:23] <Kamion> mvo: wouldn't it be better to put it in the same relative place as it is in the archive? so /dists/$DIST/main/upgrader-$ARCH/ or whatever it is
[02:23] <lifeless> infinity: if you are still up, diagnosis is that dmsetup is missing some targets
[02:23] <Kamion> dist-upgrader-$ARCH
[02:24] <lifeless> http://rafb.net/paste/results/hm6hdZ52.html shows what it should look like for me, and the #evms folk are saying 'kernel patches affect this'
[02:24] <infinity> lifeless: Fun.  Of course, I know pretty much nothing about evms.  The fact that I've uploaded it a few times means nothing. :)
[02:24] <doko> Kamion: I'd like to upload OOo 2.0.4rc1, it shouldn't affect the knot-cd unless somebody processes the new binaries in NEW (and if all builds succeed, then it could be a candidate for knot-2 as well)
[02:25] <infinity> lifeless: I can confirm the lack of targets on edgy, though.
[02:25] <lifeless> CONFIG_BLK_DEV_DM_BBR
[02:25] <Kamion> doko: -> Mithrandir, but I'm pretty sure the answer will be "please hold off until after knot-2"
[02:25] <lifeless> thats apparently not on in our kernel config anymore
[02:25] <lifeless> and thats what I need
[02:25] <infinity> doko: I'd rather not have the buildds stuffed up while we're trying to do the release, especially since we only have one powerpc buildd.
[02:25] <Mithrandir> doko: please hold it off until we're post-knot-2.
[02:26] <infinity> lifeless: Perhaps best to take it up with BenC then, either on IC< or in a bug report.
[02:26] <Mithrandir> lifeless:
[02:26] <Mithrandir> : tfheen@thosu ~ > sudo dmsetup targets
[02:26] <Mithrandir> striped          v1.0.2
[02:26] <Mithrandir> linear           v1.0.1
[02:26] <Mithrandir> error            v1.0.1
[02:26] <lifeless> infinity: well, I have no mail etc until I unfuck this
[02:26] <lifeless> infinity: but I appreciate its really in his court
[02:26] <doko> Kamion, Mithrandir: yeah, and then I have to hold off for feature freeze ... you know that -base and the wizards are currently broken?
[02:27] <infinity> doko: Blocking the powerpc buildd for the next 12 hours just isn't an option right now. :/
[02:27] <infinity> doko: If you upload right after knot-2, we'll all be much happier.
[02:27] <Kamion> there is a week between knot-2 and feature freeze
[02:27] <Kamion> so no, you won't have to hold off
[02:28] <Mithrandir> doko: unless something goes wrong, you should be able to upload late tomorrow or Friday.  That leaves you a fair bit of time.
[02:28] <doko> ok
[02:36] <jsgotangco> doko: the SoC evaluations should be in already right? i was away for a few days....
[02:36] <doko> jsgotangco: yes
[02:37] <jsgotangco> ok sorry just catching up now...and google's app gives me server errors
[02:38] <jsgotangco> argghh these server errors suck
[02:48] <iGama> Hy!
[02:48] <iGama> i have 1 question
[02:48] <Simira> iGama: ask on #ubuntu
[02:48] <iGama> what do i have do to , so submit a packet proposol?
[02:49] <iGama> Simira its not that kind of help :p
[02:49] <iGama> package pros.
[02:49] <WaterSevenUb> iGama, you are talking about the OO-PT thing?
[02:49] <iGama> also that
[02:50] <WaterSevenUb> Simira, the thing is that currently there is available openoffice-pt_PT and dictionaries for it, as well as many updates on aspell-pt and ispell-pt....
[02:50] <iGama> but in generall ways, what do i have do to, to submit a package?
[02:50] <WaterSevenUb> Simiria, that we would like to see in Edgy.
[02:50] <Simira> WaterSevenUb: uh... wrong nickname?
[02:51] <iGama> Simira so, in witch channel can we find the answer?
[02:51] <Simira> iGama: #ubuntu-motu, maybe?
[02:51] <pygi> jdub, poke?
[03:00] <dholbach> sfllaw: what does that mean?
[03:01] <sfllaw> It means that I forgot about this one.
[03:01] <sfllaw> :)
[03:01] <sfllaw> It thought it was next week.
[03:04] <lifeless> anyone know what TZ benc is operating on ?
[03:04] <StevenK> lifeless: -4
[03:04] <StevenK> lifeless: As the changelog for the kernel would have told you.
[03:05] <lifeless> thats where he *lives*, not what hes operating on.
[03:05] <StevenK> Bah, semantics. :-P
[03:05] <lifeless> and given that the kernel changelog also fails to mention 'fuck evm by removing BBR support', its not really a useful hint to give me
[03:13] <neuralis> infinity: poke me when you're around
[03:14] <infinity> neuralis: I'm vaguely aroundish.
[03:14] <lifeless> is there a dead chicken to build just -one- of our brazjillion kernel targets ?
[03:16] <Mithrandir> lifeless: debian/rules binary flavours=amd64-k8, I think
[03:21] <zul>  binary-debs
[03:23] <sivang> hmm, something is changed in when apt updates the cache.. it adds something like "GB-Translation" to the lines.. Is that part of a new specification that got implemented ?
[03:25] <mvo_> sivang: that are the translated package descriptions
[03:28] <jdong> infinity: buildd's not finding packages that exist :(
[03:28] <jdong> https://launchpad.net/+builds/+build/240508
[03:28] <jdong> it was just under dependency wait for libifp-dev, which is definitely in dapper universe
[03:28] <infinity> jdong: Err, what?
[03:28] <infinity> jdong: That's needs-build.
[03:28] <jdong> it was depwait a second ago
[03:28] <jdong> I swear
[03:29] <infinity> jdong: How many seconds? :)
[03:29] <jdong> 3 seconds ago, I swear :)
[03:29] <infinity> jdong: Anyhow, I assume that means that libifp-dev was recently published or something.
[03:29] <azeem> jdong: always make screenshots before you tell infinity
[03:29] <infinity> Or, wait.  You said that libifp-dev is in universe?
[03:29] <infinity> jdong: Let me guess, amarok is in main?
[03:29] <jdong> perhaps
[03:29] <infinity> That would do it, then.
[03:29] <infinity> main doesn't build against universe.
[03:29] <jdong> yes, it is :(
[03:30] <jdong> darn
[03:30] <slomo> janimo: evince-gtk FTBFS... could you take a look at it? or is it not used anymore by xfce?
[03:30] <janimo> slomo: I'll take a look thanks. I was planning to update it to newer evince anyway
[03:31] <slomo> janimo: thanks :)
[03:31] <janimo> slomo: thanks for moving it to dbus-90 :)
[03:32] <slomo> janimo: only a rebuild ;) unfortunately i tested only the real evince... looks like evince-gtk may need some patches for a newer djvu or something
[03:32] <janimo> slomo: ok, I'll check it out.
[03:33] <sivang> mvo_: cool
[03:33] <janimo> Mithrandir: all uploads frozen or onlyu those that go to the ubuntu cd?
[03:33] <ogra> janimo, usually main
[03:33] <Mithrandir> janimo: main is frozen.  Getting exceptions for stuff which doesn't go on the CD is obviously easier than for stuff which goes on the CD.
[03:34] <janimo> Mithrandir: I mean main and not ubuntu CD (but xubuntu)
[03:34] <janimo> it was usually less frozen than the main CD while that built
[03:35] <Mithrandir> janimo: if you ask for xubuntu-specific exceptions, I can't see me not granting them, no, but you might want to have your changes eyeballed for sanity anyway?
[03:35] <janimo> Mithrandir: ok, thanks.I'll point to the log when I am done.
[03:40] <imbrandon> siretart: ping
[03:41] <imbrandon> infinity: the libifp is in main in edgy, we cant promote it in a published distro for the backport huh ? we'll need a source change i'm guessing
[03:41] <jdong> infinity: or allow backports to build against all sections? :P
[03:42] <infinity> imbrandon: Changing components in a published distro is definitely a no-no.
[03:42] <imbrandon> right
[03:42] <imbrandon> well see thats the problem, what about allowing the -backports to build against all sections
[03:42] <imbrandon> [08:40]  <Riddell> jdong: it seems like a bug in the backports implementation to me, this sort of thing can not be too uncommon
[03:42] <infinity> Allowing backports to break component expectations may be acceptable, if we're also making it clear that we don't support backport in any way, shape, or form.
[03:42] <infinity> Since, then, sections don't matter for backports.
[03:42] <infinity> (Except for the non-free/free distinction)
[03:42] <imbrandon> infinity: yea i think thats clear since its not enabled by default either
[03:43] <imbrandon> its a choice to use it
[03:43] <jdong> right
[03:43] <infinity> I'll have to bring it up with the rest of the archive team.  It's not a policy decisoin I'll make in a vacuum.
[03:43] <infinity> But since we don't provide any commercial support for backports, I suspect the main/universe distinction is pointless anyway.
[03:43] <jdong> it's pretty clearly stated already that backports is not a supported repo
[03:43] <imbrandon> not a problem, just curious an eta ? as in will it be a meeting agenda or you just gonna poke them ?
[03:44] <Kamion> I'm not sure there's actually anything wrong with changing components in backports
[03:44] <infinity> imbrandon: I'll just bring it up with my team when we're not busy trying to do a Knot release.
[03:44] <Kamion> policy-wise
[03:44] <Kamion> but I don't know whether Soyuz deals with that gracefully
[03:44] <imbrandon> infinity: definately ;)
[03:44] <infinity> Kamion: No, but there's something wrong with chanigng components of an already-published non-backport library to allow a backport to build. :)
[03:44] <Kamion> oh, non-backport? right
[03:45] <imbrandon> infinity: yea i was just sigesting that as a no-no ;)
[03:45] <imbrandon> sugesting*
[03:45] <imbrandon> jez
[03:45] <imbrandon> e/g we COULDENT do that soo what COULD we do kinda thing
[03:45] <infinity> Kamion: Hence why I figure it might make more sense to just view backports itself as universe/multiverse free-for-all, and drop the main/resitrcted distinction entirely, since backports aren't supported, hence de-facto not "main".
[03:45] <jdong> if we backported libifp-dev to dapper, would it magically turn buildable?
[03:45] <imbrandon> jdong: no
[03:46] <infinity> jdong: Only if we popped it in main.  But don't do that.
[03:46] <imbrandon> t dosent cahnge the component
[03:46] <jdong> k
[03:46] <imbrandon> right
[03:46] <infinity> jdong: Not much point in backporting anything if we backport all the libraries too.  Then you just have.. Edgy.
[03:46] <imbrandon> exactly ;)
[03:47] <jdong> well, I'm gonna grab breakfast, you guys enjoy hashing this out :)
[03:47] <imbrandon> infinity: so ping you in ~36+ hours and ask again ( hince after knot publish )
[03:48] <elmo> I'd pay someone $$$ to "fix" ubuntu-server so nano isn't even installed
[03:48] <infinity> Kamion: Anyhow, I don't know if soyuz does per-pocket overrides, but I doubt it's worth the effort.  I can just mangle the ogre setup on the -backports chroots to always build against main+universe (for free sources) and main+universe+multiverse+restricted (for non-free sources), and just hand-wave the problem away.
[03:48] <imbrandon> elmo: nooooo
[03:48] <imbrandon> heh
[03:49] <infinity> elmo: Paypal<EMAIL_ADDRESS>[03:49] <Hobbsee> elmo: sounds good :)  who uses nano anyway :)
[03:49] <imbrandon> Hobbsee: i'll sooo disable ssh
[03:49] <imbrandon> ;)
[03:49] <jdong> EVERYONE USES NANO :)
[03:49] <infinity> They do?
[03:50] <infinity> I despise it.
[03:50] <jdong> what newbie editor would you suggest then?
[03:50] <infinity> You don't want to know.
[03:50] <jdong> I'm not teaching someone how to use vi over the phone :(
[03:50] <imbrandon> hahaha
[03:50] <infinity> Well, you might want o know, but if I tell you, elmo will hit me.
[03:50] <Hobbsee> haha
[03:50] <imbrandon> kwrite ;)
[03:50] <Hobbsee> infinity: well tell elmo to cover his ears
[03:50] <jdong> the last time I did that, swear words came out
[03:50] <infinity> elmo: Don't look.
[03:50] <infinity> jdong: I use "ae" as a lightweight newbie editor.
[03:50] <Hobbsee> imbrandon: pretty hard for me to do anything that way
[03:51] <infinity> (And, no, it's not in the archive, it's not been in Debian since potato)
[03:51] <jdong> interesting
[03:51] <imbrandon> Hobbsee: not realy you can tunnel X over ssh , i just havent told you how yet ;)
[03:51] <Hobbsee> imbrandon: i've seen it before.  in fact, i've done it before.  it's too damned slow though.
[03:51] <Hobbsee> imbrandon: i had ajmitch and StevenK over here, remember?
[03:51] <imbrandon> hehe *couch*nx*cough*
[03:52] <imbrandon> nx over ssh can go fast on a 56k ;) but thats beside the point when you only have console
[03:53] <imbrandon> and considering nx isnt in the archives either
[03:53] <Mithrandir> nx is stuffed with crack
[03:58] <janimo> dholbach: hi, is g-s-t 2.15 supposed to be less buggy than 2.14 was?
[03:58] <janimo> I get weird errors and want to make sure it's not my system that is broken
[03:58] <dholbach> janimo: it uses new infrastructure
[03:58] <janimo> that's an elusive answer ;)
[03:58] <dholbach> janimo: make sure you file a bug or ask garnacho on #gst on irc.gimp.net
[03:59] <dholbach> that's an answer that indicates that it might be due to new infrastructure :)
[03:59] <janimo> I was just generally asking fro you rexperience is it working?
[03:59] <seb128> janimo: new infrastructure is likely to bring new bugs too
[03:59] <janimo> since all tools fail but differently
[03:59] <seb128> janimo: not that good but ganarcho is working on it this week
[04:00] <janimo> good part is he reduced a few gnome dependencies in the code, my gtk-only patch is a lot smaller
[04:01] <janimo> I'll talk to him about this on #gst.
[04:02] <janimo> Mithrandir: the upload exception I asked for was for xubuntu-system-tools. It's not a simple diff, but a new orig.tar.gz as well. I resynced with gnome-system-tools
[04:02] <Mithrandir> janimo: if you think it's good to have it in xubuntu knot-2, feel free to upload it.
[04:02] <janimo> with the current version it won't start at all, with the new upload it starts and works as correcly as g-s-t
[04:03] <Mithrandir> sounds like progress to me. :-)
[04:03] <janimo> Mithrandir: thanks
[04:03] <janimo> yes, it closes one PL bug, possibly opens the gate a few new ones :)
[04:03] <janimo> s/PL/LP/
[04:05] <dholbach> janimo: they don't bite... often
[04:07] <ivoks> does anyone knows what's the size of whole archive?
[04:07] <infinity> Yes.
[04:07] <ivoks> i'm buying new disks, so i'm thinking about mirroring it
[04:08] <infinity> lp_archive@drescher:/srv/launchpad.net/ubuntu-archive/ubuntu$ du --max-depth 0
[04:08] <infinity> 206368248       .
[04:08] <infinity> That big.
[04:08] <infinity> And growing.
[04:08] <ivoks> thanks
[04:08] <jdong_> where's the emacs joke when you need it :(
[04:08] <infinity> I'd suggest 4x300GB drives in a 900GB RAID-5 would be the way to go.
[04:09] <infinity> Or, if you're pressed to options, 2x500 in a RAID-1 should give room for a while.
[04:09] <elmo> infinity: that's including non release architectures
[04:09] <infinity> s/to options/for options/
[04:09] <elmo> it's about 160GB without
[04:09] <infinity> elmo: Fair point, but we all love those arches, don't we? :)
[04:09] <ivoks> i was thinking about 320GB in RAID1
[04:10] <infinity> ivoks: Should be room for a while, as long as you're not mirroring a mess of other stuff too.
[04:10] <infinity> ivoks: I just always overpurchase, cause disk space goes really.. Fast.
[04:10] <ivoks> infinity: i'll leave it at this for a while
[04:10] <ivoks> infinity: later i'll buy new disks and new controler :/
[04:10] <infinity> And overpurchasing on disk is cheap these days anyway.
[04:11] <ivoks> it is
[04:12] <infinity> elmo: When slomo uploads 50 packages at once, I miss ross.  Can we either get it back, or remove slomo from the keyring?  I'm open to either option.
[04:12] <infinity> (Yes, I realise I can do the latter myself)
[04:13] <tseng> if you remove slomo I'll have to actually upload things
[04:13] <ivoks> :)
[04:13] <tseng> I'm against this
[04:13] <slomo> infinity: hm? you said it would be ok to upload now
[04:14] <infinity> slomo: Yes, I did, and it is.  I'm just being whiney. :)
[04:14] <elmo> infinity: znarl's moving powerpcs around now to get you ross back
[04:14] <Hobbsee> infinity: haha.
[04:14] <infinity> elmo: Oh, wow.  Many fluttering hearts for Znarl.
[04:14] <Hobbsee> infinity: if it's not him uploading things, it's me requesting syncs.  you cant win.
[04:15] <infinity> man, is there anything that ISN'T linked against dbus anymore?
[04:15] <infinity> *spit*
[04:16] <tseng> infinity: gnucash!
[04:16] <infinity> I'm just failing to understand why half this stuff cares about IPC in the first place.
[04:16] <tseng> years stuck at gtk+ 1.2, now its linked to dbus
[04:16] <slomo> infinity: in a few years dbus will be integrated in glibc ;)
[04:17] <tseng> infinity: alot of people use it simply to check for existing instances on startup
[04:17] <Riddell> Mithrandir, Kamion: kubuntu alternate CD i386 installs fine, although my apostrophy key seems to have become a forward tick/acute accent key
[04:17] <tseng> infinity: which is nice, but questionable if its worth the pain of current dbus
[04:17] <infinity> tseng: That's vile.
[04:17] <tseng> dbus is *almost* stable anyway
[04:17] <tseng> hopefully edgy+1 will not suffer such pains
[04:18] <slomo> infinity, tseng: apart from that libdbus is now guarantueed to be API/ABI stable for 1.0 (unfortunately not the bindings)
[04:18] <tseng> the bindings arent that widely used
[04:19] <infinity> tseng: I suspect that very few free software developers have done enough win32 development to learn from mistakes there, because it seems people used DDE as the same hammer for the same sort of nails on windows, and almost always with poor results in the end.
[04:19] <infinity> tseng: Oh well.  I'll get over it, I suppose.
[04:20] <Kamion> Riddell: I think there might be something wrong with kbd-choos4r
[04:20] <mvo_> Kamion: dists/edgy/dist-upgrader/binary-all/ is fine as  a path on the cdrom for me as well, whatever you prefer
[04:20] <Kamion> kbd-chooser
[04:20] <tseng> infinity: "to dbus people, everything seems like a dbus problem" -- Keybuk
[04:20] <ogra> Kamion, did i understand you right yesterday, there is no metapackage update needed for the minimal change ?
[04:20] <Kamion> ogra: not for you, no
[04:20] <ogra> s/minimal/-minimal/
[04:20] <ogra> good
[04:21] <Kamion> ubuntu-minimal needs to change, but there is no edubuntu-minimal
[04:21] <ogra> right, thats how i understood it
[04:21] <tseng> infinity: its the underpinnings of great leaps forward like hal, so I can't cry about it at night
[04:21] <ogra> its just that the update script still makes the change which is a bit irritating :)
[04:22] <Kamion> ogra: try setting 'output_seeds: desktop live' in update.cfg
[04:22] <ogra> ok
[04:22] <Kamion> and then rm minimal* standard*
[04:23] <ogra> oki
[04:26] <ogra> hmm
[04:27] <Keybuk> tseng: that wasn't a --Keybuk
[04:28] <tseng> Keybuk: pretty sure of it
[04:28] <tseng> Keybuk: unless you've borrowed it
[04:28] <Keybuk> tseng: I quote it, but the quote is Erik Troan
[04:28] <tseng> oh, rpath
[04:29] <Keybuk> when discussing upstart, he asked whether it was built using dbus
[04:29] <Keybuk> I had to admit that I had no plans to do that
[04:29] <Keybuk> which he considered a good thing
[04:29] <ogra> how would that work ?
[04:29] <tseng> ogra: dbus-activation
[04:29] <ogra> incorporating dbus code into init ?
[04:29] <Keybuk> ogra: init=/sbin/dbus
[04:29] <ogra> *shudder*
[04:29] <Keybuk> make it register everything as a service
[04:30] <Keybuk> to start/stop something, you'd send it a message
[04:30] <ogra> i thought you need to reboot if you change dbus services :P
[04:30] <tseng> only upgrading dbus
[04:30] <Keybuk> for this, and other nightmare scenarious, read Seth's/Fedora's "SystemServices" proposal
[04:34] <thom> Keybuk: ye gods fedora are actually talking about that?
[04:36] <infinity> thom: I't my experience (and I'm very grateful for it) that what Fedora contemplates and what they implement rarely relate.
[04:36] <Keybuk> thom: no, I think they've stopped
[04:37] <neuralis> Keybuk: who in the fedora camp has been discussing upstart with you?
[04:37] <Hobbsee> Keybuk: https://launchpad.net/bugs/57478 is done now, FYI.  i thought i'd approved that a while ago.  feel free to do it with the next round of syncs.
[04:37] <Ubugtu> Malone bug 57478 in lyx "Please sync xdg-utils and lyx-common from Debian" [Untriaged,Confirmed]
[04:39] <cbx33> hi guys
[04:40] <cbx33> got a scenario to run past you.  working on something in edubuntu that requires me to run a an app as a nother user, who is not root, this is a graphical app that needs to run in my current session, I can be root if necessary...gksudo doesn't work
[04:40] <cbx33> as the user doesn't have access to my xsession
[04:40] <cbx33> and I want to keep it that way
[04:40] <thom> Keybuk: that's pretty scary
[04:40] <cbx33> I tried sux.....which worked great....just not in an LTSP environment
[04:41] <cbx33> anyone got any better suggestions?
[04:41] <cbx33> the only one we came up with was sshkeys
[04:41] <cbx33> so i plant my public key in the users authoirsed keys
[04:41] <cbx33> and that way I can run
[04:41] <cbx33> ssh -X to the user@localhost
[04:41] <cbx33> can anyone see a better solution?
[04:42] <Mithrandir> Riddell: ok.  I guess you need new livefs-es and such and want to wait a little bit for the live one, though.
[04:43] <infinity> Mithrandir: The dbus qorld rebuild is still ongoing, and affect kubuntu as well.
[04:43] <Keybuk> neuralis: we haven't quite reached discussion yet
[04:43] <Mithrandir> cbx33: xhost +SI:localuser:$username ?
[04:43] <Riddell> Mithrandir: live was working too except for the issue I reported to kamion
[04:43] <Mithrandir> Riddell: and the dbus rebuild, I presume.
[04:43] <cbx33> Mithrandir, lemme try
[04:43] <Keybuk> neuralis: Bill Nottingham, Jeremy Katz, Jesse Keating, "Rahul" and "Harald" are in the Cc list
[04:44] <Riddell> Mithrandir: yes
[04:44] <cbx33> Mithrandir, it would be preferable for the user not to have access to my X session
[04:45] <Riddell> Kamion: how do I spot if the apt-setup fix is in?
[04:45] <cbx33> do you think that is the only way to go....?
[04:45] <Mithrandir> cbx33: well, you're really allowing the user access to your X session when you run an X based program as that user anyway.
[04:46] <cbx33> well true
[04:46] <infinity> cbx33: ssh -X is still allowing a user access to your session.
[04:46] <cbx33> so are you suggesting add it run the app, then when the app closes take it away again?
[04:46] <cbx33> infinity, again true
[04:46] <cbx33> is vuntz around?
[04:47] <Mithrandir> cbx33: yeah, that'd be useful.
[04:47] <infinity> cbx33: You'd need to sandbox the app completely (say, in a VNC session, or other such insanity) to prevent that.
[04:47] <cbx33> infinity, which is too much for this particular implementation
[04:47] <cbx33> it's pessulus you see
[04:47] <Mithrandir> cbx33: I guess one could implement a one-shot-cookie access control, but it wouldn't really help you much.
[04:48] <Mithrandir> infinity: Xnest (or at least Xephyr) would work by itself.
[04:48] <Mithrandir> (I'm less sure about Xnest than Xephyr, tbh)
[04:48] <infinity> Mithrandir: I think xnest is safe, yeah.  Not positive.
[04:48] <cbx33> basically it's for the Student Control Panel software
[04:48] <cbx33> i need to run pessulus as the user themself....
[04:48] <infinity> Mithrandir: I actually had "vnc or xnest" in my initial response, and backspaced over it cause I wasn't 100% sure. :)
[04:49] <cbx33> because that way it will edit their own settings
[04:49] <cbx33> if you get my meaning
[04:51] <Kamion> Riddell: look for the relevant versions of apt-setup or ubiquity in .list (alternate) or .manifest (desktop)
[04:53] <vuntz> cbx33: pong
[04:53] <cbx33> hi vuntz
[04:53] <cbx33> I'm currently implementing the Student Control Panel spec
[04:53] <cbx33> and pygi mentioned you wrote pessulus?
[04:53] <cbx33> which is on the list of things to implement :p
[04:54] <vuntz> yes
[04:54] <cbx33> well. if you are able to scroll up ^^
[04:54] <cbx33> I need to run pessulus as a specific user
[04:54] <cbx33> I wondered if you knew a way to do that
[04:55] <cbx33> I've been using sux to achieve it...but for edubuntu that doesn't work on LTSP
[04:55] <cbx33> any ideas?
[04:56] <ogra> well, actually you want to run pessulus and apply the lockdown of gconf keys to a specific user ;)
[04:56] <cbx33> well true
[04:57] <vuntz> cbx33: does the specific user have specific gconf sources?
[04:57] <ogra> there is probably a way where you dont need to run it as this user
[04:57] <ogra> vuntz, yes
[04:57] <vuntz> oh
[04:57] <cbx33> ogra, true....I was just saying what I had tried thus far
[04:57] <ogra> its a gnome multiuser setup
[04:57] <vuntz> ogra: didn't we already have this discussion?
[04:57] <ogra> dunno, did we ?
[04:57] <ogra> i know jdub discussed it in person with me in paris
[04:57] <cbx33> vuntz, did yo have a solution?
[04:57] <ogra> and he said there is an opportunity to do it
[04:58] <vuntz> iirc, I proposed to add a command line argument to pessulus to specify the gconf sources to use
[04:58] <cbx33> vuntz, how much work is that :p
[04:58] <vuntz> cbx33: shouldn't be too hard
[04:58] <vuntz> assuming you only want to change the mandatory source, it should be about 10 lines of python
[04:59] <cbx33> vuntz, possible before FF?
[04:59] <jdong_> so will edgy cd's start working soon?
[04:59] <cbx33> basically in SCP i have a context menu, so an admin can right clik on a username and hit lockdown
[04:59] <vuntz> cbx33: when is the freeze?
[04:59] <cbx33> which brings up pessulus for that user
[05:00] <cbx33> sep 9???
[05:00] <cbx33> am i right or wrong here?
[05:00] <ogra> 7
[05:00] <cbx33> 7th
[05:00] <vuntz> lots of time to do it, then :-)
[05:00] <cbx33> heheh
[05:00] <cbx33> is it something yo uhave time to do
[05:00] <cbx33> or do you want me to....try ?!
[05:01] <cbx33> and send you a patch?
[05:01] <vuntz> cbx33: you should really do it :-)
[05:01] <cbx33> oh joy
[05:01] <vuntz> look for GCONF_MANDATORY_SOURCE in pessulus
[05:01] <cbx33> vuntz, ok
[05:01] <vuntz> cbx33: replace it by a variable where it makes sense
[05:02] <vuntz> and adds some command line parsing magic in main.py
[05:02] <cbx33> ok
[05:02] <cbx33> what are you envisaging for the command line parameter?
[05:02] <vuntz> (if you could use GOption for the command line parsing, there's a bonus)
[05:02] <cbx33> the actual path of the source
[05:02] <cbx33> or the username ?
[05:02] <vuntz> cbx33: the path
[05:02] <cbx33> ok
[05:02] <cbx33> vuntz, bearing in mind I'm still a python n00b !
[05:03] <vuntz> cbx33: pessulus is good to learn :-)
[05:03] <cbx33> heheh
[05:03] <vuntz> (it was my first python project)
[05:03] <cbx33> hehe
[05:03] <cbx33> gISOMount was mine
[05:03] <cbx33> it's in edgy
[05:03] <cbx33> :D
[05:03] <vuntz> cbx33: feel free to ping me if you need some help
[05:04] <cbx33> thank you
[05:04] <cbx33> I'll take a look now
[05:04] <cbx33> I have about 2 hours
[05:05] <cbx33> do you have a devel branch somewhere?
[05:05] <cbx33> on LP?
[05:05] <vuntz> cbx33: GNOME cvs
[05:05] <cbx33> ah ok
[05:34] <ogra> wow, i managed to get edubuntu to 700MB on the spot ...
[05:36] <ogra> but installing dapper on a P133 with 64M is really no fun ...
[05:36] <dholbach> edgy will be better ;)
[05:36] <infinity> It will be?
[05:37] <infinity> Are we shipping edgy with extra RAM in the CD sleeve?
[05:37] <ogra> i managed to manually bootstrap it from the recue mode (instaler just dies if it needs to validate packages ) but now i cant install the kernel
[05:37] <dholbach> I'm trying to lift the morale :)
[05:37] <infinity> It's never been my experience that new versions of operating systems consumer fewew resources. :)
[05:38] <infinity> s/fewew/fewer/
[05:38] <Kamion> dapper can install in less RAM than breezy, actually
[05:38] <Kamion> but that's mostly just because I tweaked the lowmem limits. :)
[05:38] <infinity> (Well, not entirely true.  I found Linux 2.4->2.6 to actually increase in speed on older hardware, with similar configurations... But when you toss an upgraded desktop environment around that, you lost the benefit)
[05:38] <mvo> ogra: it would certainly help you would not run the install in a gnome-terminal ;)
[05:39] <Kamion> and of course that's only for the alternate CD
[05:39] <infinity> Yeah.
[05:39] <ogra> mvo, ah, right, you mean i shouldnt use the desktop CD ?
[05:39] <Kamion> ! don't use the desktop CD to install in 64M
[05:39] <bddebian> Howdy folks
[05:39] <mvo> ogra: exactly :P
[05:39] <ogra> Kamion, haha
[05:39] <janimo> ogra: this reminds me: what happened with the xfce edubuntu spec? No space on CD?
[05:39] <infinity> Kamion: Is smarenka still working on lowmem stuff in d-i during the etch cycle, or did he give up the fight after sarge released?
[05:39] <Kamion> the alternate CD should be able to handle down to 32M
[05:40] <ogra> Kamion, as if that woud even boot :)
[05:40] <ogra> *would
[05:40] <Kamion> infinity: don't know - I think he's done the odd bit, not sure
[05:40] <Keybuk> janimo: yeah, edubuntu *really* needs a third desktop environment on its CDs :p
[05:40] <ogra> janimo, i'm happy i just got them down to exactly 700M
[05:40] <ogra> Keybuk, well, there is a huge user demand for xfce in low end ltsp setups
[05:41] <infinity> ogra: Exactly, to the last byte?
[05:41] <janimo> Keybuk: it doesn't but deployment may really need on DE that allows them to server twice as many thin clients from the same server
[05:41] <infinity> ogra: Cause that'll surely explode on you after this publisher run, then.  No one can be that lucky. :)
[05:41] <ogra> i didnt look at the last byte yet ... cdimage shows 700
[05:41] <Keybuk> ogra: it strikes me that at some point, the effort of converting the existing KDE apps to be GTK+ apps may be worthwhile
[05:41] <ogra> Keybuk, thats in the works ;)
[05:42] <ogra> there is a team of edubuntu users rewriting kalzium ... which is the only reason to have kdeedu
[05:42] <janimo> ogra: you don't have kgeography or other kdeedu apps?
[05:42] <Kamion> you still have lots of other kde applications in the seeds
[05:43] <ogra> janimo, we have abut 5-10 kdeedu apps ...
[05:43] <ogra> but all of them would have gnome pendants or are easy to rewrite
[05:43] <ogra> apart from kalzium
[05:44] <Kamion> $ wget -q -O - http://people.ubuntu.com/~cjwatson/germinate-output/edubuntu-edgy/desktop | grep -c 'kdeedu.*desktop seed'
[05:44] <Kamion> 14
[05:44] <Chipzz> ogra: why rewrite them?
[05:44] <ogra> ok, let it be 14 ... still ...
[05:45] <ogra> Chipzz, do you have a better opportunity ?
[05:45] <Kamion> Chipzz: having to have the KDE libraries on the CD takes up a lot of space
[05:45] <Chipzz> ogra: given what I think of kde I have nothing against it
[05:45] <Chipzz> just seems like a lot of work?
[05:46] <ogra> Chipzz, gaiing 50-100M on the iso is worth it
[05:46] <ogra> *ganing
[05:46] <ogra> grmbl
[05:46] <Chipzz> yea I know what you meant ;)
[05:46] <ogra> heh :)
[05:46] <Chipzz> with the typo I mean ;)
[05:47] <Chipzz> what are they going to be rewritten in? pygtk?
[05:47] <ogra> my problem is that ubuntu fils up its own CDs to the limit ... i have to put stuff on top but dont want to cripple the desktop to much ...
[05:47] <Chipzz> Kamion: btw, my ssh issue from earlier disappeared when my uplink got less congested
[05:48] <ogra> the kalzium thingie is pygtk/cairo
[05:48] <janimo> dholbach: you know if bug-buddy is still active or apport replaces it completely?
[05:48] <Chipzz> ogra: finally having a decent gnome-office and not having to put up with openoffice would be a big improvement too I guess
[05:49] <ogra> Chipzz, oo.o would be the last thing i'd drop in a school environment
[05:49] <Chipzz> abiword and gnumeric are fine replacements IMHO
[05:49] <ogra> then i'd rather ask iwj for his desktop setup configs and go with fvwm
[05:49] <Chipzz> but that's a matter of taste I guess
[05:50] <ogra> its not about replacements or shiny apps ...
[05:50] <Chipzz> but I'm getting off-topic and keeping you from doing your job ;)
[05:50] <ogra> in schools we need to cope with free windows ...
[05:50] <ogra> well, my job is rather waiting for LP today ...
[05:51] <Chipzz> but getting into a pointless discussion with me is a waste of time too I guess ;)
[05:56] <slomo> infinity: stuff likes to FTBFS on !i386 now because of broken build-deps :(
[05:56] <infinity> slomo: I know.  Just bear with me.
[05:57] <infinity> slomo: I'll resolve it all in time.
[05:57] <sivang> spoken like a true god :p
[05:57] <slomo> infinity: thanks, you rock :)
[05:57] <ogra> what the heck does ndiswrapper do in powerpc ?
[05:57] <sivang> hi slomo
[05:57] <ogra> s/in/on/
[05:57] <infinity> ogra: Not much.
[05:58] <jdong> ha
[05:58] <ogra> well, it braks my ppc iso :)
[05:58] <slomo> Riddell: and kdegames FTBFS now because of "/usr/include/kde/kconfigbackend.h:256: error: 'KLocale' has not been declared". any idea what could've broken this lately?
[05:58] <ogra> *breaks
[05:58] <bluefoxicy> oh well time to reclaim memory.  Killing the most memory-intensive process running:    796 root      15   0  367m 156m 137m S  0.0 16.5   1:38.67 synaptic
[05:59] <mvo> bluefoxicy: *ick*
[05:59] <mvo> bluefoxicy: for how long is this runing?
[05:59] <bluefoxicy> mvo: 3 or 4 days
[05:59] <bluefoxicy> synaptic bloated more than Firefox, amusingly.
[05:59] <infinity> You had synaptic running for 4 days?
[05:59] <mvo> bluefoxicy: I blame memleaks in libapt
[05:59] <Riddell> slomo: hmm, my desktop-locale stuff could have but I doubt it
[05:59] <glatzor> slomo: hi. you have killed my music player: #58225
[05:59] <infinity> That's an odd use case.
[06:00] <bluefoxicy> 30147 bluefox   15   0  215m 117m  18m S  0.0 12.4  29:37.26 mozilla-thunder  <-- 5 days
[06:00] <Riddell> slomo: let me try a compile
[06:00] <mvo> bluefoxicy: but yeah, its pretty ugly and needs fixing
[06:00] <slomo> glatzor: cool... i'll take a look at it but it works fine here
[06:00] <bluefoxicy> infinity: I tend to leave it open and reload every so often when there's an obvious bug or when I'm waiting for an update.
[06:01] <bluefoxicy> in this case, I was waiting for pax-utils, which has finally hit universe.
[06:01] <glatzor> slomo: perhaps another powerpc only issue.
[06:02] <bluefoxicy> solar hasn't released another version; he's got some new features but he doesn't want to release them because they let the end user destroy shit badly
[06:04] <bluefoxicy> mvo:  how many apport's you got running?
[06:04] <bluefoxicy> or did you not install that?
[06:06] <ogra> oh, wow, dapper boots with 2.4.17
[06:06] <infinity> ONly on i386.
[06:06] <jdong> ogra: huh? udev?
[06:06] <ogra> right
[06:07] <infinity> On all other arches, glibc won't work with << 2.6
[06:07] <mvo> bluefoxicy: it is installed, but I doN't have one runing
[06:07] <ogra> jdong, i havent wiped the mbr yet ... :)
[06:07] <infinity> (Which will be true for i386 on edgy as well)
[06:07] <jdong> interesting
[06:07] <ogra> and was to slow to plug in the sbm floppie
[06:08] <Riddell> slomo: confirmed, it is my fault, Ill upload a new kdelibs to fix
[06:08] <Riddell> and Ill reupload kdegames
[06:08] <Riddell> Mithrandir ^^
[06:09] <slomo> Riddell: ok, thanks :)
[06:11] <slomo> hi sivang :)
[06:20] <bluefoxicy> mvo:  okay; I have 14 running.
[06:22] <geser> can someone explain me what the amd64 debs for cantlr and libantlr-dev are doing in http://archive.ubuntu.com/ubuntu/pool/universe/p/python-smbpasswd/ ?
[06:23] <geser> libantlr-dev for amd64 is also in http://archive.ubuntu.com/ubuntu/pool/main/p/python-smbpasswd/
[06:23] <mvo> bluefoxicy: pitti (when he is back) may be interessted to hear this
[06:23] <infinity> geser: Just hanging' out, I guess.
[06:23] <geser> the other packages from antlr are in the right directory
[06:23] <infinity> geser: (curious)
[06:24] <geser> these dirs are also in the packages file for amd64/egdy: Filename: pool/universe/p/python-smbpasswd/cantlr_2.7.6-6ubuntu1_amd64.deb
[06:24] <slomo> Mithrandir: libdbus-glib-1-dev is missing a replaces which breaks upgrades... are you fine with uploading?
[06:25] <infinity> geser: Yeah, the packages file just reports on the on-disk structure, so that makes sense.
[06:28] <dholbach> janimo: there are plans, but atm apport will do one part, bug-buddy the other
[06:29] <dholbach> janimo: s/atm/for edgy
[06:29] <janimo> dholbach: ok. I was wondering whether gnome_program_init is less useful but if b-b is still used then no
[06:30] <dholbach> I'm currently not quite sure about all the implications
[06:31] <infinity> geser: Team Soyuz is on it.  Thanks for the heads-up.
[06:54] <Simira> ogra: power manager messes up my system
[07:23] <Sp4rKy> hi
[07:24] <slomo> Mithrandir: libdbus-glib-1-dev is missing a replaces which breaks upgrades... are you fine with uploading?
[07:27] <infinity> Mithrandir: A kernel upload right now would make you very upset, right?
[07:31] <Keybuk> hmm, wow
[07:31] <Keybuk> whatever I'm doing is _really_ upsetting X
[07:31] <Simira> Mithrandir's out, back in two hours or so
[07:32] <Simira> Keybuk: couldn't be related to my desktop freezing and a lot of disc/swap activity?
[07:32] <Keybuk> Simira: not unless you're running upstart
[07:32] <Simira> not that I know of
[07:33] <jdub> in edgy boot process, upstart runs you!
[07:33] <Keybuk> it seems that I'm doing something to /dev/console that's making the running X server crash
[07:33] <Keybuk> which is quite clever
[07:33] <_ion> Hehe.
[07:34] <Keybuk> the trouble is, all I think I'm doing is "echo foo > /dev/console"
[07:34] <infinity> Simira: Care to phone or SMS him and ask if he'd kill BenC for uploading a new kernel? :)
[07:34] <bddebian> doko: ping?
[07:34] <BenC> infinity: this is sort of tricky...I mean it wouldn't be the end of the world if I don't upload
[07:35] <doko> bddebian: pong
[07:35] <Kamion> what are the changes?
[07:35] <BenC> Kamion: huge
[07:35] <Kamion> that doesn't sound immediately appealing
[07:35] <Keybuk> "That's the second-biggest Kernel Upload I've ever seen!"
[07:35] <BenC> the 686/k7 -> generic name changes
[07:35] <Kamion> eek
[07:35] <Kamion> that needs installer changes
[07:35] <bddebian> doko: Do you have any suggestions for azureus? It looks like you made some fairly significant changes.
[07:36] <BenC> my problem is that the kernel in Knot-1 isn't much different than what's in the archive right now
[07:36] <Kamion> and livefs build script changes I guess
[07:36] <BenC> so most ppl's problems wont be fixed from the last one
[07:36] <Kamion> is it possible to back out the intrusive packaging changes temporarily?
[07:36] <doko> bddebian: don't take the Debian package, please look at the fedora one. debian's is in contrib, so we cannot put it in main
[07:37] <BenC> Kamion: not really
[07:37] <infinity> Kamion: The livefs change is simple enough.
[07:37] <BenC> I have lrm, linux-meta and kernel source with this name change ready to upload
[07:37] <Kamion> all the consequent changes are simple enough, there are just quite a few of them and I'm not convinced I can remember them all
[07:38] <Kamion> and we'll have to basically rebuild everything from the ground up
[07:38] <BenC> well, lrm is almost ready, I have to remerge from infinity's uploads :)
[07:38] <bddebian> doko: Its not in main now
[07:38] <infinity> Kamion: We're still rebuilding the world for the dbus crap anyway.  My only concern here is the delay required to build the kernels.
[07:38] <BenC> when is knot-2 supposed to be released again?
[07:38] <doko> bddebian: sorry, universe; but contrib would be multiverse
[07:38] <Simira> infinity: sure
[07:38] <Keybuk> BenC: tomorrow
[07:39] <Kamion> yeah, but the world there wasn't supposed to include say debian-installer
[07:39] <bddebian> doko: Aye.  Hmm
[07:39] <BenC> ick, it would delay it to probably Friday night at best
[07:39] <infinity> BenC: Best to skip the kernel uploads, then?
[07:39] <Kamion> doko: we have discretion on that if the Debian package is contrib for reasons that don't apply to us
[07:40] <Kamion> e.g. dependencies that we've moved to main/universe
[07:40] <infinity> BenC: If you upload right after knot-2, that gives you a couple of weeks to iron out wrinkles and pray for a really solid kernel on knot-3. :)
[07:40] <Simira> infinity: he says go
[07:40] <BenC> probably best
[07:40] <infinity> Simira: Heh, and we seem to have just said "no". :)
[07:40] <Simira> just don't break anything
[07:40] <Simira> ;)
[07:40] <BenC> I'd hate to make this upload, and then something be broken that I didn't forsee, and end up delaying knot-2 for 3-4 days or something
[07:41] <Simira> BenC: if you can wait till after knot release, I am sure he'll appreciate
[07:41] <BenC> Simira: as usual, I can't guarantee non-breakage :)
[07:41] <Simira> BenC: what is it with you guys and breaking things...?
[07:41] <BenC> infinity: I don't suppose there's a way to have the kernel uploaded and staged somewhere is there?
[07:42] <jdub> Simira: EDGY!!!111
[07:42] <BenC> otherwise for the next two days I am going to feel the need to break^Wwork on it more
[07:42] <Kamion> BenC: dump it on chinstrap?
[07:43] <Kamion> then it can be uploaded right afterwards
[07:43] <BenC> Simira: the kernel's job is to find hardware bugs, which may, on occasion require us to implement non-standard code into the cpu/hardware in order to flush out these bugs
[07:43] <doko> Kamion: but it doesn't build using main/universe tools. and doesn't run using main/universe tools as provided in unstable
[07:43] <Kamion> doko: ok, then it's not so much that the Debian package is contrib, but that when built on Ubuntu that package has to be multiverse :-)
[07:43] <infinity> BenC: Yeah, just upload it to chinstrap (signed, even), and any one of us can plonk it on drescher when the release is out.
[07:44] <Kamion> doko: I thought you were saying that any package synced from Debian contrib had to stay in multiverse.
[07:44] <BenC> infinity: Ok, I'll have linux-source+lrm+linux-meta on there by the end of the day, and email you
[07:44] <BenC> thanks
[07:44] <infinity> BenC: Cool.
[07:45] <doko> Kamion: no, not the latter
[07:46] <doko> bddebian: if you do want to give it a try, let me know. the fedora patches are online as well.
[07:47] <bddebian> doko: Up to you.  I'm happy to try
[07:49] <jdub> (yay, fglrx works again)
[07:50] <Seveas> mjg59, you around?
[07:51] <Surak> BenC: ping
[07:51] <mjg59> Seveas: Hi
[07:52] <doko> bddebian: I'll send you some URL's tonight
[07:52] <Seveas> mjg59, will usplash on ppc do $something_better_than_640x400x16 for edgy
[07:54] <bddebian> doko: OK, thx
[07:54] <doko> away for the next hour
[07:54] <Seveas> I've ripped out run-length encoding and made pngtobogl do 256 color images, which works fine on 386 but ppc still uses bogl
[07:56] <mjg59> Seveas: If someone writes the code, sure
[07:56] <Seveas> mjg59, I would if I could but have no ppc to test
[07:56] <mjg59> Seveas: It ought to be trivial to make bogl write a 256 colour value to the framebuffer
[07:57] <Seveas> mjg59, but it'd still be 640x400, right?
[07:57] <mjg59> Seveas: That's just a matter of adding a modesetting call
[07:57] <mjg59> ppc has proper framebuffers
[07:57] <Seveas> right...
[07:58] <Seveas> anyway, I'll upload my branch to launchpad later today so you can merge at least this part
[07:58] <Seveas> (or the parts of it you like)
[07:59] <Kamion> you probably want to just use the mode the framebuffer starts up in
[07:59] <Kamion> I think that's generally reasonable
[07:59] <Kamion> at present the powerpc code in usplash deliberately centres the image on the screen
[07:59] <Kamion> (at least it did when I last wrote any of it)
[08:00] <Kamion> all you need to do is just use a bigger image instead
[08:00] <Seveas> sounds reasonable, but I don't want to touch the code with a 10-foot pole if I can't test it
[08:00] <Kamion> usplash is doing bogl_init() failed for me at present, so ...
[08:00] <Kamion> I assumed somebody broke it but haven't got round to figuring out why
[08:00] <Kamion> today IIRC it complained about /dev/fb0 not being there; could just be a module loading issue
[08:01] <Seveas> Kamion, you can test it while running (at least on x86) by running sudo usplash -c -- /dev/fb0 should be there post-boot
[08:07] <Kamion> true, but not while I'm in the middle of taking gparted apart. :)
[08:08] <Seveas> fair enough ;)
[08:14] <nanday> Sorry for barging in. I'm a Newsforge writer, researching a story. Would anyone be willing to comment publicly on the civility on Ubuntu's forums and Ubuntu's sense of direction compared to Debian's?
[08:15] <LaserJock> heh
[08:15] <Burgwork> LaserJock, hmm, nice can of worms
[08:15] <LaserJock> yep
[08:16] <mjg59> Seveas: We don't autoload framebuffer drivers now
[08:16] <mjg59> Oh, on ppc
[08:16] <mjg59> Right, sorry
[08:16] <dholbach> nanday: you can always try<EMAIL_ADDRESS>[08:16] <sbalneav> LaserJock: I installed the 25edubuntu-menus thing you pasted yesterday.  Worked like a charm.
[08:16] <Burgwork> dholbach, you want this to go to somebody official or should I cover it?
[08:17] <Burgwork> dholbach, also, nanday is in the same timezone as myself
[08:17] <LaserJock> sbalneav: excellent
[08:17] <dholbach> Burgwork: he wants somebody to comment s
[08:18] <nanday> Burgwork, the occasion is Matthew Garrett's resignation from Debian:
[08:18] <dholbach> Burgwork: he wants somebody to comment publicly, so I thought that somebody of the management would better do it
[08:18] <nanday> http://mjg59.livejournal.com/66647.html
[08:18] <Burgwork> dholbach, indeed. Light touch needed
[08:19] <Surak> hum. Bug #20943 and bug #55104 looks the same. And I confirmed the latter on every 2.6-based linux version I put my hands on
[08:19] <Ubugtu> Malone bug 20943 in linux-source-2.6.15 "module insertion hangs in apic/irq setup" [Medium,Confirmed]  http://launchpad.net/bugs/20943
[08:19] <Ubugtu> Malone bug 55104 in linux-source-2.6.15 "panic/lock/restart on dapper-amd64 if there's intel integrated video AND a nvidia card at the same time" [Untriaged,Confirmed]  http://launchpad.net/bugs/55104
[08:19] <nanday> if anyone does care to respond publicly, I can stress that it's not the official opinion of Ubuntu.
[08:20] <infinity> nanday: You may note that it's rather entertaining to discuss mjg59 in the third person when he's not only in this channel, but was actively participating 15 lines above.
[08:21] <nanday> infinity, yep.
[08:25] <Burgwork> nanday, basically, it boils down to I don't feel comfortable making any statements about those topics because I don't work for canonical. So you need to grab Mark/Jane/somebody else in Canonical's london office.
[08:26] <nanday> Burgwork, fair enough. I can hope, but I won't pry.
[08:26] <desrt> Burgwork; so have you thought any more?
[08:27] <Burgwork> desrt, sorry?
[08:27] <desrt> mentorship
[08:27] <tseng> nanday: I would like someone else to back this up, but I also don't believe that the "civility of the forums" is directly linked to ubuntu or canonical
[08:27] <desrt> tseng; word.
[08:27] <Burgwork> what sort of mentorship?
[08:27] <tseng> desrt: yo
[08:27] <desrt> Burgwork; the thing i blogged about
[08:27] <desrt> Burgwork; you said that you were the sort of person who could get the ball rolling on something :)
[08:27] <Burgwork> right, not had a chance to think about it
[08:28] <nanday> tseng, can you expand a little?
[08:28] <Burgwork> let me do that lunch today
[08:28] <desrt> just a friendly nudge :)
[08:28] <tseng> nanday: I think canonical might provide hosting, but it isnt run by Canonical
[08:28] <tseng> nanday: some forum leadership happens to be ubuntu members, not all
[08:29] <LaserJock> the forums have their own admins and moderators
[08:29] <tseng> nanday: its somewhat disconnected
[08:29] <tseng> nanday: (And definately has 0 connection to mjg59 leaving Debian)
[08:29] <LaserJock> but I think they still try to abide by the CoC
[08:29] <jdong_> LaserJock: the CoC is strictly enforced at the forums
[08:29] <Kamion> I think it depends whether you mean forums as in ubuntuforums.org or in the more general sense of places for Ubuntu discussion
[08:29] <Kamion> (including IRC and mailing lists)
[08:30] <LaserJock> ah, true
[08:30] <LaserJock> I would say though that the CoC is still the common denominator with pretty much all communication in Ubuntu
[08:30] <Kamion> most people answering seem to have assumed the former, but that's basically jargon
[08:30] <jdong_> is the forum to blame for the mjg59 situation or something?
[08:30] <tseng> its jargon with a specific meaning to most linux people
[08:30] <Kamion> jdong_: it's got nothing to do with it
[08:30] <jdong_> k, whew
[08:31] <Burgwork> jdong_, I don't know how the two questions are connected. nanday ?
[08:31] <Burgwork> nanday, generally I have found the forums to be very civil
[08:31] <jdong_> we try very hard to keep the forums civil
[08:31] <tseng> Burgwork: something to do with more civility in the forums having something to do with a departure from Debian
[08:32] <nanday> so, it's more or less a reaction to Debian?
[08:32] <Burgwork> tseng, ah, ubuntu is a more civil place in general? hmm, no idea
[08:32] <tseng> nanday: a personal decision by one person based on events in debian, clearly spelled out
[08:32] <dholbach> nanday: what do you mean?
[08:32] <tseng> nanday: the references to ubuntu was tangential
[08:33] <nanday> tseng, yes.
[08:33] <nanday> but he's not the only one to make a similar comparison.
[08:36] <tseng> nanday: it seems like jdong_ can point you to some ubuntuforums.org people if you did indeed mean 'those forums' and want to continue making such a connection
[08:36] <jdong_> I'm an admin at the forums, and I'd be glad to clarify any questions regarding the forums
[08:36] <jdong_> or put you in contact with someone who can
[08:36] <tseng> I personally don't see any news here.
[08:38] <nanday> jdong, I'd be interested in hearing if you take any particular steps to keep civililty. But maybe we should take this off the channel?
[08:38] <jdong_> nanday: what do you mean by keep civility?
[08:39] <jdong_> we have a large staff of moderators making sure users abide by the CoC
[08:39] <tseng> (Code of Conduct)
[08:39] <tseng> http://www.ubuntu.com/community/conduct
[08:39] <nanday> jdong, maybe the moderators and CoC explain it.
[08:39] <nanday> tseng, thanks.
[08:40] <tseng> officially regognized members are required to 'sign' this
[08:40] <jdong_> we do step in and take action when conversations start becoming rude or disrespectful
[08:40] <tseng> everyone else is expected to comply in good faith
[08:40] <tseng> and it mostly works, so far
[08:40] <jdong_> for the most part, people are very courteous even without our intervention
[08:40] <jdong_> but there are a handful that need us to remind them to be nice :)
[08:41] <nanday> ok, that helps to give me some perspective.
[08:41] <nanday> thanks for taking the time to talk.
[08:41] <jdong_> no problem
[08:41] <jdong_> stop by the forums or e-mail me at<EMAIL_ADDRESS>if you have any further questions
[08:41] <tseng> nanday: of most importance besides good faith "be nice"
[08:42] <tseng> nanday: note that technical matters are taken to the Tech Board for a discussion and ruling, as opposed to people duking it out on the mailing lists
[08:42] <tseng> (which still happens, sometimes)
[08:42] <Kamion> *ahem* zeroconf
[08:43] <nanday> tseng, good point.
[08:43] <tseng> community council is an escalation point for non-tech issues
[08:43] <Kamion> it takes a while to get to the techboard sometimes ;)
[08:43] <tseng> crucial points.
[08:43] <Kamion> but, shrug, you don't want to go to a committee straight away, it gets too bureaucratic
[08:43] <tseng> of course not, most things can be worked out civily
[08:44] <tseng> just not $shiny_apple_protocol
[08:44] <Mithrandir> Kamion: to be fair, the zeroconf disucssion, while lively and big was for the biggest part on-topic, civil and somewhat useful.  At least I think it didn't evolve into a flamewar.
[08:44] <tseng> Mithrandir: alot of repeition ad naseum, but it was certainly civil
[08:45] <tseng> same with mono / "zomg i only have 256mb ram"
[08:45] <Mithrandir> tseng: yeah, hence my "for the biggest part".
[08:45] <jdong_> Mithrandir: is there any plans to update opera in dapper-commercial?
[08:46] <jdong_> I was told you were the go-to guy on that
[08:47] <Mithrandir> jdong_: I uploaded the previous package.  I could always poke my contacts in opera and ask for an update.
[08:47] <nanday> thanks, everyone. Much appreciated. I'm off.
[08:48] <jdong_> Mithrandir: that'd be wonderful
[08:48] <jdong_> people have been bugging me about 9.01
[08:48] <jdong_> of course, I'm the one who gets bugged whenever something is out of date :(
[08:48] <Mithrandir> heh
[08:48] <jdong_> but this one is out of my domain :)
[08:48] <Mithrandir> jdong_: please drop me a mail about it so I don't forget.
[08:49] <jdong_> will do
[09:12] <sbalneav> Mithrandir: Are you one of the people on the X.Org swat team?
[09:12] <Mithrandir> sbalneav: depends. :-P
[09:12] <Mithrandir> sbalneav: any particular issue which is biting you?
[09:13] <sbalneav> There's a new series of thin client hardware coming out, that requires some patches to x.org.  What would the cutoff be to have them considered for inclusion?
[09:14] <zyga> did anyone notice the corrupted virtual console on ati hardware with current edgy kernel?
[09:14] <tseng> zyga: yes
[09:14] <zyga> tseng: oh, k
[09:14] <tseng> old nvidia too
[09:14] <tseng> 2/3 of my systems have it
[09:15] <zyga> cool effect, while irritating
[09:15] <zyga> ;-)
[09:15] <Mithrandir> sbalneav: hmm,  The earlier the better, naturally.
[09:16] <jammcq_laptop> Mithrandir: is there a hard cutoff ?
[09:16] <Mithrandir> sbalneav: new drivers or just patches to old ones?
[09:16] <Mithrandir> jammcq_laptop: "release" is fairly hard. :-P
[09:16] <tseng> jammcq_laptop: the hard cut off has come and gone
[09:16] <tseng> jammcq_laptop: there are always exceptions, with increasing difficulty
[09:16] <jdub> hey duderinos
[09:16] <tseng> hello jdub
[09:17] <Mithrandir> sbalneav: it should be quite doable to get it in if you have it by betafreeze.
[09:17] <sbalneav> That's by second week of Sepember?
[09:18] <sbalneav> err September?
[09:18] <Mithrandir> betafreeze is Sep 21st.
[09:18] <sbalneav> Perfect!
[09:18] <sbalneav> You, sir, deserve a beer.
[09:18] <Mithrandir> sbalneav: though, you probably rather want to talk to rodarvus, he's the X driver guy.  I generally rather touch libs and apps and other crazy !server stuff.
[09:19] <Mithrandir> mm, beer.
[09:19] <sbalneav> Ah, rodarvus! Perfect!
[09:19] <sbalneav> Thanks muchly
[09:19] <jammcq_laptop> Mithrandir: is the 'Unichrome' driver part of edgy's Xorg ?
[09:19] <jammcq_laptop> or maybe it's a Unichrome patch to the 'via' driver
[09:19] <Mithrandir> jammcq_laptop: UTSL; I'm not familiar with the via driver at all.
[09:20] <jammcq_laptop> k
[09:20] <rodarvus> sbalneav, hi :)
[09:20] <jammcq_laptop> we'll bug rodarvus about it
[09:20] <jammcq_laptop> tanks for your help
[09:20] <rodarvus> sure, just hand me the patch(es) and I'll take a look at it(them)
[09:20] <sbalneav> hey rodarvus!
[09:20] <sbalneav> Yep, you'll be hearing from us! :)
[09:20] <rodarvus> good! :)
[09:21] <jammcq_laptop> rodarvus: it'll prolly take me a week or 2 to get it all figured out, to send something to you
[09:22] <rodarvus> jammcq_laptop, sure, no problem.
[09:23] <rodarvus> jammcq_laptop, afaik, the unichrome stuff is part of the via driver, yes
[09:23] <jammcq_laptop> rodarvus: it is entirely possible that the version of Xorg in edgy already works with this thin client.  I'll dig into that soon
[09:23] <rodarvus> (but I might be wrong)
[09:25] <rodarvus> just for reference, I don't think the via driver has changed *so much* since dapper (even upstream -> http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-via.git;a=summary)
[09:25] <rodarvus> we have version 0.2.1, without any extra patches
[10:08] <bluefoxicy> Is anyone interested in compressed memory?
[10:08] <bluefoxicy> i.e. memory pressure compresses stuff, then extra memory pressure sends it to swap, possibly avoiding some I/O (the CPU-bound problem is shorter than the I/O-bound problem)
[10:10] <jdong_> bluefoxicy: how on earth do you compress RAM
[10:10] <bluefoxicy> Nitan's 2.6 patch is almost ready but he thinks it's too much work to get it into mainline; I've recommended he get it working and do some performance measurements and then try to convince a major distribution to use it as backing to convince mainline to take it
[10:10] <mjg59> bluefoxicy: It's being looked at for OLPC
[10:11] <jdong_> that would be a cool concept
[10:11] <bluefoxicy> jdong_: when memory pressure is heavy normally pages are sent to swap.  This involves a few bits of disk access, seeking back and forth, writing data; then later some seeking and reading again to get it back.
[10:11] <jdong_> right
[10:11] <bluefoxicy> the compressed memory project takes the pages going to swap and compresses them
[10:11] <mjg59> bluefoxicy: Of course, while it avoids writes to swap, it also reduces the size of available RAM
[10:12] <bluefoxicy> when memory pressure gets tighter, it pushes those pages out to swap
[10:12] <jdong_> oh, I see
[10:12] <mjg59> So you end up compressing more stuff than you would otherwise have pushed out to disk
[10:12] <bluefoxicy> mjg59:  of course, there is an effective limit and also memory access patterns affect it.
[10:12] <mjg59> I can imagine it being a win under some workloads and a loss under others
[10:12] <mjg59> But I would certainly be interested in the effect it would have on swapless systems
[10:13] <bluefoxicy> mjg59: you compress least recently used memory; in many cases this memory goes to disk and stays there for a long time.  If you have a gig of ram, you may push 400 megs to swap, have 300 megs of disk cache.
[10:13] <mjg59> Where it would be preferable to push some running code out to compressed storage in order to keep more cache
[10:13] <mjg59> bluefoxicy: LRU memory or LRU working set?
[10:13] <mjg59> bluefoxicy: IE, does it discard caches before compressing anything?
[10:13] <bluefoxicy> You may find that over the course of days, you have 700 megs of working set in RAM and 400 megs on swap, and the 400 megs for the most part stays there.
[10:14] <bluefoxicy> mjg59:  I'm not sure.  There is a lot of research behind it, Nitan is at least the third person in line
[10:14] <bluefoxicy> Rodrigo was the second (it was his master's dissertation); and he got the idea from Wilson and Kaplan, who also did it for their Ph.D. dissertaitions IIRC
[10:14] <mjg59> I can certainly see "discarding" some running apps in favour of cache as being advantageous for the live cd, for instance
[10:14] <bluefoxicy> mjg59:  yes, it'd be great for the livecd
[10:15] <zyga> re
[10:15] <mjg59> bluefoxicy: It's going to be too late for edgy, but do encourage him to bring it up on -devel
[10:15] <zyga> I don't think it's safe to turn it on by default without lots of testing
[10:15] <zyga> hello lucas
[10:16] <lucas> hello zyga
[10:16] <zyga> mvo_: do you agree?
[10:16] <mjg59> Playing with it early in the edgy+1 cycle (perhaps at one of the developer conferences) would be good
[10:16] <bluefoxicy> mjg59:  it's going to be late for edgy definitely; but I don't want to see the work die again.
[10:16] <mjg59> We can easily produce two CD images, one with this and one without
[10:16] <bluefoxicy> Rodrigo did it in 2.4.19 and it never went in, even though it worked rather well.
[10:16] <mjg59> And then see how they perform on different machines
[10:16] <bluefoxicy> two CDs are not needed.
[10:16] <bluefoxicy> Nitan took a different route from Castro; he's made a kernel module.
[10:17] <mvo_> zyga: we could try to raise more interesst in it, my latest bash upload should make it a matter of "apt-get install command-not-found" to activate it
[10:17] <bluefoxicy> "Compression structure (as desc. later in this page) has been implemented as separate kernel module (and also merged with main compressed caching code)."
[10:17] <zyga> mvo_: it's on by default after installing?
[10:17] <mvo_> zyga: maybe someone could blog about it? this seems to be the best way to raise interesst these days
[10:17] <mvo_> zyga: yes
[10:18] <zyga> mvo_: maybe someone on planet.ubuntu?
[10:18] <zyga> how about you? :)
[10:18] <bluefoxicy> mjg59:  you can use a boot time option to load/not load the module when it comes to it :)
[10:18] <zyga> I lost my blog a few days ago after forgetting to backup /var/lib before format :/
[10:18] <mvo_> zyga: yes
[10:18] <mvo_> zyga: eh ...
[10:18] <mvo_> zyga: I don't habe a blog
[10:18] <mvo_> zyga: maybe dholbach
[10:18] <slomo> infinity: some give-backs for you :) gnome-applets (ppc) and evolution-exchange (!i386) for now
[10:18] <thom> mvo_: searching Contents files for apt autocompletion?
[10:19] <mjg59> bluefoxicy: Ok, makes life even easier
[10:19] <zyga> dholbach: would you? do you think it's a good idea?
[10:19] <bluefoxicy> http://linuxcompressed.sourceforge.net/linux24-cc/statistics/index.html  Here's the old stats on the 2.4 patch
[10:19] <mvo_> thom: if a command in bash is not found, it will do a db search for binaries that might be available but are not installed. but it will not install anything automatically :)
[10:19] <bluefoxicy> Rodrigo let Nitan have http://linuxcompressed.sourceforge.net/ too
[10:19] <dholbach> zyga: i can't update planet, just a sec
[10:20] <dholbach> zyga: https://wiki.ubuntu.com/PlanetUbuntu
[10:20] <zyga> dholbach: oh, you can just be a member these days!
[10:20] <zyga> cool
[10:20] <zyga> I'll look into it, thanks
[10:21] <thom> mvo_: ah. auto-apt, the revenge?
[10:23] <zyga> thom, interesting - was auto apt fast?
[10:23] <bluefoxicy> mjg59:  eyeballing some of the stats, looking at http://linuxcompressed.sourceforge.net/linux24-cc/statistics/0.24pre6_kernel/ and http://linuxcompressed.sourceforge.net/linux24-cc/statistics/0.24pre6_mummer/
[10:24] <bluefoxicy> mjg59:  I know kernel compilation takes very little memory (as in a few tens, not 500 megs); it looks like as memory gets tighter the benefits are more and more substantial, while when memory is ample the cost/benefit ratio is almost 1:1 (you don't gain, but you don't lose either)
[10:25] <thom> zyga: i can't honestly say i ever got auto-apt to play ball
[10:25] <thom> i didn't try very hard, mind :-)
[10:25] <zyga> thom: try cnf from time to time, it's handy IMO
[10:25] <thom> zyga: i'd have to use bash then ;-)
[10:25] <bluefoxicy> as they do more parallel builds (-j2 and -j4) memory requirements go up and the cost/benefit stays higher for higher amounts of memory.  The second one (MUMmer scientific application) needs a LOT of memory and has a high benefit even with hundreds of megs of memory.
[10:26] <thom> might see if i can find the spare time to hook up zsh
[10:26] <zyga> thom: true, what do you use?
[10:26] <zyga> that was my other question
[10:26] <zyga> can zsh be hooked up easily?
[10:26] <thom> i'd imagine so
[10:26] <bluefoxicy> mjg59:  I'll send something to -devel later tonight with conjecture of impact based on the old benchmarks.
[10:26] <mvo__> thom: I would be happy to have patches for zsh :)
[10:27] <thom> we'll see :-)
[10:27] <zyga> dholbach: hmm, my pubkey was denied any ideas? I have my key in launchpad so I don't have any
[10:28] <dholbach> zyga: no idea at all
[10:30] <Simira> dholbach: I have reserved a Danish-Swedish farm-dog (? it's called something like that), born August 19th.
[10:31] <dholbach> wow!
[10:31] <dholbach> when do you get it?
[10:31] <thom> mvo__: on the random hacking states https for apt is rather higher on the priority list :-)
[10:31] <Simira> dholbach: the one with light brown on the lowest middle pic is the mother: http://www.rdsg.no/Bilde14.htm
[10:31] <Simira> dholbach: about Oct 13th
[10:31] <mvo__> thom: agreed
[10:32] <dholbach> Simira: nice :-)
[10:32] <thom> should this kernel happen to work i can actually spend some time on that
[10:32] <Simira> dholbach: not it. Him. The mother's name is Lilo, Tollef wants to call him Grub :p
[10:32] <dholbach> haha
[10:32] <Mithrandir> og silo og isolinux or maybe pxe?
[10:32] <Simira> s/og/or
[10:33] <Mithrandir> I can't type, you know that.
[10:33] <Simira> I'm not convinced
[10:33] <Simira> about the names
[10:33] <thom> just use pwgen and stick with tradition :P
[10:33] <Simira> no way
[10:34] <Mithrandir> thom: I think she'd kill me if I did that.
[10:34] <Mithrandir> or throw me out or something.
[10:34] <thom> the _dog_ won't know :-)
[10:35] <Simira> thom: I will know
[10:35] <dholbach> have a nice evening
[10:35] <Mithrandir> thom: well, I have to live with Karianne, so I better stick with something she can live with.  And it'll be her dog, not mine.  Especially on the days when it's hailing, etc.
[10:35] <Simira> good night, dholbach
[10:35] <dholbach> bye Simira
[10:35] <thom> *g*
[10:36] <thom> night daniel!
[10:36] <Mithrandir> good night, dholbach
[10:36] <OddAbe19> is the "gnome-panel using 100 cpu" bug fixed yet?
[10:36] <dholbach> bye Thom, bye Tollef
[10:44] <OddAbe19> is the "gnome-panel using 100 cpu" bug fixed yet?
[10:45] <thom> please don't repeat questions
[11:30] <ogra> Keybuk, what was the driver you used for the PCI wlan card we bought ?
[11:30] <ogra> (i dont even see it in lspci here)
[11:33] <lifeless> BenC: ping
[11:33] <BenC> lifeless: pong
[11:33] <lifeless> hi
[11:34] <lifeless> I'm going to skip my little tale of trauma from last night, and just ask - can we please get dm-bbr support put back into the dapper kernels ?
[11:34] <lifeless> I dont know when it went away, but its lack is rather unfortunate - for me at least
[11:35] <jdong|coreduo> lifeless: +1
[11:35] <lifeless> in other news, building a custom tweaked kernel was hugely painless [except for my laptop being too puny] , so thanks heaps for everything done there
[11:35] <sharms> mako: ping
[11:35] <lifeless> jdong|coreduo: well it was in before dapper
[11:36] <Burgwork> sharms, *laugh*. Good luck. Probably easier to mail him
[11:36] <BenC> lifeless: dm-bbr?
[11:36] <jdong|coreduo> lifeless: right; it disappeared at dapper....
[11:36] <lifeless> jdong|coreduo: so it had to come out at some point. I know it was in because I setup my evms config *with* dm-bbr during the beta period
[11:36] <jdong|coreduo> BenC: device-mapper's bad block relocator
[11:36] <lifeless> BenC: do an apt-get source evms
[11:36] <BenC> was that an external patch?
[11:36] <jdong|coreduo> BenC: it's a part of evms
[11:36] <lifeless> BenC: look in kernel/2.6/
[11:36] <jdong|coreduo> at least upstream evms :-/
[11:36] <lifeless> jdong|coreduo: its in the dapper evms package
[11:37] <lifeless> BenC: yes, its an external patch.
[11:37] <jdong|coreduo> BenC: it's pretty important since nowadays filesystem devs aren't thinking bad blocks are their problem anymore
[11:37] <lifeless> in fact, as a module, evms could supply the thing
[11:37] <jdong|coreduo> lifeless: I don't think the kernel module system ubuntu uses works that way
[11:37] <jdong|coreduo> but then again, BenC is the expert on that
[11:38] <BenC> lifeless: it would have to have one for each kernel flavour
[11:39] <lifeless> BenC: well, what ever is easiest for you. For me - I have a disk partition config here that needs it, which I built using dapper's betas.
[11:39] <jdong|coreduo> BenC: I got some bad hard drives I'd like to use again :)
[11:39] <lifeless> so, if we can get it into dapper updates, it will save me a world of pain
[11:39] <lifeless> and it sounds like jdong|coreduo wishes for it too
[11:39] <jdong|coreduo> :)
[11:39] <BenC> patch applied cleanly
[11:40] <BenC> I guess I can add it in with dapper since it doesn't touch any other code
[11:40] <jdong|coreduo> wow, today's a REALLY good day
[11:40] <jdong|coreduo> and it's not just the vicodin that makes me say that
[11:40] <lifeless> BenC: I built a kernel image with it myself last night, as a module, and it let me boot without error [well, it wasn't in the initramfs, but that I know how to fix]
[11:40] <lifeless> BenC: thank you !very! much
[11:41] <jdong|coreduo> grr, gedit-dev...... gedit_-dev_? what the hell is gedit-dev....
[11:41] <LaserJock> what's the default python version in Edgy? still 2.4?
[11:42] <Chipzz> LaserJock: "still"?
[11:42] <Chipzz> hrrrm
[11:42] <Chipzz> wait
[11:42] <jdong|coreduo> LaserJock: umm, isn't 2.4 still the latest version?
[11:42] <Chipzz> nm
[11:42] <lifeless> BenC: while you are there, can you see if the other evms patch is applied ?
[11:42] <LaserJock> 2.5beta is in edgy
[11:42] <lifeless> BenC: I ask because Mithrandir thought we definately have it, but its strange to have only have the patches from a package
[11:43] <sivang> how dangerous will it be to install upstart and replace my init system?
[11:43] <jdong|coreduo> sivang: it slots, so it should be safe :)
[11:43] <jdong|coreduo> sivang: you need an init= kernel argument to invoke it
[11:43] <jdong|coreduo> sivang: README.Debian time? :)
[11:44] <sivang> jdong|coreduo: probably, but I wanted to know before installing the package from univers , fearing it will just replace stuff :-)
[11:44] <jdong|coreduo> installing it appears quite harmless
[11:44] <sivang> jdong|coreduo: what do you mean it "slots" ? (please excuse my non en nativeness)
[11:45] <zyga> does anyone know how to make a nice hackergothi?
[11:45] <jdong|coreduo> it installs things alongside what's in your system already
[11:45] <jdong|coreduo> as opposed to replacing
[11:46] <jdong|coreduo> sivang: i.e. python2.4 "slots" python2.3; gaim 2.0beta in Edgy "replaces" gaim 1.5.x in Dapper
[11:46] <jdong|coreduo> sivang: it's more of a gentoo term than an english slang thing :)
[11:47] <zyga> sivang: I'll give upstart a try too
[11:47] <sivang> jdong|coreduo: you can never know what terms you will learn on ubuntu-devel ;-)
[11:47] <jdong|coreduo> :)
[11:47] <sivang> zyga: cool
[11:48] <zyga> sivang: I'll reboot now
[11:48] <zyga> mvo: night!
[11:51] <lifeless> is modules still the right way to ensure a device is loaded into the initramfs ?
[11:55] <zyga> well I'm still alive ;-)
[11:56] <zyga> Keybuk: do you write upstart?
[12:05] <zyga> upstart runs quite nice