19:23 <@Betelgeuse> If we have repoman verifying proper .xz usage then it's fine for me 19:23 <@Calchan> and its a yes from me 19:23 <@scarabeus> well it is nothing required to know if portage handles it iself :] 19:23 <@dertobi123> Calchan: that was my vote ;) 19:23 <@solar> fine as well on .xz 19:23 <@Calchan> can anybody answer Betelgeuse on repoman? ping me in private if you need voice 19:24 <+wired> and a yes from me 19:24 <@Calchan> we already have a majority anyway 19:24 <@scarabeus> iirc it does not bail out now, since we have xz packages in kde4.4 snapshots 19:24 <@scarabeus> and we supply the .xz tarballs and own extract function 19:24 <@scarabeus> only problem with it is depending on proper tar version that supports xz 19:25 <@Betelgeuse> scarabeus: Should we start forcing EAPI 3 or later for .xz? 19:25 <@Betelgeuse> Such a repoman patch is easy 19:25 <@ulm> .xz in eapi 3 fine for me as well 19:25 <@Betelgeuse> What does Portage do for .xz files in EAPIs 0 1 2? 19:25 <@scarabeus> we should push it throught, because few upstreams use only xz as sources, and the custom unpacks are lame 19:25 <@ulm> Betelgeuse: unpack ignores them 19:26 <@Betelgeuse> I remember some extension being pushed without EAPI bump but it was probably lzma related 19:26 <@Calchan> as far as I can see we have everything approved for eapi3 so unless you speak now we have final approval for it 19:26 <@Betelgeuse> ulm: Ok which is probably not what the user wants so EAPI 3 repoman check should be ok 19:27 <@ulm> Calchan: so we include xz or not? 19:27 <@dertobi123> we do 19:27 <@Calchan> ulm, looks like it, yes :o) 19:27 <@ulm> k 19:27 <@solar> Calchan: assume yes from me on the eapi3 mtime. 19:27 <@Betelgeuse> I will file a bug for repoman and xc 19:27 <@Calchan> solar, ok thanks 19:27 <@Calchan> Betelgeuse, good point
it is certainly in the realm of possibility that an .xz file is unpacked manually and/or used in a different way (installed and used at runtime) further, trying to `unpack` an .xz with EAPI={0,1,2} results in an error, so any ebuild added with this wouldnt even work ... someone adding that kind of ebuild wouldnt be stopped by a repoman warning
