Re: Getting /usr/src to match specific git hash?
On 2021-Jan-24, at 23:37, Mark Millard wrote: > >> How cat one track multiple branches with git without keeping entirely >> separate trees? > > There are multiple possibilities here and it is not > clear which you are hoping for. > > A) You could be trying to avoid having two separate .git > copies around, each also with checked-out material. > > (2 separate deep clones.) > > B) You could be trying to avoid having 1 .git with > two directories trees for checkouts. > > (One deep clone with an added worktree, for example.) > > C) You could be trying to have one .git copy and only > one directory tree with only one checkout at a time. > (In some contexts, this sort of thing might involve > considerable time and I/O for switching the content > of the directory tree to be the checkout of a > different branch. main vs. stable/13 now vs. > 3 years from now might be different.) > > (One deep clone and no additional worktrees.) > > D) Sort of like (A) but using 2 Shallow Clones, one per > branch. (This uses somewhat more space than (C), > but not a lot more.) > > (2 separate shallow clones in separate directories, > one for each branch.) > > My guess from your wording is that you are after (C). > > I presume no local modifications/patches and do not > cover how to handle having such. The command sequences > shown would destroy local changes. It is not clear if > such matches what you are after or not. > > I presume below /usr/src/ use for where the clone was > put. It also presumes the fetch status is recent enough > to contain the commit that you want to use. > > For building main : > > # cd /usr/src > # git switch --discard-changes main > # git fetch freebsd# if advancing > # git merge --ff-only freebsd/main # if advancing > # . . . > > vs. for building stable/13 : > > # cd /usr/src > # git switch --discard-changes stable/13 > # git fetch freebsd # if advancing > # git merge --ff-only freebsd/stable/13 # if advancing > # . . . > > In the above the commit is implicit as the > HEAD for the branch named. > > There is also being more explicit about the > commit that you want (branch implicit): > > # cd /usr/src > # git fetch freebsd # if advancing > # git reset --hard 08b8197a74 # use appropriate hashid > # . . . On review, I forgot that git reset --hard can create untracked files and such. So I add a git clean -f -d to the sequence: # cd /usr/src # git fetch freebsd # if advancing # git reset --hard 08b8197a74 # use appropriate hashid # git clean -f -d # . . . > This "reset --hard" command produces a "detached HEAD" > notice that you can either ignore --or you can then > create a local branch that uses that HEAD: > > # git checkout -b NEW_BRANCH_NAME > > > For reference, from my context: > > # du -sAm /usr/fbsd/main-src/ /usr/fbsd/main-src/.git > 2487 /usr/fbsd/main-src/ > 1379 /usr/fbsd/main-src/.git > > So 2487 would estimate (C) as things > are now for main or stable/13 . > > 2487-1379==1108 for the implicit, primary > worktree that goes with the clone. > > A additional worktree tied to the above: > > # du -sAm /usr/fbsd/mm-src/ > 1108 /usr/fbsd/mm-src/ > > So 2487+1108 == 3595 total using the additional > worktree, i.e., (B). > > Just for reference for how much space (D) takes: > > # git clone -o freebsd --depth 1 -b main https://git.freebsd.org/src.git > /usr/fbsd/main-shallow > Cloning into '/usr/fbsd/main-shallow'... > remote: Enumerating objects: 88695, done. > remote: Counting objects: 100% (88695/88695), done. > remote: Compressing objects: 100% (76042/76042), done. > remote: Total 88695 (delta 18867), reused 51008 (delta 9483), pack-reused 0 > Receiving objects: 100% (88695/88695), 258.57 MiB | 9.14 MiB/s, done. > Resolving deltas: 100% (18867/18867), done. > Updating files: 100% (85161/85161), done. > > # du -sAm /usr/fbsd/main-shallow/ /usr/fbsd/main-shallow/.git > 1378 /usr/fbsd/main-shallow/ > 271 /usr/fbsd/main-shallow/.git > > (The .git is branch specific only.) > > So about 2*1378 == 2756 total to also have a separate one for > stable/13 in, say, /usr/fbsd/stable-13-shallow/ . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting /usr/src to match specific git hash?
> How cat one track multiple branches with git without keeping entirely > separate trees? There are multiple possibilities here and it is not clear which you are hoping for. A) You could be trying to avoid having two separate .git copies around, each also with checked-out material. (2 separate deep clones.) B) You could be trying to avoid having 1 .git with two directories trees for checkouts. (One deep clone with an added worktree, for example.) C) You could be trying to have one .git copy and only one directory tree with only one checkout at a time. (In some contexts, this sort of thing might involve considerable time and I/O for switching the content of the directory tree to be the checkout of a different branch. main vs. stable/13 now vs. 3 years from now might be different.) (One deep clone and no additional worktrees.) D) Sort of like (A) but using 2 Shallow Clones, one per branch. (This uses somewhat more space than (C), but not a lot more.) (2 separate shallow clones in separate directories, one for each branch.) My guess from your wording is that you are after (C). I presume no local modifications/patches and do not cover how to handle having such. The command sequences shown would destroy local changes. It is not clear if such matches what you are after or not. I presume below /usr/src/ use for where the clone was put. It also presumes the fetch status is recent enough to contain the commit that you want to use. For building main : # cd /usr/src # git switch --discard-changes main # git fetch freebsd# if advancing # git merge --ff-only freebsd/main # if advancing # . . . vs. for building stable/13 : # cd /usr/src # git switch --discard-changes stable/13 # git fetch freebsd # if advancing # git merge --ff-only freebsd/stable/13 # if advancing # . . . In the above the commit is implicit as the HEAD for the branch named. There is also being more explicit about the commit that you want (branch implicit): # cd /usr/src # git fetch freebsd # if advancing # git reset --hard 08b8197a74 # use appropriate hashid # . . . This "reset --hard" command produces a "detached HEAD" notice that you can either ignore --or you can then create a local branch that uses that HEAD: # git checkout -b NEW_BRANCH_NAME For reference, from my context: # du -sAm /usr/fbsd/main-src/ /usr/fbsd/main-src/.git 2487/usr/fbsd/main-src/ 1379/usr/fbsd/main-src/.git So 2487 would estimate (C) as things are now for main or stable/13 . 2487-1379==1108 for the implicit, primary worktree that goes with the clone. A additional worktree tied to the above: # du -sAm /usr/fbsd/mm-src/ 1108/usr/fbsd/mm-src/ So 2487+1108 == 3595 total using the additional worktree, i.e., (B). Just for reference for how much space (D) takes: # git clone -o freebsd --depth 1 -b main https://git.freebsd.org/src.git /usr/fbsd/main-shallow Cloning into '/usr/fbsd/main-shallow'... remote: Enumerating objects: 88695, done. remote: Counting objects: 100% (88695/88695), done. remote: Compressing objects: 100% (76042/76042), done. remote: Total 88695 (delta 18867), reused 51008 (delta 9483), pack-reused 0 Receiving objects: 100% (88695/88695), 258.57 MiB | 9.14 MiB/s, done. Resolving deltas: 100% (18867/18867), done. Updating files: 100% (85161/85161), done. # du -sAm /usr/fbsd/main-shallow/ /usr/fbsd/main-shallow/.git 1378/usr/fbsd/main-shallow/ 271 /usr/fbsd/main-shallow/.git (The .git is branch specific only.) So about 2*1378 == 2756 total to also have a separate one for stable/13 in, say, /usr/fbsd/stable-13-shallow/ . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Files in /usr/share/misc
On 2021-01-24 21:35:40 (+0800), mj-mailingl...@gmx.de wrote: - some FreeBSD project related files, like: bsd-family-tree.dot, committers-*.dot, organization.dot These would better be part of the documentation. BTW, on 12.x they are out of date: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251701 I think we've never bothered merging those to older stable branches because there's not really any point. It might be worth doing so just before a release or something but there's very little benefit. - development(?) related files, like: pci_vendors, scsi_modes, usb_hid_usages, usbdevs, windrv_stub.c I don't know if these files are used during build-/runtime E.g. pci_vendors is used by pciconf(8) and windrv_stub.c is used by ndiscvt(8). I'm sure the others are used by similar utilities that escape my memory. - some files which are used during (build-?/)runtime: magic, magic.mgc, termcap, termcap.db Shouldn't these be in a more specific place? They are pretty static, so the "var" part in /var/db does not fit, but services.db is located there, too. The magic* files are used by file(1). See termcap(5) for the others. - is the fonts folder in base, or did some port create it? I'm not sure. Hah. I like the comment in hier(7) about this directory. :-) Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting /usr/src to match specific git hash? (just about out of swap space messages and tuning)
> (4) processes being killed with out-of-swapspace messages > even though I have 4 GB of untouched swap space. Might > be associated with (3). [This is mostly a FYI in case the material is unfamiliar.] Only believe the detailed wording of messages of the form: "was killed: out of swap space" if you also got messages of the form: "swap_pager_getswapspace(...): failed" The other causes that I know of for the "out of swap space" messages are: Sustained low free RAM [via stays-runnable process(es)]. A sufficiently delayed pageout. The swap blk uma zone was exhausted. The swap pctrie uma zone was exhausted. (This is in part because FreeBSD does not swap out runnable processes.) My personal FreeBSD builds have extra code that reports which of the 4 happened but FreeBSD itself does not report such detail. There are tunables for some of the above that make some of those not trip as soon ( /etc/sys.conf content ): # # Delay when persistent low free RAM leads to # Out Of Memory killing of processes. The # delay is a count of kernel-attempts to gain # free RAM (so not time units). vm.pageout_oom_seq=120 (The default is 12 last I knew. 120 allows a 1 GiByte armv7 to -j4 buildworld buildkernel from scratch, relative to what vm.pageout_oom_seq tunes anyway.) # # For plunty of swap/paging space (will not # run out), avoid pageout delays leading to # Out Of Memory killing of processes: vm.pfault_oom_attempts=-1 That last has the alternative structure (replace ???'s with positive integers): # # For possibly insufficient swap/paging space # (might run out), increase the pageout delay # that leads to Out Of Memory killing of # processes: #vm.pfault_oom_attempts= ??? #vm.pfault_oom_wait= ??? # (The multiplication of the two values is the # total but there are other potential tradoffs # in the factors multiplied for the same total.) For reference: # sysctl -d vm.pageout_oom_seq vm.pageout_oom_seq: back-to-back calls to oom detector to start OOM # sysctl -d vm.pfault_oom_wait vm.pfault_oom_wait: Number of seconds to wait for free pages before retrying the page fault handler # sysctl -d vm.pfault_oom_attempts vm.pfault_oom_attempts: Number of page allocation attempts in page fault handler before it triggers OOM handling I hope that helps. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can In-Kernel TLS (kTLS) work with any OpenSSL Application?
On Sat, Jan 23, 2021 at 03:25:59PM +, Rick Macklem wrote: > Ronald Klop wrote: > >On Wed, 20 Jan 2021 21:21:15 +0100, Neel Chauhan wrote: > >But I think for Tor to support KTLS it needs to implement some things > >itself. More information about that could be asked at the maintainer of > >the port (https://www.freshports.org/security/tor/) or upstream at the Tor > >project. > To just make it work, I don't think changes are needed beyond linking to > the correct OpenSSL libraries (assuming it uses OpenSSL, of course). > (There are new library calls an application can use to check to see if > KTLS is enabled for the connection, but if it doesn't care, I don't think > those calls are needed?) > > You do need to run a kernel with "options KERN_TLS" and set > kern.ipc.tls.enable=1 > kern.ipc.mb_use_ext_pgs=1 Note that upstream openssl is expecting to change in what ways ktls is (en/dis)abled by default; see https://github.com/openssl/openssl/issues/13794 -Ben ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkg for 14-current
From: Mark Linimon Subject: Re: pkg for 14-current Date: Mon, 25 Jan 2021 03:41:26 + > On Sun, Jan 24, 2021 at 07:45:08PM +0900, Yasuhiro Kimura wrote: >> By the way, when -CURRENT was bumped from 12 to 13, there were some >> ports that failed to be built on 13-CURRENT simply because they don't >> expect there is version 13.x of FreeBSD. And probably such ports fails >> to be built on 14-CURRENT with same reason. So it may takes for a >> while until offical packages for 14-CURRENT are provided with same >> level as 13-CURRENT. > > Do you remember which they were, please? What I can remember are mail/postfix and sysutils/lsof. I've been using them and when -CURRENT was bumped from 12 to 13 they were broken with -CURRENT for a while. And at that time I also saw some other ports were updated with the commit message such as "Fix build with 13-CURRENT" on FreshPorts but I don't remember what they were. --- Yasuhiro Kimura ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting /usr/src to match specific git hash?
On 2021-01-25 10:57:19 (+0800), Thomas Mueller wrote: It is in the mini primer I wrote, along with how to bisect and other useful things. This will migrate into the handbook once the doc tree converts to asciidoc (happening this weekend). https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md I looked at your mini-primer webpage, but can't find the answer to my question? How cat one track multiple branches with git without keeping entirely separate trees? Does something like this do what you want: git worktree add ../13-stable remotes/freebsd/stable/13 I see there is a git worktree command, which can keep two or more branches in much diskspace than keeping the trees entirely separately (as I did with subversion and cvs). In my case, I would want to be able to choose between main and stable-13 when compiling; have given up on releng-12 because of problems with ethernet and wireless drivers. Worktrees should be able to do what you want in this case. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkg for 14-current
On Sun, Jan 24, 2021 at 07:45:08PM +0900, Yasuhiro Kimura wrote: > By the way, when -CURRENT was bumped from 12 to 13, there were some > ports that failed to be built on 13-CURRENT simply because they don't > expect there is version 13.x of FreeBSD. And probably such ports fails > to be built on 14-CURRENT with same reason. So it may takes for a > while until offical packages for 14-CURRENT are provided with same > level as 13-CURRENT. Do you remember which they were, please? mcl ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting /usr/src to match specific git hash?
> It is in the mini primer I wrote, along with how to bisect and other useful > things. This will migrate into the handbook once the doc tree converts to > asciidoc (happening this weekend). > https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md > Warner I looked at your mini-primer webpage, but can't find the answer to my question? How cat one track multiple branches with git without keeping entirely separate trees? I see there is a git worktree command, which can keep two or more branches in much diskspace than keeping the trees entirely separately (as I did with subversion and cvs). In my case, I would want to be able to choose between main and stable-13 when compiling; have given up on releng-12 because of problems with ethernet and wireless drivers. Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting /usr/src to match specific git hash?
On Sun, Jan 24, 2021 at 3:40 PM Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > On Sun, Jan 24, 2021 at 03:22:18PM -0700, Warner Losh wrote: > > On Sun, Jan 24, 2021, 12:14 PM Steve Kargl < > s...@troutmask.apl.washington.edu> > > wrote: > > > >> > >> Any advice on how to jump, say, 4 days ahead of the current > >> date of the src/ tree? That is, I have src/ that should > >> correspond to 24 Dec 2020. How do I jump to 28 Dec 2020? > >> > > > > You could use git bisect, but as you say, the laundry list is extensive. > > > > Git doesn't offer checkout by date, alas. So here's some tools to help > you > > out. > > > > First, let's get a count of how many commits behind main you are at the > > moment. Use 'git log --oneline --first-parent HEAD..main | wc' to get a > > count of the number of commits between what you have checked out and the > > tip of current. My count is 994, but I just updated, so your count will > > differ and that's OK.The --first-parent in the git log above is critical, > > since otherwise a number of commits from vendor merges in the vendor > > branches will appear in git log's output, throwing the count off). > > > > Now, this is 1 month worth of -current. 4 days in the month is about 13%. > > However, let's keep things simple and step forward 100 commits at a time > > (which is 10% of 1000). The precise numbers don't matter, but it works > out > > well in this case. > > > > So, your commit is: > > % git log -1 3cc0c0d66a0 > > Author: Li-Wen Hsu > > Date: Sun Dec 20 02:59:44 2020 + > > > > Mark the repository as being converted to Git. > > > > which is the last subversion commit. It's also head~994, you can do a > 'git > > log -1 main~900' to verify that. So, let's move forward 94 commits. This > > would be: > > > > % git log main~900 > > commit 8d405efd73d3991fe1647f91a2b7c9989dd5f18f > > Author: Ulrich Sprlein > > Date: Wed Dec 23 22:29:34 2020 +0100 > > > > Fix newvers.sh to no longer print an outdated SVN rev > > > > which is 3 days newer and may be a good place to start: > > > > % git checkout main~900 > > > > and that will move you forward 94 commits. Do it again with main~800, etc > > to find a spot that's good for you. Not as convenient as giving dates, > but > > once you have a count of the number of commits between where you are and > > head, you can use that number to decide how far forward to go. > > > > You can adjust this as needed. If you don't do a git pull during this > > process (and you likely shouldn't) these numbers will be stable, and a > lot > > easier to work with than hashes. I've found I like to move N commits > rather > > than N days. > > > > Hope this is helpful. Sadly I found no way to say HEAD+50 commits > directly > > in git, but maybe one of the more knowledgeable folks on this list can > give > > a better hint there. > > > > Warner > > Thanks for the thorough reply! After David's response > I started to think (yes, I should do that more often) > about the mailing list archive dev-commits-src-main. > Each subject line starts with, for example, > "git: 68dc94c7d314 - main -". I assume that the hash > value is sufficient to grab a src/ up to and including > the commit. Will the following > > % cd /usr/src# This is at 3cc0c0d66a0 > % git checkout 68dc94c7d314 # Update to last commit in 2020. > > bring the src/ update to 68dc94c7d314 or do > I need to use 'git pull 68dc94c7d314'? > Sure. If you can find hashes, then git checkout does the job. git pull brings in any changes you don't already have, so unless you've not updated at all this year, you don't need any kind of pull. And if you did want to update, might I suggest 'git fetch' which is the first half of 'git pull' which is 'git fetch' followed by 'git merge'. If you just do the fetch, you'll not mess up the current branch by mistake... So for your mental map. The remote has a series of changes (a branch). There is also a local pointer to somewhere in that branch. git fetch will pull down the remote changes, but leave the local pointer unaffected. git merge will update the local repo's pointer to a newer rev. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting /usr/src to match specific git hash?
after looking in the git log for the hash I use: git -C /usr/src reset --hard you will lose any local changes On 1/24/21 5:40 PM, Steve Kargl wrote: On Sun, Jan 24, 2021 at 03:22:18PM -0700, Warner Losh wrote: On Sun, Jan 24, 2021, 12:14 PM Steve Kargl wrote: Any advice on how to jump, say, 4 days ahead of the current date of the src/ tree? That is, I have src/ that should correspond to 24 Dec 2020. How do I jump to 28 Dec 2020? You could use git bisect, but as you say, the laundry list is extensive. Git doesn't offer checkout by date, alas. So here's some tools to help you out. First, let's get a count of how many commits behind main you are at the moment. Use 'git log --oneline --first-parent HEAD..main | wc' to get a count of the number of commits between what you have checked out and the tip of current. My count is 994, but I just updated, so your count will differ and that's OK.The --first-parent in the git log above is critical, since otherwise a number of commits from vendor merges in the vendor branches will appear in git log's output, throwing the count off). Now, this is 1 month worth of -current. 4 days in the month is about 13%. However, let's keep things simple and step forward 100 commits at a time (which is 10% of 1000). The precise numbers don't matter, but it works out well in this case. So, your commit is: % git log -1 3cc0c0d66a0 Author: Li-Wen Hsu Date: Sun Dec 20 02:59:44 2020 + Mark the repository as being converted to Git. which is the last subversion commit. It's also head~994, you can do a 'git log -1 main~900' to verify that. So, let's move forward 94 commits. This would be: % git log main~900 commit 8d405efd73d3991fe1647f91a2b7c9989dd5f18f Author: Ulrich Sprlein Date: Wed Dec 23 22:29:34 2020 +0100 Fix newvers.sh to no longer print an outdated SVN rev which is 3 days newer and may be a good place to start: % git checkout main~900 and that will move you forward 94 commits. Do it again with main~800, etc to find a spot that's good for you. Not as convenient as giving dates, but once you have a count of the number of commits between where you are and head, you can use that number to decide how far forward to go. You can adjust this as needed. If you don't do a git pull during this process (and you likely shouldn't) these numbers will be stable, and a lot easier to work with than hashes. I've found I like to move N commits rather than N days. Hope this is helpful. Sadly I found no way to say HEAD+50 commits directly in git, but maybe one of the more knowledgeable folks on this list can give a better hint there. Warner Thanks for the thorough reply! After David's response I started to think (yes, I should do that more often) about the mailing list archive dev-commits-src-main. Each subject line starts with, for example, "git: 68dc94c7d314 - main -". I assume that the hash value is sufficient to grab a src/ up to and including the commit. Will the following % cd /usr/src# This is at 3cc0c0d66a0 % git checkout 68dc94c7d314 # Update to last commit in 2020. bring the src/ update to 68dc94c7d314 or do I need to use 'git pull 68dc94c7d314'? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
loading drm crashes system
Hello: On a system now running: 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-d6327ae8c1: Sun Jan 24 14:16:54 EST 2021 amd64 (src+ports updated at midnight US EST) with PORTS_MODULES="drm-current-kmod gpu-firmware-kmod", starting the system _without_ loading drm results in a usable system. Loading drm - whether via kldlist in rc.conf or by kldload at the console immediately after start-up - instantly crashes the system; the screen goes blank and the lights on the monitor report no signal from the system. There is nothing in dmesg.boot. In messages I find (75 lines follow): Jan 24 17:35:22 jerusalem kernel: [drm:drm_core_init] Initialized Jan 24 17:35:22 jerusalem kernel: [drm] radeon kernel modesetting enabled. Jan 24 17:35:22 jerusalem kernel: drmn0: on vgapci0 Jan 24 17:35:22 jerusalem kernel: vgapci0: child drmn0 requested pci_enable_io Jan 24 17:35:22 jerusalem kernel: [drm:drm_minor_register] Jan 24 17:35:22 jerusalem kernel: [drm:drm_minor_register] new minor registered 128 Jan 24 17:35:22 jerusalem kernel: [drm:drm_minor_register] Jan 24 17:35:22 jerusalem kernel: [drm:drm_minor_register] new minor registered 0 Jan 24 17:35:22 jerusalem kernel: [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1849:0x9614 0x00). Jan 24 17:35:22 jerusalem kernel: [drm:radeon_get_bios] ATOMBIOS detected Jan 24 17:35:22 jerusalem kernel: [drm ERROR :radeon_atombios_init] Unable to find PCI I/O BAR; using MMIO for ATOM IIO Jan 24 17:35:22 jerusalem kernel: [drm:atom_allocate_fb_scratch] atom firmware requested 17ffb000 20kb Jan 24 17:35:22 jerusalem kernel: drmn0: VRAM: 384M 0xC000 - 0xD7FF (384M used) Jan 24 17:35:22 jerusalem kernel: drmn0: GTT: 512M 0xA000 - 0xBFFF Jan 24 17:35:22 jerusalem kernel: [drm] Detected VRAM RAM=384M, BAR=256M Jan 24 17:35:22 jerusalem kernel: [drm] RAM width 32bits DDR Jan 24 17:35:22 jerusalem kernel: [drm] radeon: 384M of VRAM memory ready Jan 24 17:35:22 jerusalem kernel: [drm] radeon: 512M of GTT memory ready. Jan 24 17:35:22 jerusalem kernel: [drm:r600_init_microcode] Jan 24 17:35:22 jerusalem kernel: [drm] Loading RS780 Microcode Jan 24 17:35:23 jerusalem kernel: drmn0: fail (0) to get firmware image with name: radeon/RS780_pfp.bin Jan 24 17:35:23 jerusalem kernel: drmn0: successfully loaded firmware image with mapped name: radeon_RS780_pfp_bin Jan 24 17:35:23 jerusalem kernel: drmn0: fail (0) to get firmware image with name: radeon/RS780_me.bin Jan 24 17:35:23 jerusalem kernel: drmn0: successfully loaded firmware image with mapped name: radeon_RS780_me_bin Jan 24 17:35:24 jerusalem kernel: drmn0: fail (0) to get firmware image with name: radeon/R600_rlc.bin Jan 24 17:35:24 jerusalem kernel: drmn0: successfully loaded firmware image with mapped name: radeon_R600_rlc_bin Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] 3 Power State(s) Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] State 0: Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] Default[drm:radeon_pm_print_states] 1 Clock Mode(s) Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] 0 e: 80 Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] State 1: Performance Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] 1 Clock Mode(s) Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] 0 e: 50 Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] State 2: Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] 1 Clock Mode(s) Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] 0 e: 50 Jan 24 17:35:24 jerusalem kernel: [drm] radeon: power management initialized Jan 24 17:35:24 jerusalem kernel: drmn0: fail (0) to get firmware image with name: radeon/RS780_uvd.bin Jan 24 17:35:24 jerusalem kernel: drmn0: successfully loaded firmware image with mapped name: radeon_RS780_uvd_bin Jan 24 17:35:24 jerusalem kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072 Jan 24 17:35:34 jerusalem kernel: [drm] PCIE GART of 512M enabled (table at 0xC0146000). Jan 24 17:35:34 jerusalem kernel: drmn0: WB enabled Jan 24 17:35:34 jerusalem kernel: drmn0: fence driver on ring 0 use gpu addr 0xac00 and cpu addr 0x0xf801cb29cc00 Jan 24 17:35:34 jerusalem kernel: drmn0: fence driver on ring 5 use gpu addr 0xc0056038 and cpu addr 0x0xf800d0056038 Jan 24 17:35:34 jerusalem kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Jan 24 17:35:34 jerusalem kernel: [drm] Driver supports precise vblank timestamp query. Jan 24 17:35:34 jerusalem kernel: drmn0: radeon: MSI limited to 32-bit Jan 24 17:35:34 jerusalem kernel: [drm:drm_irq_install] irq=18 Jan 24 17:35:34 jerusalem kernel: [drm] radeon: irq initialized. Jan 24 17:35:34 jerusalem kernel: [drm:r600_irq_process] r600_irq_process start: rptr 0, wptr 32 Jan
Re: Getting /usr/src to match specific git hash?
On Sun, Jan 24, 2021 at 03:22:18PM -0700, Warner Losh wrote: > On Sun, Jan 24, 2021, 12:14 PM Steve Kargl > wrote: > >> >> Any advice on how to jump, say, 4 days ahead of the current >> date of the src/ tree? That is, I have src/ that should >> correspond to 24 Dec 2020. How do I jump to 28 Dec 2020? >> > > You could use git bisect, but as you say, the laundry list is extensive. > > Git doesn't offer checkout by date, alas. So here's some tools to help you > out. > > First, let's get a count of how many commits behind main you are at the > moment. Use 'git log --oneline --first-parent HEAD..main | wc' to get a > count of the number of commits between what you have checked out and the > tip of current. My count is 994, but I just updated, so your count will > differ and that's OK.The --first-parent in the git log above is critical, > since otherwise a number of commits from vendor merges in the vendor > branches will appear in git log's output, throwing the count off). > > Now, this is 1 month worth of -current. 4 days in the month is about 13%. > However, let's keep things simple and step forward 100 commits at a time > (which is 10% of 1000). The precise numbers don't matter, but it works out > well in this case. > > So, your commit is: > % git log -1 3cc0c0d66a0 > Author: Li-Wen Hsu > Date: Sun Dec 20 02:59:44 2020 + > > Mark the repository as being converted to Git. > > which is the last subversion commit. It's also head~994, you can do a 'git > log -1 main~900' to verify that. So, let's move forward 94 commits. This > would be: > > % git log main~900 > commit 8d405efd73d3991fe1647f91a2b7c9989dd5f18f > Author: Ulrich Sprlein > Date: Wed Dec 23 22:29:34 2020 +0100 > > Fix newvers.sh to no longer print an outdated SVN rev > > which is 3 days newer and may be a good place to start: > > % git checkout main~900 > > and that will move you forward 94 commits. Do it again with main~800, etc > to find a spot that's good for you. Not as convenient as giving dates, but > once you have a count of the number of commits between where you are and > head, you can use that number to decide how far forward to go. > > You can adjust this as needed. If you don't do a git pull during this > process (and you likely shouldn't) these numbers will be stable, and a lot > easier to work with than hashes. I've found I like to move N commits rather > than N days. > > Hope this is helpful. Sadly I found no way to say HEAD+50 commits directly > in git, but maybe one of the more knowledgeable folks on this list can give > a better hint there. > > Warner Thanks for the thorough reply! After David's response I started to think (yes, I should do that more often) about the mailing list archive dev-commits-src-main. Each subject line starts with, for example, "git: 68dc94c7d314 - main -". I assume that the hash value is sufficient to grab a src/ up to and including the commit. Will the following % cd /usr/src# This is at 3cc0c0d66a0 % git checkout 68dc94c7d314 # Update to last commit in 2020. bring the src/ update to 68dc94c7d314 or do I need to use 'git pull 68dc94c7d314'? -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting /usr/src to match specific git hash?
On Sun, Jan 24, 2021 at 3:22 PM Warner Losh wrote: > > > On Sun, Jan 24, 2021, 12:14 PM Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > >> On Sun, Jan 24, 2021 at 09:00:45AM -0700, Warner Losh wrote: >> > On Sun, Jan 24, 2021, 6:05 AM Jeffrey Bouquet < >> jbt...@iherebuywisely.com> >> > wrote: >> > >> > > >> > > >> > > On Sat, 23 Jan 2021 20:14:03 -0800, Steve Kargl < >> > > s...@troutmask.apl.washington.edu> wrote: >> > > >> > > > On Sun, Jan 24, 2021 at 01:08:05PM +0900, Yasuhiro Kimura wrote: >> > > > > From: Steve Kargl >> > > > > Subject: Getting /usr/src to match specific git hash? >> > > > > Date: Sat, 23 Jan 2021 19:58:52 -0800 >> > > > > >> > > > > > Suppose one has an empty /usr/src. >> > > > > > >> > > > > > Suppose further that one had to re-install a 32-bit >> > > > > > i386-*-freebsd with the 24 Dec 2020 image available >> > > > > > from freebsd.org. >> > > > > > >> > > > > > uname -a for the booted kernel shows >> > > > > > >> > > > > > % uname -a >> > > > > > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 \ >> > > > > > 3cc0c0d66a0-c255241(main)-dirty: Thu Dec 24 05:43:23 UTC 2020 \ >> > > > > > r...@releng1.nyi.freebsd.org: >> /usr/obj/usr/src/i386.i386/sys/GENERIC >> > > i386 >> > > > > > >> > > > > > How does one use git to pull the exact sources that match >> > > > > > this specifc kernel? >> > > > > >> > > > > cd /usr >> > > > > git clone https://git.freebsd.org/src.git >> > > > > cd src >> > > > > git checkout 3cc0c0d66a0 >> > > > > >> > > > >> > > > Thank you. >> > > > >> > > >> > > Can this be put in /usr/src/UPDATING with an explanation of precisely >> how >> > > each >> > > of the git commands populates or repopulated the directories in >> /usr??? >> > > >> > >> > It is in the mini primer I wrote, along with how to bisect and other >> useful >> > things. This will migrate into the handbook once the doc tree converts >> to >> > asciidoc (happening this weekend). >> > >> > https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md >> > >> >> Any advice on how to jump, say, 4 days ahead of the current >> date of the src/ tree? That is, I have src/ that should >> correspond to 24 Dec 2020. How do I jump to 28 Dec 2020? >> > > You could use git bisect, but as you say, the laundry list is extensive. > > Git doesn't offer checkout by date, alas. So here's some tools to help you > out. > > First, let's get a count of how many commits behind main you are at the > moment. Use 'git log --oneline --first-parent HEAD..main | wc' to get a > count of the number of commits between what you have checked out and the > tip of current. My count is 994, but I just updated, so your count will > differ and that's OK.The --first-parent in the git log above is critical, > since otherwise a number of commits from vendor merges in the vendor > branches will appear in git log's output, throwing the count off). > > Now, this is 1 month worth of -current. 4 days in the month is about 13%. > However, let's keep things simple and step forward 100 commits at a time > (which is 10% of 1000). The precise numbers don't matter, but it works out > well in this case. > > So, your commit is: > % git log -1 3cc0c0d66a0 > Author: Li-Wen Hsu > Date: Sun Dec 20 02:59:44 2020 + > > Mark the repository as being converted to Git. > > which is the last subversion commit. It's also head~994, you can do a 'git > log -1 main~900' to verify that. So, let's move forward 94 commits. This > would be: > The 'main~900' should be 'main~994' here since you are verifying main~944. Also 'head~994' was a typo for 'main~994'. Sorry for any confusion these mistakes caused. > % git log main~900 > commit 8d405efd73d3991fe1647f91a2b7c9989dd5f18f > Author: Ulrich Sprlein > Date: Wed Dec 23 22:29:34 2020 +0100 > > Fix newvers.sh to no longer print an outdated SVN rev > > which is 3 days newer and may be a good place to start: > > % git checkout main~900 > > and that will move you forward 94 commits. Do it again with main~800, etc > to find a spot that's good for you. Not as convenient as giving dates, but > once you have a count of the number of commits between where you are and > head, you can use that number to decide how far forward to go. > > You can adjust this as needed. If you don't do a git pull during this > process (and you likely shouldn't) these numbers will be stable, and a lot > easier to work with than hashes. I've found I like to move N commits rather > than N days. > > Hope this is helpful. Sadly I found no way to say HEAD+50 commits directly > in git, but maybe one of the more knowledgeable folks on this list can give > a better hint there. > > Warner > > > My past week experience with top-of-tree suggests doing >> a bisection would be frought with peril. My laptop runs >> well with 24 Dec 2020 kernel/world. Getting to top-of-tree, >> one has to deal with >> (1) infinite recursion in wpa_supplicant, >> (2) possible locking issue in UFS (30 second system freezes), >> (3) memory
Re: Getting /usr/src to match specific git hash?
On Sun, Jan 24, 2021, 12:14 PM Steve Kargl wrote: > On Sun, Jan 24, 2021 at 09:00:45AM -0700, Warner Losh wrote: > > On Sun, Jan 24, 2021, 6:05 AM Jeffrey Bouquet > > > wrote: > > > > > > > > > > > On Sat, 23 Jan 2021 20:14:03 -0800, Steve Kargl < > > > s...@troutmask.apl.washington.edu> wrote: > > > > > > > On Sun, Jan 24, 2021 at 01:08:05PM +0900, Yasuhiro Kimura wrote: > > > > > From: Steve Kargl > > > > > Subject: Getting /usr/src to match specific git hash? > > > > > Date: Sat, 23 Jan 2021 19:58:52 -0800 > > > > > > > > > > > Suppose one has an empty /usr/src. > > > > > > > > > > > > Suppose further that one had to re-install a 32-bit > > > > > > i386-*-freebsd with the 24 Dec 2020 image available > > > > > > from freebsd.org. > > > > > > > > > > > > uname -a for the booted kernel shows > > > > > > > > > > > > % uname -a > > > > > > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 \ > > > > > > 3cc0c0d66a0-c255241(main)-dirty: Thu Dec 24 05:43:23 UTC 2020 \ > > > > > > r...@releng1.nyi.freebsd.org: > /usr/obj/usr/src/i386.i386/sys/GENERIC > > > i386 > > > > > > > > > > > > How does one use git to pull the exact sources that match > > > > > > this specifc kernel? > > > > > > > > > > cd /usr > > > > > git clone https://git.freebsd.org/src.git > > > > > cd src > > > > > git checkout 3cc0c0d66a0 > > > > > > > > > > > > > Thank you. > > > > > > > > > > Can this be put in /usr/src/UPDATING with an explanation of precisely > how > > > each > > > of the git commands populates or repopulated the directories in /usr??? > > > > > > > It is in the mini primer I wrote, along with how to bisect and other > useful > > things. This will migrate into the handbook once the doc tree converts to > > asciidoc (happening this weekend). > > > > https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md > > > > Any advice on how to jump, say, 4 days ahead of the current > date of the src/ tree? That is, I have src/ that should > correspond to 24 Dec 2020. How do I jump to 28 Dec 2020? > You could use git bisect, but as you say, the laundry list is extensive. Git doesn't offer checkout by date, alas. So here's some tools to help you out. First, let's get a count of how many commits behind main you are at the moment. Use 'git log --oneline --first-parent HEAD..main | wc' to get a count of the number of commits between what you have checked out and the tip of current. My count is 994, but I just updated, so your count will differ and that's OK.The --first-parent in the git log above is critical, since otherwise a number of commits from vendor merges in the vendor branches will appear in git log's output, throwing the count off). Now, this is 1 month worth of -current. 4 days in the month is about 13%. However, let's keep things simple and step forward 100 commits at a time (which is 10% of 1000). The precise numbers don't matter, but it works out well in this case. So, your commit is: % git log -1 3cc0c0d66a0 Author: Li-Wen Hsu Date: Sun Dec 20 02:59:44 2020 + Mark the repository as being converted to Git. which is the last subversion commit. It's also head~994, you can do a 'git log -1 main~900' to verify that. So, let's move forward 94 commits. This would be: % git log main~900 commit 8d405efd73d3991fe1647f91a2b7c9989dd5f18f Author: Ulrich Sprlein Date: Wed Dec 23 22:29:34 2020 +0100 Fix newvers.sh to no longer print an outdated SVN rev which is 3 days newer and may be a good place to start: % git checkout main~900 and that will move you forward 94 commits. Do it again with main~800, etc to find a spot that's good for you. Not as convenient as giving dates, but once you have a count of the number of commits between where you are and head, you can use that number to decide how far forward to go. You can adjust this as needed. If you don't do a git pull during this process (and you likely shouldn't) these numbers will be stable, and a lot easier to work with than hashes. I've found I like to move N commits rather than N days. Hope this is helpful. Sadly I found no way to say HEAD+50 commits directly in git, but maybe one of the more knowledgeable folks on this list can give a better hint there. Warner My past week experience with top-of-tree suggests doing > a bisection would be frought with peril. My laptop runs > well with 24 Dec 2020 kernel/world. Getting to top-of-tree, > one has to deal with > (1) infinite recursion in wpa_supplicant, > (2) possible locking issue in UFS (30 second system freezes), > (3) memory alignment messages from the kernel, > (4) processes being killed with out-of-swapspace messages > even though I have 4 GB of untouched swap space. Might > be associated with (3). > (5) graphic console mess > (6) pilot-error of using -march=core2, which matches the > processor in the laptop, to build kernel/world but > manifests a llvm bug > > I would like to creep up on the issues. > > -- > Steve > ___
Re: Getting /usr/src to match specific git hash?
Steve Kargl wrote: > Suppose further that one had to re-install a 32-bit > i386-*-freebsd with the 24 Dec 2020 image available > from freebsd.org. > > uname -a for the booted kernel shows > > % uname -a > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 \ > 3cc0c0d66a0-c255241(main)-dirty: Thu Dec 24 05:43:23 UTC 2020 \ > r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/i386.i386/sys/GENERIC i386 > > How does one use git to pull the exact sources that match > this specifc kernel? As others have described, you can clone and 'git checkout 3cc0c0d66a0' but that "-dirty" above implies the tree had changes, so you cannot reproduce "the exact sources". --sjg ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting /usr/src to match specific git hash?
On Sun, Jan 24, 2021 at 11:14:45AM -0800, Steve Kargl wrote: > ... > Any advice on how to jump, say, 4 days ahead of the current > date of the src/ tree? That is, I have src/ that should > correspond to 24 Dec 2020. How do I jump to 28 Dec 2020? I (happen to) track FreeBSD head, stable/12 (and now, stable/13) daily on a couple of machines. In the course of that effort, the machines are set up to append the output of uname -vpUK to a file that gets copied to where my Web server can see it. (Other files are also copied, in case they might prove useful.) These are accessible from https://www.catwhisker.org/~david/FreeBSD/history/ I believe that the file that would address your immediate concern is https://www.catwhisker.org/~david/FreeBSD/history/freebeast_uname_amd64.13.txt (There is no update for stable/13 today, as there were no chnages to stable/13 sources since stable/13-c256208-gf76393a6305b at the time I updated my local private git mirrors his morning.) > Peace, david -- David H. Wolfskill da...@catwhisker.org Note that political parties are not mentioned in the US Constitution at all. See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Getting /usr/src to match specific git hash?
From: "Simon J. Gerraty" Subject: Re: Getting /usr/src to match specific git hash? Date: Sun, 24 Jan 2021 10:05:38 -0800 > As others have described, you can clone and 'git checkout 3cc0c0d66a0' > but that "-dirty" above implies the tree had changes, so you cannot > reproduce "the exact sources". There was bug in sys/conf/newvers.sh that reports the result of dirtyness check in reverse. It was introduced at commit 029ca1842fa on 2002/12/17 and fixed at commit 17eba5e32a2 on 2020/12/23. And commit 3cc0c0d66a0 is between them. So in this case "3cc0c0d66a0-c255241(main)-dirty" means there isn't any change in src tree. Just FYI. --- Yasuhiro Kimura ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting /usr/src to match specific git hash?
On Sun, Jan 24, 2021 at 09:00:45AM -0700, Warner Losh wrote: > On Sun, Jan 24, 2021, 6:05 AM Jeffrey Bouquet > wrote: > > > > > > > On Sat, 23 Jan 2021 20:14:03 -0800, Steve Kargl < > > s...@troutmask.apl.washington.edu> wrote: > > > > > On Sun, Jan 24, 2021 at 01:08:05PM +0900, Yasuhiro Kimura wrote: > > > > From: Steve Kargl > > > > Subject: Getting /usr/src to match specific git hash? > > > > Date: Sat, 23 Jan 2021 19:58:52 -0800 > > > > > > > > > Suppose one has an empty /usr/src. > > > > > > > > > > Suppose further that one had to re-install a 32-bit > > > > > i386-*-freebsd with the 24 Dec 2020 image available > > > > > from freebsd.org. > > > > > > > > > > uname -a for the booted kernel shows > > > > > > > > > > % uname -a > > > > > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 \ > > > > > 3cc0c0d66a0-c255241(main)-dirty: Thu Dec 24 05:43:23 UTC 2020 \ > > > > > r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/i386.i386/sys/GENERIC > > i386 > > > > > > > > > > How does one use git to pull the exact sources that match > > > > > this specifc kernel? > > > > > > > > cd /usr > > > > git clone https://git.freebsd.org/src.git > > > > cd src > > > > git checkout 3cc0c0d66a0 > > > > > > > > > > Thank you. > > > > > > > Can this be put in /usr/src/UPDATING with an explanation of precisely how > > each > > of the git commands populates or repopulated the directories in /usr??? > > > > It is in the mini primer I wrote, along with how to bisect and other useful > things. This will migrate into the handbook once the doc tree converts to > asciidoc (happening this weekend). > > https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md > Any advice on how to jump, say, 4 days ahead of the current date of the src/ tree? That is, I have src/ that should correspond to 24 Dec 2020. How do I jump to 28 Dec 2020? My past week experience with top-of-tree suggests doing a bisection would be frought with peril. My laptop runs well with 24 Dec 2020 kernel/world. Getting to top-of-tree, one has to deal with (1) infinite recursion in wpa_supplicant, (2) possible locking issue in UFS (30 second system freezes), (3) memory alignment messages from the kernel, (4) processes being killed with out-of-swapspace messages even though I have 4 GB of untouched swap space. Might be associated with (3). (5) graphic console mess (6) pilot-error of using -march=core2, which matches the processor in the laptop, to build kernel/world but manifests a llvm bug I would like to creep up on the issues. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 13-alpha2 libncurses removal breaks ports build
OK, building ports against a clean installation of 13.0-ALPHA2 has no problem with ncurses. But devel/glib20 fails for no obvious reason closer to the end of building process... I just wonder: do I need to report this to port maintainers or wait till it settles up somehow? A good deal of ports depend on it. With kindest regards, Kostya Berger On Sunday, 24 January 2021, 01:40:57 GMT+3, Kostya Berger wrote: Hi everyone,I don't seem to find any mentioning in the /usr/ports/UPDATING about how one should handle the removal of libncurses.so.9 from base. Source UPDATING only says:ncurses installation has been modified to only keep the widechar enabled version. Incremental build is broken for that change, so it requires a clean build. If that means to just build all ports anew, then it doesn't work as ports don't seem to incorporate any change related to this one. It would seem default configuration should take into account this, but it doesn't. The ports just use --with-libncurses-prefix=/usr, and there is no ncurses libs found there. This make it skip MOST of the ports I'm using. Working Copy Root Path: /usr/ports URL: https://svn.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 562417 Node Kind: directory Schedule: normal Last Changed Author: 0mp Last Changed Rev: 562417 Last Changed Date: 2021-01-23 23:01:38 +0300 (Sat, 23 Jan 2021) With kindest regards, Kostya Berger ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting /usr/src to match specific git hash?
On Sun, Jan 24, 2021, 9:05 AM Shawn Webb wrote: > On Sun, Jan 24, 2021 at 09:00:45AM -0700, Warner Losh wrote: > > On Sun, Jan 24, 2021, 6:05 AM Jeffrey Bouquet > > > wrote: > > > > > > > > > > > On Sat, 23 Jan 2021 20:14:03 -0800, Steve Kargl < > > > s...@troutmask.apl.washington.edu> wrote: > > > > > > > On Sun, Jan 24, 2021 at 01:08:05PM +0900, Yasuhiro Kimura wrote: > > > > > From: Steve Kargl > > > > > Subject: Getting /usr/src to match specific git hash? > > > > > Date: Sat, 23 Jan 2021 19:58:52 -0800 > > > > > > > > > > > Suppose one has an empty /usr/src. > > > > > > > > > > > > Suppose further that one had to re-install a 32-bit > > > > > > i386-*-freebsd with the 24 Dec 2020 image available > > > > > > from freebsd.org. > > > > > > > > > > > > uname -a for the booted kernel shows > > > > > > > > > > > > % uname -a > > > > > > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 \ > > > > > > 3cc0c0d66a0-c255241(main)-dirty: Thu Dec 24 05:43:23 UTC 2020 \ > > > > > > r...@releng1.nyi.freebsd.org: > /usr/obj/usr/src/i386.i386/sys/GENERIC > > > i386 > > > > > > > > > > > > How does one use git to pull the exact sources that match > > > > > > this specifc kernel? > > > > > > > > > > cd /usr > > > > > git clone https://git.freebsd.org/src.git > > > > > cd src > > > > > git checkout 3cc0c0d66a0 > > > > > > > > > > > > > Thank you. > > > > > > > > -- > > > > Steve > > > > ___ > > > > freebsd-current@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to " > > > freebsd-current-unsubscr...@freebsd.org" > > > > > > Can this be put in /usr/src/UPDATING with an explanation of precisely > how > > > each > > > of the git commands populates or repopulated the directories in /usr??? > > > > > > > It is in the mini primer I wrote, along with how to bisect and other > useful > > things. This will migrate into the handbook once the doc tree converts to > > asciidoc (happening this weekend). > > > > https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md > > I'm glad this is moving to FreeBSD's documentation. Following the > process of FreeBSD's migration to git has been a bit troublesome with > some docs somewhere other docs elsewhere. > Pointers have been posted early and often though. I don't buy it was that big a deal.. Warner Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > GPG Key ID: 0xFF2E67A277F8E1FA > GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 > > https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 13-alpha2 libncurses removal breaks ports build
On Sun, Jan 24, 2021 at 02:53:41PM +, Kostya Berger wrote: > OK, building ports against a clean installation of 13.0-ALPHA2 has no problem > with ncurses. > But devel/glib20 fails for no obvious reason closer to the end of building > process... I just wonder: do I need to report this to port maintainers or > wait till it settles up somehow? A good deal of ports depend on it. Hmm. My compile was fine. From the top of my poudriere build log: =>> Building devel/glib20 build started at Thu Jan 21 20:15:35 PST 2021 port directory: /usr/ports/devel/glib20 package name: glib-2.66.4_1,1 building for: FreeBSD 13-master-job-02 13.0-ALPHA2 FreeBSD 13.0-ALPHA2 1300136 amd64 maintained by: desk...@freebsd.org Makefile ident: Poudriere version: 3.3.6 Host OSVERSION: 1300136 Jail OSVERSION: 1300136 I'd open a PR with your details. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting /usr/src to match specific git hash?
On Sun, Jan 24, 2021 at 09:00:45AM -0700, Warner Losh wrote: > On Sun, Jan 24, 2021, 6:05 AM Jeffrey Bouquet > wrote: > > > > > > > On Sat, 23 Jan 2021 20:14:03 -0800, Steve Kargl < > > s...@troutmask.apl.washington.edu> wrote: > > > > > On Sun, Jan 24, 2021 at 01:08:05PM +0900, Yasuhiro Kimura wrote: > > > > From: Steve Kargl > > > > Subject: Getting /usr/src to match specific git hash? > > > > Date: Sat, 23 Jan 2021 19:58:52 -0800 > > > > > > > > > Suppose one has an empty /usr/src. > > > > > > > > > > Suppose further that one had to re-install a 32-bit > > > > > i386-*-freebsd with the 24 Dec 2020 image available > > > > > from freebsd.org. > > > > > > > > > > uname -a for the booted kernel shows > > > > > > > > > > % uname -a > > > > > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 \ > > > > > 3cc0c0d66a0-c255241(main)-dirty: Thu Dec 24 05:43:23 UTC 2020 \ > > > > > r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/i386.i386/sys/GENERIC > > i386 > > > > > > > > > > How does one use git to pull the exact sources that match > > > > > this specifc kernel? > > > > > > > > cd /usr > > > > git clone https://git.freebsd.org/src.git > > > > cd src > > > > git checkout 3cc0c0d66a0 > > > > > > > > > > Thank you. > > > > > > -- > > > Steve > > > ___ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > > freebsd-current-unsubscr...@freebsd.org" > > > > Can this be put in /usr/src/UPDATING with an explanation of precisely how > > each > > of the git commands populates or repopulated the directories in /usr??? > > > > It is in the mini primer I wrote, along with how to bisect and other useful > things. This will migrate into the handbook once the doc tree converts to > asciidoc (happening this weekend). > > https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md I'm glad this is moving to FreeBSD's documentation. Following the process of FreeBSD's migration to git has been a bit troublesome with some docs somewhere other docs elsewhere. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Getting /usr/src to match specific git hash?
On Sun, Jan 24, 2021, 6:05 AM Jeffrey Bouquet wrote: > > > On Sat, 23 Jan 2021 20:14:03 -0800, Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > > > On Sun, Jan 24, 2021 at 01:08:05PM +0900, Yasuhiro Kimura wrote: > > > From: Steve Kargl > > > Subject: Getting /usr/src to match specific git hash? > > > Date: Sat, 23 Jan 2021 19:58:52 -0800 > > > > > > > Suppose one has an empty /usr/src. > > > > > > > > Suppose further that one had to re-install a 32-bit > > > > i386-*-freebsd with the 24 Dec 2020 image available > > > > from freebsd.org. > > > > > > > > uname -a for the booted kernel shows > > > > > > > > % uname -a > > > > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 \ > > > > 3cc0c0d66a0-c255241(main)-dirty: Thu Dec 24 05:43:23 UTC 2020 \ > > > > r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/i386.i386/sys/GENERIC > i386 > > > > > > > > How does one use git to pull the exact sources that match > > > > this specifc kernel? > > > > > > cd /usr > > > git clone https://git.freebsd.org/src.git > > > cd src > > > git checkout 3cc0c0d66a0 > > > > > > > Thank you. > > > > -- > > Steve > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > Can this be put in /usr/src/UPDATING with an explanation of precisely how > each > of the git commands populates or repopulated the directories in /usr??? > It is in the mini primer I wrote, along with how to bisect and other useful things. This will migrate into the handbook once the doc tree converts to asciidoc (happening this weekend). https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md Warner > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Files in /usr/share/misc
> On Jan 24, 2021, at 05:36, mj-mailingl...@gmx.de wrote: > What is the history behind /usr/share/misc? Hi Martin, Have you read “man hier”, by chance? This might elucidate things a bit. Cheers, -Enji ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Files in /usr/share/misc
While browsing the filesystem, i found the folder /usr/share/misc and now i am curious, what kind of files and why they were put there. The list on "13.0-ALPHA2 stable/13-f76393a63" looks like this: -r--r--r-- 1 root wheel 3170 Jan 24 09:18 ascii -r--r--r-- 1 root wheel 5265 Jun 25 2020 bc.library -r--r--r-- 1 root wheel 374 Jan 24 09:18 birthtoken -r--r--r-- 1 root wheel43643 Jan 24 09:18 bsd-family-tree -r--r--r-- 1 root wheel 6633 Jan 24 09:18 committers-doc.dot -r--r--r-- 1 root wheel23555 Jan 24 09:18 committers-ports.dot -r--r--r-- 1 root wheel29343 Jan 24 09:18 committers-src.dot -r--r--r-- 1 root wheel19304 Jan 24 09:18 definitions.units -r--r--r-- 1 root wheel 1390 Jan 24 09:18 flowers drwxr-xr-x 2 root wheel2 Jun 25 2020 fonts -r--r--r-- 1 root wheel 3267 Jan 24 09:18 gprof.callg -r--r--r-- 1 root wheel 1064 Jan 24 09:18 gprof.flat -r--r--r-- 1 root wheel 25 Jan 24 09:18 init.ee -r--r--r-- 1 root wheel15481 Jan 24 09:18 iso3166 -r--r--r-- 1 root wheel12422 Jan 24 09:18 iso639 -r--r--r-- 1 root wheel 2391 Jan 24 09:18 latin1 -r--r--r-- 1 root wheel 1177518 Jan 24 09:18 magic -r--r--r-- 1 root wheel 6653320 Jan 24 09:18 magic.mgc -r--r--r-- 1 root wheel 941 Jan 24 09:18 mail.help -r--r--r-- 1 root wheel 1284 Jan 24 09:18 mail.tildehelp -r--r--r-- 1 root wheel 1133 Jan 24 09:18 mdoc.template -r--r--r-- 1 root wheel 582 Jan 24 09:18 operator -r--r--r-- 1 root wheel 4165 Jan 24 09:18 organization.dot -r--r--r-- 1 root wheel 1246724 Jan 24 09:18 pci_vendors -r--r--r-- 1 root wheel10913 Jan 24 09:18 scsi_modes -r--r--r-- 1 root wheel 212427 Jan 24 09:18 termcap -r--r--r-- 1 root wheel 1343488 Jan 24 09:18 termcap.db -r--r--r-- 1 root wheel37626 Jan 24 09:18 usb_hid_usages -r--r--r-- 1 root wheel 206318 Jan 24 09:18 usbdevs -r--r--r-- 1 root wheel 7081 Jan 24 09:18 windrv_stub.c There are - some more, some less technical "lookup" files, like: ascii, birthtoken, flowers, iso3166, iso639, latin1,... - some FreeBSD project related files, like: bsd-family-tree.dot, committers-*.dot, organization.dot These would better be part of the documentation. BTW, on 12.x they are out of date: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251701 - some configuration an scripting examples, like: init.ee, gprof.callg, gprof.flat,... IMHO better placed in .../examples - development(?) related files, like: pci_vendors, scsi_modes, usb_hid_usages, usbdevs, windrv_stub.c I don't know if these files are used during build-/runtime - some files which are used during (build-?/)runtime: magic, magic.mgc, termcap, termcap.db Shouldn't these be in a more specific place? They are pretty static, so the "var" part in /var/db does not fit, but services.db is located there, too. - is the fonts folder in base, or did some port create it? I'm not sure. What is the history behind /usr/share/misc? -- Martin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting /usr/src to match specific git hash?
On Sat, 23 Jan 2021 20:14:03 -0800, Steve Kargl wrote: > On Sun, Jan 24, 2021 at 01:08:05PM +0900, Yasuhiro Kimura wrote: > > From: Steve Kargl > > Subject: Getting /usr/src to match specific git hash? > > Date: Sat, 23 Jan 2021 19:58:52 -0800 > > > > > Suppose one has an empty /usr/src. > > > > > > Suppose further that one had to re-install a 32-bit > > > i386-*-freebsd with the 24 Dec 2020 image available > > > from freebsd.org. > > > > > > uname -a for the booted kernel shows > > > > > > % uname -a > > > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 \ > > > 3cc0c0d66a0-c255241(main)-dirty: Thu Dec 24 05:43:23 UTC 2020 \ > > > r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/i386.i386/sys/GENERIC i386 > > > > > > How does one use git to pull the exact sources that match > > > this specifc kernel? > > > > cd /usr > > git clone https://git.freebsd.org/src.git > > cd src > > git checkout 3cc0c0d66a0 > > > > Thank you. > > -- > Steve > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Can this be put in /usr/src/UPDATING with an explanation of precisely how each of the git commands populates or repopulated the directories in /usr??? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkg for 14-current
Yasuhiro Kimura writes: G> From: Masachika ISHIZUKA > Subject: pkg for 14-current > Date: Sun, 24 Jan 2021 19:11:28 +0900 (JST) > >> Hi. >> >> I updated to 14-current from 13-current and reinstalled ports-mgmt/pkg. >> I cannot get meta files for 14-current. >> How can I use pkg on 14-current ? >> >>> # pkg update >>> Updating FreeBSD repository catalogue... >>> pkg: http://pkgmir.geo.freebsd.org/FreeBSD:14:amd64/latest/meta.txz: Not >>> Found >>> repository FreeBSD has no meta file, using default settings >>> pkg: http://pkgmir.geo.freebsd.org/FreeBSD:14:amd64/latest/packagesite.txz: >>> Not Found >>> Unable to update repository FreeBSD >>> Error updating repositories! > > All what you can do is to wait until build of offical packages for > 14-CURRENT has completed unless you build them by yourself. Or temporarily redefine ABI as a workaround e.g., $ env ABI=FreeBSD:13:amd64 pkg install chromium ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Which branch in git is 13.0-current?
On Sun, Jan 24, 2021 at 06:11:04AM -0600, donaldwillin...@gmail.com wrote:
> I'm happy the number was changed. To many, the number "13" is
> considered to be bad luck.
>
It was not "changed" for that reason.
It's a natural progression from 11 to 12 to 13 to 14 (to 15 ...).
It's the way stable/* branches of FreeBSD are created: they are branched
off of head ("main") in sequence.
"13" is the most recent (and still nascent, at this stage of
development) stable branch; as a result, head is now designated as
"14".
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
So Lindsey Graham thinks that Trump's incitement of the Capitol mob on 6 Jan
should be without consequences? Graham suppoprts what the mob did??!?
See https://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
Re: Which branch in git is 13.0-current?
I'm happy the number was changed. To many, the number "13" is considered to be bad luck. On Sat, 2021-01-23 at 17:51 -0800, David Wolfskill wrote: > On Sat, Jan 23, 2021 at 06:34:58PM -0700, Russell L. Carter wrote: > > ... > > > That is correct, 13-stable has been branched from 13-current > > > which has now > > > been bumped to 14-current. > > > Because it's a major version change going from 13 to 14, pkg is a > > > bit > > > agitated regarding the ABI. > > > > So has anyone tracking stable/12 and ports successfully completed > > the > > git checkout stable/13; make buildworld; make installworld; > > mergemaster > > drill? I see I can checkout stable/13. > > With the substitution of "etcupdate" for "mergemaster," yes. > > Mind, I am using ports built under stable/12: I have installed the > misc/compat12x port. > > (My build machine is presently running poudriere under: > > FreeBSD freebeast.catwhisker.org 13.0-ALPHA2 FreeBSD 13.0-ALPHA2 > #1162 stable/13-c256208-gf76393a6305b: Sat Jan 23 07:09:19 PST > 2021 > r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/amd64.amd64/sys/ > GENERIC amd64 1300136 1300136 > > building packages for stable/13. I don't plan to use them right > away; this is mostly a bit of a stress-test for stable/13: bapt@ > called it "poudriere" for at least one good reason.) > > Current status: > > [13amd64-ports-home] [2021-01-23_22h27m11s] [parallel_build:] Queued: > 1038 Built: 568 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: > 470 Time: 03:21:46 > > > > Do make.conf | src.conf | GENERIC have silent breaking changes? > > I usually, recklessly, assume no. > > My build machine (builds and) runs a GENERIC kernel. It also builds > a couple of other kernels for stable/12 and stable/13; no issues > with either. > > > Ima throw the build->install as soon as the drill looks good. > > > > Russell > > > > I admit to having cheated a fair bit: I have also been tracking head. > > So last night, I "cloned" my "head" slice for use for stable/13; > there > was little to change, once that was done. (Yes, I use MBR/BIOS > booting.) > > Boring details: > > * History: https://www.catwhisker.org/~david/FreeBSD/history/ > > * How I do stuff: > https://www.catwhisker.org/~david/FreeBSD/upgrade.html > > * How I keep sources in sync: > https://www.catwhisker.org/~david/FreeBSD/repo-sync.html > > Peace, > david ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: adding existing ipv6 network route returns ENOMEM instead of EEXIST if loopback route also exists
Hi, On 25/11/20 1:12 pm, Alexander V. Chernikov wrote: 21.11.2020, 22:48, "Guy Yur" : Hi, When adding a route with a netmask, add_route() in route_ctl.c adds the route with destination address masked. If the add failed (for example, the route exists) it calls lookup_prefix() with the original unmasked destination. Thank you for the report! Indeed, there is a problem w.r.t non-masked dst handling. I'll look into that in the end of this week. Did you get a chance to look at it? I am currently using a workaround of setting RTAX_DST to the masked address before the call to lookup_prefix in add_route(): info->rti_info[RTAX_DST] = rt_key(rt); /* addition failed. Lookup prefix in the rib to determine the cause */ rt_orig = lookup_prefix(rnh, info, _orig); In a scenario where a loopback route was added followed by the network route being added, if the network route is added again and the network route destination is the same as the loopback route, lookup_prefix() will match on the loopback route, not finding the network route and add_route() will return ENOMEM instead of EEXIST. Adding the route with just the network part returns EEXIST as expected. Example: # route -6 add -host fd53:: -prefixlen 128 ::1 # route -6 add -net fd53:: -prefixlen 64 ::1 # route -6 add -net fd53:: -prefixlen 64 ::1 route: writing to routing socket: Cannot allocate memory add net fd53::: gateway ::1 fib 0: Cannot allocate memory # route -6 add -net fd53:: -prefixlen 64 ::1 add net fd53::: gateway ::1 fib 0: route already in table I was testing https://reviews.freebsd.org/D15406 changes applied to r367863. The changes call rtinit to add prefix route when interface address is added/updated and uses the interface address as the destination. rtinit returned ENOMEM instead of EEXIST causing dhcpcd to printCannot allocate memory. route commands above showing the problem were run in r367863 without D15406 changesas well. Thanks, Guy Yur ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Thanks, Guy Yur ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkg for 14-current
From: Yasuhiro Kimura Subject: Re: pkg for 14-current Date: Sun, 24 Jan 2021 19:18:29 +0900 (JST) >> I updated to 14-current from 13-current and reinstalled ports-mgmt/pkg. >> I cannot get meta files for 14-current. >> How can I use pkg on 14-current ? >> > All what you can do is to wait until build of offical packages for > 14-CURRENT has completed unless you build them by yourself. By the way, when -CURRENT was bumped from 12 to 13, there were some ports that failed to be built on 13-CURRENT simply because they don't expect there is version 13.x of FreeBSD. And probably such ports fails to be built on 14-CURRENT with same reason. So it may takes for a while until offical packages for 14-CURRENT are provided with same level as 13-CURRENT. --- Yasuhiro Kimura ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkg for 14-current
From: Masachika ISHIZUKA Subject: pkg for 14-current Date: Sun, 24 Jan 2021 19:11:28 +0900 (JST) > Hi. > > I updated to 14-current from 13-current and reinstalled ports-mgmt/pkg. > I cannot get meta files for 14-current. > How can I use pkg on 14-current ? > >> # pkg update >> Updating FreeBSD repository catalogue... >> pkg: http://pkgmir.geo.freebsd.org/FreeBSD:14:amd64/latest/meta.txz: Not >> Found >> repository FreeBSD has no meta file, using default settings >> pkg: http://pkgmir.geo.freebsd.org/FreeBSD:14:amd64/latest/packagesite.txz: >> Not Found >> Unable to update repository FreeBSD >> Error updating repositories! All what you can do is to wait until build of offical packages for 14-CURRENT has completed unless you build them by yourself. --- Yasuhiro Kimura ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
pkg for 14-current
Hi. I updated to 14-current from 13-current and reinstalled ports-mgmt/pkg. I cannot get meta files for 14-current. How can I use pkg on 14-current ? > # pkg update > Updating FreeBSD repository catalogue... > pkg: http://pkgmir.geo.freebsd.org/FreeBSD:14:amd64/latest/meta.txz: Not Found > repository FreeBSD has no meta file, using default settings > pkg: http://pkgmir.geo.freebsd.org/FreeBSD:14:amd64/latest/packagesite.txz: > Not Found > Unable to update repository FreeBSD > Error updating repositories! -- Masachika ISHIZUKA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes)
On 2021-Jan-22, at 01:45, Mark Millard wrote: > Given an already built, installed and booted system version, I've > noted a big difference for META_MODE in 2 rebuild contexts (no > source updates involved): > > *) Prior buildworld buildkernel, installkernel, installworld, boot > presumed before (A) and before (B) below. > > A) make . . . buildworld buildkernel > make . . . buildworld buildkernel > (the 2nd buildworld buildkernel in (A) builds far less than the first) > (that means that the first built more than I would have guessed) > > vs. > > B) make . . . buildworld buildkernel > make . . . installworld > make . . . buildworld buildkernel > (the 2nd buildworld buildkernel in (B) builds far more than it did in (A)) > (so, more like the 1st buildworld buildkernel in (A) and (B), given >the specified prior context) > > So I used make -dM for the commented buildworld buildkernel lines, logging > the build output and later diff'ing them. > > Result that I noticed? Lots of lines uniquely from (B)'s case, ending with > one of: > > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/awk' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/cap_mkdb' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/cat' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/cp' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/crunchgen' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/crunchide' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/dd' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/egrep' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/env' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/file2c' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/gencat' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/grep' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/gzip' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/jot' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/lex' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/ln' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/m4' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/mv' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/patch' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/rm' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/sed' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/sh' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/touch' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/truncate' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/uudecode' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/uuencode' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/xargs' > is newer than the target... > > The lines with these lead to more files being updated and so causing more > indirect rebuild activity (that cascades). > > Many/most/all(?) of these seem to me to be unlikely to actually need to > contribute to what needs to be rebuilt (just based on being newer). So > the option to ignore (some of?) them could be useful in making META_MODE > builds quicker. The following from one of the .meta files makes the point
