Ports transitioned to git.

Last edited:
If I should be worried I'm not and don't plan on changing anything till the ports tree is updated.

root@bakemono:/ # portsnap fetch update
Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found.
Fetching snapshot tag from ipv4.aws.portsnap.freebsd.org... done.
Ports tree hasn't changed since last snapshot.
No updates needed.
Ports tree is already up to date.
root@bakemono:/ # pkg audit -F
vulnxml file up-to-date
0 problem(s) in 0 installed package(s) found.
root@bakemono:/ # freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 12.2-RELEASE from update1.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 12.2-RELEASE-p5.
root@bakemono:/ #

But I don't always make the best decisions. Please feel free to correct me.
 
I just built www/youtube_dl from ports using ports-mgmt/portmaster with the flag set for LAME, am watching the video I just posted in that thread and got sound with it:

Code: 
===>  Installing for youtube_dl-2021.03.31
===>  Checking if youtube_dl is already installed
===>   Registering installation for youtube_dl-2021.03.31
Installing youtube_dl-2021.03.31...
If you want to use mp3 audio conversion please make sure multimedia/ffmpeg is
built with the "LAME" option enabled.


===>>> The following actions were performed:
    Installation of multimedia/librtmp (librtmp-2.4.20190330)
    Installation of multimedia/rtmpdump (rtmpdump-2.4.20190330)
    Installation of www/youtube_dl (youtube_dl-2021.03.31)

root@bakemono:/ #

Which is what I expected to happen.
 
Sir Dice has said that portsnap should not be affected, and I believe that, however, I just want to point out that I am using 12.2 RELEASE-p4 GENERIC amd64 and nothing has changed since March 31, 2021. Even when ports that I have don't change there is usually some port change or addition on a daily basis, so I am surprised to see zero changes for three days.
 
/var/db/ports is configuration (build options) written by ports, and has nothing to do with how you update your ports tree. Don't remove unless you want to forget everything configured with dialog4ports interface.
 
grahamperrin said:
– in general, --depth 1 is no longer recommended; see the red alert at https://docs.freebsd.org/en/articles/committers-guide/#_shallow_clone
Click to expand...
This is the committers' guide. For a committer, it makes little sense to omit history. Furthermore, the warning in this section could be relevant if you follow -STABLE or -CURRENT, depending on your local workflow. It isn't really relevant for releases, as you will know from the name (RELEASE-p1, RELEASE-p2 etc) which security fixes are already present.

If all you want is the most recent source of a branch, there's nothing wrong with --depth 1. In that case, you might also want to use net/gitup instead.
 
Zirias said:
portsnap is deprecated, … I don't know for how long it will still work. …
Click to expand...

Not yet deprecated.

There was:
  1. the plan – [HEADS UP] Planned deprecation of portsnap (2020-08-04) then
  2. amongst other things https://lists.freebsd.org/pipermail/freebsd-ports/2020-August/119114.html from the same author made clear that "… 11.x and 12.x will have it of course, …" and mentioned the prospect of full removal.
I should not expect deprecation until some time after the final RELEASE of 12.⋯ reaches end of life.

Postscripts

Cross reference: Deprecation of portsnap, and use of portsnap (2021-04-09)

I see portsnap being retired - what's the alternative? (2020-08-04, five pages, locked) but I haven't read it; I'm aware of alternatives.
 
Last edited:
Nitpick: Deprecated doesn't mean removed or defunctional. It just means an announcement, so everybody knows it is scheduled for removal and has time to adapt.

Still, I'm surprised portsnap is still built by default in 13-RC5. Maybe removal will be much later then...
 
Thanks,

… I'm surprised portsnap is still built by default in 13-RC5. Maybe removal will be much later then...
Click to expand...

This might help (a little) to paint the big picture:

Zirias said:
… If all you want is the most recent source of a branch, there's nothing wrong with --depth 1. …
Click to expand...

Will that eventually result in a different count? For example,

git -C /usr/src rev-list --count HEAD
 
With --depth 1, your local clone will start with a branch containing only the one latest commit, so, probably yes.

But that's not much different from extracting a source tarball ;) These things are only interesting if you intend to do things like work on the code yourself, or cherry-pick some patches, etc.
 
fernandel said:
On mailing list I saw recomendations for gitup. Should be /usr/ports and /var/db/ports removed and than run gitup -v 1 ports for example?
Click to expand...

Some notes about gitup(1):

* /var/db/gitup is default list location for gitup
* /usr/local/etc/gitup.conf is where you can change gitup default config.
* git.freebsd.org is the default host.
* Since 0.90_1 gitup is considered stable.
* Don't mix gitup and Git

/usr/ports is the target directory:
IF /usr/ports does not exist THEN it clones the repo.
IF /usr/ports exists THEN it'll pull down the latest commit.

443 is the default port. gitup relies on 443 for Smart HTTP over HTTPS

What's Smart HTTP

Git has different transfer protocol types:
1. git:// : unauthenticated access.
2. ssh:// : authenticated access.
3. Smart HTTP: Both authenticated and unauthenticated access (as opposite to dumb HTTP: prior to Git 1.6.6)

Smart HTTP
1. Smart HTTP relies on git-http-backend CGI script (Git over HTTP).
2. Smart HTTP operates similar to ssh:// and git://, but runs over HTTPS and uses HTTP authentication.
3. git-http-backend negotiates with client to send/receive data over HTTP.
4. git-http-backend allows Git client to access to the Git repo over http:// and https://
 
Code: 
git -C /usr clone https://git.freebsd.org/ports.git ports
Cloning into 'ports'...
fatal: repository 'https://git.freebsd.org/ports.git/' not found

Shouldn't this work?
 
Although I do wonder what went wrong, so the transition didn't finish according to the "expected" case schedule. After all, having done the same for docs and src, you'd expect experience should help ;)

At least, we're not at "worst" case schedule yet ;)
 
You must log in or register to reply here.
Back
Top