[Bug 192347] [maintainer update] multimedia/universal-media-server: Update to 4.0.1 + FIXES

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192347

--- Comment #5 from John Marino <marino at FreeBSD.org> ---
(In reply to dreamcat4 from comment #4)
> (In reply to John Marino from comment #3)
> > But this one is risky because it's messing with /var which I don't think
> > Redports tests well.
> 
> If messing with var is risky, then what is the logic not to put it back to
> how it was previously, when was tested working fine??? Please explain.


This is getting to be too much drama for me.
You said you tested previous versions, presumably also with redports which I've
already told you can't fully test everything.  The logic reason for changing a
submission, which nobody does for fun, is that an error was found that redports
didn't catch.  So obviously going back to that error is not an option.

This is conjecture, i didn't commit these.  I don't know for sure why anything
was changed.


> BTW I am not setup to run poudriere. Mainly because it is too complex / too
> much hassle to run and install on my current system. I have very limited
> hardware available to me, which can only run on 9.2 (other reasons). 


It's actually not very complex.  It's not really a hassle either.  There's no
problem in providing a poudriere report from 9.2 either.


> If the
> FreeBSD project provides in future a public build service (or improve the
> current reports) with pourdiere on it, then of course I will be happy to
> make use of that.


Which is in the plans.  I just don't know when.  And at some point it won't be
optional, but rather a requirement for all submissions but there has to be good
infrastructure in place to require that.





> > Since there seems to be a lot more background to this than the PR suggests,
> > I think you also need to illustrate what change that you didn't make that
> > was added without your approval was committed and why it's wrong.
> 
> Everything in this patch, except "java" category. Is not been tested by me.
> Is broken for example the PLIST_SUB references in the rc.d script. And does
> not improve anything anyways.

how is this change correct?
%%PORTDOCS%%@dirrmtry %%DOCSDIR%%

You'd better be able to remove that directory without question, so dirrmtry is
wrong if it's not being shared with another port (which is rare)

DISTFILES=    UMS-${DISTVERSION}.tgz

That's equivalent.  You could have also defined USES+= tar:tgz though and
gotten rid of the extract suffix


this stuff:
@exec mkdir -p %%UMS_PROFILE_PATH%%

is wrong.  it could be 8 levels deep since it's a variable.  You only attempt
to remove one level.  But you've defined it unconditionally as
/var/run/${PORTNAME} so what purpose does having it as a PLIST_SUB have?  I
don't see one.


I haven't see the rc script, maybe all it needs is
"var/run/universal-media-server" hardcoded to it.  That actually sounds like an
oversight that needs fixing.  Most of the other stuff I don't see as mistakes.


> 
> > I'm going to recommend to whomever takes this PR that they run it though
> > poudriere and not rely solely on redports.
> 
> Sure. But at least, (if it is not too much trouble) then show me the
> poudriere build results / output by attaching it to this PR. Because reports
> is showing 0 issues. And my manual build (in it's own jail). Is showing 0
> issues. And I have followed the manual testing steps  in Porters Handbook
> (the check-orphans, etc) to the letter.

- Again, redports < poudriere.  You can pass in redports and fail poudriere.
- that implies you already ran make stage-qa which is good.  That's the check
that's missing from redports

-- 
You are receiving this mail because:
You are the assignee for the bug.