x11-libs/libXfont-1.1.0-r1: vulnerable via glsa(200609-04) ( ver-rev < 1.2.0-r1 ), affects ('alpha', 'amd64', 'arm', 'hppa', 'ia64', 'm68k', 'mips', 'ppc', 'ppc64', 's390', 'sh', 'sparc', 'x86', 'x86-fbsd') x11-libs/libXfont-1.1.0-r1: vulnerable via glsa(200609-07) ( ver < 1.2.1 ), affects ('alpha', 'amd64', 'arm', 'hppa', 'ia64', 'm68k', 'mips', 'ppc', 'ppc64', 's390', 'sh', 'sparc', 'x86', 'x86-fbsd') x11-libs/libXfont-1.2.0: vulnerable via glsa(200609-04) ( ver-rev < 1.2.0-r1 ), affects ('alpha', 'amd64', 'arm', 'hppa', 'ia64', 'm68k', 'mips', 'ppc', 'ppc64', 's390', 'sh', 'sparc', 'x86', 'x86-fbsd') x11-libs/libXfont-1.2.0: vulnerable via glsa(200609-07) ( ver < 1.2.1 ), affects ('alpha', 'amd64', 'arm', 'hppa', 'ia64', 'm68k', 'mips', 'ppc', 'ppc64', 's390', 'sh', 'sparc', 'x86', 'x86-fbsd') x11-libs/libXfont-1.2.0-r1: vulnerable via glsa(200609-07) ( ver < 1.2.1 ), affects ('alpha', 'amd64', 'arm', 'hppa', 'ia64', 'm68k', 'mips', 'ppc', 'ppc64', 's390', 'sh', 'sparc', 'x86', 'x86-fbsd') x11-libs/libXfont-1.2.0-r2: vulnerable via glsa(200609-07) ( ver < 1.2.1 ), affects ('alpha', 'amd64', 'arm', 'hppa', 'ia64', 'm68k', 'mips', 'ppc', 'ppc64', 's390', 'sh', 'sparc', 'x86', 'x86-fbsd') @mips - this is pretty serious A1 vulnerability, you really should stabilize a fixed version soon (see Bug 145513). Please, clean up the above. Thanks. :0
Time to have a look... (diediediejakub!!11)
Could you please give us the output in a less nasty format in future?
(In reply to comment #2) > Could you please give us the output in a less nasty format in future? No, sorry. There's nothing wrong with the format.
(In reply to comment #3) > (In reply to comment #2) > > Could you please give us the output in a less nasty format in future? > > No, sorry. There's nothing wrong with the format. Yes there is. It's a pain in the ass to read and contains all sorts of information that isn't relevant to the bug. Here's what you should be saying: > Please stable >=x11-libs/libXfont-whatever for GLSA 200609-04 and GLSA 200609-07. It's much easier for everyone than some meaningless pile of data that has nothing to do with the bug at hand.
(In reply to comment #4) > Yes there is. It's a pain in the ass to read and contains all sorts of > information that isn't relevant to the bug. Here's what you should be saying: Last time I checked you've been retired. Would you just STFU here, noone CCed you here and noone asked you to do any job here... Ktnxbye, stop poluting this bug with your off-topic rants or go write a better check for paludis, meanwhile see the suggestion above.
Stable on MIPS.
Done, thanks.
Adding devrel to the Cc:, they might want to comment on comment #5... And FYI Jakub, *you* Cc:ed me on this bug when you originally filed it.
(In reply to comment #8) > Adding devrel to the Cc:, Feel free... > Jakub, *you* Cc:ed me on this bug when you originally filed it. No, I certainly haven't, so you might want to stop this nonsense already... http://bugs.gentoo.org/show_activity.cgi?id=164196
(In reply to comment #9) > > Jakub, *you* Cc:ed me on this bug when you originally filed it. > > No, I certainly haven't, so you might want to stop this nonsense already... You might want to have a look at the mips@ alias sometime. Preferably before you dig yourself into an even deeper hole...
(In reply to comment #10) > You might want to have a look at the mips@ alias sometime. Preferably before > you dig yourself into an even deeper hole... You might want get yourself removed from the alias finally if you can't stop polluting bugzilla with your off-topic whining. Not my fault noone has fixed that yet. Reopen to take this bug away from innocent x11 folks.
FIXED.
(In reply to comment #11) > You might want get yourself removed from the alias finally if you can't stop > polluting bugzilla with your off-topic whining. Not my fault noone has fixed > that yet. Asking you to provide more helpful bug reports so that the horribly understaffed mips team can fix them in less time is not off-topic whining. And, uh, I was intentionally *re*added to the mips alias because they value my input.
Dear userrel; I've had enough of this bugspam. It's completely off-topic, the original bug has been fixed, the only person moaning about the quality of this bug is no longer a developer and as such this bug is irrelevant to him. I have no intention to keep deleting unsolicited ciaranm's trolling from my mailbox. Deal with this or ban his account if you can't find another solution. Dear Joshua, I hereby request to get ciaranm removed from mips@ alias to prevent such unfortunate events in future. Thanks for understanding.
(In reply to comment #14) > It's completely off-topic It's entirely relevant, given how this is not the first bug you've filed in this format. Is it really so difficult to file more useful bugs? You're already automating the process to a certain extent... A simple "Thanks for the advice, I'll do this in future" is all it takes.
(In reply to comment #14) > Dear userrel; I've had enough of this bugspam. It's completely off-topic, the > original bug has been fixed, the only person moaning about the quality of this > bug is no longer a developer and as such this bug is irrelevant to him. I have > no intention to keep deleting unsolicited ciaranm's trolling from my mailbox. > Deal with this or ban his account if you can't find another solution. It is not offtopic, and I for one agree with him. > Dear Joshua, I hereby request to get ciaranm removed from mips@ alias to > prevent such unfortunate events in future. Absolutely not, as he said, we value his input. > Thanks for understanding. Whether userrel "understands" or not is irrelevant. See above comment. In other words, jakub can piss off here. "Ktnxbye"
(In reply to comment #15) > It's entirely relevant, given how this is not the first bug you've filed in > this format. Yes, and it's the *only* bug in this format that has been overtaken by a troll moaning about the quality of the report without being affected by the bug in any way, apparently just because you like to troll and waste time of lots of other people.
(In reply to comment #17) > (In reply to comment #15) > > It's entirely relevant, given how this is not the first bug you've filed in > > this format. > > Yes, and it's the *only* bug in this format that has been overtaken by a troll > moaning about the quality of the report without being affected by the bug in > any way, apparently just because you like to troll and waste time of lots of > other people. If you only give unuseful bug reports a few times, it's not really a problem. But when it gets to be something that happens regularly, it's worth asking the person to change their ways. A simple "thanks for the advice, I'll do that next time" is all it takes...
@jakub,ciaran: why do things have to escalate this way? It seems to me that comment #2 was mostly a polite request, but both of you are jumping on the occasion to give each other names and act as if you were perfectly right, without *ever* taking the time to cool off and explain clearly what your issues are. Unless you are ready to sit down and listen to each other, I don't see the point in CCing userrel.
(In reply to comment #16) > In other words, jakub can piss off here. "Ktnxbye" Are you going to *do* anything about the QA issues mips has, or just whine about the report? (My humble apologies to eroyf that got involved in this and thanks for being actually helpful; sadly that is pretty rare exception for the rest of our MIPS team).
(In reply to comment #20) > (In reply to comment #16) > > In other words, jakub can piss off here. "Ktnxbye" > > Are you going to *do* anything about the QA issues mips has, or just whine > about the report? As I said, if you provide more useful bug reports, things will get fixed quicker. Is it really so hard to make your tool produce better output?
(In reply to comment #19) > Unless you are ready to sit down and listen to each other, I don't see the > point in CCing userrel. The point of CCing userrel is that I'm already pretty busy and don't wish to waste time on another instance of ciaranm's trollfest. If Gentoo can't finally deal with this guy once and forever, you'll apparently keep losing more developers. (If MIPS team values ciaranm's input, they are free to receive such input *outside* of my mailbox.)
(In reply to comment #21) > As I said, if you provide more useful bug reports, things will get fixed > quicker. Is it really so hard to make your tool produce better output? As said, you are free to *code* such better tool; until then this is the only tool we have, so stop whining here and go do some work...
@jakub: then just ignore the guy, if he is such a pain to you. You must certainly know that trying to confront him will bring no good for anyone and will only increase the said bugspam.
(In reply to comment #22) > (In reply to comment #19) > > Unless you are ready to sit down and listen to each other, I don't see the > > point in CCing userrel. > > The point of CCing userrel is that I'm already pretty busy and don't wish to > waste time on another instance of ciaranm's trollfest. How is asking you politely to file better bug reports a trollfest? (In reply to comment #23) > As said, you are free to *code* such better tool; until then this is the only > tool we have, so stop whining here and go do some work... Strange, other developers manage... Have a look at, for example, bug 164176 for a useful format.
(In reply to comment #20) > (In reply to comment #16) > > In other words, jakub can piss off here. "Ktnxbye" > > Are you going to *do* anything about the QA issues mips has, or just whine > about the report? Actually, I'm going to retire very soon, as I simply don't have enough time for Gentoo any longer, and I haven't for many months now. > (My humble apologies to eroyf that got involved in this and thanks for being > actually helpful; sadly that is pretty rare exception for the rest of our MIPS > team). Now that we're ignorantly bashing people, my humble apologies to everyone else reading this bug for having to listen to jakub's crap; sadly that is all too common on any given bug report where jakub doesn't agree with someone. "Ktnxbye"
(In reply to comment #25) > Strange, other developers manage... Have a look at, for example, bug 164176 for > a useful format. ciaranm; if you can't read the output, then ask for explanation. For the rest of the world, it's pretty much clear that the first field is the vulnerable version, the second are relevant GLSAs, the third are the versions affected by that GLSA, and the last one are affected arches. That's pretty damn far from "meaningless pile of data" as you've "politely" marked this bug report in Comment #4. As you might have noticed, the assignee of this bug had no problems with that. That's all here from me; enough time wasted.
(In reply to comment #27) > (In reply to comment #25) > > Strange, other developers manage... Have a look at, for example, bug 164176 for > > a useful format. > > ciaranm; if you can't read the output, then ask for explanation. For the rest > of the world, it's pretty much clear that the first field is the vulnerable > version, the second are relevant GLSAs, the third are the versions affected by > that GLSA, and the last one are affected arches. That's pretty damn far from > "meaningless pile of data" as you've "politely" marked this bug report in > Comment #4. As you might have noticed, the assignee of this bug had no problems > with that. Yes, it tells you the archs affected by the GLSA (not relevant for the bug) and affected versions (again, not relevant) but nowhere does it tell the arch teams what to keyword or what the consequences of keywording would be. Providing that information would be extremely useful for arch teams, who are as you already know understaffed and overworked.
(In reply to comment #28) > affected versions (again, not relevant) but nowhere does it tell the arch teams > what to keyword or what the consequences of keywording would be. Riiight; affected versions are completely irrelevant for a bug asking to *punt* the *affected* versions. Oh wow... please stop wasting our time already.
(In reply to comment #29) > (In reply to comment #28) > > affected versions (again, not relevant) but nowhere does it tell the arch teams > > what to keyword or what the consequences of keywording would be. > > Riiight; affected versions are completely irrelevant for a bug asking to *punt* > the *affected* versions. Oh wow... please stop wasting our time already. Correct. Think about this for a moment. All that matters for arch teams is that appropriate unaffected versions are keyworded. As someone who's actually done arch keywording, I can tell you that the things an arch person wants from the bug is: * What do I need to keyword? * What other packages will also need keywording as a result? And, for completeness: * How do I test the package I am keywording? What the arch person does not want: * A list of all archs that are affected by a GLSA * A list of vulnerable versions And, as I've told you repeatedly, since you're automating things anyway it would be of much help if you could change the format of your bug reports to include the information arch teams need.
(In reply to comment #30) > Correct. Think about this for a moment. All that matters for arch teams is that > appropriate unaffected versions are keyworded. As someone who's actually done > arch keywording OMG this is NOT a keywording bug; this is a bug asking to remove vulnerable crap from the tree. All the relevant info is already included on related security bugs and it's not my damned fault that MIPS couldn't catch up with them before. I won't be doing other people's homework. The only reason why MIPS got CCed here is that their missing keyword was preventing the removal of that vulnerable cruft. Fixed, punted, why are you damn still whining here?!
(In reply to comment #31) > (In reply to comment #30) > > Correct. Think about this for a moment. All that matters for arch teams is that > > appropriate unaffected versions are keyworded. As someone who's actually done > > arch keywording > > OMG this is NOT a keywording bug; this is a bug asking to remove vulnerable > crap from the tree. Which cannot, by policy, be done until mips has caught up. So yes, this bug is a keyword request for mips, which is why you included mips in the Cc: list. > I won't be doing other people's homework. Providing decent bug reports is not other people's homework. It's your duty. If you wonder why mips tends to lag behind, perhaps you should consider that a lot of it is down to other people mistakenly removing ebuilds before they should. You can't both claim that mips breaks stuff and go around getting people to do tidyups that will lead to mips breakages.
(In reply to comment #32) > Providing decent bug reports is not other people's homework. It's your duty. Oh, maybe you forgot to sent me my cheque; haven't noticed I'm your employee yet... :P So, all the relevant info is on related security bugs, with MIPS CCed there. I have better things to do with my spare time than duplicating such info here just because some arch is lagging behind over and over again, mainly because majority of the arch devs either focuses on attacking other people or is being MIA instead of doing something. How exactly did you help here with anything? And how exactly does this bug help to get new people recruited for MIPS team? How does your attacking of other devs on the other recent bug help? Don't you have anything better to do? Then at least damn stop polluting the air here.
(In reply to comment #33) > (In reply to comment #32) > > Providing decent bug reports is not other people's homework. It's your duty. > > Oh, maybe you forgot to sent me my cheque; haven't noticed I'm your employee > yet... :P So, all the relevant info is on related security bugs, with MIPS CCed > there. That you are a volunteer does not excuse your behaviour. > I have better things to do with my spare time than duplicating such info here > just because some arch is lagging behind over and over again, mainly because > majority of the arch devs either focuses on attacking other people or is being > MIA instead of doing something. > > How exactly did you help here with anything? And how exactly does this bug help > to get new people recruited for MIPS team? How does your attacking of other > devs on the other recent bug help? Don't you have anything better to do? Then > at least damn stop polluting the air here. If it gets you to submit better bug reports in future, it will help a lot. As I've already told you, arch teams are understaffed and can use all the help they can get. Making your automated tool produce more helpful output will be a very big help. It may not seem like it to you, but you're not the one that has to do the keywording -- so, why not spend a few minutes improving the tool so that you can spare a lot more time for the arch teams? And remember, part of the reason the mips team lags a lot is because a) bug reports are nowhere near as useful as they could be, and b) because people keep on nuking latest stable versions.
Please readd us to CC if you have a specific request.
> And remember, part of the reason the mips team lags a lot is because a) bug > reports are nowhere near as useful as they could be, and b) because people keep > on nuking latest stable versions. This is exactly right, and in particular, b) is spot on. Jakub, you are wrong, so I suggest you stop arguing your position. "Ktnxbye"
(In reply to comment #34) > That you are a volunteer does not excuse your behaviour. Oh, pardon me that I dared to file a bug about vulnerable crap lingering in the tree. > If it gets you to submit better bug reports in future, it will help a lot. > And remember, part of the reason the mips team lags a lot is because a) bug > reports are nowhere near as useful as they could be, and b) because people keep > on nuking latest stable versions. I have no intent to file any bugs whatsoever concerning MIPS in future. I'll happily let some other idiot enjoy the appraisal that these bugs get from you, geoman and likes and certainly will refrain from CCing MIPS anywhere on such bugs so that I would not hurt your aesthetic sense for the format of output in these bugs reports. Go find another babysitter who will be willing to explain to you that you are still missing the keyword that everyone else already has, over and over again. Good luck with this. And don't forget to blame people reporting bugs about overdue stuff for the lag. Spot on! :P
(In reply to comment #37) > (In reply to comment #34) > > That you are a volunteer does not excuse your behaviour. > > Oh, pardon me that I dared to file a bug about vulnerable crap lingering in the > tree. That isn't the issue with your behaviour and you know it. > I have no intent to file any bugs whatsoever concerning MIPS in future. I'll > happily let some other idiot enjoy the appraisal that these bugs get from you, > geoman and likes and certainly will refrain from CCing MIPS anywhere on such > bugs so that I would not hurt your aesthetic sense for the format of output in > these bugs reports. This is not about aesthetics. This is about providing the information needed by the people who will be fixing the bug reports. Why is your response to a polite request to add that information so, well... dickish? > Go find another babysitter who will be willing to explain to you that you are > still missing the keyword that everyone else already has, over and over again. > Good luck with this. And don't forget to blame people reporting bugs about > overdue stuff for the lag. Spot on! :P No-one is blaming you for filing keyword bugs. We are merely asking that you change how you format them so that they are more useful to those who have to do the fixing. Again, I'd like devrel to comment upon whether they consider Jakub's behaviour here acceptable.
(In reply to comment #38) > This is not about aesthetics. This is about providing the information needed by > the people who will be fixing the bug reports. All that information is provided in Comment #0 and in the security bug referred to there... And, finally a $10M question: guess which keyword is missing? Keywords for x11-libs/libXfont: | a a a h i m m p p p s s s s x x | l m r p a 6 i p p p 3 h p p 8 8 | p d m p 6 8 p c c c 9 a a 6 6 | h 6 a 4 k s 6 - 0 r r - | a 4 4 m c c f | a - b | c f s | o b d | s s | d ------+-------------------------------- ( vulnerable cruft snipped ) 1.2.2 | + + + + + + ~ + + + + + + ~ 1.2.6 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 1.2.7 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Who wants to become a millionaire? :P
(In reply to comment #39) > (In reply to comment #38) > > This is not about aesthetics. This is about providing the information needed by > > the people who will be fixing the bug reports. > > All that information is provided in Comment #0 and in the security bug referred > to there... No, you're providing the means to find the information after extra work. We're asking you to provide the information straight away, as per, say, bug 164176. Given that you're already automating this, would it really be so difficult?
(In reply to comment #40) > No, you're providing the means to find the information after extra work. Oh, no winner here. Anyone else to crack the hard question about missing keyword? (Sorry, this is becoming really retarded, if you are unable to do elementary research, then please don't mess with keywords and find someone more competent. There's still hope, as at least eroyf was able to get it right.)
Jakub, please spare us the rhetorics. The information can certainly be presented better which is all that is asked. Presenting it in a better format allows arch devs to work faster and will probably help avoid keywording wrong stuff as well. Now, I'm aware that you haven't made the script yourself but maybe you could ask the pkgcore people if they could improve the output. The pkgcore developers seems to be fairly amenable regarding changing output and checks so I guess this could easily be solved to everybodys benefit.
(In reply to comment #42) > ask the pkgcore people if they could improve the output. The pkgcore developers > seems to be fairly amenable regarding changing output and checks so I guess > this could easily be solved to everybodys benefit. Yeah, I certainly could... Leaving the fact that I have absolutely no interest to actually do so after what I've seen on this bug, maybe you could explain how exactly it should be improved. Because that output is aimed at providing information about vulnerable stuff, *not* at providing information about what should be keyworded. That output is posted here for the *maintainer* of the ebuild and provides info on what is vulnerable and should be punted. It's *not* intended for the arch people to let them know what should be keyworded. If people can't figure out that they need to stabilize the same version as everyone else already did before them even after linking to the relevant security bug, sorry but not my problem really. I don't have time to be painting fancy tables with keywords, they can use eshowkw, adjutrix or whatever other tool for that.
(In reply to comment #43) > (In reply to comment #42) > Because that output is aimed at providing information about vulnerable stuff, > *not* at providing information about what should be keyworded. That output is > posted here for the *maintainer* of the ebuild and provides info on what is > vulnerable and should be punted. It's *not* intended for the arch people to let > them know what should be keyworded. > Why on earth are you cc'ing or assigning bugs to arch teams if the intention isn't to let them know what should be done? Arch teams (especially understaffed ones like mips) don't have time for riddles. Just file the bug to the maintainer in that case and let him/her deal with arch teams.
Jakub: you're driving this up to the great pink skies, please stop being so annoying... I doubt you'll change this format even though Bryan now has asked you to do so too just because of that fact that it was Ciaran who wanted you to do it. I even had to ask you yesterday about which package you wanted us to test... Read the output (on bugzilla) and please admit that the output is very unreadable. Now you've seen that people doesn't like the output -- please don't use it in the future.
My two pence: the output from (I assume) pkgcore in comment #0 is confusing, at best; it took me at least three scans just to grok that version/revision bumps of x11-libs/libXfont 1.1.x and 1.2.x were required to satisfy GLSAs 200609-04 and 200609-07; and the way it is formatted (in both e-mail and on the web) isn't at all easy on the eye. In other words, I'd like to echo what Ciaran, Bryan, Alex and others have already said in this bug: could the format used in these kind of bugs be adapted slightly, please? What might look fine on a wide-screen terminal, to someone who is perhaps familiar with the tools being used, certainly isn't for the general developer audience of this here Bugzilla. At least, that's my opinion, and is certainly the impression I've gotten from quite a few other developers.
(In reply to comment #44) Good that you neglected to post suggestion whatsoever on *how* the output should be improved; pretty much significant for all the whining folks here. Just whining, nothing done. --- Finally - you know what, folks... Do something, or stop moaning. Noone cared to punt the vulnerable junk so far, noone did the keywording here until this bug was filed, noone did even file a better bug to do this job instead of me. Fortunately, no-one yet has resorted to such extremely unproductive and annoying moaning either, MIPS must be special: http://tinyurl.com/247o38 There are folks that do something about the situation and appreciate these bugs; MIPS apparently doesn't. Before these bugs were being filed, we had vulnerable stuff sitting in the happily for years (GLSAs back from ~2004ish etc.). So, for future - go find someone else to babysit MIPS, do not care about your bugs any more. Go play with your fancy formatting tools instead of getting the work done. Eroyf, if you need something in future, poke me in private. I'd like to avoid any interaction with the rest of our MIPS team until people show better consideration for other people's voluntary effort.) Ktnxbye everyone; don't expect any other reaction here.
(In reply to comment #47) > (In reply to comment #44) > > Good that you neglected to post suggestion whatsoever on *how* the output > should be improved; pretty much significant for all the whining folks here. > Just whining, nothing done. > Yes, I neglected that as others have already stated what's needed by arch teams (see comment #4 and bug 164176). But I'll gladly state in my own words what's wrong with the format you used seen from an arch devs point of view. 1. You're providing the info we shouldn't care about (arch teams care about stuff that should stay, not stuff that should be removed from the tree) 2. You're making this somewhat of a guessing game by asking arch teams to take all the available info by themselves (all ebuilds, checking dependencies, reverse dependencies and so forth) and trying to subtract the info you gave. 3. You expect arch to work faster and never the less end up making our work much harder than needed (See point 1 and 2). I'm going to ask to consider above points when you've cooled off a bit and hopefully you'll realise that improving the output would benefit everyone involved. Nobody is asking you to stop filing these bugs, all we want is a better format so we can spend our time working on testing new versions and stabling them instead of spending our time trying to figure out what you want us to do. It's a question of helping us help you in the most basic sense.
