Gentoo Archives: gentoo-desktop

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-desktop@l.g.o
Subject: [gentoo-desktop] Re: KDE 4.5.4 distfiles missing
Date: Tue, 30 Nov 2010 10:03:15
Message-Id: pan.2010.11.30.09.16.23@cox.net
In Reply to: Re: [gentoo-desktop] Re: KDE 4.5.4 distfiles missing by Alex Schuster
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