[01:10]  * lamont wonders if any german speakers are awake for a totally-off-topic translation question
[01:11] <Hobbsee> heh
[01:11] <Hobbsee> try #ubuntu-de?
[01:11] <lamont> feh
[01:11] <lamont> be logical.
[01:11] <Hobbsee> my german won't be anywhere near good enough
[01:12] <lamont> Hobbsee: they're all speaking german there!!!! :-)
[01:13] <Hobbsee> they should speak some english :P
[01:15] <StevenK> Wouldn't it be funny if lamont got kicked for speaking English ...
[01:18] <lamont> StevenK: hehe
[01:18] <lamont> they sent me to google
[01:18] <StevenK> Haha
[01:21]  * ScottK looks around for an archive admin ...
[01:22] <StevenK> Bit late for them.
[01:22] <ScottK> True.
[01:22] <ScottK> I thought maybe slangasek or Hobbsee might be up and about.
[01:24]  * lamont tickes Hobbsee 
[01:24]  * Hobbsee stomps on lamont's feet
[01:24] <lamont> ScottK: I give you Hobbsee, live and in person.
[01:24]  * Hobbsee bites
[01:24] <ScottK> Heh.
[01:24]  * Hobbsee claws
[01:24]  * Hobbsee uses the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! ™ on ScottK
[01:25]  * Hobbsee sets lamont and ScottK on fire
[01:25] <ScottK> Hobbsee: After you're finished chewing on lamont, would you please accept the 3 uploads sitting in dapper backports?
[01:25] <lamont> "Jesus saves.  Gretsky steals, shoots,  SCORES!!!"
[01:25]  * ScottK warms up.
[01:25] <ScottK> (It's been cold here lately)
[01:25] <ScottK> Thanks.
[01:25] <Hobbsee> let me see....
[01:26] <lamont> 'twas below zero (Fahrenheit even...)  this morning
[01:26] <Hobbsee> sylpheed* and php*?
[01:26] <ScottK> Yes.  Two for slypheed.
[01:26] <Hobbsee> yep.  done.
[01:26] <lamont> php-clamavlib_0.12a-4~dapper1_source.changes
[01:26] <lamont> sylpheed-claws_1.0.5-5.1ubuntu0.1~dapper1_source.changes
[01:26] <lamont> sylpheed-claws-gtk2_2.6.0-1.1ubuntu1.1~dapper1_source.changes
[01:26] <ScottK> Hobbsee: Thanks.
[01:26] <Hobbsee> you're welcome
[01:26] <lamont> we now return you to your regularly scheduled topic.
[01:26] <lamont> (and thanks)
[01:27]  * Hobbsee sets lamont on fire again, then.
[01:27] <lamont> ah.  warmth.  thanks
[01:27] <lamont> danke, even
[01:27] <Hobbsee> :)
[01:29]  * Hobbsee smashes edge with a large brick
[01:31] <lamont> edge or edgy?>
[01:32] <Hobbsee> lamont: can you do it somehow?  launchpad is scrweing up.  again.
[01:32] <StevenK> I'm suspecting edge.launchpad.net
[01:32] <StevenK> Ah. I was right
[01:32] <Hobbsee> it's edge.  and production.
[01:33] <ScottK> How can LP be screwing up, Ubuntu doesn't have a release or freeze on right now?
[01:33] <Hobbsee> edge fails with a timeout, production fails with a non-timeout-oops.
[01:34] <lamont> oh.  edge.  yeah
[01:34] <lamont> Hobbsee: what exactly are you doing that's timing out?
[01:34] <lamont> (url??)
[01:35] <Hobbsee> accepting the dapper backports packages
[01:35] <Hobbsee> https://edge.launchpad.net/ubuntu/dapper/+queue?queue_state=1&queue_text=
[01:35] <lamont> Hobbsee: and I have your OK to accept those on your behalf?  (just to see if it'll work for me)
[01:36] <Hobbsee> lamont: yeah
[01:36] <lamont> Waiting for edge.launchpad.net.................................
[01:36] <lamont> Accepting Results:
[01:36] <lamont> OK: sylpheed-claws-gtk2, OK: sylpheed-claws, OK: php-clamavlib
[01:36] <lamont> not the quickest update I've ever seen
[01:37] <Hobbsee> right, so it works for you then?
[01:37] <lamont> yeah.
[01:37] <lamont> I should have just done one, then we could have played more.
[01:37] <lamont> sorry
[01:37] <lamont> hopefully it's not duck-related.
[01:37] <Hobbsee> thanks
[01:37] <Hobbsee> ScottK: upload more crackports, please
[01:38]  * Hobbsee tried it multiple times
[01:38] <ScottK> Hobbsee: You need to get the tech-board to approve my core-dev application before I can do it without a beard like lamont.
[01:38] <ScottK> ;-)
[01:39] <Hobbsee> hehe
[01:39]  * Hobbsee has almost no say over the techboard, sorry
[01:39] <Hobbsee> when did they want their meeting?
[01:39] <lamont> Hobbsee: I wonder if maybe it's because ScottK's sig is on the .dsc files...
[01:39] <Hobbsee> lamont: as to why it got into unapproved?
[01:39] <lamont> no, as to why it OOPSed
[01:40] <ScottK> Hobbsee: All backports go to unapproved.
[01:40] <lamont> because crackporting is an unapproved activity
[01:41] <lamont> Uploaded By:  Scott Kitterman
[01:41] <lamont> WIN
[01:41] <lamont> https://edge.launchpad.net/ubuntu/+source/sylpheed-claws/1.0.5-5.1ubuntu0.1~dapper1
[01:42] <ScottK> I got accepts for all three.
[01:42] <lamont> PENDING: Dapper  pocket Backports  in component universe  and section mail
[01:42] <lamont> it's in universe... you could have done that one
[01:43] <lamont> same for -gtk2
[01:43] <ScottK> lamont: Nope.  Backports uploads always take a core-dev
[01:43]  * lamont grumbles at ScottK 
[01:43] <lamont> oh, really?
[01:43] <ScottK> Even for Universe.
[01:43] <ScottK> Yeah.
[01:43] <lamont> how, interesting
[01:43]  * lamont ponders, remembers whyu
[01:48] <zul> lamont has a beard?
[01:48] <lamont> zul: no, apparently I _am_ one
[01:48] <zul> ah ok apparently i missed that part
[01:49] <ScottK> And a very helpful one at that.
[01:50] <StevenK> I don't see how beards are helpful in the usual case ...
[01:50]  * ScottK neither (it's really pretty obsolete), but it seemed like a funny way to put it.
[01:51] <ScottK> Thanks again Hobbsee and lamont.
[01:53] <ScottK> That's 8 down.  6 to go.
[01:53] <Hobbsee> you're welcome
[02:25]  * lamont stares at his firewall rulesete
[02:25] <lamont> s/e$//
[02:28]  * ScottK looks at the 1807 packages needs-building for Hardy and despairs his dapper-backports will ever build.
[02:29] <LaserJock> seriously?
[02:30] <ScottK> Yeah.
[02:30] <ScottK> That's down about 100 already from it's peak.
[02:32] <lamont> ScottK: launchpad.net/+builds shows 104 for i386
[02:32] <ScottK> Well these are all arch: any, so whatever you did to hppa is going to slow things down.
[02:33] <lamont> huh?
[02:33] <lamont> your backports will be a while before hppa (655) gets to it, but what do you care?
[02:33] <lamont> or does it actually require it to be current everywhere before it publishes (/me thinks "no")
[02:37] <ScottK> lamont: Now, but I won't relax until it's all done.  Only clamav needed to go through binary New and that's done.  That's the only one it would have mattered for.
[02:39]  * lamont wears his "being good" hat
[02:39] <lamont> Hobbsee: did you try to accept all 3 packages each time (edge)?
[02:40] <lamont> or just one?
[02:40] <Hobbsee> all
[02:40] <lamont> if it happens again, try just one at a time... 'twould be an interesting data point
[02:40] <lamont> word is that it's not duck-related
[02:44] <bddebian> I suppose pitti is asleep this time of day?
[02:45] <zul> most likely
[06:38] <warp10> Heya
[07:35] <jackdaw> hello, i
[08:25] <pitti> Good morning
[08:25] <pitti> bdmurray: hi
[08:26] <pitti> bdmurray: unping; that was supposed to be 'bddebian'
[08:29] <gaspa> pitti: morning.
[08:31] <pitti> hey gaspa
[08:31] <pitti> gaspa: getting to your mail, promised (I'm a bit backlogged on the sprint)
[08:31] <gaspa> pitti: np.
[08:32] <gaspa> i'm not in a hurry. :)
[08:32]  * gaspa remembers someone's blog... :P
[08:46] <Keybuk> calc: openoffice.org-core overwrites something in common
[09:02] <mpt> Gooooooooooooood morning Ubuntu lovers!
[09:06] <TheMuso> mpt: isn't that a bit old? :p
[09:06] <mpt> TheMuso, old? It's only the second time I've ever said it
[09:07] <TheMuso> mpt: Well ok then.
[09:08] <RAOF> mpt: TheMuso works on fuzzy pattern-matching, so it *is* a bit old :)
[09:09] <TheMuso> RAOF: lol
[09:10] <bdmurray> pitti: wow, that usually happens the other way around
[09:15] <pitti> bdmurray: ETABCOMPLETION :)
[09:23] <slangasek> ScottK: this is sprint week, it's late for me too. :)
[09:42] <geser> good morning
[09:46] <pitti> hi geser
[09:52] <geser> Hi pitti
[09:54] <ion_> Freenode.find_by_channel_and_status('#ubuntu-devel', :nonidle).each {|person| greet person }
[10:03] <evand> Anyone have an objection to me building a new i386 desktop CDs, or know what the giant warning in cdimage's crontab means?  pitti, slangasek?
[10:03] <slangasek> evand: which warning, the "do not re-enable"?
[10:04] <slangasek> that one means that I failed to delete the warning when reenabling the cronjobs
[10:04] <asac_the_2nd> bryce: http://ubuntuforums.org/showthread.php?t=669262
[10:04] <evand> slangasek: heh, gotcha
[10:04] <evand> and yes, that one
[10:05] <slangasek> evand: it definitely doesn't apply, since the cronjobs below it are all enabled ;)  so yeah, if you need a new desktop build, go ahead
[10:05] <evand> ok, I'll remove the warning as well then
[10:07] <asac_the_2nd> bryce: its bug 182038
[10:07] <ubotu> Launchpad bug 182038 in xserver-xorg-video-nv "Black rectangle instead of image in FF3 [Hardy]" [Undecided,Confirmed] https://launchpad.net/bugs/182038
[10:12] <calc> Keybuk: yea i'll have to fix that in the next upload :\
[10:12] <tjaalton> asac_the_2nd: I'll forward it upstream (xorg)
[10:13] <calc> Keybuk: the work around for now is to uninstall the package it is overwriting, it should have replace/conflict that old package version :\
[10:13] <asac_the_2nd> tjaalton: thanks
[10:26] <seb128> lifeless: http://bugzilla.gnome.org/show_bug.cgi?id=264264 looks like your issue but it has been duplicated and the other bug has been closed so you might want to reopen or open a new one
[10:26] <ubotu> Gnome bug 264264 in Mailer "Crash: mouse grab freeze during mail DnD" [Normal,Resolved: duplicate]
[10:34] <lifeless> thanks seb128
[10:34] <seb128> you are welcome
[10:35] <calc> mjg59: ping
[10:58] <asac_the_2nd> ogra1: http://bazaar.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.7
[11:05] <asac_the_2nd> ogra1: deb http://ppa.launchpad.net/asac/ubuntu hardy main
[12:00] <emgent> heya *
[12:49] <calc> anyone happen to know why the regular gstreamer plugins don't do mpegdemux, just the fluendo plugin?
[12:50] <calc> is it a patent issue or something like that?
[12:50] <calc> "The main difference between this and the plugin from gst-plugins-ugly is that this one allows demuxing of MPEG2 transport streams.
[12:50] <calc> "
[12:54] <hunger> q
[12:56] <calc> seb128: i see the weather is a tooltip actually on the new clock but the temperatures seem off
[12:57] <calc> seb128: it claims it is -20C in Houston, heh
[12:58] <calc> that would be about like Hell freezing over ;)
[12:59] <seb128> calc: it seems to be working for me
[13:00] <seb128> calc: 3.6°C for Houston here
[13:00] <calc> it actually says '-4.7F' i did the conversion in units
[13:00] <calc> is there a way to force the clock applet to update (like there is in gweather)?
[13:01] <seb128> not that I know
[13:01] <seb128> 38.6°F for houston
[13:01] <zul> calc: -20C is nothing
[13:01] <calc> zul: in Houston it is
[13:02] <calc> zul: Houston is probably > 15C right now
[13:02] <zul> only :)
[13:02] <calc> zul: ah well 3.6C anyway (its still early in the day there)
[13:02] <calc> seb128: switching back to C it says -20.4C heh
[13:03] <calc> seb128: oh i know what is wrong
[13:03] <zul> calc: -9C outside where I am
[13:03] <calc> seb128: i have to pick a timezone not a city, so its giving me the temp for chicago
[13:03] <seb128> calc: picked the wrong houston?
[13:04] <seb128> calc: hum? I picked the Houston Intercontinental Airport in the locations list
[13:04] <calc> seb128: i am now more confused than before, i see what i did wrong finally
[13:05] <calc> seb128: i picked America/Chicago and didn't even notice the "Find" button
[13:05] <calc> oops
[13:05]  * ogra1 is a bit irritated by all the popunder windows
[13:05] <calc> hmm when i changed to Houston Intercontintental it changed my timezone setting
[13:06] <calc> to Monterrey, not sure if that is the same as Chicago so I switched it back
[13:06] <calc> works now though for temp :)
[13:12] <calc> anyone else notice gweather (applet) complains about it can't find the xml locations file?
[13:14] <calc> ah i see a bug is already filed
[13:37] <pecisk> nautilus-connect-server will return soon? :) gvfs works nicely so far with ssh connections
[13:37] <seb128> pecisk: no
[13:39] <seb128> pecisk: gvfs does mounting now and the mounts are listed, gnomevfs worked differently
[13:39] <pecisk> I see, but nautilus-connect-server dialog will be rewriten or something else will come?
[13:40] <seb128> pecisk: not clear yet, you can read the mail sent by alex on the GNOME desktop list this morning on the topic
[13:42] <bryce_> seb128: btw, that bug I showed you earlier appears to also occur with xterm, so is probably not gnome terminal specific
[13:43] <pecisk> seb128: I quite don't get it. How someone will create connection to server?
[13:44] <pecisk> ok, I will read all thread
[13:44] <pecisk> thanks for info
[13:44] <pecisk> :)
[13:45] <seb128> bryce_: looks like a xorg issue ;-)
[13:45] <bryce_> :-P
[13:45] <seb128> pecisk: ctrl-L, enter your URI, the server is automatically mounted on first use and stay there
[13:46] <seb128> pecisk: gnome-vfs didn't do this mounting so the connect server was an handy way to use the same URL again
[13:46] <seb128> that was basically opening URI every time you used the shortcut
[13:47] <pecisk> I see
[13:47] <pecisk> but CTRL+L is somehow very cryptic for common user
[13:47] <seb128> where now the mount stay there and is listed in all the applications during the session
[13:47] <pecisk> you have to enter all parameters there
[13:47] <seb128> not really
[13:48] <seb128> if you can connect somewhere and a password is required it'll ask for it
[13:48] <seb128> and you can browser smb shares
[13:49] <pecisk> hmmm
[13:49] <pecisk> yeah, I see know
[13:49] <pecisk> now
[13:49] <pecisk> when I think, this is much easier, I have to admit
[13:52] <pecisk> only question how to create shortcuts to reuse connections - as launchers?
[13:53] <seb128> pecisk: that is not done yet
[13:53] <pecisk> ok
[13:53] <pecisk> thanks for info, nice work guys
[13:53] <seb128> you are welcome
[15:11] <pochu> cjwatson_: hi. I'm still moderated in ubuntu-devel@lists.ubuntu.com. Could you please whitelist me? pochu@ubuntu.com. Thanks!
[15:17] <Hobbsee> pochu: mail unmoderated, anyway
[15:42] <MacSlow> mvo, having keyboard-shortcuts exposed in the window-action-menu needs a patch to libwnck, which would introduce a gconf-dependency
[15:42] <MacSlow> mvo, I asked vuntz and he said it would be ok if I provide a configure/compile-time settable option for this
[15:43] <mvo> MacSlow: where does it currently get the keyboard shortcuts from?
[15:43] <MacSlow> mvo, not at all
[15:43] <MacSlow> mvo, it's not exposing them in any way
[15:43] <mvo> but when I right-click, I see "ALT-F7" here etc
[15:44]  * MacSlow starts metacity...
[15:44] <MacSlow> hm... metacity does maybe not use libwnck for the action-menu?!
[15:45] <MacSlow> mvo, my gues was right... metacity does not use libwnck for the action-menu
[15:46] <mvo> MacSlow: right. perhaps we should also move that into gtk-window-decorator then?
[15:46] <MacSlow> mvo, I would like to fix that... I mean libwnck using gconf to obtain keyboard-shortcuts
[15:46] <MacSlow> mvo, hm... no... I don't like that
[15:46] <mvo> MacSlow: so that metacity would use it? yeah, that sounds better
[15:47] <MacSlow> not that I want to patch metacity afterwards too to use it...
[15:47] <MacSlow> just place stuff in the correct places
[15:49] <MacSlow> mvo, argl... crap...
[15:50] <MacSlow> mvo, retrieving the shortcuts from gconf will need to look for metacity- or compiz-specific keys explicitly
[15:51] <MacSlow> thus it would be required to do window-manager-specific code in libwnck...
[15:57] <stgraber> mvo: Are you aware of a bug causing aptitude and apt to produce lots of empty lines + confirming the upgrade/install (sort of simulating the enter key) ? (only happens when apt did "Calculating upgrade" or aptitude did "Building tag database" before)
[15:57] <stgraber> I have it for quite some time now and managed to reproduce it on all my Hardy systems so far
[15:59] <bryce_> kees, bug 184492 is being blamed on the gutsy xserver security update, but afaik the changes shouldn't have effected suspend at all...  can you take a look at this one and comment?
[15:59] <ubotu> Launchpad bug 184492 in xorg-server "xserver-xorg-core update breaks suspend in gutsy" [Undecided,New] https://launchpad.net/bugs/184492
[16:01] <bryce_> keescook: also bug 184869
[16:01] <ubotu> Launchpad bug 184869 in xorg-server "ALT Super keys swapped after upgrade" [Undecided,New] https://launchpad.net/bugs/184869
[16:05] <mpt> Keybuk, ExitStrategy involves a bit of kernel work now, so I'm not sure it belongs in the DesktopTeam/ wiki namespace
[16:10] <slangasek> lool: wrt your changelog entry for the latest nautilus upload, is there any handling for older packages that require nautilus-extensions-1.0?
[16:11] <slangasek> lool: I stumbled across this via totem, which is currently FTBFS because the build rules look for /usr/lib/nautilus/extensions-1.0; the FTBFS is an easy fix, but it set me to wondering about upgrade handling from older versions
[16:19] <lool> slangasek: seb128 wanted to upload nautilus as fast as possible and said we would add the Breaks when the packages are actually ready
[16:19] <lool> slangasek: The provides is just to be able to use Depends in the extensions instead of Breaks
[16:19] <lool> slangasek: After the extensions have been uploaded, we should add a Breaks on the old versions in nautilus
[16:20] <lool> seb128: ^
[16:21] <slangasek> lool: alrighty; as long as it's on your radar then
[16:21] <slangasek> in totem's case the nautilus extension is optional functionality, so I guess it should be exempt
[16:22] <lool> Hmm that's a good point
[16:22] <seb128> slangasek: it's optional functionality for most of the other packages as well
[16:22] <seb128> slangasek: totem, file-roller, evince
[16:22] <lool> We should use suggests or recommends then
[16:22] <seb128> Recommends when apt will install those in Ubuntu
[16:23] <slangasek> seb128: so do you want the breaks to apply to these packages?  they aren't really broken
[16:23] <lool> We should suggests or recommends as we see fit but recommends wont work until apt supports them :)
[16:23] <seb128> slangasek: no, that's why I uploaded nautilus yesterday
[16:23] <slangasek> maybe we need [Depends,Recommends,Suggests] and [Breaks,Bruises,Inconveniences]
[16:23] <lool> mvo: \o/
[16:24] <lool> slangasek: But what about Build-Recommends and Build-Suggests?   :-P
[16:24] <slangasek> heh
[16:24] <Mithrandir> slangasek: I want "Stabs" as well.
[16:43] <pitti> doko:    * lsb-cxx: Drop dependency on libstdc++5, not needed by LSB-3.1.
[16:43] <pitti> doko: WOHOOO!
[16:43] <pitti> doko: that sounds like we could drop gcc-3.3 to universe?
[16:47] <doko> pitti: lets see; talked with Matt Taggert and Marc Tardiff about it.
[16:47] <doko> pitti: please fix grub not to build with gcc-3.4 ;-)
[16:49] <soren> kvm needs gcc-3.4, too.
[16:50] <soren> Preemptive response to the inevitable "but that's not in main": Yet.
[16:51] <slangasek> postemptive response: better fix that if you want it to be? ;)
[16:53]  * doko will mention that in the MIR for kvm ...
[16:54] <soren> with a bit of luck Fabrice will fix this within a few days.
[16:54] <soren> (it's a qemu problem, really)
[16:54] <doko> please check as well, if it does build with gcc-snapshot
[16:54] <soren> It doesn't.
[16:59] <\sh> seb128, would like to do me a favour and work on https://bugs.edge.launchpad.net/ubuntu/+source/libmicrohttpd/+bug/184400 It's a blocker for a sync
[16:59] <ubotu> Launchpad bug 184400 in libmicrohttpd "[MoM SYNC] libmicrohttpd 0.2.0-1" [Undecided,Confirmed]
[16:59] <slangasek> joejaxx: did TheMuso talk to you yet about getting the ubuntustudio-desktop seed changed for the libpt-plugins package name change?
[17:00] <TheMuso> slangasek: No I had forgotten about that one, but I did talk to him about other seed related stuff, such as merging.
[17:00] <TheMuso> The funny thing is, if it was me doing seeds, I would have jst done it. :)
[17:01] <TheMuso> slangasek: joejaxx should be subscribed to get emails of seed changes, so he should know about that.
[17:01] <joejaxx> slangasek: nojoejaxx@venus:~/ubuntustudio.hardy$ cat desktop | grep libpt * libpt-1.10.10-plugins-v4l * libpt-1.10.10-plugins-v4l2
[17:01] <joejaxx> :)
[17:02] <joejaxx> but i already made the changes the day it was made :)
[17:02] <joejaxx> unless there was another change and i did not receive an email about it
[17:03] <slangasek> joejaxx: that's the one, yes.  any chance it can be uploaded then, so I can make the old ones disappear? :)
[17:03] <TheMuso> slangasek: Does that require a -meta refresh?
[17:04] <joejaxx> yes :)
[17:04] <TheMuso> Right.
[17:04] <TheMuso> joejaxx: You do that, and I;ll do the -meta.
[17:04] <joejaxx> TheMuso: ??
[17:05] <pitti> doko: grub> ah, that
[17:05] <slangasek> TheMuso: he said he already changed the seed, so isn't the -meta all that's left? :)
[17:06] <TheMuso> slangasek: Yes, but I thought there was also other stuff to be done as well.
[17:06] <TheMuso> for the studio seeds that is
[17:07] <slangasek> ah, ok; nothing else from my end, dunno what else you guys have pending
[17:08] <TheMuso> In any case, I'll do the meta. joejaxx if there is anything that I need to wait for you to do, plesae let me know now.
[17:08] <TheMuso> please
[17:08] <joejaxx> nope there is not :)
[17:09] <TheMuso> joejaxx: Ok thanks.
[17:09] <joejaxx> TheMuso: you are most welcome
[17:09] <joejaxx> :)
[17:09] <joejaxx>  /win 107
[17:09] <joejaxx> klfjgkfjgk
[17:10] <ion_> 107? Whoa.
[17:22] <keescook> bryce_: odd bugs.  there was nothing in the CVE fixes that were related to video drivers...
[17:23] <bryce_> keescook: well neither issue seems driver related
[17:23] <bryce_> keescook: otoh, I can't fathom why those would have broken from the update
[17:24] <keescook> yeah, and the 2nd one scares me a lot -- they have selinux enabled?  if so, their machine isn't running upstart.  who know what else is weird.
[17:30] <\sh> hmm...will  synced "new packages" (not in ubuntu yet) from debian directly be delivered to the archives or are they just pushed like "new packages to ubuntu" into the new queue?
[17:31] <slangasek> they have to go through binary new
[17:42] <seb128> \sh: just did the syncs, the new sources will be in NEW but we usually accept debian packages to universe quickly
[17:42]  * _MMA_ thanx seb128 for the Ardour sync.
[17:42] <\sh> seb128, thx :)
[17:51] <TheMuso> slangasek: About to upload the new meta now.
[17:51] <TheMuso> So you can do what you were going to do.
[17:51] <seb128> mr_pouit: around?
[17:52] <slangasek> TheMuso: cheers :)
[17:53] <mr_pouit> seb128: yes
[17:54] <seb128> mr_pouit: I did demote to xfce to universe, could you close all the tasks?
[17:54] <mr_pouit> seb128: ok ^^
[17:55] <seb128> thanks
[17:55] <seb128> mr_pouit: you can likely do it by mail like you opened the tasks ;-)
[17:55] <mr_pouit> seb128: I hope so :p
[18:08] <matteo> hi
[18:08] <matteo> Now running lintian...
[18:08] <matteo> E: amrenc_0.5.1~gutsy1_source.changes: bad-distribution-in-changes-file gutsy
[18:08] <matteo> that's definitely a lintian bug
[18:09] <lool> seb128: http://people.ubuntu.com/~lool/packages/cheese/2.21.5-0ubuntu1/hardy/cheese_2.21.5-0ubuntu1.dsc
[18:10] <lool> seb128: thanks
[18:11] <seb128> you are welcome
[18:17] <sistpoty|work> matteo: yes. looks like lintian was synced from debian instead of merged
[18:29] <ScottK> matteo: That's not a proper Ubuntu revision number
[18:29] <ScottK> matteo: If it's ubuntu something it'll know about gutsy
[18:29] <matteo> it's ubuntu hardy
[18:29] <ScottK> It looks like a backport to Gutsy from Hardy.
[18:30] <ScottK> It it's a sync from Debian, .changes should say unstable, and it'd be fine.
[18:30] <jdong> should there really be a linux64 binary on i386 Ubuntu? :)
[18:31] <sistpoty|work> ScottK: however lintian was synced from unstable... though I guess lintian doesn't know anything about gutsy, hardy etc. any longer
[18:31] <ScottK> sistpoty|work: It does.
[18:31] <ScottK> sistpoty|work: It just looks for an ubuntu revision before it remembers
[18:32] <ScottK> sistpoty|work: Debian incorporated all the Ubuntu changes in their version.
[18:32] <ScottK> sistpoty|work: If they missed a spot, then it's a bug.
[18:32] <sistpoty|work> ScottK: oh, cool.. didn't know that :)
[18:33] <ScottK> Now for backports, it'd be useful to have lintian look for either ubuntu or an ubuntu release name in the revision.
[18:33] <\sh> seb128, one sync you forgot (it's also new to ubuntu but in debian): bug #184389 :)
[18:33] <ubotu> Launchpad bug 184389 in ubuntu "Sync liboglappth from debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/184389
[18:38] <seb128> \sh: synced
[18:38] <\sh> seb128, thx a lot :)
[18:39] <seb128> you are welcome
[18:40] <Keybuk> mpt: it's probably easier to separate off the kernel work into a spec we can give to that team, and depending on it for various pieces
[18:41] <mpt> Keybuk, ok
[18:41] <mpt> (though it's only two sentences or so)
[18:43] <jdstrand> msg NICKSERV help
[18:43] <jdstrand> oops...
[18:49]  * zul hands jdstrand a "/"
[18:50] <jdstrand> thanks zul!
[19:18] <CarlFK> something changed in the last 12 hours to cause Jan 23 19:14:40 main-menu[3081]: WARNING **: Configuring 'grub-installer' failed with error code 1   http://dev.personnelware.com/carl/temp/Jan23/b/log/syslog
[19:19] <CarlFK> cjwatson: ping ^^^
[19:27] <shaya> I'm wondering who is in charge of apt?
[19:27] <shaya> or who knows its internals well?
[19:28] <jdong> shaya: ask your question and see if we know the answer?
[19:28] <shaya> want to know if there's some place I can look to see how apt does dependency management
[19:29] <shaya> i.e. determining which set of packages is "good"
[19:29] <shaya> for research project, don't want to reinvent the wheel
[19:29] <shaya> want to credit debian/apt for the work
[19:42] <ToyKeeper> shaya: You probably should just get the source and start reading...  with any luck, it may include enough documentation to answer your questions, but if not, the code shouldn't be too bad.
[20:18] <desrt> dearest #ubuntu-devel, plz upload new flashplugin-nonfree package to gutsy!!
[20:19] <desrt> my fingers are getting sore from explaining how to fix this to everyone
[20:24] <lamont> slangasek: is it to late to ask for a sync of git-core from sid?
[20:28] <rzr> desrt: ask louder ..
[20:30] <Kmos> lamont: i think the feature freeze is only near 4th february
[20:30] <ScottK2> Kmos: 14 Feb.
[20:30] <Kmos> or that :)
[20:30] <Kmos> so it now has a fixed date, nice.
[20:30] <ScottK2> Kmos: It's been 14 Feb for a very long time.
[20:31] <Kmos> ScottK2: ok
[20:31] <Kmos> thx
[21:28] <matteo> hi all
[21:28] <matteo> where should I make a proposal about many packages?
[21:28] <matteo> i'll explain
[21:28] <matteo> newer dpkg supports other compression modes other than gzip
[21:29] <matteo> it supports bzip2 and lzma
[21:29] <matteo> using lzma with packages with docs will help a lot to riduce package size
[21:29] <matteo> since text compresses very well
[21:29] <ion_> I’m quite sure dpkg and apt in Ubuntu support lzma.
[21:30] <jdong> ion_: isn't that a hardy thing though?
[21:30] <ion_> Most likely.
[21:31] <matteo> yes, it's new in hardy
[21:42] <matteo> btw compressing it's very slow
[21:43] <matteo> but it's done once, in the buildd
[21:43] <matteo> http://pastebin.ca/870179
[21:44] <matteo> ~4MB saved on 26
[21:44] <matteo> exactly 15%
[21:44] <infinity> matteo: No need to "propose" it, we added the support for a reason.
[21:45] <matteo> "we"?
[21:45] <infinity> matteo: But we need to finish up infrastructure support before we start compressing anything with lzma.
[21:45] <matteo> are you in the core team?
[21:45] <jdong> matteo: he's buildd admin :)
[21:45] <infinity> matteo: Err, I run the buildds, among other things.
[21:46] <matteo> cool
[21:47] <matteo> man bc
[21:47] <matteo> oops
[21:48] <matteo> it's good to hear that the ubuntu team often change things
[21:49] <matteo> not being very conservative a-la-debian
[21:49] <matteo> also, the slowdown with bzip2 isn't too much
[21:49] <infinity> Debian's not all that conservative, per se, they just have more people to convince every time something changes.
[21:49] <matteo> so it could became the default compress mode
[21:49] <Mithrandir> matteo: uh, no.  It's much, much slower.
[21:50] <matteo> Mithrandir: twice
[21:50] <jdong> matteo: twice isn't much?
[21:50] <jdong> matteo: I guess when compared to lzma ultra, sure...
[21:50] <Mithrandir> it's not like people aren't complaining about unpack speed already..
[21:50] <matteo> jdong: imagine how many things you can put in the ubuntu CD
[21:50] <jdong> Mithrandir: lzma's unpack is in line with gzip IIRC
[21:50] <matteo> unpack is ever fast
[21:50] <jdong> definitely advertised by its author to be faster than bzip2
[21:50] <Mithrandir> jdong: it needs more memory or something, I thought?
[21:50] <matteo> just compressing is slow
[21:51] <jdong> Mithrandir: no, less memory than bzip2
[21:51] <jdong> Mithrandir: just compressing is a BEAST.
[21:51] <matteo> but compression is made *once*
[21:51] <jdong> right
[21:51] <jdong> and we have control over the compression hardware
[21:51] <matteo> the buildd make it, the it's just a mirror push
[21:51] <infinity> Decompression of lzma is still memory-intensive, comparatively.
[21:51] <mantiena-baltix> hi all
[21:51] <mantiena-baltix> lool: hi
[21:52] <infinity> Users with 4GB machines might not care, people with more conservative setups could be upset if we changed the default compression (so we won't)
[21:52]  * Mithrandir yawns and wanders off to bed.  See you all tomorrow.
[21:52] <infinity> The whole plan was to first change all the bzip2 packages to lzma (since that's an obvious win), then change some others where the space saving is too good to pass up.
[21:52]  * sladen really should just do a modified version of gzip with larger dictionary support.  It would have 95% of the cases we actually want
[21:53] <jdong> infinity: you're right, lzma levels 5 and higher are significantl more memory intensive then gzip
[21:53] <matteo> qt4-docs needs 34MB to uncompress with LZMA
[21:53] <matteo> that's on my system
[21:53] <sladen> lzma decompress (_not_ compress) is basically  dictionary size + extra
[21:53] <jdong> matteo: if we don't use level 9 to compress, it'd be a lot less
[21:53] <matteo> so it's definitely not a memory issue
[21:54] <jdong> matteo: hold on, 34MB decompression memory is not an issue?
[21:54] <matteo> impressive, lzma unpacks faster than bz
[21:54] <jdong> I'd say anything over 5MB is an issue
[21:54] <matteo> jdong: why?
[21:54] <jdong> matteo: on a minimal-requirements system, it would easily push into swap
[21:54] <matteo> ubuntu reccomends minimum 265MB ram
[21:54] <mantiena-baltix> sorry for disturbing, why you are talking about LZMA compression ?
[21:54] <jdong> mantiena-baltix: yes
[21:55] <sladen> bzip2 is ~2-4 * block size (900kB), so 4MB.  dictionary based (Deflate, LZMA) are going to win on decompression, with compression being an exp factor of dictionary size
[21:55] <jdong> matteo: ok, so booted to GNOME you're already using 130 or so in DE, open Firefox is 50MB, add restrited modules in there you barely have 30MB left over
[21:55] <jdong> matteo: and we *require* 64MB
[21:55] <jdong> matteo: we suggest 192MB
[21:56] <jdong> we only recommend 256 for desktop effects
[21:56] <sladen> jdong: I would cap the LZMA dictionary at 4MB, 8MB tops
[21:56] <jdong> sladen: agreed, unless the package significantly benefits and is only for high-end systems anyway
[21:56] <mantiena-baltix> jdong: you answer is pretty short for question "why ?" ;)
[21:57] <jdong> sladen: what's clear is that LZMA level 1 both compresses faster and better than bzip default....
[21:57] <jdong> well always faster, most times better
[21:57] <sladen> jdong: which is still 100x-200x the length for deflate
[21:58] <matteo> http://pastebin.ca/870199
[21:58] <jdong> sladen: oh I'm not gonna try to compete with deflate for resource usage :D
[21:58] <sladen> jdong: that's what I'd expect.  lzma is a dictionary compressor; compression is a case of string matching
[21:59] <sladen> jdong: bzip2 is a qsort of 900,000 strings of length 900,000 bytes
[21:59] <matteo> quicksort?
[22:00] <jdong> sladen: well can you show a deflate implementation with similar ratio to lzma without the resource usage?
[22:01] <sladen> jdong: sure.  for only for a dictionary of  < 2^15
[22:01] <matteo> you talks so much about decompression speed, ignoring completely download speed
[22:01] <sladen> jdong: deflate has hard-coded 20 year old limits.  LZMA doesn't
[22:01] <sladen> matteo: download *RAM* usage
[22:01] <jdong> sladen: I see. Isn't deflate with a bigger dictionary more or less lzma?
[22:02] <matteo> what's the problem with a 30MB usage?
[22:02] <sladen> jdong: yes.  But the coding stage on the backend that saves another 1% is semi-heavy, and could be left as the plain Huffman used in Deflate
[22:02] <matteo> apt uncompresses an archive at once
[22:03] <sladen> matteo: ...requiring 30MB to unarchive it?
[22:03] <matteo> and so?
[22:03]  * sladen hands matteo a 128MB machine with a LiveCD
[22:04] <mantiena-baltix> I have a simple question for any ubuntu developers - why wine packages in ubuntu gutsy and hardy are more than 3x bigger comparing with same wine packages in official winehq.com repository and also with older wine package from ubuntu feisty, edgy and dapper ?
[22:04] <_MMA_> sladen: Be realistic. :P
[22:04] <jdong> matteo: look you might not care about RAM usage just like how I am hooked up to 125MB/s internet and don't care about download speed :)
[22:04] <jdong> matteo: but 30MB is quite extreme for decompression RAM usage
[22:05] <sladen> _MMA_: what's unrealistic about that?
[22:05] <sladen> the problem here is that 30MB _is required_.  Otherwise decompression is _impossible_
[22:05] <_MMA_> jdong: So is having 80MB OO.o updates on dial-up.
[22:05] <jdong> _MMA_: I agree. both scenarios are unwanted
[22:05] <sladen> it is not using more RAM to make it go faster.  It is /necessary/ to have that much scrollback to copy and paste from
[22:06] <jdong> _MMA_: but 80MB download at a slow speed is POSSIBLE , while having insufficient free RAM to decompress is not very possible
[22:06] <jdong> _MMA_: it's not like if you feed it half the RAM it wants, ti'll decompress half as fast.
[22:06] <matteo> it's always possble
[22:06] <matteo> put something in the swap
[22:06] <matteo> extract
[22:07] <matteo> then restore it
[22:07] <matteo> the kernel does daily milion times
[22:07] <matteo> why can't we do once at setup time?
[22:07] <jdong> matteo: what about an openoffice update? You'd have an update manager, a GNOME DE, plus whatever else the user has running
[22:07] <_MMA_> Im just not always keep on holding back progress while worrying over 8 year old hardware.
[22:08] <jdong> _MMA_: well IMO dial-up is 20-year-old hardware. :P
[22:08] <sladen> _MMA_: "just works" means being compatible
[22:08] <jdong> done.
[22:08] <sladen> damn those 20Kbit/s connections people   ...via their mobile phone
[22:09] <_MMA_> sladen: Just my opinion. You have to cut things off sometimes. Not Vista-like but at some point things should move along.
[22:09] <_MMA_> If all you have is 128MB RAM use a Alt disk and Fluxbox.
[22:09] <sladen> _MMA_: indeed, so I think that finding a trade-off using ~3MB-4MB of dictionary would be good
[22:09] <jdong> _MMA_: it doesn't matter *WHAT* disk you use, an update later can easily require that you have 30MB RAM.
[22:10] <jdong> _MMA_: and on a system like that, there's not much idle stuff you can just swap out
[22:10] <mantiena-baltix> _MMA_: lots of people have slow connection in also in these days - for example in lithuania about 50% of internet users have slower than 128 kbit/s internet speed
[22:11] <matteo> sladen: i can't immagine the kernel unable to allocate 30MB ram
[22:11] <sladen> I've looked at many areas of compression within Ubuntu.   LiveCD, download-size, upgrade-minisize {size, download, time}, mirror size, ---the problem is that we can't optimised for all of them at once
[22:11] <_MMA_> jdong: Hence my opinion that our minimum required RAM is more like 256. Thats really not so much to ask.
[22:11] <_MMA_> s/is/should be
[22:11] <matteo> and RAM is very cheap
[22:12] <sladen> _MMA_: for X.  But not for a virtual server running Apache, that you might allocate 64MB to
[22:12] <jdong> matteo: I have several special-purpose systems with 64MB RAM running Ubuntu
[22:12] <jdong> matteo: and there's no reason why they should be unable to unpack linux-headers-generic now
[22:12] <_MMA_> sladen: Still I fell thats a corner-case.
[22:12] <mantiena-baltix> _MMA_: High Ubuntu RAM requiremens are because of putting ~35 MB of unneeded restricted modules in RAM
[22:13] <sladen> RAM does not grown on trees.  It grows in fast-eastern-Asian fabs
[22:13] <sladen> _MMA_: four corners, and you're trapping in a cage.
[22:13] <_MMA_> :)
[22:13] <jdong> mantiena-baltix: how do you propose storing them in license-compliant form? :)
[22:14] <sladen> jdong: I thought they were pruned if the hardware wasn't present after boot
[22:14] <jdong> sladen: nope
[22:14] <jdong> sladen: all three nvidia.o's, at 10MB/each or so, are in a tmpfs
[22:14] <jdong> sladen: it also adds around 2 secs to bootup
[22:16] <mantiena-baltix> jdong: there are at least 2 very simple solutions:
[22:16] <mantiena-baltix> 1. compile and store in RAM only these modules, which are really needed on that hardware
[22:16] <mantiena-baltix> 2. after installation restricted modules could be stored into hard disk instead of tmpfs in RAM
[22:17] <mantiena-baltix> almost nobody will need 3 nvidia modules at once
[22:17] <mantiena-baltix> each takes about 9 MB of RAM
[22:17] <jdong> mantiena-baltix: nobody, indeed, will use all 3 nvidia modules at once. the unused ones should certainly be removed from tmpfs
[22:17] <jdong> mantiena-baltix: our packaging doesn't even allow 3 userlands to be installed side by side
[22:18] <sladen> mantiena-baltix: (it _can't_ be stored onto the hardware disk => distribution in a linked form)
[22:18] <mantiena-baltix> so, I can't install different nvidia-glx packages if I have 2 different NVIDIA video cards on my system, which require different nvidia-glx package ?
[22:19] <jdong> mantiena-baltix: that's correct, they conflict each other
[22:19] <matteo> sorry
[22:19] <matteo> got disconnected
[22:19] <matteo> i was sayng
[22:19] <matteo> i work in the openwrt project
[22:19] <matteo> and we use lzma in routers
[22:19] <matteo> both kernel and rootfs
[22:19] <matteo> our machines has usually 8,12 or 32MB ram
[22:20] <jdong> matteo: well at boot time, you guys have full control over what's in the RAM (namely, nothing)
[22:20] <jdong> matteo: if we compressed the kernel with LZMA, I'd have zero complaints
[22:20] <matteo> and the rootfs?
[22:20] <jdong> matteo: what if you guys packaged your updates in LZMA that needed a 16MB dictionary to unpack? Would the nat conntrack tables be happy?
[22:20] <sladen> jdong: solution to the Nvidia issue might be to have a initramfs hook that causes a rebuild and adds a marker for which ones could be used
[22:23] <mantiena-baltix> jdong: If nvidia-glx packages conflicts each other and, AFAIK, nvidia-glx packages also conflicts with ATI/AMD xorg-driver-fglrx package, I think I have simple solution for this situation
[22:23] <mantiena-baltix> we don't need to link and put into tmpfs any of such modules until one of nvidia-glx or xorg-driver-fglrx packages is installed
[22:23] <jdong> mantiena-baltix: true, they can't be used simultaneously
[22:25] <mantiena-baltix> it's very simple to detect during boot time which of nvidia-glx or xorg-driver-fglrx packages is isntalled and link only needed nvidia.ko/fglrx.ko module or no modules at all if there are no nvidia-glx/xorg-driver-fglrx packages installed
[22:26] <mantiena-baltix> how you like my idea ?
[22:27] <bigon> does somebody know where http://paste.debian.net/47563 comes from?
[22:28] <bigon> I have reinstalled my hardy machine yesterday and I get that now
[22:28] <bigon> everytime I install something that call scrollkeeper
[22:29] <mantiena-baltix> also we need to check if NVIDIA/ATI hardware is on that system - one simple command: lspci |grep VGA does this job
[22:36] <mantiena-baltix> So, could anyone tell me why wine packages in ubuntu gutsy and hardy are more than 3x bigger comparing with same wine packages in official winehq.com repository and also with older wine package from ubuntu feisty, edgy and dapper ?
[22:36] <mantiena-baltix> I think it's a bug
[22:39] <mantiena-baltix> look at http://archive.ubuntu.com/ubuntu/pool/universe/w/wine/?C=S;O=D
[22:46] <BlackDiamonds> could some one take a look at this bug -> https://bugs.launchpad.net/ubuntu/+source/linux-wlan-ng/+bug/185179
[22:46] <ubotu> Launchpad bug 185179 in linux-wlan-ng "card is not recognized in live session" [Undecided,New]
[22:46] <BlackDiamonds> and say if the proposed solution is possible ?
[22:47] <mantiena-baltix> BlackDiamonds: I can look - I have linux-wlan-ng supported card now :)
[22:48] <BlackDiamonds> is it usb ?
[22:48] <mantiena-baltix> yes
[22:48] <BlackDiamonds> the current work around on the problem is to install the linux-wlan-ng package on a livecd session and then unplug, then replug the device
[22:49] <BlackDiamonds> this is really really annoying because the chipset is quite popular and a lot of people use it
[22:49] <mantiena-baltix> yea, I meet with this problem too
[22:49] <BlackDiamonds> I have been using work arounds for ages on various linux distros and it would be nice to finially see a solution to make it "just work"
[22:50] <BlackDiamonds> the best solution for the long term would have some one recode the drivers to make it support all of the kernel wireless extentions and then have it in the kernel but that will take a while, I hope an effort will start when the chipset is no longer being used in new cards
[22:52] <BlackDiamonds> mantiena-baltix, thank you very much for looking at the bug
[22:53] <mantiena-baltix> BlackDiamonds: Don't thank me - I'm not official ubuntu developer - I think you should make a bugreport to include linux-wlan-ng package into official ubuntu CD
[22:53] <BlackDiamonds> another bug report ?
[22:54] <BlackDiamonds> wouldn't it be best to keep it on this bug ?
[22:56] <mantiena-baltix> BlackDiamonds: I don't know - ask official ubuntu developers or search in wiki.ubuntu.com about this procedure
[22:56] <BlackDiamonds> alright thanks
[22:56] <BlackDiamonds> also any place to get an offical ubuntu developer ?
[22:57] <mantiena-baltix> I think here
[23:38] <Kmos> if some admin here.. the apport-retracer on datacenter is down..
[23:42] <mantiena-baltix> cool
[23:43]  * Mez points Kmos to #canonical-sysadmin
[23:45] <Kmos> Mez: thanks