BROKEN: Unfetchable (google code has gone away)

G

getopt

␢
As of today the FreeBSD ports tree has 314 broken ports.
217/314 ports are broken because of

Unfetchable (google code has gone away)

Does anyone have reliable background information of this issue?
Are these ports gone forever?
Do maintainers have no local backups?

Should we organize a fundraising for the needy Google conglomerate or does Google need a warm shitstorm?

What is the lesson to be learned from this issue?
 
getopt said:
As of today the FreeBSD ports tree has 314 broken ports.
217/314 ports are broken because of

Unfetchable (google code has gone away)

Does anyone have reliable background information of this issue?
Are these ports gone forever?
Click to expand...
According to Google Code home page the service is now down, but all projects should be available in their archive.
 
Maxnix said:
Just tried searching astro/gmapcatcher in their archive. An entry showed up, but I got a 404 for the project page. I hope they are still organizing their archive.
Click to expand...

astro/gmapcatcher was on Google Code. In March 2015, Google announced that it would be closing down Google Code on January 15, 2016. All admins of repositories on Google Code received respective notifications, and so I receveid it as well. We were asked to move our projects over to GitHub, using an automatic transfer tool provided by Google.

I moved my projects over to GitHub and adapted the Makefiles in my ports (sysutils/clone and sysutils/ipdbtools) respectively. astro/gmapcatcher is now on GitHub as well, even the old Google Code link http://code.google.com/p/gmapcatcher/ is redirected to the project on GitHub. I assume that the port maintainer did not take the necessary corrective actions.
 
Do maintainers have no local backups?
Click to expand...

FreeBSD ports has a policy that while FreeBSD could host the distfiles locally in case the upstream goes away they choose not to do so, ports that have no real upstream are treated as dead ports regardless of their importance to someone. This is to firmly draw the line on what is FreeBSD project maintained software and what is community maintained third party software.
 
Moreover, at this point, anybody listed as a maintainer for one of these ports has not performed their duty. They are clearly not maintaining it and the port should be thrown back in the "unmaintained" pool.
So many weeks have gone by and nobody including users has felt the need to update the port, host the tarball, etc. When that's the case, there's aren't any users and the port will eventually be deleted.

It's basically a status check. Most of these could be classified as abandonware -- either abandoned by the developer or abandoned by the ports maintainer. If no user tries to fix these ports, they're considered dead.

All the useful ports that were affected have likely been fixed. If you identify one of these marked broken that you think is useful, I'll ask what have done to fix it other than say "it's broken". That's not news; everybody knows this.
 
Are any of these branch or trunk ports that affect a lot of stuff? I'm hoping not, but afraid I'm gonna hear yes. If so the consequences could be far reaching.
 
Why would you think that? Do you think "far reaching consequences" wouldn't be addressed after a few months?
If a few months goes by and nobody notices, by definition the consequences are not far reaching.
 
Normally I would think that yes, but these past couple years life has taught me that nothing surprises me anymore. Anything is pretty much possible these day. A railroad with a dozen layers of fail-safe these days can still have a spectacular crash; and up to that moment of the crash everyone thought fail-safe was working. Was just asking a question. Sorry.
 
it was a loaded question. You expected to hear, "yes, there are trunk ports with far reaching consequences" per your comment, which naturally leads to conclusion that the port team collectively are at best negligent and at worst incompetent. Tone and word choice matters. Sorry.

edit: strike "expected to" and replace with "would not be surprised to" to be fair
 
marino said:
Why would you think that? Do you think "far reaching consequences" wouldn't be addressed after a few months?
If a few months goes by and nobody notices, by definition the consequences are not far reaching.
Click to expand...

Why should users notice? If they've got the port installed they could be using it constantly, and won't ever have reason to recompile it.
 
jamie said:
Why should users notice? If they've got the port installed they could be using it constantly, and won't ever have reason to recompile it.
Click to expand...

if you're suggesting that every single user of a port never attempts to install a missing package, nor attempts to compile over a period of nearly a year with at least one release of FreeBSD, I'm going to object to that suggestion as completely unrealistic. We're not talking about 1 user, we're talking about all of them. And if the port only has 1 user, then it probably doesn't deserve to be in the tree in any case.

So yes, 6 months is MORE than enough time to gauge if a port is missed. That's two complete new quarterly branches as well.
 
marino said:
if you're suggesting that every single user of a port never attempts to install a missing package, nor attempts to compile over a period of nearly a year with at least one release of FreeBSD, I'm going to object to that suggestion as completely unrealistic. We're not talking about 1 user, we're talking about all of them. And if the port only has 1 user, then it probably doesn't deserve to be in the tree in any case.

So yes, 6 months is MORE than enough time to gauge if a port is missed. That's two complete new quarterly branches as well.
Click to expand...

Are you suggesting that every user of a port is going to understand/know enough to say something?

In a perfect world, I'd agree with you, but there isn't the manpower to run such a tight ship. Do you think all maintainerless ports should be deleted too?

It just seems a shame to delete ports which still work, just because the source has gone. - I'd have happily taken over the responsibility of hosting the sources, and if something became broken and I was unwilling/unable to fix it, then dropping it due to being broken seems more reasonable to me. I was going to submit a PR until I read the whole scenario was being used as a usage litmus test, which disqualifies me as I only use one or two of those ports myself.

As for building, if there are no third-party dependency changes, I have ports that are installed for the lifetime of the major release. And I thought I was anal reinstalling them at that point rather than surviving on the -compat libraries!

Now, this would all be moot if the port-revision had been bumped when these ports were put on death-notice - then someone who professes to keep their system uptodate would have no excuse for not noticing the impending doom.. I for one would have noticed 6 months ago, and not now when it's too late.
 
somebody that chooses to build ports from scratch has to understand what they are doing. And all this information are in handbooks, including what to do when you get a "broken" notice. This has been going on for a complete year. Anybody that just found out now has only their own processes and lack of knowledge to blame. Maybe harsh, but true.

and to answer the question: yes, I expect the majority of port build users to understand enough to say something.

to address the other point: how does it really help the community that you drop the port as soon as it actually breaks? It means the port appears to be under maintainership but it's not. There are other responsibilities than just respond to a full breakage. Having maintainers that don't know how or are unwilling to actually maintain helps nobody.
 
You must log in or register to reply here.
Back
Top