Bug 193212 - [stage] sysutils/bsdconfig
Summary: [stage] sysutils/bsdconfig
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: John Marino
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-01 00:19 UTC by Chris Hutchinson
Modified: 2014-09-07 17:32 UTC (History)
3 users (show)

See Also:


Attachments
sysutils/bsdconfig [maintainer] STAGE svn diff (1.67 KB, patch)
2014-09-01 00:19 UTC, Chris Hutchinson
no flags Details | Diff
staged patch (1.45 KB, patch)
2014-09-01 21:31 UTC, Daniel Austin
no flags Details | Diff
request for maintainer FIX gross oversight properly remove bsdconfig.8.gz (1.91 KB, patch)
2014-09-01 22:20 UTC, Chris Hutchinson
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Hutchinson 2014-09-01 00:19:34 UTC
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
Comment 1 John Marino freebsd_committer 2014-09-01 11:02:27 UTC
REJECTED

contains MAN definitions, untested despite several pleas for testing.
Comment 2 Chris Hutchinson 2014-09-01 20:49:45 UTC
(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
Comment 3 John Marino freebsd_committer 2014-09-01 20:55:21 UTC
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.
Comment 4 John Marino freebsd_committer 2014-09-01 20:56:14 UTC
"through testports" => "through redports"
Comment 5 Chris Hutchinson 2014-09-01 21:21:48 UTC
(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
Comment 6 Daniel Austin 2014-09-01 21:31:31 UTC
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.
Comment 7 John Marino freebsd_committer 2014-09-01 21:43:10 UTC
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.
Comment 8 Chris Hutchinson 2014-09-01 22:20:54 UTC
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
Comment 9 Chris Hutchinson 2014-09-01 22:33:09 UTC
(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
Comment 10 Daniel Austin 2014-09-01 22:39:05 UTC
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.
Comment 11 Chris Hutchinson 2014-09-02 00:35:10 UTC
(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
Comment 12 Chris Hutchinson 2014-09-02 02:23:14 UTC
(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
Comment 13 John Marino freebsd_committer 2014-09-02 05:27:19 UTC
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 14 John Marino freebsd_committer 2014-09-02 05:27:49 UTC
Comment on attachment 146643 [details]
request for maintainer FIX gross oversight properly remove bsdconfig.8.gz

We are using the patch that daniel submitted
Comment 15 John Marino freebsd_committer 2014-09-02 05:32:55 UTC
(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.
Comment 16 Chris Hutchinson 2014-09-02 07:29:04 UTC
(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.
Comment 17 Daniel Austin 2014-09-02 07:39:22 UTC
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!)
Comment 18 John Marino freebsd_committer 2014-09-02 14:49:59 UTC
(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).
Comment 19 John Marino freebsd_committer 2014-09-07 09:58:14 UTC
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
Comment 20 John Marino freebsd_committer 2014-09-07 09:59:49 UTC
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.
Comment 21 commit-hook freebsd_committer 2014-09-07 10:21:48 UTC
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
Comment 22 John Marino freebsd_committer 2014-09-07 10:24:04 UTC
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.
Comment 23 Chris Hutchinson 2014-09-07 17:32:07 UTC
(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