Re: CVS commit: src/lib/libpthread
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 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. Currently ruby193 built on 6.0.1 works but fails on ruby193 built on netbsd-6 because the former doesn't use pthread_condattr_setclock(3). --- Izumi Tsutsui
Re: CVS commit: src/lib/libpthread
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 core. | IMO ticket #722 (pthread_condattr_setclock(3) addition) should be | reverted before 6.1 if it requires syscall bump for the real fix. It does not. | 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. | Currently ruby193 built on 6.0.1 works but fails on ruby193 built | on netbsd-6 because the former doesn't use pthread_condattr_setclock(3). Right. christos
Re: CVS commit: src/sys/net80211
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 ‘IEEE80211_QOS_HAS_SEQ’ *** Error code 1 Thomas On Fri, Mar 29, 2013 at 11:25:47PM -0400, Christos Zoulas wrote: Module Name: src Committed By: christos Date: Sat Mar 30 03:25:47 UTC 2013 Modified Files: src/sys/net80211: ieee80211.h Log Message: remove obsolete macro To generate a diff of this commit: cvs rdiff -u -r1.24 -r1.25 src/sys/net80211/ieee80211.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/kern
In article 20130401123134.dbf3b17...@cvs.netbsd.org, Martin Husemann source-changes-d@NetBSD.org wrote: - KASSERT(*timo 0); This should really not be failing since itimespecfix uses tick to correct the minimal timeout. christos
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 source-changes-d@NetBSD.org wrote: -KASSERT(*timo 0); This should really not be failing since itimespecfix uses tick to correct the minimal timeout. It does not for ts_sec == 0 and ts_nsec == 0. Martin
Re: CVS commit: src/lib/libpthread
In article 20130401132606.8cc2997...@rebar.astron.com, Christos Zoulas chris...@zoulas.com 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 mistake, we should have bumped. Note, that bumping would have just changed the nature of the failure, would not have fixed the problem. christos
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 6.1 silently fails on 6.0.1. It was a mistake, we should have bumped. Note, that bumping would have just changed the nature of the failure, would not have fixed the problem. Is it generally acceptable to bump minor (i.e. adding new public functions in libs) in release branches? I'm afraid not all third party programs use proper configure script. --- Izumi Tsutsui
Re: CVS commit: src/sys/kern
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 source-changes-d@NetBSD.org wrote: | - KASSERT(*timo 0); | | This should really not be failing since itimespecfix uses tick to correct | the minimal timeout. | | It does not for ts_sec == 0 and ts_nsec == 0. Probably cleaner to check for it there? Anyway, the question is really if we should bother to sleep at all for 0, 0 or shortcut the return. I think we should shortcut the return. christos
Re: CVS commit: src/lib/libpthread
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 6.1 silently fails on 6.0.1. | | It was a mistake, we should have bumped. | | Note, that bumping would have just changed the nature of the failure, would | not have fixed the problem. | | Is it generally acceptable to bump minor | (i.e. adding new public functions in libs) | in release branches? 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 rules down, so that we don't repeat the same problem on each release. Perhaps the best solution is to add the missing function on all branches, but that does not help those who did not upgrade. | I'm afraid not all third party programs use proper configure script. That can always cause issues.
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 itimerfix() and changing it there symetrically made a lot of things fail imediately, so I went for the simple fix. Anyway, the question is really if we should bother to sleep at all for 0, 0 or shortcut the return. I think we should shortcut the return. Shortcut is what I did, or do you mean something else? Martin
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 6.1 silently fails on 6.0.1. | | It was a mistake, we should have bumped. | | Note, that bumping would have just changed the nature of the failure, would | not have fixed the problem. | | Is it generally acceptable to bump minor | (i.e. adding new public functions in libs) | in release branches? 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 rules down, so that we don't repeat the same problem on each release. Perhaps the best solution is to add the missing function on all branches, but that does not help those who did not upgrade. Can't we simply revert ticket #722 (pthread_condattr_setclock(3) addition)? Is that function really necessary for 6.1? --- Izumi Tsutsui
Re: CVS commit: src/sys/kern
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 itimerfix() and changing it there symetrically made a lot
| of things fail imediately, so I went for the simple fix.
|
| Anyway, the question is really if
| we should bother to sleep at all for 0, 0 or shortcut the return. I think
| we should shortcut the return.
|
| Shortcut is what I did, or do you mean something else?
I meant fix it in itim{er,spec}fix. Yes, I will move the check out again,
because 0 means disable the timer.
christos
Re: CVS commit: src/lib/libpthread
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 rules down, so that we | don't repeat the same problem on each release. Perhaps the best | solution is to add the missing function on all branches, but that | does not help those who did not upgrade. | | 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. christos
Re: CVS commit: src/lib/libpthread
| 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 fixes) --- Izumi Tsutsui
Re: CVS commit: src/lib/libpthread
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 don't know if it is too late, I think it is too late. Releng knows best. christos
Re: CVS commit: src/usr.bin/tftp
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 compiling with CPUFLAGS=-march=armv7. Should be fixed properly one day... Please revert this and apply the corresponding -Wno-error=foo option only for GCC. Joerg
