[01:39] <YokoZar> why is traceroute not installed by default but traceroute6 is?
[01:40] <persia> My memory is that traceroute went away because it started requiring root.
[01:40] <persia> Should traceroute6 go away?
[01:40] <ScottK> I think there's another one.  Tracepath or something
[01:41]  * maco uses mtr
[01:41] <persia> Indeed.  tracepath is provided by default.
[01:41] <lamont> mtr is love
[01:41] <maco> (which, yes, i think is installed by default)
[01:42] <persia> maco: Only mtr-tiny is installed by default.
[01:42] <maco> persia: good enough :)
[01:42] <lamont> persia: that's good enough for most uses
[01:42] <lamont> really don't need the gtk version... :-)
[01:42] <YokoZar> Should we worry that System->Network tools has a table called "traceroute" when it's running (presumably) tracepath?
[01:42] <maco> ooh wait are you saying i can stop typing -t since i didnt go and install the not-iny version?
[01:42] <persia> YokoZar: If you want to investigate further, look into the iputils-tracepath package: perhaps traceroute6 shouldn't be there?
[01:43] <persia> maco: I'm just documenting my memory of the seeds.  How that affects your keyboard input is up to you :)
[01:43] <maco> heh
[01:44] <persia> YokoZar: Can you think of a good generic term for the operation?  If so, you could probably make an argument for the change based on HIG.
[01:45] <YokoZar> persia: Well traceroute is what most people are familiar with (windows users too).  tracepath isn't discoverable precisely because it's renamed.
[01:46] <persia> If you feel "traceroute" is a good generic term, then the GNOME Network Tools thing probably shouldn't change.
[01:47] <persia> You could investigate the differences between tracepath6 and traceroute6, and see if you could create an equivalent traceroute to go with tracepath.
[01:49] <ScottK> There was a reason we preferred tracepath over traceroute.  I don't recall what it was.
[01:49] <ScottK> Sounds like a potential job for command-not-found.
[01:49] <lamont> ScottK: better faster harder stronger, obviously
[01:49] <anon^_^> is there an appropriate channel to ask about backport consideration?
[01:49] <ScottK> I think it was actually smaller, but I don't recall.
[01:49] <persia> ScottK: The issue is that command-not-found would recommend installing 'traceroute'
[01:49] <persia> Rather than recommending the use of tracepath
[01:50] <ScottK> persia: command-not-found can do multiple things.  It could do both.
[01:51] <persia> That would need an improvement.  Current behaviour is to recommend installation of traceroute or traceroute-nanog
[01:53] <ScottK> Right.  Didn't say it was doing the job today, just that it perhaps should.  Then YokoZar's Windows using friends would find out about tracepath when they tried traceroute.
[01:53] <anon^_^> um hello?
[01:53] <anon^_^> lol
[01:53] <persia> Hrm.  Good point.
[01:54] <ScottK> anon^_^: This is probably as good a channel as any.  #ubuntu-motu might be slightly better.
[01:54] <anon^_^> Scottk, I was wondering about kernel 2.6.32 and if there was any possibility of it being backported for Karmic
[01:55] <anon^_^> Karmic has some pretty bad I/O issues which starve desktop responsiveness
[01:55] <YokoZar> anon^_^: it won't be
[01:55] <ScottK> Kernel backports aren't done through offiicial backports.  There's just linux-backports-modules (or similar)
[01:55] <YokoZar> anon^_^: We do have some plans to allow backported kernels in Lucid though, IIRC
[01:56] <persia> The issue with backported kernels is that often all sorts of odd bits break in unexpected ways.
[01:56] <YokoZar> Right, it needs lots of testing and so forth.  But without backporting kernels we had no way of enabling newer hardware updates.  So this is a problem, especially for LTS.  At least that was my memory of the discussion,
[01:57] <persia> Especially with stuff that requires kernelspace-userspace integration, like alsa, firewire, bluetooth, udev, etc.
[01:57] <anon^_^> Yeah, that's why I was hesitant to add pre-compiled 2.6.32 deb from http://kernel.ubuntu.com/~kernel-ppa/mainline/
[01:57] <anon^_^> to Karmic
[01:57] <persia> Well, if the interfaces haven't changed, one could just backport individual drivers, but that's lots more work.
[01:57] <YokoZar> and interfaces change all the time
[01:57] <persia> Yep, which is why it's just painful either way.
[01:58] <spowers> speaking of kernels, is there a minimum kernel required for booting lucid? i just tried a upgrade from jaunty to lucid in a Xen environment and ran into some problems with mountall and think it might have something to do with me running linux-image-2.6.24-24-xen
[01:58] <persia> Personally, I find it less painful to port a driver than to rebuild large dependency stacks, but then again, I'm not really a kernel person.
[01:58] <spowers> i think my issues are a good example of how userspace stuff gets tied up with kernel versions
[01:58] <lamont> spowers: I had serious issues running karmic on a jaunty kernel.. I expect lucid is at least karmic for a kernel base
[01:58] <persia> spowers: Indeed.  We know lucid boots with 2.6.31, but I'm not sure anything less than that has had significant testing.
[01:59] <lamont> though non-X stuff might work as far back as dapper even
[01:59] <persia> lamont: Nope.  Something changed with udev polling recently (.29 or .30, I think)
[01:59] <lamont> I upgraded a server from dapper to karmic without rebooting and without problems (other than that karmic didn't solve the issue I was having either, so it went back to dapper)
[02:00] <persia> heh.  "without rebooting" gives more flexibility :)
[02:00] <spowers> yeah, things were good until i rebooted
[02:00] <lamont> and trying to find what was wrong with a jaunty kernel on an i386 machine running karmic userspace was sufficiently fail that I installd a jaunty alternate-root and did the bisect there
[02:01]  * anon^_^ thanks chan for answers
[02:13] <crimsun> ok, seed change for libsdl1.2debian-foo covered (ubuntu, edubuntu, kubuntu, xubuntu, mythbuntu -- the latter two need explicit bzr merges)
[02:14] <ScottK> persia: Currently it appears that command-not-found lists traceroute as an alternative for tracepath, but not the reverse.
[02:14] <LLStarks> hi. i found a crash bug for synaptic. easy to replicate.
[02:14] <persia> ScottK: heh.  That's probably backwards.
[02:14] <ScottK> YokoZar: ^^^^ please fix to make your Windows friends happy.
[02:15] <ScottK> LLStarks: File a bug on Launchpad then.  Preferably using apport to provide a backtrace.
[02:15] <LLStarks> ubuntu-bug no good?
[02:15] <ScottK> No.  It doesn't have the backtrace.
[02:15] <ScottK> It's better than nothing if you can't manage apport
[02:16] <LLStarks> apport-bug is fine
[02:16] <LLStarks> i'll fike
[02:16] <LLStarks> *file
[02:18] <LLStarks> https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/508603
[02:20] <LLStarks> how do i collect the backtrace?
[02:20] <LLStarks> apport screwed up
[02:20] <persia> For "becomes unresponsive", it's decidedly difficult to obtain a backtrace.
[02:21] <persia> We usually differentiate "hang" (where an application stops responding), from "crash" (where an application ceases execution and drops from the process list)
[02:21] <LLStarks> i purposefully didn't use crash
[02:21] <LLStarks> wait. i did.
[02:22] <persia> In the bug, you didn't.  In your first message to the channel ("i found a crash bug for synaptic. easy to replicate.") you did.  That's why a backtrace was requested.
[02:22] <LLStarks> want me to gdb?
[02:22] <persia> If you know gdb, and can identify the problem, please add info to the bug.
[02:23] <persia> If you need help using gdb to identify the problem, ask in #ubuntu-bugs
[02:23] <LLStarks> you read my mind.
[02:23] <LLStarks> just for the record, ubuntu-devel maintains synaptic, right?
[02:24] <persia> Well, sure, but that's also true for every package in Ubuntu in some sense.
[02:24] <persia> synaptic gets more maintenance than some other stuff though.
[02:40] <YokoZar> Anyone else notice no non-default menu items showing up in lucid?
[02:43] <slangasek> crimsun: no, MIRs are for source packages
[02:44] <maco> sladen: ping? could use your help in #kubuntu
[02:45] <YokoZar> ScottK: https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/508606
[02:51] <LLStarks> persia, stupid question, but how did my nautilus tabs move to the bottom of the window?
[02:52] <LLStarks> i can't figure out how to get them back on top
[02:52] <persia> LLStarks: 1) why me?  2) I don't know, and 3) #ubuntu is a better channel for support (or #ubuntu+1 because you're running lucid)
[02:52] <LLStarks> ah ok
[02:53] <LLStarks> sorry
[02:53] <Laney> LLStarks: It was an upstream decision.
[09:42] <c_korn> can someone help me analyzing the scilab 5.2.0-1 build for amd64 ? it fails but the error log says "Built successfully" https://launchpad.net/~getdeb-package-managers/+archive/ppa/+build/1448702
[09:48] <persia> c_korn: http://wiki.debian.org/ImplicitPointerConversions
[09:48] <persia> (extracted from the very bottom of the build log)
[09:50] <c_korn> persia: oh, thanks. didn't see it.
[10:26] <wolter> hi, can somebody tell me which is the package that contains the notify-osd actions for volume control?
[10:26] <wolter> I reinstalled gnome-media and gnome-applets and now i have the old osd for volume control
[10:32] <wolter> anyway, whoever has an answer for me please leave it to me with memoserv [ /msg memoserv send wolter <your message here> ]
[12:00] <asac> pitti: really? ... http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile.html
[12:00] <asac> now it looks good
[12:01] <asac> not sure if you fixed something ... only thing i did was cleaning up all the Work items labels
[17:08] <kitallis> is notifyOSD a separate project or does it _depend_ on libnotify?
[17:21] <ScottK> separate project.
[17:23] <kitallis> ScottK: how does this little piece of code use libnotify to send the 'new' OSD notifs http://ubublogger.wordpress.com/2009/04/04/using-ubuntu-jauntys-new-notification-system-notify-osd/ then?
[17:26] <ScottK> I'm guessing it talks to it over dbus.  They use a compatible protocol on the wire.
[17:27] <kitallis> hm
[18:32] <dtchen2> is it possible to boot without activating plymouth (in lucid)? I can't diagnose why cryptsetup is failing if I can't see it :-)
[18:33] <hyperair> nosplash doesnt work?
[18:34] <dtchen2> no
[18:35] <hyperair> that sounds troubling
[18:37] <dtchen2> the problem is that regardless what boot parameters I pass, the modeswitch always occurs
[19:01] <bigon> is there a way to see the upload permission a user has on the LP?
[19:16] <geser> yes, through the LP API
[19:18] <geser> try edit_acl.py from lp:ubuntu-archive-tools
[21:04] <_Groo_> hi/2 all
[21:04] <_Groo_> siretart: ping!
[21:04] <_Groo_> siretart: latest libdirac breaks gstreamer bad plugins.. can you take a look at it when you have the time?
[21:04] <siretart> dirac hasn't been uploaded since quite some time
[21:05] <siretart> I've done a no-change upload of gst-plugins-bad to rebuild it against the new dirac, though
[21:05] <siretart> _Groo_: perhaps you could try to catch slomo on this?
[21:06] <_Groo_> siretart: dirac was updated a few days ago, the new name convention breaks some package, gstreamer included
[21:07] <siretart> _Groo_: Published on 2010-01-04
[21:07] <siretart> that's 13 days ago
[21:07] <_Groo_> The following packages are BROKEN:
[21:07] <_Groo_>   gstreamer0.10-plugins-bad  mencoder  mencoder-mt  mplayer  mplayer-mt
[21:07] <_Groo_> The following NEW packages will be installed:
[21:07] <_Groo_>   libdirac-encoder0{a} [1.0.2-2]
[21:07] <_Groo_> The following packages will be REMOVED:
[21:07] <_Groo_>   libdirac0c2a{a} [1.0.2-0ubuntu1]
[21:07] <_Groo_> exactly
[21:07] <ion> Please
[21:07] <_Groo_> but went live today
[21:08] <_Groo_> ion: i know... use paste.bin.. but for 4 lines i think is overkill
[21:08] <siretart> it's not
[21:08] <_Groo_> siretart: ok, noticed
[21:09] <siretart> anyway, mplayer needs to be rebuilt anyway as soon as libvdpau is promoted, so that ffmpeg can be built
[21:09] <_Groo_> mencoder and mplayer are my own packages, no prob there...
[21:09] <siretart> oh, I see
[21:09] <_Groo_> siretart: ffmpeg was updated today also
[21:09] <siretart> ffmpeg-extra was
[21:09] <_Groo_> exatcly
[21:09] <siretart> ffmpeg is still waiting for libvdpau
[21:10] <_Groo_> are you guys gonna add mplayer-mt to lucid?
[21:10] <_Groo_> and mencoder-mt? since they can live side by side it would be great
[21:10] <_Groo_> ffmpeg-mt is a ver nice project too
[21:10] <siretart> in a ppa perhaps. are you volunteering to help out here?
[21:10] <_Groo_> siretart: sure why not, i do packages for kubuntu anyway
[21:11] <siretart> ok
[21:11] <_Groo_> and getdeb :P
[21:11] <_Groo_> and debian :D
[21:11] <siretart> do you read the upstream mailing list?
[21:11] <_Groo_> siretart: nope, i usually send them to revu and bug the hell out of ScottK and Richie
[21:11] <_Groo_> Riddell sorry not Richie
[21:12] <Laney> ffmpeg-extra FTBFS :(
[21:12] <siretart> _Groo_: okay, well in short: upstream now includes symbol versioning since yesterday which is enabled by default if the linker supports it
[21:12] <Laney> oh no, that was the other one
[21:12] <Laney> gst-bad
[21:13] <siretart> _Groo_: this finally allows us to safely update ffmpeg without breaking unrelated applications
[21:13] <siretart> _Groo_: however I'm pretty sure that with this patch included, mplayer does no longer build against a shared build of libswscale
[21:13] <siretart> groo_: can you confirm/deny that?
[21:14] <siretart> Laney: sorry? please elaborate
[21:14] <Laney> siretart: the gst-plugins-bad0.10 rebuild FTBFS
[21:14] <Laney> https://launchpad.net/ubuntu/+source/gst-plugins-bad0.10/0.10.17-1ubuntu2
[21:15] <groo_> siretart: mplayer using latest svn?
[21:16] <siretart> groo_: post svn r30315
[21:17] <groo_> siretart: will have to build and see, also im gonna do the mplayer/mencoder-mt in parallel... they work very well with smplayer for ex :)
[21:17] <groo_> siretart: but it will take me a week or so... since i dont have much time during the week... it depends how my work is :)
[21:18] <siretart> Laney: bad sdl or gst. needs more investigation, I'd say
[21:18]  * Laney nods
[21:18] <sebner> Laney: uhh, nearly removed all the lib stuff that depends on -bad :)
[21:19] <Laney> hmm?
[21:19] <sebner> Laney: dist-upgrades updates -bad and then wants to remove all the libs that break because of new -bad
[21:20] <Laney> bad is bad!
[21:20] <sebner> better than ugly ?! ^^
[21:21] <siretart> groo_: actually, my plan was first to do ffmpeg-snapshot and mplayer-snapshot packages, both tracking trunk, and maybe setup some buildbot for them
[21:21] <groo_> like i said, gstreamer bad plugins is broken since latest libdirac upgrade... changed the package name.. so when you try to dist-upgrade apt tries to remove bad plugins and all apps with it
[21:21] <groo_> siretart: want to contact me by mail? i might be able to help.. and ive been doing mplayer/ffmpeg own packages for years :D
[21:22] <siretart> groo_: no, the problem is that gstreamer-bad fails to build from source, if it wouldn't we'd already have fixed packages
[21:22] <Laney> yes this happens in the life of a development release
[21:22] <groo_> Laney: true :)
[21:22] <groo_> siretart: with same source or newer one?
[21:22] <siretart> groo_: feel free to join the pkg-multimedia list on alioth
[21:23] <siretart> groo_: see Laney's last link in this channel
[21:24] <groo_> siretart: i will see if i find the time :)
[21:55] <RiotingPacifist> are there any problems with launchpad? https://launchpad.net/ubuntu/+search?text=kdm won't load for me today
[21:55] <ScottK> RiotingPacifist: #launchpad
[22:18] <bigon> is it possible to know for which pkg I have upload rights?
[22:21] <geser> try asking LP (through the LP API, e.g. with edit_acl.py) or as last resort: upload and see it if succeeds or not
[22:23] <bigon> geser: ok :)
[23:04] <dupondje> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/508930 => enough info in bugreport ?
[23:21] <dupondje> added wireshark dump