Re: [proaudio] non working ebuilds (was non-things ebuild not builds)

[Gavin Pryke <gavinlee303@xxxxxxxxx>]

On Monday 05 November 2012 08:59:22 Jannis Achstetter wrote:
> Am 05.11.2012 02:33, schrieb Dominique Michel:
> > The problem with snapshots is that they are taking a lot of space on
> > the server. Anyway, this must be possible. But we can make
> > snapshot-like live ebuilds: As example, the subversion eclass provide
> > ESVN_REVISION. The doc claim that it should never be used into an
> > ebuild, but I already used it, and it worked just fine.
> 
> If you need webspace to host source tarballs I'm happy to put them onto
> my server.
> 
> > # ls /var/tmp/portage/media-sound
> > [...]
> 
> I'm personally interested in these:
> ambdec
> patchage
> qmmp
> zita-rev1
> jack-capture
> 
> and since all of them seem to work here: can you please post the
> build.log files somewhere so I can take a look at them to get them fixed?
> 
> Thanks :)
> 
> 	Jannis


Hi and apologies in advance for this burbling email, it is my thoughts on 
trying to maintain this overlay and the trouble we face.

I ran an emerge like this on an arm machine some time ago tinderbox style, 
tons of packages are broken and we don't have enough resources to cope.
We have enough problem with ebuilds not working gotten from tarballs let alone 
the amount of packages in tree that download from source repository that are 
mostly always broken after upstream change layout or build system soon after a 
commit.
At least a tarball snapshot should stay working unless some major upgrade like 
gcc or library dependency upgrade breaks it. With a live ebuild the smallest 
trivial change upstream can break the package and render it unusable at the 
worst possible moment, likely when one really have a use for whatever package 
is failing and one doesn't have time to dig into the ebuild/source to fix it.

If one wants to gauge how much needs looking at just take a look at repoman 
output after running it in the root of the pro-audio tree, it really is a 
mess! I am in no way saying my ebuilds are perfect, because nothing could be 
further from the truth; I have dumped my fair share of crap in the tree and
I have made many mistakes since my journey into packaging on Gentoo.
The sad thing is though lots of these errors could have been caught by running 
a simple repoman check before committing. I'm also not saying repoman can fix 
dodgy ebuilds, because it can't. It can however point out trivial errors 
(LICENSE, bad DEPEND's etc) even if the ebuild does "work".

I have space on my server with enough bandwidth for hosting snapshots too but 
I thought it would be better to have everything on tuxfamily rather than 
scattered around on different servers. No offense Jannis because this really 
is much appreciated!

I say this because have already changed or removed quite a few ebuilds where 
SRI_URI points to files that have been moved or deleted or a tarball that has 
been modified compared to official source, that's what patches are for! 
Snapshots for our overlay really wouldn't take that much space I think if the 
unreferenced files are cleaned out regularly.
I'm getting really tired of trying to maintain live ebuilds now purely because 
I don't have time for fiddling with source layout changes when I want software 
to just work. At least with a snapshot one can come to it and update as time 
permits. It would be different if there were dedicated maintainers for every 
package watching for changes but how many of the ~15 devs with commit access 
to this overlay are active at any one time? Not many when we have ~374 
packages!
For me snapshots are the only way forward. I'd rather compile a source 
checkout manually because it's easier than fiddling with live ebuilds that are 
broken often. In contrast I am happy to commit any ebuild that references a 
tarball in SRC_URI because less time is spent digging through source trying to 
find what changed.

I hope I have not offended anyone writing all this because I really do 
appreciate everyone's effort put into this overlay. It's just hard to keep 
coming back to this overlay when so much stuff keeps getting broken when it 
doesn't have to be like this.

We need more help.

WBR
Gavin