Ports transitioned to git.

ShelLuser said:
Here's a voice that says: stop throwing wild statements around without any arguments to back up your claims.
Click to expand...
Fair enough. My personal observations seem to be incomplete, or ill-informed, in a number of ways.

ShelLuser said:
Lessee now... ports(7) which lists all build targets (you do realize that manual pages are actual manual pages on FreeBSD, right?), chapter 4.5 of the FreeBSD handbook (which even mentions Portmaster for crying out loud!) which obviously brings me to: portmaster(8) (remember my comment about manual pages?).

And about those binary packages: chapter 4.4 of said handbook.

This also brings us to pkg(8) which can refer you to pkg-install(8) and/or pkg-repo(8), if not from the command summary then surely from the SEE ALSO section.
Click to expand...
I'd argue that one can run into sticky situations (by experimentation and/or stupidity) that cannot be resolved by just reading the docs. But yes, it can help greatly to know them, and you're right: there is a lot of helpful documentation.

I guess when I was learning to use ports and occasionally fumbled it, I let "don't know, just use poudriere" statements on IRC get to me.

ShelLuser said:
So that's why Git got mentioned in the handbook long before the whole transition had been finished.
Click to expand...
Yes, there was a lot of documentation work. I was drawing incorrect conclusions from discussions here on the Forums.

ShelLuser said:
mtu said:
[*]The base system is meant to provide the tools needed for development, which is why it contains a compiler for example. The project also went to great pains to banish GPL'ed code from the base system. And yet it's practically impossible to do serious work on FreeBSD without git, which is GPLv2, and therefore cannot be part of the base system.
Click to expand...
I'm actually not too sure about this to be honest. From my point of view the only reason we have a compiler onboard is because src is a part of the whole distribution. When installing FreeBSD you can opt to have the Ports collection and source tree installed as well. But what good would those be without a compiler?

And installing ports or building your own setup does not imply development.
Click to expand...
That's true. I should have said "impossible to enter into development without git", because "serious work" can be anything. And yes, (re-)compiling the base system is a legitimate use for a compiler in base apart from development.

ShelLuser said:
What accounts for "being on your own" anyway? I mean... all the documentation is there, you only need to check it out, read and learn and then do things your way.
Click to expand...
In a world with unlimited time+energy for getting such things done, that's absolutely correct. Real-world constraints can, however, can make certain software solutions impractical, even if technically possible. By "being on your own", I meant: "not having anyone to consult with, or records of that thing having been done before".

Which, apparently, is exactly what happened to you when you …
ShelLuser said:
So all I did was check up with the Portmaster documentation, I studied pkg and learned about pkg-repo(8) and that resulted in my own "Poudrier & Synth"-free setup.

I even wrote a guide about that:

forums.freebsd.org

[Guide] Building a package repository with Portmaster

Hi gang! Editorial When it comes to maintaining a ports tree and setting up a package repository most people rely on software such as ports-mgmt/poudriere or ports-mgmt/synth. Interesting and definitely impressive projects for sure, but to be perfectly honest I never liked them myself. For the...
forums.freebsd.org forums.freebsd.org
Click to expand...
Seriously, great work. I'll be sure to study that and see if it can replace poudriere for my setup.

ShelLuser said:
FreeBSD is NOT about "either the devs way or the highway". Sorry, I personally find that comment borderline to insulting. But once again: that's me, myself and I again.
Click to expand...

See above. I didn't mean to say: "another way of using the system is impossible/forbidden/discouraged".

Just that it's probably harder, more time consuming, and lonesome – which can make it impractical for many people.

ShelLuser said:
Instead of throwing accusations around you'd actually make a difference if you'd provide examples. Tell us what documentation section is bad according to you, give us links and then we (= the community; those are all which matters) actually have something to work on. Then we can actually look at those links and improve them.
Click to expand...
Fair point. One little paragraph in the 13.0 Releaes Notes is my work, more to come.
 
A like alone is not enough in my opinion, so...

mtu said:
I'd argue that one can run into sticky situations (by experimentation and/or stupidity) that cannot be resolved by just reading the docs. But yes, it can help greatly to know them, and you're right: there is a lot of helpful documentation.
Click to expand...
I can agree with your argument here as well, and I also want to applaud you for raising it.

mtu said:
Seriously, great work. I'll be sure to study that and see if it can replace poudriere for my setup.
Click to expand...
Feel free to drop me a PM if you want some help with that. I cannot guarantee a quick response (I'm on and off so to speak) but I can promise that I won't brush it off as I normally do with PM's asking for help. Fair disclaimer (no offense): I do need to limit this to the whole "package repository" setup, not because I don't trust you but because I don't know you. (= ask me about this topic in private and I'll help in private, ask me about how to build FreeBSD from source and I'll politely direct you to the appropriate documentation or suggest you start a public topic).

mtu said:
See above. I didn't mean to say: "another way of using the system is impossible/forbidden/discouraged".
Click to expand...
For what's it worth I gained more respect for your stance. I still don't agree with your opinion (obviously) but I also think you raised some good points.

(edit)

grahamperrin said:
Posted yesterday:
Click to expand...
Bear in mind that I am not part of any official team or project or such. What you see there is me, as a person, trying to make a better place of this forum. It has nothing to do with the FreeBSD documentation project.

I really appreciate the acknowledgement, but it does not counter mtu 's statement within their context.
 
olli@ said:
Portsnap will continue to be supported. It is deprecated, but it will continue to work for several years, probably. Note that FreeBSD 13 ships with portsnap, too (and it’s even still in 14-current).
Click to expand...
I'd put it that way: It's scheduled for deprecation, at least, that's what I take from the "heads up" posted on freebsd-ports@ by portmgr@. To make the deprecation official, I agree with you, at least an official announcement would be necessary. All we can take for now is that deprecation (and later removal) probably will happen eventually.

But indeed, for now, portsnap is the documented method for "end users" to keep their ports tree up to date, so, nothing wrong with using it.
 
portsnap update does not yet provide the most recent updates (post-transition updates, I guess):

Code: 
root@mowa219-gjp4-8570p:~ # date && grep coturn /usr/ports/MOVED && portsnap update && grep coturn /usr/ports/MOVED && freebsd-version -kru && gitup ports && grep coturn /usr/ports/MOVED
Sat Apr 10 15:31:02 BST 2021
root@mowa219-gjp4-8570p:~ # date && grep coturn /usr/ports/MOVED ; portsnap update && grep coturn /usr/ports/MOVED ; freebsd-version -kru && gitup ports && grep coturn /usr/ports/MOVED
Sat Apr 10 15:31:26 BST 2021
Ports tree is already up to date.
14.0-CURRENT
14.0-CURRENT
14.0-CURRENT
# Host: git.freebsd.org
# Port: 443
# Repository: /ports.git
# Target: /usr/ports
# Want: 67227bea67da9c164fefcf30fa8b540e2b080f46
# Branch: main
# Action: clone
 * /usr/ports/.gitignore
 * /usr/ports/CHANGES
…
 * /usr/ports/MOVED
…
 - /usr/ports/x11/xmon/pkg-plist
net/coturn|net/turnserver|2021-04-09|Remove duplicate port: coturn is another name for turnserver
root@mowa219-gjp4-8570p:~ # date 
Sat Apr 10 15:49:37 BST 2021
root@mowa219-gjp4-8570p:~ #

If the local copy was truly up-to-date, then grep(1) should have found coturn (see <https://cgit-dev.freebsd.org/ports/commit/MOVED?id=b91f6147e4171425696f74c1f26de83a6ea3593a>).

I'm in no rush. Recalling:

grahamperrin said:
Portsnap and new git ports tree

…

<https://lists.freebsd.org/pipermail/freebsd-questions/2021-April/293732.html> (2021-04-07):

❝Work is in progress to convert the portsnap build infrastructure to git. The changes are just about ready for testing, but it will probably be a couple of days yet before it is deployed.❞
Click to expand...

– <https://lists.freebsd.org/pipermail/freebsd-questions/2021-April/thread.html#293732> there's not yet a follow up to Ed Maste's e-mail.
 
Note that the source trees for 11 and 12 will remain maintained in SVN until their demise. They are also available on git though. From 13.0 onward the source is only available through git.
 
I'm reading the remarks about portsnap being deprecated in a future version with great fear and amazement.

Requiring something from the ports tree in order to fetch the ports tree is, frankly, a good way to scare away new users. (and is generally called a catch-22)

For multiple reasons, I never use packages, building everything from source. The only exception to this is pkg itself, which I often immediately rebuild after bootstrapping it, just to make sure. We all know that mixing self-build ports and pre-built packages is generally a recipe for disaster.

For this reason, any new install I do generally gets these commands first:
freebsd-update fetch install
portsnap fetch extract

After which I install whatever I want for that specific machine.

When I want to use a box for dev purposes, git is something that'll be on there, but for the umpteen webservers I maintain, having git installed, along with all its dependencies, is a security risk and nothing more. Something like gitup would be a decent alternative, the speed penalty described in this thread doesn't bother me, if it gets too bad, it goes in a nightly cron job.

But it needs to be in base. If that means writing opengit, freegit or libregit so we can have a proper license, then that needs to be written.

And such a tool should preferably have an interface that removes the repository-related terminology from it. That's the power of portsnap: a normal end-user doesn't have to know or care where his sources are coming from: binaries, git, svn or Microsoft Sourcetree. He just want the latest version.
portsnap fetch update is much clearer to a non-developer than git clone.

If there is noone who is capable or willing to take that project up (I have neither the time nor the skills to do so, unfortunately), then quite simply, portsnap can't really be deprecated, as there is no viable alternative.

From Wikipedia:
In several fields, deprecation is the discouragement of use of some terminology, feature, design, or practice, typically because it has been superseded
Click to expand...

Until we have a git-based tool to fetch and update the ports-tree in base, portsnap hasn't been superseded by anything, so it can't really be regarded as deprecated.

And before someone says 'it's free software' or 'do it yourself': When I say: 'it needs to be done', I don't mean 'someone has to do it or I'll be mad'. I'm a dev, I'll manage fine without those tools, even if I won't like it. (not to mention that even if I were to write something, I don't have the authority to put it in base)


What I mean is : 'it needs to be done or we'll scare off new users'.

Thank you for reading.
 
Don't worry; if / when portsnap disappears, it will have been replaced with some other tool that allows you to do the same thing.
People who has been using FreeBSD long enough have been through a few of these transitions, so we sort of know how it is going to play out.
 
Itsacon said:
When I want to use a box for dev purposes, git is something that'll be on there, but for the umpteen webservers I maintain, having git installed, along with all its dependencies, is a security risk and nothing more. Something like gitup would be a decent alternative, the speed penalty described in this thread doesn't bother me, if it gets too bad, it goes in a nightly cron job.

But it needs to be in base. If that means writing opengit, freegit or libregit so we can have a proper license, then that needs to be written.
Click to expand...
Personally, I have moved my machines to net/gitup and must confess that it is working. gitup ports does the same thing as portsnap fetch update did.
 
Itsacon said:
Requiring something from the ports tree in order to fetch the ports tree is, frankly, a good way to scare away new users. (and is generally called a catch-22)
Click to expand...
When I started with FreeBSD many, many years ago, the only way to get the ports tree was by using CVS. In fact, the only way to update the OS (even -RELEASE versions) was by checking out the source and building it. There was no freebsd-update(8), there was no portsnap(8). The old package format was horrible to use, you needed additional tools in order to get dependencies correct and yes, you had to install those separately from the OS. Yet, I still managed. We all did. New and old users alike.

Itsacon said:
which I often immediately rebuild after bootstrapping it, just to make sure.
Click to expand...
Make sure of what exactly?

Itsacon said:
When I want to use a box for dev purposes, git is something that'll be on there, but for the umpteen webservers I maintain, having git installed, along with all its dependencies, is a security risk and nothing more.
Click to expand...
Managing a bunch of servers through ports is not very efficient and rather error prone. It'll also easily lead to configuration differences and you get a whole bunch of, otherwise useless, build dependencies. How's that for a security risk? Set up your own repository, then you can build from ports and have the benefits of that (options, default versions, etc) while keeping the ease of management of packages. It might take you a bit of time to set it all up but once you do you will wonder why you haven't done it sooner.
 
Argentum said:
Personally, I have moved my machines to net/gitup and must confess that it is working. gitup ports does the same thing as portsnap fetch update did.
Click to expand...

But how do you get gitup on a fresh system? If gitup was to become part of base, I'd be fine with that, but right now, it's not.

(Yes, you can get it through pkg, but if you're using pkg in the first place, why do you need the ports tree?)

SirDice said:
When I started with FreeBSD many, many years ago, the only way to get the ports tree was by using CVS. In fact, the only way to update the OS (even -RELEASE versions) was by checking out the source and building it. There was no freebsd-update(8), there was no portsnap(8). The old package format was horrible to use, you needed additional tools in order to get dependencies correct and yes, you had to install those separately from the OS. Yet, I still managed. We all did. New and old users alike.
Click to expand...
I started back in FreeBSD 3, I know what you mean. If I remember correctpy, csup or cvsup was part of base at some point, since you needed it to upgrade world, for example. We've come a long way, that's for sure. That's why I hope this doesn't become a step backwards from a usability perspective. I have fond memories of rebuilding world, but freebsd-update is infinitely more user friendly...

SirDice said:
Managing a bunch of servers through ports is not very efficient and rather error prone. It'll also easily lead to configuration differences and you get a whole bunch of, otherwise useless, build dependencies. How's that for a security risk? Set up your own repository, then you can build from ports and have the benefits of that (options, default versions, etc) while keeping the ease of management of packages. It might take you a bit of time to set it all up but once you do you will wonder why you haven't done it sooner.
Click to expand...
I know, I know. Problem is that the servers are spread over many locations and datacenters, so it would also require a (secure yet efficient) way to distribute the packages. And one of the reasons I don't use packages is that many of the servers have specific (differing) version requirements. I'll get around to it solving that problem someday. Hopefully. :-)

As for build dependencies; that's what pkg autoremove is for...
 
Itsacon said:
I'm reading the remarks about portsnap being deprecated in a future version with great fear and amazement.
Click to expand...
?? Beastie says:
  • Many people are afraid of change. But change is the only way to progress.
  • Many people are afraid of the unknown. But there is a simple remedy for this: learning.
 
Requiring something from the ports tree in order to fetch the ports tree is, frankly, a good way to scare away new users. (and is generally called a catch-22)
Click to expand...
That is not correct.
 
First, daily snapshots of the ports tree are made available as compressed tarballs (independent of portsnap) via FTP and HTTP(S), so you can use ftp(1) or fetch(1) to download an initial copy of the ports tree if you need to. Both of these tools are in FreeBSD’s base system.
 
Second, portsnap – even though deprecated – will probably stay for several years, and when it is finally removed, It’s safe to assume that there will be a replacement ready for use. That might be gitup (net/gitup) or something else yet to be written. Personally I think gitup would be perfect to go into base. It is BSD-licensed, dependency-free, and as easy to use as portsnap, while it supports more things than portsnap (i.e. it can download quarterly branches, and you can also use it to download a src or doc tree). Replacing portsnap with gitup is almost a no-brainer.
 
olli@ said:
?? Beastie says:
  • Many people are afraid of change. But change is the only way to progress.
  • Many people are afraid of the unknown. But there is a simple remedy for this: learning.
Click to expand...
As I tried to point out: I'm not afraid of change. I'm afraid of all this talk of portsnap already being deprecated, despite there being no valid replacement.

I'm fully onboard with replacing portsnap with something new, if needed. But that replacement should have been in base for at least a full version, in my opinion, before removing portsnap.

olli@ said:
That is not correct.
 
First, daily snapshots of the ports tree are made available as compressed tarballs (independent of portsnap) via FTP and HTTP(S), so you can use ftp(1) or fetch(1) to download an initial copy of the ports tree if you need to. Both of these tools are in FreeBSD’s base system.
Click to expand...
But that snapshot can then not be reliably used as a base for either portsnap or gitup.
If you install /usr/ports from a tarball (or installation media), and then run portsnap fetch update, it will tell you that the ports tree wasn't created using portsnap, and to use portsnap extract instead.

I haven't used gitup yet, but knowing git, cloning a repo into a directory that already contains a different but similar set of data (without the git info) is probably not a good way to get a stable repository.

So basically to use gitup you need to download the whole ports tree twice. Which can't be the intention.

olli@ said:
Second, portsnap – even though deprecated – will probably stay for several years, and when it is finally removed, It’s safe to assume that there will be a replacement ready for use. That might be gitup (net/gitup) or something else yet to be written. Personally I think gitup would be perfect to go into base. It is BSD-licensed, dependency-free, and as easy to use as portsnap, while it supports more things than portsnap (i.e. it can download quarterly branches, and you can also use it to download a src or doc tree). Replacing portsnap with gitup is almost a no-brainer.
Click to expand...

That's all I'm asking for :-)
 
  • Like
Reactions: mtu
Itsacon said:
Problem is that the servers are spread over many locations and datacenters, so it would also require a (secure yet efficient) way to distribute the packages.
Click to expand...
Put them on a VPS or some other server that's accessible over the internet. The server where you have to build ports will need to fetch their distfiles too so I assume it's not that problematic to have them fetch packages from a internet accessible host. If you sign your packages with a key you can be fairly sure it's your verified packages they're fetching.
Itsacon said:
And one of the reasons I don't use packages is that many of the servers have specific (differing) version requirements.
Click to expand...
A lot can already be archived through flavors. And when that's not good enough you can create multiple repositories quite easily (at least you can with poudriere). For a client I've set this up ages ago. We're currently migrating from the old Ruby 2.5 to Ruby 2.6 or 2.7 for example. So I have three repositories, one built for Ruby 2.5, one for 2.6 and one for 2.7. If I need to "switch" one of the machines to one version or another I simply change the repository and let pkg-upgrade(8) automatically figure it out. Only takes me a few minutes for each machine. Best of all, I'm in control of what, when and how.
 
Itsacon said:
As I tried to point out: I'm not afraid of change. I'm afraid of all this talk of portsnap already being deprecated, despite there being no valid replacement.

I'm fully onboard with replacing portsnap with something new, if needed. But that replacement should have been in base for at least a full version, in my opinion, before removing portsnap.
Click to expand...
That would be five years (FreeBSD supports a stable branches for a period of five years). That’s too much to ask for, in my opinion.
Currently it seems that portsnap will continue to be supported for the lifetime of the stable/13 branch that has just been created not very long ago, so that will be five years from now. That’s really plenty of time to put, say, gitup or something else in base.
 
But that snapshot can then not be reliably used as a base for either portsnap or gitup.
[…]
So basically to use gitup you need to download the whole ports tree twice. Which can't be the intention.
Click to expand...
So the situation at least doesn’t get worse, since it’s not different with portsnap either, right? ;)
 
Apart from that, a compressed tarball of the ports collection isn’t that large, so it’s really not a big deal. The current ports tree is just 60 MB.
 
It looks like something broke on (at least with my Poudriere) with the transition to Git. I am now getting a weird failure when trying to do a bulk build (with the -a option).

Code: 
[00:00:01] Creating the reference jail... done
[00:00:03] Mounting system devices for 12amd64-weekly-desktop
[00:00:03] Mounting ports/packages/distfiles
[00:00:03] Stashing existing package repository
[00:00:04] Mounting ccache from: /usr/local/poudriere/data/ccache/12amd64
[00:00:04] Mounting packages from: /usr/local/poudriere/data/packages/12amd64-weekly-desktop
[00:00:04] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
[00:00:04] Appending to make.conf: /usr/local/etc/poudriere.d/desktop-make.conf
/etc/resolv.conf -> /usr/local/poudriere/data/.m/12amd64-weekly-desktop/ref/etc/resolv.conf
[00:00:04] Starting jail 12amd64-weekly-desktop
[00:00:13] Logs: /usr/local/poudriere/data/logs/bulk/12amd64-weekly-desktop/2021-04-14_02h23m35s
[00:00:13] WWW: http://pkg.morante.net/poudriere/build.html?mastername=12amd64-weekly-desktop&build=2021-04-14_02h23m35s
[00:00:13] Loading MOVED for /usr/local/poudriere/data/.m/12amd64-weekly-desktop/ref/usr/ports
[00:00:15] Ports supports: FLAVORS SELECTED_OPTIONS
[00:00:15] Gathering ports metadata
[00:00:22] Warning: (databases/R-cran-DBI): Error: deps_fetch_vars: databases/R-cran-DBI already known as R-cran-DBI-1.1.1
[00:00:22] Warning: (databases/R-cran-RMySQL): Error: deps_fetch_vars: databases/R-cran-RMySQL already known as R-cran-RMySQL-0.10.21
[00:00:22] Warning: (databases/R-cran-RPostgreSQL): Error: deps_fetch_vars: databases/R-cran-RPostgreSQL already known as R-cran-RPostgreSQL-0.6.2_3
[00:00:27] Warning: (deskutils/affiche): Error: deps_fetch_vars: deskutils/affiche already known as affiche-0.6.0_11
[00:00:27] Warning: (deskutils/akonadi-calendar-tools): Error: deps_fetch_vars: deskutils/akonadi-calendar-tools already known as akonadi-calendar-tools-20.12.3
[00:00:27] Warning: (deskutils/akonadi-import-wizard): Error: deps_fetch_vars: deskutils/akonadi-import-wizard already known as akonadi-import-wizard-20.12.3
[00:00:29] Warning: (devel/9base): Error: gather_port_vars_port: Already had devel/9base (rdep=listed)
[00:00:29] Warning: (devel/ChipmunkPhysics): Error: deps_fetch_vars: devel/ChipmunkPhysics already known as ChipmunkPhysics-7.0.1_2
[00:00:29] Warning: (devel/ElectricFence): Error: deps_fetch_vars: devel/ElectricFence already known as electricfence-2.2.2_2
[00:01:08] Warning: (emulators/advancemame): Error: deps_fetch_vars: emulators/advancemame already known as advancemame-1.4_3
[00:01:08] Warning: (emulators/adamem): Error: deps_fetch_vars: emulators/adamem already known as adamem-1.0_4
[00:01:08] Warning: (emulators/advancemenu): Error: deps_fetch_vars: emulators/advancemenu already known as advancemenu-2.8_3
[00:01:25] Warning: (irc/bip): Error: deps_fetch_vars: irc/bip already known as bip-0.9.0.r4
[00:01:25] Warning: (irc/atheme-services): Error: deps_fetch_vars: irc/atheme-services already known as atheme-services-7.2.9
[00:01:25] Warning: (irc/anope): Error: deps_fetch_vars: irc/anope already known as anope-2.0.9_1
[00:02:02] Warning: (ports-mgmt/bsdadminscripts2): Error: gather_port_vars_port: Already had ports-mgmt/bsdadminscripts2 (rdep=listed)
[00:02:02] Warning: (ports-mgmt/chucky): Error: deps_fetch_vars: ports-mgmt/chucky already known as chucky-1.0_1
[00:02:02] Warning: (ports-mgmt/caronade): Error: gather_port_vars_port: Already had ports-mgmt/caronade (rdep=listed)
[00:02:14] Warning: (sysutils/3mux): Error: gather_port_vars_port: Already had sysutils/3mux (rdep=listed)
[00:02:14] Warning: (sysutils/3dm): Error: deps_fetch_vars: sysutils/3dm already known as 3dm-2.11.00.021_4,1
[00:02:14] Warning: (sysutils/44bsd-more): Error: deps_fetch_vars: sysutils/44bsd-more already known as 44bsd-more-20000521_1
[00:02:38] Warning: (www/R-cran-RgoogleMaps): Error: deps_fetch_vars: www/R-cran-RgoogleMaps already known as R-cran-RgoogleMaps-1.4.5.3_1
[00:02:38] Warning: (www/R-cran-bslib): Error: deps_fetch_vars: www/R-cran-bslib already known as R-cran-bslib-0.2.4
[00:02:38] Warning: (www/R-cran-Rook): Error: deps_fetch_vars: www/R-cran-Rook already known as R-cran-Rook-1.1.1_4
[00:02:53] Warning: (x11/3ddesktop): Error: deps_fetch_vars: x11/3ddesktop already known as 3ddesktop-0.2.9_14
[00:02:53] Warning: (x11/9menu): Error: gather_port_vars_port: Already had x11/9menu (rdep=listed)
[00:02:53] Warning: (x11/9box): Error: deps_fetch_vars: x11/9box already known as 9box-0.2.1_3
[00:03:00] Warning: (x11-themes/Kvantum): Error: deps_fetch_vars: x11-themes/Kvantum already known as Kvantum-qt5-0.19.0
[00:03:00] Warning: (x11-themes/adapta-gtk-theme): Error: deps_fetch_vars: x11-themes/adapta-gtk-theme already known as adapta-gtk-theme-3.95.0.11_1
[00:03:00] Warning: (x11-themes/adapta-backgrounds): Error: deps_fetch_vars: x11-themes/adapta-backgrounds already known as adapta-backgrounds-0.5.2.3
[00:03:03] Error: Fatal errors encountered gathering initial ports metadata
[00:03:03] Cleaning up
[00:03:04] Unmounting file systems

My port trees:

Code: 
# poudriere ports -l
PORTSTREE  METHOD    TIMESTAMP           PATH
default    portsnap  2019-01-08 23:54:32 /usr/local/poudriere/ports/default
monthly    portsnap  2020-07-07 20:11:39 /usr/local/poudriere/ports/monthly
weekly     svn+http  2021-02-19 04:04:42 /usr/local/poudriere/ports/weekly

I deleted "weekly" and recreated it as git:

Code: 
# poudriere ports -l
PORTSTREE  METHOD    TIMESTAMP           PATH
default    portsnap  2019-01-08 23:54:32 /usr/local/poudriere/ports/default
monthly    portsnap  2020-07-07 20:11:39 /usr/local/poudriere/ports/monthly
weekly     git+https 2021-04-14 01:35:19 /usr/local/poudriere/ports/weekly

I also updated the other port trees for the first time since the move to Git. They are now failing with the same problem. For example I try to use the tree named "monthly":

Code: 
[00:00:00] Creating the reference jail... done
[00:00:02] Mounting system devices for 12amd64-monthly-desktop
[00:00:02] Mounting ports/packages/distfiles
[00:00:03] Stashing existing package repository
[00:00:19] Mounting ccache from: /usr/local/poudriere/data/ccache/12amd64
[00:00:19] Mounting packages from: /usr/local/poudriere/data/packages/12amd64-monthly-desktop
[00:00:19] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
[00:00:19] Appending to make.conf: /usr/local/etc/poudriere.d/desktop-make.conf
/etc/resolv.conf -> /usr/local/poudriere/data/.m/12amd64-monthly-desktop/ref/etc/resolv.conf
[00:00:19] Starting jail 12amd64-monthly-desktop
[00:00:19] Logs: /usr/local/poudriere/data/logs/bulk/12amd64-monthly-desktop/2021-04-14_02h50m52s
[00:00:19] WWW: http://pkg.morante.net/poudriere/build.html?mastername=12amd64-monthly-desktop&build=2021-04-14_02h50m52s
[00:00:19] Loading MOVED for /usr/local/poudriere/data/.m/12amd64-monthly-desktop/ref/usr/ports
[00:00:21] Ports supports: FLAVORS SELECTED_OPTIONS
[00:00:21] Gathering ports metadata
[00:00:27] Warning: (databases/R-cran-DBI): Error: deps_fetch_vars: databases/R-cran-DBI already known as R-cran-DBI-1.1.1
[00:00:27] Warning: (databases/R-cran-RMySQL): Error: deps_fetch_vars: databases/R-cran-RMySQL already known as R-cran-RMySQL-0.10.21
[00:00:27] Warning: (databases/R-cran-RPostgreSQL): Error: deps_fetch_vars: databases/R-cran-RPostgreSQL already known as R-cran-RPostgreSQL-0.6.2_3
[00:00:30] Warning: (deskutils/affiche): Error: deps_fetch_vars: deskutils/affiche already known as affiche-0.6.0_11
[00:00:30] Warning: (deskutils/akonadi-import-wizard): Error: deps_fetch_vars: deskutils/akonadi-import-wizard already known as akonadi-import-wizard-20.12.3
[00:00:30] Warning: (deskutils/akonadi-calendar-tools): Error: deps_fetch_vars: deskutils/akonadi-calendar-tools already known as akonadi-calendar-tools-20.12.3
[00:00:30] Warning: (devel/9base): Error: deps_fetch_vars: devel/9base already known as 9base-20170701
[00:00:30] Warning: (devel/ElectricFence): Error: deps_fetch_vars: devel/ElectricFence already known as electricfence-2.2.2_2
[00:00:30] Warning: (devel/ChipmunkPhysics): Error: deps_fetch_vars: devel/ChipmunkPhysics already known as ChipmunkPhysics-7.0.1_2
[00:00:48] Warning: (emulators/adamem): Error: deps_fetch_vars: emulators/adamem already known as adamem-1.0_4
[00:00:48] Warning: (emulators/advancemenu): Error: deps_fetch_vars: emulators/advancemenu already known as advancemenu-2.8_3
[00:00:48] Warning: (emulators/advancemame): Error: deps_fetch_vars: emulators/advancemame already known as advancemame-1.4_3
[00:00:56] Warning: (irc/bip): Error: deps_fetch_vars: irc/bip already known as bip-0.9.0.r4
[00:00:56] Warning: (irc/atheme-services): Error: deps_fetch_vars: irc/atheme-services already known as atheme-services-7.2.9
[00:00:56] Warning: (irc/anope): Error: deps_fetch_vars: irc/anope already known as anope-2.0.9_1
[00:01:13] Warning: (ports-mgmt/bsdadminscripts2): Error: deps_fetch_vars: ports-mgmt/bsdadminscripts2 already known as bsdadminscripts2-0.3.0
[00:01:13] Warning: (ports-mgmt/chucky): Error: deps_fetch_vars: ports-mgmt/chucky already known as chucky-1.0_1
[00:01:13] Warning: (ports-mgmt/caronade): Error: deps_fetch_vars: ports-mgmt/caronade already known as caronade-0.4.0
[00:01:19] Warning: (sysutils/3dm): Error: deps_fetch_vars: sysutils/3dm already known as 3dm-2.11.00.021_4,1
[00:01:19] Warning: (sysutils/44bsd-more): Error: deps_fetch_vars: sysutils/44bsd-more already known as 44bsd-more-20000521_1
[00:01:19] Warning: (sysutils/3mux): Error: deps_fetch_vars: sysutils/3mux already known as 3mux-1.1.0
[00:01:29] Warning: (www/R-cran-RgoogleMaps): Error: deps_fetch_vars: www/R-cran-RgoogleMaps already known as R-cran-RgoogleMaps-1.4.5.3_1
[00:01:29] Warning: (www/R-cran-Rook): Error: deps_fetch_vars: www/R-cran-Rook already known as R-cran-Rook-1.1.1_4
[00:01:29] Warning: (www/R-cran-bslib): Error: deps_fetch_vars: www/R-cran-bslib already known as R-cran-bslib-0.2.4
[00:01:37] Warning: (x11/9menu): Error: deps_fetch_vars: x11/9menu already known as 9menu-1.10
[00:01:37] Warning: (x11/9box): Error: deps_fetch_vars: x11/9box already known as 9box-0.2.1_3
[00:01:37] Warning: (x11/3ddesktop): Error: deps_fetch_vars: x11/3ddesktop already known as 3ddesktop-0.2.9_14
[00:01:40] Warning: (x11-themes/adapta-backgrounds): Error: deps_fetch_vars: x11-themes/adapta-backgrounds already known as adapta-backgrounds-0.5.2.3
[00:01:40] Warning: (x11-themes/Kvantum): Error: deps_fetch_vars: x11-themes/Kvantum already known as Kvantum-qt5-0.19.0
[00:01:40] Warning: (x11-themes/adapta-gtk-theme): Error: deps_fetch_vars: x11-themes/adapta-gtk-theme already known as adapta-gtk-theme-3.95.0.11_1
[00:01:41] Error: Fatal errors encountered gathering initial ports metadata
[00:01:41] Cleaning up
[00:01:42] Unmounting file systems
 
I have the same metadata problem using portsnap:

Code: 
portsnap fetch
Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found.
Fetching snapshot tag from ipv4.aws.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Fetching snapshot generated at Wed Apr 14 02:09:41 CEST 2021:
0b344cd7869783c8d72504314f54f27b9ac6225ce21fae          88 MB  161 kBps 09m23s
Extracting snapshot... done.
Verifying snapshot integrity... done.
Fetching snapshot tag from ipv4.aws.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Updating from Wed Apr 14 02:09:41 CEST 2021 to Wed Apr 14 09:06:50 CEST 2021.
Fetching 5 metadata patches. done.
Applying metadata patches... done.
Fetching 5 metadata files... /usr/sbin/portsnap: cannot open a26ff8dcc066fedb59483514c8c5b17b8de665b8508bf0e74c1a171bf6c53c55.gz: No such file or directory
metadata is corrupt.

Any ideas how to solve this?
 
pantos said:
I have the same metadata problem using portsnap:

Code: 
portsnap fetch
Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found.
Fetching snapshot tag from ipv4.aws.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Fetching snapshot generated at Wed Apr 14 02:09:41 CEST 2021:
0b344cd7869783c8d72504314f54f27b9ac6225ce21fae          88 MB  161 kBps 09m23s
Extracting snapshot... done.
Verifying snapshot integrity... done.
Fetching snapshot tag from ipv4.aws.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Updating from Wed Apr 14 02:09:41 CEST 2021 to Wed Apr 14 09:06:50 CEST 2021.
Fetching 5 metadata patches. done.
Applying metadata patches... done.
Fetching 5 metadata files... /usr/sbin/portsnap: cannot open a26ff8dcc066fedb59483514c8c5b17b8de665b8508bf0e74c1a171bf6c53c55.gz: No such file or directory
metadata is corrupt.

Any ideas how to solve this?
Click to expand...
I've run into that every now and then. Just delete the portsnap cache and try again.
Something like

mv /var/db/portsnap /var/db/portsnap.broken
portsnap fetch extract
 
You must log in or register to reply here.
Back
Top