This is in an effort to become maintainer for this port. I have already staged this port. As a result it works on versions 8, and 9. But needs additional [source, not port] work. To get it past clang. Expect an svn diff soon. Thank you for all your time, and consideration. --Chris
pre-emptive PR? :) We need the [well tested] diff to do something with it. Here's the plan. 1) I close the PR 2) you finish the diff 3) you test the diff with "poudriere testport" 4) you attach the diff and testlogs back to this very PR 5) you reopen it. 6) then I'll evaluate
(In reply to John Marino from comment #1) > pre-emptive PR? :) Not exactly. But I guess you could say that too. :) > > > We need the [well tested] diff to do something with it. > > Here's the plan. > > 1) I close the PR > 2) you finish the diff > 3) you test the diff with "poudriere testport" > 4) you attach the diff and testlogs back to this very PR > 5) you reopen it. > 6) then I'll evaluate Well. the "grim reaper" indicates that anything w/o STAGING, gets the axe, on the 31st. Unless there's a pr(1). While I realize this port is rather old. It appeared to still have some value left in it. Runs wonderfully on anything with a proper compiler (GCC). But hasn't been "clangified". The adjustments I've already made. Get it past the STAGE requirement. So the DEPRECATED bit can now be removed. Technically a new pr(1) should be opened after that, against the MAINTAINER. Letting them know it doesn't build with clang. No? I'll attach the current [and working] svn diff, I've already created that STAGEs this for all versions. --Chris
Created attachment 146375 [details] dns/posadis [maintainer] STAGE Here's the svn diff, as promised. ADDS STAGE MAINTAINER REPORTS https://redports.org/~portmaster/20140827054100-42886-237531/posadis-0.60.5_5.log https://redports.org/~portmaster/20140827054100-42886-237530/posadis-0.60.5_5.log --Chris
The previous 2 comments && svn diff, justify reopening this pr(1). :) Marked it: In Discussion --Chris
(In reply to C Hutchinson from comment #2) > Well. the "grim reaper" indicates that anything w/o > STAGING, gets the axe, on the 31st. Unless there's a pr(1). Well, a PR with a fix, not an I.O.U. > While I realize this port is rather old. It appeared to > still have some value left in it. Runs wonderfully on > anything with a proper compiler (GCC). But hasn't been > "clangified". The adjustments I've already made. Get it > past the STAGE requirement. So the DEPRECATED bit can now > be removed. Technically a new pr(1) should be opened after > that, against the MAINTAINER. Letting them know it doesn't > build with clang. Are you saying it doesn't build on the current Release of FreeBSD? It needs to. At the very least define "USE_GCC=yes" What about poudriere logs? I don't trust redports anymore after the last couple of PRs.
(In reply to John Marino from comment #5) > (In reply to C Hutchinson from comment #2) > > Well. the "grim reaper" indicates that anything w/o > > STAGING, gets the axe, on the 31st. Unless there's a pr(1). > > > Well, a PR with a fix, not an I.O.U. > > > > While I realize this port is rather old. It appeared to > > still have some value left in it. Runs wonderfully on > > anything with a proper compiler (GCC). But hasn't been > > "clangified". The adjustments I've already made. Get it > > past the STAGE requirement. So the DEPRECATED bit can now > > be removed. Technically a new pr(1) should be opened after > > that, against the MAINTAINER. Letting them know it doesn't > > build with clang. > > > Are you saying it doesn't build on the current Release of FreeBSD? It needs > to. At the very least define "USE_GCC=yes" > > > What about poudriere logs? > I don't trust redports anymore after the last couple of PRs. Sure. I get it. make -j100 seems dangerous. No? I'll attempt this locally, and provide the output. --Chris -- vote John Marino, for Commit Bit Of The Year
Created attachment 146385 [details] dns/posadis build output; devel/poslib is the cause of build failure Well. A little experimentation locally, seems to indicate that devel/poslib is the reason for failure. On building dns/posadis. See attached output from build session. --Chris
it seems like it's missing a head inclusion: [0m[1mconfiguration.cpp:35:16: [0m[0;1;31merror: [0m[1muse of undeclared identifier 'PATH_MAX'[0m char i_logfile[PATH_MAX];
(In reply to John Marino from comment #8) > it seems like it's missing a head inclusion: > > [0m[1mconfiguration.cpp:35:16: [0m[0;1;31merror: [0m[1muse of undeclared > identifier 'PATH_MAX'[0m > char i_logfile[PATH_MAX]; When I grow up. I want to be as good at this, as you. :) Thanks, John. I'll sort it out. --Chris --- vote John Marino, for Commit Bit Of The Year
my guess is that you need "#include <limits.h>" somewhere.
(In reply to John Marino from comment #10) > my guess is that you need "#include <limits.h>" somewhere. Thanks for the hint, John. You _are_, of course correct. :) My skills lie in: Perl, C, Assembler, scripting, XHTML, and CSS. So the C++, CLANG, and [Free]BSD macros, are still a WIP. C++, and CLANG aren't such a big deal. But the [Free]BSD ${MACROS} are such a moving target (are so flux). It's harder to keep up with. If you're not doing it all the time -- like you. :) Thanks again, John. --Chris
(In reply to C Hutchinson from comment #11) > (In reply to John Marino from comment #10) > > my guess is that you need "#include <limits.h>" somewhere. > > Thanks for the hint, John. You _are_, of course correct. :) but I don't see a fix submitted?
(In reply to John Marino from comment #12) > (In reply to C Hutchinson from comment #11) > > (In reply to John Marino from comment #10) > > > my guess is that you need "#include <limits.h>" somewhere. > > > > Thanks for the hint, John. You _are_, of course correct. :) > > > but I don't see a fix submitted? I'm still struggling with poudriere. I'm working on it simultaneously. But wanted to try to get some of those ports under the axe, at least _started_ before the got cut. I'll _definitely_ get any outstanding issues resolved soon. Thanks, and sorry for all the bother, John. --Chris
We need a tested fix ASAP -- this port is one of the few remaining to be pruned. No fix, it will get pruned anyway
(In reply to John Marino from comment #14) > We need a tested fix ASAP -- this port is one of the few remaining to be > pruned. > No fix, it will get pruned anyway OK. Took another look at this. Taking from your thoughtful hint, above. I visually grepped the (it's) source, and I have determined that the problem lies in the fact that system headers are the culprit. Something in use| availability of [PATH_MAX], has changed from RELENG_9 --> 10. That makes posadis' usage of it, no longer function, or, more likely; is no longer available for it to use. I'll continue to spend as much time as I have for it today, and report back. As to whether I'll have time enough to pursue this port further. Thanks, John. --Chris
Is this port really worth saving? We have a lot of DNS servers implementations, newer too. What is so special about this one? There have been no updates for 11 years. Can't we just let it die?
(In reply to John Marino from comment #16) > Is this port really worth saving? We have a lot of DNS servers > implementations, newer too. > > What is so special about this one? There have been no updates for 11 years. > Can't we just let it die? Sure. I thought it'd be a great learning exercise. But as my last bumble with net/beacon seems to reveal. I think it's safe to say, I've found my limit. Feel free to drop it, and this pr. I've got just enough. I'll spend my time more productively, getting the as yet unclosed pr's I have remaining, closed -- but correctly! :) Thanks, John. --Chris
setting PR to OBE (withdraw) This is for the best I think. It appears upstream ceased all work Feb 2005, soon after their 0.60.6 release in late 2004. http://posadis.sourceforge.net/