[00:00] <slangasek> hggdh: it boggles the mind that runit has been upstartified; looking
[00:00] <SpamapS> upstart runs runit runs daemontools runs home and cries to djb ;)
[00:01] <slangasek> hggdh: this package is calling stop/start directly - that's a bug
[00:01] <slangasek> hggdh: the only interface policy says packages are supposed to use in their maintainer scripts is invoke-rc.d
[00:01] <hggdh> slangasek, ah, I feel better now :-)
[00:02] <SpamapS> slangasek: I'm going to send the idea to upstart-devel ... I think this may be the right thing to ship and recommend people use until we have 'while'
[00:03] <slangasek> SpamapS: ok, cool
[00:04] <slangasek> hggdh: so yeah, it's a bug in runit, which is definitely not a package I'm spending any effort fixing right now :)
[00:08] <hggdh> slangasek, NP. I understand all that is needed is change the postinst to call invoke-rc.d instead of /sbin/start. If this is it, I can do it mesself. Correct?
[00:09] <slangasek> hggdh: well, the *sensible* thing to do is to make the package use debhelper, which automatically spits out the correct maintainer script snippets... but yeah, I don't think you want to maintain that :) so just replacing with invoke-rc.d is the way to go
[00:09] <SpamapS> hggdh: the real question is why isn't it using dh_installinit
[00:09] <SpamapS> err.. what he said
[00:09] <slangasek> SpamapS: I don't think that's a question, really
[00:09] <slangasek> I mean, it's runit
[00:09] <slangasek> did you expect the packaging to not also be idiosyncratic? ;)
[00:11] <hggdh> SpamapS, slangasek: adding debhelper will be a bigger change ;-)
[00:12]  * hggdh would rather start with small changes
[00:14] <slangasek> hggdh: yeah, I generally wouldn't be in favor of debhelperifying a package in Ubuntu only unless it's something we plan to maintain
[00:15] <hggdh> deal
[01:45] <ScottK> geser, tumbleweed, etc.  Feel free to fix.  I need to run.
[04:21] <jderose> Does anyone know if Python3.1 will remain in Natty, or will it be dropped, leaving just Python3.2?
[04:45] <persia> jderose, I can't speak authoritatively, but I doubt anyone is going to try really hard to drop python3.1.
[04:45] <persia> I suspect the default python3 interpreter will be python3.2
[04:45] <persia> Python2.6 will likely also be available in parallel.
[04:46] <jderose> persia: yeah, 3.2 already seems to be default.  i'm working on a python3 package and was just curious if i should fully QA for running under 3.1 also, or just 3.2
[04:47] <jderose> persia: thanks for the insight!
[04:48] <persia> I'd recommend focusing on 3.2: it will be a rare case that someone would be using 3.1 unless they asked for it especially.
[04:48] <persia> And in the longer term, 3.1 will go away: I'm just not sure that the actual final removal is on someone's natty agenda.
[04:48] <jderose> persia: okay, thanks :)
[04:49] <RAOF> Any archive admins available to push through the -vmmouse sync in bug #709134?  It's the last of the pieces required to transition to Xserver 1.10.
[06:40] <pitti> Good morning
[06:41] <SpamapS> pitti: ahoi! :)
[06:45] <RAOF> pitti: Good morning!
[06:48] <RAOF> pitti: Are you archive admininging today? The sync in bug #709134 will finish the Xserver 1.10 transition.
[06:49] <pitti> RAOF: I'm not, but I can do the sync
[06:49] <pitti> RAOF: is that the reason why dist-upgrade currently croaks?
[06:49] <pitti> The following packages have unmet dependencies:
[06:49] <pitti>  xserver-xorg-core : Breaks: xserver-xorg-video-8
[06:49] <pitti> hm, hardly, that's -input
[06:50] <pitti> oops, seems the new pygobject breaks a lot
[06:51] <RAOF> It will be breaking dist-upgrade, once the rest of the uploads are built and published.
[06:51] <pitti> will fix
[06:51] <pitti> synced
[07:04] <RAOF> Hm.  That's ususually long.  -ati finished building 3 hours ago, doesn't seem to have made it to archive.ubuntu.com yet.
[07:09] <micahg> O
[07:10] <micahg> I'm wondering, if a few packages build-dep on a package only on archs that we don't have, can the build-dep be dropped from Ubuntu (gcc-4.3)
[07:11] <pitti> micahg: yes; we should drop it if it reduces delta from Debian, and keep it if that b-dep is in Debian (IMHO)
[07:12] <micahg> pitti: the build-dep is gcc-4.3 and it's only on archs we don't have
[07:12] <pitti> micahg: right, I understand
[07:13] <pitti> micahg: as it's basically a no-op for us, we should keep it if the Debian package has it as well (to avoid an unnecessary delta), and drop it if not
[07:13] <micahg> pitti: I'm wondering about dropping gcc-4.3 :)
[07:13] <pitti> ah
[07:14] <pitti> sorry, misunderstood
[07:14]  * micahg probably isn't too clear at this hour :)
[07:14] <pitti> there's still a couple of rdepends, though
[07:15] <micahg> I'm looking now for ones that aren't no-ops
[07:15] <pitti> e. g. chromium-browser
[07:15] <pitti> Build-Depends: g++-4.3 | g++-4.2
[07:16] <micahg> pitti: is there a germinate output for it?
[07:18]  * micahg is wondering if there's an easy way to check for remaining deps
[07:18] <pitti> micahg: http://paste.ubuntu.com/560844/
[07:19] <micahg> pitti: is that a special tool?
[07:19] <pitti> micahg: a lot of that is self-referential and there might also be alternative dependencies for those
[07:19] <pitti> micahg: it's checkrdepends from lp:ubuntu-archive-tools
[07:19] <micahg> ah
[07:19] <pitti> checkrdepends gcc-4.3 natty
[07:19]  * micahg needs to remember that
[07:21] <micahg> pitti: thanks, will look into this
[07:57] <dholbach> good morning
[07:58] <mvo> hey dholbach
[07:59] <dholbach> hey mvo
[08:03] <\sh> moins
[08:11] <didrocks> good morning
[08:50] <dholbach> Who wants to give a session at UDW? Please sign up at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable - thanks :)
[08:56] <apw> didrocks, anyone reporting 'focus' issues with yesterdays unity... i am seeing the wrong cursor and lack of sensitivity on some elements ... actiling like one of the semi-transparent places boxes is on the screen; though there is nothing visible
[08:57] <didrocks> apw: hey, there are some bug report in compiz, all new info like xwininfo + click on the "invisible" window can be great
[08:58] <didrocks> apw: bug #709461
[09:00] <apw> didrocks, will see what i can gleen
[09:12] <cjwatson> pitti: 'checkrdepends gcc-4.3 natty' isn't the right invocation any more :-)  probably works by accident ...
[09:21] <cjwatson> bryceh,RAOF,Sarvatt: is there going to be an upload of -video-mach64 for the new X?
[09:22] <cjwatson> bryceh,RAOF,Sarvatt: actually, there seem to be several video drivers missing, per http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html
[09:24] <RAOF> cjwatson: Meep, that's a big list of armel.
[09:25] <cjwatson> I'm guessing that's just due to no (input|video) drivers being installable yet, so xserver-xorg's uninstallable, so xserver-xorg-core's uninstallable
[09:26] <RAOF> Yeah, looks like it.
[09:26] <RAOF> *All* the drivers built against the wrong server?!  Bah.
[09:30] <RAOF> Ok.  I'll bump the X server dependencies and get those rebulit.
[09:32] <cjwatson> OK, thanks
[09:32] <cjwatson> RAOF: does that go for the ones that are still uninstallable on x86 too?
[09:33] <RAOF> Yeah.
[09:33] <RAOF> I see the rebuild-the-world script is going to need to be a bit smarter next time :/
[09:33] <cjwatson> OK, I'll leave that with you then, thanks.  Do you need upload assistance?
[09:33] <RAOF> I will, yes please.
[09:34] <cjwatson> Point me at something moderately digestible then ...
[09:34] <RAOF> I'll get everything batched up, then ping you once?
[09:34] <cjwatson> yep
[09:34] <RAOF> Is *_source.changes suitably digestible, or would you like debdiffs as well?
[09:36] <cjwatson> just source packages should be fine
[10:13] <pitti> cjwatson: oh?
[10:31] <cjwatson> pitti: 'checkrdepends -s natty gcc-4.3' or just 'checkrdepends gcc-4.3' (plus -b if you want binary)
[10:32] <cjwatson> pitti: I sent a mail about this at the time, I think - I had to change the syntax to make the interface sane for looking up multiple packages at once
[10:32] <pitti> cjwatson: ah, so I suppose it additionally checked for rdepends of the "natty" pacakge
[10:32] <cjwatson> yeah
[10:32] <pitti> cjwatson: right, forgot about that apparently; thanks!
[10:46] <ogra> The following packages have unmet dependencies:
[10:46] <ogra>  unity : Depends: unity-common (= 3.2.16-0ubuntu1) but it is not going to be installed
[10:46] <ogra> E: Broken packages
[10:46] <ogra> GRRR !
[10:47] <didrocks> ogra: on armel?
[10:47] <ogra> didrocks, yeah, i suspect only arch any vs arch all out of syncness
[10:47] <didrocks> ogra: right
[10:47] <didrocks> ogra: unity FTBFS yesterday on armel IIRC
[10:47] <ogra> but it gets annoying, we dont have images for weeks due to that skew
[10:47] <didrocks> let me recheck
[10:48] <didrocks> the FTBFS was due to something not being able to install
[10:48] <cjwatson> I retried it earlier this morning
[10:48] <ogra> cjwatson, you had some ideas how to solve that properly, i want to have a spec/BOF at next UDS about that
[10:48] <didrocks> I asked for a rebuild a little bit later without any success
[10:48] <didrocks> yeah, it's built now, thanks cjwatson
[10:48] <ogra> it has gotten really bad this release
[10:49] <cjwatson> ogra: the theory isn't difficult, but it requires soyuz implementation time
[10:49] <directhex> should i mention here that canonical's gcc madness causes mono to fail more than three times as many test cases on natty as on sid, on the same arm hardware?
[10:49] <cjwatson> it doesn't need a bof, it needs to get done
[10:49] <ogra> cjwatson, right, i'll take care that we have soyuz people around for that
[10:49] <cjwatson> directhex: given that our gcc maintainer is on holiday, I'm not sure what you would be achieving
[10:49] <ogra> i think with a new non x86 arch it will get bad for others too
[10:49] <cjwatson> ogra: around> it still doesn't need a bof
[10:50] <ogra> cjwatson, well, then a spec with the right people assigned
[10:50] <cjwatson> the solution is to keep multiple versions of packages in the Packages and Sources files, with appropriate refcounting
[10:51] <ogra> ok
[10:52] <cjwatson> so you have as many versions of architecture: all packages in the db as are required to match published builds of each architecture
[10:53] <ogra> well, wouldnt it be easier to just block the new ones from showing up until the set is complete ?
[10:54] <ogra> i know there will be a slight out of sync-ness across the arches due to that, but thats still better than completely uninstallable sets and seems easier to implement
[10:54] <ogra> at least in my imagination (not knowing the code at all)
[10:55] <cjwatson> that would cause different problems
[10:55] <ogra> ah, k
[10:56] <cjwatson> my solution is not theoretical
[10:56] <cjwatson> http://ftp-master.debian.org/wiki/projects/arch-all-tracking/
[10:56] <cjwatson> (nor is it "my solution", come to that, but anyway)
[10:57] <ogra> geez 2009 !
[10:57] <ogra> i'll talk to davidm that he organizes resources for implementing that in O
[10:58] <cjwatson> also http://twerner.blogspot.com/2009/11/dak-dominate-will-dodadoda-debian.html
[10:58] <ogra> we have literally lost weeks this cycle due to it
[10:59] <cjwatson> so this is implemented in practice and the various client-side things that had problems have generally already been fixed now; there is certainly no need to design something afresh, and it would probably be actively undesirable to do so
[11:00] <ogra> well, i think linaro designed something different from scratch
[11:00] <cjwatson> linaro probably didn't know about this
[11:00] <ogra> they us an archive snapshot afaik
[11:00] <cjwatson> this should be purely a catchup project
[11:00] <ogra> *use
[11:00] <ogra> but that adds the difficulty to know when the achive is in sync at all
[11:02] <ogra> right, i'll do some writeup for david and hand it to him to make sure we have resources assigned for an implementation
[11:33] <pitti> @pilot in
[11:36] <RAOF> ogra: Does your crazy AC100 still need -input-kbd?  I'll include that in the rebuild frenzy.
[11:38] <ogra> RAOF, yep, it does, thanks !
[11:44]  * dholbach hugs pitti
[11:44]  * pitti hugs dholback
[12:17] <RawChid> I just installed Wireshark in lucid, but for certain functionality it needs to be started as root. In previous versions it installed 2 menu option (1 to start with root privs.). Is this a bug? Anyone know if I should report this issue?
[12:21] <RawChid> The issues is I manually had to make a second menu item for starting with root privs.
[12:23] <cjwatson> RAOF: how's it going?
[12:23] <jelmer> pitti: Thanks for merging that evolution-mapi patch :)
[12:23] <RAOF> cjwatson: I'm just running a test-build of everything.
[12:24] <pitti> jelmer: at your service :)
[12:24] <RAOF> cjwatson: If you'd prefer, tjaalton has offered to sponsor the packages, too. :)
[12:25] <cjwatson> don't mind
[12:25] <cjwatson> I just want to get going on alpha-2 builds ASAP
[12:26]  * didrocks sneaks two small fixes for unity places meanwhile :)
[12:27] <RAOF> cjwatson: Yeah, sorry.
[12:32] <ari-tczew> pitti: free?
[12:32] <pitti> ari-tczew: what's up?
[12:33] <ari-tczew> pitti: could you look on gedit merge?
[12:33] <cjwatson> ari-tczew: you know main is (soft-)frozen?
[12:34] <pitti> ari-tczew: will look, if it's safe for a2
[12:34] <ari-tczew> cjwatson: oh! nope. but Robert Ancell has sponsored bluez for me 11 hours ago.
[12:34] <cjwatson> ari-tczew: that was before the soft freeze started.
[12:34] <ari-tczew> pitti: translations update
[12:34] <pitti> ari-tczew: looks safe enough, yes
[12:34] <cjwatson> pitti: please don't
[12:35] <cjwatson> gedit has an arch any/all split; build skew will render it uninstallable
[12:35] <pitti> ok
[12:35] <ari-tczew> :(
[12:35] <ogra> ari-tczew, pong btw :)
[12:35] <cjwatson> well, maybe not since the dependencies aren't actually all that strict
[12:35] <pitti> it doesn't have a strict dependency, though
[12:35] <cjwatson> but surely it can wait for after alpha-2?  we have a lot of stuff still to build, like most of X
[12:36] <ari-tczew> ogra: hi, do you will have time for my 2 bugs? (we talked PM last time)
[12:36] <pitti> so I'll just review then
[12:36] <cjwatson> so I would rather not have main uploads that will have to be scored down
[12:36] <ari-tczew> cjwatson: ok but how long it needs to wait?
[12:36] <cjwatson> alpha-2 is due on Thursday, although it will depend on QA cycles
[12:36] <cjwatson> you can see this from the release schedule
[12:37] <ogra> ari-tczew, yes, working on defoma atm but wont upload until friday (due to softfreeze)
[12:37] <pitti> it doesn't change anythign visible anyway, so it's not urgent in any way
[12:37] <ogra> (defomas build-deps are hilarious)
[12:37] <pitti> for now I just reviewed/approved the MP
[12:39] <ari-tczew> ogra: yep
[12:40] <RAOF> cjwatson: I think everything in http://cooperteam.net/Packages/ is good to go.
[12:41] <cjwatson> RAOF: OK, great, thanks - I'll start pushing
[12:42] <cjwatson> modulo wet-string internet
[12:42] <pitti> want me to take half of them?
[12:43] <pitti> cjwatson: ^
[12:43] <cjwatson> nah, it's ok
[12:46] <Kano> hi cjwatson , there is the bugreport for os-prober: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611670
[12:49] <RAOF> Ok.  Midnight says hello, time to go to bed.
[12:49] <jfer> dholbach, i had the pleasure of meeting Kate LCA2011 she informed me that packages are still being accepted for natty. I was wondering if acire will be packaged for natty?
[12:51] <dholbach> jfer, I have no idea
[12:51] <RAOF> ogra: Argh, urgh.  Despite my first test-build somehow suggesting otherwise -kbd doesn't build against 1.10; I'll look at that tomorrow morning.  Sorry.
[12:52] <ogra> RAOF, no hurry
[12:52] <ogra> RAOF, i cant use natty on the ac100 yet until the new QT is uploaded
[12:52] <ogra> (since i need to use unity-2d and QT without NEON)
[12:53] <jfer> is it possible to be included in natty?
[12:54] <dholbach> jfer, can you talk to Jono about that? I really don't want to be assumed to be the "maintainer" for it
[12:54] <jfer> ok thanks.
[12:54] <ogra> dholbach, sissy
[12:54] <dholbach> jfer, I did one upload to the PPA to backport it and could see if it's possible to upload a natty version to the PPA
[12:54] <dholbach> ogra, you do it!
[12:54] <ogra> nah
[12:54] <ogra> :)
[12:54] <dholbach> there you go
[12:55] <jfer> i am keen to get involved in packaging. is the mentoring program still happening?
[12:55] <dholbach> jfer, unfortunately not, but I suggest you still check out https://wiki.ubuntu.com/MOTU/GettingStarted and just ask your questions in #ubuntu-devel or #ubuntu-motu
[12:56] <dholbach> there's no dedicated 1-on-1 mentoring that I know of
[12:56] <dholbach> but there's still a lot of very helpful people
[12:56] <tumbleweed> #ubuntu-packaging is a good spot for packaging questions. Its very quiet, though...
[12:56] <jfer> ok. i have watched a few of your videocasts and they are most helpful but i am keen to get working on some real examples
[12:57] <dholbach> excellent
[13:06] <ari-tczew> dholbach: hello. when we can except first conclusions from surveymonkey?
[13:07] <dholbach> ari-tczew, in a few weeks
[13:08] <ari-tczew> aha
[13:08] <dholbach> lunch time :)
[13:11] <cjwatson> RAOF: all done now, thanks!
[13:12] <cjwatson> oh, damn, except it would have helped to use dupload -t ubuntu :-/
[13:13]  * cjwatson expects a giant pile of reject mails
[13:41] <cjwatson> RAOF,bryceh,Sarvatt: the new xserver-xorg-input-mouse fails to build - do you know what's going on there?
[13:41] <pitti> cjwatson: FYI, I uploaded the pywebkitgtk fix, as it's quite important, but lowered its build score
[13:42] <pitti> so it doesn't get into the way
[13:42] <cjwatson> pitti: is that the one that fixes a crash in ubiquity?
[13:42] <cjwatson> oh, no
[13:42] <pitti> it previously shipped a broken .pyc file
[13:42] <cjwatson> ok, that's fine, thanks
[13:43] <tseliot> cjwatson: can I see the build log of xserver-xorg-input-mouse, please?
[13:44] <tjaalton> http://launchpadlibrarian.net/63296363/buildlog_ubuntu-natty-i386.xserver-xorg-input-mouse_1%3A1.6.0-1ubuntu1_FAILEDTOBUILD.txt.gz
[13:44] <tseliot> ah, thanks
[13:44] <tjaalton> it probably needs an update to build against the new headers
[13:45] <tjaalton> right, there hasn't been a release for 1.10
[13:45] <tseliot> yes, I agree
[13:45] <cjwatson> raof just bumped the build-dep
[13:45] <tjaalton> hmm
[13:45] <tjaalton> yeah that's not quite enough :)
[13:49] <tjaalton> the warnings aren't critical, but looks like at least two commits from master should be needed for input abi 12
[13:50] <pitti> I guess with nvidia/fglrx being broken right now, I better disable those in Jockey for now
[13:51] <tjaalton> there could probably be a check for the video abi, and not offer those if the current package doensn't provide the current abi?
[13:51] <pitti> right, that'd be a more permanent solution
[13:51] <tseliot> pitti: yes, that would be a good idea, until I fix the dependecies as discussed in the ubuntu-x mailing list
[13:51] <tjaalton> there's been some talk about how to handle the abi's on ubuntu-x@
[13:53] <pitti> tjaalton, tseliot: so if I get the -video-abi from xserver-xorg-core, and check it against the driver package's Provides: line, would that be correct?
[13:53] <pitti> (why is it provides: and not depends:?)
[13:54] <tseliot> pitti: yes, I think so
[13:54] <pitti> tseliot: fglrx doesn't seem to have a video-abi provides at all?
[13:54] <tjaalton> I haven't read the thread with thought, yet, so can't comment in detail :)
[13:55] <pitti> tjaalton: that's how it currently seems to work, anyway
[13:55] <tjaalton> pitti: well, it doesn't really work currently
[13:55] <tseliot> pitti: RAOF pointed me to ${xviddriver:Depends} which is what I should use instead of provides
[13:55] <pitti> hm, so perhaps I just generally disable them for now, and postpone the ABI matching when this got settled
[13:55] <tjaalton> yeah
[13:56] <tseliot> pitti: I thought I added that in fglrx but I'll definitely fix it in the next upload
[13:56] <tseliot> +1
[13:57] <tjaalton> tseliot: I'll check -mouse and upload whatever builds against the new abi
[13:57] <tseliot> tjaalton: ok, good. Let me know if you need a hand
[14:00] <ari-tczew> tseliot: when we can except the fix for nvidia?
[14:01]  * cjwatson cleans up the xserver-xorg-video-s3virge reject
[14:02] <tseliot> ari-tczew: if you mean "expect", I'm still thinking about it
[14:03] <tseliot> I noticed the thread in ubuntu-x only last night
[14:11] <tjaalton> tseliot: grah, those abi patches don't apply on 1.6.0, probably best to pull master (1.6.99)
[14:11] <tjaalton> not that it's hugely different in functionality..
[14:12] <tseliot> tjaalton: they are going to release something stable together with X, aren't they? So it shouldn't be a problem
[14:13] <tjaalton> tseliot: right, it was recently bumped to 1.6.99
[14:14] <tseliot> yes, I see that in git
[14:14] <tjaalton> actually, that happened two months ago, but there's only one commit after that :)
[14:16] <cjwatson> are one of you two able to do the upload?
[14:16] <tjaalton> cjwatson: yeah, I'll pull git master and wrap it up
[14:16] <cjwatson> cool, thank you
[14:31] <zul> can anyone tell me why mcollective got rejected?
[14:37] <cjwatson> zul: you didn't get an e-mail?
[14:37] <cjwatson> zul: Riddell was doing some source rejections earlier ...
[14:37] <ev> a bit of historical curiosity: perhaps it's a false memory, but wasn't the plan a while back to use the desktop wallpaper for the plymouth theme so that the visual transition was minimal?
[14:37] <zul> cjwatson: no i might have missed it or maybe dustin got it
[14:38] <Riddell> zul: https://lists.ubuntu.com/archives/ubuntu-archive/2011-February/039057.html
[14:38] <zul> Riddell: ok thanks
[14:38] <Riddell> which also went to uploader kirkland
[14:39] <ogra> ev, quite a *while* back ;)
[14:40] <ev> any idea why it didn't come to fruition?
[14:40]  * ogra hanst heard anything of that plan after dublin
[14:40] <ogra> *hasn't
[14:40] <ev> hm
[14:40] <ogra> i guess because it was still usplash back then
[14:41] <ogra> and likely nobody thought about it later when we got plymouth
[14:58] <tjaalton> cjwatson: well, the new -mouse doesn't build on pbuilder because the headers are not available (yet). but it should be good for the archive builder, I guess
[14:59] <cjwatson> tjaalton: go ahead if you think it's good, I don't think it can get significantly worse
[14:59] <tjaalton> heh, right.. let's see how it goes
[14:59] <tjaalton> there
[15:11] <smoser> cjwatson, have you or know of a 2.6.38 kernel with grub 0.97 ? asking due to bug 710754.
[15:11] <smoser> smb has a workaround for -virtual kernel on ec2, but I was curious if it affected all grub 0.97.
[15:15] <smb> For completeness, the bug seems to be in pv-grub which is based on the old grub. It may or may not have the same potential in there.
[15:15] <cjwatson> smoser: I don't know, sorry
[15:15] <cjwatson> pvgrub makes my head hurt
[15:16] <smb> Heh, it surely did that to me even without looking at its code
[15:16] <cjwatson> let me check grub's changelog briefly
[15:16] <cjwatson> but I seriously doubt there've been any recent fixes in grub; last upstream commit in our package was 2005
[15:17] <cjwatson> don't see any relevant changes post 0.97, on a quick glance
[15:18] <smb> cjwatson, Probably just something to keep in the back of our memories should there be somone approaching us with strange boot failures with grub0.97 and Natty or later i386 kernels.
[15:18] <smb> Not this should be expected to happen...
[15:20] <pitti> @pilot out
[15:22] <tjaalton> cjwatson: -mouse built, whee
[15:47] <pitti> kees, jdstrand: postgresql just announced new security/bug fix release, I'm preparing them
[15:47] <pitti> kees, jdstrand: are we actually still concerned about this buffer/int overflow in a security sense? http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=7ccb6dc2d3e266a551827bb99179708580f72431
[15:47] <pitti> kees, jdstrand: or do we merely handle that as a DOS now?
[15:48] <pitti> i. e. do you want -security or SRU?
[15:48] <pitti> well, I guess at least teh dapper backport should go to -security
[15:48] <jdstrand> pitti: a DoS in a server we consider medium priority
[15:48] <pitti> jdstrand: ok, so still -security?
[15:48] <jdstrand> pitti: so -security would be great
[15:48] <pitti> jdstrand: ok; I'll open a tracker bug for it, and put the updated source packages somewhere
[15:49] <pitti> jdstrand: 8.1 went out of support, so for that I'll backport the fix
[15:49]  * pitti hopes there won't be too many security vulns in 8.1 any more until June
[15:49] <jdstrand> pitti: thank you. not sure who will process it, it could be sbeattie or mdeslaur (or me or kees)
[15:49]  * jdstrand nods
[15:50] <jdstrand> pitti: but if you subscribe us to the bug (and ping as you helpfully do :), we'll sort that out. thanks for preparing them :)
[15:50] <pitti> jdstrand: yup, as usual; thanks!
[16:20] <geser> has marking a function (a constructor) as "inline" (or not marking anymore) any influence on the API or ABI of a library?
[16:20] <pitti> in some cases at least
[16:20] <pitti> I painfully remember that with apt
[16:20] <pitti> inline constructors in C++ really really suck, and should be avoided
[16:21] <geser> I'm looking at http://launchpadlibrarian.net/58061583/buildlog_ubuntu-natty-i386.gecode_3.4.0-1_FAILEDTOBUILD.txt.gz
[16:21] <pitti> as you can't change them without breaking ABI
[16:21] <pitti> (in a behavioural way, not in a compile sense)
[16:23] <geser> as the .so version got bumped would that be a good chance to drop the "forceinline" from that contructor (or even all constructors)?
[16:23] <juliank> Inline functions should be avoid in general, unless you can prove that there is a large advantage in a performance-critical path
[16:23] <juliank> s/avoid/avoided/
[16:27] <pitti> geser: sounds good; but that should probably happen upstream?
[16:29] <geser> pitti: upstream "fixed" it by not providing a constructor with a va_arg list anymore. I'll wait on the DD to package it (upstream released it today)
[16:30] <pitti> geser: but still inline?
[16:30] <geser> yes, even "forceinline" :(
[16:31] <pitti> geser: that's still broken, as with that you can't change the implementation of the ctor at all without breaking abi
[16:49] <ogra> /var/lib/dpkg/tmp.ci/config: 127: cannot create /dev/null: Permission denied
[16:49]  * ogra scratches head
[16:49] <cjwatson> something's removed your /dev/null
[16:49] <ogra> i'm in a chroot
[16:50] <hallyn> make a new one
[16:50] <ogra> and am root
[16:50] <cjwatson> unfortunately it's extremely hard to retrospectively find out what
[16:50] <ogra> and /dev isnt bind mounted or anything
[16:50] <hallyn> oh
[16:50] <ogra> so i should be able to just write to it as a file
[16:50] <hallyn> ogra: cat /proc/self/status | grep Cap
[16:50] <ogra> proc isnt mounted either
[16:50] <hallyn> biab
[16:51] <geser> nodev mount option?
[16:51] <ogra> oh !
[16:51] <ogra> indeed !!!
[16:51]  * ogra higs geser 
[16:51] <ogra> err
[16:51] <ogra> *hugs
[17:44] <SpamapS> is there a quick tool that I can use to check two revisions against the debian version sort algorithm?
[17:45] <cjwatson> dpkg --compare-versions
[17:45] <SpamapS> I knew it had to be simple. :)
[18:08] <Amaranth> RAOF, bryceh: You broke my unity :/
[18:11] <didrocks> kenvandine: you have the same issue on intel as well, isn't it? ^^
[18:11] <didrocks> Amaranth is suggesting an FBO issue
[18:11] <Amaranth> compiz itself works but if you enable the unityshell plugin and start compiz it segfaults, getting a backtrace now
[18:11] <ScottK> tumbleweed: Thanks for fixing up requestsync.  Sorry I had to run off (due to $WORK stuff).
[18:13] <Amaranth> #5  0x00007fce31d361c5 in nux::IOpenGLFrameBufferObject::Deactivate() () from /usr/lib/libnux-graphics-0.9.so.0
[18:13] <Amaranth> So yeah, FBO :/
[18:13] <Amaranth> I think it fails to setup the FBO and crashes trying to clean up
[18:15] <bryceh> Amaranth, your welcome
[18:16] <bryceh> Amaranth, actually, I booted unity successfully yesterday with the new stack and it seemed to be working fine for me
[18:21] <kenvandine> didrocks, what's the issue?
[18:21] <kenvandine> didrocks, yes mine is on intel
[18:22] <didrocks> kenvandine: look ^^
[18:23] <seb128> what are you debugging?
[18:23] <kenvandine> didrocks, i didn't try disabling unity
[18:23] <kenvandine> let me do that
[18:24] <seb128> I just restart after some upgrades and my session was empty
[18:24] <seb128> no compiz, no nautilus, no gnome-panel running
[18:24] <seb128> it's weird
[18:24] <didrocks> seb128: maybe you have the same issue than Amaranth is describing
[18:25] <SpamapS> Amaranth, isn't that a grain used by the aztecs?
[18:25] <Amaranth> bug 711396
[18:26] <Amaranth> I'm thinking we have a gnome-session issue here as well
[18:26] <Amaranth> Apparently this case has never been tested
[18:26] <didrocks> Amaranth: what issue in gnome-session?
[18:26] <Amaranth> didrocks: It doesn't do any kind of fallback
[18:26] <Amaranth> or even start nautilus...
[18:27] <didrocks> Amaranth: not, nautius and gnome-panel is starting
[18:27] <didrocks> Amaranth: look bug #711378
[18:28] <kenvandine> didrocks, yes compiz works fine with the unity plugin disabled
[18:28] <Amaranth> after compiz crashed compiz has no say in gnome-panel being mapped ;)
[18:28] <kenvandine> Amaranth, right... that is the bug i filed earlier
[18:28] <didrocks> Amaranth: right, but gnome-panel is running if you look at a tty
[18:29] <didrocks> Amaranth: so as I have no input there, we filed the bug report
[18:29] <Amaranth> didrocks: In this case I'm pretty sure nothing is running
[18:29] <didrocks> Amaranth: did you try on a tty?
[18:29] <Amaranth> I know nautilus isn't, at least
[18:29] <didrocks> geser: kenvandine and I tried
[18:29] <Amaranth> Yeah, I looked with pgrep, didn't look for gnome-panel though, just nautilus
[18:29] <didrocks> and confirm it's running in that case
[18:29] <Amaranth> But when I got a terminal running and ran unity --reset it was complaining about dbus and such not running so it seems I got no session
[18:30] <Amaranth> s/terminal/gnome-terminal/
[18:30] <didrocks> Amaranth: try with that, you should have gnome-session and others… it has been confirmed
[18:30] <didrocks> just that's it's not mapped
[18:30] <geser> Amaranth: my gnome-panel is running as I send a SIGHUP to the gnome-panel to make it "reappear"
[18:32] <Amaranth> I just hope VBOs still work so I can get back to work :)
[18:32] <didrocks> Amaranth: So I just tried again
[18:32] <didrocks> Amaranth: gnome-panel is running, nautilus is running and gnome-session as well
[18:32] <didrocks> so gnome-session has no issue handling the fallback
[18:34] <Amaranth> except for not starting metacity?
[18:35] <didrocks> Amaranth: it's compiz which does it
[18:35] <geser> for me metacity gets started but no visible gnome-panel
[18:35] <didrocks> Amaranth: as the fallback session is gnomewm + gnome-panel
[18:35] <didrocks> Amaranth: but as it's segfaulting…
[18:35] <Amaranth> didrocks: That's not very bright :)
[18:35] <Amaranth> didrocks: Perhaps it should hardcode metacity
[18:35] <didrocks> Amaranth: well, you can have compiz running but not unity
[18:36] <didrocks> Amaranth: hence the helper test unity and compiz capability
[18:36] <didrocks> Amaranth: so no, sorry, "maybe not bright" but finer grained
[18:36] <didrocks> compiz should just triggers the fallback
[18:38] <didrocks> Amaranth: do you still see no nautilus process starting from the session?
[18:38] <didrocks> as it seems you are the only one to see this bug
[18:38] <Amaranth> didrocks: I don't want to kill my session and start over right now
[18:41] <SpamapS> 30757 clint     20   0 2920m 119m  43m S    4  3.0   2:12.84 banshee-1
[18:41] <SpamapS> whoa..
[18:42]  * ogra imagines thats LOUD music ;)
[18:42] <debfx> bryceh: does the xserver-xorg-video-intel apport hook really need python-dev?
[18:42] <bryceh> debfx, I've got a fix queued for that
[19:12] <tumbleweed> ScottK: np
[19:12] <SpamapS> slangasek: the portmap/sysvinit saga continues .. bug #711425
[19:18] <slangasek> SpamapS: I am skeptical; portmap should only have read-only fds on the root fs
[19:18] <SpamapS> slangasek: deleted libs are a special case
[19:18] <slangasek> ah
[19:19] <slangasek> SpamapS: why are we not restarting portmap at the time of the libc6 upgrade?
[19:19] <slangasek> oh right
[19:19] <SpamapS> slangasek: :)
[19:19] <slangasek> because we don't do that period, we only do that for services that use nss
[19:20] <slangasek> so yeah, I guess we should solve the nfs shutdown problem
[19:21] <slangasek> SpamapS: please take into consideration what should happen here in the nfsroot case
[19:22] <slangasek> (I'm not sure what *should* happen, but it's possible portmap+statd need to be kept running until the very end)
[19:22] <kees> pitti: still here?
[19:25] <pitti> hey kees
[19:26] <kees> pitti: hi! I just sent email. the meta packages haven't been copied, and linux-ec2 is still unpromoted...
[19:26] <pitti> huh?
[19:26] <pitti> copy-package.py -ybs maverick-updates --to-suite maverick-security linux linux-backports-modules-2.6.35 linux-ec2 linux-meta linux-ports-meta linux-meta-ec2
[19:26] <pitti> that's even in the bash history still
[19:26] <kees> https://launchpad.net/ubuntu/+source/linux-meta
[19:27] <kees> btw, there is no linux-ec2 in maverick
[19:27] <pitti> hm, seems that went wrong somehow
[19:27] <pitti> let me try again
[19:27] <kees> I assume copy-package.py doesn't take multiple args
[19:27] <pitti> linux-ec2 | 2.6.32-305.9 |      maverick | source
[19:27] <pitti> sure there is
[19:28] <kees> nope, that's been deleted.
[19:28] <SpamapS> slangasek: with the init.d script.. portmap is stopped after umountnfs .. so maybe nfs root requires modification of the shutdown anyway?
[19:28] <kees> linux-ec2 in maverick is provided by the "linux" source package. https://launchpad.net/ubuntu/+source/linux-ec2
[19:29] <pitti> hm, so the source wasn't deleted in time for the release then?
[19:29] <kees> correct
[19:29] <pitti>  linux-ec2 | 2.6.32-305.9 |      maverick | source
[19:29] <pitti>  linux-ec2 | 2.6.32.305.6 |      maverick | amd64, i386
[19:29] <pitti> it's even the very same binary version
[19:29] <pitti> very confusing
[19:29] <slangasek> SpamapS: fair enough
[19:29] <pitti> ok, I'll skip that then
[19:29] <kees> yup, but that's not important. linux-ec2 is provided by "linux" in maverick and later, so no one will get the old bins
[19:30] <slangasek> SpamapS: also I see nfs-common being stopped *before* umountnfs... that's not right
[19:32] <SpamapS> there's an nfs-common ?
[19:32]  * SpamapS reads
[19:33] <SpamapS> right looks like that is what used to stop statd
[19:33] <pitti> kees: all copied now; sorry about that!
[19:34] <kees> pitti: cool, thanks!
[19:34] <kees> pitti: what was the origin of the problem?
[19:34] <pitti> kees: PEBCAK + copy-packages.py fail
[19:34] <kees> heh
[19:34] <kees> I always work from https://wiki.ubuntu.com/Kernel/Dev/ABIPackages to make sure I don't miss anything
[19:35] <kees> and have scripted the post-unembargo package validations
[19:35] <pitti> I have scripts for SRU accepting and release as well
[19:35] <pitti> but not for -updates->-security
[19:36] <pitti> (... yet)
[19:36] <kees> hehe
[19:40] <WikiUser65> BOO!
[19:41] <WikiUser65> ka pow!
[19:43] <pitti> the first shot wasn't enough? :-)
[19:43] <Keybuk> first shot?
[19:44] <maco> Keybuk: i think he means the boo
[19:44] <kees> Keybuk: why both ban and unban?
[19:45] <Keybuk> kees: ban stops auto-rejoin, but no point keeping it around for ages unless he comes back and continues to be silly
[19:45] <kees> fair enough
[20:05] <barry> hi folks.  can someone upload a no change rebuild for libvigraimpex?  i think that's all we need to rebuild (and fix) python-vigra for natty
[20:22] <dupondje> somebody wants to check https://bugs.launchpad.net/ubuntu/+source/vinagre/+bug/711442 ?
[20:22] <dupondje> added patch, tested, and it works :) so ...
[20:23] <cjwatson> Amaranth: could you/somebody update #ubuntu-release once unity/X is fixed (whichever needs to change)?
[20:23] <cjwatson> (don't update me, I'm finishing for the day)
[20:23]  * skaet plans to pay attention...
[20:24] <Amaranth> cjwatson: If RAOF or bryceh don't, yeah
[20:24] <cjwatson> thanks
[20:24] <cjwatson> we're treating it as blocking alpha-2 builds, which I trust is reasonable
[20:25] <Amaranth> I dunno, if nux got fixed it would at least launch metacity instead
[20:25] <Amaranth> Although apparently you don't get a visible gnome-panel in that case...
[20:25] <cjwatson> "it"> *something* needs to change ...
[20:25] <cjwatson> I'm not sure releasing alpha-2 with 2d only would be popular?
[20:26] <Amaranth> I guess not
[20:36] <bryceh> Amaranth, does it still crash if you downgrade to glew 1.5.2?
[20:38] <kees> skaet: btw, we've got security updates coming for openoffice.org and openjdk-6. I'm not sure if we're in the point-release freeze yet, but just wanted to give you a heads-up.
[20:40] <skaet> kees: thanks for the head's up,  we're in point-release freeze now.   Probably need to discuss with pitti after we get A2 out the door later this wee, what's possible/not for 10.04.2.
[20:40] <kees> skaet: I saw the SRU freeze, but wasn't sure if it was hard freeze yet
[20:40] <pitti> no objections from my side; depends if ara/QA are fine with that, as they might test an older version for certification
[20:41] <skaet> images are going through cert testing now, so fairly solid freeze.  depends on if it will affect hardware or not - mostly.
[20:44] <pitti> oo.o shouldn't, and for a security update openjdk sounds hw independent as well
[20:45] <pitti> kees: so +1 from me, but please confirm with ara and victorp as well
[20:45] <stgraber> hmm, maverick seems broken on netinstall because of an sru ...
[20:46] <stgraber> new upstart depending on new libc6 but new libc6 is still in -proposed when new upstart is in -updates
[20:46] <stgraber> ends up red screening d-i as it can't resolve the dependencies
[20:47] <stgraber> I guess both should have been copied at the same time to avoid the breakage ...
[20:47] <pitti> did libc6 change ABI?!?
[20:47] <pitti> ah, the breaks
[20:47] <stgraber> yep
[20:47] <pitti> doesn't apt-get upgrade just hold that back for now?
[20:47] <stgraber> apt-get upgrade will, my issue is netinstall ;)
[20:48] <apw> anyone else seeing unity core dumping on  login with whats in the archive right now?
[20:48] <stgraber> I've got VMs automatically installing and they all fail at the moment because of that
[20:56] <bryceh> skaet, I've repro'd 711396 on same hw as used for testing X stack yesterday
[20:57] <victorp> skaet, pitti - what? :)
[20:58] <pitti> victorp: <kees> btw, we've got security updates coming for openoffice.org and openjdk-6. I'm not sure if we're in the point-release freeze yet, but just wanted to give you a heads-up.
[20:59] <skaet> bryceh,  thanks.
[20:59] <victorp> pitti -ok, shouldnt really impact cert testing, right?
[20:59] <pitti> victorp: I don't think so, it's not hw specific
[20:59] <skaet> victorp,  yeah, that's the assumption.
[20:59] <pitti> victorp: but still wanted you to ack this
[21:00] <victorp> pitti, thanks for that. It is fine with me.I will let ara know
[21:00] <pitti> sounds better than asking folks to download a huge OO.o update right after installing a fresh CD..
[21:00] <pitti> stgraber: so seems we urgently need to test and publish maverick's eglibc then
[21:04] <SpamapS> slangasek: so what I'm seeing is that it is considered poor practice to mount multiple machines with the same nfsroot rw... so nfsroot would suggest either nolock or ro .. both of which preclude needing statd and portmap. I don't know about the nfsv4 stuff though.
[21:05] <SpamapS> slangasek: it makes sense.. whats the point of having a bunch of machines sharing one root fs that they all modify? :-P
[21:05] <slangasek> SpamapS: for nfsv4 there's a nontrivial bootstrapping problem where the support daemons are concerned; I don't know if anyone is doing nfs4root
[21:05] <slangasek> yes, you're not allowed to share the same root fs rw :)
[21:05] <SpamapS> in that case, the point is moot
[21:06] <SpamapS> we can safely stop portmap and, ergo, statd, after umountnfs
[21:07] <bryceh> skaet, alright I think we've narrowed bug 711396 to glew.  It happened to get sync'd just recently.
[21:17] <tormod> bryceh, like 7 hours ago :)
[21:18] <bryceh> tormod, btw was there a particular need for going to the new version, aside from just being in sync?
[21:20] <tormod> bryceh, nothing in particular other than piglit, and that the last version was > 1 year old
[21:21] <tormod> bryceh, about time it got wetted, just badly timed at a2 freeze...
[21:22] <bryceh> yeah we can try again after a2
[21:23] <tormod> bryceh, maybe unity/etc needs to be rebuilt against libglew-dev?
[21:26] <bryceh> this look like a sane enough version number for it?  glew (1.5.7.is.1.5.2-1ubuntu1)
[21:27] <pitti> bryceh: that looks like the standard downgrading versioning approach, yes
[21:28] <bryceh> ../glew-1.5.7.is.1.5.2
[21:28] <bryceh> dch warning: no orig tarball found for the new version.
[21:28] <bryceh> pitti, do I need to re-upload the orig tarball with this?
[21:28] <pitti> bryceh: yes, as you have a new upstream version
[21:28] <bryceh> guessing I do, and it needs named accordingly?
[21:28] <pitti> right
[21:28] <pitti> glew_1.5.7.is.1.5.2.orig.tar.gz
[21:31] <bryceh> alright, building it again for one final test locally
[21:34] <bryceh> lookin' good
[21:34] <bryceh> uploaded
[21:35] <bryceh> skaet, blocker bug sorted, reports should close momentarily
[21:35] <pitti> now if we actually want to update to 1.5.7, it'll look even better
[21:35] <pitti> 1.5.7.is.1.5.2.no.really.really.1.5.7.this.time
[21:35] <skaet> bryceh, thanks.
[21:41] <bryceh> pitti, erf
[21:41] <bryceh> pitti, hopefully they'll be a 1.5.8 by then...  :-/
[21:43] <chrisccoulson> pitti - imagine if we update back to 1.5.7 and then decide to downgrade again ;)
[21:43] <chrisccoulson> what's the limit on version number length? :-D
[21:44] <pitti> let's test stack overflows in dpkg :)
[21:44] <chrisccoulson> lol
[21:44] <apw> pitti, doesn't 1.5.7a work as well ?
[21:44] <chrisccoulson> 1.5.7.is.1.5.2.no.really.really.1.5.7.this.time.oh.no.back.to.1.5.2.yet.again
[21:45] <apw> ie 1.5.7.is. < 1.5.7a
[21:45] <pitti> apw: sure, if upstream won't use that
[21:45] <bryceh> apw, I like that better
[21:47] <bryceh> ok back to broken X's
[21:47] <bryceh> pitti, any ideas on http://paste.ubuntu.com/561141/ ?
[21:48] <pitti> it's even worse for me
[21:48] <pitti> Calculating upgrade... Failed
[21:48] <pitti> The following packages have unmet dependencies:
[21:48] <pitti>  xserver-xorg-core : Breaks: xserver-xorg-video-8
[21:48] <pitti> E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
[21:49] <pitti> Depends: xserver-xorg-core (>= 2:1.9.99.901+git20110131.be3be758) but 2:1.9.0.902-1ubuntu4 is installed
[21:49] <pitti> bryceh: ^ hang on, perhaps same problem that I have?
[21:49] <pitti> I used the xorg-edgers PPA before
[21:50] <pitti> bryceh: I suppose the git version was only in -edgers, and is newer than what's in natty?
[21:50] <apw> cirtianly i have none of that on a machine here
[21:50] <bryceh> pitti, yeah I ran into the same problems upgrading a box with xorg-edgers enabled
[21:50] <bryceh> natty has 1.9.99
[21:50] <pitti> apw: ok, I blame sidegrading fromo -edgers then
[21:50] <bryceh> so yeah, best to completely remove xorg-edgers before doing this update
[21:51] <pitti> bryceh: at least http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html seems happy again
[21:51] <pitti> RAOF: ^ well done
[21:51] <pitti> so on i386/amd64 the only uninstallable is the libreoffice metapackage
[21:51] <pitti> nice
[21:58] <RoAkSoAx> pitti: howdy!! I was wondering if after manually using pm-suspend, when waking up, pm-utils execs any of the /usr/lib/pm-utils/power.d/ scripts?
[22:03] <RoAkSoAx> pitti: specially because of bug #711517, cause someone pointed me out that waking up after someone suspended using powernap, the user defined settings for his WoL nick changed!
[22:10] <pitti> RoAkSoAx: if you change the power state in between, it's likely, yes
[22:11] <pitti> RoAkSoAx: it also might not remember the previous power state, so upower might just always run the power.d scripts after resuming
[22:11] <pitti> ("just in case")
[22:13] <RoAkSoAx> pitti: probably that's the case cause a user changes the WoL config for the network card, but when resuming from a suspend, the changes are not kept. but Powernap doesn't touch anything rather than making sure WoL is enable in the network card (in the upstart job)
[23:17] <hdon> hello devs :) does ubuntu-bug depend on there being a crash report?
[23:18] <RAOF> No - it'll collect information for non-crash bugs, too.
[23:19] <hdon> RAOF, ok, well it's crashing on a KeyError in, i assume, settings['databases'][name] when i ubuntu-bug firefox. it worked, though, when i did "ubuntu-bug apport" (i tried ubuntu-bug ubuntu-bug, but learned that wasn't the package name for the command)
[23:19] <hdon> i'm filing a bug report now..
[23:22] <hdon> anyhow i only asked because firefox hadn't crashed, i just wanted to report an issue (that had been closed before Karmic!) that is present in Lucid
[23:22] <hdon> the bug in firefox though should be reported upstream to Mozilla, but it needs to be in the Ubuntu tracker because it's a very important issue
[23:23] <RAOF> Yeah.  There would seem to be a bug in the apport script for firefox, then.
[23:23] <hdon> RAOF, it looks as though it DOES depend on a crash report. here is the stack: http://pastebin.mozilla.org/1011729
[23:24] <hdon> ohhhh, hmmm!
[23:24] <hdon> actually it looks like it must be a different bug
[23:24] <broder> hdon: that looks like you have firefox installed out of a ppa, not the archive
[23:25] <hdon> broder, ohhhhhh... hmm! well it probably shouldn't crash... when run from the "run application" dialog, it fails silently after a box pops up with a throbber/progressbar
[23:25] <broder> hdon: i don't think running command-line things from "run application" has ever been remotely supported. but you're right that it probably shouldn't prompt
[23:26] <hdon> broder, is it not meant to support ppas? it would be nice i think for ppa maintainers to be able to utilize the bug reporting and issue tracking infrastructure that ubuntu has created. ppas are an important part of the ubuntu community
[23:26] <hdon> broder, ah, well launchpad.net directed me to a wiki which instructs the user to use Run Application
[23:26] <maco> hdon: ppa's dont have bug trackers attached to them
[23:26] <hdon> maco, :( they should!
[23:26] <maco> hdon: bug trackers are for projects
[23:27] <maco> though i think itd be amusing if you could file a bug on a person or team to mean that they screwed up packaging :P
[23:27] <broder> err, s/prompt/crash/
[23:27] <hdon> that's a place i often think Microsoft and Apple fall extremely short -- unless things have changed since i last checked years ago -- application developers have to package their own tools to help users report errors and give diagnostic information to developers
[23:27] <hdon> maco, i think that would be awesome!
[23:27] <broder> based on the very little i know about apport, i think it might be possible for a ppa package to include a file that tells apport where bugs should be filed
[23:28] <maco> in that case, i dont think it'd be "ubuntu-bug" though
[23:28] <RAOF> maco, hdon: Bug reporting against PPAs (and a wider variety of objects in general) is on the launchpad TODO list.
[23:28] <hdon> maco, yes but the ubunut-bug tool does important work like gathering diagnostic information
[23:28] <maco> would be neat if apport checked apt-cache policy to figure out which ppa to report it against
[23:28] <broder> maco: i think it does
[23:28] <hdon> RAOF, yay :)
[23:28] <maco> hdon: thats just the apport hooks in the packages themselves
[23:29] <maco> hdon: if you know the package, apport would do the same. ubuntu-bug's specialness is the symptom stuff
[23:29] <hdon> i see
[23:29] <maco> (at least, i think... cuz you used to report bugs with the apport command iirc...)
[23:30] <broder> maco: ubuntu-bug just dispatches between apport-cli, apport-gtk, and apport-kde
[23:30] <maco> oh
[23:30] <maco> so apport on its own knows how to do -s audio too then?
[23:30] <broder> i think so
[23:30] <maco> nifty
[23:30] <hdon> what is -s audio?
[23:30] <maco> -s = symptom
[23:31] <hdon> ah
[23:31] <maco> audio = what symptom is problematic
[23:31] <hdon> and these are apport-cli arguments?
[23:31] <maco> so if your sound is being faily, you do "ubuntu-bug -s audio" and it asks what sort of fail the audio device is exhibiting
[23:31] <hdon> oh i see
[23:52] <asdfqwer> could someone recommend a good torrent client for cli use?
[23:52] <asdfqwer> for ubuntu server meerkat