Re: pkg install fails in some strange way on 14.0

[Baptiste Daroussin]

On Thu, Apr 22, 2021 at 11:58:33AM +0200, Kurt Jaeger wrote:
> Hi!
> 
> > > > So even if I have newer pkg's in the repo, pkg upgrade does
> > > > not find them. Any ideas what's going on ?
> > > 
> > > pkg calls with -d option (debug) can be found at:
> > > 
> > > https://people.freebsd.org/~pi/logs/pkg-bug.txt
> 
> > Please try with: pkg -o DEBUG_LEVEL=4 
> 
> Ah, much more output (5MB!). Now available at
> 
> https://people.freebsd.org/~pi/logs/pkg-bug2.txt
> 
> I do not see obvious reasons for the problem -- any hints ?

I don't see anything obvious, (I don't see any error actually there).

Maybe try to run pkg update -f, ensure ntp is properly setup on both sides?

Best regards,
Bapt
___
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 install fails in some strange way on 14.0

[Baptiste Daroussin]

On Wed, Apr 21, 2021 at 07:48:30PM +0200, Kurt Jaeger wrote:
> Hi!
> 
> > So even if I have newer pkg's in the repo, pkg upgrade does
> > not find them. Any ideas what's going on ?
> 
> pkg calls with -d option (debug) can be found at:
> 
> https://people.freebsd.org/~pi/logs/pkg-bug.txt
> 

Please try with: pkg -o DEBUG_LEVEL=4 

Best
Bapt
___
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: Official package for `gitup` on CURRENT doesn't work

[Baptiste Daroussin]

15 avr. 2021 17:44:40 Lev Serebryakov :

>
>   I'm not sure, is it for ports@ or current@?
>
>   I've installed latest CURRENT snapshot (20210408-15dc713ceb5-24588), 
> bootstrapped `pkg` and installed `gitup`.
>
>   `gitup` can not be run due to `Undefined symbol "ucl_object_iterate"`...
>

gitup is linked to a privatelib which no ports are supposed to do... So yeah 
breakages are to be expected
___
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: @sample surprises (dns/knot-resolver)

[Baptiste Daroussin]

On Mon, Apr 12, 2021 at 11:34:11AM +0200, Adriaan de Groot wrote:
> As prep-work for CMake updates I locally "exp-run" all the ports that use 
> CMake. I use poudriere for this, with the `-t` flag to test each port.
> 
> dns/knot-resolver fails to package like that, with this error:
> 
> ===
> ===>  Building package for knot-resolver-5.3.0
> @sample with 1 single argument expect ".sample" extension
> pkg-static: Fail to apply keyword 'sample'
> *** Error code 1
> 
> 
> The same failure occurs on the build cluster. I checked the porter's handbook 
> and it describes 1- and 2-argument forms of @sample, but neither seemed 
> applicable here without digging into the port itself to rename the installed 
> configuration file. What's the right approach here?
> 
> (CC'ed maintainer and last committer; I'm going to locally stop building this 
> one in preparation of a CMake update)


This makes me happy to have implemented this prepacking tests in pkg for
keywords.

The port is clearly buggy here, the right approach is to move the
%%ETCDIR%%/kresd.conf into %%ETCDIR%%/kresd.conf.sample in the post-install
And change the plist

Best regards,
Bapt
___
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: Proposed ports git transition schedule

[Baptiste Daroussin]

On Fri, Apr 02, 2021 at 07:26:42AM -0700, Kevin Oberman wrote:
> On Fri, Apr 2, 2021 at 4:53 AM Robert Huff  wrote:
> 
> >
> > The transition has happened.
> > Where do I find the authoritative guide for non-committers?
> >
> >
> > Respectfully,
> >
> >
> > Robert Huff
> >
> > --
> > Hello ... my name is SARS-CoV-2.
> > You are not wearing a mask?
> > Prepare to die!
> >
> And where do I find the repository? I look at https://cgit.freebsd.org and
> see only doc and src. Is there a delay in the move of the repo? Or, am I
> looking in the wrong place?

Conversion of such big repos takes time + all the verification to ensure the
migration went correctly, so yes, it will take time, but will appear there.

Bapt


signature.asc
Description: PGP signature

Re: Python 2.7 removal outline

[Baptiste Daroussin]

On Thu, Mar 25, 2021 at 12:02:29PM +0100, Olivier Certner wrote:
> Hi,
> 
> Maintainer of Tauthon here, and of Pale Moon (for the few hours it lived in 
> the tree in February; but I'm still pushing updates to PR 251117).
> 
> I find this announcement very much disappointing, because the situation for 
> ports that need Python 2.7 or similar to build doesn't seem to have changed 
> at 
> all. In short, we are just told (again) that they should disappear.
> 
> But now we are told also that there are exceptions to the general rule. And 
> even worse (or better, for the comical effect), that the Chromium exception 
> is 
> going to force its agenda on portmgr@, because nobody seems to really know 
> when that migration will complete (having quickly studied how it worked out 
> for Firefox, I'm willing to bet this will never happen before June, and 
> likely 
> will not before the end of this year either). "I love it when a plan comes 
> together."
> 
> I had hoped that portmgr@ would turn to me (and others in the same situation) 
> with at least some way out to allow Pale Moon to go into the ports tree. In 
> its mail, the closest thing I can find is this:
> > - you are of course free to provide your own version of Python 2.7, Tauthon
> >   and any application using those languages in your local setup, by using
> >   overlays for example.
> So, if I understand correctly, in its great magnanimity, portmgr@ allows us 
> to 
> do what we want locally. Gosh! That's news. Didn't know I had been violating 
> the law for the past 10 years by doing exactly that with my set of patches to 
> the ports tree (a long way before overlays even existed; that said, I think 
> overlays are helpful, more on that below).
> 
> And there's more in the same "tone":
> > No excuses. * 3
> You probably were not addressing this to me in particular (at least I hope). 
> But just in case, did you mean: Excuses for not respecting a non-existing 
> policy?
> 
> In December last year, I submitted Tauthon with the goals to be able to use 
> it 
> to build Pale Moon and help others that needed to run 2.7 code despite 
> phasing 
> out of PSF's interpreter. It was pushed on 2020/12/11. I then submitted an 
> upstream-approved official version of Pale Moon port, that was pushed on 
> 2021/02/15. It was removed less than 4 hours later, together with Tauthon, in 
> "rage commit" 565350 by antoine@, without any public (or private to me) 
> communication, before or after. Except for one thing: He responsed to my 
> request for explanations by saying: "When we deprecate python 2.7, we also 
> deprecate all forks of python 2.7.".
> 
> That also was news to me. Don't know how many ports would have to be removed 
> if this rule was followed for all forks of now deprecated projects. I don't 
> think there would be only a few of them. What about the fact that Tauthon has 
> lived 2 months in the tree up to the removal? What about that it was 
> contributed through a public PR, linked to other Python-related PRs by some 
> committers? What about that nobody issued a public objection to its presence 
> on said PR or on mailing lists? What about that it is still listed *today* on 
> the wiki's WantedPorts page? Never had a single answer on all this. Surely 
> these must have been signs that what I was doing was very wrong indeed, and 
> against a very clear and strong policy, which I should have understood by 
> myself. Idiot me.
> 
> I'm not going to repeat here the long mail I wrote in response to FUD being 
> spread about Pale Moon (and even Tauthon and Python 2.7 to some extent) by 
> rene@ and danfe@, and its excruciating details on how deluded they were 
> (still are?). These mails were for committers only, and exchanged on 
> 2021/02/2{1,2}.
> 
> I'll just quickly point out the new FUD and inaccuracies, add some facts and 
> opinions to the picture, and wrap up with two possible ways out.
> 
> > Tauthon is not guaranteed to be compatible with any official
> >   Python version so keeping it would just unnecessarily complicate things.
> 
> mandree@ preceeded me, so not going to add much except that Tauthon in 
> practice lives up to its promise (there are incompatibilities due to the 
> introduction of some Python 3 features, but they are very minimal and hard to 
> trigger; unfortunately for me, Pale Moon's weird build system, inherited from 
> Mozilla, triggered some).
> 
> As to why it would complicate things, we are left with no clue, especially 
> given that Tauthon is not hooked at all into python.mk and that no port 
> currently depends on it (Pale Moon having been removed).
> 
> > - On a related note, most software using Python 2.7 was already removed
> >   from the Ports Tree last year, a lot of it being unmaintained or
> >   more or less abandoned upstream.
> 
> 1. Most is not all, unfortunately. What happens for the rest? Is "Well, let's 
> pretend it doesn't exist, and shut the contributors up." your response? 
> Seriously?
> 2. Security 

Re: Python 2.7 removal outline

[Baptiste Daroussin]

On Wed, Mar 24, 2021 at 09:45:09PM +, Bob Eager wrote:
> On Wed, 24 Mar 2021 13:03:47 +
> Rene Ladan  wrote:
> 
> > - - mail/mailman is being replaced by clusteradm@  with mlmmj. You
> > can use `pkg lock` to stick with it after removal, if there is no
> > other way.
> 
> Is anyone working on a mailman 3 port?

it is already in: mail/mailman3

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Git repository timeline?

[Baptiste Daroussin]

On Wed, Mar 17, 2021 at 08:29:27AM -0700, bob prohaska wrote:
> Is there any indication when ports will be available via git?
> 
> Thanks for reading,
> 
> bob prohaska
> 
There will be an announcement soon, but you can expect it to happen in a couple
of weeks.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: broken vuln.xml?

[Baptiste Daroussin]

On Tue, Feb 02, 2021 at 08:16:30AM -0500, Robert Huff wrote:
> 
> Baptiste Daroussin  writes:
> 
> >   On Tue, Feb 02, 2021 at 01:01:14PM +, Bob Eager wrote:
> >   
> >   > >   This appears to have broken (Sunday?) on one of my systems.
> >   > >   What is the correct way to download/regenerate this file?
> >   >=20
> >   > portaudit is being replaced by pkg audit.
> >   >=20
> >   > This may already have happened - I am not sure.
> >   
> >   portaudit has been replaced by pkg audit 7 years ago! (removed
> >   from the ports tree in 2014.
> 
>   So here's my problem:
>   Starting yesterday all attempts to rebuild ports - any port - end
> like this:
> 
> portmaster: java-zoneinfo-2020.d
> ===>>> Currently installed version: java-zoneinfo-2020.d
> ===>>> Port directory: /usr/ports/java/java-zoneinfo
> 
> ===>>> Gathering distinfo list for installed ports
> 
> ===>>> Launching 'make checksum' for java/java-zoneinfo in background
> ===>>> Gathering dependency list for java/java-zoneinfo from ports
> ===>>> Initial dependency check complete for java/java-zoneinfo
> 
> portmaster: java-zoneinfo-2020.d
> ===>>> Starting build for java/java-zoneinfo <<<===
> 
> ===>>> All dependencies are up to date
> 
> ===>  Cleaning for java-zoneinfo-2021.a
> pkg-static: Invalid end of XML
> pkg-static: cannot process vulnxml
> ===>  java-zoneinfo-2021.a has known vulnerabilities:
> 
> => Please update your ports tree and try again.
> => Note: Vulnerable ports are marked as such even if there is no update 
> available.
> => If you wish to ignore this vulnerability rebuild with 'make 
> DISABLE_VULNERABILITIES=yes'
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/java/java-zoneinfo
> 
>   Am I even asking about the right file?
>   What broke, why (if possible), and how do I fix it?
> 
> 
>   Respectfully,
> 
> 
>   Robert Huff
> 
Does pkg audit -F fixes your problem ?

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: broken vuln.xml?

[Baptiste Daroussin]

On Tue, Feb 02, 2021 at 01:01:14PM +, Bob Eager wrote:
> On Tue, 2 Feb 2021 07:56:16 -0500
> Robert Huff  wrote:
> 
> > Hello:
> > This appears to have broken (Sunday?) on one of my systems.
> > What is the correct way to download/regenerate this file?
> 
> portaudit is being replaced by pkg audit.
> 
> This may already have happened - I am not sure.

portaudit has been replaced by pkg audit 7 years ago! (removed from the ports
tree in 2014.

The machine building the portaudit db has been decomissioned:

https://lists.freebsd.org/pipermail/freebsd-ports-announce/2021-January/000131.html

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: poudriere merging multiple ports trees

[Baptiste Daroussin]

On Mon, Jan 25, 2021 at 04:25:09PM +0100, Miroslav Lachman wrote:
> On 25/01/2021 15:10, Baptiste Daroussin wrote:
> > On Sun, Jan 24, 2021 at 10:23:45PM +0100, Guido Falsi via freebsd-ports 
> > wrote:
> > > On 24/01/21 20:35, Russell L. Carter wrote:
> > > > Greetings,
> > > > I am completely ignorant here and am looking for up to
> > > > date advice on how to get poudriere to build and make
> > > > available package sets from multiple ports trees.  I
> > > > see there is a port "portshaker" that seems to do much
> > > > of what I want.
> 
> [...]
> 
> > > BTW I noticed poudriere performs shallow clones for git repos, so it 
> > > should
> > > not use up a lot of disk space.
> > 
> > Why not using directly overlays, it will simplify everything ;)
> 
> I don't know if you read me reply or not - I am using poudriere with ports
> overlay but have a problem with it. Poudriere options does not take overlay
> in to account so ports options cannot be configured for overlayed ports
> which do not exist in the base three.
> Is there a way to fix it / should I file a PR for it?
> 
> Kind regards
> Miroslav Lachman

Yes I read it and for sure poudriere option not supporting overlays is a
limitation, and yes a PR would help to not forget about implementing it.

That said most people aren't using poudriere option and prefer to define option
directly via make.conf for them overlay is fully suited, and avoid the risk or
dangerous merging of trees may it be via portshaker, or git mechanism.

there are room of improvements for overlays but it should work in most cases

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: poudriere merging multiple ports trees

[Baptiste Daroussin]

On Sun, Jan 24, 2021 at 10:23:45PM +0100, Guido Falsi via freebsd-ports wrote:
> On 24/01/21 20:35, Russell L. Carter wrote:
> > Greetings,
> > I am completely ignorant here and am looking for up to
> > date advice on how to get poudriere to build and make
> > available package sets from multiple ports trees.  I
> > see there is a port "portshaker" that seems to do much
> > of what I want.
> > 
> > I can think of possible alternatives:
> > 
> > I can reasonably expect to have my local ports not
> > conflict with already existing ports (could be a common
> > prefix in the name).  Since I'm using git, I should be
> > able to maintain my own branch which layers my own ports
> > over upstream and git pull, merge from upstream.
> > 
> > or
> > 
> > I can duplicate the structure and metadata of the existing
> > ports tree and add my own ports and leaves in the tree.
> > Still have to maintain unique names.  This seems to be
> > what portshaker does?  I am guessing that gets me a
> > single package repo.
> > 
> > or
> > 
> > Have two ports trees and generate two package repos, but
> > then dependencies would be redundantly built, I guess.
> > 
> > What do the professionals do here?
> 
> I've been using portshaker for this (ports-mgmt/portshaker) for this for  a
> long time.
> 
> But when the ports tree will be migrated to git in the near future I plan to
> stop using portshakern and use a git repository forked from the main one
> (and syncronized to it) with feature branches for any change and some
> "build" branches which I checkout in poudriere and to which I merge the
> feature branches as needed.
> 
> Git allows for such a workflow and that should also be quite less error
> prone.
> 
> BTW I noticed poudriere performs shallow clones for git repos, so it should
> not use up a lot of disk space.

Why not using directly overlays, it will simplify everything ;)

Best regards,
Bapt


signature.asc
Description: PGP signature

[FreeBSD-Ports-Announce] portaudit db EOLed

[Baptiste Daroussin]

Hello everyone,

In 2014, portaudit has been decommision and removed from the ports tree in favor
of pkg audit.

portaudit was using a csv database (namely auditfile.tbz) which was generated
from from the vuln.xml database. up to now this db was still built.

Since today the file is not updated anymore, and the infrastructure in place to
build and distribute it will be decommission soon.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Fwd: [package - main-i386-default][sysutils/env4801] Failed for env4801-0.3_1 in build

[Baptiste Daroussin]

On Tue, Jan 12, 2021 at 03:20:36PM +0100, Patrick M. Hausen wrote:
> Dear ports gurus,
> 
> what am I doing wrong that makes me still receive this message every couple 
> of days?
> 
> > Von: pkg-fall...@freebsd.org
> > Betreff: [package - main-i386-default][sysutils/env4801] Failed for 
> > env4801-0.3_1 in build
> > Datum: 12. Januar 2021 um 15:05:07 MEZ
> > An: p...@hausen.com
> > Kopie: pkg-fall...@freebsd.org
> > 
> > ===
> > ===>  Building for env4801-0.3_1
> > make[1]: "/usr/share/mk/bsd.opts.mk" line 110: "NO_MAN is defined, but 
> > deprecated. Please use MK_MAN=no instead."
> 
> The issue should be fixed since mid November:
> 
> https://svnweb.freebsd.org/ports/head/sysutils/env4801/Makefile?r1=418715=554829

What the error is saying is that the Makefile defines:
NO_MAN=sorry, which was something valid long ago, but not anymore (and its been
a while it is not valid anymore) in FreeBSD framework makefile.

Where it is misleading is that the framework (source one not ports) tells you to
use MK_MAN instead because it thinks you are trying to define a build option
which you are not

The right way to fix it is:
MAN=
instead of
NO_MAN= sorry

in the distfile makefile

Note that I have fixed it in r561337 (with some cleanup)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: What are the benefits of NO_ARCH?

[Baptiste Daroussin]

On Tue, Nov 03, 2020 at 01:41:54PM +0100, Mateusz Piotrowski wrote:
> 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=54671
> 
I think you have been a little too fast.

The point of no arch is not only that. pkg checks if a package is a valid ABI
for the system it will install to. This is done via globing on the ABI variable.

When a package is set to NO_ARCH: you end up this is line: "FreeBSD:13:*"
meaning the package can actually be installed on any freebsd 13 system. so it is
already useful as of today. what Stefan describe is other things we might
benefit one day thanks to have the NO_ARCH packages already in the futur.

best regards,
Bapt


signature.asc
Description: PGP signature

Re: What are the benefits of NO_ARCH?

[Baptiste Daroussin]

On Mon, Nov 02, 2020 at 03:48:34PM +0100, Stefan Esser wrote:
> Am 02.11.20 um 15:33 schrieb Mateusz Piotrowski:
> > 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.
> 
> 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.
> 
> Regards, STefan


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.

Best regards,
bapt


signature.asc
Description: PGP signature

Re: gvfs-1.46.1

[Baptiste Daroussin]

On Mon, Oct 12, 2020 at 06:53:36PM -0400, LuMiWa via freebsd-ports wrote:
> Hi
> 
> On FreeBSD 12.1-RELEASE I have a problem to install (it built without
> problem) gvfs 1.46.1:
> 
>  make install
> ===>  Installing for gvfs-1.46.1
> ===>  Checking if gvfs is already installed
> ===>   Registering installation for gvfs-1.46.1
> pkg-static: Unable to access file
>  
> /usr/ports/devel/gvfs/work/stage/usr/local/share/GConf/gsettings/gvfs-dns-sd.convert:No
>  such file or directory pkg-static: Unable to access file
>  
> /usr/ports/devel/gvfs/work/stage/usr/local/share/GConf/gsettings/gvfs-smb.convert:No
>  such file or directory *** Error code 74
> 
> Stop.
> make[1]: stopped in /usr/ports/devel/gvfs
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/devel/gvfs
> 
> Thank you.

There was an issue with non default option, I bet you do build without SAMBA and
without AVAHI ?

In general when reporting an issue it is a good practice to show the non default
option you have set if you have set any.

Anyway fixed

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Seeing packaging problems since about 1-2 days (Requesting argument %2 while only 1 arguments are available)

[Baptiste Daroussin]

On Fri, Oct 02, 2020 at 10:28:52AM +0200, Matthias Fechner wrote:
> Dear all,
> 
> I see recently new package errors like (this also affects ports I maintain):
> 
> ===>  Building package for avahi-app-0.7_3
> pkg-static: Requesting argument %2 while only 1 arguments are available
> pkg-static: Requesting argument %2 while only 1 arguments are available
> 
> Anyone an idea what caused this and how to fix it?
> 
> Gruß
> Matthias
> 
The issue was in @sample, the version causing the issue you are seeing was
committed 6 hours ago and the fix about it 2 hours ago.

Updating your ports tree should fix it.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: State changes via pkg's scripts

[Baptiste Daroussin]

On Wed, Jul 08, 2020 at 04:32:34PM +1000, Dewayne Geraghty wrote:
> Is there a more convenient method to examine a package's scripts than
> unpacking the manifest file and
> # cat +MANIFEST | jq -rM '.scripts'
> ?  As I'd like to know what changes will, or have been applied.

pkg info --raw-format json -R yourpkg | jq -rM '.scripts'

So far noone added a better interface yet, it should not be difficult to add

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: sysutils/screen-ncurses port

[Baptiste Daroussin]

On Mon, May 04, 2020 at 06:35:03AM -0700, Cy Schubert wrote:
> In message <20200504072624.wlyd73pehq25t...@ivaldir.net>, Baptiste 
> Daroussin wr
> ites:
> > 
> >
> > --ma2vde2ykv3k7k6b
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote:
> > > In message <20200430130449.cwsf3x42o6w67...@ivaldir.net>, Baptiste=20
> > > Daroussin wr
> > > ites:
> > > >=20
> > > >
> > > > --mvhxgm4zl62unzlf
> > > > Content-Type: text/plain; charset=3Dus-ascii
> > > > Content-Disposition: inline
> > > > Content-Transfer-Encoding: quoted-printable
> > > >
> > > > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > > > > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste=3D=
> > 20
> > > > > Daroussin wr
> > > > > ites:
> > > > > >=3D20
> > > > > >
> > > > > > --vwrr5drfobpkyvop
> > > > > > Content-Type: text/plain; charset=3D3Dus-ascii
> > > > > > Content-Disposition: inline
> > > > > > Content-Transfer-Encoding: quoted-printable
> > > > > >
> > > > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > > > > Would people be open to the idea of a sysutils/screen-ncurses por=
> > t th=3D
> > > > at=3D3D
> > > > > > =3D3D20
> > > > > > > depends on devel/ncurses instead of ncureses in base? The reason =
> > for =3D
> > > > this=3D3D
> > > > > > =3D3D20
> > > > > > > is there are screen.* terminfo entries in devel/ncurses that don'=
> > t ex=3D
> > > > ist =3D3D
> > > > > > in=3D3D20
> > > > > > > termcap(5). People who want that extra functionality would be adv=
> > ised=3D
> > > >  to=3D3D
> > > > > > =3D3D20
> > > > > > > install the alternative pkg or build the sysutils/screen port wit=
> > h th=3D
> > > > e=3D3D20
> > > > > > > appropriate option.
> > > > > > >=3D3D20
> > > > > > > Or, simply change the default from whatever ncurses is available =
> > to a=3D
> > > > lway=3D3D
> > > > > > s=3D3D20
> > > > > > > install devel/ncurses. People could always select one of the othe=
> > r op=3D
> > > > tion=3D3D
> > > > > > s.=3D3D20
> > > > > > > Personally, I'm not enamoured with this approach.
> > > > > >
> > > > > > I think it is a terrible idea, and we should fix the initial proble=
> > m in=3D
> > > > stea=3D3D
> > > > > > d of
> > > > > > workarounding it.
> > > > > >
> > > > > > 1/ why those are not in our termcap(5) ? they should be added if th=
> > ey a=3D
> > > > re
> > > > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> > > > >=3D20
> > > > > I came to this conclusion last night after sending this email thread =
> > oud=3D
> > > > =3D20
> > > > > and will test it some time today.
> > > > >=3D20
> > > > > >
> > > > > > 2/ we should allow our base ncurses to get informations from newer =
> > term=3D
> > > > cap(=3D3D
> > > > > > 5) if
> > > > > > needed.
> > > > > > So far the default TERMCAP is
> > > > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,=
> > =2Edb}
> > > > > >
> > > > > > First the user can be advise to point configure the $home/.termcap =
> > this=3D
> > > >  is =3D3D
> > > > > > for
> > > > > > quick now.
> > > >
> > > > that is in your scope via a pkg-message :D
> > > >
> > > > > >
> > > > > > Second for later futur proof mechanism we could modify our termcap =
> > read=3D
> > > > er (=3D3D
> > > > > > we
> > > > > > use our own, not the one in provided by ncurses). to be able to fet=
> > ch t=3D
> > > > ermc=3D3D
> > > > > > ap
> > > &

Re: sysutils/screen-ncurses port

[Baptiste Daroussin]

On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote:
> In message <20200430130449.cwsf3x42o6w67...@ivaldir.net>, Baptiste 
> Daroussin wr
> ites:
> > 
> >
> > --mvhxgm4zl62unzlf
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste=20
> > > Daroussin wr
> > > ites:
> > > >=20
> > > >
> > > > --vwrr5drfobpkyvop
> > > > Content-Type: text/plain; charset=3Dus-ascii
> > > > Content-Disposition: inline
> > > > Content-Transfer-Encoding: quoted-printable
> > > >
> > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > > Would people be open to the idea of a sysutils/screen-ncurses port th=
> > at=3D
> > > > =3D20
> > > > > depends on devel/ncurses instead of ncureses in base? The reason for =
> > this=3D
> > > > =3D20
> > > > > is there are screen.* terminfo entries in devel/ncurses that don't ex=
> > ist =3D
> > > > in=3D20
> > > > > termcap(5). People who want that extra functionality would be advised=
> >  to=3D
> > > > =3D20
> > > > > install the alternative pkg or build the sysutils/screen port with th=
> > e=3D20
> > > > > appropriate option.
> > > > >=3D20
> > > > > Or, simply change the default from whatever ncurses is available to a=
> > lway=3D
> > > > s=3D20
> > > > > install devel/ncurses. People could always select one of the other op=
> > tion=3D
> > > > s.=3D20
> > > > > Personally, I'm not enamoured with this approach.
> > > >
> > > > I think it is a terrible idea, and we should fix the initial problem in=
> > stea=3D
> > > > d of
> > > > workarounding it.
> > > >
> > > > 1/ why those are not in our termcap(5) ? they should be added if they a=
> > re
> > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> > >=20
> > > I came to this conclusion last night after sending this email thread oud=
> > =20
> > > and will test it some time today.
> > >=20
> > > >
> > > > 2/ we should allow our base ncurses to get informations from newer term=
> > cap(=3D
> > > > 5) if
> > > > needed.
> > > > So far the default TERMCAP is
> > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
> > > >
> > > > First the user can be advise to point configure the $home/.termcap this=
> >  is =3D
> > > > for
> > > > quick now.
> >
> > that is in your scope via a pkg-message :D
> >
> > > >
> > > > Second for later futur proof mechanism we could modify our termcap read=
> > er (=3D
> > > > we
> > > > use our own, not the one in provided by ncurses). to be able to fetch t=
> > ermc=3D
> > > > ap
> > > > capabilities from /usr/local/share/misc/termcap/*.conf for example
> > > >
> > > > This way ports with random termcap info to add would be able to do it w=
> > itho=3D
> > > > ut
> > > > the requirement to wait for a commit in base and a MFC.
> > >=20
> > > This is probably outside of my scope at the moment but, yes, agreed.
> > >=20
> > I will then.
> > I added that to my TODO
> 
> There's already a utility in devel/ncurses called infotocap (and its 
> corresponding captoinfo) that already does this. Both are links to tic. Our 
> ncurses import includes tic. Looks like all that's needed is add it to 
> buildworld.
> 
> I can look at it later tonight. Seems like a quick win.
> 
That is not the point, tic won't work here except if create your own version or
use infotocap. Tic is for terminfo databases while we are still using the 
termcap for historical reason

Having both ncurses from ports and ncurses from base installed at the same time
can open a special can of worm so imho that is not really something we want to
look forward.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: sysutils/screen-ncurses port

[Baptiste Daroussin]

On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste 
> Daroussin wr
> ites:
> > 
> >
> > --vwrr5drfobpkyvop
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > Would people be open to the idea of a sysutils/screen-ncurses port that=
> > =20
> > > depends on devel/ncurses instead of ncureses in base? The reason for this=
> > =20
> > > is there are screen.* terminfo entries in devel/ncurses that don't exist =
> > in=20
> > > termcap(5). People who want that extra functionality would be advised to=
> > =20
> > > install the alternative pkg or build the sysutils/screen port with the=20
> > > appropriate option.
> > >=20
> > > Or, simply change the default from whatever ncurses is available to alway=
> > s=20
> > > install devel/ncurses. People could always select one of the other option=
> > s.=20
> > > Personally, I'm not enamoured with this approach.
> >
> > I think it is a terrible idea, and we should fix the initial problem instea=
> > d of
> > workarounding it.
> >
> > 1/ why those are not in our termcap(5) ? they should be added if they are
> > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> 
> I came to this conclusion last night after sending this email thread oud 
> and will test it some time today.
> 
> >
> > 2/ we should allow our base ncurses to get informations from newer termcap(=
> > 5) if
> > needed.
> > So far the default TERMCAP is
> > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
> >
> > First the user can be advise to point configure the $home/.termcap this is =
> > for
> > quick now.

that is in your scope via a pkg-message :D

> >
> > Second for later futur proof mechanism we could modify our termcap reader (=
> > we
> > use our own, not the one in provided by ncurses). to be able to fetch termc=
> > ap
> > capabilities from /usr/local/share/misc/termcap/*.conf for example
> >
> > This way ports with random termcap info to add would be able to do it witho=
> > ut
> > the requirement to wait for a commit in base and a MFC.
> 
> This is probably outside of my scope at the moment but, yes, agreed.
> 
I will then.
I added that to my TODO

Bestr regards,
Bapt


signature.asc
Description: PGP signature

Re: sysutils/screen-ncurses port

[Baptiste Daroussin]

On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> Would people be open to the idea of a sysutils/screen-ncurses port that 
> depends on devel/ncurses instead of ncureses in base? The reason for this 
> is there are screen.* terminfo entries in devel/ncurses that don't exist in 
> termcap(5). People who want that extra functionality would be advised to 
> install the alternative pkg or build the sysutils/screen port with the 
> appropriate option.
> 
> Or, simply change the default from whatever ncurses is available to always 
> install devel/ncurses. People could always select one of the other options. 
> Personally, I'm not enamoured with this approach.

I think it is a terrible idea, and we should fix the initial problem instead of
workarounding it.

1/ why those are not in our termcap(5) ? they should be added if they are
missing. and MFC asap (prior 11.4 and 12.2 would be nice)

2/ we should allow our base ncurses to get informations from newer termcap(5) if
needed.
So far the default TERMCAP is
${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}

First the user can be advise to point configure the $home/.termcap this is for
quick now.

Second for later futur proof mechanism we could modify our termcap reader (we
use our own, not the one in provided by ncurses). to be able to fetch termcap
capabilities from /usr/local/share/misc/termcap/*.conf for example

This way ports with random termcap info to add would be able to do it without
the requirement to wait for a commit in base and a MFC.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Using pkg in documentation

[Baptiste Daroussin]

On Mon, Apr 27, 2020 at 08:23:09AM +0200, Miroslav Lachman wrote:
> On 2020-04-26 21:37, Muhammad Moinur Rahman wrote:
> > What is the way of mentioning about installing a py-package in 
> > documentation? Let’s say now the default version of python is 3.7 so in 
> > most of the cases we can write in our documentation that do the following:
> > # pkg install py37-babel
> 
> You can use following form too:
> pkg install devel/py-babel
> 
Which would install all flavor of py*-babel imho thta is wrong

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: current: cd /lib ; ln -s libncurses.so.9 libncurses.so.8 xterm & ffox

[Baptiste Daroussin]

On Wed, Apr 01, 2020 at 08:01:35PM +0200, Dimitry Andric wrote:
> On 2020-04-01 02:22, Julian H. Stacey wrote:
> > Hi ports@
> > A libcurses version problem:
> > 
> > Running 13.0-CURRENT with
> > /usr/src
> >   cat .svn_revision 359319
> >   cat .ctm_status src-cur 14430
> > /usr/ports
> >   cat .svn_revision 529842
> >   cat .ctm_status ports-cur 13423
> > 
> > After
> >   pkg upgrade
> >   pkg autoremove
> > xterm & firefox failed with
> >   ld-elf.so.1: Shared object "libncurses.so.8" not found, required by 
> > "xterm"
> ...
> > Next to look at /usr/src/
> > ObsoleteFiles.inc
> > # 20200220: Upgrade of ncurses, shlib bumped to version 9
> > OLD_LIBS+=lib/libncurses.so.8
> 
> Yeah, this ncurses bump was handled pretty badly, as it breaks almost all
> installed ports (and a bunch of base programs too, if you are unlucky).
> Isn't there any compat package for it yet?
> 
> -Dimitry
??

When the bump occured a month ago, an UPDATING entry was added as usual to warn
everyone, a compat12x package has been created immediatly and all the packages
have been rebuilt. What else could have been done? Can you explain me what I
have badly done here?

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: reccomendations of conference / party audio video software ?

[Baptiste Daroussin]

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.

There is no port yet of the server part on freebsd but should not be hard to do
as it is fully opensource.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Unable to run "pkg update -f" on 13-CURRENT

[Baptiste Daroussin]

On Mon, Mar 02, 2020 at 04:50:10PM +1100, Kubilay Kocak wrote:
> On 2/03/2020 2:47 pm, Neel Chauhan wrote:
> > Hi freebsd-ports@,
> > 
> > I am running FreeBSD 13-CURRENT and I am getting this error on a "pkg
> > update":
> > 
> > pkg: wrong architecture: FreeBSD:13.0:amd64 instead of FreeBSD:13:amd64
> > pkg: repository FreeBSD contains packages with wrong ABI:
> > FreeBSD:13.0:amd64
> > 
> > I am running FreeBSD 13-CURRENT r358510.
> > 
> > Why is this happening?
> > 
> > I also filed a bug on Bugzilla:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244549
> > 
> > -Neel
> > 
> > ===
> > 
> > https://www.neelc.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"
> 
> There's a known issue with the official FreeBSD package builders (which use
> ports-mgmt/pkg-devel) causing mismatched ABI error messages for package
> users after a recent pkg-devel update.
> 
> Pull request addressing the issue has been submitted by Kyle (CC'd):
> 
> https://github.com/freebsd/pkg/pull/1817
> 
> The change needs to be deployed to the build cluster to resolve the issue

No the fact that antoine marked the port as FORBIDDEN was enough. There is no
need to deploy anything to the build cluster

Bapt


signature.asc
Description: PGP signature

Re: svn commit: r358166 - head

[Baptiste Daroussin]

On Fri, Feb 21, 2020 at 11:41:15AM +, Lorenzo Salvadore via freebsd-ports 
wrote:
> > > Are there any way to know which of installed ports are linked to base
> > > ncurses?
> > > Best Regards.
> >
> > All the one with USES=ncurses in ports, otherwise I am sorry but no we have 
> > no
> > way to track that down.
> 
> What about "pkg query -a '%n: %B' | grep ncurses"? Maybe it can not 
> distinguish
> between base ncurses and ports ncurses, but I think it helps.
> 
Nope

Base libraries are not tracked as required libraries for now in pkg for the
reason that we don't have yet a list of "provided" libraries from base, meaning
all those requirements will always be seen as not fullfilled.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: svn commit: r358166 - head

[Baptiste Daroussin]

On Fri, Feb 21, 2020 at 05:22:15PM +0900, Yasuhiro KIMURA wrote:
> (Switch to freebsd-ports ML)
> 
> From: Baptiste Daroussin 
> Subject: svn commit: r358166 - head
> Date: Thu, 20 Feb 2020 09:33:14 + (UTC)
> 
> > Author: bapt
> > Date: Thu Feb 20 09:33:14 2020
> > New Revision: 358166
> > URL: https://svnweb.freebsd.org/changeset/base/358166
> > 
> > Log:
> >   Update the UPDATING information now that ncurses shlib has been bumped
> > 
> > Modified:
> >   head/UPDATING
> > 
> > Modified: head/UPDATING
> > ==
> > --- head/UPDATING   Thu Feb 20 09:17:45 2020(r358165)
> > +++ head/UPDATING   Thu Feb 20 09:33:14 2020(r358166)
> > @@ -26,10 +26,10 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:
> > disable the most expensive debugging functionality run
> > "ln -s 'abort:false,junk:false' /etc/malloc.conf".)
> >  
> > -20200218:
> > -   ncurses has been updated to a newer version (6.1-20200118). After an
> > -   update some applications using ncurses may results have some rendering
> > -   problems and would need to be rebuilt.
> > +20200220:
> > +   ncurses has been updated to a newer version (6.1-20200118). Given the 
> > ABI
> > +   has changed, users will have to rebuild all the ports that are linked to
> > +   ncurses.
> >  
> >  20200217:
> > The size of struct vnet and the magic cookie have changed.
> 
> Are there any way to know which of installed ports are linked to base
> ncurses?
> 
> Best Regards.
> 
All the one with USES=ncurses in ports, otherwise I am sorry but no we have no
way to track that down.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Starting with poudriere

[Baptiste Daroussin]

On Mon, Feb 17, 2020 at 07:55:25AM -0800, George Hartzell wrote:
> Baptiste Daroussin writes:
>  > 
>  > You should really have a look at overlays which are supported in
>  > poudriere-devel, it will allow you to get rid of portshaker with your use 
> case:
>  > 
>  > https://reviews.freebsd.org/rP510950
>  > 
>  > in poudriere an overlay is just a "regular ports tree" appended via -O 
> during
>  > the bulk.
> 
> Neat, thanks for pointing that out!
> 
> How much of a "regular ports tree" does it need to be?  Can it just
> include my local ports or does it need other elements of the tree
> (e.g. it's own index files or )?
> 
It can be your actual ports tree :D

plus the SUBDIR

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Starting with poudriere

[Baptiste Daroussin]

On Sun, Feb 16, 2020 at 10:18:33AM -0800, George Hartzell wrote:
> Dan McGrath writes:
>  > [...] I am not sure about repo priorities, or how you would deal
>  > with conflicts with build options that pull in common ports. It is
>  > something I have been meaning to look into, sorry! Perhaps someone else
>  > here can give some advice?
>  >
> 
> One way to solve this is via "portshaker", which can layer a "thin"
> ports tree on top of the standard tree.
> 
> Here's a [perhaps not entirely graceful, but It Works For Me] example
> where I layer a couple of ports onto the standard tree.
> 
> https://github.com/hartzell/freebsd-ports
> 
> I use the resulting tree for poudriere builds and populate jails with
> e.g. my LMS audio system.
> 

You should really have a look at overlays which are supported in
poudriere-devel, it will allow you to get rid of portshaker with your use case:

https://reviews.freebsd.org/rP510950

in poudriere an overlay is just a "regular ports tree" appended via -O during
the bulk.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Discussion on moving manpages to ${PREFIX}/share/man

[Baptiste Daroussin]

On Mon, Jan 13, 2020 at 09:22:01AM +0100, Baptiste Daroussin wrote:
> On Sun, Jan 12, 2020 at 03:26:04PM +0900, Yasuhiro KIMURA wrote:
> > Hello,
> > 
> > Commit message of ports r484628 says as following.
> > 
> > --
> > r484628 | bapt | 2018-11-11 03:12:57 +0900 (Sun, 11 Nov 2018) | 23 lines
> > 
> > Install texinfo files (GNU info) into ${PREFIX}/share/info
> > 
> > After a discussion on the mailing list on moving manpages to
> > ${PREFIX}/share/man for consistency with base where it is
> > installed in usr/share/man, it appeared the same should happen
> > to GNU info files which were installed under share in base and
> > not in ports.
> > --
> > 
> > I checked 2018's archive of this ML but couldn't find such thread.
> > Would someone please tell me where this discussion took place?
> > 
> > Best Regards.
> > 
> 
> The discussion happened here: 
> https://lists.freebsd.org/pipermail/freebsd-arch/2017-March/018115.html
> 
> For some reason I followed up on this only 1.5 years after, and don't know 
> when
> I will do the manpage part ;)
> 
> Best regards,
> Bapt


Also note that we did change the manpath to include share/man in base in:
https://svnweb.freebsd.org/base?view=revision=315053
Followed by:
https://svnweb.freebsd.org/base?view=revision=315142

Which both have been merged to freebsd 11 and 12 so we can start thinking about
doing it properly in ports.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Discussion on moving manpages to ${PREFIX}/share/man

[Baptiste Daroussin]

On Sun, Jan 12, 2020 at 03:26:04PM +0900, Yasuhiro KIMURA wrote:
> Hello,
> 
> Commit message of ports r484628 says as following.
> 
> --
> r484628 | bapt | 2018-11-11 03:12:57 +0900 (Sun, 11 Nov 2018) | 23 lines
> 
> Install texinfo files (GNU info) into ${PREFIX}/share/info
> 
> After a discussion on the mailing list on moving manpages to
> ${PREFIX}/share/man for consistency with base where it is
> installed in usr/share/man, it appeared the same should happen
> to GNU info files which were installed under share in base and
> not in ports.
> --
> 
> I checked 2018's archive of this ML but couldn't find such thread.
> Would someone please tell me where this discussion took place?
> 
> Best Regards.
> 

The discussion happened here: 
https://lists.freebsd.org/pipermail/freebsd-arch/2017-March/018115.html

For some reason I followed up on this only 1.5 years after, and don't know when
I will do the manpage part ;)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Retiring GNU objdump 2.17.50

[Baptiste Daroussin]

On Thu, Jan 09, 2020 at 05:56:10PM +0200, Konstantin Belousov wrote:
> On Thu, Jan 09, 2020 at 10:31:55AM -0500, Ed Maste wrote:
> > We currently install and use at most three tools from GNU binutils
> > 2.17.50, depending on target architecture:
> > 
> > 1. as - assembler
> > 2. ld - linker
> > 3. objdump - diagnostic / information tool
> > 
> > I hope to retire all use of these obsolete binutils before FreeBSD 13.
> > Here I'd like to discuss objdump. It is a diagnostic tool that
> > provides information about object files, binaries and libraries. It's
> > not required as a bootstrap tool (i.e., not needed to build FreeBSD
> > world or kernel). It is required to build a limited number of ports,
> > and is used by some developers.
> > 
> > I have a tracking PR for GNU objdump's retirement open in PR 229046.
> > https://bugs.freebsd.org/229046.
> > 
> > There are two ways we can proceed with its retirement:
> > 
> > 1. Remove it without replacement. Ports that need objdump to build
> > will have to depend on the binutils package/port, and users who wish
> > to use it will have to install it.
> > 
> > Related links for this path:
> > Ports exp-run: https://bugs.freebsd.org/212319
> > Patch review: https://reviews.freebsd.org/D7338
> > 
> > 2. Install llvm-objdump in its place (perhaps via a symlink).
> > llvm-objdump is broadly compatible in both command-line argument
> > parsing and output format, but there are many small differences and
> > it's not a full drop-in replacement.
> > 
> > Related links for this path:
> > Patch review: https://reviews.freebsd.org/D18307
> > 
> > I am interested in feedback on the preferred approach. Installing
> > llvm's objdump has the advantage that for most use cases everything
> > will "just work", but may also introduce subtle failures.
> 
> IMO no. 1 is preferrable because we do not need to track differences, nor
> we need to explain them.  Having to install binutils port is not a high cost,
> and if somebody needs details about binary at the level provided by objdump,
> including disassembler, she would need binutils port anyway.

I completly agree with kib here.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Portmaster failing

[Baptiste Daroussin]

On Thu, Jan 02, 2020 at 02:50:04PM +0100, Jan Beich wrote:
> "Thomas Mueller"  writes:
> 
> >> This is why we practically beg people to use poudriere. There seems to
> >> be a pervasive misconception that poudriere is "advanced" and
> >> portmaster is simple or straightforward. That notion is completely and
> >> totally backwards. Poudriere makes managing ports as simple and
> >> trouble-free as possible, and portmaster is specifically for people
> >> who can troubleshoot and fix problems like the one you're describing
> >> on their own. These problems WILL continue to happen very regularly
> >> for portmaster, because portmaster simply cannot do the right thing on
> >> its own. It will ALWAYS require manual intervention every time
> >> anything remotely significant changes.
> >
> >> I've mentioned this to you before, lbutlr, because you post about
> >> encountering these snags quite regularly, and your (quite warranted)
> >> frustration is apparent. I really do think that your FreeBSD life will
> >> be simpler if you switch from portmaster to poudriere. If you choose
> >> to stay on portmaster, however, then you need to check the resentment
> >> about build failures. They are simply an inevitable consequence of
> >> using a very old and broken tool that should only be used by people
> >> with substantial port-handling experience.
> >
> >> You are right that there wasn't a warning, and that was a major
> >> mistake that should not have happened. security/openssl and
> >> security/openssl111 should have contained messages about this switch.
> >
> >
> >> Adam Weinberger
> >
> > I suppose what you say about portmaster applies equally to portupgrade?
> >
> > I get the impression that synth and its dependency gcc6-aux are falling 
> > into desuetude if not actually officially deprecated.
> >
> > gcc6-aux has not been updated while gcc is up tp 8.3 and 9.2.
> 
> DragonFly has lang/gcc9-aux since 
> https://github.com/DragonFlyBSD/DeltaPorts/commit/bb774aced6d7
> Synth is still used to build binary packages on DragonFly e.g.,
> https://sting.dragonflybsd.org/dports/logs/lang___gcc9-aux.log

And is phase to be replaced by dsynth in there (rewrite in C by dillon@)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Adding FLAVORS to lua-luarocks

[Baptiste Daroussin]

On Tue, Nov 05, 2019 at 09:43:48PM -0800, Russell Haley wrote:
> Hello,
> 
> I have a review for updating the Lua package manager - LuaRocks - it to the
> latest revision, 3.2.1. The new port file uses an update to lua.mk from
> Andrew Gierth for using FLAVORS to support all available versions of Lua.
> The reviews are here:  (LuaRocks) https://reviews.freebsd.org/D17814 and
> here: (Lua.mk) https://reviews.freebsd.org/D16494
> 
> In the LuaRocks port, I've added the flavors as a selection of port OPTIONS
> to build the correct version. Unfortunately, using the OPTIONS isn't ideal
> because it will save the selected option for the next time the port is run,
> but that's not the desired use case. I wanted the build to *always* prompt
> for a Lua version so it can be used for multiple side by side Lua
> installations.
> 
> Any suggestions, alternatives to OPTIONS or other constructive input would
> be appreciated.
> 
If the lua.mk ever get the support for flavors committed in, there is no need to
add any option framework or whatever to allow the user to pickup a flavor.

if someone $ants to only build for a given flavor he will have to just to run:
make FLAVOR=lua52

if building from poudriere:
poudriere bulk devel/lua-rocks@lua52

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: [HEADSUP] Re: Is IPV6 option still necessary?

[Baptiste Daroussin]

On Thu, Oct 10, 2019 at 06:02:23PM -0700, Jeremy Chadwick via freebsd-ports 
wrote:
> > Now we can get back on the ipv6 option.
> > 
> > so if we want to proceed further in removing the option to build with or 
> > without
> > ipv6 for the ports side. Please speak up in reply to this email, if you are
> > building without ipv6, why are you doing so, what are the real benefit for 
> > it.
> > How bad it will impact you if we do remove that option?
> 
> Whenever I use ports over FreeBSD-provided packages (or to use ports to
> build my own packages), I often disable IPV6 support.  The lengthy
> response below should explain why.
> 
> In short: the IPV6 option is useful and important.  Please keep it.
> 
> In length: I think anyone operating in the Real World knows quite well
> that IPv6 is still treated as a third-class citizen when it comes to
> both general connectivity/reliability* and general use cases
> code-wise**.  It's still very much in utero; or a toddler, if you will.
> 
> When you encounter IPv6 vs. IPv4 prioritisation issues, they are painful
> and annoying.  No user or administrator is going to sit for hours
> fiddling with it all to restore things to a working state when simply
> removing IPv6 relieves the problem permanently.  Time and time again I
> see companies advertising  records and webservers listening on IPv6
> yet IPv6 transit fails but their A/IPv4 endpoint works fine.  It's the
> dual-stack nature that makes a lot of this worse than it should be.  (I
> do think this subject should be re-visited once the world as a whole
> starts to seriously decommission IPv4, though.  Yes I'm serious.)
> 
> I've worked for several companies that are IPv4-only, where the belief
> (and one I share) is that IPv6-only clients have some 6-to-4-ish
> gateway/NAT somewhere upstream, otherwise they wouldn't be able to reach
> most of the Internet.  IPv4 NAT still works for the majority of use
> cases still as of 2019.
> 
> Furthermore, faux-political statements like "IPv6 is more widely used
> than 2012" should be ignored and facts reiterated: IPv6 adoption is
> around 25% as of mid-2019.  And it's taken over 10 years to reach that.
> 
> IPv4 is also well-understood, and not, as Dave Horsfall accurately
> described, "a horse designed by a committee"; people are still trying to
> wrap their head around IPv6 NDP/RA, SLAAC, and a myriad of other things
> (dare I mention syntax?).  It's this which explains the sluggish
> adoption rate.
> 
> And yes, I am well-aware of how important IPv6 is in other regions,
> particularly Asia.  I am not belittling that need at all.  But not
> everyone globally has the same needs.
> 
> What should really be asked for is the opposite: for the FreeBSD ports
> folks to justify its removal.
> 
> How is this hurting you on a daily basis?  Is there a large percentage
> of Mk/ framework bits causing you pain?  Are the bulk of per-port
> patches inducing maintainer grief?  At what scale is this impacting you?
> In 7 years (since the OP picked 2012), how much time has been spent by
> maintainers ensuring IPV6=true works for their port(s)?  Are you truly
> OK throwing away the integration work done by many, many people (not
> just Project members!) over the past N years (see: per-port patches),
> and forcing people who still need the option to make their own ports
> tree to retain it?
> 
> Here's some harsh advice for the FreeBSD Project: quit changing shit for
> sake of change, often masked by lies like "XXX is stagnant/old" or
> similarly fallacious and loaded statements.  The project (both src and
> ports, but especially ports) have lost many very good people in the past
> 10+ years (and I'm not talking about me) *because* of that change for
> sake of change mindset -- the same mindset driving this request!  It's
> changes like this that drive people away from FreeBSD.  Really.  It's
> the same mindset that provoked people to stop using Linux distros due
> to systemd integration.
> 
> I will not be replying to this thread past this point.  I have said all
> that I care to say / spent enough time on it.  Just please stop hurting
> administrators and end users with proposals/actions like this.
> 
> * - Real-world IPv6 failures impacting end users tend to be higher
> than IPv4; this is anecdotal on my part, but I have a myriad of peers
> who have had to disable IPv6 for similar reasons.  The IPv4 fallback in
> software (both userland apps and network stacks) does not always work
> "correctly".  Just go see how often IPv6 failures/issues are reported on
> both NANOG and the outages@ mailing list.  And yes I am quite aware that
> a good portion of the Internet backbone at this point is IPv6 (that's
> nice, and not what we're talking about here).
> 
> ** - I still continue to see open-source software committing major fixes
> to AF_INET6 related code bits.  Major pieces of software include curl,
> wget, Busybox, DNS servers (pick one!), and ntp... just for starters.
> 

Let's get on 

Re: Installing packaged firefox wants to install tesseract

[Baptiste Daroussin]

On Fri, Oct 11, 2019 at 02:10:57PM +0800, Erich Dollansky wrote:
> Hi,
> 
> I just was wondering what this game has to do with the browser:
> 
> pkg install firefox says:
> 
> New packages to be INSTALLED:
> firefox: 69.0.2_1,1
> kf5-kholidays: 5.62.0
> opencv: 3.4.1_24
> tesseract: 4.1.0_3
> tesseract-data: 4.0.0
> aom: 1.0.0.2474
> 
> Is this game really required to run a browser?
> 
Run pkg upgrade first.

You probably end up with this because an installed package requires something
from new kde (kf5*) which ends up requiring tesseract (which is an OCR, not a
game ;))

pkg tries to be clever (and is not here) and try to fix a missing dependency
somewhere.

so first pkg upgrade, then pkg install, maybe also a pkg check -d if you still
have the issue.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Is IPV6 option still necessary?

[Baptiste Daroussin]

On Thu, Oct 10, 2019 at 05:40:55PM +0200, Lars Liedtke wrote:
> 
> Am 10.10.19 um 17:17 schrieb LuKreme:
> > On Oct 9, 2019, at 00:15, Baptiste Daroussin  wrote:
> >> I agree I don't see the reason why we should keep that ipv6 option. When 
> >> off
> >> this option does not bring much value to the users as the code for apps to
> >> support ipv6 mostly reside in the libc. Actually that was my intent in 
> >> 2012 to
> >> first turn it on by default everywhere and then drop the option entirely.
> > My isp does not support ipv6, so my services are not set to use it. I did 
> > have to specifically disable it in configuration for something, I forget 
> > what, but I have never felt the need to disable it in builds.
> >
> Why not just make building in IPv6 support the default, and introduce a
> flag if someone really needs or wants to build without that support?
> 
> Best regards
> 
Which is the current situation ;)

Except the ipv6 options is inconsistently spread accross the ports, most of the
ports do not even support building without ipv6 etc. Which is why came the
question about why not removing that option totally, because the current
situation is clearly inconsistent.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: [HEADSUP] Re: Is IPV6 option still necessary?

[Baptiste Daroussin]

On Thu, Oct 10, 2019 at 07:44:55PM +1100, Peter Jeremy wrote:
> On 2019-Oct-09 16:30:48 +0200, Baptiste Daroussin  wrote:
> >so if we want to proceed further in removing the option to build with or 
> >without
> >ipv6 for the ports side.
> 
> Last time I checked, XDMCP differs enough between IPv4 and IPv6 that xdm
> used a compile-time option to pick which to support.

For cases like that we should have flavors, exactly like we have for bird for
example.

Best regards,
Bapt


signature.asc
Description: PGP signature

[HEADSUP] Re: Is IPV6 option still necessary?

[Baptiste Daroussin]

On Wed, Oct 09, 2019 at 12:14:13PM +0200, Baptiste Daroussin wrote:
> On Wed, Oct 09, 2019 at 12:05:49PM +0200, Jan Beich wrote:
> > Yasuhiro KIMURA  writes:
> > 
> > > On October 10, 2012 IPV6 option of all ports was enabled by
> > > default. Commit message said "We are in 2012, it is time to activate
> > > IPV6 options by default everywhere".
> > >
> > > And now we are in 2019. IPv6 is more widely used than 2012. So I
> > > wonder if IPV6 option is still necessary.
> > 
> > ipv6 in CATEGORIES is also of dubious value nowadays. For one,
> > www/firefox has "ipv6" while www/chromium does not.
> 
> This one is even easier to fix ;)
> 
Done.

Now we can get back on the ipv6 option.

so if we want to proceed further in removing the option to build with or without
ipv6 for the ports side. Please speak up in reply to this email, if you are
building without ipv6, why are you doing so, what are the real benefit for it.
How bad it will impact you if we do remove that option?

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Is IPV6 option still necessary?

[Baptiste Daroussin]

On Wed, Oct 09, 2019 at 12:05:49PM +0200, Jan Beich wrote:
> Yasuhiro KIMURA  writes:
> 
> > On October 10, 2012 IPV6 option of all ports was enabled by
> > default. Commit message said "We are in 2012, it is time to activate
> > IPV6 options by default everywhere".
> >
> > And now we are in 2019. IPv6 is more widely used than 2012. So I
> > wonder if IPV6 option is still necessary.
> 
> ipv6 in CATEGORIES is also of dubious value nowadays. For one,
> www/firefox has "ipv6" while www/chromium does not.

This one is even easier to fix ;)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Is IPV6 option still necessary?

[Baptiste Daroussin]

On Tue, Oct 08, 2019 at 10:16:08PM +0300, abi via freebsd-ports wrote:
> 07.10.2019 09:18, Yasuhiro KIMURA пишет:
> > On October 10, 2012 IPV6 option of all ports was enabled by
> > default. Commit message said "We are in 2012, it is time to activate
> > IPV6 options by default everywhere".
> > 
> > And now we are in 2019. IPv6 is more widely used than 2012. So I
> > wonder if IPV6 option is still necessary.
> > 
> > If you use official packages then you always use IPv6-enabled
> > binaries. And even if you build packages by yourself you still use
> > IPv6-enabled ones unless you disable IPV6 option. So I think at most
> > only a few people uses IPv6-disabled packages.
> > 
> > Are there anybody who still disables IPV6 option for some serious
> > reason such as working around IPv6-related problem? If there aren't
> > then I think it's time to remove IPV6 option from ports framework.
> > 
> I'm writing from 2019 and I build kernel and ports without IPv6. For all
> this years I fail to understand why I need it.
> 
> My home devices fit 10.0.0.0/16 nicely, I have faith in NAT and I
> encountered no IPv6-only sites.
> 
> But I saw CVEs in IPv6 stack.

Plenty of FreeBSD things are ipv6 only in the FreeBSD cluster. In particular if
you do look at the build machines in the cluster, no ipv6 will mean no access to
the build log in case of failures.

I agree I don't see the reason why we should keep that ipv6 option. When off
this option does not bring much value to the users as the code for apps to
support ipv6 mostly reside in the libc. Actually that was my intent in 2012 to
first turn it on by default everywhere and then drop the option entirely.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: [HEADSUP] Removing DESTDIR support (aka chroot not staging)

[Baptiste Daroussin]

On Thu, Oct 03, 2019 at 01:02:09AM -0700, Mark Millard wrote:
> You may want to contact "jhb": head/base/README says:
> 
Well head/base has been written by me and the DESTDIR in there has nothing to do
with the feature called DESTDIR in the ports tree ;)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: [HEADSUP] Removing DESTDIR support (aka chroot not staging)

[Baptiste Daroussin]

On Wed, Oct 02, 2019 at 11:01:39PM +0400, Antranig Vartanian wrote:
> we never had any issues, the system was automated by the old sysdamin, 
> currently running FreeBSD 11.2, although I’m migrating to my way (make on NFS 
> server, make install on clients), so I wont need DESTDIR.
> 
> for the last 2 (maybe 3?) years, I haven’t seen any issues because of DESTDIR.

Thank you for the useful feedback

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: [HEADSUP] Removing DESTDIR support (aka chroot not staging)

[Baptiste Daroussin]

On Wed, Oct 02, 2019 at 10:55:12PM +0400, Antranig Vartanian wrote:
> Hi there!
> 
> I use DESTDIR at $work. our simple use case is the following: mount NFS to 
> server0 (which is more powerful), use DESTDIR to install into the NFS mounted 
> location, then other can use and merge those binaries. (no idea how it’s 
> done, just $legacy)
> 
> Some of our modern systems do just `make`, then we mount the powerful server 
> to the clients and do `make install` (no need for DESTDIR)
> 
> I think a more sane way would be using `make package` or using 
> Poudriere/Synth, but we have $legacy :)
> 
> I hope this answers the question regarding need/usage.
> 
Yup, that is 1 pont in the box of save DESTDIR for now ;), note that yes
poudriere would probably be a saner approach, but yes legacy ;)

Do you encounter issues you had to work around? or does it just work for you?

Best regards,
Bapt


signature.asc
Description: PGP signature

[HEADSUP] Removing DESTDIR support (aka chroot not staging)

[Baptiste Daroussin]

Hello,

As far as I know, the chroot support in the ports tree, is not used by anyone
(and is broken in many areas) this is the feature called DESTDIR.

If anyone is using it, can you please raise your voice, in order to understand
your use case and see if we should juste remove the support for it, or fix it to
turn it into a usable sate?

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: FLAVORS for Ruby

[Baptiste Daroussin]

On Tue, Sep 17, 2019 at 05:29:06PM +1000, Dewayne Geraghty wrote:
> Bottom line: flavors came into being to satisfy specific needs.  Python 2
> underwent substantial changes during the upgrade to python 3, to the extent
> that many (most) python applications would cease to function.  Similarly
> php5 to php7.  Without flavours the user-base would've been severly
> impacted during the upgrade transition where some fraction of their
> applications would fail.  Flavours, though I didn't appreciate it at the
> time, was/is a really smart move and has saved most of us contorting our
> systems  with different versions of the "same" software
> 
> I suppose if the ruby developers make such a substantial change to the
> language that applications break, then adding flavors to ruby might be
> worthwhile.  As stated, there is substantial effort required and the need
> significant.  And as I still have "ports" that use python2 (though most use
> python3), I greatly appeciate their effort.
> 
> Is there a specific issue, ie breakage requiring ruby flavors?

Thank you Dewayne, that is exactly it!

Flavors tends to complexify the ports framework, so they have to be used with
caution. the more flavours that are being added the more impacted it has on the
package building performances, but also on the complexity of the ports tree
itself. It also complexify the life of maintainers who have then to test every
possible flavors.

We at portmgr have decided to make a rule to try to find the right balance.

If you look at flarvors for python you can see that the only supporte flavor 
are:
one flavor for python3 and one flavor for python2 for the reason exposed by
Dewayne exactly. Same goes for php.

The last point is about end users, lots of end user are confused when you have
too many choices, each time a decision is made on the ports tree, the main
target should be to think what will happen for end users. how can they chose
what is the right version for them etc.

What about big "ruby" project like puppet, should we have 3 version of it
because ruby is flavored? how will end user pick up which is the right one here.

Again we do try to find the right balance.

So yes if someone has strong arguments in favor of ruby flavors that will
improve the user experience, then we will gladely add it.

Also note that if you look at python's flavors, while is simplified a lot the
life of end users we have ended up in a quite poor maintenance situation, lots
of ports are packages for all the flavours while not working with all of them,
many end user programs are being packages in both flavours for the sake of it,
but it confuses users for now reasons. That is something we should be careful
about.

As for the build time arguments, yes it is true as well and if someone wants 
kill
that arguments, there are room of improvements in both poudriere and pkg for
which we will be pleased to get working on ;)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: pkg check failures

[Baptiste Daroussin]

On Tue, Sep 10, 2019 at 11:41:00AM +0100, tech-lists wrote:
> Hi,
> 
> context: poudriere-devel, 12-stable
> 
> Some packages fail pkg check with the following errors:
> 
> root@desktop:/root# pkg check -d caja
> Checking caja: 100%
> root@desktop:/root# pkg check -s caja
> Checking caja:   0%
> caja-1.22.1_1: checksum mismatch for /usr/local/share/mime/XMLnamespaces
> caja-1.22.1_1: checksum mismatch for /usr/local/share/mime/aliases
> caja-1.22.1_1: checksum mismatch for /usr/local/share/mime/generic-icons
> caja-1.22.1_1: checksum mismatch for /usr/local/share/mime/globs
> caja-1.22.1_1: checksum mismatch for /usr/local/share/mime/globs2
> caja-1.22.1_1: checksum mismatch for /usr/local/share/mime/icons
> caja-1.22.1_1: checksum mismatch for /usr/local/share/mime/magic
> caja-1.22.1_1: checksum mismatch for /usr/local/share/mime/mime.cache
> caja-1.22.1_1: checksum mismatch for /usr/local/share/mime/subclasses
> caja-1.22.1_1: checksum mismatch for /usr/local/share/mime/treemagic
> caja-1.22.1_1: checksum mismatch for /usr/local/share/mime/types
> Checking caja: 100%
> 
> should I raise a bug?

The problem is the caja package is broken as it lists in its plist files that
do not belong there as they are generated at install time.

Maintainer in CC

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Reinstalling with dependencies

[Baptiste Daroussin]

On Wed, May 22, 2019 at 01:11:05PM +0100, Grzegorz Junka wrote:
> 
> On 22/05/2019 12:51, Baptiste Daroussin wrote:
> > On Wed, May 22, 2019 at 12:43:33PM +0100, Grzegorz Junka wrote:
> > > Is there any way to reinstall a package with all its dependencies?
> > > 
> > > 
> > > I am getting the following error:
> > > 
> > > root@someserv:~ # pkg check -d
> > > Checking all packages: 100%
> > > elinks is missing a required shared library: libjs.so
> > > 
> > > 
> > 2 reasons may happen for that to happen:
> > 1/ spidermonkey17 does not have a proper SONAME for the libjs.so file it
> > provides (bug 1)
> > 2/ somehow the linked port seems to not register properly spidermonkey17 as 
> > a
> > direct dependency of elinks when the option is checked (bug 2)
> > 
> > I have checked the case 1 and yes libjs.so is buggy I haven't yet checked 
> > the
> > case 2, but I quite sure there is a bug there as well, resulting in a 
> > package
> > that does not have the proper dependencies registered at the creation
> > 
> > Best regards,
> > Bapt
> 
> 
> Are you saying that even if elinks was reinstalled with dependencies that
> wouldn't help?
> 
> We have two issues here:
> 
> 1. How to reinstall a package with dependencies (as stated in the subject)
> 
> 2. Would reinstalling elinks with all dependencies fix the issue mentioned
> in the email
> 
> I have a couple more packages broken like elinks. I didn't include them
> because I only wanted to post an example and assumed they would be fixed if
> I reinstalled them properly. But here we go:

No I do mean the elinks packages is probably broken when build with the option
that brings in spidermonkey as a dependency
> 
> root@someserv:~ # pkg check -d
> Checking all packages: 100%
> elinks is missing a required shared library: libjs.so
> fireflies is missing a required shared library: libgfx.so
> py27-exiv2 is missing a required shared library: libexiv2.so.26
> 
> There was also virtuoso but I deinstalled it assuming it's an old version
> (the new version doesn't build due to openssl 1.1.0 issue).
> 
> So now I have two questions: Is it possible to reinstall a package with it's
> dependencies? And what to do with those broken packages above, should I
> report a bug?


I don't know for the specific case of the broken packages above, pkg check will
try to reinstall the missing dependency if any is found. If not, it just report
the broken packages and one has to figure out why those packages are broken.

I could easily guess for the elinks case. there might be similar reasons for
other packages.

For example reading at the MOVED file I can easily figure out that py27-exiv2 is
a package that no longer exists.

For fireflies I don't know, one has to check.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Reinstalling with dependencies

[Baptiste Daroussin]

On Wed, May 22, 2019 at 12:43:33PM +0100, Grzegorz Junka wrote:
> Is there any way to reinstall a package with all its dependencies?
> 
> 
> I am getting the following error:
> 
> root@someserv:~ # pkg check -d
> Checking all packages: 100%
> elinks is missing a required shared library: libjs.so
> 
> 

2 reasons may happen for that to happen:
1/ spidermonkey17 does not have a proper SONAME for the libjs.so file it
provides (bug 1)
2/ somehow the linked port seems to not register properly spidermonkey17 as a
direct dependency of elinks when the option is checked (bug 2)

I have checked the case 1 and yes libjs.so is buggy I haven't yet checked the
case 2, but I quite sure there is a bug there as well, resulting in a package
that does not have the proper dependencies registered at the creation

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: How to use @preexec to test for installed packages

[Baptiste Daroussin]

On Sat, Apr 06, 2019 at 03:58:48PM +0200, Matthias Fechner wrote:
> Dear all,
> 
> as pkg cannot handle CONFLICTS_INSTALL I tried now to implement this as
> a preinstall command using @preexec in pkg-plist.
> 
> The command should check if a package is installed and stop the
> installation or continue if the package is not installed.
> 
> I tried it with the following command:
> @preexec `/usr/sbin/pkg -N info -e gogs`; if [ $? -eq 0 ]; then echo
> "Gitlab cannot be installed together with gogs as both of them modify
> .ssh/authorized_keys" && exit 1; else echo "Gogs not installed,
> continue."; fi
> 
There is no reason at all to prevent gitlab to be installed along side with gogs
or even gitea because they both play with .ssh/authrized_keys.

It is up to the admin to be careful about it. As an admin I may want to be able
to install both to transition from one to another.

I can also have both on the same machine, but started with different users (I
already did that in the past with gitea and gogs and they both run fine
together.

My 2cts is admins should know what they are doing here and there is no reason to
register a conflict here. It is on purpose that pkg only check for conflicting
files, until now no cases justified yet any other case of conflict to be handled
by pkg. (If that ever happen then we will implement a conflict handling
solution).

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: category for VPN softwares?

[Baptiste Daroussin]

On Tue, Apr 02, 2019 at 03:47:30PM +0200, Mathieu Arnold wrote:
> On Tue, Apr 02, 2019 at 03:34:57PM +0200, Baptiste Daroussin wrote:
> > On Tue, Apr 02, 2019 at 06:29:09AM -0600, Adam Weinberger wrote:
> > > On Tue, Apr 2, 2019 at 6:24 AM Diane Bruce  wrote:
> > > >
> > > > On Tue, Apr 02, 2019 at 06:13:58AM -0600, Adam Weinberger wrote:
> > > > > On Tue, Apr 2, 2019 at 3:37 AM Mateusz Piotrowski <0...@freebsd.org> 
> > > > > wrote:
> > > > > >
> > > > > > 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.
> > > > >
> > > > > Creating new categories is absolutely doable! However, we have a
> > > > > pretty high bar for justifying it. There's no magic number, but our
> > > > > (portmgr's) precedent is that the new category must, at the time of
> > > > > creation, be as full as other categories like it.
> > > > >
> > > > > The most important thing in the new category proposal is a
> > > > > comprehensive list of ports that will be moved to it. Put that into a
> > > > > review or a PR and we can move forward. Fair warning though, if it's
> > > > > only about a dozen ports, it most likely will not be approved.
> > > > >
> > > > > My approach here is that new categories should be virtual unless the
> > > > > evidence for hard category is incontrovertible.
> > > >
> > > > It's far easier making a virtual category and easier to count ports.
> > > > e.g. https://www.freshports.org/hamradio
> > > >
> > > > We have 101 hamradio related ports with more coming...
> > > > korean has 43,portuguese has 15,russian has 42 although languages are a
> > > > special case palm has 15 ports but whatever. ;)
> > > >
> > > > I'd be surprised if there weren't more vpn ports than 101 so why not
> > > > go with a virtual ports category to start with?
> > > 
> > > Hi Diane,
> > > 
> > > That's a great approach to it! AFAIK we haven't explicitly used
> > > virtual categories as a staging ground for hard categories, but that
> > > seems like a really pragmatic approach; no matter the outcome, the
> > > ports tree comes out ahead.
> > > 
> > > # Adam
> > 
> > Just to say, having a new "real" category will force people to rework their
> > entry list for poudriere, reinstall things if they are using portmaster etc.
> 
> For poudriere, it is transparent as it parses MOVED, and new physical
> categories add entries in there. I think it will tell you something
> about it too.
> 
Same for portmaster yes, I just wanted to raise the fact that virtual categories
are transparent addition, but almost useless, while physical one have an impact
:)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: category for VPN softwares?

[Baptiste Daroussin]

On Tue, Apr 02, 2019 at 06:29:09AM -0600, Adam Weinberger wrote:
> On Tue, Apr 2, 2019 at 6:24 AM Diane Bruce  wrote:
> >
> > On Tue, Apr 02, 2019 at 06:13:58AM -0600, Adam Weinberger wrote:
> > > On Tue, Apr 2, 2019 at 3:37 AM Mateusz Piotrowski <0...@freebsd.org> 
> > > wrote:
> > > >
> > > > 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.
> > >
> > > Creating new categories is absolutely doable! However, we have a
> > > pretty high bar for justifying it. There's no magic number, but our
> > > (portmgr's) precedent is that the new category must, at the time of
> > > creation, be as full as other categories like it.
> > >
> > > The most important thing in the new category proposal is a
> > > comprehensive list of ports that will be moved to it. Put that into a
> > > review or a PR and we can move forward. Fair warning though, if it's
> > > only about a dozen ports, it most likely will not be approved.
> > >
> > > My approach here is that new categories should be virtual unless the
> > > evidence for hard category is incontrovertible.
> >
> > It's far easier making a virtual category and easier to count ports.
> > e.g. https://www.freshports.org/hamradio
> >
> > We have 101 hamradio related ports with more coming...
> > korean has 43,portuguese has 15,russian has 42 although languages are a
> > special case palm has 15 ports but whatever. ;)
> >
> > I'd be surprised if there weren't more vpn ports than 101 so why not
> > go with a virtual ports category to start with?
> 
> Hi Diane,
> 
> That's a great approach to it! AFAIK we haven't explicitly used
> virtual categories as a staging ground for hard categories, but that
> seems like a really pragmatic approach; no matter the outcome, the
> ports tree comes out ahead.
> 
> # Adam

Just to say, having a new "real" category will force people to rework their
entry list for poudriere, reinstall things if they are using portmaster etc.
No problem at all for pkg(8) users as it would be transparent

As for the virtual category it will work, but has the very limited effect of
only allowing things like freshports to list things withing that category,
almost nothing else do use the virtual categories.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: www/webkit-gtk2 deprecation?

[Baptiste Daroussin]

On Mon, Feb 25, 2019 at 11:33:11AM +0100, Christoph Moench-Tegeder wrote:
> ## Jonathan Chen (j...@chen.org.nz):
> 
> > I notice that www/webkit-gtk2 has just been marked as FORBIDDEN and
> > DEPRECATED. While I'm usually for putting down unmaintained ports,
> > this particular port is a dependancy for java/eclipse.
> 
> And for more, e.g. x11-toolgits/wxgtk30 (with default OPTIONS).
> Removing the old webkit-gtk versions is a worthy goal, but doing
> than on such a short notice (and with FORBIDDEN) creates a rather
> large breakage. (But it sure gets people's attention, I give you that).
> 
> I second the motion to postpone the removal of the old webkits, and
> maintainers of affected ports should have some chance to fix their
> dependencies.
> 
wx* ports has been switch to gtk3 (meaning webkit2), so they should now build
again.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Any user of esound daemon?

[Baptiste Daroussin]

On Mon, Feb 25, 2019 at 11:39:25AM +0100, Christoph Moench-Tegeder wrote:
> ## Baptiste Daroussin (b...@freebsd.org):
> 
> > Are there any esound users left that can raise a voice to explain why and 
> > how
> > they are using esound? In my latest playing directly with I couldn't find 
> > any
> > value added compared to directly using OSS for example or using any of the 
> > other
> > daemons
> 
> Even better: at least pulseaudio can provide an esd-protocol socket,
> so it's usable as a drop-in replacement (yes, I know, not everyone
> likes pulseaudio, but it "works for me").

Is it still the case? I thought this was removed from pulse after some time?

Best regards,
Bapt


signature.asc
Description: PGP signature

Any user of esound daemon?

[Baptiste Daroussin]

Hello everyone,

esound daemon is a very long time abandonware, it is not used anymore by most
modern desktops applications.

I think it is time to start deprecating it and removing the infrastructure parts
(in ports) that supports it.

Are there any esound users left that can raise a voice to explain why and how
they are using esound? In my latest playing directly with I couldn't find any
value added compared to directly using OSS for example or using any of the other
daemons

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: vim - GTK2 or GTK3?

[Baptiste Daroussin]

On Tue, Feb 19, 2019 at 08:42:29AM +0100, Guido Falsi wrote:
> On 02/01/19 16:20, Niclas Zeising wrote:
> > On 2019-01-02 10:42, Lars Engels wrote:
> [...]
> > +1, GTK3 is probably the best choice.
> > 
> > As a side note, it looks like libreoffice defaults to GTK2 as well,
> > perhaps it should be switched to GTK3 also?
> > Regards
> 
> I have used libreoffice compiled with GTK3 for a while, but I had to
> switch it back to GTK2 recently due to UI problems. Scrollbars
> disappearing, buttons without any kind of bevel, font selector combos
> not working.
> 
> I don't know what was causing that, maybe it was a misconfiguration on
> my part, but I think it should be investigated before switching the default.

libreoffice is not using yet GTK3 by default because of those issues, so not on
your side.

Noone had really time to invest why it has those bugs on freebsd. (on linux and
openbsd - iirc - GTK3 is the default for long)

Best regards
Bapt


signature.asc
Description: PGP signature

Re: how to do pkg_info -W without pkg_info?

[Baptiste Daroussin]

On Sun, Sep 30, 2018 at 07:29:37PM +0200, Matthias Apitz wrote:
> El día Sunday, September 30, 2018 a las 11:09:20AM -0600, @lbutlr escribió:
> 
> > I would like to find out what port installed a specific file, and in 
> > searching I found the suggestion, from 2010, to use
> > 
> > pkg_info -W 
> > 
> > But on FreeBSD 11.1-p4-RELEASE with postmaster, there is no pkg_info and 
> > `pkg info` doesn't have a -W flag nor, apparently, a way to check for where 
> > a file came from.
> > 
> > 
> 
> $ which gcc
> /usr/local/bin/gcc
> $ pkg which /usr/local/bin/gcc
> /usr/local/bin/gcc was installed by package gcc-4.9.4
> 
> $ man pkg-which
> 
> 
>   matthias
> 
pkg which -p gcc :)

Bapt


signature.asc
Description: PGP signature

Re: Port collection (incorrectly) marked as not supporting 11.1

[Baptiste Daroussin]

On Mon, Oct 01, 2018 at 11:22:24AM -0400, Aryeh Friedman wrote:
> On:
> 
> FreeBSD lilith 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321664: Fri Jul 28
> 23:35:18 EDT 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> Attempting to run make on any port produces:
> 
> /!\ ERROR: /!\
> 
> Ports Collection support for your FreeBSD version has ended, and no ports
> are
> guaranteed to build on this system. Please upgrade to a supported release.
> 
> No support will be provided if you silence this message by defining
> 
> How is this possibly correct when 11.1 is still listed as a production
> release!?!?!?!?

https://www.freebsd.org/security/ the EOL date is set to September 30, 2018.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: how to enforce one version of python

[Baptiste Daroussin]

On Tue, Sep 11, 2018 at 03:28:15PM +0100, tech-lists wrote:
> Hi,
> 
> There are a number of ports that seem to have their own preferential flavour
> of python, and some for example want to install python27 and python36 in the
> same place, and it's a pain when using portupgrade or similar tools.
> 
> I have this in my /etc/make.conf:
> 
> DEFAULT_VERSIONS+= python=2.7
> 
> Is this incorrect? I assume it must be, as for example devel/pylint
> (pylint-py27-1.9.2) wants to upgrade to pylint-py36-2.1.1
> 
That is because portupgrade is not flavor aware (or badly if it has been patched
to support flavors)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: dialog4ports-0.1.6 screwed up ?

[Baptiste Daroussin]

On Mon, Aug 27, 2018 at 01:45:47PM +0200, Axel Rau wrote:
> Thanks Bapt,
> 
> but…
> 
> > Am 27.08.2018 um 13:30 schrieb Baptiste Daroussin :
> > 
> > On Mon, Aug 27, 2018 at 01:25:20PM +0200, Axel Rau wrote:
> 
> >> [build3:devel/librelp] root# printenv | grep DIALOG
> >> [build3:devel/librelp] root# grep DIALOG /etc/make.conf 
> 
> 
> [build3:devel/librelp] root# make rmconfig
> ===> No user-specified options configured for librelp-1.2.17_1
> [build3:own-tree/devel/librelp] root# make config
> ===> Building/installing dialog4ports as it is required for the config dialog
> ===>  Cleaning for dialog4ports-0.1.6
> ===> Skipping 'config' as NO_DIALOG is defined
> 

It could be in your environement variable also

Bapt


signature.asc
Description: PGP signature

Re: dialog4ports-0.1.6 screwed up ?

[Baptiste Daroussin]

On Mon, Aug 27, 2018 at 01:25:20PM +0200, Axel Rau wrote:
> Hi all,
> 
> make config does not work with various ports.
> dialog4ports says:  Skipping ‚config‘ as NO_DIALOG is defined

Somewhere you defined "NO_DIALOG" meaning dialog4ports is not executed.
Either remove it or cleanup the old options you already defined (it can be in
your make.conf, or previously via dialog4ports (make config).
make rmconfig # will remove that if that is the case

In general make config will do nothing with NO_DIALOG being defined as it is
said in the messages below

Best regards,
Bapt
> 
> I have no idea whats going on here:
> 
> [build3:devel/librelp] root# make config
> ===> Building/installing dialog4ports as it is required for the config dialog
> ===>  Cleaning for dialog4ports-0.1.6
> ===> Skipping 'config' as NO_DIALOG is defined
> ===>  License BSD2CLAUSE accepted by the user
> > You must select one and only one option from the SSLLIB single
> => No option was selected (and one must be)
> *** Error code 1
> 
> Stop.
> make[2]: stopped in /basejail/usr/ports/ports-mgmt/dialog4ports
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /basejail/usr/ports/ports-mgmt/dialog4ports
> ===> Options unchanged
> > You must select one and only one option from the SSLLIB single
> => No option was selected (and one must be)
> Config is invalid. Re-edit? [Y/n] Y
> ===> Building/installing dialog4ports as it is required for the config dialog
> ===>  Cleaning for dialog4ports-0.1.6
> ===> Skipping 'config' as NO_DIALOG is defined
> ===>  License BSD2CLAUSE accepted by the user
> > You must select one and only one option from the SSLLIB single
> => No option was selected (and one must be)
> *** Error code 1
> 
> Stop.
> 
> [build3:devel/librelp] root# printenv | grep DIALOG
> [build3:devel/librelp] root# grep DIALOG /etc/make.conf 
> [build3:devel/librelp] root# 
> 
> ———
> Any help appreciated.
> 
> Thanks, Axel
> ---
> PGP-Key:29E99DD6  ☀  computing @ chaos claudius
> 
> ___
> 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"


signature.asc
Description: PGP signature

Re: Removing git dependencies on perl5 and python27

[Baptiste Daroussin]

On Fri, Jun 15, 2018 at 10:24:06AM +0200, Franco Fichtner wrote:
> 
> > On 15. Jun 2018, at 10:10 AM, Mahmoud Al-Qudsi  wrote:
> > 
> > On Fri, Jun 15, 2018 at 2:57 AM, Michael Gmelin  wrote:
> >> Last time I checked, building git without Perl broke submodules (which is 
> >> a core feature that should work with a default installation).
> > 
> > I fully agree. Fortunately, (at least at a first glance) that does not
> > seem to be the case.
> 
> The bottom line is that excluding Perl and Python support from git
> will make it only usable for automated shell scripting.
> 
> Interactive parts require Perl or Python so there is nothing to be
> gained from breaking POLA for existing users of the git FreeBSD
> package or git software in general as any random tutorial out there
> may not work for FreeBSD anymore.
> 
> For emphasis, this is suboptimal at best...
> 
The best here is to wait for subpackages, which would allow to have git,
git-python, git-perl or something like that

Bapt


signature.asc
Description: PGP signature

Re: Pause pkg install messages

[Baptiste Daroussin]

On Thu, May 24, 2018 at 07:00:02AM -0700, Chris H wrote:
> On Thu, 24 May 2018 10:03:47 +0100 "Johannes Lundberg"  
> said
> 
> > On Thu, May 24, 2018 at 9:27 AM Bob Eager  wrote:
> > 
> > > On Thu, 24 May 2018 09:08:17 +0100
> > > Johannes Lundberg  wrote:
> > >
> > > > In addition to that it would be nice (if it's not already done) to
> > > > store this information in a log file somewhere so that one can
> > > > revisit and see what needs to be manually configured for each
> > > > installed package.
> > >
> > > I have this in syslog.conf:
> > >
> > >  !pkg,pkg-static
> > >  *.* /var/log/pkg.log
> > >
> > 
> > Thanks for the tip. I'll use this.
> > However, someone who knows about this probably know how to manually
> > configure their system already.
> > 
> > I want to make sure first timers and newbies don't miss important messages
> > on how to configure the system.
> > 
> > Often we get inquires about stuff that is clearly described in the pkg
> > message and bug reports that are a consequence of wrong configuration.
> > How can we make this more clear so that it is not missed?
> ports-mgmt/portmaster used (probably still does) to concatenate the list
> of (port emitted) messages, and dump them to the console/screen when the
> build/install session completed.
> Perhaps pkg(8) could incorporate this, as well?

Have you already used pkg(8) ?

Bapt


signature.asc
Description: PGP signature

Re: zsh 5.5: core dump during serial login

[Baptiste Daroussin]

Le 17 avril 2018 00:20:43 GMT+02:00, "Dr. Peter Voigt" <pvo...@uos.de> a écrit :
>On Mon, 16 Apr 2018 12:56:45 +0200
>Baptiste Daroussin <b...@freebsd.org> wrote:
>
>> On Sun, Apr 15, 2018 at 12:33:08AM +0200, Dr. Peter Voigt wrote:
>> > Today I upgraded shells/zsh to version 5.5 on my FreeBSD
>> > 11.1-RELEASE-p9 machine.
>> > 
>> > During a login over serial line (wired or IPMI-SOL) I am
>immediately
>> > kicked out after a successful login. Syslogd shows:
>> > 
>> >  xxx kernel: pid xxx (zsh), uid 0: exited on signal 8
>> > (core dumped)
>> > 
>> > I immediately downgraded to zsh-5.4.2_1 and the error disappeared.
>> > 
>> > Is this a known error or should I created a ticket under
>> > https://bugs.freebsd.org/  
>> 
>> I have never heard of that error, so yes I would like a bug report
>> please
>> 
>> Best regards,
>> Bapt
>
>Bug ticket created:
>https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227565
>
>I hope the issue can be reproduced and fixed as soon as possible. I am
>currently using downgraded zsh-5.4.2_1 while having the package in hold
>status.
>
>Regards,
>Peter


I updated it to 5.5.1 and I can't reproduce with it. Can you check if it works 
for you? 

Best regards
Bapt
___
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: zsh 5.5: core dump during serial login

[Baptiste Daroussin]

On Sun, Apr 15, 2018 at 12:33:08AM +0200, Dr. Peter Voigt wrote:
> Today I upgraded shells/zsh to version 5.5 on my FreeBSD 11.1-RELEASE-p9
> machine.
> 
> During a login over serial line (wired or IPMI-SOL) I am immediately
> kicked out after a successful login. Syslogd shows:
> 
>  xxx kernel: pid xxx (zsh), uid 0: exited on signal 8 (core dumped)
> 
> I immediately downgraded to zsh-5.4.2_1 and the error disappeared.
> 
> Is this a known error or should I created a ticket under
> https://bugs.freebsd.org/

I have never heard of that error, so yes I would like a bug report please

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: `pkg version -PvL=` shows some ports as "orphaned"

[Baptiste Daroussin]

On Tue, Mar 13, 2018 at 09:50:35PM +0300, Lev Serebryakov wrote:
> On 13.03.2018 21:39, Walter Schwarzenfeld wrote:
> 
> > maybe, cause of this
> > 
> > pkg install devel/pecl-intl
>  Then "orphaned" status is misleading. "Renamed"?

There is no such thing as renamed yet in pkg. so there is no way for pkg to
figure pecl-intl has been renamed in php56-pecl-intl so yes it is orphaned.

And no the origin won't help here because it can be php72-pecl-intl or
php56-pecl-intl (well in the specific case of pecl-intl because there is only
one flavor it is not entirely true, but you get the idea :))

Bapt


signature.asc
Description: PGP signature

Re: daily security run output and joomla3

[Baptiste Daroussin]

On Sun, Jan 28, 2018 at 07:31:00PM +0100, Baptiste Daroussin wrote:
> On Mon, Jan 29, 2018 at 03:27:22AM +0900, Yasuhiro KIMURA wrote:
> > From: Larry Rosenman <l...@lerctr.org>
> > Subject: Re: daily security run output and joomla3
> > Date: Sun, 28 Jan 2018 12:04:56 -0600
> > 
> > > But as the OP notes, the joomla3 instructions *REQUIRE*
> > > removal of the install directory for security reasons, so 
> > > I understand where he is coming from. 
> > 
> > Do you mean that all installed file must be removed? If so, what about
> > simply deinstalling joomla3 package after instructions are finished?
> > 
> 
> Does changing the owners of the directory to nobody helps? joomla (www users)
> might not be able to read it

Another way (still ugly) would be 2 packages: joomla and
joomla-installation-cruft and once setup is done the user should pkg delete
joomla-installation-cruft

Just thinking, can't find better ideas so far :)

Bapt


signature.asc
Description: PGP signature

Re: daily security run output and joomla3

[Baptiste Daroussin]

On Mon, Jan 29, 2018 at 03:27:22AM +0900, Yasuhiro KIMURA wrote:
> From: Larry Rosenman 
> Subject: Re: daily security run output and joomla3
> Date: Sun, 28 Jan 2018 12:04:56 -0600
> 
> > But as the OP notes, the joomla3 instructions *REQUIRE*
> > removal of the install directory for security reasons, so 
> > I understand where he is coming from. 
> 
> Do you mean that all installed file must be removed? If so, what about
> simply deinstalling joomla3 package after instructions are finished?
> 

Does changing the owners of the directory to nobody helps? joomla (www users)
might not be able to read it

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: daily security run output and joomla3

[Baptiste Daroussin]

On Sun, Jan 28, 2018 at 12:04:56PM -0600, Larry Rosenman wrote:
> On Mon, Jan 29, 2018 at 02:56:51AM +0900, Yasuhiro KIMURA wrote:
> > From: Carmel NY 
> > Subject: Re: daily security run output and joomla3
> > Date: Sun, 28 Jan 2018 17:38:10 +
> > 
> > >>You can try "pkg check -r", see man pkg-check
> > > 
> > > Unfortunately, that has no affect.
> > 
> > Accoding to the messages of security periodic sript, the problrem is
> > not checksum mismatch but lost of package files. And "pkg check -r"
> > cannot recover it. So you should reinstall www/joomla3.
> > 
> But as the OP notes, the joomla3 instructions *REQUIRE*
> removal of the install directory for security reasons, so 
> I understand where he is coming from. 
> 
> As the maintainer, I'm not sure how to fix it.

I'm sorry but I have not idea as well on how to fix.
As a matter of fact, I do think web apps (most of them at least) have no reasons
to be packaged at all. That said, it does not solve the problem :)

To be more constructive, that would require to track softly some files as
belonging to the package, which I don't like much... have a directory which act
like @sample might be doable but still I do consider that as a hack.

Any better idea welcomed

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Vote: making wayland=on default

[Baptiste Daroussin]

On Wed, Dec 20, 2017 at 09:20:20AM +, Johannes Lundberg wrote:
> Hi
> 
> I want to suggest that we enable wayland by default. In current state
> having some parts of wayland in ports is basically useless the
> end-users themselves re-build gtk30 and mesa-libs with wayland
> enabled.
> 
> libwayland-egl.so from mesa-libs and the extra libraries and headers
> from gtk30 adds like a few KB, a drop in the ocean compared to xorg
> packages. (might be something more that I missed)
> 
> Personally I see no reason not to make it default on, even with
> flavors coming up. For any Desktop user (as well as embedded devices
> like IVI-systems and whatnot), Wayland is the future. There's no
> escaping that.
> 
> Wayland has been quite usable on FreeBSD for over a year now but
> access to it is limited due to the extra efforts required to use it.
> 
> If we are to compare with the other guys, several Linux distros are
> already switching to wayland-based compositors as default window
> server.
> 
> What do you think?
> 

I agree on that, we should activate wayland everywhere by defualt, as it does
not prevent at all from having a fully fonctionnal regular X working as well.

All wayland option should be on, and this as nothing to do with flavors :)

Please do it :)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Working on FLAVOR support in portmaster

[Baptiste Daroussin]

On Fri, Dec 08, 2017 at 02:13:09PM +0100, Alexander Leidinger wrote:
> Quoting Baptiste Daroussin <b...@freebsd.org> (from Thu, 7 Dec 2017 14:54:27
> +0100):
> 
> > On Thu, Dec 07, 2017 at 02:49:45PM +0100, Alexander Leidinger wrote:
> 
> > > Alternatively, how would a FreeBSD committer like Stefan or
> > > Torsten or me or whoever gain write access to
> > > https://github.com/freebsd/portmaster/ so get some progress in
> > > the official portmaster location and create a new release
> > > (sorry my ignorance for github and how it works, I'm used to
> > > CVS/SVN workflows)?
> > 
> > They just need to ask git admins to get access, I have already asked
> > Stefan (not
> > reply yet)
> > 
> > They can also ask me directly if they want given I am part of the git admins
> 
> And I see that I'm already part of the FreeBSD organisation on github, so I
> should have access. So... currently portmaster is wild-wild-west territory?
> No real owner, anyone willing to fix/improve is free to do so, and it's up
> to each individual to wear his fireproof-suite (after flavours is settled I
> would be interested to have a look at the local packages installation pull
> request)?
> 

The official maintainer is tz@ for now, he just handed the maintainership to se@

As for push access for now, only git-admin (which I am part of) and bdrewery
(who use to maintain portmaster) have access. I'll be glad to give push acces to
more people.

For now I have pushed patches from Stefan in the repo (not the flavor support
but the preliminary to it)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Working on FLAVOR support in portmaster

[Baptiste Daroussin]

On Thu, Dec 07, 2017 at 02:49:45PM +0100, Alexander Leidinger wrote:
> 
> Quoting Stefan Esser  (from Tue, 5 Dec 2017 08:35:55 +0100):
> 
> > Am 05.12.17 um 00:43 schrieb Tatsuki Makino:
> > > By the way, where is the clever way to update to flavor?
> > > I am using portmaster.
> > 
> > I'm working on FLAVOR support in portmaster. My version did already build
> 
> I wonder if it would make sense to import portmaster into
> FreeBSD SVN. It is a tool targeting the FreeBSD ports tree and
> pkg infrastructure and it looks like it is important for a not
> so small userbase.
> 
> While there are several committers within the contributors (I'm
> not sure if this means they have write access to the repo or if
> it just means that a pull request was accepted), there is more
> or less no progress since 2013 (yes, a few commits there, but
> also useful pull requests for e.g. local package installation
> with pkgng support which are not integrated at all). If we look
> at how widespread the use of portmaster still is (and I'm sure
> there are more people which use it and are more cool-headed and
> just wait if there are some fixes coming for it in the near
> future like it was the case for the pkgng switch), it would
> make sense to have the (as it looks)
> abandoned-on-github-portmaster-version in a FreeBSD controlled
> area.
> 
> Alternatively, how would a FreeBSD committer like Stefan or
> Torsten or me or whoever gain write access to
> https://github.com/freebsd/portmaster/ so get some progress in
> the official portmaster location and create a new release
> (sorry my ignorance for github and how it works, I'm used to
> CVS/SVN workflows)?

They just need to ask git admins to get access, I have already asked Stefan (not
reply yet)

They can also ask me directly if they want given I am part of the git admins

Bapt


signature.asc
Description: PGP signature

Re: gnu ltdl and FreeBSD

[Baptiste Daroussin]

On Mon, Oct 16, 2017 at 08:58:32AM +, blubee blubeeme wrote:
> I've tried passing CONFIGURE_ARGS or removing it, both gives the same error
> below.
> LIB_DEPENDS= libltdl.so:devel/libltdl
> GNU_CONFIGURE=   yes
> CONFIGURE_ARGS= --enable-ltdl-install
> USES=autoreconf gmake libtool
> 
> the config.log file is there and it's pretty long as well I am looking
> through it but I am not sure what exactly to look for.
> 
> Here's a pastebin with that config.log file: https://pastebin.com/NjkgBTeM

configure:20354: cc -o conftest -O2 -pipe  -fstack-protector
-fno-strict-aliasing -I/usr/local/include  -fstack-protector conftest.c -lltdl
>&5
/usr/bin/ld: cannot find -lltdl


this is your failure.

Try adding USES=localbase and if it fails adding USES=localbase:ldflags

Bapt


signature.asc
Description: PGP signature

Re: gnu ltdl and FreeBSD

[Baptiste Daroussin]

On Mon, Oct 16, 2017 at 08:25:57AM +, blubee blubeeme wrote:
> This is what the Makefile looks like, the file still fails:
> 
> LICENSE=  GPLv3+
> BUILD_DEPENDS=  gsed:textproc/gsed
> 
> BINARY_ALIAS=sed=gsed
> 
> LIB_DEPENDS= libltdl.so:devel/libltdl
> GNU_CONFIGURE=   yes
> USES=autoreconf gmake
> 
> same compile error.
> That config.h should be auto generated and setup by autoreconf but its not.

The config.h is not setup by autoreconf neither generated by autoreconf. the run
of the configure script should generated it except if it fails. Have you read
the config.log (very long and verbose script that explains what happened -
including failures - during the run of the configure script)

Also you should add "libtool" to your USES line

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: gnu ltdl and FreeBSD

[Baptiste Daroussin]

On Mon, Oct 16, 2017 at 05:37:57AM +, blubee blubeeme wrote:
> I'm trying to port some software that keeps failing when it tries to find a
> config.h.
> 
> I know the config.h file is there but I think the compilation is failing
> because it's trying to build ltdl and freebsd doesn't need that since
> freebsd already has dlopen in libc.
> 
> Which configure flag could I try to get rid of building that lib? The full
> configure --help file is below.
> 
> My current makefile has these settings:
> HAS_CONFIGURE=   yes
> CONFIGURE_ARGS=  --without-included-ltdl --disable-ltdl-install
> USES=autoreconf gmake

First this is wrong, if you have USES=autoreconf it means you are using GNU
configure, so s/HAS_CONFIGURE/GNU_CONFIGURE/g

Do you have libltdl.so:devel/libltdl in your LIB_DEPENDS line

Bapt


signature.asc
Description: PGP signature

Re: Why ports are allowed to be linked with base OpenSSL?

[Baptiste Daroussin]

On Sun, Oct 15, 2017 at 06:15:24PM +, Yuri wrote:
> Uses/ssl.mk allows SSL_DEFAULT=base. I know this has been discussed here
> before, but why is this even allowed? If some ports are built with
> SSL_DEFAULT=base, and some with SSL_DEFAULT=openssl, this will obviously
> cause conflicts when two incompatible openssl libraries will be mapped into
> the same process.
> 
> 
> Isn't it better to only allow port OpenSSL for ports, and disallow base
> OpenSSL in ports, so that there will be homogeneity of openssl?
> 

First the default SSL is supposed to be for the entire ports tree, not only for
a bunch of ports.

Second, yes that is the plan but it takes time and it is not that easy to make
it happen :)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Getting off topic (Re: portmaster, portupgrade, etc)

[Baptiste Daroussin]

On Fri, Oct 06, 2017 at 01:28:59PM +, George Mitchell wrote:
> On 10/06/17 04:20, Baptiste Daroussin wrote:
> > On Fri, Oct 06, 2017 at 08:13:42AM +, Steve Kargl wrote:
> >> On Fri, Oct 06, 2017 at 09:41:28AM +0200, Baptiste Daroussin wrote:
> >>> On Wed, Oct 04, 2017 at 05:15:18PM +, Steve Kargl wrote:
> >>>> On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:
> >>>>>
> >>>>> Poudriere really needs its own small book. Yes, you can do simple
> >>>>> poudriere installs, but once you start covering it properly the docs
> >>>>> quickly expand. My notes alone are longer than my af3e chapter
> >>>>> limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
> >>>>> 2018).
> >>>>
> >>>> Please include a discussion on how to use poudriere on
> >>>> a system with limited resouces (e.g., 10 GB of free
> >>>> diskspace and less than 1 GB free memory).  I know
> >>>> portmaster works well [1] within an environment with
> >>>> only 4 GB free diskspace and 1 GB memory.
> >>>>
> >>>> [1] portmaster worked well prior to portmgr's decision
> >>>> to displace simple small tools in favor of a sledge
> >>>> hammer.
> >>>
> >>> FUD.. portmgr never took any decision like this.
> >>> The problem with portmaster (beside some design flows regarding
> >>> the "not build in a clean room") is that it is not maintained anymore.
> >>> (Note that it has never been maintained by portmgr at all).
> >>
> >> I'm well aware of Doug Barton's history with FreeBSD.  You
> >> can paint it with whatever color you want.
> >>
> >> If you (and other poudriere) contributors stated that flavors/subpackages
> >> would not be supported by poudriere, would flavors/subpackages been
> >> wedged into the ports build infrastructure?
> > 
> > Yes because if you look at mailing lists etc, you ould have figured out that
> > this is the number one feature requested in the ports tree for years.
> > 
> > Also yes we would have make sure that the tools used to build official 
> > packages
> > would have worked with it, prior poudriere it was tinderbox.
> > 
> > And again we are giving time (and warning in advance) for all the tools to 
> > catch
> > up!
> > 
> > Best regards,
> > Bapt
> > 
> Speaking solely for myself, I am more than pleased by all the work
> Baptiste and fellow developers have put into the ports infrastructure.
> THANK YOU!  But also, portmaster is a life saver for me with my 4GB
> build machine, so I hope I can participate in reviving it.  -- George
> 

Thank you,

I will be more than happy to merge patches in
https://github.com/freebsd/portmaster which makes it handle flavors

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: [RFC] less patches: control the PATH

[Baptiste Daroussin]

On Fri, Oct 06, 2017 at 01:11:46PM +, Baptiste Daroussin wrote:
> Hi all,
> 
> Here is a patch to add a new feature I am willing to get for a while:
> https://reviews.freebsd.org/D12603
> 
> What this patch does it basically prepend to PATH a new directory (inside
> WRKDIR)
> 
> A user can control which binary will be found in the PATH of the build 
> sequences
> easily by adding
> BINARY_RENAME=source target
> 
> This will create a sumlink in the WRKDIR/.bin directory:
> ${WRKDIR}/.bin/target -> source
> 
> The goal here to avoid patching a port which needs to use for example gsed
> instead of our bsd sed
> BINARY_RENAMe=gsed sed
> 
> of specify gcc will be gcc7, etc
> 
> This should remove lots of custom patches in the ports tree.
> 
> PS: this should break no port building tool :)
> PS2: the BINARY_RENAME variable name sucks, any better name is welcome :)

renamed BINARY_LINKS which is less worse :)

Best regards,
Bapt


signature.asc
Description: PGP signature

[RFC] less patches: control the PATH

[Baptiste Daroussin]

Hi all,

Here is a patch to add a new feature I am willing to get for a while:
https://reviews.freebsd.org/D12603

What this patch does it basically prepend to PATH a new directory (inside
WRKDIR)

A user can control which binary will be found in the PATH of the build sequences
easily by adding
BINARY_RENAME=  source target

This will create a sumlink in the WRKDIR/.bin directory:
${WRKDIR}/.bin/target -> source

The goal here to avoid patching a port which needs to use for example gsed
instead of our bsd sed
BINARY_RENAMe=  gsed sed

of specify gcc will be gcc7, etc

This should remove lots of custom patches in the ports tree.

PS: this should break no port building tool :)
PS2: the BINARY_RENAME variable name sucks, any better name is welcome :)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: portmaster, portupgrade, etc

[Baptiste Daroussin]

On Thu, Oct 05, 2017 at 10:08:54PM +, Baho Utot wrote:
> 
> 
> On 10/05/17 16:27, Grzegorz Junka wrote:
> > 
> > On 05/10/2017 19:54, Baho Utot wrote:
> > > 
> > > 
> > > On 10/04/17 16:39, Ernie Luzar wrote:
> > > 
> > > > Here's my take on that.
> > > > 
> > > > The future direction has already been decided by the FreeBSD
> > > > leaders 2 years ago with their development of a better pkg
> > > > system.
> > > > 
> > > 
> > > [putolin]
> > > 
> > > > Don't let the few old school die hearts who are afraid of any
> > > > change and make the most noise influence you. There will always
> > > > be edge case user who think their needs out weight what is best
> > > > for the group.
> > > 
> > > So what you are really saying is Go to hell old farts we don't need
> > > you here.  We are not going to listen to you as you are too old to
> > > know anything.  You are old and stupid.
> > > 
> > > It is looking like I will need to move away from FreeBSD if that is
> > > really what is being accomplished here.
> > 
> > But do those old farts have anything interesting to say or they are just
> > making noise? What's the alternative to the proposed direction?
> > 
> > GrzegorzJ
> 
> Everyone should be heard.  who knows if the direction would be the same?
> 
> You won't hear from this old fart as every time I have had a question or
> input on direction All I got was grief.
> 
> The last time was about pkgng.  As someone that moved from LFS/building my
> own distribution to FreeBSD, and adding a package manager and tools for LFS.
> I think I may have learned something in that process.  SO what did you folks
> do, Well I was just bitch slapped down.  So much for user input.  Hell pkgng
> can not even merge configurations file in /etc when is that going to be
> fixed.
It can... and for a while, the fact it is not used in packaging base is another
subject, but the tool can definitly do it.

[...]
> 
> Anyway it looks like I will be moving to OpenBSD or just go back to rolling
> my own as I have more free time to pursue building systems that work for me.
> FreeBSD just doesn't look like it will be a fit for me in the future.

Have you figured out that OpenBSD is a step further in the direction you are
rejecting: They have FLAVORS for decades and they do strongly recommend users to
use binary packages in the first place... Just sating...

Bapt


signature.asc
Description: PGP signature

Re: portmaster, portupgrade, etc

[Baptiste Daroussin]

On Fri, Oct 06, 2017 at 08:13:42AM +, Steve Kargl wrote:
> On Fri, Oct 06, 2017 at 09:41:28AM +0200, Baptiste Daroussin wrote:
> > On Wed, Oct 04, 2017 at 05:15:18PM +, Steve Kargl wrote:
> > > On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:
> > > > 
> > > > Poudriere really needs its own small book. Yes, you can do simple
> > > > poudriere installs, but once you start covering it properly the docs
> > > > quickly expand. My notes alone are longer than my af3e chapter
> > > > limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
> > > > 2018).
> > > 
> > > Please include a discussion on how to use poudriere on
> > > a system with limited resouces (e.g., 10 GB of free
> > > diskspace and less than 1 GB free memory).  I know
> > > portmaster works well [1] within an environment with
> > > only 4 GB free diskspace and 1 GB memory.
> > > 
> > > [1] portmaster worked well prior to portmgr's decision
> > > to displace simple small tools in favor of a sledge
> > > hammer.
> > 
> > FUD.. portmgr never took any decision like this.
> > The problem with portmaster (beside some design flows regarding
> > the "not build in a clean room") is that it is not maintained anymore.
> > (Note that it has never been maintained by portmgr at all).
> 
> I'm well aware of Doug Barton's history with FreeBSD.  You
> can paint it with whatever color you want.
> 
> If you (and other poudriere) contributors stated that flavors/subpackages
> would not be supported by poudriere, would flavors/subpackages been
> wedged into the ports build infrastructure?

Yes because if you look at mailing lists etc, you ould have figured out that
this is the number one feature requested in the ports tree for years.

Also yes we would have make sure that the tools used to build official packages
would have worked with it, prior poudriere it was tinderbox.

And again we are giving time (and warning in advance) for all the tools to catch
up!

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: portmaster, portupgrade, etc

[Baptiste Daroussin]

On Wed, Oct 04, 2017 at 05:15:18PM +, Steve Kargl wrote:
> On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:
> > 
> > Poudriere really needs its own small book. Yes, you can do simple
> > poudriere installs, but once you start covering it properly the docs
> > quickly expand. My notes alone are longer than my af3e chapter
> > limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
> > 2018).
> 
> Please include a discussion on how to use poudriere on
> a system with limited resouces (e.g., 10 GB of free
> diskspace and less than 1 GB free memory).  I know
> portmaster works well [1] within an environment with
> only 4 GB free diskspace and 1 GB memory.
> 
> [1] portmaster worked well prior to portmgr's decision
> to displace simple small tools in favor of a sledge
> hammer.

FUD.. portmgr never took any decision like this.
The problem with portmaster (beside some design flows regarding the "not build
in a clean room") is that it is not maintained anymore. (Note that it has never
been maintained by portmgr at all).

What this means is, when some highly needed features such as subpackages and
flavors are coming in it will just break. portmgr is taking that into account at
that is one of the reason we have decided to block the adoption of flavors for
some time to give time to people to catchup and fixup the tools they do
like/use (yes documentation and simple examples are coming soon(c)(tm).

This not only concerns portmaster but also portupgrade, tinderbox and ANY third
party tools that works on the ports tree directly.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: pkg issue after FreeBSD 11 upgrade

[Baptiste Daroussin]

On Wed, Aug 30, 2017 at 10:07:51AM -0300, Cassiano Peixoto wrote:
> Ok I know about HANDLE_RC_SCRIPTS, it's a good approach. But how to deal
> with when I need to restart a service without upgrading? Reaper
> functionnality is a trouble for many administrators who made meta ports to
> manage their servers. I really think it could be a option to be
> enabled/disabled. Can you see this possibility?
> 

Yes I could add an option to disable the reaper functionnality (and will
probably to unblock such use case as soon as I have time to do it.)

However I still think this is not the right idea :) and a better one could be
found

Bapt


signature.asc
Description: PGP signature

Re: pkg issue after FreeBSD 11 upgrade

[Baptiste Daroussin]

On Wed, Aug 30, 2017 at 03:01:30PM +0200, Franco Fichtner wrote:
> Hi Cassiano,
> 
> > On 30. Aug 2017, at 2:55 PM, Cassiano Peixoto  
> > wrote:
> > 
> > Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only.
> 
> It was a later 10.x change as far as I know.
> 
> > Is there some flag to disable it? Or some hack that I could do?
> 
> No.  At OPNsense we use a patch to revert the behaviour.
> 
> https://github.com/opnsense/ports/blob/master/ports-mgmt/pkg/files/patch-libpkg_scripts.c

Why and what is your use case, there is a reason why this code has been added,
and I would like to hear more about use cases so we can try to address them.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: pkg issue after FreeBSD 11 upgrade

[Baptiste Daroussin]

On Wed, Aug 30, 2017 at 09:55:22AM -0300, Cassiano Peixoto wrote:
> Hi Baptiste,
> 
> Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only.

It only worked on FreeBSD 10 prior to 10.2, the reaper functionnality in freebsd
kernel appeared in 10.2
> 
> Cron is just an example, I manage more than 50 FreeBSD servers, and I've
> been using ports for years to update some configs and restart the service
> on all of them. Many times I need to change nginx config, ldap, etc. I just
> need to restart the service.

HANDLE_RC_SCRIPTS=true in your pkg.conf and pkg will automatically restart
anything rc script provide once the package containing it is upgrading.

This is off by default because in many cases it is dangerous (database upgrades,
dovecot like things upgrade etc). But if you know what you are doing it does the
job.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: pkg issue after FreeBSD 11 upgrade

[Baptiste Daroussin]

On Wed, Aug 30, 2017 at 09:00:55AM -0300, Cassiano Peixoto wrote:
> Hi Matthew,
> 
> Sorry back to this subject. But I really need to restart services with a
> port. I'm quite sure there is a bug with pkg and FreeBSD 11.
> 
> I made a simple port to restart cron service:

It is not a bug, it is by design, pkg becomes the reaper of the scripts it runs
and kills everything once the script is executed.

btw if you install crontab in cron.d you do not need to restart the service,
cron will figure out itself and reload what it needed.

Bapt


signature.asc
Description: PGP signature

Re: State of FUSE on FreeBSD

[Baptiste Daroussin]

On Thu, Aug 03, 2017 at 01:38:28PM +0200, Nikolaus Rath wrote:
> Hello,
> 
> I am the upstream maintainer of libfuse. I'd like to refresh / improve
> the FreeBSD support in libfuse. My goal is for libfuse not to require
> any FreeBSD specific patches.
> 
> After taking a look at
> https://github.com/freebsd/freebsd/tree/master/sbin/mount_fusefs,
> https://svn.freebsd.org/ports/head/sysutils/fusefs-libs/, and
> https://github.com/libfuse/libfuse/issues/173, it seems to me that:
> 
> - A lot of upstream code that was actually intended to support FreeBSD
>   is actually patched out when libfuse is installed via ports.
> 
> - The mount.fusefs and fusermount binaries are not installed from
>   libfuse at all, and are instead provided by a "sysutils/fusefs-libs"
>   package(?)
> 
> - Some additional patches are necessary to get libfuse to work.
> 
> 
> Is that correct so far, or am I looking at the wrong place?

Yes it it :)
> 
> 
> If so, my tentative plan would be to:
>  
> - Not build fusermount and mount.fusefs on FreeBSD at all. This would
>   allow getting rid of mount_bsd.c (and the corresponding patch)
>   completely.

It is correct, we don't need those (not that right now the package fusefs-libs
is a bit wrong because it still installs the fusermount manpage beside not
installing the utility itself.)
>   
> - Integrate the helper.c patch upstream using #ifdefs

Correct
> 
> - As far as I can tell, the mount_util.[ch] patch is a no-op that should
>   be dropped anyway.

Correct the patch are leftovers from the time we didn't have mount_fusefs in
base, so they are now "useless" for us.
> 
> 
> Personally, I don't use FreeBSD and I don't have an easy way to test on
> FreeBSD either. So I would appreciate any input.

I can help you testing if you need, do not hesitate to bother me :)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Monday Pick (fwd)

[Baptiste Daroussin]

On Tue, Aug 01, 2017 at 08:09:31AM +1000, Dave Horsfall wrote:
> When is the cocksucker who runs this this list going to implement some
> simple anti-spam provisions?  Or are you one of those idiotic "frea speach"
> spam supporters, so prevalent amongst Americans these days?
> 

We do not tolerate such kind of insulting email on our mailing lists (and
community)!

Bapt


signature.asc
Description: PGP signature

Re: Should a package restart on upgrade itself

[Baptiste Daroussin]

On Tue, Jun 27, 2017 at 06:29:24PM +0200, Matthias Fechner wrote:
> Dear all,
> 
> it is always a pain if pkg upgrade a lot of packages to restart all
> services to make sure update/security fixes are applied to all running
> services.
> 
> Is there an option in pkg that it restart services automatically or is
> it OK if I would add a post-install script to the packages (I maintain)
> that will include a "service foo restart"?
> 
> What is best practice here?
> 
A package self upgrading might cause issues: plugins not yet updated (hi
dovecot), or services requiring an upgrade procedure. So activating a self
restart of the service by default is a bad idea.

service -R command can simplify the procedure for the admin given it restarts
all services already started.

Another option is to activate an option of pkg(8) off by default:
HANDLE_RC_SCRIPTS = true;
in /usr/local/etc/pkg.conf

which will automatically restart the services on upgrade.

In the futur it is planed to move this into a trigger (executed at the end of
the entire upgrade process) which will solve the "dovecot" issue, but not the
one where upgrading requires a procedure.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baptiste Daroussin]

On Thu, Jun 22, 2017 at 10:03:33AM -0400, scratch65...@att.net wrote:
> [Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin
> <b...@freebsd.org> wrote:
> 
> >As usual with such proposal, where do you find the manpower to handle the 
> >number
> >of branches required (the quarterly branches are already hard to maintain, 
> >it is
> >only one branch).
> 
> Please help me out here, Baptiste, because I'm apparently missing
> *something*.   
> 
> Out in industry, if you haven't enough people to do a new
> high-quality release every N months, and you can't get a
> headcount increase, then you cut the release schedule.  Can't do
> 4 releases a year?  Cut back to 2.  Still too many?  Cut back to
> 1.
> 
> The alternatives to cutting the schedule are that (a) people
> begin burning out and quitting, (b) quality drops and your
> customer base begins abandoning you, or (c) both of the above.
> 
> Why don't the same choices apply here?  What am I missing?

We only have 1 quarterly branch at the time :)

The model with one branch per release will bring it to way more with a
maintenance window way larger (actually it is 3 month making the quarterly
relatively easy to maintain)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baptiste Daroussin]

On Thu, Jun 22, 2017 at 02:18:56PM +0200, Baptiste Daroussin wrote:
> On Thu, Jun 22, 2017 at 02:15:02PM +0200, David Demelier wrote:
> > Hello,
> > 
> > Today I've upgraded one of my personal FreeBSD servers. It's running
> > FreeBSD 11.0 for a while.
> > 
> > While I use quarterly ports branches, I usually update my ports tree
> > before installing a new service and I faced some troubles:
> > 
> > www/node was updated from 6.x to 7.x: unfortunately my etherpad
> > instance is not compatible with 7.x. I needed to install www/node6.
> > 
> > devel/mercurial was updated to 4.2: redmine has a small issue making
> > repository browsing unavailable. I temporarily downgraded Mercurial to
> > 4.0.
> > 
> > I think the current process of having rolling-releases packages makes
> > unpredictable upgrades as we have to manually check if the upgrade
> > will be fine or not. When a user installs FreeBSD 11.0 on its system,
> > it probably expects that everything will work fine until a next major
> > upgrade like 12.0. That's why I think we really should implement
> > branches for a specific FreeBSD version.
> > 
> > When FreeBSD 12.0 is released, we should create a ports branch that
> > will contains only fixes (such as security advisories, crash fixes and
> > such). No minor or major upgrades until a new 13.0 version is
> > released. This is the only way to make safe upgrades.
> > 
> > If user think that a software is too old (since we have long delay
> > between major releases) it can still use the default tree at its own
> > risks.
> > 
> > Additional benefits of having a ports tree by version: you don't need
> > to have conditionals in ports Makefiles (how many ports check for
> > FreeBSD version? a lot).
> > 
> > Any comments are appreciated.
> 
> As usual with such proposal, where do you find the manpower to handle the 
> number
> of branches required (the quarterly branches are already hard to maintain, it 
> is
> only one branch).
> 
> What do you do for security fixes: backport to the stable version? who is
> backporting to software not maintained upstream any more in the given branch?
> 
> Bapt

Oh and of course the day you freeze a branch you will have complain about "how
do I get python 3.8 on freebsd 11.0"

Bapt


signature.asc
Description: PGP signature

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baptiste Daroussin]

On Thu, Jun 22, 2017 at 02:15:02PM +0200, David Demelier wrote:
> Hello,
> 
> Today I've upgraded one of my personal FreeBSD servers. It's running
> FreeBSD 11.0 for a while.
> 
> While I use quarterly ports branches, I usually update my ports tree
> before installing a new service and I faced some troubles:
> 
> www/node was updated from 6.x to 7.x: unfortunately my etherpad
> instance is not compatible with 7.x. I needed to install www/node6.
> 
> devel/mercurial was updated to 4.2: redmine has a small issue making
> repository browsing unavailable. I temporarily downgraded Mercurial to
> 4.0.
> 
> I think the current process of having rolling-releases packages makes
> unpredictable upgrades as we have to manually check if the upgrade
> will be fine or not. When a user installs FreeBSD 11.0 on its system,
> it probably expects that everything will work fine until a next major
> upgrade like 12.0. That's why I think we really should implement
> branches for a specific FreeBSD version.
> 
> When FreeBSD 12.0 is released, we should create a ports branch that
> will contains only fixes (such as security advisories, crash fixes and
> such). No minor or major upgrades until a new 13.0 version is
> released. This is the only way to make safe upgrades.
> 
> If user think that a software is too old (since we have long delay
> between major releases) it can still use the default tree at its own
> risks.
> 
> Additional benefits of having a ports tree by version: you don't need
> to have conditionals in ports Makefiles (how many ports check for
> FreeBSD version? a lot).
> 
> Any comments are appreciated.

As usual with such proposal, where do you find the manpower to handle the number
of branches required (the quarterly branches are already hard to maintain, it is
only one branch).

What do you do for security fixes: backport to the stable version? who is
backporting to software not maintained upstream any more in the given branch?

Bapt


signature.asc
Description: PGP signature

Re: Several PostgreSQL versions installed

[Baptiste Daroussin]

On Thu, May 25, 2017 at 09:59:08PM +0200, José García Juanino wrote:
> Hi FreeBSD porters,
> 
> 
> I have been read the following thread
> 
> "Proposal to fix postgresql package maintainance nightmare"
> 
> https://lists.freebsd.org/pipermail/freebsd-ports/2015-July/099842.html
> 
> but I think that, two years later, there is no progress on this matter.
> I am unaware if there is any project that addresses this issue, so my
> apologies if this work is already in progress.

No progress as far as I am aware. except a PoC (early, ugly, unfinished)
https://people.freebsd.org/~bapt/pgsql95.diff

> 
> The goal of the new postgresql port schema should be, in my honest
> opinion:
> 
> * It must allow to install distinct version without ugly hacks as jails,
>   etc. Jails are a overkill to accomplish this task.
> 
> * Each software version must live in a separate directory
> ${LOCALBASE}/pgsql/X.Y:
> 
> /usr/local/pgsql/9.2
> /usr/local/pgsql/9.4
> /usr/local/pgsql/9.6
> 
>   and so on.

Yes this is what I was proposing
> 
> 
> * It is not necessary to provide an installed version as the default.
>   For example, if we need 9.5 and 9.6 versions installed, both are
>   equally valid, and we do not need the standard postgresql binaries
>   (pg_dump, psql, pg_ctl, etc) installed in the standard PATH as
>   /bin:/usr/bin:/usr/local/bin.  Those binaries are located under
>   /usr/local/pgsql/X.Y/bin directory, and everyone can configure the
>   shell environment variable PATH to add the previous directory:
>   PATH=$PATH:/usr/local/pgsql/X.Y/bin. Please do not make symlinks from
>   /usr/local/bin/pg_some to specific /usr/local/pgsql/X.Y/bin/pg_some,
>   it has very little advantages and a lot of drawbacks. Under a prompt
>   command line, a skilled database administrator always need to know
>   what command version is executing and do not need an standard location
>   as /usr/local/bin.

For a database administrator yes playing with the path is enough, but for a new
comer installing pgsql for his blog this would be complicated
> 
> 
> * The rc and the periodic script must be versioned also:
> 
> /usr/local/etc/rc.d/postgresql9.6
> /usr/local/etc/rc.d/postgresql5.6
> 
yes

One important thing is there is a need for a small modification for the
postgresql build system: add a proper RUNPATH for the binaries to always find
the right libpq

> 
> 
> Best regards, and thanks to the volunteers for make FreeBSD an great
> operating system!
> 

Note that the same should apply to mysql/mariadb/etc

bapt


signature.asc
Description: PGP signature

Re: diff and submissions

[Baptiste Daroussin]

On Fri, May 05, 2017 at 12:27:13PM +0200, Mathieu Arnold wrote:
> Le 05/05/2017 à 12:20, Baptiste Daroussin a écrit :
> > On Fri, May 05, 2017 at 12:17:06PM +0200, Mathieu Arnold wrote:
> >> Le 05/05/2017 à 08:16, Franco Fichtner a écrit :
> >>>> On 4. May 2017, at 10:20 AM, Mathieu Arnold <m...@freebsd.org> wrote:
> >>>>
> >>>> If you went as far as being able to create a pull request, you can do a
> >>>> git show HEAD or git diff origin/trunk...HEAD and submit that in the
> >>>> FreeBSD PR as well.
> >>> It's pretty easy to extract the diff from a PR on GitHub, just append
> >>> ".diff", and ".patch" works too, but gives the full git commit history:
> >>>
> >>> https://github.com/freebsd/freebsd-ports/pull/62.diff
> >> Yes, I am aware of that, the problem with github pull requests is that
> >> they are outside of the FreeBSD bug report process, they do not get
> >> assigned to maintainers, nobody notices them, they just stay there, and
> >> get obsolete.
> >> There have been 61 before, yes, I closed a lot because they were
> >> obsolete because it is outside of our process and nobody noticed them,
> >> and for the rest either asked the submitter to open a PR on our
> >> bugzilla, or opened one myself.
> >>
> > I made a script which is a few lines of shell that converts pull requests to
> > phabricator reviews automatically.
> >
> > I have handed it to some of the phabricator admins, I hope it will be 
> > progress
> > soon.
> 
> 
> Please, do not do that.
> 
> Phabricator is for code review, not bug reports.  It all ends up in our
> repository, but Phabricator does not have any maintainer notification
> like Bugzilla has.
> robak@ has a script that does pull-request -> bugzilla, and it has been
> waiting for months for someone with access to do something about it.
> 

Pull request are for code submissions and phabricator is the equivalent for that

Bapt


signature.asc
Description: PGP signature

Re: diff and submissions

[Baptiste Daroussin]

On Fri, May 05, 2017 at 12:17:06PM +0200, Mathieu Arnold wrote:
> Le 05/05/2017 à 08:16, Franco Fichtner a écrit :
> >> On 4. May 2017, at 10:20 AM, Mathieu Arnold  wrote:
> >>
> >> If you went as far as being able to create a pull request, you can do a
> >> git show HEAD or git diff origin/trunk...HEAD and submit that in the
> >> FreeBSD PR as well.
> > It's pretty easy to extract the diff from a PR on GitHub, just append
> > ".diff", and ".patch" works too, but gives the full git commit history:
> >
> > https://github.com/freebsd/freebsd-ports/pull/62.diff
> 
> Yes, I am aware of that, the problem with github pull requests is that
> they are outside of the FreeBSD bug report process, they do not get
> assigned to maintainers, nobody notices them, they just stay there, and
> get obsolete.
> There have been 61 before, yes, I closed a lot because they were
> obsolete because it is outside of our process and nobody noticed them,
> and for the rest either asked the submitter to open a PR on our
> bugzilla, or opened one myself.
> 

I made a script which is a few lines of shell that converts pull requests to
phabricator reviews automatically.

I have handed it to some of the phabricator admins, I hope it will be progress
soon.

Bapt


signature.asc
Description: PGP signature

Re: pkg and packages

[Baptiste Daroussin]

On Thu, May 04, 2017 at 08:09:47AM -0400, scratch65...@att.net wrote:
> On Wed, 3 May 2017 16:53:41 +0100, Matthew Seaman
>  wrote:
> 
> >>> Trying to install the desktop package, I discovered that it's
> >>> bundled with at least 2 unrelated pieces of software:  Thunar,
> >>> and samba44.  That bothered me, but I needed the desktop.
> >
> >'Bundling' isn't the right term -- Thunar and samba44 are /dependencies/
> >of the xfce4-desktop.  That is: other packages that need to be installed
> >before the package in question will work.  Sorting out dependency trees
> >like this is much of what pkg(8) exists for.
> 
> I can't imagine what code could possibly be in thunar and samba
> that the xfce desktop would need, particularly since the desktop
> is very simple, and also because I've never got samba
> functionality for free after installing xfce which if you're
> right I should have done.  But I'll check on that, and report
> back.  
> 
> That kind of tight coupling at the macro level *is* a very
> serious problem for the ports system, though.  It's strangling
> it.
> 
> How many ports just build, first go?  Are there *any*?  I suspect
> not.  And yet the maintainers presumably thought they would.
> 
> I stopped trying to build ports because I could never get a make
> to run to completion.  There was always at least one dependency
> that (a) couldn't be found at all, (b) was the wrong version, or
> (c) failed compilation.  That didn't happen when I was writing
> stuff under sco or sys v.
> 
> It shouldn't happen with our ports system, either, because it
> completely prevents code freeze and stability, a basic
> requirement for high-quality software.   The stuff being fetched
> from Timbuktu or somebody's cat's litter box should be cleaned
> up, built into a library, and be fetched from there subsequently.
> There should never be a dependency on code that the ports project
> doesn't control.  
> 
> 
> >The thing that seems to trip most people up is thinking they can
> >substitute some other package instead of the exact dependency listed in
> >the package metadata.  This is not an unreasonable request, especially
> >when you know your alternate package does exactly the same thing as the
> >one you want to replace.  Unfortunately it just doesn't work right now,
> >and it would take quite a lot of disruptive change in the ports tree and
> >to pkg(8) itself to make that happen.
> 
> You call it "disruptive" change, but from  here it looks exactly
> like *healthy*, *professional* change.  Really.

There is no garanty the libsmb.so.X provided by samba44 is binary compatible
with the one from samba46 this is why there is a strong dependency here.

For more defaly look at my answer here
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219036

Bapt


signature.asc
Description: PGP signature

Re: manpath change for ports ?

[Baptiste Daroussin]

On Fri, Apr 21, 2017 at 12:18:53AM +0200, Mathieu Arnold wrote:
> Le 21/04/2017 à 00:16, Baptiste Daroussin a écrit :
> > On Fri, Apr 21, 2017 at 12:13:52AM +0200, Mathieu Arnold wrote:
> >> Le 20/04/2017 à 23:21, Baptiste Daroussin a écrit :
> >>> On Thu, Apr 20, 2017 at 11:18:14PM +0200, Koop Mast wrote:
> >>>> On Tue, 2017-03-07 at 00:56 +0100, Baptiste Daroussin wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> I would like to propose a change in the localbase hier for ports
> >>>>>
> >>>>> I think we should add /usr/local/share/man in the manpath along with
> >>>>> at first
> >>>>> and maybe instead of in long term.
> >>>>>
> >>>>> The reason is:
> >>>>> - /usr/local/share/man seems more consistent to me with base which
> >>>>> have:
> >>>>>   /usr/share/man
> >>>>> - It will remove lots of patches from the ports tree where were we
> >>>>> need to patch
> >>>>>   upstream build system to install in a non usual path.
> >>>>>
> >>>>> My proposal is to add to the manpath /usr/local/share/man in default
> >>>>> man(1)
> >>>>> command in FreeBSD 12 (MFCed to 11-STABLE)
> >>>>>
> >>>>> and either provide an errata for 11.0/10.3 or a
> >>>>> /usr/local/etc/man.d/something.conf via a port or something like that
> >>>>> for those
> >>>>> two, what do you think?
> >>>>>
> >>>>> For the same reason I would like to allow porters to stop patching
> >>>>> (with pathfix
> >>>>> or anything else) the path for pkgconfig files and allow
> >>>>> /usr/local/lib/pkgconfig along with the current
> >>>>> /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
> >>>>>
> >>>>> Which will also remove tons of hacks from the ports tree.
> >>>>>
> >>>>> What do you think?
> >>>>>
> >>>>> Best regards,
> >>>>> Bapt
> >>>> Hello,
> >>>>
> >>>> I recently committed the USES for the meson build system to ports. This
> >>>> USES configures the meson build system with some default variables
> >>>> which includes the location of the man pages. This setting is just a
> >>>> flag to the meson command so it easy to change.
> >>>>
> >>>> Meson also handles the generation and installation of pkg-config files
> >>>> that a port wants. The problem is that this is handled by the script
> >>>> itself and there is no way to configure it, so we need to hack the
> >>>> meson port to change it from lib/pkg-config to libdata/pkg-config like
> >>>> we currently are using. (1) Or add a hack to meson.mk to move the pkg-
> >>>> config to the right location (evil++ imho).
> >>>>
> >>>> My point I want to make is that currently there is only 1 port build
> >>>> via the meson system (graphics/graphene). Should we change man/pkg-
> >>>> config file locations now, it very easy. If we want to change them
> >>>> later we will need to mass bump every meson build port. It is important
> >>>> to note that GStreamer and GNOME are moving over to using meson instead
> >>>> of autotools and that Wayland, Xorg en Mesa are exploring want is
> >>>> needed to make the switch. So I think it important that the decision
> >>>> what to do is done now and that we stick with it.
> >>>>
> >>>> Reading the rest of the thread it seems nobody is really against the
> >>>> proposed change of man and pkg-config path's. So how does one submit a
> >>>> policy change like this? I'm also not sure I'm the right person to push
> >>>> this, I just got back from a break and I don't want to really deal with
> >>>> something super high profile right away.
> >>>>
> >>>> -Koop
> >>>>
> >>>> (1) I would like to see lib/pkg-config back in the search path of
> >>>> pkgconf since that means I don't have to do a crash course python
> >>>> programming.
> >>> Would be nice is portmgr can step on this, let's reduce this discussion 
> >>> for now
> >>> on pkgconf.
> >>
> >> I am waiting on an exp-run to fix this once and for all.
> >>
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218067
> >>
> >> When that is committed, anything can be added to the path pkgconfig
> >> searches, ports will always install it in the right place.
> >>
> > Sorry but why? why not moving libdata/pkgconfig to lib/pkgconfig? what is 
> > the
> > rationale?
> Because a lot of build software know that on FreeBSD, the .pc file go in
> libdata/pkgconfig. If we move to some other place, we'll have a
> USES=pathfixmore for the next 25 years until everyone understands we
> moved it some place else.
> 
ok a point for you there :)

Bapt


signature.asc
Description: PGP signature

Re: manpath change for ports ?

[Baptiste Daroussin]

On Fri, Apr 21, 2017 at 12:13:52AM +0200, Mathieu Arnold wrote:
> Le 20/04/2017 à 23:21, Baptiste Daroussin a écrit :
> > On Thu, Apr 20, 2017 at 11:18:14PM +0200, Koop Mast wrote:
> >> On Tue, 2017-03-07 at 00:56 +0100, Baptiste Daroussin wrote:
> >>> Hi all,
> >>>
> >>> I would like to propose a change in the localbase hier for ports
> >>>
> >>> I think we should add /usr/local/share/man in the manpath along with
> >>> at first
> >>> and maybe instead of in long term.
> >>>
> >>> The reason is:
> >>> - /usr/local/share/man seems more consistent to me with base which
> >>> have:
> >>>   /usr/share/man
> >>> - It will remove lots of patches from the ports tree where were we
> >>> need to patch
> >>>   upstream build system to install in a non usual path.
> >>>
> >>> My proposal is to add to the manpath /usr/local/share/man in default
> >>> man(1)
> >>> command in FreeBSD 12 (MFCed to 11-STABLE)
> >>>
> >>> and either provide an errata for 11.0/10.3 or a
> >>> /usr/local/etc/man.d/something.conf via a port or something like that
> >>> for those
> >>> two, what do you think?
> >>>
> >>> For the same reason I would like to allow porters to stop patching
> >>> (with pathfix
> >>> or anything else) the path for pkgconfig files and allow
> >>> /usr/local/lib/pkgconfig along with the current
> >>> /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
> >>>
> >>> Which will also remove tons of hacks from the ports tree.
> >>>
> >>> What do you think?
> >>>
> >>> Best regards,
> >>> Bapt
> >> Hello,
> >>
> >> I recently committed the USES for the meson build system to ports. This
> >> USES configures the meson build system with some default variables
> >> which includes the location of the man pages. This setting is just a
> >> flag to the meson command so it easy to change.
> >>
> >> Meson also handles the generation and installation of pkg-config files
> >> that a port wants. The problem is that this is handled by the script
> >> itself and there is no way to configure it, so we need to hack the
> >> meson port to change it from lib/pkg-config to libdata/pkg-config like
> >> we currently are using. (1) Or add a hack to meson.mk to move the pkg-
> >> config to the right location (evil++ imho).
> >>
> >> My point I want to make is that currently there is only 1 port build
> >> via the meson system (graphics/graphene). Should we change man/pkg-
> >> config file locations now, it very easy. If we want to change them
> >> later we will need to mass bump every meson build port. It is important
> >> to note that GStreamer and GNOME are moving over to using meson instead
> >> of autotools and that Wayland, Xorg en Mesa are exploring want is
> >> needed to make the switch. So I think it important that the decision
> >> what to do is done now and that we stick with it.
> >>
> >> Reading the rest of the thread it seems nobody is really against the
> >> proposed change of man and pkg-config path's. So how does one submit a
> >> policy change like this? I'm also not sure I'm the right person to push
> >> this, I just got back from a break and I don't want to really deal with
> >> something super high profile right away.
> >>
> >> -Koop
> >>
> >> (1) I would like to see lib/pkg-config back in the search path of
> >> pkgconf since that means I don't have to do a crash course python
> >> programming.
> > Would be nice is portmgr can step on this, let's reduce this discussion for 
> > now
> > on pkgconf.
> 
> 
> I am waiting on an exp-run to fix this once and for all.
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218067
> 
> When that is committed, anything can be added to the path pkgconfig
> searches, ports will always install it in the right place.
> 
Sorry but why? why not moving libdata/pkgconfig to lib/pkgconfig? what is the
rationale?

Bapt


signature.asc
Description: PGP signature