summaryrefslogtreecommitdiff
blob: b8f5ea6ec899a7b9d267020660dc4670677f2ce3 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
21:00:06 ---	dertobi123 sets mode +m #gentoo-council
21:00:09 <dertobi123>	hi
21:00:11 <Calchan>	Betelgeuse, dertobi123, solar?
21:00:14 <Betelgeuse>	Calchan: yes
21:00:26 *	scarabeus aroundy :]
21:00:31 <Calchan>	ok, so it looks like we're only missing solar
21:00:45 <solar>	why do you say that?
21:00:59 <Calchan>	solar, oh sorry, hi :o)
21:01:06 <scarabeus>	:]
21:01:54 <Calchan>	ko, so who's logging?
21:02:00 <Betelgeuse>	I am
21:02:03 <Calchan>	good
21:02:13 <Calchan>	anyone else, just in case?
21:02:14 *	wired logging as well
21:02:17 <Calchan>	great
21:02:21 <Calchan>	roll call
21:02:25 <ulm>	here
21:02:31 <wired>	here, proxy for leio
21:02:32 <scarabeus>	here
21:02:44 <Betelgeuse>	still here
21:02:46 <Calchan>	I'm obviously here :o)
21:02:47 <solar>	likewise
21:03:01 <Calchan>	dertobi123, is here too, still alive ? ;o)
21:03:13 <dertobi123>	yep
21:03:15 <dertobi123>	somewhat
21:03:17 <Calchan>	great
21:03:23 <Calchan>	who wants to chair?
21:03:39 <Calchan>	I can as I know the topics, but anybody else is welcome to volunteer
21:03:45 <solar>	Please do
21:03:45 <Betelgeuse>	feel free
21:03:46 <ulm>	Calchan: no objections
21:03:53 <Calchan>	ok then
21:04:02 <Calchan>	any remarks on the agenda?
21:04:22 <Betelgeuse>	Calchan: Could get comments on the council web app at end if there's time but unlikely
21:04:30 <Betelgeuse>	Calchan: As I didn't get much on the mailing list
21:04:33 <Betelgeuse>	and scarabeus is new
21:04:35 <Calchan>	after 4 we need to officially approve eapi3 if the status report of 2 and 3 is OK
21:04:54 <ulm>	yes
21:05:02 <Calchan>	Betelgeuse, yes, let's discuss that i n the open floor part if you want
21:05:16 -->	ssuominen (n=ssuomine@gentoo/developer/ssuominen) has joined #gentoo-council
21:05:22 <Calchan>	I couldn't comment on that, I was too busy with other ongoing subjects
21:05:35 <Calchan>	any other comments?
21:05:48 ---	Calchan gives voice to grobian
21:06:11 <Calchan>	ok, let's moce to 2. prefix status
21:06:23 -->	Cardoe (n=Cardoe@gentoo/developer/Cardoe) has joined #gentoo-council
21:06:34 <Calchan>	grobian, can you tell us how prefix is progressing?
21:06:39 <Calchan>	my typing sucks today
21:06:43 <grobian>	Calchan: fairly well, I'd say
21:06:51 <grobian>	as far as I know, portage is ready
21:07:00 <Calchan>	ok, what was done, and what still needs to be done?
21:07:03 <grobian>	it seems the PMS patch needed a final review by the council
21:07:09 <Calchan>	ok
21:07:18 <grobian>	so thanks to ulm the patch has been brought into a final state
21:07:40 <grobian>	I personally see nothing that needs to be done
21:07:49 <Calchan>	grobian, am I right in thing that there's nothing pending before finmal approval?
21:07:51 <grobian>	lots of peeps actually started porting stuff
21:07:56 <Calchan>	/thing/thinking/
21:08:21 <grobian>	Calchan: as far as I am aware, all objections/questions by PMS team were dealt with
21:08:30 <grobian>	I'd have to ask ulm to make that official
21:08:42 <ulm>	yes, I think so
21:09:05 <Calchan>	so if other council members agree we will consider prefix done and not a blocker for final approval of eapi3 then
21:09:09 <ulm>	there were no more comments on the last version of the patch
21:09:25 <Calchan>	can I get a quick yes from everybody on the above question? just a formality...
21:09:27 <--	Arfrever has quit (Client Quit)
21:09:41 <Calchan>	so that's a yes from me
21:09:43 <dertobi123>	here's your "yes"
21:09:45 <wired>	+1 here
21:09:46 <ulm>	yes
21:09:51 <scarabeus>	here is 1 "yes"
21:09:52 <Betelgeuse>	the approval is done by having something to tag in PMS before
21:10:03 <Betelgeuse>	if it's not committed yet then there's no commit to review and tag yet
21:10:13 <ulm>	sigh
21:10:18 <Betelgeuse>	but conceptually yes
21:10:22 <Calchan>	Betelgeuse, we have a patch so it's as good
21:10:23 <ulm>	it's committed: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=f49a53b3a97dbe299f1b71dad5a6bf5b9b6805ba>
21:10:32 <Calchan>	ulm, thanks
21:10:32 <Betelgeuse>	ulm: good
21:10:44 <Calchan>	solar? although we seem to have a majority here
21:11:40 <solar>	Calchan: one moment
21:11:44 <Calchan>	solar, sure
21:13:22 <Calchan>	solar, let's move one as we have a majority anyway, and feel free to chime in with your opinion on that at any time during the meeting when you're more available
21:13:38 <Calchan>	so let's move to : 3. mtime preservation status
21:13:41 <Calchan>	ulm?
21:14:08 <Calchan>	I seem to remember there was a minor point still to be dealt with, what was it again?
21:14:18 <ulm>	no, all issues resolved
21:14:26 <Calchan>	nothing that I would consider big enough to block eapi3 approval though
21:14:30 <ulm>	consensus with PMS team and all PM authors
21:14:40 <Calchan>	ulm, but can you still please remind us what it was?
21:14:47 <Calchan>	just out of curiosity
21:15:10 <solar>	Calchan: I voted last month to approve the prefix stuff. My vote from then still stands. So yes.
21:15:12 <ulm>	there was an issue with nanosecond time stamps
21:15:18 <Calchan>	solar thanks
21:15:27 <Calchan>	ulm ah yes
21:15:30 <ulm>	but it has been resolved
21:15:49 <ulm>	here's the commit in PMS: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=51690686a39149f89a64b80b5d6074cc56c46e1a>
21:16:02 <Calchan>	ok, so do we all agree on final approval of mtime preservation for eapi3?
21:16:06 <Calchan>	yes from here
21:16:09 <ulm>	yes
21:16:13 <dertobi123>	yep
21:16:52 <scarabeus>	yep
21:16:56 <Betelgeuse>	yes
21:17:03 <solar>	reading
21:18:26 <wired>	looks good, yes
21:18:49 <Calchan>	alright we have a majority anyway, solar you can take your time
21:18:53 <solar>	what is this subsecond stuff being slipped in?
21:19:27 <ulm>	solar: basically, it says that subseconds must be set to zero or preserved exactly
21:19:39 <solar>	ulm: that is new.
21:19:51 <solar>	so does this turn it's value into a float/double ?
21:20:15 <ulm>	solar: no, only intergers involved
21:20:19 -->	yporti (n=yporti@r306-pb-passacinco.ibys.com.br) has joined #gentoo-council
21:20:19 <ulm>	*integers
21:21:07 <Calchan>	solar, ulm, can we move forward or you need more time to discuss this now?
21:21:32 <ulm>	Calchan: move forward please, we can discuss it later
21:21:38 <Calchan>	ulm, ok thanks
21:21:46 <Calchan>	4. Should we move xz unpacking from EAPI4 to EAPI3?
21:21:51 <ulm>	solar: it's all fine, trust me ;)
21:21:57 <Calchan>	this was actually my fault that this was not discussed last time
21:22:19 <Calchan>	we had a PMS patch ready already, prtage has that implemented for quite some time
21:22:23 <Calchan>	and it's trivial
21:22:32 -->	Fauli (n=Opfer@gentoo/developer/fauli) has joined #gentoo-council
21:22:42 <dertobi123>	then lets get that in to eapi 3
21:22:47 <Betelgeuse>	My point previosly and still is keeping EAPI 3 as something that most developers wouldn't need to know the contents of
21:22:59 <scarabeus>	its two liner iirc :]
21:23:00 <Calchan>	dertobi123, we still need to vote on xz though
21:23:13 <Betelgeuse>	If we have repoman verifying proper .xz usage then it's fine for me
21:23:23 <Calchan>	and its a yes from me
21:23:35 <scarabeus>	well it is nothing required to know if portage handles it iself :]
21:23:37 <dertobi123>	Calchan: that was my vote ;)
21:23:41 <solar>	fine as well on .xz
21:23:45 <Calchan>	can anybody answer Betelgeuse on repoman? ping me in private if you need voice
21:24:02 <wired>	and a yes from me
21:24:24 <Calchan>	we already have a majority anyway
21:24:25 <scarabeus>	iirc it does not bail out now, since we have xz packages in kde4.4 snapshots
21:24:37 <scarabeus>	and we supply the .xz tarballs and own extract function
21:24:51 <scarabeus>	only problem with it is depending on proper tar version that supports xz
21:25:01 <Betelgeuse>	scarabeus: Should we start forcing EAPI 3 or later for .xz?
21:25:05 <Betelgeuse>	Such a repoman patch is easy
21:25:26 <ulm>	.xz in eapi 3 fine for me as well
21:25:40 <Betelgeuse>	What does Portage do for .xz files in EAPIs 0 1 2?
21:25:44 <scarabeus>	we should push it throught, because few upstreams use only xz as sources, and the custom unpacks are lame
21:25:53 <ulm>	Betelgeuse: unpack ignores them
21:26:06 <Betelgeuse>	I remember some extension being pushed without EAPI bump but it was probably lzma related
21:26:28 <Calchan>	as far as I can see we have everything approved for eapi3 so unless you speak now we have final approval for it
21:26:50 <Betelgeuse>	ulm: Ok which is probably not what the user wants so EAPI 3 repoman check should be ok
21:27:04 <ulm>	Calchan: so we include xz or not?
21:27:15 <dertobi123>	we do
21:27:17 <Calchan>	ulm, looks like it, yes :o)
21:27:20 <ulm>	k
21:27:23 <solar>	Calchan: assume yes from me on the eapi3 mtime.
21:27:30 <Betelgeuse>	I will file a bug for repoman and xc
21:27:31 <Calchan>	solar, ok thanks
21:27:36 <Calchan>	Betelgeuse, good point
21:27:48 <Calchan>	should we move forward?
21:28:13 <Calchan>	5. GLEP 57
21:28:23 <Betelgeuse>	https://bugs.gentoo.org/show_bug.cgi?id=301426
21:28:45 <Calchan>	it's in informational glep on tree signing and security in general
21:29:06 <Calchan>	if you want to discus it (briefly) speak now, or we'll move to vote on it
21:29:46 <ulm>	Calchan: we don't approve eapi 3?
21:29:59 <Betelgeuse>	I was mainly thinking do we need informational docs as GLEPs
21:30:01 -->	romi (n=Rodrigo@mail.ltia.fc.unesp.br) has joined #gentoo-council
21:30:09 <Calchan>	ulm, you want a specific vote for it? that's ok with me
21:30:23 <Calchan>	let's vote for final approval of eapi3 then
21:30:27 <Calchan>	yes
21:30:30 <ulm>	Calchan: i think it would be appropriate
21:30:35 <scarabeus>	yes for eapi3
21:30:35 <ulm>	yes
21:30:35 <dertobi123>	here's your yes :)
21:31:04 <Calchan>	grobian, can you please take care of the champagne in the meantime?
21:31:12 <Betelgeuse>	yes
21:31:13 <grobian>	Calchan: you're just too late
21:31:17 <dertobi123>	Betelgeuse: wrt informational docs - i don't think we *need* those as GLEPs, but it doesn't hurt to have one as a GLEP
21:32:00 <Calchan>	we have a majority for eapi3 final approval, so as of right now eapi3 is offically official
21:32:24 <Betelgeuse>	ulm: as you have commit rights it's easiest for you to tag it
21:33:02 <Calchan>	let's move to GLEP 57 now
21:33:05 <ulm>	Betelgeuse: I don't, but I'll ask fauli
21:33:15 <wired>	yes for eapi3 for formality :)
21:33:17 <solar>	We are going to have a hard time talking about these gleps 57-61 if robbat2 does not show up.
21:33:26 <Betelgeuse>	ulm: The tags have been signed by council members
21:33:37 <scarabeus>	the first one is ok
21:33:40 <ulm>	Betelgeuse: ok, will do then
21:33:49 <scarabeus>	it just sums up the reasons and whats going on :]
21:33:55 <Calchan>	solar, he said he probably wouldn't though and I think most of us have discussed it with him before
21:34:21 <Betelgeuse>	ulm: I remember using a bundle or something like that and emailing that to someone who can commit
21:34:58 <Calchan>	technically all we need to do is vote yes or no, and no might mean not yet, discussions should have happened before as this has been in the making for years
21:35:12 ---	Calchan gives voice to Fauli
21:35:53 <Calchan>	Fauli, you have voice now so go ahead
21:35:59 <Fauli>	Betelgeuse: I can commit, as Ciaran is not available for some days.
21:36:15 <Fauli>	As soon as you are ready, send it my way.
21:36:26 <--	Cardoe has quit (Remote closed the connection)
21:37:18 <Calchan>	ok, so since there does not seem to be any discussion about glep 57, let's vote
21:37:37 <Calchan>	I vote yes, as in it's informational only but states some necessary goals
21:37:54 <ulm>	yes for 57
21:38:06 <scarabeus>	glep 57 - yep
21:38:15 <dertobi123>	yes
21:38:21 <Betelgeuse>	yes
21:38:26 <solar>	yes
21:38:41 <Calchan>	good, we have a majority for yes, glep 57 is approved
21:38:52 <Calchan>	6. GLEP 58
21:39:39 <Calchan>	58 is about implementing metamanifest which does not require developper action
21:39:56 <Calchan>	same thing, vote or comment please
21:40:04 <Betelgeuse>	I assume robbat2 has done testing in practise from the latter GLEPs so no objections here
21:40:14 -->	_robbat2laptop (n=robbat2@gentoo/developer/robbat2) has joined #gentoo-council
21:40:15 <dertobi123>	first we'd need to vote for glep-60, as this one is required by 57
21:40:22 ---	Calchan gives voice to _robbat2laptop
21:40:26 <Calchan>	yay
21:40:33 <_robbat2laptop>	sorry, in work meeting, and had bad wifi till now
21:40:41 <ulm>	the size of the metamanifest is very large if there are no subdir (i.e. categories + eclass + profiles) metamanifests
21:40:56 <Calchan>	_robbat2laptop, we approved 57 and were just starting 58
21:41:11 <_robbat2laptop>	ulm, the metamanifest spec does specify subdirs Manifests are strongly suggested
21:41:15 <Calchan>	ulm, agreed but there's glep 61 to the rescue
21:41:39 <ulm>	_robbat2laptop: maybe council should support this suggestion then
21:42:13 <Calchan>	ulm, we can make a specific note of it but it being in the glep already is enough for me
21:42:41 <Calchan>	I would vote yes on this one, my only concern is about infra havong the manpower to actually implement that
21:42:56 <_robbat2laptop>	Calchan, there's a functional MetaManifest generation prototype already
21:43:03 <_robbat2laptop>	in my other dir on the gentoo CVS repo
21:43:10 <solar>	and how is the final file?
21:43:13 <solar>	how big
21:43:33 <Betelgeuse>	_robbat2laptop: Have you tested how much slowers emerge --sync becomes?
21:43:44 <ulm>	solar: I think it was 8 MB if without subdir manifests
21:43:59 <Calchan>	ulm, compressed or not?
21:44:21 <_robbat2laptop>	8MB uncompressed without subdirs
21:44:37 <Calchan>	not that big of a deal then
21:44:46 <_robbat2laptop>	if subdirs are used, it's about 8.05MB raw
21:45:16 <ulm>	the compression factor cannot be good for SHA hashes
21:45:39 <ulm>	mainly factor of 2 for ascii -> binary
21:45:48 <Calchan>	_robbat2laptop, can you confirm that e.g. users on low bandwidth can deactivate this?
21:45:49 <_robbat2laptop>	better than 2:1
21:46:00 <_robbat2laptop>	Calchan, they can add --exclude MetaManifest*
21:46:12 <_robbat2laptop>	they wouldn't be able to validate the tree as easily
21:46:19 <_robbat2laptop>	but that is a tradeoff they have to decide
21:46:43 <Calchan>	then if it can be deactivated and we have an already (at least partially) working implementation I vote yes
21:46:47 <Calchan>	what about others?
21:47:00 <Betelgeuse>	_robbat2laptop: I don't think you answered the speed implications
21:47:34 <_robbat2laptop>	Betelgeuse, without the split, it's a new MetaManifest file nearly every rsync pass
21:47:57 <Betelgeuse>	_robbat2laptop: I mean how long does verifying the Manifests add to the time
21:47:58 <_robbat2laptop>	with the subdir split, the extra data transfered is <2MB in my tests
21:48:03 <scarabeus>	we should maybe enforce the splits instead of recommending
21:48:22 <Calchan>	scarabeus, good point
21:48:23 <Betelgeuse>	_robbat2laptop: Mainly if there's anything major for older machines?
21:48:23 <wired>	2mb isn't that bad
21:48:40 <wired>	scarabeus: that sounds good
21:48:47 <Calchan>	_robbat2laptop, what's the cost/implications of splitting?
21:48:48 <_robbat2laptop>	Betelgeuse, I had full signature verification of _every_ Manifest and MetaManifest in <5 seconds, plus any IO time
21:49:07 <Betelgeuse>	_robbat2laptop: ok thanks
21:49:14 <_robbat2laptop>	cputime ~5 seconds on a not fast P4 box, ~3 years ago
21:49:14 <solar>	Calchan: in short it's faster if split.
21:49:35 <_robbat2laptop>	yes, because the subdir MetaManifests might not have changed between passes
21:49:35 <Calchan>	solar, that's what I thought but I was afraid there was a downside to it
21:49:44 <_robbat2laptop>	~50 more inodes
21:49:48 <solar>	8M ? there is too much overhead in this format
21:49:57 <_robbat2laptop>	8M uncompressed
21:49:59 <Calchan>	if there is no downside I'd be in favor of making it mandatory
21:50:05 <_robbat2laptop>	that's why there was the compression GLEP
21:50:10 <solar>	I just hashed the entire tree sha1 @ around 3.6M
21:50:47 <ulm>	but sha256/512 is longer
21:51:26 <Calchan>	are we ready to vote on this or do you need more time to discuss?
21:51:33 <_robbat2laptop>	http://dev.gentoo.org/~robbat2/MetaManifest.bz2
21:51:38 <solar>	_robbat2laptop: You are not filering the files that are moot?
21:51:45 <_robbat2laptop>	from July 2008
21:51:51 <solar>	like ChangeLog/metadata.xml and other manifests?
21:52:04 <_robbat2laptop>	solar, every file should turn up in exactly on Manifest file
21:52:11 <_robbat2laptop>	*exactly one
21:52:16 <_robbat2laptop>	MetaManifest or Manifest
21:52:25 <_robbat2laptop>	but no single file should be in more than one Manifest
21:53:58 <solar>	is there any valid reason to checksum metadata.xml or ChangeLog files in this format?
21:54:26 <_robbat2laptop>	solar, the added filetypes GLEP deals with when they can be excluded
21:55:08 <ulm>	_robbat2laptop: about 2/3 of the metamaifest size are due to metadata/cache?
21:55:19 <_robbat2laptop>	ulm, yes unfortuntely
21:55:22 <solar>	what number is that? these gleps kinda make you just back and forth. Making it a bit difficult to follow
21:55:26 <_robbat2laptop>	and those files DO need to be protected
21:55:42 <wired>	scarabeus: 60
21:55:46 <wired>	oops
21:55:50 <wired>	solar: ^^ :)
21:56:48 <_robbat2laptop>	58 - MetaManifest itself, 59 - hash types (SHA512), 60 - filetypes, 61 - compression
21:57:12 <Calchan>	are we ready to vote on glep 58?
21:57:52 <solar>	no
21:58:04 <solar>	I can say. I'm ok with the idea as a whole and would like to see a compressed per cat metamanifests
21:58:19 <Calchan>	solar, you need more time to discuss or you're voting no?
21:58:20 <solar>	but these gleps don't allow you to vote on one of them.
21:58:49 <solar>	and 60 looks like a format change in portage
21:58:58 <_robbat2laptop>	ok, let's just tackle them in a different order for a sec.
21:59:06 <_robbat2laptop>	61 is allowing compression in ANY manifest
21:59:09 <_robbat2laptop>	not just the MetaManifest
22:00:43 <Calchan>	solar, if you think they're not ready to be approved then vote no, ok?
22:00:55 <solar>	wait a sec plz.
22:01:08 <solar>	you guys even know what you are voting on?
22:01:26 <Betelgeuse>	as much as always :)
22:01:39 <Calchan>	solar, I have provisions to add to my vote but I'm ready to vote
22:02:11 <dertobi123>	guess i do, and given the impact i'm against rushing this through today, especially if anyone of us has points he'd like to see adressed before voting
22:02:21 <Calchan>	tjose provisions are btw that it is optional for the user and not on by default a tthe beginning, and that subdir splitting is mandatory
22:04:02 <_robbat2laptop>	Calchan, is having the users that don't want it add --exclude MetaManifest* to their sync options acceptable?
22:04:52 <Calchan>	_robbat2laptop, I wuold prefer the contrary at the beginning, i.e. users having to turn the feature on to use it
22:04:55 <_robbat2laptop>	Betelgeuse, dertobi123, leio, scarabeus, solar, ulm: could you list what changes you would like?
22:05:04 <scarabeus>	can we go throught rest of those (1glep in 4) and add all comments under which it can be accepted, and we can proceed with vote next time on all of them at once if anyone is not against?
22:05:15 <_robbat2laptop>	Calchan, ok, if we roll out an upgrade of portage that includes that?
22:05:30 <wired>	perhaps we could tackle these gleps one/two at a time?
22:05:34 <Calchan>	_robbat2laptop, yes ok from me at this condition
22:05:35 <_robbat2laptop>	ok, so no metamanifest yet, move on to the next glep
22:05:53 <Calchan>	scarabeus, wired hold on, let's stick to the agenda for the time being
22:05:54 <_robbat2laptop>	i'll represent GLEP58 with more changes
22:06:14 <Calchan>	glep 59 is rather orthogonal to the others
22:06:31 <Betelgeuse>	_robbat2laptop: GLEP 59 seems a bit outdated for python versions but that's just cosmetical
22:06:39 <Betelgeuse>	_robbat2laptop: Could make it reflect the current situation
22:06:41 <Calchan>	has everybody read it and does any og you have questions for _robbat2laptop?
22:06:42 <_robbat2laptop>	58, 59, 60, 61 are all orthangonal
22:06:45 <solar>	_robbat2laptop: Re; Like. I'd like to simply see the MetaManifests in the per category basis compressed. Not including bloat files that portage already ignores by allowing you to --exclude=metadata.xml and --exclude=ChangeLog ; With no changes to the existing Manifest format
22:07:03 <--	billie has quit (Remote closed the connection)
22:07:08 -->	billie (n=billie@gentoo/developer/billie) has joined #gentoo-council
22:08:07 <Calchan>	_robbat2laptop, I had the following question about 59:
22:08:29 <Calchan>	Second paragraph of "Checksum depreciation". Is the description still up-to-date about python support of various checksums? How about using external executables when python does not have support for a desirable checksum?
22:08:45 <solar>	so the first parts can be introduced w/o major bloat or behavior changes in the PM. We review the overhead it causes on the rsync servers and decide from there if it safe to move fwd.
22:09:48 <_robbat2laptop>	Calchan, yes, py2.5 and newer all support SHA512
22:10:18 <Calchan>	we're seriously late now, here's what I propose:
22:10:24 <dertobi123>	solar: i like that suggestion
22:10:58 <Calchan>	it doesn't look liketoday  we're going to approve any of these gleps except for the informational one we have already approve
22:11:16 <wired>	solar's suggestion is nice, or we can go the other way around and implement 59/60/61 first, then finish up with 58 when they're done
22:11:38 <Calchan>	so I suggest that one of us (me if nobody volunteers but I would prefer somebody else) gathers a list of questions/remarks/provisions for robin tio update his gleps fpor next time
22:11:56 <Calchan>	how's that?
22:12:00 <_robbat2laptop>	i'll post each glep in the body of a mail to -dev
22:12:12 <_robbat2laptop>	if you have an item, post a reply there as a new thread
22:12:35 <Calchan>	does everybody agree postponing the rest of these gleps?
22:12:47 <_robbat2laptop>	they've been presented for 2 months already, so I don't know why none of you except ulm have come to me with questions/changes
22:12:59 <scarabeus>	actualy we technicaly can accept the 61, and if we will not accept the Metamanifest itself, that section of sentence can be removed
22:12:59 <scarabeus>	because that glep apply to the Manifest2 too
22:13:16 <scarabeus>	_robbat2laptop: i read them on saturday first time ;]
22:13:27 <Calchan>	scarabeus, let's keep that for when we have a clearer view
22:13:33 *	solar has been reading them for ~4 years
22:13:59 <Calchan>	if nobody disagrees right now with postponing I'll move to the next point]
22:14:39 <Betelgeuse>	_robbat2laptop: Because we need that web app of mine
22:15:06 <scarabeus>	can we make mandatory that next time we will only vote on them and all concerns will have to be settled up to that meeting (so we dont end up like today?)
22:15:21 <_robbat2laptop>	any if you don't present your question in the next month
22:15:24 <ulm>	scarabeus: +1
22:15:26 <_robbat2laptop>	you hold your tongue
22:15:29 <Calchan>	scarabeus, eh, let me guess, you're new, right? ;o)
22:15:41 <solar>	Calchan knew before the meeting that we would not vote on all. But would be doing this in phases
22:15:42 <scarabeus>	:D
22:16:08 <Calchan>	solar, I'll pretend I disagree
22:16:20 <scarabeus>	okey okey :D
22:16:26 <Calchan>	solar, what I actually told you is that you could vote no if you thought this wasn't ready
22:16:48 <wired>	metamanifest aside, what are the objections to the other gleps?
22:17:02 <Calchan>	I wasn't forcing anybofy to vote or even less agree to this, I was just putting this on the agenda as requested by robin
22:17:12 <Calchan>	on the other hand you guys could have done your homework
22:17:18 <Calchan>	anyway
22:17:33 <Calchan>	10. Do we want to merge the code maintained by Tomas Sachau for multiple ABIs into portage 2.2 or should it be kept in a separate repository for now?
22:17:46 <_robbat2laptop>	i'm going to part here now
22:17:47 <scarabeus>	there i have question
22:17:47 <_robbat2laptop>	thanks
22:17:51 <scarabeus>	how is the git migration
22:17:59 <_robbat2laptop>	scarabeus, RESO LATER
22:17:59 <scarabeus>	s/how/where/
22:18:14 <scarabeus>	i mean migration for portage as the manager :]
22:18:22 <--	_robbat2laptop (n=robbat2@gentoo/developer/robbat2) has left #gentoo-council ("back to my other meeting")
22:18:28 <scarabeus>	because if portage is on git, tommy just can have another branch
22:18:37 <Calchan>	scarabeus, when you have such questions you should ask in advance for them to be put on the agenda
22:18:59 <Calchan>	scarabeus, and you don't need to be a council member for that, you don't even need to wait for a council meeting
22:19:21 <Calchan>	let's go back to:
22:19:25 <Calchan>	10. Do we want to merge the code maintained by Tomas Sachau for multiple ABIs into portage 2.2 or should it be kept in a separate repository for now?
22:19:25 <dertobi123>	imho that's nothing we'd need to vote on, it's zac's decision whether he wants to maintain the code in portage svn/git or not
22:19:53 <Calchan>	but zac and thomas have asked for us to decide on that
22:20:08 <wired>	I think they just want the format decision
22:20:34 <scarabeus>	well if zac is ok with it, i think portage-2.2 can be experimental for bit longer :]
22:20:53 <scarabeus>	where "bit" can vary :]
22:20:54 <Calchan>	note that zac's opinion is to not merge that to portage 2.2 yet, but as the portage repo is being switched to git it will make it easier for him to help thomas maintain it, which ws thomas' main concern
22:21:14 <Betelgeuse>	go with git and do whatever branch magic wanted
22:21:17 <scarabeus>	which is what i said above with the question if they migrated to git yet?
22:21:20 <dertobi123>	Betelgeuse++
22:21:28 <dertobi123>	besides that, i'd still say it's up to zac
22:21:42 <Calchan>	scarabeus, there's a bug for that in the agenda if you want to read it
22:22:11 <scarabeus>	see;read
22:22:38 <Calchan>	alright, so far we have:
22:22:56 <Calchan>	no , go with git instead from Betelgeuse
22:23:10 <Calchan>	and I have the same opinion/vote
22:23:26 <Calchan>	dertobi123 says it's up to zac and zac says no
22:23:27 <solar>	same. no portage-maintree. yes on new branch.
22:23:45 <scarabeus>	branch is 100% fine with me too
22:23:46 <Calchan>	that's 4 nos with solar's
22:23:48 <wired>	leave it up to zac
22:24:04 <solar>	we attempted to. He did not want to think for himself this time
22:24:06 <Calchan>	alright, we have a decision then, that's no to 10
22:24:06 <ulm>	no from me to, leave it to zac
22:24:09 <ulm>	*too
22:24:16 ---	Calchan gives voice to Tommy[D]
22:24:20 <Calchan>	hi Tommy[D]
22:25:03 <Calchan>	afaik the migration of the portage repo to git should happen any day now
22:25:16 <wired>	a git branch would be nice though
22:25:26 <Tommy[D]>	most say "no, go with git", but as robbat2 just said, that wont happen for now, so that means "no, no integration in the experimental portage-2.2* branch"
22:25:56 <Tommy[D]>	and also "no intregration within the next future"
22:25:56 <Betelgeuse>	Tommy[D]: that was about main tree
22:25:56 <Calchan>	Tommy[D], the no above was for the migration of the tree to git, not the portage repo
22:26:15 <solar>	right. That is also a no on portage-2.2
22:26:39 <Calchan>	Tommy[D], the portage repo *is* being switched to git right now, it got delayed a bit for technical reasons but it's any day now
22:26:42 <--	romi has quit (Client Quit)
22:27:31 <solar>	You can branch in svn as well.
22:27:38 <Betelgeuse>	but it sucks
22:27:44 <wired>	is it possible to somehow put the whole mutilib code behind a USE flag in 2.2 to get more people to test it?
22:27:45 <solar>	but it's not enough to hold anybody back
22:27:47 <Calchan>	Tommy[D], again zac has agreed to help you maintain this, the fact that it's going to be an official branch maintained with zac will make it more visibla and it will get more testing
22:28:21 <Tommy[D]>	Can those, who vote against integration give me their technical reasons against it, preferable via mail on the #-dev ML thread?
22:28:22 <scarabeus>	wired: it can be FEATUREised, but the branch is easier
22:28:26 <Betelgeuse>	Calchan: Well I doubt there's really much people on anything else put main tree releases
22:28:39 <scarabeus>	wired: specialy with the GIT eclass
22:29:15 <wired>	scarabeus: yeah but I was hoping for releases not live ebuilds :)
22:29:31 <Betelgeuse>	Tommy[D]: What do you mean with integration?
22:30:19 <Tommy[D]>	Betelgeuse: my request was merging into portage-2.2* branch, it was voted against, so i would like to know the reasons for the votes
22:30:25 <Calchan>	Betelgeuse, Tommy[D], wired, scarabeus: I propose you go on with that discussion during the open floor session in a couple minutes
22:30:49 <solar>	Tommy[D]: baby steps buddy.
22:31:01 <Calchan>	let's finish with 11 and you can all resume this discussion
22:31:07 <Calchan>	11. Conclusion
22:31:12 <Calchan>	11.1 Action list. Who does what and when?
22:31:38 <Calchan>	as actions I have gahter a list of questions/changes for robin
22:31:52 <Calchan>	or lists if we want to do this per glep
22:31:58 <Calchan>	who wants to do it?
22:32:00 <Betelgeuse>	I am in Finland only the first Monday of February
22:32:13 <Betelgeuse>	Otherwise I am in Bryssels or Vancouver
22:32:16 <Calchan>	Betelgeuse, we'll come to that hold on
22:32:31 <Betelgeuse>	Calchan: Don't ask both :)
22:32:47 <Betelgeuse>	Calchan: Any way it excludes me from good agenda work
22:33:00 <Calchan>	as I said I can volunteer for the questions to robin but I would really prefer somebody more technical takes care of it
22:33:12 <Calchan>	solar?
22:33:33 <Calchan>	anybody?
22:33:36 <Betelgeuse>	solar seemed to have the most to need for changing things so would make sense
22:33:50 <ulm>	Calchan: I can take it if nobody else volunteers
22:33:51 <solar>	I can send him my last sentance. I expect he has his reasons for wanting to include metadata.xml/ChangeLog (I just don't understand them)
22:34:10 <solar>	I don't know what concerns the rest of you had in the same/similar respects
22:34:13 <Calchan>	ulm, thanks, I'll help you with that if you need
22:34:37 <Calchan>	ok 11.2 Who takes care of the summary and log for this meeting? When?
22:34:49 <Calchan>	when have leio and tanderson as volunteer for that
22:34:59 <Calchan>	so I think we're covered
22:34:59 <Betelgeuse>	Calchan: leio volunteered so I have no objections
22:35:04 <ulm>	we still don't have a summary for october 2009 btw
22:35:22 <Calchan>	ulm, leio said he was working on that in his latest email
22:35:31 <Calchan>	11.3 Next meeting date/time.
22:35:41 <Calchan>	I have a problem with the 15th of februiary
22:35:47 <solar>	8th?
22:35:51 <Calchan>	but any other days is ok
22:35:55 <Calchan>	I like the 8th
22:36:13 <scarabeus>	its right after fossdem right?
22:36:16 <scarabeus>	looks fine
22:36:16 <dertobi123>	8th is ok, every other monday in february might not work for me
22:36:17 <grobian>	yep
22:36:45 <Calchan>	Betelgeuse?
22:36:47 <ulm>	8th ok for me too
22:37:05 <solar>	good. that is better for robins gleps to not make him wait another month
22:37:26 <Betelgeuse>	Calchan: I would need to remember when I am flying back
22:37:37 <Betelgeuse>	Calchan: I am guessing I am back before 19UTC
22:37:45 <Betelgeuse>	Calchan: I will mail if that's not the case
22:37:54 <Calchan>	Betelgeuse, ok, we can confirm the date on the alias after the meeting
22:38:07 <Calchan>	11.4 Who will follow-up discussions and prepare the agenda for the next meeting?
22:38:09 <Betelgeuse>	Calchan: I will mail and ask
22:38:16 <Betelgeuse>	Calchan: s/mail/phone/
22:38:23 <Calchan>	as always I volunteer but that shouldn;'tprevent any of you to step up
22:39:13 <Calchan>	ok, I'll do it then
22:39:23 <Calchan>	12. Open floor (ad libitum)
22:39:39 <Betelgeuse>	19:25
22:39:43 <Calchan>	you can discuss multilib again now, and any other topic
22:39:47 <Betelgeuse>	19UTC doesn't work
22:40:02 <Betelgeuse>	I am home 20UTC
22:40:04 <Calchan>	Betelgeuse, are you availableon the tuesday?
22:40:10 <Betelgeuse>	yes
22:40:35 <Calchan>	then I propose tuesday, let's settle that on the alias
22:40:53 <Calchan>	somebody takes care of the +m while I go have some lunch?
22:41:03 ---	Betelgeuse sets mode -m #gentoo-council
22:41:10 <Betelgeuse>	Calchan: /mode -m ?
22:41:17 <solar>	Tommy[D]: I still have a bunch of questions about the multilib/stuff. I'll be back in 10-15 if you want to chat some more
22:41:44 <Tommy[D]>	wrt git branch: that wont help with additional testers/users, since they would do the same as now, in addition they would have to use a live version or something like my current multilib branch, so that would be of no big advance
22:42:07 <grobian>	erhm?
22:42:24 <grobian>	has always been an advantage to me, tbh
22:42:44 *	solar was thinking the same. grobian did prefix for years before it got accepted
22:42:49 <Tommy[D]>	if someone knows about multilib-portage and wants to use it, he can already follow the doc lines from our channel and easily use it
22:42:50 <Fauli>	Tommy[D]: You raise the visibility a lot inside the official repository.
22:43:14 <grobian>	and syncing it with trunk is reasonably easy these days
22:43:22 <Tommy[D]>	all others wont use it now and wont use it, when it is a different branch of portage git tree
22:43:47 <spatz>	I thought the main priority was getting help from zac in maintaining it, which a git branch can provide
22:43:51 <Betelgeuse>	Tommy[D]: The item on the agenda was never about main tree use
22:43:58 <Betelgeuse>	what spatz said
22:44:06 <Tommy[D]>	Fauli: that is goal, higher visibility will raise the amount of testers/users and possible volunteers
22:44:06 <wired>	I still feel that a features/use method in 2.2 would really boost multilib testing
22:44:22 <Fauli>	Betelgeuse: Quick about PMS: You take care of the signing tag?
22:44:42 <Betelgeuse>	Fauli: I can if needed
22:44:53 <Betelgeuse>	Fauli: My key is probably best connected any way
22:44:58 <Tommy[D]>	Betelgeuse: my request was merging into portage-2.2* branch, which is (masked by testing keyword and package.mask) main tree
22:45:13 <Fauli>	Betelgeuse: I will commit one last patch (xz support move from 4 to 3) and merge a branch for the cheat sheet.
22:46:08 <Betelgeuse>	Tommy[D]: http://archives.gentoo.org/gentoo-council/msg_4134a24b5a92a4684b8b393fd0013fb7.xml
22:46:20 <Betelgeuse>	Tommy[D]: Other options not being good enough for you doesn't come clear from that
22:46:52 <Betelgeuse>	Tommy[D]: It explicitly says there it not being about main tree
22:47:06 <Tommy[D]>	Betelgeuse: What is unclear about "into portage 2.2"?
22:47:11 <Betelgeuse>	Tommy[D]: read the whole thing
22:47:34 <Betelgeuse>	Tommy[D]: You can't make the start magically revert what comes after
22:48:41 <Betelgeuse>	answering the question there git and branches is in my opinion the best approach
22:49:11 <Tommy[D]>	Betelgeuse: 10. is written in an unclear way.... on one side, it allows to vote on inclusion in portage-2.2, on the other side, it writes about "no main tree", so what should one use?
22:49:57 <Fauli>	Tommy[D]: Don't be too hasty, be happy that you can play in the official repo and test it widely.
22:50:13 <Tommy[D]>	Betelgeuse: and my request explicitly targeted portage-2.2 since it is the experimental branch and hardmasked
22:50:51 <Tommy[D]>	Fauli: What do you mean by "test it widely"?
22:51:16 <Fauli>	Tommy[D]: More testers attracted by the "official" status...
22:51:24 <Betelgeuse>	Tommy[D]: 20:20 <@Calchan> note that zac's opinion is to not merge that to portage 2.2 yet, but as the portage repo is being switched to git it will make it easier for him to  help thomas maintain it, which ws thomas' main concern
22:51:45 <Betelgeuse>	Tommy[D]: I doubt most council members want to force zac
22:52:03 <leio>	2.2 really really should get released finally, these rc61's are embarrassing imho, but that apparently involves fixing all cornercase bugs of sets and preserve-libs, more experimental stuff in it doesn't help. However it being restricted behind a certain release candidate EAPI string that can be used in overlays only could be an option
22:52:03 <Tommy[D]>	Fauli: i am not sure about that point, if one is interested in multilib-portage, he will use it anyway, i dont think the repo will make a big difference
22:52:15 <Fauli>	Tommy[D]: As solar said, baby steps.
22:52:44 <leio>	wired: thanks for proxying, hope it is a useful experience
22:52:50 <wired>	can someone tell me why we're not making this optional for 2.2 users?
22:52:58 <tanderson>	anything in the official repos automatically has more 'credence' and 'reliability' even if it isn't. And the result is more eyes on the code
22:52:59 <ohnobinki>	tommy[d]: but you'll still get more publicity if it's in the ``official'' portage repository at all
22:53:33 <Betelgeuse>	more but if it will make a difference is not certain
22:53:42 <wired>	leio: no problem, it was really interesting :)
22:53:45 <Tommy[D]>	Betelgeuse: i asked him about main tree integration and he said, he would principally ok with it, but requested a council ok before, that was the main reason for my request
22:54:07 <spatz>	btw, why is portage->git RESO LATER? :(
22:54:14 <Betelgeuse>	Tommy[D]: Then there's probably a communication break between zac and Calchan
22:54:19 <Betelgeuse>	Tommy[D]: Or different times of asking
22:54:44 <Tommy[D]>	Betelgeuse: different times and different questions
22:54:46 <grobian>	Tommy[D]: IMO your multilib thing is a same sort of boat like Prefix, if you want it in portage mainline, Zac will only do it if the council has said yes
22:55:01 <grobian>	Tommy[D]: and the council only says yes if you do all the specing stuff
22:56:21 <Tommy[D]>	grobian: i have also seen a request for a "team" or similar as backup, which currently does not happen and wont happen without being in (even hardmasked 2.2 version of ) portage
22:56:22 <Betelgeuse>	Any way I want to leave the office finally as it's 11PM
22:56:46 <Betelgeuse>	So bye everyone
22:57:02 <Betelgeuse>	Tommy[D]: Too bad it didn't work out as you wanted but at least it should be moving forward
22:57:05 <grobian>	Tommy[D]: did that someone also define the minimum amount of members for a team?
22:57:26 <grobian>	Tommy[D]: Prefix has been a one-man-show for most of its live
22:58:38 <Tommy[D]>	grobian: i think, that was Calchan and he wanted a team like amd64 arch team as backup, so it wont be a one-man-show with the bus factor
22:59:23 <grobian>	Tommy[D]: I just wanted to help you, but anyway, you can make it as black as you prefer
22:59:53 <wired>	leio: I didn't get to say much but I tried to help wherever i could and I think I gained some knowledge of how you do things :)
23:00:12 <Tommy[D]>	grobian: he did not define the number, no
23:03:01 <Tommy[D]>	grobian: let me quote Calchan from his mail: http://dpaste.com/147117/
23:03:12 <grobian>	Tommy[D]: I read that\
23:04:06 <grobian>	you can easily claim support is no problem given the support that you claim to have by many devs and users wanting it
23:05:30 <Tommy[D]>	grobian: the problem is this: this is moral support or something like "would like to use it", but not much in the direction of helping with the code or maintainence or similar :-/
23:06:00 <grobian>	Tommy[D]: I see so many parallels...
23:06:30 <grobian>	Maybe if I'm brave, I'd say that 4-5 years ago I also felt like prefix should be integrated in mainline portage "right now"
23:06:52 <grobian>	I'm a bit of a slow person
23:07:13 <grobian>	so you'd probably do it faster, but you need some time to get your idea to cristalise
23:07:31 <Tommy[D]>	i think, it might take months, if not years, until all is done, when it continues the current way because of my limited time and python knowledge
23:07:33 <grobian>	there are many questions, and many critics
23:07:41 <solar>	grobian seems of gained some wisdom over the years.
23:07:46 <grobian>	lol
23:10:00 <Tommy[D]>	currently i only remember a suggested improvement from vapier, which i currently work on (first default ABI, then others, if needed instead of all ABIs in every phase) and comments on flag naming (i have no problem changing that scheme, once the code works)
23:10:45 <solar>	I still don't understand how pkgconfig can properly give you results back
23:11:28 <ohnobinki>	pkgconfig installs its files into into /usr/$(get_libdir)/pkgconfig which automatically picks up ABI differences...
23:12:06 <solar>	not always.. cd /usr/share/pkgconfig ; grep lib *
23:12:26 <Tommy[D]>	solar: there is a .pc file for every ABI, which only contains the details for that ABI
23:12:47 <solar>	and how does pkg-config know which one to call ?
23:12:59 <ohnobinki>	solar: those packages would have bugs filed against them
23:13:36 <ohnobinki>	http://pkg-config.freedesktop.org/wiki/CrossCompileProposal
23:14:08 <Tommy[D]>	the dir, where pkg-config searches is set depending on the current ABI (so it searches in /usr/lib32 for 32bit ones and /usr/lib64 for 64bit ones)
23:15:01 <leio>	ohnobinki: those that install to /usr/share/pkgconfig? I will INVALID all of em ;p
23:15:35 <ohnobinki>	leio: for the ones deserving attention, I'll swim upstream then :-p
23:15:50 <leio>	ohnobinki: They will INVALID it too, read the manuals :)
23:16:02 <leio>	ABI independent .pc files go to /usr/share/pkgconfig
23:16:29 <ohnobinki>	leio: solar pointed out a few ABI-dependent ones in /usr/share/pkgconfig, those are the ones I'm referring to
23:16:29 <leio>	so those packages simply shouldn't be installed twice, they are ABI independent packages.
23:16:38 <solar>	leio: and we are saying there is ABI dependent files in /usr/share/pkg..
23:16:44 <leio>	ok, got a list?
23:16:46 <ohnobinki>	although I can't find any on my system...
23:17:08 <solar>	gnome-mime-data-2.0.pc:libdir=/usr/lib64
23:17:22 <Tommy[D]>	i have udev.pc and xtrans.pc in /usr/share/pkgconfig
23:17:24 <leio>	gnome-mime-data is ABI independent
23:17:31 <ohnobinki>	solar: that one's not ABI-dependent
23:17:51 <leio>	udev is ABI independent (libudev.pc isn't(
23:17:55 <solar>	then it should not define any libdir should it?
23:18:21 <leio>	xtrans is ABI independent (C code and aclocal file)
23:18:56 <--	grobian has quit ("Zzzzz")
23:18:58 <leio>	you will have an issue with udev as the same portage package installs both /usr/share/pkgconfig/udev.pc and /usr/share/${libdir}/pkgconfig/libudev.pc
23:19:09 <leio>	scratch a "share" from the latter
23:19:31 <ohnobinki>	I don't see the issue there ;-)
23:19:36 <leio>	So I presume the meeting is over and I can commit a raw log the next time I'm waiting on something workwise? :)
23:19:58 <Tommy[D]>	so the issue in this case is not my concept, but instead what some packages install and should not install
23:20:02 <leio>	the issue is if you want to install it for both 64bit and 32bit from a monolith package or something
23:20:17 <solar>	this is going to be a nightmare to cross-compile. probably be limited to non multilib cross-compiles in the future
23:21:02 <leio>	Tommy[D]: I don't know, I don't think I have a multilib specification or PMS patch to read
23:22:17 <Tommy[D]>	leio: i currently answer question and have my code, i prefer to improve the code, when i have the time over writing specs
23:23:19 <Tommy[D]>	leio: did you read my #-dev ML discussion with vapier, where i wrote about the basic implementation?
23:24:42 <leio>	Not yet
23:27:11 <leio>	is that write-up something that be converted into an initial spec sort of thing so you don't need to write it up all the time or find all the snippets that explain it when a new thread comes up and the previous one is already forgotten? :)
23:29:30 <Tommy[D]>	i use a different workdir for every ABI and preserve a specified set of vars, with that, i do loop in every src* phase over all ABIs with the default one as last one
23:29:58 <Tommy[D]>	during src_install i have an additional function, which does additional steps (like preserving headers, which differ per ABI or preserve requested binaries and generating a wrapper-symlink for them)
23:30:05 <--	darkside_ (n=darkside@gentoo/developer/darkside) has left #gentoo-council
23:33:16 <Tommy[D]>	leio: this was the mail: http://archives.gentoo.org/gentoo-dev/msg_9b89064c248dd2639501a3a8140b7474.xml