:A solution is already there; Jeremy C. Reed has all the distfiles
:(updated) in /archive/distfiles/ - I was planning to switch to that when
:the next build started. I don't know if they match exactly with the
:quarterly release or the most recent pkgsrc, but it will be a timesaver
:either way.
:
On Sun, March 30, 2008 4:21 pm, Matthew Dillon wrote:
>Well, one thing I've noticed on pkgbox is that there are very large
> swaths
>of time where the whole build process seems to just stop, getting stuck
>(or slowed down) on a single ftp line. For example:
I saw this several times; I
Well, one thing I've noticed on pkgbox is that there are very large swaths
of time where the whole build process seems to just stop, getting stuck
(or slowed down) on a single ftp line. For example:
PID TT STAT TIME COMMAND
17447 p1 ILs0:00.01 -tcsh (tcsh)
17449 p1 IL
Oh, here's another possible issue. pkgbox is not turning on
net.inet.tcp.always_keepalive. That can cause connections that
go bad to hang forever.
I will turn it on.
-Matt
On Thu, Mar 27, 2008 at 10:08:45AM +0100, Robert Luciani wrote:
> Didn't you mention that the build system could be "distributed"?
I don't think it helps that much.
> If CPU is a bottleneck, perhaps some of us could lend out hardware?
> Also perhaps it would ease the burden you when checking for
Justin C. Sherrill wrote:
> On Wed, March 26, 2008 10:46 am, Hasso Tepper wrote:
>
>> * 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. T
Jeremy C. Reed wrote:
> 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.
The problem with this particular fix is that it's just tiny part of larger
patchset. To submit th
On Wed, March 26, 2008 10:46 am, Hasso Tepper wrote:
> * 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
Matthew Dillon wrote:
... What we would do is set up an automatic daily sync
from NetBSD to our pkgsrc CVS so we would always have the latest, but we
would also have the option of committing fixes into our tree to get
them off our table...
That's a great idea. I would have
> * 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
:> * Regular builds of pkgsrc HEAD on both our stable and HEAD with info=20
:> 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=20
:> important point is that we should try to catch as much of bugs as
On Wed, Mar 26, 2008 at 9:46 AM, Hasso Tepper <[EMAIL PROTECTED]> wrote:
> * 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
> (n
Hasso Tepper wrote:
At least some of us agreed that pkgsrc isn't shiniest package management
system - upgrade is real pain etc. This is not about these technical
issues. Pkgsrc is IMHO the best option we have at the moment, but ...
Pkgsrc is virtually the only option we have at the moment.
AF
Thomas E. Spanjaard wrote:
> Fixed in pkgsrc -current, and possibly 2008Q2 as well? The problem was
> some bluetooth preprocessor directives had a conditional only for
> NetBSD, but we use NetBSD's bluetooth stack as well.
Yeah, which reminds me that IMHO we should discuss _the_ issue with pkgsrc
14 matches
Mail list logo
