nginx-full version numbering question
hey there - i had a question about an apparent version numbering issue with the nginx-full port: https://www.freshports.org/www/nginx-full/ on April 10th the version number is:1.20.2_9,2 then on the next update (may 31) the version number seems to go backwards: 1.22.0_10,2 i was curious if that was intended? this makes it a little awkward to upgrade a locally patched version of the port from before May 31, as i'll have to uninstall then install to pick up the latest upstream (which contains a fix i was patching out of tree). thanks! -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA
Re: nginx-full version numbering question
On Sun, Aug 28, 2022 at 11:05:24PM +0200, Michael Gmelin wrote: > > > > On 28. Aug 2022, at 19:23, Pete Wright wrote: > > > > hey there - i had a question about an apparent version numbering issue > > with the nginx-full port: > > https://www.freshports.org/www/nginx-full/ > > > > on April 10th the version number is: 1.20.2_9,2 > > then on the next update (may 31) the version number seems to go backwards: > > 1.22.0_10,2 > > > > Hi Pete, > > What makes you think that 1.22.0 is smaller than 1.20.2? > dyslexia - i transposed some numbers when looking at this. i'm going to whipe the egg off my face now. sorry for the noise on this one folks. -pete -- Pete Wright p...@nomadlogic.org
Re: Recover from a corrupt pkg DB
On Tue, Aug 30, 2022 at 09:36:52AM -0700, Kevin Oberman wrote: > I had a crash while building ffmpeg on a new system. The build had not > begun, so I don't think ffmpeg is really an issue. portmaster(8) was > walking the dependency tree when the system panicked and, after a reboot > and full fsck, I get the error: > pkg: sqlite error while executing PRAGMA user_version; in file > pkgdb.c:2357: database disk image is malformed > > Is there any way to rebuild the DB or, if not, how do I remove it and start > from scratch? I ran into a similar issue a while back, I discovered I was able to recover by using one of the automated backups generated at: /var/backups/pkg.sql.xz* I can't remember the details, but I think it involved replacing repo-FreeBSD.sqlite in /var/db/pkg/. hope this helps, -pete -- Pete Wright p...@nomadlogic.org
Re: security/portsentry removal
On 4/8/23 12:47 AM, Andrea Venturoli wrote: On 4/8/23 04:56, Mel Pilgrim wrote: Can anyone suggest something equivalent in the port tree? Have a look at fail2ban. It's design intent is monitoring running services, but really it's just a set of log file regex filters. Anything that logs network activity can feed it. Hello and thanks for answering. In fact I'm already using fail2ban for "running" services. Portsenty is a bit different, in that it's conceived to listen on ports used by non-running services. I.e. Got a SMTP server? Let fail2ban check its logs. No? Let portsentry listen on port 25. I thought about writing regexes for fail2ban to check if ipfw denied access to ports where portsentry used to listen. So far it's the best idea I've come up with, but I hoped for something simpler (i.e. more close to how portsentry worked). would blacklistd(8) meet your requirements? i use it to block ssh login spammers with decent success. its part of the base system as well, but does require pf. -p
Re: Guidance on creating a port for an npm installed tool
On 6/9/23 11:11, Patrick M. Hausen wrote:
Hi all,
is there some general guide on how to go about creating a port
for anything implemented in node.js and using npm to download
all sorts of dependencies at build/install time?
I'd like to see a port of this:
https://github.com/louislam/uptime-kuma
Similarly a port of mineos would be awesome.
Cloning from Github and running npm works and delivers a
functional installation in ${WRKSRC} ...
What now?
I did not find any detailled help in the handbook or by searching.
There seems to be a general method if all modules are available
in npm (they have a repository it seems).
But what with products like these?
For Go applications there are very convenient tools to get
all the dependencies into the port Makefile and do it in a clean way.
Section 6.5.8 here:
https://docs.freebsd.org/en/books/porters-handbook/special/#building
So any help with porting these would be greatly appreciated.
i've had to build node/js code in the past internally and i've found
that whole ecosystem is awkward at best to work with (ports or not).
i did poke around the ports tree just now and found www/hedgedoc which
makes use of yarn for building, it may be worth taking a look at that
Makefile for inspiration. for my internal pkgs i did something similar
that is in the "do-build" section iirc.
-pete
--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA
Re: chromium + foreign-cdm not working?
On 10/3/23 11:32 AM, j...@chen.org.nz wrote: Hi, I noticed the inclusion of foreign-cdm support to www/chromium, and decided to try this out. However, any effort to play content from Netflix results in a failure. I've got: linux_enable="YES" in /etc/rc.conf, and the port pulls in linux-base-c7 as well. The chromium logs from stdout all end with: lib.cpp:80: info: CreateSessionAndGenerateRequest; promise_id = 3; session_type = 0; init_data_type = 0; init_data = 1bb11863200; init_data_size = 52 worker.cpp:240: info: createSessionAndGenerateRequest *** Fatal uncaught kj::Exception: worker.cpp:546: unimplemented: CreateFileIO *** Fatal uncaught kj::Exception: capnp/rpc.c++:2778: disconnected: Peer disconnected. stack: 1bb18037f18 1bb1802c580 1bb1816a310 [34603:-692588544:1004/072526.678703:ERROR:mojo_cdm.cc(118)] Remote CDM connection error: custom_reason=0, description="" Any ideas on how to get this working? Cheers If you haven't seen this already it's def work a look: https://github.com/mrclksr/linux-browser-installer this is what i use to run linux-chrome on my freebsd workstations. it works well with most of the linux/win/mac only websites out there (how's that a thing again?). i run it side-by-side with my native freebsd chromium install and have no issues. cheers, -pete -- Pete Wright p...@nomadlogic.org
sysutils/py-salt broken
hello, it looks like after a recent update of saltstack to version 3007 it stopped working on freebsd. there is a bug here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278149 i've verified the attached patch works as well. i was hoping we could some more eyes on this as the published packages for py-salt are non-functional. this is pretty disruptive to folks who have any sort of systems automations in place, so i'm sure you'll find no lack of people (myself included) who can help with testing verification. thanks! -pete -- Pete Wright p...@nomadlogic.org
www/py-gunicorn rc script change
hello - i filed this PR a little while ago and was hoping to get some eyes on it. i'm using the patched version of the rc script proposed in my production environment successfully and was hoping it could be picked up upstream. in fact without this patch things like newsyslog won't work correctly. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281005 thanks! -pete -- Pete Wright p...@nomadlogic.org
databases/redis PR request
hello, a little while ago I filed this PR asking to enable TLS by default for databases/redis: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263729 I was hoping someone could take a look at it? i should note - by enabling TLS by default it only enables the options to use TLS for both the redis client and server and doesn't seem to have any negative impact on clear-text operation. the TLS support for the client is a requirement for my $JOB personally, and would assume it would be for others as well. thanks! -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA
Re: Compiling the port graphics/drm-515-kmod gives compile errors
On 2/18/25 11:35, Edwin Ancaer wrote: Hello, I have this 2nd hand laptop where I installed FreeBSD 14.2-RELEASE FreeBSD 14.2-RELEASE releng/14.2-n269506-c8918d6c7412 GENERIC amd64. It seems to have a NVIDIA graphics card: | | ||| |[edwin@ottopedi ~]$ pciconf -lv | grep -B4 VGA vgapci0@pci0:0:2:0: class=0x03 rev=0x09 hdr=0x00 vendor=0x8086 device=0x0a16 subvendor=0x17aa subdevice=0x3800 vendor = 'Intel Corporation' device = 'Haswell-ULT Integrated Graphics Controller' class = display subclass = VGA [edwin@ottopedi ~]$ this is an integrated Intel GPU, which should be supported by the drm-kmod. I tried to install the package graphics/drm-515-kmod. pgk install said there was no such package, and when compiling with make install I got the compilation errors as in the attached file. Can anybody find what I am doing wrong here? what happens when you attempt to install the metaport like this: pkg install drm-kmod that *should* pick the right version and provide instructions on configuring it after installing the package. -pete -- Pete Wright p...@nomadlogic.org
Re: Compiling the port graphics/drm-515-kmod gives compile errors
On Tue, Feb 18, 2025 at 09:48:03PM +0100, Edwin Ancaer wrote: > Hello Pete, > > thanks a lot for your replay. Sorry to bother you guys for that. But I have > one more question if I may. > > The install procedure ends with: > Please note that this package was built for FreeBSD 14.1. > If this is not your current running version, please rebuild > it from ports to prevent panics when loading the module. > > > As I have FreeBSD version 14.2, should I really build from the port? yes that's most likely correct. looking at your original error it wasn't clear to me what the issue was. to cover the basic's - you had a recent checkout of both the 14.2-RELEASE source and the latest ports collection too right? then you went into graphics/drm-kmod and ran "make package" which resulted in the compilation exception? -pete
Re: Any interest in lang/rust-bin?
> On Jun 6, 2025, at 6:44 AM, Vidar Karlsen wrote: > > Hello, > > In an attempt to reduce build times, a review[1] for lang/rust-bin as a > new port was floated last year, but didn't get a whole lot of traction. > > While this is unlikely to be used as the default rust toolchain due to > it being a precompiled binary from an external source, I believe it > would be useful for many of us who build our own packages. > > Is there any interest in picking this up and getting it into the tree? > > [1] https://reviews.freebsd.org/D43341 > > Too long; didn't click: the review adds a port for a pre-compiled rust > toolchain and the Mk/bsd.default-versions.mk scaffolding for setting > DEFAULT_VERSIONS+=rust=rust-bin. I could see this being very helpful for people dealing with python packages. You’ll still need to compile rust code - but not having to build rust itself would be a timesaver for my CI/CD pipelines. -Pete
Re: Any interest in lang/rust-bin?
On 6/6/25 06:57, Tomek CEDRO wrote: On Fri, Jun 6, 2025 at 3:44 PM Vidar Karlsen wrote: Hello, In an attempt to reduce build times, a review[1] for lang/rust-bin as a new port was floated last year, but didn't get a whole lot of traction. While this is unlikely to be used as the default rust toolchain due to it being a precompiled binary from an external source, I believe it would be useful for many of us who build our own packages. Is there any interest in picking this up and getting it into the tree? [1] https://reviews.freebsd.org/D43341 Too long; didn't click: the review adds a port for a pre-compiled rust toolchain and the Mk/bsd.default-versions.mk scaffolding for setting DEFAULT_VERSIONS+=rust=rust-bin. Why not pkg install rust ? i think that's workable but is pretty suboptimal. our current rust package includes lots of rust source files, tons of HTML documentation (7 files!) and lots of other small files not really needed for compiling code or using cargo. while this is great for a general purpose port/pkg if you are developing rust - i could find it helpful to have a slimmed down package that is faster to install on VMs. for example cutting down on the time for an automated build or unit-test where you pay by the minute is a good thing. as-is the current rust package takes quite a while to install, granted its not a show stopper but imho a rough patch. -pete -- Pete Wright p...@nomadlogic.org
Re: Any interest in lang/rust-bin?
On 6/7/25 7:46 AM, Mathieu Arnold wrote: On Sat, Jun 07, 2025 at 04:36:34PM +0300, Gleb Popov wrote: On Sat, Jun 7, 2025 at 4:19 PM Mathieu Arnold wrote: Hi, I am sorry but I do not understand, you are basically re-inventing `pkg install rust`, but from within a port, it makes little sense. It makes sense for Poudriere users that often have to recompile lang/rust, but would like to avoid that. Well, I'm not sure this needs to be spelled out, but, well, people who decide to build their own ports have to, well, build their own ports. If they don't want to build their own ports, they should be using the packages we provide, or at least use the poudriere option that will fetch the packages instead of building them. But adding binary packages to the ports tree makes absolutely no sense. IMHO there should be a middle ground here, our rust port contains over 40k html files and documentation. this seems wild that we just force people to deal with that rather than trying to improve things for a wider set of users. maybe the answer is a no-doc version of the package? $ pkg list rust | grep html | wc -l 7 $ for low power vm's or systems its super wasteful to force installation of so many small files. rust/cargo is slow enough, but having to wait ages for rust itself just makes things needlessly more painful. -pete -- Pete Wright p...@nomadlogic.org
Re: Any interest in lang/rust-bin?
On 6/7/25 8:44 AM, Guido Falsi wrote: On 6/7/25 17:18, Pete Wright wrote: for low power vm's or systems its super wasteful to force installation of so many small files. rust/cargo is slow enough, but having to wait ages for rust itself just makes things needlessly more painful. IMHO this is better solved by building on more powerful machines and deploying to low power VMs. CI systems are specific for this kind of need AFAIK. But not knowing your specific use case I cannot be sure. that's my specific use case - automated ci/cd infrastructure that charges per-min. the main annoyance for developers is that rust is an ancillary dependency for building python packages and dependencies. for modules with c it's a non issue because we can generally use the useland clang/llvm. but having to wait like 60seconds to install 40k+ files just so rustc can run is a pretty big annoyance - esp when linux based workflows have already optimized on this front. the alternative is maintaining our own images for CI/CD...which is a lot of uneeded admin overhead imho. we already have to jump through enough hoops to get wheel dists built internally that contain rust code precompiled as is since the rust community doesn't treat freebsd as a tier-1 platform. so this is just more friction with little upside for most use-cases. -pete -- Pete Wright p...@nomadlogic.org
Re: Any interest in lang/rust-bin?
On 6/7/25 10:06 AM, Guido Falsi wrote: On 6/7/25 18:53, Pete Wright wrote: On 6/7/25 8:44 AM, Guido Falsi wrote: On 6/7/25 17:18, Pete Wright wrote: for low power vm's or systems its super wasteful to force installation of so many small files. rust/cargo is slow enough, but having to wait ages for rust itself just makes things needlessly more painful. IMHO this is better solved by building on more powerful machines and deploying to low power VMs. CI systems are specific for this kind of need AFAIK. But not knowing your specific use case I cannot be sure. that's my specific use case - automated ci/cd infrastructure that charges per-min. the main annoyance for developers is that rust is an ancillary dependency for building python packages and dependencies. for modules with c it's a non issue because we can generally use the useland clang/llvm. but having to wait like 60seconds to install 40k+ files just so rustc can run is a pretty big annoyance - esp when linux based workflows have already optimized on this front. the alternative is maintaining our own images for CI/CD...which is a lot of uneeded admin overhead imho. we already have to jump through enough hoops to get wheel dists built internally that contain rust code precompiled as is since the rust community doesn't treat freebsd as a tier-1 platform. so this is just more friction with little upside for most use-cases. This is a very specific thing. Anyway I think the way to get a "rust- lite" package is via subpackages. What the best way is to manage your CI environment is a completely different thing. lol - well i'm happy that someone is at least is starting to recognize not everyone needs 40k html files installed for rust. maybe we can stop this bike shed now. -p -- Pete Wright p...@nomadlogic.org
Re: Dovecot
On 7/1/21 3:59 PM, @lbutlr wrote: On 01 Jul 2021, at 16:45, The Doctor wrote: On Thu, Jul 01, 2021 at 04:21:31PM -0600, @lbutlr wrote: The current version of dovecot is 2.3.15. The newest ports version is 2.3.13_1 dovecot-2.3.13_1 is vulnerable: dovecot -- multiple vulnerabilities CVE: CVE-2021-33515 CVE: CVE-2021-29157 WWW: https://vuxml.FreeBSD.org/freebsd/d18f431d-d360-11eb-a32c-00a0989e4ec1.html dovecot-pigeonhole-0.5.13 is vulnerable: dovecot-pigeonhole -- Sieve excessive resource usage CVE: CVE-2020-28200 WWW: https://vuxml.FreeBSD.org/freebsd/f3fc2b50-d36a-11eb-a32c-00a0989e4ec1.html These CVEs were addressed in 2.3.14.1. Any idea what the delay is? Where is the person responsible for the ports? No idea. Some people have emailed and received no reply. looks like this is actively being worked on? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256860 -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA
Re: OT: Freshports has been unreachable for over 24hrs. Is it just me?
On 7/29/21 11:15 AM, Chris wrote: Sorry. I'd have attempted to contact Dan directly. But given I can't reach freshports... My upstream BGP seems to be in order as I have zero trouble with any other destination other than freshports. Here's my experience # traceroute freshports.org traceroute to freshports.org (54.227.255.74), 64 hops max, 40 byte packets ... 6 ae21.cr9-chi1.ip4.gtt.net (141.136.108.245) 79.236 ms 56.609 ms 60.092 ms 7 76.74.1.10 (76.74.1.10) 71.455 ms 69.593 ms 62.251 ms 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 52.93.28.74 (52.93.28.74) 86.625 ms 52.93.28.84 (52.93.28.84) 75.426 ms 52.93.28.82 (52.93.28.82) 86.000 ms 17 * 52.93.28.72 (52.93.28.72) 141.229 ms * 18 * * * 19 * * * 20 * * * 21 * * * 22 ec2-54-227-255-74.compute-1.amazonaws.com (54.227.255.74) 76.154 ms 76.348 ms * ping(8) reveals no difficulties. Yes, I run a firewall. But nothing is set that would block my ability to reach freshports. Dan mentioned yesterday that they were getting DDoS'd: https://twitter.com/DLangille/status/1420554141022097412 But I can verify it is loading as expected on my end as of today. hope this helps with your debugging. -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA
Re: RFC: vim default GUI
On 8/2/21 5:08 AM, Pietro Cerutti wrote: On Aug 02 2021, 11:51 UTC, Adam Weinberger wrote: Hello, ports users, I’ve never liked that the default vim package has a huge number of dependencies. GTK3 is a beast of a dependency, carrying dozens of packages with it. I would like to reduce this, but I want to gain insight from you all first. My thought is to flavorize the port and make separate packages for each of the GUI toolkits: -console (TUI-only), -gtk3, -gtk2, -x11, -motif, etc. I would like to make -console the default, meaning that the DEFAULT vim port is console-only. This would be disruptive: the default package would no longer come with gvim! My question is: how disruptive would this be for you? Would requiring people to install vim-gtk3 rather than vim be unduly burdensome? Would it be better to maintain the status quo? I’m really interested in your insight here. I'd love a console-only vim by default! would the idea be to deprecate the "vim-console" port? i'm quite happy with vim-console myself (and use vim-tiny on servers when needed) but i'd be interested to hear about how many people actually use the X11 enabled vim features. -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA
