Created attachment 175177 [details] mysqlbackup.diff
Comment on attachment 175177 [details] mysqlbackup.diff poudriere and portlint are ok
This will unbreak the port which was shamelessly broken by bulk-update.
sorry, ftp://ftp.renatasystems.org/pub/FreeBSD/ports/distfiles/ is not valid. It's empty. Had it not been empty, the port would not have been "shamelessly" marked broken. It "worked" because the framework fell back to the freebsd cache, which is not sufficient. Presumably you own renatasystems.org, so fix the problem and we can check again.
> It's empty. Not true. It is does not list directory index for you, but this does not mean it is empty. Try to fetch distfile by direct URL: ftp://ftp.renatasystems.org/pub/FreeBSD/ports/distfiles/mysqlbackup-2.8.tar.gz > Had it not been empty, the port would not have been "shamelessly" marked broken. Had it BEEN empty, why would one mark the port as broken instead of contacting port's maintainer first?
obviously it failed to fetch. All the 400+ ports were tested. I saw several with backup sites in addition to GOOGLE_CODE site where the mass-commit just removed the GOOGLE_CODE site. If you require additional information, ask mat@FreeBSD.org. I didn't have anything to do with it. That bit about not showing the directory doesn't help the cause. That's rare. You should consider allowing that particular directory to be listed.
maybe it was transient. It fetched for me now.
A commit references this bug: Author: marino Date: Wed Oct 5 18:33:08 UTC 2016 New revision: 423365 URL: https://svnweb.freebsd.org/changeset/ports/423365 Log: databases/mysqlbackup: unbreak (fetches fine) Maybe the renatasystems server was down briefly because this port fetches without any issue now. PR: 213002 Submitted by: maintainer Changes: head/databases/mysqlbackup/Makefile
> obviously it failed to fetch. > If you require additional information, ask mat@FreeBSD.org. I didn't have anything to do with it. I didn't asked anybody for anything. Obviously here is that mat@ shouldn't do that before contacting port's maintainer for whatever a reason the port has failed to fetch. And if I'd wanted for any additional info about that, I'd find committer's email by myself. To err is human.
mat does not need to ask your permission. The label of "Maintainer" doesn't mean that nobody can touch your port without asking first. This has been stated many, many times. If you are under this impression, it's going to cause you angst in the future. A member of portmgr doesn't need to consult with a maintainer first if rules and judgement dictate. If a port doesn't fetch by the primary master site, it gets marked broken, period, immediately, without asking permission. It's a standing rule. In this particular case, the port probably failed to fetch due to a transient error and it was just bad luck for you. It was part of a massive commit and as I hope you can imagine, the practicality of contacting all active maintainers in a timely fashion for 400+ ports is zero. It's not going to happen.
> mat does not need to ask your permission. Again, I didn't wrote anything about asking for my permission, > nobody can touch your port without asking first. ... nor that was written anywhere here in my comments. > In this particular case, the port probably failed to fetch due to a transient > error and it was just bad luck for you. This is what I call "shamelessly broken". There is no evidence that all of MASTER_SITES were broken and I insist the opposite. It wasn't bad luck for me, btw - people using this software were inconvenienced because of this false error and was forced to do what committer should have done before making a breaking change - contact maintainer. That is why it is reasonable to drop a note to ports maintainers like: "hey guys, I'm going to break your ports in a week or two, please ASAP fix your MASTER_SITES as Google Code is not working anymore, thanks!". Thats all. > It was part of a massive commit and as I hope you can imagine, the > practicality of contacting all active maintainers in a timely fashion for > 400+ ports is zero. It's not going to happen. No I can't imagine why it is a problem to notify maintainers of ports affected.
(In reply to Alexey Degtyarev from comment #10) "contacting port's maintainer for whatever a reason the port has failed to fetch". "was forced to do what committer should have done before making a breaking change - contact maintainer." That implies a 2-way conversation, a negotiation, or otherwise a diagnostic on a per-port basis. Please don't try to claim "I didn't say this or that". You basically did and I don't want to dissect and analyze exact wording. The best you could hope for is a one-way announcement to the maintainers of these ports and then what? They have X days to fix the ports. How? via PR, exactly like you did. So what is gained? I guess in a few select cases, say around 10% of the ports, they don't get broken temporarily. And it's limited to HEAD, none of the default Quarterly branches were affected. Don't forget that I took time out of my day to handle this PR. I didn't have to do that. No simple "thank you", no nod of appreciation, but rather I have to suffer your griping about something I had nothing to do with.
> That implies a 2-way conversation, a negotiation, or otherwise a diagnostic > on a per-port basis. Please don't try to claim "I didn't say this or that". > You basically did and I don't want to dissect and analyze exact wording. One more lie here. No need in asking for permission and all other stuff you have "implied" in your imagination. There is a huge difference between "asking for permission" and "contacting maintainer". So please don't mix apples and oranges. He could have notify maintainers even after he made a commit, postfactum. > Don't forget that I took time out of my day to handle this PR. > I didn't have to do that. No simple "thank you", no nod of appreciation, > but rather I have to suffer your griping about something I had nothing to do with. As well as no simple and usual "Committed, thank you!" from you, right? Instead, you are boring me with something I didn't ask for and something I didn't say. See my comment #8.
The google announced a shut down 18 months ago. You're the maintainer. At the end of the day, you neglected to remove GOOGLE_CODE from the list of master sites for those 18 months. I still don't know why the second master site didn't pass fetch. Either the server or the connection to the server was down (bad luck) or the test involved "seeing" the file, it which it's a combination of a bad test on mat's part and a bad decision to hide the file on your part. Don't worry about the future though, I'll never pick up a PR originated by you again. There's nothing like being called a liar after doing a good deed for somebody that isn't grateful, but I think I'll pass next time.
> The google announced a shut down 18 months ago. You're the maintainer. > At the end of the day, you neglected to remove GOOGLE_CODE from the list > of master sites for those 18 months. It looks like while trying to teach me what label of maintainer is meant for, you lost my point completely. The point is that making a port as BROKEN due to a fetch error is not something that should be done behind maintainer's back. > a combination of a bad test on mat's part and a bad decision to hide > the file on your part. There is no any sense to check directory index of MASTER_SITE. I'm pretty sure it is not the case here. If not, that would be a second bad thing on mat's part. Simply because a list of files does not mean that port's DISTFILE is actually there and/or fetchable by it's direct URL. > Don't worry about the future though, I'll never pick up a PR originated > by you again. I am sorry to hear such a conclusion, but should note that when I had commit bit, I would never act like you did in this PR. Except that I'd gratefully commit the patch. > There's nothing like being called a liar after doing a good deed for > somebody that isn't grateful, but I think I'll pass next time. You told a pure lie at least twice in this PR. I see no sorry about that.
(In reply to Alexey Degtyarev from comment #14) "The point is that making a port as BROKEN due to a fetch error is not something that should be done behind maintainer's back." This has happened hundreds of times in the last 3 years. You aren't the first and you won't be the last. This will not change. The maintainer will either A) figure it out and fix it (as intended) or B) he won't and the port will be either removed or given to another person to maintain. Either way, the intended thing happens (your opinion on the intent is just that.) "If not, that would be a second bad thing on mat's part." At this point I am going to assume you're incapable of taking any responsibility. Plenty of people always look for others to blame for their own mistakes, so you're in good company. "I would never act like you did in this PR. Except that I'd gratefully commit the patch." Yes, throwing around heavy and loaded words like "liar" which are sure to be the same offense in every culture is exceptional on your part. I can only dream to reach the level of decorum you have displayed. You have my sincerest apologies for not immediately groveling for you mercy as a representative of the organization that crossed you so. You won't have to worry about that happening again.