Seriously: - you've subversion ebuilds not only for seemingly non-live content but even STABLE ! - you've got a binary file in $FILESDIR, and it's even _huge_! flame@yamato pymol % find files -type f | grep -v CVS | xargs ls -lh -rw-r--r-- 1 flame flame 20K 2008-08-17 19:41 files/1.1/apbs-070604.patch.bz2 -rw-r--r-- 1 flame flame 467 2008-08-17 05:07 files/1.1/nosplash-gentoo.patch -rw-r--r-- 1 flame flame 2.6K 2008-12-19 03:02 files/1.1/pymol-1.1-r2-data-path.patch -rw-r--r-- 1 flame flame 524 2008-12-19 03:02 files/1.1/pymol-1.1-r2-shaders.patch -rw-r--r-- 1 flame users 332 2004-12-24 18:00 files/nosplash-gentoo.patch -rw-r--r-- 1 flame users 2.9K 2007-06-06 20:26 files/pymol-0.99_rc10-data-path.patch -rw-r--r-- 1 flame users 3.5K 2007-07-03 02:12 files/pymol-1.0-r1-data-path.patch Please do solve this ASAP.
(In reply to comment #0) > - you've subversion ebuilds not only for seemingly non-live content but even > STABLE ! Upstream only provides the code from the repo, but tags it with every new release. We could think about hosting a tarball ourself. The license allows this. > - you've got a binary file in $FILESDIR, and it's even _huge_! I cannot see any not allowed binary files! And I don't know why you think it is huge, but repoman thinks this not and as long as its that way, we don't need to change anything. > > flame@yamato pymol % find files -type f | grep -v CVS | xargs ls -lh > -rw-r--r-- 1 flame flame 20K 2008-08-17 19:41 files/1.1/apbs-070604.patch.bz2 > -rw-r--r-- 1 flame flame 467 2008-08-17 05:07 files/1.1/nosplash-gentoo.patch > -rw-r--r-- 1 flame flame 2.6K 2008-12-19 03:02 > files/1.1/pymol-1.1-r2-data-path.patch > -rw-r--r-- 1 flame flame 524 2008-12-19 03:02 > files/1.1/pymol-1.1-r2-shaders.patch > -rw-r--r-- 1 flame users 332 2004-12-24 18:00 files/nosplash-gentoo.patch > -rw-r--r-- 1 flame users 2.9K 2007-06-06 20:26 > files/pymol-0.99_rc10-data-path.patch > -rw-r--r-- 1 flame users 3.5K 2007-07-03 02:12 > files/pymol-1.0-r1-data-path.patch > > Please do solve this ASAP. >
Binary files are not allowed because we manage the tree in CVS which is renown for being a mess with binary files, but nonetheless the tree should only maintain SMALLER patches that won't make a difference on user systems: the stuff in the tree is downloaded by each and every user out there, whether they have a clue what pymol is or not. And I don't care what repoman says; if QA says you have to fix it, _you have to fix it_.
(In reply to comment #2) > Binary files are not allowed because we manage the tree in CVS which is renown > for being a mess with binary files, but nonetheless the tree should only > maintain SMALLER patches that won't make a difference on user systems: the > stuff in the tree is downloaded by each and every user out there, whether they > have a clue what pymol is or not. Okay, maybe I miss understand it. For clarification compressed patches aren't allowed in FILESDIR? > > And I don't care what repoman says; if QA says you have to fix it, _you have to > fix it_. > So rules of QA aren't the ones which repoman applies? Perhaps this discrepancy should be fixed, otherwise it is hard to do what QA wants!
I have a bug to make repoman stricter about warnings. The problem is that since all the files in the tree gets sent around to the users, there has to be consideration often on a case-by-case basis for whether a file > 10K is acceptable. In general, if you need to compress the file to get around repoman's refusal to commit the big file, then the file belongs to the mirrors either way. Maybe in a patchset tarball with the rest. Half the time I see compressed stuff was either big enough at the start to be deemed for mirrors propagation or was applying rebuilt autotools. So yeah, compressed patches are not accepted, and there's already a bug open for repoman to refuse committing those files.
Thanks for the lesson. I thought having files until 20k is allowed and compressing them is a valid way. I already fixed it for the ebuilds in the overlay and will check this once I am allowed to do.
