1 |
Alex Schuster posted on Mon, 29 Nov 2010 20:33:02 +0100 as excerpted: |
2 |
|
3 |
> Duncan writes: |
4 |
> |
5 |
>> It hasn't actually been released upstream, yet. Normally, the kde team |
6 |
>> put a mask in the overlay before they add the new ebuilds in |
7 |
>> preparation, then simply unmask them on the day of release (or maybe a |
8 |
>> day later if they forget or if there are last-minute changes that broke |
9 |
>> something and they're left scrambling), but this time, whether due to |
10 |
>> policy change or simply overlooking it (it /was/ a long holiday weekend |
11 |
>> here in the US) I don't know, they didn't. |
12 |
> |
13 |
> Thanks, Duncan! Then I'll just wait. I thought maybe I have to add some |
14 |
> specific mirrors for the kde overlay or something. Now I'll just wait a |
15 |
> little. |
16 |
> |
17 |
>> There's a bug open. I'm CCed and you can too (I searched on ALL kde |
18 |
>> 4.5.4 and it was the only one), but if I don't miss my guess, release |
19 |
>> might be today anyway, in which case it'll be moot. I'm sort of |
20 |
>> expecting it today, Monday, but I'd almost certainly expect it by |
21 |
>> Wednesday. |
22 |
> |
23 |
> I do not find anything when I search for 4.5.4. Well, whatever. |
24 |
|
25 |
Two notes: |
26 |
|
27 |
1: According to the bug, they did the masking and marked the bug invalid |
28 |
(I'd have chosen fixed, but whatever...), so at your next update it should |
29 |
no longer be a problem (it'll either be masked or the new version will be |
30 |
out and it'll be unmasked again). |
31 |
|
32 |
2: Making bugzilla search work is a challenge. I never did get the |
33 |
detailed search working for me, but the little one-box fast-search down at |
34 |
the bottom, where you put in a bug number or search terms, works well |
35 |
enough in most cases. |
36 |
|
37 |
The key to remember is that in almost all cases, you'll want to precede |
38 |
your query with the word "ALL" (in all caps). Without that, you only get |
39 |
open bugs, but as a user, you almost always want to be searching for bugs |
40 |
that may have been closed, as well. So it's become a habit for me now, if |
41 |
I'm putting in search terms and not a bug number, I always start it with |
42 |
ALL<space>, then my search terms. |
43 |
|
44 |
Normally, you'd then put in a specific package name, but we don't have a |
45 |
specific name as it's all kde, so we just use kde. If possible, use the |
46 |
full Gentoo category/name, too, when searching on a specific package. |
47 |
Otherwise you'll likely get bugs in other packages only slightly related |
48 |
to the package in question. |
49 |
|
50 |
Then, put in as much of the version number as makes sense. When it's a |
51 |
specific package, that means using the category/package-v.e.r syntax. The |
52 |
reasoning for that is that if a filter forgets to put it in, the bug |
53 |
wranglers usually adjust it to that as standard form, so you'll get all |
54 |
the hits on that package and version, while eliminating more extraneous |
55 |
hits. But do keep in mind, if you don't /know/ which version the bug |
56 |
appeared in, and you try say 4.4.3 and it doesn't turn up, you can hit |
57 |
back and relax your query to only 4.4. or even only 4. Again, use what |
58 |
makes sense. |
59 |
|
60 |
Then put any other search terms likely to be in the title, crash if it is, |
61 |
a keyword from the error if it's an emerge failure, etc. Again, you can |
62 |
take them out if you don't get any hits and try again. Or of course if |
63 |
you get too many hits, you can try narrowing it with more keywords. Be |
64 |
sure and think of alternatives as well and try them too. Many crashes are |
65 |
segfaults, for instance, so if crash doesn't work, segfault might. |
66 |
|
67 |
Regardless, you'll often find yourself looking at a whole long list of |
68 |
bugs, say 200, 500, whatever, with no way to practically narrow it further |
69 |
without using the detail search which as I said I've never been able to |
70 |
get to work as I expect, here. At this point, the key is to remember that |
71 |
the bugs are in numerical order by default, with the numbers assigned |
72 |
chronologically. So you can start with the LAST bug listed, therefore, |
73 |
the newest, and search titles going backward, looking for something that |
74 |
looks possibly related, until you clearly get back to when they were |
75 |
obviously dealing with way earlier versions that didn't have the problem. |
76 |
If you haven't found it by then, it's time to declare your search foo too |
77 |
bad to find it, if it's there, and file a new bug. |
78 |
|
79 |
Based on the above general rules, as I said, this query: |
80 |
|
81 |
ALL kde 4.5.4 |
82 |
|
83 |
returns (still) just one bug, which happens to be the one we're looking |
84 |
for. If you forget the ALL, you'll miss it since the bug is (as I say |
85 |
above) already resolved/invalid, and thus won't show unless the query |
86 |
starts with that all-important ALL. |
87 |
|
88 |
Which is I expect what happened when you searched. You missed (or didn't |
89 |
ALL CAPS) that ALL, and the bug was already resolved, so you got the |
90 |
infamous zarro boogs found message. |
91 |
|
92 |
Anyway, now that I've explained all that, since I just tried it again to |
93 |
be sure, I might as well include the bug link it returns. |
94 |
|
95 |
http://bugs.gentoo.org/show_bug.cgi?id=347013 |
96 |
|
97 |
-- |
98 |
Duncan - List replies preferred. No HTML msgs. |
99 |
"Every nonfree program has a lord, a master -- |
100 |
and if you use the program, he is your master." Richard Stallman |