I thought "pkg updating" would alert me about python...?
I just re-verified the behavior, so -- even though I have already started taking evasive action (updating python), I figured it may be of use to show what I'm seeing; maybe I'm confused: Local ports tree is updated; previous ports update was a week ago. I happen to know that there's an UPDATING entry: lgld-dhw(12.2-S)[4] tail +16 /usr/ports/UPDATING | head -5 20210425: AFFECTS: users of python AUTHOR: k...@freebsd.org The default version of python3 and python was switched to 3.8. And that this machine should be affected: lgld-dhw(12.2-S)[5] pkg info -o python\* python27-2.7.18_1 lang/python27 python36-3.6.13lang/python36 python38-3.8.9 lang/python38 [As noted above, I had already started evasive action.] But "pkg updating" is not actually showing the above entry: lgld-dhw(12.2-S)[6] pkg updating -d 20210424 lgld-dhw(12.2-S)[7] echo $? 0 Am I alone in expecting "pkg updating" to have displayed the 20210425 entry? (There was an issue a while back, where "pkg updating" was not showing "glob" entries, but that has since been addressed.) This is on a machine running stable/12: lgld-dhw(12.2-S)[8] uname -a FreeBSD lgld-dhw.corp.example.com 12.2-STABLE FreeBSD 12.2-STABLE #21 stable/12-n233048-23a3c3d97d72: Sun May 2 04:43:57 PDT 2021 r...@lgld-dhw.corp.example.com:/common/S2/obj/common/S2/src/amd64.amd64/sys/GENERIC amd64 lgld-dhw(12.2-S)[9] pkg -v 1.16.3 Thanks. Peace, david -- David H. Wolfskill da...@catwhisker.org "some of the terminology that was used, like 'hugs and kisses,' and 'very fine people,' is like very different from what I experienced and what my co-workers experienced on the 6th." - Michael Fanone, DC Metro Police Officer See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Some success; some problems with x11/nvidia-driver-460.39_1
With the update of x11/nvidia-driver from 460.39 to 460.39_1, it now builds and works on a couple of laptops, running either stable/12 (stable/12-n232662-e8eded55f23) or stable/13 (stable/13-n244485-6136a10e355a). On those same laptops, however, I get panices running head (either main-n244659-689561d40322 or main-n244663-f6e8256a965d). As I was unable to get crash dumps, I took screenshots; they are available at https://www.catwhisker.org/~david/FreeBSD/ports/nvidia-driver/head_panics/ They look like lock-ordering issues to me -- but that should be considered a semi-educated guess (at best). Quite unrelated to the above (as far as I can tell), except that it also involves an issue with x11/nvidia-driver: a desktop mini-tower that had been building/updating x11/nvidia-driver-440 every week running stable/12 ... did not do so well attempting to build the port during its kernel build (by virtue of PORTS_MODULES=x11/nvidia-driver in /etc/src.conf) this morning -- it nearly finished, then failed to find a file where it was expected during the "Registering installation" phase: | ... | > Compressing man pages (compress-man) | ===> Installing for nvidia-driver-460.39_1 | ===> Registering installation for nvidia-driver-460.39_1 | pkg-static: Unable to access file /common/ports/x11/nvidia-driver/work/stage/common/local/share/vulkan/icd.d/nvidia_icd.json:No such file or directory | pkg-static: Unable to access file /common/ports/x11/nvidia-driver/work/stage/common/local/share/vulkan/implicit_layer.d/nvidia_layers.json:No such file or directory | *** Error code 1 | | Stop. | make[1]: stopped in /common/ports/x11/nvidia-driver | *** Error code 1 | | This machine has the specification (in /etc/make.conf): PORTSDIR=/common/ports I re-created the observed issue by trying to update/install x11/nvidia-driver using portmaster (in its default "clean everything before and after" mode). I did this in a script(1) invocation, and have copied the resulting typescript to https://www.catwhisker.org/~david/FreeBSD/ports/nvidia-driver/stable_12_staging_error/nvidia_build.txt Peace, david -- David H. Wolfskill da...@catwhisker.org Donald Trump held the office of President of the US as he incited his Putsch. See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Can't load nvidia.ko on stable/12 after r564088 (440.100_1 -> 460.36)
On Fri, Feb 05, 2021 at 04:51:02AM -0800, John Kennedy wrote: > ... > > So I suspect that "link_elf_obj: symbol nvidia_driver_name undefined" > > whine is likely salient. > > I just opened up PR#253269 for the same symptom. Ah; cool -- thanks! Once I finish the morning's update cycle, I'll Cc: myself on it. > I suspect that it is due to me having WITH_BIND_NOW=YES set in > my /etc/src.conf (my usual cause for undefined symbols that haven't > bitten other people). Have you set that as well? I do not; what I have is: KERNCONF=CANARY PORTS_MODULES+=x11/nvidia-driver .MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d WITHOUT_DEBUG_FILES=1 IWN_DEBUG=1 IEEE80211_DEBUG=1 BATCH_DELETE_OLD_FILES=1 WITHOUT_REPRODUCIBLE_BUILD=yes WITHOUT_LLVM_TARGET_ALL=yes > If not, then probably a much wider audience. Probably, yeah. Peace, david -- David H. Wolfskill da...@catwhisker.org Donald Trump held the office of President of the US as he incited his Putsch. See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Can't load nvidia.ko on stable/12 after r564088 (440.100_1 -> 460.36)
This is on both my current laptop (Dell Precision M4800) and a new(er) one (Dell Precision 7520); the current laptop's graphics card shows up as: vgapci0@pci0:1:0:0: class=0x03 card=0x05cc1028 chip=0x11fc10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'GK106GLM [Quadro K2100M]' class = display subclass = VGA and the new(eR) one as: vgapci0@pci0:1:0:0: class=0x03 card=0x17b01028 chip=0x13b610de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'GM107GLM [Quadro M1200 Mobile]' class = display subclass = VGA while running stable/12 at n232662-e8eded55f23: g1-55(12.2-S)[5] uname -aUK FreeBSD g1-55.catwhisker.org 12.2-STABLE FreeBSD 12.2-STABLE #949 stable/12-n232662-e8eded55f23: Fri Feb 5 03:33:27 PST 2021 r...@g1-55.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY amd64 1202505 1202505 dmesg reports: link_elf_obj: symbol nvidia_driver_name undefined linker_load_file: /boot/modules/nvidia.ko - unsupported file type KLD nvidia-modeset.ko: depends on nvidia - not available or version mismatch linker_load_file: /boot/modules/nvidia-modeset.ko - unsupported file type for each. So I suspect that "link_elf_obj: symbol nvidia_driver_name undefined" whine is likely salient. As a circumvention: cd /usr/ports/x11/nvidia-driver && \ sudo svn merge -c -r564088 . && \ sudo portmaster x11/nvidia-driver worked for me (well, for the current laptop; I left the newer laptop broken, as I only ssh into it, as its built-in mouse doesn't seem to work with FreeBSD, nor does its wireless card (yet)). Peace, david -- David H. Wolfskill da...@catwhisker.org Donald Trump held the office of President of the US as he incited his Putsch. See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Pinentry
On Mon, Jan 25, 2021 at 11:00:46AM -0700, @lbutlr wrote: > I ma trying to figure out why pin entry and pinetnry-tty are installed. If I > try to remove it, I get a list of post that are to be deleted. > > Installed packages to be REMOVED: > gnupg: 2.2.27 > gpgme: 1.15.1 > mimedefang: 2.83_3 > mutt: 2.0.4 > pinentry: 1.1.0_7 > pinentry-tty: 1.1.0 > spamass-milter: 0.4.0_4 > spamassassin: 3.4.4 > subversion: 1.14.0 > > I've looked through he config for all of these and not seen anything about > PIN entry, and am wondering why it would be required to run any of these > packages. pinentry is (also) used to enter (e,g,) passphrases (as would be used by gnupg). > I cannot imagine any circumstances in which I would need to enter a PIN on a > TTY and no one else could possibly do so. > > I suspect mutt since it is relatively newly installed, nut I see nothing in > the config that seems like it wold disable this. (Mutt is used as a > convenient way to send html formatted mail of some system events), it is not > used to access mail off the server and is only used by me to access mail on > the server. > You may well need but a subset of the default options in that case. Peace, david -- David H. Wolfskill da...@catwhisker.org Some "Republicans" seem bound and determined to turn the party known for touting "law and order" into one that supports mob rule and insurrection. See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: portmaster new development
Original Message Subject: Re: portmaster new development From: LuMiWa via freebsd-ports To: freebsd-ports@freebsd.org Date: 2020-12-27 02:00+0300 On Sun, 27 Dec 2020 11:16:23 +0100 Michael Grimm wrote: Matthias Apitz wrote: El día domingo, diciembre 27, 2020 a las 09:22:42a. m. +0100, Kurt Jaeger escribió: That works as well. I have a checkout of the ports tree, use make config to define non-default port options. This stores the selected OPTIONs in /var/db/ports/, and poudriere uses those options just fine. Re/ the options, I copy them into the jail with something like this procedure: # cd /usr/ports/mail/mutt # make config # mkdir -p /usr/local/etc/poudriere.d/freebsd-head-options/mail_mutt # cp /var/db/ports/mail_mutt/options /usr/local/etc/poudriere.d/freebsd-head-options/mail_mutt 'freebsd-head' is the name of the poudriere jail (I have some of them) and the ports options stay there, as well the make.conf options in /usr/local/etc/poudriere.d/freebsd-head-make.conf I am following stable, and my jail's name has been set to stable. All of poudriere's settings/configs are kept in: /usr/local/etc/poudriere.d The subject is 'portmaster new development' but again start pushing poudriere to FreeBSD users. I do not use zfs file system and I do not use poudriere and I do not want to use on my computer for building some ports and then spending hours and hours with poudriere with not enough machine. For me is portmaster perfect as is now. I have to agree, portmaster works for certain user cases where poudriere doesn't, like mine. The answer seems to be just (buy) a high end machine and dedicate it to build with lots of RAM, high end CPU's, and a big ZFS array with the right combination of SSDs etc and it is fast and stable! While I'm sure that's true, that's not consistent with everyone's environment. I'm reminded of many client-server applications that are developed by people on gigabit fiber and seem to consider the "edge" case of the rest of the world on spotty internet not worthy of consideration, complaints merely whiny carping by people who should just lift their internet up by the bootstraps. I've run a server with a set of jails providing services for about 20 years. Maintaining them with portsnap and portmaster works and is efficient and functional and an efficient and practical use of the compute resources I have. Adding new and potentially better tools has been a pleasure of the community, but abandoning users always going to create friction and dismissing another's use case as "doing it wrong" is a great way to create animosity and dysfunction. The first wave of poudriereism was very annoying and offputting, but in the last year I've been delighted by the excellent and very responsive work of port maintainers to resolve issues quickly and cleanly and those of us still doing it the "old way" can still do so successfully. It'll be annoying and a little disruptive to lose the excellent tool that portsnap has been all these years, truly one of the brilliant, focused, and tremendously useful tools in the FreeBSD kit, but we'll figure out how to keep things working. ___ 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: make index errors ports/head rev 556800
On Wed, Dec 02, 2020 at 02:41:17PM +, tech-lists wrote: > Hi, > > I'm getting these errors when make index runs on latest ports: > [...] > Warning: Duplicate INDEX entry: ocaml-nox11-4.05.0_1 > Warning: Duplicate INDEX entry: mc-nox11-4.8.24 > [...] > > Should I raise this in bugzilla? > > thanks, > -- > J. My local "make index" had no issues with a ports tree (head@r556814), running on stable/12@r368270. Peace, david -- David H. Wolfskill da...@catwhisker.org "We are trying to do another four years." (delusional) Donald Trump, 01 Dec 2020 See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Might an UPDATING entry be appropriate for a MINIMAL_PKG_VERSION bump?
On Tue, Oct 06, 2020 at 08:31:05AM +0900, Tatsuki Makino wrote:
> Hello.
>
> In my case,
> -x \*-kmod-\[0-9gv\] is added to portmaster because all packages that
> install kernel modules contain -kmod in their names. This excludes *-kmod.
> And when they are upgraded, I won't be installing them right away.
>
> Then to install them I write PORTS_MODULES in src.conf.
> PORTS_MODULES=\
> graphics/drm-fbsd12.0-kmod\
> graphics/gpu-firmware-kmod
>
> They are created at the same time as the kernel.
>
But in order for them to be built, you need to have updated
ports-mgmt/pkg ahead of time, or this kind of thing happens:
| ...
| --- kernel.full ---
| linking kernel.full
| ctfmerge -L VERSION -g -o kernel.full ...
| text data bssdec hex filename
| 22900304 1840729 3667344 28408377 0x1b17a39 kernel.full
| Building /common/S1/obj/usr/src/amd64.amd64/sys/CANARY/kernel.debug
| Building /common/S1/obj/usr/src/amd64.amd64/sys/CANARY/kernel
| --- all ---
| ===> Ports module x11/nvidia-driver (all)
| cd ${PORTSDIR:-/usr/ports}/x11/nvidia-driver; env -u CC -u CXX -u CPP -u
MAKESYSPATH -u MK_AUTO_OBJ -u MAKEOBJDIR MAKEFLAGS="-j 16 -J 15,16 -j 16 -J
15,16 -D NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL KERNEL=kernel TARGET=amd64
TARGET_ARCH=amd64" SYSDIR=/usr/src/sys
PATH=/common/S1/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/common/S1/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/common/S1/obj/usr/src/amd64.amd64/tmp/legacy/bin:/common/S1/obj/usr/src/amd64.amd64/tmp/usr/sbin:/common/S1/obj/usr/src/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SRC_BASE=/usr/src OSVERSION=1202502
WRKDIRPREFIX=/common/S1/obj/usr/src/amd64.amd64/sys/CANARY make -B clean build
| ===> Cleaning for nvidia-driver-440.100_1
| ===> nvidia-driver-440.100_1 pkg(8) must be version 1.15.9 or greater, but
| you have 1.15.8. You must upgrade the ports-mgmt/pkg port first.
| *** Error code 1
|
| Stop.
Hence my query: Is an UPDATING entry warranted when MINIMAL_PKG_VERSION is
bumped?
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
"the end of the pandemic is in sight" -- Donald Trump (while infected
with SARS-COV-2)
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
Might an UPDATING entry be appropriate for a MINIMAL_PKG_VERSION bump?
When I rebuild FreeBSD (stable/12) on my laptop, I also rebuild a ports module (x11/nvidia-driver), since the laptop has an Nvidia graphics card. However, a couple of times within the last few days, the kernel build has failed because I normally wait to update ports until after I have built and rebooted the newly-built base OS... and "?ports" includes ports-mgmt/pkg. In each case (so far), I have then updated ports-mgmt/pkg, then re-started the base OS build/install. I believe that it would be helpful to have an UPDATING entry reflect that "evasive action" is required when MINIMAL_PKG_VERSION is bumped. Or, perhaps, I'm going about this all wrong...? If so, please let me know a better way. Thanks. Peace, david -- David H. Wolfskill da...@catwhisker.org Donald Trump is just in it for the publicity (well, and the money). See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
r548950: graphics/mesa-libs vs. x11/nvidia-driver??!?
r548950 | manu | 2020-09-19 02:34:36 -0700 (Sat, 19 Sep 2020) | 9 lines mesa-libs: Add glesv1 lib There is no real reason to disable glesv1 so add it to the build. While here add a USE_GL for it. Reviewed by:zeising Approved by:x11 (zeising@) Differential Revision: https://reviews.freebsd.org/D26461 g1-48(12.2-S)[4] pkg which /usr/local/lib/libGLESv1_CM.so /usr/local/lib/libGLESv1_CM.so was installed by package nvidia-driver-440.100 So when graphics/mesa-libs is updated to r548950, it builds & stages OK, but: ===> Installing for mesa-libs-19.0.8_3 ===> Registering installation for mesa-libs-19.0.8_3 as automatic Installing mesa-libs-19.0.8_3... pkg-static: mesa-libs-19.0.8_3 conflicts with nvidia-driver-440.100 (installs files into the same place). Problematic file: /usr/local/lib/libGLESv1_CM.so *** Error code 70 How should this be resolved? Thanks. Peace, david -- David H. Wolfskill da...@catwhisker.org "President Trump can say whatever he likes, but his actions speak for themselves." -- Dan Berschinski, wounded US Army veteran See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: portsnap depreciation
On Fri, Sep 18, 2020 at 01:58:29PM -0400, Carmel NY wrote: > ... > >https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing-poudriere.html#testing-poudriere-ports-tree > > > >and the next sections. > > According to the above page, "The most straightforward way is to have > Poudriere create a default ports tree for itself, using either > portsnap(8) (if running FreeBSD 12.1 or 11.4) or Subversion (if running > FreeBSD-CURRENT)" Am I to understand that if I am running 11.4-RELEASE, > I cannot use subversion? > I don't see any reason why you cannot use subversion: I do, and have done, since 05 July 2015, running stable/10 at the time; now running stable/12. Peace, david -- David H. Wolfskill da...@catwhisker.org "President Trump can say whatever he likes, but his actions speak for themselves." -- Dan Berschinski, wounded US Army veteran See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: the state of amd64 ports on -CURRENT as of 20200827
On Thu, Aug 27, 2020 at 01:55:08PM +, Mark Linimon wrote: > The latest build of amd64-CURRENT ports has just completed: > > > http://beefy18.nyi.freebsd.org/build.html?mastername=head-amd64-default=p546132_s364744 > > The number of build failures is now 740. This is an slight drop from > the initial post-clang11 commit of 830. This is due to diligent work > by a more than a dozen ports committers. I appreciate their efforts. > As maintainer of a (likely rarely-used) port (x11-wm/piewm), I received a note from pkg-fallout, requested & received advice on how to adrdess it, filed a bug report & attached a maintainer-approved patch; got some advice on a better fix, updated the bug report with the better fix ... and have now received at least 3 more notices of the same failure on the same port... It's https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248859, in case you wanted to see for yourself. As I'm not a committer, it's not clear to me what (else) I can do to help fix this. Peace, david -- David H. Wolfskill da...@catwhisker.org "Those countries that have lost control of the virus like the United States are seeing economic forecasts constantly revised down and are weaker economically." -- Dominick Stephens, Westpac NZ's chief economist See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: x11-wm/piewm: "ld: error: duplicate symbol: yylineno"
On Mon, Aug 24, 2020 at 10:11:45AM +0200, Dimitry Andric wrote: > > > Advice/suggestions? > > In this case, "svn rm x11-wm/piewm/files/patch-gram.y" will fix it > correctly. I have no idea why that patch was added in the first place, > it is clearly incorrect! > > -Dimitry > Thank you very much! I will verify that and send in a correct fix once I do. Peace, david -- David H. Wolfskill da...@catwhisker.org "Those countries that have lost control of the virus like the United States are seeing economic forecasts constantly revised down and are weaker economically." -- Dominick Stephens, Westpac NZ's chief economist See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
x11-wm/piewm: "ld: error: duplicate symbol: yylineno"
On Sun, Aug 23, 2020 at 06:39:10PM +, pkg-fall...@freebsd.org wrote: > You are receiving this mail as a port that you maintain > is failing to build on the FreeBSD package build server. > Please investigate the failure and submit a PR to fix > build. > > Maintainer: da...@catwhisker.org > Last committer: swi...@freebsd.org > Ident: $FreeBSD: head/x11-wm/piewm/Makefile 519608 2019-12-09 > 13:47:16Z swills $ > Log URL: > http://beefy18.nyi.freebsd.org/data/head-amd64-default/p545731_s364466/logs/piewm-1.04_4.log > Build URL: > http://beefy18.nyi.freebsd.org/build.html?mastername=head-amd64-default=p545731_s364466 > ... > --- piewm --- > rm -f piewm > cc -o piewm -L/usr/local/lib gram.o lex.o deftwmrc.o add_window.o > gc.o list.o twm.o parse.o menus.o events.o resize.o util.o > version.o iconmgr.ocursor.o icons.o vdt.o move.o LocPixmap.o > -lXmu -lXt -lSM -lICE -lXext -lX11 -lXt -lSM -lICE -lXext -lXext -lX11 -lm > -ll -lXpm -Wl,-rpath,/usr/local/lib > ld: error: duplicate symbol: yylineno > >>> defined at gram.c > >>>gram.o:(yylineno) > >>> defined at lex.c > >>>lex.o:(.data+0x0) > cc: error: linker command failed with exit code 1 (use -v to see invocation) > *** [piewm] Error code 1 > > make[1]: stopped in /wrkdirs/usr/ports/x11-wm/piewm/work/piewm-1.04 > 1 error > > make[1]: stopped in /wrkdirs/usr/ports/x11-wm/piewm/work/piewm-1.04 > ===> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > the maintainer. > *** Error code 1 > > Stop. > make: stopped in /usr/ports/x11-wm/piewm So... I confess a lack of familiarity with lex, yacc, and their work-alikes. It also appears that x11-wm/tvtwm (for which MAINTAINER is this list -- po...@freebsd.org) is likely similarly affected. I understand that the immediate cause is a recent change; in http://docs.FreeBSD.org/cgi/mid.cgi?B7F9F85B-60A4-4A87-9911-BDE1CBC7BC91, dim@ mentioned: | This is because clang 11 (and gcc 10) now default to -fno-common. The | rationale is explained pretty well in... and goes on to state: | A quick fix is to add CFLAGS+=-fcommon to your make.conf, but that is | rather a big hammer. It is better to add it to just the ports that show | problems due to duplicated symbols. And ideally, those duplicated | symbols should be patched out of the ports. So: apparently *a* way around this is to change the Makefile (to include 'CFLAGS+=-fcommon') -- but I don't know if a "better" approach is feasible: we are dealing with some rather old (or, perhaps, "well-established") code, here. Advice/suggestions? Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org "Those countries that have lost control of the virus like the United States are seeing economic forecasts constantly revised down and are weaker economically." -- Dominick Stephens, Westpac NZ's chief economist See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: bugzilla messages about issues related to freebsd-ports, freebsd-multimedia, ...
On Sat, Jul 11, 2020 at 01:27:55PM +0200, Matthias Apitz wrote: > ... > There is nothing written about "... and for Cc issues from bugzilla". > > What I do not like and do not understand why this was introduced, that > the issue tracker bugzilla copies comments etc. in the issues to the > mailing-list and spams the lists with this (an example is below). This > way I get every day some hundred mails. > > Why is this intention? Can it be changed? To whom I should direct this > complain? > > matthias > That happens -- at least in the case of multimedia/ffmpeg -- because: g1-55(13.0-C)[4] awk -F = '$1 == "MAINTAINER"' /usr/ports/multimedia/ffmpeg/Makefile MAINTAINER= multime...@freebsd.org So it's merely notification to the listed "maintainer" of the port. Peace, david -- David H. Wolfskill da...@catwhisker.org If Trump continues to delay access to his tax records, a voter would be prudent to presume that they contain incriminating information. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Can anyone build www/node right now?
On Sun, Jun 28, 2020 at 10:07:58PM +0200, DutchDaemon - FreeBSD Forums Administrator wrote: > I have tried to build www/node for weeks now, and it always fails. This is on > a fresh Poudriere jail, amd64, 12.1-REL-p6. Checking my logs, www/node is one of the packages built (via poudriere) this morning by my build machine, which was running: freebeast(12.1-S)[1] uname -aUK FreeBSD freebeast.catwhisker.org 12.1-STABLE FreeBSD 12.1-STABLE #942 r362716M/362719: Sun Jun 28 03:33:45 PDT 2020 r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1201518 1201518 at the time, using a (head) ports tree at r540699. As a reality check, I am trying to build www/node on my laptop, running: g1-55(12.1-S)[4] uname -aUK FreeBSD g1-55.catwhisker.org 12.1-STABLE FreeBSD 12.1-STABLE #737 r362716M/362719: Sun Jun 28 03:33:54 PDT 2020 r...@g1-48.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY amd64 1201518 1201518 with a (head) ports tree at r540699. The build machine has no option overrides for www/node; the laptop shows: g1-55(12.1-S)[2] make -C /usr/ports/www/node showconfig ===> The following configuration options are available for node-14.4.0: BUNDLED_SSL=on: Use node.js's bundled OpenSSL implementation DOCS=on: Build and/or install documentation DTRACE=on: Build with DTrace probes NLS=on: Native Language Support ===> Use 'make config' to modify these settings > Opened a ticket for it, with full output... Peace, david -- David H. Wolfskill da...@catwhisker.org Of course Black Lives Matter! Now vote accordingly! See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: poudriere-devel failed to build lang/rust (rust-1.43.1)
On Sun, May 24, 2020 at 04:31:42PM +0200, Jan Beich wrote: > ... > According to the full log the reason is "(signal: 9, SIGKILL: kill)" and > the signal was sent to multiple processes. The kernel usually sends > SIGKILL on out-of-memory conditions. Oh! OK; thank you: I had failed to see that. I'll look into appropriate evasive action (e.g., adding more memory or replacing the machine with a more capable one.) Peace, david -- David H. Wolfskill da...@catwhisker.org "The Liar Tweets Tonight": https://www.youtube.com/watch?v=TkU1ob_lHCw See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Ports from github
i am ahead of you in learning about making ports - if no one more experienced can help you out, feel free to contact me privately and I'll do what I can to help. The FreeBSD ports system is pretty awesome in my opinion - it's far easier than RPMs or DEBs. dave c - Kailua, HI 96734 Cornejo for Congress https://davidcornejo.org/ On Sat, May 23, 2020 at 4:40 PM Montgomery-Smith, Stephen wrote: > > Is there a "howto" that explains how to build a port from a project that > is on github? The FreeBSD porters handbook seems to assume a lot of > knowledge is already understood. > ___ > 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" -- Kailua, Hawaiʻi US +1 (808) 728-3050 ___ 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-devel failed to build lang/rust (rust-1.43.1)
On Sat, May 23, 2020 at 03:56:09PM -0700, David Wolfskill wrote: > ... > load: 8.59 cmd: sh 99503 [piperd] 35609.83r 1.23u 1.88s 0% 2156k > [12amd64-ports-home] [2020-05-23_12h08m48s] [parallel_build:] Queued: 1003 > Built: 999 Failed: 1Skipped: 2Ignored: 0Tobuild: 1 Time: > 09:53:48 > [05]: www/chromium | chromium-81.0.4044.138_1 build > (03:59:48 / 04:08:53) > [09:53:49] Logs: > /tank/poudriere/poudriere/data/logs/bulk/12amd64-ports-home/2020-05-23_12h08m48s > ... > I expect that once www/chromium finally finishes, I'll give poudriere > another chance at the "stragglers" (and record the results in > http://www.catwhisker.org/~david/FreeBSD/ports/rust/). > Retry appears to have worked : [00:00:16] Starting/Cloning builders [00:00:17] Hit CTRL+t at any time to see build progress and stats [00:00:17] [01] [00:00:00] Building lang/rust | rust-1.43.1 [01:00:51] [01] [01:00:34] Finished lang/rust | rust-1.43.1: Success [01:00:53] [01] [00:00:00] Building devel/rust-cbindgen | rust-cbindgen-0.14.2 [01:02:27] [01] [00:01:34] Finished devel/rust-cbindgen | rust-cbindgen-0.14.2: Success [01:02:27] [01] [00:00:00] Building www/firefox | firefox-76.0.1_3,1 [01:39:07] [01] [00:36:40] Finished www/firefox | firefox-76.0.1_3,1: Success [01:39:08] Stopping 3 builders Peace, david -- David H. Wolfskill da...@catwhisker.org "The Liar Tweets Tonight": https://www.youtube.com/watch?v=TkU1ob_lHCw See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
poudriere-devel failed to build lang/rust (rust-1.43.1)
In my environment, I have a designated "build machine" (named "freebeast"); in addition to building FreeBSD for itself and a couple of other machines, it also builds packages (via devel/poudriere-devel) for those other machines. (Each machine is amd64, running stable/12.) The other machines get weekly updates (every Sunday), so I set up freebeast to build the bulk of the packages every Saturday, then (usually) the Sunday set of packages to build is relatively small (so I can get the weekly updates done faster than if I were to wait until Sunday to build all the packages that warrant rebuilding). Details are in http://www.catwhisker.org/~david/FreeBSD/upgrade.html. Today, after building stable/12 & head, I set freebeast to building packages; a while later, Spouse and I took the tandem bike out for a ride (for about 2.5 hours). A whlie later, I noticed that freebeast was still chugging away; ^T revealed that it was building www/chromium (which was expected); it also revealed that there had been a failure (which was not): load: 8.59 cmd: sh 99503 [piperd] 35609.83r 1.23u 1.88s 0% 2156k [12amd64-ports-home] [2020-05-23_12h08m48s] [parallel_build:] Queued: 1003 Built: 999 Failed: 1Skipped: 2Ignored: 0Tobuild: 1 Time: 09:53:48 [05]: www/chromium | chromium-81.0.4044.138_1 build (03:59:48 / 04:08:53) [09:53:49] Logs: /tank/poudriere/poudriere/data/logs/bulk/12amd64-ports-home/2020-05-23_12h08m48s A quick check revealed that lang/rust was the failing port; I've dumped a copy of the poudriere log (there's a gzipped copy there, as well) and an "info.txt" file that shows things like "uname -a" output from freebeast, as well as information about ports-mgmt/poudriere-devel and the current state of the SVN working copies for src & ports. It appears (to my eye that is quite unfamiliar with rust) that the first failure in the log is: sysroot: "/wrkdirs/usr/ports/lang/rust/work/rustc-1.43.1-src/build/x86_64-unknown-freebsd/stage1" libdir: "/wrkdirs/usr/ports/lang/rust/work/rustc-1.43.1-src/build/x86_64-unknown-freebsd/stage1/lib" error: could not compile `rustc_lint`. (which shows up quite near the end of the supplied log file). Please note that the machine has been building www/firefox (and thus, lang/rust) routinely for quite some time, so this is a little surprising. Even more surprising is that my laptop, where I also have www/firefox installed, and which I update via ports-mgmt/portmaster, has rust-1.43.1 built and installed, apparently without issue (other than consuming time and generating heat). I expect that once www/chromium finally finishes, I'll give poudriere another chance at the "stragglers" (and record the results in http://www.catwhisker.org/~david/FreeBSD/ports/rust/). Peace, david -- David H. Wolfskill da...@catwhisker.org "The Liar Tweets Tonight": https://www.youtube.com/watch?v=TkU1ob_lHCw See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Bind 9.16 port error still lingers
On Sat, May 02, 2020 at 05:20:27PM +0200, Per olof Ljungmark wrote: > On 2020-05-02 17:16, The Doctor via freebsd-ports wrote: > > On Sat, May 02, 2020 at 04:32:10PM +0200, Christoph Moench-Tegeder wrote: > >> ## The Doctor via freebsd-ports (freebsd-ports@freebsd.org): > >> > >>> Subject: Bind 9.16 port error still lingers > >> > >> "Still"? > >> > >>> May 1 21:29:02 gallifrey named[90441]: Required root permissions to open > >>> '/var/run/named.pid'. > >>> May 1 21:29:02 gallifrey named[90441]: Please check file and directory > >>> permissions or reconfigure the filename. > >> > >> Did you? > >> BTW the default location for named's pidfile on FreeBSD is > >> /var/run/named/pid. I'm running bind916-9.16.2: albert(12.1-S)[3] pkg info -o dns/bind\* bind-tools-9.16.2 dns/bind-tools bind916-9.16.2 dns/bind916 Here's what I have in /etc/rc.conf about it: albert(12.1-S)[5] egrep 'bind|named' /etc/rc.conf rpcbind_enable="YES" named_enable="YES" named_program="/usr/local/sbin/named" and the pidfile is in /var/run/named/: albert(12.1-S)[4] ls -lT /var/run/named/ total 8 -rw-r--r-- 1 bind bind6 May 1 05:03:40 2020 pid -rw--- 1 bind bind 102 May 1 05:03:40 2020 session.key No issues. > Peace, david -- David H. Wolfskill da...@catwhisker.org "I believe the people of this country are smart. And I don't think that they will put a man in who's incompetent." -- Donald J. Trump, who apparently missed the irony, 29 Apr 2020. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Difference between tarball from ports and from git-archive
As I work on updating ports/games/frotz, I noticed that the file size for the distribution tarball deposited in /usr/ports/distfiles is different than what I get when using git-archive(1). What I get from git-archive(1) is exactly what I get from https://gitlab.com/DavidGriffith/frotz/-/releases/2.51, and NetBSD. Furthermore, when gunzipped, the uncompressed tar files all are 1484800 bytes long, but the FreeBSD one has a different hash than do the others. When all these tar files are unpacked and checked with diff -ru, I'm told that they're all exactly the same. What's going on here? $ ls -l total 1376 -rw-r--r-- 1 dave dave 350429 Mar 30 21:15 frotz-2.51.tar.gz.freebsd -rw-r--r-- 1 dave dave 350626 Mar 30 21:39 frotz-2.51.tar.gz.gitlab -rw-r--r-- 1 dave dave 350626 Mar 30 21:40 frotz-2.51.tar.gz.main -rw-r--r-- 1 dave dave 350626 Mar 30 21:54 frotz-2.51.tar.gz.netbsd 6e62a6b41736186f6a71952af950455e frotz-2.51.tar.gz.freebsd 49f4d1dd64315200b9923d72c2a6d082 frotz-2.51.tar.gz.gitlab 49f4d1dd64315200b9923d72c2a6d082 frotz-2.51.tar.gz.main 49f4d1dd64315200b9923d72c2a6d082 frotz-2.51.tar.gz.netbsd -- David Griffith d...@661.org A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ 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: firefox-73.0,1 error build
On Tue, Feb 04, 2020 at 03:49:39PM +0700, Alex V. Petrov wrote: > ... > In file included from > /usr/ports/www/firefox/work/.build/dist/system_wrappers/exception:3: > > > /usr/include/c++/v1/exception:180:5: error: no member named 'abort' in > namespace 'std::__1'; did you mean simply 'abort'? > _VSTD::abort(); > ^~~ > /usr/include/c++/v1/__config:759:15: note: expanded from macro '_VSTD' > > #define _VSTD std::_LIBCPP_ABI_NAMESPACE > > ^ > /usr/include/stdlib.h:86:17: note: 'abort' declared here > > _Noreturn void abort(void); > ^ > 1 error generated. > gmake[5]: *** > [/usr/ports/www/firefox/work/firefox-73.0/config/rules.mk:738: > rlbox_thread_locals.o] Error 1 > This is being tracked in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243863 Peace, david -- David H. Wolfskill da...@catwhisker.org "The Senate has abdicated its constitutional duty during the impeachment trial of President Donald Trump." -- Alan S. Frumin, parliamentarian emeritus of the US Senate See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Seeking flavors examples and advice
Would someone please point me to a simple example of FLAVORS being used to
build something in ports to select different targets.
I recently took over games/frotz for which I am also upstream. This
package can be built with three different user interfaces with one of them
having two sub-variations. There are curses-nosound, curses (uses libao
for audio output), dumb (no screen handling at all), and SDL (uses libsdl
for graphics and audio). When building straight from source, you simply
do "gmake curses", "gmake nosound", "gmake dumb", or "gmake sdl" and you
get the interface specified by the parameter supplied to gmake. I can't
seem to find any webpage that goes into any more detail than
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/flavors-using.html
and this leaves me wondering just how to even start.
Here's what I have so far: targeting noaudio and dumb for starters. I'm
leaving out documentation and examples for now until I figure this out.
Both the noaudio and dumb targets will build, but when I do "make install"
or "make FLAVOR=dumb install", nothing actually gets put into
/usr/local/bin.
# Created by: Andrey Zakhvatov
# $FreeBSD: head/games/frotz/Makefile 522166 2020-01-05 19:39:46Z tcberner $
PORTNAME= frotz
PORTVERSION=2.50
CATEGORIES= games
MAINTAINER= d...@661.org
COMMENT=Infocom Z-machine games interpreter
LICENSE=GPLv2+
LICENSE_FILE= ${WRKSRC}/COPYING
USE_GITLAB= yes
GL_ACCOUNT= DavidGriffith
GL_COMMIT= 9867a1f14da1e9c0707492d2ac74d1e8ffdd3a64
USES= gmake
FLAVORS=curses dumb
FLAVOR?=${FLAVORS:[1]}
curses_PKGNAMESUFFIX= -curses
dumb_PKGNAMESUFFIX= -dumb
curses_PLIST= bin/frotz\
man/man6/frotz.6.gz
dumb_PLIST= bin/dfrotz\
man/man6/dfrotz.6.gz
.if ${FLAVOR:U} == curses
COMMENT+= (curses interface, no audio)
ALL_TARGET= nosound
USES+= ncurses
.elif ${FLAVOR:U} == dumb
COMMENT+= (dumb interface)
ALL_TARGET= dumb
dumb_PKGNAMEPREFIX= d
.endif
MAKE_ENV= OPTS="${CFLAGS}" CONFIG_DIR="${PREFIX}/etc"
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/${PKGNAMEPREFIX}${PORTNAME}
${STAGEDIR}${PREFIX}/bin/
${INSTALL_MAN} ${WRKSRC}/doc/${PKGNAMEPREFIX}${PORTNAME}.6
${STAGEDIR}${MAN6PREFIX}/man/man6/
.include
--
David Griffith
d...@661.org
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
___
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: xterm-353
On Sun, Feb 02, 2020 at 10:36:00AM -0500, ajtiM via freebsd-ports wrote: > Update of xterm to version 253 has a problem: > > ===> License MIT accepted by the user > ===> xterm-353 depends on file: /usr/local/sbin/pkg - found > ===> Fetching all distfiles required by xterm-353 for building > => SHA256 Checksum mismatch for xterm-353.tgz. > => SHA256 Checksum OK for bsd-xterm-icons-1.tgz. > ===> Giving up on fetching files: xterm-353.tgz > Make sure the Makefile and distinfo file (/usr/ports/x11/xterm/distinfo) > are up to date. If you are absolutely sure you want to override this > check, type "make NO_CHECKSUM=yes [other args]". > *** Error code 1 > I don't see that: g1-55(12.1-S)[1] pkg info -o xterm\* xterm-353 x11/xterm g1-55(12.1-S)[2] make -C /usr/ports/x11/xterm checksum ===> License MIT accepted by the user ===> xterm-353 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by xterm-353 for building => SHA256 Checksum OK for xterm-353.tgz. => SHA256 Checksum OK for bsd-xterm-icons-1.tgz. g1-55(12.1-S)[3] uname -a FreeBSD g1-55.catwhisker.org 12.1-STABLE FreeBSD 12.1-STABLE #594 r357402M/357406: Sun Feb 2 03:44:20 PST 2020 r...@g1-55.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY amd64 g1-55(12.1-S)[4] svn info /usr/ports Path: /usr/ports Working Copy Root Path: /usr/ports URL: file:///svn/freebsd/ports/head Relative URL: ^/head Repository Root: file:///svn/freebsd/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 524937 Node Kind: directory Schedule: normal Last Changed Author: sunpoet Last Changed Rev: 524937 Last Changed Date: 2020-02-02 03:07:56 -0800 (Sun, 02 Feb 2020) g1-55(12.1-S)[5] Peace, david -- David H. Wolfskill da...@catwhisker.org McConnell's Senators are covering up their whitewash of Trump's malfeasance. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: sqlite3 update to 3.31.0 breaks firefox and thunderbird
Le 27/01/2020 à 06:06, Tobias C. Berner a écrit : This should likely be added to firefox: https://hg.mozilla.org/try/rev/8d7104bac33729b4da67954b07fb08371df39bd8 Finally, it sounds that the sqlite team will do review their API to ensure backward compatibility. https://www.sqlite.org/src/info/34ab760689fd493e : >> It turns out that some important 3rd-party software does questionable >> pointer manipulations on those filenames that depend on that legacy >> layout. Technically, this is a misuse of SQLite by the 3rd-party >> software, but we want to avoid unnecessary breakage Thanks, even if I think they are in a way being too soft in this case. -- David Marec http://poudriere.lapinbilly.eu/ ___ 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, thunderbird crash on start
On Mon, Jan 27, 2020 at 11:51:32AM -0700, Russell L. Carter wrote: > Hi folks, > On about a month old -stable amd64, recent, up-to-the minute > firefox and thunderbird are crashing on startup since yesterday, > like so: > > rcarter@feyerabend> firefox > > (firefox:5486): GLib-GIO-CRITICAL **: 11:45:26.964: g_dbus_proxy_new: > assertion 'G_IS_DBUS_CONNECTION (connection)' failed > > (firefox:5486): GLib-GIO-CRITICAL **: 11:45:26.965: g_dbus_proxy_new: > assertion 'G_IS_DBUS_CONNECTION (connection)' failed > > (firefox:5486): GLib-GIO-CRITICAL **: 11:45:26.965: g_dbus_proxy_new: > assertion 'G_IS_DBUS_CONNECTION (connection)' failed > Exiting due to channel error. > Exiting due to channel error. > zsh: segmentation fault firefox > rcarter@feyerabend> thunderbird > rcarter@feyerabend> > > Sometimes I'll get a window, that goes away immediately, mostly not. > I cleared the .mozilla .thunderbird profiles and it's not that. > > I build ports via poudriere. > See (e.g.) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243629 -- note that dropping databases/sqlite3 back to sqlite3-3.30.1 (from sqlite3-3.31.0) appears to resolve the issue; it seem sthat firefox was using a non-public interface, and that interface changed Note that databases/sqlite3 has been reverted as of ports (head) revision r524241. Peace, david -- David H. Wolfskill da...@catwhisker.org "Now, with me, there's no lying." -- Donald J. Trump ["??!?" -- me] See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: sqlite3 update to 3.31.0 breaks firefox and thunderbird
On Sun, Jan 26, 2020 at 06:35:01PM -0500, Michael Butler wrote: > Both produce core dumps related to sqlite :-( Rebuilding both doesn't > fix either. Downgrading to 3.30.1 restores normal operation, > Confirmed; thank you for the circumvention. Peace, david -- David H. Wolfskill da...@catwhisker.org "Now, with me, there's no lying." -- Donald J. Trump ["??!?" -- me] See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: chromium-79.0.3945.130 fails to build.
On Thu, Jan 23, 2020 at 09:58:17AM +1300, Jonathan Chen wrote: > Hi, > > The latest update of chromium-79.0.3945.130 is currently failing to > build on FreeBSD-12/amd64: > Please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243509 (which has a patch that allowed the build to succeed for some of us). Peace, david -- David H. Wolfskill da...@catwhisker.org What will Donald J. Trump choose as his regnal name once McConnell's whitewash fails to convict him? See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
getting Frotz 2.50 committed
I submitted an update for games/frotz at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242821. Now what? -- David Griffith d...@661.org A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ 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: How should follks migrate from linux_base-c6 to linux_base-c7?
On Tue, Dec 31, 2019 at 04:19:30PM +0100, Tijl Coosemans wrote: > ... > > | compat.linux.osrelease=2.6.18 > > This was needed when the default value was 2.4., but nowadays > the default is already higher than 2.6.18 so you can just remove this. > Besides that it's just a matter of removing c6 packages and installing c7 > packages. Excellent: thank you! Peace, david -- David H. Wolfskill da...@catwhisker.org At least Trump can count on McConnell and Putin to "have his back." And the rest of us can consider what that means about each of them. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
How should follks migrate from linux_base-c6 to linux_base-c7?
As noted in <http://docs.FreeBSD.org/cgi/mid.cgi?201912302038.xBUKcol9050658>, the -c6 ports "expire tomorrow." I don't see a documented process for migrating from linux_base-c6 to linux_base-c7; perhaps I'm being thicker than usual. For example, from prior migrations (e.g., the 20141209 entry in ports/UPDATING), there's a mention of: | 2. Persistently update the Linux kernel version in /etc/sysctl.conf: | | compat.linux.osrelease=2.6.18 and since there has (as far as I know) been no indication that that should be changed, I still have it (in stable/11, stable/12, and head). But <https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/linuxemu-lbc-install.html> does not mention a compat.linux.osrelease sysctl value at all. I had asked about the migration process Fri Sep 30 20:30:24 UTC 2016; at the time, the response was: | We are still working on the other c7 ports: | https://reviews.freebsd.org/D7886 but I have seen nothing further about the migration process itself. ports/UPDATING entry 20190710 does discuss the "c6" Linux emulation (but not "c7"). So: how should a system that has been configured to support linux_base-c6 be migrated to support linux_base-c7? Thanks. Peace, david -- David H. Wolfskill da...@catwhisker.org At least Trump can count on McConnell and Putin to "have his back." And the rest of us can consider what that means about each of them. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Frotz upgrade to 2.50
My reply is at the bottom. Please put your reply there too. On Fri, 20 Dec 2019, Marcin Cieslak wrote: On Fri, 20 Dec 2019, David Griffith wrote: With this patch applied, you get both frotz without audio support and dumb frotz. For audio, some more libraries are required, but that should not pull in anything graphical. For the graphics-capable variant of Frotz, SDL2 is needed among other things. I propose to add two additional ports entries for Frotz. One is "frotz-audio" which is simply curses Frotz with the audio subsystem compiled in and dumb Frotz along for the ride. This would be mutually-exclusive from the regular silent "frotz" entry for obvious reasons. The other would be "frotz-sdl" for the SDL interface. I don't know frotz so I have no idea what the differences are but we could decide to have more OPTIONS or FLAVOURS (pretty new facility in FreeBSD ports) if really needed. I wonder why DUMB is optional really - it does not take much to build I guess so it could always be shipped (or never if one feels so). Dumb is built optionally because that's how things evolved. I started with the separated core and curses interface, then started adding additional interfaces. Each of them is built with a different target. So "make dumb" makes dfrotz and simply "make" builds curses frotz. I see no particular reason to change the ports installer such that it doesn't install dfrotz along with regular curses frotz. To explain things, Frotz is a modern reimplementation of the Z-machine. This is a virtual machine designed by Infocom in the last 1970s to play "interactive fiction" aka "text adventures". If you've heard of games like "Zork" and "Hitchhiker's Guide to the Galaxy", that's it. Infocom ported the virtual machine to pretty much all the home computers available in the 1980s and so just had to write the game once. Their stuff was also available for the PDP10 (their development systems) and PDP11 if you knew who to ask. Nowadays, there are some new languages for making new games. Many of those new games can be found at https://ifarchive.org/ The regular curses interface is more or less what you got with the classic Infocom games. The Dumb interface doesn't bother with screen and cursor control. The experience is akin to "adventure" in the bsd games package. The Dumb interface is intended to make chatbots that play text adventures through IRC, instant messengers, etc and for use on teletypes. The SDL interface allows one to play any of the four graphical Z-machine games as intended. The can be played with the curses or dumb interfaces, but with outlines drawn where graphics should go. The SDL interface can also play all nongraphical games as well. Two of Infocom's games included sound effects. The effects are brief audio samples that play at certain parts of the game. After the demise of Infocom, the Blorb standard was proposed to allow for Ogg-vorbis compressed audio and MOD music as well as uncompressed samples. The Blorb standard describes how everything a game needs: executable, graphics, audio, and metadata can be wrapped up into a single IFF container. One can always decided to ship the tools with "all batteries included" - I don't know what the users really want. Sadly this port has no maintainer who would probably knew more. I could possibly take it over if nobody else wants to. For now, here's the patch for silent Frotz: ===cut here=== diff -ruP frotz-orig/Makefile frotz/Makefile can you add -N ? otherwise we only get: Only in frotz-orig/files: patch-src_curses_ux__audio__oss.c That's because that patch is no longer necessary. I applied the changes in that patch to upstream a few years ago. When I ran your patch, I got an empty file named patch-src_curses_ux__audio__oss.c. The build process refused to continue unless I removed that file. -- David Griffith d...@661.org A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ 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: Frotz upgrade to 2.50
My reply is at the bottom. Please put your reply there too.
On Thu, 19 Dec 2019, David Griffith wrote:
My reply is at the bottom. Please put your reply there too.
On Thu, 19 Dec 2019, Marcin Cieslak wrote:
On Thu, 19 Dec 2019, David Griffith wrote:
My reply is at the bottom. Please put your reply there too.
On Wed, 18 Dec 2019, Marcin Cieslak wrote:
On Mon, 16 Dec 2019, David Griffith wrote:
I released version 2.50 of Frotz last month. Would someone please
update ports to install this version?
I have never used that software but I gave it a try and:
* moved it to Gitlab
* applied fix for a https://gitlab.com/DavidGriffith/frotz/issues/180
* I think we do not need to generate soundcard.h manually anymore?
Now I am getting:
===> Building for frotz-2.50
gmake[2]: Entering directory
'/usr/home/saper/sw/FreeBSD/ports/games/frotz/work/frotz-9867a1f14da1e9c0707492d2ac74d1e8ffdd3a64-9867a1f14da1e9c0707492d2ac74d1e8ffdd3a64'
** Generating src/common/defs.h
** Generating src/common/git_hash.h
** ERROR UTF-8 support only works with ncursesw!
exit 2
gmake[2]: *** [Makefile:391: src/curses/ux_defines.h] Error 2
but then second "make" works just fine...
The OSS interface is deprecated for now. There's no need to go hunting
around for soundcard.h anymore in favor of libao. I've resisted removing
ux_audio_oss.c entirely because I'd like to someday reenable that for
older machines and massage it into something for older Sun workstations.
Thank you. Is there any quick way to test if sound is working?
I have a couple sound-using games that should suffice.
https://661.org/proj/if/uninvited/uninvited.zblorb
https://661.org/proj/if/oldcode/soundtest.blb
The first is a reimplementation of Uninvited
(https://en.wikipedia.org/wiki/Uninvited_(video_game)) and the second is
intended to quickly and easily test all of Frotz's audio capabilities.
What about that ncursesw thing? I think it is NetBSD-specific?
It might be. The distinction between old BSD curses and ncurses has been a
source of problems over the years. I'm puzzled as to why it would complain
there because I went over curses stuff repeatedly with all the BSDs prior to
releasing 2.50 and it still compiles fine outside of the ports system.
How is this patch supposed to be applied?
Just like as you did. Can you check if your ports tree is up to date?
The Makefile should have the following line:
# $FreeBSD: head/games/frotz/Makefile 442400 2017-06-02 15:43:42Z sunpoet $
If 442400 is a lower number, the ports tree needs updating, the way
to do it depends on the way you got it (I have used the portsnap method):
https://www.freebsd.org/doc/handbook/ports-using.html
That's the same top line that I have. I updated it with Subversion.
After fixing them by hand, I noticed that the patch zeroed out
patch-src_curses_ux__audio__oss.c instead of deleting it. That caused a
complaint from the ports Makefile. After manually deleting that, I got the
same error you did. So, now we're sort of on the same page. I'll prod at
this over the next couple days. NetBSD already has 2.50 commited. Maybe
borrowing from there will work.
I came up with a patch against the 2.44 ports entry that seems to work.
Things have considerably changed since 2.44, so simply changing lines to
point at Gitlab didn't work. The strange complaint about ncurses came
about because the CURSES variable in the Makefile no longer contains
LDFLAGS, but just a simple string: [curses|ncurses|ncursesw].
With this patch applied, you get both frotz without audio support and dumb
frotz. For audio, some more libraries are required, but that should not
pull in anything graphical. For the graphics-capable variant of Frotz,
SDL2 is needed among other things.
I propose to add two additional ports entries for Frotz. One is
"frotz-audio" which is simply curses Frotz with the audio subsystem
compiled in and dumb Frotz along for the ride. This would be
mutually-exclusive from the regular silent "frotz" entry for obvious
reasons. The other would be "frotz-sdl" for the SDL interface.
For now, here's the patch for silent Frotz:
===cut here===
diff -ruP frotz-orig/Makefile frotz/Makefile
--- frotz-orig/Makefile 2017-06-02 08:43:42.0 -0700
+++ frotz/Makefile 2019-12-20 00:15:17.440596000 -0800
@@ -1,8 +1,8 @@
# Created by: Andrey Zakhvatov
-# $FreeBSD: head/games/frotz/Makefile 442400 2017-06-02 15:43:42Z sunpoet $
+# $FreeBSD: tags/RELEASE_12_0_0/games/frotz/Makefile 442400 2017-06-02
15:43:42Z sunpoet $
PORTNAME= frotz
-PORTVERSION= 2.44
+PORTVERSION= 2.50
CATEGORIES=games
MAINTAINER=po...@freebsd.org
@@ -11,31 +11,29 @@
LICENSE= GPLv2+
LICENSE_FILE= ${WRKSRC}/COPYING
-USE_GITHUB=yes
-GH_ACCOUNT=DavidGriffith
+USE_GITLAB=yes
+GL_ACCOUNT=DavidGriffith
+GL_COMMIT= 9867a1f14da1e9c0707492d2ac74d1e8ffdd3a64
USES= gmake ncurses
-MAK
Re: Frotz upgrade to 2.50
My reply is at the bottom. Please put your reply there too. On Thu, 19 Dec 2019, Marcin Cieslak wrote: On Thu, 19 Dec 2019, David Griffith wrote: My reply is at the bottom. Please put your reply there too. On Wed, 18 Dec 2019, Marcin Cieslak wrote: On Mon, 16 Dec 2019, David Griffith wrote: I released version 2.50 of Frotz last month. Would someone please update ports to install this version? I have never used that software but I gave it a try and: * moved it to Gitlab * applied fix for a https://gitlab.com/DavidGriffith/frotz/issues/180 * I think we do not need to generate soundcard.h manually anymore? Now I am getting: ===> Building for frotz-2.50 gmake[2]: Entering directory '/usr/home/saper/sw/FreeBSD/ports/games/frotz/work/frotz-9867a1f14da1e9c0707492d2ac74d1e8ffdd3a64-9867a1f14da1e9c0707492d2ac74d1e8ffdd3a64' ** Generating src/common/defs.h ** Generating src/common/git_hash.h ** ERROR UTF-8 support only works with ncursesw! exit 2 gmake[2]: *** [Makefile:391: src/curses/ux_defines.h] Error 2 but then second "make" works just fine... The OSS interface is deprecated for now. There's no need to go hunting around for soundcard.h anymore in favor of libao. I've resisted removing ux_audio_oss.c entirely because I'd like to someday reenable that for older machines and massage it into something for older Sun workstations. Thank you. Is there any quick way to test if sound is working? I have a couple sound-using games that should suffice. https://661.org/proj/if/uninvited/uninvited.zblorb https://661.org/proj/if/oldcode/soundtest.blb The first is a reimplementation of Uninvited (https://en.wikipedia.org/wiki/Uninvited_(video_game)) and the second is intended to quickly and easily test all of Frotz's audio capabilities. What about that ncursesw thing? I think it is NetBSD-specific? It might be. The distinction between old BSD curses and ncurses has been a source of problems over the years. I'm puzzled as to why it would complain there because I went over curses stuff repeatedly with all the BSDs prior to releasing 2.50 and it still compiles fine outside of the ports system. How is this patch supposed to be applied? Just like as you did. Can you check if your ports tree is up to date? The Makefile should have the following line: # $FreeBSD: head/games/frotz/Makefile 442400 2017-06-02 15:43:42Z sunpoet $ If 442400 is a lower number, the ports tree needs updating, the way to do it depends on the way you got it (I have used the portsnap method): https://www.freebsd.org/doc/handbook/ports-using.html That's the same top line that I have. I updated it with Subversion. After fixing them by hand, I noticed that the patch zeroed out patch-src_curses_ux__audio__oss.c instead of deleting it. That caused a complaint from the ports Makefile. After manually deleting that, I got the same error you did. So, now we're sort of on the same page. I'll prod at this over the next couple days. NetBSD already has 2.50 commited. Maybe borrowing from there will work. -- David Griffith d...@661.org A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ 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: Frotz upgrade to 2.50
My reply is at the bottom. Please put your reply there too. On Wed, 18 Dec 2019, Marcin Cieslak wrote: On Mon, 16 Dec 2019, David Griffith wrote: I released version 2.50 of Frotz last month. Would someone please update ports to install this version? I have never used that software but I gave it a try and: * moved it to Gitlab * applied fix for a https://gitlab.com/DavidGriffith/frotz/issues/180 * I think we do not need to generate soundcard.h manually anymore? Now I am getting: ===> Building for frotz-2.50 gmake[2]: Entering directory '/usr/home/saper/sw/FreeBSD/ports/games/frotz/work/frotz-9867a1f14da1e9c0707492d2ac74d1e8ffdd3a64-9867a1f14da1e9c0707492d2ac74d1e8ffdd3a64' ** Generating src/common/defs.h ** Generating src/common/git_hash.h ** ERROR UTF-8 support only works with ncursesw! exit 2 gmake[2]: *** [Makefile:391: src/curses/ux_defines.h] Error 2 but then second "make" works just fine... The OSS interface is deprecated for now. There's no need to go hunting around for soundcard.h anymore in favor of libao. I've resisted removing ux_audio_oss.c entirely because I'd like to someday reenable that for older machines and massage it into something for older Sun workstations. How is this patch supposed to be applied? [dave@diemos /usr/ports/games/frotz]$ patch < frotz-freebsd.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -- |diff -ruN /usr/ports/games/frotz/distinfo ./distinfo |--- /usr/ports/games/frotz/distinfo2015-05-26 20:50:09.0 +0200 |+++ ./distinfo 2019-12-18 23:51:11.422706000 +0100 -- Patching file distinfo using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |diff -ruN /usr/ports/games/frotz/files/patch-Makefile ./files/patch-Makefile |--- /usr/ports/games/frotz/files/patch-Makefile1970-01-01 01:00:00.0 +0100 |+++ ./files/patch-Makefile 2019-12-18 23:55:18.081693000 +0100 -- Patching file patch-Makefile using Plan A... Empty context always matches. Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |diff -ruN /usr/ports/games/frotz/files/patch-src_curses_ux__audio__oss.c ./files/patch-src_curses_ux__audio__oss.c |--- /usr/ports/games/frotz/files/patch-src_curses_ux__audio__oss.c 2014-12-05 18:18:12.0 +0100 |+++ ./files/patch-src_curses_ux__audio__oss.c 1970-01-01 01:00:00.0 +0100 -- Patching file ./files/patch-src_curses_ux__audio__oss.c using Plan A... Hunk #1 succeeded at 0. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |diff -ruN /usr/ports/games/frotz/Makefile ./Makefile |--- /usr/ports/games/frotz/Makefile2017-06-02 17:43:42.0 +0200 |+++ ./Makefile 2019-12-19 00:03:18.599172000 +0100 -- Patching file Makefile using Plan A... Hunk #1 failed at 2. Hunk #2 succeeded at 11 with fuzz 2. Hunk #3 failed at 26. Hunk #4 failed at 34. 3 out of 4 hunks failed--saving rejects to Makefile.rej done -- David Griffith d...@661.org A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ 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"
Frotz upgrade to 2.50
I released version 2.50 of Frotz last month. Would someone please update ports to install this version? -- David Griffith d...@661.org A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ 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: FLAVORS for Ruby
Le 16/10/2019 à 09:02, David Demelier a écrit : Le 15/10/2019 à 18:41, Steve Wills a écrit : I disagree with the idea that we can have simply one version of Ruby in ports. Look at all the work it takes to move an app like GitLab to a new version of Ruby: https://gitlab.com/gitlab-org/gitlab-foss/issues/41825 https://gitlab.com/gitlab-org/gitlab-foss/issues/57323 I see no reason to think Ruby 2.7 will be any different. So Ruby team is lying with their versioning promise? So they say to follow semantic versioning while it's not [0] MINOR: increased every christmas, may be API incompatible Definitely not what semantic versioning defines. I finally understand why other languages gained popularity over it ;) [0]: https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/ -- Regards ___ 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: FLAVORS for Ruby
Le 15/10/2019 à 18:41, Steve Wills a écrit : I disagree with the idea that we can have simply one version of Ruby in ports. Look at all the work it takes to move an app like GitLab to a new version of Ruby: https://gitlab.com/gitlab-org/gitlab-foss/issues/41825 https://gitlab.com/gitlab-org/gitlab-foss/issues/57323 I see no reason to think Ruby 2.7 will be any different. So Ruby team is lying with their versioning promise? -- David ___ 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: FLAVORS for Ruby
Le 14/10/2019 à 18:37, Koichiro Iwao a écrit : On Tue, Sep 17, 2019 at 07:34:27AM -0400, Steve Wills wrote: Hi, On 9/17/19 2:40 AM, Mathieu Arnold wrote: What we are all trying to say is that adding flavors for ruby will have a big impact on build time and ressources required for building. If all you want is to have ruby flavors for the kicks of it, then I am glad to tell you that no, it will not be done. Now, the question is, why would someone need to have ruby flavors? The answer cannot be "because it should be fun" or "there is no reason there should not be". Give us a real reason about why it would be required. We have multiple versions of Ruby, we should provide the gems for each version. Right now, there is no way for users of Ruby 2.4 to install gem packages except to change the default ruby and then build their own packages. We want people to have fewer reasons to build their own packages, not more. We keep the latest Ruby as not default because it tends to have more bugs and gems lag, and the older version of Ruby is available because some gems tend to lag really badly. So, users do have legitimate reasons for using the non-default versions of Ruby. Also, upstream supports latest and two versions back. It wasn't until Ruby 2.6 was out that GitLab even supported 2.5, to give just one example. So, we have those versions of Ruby, and they should be usable, and that includes installing gems via pkg. There's the point that maybe we should only package gems that are needed by other things, which I can understand, but don't know if I necessarily agree with, because then you have users confused on what the "right" way to install a gem is. "Oh, this one is packaged because something else in ports needs it, so use the pkg, but this other one isn't packaged, so you have to use gem." And I'd think the same applies to python modules or perl modules, etc. One could ask, why not provide flavors for all versions of python, that is, 3.5, 3.6 and 3.7, along with the 2.7 ones as well, but to me that doesn't seem quite necessary because the compatibility is better there, as far as I can tell. But, I wouldn't be opposed to it personally, if someone did make the argument in favor of it. Same with Perl and especially things that depend on Java. But that's all beside the point, really. Steve Hello again everyone, I'm sorry I cannot express my thoughts correctly in English and I clould not explain why flavors for Ruby required but swills explained far better than me. Based on his explanation, will it be a valid reason to introduce flavors on Ruby ports? Ruby use semantic versioning since version 2.1.0, unless there is Ruby 3 version release there is no reason to have flavors in FreeBSD for Ruby. Also, I don't even understand why there is several Ruby version in the ports tree since Ruby 2.6 is (as guaranteed by semantic versioning) retro compatible with 2.5, 2.4 and so on. Ports ruby24, ruby25 should be deleted. ___ 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: FLAVORS for Ruby
Le 17/09/2019 à 08:40, Mathieu Arnold a écrit : What we are all trying to say is that adding flavors for ruby will have a big impact on build time and ressources required for building. If all you want is to have ruby flavors for the kicks of it, then I am glad to tell you that no, it will not be done. Now, the question is, why would someone need to have ruby flavors? I second this. Ruby follows semantic versioning since 2.1.0 so there is no need to have flavors until they do a major release that breaks the compatibility. -- David ___ 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: [Circumvented] Problem updating gimp-app-2.10.12_2,1 to gimp-app-2.10.12_3,1
On Mon, Sep 02, 2019 at 01:34:50PM +0200, Walter Schwarzenfeld wrote: > Try recompile graphics/libspiro. > Thanks. As noted, I did (along with graphics/gegl), and that appears to have circumvented the problem. I wrote the note so that others might make use of my experience: the issue is resolved for me. Peace, david -- David H. Wolfskill da...@catwhisker.org "I am the Chosen One!" -- Donald Trump [Cf. Mt 24:23-24; Mk 13:21-23; Jn 5:31] See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
[Circumvented] Problem updating gimp-app-2.10.12_2,1 to gimp-app-2.10.12_3,1
aphics/libspiro, or graphics/gegl -- possibly involving port options; here are the options I have for each: g1-49(11.3-S)[15] foreach p ( graphics/gimp-app graphics/libspiro graphics/gegl ) foreach? echo $p && make -C $p showconfig; echo "" foreach? end graphics/gimp-app ===> The following configuration options are available for gimp-app-2.10.12_3,1: AA=on: Ascii-art Plug-in GHOSTSCRIPT=on: Ghostscript support LIBHEIF=off: ISO/IEC 23008-12:2017 HEIF file format support LIBMNG=on: MNG animated images support via libmng OPENEXR=on: HDR image format support via OpenEXR OPENJPEG=on: Enhanced JPEG (jpeg2000) graphics support SIMD=on: Use CPU-specific optimizations WEBP=on: WebP image format support WMF=on: Windows Metafile image format support ===> Use 'make config' to modify these settings graphics/libspiro graphics/gegl ===> The following configuration options are available for gegl-0.4.16_2: CAIRO=on: Cairo graphics library support ENSCRIPT=off: Enscript support EXAMPLES=on: Build and/or install examples FFMPEG=off: FFmpeg support (WMA, AIFF, AC3, APE...) GEXIV2=off: EXIF and IPTC metadata support via gexiv2 GRAPHVIZ=on: Graphviz graph drawing support JASPER=on: JPEG 2000 support via JasPer LCMS2=on: Little CMS 2.x support LIBRSVG2=on: SVG vector graphics support via librsvg2 LUA=on: Lua scripting language support OPENEXR=on: HDR image format support via OpenEXR PANGO=on: Pango rendering library support PIXBUF=on: GDK-PixBuf library support POPPLER=on: PDF and PS file support via poppler RAW=on: RAW format support SDL=on: Simple Direct Media Layer support SPIRO=on: Spiro support TIFF=on: TIFF image format support V4L=on: Video 4 Linux support WEBP=on: WebP image format support ===> Use 'make config' to modify these settings g1-49(11.3-S)[18] Peace, david -- David H. Wolfskill da...@catwhisker.org "I am the Chosen One!" -- Donald Trump [Cf. Mt 24:23-24; Mk 13:21-23; Jn 5:31] See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: devel/llvm80 build blocked by "graphics/py-imagesize@py27 | py27-imagesize-1.1.0: Failed: fetch"
On Tue, Jul 23, 2019 at 01:28:46PM -0700, Mark Millard via freebsd-ports wrote: > I'm unclear on why devel/llvm80 depends on graphics ports, but > after 'svnlite update -r507241 /usr/ports' (not having updated > in some time), my poudriere bulk run reported: > > [00:23:50] [26] [00:10:36] Finished graphics/py-imagesize@py27 | > py27-imagesize-1.1.0: Failed: fetch > [00:23:50] [26] [00:10:36] Skipping devel/llvm80 | llvm80-8.0.1: Dependent > port graphics/py-imagesize@py27 | py27-imagesize-1.1.0 failed > [00:23:50] [26] [00:10:36] Skipping textproc/py-recommonmark@py27 | > py27-recommonmark-0.5.0_1: Dependent port graphics/py-imagesize@py27 | > py27-imagesize-1.1.0 failed > [00:23:50] [26] [00:10:36] Skipping textproc/py-sphinx@py27 | > py27-sphinx-1.6.5_2,1: Dependent port graphics/py-imagesize@py27 | > py27-imagesize-1.1.0 failed > [00:23:50] [26] [00:10:36] Skipping devel/xtoolchain-llvm80 | > xtoolchain-llvm80-0.1: Dependent port graphics/py-imagesize@py27 | > py27-imagesize-1.1.0 failed > Well, for me, I see: g1-49(11.3-S)[491] make -C /usr/ports/devel/llvm80 all-depends-list | grep -i imagesize /common/ports/graphics/py-imagesize g1-49(11.3-S)[492] ... so, yeah, it seems to be required. And the fetch (of the distfile(s) is what failed. You could try fetching the distfile(s) manually, perhaps. If nothing else, that might provide some hints as to the nature of the failure. Peace, david -- David H. Wolfskill da...@catwhisker.org "Examples of potentially unlawful conduct include ... comments like, 'Go back to where you came from,' whether made by supervisors or ..." - EEOC See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: ffmpeg port
Le 12/07/2019 à 01:17, Adam Weinberger a écrit : We really would love to be able to provide release or LTS branches, but it simply comes down to resources. We'd need a few people working in paid positions to manage RE environments. The FreeBSD Foundation (which underwrites a couple very selective paid positions) has prioritized development of new technologies to keep FreeBSD competitive over third-party software backporting. Hello Adam, I'm not sure how can a LTS branch that you usually never update (except CVE, security fixes) take more time than quarterly branches that you need to recreate every 3 months and do some merges. Basically, a LTS branch stay in marble for a release lifetime and will only contain sporadic commits for security fixes or vulnerabilities. That's mostly what Slackware does for a release version. For someone who wants bleeding edge, they use slackware-current. Regards, -- David ___ 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: ffmpeg port
Le 10/07/2019 à 13:59, Jan Beich a écrit : Why not use binary packages? Or why not build a quarterly branch? Or does anyone have better ideas? Unfortunately quarterly branches do not solve anything. They are just to short to have any benefit. Let say you build a package in January and then you don't touch your system for a while. In September, you realize you need another port but your local ports also have vulnerabilities. Now you have to update by changing the quarterly branch since others are no longer maintained. Then, you may have some local ports that will be upgraded to a major version which can be undesired for a production server. This happened to me a while ago when I had to run an old version of nodejs for an old version of etherpad, after an upgrade the new nodejs version was no longer compatible and I needed to install node6 port quickly (hopefully it was available !). This can be very frustrating since FreeBSD is a rock solid server OS that comes with strong compatibility conventions in releases versions but provides a ports tree in a rolling release fashion that do not match the base version (unlike OpenBSD does). Then you have to carefully check each time you need to update your ports that you won't break your system (like many do with Arch, Gentoo, etc). IMHO, FreeBSD definitely requires a per-RELEASE branches of ports that contain only bugfixes/security fixes. -- David ___ 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"
PR236858 – [NEW PORT] www/grafana6: Dashboard and graph editor for multiple data stores
HiAny commiter care to look athttps://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236858 ?Seems to be tested and working. RegardsDavid ___ 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: Cleaning up pkg-message
Le 10/06/2019 à 11:13, David Demelier a écrit : I've also proposed an idea to remove all fancy styles from those messages especially because their are not uniformized. One answer to my proposal : https://marc.info/?l=freebsd-ports=127731211606211=2 ___ 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: Cleaning up pkg-message
Le 08/06/2019 à 20:11, Adam Weinberger a écrit : Hello everyone, I want to get some stakeholder input on our pkg-message files. I think we need to have a clear policy about what does and doesn't belong in them, and I'd like to get your input. pkg-message is shown to every user on every install. UPDATING is only shown when users run `pkg updating` *and* /usr/ports/UPDATING exists. I suspect that only a small proportion of users do that. pkg-message needs to contain only highly relevant information. Many, many ports have messages with irrelevant information that users are likely to get message fatigue and ignore them entirely. I don't want to pick on Joe Barbish, because his work is absolutely fantastic, but dns/dns2blackhole/pkg-message is an example of a giant message that tells users to do the same thing they always do for any port: dns2blackhole Malware Prevention through Domain Blocking (Black Hole) Issue "man dns2blackhole" For configuration and usage information We now have the ability to specify messages that appear on initial install, or on upgrades from/to specific version. So here is what I propose as policy: pkg-message must contain only information that is vital to setup and operation, and that is unique to the port in question. Setup information should only be shown on initial install, and upgrade instructions should be shown only when upgrading to the relevant version. All committers have blanket approval to constrain existing messages to install/upgrade ranges using the UCL format specifications. Message pruning falls under the blanket approval as well, but committers are encouraged to get maintainer input beforehand. <<< What are your thoughts? # Adam I've also proposed an idea to remove all fancy styles from those messages especially because their are not uniformized. Unfortunately it didn't get much attention saying that it's not a real necessity to work on changing this just for aesthetic purposes. But if we start making a policy on that, could be nice to include this too. Regards -- David ___ 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: Cleaning up pkg-message
On Sat, Jun 08, 2019 at 12:11:57PM -0600, Adam Weinberger wrote: > Hello everyone, > > I want to get some stakeholder input on our pkg-message files. I think > we need to have a clear policy about what does and doesn't belong in > them, and I'd like to get your input. > > pkg-message is shown to every user on every install. UPDATING is only > shown when users run `pkg updating` *and* /usr/ports/UPDATING exists. > I suspect that only a small proportion of users do that. Well, for folks who install pre-built packages, probably. For those of us who -- for at least some systems -- build from ports locally, I'm less confident: I check it for relevant entries that have been added since last time I updated installed ports on my laptop or local build machine (which is daily) or my work desktop (which is weekly). Mind, its utility falls a bit short of the mark: ref. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227193 > pkg-message needs to contain only highly relevant information. Many, > many ports have messages with irrelevant information that users are > likely to get message fatigue and ignore them entirely. I don't want > to pick on Joe Barbish, because his work is absolutely fantastic, but > dns/dns2blackhole/pkg-message is an example of a giant message that > tells users to do the same thing they always do for any port: > > > dns2blackhole > >Malware Prevention through Domain Blocking (Black Hole) > >Issue "man dns2blackhole" For configuration and usage information > > > > We now have the ability to specify messages that appear on initial > install, or on upgrades from/to specific version. So here is what I > propose as policy: > > >>> > pkg-message must contain only information that is vital to setup and > operation, and that is unique to the port in question. Setup > information should only be shown on initial install, and upgrade > instructions should be shown only when upgrading to the relevant > version. All committers have blanket approval to constrain existing > messages to install/upgrade ranges using the UCL format > specifications. Message pruning falls under the blanket approval as > well, but committers are encouraged to get maintainer input > beforehand. > <<< > > What are your thoughts? > No objections, and de-cluttering seems like a pretty good idea. (At least you didn't insert a requirement that any such messages must "spark joy." :-) ) Peace, david -- David H. Wolfskill da...@catwhisker.org "...including Mars (of which the Moon is a part)" -- Donald J. Trump See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Is there a way to build only the port from source, and install dependencies from packages with the make command?
On Tue, Apr 30, 2019 at 10:35:21AM -0700, Yuri wrote:
> Sometimes instructions to build some port from source are needed. "cd
> /usr/ports/{caregory}/{port-name} && make" rebuilds everything from
> source, including dependencies.
>
> Is there an easy way to make it install missing dependencies with pkg,
> without listing them? I couldn't find such feature.
>
I won't claim it's especially "easy," but within the port directory --
prior to attempting to build the port -- one can run:
make missing
to find out what dependencies are needed. Given that list, one could
conceivably install the requisite packages.
Caveat: I have not actually done this.
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Mr. Trump: "'very fine people' do not attend neo-Nazi rallies." - Nicole Hemmer
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
Re: irc/ngircd: typo in Makefile
Le 15/04/2019 à 21:09, Serpent7776 a écrit : Hello, I've just stumbled upon a possible typo in Makefile: DEBUG_CONFIGURE_EBABLE=¦¦ debug Shouldn't this be ENABLE instead of EBABLE? Hello, Indeed it is, would you mind sending a patch on https://reviews.freebsd.org? Or at least, file a bug in https://bugs.freebsd.org/bugzilla. Regards, -- David ___ 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 you maintain which are out of date
[Recipient list trimmed -- dhw] On Sun, Mar 17, 2019 at 11:10:02AM +, Dima Pasechnik wrote: > Here is an email from portscout I got today - is it sent in error, as > I have nothing to do with the port mentioned there (and I do not > maintain any ports), and it's not directed to me, but to the whole > mailing list? portscout sends messages to port maintainers. The "port maintainer" for ports that lack an explicit maintainer is the mailing list, freebsd-ports@freebsd.org (which has an alias of "po...@freebsd.org"). > ... Peace, david -- David H. Wolfskill da...@catwhisker.org "Saying 'I'm sorry I got caught' is not an inspiring plea for leniency." See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: vim - GTK2 or GTK3?
Le 20/02/2019 à 08:16, Kevin Oberman a écrit : On Tue, Feb 19, 2019 at 4:26 AM David Demelier <mailto:mark...@malikania.fr>> wrote: Le 19/02/2019 à 04:44, Jan Beich a écrit : > Adam Weinberger mailto:ad...@adamw.org>> writes: > >> I'm curious whether the default Vim port should use GTK2 or GTK3 as >> its UI toolkit, but I use neither so I need input from people here. >> >> Right now it defaults to GTK2, but I'm suspecting that more people use >> GTK3 these days. I haven't run X in about 10 years, so I don't really >> know one way or the other. If anybody on this list has thoughts about >> GTK2 vs GTK3 (or something else!) as the default, I'd love to hear it. Gtk2 is deprecated and does not support high DPI displays, so it's already a reason to not use it anymore. -- David When did that happen? I run Mate desktop which is gtk2 based as are a great many ports. Deprecated does not mean it does not work :) It just means it don't get bugfixes and that it should not be used in new code. Regards ___ 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: vim - GTK2 or GTK3?
Le 19/02/2019 à 04:44, Jan Beich a écrit : Adam Weinberger writes: I'm curious whether the default Vim port should use GTK2 or GTK3 as its UI toolkit, but I use neither so I need input from people here. Right now it defaults to GTK2, but I'm suspecting that more people use GTK3 these days. I haven't run X in about 10 years, so I don't really know one way or the other. If anybody on this list has thoughts about GTK2 vs GTK3 (or something else!) as the default, I'd love to hear it. Gtk2 is deprecated and does not support high DPI displays, so it's already a reason to not use it anymore. -- David ___ 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: Resolving ports conflicts for ImageMagick6
On Sun, Nov 18, 2018 at 09:43:39AM -0800, bob prohaska wrote: > In trying to bring inkscape up to date on r340487 the process > is getting stuck with > > ===> Registering installation for ImageMagick6-6.9.10.14,1 as automatic > Installing ImageMagick6-6.9.10.14,1... > pkg-static: ImageMagick6-6.9.10.14,1 conflicts with ImageMagick-6.9.9.28_2,1 > (installs files into the same place). Problematic file: > /usr/local/bin/Magick++-config > *** Error code 70 > > The problem seems to have its origin in the rename of the imagemagick > port mentioned in /usr/ports/UPDATING for November 10th. > > How does one work past a problem like this? > > Thanks for reading, > > bob prohaska > . I did so via "pkg delete -f graphics/ImageMagick". (After following that with "portmaster -ad", I ran "pkg_libchk" to see what other prts might need attention, then used portmaster to re-install them.) Peace, david -- David H. Wolfskill da...@catwhisker.org Possible defense against a "perjury trap" for Trump: Tell the truth. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: FreeBSD Port: firefox-63.0.1,1 multiple errors build
[Recipient list trimmed -- dhw] On Thu, Nov 01, 2018 at 08:54:16AM +0100, Stefan Esser wrote: > ... > > For reliable port builds, you need use port builders that use clean > > environments; ie poudriere or synth > > True, but we used to make ports build with a previous version installed, > whenever possible. Quite so. > The problems are generally caused by the build process > picking up include files or libraries from LOCALBASE instead of from the > port's source directory. Seems likely. > I'd expect a port maintainer to check for easy fixes to such build problems. :-} > Maybe we should add a port variable that is true if a port conflicts with > earlier versions of itself. That would indicate to port build tools like > portmaster or portupgrade that the old version should be deleted before > starting the build of the new version (and to re-install the old version > if the build of the new one fails). I would welcome such a thing: it's annoying to need to manually "pkg delete lang/rust" every time rust needs an update. > E.g.: > > CONFLICTS_WITH_ITSELF=yes > > I'd be willing to integrate support for such a functionality into portmaster, > if it was accepted in the ports framework. And I would be quite happy to use it. > Regards, STefan > > PS: And yes, there are good reasons to keep support for tools that are > lighter-weight than poudriere and more portable than synth in the > ports system. > ... :-) Peace, david -- David H. Wolfskill da...@catwhisker.org Support the US Constitution: restrain Donald Trump. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Silent failure of 'pkg upgrade'
Since July, 2015, I have been updating my "production" machines here at home on a weekly basis; for the ports/packages phase of this, I have been using poudriere (on a dedicated "build machine") to build packages for the production machines. Overall, this approach has been working quite well. Thus, I was rather surprised to find after this morning's update that the packages had actually not been updated at all. Reviewing the typescript, I see that sailent parts of it read: ... Checking integrity... done (0 conflicting) The following 47 package(s) will be affected (of 0 checked): Installed packages to be REMOVED: webkit-gtk2-2.4.11_17 webkit2-gtk3-2.20.5 gvfs-1.30.4 gnome-online-accounts-3.28.0 libgdata-0.17.9 Installed packages to be UPGRADED: tmux: 2.7 -> 2.8 tesseract: 3.05.02_2 -> 3.05.02_3 sqlite3: 3.25.1 -> 3.25.1_1 spidermonkey52: 52.8.0_1 -> 52.8.0_2 qtchooser: 39 -> 66 qt5-core: 5.11.2 -> 5.11.2_1 python36: 3.6.6_1 -> 3.6.7 py27-openssl: 17.5.0_1 -> 18.0.0 py27-libxml2: 2.9.7 -> 2.9.7_1 py27-gimp: 2.8.22_1 -> 2.10.6_1 portmaster: 3.19_15 -> 3.19_18 pkgconf: 1.5.3,1 -> 1.5.4,1 pciids: 20180921 -> 20181027 nss: 3.39 -> 3.40 netpbm: 10.83.02 -> 10.84.02 net-snmp: 5.7.3_18 -> 5.7.3_19 neon: 0.30.2_3 -> 0.30.2_4 mesa-dri: 18.1.9 -> 18.1.9_1 llvm60: 6.0.1_2 -> 6.0.1_3 linux-c6: 6.9_1 -> 6.10_1 libdvdcss: 1.4.1 -> 1.4.2 icu: 62.1_2,1 -> 63.1,1 help2man: 1.47.7 -> 1.47.8 harfbuzz-icu: 2.0.0 -> 2.0.2_1 harfbuzz: 2.0.0 -> 2.0.2 gtk-doc: 1.28 -> 1.29 gpgme: 1.11.1 -> 1.12.0 glib: 2.56.1_1,1 -> 2.56.1_2,1 gimp-app: 2.8.22_1,1 -> 2.10.6_1,1 gimp: 2.8.22,2 -> 2.10.6,2 freeglut: 3.0.0_1 -> 3.0.0_2 firefox: 62.0.3,1 -> 63.0_3,1 ffmpeg: 4.0.2_5,1 -> 4.0.2_7,1 dovecot: 2.3.3 -> 2.3.3_2 ca_root_nss: 3.39 -> 3.40 boost-libs: 1.68.0_1 -> 1.68.0_2 bind911: 9.11.4P2 -> 9.11.5 apr: 1.6.3.1.6.1_1 -> 1.6.5.1.6.1 apache24: 2.4.35 -> 2.4.37 Installed packages to be REINSTALLED: nut-2.7.4_8 (options changed) linux-c6-qt47-webkit-4.7.2_4 (direct dependency changed: linux-c6-qt47-x11) gimp-gutenprint-5.2.14 (needed shared library changed) Number of packages to be removed: 5 Number of packages to be upgraded: 39 Number of packages to be reinstalled: 3 The operation will free 121 MiB. Proceed with this action? [y/N]: y ... [17/47] Upgrading gimp-app from 2.8.22_1,1 to 2.10.6_1,1... [17/47] Extracting gimp-app-2.10.6_1,1: 0%^M[17/47] Extracting gimp-app-2.10.6_1,1: 0%^M[17/47] Extracting gimp-app-2.10.6_1,1: 1%^M[17/47] Extracting gimp-app-2.10.6_1,1: 2%^M[17/47] Extracting gimp-app-2.10.6_1,1: 3%^M[17/47] Extracting gimp-app-2.10.6_1,1: 4%^M[17/47] Extracting gimp-app-2.10.6_1,1: 5%^M[17/47] Extracting gimp-app-2.10.6_1,1: 6% pkg: Fail to create temporary file: /usr/local/libexec/gimp/2.2/plug-ins/align-layers/.align-layers.pD2NdeK0jYaA:Not a directory ^M[17/47] Extracting gimp-app-2.10.6_1,1: 100% Command exit status: 0 Script done on Sun Oct 28 05:34:25 2018 [For those who may be curious: I circumvented the problem -- once I discovered its existence -- by deleting the graphics/gimp* packages, re-issuing "pkg upgrade", then installing graphics/gimp.] I'm a little(!) concerned, though, that pkg would encounter an issue that caused it to completely fail to perform what it had been doing, and then exit with a status of 0. Am I missing something that others would find obvious, here? (I thought a reality check might be in order before filing a bug report.) Thanks. Replies directed to the list: I'm subscribed. Peace, david -- David H. Wolfskill da...@catwhisker.org Women (and decent men): vote against supporters of Trump's misogyny! See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: emulators/i386-wine-devel
On Sunday, 16 September 2018 23:51:01 SAST Rozhuk Ivan wrote: > On Sat, 15 Sep 2018 10:06:01 +0200 > Thanks! > I already subscribe to this and post few comments. > I have no choice - I need wine to few win programs. Is the current version of i386-wine(-devel) not working for you? I understand that these are become quite old version. I'm hoping that we can complete the lib32 work (and then the WOW64 patch) before things become too stale. Regards signature.asc Description: This is a digitally signed message part.
Re: emulators/i386-wine-devel
On Saturday, 01 September 2018 22:45:58 SAST Rozhuk Ivan wrote: > Hi! Hi > What happen with emulators/i386-wine-devel ? Honestly, I've lost interest in compiling the port. I'm working on a means to avoid manual compilation [1][2]. I've attached the scripts I use to build and update the ports - if anyone is interested. > I use it on FreeBSD 11.2 x64 to run old win32 apps. The above mentioned work will also make running win64 apps concurrently with win32 apps. Regards [1] https://reviews.freebsd.org/D14721 [2] https://reviews.freebsd.org/D16830 signature.asc Description: This is a digitally signed message part.
Re: x11/nvidia-driver no longer works under -current (r338323)
On Sun, Aug 26, 2018 at 09:12:05PM +1000, Kubilay Kocak wrote: > ... > > It fails here: > > Hi John, > > It fails earlier, can you find and paste the 'error: ' line(s) ? > I expect the observed failure is related to the message Alan Cox sent yesterday: | Subject: Re: nvidia-driver build error (last ports, FreeBSD-HEAD) | From: Alan Cox | Message-ID: <4a20ff49-9dc7-736f-9339-2bbbfae1e...@rice.edu> | Date: Sat, 25 Aug 2018 14:48:55 -0500 | | ... | The last change in this series has been committed to HEAD. With that | change, you will want to remove the first argument, which should be an | arena pointer, from kmem_free() calls. | | Alan Peace, david -- David H. Wolfskill da...@catwhisker.org Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300 See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: nvidia-driver build error (last ports, FreeBSD-HEAD)
On Tue, Aug 21, 2018 at 04:41:42PM +0700, Alex V. Petrov wrote: > I also encountered this, but with x11/nvidia-driver-340. Some additional information: * I did not encounter the issue on stable/11 (as of r338124). * In head, I did not have a problem as recently as @r338094. * In head, where I did have a problem, it was @r338130. It looks to me as if this may be collateral damage from r338107. Peace, david -- David H. Wolfskill da...@catwhisker.org Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300 See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: After mutt-1.10.0_1 -> mutt-1.10.1 upgrade, gnupg fails
On Fri, Jul 20, 2018 at 05:52:51AM -0700, David Wolfskill wrote: > > A symptom is that an attempt to send a signed, unencrypted message > yields a failure, with the messages: > > | gpg: skipped "0x6757003D": Unusable secret key > | gpg: signing failed: Unusable secret key > I found a way to get mutt-1.10.1 to work for me (as long as I disable the use of gpgme): unset pgp_check_gpg_decrypt_status_fd in ~/.muttrc. Peace, david -- David H. Wolfskill da...@catwhisker.org Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300 See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
After mutt-1.10.0_1 -> mutt-1.10.1 upgrade, gnupg fails
This is running: FreeBSD g1-215.catwhisker.org 11.2-STABLE FreeBSD 11.2-STABLE #685 r336523M/336541:1102501: Fri Jul 20 03:40:05 PDT 2018 r...@g1-215.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY amd64 and after updating all installed ports to reflect the ports "head" branch at r475002. A symptom is that an attempt to send a signed, unencrypted message yields a failure, with the messages: | gpg: skipped "0x6757003D": Unusable secret key | gpg: signing failed: Unusable secret key This works on another machine (the one I'm using to send this message), with the same gnupg/mutt setup, but running mutt-1.10.0_1. I have not configured mutt to use gpgme, though I'm willing to try it. I recall that I needed to tweak ~/.muttrc a bit after the gnupg-2.0 -> gnupg-2.1 update -- though that change was merely commenting out the 'pgp_verify_command' line. I note that a result of the mutt upgrade is that /usr/local/share/examples/mutt/gpg.rc has changed, but that change was merely to remove the pgp_decryption_okay setting (which I don't have) and add 'set pgp_check_gpg_decrypt_status_fd'; I tried adding that, to no avail. Any hints or suggestions? Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org Trump is providing aid and comfort to a regime that is hostile to US interests. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Battle for wesnoth
Hello, Some days ago, the port games/wesnoth was removed from my poudriere builds, because of boost libraries mismatches I guess. So that, I decided to port a newer version of the game (1.14.%) to FreeBSD. If the port "works for me", it 'be better to provide a port-tree compliant installation. If I'm running FreeBSD for years, it's the first time I am writing a Makefile for the port tree. Thanks to the porters-handbook, (and the original wesnoth Makefile) I was able to write a Makefile and provides a couple of patches. One can find the files below: https://gitlab.com/TurtleCrazy/wesnoth_1_14_freebsd Now, as a beginner, I have some questions regarding the Makefile to be included in the port tree. First, the CMake file provides one option to disable the installation of the game itself. This might be use to run game servers only. It also avoid the installation of SDL2 libs. This option was not defined on the previous port, so I wonder if there is a need for it. It could be done by adding the following lines: GAME_DESC=The game client GAME_CMAKE_OFF=-DENABLE_GAME=off GAME_USE_SDL= image2 mixer2 net2 ttf2 sdl2 Second, the pkg-plist is missing. - what makes poudriere testport to fail. - I did not find suitable information in the handbook that explains how to fill it. Any clue may be helpful. Next, some sets of options requires additional boost libraries. as * unit_test_framework * iostreams program_options regex system thread random The Makefile need some reworks to allow fine-grained dependencies Finally, what about the entry name in the port tree ? Feel free to correct the code, moreover: be "-pedantic". regards, -- David Marec https://lapinbilly.eu/ ___ 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: unreliable pkg upgrade of pecl / pear packages after flavors
On Tue, Apr 03, 2018 at 01:59:50PM +0200, Mathieu Arnold wrote: > On Mon, Apr 02, 2018 at 10:14:06PM +0200, Miroslav Lachman wrote: > > UPDATING entry says it should be upgraded automatically but it was not. > > > > "People using Poudriere 3.2+ and binary packages do not have to do > > anything." > > M, well, this sentence is partly right, and partly wrong. > > If you install a PHP app, say wordpress, you do not have anything to do > because pkg will install the new pecl package and remove the old ones. > > On the other hand, if you install php/pear/pecl ports manually, you do > have to rename them. > > I will update the UPDATING entry. > How would someone performing only binary package updates know to look at ports/UPDATING, and how would that be done? Such an installation may well not have /usr/ports at all. Mind, there is useful information in ports/UPDATING, some of which applies at least as well to binary package updates -- e.g., the 20180401 entry re. mail/dovecot and mail/dovecot-pigeonhole, which mentions: | Modify your Dovecot conf.d/ files before spinning up 2.3.1. The | upgrading instructions are detailed here: | | https://wiki2.dovecot.org/Upgrading/2.3 Perhaps I'm missing something obvious Peace, david -- David H. Wolfskill da...@catwhisker.org An investigator who doesn't make a perp nervous isn't doing his job. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Perl version change and ports/UPDATING
On Sat, Mar 31, 2018 at 04:23:54PM -0700, Kevin Oberman wrote: > On Sat, Mar 31, 2018 at 7:25 AM, David Wolfskill <da...@catwhisker.org> > wrote: > ... > > But "pkg updating -i" fails to display the 20180330 entry for me; > > it does show entries for some(?) other ports I have installed: > ... > > Is the above a demostration of a problem with "pkg updating"? > > Something else? > ... > I suspect thre issue is the handing of the wildcard (lang/perl5*). Either > it's a bug or wildcards should not be allowed in UPDATING. There are LOTS > of entries with asterisks, though, ome rather more complex such as: > 20180308: > AFFECTS: */php* */pecl* */pear* > BTW, that one should show up in "pkg updating -i" and does not, either. > I finally(!) got around to unpacking the distribution files for pkg-1.10.5; looking at src/updating.c, "pkg updating" uses either strcasestr() or strstr() (depending on whether or not -i is specified) for matching the origins of installed ports against the "AFFECTS" lines in ports/UPDATING. I see no code that would support anything other than literal string matches -- no attempts to specify/use meta-characters; no globs; no regular expressions. Peace, david -- David H. Wolfskill da...@catwhisker.org An investigator who doesn't make a perp nervous isn't doing his job. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Perl version change and ports/UPDATING
While the actual change to the Perl version works fine for me, I find that invoking "pkg updating" fails to display the 20180330 ports/UPDATING entry. I got lucky, because I found out about the change a different way. I maintain /usr/ports as an SVN working copy, using a local private mirror (updated nightly): g1-215(11.1-S)[1] svn info /usr/ports/ Path: /usr/ports Working Copy Root Path: /usr/ports URL: file:///svn/freebsd/ports/head Relative URL: ^/head Repository Root: file:///svn/freebsd/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 466037 Node Kind: directory Schedule: normal Last Changed Author: mandree Last Changed Rev: 466037 Last Changed Date: 2018-03-31 03:08:17 -0700 (Sat, 31 Mar 2018) g1-215(11.1-S)[2] The 20180330 entry does exist in /usr/ports/UPDATIMG: g1-215(11.1-S)[2] grep -i -B 2 -A 2 perl /usr/ports/UPDATING | head 20180330: AFFECTS: users of lang/perl5* AUTHOR: m...@freebsd.org The default Perl version has been switched to Perl 5.26. If you are using binary packages to upgrade your system, you do not have anything to do, pkg upgrade will do the right thing. For the other people, follow the -- g1-215(11.1-S)[3] I have Perl installed: g1-215(11.1-S)[3] pkg info -o perl5\* perl5-5.26.1 lang/perl5.26 g1-215(11.1-S)[4] But "pkg updating -i" fails to display the 20180330 entry for me; it does show entries for some(?) other ports I have installed: g1-215(11.1-S)[4] pkg updating -i | head 20180319: AFFECTS: users of dns/dnsmasq AUTHOR: mand...@freebsd.org Note that with dnsmasq 2.79, some parts of the interface have changed in an incompatible way versus previous versions. This comprises changed recursion behaviour, signature support, a change for SIGINT (vs. SIGHUP) behaviour. Note especially that dnsmasq will no longer answer non-recursive queries unless it is marked authoritative! Be sure to see the manual page for the g1-215(11.1-S)[5] Is the above a demostration of a problem with "pkg updating"? Something else? Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org An investigator who doesn't make a perp nervous isn't doing his job. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Mono 5.2 patch and DotNet Core 2 update
On Wednesday, 10 January 2018 08:55:45 Russell Haley wrote: > Hi David, > > I've successfully built mono based on a modified version of your patch > from here: https://reviews.freebsd.org/D13752 > > I'm getting size and checksum errors for the file > dotnet-roslyn-322bd5b_GH0.tar.gz. This shouldn't be an issue: I > changed the size of the file in distinfo from 22058493 to the actual > size I received of 22058637 in order to make it build. My expectation > is that I should then run make checksum to fix the distinfo file > correctly. I run sudo make checksum and the target goes into an > infinite loop downloading the file, deciding it doesn't match the > checksum and then downloading it again. WTH? > > I am unsure how to proceed. The porters handbook is quite explicit > that this is the way forward: > https://www.freebsd.org/doc/en/books/porters-handbook/porting-checksum.html > > I have attached what I think is the svn diff that include both your > patch and my update. The distinfo file should still be incorrect. I > haven't tested it. I have to get to work . :P > > I have cc'd the ports list as well in this conversation. Any input > from all parties would be grand. Thank you for the review - I see you commented on the review. I'll try and finish the port over the weekend. FYI, I have uploaded another two reviews. These combined get the CentOS version of .NET Core running on FreeBSD :-). Regards signature.asc Description: This is a digitally signed message part.
Re: All those notes...
On Mon, Jan 08, 2018 at 09:39:56AM +1100, Greg 'groggy' Lehey wrote: > > > This was accompanied by zillions of notes, warning me to "do this" and > > "avoid doing that" etc. Err, were those notes squirreled away somewhere, > > or do I have to hope that I don't lose the window and its scrollback > > buffer? > > I pipe the output of pkg to a file. It's worth the trouble. I don't > know any other way to keep track of what this particular instance did. > The notes themselves are in the pkg-message file for the individual > ports. > . My practice has been to run such commands within script(1). (This iis also helpful if I need to show someone else exactly what commands were issued and what the responses were.) Peace, david -- David H. Wolfskill da...@catwhisker.org A "Birther" calls himself a "a very stable genius" -- same level of truth? See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
A note on updating security/gnupg20 -> gnupg
I had been using security/gnupg20 with mail/mutt, based on a misunderstanding on my part (back when the security/gnupg20 port was created). Now that security/gnupg20 has been expired and removed, I had motivation to look into the situation in more detail; I found that security/gnupg (now at 2.2.4) works fine with mail/mutt -- if I made a change (in ~/.muttrc) to the way gpg is invoked. E.g., I changed: set pgp_decrypt_command="gpg2 --passphrase-fd 0 --no-verbose --batch --output - %f" to pgp_decrypt_command="gpg2 %?p?--passphrase-fd 0 --pinentry-mode=loopback? --no-verbose --batch --output - %f" The salient differences appear to be the insertion of "%?p?" before "--passphrase-fd 0" and the insertion of "--pinentry-mode=loopback?". The changes to ~/.muttrc appear to have been sufficient (in my case) for mutt to be able to use security/gnupg (vs. security/gnupg20) for encryption and decryption of PGP-compatible email messages. Finally, on the actual replacement: I did this on three systems; on two of those, I update ports via portmaster; on the other, I update them from a locally-built repository (via "pkg upgrade"). For the systems using portmaster, "portmaster -o security/gnupg gnupg20-2.0.30_2" worked well. (My thanks to Doug Barton and Stefan Esser!) When I ran "pkg upgrade" on the system I update that way, there was no indication that the status of security/gnupg* had changed since the previous update (one week ago -- shortly before the removal of security/gnupg20). I ended up performing "pkg delete security/gnupg20", followed by "pkg install security/gnupg" -- which worked. (I had previously updated the list of packages to build on my build machine, to replace security/gnupg20 by security/gnupg.) My concern about that last point is that if I were only updating ports via "pkg upgrade", I would not have known that security/gnupg20 no longer existed (well, unless I read the svn-ports-head list, or polled the svn log for ports/security/Makefile -- or some other similarly-unlikely activity for someone updating via packages only). Perhaps I'm overlooking something. In any case: If you use mutt with security/gnupg20 and migrate to security/gnupg, and find that you cannot decrypt encrypted messages any more, you should check your ~/.muttrc: you probably need to change the "gpg" (or "gpg2") invocations; in my experience, that is a necessary and sufficient change to make encryption and decryption work again. Peace, david -- David H. Wolfskill da...@catwhisker.org A "Birther" calls himself a "a very stable genius" -- same level of truth? See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: mail/mutt && security/gnupg (after gnupg20 -> gnupg) weirdness
I *think* the issue is that I needed to update ~/.muttrc for the change in gnupg; in particular: set pgp_decrypt_command="gpg --keyserver pgp.mit.edu --passphrase-fd 0 --no-verbose --batch -o - %f" was changed to set pgp_decrypt_command="gpg2 %?p?--passphrase-fd 0 --pinentry-mode=loopback? --no-verbose --batch --output - %f" (based on <https://github.com/termux/termux-packages/issues/694>). Peace, david -- David H. Wolfskill da...@catwhisker.org If you want the best Fake News, go to the best source of it: Donald J. Trump. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
mail/mutt && security/gnupg (after gnupg20 -> gnupg) weirdness
I have been using mail/mutt & security/gnupg (latter switched to
security/gnupg20 back when gnupg20 port was created because of a
similar-looking issue to what's described in the first part of the
below narrative) for several years -- without enabling "gpgme" (in
case that turns out to be relevant).
As a result, I have a collection of messages that were sent to me that
contain information that was deemed suitable for encryption; I still
have occasion to refer to the contents of some of these messages, and
prefer to leave them stored in encrypted form when I am not actively
reading them.
This morning, during the daily update of installed ports on my
laptop, I saw:
===>>> The security/gnupg20 port moved to security/gnupg
===>>> Reason: Has expired: Will reach EOL upstream on 2017-12-31
OK. I had vague memories that things didn't work very well last time
there was a "minor" upgrade to gnupg, so I deferred that part of the
upgrade until I could do a bit more research.
I soon found "Bug 196382 - security/gnupg breaks keyring on 2.1.1"
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196382>. So I tried
the recipe listed in Comment 4, then verified that decryption still
worked (while gnupg20 was the version of gnupg that was installed).
That was successful, so I deleted security/gnupg20, then installed
security/gnupg; that done, I re-tried the decryption, which failed
("Could not decrypt PGP message"; "Could not copy message" -- these
messages from mutt).
I then re-did the recipe from Comment 4 (now that security/gnupg was
installed), then re-tried the decryption test; it (still) failed the
same way.
Trying the decryption again (under "ktrace -di") showed the following
messages being issued by gpg:
"gpg: WARNING: no command supplied. Trying to guess what you mean ..."
"gpg: encrypted with 2048-bit RSA key, ID C8A5439CFA5A0A07, created 201\
5-11-29"
" "David H. Wolfskill <da...@catwhisker.org>"
"gpg: public key decryption failed: Invalid IPC response"
"gpg: decryption failed: No secret key"
Following a hint obtained by searching on the above (particularly
the "gpg: public key decryption failed: Invalid IPC response" message),
I logged in to a machine that still has security/gnupg20 and used
gpg -e /etc/rc.conf
to encrypt a copy of that file with me as a recipient. Decrypting
worked (as expected).
I then copied the rc.conf.gpg from that machine to my laptop (which now
has security/gnupg installed) and attempted the decryption -- and it
worked.
Given that, I thought that perhaps the (re-)installation of mail/mutt
had been what got things working again; I was thus quite surprised when
(about 3.5 hrs. later) I got in to work and had need to decrypt a
message on my laptop, and it -- again -- failed as described above.
As a reality check, I then re-tried the decryption of rc.conf.gpg (from
above); that worked.
After a couple quick shakes of my head to help ensure that I wasn't
hallucinating, I tried reading an encrypted email message (on the
laptop) again... and this time, it worked.
In fact, going back to the first "mutt" invocation that failed at work,
merely requesting to read a message Just Worked -- my passphrase was not
requested (as I had entered it less than 2 hours earlier).
This leaves me wondering if all of the above means that before
attempting to decrypt an encrypted email message via mutt, one is
supposed to (first) use bare gpg to decrypt a file -- but that seems
ridiculous to thye point of hostility
Does anyone have insights, clues, or pointers to same to share?
Thanks!
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
If you want the best Fake News, go to the best source of it: Donald J. Trump.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
Re: Working on FLAVOR support in portmaster
On Tue, Dec 05, 2017 at 08:35:55AM +0100, Stefan Esser wrote: > ... > I'm working on FLAVOR support in portmaster. My version did already build > all updated ports, the FLAVOR parameter is passed to build sub-processes, > but there is still some confusion between multiple flavored versions of the > same port (installing the py27 version wants to deinstall the py36 version > and vice versa), which I still have to fix. Thank you; that is encouraging. > I'm not sure that I have time to complete the fix today, but it is not too > hard. Ports need to complement the port origin with the FLAVOR, where > appropriate (e.g. when a flavored destination is found in MOVED). Already > installed packages are annotated with "flavor" and that must be passed to > the build command, when that port is updated. Most other logic in portmaster > remains unaffected. That seems reasonable. > My work version has all non PKG_NG support stripped, but that is mainly to > not waste effort fixing irrelevant sub-routines. Also reasonable, IMO. > Is it acceptable, to have portmaster stop supporting the old package system? > AFAIK, there is no way that a modern ports tree with flavor support works > with a non-PKG_NG infrastructure? I believe so: if for no other reason, one wishing to support such a non-PKG_NG infrastructure can certainly use an older version of portmaster. > Regards, STefan > Peace, david -- David H. Wolfskill da...@catwhisker.org Trump is an incompetent, lying bully who is unfit for any public office. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Spam on -ports
On Fri, Oct 27, 2017 at 11:13:20AM +0200, Jan Bramkamp wrote: > ... > I would like to help fighting the spam problem on the FreeBSD.org > mailing lists. Can you put me in contact with the right people? > > -- Jan Bramkamp <postmas...@freebsd.org> would be the appropriate email address -- both for offers of help and pointing out perceived issues (whether it's the existence of spam, problems sending mail to a list, or just about anything involving the email infrastructure at FreeBSD.org). Peace, david (who has worn that hat, but is handing it off to others) -- David H. Wolfskill da...@catwhisker.org Unsubstantiated claims of "Fake News" are evidence that the claimant lies again. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: FreeBSD Port: sudo-1.8.21p2 - 1.8.21p2 SegFaults
I’m going forward with 11.1-stable, and the 1.8.21p2 packages on pkg.freebsd.org <http://pkg.freebsd.org/> also segfaults on bare metal. -- David P. Discher • d...@ixsystems.com Director, Information Technology iXsystems, Inc. Office: 408.943.4100 x150 Mobile: 408.368.3725 > On Oct 1, 2017, at 2:34 PM, David P. Discher <d...@ixsystems.com> wrote: > > Hi Renato & ports : > > I was just stumble over this, with 12.0-CURRENT r323934, sudo 1.8.21p2 > SegFaults when run in a bhyve VM - however, seemly on bare metal, its fine. > > sudo-1.8.20p2_3 runs just fine in bhyve VM. There are all my own builds of > 12- and ports (via poudriere). I recompiled sudo on the Bhyve, and still had > the same issue. > > > -- > David P. Discher • d...@ixsystems.com > Director, Information Technology > iXsystems, Inc. > Office: 408.943.4100 x150 > Mobile: 408.368.3725 > > signature.asc Description: Message signed with OpenPGP
graphics/netpbm update to netpbm-10.80.00
Empirical observation: environments that currently have an older installation of graphics/netpbm already installed, and where the intent is to update graphics/netpbm to netpbm-10.80.00 by building the port in the environment with the older netpbm already installed (e.g., make, portmaster, and portupgrade -- not within a jail or a chroot) may benefit from deleting the old installed version before attempting the in-place update. Disclaimer: That's what worked for me, using portmaster. In a couple of days, I expect to be updating at least one system from custom-built packages (built using poudriere); I expect that this will Just Work (without the evasive maneuver of a preemptive "pkg delete -f graphics/netpbm"). And there's another system I expect to update that same day -- rather isolated from everything else -- where I expect to use portmaster, and will need to perform said preemptive evasive maneuver. I mention it in the hope that the information will reduce the time spent trying to figure this out: time is not one of the "more renewable resources" we have. Peace, david -- David H. Wolfskill da...@catwhisker.org http://www.cbc.ca/news/opinion/donald-trump-playbook-1.4265374 See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Status of portupgrade and portmaster?
On Mon, Oct 02, 2017 at 11:51:33AM -0700, Don Lewis wrote: > On 2 Oct, Marco Beishuizen wrote: > ... > > I'm running 11.1-STABLE now, upgrading every few months or when there is > > an important security fix. Do I have to build a new system twice in that > > case (once my running system and once the poudriere jail)? > > Yes, but at least the poudriere jail doesn't build the kernel bits. The > real pain point is that when you update the jail, the next bulk package > build will toss all the previously built packages and force a full > rebuild from scratch. That makes sense if you believe that the contents > of the jail affect the contents of the packages build using that jail. > If you don't think that is true, then why bother to update the jail. > > I stick to pretty much the same schedule as you for updating my -STABLE > machines, though I'm doing it for 10.4-STABLE i386, 11.1-STABLE amd64 > and i386, and 12.0-CURRENT amd64. I try to do weekly package update > runs. > With respect, that (building the world twice -- once for the host and once for the poudriere jail) has not been my experience. As described in <http://www.catwhisker.org/~david/FreeBSD/upgrade.html> and <http://www.catwhisker.org/~david/FreeBSD/convert_i386_amd64.html> (particularly the "Postscript: Subsequent Maintenance" section at the bottom of the latter page), the machine that runs poudriere gets its stable/11 environment updated daily; it runs poudriere twice each week (Saturday and Sunday), and the thus-refreshed local repository is used weekly (on Sunday). As a case in point, on Saturday last (2 days ago, as of this writing), the host system was updated from: FreeBSD 11.1-STABLE #469 r324085M/324100:1101505: Fri Sep 29 03:39:21 PDT 2017 r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/GENERIC amd64 to FreeBSD 11.1-STABLE #470 r324115M/324116:1101505: Sat Sep 30 03:41:57 PDT 2017 r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/GENERIC amd64 the ports working copy was updated from r450887 to r450972, and the ensuing poudriere run recorded: [11amd64-ports-home] [2017-09-30_10h55m37s] [committing:] Queued: 1091 Built: 1091 Failed: 0Skipped: 0Ignored: 0Tobuild: 0 Time: 04:28:37 The following day, the host system was updated from: FreeBSD 11.1-STABLE #470 r324115M/324116:1101505: Sat Sep 30 03:41:57 PDT 2017 r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/GENERIC amd64 to FreeBSD 11.1-STABLE #471 r324138M/324155:1101505: Sun Oct 1 03:42:38 PDT 2017 r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/GENERIC amd64 the ports working copy was updated from r450972 to r451042, and the ensuing poudriere run recorded: [11amd64-ports-home] [2017-10-01_10h50m40s] [committing:] Queued: 183 Built: 183 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 0Time: 01:42:10 Disclaimer: I do not claim expertise in ports-system wrangling. While I use poudriere to build packages for my systems that are only updated weekly, I use portmaster for those that are updated daily. I make no claims of optimal ... anything, really. What I describe seems to generally work for me, but my approaches are almost certainly not suitable for most folks. Despite that, it may be possible to learn things from what others have done, so I have tried to document what I did; please feel free to use it -- possibly as an example of what NOT to do. :-) Peace, david -- David H. Wolfskill da...@catwhisker.org http://www.cbc.ca/news/opinion/donald-trump-playbook-1.4265374 See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
FreeBSD Port: sudo-1.8.21p2 - 1.8.21p2 SegFaults
Hi Renato & ports : I was just stumble over this, with 12.0-CURRENT r323934, sudo 1.8.21p2 SegFaults when run in a bhyve VM - however, seemly on bare metal, its fine. sudo-1.8.20p2_3 runs just fine in bhyve VM. There are all my own builds of 12- and ports (via poudriere). I recompiled sudo on the Bhyve, and still had the same issue. -- David P. Discher • d...@ixsystems.com Director, Information Technology iXsystems, Inc. Office: 408.943.4100 x150 Mobile: 408.368.3725 signature.asc Description: Message signed with OpenPGP
Re: Help Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD
On Monday, 4 September 2017 10:54:21 Geoffrey Huntley wrote: > See https://www.youtube.com/watch?v=NHllisWOCpU and > https://twitter.com/GeoffreyHuntley/status/904227946084294656 Hi Geoffrey It is great to hear there is more interest in finishing the port of .NET Core to FreeBSD (and, I hope, to have ports living in the Port's Collection). Would it be possible for you to put me (and the mono@ mailing list) in touch with Karel and Tomas - I'm not on Twitter. I'll reply to this email (dropping ports@ and advocacy@) with more technical details. Regards David signature.asc Description: This is a digitally signed message part.
Re: FreeBSD Port: RetroArch-1.3.6_7
2017-08-24 6:49 GMT+02:00 Kevin Oberman <rkober...@gmail.com>: > Are you building with the default options? fmpeg has about as many options > as any port and they increase as new codecs, multiplexers, and such are > developed. It may be some non-standard selection that is causing your > problem. It built for me with MY options just fine. (11-stable on amd64). > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 Yes, I usually never change any option, I use poudriere which does batch building anyway. -- Demelier David ___ 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: RetroArch-1.3.6_7
On Wed, 2017-08-23 at 07:23 -0700, Ultima wrote: > Are you positive ffmpeg is the issue? I just did a clean build on > 110amd64 and 12 current and ffmpeg built just fine. Also build fairly > recent (less than a week) on the other releases/tier 1 arch. Weird, I've pulled the ports source tree yesterday and it still did not build with the same error. I'll double check. But for now I'll disable temporarily the ffmpeg dependency to update the port :) Regards, -- David ___ 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: RetroArch-1.3.6_7
2017-07-11 10:02 GMT+02:00 bluesky <blue...@airmail.cc>: > Hello. The Retroarch port seems a bit out of date. Retroarch is on version > 1.6.0 now. Hi, I'm sorry I'm unable to update it at the moment because ffmpeg does not compile since many FreeBSD developers push changes without testing: https://lists.freebsd.org/pipermail/freebsd-ports/2017-July/109566.html I'll postpone that update once it has been fixed. -- Demelier David ___ 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: security/libressl: Add the possibility to build only libtls
On 2017-08-21 11:59, David Wahlund wrote: Hi I'd like to use the libtls library of LibreSSL on FreeBSD. Or the python bindings to libtls specifically. I do NOT however want to replace openssl or use the libssl library. From what I understand it would be possible in practice as I assume it's only libssl that overwrites files used by openssl. Would it be possible to create an option in LibreSSL, or preferably make a separate port, for libtls only? That way future ports can depend on libtls only. For example a future python-libtls port could depend on that. -David I guess it's the libtls-standalone I'm after. It's on GitHub. https://github.com/libressl-portable/portable/tree/master/libtls-standalone ___ 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: security/libressl: Add the possibility to build only libtls
On 2017-08-21 16:55, Mathieu Arnold wrote: Le 21/08/2017 à 12:03, Franco Fichtner a écrit : On 21. Aug 2017, at 11:59 AM, David Wahlund <da...@dafnet.se> wrote: I'd like to use the libtls library of LibreSSL on FreeBSD. Or the python bindings to libtls specifically. I do NOT however want to replace openssl or use the libssl library. From what I understand it would be possible in practice as I assume it's only libssl that overwrites files used by openssl. Would it be possible to create an option in LibreSSL, or preferably make a separate port, for libtls only? That way future ports can depend on libtls only. For example a future python-libtls port could depend on that. Unless you build your own packages with OpenSSL from ports you can just install LibreSSL and use it in your programs... # pkg install libressl OpenSSL lives in the base system, LibreSSL will be an optional install under /usr/local. That is not quite true. As soon as you install openssl, openssl-devel, or libressl or libressl-devel, the ports framework will use it whenever you build something that needs SSL from the ports tree. If you truly want to have libressl but do not want to use it for building ports, you will need to install it in a separate PREFIX. Well the problem is that libressl is TWO libraries (actually three but nm). One that replaces openssl (libssl) and one that doesn't (libtls). However the libtls has shared dependencies with libssl. I DO want to use libtls for ports that has that dependency, but NOT use it to replace openssl. Libtls CAN be a separate dependency in parallel to openssl from what I understand. But now the libressl port conflicts with the openssl port even though parts of it is not in conflict and I don't think the shared parts between libssl and libtls are in conflict with openssl. But I might be wrong. So what I'm looking for is a way to use libtls but NOT use libssl. ___ 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"
security/libressl: Add the possibility to build only libtls
Hi I'd like to use the libtls library of LibreSSL on FreeBSD. Or the python bindings to libtls specifically. I do NOT however want to replace openssl or use the libssl library. From what I understand it would be possible in practice as I assume it's only libssl that overwrites files used by openssl. Would it be possible to create an option in LibreSSL, or preferably make a separate port, for libtls only? That way future ports can depend on libtls only. For example a future python-libtls port could depend on that. -David ___ 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: x11/nvidia-settings: poudriere fails; portmaster succeeds
On Sat, Aug 19, 2017 at 09:39:39AM -0700, Yuri wrote:
> On 08/19/17 06:01, David Wolfskill wrote:
> > In fairness, this may be an "apple vs. orange" comparison. But it's
> > fairly unusual (in my experience) for poudriere to fail to build a port,
> > but when it's a port that I had just built successfully (using
> > portmaster) on my laptop... well, I thought it was worth mentioning.
>
> What version is fails on?
The OS for the poudriere run was:
FreeBSD 11.1-STABLE #431 r322692M/322692:1101501: Sat Aug 19 03:43:54 PDT 2017
r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/GENERIC amd64
For the portmaster run, it was:
FreeBSD 11.1-STABLE #365 r322647M/322650:1101501: Fri Aug 18 03:52:30 PDT 2017
r...@g1-252.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY amd64
The port was attempting to build nvidia-settings-384.59_1.
The Makefile shows r448102:
g1-252(11.1-S)[15] dirs
/usr/ports/x11/nvidia-settings
g1-252(11.1-S)[16] grep BUILD Makefile
g1-252(11.1-S)[17] head -3 Makefile
# Created by: Alexander Nedotsukov <bl...@freebsd.org>
# $FreeBSD: head/x11/nvidia-settings/Makefile 448102 2017-08-17 14:08:26Z
swills $
g1-252(11.1-S)[18] svn info ../../
Path: /common/ports
Working Copy Root Path: /common/ports
URL: file:///svn/freebsd/ports/head
Relative URL: ^/head
Repository Root: file:///svn/freebsd/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 448295
Node Kind: directory
Schedule: normal
Last Changed Author: bsam
Last Changed Rev: 448295
Last Changed Date: 2017-08-19 03:28:29 -0700 (Sat, 19 Aug 2017)
g1-252(11.1-S)[19]
> > gtk+-2.x/ctkgridlicense.c:42:10: fatal error: 'dbus/dbus.h' file not found
> > #include
> > ^
> > 1 error generated.
>
>
> It builds in poudriere 11.1 amd64 for me.
The apparent difference in behavior is curious.
> This means that it requires DBus at compile time, and it isn't in
> BUILD_DEPENDS:
>
> BUILD_DEPENDS=${LOCALBASE}/dbus/dbus.h:devel/dbus
>
>
> Yuri
>
Thankk you for pointing that out. As above, the Makefile as of r448102
appears to lack a BUILD_DEPENDS specification. This may be confirmed at
https://svnweb.freebsd.org/ports/head/x11/nvidia-settings/Makefile?revision=448102=markup
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
If we wish to eliminate sources of Fake News, start at the top: D. Trump.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
x11/nvidia-settings: poudriere fails; portmaster succeeds
In fairness, this may be an "apple vs. orange" comparison. But it's
fairly unusual (in my experience) for poudriere to fail to build a port,
but when it's a port that I had just built successfully (using
portmaster) on my laptop... well, I thought it was worth mentioning.
The whine in the poudriere log is:
...
cc -O2 -pipe -fstack-protector -fno-strict-aliasing -fno-strict-aliasing
-fno-omit-frame-pointer -Wformat=2 -Wno-unused-parameter
-Wno-format-zero-length -DNV_BSD -I/usr/local/include -I . -I image_data -I
libXNVCtrl -I XF86Config-parser/.. -I libXNVCtrlAttributes -I xpm_data -I
common-utils -I common-unix/virtual-resolutions -I _out/FreeBSD_amd64
-I/usr/local/include -D_THREAD_SAFE -pthread -I /usr/include/dbus-1.0/
-DPROGRAM_NAME=\"nvidia-settings\" -fPIC -c XF86Config-parser/Generate.c -o
_out/FreeBSD_amd64/Generate.o && cc -MM -O2 -pipe -fstack-protector
-fno-strict-aliasing -fno-strict-aliasing -fno-omit-frame-pointer -Wformat=2
-Wno-unused-parameter -Wno-format-zero-length -DNV_BSD -I/usr/local/include
-I . -I image_data -I libXNVCtrl -I XF86Config-parser/.. -I
libXNVCtrlAttributes -I xpm_data -I common-utils -I
common-unix/virtual-resolutions -I _out/FreeBSD_amd64 -I/usr/local/include
-D_THREAD_SAFE -pthread -I /usr/include/dbus-1.0/
-DPROGRAM_NAME=\"nvidia-settings\" -fPIC XF86Config-parser/Generate.c | sed -e
"s,: ,: $\(wildcard ," -e "s,\([^\\]\)$,\1)," -e "s;^Generate.o: ;
_out/FreeBSD_amd64/Generate.o: ;" > _out/FreeBSD_amd64/Generate.d
gtk+-2.x/ctkgridlicense.c:42:10: fatal error: 'dbus/dbus.h' file not found
#include
^
1 error generated.
which looks to me as if somehow nvidia-settings has a dependency on dbus
of which poudriere was unaware; more on that below (after I sketch the
environment).
I have two machines that have nightly-updated private mirrors of the
FreeBSD SVN src, ports, and doc repositories: my laptop and a "build
machine" ("freebeast").
As described in <http://www.catwhisker.org/~david/FreeBSD/upgrade.html>,
I perform a source-based update of stable/11 on each of the machines
each morning; upon reboot and after "make delete-old-libs", I use
portmaster on each of these machines to update the installed ports to
match the state of the just-updated /usr/ports working copy.
The laptop only builds the world & its own custom kernel; freebeast runs
a GENERIC kernel and builds that, as well as kernels for the two
"production" machines. On a regular basis (normally, each Sunday
morning), I update the production machines by installing the just-built
snapshot of stable/11 onto them, reboot, perform a "pkg updgrade", and
reboot again.
The production machines are configured to get their packages (for the
"pkg upgrade") from freebeast.
freebeast uses poudriere to build the packages.
Since I (normally) only update the production machines on Sunday, I
don't see much value in running poudriere every day. On the other hand,
if I wait until Sunday (to get a week's worth of updates), that can take
a while, even with a reasonably fast machine.
So, as a compromise, I do the "weekly" package-building in two stages:
the first is on Saturday (as in, today), doing a "catch up" run for the
last 6 days of updates, then on Sunday -- usually! -- there's only a
small amount of work to get caught up.
Thus, the successful build of x11/nvidia-settings was on my laptop,
yesterday:
...
===>>> The following actions were performed:
Upgrade of nvidia-xconfig-378.13 to nvidia-xconfig-384.59
Upgrade of libuv-1.13.1 to libuv-1.14.0
Upgrade of cups-filters-1.13.5 to cups-filters-1.16.0
Upgrade of harfbuzz-1.4.7 to harfbuzz-1.4.8
Upgrade of harfbuzz-icu-1.4.7 to harfbuzz-icu-1.4.8
Upgrade of opusfile-0.8 to opusfile-0.9
Upgrade of nvidia-settings-378.13_1 to nvidia-settings-384.59_1
Command exit status: 0
freebeast runs (essentially) headless; it has no X11-related ports
installed at all. So my next attempt to build x11/nvidia-settings
was on freebeast, but using poudriere -- which failed as described
above.
Checking (on my laptop) for ports on which nvidia-settings depends, I
see:
g1-252(11.1-S)[1] pkg info -d x11/nvidia-settings
nvidia-settings-384.59_1:
libXxf86vm-1.1.4_1
libXv-1.0.11,1
libXext-1.3.3_1,1
libX11-1.6.5,1
pango-1.40.6
gtk2-2.24.31
fontconfig-2.12.1,1
freetype2-2.8
libvdpau-1.1.1
mesa-libs-17.1.5
gdk-pixbuf2-2.36.6
cairo-1.14.8_1,2
jansson-2.10
glib-2.50.2_4,1
gettext-runtime-0.19.8.1_1
atk-2.24.0
g1-252(11.1-S)[2]
And that list does not seem to mention any dbus-related ports.
So I *suspect* that the portmaster build was "successful" only by
accident (because portmaste
Re: lang/rust: failure to build stage0 tool rust-installer (amd64)
On Tue, Aug 08, 2017 at 02:30:44PM +0200, Jan Beich wrote: > David Wolfskill <da...@catwhisker.org> writes: >> [whine about lang/rust failing to build...] > > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221088 > Thanks; given the hints there, I was able to circumvent the problem (and update the report to show what worked for me). TL;DR: "sudo su -" seems to do the trick (as it removes the SUDO_* environment variables). Peace, david -- David H. Wolfskill da...@catwhisker.org Of the Trump White House activity, how much is "chaff?" (ref. RADAR) See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
lang/rust: failure to build stage0 tool rust-installer (amd64)
This is on my laptop, running: FreeBSD g1-252.catwhisker.org 11.1-STABLE FreeBSD 11.1-STABLE #356 r322216M/322217:1101501: Tue Aug 8 03:44:01 PDT 2017 r...@g1-252.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY amd64 using a ports working copy updated from r447489 to r447536: g1-252(12.0-C)[4] svn info /usr/ports/ Path: /usr/ports Working Copy Root Path: /usr/ports URL: file:///svn/freebsd/ports/head Relative URL: ^/head Repository Root: file:///svn/freebsd/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 447536 Node Kind: directory Schedule: normal Last Changed Author: cpm Last Changed Rev: 447536 Last Changed Date: 2017-08-08 02:12:27 -0700 (Tue, 08 Aug 2017) (I point out the previous rr447489, as the installed ports had been updated to that point successfully (yesterday).) After updating base FreeBSD (ref. above "uname -a" outpout) & rebooting, I ran "portmaster -ad" (within script), and was informed: portmaster: All >> (4) ===>>> The following actions will be taken if you choose to proceed: Upgrade p5-Error-0.17024 to p5-Error-0.17025 Upgrade firefox-54.0.1_1,1 to firefox-55.0,1 Install devel/cargo Install lang/rust ===>>> Proceed? y/n [y] (Immediately following the previous -- successful -- update of www/firefox, I had performed a "pkg delete lang/rust", as I had been made quite aware that lang/rust does not build successully if (an earlier version of) it is already installed. That also deleted devel/cargo; since they are only build dependencies for www/firefox (in my environment), that seemed OK.) I have placed the complete typescript in <http://www/~david/FreeBSD/ports/rust.txt>; there is also <http://www/~david/FreeBSD/ports/rust.txt.gz> available. In any case, the distribution files seem OK: ... ===> License APACHE20 MIT accepted by the user ===> rust-1.19.0 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by rust-1.19.0 for building ===> Extracting for rust-1.19.0 => SHA256 Checksum OK for rust/rustc-1.19.0-src.tar.gz. => SHA256 Checksum OK for rust/2017-06-08/rustc-1.18.0-x86_64-unknown-freebsd.tar.gz. => SHA256 Checksum OK for rust/2017-06-08/rust-std-1.18.0-x86_64-unknown-freebsd.tar.gz. => SHA256 Checksum OK for rust/2017-06-08/cargo-0.19.0-x86_64-unknown-freebsd.tar.gz. => SHA256 Checksum OK for rust/rust-registry-1.19.0.tar.xz. /bin/ln -sf /common/ports/distfiles//rust/2017-06-08/rustc-1.18.0-x86_64-unknown-freebsd.tar.gz /common/ports/lang/rust/work/rustc-1.19.0-src/build/cache/2017-06-08 ... Patching seemed OK: ... ===> Patching for rust-1.19.0 ===> Applying FreeBSD patches for rust-1.19.0 ===> rust-1.19.0 depends on executable: cmake - found ===> rust-1.19.0 depends on file: /usr/local/bin/FileCheck40 - found ===> rust-1.19.0 depends on executable: gmake - found ===> rust-1.19.0 depends on file: /usr/local/bin/python2.7 - found ===> rust-1.19.0 depends on shared library: libedit.so.0 - found (/usr/local/lib/libedit.so.0) ===> Configuring for rust-1.19.0 ... Configuring was apparently OK: ... ===> Configuring for rust-1.19.0 ===> FreeBSD 10 autotools fix applied to /common/ports/lang/rust/work/rustc-1.19.0-src/src/vendor/lzma-sys/xz-5.2.3/build-aux/config.rpath ===> FreeBSD 10 autotools fix applied to /common/ports/lang/rust/work/rustc-1.19.0-src/src/vendor/libssh2-sys/libssh2/config.rpath ===> FreeBSD 10 autotools fix applied to /common/ports/lang/rust/work/.cargo/registry/src/github.com-1ecc6299db9ec823/libssh2-sys-0.2.6/libssh2/config.rpath ===> FreeBSD 10 autotools fix applied to /common/ports/lang/rust/work/.cargo/registry/src/github.com-1ecc6299db9ec823/lzma-sys-0.1.4/xz-5.2.3/build-aux/config.rpath /usr/bin/sed -E -e 's,%PREFIX%,/usr/local,' -e 's,%SYSCONFDIR%,/usr/local/etc,' -e 's,%MANDIR%,/usr/local/man,' -e 's,%PYTHON_CMD%,/usr/local/bin/python2.7,' -e 's,%CHANNEL%,stable,' -e 's,%TARGET%,x86_64-unknown-freebsd,' < /common/ports/lang/rust/files/config.toml > /common/ports/lang/rust/work/rustc-1.19.0-src/config.toml /usr/bin/sed -i.bak -e 's,%DOCS%,true,' /common/ports/lang/rust/work/rustc-1.19.0-src/config.toml /usr/bin/sed -i.bak -e 's,%LLVM_CONFIG%,/usr/local/bin/llvm-config40,' /common/ports/lang/rust/work/rustc-1.19.0-src/config.toml ===> Building for rust-1.19.0 ... Building... hmmm... I just noticed the "info" text; that seems... odd: ===> Building for rust-1.19.0 cd /common/ports/lang/rust/work/rustc-1.19.0-src && /usr/bin/env HOME=/common/ports/lang/rust/work /usr/local/bin/python2.7 /common/ports/lang/rust/work/rustc-1.19.0-src/x.py build --verbose --config ./config.toml --jobs 8 info: looks like you are running this command under `sudo` and so in order to preserve your $HOME this will now use vendored sources by default.
ffmpeg undefined references
Hello, I never had this build error before, but I can't get ffmpeg to build: cc -Llibavcodec -Llibavdevice -Llibavfilter -Llibavformat -Llibavresample -Llibavutil -Llibpostproc -Llibswscale -Llibswresample -fstack-protector -L/usr/local/lib -Wl,--as-needed -Wl,-z,noexecstack -Wl,--warn-common -Wl,-rpath-link=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample -Qunused-arguments -o ffmpeg_g cmdutils.o ffmpeg_opt.o ffmpeg_filter.o ffmpeg.o ffmpeg_vaapi.o ffmpeg_vdpau.o -lavdevice -lavfilter -lavformat -lavcodec -lavresample -lpostproc -lswresample -lswscale -lavutil -lvdpau -lva -lva-x11 -lX11 -lva -lva-drm -lva -lxvidcore -L/usr/local/lib -lx265 -L/usr/local/lib -lx264 -L/usr/local/lib -lvpx -lm -L/usr/local/lib -lvpx -lm -L/usr/local/lib -lvpx -lm -L/usr/local/lib -lvpx -lm -lvorbisenc -lvorbis -logg -L/usr/local/lib -lv4l2 -ltheoraenc -ltheoradec -logg -L/usr/local/lib -lschroedinger-1.0 -lopencv_core -lopencv_imgproc -L/usr/local/lib -lfreetype -L/usr/local/lib -lfontconfig -lfreetype -L/usr/local/lib -lgnutls -lgmp -lm -llzma -lbz2 -lz -pthread libavfilter/libavfilter.so: undefined reference to `ff_pullup_init_x86' libavcodec/libavcodec.so: undefined reference to `ff_v210_x86_init' libavcodec/libavcodec.so: undefined reference to `ff_psdsp_init_x86' libavcodec/libavcodec.so: undefined reference to `ff_svq1enc_init_x86' libavcodec/libavcodec.so: undefined reference to `ff_synth_filter_init_x86' [ ... more ... ] I use the default ffmpeg options. Regards, -- Demelier David ___ 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: nvidia-driver-375.66
There is a new version of the nvidia driver on there site as of may 9th … Version: 381.22 Release Date: 2017.5.9 This Added support for GeForce GT 1030 … which I’d imagine others may start trying to use like myself. This older driver doesn’t work at all with the 1030. -- David P. Discher • d...@ixsystems.com Director, Information Technology iXsystems, Inc. Office: 408.943.4100 x150 Mobile: 408.368.3725 signature.asc Description: Message signed with OpenPGP
Re: devel/apr1: "make install" can't find apr_dbd_sqlite3-1.so
On Thu, Jul 13, 2017 at 05:35:05AM -0700, David Wolfskill wrote: > Ref. PR <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220699> > Ports r445645 seems to have addressed the issue(s) successfully. Peace, david -- David H. Wolfskill da...@catwhisker.org If the meeting was innocuous, why was its purpose mischaracterized? See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
devel/apr1: "make install" can't find apr_dbd_sqlite3-1.so
Ref. PR <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220699> Peace, david -- David H. Wolfskill da...@catwhisker.org If the meeting was innocuous, why was its purpose mischaracterized? See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: make install for print/texinfo fails on -CURRENT
On Tuesday, 11 July 2017 08:47:17 Bob Willcox wrote: > Hmm, I just tried running synth on my test system again (this is the system > that I successfully built and install texinfo on just a bit ago) and synth > still fails with the same build errors as before. I'm not all that familiar > with synth, but it appears that it may be working with some old stuff. Hi (Replying to a random email) I've encountered the exact same issue while building the i386 packages for wine. Once I forced a rebuild of _all_ texinfo dependencies, installation worked. I suspect an ABI change in -CURRENT that broke a dependency (sounds like perl based on the thread). Regards signature.asc Description: This is a digitally signed message part.
Re: FreeBSD Port: RetroArch-1.3.6_7
I'll update it. -- David Demelier Le 11 juil. 2017 6:02 AM, "bluesky" <blue...@airmail.cc> a écrit : > Hello. The Retroarch port seems a bit out of date. Retroarch is on version > 1.6.0 now. > > Thank you. > > > ___ > 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-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: freeze-2.5_2 - license dialog
Would it be possible to move the license dialog to a standard option so batch portmaster (etc) will get the license confirmation with the rest of the options updates rather than during the (often unattended) build phase? -David ___ 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: math/R: Build failure after PORTREVISION for shlib change
On Thu, Jun 29, 2017 at 12:39:50PM -0300, Joseph Mingrone wrote: > ... > With those options, the build succeeds in an 11.0-RELEASE-p1 jail. > http://pkg.awarnach.mathstat.dal.ca/data/11amd64-default/2017-06-28_16h53m48s/logs/R-3.4.0_2.log > ... > Everything matches. The successful build in poudriere even has the same > line that generates the error for you. > > /usr/local/bin/gcc-ar5 -cr libtre.a regcomp.o regerror.o regexec.o tre-ast.o > tre-compile.o tre-match-approx.o tre-match-backtrack.o tre-match-parallel.o > tre-mem.o tre-parse.o tre-stack.o xmalloc.o > > Could you have something in your environment or in make.conf that's > causing a problem? > As expected, further attempts to build math/R on my laptop have continued to fail as before -- and as mentioned, I ran a poudriere run, where building the package for math/R worked. That said, the line in the poudriere log that corresponds to the failing invocation is a bit different in my case. (I found a couple of small options differences, such as paper size; I don't believe those have anything to do with the observed differences, but I've corrected them for tomorrow's poudriere run.) The line in the failing case (with the immediately preceding line for context): ... gcc5 -I. -I. -I../../../src/include -I../../../src/include -DLIBICONV_PLUG -I/usr/local/include -isystem /usr/local/include -DHAVE_CONFIG_H -fopenmp -fpic -O2 -pipe -DLIBICONV_PLUG -fstack-protector -Wl,-rpath=/usr/local/lib/gcc5 -isystem /usr/local/include -fno-strict-aliasing -flto -fvisibility=hidden -c xmalloc.c -o xmalloc.o /usr/local/bin/gcc-ar5 -cr libtre.a regcomp.o regerror.o regexec.o tre-ast.o tre-compile.o tre-match-approx.o tre-match-backtrack.o tre-match-parallel.o tre-mem.o tre-parse.o tre-stack.o xmalloc.o ar: unrecognized option `--plugin' and in the successful poudriere run: ... cc -I. -I. -I../../../src/include -I../../../src/include -DLIBICONV_PLUG -I/usr/local/include -isystem /usr/local/include -DHAVE_CONFIG_H-fpic -O2 -pipe -DLIBICONV_PLUG -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -fvisibility=hidden -c xmalloc.c -o xmalloc.o /usr/local/bin/ar -cr libtre.a regcomp.o regerror.o regexec.o tre-ast.o tre-compile.o tre-match-approx.o tre-match-backtrack.o tre-match-parallel.o tre-mem.o tre-parse.o tre-stack.o xmalloc.o Looking (on the laptop) at plausible "ar" executables in /usr/local/bin, I see: g1-227(12.0-C)[3] (cd /usr/local/bin && ls -lTi gcc-ar* ar) 1850562 -r-xr-xr-x 2 root wheel 6368928 Mar 23 05:10:40 2017 ar 1850780 -r-xr-xr-x 2 root wheel25728 May 1 05:47:28 2017 gcc-ar49 1846261 -r-xr-xr-x 2 root wheel26192 Jun 30 04:57:30 2017 gcc-ar5 g1-227(12.0-C)[4] Apparently "ar" was installed by binutils-2.28,1, while the gcc-ar* were installed by gcc49-4.9.4_3 and gcc5-5.4.0_2, respectively. Weird. Peace, david -- David H. Wolfskill da...@catwhisker.org Congratulations on the sesquicentennial, Canada! :-) See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: math/R: Build failure after PORTREVISION for shlib change
On Thu, Jun 29, 2017 at 12:39:50PM -0300, Joseph Mingrone wrote: > ... > Everything matches. The successful build in poudriere even has the same > line that generates the error for you. I may try ktracing the build > /usr/local/bin/gcc-ar5 -cr libtre.a regcomp.o regerror.o regexec.o tre-ast.o > tre-compile.o tre-match-approx.o tre-match-backtrack.o tre-match-parallel.o > tre-mem.o tre-parse.o tre-stack.o xmalloc.o > > Could you have something in your environment or in make.conf that's > causing a problem? g1-227(11.1)[1] grep -v '^#' /etc/make.conf NET_SNMP_SYS_CONTACT="da...@catwhisker.org" NET_SNMP_SYS_LOCATION="variable" NET_SNMP_LOGFILE=/var/log/snmpd.log NET_SNMP_PERSISTENTDIR=/var/net-snmp SENDMAIL_MC=/etc/mail/laptop.mc WITH_BSD_JDK=TRUE WITHOUT_RUNTIME_CPUDETECTION= YES WITHOUT_CJK=YES NO_SUID_XSERVER=YES DEFAULT_VERSIONS+=linux=c6 INSTALL_AS_NCFTP=yes OPTIONS_SET=OPTIMIZED_CFLAGS DEFAULT_VERSIONS+= perl5=5.24 FORCE_PKG_REGISTER= YES PKG_NOCOMPRESS=1 g1-227(11.1)[2] > Joseph I'll be trying a poudriere run Saturday morning, and will report anything "interesting." Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org Do Congress's recent actions on health care qualify as "terrorist acts?" See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: math/R: Build failure after PORTREVISION for shlib change
On Wed, Jun 28, 2017 at 04:36:18PM -0300, Joseph Mingrone wrote: > Hi David, > > So far I haven't been able to reproduce any problems in an > 11.0-RELEASE-p1 jail. Could you send your list of port options? If I > can't reproduce any issues with the same options turned on, I will ask > you for a full build log. > > Joseph Thanks for taking a look. g1-227(11.1)[2] make -C /usr/ports/math/R showconfig ===> The following configuration options are available for R-3.4.0_1: ICU=on: Unicode support via ICU INFO=on: GNU info manuals LDOUBLE=on: Long double data type LETTER=on: US letter paper LIBR=on: Shared R library MEMPROF=off: Memory profiling via Rprofmem() and tracemem() NLS=on: Native Language Support RPROF=on: R profiling via Rprof() X11=on: X11 graphics device > Require GCC LTO=on: Use Link Time Optimization OPENMP=on: Parallel processing support via OpenMP > Require X11 GHOSTSCRIPT=on: Graphics device for bitmap files via Ghostscript JPEG=on: JPEG graphics device CAIROPANGO=on: Cairo graphics device and Pango multi-language text PNG=on: PNG graphics device TCLTK=on: Tcl/Tk GUI toolkit support TEXDOCS=on: Build/Install TeX-dependent documentation files TIFF=on: TIFF image format support > Options available for the single BLAS: you have to select exactly one of them ATLAS=off: ATLAS BLAS implementation OPENBLAS=off: OpenBLAS BLAS implementation NETLIB=off: Netlib BLAS implementation RBLAS=on: Use R-bundled BLAS implementation ===> Use 'make config' to modify these settings g1-227(11.1)[3] I also placed both "normal" and gzipped copies of the typescript from the (multiple) portmaster runs in <http://www.catwhisker.org/~david/FreeBSD/ports/>; see R.log (or R.log.gz). (I had run portmaster; it built a few things, tried math/R & died. I re-started portmaster, eliding math/R, but portmaster found it anyway... though it didn't show up in the list until several other ports were built successfully. I then tried again, skipping both math/R and databases/R-cran-DBI; all of the specified ports built OK. Then I tried just math/R & databases/R-cran-DBI; those failed (as before). I then specified 'MAKE_JOBS_UNSAFE=yes' in /etc/make.conf & tried the laast run again; still failed. Each time, I appended to the typescript.) Just in case it's relevant, as /usr/local/bin/gcc-ar5 is from gcc5-5.4.0_2: g1-227(11.1)[5] make -C /usr/ports/lang/gcc5 showconfig ===> The following configuration options are available for gcc5-5.4.0_2: BOOTSTRAP=on: Build using a full bootstrap GRAPHITE=off: Support for Graphite loop optimizations JAVA=on: Java platform support ===> Use 'make config' to modify these settings Peace, david -- David H. Wolfskill da...@catwhisker.org Do Congress's recent actions on health care qualify as "terrorist acts?" See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
