Re: Clamav upgrade to 0.100.0_1 broken on amd64 current

[Larry Rosenman]

Rerunning testport in my poudriere 11.1 jail for clamav, I get the following:

gmake  check-TESTS
gmake[3]: Entering directory 
'/wrkdirs/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
gmake[4]: Entering directory 
'/wrkdirs/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
PASS: check_clamav
PASS: check_freshclam.sh
PASS: check_sigtool.sh
SKIP: check_unit_vg.sh
PASS: check1_clamscan.sh
PASS: check2_clamd.sh
PASS: check3_clamd.sh
PASS: check4_clamd.sh
SKIP: check5_clamd_vg.sh
SKIP: check6_clamd_vg.sh
SKIP: check7_clamd_hg.sh
SKIP: check8_clamd_hg.sh
SKIP: check9_clamscan_vg.sh
gmake[5]: Entering directory 
'/wrkdirs/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
gmake[5]: Nothing to be done for 'all'.
gmake[5]: Leaving directory 
'/wrkdirs/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'

Testsuite summary for ClamAV 0.100.0

# TOTAL: 13
# PASS:  7
# SKIP:  6
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

So, what EXACT freebsd version are you running, and what EXACT set of options 
for clamav did you set?

And what tool are you using to build clamav?

Thanks!



-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106

On 4/14/18, 8:22 PM, "Manfred Antar"  wrote:

I tried to upgrade clamav to 0.100.0_1 and it fails during tests.
If you disable the tests it will build and install but clamscan dumps core.
Here is output of build with tests enabled:

FAIL: check_clamav
PASS: check_freshclam.sh
PASS: check_sigtool.sh
SKIP: check_unit_vg.sh
FAIL: check1_clamscan.sh
FAIL: check2_clamd.sh
PASS: check3_clamd.sh
PASS: check4_clamd.sh
SKIP: check5_clamd_vg.sh
SKIP: check6_clamd_vg.sh
SKIP: check7_clamd_hg.sh
SKIP: check8_clamd_hg.sh
SKIP: check9_clamscan_vg.sh
gmake[6]: Entering directory 
'/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
gmake[6]: Nothing to be done for 'all'.
gmake[6]: Leaving directory 
'/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'

Testsuite summary for ClamAV 0.100.0

# TOTAL: 13
# PASS:  4
# SKIP:  6
# XFAIL: 0
# FAIL:  3
# XPASS: 0
# ERROR: 0

See unit_tests/test-suite.log
Please report to https://bugzilla.clamav.net/

gmake[5]: *** [Makefile:1089: test-suite.log] Error 1
gmake[5]: Leaving directory 
'/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
gmake[4]: *** [Makefile:1197: check-TESTS] Error 2
gmake[4]: Leaving directory 
'/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
gmake[3]: *** [Makefile:1352: check-am] Error 2
gmake[3]: Leaving directory 
'/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
gmake[2]: *** [Makefile:756: check-recursive] Error 1
gmake[2]: Leaving directory '/usr/ports/security/clamav/work/clamav-0.100.0'
*** Error code 2

Stop.
make[1]: stopped in /usr/ports/security/clamav
*** Error code 1

Stop.
make: stopped in /usr/ports/security/clamav

clamav 0.99.4 builds and passes tests fine

Manfred


___
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: Clamav upgrade to 0.100.0_1 broken on amd64 current

[Larry Rosenman]

The full log is at:
http://home.lerctr.org:/data/p111-S-amd64-host-ports/2018-04-14_20h32m16s/logs/clamav-0.100.0_1.log



-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106

On 4/14/18, 8:36 PM, "Larry Rosenman"  wrote:

Rerunning testport in my poudriere 11.1 jail for clamav, I get the 
following:

gmake  check-TESTS
gmake[3]: Entering directory 
'/wrkdirs/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
gmake[4]: Entering directory 
'/wrkdirs/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
PASS: check_clamav
PASS: check_freshclam.sh
PASS: check_sigtool.sh
SKIP: check_unit_vg.sh
PASS: check1_clamscan.sh
PASS: check2_clamd.sh
PASS: check3_clamd.sh
PASS: check4_clamd.sh
SKIP: check5_clamd_vg.sh
SKIP: check6_clamd_vg.sh
SKIP: check7_clamd_hg.sh
SKIP: check8_clamd_hg.sh
SKIP: check9_clamscan_vg.sh
gmake[5]: Entering directory 
'/wrkdirs/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
gmake[5]: Nothing to be done for 'all'.
gmake[5]: Leaving directory 
'/wrkdirs/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'

Testsuite summary for ClamAV 0.100.0

# TOTAL: 13
# PASS:  7
# SKIP:  6
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

So, what EXACT freebsd version are you running, and what EXACT set of 
options for clamav did you set?

And what tool are you using to build clamav?

Thanks!



-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106

On 4/14/18, 8:22 PM, "Manfred Antar"  wrote:

I tried to upgrade clamav to 0.100.0_1 and it fails during tests.
If you disable the tests it will build and install but clamscan dumps 
core.
Here is output of build with tests enabled:

FAIL: check_clamav
PASS: check_freshclam.sh
PASS: check_sigtool.sh
SKIP: check_unit_vg.sh
FAIL: check1_clamscan.sh
FAIL: check2_clamd.sh
PASS: check3_clamd.sh
PASS: check4_clamd.sh
SKIP: check5_clamd_vg.sh
SKIP: check6_clamd_vg.sh
SKIP: check7_clamd_hg.sh
SKIP: check8_clamd_hg.sh
SKIP: check9_clamscan_vg.sh
gmake[6]: Entering directory 
'/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
gmake[6]: Nothing to be done for 'all'.
gmake[6]: Leaving directory 
'/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'


Testsuite summary for ClamAV 0.100.0


# TOTAL: 13
# PASS:  4
# SKIP:  6
# XFAIL: 0
# FAIL:  3
# XPASS: 0
# ERROR: 0


See unit_tests/test-suite.log
Please report to https://bugzilla.clamav.net/


gmake[5]: *** [Makefile:1089: test-suite.log] Error 1
gmake[5]: Leaving directory 
'/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
gmake[4]: *** [Makefile:1197: check-TESTS] Error 2
gmake[4]: Leaving directory 
'/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
gmake[3]: *** [Makefile:1352: check-am] Error 2
gmake[3]: Leaving directory 
'/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
gmake[2]: *** [Makefile:756: check-recursive] Error 1
gmake[2]: Leaving directory 
'/usr/ports/security/clamav/work/clamav-0.100.0'
*** Error code 2

Stop.
make[1]: stopped in /usr/ports/security/clamav
*** Error code 1

Stop.
make: stopped in /usr/ports/security/clamav

clamav 0.99.4 builds and passes tests fine

Manfred



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

Clamav upgrade to 0.100.0_1 broken on amd64 current

[Manfred Antar]

I tried to upgrade clamav to 0.100.0_1 and it fails during tests.
If you disable the tests it will build and install but clamscan dumps core.
Here is output of build with tests enabled:

FAIL: check_clamav
PASS: check_freshclam.sh
PASS: check_sigtool.sh
SKIP: check_unit_vg.sh
FAIL: check1_clamscan.sh
FAIL: check2_clamd.sh
PASS: check3_clamd.sh
PASS: check4_clamd.sh
SKIP: check5_clamd_vg.sh
SKIP: check6_clamd_vg.sh
SKIP: check7_clamd_hg.sh
SKIP: check8_clamd_hg.sh
SKIP: check9_clamscan_vg.sh
gmake[6]: Entering directory 
'/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
gmake[6]: Nothing to be done for 'all'.
gmake[6]: Leaving directory 
'/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'

Testsuite summary for ClamAV 0.100.0

# TOTAL: 13
# PASS:  4
# SKIP:  6
# XFAIL: 0
# FAIL:  3
# XPASS: 0
# ERROR: 0

See unit_tests/test-suite.log
Please report to https://bugzilla.clamav.net/

gmake[5]: *** [Makefile:1089: test-suite.log] Error 1
gmake[5]: Leaving directory 
'/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
gmake[4]: *** [Makefile:1197: check-TESTS] Error 2
gmake[4]: Leaving directory 
'/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
gmake[3]: *** [Makefile:1352: check-am] Error 2
gmake[3]: Leaving directory 
'/usr/ports/security/clamav/work/clamav-0.100.0/unit_tests'
gmake[2]: *** [Makefile:756: check-recursive] Error 1
gmake[2]: Leaving directory '/usr/ports/security/clamav/work/clamav-0.100.0'
*** Error code 2

Stop.
make[1]: stopped in /usr/ports/security/clamav
*** Error code 1

Stop.
make: stopped in /usr/ports/security/clamav

clamav 0.99.4 builds and passes tests fine

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

zsh 5.5: core dump during serial login

[Dr. Peter Voigt]

Today I upgraded shells/zsh to version 5.5 on my FreeBSD 11.1-RELEASE-p9
machine.

During a login over serial line (wired or IPMI-SOL) I am immediately
kicked out after a successful login. Syslogd shows:

 xxx kernel: pid xxx (zsh), uid 0: exited on signal 8 (core dumped)

I immediately downgraded to zsh-5.4.2_1 and the error disappeared.

Is this a known error or should I created a ticket under
https://bugs.freebsd.org/
___
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: Conflicts due to renamed KDE4 ports

[Carmel NY]

On Sat, 14 Apr 2018 19:53:49 +0200, Stefan Esser stated:

>Yes, but I put literally hundreds of hours of effort into
>understanding portmaster (which is one monolythic 4000 line
>shell script with global state that recursively invokes itself
>to implement local state, with hundreds of instances forked in
>practice) and implementing FLAVOR support.

Good luck. A 4,000+ line shell script is, IMHO, ridiculous.

-- 
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: Conflicts due to renamed KDE4 ports

[Stefan Esser]

Am 14.04.18 um 18:57 schrieb Steve Kargl:
> On Sat, Apr 14, 2018 at 02:30:09PM +, Carmel NY wrote:
>> On Sat, 14 Apr 2018 14:18:22 +0200, Stefan Esser stated:
>>
>> {truncated}
>>
>>> This is another case (after the implementation of FLAVOR support that does
>>> not seem well-designed and causes lots of effort and inefficiencies in port
>>> management tools like portmaster), which makes me consider giving up my
>>> efforts to keep portmaster alive.
>>
>> Have you tried using "synth"?
> 
> This discussion occurred with the introduction of FLAVORS,
> which broken all ports management tools except poudriere.

Yes, but I put literally hundreds of hours of effort into
understanding portmaster (which is one monolythic 4000 line
shell script with global state that recursively invokes itself
to implement local state, with hundreds of instances forked in
practice) and implementing FLAVOR support.

That worked, until the next breakage was introduced by port
and package renames, that make it impossible to automatically
track the history of a port and to upgrade it correctly.

While poudriere just rebuilds ports (using available packages
to satisfy dependencies) and does not care what dependencies
a user has previously used on a system (e.g. which of multiple
SSL libraries, for ports that offer a choice). Instead the
packages built by poudriere will enforce a certain set of
dependencies, giving the user no choice (unless the packages
were custom built with specific options).

But it seems that the packages built by poudriere are also
not suitable for a clean upgrade of installed KDE4 ports.
At least in a test run, some 10 KF5 ports were going to be
installed during an attempt to upgrade a KDE4 port from an
official package.

Portmaster was fully functional before this new breakage, and
I'm really annoyed, that the KDE port and package name changes
have been performed without any thought about the consequences
for port management tools.

It is possible to work around this problem by manually setting
certain parameters in the package DB for each affected port.

I had expected that at least a script that perform these
operations on the package DB was provided.

Now the best option appears to be to remove all installed KDE4
ports and then to rebuild them with portmaster (which will work,
but requires a lot of unnecessary effort and time).

I'm still trying to find a satisfactory heuristic that lets
portmaster DTRT.

But this is a problem, since there are situations where one
choice of action is correct, while it will lead to corruption
of the installed packages in other cases.

The problem is, that now there are systems that have KDE4 ports
with package names (sans version) and origin identical to KDE5
versions of the respective program (e.g. databases/akonadi used
to be a KDE4 port that built akonadi-1.*, now it is a KDE5 port
that builds akonadi-17.*, which is of no use on a KDE4 system and
not suitable for use with KDE4 ports.

Upgrading akonadi (and the tens of other KDE4 ports whose port
directory has been hijacked by KDE5 versions) will thus create
useless KDE5 versions (and the KDE4 version will be removed
when the KDE5 version is installed).

Later upgrades of ports that depend on akonadi-kde4 will install
the correct new dependency (but are broken up to that point). But
the useless KDE5 ports will not be automatically removed.

Hmmm, if they were installed as an automatic dependency (and not
directly by the user), I could use that as a sign, that no other
port depends on them (unless they are actually required by a KDE5
package). This will require extra effort, but I can try whether
this works reliably.

I'll see whether I find an algorithm that uses information not
currently required or used to resolve these cases.

But this will only be in a completely new portmaster, which
shares just the options processing (to stay as compatible as
possible with existing scripts that invoke it) with the current
version in ports.

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

Re: Conflicts due to renamed KDE4 ports

[Kevin Oberman]

On Sat, Apr 14, 2018 at 10:12 AM, Carmel NY  wrote:

> On Sat, 14 Apr 2018 09:57:07 -0700, Steve Kargl stated:
>
> >This discussion occurred with the introduction of FLAVORS,
> >which broken all ports management tools except poudriere.
>
> So, you have not tried "synth" and I assume poudriere.
>

Please STOP!

He is the maintainer of portmaster and, for many people, portmaster is
still a critical system component that is not replaceable by either synth
or poudriere. Since his goal is to make portmaster work, telling him that
he should use another tool is missing the whole point.

The issue he is bringing up is NOT flavors. portmaster has supported
flavors for some time. It is changes made to a set of ports that seems to
break the existing paradigm of the ports system.
--
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: Conflicts due to renamed KDE4 ports

[Carmel NY]

On Sat, 14 Apr 2018 09:57:07 -0700, Steve Kargl stated:

>This discussion occurred with the introduction of FLAVORS,
>which broken all ports management tools except poudriere.

So, you have not tried "synth" and I assume poudriere.

-- 
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: Conflicts due to renamed KDE4 ports

[Steve Kargl]

On Sat, Apr 14, 2018 at 02:30:09PM +, Carmel NY wrote:
> On Sat, 14 Apr 2018 14:18:22 +0200, Stefan Esser stated:
> 
> {truncated}
> 
> >This is another case (after the implementation of FLAVOR support that does
> >not seem well-designed and causes lots of effort and inefficiencies in port
> >management tools like portmaster), which makes me consider giving up my
> >efforts to keep portmaster alive.
> 
> Have you tried using "synth"?

This discussion occurred with the introduction of FLAVORS,
which broken all ports management tools except poudriere.

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

pkg wants to install perl5.24 even thought it's not required

[Serpent7776]

Hello,

I have strange issue: when I install or upgrade a package pkg wants to install
perl5.24 too every time. That's strange because all ports require perl5.26, not
perl5.24.
After installation/upgrade when I do pkg autoremove pkg tells that
perl5.24 in not required and can be deleted.
I have not specified any default perl version in /etc/make.conf.
I'm using custom built ports via poudriere.
What might be causing this?

Thanks
-- 
/*
 * Serpent7776
 */
___
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: Conflicts due to renamed KDE4 ports

[Grzegorz Junka]

On 14/04/2018 12:18, Stefan Esser wrote:

[cut]

This is another case (after the implementation of FLAVOR support that does
not seem well-designed and causes lots of effort and inefficiencies in port
management tools like portmaster), which makes me consider giving up my
efforts to keep portmaster alive.

STefan


This caused some headache on my system too even though I use poudriere 
to build packages and I don't use the whole kde suite, just some 
applications. I had to manually uninstall all old kde ports and 
re-install them again adding the kde4 suffix. Are you saying I will need 
to do that again when I want to switch to kde5?


I haven't seen any consultation being posted on this forum if/when/how 
the introduction of kde5 should be handled. I imagine it's not the first 
time such a massive upgrade of version has had happened in FreeBSD 
ports. Is it how it's usually handled?


Also, wouldn't in this case converting kde to flavours, i.e. 
kde-base@kde4 and kde-base@kde5 be a better approach?


GrzegorzJ
___
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: Conflicts due to renamed KDE4 ports

[Carmel NY]

On Sat, 14 Apr 2018 14:18:22 +0200, Stefan Esser stated:

{truncated}

>This is another case (after the implementation of FLAVOR support that does
>not seem well-designed and causes lots of effort and inefficiencies in port
>management tools like portmaster), which makes me consider giving up my
>efforts to keep portmaster alive.

Have you tried using "synth"? I have not used it on KDE since I don't have KDE
installed; however, it has worked well with other ports that seemed to have a
similar problem. It couldn't hurt to give it a try. Just make sure you have an
up-to-date ports tree before running it.

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

Conflicts due to renamed KDE4 ports

[Stefan Esser]

The way the new KDE5/KF5 ports have been introduced a few weeks back has
caused me quite some effort (more than 100 hours of work), and now there
have been further changes to implement KDE5 support (which I generally
appreciate), which cause further complications and seem not to be well
thought out.

These problems affect at least all portmaster users, but I guess portupgrade
is affected as well and a "pkg upgrade" dry-run indicates, that it will also
cause breakage to binary upgrades of KDE4 installations.


I'm trying to get portmaster operational again, after it has been unusable
for systems with KDE4 ports for a few weeks.

Since the way portmaster works prevents an easy solution, I'm currently
rewriting it from scratch (and had it mostly working for the normal upgrade
tasks, with some of the more "special" like cleaning up stale distfiles
missing).

This new version is now again broken, because of changes that I do not
know how to automatically deal with. (And IMHO it is impossible to deal
with them, without hard-coding specific work-arounds for the affected
ports. This is against the spirit of a generic port management tool.)


A number of KDE4 ports have been moved to port directories that have an
extra -kde4 appended. The package names changed at the same time, and
that caused problems for portmaster, since if there was a dependency
that referred to the new origin with -kde4 attached, it would be in
conflict with the installed package. (The -kde4 version would be built
and the install would fail because the non-kde version was not recongnized
as a previous version of the same port and was not automatically deinstalled
first. This is fixed in my new portmaster version, which finds the old
origin in the MOVED file and checks whether there is a port that was
installed from some meanwhile "moved" origin.)

Individually updating those ports first, could solve this issue, but there
was not list of affected ports and thus it was up to the user to detect
the build failures as they occurred, delete the old version and restart
the portmaster run. (My new version deals with this, based on the MOVED
file, as described above.)


Now the situation has become much worse: Now there are KDE5 versions of
quite a number of prior KDE4 ports, which share the origins and package
names of these prior KDE4 programs, and can only be recognized by their
version numbers being different from 4.*).

This leads to breakage in a number of ways:

Ports depending on say KDE4 akonadi but installed at a time when the
origin still was databases/akonadi will (probably) break when akonadi
is upgraded and replaced by the KDE5 version of akonadi. There is no
way that portmaster could know, that the KDE4 version is now built from
databases/akonadi-kde4 and installed as akonadi-kde4-4.* (instead of
just akonade-4.*).

New ports will try to install akonadi-kde4 as a dependency, which may
succeed, after databases/akonadi has been upgraded to the KDE5 version,
but before that has happened, there will be conflicting files and the
dependency on akonadi-kde4 cannot be satisfied by the ports system.

OTOH, I now have a KDE5 version of akonadi, which has not been requested
by the user (who may want to stay at KDE4 at the moment). This KDE5 version
has been built, because there was a KDE4 version, and the port system did
not know, that these two ports share their origin and package name (sans
version), but are not directly related.

Again OTOH, the upgrade of akonadi to the KDE5 version will break all
ports, that rely on the KDE4 version being installed. These seem to be:

$ pkg info -r akonadi
akonadi-1.13.0_6:
kdepimlibs-kde4-4.14.10_15
smokekde-4.14.3_3
kde-workspace-4.11.22_14
kdeplasma-addons-4.14.3_6
kdepim-runtime-kde4-4.14.10_9
kdepim-kde4-4.14.10_11
ruby24-korundum-4.14.3_2
py27-pykde4-4.14.3_7
baloo-kde4-4.14.3_7

on my system ...


A number of KDE4 ports have been copied to new origins (with -kde4 attached)
with there old directories still present and functional. That does also cause
problems for automatic port build tools like portmaster. The old ports seems
to be still valid and is not marked to be in conflict with its copy. Since
the package names have been changed (by appending -kde4) it is not possible
to detect, that these are in fact just renamed versions of the previous port.
Since there is no MOVED entry, the last possibility that might provide a hint
is lost. (There can be no MOVED entry, since the old name is to be re-used for
the KDE5 version of that program.)


I think it is a very bad idea to do any of the following:

1) Rename a port without an entry in MOVED (even though dependencies are
   updated) if the package name (sans version) is changed at the same time.

2) Copy a port resulting in two origins that build the same package and that
   are not marked as mutually conflicting (whether with identical or changed
   package names - but the latter 

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
databases/postgresql-plv8js | 1.4.8   | v2.3.2
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

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