Re: Large builds with poudriere
On 2021-May-20, at 21:10, Chris wrote: > On 2021-05-20 13:47, Mark Millard wrote: >> Chris portmaster at bsdforge.com wrote on >> Thu May 20 20:09:29 UTC 2021 : >>> On 2021-05-20 12:21, Kevin Oberman wrote: >>> > . . . >>> >> >>> > You can greatly reduce the build-time for devel/llvm* by changing the >>> > config to BE_NATIVE to avoid building backends for all FreeBSD supported >>> > platforms. Obviously this is not acceptable for many cases, but if you >>> > never cross-compile for other platforms, it's a really big win. >>> If I understand correctly. Isn't your suggestion synonymous with >>> WITHOUT_CROSS_COMPILER? >> So far as I know, devel/llvm* builds make no use of WITHOUT_CROSS_COMPILER >> definitions ( documented in src.conf ) or what I mention below (also from >> src.conf documentation). >> As for what is analogous in src.conf's documentation for system >> builds: BE_NATIVE in an devel/llvm* for a given context would be >> analogous to using a specific mix of: >>WITHOUT_LLVM_TARGET_AARCH64 vs. WITH_LLVM_TARGET_AARCH64 >>WITHOUT_LLVM_TARGET_ARM vs. WITH_LLVM_TARGET_ARM >>WITHOUT_LLVM_TARGET_MIPSvs. WITH_LLVM_TARGET_MIPS >>WITHOUT_LLVM_TARGET_POWERPC vs. WITH_LLVM_TARGET_POWERPC >>WITHOUT_LLVM_TARGET_RISCV vs. WITH_LLVM_TARGET_RISCV >>WITHOUT_LLVM_TARGET_X86 vs. WITH_LLVM_TARGET_X86 >> Some of the mixes would simulate the various devel/llvm* ports >> BE_NATIVE's intent for various platforms. (BE_NATIVE does not >> work in all contexts, last I tried it anyway.) > Ahh. My mistake I guess. I somehow got the idea that defining > WITHOUT_CROSS_COMPILER caused llvm to build only what's needed > build/bootstrap for the arch it's (currently) running on. Which > would, of course. Slim down the buildtime/installed footprint. (I'm not trying to have my wording below cover older gcc based FreeBSD alternatives.) 13.x of FreeBSD building 14.0 (for example) generally uses a bootstrap compiler even for the same architecture. A difference is the default target of the two compilers, such as: aarch64-unknown-freebsd13.0 vs. aarch64-unknown-freebsd14.0 even if that were the only difference at the time. (A different form of "cross"?) devel/llvm* does not have this bootstrapping issue that is driven by FreeBSD definitions for building FreeBSD --instead of by processor architecture. WITHOUT_CROSS_COMPILER for a FreeBSD system build causes: WITHOUT_CLANG_BOOTSTRAP WITHOUT_ELFTOOLCHAIN_BOOTSTRAP WITHOUT_LLD_BOOTSTRAP and so can not be used for the 13.x to 14.0 example: such is not an example of "close" if I understand right: WITHOUT_CROSS_COMPILER Set to not build any cross compiler in the cross-tools stage of buildworld. When compiling a different version of FreeBSD than what is installed on the system, provide an alternate compiler with XCC to ensure success. When compiling with an identical version of FreeBSD to the host, this option may be safely used. This option may also be safe when the host version of FreeBSD is close to the sources being built, but all bets are off if there have been any changes to the toolchain between the versions. When set, it enforces these options: WITHOUT_CLANG_BOOTSTRAP WITHOUT_ELFTOOLCHAIN_BOOTSTRAP WITHOUT_LLD_BOOTSTRAP (One might have compilers around for XCC and such symbol use but that is a different kind of context.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Large builds with poudriere
Kevin Oberman rkoberman at gmail.com wrote on
Thu May 20 21:37:28 UTC 2021 :
> On Thu, May 20, 2021 at 12:48 PM Mark Millard wrote:
>
> > Kevin Oberman rkoberman at gmail.com wrote on
> > Thu May 20 19:21:24 UTC 2021 :
> >
> > > You can greatly reduce the build-time for devel/llvm* by changing the
> > > config to BE_NATIVE to avoid building backends for all FreeBSD supported
> > > platforms. Obviously this is not acceptable for many cases, but if you
> > > never cross-compile for other platforms, it's a really big win.
> >
> >
> > Unfortunately, using something like (llvm10 is just one example,
> > llvm11 showed the same sort of problem at the time):
> >
> > /usr/local/etc/poudriere.d/options/devel_llvm10/options:_FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU
> > CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE
> > BE_STANDARD
> >
> > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_AMDGPU
> >
> > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_FREEBSD
> >
> > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_NATIVE
> >
> > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_STANDARD
> >
> > does not work for all platforms/targets. On a Cortex-A57
> > this lead to:
> >
> > Registered Targets:
> > amdgcn - AMD GCN GPUs
> > r600 - AMD GPUs HD2XXX-HD6XXX
> >
> > In other words, aarch64 was missing. I had to pick
> > BE_STANDARD or BE_FREEBSD to get something that
> > would target aarch64 on aarch64.
> >
> > ===
> > Mark Millard
> > marklmi at yahoo.com
> > ( dsl-only.net went
> > away in early 2018-Mar)
> >
> Looks like the Makefile might need some work. I see stuff for handling
> aach64/arm64, so it SHOULD work, but there are things I don't understand
> about AARCH64 to figure it all out. Still, it should be detected.
>
> Out of curiosity, if you do a "make -C /usr/ports/devel/llvm10 config",
> the line for BE_NATIVE should show the architecture you are running on. If
> it's missing/something else, maybe you should ask brooks@ about it.
On two types of Cortex-A72 context
# make -C /usr/ports/devel/llvm10 config
produced:
BE_NATIVE Backend(s) for this architecture ()
The same for each of:
# make -C /usr/ports/devel/llvm80 config
# make -C /usr/ports/devel/llvm90 config
# make -C /usr/ports/devel/llvm11 config
# make -C /usr/ports/devel/llvm12 config
But this turns out to be because:
# make -C /usr/ports/devel/llvm10 -V ARCH
aarch64
yet the Makefiles have a test for arm64 instead:
.elif ${ARCH} == arm64
_NATIVE_BACKENDS= AAarch64
FYI (from one of the test environments):
# uname -apKU
FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0
releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021
root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1300139 1300139
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Large builds with poudriere
Chris portmaster at bsdforge.com wrote on Thu May 20 20:09:29 UTC 2021 : > On 2021-05-20 12:21, Kevin Oberman wrote: > > . . . > >> > > You can greatly reduce the build-time for devel/llvm* by changing the > > config to BE_NATIVE to avoid building backends for all FreeBSD supported > > platforms. Obviously this is not acceptable for many cases, but if you > > never cross-compile for other platforms, it's a really big win. > > If I understand correctly. Isn't your suggestion synonymous with > WITHOUT_CROSS_COMPILER? So far as I know, devel/llvm* builds make no use of WITHOUT_CROSS_COMPILER definitions ( documented in src.conf ) or what I mention below (also from src.conf documentation). As for what is analogous in src.conf's documentation for system builds: BE_NATIVE in an devel/llvm* for a given context would be analogous to using a specific mix of: WITHOUT_LLVM_TARGET_AARCH64 vs. WITH_LLVM_TARGET_AARCH64 WITHOUT_LLVM_TARGET_ARM vs. WITH_LLVM_TARGET_ARM WITHOUT_LLVM_TARGET_MIPSvs. WITH_LLVM_TARGET_MIPS WITHOUT_LLVM_TARGET_POWERPC vs. WITH_LLVM_TARGET_POWERPC WITHOUT_LLVM_TARGET_RISCV vs. WITH_LLVM_TARGET_RISCV WITHOUT_LLVM_TARGET_X86 vs. WITH_LLVM_TARGET_X86 Some of the mixes would simulate the various devel/llvm* ports BE_NATIVE's intent for various platforms. (BE_NATIVE does not work in all contexts, last I tried it anyway.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Large builds with poudriere
Kevin Oberman rkoberman at gmail.com wrote on Thu May 20 19:21:24 UTC 2021 : > You can greatly reduce the build-time for devel/llvm* by changing the > config to BE_NATIVE to avoid building backends for all FreeBSD supported > platforms. Obviously this is not acceptable for many cases, but if you > never cross-compile for other platforms, it's a really big win. Unfortunately, using something like (llvm10 is just one example, llvm11 showed the same sort of problem at the time): /usr/local/etc/poudriere.d/options/devel_llvm10/options:_FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_AMDGPU /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_FREEBSD /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_NATIVE /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_STANDARD does not work for all platforms/targets. On a Cortex-A57 this lead to: Registered Targets: amdgcn - AMD GCN GPUs r600 - AMD GPUs HD2XXX-HD6XXX In other words, aarch64 was missing. I had to pick BE_STANDARD or BE_FREEBSD to get something that would target aarch64 on aarch64. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Large builds with poudriere
On 2021-May-20, at 11:11, Mark Millard wrote: > Andrea Venturoli ml at netfence.it wrote on > Thu May 20 14:54:50 UTC 2021 : > >> On 5/20/21 4:11 PM, Alexis Praga wrote: >>> >>> Thanks for the suggestions. >>> >>>> At least, if your machine is powerful enough, you can edit your >>>> /usr/local/etc/poudriere.conf and list these big ports in >>>> ALLOW_MAKE_JOBS_PACKAGES. >>> I'm using ALLOW_MAKE_JOBS=yes already so it won't help unfortunately, I >>> think. >> >> Those are not the same things. Check the docs. >> >> Briefly, ALLOW_MAKE_JOBS will allow building several packages at once >> (one per core) with one core dedicated to each. > > Nope: /usr/local/etc/poudriere.conf.sample reports that it enables > more than one process per cpu: > > # By default MAKE_JOBS is disabled to allow only one process per cpu > # Use the following to allow it anyway > # ALLOW_MAKE_JOBS=yes My wording was poor by being incomplete: ALLOW_MAKE_JOBS allows each builder to have as many processes as there are cores/processors. So if multiple builders are allowed (and happen to be in use), then the total number of processes ready to run for building can be bigger than the number of cores/processors, something that shows up in the load averages. How many builders are allowed can be controlled with: # parallel build support. # # By default poudriere uses hw.ncpu to determine the number of builders. # You can override this default by changing PARALLEL_JOBS here, or # by specifying the -J flag to bulk/testport. # # Example to define PARALLEL_JOBS to one single job # PARALLEL_JOBS=1 Looking in /usr/ports/Mk/bsd.port.mk there is also the following, that is part of where some of the "MAKE_JOBS" terminology comes from: # MAKE_JOBS_UNSAFE # - Disallow multiple jobs even when user set a global override. # To be used with known bad ports. # DISABLE_MAKE_JOBS # - Set to disable the multiple jobs feature. User settable. # MAKE_JOBS_NUMBER # - Override the number of make jobs to be used. User settable. # MAKE_JOBS_NUMBER_LIMIT # - Set a limit for maximum number of make jobs allowed to be # used. >> ALLOW_MAKE_JOBS_PACKAGES will let a single package build using more cores. > > > Even when MAKE_JOBS is otherwise disabled: > > # List of packages that will always be allowed to use MAKE_JOBS > # regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports > # which holdup the rest of the queue to build more quickly. > #ALLOW_MAKE_JOBS_PACKAGES="pkg ccache py*" === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Large builds with poudriere
Andrea Venturoli ml at netfence.it wrote on Thu May 20 14:54:50 UTC 2021 : > On 5/20/21 4:11 PM, Alexis Praga wrote: > > > > Thanks for the suggestions. > > > >> At least, if your machine is powerful enough, you can edit your > >> /usr/local/etc/poudriere.conf and list these big ports in > >> ALLOW_MAKE_JOBS_PACKAGES. > > I'm using ALLOW_MAKE_JOBS=yes already so it won't help unfortunately, I > > think. > > Those are not the same things. Check the docs. > > Briefly, ALLOW_MAKE_JOBS will allow building several packages at once > (one per core) with one core dedicated to each. Nope: /usr/local/etc/poudriere.conf.sample reports that it enables more than one process per cpu: # By default MAKE_JOBS is disabled to allow only one process per cpu # Use the following to allow it anyway # ALLOW_MAKE_JOBS=yes > ALLOW_MAKE_JOBS_PACKAGES will let a single package build using more cores. Even when MAKE_JOBS is otherwise disabled: # List of packages that will always be allowed to use MAKE_JOBS # regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports # which holdup the rest of the queue to build more quickly. #ALLOW_MAKE_JOBS_PACKAGES="pkg ccache py*" === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
On aarch64: "sysutils/hpacucli dependency on misc/compat4x has wrong PKGNAME"
I was doing a poudriere pkgclean under: # uname -apKU FreeBSD CA72_16Gp_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 and got a message: [00:07:18] Warning: sysutils/hpacucli dependency on misc/compat4x has wrong PKGNAME of 'compat4x-i386' but should be 'compat4x-aarch64' For reference: # cd /usr/ports # ~/fbsd-based-on-what-commit.sh branch: main merge-base: b309895b3544ffba9e8df8786062ec6013c752ff merge-base: CommitDate: 2021-05-17 06:32:36 + b309895b3544 (HEAD -> main, freebsd/main, freebsd/HEAD) x11-themes/kde-icons-black-and-white: add LICENSE, take MAINTAINER n545993 (--first-parent --count for merge-base) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
ent is so >> messed up that pkg delete -a would fail. >> >> I'll note that if pkg instead still points to the >> FreeBSD servers (such as quarterly), the same 2 >> command sequence should re-establish those builds. >> > > I started a: > > # poudriere bulk -j13_0R-CA72 x11-wm/lxqt > > on one of the aarch64 systems that I have access to > (cortex-a72 with 4 cores). It reports (based on prior > history of other ports building that might overlap and > so avoid some things needing to be built this time): > > . . . > [00:00:25] Building 99 packages using 4 builders > . . . > [00:00:38] [03] [00:00:00] Building lang/rust | rust-1.52.1 > . . . > > so it looks like it will be hours from when I started > it before it will have finished, presuming that rust > builds to completion. (Rust takes longer and uses more > disk space and the like to build than any llvm* that > I normally build.) > > I expect to later report that it built to completion, no > failure, so long as nothing else causes lxqt ports to > be skipped. But we will see if my context gets the same > results as the FreeBSD build server(s). > > If it builds, I'll see if pkg can install it. > > poudriere jail 13_0R-CA72 is based on a releng/13 > release/13.0.0 installworld, instead of being based > on a main [so: 14] one. This should not matter for > the issues at hand. Technically, I could reboot into > main [so: 14] (so that kernel is running) and build > in jail main-CA72 that has an installation of main > --but I do not think it would provide significantly > different information. > > The system is faster than an RPi4B, despite the > configurations using the same Cortex-A72 count > and clock rate. It has more RAM (16 GiByte) and > more RAM caching, and a RAM subsystem that is > faster overall for parallel activities (more than > size can matter for caching effectiveness for > parallel activities). > > (The used system's single DIMM DDR4 RAM+RAM > caching was less effective for parallel jobs than > the OverDrive 1000's smaller but dual-DIMM RAM > subsystem [8 GiByte] and larger RAM-caches, despite > the OverDrive having 4 Cortex-A57s and a slower CPU > clock rate. Unfortunately, the OverDrive 1000 > failed recently or I would have used it to cut > the time some. The used system is the faster one > for activities that are close to single threaded.) > . . . [13_0R-CA72-default] [2021-05-19_10h44m58s] [committing:] Queued: 99 Built: 99 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 0 Time: 08:30:14 . . . # pkg install x11-wm/lxqt Updating custom repository catalogue... Fetching meta.conf: 100%163 B 0.2kB/s00:01 Fetching packagesite.txz: 100% 140 KiB 143.5kB/s00:01 Processing entries: 100% custom repository update completed. 612 packages processed. All repositories are up to date. Checking integrity... done (0 conflicting) The following 74 package(s) will be affected (of 0 checked): New packages to be INSTALLED: . . . . . . [1/74] Installing qt5-linguisttools-5.15.2... [1/74] Extracting qt5-linguisttools-5.15.2: 100% . . . [74/74] Installing lxqt-0.17.0... [74/74] Extracting lxqt-0.17.0: 100% So: It worked fine. (The system has no video hardware present, so lxqt is untested but installed at this point.) FYI: at one point just lang/rust was using about 17634 MiBytes of temporary storage space. That lang/rust requires such an amount of storage space to build is not specific to poudriere builds. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
oid some things needing to be built this time): . . . [00:00:25] Building 99 packages using 4 builders . . . [00:00:38] [03] [00:00:00] Building lang/rust | rust-1.52.1 . . . so it looks like it will be hours from when I started it before it will have finished, presuming that rust builds to completion. (Rust takes longer and uses more disk space and the like to build than any llvm* that I normally build.) I expect to later report that it built to completion, no failure, so long as nothing else causes lxqt ports to be skipped. But we will see if my context gets the same results as the FreeBSD build server(s). If it builds, I'll see if pkg can install it. poudriere jail 13_0R-CA72 is based on a releng/13 release/13.0.0 installworld, instead of being based on a main [so: 14] one. This should not matter for the issues at hand. Technically, I could reboot into main [so: 14] (so that kernel is running) and build in jail main-CA72 that has an installation of main --but I do not think it would provide significantly different information. The system is faster than an RPi4B, despite the configurations using the same Cortex-A72 count and clock rate. It has more RAM (16 GiByte) and more RAM caching, and a RAM subsystem that is faster overall for parallel activities (more than size can matter for caching effectiveness for parallel activities). (The used system's single DIMM DDR4 RAM+RAM caching was less effective for parallel jobs than the OverDrive 1000's smaller but dual-DIMM RAM subsystem [8 GiByte] and larger RAM-caches, despite the OverDrive having 4 Cortex-A57s and a slower CPU clock rate. Unfortunately, the OverDrive 1000 failed recently or I would have used it to cut the time some. The used system is the faster one for activities that are close to single threaded.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
bob prohaska fbsd at www.zefox.net wrote on Wed May 19 16:09:32 UTC 2021 : > On Tue, May 18, 2021 at 09:24:00AM +0200, Stefan Esser wrote: > > > > [portmaster background omitted] > > > If you want to give the attached port a try, it will install LUA and some > > > I tried ports-mgmt/portmaster, it got stuck the same as make. > Unless the new version behaves very differently I'm doubtful it'll > help. > > At the moment it looks like lxqt requires both python37 and python38. > The needs seem to arise at different stages of the build, so perhaps > they can be invoked, used and removed sequentially, but at this point > deleting python37 causes enough collateral damage to make further > progress impossible, or at least non-obvious. > > If the conflict is really limited to merely naming two versions of > /usr/local/bin/easy_install fixing the naming convention seems to be > the obvious answer. I remain baffled why something called "easy_install" > remains essential after installatiion. Unless of course it's not really > an installer. Even so, a more sensible naming scheme strikes me as helpful. > > It isn't apparent to me that something like poudriere can solve this sort > of problem either. If poudriere attempts to build lxqt in a single jail > it looks like the conflict will emerge within the jail. The FreeBSD port building servers use poudriere and are not having a problem. The problem is your messed up environment that already has the inappropriate mixed that poudriere and the package installers it makes would never produce. The following show lxqt (10 ports have that in their names) as attempted to be built (not skipped) and all were successful instead of any failing: Built with python37: Apr 20: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p338d8ba0f777_s5a89498d19 Apr 13: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p46fc7df8540c_s1f64f32a4c Apr 17: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p9d5f4ef1a469_s86046cf55f Built with python38: May 11: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p0c0a4f4b9148_scb07628d9e May 15: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p6ffbcd54bf8c_s91f251b2ab May 18: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p7bfc2c072607_s8d2b4b2e7c May 6: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=pcd62f0886c18_sd1cb8d11b0 These imply that all the prerequisite ports for the build were also built and working for doing so. > It'd have to > split the build between two or more jails and then merge the (compatible) > executables into a third jail for completion, AIUI. No such problems in a correctly configured system. You are stuck trying to get out of a incorrect system configuration. poudriere ignores your system configuration and uses its own separate one to do its builds. > At this point I'm stuck. So you had a poudriere failure? If so, report the details, such as publishing someplace the log file showing the failure. Otherwise, you are not stuck. Once poudriere has built the packages, you would set up pkg to use those builds and then force-(re)install all your ports to use the ones poudriere built. (Not just lxqt.) This would get all your ports back to being coherent with each other. Presuming a file listing the packages that you want to be sure are installed (not needing to list dependencies) and that that pkg has arleady been redirected to use the poudriere-built packages: # pkg delete -a # pkg install `cat file-listing-packages` Technically, I do not know if your environment is so messed up that pkg delete -a would fail. I'll note that if pkg instead still points to the FreeBSD servers (such as quarterly), the same 2 command sequence should re-establish those builds. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Is there a way to subscribe to the commit messages for only ports you maintain?
On 18-5-2021 03:56, Chris wrote:
On 2021-05-17 18:17, Julian H. Stacey wrote:
Chris wrote:
On 2021-05-17 16:30, Jan Beich wrote:
> Chris writes:
>
>> I'd like to subscribe to the commit messages
>> ( dev-commits-ports-all )
>> but only receive messages that affect me -- the
>> ports I currently maintain. Is it possible? Or
>> am I just dreaming? ;-)
>
> No clue but I use Herald rules for something similar.
Thanks for the hints, Jan. :-)
Herald ? Nothing from
https://www.freebsd.org/cgi/ports.cgi?query=herald=all=all
...
https://en.wikipedia.org/wiki/Phabricator
...
https://cgit.freebsd.org/ports/tree/devel/phabricator/pkg-descr
I'd use /usr/ports/mail/procmail
https://lists.freebsd.org/pipermail/dev-commits-ports-all/2021-May/date.html
~/.procmailrc example:
:0 H
* ^Sender: owner-dev-commits-ports-...@freebsd.org
{
:0 H
* ^Subject: git: .+ sysutils/rubygem-bolt
| $RCVSTORE +dir_of_ports_you_might_maintain
:0 H
* ^Subject: git: .+ x11/xterm
| $RCVSTORE +another_dir_of_ports_you_might_maintain
}
or eg: # mkdir ~/Mail/your_ports
:0 H
* ^Sender: owner-dev-commits-ports-...@freebsd.org
* ^Subject: git: .+
(archivers/bzip|audio/pocketsphinx|audio/snd|comms/pr|comms/sms_client|databases/pgaccess|devel/c2mdoc|devel/compiz-bcop|devel/ecgi|devel/codeville|devel/frink|dns/dnscheckengine|dns/ldapdns|graphics/gdtclft|graphics/gimmage|graphics/repng2jpeg|graphics/urt|lang/picoc|net/beacon|net/openradius|net/spread|net/wackamole|net-im/mbpurple|sysutils/cdroot|sysutils/ffs2recov|sysutils/rsyncbackup|textproc/asm2html|textproc/smi|textproc/sansi|www/spreadlogd|www/ttf2eot|x11/wmblob|x11/xvt|x11-themes/kde-icons-graphite-rade8|x11-toolkits/iwidgets|x11-wm/icewm)
| $RCVSTORE +your_ports
Wow! Thanks Julian. You even did all my homework for me.! ;-)
In fact I think your re would even satisfy Herald.
Yup, this is a great example.
I had been wining about the same problem in private, but dit not even
realize that this list is available.
Perhaps this piece of code and suggestion for commits-ports-all could go
into the porters manual?
--WjW
_______
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
bob prohaska fbsd at www.zefox.net wrote on Mon May 17 23:46:38 UTC 2021 : > On Mon, May 17, 2021 at 12:28:24PM -0700, Mark Millard via freebsd-ports > wrote: > > bob prohaska fbsd at www.zefox.net wrote on > > Mon May 17 15:55:21 UTC 2021 : > > > > > The existing conflict between versions of python strikes me as more of a > > > planning problem than a software bug. It may be naive, but I don't see > > > why python37 and python38 can't use distinct names for files placed in > > > system directories. > > > > You seem to be under the impression that absent having > > any common file paths, things would just work. This > > seems unlikely. A simplified presentation of why > > follows. > > > > I'm under the impression that absence of common paths would help > reduce conflicts. True: possibly necessary, even if not sufficient. > In the case at hand it might be sufficient. I do not know: I do not have a very complete understanding of the full status of your environment after the problem. (Nor of just what specifically lead to the problem.) I do know that I do not deal with the issue in my context --but that is because I use procedures that avoid the general type of issue (tolerating any other tradeoffs involved). (I have worked via portmaster and just plain make in the past before using poudriere as well.) > > Imagine two programs: > > > > p37 that is set up for python37 > > p38 that is set up for python38 > > > > imagine that both use a library plib that is > > not internal to each but external to both. > > > > So should plib be built/present for python37? > > python38? Both? > > > > If both: it suggests building a huge set of python > > software multiple times, once per supported version > > in the range of to-be-supported python versions. (I > > do assume python versions make for some degree of > > incompatibility distinctions. It might be only only > > some version changes have that property. But such > > would not change the basic point.) > > > > It suggests that p37 (installed first) would install > its preferred version of plib. When p38 is installed, it > would test for a compatible version of plib So now p38 is required to classify all prior combinations of versions of external libraries it might use (such plib), and to put in tests for handling all the combinations. And what if p38 is installed first and p37 second? p37 must do similarly --but has no way to well classify combinations involving library versions that did not exist when it was released. One alternative in the industry is having each package fully self contained (up to the interfacong with the OS or whatever the kind of context is). The package-build builds everything required and bundles what is needed at run time all together so the package does not depend on any other packages: its installer and installation results are self sufficient (up to the "OS"). This makes other tradeoffs. There are examples that are similar in ports, some tied to bootstrapping issues. For example, building ports-mgmt/pkg builds far more internally because pkg can not depend on other ports/packages that would need pkg to already be operational to get things setup. https://github.com/freebsd/pkg/tree/master/external/ lists: blake2/ libelf/ libfetch/ liblua/ libmachista/ libucl/ linenoise/ lua/ msgpuck/ picosat/ sqlite/ uthash/ yxml/ As I understand lang/rust contains and builds its own (subset of?) some llvm version instead of depending on one of llvm10/llvm11/llvm12. Its build time and resource use may be illustrations of some of the tradeoffs in this style: its build of an llvm does no good at saving time for any other port build that involves the same vintage of llvm. > and add a new > one, with a different name, if the prior version isn't > satisfactory. Libraries already seem to have a variety of > suffixes on their names, so it appears something of the sort > is already going on. Am I completely missing the point? See notes above. > > I know, for example, python39 invalidated code in > > something I've built in a non-FreeBSD context. The > > software had to be modified to be compatible with > > both older python's and python39 (if they wanted > > to support the older versions as well going > > forward). (It was not a context of wanting to take > > advantage of new things in the newer python. But > > that kind of context is not universal.) > > Not sure I see a fundamental problem here. Python > 38 remaining useful/necessary after introduction of > 39 doesn't seem so bad. It seems the norm. How far back are the pre-supplied older versions supposed to go? On operating system A? B? C? (Likely differing choices
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
bob prohaska fbsd at www.zefox.net wrote on Mon May 17 15:55:21 UTC 2021 : > The existing conflict between versions of python strikes me as more of a > planning problem than a software bug. It may be naive, but I don't see > why python37 and python38 can't use distinct names for files placed in > system directories. You seem to be under the impression that absent having any common file paths, things would just work. This seems unlikely. A simplified presentation of why follows. Imagine two programs: p37 that is set up for python37 p38 that is set up for python38 imagine that both use a library plib that is not internal to each but external to both. So should plib be built/present for python37? python38? Both? If both: it suggests building a huge set of python software multiple times, once per supported version in the range of to-be-supported python versions. (I do assume python versions make for some degree of incompatibility distinctions. It might be only only some version changes have that property. But such would not change the basic point.) I know, for example, python39 invalidated code in something I've built in a non-FreeBSD context. The software had to be modified to be compatible with both older python's and python39 (if they wanted to support the older versions as well going forward). (It was not a context of wanting to take advantage of new things in the newer python. But that kind of context is not universal.) Most ports having a separate upstream to deal with and having a huge number of ports makes for port-developer and upstream-developer coordination based solutions having great difficulties overall. No technical-content has been presented to make these sorts of problems disappear. With the problems being present, it is a matter of working in a way that avoids running into the problems or with dealing with fixing things when the problems occur. I've done both basic styles over the years and recognize tradeoffs. I'm happy to help someone explore one of the ways in which poudriere can be an alternative. It is not for me to declare how well it would end up fitting their goals, context, preferences, and so on vs. other alternatives overall. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
-i "TERM=$TERM" /usr/bin/login -f -p root
> This is where you can debug, etc. in a mostly clean environment.
I've only used -i to get in the session at the end of a
bulk build. Someday I may experiment with the above sort
of sequence. Thanks for the notes.
> If you break that environment too much, you can use the following command to
> get it back to normal.
> poudriere jail -k -j main -p default
Good to know.
> # Regardless of which person's method is more efficient, I am releasing my
> method in a similar topic area to let people know that there are different
> types of methods.
Thanks for all the notes!
Relative to Bob's activity, he had already reported poudriere as
complicated to become familiar with for his purposes. So I was
avoiding suggesting alternatives for him to initially explore,
as well as avoiding covering other areas where I know he has an
already existing pattern of operation (buildworld, installworld,
etc.). Less to learn all at once. Bob had mentioned avoiding
necessarily using significant extra storage and such as well.
I did not intend to indicate that the alternative presented
was the unique most-efficient style of use, even for Bob's
context. I just tried to address his concerns to give an
initial context to start with, reusing what he already does
that is related. If he finds it sufficiently appropriate to
his context, he may well explore alternatives usage styles.
Hopefully I got close enough to matching his context for
him to make the go/no-go judgments about poudriere use from
trying it --without having to explore poudriere's many
alternative configuration possibilities first.
> Any jails other than -m null will be cleanly removed by poudriere jail -d, so
> try different ones :)
I forgot to warn Bob of:
QUOTE
Be careful to respect the names supported by jail(8):
This is an arbitrary string that identifies a jail (except it
may not contain a '.').
END QUOTE
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On 2021-May-16, at 00:16, Tatsuki Makino wrote:
> Mark Millard via freebsd-ports wrote on 2021/05/16 10:57:
>> In the form that I use poudriere I use something
>> like the following. I presume here that /usr/src
>> is populated and has the source for the system
>> involved. (I do not remember your describing its
>> status.)
> (Omitted below)
>
> I was just wondering...
> If you want to use the sources in /usr/src and collect the files in /usr/obj
> to make a jail, the following is easier.
>
> poudriere jail -c -j main -m 'src=/usr/src' -v `make -C /usr/src/release/ -V
> VERSION VERSION=\$\{REVISION:Q\}-\$\{BRANCH:Q\}`
>
> Updating it can be done with just the following.
>
> poudriere jail -u -j main
Bob already does a buildworld based on /usr/src for other
reasons/uses than poudriere. My suggestions are targeted
to resusing that buildworld result instead of involving
doing another buildworld for poudriere. It is also biased
to not changing how he does that buildworld (out of scope
to what he was asking about). So far as I know he does
not use /usr/src/release to do builds. Bob's system is
not fast, each buildworld is time consuming.
Would your command suggestion reuse his already-existing
buildworld?
In my own use the same is true: I buildworld separately
before any poudriere activity (for other reasons/uses)
and then I reuse the buildworld that resulted for
also setting up poudriere later.
In essence, the same buildworld that generates what I
boot is later also used to set up (or update) a
poudriere. In other contexts, I set up (or update) an
independent chroot directory tree first and later a
poudriere directory tree --via one buildworld used
for setting up (or updating) both.
I do not use /usr/src/release to do buildworld or
installworld activities.
As most of the systems involved for my activity are
far from fast, avoiding extra buildworlds and reusing
buildworld results saves time. It also saves storage.
(I choose to work the same way on the fast
ThreadRipper 1950X for uniformity of procedure.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
Something I've not asked about or otherwise referenced is if you use non-default port options for any of the ports that you build. There is: poudriere options -jmain -c -f ~root/origins/main-origins.txt or: poudriere options -jmain -C -f ~root/origins/main-origins.txt where -c vs. -C is: QUOTE -c Use 'config' target, which will always show the dialog for the given ports. -C Use 'config-conditional' target, which will only bring up the dialog on new options for the given ports. (This is the default) END QUOTE There is also: QUOTE -n Do not be recursive -r Remove port options instead of configuring them -s Show port options instead of configuring them END QUOTE See: man poudriere-options === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
y38-diffoscope
sysutils/rpi-firmware
sysutils/smartmontools
sysutils/stress
sysutils/u-boot-orangepi-plus-2e
sysutils/u-boot-pine64
sysutils/u-boot-rock64
sysutils/u-boot-rpi-arm64
sysutils/u-boot-rpi2
sysutils/u-boot-rpi3
sysutils/u-boot-rpi4
sysutils/u-boot-sinovoip-bpi-m3
x11-drivers/xf86-video-scfb
x11/lumina
x11/xorg-minimal
x11/xterm
The files that configure pkg to use what poudriere
has built are:
# ls -Tld /usr/local/etc/pkg/repos/*
-rw-r--r-- 1 root wheel 25 Apr 25 20:35:22 2021
/usr/local/etc/pkg/repos/FreeBSD.conf
-rw-r--r-- 1 root wheel 111 Apr 25 20:39:38 2021
/usr/local/etc/pkg/repos/custom.conf
(Again: that I use an "as root" context is visible.
Adjust as needed.)
Example content for this is as shown:
# more /usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD: { enabled: no }
# more /usr/local/etc/pkg/repos/custom.conf
custom: {
url: "file:///usr/local/poudriere/data/packages/main-default",
enabled: yes,
}
With those, something like:
# pkg install `cat ~root/origins/main-pkgs.txt`
would try installing the packages that had been
built. pkg has a -f option but it means "force",
not "file": thus the use of cat. With
pre-existing ports installed, -f may be required
to replace them all with poudriere's builds.
The command will install other ports needed at
run-time, not just what you explicitly list.
The command will not install ports only needed
at build time.
Given the initial problem that you are starting
from, you likely want to do:
# pkg delete -a
# pkg install `cat ~root/origins/main-pkgs.txt`
so that no cruft is left installed, ending up
with just what poudriere built.
Hopefully the above material helps.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
only one type of context to cover. E) Build as root? As non-root? I happen to only have done build as root but the systems are not used for other activities. There could be ownership/permission issues that I've not run into. Examples of a couple of configuration files . . . You might end up with a file like: # more /usr/local/etc/poudriere.d/make.conf WANT_QT_VERBOSE_CONFIGURE=1 (I no longer remember why I enabled that.) For a UFS context an example of the differences with the /usr/local/etc/poudriere.conf.sample file is as follows ( +: poudriere.conf and -: poudriere.conf.sample ). Some of it presumes example answers to the earlier questions. (white space details might not go through unchanged) # diff -u /usr/local/etc/poudriere.conf.sample /usr/local/etc/poudriere.conf --- /usr/local/etc/poudriere.conf.sample2021-03-09 07:43:07.0 -0800 +++ /usr/local/etc/poudriere.conf 2021-05-14 19:09:30.055596000 -0700 @@ -13,7 +13,7 @@ ### NO ZFS # To not use ZFS, define NO_ZFS=yes -#NO_ZFS=yes +NO_ZFS=yes # root of the poudriere zfs filesystem, by default /poudriere # ZROOTFS=/poudriere @@ -27,7 +27,7 @@ # Also note that all protocols supported by fetch(1) are supported here, even # file:/// # Suggested: https://download.FreeBSD.org -FREEBSD_HOST=_PROTO_://_CHANGE_THIS_ +FREEBSD_HOST=https://download.FreeBSD.org # By default the jails have no /etc/resolv.conf, you will need to set # RESOLV_CONF to a file on your hosts system that will be copied to @@ -56,7 +56,15 @@ # yes - Enables tmpfs(5) for wrkdir and data # no- Disable use of tmpfs(5) # EXAMPLE: USE_TMPFS="wrkdir data" -USE_TMPFS=yes +#NOTE: Disable (or just "data") for < 8 GiByte RAM environments, +# presuming -j4 for 4 cores. wrkdir can be rather large +# (17+ GiByte for lang/rust) and localbase can be larger. +# Swap covers tmpfs space needs. +# For aarch64 I keep total swap somewhat under 4*RAM. +# For armv7 I keep total swap somewhat under 2*RAM. +# This avoids hard to interpret boot notices about being +# mistuned. +USE_TMPFS=no # How much memory to limit tmpfs size to for *each builder* in GiB # (default: none) @@ -155,6 +163,11 @@ # # Example to define PARALLEL_JOBS to one single job # PARALLEL_JOBS=1 +#NOTE: on 2 GiByte RAM contexts I've used: PARALLEL_JOBS=2 but +# two llvm*'s are likely the biggest combination that +# could occur in my context. lang/rust or other even +# larger build contexts need not be appropriate. I +# normally use ALLOW_MAKE_JOBS=yes . # How many jobs should be used for preparing the build? These tend to # be more IO bound and may be worth tweaking. Default: PARALLEL_JOBS * 1.25 @@ -188,12 +201,13 @@ # By default MAKE_JOBS is disabled to allow only one process per cpu # Use the following to allow it anyway -# ALLOW_MAKE_JOBS=yes +ALLOW_MAKE_JOBS=yes # List of packages that will always be allowed to use MAKE_JOBS # regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports # which holdup the rest of the queue to build more quickly. #ALLOW_MAKE_JOBS_PACKAGES="pkg ccache py*" +ALLOW_MAKE_JOBS_PACKAGES="pkg ccache py* gcc* llvm* rust* ghc* *webkit* *office* chromium* iridium* mongodb*" # Timestamp every line of build logs # Default: no @@ -208,11 +222,22 @@ # This defines the max time (in seconds) that a command may run for a build # before it is killed for taking too long. Default: 86400 #MAX_EXECUTION_TIME=86400 +# Cortex-A53 and such are slow for the purpose, allow 4 times the defaults: +MAX_EXECUTION_TIME=432000 # This defines the time (in seconds) before a command is considered to # be in a runaway state for having no output on stdout. Default: 7200 #NOHANG_TIME=7200 +# Cortex-A53 and such are slow for the purpose, allow 4 times the defaults: +# Also: boost-libs seems to have a long time with no output but it making +# progress in parallel builds. +NOHANG_TIME=28800 +# Cortex-A53 and such are slow for the purpose, allow 4 times the defaults: +MAX_EXECUTION_TIME_EXTRACT=14400 +MAX_EXECUTION_TIME_INSTALL=14400 +MAX_EXECUTION_TIME_PACKAGE=28800 +MAX_EXECUTION_TIME_DEINSTALL=14400 # The repository is updated atomically if set yes. This leaves the # repository untouched until the build completes. This involves using @@ -260,7 +285,7 @@ # set. Note that to use ccache with BUILD_AS_NON_ROOT you will need to # use a non-shared CCACHE_DIR that is only built by PORTBUILD_USER and chowned # to that user. Then set CCACHE_DIR_NON_ROOT_SAFE to yes. -#BUILD_AS_NON_ROOT=no +BUILD_AS_NON_ROOT=no # Define to the username to build as when BUILD_AS_NON_ROOT is yes. # Default: nobody (uid PORTBUILD_UID) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Trubles compiling lxqt on RPi4
On 2021-May-13, at 14:27, Tatsuki Makino wrote: > 20210425 of UPDATING doesn't take into care the environment where python37 > and python38 are installed at the same time. > This is a problem for people who installed 3.8 when 3.7 was the default. > (e.g. user of graphics/blender) > > Can you experiment with the commands I've been thinking about in anticipation > of 3.9 becoming the default :) > > # check dependencies. > pkg check -d -n -a > # gather the names of packages that will need to be reinstalled. > pkg query -e '( %n !~ py37-* && %n !~ *-py37-* )' %n-:%dn | grep -e > ':python37\|:py37-\|:.*-py37-' | cut -d : -f 1 | sort -u > /tmp/py37.txt > # gather the origins of manually installed packages where the FLAVOR will > change. > pkg query -e '( %n ~ py37-* || %n ~ *-py37-* ) && %a = 0 && %#''r = 0' %o:%dn > | grep -e ':python37\|:py37-\|:.*-py37-' | cut -d : -f 1 | sort -u > > /tmp/py37-o.txt > # delete the py37 packages > pkg delete -f -g py37-\* \*-py37-\* > # install the package of py37-o.txt > xargs -o -- portmaster (portmaster options of your choice) < /tmp/py37-o.txt > # reinstall the package of py37.txt > xargs -o -- portmaster (portmaster options of your choice) < /tmp/py37.txt > My context is not based on using portmaster at all. I do not create environments with multiple versions of python in use (or other such potential conflicts). So: It will not be me that tests such commands for handling such contexts. May be Bob P. will test your sequence. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Trubles compiling lxqt on RPi4
bob prohaska fbsd at www.zefox.net wrote on
Thu May 13 15:39:41 UTC 2021 :
> On Thu, May 13, 2021 at 08:13:07AM +0200, Jan Beich wrote:
> > >
> > > Moving to /usr/ports/json-glib and using
> > > make -DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4
> > > DISABLE_VULNERABILITIES=yes > make.log
> > > reports several instances of
> > > error: unknown argument: '-fno-color-diagnostics'
> >
> > Likely caused by desync between USES=meson and devel/meson, see
> > https://cgit.freebsd.org/ports/commit/?id=ff2796d5bc83
> >
> > Try again after re-installing devel/meson.
>
> That might be a hint which circles back to Mark's comments related to
> python37 vs -38. Trying to re-make devel/meson finds.
>
> root at nemesis:/usr/ports/devel/meson # make -DBATCH FORCE_PKG_REGISTER=yes
> install
> ===> meson-0.57.1_1 depends on package: py38-setuptools>0 - not found
> ===> Installing for py38-setuptools-44.0.0_1
> ===> Registering installation for py38-setuptools-44.0.0_1 as automatic
> Installing py38-setuptools-44.0.0_1...
> pkg-static: py38-setuptools-44.0.0_1 conflicts with py37-setuptools-44.0.0
> (installs files into the same place). Problematic file:
> /usr/local/bin/easy_install
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/devel/py-setuptools
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/devel/meson
>
> The fix for the -37 vs-38 conflict invokes portmaster, might it
> suffice to simply deinstall -37 and explicitly replace it with
> -38 ? I'll give it a try.
>
> Hmm, no dice. After deinstalling python37 and reinstalling python38 an
> attempt to make devel/meson still stops with
>
> root at nemesis:/usr/ports/devel/meson # make -DBATCH
> DISABLE_VULNERABILITIES=yes install
> ===> meson-0.57.1_1 depends on package: py38-setuptools>0 - not found
> ===> Installing for py38-setuptools-44.0.0_1
> ===> Checking if py38-setuptools is already installed
> ===> Registering installation for py38-setuptools-44.0.0_1 as automatic
> Installing py38-setuptools-44.0.0_1...
> pkg-static: py38-setuptools-44.0.0_1 conflicts with py37-setuptools-44.0.0
> (installs files into the same place). Problematic file:
> /usr/local/bin/easy_install
> *** Error code 1
>
> How did python38 get installed without py38-setuptools?
You have apparently chosen to build/update ports via a
technique that requires you to manage the dependencies, at
least some of the time. (Not that when is necessarily
obvious up front.)
Your environment is now based on a mix of python37 and
python 38 related materials. You are likely going to
need to rework/rebuild/reinstall things to avoid that.
Hints may come from that UPDATING that I quoted but
things are more broken overall than what UPDATING is
intended to cover. You might end up needing to
uninstall a bunch of stuff until python is unused
(or only one python is used) and then follow the
notes if you have only python37 use and want to
get to python38. Finally rebuild/reinstall what
was uninstalled, based on python38 as a context.
(I'm not even sure uninstalls are going to always work
correctly/completely in the mixed context.)
QUOTE
20210425:
AFFECTS: users of python
AUTHOR: kai at FreeBSD.org
The default version of python3 and python was switched to 3.8.
For ports users wanting to keep version 3.7 as default,
add DEFAULT_VERSIONS+= python=3.7 python3=3.7 to make.conf
Following procedures may ease the upgrade:
For users of pre-build packages:
# sh
# for i in $(pkg query -g %n 'py37-*'); do pkg set -yn ${i}:py38-${i#py37-};
done
# pkg upgrade
For portmaster users:
# sh
# portmaster -o lang/python38 python37
# REINSTALL="$(pkg info -o "*py37*" | awk '{printf "%s ", $2}')"
# pkg delete -f "*py37*"
# portmaster $REINSTALL
# REBUILD=$(pkg query -g "%n:%dn" '*' | grep py3 | grep -v py38 | cut -d : -f
1 | sort -u)
# portmaster $REBUILD
# REBUILD2=$(pkg list | grep python-37 | xargs pkg which | awk '{print $6}' |
sort -u)
# portmaster $REBUILD2
END QUOTE
Due to how I build/install ports, I've not had to deal
with ending up with the mix so I'm not familiar with
the details for recovering from a messy mix.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Troubles compiling lxqt on RPi4 [out of date Mk/Uses/meson.mk in use]
On 2021-May-12, at 23:13, Mark Millard wrote:
>
> On 2021-May-12, at 22:28, bob prohaska wrote:
>
>> On Wed, May 12, 2021 at 09:16:29PM -0700, Mark Millard via freebsd-ports
>> wrote:
>>> On 2021-May-12, at 20:48, bob prohaska wrote:
>>>
>>>>
>>>> Moving to /usr/ports/json-glib and using
>>>> make -DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4
>>>> DISABLE_VULNERABILITIES=yes > make.log
>>>> reports several instances of
>>>> error: unknown argument: '-fno-color-diagnostics'
>>>>
>>>> Running make clean and restarting makes no difference. There don't seem to
>>>> be
>>>> any user options for making json-glib,
>>>
>>> The build log at:
>>>
>>> http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb8d11b0/logs/json-glib-1.6.2_1.log
>>>
>>> is the one that just python38 and it reports:
>>>
>>> ---Begin OPTIONS List---
>>> ===> The following configuration options are available for
>>> json-glib-1.6.2_1:
>>>DOCS=on: Build and/or install documentation
>>>GIR=on: Build introspection data
>>> ===> Use 'make config' to modify these settings
>>> ---End OPTIONS List---
>>>
>>> as the options that were used for the build. So
>>> there are 2 options, one of which is appearently
>>> tied to the code's operation (introspection data).
>>>
>>
>> Turning off both options and trying a manual make seems to end with the same
>> error.
>>
>>
>>
>>>> but I wonder if it might be inherting
>>>> an incompatible option from something else.
>>>
>>> That build log also has lines showing the likes of:
>>>
>>> [ 21% 16/69] cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . .
>>> -fno-color-diagnostics . . .
>>>
>>> The compiler is reported in the log to be:
>>>
>>> C compiler for the host machine: cc (clang 11.0.1 "FreeBSD clang version
>>> 11.0.1 (g...@github.com:llvm/llvm-project.git
>>> llvmorg-11.0.1-0-g43ff75f2c3fe)")
>>> C linker for the host machine: cc ld.lld 11.0.1
>>>
>>> That "llvmorg-11.0.1-0-g43ff75f2c3fe" matches what is in my
>>> historical main [so: 14] environments.
>>>
>>> So system-clang apparently allows the option.
>>>
>>> You did not show any example command that got the complaint
>>> about -fno-color-diagnostics so I can ont even be sure it
>>> was a cc command that had the option.
>>>
>>>
>>
>> A copy of the make log is at
>> http://www.zefox.net/~fbsd/rpi4/lxqt/make.log
>
> Note: Your environment is not up to date enough to be using
> python38 . The log shows:
>
> [ 1% 4/69] /usr/local/bin/python3.7 . . .
> . . .
>
> I'll note that /usr/ports/UPDATING reports:
>
> 20210425:
> AFFECTS: users of python
> AUTHOR: k...@freebsd.org
>
> The default version of python3 and python was switched to 3.8.
>
> For ports users wanting to keep version 3.7 as default,
> add DEFAULT_VERSIONS+= python=3.7 python3=3.7 to make.conf
>
> Following procedures may ease the upgrade:
>
> For users of pre-build packages:
> # sh
> # for i in $(pkg query -g %n 'py37-*'); do pkg set -yn ${i}:py38-${i#py37-};
> done
> # pkg upgrade
>
> For portmaster users:
> # sh
> # portmaster -o lang/python38 python37
> # REINSTALL="$(pkg info -o "*py37*" | awk '{printf "%s ", $2}')"
> # pkg delete -f "*py37*"
> # portmaster $REINSTALL
> # REBUILD=$(pkg query -g "%n:%dn" '*' | grep py3 | grep -v py38 | cut -d :
> -f 1 | sort -u)
> # portmaster $REBUILD
> # REBUILD2=$(pkg list | grep python-37 | xargs pkg which | awk '{print $6}'
> | sort -u)
> # portmaster $REBUILD2
>
>
>
> The log also shows the use of -Xclang in the cc commands:
>
> cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . . -Xclang
> -fno-color-diagnostics . . .
>
> but:
>
> http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb8d11b0/logs/json-glib-1.6.2_1.log
>
> does not show any use of -Xclang .
>
> -Xclang makes the following argument be passed directly to the
> cc1 compiler stage. So the:
>
> error: unknown argument: '-fno-color-diagnostics'
>
> would be from cc1. "clang -cc1 --help" only reports one
> form of color-diagnostics option allowed by the -cc1
> stage:
>
> -fcolor-diagnosti
Re: Troubles compiling lxqt on RPi4
On 2021-May-12, at 22:28, bob prohaska wrote:
> On Wed, May 12, 2021 at 09:16:29PM -0700, Mark Millard via freebsd-ports
> wrote:
>> On 2021-May-12, at 20:48, bob prohaska wrote:
>>
>>>
>>> Moving to /usr/ports/json-glib and using
>>> make -DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4
>>> DISABLE_VULNERABILITIES=yes > make.log
>>> reports several instances of
>>> error: unknown argument: '-fno-color-diagnostics'
>>>
>>> Running make clean and restarting makes no difference. There don't seem to
>>> be
>>> any user options for making json-glib,
>>
>> The build log at:
>>
>> http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb8d11b0/logs/json-glib-1.6.2_1.log
>>
>> is the one that just python38 and it reports:
>>
>> ---Begin OPTIONS List---
>> ===> The following configuration options are available for json-glib-1.6.2_1:
>> DOCS=on: Build and/or install documentation
>> GIR=on: Build introspection data
>> ===> Use 'make config' to modify these settings
>> ---End OPTIONS List---
>>
>> as the options that were used for the build. So
>> there are 2 options, one of which is appearently
>> tied to the code's operation (introspection data).
>>
>
> Turning off both options and trying a manual make seems to end with the same
> error.
>
>
>
>>> but I wonder if it might be inherting
>>> an incompatible option from something else.
>>
>> That build log also has lines showing the likes of:
>>
>> [ 21% 16/69] cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . .
>> -fno-color-diagnostics . . .
>>
>> The compiler is reported in the log to be:
>>
>> C compiler for the host machine: cc (clang 11.0.1 "FreeBSD clang version
>> 11.0.1 (g...@github.com:llvm/llvm-project.git
>> llvmorg-11.0.1-0-g43ff75f2c3fe)")
>> C linker for the host machine: cc ld.lld 11.0.1
>>
>> That "llvmorg-11.0.1-0-g43ff75f2c3fe" matches what is in my
>> historical main [so: 14] environments.
>>
>> So system-clang apparently allows the option.
>>
>> You did not show any example command that got the complaint
>> about -fno-color-diagnostics so I can ont even be sure it
>> was a cc command that had the option.
>>
>>
>
> A copy of the make log is at
> http://www.zefox.net/~fbsd/rpi4/lxqt/make.log
Note: Your environment is not up to date enough to be using
python38 . The log shows:
[ 1% 4/69] /usr/local/bin/python3.7 . . .
. . .
I'll note that /usr/ports/UPDATING reports:
20210425:
AFFECTS: users of python
AUTHOR: k...@freebsd.org
The default version of python3 and python was switched to 3.8.
For ports users wanting to keep version 3.7 as default,
add DEFAULT_VERSIONS+= python=3.7 python3=3.7 to make.conf
Following procedures may ease the upgrade:
For users of pre-build packages:
# sh
# for i in $(pkg query -g %n 'py37-*'); do pkg set -yn ${i}:py38-${i#py37-};
done
# pkg upgrade
For portmaster users:
# sh
# portmaster -o lang/python38 python37
# REINSTALL="$(pkg info -o "*py37*" | awk '{printf "%s ", $2}')"
# pkg delete -f "*py37*"
# portmaster $REINSTALL
# REBUILD=$(pkg query -g "%n:%dn" '*' | grep py3 | grep -v py38 | cut -d : -f
1 | sort -u)
# portmaster $REBUILD
# REBUILD2=$(pkg list | grep python-37 | xargs pkg which | awk '{print $6}' |
sort -u)
# portmaster $REBUILD2
The log also shows the use of -Xclang in the cc commands:
cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . . -Xclang
-fno-color-diagnostics . . .
but:
http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb8d11b0/logs/json-glib-1.6.2_1.log
does not show any use of -Xclang .
-Xclang makes the following argument be passed directly to the
cc1 compiler stage. So the:
error: unknown argument: '-fno-color-diagnostics'
would be from cc1. "clang -cc1 --help" only reports one
form of color-diagnostics option allowed by the -cc1
stage:
-fcolor-diagnostics Enable colors in diagnostics
Viewed various ways that confirm:
# more main.c
static volatile char big_area[67001] = "This is a test";
int main ()
{
big_area[67000] = '9';
}
# clang -Xclang -fno-color-diagnostics main.c
error: unknown argument: '-fno-color-diagnostics'
But the detail of what is involved, showing the
-cc1 command that is internally generated, is:
# clang -### -Xclang -fno-color-diagnostics main.c
FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git
llvmorg-11.0.1-0-g43ff75f2c3fe)
Target: x86_64-unknown-freebsd14.0
Thread model: posix
InstalledDir: /usr/bin
&
Re: Trubles compiling lxqt on RPi4
On 2021-May-12, at 20:48, bob prohaska wrote: > On Wed, May 12, 2021 at 05:17:37PM -0700, Mark Millard via freebsd-ports > wrote: >> bob prohaska fbsd at www.zefox.net wrote on >> Wed May 12 21:10:02 UTC 2021 : >> >>> Attempts to compile x11/x11-wm/lxqt on a Pi4 running -current >>> get stuck with: >>> ===> Building for json-glib-1.6.2_1 > [] >>> FAILED: >>> json-glib/libjson-glib-1.0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o >>> >>> Is there a workaround? Ports were up-to-date as of today, May 12, 2021. >> >> You are not very explicit about the FreeBSD context and >> such, beyond RPi4 (so aarm64/aarch64). >> >> > > Moving to /usr/ports/json-glib and using > make -DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4 > DISABLE_VULNERABILITIES=yes > make.log > reports several instances of > error: unknown argument: '-fno-color-diagnostics' > > Running make clean and restarting makes no difference. There don't seem to be > any user options for making json-glib, The build log at: http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb8d11b0/logs/json-glib-1.6.2_1.log is the one that just python38 and it reports: ---Begin OPTIONS List--- ===> The following configuration options are available for json-glib-1.6.2_1: DOCS=on: Build and/or install documentation GIR=on: Build introspection data ===> Use 'make config' to modify these settings ---End OPTIONS List--- as the options that were used for the build. So there are 2 options, one of which is appearently tied to the code's operation (introspection data). > but I wonder if it might be inherting > an incompatible option from something else. That build log also has lines showing the likes of: [ 21% 16/69] cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . . -fno-color-diagnostics . . . The compiler is reported in the log to be: C compiler for the host machine: cc (clang 11.0.1 "FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)") C linker for the host machine: cc ld.lld 11.0.1 That "llvmorg-11.0.1-0-g43ff75f2c3fe" matches what is in my historical main [so: 14] environments. So system-clang apparently allows the option. You did not show any example command that got the complaint about -fno-color-diagnostics so I can ont even be sure it was a cc command that had the option. Still, your report suggests that the "cc" in your environment for this build does not reach the normal system-clang. Do you have /etc/make.conf or /etc/src.conf or the like that might be interfering? Something else? What does "cc -v" show in your context? FYI: As I remember, "-DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4" is incoherent: the first says not to do the last. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Trubles compiling lxqt on RPi4
bob prohaska fbsd at www.zefox.net wrote on Wed May 12 21:10:02 UTC 2021 : > Attempts to compile x11/x11-wm/lxqt on a Pi4 running -current > get stuck with: > ===> Building for json-glib-1.6.2_1 > [ 1% 1/53] cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p -Ijson-glib > -I../json-glib -I. -I.. -I/usr/ > local/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include > -Xclang -fno-color-dia > gnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c99 -O3 -O2 > -fstack-protector-strong > -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include > -fPIC -pthread '-DG_LOG > _DOMAIN="Json"' -DG_LOG_USE_STRUCTURED=1 -DJSON_COMPILATION > '-DJSON_LOCALEDIR="/usr/local/share/loca > le"' -Wcast-align -Wmissing-declarations -Wmissing-format-attribute > -Wmissing-prototypes -Wmissing-n > oreturn -Wold-style-definition -Wpointer-arith -Wshadow -Wstrict-prototypes > -Wunused -Wno-int-conver > sion -fno-strict-aliasing -Wno-uninitialized -Werror=address > -Werror=array-bounds -Werror=empty-body > -Werror=format=2 -Werror=implicit -Werror=init-self > -Werror=int-to-pointer-cast -Werror=main -Werro > r=missing-braces -Werror=nested-externs -Werror=nonnull > -Werror=pointer-to-int-cast -Werror=return-t > ype -Werror=sequence-point -Werror=trigraphs -Werror=undef > -Werror=write-strings -fvisibility=hidden > -MD -MQ > json-glib/libjson-glib-1.0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o > -MF json-gli > b/libjson-glib-1.0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o.d -o > json-glib/libjson-glib-1 > .0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o -c > json-glib/json-enum-types.c > FAILED: > json-glib/libjson-glib-1.0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o > > Is there a workaround? Ports were up-to-date as of today, May 12, 2021. You are not very explicit about the FreeBSD context and such, beyond RPi4 (so aarm64/aarch64). It is also likely that there was more error-type reporting text than just: FAILED: json-glib/libjson-glib-1.0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o The error is from the build attempt for: devel/json-glib instead of directly from lxqt. http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p46fc7df8540c_s1f64f32a4c and: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=pcd62f0886c18_sd1cb8d11b0 show successful builds of json-glib-1.6.2_1 on/for main [so: 14]. The first used python37 and the 2nd python38 . Most of the other modern build runs that show json-glib-1.6.2_1 queued indicate that it was skipped because of: docbook-xml-5.0_3 sdocbook-xml-1.1_2,2 None listed failed builds, so no logs would match your report. https://www.freshports.org/devel/json-glib indicates that the last devel/json-glib update was on 2021-Apr-06. (I've not checked other dependencies, beyond the basicis of the python3 change.) This may get into things like poudriere based builds vs. some other ways of building that are more sensitive to context oddities. But you were not explicit about that aspect of things. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD:13:aarch64 packages are outdated
Yuri yuri at FreeBSD.org wrote on Tue May 11 16:54:05 UTC 2021 : > I checked packages for www/authelia, www/adguardhome, science/siesta and > they are 2+ weeks outdated for thus architecture. Using http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=pe67ae562eb4c_s64fe4400da to search for build status . . . The "Failed ports" search for siesta reports: 258 siesta-4.1.5science/siesta build 0 ??? 00:04:05 clicking on the Log link and looking shows, for example, QUOTE /wrkdirs/usr/ports/science/siesta/work/siesta-4.1.5/Src/ts_dq.F90:458:22: 458 | USE, INTRINSIC :: IEEE_ARITHMETIC, ONLY: IEEE_IS_NAN | 1 Fatal Error: Cannot find an intrinsic module named 'ieee_arithmetic' at (1) compilation terminated. gmake[1]: *** [arch.make:59: ts_dq.o] Error 1 gmake[1]: *** Waiting for unfinished jobs gmake[1]: Leaving directory '/wrkdirs/usr/ports/science/siesta/work/siesta-4.1.5/Obj' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 END QUOTE By contrast, searching for adguardhome shows success. But the overall build run reports :stopped:crashed: . . . QUOTE Master main-arm64-default Build pe67ae562eb4c_s64fe4400da Status stopped:crashed: Jail main-arm64 Set Ports Tree default END QUOTE As for authelia, the build run I looked up the above in only queued 16055 ports and authelia was not queued. (I searched "Queued ports".) Of what: http://ampere2.nyi.freebsd.org/jail.html?mastername=main-arm64-default shows that have the new naming for git-based: 9 of the 13 build runs show "stopped:crashed:". Seems like they are having build problems. Note: http://ampere2.nyi.freebsd.org deals with: main-arm64-deafult http://ampere1.nyi.freebsd.org deals with: 130arm64-quarterly 130releng-arm64-quarterly 122arm64-quarterly You can use these to look up the status. But it is unfortunately and messy to deal with the git naming giving no clue about the order in the sequence of builds, such as no having time encoded to making sorting by name work for such: p0c0a4f4b9148_scb07628d9e I wish that date-and-time had been encoded as a prefix on the names. (To pick an example handling of the issue.) For http://ampere2.nyi.freebsd.org the one listed on that page (currently showing): main-arm64-default p0c0a4f4b9148_scb07628d9e is the active/most-recent build. That is the only one that has some order-of-build information displayed. For http://ampere1.nyi.freebsd.org : 130arm64-quarterly 61257645fee1 130releng-arm64-quarterly ad3fc2921022 122arm64-quarterly e680e4dc222a are similarly listing the active or most recent build of the type. Under "Queued" on the same pages, one can see if the build is for the full 31000+ list or a subset. The same goes for "Queued" when you click through to something like: http://ampere2.nyi.freebsd.org/jail.html?mastername=main-arm64-default === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
State of mail/postfix-sasl for older FreeBSD
(Please CC me, as I am not on -ports) I would like to know what has happened to mail/postfix-sasl, particularly with regards to FreeBSD 11.x (warning: I will ignore any responses about it being EoL). I clearly see committers tinkering around with things for postfix 3.6, which supports OpenSSL 1.1.1 and newer only. postfix 3.5 however works just fine with older base OpenSSL (1.0.2u-freebsd), and said committers seem to recognise that fact with the addition of mail/postfix35. That said: I see mail/postfix-sasl as orphaned, but no mail/postfix35-sasl stub port. Simultaneously, I see mail/postfix35 lacks the SASL_SLAVE -- for reasons completely unknown/undiscussed (not in commit messages, etc.), which is very strange considering this model has been in place in mail/postfix for a very, very long time -- thus likely why there's no stub port. Please, *please* do this properly, i.e. bring back SASL_SLAVE in mail/postfix35 and make a mail/postfix35-sasl stub port. Understand that there's a large percentage of FreeBSD users who do not want to deal with poudrier and its nonsense just to get something as basic as SASL support in their MTA. Stub ports are important for this very reason. Thank you. # pkg version -v | grep postfix postfix-sasl-3.5.10,1 ? orphaned: mail/postfix-sasl # pkg search ^postfix postfix-logwatch-1.40.03_1 Postfix MTA log parser postfix-policyd-sf-1.82_1,1Anti-spam plugin for Postfix (written in C) postfix-policyd-spf-perl-2.010_1 SPF policy service for Postfix written in Perl postfix-policyd-weight-0.1.15.2_6 Weighted policy daemon for postfix postfix-postfwd-2.03 Postfix firewall policy daemon postfix35-3.5.10,1 Secure alternative to widely-used Sendmail postfixadmin-3.2.4 PHP web-based management tool for Postfix virtual domains and users # pkg search -f postfix35-3.5.10,1 | grep SASL LDAP_SASL : off SASL : off SASLKMIT : off SASLKRB5 : off https://github.com/freebsd/freebsd-ports/commit/efa868ac9533de8e3f73b9cc6c938af81bc9caaf#diff-aa9e338474f4fce707a72f5adf92f7ca9cdf10529245a09e1fd215f111ebf9dc -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administrator PGP 0x2A389531 | | Making life hard for others since 1977.| ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
ports-mgmt/poudriere-devel, lang/rust (for example), and USE_TMPFS that includes wrkdir (or yes)
I've been using USE_TMPFS=yes (so "wrkdir data") on various systems, both ZFS (recently) and UFS (generally, even now). Only one system builds rust (in order for something else to be built), at least so far. An example of the wrkdirs tmpfs use for rust is (UFS context): # df -m | grep tmpfs Filesystem 1M-blocks Used Avail Capacity Mounted on . . . tmpfs 301422 17859 283563 6% /usr/local/poudriere/data/.m/FBSDFSSDjail-default/01/wrkdirs . . . This was near the end but the maximum figure was probably somewhat higher than the 17 GiByte+ figure above. The context the example is from is for the only large capacity build machine that I have access to, an amd64 context. I have other build contexts as well, but, so far, none have had to deal with building rust. Rust likely would fit the 8 GiByte RAM + 24 GiByte swap aarch64 build context with USE_TMPFS including wrkdir if it was the only builder running at the time. But the existing builds for the context allow 4 builders in parallel, one per core. [This deals just fine with llvm10, llvm11, llvm12, and, gcc10 (no bootstrap) being what happens to build in parallel, even with USE_TMPFS that includes wrkdir. Rust is just uses more space all by itself.] If I end up with something that requires rust for the aarch64 builder context, is there a different technique to deal with the tradeoff other than giving up on USE_TMPFS spanning wrkdir for all other other ports/builder-instances as well, presuming the same media and partitioning (such as total swap space)? Imaginary examples could be: A) Tell poudriere that lang/rust is to be built by itself despite the general 4-builder context. B) Tell poudriere that USE_TMPFS excludes wrkdir for lang/rust's specific builder. C) . . . (good question) . . . So far all I've come up with is explicitly building lang/rust by itself first, a form of (A): # poudriere bulk -jNAME -w lang/rust # poudriere bulk -jNAME -w -f ~/origins/CA72-origins.txt (Hopefully, reliably remembering to do so.) Is there any better technique that I've not noticed? To some extent here, lang/rust is being used an example of a more general issue: Other ports could have similar issues with attempted wrkdir-included USE_TMPFS use. Note: If I build using WITH_DEBUG, the one system that I have access to that can build such a lang/rust with workdir included in USE_TMPFS shows over 130 GiBytes in the tmpfs earn the end of the builder's activity. (This is a amd64 context with 128 GiBytes of RAM and 192 GiBytes of swapping/paging space.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg builders order of jobs
Tatsuki Makino tatsuki_makino at hotmail.com wrote on
Mon May 10 21:08:06 UTC 2021 :
> In poudriere.conf, there is a setting for BUILDNAME_FORMAT.
> It will be set to the default value of %Y-%m-%d_%Hh%Mm%Ss in
> /usr/local/share/poudriere/common.sh
>
> BUILDNAME_FORMAT is used as ${BUILDNAME:=$(date +${BUILDNAME_FORMAT})} and
> becomes the default value for BUILDNAME.
> BUILDNAME can be set with the -B option of poudriere-bulk.
>
> In other words, I want the official poudriere bulk to start with an option
> like -B 210511060619-53863351e3fbec0d89e941ee9f0f288bd2461e87 too :)
Another, shorter option would be to truncate the hash to,
say, 12 characters (and I show all 4 digits of the year):
-B 20210511060619-53863351e3fb
Especially with content like 20210511060619 as context
in the name, 53863351e3fb is unlikely to not be
unique for built-commit identification.
However, the port builds identify two commits: one for
the port (p prefixed currently) and one for the system
(_s prefixed currently). So more like (using a real
build's hashes):
-B 20210511060619-p0ae18b07e470_sf5ff282bc0
Note that the text after the "-" is the same text now
used in the name.
The use of the date/time encoding as a prefix avoids
dealing with picking between the port and system
"rev-list --first-parent --count" figure or having to
list both in some order --and avoids the computational
effort to find those counts.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg builders order of jobs
Ronald Klop ronald-lists at klop.ws wrote on Sun May 9 10:22:38 UTC 2021 : > On the pkg builders the list of builds is ordered on git hash. > > http://beefy18.nyi.freebsd.org/jail.html?mastername=main-amd64-default > > (NB: ipv6 only) > > This ordering is totally random to me. With svn the list was naturally > ordered because of the incremental commit id. > > Is it possible to add the commit count to the job-name like > sys/conf/newvers.sh in base? > git_cnt=$($git_cmd rev-list --first-parent --count HEAD 2>/dev/null) Places like: https://artifact.ci.freebsd.org/snapshot/stable-13/ have the same sort of problem, partially because the dates(/times) shown at the displayed level need not match what the files will have for date/time (when the files even exist). An example from my past was: https://artifact.ci.freebsd.org/snapshot/stable-13/?C=M=D lists ac845558f7b626d9a31b8f6dab686c45d39dc5a0/ as having date/time 2021-Apr-10 18:43 . QUOTE https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/?C=M=D lists: powerpc/ and arm/ as having date/times 2021-Apr-10 18:54 and 2021-Apr-10 18:50 yet lists... i386/ and arm64/ as having date/times 2021-Feb-19 19:00 and 2021-Feb-19 18:50 . But it gets worse: https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/powerpc/?C=M=D shows an empty directory. Same for: https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/arm/?C=M=D By contrast, https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/i386/?C=M=D shows i386/ with date/time 2021-Apr-10 18:43 but https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/i386/i386/?C=M=D shows all the file dates as 2021-Feb-19 19:00 . . . . END QUOTE https://artifact.ci.freebsd.org/snapshot/*/ has already accumulated a huge number of hash-only based naming subdirectories and trying to do a "no-rebuild approximate bisect" via artifact builds has become much more painful/impractical. (It has never helped that architecture is in a deeper layer but is also partial: only some architectures might build for the commit in question. One has had to inspect to find examples of the architecture of interest.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gdal
On Mon, 3 May 2021 12:42:00 +0200
Matthieu Volat wrote:
> On Sun, 2 May 2021 13:55:45 -0400
> LuMiWa via freebsd-ports wrote:
>
> > Hi!
> >
> > I have a problem to build graphics/gdal on FreeBSD-13.0-RELEASE:
> > m::seekp' declared here: type mismatch at 1st parameter ('uint64_t'
> > (aka 'unsigned long') vs 'GInt64' (aka 'long long')) virtual void
> > seekp (uint64_t pos) = 0; ^
> > exrdataset.cpp:495:1: error: unknown type name 'Int64'; did you mean
> > 'GInt64'? Int64 GDALEXRIOStream::tellg ()
> > ^
> > GInt64
> > /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26:
> > note: 'GInt64' declared here typedef GIntBig GInt64;
> > ^
> > exrdataset.cpp:497:24: error: unknown type name 'Int64'; did you
> > mean 'GInt64'? return static_cast(VSIFTellL(m_fp));
> >^
> >GInt64
> > /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26:
> > note: 'GInt64' declared here typedef GIntBig GInt64;
> > ^
> > exrdataset.cpp:500:30: error: unknown type name 'Int64'; did you
> > mean 'GInt64'? void GDALEXRIOStream::seekg (Int64 pos)
> > ^
> > GInt64
> > /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26:
> > note: 'GInt64' declared here typedef GIntBig GInt64;
> > ^
> > exrdataset.cpp:566:36: error: allocating an object of abstract class
> > type 'GDALEXRIOStream' poDS->m_pIStream.reset(new
> > GDALEXRIOStream(fp, osFilename)); ^
> > exrdataset.cpp:992:25: error: variable type 'GDALEXRIOStream' is an
> > abstract class GDALEXRIOStream ostream(fp, pszFilename);
> > ^
> > exrdataset.cpp:1984:32: error: allocating an object of abstract
> > class type 'GDALEXRIOStream' poDS->m_pOStream.reset(new
> > GDALEXRIOStream(fp, pszFilename)); ^
> > 3 warnings and 14 errors generated.
> > gmake[4]: *** [../../GDALmake.opt:646: ../o/exrdataset.o] Error 1
> > gmake[4]: Leaving directory
> > '/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts/exr' gmake[3]: ***
> > [GNUmakefile:15: exr-install-obj] Error 2 gmake[3]: Leaving
> > directory '/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts'
> > gmake[2]: *** [GNUmakefile:114: frmts-target] Error 2 gmake[2]:
> > Leaving directory '/usr/ports/graphics/gdal/work/gdal-3.2.2' ***
> > Error code 1
> >
> > Stop.
> > make[1]: stopped in /usr/ports/graphics/gdal
> > *** Error code 1
> >
> > Thank you.
> >
>
> Hi, this happens indeed when you build gdal *without* the EXR option
> when openexr is present at build time. I guess the off option is not
> passed correctly to the configure script?
>
> Cheers,
>
> -- Matthieu Volat
Thank you very much.
--
“Two things are infinite: the universe and human stupidity; and I'm not
sure about the universe.”
― Albert Einstein
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Xoscope nuisance console messages on Pi4 running -current
On 2021-May-3, at 08:23, bob prohaska wrote: > On Mon, May 03, 2021 at 01:00:03AM -0700, Mark Millard via freebsd-ports > wrote: > [detailed code tour omitted] > >> >> My guess would be xoscope used a signed 32-bit type >> that got a value with sign extension to 64 bits >> before the value started being treated as unsigned. >> If it had used an unsigned type instead, the padding >> would have been a zero fill instead (presuming that >> I've guessed right). >> > > So this was an artifact of compiling a 32 program on a 64 bit machine? I've no evidence that you were building the port for armv7 instead of aarch64. If you were, it would be good to report that. Otherwise, I expect the code produced was 64-bit (aarch64) and the rest is just how the program's source code is set up. > And, perhaps unnecessary use of signed versus unsigned integers? That is what I expect is going on in the xoscope source code. (I've not looked.) > This begs two more questions: It is harmless (seemingly not always), I doubt that it is a problem (other than the messages). As I wrote: QUOTE While I do not know the specifics for the command and command group encoding, the truncated value seems coherent with the code that is using it. END QUOTE > and would it go away if compiled and run on a 32 bit machine, say armv7? "long int" and "int" are both 32-bits on armv7 (unsigned or signed) so no extra 1-bits would be produced by sign extension. So I do not expect the messages would be generated when executed via armv7 code. As far as I can tell, the program likely works (ignoring the messages) for aarch64. The messages are from the FreeBSD you are using being a debug build with INVARIANTS enabled. A non-debug FreeBSD build would not report the messages. (It is possible to buildworld for armv7 and install it into a directory tree and use chroot into that directory tree to run armv7 code on the RPi4's. This should not produce the messages --and if it did then there would be FreeBSD code to change for that kind of context.) > Many thanks for the detailed explanation, but I'll admit not understanding > much more than the quoted part above 8-( === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Xoscope nuisance console messages on Pi4 running -current
On 2021-May-2, at 23:37, bob prohaska wrote:
> After a successful compile of audio/xoscope on a Pi4 running current a
> stream of messages appeared on the console and in the security log
> while xoscope was running:
>
>
> +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl c0045006
> +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl c0045005
> +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl c0045002
> +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl c0045006
> +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl c0045005
> +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl c0045002
>
> They seem to come at a fairly high rate and clutter the logfiles, but
> apart from that nuisance nothing else seemed visibly amiss.
>
> Are they of any significance?
The code from a mid 2021-Mar vintage of main [so: 14]
looks like:
/* ARGSUSED */
int
sys_ioctl(struct thread *td, struct ioctl_args *uap)
{
u_char smalldata[SYS_IOCTL_SMALL_SIZE] __aligned(SYS_IOCTL_SMALL_ALIGN);
uint32_t com;
int arg, error;
u_int size;
caddr_t data;
#ifdef INVARIANTS
if (uap->com > 0x) {
printf(
"WARNING pid %d (%s): ioctl sign-extension ioctl %lx\n",
td->td_proc->p_pid, td->td_name, uap->com);
}
#endif
com = (uint32_t)uap->com;
. . .
where sys/sys/sysproto.h shows:
struct ioctl_args {
char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)];
char com_l_[PADL_(u_long)]; u_long com; char com_r_[PADR_(u_long)];
char data_l_[PADL_(char *)]; char * data; char data_r_[PADR_(char *)];
};
So, uap->com is unsigned with 64 bits for aarch64 and the
0x is converted to match that for the > test (C
rules).
The assignment to uint32_t com would end up with a
truncated value recorded whenever the warning is
produced.
Thus a value like 0xc0045006ul ends up with
com == 0xc0045006u instead.
Then looking at the usage of com leads to sys/sys/ioccom.h :
. . .
/*
* Ioctl's have the command encoded in the lower word, and the size of
* any in or out parameters in the upper word. The high 3 bits of the
* upper word are used to encode the in/out status of the parameter.
*
* 31 29 28 16 158 7 0
* +---+
* | I/O | Parameter Length| Command Group | Command |
* +---+
*/
#define IOCPARM_SHIFT 13 /* number of bits for ioctl size */
#define IOCPARM_MASK((1 << IOCPARM_SHIFT) - 1) /* parameter length mask */
#define IOCPARM_LEN(x) (((x) >> 16) & IOCPARM_MASK)
#define IOCBASECMD(x) ((x) & ~(IOCPARM_MASK << 16))
#define IOCGROUP(x) (((x) >> 8) & 0xff)
#define IOCPARM_MAX (1 << IOCPARM_SHIFT) /* max size of ioctl */
#define IOC_VOID0x2000UL/* no parameters */
#define IOC_OUT 0x4000UL/* copy out parameters */
#define IOC_IN 0x8000UL/* copy in parameters */
#define IOC_INOUT (IOC_IN|IOC_OUT)/* copy parameters in and out */
#define IOC_DIRMASK (IOC_VOID|IOC_OUT|IOC_IN)/* mask for IN/OUT/VOID */
. . .
So, com == 0xc0045006u ends up with:
I/O matching:: IOC_IN | IOC_OUT
Command matching (byte): 0x06u
Command Group matching (byte): 0x50u
Parameter Length matching: 0x0004u
While I do not know the specifics for the command
and command group encoding, the truncated value
seems coherent with the code that is using it.
My guess would be xoscope used a signed 32-bit type
that got a value with sign extension to 64 bits
before the value started being treated as unsigned.
If it had used an unsigned type instead, the padding
would have been a zero fill instead (presuming that
I've guessed right).
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gdal
On Sun, 2 May 2021 20:14:12 +0200 Loïc Bartoletti wrote: > Hi, > > What's your options? How do you build it? > > Thanks. > > Loïc > I built with the default options. I am using portmaster and I try cd /usr/oprts/graphics/gdal and make but the same result -- “Two things are infinite: the universe and human stupidity; and I'm not sure about the universe.” ― Albert Einstein _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
gdal
Hi!
I have a problem to build graphics/gdal on FreeBSD-13.0-RELEASE:
m::seekp' declared here: type mismatch at 1st parameter ('uint64_t'
(aka 'unsigned long') vs 'GInt64' (aka 'long long')) virtual void
seekp (uint64_t pos) = 0; ^
exrdataset.cpp:495:1: error: unknown type name 'Int64'; did you mean
'GInt64'? Int64 GDALEXRIOStream::tellg ()
^
GInt64
/usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
'GInt64' declared here typedef GIntBig GInt64;
^
exrdataset.cpp:497:24: error: unknown type name 'Int64'; did you mean
'GInt64'? return static_cast(VSIFTellL(m_fp));
^
GInt64
/usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
'GInt64' declared here typedef GIntBig GInt64;
^
exrdataset.cpp:500:30: error: unknown type name 'Int64'; did you mean
'GInt64'? void GDALEXRIOStream::seekg (Int64 pos)
^
GInt64
/usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
'GInt64' declared here typedef GIntBig GInt64;
^
exrdataset.cpp:566:36: error: allocating an object of abstract class
type 'GDALEXRIOStream' poDS->m_pIStream.reset(new GDALEXRIOStream(fp,
osFilename)); ^
exrdataset.cpp:992:25: error: variable type 'GDALEXRIOStream' is an
abstract class GDALEXRIOStream ostream(fp, pszFilename);
^
exrdataset.cpp:1984:32: error: allocating an object of abstract class
type 'GDALEXRIOStream' poDS->m_pOStream.reset(new GDALEXRIOStream(fp,
pszFilename)); ^
3 warnings and 14 errors generated.
gmake[4]: *** [../../GDALmake.opt:646: ../o/exrdataset.o] Error 1
gmake[4]: Leaving directory
'/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts/exr' gmake[3]: ***
[GNUmakefile:15: exr-install-obj] Error 2 gmake[3]: Leaving directory
'/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts' gmake[2]: ***
[GNUmakefile:114: frmts-target] Error 2 gmake[2]: Leaving directory
'/usr/ports/graphics/gdal/work/gdal-3.2.2' *** Error code 1
Stop.
make[1]: stopped in /usr/ports/graphics/gdal
*** Error code 1
Thank you.
--
“Two things are infinite: the universe and human stupidity; and I'm not
sure about the universe.”
― Albert Einstein
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: virtualbox-ose-6.1.20 outdated
On 01/05/21 01:17, Dutchman01 via freebsd-emulation wrote: bugfix release 6.1.22 is released! There is need to upgrade from 6.1.20 to 6.1.22 This is known, automatic notifications already reached the mailing list yesterday at 8:55 UTC The notification actually contained an error and I already reacted to that by adding the PORTSCOUT variable to the legacy ports. I'm testing the new release and should be able to commit the update to the tree later. It looks like a n easy update, but testing this ports requires time. Time to compile it (and it's heavy dependencies) on multiple OS version, time to run it to verify there are no big regressions. This time the update looks easy with no need to modify patches or add new ones, but this looks like an exception not the rule. When someone (like me this time) is able to start working on the update right away it's anyway impossible to get it in the tree in less than 24/48 hours in the best scenarios. Much more it the update proves difficult due to incompatibilities or need to modify patches. It could also happen for committers to be all busy or unavailable so a week or two could also happen. Anyway, as stated, I should be able to commit the update today. -- Guido Falsi ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD Port: virtualbox-ose-6.1.20 outdated
bugfix release 6.1.22 is released! There is need to upgrade from 6.1.20 to 6.1.22 Regards, Dutchman ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: More www/chromium build woes
Hi, "bob prohaska" f...@www.zefox.net – 29. April 2021 17:11 > Attempts to compile chromium-90.0.4430.85 are stopping with > > ===> Configuring for chromium-90.0.4430.85 > cd /usr/ports/www/chromium/work/chromium-90.0.4430.85 && /usr/bin/env > ac_cv_path_PERL=/usr/local/bin/perl ac_cv_path_PERL_PATH=/usr/local/bin/perl > PERL_USE_UNSAFE_INC=1 PKG_CONFIG=pkgconf PYTHON="/usr/local/bin/python2.7" > XDG_DATA_HOME=/usr/ports/www/chromium/work > XDG_CONFIG_HOME=/usr/ports/www/chromium/work > HOME=/usr/ports/www/chromium/work > PATH=/usr/ports/www/chromium/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin > SHELL=/bin/sh CONFIG_SHELL=/bin/sh CMAKE_PREFIX_PATH="/usr/local" > LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 /usr/local/bin/python2.7 > ./build/linux/unbundle/replace_gn_files.py --system-libraries ffmpeg flac > fontconfig freetype harfbuzz-ng libdrm libpng libwebp libxml libxslt openh264 > opus snappy || false > cp -f /usr/local/lib/python3.8/site-packages/xcbgen/*.py > /usr/ports/www/chromium/work/site-packages/xcbgen > *** Error code 1 > > It looked like lang/python38 wasn't installed, so I compiled it manually. > That didn't seem to make a difference. > > Any ideas what I'm doing wrong? I see the PATH reference to python2.7, is > that the culprit? Both 2.7 and 3.8 are installed. The chromium port copies the xcbgen package (from xcb-proto) to its working directory, because we need it for python 2.7. The copy assumes the default python version as source, which is 3.8 as of now - probably the xcb package is still installed for 3.7 though (see line 268 in the Makefile). Rebuilding/installing xcb-proto should do the trick. Cheers, Matthias _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: When will git be supported for ports?
On 2021-Apr-28, at 22:26, Kurt Jaeger wrote: > >>> https://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html >> >> The https://github.com/bsdimp/freebsd-git-docs/ material >> for git-why.md is still available via: >> >> https://github.com/bsdimp/freebsd-git-docs/commits/483527525db5cd7cf27141a2ca21059d9a3b158e/git-why.md >> >> It had commits on 2020-Oct-20, 2020-Dec-02, and 2020-Dec-03. So >> it was updated a little from the 2020-Sep blog variant. The >> changes may not be important. I've not gone through them. > > Thanks -- how did you find the commit hash / link and the dates ? In a web browser I did the sequence: Go to: https://github.com/bsdimp/freebsd-git-docs/ Click on "186 commits" Click on the "<>" to the right of "72f477a" (that skips past the 3ebc4f7 commit titled "git-why is obsolete") Click on "git-why.md" Note: at this point the most recent git-why.md document version should be displayed. Click on "History" Note: at this point the history of the commits to the document should be displayed, dates shown. The hashes/links that I supplied were there to copy in the web browser during this sequence, so that I what I did to supply them. > > It's the old saying: Give a man a fish, so he will not be hungry > for a day, teach him to fish and he will be fed for a livetime 8-} I hope that the above proves of future use. But a lifetime of complete meals? I doubt it . . . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: When will git be supported for ports?
Kurt Jaeger pi at freebsd.org wrote on Wed Apr 28 19:30:32 UTC 2021 : > > > > The 'why' was explained here: > > > > > > > > https://github.com/bsdimp/freebsd-git-docs/ > > Ah, here's the link to the 'why' post: > > https://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html The https://github.com/bsdimp/freebsd-git-docs/ material for git-why.md is still available via: https://github.com/bsdimp/freebsd-git-docs/commits/483527525db5cd7cf27141a2ca21059d9a3b158e/git-why.md It had commits on 2020-Oct-20, 2020-Dec-02, and 2020-Dec-03. So it was updated a little from the 2020-Sep blog variant. The changes may not be important. I've not gone through them. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: python 3.8 default
On Tue, 27 Apr 2021 17:42:19 +0900
Minoru TANABE wrote:
> This maybe /usr/local/bin/g-ir-scannner is python script file, and
> depend on python3.7.
> Please check the first line of /usr/local/bin/g-ir-scannner is
> #!/usr/local/bin/python3.8
> or
> #!/usr/local/bin/python3.7
>
>
> 2021年4月27日(火) 17:18 LuMiWa via freebsd-ports
> :
>
> > Hi!
> >
> > I have a problem to update Python on FreeBSD 13.0 RELEASE follow
> > the rules for portmaster in /usr/ports/UPDATING. It stopped wit
> > py-gobject3:
> >
> > self.evaluate_codeblock(codeblock)
> > File
> > "/usr/local/lib/python3.8/site-packages/mesonbuild/interpreterbase.py",
> > line 666, in evaluate_codeblock raise e File
> > "/usr/local/lib/python3.8/site-packages/mesonbuild/interpreterbase.py",
> > line 659, in evaluate_codeblock self.evaluate_statement(cur)
> > File
> > "/usr/local/lib/python3.8/site-packages/mesonbuild/interpreterbase.py",
> > line 676, in evaluate_statement return self.method_call(cur) File
> > "/usr/local/lib/python3.8/site-packages/mesonbuild/interpreterbase.py",
> > line 1073, in method_call return obj.method_call(method_name, args,
> > kwargs) File
> > "/usr/local/lib/python3.8/site-packages/mesonbuild/interpreter.py",
> > line 1843, in method_call value = fn(state, args, kwargs) File
> > "/usr/local/lib/python3.8/site-packages/mesonbuild/interpreterbase.py",
> > line 515, in wrapped return f(*wrapped_args, **wrapped_kwargs) File
> > "/usr/local/lib/python3.8/site-packages/mesonbuild/interpreterbase.py",
> > line 515, in wrapped return f(*wrapped_args, **wrapped_kwargs) File
> > "/usr/local/lib/python3.8/site-packages/mesonbuild/interpreterbase.py",
> > line 229, in wrapped return f(*wrapped_args, **wrapped_kwargs) File
> > "/usr/local/lib/python3.8/site-packages/mesonbuild/modules/gnome.py",
> > line 831, in generate_gir self._get_dependencies_flags(deps, state,
> > depends, use_gir_args=True) File
> > "/usr/local/lib/python3.8/site-packages/mesonbuild/modules/gnome.py",
> > line 449, in _get_dependencies_flags if use_gir_args and
> > self._gir_has_option('--extra-library'): File
> > "/usr/local/lib/python3.8/site-packages/mesonbuild/modules/gnome.py",
> > line 498, in _gir_has_option p, o, e = Popen_safe(exe.get_command()
> > + ['--help'], stderr=subprocess.STDOUT) File
> >
> > "/usr/local/lib/python3.8/site-packages/mesonbuild/mesonlib/universal.py",
> > line 1320, in Popen_safe p = subprocess.Popen(args,
> > universal_newlines=True, close_fds=False, File
> > "/usr/local/lib/python3.8/subprocess.py", line 858, in __init__
> > self._execute_child(args, executable, preexec_fn, close_fds,
> > File "/usr/local/lib/python3.8/subprocess.py", line 1704, in
> > _execute_child raise child_exception_type(errno_num, err_msg,
> > err_filename) FileNotFoundError: [Errno 2] No such file or
> > directory: '/usr/local/bin/g-ir-scanner' ===> Script
> > "configure" failed unexpectedly. Please report the problem to
> > desk...@freebsd.org [maintainer] and attach the
> >
> > "/usr/ports/devel/py-gobject3/work-py38/pygobject-3.38.0/_build/meson-logs/meson-log.txt"
> > including the output of the failure of your make command. Also,
> > it might be a good idea to provide an overview of all packages
> > installed on your system (e.g. a /usr/local/sbin/pkg-static
> > info -g -Ea). *** Error code 1
> >
> > Stop.
> > make: stopped in /usr/ports/devel/py-gobject3
> >
> > ===>>> make build failed for devel/py-gobject3
> > ===>>> Aborting update
> >
> >
> > ===>>> You can restart from the point of failure with this command
> > line: portmaster devel/py-gobject3 devel/pygobject3-common
> >
> >
> > --
> > “We live in a world where there is more and more information, and
> > less and less meaning.”
> >
> > Jean Baudrillard
> > ___
> > freebsd-ports@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> > To unsubscribe, send any mail to
> > "freebsd-ports-unsubscr...@freebsd.org"
> >
>
>
Thank you very much. It works.
--
“We live in a world where there is more and more information, and less
and less meaning.”
Jean Baudrillard
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Some delayed ports
Spamassassin is up to 3.4.6 Gcc is up to 11.1 Exim there WAS A SECURITY FLAW CAUGHT. aRE WE KEEPING UP? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b Welcome weeds into the garden, and soon that's all which will grow. -unknown ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
python 3.8 default
ility=hidden Code: extern int i; int i; Compiler stdout: Compiler stderr: Compiler for C supports arguments -fvisibility=hidden: YES Configuring config.h using configuration Configuring pygobject-3.0.pc using configuration Configuring PyGObject-3.38.0.egg-info using configuration Using cached compile: Cached command line: Code: extern int i; int i; Cached compiler stdout: Cached compiler stderr: Compiler for C supports arguments -fvisibility=hidden: YES (cached) PKG_CONFIG_PATH: Called `/usr/local/bin/pkgconf --variable=gidatadir gobject-introspection-1.0` -> 0 /usr/local/share/gobject-introspection-1.0 Got pkgconfig variable gidatadir : /usr/local/share/gobject-introspection-1.0 Pkg-config binary for MachineChoice.BUILD is not cached. Pkg-config binary for 0 specified from cross file, native file, or env var as ['pkgconf'] Found pkg-config: /usr/local/bin/pkgconf (1.7.4) Determining dependency 'gobject-introspection-1.0' with pkg-config executable '/usr/local/bin/pkgconf' PKG_CONFIG_PATH: Called `/usr/local/bin/pkgconf --modversion gobject-introspection-1.0` -> 0 1.66.1 PKG_CONFIG_PATH: Called `/usr/local/bin/pkgconf --cflags gobject-introspection-1.0` -> 0 -I/usr/local/include/gobject-introspection-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include PKG_CONFIG_PATH: Called `/usr/local/bin/pkgconf --libs gobject-introspection-1.0` -> 0 -L/usr/local/lib -lgirepository-1.0 -lgobject-2.0 -lglib-2.0 -lintl PKG_CONFIG_PATH: Called `/usr/local/bin/pkgconf --libs gobject-introspection-1.0` -> 0 -L/usr/local/lib -lgirepository-1.0 -lgobject-2.0 -lglib-2.0 -lintl Build-time dependency gobject-introspection-1.0 found: YES 1.66.1 Dependency gobject-introspection-1.0 found: YES 1.66.1 (cached) PKG_CONFIG_PATH: Called `/usr/local/bin/pkgconf --variable=g_ir_scanner gobject-introspection-1.0` -> 0 /usr/local/bin/g-ir-scanner Got pkgconfig variable g_ir_scanner : /usr/local/bin/g-ir-scanner Program g-ir-scanner found: YES (/usr/local/bin/g-ir-scanner) Dependency gobject-introspection-1.0 found: YES 1.66.1 (cached) PKG_CONFIG_PATH: Called `/usr/local/bin/pkgconf --variable=g_ir_compiler gobject-introspection-1.0` -> 0 /usr/local/bin/g-ir-compiler Got pkgconfig variable g_ir_compiler : /usr/local/bin/g-ir-compiler Program g-ir-compiler found: YES (/usr/local/bin/g-ir-compiler) PKG_CONFIG_PATH: Called `/usr/local/bin/pkgconf --variable=girdir glib-2.0` -> 0 PKG_CONFIG_PATH: Called `/usr/local/bin/pkgconf --print-variables glib-2.0` -> 0 glib_mkenums gobject_query glib_genmarshal bindir includedir libdir prefix pcfiledir Got pkgconfig variable girdir : PKG_CONFIG_PATH: Called `/usr/local/bin/pkgconf --variable=girdir gobject-2.0` -> 0 PKG_CONFIG_PATH: Called `/usr/local/bin/pkgconf --print-variables gobject-2.0` -> 0 includedir libdir prefix pcfiledir Got pkgconfig variable girdir : PKG_CONFIG_PATH: Called `/usr/local/bin/pkgconf --variable=girdir gio-2.0` -> 0 PKG_CONFIG_PATH: Called `/usr/local/bin/pkgconf --print-variables gio-2.0` -> 0 gsettings gresource gdbus_codegen gdbus glib_compile_resources glib_compile_schemas gio_querymodules gio giomoduledir bindir schemasdir datadir includedir libdir prefix pcfiledir Got pkgconfig variable girdir : PKG_CONFIG_PATH: Called `/usr/local/bin/pkgconf --variable=girdir gmodule-2.0` -> 0 PKG_CONFIG_PATH: Called `/usr/local/bin/pkgconf --print-variables gmodule-2.0` -> 0 gmodule_supported includedir libdir prefix pcfiledir Got pkgconfig variable girdir : PKG_CONFIG_PATH: PKG_CONFIG_PATH: Got pkgconfig variable girdir : PKG_CONFIG_PATH: PKG_CONFIG_PATH: Got pkgconfig variable girdir : PKG_CONFIG_PATH: PKG_CONFIG_PATH: Got pkgconfig variable girdir : PKG_CONFIG_PATH: PKG_CONFIG_PATH: Got pkgconfig variable girdir : PKG_CONFIG_PATH: Called `/usr/local/bin/pkgconf --variable=girdir gobject-introspection-1.0` -> 0 /usr/local/share/gir-1.0 Got pkgconfig variable girdir : /usr/local/share/gir-1.0 PKG_CONFIG_PATH: PKG_CONFIG_PATH: Got pkgconfig variable girdir : PKG_CONFIG_PATH: PKG_CONFIG_PATH: Got pkgconfig variable girdir : PKG_CONFIG_PATH: PKG_CONFIG_PATH: Got pkgconfig variable girdir : PKG_CONFIG_PATH: PKG_CONFIG_PATH: Got pkgconfig variable girdir : PKG_CONFIG_PATH: PKG_CONFIG_PATH: Got pkgconfig variable girdir : PKG_CONFIG_PATH: PKG_CONFIG_PATH: Got pkgconfig variable girdir : PKG_CONFIG_PATH: PKG_CONFIG_PATH: Got pkgconfig variable girdir : PKG_CONFIG_PATH: PKG_CONFIG_PATH: Got pkgconfig variable girdir : PKG_CONFIG_PATH: Got pkgconfig variable girdir : /usr/local/share/gir-1.0 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: freebsd-ports Digest, Vol 933, Issue 7
On 18-4-2021 16:51, Adriaan de Groot wrote: On Sunday, 18 April 2021 14:00:01 CEST freebsd-ports-requ...@freebsd.org wrote: So perhaps that is the best way to avoid having to deal with ABI/API breakage... After that it is up to the maintainers of the dependant packages to update their package and start using boost-1.75. There is the implicit assumption that a patch that updates boost for all the dependent ports should also provide fixes if those ports fail to build after the update. That is the major task. There are "only" 490 ports that have boost in their Makefile. Compare this to CMake, which has about 1900 direct consumers. While there's less ABI-breakage and more configure- and build-time breakage, a CMake update looks like this: - build all the consumers with the current version of CMake - fix the ones that don't build, or mark BROKEN - bump CMake locally - build everything again - fix the ones that don't build The actual CMake parts are the easy bits. Dealing with 15-year old C++ code that happens to use CMake and falls over for totally unrelated reasons is the real time sink. Ceph, too, is one of those things that eventually gets added to my ignore list as "doesn't build in any recent ports checkout": /usr/local/bin/ld: ../../../lib/libkv.a(LevelDBStore.cc.o): (.data.rel.ro._ZTI17CephLevelDBLogger[_ZTI17CephLevelDBLogger]+0x10): undefined reference to `typeinfo for leveldb::Logger' I fix what I can, send mail to maintainers when I can't and so we hope that progress happens Hi Adriaan, I understand your pain. I'm in the squeeze that Ceph has moved to new version, which I do get to build/test in my jenkins builders. But I'm/was sort of waiting for the move to git with ports. And then figure out how to get things to work again with the latest release. Unfortunately I got little time at the moment, so progress there is slow. And you are right that it hard to find the cause for this, since so many things have changed: Ceph source, Cmake config, llvm compiler and linker and leveldb. So the permutations are plenty. If you want to fix the above (which I also got in my builders, and have not found the root cause for) you could add `-D WITH_LEVELDB=OFF` to the CMAKE options. Hopefully I get around to submitting a patch to get ceph14 to v14.2.20 real soon now. --WjW _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: wxgtk31: wayland dependency
> > Hmm, seems so, but I don't have xorg-minimal installed > > $ pkg info xorg-\* > xorg-fonts-truetype-7.7_1 > xorg-server-1.20.11,1 > Ah I see, you have a lighter install of Xorg than me. OK I have been looking around at what is really pulling Wayland in and it seems that Gtk itself does too (at least by default) :/ https://svnweb.freebsd.org/ports/head/x11-toolkits/gtk30/ https://www.freebsd.org/cgi/ports.cgi?query=^gtk3-3.24.27 ___________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: wxgtk31: wayland dependency
> Starting from version 3.1.5 wxgtk31 got a hard dependency on wayland. > Could that depndency be made optional? I don't use wayland and don't want to > have it installed. > Doesn't xorg-minimal already bring in Wayland? https://svnweb.freebsd.org/ports/head/x11/xorg-minimal https://www.freebsd.org/cgi/ports.cgi?query=xorg-minimal _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[exim-us...@exim.org: [exim] Exim security release ahead]
Heads up for exim porters.
- Forwarded message from Heiko Schlittermann via Exim-users
-
Date: Wed, 21 Apr 2021 14:36:32 +0200
From: Heiko Schlittermann via Exim-users
To: exim-users , "exim-maintain...@exim.org"
, exim-annou...@exim.org
Subject: [exim] Exim security release ahead
User-Agent: Mutt/1.10.1 (2018-07-13)
Dear Exim-Users and maintainers,
this is a *heads up* notice only. No action is required on your part
right now.
Abstract
Several exploitable vulnerabilities in Exim were reported to us and are
fixed.
We have prepared a security release, tagged as "exim-4.94.1".
This release contains all changes on the exim-4.94+fixes branch plus
security fixes.
Schedule
2021-04-27 13.30 UTC: Grant access to the security repos
for distro maintainers
2021-05-04 13:30 UTC: Publish the release on the public
repos/website/etc
Repositories
The sources *will* be available on our security repo:
tarballs: g...@git.exim.org:exim-packages-security.git
source: g...@git.exim.org:exim-security.git
tag: exim-4.94.1
Access to these security Git repos will be granted for the known set of
Exim maintainers and distro packagers first. Please reach out to us, if
you need further details or if you think, you should be part of this
set.
One week after granting access to the distro packagers the release will
be pushed to the well known public repos as usual.
Details
---
The current Exim versions (and likely older versions too) suffer from
several exploitable vulnerabilities. These vulnerabilities were reported
by Qualys via secur...@exim.org back in October 2020.
Due to several internal reasons it took more time than usual for the Exim
development team to work on these reported issues in a timely manner.
We explicitly thank Qualys for reporting *and* for providing patches for
most of the reported vulnerabilities.
Thank you for using Exim.
Best regards from Dresden/Germany
Viele Gre aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --- key ID: F69376CE -
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
- End forwarded message -
--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
When one lacks enemies, one can always make them. -unknown
_______
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: SVNWEB not updated for ports
George Mitchell george+freebsd at m5p.com wrote on Mon Apr 19 14:51:54 UTC 2021 : > For me, https://cgit.freebsd.org/ports/tree/ > is more helpful, though I still haven't figured out where to find the > *date* of any commit ... Two ways starting from a tree view: A) On the same line as the file/directory of interest, click on log and the commit sequence for file/directory will be shown, with dates listed. B) On the same line as the file of interest (not directory), click on blame first then on the page that is displayed hover the mouse over a commit-id for a range of lines and it will show the author, committer, dates, and the one-line summary for the commit identified. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Ports looking for adoption: brlaser numix-gtk-theme numix-icon-theme
Hi, I'm the maintainer for the following ports: brlaser numix-gtk-theme numix-icon-theme As I'm no longer interested in FreeBSD, these ports are available for adoption. They require very little maintenance work. Regards Vincent ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Firefox error
On Mon, Apr 19, 2021 at 09:24:31AM +0300, Gleb Popov wrote:
> On Mon, Apr 19, 2021 at 8:52 AM The Doctor via freebsd-ports <
> freebsd-ports@freebsd.org> wrote:
>
> > Why am I getting:
> >
> > In file included from Unified_cpp_libsoundtouch_src0.cpp:47:
> > /usr/ports/www/firefox/work/firefox-88.0/media/libsoundtouch/src/InterpolateShannon.cpp:71:9:
> > warning: 'PI' macro redefined [-Wmacro-redefined]
> > #define PI 3.1415926536
> > ^
> > /usr/ports/www/firefox/work/firefox-88.0/media/libsoundtouch/src/AAFilter.cpp:45:9:
> > note: previous definition is here
> > #define PI M_PI
> > ^
> > In file included from Unified_cpp_image_decoders0.cpp:11:
> > /usr/ports/www/firefox/work/firefox-88.0/image/decoders/nsAVIFDecoder.cpp:656:60:
> > error: use of undeclared identifier 'AOM_PLANE_ALPHA'
> > MOZ_ASSERT(aImage->stride[AOM_PLANE_Y] ==
> > aImage->stride[AOM_PLANE_ALPHA]);
> > ^
> > /usr/ports/www/firefox/work/firefox-88.0/image/decoders/nsAVIFDecoder.cpp:656:60:
> > error: use of undeclared identifier 'AOM_PLANE_ALPHA'
> > In file included from Unified_cpp_libsoundtouch_src0.cpp:92:
> > /usr/ports/www/firefox/work/firefox-88.0/media/libsoundtouch/src/cpu_detect_x86.cpp:48:12:
> > warning: 'bit_MMX' macro redefined [-Wmacro-redefined]
> > #define bit_MMX (1 << 23)
> >^
> > /usr/local/llvm11/lib/clang/11.0.1/include/cpuid.h:130:9: note: previous
> > definition is here
> > #define bit_MMX 0x0080
> >^
> > In file included from Unified_cpp_libsoundtouch_src0.cpp:92:
> > /usr/ports/www/firefox/work/firefox-88.0/media/libsoundtouch/src/cpu_detect_x86.cpp:49:12:
> > warning: 'bit_SSE' macro redefined [-Wmacro-redefined]
> > #define bit_SSE (1 << 25)
> > ^
> > /usr/local/llvm11/lib/clang/11.0.1/include/cpuid.h:133:9: note: previous
> > definition is here
> > #define bit_SSE 0x0200
> > ^
> > In file included from Unified_cpp_libsoundtouch_src0.cpp:92:
> > /usr/ports/www/firefox/work/firefox-88.0/media/libsoundtouch/src/cpu_detect_x86.cpp:50:12:
> > warning: 'bit_SSE2' macro redefined [-Wmacro-redefined]
> > #define bit_SSE2(1 << 26)
> > ^
> > /usr/local/llvm11/lib/clang/11.0.1/include/cpuid.h:134:9: note: previous
> > definition is here
> > #define bit_SSE20x0400
> > ^
> > 4 warnings generated.
> >
>
> Are you building the port on a live system? Try upgrading multimedia/aom
> first.
No Dice!
In file included from Unified_cpp_image_decoders0.cpp:11:
/usr/ports/www/firefox/work/firefox-88.0/image/decoders/nsAVIFDecoder.cpp:656:60:
error: use of undeclared identifier 'AOM_PLANE_ALPHA'
MOZ_ASSERT(aImage->stride[AOM_PLANE_Y] == aImage->stride[AOM_PLANE_ALPHA]);
^
/usr/ports/www/firefox/work/firefox-88.0/image/decoders/nsAVIFDecoder.cpp:656:60:
error: use of undeclared identifier 'AOM_PLANE_ALPHA'
gmake[5]: Leaving
directory '/usr/ports/www/firefox/work/.build/image/encoders/jpeg'
gmake[5]: Entering
directory '/usr/ports/www/firefox/work/.build/image/encoders/png'
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
When one lacks enemies, one can always make them. -unknown
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Firefox error
Why am I getting: In file included from Unified_cpp_libsoundtouch_src0.cpp:47: /usr/ports/www/firefox/work/firefox-88.0/media/libsoundtouch/src/InterpolateShannon.cpp:71:9: warning: 'PI' macro redefined [-Wmacro-redefined] #define PI 3.1415926536 ^ /usr/ports/www/firefox/work/firefox-88.0/media/libsoundtouch/src/AAFilter.cpp:45:9: note: previous definition is here #define PI M_PI ^ In file included from Unified_cpp_image_decoders0.cpp:11: /usr/ports/www/firefox/work/firefox-88.0/image/decoders/nsAVIFDecoder.cpp:656:60: error: use of undeclared identifier 'AOM_PLANE_ALPHA' MOZ_ASSERT(aImage->stride[AOM_PLANE_Y] == aImage->stride[AOM_PLANE_ALPHA]); ^ /usr/ports/www/firefox/work/firefox-88.0/image/decoders/nsAVIFDecoder.cpp:656:60: error: use of undeclared identifier 'AOM_PLANE_ALPHA' In file included from Unified_cpp_libsoundtouch_src0.cpp:92: /usr/ports/www/firefox/work/firefox-88.0/media/libsoundtouch/src/cpu_detect_x86.cpp:48:12: warning: 'bit_MMX' macro redefined [-Wmacro-redefined] #define bit_MMX (1 << 23) ^ /usr/local/llvm11/lib/clang/11.0.1/include/cpuid.h:130:9: note: previous definition is here #define bit_MMX 0x0080 ^ In file included from Unified_cpp_libsoundtouch_src0.cpp:92: /usr/ports/www/firefox/work/firefox-88.0/media/libsoundtouch/src/cpu_detect_x86.cpp:49:12: warning: 'bit_SSE' macro redefined [-Wmacro-redefined] #define bit_SSE (1 << 25) ^ /usr/local/llvm11/lib/clang/11.0.1/include/cpuid.h:133:9: note: previous definition is here #define bit_SSE 0x0200 ^ In file included from Unified_cpp_libsoundtouch_src0.cpp:92: /usr/ports/www/firefox/work/firefox-88.0/media/libsoundtouch/src/cpu_detect_x86.cpp:50:12: warning: 'bit_SSE2' macro redefined [-Wmacro-redefined] #define bit_SSE2(1 << 26) ^ /usr/local/llvm11/lib/clang/11.0.1/include/cpuid.h:134:9: note: previous definition is here #define bit_SSE20x0400 ^ 4 warnings generated. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b When one lacks enemies, one can always make them. -unknown _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Boost versions
On 17-4-2021 13:09, Li-Wen Hsu wrote: On Sat, Apr 17, 2021 at 6:58 PM Kurt Jaeger wrote: Hi! Ceph has moved to Boost 1.75, so now it is build with the project. Which is of course a pity. Are there any plans to also get Boost 1.75 in ports? There is this one PR which touches the topic: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246106 It looks like a major undertaking! Why is that? If I look at what is in phabricator, the largest part is diffs on the plist? I don't think office@ currently has enough manpower to maintain boost ports. I suggest we need to seek a new maintainer or form a group to maintain it. I am also interested in updating boost, but I don't think I can maintain it solely. I can help on porting, allocating resource to test, but I don't think I can fix all the issues during upgrading and exp-run myself alone. I hope the maintenance of the complex ports like this can be a team work. Is anyone interested in joining the effort? I am importing boost 1.75 raw into Ceph, and build it there. That seems to work for what ceph needs. There used to be several versions of Boost in parallel. So perhaps that is the best way to avoid having to deal with ABI/API breakage... After that it is up to the maintainers of the dependant packages to update their package and start using boost-1.75. The report in bugzilla suggests that that is all what other maintainers ask. Or am I too simple in thinking this? --WjW ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Boost versions
On 17-4-2021 14:16, Kurt Jaeger wrote: Getting the port to build is one thing. Right that is probably not very complicated. But the API/ABI changes are indeed a pain. Reason for all kinds of trouble with Ceph as well. There used to be several versions of Boost in parallel. Yes. I have no idea how easy that would be. Neither do I, it is just a vague recollection. But there must be more libraries with that same challenge? The bigger part is, as you described: So perhaps that is the best way to avoid having to deal with ABI/API breakage... After that it is up to the maintainers of the dependant packages to update their package and start using boost-1.75. There is the implicit assumption that a patch that updates boost for all the dependent ports should also provide fixes if those ports fail to build after the update. That is the major task. There are "only" 490 ports that have boost in their Makefile. Or am I too simple in thinking this? No. The normal way would be to provide the patch, testbuild all the depends, list the broken ports in the PR and then a small group of folks can try to fix them one by one. I have no experience in that. Keeping up with Ceph is already quite a task, since that is a very fast moving task. --WjW _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Boost versions
On 17-4-2021 13:09, Li-Wen Hsu wrote: On Sat, Apr 17, 2021 at 6:58 PM Kurt Jaeger wrote: Hi! Ceph has moved to Boost 1.75, so now it is build with the project. Which is of course a pity. Are there any plans to also get Boost 1.75 in ports? There is this one PR which touches the topic: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246106 It looks like a major undertaking! Why is that? If I look at what is in phabricator, the largest part is diffs on the plist? I don't think office@ currently has enough manpower to maintain boost ports. I suggest we need to seek a new maintainer or form a group to maintain it. I am also interested in updating boost, but I don't think I can maintain it solely. I can help on porting, allocating resource to test, but I don't think I can fix all the issues during upgrading and exp-run myself alone. I hope the maintenance of the complex ports like this can be a team work. Is anyone interested in joining the effort? I am importing boost 1.75 raw into Ceph, and build it there. That seems to work for what ceph needs. There used to be several versions of Boost in parallel. So perhaps that is the best way to avoid having to deal with ABI/API breakage... After that it is up to the maintainers of the dependant packages to update their package and start using boost-1.75. The report in bugzilla suggests that that is all what other maintainers ask. Or am I too simple in thinking this? --WjW ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Boost versions
Hi, Ceph has moved to Boost 1.75, so now it is build with the project. Which is of course a pity. Are there any plans to also get Boost 1.75 in ports? --WjW ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: openhab2-2.5.11 - openhab3?
Hi Frank, Alexander, thanks for your feedback. Meanwhile I had created a port of my own, which was quite easy with the openhab2 port as template. One remark to your version: I have noticed that the openHAB folks have changed their naming scheme and have omitted the major version number from the package name, so the name of the openHAB 3 package on Linux is just ‚openhab‘ as opposed to ‚openhab3‘. I think that should also be reflected in the FreeBSD port. Kind regards, Thomas. > Am 15.04.2021 um 20:03 schrieb Frank Preußer : > > Hello everybody > > openhab3 runs in a TrueNAS jail for me. I once attached the necessary files > to you, these must then be added to the /usr/ports/misc/ directory > then simply enter the command "make install clean" in the two directories. > And take the same options after the openhab2 install > > Bye Frank. > > Von: Alexander Leidinger <mailto:netch...@freebsd.org> > Gesendet: Sonntag, 11. April 2021 15:01 > An: Thomas Gude <mailto:thg...@googlemail.com> > Cc: po...@freebsd.org <mailto:po...@freebsd.org>; frank.preus...@hotmail.de > <mailto:frank.preus...@hotmail.de> > Betreff: Re: FreeBSD Port: openhab2-2.5.11 - openhab3? > > > Quoting Thomas Gude (from Fri, 9 Apr 2021 > 12:11:19 +0200): > > > Hi netchild, > > > > I am happily using the openhab2 port on my FreeBSD home server. The > > openHAB guys have released the new 3.0 version quite some time ago > > and I am wondering if you (or anyone else) have plans for (or are > > even already working on) a port for FreeBSD. Would be nice to get > > your feedback or thoughts on this. > > Frank Preusser (in CC) has send me an openhab 3 port. I didn't had the > possibility to have a look at this. The last thing I remember is that > there were some issues still left (IIRC some java error). I'm not sure > if it migrates the openhab2 config. With openhab2 there was an update > script to update from a previous version of openhab2. I had to ... > sort of replace ... it with something similar, no idea how openhab-3 > is doing this. I just remember that in the release notes it was > mentioned that they renamed from "openhab2" to "openhab". > > Bye, > Alexander. > -- > http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF > > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[net-im/openfire] CPU utilization
Before I open a bug I wanted to see if anyone else is having this problem and/or have any suggestions on how to resolve it. I am using Openfire version 4.6.2 (net-im/openfire). There are no functional issues but I've noticed that the process is always at 100% CPU utilization: openfire 99371 100.0 2.0 1820876 335772 - I 8Mar21 22183:09.67 | `-- /usr/local/openjdk8/bin/java -server -jar -Xmx256M -Dopenfire.lib.dir=/usr/local/share/java/openfire/lib -DopenfireHome=/usr/local/share/java/openfire /usr/local/share/java/openfire/lib/startup.jar Restarting the process fixes it temporarily but returns to it's previous levels after several hours (sometimes days). It's not specific to this machine. I was previously running it on a virtual FreeBSD machine (VMWare ESXi) and recently moved it to real hardware. The CPU utilization is the same. It's non-production used for myself. It's not a busy server with just 2-3 people on at most. Server to server federation is enabled with only an account from jabber.org added in my contact list. smime.p7s Description: S/MIME Cryptographic Signature
Re: Deprecation of portsnap (was: Proposed ports git transition schedule)
On 2021-Apr-11 14:27:27 +0200, Helge Oldach wrote: >Peter Jeremy via freebsd-ports wrote on Sun, 11 Apr 2021 00:52:11 +0200 (CEST): >> Following the SVN to GIT migration, portsnap is now the only practical >> way to use ports on a low-memory system. I've done some experiments >> and standard git has a 2GB working set to checkout a ports tree. > >However checking out is a one-time action with ports as there is only >one branch (switching frequently between main and quarterly is probably >not very sensible on a limited machine). git pull is significantly more >lightweight, I've just seen some 200M RSS. That should work well even on >a 512M machine. Probably much better than gitup in constrained memory? Except that git will arbitrarily and randomly decide that it needs to run "gc" - which is similarly extravagant in memory usage. Last time I found one running, it thrashed that poor VM for 3 days. Ignoring that, a "git up -ff" on a ports tree peaks with 2×1GB processes, though it looks like the working set size might only be ~350MB. -- Peter Jeremy signature.asc Description: PGP signature
gitup issues [was Re: No update for a day on ports?]
On 2021-Apr-01 22:36:02 +1100, Trev wrote: >> I just tried gitup and was told tha I had no permissions for >> /var/db/gitup. "sudo chown $USER /var/db/gitup" fixes that. >I just tried gitup and it was killed after apparently exhausting my >swap space. I had no such problem with portsnap :-( gitup walks the destination tree (ie /usr/ports), hashing every file it finds (by reading the complete file into memory). Whilst the default gitup configuration ignores /usr/ports/packages and /usr/ports/distfiles, it reads and hashes all the files down both paths before ignoring them. One consequence is that gitup is unusable on small memory environments - in my case, I saw peak memory usage hit 5GB (though the largest file I have is 1.8GB, so I'm not sure why it's eating so much memory). >My system (Vultr VPS) has 512K memory and 1.5G swap. git is barely usable on such a system (it's peak memory usage is about 2GB whilst processing a ports tree). gitup is unusable unless you either delete all packages and distfiles, or symlink them out of the way. > > Can I not run gitup as a normal user? > >I don't believe so. Well, git or gitup need write access to the working directory and the associated metadata directory. -- Peter Jeremy signature.asc Description: PGP signature
Re: Deprecation of portsnap (was: Proposed ports git transition schedule)
On 2021-Apr-01 12:19:08 +0200, Felix Palmen wrote: >* Christoph Moench-Tegeder [20210326 19:45]: >> ## Felix Palmen (fe...@palmen-it.de): >> >> > I'd assume (someone may correct me) that portsnap will still be >> > supported, >> >> https://lists.freebsd.org/pipermail/freebsd-ports/2020-August/119098.html > >Is this finally decided, and is there a timeline? Right now, it seems >portsnap is still built by default on releng/13.0. Following the SVN to GIT migration, portsnap is now the only practical way to use ports on a low-memory system. I've done some experiments and standard git has a 2GB working set to checkout a ports tree. gitup reached a 5GB working set size before I gave up. Typical small VPSs are around the 1GB RAM size and moving to something that can support 2GB or 5GB processes is a big price jump. -- Peter Jeremy signature.asc Description: PGP signature
Re: FreeCAD
On Sat, 10 Apr 2021 00:34:46 +0200 Christoph Moench-Tegeder wrote: > ## LuMiWa via freebsd-ports (freebsd-ports@freebsd.org): > > > portmaster -d cad/freecad > > That installs all the build dependencies (and the build dependencies > of the dependencies, etc.) in your system - and that includes the old > python 2.7 as a build dependency of qt5-webkit (which itself is > required by pyside2, which is required by FreeCAD). > If you want to avoid that and do not have special requirements > with regard to port options, I'd recommend eschewing local builds > and using packages (pkg install ...). > > Regards, > Christoph > Thank you. I think that we "talked" about qt-webkit long time before and will be nice that FreeCAD doesn't depend on it. -- “We live in a world where there is more and more information, and less and less meaning.” Jean Baudrillard ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: devel/llvm10 (and 11) on aarch64: only BE_AMDGPU registered targets despite OPTIONS_FILE_SET+=BE_NATIVE also being set
t; n245444 (--first-parent --count for merge-base) Using OPTIONS_FILE_SET+=BE_STANDARD instead of OPTIONS_FILE_SET+=BE_NATIVE did not have this problem. (I've not tried BE_FREEBSD so far.) Also, my Cortex-A7 (so: armv7) context did not have the "amdgcn/r600 only" problem with OPTIONS_FILE_SET+=BE_NATIVE : # /usr/local/llvm10/bin/llc -version LLVM (http://llvm.org/): LLVM version 10.0.1 Optimized build. Default target: armv7-portbld-freebsd14.0-gnueabihf Host CPU: (unknown) Registered Targets: amdgcn - AMD GCN GPUs arm - ARM armeb - ARM (big endian) r600- AMD GPUs HD2XXX-HD6XXX thumb - Thumb thumbeb - Thumb (big endian) # pkg info llvm10 llvm10-10.0.1_5 Name : llvm10 Version: 10.0.1_5 Installed on : Fri Feb 12 11:59:11 2021 PST Origin : devel/llvm10 Architecture : FreeBSD:14:armv7 Prefix : /usr/local Categories : devel lang Licenses : MIT, BSD3CLAUSE, PD, REGEX, LLVM2, LLVM Maintainer : bro...@freebsd.org WWW: http://llvm.org/ Comment: LLVM and Clang Options: BE_AMDGPU : on BE_FREEBSD : off BE_NATIVE : on BE_STANDARD: off CLANG : on DOCS : on EXTRAS : on LIT: on LLD: on LLDB : on LLD_LINK : on PYCLANG: off Shared Libs required: libedit.so.0 liblua-5.2.so libpython3.7m.so.1.0 libxml2.so.2 Shared Libs provided: libLTO.so.10 libRemarks.so.10 libLLVM-10.so libclang-cpp.so.10 liblldb.so.10 libclang.so.10 Annotations: FreeBSD_version: 144 repo_type : binary repository : custom Flat size : 511MiB Description: The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. This port includes Clang (a C/C++/Objective-C compiler), LLD (a linker), LLDB (a debugger), an OpenMP runtime library, and the LLVM infrastructure these are built on. WWW: http://llvm.org/ So somehow specific to Cortex-A57/Cortex-A72 or to aarch64 generally. (The MACCHIATObin Double Shot had the same build problem as the OverDrive 1000.) It might be appropriate to disable the BE_NATIVE option for aarch64 if it is going to silently not produce aarch64 support. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Specific svn/git package update use case
Simon Wright simon.wright at gmx.net wrote on
Fri Apr 9 10:12:04 UTC 2021 :
> Excellent Mark, thank you, then that is exactly what I need, the git
> equivilent of svn up -r xx ${portsdir}.
>
> And is there a need to do git-commit or git-merge to deal with the
> 'detached HEAD' message or can I just suppress this? Any local
> modifications live in an overlay for poudriere to use so there is
> nothing unique in my /usr/ports and I only track main, no other branches.
So far as I know, you could just ignore the messages about
detached HEAD for your intended style of use, if I
understand your usage correctly.
You may have other git use besides FreeBSD ports (now or
someday), so I'm cautious about claiming the specifics
below are fully appropriate, but you could do something
like:
git config --global advice.detachedHead false
to make detached HEADs status easier to ignore: no more
messages, or at least in fewer contexts. (I'm unsure if
it would disable git status reporting on the that
specific type of status information.)
As indicated already, you may want to periodically use
git status to cross-check on if something unexpected
happened in your use that should be cleaned up.
> On 09/04/2021 1:23 pm, Mark Millard via freebsd-ports wrote:
>> Simon Wright simon.wright at gmx.net wrote on
>> Fri Apr 9 02:48:47 UTC 2021 :
>>
>>> I'm still not clear though whether checking out this commit brings in
>>> all the commits from git clone to this one or only this commit. My
>>> reading seems to say that this is *only* this one commit which is not my
>>> need. Can anyone confirm this please?
>>
>> [My wording is not trying to be explicit about multi-branch
>> merge points. Nor does it try to deal much with if you have
>> local changes or staged changes in place at the time of the
>> activity or if you have extra files not checked into git in
>> the tree as well. And so on: a simple same-branch context.]
>>
>> A commit hash/id identifies everything on the branch at the
>> time the commit finished, including what did not change
>> compared to the prior commit on the branch. Checking out the
>> commit spans all of it. Jumping forward (or backward) a bunch
>> of commits on a branch does not require doing them one by one
>> to get the net effect.
>>
>> You may want to inspect after checkouts (or similar activity)
>> that "git status" does not display any surprises that need
>> to be cleaned up in the local file system via some variant(s)
>> of git restore or/and git clean or the like.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: poudriere: net/openldap24-server: stage/runaway , building forever
On 09/04/21 11:56, O. Hartmann wrote: On Fri, 9 Apr 2021 10:16:27 +0200 (CEST) Ronald Klop wrote: Hi, The official pkg builders are also stuck for 14-CURRENT. Although at a different port sysutils/msktutil. See main-amd64 at https://pkg-status.freebsd.org/builds?type=package It is stuck in "stage/runaway" for 61 hours now. http://beefy18.nyi.freebsd.org/build.html?mastername=main-amd64-default=p569609_s5b3b19db73 (ipv6 only) NB: I'm not involved in the pkg building cluster. Regards, Ronald. Van: "O. Hartmann" Datum: vrijdag, 9 april 2021 07:27 Aan: FreeBSD Ports Onderwerp: Re: poudriere: net/openldap24-server: stage/runaway , building forever On Fri, 9 Apr 2021 06:17:03 +0200 "Hartmann, O." wrote: Recent CURRENT host (FreeBSD 14.0-CURRENT #26 main-n245806-4d221f59b85: Sat Apr 3 06:43:44 CEST 2021 amd64), poudriere CURRENT jail at 14.0-CURRENT 147 amd64 from 2021-04-08 05:25:38. It seems that the recent CURRENT does have a serious problem when building net/openldap24-server. The build process gets stuck with staging and is marked "runaway": [head-amd64-head-default] [2021-04-08_13h56m41s] [parallel_build:] Queued: 1847 Built: 63 Failed: 17 Skipped: 1759 Ignored: 8Tobuild: 0 Time: 13:26:35 [01]: net/openldap24-server | openldap-sasl-server-2.4.58 stage/runaway (06:28:32 / 08:41:16) Also, on jails (recent CURRENT) serving as OpenLDAP server (also recent taken from git /usr/ports, branch main), run into a serious problem starting slapd, when starting slapd and the process is reporting checking configuration, it freezes forever. Putting slapd into debug mode doesn't help, since the freeze is quite early. Does anybody know what the reason for this strange behaviour is on CURRENT? All CURRENT servers are affected (almost all the same revision as shown above)? Thanks in advance, O. Hartmann Short update, another host is stuck at the very same point, host's CURRENT is at FreeBSD 14.0-CURRENT #2 main-n245870-86a52e262a6: Wed Apr 7 13:57:20 CEST 2021 amd64, it's jails is taken from the same source. The process is stuck at staging and took 34 hours ... never seen before: [...] [09:05:25] [03] [02:13:44] Finished net/openldap24-server | openldap-sasl-server-2.4.58: Failed: stage/runaway load: 10.39 cmd: awk 24374 [running] 0.06r 0.00u 0.00s 0% 3420k [headamd64-head-default] [2021-04-07_12h26m18s] [parallel_build:] Queued: 3298 Built: 2123 Failed: 7 Skipped: 1161 Ignored: 7Tobuild: 0 Time: 40:52:34 [03]: net/openldap24-server | openldap-sasl-server-2.4.58 stage/runaway (31:48:30 / 34:01:11) [40:52:52] Logs: /pool/poudriere/data/logs/bulk/headamd64-head-default/2021-04-07_12h26m18s ___ [...] It seems, that jails on 14-CURRENT do have a strange and malfunctional behaviour now. Most probably related to commit d36d68161517 check the thread at [1]. A solution is being discussed in D29623 at [2]. [1] https://lists.freebsd.org/pipermail/dev-commits-src-all/2021-April/005159.html [2] https://reviews.freebsd.org/D29623 -- Guido Falsi _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Specific svn/git package update use case
Simon Wright simon.wright at gmx.net wrote on Fri Apr 9 02:48:47 UTC 2021 : > I'm still not clear though whether checking out this commit brings in > all the commits from git clone to this one or only this commit. My > reading seems to say that this is *only* this one commit which is not my > need. Can anyone confirm this please? [My wording is not trying to be explicit about multi-branch merge points. Nor does it try to deal much with if you have local changes or staged changes in place at the time of the activity or if you have extra files not checked into git in the tree as well. And so on: a simple same-branch context.] A commit hash/id identifies everything on the branch at the time the commit finished, including what did not change compared to the prior commit on the branch. Checking out the commit spans all of it. Jumping forward (or backward) a bunch of commits on a branch does not require doing them one by one to get the net effect. You may want to inspect after checkouts (or similar activity) that "git status" does not display any surprises that need to be cleaned up in the local file system via some variant(s) of git restore or/and git clean or the like. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeCAD
On Fri, 9 Apr 2021 07:17:18 +0900 Tatsuki Makino wrote: > LuMiWa via freebsd-ports wrote on 2021/04/07 06:46: > > I didn't install because it pull Python 2.7. I didn't change any > > configuration. FreeCAD has just collada but other I left default. QT > > Web engine pulls Gstreamer and I thing something from Gstreamer > > pulls Python 2.7. > > make -C /usr/ports/www/qt5-webengine/ -V USES > > The above command returns a value containing python:2.7,build. > > _______ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to > "freebsd-ports-unsubscr...@freebsd.org" Thank you very much. -- “We live in a world where there is more and more information, and less and less meaning.” Jean Baudrillard ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeCAD
On Thu, 8 Apr 2021 20:09:12 +0200 Christoph Moench-Tegeder wrote: > ## LuMiWa via freebsd-ports (freebsd-ports@freebsd.org): > > > I didn't install because it pull Python 2.7. I didn't change any > > configuration. > > The question is not so much what you did not do, but what you did > do. How did you try to install FreeCAD? > > Regards, > Christoph > portmaster -d cad/freecad -- “We live in a world where there is more and more information, and less and less meaning.” Jean Baudrillard _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
devel/llvm10 (and 11) on aarch64: only BE_AMDGPU registered targets despite OPTIONS_FILE_SET+=BE_NATIVE also being set
Building devel/llvm10 via poudriere-devel on a Cortex-A57 system (OverDrive 1000), I ended up with just: # /usr/local/llvm10/bin/llc -version LLVM (http://llvm.org/): LLVM version 10.0.1 Optimized build. Default target: aarch64-portbld-freebsd14.0 Host CPU: (unknown) Registered Targets: amdgcn - AMD GCN GPUs r600 - AMD GPUs HD2XXX-HD6XXX from a context that has: # grep -r BE /usr/local/etc/poudriere.d/options/devel_llvm10/ /usr/local/etc/poudriere.d/options/devel_llvm10/options:_FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_AMDGPU /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_FREEBSD /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_NATIVE /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_STANDARD (I've used the combination in various llvm*'s for years, including using such for llvm10. Something has changed.) I'll not repeat the material here but llvm11 got the same sort of result. May be that "Host CPU: (unknown)" has something to do with it? This has been true since I built and installed back on 2021-Feb-11 and is true of my updating build started yesterday (bulk still in progress). LLVM10 pkg info from active install: # pkg info llvm10 llvm10-10.0.1_5 Name : llvm10 Version: 10.0.1_5 Installed on : Thu Feb 11 12:05:43 2021 PST Origin : devel/llvm10 Architecture : FreeBSD:14:aarch64 Prefix : /usr/local Categories : devel lang Licenses : MIT, BSD3CLAUSE, PD, LLVM, REGEX, LLVM2 Maintainer : bro...@freebsd.org WWW: http://llvm.org/ Comment: LLVM and Clang Options: BE_AMDGPU : on BE_FREEBSD : off BE_NATIVE : on BE_STANDARD: off CLANG : on DOCS : on EXTRAS : on LIT: on LLD: on LLDB : on LLD_LINK : on OPENMP : on PYCLANG: off Shared Libs required: libedit.so.0 liblua-5.2.so libpython3.7m.so.1.0 libxml2.so.2 Shared Libs provided: libRemarks.so.10 libarcher.so libclang-cpp.so.10 liblldb.so.10 libLTO.so.10 libLLVM-10.so libomptarget.so libomp.so libclang.so.10 Annotations: FreeBSD_version: 144 repo_type : binary repository : custom Flat size : 509MiB Description: The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. This port includes Clang (a C/C++/Objective-C compiler), LLD (a linker), LLDB (a debugger), an OpenMP runtime library, and the LLVM infrastructure these are built on. WWW: http://llvm.org/ (So the above predates the git conversion.) The issue was first noticed via build failures like (from a log file): . . . Sanity testing C compiler: /usr/local/bin/clang10 Is cross compiler: False. Sanity check compiler command line: /usr/local/bin/clang10 /wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-20.2.3/_build/meson-private/sanitycheckc.c -o /wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-20.2.3/_build/meson-private/sanitycheckc.exe -O2 -pipe -mcpu=cortex-a57 -g -fstack-protector-strong -fno-strict-aliasing -mcpu=cortex-a57 -pipe -D_FILE_OFFSET_BITS=64 -Wl,-rpath=/usr/local/llvm10/lib Sanity check compile stdout: - Sanity check compile stderr: error: unable to create target: 'No available targets are compatible with triple "aarch64-portbld-freebsd14.0"' 1 error generated. . . . The FreeBSD is a non-debug build based on main 7381bbee29df: # ~/fbsd-based-on-what-freebsd-main.sh FreeBSD FBSDCA57 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm64 aarch64 145 145 def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context. merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2 merge-base: CommitDate: 2021-03-12 20:29:42 + 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread n245444 (--first-parent --count for merge-base) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Portsbase and maildir
On 08/04/21 07:27, Jim Trigg wrote: I am going to submit that PORTSBASE should be something other than /usr/local/. My current preference (though not solid) is /ports/. I would like to reclaim /usr/local for true local (site-based, not distribution-based) things. (Example: local [site-based] scripts in /usr/local/s?bin/.) Not sure if PORTSBASE is the name of what you mean, Looks like you mean PREFIX and LOCALBASE. You can redefine those if you want your ports to be installed in a different path than the default. On a related note, I would like to see maildirmake separated out as a port of its own on which ports supporting Maildir depend. That way we avoid clunkiness like "/usr/local/bin/maildrop-maildirmake". (The first point most recently evidenced itself as "where do I put a symbolic link to maildrop-maildirmake called maildirmake?".) As the maintainer of maildrop and other related ports, I am installing it like that to avoid conflicts with other ports installing the same thing. Please note that mail/courier-imap installs it as bin/maildirmake. ports/pkg do not provide an official way to create symlinks, anyway the two executables are completely equivalent. Upstream does not provide maildirmake as a separate package and I'm only following upstream practices. As I stated in the past, my opinion is that ports is just that, ports, not a place for original development. If you'd like to extract maildirmake from the courier ports as a standalone package I have no objection, you can do that and submit a port of the result, providing upstream tarball and all. -- Guido Falsi _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeCAD
On Tue, 6 Apr 2021 22:14:21 +0200 Christoph Moench-Tegeder wrote: > ## LuMiWa via freebsd-ports (freebsd-ports@freebsd.org): > > > I try to install cad/freecad and it pulls lang/Python 27. > > FreeCAD itself depends on Python "3.6 or higher". What exactly did > you do? > > > I didn't install. > > So you're sying it's not relevant anymore anyway? > > Regards, > Christoph > I didn't install because it pull Python 2.7. I didn't change any configuration. FreeCAD has just collada but other I left default. QT Web engine pulls Gstreamer and I thing something from Gstreamer pulls Python 2.7. Thank you. -- “We live in a world where there is more and more information, and less and less meaning.” Jean Baudrillard ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: poudriere and gitup
Tatsuki Makino wrote:
> -U default value can be changed in ${LOCALBASE}/etc/poudriere.conf, cannot it?
> The default value is defined in common.sh.
>
> GIT_PORTSURL="git.FreeBSD.org/ports.git"
> And
> poudriere ports -c -m git+https -B main
>
Yes, you can put GIT_PORTSURL into poudriere.conf and it will work.
Eventually that and the default branch should be changed in poudriere
proper.
--
Charlie Li
…nope, still don't have an exit line.
(This email address is for mailing list use; replace local-part with
vishwin for off-list communication if possible)
OpenPGP_signature
Description: OpenPGP digital signature
Re: Any plan to fix ports git main history compatibility with old GitHub master?
[The original send attempt for this failed somehow.] Eric Turgeon ericbsd at freebsd.org wrote on Mon Apr 5 20:33:22 UTC 2021 : > Today when trying to sync the GhostBSD ports tree with the FreeBSD ports > tree, I found out the main branch history is not compatible with the old > GitHub master. > > Any plan to migrate to main with hold git history as we had with > freebsd-src? https://wiki.freebsd.org/git says in part (items not completed): QUOTE Apr 4th lwhsu Enable push access to Git deploying to production env and verifying Apr 5th lwhsu Enable push access to Git Apr 6th lwhsu Enable push access to Git (worst-case) lwhsu Push “Welcome to Git” commit lwhsu Starting pushing to external mirrors (github, gitlab, etc.) portmgr 2021Q2 quarterly branch created END QUOTE Note the "Starting pushing to external mirrors (github, gitlab, etc.)" that was added to the schedule on 2021-04-05 09:12:09 UTC. That might be what you are waiting for. Still not listed as started, last I looked. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Any plan to fix ports git main history compatibility with old GitHub master?
___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: poudriere and gitup
On 05/04/21 23:26, Jose Quinteiro wrote: On 4/4/21 7:35 AM, Carmel wrote: On Sat, 3 Apr 2021 12:18:27 +, Rene Ladan stated: ... Is or will poudriere default to using net/gitup in FreeBSD 13? Is there a way to configure it in the "poudriere.conf" file? There's a "git" option for the "-m method" command-line switch of poudriere-ports(8). This option is used to specify which method to use to create a ports tree. I don't have any experience with it because I use "-m null" to have Poudriere use a Ports tree I maintain manually with git. It performs a shallow clone, not getting all history (similar to what gitup does) should work with a command line like this: poudriere ports -c -B main -m git -U 'https://git.FreeBSD.org/ports.git' -p freebsd then use following command to update: poudriere ports -u -p freebsd -- Guido Falsi _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD Port: lang/cmucl
Hello, I am trying to port cmucl to RPI4-B RELEASE-13.0-RC3 (arm64-aarch64), but of course I can't as port's and host's architectures are different. Any method for cross-building/compiling this port? or any other port? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Read-only https://cgit.freebsd.org/ports/ accessible now; push access not reported as available yet
https://cgit.freebsd.org/ shows: QUOTE NameDescription IdleLinks development doc FreeBSD documentation tree 16 hourssummarylogtree ports FreeBSD ports tree 57 min. summarylogtree src FreeBSD source tree 3 days summarylogtree END QUOTE https://wiki.freebsd.org/git now reports "deploying to production env" but does not yet indicate "Enable push access to Git". The schedule now has an explicit "Starting pushing to external mirrors (github, gitlab, etc.)" after "Push “Welcome to Git” commit", neither of which have happened yet. "2021Q2 quarterly branch created" is listed last. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeCAD
Hi! I try to install cad/freecad and it pulls lang/Python 27. I thought that we are done with version 27. I didn't install. Thank you. -- “We live in a world where there is more and more information, and less and less meaning.” Jean Baudrillard ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gitip usage.
Carmel carmel_ny at outlook.com wrote on
Sun Apr 4 18:05:17 UTC 2021 :
> On Sun, 4 Apr 2021 19:49:04 +0200 (CEST), Helge Oldach stated:
> >Jeffrey Bouquet via freebsd-ports wrote on Sun, 04 Apr 2021 18:46:15
> >+0200 (CEST):
> >> running 12.2 STABLE, I would like a complete DEFAULTS and PORTS
> >> example for gitup.conf.
> >
> > "defaults" : {
> > "host" : "git.freebsd.org",
> > "port" : 443,
> > "verbosity" : 1,
> > "work_directory" : "/var/db/gitup",
> > },
> >
> > "ports" : {
> > "repository" : "/ports.git",
> > "branch" : "main",
> > "target" : "/usr/ports",
> > "ignores": [
> > "distfiles",
> > "packages",
> > ],
> > },
> >
> >Note this will not work at present - migration is still underway.
> >
> >Kind regards
> >Helge
>
> This seems to work for me.
>
> "defaults" : {
> "host" : "git.freebsd.org",
> "port" : 443,
> "verbosity" : 1,
> "work_directory" : "/var/db/gitup",
> },
>
> "ports" : {
> "host" : "github.com",
> "repository" : "/freebsd/freebsd-ports.git",
The just-above gets you access to github's ports
repository, which is not yet based on the new git
repository.
Until https://cgit.freebsd.org starts showing ports
(in addition to the existing doc and src) not even
read-only access to the updated FreeBSD ports git
repository is available for browsing use. (Any
github update likely comes later?)
Going along with that is that the schedule listed at
https://wiki.freebsd.org/git still indicates "verifying
result in staging env" and does not yet indicate that
the "Welcome to Git" commit as in place.
Unlike for src, the ports schedule makes no mention of
the likes of "Starting pushing to external mirrors
(github, gitlab, etc.)". The following *presumes* such
will be done but the status of such in unclear.
Once github is updated(?) to be tracking the new ports
git repository, you may have some more to do to again
have things be coherent vs. the older github
repository content (hashid changes?).
> "branch" : "main",
> "target" : "/usr/ports",
> "ignores": [
> "distfiles",
> "packages",
> ],
> },
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
gitip usage.
running 12.2 STABLE, I would like a complete DEFAULTS and PORTS example for gitup.conf. forums and this list provide changes [ tersely or sed templating tersely, ] , but no latest indication in its entirety of which invocation would work that I've been able to make update the ports past april 1 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
Felix Palmen felix at palmen-it.de wrote on Sat Apr 3 20:35:46 UTC 2021 : > * Mark Millard via freebsd-ports [20210403 > 10:02]: > > Felix Palmen felix at palmen-it.de wrote on > > > There was an announcement to deprecate it, but it's still built with > > > releng/13 so far, and I'd be surprised if the snapshots for it wouldn't > > > be available any more. Deprecation of portsnap AFAIK isn't directly > > > related to moving to git. (someone correct me please if I'm wrong) > > > > /usr/sbin/portsnap is just a shell script: > --snip-- > > Please see the original announcement for context: > <https://lists.freebsd.org/pipermail/freebsd-ports/2020-August/119098.html> Good point: QUOTE * Make WITHOUT_PORTSNAP default in base. Currently not certain when this will happen. May not happen before 13.0, but hopefully it will. * Eventually, portsnap servers will see low enough usage they can be disabled. END QUOTE Even if WITHOUT_PORTSNAP was the default, the wording suggests that WITH_PORTSNAP would be allowed for a time. And it suggests that portsnap servers disabling would be based on monitoring usage of the servers. > In a nutshell: It was *planned* to no longer build portsnap by default > in 13. Now, it's still built, so I assume that's intentional and > snapshots will still be available (for some time). Seems so. > These snapshots aren't provided by SVN, therefore I doubt having ports > in GIT will cause any technical trouble creating them? The /usr/ports/ content provided by portsnap is extracted from SVN historically and will have to be extracted from git going forward. I expect that there is some implementation change to have the materials show up in the portsnap servers. I'm not claiming to estimate how difficult the change would be. > Side note: your postings have no meaningful References and therefore > don't show up in the correct location in the thread, maybe check your > mail client? Sorry for such problems. > And please don't CC me, I'm reading the list. Okay, but long term I may not remember. I've gotten requests for the other way as well and I'm not likely to try to track all the individual preferences in any reliable manor. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On 03/04/21 18:10, LuMiWa via freebsd-ports wrote: It is not good. The last was I did red was "portsnap" stay still for awhile. I am portsnap and portmaster user for years. Where should I find information what will happened with /usr/ports. Will gitup just replace, update? I am using FreeBSD 13.0-RC5. Thank you. I have no definitive information regarding portsnap. I only remember reading a comment in the last few days to the effect of it being discontinued and suggested a replacement, but I could be wrong about this. I've not been using it for a while and I have not followed news about it. -- Guido Falsi _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On Sat, Apr 03, 2021 at 12:10:33PM -0400, LuMiWa wrote: > On Sat, 3 Apr 2021 05:51:29 -0600 > The Doctor via freebsd-ports wrote: > > > On Sat, Apr 03, 2021 at 12:00:29PM +0200, Guido Falsi via > > freebsd-ports wrote: > > > On 03/04/21 11:28, Guido Falsi via freebsd-ports wrote: > > > > On 03/04/21 02:24, The Doctor wrote: > > > >> On Sat, Apr 03, 2021 at 02:05:45AM +0200, Guido Falsi wrote: > > > >>> On 03/04/21 01:35, The Doctor wrote: > > > >>> > > > >>> Please install gitup and read it's man page, it's straight > > > >>> forward. > > > >>> > > > >>> -- > > > >>> Guido Falsi > > > >> > > > >> > > > >> Results: > > > >> > > > >> gitup -v 1 ports > > > >> # Host: github.com > > > >> # Port: 443 > > > >> # Repository: /freebsd/freebsd-ports.git > > > >> # Target: /usr/ports > > > >> gitup: get_commit_details: refs/heads/master doesn't exist in > > > >> /freebsd/freebsd-ports.git: Invalid argument > > > >> > > > > > > > > Thew migration is still in progress, so I guess the repository is > > > > in an unstable state. Try again once the migration is done. > > > > > > > > > > BTW after migration gitup configuration will need to be updated to > > > point to the new repository I guess. DOcumentation clearly shows > > > how to do that. > > > > > > > Where? > > > > > -- > > > Guido Falsi > > > ___ > > > freebsd-ports@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > > > To unsubscribe, send any mail to > > > "freebsd-ports-unsubscr...@freebsd.org" > > > > It is not good. The last was I did red was "portsnap" stay still for > awhile. I am portsnap and portmaster user for years. Where should I > find information what will happened with /usr/ports. Will gitup just > replace, update? I am using FreeBSD 13.0-RC5. > Thank you. > Well said. > -- > ???We live in a world where there is more and more information, and less > and less meaning.??? > > Jean Baudrillard -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b If they can dehumanize the most innocent, they can dehumanize anyone. -unknown ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
Felix Palmen felix at palmen-it.de wrote on
Fri Apr 2 22:49:58 UTC 2021 :
> * Guido Falsi via freebsd-ports [20210403
> 00:35]:
> > On 02/04/21 23:16, The Doctor via freebsd-ports wrote:
> > > but I use pkg/portsnap .
> > >
> > > How does that affect us?
> >
> > AFAIK you can't use it anymore. Use gitup. It's almost a drop-in
> > replacement.
>
> There was an announcement to deprecate it, but it's still built with
> releng/13 so far, and I'd be surprised if the snapshots for it wouldn't
> be available any more. Deprecation of portsnap AFAIK isn't directly
> related to moving to git. (someone correct me please if I'm wrong)
/usr/sbin/portsnap is just a shell script:
# file /usr/sbin/portsnap
/usr/sbin/portsnap: POSIX shell script, ASCII text executable
Just because the shell script portsnap is installed does not
mean that it will provide updates (that would ultimately
be based the FreeBSD ports git repository content).
The lines in the script that fetch the compressed snapshot
look like:
echo "Fetching snapshot generated at `date -r ${SNAPSHOTDATE}`:"
fetch -r http://${SERVERNAME}/s/${SNAPSHOTHASH}.tgz || return 1
where by default SERVERNAME is as shown below:
# grep SERVERNAME /etc/portsnap.conf
SERVERNAME=portsnap.FreeBSD.org
(It gets the SNAPSHOTHASH from another file fetched from the
server. I'll not indicate such details.)
Saying that portsnap is to be deprecated is to say that the
http://${SERVERNAME}/s/${SNAPSHOTHASH}.tgz files (and related)
will not have updated versions to fetch --and that will cause
portsnap to stop working for its purpose, eve if installed.
It is likely that the lack of:
http://${SERVERNAME}/s/${SNAPSHOTHASH}.tgz
files (and related) is tied to not producing such files
from the new FreeBSD ports git repository.
So, likely: Yes, directly related to moving to git.
>
> Still, in the long run, expect it to vanish.
>
When /usr/sbin/portsnap is removed from the file systems
is not in control of when useful:
http://${SERVERNAME}/s/${SNAPSHOTHASH}.tgz
files exist. But there is not much point to having
/usr/sbin/portsnap in the file systems once useful
versions of such files are no longer available to
fetch.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
_______
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On Sat, 3 Apr 2021 05:51:29 -0600 The Doctor via freebsd-ports wrote: > On Sat, Apr 03, 2021 at 12:00:29PM +0200, Guido Falsi via > freebsd-ports wrote: > > On 03/04/21 11:28, Guido Falsi via freebsd-ports wrote: > > > On 03/04/21 02:24, The Doctor wrote: > > >> On Sat, Apr 03, 2021 at 02:05:45AM +0200, Guido Falsi wrote: > > >>> On 03/04/21 01:35, The Doctor wrote: > > >>> > > >>> Please install gitup and read it's man page, it's straight > > >>> forward. > > >>> > > >>> -- > > >>> Guido Falsi > > >> > > >> > > >> Results: > > >> > > >> gitup -v 1 ports > > >> # Host: github.com > > >> # Port: 443 > > >> # Repository: /freebsd/freebsd-ports.git > > >> # Target: /usr/ports > > >> gitup: get_commit_details: refs/heads/master doesn't exist in > > >> /freebsd/freebsd-ports.git: Invalid argument > > >> > > > > > > Thew migration is still in progress, so I guess the repository is > > > in an unstable state. Try again once the migration is done. > > > > > > > BTW after migration gitup configuration will need to be updated to > > point to the new repository I guess. DOcumentation clearly shows > > how to do that. > > > > Where? > > > -- > > Guido Falsi > > ___ > > freebsd-ports@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to > > "freebsd-ports-unsubscr...@freebsd.org" > It is not good. The last was I did red was "portsnap" stay still for awhile. I am portsnap and portmaster user for years. Where should I find information what will happened with /usr/ports. Will gitup just replace, update? I am using FreeBSD 13.0-RC5. Thank you. -- “We live in a world where there is more and more information, and less and less meaning.” Jean Baudrillard ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On 03/04/21 13:50, The Doctor via freebsd-ports wrote: On Sat, Apr 03, 2021 at 11:28:23AM +0200, Guido Falsi wrote: On 03/04/21 02:24, The Doctor wrote: On Sat, Apr 03, 2021 at 02:05:45AM +0200, Guido Falsi wrote: On 03/04/21 01:35, The Doctor wrote: On Sat, Apr 03, 2021 at 12:35:57AM +0200, Guido Falsi wrote: On 02/04/21 23:16, The Doctor via freebsd-ports wrote: On Fri, Apr 02, 2021 at 04:45:00PM +0200, Guido Falsi via freebsd-ports wrote: On 02/04/21 15:44, The Doctor via freebsd-ports wrote: On Fri, Apr 02, 2021 at 08:55:00AM +0200, Kurt Jaeger wrote: Hi! As a minor aside, has anyone stated the reason why the user-base of base or ports are moving to git? Yes: https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md Then the question is : Moving forward, how do we update the ports? The same questions keep being asked even if replied to multiple times. you can use git with the official git repo (once it will be available, migration is still in progress), or reference a mirror on github or gitlab. Some documentation about how to do this is available at [1]. If I understand correctly documentation will also be added to the handbook once migration is done. Git is a little complicated but a lot of documentation is available on the internet. search engines are you friends. If you only want to keep /usr/ports updated the easiest tool to achieve that is gitup available in ports at net/gitup. I reiterate, migration is still in progress, the latest available snapshot of the ports tree (at present read only) is via subversion. once migration is done the official git repo and mirrors will be available. There isn't much more to be sail until the migration is done. Git is ready, but I use pkg/portsnap . How does that affect us? AFAIK you can't use it anymore. Use gitup. It's almost a drop-in replacement. How do we use gitup in this scenario? What scenario? Please install gitup and read it's man page, it's straight forward. -- Guido Falsi Results: gitup -v 1 ports # Host: github.com # Port: 443 # Repository: /freebsd/freebsd-ports.git # Target: /usr/ports gitup: get_commit_details: refs/heads/master doesn't exist in /freebsd/freebsd-ports.git: Invalid argument Thew migration is still in progress, so I guess the repository is in an unstable state. Try again once the migration is done. -- Guido Falsi LEt us know when ready. This is getting ridicolous. Why should I let you know? Learn to read documentation and use provided information instruments yourself. Check this very thread, in previous posts you have all links and information necessary to know when the tree will be ready, how to configure various tools you need. There is a limit to hand holding you can expect on mailing lists. -- Guido Falsi ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On Sat, Apr 03, 2021 at 12:00:29PM +0200, Guido Falsi via freebsd-ports wrote: > On 03/04/21 11:28, Guido Falsi via freebsd-ports wrote: > > On 03/04/21 02:24, The Doctor wrote: > >> On Sat, Apr 03, 2021 at 02:05:45AM +0200, Guido Falsi wrote: > >>> On 03/04/21 01:35, The Doctor wrote: > >>> > >>> Please install gitup and read it's man page, it's straight forward. > >>> > >>> -- > >>> Guido Falsi > >> > >> > >> Results: > >> > >> gitup -v 1 ports > >> # Host: github.com > >> # Port: 443 > >> # Repository: /freebsd/freebsd-ports.git > >> # Target: /usr/ports > >> gitup: get_commit_details: refs/heads/master doesn't exist in > >> /freebsd/freebsd-ports.git: Invalid argument > >> > > > > Thew migration is still in progress, so I guess the repository is in an > > unstable state. Try again once the migration is done. > > > > BTW after migration gitup configuration will need to be updated to point > to the new repository I guess. DOcumentation clearly shows how to do that. > Where? > -- > Guido Falsi > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b If they can dehumanize the most innocent, they can dehumanize anyone. -unknown ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On Sat, Apr 03, 2021 at 11:28:23AM +0200, Guido Falsi wrote: > On 03/04/21 02:24, The Doctor wrote: > > On Sat, Apr 03, 2021 at 02:05:45AM +0200, Guido Falsi wrote: > >> On 03/04/21 01:35, The Doctor wrote: > >>> On Sat, Apr 03, 2021 at 12:35:57AM +0200, Guido Falsi wrote: > >>>> On 02/04/21 23:16, The Doctor via freebsd-ports wrote: > >>>>> On Fri, Apr 02, 2021 at 04:45:00PM +0200, Guido Falsi via freebsd-ports > >>>>> wrote: > >>>>>> On 02/04/21 15:44, The Doctor via freebsd-ports wrote: > >>>>>>> On Fri, Apr 02, 2021 at 08:55:00AM +0200, Kurt Jaeger wrote: > >>>>>>>> Hi! > >>>>>>>> > >>>>>>>>> As a minor aside, has anyone stated the reason why the user-base of > >>>>>>>>> base > >>>>>>>>> or ports are moving to git? > >>>>>>>> > >>>>>>>> Yes: > >>>>>>>> > >>>>>>>> https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md > >>>>>>>> > >>>>>>> > >>>>>>> Then the question is : Moving forward, how do we update > >>>>>>> the ports? > >>>>>>> > >>>>>> > >>>>>> The same questions keep being asked even if replied to multiple times. > >>>>>> > >>>>>> you can use git with the official git repo (once it will be available, > >>>>>> migration is still in progress), or reference a mirror on github or > >>>>>> gitlab. Some documentation about how to do this is available at [1]. > >>>>>> > >>>>>> If I understand correctly documentation will also be added to the > >>>>>> handbook once migration is done. > >>>>>> > >>>>>> Git is a little complicated but a lot of documentation is available on > >>>>>> the internet. search engines are you friends. > >>>>>> > >>>>>> If you only want to keep /usr/ports updated the easiest tool to achieve > >>>>>> that is gitup available in ports at net/gitup. > >>>>>> > >>>>>> I reiterate, migration is still in progress, the latest available > >>>>>> snapshot of the ports tree (at present read only) is via subversion. > >>>>>> once migration is done the official git repo and mirrors will be > >>>>>> available. > >>>>>> > >>>>>> There isn't much more to be sail until the migration is done. > >>>>>> > >>>>> > >>>>> Git is ready, > >>>>> > >>>>> but I use pkg/portsnap . > >>>>> > >>>>> How does that affect us? > >>>> > >>>> AFAIK you can't use it anymore. Use gitup. It's almost a drop-in > >>>> replacement. > >>>> > >>> > >>> How do we use gitup in this scenario? > >> > >> What scenario? > >> > >> Please install gitup and read it's man page, it's straight forward. > >> > >> -- > >> Guido Falsi > > > > > > Results: > > > > gitup -v 1 ports > > # Host: github.com > > # Port: 443 > > # Repository: /freebsd/freebsd-ports.git > > # Target: /usr/ports > > gitup: get_commit_details: refs/heads/master doesn't exist in > > /freebsd/freebsd-ports.git: Invalid argument > > > > Thew migration is still in progress, so I guess the repository is in an > unstable state. Try again once the migration is done. > > -- > Guido Falsi LEt us know when ready. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b If they can dehumanize the most innocent, they can dehumanize anyone. -unknown ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On Sat, Apr 03, 2021 at 06:23:00AM +0200, Helge Oldach wrote: > The Doctor via freebsd-ports wrote on Fri, 02 Apr 2021 23:16:53 +0200 (CEST): > > Git is ready, > > Is it? > > # git clone -o freebsd https://git.freebsd.org/ports.git > Cloning into 'ports'... > fatal: repository 'https://git.freebsd.org/ports.git/' not found > # > > Check https://github.com/lwhsu/freebsd-git-docs/blob/main/URLs.md > Try gitup from net/gitup > Kind regards > Helge -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b If they can dehumanize the most innocent, they can dehumanize anyone. -unknown _______ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On Fri, Apr 02, 2021 at 11:01:18PM -0700, Mark Millard via freebsd-ports wrote: > > > On 2021-Apr-2, at 20:24, The Doctor wrote: > > > On Sat, Apr 03, 2021 at 07:45:56AM +0600, Muhammad Moinur Rahman wrote: > >> Once it is publicly mentioned that the conversion is completed run the > >> following command: > >> > >> sed -e '/github.com/d' -e 's/freebsd\/freebsd-//g' > >> /usr/local/etc/gitup.conf > >> > >> then do `gitup ports` > >> > >> Kind Regards, > >> Moin > >> > >>> On 3 Apr, 2021, at 07:20, The Doctor via freebsd-ports > >>> wrote: > >>> > >>> On Fri, Apr 02, 2021 at 05:54:48PM -0700, Mark Millard via freebsd-ports > >>> wrote: > >>>> > >>>> > >>>> On 2021-Apr-2, at 17:41, Mark Millard wrote: > >>>> > >>>>> . . . > >>>> > >>> > >>> So what patch is needed to fix the ports issue? > >>> > >>>> > >>>> =. . . > >>> > >>> . . . > >> > > > > 50/50 . > > > > FreeBSD 13.0-RC workstation works. > > > > Ns2 works > > > > ns1 is hung up. > > > > So far I'm unable to interpret the above as a reply > to Moin's text. 50/50? Ns2? ns1? 13.0-RC? > How does that match up to the sed suggestion? > > Also, the conversion has not been made accessible > yet from what I can tell. For example, > > https://cgit.freebsd.org/ > > lists "doc" and "src" but not (yet) "ports". > So, likely: > > https://git.freebsd.org/ports.git > and: > ssh://anon...@git.freebsd.org/ports.git > > are also not working notations yet. > > Thus, removing github.com references in a way that > would try to use one of the above would mean not > finding a ports repository at all (yet). (Justifying > Moin's "Once it is publicly mentioned that the > conversion is completed . . ." wording?) > > (I've no clue if the specifics of the sed suggestion > are correct or not.) > I left this overnight and now gitp -v 2 ports seems to be working properly on all 3 machines. Even FreeBSD 13.0-RC4 to FreeBSD 13.0-RC5 is working correctly! > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b If they can dehumanize the most innocent, they can dehumanize anyone. -unknown ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On 03/04/21 11:28, Guido Falsi via freebsd-ports wrote: On 03/04/21 02:24, The Doctor wrote: On Sat, Apr 03, 2021 at 02:05:45AM +0200, Guido Falsi wrote: On 03/04/21 01:35, The Doctor wrote: Please install gitup and read it's man page, it's straight forward. -- Guido Falsi Results: gitup -v 1 ports # Host: github.com # Port: 443 # Repository: /freebsd/freebsd-ports.git # Target: /usr/ports gitup: get_commit_details: refs/heads/master doesn't exist in /freebsd/freebsd-ports.git: Invalid argument Thew migration is still in progress, so I guess the repository is in an unstable state. Try again once the migration is done. BTW after migration gitup configuration will need to be updated to point to the new repository I guess. DOcumentation clearly shows how to do that. -- Guido Falsi ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On 03/04/21 06:23, Helge Oldach wrote: The Doctor via freebsd-ports wrote on Fri, 02 Apr 2021 23:16:53 +0200 (CEST): Git is ready, Is it? # git clone -o freebsd https://git.freebsd.org/ports.git Cloning into 'ports'... fatal: repository 'https://git.freebsd.org/ports.git/' not found # Check https://github.com/lwhsu/freebsd-git-docs/blob/main/URLs.md No it's not, migration still in progress, please be patient. -- Guido Falsi ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On 03/04/21 02:24, The Doctor wrote: On Sat, Apr 03, 2021 at 02:05:45AM +0200, Guido Falsi wrote: On 03/04/21 01:35, The Doctor wrote: On Sat, Apr 03, 2021 at 12:35:57AM +0200, Guido Falsi wrote: On 02/04/21 23:16, The Doctor via freebsd-ports wrote: On Fri, Apr 02, 2021 at 04:45:00PM +0200, Guido Falsi via freebsd-ports wrote: On 02/04/21 15:44, The Doctor via freebsd-ports wrote: On Fri, Apr 02, 2021 at 08:55:00AM +0200, Kurt Jaeger wrote: Hi! As a minor aside, has anyone stated the reason why the user-base of base or ports are moving to git? Yes: https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md Then the question is : Moving forward, how do we update the ports? The same questions keep being asked even if replied to multiple times. you can use git with the official git repo (once it will be available, migration is still in progress), or reference a mirror on github or gitlab. Some documentation about how to do this is available at [1]. If I understand correctly documentation will also be added to the handbook once migration is done. Git is a little complicated but a lot of documentation is available on the internet. search engines are you friends. If you only want to keep /usr/ports updated the easiest tool to achieve that is gitup available in ports at net/gitup. I reiterate, migration is still in progress, the latest available snapshot of the ports tree (at present read only) is via subversion. once migration is done the official git repo and mirrors will be available. There isn't much more to be sail until the migration is done. Git is ready, but I use pkg/portsnap . How does that affect us? AFAIK you can't use it anymore. Use gitup. It's almost a drop-in replacement. How do we use gitup in this scenario? What scenario? Please install gitup and read it's man page, it's straight forward. -- Guido Falsi Results: gitup -v 1 ports # Host: github.com # Port: 443 # Repository: /freebsd/freebsd-ports.git # Target: /usr/ports gitup: get_commit_details: refs/heads/master doesn't exist in /freebsd/freebsd-ports.git: Invalid argument Thew migration is still in progress, so I guess the repository is in an unstable state. Try again once the migration is done. -- Guido Falsi ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On 2021-Apr-2, at 20:24, The Doctor wrote: > On Sat, Apr 03, 2021 at 07:45:56AM +0600, Muhammad Moinur Rahman wrote: >> Once it is publicly mentioned that the conversion is completed run the >> following command: >> >> sed -e '/github.com/d' -e 's/freebsd\/freebsd-//g' /usr/local/etc/gitup.conf >> >> then do `gitup ports` >> >> Kind Regards, >> Moin >> >>> On 3 Apr, 2021, at 07:20, The Doctor via freebsd-ports >>> wrote: >>> >>> On Fri, Apr 02, 2021 at 05:54:48PM -0700, Mark Millard via freebsd-ports >>> wrote: >>>> >>>> >>>> On 2021-Apr-2, at 17:41, Mark Millard wrote: >>>> >>>>> . . . >>>> >>> >>> So what patch is needed to fix the ports issue? >>> >>>> >>>> =. . . >>> >>> . . . >> > > 50/50 . > > FreeBSD 13.0-RC workstation works. > > Ns2 works > > ns1 is hung up. > So far I'm unable to interpret the above as a reply to Moin's text. 50/50? Ns2? ns1? 13.0-RC? How does that match up to the sed suggestion? Also, the conversion has not been made accessible yet from what I can tell. For example, https://cgit.freebsd.org/ lists "doc" and "src" but not (yet) "ports". So, likely: https://git.freebsd.org/ports.git and: ssh://anon...@git.freebsd.org/ports.git are also not working notations yet. Thus, removing github.com references in a way that would try to use one of the above would mean not finding a ports repository at all (yet). (Justifying Moin's "Once it is publicly mentioned that the conversion is completed . . ." wording?) (I've no clue if the specifics of the sed suggestion are correct or not.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On Sat, Apr 03, 2021 at 07:45:56AM +0600, Muhammad Moinur Rahman wrote: > Once it is publicly mentioned that the conversion is completed run the > following command: > > sed -e '/github.com/d' -e 's/freebsd\/freebsd-//g' /usr/local/etc/gitup.conf > > then do `gitup ports` > > Kind Regards, > Moin > > > On 3 Apr, 2021, at 07:20, The Doctor via freebsd-ports > > wrote: > > > > On Fri, Apr 02, 2021 at 05:54:48PM -0700, Mark Millard via freebsd-ports > > wrote: > >> > >> > >> On 2021-Apr-2, at 17:41, Mark Millard wrote: > >> > >>> The Doctor doctor at doctor.nl2k.ab.ca wrote on > >>> Sat Apr 3 00:27:42 UTC 2021 : > >>> > >>> Results: > >>> > >>>> gitup -v 1 ports > >>>> # Host: github.com > >>>> # Port: 443 > >>>> # Repository: /freebsd/freebsd-ports.git > >>>> # Target: /usr/ports > >>>> gitup: get_commit_details: refs/heads/master doesn't exist in > >>>> /freebsd/freebsd-ports.git: Invalid argument > >>> > >>> When I look at: > >>> > >>> https://github.com/freebsd/freebsd-ports/ > >>> > >>> and look at the popup for selecting a branch > >>> I see a "main" but do not see a "master". > >>> > >>> By contrast when I look at: > >>> > >>> https://github.com/freebsd/freebsd-ports-legacy/ > >>> > >>> and look at the popup for selecting a branch > >>> I see a "master" but do not see a "main". > >>> > >>> It looks like the your gitup is configured for > >>> before the conversion, when only the combination: > >> > >> One aspect of the above sentence is poor: which > >> "conversion"? It might not be the current > >> svn to git one one. For all I know > >> /freebsd/freebsd-ports-legacy/ could have existed > >> under that naming for a while and > >> /freebsd/freebsd-ports/ could have been tracking > >> svn over the same time frame. > >> > >>> /freebsd/freebsd-ports.git > >>> refs/heads/master > >>> > >>> existed. Since then the old /freebsd/freebsd-ports.git > >>> was effectively renamed to /freebsd/freebsd-ports-legacy/ > >>> and a new /freebsd/freebsd-ports/ was created that used > >>> "main" instead of "master". > >> > > > > So what patch is needed to fix the ports issue? > > > >> > >> === > >> Mark Millard > >> marklmi at yahoo.com > >> ( dsl-only.net went > >> away in early 2018-Mar) > >> > >> _______ > >> freebsd-ports@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-ports > >> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > > > > -- > > Member - Liberal International This is doctor@@nl2k.ab.ca Ici > > doctor@@nl2k.ab.ca > > Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist > > rising! > > Look at Psalms 14 and 53 on Atheism > > https://www.empire.kred/ROOTNK?t=94a1f39b > > If they can dehumanize the most innocent, they can dehumanize anyone. > > -unknown > > ___ > > freebsd-ports@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > 50/50 . FreeBSD 13.0-RC workstation works. Ns2 works ns1 is hung up. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b If they can dehumanize the most innocent, they can dehumanize anyone. -unknown ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On 2021-Apr-2, at 18:20, The Doctor wrote: > On Fri, Apr 02, 2021 at 05:54:48PM -0700, Mark Millard via freebsd-ports > wrote: >> >> >> On 2021-Apr-2, at 17:41, Mark Millard wrote: >> >>> The Doctor doctor at doctor.nl2k.ab.ca wrote on >>> Sat Apr 3 00:27:42 UTC 2021 : >>> >>> Results: >>> >>>> gitup -v 1 ports >>>> # Host: github.com >>>> # Port: 443 >>>> # Repository: /freebsd/freebsd-ports.git >>>> # Target: /usr/ports >>>> gitup: get_commit_details: refs/heads/master doesn't exist in >>>> /freebsd/freebsd-ports.git: Invalid argument >>> >>> When I look at: >>> >>> https://github.com/freebsd/freebsd-ports/ >>> >>> and look at the popup for selecting a branch >>> I see a "main" but do not see a "master". >>> >>> By contrast when I look at: >>> >>> https://github.com/freebsd/freebsd-ports-legacy/ >>> >>> and look at the popup for selecting a branch >>> I see a "master" but do not see a "main". >>> >>> It looks like the your gitup is configured for >>> before the conversion, when only the combination: >> >> One aspect of the above sentence is poor: which >> "conversion"? It might not be the current >> svn to git one one. For all I know >> /freebsd/freebsd-ports-legacy/ could have existed >> under that naming for a while and >> /freebsd/freebsd-ports/ could have been tracking >> svn over the same time frame. >> >>> /freebsd/freebsd-ports.git >>> refs/heads/master >>> >>> existed. Since then the old /freebsd/freebsd-ports.git >>> was effectively renamed to /freebsd/freebsd-ports-legacy/ >>> and a new /freebsd/freebsd-ports/ was created that used >>> "main" instead of "master". >> > > So what patch is needed to fix the ports issue? > I only recognized the "master" (github/older) vs. "main" (modern) terminology issue, which was enough to prompt me to look and see what things looked like and report on what I found. I've not done my ports conversion experiments yet and I will be using git, not gitup. I've never used gitup. So I do not know the operational details for fixing what gitup references. (I use git for FreeBSD src.) I can say that you would want to use /freebsd/freebsd-ports.git and whatever notation is appropriate for "main" in order to track ongoing updates. (Presumes that you stick with github instead of the FreeBSD servers.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On Fri, Apr 02, 2021 at 05:54:48PM -0700, Mark Millard via freebsd-ports wrote: > > > On 2021-Apr-2, at 17:41, Mark Millard wrote: > > > The Doctor doctor at doctor.nl2k.ab.ca wrote on > > Sat Apr 3 00:27:42 UTC 2021 : > > > > Results: > > > >> gitup -v 1 ports > >> # Host: github.com > >> # Port: 443 > >> # Repository: /freebsd/freebsd-ports.git > >> # Target: /usr/ports > >> gitup: get_commit_details: refs/heads/master doesn't exist in > >> /freebsd/freebsd-ports.git: Invalid argument > > > > When I look at: > > > > https://github.com/freebsd/freebsd-ports/ > > > > and look at the popup for selecting a branch > > I see a "main" but do not see a "master". > > > > By contrast when I look at: > > > > https://github.com/freebsd/freebsd-ports-legacy/ > > > > and look at the popup for selecting a branch > > I see a "master" but do not see a "main". > > > > It looks like the your gitup is configured for > > before the conversion, when only the combination: > > One aspect of the above sentence is poor: which > "conversion"? It might not be the current > svn to git one one. For all I know > /freebsd/freebsd-ports-legacy/ could have existed > under that naming for a while and > /freebsd/freebsd-ports/ could have been tracking > svn over the same time frame. > > > /freebsd/freebsd-ports.git > > refs/heads/master > > > > existed. Since then the old /freebsd/freebsd-ports.git > > was effectively renamed to /freebsd/freebsd-ports-legacy/ > > and a new /freebsd/freebsd-ports/ was created that used > > "main" instead of "master". > So what patch is needed to fix the ports issue? > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b If they can dehumanize the most innocent, they can dehumanize anyone. -unknown ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On 2021-Apr-2, at 17:41, Mark Millard wrote: > The Doctor doctor at doctor.nl2k.ab.ca wrote on > Sat Apr 3 00:27:42 UTC 2021 : > > Results: > >> gitup -v 1 ports >> # Host: github.com >> # Port: 443 >> # Repository: /freebsd/freebsd-ports.git >> # Target: /usr/ports >> gitup: get_commit_details: refs/heads/master doesn't exist in >> /freebsd/freebsd-ports.git: Invalid argument > > When I look at: > > https://github.com/freebsd/freebsd-ports/ > > and look at the popup for selecting a branch > I see a "main" but do not see a "master". > > By contrast when I look at: > > https://github.com/freebsd/freebsd-ports-legacy/ > > and look at the popup for selecting a branch > I see a "master" but do not see a "main". > > It looks like the your gitup is configured for > before the conversion, when only the combination: One aspect of the above sentence is poor: which "conversion"? It might not be the current svn to git one one. For all I know /freebsd/freebsd-ports-legacy/ could have existed under that naming for a while and /freebsd/freebsd-ports/ could have been tracking svn over the same time frame. > /freebsd/freebsd-ports.git > refs/heads/master > > existed. Since then the old /freebsd/freebsd-ports.git > was effectively renamed to /freebsd/freebsd-ports-legacy/ > and a new /freebsd/freebsd-ports/ was created that used > "main" instead of "master". === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
The Doctor doctor at doctor.nl2k.ab.ca wrote on Sat Apr 3 00:27:42 UTC 2021 : Results: > gitup -v 1 ports > # Host: github.com > # Port: 443 > # Repository: /freebsd/freebsd-ports.git > # Target: /usr/ports > gitup: get_commit_details: refs/heads/master doesn't exist in > /freebsd/freebsd-ports.git: Invalid argument When I look at: https://github.com/freebsd/freebsd-ports/ and look at the popup for selecting a branch I see a "main" but do not see a "master". By contrast when I look at: https://github.com/freebsd/freebsd-ports-legacy/ and look at the popup for selecting a branch I see a "master" but do not see a "main". It looks like the your gitup is configured for before the conversion, when only the combination: /freebsd/freebsd-ports.git refs/heads/master existed. Since then the old /freebsd/freebsd-ports.git was effectively renamed to /freebsd/freebsd-ports-legacy/ and a new /freebsd/freebsd-ports/ was created that used "main" instead of "master". === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On Sat, Apr 03, 2021 at 02:05:45AM +0200, Guido Falsi wrote: > On 03/04/21 01:35, The Doctor wrote: > > On Sat, Apr 03, 2021 at 12:35:57AM +0200, Guido Falsi wrote: > >> On 02/04/21 23:16, The Doctor via freebsd-ports wrote: > >>> On Fri, Apr 02, 2021 at 04:45:00PM +0200, Guido Falsi via freebsd-ports > >>> wrote: > >>>> On 02/04/21 15:44, The Doctor via freebsd-ports wrote: > >>>>> On Fri, Apr 02, 2021 at 08:55:00AM +0200, Kurt Jaeger wrote: > >>>>>> Hi! > >>>>>> > >>>>>>> As a minor aside, has anyone stated the reason why the user-base of > >>>>>>> base > >>>>>>> or ports are moving to git? > >>>>>> > >>>>>> Yes: > >>>>>> > >>>>>> https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md > >>>>>> > >>>>> > >>>>> Then the question is : Moving forward, how do we update > >>>>> the ports? > >>>>> > >>>> > >>>> The same questions keep being asked even if replied to multiple times. > >>>> > >>>> you can use git with the official git repo (once it will be available, > >>>> migration is still in progress), or reference a mirror on github or > >>>> gitlab. Some documentation about how to do this is available at [1]. > >>>> > >>>> If I understand correctly documentation will also be added to the > >>>> handbook once migration is done. > >>>> > >>>> Git is a little complicated but a lot of documentation is available on > >>>> the internet. search engines are you friends. > >>>> > >>>> If you only want to keep /usr/ports updated the easiest tool to achieve > >>>> that is gitup available in ports at net/gitup. > >>>> > >>>> I reiterate, migration is still in progress, the latest available > >>>> snapshot of the ports tree (at present read only) is via subversion. > >>>> once migration is done the official git repo and mirrors will be > >>>> available. > >>>> > >>>> There isn't much more to be sail until the migration is done. > >>>> > >>> > >>> Git is ready, > >>> > >>> but I use pkg/portsnap . > >>> > >>> How does that affect us? > >> > >> AFAIK you can't use it anymore. Use gitup. It's almost a drop-in > >> replacement. > >> > > > > How do we use gitup in this scenario? > > What scenario? > > Please install gitup and read it's man page, it's straight forward. > > -- > Guido Falsi Results: gitup -v 1 ports # Host: github.com # Port: 443 # Repository: /freebsd/freebsd-ports.git # Target: /usr/ports gitup: get_commit_details: refs/heads/master doesn't exist in /freebsd/freebsd-ports.git: Invalid argument -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b If they can dehumanize the most innocent, they can dehumanize anyone. -unknown ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On 03/04/21 01:35, The Doctor wrote: On Sat, Apr 03, 2021 at 12:35:57AM +0200, Guido Falsi wrote: On 02/04/21 23:16, The Doctor via freebsd-ports wrote: On Fri, Apr 02, 2021 at 04:45:00PM +0200, Guido Falsi via freebsd-ports wrote: On 02/04/21 15:44, The Doctor via freebsd-ports wrote: On Fri, Apr 02, 2021 at 08:55:00AM +0200, Kurt Jaeger wrote: Hi! As a minor aside, has anyone stated the reason why the user-base of base or ports are moving to git? Yes: https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md Then the question is : Moving forward, how do we update the ports? The same questions keep being asked even if replied to multiple times. you can use git with the official git repo (once it will be available, migration is still in progress), or reference a mirror on github or gitlab. Some documentation about how to do this is available at [1]. If I understand correctly documentation will also be added to the handbook once migration is done. Git is a little complicated but a lot of documentation is available on the internet. search engines are you friends. If you only want to keep /usr/ports updated the easiest tool to achieve that is gitup available in ports at net/gitup. I reiterate, migration is still in progress, the latest available snapshot of the ports tree (at present read only) is via subversion. once migration is done the official git repo and mirrors will be available. There isn't much more to be sail until the migration is done. Git is ready, but I use pkg/portsnap . How does that affect us? AFAIK you can't use it anymore. Use gitup. It's almost a drop-in replacement. How do we use gitup in this scenario? What scenario? Please install gitup and read it's man page, it's straight forward. -- Guido Falsi ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No update for a day on ports?
On Sat, Apr 03, 2021 at 12:35:57AM +0200, Guido Falsi wrote: > On 02/04/21 23:16, The Doctor via freebsd-ports wrote: > > On Fri, Apr 02, 2021 at 04:45:00PM +0200, Guido Falsi via freebsd-ports > > wrote: > >> On 02/04/21 15:44, The Doctor via freebsd-ports wrote: > >>> On Fri, Apr 02, 2021 at 08:55:00AM +0200, Kurt Jaeger wrote: > >>>> Hi! > >>>> > >>>>> As a minor aside, has anyone stated the reason why the user-base of base > >>>>> or ports are moving to git? > >>>> > >>>> Yes: > >>>> > >>>> https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md > >>>> > >>> > >>> Then the question is : Moving forward, how do we update > >>> the ports? > >>> > >> > >> The same questions keep being asked even if replied to multiple times. > >> > >> you can use git with the official git repo (once it will be available, > >> migration is still in progress), or reference a mirror on github or > >> gitlab. Some documentation about how to do this is available at [1]. > >> > >> If I understand correctly documentation will also be added to the > >> handbook once migration is done. > >> > >> Git is a little complicated but a lot of documentation is available on > >> the internet. search engines are you friends. > >> > >> If you only want to keep /usr/ports updated the easiest tool to achieve > >> that is gitup available in ports at net/gitup. > >> > >> I reiterate, migration is still in progress, the latest available > >> snapshot of the ports tree (at present read only) is via subversion. > >> once migration is done the official git repo and mirrors will be available. > >> > >> There isn't much more to be sail until the migration is done. > >> > > > > Git is ready, > > > > but I use pkg/portsnap . > > > > How does that affect us? > > AFAIK you can't use it anymore. Use gitup. It's almost a drop-in > replacement. > How do we use gitup in this scenario? > -- > Guido Falsi -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b If they can dehumanize the most innocent, they can dehumanize anyone. -unknown ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
