[01:42] <mekius> on the live cd, it starts up with a boot menu, is there anyway to change the background of this?  what files do i need to unpack/edit/etc?
[02:50] <wasabi> Blah. New kernel has also caused my bcm to be unable to scan/connect to anything.
[07:45] <pitti> Good morning
[07:45] <StevenK> Morning pitti
[07:46] <StevenK> pitti: Most of the boost stuff has been sorted out - schroot fails to build, which has been fixed in Debian, and there are no Ubuntu changes. Would you mind sync'ing it? (It's a -1 to -1.1 jump)
[07:46] <pitti> StevenK: not at all, doing
[07:47] <StevenK> The other is sfftobmp, which is maintained by doko_
[07:50] <pitti> StevenK: does that mean 'please sync it'?
[07:51] <StevenK> pitti: sfftobmp? No, it's unchanged in Debian.
[07:51] <StevenK> pitti: It means I need to talk to doko_. :-)
[08:02] <desertc> What do you think - Is Valve bringing their Steam Engine to Linux?
[08:02] <desertc> http://www.valvesoftware.com/job-SenSoftEngineer.html
[08:15] <maikmerten> nope, looks more like server backend, not client
[08:16] <maikmerten> Oh, missed "Port Windows-based games to the Linux platform."
[08:16] <desertc> Yes, was just going to point it out.  I was thinking servers, too, when I first saw it.
[08:17] <desertc> It would be interesting, I think, for Ubuntu, if there was Steam Engine for Linux.  It is a very popular commercial software distribution system.
[08:17] <maikmerten> OTOH they may only want to port the server part of Windows games to Linux
[08:17] <YokoZar_> steam runs perfectly in Wine desertc
[08:18] <desertc> But that is not a supported solution.
[08:19] <YokoZar_> Well having a supported version of Wine would be.  Then it'd be trivially easy to support, especially compared with rewriting the whole thing using another software library
[08:19] <keescook> I must be up too late!  good morning pitti!  :)
[08:19] <YokoZar_> Not to mention most of the steam apps use Windows only stuff (eg Direct X) that requires Wine
[08:20] <YokoZar_> So unless they're going to rewrite everything, they'll have to rely on Wine at some point.
[08:20] <pitti> hey keescook!
[08:21] <desertc> YokoZar_, That supported "wine+WinApp" is the path the game EveOnline is taking.
[08:21] <keescook> pitti: I've got a cupsys that just built with some minor changes to the profile (use @{PROC} @{HOME}), if you don't anything anything about to go in, I can go ahead and upload it.
[08:21] <YokoZar_> Which is why Wine should make a 1.0 release, and why we should include it with Hardy.  That way Valve can just say "use Ubuntu Hardy or later" rather than, say, "use a version of Wine greater than 0.9.44, except 0.9.48 and 0.9.52 which have regressions)
[08:22] <YokoZar_> desertc: It's also what Google did with Picassa.  They just bundled a copy of Wine with Picassa, and targetted that directly
[08:22] <pitti> keescook: sure; please send me a debdiff, though, so that I can commit it to the bzr/svn
[08:22] <YokoZar_> desertc: if we, at the distribution level, support a Wine version, then ISVs won't need to go through all that hassle.  And, let's be honest, almost no one knows that much about Wine, especially Windows people.
[08:23] <desertc> YokoZar_, That is an option - I will grant you that.  I think it is in Free Software's best interest (and Ubuntu's) to have commercial companies supporting real-Linux solutions, because they will be compelled to work with the community.
[08:24] <desertc> I do not think simply getting a Windows app running on Linux through Wine gets much for the community in the long run, even if it is another application that runs on Linux in the short-term.
[08:24] <YokoZar_> Valve is as close to a Microsoft shop as you can get.  They do everything in Direct X, and Gabe Newell actually worked for MS.  Even still, they have quite literally tens of thousands of users using Wine.
[08:25] <YokoZar_> What difference does it make if an ISV makes a proprietary app for Linux that works via Wine or a proprietary app that works via SDL?  The app is still proprietary, and the library is still free.
[08:26] <YokoZar_> This is especially irrelevant with full screen games, where we don't even have to worry about look and feel matching
[08:26] <desertc> I think that companies that use SDL help improve SDL.  Also, companies that work with the Linux community, tend to give back to the community by opening their code - a new library or a software engine.
[08:27] <YokoZar_> Well, Google helped improve Wine in much the same way.
[08:27] <pitti> keescook: I have a pending fix in svn, though
[08:28] <YokoZar_> desertc: I think that tendency isn't because they're apps work on Linux, it's because community-minded companies make Linux apps.  I don't see Valve opening anything, even if everything worked on Linux perfectly.
[08:29] <keescook> pitti: doh, I just sent and uploaded.
[08:29] <pitti> keescook: that's fine, thanks
[08:30] <YokoZar_> desertc: Still, you raise an interesting question about short and long term consequences.  Do you think that more Linux users is good for Linux in the long run, even if they're using Wine for some of their apps?
[08:30] <desertc> I don't agree with you on that point.  Valve may not open something today, but if that engineer they are hiring is a FOSS developer, then he will be in a position to effect the Valve decisions one day.  Maybe 5 years from now Valve will make a valuable contribution to FOSS because of it.  If they chose to simply use Wine, then there would be assuredly be no such contributions.
[08:31] <desertc> Now I have to run, too late for me here.  Night!
[08:31] <desertc> Thanks for your thoughts, YokoZar_
[08:32] <kagou> good morning
[08:39] <StevenK> pitti: Can I convince you to look at a few things in the NEW queue?
[08:40] <pitti> StevenK: you can
[08:40] <StevenK> pitti: virtualbox-ose, which has had it's DFSG and maintainer troubles sorted out, and kompozer because tonyyarusso is getting begged by users.
[09:00] <pitti> \sh_away: erk, I forgot to build the new CD images for you, I was distracted with some phone conf calls yesterday, sorry; were this morning's images enough for testing?
[09:05] <dholbach> good morning
[09:12] <mdke> morning dholbach
[09:13] <dholbach> hey mdke
[09:14] <mdke> dholbach: do I have to do the version number for gnome-user-docs manually? I had been under the impression it was generating it automatically when i did "dch -i"
[09:14] <dholbach> no, it just increments the last numerical part of the version number
[09:14] <mdke> dholbach: aha. Ok i'll do that now
[09:14] <dholbach> you imported new stuff from upstream, so you have to bump it manually
[09:14] <dholbach> thanks a lot
[09:15] <dholbach> I'm looking through the sponsoring queue at the moment, so I'll notice, once you've changed the bug
[09:15] <mdke> dholbach: pushed. I also merged again from upstream (changes to one po file), do I need to do a new debdiff?
[09:15] <doko> pitti: please demote db =)
[09:15] <dholbach> mdke: no, not necessary
[09:16] <dholbach> mdke: I'll look at the bug again
[09:16] <pitti> doko: \o/
[09:17] <mdke> dholbach: thanks
[09:17] <dholbach> mdke: rock on :)
[09:17] <dholbach> mdke: I'll change it to ubuntu1
[09:18] <dholbach> mdke: or do you want to do it?
[09:19] <mdke> oh damn. Feel free to do it and I'll do it in the branch
[09:19] <dholbach> ok, I'll push it to my fixes branch
[09:19] <mdke> dholbach: I already pushed
[09:19] <dholbach> ok great
[09:20] <dholbach> doing a test build
[09:20] <mdke> thanks dude
[09:20] <dholbach> de rien
[09:20] <dholbach> hum, it should be 20070912, sorry for being picky
[09:21] <dholbach> I'll push it to my branch later on, so you can simply merge from there
[09:23] <mdke> dholbach: i think 13 works
[09:23] <mdke> that's today
[09:24] <dholbach> 12 was the last commit upstream
[09:24] <mdke> dholbach: true, but the merge was done today, so it's in sync with today's svn
[09:24] <mdke> I don't mind if you change it though
[09:25] <mdke> hi Hobbsee
[09:25] <dholbach> ok, I'm happy with both - it's just the sniplet I added at the end of the build checks the last note in 'ChangeLog'
[09:25] <dholbach> hey Hobbsee
[09:26] <mdke> oh i see, ok
[09:26] <dholbach> mdke: I'll also add a (LP: #12345) to automatically close the bug you opened
[09:26] <mdke> oh wow, that's cool
[09:28] <MacSlow> Greetings everybody!
[09:28] <dholbach> hey bigon
[09:28] <bigon> dholbach: hi :)
[09:28] <dholbach> bigon: do you think we should have something like http://wiki.ubuntu.com/DesktopTeam/TODO for the ubuntu telepathy team?
[09:29] <Hobbsee> asac: it's not NM mangling (from yesterday).  it's that the Uni IT department sucks, and cant make their connection work :)
[09:29] <MacSlow> hi Hobbsee
[09:30] <dholbach> bigon: I know that the telepathy todo list wouldn't get that full, but maybe we could attract some new followers for the team :)
[09:30] <dholbach> bigon: I know of at least 4 packages we should get in also (for hardy) :)
[09:31] <dholbach> mdke: pushed to my branch, uploading the package now
[09:32] <dholbach> (still pushing...)
[09:32] <bigon> dholbach: yep a todolist is maybe a good idea :)
[09:32] <bigon> dholbach: which packages?
[09:33] <dholbach> bigon: CupsAndString 0.1, soylent 0.1.0, banter 0.1.10, decibel 0.5.0
[09:33] <dholbach> bigon: I'll create that wiki page
[09:36] <pitti> calc: still here by chance?
[09:36] <pitti> doko: the CDs recently exploded because java-gcj-compat was added (which pulls in libgcj8-jar); any idea why?
[09:37] <\sh> cjwatson, pitti: the daily i386 iso from this morning (what I need to test) is oversized
[09:37] <pitti> \sh: right, see above ^; just trying to figure out the reason
[09:38] <doko> pitti: didn't look, but probably OOo now depends on java-gcj-compat instead of gij ?
[09:38] <pitti> yeah, it's most certainly due to OO.o
[09:38] <\sh> pitti, yepp, just wanted to tell you that I can't test or I'm trying to get an 800MB blank media, which is quite impossible here
[09:38] <bigon> dholbach: I've already made a package for soylent but I never upload it because It think soylent need a bit more work before be really usable
[09:38] <dholbach> nice
[09:39] <dholbach> but that's a good start
[09:39] <asac> Hobbsee: good ... thanks ;)
[09:40] <Hobbsee> asac: :)
[09:41] <Lure> pitti: morning
[09:42] <pitti> doko: ah, indeed; most apps still prefer gij, but -officebean pulls it in
[09:42] <Lure> pitti: we got bug fix for canon second try problem and it "works for me", just need confirmation from allee if it helps him too
[09:42] <pitti> Lure: ah, good!
[09:42] <Lure> pitti: have sent mail to kubuntu-devel@/ubuntu-devel-discuss@ for wider testing
[09:43] <Lure> pitti: if you have time, it would be good to review merge I did -> it is in my ppa
[09:43] <doko> calc: pretty please, merge new stuff from debian, don't reapply all ubuntu changes on each merge ...
[09:44] <doko> pitti: is officebean really on the cd?
[09:45] <pitti> doko: yes, it's also a new package on CD
[09:45] <pitti> doko: got introduced on image 20070912
[09:45] <Kmos> edge is not working for apport
[09:45] <Kmos> LP beta :-(
[09:46] <dholbach> the new pylpbugs knows how to work with edge - pitti: maybe you need to update the cookie?
[09:46] <pitti> dholbach: how so? the apport retracer bot user is not in -beta-testers, so it uses the normal lp
[09:47] <dholbach> oh ok
[09:49] <pitti> doko, calc: bug 139309
[09:49] <Ubotu> Launchpad bug 139309 in openoffice.org "Please drop -officebean dependency" [High,New]  https://launchpad.net/bugs/139309
[09:50] <pitti> Kmos: you mean on the client side? do you have the very latest python-launchpad-bugs?
[09:51] <Kmos> pitti: i've my system updated
[09:51] <Kmos> pitti: the one changed by dholbach yes
[09:55] <StevenK> doko: sfftobmp in Debian doesn't build with the new boost, would you like me to NMU it and then get it sync'd?
[09:55] <doko> StevenK: go ahead
[09:58] <asac> StevenK: hey ... did you upload gnash?
[09:59] <doko> mvo: the command-no-found bugs ... I suppose a rebuild of the database would help
[10:00] <StevenK> asac: Yes, yes, I did.
[10:01] <asac> StevenK: why don't you stop when you see something like: Xs-Vcs-Bzr: http://bazaar.launchpad.net/~ubuntu-core-dev/gnash/ubuntu
[10:01] <StevenK> asac: I only realised that was a bad move *after* it hit upload.u.c. I'm so sorry.
[10:01] <asac> ok
[10:02] <siretart> is patches.ubuntu.com currently disabled? or is it a temporary problem wrt processing new uploads?
[10:02] <StevenK> asac: It was only a changelog entry, which I can commit and push to that branch when I get home, if you wish?
[10:03] <asac> StevenK: no its ok ... will do it
[10:03] <asac> StevenK: if I have questions, I let you know :)
[10:03] <StevenK> asac: Okay. Sorry for the trouble.
[10:03] <asac> np
[10:05] <Kmos> pitti: i got the OOPS-621EC17 when tried to report the bug.. after I click on "Continue" on Edge (Beta)
[10:05] <Kmos> always got timeout and OOPS
[10:05] <pitti> Kmos: ah, LP bug then
[10:08] <Kmos> i've some packages to report :-(
[10:10] <Kmos> pitti: https://edge.launchpad.net/ubuntu/+source/flashplugin-nonfree/+filebug/rja7OGcXmR2N7PDRI9OX8izu2pu
[10:10] <Kmos> this is the url
[10:11] <pitti> Kmos: hm, that works for me
[10:13] <Kmos> pitti: you clicked on continue
[10:13] <pitti> no
[10:14] <Kmos> try to do it
[10:15] <pitti> Kmos: works
[10:15] <pitti> Kmos: but I won't actually file the bug since I don't have a good subject/description
[10:16] <Kmos> ok
[10:16] <Kmos> strange to not work here
[10:16] <Kmos> pitti: you're in LP beta right?
[10:16] <pitti> yes
[10:16] <Kmos> https://bugs.edge.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/139255
[10:16] <Ubotu> Launchpad bug 139255 in flashplugin-nonfree "package flashplugin-nonfree 9.0.48.0.0ubuntu9 failed to install/upgrade: " [Undecided,New] 
[10:16] <Kmos> it's already reported
[10:19] <asac> Kmos: can you please attach more info to that bug?
[10:19] <Kmos> asac: sure
[10:19] <doko> pitti, calc: lapack3 and refblas3 were pulled in as well (we might want to build with the internal sp-solve again)
[10:19] <Kmos> do you want my crash report ?
[10:20] <asac> Kmos: well ... the report claims that flash cannot be installed ... if that is not your problem then I misunderstood :)
[10:20] <Kmos> asac: yes, it's also my problem
[10:21] <pitti> StevenK: kompozer? Oh noes, yet another mozilla tree copy?
[10:21] <pitti> those recently fork like hell
[10:22] <asac> Kmos: please add that info
[10:22] <Kmos> asac: done
[10:23] <Kmos> pitti: it's a newer nvu.. like bugs fixed
[10:23] <asac> Kmos: i don't understand ... do you get that crash report while installing?
[10:24] <asac> Kmos: further, the initial reporter mentions a md5sum mismatch
[10:24] <Kmos> asac: upgrading
[10:24] <tonyyarusso> pitti: Well, at least this one is replacing a package rather than adding one (as nvu was dropped from the repos for feisty)
[10:24] <Kmos> asac: that tried after to install
[10:24] <pitti> why can't packages like this build against firefox-dev or so?
[10:25] <asac> Mithrandir: bug 139255 .... you forgot to take care that the midbrowser dir exists ;)
[10:25] <Ubotu> Launchpad bug 139255 in flashplugin-nonfree "package flashplugin-nonfree 9.0.48.0.0ubuntu9 failed to install/upgrade: " [Undecided,New]  https://launchpad.net/bugs/139255
[10:25] <tonyyarusso> I'm not sure...I'll need to ask about that
[10:25] <asac> pitti: this discussion is (as always) really fruitless
[10:25] <asac> pitti: we have xulrunner 1.9 in mozillateam archive ... before that you cannot do such things with mozilla trees ;)
[10:25] <pitti> tonyyarusso: (it won't work, don't worry; that's an upstream problem)
[10:26] <tonyyarusso> pitti: (ah, phooey)
[10:26] <Kmos> asac: so, i've clarified the bug ? =)
[10:26] <asac> Kmos: i don't see how the crash is related ... but otherwise yes.
[10:27] <Kmos> update-alternatives: unable to make /usr/lib/midbrowser/plugins/flashplugin-alternative.so.dpkg-tmp a symlink to /etc/alternatives/midbrowser-flashplugin: No such file or directory
[10:27] <Kmos> this is one bug
[10:27] <Kmos> maybe fir it
[10:27] <Kmos> fix it
[10:27] <pitti> it is apparently possible for epiphany or galeon
[10:27] <asac> pitti: thats not a xul application
[10:27] <asac> pitti: those are just gtkzmozembedders ;)
[10:27] <pitti> ah, ok
[10:28] <asac> anyway kompozer is even from the 1.7 branch
[10:28] <asac> i'll leave it to the reader to figure out what that means :)
[10:29] <pitti> asac: stuck with obsolete code which is full of known security holes?
[10:29] <Kmos> http://www.aptana.org/
[10:29] <Kmos> it's better to have this one
[10:29] <Kmos> than kompozer
[10:30] <asac> pitti: yeah ;) ... though kompozer doesn't really do remote stuff as a main use-case ... so the severity might be different.
[10:30] <pitti> asac: you mean if it contains remote images or other remote content in a HTML page, it won't fetch and display them?
[10:34] <asac> pitti: i am not sure ... but I would think it will
[10:40] <asac> pitti: so yes ... you probably can trick users into executing local code by sending a specially crafted html page and ask him to open it in kompozer ... but you could do that with python and other scripts as well ;)
[10:41] <asac> pitti: but i see the difference ;)
[10:55] <zyga> doko: why did you move #135794 back to c-n-f?
[10:58] <doko> zyga: bash.bashrc references /usr/lib/command-not-found, which is found in the current package. where is the problem?
[11:01] <pitti> sjoerd: got a minute to talk about bug 118919? would it be fine for you to move dbus-launch to dbus proper, and have only the Xsession.d script in dbus-x11?
[11:01] <Ubotu> Launchpad bug 118919 in dbus "dbus-launch does not exist in dbus" [High,Confirmed]  https://launchpad.net/bugs/118919
[11:01] <zyga> doko: oh? then the bug is fixed
[11:01] <zyga> doko: sorry for not checking this
[11:02] <dholbach> calc: can you take a look at bug 135086? :)
[11:02] <Ubotu> Launchpad bug 135086 in unzip "zipgrep: exit code always 0" [Medium,Triaged]  https://launchpad.net/bugs/135086
[11:10] <Hobbsee> dholbach: do you know who could tell me about the purpose of gparted-disable-automount.fdi ?
[11:10] <dholbach> dholbach: no idea - maybe people in #gparted on irc.gnome.org?
[11:10] <pitti> dholbach, Hobbsee: I recently disabled automounting of fixed disks in hal, so that patch might be obsolete
[11:11] <dholbach> pitti: I didn't touch gparted for ages
[11:11] <Hobbsee> pitti: right.  because, obviously, it's breaking automounting - completely.
[11:11] <pitti> Hobbsee: sounds like it would inhibit gnome-volume-manger and the KDE pendant from automatically  mounting newly craeted partitions while you work with them in gparted?
[11:11] <pitti> Hobbsee: can you put that file somewhere?
[11:11] <Hobbsee> pitti: ahhh.  right.
[11:12] <Hobbsee> pitti: no, sorry, i rm'd it, and had everything automount properly again.
[11:12] <Hobbsee> i was *wondering* why my SD card wouldnt automount, at all.
[11:12] <Hobbsee> nor my USB stick
[11:12] <pitti> Hobbsee: sounds like it should be kicked then :)
[11:12] <Hobbsee> sure enough, with that removed, it all works fine, and i dont have to mount via the command line anymore
[11:13] <pitti> Hobbsee: I guess it did a blunt volume.ignore=True for all volumes or so
[11:13] <Hobbsee> pitti: i wanted to know why it was actually there, before killing it :P
[11:13] <Hobbsee> right
[11:13] <Hobbsee> OTOH, do i *really* want to touch hal?
[11:14] <pitti> Hobbsee: why would you?
[11:15] <Hobbsee> pitti: i thought that patch was in the hal source.
[11:15] <pitti> blimey, no
[11:15] <pitti> Hobbsee: gparted probably
[11:18] <Hobbsee> oh, hmm.
[11:22] <allee> Hi Pitti, looks like the latest python db4,5/4.6 broke apt-listchanges.  bug 139259
[11:22] <Ubotu> Launchpad bug 139259 in apt-listchanges "apt-listchanges crashed with DBInvalidArgError in hashopen()" [Undecided,New]  https://launchpad.net/bugs/139259
[11:37] <DktrKranz> pitti: when have time, could you please check bug 130059 ?
[11:37] <Ubotu> Launchpad bug 130059 in plr "[SRU]  R_HOME environmental variable not set" [Medium,In progress]  https://launchpad.net/bugs/130059
[11:38] <Moniker42> hey, i wouldn't normally come to the dev channel looking for support - but i have a SATA drive that works perfectly well in ubuntu but isn't detected by the BIOS and breaks the Windows XP install disc (doesn't get to bluescreen / asking for SATA drivers even)
[11:38] <Moniker42> it's stumped everyone i've asked...
[11:39] <pitti> DktrKranz: bug updated
[11:42] <DktrKranz> thabks
[11:42] <DktrKranz> *thanks
[11:44] <sjoerd> pitti: What we want to do at some point is to have a dbus-launch without X11 deps in dbus proper and have dbus-x11 have a dbus-launch-x11 variant
[11:45] <sjoerd> pitti: dbus-x11 is useless if you have the dbus-launch depending on x11 in it :)
[11:46] <pitti> sjoerd: hm; well, the benefit of dbus-x11 for me was to get rid of that Xsession.d script
[11:47] <sjoerd> Heh, no the Xsession.d is what you want on every desktop
[11:47] <sjoerd> What you want to get rid of is the x11 depends for headless machines running dbus
[12:05] <pitti> bryce: FYI, I just sponsored a new -amd for Q-FUNK to Debian; we might want to sync that
[12:20] <StevenK> pitti: So it would seem - why kompozer seems fit to include a mozilla source tree is beyond me.
[12:20] <StevenK> doko: Do you have any preference if I use dpatch, or would you rather I edited the source files directly for sfftobmp?
[12:21] <doko> StevenK: I don't care for that package
[12:30] <mvo> hey mjg59! thanks for your compiz upload. do you want me to add you to the compiz-packagers team so that you can directly commit uploads to our bzr repository?
[12:31] <sladen> mvo: he's asleep.  ati, specs, avivo etc
[12:31] <mvo> oh, right
[12:47] <mjg59> mvo: Yeah, that'd be helpful.
[12:49] <mvo> mjg59: cool, I do that now. is it all rs480 chips that give trouble? I have three pci ids for it (one is the rs480m)
[12:50] <xhaker> mvo, i think i have one rs480, those are ati  xpress 1100
[12:50] <xhaker> mvo, right?
[12:51] <mvo> xhaker: it seems to be. does it give you trouble with compiz?
[12:52] <Amaranth> mjg59: What was the problem?
[12:52] <Amaranth> Maybe we can detect it another way
[12:52] <xhaker> mvo, i haven't tried. it shouldn't work anyway, i hear that there are some problems because it doesn't use direct memory, and shared instead
[12:53] <Amaranth> Although I suppose we'll need pciid blacklisting for intel
[12:54] <Mirv> cjwatson: are you sure gutsy installer strings are exported to rosetta correctly? carlos now made an import that added ca. 100 strings, but they were almost all related to Mythbuntu. using the 20070913 live image all the problems in bug 132157 are still there.
[12:54] <Ubotu> Launchpad bug 132157 in ubiquity "Untranslated strings in gutsy installer" [Undecided,New]  https://launchpad.net/bugs/132157
[12:55] <carlos> Mirv, cjwatson: I got it from http://people.ubuntu.com/~cjwatson/installer-po/
[12:56] <mvo> Amaranth: do you know any specifc one to blacklist?
[12:56] <Amaranth> no
[12:56] <Amaranth> and for intel we could actually do something other than pciid blacklisting
[12:57] <Amaranth> if intel and only texture xv output: no compiz
[12:59] <Mirv> cjwatson/carlos: those do seem to have at least many of the texts that are currently not translated. besides some bug in installer the only other option I can think of is that the places for strings were changed, but the strings themselves stayed the same from feisty, so no new untranslated strings came to Rosetta but getting the updated files from Rosetta now to installer would fix the translations. though it would probably still leave th
[01:00] <xhaker> mvo, nvm what i said earlier about the shared memory on rs480, didn't notice the newer version on the repos of the ati driver
[01:07] <mjg59> Amaranth: compiz kills rs480 immediately
[01:08] <tepsipakki> mjg59: so now that I've been running it happily on my r200 it refuses to start after an update?
[01:11] <mjg59> tepsipakki: Yes. I blacklisted it on ati, because we currently have no mechanism for more fine-grained control.
[01:12] <tepsipakki> mjg59: do you have such card?
[01:12] <tepsipakki> I mean, have you tried with a newer driver..
[01:13] <tepsipakki> ..which is now in UVF queue
[01:13] <mvo> mjg59, tepsipakki: I just added pciid backlisting, so the next version wil be happy again
[01:13] <mjg59> tepsipakki: This was with current git head, and it was Dave Airlie who was complaining about it
[01:13] <tepsipakki> mjg59: right :)
[01:13] <tepsipakki> mvo: excellent, thanks
[01:13] <mjg59> mvo: Excellent, that sounds like it'll work nicely
[01:14] <mjg59> mvo: Do you want me to dig out the set of PCI IDs? I can't remember whether there's more than one that fall into that class
[01:14] <mvo> mjg59: I wonder if we should also blacklist i965 under intel if video does not work there
[01:14] <mjg59> mvo: Probably, yes
[01:14] <mvo> mjg59: I added three (took them from the ati website) rv480,rv480 andd rv480m
[01:14] <mjg59> But it worries me a great deal that we didn't seem to have bug reports on this
[01:15] <mvo> mjg59: I assume you have a machine where the error shows?
[01:15] <xhaker> mjg59, it's probably because the people with this card are used to install fglrx
[01:15] <mjg59> xhaker: Currently there's no way to do that, given that X exits immediately
[01:15] <xhaker> mjg59, this card didn't have acceleration without it
[01:15] <mjg59> mvo: Yes
[01:16] <mvo> (ids: 1002:{5954,5854,5955})
[01:16] <mvo> mjg59: what does happen? black window? crash?
[01:16] <mjg59> mvo: Instant crash
[01:16] <mvo> *ick*
[01:17] <mjg59> But there's a large number of people with this hardware, and nobody complaining loudly, which makes me worry that basically nobody is testing this (or nobody expects it to work if they are)
[01:18] <xhaker> mjg59, is that card supposed to have direct rendering ?
[01:18] <xhaker> i'm testing it right now
[01:18] <mjg59> xhaker: Yes
[01:20] <mvo> mjg59: if that is true, then this would be very bad. I think we need to make very clear in the that all compiz bugs should be reported so that we get a more accurate picture. maybe a blog post or a mail to ubuntu-devel-announce?
[01:20] <mjg59> mvo: Yeah
[01:23] <xhaker> mjg59, i'm always getting direct rendering: No with the ati driver
[01:23] <mjg59> xhaker: I'd file a bug, then. Might just be a missing ID.
[01:24] <xhaker> hmm.. with LIBGL_DEBUG= verbose "unable to find driver: r300_dri.so"
[01:24] <Mirv> ah, the 20070913 installer I'm running is now at 122%, interesting :D
[01:24] <Mirv> hmm now it crashed, but I think it's the corrupt CD anyway, since I forcily wrote 716MB
[01:25] <mjg59> xhaker: Do you have libgl1-mesa-dri installed?
[01:25] <xhaker> mjg59, yes.. it's there.. 7.0.1-1...
[01:26] <ogra> Mirv, take a DVDRW or 800MB CD for the oversized images
[01:26] <tepsipakki> xhaker: you have /usr/lib/dri/r300_dri.so?
[01:27] <mjg59> xhaker: Mine contains /usr/lib/r300_dri.so
[01:27] <mjg59> Sorry, /usr/lib/dri
[01:27] <Mirv> ogra: yep, it's just that my only DVDRW drive doesn't work in linux for writing anything :( (Plextor PX-755SA SATA drive)
[01:28] <ogra> gah, thats bad indeed
[01:30] <xhaker> tepsipakki, mjg59: it's there.. reading more carefully.. "dlopen... failed... undefined symbol.. _glapi_get_dispatch
[01:30] <mjg59> xhaker: Do you have the fglrx libGL installed?
[01:31] <StevenK> doko: Do you want to a see a debdiff for sfftobmp?
[01:31] <xhaker> mjg59, yes.. that might be it.. should i update alternatives?
[01:32] <tepsipakki> xhaker: just purge fglrx
[01:32] <mjg59> xhaker: Yes
[01:32] <Mirv> xhaker: fglrx diverts the correct libGL and breaks non-fglrx
[01:32] <tepsipakki> the mother of all evil (=bugs :)
[01:36] <xhaker> mjg59, confirmed. it crashes.. even though i think this is progress.. it has direct rendering now.. :)
[02:03] <hunger> Hmmm.... this output from aptitude is unexpected: "Removing linux-ubuntu-modules-2.6.22-9-generic ..." followed by "update-initramfs: Generating /boot/initrd.img-2.6.22-9-generic".
[02:05] <StevenK> hunger: Which means /lib/modules/2.6.22-9-generic still exists
[02:06] <hunger> StevenK: Those lines happend one after the other. Once aptitude is done the initrd is properly removed.
[02:07] <StevenK> hunger: So ubuntu-modules got removed, but the linux-image was still installed?
[02:08] <hunger> StevenK: Oh, forget it. I overlooked the modules in the first line.
[02:13] <pitti> bryce: hm, today's live CD has ridiculously large fonts; is that due to the DPI now being fixed to 100 in the X server?
[02:13] <pitti> bryce: not sure what the default was in feisty, but maybe more like 85?
[02:16] <Seveas> pitti, 96 is default -- on new installs it's set to 126 in gnome
[02:16] <Seveas> annoying :)
[02:16] <pitti> ah, that might be it, too
[02:16] <Seveas> even on upgrades from feisty to gutsy it's set to 126
[02:21] <ogra> Seveas, thats progress :) we expect users to have at least 30" displays now :P
[02:21] <Seveas> hehe
[02:22] <Seveas> it was annoing on 1024x768
[02:22] <StevenK> ogra: I'll use one if you provide it
[02:22] <ogra> heh
[02:22] <ogra> i need my TV :)
[02:22] <Seveas> the 'Advanced' button in the font properties thing was invisible
[02:22] <Seveas> so I couldn't change it!
[02:22] <pitti> ogra: but those usually have a lower DPI than those tiny 11" laptop screens, don't they?
[02:22] <ogra> pitti, higher imho
[02:23] <pitti> ogra: 30" on 150 dpi? that's like 3000x2500 pixels...
[02:23] <Seveas> yummy
[02:23] <ogra> yeah :) crisp
[02:23] <Seveas> I could live with that resolution :)
[02:23] <pitti> but such high DPIs strain your eyes to the max...
[02:24] <hunger> pitti: They do?!
[02:24] <hunger> pitti: Fonts just look better with a higher DPI here.
[02:24] <ogra> yeah
[02:24] <pitti> hunger: well, sure, if you scale everything up, but then it's quite moot :)
[02:24] <ogra> antialiasing is better etc
[02:24] <hunger> At least as long as I do not abuse the system to display 5pt fonts (which are actually still readable if you get *very* close to the screen).
[02:25] <hunger> pitti: The only thing that annoys me is that you guys keep changing font sizes (or probably better DPI settings) at least twice each release cycle:-)
[02:26] <pitti> hunger: not only you
[02:30] <StevenK> pitti: Just curious, can you sync from Incoming?
[02:31] <pitti> StevenK: yes; it's a little more effort, but not too much
[02:33] <Whoopie> mjg59: Hi, any specific reason why you removed s2ram from the uswsusp package? Asking because of bug 134238
[02:33] <ubotu> Launchpad bug 134238 in uswsusp "Please re-enable build of s2ram binary" [Undecided,Confirmed]  https://launchpad.net/bugs/134238
[02:33] <Whoopie> working with bluekuja on the uswsusp package.
[02:36] <mjg59> Whoopie: Because it's inappropriate for Ubuntu
[02:39] <Mirv> mjg59: oh btw bug 86666 has the full vbetrace in case you didn't notice it, but I understand it's a rather low priority thing
[02:39] <ubotu> Launchpad bug 86666 in usplash "Feisty crashes after grub, before boot process, if usplash is enabled (amd64)" [High,Triaged]  https://launchpad.net/bugs/86666
[02:41] <Whoopie> mjg59: but what if the users want to use it although it needs tweaking some scripts?
[02:41] <Whoopie> mjg59: shall we close the bug report then?
[02:42] <mjg59> Whoopie: There's no reason to use it on Ubuntu
[02:43] <ogra> mvo, i have displayconfig-gtk in my menu as a non admin user ... i guess thats not intended
[03:07] <calc> doko: i don't reapply the ubuntu stuff each new merge, i take the debian diff between bzr revisions and apply it to the ubuntu bzr, which is effectively like applying the ubuntu changes each time but without the chance of breaking things as much, we are supposed to writing the changelog entries like we merged from debian though
[03:08] <calc> doko: each #ubuntu1 upload is supposed to list all remaining changes from the debian version
[03:08] <calc> doko: but each #ubuntu1+ can list just changes from the #ubuntu1 upload, which is what I am doing now
[03:11] <doko> calc: just missing my entries from bzr (which is not current) and which makes it difficult to follow ...
[03:12] <calc> doko: sorry i wasn't able to commit them yesterday I was at the doctor/emergency room most of the day :(
[03:12] <calc> doko: i will be getting them committed today
[03:14] <calc> doko: my wife appears to be recovering on her own though the doctors still couldn't determine what was wrong with her when I left the ER last night, she was supposed to be checked into a room eventually :\
[03:15] <calc> doko: supposed to since I haven't head from her yet since cellphones don't work in the hospital
[03:15] <calc> er heard
[03:16] <unggnu> hi all
[03:16] <unggnu> Is it possible that the new Ati driver xorg-driver-fglrx 8.41.7 make it to Gutsy since they should be around 50-90% fastern than the old one?
[03:20] <xerakko> anybody has tested new ati driver?
[03:22] <geser> you mean the fglrx one or the FLOSS one?
[03:23] <mjg59> xerakko: The Novell driver has not been released yet
[03:23] <xerakko> the fglrx
[03:24] <xerakko> the 0.41.7
[03:24] <xerakko> the fglrx 8.41.7
[03:27] <Amaranth> xerakko: from what i've heard it actually breaks r500 and older a lot
[03:27] <Amaranth> xerakko: the main focus was r600
[03:27] <xerakko> :(
[03:27] <superm1> unggnu, not to mention that it has a big warning on the driver download page not to package it in distros
[03:27] <Amaranth> driver next month is supposed to catch the rest up
[03:28] <superm1> it breaks my r300 FirGL hardware
[03:29] <Amaranth> right, it's only for r600
[03:29] <Amaranth> if it works on older cards you got lucky
[03:30] <unggnu> superm1, ok, sorry :)
[03:31] <tepsipakki> 8.42 should also add aiglx support
[03:31] <tepsipakki> ..finally
[03:31] <unggnu> would be great
[03:32] <xerakko> yes, but if it only works in r600 cards I fucked again :/
[03:34] <\sh> damn...what was the name of the kernel driver to use the LSI Logic SCSI Hostadapter for a vmware instance?
[03:35] <unggnu> Could someone of the acpi-support guys have a look at https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/136380 . At least a comment what is wrong with the patch please. Thanks.
[03:35] <ubotu> Launchpad bug 136380 in acpi-support "[Gutsy]  sonybright.sh doesn't use the correct value range" [Undecided,New] 
[03:36] <zul> \sh: buslogic or something like that
[03:36] <\sh> zul, buslogic was the old one...but LSI Logic is the new...I wonder what I forgot in my kernel that my vmware instance is not booting up anymore...damn
[03:56] <\sh> if some of the main devs is so nice and check bug 139376 and push it to the archive admin?
[03:56] <ubotu> Launchpad bug 139376 in quagga "[sync request]  please sync quagga 0.99.9 " [Undecided,New]  https://launchpad.net/bugs/139376
[03:56] <\sh> s/some/one/
[03:56] <\sh> oh damn
[03:57] <\sh> I need sleep...it needs a merge
[04:31] <terlmann> ok is there anyone here who would help me get something implemented right away ? a policy I mean , not a feature or fix to code.
[04:32] <terlmann> elmos smurfs and rabbits. is there a cookie monster in here too ?
[04:34] <Hobbsee> terlmann: is this the same thing as you were saying in #ubuntu+1?
[04:34] <terlmann> YEA!!
[04:34] <Hobbsee> terlmann: and you are really bad at asking useful questions
[04:34] <azeem> and you're root
[04:34] <terlmann> and telinit one
[04:35] <terlmann> nice of you to notice
[04:35] <Hobbsee> let me read the whole thing, sec.
[04:35] <\sh> zul, it was fusion mpt for vmwares lsi logic support...and this I missed out in my kernel config ;)
[04:35] <Hobbsee> terlmann: dude, no.  just no.
[04:35] <terlmann> could I submit a petition to test ?
[04:35] <Hobbsee> dapper --> hardy will already support that.  LTS --> LTS.  not random versions to later random versions
[04:35] <Hobbsee> no.
[04:36] <Hobbsee> and really, #ubuntu isnt the discussion for that either.
[04:36] <Seveas> there isn't really any place to discuss that
[04:36] <Hobbsee> terlmann: you can use a clean cd to upgrade, if you wish.  save /home.
[04:36] <terlmann> I was counsuling a user of hoary who wanted to upgrade.
[04:36] <Hobbsee> terlmann: yes, i know.  i can read.
[04:36] <Hobbsee> terlmann: and it's been discussed before, and the answer is still no.
[04:36] <terlmann> Fine.
[04:37] <terlmann> now onto todays topic for me
[04:37] <Seveas> \sh, supporting hoary -> gutsy
[04:37] <StevenK> Directly?
[04:37] <Hobbsee> \sh: supporting hoary --> feisty or hoary --> gutsy.
[04:37] <Hobbsee> StevenK: yes.
[04:37] <StevenK> Hoarty is completly unsupported
[04:37] <StevenK> Er, Hoary
[04:37] <\sh> Seveas, Hobbsee ah...no that doesn't work ,)
[04:38] <Seveas> \sh, and never will unless someone pays developers to make it work
[04:38] <Hobbsee> \sh: we know. terlmann doesnt seem to
[04:38] <terlmann> is there someone in here who can teach me how to develop a specialized ubuntu derivative. I want to make a specialized pre-dapper like os with extremely limited hardware support that can outrun the devel on the i686 architecture.
[04:38] <\sh> actually it's a FAQ which is written somewhere on the wiki or the ubuntu.com pages...when I remember correctly
[04:39] <terlmann> devil*
[04:39] <Hobbsee> there's a derivatives mailing list too, i believe
[04:40] <Hobbsee> terlmann: btw, if people in #ubuntu+1 tell you it's a stupid idea, it's unlikely that we think differently.
[04:40] <bddebian> Heya
[04:41] <terlmann> Its unrecommended and unsupported. If you got flamed for recommending it and breaking systems, I can see the motive for not doing so.
[04:41] <Seveas> ScottK, warty->hoary was like that for me
[04:41] <Hobbsee> terlmann: because of the sheer amount of work in making sure all the dependancies work.  time better spent doing other things.  think about it.
[04:42] <StevenK> To be honest, if you have a mirror very close, you can jump from Hoary to Feisty in an afternoon
[04:42] <Seveas> StevenK, not without some pain (iirc, lvm package breaks)
[04:42] <terlmann> well I did it. I went hoary-feisty in one fell swoop. with only one command. then recently I decided to try it with warty - gutsy.
[04:43] <Seveas> but you can do warty->gutsy if you want to and know how to debug package problems :)
[04:43] <Seveas> !worksforme | terlmann
[04:43] <ubotu> terlmann: Common Sense: Just because you can, does not mean you should (and especially recommend to others). Think before you do. "Works for me" does not mean it is ok. The latest version of everything is not always useful if you aim for stability. Please see http://geekosophical.net/random/worksforme/
[04:43] <terlmann> Seveas : the limitations on upgrade paths are reduced when we are discussing fresh installs right ?
[04:43] <StevenK> Seveas: I did Dapper -> Edgy -> Feisty in an afternoon with no pain at all
[04:43] <Seveas> sure, but if you do a fresh install, why not install the latest version anyway...
[04:43] <Amaranth> dapper->hardy is going to be fun
[04:44] <terlmann> what if you dont have the latest disk ?
[04:44] <Seveas> download it
[04:44] <StevenK> Amaranth: And is going to result in fun discussions at Boston
[04:44] <terlmann> what if you cant ?
[04:44] <Seveas> you're going to have to download the packages anyway
[04:44] <StevenK> terlmann: Or order one from shipit.ubuntu.com
[04:44] <Hobbsee> Amaranth: fsvo fun.  i think people are still ignoring that problem.
[04:44] <terlmann> some people insist on using what they have. not my way , but they do.
[04:44] <Amaranth> StevenK: yeah, that'll be interesting
[04:44] <Seveas> terlmann, that's their problem
[04:44] <terlmann> was there a release before warty ?
[04:45] <Hobbsee> Amaranth: it's probably not bad if you update the toolchain and apt first.  although, will the GUI tools then break?
[04:45] <ScottK> terlmann: If you did hoary -> feisty you almost certainly have pty problems you need to find and fix.
[04:45] <Hobbsee> terlmann: dude...if you don tknow that kind fo stuff, and want to change policy...
[04:45] <Seveas> terlmann, you could try debian woody --> ubuntu gutsy :)
[04:45] <terlmann> ScottK : it replaced everything , but it worked.
[04:45] <Amaranth> Seveas: potato
[04:45] <ScottK> terlmann: Appeared to work.  Not the same.
[04:45] <ogra> Seveas, why woody ? bo was great too :)
[04:45] <Seveas> ogra, ;)
[04:46] <terlmann> ScottK : not appeared. worked perfectly
[04:46] <ScottK> OK.  There's an unfixed PTY bug that will bite you when you skip edgy.  Good luck with that.
[04:47] <\sh> well, this discussion is totally useless...for users it's not recommended...and if someone is good, he follows the normal upgrade paths...
[04:47] <terlmann> and goes through dapper to edgy
[04:47] <terlmann> sounds logical
[04:47] <Amaranth> it's faster to backup and do a fresh install
[04:47] <StevenK> \sh: Or he deals with breakage and keeps both pieces
[04:47] <ScottK> Agreed.  As I said, I did it as an experiment and then did a fresh install after.
[04:47] <\sh> StevenK, he could also use a knife to cut himself...yeah, can be done, but it's painful
[04:48] <StevenK> \sh: That might be more productive. :-)
[04:48] <StevenK> pitti!
[04:48] <pitti> re
[04:48] <StevenK> pitti: How long does the NBS list take to regenerate?
[04:49] <pitti> StevenK: depends on how long it is, but usually < 10 mins
[04:49] <StevenK> pitti: Because I note the publisher has just finished, and I want to see if I missed anything obvious.
[04:50] <pitti> StevenK: started
[04:50] <StevenK> pitti: Danke
[04:50] <terlmann> Im going back to +1 , dont want to waste your space. konversation closed.
[04:55] <StevenK> pitti: Right, if you wouldn't mind sync'ing sfftobmp 3.0-7.1 from Incoming
[04:55] <pitti> StevenK: cron.NBS finished
[04:55] <StevenK> pitti: Ah, excellent.
[04:55] <StevenK> pitti: You could let through virtualbox-ose from binary NEW if you wished, too. :-)
[04:56] <dholbach> PPA and Ubuntu Packaging 101 in #launchpad in 4 minutes
[04:56] <Keybuk> dholbach: doesn't that clash with the team meeting? :p
[04:56] <Keybuk> (different channel
[04:56] <dholbach> if you mean the launchpad team meeting, no that's over :)
[04:57] <Keybuk> the community development team meeting ;)
[04:58] <evand> if we used Exchange, this kind of thing would never happen.
[04:58] <Keybuk> +1
[04:58] <Keybuk> though I need to try out that esdgcal plugin
[04:58] <Hobbsee> evand: it's more fun having lots of mental arithmetic
[04:59] <Keybuk> http://code.google.com/p/google-calendar-backend/
[04:59] <evand> AWESOME
[05:01] <pitti> StevenK: syncs
[05:01] <StevenK> pitti: Could I also convince you to wave your Wand of Death at bug 139261?
[05:01] <ubotu> Launchpad bug 139261 in democracyplayer "Please remove democracyplayer from the archives" [Undecided,Confirmed]  https://launchpad.net/bugs/139261
[05:02] <ogra> Keybuk, overwhelming content
[05:02] <pitti> StevenK: remove democracy? our path to world dominance? :-)
[05:02] <StevenK> pitti: :-P
[05:02] <ScottK> Path to something.
[05:02] <StevenK> pitti: The bug contains the reason why, and it's just another rdepends on the old boost
[05:02] <mvo> community development team meeing? when/where?
[05:02] <Keybuk> ogra: SoC
[05:02] <Keybuk> mvo: now, #ubuntu-meeting
[05:02] <\sh> pitti, bug 139376 you get a debdiff latest tomorrow morning...hopefully with patches to dapper/edgy/feisty as well
[05:02] <ubotu> Launchpad bug 139376 in quagga "[UVF exception]  please update quagga 0.99.9 " [Undecided,New]  https://launchpad.net/bugs/139376
[05:03] <pitti> StevenK: miro does not build a transitional package
[05:04] <StevenK> pitti: It Provides/Conflicts/Replaces democracyplayer. Not enough?
[05:05] <pitti> StevenK: nope, you need a real transitional package
[05:05] <pitti> StevenK: Provides: never win over real packages on upgrades
[05:05] <StevenK> pitti: Okay, I shall tell RAOF all about it tomrorow, and he can fix it.
[05:09] <StevenK> pitti: Right, it looks like I dealt with 90% of the boost rdepends today, there's 4 source packages left, all of them under control.
[05:10] <pitti> StevenK: dp removed
[05:10] <Mithrandir> StevenK: you seem to have put in quite a lot of work there, thanks a lot.
[05:10] <StevenK> Mithrandir: Not a problem. :-)
[05:11] <StevenK> pitti: Oh thanks, I was expecting you to leave it until the new miro was uploaded.
[05:11] <pitti> StevenK: doesn't make much of a difference (except for binary NEW)
[05:11] <StevenK> Ah
[05:12] <StevenK> pitti: Would you mind keeping an eye on wengophone's ia64 build? When it builds could you drag it out of binary NEW?
[05:12] <pitti> StevenK: can do
[05:13] <StevenK> Mithrandir: Oh, and this lot of work was nothing - I uploaded 72 packages for the libcurl transition mess.
[05:13] <StevenK> Just as long as they aren't American. :-P
[05:13] <Seveas> he said beer, not piss ;)
[05:14] <Mithrandir> the US has plenty of good beers.  Just not the big brands.
[05:14] <StevenK> Since American beer is like having sex in a canoe
[05:14] <pitti> fucking close to water?
[05:14] <StevenK> Exactly. :-D
[05:15] <StevenK> But okay, based on Mithrandir's comment, I shall change my joke to be s/American/main-stream American/
[05:15] <Mithrandir> at least I had good beer when I was in Boston
[05:15] <ScottK> Ugh.  Yeah.
[05:15] <StevenK> Muahaha
[05:15] <StevenK> That'll learn you
[05:15] <pitti> s/reminds/remembers/
[05:16] <StevenK> pitti: Did any Australian buy you a Fosters while you were over here?
[05:16] <pitti> StevenK: I might have had it, I don't remember any more
[05:16] <pitti> only that we had lots :)
[05:16] <Mithrandir> Fosters isn't _that_ bad.  Just boring.
[05:16] <StevenK> Fosters *is* that bad, compared to some of the other beers we have on offer.
[05:17] <Mithrandir> oh, sure, but it's not nearly as bad as some of the bad US beers.
[05:17] <Mithrandir> as an example of good US beer, you have most of the Anchor beers.
[05:17] <Spads> Mendocino Brewing COmpany
[05:17] <ScottK> Unfortunately it doesn't travel well.
[05:17] <Hobbsee> mmm....brains.
[05:17] <Spads> Red Tail Ale
[05:17] <Spads> very nice stuff
[05:17] <Hobbsee> brains are better than beer.
[05:17] <pitti> StevenK: limited baggage :/
[05:17] <StevenK> I might bring a 8-pack (that's right, it doesn't come in 6 packs) of Tooheys Extra Dry Premium
[05:18] <StevenK> It's *dangerous* to drink, since it's so smooth
[05:19] <Mithrandir> I guess I could get some from either Ngne  (naked island) or Hndbryggeriet (the hand brewery) and bring.
[05:19] <Mithrandir> only is they're bottle-conditioned, so they need to sit still for a bit before being consumed.  Like, a couple of days.
[05:19] <StevenK> Oh, floe has started on wengophone. Yay.
[05:19] <StevenK> Mithrandir: *Neat*
[05:20] <StevenK> Oh, for want of more baggage space. Coopers is a bit like that.
[05:20] <Mithrandir> coopers is good.
[05:20] <Mithrandir> well, since UDS is for a week, it's not really a problem
[05:20] <Hobbsee> assuming your luggage gets there :P
[05:20] <StevenK> Haha
[05:21] <Seveas> Hobbsee, you should be thrown in the pool for that :)
[05:21] <StevenK> Mithrandir and I are about the same size, I can be convinced to bring a few extra shirts. :-)
[05:21] <Hobbsee> Seveas: no, no, you've learned not to throw me in the pool, right?
[05:22] <Hobbsee> Seveas: you've learned that attempting to break people's wrists is bad.
[05:22] <Seveas> hehe
[05:22] <Mithrandir> StevenK: shirts is usually not the problem.  It's the socks and such
[05:23] <StevenK> Mithrandir: Oh, I've got my own problems with socks. :-)
[05:23] <Mithrandir> with socks or SOCKS?
[05:23] <StevenK> Both
[05:23] <superm1> it appears that ubuntu-desktop is depending upon ubufox which is depending upon apturl, does this mean apturl was decided to be on by default then on new gutsy installs?
[05:33] <dholbach> hum, is there a problem with cvs.freedesktop.org or http://bugs.freedesktop.org/ ?
[05:34] <mvo> dholbach: I heard freedesktop.org is currently hit very hard because of the amd register documentation that is now hosted on www.x.org and that draw some attention ( ~70.000 downlods)
[05:34] <dholbach> oh right
[05:34] <dholbach> ok
[05:35] <gnomefreak> superm1: if ubotufox needs it than yes. last i heard ubufox will be installed by default
[05:35] <superm1> i'm kind of surprised ubufox would need it
[05:35] <superm1> it appears ubufox is actually a recommend of *-desktop
[05:35] <gnomefreak> maybe one of hte options it allows you to change would need it?
[05:36] <gnomefreak> superm1: the des. still says ubufox - modifications for ubuntu firefox (default) install
[05:36] <illovae> hello o/
[05:36] <superm1> the big thing ubufox provides was a way to install extensions system wide
[05:37] <gnomefreak> so im assuming its installed with normal install but asac would know best if it was or wasnt accepted for default install
[05:37] <mvo> dholbach: we need a worumx update ;)
[05:37] <gnomefreak> mvo: apt-listchanges is borked keeps segfaulting seems like (i removed it but thought i would let you know)
[05:37] <dholbach> mvo: I think a uvfe was filed for it
[05:38] <dholbach> mvo: ah no, it wasn't
[05:38] <mvo> someone should :)
[05:38] <mvo> gnomefreak: oh?
[05:38] <mvo> gnomefreak: do you have a backtrace?
[05:38] <gnomefreak> ill install it and grab it
[05:39] <superm1> mvo, being listed as maintainer on apturl, do you know whether it was accepted for the default install then?
[05:39] <superm1> or why asac depends upon it for ubufox?
[05:40] <gnomefreak> superm1: i just asked him but he seems afk atm
[05:40] <gnomefreak> hmmm let me see if logs have it
[05:41] <mvo> superm1: it is already a dependency of some firefox thing, so it should be in
[05:41] <superm1> mvo, yea its a dependency for 'ubufox'
[05:41] <asac> superm1: apturil is currently used for plugin finder wizard that allows you to install plugins packaged in ubuntu
[05:42] <mvo> superm1: its on the CD already so I expect that it is part of the defaul tinstall
[05:42] <superm1> asac, ah i see
[05:42] <superm1> mvo, i remember reading about it, but that there was uncertainty regarding if its an unsigned apt repo or if you dont have the apt-key in your apt-keyring already, has that been resolved?
[05:43] <mvo> superm1: it will not support unsingend repositores
[05:43] <superm1> mvo, okay so it won't support PPAs then for now.
[05:44] <mvo> superm1: unfortunately no, also it was deisgned with ppa in mind.
[05:44] <mvo> superm1: its a limitation of ppas currently that they are not signed (and that is no good IMHO)
[05:44] <superm1> mvo, yeah for now, we are mirroring our PPA off site and signing the release to simplify things
[05:45] <gnomefreak> mvo: i cant find logs atm ill ping you when and if it happens again
[05:45] <gnomefreak> seems to have done it on both upgrades i did yesterday and today
[05:46] <superm1> mvo, okay well i'll play with it a bit then :) one more question, did you see my mail earlier this week or so ago about how the .desktop files get updated in g-a-i?
[05:46] <mvo> gnomefreak: ok, thanks
[05:47] <mvo> superm1: maybe :) did you send it to me personally? or to a list?
[05:47] <superm1> mvo, to you personally
[05:47] <superm1> i had thought perhaps it might have been overlooked for that reason :)
[05:48] <mvo> superm1: ha! I have it and marked it as important :)
[05:48] <gnomefreak> mvo: im gonna guess and say if it cant find changelog it segfaults. espeak update just showed changelog and didnt seg.
[05:48] <mvo> superm1: I will try to answer it soon, please just keep naging me, I'm a bit overloaded currently with regular work, my backlog for mail is terrible
[05:48] <superm1> mvo, no biggie, didn't want to nag too badly :)
[05:51] <mvo> superm1: right :) but please do, otherwise it may fall to the floor.
[05:59] <StevenK> Amaranth: Oh, I spoke to Bart today - according to him, metacity *does* talk when switching
[05:59] <Amaranth> StevenK: hrm
[05:59] <Amaranth> accessibility checker lies then
[05:59] <StevenK> Amaranth: It could be Orca doing it
[06:01] <Amaranth> but metacity has to do the accessibility stuff so orca can 'read' it
[06:01] <StevenK> Yes, of course.
[06:02] <StevenK> Amaranth: Try it yourself, Orca is brain-damagingly easy to set up
[06:02] <pitti> asac: networks are just overrated *sigh*
[06:04] <asac> pitti: yeah ;)
[06:04] <ogra> pitti, yeah, we should use drums again :) will make work fun ... no gym anymore for canonical develpers :)
[06:04] <asac> ok i pasted the log to the bug
[06:05] <ogra> lol
[06:05] <pitti> asac: just in case you got the wrong impression: I would love to see n-m get decoupled from ifupdown
[06:05] <StevenK> I have a whole two machines with floppy drives
[06:05] <ogra> i still have a handfull in the basement
[06:06] <ogra> but none of them in a bootable state
[06:06] <pitti> asac: instead, I'd rather have it read the current status with ioctls and route, so that these changes becomes upstream compatible, too, and don't mess with other network setup tools either
[06:06] <pitti> it's just so utterly hard to get it right
[06:06] <asac> pitti: i didn't know that before ... but after the chat we had, I already saw that ;)
[06:06] <StevenK> Actually, I have two working floppy drives in my junk pile
[06:06] <asac> pitti: network-manager 0.7 has lots of things
[06:07] <pitti> asac: ooh, is there a 0.7 released now?
[06:07] <asac> unfortunately not
[06:07] <asac> but its ment to be the "great" solution afaik ;)
[06:07] <asac> hopefully be avail for gutsy+1
[06:08] <asac> if we want to contribute ... we should do it there ;)
[06:08] <asac> so its not worth to put too much effort into 0.6.5
[06:09] <pitti> ack
[06:09] <StevenK> Have upstream a plan about 0.7?
[06:13] <gnomefreak> mvo: i found a crash report ill report bug and upload for you
[06:17] <StevenK> Hmph.
[06:17] <StevenK> Launchpad, show me more than fifteen lines of the build log!
[06:17] <StevenK> (While the build is running)
[06:21] <Keybuk> http://arstechnica.com/journals/linux.ars/2007/09/12/ubuntu-technical-board-votes-on-compiz-for-ubuntu-7-10
[06:21] <Keybuk> heh
[06:28] <StevenK> pitti: wengophone built everywhere, drag it out of NEW at your leisure
[06:31] <asac> StevenK: what do you mean by "Have upstream a plan about 0.7"? do you ask for a prospective release date?
[06:31] <pitti> StevenK: done
[06:31] <StevenK> pitti: Thanks
[06:31] <StevenK> asac: Not just a release date, but testing and rc's and so on
[06:31] <asac> StevenK: since its a gnome project i hope that they try to release on next gnome release ;)
[06:32] <Keybuk> asac: planned features?
[06:32] <asac> StevenK: then rc's et al would be aligned with gnome as well i guess
[06:32] <asac> Keybuk: haven't looked in detail
[06:32] <StevenK> pitti: virtualbox-ose has built everywhere it's going to if you wish to drag it out
[06:33] <asac> Keybuk: but will do so as soon as i am done with nm for gutsy ;)
[06:33] <StevenK> Speaking of, P-a-s needs to be updated for it
[06:34] <pochu> asac, Keybuk: http://live.gnome.org/NetworkManagerToDo
[06:34] <Keybuk> "Work is in-progress to create a dbus-based control interface for wpa_supplication."
[06:34] <Keybuk> ironic
[06:34] <Keybuk> didn't they just rip out the dep on dhcdbd so that they could control it directly, rather than across D-BUS?
[06:36] <asac> "KILL KILL KILL dhcdbd (DONE)" :)
[06:36] <Keybuk> so they appear to have contradictory goals
[06:36] <Keybuk> D-BUS simultaneously GOOD and BAD
[06:37] <ubotu> Launchpad bug 139405 in gnome-screensaver "screensaver does not start when you bring up a right click menu" [Medium,Triaged]  https://launchpad.net/bugs/139405
[06:37] <ogra> i dont want my screensaver to start if i use my mouse ...
[06:38] <asac> Keybuk: i think they prefer to communicate over dbus instead of unix sockets.
[06:38] <Keybuk> yes, because sockets are hard
[06:38] <Keybuk> and D-BUS is near=impossible
[06:38] <asac> ;)
[06:38] <Keybuk> developers appear much more macho if they use D-BUS
[06:38] <Keybuk> :p
[06:38] <hunger> ogra: I guess that bug is about right-clicking, have a menu appear and then doing nothing for ages with the menu still visible.
[06:38] <asac> yeah ... they like to highly asynchronous behaviour ... no idea why
[06:38] <Keybuk> after all, you can establish a simple two-way D-BUS connection in only 10,000 lines of C
[06:39] <asac> hehe
[06:39] <hunger> ogra:
[06:39] <ogra> hunger, hmm, how is that related to the screensaver
[06:39] <asac> yeah ... implement tcp on top of dbus ... thats great
[06:39] <hunger> ogra: screensavers should trigger after x min of inactivity.
[06:39] <ogra> right
[06:39] <Keybuk> ogra: the upstream bug may explain more
[06:40] <ogra> oh, you mean if the popup menu just *sits* there on the screen ?
[06:40] <hunger> ogra: Independent of wether that inactivity happened after right-clicking on the desktop or not.
[06:40] <Keybuk> you can inhibit screensavers from starting by leaving a menu open
[06:40] <Keybuk> (some of us used to use this as a feature, of course :p)
[06:40] <ogra> hehe
[06:40] <ogra> ok, then i understand
[06:40] <ogra> it read like the OP wanted the screensaver to go off while the right mouse button is in use :)
[06:41] <hunger> ogra: Now that would be silly:-)
[06:41] <Keybuk> of course, that bug needs careful fixing
[06:41] <hunger> ogra: But otoh... users sometimes have silly ideas;-)
[06:41] <ogra> yeah, thats what made me scratch my head
[06:41] <Keybuk> since it would be a bug if, after the screensaver was unlocked, the menu wasn't still open ;)
[06:41] <ogra> lol
[06:46] <hunger> any progress on the open-vm-tools package since yesterday?
[06:47] <keescook> okay, anyone know why enabling desktop effects seems to just kill my window manager?
[06:48] <Keybuk> uhh
[06:48] <Keybuk> because that's what it does?
[06:48] <Keybuk> :)
[06:48] <keescook> Keybuk: heh, well, right, but it doesn't start the _new_ decorator.
[06:48] <superm1> keescook, desktop effects calls compiz --replace
[06:48] <Keybuk> new decorator or new window manager?
[06:48] <Keybuk> (they're different things)
[06:48] <superm1> so it needs a new decorator and window manager
[06:48] <Keybuk> try compiz --replace on a terminal
[06:49] <keescook> now all my window borders are gone.  :)
[06:49] <keescook> perhaps there is some gconf wipe I need to do?
[06:49] <Hobbsee> you havent switched to kde, have you?
[06:49] <keescook> Hobbsee: nopers
[06:49] <Keybuk> keescook: is the window manager still working?
[06:49] <tepsipakki> keescook: start gtk-window-decorator?
[06:49] <Keybuk> ie. do window shortcuts work like Alt=F4
[06:50] <Hobbsee> that's normal for kde, as k-w-d tends to segfault
[06:50] <keescook> Keybuk: alt-f4 works against my xterms
[06:50] <keescook> tepsipakki: compiz says it did start it
[06:50] <keescook> Starting gtk-window-decorator
[06:50] <Keybuk> ok, then you've not got the decorator for some reason
[06:51] <keescook> kees     12073  0.0  0.3 127932 10048 pts/1    S+   09:49   0:00 /usr/bin/gtk-window-decorator --replace
[06:52] <wasabi> I'm having random segfaults since ... updating gutsy yesterday.
[06:52] <wasabi> Unsure if it's kernel or a dependency... since gdb itself usually crashes.
[06:52] <wasabi> metacity just died.  weee
[06:53] <keescook> wasabi: yeow.  do you use XFS?
[06:53] <wasabi> Nope.
[06:53] <keescook> hmp
[06:53] <wasabi> Yeah, file corruption could be a possibility... just not sure how to isolate it.
[06:53] <keescook> tepsipakki: any thoughts on how to further debug?
[06:53] <wasabi> Let me reinstall the entire stack under metacity and see if it continues or something.
[06:53] <keescook> wasabi: try comparing the md5sum of packages?
[06:54] <wasabi> debsumming.
[06:54] <wasabi> Oh. I've got some crap prelinked.
[06:54] <wasabi> So that's not of much help.
[06:55] <superm1> mvo, in playing with apturl a bit, its not possible to activate both universe and multiverse from an apt url is it?
[06:55] <superm1> i can seem to do one or the other, but not both
[06:56] <mvo> superm1: sounds like a bug, could you please report that?
[06:56] <superm1> sure
[06:56] <Hobbsee> mvo: what's your opinion on putting a conflicts/replaces libsvg, for libsvg1?
[06:56] <keescook> mvo: is some incantation to clear the conf settings for compiz back to default?
[06:56] <Hobbsee> mvo: it's outside of the packaging system, but it's going to hit every user who installed beryl-crack.
[06:57] <mvo> keescook: there is a button for this in "compizconfig-settings-manager". we could also add this to the apperance capplet
[06:57] <mvo> Hobbsee: sounds not bad to me if it helps users
[06:58] <keescook> mvo: okay, thanks
[06:58] <Hobbsee> mvo: i wonder if we need to do anything with libsvg-dev
[06:58] <lamont> ltsp-build-client --security-mirror doesn't like to be redirected...
[06:58] <lamont> adds a /ubuntu to the URL
[06:59] <wasabi> keescook: Well, found an app that consistantly segfaults.... in libc.
[07:01] <Hobbsee> mvo: done
[07:03] <wasabi> Heh. Nice. I just reinstalled libc, and it works now!
[07:03] <wasabi> dangerous stuff, that
[07:05] <keescook> mvo: ccsm is nice, and things are working okay except that I still have no window borders and 3d windows are just black.  :P
[07:05] <mvo> keescook: you call that "working" ?
[07:05] <mvo> keescook: does it help if your run "gtk-window-decorator --replace" ?
[07:05] <keescook> mvo: well, no, it's unusable, but I mean, I can confirm that the animations and things work
[07:05] <mvo> keescook: do you have a nvidia ?
[07:06] <keescook> mvo: decorator was already running.  yup, nvidia (I know there are issues with it, which is why I thought I'd go test it a bit)
[07:06] <mvo> keescook: what kind of nvidia is it?
[07:07] <keescook> GeForce 6100
[07:07] <keescook> on-board
[07:07] <keescook> (C51G)
[07:09] <keescook> mvo: ah-ha! needed:     Option "AddARGBGLXVisuals" "true"
[07:09] <mjg59> Keybuk: Why did you assign 60042 to acpi-support?
[07:10] <mvo> keescook: ha! isn't that set automatically by the enable-nvidia script (or restricted-manager)? if not, we should file a bug :)
[07:10] <Keybuk> mjg59: uhh, didn't I assign that to powernowd?
[07:10] <keescook> mvo: well my xorg.conf pre-dates restricted-manager, so perhaps a test for it?
[07:10] <mjg59> Keybuk: No?
[07:10] <Keybuk> oh, I know, I did, but then got confused about the silly LP change where clicking on the "Affects" doesn't do the right thing
[07:11] <Keybuk> and then put it to the wrong package in my dizzyness
[07:11] <Keybuk> let me fix that
[07:11] <Keybuk> (since powernowd is the init script that fiddles with the cpufreq stuff atm)
[07:19] <doko> Hobbsee: does kmplayer build for you?
[07:20] <Hobbsee> doko: havnet tried, tbh
[07:22] <doko> Hobbsee: would you mind to start a build?
[07:22] <sladen> must. rename.  powernowd.
[07:22] <Hobbsee> doko: at 3.22am?  yes, i would mind.
[07:23] <Hobbsee> doko: send me an email, and i'll try it after some sleep
[07:23] <Keybuk> sladen: powernowdbd
[07:24] <sladen> dbcpowernowdd
[07:24] <keescook> heh
[07:24] <Keybuk> I, for one, will not mourn the passing of *that* package
[07:24] <Keybuk> dhcdbdbdbdbdbdbdbd...what's up buck?
[07:25] <Keybuk> then I just have to get rid of udev-udeb :p
[07:25] <ikonia> best tweeky impression ever
[07:27] <lamont> so, um, today's livecd... should I actually get running Xwindows? :-(
[07:28] <sladen> lamont: nah, somebody setup teh bomb on the X server
[07:29] <Ng> does our thinkpad acpi module not have the fan control patches? (http://www.thinkwiki.org/wiki/How_to_control_fan_speed claims they are in mainline from 2.6.20, but I don't see the same control options in gutsy)
[07:30] <lamont> sladen: really?
[07:30] <lamont> I mean, it does want fglrx... :(
[07:30] <lamont> was trying the livecd to see if I could figure out a working config that gave me 1680x1050 instead of 1024x768
[07:31] <lamont> heh.  my bad... it came up
[07:31] <sladen> ahhh, trackerd
[07:31] <sladen> turns your CPU back into a 20Mhz part
[07:32] <wasabi> oooh. system lock up that time.
[07:32] <wasabi> ssh died... was still able to ping
[07:32] <wasabi> well this is no good!
[07:32] <ogra> sladen, just replace it with trackerd to speed up :) http://www.eyrie.org/~eagle/software/tracker/trackerd.html
[07:32] <bhale> sladen: you can turn it off in tracker-preferences, but it still will start up trackerd and spin the hell out of your disk if it feels like it
[07:35] <Arador> yeah, it's weird that it insist in doing things when you've turned it off in the preferences
[07:35] <jamiemcc> sladen: uncheck enable watching and enable Evolution email indexing and restart trackerd - it should behave
[07:35] <jamiemcc> arador: its a known bug which im fixing
[07:35] <sladen> bhale: well yes, you /can turn it off in the preferences/.  However, that wouldn't have any effect on the trackerd still running in the background, until you logout/reboot
[07:35] <bhale> sladen: well. ive seen it start up anyway
[07:36] <sladen> bhale: *and*, whenever trackerd gets reinstalled/upgraded ... it resets itself to enabled.
[07:36] <bhale> oh REALLY
[07:36] <bhale> brilliant.
[07:36] <bhale> mine was certainly unchecked when i found it beating my disk to a pulp, though
[07:37] <bhale> on battery power, too
[07:38] <bhale> seems like a backwards default to me
[07:38] <sladen> stabby, stabby, stabby, kill, kill, kill
[07:38] <Arador> in my box trackerd manages to halt applications for many seconds, but it looks more like a bad kernel behaviour than a trackerd bug
[07:39] <mjg59> Trackerd was, until recently, demonstrably broken - you can't call lseek() 100 times a second and expect throughput to be high
[07:39] <jamiemcc> mjg59: unless its cached
[07:39] <jamiemcc> by kernel
[07:40] <mjg59> jamiemcc: Which you can't guarantee at all
[07:40] <sladen> type  C-x C-s  in emacs and watch it hang
[07:40] <jamiemcc> mjg59: true
[07:40] <mjg59> Especially if you're making tiny writes over a very large area
[07:40] <jamiemcc> but it should not cause very high iowait
[07:40] <wasabi> Should not having debsums be something people should FIX? :)
[07:40] <sladen> the I/O is not on the files isn't supposed to be indexing, but on  seek(), read(), seek(), write()  (mmap'ed?) on its data-base files
[07:41] <mjg59> Knowing how much of an issue it still is in 0.6.2 would be much more helpful
[07:41] <jamiemcc> mjg59: the way the indexer works has not changed for a long time
[07:41] <jamiemcc> only recently did we add sqlite but the mechanics are the same
[07:41] <jamiemcc> an index is word -> array of hits
[07:42] <jamiemcc> when array grows we have to reaalocate pages
[07:42] <jamiemcc> adding a hit means doing a read/write op
[07:42] <sladen> jamiemcc: can't that be done *in memory* and serialised to disk once an hour?
[07:42] <jamiemcc> sladen: we cache in memory yes
[07:42] <sladen> jamiemcc: rather than holding the working-set on disk
[07:42] <mjg59> jamiemcc: As I said, if you're calling lseek() and writing a tiny amount of data repeatdly, there's no way you're going to get any sensible throughput
[07:42] <jamiemcc> next version will do index merging which means creating a small tmp index
[07:43] <jamiemcc> mjg59: we did that in feisty very fast
[07:43] <mjg59> jamiemcc: At some point those writes need to hit disk. If you're spreading them out far enough, you can't collate them.
[07:43] <jamiemcc> 0.5.4 does that
[07:43] <mjg59> It's simply impossible
[07:43] <sladen> a 50MB write costs the same as a 5 byte one
[07:43] <jamiemcc> with elevator in the kernel it should reorder the writes into an optimal order
[07:43] <sladen> tiny is not the problem, it's the quantity
[07:43] <jamiemcc> fsync is off by the way
[07:43] <mjg59> jamiemcc: Again, that assumes that the writes are close enough that they /can/ be reordered into an optimal order
[07:43] <sladen> trackerd needs to *not do those writes* in the first place
[07:44] <jamiemcc> well basically we cache up wroites and use padding to reduce reallocation
[07:44] <sladen> trackerd needs to do *one* 50MB write each time it has fully filled a database
[07:44] <mjg59> jamiemcc: Once the index file has reached a GB or so, that's simply not going to happen.
[07:44] <jamiemcc> mjc59: agree
[07:44] <jamiemcc> thats why I say its scalable up to 1gb
[07:44] <jamiemcc> 1gb index == 10GB text
[07:44] <mjg59> And as a result, your maximum throughput is going to be around 25K/sec
[07:45] <mjg59> jamiemcc: Ok. Is it going to be scalable beyond that within a month?
[07:45] <jamiemcc> yes with index merging
[07:45] <jamiemcc> we will merge at 64mb intervals
[07:45] <mjg59> That sounds good
[07:45] <jamiemcc> so a tmp index is created and then merged with the buig one
[07:45] <jamiemcc> big
[07:46] <sladen> jamiemcc: okay, does that means you'll only touch the disk for the index files once every 64MB ?
[07:46] <jamiemcc> no we create a small index which the kernel can cache
[07:46] <jamiemcc> 64mb is small and should never be slow to read or write
[07:46] <sladen> and this "small index" is still being accessed with  seek(), read(), seek(), write ...
[07:47] <jamiemcc> yes but those seeks are on cached pages in ram
[07:47] <sladen> bad assumption
[07:47] <jamiemcc> kernel uses spare memeory to cache disk pages
[07:47] <sladen> *IF THERE IS ANY SPARE MEMORY*
[07:47] <jamiemcc> you will need 64mb spare yes
[07:47] <jamiemcc> we can make the merge index smaller if you like
[07:47] <jamiemcc> 32mb?
[07:48] <Arador> just curiosity: does trackerd uses fadvise()/madvise() to tell the kernel that it's not going to need to read data again? (since I suppose it should be the standard behaviour in a indexer, shouldn't it?)
[07:48] <jamiemcc> arador: just committed that the other day
[07:48] <sladen> 256MB, OpenOffice running, trackerd raping the disk in the background, i/o => swap => thrash
[07:48] <jamiemcc> ubuntu 7.10 has 512mb min memory
[07:48] <jamiemcc> in the specs
[07:49] <mjg59> Still fairly easy to push into swap with that much, sadly
[07:49] <sladen> I guess the thing is to do the index-merging operations when there is RAM to do so
[07:49] <jamiemcc> alternative is to cache in memory?
[07:49] <mjg59> Explicitly operating on in-memory data structures and then pushing them out as a single linear write might make more sense
[07:50] <jamiemcc> mjg59: only an issue during initial index though
[07:50] <mjg59> jamiemcc: Yeah, but right now that can take about two days :)
[07:50] <jamiemcc> well we have an in memory cache but its only 2mb
[07:50] <sladen> if you alloc(64MB) and are not doing anything (because people are trying to use their machine for work), you should get paged out == but that's fine
[07:50] <Arador> jamiemcc: nice, because it looked like it was the problem I was hitting - trackerd would cause the kernel to cache all the stuff it was indexing, so the kernel would "uncache" the applications I'm using to make room :/
[07:50] <jamiemcc> mjg59: on debian unstable 800mb database took 3 hours to index
[07:51] <sladen> it's taking 2 hours to produce a 50MB database here
[07:51] <jamiemcc> sladen: kernel bug
[07:51] <jamiemcc> vmstat 1 and check wait states
[07:51] <jamiemcc> my 400mb database took a lilttle over an hour
[07:51] <sladen> jamiemcc: kernel bug ... but  killall -9 trackerd  seems to solve it
[07:52] <mjg59> jamiemcc: When I was monitoring it, it was entirely seek bound (and each of those seeks was hitting disk)
[07:52] <jamiemcc> sladen: when I did a fresh install of tribe 4 kernel bug went away
[07:52] <sladen> jamiemcc: fresh install == empty disk == nothing to index == nothing to do!
[07:52] <mjg59> jamiemcc: There's no way that an updated system will differ from a clean install in terms of kernel
[07:52] <jamiemcc> tribe 3 has the bug and it persists
[07:52] <jamiemcc> some setting somewhere?
[07:52] <mjg59> No
[07:53] <mjg59> The problem must be elsewhere
[07:53] <jamiemcc> I will add tribe 3 again tonoight and confirm
[07:53] <jamiemcc> 2 people have confirmed that fresh install solved the issues
[07:53] <sladen> jamiemcc: it will.
[07:53] <sladen> jamiemcc: empty disk
[07:53] <jamiemcc> with identical home directory
[07:54] <Hobbsee> sigh.  i would have had time to do the build too.  night all.
[07:54] <jamiemcc> well 0.5.4 on feisty never produced a single claim of slowdown and iondexer works same way
[07:55] <jamiemcc> excessive seeks might slow indexing but not the system
[07:56] <sladen> hard-disk => 10msec seek => maximum 100 seeks/seconds
[07:56] <jamiemcc> sladen on uncached yes but stuff close together on disk is usually < 1ms
[07:57] <jamiemcc> 10ms is avaergae across whole disk
[07:57] <mjg59> jamiemcc: Rotational latency still gets you
[07:57] <sladen> jamiemcc: the use case to optimise is not running trackerd on an unused system
[07:58] <jamiemcc> sladen: you have 50mb db and have more than 50mb free memory then kernel wll cache it 100% so you should never have a slow down
[07:58] <mjg59> Especially on laptops, where you're looking at 70rps
[07:58] <sladen> jamiemcc: it's to optimise the case of *other people wanting to use the CPU for real work*
[07:58] <jamiemcc> sladen its niced +19 and disk io best effort 7
[07:58] <jamiemcc> same as on feisty with 0,5,4
[07:58] <mjg59> sladen: Calm, please
[07:58] <sladen> jamiemcc: yup, so those writes are likely to end up >1msec apart (other things attempting to get scheduled)
[07:59] <jamiemcc> well fsync delays it so they are bucnhed up together
[07:59] <jamiemcc> levator write in the kernel should optimise it
[07:59] <mjg59> jamiemcc: Switching to using it by default is likely to have resulted in it being exposed to a much wider range of users
[08:00] <jamiemcc> mjc59: it affected me in tribe 3
[08:00] <jamiemcc> I had to do celan install of tribe 4 to get it to go away
[08:00] <jamiemcc> same set of files took ages to index and slowed desktop massively
[08:00] <mjg59> I'm immensely reluctant o conclude that it's a kernel bug, because (a) nobody in the wider Linux community has started complaining that their database has slowed down, and (b) whether this behaviour is evident or not is unrelated to the kernel you're running
[08:01] <jamiemcc> only gutsy kernel is affected
[08:01] <jamiemcc> debian is not
[08:01] <mjg59> jamiemcc: If it's fine in a clean install and not in an upgraded one, it's not a kernel bug.
[08:01] <jamiemcc> even without tracker running people complain on gutsy that disk io is harming desktop
[08:02] <jamiemcc> mjc59: could it be some other  process then?
[08:03] <mjg59> That would seem rather more likely, but it's still not clear why it would be different on an upgraded system
[08:03] <jamiemcc> initial config might be different for a rocess
[08:04] <jamiemcc> it might use an old config
[08:05] <mjg59> Desktop applications will be getting stuff from gconf, so will get the new defaults. System ones will be in /etc, where they'll be overwritten unless the admin manually changed them
[08:05] <jamiemcc> mjg59: could pdflush or something have an effect?
[08:06] <mjg59> jamiemcc: That's a kernel thread
[08:06] <jamiemcc> yes but its responisble for flushing the disk
[08:06] <mjg59> Yes, but it has no configuration
[08:06] <jamiemcc> I thought you could set dirty page buffers
[08:07] <jamiemcc> and how often to flush
[08:07] <mjg59> So clearly yes, it could have an influence - but that doesn't explain the difference between upgrades and reinstalls
[08:07] <mjg59> jamiemcc: You can, but we don't ship any configuration
[08:35] <siretart> asac: hmm. it seems that with wpasupplicant 0.5.8, I get a lot fewer TIMEOUTs than with 0.6.0.
[08:38] <mdomsch> packaging question
[08:38] <mdomsch> is there a way to install a file into /etc/* without it automatically being considered a conf file?
[08:39] <Mithrandir> all files in /etc are configuration files, but not all of them are conffiles
[08:40] <Mithrandir> you can create non-conffile configuration files by creating them in the postinst.
[08:40] <mdomsch> that's what I was afraid of
[08:41] <mdomsch> honestly, it's not a configuration file nor a conffile, but it has to go in /etc/kernel/{prerm,postinst}.d/ because that's where linux-image expects it to go
[08:41] <Mithrandir> why do you claim it's not a configuration file?
[08:42] <mdomsch> it's a script called by linux-image.postinst to invoke another package (in my case, DKMS)
[08:42] <mdomsch> e.g. like a trigger
[08:44] <Mithrandir> yes, and in what way is that not a configuration file?  /etc/dhcp3/dhclient-script is a script invoked as part of the DHCP sequence, this sounds very much the same
[08:45] <Mithrandir> Seveas: any chance we could get ubotu in #ubuntu-kernel?
[08:45] <mdomsch> indeed, very similar
[08:45] <mdomsch> ok, great, then it is and I'll let it be treated as such
[08:45] <Seveas> @join #ubuntu-kernel
[08:45] <mdomsch> thanks
[09:09] <mdomsch> if doing apt-get install linux-image-2.6.20-15-generic linux-headers-2.6.20-15-generic
[09:09] <mdomsch> is there a way to guarantee the ordering that the postinst scripts of those get run?
[09:09] <mdomsch> in my limited tests, it seems linux-image.postinst gets run after linux-headers.postinst
[09:09] <mdomsch> but is that actually deterministic?
[09:09] <kdean06> I've got a question pertaining to a license found in an Ubuntu package. I e-mailed the maintainer about two weeks ago, and haven't gotten a responce. The package is copywritten by Canonical, so is there an "upstream" contact for this?
[09:09] <mc44> kdean06: which package?
[09:09] <kdean06> ubuntu-calendar-*
[09:10] <tonyy> kdean06: what's the question?  maybe there's a chance someone here will know.
[09:11] <kdean06> tonyy, My question is specifically if the package allows redistribution, and if so under what terms.
[09:11] <kdean06> There's no license on that package at all, only copywrite notice.
[09:11] <tonyy> kdean06: You've checked the source package?
[09:12] <kdean06> Yes, it's got no license... The contents of the package are graphics, not code, or at least, not licensed code.
[09:12] <tonyy> It should still have full licensing info in debian/copyright though...
[09:13] <kdean06> The changelog file contains not license reference, and the copyright only gives "Copyright 2004 Canonical Ltd." and the upstream author.
[09:14] <Keybuk> kdean06: what is the package?
[09:14] <kdean06> The link, from packages, which is identical to the debian/copyright file, is http://changelogs.ubuntu.com/changelogs/pool/main/u/ubuntu-calendar/ubuntu-calendar_5.03-2/ubuntu-calendar.copyright
[09:14] <tonyy> kdean06: you're quite right
[09:14] <kdean06> Keybuk, ubuntu-calendar*
[09:15] <Keybuk> ubuntu-calendar is probably not redistributable
[09:15] <tonyy> kdean06: jdub is the maintainer, and currently on IRC, but likely away
[09:16] <Keybuk> Mithrandir: around?
[09:19] <Keybuk> tonyy: jdub isn't at Canonical anymore
[09:19] <tonyy> Keybuk: Ah...I think I knew that.  Still listed as the maintainer though ;)
[09:19] <tonyy> (feisty pkg)
[09:20] <Keybuk> those packages haven't been touched in *years* :p
[09:20] <tonyy> I noticed it had 'warty-updates' in it...
[09:22] <kdean06> That might explain why he hadn't responded to my inquiries. :)
[09:22] <lamont> ogra: where do the ltsp folks hang out?
[09:22] <ogra> #ltsp
[09:22] <ogra> but if you have a question sbalneav and me are here :)
[09:22] <ogra> we are essentially the ltsp dev team ;)
[09:22] <lamont> trying to get ltsp happy on gutsy...
[09:23] <Mithrandir> Keybuk: on the phone
[09:23] <lamont>         lpadmin (104)
[09:23] <lamont> Info: updating inetd config
[09:23] <lamont> that's where ltsp-build-client hangs
[09:23] <lamont> with update-inetd running and blocked on something - I wonder if it's the lack of /proc et al in the chroot
[09:23] <lamont> ogra: or is gutsy ltsp scary atm?
[09:23] <ogra> lamont, no, it should be fine
[09:24] <lamont> ogra: got a convenient howto?
[09:24] <ogra> but i fixed some bugs in the update-inetd code ...
[09:24] <lamont> and wth does it use /opt instead of /srv?
[09:24] <ogra> https://help.ubuntu.com/community/UbuntuLTSP/QuickInstall
[09:24] <ogra> nostalgic reasons :)
[09:25] <ogra> i think we'll switch soon, i get that question more and more often recently :)
[09:25] <lamont> uh... pg does not exist
[09:25] <sbalneav> lamont: At the time ltsp started up, /srv wasn't there yet :)
[09:25] <lamont> sbalneav: yeah
[09:25] <lamont> UbuntuLTSP/LTSPQuickInstall
[09:25] <ogra> lamont, weird, i'm using it since 1.5 years ...
[09:25] <lamont> and,uh, yeah.  I'm at the "sudo ltsp-build-client" step, and it's hung
[09:26] <ogra> more likely in the ltsp-update-image step (which is run by ltsp-build-client)
[09:26] <sbalneav> Man, if ltsp moves to /srv, I'm gonna have 8 years of muscle memory to undo.  cd / o tab l tab :)
[09:26] <lamont> root      3496  0.0  0.0   3968  1532 pts/1    S+   11:30   0:01          |   \_ /bin/bash /usr/sbin/ltsp-build-client --mirror http://archive.mmjgroup.com/ubuntu --security-mirror http://archive.mmjgroup.com gutsy-security main universe restricted multiverse
[09:26] <lamont> root     24364  0.0  0.0   3844  1356 pts/1    S+   11:37   0:00          |       \_ /bin/sh /usr/sbin/ltsp-update-image -a i386
[09:26] <lamont> root     24403  0.0  0.4  12808  9700 pts/1    S+   11:39   0:00          |           \_ /usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/update-inetd --group LTSP --add 2000               stream  tc
[09:26] <lamont> debconf seems to be very unhappy with ltsp-update-image
[09:27] <ogra> hmm
[09:27] <ogra> it uses passthrough
[09:27] <lamont> and it's 13:27 here, so I I think that means it's hung...
[09:27] <ogra> yeah
[09:27] <ogra> likely my recent changes, sorry
[09:27] <lamont> and nothing in /proc about it
[09:27] <lamont> and oh btw, you'll notice that --security-mirror seems to append /ubuntu automagically to the name
[09:27] <ogra> even though i built an image today that worked, weird+
[09:28] <lamont> which will break ports, if nothing else...
[09:28] <ogra> can you bug that ?
[09:28] <lamont> ogra: yeah
[09:29] <ogra> thanks :)
[09:29] <lamont> and at some point, it'd be nice if it used ipv6's built in ipsec instead of ssh-ing everywhere...
[09:30] <okaratas> hello
[09:30] <ogra> erll, we somewhat rely on the ssh ability to offer siocekts for established tunnels ... not sure thats easily replaceable by ipsec
[09:30] <ogra> *sockets
[09:30] <lamont> right
[09:30] <wasabi> Sillyness.
[09:31] <wasabi> Compiz crashes my X server on my plain ol' new NVidia card.
[09:31] <lamont> I just meant for the getting-back-to-the-server default stuff
[09:31] <wasabi> Sounds like it should be enabled by default to me!
[09:31] <lamont> wasabi: compiz doesn't do anything on my computer... but then, I don't install it.
[09:31] <lamont> hrm... actually, it is installed.
[09:31] <lamont> but fglrx isn't, since I like to have working suspend
[09:32] <Keybuk> wasabi: file a useful bug report instead of whining
[09:32] <lamont> Keybuk: party pooper. :-)
[09:33] <ogra> wasabi, else Keybuk will take out the ability to disable compiz :P
[09:33] <wasabi> oh noes. =/
[09:35] <ogra> hmm, finishes fine here, weird
[09:35] <ogra> grmbl
[09:36] <ogra> i should probably use up to date software ...
[09:36] <okaratas> ls
[09:36] <okaratas> clear
[09:36] <okaratas> hm sorry, please...
[09:36] <ogra> no, we'll never forgive
[09:37] <ogra> :)
[09:38] <ogra> lamont, i think i know what broke ... ltsp-update-image tries to write to $CHROOT/etc/ltsp which doesnt exist
[09:38] <ogra> lamont, sudo mkdir /opt/ltsp/i386/etc/ltsp && sudo ltsp-update-image
[09:40] <lamont> how much does server speed affect the client machine's performance?
[09:40] <ogra> not at all ... the client runs as standalone diskless system ... the question is how much does server speed affect the users sessions ;)
[09:41] <ogra> since after login 98% of your stuff run on the server
[09:41] <lamont> why would it run on the server/
[09:41] <ogra> the client is only an input/output device
[09:41] <lamont> client is basically a remote display with stuff?
[09:41] <lamont> riht
[09:41] <ogra> yeah
[09:42] <lamont> hrm... I hope my family doesn't mind when I dump all 3 of them on a PIII/933.
[09:42] <ogra> its boots to a login manager, which then basically does ssh -X user@server /etc/X11/Xsession
[09:42] <lamont> 2-way, so it's not quite _that_ bad
[09:42] <lamont> that directory fixed the update-image
[09:43] <ogra> yay
[09:43] <lamont> docs on how to update things, etc?
[09:43] <lamont> and what use is made of the image?
[09:43] <ogra> https://help.ubuntu.com/community/UbuntuLTSP/LTSPWithoutNFS
[09:43] <lamont> and should I worry that i386.img is 129MB
[09:43] <lamont> ?
[09:43] <ogra> not many docs yet
[09:43] <lamont> tahnks
[09:43] <ogra> no. thats perfect
[09:44] <ogra> (the chroot is over 300MB :) thats a pretty good compression rate )
[09:44] <dobey> does the xgl package in gutsy enable itself as an alternate session that you can choose through gdm?
[09:45] <ogra> i'd like to get rid of the chroot at some point to save diskspace, but for gutsy we want to give users an easy ability to switch to fs if they want
[09:45] <ogra> s/fs/nfs/
[09:45] <lamont> ogra: so clients are chrooted into that chroot, and anything they need should be installed in that chroot, and run ltsp-update-iameg
[09:45] <lamont> eys?
[09:45] <tonyy> dobey: gutsy doesn't use xgl I'm sure
[09:45] <lamont> yes, even?
[09:45] <ogra> yeah
[09:46] <moquist> ogra: LTSPWithoutNFS is a good read.
[09:46] <moquist> (thx)
[09:46] <dobey> tonyy: not by default, but the package is installable, and enables itself when you install it
[09:46] <ogra> if you want extra stuff on the client, thats the way to do it ... but usually the default image in combination with lts.conf should do
[09:46] <ogra> moquist, thanks :)
[09:47] <ogra> lamont, its a bit manual work still, i hope to have http://people.ubuntu.com/~ogra/LTSPManager/ ready for hardy that will do everything in a nicer way :)
[09:48] <lamont> ogra: it would be nice if ltsp-manager had an instance that didn't drag in dhcp-server...
[09:48] <mathiaz> keescook: I've updated the apparmor package.
[09:48] <lamont> since the machine where I have the roots is _NOT_ the dhcp server for the network.
[09:48] <ogra> lamont, yeah, i'll take that into account ... the initial thing was designed for a standalone server
[09:48] <mathiaz> keescook: I've published a new version in my branch, which has an updated avahi-daemon profile.
[09:49] <ogra> plan is to have it being an enterprise tool at some point to manage all your ltsp servers in a network
[09:49] <lamont> ogra: having it Recommend the dhcp server and depend standalone| $theotherone would be nice
[09:49] <ogra> but its still in pre alpha ... i'm simply missing the time
[09:49] <lamont> of course, if it's not standalone, then you have to tell me to copy the dhcp snippet over...
[09:49] <lamont> yeah - I'll wind up removing ltsp-manager for now
[09:50] <ogra> or have remote clients on every server somehow ...
[09:50] <ogra> yeah, its more a mockup than an ap atm
[09:50] <lamont> well... my config is one server, dhcp is "over there" though on a different box
[09:50] <ogra> i'll add a popup warning and a note to the package description before release
[09:53] <lamont> of course, the 121 packages it dragged in were a bit amusing
[09:55] <ogra> heh, yes supporting a lot of stuff costs a lot
[09:55] <ogra> oh, you mean ltsp-manager ?
[09:55] <ogra> eek
[09:57] <lamont> after removing ltsp-manager and ltsp-server-standalone, apt-get autoremove removed 121 packages
[09:58] <lamont> you want the list?
[09:58] <lamont> (the machine is basically ubuntu-{minimal,server}
[09:58] <lamont> er, s/server/standard/
[09:59] <ogra> oh, you'll need -desktop
[10:00] <Mithrandir> Keybuk: I'm around for about five minutes more now.
[10:00] <ogra> unless you want to run the desktop elsewhere ... then it gets intresting :)
[10:01] <lamont> ogra: won't I need desktop in the chroot, rather than the real root?
[10:01] <ogra> yeah
[10:01] <ogra> in the real root was what i meant
[10:01] <lamont> ??
 (the machine is basically ubuntu-{minimal,server}
[10:02] <ogra> the machine needs -desktop
[10:02] <lamont> s/machine/machine's real root/
[10:02] <ogra> yeah
[10:02] <lamont> the client chroot is whatever ltsp-build-client built
[10:02] <ogra> right
[10:02] <lamont> sufficient? or does the real root need -desktop?
[10:02] <ogra> the real system needs a desktop where you can log in to from the client
[10:03] <lamont> client logs in (with ssh) and runs what?
[10:03] <ogra> as i said, the login manager does basically: ssh -X user@server /etc/X11/Xsession
[10:04] <ogra> in gutsy we added the option to set DISPLAY pointing to the client, so you can circumvent encryption for X but keep secure passwords if you find encryption to slow
[10:05] <ogra> lamont, btw, sbalneav works on the edubuntu-docs package that should have more detailed docs, its in his PPA
[10:06] <ogra> we have the most recent ltsp docs in there
[10:06] <sbalneav> lamont: You just trying out ltsp?  Or this for work?
[10:06] <lamont> sbalneav: family
[10:06] <sbalneav> Cool
[10:06] <wasabi> Hmm. I suspect this new kernel has hosed my vmware too
[10:07] <wasabi> blah
[10:08] <ogra> sbalneav, eeek BASE=${BASE:-"/opt/ltsp/"} .... IMGDIR="${BASE}/images" ... CHROOT="${BASE}/${ARCH}"
[10:08] <ogra> double dahes everywhere
[10:09] <ogra> *dashes
[10:09] <sbalneav> yeah, I fixed that
[10:09] <ogra> you didnt commit, did you ?
[10:09] <sbalneav> don't know where that last dash came it
[10:09] <ogra> or push
[10:09] <sbalneav> I did indeed. At least I think so...
[10:09] <lamont> ogra: those are called slashes. :)
[10:09] <ogra> heh, right
[10:09] <sbalneav> lemme check
[10:09] <ogra> i should stop for the day, 12h are enough
[10:10] <sbalneav> Whoops
[10:10] <sbalneav> no I didn't
[10:11] <sbalneav> Hold fix now...
[10:11] <ogra> sbalneav, bad thing is that everyone using the 5.0.28 and 29 packages has the image entry with double slash in inetd.conf now :/
[10:11] <sbalneav> How did we get that in there?
[10:11] <ogra> it uses ${IMAGE}
[10:12] <ogra> for update-inetd
[10:12] <ogra> and it uses ${IMAGE} to check if the image is already there
[10:12] <ogra> next check will be without doubleslash now ... so it wont find it and add an entry *sigh*
[10:13] <ogra> its just a wasted extra entry, but still ugly
[10:14] <sbalneav> Well, chances are not a huge number of people are affected.
[10:14] <ogra> well ... my friend <joebob777as7> will be ...
[10:14] <sbalneav> ok, pushed
[10:28] <ogra> merged, pushed, packaged, uploaded ... :)
[10:31] <ogra> but before ....
[10:31] <desrt> moodle rocks my world!
[10:31] <ogra> night all
[10:31] <desrt> ta :)
[10:32] <Mithrandir> yo, desrt
[10:32] <desrt> hello.
[10:32] <Mithrandir> how's you, yourself, .ca and Annika (sorry about the spelling if that's wrong)
[10:33] <desrt> i am fine.  my country is starting to cool off and anneka is in ottawa
[10:36] <desrt> did i send you the picture near the beach?
[10:40] <Mithrandir> I don't think you, did, no.
[10:42] <wasabi> wonder if the new nvidia driver is causing all these segfaults. =/
[10:42] <wasabi> wonder if nv even supports my card in 2d
[10:44] <Kopfgeldjaeger> cu
[10:45] <tepsipakki> wasabi: if X starts, the driver supports your card
[10:45] <wasabi> heh.
[10:45] <tepsipakki> oh you meant to switch nvidia -> nv?
[10:45] <wasabi> yeah
[10:46] <tepsipakki> I'd be surprised if it didn't support what's in the blob
[10:46] <tepsipakki> since nvidia maintains both
[10:46] <wasabi> What's in the blob?
[10:46] <wasabi> Oh.
[10:46] <tepsipakki> er, supported by the blob
[11:20] <lucky_lucas> Is the ati driver blacklisted until the release ? Or may we have it back in a while ?
[11:31] <torkel> lucky_lucas: I think they changed it in the latest release not to blacklist all ati cards, but instead doing it by using pci id's
[11:32] <lucky_lucas> ok, it's safer like this, because I had systematic crash when running compiz
[11:33] <lucky_lucas> And I have read that compiz will be enabled by default so it was somehow critical
[11:38] <asac> siretart: i saw that too ... the interesting thing is that i sometimes still get garbage replies with 0.6.0 while i don't get that with 0.5.8
[11:39] <asac> siretart: i don't say that this is a bad thing ... i only say that there appears to be a case where wpasupp really returns garbage ...
[11:48] <stdin> hmm, apparmor doesn't seem to want to release, it was published nearly 24 hours ago but it's not in the archive yet
[11:49] <mathiaz> stdin: yes. There are some dependcy problems.
[11:49] <mathiaz> stdin: it still depends on some packages that are in universe. It has been fixed in the bzr tree.
[11:50] <stdin> ahh, ok
[12:26] <keescook> mathiaz: okay, great
[12:27] <keescook> mathiaz: though something odd is going on -- apparmor should be published (https://launchpad.net/ubuntu/+source/apparmor/2.1+961-0ubuntu2) but is not showing up in the archive.
[12:28] <mathiaz> keescook: may be an archive-admin should have a look at it ?
[12:28] <keescook> mathiaz: yeah, asking now...
[12:30] <geser> keescook: apparmor is in bin-NEW because of libapparmor1-dev
[12:31] <keescook> geser: aaaah, thanks.  where'd you see that?
[12:31] <geser> https://edge.launchpad.net/ubuntu/gutsy/+queue
[12:32] <keescook> I wish that was linked from the packages.  ;)
[12:32] <geser> and when you expand one of the apparmor entries you can see a NEW before the -dev package
[12:33] <geser> keescook: start at https://edge.launchpad.net/ubuntu/ -> Series: gutsy -> Actions: Show uploads
[12:33] <ajmitch> at least binary NEW packages tend to be processed quite fast, if there's an archive admin awake