Solved Cloning /usr/ports

That is the correct URL. It encountered some kind of network error. Try pinging or a traceroute to git.freebsd.org.

Are you behind a NAT router? Does your ISP do some kind of proxying or tunneling? I've seen MTU issues through tunnels (professionally at $JOB) that cause these kinds of errors. The idea is to make sure your network connection is solid.
 
Hi cy@,

thank you for the reply.

Last night I actually did ping the web-site and got a reply back; the round trip being about 35 ms. I then repeated the command with the same failed response, so I tried to open the web-site in a web-browser, and it worked too. I noticed that some of the items were updated few (about 30 min) or so ago, so I though that maybe there is some problem with the update. However, this morning, I have the same problem.

I am behind NAT, but no proxy or tunnel. My network connection is excellent.

Kindest regards,

M
 
Can you clone any other git repo hosted on https?

E.g. you could try using the mirror on github instead: git clone https://github.com/freebsd/freebsd-ports.git /usr/ports.

If this doesn't work either, it really looks a lot like some "transparent https proxy" in the way...
 
Hi zirias@,

thank you for your reply.

The alternative mirror worked on the first attempt after four consecutive failures of the (official/primary?) one. I attempted the (official/primary?) one immediately after the clone from the mirror finished, but the clone failed again with the same error and not due to the /usr/ports being already cloned.

Thus, I conclude that it is not my side problem. Should I report the issue somewhere?

Are there any other mirrors? I could not find anything in the Handbook.

Hi elgrande,

thank you for the reply. No, I did not attempt the alternative, as according to the Handbook it has some limitations and, as I understand it, git is the preferred method,

Kindest regards,

M
 
I can reproduce it on my system. I have 1Gbps symmetric Internet access, so I'm pretty sure that's not the problem. I've been able to clone the ports tree in the past.

Edit: Anon SSH works, FWIW
Code: 
git clone https://git.freebsd.org/ports.git
Cloning into 'ports'...
error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504
fatal: error reading section header 'shallow-info'
git clone ssh://anongit@git.freebsd.org/ports.git                                      <
Cloning into 'ports'...
The authenticity of host 'git.freebsd.org (149.20.1.203)' can't be established.
ECDSA key fingerprint is SHA256:/UlirUAsGiitupxmtsn7f9b7zCWd0vCs4Yo/tpVWP9w.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'git.freebsd.org' (ECDSA) to the list of known hosts.
remote: Enumerating objects: 5449426, done.
remote: Counting objects: 100% (322290/322290), done.
remote: Compressing objects: 100% (256647/256647), done.
Receiving objects: 100% (5449426/5449426), 960.69 MiB | 18.17 MiB/s, done.
remote: Total 5449426 (delta 160790), reused 139702 (delta 63607), pack-reused 5127136
Resolving deltas: 100% (3249871/3249871), done.
Updating files: 100% (147352/147352), done.
 
This is weird indeed. FWIW, I have configured the official https url for fetching and a git fetch worked fine right now.

mefizto you can change the remote url any time you want, e.g. try git remote set-url origin https://git.freebsd.org/ports.git to change it back to the official repo. You could try whether a git pull works normally, maybe just git clone is affected. But then, using the github mirror doesn't really have any drawbacks (except for, well, depending on github).
 
Hi zirias@,

this is my first attempt on populating the /usr/ports with git, on the 13.1-RELEASE, since on on the 12.X-RELEASE I used svnlite(1), so I do not understand all the intricacies, e.g., the git clone vs. git fetch.

Is there a good git tutorial for simpletons?

Kindest regards,

M
 
Starting off with a warning of kind. Apart from the fact that git was set up as a distributed version control system, git does a lot of things differently than your ordinary version control system, like subversion for example. Things "differently" apply to the internal structure and inner workings of git but, also very much so to git's user interface. For users coming from more commonly known version control systems and more generally for most other new git users as well, it has been known that—more often than not—git's user interface and how git handles version control is rather hard to wrap one’s mind around; perhaps because the mind of git's inventor works differently.

I do not have a lot of experience with git users that are just starting and, if I may be so bold, I wouldn't think of you as someone on the level as you referred to in your message. It is always somewhat difficult to gauge what is likely to be helpful for someone just starting, because it depends a lot on one's background and how one learns new things. As git is intended to be used as a fully-fledged distributed version control system for software development it may be somewhat overwhelming for anyone new who perhaps is looking into git to use it for "just getting the source code". Although perhaps not the tutorial you had in mind, the following may help you on your way and contains a reference as well; no doubt others will add their own recommendations and I'm curious what will be mentioned.

___
Edit: added an entry that contains a link to Warner Losch's FreeBSD Subversion to Git Migration: Pt 2 Primer for Users
 
Last edited:
Hi zirias@,

thank you for the reply.
zirias@ said:
mefizto you can change the remote url any time you want, e.g. try git remote set-url origin https://git.freebsd.org/ports.git to change it back to the official repo. You could try whether a git pull works normally, maybe just git clone is affected.
Click to expand...
As noted in my post above, I am just starting, so I followed the handbook, which does not provide any alternatives to clone to download the initial ports collection and then uses pull for updates.

Hence my question re some resources, kindly answered by Erichans.

Hi Erichans,

thank you very much for your time writing the above and adding links.
Erichans said:
. . . f I may be so bold, I wouldn't think of you as someone on the level as you referred to in your message.
As git is intended to be used as a fully-fledged distributed version control system for software development it may be somewhat overwhelming for anyone new who perhaps is looking into git to use it for "just getting the source code".
Click to expand...

Absolutely no need to apologize for being be "so bold", you have correctly identified both points. In fact that is one of the reasons why I need to learn more about git - general knowledge, the ability to know other ways to work around potential issues as illustrated by both zirias@ and Jose, and not introduce inconsistencies to the "gotten source code."

Kindest regards,

M
 
Actually for only passively using ports, I have had good experience with portsnap, I do not see any backdraw except it lagging some hours behind...
 
Hi ,

you may well be correct, it may be my inexperience, but this is what I found in the Handbook (emphasis supplied):

Note that Portsnap updates are generated from a snapshot of the main branch of the Ports Collection and cannot be configured to use a different branch (for example, quarterly). If it is necessary to use a different branch of the Ports Collection (for instance as referenced earlier in conjunction with binary packages), then the Git method must be used.
Click to expand...

Kindest regards,

M
 
elgrande said:
Yeah, why'd you actually want to use any other branch than the main branch of ports?
Click to expand...
You *might* want a local repo with (mostly) stable package versions for a quarter? So, same reason you'd use the "quarterly" package repo. But if you have a need to change some port options, you can't just use the official packages.
 
zirias@ said:
You *might* want a local repo with (mostly) stable package versions for a quarter? So, same reason you'd use the "quarterly" package repo. But if you have a need to change some port options, you can't just use the official packages.
Click to expand...
Yeah, I was referring with "you" more to the OP than to "anyone"... (non native speaker here ;))
 
Hi elgrande,

elgrande said:
Yeah, I was referring with "you" more to the OP than to "anyone"... (non native speaker here ;))
Click to expand...
I am not quite sure, why you were referring "more to the OP than to 'anyone'". Would the fact that I have pointed to the disadvantage of using portsnap(8) and actually posted the reason for such, not indicate that I am considering a quarterly branch?

In addition to zirias@'s reasoning, I might use the quarterly branch e.g., initially, to familiarize myself with poudriere(8) and not wonder whether I am getting unexpected results due to a package(s) change or a mistake in configuration, or I might use the quarterly branch for server(s) that need to be stable and do not face Internet, and the main branch for laptops/workstations.

In other words, there are reasons why different people do things in different ways. Do you not agree?

Kindest regards,

M
 
mefizto said:
Hi elgrande,


I am not quite sure, why you were referring "more to the OP than to 'anyone'". Would the fact that I have pointed to the disadvantage of using portsnap(8) and actually posted the reason for such, not indicate that I am considering a quarterly branch?

In addition to zirias@'s reasoning, I might use the quarterly branch e.g., initially, to familiarize myself with poudriere(8) and not wonder whether I am getting unexpected results due to a package(s) change or a mistake in configuration, or I might use the quarterly branch for server(s) that need to be stable and do not face Internet, and the main branch for laptops/workstations.

In other words, there are reasons why different people do things in different ways. Do you not agree?

Kindest regards,

M
Click to expand...

Hey mefizto,

Obviously I was wrong here. Sorry no intention to be offending here.
Of course anyone should do as he/she likes...

Maybe my knowledge about ports branches is also a bit outdated... I read a bit about them like 10 years ago and my impression was that quarterly is a more or less random snapshot at a certain point in time. So I never saw any big advantages using it. I may have gotten that wrong and also this may have changed and quarterly now also undergoes some kind of regression / stability measures.

Anyhow I stand corrected. :cool:

Kind regards.
 
Hi elgrande,

elgrande said:
Obviously I was wrong here. Sorry no intention to be offending here.
Click to expand...
No, no, you were not wrong per se. I was just wondering whether you have noted some inconsitency in my writing. No offense was taken.

As I understand it, quarterly branch allows only security and other bug fixes that do not change the function of the port/package. Hence, there should be no surprise in recompiling; thus my consideration of them for servers.

I have been building packages from the main branch for laptop/workstation, albeit using synth(1).

Kindest regards,

M
 
mefizto said:
As I understand it, quarterly branch allows only security and other bug fixes that do not change the function of the port/package.
Click to expand...
Yeah that's my understanding, too.
I am wondering, if those packages nowadays undergo any kind of QA gate or if it basically is still a snapshot of a certain point in time (+later fixes ofc).
 
All ports/packages undergo Q/A. Maintainers are expected to do test builds using tools for testing (like portlint and poudriere testport) and of course to test the software at runtime. Committers are expected to make sure the build tests at least are complete. Any more complex change should always undergo review and find approval of another committer. No change (except for "blanket approval" things like simple build fixes) can ever be made without approval of the maintainer. And still errors will happen from time to time (even with reviews, you can overlook something, and also, upstream can have bugs you just don't discover doing your runtime tests), and should then be fixed ASAP. And if the error is present in the quarterly branch as well, it must be fixed there as well.

In a nutshell, quarterly is just good for reducing the work of an admin. Don't underestimate the amount of work that can be necessary on version upgrades of some software, e.g. to chase incompatible configuration changes. With quarterly, you get a branch where software is only ever upgraded when necessary to fix some problem (security or severe bugs), so most of the local admin work only needs to be done four times a year. Of course, you also avoid the occasional breakage in case some port upgrade is buggy in spite of all the Q/A controls.
 
zirias@ said:
[...] In a nutshell, quarterly is just good for reducing the work of an admin.
Click to expand...
Thanks Zirias; just to emphasize:

"an admin"* is you-the end user. When you are an end user responsible for managing your own FreeBSD system, the role of (sys)admin must be taken up by you.

___
* an admin does not refer to an admin of the ports tree or maintainers of individual ports in the ports tree.
 
zirias@ said:
All ports/packages undergo Q/A. Maintainers are expected to do test builds using tools for testing (like portlint and poudriere testport) and of course to test the software at runtime. Committers are expected to make sure the build tests at least are complete. Any more complex change should always undergo review and find approval of another committer. No change (except for "blanket approval" things like simple build fixes) can ever be made without approval of the maintainer.
Click to expand...
Of course I did not want to doubt the (imho excellent) QA control of the port maintainers.
I just was talking about my view, which is, that quarterly ports reduce the update overhead, but do not necessarily provide additional stability by a manual selection of certain versions.
That to say, latest ports vs. quarterly ports is imho a smaller win concerning stability than e.g. Debian stable vs. testing.

Edit: corrected wrong naming of ports.
 
You must log in or register to reply here.
Back
Top