On Fri, Mar 29, 2013 at 06:53:22PM +, Radoslaw Kujawa wrote:
> Module Name: src
> Committed By: rkujawa
> Date: Fri Mar 29 18:53:21 UTC 2013
>
> Modified Files:
> src/usr.bin/tftp: Makefile
>
> Log Message:
> Work around "variable might be clobbered by longjmp" gcc warning when
On Apr 2, 1:46am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/lib/libpthread
| > I think it is too late now.
|
| Hmm. If core and releng think so, I have no further comment.
| (but I'm afraid we need 6.1_RC4 anyway since RC3 doesn't include pthread
fixes)
I d
> | Can't we simply revert ticket #722 (pthread_condattr_setclock(3) addition)?
> | Is that function really necessary for 6.1?
>
> I think it is too late now.
Hmm. If core and releng think so, I have no further comment.
(but I'm afraid we need 6.1_RC4 anyway since RC3 doesn't include pthread fixe
On Apr 2, 1:22am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/lib/libpthread
| > It depends on where we build 3rd party binaries. If we build on
| > the earliest branch there is no problem. But if we build in the
| > latest one there is. We should write the rule
On Apr 1, 6:20pm, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| On Mon, Apr 01, 2013 at 11:36:57AM -0400, Christos Zoulas wrote:
| > Probably cleaner to check for it there?
|
| Maybe, but I wasn't sure about the other callers. There is similar
| code in i
> | > >| Furthermore, was it safe to add a new pthread_condattr_setclock(3)
> function
> | > >| without libpthread minor bump? I'm afraid pkgsrc ruby193 (and other)
> | > >| binaries built on 6.1 silently fails on 6.0.1.
> | > >
> | > >It was a mistake, we should have bumped.
> | >
> | > Note, t
On Mon, Apr 01, 2013 at 11:36:57AM -0400, Christos Zoulas wrote:
> Probably cleaner to check for it there?
Maybe, but I wasn't sure about the other callers. There is similar
code in itimerfix() and changing it there symetrically made a lot
of things fail imediately, so I went for the simple fix.
On Apr 1, 11:43pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/lib/libpthread
| > >| Furthermore, was it safe to add a new pthread_condattr_setclock(3)
function
| > >| without libpthread minor bump? I'm afraid pkgsrc ruby193 (and other)
| > >| binaries built on
On Apr 1, 4:32pm, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| On Mon, Apr 01, 2013 at 02:28:02PM +, Christos Zoulas wrote:
| > In article <20130401123134.dbf3b17...@cvs.netbsd.org>,
| > Martin Husemann wrote:
| > >- KASSERT(*timo > 0);
| >
| > Thi
> >| Furthermore, was it safe to add a new pthread_condattr_setclock(3) function
> >| without libpthread minor bump? I'm afraid pkgsrc ruby193 (and other)
> >| binaries built on 6.1 silently fails on 6.0.1.
> >
> >It was a mistake, we should have bumped.
>
> Note, that bumping would have just cha
In article <20130401132606.8cc2997...@rebar.astron.com>,
Christos Zoulas wrote:
>
>| Furthermore, was it safe to add a new pthread_condattr_setclock(3) function
>| without libpthread minor bump? I'm afraid pkgsrc ruby193 (and other)
>| binaries built on 6.1 silently fails on 6.0.1.
>
>It was a mi
On Mon, Apr 01, 2013 at 02:28:02PM +, Christos Zoulas wrote:
> In article <20130401123134.dbf3b17...@cvs.netbsd.org>,
> Martin Husemann wrote:
> >-KASSERT(*timo > 0);
>
> This should really not be failing since itimespecfix uses tick to correct
> the minimal timeout.
It does not for ts_s
In article <20130401123134.dbf3b17...@cvs.netbsd.org>,
Martin Husemann wrote:
>- KASSERT(*timo > 0);
This should really not be failing since itimespecfix uses tick to correct
the minimal timeout.
christos
Now current/GENERIC doesn't compile:
In file included from ../../../../net80211/ieee80211_var.h:62:0,
from ../../../../dev/ic/an.c:108:
../../../../net80211/ieee80211_proto.h: In function ‘ieee80211_hdrsize’:
../../../../net80211/ieee80211_proto.h:109:2: error: implicit declaration of
function
On Apr 1, 9:18pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/lib/libpthread
| Will this workaround fix for PR lib/47703 be pulled to 6.1 release?
Yes,
| Does releng have any plan for all libpthread issue (including dlopen one)?
This is an open question to co
Will this workaround fix for PR lib/47703 be pulled to 6.1 release?
Does releng have any plan for all libpthread issue (including dlopen one)?
IMO ticket #722 (pthread_condattr_setclock(3) addition) should be
reverted before 6.1 if it requires syscall bump for the "real" fix.
Furthermore, was it
16 matches
Mail list logo
