Created attachment 146619 [details] sysutils/bsdconfig [maintainer] STAGE svn diff sysutils/bsdconfig adds MAINTAINER, STAGE Trivial modifications. please see svn(1) diff(1), attached. --Chris
REJECTED contains MAN definitions, untested despite several pleas for testing.
(In reply to John Marino from comment #1) > REJECTED > > contains MAN definitions, untested despite several pleas for testing. Not true (untested)! https://redports.org/~portmaster/20140901000100-35550-239478/bsdconfig-0.9.0.log https://redports.org/~portmaster/20140901000100-35550-239477/bsdconfig-0.9.0.log https://redports.org/~portmaster/20140901000100-35550-239476/bsdconfig-0.9.0.log I omitted RELENG_8, as it is [correctly] setup to IGNORE, and does so, on ${OSVERSION} < 900030 --Chris
Do you seriously not understand what is wrong with this submission and why it was rejected? I've told you several times. I even gave you a link on how to stage, which you should already have. The fact that you ran this grossly wrong port through testports indicates to me you have no idea why I rejected it. And I told you want tested means 15 minutes ago.
"through testports" => "through redports"
(In reply to John Marino from comment #4) > "through testports" => "through redports" Yes. I _did_ understand you -- really. :) But I'm _trying_ to get poudriere going today. So I am [for expedience sake] hoping to do so, UN-distracted. :) I'll be cleaning up, and adding/removing as necessary to get all of my submissions, cleaned, and tidied, soon. --Chris
Created attachment 146642 [details] staged patch I've attached a staged patch for the port. I'm not interested in taking over maintainer for the port personally. Poudriere testport logs at: http://poudriere.dan.tm/latest-per-pkg/bsdconfig/0.9.0_1/ I'm sure the port could do with some more work, but this solves the staging issue at least.
Daniel, thanks, moving to patch-ready status Chris, I believe that you think you understand, but you've continually made the same gross mistake after I've pointed out the mistake several times with pretty harsh language, e.g. "the MAN= mistake was frankly astonishing". I made such a big deal about it that I never expected to see the same mistake again, yet you made it several times after that. The most basic checks (which are available to you now), "make check-plist" would have caught this error. The error didn't get caught, so obviously it wasn't tested. The only explanation that makes sense is that you never understood why the "MAN<X>=" definitions were a problem, nor how to fix it, nor that redports can't detect it. So I truly believe there is a serious understanding issue underground. Please try to understand MAN pages fixes and all those "make" checks I listed previously. There is zero excuse not to do those, and I want to see the *OUTPUT* of those checks. I don't assume that you did them, I want proof.
Created attachment 146643 [details] request for maintainer FIX gross oversight properly remove bsdconfig.8.gz Guys, _Really_ sorry for my gross oversight en re; NO_STAGE=YES not having been removed. I also corrected some cleanup issues (bsdconfig.8.gz) having been left behind after deinstall. FWIW https://redports.org/~portmaster/20140901220001-25426-239986/bsdconfig-0.9.0.log https://redports.org/~portmaster/20140901220001-25426-239985/bsdconfig-0.9.0.log https://redports.org/~portmaster/20140901220001-25426-239984/bsdconfig-0.9.0.log Yes. I know. Not anyone's favorite. But it does [at least] show much of the process. Thanks, and sorry for the horrible oversight(s). --Chris
(In reply to John Marino from comment #7) > Daniel, thanks, moving to patch-ready status > > Chris, > I believe that you think you understand, but you've continually made the > same gross mistake after I've pointed out the mistake several times with > pretty harsh language, e.g. "the MAN= mistake was frankly astonishing". I > made such a big deal about it that I never expected to see the same mistake > again, yet you made it several times after that. > > The most basic checks (which are available to you now), "make check-plist" > would have caught this error. The error didn't get caught, so obviously it > wasn't tested. The only explanation that makes sense is that you never > understood why the "MAN<X>=" definitions were a problem, nor how to fix it, > nor that redports can't detect it. > > So I truly believe there is a serious understanding issue underground. > Please try to understand MAN pages fixes and all those "make" checks I > listed previously. There is zero excuse not to do those, and I want to see > the *OUTPUT* of those checks. I don't assume that you did them, I want > proof. Actually. I _do_ understand. But I _completely_ understand how you would arrive at your conclusion. I hit this port too late in the day, and in _too_ big a hurry. I just submitted a patch that I am confident addresses all of the previous issues this port had. IMHO I think it is also cleaner that the one just submitted before mine. :) Thanks, John, and sorry for all the bother. --Chris
Hi Chris, Your patch will fail a stage-qa check as it will leave references to the stagedir in the end resulting files due to your changes in the post-patch section. ====> Running Q/A tests (stage-qa) Error: 'share/bsdconfig/struct.subr' is referring to /usr/ports/sysutils/bsdconfig/work/stage Error: 'share/bsdconfig/packages/packages.subr' is referring to /usr/ports/sysutils/bsdconfig/work/stage Error: 'share/bsdconfig/packages/categories.subr' is referring to /usr/ports/sysutils/bsdconfig/work/stage etc. a simple 'make stage-qa' will give you the above info, or build using DEVELOPER=yes, or run it through poudriere.
(In reply to Daniel Austin from comment #10) > Hi Chris, > > Your patch will fail a stage-qa check as it will leave references to the > stagedir in the end resulting files due to your changes in the post-patch > section. > > ====> Running Q/A tests (stage-qa) > Error: 'share/bsdconfig/struct.subr' is referring to > /usr/ports/sysutils/bsdconfig/work/stage > Error: 'share/bsdconfig/packages/packages.subr' is referring to > /usr/ports/sysutils/bsdconfig/work/stage > Error: 'share/bsdconfig/packages/categories.subr' is referring to > /usr/ports/sysutils/bsdconfig/work/stage > > etc. > > a simple 'make stage-qa' will give you the above info, or build using > DEVELOPER=yes, or run it through poudriere. Thank you, John. For your input. I really appreciate it. I believe I have a suitable poudriere system built, and I am already running a bulk session [coincidentally] against sysutils/bsdconfig. I will (undoubtedly) discover what you've kindly informed me of. Thanks, again, John. --Chris
(In reply to C Hutchinson from comment #11) > (In reply to Daniel Austin from comment #10) > > Hi Chris, > > > > Your patch will fail a stage-qa check as it will leave references to the > > stagedir in the end resulting files due to your changes in the post-patch > > section. > > > > ====> Running Q/A tests (stage-qa) > > Error: 'share/bsdconfig/struct.subr' is referring to > > /usr/ports/sysutils/bsdconfig/work/stage > > Error: 'share/bsdconfig/packages/packages.subr' is referring to > > /usr/ports/sysutils/bsdconfig/work/stage > > Error: 'share/bsdconfig/packages/categories.subr' is referring to > > /usr/ports/sysutils/bsdconfig/work/stage > > > > etc. > > > > a simple 'make stage-qa' will give you the above info, or build using > > DEVELOPER=yes, or run it through poudriere. > > Thank you, John. For your input. I really appreciate it. > I believe I have a suitable poudriere system built, and I > am already running a bulk session [coincidentally] against > sysutils/bsdconfig. I will (undoubtedly) discover what you've > kindly informed me of. > > Thanks, again, John. > > --Chris Crap! Sorry, Daniel. I meant no offense. I'm so used to getting replies from John. It just didn't occur to me otherwise. Simply s/John/Daniel/g above. :) Thanks, Daniel. I hope you'll understand. --Chris
Chris, I moved it to patch-ready because daniel submitted a good patch. Apparently you didn't notice. I'm making your obsolete. His patch is tested. You cannot submit untested work for any reason (late in the day is certainly not an acceptable reason). Even this very last patch was untested. I have go as far as reject your PRs for lack of basic testing (e.g. make stage-qa) that you can do without having poudriere and you still aren't doing it. Read what daniel wrote again. If you don't understand what he means, keep at it until you do (or ask him)
Comment on attachment 146643 [details] request for maintainer FIX gross oversight properly remove bsdconfig.8.gz We are using the patch that daniel submitted
(In reply to Daniel Austin from comment #10) > a simple 'make stage-qa' will give you the above info, or build using > DEVELOPER=yes, or run it through poudriere. Specifically: Read that line again and again until you unstand what he means. We've mentioned "make stage-qa" 50 times and it seems that it's going over your head.
(In reply to John Marino from comment #15) > (In reply to Daniel Austin from comment #10) > > a simple 'make stage-qa' will give you the above info, or build using > > DEVELOPER=yes, or run it through poudriere. > > > > Specifically: Read that line again and again until you unstand what he > means. We've mentioned "make stage-qa" 50 times and it seems that it's > going over your head. OH. I understand. FWIW here is the make.conf(5) for poudriere DEVELOPER=yes USE_PORTLINT=yes USE_PACKAGE_DEPENDS=yes BATCH=yes WRKDIRPREFIX=/wrkdirs Am I missing anything? Why is there no poudriere.conf man page? I also can't find any "ports production" related material for poudriere. Only package related information. I really feel like the requirement for using poudriere, a bit premature. Given that the use of make(1) install/deinstall/stage/* plist/ {...} will frequently pollute the system it's on, and, as mentioned; the lack of pertinent info, where poudriere is concerned. I would probably have been better off using a dump(8) restore(8) scheme. To provide a fresh system to work in after thoroughly testing each port. Or perhaps devise some chroot(8) scheme. In short; I think I spent too much time attempting to employ a development scheme, on something that isn't [yet] readily adapted to, without a great deal of experimentation, trial, and error. Don't get me wrong, I am all too aware of that being a big part of general development. But in this case [poudriere] isn't [yet] the most expedient approach. Thanks for your thoughtful reply. --Chris P.S. I have no issue with your choice of Daniels patch, over mine.
DEVELOPER=yes isnt required in the poudriere make.conf (in fact, I think it now actively complains about it). It's automatically set when doing a testport run, or bulk -t I believe the sample poudriere.conf file contains all the documentation you'd need to adjust any settings within it. The whole purpose of poudriere is to ensure that package builds do not pollute your system. Using ZFS is the easiest way as it just uses snapshots to maintain a clean jail for each build. Thr trouble with building ports on a live system is that you never know what installed ports/packages are going to affect the port you're building. Poudriere only ever builds a port with the base system plus any build/run_depends from the port in question. This is why poudriere testport logs are desired - it can do testing well beyond any standard live system. I'm not sure what issues you have with poudriere. As far as I'm concerned it's the perfect tool for testing builds, and it even lets me test against 8.4, 9.3, 10.0 and 11.0 (in both i386 and amd64) on the same machine. (and with some patches to qemu, you can even cross-build for some ARM targets) It's an excellent tool, and I wish we had been able to use it sooner. We used to have to use tinderbox which is nowhere near as useful as poudriere (and more annoying to setup!)
(In reply to C Hutchinson from comment #16) > OH. I understand. FWIW here is the make.conf(5) for poudriere > DEVELOPER=yes > USE_PORTLINT=yes > USE_PACKAGE_DEPENDS=yes > BATCH=yes > WRKDIRPREFIX=/wrkdirs Daniel gave you an excellent answer, but I think the above means you don't understand. What I was talking about has *NOTHING* to do with poudriere. This must be the source of confusion. I finally gave up asking for poudriere logs and I started asking for something that I knew you could provide. Apparently you thought it was related to poudriere. > I really feel > like the requirement for using poudriere, a bit premature. A good "howto" is missing and I've asked a committer to write one in the official documentation, but poudriere itself is not immature at all. > Given that the use of make(1) install/deinstall/stage/* plist/ > {...} will frequently pollute the system it's on, and, as > mentioned; the lack of pertinent info, where poudriere is > concerned. This sentence makes no sense to me. It's obviously not true. > I would probably have been better off using a > dump(8) restore(8) scheme. To provide a fresh system to work > in after thoroughly testing each port. Or perhaps devise some > chroot(8) scheme. In short; I think I spent too much time > attempting to employ a development scheme, on something that > isn't [yet] readily adapted to, without a great deal of > experimentation, trial, and error. Don't get me wrong, I am all > too aware of that being a big part of general development. But > in this case [poudriere] isn't [yet] the most expedient approach. I also have no idea what you are attempting. You can literally have a working poudriere in 2 commands (1 = build jail, 2 = install portree).
oh dear, even Daniel's version has issues (were present always but not addressed) 5-second review: A) uses of PLIST_FILES ridiculous, needs a static pkg-plist B) do-install target commands are masked C) OSVERSION used without OPSYS, reason for excluding FreeBSD 8 unclear
Also do-install is roll-your-own and I don't see why. It should be able to use standard target if MAKE_ARGS adds these new variables.
A commit references this bug: Author: marino Date: Sun Sep 7 10:21:17 UTC 2014 New revision: 367504 URL: http://svnweb.freebsd.org/changeset/ports/367504 Log: Stage sysutils/bsdconfig PR: 193212 Reported by: Chris Hutchinson Patch by: Daniel Austin Major tweaks: marino Changes: head/sysutils/bsdconfig/Makefile head/sysutils/bsdconfig/pkg-plist
The makefile is now significantly cleaner. The port is still unmaintained. This is not a big deal because it's staged now. Chris, you don't have to automatically become the maintainer for every port you want fixed. You can always submit a non-maintainer patch to fix them.
(In reply to John Marino from comment #22) > The makefile is now significantly cleaner. > > The port is still unmaintained. This is not a big deal because it's staged > now. Chris, you don't have to automatically become the maintainer for every > port you want fixed. You can always submit a non-maintainer patch to fix > them. I _greatly_ appreciate your help, John. But probably more so, your patience, where all my dimwitted mistakes/oversights, are concerned. In the end. I'm finding that I'm too often attempting to keep too many things in the air, simultaneously. I've resolved to slow down, and take whatever time is required to do it _correctly_, rather than respond immediately. As to becoming MAINTAINER; I found most of the ports I chose, - still have value, in spite of their age - could be expanded, to have even greater value - probably more than anything; I need the experience - (ports education) Thanks again, John. You still have my vote for Commit Bit of the Year. :) --Chris