"don't know how to make /usr/main-src/sys/contrib/dev/iwm/iwm-3160-17.fw.uu. Stop"
Unfortunately, for now my reporting is based on my personal build environment, not on anofficial FreeBSD build. Context doing the building: # uname -apKU FreeBSD 7950X3D-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT #155 main-n274094-45d5b9f0324a-dirty: Sat Dec 7 23:06:19 PST 2024 root@7950X3D-ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 1500029 1500029 Building what? : # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ 46a9fb7287f4 (HEAD -> main, freebsd/main, freebsd/HEAD) man.1: Improve search + spdx Author: Alexander Ziaee Commit: Alexander Ziaee CommitDate: 2025-01-25 00:07:01 + branch: main merge-base: 46a9fb7287f41eedf321d81a68a826f231d11bfe merge-base: CommitDate: 2025-01-25 00:07:01 + n275030 (--first-parent --count for merge-base) Got (nodbg is similar): Building /usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-DBG/iwm3160fw.o . . . make[2]: don't know how to make /usr/main-src/sys/contrib/dev/iwm/iwm-3160-17.fw.uu. Stop make[2]: stopped making "all" in /usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-DBG .ERROR_TARGET='/usr/main-src/sys/contrib/dev/iwm/iwm-3160-17.fw.uu' .ERROR_META_FILE='' .MAKE.LEVEL='2' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose curdirOk=yes' _ERROR_CMD='.PHONY' .CURDIR='/usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-DBG' .MAKE='make' .OBJDIR='/usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-DBG' .TARGETS='all' CPUTYPE='' DESTDIR='' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MACHINE_CPUARCH='amd64' MAKEOBJDIRPREFIX='' MAKESYSPATH='/usr/main-src/share/mk' MAKE_VERSION='20240711' PATH='/usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/tmp/bin:/usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/tmp/usr/sbin:/usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/tmp/usr/bin:/usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/tmp/legacy/bin:/usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/main-src' OBJTOP='/usr/main-src' .MAKE.MAKEFILES='/usr/main-src/share/mk/sys.mk /usr/main-src/share/mk/local.sys.env.mk /usr/main-src/share/mk/src.sys.env.mk /usr/home/root/src.configs/src.conf.amd64-dbg-clang.amd64-host /usr/main-src/share/mk/bsd.mkopt.mk /usr/main-src/share/mk/src.sys.obj.mk /usr/main-src/share/mk/local.sys.machine.mk /usr/main-src/share/mk/meta.sys.mk /usr/main-src/share/mk/local.meta.sys.env.mk /usr/main-src/share/mk/auto.obj.mk /usr/main-src/share/mk/bsd.suffixes.mk /usr/home/root/src.configs/make.conf /usr/main-src/share/mk/local.sys.mk /usr/main-src/share/mk/src.sys.mk /dev/null Makefile /usr/main-src/sys/conf/kern.pre.mk /usr/main-src/share/mk/bsd.own.mk /usr/main-src/share/mk/bsd.opts.mk /usr/main-src/share/mk/bsd.cpu.mk /usr/main-src/share/mk/bsd.compiler.mk /usr/main-src/share/mk/bsd.endian.mk /usr/main-src/share/mk/bsd.linker.mk /usr/main-src/sys/conf/kern.opts.mk /usr/main-src/sys/conf/kern.post.mk /usr/main-src/sys/conf/kern.mk' .PATH='. /usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-DBG' 37.06 real 108.72 user 5.50 sys make[1]: stopped making "buildkernel" in /usr/main-src make: stopped making "buildkernel" in /usr/main-src Script done, output file is /usr/obj/BUILDs/main-amd64-dbg-clang/sys-typescripts/typescript-make-amd64-dbg-clang-amd64-host-2025-01-25:01:25:05 === Mark Millard marklmi at yahoo.com
Re: "don't know how to make /usr/main-src/sys/contrib/dev/iwm/iwm-3160-17.fw.uu. Stop"
On Jan 25, 2025, at 02:10, Stefan Esser wrote: > Am 25.01.25 um 10:54 schrieb Mark Millard: >> Unfortunately, for now my reporting is based on my personal build >> environment, >> not on anofficial FreeBSD build. >> Context doing the building: > > Hi Mark, > > probably an issue due to commit af0a81b6470 from 2024-12-12: > > commit af0a81b6470aba4af4a24ae9804053722846ded4 > Author: Emmanuel Vadot > Date: Thu Dec 12 17:13:58 2024 +0100 > >iwm: Stop shipping firmware as kernel module > >Since we can load raw firmware start shipping them as is. >This also remove the uuencode format that don't add any value and garbage >collect old firmwares version. >For pkgbase users they are now in the FreeBSD-firmware-iwm package. > >Sponsored by: Beckhoff Automation GmbH & Co. KG > > Maybe your sources are out of sync with regard to that commit? https://cgit.freebsd.org/src/blame/sys/conf/files shows the lines that I quoted that indicate dependencies on various *.fw.uu files. It is true that a pre 2024-Dec-12 installation is attempting to build what I reported: 2025-01-25 00:07:01 + ( i.e., n275030 46a9fb7287f41eedf321d81a68a826f231d11bfe ). I had not updated at all between those times and was finally trying to update. === Mark Millard marklmi at yahoo.com
Re: /usr/src and /usr/ports not git directories ?
Florian Walpen wrote in <4081188.p4y8TspHLy@z240>: |On Thursday, January 23, 2025 4:38:16 AM CET Florian Walpen wrote: |> Installing the src tree as a non-git snapshot is useless for developers \ |> and |> people that update through src builds, I agree with that. My take is that |> installing the src tree is optional, giving a hint in the installer \ |> should |> be enough. There will be secondary steps anyway in this scenario, like |> installing the git executable and updating the src tree. As stated, we |> could simplify the post-install repo cloning through a Makefile. | |FWIW, I found the /usr/Makefile that is part of DragonflyBSD here: I *thought* the thing is also data reduction, you know. As in, if the source directory is simply tarballed, you have the full size but no git repository; if you want to update, you need to download the full new ball, even if the actual changes are only a few megabyte or so. (Or bsdiff(1)ed, but no such iirc.) If you have the git directory that it is, "fully" garbage collected, then this increases the size, but you can then simply update, merge --ff-only. But this is a large tarball. If you ship only the .git repository *without* a checkout, with a depth of 1, you get almost the same size as with the normal only-sources tarball, but you can use git to update very easily, with minimal bandwidth, you can use git to populate the complete history, etc. However, you need git to perform the initial checkout of the sources. git is large and git is not BSD/etc licensed. Thus: if you would have a minimal program that fetches the blob content out of a shallow, garbage-collected git clone, you have all the advantages, but none of the disadvantages. Problem is there is no such program. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |In Fall and Winter, feel "The Dropbear Bard"s pint(er). | |The banded bear |without a care, |Banged on himself for e'er and e'er | |Farewell, dear collar bear
Re: [9fans] /usr/src and /usr/ports not git directories ?
Bakul Shah wrote in : |[-9fans, +freebsd-current as 9fans adds a reply-to: 9fans line] |> On Jan 23, 2025, at 3:53 PM, Warner Losh wrote: |> |> I fail to see how putting code in the kernel is better than just \ |> using got for the few people that are alergic to git. Even if it \ |> is only 1000 lines in plan 9, but likely more in FreeBSD and by the \ |> way not yet ported to FreeBSD. We know got can't crash the system \ |> and is small enough to not matter, even if it isn't in the base today. | |May I suggest: |- always ship the *commit hash* for any release or snapshot with its \ |base.txz |- src.txz as now (or add commit hash) |- this is enough to download a repo (1-deep or whatever), bare if src.txz \ |was also unpacked. |- add a simple script to download as above. |- people can install whatever git client they want for further work. | |git9 doesn't require any kernel code but on freebsd you'd have to |use plan9port. It is far simpler but has a different interface. I never meant to take _exactly_ the code as in Plan9 / 9front btw. I only knew he was doing the work already, and did so over so several years, so there is experience. Likely the code that accesses git's objects/ as such is pretty lean / portable. Maybe even he would have been willing to port the extract to POSIX so that for example "xy HASH" searches in . and cats a blob content to stdout, you know. Hey, it seems his qpath() even uses Torek's hash! Here you have the BSD link you are missing. :) A nice Sunday everyone whoeever can, and others even more. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |In Fall and Winter, feel "The Dropbear Bard"s pint(er). | |The banded bear |without a care, |Banged on himself for e'er and e'er | |Farewell, dear collar bear
Re: /usr/src and /usr/ports not git directories ?
Warner Losh wrote in : |On Sat, Jan 25, 2025 at 10:50 AM Steffen Nurpmeso |wrote: |> Florian Walpen wrote in |> <4081188.p4y8TspHLy@z240>: |>|On Thursday, January 23, 2025 4:38:16 AM CET Florian Walpen wrote: |>|> Installing the src tree as a non-git snapshot is useless for |> developers \ |>|> and |>|> people that update through src builds, I agree with that. My take is |> that |>|> installing the src tree is optional, giving a hint in the installer \ |>|> should |>|> be enough. There will be secondary steps anyway in this scenario, like |>|> installing the git executable and updating the src tree. As stated, we |>|> could simplify the post-install repo cloning through a Makefile. |>| |>|FWIW, I found the /usr/Makefile that is part of DragonflyBSD here: |> |> I *thought* the thing is also data reduction, you know. |> |> As in, if the source directory is simply tarballed, you have the |> full size but no git repository; if you want to update, you need |> to download the full new ball, even if the actual changes are only |> a few megabyte or so. (Or bsdiff(1)ed, but no such iirc.) |> |> If you have the git directory that it is, "fully" garbage |> collected, then this increases the size, but you can then simply |> update, merge --ff-only. But this is a large tarball. |> |> If you ship only the .git repository *without* a checkout, with |> a depth of 1, you get almost the same size as with the normal |> only-sources tarball, but you can use git to update very easily, |> with minimal bandwidth, you can use git to populate the complete |> history, etc. |> However, you need git to perform the initial checkout of the |> sources. git is large and git is not BSD/etc licensed. |> Thus: if you would have a minimal program that fetches the blob |> content out of a shallow, garbage-collected git clone, you have |> all the advantages, but none of the disadvantages. |> Problem is there is no such program. | |pkg add git isn't terrible. pkg add got is even smaller and should |work, but I've not double checked. | |Since moving to git, git has become 'table stakes' to do things |with the system. While we don't go out of our way to make 'got' not |work for simple things, we don't test it that often either. got has |a happy license, but an incompatible CLI and it's quite a bit less |capable than git, despite it's better license. Including it in base has |a lot of issues beyond the git import (how much of our git instructions |do we update to include it in our docs, for example). | |So it's possible to extract things w/o GPL'd code, it would be very |much a niche thing for the relatively few people that care. Everybody |else would take 'the paved path' of git and not give it a second thought. |I think the projects limited resources would be best spent by doing this |and allowing the purists to be able to do it if they wanted, while not |saddling everybody else with a tool they aren't familiar with. In a world |where we have infinite resources, we could do the training and education |needed for got, but pragmatically, I think got or any other git-alternative |path is too much of a hassle for too many people to be a viable option |any time soon. That is where i started with the way i do it for myself, with "git checkout $(cat NULL)"; this NULL could in FreeBSD be a file README that states something like "make checkout" or so ... Even though that smells like DragonFly BSD then :) I install git on my FreeBSDs, so this is not about me. (Since i track FreeBSD source i can very well use git archive to get the sources from "the inside", if desired. Having a file that contains the branch name in src/ would allow automatization of that even.) It was only a suggestion... Ciao, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |In Fall and Winter, feel "The Dropbear Bard"s pint(er). | |The banded bear |without a care, |Banged on himself for e'er and e'er | |Farewell, dear collar bear
Re: /usr/src and /usr/ports not git directories ?
On Sat, Jan 25, 2025 at 10:50 AM Steffen Nurpmeso wrote: > Florian Walpen wrote in > <4081188.p4y8TspHLy@z240>: > |On Thursday, January 23, 2025 4:38:16 AM CET Florian Walpen wrote: > |> Installing the src tree as a non-git snapshot is useless for > developers \ > |> and > |> people that update through src builds, I agree with that. My take is > that > |> installing the src tree is optional, giving a hint in the installer \ > |> should > |> be enough. There will be secondary steps anyway in this scenario, like > |> installing the git executable and updating the src tree. As stated, we > |> could simplify the post-install repo cloning through a Makefile. > | > |FWIW, I found the /usr/Makefile that is part of DragonflyBSD here: > > I *thought* the thing is also data reduction, you know. > > As in, if the source directory is simply tarballed, you have the > full size but no git repository; if you want to update, you need > to download the full new ball, even if the actual changes are only > a few megabyte or so. (Or bsdiff(1)ed, but no such iirc.) > > If you have the git directory that it is, "fully" garbage > collected, then this increases the size, but you can then simply > update, merge --ff-only. But this is a large tarball. > > If you ship only the .git repository *without* a checkout, with > a depth of 1, you get almost the same size as with the normal > only-sources tarball, but you can use git to update very easily, > with minimal bandwidth, you can use git to populate the complete > history, etc. > However, you need git to perform the initial checkout of the > sources. git is large and git is not BSD/etc licensed. > Thus: if you would have a minimal program that fetches the blob > content out of a shallow, garbage-collected git clone, you have > all the advantages, but none of the disadvantages. > Problem is there is no such program. > pkg add git isn't terrible. pkg add got is even smaller and should work, but I've not double checked. Since moving to git, git has become 'table stakes' to do things with the system. While we don't go out of our way to make 'got' not work for simple things, we don't test it that often either. got has a happy license, but an incompatible CLI and it's quite a bit less capable than git, despite it's better license. Including it in base has a lot of issues beyond the git import (how much of our git instructions do we update to include it in our docs, for example). So it's possible to extract things w/o GPL'd code, it would be very much a niche thing for the relatively few people that care. Everybody else would take 'the paved path' of git and not give it a second thought. I think the projects limited resources would be best spent by doing this and allowing the purists to be able to do it if they wanted, while not saddling everybody else with a tool they aren't familiar with. In a world where we have infinite resources, we could do the training and education needed for got, but pragmatically, I think got or any other git-alternative path is too much of a hassle for too many people to be a viable option any time soon. Warner > --steffen > | > |Der Kragenbaer,The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > | > |In Fall and Winter, feel "The Dropbear Bard"s pint(er). > | > |The banded bear > |without a care, > |Banged on himself for e'er and e'er > | > |Farewell, dear collar bear >
