Re: Can't build a working package for texlive-texmf
On 20/04/2021 14:36, D'Arcy Cain wrote: I have been struggling with this for months. Has anyone else seen this? I have a network of servers and I like to build packages from source. I don't use Poudriere. I have a series of scripts that determine what needs to be built on the package server. I currently have 1,152 packages built and they all seem to work just fine except for lilypond. Every time I try to install it on another server pkg dumps core. I started installing the dependencies and eventually found that it is actually texlive-texmf that is failing. Over the last few months I have rebuilt every package and still get this core dump. I just recently upgraded to FreeBSD 12.2p6 and started over. I removed all packages except pkg which I rebuilt and forced an upgrade. I removed all of the distfiles from the ports server and all the files in /var/cache/pkg on the clients. Same problem. The one thing I notice is that the package is an order of magnitude larger than the second biggest file. Am I having a memory issue? I guess my next step is to install gdb and build pkg with symbols unless someone can point me to an easy answer. Just a note: you may have a debugger already installed as /usr/bin/lldb. Also, pkg, in contrast to other binaries, is not stripped, so the chances are that you are not going to have to rebuild anything. Cheers, Mateusz ___ 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: www/hiawatha error
Hi, On 16/04/2021 16:49, asci...@free.fr wrote: Hi, sending this because there is no maintainer for this port. This port doesn't run anymore on 13, probably because of regexp changes. It fails with message : "Error in regexp '\s*(;\s*)?--(\s|') Error initializing SQL injection detection." Problem is at the beginning of session.c I think. ___ 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" Cool, thanks for the report. Could you open a problem report on Bugzilla (https://bugs.freebsd.org/bugzilla/)? Thanks! Regards, Mateusz ___ 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: sysutils/uefi-edk2-bhyve isssue
On 23/02/2021 15:49, The Doctor via freebsd-ports wrote: DEFAULT_VERSIONS+=linux=c7_64 DEFAULT_VERSIONS+=ruby=2.7 DEFAULT_VERSIONS+=python=3.8 DEFAULT_VERSIONS+=pytho3=3.8 This looks like a typo BTW. ___ 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: net-im/signal-cli
Hi, On 12/16/20 9:02 PM, Miroslav Lachman wrote: I read your comment on revision 549450 - BROKEN FreeBSD 11 amd64. I really would like to build it and run it on my desktop FreeBSD 11.4 amd64. Is there some way to debug it and fix it for 11.4? I am building all my packages in poudriere, I can test something but I don't know what and how. I've done a couple of rounds of debugging but I couldn't get the port to build on 11.4. Surely, there is a way to fix it but I cannot commit more time to it unfortunately. I'll be happy to review patches, if someone manages to build net-im/signal-cli in poudriere. Regards, Mateusz Piotrowski ___ 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: Need help with python based port (home assistant)
Hi,
On 11/23/20 4:28 AM, Rozhuk Ivan wrote:
Hi!
Im trying to make Home Assistant port.
It requires many deps:
https://github.com/home-assistant/core/blob/dev/setup.py
"aiohttp==3.7.1",
"astral==1.10.1",
"async_timeout==3.0.1",
"attrs==19.3.0",
"bcrypt==3.1.7",
"certifi>=2020.6.20",
"ciso8601==2.1.3",
"httpx==0.16.1",
"importlib-metadata==1.6.0;python_version<'3.8'",
"jinja2>=2.11.2",
"PyJWT==1.7.1",
# PyJWT has loose dependency. We want the latest one.
"cryptography==3.2",
"pip>=8.0.3",
"python-slugify==4.0.1",
"pytz>=2020.1",
"pyyaml==5.3.1",
"requests==2.25.0",
"ruamel.yaml==0.15.100",
"voluptuous==0.12.0",
"voluptuous-serialize==2.4.0",
"yarl==1.4.2",
we have most of them, but many ports have different versions.
I made a hack:
post-patch:
@${REINPLACE_CMD} -e 's|requests==2.25.0|requests>=2.22.0|g' \
-e 's|cryptography==3.2|cryptography>=2.6.1|g' \
-e 's|aiohttp==3.7.1|aiohttp>=3.6.2|g' \
-e 's|==|>=|g' \
${WRKSRC}/setup.py
it force to use newer versions and make few downgrades.
With this HA install and start.
But on first start it show errors in console and download and install
some python packets that was hacked version and some packets that
was not in requires list.
(I suspest it set as deps in plugins/componets)
Questions:
1. Is it ok that I use hack to change required deps versions?
Or how to deal with it?
It is OK to change the required deps as long as the program keeps working. Sometimes, however, we
just add new ports for the specific desired versions of the dependencies (e.g.,
py37-sphinxcontrib-websupport11 and py37-sphinxcontrib-websupport).
2. Is it ok that HA download all deps that required into HA
work dir?
Should I add all these deps in port to prevent this?
If I understand correctly, HA is missing some runtime dependencies. Each runtime dependency should
be specified (e.g., via RUN_DEPENDS).
___
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: What are the benefits of NO_ARCH?
On 11/3/20 11:24 AM, Mateusz Piotrowski wrote: On 11/2/20 3:50 PM, Baptiste Daroussin wrote: On Mon, Nov 02, 2020 at 03:48:34PM +0100, Stefan Esser wrote: Am 02.11.20 um 15:33 schrieb Mateusz Piotrowski: I wonder if setting NO_ARCH=yes brings any significant benefits to how our ports collection works. I'd be grateful if you could shed some light on the importance of setting NO_ARCH whenever possible. NO_ARCH means that there is no need to build packages for each of the supported architectures, e.g. for pure interpreted scripts or data files that do not depend on byte-order and word-size (e.g. many font file formats). The result is reduced resources spent on building the packages, network traffic, disk space on mirrors and on distribution media. Yes that is the goal, in practice it is not yet the case, so it is purely informational, but that what we are aiming at yes. Thanks! I've added a note to the porter's handbook based on the information you provided: https://svnweb.freebsd.org/doc?view=revision&revision=54671 ___ 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: What are the benefits of NO_ARCH?
On 11/2/20 3:50 PM, Baptiste Daroussin wrote: On Mon, Nov 02, 2020 at 03:48:34PM +0100, Stefan Esser wrote: Am 02.11.20 um 15:33 schrieb Mateusz Piotrowski: I wonder if setting NO_ARCH=yes brings any significant benefits to how our ports collection works. I'd be grateful if you could shed some light on the importance of setting NO_ARCH whenever possible. NO_ARCH means that there is no need to build packages for each of the supported architectures, e.g. for pure interpreted scripts or data files that do not depend on byte-order and word-size (e.g. many font file formats). The result is reduced resources spent on building the packages, network traffic, disk space on mirrors and on distribution media. Yes that is the goal, in practice it is not yet the case, so it is purely informational, but that what we are aiming at yes. Thanks! ___ 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"
What are the benefits of NO_ARCH?
Hi ports@, I wonder if setting NO_ARCH=yes brings any significant benefits to how our ports collection works. I'd be grateful if you could shed some light on the importance of setting NO_ARCH whenever possible. Thanks, Mateusz ___ 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: Correct path for man pages
On 11/1/20 2:41 PM, Nuno Teixeira wrote:
I remember reading something about correct path for man pages:
${STAGEDIR}${PREFIX}/share/man/manN
or
${STAGEDIR}${MAN1PREFIX}/man/manN
Can't find original post about it.
Probably the CHANGES file in the ports tree:
20200115:
AUTHOR: b...@freebsd.org
${PREFIX}/share/man is now a valid location for manpages ${PREFIX}/man being
considered as deprecated.
Cheers,
Mateusz
___
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/oleo pkd-descr
On 9/23/20 6:34 PM, Montgomery-Smith, Stephen wrote: Dear Ports and people who recently modified the math/olea port, Do people agree with me that pkg-descr assumes you already know what oleo is? Or is it considered that people should read COMMENT in Makefile as well? I was thinking of changing pkg-descr to: Oleo is a light-weight spreadsheet that'll work in almost any environment. Oleo features a curses based interface (character mode), and also a LessTif (Motif) based graphical user interface. https://www.gnu.org/software/oleo/oleo.html Committed in 549778. Thanks! Mateusz ___ 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: [HEADS UP] Planned deprecation of portsnap
On 8/11/20 9:39 PM, Mike Clarke wrote: On Sunday, 9 August 2020 17:27:01 BST RW via freebsd-ports wrote: What I'd like to see is a simple way to update the ports tree to match what was used to build the current packages in the repository. Something I've felt in need of for a long time, and suggested from time to time in the past. What we need is a pkg command which returns the revision number of the ports tree which was used to build the current repository. When provided with that information I could run "svnlite up -q -r $REV $PORTSDIR" to keep my ports and packages in sync. I also think that would be great. ___ 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: set_rcvar() function use?
Hi,
On 7/2/20 8:54 PM, Hiroki Sato wrote:
> Pavel Timofeev wrote
> in :
>
> ti> Hello, dear community. I'm confused, please, help me.
> ti>
> ti> There is a rc.subr function which was buried[1] and resurrected[2] after a
> ti> couple of years in almost the same form.
> ti>
> ti> I don't know what happened behind the scenes, but I have a question.
> ti> Is it a preferable way to define a rc.conf variable these days in rc
> ti> scripts (again/over and over)?
>
> I resurrected it because I wanted to change the standard style to use
> set_rcvar() to declare the user-configurable variables, their default
> values, and descriptions without losing backward compatibility.
> There is no clear consensus on this migration, however.
>
> The primary motivation was to add multi-instance support in rc
> scrupts[1]. To support this, the set_rcvar() style was required.
>
> [1]
> https://lists.freebsd.org/pipermail/freebsd-current/2014-October/052706.html
>
> Another issue I am aware of is that rc scripts installed by ports/pkg
> that they cannot have related entries in /etc/defaults/rc.conf for
> the default values. So a lot of ports tend to end up with
> assignments in the rc scripts like this:
>
> : ${foo_enable=YES}
>
> This introduces inconsistency and it is difficult to find
> documentation about which knobs are available. The set_rcvar() style
> should mitigate this and also implements a support to obsolete a
> variable when needed. set_rcvar_obsolete() will convert the old
> value to the new variable automatically or emit an error if there is
> no compatibility between the old and the new.
>
> I committed set_rcvar() part only in [1], not whole of the
> multi-instance support. This is because it was quite difficult to
> control which version of rc.subr is installed. If rc scipts in ports
> use set_rcvar() on older versions of FreeBSD which do not support it,
> the port breaks. At this moment all of the supported FreeBSD
> versions have the resurrected set_rcvar(), so I think it is now safe
> to use it globally. Probably we might want to add a version number
> or feature flags in rc.subr to prevent this kind of situation.
>
> I am planning to revisit the multi-instance support shortly because I
> am using it for a long time and I think it is useful. While I did
> not receive a strong objection to it so far, it is also true that
> adopting the set_rcvar() style was not discussed properly. I would
> like more feedback before moving forward.
AFAIR, manu@ was concerned at some point that using set_rcvar() extensively
might result in slowdowns on embedded systems.
Regards,
Mateusz
___
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: Can anyone build www/node right now?
Hi Bradley, do you think that we should specify the minimal required Python version in www/node? Like, USES=python:build,3.7+? Here's the context: On 6/29/20 2:20 AM, Dutch Daemon - FreeBSD Forums Administrator wrote: > On June 28, 2020 22:54:57 DutchDaemon - FreeBSD Forums Administrator > wrote: > >> On 2020-06-28 22:49, Christoph Moench-Tegeder wrote: >>> ## Dutch Daemon - FreeBSD Forums Administrator (dutchdae...@freebsd.org): >>> In absence of a make.conf in the jail it pulled in python36-3.6.11 as the default. >>> Uhm. From your log, we see that you have a make.conf with a python >>> version override: >>> >>> 95. /usr/local/etc/poudriere.d/testamd64-make.conf >>> [...] >>> 116. DEFAULT_VERSIONS= perl5=5.30 python=3.6 python3=3.6 php=73 apache=2.4 >>> mysql=56 ssl=openssl >>> >>> The default "default python" is 3.7. >> >> >> Ah, it pulled in the generic /etc/make.conf., which was never there >> until I tested something (else) with it; forgot to remove it. > > Even worse: I had had a jail with the same name before, and that one had a > make.conf with Python > 3.6 in it. Always clear out your test configs when you're unoriginal with > your test jail names ;) > >> I'll try Python 3.7 in all of the build jails that need www/node and remove >> the hard Python default. > > That did indeed fix it, thanks again. > > ___ > 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" Cheers, Mateusz ___ 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: New feature suggestion: print-gh-tuple: Print GH_TUPLE corresponding to submodules of a GitHub repository ${GH_ACCOUNT}/${GH_PROJECT}
On 4/16/20 6:56 PM, Yuri wrote: I am suggesting a new feature: make print-gh-tuple https://reviews.freebsd.org/D24231 It works when USE_GITHUB=yes is set. When a GitHub repository has git submodules, that themselves can also have embedded submodules, it can traverse all of them and output the value of GH_TUPLE that would include all of them. Great idea! I've done something similar for x11/ly. It's great to possibly have something more general and available through out the whole ports tree. I'll try to take a look at the patch soon. Cheers, Mateusz ___ 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: Dropping maintainership of my Ports
On 3/28/20 5:33 PM, Peter Pentchev wrote: On Fri, Mar 27, 2020 at 05:35:44PM -0700, Neel Chauhan wrote: Hi freebsd-ports@, I would like to drop maintainership for the following Ports: Thanks, Neel! [snip] net/librsync2 sysutils/ioping sysutils/pick Hi, If no one has already stepped up, I'd like to try my hand at maintaining these three as a way of tentatively slowly coming back to FreeBSD. Sure! Could you submit appropriate patches to bugzilla? Thanks! Mateusz ___ 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: reccomendations of conference / party audio video software ?
On 3/24/20 11:31 AM, Baptiste Daroussin wrote: On Sat, Mar 21, 2020 at 04:38:11PM +, Bob Eager wrote: People have been saying good things about jitsi (Java based) bu the port didn't work on a quick try (my ports tree isn't very new though and there was no time to update it). The port is about a previous thing from jitsi (a SIP client) when people speak about Jitsi c'est speak about https://meet.jit.si aka https://jitsi.org/ The video bridge is in java and the frontend is in javascript with desktop apps iirc for those who do not want to use a browser. Note that on freebsd desktops it works well in firefox browser. No login required, no decidated required it just works fine. Is screen sharing working for 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"
Re: Anyone interested in helping with linux-wps-office ?
On 3/22/20 5:59 AM, Pedro Giffuni wrote: I recently got asked about WPS Office, a really nice office suite that works on the linuxulator: http://linux.wps.com/ ... So, I updated a basic port for it here: https://people.freebsd.org/~pfg/ports/linux-wps-office.tgz The above passes portlint but I really don't know well how linuxulator ports should work. I'd like to know more about those ports as well. Open questions: - Does the RPM stuff figure out the right PREFIX? In order words, is the path OK? - Do I have to add a softlink so the program can be executed? - What to do about desktop icons. - I still have to figure out what to do about fonts, if anything. As fair as I understand the documentation, everything should be installed in the default PREFIX (usually /usr/local). At least, that's what I did recently for the biology/linux-foldingathome port, which works nicely with our Linux compatibility layer. Only infrastructure packages (such as libraries) should be installed under /compat/linux. It would be great, however, to learn more from people who worked more with ports utilizing Linuxulator. Regards, Mateusz Piotrowski ___ 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: Help would be appreciated about rc scripts
On 3/21/20 12:33 PM, Lorenzo Salvadore via freebsd-ports wrote: Can anyone please take a look at review https://reviews.freebsd.org/D24104 ? My mentor would like an advice from someone with some expertise about rc scripts to check if everything is fine. Hmm, rc scripts. I'll take a look for sure! Also, there is an issue with licensing: if you want to give an advice about that issue as well it is welcome. I'd keep the license as is and just contribute the changes to the public domain as well. I've done something similar with sct[1] -- I just licensed all my improvements under the UNLICENSE license. Cheers, Mateusz Piotrowski [1]: https://www.freshports.org/accessibility/sct/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg: how to retrieve the messages ports emit after install?
On 3/18/20 5:20 PM, Chris wrote: IMHO this should be added to the pkg(8) man page. Maybe the EXAMPLES section? https://github.com/freebsd/pkg/pull/1819 Cheers, Mateusz ___ 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: atom-ide-1.45.0 Error build
On 3/18/20 5:12 PM, Alex V. Petrov wrote: 18.03.2020 18:57, Hiroki Tagato пишет: It appears the leveldown module fails to build with Node 12 or 13. Can you retry with Node 10? The port specifies www/node10 as a build dependency. Would it be possible to specify that the port depends on a package instead of a binary? For example, instead of node:www/node10 we would use node10>0:www/node10 in *_DEPENDS. Cheers, Mateusz ___ 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: Should 'Reported by' reflect who/which system reported the port to be out-of-date?
Hi, On 3/7/20 9:49 PM, Yuri wrote: I got a feedback that such use of 'Reported by' might be incorrect. I've never received any negative feedback about it. In fact, I believe it is a nice way of giving credits to some really useful services. Mateusz ___ 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: Downloading source archive from GitHub release instead of repo tar
On 3/7/20 12:53 PM, Stefan Bethke wrote:
I'm working on updating the Gitea port to 1.11, and I need to download the
source archive off the release page, instead of an archive of the Github repo.
The source archive on the release page contains additional files that are
needed for the build (Go and node modules that would need to be downloaded
during the build otherwise).
PORTNAME= gitea
DISTVERSIONPREFIX= v
DISTVERSION=1.11.2
USE_GITHUB= yes
How do I tell make that I do want to download the release tar.gz instead of the
repo archive? Specifically, I need to download
https://github.com/go-gitea/gitea/releases/download/v1.11.2/gitea-src-1.11.2.tar.gz
instead of
https://codeload.github.com/go-gitea/gitea/tar.gz/v1.11.2?dummy=/go-gitea-gitea-v1.11.2_GH0.tar.gz
In such case I'd just just use
MASTER_SITES=
https://github.com/go-gitea/gitea/releases/download/${DISTVERSIONFULL}/
and then set DISTNAME appropriately.
Cheers,
Mateusz Piotrowski
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: When to use TMPPLIST instead of pkg-plist?
On 2/29/20 12:15 AM, Mathieu Arnold wrote: On Fri, Feb 28, 2020 at 10:06:19PM +0100, Mateusz Piotrowski wrote: Do we have any (perhaps unwritten) policy for when to use TMPPLIST? And when should a port maintainer stick to pkg-plist? We do not. A port maintainer should stick to pkg-plist. That's what I thought. Is there a reason for it? Does it all boil down to that fact that pkg-plist is much more explicit and easier to debug/review? Or there is another reason? Cheers, Mateusz ___ 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"
When to use TMPPLIST instead of pkg-plist?
Hello ports@, recently I saw TMPPLIST being used for a relatively simple fonts port instead of pkg-plist to keep track of files to be installed by a port. I am quite surprised because I've always thought that this mechanism is reserved for special cases such as autoplist for Python packages. Do we have any (perhaps unwritten) policy for when to use TMPPLIST? And when should a port maintainer stick to pkg-plist? Cheers, Mateusz ___ 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: Timidity++ needs libarc as run dependency ??
On 2/27/20 3:54 PM, Marcin Cieslak wrote:
On Thu, 27 Feb 2020, Mateusz Piotrowski wrote:
On 2/26/20 3:20 PM, Hans Petter Selasky wrote:
On 2020-02-26 13:18, Mateusz Piotrowski wrote:
On 2/26/20 10:55 AM, Hans Petter Selasky wrote:
ld-elf.so.1: Shared object "libarc.so.1" not found, required by
"timidity"
pkg install libarc
It looks like libarc is already included in LIB_DEPENDS. It is not
included in the timidity++ package. It is only included with the
timidity++-${PKGNAMESUFFIX} packages (like timidity++-emacs).
I've never used timidity myself, so I am not sure why this is this
way.
Is there a reason why you installed timidity++ instead of one of
the timidity++-${PKGNAMESUFFIX} packages?
No specific reason. I just wanted to test some MIDI files.
And did "pkg instal xxx". Is timidity++ not a valid port/package?
It is a valid port. I am not sure why libarc is not a run-time
dependency here. Maybe just an oversight.
Maybe there is some bug with
.if !defined(PKGNAMESUFFIX)
during package building?
No idea...
___
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: Timidity++ needs libarc as run dependency ??
On 2/26/20 3:20 PM, Hans Petter Selasky wrote:
On 2020-02-26 13:18, Mateusz Piotrowski wrote:
On 2/26/20 10:55 AM, Hans Petter Selasky wrote:
ld-elf.so.1: Shared object "libarc.so.1" not found, required by
"timidity"
pkg install libarc
It looks like libarc is already included in LIB_DEPENDS. It is not
included in the timidity++ package. It is only included with the
timidity++-${PKGNAMESUFFIX} packages (like timidity++-emacs).
I've never used timidity myself, so I am not sure why this is this way.
Is there a reason why you installed timidity++ instead of one of the
timidity++-${PKGNAMESUFFIX} packages?
No specific reason. I just wanted to test some MIDI files.
And did "pkg instal xxx". Is timidity++ not a valid port/package?
It is a valid port. I am not sure why libarc is not a run-time
dependency here. Maybe just an oversight.
I've committed a patch in r527232
Cheers,
Mateusz
___
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: Timidity++ needs libarc as run dependency ??
On 2/26/20 10:55 AM, Hans Petter Selasky wrote:
Hi,
ld-elf.so.1: Shared object "libarc.so.1" not found, required by
"timidity"
pkg install libarc
It looks like libarc is already included in LIB_DEPENDS. It is not
included in the timidity++ package. It is only included with the
timidity++-${PKGNAMESUFFIX} packages (like timidity++-emacs).
I've never used timidity myself, so I am not sure why this is this way.
Is there a reason why you installed timidity++ instead of one of the
timidity++-${PKGNAMESUFFIX} packages?
Cheers,
Mateusz
___
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: Timidity++ needs libarc as run dependency ??
On 2/26/20 10:55 AM, Hans Petter Selasky wrote: Hi, ld-elf.so.1: Shared object "libarc.so.1" not found, required by "timidity" pkg install libarc and it works. --HPS ___ 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" I'll take a look. ___ 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: quark-server-g20180403
Hi, On Sat, 19 Oct 2019 at 11:56, BieHDC wrote: > can you please update this package to the latest release? > Sure! Thanks for the heads-up. I've just committed the latest version. BTW, do you know if there is a way to get a tarball of a commit from the Suckless servers? I was only able to find https://dl.suckless.org/ but it only contains releases and tags. PS: I dont know how this works since i am new around here and i dont > know if it is inappropriate to do this. In that case please forgive me. > This a great way. Thanks a lot for help! A slightly more official way would be to open a request for an update on Bugzilla: https://bugs.freebsd.org/ Cheers, Mateusz ___ 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: category for VPN softwares?
On Tue, 2 Apr 2019 at 10:58, Stefan Esser wrote: > Am 02.04.19 um 07:42 schrieb Koichiro Iwao: > > On Tue, Apr 02, 2019 at 06:41:51AM +0200, Kurt Jaeger wrote: > >> Create a real category vpn and move everything to it ? > > > > Sounds better! Gentoo has net-vpn category. Just FYI, Gentoo also have > > net-dialup category. PPP/PPPoE/L2TP softwares are put under net-dialup > > but I feel that classification is too fine. At least creating vpn or > > net-vpn souds good. > > How about a new "real" category vpn I am not sure if it should be vpn or net-vpn. I feel net-vpn is more suitable. > and preserving the current categories > of the ports as their additional categories (assuming that they are in net > vs. security for a reason). > I like the idea. ___ 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: New port. QEMU Guest Agent
Hi, On Sat, 27 Oct 2018 17:44:29 +0300 Eugene Kaltashkin wrote: >I made a port for QEMU Guest Agent. > >Git repo of this port at GitHub https://github.com/aborche/qemu-guest-agent > >But i need change original Makefile for qemu port /usr/ports/emulators/qemu >Can you help me ? Sounds cool! Could you submit patches to Bugzilla? This way we might start fixing potential issues before we start bringing it into the tree. Cheers, Mateusz ___ 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: Do you support creation of "chemistry" and "physics" virtual categories?
On 30 Jul 2018, at 10:16, Kurt Jaeger wrote: > > Hi! > >> I assembled the lists of 50 ports for the chemistry virtual category, >> and 25 ports for the physics virtual category: >> https://reviews.freebsd.org/D13481#350005 > [...] >> Do you support creation of "chemistry" and "physics" virtual categories? > > Yes. Yes. ___ 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: List of which pkg's have been downloaded
On Thu, 05 Apr 2018 16:32:11 -0400 Ernie Luzar wrote: >Goal = I want to get statistics from the pkg system mirrored servers >containing a count of how many times a pkg has been downloaded. > >First of all, are these statistics currently available? > >Who should I contact about getting these statistics? > >If not currently available, who should I contact about getting the >information needed to design a method to capture these statistics? > >I am willing to do the coding and testing to make this happen. That would be really cool, I think. For the time being I've added this idea to our wiki so that it isn't forgotten. Cheers, Mateusz Piotrowski ___ 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: Should we Rust warnings suggesting adding work/stage/usr/local/bin to the PATH?
>On Thu, May 17, 2018 at 3:26 PM, Stefan Esser wrote:
>
>> Am 17.05.18 um 14:42 schrieb Mateusz Piotrowski:
>> > When I build Rust packages I get warnings like this one:
>> >
>> >> warning: be sure to add `/usr/home/0mp/ports/games/
>> >> genact/work/stage/usr/local/bin` to your PATH to be able to run
>> >> the installed binaries
>> >
>> > It is not very helpful when building ports. Do you think that we should
>> > try to mute it by default?
>>
>> I have seen such a message when building a Haskell based port, too.
>>
>> Seems there are more languages (or build systems) that perform such
>> a check and emit a misleading warning ...
On Mon, 21 May 2018 23:38:35 +0200
Luca Pizzamiglio wrote:
>I've no idea how, but it's obviously misleading and somehow wrong, we
>should mute this message
Folks on ##rust on Freenode suggested me to add the target directory to
PATH:
> PATH="$PATH:/path/to/bin" cargo install
I've already looked at Uses/cargo.mk, but it's not obvious to me how to
do it properly. We might add an extended PATH to CARGO_ENV but I don't
know how to get the path that the program is going to be actually
installed (like ${STAGEDIR}${PREFIX}/bin).
I've not looked into Haskell code yet.
___
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: Request clear steps for updating own port
On Mon, 21 May 2018 04:47:56 +0530 Manish Jain wrote: >Hi, > >I have an active port (sysutils/mkdesktop) which I maintain myself. > >A few days back, I had to upgrade the port from 1.6 to 1.7 so as to >reflect new names of kde4 packages. > >I seem to have completely lost memory of what I have to do to get the >port updated properly in FreeBSD ports. Can someone be kind enough to >guide me what steps are needed for updating one's own port? > >My port uses GitHub and is located at: >https://github.com/bourne-again/mkdesktop > >Essentially, I have an updated Makefile/distinfo which I need to get >merged into FreeBSD ports. > >I have updated the shar attachment for the port at the URL where the >port was originally submitted: > >https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221370 I'd open a new issue if you wish to update your port. The title of the issue could be something like: sysutils/mkdesktop: Update to 1.7 Make sure to upload the diff with the new version of your port. Shar is OK, I guess, but a patch is much much better. The handbook has some useful hints as well probably: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/port-upgrading.html Good luck! Mateusz ___ 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"
Should we Rust warnings suggesting adding work/stage/usr/local/bin to the PATH?
Hello, When I build Rust packages I get warnings like this one: > warning: be sure to add > `/usr/home/0mp/ports/games/genact/work/stage/usr/local/bin` to your PATH to > be able to run the installed binaries It is not very helpful when building ports. Do you think that we should try to mute it by default? Regards, Mateusz ___ 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: request for a new port + package
On Fri, 20 Apr 2018 04:22:32 +0800 Julian Elischer wrote: >On 9/4/18 7:15 pm, Eugene Grosbein wrote: >> On 09.04.2018 14:16, Mayuresh Kathe wrote: >> >>> how do i place a request for a new port + package? >>> the sources for my requested tool are available at >>> http://www.t3x.org/files/zenlisp.zip and the author of that tool has >>> granted permission to move it from the existing "public domain" >>> license to any "bsdl" license. >> The package is created automatically once new port is created and >> added to FreeBSD Ports collection. You can create and submit new >> port yourself, just read >> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ > >It seems to me that the description of what to do to make a port >is somewhat recursive by which I mean you need to understand >what it says before you read it. if you don't already know the jargon, >it is all Greek. (Apologies to any Greeks on the list). >I think it would be a pretty cool project to write a tool that asks >lots of questions and then eventually spits out a port Makefile. >it could allow the user to browse to places and then analyse the >links used etc. >I think the port writer's handbook is a bit intimidating to new ports >submitters. You might be interested in this: https://reviews.freebsd.org/D12921 Cheers :) MP ___ 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: port x11-wm/icewm does not have a pkg?
Hello, On Thu, 03 May 2018 12:50:24 +0200 "Ronald Klop" wrote: >I can't install a pkg of x11-wm/icewm. But I can't see in the port >why. It seems to have a proper license GPLv2 and is distributable. It looks like it's simply broken because it does not compile probably due to the switch to a C++11. I've opened an issue on Bugzilla for this.[1] It seems to require some minor fixes but I don't have time for this unfortunatelly at the moment. You may look at those errors on your own. Just download the ports[2] and then run # cd /usr/ports/x11-wm/icewm # make If you would like to work on this issue and write some patches then I'm ready to assist you. Cheers, Mateusz [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227951 [2]: https://www.freebsd.org/doc/handbook/ports-using.html ___ 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: Committing ${name}_limits patches for the rc files of various databases
Hi!
On Sat, 21 Apr 2018 20:44:05 +0200
Kirill Ponomarev wrote:
>On 04/21, Mateusz Piotrowski wrote:
>> Some of the patches were already incorporated into the ports tree,
>> but many of them are still waiting to be committed. Recently, an
>> update to database/mongodb36 was committed[2], which not only does
>> not solve the problem of the mongodb36 daemon to be broken on
>> FreeBSD 12.0-CURRENT but also introduces parts of my old patches,
>> which were marked obsolete[3].
>
>Please contact maintainer and resolve these issues.
Thanks for reaching out :)
I will contact the maintainer. It looks like the maintainer integrated
an old ${name}_limits patch locally and then submitted only a part of it
when submitting the upgrade to 3.6.4[1].
>I didn't see any objections and proposals from you in this PR.
True, I could have act quicker. Actually, I didn't look into the patch
back when it was submitted because I thought that it is just an update
(which leaves the ${name}_limits issue unresolved as it wasn't mentioned
anywhere in the issue). I'll pay more attention next time.
Regards,
Mateusz Piotrowski
[1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227636
___
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"
Committing ${name}_limits patches for the rc files of various databases
Hello,
A few weeks ago I discovered a regression caused by the standardization
of the mechanism used to limit daemons resources with limits(1). This
feature was introduced in r328331[1]. Basically, it defines that
limits(1) could be controlled via rc.conf(5) using ${name}_limits
variables as defined in rc.subr(5).
Unfortunately, many database rc scripts have already used ${name}_limits
variables with incompatible semantics. This is why I worked with some
FreeBSD committers and developers on a set of patch for those affected
databases. Thanks to their reviews and testing effort I was able to
open an issue on Bugzilla for every affected database port and provide a
few revisions of patchs for each of them.
Some of the patches were already incorporated into the ports tree, but
many of them are still waiting to be committed. Recently, an update to
database/mongodb36 was committed[2], which not only does not solve the
problem of the mongodb36 daemon to be broken on FreeBSD 12.0-CURRENT but
also introduces parts of my old patches, which were marked obsolete[3].
I am deeply concerned about the whole situation and after a few weeks of
waiting I decided to step forward and bring community's attention.
The meta issue with all the ports listed is available here[4]. It has
got links to all the other issues and patch with a proposed UPDATING
entry.
I understand that there a lot of work to be done for committers in every
corner of the FreeBSD system. If anyone, however, would like to mentor
me and help me commit those changes into our ports tree then I am 100%
eager to get started. I'd really appreciate it. :)
Cheers & happy hacking,
Mateusz Piotrowski
[1]: https://svnweb.freebsd.org/base?view=revision&revision=r328331
[2]: https://svnweb.freebsd.org/ports?view=revision&revision=467897
[3]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226907#c11
[4]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227205
___
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, 3 Apr 2018 17:34:25 +0200 Mathieu Arnold wrote: >On Tue, Apr 03, 2018 at 05:07:22AM -0700, David Wolfskill wrote: >> 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. > >I assumed pkg updating worked without a /usr/ports, seems I was wrong. FWIW, there are UPDATING RSS feeds: https://wiki.freebsd.org/Ports/#Services ___ 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"
Regression affecting some database daemons on 12-CURRENT
Hello,
Due to the changes in rc.subr introduced by r328331[1] some of the
database services are broken on FreeBSD 12-CURRENT.
Before r328331 some database services defined a bool variable
`${name}_limits`. When it was set to YES it triggered limits(1) to run
before a daemon was started.
Revision 328331 introduced a standard mechanism to do it. As a result
daemon maintainers/developers no longer have to roll out their own
solutions. The problem is that the semantics of the new common
mechanism is not compatible with many service files. `${name}_limits`
used to be a bool variable whereas now it is a string of extra flags to
be passed to limits(1).
The following command reveals a list of potenially affected ports:
$ cd /usr/ports
$ find . -mindepth 4 -maxdepth 4 -type f ! -name '*patch*' \
-exec grep -l _limits {} \+ | \
awk -v FS=/ -v OFS=/ '{print $2,$3}' - | sort | uniq
databases/arangodb32
databases/arangodb33
databases/clickhouse
databases/mariadb100-server
databases/mariadb101-server
databases/mariadb102-server
databases/mariadb55-server
databases/mongodb
databases/mongodb32
databases/mongodb34
databases/mongodb34-rocks
databases/mongodb36
databases/mysql55-server
databases/mysql56-server
databases/mysql57-server
databases/mysql80-server
databases/mysqlwsrep56-server
databases/mysqlwsrep57-server
databases/percona55-server
databases/percona56-server
databases/percona57-server
I confirm that the problem exists in all those ports.
The ports maintainers received a BCC of this message.
Initially, I thought that this bug is related only to the
databases/mongodb36 port but it turned out that it is a bigger issue.
The issue on Bugzilla for monogodb36 is here[2].
FWIW, I've submitted an update to the rc.subr manual to improve the
documentation of that new ${name}_limits variable.[3]
Regards,
Mateusz Piotrowski
[1]: https://svnweb.freebsd.org/base?view=revision&revision=r328331
[2]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226907
[3]: https://reviews.freebsd.org/D14928
___
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: New branch
On Sun, 1 Apr 2018 11:22:45 -0600 Adam Weinberger wrote: >> On 1 Apr, 2018, at 11:13, Andreas Sommer via freebsd-ports >> wrote: >> >> The Wiki (https://wiki.freebsd.org/Quarterly_Branch) says branches >> are created "at the beginning of every yearly quarter in January, >> March, July, September" (2-4-2-4 months, each). It seems those start >> dates were never the case, but the ports team uses fixed 3-month >> quarters as expected. Someone may want to clarify/edit ;) >> >> Thanks, >> Andreas > >Hah! Done, thanks Andreas. FYI, the Quaterly_Branch wiki page has been moved to https://wiki.freebsd.org/Ports/QuarterlyBranch ___ 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: redshift-1.7_4
On Sat, 10 Mar 2018 07:45:15 -0600 Mark Felder wrote: >On Fri, Mar 9, 2018, at 16:43, Aurélien Murith wrote: >> Hello! >> >> I read you are the maintainer of the redshift port. It is wildly out >> of date, current upstream version is 1.11, published two years >> ago... could you please update it? >> >> Thanks >> >> A.M. >> > >It was frozen because the new version required Python 3.x and we >couldn't have 2.x and 3.x packages at the same time. That problem is >gone now, but I haven't updated it quite yet. I'll look at it some >more today. > > There's also accessibility/sct/ [1], which works similarly to Redshift (some say it produces better colors). sct does not change the screen temperature automatically, however. [1]: https://www.freshports.org/accessibility/sct/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Is there possible run a MacOS X binary
On 8 Dec 2016, at 14:07, mokhi wrote: > I had started a writing a Mach-O image activator monthes ago, but > time/daily-life distracted me from continuing it. > Maybe some day I continue it :D > Currently it's available on my github[1] if it helps. > I had some success-like running of some super-simple less-than 'return > A+B' programs with it :) Have you considered adding it to the FreeBSD Google Summer of Code Ideas wiki[2]? Maybe some brave student will like the idea and decide to spend some time on this project. Cheers, -mateusz [2]: https://wiki.freebsd.org/SummerOfCodeIdeas ___ 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"
