Date: Sun, 03 Aug 2014 12:02:14 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 192347] [maintainer update] multimedia/universal-media-server: Update to 4.0.1 + FIXES Message-ID: <bug-192347-13-Ogz3UW7v1R@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-192347-13@https.bugs.freebsd.org/bugzilla/> References: <bug-192347-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192347 --- Comment #3 from John Marino <marino@FreeBSD.org> --- (In reply to dreamcat4 from comment #2) > (In reply to John Marino from comment #1) > > Are there any test logs available? preferably with stage-qa tests? > > Yes: > > https://redports.org/buildarchive/20140802204647-04291/ > > If you want other type of 'stage-qa test' apart from reports build. Then > unfortunately I don't know what you might mean, so please explain what that > means. I build on reports.org build farm and manually on 9.2-RELEASE (inside > a jail). And all is fine. Redports is good, but not the best. Redports does not provide stage-qa checks yet, only poudriere does. This means a port can potentially pass Redports but fail on the poudriere-based Jenkins so a committer isn't fully confident in a redports-only test. But this one is risky because it's messing with /var which I don't think Redports tests well. > > Am I seeing the pkg-plist diff correctly in that there are blank lines in > > the pkg-plist now? I don't think those are going to fly > > The blank lines in pky-plist are only for readability the manual section at > end of file. They can be taken out if you want. But it's nothing new. The > original version of the port had them (4.0.0-b1) and was approved on that > basis. > > This patch puts back breakages in previous commit. There is no big cause to > worry, this ways have been thoroughly tested on 4.0.0-b1, which was just > like this patch ^^. > > I'm honestly tired of other people trying to mess this up and 'so called fix > things' that were not broken to begin with. Because delaying this commit for > other small petty reasons like that is certainly going to lead to problem > for other users. That is because of breakages committed just previously > (without my consultation or approval). What do you "muck this up"? This port has 3 main commits, all with PRs coming from you. If a committer changes what you submitted, it's because it didn't pass a test or wasn't done correctly. 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. I'm going to recommend to whomever takes this PR that they run it though poudriere and not rely solely on redports. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-192347-13-Ogz3UW7v1R>