Gentoo Archives: gentoo-dev

From: Greg <greg@××××××××.com>
To: gentoo-dev@××××××××××××.org
Subject: [gentoo-dev] unsubscribe
Date: Tue, 22 Mar 2005 02:04:16
Message-Id: 423F7D1C.7070500@mdntridr.com
1 gentoo-dev+help@××××××××××××.org wrote:
2
3 >
4 > ------------------------------------------------------------------------
5 >
6 > Subject:
7 > [gentoo-dev] Managers Meeting Log - 14/03/2005
8 > From:
9 > Daniel Ostrow <dostrow@g.o>
10 > Date:
11 > Mon, 14 Mar 2005 14:03:32 -0500
12 > To:
13 > gentoo-dev@××××××××××××.org
14 >
15 > To:
16 > gentoo-dev@××××××××××××.org
17 >
18 >
19 >All:
20 >
21 >Here is the meeting log for March 14th 2005.
22 >
23 >--Dan
24 >
25 >
26 >------------------------------------------------------------------------
27 >
28 >**** BEGIN LOGGING AT Mon Mar 14 12:34:38 2005
29 >
30 >Mar 14 12:34:38 * Now talking on #gentoo-meetings
31 >Mar 14 12:34:42 * Griffon26 (~griffon26@×××××××××××××××××××.gentoo) has joined #gentoo-meetings
32 >Mar 14 12:39:39 * carpaski 's conference call just now started... I might miss the meeting. I sent an email to core.
33 >Mar 14 12:41:12 * kosmikus (~andres@××××××××××××××××××.gentoo) has joined #gentoo-meetings
34 >Mar 14 12:49:48 * tove (~tove@××××××××××××××××××××××××××.de) has joined #gentoo-meetings
35 >Mar 14 12:50:18 * bcowan (~bcowan@××××××××××××××××××××××××××××××××××××××××××××.net) has joined #gentoo-meetings
36 >Mar 14 12:52:35 * klieber (klieber@×××××××××××××××××××.freenode) has joined #gentoo-meetings
37 >Mar 14 12:52:35 * ChanServ gives channel operator status to klieber
38 >Mar 14 12:55:42 pvdabeel how long till the meeting?
39 >Mar 14 12:55:48 Battousai 3 minutes?
40 >Mar 14 12:55:51 pvdabeel k
41 >Mar 14 12:56:00 Battousai i think carpaski said 1pm
42 >Mar 14 12:56:05 Battousai eastern, which is in 3 minutes
43 >Mar 14 12:56:05 * ferringb (esmith@××××××××××××××××××.gentoo) has joined #gentoo-meetings
44 >Mar 14 12:56:50 * ciaranm (~ciaranm_@×××××××××××××××××××××××××××××××.pdpc) has joined #gentoo-meetings
45 >Mar 14 12:56:58 ferringb carpaski: have you read anything of the glep33 discussion yet?
46 >Mar 14 12:57:01 ciaranm yay, i can remember the password
47 >Mar 14 12:57:09 spb well done ciaranm
48 >Mar 14 12:57:13 ferringb ciaranm: yeah, took a bit of searching on my part to get in also.
49 >Mar 14 12:57:18 ciaranm re glep 33, i still don't see the need for separation :P
50 >Mar 14 12:57:41 * cshields (~cshields@××××××××××××××.osuosl) has joined #gentoo-meetings
51 >Mar 14 12:57:58 * cryos (~cryos@×××××××××××××××.gentoo) has joined #gentoo-meetings
52 >Mar 14 12:58:00 ferringb ciaranm: elib vs eclasses? it comes down to having an appropriate container for the bin/* crap moved out of portage, and into the tree.
53 >Mar 14 12:58:35 ciaranm yup. but the "no var modification" stuff is gonna make it hard to actually have any elibs...
54 >Mar 14 12:58:43 * kloeri_ (~kloeri@××××××××××××××××.gentoo) has joined #gentoo-meetings
55 >Mar 14 13:00:06 Pylon Where is the chairman?
56 >Mar 14 13:00:13 ciaranm chairperson
57 >Mar 14 13:00:27 Pylon Whatever.
58 >Mar 14 13:00:31 ciaranm chairthing
59 >Mar 14 13:00:34 ferringb ciaranm: actually, it's pretty easy.
60 >Mar 14 13:00:49 Pylon chairwossname
61 >Mar 14 13:00:56 ciaranm chair
62 >Mar 14 13:00:58 ferringb ciaranm: elibs are loaded pre-setup phase. can't screw with metadata, cause the elib functionality isn't available at that stage (it's an internal ebuild.sh trick)
63 >Mar 14 13:01:41 ciaranm ferringb: yeah. i know how it works. i just think that that restriction means we'll have maybe one or two elibs and no reduction in eclass count
64 >Mar 14 13:02:17 ferringb ciaranm: possibly. if that's the case, we do eclass3. meanwhile, elibs *are* needed from a portage perspective.
65 >Mar 14 13:02:40 ferringb that's the maint thrust of it, that and rolling most of eutils back into defaults, as it should've been.
66 >Mar 14 13:03:01 ciaranm yeah, in which case i object to your examples in the glep :)
67 >Mar 14 13:03:07 ferringb such as?
68 >Mar 14 13:03:25 * ian|home (~ian|home@×××××××××××××.gentoo) has joined #gentoo-meetings
69 >Mar 14 13:03:33 * ciaranm goes to actually find the thing again
70 >Mar 14 13:04:47 * blackace (~blackace@××××××××××××××××××.gentoo) has joined #gentoo-meetings
71 >Mar 14 13:05:24 ciaranm yeah, it still mentions eutils
72 >Mar 14 13:05:39 ferringb ciaranm: iirc, the glep specifically singled out your epatch example.
73 >Mar 14 13:05:46 ferringb ciaranm: the patch dependency.
74 >Mar 14 13:05:54 ciaranm ferringb: it does at one point, and then forgets it again a bit later on
75 >Mar 14 13:06:05 ferringb so the writing is slightly daft. the idea is there though :P
76 >Mar 14 13:06:18 ferringb and the wording can be tweaked.
77 >Mar 14 13:10:12 * genstef (~stefan@×××××××××××××××××.gentoo) has joined #gentoo-meetings
78 >Mar 14 13:11:30 * ferringb (esmith@××××××××××××××××××.gentoo) has left #gentoo-meetings
79 >Mar 14 13:11:45 * ferringb (esmith@××××××××××××××××××.gentoo) has joined #gentoo-meetings
80 >Mar 14 13:13:45 dostrow_work ok, who killed Grant and buried him the the back yard........
81 >Mar 14 13:14:42 * pvdabeel has quit ("leaving")
82 >Mar 14 13:14:43 ciaranm wasn't me. i like grant. he agrees with me
83 >Mar 14 13:14:57 spb everyone likes grant really
84 >Mar 14 13:15:07 ciaranm yeah, except for the apache devs :)
85 >Mar 14 13:15:11 dostrow_work heh
86 >Mar 14 13:15:29 spb exception that proves the rule ;p
87 >Mar 14 13:15:53 * araujo (~araujo@××××××××××××××××.gentoo) has joined #gentoo-meetings
88 >Mar 14 13:20:30 ferringb ah hell with this, I have work to do.
89 >Mar 14 13:20:32 ciaranm hrm. another amazing demonstration of the effectiveness of our current management...
90 >Mar 14 13:20:36 ferringb no shit.
91 >Mar 14 13:20:39 * ferringb (esmith@××××××××××××××××××.gentoo) has left #gentoo-meetings
92 >Mar 14 13:21:18 * swegener (~sven@××××××××××××××××××.gentoo) has joined #gentoo-meetings
93 >Mar 14 13:22:49 blackace so stop bitching about it and do something, one of you could have picked up for grant and started the meeting, but no, it's easier to blame someone else and bitch about it.
94 >Mar 14 13:23:04 ciaranm yeah. the meeting. right. with how managers here?
95 >Mar 14 13:23:14 ciaranm the whole point of this meeting is to vote on GLEPs by me and ferringb
96 >Mar 14 13:23:19 ciaranm which, uh, we kinda can't do...
97 >Mar 14 13:23:52 blackace you say "ok, let's get the meeting started, first up let's talk about my glep, yea/nay?"
98 >Mar 14 13:24:13 ciaranm ...and there aren't any managers active to actually say yae/nay
99 >Mar 14 13:24:18 ciaranm so it makes no difference
100 >Mar 14 13:24:19 * klieber coughs
101 >Mar 14 13:24:32 ciaranm ok, klieber became unidle. that's one :)
102 >Mar 14 13:24:39 klieber I've been here the whole time
103 >Mar 14 13:24:48 blackace he's been here the whole time waiting for someone to say "hey let's start"
104 >Mar 14 13:24:52 * dostrow_work wipes the nasty klieber cough off his shirt
105 >Mar 14 13:24:56 blackace as have the rest of us.
106 >Mar 14 13:25:04 klieber yeah, I think I'm getting the flu, too
107 >Mar 14 13:25:07 * klieber coughs on ciaranm
108 >Mar 14 13:25:13 * g2boojum (~grant@××××××××××××××××××.gentoo) has joined #gentoo-meetings
109 >Mar 14 13:25:13 * ChanServ gives channel operator status to g2boojum
110 >Mar 14 13:25:20 ciaranm he's alive!
111 >Mar 14 13:25:20 Ramereth speak of the devil
112 >Mar 14 13:25:21 Kugelfang blackace: but ciaranm is right (oh did i really say that?)
113 >Mar 14 13:25:21 klieber hi grant
114 >Mar 14 13:25:24 dostrow_work klieber: oh great, no I'm going to get sick
115 >Mar 14 13:25:28 dostrow_work *now
116 >Mar 14 13:25:28 g2boojum Sorry, extremely long meeting.
117 >Mar 14 13:25:41 blackace Kugelfang: no he's not, he just has no initiative, he's not self starting.
118 >Mar 14 13:25:44 dostrow_work grant!!!!!!
119 >Mar 14 13:25:55 klieber guys...it's just a fact of life that RL happens and will invariably impact us on a regular basis
120 >Mar 14 13:26:01 klieber we're a volunteer organization
121 >Mar 14 13:26:06 Kugelfang blackace: no, i mean: where are the manages to vote on the gleps?
122 >Mar 14 13:26:15 ciaranm blackace: ah, no, see i do the actual work. i leave the paper pushing to others
123 >Mar 14 13:26:35 Kugelfang klieber: we all know that...
124 >Mar 14 13:26:41 klieber personally, I'd like to see voting moved to a web site or some other method that has a history, etc.
125 >Mar 14 13:26:46 blackace exactly, which means it's OK if grant runs late, someone else has to step up to the plate and get the meeting started in his stead, who better than someone who bitches about it? like ciaranm or ferringb?
126 >Mar 14 13:26:50 klieber irc is too transient and not everyone can meet at the same time
127 >Mar 14 13:26:58 Kugelfang klieber: still, what is a meeting for that should vote on things when hardly anyone who is allowed to vote is here ?
128 >Mar 14 13:27:21 klieber Kugelfang: which is why I think we should move the voting to something else where we can get a higher rate of participation
129 >Mar 14 13:27:37 ian|home *cough*forums*cough*
130 >Mar 14 13:27:44 klieber we're a global team -- no matter what time we pick, it will suck for at least some of the people responsible for voting
131 >Mar 14 13:27:57 Pylon We could shift the meeting to 0UTC or so.
132 >Mar 14 13:27:58 blackace klieber: could always have veszig set up surveys.g.o for it
133 >Mar 14 13:28:00 ciaranm ian|home: yeah right. how many developers actually have forums accounts, and how many of those are banned?
134 >Mar 14 13:28:03 Pylon Then probably more could attend.
135 >Mar 14 13:28:05 Ramereth klieber: we could adapt survey.g.o to do voting it hink
136 >Mar 14 13:28:19 g2boojum Also, we've always allowed people to vote by e-mail, too.
137 >Mar 14 13:28:20 ian|home ciaranm: banned? none. accounts. look it up yourself.
138 >Mar 14 13:28:22 klieber ciaranm: instead of pissing on every idea that gets proposed, why not help be part of the solution?
139 >Mar 14 13:28:39 klieber forums would work, surveys might work too.
140 >Mar 14 13:28:45 klieber I'm sure there are other ideas that would work as well
141 >Mar 14 13:28:49 ciaranm klieber: it might have escaped your notice, but the solutions i'm working on kinda involve the tree... ya know, our main product
142 >Mar 14 13:29:14 klieber ok ciaran....you're never going to be happy no matter what we do. I'll hope that others will be willing to help.
143 >Mar 14 13:29:18 g2boojum Just out of curiostiy, what's the current topic?
144 >Mar 14 13:29:31 klieber lack of attendance at these meetings
145 >Mar 14 13:29:38 dostrow_work klieber: hehe
146 >Mar 14 13:29:38 ciaranm klieber: i'm happy so long as i'm able to keep the tree working and moving forward
147 >Mar 14 13:29:51 * g2boojum has changed the topic to: current topic: lack of attendance at meetings
148 >Mar 14 13:30:18 Kugelfang can anyone tell me how many managers attend this meeting ?
149 >Mar 14 13:30:22 dostrow_work someone might want to call ferringb back if there is going to be an active vote on glep33........but hey what do I know
150 >Mar 14 13:30:29 klieber and I've certainly been guilty of lack of attendance recently, but I hope to get better about that now that my personal life is settling a bit.
151 >Mar 14 13:30:32 ciaranm Kugelfang: you're looking at around two or three
152 >Mar 14 13:30:59 Kugelfang ciaranm: klieber, carpaski and ?
153 >Mar 14 13:31:07 ciaranm Kugelfang: az may or may not be a manager
154 >Mar 14 13:31:11 Pylon Well. 18UTC is pretty good for Europeans. But US-devs are at work. And Australians are somewhen in the night. What about shifting to a better time? Many European devs seem to be night-workers.
155 >Mar 14 13:31:31 g2boojum ciaranm: Az is the manager for base.
156 >Mar 14 13:31:31 az he was once aponce a time
157 >Mar 14 13:31:33 Kugelfang what about shifting to the weekend ?
158 >Mar 14 13:31:34 klieber Pylon: I don't think there's one time that will ever work for everyone.
159 >Mar 14 13:31:49 az sorry, busy with the foodstuff making, and nearly forgot
160 >Mar 14 13:32:00 Pylon klieber: That's true. But a time on which we could raise the attendance.
161 >Mar 14 13:32:37 klieber for discussion? or voting?
162 >Mar 14 13:32:38 cshields wasn't that the point of the current timeslot?
163 >Mar 14 13:32:41 bcowan been thru the meeting time changes stuff since we started having meetings, it's not a solution
164 >Mar 14 13:32:57 klieber because if it's for voting...it's not fair to consistently exclude people who can't make that particular time
165 >Mar 14 13:33:07 dostrow_work it always ends up at 1800 UTC on monday seems to be the best time
166 >Mar 14 13:33:56 bcowan maybe we need to re-look into some groupware stuff just for this situation
167 >Mar 14 13:34:17 blackace bcowan: cshields is working on that I believe.
168 >Mar 14 13:34:22 az i thought g2 suggested sending replacements?
169 >Mar 14 13:34:29 klieber I think the discussions can happen via any number of methods (irc, email, whatever) and then have a separate means for voting
170 >Mar 14 13:34:32 az i cant think that anybody but nick said he might not be here
171 >Mar 14 13:34:39 * wolf31o2-work (~wolf31o2@×××××××××××××××××××××××.gentoo) has joined #gentoo-meetings
172 >Mar 14 13:34:52 dostrow_work also brings to mind: What is the present number of managers necessary to carry a vote?
173 >Mar 14 13:35:03 klieber honestly, the forums would work well for this kind of stuff. avenue for discussion and we can then vote at the same time
174 >Mar 14 13:35:05 carpaski I'm back.
175 >Mar 14 13:35:10 carpaski Just finished my conference call.
176 >Mar 14 13:35:14 * carpaski reads back.
177 >Mar 14 13:35:28 klieber dostrow_work: it's never really been formalized, afaik.
178 >Mar 14 13:35:29 Pylon For voting we could even involve forums or the other solution.
179 >Mar 14 13:35:53 g2boojum dostrow_work: I've always assumed that the answer is: "whatever number shows up".
180 >Mar 14 13:35:54 ciaranm forums are up for abuse by non-devs
181 >Mar 14 13:36:00 ian|home all we'd need to do is to make forumsaccounts mandatory for devs.
182 >Mar 14 13:36:04 klieber ciaranm: we have a dev-only forum.
183 >Mar 14 13:36:10 carpaski The meeting was announced in the last meeting email... I almost missed the fact that we had one today at all.
184 >Mar 14 13:36:12 ciaranm klieber: yup, which can be read by non-devs
185 >Mar 14 13:36:16 klieber so?
186 >Mar 14 13:36:23 ciaranm klieber: and, more to the point, moderated by non-devs
187 >Mar 14 13:36:34 carpaski We only have 4 managers here?
188 >Mar 14 13:36:36 klieber that can be changed if it's so important
189 >Mar 14 13:36:44 Kugelfang carpaski: 4 ?
190 >Mar 14 13:36:45 klieber but I don't think it is
191 >Mar 14 13:36:51 * ian|home shrugs
192 >Mar 14 13:36:51 bcowan I personally don't like forums, but my say is generally irrelevant
193 >Mar 14 13:36:57 Kugelfang carpaski: you, klieber, az and ?
194 >Mar 14 13:37:12 az peter was here, but he went missing it seems
195 >Mar 14 13:37:27 g2boojum wolf31o2-work just popped in.
196 >Mar 14 13:37:39 wolf31o2-work I just got here... didn't realize 1800UTC was 1PM EST and not 2PM...\
197 >Mar 14 13:37:51 dostrow_work g2boojum: you could op him so the less inclined would realize his status
198 >Mar 14 13:37:54 g2boojum wolf31o2-work: Wait a month or so, and it will change. *Grin*
199 >Mar 14 13:37:58 * g2boojum gives channel operator status to wolf31o2-work
200 >Mar 14 13:38:10 wolf31o2-work thanks
201 >Mar 14 13:38:28 bcowan April 3rd....spring forward
202 >Mar 14 13:38:45 Pylon One week earlier in Europe.
203 >Mar 14 13:39:42 * beejay (~benni@××××××××××××××××.gentoo) has joined #gentoo-meetings
204 >Mar 14 13:39:49 beejay I knew I forgot something ...
205 >Mar 14 13:40:31 dostrow_work soooo.....then.....with 4 managers present.......are glep33 and glep34 going to be talked about......or is the general silence a bad sign?
206 >Mar 14 13:40:46 ciaranm no point in talking about 34 since ferringb left...
207 >Mar 14 13:41:31 carpaski You mean 33?
208 >Mar 14 13:41:44 ciaranm uh, probably :)
209 >Mar 14 13:41:45 carpaski 34 was the category metadata...
210 >Mar 14 13:41:57 ciaranm yeah, 34 was mine. i mean 33. i think
211 >Mar 14 13:42:01 * ciaranm injects caffeine
212 >Mar 14 13:43:01 ciaranm ok, well i think i answered all the queries re 34 on the list already...
213 >Mar 14 13:43:13 ciaranm and incorporated them into the revised version
214 >Mar 14 13:43:30 ciaranm unless anyone has any other questions?
215 >Mar 14 13:43:40 carpaski Where are these gleps being discuessed?
216 >Mar 14 13:43:47 ciaranm -dev
217 >Mar 14 13:44:29 blackace ciaranm: did you see carpaski's mail on -core?
218 >Mar 14 13:44:36 ciaranm blackace: yup
219 >Mar 14 13:44:49 ciaranm > I have no issues with GLEP 34. It's a yea.
220 >Mar 14 13:45:02 blackace I like the release/-testing idea
221 >Mar 14 13:45:24 ciaranm that's 33
222 >Mar 14 13:45:25 genone blackace: are you talking about the right one?
223 >Mar 14 13:45:47 blackace genone: 'course I'm not :P
224 >Mar 14 13:46:13 * dostrow_work hands to pot o' caffine around the room
225 >Mar 14 13:47:10 wolf31o2-work =]
226 >Mar 14 13:47:34 ciaranm ok, someone ask g2boojum to ask for a vote on 34 (metadata) please :)
227 >Mar 14 13:47:35 dostrow_work <crickets>
228 >Mar 14 13:47:49 wolf31o2-work dostrow_work: I was just thinking the same thing
229 >Mar 14 13:47:51 g2boojum May we have a vote on GLEP 34, please?
230 >Mar 14 13:47:59 wolf31o2-work g2boojum: yes
231 >Mar 14 13:48:09 wolf31o2-work g2boojum: and that's my vote, too
232 >Mar 14 13:48:13 klieber I vote yes as well.
233 >Mar 14 13:48:30 dostrow_work and carpaski already gave his nod
234 >Mar 14 13:48:39 az yes
235 >Mar 14 13:48:40 carpaski yes
236 >Mar 14 13:48:45 dostrow_work that makes 4 for 4
237 >Mar 14 13:48:57 Kugelfang wonderful
238 >Mar 14 13:49:11 ciaranm hrm. now i just need to find pauldv to do the dtd commit. wooh!
239 >Mar 14 13:49:24 az mail him
240 >Mar 14 13:49:31 ciaranm ja
241 >Mar 14 13:50:44 dostrow_work so, unless anyone feels like tracking ferringb down and calling him back, I think that just about does it........
242 >Mar 14 13:51:16 g2boojum All in favor of adjourning? I arrived late, so I didn't log. Will somebody please post a log?
243 >Mar 14 13:51:27 dostrow_work sure
244 >Mar 14 13:53:05 ciaranm yay. now i can go eat
245 >Mar 14 13:53:07 * ciaranm (~ciaranm_@×××××××××××××××××××××××××××××××.pdpc) has left #gentoo-meetings
246 >Mar 14 13:53:21 dostrow_work <more crickets>
247 >Mar 14 13:57:38 * wolf31o2-work (~wolf31o2@×××××××××××××××××××××××.gentoo) has left #gentoo-meetings ("Leaving")
248 >Mar 14 13:58:09 * g2boojum (~grant@××××××××××××××××××.gentoo) has left #gentoo-meetings
249 >Mar 14 13:58:21 * kloeri_ (~kloeri@××××××××××××××××.gentoo) has left #gentoo-meetings
250 >**** ENDING LOGGING AT Mon Mar 14 13:59:37 2005
251 >
252 >
253 >
254 >
255 > ------------------------------------------------------------------------
256 >
257 > Subject:
258 > Re: [gentoo-dev] whitelisting the env ebuilds execute in
259 > From:
260 > Aron Griffis <agriffis@g.o>
261 > Date:
262 > Mon, 14 Mar 2005 14:21:53 -0500
263 > To:
264 > gentoo-dev@××××××××××××.org
265 >
266 > To:
267 > gentoo-dev@××××××××××××.org
268 >
269 >
270 >Brian Harring wrote: [Sun Mar 13 2005, 10:40:16AM EST]
271 >
272 >
273 >>So... yeah. Anyone got a good reason why all vars should be dumped
274 >>into the ebuild environment? I don't see the point in all of my
275 >>binpkgs having my ECHANGELOG_USER setting, for example.
276 >>
277 >>
278 >
279 >Sounds like a great idea to me.
280 >
281 >Regards,
282 >Aron
283 >
284 >--
285 >Aron Griffis
286 >Gentoo Linux Developer
287 >
288 >
289 >
290 >
291 > ------------------------------------------------------------------------
292 >
293 > Subject:
294 > [gentoo-dev] mysql-4.1.10a ebuild
295 > From:
296 > Francesco Riosa <francesco@×××××××××.it>
297 > Date:
298 > Mon, 14 Mar 2005 22:00:28 +0100
299 > To:
300 > gentoo-dev@××××××××××××.org
301 >
302 > To:
303 > gentoo-dev@××××××××××××.org
304 >
305 >
306 > bug [1] has two new attachments [2] and [3], untar [2] in your
307 > $OVERLAY directory should be enough to make it possible an "emerge -av
308 > =mysql-4.1.10a".
309 >
310 > ATM it compile and run without problems on two boxes, ~x86 and amd64,
311 > with FEATURES="maketest" too... but is heavy modified from what I was
312 > running before, mainly because of suggestions received today.
313 >
314 > Has been requested that bugs for this ebuild goes on bugzilla, to make
315 > mysql-team can see what happen too.
316 >
317 > <grin>
318 > robbat2 ask me to specify "That I will be working with you to
319 > integrate your work within the next two months."
320 > </grin>
321 >
322 > please fullfill #83011 of reports I'll try my best to correct all the
323 > possible ;)
324 >
325 > enjoy
326 > francesco
327 >
328 > [1] http://bugs.gentoo.org/show_bug.cgi?id=83011 "mySQL new version
329 > 4.1.10"
330 > [2] http://bugs.gentoo.org/attachment.cgi?id=53446&action=view
331 > "overlay for mysql-4.1.10a"[3]
332 > [3] http://bugs.gentoo.org/attachment.cgi?id=53447 diffs between
333 > 4.0.24-r1 and 4.1.10a ebuilds
334 >
335 > --
336 > gentoo-dev@g.o mailing list
337 >
338 > ------------------------------------------------------------------------
339 >
340 > Subject:
341 > Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'
342 > From:
343 > Donnie Berkholz <spyderous@g.o>
344 > Date:
345 > Mon, 14 Mar 2005 13:21:18 -0800
346 > To:
347 > gentoo-dev@××××××××××××.org
348 >
349 > To:
350 > gentoo-dev@××××××××××××.org
351 >
352 >
353 >-----BEGIN PGP SIGNED MESSAGE-----
354 >Hash: SHA1
355 >
356 >Vitaly Ivanov wrote:
357 >
358 >
359 >>I found the comments of Nicholas Jones in bug
360 >>http://bugs.gentoo.org/show_bug.cgi?id=52415
361 >>
362 >>
363 >>>>Portage makes the assumption that if you're installing
364 >>>>into a new root, then you're building a system and
365 >>>>shouldn't bother with config protection. It's not
366 >>>>documented either way, so it's undefined behavior.
367 >>>>
368 >>>>
369 >
370 >I disagree with that logic, because people may be maintaining systems in
371 >a ROOT with modified config files. Updating those systems trashes the
372 >files. Thank you for pointing out this behavior now, because it walks
373 >all over plans I have for a diskless cluster.
374 >-----BEGIN PGP SIGNATURE-----
375 >Version: GnuPG v1.4.0 (GNU/Linux)
376 >
377 >iD8DBQFCNgBOXVaO67S1rtsRAqwXAKD1gXa1Du1kUQl2SpmxGHKTIl+u3ACg++D1
378 >yEnWNpiVD2Fhg97Tic7ZcFo=
379 >=9nYL
380 >-----END PGP SIGNATURE-----
381 >--
382 >gentoo-dev@g.o mailing list
383 >
384 >
385 >
386 > ------------------------------------------------------------------------
387 >
388 > Subject:
389 > [gentoo-dev] initialisation oder in checkfs
390 > From:
391 > Thomas Wöckinger <thomas.woeckinger@×××××.com>
392 > Date:
393 > Mon, 14 Mar 2005 22:34:55 +0100
394 > To:
395 > gentoo-dev@××××××××××××.org
396 >
397 > To:
398 > gentoo-dev@××××××××××××.org
399 >
400 >
401 >Hi!
402 >
403 >This is just a hint for changing the initialisation order in checkfs.
404 >Currently lvm will be initialized before sw-raid. So it is not
405 >possible to set up lvm on a raid device during the boot procedure,
406 >therefore i think it is a good idea to change the initialization order
407 >to evms -- raid -- lvm
408 >
409 >lg tom
410 >--
411 >gentoo-dev@g.o mailing list
412 >
413 >
414 >
415 > ------------------------------------------------------------------------
416 >
417 > Subject:
418 > [gentoo-dev] Ebuild removing
419 > From:
420 > Ciaran McCreesh <ciaranm@g.o>
421 > Date:
422 > Mon, 14 Mar 2005 22:17:01 +0000
423 > To:
424 > gentoo-dev@l.g.o
425 >
426 > To:
427 > gentoo-dev@l.g.o
428 >
429 >
430 >Ok, I dunno how many times me and Weeve have said this now, but it's
431 >still being ignored...
432 >
433 >FOLLOW THE FRICKIN' POLICY WHEN REMOVING EBUILDS
434 >
435 >In particular:
436 >
437 >1) Don't remove the highest stable version for any arch
438 >
439 >2) Don't remove the highest ~arch version for any arch unless there is a
440 >higher stable version for that arch. Exception: you're deliberately
441 >forcing a downgrade because you committed something really broken to
442 >~arch.
443 >
444 >It really isn't funny when the arch teams have to spend more time fixing
445 >screwups caused by developers not following keyword policy than working
446 >on useful stuff. I don't care if being careful involves slightly more
447 >work on your part -- identifying and fixing the screwups you caused not
448 >only takes a lot more effort from a lot more people, it also impacts end
449 >user systems. Stop being so damned rude.
450 >
451 >
452 >
453 >
454 > ------------------------------------------------------------------------
455 >
456 > Subject:
457 > Re: [gentoo-dev] Partimage on the livecd
458 > From:
459 > Christian Zoffoli <xmerlin@g.o>
460 > Date:
461 > Tue, 15 Mar 2005 02:22:03 +0100
462 > To:
463 > gentoo-dev@××××××××××××.org
464 >
465 > To:
466 > gentoo-dev@××××××××××××.org
467 >
468 >
469 > Chris Gianelloni wrote:
470 > [cut]
471 >
472 >> HAHAHAHAHA...
473 >>
474 >> Anyway, though spyderous was joking somewhat, he does have a point. We
475 >> really have no reason to produce one as part of the regular releases. I
476 >> have thought about making one, just for kicks. The primary reason for
477 >> not doing one is that SystemRescueCD already does this quite well. This
478 >> is a niche where someone else has built on Gentoo's work and has come up
479 >> with a unique and usable product. While I have no problem with someone
480 >> else within the Gentoo project using catalyst for this task, I don't see
481 >> a reason for one as part of the official releases.
482 >>
483 >
484 > Sysrescuecd works only on x86, the ppc version is in beta from months
485 > and months and it doesn't work with a network backup solution like
486 > bacula or something similar (FYI projects like qtparted are officially
487 > death).
488 >
489 > And I'm agree with many users that want a recovery solution integrated
490 > with the "install disk".
491 >
492 >
493 > Christian
494 >
495 > --
496 > gentoo-dev@g.o mailing list
497 >
498 > ------------------------------------------------------------------------
499 >
500 > Subject:
501 > Re: [gentoo-dev] Gentoo @ LinuxTag 2005?
502 > From:
503 > Lars Weiler <pylon@g.o>
504 > Date:
505 > Tue, 15 Mar 2005 03:20:10 +0100
506 > To:
507 > gentoo-dev@××××××××××××.org
508 >
509 > To:
510 > gentoo-dev@××××××××××××.org
511 >
512 >
513 >* Andrew Cowie <andrew@×××××××××××××××××××.com> [05/03/14 12:14 +1100]:
514 >
515 >
516 >>One suggestion: last year the Gentoo contingent seemed to have missed
517 >>out on the keysigning that was held at LinuxTag, which I thought was a
518 >>rather large lost opportunity.
519 >>
520 >>
521 >
522 >I took part the year before. But did you ever attended a
523 >keysigning-party with 200 persons? You need a whole day for
524 >signing the keys :-/
525 >
526 >
527 >
528 >>Manning a booth always takes persistence and effort, but I would
529 >>encourage a conscientious effort for any Gentoo devs or users at
530 >>LinuxTag this year to participate in the keysigning.
531 >>
532 >>
533 >
534 >By the way: We drank beer together, did we also signed keys? ;-)
535 >
536 >
537 >
538 >>++
539 >>
540 >>The other thing that often happens when you man a booth is that the
541 >>people doing so end up missing everything else that is going on. As a
542 >>generic example, last year Ian Murdoch gave a keynote (!) at LinuxTag,
543 >>and none of the Debian developers who were busy manning their booth even
544 >>knew he was speaking.
545 >>
546 >>The technical conference side of LinuxTag is significant, and I
547 >>encourage people to attend as many sessions as they can.
548 >>
549 >>
550 >
551 >Well. I like manning a booth or installing Gentoo on a HP
552 >Quad-Opteron or even have a talk with an interesting person
553 >more than watching a lot of talks.
554 >
555 >But as we should be enough Devs this year, we probably could
556 >prepare a schedule, so that some could visit some talks.
557 >And as our experience for preparing booths grew within the
558 >last two years we will do the presentation of Gentoo at
559 >LinuxTag ever ;-)
560 >
561 >Regards, Lars
562 >
563 >
564 >
565 > ------------------------------------------------------------------------
566 >
567 > Subject:
568 > Re: [gentoo-dev] Gentoo @ LinuxTag 2005?
569 > From:
570 > Michael Imhof <tantive@g.o>
571 > Date:
572 > Tue, 15 Mar 2005 03:24:37 +0100
573 > To:
574 > gentoo-dev@××××××××××××.org
575 >
576 > To:
577 > gentoo-dev@××××××××××××.org
578 > CC:
579 > Gentoo Developers <gentoo-dev@××××××××××××.org>
580 >
581 >
582 > Robin H. Johnson wrote:
583 >
584 >> In the same vein as DSD's question about GUADEC 2005, and in the same
585 >> area, is there going to be a Gentoo presence at LinuxTag 2005?
586 >> (Karlsruhe, June 22 to 25)
587 >
588 >
589 > Sure! As for the last years gentoo will have a booth. Pictures should be
590 > flying around the net ;)
591 > If you want to get involved feel free to contact me...
592 >
593 >>
594 >> I'm going to be there, but I will probably be manning the phpMyAdmin
595 >> booth in the LAMP area most of the time. I would however like to meet
596 >> up with whatever Gentoo developers are out there. (My itinerary should
597 >> be up on Planet shortly).
598 >>
599 > Great, Sebastian already told he will be in the LAMP area as well.
600 >
601 >
602 >
603 > Regards
604 > Tantive
605 >
606 > ------------------------------------------------------------------------
607 >
608 > Subject:
609 > Re: [gentoo-dev] Partimage on the livecd
610 > From:
611 > "M. Edward (Ed) Borasky" <znmeb@×××××××.net>
612 > Date:
613 > Mon, 14 Mar 2005 18:24:36 -0800
614 > To:
615 > gentoo-dev@××××××××××××.org
616 >
617 > To:
618 > gentoo-dev@××××××××××××.org
619 >
620 >
621 > Christian Zoffoli wrote:
622 >
623 >> (FYI projects like qtparted are officially death).
624 >
625 >
626 > Well ... I'm not so sure about that. QTParted and its underlying
627 > parted do not work safely with NTFS or reiserfs. As far as I know,
628 > they work with ext2 and FAT32, and may work with ext3. That's it!
629 > Partition Magic, which is licensed, works with NTFS (but not reiserfs).
630 >
631 >>
632 >> And I'm agree with many users that want a recovery solution
633 >> integrated with the "install disk".
634 >
635 >
636 > I've got a stack of "rescue CDs" -- Knoppix, Kanotix, Fedora Core 3
637 > rescue, etc. Most of the rescue tasks I need to get done can also be
638 > done by Damn Small and by the Gentoo LiveCD. The one I reach for,
639 > though, is Knoppix, because I have more experience with it.
640 > --
641 > gentoo-dev@g.o mailing list
642 >
643 > ------------------------------------------------------------------------
644 >
645 > Subject:
646 > Re: [gentoo-dev] GUADEC 2005?
647 > From:
648 > Michael Imhof <tantive@g.o>
649 > Date:
650 > Tue, 15 Mar 2005 03:26:09 +0100
651 > To:
652 > gentoo-dev@××××××××××××.org
653 >
654 > To:
655 > gentoo-dev@××××××××××××.org
656 > CC:
657 > gentoo-dev@××××××××××××.org
658 >
659 >
660 > Hi,
661 >
662 > Daniel Drake wrote:
663 >
664 >> Hi,
665 >>
666 >> Is anyone planning to head out to GUADEC this year? (May 29th-31st,
667 >> Stuttgart, Germany)
668 >> Have Gentoo participated here before?
669 >
670 > Nope, i participated in the KDE Konference last year (in Stuttgart as
671 > well).
672 >
673 >>
674 >> I'm planning to go, assuming that I do not have any exams those days.
675 >
676 > heh, i will try to attend it as well as i'm living in stuttgart ;)
677 >
678 >
679 > Regards
680 > Tantive
681 >
682 > ------------------------------------------------------------------------
683 >
684 > Subject:
685 > Re: [gentoo-dev] Partimage on the livecd
686 > From:
687 > Alec Warner <warnera6@×××××××.edu>
688 > Date:
689 > Mon, 14 Mar 2005 21:38:22 -0500
690 > To:
691 > gentoo-dev@××××××××××××.org
692 >
693 > To:
694 > gentoo-dev@××××××××××××.org
695 >
696 >
697 > Christian Zoffoli wrote:
698 >
699 >> Chris Gianelloni wrote:
700 >> [cut]
701 >>
702 >>> <snip>
703 >>
704 >>
705 >>
706 >> Sysrescuecd works only on x86, the ppc version is in beta from months
707 >> and months and it doesn't work with a network backup solution like
708 >> bacula or something similar (FYI projects like qtparted are
709 >> officially death).
710 >>
711 >> And I'm agree with many users that want a recovery solution
712 >> integrated with the "install disk".
713 >>
714 >>
715 >> Christian
716 >>
717 >> --
718 >> gentoo-dev@g.o mailing list
719 >
720 >
721 > One of the things I enjoy about Gentoo is how small the install disk
722 > is, that I can quickly nab 50 megs and burn it in about 5 minutes,
723 > compared to say FC3 and it's 5 CD's. Install disks for Installing,
724 > Recovery disks for Recovery :) There are a lot of CD's that are great
725 > for recovery ( albiet I will admit not many for alt arches ). No one
726 > is stopping you from rolling your own debian variation that runs on
727 > multiplatform. I'm all for more tools that make the install easier,
728 > but space is at a premium, especially with gentoo-installer and X on
729 > the liveCD ( when is that coming out *grin* ). --
730 > gentoo-dev@g.o mailing list
731 >
732 > ------------------------------------------------------------------------
733 >
734 > Subject:
735 > Re: [gentoo-dev] Gentoo @ LinuxTag 2005?
736 > From:
737 > Andrew Cowie <andrew@×××××××××××××××××××.com>
738 > Date:
739 > Tue, 15 Mar 2005 13:53:54 +1100
740 > To:
741 > gentoo-dev@××××××××××××.org
742 >
743 > To:
744 > gentoo-dev@××××××××××××.org
745 >
746 >
747 >On Tue, 2005-15-03 at 03:20 +0100, Lars Weiler wrote:
748 >
749 >
750 >
751 >>By the way: We drank beer together, did we also signed keys? ;-)
752 >>
753 >>
754 >
755 >No, we never got around to it :) [Though I did sign karltk and spider
756 >when I was at GUADEC the following week]
757 >
758 >
759 >
760 >>installing Gentoo on a HP
761 >>Quad-Opteron
762 >>
763 >>
764 >
765 >That was *very* cool.
766 >
767 >++
768 >
769 >Just wanted to encourage everyone to attend the conference, as opposed
770 >to just the expo. The trade-show booths are ok, but the speakers were,
771 >in general, very good, and that (to me, anyway) is the interesting part
772 >about a technical conference. Indeed, most of the conferences I go to /
773 >speak at don't *have* booths.
774 >
775 >AfC
776 >Sydney
777 >
778 >
779 >
780 >
781 > ------------------------------------------------------------------------
782 >
783 > Subject:
784 > Re: [gentoo-dev] Partimage on the livecd
785 > From:
786 > Christian Zoffoli <xmerlin@g.o>
787 > Date:
788 > Tue, 15 Mar 2005 04:07:52 +0100
789 > To:
790 > gentoo-dev@××××××××××××.org
791 >
792 > To:
793 > gentoo-dev@××××××××××××.org
794 >
795 >
796 > Alec Warner wrote:
797 > [cut]
798 >
799 >> One of the things I enjoy about Gentoo is how small the install disk
800 >> is, that I can quickly nab 50 megs and burn it in about 5 minutes,
801 >> compared to say FC3 and it's 5 CD's. Install disks for Installing,
802 >> Recovery disks for Recovery :) There are a lot of CD's that are
803 >> great for recovery ( albiet I will admit not many for alt arches ).
804 >> No one is stopping you from rolling your own debian variation that
805 >> runs on multiplatform. I'm all for more tools that make the install
806 >> easier, but space is at a premium, especially with gentoo-installer
807 >> and X on the liveCD ( when is that coming out *grin* ). --
808 >> gentoo-dev@g.o mailing list
809 >
810 >
811 > but I'm talking about adding a couple of MB of tools, it's not
812 > comparable to X + ....
813 >
814 > Christian
815 >
816 >
817 >
818 >
819 >
820 >
821 > --
822 > gentoo-dev@g.o mailing list
823 >
824 > ------------------------------------------------------------------------
825 >
826 > Subject:
827 > Re: [gentoo-dev] Partimage on the livecd
828 > From:
829 > Donnie Berkholz <spyderous@g.o>
830 > Date:
831 > Mon, 14 Mar 2005 20:17:48 -0800
832 > To:
833 > gentoo-dev@××××××××××××.org
834 >
835 > To:
836 > gentoo-dev@××××××××××××.org
837 >
838 >
839 >-----BEGIN PGP SIGNED MESSAGE-----
840 >Hash: SHA1
841 >
842 >Christian Zoffoli wrote:
843 >
844 >
845 >>but I'm talking about adding a couple of MB of tools, it's not
846 >>comparable to X + ....
847 >>
848 >>
849 >
850 >Slippery slope. A couple MB here, a couple there ... suddenly the
851 >minimal CD that Chris has worked so hard to drop size from is bloated up
852 >again.
853 >-----BEGIN PGP SIGNATURE-----
854 >Version: GnuPG v1.4.0 (GNU/Linux)
855 >
856 >iD8DBQFCNmHsXVaO67S1rtsRAsm6AJ9S3SknpIXSbZuxKa2IQA9T4LEzAACgzYYK
857 >M8wFq04JHKK077hgZg23zos=
858 >=74HI
859 >-----END PGP SIGNATURE-----
860 >--
861 >gentoo-dev@g.o mailing list
862 >
863 >
864 >
865 > ------------------------------------------------------------------------
866 >
867 > Subject:
868 > Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'
869 > From:
870 > Brian Jackson <iggy@g.o>
871 > Date:
872 > Mon, 14 Mar 2005 22:24:24 -0600
873 > To:
874 > gentoo-dev@××××××××××××.org
875 >
876 > To:
877 > gentoo-dev@××××××××××××.org
878 > CC:
879 > gentoo-dev@××××××××××××.org
880 >
881 >
882 >On Mon, 2005-03-14 at 13:21 -0800, Donnie Berkholz wrote:
883 >
884 >
885 >>-----BEGIN PGP SIGNED MESSAGE-----
886 >>Hash: SHA1
887 >>
888 >>Vitaly Ivanov wrote:
889 >>
890 >>
891 >>>I found the comments of Nicholas Jones in bug
892 >>>http://bugs.gentoo.org/show_bug.cgi?id=52415
893 >>>
894 >>>
895 >>>>>Portage makes the assumption that if you're installing
896 >>>>>into a new root, then you're building a system and
897 >>>>>shouldn't bother with config protection. It's not
898 >>>>>documented either way, so it's undefined behavior.
899 >>>>>
900 >>>>>
901 >>I disagree with that logic, because people may be maintaining systems in
902 >>a ROOT with modified config files. Updating those systems trashes the
903 >>files. Thank you for pointing out this behavior now, because it walks
904 >>all over plans I have for a diskless cluster.
905 >>
906 >>
907 >
908 >I mentioned this to the portage guys the other day. Either they didn't
909 >care, or they didn't hear me. Either way, probably need to file a bug
910 >about it (or stir up that other one).
911 >
912 >--Iggy
913 >
914 >--
915 >gentoo-dev@g.o mailing list
916 >
917 >
918 >
919 > ------------------------------------------------------------------------
920 >
921 > Subject:
922 > Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'
923 > From:
924 > Brian Jackson <iggy@g.o>
925 > Date:
926 > Mon, 14 Mar 2005 22:24:24 -0600
927 > To:
928 > gentoo-dev@g.o
929 >
930 > To:
931 > gentoo-dev@g.o
932 > CC:
933 > gentoo-dev@××××××××××××.org
934 >
935 >
936 >On Mon, 2005-03-14 at 13:21 -0800, Donnie Berkholz wrote:
937 >
938 >
939 >>-----BEGIN PGP SIGNED MESSAGE-----
940 >>Hash: SHA1
941 >>
942 >>Vitaly Ivanov wrote:
943 >>
944 >>
945 >>>I found the comments of Nicholas Jones in bug
946 >>>http://bugs.gentoo.org/show_bug.cgi?id=52415
947 >>>
948 >>>
949 >>>>>Portage makes the assumption that if you're installing
950 >>>>>into a new root, then you're building a system and
951 >>>>>shouldn't bother with config protection. It's not
952 >>>>>documented either way, so it's undefined behavior.
953 >>>>>
954 >>>>>
955 >>I disagree with that logic, because people may be maintaining systems in
956 >>a ROOT with modified config files. Updating those systems trashes the
957 >>files. Thank you for pointing out this behavior now, because it walks
958 >>all over plans I have for a diskless cluster.
959 >>
960 >>
961 >
962 >I mentioned this to the portage guys the other day. Either they didn't
963 >care, or they didn't hear me. Either way, probably need to file a bug
964 >about it (or stir up that other one).
965 >
966 >--Iggy
967 >
968 >--
969 >gentoo-dev@g.o mailing list
970 >
971 >
972 >
973 > ------------------------------------------------------------------------
974 >
975 > Subject:
976 > Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'
977 > From:
978 > Georgi Georgiev <chutz@×××.net>
979 > Date:
980 > Tue, 15 Mar 2005 15:56:00 +0900
981 > To:
982 > gentoo-dev@××××××××××××.org
983 >
984 > To:
985 > gentoo-dev@××××××××××××.org
986 >
987 >
988 >maillog: 14/03/2005-22:24:24(-0600): Brian Jackson types
989 >
990 >
991 >>On Mon, 2005-03-14 at 13:21 -0800, Donnie Berkholz wrote:
992 >>
993 >>
994 >>>Vitaly Ivanov wrote:
995 >>>
996 >>>
997 >>>>I found the comments of Nicholas Jones in bug
998 >>>>http://bugs.gentoo.org/show_bug.cgi?id=52415
999 >>>>
1000 >>>>
1001 >>>>>>Portage makes the assumption that if you're installing
1002 >>>>>>into a new root, then you're building a system and
1003 >>>>>>shouldn't bother with config protection. It's not
1004 >>>>>>documented either way, so it's undefined behavior.
1005 >>>>>>
1006 >>>>>>
1007 >>>I disagree with that logic, because people may be maintaining systems in
1008 >>>a ROOT with modified config files. Updating those systems trashes the
1009 >>>files. Thank you for pointing out this behavior now, because it walks
1010 >>>all over plans I have for a diskless cluster.
1011 >>>
1012 >>>
1013 >>I mentioned this to the portage guys the other day. Either they didn't
1014 >>care, or they didn't hear me. Either way, probably need to file a bug
1015 >>about it (or stir up that other one).
1016 >>
1017 >>
1018 >
1019 >Alright! The bug is getting attention, and it even hasn't been a year!
1020 >
1021 >I posted a patch at http://bugs.gentoo.org/show_bug.cgi?id=52415 that
1022 >addresses the issue. You can directly do
1023 >
1024 >wget http://bugs.gentoo.org/attachment.cgi?id=53496 -O - | patch -p0
1025 >
1026 >which will in turn screw your portage.py, but hopefully for the best.
1027 >
1028 >As I see that there are more people who are interested in the bug, I am
1029 >expecting at least some to trust me enough as to try out the patch and
1030 >in turn make some noise (yeah, noise is what we need) when it makes them
1031 >happy.
1032 >
1033 >The other problem that bothers me (that is: reading configuration
1034 >files from $ROOT) seems to be worked on. At least, there are
1035 >comments like:
1036 >
1037 > # XXX: This should depend on ROOT?
1038 > if os.path.exists("/"+CUSTOM_PROFILE_PATH):
1039 > self.user_profile_dir = os.path.normpath("/"+"///"+CUSTOM_PROFILE_PATH)
1040 > self.profiles.append(self.user_profile_dir[:])
1041 >
1042 >...
1043 >
1044 > # XXX: Should depend on root?
1045 > self.mygcfg=getconfig("/"+MAKE_CONF_FILE,allow_sourcing=True)
1046 > if self.mygcfg == None:
1047 > self.mygcfg = {}
1048 >
1049 >
1050 >Which I guess means that it will sooner or later make it to the next
1051 >level in some form.
1052 >
1053 >chutz out
1054 >
1055 >
1056 >
1057 >
1058 > ------------------------------------------------------------------------
1059 >
1060 > Subject:
1061 > Re: [gentoo-dev] initialisation order in checkfs
1062 > From:
1063 > tchiwam <tchiwam@g.o>
1064 > Date:
1065 > Tue, 15 Mar 2005 09:51:34 +0200
1066 > To:
1067 > gentoo-dev@××××××××××××.org
1068 >
1069 > To:
1070 > gentoo-dev@××××××××××××.org
1071 >
1072 >
1073 > Thomas Wöckinger wrote:
1074 >
1075 >> Hi!
1076 >>
1077 >> This is just a hint for changing the initialisation order in checkfs.
1078 >> Currently lvm will be initialized before sw-raid. So it is not
1079 >> possible to set up lvm on a raid device during the boot procedure,
1080 >> therefore i think it is a good idea to change the initialization order
1081 >> to evms -- raid -- lvm
1082 >
1083 >
1084 > In theory many permutations are possible, even if not reasonable. But
1085 > I have found that raid can automount with type fd on x86 partition
1086 > type. On most of the other arch passing md=0,/dev/hda1,/dev/hdb1 to
1087 > the kernel will autostart your raid. Once that is done lvm will be
1088 > happy on your raid partition.
1089 >
1090 > I do like the idea of booting on some raid partitions with most
1091 > journaled FS it needs to be rw.
1092 >
1093 > I am watching lvm as it might become one of the best overall solution
1094 > including raid in a same wrapper.
1095 >
1096 > Phil
1097 > --
1098 > gentoo-dev@g.o mailing list
1099 >
1100 > ------------------------------------------------------------------------
1101 >
1102 > Subject:
1103 > Re: [gentoo-dev] GLEP 34: Per-Category metadata.xml Files
1104 > From:
1105 > Sven Vermeulen <swift@g.o>
1106 > Date:
1107 > Tue, 15 Mar 2005 09:59:31 +0100
1108 > To:
1109 > gentoo-dev@××××××××××××.org
1110 >
1111 > To:
1112 > gentoo-dev@××××××××××××.org
1113 >
1114 >
1115 > Ciaran McCreesh wrote:
1116 > [...]
1117 >
1118 >> It is proposed that the existing ``metadata.xml`` format [1]_ be used.
1119 >> Even though XML sucks, there is already a framework in place for these
1120 >> files. The filename will be ``blah-misc/metadata.xml``. The
1121 >> character set
1122 >> used shall be UTF-8 for consistency with GLEP 31 [2]_.
1123 >
1124 >
1125 > Perhaps you might want to remove any subjective opinions from the
1126 > GLEP. Specifically, "XML sucks", since it doesn't suck. People just
1127 > abuse it too much.
1128 >
1129 > Wkr,
1130 > Sven Vermeulen
1131 >
1132 >
1133 > ------------------------------------------------------------------------
1134 >
1135 > Subject:
1136 > Re: [gentoo-dev] whitelisting the env ebuilds execute in
1137 > From:
1138 > Sven Vermeulen <swift@g.o>
1139 > Date:
1140 > Tue, 15 Mar 2005 10:03:18 +0100
1141 > To:
1142 > gentoo-dev@××××××××××××.org
1143 >
1144 > To:
1145 > gentoo-dev@××××××××××××.org
1146 >
1147 >
1148 > Ned Ludd wrote:
1149 >
1150 >> So it will be something like $PORTDIR/profiles/env.accept.list in
1151 >> which all devs should be able to add to as needed vs having to file
1152 >> bugs and
1153 >> wait for long periods of time?
1154 >
1155 >
1156 > With an IREQUEST="ALSA_CARDS" for additional, per-ebuild variables?
1157 >
1158 >
1159 > ------------------------------------------------------------------------
1160 >
1161 > Subject:
1162 > Re: [gentoo-dev] apache and ~arch
1163 > From:
1164 > Sven Vermeulen <swift@g.o>
1165 > Date:
1166 > Tue, 15 Mar 2005 10:08:42 +0100
1167 > To:
1168 > gentoo-dev@××××××××××××.org
1169 >
1170 > To:
1171 > gentoo-dev@××××××××××××.org
1172 >
1173 >
1174 > Marius Mauch wrote:
1175 >
1176 >> http://planet.gentoo.org/developers/hollow/2005/03/14/apache_dithering
1177 >> "... and users using testing may not complain if things break."
1178 >>
1179 >> That's the real problem.
1180 >
1181 >
1182 > They *should* complain, constructively, on a bugreport, stating the
1183 > issue and how they could resolve it. If people wouldn't be allowed to
1184 > reply to ~arch bugs, then why do we have ~arch?
1185 >
1186 >
1187 > ------------------------------------------------------------------------
1188 >
1189 > Subject:
1190 > [gentoo-dev] kernel sources updating
1191 > From:
1192 > "Evgeny A. Grebennikov" <evgeniy@×××××××.ru>
1193 > Date:
1194 > Tue, 15 Mar 2005 12:11:32 +0300
1195 > To:
1196 > gentoo-dev@××××××××××××.org
1197 >
1198 > To:
1199 > gentoo-dev@××××××××××××.org
1200 >
1201 >
1202 >Hello gentoo-dev,
1203 > I have a question about updating kernel sources. I have to download
1204 > kernel sources every time kernel version is up (using portage system),
1205 > but here is a small patches at kernel.org for updating sources without
1206 > full download.
1207 > In my opinion it's more rationally to realize kernel sources updating
1208 > with patching method. If it's not so, please explain me why?
1209 > Thanks.
1210 >
1211 >
1212 >
1213 > ------------------------------------------------------------------------
1214 >
1215 > Subject:
1216 > Re: [gentoo-dev] initialisation oder in checkfs
1217 > From:
1218 > Martin Schlemmer <azarah@g.o>
1219 > Date:
1220 > Tue, 15 Mar 2005 11:20:07 +0200
1221 > To:
1222 > gentoo-dev@××××××××××××.org
1223 >
1224 > To:
1225 > gentoo-dev@××××××××××××.org
1226 >
1227 >
1228 >On Mon, 2005-03-14 at 22:34 +0100, Thomas Wöckinger wrote:
1229 >
1230 >
1231 >>Hi!
1232 >>
1233 >>This is just a hint for changing the initialisation order in checkfs.
1234 >>Currently lvm will be initialized before sw-raid. So it is not
1235 >>possible to set up lvm on a raid device during the boot procedure,
1236 >>therefore i think it is a good idea to change the initialization order
1237 >>to evms -- raid -- lvm
1238 >>
1239 >>
1240 >>
1241 >
1242 >It is currently still masked, but baselayout-1.12.0 (check
1243 >RC_VOLUME_ORDER in /etc/conf.d/rc if you want to dare it) does provide
1244 >you with the option to change the order. You need the latest ~arch of
1245 >all the volume tools as well though.
1246 >
1247 >
1248 >
1249 >
1250 >
1251 >
1252 > ------------------------------------------------------------------------
1253 >
1254 > Subject:
1255 > Re: [gentoo-dev] kernel sources updating
1256 > From:
1257 > "Robin H. Johnson" <robbat2@g.o>
1258 > Date:
1259 > Tue, 15 Mar 2005 01:26:37 -0800
1260 > To:
1261 > gentoo-dev@××××××××××××.org
1262 >
1263 > To:
1264 > gentoo-dev@××××××××××××.org
1265 >
1266 >
1267 >On Tue, Mar 15, 2005 at 12:11:32PM +0300, Evgeny A. Grebennikov wrote:
1268 >
1269 >
1270 >>Hello gentoo-dev,
1271 >> I have a question about updating kernel sources. I have to download
1272 >> kernel sources every time kernel version is up (using portage system),
1273 >> but here is a small patches at kernel.org for updating sources without
1274 >> full download.
1275 >> In my opinion it's more rationally to realize kernel sources updating
1276 >> with patching method. If it's not so, please explain me why?
1277 >>
1278 >>
1279 >Search bugzilla for the discussion on this.
1280 >Additionally, see this blog posting about a workaround for the meantime:
1281 >http://www.reactivated.net/weblog/archives/2005/03/using-getdelta-to-reduce-size-of-distfiles-download/
1282 >
1283 >
1284 >
1285 >
1286 >
1287 > ------------------------------------------------------------------------
1288 >
1289 > Subject:
1290 > Re: [gentoo-dev] Partimage on the livecd
1291 > From:
1292 > Sven Vermeulen <swift@g.o>
1293 > Date:
1294 > Tue, 15 Mar 2005 10:43:49 +0100
1295 > To:
1296 > gentoo-dev@××××××××××××.org
1297 >
1298 > To:
1299 > gentoo-dev@××××××××××××.org
1300 >
1301 >
1302 > Donnie Berkholz wrote:
1303 > [... rescue CD with partimage and other tools ...]
1304 >
1305 >> Let us know when you've got it ready. I'm looking forward to it.
1306 >
1307 >
1308 > Please bear in mind that partimage, ghost4linux, g4u and similar
1309 > projects are all rather slow-paced in their development (if not
1310 > stalled indefinitely). And it's not because they're finished - they're
1311 > not.
1312 >
1313 > Wkr,
1314 > Sven Vermeulen
1315 >
1316 >
1317 > ------------------------------------------------------------------------
1318 >
1319 > Subject:
1320 > Re: [gentoo-dev] Gentoo @ LinuxTag 2005?
1321 > From:
1322 > Sebastian Bergmann <sebastian@g.o>
1323 > Date:
1324 > Tue, 15 Mar 2005 10:43:45 +0100
1325 > To:
1326 > gentoo-dev@××××××××××××.org
1327 >
1328 > To:
1329 > gentoo-dev@××××××××××××.org
1330 >
1331 >
1332 >Robin H. Johnson wrote:
1333 >
1334 >
1335 >>I'm going to be there, but I will probably be manning the phpMyAdmin
1336 >>booth in the LAMP area most of the time.
1337 >>
1338 >>
1339 >
1340 > Nice! The LAMP Area [1] will, once again, be the biggest booth on the
1341 > expo. Last year it was at least as big as the HP one.
1342 >
1343 > --
1344 > [1] http://www.lamparea.org/
1345 >
1346 >--
1347 >Sebastian Bergmann http://www.sebastian-bergmann.de/
1348 >GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
1349 >
1350 >
1351 >
1352 > ------------------------------------------------------------------------
1353 >
1354 > Subject:
1355 > Re: [gentoo-dev] GLEP ??: Metapackages
1356 > From:
1357 > Thomas de Grenier de Latour <degrenier@×××××××××××.fr>
1358 > Date:
1359 > Tue, 15 Mar 2005 13:21:16 +0100
1360 > To:
1361 > gentoo-dev@××××××××××××.org
1362 >
1363 > To:
1364 > gentoo-dev@××××××××××××.org
1365 >
1366 >
1367 >Two other very minor drawbacks i've just thought of:
1368 >
1369 > - no easy replacement for the use of virtuals in "use.defaults"
1370 >files (currently, virtual/jre, virtual/opengl and virtual/x11 are
1371 >used in that files)
1372 >
1373 > - no easy replacement for "has_version virtual/something" in
1374 >ebuilds (currently, such statements exists with virtual/emacs,
1375 >virtual/ghc, virtual/php, virtual/os-headers, virtual/jdk, but
1376 >that's in less than 30 ebuilds in the whole tree)
1377 >
1378 >
1379 >
1380 >
1381 > ------------------------------------------------------------------------
1382 >
1383 > Subject:
1384 > Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'
1385 > From:
1386 > "Brian Jackson" <iggy@g.o>
1387 > Date:
1388 > Tue, 15 Mar 2005 08:26:49 -0600
1389 > To:
1390 > gentoo-dev@××××××××××××.org
1391 >
1392 > To:
1393 > gentoo-dev@××××××××××××.org
1394 >
1395 >
1396 >On 12:56:00 am 2005-03-15 Georgi Georgiev <chutz@×××.net> wrote:
1397 >
1398 >
1399 >>maillog: 14/03/2005-22:24:24(-0600): Brian Jackson types
1400 >>
1401 >>
1402 >>> On Mon, 2005-03-14 at 13:21 -0800, Donnie Berkholz wrote:
1403 >>>
1404 >>>
1405 >>>> Vitaly Ivanov wrote:
1406 >>>>
1407 >>>>
1408 >>>>> I found the comments of Nicholas Jones in bug
1409 >>>>> http://bugs.gentoo.org/show_bug.cgi?id=52415
1410 >>>>>
1411 >>>>>
1412 >>>>>>> Portage makes the assumption that if you're installing
1413 >>>>>>> into a new root, then you're building a system and
1414 >>>>>>> shouldn't bother with config protection. It's not
1415 >>>>>>> documented either way, so it's undefined behavior.
1416 >>>>>>>
1417 >>>>>>>
1418 >>>> I disagree with that logic, because people may be maintaining
1419 >>>> systems in a ROOT with modified config files. Updating those
1420 >>>> systems trashes the files. Thank you for pointing out this
1421 >>>> behavior now, because it walks all over plans I have for a
1422 >>>>
1423 >>>>
1424 >>> diskless cluster.
1425 >>> I mentioned this to the portage guys the other day. Either they
1426 >>> didn't care, or they didn't hear me. Either way, probably need to
1427 >>> file a bug about it (or stir up that other one).
1428 >>>
1429 >>>
1430 >>Alright! The bug is getting attention, and it even hasn't been a year!
1431 >>
1432 >>I posted a patch at http://bugs.gentoo.org/show_bug.cgi?id=52415 that
1433 >>addresses the issue. You can directly do
1434 >>
1435 >>wget http://bugs.gentoo.org/attachment.cgi?id=53496 -O - | patch -p0
1436 >>
1437 >>which will in turn screw your portage.py, but hopefully for the best.
1438 >>
1439 >>As I see that there are more people who are interested in the bug, I
1440 >>am expecting at least some to trust me enough as to try out the patch
1441 >>and in turn make some noise (yeah, noise is what we need) when it
1442 >>makes them happy.
1443 >>
1444 >>The other problem that bothers me (that is: reading configuration
1445 >>files from $ROOT) seems to be worked on. At least, there are
1446 >>comments like:
1447 >>
1448 >>
1449 >
1450 >I have a bug filed for that too, but it's probably going to be a while
1451 >before it's fixed. From what I've been told, it's not trivial to fix it
1452 >because some of the config stuff isn't very well abstracted.
1453 >
1454 >http://bugs.gentoo.org/show_bug.cgi?id=73350
1455 >
1456 >--Iggy
1457 >
1458 >
1459 >
1460 >> # XXX: This should depend on ROOT?
1461 >> if os.path.exists("/"+CUSTOM_PROFILE_PATH):
1462 >> self.user_profile_dir = os.path.normpath("/"+"///"+CUSTOM_PROF
1463 >>ILE_PATH)
1464 >> self.profiles.append(self.user_profile_dir[:])
1465 >>
1466 >>...
1467 >>
1468 >> # XXX: Should depend on root?
1469 >> self.mygcfg=getconfig("/"+MAKE_CONF_FILE,allow_sourcing=True)
1470 >> if self.mygcfg == None:
1471 >> self.mygcfg = {}
1472 >>
1473 >>
1474 >>Which I guess means that it will sooner or later make it to the next
1475 >>level in some form.
1476 >>
1477 >>chutz out
1478 >>
1479 >>
1480 >
1481 >--
1482 >gentoo-dev@g.o mailing list
1483 >
1484 >
1485 >
1486 > ------------------------------------------------------------------------
1487 >
1488 > Subject:
1489 > Re: [gentoo-dev] apache and ~arch
1490 > From:
1491 > Ciaran McCreesh <ciaranm@g.o>
1492 > Date:
1493 > Tue, 15 Mar 2005 15:20:34 +0000
1494 > To:
1495 > gentoo-dev@××××××××××××.org
1496 >
1497 > To:
1498 > gentoo-dev@××××××××××××.org
1499 >
1500 >
1501 >On Tue, 15 Mar 2005 10:08:42 +0100 Sven Vermeulen <swift@g.o>
1502 >wrote:
1503 >| Marius Mauch wrote:
1504 >| > http://planet.gentoo.org/developers/hollow/2005/03/14/apache_dithering
1505 >| > "... and users using testing may not complain if things break."
1506 >| >
1507 >| > That's the real problem.
1508 >|
1509 >| They *should* complain, constructively, on a bugreport, stating the
1510 >| issue and how they could resolve it. If people wouldn't be allowed to
1511 >| reply to ~arch bugs, then why do we have ~arch?
1512 >
1513 >We have ~arch for things that aren't well tested but aren't believed to
1514 >be broken. So, some midpoint is needed on the ~arch being broken thing.
1515 >On the one hand, it's not suitable for running on production kit, so
1516 >complaints about things which aren't known to be broken being added to
1517 >~arch aren't particularly viable. On the other hand, constructive useful
1518 >bug reports about breakages in ~arch that the maintainer doesn't know
1519 >about *are* useful, since they'll let the maintainer know that the
1520 >package isn't ready to go stable.
1521 >
1522 >Probably easiest to think of ~arch as meaning "candidate for arch after
1523 >more testing".
1524 >
1525 >
1526 >
1527 >
1528 > ------------------------------------------------------------------------
1529 >
1530 > Subject:
1531 > Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'
1532 > From:
1533 > Georgi Georgiev <chutz@×××.net>
1534 > Date:
1535 > Wed, 16 Mar 2005 01:14:14 +0900
1536 > To:
1537 > gentoo-dev@××××××××××××.org
1538 >
1539 > To:
1540 > gentoo-dev@××××××××××××.org
1541 >
1542 >
1543 >maillog: 15/03/2005-08:26:49(-0600): Brian Jackson types
1544 >
1545 >
1546 >>On 12:56:00 am 2005-03-15 Georgi Georgiev <chutz@×××.net> wrote:
1547 >>
1548 >>
1549 >>>maillog: 14/03/2005-22:24:24(-0600): Brian Jackson types
1550 >>>
1551 >>>
1552 >>>> On Mon, 2005-03-14 at 13:21 -0800, Donnie Berkholz wrote:
1553 >>>>
1554 >>>>
1555 >>>>> Vitaly Ivanov wrote:
1556 >>>>>
1557 >>>>>
1558 >>>>>> I found the comments of Nicholas Jones in bug
1559 >>>>>> http://bugs.gentoo.org/show_bug.cgi?id=52415
1560 >>>>>>
1561 >>>>>>
1562 >>>>>>>> Portage makes the assumption that if you're installing
1563 >>>>>>>> into a new root, then you're building a system and
1564 >>>>>>>> shouldn't bother with config protection. It's not
1565 >>>>>>>> documented either way, so it's undefined behavior.
1566 >>>>>>>>
1567 >>>>>>>>
1568 >>>>> I disagree with that logic, because people may be maintaining
1569 >>>>> systems in a ROOT with modified config files. Updating those
1570 >>>>> systems trashes the files. Thank you for pointing out this
1571 >>>>> behavior now, because it walks all over plans I have for a
1572 >>>>>
1573 >>>>>
1574 >>>> diskless cluster.
1575 >>>> I mentioned this to the portage guys the other day. Either they
1576 >>>> didn't care, or they didn't hear me. Either way, probably need to
1577 >>>> file a bug about it (or stir up that other one).
1578 >>>>
1579 >>>>
1580 >>>Alright! The bug is getting attention, and it even hasn't been a year!
1581 >>>
1582 >>>I posted a patch at http://bugs.gentoo.org/show_bug.cgi?id=52415 that
1583 >>>addresses the issue. You can directly do
1584 >>>
1585 >>>wget http://bugs.gentoo.org/attachment.cgi?id=53496 -O - | patch -p0
1586 >>>
1587 >>>which will in turn screw your portage.py, but hopefully for the best.
1588 >>>
1589 >>>As I see that there are more people who are interested in the bug, I
1590 >>>am expecting at least some to trust me enough as to try out the patch
1591 >>>and in turn make some noise (yeah, noise is what we need) when it
1592 >>>makes them happy.
1593 >>>
1594 >>>The other problem that bothers me (that is: reading configuration
1595 >>>files from $ROOT) seems to be worked on. At least, there are
1596 >>>comments like:
1597 >>>
1598 >>>
1599 >>I have a bug filed for that too, but it's probably going to be a while
1600 >>before it's fixed. From what I've been told, it's not trivial to fix it
1601 >>because some of the config stuff isn't very well abstracted.
1602 >>
1603 >>
1604 >
1605 >It isn't? Are we talking about the same thing? After all, the locations
1606 >are just variables, that only need to be prefixed with something. Could
1607 >we get some input from whoever told you this?
1608 >
1609 >
1610 >
1611 >>http://bugs.gentoo.org/show_bug.cgi?id=73350
1612 >>
1613 >>
1614 >
1615 >
1616 >
1617 >
1618 > ------------------------------------------------------------------------
1619 >
1620 > Subject:
1621 > Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'
1622 > From:
1623 > "Brian Jackson" <iggy@g.o>
1624 > Date:
1625 > Tue, 15 Mar 2005 12:01:47 -0600
1626 > To:
1627 > gentoo-dev@××××××××××××.org
1628 >
1629 > To:
1630 > gentoo-dev@××××××××××××.org
1631 >
1632 >
1633 >On 10:14:14 am 2005-03-15 Georgi Georgiev <chutz@×××.net> wrote:
1634 >
1635 >
1636 >>maillog: 15/03/2005-08:26:49(-0600): Brian Jackson types
1637 >>
1638 >>
1639 >>> On 12:56:00 am 2005-03-15 Georgi Georgiev <chutz@×××.net> wrote:
1640 >>>
1641 >>>
1642 >>>> maillog: 14/03/2005-22:24:24(-0600): Brian Jackson types
1643 >>>>
1644 >>>>
1645 >>>>> On Mon, 2005-03-14 at 13:21 -0800, Donnie Berkholz wrote:
1646 >>>>>
1647 >>>>>
1648 >>>>>> Vitaly Ivanov wrote:
1649 >>>>>>
1650 >>>>>>
1651 >>>>>>> I found the comments of Nicholas Jones in bug
1652 >>>>>>> http://bugs.gentoo.org/show_bug.cgi?id=52415
1653 >>>>>>>
1654 >>>>>>>
1655 >>>>>>>>> Portage makes the assumption that if you're installing
1656 >>>>>>>>> into a new root, then you're building a system and
1657 >>>>>>>>> shouldn't bother with config protection. It's not
1658 >>>>>>>>> documented either way, so it's undefined behavior.
1659 >>>>>>>>>
1660 >>>>>>>>>
1661 >>>>>> I disagree with that logic, because people may be
1662 >>>>>> maintaining systems in a ROOT with modified config files.
1663 >>>>>> Updating those systems trashes the files. Thank you for
1664 >>>>>> pointing out this behavior now, because it walks all over
1665 >>>>>>
1666 >>>>>>
1667 >>>>> plans I have for a diskless cluster.
1668 >>>>> I mentioned this to the portage guys the other day. Either
1669 >>>>> they didn't care, or they didn't hear me. Either way,
1670 >>>>> probably need to file a bug about it (or stir up that other
1671 >>>>>
1672 >>>>>
1673 >>>>one).
1674 >>>> Alright! The bug is getting attention, and it even hasn't been a
1675 >>>>year!
1676 >>>> I posted a patch at http://bugs.gentoo.org/show_bug.cgi?id=52415
1677 >>>> that addresses the issue. You can directly do
1678 >>>>
1679 >>>> wget http://bugs.gentoo.org/attachment.cgi?id=53496 -O - | patch
1680 >>>>-p0
1681 >>>> which will in turn screw your portage.py, but hopefully for the
1682 >>>>best.
1683 >>>> As I see that there are more people who are interested in the
1684 >>>> bug, I am expecting at least some to trust me enough as to try
1685 >>>> out the patch and in turn make some noise (yeah, noise is what
1686 >>>> we need) when it makes them happy.
1687 >>>>
1688 >>>> The other problem that bothers me (that is: reading configuration
1689 >>>> files from $ROOT) seems to be worked on. At least, there are
1690 >>>> comments like:
1691 >>>>
1692 >>>>
1693 >>> I have a bug filed for that too, but it's probably going to be a
1694 >>> while before it's fixed. From what I've been told, it's not
1695 >>> trivial to fix it because some of the config stuff isn't very well
1696 >>>
1697 >>>
1698 >>abstracted.
1699 >>
1700 >>It isn't? Are we talking about the same thing? After all, the
1701 >>locations are just variables, that only need to be prefixed with
1702 >>something. Could we get some input from whoever told you this?
1703 >>
1704 >>
1705 >
1706 >make.conf is easy. The profile isn't as easy. /etc/portage isn't easy at
1707 >all. That's the basics. You'd have to ask the portage guys for more in
1708 >depth info.
1709 >
1710 >--Iggy
1711 >
1712 >
1713 >
1714 >>> http://bugs.gentoo.org/show_bug.cgi?id=73350
1715 >>>
1716 >>>
1717 >
1718 >--
1719 >gentoo-dev@g.o mailing list
1720 >
1721 >
1722 >
1723 > ------------------------------------------------------------------------
1724 >
1725 > Subject:
1726 > Re: [gentoo-dev] Partimage on the livecd
1727 > From:
1728 > Chris Gianelloni <wolf31o2@g.o>
1729 > Date:
1730 > Tue, 15 Mar 2005 14:30:23 -0500
1731 > To:
1732 > gentoo-dev@××××××××××××.org
1733 >
1734 > To:
1735 > gentoo-dev@××××××××××××.org
1736 >
1737 >
1738 >On Mon, 2005-03-14 at 21:38 -0500, Alec Warner wrote:
1739 >
1740 >
1741 >>One of the things I enjoy about Gentoo is how small the install disk is,
1742 >>that I can quickly nab 50 megs and burn it in about 5 minutes, compared
1743 >>to say FC3 and it's 5 CD's. Install disks for Installing, Recovery
1744 >>disks for Recovery :) There are a lot of CD's that are great for
1745 >>
1746 >>
1747 >
1748 >This is pretty much our driving force. The Release Engineering group is
1749 >only interested in building release materials. It isn't our job to care
1750 >about backup/recovery, really. You are more than free to create your
1751 >own recovery CD for any architecture you want, and we'll even help you
1752 >with any problems you have. That being said, we are not going to add
1753 >more packages to the installation media. We are looking to reduce the
1754 >size of the media, rather than increase it.
1755 >
1756 >
1757 >
1758 >>recovery ( albiet I will admit not many for alt arches ). No one is
1759 >>stopping you from rolling your own debian variation that runs on
1760 >>
1761 >>
1762 >
1763 >Why bother with Debian? You could use catalyst and do it all from
1764 >Gentoo.
1765 >
1766 >
1767 >
1768 >>multiplatform. I'm all for more tools that make the install easier, but
1769 >>space is at a premium, especially with gentoo-installer and X on the
1770 >>liveCD ( when is that coming out *grin* ).
1771 >>
1772 >>
1773 >
1774 >Never. *grin*
1775 >
1776 >I guess this is where I give my standard answer. The experimental
1777 >LiveCD, which has no real ties to the actual 2005.0 release, will be
1778 >done when it is done, and will be released shortly after that. ;]
1779 >
1780 >
1781 >
1782 >
1783 > ------------------------------------------------------------------------
1784 >
1785 > Subject:
1786 > [gentoo-dev] KDE split ebuilds
1787 > From:
1788 > Tom Wesley <tom@×××××.org>
1789 > Date:
1790 > Tue, 15 Mar 2005 19:25:29 +0000
1791 > To:
1792 > gentoo-dev <gentoo-dev@l.g.o>
1793 >
1794 > To:
1795 > gentoo-dev <gentoo-dev@l.g.o>
1796 >
1797 >
1798 > Hey
1799 >
1800 > I've seen several queries regarding KDE's new split ebuilds and the
1801 > version numbers used for specific packages. It seems that all of the
1802 > KDE 3.4 packages have been versioned as 3.4.
1803 >
1804 > Should kmail, kopete etc not be using their own version numbers with
1805 > the meta-packages being versioned based on the kde release number?
1806 > IMO this would make more sense, especially when reading the kopete
1807 > website, finding the latest version is 0.9.2 and then noticing that
1808 > portage only has 3.4.
1809 >
1810 >
1811 > ------------------------------------------------------------------------
1812 >
1813 > Subject:
1814 > Re: [gentoo-dev] Partimage on the livecd
1815 > From:
1816 > Chris Gianelloni <wolf31o2@g.o>
1817 > Date:
1818 > Tue, 15 Mar 2005 14:32:38 -0500
1819 > To:
1820 > gentoo-dev@××××××××××××.org
1821 >
1822 > To:
1823 > gentoo-dev@××××××××××××.org
1824 >
1825 >
1826 >On Tue, 2005-03-15 at 04:07 +0100, Christian Zoffoli wrote:
1827 >
1828 >
1829 >>but I'm talking about adding a couple of MB of tools, it's not
1830 >>comparable to X + ....
1831 >>
1832 >>
1833 >
1834 >We're also to the point where we count the size of the installation
1835 >media in bytes. A couple of MB of additional space requirements that
1836 >will only be used by a very small percentage of our user base (I would
1837 >say less than 1%) and that has nothing to do with installation is
1838 >unnecessary.
1839 >
1840 >
1841 >
1842 >
1843 > ------------------------------------------------------------------------
1844 >
1845 > Subject:
1846 > Re: [gentoo-dev] Partimage on the livecd
1847 > From:
1848 > Chris Gianelloni <wolf31o2@g.o>
1849 > Date:
1850 > Tue, 15 Mar 2005 14:35:02 -0500
1851 > To:
1852 > gentoo-dev@××××××××××××.org
1853 >
1854 > To:
1855 > gentoo-dev@××××××××××××.org
1856 >
1857 >
1858 >On Mon, 2005-03-14 at 20:17 -0800, Donnie Berkholz wrote:
1859 >
1860 >
1861 >>Slippery slope. A couple MB here, a couple there ... suddenly the
1862 >>minimal CD that Chris has worked so hard to drop size from is bloated up
1863 >>again.
1864 >>
1865 >>
1866 >
1867 >Exactly.
1868 >
1869 >Nevermind that we've added about 10MB to this release already. Of
1870 >course, that is to add better support for lvm2 and dmraid, plus a bunch
1871 >of extra network drivers. These are things that would be used during an
1872 >installation, so they fit the requirements, but one of my first tasks
1873 >after this release is to start working towards reducing the size of the
1874 >minimal install CD (again). My personal goal is to fit the entire
1875 >contents of the CD on a 32MB USB key.
1876 >
1877 >
1878 >
1879 >
1880 > ------------------------------------------------------------------------
1881 >
1882 > Subject:
1883 > Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'
1884 > From:
1885 > Georgi Georgiev <chutz@×××.net>
1886 > Date:
1887 > Wed, 16 Mar 2005 08:05:43 +0900
1888 > To:
1889 > gentoo-dev@××××××××××××.org
1890 >
1891 > To:
1892 > gentoo-dev@××××××××××××.org
1893 >
1894 >
1895 >maillog: 15/03/2005-12:01:47(-0600): Brian Jackson types
1896 >
1897 >
1898 >>On 10:14:14 am 2005-03-15 Georgi Georgiev <chutz@×××.net> wrote:
1899 >>
1900 >>
1901 >>>maillog: 15/03/2005-08:26:49(-0600): Brian Jackson types
1902 >>>
1903 >>>
1904 >>>> I have a bug filed for that too, but it's probably going to be a
1905 >>>> while before it's fixed. From what I've been told, it's not
1906 >>>> trivial to fix it because some of the config stuff isn't very
1907 >>>> well abstracted.
1908 >>>>
1909 >>>>
1910 >>>It isn't? Are we talking about the same thing? After all, the
1911 >>>locations are just variables, that only need to be prefixed with
1912 >>>something. Could we get some input from whoever told you this?
1913 >>>
1914 >>>
1915 >>make.conf is easy. The profile isn't as easy. /etc/portage isn't easy
1916 >>at all. That's the basics. You'd have to ask the portage guys for more
1917 >>in depth info.
1918 >>
1919 >>
1920 >
1921 >I was hoping to get a response from them here. Portage guys, you there?
1922 >
1923 >
1924 >
1925 >
1926 > ------------------------------------------------------------------------
1927 >
1928 > Subject:
1929 > Re: [gentoo-dev] Partimage on the livecd
1930 > From:
1931 > Christian Zoffoli <xmerlin@g.o>
1932 > Date:
1933 > Wed, 16 Mar 2005 00:10:09 +0100
1934 > To:
1935 > gentoo-dev@××××××××××××.org
1936 >
1937 > To:
1938 > gentoo-dev@××××××××××××.org
1939 >
1940 >
1941 > Chris Gianelloni wrote:
1942 >
1943 >> On Tue, 2005-03-15 at 04:07 +0100, Christian Zoffoli wrote:
1944 >>
1945 >>> but I'm talking about adding a couple of MB of tools, it's not
1946 >>> comparable to X + ....
1947 >>
1948 >>
1949 >>
1950 >> We're also to the point where we count the size of the installation
1951 >> media in bytes. A couple of MB of additional space requirements that
1952 >> will only be used by a very small percentage of our user base (I would
1953 >> say less than 1%) and that has nothing to do with installation is
1954 >> unnecessary.
1955 >
1956 >
1957 > ok ok
1958 > ...the right way is the second one ...create another live cd only for
1959 > recovering ;-)
1960 >
1961 >
1962 > Christian
1963 > --
1964 > gentoo-dev@g.o mailing list
1965 >
1966 > ------------------------------------------------------------------------
1967 >
1968 > Subject:
1969 > Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'
1970 > From:
1971 > Brian Harring <ferringb@g.o>
1972 > Date:
1973 > Tue, 15 Mar 2005 21:17:26 -0600
1974 > To:
1975 > gentoo-dev@××××××××××××.org
1976 >
1977 > To:
1978 > gentoo-dev@××××××××××××.org
1979 >
1980 >
1981 >On Wed, Mar 16, 2005 at 08:05:43AM +0900, Georgi Georgiev wrote:
1982 >
1983 >
1984 >>maillog: 15/03/2005-12:01:47(-0600): Brian Jackson types
1985 >>
1986 >>
1987 >>>On 10:14:14 am 2005-03-15 Georgi Georgiev <chutz@×××.net> wrote:
1988 >>>
1989 >>>
1990 >>>>maillog: 15/03/2005-08:26:49(-0600): Brian Jackson types
1991 >>>>
1992 >>>>
1993 >>>>> I have a bug filed for that too, but it's probably going to be a
1994 >>>>> while before it's fixed. From what I've been told, it's not
1995 >>>>> trivial to fix it because some of the config stuff isn't very
1996 >>>>> well abstracted.
1997 >>>>>
1998 >>>>>
1999 >>>>It isn't? Are we talking about the same thing? After all, the
2000 >>>>locations are just variables, that only need to be prefixed with
2001 >>>>something. Could we get some input from whoever told you this?
2002 >>>>
2003 >>>>
2004 >>>make.conf is easy. The profile isn't as easy. /etc/portage isn't easy
2005 >>>at all. That's the basics. You'd have to ask the portage guys for more
2006 >>>in depth info.
2007 >>>
2008 >>>
2009 >>I was hoping to get a response from them here. Portage guys, you there?
2010 >>
2011 >>
2012 >http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/pym/config.py?root=gentoo-src
2013 >^^^^ config class, cleaned up a bit from what stable has.
2014 >
2015 >At the moment, my focus on the bugger is the following-
2016 >A) integration of env whitelist tracking, preferably in a an attached
2017 > instance (the need for this is partially bound to covering
2018 > filter-env's ass).
2019 >B) either reorganize the beast so env stuff is accessible via an
2020 > attribute, or create a container class that the config gets
2021 > assigned into
2022 >C) bind all tree instances to the config. Why? Kill off portage.db
2023 > global usage entirely, and try and encapsulate data into one
2024 > common, passable instance
2025 >D) shift virtual loading, setcpv, setinst, load_infodir, etc, all out
2026 > of config and to a proper class.
2027 >
2028 >So... why tack that stuff in now, when the class itself needs a major
2029 >enema? :)
2030 >
2031 >Basically it comes down to a focus (at this point) in trying to
2032 >improve the existing code/abstractions in use, rather then tacking
2033 >more features/codepaths in.
2034 >
2035 >Anyone interested can take a crack at the request above, it's just not
2036 >high on my peronsal (likely our) list of priorities, since the
2037 >existing code is spaghetti like.
2038 >
2039 >Note that integration of env whitelisting *is* adding a new feature
2040 >in. It's kind of required to keep things sane for the env handling
2041 >though (mainly, a few very crazy var settings are *very* hard to
2042 >properly filter). That and it can't be done without refactoring the
2043 >config class anyways (which is intended)...
2044 >~harring
2045 >--
2046 >gentoo-dev@g.o mailing list
2047 >
2048 >
2049 >
2050 > ------------------------------------------------------------------------
2051 >
2052 > Subject:
2053 > Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'
2054 > From:
2055 > Georgi Georgiev <chutz@×××.net>
2056 > Date:
2057 > Wed, 16 Mar 2005 12:35:55 +0900
2058 > To:
2059 > gentoo-dev@××××××××××××.org
2060 >
2061 > To:
2062 > gentoo-dev@××××××××××××.org
2063 >
2064 >
2065 >maillog: 15/03/2005-21:17:26(-0600): Brian Harring types
2066 >
2067 >
2068 >>On Wed, Mar 16, 2005 at 08:05:43AM +0900, Georgi Georgiev wrote:
2069 >>
2070 >>
2071 >>>maillog: 15/03/2005-12:01:47(-0600): Brian Jackson types
2072 >>>
2073 >>>
2074 >>>>On 10:14:14 am 2005-03-15 Georgi Georgiev <chutz@×××.net> wrote:
2075 >>>>
2076 >>>>
2077 >>>>>maillog: 15/03/2005-08:26:49(-0600): Brian Jackson types
2078 >>>>>
2079 >>>>>
2080 >>>>>> I have a bug filed for that too, but it's probably going to be a
2081 >>>>>> while before it's fixed. From what I've been told, it's not
2082 >>>>>> trivial to fix it because some of the config stuff isn't very
2083 >>>>>> well abstracted.
2084 >>>>>>
2085 >>>>>>
2086 >>>>>It isn't? Are we talking about the same thing? After all, the
2087 >>>>>locations are just variables, that only need to be prefixed with
2088 >>>>>something. Could we get some input from whoever told you this?
2089 >>>>>
2090 >>>>>
2091 >>>>make.conf is easy. The profile isn't as easy. /etc/portage isn't easy
2092 >>>>at all. That's the basics. You'd have to ask the portage guys for more
2093 >>>>in depth info.
2094 >>>>
2095 >>>>
2096 >>>I was hoping to get a response from them here. Portage guys, you there?
2097 >>>
2098 >>>
2099 >>http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/pym/config.py?root=gentoo-src
2100 >>^^^^ config class, cleaned up a bit from what stable has.
2101 >>
2102 >>At the moment, my focus on the bugger is the following-
2103 >>A) integration of env whitelist tracking, preferably in a an attached
2104 >> instance (the need for this is partially bound to covering
2105 >> filter-env's ass).
2106 >>B) either reorganize the beast so env stuff is accessible via an
2107 >> attribute, or create a container class that the config gets
2108 >> assigned into
2109 >>C) bind all tree instances to the config. Why? Kill off portage.db
2110 >> global usage entirely, and try and encapsulate data into one
2111 >> common, passable instance
2112 >>D) shift virtual loading, setcpv, setinst, load_infodir, etc, all out
2113 >> of config and to a proper class.
2114 >>
2115 >>So... why tack that stuff in now, when the class itself needs a major
2116 >>enema? :)
2117 >>
2118 >>Basically it comes down to a focus (at this point) in trying to
2119 >>improve the existing code/abstractions in use, rather then tacking
2120 >>more features/codepaths in.
2121 >>
2122 >>Anyone interested can take a crack at the request above, it's just not
2123 >>high on my peronsal (likely our) list of priorities, since the
2124 >>existing code is spaghetti like.
2125 >>
2126 >>Note that integration of env whitelisting *is* adding a new feature
2127 >>in. It's kind of required to keep things sane for the env handling
2128 >>though (mainly, a few very crazy var settings are *very* hard to
2129 >>properly filter). That and it can't be done without refactoring the
2130 >>config class anyways (which is intended)...
2131 >>
2132 >>
2133 >
2134 >Well, I never intended to rush things... bug #52415 has been open for
2135 >almost an year after all, and at least the config protection seems to be
2136 >more of a bug than a problem with the implementation (as I had posted in
2137 >a comment on the bug, $ROOT/etc/somefile is being checked against a list
2138 >that is not prefixed with a $ROOT).
2139 >
2140 >The issue with the alternate configuration location is only a matter of
2141 >convenience, since it can be worked around with a couple of symlinks.
2142 >As your hands are full with other stuff, I'd only hope you keep the
2143 >request in mind. Maybe even post a note when you guys unknot the
2144 >spaghetti?
2145 >
2146 >
2147 >
2148 >
2149 > ------------------------------------------------------------------------
2150 >
2151 > Subject:
2152 > Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'
2153 > From:
2154 > Brian Harring <ferringb@g.o>
2155 > Date:
2156 > Tue, 15 Mar 2005 22:11:10 -0600
2157 > To:
2158 > gentoo-dev@××××××××××××.org
2159 >
2160 > To:
2161 > gentoo-dev@××××××××××××.org
2162 >
2163 >
2164 >On Wed, Mar 16, 2005 at 12:35:55PM +0900, Georgi Georgiev wrote:
2165 >
2166 >
2167 >>Well, I never intended to rush things...
2168 >>
2169 >>
2170 >Rush isn't necessarily bad. Portage bugs have a way of acruing years
2171 >without action...
2172 >
2173 >
2174 >
2175 >>Maybe even post a note when you guys unknot the
2176 >>spaghetti?
2177 >>
2178 >>
2179 >cvs head is becoming better... help/patches would be wonderful
2180 >however. :):
2181 >~harring
2182 >--
2183 >gentoo-dev@g.o mailing list
2184 >
2185 >
2186 >
2187 > ------------------------------------------------------------------------
2188 >
2189 > Subject:
2190 > [gentoo-dev] categories.desc?
2191 > From:
2192 > marduk <marduk@g.o>
2193 > Date:
2194 > Tue, 15 Mar 2005 22:43:57 -0600
2195 > To:
2196 > gentoo-dev@××××××××××××.org
2197 >
2198 > To:
2199 > gentoo-dev@××××××××××××.org
2200 >
2201 >
2202 >I've been looking for a resource that would give a description of all
2203 >the categories in portage. There is a 'categories' file in portage but
2204 >it has no descriptions. Does such a resource exist and, if not, would
2205 >there be sufficient interest of the portage developers to create one?
2206 >
2207 >thanks in advance,
2208 >-m
2209 >
2210 >
2211 >
2212 >
2213 >
2214 > ------------------------------------------------------------------------
2215 >
2216 > Subject:
2217 > Re: [gentoo-dev] categories.desc?
2218 > From:
2219 > Donnie Berkholz <spyderous@g.o>
2220 > Date:
2221 > Tue, 15 Mar 2005 20:50:21 -0800
2222 > To:
2223 > gentoo-dev@××××××××××××.org
2224 >
2225 > To:
2226 > gentoo-dev@××××××××××××.org
2227 >
2228 >
2229 >-----BEGIN PGP SIGNED MESSAGE-----
2230 >Hash: SHA1
2231 >
2232 >marduk wrote:
2233 >
2234 >
2235 >>I've been looking for a resource that would give a description of all
2236 >>the categories in portage. There is a 'categories' file in portage but
2237 >>it has no descriptions. Does such a resource exist and, if not, would
2238 >>there be sufficient interest of the portage developers to create one?
2239 >>
2240 >>
2241 >
2242 >Perhaps you'd be interested in
2243 >http://www.gentoo.org/proj/en/glep/glep-0034.html
2244 >-----BEGIN PGP SIGNATURE-----
2245 >Version: GnuPG v1.4.0 (GNU/Linux)
2246 >
2247 >iD8DBQFCN7sNXVaO67S1rtsRAvs7AKD1zFSods7qreBgOzYyY+SoIBIr7gCgyReY
2248 >hhBhPodtI7V4gvHbLVWCXLs=
2249 >=ZN19
2250 >-----END PGP SIGNATURE-----
2251 >--
2252 >gentoo-dev@g.o mailing list
2253 >
2254 >
2255 >
2256 > ------------------------------------------------------------------------
2257 >
2258 > Subject:
2259 > [gentoo-dev] giflib and libungif hell
2260 > From:
2261 > Chris White <chriswhite@g.o>
2262 > Date:
2263 > Thu, 17 Mar 2005 00:41:35 +0900
2264 > To:
2265 > gentoo-dev@××××××××××××.org
2266 >
2267 > To:
2268 > gentoo-dev@××××××××××××.org
2269 >
2270 >
2271 > So.. basically:
2272 >
2273 > 1) libungif and giflib both install -lgif
2274 > 2) They don't block each other
2275 > 3) libungif does some weird thing where it deletes the giflib header
2276 > file (probably because they aren't blocking each other?)
2277 >
2278 > So, they pretty much install the same thing... Can I put a blocker on
2279 > this? Or does someone have a valid reason why I shouldn't...
2280 >
2281 >
2282 > ------------------------------------------------------------------------
2283 >
2284 > Subject:
2285 > Re: [gentoo-dev] giflib and libungif hell
2286 > From:
2287 > Mike Frysinger <vapier@g.o>
2288 > Date:
2289 > Wed, 16 Mar 2005 13:59:10 -0500
2290 > To:
2291 > gentoo-dev@××××××××××××.org
2292 >
2293 > To:
2294 > gentoo-dev@××××××××××××.org
2295 >
2296 >
2297 >On Wednesday 16 March 2005 10:41 am, Chris White wrote:
2298 >
2299 >
2300 >>So, they pretty much install the same thing... Can I put a blocker on
2301 >>this? Or does someone have a valid reason why I shouldn't...
2302 >>
2303 >>
2304 >
2305 >going by the description, it seems like libungif is pretty much pointless
2306 >now ? libgd has added back in gif support now that the LZW patent has
2307 >expired everywhere ...
2308 >
2309 >perhaps we can just clean out libungif and have everything use giflib now
2310 >-mike
2311 >--
2312 >gentoo-dev@g.o mailing list
2313 >
2314 >
2315 >
2316 > ------------------------------------------------------------------------
2317 >
2318 > Subject:
2319 > Re: [gentoo-dev] KDE split ebuilds
2320 > From:
2321 > Sven Vermeulen <swift@g.o>
2322 > Date:
2323 > Wed, 16 Mar 2005 20:49:56 +0100
2324 > To:
2325 > gentoo-dev@××××××××××××.org
2326 >
2327 > To:
2328 > gentoo-dev@××××××××××××.org
2329 >
2330 >
2331 > Tom Wesley wrote:
2332 >
2333 >> Should kmail, kopete etc not be using their own version numbers with
2334 >> the meta-packages being versioned based on the kde release number?
2335 >> IMO this would make more sense, especially when reading the kopete
2336 >> website, finding the latest version is 0.9.2 and then noticing that
2337 >> portage only has 3.4.
2338 >
2339 >
2340 > Would that mean individual masks on >= 3.0.0 versions for each of
2341 > these tools? Sounds scary...
2342 >
2343 > Wkr,
2344 > Sven Vermeulen
2345 >
2346 >
2347 > ------------------------------------------------------------------------
2348 >
2349 > Subject:
2350 > [gentoo-dev] KDE 3.4.0; reminder - there are split ebuilds
2351 > From:
2352 > Dan Armak <danarmak@g.o>
2353 > Date:
2354 > Wed, 16 Mar 2005 22:16:06 +0200
2355 > To:
2356 > gentoo-dev@××××××××××××.org
2357 >
2358 > To:
2359 > gentoo-dev@××××××××××××.org
2360 >
2361 >
2362 >Hello,
2363 >
2364 >I'm unmasking the KDE 3.4.0 ebuilds now, and wanted to remind anyone who
2365 >missed this fact that starting with this release, we're providing split
2366 >ebuilds. That means you can 'emerge konqueror kmail' rather than 'emerge
2367 >kdebase kdepim'. Details and FAQ at
2368 >http://www.gentoo.org/doc/en/kde-split-ebuilds.xml.
2369 >
2370 >
2371 >
2372 >
2373 > ------------------------------------------------------------------------
2374 >
2375 > Subject:
2376 > Re: [gentoo-dev] giflib and libungif hell
2377 > From:
2378 > Dan Armak <danarmak@g.o>
2379 > Date:
2380 > Wed, 16 Mar 2005 22:19:35 +0200
2381 > To:
2382 > gentoo-dev@××××××××××××.org
2383 >
2384 > To:
2385 > gentoo-dev@××××××××××××.org
2386 >
2387 >
2388 >On Wednesday 16 March 2005 17:41, Chris White wrote:
2389 >
2390 >
2391 >>So.. basically:
2392 >>
2393 >>1) libungif and giflib both install -lgif
2394 >>2) They don't block each other
2395 >>3) libungif does some weird thing where it deletes the giflib header
2396 >>file (probably because they aren't blocking each other?)
2397 >>
2398 >>So, they pretty much install the same thing... Can I put a blocker on
2399 >>this? Or does someone have a valid reason why I shouldn't...
2400 >>
2401 >>
2402 >Bug 18820. This's been around forever...
2403 >
2404 >
2405 >
2406 >
2407 > ------------------------------------------------------------------------
2408 >
2409 > Subject:
2410 > Re: [gentoo-dev] KDE split ebuilds
2411 > From:
2412 > Dan Armak <danarmak@g.o>
2413 > Date:
2414 > Wed, 16 Mar 2005 22:29:21 +0200
2415 > To:
2416 > gentoo-dev@××××××××××××.org
2417 >
2418 > To:
2419 > gentoo-dev@××××××××××××.org
2420 >
2421 >
2422 >On Tuesday 15 March 2005 21:25, Tom Wesley wrote:
2423 >
2424 >
2425 >>Hey
2426 >>
2427 >>I've seen several queries regarding KDE's new split ebuilds and the
2428 >>version numbers used for specific packages. It seems that all of the
2429 >>KDE 3.4 packages have been versioned as 3.4.
2430 >>
2431 >>Should kmail, kopete etc not be using their own version numbers with the
2432 >>meta-packages being versioned based on the kde release number?
2433 >>IMO this would make more sense, especially when reading the kopete website,
2434 >>finding the latest version is 0.9.2 and then noticing that portage only
2435 >>has 3.4.
2436 >>
2437 >>
2438 >In my experience most KDE users have no idea offhand what the individual app
2439 >versions are and which versions belong to which kde.org release. They'd be
2440 >confused.
2441 >
2442 >If a lot of users told me I'm wrong, I guess I'd be willing to concede this
2443 >point...
2444 >
2445 >BTW, what do other distros use?
2446 >
2447 >Another problem is that there are a few KDE devs who are the same: they don't
2448 >bother to put real version numbers on their apps (and especially libs), and
2449 >they stay stuck at 0.0.1, or don't always receive a version number upgrade
2450 >when they change. I can't find an example offhand now, but I remember seeing
2451 >such before...
2452 >
2453 >And a third problem: it'd make it much easier for us to make a versioning/dep
2454 >mistake (think about updating 300 differently-schemed version numbers)
2455 >without noticing.
2456 >
2457 >
2458 >
2459 >
2460 > ------------------------------------------------------------------------
2461 >
2462 > Subject:
2463 > [gentoo-dev] SCSI support on next PPC LiveCD?
2464 > From:
2465 > "A. Khattri" <ajai@××××.net>
2466 > Date:
2467 > Wed, 16 Mar 2005 14:55:03 -0500 (EST)
2468 > To:
2469 > gentoo-dev@××××××××××××.org
2470 >
2471 > To: