[05:53] <pitti> Good morning
[05:54] <ajmitch> hi pitti
[06:48] <dholbach> good morning
=== doko_ is now known as doko
=== asac_ is now known as asac
[08:22] <soren> Any chance of a bit of unapproved queue love today?
[08:43] <pitti> soren: yes, I'll get to it; I spent two hours on it yesterday, until I had to run out
[08:53] <pwnguin> neat
[08:53] <pwnguin> i wrote to a guy about mindscript's license (posted a few days ago) and he agreed to publish it under gplv3
[09:08]  * soren hugs pitti
[09:08] <soren> pitti: Sounds great!
[09:15] <pitti> bdmurray: wrt our hal-info discussion yesterday, I just sent an SRU proposal to TB, CC'ing u-devel@
=== foka_ is now known as foka
[10:54] <seb128> hum, upgrade to intrepid doesn't work
[10:55] <soren> Wow.
[10:55] <soren> I was literally seconds away from saying:
[10:55] <seb128> xargs assertion error
[10:55]  * soren takes the red pill and installs intrepid on one of his servers
[10:56] <soren> Maybe I should wait a bit. My workstation seems to be chugging along just fine, though.
[10:56] <seb128> xargs: xargs.c:443: main: Assertion `bc_ctl.arg_max <= (131072-2048)' failed
[10:56] <seb128> I get that on debconf installation
[10:56] <seb128> https://bugs.edge.launchpad.net/ubuntu/+bug/232416
[10:56] <ubottu> Launchpad bug 232416 in ubuntu "debconf upgrade: xargs Assertion `bc_ctl.arg_max <= (131072-2048)' failed." [Undecided,New]
[10:57] <seb128> https://bugs.edge.launchpad.net/ubuntu/+source/findutils/+bug/234345 too
[10:57] <ubottu> Launchpad bug 234345 in findutils "xargs: xargs.c:443: main: Assertion `bc_ctl.arg_max <= (131072-2048)' failed." [Undecided,Invalid]
[10:57] <soren> Yeah, infinity was working on that problem on the buildd's when we were at UDS, I think.
[10:58] <soren> I thought it was resolved.
[10:59] <seb128> ok
[10:59] <seb128> upgrading findutils to the intrepid version and restarting the dist-upgrade worked
[11:00] <seb128> something should pre-depends on the new version then
[11:00] <Keybuk> why findutils?
[11:00] <Keybuk> oh, because that's where xargs is
[11:00] <seb128> Keybuk: because that's where xargs is
[11:00] <Keybuk> I had it in my head as in coreutils
=== davmor2 is now known as davmor2_away
[11:03] <cjwatson> the only thing I can imagine is that the new libc6 trips it
[11:03] <cjwatson> (somebody should test that)
[11:03] <cjwatson> in which case libc6 should Breaks: findutils (<< whatever)
[11:07] <Keybuk> it was the new libc
[11:07] <Keybuk> I assume that it increased the maximum argv length
[11:07] <Keybuk> and broke xargs assert
[11:08] <StevenK> \o/
[11:08] <StevenK> We saw that on the buildds at the start of UDS/Fosscamp
[11:09] <StevenK> Actually, that would explain why pitti's build fixed it.
[11:09] <cjwatson> so Breaks seems appropriate then
[11:09] <cjwatson> indeed, if it picks it up at compile-time
[11:09] <StevenK> They changed the define, xargs was built against the old libc, the new one is installed, and xargs goes bang.
[11:09] <StevenK> pitti uploads a no-change upload that infinity hand-held, and it is built against the new libc
[11:10] <StevenK> So no assert error
[11:10] <cjwatson> somebody should report that to findutils upstream too; it's a corner case, but nasty
[11:10] <StevenK> Indeed
[11:11] <soren> Why would findutils want to make that assertion anyway?
[11:11] <geser> pitti: Hi, please give-back: libparams-validate-perl. Thanks.
[11:12] <soren> I could understand why it'd make sure that arg_max was *more* than what it used internally. Not less.
[11:12] <soren> Oh, or is bc_ctl.arg_max perhaps its internal max_argv?
[11:12] <soren> That would make sense.
[11:13]  * soren makes a note to think more before he types
[11:16] <pitti> geser: nudged
[11:19] <pochu> some core-dev could decline the edgy nominations from https://bugs.edge.launchpad.net/ubuntu/edgy/+nominations, as edgy is out of support now
[11:25] <pitti> pochu: done
[11:25] <pochu> thanks pitti
[11:26]  * pitti fixes the bug number parsing in http://people.ubuntu.com/~ubuntu-archive/pending-sru.html to match current LP HTML
[11:27] <pitti> seb128, bdmurray, ogasawara_: ^ FYI, they are reasonable now, no upstream bugs, all LP bugs
[11:28] <seb128> pitti: ah good, I looked at it this morning and it was lacking some bugs, seems alright now ;-)
[11:28]  * seb128 hugs pitti
[11:28] <pitti> seb128: it changed recently, it's LP: <a href="/bugs/220805" ... now
[11:28] <seb128> ok
[11:34]  * ion_ fails to understand why apt-get dist-upgrade installed dbus and dbus-x11 to his virtual intrepid system. Nothing that is installed seems to depend on it.
[11:36] <geser> ion_: recommeds-by-default perhaps
[11:37] <geser> doko: do you know when you will find some time to review/comment/sponsor bug #229877?
[11:37] <ubottu> Launchpad bug 229877 in cpio "[intrepid] cpio build-depends on mingw32" [Undecided,New] https://launchpad.net/bugs/229877
[11:37] <ion_> geser: No metapackages that are installed seem to recommend it either.
[11:37] <geser> ion_: aren't recommends installed now for all packages and not only metapackages?
[11:37] <gnomefreak> dbus is installed by default and i thought ubuntu-desktop has it as dep
[11:38] <ion_> Oh. That i didn’t know. libdbus-1-3 indeed recommends dbus.
[11:38] <gnomefreak> or not
[11:38] <gnomefreak> ah
[11:39] <geser> ion_: see the changelog for apt 0.7.13ubuntu1: * enable installation of recommends by default
[11:40] <ion_> Yeah, i read it after you mentioned it.
=== davmor2_away is now known as davmor2
[11:46] <Riddell> pitti: split soprano and decibel should be available if you are able to take a look
[11:48] <pitti> Riddell: ok, thanks
=== hunger_t is now known as hunger
[12:49] <siretart> asac: is there still something to do for bug #141233?
[12:49] <ubottu> Launchpad bug 141233 in wpasupplicant "MASTER network-manager crashes when wpasupplicant ctrl socket is not available" [Medium,Confirmed] https://launchpad.net/bugs/141233
[12:51] <asac> siretart: its worked around on network manager side, but it still exists iirc
[12:51] <asac> e.g. just shutdown sometimes will not release control socket
[12:51] <siretart> what do you mean with 'releasing' the control socket. 'unlink'-ing?
[12:54] <siretart> I'm inclined to propose marking it as invalid for wpasupplicant for now. I don't think this is a problem if wpa_supplicant is used standalone
[12:54] <siretart> and for the interaction part NM vs wpa_supplicant, a workaround is found. so what's left to do?
[13:20] <james_w> If I have a usb key formatted as vfat then it gets mounted so that my user owns it and can write to it. If it is formatted with ext2 then it is mounted with root as the owner and no write permissions for anyone else.
[13:21] <james_w> This is with nautilus taking care of the mounting. Is this intentional, a bug, or should I configure what I want somewhere?
[13:21] <james_w> oh, and the filesystem is actually within a luksformat created partition, which may make a difference.
[13:22] <seb128> james_w: that's a gnome-mount thing, start gconf-editor, system, storage, default_options
[13:23] <seb128> james_w: there is default options specified for vfat there
[13:23] <james_w> ah, thanks, I see it.
[13:23] <james_w> is there a reason that ext2/3 are not there?
[13:24] <seb128> james_w: the behaviour for ext* might be wanted, not sure, you should ask pitti about that
[13:24] <james_w> I guess it shouldn't interfere with system volumes, and they typically wouldn't be vfat.
[13:26] <pitti> james_w: it's half-intended, I'd say
[13:26] <pitti> james_w: the underlying problem is that ext2 & friends do not support mount options "uid" and "gid"
[13:27] <pitti> james_w: primarily because they have a clear idea about multiple users/groups and thus just changing root:root files would be inconsistent
[13:27] <james_w> ah, I didn't know that.
[13:27] <pitti> james_w: for those you either need to create a folder for you, or chown the drive's / to you, or use vfat
[13:28] <james_w> thanks pitti, I should be able to get what I want from here.
=== |Xorothal| is now known as Xorothal
[14:32] <pitti> geser: I had to reject your apache-itm upload, the changelog had a wrong bug number (lp: #xxx)
[14:34] <calc> slangasek: hi
[14:36] <cjwatson> calc: he's been on holiday so far this week, FYI; back tomorrow
[14:39] <calc> cjwatson: ah ok :)
[14:39]  * calc is on vacation still as well, just waiting for his wife to get ready
[14:39] <YokoZar> Apparently you can use tinyurl with apt-url: http://tinyurl.com/2bhmdp  <--- installs Wine
[14:40] <geser> pitti: argh, will upload a fixed one
[14:42] <cjwatson> YokoZar: I'm sure it can't be a good idea for the browser to support that; although I suppose it still prompts
[14:42] <calc> OOo 2.4.1 rc1 is out now and might end up being the final one released early next week, still watching the lists to see what happens
=== jelmer is now known as jelmer__
=== jelmer__ is now known as jelmer
[14:45] <cjwatson> calc: kinda moot if it doesn't make it into the archive for the deadline, though
[14:46] <mvo> if there is anyone with a powerpc, I would appreciate testing for the fix for bug #220890
[14:46] <ubottu> Launchpad bug 220890 in software-properties "[hardy] software-properties-gtk doesn't recognize (nor know about) ports.ubuntu.com" [High,Confirmed] https://launchpad.net/bugs/220890
[14:46] <calc> yea, i can upload the rcX whatever is available in time for the deadline, it will most likely just get renamed
[14:46] <calc> i will see what i can find out on monday at the release meeting
[14:46] <cjwatson> I think I had assumed from your mail that it had already been uploaded
[14:47] <cjwatson> I understand the deadline to be Sunday, BTW
[14:47] <calc> cjwatson: m14 has been the final 2.4.1 is scheduled for official release on june 3
[14:47] <calc> oh argh, i will be in the air at that time :(
[14:47] <cjwatson> just in case that wasn't clear
[14:47]  * calc had forgotten the deadline was june 1 the same as his fly home date
[14:48] <calc> ok well i'll get rc1 into proposed once m14 is done building everywhere to make sure there aren't any problems
[14:48] <calc> shouldn't take too long to do that update
[14:52]  * calc checking the diff between m14->m16 upstream
[14:58] <tjaalton> deadline? for .1?
[15:00] <lucas_> how can I check if a package is shipped on the ubuntu CDs?
[15:01] <lucas_> (the package is libruby1.8)
=== [Xorothal] is now known as Xorothal
=== smarter_ is now known as smarter
[15:05] <tmmoyer> I would like to try and package a program called TrustedGRUB, but looking at the way its source tree is structured, it doesn't really follow the conventional Makefile at the top-level idea.  It has a custom shell script to build the binaries and requires user interaction.  What would be the best method of packaging it?  My first thought is to add a Makefile that handles everything (i.e. calling the build script and then running the commands that t
[15:05] <ompaul> lucas_,  /msg ubottu info libruby
[15:07] <lucas_> ompaul: I know it's in main, but it doesn't say if it's shipped
[15:10] <cjwatson> tjaalton: yes. June 1
=== lucas_ is now known as lucas
[15:10] <cjwatson> https://wiki.ubuntu.com/HardyReleaseSchedule has it (in fact documents something slightly earlier due to week alignment)
[15:11] <cjwatson> tmmoyer: there's no reason upstream build scripts have to be Makefiles; they just have to be callable from debian/rules
[15:11] <cjwatson> debian/rules can do whatever it likes, not necessarily $(MAKE)
[15:11] <tjaalton> cjwatson: ok, thanks for the heads-up.. need to get busy then ;)
[15:11] <cjwatson> you could even use expect to deal with user interaction if there was no other way
[15:11] <cjwatson> lucas: look at the .list and .manifest files distributed alongside the CDs
[15:12] <lucas> cjwatson: thanks
[15:12] <tmmoyer> cjwatson: what about the user interaction.  I think i may have mis-spoken about "interaction" what i really mean is that the script just builds the binaries then the user has a list of commands to run to actually install the binaries
[15:12] <cjwatson> tmmoyer: even easier then
[15:13] <cjwatson> just have debian/rules copy stuff into the filesystem hierarchy (under debian/$PACKAGENAME/) as necessary
[15:13] <cjwatson> or use dh_install
[15:13] <tmmoyer> okay thanks... i will play around and see what I can come up wth
=== jamesh_ is now known as jamesh
[16:10] <bdmurray> pitti: thanks for letting me know about hal-ifno
[16:10] <pitti> bdmurray: you're welcome
[16:13] <tmmoyer> when a package uses autoconf and automake, is there a way to ensure that the generated Makefile installs to DESTDIR instead of / as instructed my dh_make
[16:18] <tmmoyer> nevermind after digging into the documentation a bit more, i found that automake respects DESTDIR staged installs
[16:22] <asac> bryce: could you follow up on bug 211569 (milestoned)
[16:22] <ubottu> Launchpad bug 211569 in hal "xsane won't start unless run as root (Epson Perfection 1240)" [Medium,Incomplete] https://launchpad.net/bugs/211569
[16:25] <bdmurray> pitti: some of the SRU verification for 8.04.1 requires a new iso correct?
[16:25] <pitti> bdmurray: right, the installer bits
[16:26] <bdmurray> pitti: rescue too - bug 218549
[16:26] <ubottu> Launchpad bug 218549 in rescue "Choosing "Reboot" in rescue menu jumps to main menu" [Medium,Fix committed] https://launchpad.net/bugs/218549
[16:26] <cjwatson> I was waiting until the kernel was definitely final
[16:26] <cjwatson> since it needs a debian-installer upload
[16:26] <pitti> linux -18 is around the corner
[16:27] <bdmurray> pitti: could / should we start identify those SRUs which require an ISO?
[16:27] <pitti> bdmurray: that's relatively easy
[16:28] <pochu> what's an ISO?
[16:28] <bdmurray> I was thinking something similar to hw-specific
[16:28] <pitti> bdmurray: apt-setup, base-installer, grub-installer, rescue
[16:28] <bdmurray> Is new CD image better?
[16:28] <pochu> ah, packages which go into the CDs :)
[16:28] <pochu> I thought it was another process
[16:29] <bdmurray> pitti: kickseed?
[16:30] <pitti> I'm not sure what this is about, but yes, it's a d-i module
[16:30] <cjwatson> kickseed will require it, yes
[16:30] <bdmurray> pitti: my concern is we have a list of 4 or 5 packages and a tag might be easier to track
[16:31] <bdmurray> cjwatson: speaking of bug 221501 doesn't have a test case
[16:31] <ubottu> Launchpad bug 221501 in kickseed "grub-installer failing on Hardy kickseed when "bootloader --md5pass" is set" [Medium,Fix committed] https://launchpad.net/bugs/221501
[16:33] <bryce> asac: ok
[16:40] <cjwatson> bdmurray: fixed
[16:41] <bdmurray> cjwatson: great thanks!
[16:50] <bdmurray> cjwatson: is bug 218975 still an issue for you?
[16:50] <ubottu> Launchpad bug 218975 in yelp "refuses to follow http: links from toc.xml" [Undecided,Incomplete] https://launchpad.net/bugs/218975
=== asac_ is now known as asac
[17:00] <cjwatson> bdmurray: will follow up on the bug
[17:00] <bdmurray> thanks
[17:07] <pitti> Keybuk: FYI, sysvinit merge upload now works fine; upload pending merge of devmapper, though, since it conflicts to the current version in intrepid
[17:08] <Keybuk> what changed in devmapper?
[17:08] <pitti> no idea, I didn't check that closely why it conflicts
[17:08] <pitti> Keybuk: Debian/upstream accepted two of our big patches, though \o/
[17:08] <pitti> unfortunately not the third one
[17:08]  * pitti sends some sysvinit patches Debianwards in the meantime
[17:09] <Keybuk> what was the third one?
[17:09] <pitti> +    - Call dmsetup from udev rules to name the device, so udev creates them
[17:09] <pitti> +      if they do not already exist, and fill in information about the
[17:09] <pitti> +      filesystem on the device afterwards.
[17:10] <pitti> +      (forwarded to Debian #455746)
[17:10] <ubottu> Debian bug 455746 in devmapper "udev support" [Wishlist,Open] http://bugs.debian.org/455746
[17:10] <pitti> they accepted the 'export' option and the 'create devices atomically' patches
[17:10] <Keybuk> heh
[17:10] <Keybuk> so the main patch, then ;)
[17:11] <Keybuk> did they use the same atomic patch as us?
[17:11] <Keybuk> upstream wailed like a bitch to me about that one
[17:11] <pitti> changelog says 'slightly modified'
[17:11] <Keybuk> *cough*
[17:11] <Keybuk> interdiff might be nice to see there ;)
[17:11]  * pitti just parrots the changelog, he didn't look at the patches at all
[17:12] <pitti> Keybuk: http://merges.ubuntu.com/d/devmapper/devmapper_2:1.02.25-1.patch :)
[17:12] <Keybuk> since I'm vaguely arguing that LVM-by-default is good, it might be nice to not break it
[17:12] <Keybuk> that is, until Casablanca happens
[17:12] <pitti> . o O { Casablanca? }
[17:13] <Keybuk> pitti: ZFS-in-Linux
[17:14] <Keybuk> patch looks ok
[17:14] <Keybuk> I think
[17:14] <Keybuk> by upstream you mean Debian, right? :)
[17:15] <pitti> some upstream, yes :)
[17:30] <norsetto> asac: any news about my last email?
[17:32] <pitti> Keybuk: is patches.ubuntu.com greppable somewhere? I'd like to know how many/which packages still use update-rc.d with 'multiuser'
[17:35] <smarter> multiuser is deprecated?
[17:59] <Keybuk> pitti: casey.ubuntu.com
=== sivan is now known as sivang
=== dmb_ is now known as dmb
[18:07]  * danshearer is away: whoops have to rush off home
[18:12] <pitti> Keybuk: ah, EPERM on that :/
[18:17] <Keybuk> pitti: -> elmo ;)
=== dwatson` is now known as dwatson
[18:33] <tmmoyer> where might I find information/source for the installer that handles bootloaders?  I would like to see how grub is installed and create a custom version that will installer TrustedGRUB from a package that I have created?
[18:37] <infinity> tmmoyer: apt-get source grub-installer
[18:51] <tmmoyer> thanks
[19:17] <ceekay> anyone able to point me in the direction of some documentation for kernel panic dumps in ubuntu? there seems to be evidence of some effort out there, but not a lot of "how to" papers, making me wonder if the implementation is complete
[19:54] <Keybuk> damn
[19:54] <Keybuk> where's cjwatson when you need him ;)
[19:54] <Keybuk> I have an obscure detail of the C language to ask him about
[19:55] <Robot101> Keybuk: try #d-uk? :)
=== smarter_ is now known as smarter
[20:28] <cjwatson> Keybuk: yo
[20:32] <Tm_T> evand: hi, you around?
[20:35] <evand> Tm_T: indeed
[20:36] <Tm_T> evand: hi, should I branch whole ubiquity or what? and, should it have branch in where in launchpad?
[20:36] <Tm_T> I'm bit new with this bzr and all
[20:36] <emgent> heya people
[20:37] <Tm_T> hmm, prolly whole ubiquity anyway
[20:38] <evand> Tm_T: you shouldn't need to branch ubiquity.  The migration-assistant code, with the exception of the UI, lives in http://bazaar.launchpad.net/~evand/migration-assistant/trunk, feel free to branch off of that (https://code.launchpad.net/migration-assistant)
[20:38] <Tm_T> thanks
[20:38] <Tm_T> local branch or should I push it to launchpad somewhere?
[20:39] <evand> please push it to LP
[20:39] <Tm_T> roger
[20:46] <Tm_T> evand: branch registered, I'll start pushing as soon as I get some real changes done
[20:47] <Tm_T> evand: thanks
[20:47] <evand> Tm_T: much appreciated
[20:48] <evand> feel free to bounce any questions you have off me
[20:48] <Tm_T> I will, don't worry ;)
[20:48] <evand> heh
[20:48]  * cody-somerville pokes evand in the tummy.
[20:49] <Tm_T> I'm moving to new home currently and other family issues AND school issues going on but I'll try to get this thing rolling
[20:50]  * evand doubles over, pokes cody-somerville back
[20:51] <evand> Tm_T: no worries, take your time
[20:51] <Tm_T> thanks sir
[20:55] <kees> soren: say, in your magic irssi/screen configs, is there a way to get the [Act: ] section to not overwrite the [N:#channel-name] section?  I can't always remember a channel based on the visible topic.  :P
[20:59] <Mithrandir> just have the channel name before the Act bit?
[20:59] <Mithrandir> like it is by default.
[21:00] <kees> Mithrandir: right, but when my Act section gets giant, it overwrites the channel name
[21:00] <Mithrandir> hm, it does?  I don't think it does for me.
[21:00] <Tm_T> Mithrandir: it does, when you have them enough
[21:00] <Tm_T> kees: you don't remember what channels you have in where? ;)
[21:01] <kees> alternatively, if Act didn't show join/part, that would work.
[21:01] <kees> Tm_T: I have a few that have very similar members and topics (ubuntu-server, ubuntu-devel, e.g.)
[21:01] <Tm_T> kees: same here
[21:02] <Tm_T> but meh, I'm used to live with ~50 channels
[21:02] <Mithrandir> kees: /set activity_hide_level ALL -PUBLIC -MSGS -DCCMSGS -HILIGHT -ACTIONS
[21:02] <kees> oooooh
[21:02] <Mithrandir> how do you survive with more than two channels and not having that set?
[21:02] <Tm_T> well
[21:02]  * cjwatson just ignores the grey ones
[21:02] <kees> precisely.  ;)
[21:03]  * Mithrandir likes M-a
[21:03] <kees> yeah, I'd generally ignore the grey ones, but I've got too many channels now thanks to bltbee+jabber
[21:04] <Lightkey> bitlbee?
[21:04] <kees> Lightkey: yeah.  typo on my part.
=== Adri2000_ is now known as Adri2000
[21:32] <Tm_T> evand: ok, for gui, what I should be looking at, ubiquity/trunk/ubiquity/components ? or frontend/ ?
[21:32] <cjwatson> the GUI code is in frontend
[21:33] <cjwatson> you may like to read doc/README
[21:33] <Tm_T> ah, thanks
[21:34] <cody-somerville> elmo, ping
[21:36] <Tm_T> cjwatson: FYI I'm trying to bring KDE love for migration-assistant :)
[21:36] <Tm_T> so you know who to bash and blame
[21:43] <cjwatson> Tm_T: been lacking for a long time, good luck
[21:43] <Tm_T> thanks
[21:56] <soren> kees: My prompt in irssi shows the channel name.
[21:56] <kees> soren: weird.  I wonder why mine over-writes when the Act list gets long.
[21:57] <soren> kees: Er... No.
[21:57] <soren> kees: I mean..
[21:57] <kees> soren: oh! the prompt.  right.
[21:57] <soren> kees: Hang on, I'll make a screenshot.
[21:57] <soren> kees: Oh, you got it :)
[21:57] <kees> I turned that off because I don't like it.  :)
[21:58] <soren> DDTT.
[21:58] <kees> hehe.  I guess I'll turn it back on.  ;)
[22:28] <munckfish> Is there a special LP tag for packages which require update to a new upstream version?
[22:28] <munckfish> I see 'update' is used but doesn't seem to have a standardised meaning
[22:28] <munckfish> I see 'needs-packaging' is standard for that situ
=== ScottK-uds is now known as ScottK2
[22:30] <cjwatson> munckfish: needs-packaging refers to initial packaging
[22:30] <munckfish> cjwatson: yes I understand that
[22:30] <cjwatson> i.e. new package needs to be packaged and introduced
[22:30] <munckfish> :)
[22:30] <cjwatson> ok
[22:30] <cjwatson> your comment was ambiguous, so :-)
[22:30] <munckfish> I was looking for the equivilent updates
[22:30] <cjwatson> I can't think of one
[22:31] <munckfish> cjwatson: ok that's my trade mark I guess :D
[22:31] <cjwatson> there may exist one, but it's managed to escape my attention if so
[22:31] <munckfish> ok np
[22:31] <ScottK2> I think it's upgrade
[22:31] <cjwatson> huh, ok
[22:32] <munckfish> ScottK: ok I'll look at that
[22:32] <ScottK2> Someone told me that.  Dunno if it's right.  I don't tend to follow such bugs very closely.
[22:32] <munckfish> does it not get abused for issues which relate to upgrading to a new OS version?
[22:33] <munckfish> anyway it doesn't matter too much I just want an easy way to refer to a list of such issues, 'update' will do.
[22:33] <munckfish> cjwatson: I see you're leading an initiative to reduce memory usage
[22:34] <munckfish> do you have any estimate how successful that's likely to be?
[22:34] <munckfish> Or any target?
[22:36] <ScottK2> cjwatson: You wanted ubuntu-devel revitilized, IIRC.  Are you feeling the volume is high enough the last couple of days? ;-)
[22:36] <mdke> I have been thinking that ubuntu-devel was a bit quiet over the last few months too
[22:37] <mdke> now it's looking great :)
[22:38] <cjwatson> ScottK2: *cough*
[22:38] <cjwatson> now I just need to find time to finish off the things I want to drop on it
[22:38] <cjwatson> munckfish: not sure I want to give a target at this point
[22:38] <ScottK2> Excellent.  People should be paying attention now.
[22:38] <cjwatson> well, I definitely want to get the live CDs back under 256MB
[22:38] <cjwatson> I hope we can get further but I don't have a figure
[22:40] <munckfish> cjwatson: well I'm certainly interested from a PS3 point-of-view it'd be great to be able to run LiveCD on PS3, and now there's this ps3vram driver upstream
[22:40] <munckfish> which unlocks the vram as swap, it's all looking quite bright and hopeful IMO
[22:41] <cjwatson> munckfish: oh, that would be good
[22:41] <cjwatson> you used to be able to run the live CD on PS3 at least, though it was always very slow
[22:42] <munckfish> yeah it unlocks roughly 256MB - FB size for use as swap
[22:59] <tormod> looking forward to seeing applets like update-manager use less than 100MB
[22:59] <pochu> update-notifier you mean?
[23:00] <tormod> pochu: no, that one uses only 32MB to show an icon
[23:00] <pochu> there was a memory leak in update-notifier, should be fixed now AFAIK
[23:06] <tormod> I don't think it's all leaks, but the problem is some developers think 32MB is reasonable.
[23:06] <pochu> update-notifier is using 4.5 MB
[23:06] <pochu> 00:06:35 up 14:10,
[23:06] <pochu> and I've never seen it grow up
[23:07] <pochu> same for update-manager
[23:12] <tormod> pochu: how do you measure it?
[23:12] <Amaranth> pochu: it'd probably be like 1MB if it was written in C though :P
[23:13] <Amaranth> tormod: don't read RSS, it lies to you
[23:13] <Amaranth> my update-notifier is actually only using 1.5MB
[23:13] <pochu> tormod: "memory" column in gnome-system-monitor
[23:13] <Amaranth> 17:13:41 up 1 day,  1:26
[23:14] <Amaranth> pochu: why does yours use more than mine?
[23:15] <soren> pochu: Quick! Say: "Because mine is bigger than yours."
[23:15] <soren> It'll be fun!
[23:15]  * Amaranth wonders why devhelp needs 50MB
[23:15] <pochu> lol
[23:15] <Amaranth> oh yeah, gecko
[23:15]  * pochu waits for the webkit massive transition
[23:16] <Amaranth> not sure why they use gecko, gtkhtml is more than enough for the simple html it uses
[23:16] <Keybuk> gtkhtml is a bit ... crufty though
[23:16] <Amaranth> Keybuk: gecko is worse
[23:16] <Amaranth> gecko is always worse
[23:17] <Keybuk> well, yes
[23:17] <Keybuk> webkit is better
[23:17] <Amaranth> but then we have two engines in main
[23:17] <Amaranth> wait, we already have khtml in there
[23:17] <Amaranth> so three
[23:18] <tormod> ok, update-manager is "only" 62MB and update-notifier 4.9MB. tell me that is needed :)
[23:18] <pochu> update-manager shouldn't be running unless you are updating something
[23:19] <tormod> pochu: sure it's just an example of basic applications. now add firefox...
[23:19] <Keybuk> update-notifier should only run to check, the notification should stay after it exists
[23:19] <Keybuk> but that's a design flaw in GNOME :)
[23:20] <sharms> update-manager for me is at 69MB, update-notifier is at 14MB for RSS
[23:20] <Amaranth> sharms: RSS is pretty worthless
[23:20] <sharms> Amaranth: which stat would you compare then?
[23:21] <Amaranth> private rss + shared rss / number of apps sharing it would be ideal, i think
[23:22] <sharms> is there a program that does that already or a pretty awk line or some common method that I am missing?
[23:22] <Amaranth> otherwise you count every library for every app that uses it even if they share most of the cost
[23:22] <Amaranth> gnome-system-monitor does that
[23:22] <sharms> anything from console?
[23:22] <Amaranth> don't think so
[23:23] <Amaranth> why would people only using console care about memory usage other than "how much do I have left?" :)
[23:24] <sharms> I don't really care, just for arguments sake I would like to have accurate numbers
[23:25] <ion_> Substitute console for a terminal, and it would become useful. :-)
[23:25] <ion_> s/for/with/