Both the 3.12-* patches appear to have been applied upstream as of the 3.14 tag and thus fail to apply in the ebuild. Deleting the epatches, leaving only epatch_user in src_prepare, works fine. Thanks. =:^)
Pushed as: > 07 Apr 2014; Sergei Trofimovich <slyfox@gentoo.org> btrfs-progs-9999.ebuild: > Drop upstreamed patches. Thanks to Duncan at #507008. I'll leave this bug open until Chris uploads tarball and we bump latest release in tree. Thanks Duncan!
Pushed updated snapshot as: >*btrfs-progs-3.14_pre20140414 (14 Apr 2014) > > 14 Apr 2014; Sergei Trofimovich <slyfox@gentoo.org> > +btrfs-progs-3.14_pre20140414.ebuild: > Bump snapshot up to latest stable upstream tag v3.14 (bug #507008 by Duncan). Thanks!
Why the _pre20140414 suffix? This appears to be v3.14 proper.
(In reply to redneb from comment #3) > Why the _pre20140414 suffix? This appears to be v3.14 proper. It's only to mark explicitly that we use non-upstream tarball. There are various ways to get into trouble when name tarballs in a generic way. 1. If Chris will get to packaging btrfs-progs release himself I'll switch SRC_URI to his (upstream) tarball without any distfiles collisions for users. 2. Upstream might think a bit more before packaging and include something minor into final release and we'll subtly diverge. 3. People who will randomly google for btrfs-progs-3.14 tarball on gentoo mirrors might get false impression of that thing being official release with varying consequences for them. Better try as hard as possible of not tricking people into such "collisions". When they happen and some bug pops up tracking issue down takes way more time, than even write this thing.
