[12:07] <Kamion> Riddell: Kubuntu install CDs up
[12:12] <Riddell> Kamion: thanks
[12:13] <Kamion> http://king.buildd/%7Ebuildd/livecd/kubuntu/current/livecd.kubuntu.cloop:
[12:13] <Kamion> 23:11:21 ERROR 403: Forbidden.
[12:13] <Kamion> meh
[12:13] <Kamion> lamont: please fix? all buildds I think
[12:14] <Kamion> lamont: ah, the problem is that the cloop didn't build, due to this, which is still your bug :-)
[12:14] <Kamion> E: Couldn't find package kubuntu-base
[12:15] <Kamion> lamont: both Kubuntu and Edubuntu should use ubuntu-base
[12:15] <Kamion> infinity: or you, if you're around?
[12:20] <lamont> Kamion: hrm...
[12:20] <lamont> Kamion: while I'm doing that - do you know how to run javascript crap in a manner that gets me error messages when I have syntax errors?
[12:21] <mdz> lamont: tools->javascript console in firefox
[12:21] <lamont> woot
[12:21] <lamont> Kamion: ISTR kubuntu-base got created in breezy, yes?
[12:21] <neuralis> lamont, for more serious stuff, download venkman
[12:21] <neuralis> lamont, full javascript debugger in xul.
[12:22] <xhaker> anyone holding packages for firefox1.5 rc's somewhere?
[12:23] <lamont> sadly, that doesn't show me the errors in my proxy.pac file...
[12:25] <Kamion> lamont: AFAIK there was never a kubuntu-base
[12:25] <Kamion> lamont: for good reason - it isn't possible to make netboot installs work properly if Kubuntu's or Edubuntu's base system is ever at variance from Ubuntu's
[12:26] <Kamion> at least not at present
[12:26] <lamont>             LIST="$LIST ubuntu-base ubuntu-desktop ubuntu-live"
[12:26] <lamont>             LIST="$LIST ubuntu-base kubuntu-desktop kubuntu-live"
[12:26] <lamont>             LIST="$LIST ubuntu-base edubuntu-desktop edubuntu-live"
[12:26] <Kamion> great, that's correct
[12:26] <lamont> you are go for launching your builds
[12:26] <Kamion> launched
[12:26] <Kamion> thanks for the quick fix
[12:26] <lamont> now tell me how to find proxy.pac syntax errors. :-)
[12:27] <Kamion> on that, I'm afraid, I am clueless :(
[12:27] <lamont> well, I still need to go really fix the source, etc.
[12:27] <lamont> Kamion: ditto
[12:28] <lamont> neuralis: E: Couldn't find package venkman
[12:28] <Kamion> mozilla-venkman |   0.9.85-3 | dapper/universe | all
[12:28] <Kamion> (back to hoary/universe)
[12:28] <neuralis> lamont, look harder :P
[12:28] <lamont> danke
[12:30] <lamont> neuralis: and this lets me examine the .pac file how?
[12:31] <neuralis> lamont, you didn't specify proxy.pac as part of your problem until later. venkman lets you "run javascript crap in a manner that" gives you full debug control.
[12:31] <lamont> ok.
[12:31] <lamont> how does it let me do that?
[12:32] <lamont> Kamion: fix committed, it'll be in 0.25 for real.
[12:33] <neuralis> after starting it up, it will show javascript loaded across all firefox windows, and allow you to place breakpoints or enable full-tracing and such. i'm not sure it'll help with proxy.pac.
[12:36] <Riddell> elmo: please sync smb4k from debian, ok to override ubuntu changes
[12:38] <elmo> Riddell: queued
[12:38] <Kamion> mdz: I reckon the Flight 1 announcement should go to ubuntu-devel-announce these days. Should it go to ubuntu-users too?
[12:39] <lamont> neuralis: how do I print something in javascript?
[12:39] <neuralis> there's nowhere to print to, generally. alert('message') will do a pop-up.
[12:40] <mdz> Kamion: sure
[12:40] <mdz> Kamion: perhaps with a note to subscribe to -devel-announce for the future
[12:41] <Kamion> good plan
[12:45] <lamont> grumble.  myIpAddress() returned 127.0.0.1
[12:46] <Kamion> amd64/server pass
[12:48] <lamont> The autoconfig file can be output by a CGI script. This is useful e.g. when making the autoconfig file act differently based on the client IP address (the REMOTE_ADDR environment variable in CGI).
[12:48] <lamont> but I don't _WANT_ to write CGI
[01:13] <Kamion> Riddell: just a procedural note re http://lists.ubuntu.com/archives/kubuntu-devel/2005-November/000554.html - it's not called flight-1 until it's released
[01:16] <Kamion> amd64/install pass
[01:17] <Riddell> Kamion: good point, noted
[01:20] <Kamion> Riddell: things are looking good on the Ubuntu side; I've written the release announcement, although I probably won't actually do the release until tomorrow morning now. If you've got basic testing done on all the CDs by then, let me know and I'll release Kubuntu Flight 1 along with it; otherwise I can do it shortly afterwards.
[01:20] <Kamion> you don't have to test quite as thoroughly as for preview/RC/final - just basic validation that the image can perform an install or boot to a live session as appropriate will be fine
[01:22] <Kamion> I'm afraid my release announcement errs on the duck side of the debate contrary to my personal preference, but only because I found the perfect quote ;)
[01:23] <Riddell> Kamion: I don't have anyone to test the ppc disk but otherwise they should all be tested by morning
[01:23] <ogra> Riddell, i can test ppc live 
[01:23] <Kamion> ok, I'll download ppc install and see if I can give it a go tomorrow morning
[01:23] <Kamion> thanks ogra
[01:24] <Riddell> ooh, live CDs are up
[01:24] <Riddell> ogra: http://cdimage.ubuntu.com/cdimage/kubuntu/daily-live/20051119/  thanks
[01:24] <ogra> i'll try rsyncing a ubuntu live :)
[01:24] <Kamion> ah, yes
[01:25] <Kamion> ogra: that will help a bit, probably, but not a lot
[01:25] <ogra> a bit is fine ...
[01:25] <ogra> at least more than nothing ;)
[01:28] <ogra> meh
[01:28] <ogra> dapper-live-powerpc.OVERSIZED
[01:28] <ogra> Riddell, ^^ drop some languages :)
[01:28] <Kamion> says the man whose project has a special exception in cdimage code to let it be larger ...
[01:28] <ogra> lol
[01:29] <Kamion> kubuntu/powerpc/live is only 3MB over; no great concern for now
[01:45] <ajmitch> ogra: what, drop .de?
[01:46] <ogra> heh... i'm fine with .en :)
[01:46] <ajmitch> noone uses it :)
[01:46] <Kamion> Kubuntu ships a *lot* of languages; dropping a couple would not be a problem, and we wouldn't have to go anywhere near the most popular ones
[01:46] <Kamion> this sort of optimisation may be best done later though
[01:46] <Kamion> well, s/optimisation/tweaking/
[01:48] <Kamion>  * Languages: af am as az be bg br bs ca cs cy da el eo et eu fa fi ga gl gu he hr hu ia id
[01:48] <Kamion>  ^-- list of languages hipped on kubuntu/powerpc/install outside the most popular dozen
[01:49] <Kamion> er, "shipped"
[01:49] <mpt> that should cut down on plenty of space :-)
[01:50] <Kamion> sounds like a good way to ship only one language ;)
[01:50] <ogra> if they are not complete, they might not take much space :)
[01:50] <Kamion> now is a bad time to try to execute that metric, though
[01:50] <Kamion> and, as ogra says, incomplete ones are cheap
[01:50] <mpt> if Microsoft or Apple shipped with incomplete translations, they'd get tomatoes thrown at them, wouldn't they?
[01:50] <ogra> nope
[01:51] <ogra> Apple probably ...
[01:52] <Kamion> it depends how you define "complete". our archive contains a hell of a lot more software than either Microsoft or Apple ship; even if you go by what we ship, we have an awful lot of translation domains
[01:53] <Kamion> it's hard to compare because Microsoft and Apple don't have the same kind of huge archive of stuff you can grab after the install
[01:53] <mpt> and we don't measure CD-completeness separately?
[01:53] <Kamion> we don't measure it at all yet
[01:54] <mpt> Rosetta measures completeness at all
[01:54] <Kamion> ok, I didn't know how good its measurements were, but I'm pretty sure it doesn't measure CD-completeness
[01:55] <Kamion> in any case I can tell you for free that only one language other than English was even at 100% in the breezy installer
[01:55] <ogra> french ? 
[01:55] <Kamion> many were very close, but IIRC only French actually made it
[01:55] <mpt> :-(
[01:56] <mpt> Will Dapper's earlier feature freeze mean more time for translation?
[01:56] <Kamion> hahahahahaha
[01:56] <Kamion> I wish
[01:56] <ogra> *g*
[01:56] <Kamion> in any case I don't think more time would have helped; we need better advertisement of what order one should translate things in
[01:57] <Kamion> I've been discussing installer translations with Carlos
[01:57] <Kamion> we have a plan which should help
[01:57] <Kamion> anyway, bed :)
[01:57] <ajmitch> a lot of random stuff in universe got translated?
[01:57] <ajmitch> night Kamion 
[01:57] <mpt> we have a bug reported on that
[01:57] <ogra> night Kamion 
[01:57] <mpt> show which stuff is important first
[01:57] <mpt> g'night Kamion 
[01:58] <mpt> https://launchpad.net/products/rosetta/+bug/20
[03:04] <sistpoty> elmo: please sync nvclock from unstable, ok to override ubuntu changes
[03:50] <sistpoty> elmo: please sync rafkill from unstable, ok to override ubuntu changes
[04:02] <Kinnison> g/night all
[04:03] <powerj> Hello fellows!
[04:03] <powerj> Anyone around.
[04:03] <powerj> ??
[04:04] <powerj> Anyone awake?
[04:09] <crimsun> elmo: please sync vile and tse3 from Sid, overriding Ubuntu changes, thanks
[04:09] <elmo> is flight1 out yet?
[04:09] <ogra> elmo, its done, but not out yet
[04:09] <powerj> I woud like some gentoo devs opinions about some new software i wrote.. Anyone around?
[04:09] <ogra> Kamion wanted to announce it tomorrow morning
[04:10] <elmo> powerj: wrong channel
[04:10] <zul> very wrong channel
[04:10] <powerj> elmo, is it not here you find the ubuntu devel staff?
[04:11] <elmo> crimsun: queued
[04:11] <crimsun> elmo: thank you.
[04:11] <crimsun> powerj: you mistyped "gentoo"
[04:12] <powerj> Oh, sorry i was thinking ubuntu..
[04:13] <powerj> I am writing an replacement for sysvinit, that boots the system in parraler, and heavy reduces boot time.
[04:13] <powerj> Maby you devs, can tell me a feature list you want to have in a sutch system.
[04:13] <powerj> Things that i missed.
[04:14] <powerj> Have a look: http://initng.thinktux.net/
[04:15] <crimsun> issue has been raised in the channel previously and on the mailing lists
[04:16] <powerj> Ok?
[04:16] <crimsun> just letting you know it has been raised. Timeframe is not within Dapper.
[04:19] <powerj> crimsun, do you have any url to the debate on the mailinglist, or an irc log?
[04:20] <crimsun> powerj: http://people.ubuntu.com/~fabbione/irclogs/  and lists.ubuntu.com
[04:21] <crimsun> sorry I don't have them handy
[04:23] <mpt> powerj, http://lists.ubuntu.com/archives/ubuntu-devel/2005-May/thread.html#7410 is one
[04:27] <powerj> mpt, thanks, but these mails are back from may, anything fresh?
[04:28] <mpt> powerj, see http://lists.ubuntu.com/archives/ubuntu-devel/2005-November/013072.html w.r.t. Dapper
[04:28] <powerj> Are there any intrest what you know, to include an alternative init system in ubuntu?
[04:33] <powerj> People from linspire distro, walked by my #initng and sad that they are working for a complete switch to #initng, actually i would like to see it if even optionally in ubuntu sience its my default distro.
[04:36] <powerj> That i calually want to say here is that i woud like some feedback, and possibly some directions of what shud be done to my project, towars the integration in ubuntu.
[04:37] <mpt> powerj, I am in no way an expert on the subject, but from what I have read, the plan is to work on simple improvements to the current system for 6.04 (and there's substantial room for improvement in the current system), then do something less hackish than init-ng for Dapper+n, where n is approximately 1.
[04:39] <mpt> see for example http://lists.ubuntu.com/archives/ubuntu-devel/2005-November/013021.html
[04:39] <powerj> less hackish than init-ng?
[04:43] <mpt> and http://lists.ubuntu.com/archives/ubuntu-devel/2005-November/013053.html
[04:43] <mpt> but I have my own work to do now, so excuse me :-)
[04:44] <powerj> mpt, actually initng is way more advanched than Solaris SMF, and way more extensionable.
[04:44] <powerj> mpt, okay thank you for your time.
[04:44] <mpt> If you want to discuss that, the best person to discuss it with would be the Scott James Remnant who wrote that message, aka Keybuk in IRC
[04:45] <mpt> he's the one doing a lot of the work to reduce startup time for Ubuntu at the moment.
[04:46] <Riddell> ogra: did you test the ppc CD?
[04:46] <ogra> Riddell, just finished
[04:47] <ogra> Riddell, i had only one problem ... there was KDE on my ubuntu ;)
[04:47] <ogra> Riddell, its fine :)
[04:47] <spacey> :o
[04:48] <spacey> whole night messing around with migrating ADS to Samba stuff, i look and feel like a zombie now
[04:48] <spacey> good night
[04:48] <ogra> night spacey 
[04:48] <ajmitch> night spacey :)
[04:48] <ogra> and night world, i'm off as well ...
[04:49] <ajmitch> see you later
[04:49] <powerj> mpt, thank you, i drop him a mail.
[04:51] <Riddell> ogra: great, thanks
[04:51] <Riddell> ogra: how come you can't do an install?
[04:52] <Riddell> Kamion: kubuntu x86 install/live, amd64 install/live and ppc live all work
[05:07] <Erlang> Can anyone help my with my Ubuntu/Debian dilemma?
[05:07] <magnon> the answer will always be ubuntu
[05:09] <Erlang> I can answer the dilemma myself at the end, but I'm looking for a killer p.o.v. somewhere.
[05:34] <magnon> Erlang: well, you could start by asking a bit more specific
[05:41] <Erlang> magnon: I could... I will be updating my system to AMD64 from 32 bit soon and I need to decide between
[05:42] <Erlang> Ubuntu and Debian
[05:42] <Erlang> I'm a wannabe Debian developer...
[05:54] <mpt> desrt, ping
[06:00] <Erlang> well, right now I'd go for Ubuntu.  If I think of a reason I could change my mind, I'll come back here.  It'll be more productive that way.
[06:00] <mpt> Erlang, no-one can deny the power of the brown
[06:01] <Erlang> the brown?
[06:02] <mpt> the brown!
[06:02] <Erlang> hmmm
[06:03] <Erlang> whats ... that?
[06:04] <ajmitch> a nice earthy colour
[06:05] <Erlang> o_O
[07:31] <Aegir`> Flaming mother of mercy. My filesystem just exploded... Well, thats one dapper box thats bit the dust. Time to reformat...
[09:06] <rob1> what is the default music app on a fresh install? rhythmbox/totem?
[09:08] <sabdfl> rob1: rhythmbox
[09:08] <rob1> thanks sabdfl 
[10:58] <zyga> morning
[11:00] <sivang> morning all
[11:30] <Kamion> powerpc/install fail due to media problems; my current inclination is to say "sod it", Kubuntu powerpc/install has got further
[11:31] <zyga> Kamion: is there any working hfs+ repartitioner?
[11:31] <zyga> (partition/fs resizer)
[11:32] <Kamion> zyga: parted in dapper should do it; not parted in breezy
[11:32] <zyga> Kamion: with user interface in the installer?
[11:33] <zyga> (or the livecd)
[11:33] <Kamion> try why not try it?
[11:33] <Kamion> (excuse weirdness, slow link)
[11:33] <zyga> breezy does not have any user interface for it and I'm not feeling like loosing my data again
[11:33] <Kamion> also breezy's parted can resize hfs+ provided that you disable journalling
[11:33] <Kamion> breezy sure does have user interface for it
[11:34] <zyga> hmm
[11:34] <Kamion> press enter on the Size: field in the detailed page for the partition
[11:34] <zyga> is that interface available in the debian installer?
[11:34] <Kamion> YES
[11:34] <zyga> hmm
[11:34] <Kamion> (er, sorry, caps lock)
[11:34] <zyga> can the journal be disabled after installation?
[11:35] <Kamion> of Mac OS? yes, google for instructions
[11:35] <zyga> right
[11:35] <Kamion> there are several ways to do it, both command-line and graphical
[11:35] <zyga> Kamion: if I find such instructions they could be patched as an info node into the installer, do you agree?
[11:35] <zyga> (mornin pitti)
[11:35] <pitti> Good morning
[11:35] <Kamion> no, I do not agree
[11:35] <Kamion> they could go in the installation manual, but they don't belong in the installer itself
[11:36] <zyga> at least a note that they are in the manual (and how to find the manual)
[11:36] <Kamion> no, only in the manual
[11:36] <zyga> hmm
[11:36] <zyga> I never knew about the manual really and I think that's something users might struggle with
[11:37] <Kamion> I'm not going to burden our translators with having to translate a million links to the manual from lots of places
[11:38] <Kamion> it's sufficient to point to the manual up-front at the very start, in the boot screens (we should add that)
[11:38] <zyga> I see, but if the user does not know how to sucessfuly resize their hfs+ volume he might decide not to install, just as I did. A single sentence that points in the right direction (Like: To find out how to resize your hfs+ volume, take a look at the manual on the CD) could help a lot
[11:38] <xxenon> is anyone testing 2.6.15 in dapper ?
[11:38] <zyga> I agree
[11:39] <Kamion> zyga: that will no longer be necessary in dapper *anyway*
[11:39] <zyga> oh, why? :-)
[11:39] <Kamion> because parted in dapper works even if you leave journalling enabled, as I implied above
[11:39] <Kamion> or at least so I am told
[11:40] <zyga> ah, then this is a no-issue :-)
[11:40] <zyga> thanks for the information
[11:40] <Kamion> indeed
[11:40] <Kamion> meh, kubuntu powerpc/install gets further but still dies due to media problems
[11:41] <Kamion> well, I have no reason to believe it will break and we've tested most of the individual pieces, so I'll just release it
[11:44] <Kamion> zyga: dapper's parted should also be able to handle HFSX (new variant of HFS+ used in very new versions of Mac OS X)
[11:44] <Kamion> breezy's couldn't
[11:44] <zyga> Kamion: hmm, 10.4.3?
[11:46] <Kamion> http://developer.apple.com/technotes/tn/tn1150.html says it was introduced in 10.3; may not be the default, I don't know
[11:46] <zyga> checking
[11:48] <Kamion> 03:44 < powerj> mpt, actually initng is way more advanched than Solaris SMF, and way more extensionable.
[11:48] <Kamion> 03:44 < powerj> mpt, actually initng is way more advanched than Solaris SMF, and way more extensionable.
[11:49] <Kamion> (d'oh, sorry)
[11:50] <zyga> Kamion: hfsx is a minor modification, it allows for (bah) case-sensitive file names
[11:51] <Kamion> yes (I don't really care about the details), but it still requires explicit support in parted because it's a new filesystem type
[11:51] <zyga> (welcome to the 1970 ;-)
[11:51] <Kamion> I also have read the technote I pointed you to ;)
[12:01] <Keybuk> ooh
[12:01] <Keybuk> when did lists.uc get prettyfied?
[12:01] <zyga> Keybuk: hi
[12:02] <Keybuk> that was a "hi, I was looking for you, and you're in trouble" kind of hi, wasn't it?
[12:02] <zyga> :>
[12:02] <zyga> no not really :)
[12:02] <Keybuk> oh, phew
[12:02] <zyga> I had a few questions but they are not important anymore I guess
[12:03] <Keybuk> I'm all ears
[12:03] <Keybuk> except for the bits of me that aren't
[12:03] <Keybuk> because I'm not a grasshopper
[12:03] <Keybuk> ask away
[12:03] <zyga> It was about non-contiguous malloc, one that doensn't suffer from allocation spikes
[12:04] <zyga> I had a discussion with seb the other day
[12:05] <zyga> if you know of any malloc that's better than current one I'm all ears myself :)
[12:06] <Keybuk> there's about as many malloc implementations as there are nih libcs
[12:06] <Keybuk> all equally bad at most things :)
[12:06] <Kamion> a totally new malloc implementation sounds about as inappropriate for dapper (a long-term supported release) as it's possible to get
[12:07] <zyga> it's not about dapper at all
[12:07] <zyga> damn I confuse you two
[12:07] <Keybuk> #define malloc mmap
[12:07] <Keybuk> easy
[12:07] <zyga>  hehe
[12:07] <zyga> almost ;] 
[12:08] <Keybuk> Kamion's the Lord of the Dance, and I'm the Queen of the Dancefloor
[12:08] <zyga> oh, where's buffy then?
[12:08] <Kamion> that's elmo
[12:08] <zyga> lol
[12:10] <zyga> Keybuk: http://www.suxx.pl/~zyga/malloc-test/ if you know of anything that can survive this please let me know :)
[12:11] <Kamion> malloc is about the common case as well as stress-tests
[12:11] <zyga> ?
[12:11] <zyga> ah
[12:11] <zyga> sorry I omitted one word and it didn't make sense
[12:11] <Keybuk> you can also tune malloc for your process too
[12:11] <Keybuk> there's a bunch of random options to let you rely less on sbrk, and more on mmap, etc.
[12:12] <Kamion> programs that really run into pathological behaviour of malloc often use their own allocators; it's not like there aren't loads around :)
[12:12] <Kamion> like the apr pools implementation, talloc, etc.
[12:12] <neuralis> zyga, have you looked at google's TC Malloc?
[12:12] <zyga> yes there are a multiudue of them
[12:12] <zyga> neuralis: no :> but it already sounds interesting
[12:12] <neuralis> zyga, goog-perftools.sf.net
[12:12] <neuralis> zyga, blazing fast, plays well with stl and threads
[12:13] <zyga> in-app allocators are basically because standard allocators are more less bad :/
[12:14] <Kamion> standard allocators are generally trying to be simple, so that they can be a common denominator; once you start being clever you often end up de-optimising for cases you didn't think of
[12:14] <Keybuk> malloc works sufficiently well for the most part
[12:15] <Keybuk> the glibc one is a little more intelligent than just "sbrk to get more space"
[12:15] <zyga> right but the really messy feature of the standard doug lea's malloc is the dependance on sbrk
[12:15] <zyga> it can use mmap but as far as the source says, it's not that smart
[12:16] <zyga> (especially when it comes to free)
[12:16] <Keybuk> free is over-rated :)
[12:16] <zyga> yeah ;] 
[12:16] <Keybuk> Linux knows better than to believe an app about how much memory it wants
[12:16] <Keybuk> and it all gets freed when the app closes anyway
[12:16] <zyga> ?
[12:17] <zyga> what about apps that keep runing and running
[12:17] <Kamion> for example I've worked on programs that really heavily use mmap, right up to the limits of the virtual address space; an mmap-based malloc would de-optimise for that
[12:17] <zyga> like browsers and damn text editors in most ofices
[12:17] <Keybuk> the big pages of unused memory won't be mapped
[12:17] <Keybuk> and they won't page fault because they're not being used
[12:17] <zyga> ?
[12:17] <Keybuk> so the app "thinks" it has that memory, when the kernel got rid of it ages ago
[12:17] <jamesh> Kamion: good reason to switch to 64-bit then :)
[12:17] <zyga> big pages of previously used memory keep being mapped
[12:18] <Keybuk> "big pages" ?!
[12:18] <zyga> s/big pages/lots of pages/
[12:18] <Keybuk> I of course meant lots of
[12:18] <Keybuk> yeah I was correcting myself there
[12:18] <zyga> :-)
[12:18] <Kamion> jamesh: in some cases that was a win, yes (subject to some other considerations), but it was not always quite so simple, especially five years ago
[12:18] <jamesh> nod.
[12:18] <Keybuk> why would they keep being mapped if they weren't used?
[12:18] <zyga> Keybuck: they were used before, that's why they were mapped
[12:19] <Kamion> jamesh: frex on the early Opterons it made almost no difference (curiously enough)
[12:19] <zyga> but after they were freed in the program they are still mapped 
[12:19] <Kamion> I think that's been sorted out since though
[12:19] <Keybuk> right, but Linux gets bored quite easily and unmaps them from the real memory if they're not actually used
[12:19] <zyga> and puts them to swap
[12:19] <Keybuk> so they appear in the process map, but don't actually take up real memory
[12:19] <zyga> that's bad IMHO
[12:19] <zyga> it cannot just discard them, linux doesn't know they are 'free' it just swaps them away, right?
[12:20] <Keybuk> right
[12:20] <zyga> exactly :/
[12:20] <zyga> why would an mmap based allocator be bad then?
[12:20] <Keybuk> the cost-per-map is reasonably high, you wouldn't want a new map per 16 byte struct
[12:21] <zyga> you cannot map such small regions anyway
[12:21] <zyga> but a mmap per 1MB makes more sense
[12:21] <zyga> when such chunk gets free it can be really returned
[12:21] <Keybuk> 1MB is rather arbitrary
[12:21] <zyga> generally a multi-heap design, in the allocator
[12:22] <zyga> it was an example
[12:22] <Keybuk> mapping anything other than multiples of 4096 bytes is silly ;)
[12:22] <zyga> (I was really thinking about mapping 4MB jumbo pages)
[12:22] <Keybuk> right, 4MB is a reasonably sensible (and common) size
[12:22] <Keybuk> as is 8MB (default stack, iirc)
[12:23] <zyga> each jumbo page could be freed (even parts of it could be unmaped if necessary)
[12:23] <Keybuk> ah, but then you have the fun thing
[12:23] <Keybuk> allocating space on the page according to where it's likely to be /freed/
[12:24] <zyga> (BTW: this can go away from #u-d if that's not appropriate here)
[12:24] <Keybuk> as you'd want to deliberately optimise for clearing pages at once
[12:24] <zyga> yesh :)
[12:24] <zyga> run-time data gathering could help
[12:24] <Keybuk> you wouldn't want to front-fill pages, you'd want to know in advance the memory usage pattern of the program so that data that is commonly freed together is put on the same page
[12:24] <zyga> or an enchanced malloc api like MALLOC_LONG_LIVED flag
[12:24] <Keybuk> there are compiler thingies that deal with that
[12:25] <zyga> oh?
[12:25] <zyga> I heard about the sun compiler, that it can optimize away some malloc calls
[12:25] <zyga> (but it was only for loops and trivial cases)
[12:26] <zyga> a generic approach, one that could calculate the probability of long-livedness of an object would be better
[12:26] <zyga> it could minimize living objects in mostly empty pages
[12:26] <zyga> (or simply chunk all long-lived objects together)
[12:27] <Keybuk> there are many many papers and experiments into it
[12:27] <Keybuk> see Google
[12:27] <zyga> believe me I did 
[12:27] <zyga> I tried citeseer too
[12:27] <zyga> maybe I spell badly
[12:27] <zyga> ..
[12:28] <Keybuk> the "generic" approach is often to use multiple memory pools
[12:29] <Keybuk> ie. have a "small shit" pool for fixed-sized blocks that you just reuse over and over
[12:29] <zyga> right :-)
[12:29] <Keybuk> so whenever you need anything less than 128 bytes, you just grab the first unusued block from that pool
[12:29] <Keybuk> and everything in that pool is 128 bytes long
[12:29] <zyga> I was really looking for some exisitng work but all I could find were multi-processor high-end allocators
[12:29] <Keybuk> you might also have a long-lived pool, for things you know are going to be around for a while
[12:30] <zyga> interesting but useless stuff for the desktop
[12:30] <Keybuk> sometimes you have a string pool, where you try some wacky stuff to re-use strings
[12:30] <zyga> I have a more generic approach
[12:30] <zyga> I have governors
[12:30] <zyga> classes and instances
[12:30] <zyga> and each governor is assigned to a fragment of vm space
[12:30] <zyga> each can really do what it wants internally
[12:31] <Keybuk> the trouble with the more complicated approaches is that you sacrifice speed for vsz
[12:31] <zyga> they have pretty simple outside api
[12:31] <zyga> yes I know
[12:31] <zyga> but that's the part of design
[12:31] <Keybuk> which de-optimises for something that needs to live fast and die young
[12:31] <zyga> to win speed by doing best not to touch swap as long as that's possible
[12:31] <zyga> well the governor init is pretty fast
[12:31] <Kamion> optimise for where it's likely to be freed> this is why application-specific allocators are often superior *anyway*
[12:31] <zyga> I'm still not sure about how to do startup
[12:32] <Keybuk> grep for example needs to just to allocate until it dies from either lack of memory, or finishes (and lets the kernel free up the memory it used)
[12:32] <zyga> app-specific allocators don't span libraries
[12:32] <Kamion> memory allocation patterns usually don't span libraries well either
[12:32] <zyga> and multiple allocators fighting one-another is bad for both vm space and swap-likliness
[12:33] <zyga> true, but an unified system that allows apps to plug their allocators 'higher' would be better
[12:33] <zyga> if you really need that custom allocator make sure it plays nicely with other parts of the system
[12:33] <zyga> anyway that's the long-term idea 
[12:33] <zyga> so far I've got a trivial allocator with one governor that survives that spike test 
[12:33] <zyga> and lots of ideas for other allocators
[12:34] <zyga> but I'm still far from tying that into runtime detection of what's best here
[12:34] <zyga> small object allocator, big object allocator, generic allocator (currently similar to what malloc does)
[12:35] <zyga> the key to unlocking all of this is to put a working history-based guesser that can allocate in the right governor
[12:35] <zyga> so long lived allcations go into one place mostly
[12:36] <zyga> history tracking is based on the call traceback of each malloc call
[12:37] <zyga> it's not working 'live' yet but it's a start
[12:37] <Kamion> *phew*
[12:37] <Kamion> doko: you're good to go with libstdc++ allocator changes
[12:38] <zyga> allocator changes??
[12:38] <Keybuk> hmm, I might upload udev and break the world this weekend then <g>
[12:38] <Kamion> zyga: *sigh*
[12:38] <siretart> Kamion: grats for flight cd1, man! :)
[12:39] <seb128_> Kamion: rock ;)
[12:39] <Kamion> zyga: *libstdc++*, not libc; http://lists.debian.org/debian-devel-announce/2005/11/msg00010.html
[12:39] <zyga> checking
[12:40] <siretart> zyga: some ppl refer to that as the 'c2a' transition. it basically means another cxx transition *sigh*
[12:41] <zyga> ;-)
[12:41] <zyga> right
[12:41] <Keybuk> "you need to update for the C++ transition"
[12:41] <Keybuk> "right, uh, which one?"
[12:42] <siretart> hrhr
[12:44] <Keybuk> Kamion: good quote <g>
[12:44] <Kamion> I liked it
[12:45] <Keybuk> at least, I think I clicked approve
[12:45] <Keybuk> I hate mailman
[12:45] <Kamion> shout if I need to resend it
[12:45] <Keybuk> it showed up, so I must have :)
[12:46] <Kamion> ah, yes, there it is
[12:46] <HiddenWolf> Keybuk, you take pleasure in breaking the world, don't you? ;)
[12:46] <Keybuk> HiddenWolf: only by breaking the world can we learn what it's made of, and how to put one back together again
[12:46] <HiddenWolf> dude, it's saturday. Don't make me read twice. :)
[12:47] <Kamion> Keybuk: *do* sync that with an upload of linux-meta, please :)
[12:47] <Kamion> hm, we probably want l-r-m first too
[12:47] <Keybuk> yeah, we'll need to sync, at once:
[12:47] <Keybuk> 1) 2.6.15 in meta
[12:47] <Keybuk> 2) lrm
[12:47] <Keybuk> 3) udev
[12:48] <Keybuk> 4) hotplug and grepmap removed from meta
[12:48] <Kamion> l-r-m can come first
[12:48] <Keybuk> probably hal too
[12:48] <Keybuk> I'll grab everyone into #ubuntu-boot when it's "ready" and we'll make sure we lock-step everything
[12:48] <Kamion> and should, given how tricky it is to make it build
[12:48] <Keybuk> probably 5) installer checks too
[12:49] <Kamion> yeah; I'm going to be away much of the weekend
[12:49] <Kamion> we need some installer syncs/merges from upstream before the installer will work right with 2.6.15
[12:50] <Keybuk> "I'm sorry, was that your aorta?"
[12:50] <Kamion> couple of things we noticed at the last minute
[12:50] <Keybuk> what changed with 15 that broke it?
[12:51] <Kamion> Keybuk: not 15 in particular, just a few things about newish udev we forgot to actually do as opposed to talk about
[12:51] <Keybuk> oh, such as?
[12:52] <Keybuk> bearing in mind our new udev isn't the same as Debian's
[12:53] <HiddenWolf> Keybuk, why not?
[12:54] <Riddell> Kamion: nice quote :)
[12:57] <Keybuk> HiddenWolf: because Debian took a long stroll down crack-addled-alley
[12:59] <HiddenWolf> Keybuk, seriously?
[12:59] <Keybuk> take for example the elaborate maintainer scripts that mount a new tmpfs, initialise it with the newly upgraded udev, and try to migrate the existing system over to that while killing any process currently reading a device, etc.
[12:59] <HiddenWolf> ehm, ouch?
[12:59] <Keybuk> ... we decided just to leave the old /dev in place and pop up a "you might want to reboot at some point" thing
[01:00] <doko> Kamion: ok, thanks
[01:00] <HiddenWolf> Keybuk, you're telling me that udev update will kill all processes on any debian rig?
[01:00] <Keybuk> not all processes, but it'll certainly handicap a few things
[01:01] <HiddenWolf> pretty much kicking around in a domino setup...
[01:01] <Keybuk> yeah, upgrading udev is pretty much like purging your current kernel and popping a new one on the disk
[01:02] <Keybuk> or, tbh, upgrading libc
[01:02] <Keybuk> it's reboot time
[01:02] <Keybuk> trying to deal with it any other way is just not going to work
[01:02] <HiddenWolf> Poor testers, all thinking flight might be a decent time to take the plunge. :)
[01:04] <Keybuk> it is a good time
[01:04] <Keybuk> what's the point in having testers who don't want to test things? :p
[01:17] <Kamion> Keybuk: by newish I mean "post-060"
[01:18] <Kamion> Keybuk: like dealing with udevstart possibly not being there
[01:19] <Keybuk> ahh
[01:48] <HiddenWolf> Keybuk, so if this goes wrong, is the system unbootable?
[02:31] <Keybuk> HiddenWolf: only if it goes _very_ wrong
[02:32] <HiddenWolf> Keybuk, so if someone updates halfway through putting the new versions in the archive, they're screwed. :P
[02:35] <Keybuk> that's what versioned dependencies are for
[02:35] <Keybuk> though if someone compiles their own older kernel, lots of things will stop working for them
[02:35] <Keybuk> they'll get the old static /dev and no hotplug at all, etc.
[02:53] <thierry> seb128 : for https://launchpad.net/distros/ubuntu/+source/ghextris/+bug/4618 , do I send another patch to not force the extension, or do you simply close the bug as NOTABUG ?
[02:54] <seb128> thierry: if the path is fixed there is no need to drop the .png, there is no variants
[02:54] <seb128> thierry: variants are usually shipped with themes
[02:56] <seb128> ie: if you specify just a name "icon_name"
[02:56] <thierry> seb128 : ok so you'll close it?
[02:56] <seb128> it can be shipped by different themes, with a svg variant by example
[02:56] <seb128> I already did
[02:56] <thierry> ho ok sorry<
[02:57] <thierry> we should copy your comment in the wiki page
[02:57] <seb128> I'll comment
[02:58] <thierry> k thanks
[02:58] <seb128> np
[03:00] <thierry> seb128 : while we talk about that I have other bugs that maybe you'd like to check too (for the absolute icon path thing)
[03:02] <seb128> thierry: which one?
[03:02] <thierry> seb128 : 4587 , 4608 , 4419 , 3963 AND 3951
[03:02] <seb128> thierry: I've closed 5-6 bugs this morning
[03:02] <thierry> seb128 : I know so let's do the whole clean up
[03:03] <seb128> bittornado doesn't ship a .desktop with dapper
[03:03] <seb128> so I've not commented on #4587
[03:03] <thierry> seb128 : but he needs one! no?
[03:04] <seb128> yeah, but I don't want to start doing such change, I just want to quick comment on stuff I can try without rebuilding a package modified :p
[03:04] <seb128> that's saturday
[03:04] <seb128> #4608
[03:04] <seb128> Icon=/usr/share/httrack/icons/webhttrack.xpm
[03:04] <thierry> seb128 : yeah ok... but I mean you won't close the bug for that right?
[03:04] <seb128> same issue, I reject it
[03:04] <thierry> seb128 : yeah I see
[03:04] <seb128> thierry: no
[03:04] <thierry> good
[03:08] <zakame> is mdnsresponder dropped in dapper?
[03:08] <zakame> I don't see it in packages.u.c, but asking away just to be sure :)
[03:08] <seb128> thierry: 4419 path required
[03:08] <seb128> thierry: #3963 is ok
[03:09] <pef> hello
[03:09] <seb128> thierry:utch, patch from #3951 is really broken, you just dropped the translations
[03:09] <seb128> hi pef
[03:11] <thierry> seb128 : damn, didn't saw that, but anyway it should be closed since it goes in /usr/share/gnome-system-tools/pixmaps/disks.png
[03:12] <thierry> seb128 : while looking at the patch, I remember there was some specs problems
[03:14] <seb128> thierry: there is different desktop file to autogenerate translations, etc
[03:14] <seb128> you drop the _ on _Name by example
[03:14] <seb128> which breaks the translations
[03:15] <zakame> hmmm, netatalk doesn't seem to build, build-deps not met as libdb4.2-dev removes heimdal-dev and kerberos4kth-dev, all of which build-depended on by netatalk :( what should I do?
[03:16] <seb128> zakame: your sentence is not clear
[03:17] <seb128> there is some mess with libdb versions
[03:17] <seb128> pitti started looking on that yesterday, maybe wait a few days
[03:17] <thierry> seb128 : yeah I see... but icon like @pixmapsdir@/network.png ... does it needs to stay like that?
[03:17] <seb128> thierry: yeah, they do
[03:18] <zakame> seb128: I was trying to grab the build-deps for netatalk, but I couldn't do so because upon grabbing libdb4.2-dev it tries to remove heimdal and kerberos :(
[03:18] <thierry> k
[03:22] <seb128> zakame: right, pitti was on this yesterday, wait monday
[03:22] <zakame> seb128: ah, ok, putting this on #4106 as a comment, thanks :)
[03:23] <seb128> np
[03:48] <Lathiat> mjg59: hrm, is usplash in dapper supposed to be b0rked?
[03:49] <tseng> Lathiat: yes.
[03:49] <Lathiat> ok
[03:56] <Lathiat> ooh interesting 2.6.15 sound driver for my laptop (i810) no longer has a split master/headphone
[03:56] <Lathiat> that was both a usefull and annoying feature
[04:05] <xhaker> shouldn't ubuntu-desktop depend on xchat | xchat-gnome
[04:05] <xhaker> nvm
[04:05] <xhaker> it's in universe
[04:05] <xhaker> any plans to bring it to main?
[04:10] <slomo> xhaker: when it's completly usable maybe ;)
[04:11] <xhaker> i ask this because i'd like to try it.. the spell checker sound good for ubuntu
[04:12] <xhaker> i guess i'll try it later when it gets depends on 2.6.0
[04:14] <spacey> any ms active directory guru's here by *any* chance?
[04:50] <Manny> hi
[04:51] <Manny> I'm re-asking the question here, since asking it ni #ubuntu didn't yield any results: are there any plans to add more -dbg packages? I'm specifically looking for libpoppler-glib-dbg and libpoppler-dbg
[05:10] <Riddell> Manny: I don't think there's any plans for it, but feel free to do the changes and ask for them to be reviewed and included
[05:18] <Manny> Riddell, thanks
[05:18] <Manny> Riddell, -dbg packages are particularly useful for tracking down crashes
[05:22] <pitti> Manny: eventually we want a more general approach to this
[05:22] <pitti> Manny: https://wiki.ubuntu.com/AutomatedProblemReports
[05:26] <Manny> pitti, excellent
[05:29] <zyga> pitti: hi
[05:29] <zyga> pitti: a few questions
[05:29] <zyga> pitti: first langpack update for breezy, when
[05:30] <zyga> pitti: dapper translations open, when
[05:30] <zyga> thanks
[05:30] <zyga> carlos: ^
[05:30] <pitti> Rosetta export is currently switched off
[05:30] <pitti> without data I can't do anything
[05:30] <zyga> any particular reason? is something broken
[05:30] <pitti> I hope it is fixed soon now
[05:30] <pitti> it has been broken all the time
[05:31] <zyga> hmm :/
[05:31] <zyga> okay
[05:31] <zyga> thanks
[05:31] <zyga> and feel free to ping me if you feel that .desktop files need any coding :-)
[05:31] <zyga> I'd like to finish that one
[05:40] <psusi> I changed my sources.list to point to dapper instead of breezy, then did an apt-get update ; apt-get dist-upgrade.. it looked like it upgraded me to dapper, only a number of packages are not using the newer dapper versions
[05:40] <psusi> anyone got any idea what I did wrong?
[05:41] <hunger> psusi: This is not a support channel. Please check in #ubuntu.
[05:41] <psusi> ok... thought they were more user level issues with breezy
[05:42] <psusi> I changed my sources.list to point to dapper instead of breezy, then did an apt-get update ; apt-get dist-upgrade.. it looked like it upgraded me to dapper, only a number of packages are not using the newer dapper versions
[05:42] <psusi> damnit... sorry
[05:42] <hunger> psusi: This channel is for developer talk. Feel free to stay and listen in.
[05:44] <psusi> I'm trying to get the new version of coreutils with O_DIRECT support and possibly do some hacking on it... thought that since it was being used in dapper, I could just dist-upgrade... heh
[05:44] <hunger> psusi: I never do dist-upgrades. Always to upgrade (plus remove and install).
[05:45] <HiddenWolf> hunger, why is that? As soon as the dist-upgrade doesn't conflict, it should be perfectly safe, right?
[05:46] <hunger> HiddenWolf: Sure. It's just a control-freak kind of thing.
[05:46] <psusi> well is what I did the correct way to do a dist-upgrade?  It looked like it worked... chugged along for a while doing upgrades
[05:46] <psusi> but when I look in synaptic, I've still got the old version of coreutils
[05:46] <hunger> psusi: dist-upgrade is definitly the proper way to do it.
[05:47] <hunger> psusi: Which one is that?
[05:47] <psusi> 5.2.1
[05:47] <hunger> psusi: It is not as if *everything* changes on dist-upgrade.
[05:47] <psusi> according to packages.ubuntu.com, dapper is using coreutils 5.93
[05:47] <psusi> that's what I need
[05:48] <hunger> psusi: I am on dapper and I got 5.93. Have you tried running apt-get directly in a terminal?
[05:49] <psusi> yea... after the apt-get dist-upgrade I tried update and upgrade again... no dice
[05:50] <hunger> psusi: apt-get -f install does not find anything to fix either?
[05:50] <psusi> nope
[05:50] <hunger> psusi: Dapper is in development, sometimes something does go wrong.
[05:51] <psusi> yea... I understand... that's why I'm trying to figure out of this is something stupid that I am doing, or something is borked in the repositories
[05:51] <psusi> apt-get update fetches all the dapper package lists... I just don't get it
[05:54] <infinity> psui : apt-cache policy coreutils
[05:54] <mdz> psusi: using the us.archive.ubuntu.com mirror?
[05:55] <mdz> psusi: (it's broken at the moment)
[05:55] <psusi> yes...hr... pastebin seems to be down
[05:55] <psusi> ohh, it is?  how's it broken and is there another mirror I could use?
[05:55] <infinity> s/us.//
[05:56] <psusi> hrm... ok
[05:57] <psusi> bingo
[05:57] <psusi> upgrading 380 packages... hah
[05:57] <psusi> thanks...
[06:06] <Znarl> mdz : us.archive is broken?!?
[06:15] <psusi> it seems so
[06:29] <pitti> hmm?
[06:29] <pitti> dpkg-divert: rename involves overwriting `/usr/lib32/libGL.so.1' with
[06:29] <pitti>   different file `/usr/lib32/nvidia/libGL.so.1.xlibmesa', not allowed
[06:29] <pitti> d'oh, I can't purge nvidia-glx any more
[06:41] <zyga> pitti: I never understood why there cannot be multiple gl systems at the same time (like gl.d) with a select-opengl tool
[06:41] <hunger> zyga: gentoo has something like that.
[06:44] <zyga> oh, so it's possible technically :>
[06:44] <zyga> cool, why don't we get it?
[06:59] <mdz> Znarl: broken = hasn't been updating for a while, yeah.  we discussed it yesterday
[07:55] <desrt> mpt; pong
[08:00] <mjg59> Hmm. Anyone have any idea how many tablet PCs there are on the market?
[08:01] <Treenaks> mjg59: how many models, or how many sales of those models/
[08:02] <mjg59> How many models
[08:02] <HiddenWolf> mjg59, why? they're 90% Win or Palm.
[08:02] <mjg59> HiddenWolf: Uh. No they aren't. Tablet PCs, not PDAs.
[08:04] <sivang> mjg59: for starters, there's one per each "big" vendor, Toshiba, Panasonic, Sony, IBM, Compaq etc
[08:04] <sivang> mjg59: the Panasonic's one are interesting :)
[08:05] <mjg59> Ah. I hadn't seen any Panasonic or Sony ones.
[08:05] <mjg59> I've just written some code for the Toshiba one to detect when it's in tablet mode
[08:06] <mjg59> So I'm wondering how many people I'll need to find in order to make it useful on other pieces of hardware
[08:06] <sivang> mjg59: wow nice, do you have the hardware at your disposal?
[08:06] <mjg59> I've got a Toshiba tablet, yeah
[08:07] <sivang> mjg59: I'd say 5 people :)
[08:07] <mjg59> The HP one I've got is a slab design - there's no screen rotation, there's just keyboard attach/detatch
[08:07] <sivang> mjg59: Canonica's sponsering or privately yours?
[08:07] <mjg59> Various sources
[08:07] <sivang> mjg59: very cool
[08:08] <sivang> mjg59: so, what features does Ubuntu already supports on the Tablet PC ?
[08:08] <mjg59> sivang: Touch screen is supported if you install wacom-tools
[08:08] <mjg59> And, uh, that's about it
[08:08] <sivang> mjg59: and then I can use handwriting recognition to input in?
[08:08] <sivang> m
[08:08] <mjg59> You can install some handwriting software that doesn't work very well
[08:09] <mjg59> And then you can have extreme problems when the screensaver comes up
[08:09] <sivang> mjg59: FOSS , in need of more work ? :)
[08:09] <sivang> mjg59: well, at least good to hear from you that we're getting there 
[08:10] <mjg59> Oh, and you currently still need to hack xorg.conf if wacom-tools is installed
[08:10] <mjg59> But other than that, it's all good
[08:10] <sivang> mjg59: so at least I can use my finger instead of the mouse?
[08:11] <sivang> mjg59: well, if you need someone to do testing, I'm always willing to be sent some hardware ;-D
[08:14] <HiddenWolf> mjg59, is there any chance whatsoever that ubuntu would ever get the handwriting right?
[08:15] <mjg59> sivang: They're generally wacom devices, so not a touch screen in the traditional sense
[08:15] <mjg59> You have to use a special pen
[08:15] <mjg59> HiddenWolf: Ideally
[08:22] <HiddenWolf> mjg59, not too promising. :(
[08:23] <mjg59> HiddenWolf: It's not something I've got any time to work on, but with luck somebody will be able to at some point
[08:25] <HiddenWolf> mjg59, so is it a goal to get ubuntu in the embedeed realm?
[08:28] <mjg59> HiddenWolf: That's what the ucbuntu project's supposed to be looking at
[08:34] <sivang> mjg59: Charles is one of the guys working on it right?
[08:36] <mjg59> sivang: Not sure, I'm afraid
[08:37] <sivang> mjg59: I met him at UBZ, he told me he was working on some packages for hendhelds. actually, this isn't probably "embedded" per se :)
[08:39] <mjg59> Hmm. That's interesting.
[08:39] <mjg59> One of the SATA patches is breaking suspend on this laptop
[08:49] <ispiked> mjg59: suspend to disk or suspend to ram?
[08:52] <mjg59> ispiked: Suspend to RAM
[08:59] <mjg59> Grah. Cock.
[08:59] <mjg59> It's the sata suspend/resume patch (ironically)
[08:59] <mjg59> mdz: Around by any chance?
[09:00] <mdz> yep
[09:00] <suneco> hello guys
[09:00] <suneco> plz i am semi new to ubuntu
[09:01] <suneco> and i need to know - how do i follows these instructions
[09:01] <suneco> 1/ install (using synaptic) the kernel sources for 2.6.10-5386
[09:01] <mdz> suneco: the best place to ask such questions is #ubuntu
[09:01] <suneco> yes, but they don't answer
[09:01] <suneco> its intermediate
[09:01] <suneco> ok, i will
[09:02] <mdz> there is a list of other support resources at http://www.ubuntu.com/support/
[09:02] <suneco> ok thks
[09:04] <Loevborg> I just discovered that breezy's ruby threading is borked; can't http://bugzilla.ubuntu.com/show_bug.cgi?id=17415 be fixed in a breezy update?
[09:09] <ispiked> mjg59: 59?
[09:09] <mjg59> ispiked: ?
[09:10] <Blejdfizt> i'm having some trouble with launchpad.. my bugreport is falsely reported to be in upstream.. how do i remove that?
[09:10] <ispiked> mjg59: what's the 59 mean on the end of your name?
[09:10] <mjg59> ispiked: It's my university username
[09:11] <ispiked> mjg59: I see. Our scheme is <first initial><middle initial><first six letters of our last name><optional number if you're not unique>.
[09:11] <mjg59> All usernames here have numbers
[09:15] <HiddenWolf> heh
[09:15] <HiddenWolf> still better than my uni.
[09:15] <HiddenWolf> I'm 279169hb. :)
[09:43] <mpt> Blejdfizt, what's the URL of the bug report?
[09:45] <Treenaks> mpt: then you had your birthday?
[09:45] <mpt> yeah, now I'm 27 :-)
[09:45] <Treenaks> mpt: wow, mjg59 must be very old then ;)
[09:45] <mpt> but seriously, I was mpt26 at my first university
[09:45] <mpt> and thoma994 at my second
[09:47] <ispiked> oh, nevermind. princeton.org != princeton.edu
[09:47] <mpt> What did you think Brian Kernighan taught, ispiked?
[09:48] <mpt> (but yes, Princeton was neither of my universities, sad to say)
[09:48] <Treenaks> mpt: wrong continent?
[09:48] <mpt> indeed
[09:51] <mpt> Blejdfizt, if you're going to come back later and try asking again you might get a better response in #launchpad
[10:02] <zyga> hi
[10:02] <zyga> is it just me or is ubuntu.com down?
[10:10] <HiddenWolf> it's up for me
[10:10] <Blejdfizt> mpt: sorry.. was writing on a report :)
[10:10] <Blejdfizt> mpt: https://launchpad.net/products/glibc/+bug/4641
[10:32] <mpt> Blejdfizt, so the bug occurs only in the Ubuntu glibc package, not in glibc upstream?
[10:34] <mpt> unfortunately you can't alter the upstream request because of https://launchpad.net/products/malone/+bug/1342
[10:34] <mpt> I'll do it for you since I'm a Launchpad admin
[10:34] <mpt> if it's true that the bug doesn't happen upstream
[10:35] <Blejdfizt> i cannot confirm that it does or doesn't occur upstream
[10:36] <Blejdfizt> i just did the report wrong :)
[10:36] <Blejdfizt> it works in debian stable (but it's an older version there).
[10:37] <mpt> ok
[10:37] <Blejdfizt> the first post (with the patch) could be removed also since the patch is in an attachment
[10:40] <mpt> Malone doesn't remove comments (including original bug reports), but hopefully they'll eventually be hidden by default if superceded, as described in https://wiki.launchpad.canonical.com/KeepingBugsConcise
[10:41] <Blejdfizt> ok.. i'll know that until next time then :)
[10:42] <mpt> yeah, patches are much better as attachments
[10:43] <Blejdfizt> but.. i attached a patch :)
[10:54] <zyga> can anyone give me a direct link to 'download breezy' section
[10:55] <zyga> somehow my isp has broken connection to the majority of outside world
[10:55] <zyga> and I'm just about to publish a new version of ubuntu.pl
[11:02] <psusi> jesus I hate octal
[11:03] <zyga> psusi: why?
[11:04] <psusi> I dunno... I just don't like octal
[11:04] <psusi> I have to think to figure out how it maps to binary
[11:04] <psusi> hex I just see it in binary right away
[11:07] <zyga> octal only makes sense to chmod arguments IMHO :-)
[11:07] <psusi> I can't stand it there either