[00:09] <rusivi> regarding 162841 seems https://wiki.ubuntu.com/Bugs/Responses#Packages%20not%20provided%20by%20Ubuntu ?
[00:09] <rusivi> regarding bug 162841 seems https://wiki.ubuntu.com/Bugs/Responses#Packages%20not%20provided%20by%20Ubuntu ?
[00:09] <ubot2> Launchpad bug 162841 in vmware-server (Ubuntu) "Instructs users to upgrade it outside of the packaging system (heat: 3)" [Undecided,New] https://launchpad.net/bugs/162841
[00:19] <hggdh> rusivi: re. 162841 -- this would be the wrong answer. The bug is about the VMware that was packaged for Ubuntu (via partnership)
[00:20] <rusivi> hggdh: k do you have a recommendation?
[00:21] <rusivi> fyi I marked a couple bugs recently invalid, I should not have, my mistake I'll avoid in the future.
[00:21] <hggdh> not sure right now, I will have to query the folks about the status (but I think it will be closed wontfix, eventually). So, for now, please leave it be
[00:21] <rusivi> Just a couple or so
[00:22] <rusivi> hggdh: roger
[00:22] <hggdh> just subscribed to it
[00:22] <penguin42> rusivi: Remember you don't have to change a bug that you're unsure about
[00:23] <rusivi> penguin42: I just realized invalid was the wrong way to go
[00:23] <rusivi> I'm like ugh J.H.C.
[00:23] <hggdh> rusivi: if you marked a bug wrongly, just go ahead and redo it (and add a comment stating it was wrongly marked). No problems
[00:23] <hggdh> it happens to the best of us ;-)
[00:23] <rusivi> hggdh Where do I go to see bugs I marked invalid?
[00:24] <G> penguin42: yo
[00:24] <penguin42> G: Did you see the comment on the Maverick SDL/kvm thing
[00:24] <G> penguin42: yeah, can't decide if it's bull or not
[00:25] <yofel> rusivi: go to bugs.launchpad.net/~rusivi1 -> advanced search -> filter for status invalid
[00:25] <rusivi> hggdh: ty
[00:25] <penguin42> G: It sounds like a reasonable explanation - it's a bit of a nasty outcome though
[00:25] <G> penguin42: the fact of the matter is that none the less, the XAUTHORITY env variable is still wrong
[00:26] <G> penguin42: if you run 'env' and look at what you have, compared to what gets passed to KVM you can kinda see
[00:26] <penguin42> G: But I think Marc is saying even if it was right it wouldn't be able to read it
[00:26] <hggdh> rusivi: or use this: http://tinyurl.com/3a8j2nt
[00:26] <rusivi> hggdh: oh wow only 357 :P man I got a lot of self-help to do!
[00:27] <hggdh> actually, these are the bugs you acted on that are set to INVALID
[00:27] <rusivi> hggdh: I'm going to review all my invalid bugs right now before I start anything more
[00:27] <G> penguin42: sure, and thats something that needs to be sorted w/ a facl
[00:27] <hggdh> ordered most recently changed
[00:27] <penguin42> G: Yeh, it's probably not trivial though - IMHO even if that's going to be a pain to fix, if it couldn't be done for maverick it could do with a fix that refuses rather than blatting X
[00:28] <mdeslaur> G: what's bull?
[00:29] <G> penguin42: imo if it ain't working it's fairly serious
[00:29] <G> mdeslaur: I can't decide because I haven't had the chance to go back and take a look
[00:29] <penguin42> G: Yeh I agree, but I can see that if it's the increased security that's broken it I'd keep the security and tell people to use the VNC one until fixed
[00:30] <G> mdeslaur: I've been out of power for a while
[00:30] <penguin42> although the VNC one is a bit laggy
[00:30] <mdeslaur> G: I honestly don't know why that makes your X crash though
[00:31] <G> penguin42: well this is what bugs me, because the default is use VNC it'd never be considered as serious
[00:31] <penguin42> mdeslaur: I think it's SDL falling back to framebuffer
[00:31] <G> mdeslaur: because, as it can't find the right XAUTHORITY it's attacking framebuffer
[00:31] <G> and as root, it can to rather drastic results
[00:32] <penguin42> G: Except it isn't root if it's dropping to that other user - so....
[00:32] <mdeslaur> oh, right...that makes sense...
[00:32] <G> penguin42: true, but it highlights the problem perfectly well imo
[00:32] <penguin42> mdeslaur: If there was a way just to stop it falling back to frame buffer it would be a big improvement; failing to work is one nasty problem, but nuking X is a real nasty
[00:32] <G> if it's got the right XAUTHORITY it works perfectly
[00:33] <G> (even as root)
[00:33] <mdeslaur> penguin42: yeah...it doesn't nuke my X...what video driver do you have?
[00:33] <penguin42> mdeslaur: Radeon (open source) - it only nuked the X sometimes
[00:34] <mdeslaur> we could remove the framebuffer permissions from the apparmor profile...that would stop it from at least nuking X
[00:34] <G> mdeslaur: put simply: {lib,}virt* should pass the right XAUTHORITY, and do what it's done for isos etc and set a facl so that it can be accessed
[00:34] <penguin42> G: It's not that simple
[00:34] <penguin42> mdeslaur: I think that would be an improvement
[00:35] <mdeslaur> G: libvirt actually does a chown libvirt:kvm to isos and image files...I don't think you'd want it to do that to your xauth file
[00:35] <G> mdeslaur: not a chown no... facl
[00:36] <G> chown/chmod would be wrong, it should be owned by $USER:$GROUP, at least setting a facl for the KVM binary would be better
[00:36] <penguin42> mdeslaur: Erk! That's nasty
[00:37] <mdeslaur> G: it doesn't fo a facl AFAIK
[00:37] <penguin42> mdeslaur: What happens if my ISOs are on something like an NFS repo I don't have write to (or worse I do have write to!)
[00:37] <mdeslaur> penguin42: yes, it's _really_ ugly
[00:37] <mdeslaur> penguin42: everything blows up
[00:37] <G> mdeslaur: I'm talking about instead of chown for $XAUTHORITY
[00:37] <mdeslaur> penguin42: what's really cool is when you specify /dev/cdrom
[00:38] <mdeslaur> G: that's only one part of the probem
[00:38] <penguin42> mdeslaur: Would this work if something passed it an open fd for the .Xauthority?
[00:38] <penguin42> (ditto for image files and cds ?)
[00:39] <mdeslaur> penguin42: it chowns /dev/cdrom to libvirt:kvm, and if something goes wrong, it never changes it back
[00:39]  * penguin42 finds a bucket
[00:39] <penguin42> mdeslaur: I await the hundreds of random CDROM access bugs with joy
[00:40] <mdeslaur> penguin42: IMHO, it should at least _add_ the required permissions with extended acls, like consolekit does...that would be better
[00:40] <penguin42> mdeslaur: Hmm that's a security hole (either way)
[00:41] <penguin42> mdeslaur: Two users, both allowed to run kvm, but they've each got ISOs/devices they're allowed to see - run kvm and it means that the other users kvm can see it
[00:41] <mdeslaur> penguin42: well, adding a user to the libvirt group basically gives up security anyway
[00:42] <penguin42> why?
[00:42] <penguin42> oh something is giving it block device access?
[00:42] <mdeslaur> among other things
[00:43] <mdeslaur> from the readme.Debian file: "Adding users to the libvirtd group effectively grants them root access."
[00:43] <penguin42> it shouldn't chown the cdrom if it's all read anyway
[00:43] <penguin42> that sucks
[02:57] <rusivi> Hello does anyone know of a outstanding Malone bug regarding "poster's remorse"?
[02:59] <micahg> rusivi: bug 80895
[02:59] <ubot2> Launchpad bug 80895 in malone (and 1 other project) "Give people five minutes to edit/delete their comment (affects: 40) (dups: 8) (heat: 230)" [Low,Triaged] https://launchpad.net/bugs/80895
[02:59] <rusivi> micahg: ty
[03:39] <rusivi> bug 418090 should be wishlisted on both yelp & WINE
[03:40] <ubot2> Launchpad bug 418090 in wine (Ubuntu) "wine instalation problem (affects: 1) (heat: 8)" [Undecided,Incomplete] https://launchpad.net/bugs/418090
[03:42] <micahg> rusivi: none of the above
[03:43] <micahg> rusivi: do you understand what wishlist is?
[03:43] <rusivi> micahg: yes that's why I asked for ti
[03:43] <rusivi> ti = it
[03:43] <micahg> rusivi: no, you don't
[03:43] <rusivi> do you understand WINE project
[03:43] <rusivi> ?
[03:43] <rusivi> :)
[03:43] <micahg> this is an installation issue
[03:43] <rusivi> I disagree still should be in yelp
[03:43] <micahg> rusivi: people commonly report bugs against yelp and firefox since that's where report a problem links are in older installs
[03:44] <rusivi> and?
[03:44] <micahg> rusivi: and the problem here is that wine can't be installed apparently on jaunty
[03:45] <rusivi> It was a matter of user familiarity but for a first-timer it can be a huge deal breaker
[03:45] <micahg> ?
[03:45] <rusivi> I'm trying to overcome those hurdles for them
[03:45] <rusivi> not for the people who already know ;)
[03:45] <micahg> no, what you wrote didn't help
[03:45] <rusivi> ok disagree but respect your opinion
[03:46] <rusivi> ty for checking
[03:46] <micahg> rusivi: first question to ask is to provide the output of: apt-cache policy wine
[03:46] <micahg> rusivi: that will tell us which version is to be installed
[03:46] <micahg> since there is no libfontconfig package in the archive, it's probably a PPA, but we ask to make sure
[03:47] <rusivi> ok np
[03:47] <rusivi> :)
[03:47] <micahg> alos, the user might have upgraded already since this bug is a year old
[03:47] <rusivi> very valid point.
[03:48] <rusivi> I'll leave me post where it stands. I do very much appreciate you checking into it.
[03:48] <lifeless> rusivi: please don't nominate things randomly
[03:49] <rusivi> lifeless: example(s)?
[03:49] <lifeless> rusivi: particularly you need to check the release process for the product first
[03:49] <lifeless> rusivi: launchpad. bug 80895
[03:49] <ubot2> Launchpad bug 80895 in malone (and 1 other project) "Give people five minutes to edit/delete their comment (affects: 41) (dups: 8) (heat: 256)" [Low,Triaged] https://launchpad.net/bugs/80895
[03:49] <rusivi> oh come on with that
[03:49] <rusivi> I am very secure it my nomination.
[03:49] <rusivi> and my post.
[03:49] <lifeless> rusivi: launchpad is a web service, it has no backports.
[03:50] <rusivi> lifeless: your saying my nomination was for a previous version of Malone?
[03:50] <lifeless> the 'nomination' process is always for backports.
[03:50] <rusivi> (doh)
[03:50] <lifeless> 2.1 was years ago
[03:51] <lifeless> and as its a web service it has no meaning.
[03:51] <rusivi> well I'm lost b/c nominations for packages are for forward versions and backwards.
[03:52] <lifeless> they may mean something different than you think they mean.
[03:52] <lifeless> we should perhaps restrict nomination use to the bug control & driver teams.
[03:52] <micahg> rusivi: nominations work differently in malone than Ubuntu
[03:53] <rusivi> micahg: duly noted
[03:54] <rusivi> lifeless: that's for you to decide. I think it's a good idea, despite my unfamiliarity.
[03:54] <rusivi> to allow newbs = me, to nominate
[03:55] <rusivi> I'll tell you this if I could not nominate I would be very salty about it
[03:55] <rusivi> I just should be more careful in the future
[03:55] <rusivi> innocent mistake
[03:58] <lifeless> rusivi: 99% of nominations are noise in the system.
[03:58] <lifeless> rusivi: because of various reasons:
[03:58] <lifeless>  - they are for bugs that are not severe enough to risk a SRU
[03:58] <lifeless>  - they are for bugs where the fix is too big and no developers are going to redo it
[03:58] <rusivi> SRU = ?
[03:59] <lifeless>  - they are simply marking enthusaism or interest from users, which doesn't actually alter what gets done
[03:59] <lifeless> stable release update
[03:59] <rusivi> k ty
[04:06] <hggdh> rusivi: we are trying to help you understand what is done, why it is done, and how it is done.
[04:06] <rusivi> hggdh: and I am very appreciative of it!
[04:06] <hggdh> rusivi: I agree beforehand that we are not always correct, but please
[04:06] <rusivi> ty
[04:06] <rusivi> I apologize if I seem a little overbearing
[04:07] <hggdh> try to understand the process. Otherwise all you will achieve is a lot of noise
[04:07] <micahg> rusivi: I think the feature you were looking for on the malone bug was marking as affecting me, not a nomination
[04:08] <rusivi> hggdh: I am trying to fully understand the processes everyone notes.
[04:10] <hggdh> rusivi | lifeless: that's for you to decide. I think it's a good idea, despite my unfamiliarity.
[04:10] <hggdh> it is not a good idea, and we have been trying to tell you so
[04:11] <rusivi> hggdh: What is not a good idea.
[04:12] <hggdh> your iteraction with lifeless just a few ago
[04:14] <rusivi> sorry lifeless if you feel insulted
[04:14] <lifeless> why would I?
[04:14] <lifeless> hggdh is saying that having non bug-control/drivers doing nominations is a bad idea
[04:15] <lifeless> which I agree with based on the fact that most nominations are not useful in the system
[04:15] <micahg> I don't know if the nominations in Ubuntu are an issue per say, but in Malone they don't make any sense
[04:15] <micahg> *se
[04:16] <lifeless> most nominations in Ubuntu are not useful
[04:16] <hggdh> and I am trying to point out that -- even when people with more experience on triaging on Ubuntu tell you something was not quite good -- you still do not heed it
[04:16] <lifeless> noniminations in projects that don't do SRU's are also not useful
[04:16] <hggdh> +1
[04:16] <lifeless> and nominations in web services are never useful
[04:16] <rusivi> I'm not going to have an involved discussion about nominations by community members. I was wrong. It got denied. I learned my lesson. end of story.
[04:16] <micahg> lifeless: true, but we need some way to know if a bug is even wanted on a previous release, don't we?
[04:17] <lifeless> micahg: do you mean 'is present in a previous release' ?
[04:17] <rusivi> I think having it as is is fine.
[04:17] <lifeless> micahg: if so, thats what bug tasks / infestations are for
[04:17] <rusivi> I should have been more careful, no big deal.
[04:17] <micahg> lifeless: no, a bug can be present without a great need for fixing
[04:17] <lifeless> micahg: the way we'd record that in lp today is a bugtask with 'wontfix' or 'wishlist' status
[04:18] <micahg> but the nominations do get abused
[04:18] <rusivi> What up Poizhan
[04:18] <Poizhan> hello rus
[04:18] <hggdh> yes. And we have been sort of easygoing with bad nominations
[04:18] <micahg> lifeless: I guess we're moving towards a task for each affected release anyways which would render nominations almost useless
[04:19] <rusivi> Poizhan = great friend and fellow Ubuntu Community Member, welcome to the Bug Squad chat room!
[04:19] <Poizhan> =D
[04:19] <hggdh> rusivi: we are all community here
[04:20] <Poizhan> Thanks.
[04:21] <rusivi> Poizhan thank you very much for joining the chat room. We have a lot of great professional who are eager and capable of working together with Bug zapping procedures.
[04:22] <hggdh> rusivi: are you trying to be sarcastic?
[04:22] <rusivi> seriously no.
[04:23] <Poizhan> I believe rus is sincere.
[04:23] <rusivi> I meant it.
[04:23] <Poizhan> :O
[04:25] <hggdh> I am sorry, rusivi. I was unsure on how to consider your comments.
[04:28] <hggdh> lifeless: what could be done re. nominations? I really would not like to limit it to -control and other restricted groups
[04:29] <lifeless> hggdh: I don't really know; but I don't know that its doing its job either.
[04:30] <lifeless> you can guarantee for any bug that is present when we release that someone will want it SRU'd
[04:30] <hggdh> heh. I would not bet on that, I would lose ;-)
[04:30] <G> hggdh: wouldn't limiting it prevent people who have made patches etc nominate those patches for SRU in Ubuntu?
[04:30] <lifeless> G: no, nominating has /nothing/ to do with the actual SRU process
[04:30] <rusivi> What I was looking for in nominations was just asking for it to be dealt with in a particular release. I did not realize that nomination was for SRU, maybe they should put SRU Nomination in each bug ;)
[04:31] <lifeless> in fact, for any bug, you can guarantee that its the most important thing for *some* user.
[04:31] <lifeless> the 'affects me' is I think a much better surrogate for estimating the impact/benefits of a fix
[04:31] <micahg> lifeless: actually, nominating is mentioned in the SRU process
[04:31] <G> micahg: thats what I thought too
[04:32] <hggdh> G: usually I am against restrictions on usage; but nominations are being so much abuse that they are losing their value
[04:32] <G> hggdh: exactly
[04:32] <lifeless> micahg: its mentioned, but its not functional.
[04:32] <hggdh> G: so, this is the rub...
[04:32] <G> why not a restriction to the bug supervisors/etc + people who have uploaded patches etc
[04:32] <lifeless> micahg: the only functional aspect is when one is *declined*.
[04:33] <hggdh> ^ yes. And this is sort of wrong
[04:33] <lifeless> An approved one doesn't trigger work - the subscription and patch preparation combined do that.
[04:33] <lifeless> I don't like restrictions either
[04:33] <G> tbh, I'm totally confused over the whole nominate stuff
[04:33] <lifeless> I'm just saying that the benefits of it are not clearly articulated, nor the connection between the code/feature in LP and the work of the sru tea.
[04:34] <hggdh> hum. Something to clear up
[04:34] <lifeless> its not surprising that even old hands get confused.
[04:34] <rusivi> Minimizing nomination eligible members to CoC signers is a great idea.
[04:34] <G> what makes the whole nomination/sru stuff even more confusing is the seperate process for Server packages
[04:34] <rusivi> CoC = Code of Conduct
[04:34] <rusivi> sorry Poizhan
[04:34] <hggdh> mostly because we/some are now using it even on Maverick
[04:35] <micahg> rusivi: no, we're talking about reducing it to bug control members
[04:35] <rusivi> I understood that and I'm not pleased nor do I agree :)
[04:35] <hggdh> rusivi: *I* am not pleased
[04:35] <hggdh> but we have to control/curb the wrong usage
[04:36] <rusivi> CoC signers is a fair way to do it IMHO
[04:36] <G> but how does that stop people
[04:36] <hggdh> it does not
[04:36] <G> "Error you nede to have signed the CoC" "Oh, I'll go sign it then"
[04:36] <lifeless> G: whats the server package process?
[04:36] <hggdh> if you do not read the documentation, it does not matter if you signed the CoC or not
[04:37] <G> lifeless: https://wiki.ubuntu.com/ServerTeam/SRUPolicy
[04:37] <G> (so I'm told)
[04:37] <hggdh> G: CoC is more important than you may realise... if you sign because it is required, but does not follow it, I will personally ban you from here
[04:38] <lifeless> G: thats nice
[04:38] <G> hggdh: hey I read it, I agree with it, but what I'm saying is that is what people's attitudes will end up as
[04:38] <hggdh> ("you" meaning "anyone", not you G actually)
[04:38] <lifeless> be nice to consolidate the definitions
[04:38] <hggdh> lifeless: I am starting to really think this is UDS material
[04:39] <lifeless> hggdh: could be
[04:39] <micahg> hggdh: we should deifnitely have some sessions on this
[04:39] <lifeless> hggdh: there will be an lp bugs member @ uds, and I will be there and jml too
[04:39] <nigelb> definitely, UDS material - I agree.
[04:39] <lifeless> hggdh: so if there are LP changes needed we can assess and help
[04:39] <hggdh> lifeless: great! I will ask a/some track(s) from QA
[04:39] <rusivi> UDS = ?
[04:40] <G> hggdh: All I'm saying is that if CoC becomes the sole barrier to prevent abuse of the nominations system, people will do it just so they can nominate
[04:40] <micahg> rusivi: Ubuntu Developer Summit
[04:40] <lifeless> CoC isn't a useful test for this
[04:40] <rusivi> ty
[04:40] <lifeless> this is a knowledge/experience issue
[04:40] <hggdh> rusivi: Ubuntu Development Summit, happens every half-year
[04:40] <hggdh> rusivi: usually November/May
[04:40] <rusivi> It is both CoC & knowledge/experience
[04:40] <lifeless> + what LP presents/offers/encourages
[04:40] <G> \
[04:41] <lifeless> rusivi: why do you think the CoC is relevant?
[04:41] <hggdh> micahg: willing to participate on such sessions?
[04:41] <micahg> hggdh: always :)
[04:41] <micahg> hggdh: please subscribe me
[04:41] <rusivi> b/c that is what Ubuntu is founded on
[04:42] <rusivi> both the philosophy and the OS
[04:42] <hggdh> lifeless: I will submit a blueprint on that
[04:42] <rusivi> and Canonical for that matter
[04:42] <lifeless> hggdh: great, thanks.
[04:42] <G> but yeah, as someone that has been following bugs/providing fixes/solutions for certain packages I have experience/knowledge in the whole nomination system and different SRU policies are confusing as anything
[04:42] <G> (my personal opinion there)
[04:42] <hggdh> G: indeed, and thank you for pointing this out
[04:43] <nigelb> The only irk I have with sru is that someone who knows what they're doing need to be following it up.
[04:43] <hggdh> G: I will propose a session/track on UDS to consolidate this, at least on the macroscopic level
[04:43] <nigelb> We are far too busy to have an automatic process run.
[04:43] <lifeless> rusivi: Launchpad hosts much more than Ubuntu; other projects have nomination issues too, the CoC wouldn't help them. Secondly, unlike Ubuntu membership or PPAs, this doesn't lead to using potentially lots of resources or franchisement.
[04:43] <lifeless> rusivi: the CoC is totally irrelevant for this IMO
[04:43] <rusivi> lifeless no it's not
[04:44] <rusivi> IMHO
[04:44] <lifeless> I'd need a much stronger argument than that to even consider accepting a patch using it as a test.
[04:44] <Poizhan> It's impossible for CoC *not* to be relevant.
[04:44] <rusivi> I think having the opportunity to see other project's stuff and contribute is a valuable and interesting thing
[04:45] <lifeless> yes, neither of those need a CoC signature
[04:45] <rusivi> I learned a lot about, granted mis-posting, to projects I never even heard of
[04:45] <hggdh> the CoC is important as a ethic
[04:45] <G> hggdh: as an example https://bugs.edge.launchpad.net/ubuntu/+source/seabios/+bug/589063
[04:45] <ubot2> Ubuntu bug 589063 in seabios (Ubuntu) (and 1 other project) "Windows Server 2008 won't boot with more than 4 vCPUs (affects: 4) (heat: 52)" [Undecided,Confirmed]
[04:45] <Poizhan> The morality portion of the CoC.
[04:45] <hggdh> G: ohhh, this bug... yes...
[04:46] <G> hggdh: I was told to nominate it via the u-server mailing list and never heard a thing (and I haven't seen the list of SRU bugs etc since)
[04:46]  * hggdh works with the server team
[04:46] <micahg> but the CoC is only relevant to Ubuntu and maybe launchpad itself
[04:46] <lifeless> unlesss morality is at issue in the thing being restricted, the CoC isn't particularly relevant; morality isn't relevant for clicking on 'nominate for'.
[04:46] <G> hggdh: ahhh yes I've seen your name in a few libvirt bug e-mails :)
[04:46] <G> (just checked /whois)
[04:47] <Poizhan> What realm of interaction are we talking about, that doesn't include the ubuntu community or the facilitation of launchpad?
[04:47] <lifeless> if someone is being abusive and clicking all over the place, folk will complain and the account will be banned.
[04:47] <lifeless> which is sad.
[04:47] <hggdh> G: can you please forward me your email?  hggdh2 at ubuntu dot com
[04:47] <lifeless> sigh, I've better things to do, sorry.
[04:47] <G> hggdh: I'll have a hunt for it, it's on my old g-mail server I think :)
[04:47] <lifeless> hggdh: G: It will be nice to get some clarity on this; please subscribe me to the spec.
[04:48] <hggdh> lifeless: roger wilco
[04:48] <G> hggdh: yes, please subscirbe me ona  spec even though I won't be attending UDS
[04:48] <G> (dev-nigelj)
[04:48] <nigelb> oh, another nigel :)
[04:49] <hggdh> G: will do
[04:49] <G> nigelb: heh :)
[04:50] <G> (the irc nick 'G' doesn't make that too obvious I admit)
[04:50] <nigelb> heh, true
[04:50] <hggdh> rusivi: the CoC is more a philosophical stand than anything else. We do follow and abide by it, but it does not replace documentation
[04:51] <hggdh> Poizhan: for your question: all that is needed to do a lot of things in LP is an LP account
[04:51] <Poizhan> hggdh: thank you for the clarification
[04:51] <nigelb> speaking of which, is it just me or the tracks a bit different from the usual this time?
[04:51] <hggdh> Poizhan: a perfect example is, indeed, rusivi -- s/he is not a member of the bugSquad
[04:52]  * nigelb doesn't see things like 'kernel', 'qa', etc
[04:52] <rusivi> hggdh: but I do my best to abide by your wishes and principles about BugSquad'ing
[04:52] <hggdh> nigelb: the tracks are different, it will be more on areas of interest than on specialty groups
[04:52] <Poizhan> hggdh: That does not mean one cannot be a valueable member of the community no?
[04:53] <nigelb> hggdh: heh, that's confusing ;)
[04:53] <hggdh> rusivi: I did not mean anything else, I was just pointing that you do not need to be a member of the bugSquad to work on bugs
[04:53] <lifeless> nigelb: yes, UDS has a new structure
[04:54] <hggdh> Poizhan: indeed. The community is comprised of all the users
[04:54] <rusivi> hggdh understood
[04:54] <nigelb> lifeless: should be interesting.  At least this time it should be easier to choose sessions to attend.
[04:54] <hggdh> or not...
[04:54] <micahg> rusivi: why are you marking package installation bugs incomplete asking for people to test with the devel release?
[04:55] <nigelb> hggdh: haha
[04:55] <micahg> rusivi: bug 623927
[04:55] <ubot2> Launchpad bug 623927 in vlc (Ubuntu) "package mozilla-plugin-vlc 1.0.6-1ubuntu1.1 failed to install/upgrade: unable to install new version of `/usr/lib/mozilla/plugins/libvlcplugin.so': No such file or directory (affects: 1) (heat: 147)" [Undecided,Incomplete] https://launchpad.net/bugs/623927
[04:55] <rusivi> micahg: yes I know it seems troll/spam'ish
[04:55] <nigelb> hggdh: every UDS participant feels he/she had access to a time machine.
[04:55] <rusivi> but I felt compelled based on my actions to give them the opportunity to solve their own problem not just shut them down
[04:55] <rusivi> lock stock and barrel
[04:56] <rusivi> I'm reviewing all my bugs I invalidated for mis-invalidation
[04:56] <micahg> rusivi: it doesn't help, package installation bugs need to be dealt with in the release they occur in
[04:56] <rusivi> micahg: That is why I prefaced with the troll spam'ing remark
[04:57] <micahg> rusivi: well, please stop
[04:57] <rusivi> ok sorry
[04:57] <rusivi> I'll move forward then
[04:57] <lifeless> bugs that are confirmed or triaged *should not be changed to incomplete*
[04:57] <lifeless> ever
[04:57] <rusivi> I'm not going into a habit of posting then going back on posts
[04:57] <rusivi> I'm in a learning process
[04:58] <lifeless> yes, OTOH you've touched nearly 1500 bugs
[04:58] <rusivi> I understand it may be frustrating but it has revealed alot about what I don't know and sparked my interest in a ton of projects, ideas, and packages!
[04:58] <lifeless> I think you need to touch less, with more mentoring, or something.
[04:58] <micahg> closer to 2k actually from what I can tell
[04:58] <lifeless> learning is good
[04:59] <rusivi> I'm very open to being mentored more focusedly
[04:59] <Poizhan> micahg: What would be a more effective action path in order to address stale or unresolved bugs, I'm assuming posting to 4-5 year old bugs is frowned upon in the same way necroing a 5 year old forum thread would be, correct me if I'm wrong.
[04:59] <rusivi> I'm still learning a ton, micahg has been holding me very accountable to my actions and I have learned a great deal from this
[05:00] <micahg> Poizhan: depends on the bug, posting if the bug still occurs when recreate steps are present or easily inferable is frowned upon
[05:00] <micahg> Poizhan: checking for the same bug upstream is a good start, then we can link it and mark our bug triaged
[05:00] <Poizhan> micahg: That's some what ambiguous
[05:00] <hggdh> Poizhan: if you ask a question on a bug you should subscribe to it -- otherwise what is the meaning of asking the OP for something if nobody is going to read it?
[05:01] <Poizhan> Why retain a bug if no one plans to ever resolve it, let alone fix it?
[05:01] <hggdh> Poizhan: and -- when the OP answers -- you should act on it
[05:01] <rusivi> michag: I understood/understand it is, but Launchpad is a community effort and as part of the community even if I cannot go through all the involved processes of recreating the bug and dealing with I feel it is of significant contribution to ask if their problem is still outstanding. It is acknowledging thier problem was and is important shows the community is behind them!
[05:01] <micahg> Poizhan: we forward most bugs upstream if they are inherent in the software and not related to or changes
[05:01] <hggdh> Poizhan: this does not justify a fire-and-forget action
[05:02] <rusivi> micahg: respecting the BugSquad process of if your not going to fix it don't bother
[05:02] <micahg> rusivi: no, that is not appropriate and against current bug squad policy
[05:02] <hggdh> rusivi: you misunderstand triage
[05:02] <Poizhan> hggdh: I agree with you, restraint is always productive, should there not be some measure of accountability on the OP to resolve the issue, or at least maintain the bug upstream?
[05:02] <micahg> it just serves to annoy the reporter
[05:03] <nigelb> I'm actually surprisd that no bug reporter hasn't trolled you yet.
[05:03] <micahg> nigelb: it's happened
[05:03] <hggdh> Poizhan: the majority of bugs are opened by casual users, not experts on Linux/Ubuntu. You cannot require from them doing this all.
[05:03] <micahg> and upstream triagers as well
[05:03] <hggdh> Poizhan: this is why there is triage
[05:04] <Poizhan> hggdh: duly noted
[05:04] <rusivi> micah: Yes the risk of pissing people off exists but I should not feel uncomfortable asking if their problem is resolved in a judicious manner (like when it is 1-4 years old with no patch, comments, zilch)
[05:04] <Poizhan> rusivi: this seems very reasonable
[05:04] <nigelb> rusivi: you should be etrying to recreate and see if the bug exists, not ask.
[05:04] <micahg> rusivi: that's not true, that's what we've been trying to tell you, if there are recreate steps, they've done their part
[05:05] <micahg> rusivi: if you don't have time to reproduce, work on bugs that don't require it
[05:05] <hggdh> the issue here is of perception: an user opened a bug years ago. It went on undeteted; then somebody asks if it is still an issue, and there is no follow-up
[05:05] <hggdh> end result: we are worse off
[05:06] <Poizhan> hggdh: please explain *worse off*
[05:06] <rusivi> hggdh: yes just asking inquiring for inquiry sake is waste of time. But providing some sort of suggestion to move forward is good
[05:06] <rusivi> hggdh: every post I do, I have done this.
[05:06] <rusivi> hggdh: even ones I misposted too
[05:07] <hggdh> worse off -- the poor user opened a bug years ago, nobody looked at it; then somebody asks if it is still an issue, and then -- again! -- nothing
[05:07] <rusivi> hggdh: agreed on that point
[05:08] <hggdh> this is why we recommend subscribing to the bug. If one cannot bother to subscribe, then one should not bother to comment
[05:08] <rusivi> hggdh / Poizhan we have to give them something to move forward with. If your BugSquad you recreate or don't post.
[05:08] <G> hggdh: btw, SRU policy says that the modification of verification-needing tags should be done by the SRU Verification team, do yuo want to leverage my comments in 455832 & 571093 to get the libvirt update out?
[05:08] <hggdh> bug 455832
[05:08] <ubot2> Launchpad bug 455832 in libvirt (Ubuntu Karmic) (and 3 other projects) "segfault when attaching disk with same physical device (affects: 2) (heat: 29)" [High,Won't fix] https://launchpad.net/bugs/455832
[05:08] <hggdh> bug 571093
[05:08] <ubot2> Launchpad bug 571093 in libvirt (Debian) (and 4 other projects) "[SRU] multipath + libvirtd eats away more memory over time (affects: 8) (heat: 73)" [Unknown,Fix released] https://launchpad.net/bugs/571093
[05:09] <rusivi> I've found a lot of people who were both thankful and noted their problem was fixed or moved forward with it on my inquiring with helpful suggestion. Granted I did not, from my skill level, reinvent the wheel, but it still has contribution value.
[05:09] <micahg> rusivi: yes, but there were a large portion annoyed by the efforts as well, that's why we don't think it's worth the tradeoff
[05:09] <rusivi> This empathy is also what the CoC is all about
[05:10] <rusivi> micahg: I see.
[05:10] <rusivi> micahg: then I beg your pardon if I have annoyed many people it was certainly not my intention to do so.
[05:11] <rusivi> micahg: that is why I am striving to continue to improve in my post judiciousness.
[05:11] <Poizhan> micahg: Who is being annoyed?
[05:11] <rusivi> micahg: This is what I was talking about when I first join the channel a week ago, sub-triage but above-spam
[05:11] <Poizhan> rusivi: Why are you annoying people :(
[05:11] <micahg> Poizhan: reporters, Ubuntu triagers/developers, upstream triagers/developer
[05:12] <Poizhan> micahg: How would you suggest rusivi move forward, as a community member, who is interested in addressing unresolved or buried bugs?
[05:13] <hggdh> Poizhan: instead of asking, try to recreate
[05:13] <hggdh> Poizhan: do not mark incpmplete bugs that have been confirmed/triaged
[05:13] <Poizhan> hggdh: I have not, and do not plan to do so.
[05:14] <micahg> Poizhan: there are many types of bugs, each with their own actions, that's why we try to assign mentors or at the very least suggest asking *before* taking an action on things that seems unfamiliar
[05:14] <hggdh> G: I am unsure on bug 455832 -- did you confirm it NOT wirkig with the patch?
[05:14] <ubot2> Launchpad bug 455832 in libvirt (Ubuntu Karmic) (and 3 other projects) "segfault when attaching disk with same physical device (affects: 2) (heat: 29)" [High,Won't fix] https://launchpad.net/bugs/455832
[05:16] <Poizhan> It seems there is a divide between the community and the bug zappers.
[05:16] <rusivi> Poizhan: not quite.
[05:16] <rusivi> We all try to come to a mutual understanding of each others views and compromise/adopt philosophy.
[05:17] <hggdh> G: you missed changing the tag 'verification-needed' to 'verification-done'
[05:17] <G> hggdh: okay, so I am allowed to change it?
[05:17] <G> hggdh: btw, I meant that it does fix it, i.e. thi right error appears
[05:17] <hggdh> G: yes, you are :-)
[05:18] <G> I'll change the tags now then :)
[05:18] <hggdh> G: so both bugs should be marked 'verification-done'. The corrected package will then be officially published
[05:18] <hggdh> G: if the patch fails, then it should be tagged 'verification-failed'
[05:18] <G> hggdh: okay marked both as done
[05:19] <hggdh> G: thank you. As a bonus your LP name will be published ;-)
[05:20] <hggdh> Poizhan: actually, no, there is no divide. We are trying to explain the process, but it has been a bit difficult
[05:20] <G> hggdh: I've also clarified what I meant about the error
[05:20] <hggdh> G: thank you
[05:21] <G> hggdh: so whats your thoughts regarding next steps for the seabios issue?
[05:21] <G> hggdh: I've also noticed that he control file doesn't look right, instead of Ubuntu Developers it has Dustin's name personally there
[05:22] <hggdh> G: this is not a big issue -- only means Dustin is going to be called on all bugs on it...
[05:22] <G> heh :)
[05:22] <hggdh> G: I am still to read it all
[05:22] <G> hggdh: ahhh okay
[05:23] <G> (yeah sorry my updates to bugs are typically long winded)
[05:23] <hggdh> Poizhan: also, I am not sure what you mean by 'bug zappers' and 'community'
[05:23] <hggdh> this is a community channel
[05:24] <hggdh> so, who are the bug zappers?
[05:24] <Poizhan> hggdh: excuse me, the professionals and the amateurs.
[05:24] <Poizhan> hggdh: dev/end user.
[05:25] <hggdh> oh, OK. Then yes, I agree
[05:28] <Poizhan> From what Rusivi and I have discussed, he is definitely geniune in his desire to assist in moving the community forward, but it seems like the proper channels and procedures are ambiguous or open to interpretation.
[05:28] <Poizhan> ...in certain situations.
[05:29] <rusivi> Not regarding BugSquad.
[05:29] <rusivi> They are in stone. Fix it or don't touch.
[05:29] <rusivi> :)
[05:31] <micahg> Poizhan: if something is ambiguous, one should ask for clarification before continuing
[05:46] <rusivi> bug 159396 really gets at the philosophy difference of community member (move forward/provide helpful suggestions/ask for community testing on Maverick) vs. BugSquad
[05:46] <ubot2> Launchpad bug 159396 in apt-file (Ubuntu) "apt-file can't find Contents on /cdrom (heat: 3)" [Undecided,New] https://launchpad.net/bugs/159396
[05:47] <rusivi> If BugSquad triaging, don't touch unless your fixing (and poster offers helpful suggestion) while community member who wants to help but does not have the skills to and does best to try to.
[05:47] <rusivi> :)
[05:47] <micahg> rusivi: that's not the policy no matter how many times you say it is
[05:47] <rusivi> rusivi = not comp. sci. major
[05:48] <micahg> and you can clearly see the reporter's annoyance
[05:48] <rusivi> micahg: I do see he is frustrated but that does not mean the issue is not moving forward
[05:48] <rusivi> we want his issue fixed, how else then to either fix for him or ask him info about it?
[05:48] <micahg> rusivi: it doesn't move fwd by you asking again
[05:49] <rusivi> micahg: and this is where I disagreed with you a week ago
[05:49] <micahg> it can move fwd by you marking confirmed if you can reproduce, or find an upstream bug with the same problem that we can link
[05:49] <rusivi> sub-triage/above-spam
[05:50] <micahg> rusivi: you're making that up, asking again isn't sub-triage
[05:50] <rusivi> micahg: and from the way I see it the issue is moved forward, even in from your vantage insignificantly, it still  moved forward
[05:50] <micahg> triage is getting the bug ready for the developer
[05:50] <micahg> rusivi: not really, because there is no external confirmation still
[05:51] <rusivi> Well maybe someone else in the community is reviewing!
[05:51] <rusivi> not just bug squad
[05:51] <micahg> we're at the same point we were when the bug was filed
[05:51] <rusivi> That's not true
[05:51] <micahg> rusivi: what do you mean?
[05:52] <G> out of interest, what bug are you talking about?
[05:52] <rusivi> micahg: what I mean is that we (community) are giving the poster the gentle nudge to see what else he can do with it (which he did).
[05:52] <micahg> rusivi: no, that doesn't help anything
[05:53] <rusivi> micahg: disagreed but respect your opinion.
[05:53] <micahg> rusivi: and as hggdh we are all part of the bugs community here
[05:53] <micahg> rusivi: the point is the bug cannot move forward until someone else confirms it
[05:53] <rusivi> Their is no disputing that fact.
[05:54] <G> micahg: have you got the number of the bug you and rusivi are talking about?
[05:54] <rusivi> the bug cannot move forward without that. But the bug also cannot move forward if nobody is looking at it!
[05:54] <micahg> rusivi: you posting for the reporter to confirm just annoys people, that's the point
[05:54] <rusivi> Well I see better annoyed then forgotten
[05:54] <rusivi> but not just annoyed for annoyed sake
[05:54] <micahg> rusivi: so, there are 2 ways to help, confirm the bug has sufficient steps to reproduce or check upstream for a similar bug
[05:54] <micahg> G: bug 159396
[05:54] <ubot2> Launchpad bug 159396 in apt-file (Ubuntu) "apt-file can't find Contents on /cdrom (heat: 3)" [Undecided,New] https://launchpad.net/bugs/159396
[05:54] <rusivi> like "is your bug still a problem" = fail
[05:55] <micahg> rusivi: that's exactly what I'm sayign
[05:55] <rusivi> but asking him to test on Maverick is not out of control
[05:55] <rusivi> I'm sorry.
[05:55] <micahg> rusivi: yes, it's against current policy
[05:55] <micahg> since there are steps to reproduce
[05:55] <rusivi> BugSquad policy yes.
[05:55] <micahg> rusivi: Ubuntu bugs policy
[05:55] <rusivi> Community policy?
[05:55] <rusivi> CoC?
[05:56] <G> argh yeah, asking like that is annoying, and I'll tell you why:
[05:56] <micahg> rusivi: as I said earlier in the week, I'm very close to calling it a violation of the CoC since you've been told to stop
[05:56] <G> 1. You don't know if the reporter, had just reported it to be a good person and has a continuted interest in the bug
[05:56] <G> 2. You don't know if the reporter still has the resources to test the bug continually
[05:57] <rusivi> micahg: well I'm sorry if you feel that way. I don't believe my actions have violated the CoC.
[05:57] <G> 3. It's simple enough to test yourself
[05:57] <micahg> rusivi: also, we appreciate you trying to help and have given you guidance in how that energy can be used, but there seems to be a communication issue
[05:58] <micahg> G: right on all 3 counts which is why we don't advocate asking that anymore
[05:58] <rusivi> micahg: there is not a communication issue at all. I agree with your philosophy, but your putting me down by saying my efforts in inquiring about old bugs are pointless...
[05:58] <micahg> even thought we are overloaded with bugs
[05:58] <G> Using 2 as an example, I reported a bug to another distro, one I discovered by downloading a Beta ISO and installing etc, noticed something wrong reported a bug (it was related to the installer), the response from the maintainers of the bug was "Can you try the latest daily iso"
[05:58] <micahg> rusivi: I've tried very hard not to attack you personally
[05:59] <micahg> rusivi: I'm saying more than that, it's harmful
[05:59] <rusivi> G: But I'm not a maintainer.
[05:59] <micahg> rusivi: if you don't want to reproduce, find bugs with insufficient information and ask for it
[06:00] <G> As someone w/ a very small bandwidth cap/slow speed connection (less than ~700MB/day 2Mbit/s) it wasn't of that great interest for me to continually test the daily CDs
[06:00] <rusivi> micahg: I don't feel personally attacked, I feel that you have done nothing but guide me in the direction of following BugSquad procedures
[06:00] <G> last week, 4 releases later, I discovered the bug in the current version
[06:00] <G> I'm not going to bother reopening it, because I know what the response is going to be
[06:01] <persia> So, can we set the concept of "CoC" violation aside here?  The point of the CoC is that we discuss these things rationally, not that we're especially nice.
[06:01] <rusivi> micahg: I'm tryin to work together with everyone :) I'll see what I can do about more "BugSquad" adhered zapping ;)
[06:01] <G> and I still don't have the resources to continually test it, even though it was easily testable by triagers/etc
[06:01] <persia> rusivi, Essentially, the goal is to make the bug useful to be fixed.  Operations on bugs for their own sake are useless.
[06:01] <G> rusivi: all I'm saying is that it causes bad faith
[06:01] <rusivi> I really don't like being threatened about CoC when I feel I'm in the right
[06:02] <persia> So it's only interesting to ask for confirmation if there is a real expectation that it's fixed (because the person asking for confirmation can't repeat with the provided steps on a current install)
[06:04] <G> and going w/ persia's line, it's a bit different to say "This worked for me on this type ofhardware, does it still happen for you, what hardware are you using"
[06:04] <persia> Indeed, and that kind of comment is *encouraged*
[06:05] <G> really you've got to think of the bug reporters as the customers
[06:05] <persia> Well, or as other members of a cooperative community.  Depends on your viewpoint.
[06:07] <AbhiJit> hi
[06:07] <G> persia: well both really, but looking at them as customers means respecting them
[06:07] <G> (more)
[06:08] <persia> G, Does it?  I respect my peers more than folks who throw money at me so they can ignore things.
[06:08] <persia> Maybe I have different customers than you :)
[06:08] <lifeless> persia: ;p;
[06:08] <lifeless> wow, reading backlog
[06:09] <lifeless> I think we may need to send rusivi a warning
[06:09] <lifeless> I know of at least one package maintainer who reckons they simply don't have the time to recover the correct bug state from the changes rusivi did
[06:09] <G> persia: they earn the respect as 'customers' because they've taken the time to report the bug, sure they aren't paying money, but they are users and they've take the time
[06:10] <persia> G, That earns them my respect as "peers" for all the same reasons :)
[06:10] <persia> I think we have different worldviews, but agree on how to treat bug reporters :)
[06:10] <G> yeah we get to the same end result
[06:12] <persia> lifeless, How do you mean "send a warning"?  We can raise an issue to be discussed by some body (say in a bugsquad meeting or so).
[06:12] <micahg> lifeless: many of us have sent messages
[06:12] <persia> I'm unsure that rusivi qualifies for the bans we usually give to spammers, as there seems to be interest in contribution.
[06:13] <lifeless> persia: I mean that there seems to be a rough consensus that he is not *modifying* his behaviour as requested, at least not in a reasonable timeframe.
[06:13] <G> tbh it's seems every time I look at a ubuntu channel I see a discussion w/ rusivi
[06:13] <micahg> well, wanting to help doesn't mean one can do what they want, we might need some type of bug etiquette similar to what mozilla's bugzilla has
[06:14] <lifeless> micahg: its larger than Ubuntu; he has run riot through medibuntu, various upstreams on launchpad as well.
[06:14] <micahg> lifeless: is it possible to just ban from 1 module?
[06:15] <lifeless> not currently
[06:15] <persia> lifeless, The medibuntu/upstream stuff probably needs to be handled from a launchpad perspective though: I'm not sure we can do anything about that other than consider it as supporting information.
[06:15] <lifeless> https://bugs.edge.launchpad.net/~rusivi1/+commentedbugs - 1500 bugs
[06:15] <G> in how long?
[06:17] <micahg> lifeless: that doesn't include the invalid ones
[06:17] <lifeless> yes
[06:17] <G> potentially over a year
[06:17] <lifeless> but that goes back to 09-10
[06:17] <lifeless> I'm trying to find the spike
[06:17] <G> 1762 including invalid
[06:18] <lifeless> you'll have some duplicate tasks in there
[06:18] <lifeless> https://bugs.edge.launchpad.net/~rusivi1/+commentedbugs?assignee_option=any&field.affects_me.used=&field.assignee=&field.bug_commenter=rusivi1&field.bug_reporter=&field.bug_supervisor=&field.has_branches=on&field.has_branches.used=&field.has_cve.used=&field.has_no_branches=on&field.has_no_branches.used=&field.has_patch.used=&field.omit_dupes=on&field.omit_dupes.used=&field.searchtext=&field.status:list=CONFIRMED&field.status:list=
[06:18] <micahg> lifeless: earlier this week IIRC
[06:18] <lifeless> bah
[06:18] <lifeless> https://bugs.edge.launchpad.net/~rusivi1/+commentedbugs?assignee_option=any&field.affects_me.used=&field.assignee=&field.bug_commenter=rusivi1&field.bug_reporter=&field.bug_supervisor=&field.has_branches=on&field.has_branches.used=&field.has_cve.used=&field.has_no_branches=on&field.has_no_branches.used
[06:18] <lifeless> =&field.has_patch.used=&field.omit_dupes=on&field.omit_dupes.used=&field.searchtext=&field.status:list=CONFIRMED&field.status:list=EXPIRED&field.status:list=FIXCOMMITTED&field.status:list=FIXRELEASED&field.status:list=INCOMPLETE_WITHOUT_RESPONSE
[06:18] <lifeless> &field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INPROGRESS&field.status:list=INVALID&field.status:list=NEW&field.status:list=OPINION&field.status:list=TRIAGED&field.status:list=WONTFIX&field.status_upstream-empty-marker=1&field.subscriber=&field.tag=&field.tags_combinator=ANY&orderby=date_last_updated&search=Search&start=0
[06:19] <G> lifeless: tinyurl?
[06:19] <lifeless> heh, should have; sorry.
[06:19] <lifeless> so on the 13th
[06:19] <lifeless> http://tinyurl.com/2cwuwwz
[06:19] <hggdh> wow! I leave for 30 minutes, and all hell breaks loose
[06:20] <persia> !ohmy
[06:20] <ubot2> Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
[06:20] <persia> :p
[06:20]  * hggdh just finished reading the backlog
[06:20] <G> persia: heh
[06:20] <lifeless> bug 492837 3/4 down the first page
[06:20] <hggdh> persia: mea culpa
[06:20] <ubot2> Launchpad bug 492837 in virtualbox-ose (Ubuntu) "Blank screen in virtualbox guest - says "running" (affects: 1) (heat: 6)" [Undecided,Fix released] https://launchpad.net/bugs/492837
[06:20] <lifeless> so - say all but 50 bugs are since the 13th
[06:21] <persia> hggdh, Would you be willing to take this to some appropriate escalation meeting?  They always seem to happen in your timezone.
[06:21] <lifeless> so thats between 1450 and 1720 bugs in 6 days
[06:21] <G> hmmmmm
[06:21] <hggdh> persia: yes, no problem
[06:21] <G> that bug is actually interesting in itself
[06:21]  * persia has trouble imagining that to be the result of deep investigation into any of them
[06:21] <lifeless> right
[06:21] <persia> hggdh, Thanks :)
[06:21] <G> "Machine is 'running' but totally unresponsive. I think it needs a boot file..."
[06:22] <lifeless> and he's been told 'dig deep stop doing surface stuff'
[06:22] <G> so he sets it fixed released
[06:22] <hggdh> now, careful there
[06:22] <hggdh> remember that one example does not a trend show
[06:22] <lifeless> right
[06:22] <lifeless> I am not claiming that is work is accurate or inaccurate.
[06:22]  * hggdh knows... there is much more
[06:23] <G> hggdh: of course, I was just saying that reading it it seems wrong on it's own
[06:23] <lifeless> I'm claiming that nearly 600 bugs a day is guaranteed to be shallow
[06:23] <lifeless> and that we've asked repeatedly for in depth analysis.
[06:23] <persia> Sometimes that's called for, but it's always been good practice to tell folks when you're going to touch a few hundred bugs for some purpose.
[06:23] <lifeless> anyhow, thats enough analysis
[06:24] <hggdh> yes, it does. I have an email thread with her/him about some of her/his actions, and sometimes I think we were on different channels
[06:24] <lifeless> I'm convinced that the vast bulk of this activity is recent
[06:24] <lifeless> not contributing productively
[06:24] <hggdh> but... <sigh/> we *did* try
[06:24] <persia> No.
[06:24] <lifeless> it may be recoverable
[06:25] <hggdh> lifeless: in about a week there were ~2k bugs touched
[06:25] <lifeless> but I think we need to limit the damage; as it is there are a huge number of bugs needing experienced review now.
[06:25] <hggdh> yes
[06:25] <persia> We are still working to ensure that rusivi has a productive place as a member of our community.  "we *did* try" implies we have completed, and we ought not consider it completed as long as someone with interest is not being productive in our (collective) view.
[06:25] <micahg> I've been reviewing the vlc/mozilla bugs
[06:25] <micahg> it'll take me another week or 2 to get through them all though
[06:26] <G> I haven't seen anything on the libvirt/qemu bugs
[06:26] <hggdh> persia: BTW -- I will propose a track about but track flow, specially nominations
[06:26] <hggdh> G: lucky you
[06:27] <persia> hggdh,  I fail to parse that.  Did you mean "I'm planning a session at UDS about a spec for bug tracking workflow, specifically about nominations?"
[06:28] <hggdh> persia: sorry, tired. I will open a blueprint about bug tracking workflow, specially nominations
[06:29] <hggdh> also, it sounds like our docs on triage are failing somewhere
[06:29] <lifeless> persia: bug nomination is one of the things that  rusivi added noise in
[06:29] <lifeless> hggdh: the traige docs could say more boldly 'do not mess with confirmed/triaged status bugs. Thanks.'
[06:30] <lifeless> hggdh: its kindof by implication at the moment
[06:30] <hggdh> yes. And, I think, more on 'do' and 'do not'
[06:30] <persia> The attempt not to be negative needs to be stomped.  We should be clear about things we wish not to be done, so we can discuss them effectively.
[06:30] <micahg> hggdh: maybe a separate session on Do's and Don'ts of bug triage
[06:31] <hggdh> persia: and nomination seems to have two different meanings right now: SRU and 'fix on the current devel'
[06:31] <persia> hggdh, It has more uses than that, but yes, is hopelessly messy.
[06:31] <hggdh> micahg: I could do that on my devel week session
[06:31] <micahg> hggdh: I was thinking more for creating the list :)
[06:31] <lifeless> you can be positive and still prohibit certain actions
[06:31] <persia> But let's not conflate 1) fixing the docs, 2) fixing nominations, and 3) ensuring we can effectively apply available interest and energy without causing dispute
[06:31] <hggdh> persia: sorry, yes, these two are the ones involved in tonight's discussion here
[06:32] <lifeless> 'do walk a metre back from the unstable cliff edge' vs 'do not come closer to the unstable cliff than 1 metre'
[06:32] <hggdh> lifeless: indeed, I see your point
[06:33] <persia> lifeless, At one point someone said they didn't like negative statements "Don't do this", or limiting statements "this is prohibited".  I agree that well structured, encouraging documentation is possible with that class of statement, but it needs some push to get over the inertia from the past.
[06:34] <persia> Oh, so things like "Once a bug has reached "Triage", it is then expected to be solved.  the next action on the bug must be related to a solution in some way"?
[06:34]  * hggdh always thinks of 'positive feedaback' -- a system going entropic -- and 'negative feedback' -- a controlled system
[06:34] <lifeless> I think minimising the blocking-rules is a good idea, but eliminating them completely implies that everything is tolerated.
[06:34] <lifeless> which is false.
[06:34] <lifeless> anyhoo
[06:35] <lifeless> no big conflict here
[06:35] <lifeless> but we need to act on the several issues that are becoming evident
[06:35] <lifeless> right now, I'm going to go and try to make bugtask loading faster still
[06:36] <hggdh> lifeless: yes!
[06:36]  * hggdh goes to bed. Tomorrow is Mowing Morning...
[06:36] <nigelb> hggdh: heh, night :)
[06:37] <G> hggdh: have a good night
[06:37] <hggdh> g'night all
[06:56] <vish> Poizhan: hmm , are you with rusivi's LoCo or just new the triage as well?
[06:56] <Poizhan> He's my cousin.
[06:56] <vish> ah!
[06:56] <Poizhan> But his views/claims are not necissarily mine.
[06:56] <Poizhan> Of course :)
[06:57] <vish> Poizhan: well , it is highly unfair to say there is a divide between "the professionals and the amateurs"
[06:57] <vish> Poizhan: people like micahg have been exceedingly patient with rusivi
[06:58] <vish> Poizhan: they have been trying to help him/her understand how to triage and saying that there is a divide does not help rusivi understand the process better
[06:58] <Poizhan> vish: a divide is not necissarily a negitive thing
[06:59] <Poizhan> vish: I wasn't referring to rusivi when I expressed that opinion.
[06:59] <micahg> Poizhan: we try to maintain an atmosphere of collaboration and avoid the us vs them mentality
[06:59] <vish> Poizhan: no.. there isnt *any* divide .. people just have a misunderstanding of the process and we try to help understand
[06:59]  * persia notes that the vast majority of folks working on Ubuntu bugs are not doing so professionally (although they may exhibit professional demeanor in doing so, depending on their profession, etc.)
[07:01] <AbhiJit> thats the difference between ubuntu adn others - ubuntu - we all as team- works together- it takes all of us with it- and thats why its the most famous one
[07:01] <Poizhan> micahg: This is my first time in this IRC channel ever, I don't use Ubuntu actively, and I've rarely submitted bug report. I can say objectively the bugging process is not end-user friendly.
[07:01] <micahg> Poizhan: we welcome suggestions on how to improve it
[07:01] <Poizhan> micahg: and the atmosphere of this irc has been divisive, at least in my limited time here.
[07:02] <Poizhan> micahg: Obviously I don't know the whole story.
[07:02] <persia> AbhiJit, To be fair, there are plenty of other distributions with that model, but yes, some don't work that way.
[07:02] <micahg> Poizhan: in this channel, you'll usually find people asking questions and getting answers, this type of chat is highly unusual
[07:02] <vish> Poizhan: thats a nice start.. yes, not end-user friendly , but we would welcome suggestions :)
[07:02] <AbhiJit> persia, yah
[07:03] <Poizhan> micahg: Unfortunately, rusivi is...high spirited.
[07:03] <vish> Poizhan:  if rusivi wasnt available here on irc by now his lp account would have been disabled.. since his activity pattern is nearly bordering on spamming..  but since rusivi was *here*, we do understand that rusivi is trying to help and we are trying to help him understand how to be more productive
[07:03] <persia> highly-spirited is generally a good thing :)  Just needs focus.
[07:05] <AbhiJit> ohh i just forget to say you all that its me - abhijit!
[07:05] <AbhiJit> :)
[07:05] <persia> Hrm?
[07:06] <AbhiJit> persia, i change my nick from abhijit to AbhiJit
[07:06] <AbhiJit> :)
[07:06] <persia> Ah, OK.  makes sens.
[07:06] <AbhiJit> :)
[07:06] <vish> Poizhan: but seriously though.. we may sound like hard asses , but we aernt, really!  :)  we are short of high spirited people like rusivi and do want rusivi to help us ;)
[07:06] <micahg> !ohmy | vish :)
[07:06] <ubot2> vish :): Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
[07:06] <vish> ;p
[07:06] <AbhiJit> :D
[07:08] <vish> anywho.. hggdh is sleeping now!
[07:08] <Poizhan> vish: It's just a certain mindset that I recognize that keeps Ubuntu from becoming more mainstream than it could be.
[07:09] <Poizhan> vish: progress is progress.
[07:09] <vish> Poizhan: care to explain? maybe we just got too accustomed ? :)
[07:09] <micahg> Poizhan: we welcome input on this, we're constantly trying to improve the process
[07:10] <Poizhan> vish: if certain bugs were fixed, and wishlist items implemented, I would switch, and many people I know might follow suit, rusivi is just trying to make it so that the average user can make the switch painlessly.
[07:10]  * AbhiJit dont see any problem in this channel or bug triaging process!
[07:10] <micahg> Poizhan: well, people should mark the bugs as affecting them, that might encourage them to be fixed
[07:10] <micahg> if there are enough people affected
[07:11] <Poizhan> micahg: For example, my dual monitor setup does not behave like it does in windows with the ubuntu nvidia drivers.
[07:11] <persia> Not really.
[07:11] <Poizhan> micahg: which is really a deal breaker.
[07:11] <persia> Or at least I know very few developers who fix bugs based on how many people are affected.
[07:11] <vish> hehe!
[07:11] <Poizhan> poizhan: how does the average joe address that.
[07:11] <Poizhan> err
[07:11] <Poizhan> lol
[07:11] <micahg> persia: well, perhaps an opportunistic developer would see it
[07:11] <Poizhan> I apologize, I didn't mean to address myself.
[07:12] <persia> The key for most of these is that they aren't well understood.  If I encounter a bug that is well-understood, I tend to upload a solution because it's easier than explaining why I didn't.
[07:12] <Poizhan> It's been eons since I used irc.
[07:12] <micahg> Poizhan: try to make sure the bug gets upstream if possible
[07:12] <micahg> come in here and ask if there's anything more to do with it
[07:12] <persia> So to add value to bugs, I believe the best thing to do is to *understand* the bug.  try to replicate it.  try to find out what is wrong.
[07:12] <persia> Ask folk for help (here is a good resource, as are the upstream developers)
[07:13] <persia> Once you understand a bug well, and can communicate that understanding, it's typically trivial to get fixed, and doesn't much matter (can fix in Ubuntu, in Debian, upstream, some other distro), as everyone in the community tends to cooperate, and fixes move around.
[07:13] <Poizhan> micahg: For whom does Ubuntu exist.
[07:14] <micahg> Poizhan: for everyone and anyone
[07:14] <micahg> AFAIK
[07:14] <persia> If one isn't a developer oneself, one can often still make significant progress towards understanding, so that someone who knows a bit more about the code can reach full understanding.
[07:14] <vish> Poizhan: thats the million dollar question.. and there is no well defined "user" yet;)
[07:14] <persia> micahg, I think you want to add "who wants it" to your definition :)
[07:14] <Poizhan> micahg: Bug reporting is not easily accessible to everyone and anyone.
[07:15] <micahg> Poizhan: where are the pitfalls?  we have a command line utility to assist with submitting bugs
[07:15] <vish> Poizhan: yes, it is not easy.. but we dont seem to know how to improve it.. if you could mention the problems you've encountered , maybe we can fix them?
[07:15] <Poizhan> micahg: What about users who do not know how to use the command line?
[07:16] <micahg> Poizhan: idk, I'll bring that up at the next conference, we used to have a report a bug menu option, but that was removed starting with Lucid
[07:16] <micahg> for the stable releases
[07:16] <persia> micahg, Do you happen to know why it was removed?
[07:17] <AbhiJit> an option in system->Report a Bug!
[07:17] <AbhiJit> ??
[07:17] <micahg> persia: well, I think the idea was that more people have support issues rather than bugs in teh stable release
[07:17] <persia> I know that apport got diabled by default because there were more reports than folks to triage them, but I never understood about "Report a Bug"
[07:17] <micahg> persia: but I missed the initial discussion and only found out about it at the tail end of Lucid developement
[07:17] <persia> To a certain viewpoint, the need for support is itself a bug :)
[07:17] <vish> persia: i think seb128 mentioned something as it being too confusing.. but not sure.. seb128 knowsn
[07:17] <vish> knows*
[07:18] <persia> But, yeah, the support team is way overloaded, so even with convert-to-question, too many users end up unhappy.
[07:18] <micahg> persia: right, we have have different people doing support vs bug triage
[07:18] <Poizhan> If the only users that are bugging and wishlisting are "power-users" or devs, then bugs average joe's encounter are not addressed.
[07:18] <vish> people seem to file support questions rather than bugs using that item and it seemed to overload lp bugs , with support
[07:19] <persia> vish, Almost always, I prefer documentation to people, especially extremely busy people who's time I'd rather see spent on things other than explaining something to me that I don't have a strong need to know.
[07:19] <persia> Poizhan, I completely agree.
[07:19] <Poizhan> The Operating system evolves to meet the needs of the power users and the devs
[07:19] <Poizhan> And not the end user as a whole
[07:19] <Poizhan> Is Ubuntu being developed for the developers or the end user?
[07:19] <AbhiJit> vish, i need to submit a wishlist for -- ' i want to see the total size of the currently installed aps' -- so which pakage to submit against?
[07:20] <micahg> Poizhan: we're trying to overcome that, the keynote at the last developer summit was on bridging that gap
[07:20] <persia> Poizhan, I think we have a conflict between the folk that want to make it easy to contact someone, and the folk that coordinate responses.  If we do too much of the former before we have large enough groups working on the latter, we end up with just as much unhappiness as if we made no progress on the former.
[07:20] <persia> AbhiJit, How/where do you want to see that?
[07:20] <vish> AbhiJit: your wishlist is granted!
[07:20] <AbhiJit> persia, in ubuntu
[07:20] <AbhiJit> vish, how nice of you! :)
[07:20] <persia> AbhiJit, How?  What sort of UI?  Where?
[07:20] <Poizhan> micahg: I've noticed what you're saying, and agree, trying to have the same level of discussion in a Gentoo IRC would result in immediate ban.
[07:20] <vish> AbhiJit: in synaptic you can see the installed size of the package
[07:20] <AbhiJit> persia, in synpatic probably
[07:20] <AbhiJit> vish, really? how?
[07:21] <persia> AbhiJit, then file the bug against synaptic :)
[07:21] <Poizhan> micahg: Ubuntu is very accessible, but it needs to be a lot more, to reach the average joe.
[07:21] <AbhiJit> persia, ok
[07:21] <vish> AbhiJit: package > properties > Common tab , there you have "size"
[07:21] <Poizhan> micahg: bug reporting is just one facet. :)
[07:21] <vish> persia: its already there :)
[07:22] <AbhiJit> vish, no
[07:22] <persia> vish, No, it isn't.
[07:22] <vish> hmm!
[07:22] <AbhiJit> vish,  i mean the size of the 'all' package at once. e.g. 1gb etc
[07:22] <persia> vish, The request is for a summary report for the entire system.
[07:22] <vish> then i seem to have misunderstaood something!
[07:22] <AbhiJit> yah
[07:22] <vish> oh!
[07:22] <micahg> Poizhan: the best we can do in this channel is get the bug to the people that can fix it, we don't fix bugs in here, we triage
[07:22] <persia> AbhiJit, It's usually between 2 and 5 for most folk.
[07:22] <AbhiJit> persia, yah
[07:23] <persia> Poizhan, Do you have any specific suggestions on what could be improved?
[07:23] <micahg> Poizhan: it's up to either the upstream project or development team to actually fix the issue
[07:24] <persia> No it isn't.
[07:24] <persia> It's up to *all* of us to fix the issue.
[07:24] <vish> gah!  AbhiJit mentioned ' i want to see the total size of the currently installed aps'  i took it as for each app! while he meant for *all* apps!
[07:24] <vish> :(
[07:25] <persia> Some of us can't do it without help, which is why there's the rest of us, but if we don't take responsibility for fixing it, the chances it will be fixed are lots lower.
[07:25] <AbhiJit> vish, :P
[07:25] <AbhiJit> vish, hey you can correct your mistake by makring this bug as wishilist!!! :P :D
[07:25] <AbhiJit> https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/642567
[07:25] <ubot2> Ubuntu bug 642567 in synaptic (Ubuntu) "cant see the size of the all packages at once (affects: 1) (heat: 6)" [Undecided,New]
[07:25] <Poizhan> micahg: For example I just recently bugged an issue with changing the default alert sound with the sound preferences GUI.
[07:26] <Poizhan> micahg: There are 5 radio buttons, but if you click on the radio button the preview sound will play, but the bubble will not fill in.
[07:26] <AbhiJit> :o
[07:26] <micahg> Poizhan: bug #
[07:26] <Poizhan> micahg: I had no idea with whom to bug with.
[07:26] <Poizhan> micahg: one moment
[07:26] <vish> AbhiJit: the closest guesstimate i use is by having a separate / , that way it is somewhat easier to roughly estimate the size of the main install
[07:26] <Poizhan> micahg: 633813
[07:26] <micahg> bug 633813
[07:26] <AbhiJit> vish, no
[07:26] <ubot2> Launchpad bug 633813 in gnome-panel (Ubuntu) (and 1 other project) "unable to select different alert sounds with sound preferences (affects: 2) (heat: 12)" [Low,Confirmed] https://launchpad.net/bugs/633813
[07:26] <persia> bug #633813
[07:26] <micahg> Poizhan: thanks
[07:27] <AbhiJit> vish, that will be the size of the packages after installation.
[07:27] <vish> :(
[07:27] <AbhiJit> vish, i want the size of the package before installation both are different
[07:27] <Poizhan> micahg: I submited upstream to gnome, and the gnome devs shot me down asap... I was left wondering who to bug with.
[07:27] <rusivi> micahg: sorry for arguing with you. I'm going to slow down on the bug posting and try to see what I can do with what I have. If I have any more questions I will ask :)
[07:27] <vish> now what is it?
[07:27] <AbhiJit> vish, wait
[07:27] <vish> AbhiJit: you want the download size?
[07:27] <AbhiJit> vish, yes excatly
[07:27] <AbhiJit> but of all package at once
[07:27] <micahg> rusivi: discussion is fine, I apologize for bring the CoC into this
[07:28] <rusivi> micahg: np I realize how stressful working together on this is (I've been sleeping 2-4 hours a night!)
[07:28]  * persia retargets 633813 against gnome-media
[07:29] <micahg> persia: thanks, I wasn't sure what to do with it
[07:29] <Poizhan> micahg: Neither was I, kind of frustrating not knowing whom to bug with. :)
[07:29] <micahg> persia: is there a possibility of moving it upstream in b.g.o as well?
[07:29] <Poizhan> micahg: Many less patient people would just not bug and move on with their life.
[07:30] <rusivi> micahg: my style brings about a lot of very difficult ideas all at once, and while that works in certain areas, clearly I need to continue working together in compromising and improving my knowledge and bug process.
[07:30] <persia> It's in a control panel, so I launched the control panel.  I then used the wonderful "lsw" from suckless-tools to get a list of executables with open windows.  One looked right, so dpkg -S `which gnome-volume-properties` led me to gnome-media
[07:30] <micahg> Poizhan: you can always come in here and ask for it to be triaged if it's not looked at within a few days
[07:30] <vish> AbhiJit: hmm! download size! , why exactly?  just curious ;)
[07:30] <persia> micahg, I don't know how to manipulate GNOME b.g.o, but it would be good if someone could do that.
[07:30] <micahg> persia: I don't run GNOME :)
[07:30] <micahg> persia: I'll try to remember to poke a b.g.o bugcontrol member later
[07:30] <persia> micahg, Then not something you can triage well :)
[07:31] <vish> the easiest way i do , is ask on #bugs on gimpnet
[07:31] <Poizhan> micahg: Cool, thanks, it's good to know there is community support.
[07:31] <persia> vish, Do you have access to GNOME b.g.o?
[07:31] <AbhiJit> vish, because i need to reinstall ubuntu. and i have generated automatic installl script. but problem is my net speed. so when i wll be inside my new clean install i want to see total of how much time it is going to take so that i can leave lappy for that much time and go to other work
[07:31] <AbhiJit> i have?
[07:31] <vish> persia: nope.. :)  <vish> the easiest way i do , is ask on #bugs on gimpnet
[07:31] <micahg> Poizhan: that's where Ubuntu excels, IRC, forums, answers.launchpad.net/ubuntu
[07:31] <Poizhan> micahg: But what about people who think IRC is a government agency.
[07:31] <rusivi> micahg: I just have this vision to see all the bugs on addressed+fixed, while this is an awesome vision, it's not realistic nor the best way to go. So, back to the bugs I got!
[07:31] <persia> vish, Would you get it redirected to the right folk?
[07:31] <AbhiJit> i have account in gnome bug zilla!
[07:31] <persia> micahg, Um, no.  We're OK, but it's not true to say we excel: we leave *lots* of unhappy users.
[07:32] <vish> persia: just a sec , let me check the bug fully
[07:32] <persia> vish, Thanks.
[07:32] <micahg> persia: well, compared to other platforms
[07:32] <micahg> persia: I guess I meant it relative to Windows or Mac
[07:32] <persia> micahg, I guess.  I consider that an area of improvement, but I don't usually compare with others, so much as how I think things ought be :)
[07:33] <vish> Poizhan: are you the reporter of the bug? in upstream gnome ?
[07:33] <micahg> rusivi: we share that vision, but it's hard to do, we have people signing up to help every day and are improving our processes each cycle, maybe one day we can get there
[07:33] <Poizhan> vish: yes.
[07:33] <Poizhan> vish: I bugged with gnome-panel
[07:33] <vish> Poizhan: cool! then you can re-open and change it to gnome-media
[07:33] <micahg> persia: well, we need more people to help :)
[07:34] <Poizhan> vish: Will do.
[07:34]  * AbhiJit helps in bug and wiki!
[07:34] <vish> Poizhan: mention that you discussed the bug was identified as due to gnome-media , and re-open it
[07:34] <rusivi> Poizhan: regarding "But what about people who think IRC is a government agency." We will have to wishlist that and have a formal investigation in the inner workings of IRC :P
[07:34] <rusivi> jk
[07:35] <persia> micahg, And cleaner organisation: lots of folk can't deal with the current stuff because it's too high-volume and index-poor
[07:35] <vish> Poizhan: to remind "product" part needs changed
[07:35] <persia> Or folk get directed to regional fora, which might not contain expertise, whilst an expert is looking somewhere else, etc.
[07:35] <micahg> persia: right
[07:36] <valsum> regional 'fora', wow, seems you can speak latin language ;)
[07:36] <vish> fauna!
[07:38] <persia> No, "fora" as in places where people do things, not "flora" stuff that doesn't tend to move much and tends to have roots.
[07:39] <vish> oh! plural of forum!
[07:39] <persia> And "fora" is no more latin than "data"
[07:39]  * vish just thought it was a typo ;p
[07:40] <valsum> persia: most people just use 'forums'
[07:40] <micahg> hmm, seems we're back to 86k bugs
[07:41] <persia> valsum, Would you say "datums"?  I believe those who use "forums" are insufficiently erudite, but I won't generally fault them for it.
[07:42] <valsum> ;P
[07:42] <AbhiJit> vish, ??
[07:43] <vish> ?
[07:44] <vish> Poizhan: you can re-open the bug.. waiting for them will take longer :)
[07:45] <hungtran> Hello everyone, I would like to join Bug Squad. Do I need to know any programming language?
[07:45] <vish> Poizhan: under the comment box , change the status to "unconfirmed" , use the product dropbox and switch it to "gnome-media"
[07:45] <AbhiJit> vish, u thr?
[07:45] <micahg> hungtran: nope
[07:45] <vish> AbhiJit: you left! ;p
[07:45] <AbhiJit> vish, yah you marking that bug as wishlist naa?
[07:45] <vish> AbhiJit: yup , in a min ;)
[07:45] <AbhiJit> vish, thanks!
[07:46] <vish> AbhiJit: helping Poizhan re-open the bug now..
[07:46] <AbhiJit> vish, ok i wll wait np
[07:46] <Poizhan> vish: Ok
 Thanks :D. I'm reading wiki pages for more informations :D.
[08:16] <ebroder> Should bug #642518 be importance medium or high?
[08:16] <ubot2> Launchpad bug 642518 in fglrx-installer (Ubuntu) "package fglrx 2:8.723.1-0ubuntu4 failed to install/upgrade: fglrx kernel module failed to build (affects: 79) (dups: 76) (heat: 632)" [Undecided,Confirmed] https://launchpad.net/bugs/642518
[08:17] <persia> Probably "high" under the essential component guideline: most people like to have a working display, and some folk need that to achieve that goal.
[08:17] <micahg> +1
[08:17] <persia> !importance
[08:17] <ubot2> You can learn about setting bug importance at https://wiki.ubuntu.com/Bugs/Importance
[08:17]  * ebroder nods. That's what I was thinking, just wanted to double-check
[08:18] <persia> Right: Has a severe impact on a small portion of Ubuntu users (estimated)
[08:18] <persia> And A problem with an essential hardware component (disk controller, laptop built-in wireless, video card, keyboard, mouse)
[08:20] <ebroder> Who should I be hunting down to look at this and pass judgement on my (questionable) patch?
[08:21] <micahg> ebroder: tseliot seems to have done most of the uploads lately
[08:24] <ebroder> Ok, I'll keep an eye out for him, thanks
[08:27] <persia> You might also just ask generally in #ubuntu-x : there's a few folk there familiar with it.
[08:58] <rusivi> sorry misposted bug 94208
[08:58] <ubot2> Launchpad bug 94208 in acroread (Ubuntu) "[apport] acroread crashed with signal 5 in g_cclosure_marshal_VOID__PARAM() (heat: 4)" [Medium,Incomplete] https://launchpad.net/bugs/94208
[08:58] <rusivi> i'm virtualboxing 2 lucid VMs one had it other did not
[08:59] <rusivi> i'm about to follow up post w/ correct apt-cache policy acroread and leave it at that
[09:02] <rusivi> corrected moving on
[09:22] <persia> rusivi, Most issues with PDF readers are content-dependent: it is generally useful to find the specific content that had issues.  That said, if it's acrobat reader (from Adobe), we don't actually care much, because we can't fix it (closed source).
[09:23] <rusivi> persia: k, I should have asked the poster what PDF file they had this in... I'll do that next time!
[09:23] <micahg> also no bug tracker (at least flash has a bug tracker)
[09:24] <rusivi> micahg: they have a prop-bug tracker
[09:24] <micahg> rusivi: who?
[09:24] <rusivi> I've posted to it before
[09:24] <rusivi> adobe
[09:24] <micahg> rusivi: for?
[09:24] <rusivi> public and private
[09:25] <rusivi> sec
[09:26] <rusivi> public = https://bugs.adobe.com/jira/secure/Dashboard.jspa
[09:27] <rusivi> public forum: http://forums.adobe.com/index.jspa
[09:27] <micahg> rusivi: right, but it's basically flash
[09:28] <rusivi> sorry I was miscontexualizing
[09:30] <rusivi> private: https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform
[09:31] <persia> micahg, Ah, cool.  That's hugely useful.  Thanks.
[09:31] <micahg> indeed, they do let you upstream bugs
[09:31] <micahg> rusivi: thanks for the tip
[09:32] <persia> rusivi, Indeed: often with any sort of content processor (media players, document readers, browsers, etc.) if the bug is hard to reproduce, it may be because of changes in the content being rendered.
[09:33] <rusivi> persia: good call ty! :)
[10:33] <rusivi> micahg: ty for 2x'ing bug 623927
[10:33] <ubot2> Launchpad bug 623927 in vlc (Ubuntu) "package mozilla-plugin-vlc 1.0.6-1ubuntu1.1 failed to install/upgrade: unable to install new version of `/usr/lib/mozilla/plugins/libvlcplugin.so': No such file or directory (affects: 1) (heat: 10)" [Undecided,Incomplete] https://launchpad.net/bugs/623927
[10:46] <rusivi> Anyone know how to do a hydra-search on multi-bug trackers?
[10:47] <rusivi> I felt compelled to research this further -> bug 147203
[10:47] <ubot2> Launchpad bug 147203 in linux (Ubuntu) "WG111T not working on Hardy (dups: 2) (heat: 24)" [Undecided,Incomplete] https://launchpad.net/bugs/147203
[10:47] <rusivi> did not want to live in the stone age by cut/copy links but will if I have to!
[10:48] <rusivi> WG111T = http://kb.netgear.com/app/products/model/a_id/2559
[10:53] <rusivi> ...
[10:53] <micahg> rusivi: we'll need the output of lsusb -v, it might be included already
[10:54] <rusivi> micahg: k anything on the hydra-search?
[10:54]  * micahg isn't sure what that is
[10:54] <rusivi> macro or something to search a particular word over many different bug trackers simultaneously
[10:54] <micahg> rusivi: Google :)
[10:54] <rusivi> uh huh
[10:55] <micahg> rusivi: http://wireless.kernel.org/en/users/Devices/USB lists the devices currently supported
[10:55] <rusivi> Google is not as good as I want when I search Launchpad...
[10:55] <micahg> or supported in some form
[10:55] <rusivi> Advanced search and everything
[10:55] <rusivi> site etc
[10:55] <micahg> rusivi: keep in mind also, kernel bugs have their own rules
[10:56] <micahg> rusivi: https://wiki.ubuntu.com/Kernel/BugTriage
[10:57] <micahg> yofel: you actually updated bug 147203, you should be careful if it's a USB device to ask for lsusb -v, I'm not sure if that's in the kernel docs or not, but it should be
[10:57] <ubot2> Launchpad bug 147203 in linux (Ubuntu) "Netgear WG111T not auto-sensed (dups: 2) (heat: 24)" [Undecided,Incomplete] https://launchpad.net/bugs/147203
[10:58] <rusivi> micahg: k ty for the link!
[10:59] <rusivi> micahg: quick follow-up on hydra-search, something that directly queries the webpage the bugtracker home search is, not intermediary (google, yahoo, etc. thought they are good, I want best!)
[11:00] <persia> Better to ask for `sudo lsusb -v`: there's a number of pieces of information only available to root.
[11:01] <rusivi> persia: ty!
[11:01] <persia> rusivi, Depends on indexing: if the bugtracker doesn't have a good internal search, and an external engine has every page indexed, it can be better to go somewhere else.  hard to day, and results/preferences change over time.
[11:02] <rusivi> fair enough I'll put it on my personal wishlist hehe
[11:02] <rusivi> I could probably q&d it via KeePassX
[11:02] <rusivi> I use that very frequently
[11:03] <yofel> micahg: I wrote the response following https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies - and lsusb is missing there (though apport would probably add it), just wanted to add the minimal information required to the bug
[11:03] <rusivi> job and personal
[11:03] <micahg> yofel: in this case lsusb is minimal ;)
[11:03] <yofel> k, thanks for the info
[11:04] <rusivi> Well KeePass, we use Windows at work b/c of http://bugs.winehq.org/show_bug.cgi?id=24115
[11:04] <ubot2> bugs.winehq.org bug 24115 in tapi32 "Windows TAPI Service not located by Avaya IP Agent R6.0.28.601" [Normal,New]
[11:05] <rusivi> Companies not going to re-invent the financial wheel
[11:39] <persia> rusivi, You might look at what *other* VoIP clients are compatible with the Avaya system.  I believe it ought work with any of several solutions.
[11:41] <rusivi> persia: ty for the suggestion.

[13:12] <kklimonda> so.. cold..
[13:15] <hggdh> so... tired...
[13:21] <hggdh> for those starting to deal with bugs on bugzilla.gnome.org: ping me, give me your b.g.o account name, and I will see your work
[13:21] <hggdh> and -- perhaps -- give you rights there
[13:22] <rusivi> so... fired up!
[13:23] <hggdh> heh
[13:43] <rusivi> hggdh: got a goofy GNOME bug for ya bug 642766
[13:43] <ubot2> Launchpad bug 642766 in gnubik (Ubuntu) "GNUBik cube controls clunky (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/642766
[13:44] <rusivi> If you want I'll file upstream, just give me the word
[13:49] <vish> persia , lifeless , hggdh , micahg : to add to the UDS discussions regarding restriction [do/dont's].. how about restricting triaged -> confirmed  only to BC ? there are several bug where the user changes from triaged -> confirmed just because they did not know what "triaged" means..
[13:51] <hggdh> vish: to consider, yes. But we have to be careful on adding restrcitions
[13:51] <vish> yea.. but worth a shot ;)
[13:53] <persia> I only intended the discussion to be about documentation.  If you want to change the rules, file bugs against Malone (preferably with patches).
[13:58] <hggdh> persia: lifeless told us we will have LP devs at UDS -- we can use it to personally discuss changes in LP (based, of course, on bugs)
[14:00] <persia> Yep.  We always have LP devs at UDS.
[14:00] <persia> Frequently we can discuss blueprints as well as bugs.
[14:02] <persia> That said, the team which used to be responsible for making my preferences (in collection with a bundle of other folks) known to the LP devs has been dissolved, so I'm not really sure how we currently offer input into the prioritisation of LP blueprints.
[14:03] <hggdh> neither am I... also I would rather have a comprehensive approach to bug workflow (as opposed to a single change)
[14:04] <persia> Well, remember that we're responsible for defining policy: the LP folk only provide the tools.
[14:06] <rusivi> vish / persia: FWIW, yes restricting this would limit users from changing it = myself, but at the same time begin to exclude community members from feeling empowered to help. Personally, I am ambiguous about it but it would be strange not to be able to toggle it if someone is trying to help. :)
[14:07] <rusivi> I do like feeling empowered and that encouraged me to learn more.
[14:07] <vish> rusivi: gah! its not about you! there are several bugs where users simply change because they think confirmed means a higher status than triaged
[14:08] <vish> rusivi: you know others can fumble too! ;p
[14:09] <rusivi> vish: Not trying to be myopic and only focus myself, just providing my own experience into the discussion. Granted, it may be a certain people's inconvenience but it keeps everyone on the same playing field to have the freedom to make a mistake and learn from it versus just getting "Access Denied".
[14:09] <rusivi> That's what I like about Ubuntu, the freedom and the perception we are all equal for a large swath of scenarios.
[14:10] <rusivi> :)
[14:10] <vish> rusivi: the people who make that change are often not new triagers , they are just bug reporters who are not sure of the statuses
[14:10] <rusivi> vish: k np
[14:10] <rusivi> vish: just throwing it out there, I'm not siding either way at this point, just providing input.
[14:11] <vish> rusivi: yea.. equality is great , no one denies it.. ;)
[14:11] <rusivi> :D
[14:12] <rusivi> last thing on this, if I could not toggle the status my initial default thinking is "oh well devs got that handled"
[14:12] <rusivi> vs. wow I should keep on that
[14:13] <rusivi> boils down to inclusion v. exclusion in a seemingly minor regard
[14:13] <rusivi> but may not be as minor as one view it
[14:16] <rusivi> This type of inclusion is what makes the difference for me on what distro I use. not that if this particular opportunity vanished I would say bye to Ubuntu but it would start down a path that it could lead others down to...
[14:17] <persia> rusivi, I'm somewhat unhappy at your characterisation that vish and I are not community members.  I'm not sure from where you develop that opinion.
[14:17] <rusivi> persia: I don't think that.
[14:18] <rusivi> persia: if I ever typed that I beg your pardon.
[14:18] <persia> If you don't, then I'm not sure how making a change to restrict certain actions to folks that have previously demonstrated good content excludes "community members".
[14:18] <persia> s/content/conduct/
[14:18] <rusivi> persia: I have said what I felt, which ever way it falls so be it for me.
[14:19] <rusivi> :)
[14:19] <persia> Um, I'm just expressing that I'm a bit unhappy.  There's no direct consequence of making me unhappy, except if it's a long-term repeated thing, in which case it's limited to my opinion as expressed in various fora.
[14:20] <rusivi> persia: sorry to displease you but I feel comfortable having discourse with anyone here in a respectful manner. I have done so as well as everyone else here.
[14:20] <persia> I agree with much of your statements, I just object to the implication that anyone who has special permissions aren't community members.  I feel quite the contrary, that those who have yet to participate much are not yet members of our community.
[14:20] <rusivi> persia: i disagree
[14:20] <rusivi> respectfully.
[14:20] <persia> I encourage your discourse, or I wouldn't be debating this point with you :)
[14:20] <rusivi> ty for indulging me
[14:21] <persia> Please explain how you disagree.  How are people who have been contributing for a while not members?  Alternately, how are people who have yet to contribute members?
[14:22]  * hggdh watches
[14:22] <rusivi> I think once a member always a member, whether you contributed once or highest contributer. People who are not contributing are members via downloading the OS and using it.
[14:22] <rusivi> We want them to use it, it rocks!
[14:23] <rusivi> We as contributing community members are serving the user community, and if the user community has a problem we try to work together to solve it!
[14:24] <rusivi> and vice versa
[14:24] <persia> I guess I think it's about trust.  I want lots of folks to use Ubuntu, but I want to be able to trust that everyone with whom I'm working on Ubuntu shares certain values and goals.
[14:24] <rusivi> persia: that's what signing the CoC is about.
[14:24] <persia> And so I consider those folk who have been around and earned that trust to be part of Ubuntu, and the remainder to be users, and potential members.
[14:24] <persia> Ah, I think I understand.
[14:24] <rusivi> I signed it, and I'm trying my darnedest to follow it.
[14:25] <rusivi> persia: I know where your coming from regarding the trust factor, but that is demo'ed via the quality of contributions over time!
[14:25] <persia> I'm talking about the community of folk creating Ubuntu.  And I'm perhaps excluding the user community from my definition.  You're talking about the wider user community.
[14:25] <rusivi> yes
[14:25] <rusivi> I don't really want to draw a line in the sand
[14:25] <persia> rusivi, Absolutely, quality of contributions over time is one of the largest criteria I use in developing my opinion of whether someone is a member.
[14:25] <rusivi> there you have it.
[14:26] <persia> Makes sense.  I have to draw a line because of some of my roles, which may be why I got confused.
[14:26] <persia> Thanks for explaining yourself: I'm much less unhappy with the characterisation now.
[14:26] <kklimonda> hmm.. btw signing CoC I have a "geeky" question - will there be a gpg key signing party at the UDS? ;)
[14:26] <nigelb> kklimonda: YES
[14:26] <hggdh> we can set one up (usually informally)
[14:27] <persia> kklimonda, There is sometimes a formal one.  Lots of folk exchange keys by other means as well.
[14:27] <rusivi> persia: Frankly I never characterized anyone as non-community members.
[14:27] <persia> rusivi, Just how I read " yes restricting this would limit users from changing it ..., but at the same time begin to exclude community members"
[14:28] <rusivi> I have been making a distinction over the entire time I have started in this chat as "community member" v. "contributing community member"
[14:28] <persia> I now understand you never meant what I understood from reading that.  As I said, thanks for explaining.
[14:28] <rusivi> which is why I'm not siding either way.
[14:29] <rusivi> No change triage status, no big deal, yes change, no big deal!
[14:29] <hggdh> the problem is that at some point we need to limit access
[14:30] <rusivi> hggdh: agreed on security grounds
[14:30] <persia> I think it's folk like hggdh and vish who are subscribed to thousands of bugs and trying to move them all to Triaged who are most affected, as they have to go switch them back if someone makes a mistake (usually because they are still learning), so the decision is best theirs, as long as it doesn't break stuff for other folk.
[14:31] <hggdh> well, not only on security, but also on quality *and* consistency of work
[14:31] <rusivi> I think giving those like vish / hggdh the option to freeze a post if it gets egregious
[14:31] <popey> Could someone tell me if bug 642792 is filed in the right place? I wasnt quite sure where to put it.
[14:31] <ubot2> Launchpad bug 642792 in xkeyboard-config (Ubuntu) "ALT+PrtSc not recognised (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/642792
[14:32] <rusivi> but freezing a post won't stop PM entering into your Launchpad E-Mail acct
[14:32] <rusivi> if it affects a lot of members strongly
[14:32] <vish> popey: it would be a gnome-settings-daemon bug, afaik... hggdh second opinion ? :)
[14:32] <rusivi> the community speaks loud and clear when something affects them!
[14:32] <persia> It's not xkeyboard-config
[14:32] <persia> That's about DE shortcuts
[14:32] <vish> or persia too..
[14:32] <persia> Oh, maybe not.
[14:33] <hggdh> if this could be tested outside Gnome... but sounds sane right now, popey.
[14:33] <persia> popey, So the screenshot issue is about shortcuts, but the xev issue is either xkeyboard-config *OR* the kernel.  The GNOME bug is probably only a symptom of the deeper bug.
[14:33] <persia> popey, You can distinguish issues with xkeyboard-config from kernel issues with the input-utils utilities.
[14:34] <hggdh> heh. Nothing better than sitting down and listening to persia
[14:34] <vish> ;p
[14:34] <persia> Well, only about HID stuff, audio, porting, and policy :)
[14:35] <popey> could it be a recurrance of bug /~198748
[14:35] <popey> bah
[14:35] <popey> could it be a recurrance of bug 198748
[14:35] <ubot2> Launchpad bug 198748 in gnome-control-center (Ubuntu) "sysrq and screenshot use the same keyboard shortcut (affects: 6) (dups: 1) (heat: 10)" [Low,Invalid] https://launchpad.net/bugs/198748
[14:36] <hggdh> popey: I wonder is this is just the tip. I found a few days ago that Ctrl/Alt/Fx works to bring me to the terminal, but not to get me back to Gnome
[14:36] <persia> popey, Possibly, although I don't think 198748 ever really got triaged.
[14:36] <hggdh> but did not have time to pursue
[14:36] <popey> I have had multiple people confirm this bug on other machines
[14:36] <popey> all running maverick
[14:37] <vish> hmm , i had the same bug actually!
[14:37] <hggdh> FWIW, just confirmed it on gnome here
[14:38] <persia> Next step, install input-utils.
[14:38] <persia> And check the responses there.
[14:38] <persia> I strongly recommend playing with input-utils in a console if you're doing anything interesting, as I've gotten some odd results (including full DE crash) performing some operations inside X.
[14:39] <popey> hmm, it does seem to be a sysrq issue
[14:39] <popey> in a terminal if I do ALT+PrtSc+h I get the sysrq help
[14:39] <persia> The keycode is being trapped by the kernel?
[14:39] <popey> yeah
[14:40] <persia> Excellent.
[14:40] <persia> So reassign the bug to the kernel.
[14:40] <popey> kernel bug? :)
[14:40] <persia> yep.
[14:40] <popey> thanks!
[14:40] <persia> If kernel wonftfixes it, then it needs a g-s-d bug to change the default screenshot shortcut
[14:43] <popey> one last thing, the kernel bugs just go to the "linux" package these days dont they?
[14:45] <persia> popey, Yes.
[14:45] <popey> thanks
[14:45] <popey> sorry for interrupting your interesting discussion, carry on :D
[14:47] <BUGabundo> hurm
[14:47] <BUGabundo> I get a screenshot :S
[14:47] <BUGabundo> ALT+Fn+PrtSc+h
[14:47] <BUGabundo> maverick
[14:52] <persia> Yes, but it's at least racy
[15:01] <rusivi> "You are not the bug assignee nor the maintainer of gltron (Ubuntu), and therefore cannot edit this bug's status." I just confirmed this in Lucid. Granted I can understand to an extent why this occurred, but I am contributing...
[15:02] <rusivi> bug 110989
[15:02] <ubot2> Launchpad bug 110989 in gltron (Ubuntu) "[apport] gltron crashed with SIGSEGV in SDL_GL_SwapBuffers() (affects: 2) (heat: 11)" [Medium,Incomplete] https://launchpad.net/bugs/110989
[15:02]  * persia looks
[15:03] <persia> rusivi, Firstly, I'd suggest trying to replicate in maverick (as you asked the reporter to do last week)
[15:04] <rusivi> I wanted to give them that opportunity after I posted for Lucid and prior versions...
[15:05] <persia> Most reporters are nervous about upgrading (as they ought be).  You and I, working on Ubuntu, are more likely to be comforable installing a newer release to test something.
[15:05] <rusivi> I have maverick natively installed on my laptop...
[15:05] <persia> But there7s no point.  it will occur: it's not been fixed in the changelogs, and there's no new upstream version.
[15:06] <persia> It's uncareful coding, and needs a code patch: upstream would probably appreciate replication with current upstream and a bug report there.
[15:06] <persia> I figured you'd have a maverick install handy :)
[15:06] <rusivi> I respect the fact that it is a developer "annoyance" but I am contributing in the way I know how
[15:07] <persia> Hrm?  What's a developer annoyance?
[15:07] <rusivi> arguably myself :P
[15:07] <persia> Let's assume you aren't (or at least don't intend to be if you are), and focus on how to get the bugs fixed :)
[15:08] <rusivi> progress get's us towards that
[15:08] <persia> So, the reporter reported the bug with feisty.
[15:08] <rusivi> my contribution, however inane it seems, is so
[15:08] <persia> You've validated it in lucid, and we can check rmadison to see the same upstream version in maverick,.
[15:09] <rusivi> If my account is banned just come out and say it don't beat around the bush.
[15:09] <rusivi> It's just spitting in face about how you understood what I said earlier and this happens.
[15:09] <persia> Looking at the changelog on the maverick package (I usually use `aptitude changelog ${PACKAGE}`), we can see there is no fix that happened.
[15:10] <rusivi> You didn't  understand imho
[15:10] <persia> I don't have any knowledge of whether your account is banned.  I doubt it is, and suspect you've encountered yet another odd confusing launchpad permissions thing.
[15:10] <rusivi> uh huh
[15:10] <persia> I'm only trying to help you track down the bug.
[15:11] <persia> Do you wish me to continue?
[15:12] <rusivi> I frankly don't think you guys understood/understand what Ubuntu, the CoC is about, nor this community. I'm going to Fedora. Maybe in the future you guys will understand what I said but that will remain to be seen.
[15:12]  * persia is confused, and decides to go to bed
[15:13] <coafcv> Can someone help me find a bug? I'm using an ATI card (HD 4850) and with the restricted drivers maximizing windows takes more than a second (!).
[15:15] <BUGabundo> o_O
[15:15] <BUGabundo> what was that?
[15:15] <BUGabundo> did he somehow blow his steam out !?
[15:16] <BUGabundo> coafcv: try #ubuntu-x
[15:16] <BUGabundo> but don't expect much of them on a weekend
[15:21] <coafcv> BUGabundo: lol ok
[15:23] <BUGabundo> not joking... they are ppl too.. they don't spend their life on IRC
[15:23] <BUGabundo> just be calm, try to be informative, and eventually you will get there
[15:24] <bcurtiswx> so, whats the new way to forward bugs upstream?
[15:25] <hggdh> we, what happened?
[15:27] <hggdh> oh, OK. S/he just showed a real lack of reading & understanding the wikis.
[15:29] <BUGabundo> yes
[15:32] <hggdh> BUGabundo: read the logs, you will understand
[15:34] <bcurtiswx> hggdh, a bug report?
[15:35] <hggdh> bcurtiswx: what, how to forward?
[15:35] <bcurtiswx> no i am just wondering where all this started... lol.. came in late
[15:36] <hggdh> bcurtiswx: rusivi, in one week, commented on about 2k bugs; unfortunately, a lot of the actions were not looked at nicely by the affected people
[15:36] <vish> bcurtiswx: well , you came in 2day late ;p
[15:36] <vish> days*
[15:37] <hggdh> bcurtiswx: lack of reading the HowToTriage/Knowledge pages, unwillingness to reason
[15:37] <vish> bcurtiswx: people have been trying patiently to explain to him/her , but he seems to think that *we* are being rude ;)
[15:37] <vish>  he/she
[15:37] <hggdh> her/his parting rant has more to do with lack of understanding than with reality
[15:38] <hggdh> oh, there are a lot of rude comments about her/his actions
[15:38] <hggdh> and maintainers coming in here to say "stop with it"
[15:38] <bcurtiswx> ah, i .c.
[15:39] <hggdh> but most such comments were on the bugs, or off-band. *We* did not get rude, at all
[15:39] <vish> hggdh: well on the bugs maybe, but not here.. or atleast i dint notice them on the channel ;)
[15:39] <bcurtiswx> got some example bugs?
[15:39] <hggdh> heh. Just a sec
 <tock>
[15:40] <hggdh> bcurtiswx: https://bugs.edge.launchpad.net/~rusivi1/+commentedbugs enjoy
[15:43] <vish> hggdh: "I use Fedora you should too." ;)  https://launchpad.net/~rusivi1
 To top, vindictive
[15:46] <hggdh> selecting a distro is a personal decision. Unfortunately, s/he is bound to get the same results there if still not willing to learn/listen
[15:48] <vish> i think he must have *accidentally* tried to "assign" someone to the bug.. thats when the warning might have occurred..
[15:49] <vish> which might have mislead to believe that the account was being blocked ;)
[15:49] <vish> again.. it might just be a misunderstanding and not trying to listen what people are trying to say..
[15:50] <vish> anyhoo.....
[15:52] <hggdh> water past the bridge
[15:52] <coafcv> I'm wary of people who don't use punctuation in 6 word sentence like rusivil1 on his launchpad site it's scary besides it makes you look like an idiot
[15:53] <hggdh> coafcv: s/he is, right now, angry
[15:53] <hggdh> coafcv: BTW -- run 'ssh -vvv <IP> -l username', and see what key is being selected
[15:53] <hggdh> I suspect you named your key after the username
[15:56] <bcurtiswx> holy incomplete bugs batman
[15:57] <bcurtiswx> what is rusivi doing with bugs thats annoying?  there's a thousand.. i can only look at so much
[15:58] <vish> bcurtiswx: the most common complain was setting confirmed/triaged -> incomplete , because he/she asks to test with latest release
[15:59] <vish> bcurtiswx: but unfortunately most of the bugs touched were kinda known issues ;p
[15:59] <jbicha> some of these bugs are from 4-5 years ago
[16:00] <vish> hence the maintainer's "stop now! we know it isnt fixed yet"
[16:00] <bcurtiswx> vish, ah.  so they weren't realizing that the bugs were known and not fixed yet still requested the latest release review
[16:01] <vish> should have instead started with "new" untouched bugs for those type of questions..
[16:01] <hggdh> among asking for tests on bugs where the Ubuntu task was closed wontfix
[16:02] <hggdh> s/he did not even *read* the comments to understand what it was about
[16:03] <coafcv> hggdh: I just did. nowhere does it mention the right file. it just mentions that it found the host in known_hosts, and is using id_rsa as the identity file, but this file does not exist! however, I noticed that moving the correct key files out of the folder makes ssh ask for a password. so I suspect it tries all key files until one works.
[16:03] <hggdh> coafcv: this is... weird.
[16:04] <hggdh> coafcv: what UBuntu version are you in?
[16:04] <coafcv> hggdh: 10.04.1
[16:05] <hggdh> coafcv: please open a bug on openssh, explain what is going on, provide a 'ls -la ~/.ssh', and the output of running 'ssh -vvv'
[16:05] <hggdh> coafcv: I will be auto-notified when the bug is open...
[16:05] <hggdh> coafcv: best way to open the bug: ubuntu-bug openssh
[16:11] <coafcv> okay, hold on please.
[16:12] <drecute> hello
[16:12] <drecute> i'm installing ubuntu via a usb stick
[16:12] <drecute> after the first screen, i get this: ubuntu unable to find a medium containing a live file system
[16:17] <coafcv> hggdh: it says that openssh is not found, but openssh-client works.
[16:18] <hggdh> duh. My error, coafcv
[16:27] <coafcv> … I had referrer headers disabled, now I have to retype the whole bug report.
[16:31] <coafcv> hggdh: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/642866
[16:31] <ubot2> Ubuntu bug 642866 in openssh (Ubuntu) "openssh client logs into server without specifying the correct key file. (affects: 1) (heat: 6)" [Undecided,New]
[16:38] <hggdh> coafcv: when you ran it what username did you use (my -l username was not to be taken literally)
[16:43] <coafcv> hggdh: heh, I know, but username is the actual username I used (it's a test server, anyway).
[16:44] <coafcv> hggdh: I mean, username is the correct username on the test server.
[16:50] <hggdh> coafcv: thaks :-)
[16:52] <coafcv> hggdh: np :) what will happen next?
[16:54] <hggdh> coafcv: we will try to figure out what is going on (if this is expected behaviour -- which I do not think) or if indeed ssh reads all files in ~/.ssh and looks for a corresponding key
[16:55] <hggdh> but I still think this is weird
[16:55] <coafcv> okay, I'll check the bug report from time to time.
[19:45] <hggdh> coafcv: still there? Got a Q for you
[20:14] <coafcv> hggdh: go ahead.
[20:26] <hggdh> coafcv: just updated the bug with two things I would like you to try
[22:18] <RoyK> hi all. seems https://bugs.launchpad.net/ubuntu/+source/denyhosts/+bug/564476 is fixed with a one-character fix - any chance to get that fixed upstream?
[22:18] <ubot2> Ubuntu bug 564476 in denyhosts (Ubuntu) "OverflowError, "long int exceeds XML-RPC limits" (affects: 9) (heat: 63)" [Undecided,New]
[22:25] <steelrat> hello?
[22:31] <stlsaint> sup
[22:33] <steelrat> can someone, pls, teach me to triage a bugs? :)
[22:35] <hggdh> steelrat: please start by reading http://wiki.ubuntu.com/HelpingWithBugs