Re: I thought "pkg updating" would alert me about python...?

[Ronald Klop]

Van: Tatsuki Makino 
Datum: 2 mei 2021 22:36
Aan: Ronald Klop , freebsd-ports@freebsd.org
Onderwerp: Re: I thought "pkg updating" would alert me about python...?




Ronald Klop wrote on 2021/05/03 05:14:
> The UPDATING entry should have said something like "users of lang/python*" to 
work.

The behavior of this is strange.
I have the following python* in my environment.
python, python27, python3, python37 and python38

AFFECTS: users of python : not match
AFFECTS: users of pytho? : match
AFFECTS: users of python3 : not match
AFFECTS: users of python* : match
AFFECTS: users of python3[7] : match

package names are also comparable.
Does it not pattern match if the pattern match symbol ?, [] or * is not 
included?

Regards.








If I read the pkg source correctly it uses regex with some glob-like 
preparation like converting * to 
.*.https://github.com/freebsd/pkg/blob/62302ab4b4d69528e155ea7b68f058a05d6dffdd/src/updating.c#L71And
 it indeed checks if the word contains regex characters. If not it compares 
with strcmp.
strpbrk(words[i],"^$*|?") == NULL



What is remarkable is that it compares to "origin". I think origin is the full portname 
"lang/python". The regex match also matches a substring of origin.


This would explain why pytho? matches, but python didn't.


NB: this is by  looking at the C code for a minute with my rusty C skills. I 
might have overlooked something. 

Regards,Ronald
___
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: I thought "pkg updating" would alert me about python...?

[Tatsuki Makino]

Ronald Klop wrote on 2021/05/03 05:14:
> The UPDATING entry should have said something like "users of lang/python*" to 
> work.

The behavior of this is strange.
I have the following python* in my environment.
python, python27, python3, python37 and python38

AFFECTS: users of python : not match
AFFECTS: users of pytho? : match
AFFECTS: users of python3 : not match
AFFECTS: users of python* : match
AFFECTS: users of python3[7] : match

package names are also comparable.
Does it not pattern match if the pattern match symbol ?, [] or * is not 
included?

Regards.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: I thought "pkg updating" would alert me about python...?

[Ronald Klop]

On 5/2/21 4:20 PM, David Wolfskill wrote:

I just re-verified the behavior, so -- even though I have already
started taking evasive action (updating python), I figured it may be of
use to show what I'm seeing; maybe I'm confused:

Local ports tree is updated; previous ports update was a week ago.  I
happen to know that there's an UPDATING entry:

lgld-dhw(12.2-S)[4] tail +16 /usr/ports/UPDATING | head -5
20210425:
   AFFECTS: users of python
   AUTHOR: k...@freebsd.org

   The default version of python3 and python was switched to 3.8.


And that this machine should be affected:

lgld-dhw(12.2-S)[5] pkg info -o python\*
python27-2.7.18_1  lang/python27
python36-3.6.13lang/python36
python38-3.8.9 lang/python38


[As noted above, I had already started evasive action.]

But "pkg updating" is not actually showing the above entry:

lgld-dhw(12.2-S)[6] pkg updating -d 20210424
lgld-dhw(12.2-S)[7] echo $?
0


Am I alone in expecting "pkg updating" to have displayed the 20210425
entry?

(There was an issue a while back, where "pkg updating" was not showing
"glob" entries, but that has since been addressed.)

This is on a machine running stable/12:

lgld-dhw(12.2-S)[8] uname -a
FreeBSD lgld-dhw.corp.example.com 12.2-STABLE FreeBSD 12.2-STABLE #21 
stable/12-n233048-23a3c3d97d72: Sun May  2 04:43:57 PDT 2021 
r...@lgld-dhw.corp.example.com:/common/S2/obj/common/S2/src/amd64.amd64/sys/GENERIC
  amd64
lgld-dhw(12.2-S)[9] pkg -v
1.16.3

Thanks.

Peace,
david




The UPDATING file says "users of python" while the pkg/port name is python37. 
So that does not match. It does match for humans but not for computers. :-)
The UPDATING entry should have said something like "users of lang/python*" to 
work.

Regards,
Ronald.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

I thought "pkg updating" would alert me about python...?

[David Wolfskill]

I just re-verified the behavior, so -- even though I have already
started taking evasive action (updating python), I figured it may be of
use to show what I'm seeing; maybe I'm confused:

Local ports tree is updated; previous ports update was a week ago.  I
happen to know that there's an UPDATING entry:

lgld-dhw(12.2-S)[4] tail +16 /usr/ports/UPDATING | head -5
20210425:
  AFFECTS: users of python
  AUTHOR: k...@freebsd.org

  The default version of python3 and python was switched to 3.8.


And that this machine should be affected:

lgld-dhw(12.2-S)[5] pkg info -o python\*
python27-2.7.18_1  lang/python27
python36-3.6.13lang/python36
python38-3.8.9 lang/python38


[As noted above, I had already started evasive action.]

But "pkg updating" is not actually showing the above entry:

lgld-dhw(12.2-S)[6] pkg updating -d 20210424
lgld-dhw(12.2-S)[7] echo $?
0


Am I alone in expecting "pkg updating" to have displayed the 20210425
entry?

(There was an issue a while back, where "pkg updating" was not showing
"glob" entries, but that has since been addressed.)

This is on a machine running stable/12:

lgld-dhw(12.2-S)[8] uname -a
FreeBSD lgld-dhw.corp.example.com 12.2-STABLE FreeBSD 12.2-STABLE #21 
stable/12-n233048-23a3c3d97d72: Sun May  2 04:43:57 PDT 2021 
r...@lgld-dhw.corp.example.com:/common/S2/obj/common/S2/src/amd64.amd64/sys/GENERIC
  amd64
lgld-dhw(12.2-S)[9] pkg -v
1.16.3

Thanks.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"some of the terminology that was used, like 'hugs and kisses,' and 'very
fine people,' is like very different from what I experienced and what my
co-workers experienced on the 6th." - Michael Fanone, DC Metro Police Officer

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Changing daemon user, dir ownership and updating packages

[Gleb Popov]

On Mon, Apr 26, 2021 at 10:13 PM Dewayne Geraghty <
dewa...@heuristicsystems.com.au> wrote:

> On 26/04/2021 6:03 pm, Stefan Bethke wrote:
> > But that still leaves pkg updating the ownership/mode of existing
> directories as a surprise on updating a package. I think the "right" thing
> here would be a kind of three-way merge between changes an updated package
> brings in vs. changes the user has made on their system.
>
> Sometimes the right thing isn't easy ;)
>
> There are some cases where I explicitly assign ownership and more
> restrictive modes to installed ports.  Would "pkg add -I" prevent file
> ownership/mode changes or just prevent the execution of installation
> scripts... (hint for a flag to prevent file mode/ownership changes on
> existing systems)
>
> I suspect Gleb's paradigm of a separate file to explicitly control file
> attributes (after upgrades) is reasonable, but this is problematic and
> negates the value of a packaging system.
>

It only shifts the task of organizing runtime files/dirs to the software
upstream, which is a right thing, IMO. The same way we use automatic
pkg-plist generation for Python easyinstall-based ports.

That tmpfiles.d thing seems to be an established way to do that sort of
stuff in the Linux world, so I believe we should get on the train too.
___
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: Changing daemon user, dir ownership and updating packages

[Dewayne Geraghty]

On 26/04/2021 6:03 pm, Stefan Bethke wrote:
> But that still leaves pkg updating the ownership/mode of existing directories 
> as a surprise on updating a package. I think the "right" thing here would be 
> a kind of three-way merge between changes an updated package brings in vs. 
> changes the user has made on their system. 

Sometimes the right thing isn't easy ;)

There are some cases where I explicitly assign ownership and more
restrictive modes to installed ports.  Would "pkg add -I" prevent file
ownership/mode changes or just prevent the execution of installation
scripts... (hint for a flag to prevent file mode/ownership changes on
existing systems)

I suspect Gleb's paradigm of a separate file to explicitly control file
attributes (after upgrades) is reasonable, but this is problematic and
negates the value of a packaging system.
___
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: Changing daemon user, dir ownership and updating packages

[Gleb Popov]

On Mon, Apr 26, 2021 at 11:03 AM Stefan Bethke  wrote:

> Am 13.04.2021 um 10:24 schrieb Stefan Bethke :
> >
> > As the maintainer, I've received this bug report:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255009
> >
> > If you'd like to run the daemon under a user different from the default
> git, you also need to change the ownership of the working directories,
> especially /var/*/gitea.
> >
> > The expectation is that upgrading the package will not change the
> ownership of already existing directories. When installing a newer version
> of the package, pkg appears to reset the ownership to those specified in
> the package.
> >
> > The pkg-plist has this:
> > @owner git
> > @group git
> > @dir /var/db/gitea
> > @dir /var/log/gitea
> > @dir /var/run/gitea
> >
> > I believe this to be best practice. Is there a better way to have pkg
> create these dirs if they're missing, but not touch them if they are there
> already?
>
> Adam has suggested a couple of approaches, but what I would really like is
> a common, documented way for ports to handle this situation.
>
> Updating ownership and mode of entries in the rc script automatically
> feels wrong to me, especially if it's a custom one-off for a single port.
> Kinda creating a POLA violation.
>
> I think as a general approach, checking that directories and files that
> the port knows will need to be writable for compatible access rights might
> be the safe choice.
>
> But that still leaves pkg updating the ownership/mode of existing
> directories as a surprise on updating a package. I think the "right" thing
> here would be a kind of three-way merge between changes an updated package
> brings in vs. changes the user has made on their system. That sound
> complicated to get right.
>
>
> Stefan
>
> --
> Stefan BethkeFon +49 151 14070811
>

I believe the general approach is what is called tmpfiles.d in systemd. It
is a startup script that reads configuration files installed by 3rd-party
software and creates file system hierarchies according to them. This is an
example of such configuration file:
https://github.com/Xpra-org/xpra/blob/master/fs/lib/tmpfiles.d/xpra.conf

Maybe we need to grow our own implementation of tmpfiles.d.
___
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: Changing daemon user, dir ownership and updating packages

[Stefan Bethke]

Am 13.04.2021 um 10:24 schrieb Stefan Bethke :
> 
> As the maintainer, I've received this bug report:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255009
> 
> If you'd like to run the daemon under a user different from the default git, 
> you also need to change the ownership of the working directories, especially 
> /var/*/gitea.
> 
> The expectation is that upgrading the package will not change the ownership 
> of already existing directories. When installing a newer version of the 
> package, pkg appears to reset the ownership to those specified in the package.
> 
> The pkg-plist has this:
> @owner git
> @group git
> @dir /var/db/gitea
> @dir /var/log/gitea
> @dir /var/run/gitea
> 
> I believe this to be best practice. Is there a better way to have pkg create 
> these dirs if they're missing, but not touch them if they are there already?

Adam has suggested a couple of approaches, but what I would really like is a 
common, documented way for ports to handle this situation.

Updating ownership and mode of entries in the rc script automatically feels 
wrong to me, especially if it's a custom one-off for a single port. Kinda 
creating a POLA violation.

I think as a general approach, checking that directories and files that the 
port knows will need to be writable for compatible access rights might be the 
safe choice.

But that still leaves pkg updating the ownership/mode of existing directories 
as a surprise on updating a package. I think the "right" thing here would be a 
kind of three-way merge between changes an updated package brings in vs. 
changes the user has made on their system. That sound complicated to get right.


Stefan

--
Stefan BethkeFon +49 151 14070811



signature.asc
Description: Message signed with OpenPGP

Changing daemon user, dir ownership and updating packages

[Stefan Bethke]

As the maintainer, I've received this bug report:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255009

If you'd like to run the daemon under a user different from the default git, 
you also need to change the ownership of the working directories, especially 
/var/*/gitea.

The expectation is that upgrading the package will not change the ownership of 
already existing directories. When installing a newer version of the package, 
pkg appears to reset the ownership to those specified in the package.

The pkg-plist has this:
@owner git
@group git
@dir /var/db/gitea
@dir /var/log/gitea
@dir /var/run/gitea

I believe this to be best practice. Is there a better way to have pkg create 
these dirs if they're missing, but not touch them if they are there already?


Stefan

--
Stefan BethkeFon +49 151 14070811



signature.asc
Description: Message signed with OpenPGP

Re: Updating poudriere to use gitup

[Felix Palmen]

* Carmel  [20210407 06:03]:
> Is there a 'How-to" posted on how to convert poudriere to use 'gitup' or
> even "git" if necessary?

Poudriere doesn't support gitup (so far?)

Your options are to use methods git or null, see poudriere-ports(8). To
use gitup with poudriere, configure your ports with method null and edit
gitup.conf to have `target_directory` point to your ports tree used by
poudriere, then you can update it with `gitup ports`.

-- 
 Dipl.-Inform. Felix Palmen ,.//..
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key} http://palmen-it.de/pub.txt   //   """
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A


signature.asc
Description: PGP signature

Re: Updating poudriere to use gitup

[Kurt Jaeger]

Hi!

> With the change in the FreeBSD ports system, I have started to use
> "gitup". I have this working fine. Unfortunately, I cannot figure out
> how to get poudriere, version 3.3.99.20210303_1 to use 'gitup' too. It
> insists on using 'portsnap'. This is on a FreeBSD 11.4-p9 system.
> 
> Is there a 'How-to" posted on how to convert poudriere to use 'gitup' or
> even "git" if necessary?

I had a portsnap ports tree 'default' in poudriere and did this to
switch to git:

  poudriere ports -d -p default
  poudriere ports -c -U https://git.freebsd.org/ports.git -m git -B main

-- 
p...@opsec.eu+49 171 3101372Now what ?
___
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"

Updating poudriere to use gitup

[Carmel]

With the change in the FreeBSD ports system, I have started to use
"gitup". I have this working fine. Unfortunately, I cannot figure out
how to get poudriere, version 3.3.99.20210303_1 to use 'gitup' too. It
insists on using 'portsnap'. This is on a FreeBSD 11.4-p9 system.

Is there a 'How-to" posted on how to convert poudriere to use 'gitup' or
even "git" if necessary?

Thanks!


pgpBc6RGqYjQr.pgp
Description: OpenPGP digital signature

Re: Problems with updating a port due to top directory in tarball

[Dan Mahoney (Gushi)]

On Sat, 6 Mar 2021, Kevin Oberman wrote:


On Wed, Mar 3, 2021 at 10:15 PM Hiroo Ono  wrote:



On 2021年3月4日木曜日 9時00分32秒 JST, Kevin Oberman wrote:

I'm trying to update a port I maintain. Since I last updated, it moved

from

ISC to github and it uses unusual naming conventions.

The distfile is "irrtoolset/archive/release-5.1.3.tar.gz". I can work
around this with a DIST_SUBDIR and DISTNAME, but when the extract takes
place,  the top directory in the tarball is "irrtoolset-release-5.1.3".
Since this is not expected, patch fails.


If it is same as what is tagged as "release-5.1.3",

DISTVERSIONPREFIX=  release-
DISTVERSION=5.1.3
USE_GITHUB= yes
GH_ACCOUNT= irrtoolset
GH_PROJECT= irrtoolset

should work.
cf.

https://docs.freebsd.org/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html#makefile-master_sites-github-description

Thanks you very much! The update to the port has been submitted and is

awaiting a committer. Looking at the Porter's Handbook, I now understand
how it works, but it would have taken a VERY long time to figure it all out
without your help! (Might have taken until the heat death of the universe.)


I also was hitting some issues with this for opendmarc, which recently 
moved from Sourceforge to Github.  Well, moved a while ago but put out its 
first github-exclusive release recently.


For some of the process, portsfiles just plain didn't try to fetch.  Even 
when I copied the relevant variables verbatim from another port.


Despite having the porter's handbook open lots, there were many things I 
had to just go read the files in /usr/ports/Mk to figure out.


There could definitely be more recipes.  One example: how to correctly 
handle a port that uses an RPM.  Or multiple RPMs.


--

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.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"

Re: Problems with updating a port due to top directory in tarball

[Kevin Oberman]

On Wed, Mar 3, 2021 at 10:15 PM Hiroo Ono  wrote:

>
> On 2021年3月4日木曜日 9時00分32秒 JST, Kevin Oberman wrote:
> > I'm trying to update a port I maintain. Since I last updated, it moved
> from
> > ISC to github and it uses unusual naming conventions.
> >
> > The distfile is "irrtoolset/archive/release-5.1.3.tar.gz". I can work
> > around this with a DIST_SUBDIR and DISTNAME, but when the extract takes
> > place,  the top directory in the tarball is "irrtoolset-release-5.1.3".
> > Since this is not expected, patch fails.
>
> If it is same as what is tagged as "release-5.1.3",
>
> DISTVERSIONPREFIX=  release-
> DISTVERSION=5.1.3
> USE_GITHUB= yes
> GH_ACCOUNT= irrtoolset
> GH_PROJECT= irrtoolset
>
> should work.
> cf.
>
> https://docs.freebsd.org/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html#makefile-master_sites-github-description
>
> Thanks you very much! The update to the port has been submitted and is
awaiting a committer. Looking at the Porter's Handbook, I now understand
how it works, but it would have taken a VERY long time to figure it all out
without your help! (Might have taken until the heat death of the universe.)
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: Problems with updating a port due to top directory in tarball

[Hiroo Ono]

On 2021年3月4日木曜日 9時00分32秒 JST, Kevin Oberman wrote:

I'm trying to update a port I maintain. Since I last updated, it moved from
ISC to github and it uses unusual naming conventions.

The distfile is "irrtoolset/archive/release-5.1.3.tar.gz". I can work
around this with a DIST_SUBDIR and DISTNAME, but when the extract takes
place,  the top directory in the tarball is "irrtoolset-release-5.1.3".
Since this is not expected, patch fails.


If it is same as what is tagged as "release-5.1.3",

DISTVERSIONPREFIX=  release-
DISTVERSION=5.1.3
USE_GITHUB= yes
GH_ACCOUNT= irrtoolset
GH_PROJECT= irrtoolset

should work.
cf. 
https://docs.freebsd.org/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html#makefile-master_sites-github-description


___
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: Problems with updating a port due to top directory in tarball

[Hiroo Ono]

I am resending this mail because I put the wrong From for the first time.

On 2021年3月4日木曜日 9時00分32秒 JST, Kevin Oberman wrote:

I'm trying to update a port I maintain. Since I last updated, it moved from
ISC to github and it uses unusual naming conventions.

The distfile is "irrtoolset/archive/release-5.1.3.tar.gz". I can work
around this with a DIST_SUBDIR and DISTNAME, but when the extract takes
place,  the top directory in the tarball is "irrtoolset-release-5.1.3".
Since this is not expected, patch fails.


If it is same as what is tagged as "release-5.1.3",

DISTVERSIONPREFIX=  release-
DISTVERSION=5.1.3
USE_GITHUB= yes
GH_ACCOUNT= irrtoolset
GH_PROJECT= irrtoolset

should work.
cf. 
https://docs.freebsd.org/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html#makefile-master_sites-github-description


___
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: Problems with updating a port due to top directory in tarball

[Kevin Oberman]

Thanks to both of you. Looks like I can continue working on the port, now!
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: Problems with updating a port due to top directory in tarball

[Jan Beich]

Kevin Oberman  writes:

> I'm trying to update a port I maintain. Since I last updated, it moved from
> ISC to github and it uses unusual naming conventions.
>
> The distfile is "irrtoolset/archive/release-5.1.3.tar.gz". I can work
> around this with a DIST_SUBDIR and DISTNAME, but when the extract takes
> place,  the top directory in the tarball is "irrtoolset-release-5.1.3".
> Since this is not expected, patch fails.

Try DISTVERSIONPREFIX=release- like devel/googletest. USE_GITHUB renames
distfile via ?dummy=/ in MASTER_SITES, so you don't need to manually set
DIST_SUBDIR/DISTNAME.

$ make fetch-urlall-list MASTER_SITE_BACKUP=
https://codeload.github.com/irrtoolset/irrtoolset/tar.gz/release-5.1.3?dummy=/irrtoolset-irrtoolset-release-5.1.3_GH0.tar.gz
___
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: Problems with updating a port due to top directory in tarball

[Pau Amma]

On 2021-03-04 00:00, Kevin Oberman wrote:
I'm trying to update a port I maintain. Since I last updated, it moved 
from

ISC to github and it uses unusual naming conventions.

The distfile is "irrtoolset/archive/release-5.1.3.tar.gz". I can work
around this with a DIST_SUBDIR and DISTNAME, but when the extract takes
place,  the top directory in the tarball is "irrtoolset-release-5.1.3".
Since this is not expected, patch fails.

Is there a way to specify the name of the restore directory? Or to 
rename

it after the extract phase?


I'd use the post-extract target, but maybe there's a better way.


Since loading the "Porter's Handbook" as a
single file seems to not be an option any longer, it is harder to 
search
through the whole thing, I may have missed an simple way to deal with 
this.


Have you tried https://docs.freebsd.org/en/books/porters-handbook/ ? It 
loads as a single file for me.

___
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"

Problems with updating a port due to top directory in tarball

[Kevin Oberman]

I'm trying to update a port I maintain. Since I last updated, it moved from
ISC to github and it uses unusual naming conventions.

The distfile is "irrtoolset/archive/release-5.1.3.tar.gz". I can work
around this with a DIST_SUBDIR and DISTNAME, but when the extract takes
place,  the top directory in the tarball is "irrtoolset-release-5.1.3".
Since this is not expected, patch fails.

Is there a way to specify the name of the restore directory? Or to rename
it after the extract phase? Since loading the "Porter's Handbook" as a
single file seems to not be an option any longer, it is harder to search
through the whole thing, I may have missed an simple way to deal with this.

Thanks,
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: Updating emulators/i386-wine-devel but get a runtime error

[Neel Chauhan]

Nevermind, it was that WINEDLLPATH was missing.

-Neel

On 2021-02-23 13:01, Neel Chauhan wrote:

Hi freebsd-ports@

I recently adopted emulators/i386-wine-devel and am attempting to
update it to 6.2 along with adding 14.0 support.

Phabricator URL: https://reviews.freebsd.org/D28908

When I attempt to run the `wine` command, I get this error:

root@omen:/usr/ports.dev/emulators/i386-wine-devel # wine
wine: could not load ntdll.so: (null)
root@omen:/usr/ports.dev/emulators/i386-wine-devel #

It seems ntdll.so is a new DLL.

For anyone who has worked with Wine, is there a reason why this is
happening and how I can solve this?

-Neel

___
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"

Updating emulators/i386-wine-devel but get a runtime error

[Neel Chauhan]

Hi freebsd-ports@

I recently adopted emulators/i386-wine-devel and am attempting to update 
it to 6.2 along with adding 14.0 support.


Phabricator URL: https://reviews.freebsd.org/D28908

When I attempt to run the `wine` command, I get this error:

root@omen:/usr/ports.dev/emulators/i386-wine-devel # wine
wine: could not load ntdll.so: (null)
root@omen:/usr/ports.dev/emulators/i386-wine-devel #

It seems ntdll.so is a new DLL.

For anyone who has worked with Wine, is there a reason why this is 
happening and how I can solve this?


-Neel


signature.asc
Description: OpenPGP digital signature

Re: Phabricator Review: Updating the GNUstep Ports

[Neel Chauhan]

The phrase "The Port" in this email should mean "This patch", sorry for 
the wrong wording.


-Neel

On 2021-02-13 14:15, Neel Chauhan wrote:

Hi freebsd-ports@,

I have a review on Phabricator to update the GNUstep Ports:
https://reviews.freebsd.org/D28654

The Port mainly updates:

* devel/gnustep-make: Update to 2.8.0
* lang/gnustep-base: Update to 1.27.0
* x11-toolkits/gnustep-back: update to 0.28.0
* x11-toolkits/gnustep-gui: update to 0.28.0

But since this is a big update and involves bumping a lot of
PORTVERSIONs, could one of you committers please review this?

-Neel Chauhan (nc@)




signature.asc
Description: OpenPGP digital signature

Phabricator Review: Updating the GNUstep Ports

[Neel Chauhan]

Hi freebsd-ports@,

I have a review on Phabricator to update the GNUstep Ports: 
https://reviews.freebsd.org/D28654


The Port mainly updates:

* devel/gnustep-make: Update to 2.8.0
* lang/gnustep-base: Update to 1.27.0
* x11-toolkits/gnustep-back: update to 0.28.0
* x11-toolkits/gnustep-gui: update to 0.28.0

But since this is a big update and involves bumping a lot of 
PORTVERSIONs, could one of you committers please review this?


-Neel Chauhan (nc@)


signature.asc
Description: OpenPGP digital signature

Re: Updating devel/tbb - Introducing devel/onetbb

[Ganael Laplanche]

On Sunday, January 10, 2021 6:29:07 AM CET Shane Ambler wrote:

Hello Shane,

> You don't have to do it all yourself, you create the bug reports to
> change tbb and to create onetbb, one report can depend on the other so
> they get committed together. My experience is being told to submit one
> report for each port, not one patch to change multiple ports.
> 
> Then you create a report to say blender fails to build with your new
> port and add the report number to the Blocks list in your report. That
> leaves me to submit a patch to update blender to work with your change
> before your update can be committed. I would then add reports to update
> other dependencies that block my update.
> 
> At most you submit 20 reports to say xx/yy port needs updating. There is
> devel/pybugz and ports-mgmt/freebsd-bugzilla-cli that could automate
> that but I haven't used them so can't recommend either.
> 
> Then all the depends and blocks get updated together or some ports can
> get marked as broken if they fail to update in a suitable time.

OK, using Bugzilla that way will help us synchronize changes and prevent the 
ports tree from having things depending on both versions.

So, finally, here is the plan:

- Create a master PR containing expected devel/tbb and devel/onetbb ports
  (with CONFLICTS). I won't commit devel/onetbb before, to avoid having new
  ports needing it while others are still not migrated.
- Attach a blocking PR for each failing port and wait for patches
- At last, commit the new port and all port changes together

That should be OK that way :)

Thanks again for help! I'll start working on that ASAP, stay tuned!

-- 
Ganael LAPLANCHE 
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac , http://www.FreeBSD.org


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Updating devel/tbb - Introducing devel/onetbb

[Shane Ambler]

On 10/1/21 4:29 am, Ganael Laplanche wrote:

> 1) Move devel/tbb to a dedicated subdir and install devel/onetbb to its 
> default location. Here, we just anticipate what is written above. As you say, 
> as having devel/onetbb-only is the target, that would be the best solution 
> *BUT* it has the major disadvantage of having to patch all the current 
> dependent ports. This is error-prone and will require extra work I won't have 
> time to do. As I already wrote, I would prefer each porter to patch each port 
> himself (because he is the one who knows his port better that anyone). That's 
> why I suggested the second option.

You don't have to do it all yourself, you create the bug reports to
change tbb and to create onetbb, one report can depend on the other so
they get committed together. My experience is being told to submit one
report for each port, not one patch to change multiple ports.

Then you create a report to say blender fails to build with your new
port and add the report number to the Blocks list in your report. That
leaves me to submit a patch to update blender to work with your change
before your update can be committed. I would then add reports to update
other dependencies that block my update.

At most you submit 20 reports to say xx/yy port needs updating. There is
devel/pybugz and ports-mgmt/freebsd-bugzilla-cli that could automate
that but I haven't used them so can't recommend either.

Then all the depends and blocks get updated together or some ports can
get marked as broken if they fail to update in a suitable time.


-- 
FreeBSD - the place to B...Software Developing

Shane Ambler

___
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: Updating devel/tbb - Introducing devel/onetbb

[Ganael Laplanche]

On Saturday, January 9, 2021 9:49:24 AM CET Shane Ambler wrote:

Hello Shane,

Thanks for your reply.

> > - leave devel/tbb in place and introduce a new port: devel/onetbb
> 
> While I would generally support moving the old libs to a new portname,
> the fact that the project has renamed itself makes this acceptable.

Yes, this is the idea.

> The expected result is to have onetbb as the only option in the future,
> you should leave the new port to use a standard install and only if
> there is a need for it, alter the old port to co-install, you could get
> lucky and not have anyone that wants both versions installed.

I first thought about that too, but once several ports have started to use 
devel/onetbb, we could be in a situation where we have to relocate devel/tbb 
in a hurry (to avoid the CONFLICTS) because important ports still depending on 
devel/tbb cannot install anymore. I would like to avoid breaking important 
dependent ports that way as it can be anticipated.

I don't know each failing port, but for example I have the following deps on 
my desktop machine (default options) :

tbb <- suitesparse <- eigen <- movit <- mlt <- kdenlive <- kdemultimedia

so anyone wanting to install a port using the new devel/onetbb will be unable 
to install kdemultimedia and that's a no-go for me. What I mean here is that 
just leaving devel/tbb and devel/onetbb in place and hoping noone will be 
facing a CONFLICT seems unrealistic.

So that leaves only two possibilities :

1) Move devel/tbb to a dedicated subdir and install devel/onetbb to its 
default location. Here, we just anticipate what is written above. As you say, 
as having devel/onetbb-only is the target, that would be the best solution 
*BUT* it has the major disadvantage of having to patch all the current 
dependent ports. This is error-prone and will require extra work I won't have 
time to do. As I already wrote, I would prefer each porter to patch each port 
himself (because he is the one who knows his port better that anyone). That's 
why I suggested the second option.

2) The second option is to do quite the opposite : as everything is working 
fine now, don't touch anything and just introduce devel/onetbb in a way that 
it does not CONFLICT with current devel/tbb (i.e. in a dedicated subdir). It 
has several benefits : first, we don't break anything, then we leave each 
porter time to move their ports to devel/onetbb (we will not have to do that 
in a hurry) and finally, as each porter will have to move each port, if it is 
done by using a facility such as pkgconf, we gain a certain flexibility we 
don't have right now and that will ease next move (if there is one). The only 
disadvantage is that the library will not be located in the default paths 
anymore, but in a subdir. As we will have to patch dependent ports anyway to 
make them either detect the relocated devel/tbb (1st solution) or the new 
devel/onetbb (2nd solution), is that a problem ? Several ports already do that 
to be able to install several versions at the same time.

That's why I still think it would be easier and less error-prone to introduce 
devel/onetbb to a specific location and go for solution 2).

I would be pleased to receive other feedbacks. Maybe I am missing something 
here... ?

> Use bugs.freebsd to manage the update, start with submitting onetbb, and
> add conflicts with tbb. If dependent ports don't update and people want
> both installed, submit changes to allow tbb to co-install and have
> depends on bugs for each port that breaks so they get updated when the
> tbb changes get committed.

If we choose the second option, bugs.freebsd.org will probably be of less 
need, but it may be interesting to open a PR to follow ports migration anyway. 
I'll keep the idea in mind, thanks.

> The blender port uses seven of the other ports (with options on), with
> three others being slaves of one, so I expect that means a third of the
> ports will need to be updated together, as I doubt they will work
> together if they link to different tbb libs.
> 
> > - add a PKGNAMESUFFIX to devel/tbb to 'freeze' its version and modify
> > description to indicate the 'legacy' status of the port
> 
> I don't see a need to make these changes to the existing port. Maybe
> adding a note in the pkg-descr could make people aware of the new port.

Yes, I will do that too.

> > - [let maintainers migrate their ports to that new version]
> > - at some time (?), mark devel/tbb as DEPRECATED with an EXPIRATION_DATE
> > and do the same for remaining (non-updated) deps
> 
> As long as the existing tbb library compiles, it can stay as it is. Once
> maintaining the old port to build with new compilers/systems becomes a
> chore, then mark tbb and deps as deprecated and give them six months to
> update or be deleted. If all the deps get updated before then, the old
> tbb port can just be deleted.
> 
> If a port or two wants to stay with the old tbb, then let them maintain
> the tbb port.

Yes, why not. 

Re: Updating devel/tbb - Introducing devel/onetbb

[Shane Ambler]

On 8/1/21 9:51 pm, Ganael Laplanche wrote:

> - leave devel/tbb in place and introduce a new port: devel/onetbb

While I would generally support moving the old libs to a new portname,
the fact that the project has renamed itself makes this acceptable.

> - design devel/onetbb to install files in dedicated subdirs so that it will
> not CONFLICT with current devel/tbb (needed during migration phase)
> - provide a pkgconf file that will be used by dependencies to locate those
> files and include/link options easily

The expected result is to have onetbb as the only option in the future,
you should leave the new port to use a standard install and only if
there is a need for it, alter the old port to co-install, you could get
lucky and not have anyone that wants both versions installed.

Use bugs.freebsd to manage the update, start with submitting onetbb, and
add conflicts with tbb. If dependent ports don't update and people want
both installed, submit changes to allow tbb to co-install and have
depends on bugs for each port that breaks so they get updated when the
tbb changes get committed.

The blender port uses seven of the other ports (with options on), with
three others being slaves of one, so I expect that means a third of the
ports will need to be updated together, as I doubt they will work
together if they link to different tbb libs.

> - add a PKGNAMESUFFIX to devel/tbb to 'freeze' its version and modify
> description to indicate the 'legacy' status of the port

I don't see a need to make these changes to the existing port. Maybe
adding a note in the pkg-descr could make people aware of the new port.

> - [let maintainers migrate their ports to that new version]
> - at some time (?), mark devel/tbb as DEPRECATED with an EXPIRATION_DATE and
> do the same for remaining (non-updated) deps

As long as the existing tbb library compiles, it can stay as it is. Once
maintaining the old port to build with new compilers/systems becomes a
chore, then mark tbb and deps as deprecated and give them six months to
update or be deleted. If all the deps get updated before then, the old
tbb port can just be deleted.

If a port or two wants to stay with the old tbb, then let them maintain
the tbb port.


-- 
FreeBSD - the place to B...Software Developing

Shane Ambler

___
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"

Updating devel/tbb - Introducing devel/onetbb

[Ganael Laplanche]

Hello,

First of all, happy new year :)

Intel oneAPI tbb (formerly known as Intel tbb) 2021.1 has been released and 
has deprecated several interfaces over tbb 2020.

See:

  
https://software.intel.com/content/www/us/en/develop/articles/intel-oneapi-threading-building-blocks-release-notes.html

and:

  https://software.intel.com/content/www/us/en/develop/articles/tbb-revamp.html

As a consequence, I cannot update devel/tbb anymore as most of our dependent 
ports do *not* build with that new version, that includes:

Portname: Maintainer:
- ---
misc/openvdb  y...@freebsd.org
misc/dartsim  y...@freebsd.org
misc/ngraph   y...@freebsd.org
databases/tiledb  sunp...@freebsd.org
graphics/py-opencvtcber...@freebsd.org
graphics/opencv-java  tcber...@freebsd.org
graphics/instant-meshes   greg@unrelenting.technology
graphics/mirtky...@freebsd.org
graphics/opensubdiv   free...@shaneware.biz
graphics/blender  free...@shaneware.biz
graphics/opencv   tcber...@freebsd.org
graphics/opencv-core  tcber...@freebsd.org
graphics/oidn y...@freebsd.org
devel/py-numbad...@dal.ca
devel/ikosy...@freebsd.org
science/pagmo2y...@freebsd.org
science/madness   y...@freebsd.org
www/osrm-backend  free...@mosedal.net
archivers/par2cmdline-tbb marty...@freebsd.org
cad/opencascade   thie...@freebsd.org
cad/PrusaSlicer   teodorsig...@gmail.com
math/suitesparse  fort...@freebsd.org
math/saga rhur...@freebsd.org
math/dune-pdelab  y...@freebsd.org
math/openturnsy...@freebsd.org
math/curv y...@freebsd.org

The following ports seem to build correctly :

Portname: Maintainer:
- ---
math/dune-gridy...@freebsd.org
math/dune-common  y...@freebsd.org
math/dune-uggrid  y...@freebsd.org
math/dune-geometryy...@freebsd.org
biology/bowtie2   j...@freebsd.org
graphics/openimageio  free...@shaneware.biz
graphics/embree   da...@freebsd.org
math/deal.ii  y...@freebsd.org

See: http://box.martymac.org/FreeBSD-Packages/build.html?
mastername=FBSD122amd64-default=2021-01-07_12h17m40s for more details.

To be able to smoothly introduce onetbb 2021 into the ports tree and let 
maintainers migrate to that new version, here is my plan :

- leave devel/tbb in place and introduce a new port: devel/onetbb
- add a PKGNAMESUFFIX to devel/tbb to 'freeze' its version and modify 
description to indicate the 'legacy' status of the port
- design devel/onetbb to install files in dedicated subdirs so that it will 
not CONFLICT with current devel/tbb (needed during migration phase)
- provide a pkgconf file that will be used by dependencies to locate those 
files and include/link options easily
- [let maintainers migrate their ports to that new version]
- at some time (?), mark devel/tbb as DEPRECATED with an EXPIRATION_DATE and 
do the same for remaining (non-updated) deps

I would originally have preferred to do the opposite : i.e. move files from 
devel/tbb to a dedicated subdir and let devel/onetbb install files to the 
default PREFIX, but that would imply modifying each dependency myself, which 
is something I won't have time to do (and each port's MAINTAINER is probably 
the best person do do that). Doing it that way will also incite MAINTAINERs to 
use the pkgconf file whenever possible to detect onetbb, wich will introduce 
more flexibility for future updates.

Any comment on this ?

Best regards,

-- 
Ganael LAPLANCHE 
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac , http://www.FreeBSD.org


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Updating x11-toolkits/scintilla

[Naram Qashat]

Hello everyone,

I have been pretty behind on updating ports I maintain so I have been 
looking into updating x11-toolkits/scintilla from the current version in 
ports of 4.3.2 to the current actual version of 4.4.5. It appears as if 
scintilla is working towards making the lexers part of the library a 
separate component being named Lexilla. Although not planned to be the 
actual norm until Scintilla 5.0 comes out, currently it builds alongside 
the main Scintilla library.


In the ports tree, the only software utilizing x11-toolkits/scintilla is 
editors/scite (which I also maintain alongside it). The strange thing is 
that the Scintilla library currently includes the lexers AND builds the 
separate Lexilla library, and while SciTE by default statically links to 
the Scintilla library, it can at runtime load the Lexilla library (I'm 
not really sure why or how this would work if the main library also 
includes the same functionality).


The port for Scintilla was being modified to produce a separate lexer 
library anyways (although named scintilla_lexers instead of lexilla), 
and the SciTE port was being modified to link to a shared Scintilla 
library instead of the static library it expects.


Since SciTE is the only thing in the ports tree utilizing Scintilla 
directly, I am unsure how many projects external to the ports tree are 
being used by others with also utilize the Scintilla library. As such, I 
am wanting to change things up with the port so it produces the 
Scintilla and Lexilla libraries as the author has set out (so basically, 
scintilla and lexilla instead of scintilla and scintilla_lexers), and 
then making SciTE still continue with linking to the shared Scintilla 
library instead of the static one.


If anyone on the mailing list here does use the library as built by 
x11-toolkits/scintilla and would be affected if I do the above change 
for the installed shared libraries, please let me know. Otherwise I will 
be attempting to go forward with the change, especially since once the 
author releases Scintilla 5.0, it will be the norm anyways.


Thanks in advance,
Naram "CyberBotX" Qashat
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Poudriere: Installing or updating jails fail with cp/utils.c error

[Kyle Evans]

On Tue, Oct 6, 2020 at 2:30 PM Rainer Hurling  wrote:
>
> On 02.10.20 11:19, Rainer Hurling wrote:
> > For some time now, I get the following error when trying to create or
> > update 11.4 or 12.2 jails in Poudriere:
> >
> >
> > #poudriere jail -c -j F114i386 -v stable/11 -a i386 -m svn+https
> >
> > [..snip..]
> > --- all_subdir_rescue ---
> > --- /poudriere/jails/F114i386/usr/src/bin/cp/utils.o ---
> > cc  -O2 -pipe   -std=gnu99-Qunused-arguments   -O2 -pipe -c
> > /poudriere/jails/F114i386/usr/src/bin/cp/utils.c -o
> > /poudriere/jails/F114i386/usr/src/bin/cp/utils.o
> > /poudriere/jails/F114i386/usr/src/bin/cp/utils.c:515:14: error: member
> > reference base type 'void' is not a structure or union
> > aclp = >ats_acl;
> > ~~~^ ~~~
> > /poudriere/jails/F114i386/usr/src/bin/cp/utils.c:516:11: error:
> > incomplete definition of type 'struct acl'
> > if (aclp->acl_cnt != 0 && aclsetf(dest_dir,
> > ^
> > /poudriere/jails/F114i386/usr/src/bin/cp/utils.c:466:9: note: forward
> > declaration of 'struct acl'
> > struct acl *aclp;
> >^
> > 2 errors generated.
> > *** [/poudriere/jails/F114i386/usr/src/bin/cp/utils.o] Error code 1
> >
> > make[5]: stopped in
> > /usr/obj/i386.i386/poudriere/jails/F114i386/usr/src/rescue/rescue
> >
> >
> > This happens on a recent 13.0-CURRENT amd64 (r366190). Updating HEAD
> > jails work fine so far.
>
> Just for the record:
>
> After updating my (host) box to 13.0-CURRENT r366466 (crunchgen: fix
> MK_AUTO_OBJ logic), I am able to install and update my jails versions
> 11.4 and 12.1 on Poudriere again.
>

Ah, my apologies for missing this report. :-( Indeed, that should be
the end of that; it will get MFC'd in ~2 days to mitigate the issue on
stable/12 since I MFC'd the breaking commit back, but the bug
fortunately did not make it into 12.2.

Thanks,

Kyle Evans
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Poudriere: Installing or updating jails fail with cp/utils.c error

[Rainer Hurling]

On 02.10.20 11:19, Rainer Hurling wrote:
> For some time now, I get the following error when trying to create or
> update 11.4 or 12.2 jails in Poudriere:
> 
> 
> #poudriere jail -c -j F114i386 -v stable/11 -a i386 -m svn+https
> 
> [..snip..]
> --- all_subdir_rescue ---
> --- /poudriere/jails/F114i386/usr/src/bin/cp/utils.o ---
> cc  -O2 -pipe   -std=gnu99    -Qunused-arguments   -O2 -pipe -c
> /poudriere/jails/F114i386/usr/src/bin/cp/utils.c -o
> /poudriere/jails/F114i386/usr/src/bin/cp/utils.o
> /poudriere/jails/F114i386/usr/src/bin/cp/utils.c:515:14: error: member
> reference base type 'void' is not a structure or union
>     aclp = >ats_acl;
>     ~~~^ ~~~
> /poudriere/jails/F114i386/usr/src/bin/cp/utils.c:516:11: error:
> incomplete definition of type 'struct acl'
>     if (aclp->acl_cnt != 0 && aclsetf(dest_dir,
>     ^
> /poudriere/jails/F114i386/usr/src/bin/cp/utils.c:466:9: note: forward
> declaration of 'struct acl'
>     struct acl *aclp;
>    ^
> 2 errors generated.
> *** [/poudriere/jails/F114i386/usr/src/bin/cp/utils.o] Error code 1
> 
> make[5]: stopped in
> /usr/obj/i386.i386/poudriere/jails/F114i386/usr/src/rescue/rescue
> 
> 
> This happens on a recent 13.0-CURRENT amd64 (r366190). Updating HEAD
> jails work fine so far.

Just for the record:

After updating my (host) box to 13.0-CURRENT r366466 (crunchgen: fix
MK_AUTO_OBJ logic), I am able to install and update my jails versions
11.4 and 12.1 on Poudriere again.

> 
> Am I doing something wrong? I thought, the cp/utils.c problem was solved
> some time ago?
> 
> Thanks for any insight and help.
> 
> Regards,
> Rainer Hurling

___
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: Might an UPDATING entry be appropriate for a MINIMAL_PKG_VERSION bump?

[Tatsuki Makino]

David Wolfskill wrote on 2020/10/06 08:45:

> 
> But in order for them to be built, you need to have updated
> ports-mgmt/pkg ahead of time, or this kind of thing happens:
> 
> | ...

> | ===>  Cleaning for nvidia-driver-440.100_1
> | ===>  nvidia-driver-440.100_1 pkg(8) must be version 1.15.9 or greater, but
> | you have 1.15.8. You must upgrade the ports-mgmt/pkg port first.
> | *** Error code 1
> | 
> | Stop.
> 

Hmmm.
I've never bothered with that because I'm following the steps below :)

svnlite cleanup /usr/src
svnlite update /usr/src
rm -r -f /usr/obj/{*,.[^.]*,..?*}
svnlite revert -R /usr/src
patch -d /usr/src < mypatch
portsnap fetch update
portmaster -x \*-kmod-\[0-9gv\] -a
make -C /usr/src buildworld
make -C /usr/src buildkernel
mergemaster -p
make -C /usr/src installkernel
make -C /usr/src installworld
make -C /usr/src delete-old delete-old-libs
mergemaster
shutdown -r +1

> 
> Hence my query: Is an UPDATING entry warranted when MINIMAL_PKG_VERSION is
> bumped?
>

Normally, when pkg appears in pkg version -L =, it is replaced
immediately because something of a bug in it has been fixed.
Rarely, though, there are more bugs :)

Best regards.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Might an UPDATING entry be appropriate for a MINIMAL_PKG_VERSION bump?

[David Wolfskill]

On Tue, Oct 06, 2020 at 08:31:05AM +0900, Tatsuki Makino wrote:
> Hello.
> 
> In my case,
> -x \*-kmod-\[0-9gv\] is added to portmaster because all packages that
> install kernel modules contain -kmod in their names. This excludes *-kmod.
> And when they are upgraded, I won't be installing them right away.
> 
> Then to install them I write PORTS_MODULES in src.conf.
> PORTS_MODULES=\
> graphics/drm-fbsd12.0-kmod\
> graphics/gpu-firmware-kmod
> 
> They are created at the same time as the kernel.
> 

But in order for them to be built, you need to have updated
ports-mgmt/pkg ahead of time, or this kind of thing happens:

| ...
| --- kernel.full ---
| linking kernel.full
| ctfmerge -L VERSION -g -o kernel.full ...
|   text  data   bssdec hex   filename
|   22900304   1840729   3667344   28408377   0x1b17a39   kernel.full
| Building /common/S1/obj/usr/src/amd64.amd64/sys/CANARY/kernel.debug
| Building /common/S1/obj/usr/src/amd64.amd64/sys/CANARY/kernel
| --- all ---
| ===> Ports module x11/nvidia-driver (all)
| cd ${PORTSDIR:-/usr/ports}/x11/nvidia-driver; env  -u CC  -u CXX  -u CPP  -u 
MAKESYSPATH  -u MK_AUTO_OBJ  -u MAKEOBJDIR  MAKEFLAGS="-j 16 -J 15,16 -j 16 -J 
15,16 -D NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL KERNEL=kernel TARGET=amd64 
TARGET_ARCH=amd64"  SYSDIR=/usr/src/sys  
PATH=/common/S1/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/common/S1/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/common/S1/obj/usr/src/amd64.amd64/tmp/legacy/bin:/common/S1/obj/usr/src/amd64.amd64/tmp/usr/sbin:/common/S1/obj/usr/src/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
  SRC_BASE=/usr/src  OSVERSION=1202502  
WRKDIRPREFIX=/common/S1/obj/usr/src/amd64.amd64/sys/CANARY make -B clean build
| ===>  Cleaning for nvidia-driver-440.100_1
| ===>  nvidia-driver-440.100_1 pkg(8) must be version 1.15.9 or greater, but
| you have 1.15.8. You must upgrade the ports-mgmt/pkg port first.
| *** Error code 1
| 
| Stop.


Hence my query: Is an UPDATING entry warranted when MINIMAL_PKG_VERSION is
bumped?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"the end of the pandemic is in sight" -- Donald Trump (while infected
with SARS-COV-2)

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Might an UPDATING entry be appropriate for a MINIMAL_PKG_VERSION bump?

[Tatsuki Makino]

Hello.

In my case,
-x \*-kmod-\[0-9gv\] is added to portmaster because all packages that
install kernel modules contain -kmod in their names. This excludes *-kmod.
And when they are upgraded, I won't be installing them right away.

Then to install them I write PORTS_MODULES in src.conf.
PORTS_MODULES=\
graphics/drm-fbsd12.0-kmod\
graphics/gpu-firmware-kmod

They are created at the same time as the kernel.

Best regards.


David Wolfskill wrote on 2020/10/05 21:54:
> When I rebuild FreeBSD (stable/12) on my laptop, I also rebuild a ports
> module (x11/nvidia-driver), since the laptop has an Nvidia graphics
> card.
> 
> However, a couple of times within the last few days, the kernel build
> has failed because I normally wait to update ports until after I have
> built and rebooted the newly-built base OS... and "?ports" includes
> ports-mgmt/pkg.
> 
> In each case (so far), I have then updated ports-mgmt/pkg, then
> re-started the base OS build/install.
> 
> I believe that it would be helpful to have an UPDATING entry reflect
> that "evasive action" is required when MINIMAL_PKG_VERSION is bumped.
> 
> Or, perhaps, I'm going about this all wrong...?  If so, please let me
> know a better way.
> 
> Thanks.
> 
> Peace,
> david
> 
___
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"

Might an UPDATING entry be appropriate for a MINIMAL_PKG_VERSION bump?

[David Wolfskill]

When I rebuild FreeBSD (stable/12) on my laptop, I also rebuild a ports
module (x11/nvidia-driver), since the laptop has an Nvidia graphics
card.

However, a couple of times within the last few days, the kernel build
has failed because I normally wait to update ports until after I have
built and rebooted the newly-built base OS... and "?ports" includes
ports-mgmt/pkg.

In each case (so far), I have then updated ports-mgmt/pkg, then
re-started the base OS build/install.

I believe that it would be helpful to have an UPDATING entry reflect
that "evasive action" is required when MINIMAL_PKG_VERSION is bumped.

Or, perhaps, I'm going about this all wrong...?  If so, please let me
know a better way.

Thanks.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Donald Trump is just in it for the publicity (well, and the money).

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Poudriere: Installing or updating jails fail with cp/utils.c error

[Rainer Hurling]

For some time now, I get the following error when trying to create or 
update 11.4 or 12.2 jails in Poudriere:



#poudriere jail -c -j F114i386 -v stable/11 -a i386 -m svn+https

[..snip..]
--- all_subdir_rescue ---
--- /poudriere/jails/F114i386/usr/src/bin/cp/utils.o ---
cc  -O2 -pipe   -std=gnu99-Qunused-arguments   -O2 -pipe -c 
/poudriere/jails/F114i386/usr/src/bin/cp/utils.c -o 
/poudriere/jails/F114i386/usr/src/bin/cp/utils.o
/poudriere/jails/F114i386/usr/src/bin/cp/utils.c:515:14: error: member 
reference base type 'void' is not a structure or union

aclp = >ats_acl;
~~~^ ~~~
/poudriere/jails/F114i386/usr/src/bin/cp/utils.c:516:11: error: 
incomplete definition of type 'struct acl'

if (aclp->acl_cnt != 0 && aclsetf(dest_dir,
^
/poudriere/jails/F114i386/usr/src/bin/cp/utils.c:466:9: note: forward 
declaration of 'struct acl'

struct acl *aclp;
   ^
2 errors generated.
*** [/poudriere/jails/F114i386/usr/src/bin/cp/utils.o] Error code 1

make[5]: stopped in 
/usr/obj/i386.i386/poudriere/jails/F114i386/usr/src/rescue/rescue



This happens on a recent 13.0-CURRENT amd64 (r366190). Updating HEAD 
jails work fine so far.


Am I doing something wrong? I thought, the cp/utils.c problem was solved 
some time ago?


Thanks for any insight and help.

Regards,
Rainer Hurling
___
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: Segmentation fault happens after updating mail/postfix to 3.5.5

[Carmel]

On Sun, 26 Jul 2020 11:59:25 +0900 (JST), Yasuhiro KIMURA stated:
>Hello All,
>
>After updating mail/postfix to 3.5.5 following warning message appears
>in /var/log/maillog.
>
>Jul 26 11:47:34 eastasia postfix/smtpd[93696]: connect from
>maybe.home.utahime.org[192.168.174.201] Jul 26 11:47:34 eastasia
>postfix/smtpd[93696]: SSL_accept error from
>maybe.home.utahime.org[192.168.174.201]: -1 Jul 26 11:47:34 eastasia
>postfix/smtpd[93696]: warning: TLS library problem: error:14094412:SSL
>routines:ssl3_read_bytes:sslv3 alert bad
>certificate:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:1544:SSL
>alert number 42: Jul 26 11:47:34 eastasia postfix/master[93317]:
>warning: process /usr/local/libexec/postfix/smtpd pid 93696 killed by
>signal 11
>
>yasu@eastasia[3721]% uname -a
>FreeBSD eastasia.home.utahime.org 12.1-RELEASE-p7 FreeBSD
>12.1-RELEASE-p7 GENERIC  amd64
>
>Does anyone else experience it?


Have you read this:
http://www.postfix.org/DEBUG_README.html

In particular, this:
http://www.postfix.org/DEBUG_README.html#mail

Better, provide output from the postfinger tool. This can be found at
http://ftp.wl0.org/SOURCES/postfinger.

In any case, you would be best served by reporting this problem on the
Postfix forum. Victor will probably be able to tell you what the
problem is immediately, after posting the required data as mentioned
above.

-- 
Jerry



pgpqmOrIFuTuD.pgp
Description: OpenPGP digital signature

Segmentation fault happens after updating mail/postfix to 3.5.5

[Yasuhiro KIMURA]

Hello All,

After updating mail/postfix to 3.5.5 following warning message appears
in /var/log/maillog.

Jul 26 11:47:34 eastasia postfix/smtpd[93696]: connect from 
maybe.home.utahime.org[192.168.174.201]
Jul 26 11:47:34 eastasia postfix/smtpd[93696]: SSL_accept error from 
maybe.home.utahime.org[192.168.174.201]: -1
Jul 26 11:47:34 eastasia postfix/smtpd[93696]: warning: TLS library problem: 
error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad 
certificate:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:1544:SSL alert 
number 42:
Jul 26 11:47:34 eastasia postfix/master[93317]: warning: process 
/usr/local/libexec/postfix/smtpd pid 93696 killed by signal 11

yasu@eastasia[3721]% uname -a
FreeBSD eastasia.home.utahime.org 12.1-RELEASE-p7 FreeBSD 12.1-RELEASE-p7 
GENERIC  amd64

Does anyone else experience it?

---
Yasuhiro KIMURA
___
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: Updating py27-* ports

[Carmel]

On Sat, 4 Jul 2020 10:23:09 -0600, @lbutlr stated:
>On 04 Jul 2020, at 08:30, Carmel  wrote:
>> I see that you are putting it all on one line. That is probably
>> easier. I like the separate entries technique simply because I find
>> it easier to read myself or quickly comment out an entry.  
>
>I agree that separate lines have advantages. When making changes I
>tend to go to multiple lines, then collapse back to a single line when
>I have a stable set.
>
>> What I have never been able to get a definitive answer to is exactly
>> what the "+" does or if it is even needed, I have seen
>> 'default_versions" both with and without it.  
>
>+= adds the option, = set it.
>
>DEFAULT_VERSIONS=foo bar sing
>$DEFAULT_VERSIONS foo bar sing
>
>DEFAULT_VERSIONS+=max
>$DEFAULT_VERSIONS foo bar sing max
>
>DEFAULT_VERSIONS=sam
>$DEFAULT_VERSIONS sam

Thanks

-- 
Carmel

I never slept with an ugly woman,
although I certainly woke up with a few.


pgpimKP5rOkhg.pgp
Description: OpenPGP digital signature

Re: Updating py27-* ports

[Tatsuki Makino]

Hello.

As for packages that require py27-*, I think it's better to leave it to
poudriere.

Then I think the py27-* package can be cleaned up with the following
command.

# If you are running poudriere bulk as follows.
# poudriere bulk -f ~/pkglist -j name

poudriere pkgclean -f ~/pkglist -j name


Regards.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Updating py27-* ports

[@lbutlr]

On 04 Jul 2020, at 08:30, Carmel  wrote:
> I see that you are putting it all on one line. That is probably easier.
> I like the separate entries technique simply because I find it easier
> to read myself or quickly comment out an entry.

I agree that separate lines have advantages. When making changes I tend to go 
to multiple lines, then collapse back to a single line when I have a stable set.

> What I have never been able to get a definitive answer to is exactly
> what the "+" does or if it is even needed, I have seen
> 'default_versions" both with and without it.

+= adds the option, = set it.

DEFAULT_VERSIONS=foo bar sing
$DEFAULT_VERSIONS foo bar sing

DEFAULT_VERSIONS+=max
$DEFAULT_VERSIONS foo bar sing max

DEFAULT_VERSIONS=sam
$DEFAULT_VERSIONS sam



-- 
Please to meet you, Rose. Now run for your life!

___
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: Updating py27-* ports

[Christoph Moench-Tegeder]

## Carmel (carmel...@outlook.com):

> DEFAULT_VERSIONS+=python2=3.7

Forcing python 2 to be python 3.7 will probably break - as far as I can
see, there're safeguards in place which will prevent this. In most cases,
the python2 dependency is there because upstream hasn't updated their
code yet. (That's the case for the build systems of firefox/thunderbird
and chromium - all of them are work in progress upstream - and Gimp's
python bindings, which are planned to be python-3-compatible with
Gimp 3 expected later this year (at least it was, last time I checked)).

Regards,
Christoph

-- 
Spare Space
___
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: Updating py27-* ports

[Pau Amma]

On 2020-07-04 16:30, Carmel wrote:

What I have never been able to get a definitive answer to is exactly
what the "+" does or if it is even needed, I have seen
'default_versions" both with and without it.


The way I understand it, += appends. Thus:
FOO=bar
FOO+=quux
will result in FOO having the value bar quux. Sometimes you will see += 
used even for what looks like the first of a series of assignments. This 
works because the initial value is the empty string, and is usually done 
to add to any non-empty default or initial value the variable may be 
getting elsewhere (now or later) or to future-proof against needing to 
add something before the first assignment and forgetting to change it 
from = to +=.


See also, "Variable assignment modifiers" in the make manual page.
___
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: Updating py27-* ports

[Kurt Jaeger]

Hi!

> >> update these ports? I was thinking of placing this in the
> >> "poudriere.d/make.conf" file:
[...]
> What I have never been able to get a definitive answer to is exactly
> what the "+" does or if it is even needed, I have seen
> 'default_versions" both with and without it.

The file is read by make during the build, so it's just part
of the make syntax:

man make

says:

+=  Append the value to the current value of the variable.

-- 
p...@opsec.eu+49 171 3101372Now what ?
___
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: Updating py27-* ports

[Carmel]

On Sat, 4 Jul 2020 16:11:29 +0200, Kurt Jaeger stated:
>Hi!
>
>> I use 'poudriere' to maintain my ports. I still have a few ports that
>> depend on the depreciated py27. What is the recommended method to
>> update these ports? I was thinking of placing this in the
>> "poudriere.d/make.conf" file:
>> 
>> DEFAULT_VERSIONS+=python=3.7
>> DEFAULT_VERSIONS+=python2=3.7
>> DEFAULT_VERSIONS+=python3=3.7
>> 
>> and then rebuild all of my ports. Would that be sufficient, or even
>> correct?  
>
>I used this in poudriere:
>
>DEFAULT_VERSIONS=python=3.7 python3=3.7
>
>So I did not use python2=3.7 -- which will probably not work.
>
>That worked good enough that I did not investigate any further.

I see that you are putting it all on one line. That is probably easier.
I like the separate entries technique simply because I find it easier
to read myself or quickly comment out an entry.

What I have never been able to get a definitive answer to is exactly
what the "+" does or if it is even needed, I have seen
'default_versions" both with and without it.

Thanks!

-- 
Carmel


pgpAqUzgXWw1M.pgp
Description: OpenPGP digital signature

Re: Updating py27-* ports

[Kurt Jaeger]

Hi!

> I use 'poudriere' to maintain my ports. I still have a few ports that
> depend on the depreciated py27. What is the recommended method to
> update these ports? I was thinking of placing this in the
> "poudriere.d/make.conf" file:
> 
> DEFAULT_VERSIONS+=python=3.7
> DEFAULT_VERSIONS+=python2=3.7
> DEFAULT_VERSIONS+=python3=3.7
> 
> and then rebuild all of my ports. Would that be sufficient, or even
> correct?

I used this in poudriere:

DEFAULT_VERSIONS=python=3.7 python3=3.7

So I did not use python2=3.7 -- which will probably not work.

That worked good enough that I did not investigate any further.

-- 
p...@opsec.eu+49 171 3101372Now what ?
___
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"

Updating py27-* ports

[Carmel]

I use 'poudriere' to maintain my ports. I still have a few ports that
depend on the depreciated py27. What is the recommended method to
update these ports? I was thinking of placing this in the
"poudriere.d/make.conf" file:

DEFAULT_VERSIONS+=python=3.7
DEFAULT_VERSIONS+=python2=3.7
DEFAULT_VERSIONS+=python3=3.7

and then rebuild all of my ports. Would that be sufficient, or even
correct?

Thanks!

-- 
Carmel


pgpF26xWJ1z3w.pgp
Description: OpenPGP digital signature

Re: Json-c, bind, and updating

[Renato Botelho]

On 10/06/20 03:18, Steve Kargl wrote:

On Tue, Jun 09, 2020 at 11:45:28PM -0600, @lbutlr wrote:

This has happened in the past, but it happened again this weekend when an 
update to ;ibjson-c did not update bind, rendering bind unable to load 
libjson-c.so.4 because it had been replaced with libjson-c.so.5.



man libmap.conf

This allows you to associate libjson-c.so.4 with *.5
without doing the symlink, which you'll need to
remember to remove in the future.

My libmap.conf currently has

% cat /etc/libmap.conf
includedir /usr/local/etc/libmap.d
libicui18n.so.66  libicui18n.so.67
libicuuc.so.66libicuuc.so.67
libevent-2.1.so.6 libevent-2.1.so.7
libncurses.so.8 libncurses.so.9
libncursesw.so.8 libncursesw.so.9

because it seems like everything (indirectly) depends on
libncurses change and the icu port.  Eventually, portmaster
and I catch up and libmap.conf entries are removed.


For this libncurses speficific case you can just install misc/compat12x 
and have the old library version available.


--
Renato Botelho
___
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: Json-c, bind, and updating

[Steve Kargl]

On Tue, Jun 09, 2020 at 11:45:28PM -0600, @lbutlr wrote:
> This has happened in the past, but it happened again this weekend when an 
> update to ;ibjson-c did not update bind, rendering bind unable to load 
> libjson-c.so.4 because it had been replaced with libjson-c.so.5.
> 

man libmap.conf

This allows you to associate libjson-c.so.4 with *.5
without doing the symlink, which you'll need to 
remember to remove in the future.

My libmap.conf currently has

% cat /etc/libmap.conf
includedir /usr/local/etc/libmap.d
libicui18n.so.66  libicui18n.so.67
libicuuc.so.66libicuuc.so.67
libevent-2.1.so.6 libevent-2.1.so.7
libncurses.so.8 libncurses.so.9
libncursesw.so.8 libncursesw.so.9

because it seems like everything (indirectly) depends on
libncurses change and the icu port.  Eventually, portmaster
and I catch up and libmap.conf entries are removed.

--
Steve
___
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"

Json-c, bind, and updating

[@lbutlr]

This has happened in the past, but it happened again this weekend when an 
update to ;ibjson-c did not update bind, rendering bind unable to load 
libjson-c.so.4 because it had been replaced with libjson-c.so.5.

In a rush I simply linked libjson-c.so.4 -> libjson-c.so.5 and all is happy 
AFAICT. Well, at least functional.

There is no update listed for bind because, evidently, "The dns/bind914 port 
moved to dns/bind916 Reason: Has expired: End of life, please migrate to a 
newer version of BIND9" is not an "update". I mean, yes, this is correct, but 
it seems less than helpful. And yet, if I try to install bund914, it will 
install 916, so there is an update.

Especially when Bind-tools is happily updated to 9.16

The following actions were performed:
Re-installation of bind-tools-9.16.3_1
Upgrade of bind914-9.14.11 to bind916-9.16.3_2

Sure would have been nice if this had shown up as an available update.


-- 
he'd moved like music, like someone dancing to a rhythm inside his
head. And his face for a moment in the moonlight was the skull of
an angel…


___
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"

Updating Samba

[Carmel NY]

The latest stable release of Samba is "4.11.2". The newest port version
is "4.10.10". Are there plans to update Samba to the latest stable
release or is there a specific reason that it cannot be done at this
time?

-- 
Carmel
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [Circumvented] Problem updating gimp-app-2.10.12_2, 1 to gimp-app-2.10.12_3, 1

[Kevin Oberman]

On Mon, Sep 2, 2019 at 4:41 AM David Wolfskill  wrote:

> On Mon, Sep 02, 2019 at 01:34:50PM +0200, Walter Schwarzenfeld wrote:
> > Try recompile graphics/libspiro.
> > 
>
> Thanks.  As noted, I did (along with graphics/gegl), and that appears to
> have circumvented the problem.
>
> I wrote the note so that others might make use of my experience: the
> issue is resolved for me.
>
> Peace,
> david


Actually, no need to rebuild libspiro. The problem is that libpiro was
updated Aug. 19 and the shareable version was bumped from '0' to '1' making
gegl fail to load. Rebuilding gegl allows it to run normally and gimp-app
to build.
The real problem is that the pkg database is not working "right". i looked
at gegl dependencies, it showed libspiro:
   > pkg info -d gegl
   gegl-0.4.16_2:
   [...]
   openexr-2.3.0_2
   libspiro-20190731,1
   librsvg2-2.40.20
  [...]

But showing the "depends on" for libspiro showed:
   > pkg info -r libspiro
   libspiro-20190731,1:
   >
So attempting to list dependencies on libspiro would not have flagged gegl
s needing a PORT_REVISION bump to be rebuilt to catch the .so version bump
of libspiro. This should not happen, but clearly did... and not just to me.
I will also mention that the commit to libspiro did not mention the
shareable version bump or bump PORT_REVISION on ny ports. So the committer
perhaps did not realize that there was an issue. I will drop the committer
a note.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [Circumvented] Problem updating gimp-app-2.10.12_2,1 to gimp-app-2.10.12_3,1

[Walter Schwarzenfeld]

Sorry,seems I only read the half of the post.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [Circumvented] Problem updating gimp-app-2.10.12_2,1 to gimp-app-2.10.12_3,1

[David Wolfskill]

On Mon, Sep 02, 2019 at 01:34:50PM +0200, Walter Schwarzenfeld wrote:
> Try recompile graphics/libspiro.
> 

Thanks.  As noted, I did (along with graphics/gegl), and that appears to
have circumvented the problem.

I wrote the note so that others might make use of my experience: the
issue is resolved for me.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"I am the Chosen One!" -- Donald Trump [Cf. Mt 24:23-24; Mk 13:21-23; Jn 5:31]

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: [Circumvented] Problem updating gimp-app-2.10.12_2,1 to gimp-app-2.10.12_3,1

[Walter Schwarzenfeld]

Try recompile graphics/libspiro.

___
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"

[Circumvented] Problem updating gimp-app-2.10.12_2,1 to gimp-app-2.10.12_3,1

[David Wolfskill]

I update base FreeBSD and the installed ports on my laptop daily;
usually, this works out quite well (which I think says something very
positive about FreeBSD).

This morning, the attempt to update graphics/gimp-app failed; I was able
to get it to work by manually re-building and -installing
graphics/libspiro and graphics/gegl.  (It's quite possible that only
doing one of those would have been sufficient; I don't know.)  Below are
details for those who may be interested.

Yesterday's update for base stable/11 was actually a no-op: I updated
from r351611 to r351640 on Saturday (31 August); there were no updates
to stable/11 (or stable/12, for that matter) as of the sync I ran on 01
September.

Yesterday's update for ports from from r510361 to r510686, and was
uneventful.

Today's update for base FreeBSD stable/11 was from r351640 to
r351694; ports was from r510686 to r510776.

I use portmaster to build/install the ports on my laptop; it reported
the following ports would be updated (this morning):

===>>> The following actions will be taken if you choose to proceed:
Upgrade libogg-1.3.3,4 to libogg-1.3.4,4
Upgrade gimp-app-2.10.12_2,1 to gimp-app-2.10.12_3,1
Upgrade poppler-glib-0.79.0 to poppler-glib-0.80.0_1
Upgrade poppler-0.79.0 to poppler-0.80.0_1
Upgrade libarchive-3.3.3_1,1 to libarchive-3.4.0,1
Upgrade libgcrypt-1.8.4_1 to libgcrypt-1.8.5
Upgrade poppler-utils-0.79.0 to poppler-utils-0.80.0_1
Upgrade texlive-base-20150521_39 to texlive-base-20150521_40
Upgrade chromium-76.0.3809.100 to chromium-76.0.3809.132
Upgrade inkscape-0.92.4_6 to inkscape-0.92.4_7
Upgrade py27-gimp-2.10.12_2 to py27-gimp-2.10.12_3
Re-install py27-gobject-2.28.6_8
Re-install py27-gtk2-2.24.0_5


The failure looked like this:

...
mkdir -p 24 && \
../../tools/invert-svg ../../icons/Symbolic/24/gimp-wilber.svg 
24/gimp-wilber.svg
mkdir -p `dirname 64/gimp-error.png`; GEGL_USE_OPENCL=no GEGL_SWAP=ram 
/usr/local/bin/gegl ../../icons/Symbolic/64/gimp-error.png -o 64/gimp-error.png 
-- gegl:invert-gamma
mkdir -p `dirname 64/gimp-info.png`; GEGL_USE_OPENCL=no GEGL_SWAP=ram 
/usr/local/bin/gegl ../../icons/Symbolic/64/gimp-info.png -o 64/gimp-info.png 
-- gegl:invert-gamma
mkdir -p `dirname 64/gimp-question.png`; GEGL_USE_OPENCL=no GEGL_SWAP=ram 
/usr/local/bin/gegl ../../icons/Symbolic/64/gimp-question.png -o 
64/gimp-question.png -- gegl:invert-gamma
Shared object "libspiro.so.0" not found, required by "gegl"
Shared object "libspiro.so.0" not found, required by "gegl"
gmake[5]: *** [Makefile:2411: 64/gimp-error.png] Error 1
gmake[5]: *** Waiting for unfinished jobs
gmake[5]: *** [Makefile:2411: 64/gimp-info.png] Error 1
Shared object "libspiro.so.0" not found, required by "gegl"
gmake[5]: *** [Makefile:2411: 64/gimp-question.png] Error 1
gmake[5]: Leaving directory 
'/common/ports/graphics/gimp-app/work/gimp-2.10.12/icons/Symbolic-Inverted'
gmake[4]: *** [Makefile:717: all-recursive] Error 1
gmake[4]: Leaving directory 
'/common/ports/graphics/gimp-app/work/gimp-2.10.12/icons'
gmake[3]: *** [Makefile:852: all-recursive] Error 1
gmake[3]: Leaving directory '/common/ports/graphics/gimp-app/work/gimp-2.10.12'
gmake[2]: *** [Makefile:753: all] Error 2
gmake[2]: Leaving directory '/common/ports/graphics/gimp-app/work/gimp-2.10.12'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[1]: stopped in /common/ports/graphics/gimp-app
*** Error code 1

Stop.
make: stopped in /common/ports/graphics/gimp-app

===>>> make build failed for graphics/gimp-app
===>>> Aborting update

===>>> Update for graphics/gimp-app failed
===>>> Aborting update
.



I then ran:

portmaster --no-term-title -d graphics/libspiro graphics/gegl

(which was ... uneventful), after which 

portmaster --no-term-title -ad

reported:

===>>> The following actions will be taken if you choose to proceed:
Upgrade gimp-app-2.10.12_2,1 to gimp-app-2.10.12_3,1
Upgrade libarchive-3.3.3_1,1 to libarchive-3.4.0,1
Upgrade libgcrypt-1.8.4_1 to libgcrypt-1.8.5
Upgrade poppler-utils-0.79.0 to poppler-utils-0.80.0_1
Upgrade texlive-base-20150521_39 to texlive-base-20150521_40
Upgrade chromium-76.0.3809.100 to chromium-76.0.3809.132
Upgrade inkscape-0.92.4_6 to inkscape-0.92.4_7
Upgrade py27-gimp-2.10.12_2 to py27-gimp-2.10.12_3
Re-install py27-gobject-2.28.6_8
Re-install py27-gtk2-2.24.0_5

which I acknowledged -- and it's well past the problematic port now
(working on chromium, which will take  a while).

Given the nature of the failure and the circumvention, I suspect
that an undeclared dependency may exist that involves some combination
of graphics/gimp-app, graphics/libspiro, or graphics/gegl -- possibly
involving port options; here are the options I have for each:

g1-49(11.3-S)[15] 

Re: Updating Samba

[DutchDaemon - FreeBSD Forums Administrator]

On 2019-06-20 14:17, Carmel NY wrote:
> The 20190619 entry in "UPDATING" recommends certain actions for
> updating Samba4[6-8] utilizing either 'portmaster' or 'portupgrade'.
> Are there4 any special actions that have to be taken if utilizing


Poudriere built the ports correctly; I did have to run pkg upgrade twice
because of conflicting dependencies; which were solved by running it twice.




signature.asc
Description: OpenPGP digital signature

Updating Samba

[Carmel NY]

The 20190619 entry in "UPDATING" recommends certain actions for
updating Samba4[6-8] utilizing either 'portmaster' or 'portupgrade'.
Are there4 any special actions that have to be taken if utilizing
'poudriere'?

Thanks!

-- 
Carmel NY
___
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"

devel/autogen upgrade will fail. UPDATING needs an entry

[Kevin Oberman]

Upgrading devel/autogen will fail as the build procedure will attempt to
run the new version, but will find the old library version and error.

An entry in UPDATING to the effect that "pkg delete autogen" should by run
and then autogen should be reinstalled.

This does not apply up upgrading with pkg or building with poudriere.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: Updating Postfix

[@lbutlr]

On 21 Mar 2019, at 06:25, Carmel NY  wrote:
> I am just inquiring to find out if there is any specific reason for
> these ports not being updated. In the past, the releases and the
> FreeBSD ports system were kept virtually in sync.

There was some talk when 3.4.0 came out about withdrawing it, and then the 
.1-.4 updates came quite quickly.

I don't know, but I guess, this delayed the port maintainer from moving forward.


-- 
in the long run there's still time to change the road you're on


___
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"

Updating Postfix

[Carmel NY]

Both Postfix 3.4 stable release and Postfix 3.5 experimental release
were released over a month ago. In fact, the stable release is now at
Postfix 3.4.4.

The posts system still has postfix-3.3.3,1 as the stable release and
Postfix-3.4.20181202,5 as the development release.

I am just inquiring to find out if there is any specific reason for
these ports not being updated. In the past, the releases and the
FreeBSD ports system were kept virtually in sync.

-- 
Carmel
___
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: Updating the sysutils/paladin port

[Kurt Jaeger]

Hi!

> sysutils/paladin has version 2.0.0 available; the port could use updating.
> The PR is  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236111; hoping
> we can get a committer to look at it sometime soon.

Done.

-- 
p...@opsec.eu+49 171 3101372One year to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Updating the sysutils/paladin port

[Ryan Westlund]

sysutils/paladin has version 2.0.0 available; the port could use updating.
The PR is  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236111; hoping
we can get a committer to look at it sometime soon.
___
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: Updating perl

[Matthew Seaman]

On 14/12/2018 10:44, Carmel NY wrote:
> Using poudriere, I attempted to update my system to the new "perl 5.28". I
> made the necessary changes in the "make.conf" files and then attempted to run
> poudriere. At the very beginning of the run, poudriere issued a warning that
> "security/py-certbot | py36-certbot-0.29.1_1,1" failed. This is from the end
> of the log file:
> 
> ===
> ===
> ===>  Patching for py36-certbot-0.29.1_1,1
> ===>  Applying FreeBSD patches for py36-certbot-0.29.1_1,1
> Ignoring previously applied (or reversed) patch.
> 2 out of 2 hunks ignored--saving rejects to certbot/compat.py.rej
> => FreeBSD patch patch-certbot_compat.py failed to apply cleanly.
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/security/py-certbot
> =>> Cleaning up wrkdir
> ===>  Cleaning for py36-certbot-0.29.1_1,1
> build of security/py-certbot | py36-certbot-0.29.1_1,1 ended at Fri Dec 14
> 05:35:15 EST 2018 build time: 00:00:05
> !!! build failure encountered !!!
> 
> Has anyone else had this problem?
> 

Yeah -- I just committed the fixes for py-certbot for which you had been
testing.  What was committed was very slightly different to the patch
you tested.

You're seeing some sort of mismerge in your ports tree there.  You
should be able to fix it by:

   cd ${PORTSDIR}/security/py-certbot
   svn revert -R .

and then try rebuilding.  That is assuming you have the ports tree
checked out of SVN. Use something like 'git reset --hard' if you're a
git user.  Anything else, I don't actually know, but the main aim would
be to get rid of any local changes and resynch to the primary repository
contents.

Cheers,

Matthew








signature.asc
Description: OpenPGP digital signature

Re: Updating perl

[Kubilay Kocak]

On 14/12/2018 9:44 pm, Carmel NY wrote:

Using poudriere, I attempted to update my system to the new "perl 5.28". I
made the necessary changes in the "make.conf" files and then attempted to run
poudriere. At the very beginning of the run, poudriere issued a warning that
"security/py-certbot | py36-certbot-0.29.1_1,1" failed. This is from the end
of the log file:

===
===
===>  Patching for py36-certbot-0.29.1_1,1
===>  Applying FreeBSD patches for py36-certbot-0.29.1_1,1
Ignoring previously applied (or reversed) patch.
2 out of 2 hunks ignored--saving rejects to certbot/compat.py.rej
=> FreeBSD patch patch-certbot_compat.py failed to apply cleanly.
*** Error code 1

Stop.
make: stopped in /usr/ports/security/py-certbot
=>> Cleaning up wrkdir
===>  Cleaning for py36-certbot-0.29.1_1,1
build of security/py-certbot | py36-certbot-0.29.1_1,1 ended at Fri Dec 14
05:35:15 EST 2018 build time: 00:00:05
!!! build failure encountered !!!

Has anyone else had this problem?



Hi Carmel,

That was just reported here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234009

I'm trying to grok how this may be perl update related.

Can you try what I suggested in comment #1 and let me know (in the 
issue) how that goes.


./koobs
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Updating poudriere jail

[andrew clarke]

On Fri 2018-12-14 11:13:16 UTC+, Carmel NY (carmel...@outlook.com) wrote:

> ># build Postfix with Cyrus SASL support
> >mail_postfix_SET=SASL
> >
> >Of course, be sure to point your FreeBSD 12.0-REL systems to your new 12.0
> >repo, instead of your old 11.x repo.
> >
> >Regards
> >Andrew
> 
> You know, that there are both a:
> 
> Port:   postfix-current-sasl-3.4.20181202,5
> Path:   /usr/ports/mail/postfix-current-sasl
> Info:   Experimental Postfix version
> 
> and
> 
> Port:   postfix-sasl-3.3.2_1,1
> Path:   /usr/ports/mail/postfix-sasl
> Info:   Postfix with Cyrus SASL support
> 
> Why not just use one of them?

I had no idea until it was mentioned to me off-list earlier.

You learn something new every day :-)

Thanks,

Regards
Andrew
___
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: Updating poudriere jail

[Carmel NY]

On Fri, 14 Dec 2018 07:29:18 +1100, andrew clarke stated:

>On Thu 2018-12-13 19:43:30 UTC+, Carmel NY (carmel...@outlook.com) wrote:
>
>> I am using FreeBSD 11.2-RELEASE-p6. If I use freebsd-update to install the
>> new version 12, what do I have to do to update the poudriere jail? Plus,
>> if I do update, will I have to rebuild all of my installed applications?
>> 
>> Thanks :)  
>
>I found it simplest to create a new poudriere jail named 12amd64 to coincide
>with my existing 11amd64 jail.
>
>In my case the only port I build that needs non-standard options is
>mail/postfix, to enable Cyrus SASL support. Consequently I have this setting
>in /usr/local/etc/poudriere.d/make.conf (outside the jail) which from what I
>understand applies to both my 11amd64 and 12amd64 (and future) poudriere
>jails:
>
># build Postfix with Cyrus SASL support
>mail_postfix_SET=SASL
>
>Of course, be sure to point your FreeBSD 12.0-REL systems to your new 12.0
>repo, instead of your old 11.x repo.
>
>Regards
>Andrew

You know, that there are both a:

Port:   postfix-current-sasl-3.4.20181202,5
Path:   /usr/ports/mail/postfix-current-sasl
Info:   Experimental Postfix version

and

Port:   postfix-sasl-3.3.2_1,1
Path:   /usr/ports/mail/postfix-sasl
Info:   Postfix with Cyrus SASL support

Why not just use one of them?

-- 
Carmel
___
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"

Updating perl

[Carmel NY]

Using poudriere, I attempted to update my system to the new "perl 5.28". I
made the necessary changes in the "make.conf" files and then attempted to run
poudriere. At the very beginning of the run, poudriere issued a warning that
"security/py-certbot | py36-certbot-0.29.1_1,1" failed. This is from the end
of the log file:

===
===
===>  Patching for py36-certbot-0.29.1_1,1
===>  Applying FreeBSD patches for py36-certbot-0.29.1_1,1
Ignoring previously applied (or reversed) patch.
2 out of 2 hunks ignored--saving rejects to certbot/compat.py.rej
=> FreeBSD patch patch-certbot_compat.py failed to apply cleanly.
*** Error code 1

Stop.
make: stopped in /usr/ports/security/py-certbot
=>> Cleaning up wrkdir
===>  Cleaning for py36-certbot-0.29.1_1,1
build of security/py-certbot | py36-certbot-0.29.1_1,1 ended at Fri Dec 14
05:35:15 EST 2018 build time: 00:00:05
!!! build failure encountered !!!

Has anyone else had this problem?

-- 
Carmel
___
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: Updating poudriere jail

[Simon Wright]

On 14/12/2018 05:41, Kurt Jaeger wrote:


I am using FreeBSD 11.2-RELEASE-p6. If I use freebsd-update to install the
new version 12, what do I have to do to update the poudriere jail? Plus, if I
do update, will I have to rebuild all of my installed applications?


I had a jail '120' created as

poudriere jail -c -v 12.0-RC3 -a amd64 -j 120

I updated it with this:

poudriere jail -u -t 12.0-RELEASE -j 120


+1

This upgrade command line has worked for me since 10.x for major and 
minor upgrades. Yes you will have to let poudriere rebuild your apps 
since the build process will clean your pkg repro on any jail updates.


--
Simon Wright.
--
Simon Wright
Public key: http://www.santos-wright.net/pki/publickey.gpg



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Updating poudriere jail

[Kurt Jaeger]

Hi!

> I am using FreeBSD 11.2-RELEASE-p6. If I use freebsd-update to install the
> new version 12, what do I have to do to update the poudriere jail? Plus, if I
> do update, will I have to rebuild all of my installed applications?

I had a jail '120' created as

poudriere jail -c -v 12.0-RC3 -a amd64 -j 120

I updated it with this:

poudriere jail -u -t 12.0-RELEASE -j 120

-- 
p...@freebsd.org +49 171 3101372  2 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Updating poudriere jail

[andrew clarke]

On Thu 2018-12-13 19:43:30 UTC+, Carmel NY (carmel...@outlook.com) wrote:

> I am using FreeBSD 11.2-RELEASE-p6. If I use freebsd-update to install the
> new version 12, what do I have to do to update the poudriere jail? Plus, if I
> do update, will I have to rebuild all of my installed applications?
> 
> Thanks :)

I found it simplest to create a new poudriere jail named 12amd64 to coincide
with my existing 11amd64 jail.

In my case the only port I build that needs non-standard options is
mail/postfix, to enable Cyrus SASL support. Consequently I have this setting
in /usr/local/etc/poudriere.d/make.conf (outside the jail) which from what I
understand applies to both my 11amd64 and 12amd64 (and future) poudriere jails:

# build Postfix with Cyrus SASL support
mail_postfix_SET=SASL

Of course, be sure to point your FreeBSD 12.0-REL systems to your new 12.0 repo,
instead of your old 11.x repo.

Regards
Andrew
___
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: Updating poudriere jail

[Adam Weinberger]

On Thu, Dec 13, 2018 at 1:01 PM Carmel NY  wrote:
>
> On Thu, 13 Dec 2018 12:49:07 -0700, Adam Weinberger stated:
>
> >On Thu, Dec 13, 2018 at 12:43 PM Carmel NY  wrote:
> >>
> >> I am using FreeBSD 11.2-RELEASE-p6. If I use freebsd-update to install the
> >> new version 12, what do I have to do to update the poudriere jail? Plus,
> >> if I do update, will I have to rebuild all of my installed applications?
> >
> >It's not really possible to cleanly upgrade a poudriere jail to a new
> >major. You'll need to delete the jail and recreate it.
> >  poudriere jail -d -j $jailname
> >  poudriere jail -c -j $jailname -v 12.0-RELEASE
> >
> >If the jail name stays the same, it will retain all the options,
> >make.conf, and poudriere.conf. If the jail name has changed, you'll
> >most likely want to move those things over:
> >  cd /usr/local/etc/poudriere.d
> >  mv oldjailname-{make.conf,poudriere.conf,options,etc} newjailname-...
> >
> >You will, unfortunately, need to rebuild everything. After rebuilding,
> >be sure to run "pkg upgrade -f" BEFORE the final "freebsd-update
> >install"!
> >
> ># Adam
>
> I build my packages. Do I really have to do the "pkg upgrade -f" procedure?

Yeah, it is necessary. The packages that are on your system are linked
against the 11.2 libraries. Once you do the final "freebsd-update
install", those 11.2 libraries will disappear. As a result, every
package you have installed will break. Rebuild everything, then "pkg
upgrade -f" to reinstall all the packages using the newly built
versions. That way, nothing will break after the final freebsd-update
install.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.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"

Re: Updating poudriere jail

[Carmel NY]

On Thu, 13 Dec 2018 12:49:07 -0700, Adam Weinberger stated:

>On Thu, Dec 13, 2018 at 12:43 PM Carmel NY  wrote:
>>
>> I am using FreeBSD 11.2-RELEASE-p6. If I use freebsd-update to install the
>> new version 12, what do I have to do to update the poudriere jail? Plus,
>> if I do update, will I have to rebuild all of my installed applications?  
>
>It's not really possible to cleanly upgrade a poudriere jail to a new
>major. You'll need to delete the jail and recreate it.
>  poudriere jail -d -j $jailname
>  poudriere jail -c -j $jailname -v 12.0-RELEASE
>
>If the jail name stays the same, it will retain all the options,
>make.conf, and poudriere.conf. If the jail name has changed, you'll
>most likely want to move those things over:
>  cd /usr/local/etc/poudriere.d
>  mv oldjailname-{make.conf,poudriere.conf,options,etc} newjailname-...
>
>You will, unfortunately, need to rebuild everything. After rebuilding,
>be sure to run "pkg upgrade -f" BEFORE the final "freebsd-update
>install"!
>
># Adam

I build my packages. Do I really have to do the "pkg upgrade -f" procedure?

-- 
Carmel
___
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: Updating poudriere jail

[Adam Weinberger]

On Thu, Dec 13, 2018 at 12:43 PM Carmel NY  wrote:
>
> I am using FreeBSD 11.2-RELEASE-p6. If I use freebsd-update to install the
> new version 12, what do I have to do to update the poudriere jail? Plus, if I
> do update, will I have to rebuild all of my installed applications?

It's not really possible to cleanly upgrade a poudriere jail to a new
major. You'll need to delete the jail and recreate it.
  poudriere jail -d -j $jailname
  poudriere jail -c -j $jailname -v 12.0-RELEASE

If the jail name stays the same, it will retain all the options,
make.conf, and poudriere.conf. If the jail name has changed, you'll
most likely want to move those things over:
  cd /usr/local/etc/poudriere.d
  mv oldjailname-{make.conf,poudriere.conf,options,etc} newjailname-...

You will, unfortunately, need to rebuild everything. After rebuilding,
be sure to run "pkg upgrade -f" BEFORE the final "freebsd-update
install"!

# Adam



-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.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"

Updating poudriere jail

[Carmel NY]

I am using FreeBSD 11.2-RELEASE-p6. If I use freebsd-update to install the
new version 12, what do I have to do to update the poudriere jail? Plus, if I
do update, will I have to rebuild all of my installed applications?

Thanks :)

-- 
Carmel
___
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"

Updating "mysql80-server" port

[Carmel NY]

My daily security run summary includes the following:

Checking for packages with security vulnerabilities:
Database fetched: Sun Dec  9 03:18:49 EST 2018
mysql80-server-8.0.12_2

This has been included in the report for quite some time now. After doing
some quick checking, I find that MySQL 8.0.13 has been available
since 2018-10-22. I was just wondering why, especially if there is a security
problem, this port has not been updated?

Thanks!

-- 
Carmel
___
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: Unable to update repository FreeBSD Error updating repositories

[Kurt Jaeger]

Hi!

> > Soon, although it's unclear, when. Give the team a few more days or
> > build yourself your own repo using poudriere ?

> poudriere - or synth, which might be more user-friendly?

I'm using poudriere, because synth is limited to those architectures
where ada is available.

-- 
p...@opsec.eu+49 171 31013722 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Unable to update repository FreeBSD Error updating repositories

[Rebecca Cran via freebsd-ports]

On 10/22/18 9:39 AM, Kurt Jaeger wrote:



Soon, although it's unclear, when. Give the team a few more days or
build yourself your own repo using poudriere ?



poudriere - or synth, which might be more user-friendly?


--

Rebecca Cran

___
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: Unable to update repository FreeBSD Error updating repositories

[Walter Schwarzenfeld]

Andy opened a PR

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232530

___
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: Unable to update repository FreeBSD Error updating repositories

[Kurt Jaeger]

Hi!

> is "translated" in ...pkg.FreeBSD.org/FreeBSD:13:amd64/latest...
> but currently http://pkg.FreeBSD.org/ hasn't "FreeBSD:13:amd64".

> The question is: When will be it added?

Soon, although it's unclear, when. Give the team a few more days or
build yourself your own repo using poudriere ?

-- 
p...@opsec.eu+49 171 31013722 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Unable to update repository FreeBSD Error updating repositories

[Alfonso Siciliano]

Hello,

I have the same problem:

> Just upgraded a machine to 13-current:
> 
> FreeBSD  13.0-CURRENT FreeBSD 13.0-CURRENT #18 r339556: Sun Oct 21 

> # pkg info
> pkg: Warning: Major OS version upgrade detected.  Running "pkg-static 
> install -f pkg" recommended
> 
> What does "Warning: Major OS version upgrade detected" mean?  And what 
> should you do about it?  Thanks in advance, appreciate any help.
> 
> # pkg-static install -f pkg
> pkg-static: Warning: Major OS version upgrade detected.  Running 
> "pkg-static install -f pkg" recommended
> Updating FreeBSD repository catalogue...
> pkg-static: Repository FreeBSD load error: access repo 
> file(/var/db/pkg/repo-FreeBSD.sqlite) failed: No such file or directory
> pkg-static: http://pkg.FreeBSD.org/FreeBSD:13:amd64/latest/meta.txz: Not 
> Found
> repository FreeBSD has no meta file, using default settings
> pkg-static: 
> http://pkg.FreeBSD.org/FreeBSD:13:amd64/latest/packagesite.txz: Not Found
> Unable to update repository FreeBSD
> Error updating repositories!
> 


Moreover

/usr/sbin/pkg bootstrap -f 

gives an analogue error.

The reason is inside the file:  "/etc/pkg/repos/FreeBSD.conf", the line : 

... pkg.FreeBSD.org/${ABI}/latest/ ...


is "translated" in ...pkg.FreeBSD.org/FreeBSD:13:amd64/latest...
but currently http://pkg.FreeBSD.org/ hasn't "FreeBSD:13:amd64".

The question is: When will be it added?
(Meanwhile I/you can use the ports)


Regards
Alfonso

--- 
Alfonso S. Siciliano 
   http://alfix.gitlab.io
___
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: Unable to update repository FreeBSD Error updating repositories

[Walter Schwarzenfeld]

This

http://pkg.FreeBSD.org/FreeBSD:13:amd64/latest/  

side seems not to exist on http://pkg.freebsd.org/.

Maybe, you try to change the ABI in your /etc/pkg/repos/FreeBSD.conf to 12
install "pkg" and if it is successful recompile it in the port.

___
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"

Unable to update repository FreeBSD Error updating repositories

[AN]

i:

Just upgraded a machine to 13-current:

FreeBSD  13.0-CURRENT FreeBSD 13.0-CURRENT #18 r339556: Sun Oct 21 
17:33:46 EDT 2018 root@sparc:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL

amd64 130


I deleted /usr/ports and did a fresh svnlite co into /usr/ports.

# pkg info
pkg: Warning: Major OS version upgrade detected.  Running "pkg-static 
install -f pkg" recommended


What does "Warning: Major OS version upgrade detected" mean?  And what 
should you do about it?  Thanks in advance, appreciate any help.


# pkg-static install -f pkg
pkg-static: Warning: Major OS version upgrade detected.  Running 
"pkg-static install -f pkg" recommended

Updating FreeBSD repository catalogue...
pkg-static: Repository FreeBSD load error: access repo 
file(/var/db/pkg/repo-FreeBSD.sqlite) failed: No such file or directory
pkg-static: http://pkg.FreeBSD.org/FreeBSD:13:amd64/latest/meta.txz: Not 
Found

repository FreeBSD has no meta file, using default settings
pkg-static: 
http://pkg.FreeBSD.org/FreeBSD:13:amd64/latest/packagesite.txz: Not Found

Unable to update repository FreeBSD
Error updating repositories!

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Wrong hint while updating p5-Net-SMTP-SSL

[Herbert J. Skuhra]

On Mon, Aug 20, 2018 at 11:53:07AM +0200, free...@doom-labs.net wrote:
> Ahoi!
> 
> If you try upgrading mentioned port you get:
> ---8<--
> 
> ===>>> p5-Net-SMTP-SSL-1.04
> 
> ===>>> The mail/p5-Net-SMTP-SSL port has been deleted: Has expired:
> Deprecated by upstream, use Net::SMTP instead
> ===>>> Aborting update
> ---8<---
> 
> I guess this should be either NET:SMTPS or (even better) mail/p5-Net-SMTPS

Why?

https://perldoc.perl.org/5.24.0/Net/SMTP.html
https://perldoc.perl.org/5.26.0/Net/SMTP.html

Description:

This module implements a client interface to the SMTP and ESMTP
protocol, enabling a perl5 application to talk to SMTP servers. This
documentation assumes that you are familiar with the concepts of the
SMTP protocol described in RFC2821. With IO::Socket::SSL installed it
also provides support for implicit and explicit TLS encryption, i.e.
SMTPS or SMTP+STARTTLS.

-- 
Herbert
___
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"

Wrong hint while updating p5-Net-SMTP-SSL

[freebsd]

Ahoi!

If you try upgrading mentioned port you get:
---8<--

===>>> p5-Net-SMTP-SSL-1.04

===>>> The mail/p5-Net-SMTP-SSL port has been deleted: Has expired: 
Deprecated by upstream, use Net::SMTP instead

===>>> Aborting update
---8<---

I guess this should be either NET:SMTPS or (even better) 
mail/p5-Net-SMTPS 


Cheers,

Ekkehard 'Ekki' Gehm

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Request clear steps for updating own port

[blubee blubeeme]

On Mon, May 21, 2018, 07:49 Mateusz Piotrowski <0...@freebsd.org> wrote:

> On Mon, 21 May 2018 04:47:56 +0530
> Manish Jain <jude.obsc...@yandex.com> wrote:
>
> >Hi,
> >
> >I have an active port (sysutils/mkdesktop) which I maintain myself.
> >
> >A few days back, I had to upgrade the port from 1.6 to 1.7 so as to
> >reflect new names of kde4 packages.
> >
> >I seem to have completely lost memory of what I have to do to get the
> >port updated properly in FreeBSD ports. Can someone be kind enough to
> >guide me what steps are needed for updating one's own port?
> >
> >My port uses GitHub and is located at:
> >https://github.com/bourne-again/mkdesktop
> >
> >Essentially, I have an updated Makefile/distinfo which I need to get
> >merged into FreeBSD ports.
> >
> >I have updated the shar attachment for the port at the URL where the
> >port was originally submitted:
> >
> >https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221370
>
> I'd open a new issue if you wish to update your port.
>
> The title of the issue could be something like:
>
> sysutils/mkdesktop: Update to 1.7
>
> Make sure to upload the diff with the new version of your port. Shar is
> OK, I guess, but a patch is much much better.
>
> The handbook has some useful hints as well probably:
>
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/port-upgrading.html
>
> Good luck!
>
> Mateusz
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
Create a diff
Go to FreeBSD bugzilla file a new bug report with diff.
Wait for a committer to merge it for you.
Profit!

Best,
Owen

>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Request clear steps for updating own port

[Mateusz Piotrowski]

On Mon, 21 May 2018 04:47:56 +0530
Manish Jain <jude.obsc...@yandex.com> wrote:

>Hi,
>
>I have an active port (sysutils/mkdesktop) which I maintain myself.
>
>A few days back, I had to upgrade the port from 1.6 to 1.7 so as to
>reflect new names of kde4 packages.
>
>I seem to have completely lost memory of what I have to do to get the
>port updated properly in FreeBSD ports. Can someone be kind enough to
>guide me what steps are needed for updating one's own port?
>
>My port uses GitHub and is located at:
>https://github.com/bourne-again/mkdesktop
>
>Essentially, I have an updated Makefile/distinfo which I need to get
>merged into FreeBSD ports.
>
>I have updated the shar attachment for the port at the URL where the
>port was originally submitted:
>
>https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221370

I'd open a new issue if you wish to update your port.

The title of the issue could be something like:

sysutils/mkdesktop: Update to 1.7

Make sure to upload the diff with the new version of your port. Shar is
OK, I guess, but a patch is much much better.

The handbook has some useful hints as well probably:
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/port-upgrading.html

Good luck!

Mateusz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Request clear steps for updating own port

[Manish Jain]

Hi,

I have an active port (sysutils/mkdesktop) which I maintain myself.

A few days back, I had to upgrade the port from 1.6 to 1.7 so as to 
reflect new names of kde4 packages.


I seem to have completely lost memory of what I have to do to get the 
port updated properly in FreeBSD ports. Can someone be kind enough to 
guide me what steps are needed for updating one's own port?


My port uses GitHub and is located at:
https://github.com/bourne-again/mkdesktop

Essentially, I have an updated Makefile/distinfo which I need to get 
merged into FreeBSD ports.


I have updated the shar attachment for the port at the URL where the 
port was originally submitted:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221370

But it has been a few days since the shar attachment was updated, and 
fetch continues to get the outdated versions of files for the port.


Is there anything else I should be doing to get the updated version of 
the port synced into FreeBSD mainstream ?


Thanks for any help.
Manish Jain
___
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: Updating www/py-recaptcha

[Matthew Seaman]

On 22/04/2018 22:14, Dan Mahoney (Gushi) wrote:
> 2) I can't figure out how to tell what packages (if any) depend on this
> -- I know how to do it with *installed* packages, but not *all packages
> total*, so I know who to reach out to for having them update.  Can
> someone clue me in?

  cd /usr/ports
  make fetchindex
  grep py..-recaptcha INDEX-* | less -S

- or -

  cd /usr/ports
  grep -r www/py-recaptcha .

However, it looks like nothing depends specifically on that package.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: Updating www/py-recaptcha

[Philip Paeps]

On 2018-04-23 01:44:27 (+0430), Dan Mahoney (Gushi) wrote:
This port is pretty much useless as a dependency, since Google has now 
deprecated the v1 captcha (which is all this code can do).


Oh wow.  I completely forgot I'm maintaining this.  I haven't had a use 
for it in ages.


It's been fixed here: 
https://github.com/redhat-infosec/python-recaptcha


(I.e. the module name this code generates uses the same import name, 
but any underlying code still needs to be slightly tweaked to generate 
a v2 captcha).


Questions:

1) Do you want a patch -- or would this just be considered a new port 
since the master site would be different?


If the original upstream is abandoned and the new upstream uses the same 
name and presents the same interface to consumers, we can keep the same 
port.  We may need to bump the epoch if the version numbering is 
different.  If the new port is is completely different, it's probably 
better to get rid of this one (after a suitable deprecation period).


Patches are always welcome.  If you're interested in this port, feel 
free to set yourself as MAINTAINER.  I have no use for this at the 
moment.  I'm happy to review and commit your changes though.


2) I can't figure out how to tell what packages (if any) depend on 
this -- I know how to do it with *installed* packages, but not *all 
packages total*, so I know who to reach out to for having them update. 
 Can someone clue me in?


Try `pkg rquery %ro py27-recaptcha`.

Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information
___
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"

Updating www/py-recaptcha

[Dan Mahoney (Gushi)]

All,

This port is pretty much useless as a dependency, since Google has now 
deprecated the v1 captcha (which is all this code can do).


It's been fixed here: https://github.com/redhat-infosec/python-recaptcha

(I.e. the module name this code generates uses the same import name, but 
any underlying code still needs to be slightly tweaked to generate a v2 
captcha).


Questions:

1) Do you want a patch -- or would this just be considered a new port 
since the master site would be different?


2) I can't figure out how to tell what packages (if any) depend on this -- 
I know how to do it with *installed* packages, but not *all packages 
total*, so I know who to reach out to for having them update.  Can someone 
clue me in?


-Dan

--


Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.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"

Re: UPDATING RSS feed

[Andrea Venturoli]

On 03/31/18 19:34, Kevin Oberman wrote:


I moved to:
http://updating.kojevnikov.com/


Thanks a lot!

 bye
av.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Perl version change and ports/UPDATING

[David Wolfskill]

On Sat, Mar 31, 2018 at 04:23:54PM -0700, Kevin Oberman wrote:
> On Sat, Mar 31, 2018 at 7:25 AM, David Wolfskill <da...@catwhisker.org>
> wrote:
> ... 
> > But "pkg updating -i" fails to display the 20180330 entry for me;
> > it does show entries for some(?) other ports I have installed:
> ...
> > Is the above a demostration of a problem with "pkg updating"?
> > Something else?
> ...
> I suspect thre issue is the handing of the wildcard (lang/perl5*). Either
> it's a bug or wildcards should not be allowed in UPDATING. There are LOTS
> of entries with asterisks, though, ome rather more complex such as:
> 20180308:
>   AFFECTS: */php* */pecl* */pear*
> BTW, that one should show up in "pkg updating -i" and does not, either.
> 

I finally(!) got around to unpacking the distribution files for
pkg-1.10.5; looking at src/updating.c, "pkg updating" uses either
strcasestr() or strstr() (depending on whether or not -i is specified)
for matching the origins of installed ports against the "AFFECTS" lines
in ports/UPDATING.

I see no code that would support anything other than literal string
matches -- no attempts to specify/use meta-characters; no globs;
no regular expressions.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
An investigator who doesn't make a perp nervous isn't doing his job.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Perl version change and ports/UPDATING

[Kevin Oberman]

On Sat, Mar 31, 2018 at 7:25 AM, David Wolfskill <da...@catwhisker.org>
wrote:

> While the actual change to the Perl version works fine for me, I
> find that invoking "pkg updating" fails to display the 20180330
> ports/UPDATING entry.  I got lucky, because I found out about the
> change a different way.
>
> I maintain /usr/ports as an SVN working copy, using a local private
> mirror (updated nightly):
>
> g1-215(11.1-S)[1] svn info /usr/ports/
> Path: /usr/ports
> Working Copy Root Path: /usr/ports
> URL: file:///svn/freebsd/ports/head
> Relative URL: ^/head
> Repository Root: file:///svn/freebsd/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 466037
> Node Kind: directory
> Schedule: normal
> Last Changed Author: mandree
> Last Changed Rev: 466037
> Last Changed Date: 2018-03-31 03:08:17 -0700 (Sat, 31 Mar 2018)
>
> g1-215(11.1-S)[2]
>
>
> The 20180330 entry does exist in /usr/ports/UPDATIMG:
>
> g1-215(11.1-S)[2] grep -i -B 2 -A 2 perl /usr/ports/UPDATING | head
>
> 20180330:
>   AFFECTS: users of lang/perl5*
>   AUTHOR: m...@freebsd.org
>
>   The default Perl version has been switched to Perl 5.26.  If you are
> using
>   binary packages to upgrade your system, you do not have anything to do,
> pkg
>   upgrade will do the right thing.  For the other people, follow the
> --
>
> g1-215(11.1-S)[3]
>
>
> I have Perl installed:
>
> g1-215(11.1-S)[3] pkg info -o perl5\*
> perl5-5.26.1   lang/perl5.26
> g1-215(11.1-S)[4]
>
>
> But "pkg updating -i" fails to display the 20180330 entry for me;
> it does show entries for some(?) other ports I have installed:
>
> g1-215(11.1-S)[4] pkg updating -i | head
> 20180319:
>   AFFECTS: users of dns/dnsmasq
>   AUTHOR: mand...@freebsd.org
>
>   Note that with dnsmasq 2.79, some parts of the interface have changed in
> an
>   incompatible way versus previous versions. This comprises changed
> recursion
>   behaviour, signature support, a change for SIGINT (vs. SIGHUP) behaviour.
>
>   Note especially that dnsmasq will no longer answer non-recursive queries
>   unless it is marked authoritative!  Be sure to see the manual page for
> the
> g1-215(11.1-S)[5]
>
>
> Is the above a demostration of a problem with "pkg updating"?
> Something else?
>
> Thanks!
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> An investigator who doesn't make a perp nervous isn't doing his job.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
>

I also don't see the perl message. The newest entry I see is:
20180214:
  AFFECTS: users of lang/ruby23
I have no installed ports with newer update messages installed.

I suspect thre issue is the handing of the wildcard (lang/perl5*). Either
it's a bug or wildcards should not be allowed in UPDATING. There are LOTS
of entries with asterisks, though, ome rather more complex such as:
20180308:
  AFFECTS: */php* */pecl* */pear*
BTW, that one should show up in "pkg updating -i" and does not, either.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: UPDATING RSS feed

[Kevin Oberman]

On Fri, Mar 30, 2018 at 9:45 AM, Andrea Venturoli <m...@netfence.it> wrote:

> Hello.
>
> I used to read ports' UPDATING via RSS, but now the feed I was using (from
> versia) seems to be gone.
>
> Anyone knows of another one?
>
> I looked into FreshPorts, but didn't find a way to get this specific feed.
>
>  bye & Thanks
> av.
>

I moved to:
http://updating.kojevnikov.com/
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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"

UPDATING RSS feed

[Andrea Venturoli]

Hello.

I used to read ports' UPDATING via RSS, but now the feed I was using 
(from versia) seems to be gone.


Anyone knows of another one?

I looked into FreshPorts, but didn't find a way to get this specific feed.

 bye & Thanks
av.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Perl version change and ports/UPDATING

[David Wolfskill]

While the actual change to the Perl version works fine for me, I
find that invoking "pkg updating" fails to display the 20180330
ports/UPDATING entry.  I got lucky, because I found out about the
change a different way.

I maintain /usr/ports as an SVN working copy, using a local private
mirror (updated nightly):

g1-215(11.1-S)[1] svn info /usr/ports/
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: file:///svn/freebsd/ports/head
Relative URL: ^/head
Repository Root: file:///svn/freebsd/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 466037
Node Kind: directory
Schedule: normal
Last Changed Author: mandree
Last Changed Rev: 466037
Last Changed Date: 2018-03-31 03:08:17 -0700 (Sat, 31 Mar 2018)

g1-215(11.1-S)[2] 


The 20180330 entry does exist in /usr/ports/UPDATIMG:

g1-215(11.1-S)[2] grep -i -B 2 -A 2 perl /usr/ports/UPDATING | head

20180330:
  AFFECTS: users of lang/perl5*
  AUTHOR: m...@freebsd.org

  The default Perl version has been switched to Perl 5.26.  If you are using
  binary packages to upgrade your system, you do not have anything to do, pkg
  upgrade will do the right thing.  For the other people, follow the
--

g1-215(11.1-S)[3] 


I have Perl installed:

g1-215(11.1-S)[3] pkg info -o perl5\*
perl5-5.26.1   lang/perl5.26
g1-215(11.1-S)[4] 


But "pkg updating -i" fails to display the 20180330 entry for me;
it does show entries for some(?) other ports I have installed:

g1-215(11.1-S)[4] pkg updating -i | head
20180319:
  AFFECTS: users of dns/dnsmasq
  AUTHOR: mand...@freebsd.org

  Note that with dnsmasq 2.79, some parts of the interface have changed in an
  incompatible way versus previous versions. This comprises changed recursion
  behaviour, signature support, a change for SIGINT (vs. SIGHUP) behaviour.

  Note especially that dnsmasq will no longer answer non-recursive queries
  unless it is marked authoritative!  Be sure to see the manual page for the
g1-215(11.1-S)[5] 


Is the above a demostration of a problem with "pkg updating"?
Something else?

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
An investigator who doesn't make a perp nervous isn't doing his job.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: A note on updating security/gnupg20 -> gnupg

[Adam Weinberger]

On 7 Jan, 2018, at 7:33, David Wolfskill <da...@catwhisker.org> wrote:

I had been using security/gnupg20 with mail/mutt, based on a
misunderstanding on my part (back when the security/gnupg20 port was
created).

Now that security/gnupg20 has been expired and removed, I had motivation
to look into the situation in more detail; I found that security/gnupg
(now at 2.2.4) works fine with mail/mutt -- if I made a change (in
~/.muttrc) to the way gpg is invoked.  E.g., I changed:

set pgp_decrypt_command="gpg2 --passphrase-fd 0 --no-verbose --batch  
--output - %f"


to

pgp_decrypt_command="gpg2 %?p?--passphrase-fd 0 --pinentry-mode=loopback?  
--no-verbose --batch --output - %f"


The salient differences appear to be the insertion of "%?p?" before
"--passphrase-fd 0" and the insertion of "--pinentry-mode=loopback?".


The changes to ~/.muttrc appear to have been sufficient (in my case) for
mutt to be able to use security/gnupg (vs. security/gnupg20) for
encryption and decryption of PGP-compatible email messages.


Finally, on the actual replacement: I did this on three systems; on two
of those, I update ports via portmaster; on the other, I update them
from a locally-built repository (via "pkg upgrade").

For the systems using portmaster, "portmaster -o security/gnupg
gnupg20-2.0.30_2" worked well.   (My thanks to Doug Barton and Stefan
Esser!)

When I ran "pkg upgrade" on the system I update that way, there was
no indication that the status of security/gnupg* had changed since
the previous update (one week ago -- shortly before the removal of
security/gnupg20).  I ended up performing "pkg delete security/gnupg20",
followed by "pkg install security/gnupg" -- which worked.  (I had
previously updated the list of packages to build on my build machine,
to replace security/gnupg20 by security/gnupg.)

My concern about that last point is that if I were only updating ports
via "pkg upgrade", I would not have known that security/gnupg20 no
longer existed (well, unless I read the svn-ports-head list, or polled
the svn log for ports/security/Makefile -- or some other
similarly-unlikely activity for someone updating via packages only).

Perhaps I'm overlooking something.


In any case: If you use mutt with security/gnupg20 and migrate to
security/gnupg, and find that you cannot decrypt encrypted messages any
more, you should check your ~/.muttrc: you probably need to change the
"gpg" (or "gpg2") invocations; in my experience, that is a necessary and
sufficient change to make encryption and decryption work again.

Peace,
david


I can't speak much to the pkg upgrade process, but the switch should happen
pretty transparently.

As for the mutt invocation, I've added your muttrc line to ports/UPDATING.
I strongly recommend using security/gpgme instead unless you specifically
need gpg called in a nonstandard way.

# Adam


--
Adam Weinberger
ad...@adamw.org
http://www.adamw.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"

A note on updating security/gnupg20 -> gnupg

[David Wolfskill]

I had been using security/gnupg20 with mail/mutt, based on a
misunderstanding on my part (back when the security/gnupg20 port was
created).

Now that security/gnupg20 has been expired and removed, I had motivation
to look into the situation in more detail; I found that security/gnupg
(now at 2.2.4) works fine with mail/mutt -- if I made a change (in
~/.muttrc) to the way gpg is invoked.  E.g., I changed:

set pgp_decrypt_command="gpg2 --passphrase-fd 0 --no-verbose --batch --output - 
%f"

to

pgp_decrypt_command="gpg2 %?p?--passphrase-fd 0 --pinentry-mode=loopback? 
--no-verbose --batch --output - %f"

The salient differences appear to be the insertion of "%?p?" before
"--passphrase-fd 0" and the insertion of "--pinentry-mode=loopback?".


The changes to ~/.muttrc appear to have been sufficient (in my case) for
mutt to be able to use security/gnupg (vs. security/gnupg20) for
encryption and decryption of PGP-compatible email messages.


Finally, on the actual replacement: I did this on three systems; on two
of those, I update ports via portmaster; on the other, I update them
from a locally-built repository (via "pkg upgrade").

For the systems using portmaster, "portmaster -o security/gnupg
gnupg20-2.0.30_2" worked well.   (My thanks to Doug Barton and Stefan
Esser!)

When I ran "pkg upgrade" on the system I update that way, there was
no indication that the status of security/gnupg* had changed since
the previous update (one week ago -- shortly before the removal of
security/gnupg20).  I ended up performing "pkg delete security/gnupg20",
followed by "pkg install security/gnupg" -- which worked.  (I had
previously updated the list of packages to build on my build machine,
to replace security/gnupg20 by security/gnupg.)

My concern about that last point is that if I were only updating ports
via "pkg upgrade", I would not have known that security/gnupg20 no
longer existed (well, unless I read the svn-ports-head list, or polled
the svn log for ports/security/Makefile -- or some other
similarly-unlikely activity for someone updating via packages only).

Perhaps I'm overlooking something.


In any case: If you use mutt with security/gnupg20 and migrate to
security/gnupg, and find that you cannot decrypt encrypted messages any
more, you should check your ~/.muttrc: you probably need to change the
"gpg" (or "gpg2") invocations; in my experience, that is a necessary and
sufficient change to make encryption and decryption work again.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
A "Birther" calls himself a "a very stable genius" -- same level of truth? 

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature