Re: Pkgsrc problems [ was: lang/python24 build problems]

["Jeremy C. Reed" <reed@xxxxxxxxxxxxx>]

> * Patches sit in NetBSD bugs database too long. Nobody seems to confident 
>   enough to commit patches or just don't care enough or patches remain 
>   just unnoticed etc. #36978 is good example, but there are others 
>   (net-snmp with this fix doesn't build any more, btw, but I'm also afraid 
>   that it isn't net-snmp issue now, but perl).

Using your #36978 example, if "pkgsrc" maintaines aren't "confident enough 
to commit patches", then please share upstream and try to get them to 
commit to official source.

Please continue to send reminders to the pkgsrc list(s) and to maintainers 
and to gnats.

> * Even if patches go into pkgsrc, they are not pushed to upstream. While I 
>   know there are a lot of people out there who don't think about it as 
>   important thing, it's extremely important IMHO.

Yes, that is the pkgsrc rule. Please help by submitting patches upstream 
too (don't put all the burden on pkgsrc developers).

> * Regular builds of pkgsrc HEAD on both our stable and HEAD with info 
>   about failures made available for community. I think that many of us 
>   (including me) can take a look at logs and try to fix issues. The 
>   important point is that we should try to catch as much of bugs as 
>   possible _before_ release.

That is a problem. The logs are available, but I don't see them all.
For example old logs at http://www.pkgsrc-box.org/reports/current/
(look under "meta" for report.html).

Also I don't see the recent reports on pkgbox.dragonflybsd.org
I made a symlink to see current status but no HTML reports yet:
http://pkgbox.dragonflybsd.org/reports2/

Justin: can you keep around old reports? And can you post about your 
completed build to pkgsrc-bulk@netbsd.org mailing list when each bulk 
build is done?

> There is at least one laternative as well of course - to branch pkgsrc 
> (fork isn't correct term here IMHO). So, we could fix our issues in "our 
> pkgsrc stable", build our packages from this "branch" etc. While 
> recommended by some people, I personally don't like the idea much though.

I don't like that either. More work.