re: CVS commit: src/sys/arch/sparc
On Aug 2, 4:22am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: src/sys/arch/sparc | how can you say that commiting untsted code to sparc initialisation | is the right thing? there's absolutely nothing in the above statement | (or any part of tiering) that supports this, nor has it ever been an | OK thing to do in our community. It was a judgement call. I thought that it has a good chance to work. I was wrong. | IMO, the right fix for you to get past the build problem originally | would have been to disable -fno-common on sparc and file a PR. Or just file a PR instead. I don't like adding kludges that would certainly require undoing. christos
Re: CVS commit: src/sys/arch/sparc
On Aug 2, 3:10am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/sys/arch/sparc | christos@ wrote: | | > He did it by himself, but that was a good change. | | Even if it was a good change, no announcement is always a bad thing. | (unless it's approved by Core) Absolutely, that is true. I think he underestimated the amount of things that would break. christos
Re: CVS commit: src/sys/arch/sparc
On Aug 1, 4:38pm, a...@netbsd.org (David Brownlee) wrote: -- Subject: Re: CVS commit: src/sys/arch/sparc | On 1 August 2012 13:42, Izumi Tsutsui wrote: | > christos@ wrote: | >> It is simple enough to arrange to be notified about autobuild failures. | [...] | > | > See above. I'm afraid automated daily notifies which | > won't stop until "real fix" are too annoying. | > | > If it's sent ~bi-weelky like our gnats, it's fine for me. | | Possibly an on-failure/on-resume with a weekly "current fails"? | | It could even collate the data nightly and include the details for all | ports, so for example dreamcast-builds@ list gets an email like they | below they can be pretty certain it was an MI change that broke | something... That sounds good to me. christos
Re: CVS commit: src/sys
"Mindaugas Rasiukevicius" wrote: > Module Name: src > Committed By: rmind > Date: Wed Aug 1 23:24:29 UTC 2012 > > <...> > > Log Message: > Add BPF JIT compiler, currently supporting amd64 and i386. Code obtained > from FreeBSD. Also, make few BPF fixes and simplifications while here. > Note that bpf_jit_enable is false for now. FYI: FreeBSD has quite comprehensive regression tests for BPF. With some changes they run on NetBSD. http://www.netbsd.org/~rmind/regress/bpf_tests.tar.bz2 Out of 84 tests, all pass with BPF JIT enabled (and disabled). -- Mindaugas
Re: CVS commit: src/sys/modules/bpf
"Matt Thomas" wrote: > Module Name: src > Committed By: matt > Date: Thu Aug 2 00:22:32 UTC 2012 > > Modified Files: > src/sys/modules/bpf: Makefile > > Log Message: > Add missing paren. > > > To generate a diff of this commit: > cvs rdiff -u -r1.2 -r1.3 src/sys/modules/bpf/Makefile Seems that make ignored the syntax error in .if statement, as it compiles on e.g. x86 where the first check is true. Is this a bug in make? -- Mindaugas
Re: CVS commit: src/etc
On Thu, Aug 02, 2012 at 02:01:22AM +0400, Aleksej Saushev wrote: > "Julian Fagir" writes: > > > Module Name:src > > Committed By: jdf > > Date: Mon Jul 30 22:13:38 UTC 2012 > > > > Modified Files: > > src/etc: daily > > > > Log Message: > > Call `makemandb -q` instead of `makemandb`, as proposed by Edgar Fuss on > > tech-userlevel on 20th of July 2012, 12:38. > > Why does it not follow "silent-if-succesful" pattern? Because the warnings are all cases of "I don't know how to correctly deal with this input". Joerg
Re: CVS commit: src/etc
"Julian Fagir" writes: > Module Name: src > Committed By: jdf > Date: Mon Jul 30 22:13:38 UTC 2012 > > Modified Files: > src/etc: daily > > Log Message: > Call `makemandb -q` instead of `makemandb`, as proposed by Edgar Fuss on > tech-userlevel on 20th of July 2012, 12:38. Why does it not follow "silent-if-succesful" pattern? -- HE CE3OH...
re: CVS commit: src/sys/arch/sparc
> | We already have Tier definitions. > | > | In Tier II: > | >> ... keeping it working is the responsibility of the user community. > | : > | >> If the port is not working at release time, a release is done > | >> without the port and the port is moved down to the life support tier. > > Yes, but this is nebulous; according to it, I did the right thing by stepping > in and trying to fix it. If they fail to build constantly, then it is a > waste of time to keep building them. We can say that if they fail to build > for more than a month, they go to tier III. how can you say that commiting untsted code to sparc initialisation is the right thing? there's absolutely nothing in the above statement (or any part of tiering) that supports this, nor has it ever been an OK thing to do in our community. IMO, the right fix for you to get past the build problem originally would have been to disable -fno-common on sparc and file a PR. .mrg.
Re: CVS commit: src/sys/arch/sparc
christos@ wrote: > He did it by himself, but that was a good change. Even if it was a good change, no announcement is always a bad thing. (unless it's approved by Core) --- Izumi Tsutsui
Re: CVS commit: src/sys/arch/sparc
On Aug 1, 9:42pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/sys/arch/sparc | christos@ wrote: | | > On Aug 1, 8:23pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: | > -- Subject: Re: CVS commit: src/sys/arch/sparc | > | > | I agree you can blame port masters if they leave their ports broken | > | more than *weeks*. | > | > Fine, let's create an SLA then. Without an SLA, people don't know | > what's to be expected. | | We already have Tier definitions. | | In Tier II: | >> ... keeping it working is the responsibility of the user community. | : | >> If the port is not working at release time, a release is done | >> without the port and the port is moved down to the life support tier. Yes, but this is nebulous; according to it, I did the right thing by stepping in and trying to fix it. If they fail to build constantly, then it is a waste of time to keep building them. We can say that if they fail to build for more than a month, they go to tier III. | In Tier III: | >> Organic ports get moved here if they do not complete a build for | >> 6 months or are otherwise suspected to be broken. | | Tier was introduced to reduce extra work for developers working | on Tier I ports. If these are not enough for you, what's better? | All Tier II ports would have few MD new features, so | they don't need *daily* checks. That's the point. But this is not true in practice. | We can split autobuild script into Tier I/II ones | if people just want "0 failure" in daily buidable status. Yes, that would be better. | | > | If you claim port-masters must check buildable state *everyday* | > | against all MI changes without review or announcement, I'll resign | > | from all maintainership. | > | > No, read above. | | See above. I'm afraid automated daily notifies which | won't stop until "real fix" are too annoying. It is easy enough to put them in a folder with todays' MUA's. | If it's sent ~bi-weelky like our gnats, it's fine for me. That's fine too. | If we have enough man power to make it possible? | | But unfortunately we also need reasonable compromise | and I think that's the what the Tier system intended. We are trying to reach it. | I meant matt@, who committed the initial -fno-common change. | I don't know if it was done by Core's decision or not. He did it by himself, but that was a good change. christos
Re: CVS commit: src/sys/arch/sparc
On 1 August 2012 13:42, Izumi Tsutsui wrote: > christos@ wrote: >> It is simple enough to arrange to be notified about autobuild failures. [...] > > See above. I'm afraid automated daily notifies which > won't stop until "real fix" are too annoying. > > If it's sent ~bi-weelky like our gnats, it's fine for me. Possibly an on-failure/on-resume with a weekly "current fails"? It could even collate the data nightly and include the details for all ports, so for example dreamcast-builds@ list gets an email like they below they can be pretty certain it was an MI change that broke something... | Subject: HEAD builds: dreamcast FAIL | | Build report for: HEAD 201209091130 | | dreamcast: FAIL (was OK) | | All ports: FAIL (was OK) | acorn26 acorn32 algor alpha amd64 amiga amigappc arc atari bebox | cats cesfic cobalt dreamcast emips evbarm evbsh3-sh3eb evbsh3-sh3el | ews4800mips hp300 hp700 hpcarm hpcmips hpcsh i386 ibmnws iyonix | landisk luna68k mac68k macppc mipsco mmeye mvme68k mvmeppc netwinder | news68k newsmips next68k ofppc pmax prep rs6000 sandpoint sbmips-mipseb | sbmips-mipsel shark sparc sparc64 sun2 sun3 x68k zaurus | | All ports: FAIL (unchanged) | evbmips-mips64eb evbmips-mips64el evbmips-mipseb evbmips-mipsel evbppc | sgimips vax
Re: CVS commit: src/sys/arch/sparc
christos@ wrote: > On Aug 1, 8:23pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: > -- Subject: Re: CVS commit: src/sys/arch/sparc > > | I agree you can blame port masters if they leave their ports broken > | more than *weeks*. > > Fine, let's create an SLA then. Without an SLA, people don't know > what's to be expected. We already have Tier definitions. In Tier II: >> ... keeping it working is the responsibility of the user community. : >> If the port is not working at release time, a release is done >> without the port and the port is moved down to the life support tier. In Tier III: >> Organic ports get moved here if they do not complete a build for >> 6 months or are otherwise suspected to be broken. Tier was introduced to reduce extra work for developers working on Tier I ports. If these are not enough for you, what's better? > | But tier II ports are not primary even for their users and > | few people check status everyday. > | No chance to notice breakage without heads up about MI changes. > > It is simple enough to arrange to be notified about autobuild failures. All Tier II ports would have few MD new features, so they don't need *daily* checks. That's the point. We can split autobuild script into Tier I/II ones if people just want "0 failure" in daily buidable status. > | If you claim port-masters must check buildable state *everyday* > | against all MI changes without review or announcement, I'll resign > | from all maintainership. > > No, read above. See above. I'm afraid automated daily notifies which won't stop until "real fix" are too annoying. If it's sent ~bi-weelky like our gnats, it's fine for me. > | Ok, but why should it be defined in MI sys/conf/Makefile.kern.inc? > | > | Isn't it enought to define it per port (only tier I ports for example), > | or per kernel config file for debug purpose? > > Ideally we want to fix all the code ASAP. If we have enough man power to make it possible? But unfortunately we also need reasonable compromise and I think that's the what the Tier system intended. > | > | For sparc, the correct place seems in sparc/autoconf.c:bootstrap(). > | > | For sun2 it's sun2/locore2.c:_bootstrap(). > | > | Most other m68k ports foo_init() for pre-main initialization. > | > > | > It would be nice if the individual port-masters would proactively > | > check their ports so that they would remain buildable, and people > | > who have cross-port knowledge like you, would work to harmonize > | > these disparate and undocumented interfaces. > | > | It would be nice if you guys asked proper persons to fix their ports > | before you did try it yourself, so you don't have to check undocumented > | MD kludges. > | > | IMO "buildable but non-bootable state" is worse than non buildable. > | It just hides actual problems and makes late debug harder. > > It is not "you guys", it is just my fault. I don't know who you consider > co-responsible. As far as that goes, I will agree. I definitely seem to > have stirred the waters enough for the fix to be applied sooner than later, > but this is not the way to operate. I meant matt@, who committed the initial -fno-common change. I don't know if it was done by Core's decision or not. --- Izumi Tsutsui
Re: CVS commit: src/sys/arch/sparc
Well, the problem was that all details were hidden behind several layers of fallout by evil conspiracy of openssl update and -Wno-common changes, and a slow serious of partial fixes. A heads up for both of those changes would have been nice, but I guess we'll get over it. It seems to be mostly fixed now, next autobuild should have most archs building again (and hopefully working). Tests will resume... Martin
Re: CVS commit: src/sys/arch/sparc
On Aug 1, 8:23pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/sys/arch/sparc | I agree you can blame port masters if they leave their ports broken | more than *weeks*. Fine, let's create an SLA then. Without an SLA, people don't know what's to be expected. | But tier II ports are not primary even for their users and | few people check status everyday. | No chance to notice breakage without heads up about MI changes. It is simple enough to arrange to be notified about autobuild failures. | If you claim port-masters must check buildable state *everyday* | against all MI changes without review or announcement, I'll resign | from all maintainership. No, read above. | Ok, but why should it be defined in MI sys/conf/Makefile.kern.inc? | | Isn't it enought to define it per port (only tier I ports for example), | or per kernel config file for debug purpose? Ideally we want to fix all the code ASAP. | > | For sparc, the correct place seems in sparc/autoconf.c:bootstrap(). | > | For sun2 it's sun2/locore2.c:_bootstrap(). | > | Most other m68k ports foo_init() for pre-main initialization. | > | > It would be nice if the individual port-masters would proactively | > check their ports so that they would remain buildable, and people | > who have cross-port knowledge like you, would work to harmonize | > these disparate and undocumented interfaces. | | It would be nice if you guys asked proper persons to fix their ports | before you did try it yourself, so you don't have to check undocumented | MD kludges. | | IMO "buildable but non-bootable state" is worse than non buildable. | It just hides actual problems and makes late debug harder. It is not "you guys", it is just my fault. I don't know who you consider co-responsible. As far as that goes, I will agree. I definitely seem to have stirred the waters enough for the fix to be applied sooner than later, but this is not the way to operate. christos
Re: CVS commit: src/sys/arch/sparc
christos@ wrote: > On Jul 31, 8:51pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: > -- Subject: Re: CVS commit: src/sys/arch/sparc > > | christos@ wrote: > | > | Why don't you guys (as core? or individual developer?) post > | an announcement that mentions benefit of -fno-common and > | ask Tier II users to fix possible fallout, before putting > | random MD fixes that would cause annoying silent hangs? > > I can say the same for the port-masters who leave their ports > broken for days. I agree you can blame port masters if they leave their ports broken more than *weeks*. But tier II ports are not primary even for their users and few people check status everyday. No chance to notice breakage without heads up about MI changes. If you claim port-masters must check buildable state *everyday* against all MI changes without review or announcement, I'll resign from all maintainership. > But the benefits of -fno-common are pretty > obvious: mistakes like having char *foo in one file and int foo in > another, now will cause a build failure. Ok, but why should it be defined in MI sys/conf/Makefile.kern.inc? Isn't it enought to define it per port (only tier I ports for example), or per kernel config file for debug purpose? > | For sparc, the correct place seems in sparc/autoconf.c:bootstrap(). > | For sun2 it's sun2/locore2.c:_bootstrap(). > | Most other m68k ports foo_init() for pre-main initialization. > > It would be nice if the individual port-masters would proactively > check their ports so that they would remain buildable, and people > who have cross-port knowledge like you, would work to harmonize > these disparate and undocumented interfaces. It would be nice if you guys asked proper persons to fix their ports before you did try it yourself, so you don't have to check undocumented MD kludges. IMO "buildable but non-bootable state" is worse than non buildable. It just hides actual problems and makes late debug harder. --- Izumi Tsutsui
Re: CVS commit: src/sbin/newfs_msdos
In article <20120731135245.5213217...@cvs.netbsd.org>, Jonathan A. Kollasch wrote: > >Log Message: >Use correct values for minimum and maximum cluster counts for the various FAT >types. These values come from a publically-avaliable document of an >infallible source that must not be named due to a violation of the document's >license restrictions. This is justified by interoperability concerns. Please document those values in the manual page too, so that people know about the interoperability limits. christos
Re: CVS commit: src/sys/arch/sparc
On Jul 31, 8:51pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/sys/arch/sparc | christos@ wrote: | | Why don't you guys (as core? or individual developer?) post | an announcement that mentions benefit of -fno-common and | ask Tier II users to fix possible fallout, before putting | random MD fixes that would cause annoying silent hangs? I can say the same for the port-masters who leave their ports broken for days. But the benefits of -fno-common are pretty obvious: mistakes like having char *foo in one file and int foo in another, now will cause a build failure. | For sparc, the correct place seems in sparc/autoconf.c:bootstrap(). | For sun2 it's sun2/locore2.c:_bootstrap(). | Most other m68k ports foo_init() for pre-main initialization. It would be nice if the individual port-masters would proactively check their ports so that they would remain buildable, and people who have cross-port knowledge like you, would work to harmonize these disparate and undocumented interfaces. christos
Re: CVS commit: src/sys
On Tue, Jul 31, 2012 at 11:58:51AM -0500, Jonathan A. Kollasch wrote: > On Tue, Jul 31, 2012 at 03:50:39PM +, Manuel Bouyer wrote: > > Apply back changes that were reverted on Jul 24 and Jul 26 (general ata/wdc > > cleanup and SATA PMP support), now that I'm back to fix the fallouts. > > What about the fallout (that on inspection of the code I'm fairly sure > exists) that won't be immediately detected? The drive_type change is > far too significant to be applied with other unrelated changes as well. Something has to be changed in this area anyway, because we have to add a new type for port multipliers. The existing bitmask scheme doesn't scale. Yes, the change is large but there's not so many places where it matters. If you know of other problems, please report. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys
On Tue, Jul 31, 2012 at 11:32:02AM -0700, Hisashi T Fujinaka wrote: > On Tue, 31 Jul 2012, Jonathan A. Kollasch wrote: > > >On Tue, Jul 31, 2012 at 03:50:39PM +, Manuel Bouyer wrote: > >>Apply back changes that were reverted on Jul 24 and Jul 26 (general ata/wdc > >>cleanup and SATA PMP support), now that I'm back to fix the fallouts. > > > >What about the fallout (that on inspection of the code I'm fairly sure > >exists) that won't be immediately detected? The drive_type change is > >far too significant to be applied with other unrelated changes as well. > > Did you fix the problem with drives disappearing in amd64? I hope so. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
