pkg 2.0.0 problems

Screenshot of commit messages that I'm seeing:
View attachment 21665
I'm happy bugs are getting fixed, but that still doesn't change my personal opinion that this should have been limited to 15-CURRENT if devs are gonna have a major version bump and a thorough re-working of how pkg(8) even functions. IMHO, this would be a nice feature announcement for the release of FreeBSD 15...
Screenshots for me.
screenshot-2025-02-05 06-12-49.png
screenshot-2025-02-05 06-17-39.png
 
One idea that I have is maybe hit F5 a few times? Sometimes those web front apps like devel/cgit don't pull in the data very well, and it takes a few tries before everything is pulled in.

Not impossible to use devel/git to pull the ports tree in and verify, but that takes skill and a certain kind of attitude towards spending time like that.
 
One idea that I have is maybe hit F5 a few times? Sometimes those web front apps like devel/cgit don't pull in the data very well, and it takes a few tries before everything is pulled in.

Not impossible to use devel/git to pull the ports tree in and verify, but that takes skill and a certain kind of attitude towards spending time like that.
Unfortunately, didn't work. So-called "super reload" (Shift+Reload button) didn't work, too.
 
Code:
$ host cgit.freebsd.org
cgit.freebsd.org is an alias for cgit.geo.freebsd.org.
cgit.geo.freebsd.org has address 103.2.119.199
cgit.geo.freebsd.org has IPv6 address 2402:9200:0:7::50:3
cgit.geo.freebsd.org mail is handled by 0 .
w3m -4 -dump 'https://cgit.freebsd.org/ports/tree/ports-mgmt/pkg/Makefile?id=8516fca970c1f68e684392b8923e462a00b548ba'
Code:
cgit logo index : ports      [main  ] [switch]
          FreeBSD ports tree

aboutsummaryrefslogtreecommitdiff [log msg  ] [          ] [search]

path: root/ports-mgmt/pkg/Makefile
blob: 1a756cf2adae46392c9b4e73cadebc52d3547bd8 (plain) (blame)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

generated by cgit v1.2.3 (git 2.25.1) at 2025-02-05 12:16:35 +0000
On chromium, same as #128.
 
Code:
$ host cgit.freebsd.org
cgit.freebsd.org is an alias for cgit.geo.freebsd.org.
cgit.geo.freebsd.org has address 103.2.119.199
cgit.geo.freebsd.org has IPv6 address 2402:9200:0:7::50:3
cgit.geo.freebsd.org mail is handled by 0 .
w3m -4 -dump 'https://cgit.freebsd.org/ports/tree/ports-mgmt/pkg/Makefile?id=8516fca970c1f68e684392b8923e462a00b548ba'
Code:
cgit logo index : ports      [main  ] [switch]
          FreeBSD ports tree

aboutsummaryrefslogtreecommitdiff [log msg  ] [          ] [search]

path: root/ports-mgmt/pkg/Makefile
blob: 1a756cf2adae46392c9b4e73cadebc52d3547bd8 (plain) (blame)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

generated by cgit v1.2.3 (git 2.25.1) at 2025-02-05 12:16:35 +0000
On chromium, same as #128.
Same results except timestamp.
Code:
% host cgit.freebsd.org
cgit.freebsd.org is an alias for cgit.geo.freebsd.org.
cgit.geo.freebsd.org has address 103.2.119.199
cgit.geo.freebsd.org has IPv6 address 2402:9200:0:7::50:3
cgit.geo.freebsd.org mail is handled by 0 .

Code:
% w3m -4 -dump 'https://cgit.freebsd.org/ports/tree/ports-mgmt/pkg/Makefile?id=8516fca970c1f68e684392b8923e462a00b548ba'
cgit logo index : ports      [main  ] [switch]
          FreeBSD ports tree

aboutsummaryrefslogtreecommitdiff [log msg  ] [          ] [search]

path: root/ports-mgmt/pkg/Makefile
blob: 1a756cf2adae46392c9b4e73cadebc52d3547bd8 (plain) (blame)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

generated by cgit v1.2.3 (git 2.25.1) at 2025-02-05 12:49:04 +0000
 
T-Aoki : Wow, I'm so sorry to hear about this! This looks like some unfortunate geopolitics at play. Can you provide a text dump of what happens when you pull the Ports collection in with
devel/git?
Code:
% git clone https://git.FreeBSD.org/ports.git
This SHOULD pull in the Makefile for ports-mgmt/pkg and the complete port history, right up to the moment you cloned the repo. If it doesn't - there should be something in the local logs on your machine to alert you to possibilities.

If that is too much, you could try looking at places other than FreeBSD's cgit mirror:
 
T-Aoki : Wow, I'm so sorry to hear about this! This looks like some unfortunate geopolitics at play. Can you provide a text dump of what happens when you pull the Ports collection in with
devel/git?
Code:
% git clone https://git.FreeBSD.org/ports.git
This SHOULD pull in the Makefile for ports-mgmt/pkg and the complete port history, right up to the moment you cloned the repo. If it doesn't - there should be something in the local logs on your machine to alert you to possibilities.

If that is too much, you could try looking at places other than FreeBSD's cgit mirror:
I already have cloned repo and git pull --ff-only is working normally even in this time window. So the problem is NOT in git repo, but cgit frontend.
 
Yes, 1.21.3 can still be used. However, on 14.2 and on 'latest' now also pkg v. 2.0.5 as a package is available. When you can get 2.0.5 comfortably by just using pkg update and pkg upgrade pkg I would suggest you consider doing that; in the end it is your decision.

If you experience any problems with 2.0.5, these should be reported.

Edit: I'm a bit puzzled why amd64-FreeBSD 13.x and 'latest' still hasn't advanced to the package 2.0.5; seems to be stuck at 2.0.3.
 
pkg 2.0.4 and 2.0.5 seems to work correctly unless prioritized multiple repositories (for example, local repo by poudriere and official, prefer local) are used.
For example, if full flavor of devel/llvm18 is installed and pkgs in local repo depends on it, pkg attempts to pull in lite flavor, thus, conflict, and want to deinstall everything depending on the full flavor. Not tried on 2.0.5 yet, but 2.0.4 behaved as such for me.
If explicitly specify local repo only usung -r option, this problem does not happen at least for me.

So it is adviced for anyony using test kmod repo, upgrade should be done with specifying regular official repo, and once finished, upgrade specifying kmod repo only to make sure wanted build of kmod pkgs are used.
 
Looks, like it. However, I find it somewhat surprising that it manages to serve all the numbered lines for this particular file correctly, without showing its contents that is.
I suspect that cgit server I'm introduced to is somehow mis-configured, or intentionally limit contents to decrease network traffic (DDoS again?).
 
pkg 2.0.4 and 2.0.5 seems to work correctly unless prioritized multiple repositories (for example, local repo by poudriere and official, prefer local) are used.
For example, if full flavor of devel/llvm18 is installed and pkgs in local repo depends on it, pkg attempts to pull in lite flavor, thus, conflict, and want to deinstall everything depending on the full flavor. Not tried on 2.0.5 yet, but 2.0.4 behaved as such for me.
If explicitly specify local repo only usung -r option, this problem does not happen at least for me.

So it is adviced for anyony using test kmod repo, upgrade should be done with specifying regular official repo, and once finished, upgrade specifying kmod repo only to make sure wanted build of kmod pkgs are used.
I couldn't find a problem related to this 'priority-poudriere-2.0.{4|5}'* issue; either at pkg issues - github or dashboard view PR tagged with 'ports-mgmt/pkg', but I could have overlooked something.

IF that 'priority' specific problem in combination with 'kmods' and poudriere (I don't have such a set up) still occurs with 2.0.5, then, unfortunately the pkg 2.0.x series seem still without a final ending. As far as you know, is there already a known report (PR or issue) linked to 2.0.5 about this particular problem?

Related to this cgit behaviour: with Charlie_ and yourself this is now confirmed: is 'FreeBSD' aware (or has been made aware) of this?

___
* Given that 2.0.5 is 'live', I'm hoping that we can put 2.0.4 behind us; concentrate on 2.0.5 and and getting all 'latest' package repositories up to that version (or advanced beyond 2.0.5 if necessary).
 
I couldn't find a problem related to this 'priority-poudriere-2.0.{4|5}'* issue; either at pkg issues - github or dashboard view PR tagged with 'ports-mgmt/pkg', but I could have overlooked something.
At least I've not yet filed a PR for this, as I still don't have enough data not to confuse the developer.

IF that 'priority' specific problem in combination with 'kmods' and poudriere (I don't have such a set up) still occurs with 2.0.5, then, unfortunately the pkg 2.0.x series seem still without a final ending. As far as you know, is there already a known report (PR or issue) linked to 2.0.5 about this particular problem?
I've not using kmod repo, but local repo and official repo.
And why I've posted this was because newbies not yet enough understanding what they're doing could fall into the pitfall if regular + kmod combination if something alike happenes with the combination.
And with quite rough search (search "pkg" and look into PRs having latest update date later than 2.0.5 and having subject that looks related), nothing clearly tied with 2.0.5 yet.

Not fully matches, but possibly PR 284428 could be related.
It's for pkgbase, but stating pkg archive date could make pkg confused.
How do you think?

Related to this cgit behaviour: with Charlie_ and yourself this is now confirmed: is 'FreeBSD' aware (or has been made aware) of this?
As noted on comment #132, Chrome on Android phone encountered the same issue. So it would not be "FreeBSD" aware.
 
As noted on comment #132, Chrome on Android phone encountered the same issue. So it would not be "FreeBSD" aware
I intended to refer to something else, but I could have elaborated more/better.

First, I'm assuming this cgit misbehaviour isn't confined to just ports-mgmt/pkg/Makefile but occurs with other files/commits as well (not related to pkg).

With 'FreeBSD' I was thinking about the FreeBSD organisation (not the 'FreeBSD OS' you happen to run). No doubt someone in the FreeBSD organisation is running or managing this (Japanese-region oriented) cgit server or has the means to change its settings. Good to know that other OS-es experience the same problem, that solidifies the idea that this is indeed a cgit (region bound) problem. I do not know exactly where such an issue should be reported most suitably though.



Not fully matches, but possibly PR 284428 could be related.
It's for pkgbase, but stating pkg archive date could make pkg confused.
How do you think?
I lack (detailed enough) knowledge about pkgbase and how it relates to the 'ordinary' pkg(8); I don't have any experience with it and I haven't found any detailed description about it as to its (full) intended functionality (maybe there's some detailed description document that I have missed*). As to the specifc PR 284428: I don't see anything related to FreeBSD 14:amd64; it's all -CURRENT (15) as indicated by the PR's submitter. It doesn't strike me as related.

I agree that one better/best submits a detailed PR to indicate a problem. However, if you can (reproducibly) show that certain behaviour related to pkg 2.0.5 occurs where you (quite reasonably would) expect, or really need, other behaviour, I suggest you file a PR, or at least post it to the pkg mailing list. In case a clear error is indicated, IMO, you should file a PR. You have the knowledge and setup to run further tests and acquire more detailed debug info if so required upon request.

There doesn't seem to be a great influx of recently reported PRs related to pkg 2.0.x. Any new PR described and detailed appropriatedly should be welcome, IMHO.

___
* AFAIK, pkgbase is still considered to be experimental, however applicable/stable it may be for FreeBSD users.
 
You jump first. Let us know if it works. I like to lagg a little after the sparks. When does 2.x hit quarterly? Begining of April?
It should work. At least it does work on my system. And I have now used it for days building everything myself. I have had no problems with version 2.0.5. It upgrades pkg itself first though on a first run. So look for what it wants to do after the pkg upgrade. And abort if it does seems like big problems arise.
 
I lack (detailed enough) knowledge about pkgbase and how it relates to the 'ordinary' pkg(8); I don't have any experience with it and I haven't found any detailed description about it as to its (full) intended functionality (maybe there's some detailed description document that I have missed*).
pkgbase or not, and/or OS version is not so important here.
What seems to be important is that the timestamp of each *.pkg (not pkg(8) here) affects or not.

However, if you can (reproducibly) show that certain behaviour related to pkg 2.0.5 occurs where you (quite reasonably would) expect, or really need, other behaviour, I suggest you file a PR, or at least post it to the pkg mailing list.
What makes it difficult is the reproducibility (simple, light-weighted PoC for reproducibiity should be strongly [almost mandatorily] wanted).
How the problem happens is quite mangled and I still cannot find any simple, easy and reliable PoC for reproducibilities. And this happened on massive updates invoked by upgrading of fundamental ports and following bumps.
 
How the problem happens is quite mangled and I still cannot find any simple, easy and reliable PoC for reproducibilities. And this happened on massive updates invoked by upgrading of fundamental ports and following bumps.
well, pkg threatens to remove Firefox a lot, that is a common complaint. Did that get addressed by the 2.0 upgrade, or is it too early to see such threats?
 
well, pkg threatens to remove Firefox a lot, that is a common complaint. Did that get addressed by the 2.0 upgrade, or is it too early to see such threats?
I think it too early the kind of threats goes away.
It would be (at least partly) different issue, maybe because of "automatic".
If I recall and understand correctly, pkg still don't have the functionality to interactively re-mark leaf ports to be automatic or not.
 
Back
Top