Re: FreeBSD Port: virtualbox-ose-6.1.20 outdated

[Guido Falsi via freebsd-ports]

On 01/05/21 01:17, Dutchman01 via freebsd-emulation wrote:

bugfix release 6.1.22 is released!

  


There is need to upgrade from 6.1.20 to 6.1.22


This is known, automatic notifications already reached the mailing list 
yesterday at 8:55 UTC


The notification actually contained an error and I already reacted to 
that by adding the PORTSCOUT variable to the legacy ports.


I'm testing the new release and should be able to commit the update to 
the tree later. It looks like a n easy update, but testing this ports 
requires time. Time to compile it (and it's heavy dependencies) on 
multiple OS version, time to run it to verify there are no big regressions.


This time the update looks easy with no need to modify patches or add 
new ones, but this looks like an exception not the rule.


When someone (like me this time) is able to start working on the update 
right away it's anyway impossible to get it in the tree in less than 
24/48 hours in the best scenarios. Much more it the update proves 
difficult due to incompatibilities or need to modify patches.


It could also happen for committers to be all busy or unavailable so a 
week or two could also happen.


Anyway, as stated, I should be able to commit the update today.

--
Guido Falsi 
___
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: net/openldap24-server: stage/runaway , building forever

[Guido Falsi via freebsd-ports]

On 09/04/21 11:56, O. Hartmann wrote:

On Fri, 9 Apr 2021 10:16:27 +0200 (CEST)
Ronald Klop  wrote:


Hi,

The official pkg builders are also stuck for 14-CURRENT. Although at a
different port sysutils/msktutil.

See main-amd64 at https://pkg-status.freebsd.org/builds?type=package

It is stuck in "stage/runaway" for 61 hours now.
http://beefy18.nyi.freebsd.org/build.html?mastername=main-amd64-default=p569609_s5b3b19db73
(ipv6 only)

NB: I'm not involved in the pkg building cluster.

Regards,
Ronald.


Van: "O. Hartmann" 
Datum: vrijdag, 9 april 2021 07:27
Aan: FreeBSD Ports 
Onderwerp: Re: poudriere: net/openldap24-server: stage/runaway , building
forever


On Fri, 9 Apr 2021 06:17:03 +0200
"Hartmann, O."  wrote:


Recent CURRENT host (FreeBSD 14.0-CURRENT #26 main-n245806-4d221f59b85:
Sat Apr  3 06:43:44 CEST 2021 amd64), poudriere CURRENT jail at
14.0-CURRENT 147 amd64 from 2021-04-08 05:25:38. It seems that the
recent CURRENT does have a serious problem when building
net/openldap24-server. The build process gets stuck with staging and is
marked "runaway":

[head-amd64-head-default] [2021-04-08_13h56m41s] [parallel_build:] Queued:
1847 Built: 63 Failed: 17   Skipped: 1759 Ignored: 8Tobuild: 0
Time: 13:26:35 [01]: net/openldap24-server |
openldap-sasl-server-2.4.58 stage/runaway (06:28:32 / 08:41:16)

Also, on jails (recent CURRENT) serving as OpenLDAP server (also recent
taken from git /usr/ports, branch main), run into a serious problem
starting slapd, when starting slapd and the process is reporting checking
configuration, it freezes forever. Putting slapd into debug mode doesn't
help, since the freeze is quite early.

Does anybody know what the reason for this strange behaviour is on
CURRENT? All CURRENT servers are affected (almost all the same revision
as shown above)?

Thanks in advance,

O. Hartmann


Short update, another host is stuck at the very same point, host's CURRENT
is at FreeBSD 14.0-CURRENT #2 main-n245870-86a52e262a6: Wed Apr  7 13:57:20
CEST 2021 amd64, it's jails is taken from the same source.

The process is stuck at staging and took 34 hours ... never seen before:


[...]
[09:05:25] [03] [02:13:44] Finished net/openldap24-server |
openldap-sasl-server-2.4.58: Failed: stage/runaway load: 10.39  cmd: awk
24374 [running] 0.06r 0.00u 0.00s 0% 3420k [headamd64-head-default]
[2021-04-07_12h26m18s] [parallel_build:] Queued: 3298 Built: 2123 Failed: 7
Skipped: 1161 Ignored: 7Tobuild: 0 Time: 40:52:34 [03]:
net/openldap24-server | openldap-sasl-server-2.4.58 stage/runaway
(31:48:30 / 34:01:11) [40:52:52] Logs:
/pool/poudriere/data/logs/bulk/headamd64-head-default/2021-04-07_12h26m18s
___


[...]

It seems, that jails on 14-CURRENT do have a strange and malfunctional
behaviour now.


Most probably related to commit d36d68161517 check the thread at [1].

A solution is being discussed in D29623 at [2].


[1] 
https://lists.freebsd.org/pipermail/dev-commits-src-all/2021-April/005159.html


[2] https://reviews.freebsd.org/D29623

--
Guido Falsi 
___
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: Portsbase and maildir

[Guido Falsi via freebsd-ports]

On 08/04/21 07:27, Jim Trigg wrote:
I am going to submit that PORTSBASE should be something other than 
/usr/local/. My current preference (though not solid) is /ports/. I 
would like to reclaim /usr/local for true local (site-based, not 
distribution-based) things. (Example: local [site-based] scripts in 
/usr/local/s?bin/.)


Not sure if PORTSBASE is the name of what you mean, Looks like you mean 
PREFIX and LOCALBASE. You can redefine those if you want your ports to 
be installed in a different path than the default.




On a related note, I would like to see maildirmake separated out as a 
port of its own on which ports supporting Maildir depend. That way we 
avoid clunkiness like "/usr/local/bin/maildrop-maildirmake". (The first 
point most recently evidenced itself as "where do I put a symbolic link 
to maildrop-maildirmake called maildirmake?".)


As the maintainer of maildrop and other related ports, I am installing 
it like that to avoid conflicts with other ports installing the same thing.


Please note that mail/courier-imap installs it as bin/maildirmake. 
ports/pkg do not provide an official way to create symlinks, anyway the 
two executables are completely equivalent.



Upstream does not provide maildirmake as a separate package and I'm only 
following upstream practices. As I stated in the past, my opinion is 
that ports is just that, ports, not a place for original development.


If you'd like to extract maildirmake from the courier ports as a 
standalone package I have no objection, you can do that and submit a 
port of the result, providing upstream tarball and all.


--
Guido Falsi 
___
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 and gitup

[Guido Falsi via freebsd-ports]

On 05/04/21 23:26, Jose Quinteiro wrote:

On 4/4/21 7:35 AM, Carmel wrote:

On Sat, 3 Apr 2021 12:18:27 +, Rene Ladan stated:
...
Is or will poudriere default to using net/gitup in FreeBSD 13? Is there
a way to configure it in the "poudriere.conf" file?



There's a "git" option for the "-m method" command-line switch of
poudriere-ports(8). This option is used to specify which method to use
to create a ports tree.

I don't have any experience with it because I use "-m null" to have
Poudriere use a Ports tree I maintain manually with git.


It performs a shallow clone, not getting all history (similar to what 
gitup does) should work with a command line like this:


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


then use following command to update:

poudriere ports -u -p freebsd

--
Guido Falsi 
___
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: No update for a day on ports?

[Guido Falsi via freebsd-ports]

On 03/04/21 18:10, LuMiWa via freebsd-ports wrote:


It is not good. The last was I did red was "portsnap" stay still for
awhile. I  am portsnap and portmaster user for years. Where should I
find information what will happened with /usr/ports. Will gitup just
replace, update? I am using FreeBSD 13.0-RC5.
Thank you.



I have no definitive information regarding portsnap. I only remember 
reading a comment in the last few days to the effect of it being 
discontinued and suggested a replacement, but I could be wrong about this.


I've not been using it for a while and I have not followed news about it.

--
Guido Falsi 
___
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: No update for a day on ports?

[Guido Falsi via freebsd-ports]

On 03/04/21 13:50, The Doctor via freebsd-ports wrote:

On Sat, Apr 03, 2021 at 11:28:23AM +0200, Guido Falsi wrote:

On 03/04/21 02:24, The Doctor wrote:

On Sat, Apr 03, 2021 at 02:05:45AM +0200, Guido Falsi wrote:

On 03/04/21 01:35, The Doctor wrote:

On Sat, Apr 03, 2021 at 12:35:57AM +0200, Guido Falsi wrote:

On 02/04/21 23:16, The Doctor via freebsd-ports wrote:

On Fri, Apr 02, 2021 at 04:45:00PM +0200, Guido Falsi via freebsd-ports wrote:

On 02/04/21 15:44, The Doctor via freebsd-ports wrote:

On Fri, Apr 02, 2021 at 08:55:00AM +0200, Kurt Jaeger wrote:

Hi!


As a minor aside, has anyone stated the reason why the user-base of base
or ports are moving to git?


Yes:

https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md



Then the question is : Moving forward, how do we update
the ports?



The same questions keep being asked even if replied to multiple times.

you can use git with the official git repo (once it will be available,
migration is still in progress), or reference a mirror on github or
gitlab. Some documentation about how to do this is available at [1].

If I understand correctly documentation will also be added to the
handbook once migration is done.

Git is a little complicated but a lot of documentation is available on
the internet. search engines are you friends.

If you only want to keep /usr/ports updated the easiest tool to achieve
that is gitup available in ports at net/gitup.

I reiterate, migration is still in progress, the latest available
snapshot of the ports tree (at present read only) is via subversion.
once migration is done the official git repo and mirrors will be available.

There isn't much more to be sail until the migration is done.



Git is ready,

but I use pkg/portsnap .

How does that affect us?


AFAIK you can't use it anymore. Use gitup. It's almost a drop-in
replacement.



How do we use gitup in this scenario?


What scenario?

Please install gitup and read it's man page, it's straight forward.

--
Guido Falsi 



Results:

gitup -v 1 ports
# Host: github.com
# Port: 443
# Repository: /freebsd/freebsd-ports.git
# Target: /usr/ports
gitup: get_commit_details: refs/heads/master doesn't exist in 
/freebsd/freebsd-ports.git: Invalid argument



Thew migration is still in progress, so I guess the repository is in an
unstable state. Try again once the migration is done.

--
Guido Falsi 


LEt us know when ready.



This is getting ridicolous.

Why should I let you know? Learn to read documentation and use provided 
information instruments yourself.


Check this very thread, in previous posts you have all links and 
information necessary to know when the tree will be ready, how to 
configure various tools you need.


There is a limit to hand holding you can expect on mailing lists.

--
Guido Falsi 
___
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: No update for a day on ports?

[Guido Falsi via freebsd-ports]

On 03/04/21 11:28, Guido Falsi via freebsd-ports wrote:

On 03/04/21 02:24, The Doctor wrote:

On Sat, Apr 03, 2021 at 02:05:45AM +0200, Guido Falsi wrote:

On 03/04/21 01:35, The Doctor wrote:

Please install gitup and read it's man page, it's straight forward.

--
Guido Falsi 



Results:

gitup -v 1 ports
# Host: github.com
# Port: 443
# Repository: /freebsd/freebsd-ports.git
# Target: /usr/ports
gitup: get_commit_details: refs/heads/master doesn't exist in 
/freebsd/freebsd-ports.git: Invalid argument




Thew migration is still in progress, so I guess the repository is in an 
unstable state. Try again once the migration is done.




BTW after migration gitup configuration will need to be updated to point 
to the new repository I guess. DOcumentation clearly shows how to do that.


--
Guido Falsi 
___
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: No update for a day on ports?

[Guido Falsi via freebsd-ports]

On 03/04/21 06:23, Helge Oldach wrote:

The Doctor via freebsd-ports wrote on Fri, 02 Apr 2021 23:16:53 +0200 (CEST):

Git is ready,


Is it?

# git clone -o freebsd https://git.freebsd.org/ports.git
Cloning into 'ports'...
fatal: repository 'https://git.freebsd.org/ports.git/' not found
#

Check https://github.com/lwhsu/freebsd-git-docs/blob/main/URLs.md



No it's not, migration still in progress, please be patient.

--
Guido Falsi 
___
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: No update for a day on ports?

[Guido Falsi via freebsd-ports]

On 03/04/21 02:24, The Doctor wrote:

On Sat, Apr 03, 2021 at 02:05:45AM +0200, Guido Falsi wrote:

On 03/04/21 01:35, The Doctor wrote:

On Sat, Apr 03, 2021 at 12:35:57AM +0200, Guido Falsi wrote:

On 02/04/21 23:16, The Doctor via freebsd-ports wrote:

On Fri, Apr 02, 2021 at 04:45:00PM +0200, Guido Falsi via freebsd-ports wrote:

On 02/04/21 15:44, The Doctor via freebsd-ports wrote:

On Fri, Apr 02, 2021 at 08:55:00AM +0200, Kurt Jaeger wrote:

Hi!


As a minor aside, has anyone stated the reason why the user-base of base
or ports are moving to git?


Yes:

https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md



Then the question is : Moving forward, how do we update
the ports?



The same questions keep being asked even if replied to multiple times.

you can use git with the official git repo (once it will be available,
migration is still in progress), or reference a mirror on github or
gitlab. Some documentation about how to do this is available at [1].

If I understand correctly documentation will also be added to the
handbook once migration is done.

Git is a little complicated but a lot of documentation is available on
the internet. search engines are you friends.

If you only want to keep /usr/ports updated the easiest tool to achieve
that is gitup available in ports at net/gitup.

I reiterate, migration is still in progress, the latest available
snapshot of the ports tree (at present read only) is via subversion.
once migration is done the official git repo and mirrors will be available.

There isn't much more to be sail until the migration is done.



Git is ready,

but I use pkg/portsnap .

How does that affect us?


AFAIK you can't use it anymore. Use gitup. It's almost a drop-in
replacement.



How do we use gitup in this scenario?


What scenario?

Please install gitup and read it's man page, it's straight forward.

--
Guido Falsi 



Results:

gitup -v 1 ports
# Host: github.com
# Port: 443
# Repository: /freebsd/freebsd-ports.git
# Target: /usr/ports
gitup: get_commit_details: refs/heads/master doesn't exist in 
/freebsd/freebsd-ports.git: Invalid argument



Thew migration is still in progress, so I guess the repository is in an 
unstable state. Try again once the migration is done.


--
Guido Falsi 
___
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: No update for a day on ports?

[Guido Falsi via freebsd-ports]

On 03/04/21 01:35, The Doctor wrote:

On Sat, Apr 03, 2021 at 12:35:57AM +0200, Guido Falsi wrote:

On 02/04/21 23:16, The Doctor via freebsd-ports wrote:

On Fri, Apr 02, 2021 at 04:45:00PM +0200, Guido Falsi via freebsd-ports wrote:

On 02/04/21 15:44, The Doctor via freebsd-ports wrote:

On Fri, Apr 02, 2021 at 08:55:00AM +0200, Kurt Jaeger wrote:

Hi!


As a minor aside, has anyone stated the reason why the user-base of base
or ports are moving to git?


Yes:

https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md



Then the question is : Moving forward, how do we update
the ports?



The same questions keep being asked even if replied to multiple times.

you can use git with the official git repo (once it will be available,
migration is still in progress), or reference a mirror on github or
gitlab. Some documentation about how to do this is available at [1].

If I understand correctly documentation will also be added to the
handbook once migration is done.

Git is a little complicated but a lot of documentation is available on
the internet. search engines are you friends.

If you only want to keep /usr/ports updated the easiest tool to achieve
that is gitup available in ports at net/gitup.

I reiterate, migration is still in progress, the latest available
snapshot of the ports tree (at present read only) is via subversion.
once migration is done the official git repo and mirrors will be available.

There isn't much more to be sail until the migration is done.



Git is ready,

but I use pkg/portsnap .

How does that affect us?


AFAIK you can't use it anymore. Use gitup. It's almost a drop-in
replacement.



How do we use gitup in this scenario?


What scenario?

Please install gitup and read it's man page, it's straight forward.

--
Guido Falsi 
___
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: No update for a day on ports?

[Guido Falsi via freebsd-ports]

On 02/04/21 23:16, The Doctor via freebsd-ports wrote:

On Fri, Apr 02, 2021 at 04:45:00PM +0200, Guido Falsi via freebsd-ports wrote:

On 02/04/21 15:44, The Doctor via freebsd-ports wrote:

On Fri, Apr 02, 2021 at 08:55:00AM +0200, Kurt Jaeger wrote:

Hi!


As a minor aside, has anyone stated the reason why the user-base of base
or ports are moving to git?


Yes:

https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md



Then the question is : Moving forward, how do we update
the ports?



The same questions keep being asked even if replied to multiple times.

you can use git with the official git repo (once it will be available,
migration is still in progress), or reference a mirror on github or
gitlab. Some documentation about how to do this is available at [1].

If I understand correctly documentation will also be added to the
handbook once migration is done.

Git is a little complicated but a lot of documentation is available on
the internet. search engines are you friends.

If you only want to keep /usr/ports updated the easiest tool to achieve
that is gitup available in ports at net/gitup.

I reiterate, migration is still in progress, the latest available
snapshot of the ports tree (at present read only) is via subversion.
once migration is done the official git repo and mirrors will be available.

There isn't much more to be sail until the migration is done.



Git is ready,

but I use pkg/portsnap .

How does that affect us?


AFAIK you can't use it anymore. Use gitup. It's almost a drop-in 
replacement.


--
Guido Falsi 
___
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: No update for a day on ports?

[Guido Falsi via freebsd-ports]

On 02/04/21 15:44, The Doctor via freebsd-ports wrote:

On Fri, Apr 02, 2021 at 08:55:00AM +0200, Kurt Jaeger wrote:

Hi!


As a minor aside, has anyone stated the reason why the user-base of base
or ports are moving to git?


Yes:

https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md



Then the question is : Moving forward, how do we update
the ports?



The same questions keep being asked even if replied to multiple times.

you can use git with the official git repo (once it will be available, 
migration is still in progress), or reference a mirror on github or 
gitlab. Some documentation about how to do this is available at [1].


If I understand correctly documentation will also be added to the 
handbook once migration is done.


Git is a little complicated but a lot of documentation is available on 
the internet. search engines are you friends.


If you only want to keep /usr/ports updated the easiest tool to achieve 
that is gitup available in ports at net/gitup.


I reiterate, migration is still in progress, the latest available 
snapshot of the ports tree (at present read only) is via subversion. 
once migration is done the official git repo and mirrors will be available.


There isn't much more to be sail until the migration is done.


[1] https://docs.freebsd.org/en/articles/committers-guide/#git-primer

--
Guido Falsi 
___
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: Python 2.7 removal outline

[Guido Falsi via freebsd-ports]

On 27/03/21 12:42, Guido Falsi via freebsd-ports wrote:

On 27/03/21 10:44, Anatoly wrote:

On Thu, 25 Mar 2021 23:06:27 -0700
Chris  wrote:


On 2021-03-25 22:24, Kurt Jaeger wrote:



The portmgr@ role is a huge task and all the reasons (limited time,
dayjobs, etc) ares  valid for those folks from portmgr as for
the rest of the ports maintainers and committers.

Indeed, and don't think that hadn't occurred to me. In fact I
suspected that portmgr@ was feeling a bit overwhelmed, and that
*that* triggered the seemingly overreaching python announcement.
May I humbly request a petition for such large-sweeping changes? IMHO
this will give portmgr@ the opportunity to get caught up, and perhaps
get some assistance -- maybe we all come up with an idea that saves
_everyones_ bacon. :-)

I already miss tools depending on gtk1.2, qt3, qt4 in ports.
Maybe it makes sense to introduce new "flag"
NOAUTOBUILD=    
To mark the ports from which no packages should be build
quarterly automatically to reduce portmgr@ load, instead of just
dropping those ports out of ports tree? And leave all the care of those
ports to their maintainers, requiring them some kind of "pings" to
detect if maintainer is "alive" as the only criteria to keep port in
the tree?



If I understand what you propose  you also mean that updates to the 
ports tree infrastructure and to ports not marked "NOAUTOBUILD" don't 
need to care if the NOAUTOBUILD ports get broken in the process.


If that is so, you can already do this.

Just create a repo on github with a port overlay, or fork the ports tree 
git repo (just wait a few days for the migration of the official ports 
tree to git) and you can add all the ports for old software you need and 
maintain them, or find other people to help you doing it. If you find 
the resources you can also provide CI and binary packages for them.


There iss no need for the project's or portmgr involvement.


OTOH, if you expect all committers to put additional work on the 
infrastructure or their ports to make sure they don't break obsolete and 
EOL software, that is not a viable option.


--
Guido Falsi 
___
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: Python 2.7 removal outline

[Guido Falsi via freebsd-ports]

On 27/03/21 10:44, Anatoly wrote:

On Thu, 25 Mar 2021 23:06:27 -0700
Chris  wrote:


On 2021-03-25 22:24, Kurt Jaeger wrote:



The portmgr@ role is a huge task and all the reasons (limited time,
dayjobs, etc) ares  valid for those folks from portmgr as for
the rest of the ports maintainers and committers.

Indeed, and don't think that hadn't occurred to me. In fact I
suspected that portmgr@ was feeling a bit overwhelmed, and that
*that* triggered the seemingly overreaching python announcement.
May I humbly request a petition for such large-sweeping changes? IMHO
this will give portmgr@ the opportunity to get caught up, and perhaps
get some assistance -- maybe we all come up with an idea that saves
_everyones_ bacon. :-)
  
I already miss tools depending on gtk1.2, qt3, qt4 in ports.

Maybe it makes sense to introduce new "flag"
NOAUTOBUILD=
To mark the ports from which no packages should be build
quarterly automatically to reduce portmgr@ load, instead of just
dropping those ports out of ports tree? And leave all the care of those
ports to their maintainers, requiring them some kind of "pings" to
detect if maintainer is "alive" as the only criteria to keep port in
the tree?



If I understand what you propose  you also mean that updates to the 
ports tree infrastructure and to ports not marked "NOAUTOBUILD" don't 
need to care if the NOAUTOBUILD ports get broken in the process.


If that is so, you can already do this.

Just create a repo on github with a port overlay, or fork the ports tree 
git repo (just wait a few days for the migration of the official ports 
tree to git) and you can add all the ports for old software you need and 
maintain them, or find other people to help you doing it. If you find 
the resources you can also provide CI and binary packages for them.


There iss no need for the project's or portmgr involvement.



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




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

Re: freebsd-ports Digest, Vol 930, Issue 4

[Guido Falsi via freebsd-ports]

On 25/03/21 15:43, Adriaan de Groot wrote:

On Thursday, 25 March 2021 13:00:02 CET freebsd-ports-requ...@freebsd.org
wrote:

The idea is to try to have www/qt5-webengine fixed before the expiration
time, saving with it a bunch of innocent ports depending on it, correct?


In the sense of "have one guy take a stab at it over the weekend because
multi-billion-dollar companies can't be arsed", yes. I'm not sure what the
situation over in Linux-land is.



And I'm really grateful to you for your work on this.

Anyway we do have some kind of plan and I also read (I think it was you) 
that a brute force approach of just grabbing the output of the python 
parts and forcing them in the build could work. While not elegant maybe 
it can bring results in a shorter time if things get tight.


Unluckily, notwithstanding me being involved with some python ports, I 
have actually very little knowledge of python, so I don't think I can 
help much,



[ade]

PS1. I'm going to primarily blame Google; the Qt Company, though, is far from
blameless in its maintainence of WebEngine (or lack thereof). I have hope for
TurtleBrowser, but they are also kind of waiting on me for a breakthrough on
the Python3 front.



The whole python27 situation is really an horrible mess, and many are to 
blame, including big tech. This also demonstrates that just having money 
to throw at a problem is no warranty of it being solved (or the money 
actually being thrown).




PS2. Works-in-progress are the branches *webengine-python3* (old, but does
complete an entire build that then doesn't actually **work**) and *webengine-
logpy27* (new, currently more hacky, doesn't build) in the https://github.com/
freebsd/freebsd-ports-kde.git ports repo.



Will try to take a look.

--
Guido Falsi 
___
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: Python 2.7 removal outline

[Guido Falsi via freebsd-ports]

On 24/03/21 14:03, Rene Ladan wrote:

Hi,

below is an outline continuing the Python 2.7 cleanup:

- all affected ports are now marked as deprecated, with an expiration date
   of either 2020-12-31 or 2021-06-23.
- we will have to wait for Chromium to fully switch to Python 3 before we
   can fully remove Python 2.7. This is work in progress on their side. Not
   waiting would imply removing www/chromium (obviously), editors/vscode
   (it escaped the recursive-deprecation dance of devel/electron*), but most
   importantly www/qt5-webengine which would drag half of KDE with it.
   However, lang/python27 will be marked as RESTRICTED so that all ports
   mentioned above can still be built and run, but Python 2.7 itself will
   not be available as a package.


Just to be sure I get everything right.

The idea is to try to have www/qt5-webengine fixed before the expiration 
time, saving with it a bunch of innocent ports depending on it, correct?


P.S. I want to make clear I have no objection about the removal of 
python 2.7 and I'm really appalled by the situation with chrome build 
system (*). I'm just letting the little worried user inside me express 
his worries. I'd like to understand how we can reach the objective 
without killing a bunch of perfectly working, supported and useful 
software that is now being deprecated due to depending on 
chrmoium/webengine. So I only ask a few questions to get the picture.


If I sound rude please pardon me, I really don't mean to be rude or 
demanding!


[...]

- Upstream Chromium is working on converting their codebase to Python 3 but
   there is no completion date. Interestingly, adridg@ is experimenting with
   converting www/qt5-webengine to Python 3 too.


Is there some ETA on these? Is it realistically possible for these to be 
ready before the end of June?



- We are indeed faster with dropping Python 2.7 than e.g. Ubuntu, however
   more recent Debian/Ubuntu distributions are more and more dropping Python
   2.7 too. This also has to do with how their branching model works, the
   package set of Ubuntu LTS is determined a few months before the release
   itself.


Is the deadline amendable if the plan does not unfold as expected? Or 
are we really going to drop kde and a bunch of other working software to 
stand out ground?




(*) I'm also really appalled by the fact that in the last few years 
almost any software started having the need to include a fully fledged 
html5/js engine but this is another story.


--
Guido Falsi 
___
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: On 14-CURRENT: no ports options anymore?

[Guido Falsi via freebsd-ports]

On 13/03/21 20:17, Hartmann, O. wrote:

Since I moved on to 14-CURRENT, I face a very strange behaviour when trying to 
set
options via "make config" or via poudriere accordingly. I always get "===> 
Options
unchanged" (when options has been already set and I'd expect a dialog menu).
This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is at FreeBSD
14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 amd64).

I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG.

How to fix this? What happened?


I encountered something similar, some base shared library has changed, 
guess this is related with the ncurses changes in base.


If I remember correctly force reinstalling dialog4ports package fixed 
it. Make sure you reinstall a freshly rebuilt one.


Most probably anything using ncurses will require rebuild/reinstall.

The cause is dialog4ports failing to start and the system sees no option 
changed.


If that's not enough try

# ldd -v /usr/local/bin/dialog4ports

And see if it reports some useful information.

--
Guido Falsi 
___
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: having trouble "svn up"-ing /usr/ports/

[Guido Falsi via freebsd-ports]

On 05/02/21 18:11, Michael Schuster wrote:

Hi,

sorry if this is the wrong group - please point me to the proper place if
that's the case.

I updated to Current (14) on Feb 2nd from source (including running
mergemaster)

Since at least yesterday any attempt at "svn up" in /usr/ports either times
out, or rather, fails after some time (over a minute) with:
"svn: E170013: Unable to connect to a repository at URL '
https://svn.freebsd.org/ports/head/graphics'
svn: E120108: Error running context: The server unexpectedly closed the
connection."
or just "hangs", ie doesn't do anything but has one core quite busy, and
when I truss it, I see it opening /etc/ssl/cert.pem over and over again (~
10 per second)

I just checked https://cgit.freebsd.org/; ports isn't there yet, so I would
assume that svn still holds source code for me :-)

Can anyone point out where I need to investigate, or what I may be doing
wrong ... any and all hints appreciated!
thx
Michael



You could have been hit by this bug:


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

You should update to a more recent head (after commit cb7cc72c546e) and 
also make sure you have the www/serf PORTREVISION 6 or later 
(serf-1.3.9_6 or newer)


--
Guido Falsi 
___
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 merging multiple ports trees

[Guido Falsi via freebsd-ports]

On 25/01/21 00:24, Russell L. Carter wrote:

On 1/24/21 2:23 PM, Guido Falsi wrote:

On 24/01/21 20:35, Russell L. Carter wrote:
Greetings, I am completely ignorant here and am looking for up to 
date advice on how to get poudriere to build and make available

package sets from multiple ports trees.  I see there is a port
"portshaker" that seems to do much of what I want.

I can think of possible alternatives:

I can reasonably expect to have my local ports not conflict with
already existing ports (could be a common prefix in the name).
Since I'm using git, I should be able to maintain my own branch
which layers my own ports over upstream and git pull, merge from
upstream.

or

I can duplicate the structure and metadata of the existing ports
tree and add my own ports and leaves in the tree. Still have to
maintain unique names.  This seems to be what portshaker does?  I
am guessing that gets me a single package repo.

or

Have two ports trees and generate two package repos, but then
dependencies would be redundantly built, I guess.

What do the professionals do here?


I've been using portshaker for this (ports-mgmt/portshaker) for this
for a long time.

But when the ports tree will be migrated to git in the near future I
 plan to stop using portshakern and use a git repository forked from
the main one (and syncronized to it) with feature branches for any
change and some "build" branches which I checkout in poudriere and to
which I merge the feature branches as needed.

Git allows for such a workflow and that should also be quite less
error prone.

BTW I noticed poudriere performs shallow clones for git repos, so it
 should not use up a lot of disk space.



Yes, it seems obvious to me to use git for maintaining
the feature branches containing my ports, and as you point out
it makes it easy to maintain multiple feature branches
containing different contents.  Keeping the names disjoint will
prevent messy conflicts.  I am by no means a git expert and
I already do this all the time for other projects.


There already is a git mirror of the ports tree, so you could also start 
doing this now. Only problem is, when the tree is converted you would 
probably have a messy time migrating to the new tree, which, I guess, 
will have new commit hashes, like it happened for source.


--
Guido Falsi 
___
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 merging multiple ports trees

[Guido Falsi via freebsd-ports]

On 24/01/21 20:35, Russell L. Carter wrote:

Greetings,
I am completely ignorant here and am looking for up to
date advice on how to get poudriere to build and make
available package sets from multiple ports trees.  I
see there is a port "portshaker" that seems to do much
of what I want.

I can think of possible alternatives:

I can reasonably expect to have my local ports not
conflict with already existing ports (could be a common
prefix in the name).  Since I'm using git, I should be
able to maintain my own branch which layers my own ports
over upstream and git pull, merge from upstream.

or

I can duplicate the structure and metadata of the existing
ports tree and add my own ports and leaves in the tree.
Still have to maintain unique names.  This seems to be
what portshaker does?  I am guessing that gets me a
single package repo.

or

Have two ports trees and generate two package repos, but
then dependencies would be redundantly built, I guess.

What do the professionals do here?


I've been using portshaker for this (ports-mgmt/portshaker) for this for 
 a long time.


But when the ports tree will be migrated to git in the near future I 
plan to stop using portshakern and use a git repository forked from the 
main one (and syncronized to it) with feature branches for any change 
and some "build" branches which I checkout in poudriere and to which I 
merge the feature branches as needed.


Git allows for such a workflow and that should also be quite less error 
prone.


BTW I noticed poudriere performs shallow clones for git repos, so it 
should not use up a lot of disk space.


--
Guido Falsi 
___
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: Xfce, xfce4-terminal, and UTF-8

[Guido Falsi via freebsd-ports]

On 01/01/21 23:37, George Mitchell wrote:

On 1/1/21 3:12 PM, Guido Falsi via freebsd-ports wrote:

[...]
.cshrc does not look like the correct place for it anyway. That file 
is executed multiple times during a session. I'm not sure how it can 
work for everything else. Also the fact that XFCE has it's own 
configuration, if it's not configured from there could cause conflicts.


IMHO a better place would be .xsession if using a display manager or 
Xinit if using startx.


If using XFCE as your DE it's own settings tool would be the best place.



Regardless of where I put setxkbmap, xev shows this sequence of events
when I type the compose key (Left Win), ', and e to enter "é":

KeyPress event, serial 37, synthetic NO, window 0x2e1,
  root 0x50f, subw 0x2e2, time 89630, (34,51), root:(905,493),
  state 0x10, keycode 133 (keysym 0xff20, Multi_key), same_screen YES,
  XLookupString gives 0 bytes:
  XmbLookupString gives 0 bytes:
  XFilterEvent returns: True

KeyRelease event, serial 37, synthetic NO, window 0x2e1,
  root 0x50f, subw 0x2e2, time 89758, (34,51), root:(905,493),
  state 0x10, keycode 133 (keysym 0xff20, Multi_key), same_screen YES,
  XLookupString gives 0 bytes:
  XFilterEvent returns: False

KeyPress event, serial 37, synthetic NO, window 0x2e1,
  root 0x50f, subw 0x2e2, time 92574, (34,51), root:(905,493),
  state 0x10, keycode 48 (keysym 0x27, apostrophe), same_screen YES,
  XLookupString gives 1 bytes: (27) "'"
  XmbLookupString gives 1 bytes: (27) "'"
  XFilterEvent returns: True

KeyRelease event, serial 37, synthetic NO, window 0x2e1,
  root 0x50f, subw 0x2e2, time 92750, (34,51), root:(905,493),
  state 0x10, keycode 48 (keysym 0x27, apostrophe), same_screen YES,
  XLookupString gives 1 bytes: (27) "'"
  XFilterEvent returns: False

KeyPress event, serial 37, synthetic NO, window 0x2e1,
  root 0x50f, subw 0x2e2, time 98926, (34,51), root:(905,493),
  state 0x10, keycode 26 (keysym 0x65, e), same_screen YES,
  XLookupString gives 1 bytes: (65) "e"
  XmbLookupString gives 1 bytes: (65) "e"
  XFilterEvent returns: True

KeyPress event, serial 37, synthetic NO, window 0x2e1,
  root 0x50f, subw 0x2e2, time 98926, (34,51), root:(905,493),
  state 0x10, keycode 0 (keysym 0xe9, eacute), same_screen YES,
  XLookupString gives 0 bytes:
  XmbLookupString gives 1 bytes: (e9) "�"
  XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x2e1,
  root 0x50f, subw 0x2e2, time 99062, (34,51), root:(905,493),
  state 0x10, keycode 26 (keysym 0x65, e), same_screen YES,
  XLookupString gives 1 bytes: (65) "e"
  XFilterEvent returns: False

The same sequence in an xfce4-terminal window shows nothing, but
any following keypresses act normally.

I removed the setxkbmap command from my .cshrc and used the XFCE
keyboard settings to set the compose key to Left Win.  Then I logged
out and back in.  I verified that the keyboard settings dialog still
showed that Left Win was used for the compose key.  But it does not
work at all.  When I type Left Win, ', e in xfce4-terminal (or in
any other client in my session), it shows 'e.  Xev shows the three
keypresses and releases but no e with acute accent.  -- George



From what you say it looks like xfce4-terminal is getting the special 
character you typed but is ignoring it or unable to display it for some 
reason.


If you think there is a bug in xfce4-terminal you should file a bug with 
upstream directly.


I'm sorry I have no idea where the blame is, I don't know how 
composition is actually implemented, here it just works for me.


Also make sure all your ports are aligned, I use binary packages from my 
own repo. I did have a glitch with composition (it was not working, much 
like you report above after setting it in xfce preferences) and forcing 
reinstallation of many Xorg and XFCE4 related ports "fixed" it. I 
usually think this is due to package upgrading libraries from below 
other packages and some hidden/unwanted binary compatibility change in 
the library.


This is quite a difficult one to diagnose!

--
Guido Falsi 
___
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: Xfce, xfce4-terminal, and UTF-8

[Guido Falsi via freebsd-ports]

On 01/01/21 21:09, George Mitchell wrote:

On 1/1/21 2:57 PM, Guido Falsi via freebsd-ports wrote:

On 01/01/21 20:12, George Mitchell wrote:

I applied the patch from https://reviews.freebsd.org/D27846 to my ports
tree and recompiled with no problems.  But it did not change the compose
key behavior (still fails in xfce4-terminal but works elsewhere).


I actually have no idea. I don't know exactly how the compose key is 
managed in Xorg.


My intuition is it's Xorg itself who is managing it, intercepting the 
key presses before the application and sending it the result if any. 
But I don't know for sure.


Also maybe the setting can be per application. Have you tried 
configuring the compose key in XFCE settings?


Or setting it via command line before launching startxfce4?



I've been setting it in .csrhc (setxkbmap -option compose:lwin), and
originally worked for everything including xfce4-terminal.  It still
works for everything else (including mousepad), but not for
xfce4-terminal.  The XFCE keyboard settings compose key setting does
not seem to work for anything.    -- George



.cshrc does not look like the correct place for it anyway. That file is 
executed multiple times during a session. I'm not sure how it can work 
for everything else. Also the fact that XFCE has it's own configuration, 
if it's not configured from there could cause conflicts.


IMHO a better place would be .xsession if using a display manager or 
Xinit if using startx.


If using XFCE as your DE it's own settings tool would be the best place.

--
Guido Falsi 
___
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: Xfce, xfce4-terminal, and UTF-8

[Guido Falsi via freebsd-ports]

On 01/01/21 20:12, George Mitchell wrote:

I applied the patch from https://reviews.freebsd.org/D27846 to my ports
tree and recompiled with no problems.  But it did not change the compose
key behavior (still fails in xfce4-terminal but works elsewhere).


I actually have no idea. I don't know exactly how the compose key is 
managed in Xorg.


My intuition is it's Xorg itself who is managing it, intercepting the 
key presses before the application and sending it the result if any. But 
I don't know for sure.


Also maybe the setting can be per application. Have you tried 
configuring the compose key in XFCE settings?


Or setting it via command line before launching startxfce4?


--
Guido Falsi 
___
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: Xfce, xfce4-terminal, and UTF-8

[Guido Falsi via freebsd-ports]

On 01/01/21 01:22, Guido Falsi via freebsd-ports wrote:

On 31/12/20 23:57, George Mitchell wrote:

On 12/31/20 3:11 PM, George Mitchell wrote:

I set LOCALE to en_US.UTF-8 and LC_CTYPE to C.  Upon login, I run
setxkbmap -option compose:lwin.  Consequently, I can enter all the
UTF-8 characters I need, such as é, ç, and even ™, into most X-based
programs I run.  When I first set this up, over a year ago, it also
worked for xfce4-terminal, but that stopped working earlier this
year.  (At this point, I can't tell you when exactly, because I
just worked around the problem with mousepad as necessary.)  Does
anyone know the correct fix for this?

Happy New Year, and let's all have a great FreeBSD-based 2021!
-- George



I guess I should have been a little more specific about the exact
failure.  I press the Compose key and two more keys, provoking no
response at all from xfce4-terminal, but any following keys act
normally.  I'm pretty sure it all worked under FBSD 11.3, and it
started to fail some time after I upgraded to 11.4 (don't quote me
on that) and hasn't worked since I upgraded to 12.1.  (By the way,
the same failure afflicts plain xterm.)    -- George




I'm not an expert on composition but I'm working on the update to XFCE 
4.16. I recently noticed some problems with XFCE 4.14 and composition 
(being Italian I use it a lot mainly for accented letters, which are 
quite common and essential in my mother tongue).


Unluckily the update is now held back due to issues with some packages 
not updating correctly sometimes.


But maybe the update would solve it for you. The update is being worked 
on at [1] and [2].


BTW if you're using xfce you can configure your compose key via the 
keyboard configuration in xfce4-settings.


Also more strictly on composition, have you checked the combinations you 
are using are actually present in the list of known key combinations 
(can't recall what file that is in, sorry)


Found it, it's in /usr/local/lib/X11/locale/en_US.UTF-8/Compose, and 
here does contain the copyright symbols, as  o c (and others), 
it is working for me also in xfce4-terminal, but I'm using XFCE 4.16 
with the patches linked in the previous message.


--
Guido Falsi 
___
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: Xfce, xfce4-terminal, and UTF-8

[Guido Falsi via freebsd-ports]

On 31/12/20 23:57, George Mitchell wrote:

On 12/31/20 3:11 PM, George Mitchell wrote:

I set LOCALE to en_US.UTF-8 and LC_CTYPE to C.  Upon login, I run
setxkbmap -option compose:lwin.  Consequently, I can enter all the
UTF-8 characters I need, such as é, ç, and even ™, into most X-based
programs I run.  When I first set this up, over a year ago, it also
worked for xfce4-terminal, but that stopped working earlier this
year.  (At this point, I can't tell you when exactly, because I
just worked around the problem with mousepad as necessary.)  Does
anyone know the correct fix for this?

Happy New Year, and let's all have a great FreeBSD-based 2021!
-- George



I guess I should have been a little more specific about the exact
failure.  I press the Compose key and two more keys, provoking no
response at all from xfce4-terminal, but any following keys act
normally.  I'm pretty sure it all worked under FBSD 11.3, and it
started to fail some time after I upgraded to 11.4 (don't quote me
on that) and hasn't worked since I upgraded to 12.1.  (By the way,
the same failure afflicts plain xterm.)    -- George




I'm not an expert on composition but I'm working on the update to XFCE 
4.16. I recently noticed some problems with XFCE 4.14 and composition 
(being Italian I use it a lot mainly for accented letters, which are 
quite common and essential in my mother tongue).


Unluckily the update is now held back due to issues with some packages 
not updating correctly sometimes.


But maybe the update would solve it for you. The update is being worked 
on at [1] and [2].


BTW if you're using xfce you can configure your compose key via the 
keyboard configuration in xfce4-settings.


Also more strictly on composition, have you checked the combinations you 
are using are actually present in the list of known key combinations 
(can't recall what file that is in, sorry)



[1] https://github.com/madpilot78/FreeBSD-XFCE-4.15
[2] https://reviews.freebsd.org/D27846

--
Guido Falsi 
___
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: portmaster new development

[Guido Falsi via freebsd-ports]

On 29/12/20 00:07, Tatsuki Makino wrote:

Where should I hang out to reply? :)

poudriere has weaknesses in updating packages such as libxml and glib.
When run all at once, all packages that depend on the package being updated and 
all packages that depend on the package being removed will be removed.
The text is not clear :), but qt5-webkit and webkit2-gtk3 are removed, and the 
time-consuming build begins.

This is intentional behaviour, hand there are good reasons for this.

Anyway poudriere has the CHECK_CHANGED_DEPS option which can be disabled 
and should restrict this behavior. I have never tested it though, I 
don't think the risk of getting and incoherent repo is worth it.


--
Guido Falsi 
___
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: FireFox keeps loosing data

[Guido Falsi via freebsd-ports]

On 13/11/20 07:58, Andrea Venturoli wrote:

On 11/12/20 9:52 PM, Dave Horsfall wrote:

Never use file locking on NFS.  Period.  One day it *will* bite you, 
due to some yet-to-be-discovered bug.  In the meantime, feel free to 
ignore the advice of those who have been there before...


Thanks for the advice.
What protocol do you suggest, instead, for sharing data to a diskless 
client?


I don't have a suggestion for "diskless" but since we're not i  the 80's 
anymore, all machines come with some kind of disk controller and small 
disks (even decent SSD ones) don't cost so much, I'd suggest you install 
a minimal OS on the machine and use something like unison or syncthing 
to synchronize what you need.


I'm doing this with my home directory with very good results. Personally 
I don't sync firefox and thunderbird profiles though, and have other 
exceptions (cache directories for npm and php-composer for example).


I also think the synchronizing approach has advantage: Multiple copies 
of the data are usually a good thing, I can use this with my laptop too, 
just remember to sync it back as soon as I am back home, before using 
other machines!


YMMV

--
Guido Falsi 
___
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: Reason for +MANIFEST & +COMPACT_MANIFEST birthday of 1 Jan 1970

[Guido Falsi via freebsd-ports]

On 07/11/20 20:51, Yuet-nan Wong via freebsd-ports wrote:

Is there a particular reason why?


https://en.wikipedia.org/wiki/Unix_time


--
Guido Falsi 
___
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: Icingaweb2

[Guido Falsi via freebsd-ports]

On 27/09/20 18:06, Xavier Humbert wrote:

Hi,

pkg update broke icingaweb2 :
* it upgraded php73 to php74, which at first glance is not a problem
* deleted blindly icingaweb2 without noticing that icingaweb2-php74 was
present

So I reinstalled manually icingaweb2-php74, and when launching the
browser, I got the (in)famous


Call to undefined function Icinga\Util\json_encode()

However :


[root@aragorn ~]# pkg info php74-json
php74-json-7.4.10
[root@aragorn ~]# php -m | grep json
json
[root@aragorn ~]# php phpinfo.php | grepjson
json
json support => enabled

I ran into the very same problem when updated from  php72 to php73, but
can't remember how I fixed it

Someone can help, please ?


Ideas from the top of my head:

- did you restart php-fpm?
- check php-fpm config, is json support enabled there too?

--
Guido Falsi 
___
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: graphics/vigra broken, unbreak?

[Guido Falsi via freebsd-ports]

On 02/04/20 23:30, Felix Palmen wrote:

Hello all,

I'm referring to
 here. This
port is currently broken with default options because science/hdf5 moved
to a new API. I think this is an important issue because graphics/vigra
is a dependency of LibreOffice. I added a patch (just adding a define
that enables the old API) to the PR in question and kindly ask for
review. Also, I assume more ports could be affected, see the PR.


AFAIK the commit upgrading hdf5 to 1.12 has been reverted. You should 
upgrade your ports tree and force vigra to reinstall/downgrade.


--
Guido Falsi 
___
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: Alternatives to security/swatch

[Guido Falsi via freebsd-ports]

On 15/03/20 18:09, Andrea Venturoli wrote:
> Hello.
> 
> I'm using security/swatch to look *in real time* for specific strings in
> my logs, but now it's deprecated because it's unfetchable.
> 
> Can someone suggest an alternative?
> 
> N.B. I'm not looking for something that will parse logs at specified
> times (e.g. run from cron); I already have logcheck.
> I'm using swatch, in addition to that, to look for things that require
> immediate attention, by piping syslogd into it.
> 
> Bonus for not requiring too many dependencies :)

In the past I've used misc/logsurfer for such purpose.

I'm not using it anymore since I'm now using fail2ban for the purpose.
BTW it also does monitor log files in real time and with clever
programming could also work as a notification system, but I agree that's
not it's primary purpose.

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