Re: poudriere, FLAVOR and rebuilding for python3.6
On 09/09/2018 19:34, Bjarne wrote: > > I have been using python 2.7 so far for all ports, which means all > python packages are built as py27-something. These python packages are > all automaticcaly build as dependencies from other packages, for example > like py27-dnspython which is a requirement of mailman. > > Now I am trying to change to python36, but can't get the py36 packages > to build. In the transition period, I would like to simultaneously have: > py27-something > py36-something > > > In make.conf for the jail I set: > DEFAULT_VERSIONS+= python=3.6 python=2.7 This does not do what you're expecting, and will be equivalent to just 'python=2.7' > I would expect a new "poudriere bulk" command would build all > py36-something for me, but no, got nothing. > No packages where build. > > > I added the follwing to poudriere.conf: > FLAVOR_DEFAULT_ALL=yes > Still without any luck. > > I can of course specify that I want to build for example dnspython and > then poudriere builds py36-dnspython, but that means I will have to go > through all dependencies by hand. > > So what am I supposed to do. OK, there are two ways of handling this. Firstly you can specify a package as: some/port@all in the list of packages you feed to poudriere. I think you can use that on a package which is not itself flavoured, and the effect is inherited by flavoured dependencies, but you'll need to experiment. If you do this explicitly for python ports it will result in building both python-2.7 and python-3.6 versions. Secondly you can build your packages with one default setting, and then do an incremental bulk using the other default setting, which should result in you ending up with both flavours in your repository. Something like: # echo 'DEFAULT_VERSIONS+= python=3.6' > /usr/local/etc/poudriere.d/python36-make.conf # poudriere bulk -c -f /usr/local/etc/poudriere.d/my-ports # poudriere bulk -z python36 -f /usr/local/etc/poudriere.d/my-ports It is, quite feasible to have simultaneous parallel installs of python-2.7 and python-3.6 -- the DEFAULT_VERSIONS make.conf setting will affect which version you get by typing plain 'python' by controlling how various symbolic links are created. Note that the version of any flavoured dependencies will be baked into unflavoured packages, and it's the last built that will appear in your repository. However, your example of trying to treat the mail/mailman port in this way is unfortunately doomed to failure, as mailman is specifically restricted to python-2.7 only. Cheers, Matthew signature.asc Description: OpenPGP digital signature
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ sysutils/busybox| 1.26.2 | 1.29.3 +-+ sysutils/freefilesync | 9.8 | 10.4 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt 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"
FreeBSD Port: databases/couchdb upgrade to 2.2
Hi, are there any plans to create port for CouchDB 2.2? According to latest vulnerability in 1.7.2 and statement on upstream website http://docs.couchdb.org/en/stable/cve/2018-11769.html there are no plans to fix it in 1.7, because this version is no longer supported. I am not able to create / maintain CouchDB 2.2 port by myself but I really would like to have not vulnerable version on our server. Kind regards Miroslav Lachman ___ 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: RUN_DEPENDS and portmaster
Am 10.09.18 um 06:54 schrieb Matthias Fechner:
> Dear all,
>
> I have a questions reagarding the RUN_DEPENDS and at which step
> dependencies should be installed.
> I'm the maintainer of gitlab-ce port and I added a feature that checks
> in the install target:
> do-install:
> (cd ${WRKSRC} && ${RM} Gemfile.lock && bundle install --local)
> ${FIND} ${WRKSRC} -name '*.orig' -delete
> ...
>
> that all gems available in the system do match the version required by
> the Gemfile.
> Poudriere works fine with this, but portmaster fails.
> Regarding the documentation RUN_DEPENDS packages should be installed
> before the install is happening.
Hi Matthias,
this is the description of the sequence of actions performed by the
ports framework alone.
INSTALLS_DEPENDS covers the case of dependencies that are required
to be available when a port is being installed.
Portmaster installs RUN_DEPENDS only after the port that depends on
them, since it is assumed, that they are actually only required to
execute it after it has been completely installed.
The reason is, that portmaster is typically used to upgrade multiple
ports in such a way, that all BUILD_DEPENDS are up to date (not only
available) when some some dependent port is compiled.
In case that some upgraded port actually is a build dependency of
some other port, it will need to have its run dependencies installed
and upgraded, and portmaster will assure this is the case.
The sequence of upgrade actions was chosen to follow this scheme to
prevent dependency loops (which typically will consist of a mix of
build and run dependencies).
> Is this install related to the do-install target or the installation
> of the package itself?
I have re-implemented portmaster and have been using my version to
maintain my ports since May. Due to several bad design decisions (or
rather the lack of thorough design) of the FLAVOR feature, it took me
quite some effort and time to get performance of that version to an
acceptable level.
Currently I'm building and installing ports in the same order as the
current official portmaster version, but that could easily be changed.
I have considered following the same concept as synth does (i.e. build
ports in a clean environment), at least as an option. But I have not
started to implement such a feature, yet.
> Is this maybe a problem with portmaster as poudiere handles this correctly?
This is a design decision in portmaster that has existed for at least
a decade.
Use INSTALL_DEPENDS if you depend on a port being available and upgraded
before your port's do-install is invoked.
Changing the current portmaster version in ports is no option, since it
does not offer to recursively upgrade or install any other port while
working on some port and it cannot easily be made to support such a
sequence of actions.
Regards, STefan
___
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: RUN_DEPENDS and portmaster
On Mon, Sep 10, 2018 at 06:54:19AM +0200, Matthias Fechner wrote:
> Dear all,
>
> I have a questions reagarding the RUN_DEPENDS and at which step
> dependencies should be installed.
Reading Mk/bsd.port.mk at line 5274, run-depends are installed before
do-install runs.
> I'm the maintainer of gitlab-ce port and I added a feature that checks
> in the install target:
> do-install:
> (cd ${WRKSRC} && ${RM} Gemfile.lock && bundle install --local)
> ${FIND} ${WRKSRC} -name '*.orig' -delete
> ...
>
> that all gems available in the system do match the version required by
> the Gemfile.
> Poudriere works fine with this, but portmaster fails.
> Regarding the documentation RUN_DEPENDS packages should be installed
> before the install is happening.
> Is this install related to the do-install target or the installation of
> the package itself?
>
> Is this maybe a problem with portmaster as poudiere handles this correctly?
It's probably a problem with portmaster not doing clean builds.
--
Mathieu Arnold
signature.asc
Description: PGP signature
Re: FreeBSD Port: databases/couchdb upgrade to 2.2
Kurt Jaeger wrote on 2018/09/10 12:06: Hi! are there any plans to create port for CouchDB 2.2? Yes, here's the PR about it: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218844 Dave's a bit busy right now, so progress is slow. Great news. Thank you! Miroslav Lachman ___ 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: databases/couchdb upgrade to 2.2
Hi! > are there any plans to create port for CouchDB 2.2? Yes, here's the PR about it: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218844 Dave's a bit busy right now, so progress is slow. -- p...@freebsd.org +49 171 3101372 2 years to go ! ___ 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: Wrong log and archive permissions in Nagios
On 9/6/18 7:30 PM, Andrea Venturoli wrote: I'm now compiling 4.4.2 and will see if something changes. Unfortunately, it didn't. bye av. ___ 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"
weechat failing to load ruby.so after recent updates
Hi all, I recently restarted weechat for the first time in awhile (1-2 months), and now it can't load ruby.so because of: Error: unable to load plugin "/usr/local/lib/weechat/plugins/ruby.so" /usr/local/lib/weechat/plugins/ruby.so: Undefined symbol "ruby_version" `strings /usr/local/lib/weechat/plugins/ruby.so` reveals that ruby_version is in the file. I first saw this with the binary pkg installation, but I've rebuilt weechat from source from the ports tree and that didn't resolve the problem. I also updated to 11.2-RELEASE after I first saw this, which also had no effect, incidentally. ktrace revealed nothing useful, and I'm not sure what I should look for with dtrace. Any thoughts? I suspect this is more likely to be a FreeBSD-specific problem than a general weechat problem, as I see no reports (other than a random pastebin paste) of this anywhere online. Any help would be appreciated! Todd ___ 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: weechat failing to load ruby.so after recent updates
On 11/09/2018 1:36 am, Todd Wasson wrote: > Hi all, I recently restarted weechat for the first time in awhile (1-2 > months), and now it can't load ruby.so because of: > > Error: unable to load plugin "/usr/local/lib/weechat/plugins/ruby.so" > /usr/local/lib/weechat/plugins/ruby.so: Undefined symbol "ruby_version" > > `strings /usr/local/lib/weechat/plugins/ruby.so` reveals that ruby_version > is in the file. I first saw this with the binary pkg installation, but > I've rebuilt weechat from source from the ports tree and that didn't > resolve the problem. I also updated to 11.2-RELEASE after I first saw > this, which also had no effect, incidentally. ktrace revealed nothing > useful, and I'm not sure what I should look for with dtrace. > > Any thoughts? I suspect this is more likely to be a FreeBSD-specific > problem than a general weechat problem, as I see no reports (other than a > random pastebin paste) of this anywhere online. Any help would be > appreciated! > > > Todd Hi Todd, I can confirm the issue, also present on CURRENT using ports (so not specific to packages or freebsd versions), after updating to weechat 2.2 (and ruby 2.4.4). Rebuilding both does not resolve the issue. Best course of action is to report the issue so that at least the issue is logged, and the maintainer (cc'd) can investigate: "irc/weechat: Fails to load ruby plugin after update to 2.2 (Undefined symbol "ruby_version)" Feel free to CC me on it. ./koobs ___ 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"
