emulators/twin installs its own libreadline.a

[Mikhail T.]

Does anyone know, why emulators/twin install its own libreadline.a into
${PREFIX}/lib? Sometimes it is picked up instead of the system one and
causes mayhem...

It does not do that on NetBSD pkgsrc, so, I guess, I'll just patch it
accordingly for FreeBSD as well...

Thanks!

-mi

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

The state of Ada (Re: FreeBSD unmaintained ports which are currently scheduled for deletion)

[Mikhail T.]

01/-10/37 14:59, lini...@freebsd.org wrote:

portname:   devel/adabindx
description:An Ada-binding to the X Window System and *tif
maintainer:po...@freebsd.org
status: BROKEN
deprecated because: has been broken for 3 months
expiration date:2010-01-08
build errors:   none.
overview:http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=adabindx


[...]


It looks like a noticeable share of the ports listed have one thing in 
common -- they depend on Ada.


Various gnat-ports would not even build on anything but i386...

Is Ada-support really in such a bad shape by the GNU-project, or is it 
just a FreeBSD problem?


   -mi

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

Maintaining compiler front-ends (Re: The state of Ada)

[Mikhail T.]

01/08/10 13:10, John Merryweather Cooper написав(ла):

Well, the [Ada -mi] compiler needs to be upgraded to the latest version.  Linux 
gets a compiler out of the box, but we have to bend one to shape.
I remain convinced, that the "bending into shape" ought to begin with 
making the additional GNU compiler front-ends (be they Ada, or Lisp, 
Java, Fortran, Pascal, Objective C, etc.) addable to an already existing 
C-compiler. I find it crazy, that every such front end currently 
downloads and builds its own gcc-core-SOMEVERSION, instead of using the 
base gcc or DEPEND-ing on lang/gccSOMEVERSION.


Yes, I am well aware, that this is, how GNU people do things. No, I 
don't think, there is nothing FreeBSD can do about it... Starting with 
making all such compilers use common binutils. (Perhaps, these can even 
be provided by the base -- NetBSD does just that, for example...)


Once done, ports of front-ends will no longer have to each deal with the 
back-end making the maintainership easier and thus giving us better ports...


   -mi

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

Re: The state of Ada (Re: FreeBSD unmaintained ports which are currently scheduled for deletion)

[Mikhail T.]

01/08/10 14:59, Daniel Eischen написав(ла):

All the ports that I saw that were broken, were broken
*because* the compiler (lang/gnat) was updated.  Those
ports seemed to be vastly out of date and didn't build
with the latest GPL gnat from ACT. 
Well, I tried to fix one, but my system is amd64, so I couldn't even 
begin... Good to see, somebody is working on it, though...


   -mi

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

Re: Maintaining compiler front-ends (Re: The state of Ada)

[Mikhail T.]

01/08/10 15:59, Joerg Wunsch ???(??):

I'm also maintaining a port of libbfd which is used by some AVR
toolchain software.  This port is set up in a "kitchensink" way, so
all possible binary file formats are included.  This could perhaps
serve as a base for a generic GNU libbfd package to be used by other
GNU stuff if desired.  Note that it requires GNU libiberty to be
installed as well (freelibiberty won't do), as libbfd uses
undocumented GNU libiberty functions.:-(
   
Hi, Joerg! Yes, this is why I added you to CC, and I do think, that the 
common libbfd ought to have all of the known targets included. Even 
altogether they use very little space -- less, than having to add just 
one more flavor separately (even multiplied by the probability of ever 
having to do that :)


As for GNUberty, well... Maybe, some day, we'll add those functions to 
the liberfreety (or patch bfd to avoid them). Until then -- use the 
GNU's code as we do elsewhere...


Yours,

   -mi

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

Re: Re: Recent massive port update.

[Mikhail T.]

Miroslav Lachman wrote:
Is expected, but if somebody are not using portmaster or portupgrade, 
simple upgrade of jpeg will break other ports and I think that in the 
case of jpeg (widely used library) there will be a lot of users asking 
"why my app XYZ is not working anymore".
A "simple upgrade" involves removing the old version of the JPEG 
package. When performing the removal, the user was given a list of other 
packages, that depend on the JPEG -- and saw pkg_delete exit. *That* was 
the warning...


Yes, `make deinstall' invokes pkg_delete with the `-f', thus making it 
too easy to shoot oneself in the foot... This may be a problem worth 
addressing, but the warning is still there...


   -mi

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

Re: Re: FreeBSD Port: firefox-3.6.3, 1 (trying to load certain pages causes the browser to hang then crash)

[Mikhail T.]

-10.01.-28163 14:59, Joey Mingrone написав(ла):

Nothing loads at all.  It just remains on the current page and says
something like "connected to mail.google.com" in the status bar and
hangs for a minute or two then crashes/closes.  Sometimes it seg.
faults and other times it closes, but the processes are still running
when I check with ps.

Joey

None of https-using URLs worked for me with a 3.6.x firefox
on my FreeBSD-7.x/amd64 desktop back in March. The browser
would usually just hang.

Thunderbird-3.x had a similar problem -- although the first SSL-based
connection to my IMAP server would succeed, the MUA would not be
able to reconnect later...

Going back to 3.5.x (and 2.0.x for Thunderbird) fixed the problems.
Folks on gecko@ could not reproduce it, so I am "glad" somebody
else confirms, I'm not a complete lunatic :-)

   -mi

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

minidlna: a new port needs testers, start-up script

[Mikhail T.]

Hello!

"Digital Life Network Alliance " is a 
standard newer than UPnP -- some devices on the market are not satisfied 
with plain UPnP-servers like mediatomb 
... As far as I understand, the 
only DLNA-capable server ported to FreeBSD right now is ushare 
, but it seems to require a full 
rescan of one's media-collection upon every startup...


I (almost) ported a promising little DLNA-server 
 (which uses SQLite3 database to store 
the collection data between restarts), but I need help with the start-up 
script 
 
-- the server should run as its own unprivileged user:group (dlna:dlna), 
send stderr/stdout to /var/log/minidlna.log (I may later patch it to use 
syslog instead), and maintain PID-file in /var/run/minidlna.pid.


The port can be downloaded from:

   http://aldan.algebra.com/~mi/minidlna-port.shar

Both my Bravia TV and Onkyo receiver are able to play MP3 files served 
by it (although Onkyo can't decode the Cyrillics in the titles)... The 
TV can also show pictures (except for /progressive/ JPEGs, which Sony's 
JPEG implementation infamously rejects 
). I'm 
yet to figure out, what video-file format the TV would accept -- 
minidlna does not offer on-the-fly transcoding... Also, some bug in 
avformat breaks it for certain .m2ts files I have (both ushare and 
ffplay suffer from the same).


Please, report any problems by private e-mail. As soon as the start-up 
script is contributed, I'll commit the port.


Thanks!

   -mi

P.S. Before installing the port, remember to add the dlna user and group 
to /usr/ports/UIDs and /usr/ports/GIDs:


   --- UIDs12 Jun 2010 17:43:50 -  1.115
   +++ UIDs23 Jun 2010 15:07:54 -
   @@ -173,2 +173,3 @@
 nslcd:*:928:928::0:0:nslcd daemon:/nonexistent:/usr/sbin/nologin
 activemq:*:929:929::0:0:ActiveMQ Daemon:/nonexistent:/sbin/nologin
   +dlna:*:930:930::0:0:DLNA server:/nonexistent:/sbin/nologin
   --- GIDs12 Jun 2010 01:05:53 -  1.99
   +++ GIDs23 Jun 2010 15:07:54 -
   @@ -163,2 +163,3 @@
 nslcd:*:928:
 activemq:*:929:
   +dlna:*:930:

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

Re: devel/icu does not build with gcc 4.5.1

[Mikhail T.]

Doug Barton wrote:
> Howdy,
>
> Tried building devel/icu today with gcc 4.5.1 and it failed:
devel/icu4 is the newer version, but should be compatible with all
depending ports. If that builds with gcc-4.5.1, then I'm not going to
worry -- after the release, I'm planning to request a repo-copy of icu4
to icu. Thanks!

-mi

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

Re: ptlib build failure - breaks pwlib - hence also asterisk - opal - & openh323

[Mikhail T.]

21.09.2010 05:34, David Southwell написав(ла):

I had the crazy idea that all the maintainers on the hook might be able
to collaborate to deal with a common interest.

Maintainers on the hook as listed in the relevant Makefiles are:

ptlib -- lih...@ieee.org
ptlib26 -- melif...@ipfw.ru
pwlib -- st...@energistic.com
openh323 -- st...@energistic.com
opal m...@aldan.algebra.com
asterisk sobo...@freebsd.org


I have not committed anything in Opal-related in many months... Thus, I 
doubt, it is my problem... If you think, it is, please, file a PR. Thank 
you,


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

Re: ptlib build failure - breaks pwlib - hence also asterisk - opal - & openh323

[Mikhail T.]

 21.09.2010 12:05, David Southwell написав(ла):
Problem is opal does not compile due to failure which was in original 
posting:

According to:


http://pointyhat.freebsd.org/errorlogs/i386-8-latest-logs/opal-2.2.11_2.log.bz2


Opal builds just fine -- in the "clean" environment... As does ptlib:


http://pointyhat.freebsd.org/errorlogs/i386-8-latest-logs/ptlib-2.4.4.log.bz2


Which means, there is something about your configuration, that 
interferes with the build.


I'm not blaming you -- ports (unlike packages) ought to be flexible and 
build properly in a variety of configurations. The price for that 
flexibility, however, is having to deal with an occasional breakage, 
when your setup deviates "too far" from the mainstream. But you need to, 
at least, diagnose the problem yourself.


Does the presence of some "unusual" package break the build? Any other 
unexpected setting/configuration option?


Include that info in a PR, so that the problem can be reproduced... 
Thanks! Yours,


-mi

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

Re: ptlib build failure - breaks pwlib - hence also asterisk - opal - & openh323

[Mikhail T.]

 23.09.2010 04:14, David Southwell написав(ла):


> To OP (David Southwell):

>

> Do you have openssl installed from ports (so it shows up in pkg_info

> output)?

David, I think, it is much easier for you to answer the above simple 
question, than for the others to attempt the below experiment...

> To port maintainers:

>

> Could you try to build your ports in the presence of openssl installed

> from ports?


Have any maintainers tried this?


Not me...

   -mi


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

Re: Re: FreeBSD unmaintained ports which are currently scheduled for deletion

[Mikhail T.]

On -10.01.-28163 14:59, Peter Jeremy wrote:

>>  >portname:   sysutils/cpuburn

>>  Actually, the mastersite has been discontinued by the ISP.  It looks
>>  like it's still available elsewhere but I can't find a replacement
>>  mastersite.

>
>So this one is correct???

It seems to be - which is unfortunate.

Can it be unbroken by using the Internet archive?

   --- Makefile2 Aug 2011 17:03:41 -   1.9
   +++ Makefile24 Aug 2011 13:46:21 -
   @@ -9,5 +9,5 @@
 PORTVERSION=   1.4
 CATEGORIES=sysutils
   -MASTER_SITES=  http://pages.sbcglobal.net/redelm/
   +MASTER_SITES= 
   http://web.archive.org/web/20070304200856/http://pages.sbcglobal.net/redelm/

 DISTNAME=  cpuburn_${PORTVERSION:S/./_/g}
 EXTRACT_SUFX=  _tar.gz

If so, quite a few other victims of this latest purging can be given a 
new life. Yours,


   -mi

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

Re: FreeBSD unmaintained ports which are currently scheduled for deletion

[Mikhail T.]

On 25.08.2011 08:48, Chris Rees wrote:

On 24 August 2011 14:47, Mikhail T.  wrote:


Can it be unbroken by using the Internet archive?

...
If so, quite a few other victims of this latest purging can be given a new
life.



Matthias recently made reference on this subject, if you care to take a look:

http://lists.freebsd.org/pipermail/cvs-ports/2011-August/223266.html



Thanks for the pointer. I disagree with Matthias very strongly on this -- and 
made my disagreement known in the past. It remains my deeply-held opinion, that 
only those ports, which fail to build, ought to be removed from the tree. I'm 
happy to learn, amdmi3@ is of similar persuasion. Matthias warns, that 
"something we mirrored years ago" could be missing "crucial patches" -- but 
that's inevitable even with actively-maintained ports, and FreeBSD, wisely, 
makes no promises of software quality or security.


Matthias' proposal to remove "unmaintained" ports makes it impossible to find a 
PERFECT program, port it and wash one's hands away from it. Sooner or later 
somebody will come to claim, your software is "too old" and thus /could/ contain 
security holes, and therefor must be removed. Because we have "too many" ports 
or something.


Perhaps more importantly, Matthias' argument is different from the problem at 
hand -- he seems to dislike old distfiles, but the current campaign targets not 
the old pieces, but those, for which the master-sites' have disappeared. For 
example, the sources of audio/adpcm date to 1994, but the port only got into 
trouble, when the FTP-site hosting it disappeared from the Internet... Likewise, 
sysutils/cpuburn's sources are from 2003, but the port arose no questions, until 
AT&T discontinued subscribers' web-spaces (where the author was hosting the 
distfile) two months ago...


Do we really want to allow ISPs to affect the contents of our ports collection 
in this manner?


If we were really ruled by consensus, these unfortunate ports would've stayed 
because, evidently, there is no consensus, as Dmitry and Matthias discuss at the 
very beginning of the e-mail you linked to...


It appears, that the rule currently being applied, is: "remove, if there are no 
master-sites other than FreeBSD's mirrors" (the deprecation messages state 
something else, but this is the real meaning). Though this rule is refreshingly 
objective, I still don't like it -- FreeBSD claimed "there is a port for it" 
long before the catchy "there is an app for it", and this remains a major 
"selling" point for the OS.


But, if the rule's application is unstoppable, then I'd save most of the victims 
of the current purge by switching them to archive.org. It can even be done 
automatically by a clever script... Yours,


   -mi

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

Re: Re: sysutils/cfs

[Mikhail T.]

On -10.01.-28163 14:59, Chris Rees wrote:

I've had to deprecate sysutils/cfs -- there's a confirmed issue with
failing locks [1] which has been open for two years with no fix.


Whoops, also missed a CVE -- buffer overflows can cause a DoS.
Expiration date altered to 1 month accordingly.


Is this the only vulnerability you are talking about?

   http://www.debian.org/security/2006/dsa-1138

Does not seem hard to fix at all... Listing all of the fatal problems 
would be helpful...


   -mi

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

Re: sysutils/cfs

[Mikhail T.]

On 05.09.2011 13:32, Chris Rees wrote:

If it's not that hard to fix then do it.
Before doing it, I wanted to confirm, that there are no other, more 
serious vulnerabilities.


Things, for which no fixes have been posted -- unlike for this 
particular one, which Debian fixed several years ago (before dropping it 
for whatever reasons).


Instead of confirming (or denying), you yelled at me. Ouch...

   -mi

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

Community's opinion (Re: Re: sysutils/cfs_

[Mikhail T.]

On -10.01.-28163 14:59, Doug Barton wrote:

It is not responsible to threaten to remove ports without warning
between releases for non urgent reasons.

We understand that this is your perspective, however the community in
general has a different idea.


Well, several committers are on (recent) record agreeing with Julian and 
myself.


Yet, the "community", supposedly, feels different. Can we ask, just what 
that nameless "community" is, and how do we know its opinion?


Has there been a vote? What were the results? Were they overwhelming to 
one side, or close? And what, exactly, are our bylaws and procedures for 
when there is no consensus? Thanks! Yours,


   -mi

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

Re: sysutils/cfs

[Mikhail T.]

On 07.09.2011 03:09, per...@pluto.rain.com wrote:

So at this point, all that is needed is for someone interested in
preserving the port -- like maybe you? -- to step up and_do_  that.


The main topic here -- despite the subject line -- is not about the 
particular part, but about the conflicting opinions on when to remove 
ports from the tree. The fate of sysutils/cfs or any other individual 
port is, really, secondary to that discussion...


Yar, myself, as well as other folks, who object to the on-going 
deprecations/removals of ports for the slightest of offenses, can fix 
/any/ port currently on the death-row, but we can not fix /all/ of them. 
Still, we would like them to remain in the tree -- unless they flat-out 
do not build.


Yours,

   -mi

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

Re: sysutils/cfs

[Mikhail T.]

On 07.09.2011 12:04, Chris Rees wrote:


However... I find it deeply troubling that you consider buildability more 
important than security fixes. Are you actually serious?




Yes, I'm, of course, serious. As you formulated above, the question is a no 
brainer: software, that does not build is ultimately "secure". Ha-ha...


Seriously, this ought to remain up to the user. To quote an ancient principle, 
we are to provide mechanism, not policy. If we are aware of a problem, we ought 
to advise the user of it. But to completely remove the mechanism for the sake of 
enforcing, what we think ought to be the user's own policy, is wrong...


For example, the cfs' known vulnerability strikes only, when a particular file's 
size exceeds 2Gb (that's about 3 CDs).


I can see a number of use-cases, when the entire encrypted FS is less than that. 
One can certainly fit all of one's passwords, as well as high-res scans of 
important documents and have room to spare. It may also be possible to prevent 
hitting that threshold with quotas.


And so on. Yours,

   -mi

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

Re: sysutils/cfs

[Mikhail T.]

On -10.01.-28163 14:59, Chris Rees wrote:
I don't actually think they've been divisive -- it's been policy for years. 


The policy -- up until fairly recently -- was to remove ports, that *fail to 
build* for a while. This made sense -- if the port remains unbuildable long 
enough, then, certainly, it is no longer in use.


The /new/ policy of removing ports for much lighter offenses, such as having 
vulnerabilities, has already caused so many objections, that it is time to 
abolish it.
I don't call four weeks for software with a security vulnerability short 
notice. We count a maintainer timeout as half that.


A "maintainer timeout" will allow another developer to perform a fix. To 
completely remove the port (if that has to happen at all), a much longer warning 
is warranted.


My problem with 'whining' (perhaps a less emotional response from me would 
have been better) was the sheer number of people stepping up and refusing to 
provide any fixes, just criticising me for wanting to remove something. It's 
just not constructive. 


Yes, the matter is exactly that: your wanting to remove something, that 
continues to build and remains in use. You followed, what you think is "an old" 
policy, and are getting flack from people like myself, who object to the (new) 
policy. Nothing personal...



Patches gratefully received (this is a volunteer effort after all)


Again. This is not about a particular port -- Julian, myself, and other 
objectors can fix /any/ port, but we can not fix them /all/, so blaming us for 
not submitting patches is wrong.


We object to the new policy, because we believe, only those ports, that fail to 
build, ought to be removed. Problematic ports ought to remain in the tree (as 
long as they build) -- to make it easier for people to continue using them 
and/or offer to maintain them. If there remains a vulnerability, then, of 
course, a loud warning (with a link to the advisory(ies)) is in order, but the 
users ought to make their own choices and evaluations.


   -mi

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

ports-system priorities rant (Re: sysutils/cfs)

[Mikhail T.]

On -10.01.-28163 14:59, Doug Barton wrote:
Non sequitur. The large number of ports that we support IS a feature. However, 
it's also a pretty big maintenance burden. Especially when you consider the 
number of those ports that are either actually or effectively unmaintained.


Support? What support? Can I call someone and have a solution to a problem? Some 
PRs remain open for years and any attempts to escalate are met with "patches 
welcome" -- I've been on both sides myself :-)


We do not offer support, make no promises of such and offer neither guarantees 
nor SLAs. What we do offer is: "THERE IS A PORT OF IT". If there is a piece of 
software out there, chances are, it is ported to FreeBSD. Even if the existing 
port is imperfect, it is a starting point for somebody, who needs that software 
on their system.


With every port removed, that promise wears thinner and thinner...


Maintaining a high level of actual support for the ports tree is the goal here.


Without paid contracts talk of "high level actual support" is meaningless. Both 
src and ports are maintained by people, to whom software-development and 
engineering is FUN. Support is not fun -- it is a burden. A burden we undertake 
(you, perhaps, more than others), but do not like...


In the near term future we're also hoping to provide some new, better tools; 
as well as better/more consistent package support. In order to do those things 
we need to make sure that we're putting our effort where it is most needed.


This is great, but:

1. I don't see, how the sliver of removed ports, actually, helps you there.
2. In the past "consistent package support" used to conflict with the loose
   building from source (recall the ongoing problem with major shlib numbers
   bogusly included in most LIB_DEPENDS lines).

Having to deal with RedHat's yum at work, I got to say, I'd rather be building 
from source, than installing from "consistent packages", that somebody else 
built *to their* tastes. Also, having to provide "high level support" for those 
packages limits their number. No, I don't want FreeBSD to go in that direction 
at all. Let RedHat cater to that market :-)


To rephrase: your opinion seems to be: let's provide better support to fewer 
ports. I say, that's misguided -- you will not be able to significantly improve 
the support quality, even if you do remove the niche ports from the tree. But 
the removal will in itself be harmful...


Yours,

   -mi

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

Re: ports-system priorities rant (Re: sysutils/cfs)

[Mikhail T.]

On 08.09.2011 04:42, Greg Byshenk wrote:

For many people, what "THERE IS A PORT OF IT" actually -means- is
that the user can go to ports and install a -working- version of
the software, not merley that there is something called 'IT'
somewhere in the ports tree that may or may not work.


Some ports -- both maintained or disowned -- will always be behind the 
upstream. Some ports will always be better than others. Simply removing 
those, where the perceived quality drops below somebody's subjective 
threshold does not improve quality. Having a poor port of an obscure 
piece of software is better, than no port at all. And, yes, this is the 
core of the disagreement... Yours,


   -mi

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

Re: Recent ports removal

[Mikhail T.]

On -10.01.-28163 14:59, Doug Barton wrote:

Yes, we realize that you, and a small minority of other interested
parties, have this belief in spite of endless repetition of the
reasoning, by the people who do the actual work to keep the ports tree
functional, as to why your desire to keep every port is not a workable
solution.


I'm one of this "small minority" and can't recall hearing the actual 
"reasoning" repeated even once -- without every argument being soundly 
rebutted by myself and other "interested parties".


The last discussion, that I can recall ended with an assurance, that the 
matter is being discussed by the portmgr@ and that the discussion's 
results will soon be delivered to the unwashed masses.


If, indeed, the sound arguments exist, then, perhaps, they can be 
summarized on a web-page of some sort -- together with the attempts at 
rebuttal and the counter-rebuttals? There is clearly a vocal share of 
contributors that currently disagree with portmgr's line -- and our 
claim to represent a sizable portion of users is just as good as your 
claim, that we are nothing but a "small minority".


Please, convince us so we can all go along with the consensus -- and 
relieve you from having to repeat your reasoning (whatever it is) 
monthly... Thanks!



However the fact that no one has made a peep about them is a pretty strong 
indication that they were simply dead
weight that we were carrying for no good reason.


You've gone from "small minority of other interested parties" to "no one 
has made a peep" in a single e-mail! If this is the quality of the rest 
of your reasoning, than you should not be surprised, that it has not 
really resonated despite the "endless repetition"...


   -mi

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

Re: Recent ports removal

[Mikhail T.]

On 13.11.2011 16:20, Doug Barton wrote:

You turned a comparison of the discussion of the concept of ports
removal generally to the removal of individual ports and turned it into
an ad hominem attack on the quality of*my*  reasoning.


Huh?


This is an excellent example of why I, for one, don't bother replying 
substantively
to your messages anymore.


And yet, you are going to have to... Because you are not doing your 
removals as an individual committer (if you were, your desire to remove 
a port could've been stopped by *my* desire to keep it). And as long as 
you imply having some sort of governing authority behind you (such as a 
portmgr hat -- permanent or temporary), you need to justify your actions 
to keep the consent of the governed.


But I'm not asking you to reply to the uncivil, sarcastic, and otherwise 
flawed *me*. My proposal was for you and the rest of the "removers" to 
articulate your reasoning on a web-page. That would carry your message 
(calmly thought-through and edited) to all users and colleagues alike, 
including those too polite to question your actions publicly. Please, 
oblige.


On 13.11.2011 16:31, Chris Rees wrote:

Oh my it's two months ago.


Yes. And my recollection from back then is that portmgr was reviewing 
the issue (in the quiet of Olympus away from the noise of all the silly 
mortals) and was going to render their decision (eloquently and 
convincingly to all)... That has not happened, but the removals continue 
to this day...


Can we move on? Ports are deprecated and removed. 
Insecure/unmaintained ports are harmful.


No, we can not move on. It should, by now, be obvious to all, that there 
is no consensus on when a port should be removed. And yet, a fraction of 
the committers take it upon themselves to remove ports based on their 
own credentials -- much to the dissatisfaction of the opposing fraction. 
I fail to see, why or how the opinion of crees@ and dougb@ outweighs 
that of stas@ and mi@. To be sure, both factions have other members, but 
nobody conducted a vote -- and we don't even know, what such a vote 
would mean anyway.


Yours,

   -mi

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

Installing executables with generic names

[Mikhail T.]

Hello!

I'm preparing a new port (net/udt), which installs a library with its 
header file and a handful of sample applications.


The applications are rather generically named: sendfile, recvfile, 
test... Having them in ${PREFIX}/bin

like that would be confusing.

I see two alternatives:

 * use a port-specific prefix for each binary: udt-sendfile,
   udt-recvfile, udt-test, etc.
   or
 * use a port-specific subdirectory: ${PREFIX}/bin/udt/ (lua seems to
   do this)

The first is simpler for me, but might be a trouble for anyone porting a 
script in the future, which calls the binaries by their generic name...


Opinions? Thanks! Yours,

   -mi

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

Re: Installing executables with generic names

[Mikhail T.]

On 14.02.2012 10:25, Michael Scheidell wrote:

EXAMPLESDIR


I thought, EXAMPLESDIR is for actual examples, such as source code, not compiled 
and fully-functional executables... Indeed, the directory is under 
${PREFIX}/share -- which, according to hier(7) is for architecture-independent 
files.


   -mi

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

Re: Installing executables with generic names

[Mikhail T.]

On 14.02.2012 13:17, Ion-Mihai Tetcu wrote:

The other idea of prefixing them is_much_  better.


Ok, so which flavor of prefixing do you prefer? Should the executable "bar" be 
installed as bin/foo-bar or as bin/foo/bar?


   -mi

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

Re: Re: recent portrevision bump for libvpx

[Mikhail T.]

On -10.01.-28163 14:59, Jakub Lach wrote:

Speaking of recent libvpx update, some ports explicitly look
for libvpx.so.0, and fail to update trying to install again libvpx
which is already installed.

e.g. multimedia/gstreamer-plugins-vp8
Yet again I'd like to point out, that -- contrary to the wide-spread 
practice -- ports should not, by default, list a particular shlib major 
number in LIB_DEPENDS. Only in cases, when a wrong version of some 
libfoo is known to cause problems, should the correct version be 
explicitly given in LIB_DEPENDS.


   -mi

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

Re: recent portrevision bump for libvpx

[Mikhail T.]

On 17.02.2012 12:36, Chris Rees wrote:

Yet again I'd like to point out, that -- contrary to the wide-spread
>  practice -- ports should not, by default, list a particular shlib major
>  number in LIB_DEPENDS. Only in cases, when a wrong version of some libfoo is
>  known to cause problems, should the correct version be explicitly given in
>  LIB_DEPENDS.

Perhaps someone could make a patch for the Porter's Handbook.


Last time I broached the subject, I could not get my argument through... I even 
once made a patch, which would've allowed the user (at their own risk) to tell 
bsd.port.mk to ignore all explicitly-specified shlib-major numbers -- and 
portmgr@ shut it down, even though the new flag would not be on by default.


If the consensus has changed over the years, coming up with the new text for the 
manual would not be a problem...


   -mi

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

Re: recent portrevision bump for libvpx

[Mikhail T.]

On 17.02.2012 14:24, Zhihao Yuan wrote:

I regard this as a wrong practice. Here is why:

1. The way you specify the version in LIB_DEPENDS has NO relation with
how the port link to the lib. The port can link to the major version
(pkg-config), or the .so, etc.

I'm sorry, I can not parse the above part. Perhaps, a live example is in order.

2. One responsibility of the ports system is to protect the user from
suffering from running a software which links to a ABI incompatible,
hence, wrong shared library.
This is a made-up non-reason, sorry. The only way to get into an ABI 
incompatibility is to have -- at the time of the port building -- header-files 
declarations from one version of a library and implementation(s) from another. 
Avoiding such situations is out of the scope of the ports-system and this 
discussion.


Again, try to come up with a real-life example of how my proposal would break 
ABI for an actual user... You can not.

3. "Known to cause problem"? Can I infer ""you can predict the future"
from that?
Yes, you can. Well-knowing the past 15 or so years of the ports-system, I can 
predict some aspects of the future. For example:


 * committers will continue to forget to update some of the umpteen instances
   of LIB_DEPENDS=foo.X in various ports, when bumping up major version of foo.
 * committers will continue to /mindlessly/ bump-up these umpteen instances --
   without actually verifying, that the new version of foo is still acceptable
   to all of those dependants.
 * port-building will remain unduly difficult because of the wide-spread
   mindless (mis)use of the major shlib-number in LIB_DEPENDS. Consider the
   following scenario (substitute any of "png", "jpeg", "xml", etc. for "foo"):
1. You build a shiny new machine -- with the desktop of your choice (KDE,
   Gnome, Xfce - whatever) from ports. Hours of build-time interrupted by
   occasional `config' screens...
2. A week later you update your ports tree -- which sees version-bump of
   libfoo.
3. You try to add a foo-using program bar to your computer -- and fail,
   because the bar-port now insists on the very latest version of libfoo.
   Not because the maintainer of bar determined, that the earlier versions
   are bad -- simply because the maintainer of foo went through all
   dependents and updated the LIB_DEPENDS lines in all of them, as is the
   current sad practice.
4. You now have to either portupgrade libfoo -- which means, your desktop
   will be using libfoo.N and the newly-built bar will be using libfoo.N+1
   (inefficient and sometimes a source of problems in its own), or go
   through rebuilding all of the foo-using ports again...


So, to link to a version explicitly should be the default. Only a
library behaviors "good" in its development history can be considered
to use it's libname only in LIB_DEPENDS.
I'm not sure, what you mean by "link to a version". Once again, I beg you to 
offer a live example. Yours,


   -mi

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

Re: recent portrevision bump for libvpx

[Mikhail T.]

On 17.02.2012 17:05, Zhihao Yuan wrote:

On Fri, Feb 17, 2012 at 2:57 PM, Mikhail T.  wrote:

On 17.02.2012 14:24, Zhihao Yuan wrote:

I regard this as a wrong practice. Here is why:

1. The way you specify the version in LIB_DEPENDS has NO relation with
how the port link to the lib. The port can link to the major version
(pkg-config), or the .so, etc.

I'm sorry, I can not parse the above part. Perhaps, a live example is in
order.

LIB_DEPENDS= png.6: or =png: does not affect how the lib got linked.
It always links to the latest libpng the time you compile the port.
Yes, this is correct. But irrelevant, really -- this will remain true, whether 
or not LIB_DEPENDS lines contain explicit library numbers.



2. One responsibility of the ports system is to protect the user from
suffering from running a software which links to a ABI incompatible,
hence, wrong shared library.

This is a made-up non-reason, sorry. The only way to get into an ABI
incompatibility is to have -- at the time of the port building --
header-files declarations from one version of a library and
implementation(s) from another. Avoiding such situations is out of the scope
of the ports-system and this discussion.

Again, try to come up with a real-life example of how my proposal would
break ABI for an actual user... You can not.

This only happens when a minor version of a library is not compatible
with another one. OK, that's out of the scope.


We have not used minor library versions since switch-over to ELF... I do not 
understand, what you are talking about.





3. "Known to cause problem"? Can I infer ""you can predict the future"
from that?

Yes, you can. Well-knowing the past 15 or so years of the ports-system, I
can predict some aspects of the future. For example:

committers will continue to forget to update some of the umpteen instances
of LIB_DEPENDS=foo.X in various ports, when bumping up major version of foo.
committers will continue to mindlessly bump-up these umpteen instances --
without actually verifying, that the new version of foo is still acceptable
to all of those dependants.

My opinion is that, fails to build is not a big trouble, at least we
notified the through portsnap/pkg_version; The user surprisingly finds
that his software fails to run is a bigger trouble.
The existing practice does not protect against this "bigger trouble" either -- 
whenever port installing libfoo.so is updated, all of the ports LIB_DEPENDing on 
foo.X are matter-of-factly updated to LIB_DEPEND on foo.(X+1). At best, these  
updates are verified to continue to /build/ -- but they are never verified to 
continue to /work/ -- although they usually do work, of course.


`cvs log' shows thousands of commit messages matching the pattern "chas.*bump" 
(libvpx included, of course) -- I'd be surprised to learn, the usability test 
was conducted in 1% of these cases...





port-building will remain unduly difficult because of the wide-spread
mindless (mis)use of the major shlib-number in LIB_DEPENDS. Consider the
following scenario (substitute any of "png", "jpeg", "xml", etc. for "foo"):

The updates to major libs always bind to a larger updates in the ports
tree. You have to upgrade all of the ports depend on them no matter
how you use LIB_DEPENDS.
No, I should not have to. I might prefer to, but I should not be forced to do 
it. And what's a "major lib" anyway? Does x264 qualify? If I want to add vlc, 
for example, do you want to /force/ me to rebuild mplayer as well -- because 
x264 went from 137 to 171 since I last built it?

You build a shiny new machine -- with the desktop of your choice (KDE,
Gnome, Xfce - whatever) from ports. Hours of build-time interrupted by
occasional `config' screens...
A week later you update your ports tree -- which sees version-bump of
libfoo.
You try to add a foo-using program bar to your computer -- and fail, because
the bar-port now insists on the very latest version of libfoo. Not because
the maintainer of bar determined, that the earlier versions are bad --
simply because the maintainer of foo went through all dependents and updated
the LIB_DEPENDS lines in all of them, as is the current sad practice.
You now have to either portupgrade libfoo -- which means, your desktop will
be using libfoo.N and the newly-built bar will be using libfoo.N+1
(inefficient and sometimes a source of problems in its own), or go through
rebuilding all of the foo-using ports again...

I regards what you said above as the regular routine, and I can't see
how your practice can improve such a routine.


If the port bar is willing to compile against /any/ version of libfoo (and the 
vast majority of ports are), then the problem I described will not strike anyone 
-- bar will built against whatever libfoo is already installed on the building 
computer, and that's it. The user still has an option to upg

Library numbers in LIB_DEPENDS considered harmful (Re: recent portrevision bump for libvpx)

[Mikhail T.]

On 17.02.2012 17:05, Zhihao Yuan wrote:

LIB_DEPENDS= png.6: or =png: does not affect how the lib got linked.

Allow me to rephrase my argument from a different perspective...

The language used in our ports' Makefiles is, largely, /declarative/ -- various 
things are declared and then bsd.port.mk (and friends) interpret them to do the 
right thing.


Each declaration is meant to say something, so let's examine, what a LIB_DEPENDS 
entry declares:


   LIB_DEPENDS=foo.V:${PORTSDIR}/cat/libfoo

The above line says, that this port needs a shared library libfoo.so.V to be 
installed. It also says, how to install it, if it is not already present at 
build-time.


If, in fact, the current port does not care, which version of libfoo is uses -- 
and most software does not -- then declaring an explicit V is wrong: it 
/gratuitously/ tightens the build-time requirements. Unless a particular version 
is, indeed, required, the above line should read simply:


   LIB_DEPENDS=foo:${PORTSDIR}/cat/libfoo

Let's say, you sent someone to buy a bottle of dry red wine in a store. Wouldn't 
you be (unpleasantly) surprised, if he returned empty-handed, because the store 
did not have any Californian Pinot Noir of the 2003 vintage? Huh? You did not 
ask for Pinot Noir. You did not specify the origin nor the year either -- why 
did not he get something else that matched your much wider and easier-to-satisfy 
requirement: "dry red wine"?


A similar thing happens here: if the, say, vlc software needs libx264 to be 
available at build time, the FreeBSD port of vlc should not add a requirement of 
a particular version to that.


   -mi

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

Re: how do you specify a minimum lib version?

[Mikhail T.]

On -10.01.-28163 14:59, Michael Scheidell wrote:

in LIB_DEPENDS
it won't take anything like:

= boost_serialization>=.4

what if you needed a minimum version of the library?


For years now the shared-library's major number is treated as a regular 
expression by bsd.port.mk.


So you could use something like:

   LIB_DEPENDS=boost_serialization.[456789]:...

this should be enough for a while -- until there appears boost_serialization.10, 
necessitating a hairier regexp. ImageMagick port uses this to depend on the 
fixed version of libfpx, for example.


You may also be able to insist on the version of the boost port being above a 
certain string, but I don't know the syntax... Yours,


   -mi

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

pgtclng port (Re: FreeBSD ports which are currently scheduled for deletion)

[Mikhail T.]

On 21.03.2012 08:00, M. Linimon wrote:

portname:   databases/postgresql-tcltk
description:A TCL interface to the database PostgreSQL, including
 a tk GUI
maintainer:pg...@freebsd.org
status: BROKEN
deprecated because: Broken for months with no-one caring, superseded by
 http://pgtclng.sourceforge.net/
expiration date:2012/03/16
build errors:
http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.7.20101015091133/postgresql-tcltk-7.4.30_2.log.bz2
  (_Oct_16_11:22:03_UTC_2010)
overview:http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=postgresql-tcltk
pgtclng is available via databases/pgtcl. Maybe, this will be worth a 
mention in MOVED, when the axe falls...


   -mi

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

Re: FreeBSD Port: minidlna-2010.12.12

[Mikhail T.]

   On 04.02.2011 05:50, Jan Solc wrote:

   With help from the maker of miniupnpd I have done patches for
   minidlna.

   patch-ssdpd - minidlna can use minissdpd when you need using more upnp
   services at once (in example miniupnpd and minidlna simultaneously).
   patch-zsamsung - it's latest patch for better cooperation with samsung
   televisions

   Thank you very much for the work. If you have an account on
   SourceForge, please, [1]submit your patches to the developer directly.
   I will try to add them to the port in parallel, but for them to get
   into the official tree, somebody has to send them to the author.
   Ideally that would be you... That said, there are already patches
   submitted for the things you mentioned:
 * [2]patch to use MiniSSDPd if available (3170970)
 * [3]Samsung support with optional Thumbnails (3148380)
 * [4]Display thumbnail on Samsung C Series (2010 models) (3090002)
 * [5]Basic Samsung TV xxC650 support v2 (3084362)

   Any of these your doing?
   If you don't have a SourceForge account (and don't want to create
   one), I'll do it in your stead, but then any questions/comments the
   developer may have will, likely, have to go through me -- with
   inevitable latency...

   Thanks again. Yours,

 -mi

References

   1. http://sourceforge.net/tracker/?group_id=243163&atid=1121518
   2. 
http://sourceforge.net/tracker/?func=detail&aid=3170970&group_id=243163&atid=1121518
   3. 
http://sourceforge.net/tracker/?func=detail&aid=3148380&group_id=243163&atid=1121518
   4. 
http://sourceforge.net/tracker/?func=detail&aid=3090002&group_id=243163&atid=1121518
   5. 
http://sourceforge.net/tracker/?func=detail&aid=3084362&group_id=243163&atid=1121518
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Re: saving a few ports from death

[Mikhail T.]

On -10.01.-28163 14:59, Robert Huff wrote:

It is also possible it is only important to a fairly small
number ... but to those it is absolutely crucial.

Or the port might become useful/essential/critical to somebody in the future...

What is not broken -- just old, like  databases/db2 or www/apache13*, for 
example -- should be left alone (until it becomes both broken and unmaintained). 
And even then, the removal should not be mass-scale/automatic...


Maybe, for cleanliness and neatness, we should have a separate directory (and 
category): "obsolete" -- where ports can go to die peacefully. But it should not 
be cvs' "Attic"...


   -mi

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

Re: saving a few ports from death

[Mikhail T.]

On 27.04.2011 14:16, Eitan Adler wrote:

Then bapt@ marked the ports*deprecated*  which does not mean deleted. It was a 
warning that people who were interested should step up and take up the work. If 
after N amount of time no one does so they will be individually deleted.
The ports I listed -- db2 and apache13* family -- are/were not broken. What 
"work" are you talking about?


Yet, mandree deleted db2 on April 12th and dougb is anxious to delete apache13 
as well instead of simply disowning it...

>  Maybe, for cleanliness and neatness, we should have a separate directory
>  (and category): "obsolete" -- where ports can go to die peacefully. But it
>  should not be cvs' "Attic"...

Who will be the ones to deal with that category, ensuring new
infrastructure works, etc? The port maintainer? oh wait!
The same entity(ies), that currently busy themselves marking things 
"deprecated". But it was just a proposal -- for those, who don't like to see 
"obsolete" software mixed with the latest and greatest. I'm perfectly satisfied 
with not touching "obsolete" things at all. Certainly not until they break -- 
and stay broken for "too long".

cvs's Attic can be easily restored if people take up the slack. I see
no reason to change this policy
No, not easily. It requires the CVS tree, which is not automatically installed. 
/usr/ports/obsoleted, on the other hand, would be rolled out together with the 
rest of the ports-tree. And, under my proposal, the packages for the "obsolete" 
stuff will continue building.


The "if people take up the slack" seems to imply need to continuously work on 
the software. But the db2 needed no serious changes since 2004 and the last 
meaningful change was in 2008... The only reason to kill it was "too old"... Now 
all current users of db2 have to move onto later dbX, which means not only 
patching up the API-calls in their source-code (if the source code is even 
available!), but recreating their databases too -- because Berkeley DB files are 
not backwards-compatible. And for what reason?..


Same goes for apache13 -- last change was an upgrade to 1.3.42 (February 2010) 
-- it does not seem to require much work. There may well be good reasons to hate 
it, but somebody with a custom module, for example, may be perfectly satisfied 
with it... I happen to know one such site, for example. There may be more. If 
apache@ does not want it, they can drop maintainership. But deletion is not 
called for.


Upgrading the OS should not /require/ upgrading (and replacing!) the 
applications.

Yours,

   -mi

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

Re: saving a few ports from death

[Mikhail T.]

On 27.04.2011 16:47, Wesley Shields wrote:

apache13 is EOL upstream. We should not have ports for EOL software.

Why not, exactly?..

If upstream says it's dead, who are we to keep it alive?
We are a major Operating System project, which maintains ports of third-party 
applications for the convenience of our users. An EOL-declaration by the authors 
does not mean, the users must stop using it immediately -- it simply says, the 
authors will not be releasing updates/bug-fixes.


   -mi


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

Re: saving a few ports from death

[Mikhail T.]

Eitan, you are entitled to your opinions, but not to your own facts. My factual 
corrections are inline below. Arguing about opinions and policy is useless until 
the facts are accepted as such by all participants:


On 27.04.2011 16:54, Eitan Adler wrote:

The upstream maintainer already called it "end of life". FreeBSD does
not and will not ever take over the development of dead upstream ports
(and in this case there is a upstream version)
I never suggested, we undertake /development/ of upstream software -- EOLed or 
not. Fact 1.

The same entity(ies), that currently busy themselves marking 
things>"deprecated".

The ports marked "broken with no one to fix them" (shortened to
'deprecated') take a significant amount of time and energy to fix.

db2 was not broken. Neither is apache13... Fact 2.

Which is a *major* drain of resources.
"Major"? Didn't you say earlier, that the most recent sweep -- only deleted 
about 3% of the ports? I'd say, this is Fact 3, but, maybe, even 3% qualifies as 
"major" in your view... And was not this sweep the largest in our history?

What you fail to understand is that we are NOT marking ports as
'obsolete' or 'bad' or 'there exists a better program' but as broken
and unmaintained.
I can only repeat the example of db2. It was never broken, but deleted 
nonetheless... The same is about to happen to apache13...


   -mi

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

Re: ports/155759 - bad reasons for ports removal -- again

[Mikhail T.]

On 23.05.2011 06:42, Matthias Andree wrote:

In your particular case, you as the maintainer remained silent on the
relevant PR although Erwin and I have pointed you to it on March 21st
This is true -- I was silent on the PR. My earlier objection was to my alleged 
"silence" on ports@

and your ports were broken since the db2 removal in April.
Yes, they were. The person(s) behind that gratuitous removal is/are responsible 
for the breakage of tcl-neo*

Conclusion: neowebscript is not only unmaintained in ports, but
also unmaintained upstream.
Both were maintained in the ports as much as was needed to ensure successful 
builds -- until some busybody came along to remove the perfectly functional 
databases/db2 -- on bogus grounds.

I do concur with Wesley Shields and Eitan Adler that we don't need
unmaintained software in the ports tree
I'm well familiar with this line of reasoning and reject it. As long as the port 
builds -- and has no known unpatched security holes -- it is "maintained" and 
should not be removed. All other reasons: "too old", "not used by anybody I 
know", etc. are subjective and are based of non-existent statistics. Though 
tcl-neo* themselves stopped building, this was a result of the (gratuitous) 
removal of db2 -- and whoever was behind that removal, was supposed to fix the 
fallout, or, better yet, find some other application for their energy.


That a package is discontinued up-stream is not a good reason for removal at all 
-- not until you remove games/bsdgames and the entire KDE3 (for just some 
examples)...


That said, I'm not insisting, the ports be resurrected and will not be doing it 
myself out of spite. I'm no longer using the software, and neither does the 
client, for whom I originally ported it. But I don't like this drive to remove 
working ports, in which the energetic removers see no value personally, and 
restate this position again because, evidently, certain active decision-makers 
weren't aware of it...


Yours,

   -mi

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

Re: ports/155759 - bad reasons for ports removal -- again

[Mikhail T.]

On 23.05.2011 11:24, Matthias Andree wrote:

discontinued more than ten years ago, but in the case of Berkeley DB 2.7.7, 
superseded as well.


These -- being "too old" (BSD's hack is much older, BTW) or "superseded" -- 
aren't valid reasons in my opinion. As long as a package keeps building -- and 
there were no problems with it, when db2 was removed -- it should not be 
deleted. Ever. Even the maintainer (who does "know best", how to maintain it) 
can't remove it -- only disown it.


   -mi


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

Turning APNG to on by default in graphics/png

[Mikhail T.]

I'd like to see this option on by default now. I think, it's been available (off 
by default) long enough and I, for one, always turn it on for completeness. 
There used to be concerns about security of animated PNG code, but today I can 
not find any advisories fresher than 2008:


   http://osvdb.org/show/osvdb/48766

Various Mozilla applications will then be able to LIB_DEPEND on the installed 
png instead of building their own versions.


Comments? Thanks!

   -mi

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

Re: Turning APNG to on by default in graphics/png

[Mikhail T.]

On 25.05.2011 15:02, Andrey Chernov wrote:

There used to be concerns about security of animated PNG code, but today I can
>  not find any advisories fresher than 2008:
>  
>   http://osvdb.org/show/osvdb/48766

Wrong place to find advisores related to subj. See
http://www.libpng.org/pub/png/libpng.html
page, right below yellow tables. Latest one fixed Feb 3 2011.
Your link has no information on ANIMATED png. The ANIMATED functionality has no 
advisories since 2008...

>  Various Mozilla applications will then be able to LIB_DEPEND on the installed
>  png instead of building their own versions.

FYI: apng is quick hack to overcome animated gifs limitations and libpng
author is strongly against it, suggesting to use more flexible mng
instead:http://www.libpng.org/pub/mng
I have this information -- this was discussed (with your and my selves present) 
back in 2008. But we are not going to change the way Mozilla projects are going 
about this... Our options at this point are:


 * continue building a private libpng as part of each Mozilla application -- a 
silly redundancy of patches and waste of time and space;
 * make a separate port (apng or mozilla-png) -- making sure, it does not 
conflict with the "official" png;

 * just turn the APNG option on by default in the existing png port...

I think, the third options is the easiest -- and it has NO downsides... Yours,

   -mi

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

Re: Turning APNG to on by default in graphics/png

[Mikhail T.]

On 25.05.2011 17:37, Andrey Chernov wrote:

If only FF wants hacked library, there is no point to make even
separated port.
Certainly thunderbird too. Not sure about others, but, likely, www/libxul too -- 
and www/seamonkey2. Worse: we tend to have multiple versions of some of those in 
the tree (for example: mail/thunderbird, mail/thunderbird3, 
deskutils/lightning-thunderbird, www/firefox, www/firefox3, www/firefox35).

Making APNG default is an additional security risk since
another vulnerability may be founded in the APNG extension in the future
will affect all programs at once, i.e. we'll have png risk + apng risk as
result.
In theory, EVERY additional feature is an additional security risk :) But APNG 
has not had an issue in three years.

Moreover, APNG development is always behind official png in time,
so fixing vulnerabilities will be not as fast as now.
APNG-patched areas aren't usually, where the stock PNG is affected by security 
problems -- or else APNG would've been implicated in more advisories.


In short, it does not seem, APNG is any riskier than the PNG itself...

And now consider this -- the number one "vector" for security threats is through 
malicious files e-mailed or injected into web-servers... And those are accessed 
by e-mail programs and browsers. So, users of Firefox and Thunderbird (the 
primary tools today -- and thus the first to be targeted by miscreants) will be 
affected by any future APNG-bug /anyway/. My way, at least, the fix will require 
updating only a single port on one's machine...


Yours,

   -mi

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

Re: Re: GPC 2006 (Pascal) -- deprecated or "expired"??

[Mikhail T.]

On -10.01.-28163 14:59, Matthias Andree wrote:

Call it dying or undead then. That's usually not reason enough for
someone who does not _need_ the port (for something other than to put it
on display, that is) to invest time.
If it is not dead, it should not have been removed... (Temporary) 
absence of maintainer is not a good reason for removal.


Sadly, this appears to be yet another manifestation of the bright new 
idea, that the comfort of port-managers is more important than the 
availability of software.


Least somebody else claims again, that there is "consensus" on the issue 
of removing ports, let me state my dissenting opinion once again: the 
only good reason (other than licensing/legal) to remove a port is when 
it remains broken -- due to changes in the base OS -- for "too long".


Changes to ports infrastructure or in other ports, that break a 
particular port, do not count -- if any such changes break a port, then 
the changes ought to be backed-out immediately. Not even the maintainer 
can "kill" a port -- they can only disown it.


By all appearances, lang/gpc is just another victim of the new policy, 
where ports are removed on the personal decisions of people with enough 
free time to make them. Such approach is prone to mistakes and subtle 
favoritism -- for there are no reliable statistics on which ports are in 
use, nor how vitally important a particular one is to its user-base 
(however small).


Traffic on ports@ is not indicator of the users' preferences whatsoever.

Although most open-source applications out there offer pre-compiled 
Linux binaries, FreeBSD's  ports offered a compelling alternative by 
providing the same applications carefully integrated with the best Unix 
in the world. If we continue to capriciously drop ports for no other 
reason than that a group of 10-15 (if that many!) considers it 
"obsolete" or "dying", we will be losing that competitive advantage.


Yours,

   -mi

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

Re: GPC 2006 (Pascal) -- deprecated or "expired"??

[Mikhail T.]

On 04.06.2011 18:27, Doug Barton wrote:
The math on this is simple, there are maintainers willing to do the 
work, or not.
It does not matter, whether there are any such maintainers, /if there is 
no work to do/. Neither lang/gpc nor databases/db2 (for one more 
example) required a maintainer at all, when they got "pre-emptively" 
killed...
Rehashing the arguments about how nice it would be to keep every port 
in the universe isn't going to get us anywhere. 
Every port in the universe (interestingly, all of them happened to be in 
the Solar system), /that continues to build through changes in the base 
OS/. That's quite achievable -- in fact, we had just that until fairly 
recently...


   -mi

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

Re: GPC 2006 (Pascal) -- deprecated or "expired"??

[Mikhail T.]

On 05.06.2011 12:43, Matthias Andree wrote:

Let it rest.  You could have offered to maintain it, but you didn't.
This is nonsense. *I* don't care for *this* port. *I* wrote *my* last 
Pascal program twenty years ago in 1991. My objections is to the 
/policy/, which leads to the removal of perfectly-building ports, such 
as lang/gpc (and databases/db2 before it) based on subjective decisions 
of fallible humans.


This policy makes but a dent in the total size of the ports tree -- and 
the associated costs of storage, bandwidth, and processing power. But it 
is likely to cause great inconvenience to some user(s), who may some day 
decide to upgrade their trusty old FreeBSD server to a trusty new 
FreeBSD server only to discover, that the piece of software, that's of 
some importance to them, is no longer available as a port.


And while we can't fix everything, what is broken, we should not be 
preemptively removing, what is not.


   -mi

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

audio/adpcm (Re: FreeBSD unmaintained ports which are currently scheduled for deletion)

[Mikhail T.]

On -10.01.-28163 14:59, lini...@freebsd.org wrote:

portname:   audio/adpcm
description:An Intel/DVI IMA ADPCM codec library
maintainer:po...@freebsd.org
deprecated because: No more public distfiles
expiration date:2011-09-01
build errors:   none.
overview:http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=adpcm

At least in this particular case, I don't think, the removal is warranted.

The public distfiles disappeared not because of a deliberate action by 
the developer or copyright-holder, but simply because the entire 
ftp.cwi.nl is now gone. Sites continue to host the file -- we should 
allow CWI.net to sort things out with their FTP-server (or, perhaps, 
they intend to offer the same code over HTTP later).


   -mi

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

Re: audio/adpcm (Re: FreeBSD unmaintained ports which are currently scheduled for deletion)

[Mikhail T.]

On 22.08.2011 04:46, Chris Rees wrote:

On 22 August 2011 03:24, Mikhail T.  wrote:

On -10.01.-28163 14:59, lini...@freebsd.org wrote:

portname:   audio/adpcm
description:An Intel/DVI IMA ADPCM codec library
maintainer:po...@freebsd.org
deprecated because: No more public distfiles
expiration date:2011-09-01
build errors:   none.

overview:http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=adpcm

At least in this particular case, I don't think, the removal is warranted.

The public distfiles disappeared not because of a deliberate action by the
developer or copyright-holder, but simply because the entire ftp.cwi.nl is
now gone. Sites continue to host the file -- we should allow CWI.net to sort
things out with their FTP-server (or, perhaps, they intend to offer the same
code over HTTP later).

Could you add those extra sites to MASTER_SITES then please?


None of them are "official" -- and various web-pages continue to refer 
to ftp.cwi.nl as the source.


Since FreeBSD mirrors already provide unofficial mirrors, is there a 
point in adding those at this time?


   -mi

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

Re: freebsd-ports Digest, Vol 474, Issue 7

[Mikhail T.]

On 21.06.2012 04:30, freebsd-ports-requ...@freebsd.org wrote:

portname:   x11/etoile
description:Metaport for Etoile desktop
maintainer:po...@freebsd.org
deprecated because: API no longer supported
expiration date:2012-07-20
build errors:   none.
overview:http://portsmon.FreeBSD.org/portoverview.py?category=x11&portname=etoile
The entire etoile is being ripped out for a reason of "API no longer 
supported"... Could the powers that be elaborate, what this means, 
please? Which API?


The version in ports is 0.4.1. Visiting the project's web-site 
(http://www.etoile-project.org/) shows version 0.4.2 available since 
April. Thanks!


   -mi

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

etoile ports dropped for strange reason (Re: freebsd-ports Digest, Vol 474, Issue 7)

[Mikhail T.]

On 21.06.2012 06:54, Michael Scheidell wrote:

you are more then welcome to adopt them.

Is the above REALLY, what "API no longer supported" means these days?

   -mi

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

Re: etoile ports dropped for strange reason (Re: freebsd-ports Digest, Vol 474, Issue 7)

[Mikhail T.]

On 21.06.2012 11:37, Wesley Shields wrote:

The release in our ports tree is not recommended upstream anymore.
Quoting the upstream webpage: "Take note they [old releases] won't
usually work with recent LLVM and GNUstep releases."

Do we have these recent LLVM and GNUstep releases in the tree already?

As the port is unmaintained and the version in our tree is not
recommended for use anymore it was deprecated. Sure, the reason could be
more clear. I will commit an update that reflects that to make it more
clear.

If you would like to see this port remain in the tree I recommend
adopting it and keeping it in working order (first step is to update it
to a recommended release).
The chance of a new maintainer stepping up may increase, if the "deprecation" 
message states something like "Update to a new release is required"... And, of 
course, a more generous expiration time would be needed. These ports are a legion...


Yours,

   -mi

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

How to fetch files from GitHub?

[Mikhail T.]

Hello!

I've created a port of bittorrent-libutp -- a piece of software, that has not 
been officially "released" yet. It is in use by a number of other projects (like 
net-p2p/transmission/). The not-yet-committed port can be found at:


   http://aldan.algebra.com/~mi/port-stuff/libutp.shar

The vendor's code is hosted on GitHub, which allows downloading the entire 
directory as a single tarball. However, to download sources as of particular 
date/time, one has to use a hash of the version one cares for.


For example, the current version's tag is d4685a3. If you attempt to download 
the tar.gz from the https://github.com/bittorrent/libutp/downloads, you will get 
a file named: bittorrent-libutp-d4685a3.tar.gz.


Setting MASTER_SITES to https://github.com/bittorrent/libutp/tarball/d4685a3/ 
works, but the download is a redirect...


The port builds fine, but has two nasty problems:

1. The DISTVERSION being simply the first 7 characters of some hash will not be
   sequential -- the next release of the sources may have a hash, that will
   sort below the current one, necessitating an ugly PORT_EPOCH bump. The
   PORTVERSION ends up being "d4685.a3", which is not at all useful, but
   forcing one's own PORTVERSION (something like 0.20120726) is not allowed...
2. Fetching the code requires forceful removal of the -A option from fetch(1)'s
   arguments.

Would anyone care to play with the port as posted and offer suggestions on how 
to best resolve the two problems (other than hosting the tarball on my own)?


Thanks! Yours,

   -mi

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

Re: How to fetch files from GitHub?

[Mikhail T.]

On 26.07.2012 19:41, Bryan Drewery wrote:

Check out ports-mgmt/portupgrade-devel for an example.

It uses a known hash, but you can use tags as well.
Thanks for the pointer! Yes, that's it... The port uses a separate 
variable (GITVERSION) instead of just calling it DISTVERSION -- no 
doubt, to appease portlint, which complains, when DISTVERSION and 
PORTVERSION are specified at the same time. This work-around 
necessitates two extra lines in the Makefile without being otherwise 
useful...


I think, I'll just call the hash "DISTVERSION" and also explicitly set 
the PORTVERSION -- to 0.20120726. (The 0.-prefix may help in the future, 
when the upstream finally release version 1.0 :-)



You'll need to override FETCH_ARGS as seen there too.

Yes, that works, thank you!

   -mi


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

Re: graphics/libfpx: use of bsd.lib.mk and warnings

[Mikhail T.]

On 28.07.2012 13:46, Andriy Gapon wrote:

I very much wonder how the above email ended up having From: set to_my_  email
address.
My apologies. Thunderbird's "Virtual Identity" extension got confused 
and I failed to notice :( I am sorry.


   -mi


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

Re: graphics/libfpx: use of bsd.lib.mk and warnings

[Mikhail T.]

On 28.07.2012 12:25, Thomas Zander wrote:

It also causes the port to use clang when setting CC=clang in
/etc/src.conf (!) which fails here.

What if you use CC?=clang instead? Thanks,

   -mi


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

Re: Some success; some problems with x11/nvidia-driver-460.39_1

[Mikhail T.]

On 07.02.21 09:05, David Wolfskill wrote:

| pkg-static: Unable to access file 
/common/ports/x11/nvidia-driver/work/stage/common/local/share/vulkan/icd.d/nvidia_icd.json:No
 such file or directory
| pkg-static: Unable to access file 
/common/ports/x11/nvidia-driver/work/stage/common/local/share/vulkan/implicit_layer.d/nvidia_layers.json:No
 such file or directory


FWIW, I reported this particular problem a few days ago:

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

Yours,

   -mi

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

Should USE_UNZIP be deprecated?

[Mikhail T.]

tar(1) has been able to extract .zip files for quite a while now. Is it 
time to deprecated USE_UNZIP knob?


The ports, that use it without also altering 
EXTRACT_{BEFORE|AFTER}_ARGS, can, probably, be in the first wave -- 
simply removing the knob from them should do the trick...


For the rest, portlint can be taught to warn about it...

Or do we still support OS-releases, where tar was not so advanced? Thanks,

   -mi

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

Why delete KDE3 ports?

[Mikhail T.]

On 07.01.2013 03:33, freebsd-ports-requ...@freebsd.org wrote:

portname:   accessibility/kdeaccessibility
description:Accessibility applications for KDE
maintainer:po...@freebsd.org
deprecated because: Depends on QT3; unmaintained
expiration date:2013-07-01
build errors:   none.
overview:http://portsmon.FreeBSD.org/portoverview.py?category=accessibility&portname=kdeaccessibility
Once again a working port (no build errors) is scheduled for deletion on 
the grounds of simply being "unmaintained".


Please, reconsider deleting this and other KDE-3 ports.

   -mi

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

Re: Why delete KDE3 ports?

[Mikhail T.]

On 07.01.2013 09:41, David Demelier wrote:

Because Qt3 is old and KDE3 will completely disappear.
This is exactly the sentiment I find disagreeable -- that simply being 
"old" is enough to condemn a perfectly functional piece of software.


Maybe, it is because of my own age, that I am -- in the back of my mind 
-- becoming concerned, the sentiment may get applied to humans as well. 
But, more likely, it is simply because it does not make sense...


I think you should look at trinity. It is a fork of KDE3 and is in 
development to be ported to Qt4 :)
Yes, I looked at it, and may even port it some day -- if I find a 
collaborator or two. In my opinion, absent the other "prong", Trinity is 
not even a "fork", but the actual next version of KDE3 (something, KDE4 
is not).


But, until then, deleting KDE3 ports -- which continue to build fine -- 
seems wrong.


   -mi

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

Re: Why delete KDE3 ports?

[Mikhail T.]

On 07.01.2013 09:54, Kimmo Paasiala wrote:

Are you willing to step up as the maintainer of the KDE3 ports? Or
anyone else reading this? The situation with ports like KDE3 is that
they are lots of work to keep up in shape and if no one wants to
maintain them they succumb to what is called "bitrot" very quickly
when something changes in dependent ports or in the base system.
When/if that happens, we can renew the conversation. For the time being 
there are no build errors.


   -mi

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

Re: Why delete KDE3 ports?

[Mikhail T.]

On 08.01.2013 19:02, Jakub Lach wrote:

I'm on the fence. It's true, that there is no low-print feature complete
equivalent for KDE3.
Worse, KDE4 is not only much heavier (which could've been acceptable). 
It is also not compatible -- people like myself, who customized their 
desktops with additional menus, who created knotes, etc. will have to 
redo all of their settings. KDE4, as built, is not even going to look 
under the ~/.kde. Though it can be compiled to consider the old 
directory, the format/syntax for many of the config-files has changed -- 
and there is no "upgrade path".

On the other hand, if nobody wants to maintain Trinity, well
it should be letten go, as sooner or later there will be problems.
Before becoming "maintained", Trinity first needs to be ported -- a 
substantial effort, because, for example, the project switched to its 
own verstion Qt (Trinity Qt). All classes have been renamed from Qfoo to 
TQfoo...


This can all be handled, but meanwhile, until there ARE actual problems, 
leave the ports alone, please.


   -mi

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

Re: Why delete KDE3 ports?

[Mikhail T.]

On 09.01.2013 14:53, Adam Vande More wrote:
I don't use knotes, but have you tried the solution here? 
http://forum.kde.org/viewtopic.php?f=22&t=84823
Obviously, knotes was just an example. All other customizations (such as menus, 
backgrounds&screen-savers, email accounts -- everything under ~/.kde) have to be 
redone too and, frankly, I do not trust today's KDE project to not do the same 
nonsense again, when they decide to abandon KDE4 for 5 (can't be long now that 
the release is 4.8).


The very existence of the project Trinity is a sign, that my opinion is shared 
by a few more people.


This can all be handled, but meanwhile, until there ARE actual problems,
leave the ports alone, please.


"Actual problems" have already been cited for it.
No, they have not. The minor security threat cited is easily managed by simply 
not using kdm on a system, where less than trusted users have access. kdm is a 
minor part of KDE anyway (I, for one, use xdm).

Fighting change can often lead much more wasted

Yes, it often can. But not in this case. Yours,

   -mi

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

Re: Re: ports include /etc/src.conf? i.e. graphics/libfpx

[Mikhail T.]

13.02.2013 11:22, O. Hartmann написав(ла):
>> > If this is taken literally then could it be said that ports that use
>> > bsd.lib.mk are broken because they are using makefile includes from
>> > the source tree?
>> > 
>> > -Kimmo
For one, the particular port (its Makefile.bsd) was created in 2001,
five years before src.conf appeared. The intent of creating a separate
src.conf, I believe, was to shield a world-build from "crazy" options
someone could've put into their make.conf for the benefit of building a
port or two... But I may be mistaken.
> I would consider them broken!
On the contrary. I wish, more ports were using the system's bsd.*.mk
collection -- instead of the godawful autoconf, for example. What does
the port's Makefile.bsd say? It says: "These are the sources, this is
the name of the library I want. Please, create it." That's all... It is
how things are supposed to be, in my opinion. If the bsd.*.mk collection
was not meant to be used outside of /usr/src, then it wouldn't be
installed (under /usr/share/mk) for the decades, that BSD exists.

Maybe, the bsd.*.mk collection should be smarter -- and not include
src.conf -- when .CURDIR is outside of /usr/src. I'm not sure...
> How could I track down problems if they are results of intermixed config
> files when the manpage explicitely tells me, that the /etc/src.conf is
> only for the build of the operating system?
If the manual says that, it is incorrect -- if only because it does not
reflect (as you've experienced) the practice, that existed long before
the manual was written. As for your tracking down problems, I'd say, it
should be very easy for you to recognize the flags you've added by hand
-- even if you've added them to where you believed, they would not
affect a port.

-mi

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

Re: ports include /etc/src.conf? i.e. graphics/libfpx

[Mikhail T.]

14.02.2013 08:02, Tom Evans написав(ла):
> I think src.conf is meant only to be included when building src. For
> example, bsd.port.mk sets _WITHOUT_SRCCONF before including bsd.own.mk
> (which is the makefile that includes src.conf). It's done this since
> src.conf was added in 2006, so evidently ports are, by design, not
> supposed to include src.conf. 
Awesome. All that's missing then, is for _WITHOUT_SRCCONF to be
automatically added to MAKE_ENV...
>>> I would consider them broken!
>> On the contrary. I wish, more ports were using the system's bsd.*.mk
>> collection -- instead of the godawful autoconf, for example.
> Er? What port uses autoconf for driving the building the port? A lot
> of ports have build systems that use autoconf, but determining how to
> build is always driven by *.mk.
>
> I don't think part of porting to FreeBSD should be rewriting how the
> package builds itself.
Hundreds of ports rely on auto-something bundled with the vendor's
sources, that's what I meant. As for how to build a particular package,
that's up to the port-maintainer.
> Either the documentation is wrong, and should be changed, or this
> singular port is not behaving as it should.
I may sound defensive here, but I'll still repeat, that "this singular
port" (and I do, in fact, have other ones like it) started using
bsd.lib.mk 5 years before src.conf (and its man-page) was added to the tree.

-mi

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

Re: ports include /etc/src.conf? i.e. graphics/libfpx

[Mikhail T.]

14.02.2013 08:55, Tom Evans написав(ла):
> On Thu, Feb 14, 2013 at 1:12 PM, Mikhail T.  wrote:
>> > I may sound defensive here, but I'll still repeat, that "this singular 
>> > port"
>> > (and I do, in fact, have other ones like it) started using bsd.lib.mk 5
>> > years before src.conf (and its man-page) was added to the tree.
>>
> This is true. But what is the bug, that the port's Makefile.bsd was
> not updated on the introduction of src.conf to DTRT (and no-one
> noticed for 7 years), or that the purpose of src.conf has been
> mistakenly documented for 7 years?

I think, the bug is either in documentation or implementation of
src.conf (if it had to be implemented at all, that is) -- there was
never (and still is not) any suggestion, that bsd.{prog,lib}.mk are not
supposed to be used by other people's software.

Maybe, if the file is really meant to be used by *world and *kernel
targets, the knob should've been _WITH_SRCONF -- and added to the
environment by src/Makefile? Because, forget ports for a second, what if
my own little project uses bsd.prog.mk -- because Makefiles using it
tend to fit in a window without scrolling?

I'd say, the documentation should be updated to state, that src.conf
will affect anything, that uses bsd.*.mk family of makefiles, unless
_WITHOUT_SRCCONF is set. The entire /usr/src as well as "some of the
ports" may then be listed as examples of the areas affected. This will
reflect reality and help avoid frustration that O. Hartmann went through.

-mi

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

Re: ports include /etc/src.conf? i.e. graphics/libfpx

[Mikhail T.]

14.02.2013 09:34, Peter Pentchev ???(??):
However, there is then the argument of "well, if you want to use the bsd.*.mk 
infrastructure, then why don't you just copy it into your project and include 
it from there - just like many, many projects do with, say, the sys/queue.h 
header, or parts of libc, or whatever?" And it is, indeed, a very good argument
Either I completely misunderstand the argument, or I disagree -- strongly -- 
with it. Including bits created and maintained by others into your own project 
is very rarely justified (although done quite often). I don't see, why adding 
(some version of) bsd.lib.mk and friends into every project, that wishes to 
build a shared library on FreeBSD, is any more justified, than bundling libjpeg 
with every graphics application.


John-Mark also just posted a strong argument for using the existing bsd.*.mk 
family of makefiles...
since this is how a software distribution's parts are supposed to be used - 
you copy them into your project and use them even when they are not available 
on the host system. So one might argue that the port is, indeed, buggy, that 
the src.conf documentation is, indeed, correct, and that the proper way for 
people to use the bsd.*.mk
The documentation is, demonstrably, incorrect -- it was incorrect, when it was 
written 7 years ago, and remains so. Because a user of bsd.*.mk /will be/ 
affected by src.conf -- unless he takes special steps to prevent it. This fact 
can not be fixed by a user, the only way to avoid the effect, is to modify their 
own makefile(s).


The implementation of the change may be blamed for this -- if, indeed, there was 
a need for src-only configuration knobs, src.conf should be included, when a 
special flag is present in the environment (put there by src/Makefile), not the 
other way around.
some weird src.conf settings might confuse the build of some of my software on 
FreeBSD.
And some of those settings are required for healthy building of some of the 
ports... For example, libreoffice "knows" out of the box, that FreeBSD has 
Kerberos libraries. So, if your world was built WITHOUT_KERBEROS and 
WITHOUT_GSSAPI, libreoffice fails to configure. A simple patch like:


   +.if defined(WITHOUT_KERBEROS)
   +CONFIGURE_ARGS+=   --without-krb5
   +.endif
   +.if defined(WITHOUT_GSSAPI)
   +CONFIGURE_ARGS+=   --without-gssapi
   +.endif

could help, but WITHOUT_KERBEROS and WITHOUT_GSSAPI are set in src.conf and not, 
normally, available to the ports...


So, in my opinion, the manual (src.conf(5)) should be updated to reflect 
reality. Or, if the separation is really deemed desirable (something I, for one, 
continue to question), the implementation (in /usr/src/Makefile and bsd.own.mk) 
needs to be altered to only consider src.conf, when world/kernel are being 
built/installed.


   -mi

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

Re: ports include /etc/src.conf? i.e. graphics/libfpx

[Mikhail T.]

15.02.2013 19:12, Ian Lepore ???(??):
> The src.conf manpage is not in error.  The intent is that src.conf
> applies only to the building of the freebsd world and kernel, that is,
> the source that's usually located under /usr/src.  If settings from
> src.conf are leaking into other builds, the error is in the makefiles,
> not in the manpage.  
>
> Unambiguous evidence of this can be found in the email announcing the
> new src.conf file and why it was created:
>
> http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061725.html
>
> I'm not an expert with the build system, and that goes double for ports,
> so I can't say exact how or why it's broken, or when the breakage
> happened (or even if it's been broken from the very beginning), but I
> think that announcement email makes it clear the bug isn't the
> documentation.
Thank you, sir, for posting the link. Once I read it, however, I am
puzzled. Because, contrary to what you are saying,it makes no statement
about whether or not knobs in src.conf are (or are not) supposed to
affect makefiles outside of /usr/src. The only paragraph mentioning the
new file says:

- Options can be passed on the make(1) command line or in the
  new /etc/src.conf (overrideable).  The reason for the new
  src.conf is so we keep make(1) environment clean from these
  variables outside world/kernel builds (make.conf pollutes
  the environment as it's included by sys.mk).

I fail to see, where in the above it says, that a private project's
/home/ian/foo/BSDmakefile is not supposed to be affected by the system's
/etc/src.conf. Do you?

There may be other reasons for src.conf(5) to claim, what it claims
about the file's "only purpose", but the e-mail you referred to is not
one of them.

-mi

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

Re: ports include /etc/src.conf? i.e. graphics/libfpx

[Mikhail T.]

15.02.2013 23:21, Ian Lepore ???(??):
> Since /home/ian/foo/BSDmakefile is not building something that is part
> of  the freebsd world, or the freebsd kernel, then according to that
> paragraph, a build using that makefile should not be affected
> by /etc/src.conf.
Maybe it should not be affected. But it is. And the only way to avoid it
is by using an undocumented knob. If the documentation properly
documents the feature, then the implementation of it is faulty.

As suggested earlier, perhaps, the file should only be included, if
something special is put into environment (by /usr/src/Makefile).
Instead it bsd.own.mk currently sucks-in /etc/src.conf by default -- and
one has to set an undocumented flag to avoid that. Something like this
(untested):

Index: Makefile
===
--- Makefile(revision 246385)
+++ Makefile(working copy)
@@ -293,7 +293,7 @@
 # the system bsdmake-like utility to be overridden.
 #
 MMAKEENV=  MAKEOBJDIRPREFIX=${MAKEPATH} \
-   DESTDIR= \
+   DESTDIR= _WITH_SRCCONF= \
INSTALL="sh ${.CURDIR}/tools/install.sh"
 MMAKE= ${MMAKEENV} ${MAKE} \
-D_UPGRADING \
Index: share/mk/bsd.own.mk
===
--- share/mk/bsd.own.mk (revision 246385)
+++ share/mk/bsd.own.mk (working copy)
@@ -115,7 +115,7 @@
 .if !target()
 :
 
-.if !defined(_WITHOUT_SRCCONF)
+.if defined(_WITH_SRCCONF)
 SRCCONF?=  /etc/src.conf
 .if exists(${SRCCONF})
 .include "${SRCCONF}"

Yours,

-mi

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

Why can't lang/gcc4X compilers build kernel modules?

[Mikhail T.]

It seems, none of the gcc-ports have the FreeBSD-extensions, that are worked 
into the base cc. This is fine for regular ports, but the consumers of 
bsd.kmod.mk (such as print/acroreadwrapper or multimedia/cuse4bsd-kmod) all 
choke. For example:


   gcc46 -O2 -pipe -march=prescott -fno-strict-aliasing -Werror -D_KERNEL
   -DKLD_MODULE -nostdinc   -I. -I@ -I@/contrib/altq -finline-limit=8000
   --param inline-unit-growth=100 --param large-function-growth=1000
   -fno-common  -mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx
   -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -std=iso9899:1999
   -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
   -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
   -Wno-pointer-sign -fformat-extensions -c linux_adobe.c
   cc1: error: unrecognized command line option '-mno-align-long-strings'
   cc1: error: unrecognized command line option '-fformat-extensions'
   *** Error code 1

Would it be too much work to extend the port-installed compilers the same way 
gcc-4.2.1 in the base is extended? May be not for gcc4[89], which are complete 
rewrites, but for 4.[4-7]? If not too difficult, should it be done?


Once implemented, it would become easier to build the entire kernel using a 
newer compiler. And dim@ (CC-ed) has already demonstrated non-trivial speed-ups 
obtained by building the kernel with gcc-4.7 over gcc-4.2:


   http://lists.freebsd.org/pipermail/freebsd-current/2012-November/037842.html
   http://www.andric.com/freebsd/perftest/perftest-kernel-2012-09-25b.txt

Yours,

   -mi

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

Re: Why can't lang/gcc4X compilers build kernel modules?

[Mikhail T.]

On 10.05.2013 13:15, Dimitry Andric wrote:

Getting rid of non-standard extensions in general is really the way to
go.  This would enable compiling with any standards-compliant compiler,
even commercial ones.
Of course, some day we may get there and it will be great. But until then the 
ports-provided compilers should support the same extensions, that the base one 
does -- unless it is too difficult to do...
Of course recent versions of gcc will be more feature-complete, result in 
faster code, etc. But please be reminded of the GPLv3 licensing issues with 
them. The license is not acceptable for everybody. (And yes, I know the 
license does not apply to the generated code, that is not the point. :)
The users, who don't find the new GPL acceptable, would not be installing any of 
the lang/gccXX at all -- and are most likely to skip this entire thread because 
of its very subject-line.


I am concerned for those like myself, who do accept the license, went through 
the trouble of installing one of the ports and are now hitting some unexpected 
problems with it...


   -mi

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

Re: graphics/libfpx fails to build

[Mikhail T.]

02.09.2013 02:13, Kenta Suzumoto написав(ла):
> Still doesn't build with Clang for me. Log attached.
Must be a clang-3.3 thing... Well, at least, we established, the PR
would not have fixed this...

Let me contemplate some more. Thanks,

-mi

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

Re: graphics/libfpx fails to build

[Mikhail T.]

01.09.2013 20:40, Kenta Suzumoto написав(ла):
> There's also a PR to update it which may fix it, but the maintainer hasn't 
> responded in a few weeks.
>
> https://www.freebsd.org/cgi/query-pr.cgi?pr=181302
I just committed the update and fixes proposed in the PR -- along with
an additional patch, that fixes
warnings raised by gcc-4.8 (at least one of those pointed to a real
error even).

Please, give it a try. Thanks for your patience. Yours,

-mi

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

Re: Re: databases/mysql-connector-java: Looks broken to me

[Mikhail T.]

On 04/06/15 06:31, Matthew Seaman wrote:
>> lucid-nonsense:/tmp/mysql-connector-java-5.1.35:% ant compile
>> > Buildfile: /tmp/mysql-connector-java-5.1.35/build.xml
>> > 
>> > -jdk5-check:
>> >  [exec] Execute failed: java.io.IOException: Cannot run program 
>> > "/usr/lib/jvm/jdk1.5/bin/java": error=2, No such file or directory
>> > 
>> > BUILD FAILED
>> > /tmp/mysql-connector-java-5.1.35/build.xml:240: Java 5 is required. Set 
>> > the full path to this JDK home with the property 'com.mysql.jdbc.jdk5'. 
>> > Default: '/usr/lib/jvm/jdk1.5'). Java 6 (for JDBC4+ implementation) is 
>> > also required. Set the full path to this JDK home with the property 
>> > 'com.mysql.jdbc.jdk6'. Default: '/usr/lib/jvm/jdk1.6'.
>> > 
>> > Total time: 1 second
> Given there is no longer any support in the ports for java-1.5 I'm
> afraid we're stuck with using the pre-compiled .jar file.
Can't the build.xml be patched to augment and/or drop the requirement?
We might then see the actual problem in the Java source -- if any -- and
patch that...

-mi

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

Re: databases/mysql-connector-java: Looks broken to me

[Mikhail T.]

On 04/06/15 16:00, Matthew Seaman wrote:
> That might be possible, but it would result in dropping a serious slice
> of functionality from the connector.
Which functionality is it? If an old compiler is truly required at all,
it can only be to generate code to run in an old JVM.

Since FreeBSD stopped offering java-1.5 long ago, this can not possibly
be a concern... And, of course, even a modern javac can be asked to
generate 1.5-compatible byte code.

None of these changes would be particularly /pleasant/ -- I, personally,
am always revolted by the innards of a pom.xml or build.xml -- but they
ought to be /possible/...

-mi

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

Re: databases/mysql-connector-java: Looks broken to me

[Mikhail T.]

On 07.04.2015 02:41, Matthew Seaman wrote:
> So anyone using JDBC3 would be disappointed by our chopping it out.  I
> have precisely zero idea how many people that might be, or indeed how
> much call there is for JDBC3 adaptors in general.
If the difference between JDBC3 and 4 is the compiler-version used to compile
them, then JDBC3 must only be of interest to those, who still use Java-1.5 for
whatever reason. These would not be new FreeBSD installations...

Various other packages have stopped supporting JDBC3 long ago
. I'd recommend dropping it too.

But if you think, we should not drop it, there is still no need for the older
JDKs. Any newer javac can be asked to generate older bytecode. For example:

javac -source 1.5 -target 1.5 ...

Yours,

-mi

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

FYI: libsdb (Re: FreeBSD ports you maintain which are out of date)

[Mikhail T.]

On 05/08/15 05:47, portsc...@freebsd.org wrote:
> databases/libsdb| 0.10.0  | 0.10.1
Both the 0.10.0 and 0.10.1 versions of libsdb date back to 2010 and the
only changes in the later "release" are in configure-script. There is no
need to bother upgrading this port at this time.

-mi

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

Enabling AVAHI-option in cups-client results in circular dependency

[Mikhail T.]

If cups-client is built with the AVAHI option, there will be a circular
dependency, it seems.

portupgrade will report it and stop. The dependency chain is too long
for me to analyze, perhaps somebody better versed with the current
package-management tools can figure it out... Yours,

-mi

___
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/poco (Re: FreeBSD ports you maintain which are out of date)

[Mikhail T.]

On 21.03.2016 04:52, portsc...@freebsd.org wrote:
> devel/poco  | 1.7.0   | 
> poco-1.7.2-release
Whoever takes this on, please, watch:

https://github.com/pocoproject/poco/issues/1208

Yours,

-mi

___
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: APNG patch for graphics/png port

[Mikhail T.]

Jeremy Lea wrote:

Hi,

On Mon, Dec 22, 2008 at 05:06:52PM -0500, Mikhail Teterin wrote:
  
Was not one of the advantages of APNG the fact, that a non-Animated PNG 
reader will still show the first frame of the animation? In that case, 
the icons will simply be non-animated...



The throbber is pretty important UI for a browser.  If you break it,
people will complain.

Uhm, what is "throbber"? Could you elaborate?

And say goodbye to '--enable-offical-branding'.
  

That, probably, is the lowest concern of all :-)

   -mi

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

Re: APNG patch for graphics/png port

[Mikhail T.]

Jeremy Lea wrote:

Hi,

On Mon, Dec 22, 2008 at 08:16:43PM -0500, Mikhail T. wrote:
  

The throbber is pretty important UI for a browser.  If you break it,
people will complain.
  

Uhm, what is "throbber"? Could you elaborate?



The little spinning things in the tabs, or the right hand side of the
menu bar, which tell you that its loading a page.


Oh, I see. Well, if that thing requires APNG, then, indeed, it is 
indispensable and the cat is, indeed, out of the bag... In that case we 
should either make our own graphics/apng or add the patch to graphics/png.


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

Re: devel/icu: doesn't build at 8-CURRENT

[Mikhail T.]

Rene Ladan написав(ла):

Boris Samorodov schreef:

[...]
cc  -I../../common -I../../i18n -I./../toolutil  -pipe -O2 
-fno-strict-aliasing  -c   -o wrtxml.o wrtxml.c
c++  -I../../common -I../../i18n -I./../toolutil  -pipe -O2 
-fno-strict-aliasing  -c   -o prscmnts.o prscmnts.cpp
cc  -I../../common -I../../i18n -I./../toolutil  -pipe -O2 
-fno-strict-aliasing  -c   -o derb.o derb.c

cd ../.. \
 && CONFIG_FILES=tools/genrb/derb.1 CONFIG_HEADERS= /bin/sh 
./config.status

config.status: creating tools/genrb/derb.1
cd ../.. \
 && CONFIG_FILES=tools/genrb/genrb.1 CONFIG_HEADERS= /bin/sh 
./config.status

./config.status: Can't open ./config.status: No such file or directory
gmake[2]: *** [genrb.1] Error 2


Same on 7.1-RELEASE/amd64, the THREAD option is on.
Ports tree is from 2009-03-27 09:57:43 UTC

Does it help to comment out the ALL_TARGET line from the port's 
Makefile? Thanks,


   -mi

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

Re: freebsd-ports Digest, Vol 311, Issue 3

[Mikhail T.]

>
> 1) Is it working at all? I always receive SIGBUS on 7x.
> 2) Is our valgrind from http://valgrind.org/ or valgrind.kde.org?
> 3) valgrind.org lists 3.4.1 as latest release, but there is 3.52 in
> ports, how is it possible?
>
> I am teaching people C, C++ and UNIX API using FreeBSD at university.
> There is a need for memory-checking tool.

It is, for most intents and purposes, not working on FreeBSD. And it
never worked on anything by i386 anyway.

According to the author(s), porting it from Linux to anything else would
take a substantial "research-grade" effort. (I think, such effort ought
to be sponsored similar to how java-porting was -- valgrind is a MAJOR
feature for many.)

> Does anybody know any alternatives for FreeBSD 7?
>   
Modern gcc-4.x has memory-checking features, which -- in a manner
remotely similar to Purify -- build various checks into the binary. Look
through gcc's man-page for the "mudflap" keyword.

That said, nothing beats Purify in my opinion, but that's not on FreeBSD
either and costs thousands of dollars :-(

Yours,

-mi

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

Re: Urgent: pwlib library issues (GetNumberValueAt functions are gone)

[Mikhail T.]

According to the (partial) history of this code, the functions were 
eliminated in April 2003:


http://www.openh323.org/~openh323/cvsweb.cgi/pwlib/src/ptlib/common/contain.cxx.diff?r1=1.130&r2=1.131

Touched as we are by your belief, that FreeBSD is in a position to help 
you with the third-party's code, we are not :(.


Most likely, you will have to study the diff to understand, how to 
modify your code to avoid using these functions in favor of whatever 
replacements are made for them by the PWLib's authors. If you still have 
problems, you may need to contact the authors (CC-ed).


It is quite confusing, that the openh323.org site is stale, and the 
project is currently SourceForge-hosted:


   http://openh323.sourceforge.net/
   https://sourceforge.net/projects/openh323

Yours,

   -mi

P.S. Steve, do you mind if I change the port's pkg-descr to point there? 
MASTER_SITES can also be turned to SourceForge's mirrors.



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Help needed with GUI for devel/gdb6

[Mikhail T.]

Hello!

The newly updated devel/gdb6 now has an option to build the debugger GUI 
(Insight).


It builds, but the GUI is broken, because instead of using the ancient 
version of ITk/ITcl bundled with Insight, I chose to rely on the itk and 
itcl ports.


If you know [incr tcl] (object-oriented extension for Tcl), and are 
interested in helping out, please, build the port with the GUI-option on 
and try to make it run (resolve the Tcl errors popping up, when 
accessing menu buttons, etc.) by modifying the scripts under 
${PREFIX}/lib/insight1.0


Thanks!

   -mi
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

textproc/sxml (FreeBSD ports which are currently scheduled for deletion)

[Mikhail T.]

On October 7 PortMgr wrote:
> portname:   textproc/sxml
> description:Skimpy XML parsing and grafting library for C language
> maintainer: po...@freebsd.org
> deprecated because: 
> expiration date:2014-08-31
> build errors:   none.
> overview:   
> http://portsmon.FreeBSD.org/portoverview.py?category=textproc&portname=sxml
The snippet above does not explain, why the port is condemned... The
linked-to overview claims, the port is "unstaged", which seems to be
stale, because the port was updated over a month ago:

r365899 | riggs | 2014-08-24 03:25:09 -0400 (Sun, 24 Aug 2014) | 9 lines

- Update to upstream version 1.0.6
- Add LICENSE
- Stagify
- Pet portlint

PR: 192811
Submitted by:   tkato...@yahoo.com
Approved by:mentors (implicit)

A disconnect somewhere? Yours,

-mi

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

Overly aggressive obsoleting of ports (Re: FreeBSD ports which are currently scheduled for deletion)

[Mikhail T.]

The two examples below strike me as particularly aggressive. Speaking as
someone working for a web-hosting group in a major company, I can tell
authoritatively, that -- had we used FreeBSD over there -- we would've
found having to upgrade this way unbearable.

We use Red Hat, which emphasizes stability -- to a fault, I might add.
But such whimsical dropping of software merely because it is
"deprecated" (not broken, mind you) is not helping me advocate for
FreeBSD. Not in the least...

If, for example, somebody was planning to add a new FreeBSD-server on
Dec 1st to their existing fleet, they are likely to reconsider it, if
their current software suit uses db48. The obsoletion-warnings should be
counted in /years/, not in months...

I, for one, have just upgraded my own system from 9.x to 10.1. The
freshly-rebuilt ports all use db48 -- perhaps, because that's what I had
installed already. An attempt to remove db48, would remove 34 other
ports along with it here:
Deinstallation has been requested for the following 35 packages (of 0
packages in the universe):

Installed packages to be REMOVED:
db48-4.8.30.0_2
jackit-0.124.1 (depends on db48-4.8.30.0_2)
fluidsynth-1.1.6_1 (depends on db48-4.8.30.0_2)
openal-soft-1.16.0_1 (depends on db48-4.8.30.0_2)
ffmpeg-2.3.5_1,1 (depends on db48-4.8.30.0_2)
alsa-plugins-1.0.28 (depends on db48-4.8.30.0_2)
openjdk6-b25_1 (depends on db48-4.8.30.0_2)
thunderbird-31.2.0 (depends on db48-4.8.30.0_2)

polkit-kde-0.99.1_3 (depends on db48-4.8.30.0_2)
kcm-polkit-kde-0.0.20121008_3 (depends on db48-4.8.30.0_2)
kde-base-artwork-4.14.2 (depends on db48-4.8.30.0_2)

No doubt, this can be rectified by yet another rebuild of everything --
and there is, of course, a clever combination of portupgrade options to
help achieve that (if nothing breaks). But I am rather resentful of
having to do that /again/ so soon after the previous round. Had I not
been a FreeBSD user and contributor of over 20 years already, I would've
seriously considered a different offering over such nonsense.

-mi

On 21.11.2014 03:28, lini...@freebsd.org wrote:
> portname:   databases/db48
> description:The Berkeley DB package, revision 4.8
> maintainer: mand...@freebsd.org
> deprecated because: Please migrate to db5 or db6
> expiration date:2014-11-30
> build errors:   none.
> overview:   
> http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=db48
>
>
> portname:   databases/memcachedb
> description:Distributed storage system designed for persistence
> maintainer: k...@stereochro.me
> deprecated because: Depends on deprecated Berkeley DB version, needs
> porting to DB_SITE
> expiration date:2014-11-30
> build errors:   none.
> overview:   
> http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=memcachedb

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

Downloading DISTFILES from multiple locations in parallel (torrent or ...)?

[Mikhail T.]

Has anybody given the idea any thought? Though in addition to the
"upstream" MASTER_SITES, there is a (fast) collection of FreeBSD
mirrors, the downloads currently aren't happening in parallel -- they
are serial...

One solution would be for the downloader (fetch(1) or whatever) to try
to open multiple connections -- to several possible sites -- and
download different ranges of the same tarball from different locations
in parallel thus affording the total download rate of the actually
fastest mirror (almost), rather than the one first on the list.

The alternative would use one of the existing torrent-clients, but we'd
need to think of how to publish the torrent-information with the ports.
It would seem, this second plan can go further even if the first would
require fewer  changes to the existing infrastructure.

Any thoughts?

-mi

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

Re: Overly aggressive obsoleting of ports (Re: FreeBSD ports which are currently scheduled for deletion)

[Mikhail T.]

On 22.11.2014 18:19, Kevin Oberman wrote:
> It's not like FreeBSD has a to of choice when the  BerkeleyDB folks
> have dropped  db-4.8.
I don't see a connection... People getting their software from Oracle
may have a point to make with the vendor. I'm talking about those, who
install it via FreeBSD port. Nor do I see, what you mean by "have
dropped" -- certainly, the manual is still there:


https://docs.oracle.com/cd/E17275_01/html/programmer_reference/changelog_4_8.html

As is the tarball. More generally, I do not believe, our decision to
drop a particular package should be based on that of the software's
authors/vendors -- unless their license requires us to, of course.

Sure, it usually makes little sense to keep a port of foo-X, when
foo-(X+1) is available. But some software groups -- like BerkeleyDB or
KDE -- have historically been obnoxiously bad about compatibility with
their own older releases. In these situations, FreeBSD ought to keep it
easy for our users to stay with the old version for much longer, than we
have been doing lately...
> It's been obsolete for a very long time.
db-4.8.30 was released in 2010. That is not "a very long time" ago. Not
at all. Even if it were declared "obsolete" back then -- which it was not...
> You just need to re-install them.
What of the organizations' own projects, which rely on BerkeleyDB? Even
if they do all continue to work after changing, verifying it takes time.
Worse, major upgrades of BerkeleyDB require migrating the data. It is
not a trivial task some times -- especially with large databases (such
as an LDAP user-database of a major company).

Heck, even an Apache-upgrade from 2.4.x to 2.4.y can be a minefield some
times, even when nothing was /supposed/ to have changed. With
BerkeleyDB, coming up with upgrade instructions and the scripts for
dump-ing and restore-ing of existing databases -- required planning and
man-days of development, testing, and roll-out efforts. Suggesting, such
efforts must be undertaken immediately -- on a whim of our portmgr@ team
-- is simply a non-starter.

Do you want to tell companies using FreeBSD, that ports/ can not be
relied on for anything mission-critical? Well, I guess, you might be
right if you said that today, but the goal ought to be to reverse that
unfortunate trend, not to accelerate it...

-mi

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

Support for "partial upgrades"

[Mikhail T.]

Hello!

A prominent committer stated today
:

"We do not support partial upgrades, never had, never will."

He then elaborated, that by "partial upgrades" he meant building a port from an
updated tree without first rebuilding all of the already-installed ports.

Whatever the deal may be with perl5-versions (subject of the above PR), I'd like
voice my concern about the "do not, never had, never will" part. For we
certainly "had" supported such things. For example, the ability of a port to
LIB_DEPEND on a shared-library without a specific major-number
 was added -- 12 years
ago -- exactly to better support such a "partial upgrades":

 1. Build everything.
 2. Update your ports-tree.
 3. Try to build one more thing.

And we still "do" support such handling of LIB_DEPENDS -- even if another
prominent committer does not know about it
.

While no "guarantees" can be provided by a free software project (indeed, even
commercial ones usually do not), it is rather unreasonable to demand, the user
rebuilds /everything/ in order to be able to build one more port from an updated
tree...

I'd argue, that one simply can not comply with this policy, while maintaining a
FreeBSD system usable for anything /other/ than testing the rebuilds themselves
and show-casing... Unless, of course, portmgr@ wants us all to switch to
prebuilt binaries (and Koolbuntu), that is...

It is one thing to say "yeah, this might not work -- send us patches": we may
not be able to /afford/ the ideal (due to shortage of people and/or material
resources), but we agree on /what the ideal is/. It becomes different, when the
response is "this should not work, never worked, never will"...

I'd like to see us continuing to recognize, that one FreeBSD install may differ
from another, and ports not having gratuitously-strict dependencies and
requirements... Could portmgr@, please, (re)affirm this goal and otherwise
clarify the matter for the benefit of mortals and the body's own members alike?
Thank you!

-mi

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

Re: Enabling AVAHI-option in cups-client results in circular dependency

[Mikhail T.]

On 24.01.2016 06:33, Kurt Jaeger wrote:

If cups-client is built with the AVAHI option, there will be a circular
>dependency, it seems.

There's a whole bunch of problem reports for some cups, and
we're missing someone to really look into those. Difficult
issue.


I was hoping, these problems would go away after the recent rework of 
cups ports, but it seems, it only got worse. Not just AVAHI, DBUS, and 
X11 can lead to a circular dependency during a portupgrade.


Also, cups-filters is required for something as simple as printing a 
text/plain, but conflicts with foomatic-filters -- which provides 
support for additional printers.


If someone found the time and the energy to rework cups-ports, why are 
these problems still remaining?


   -mi

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

textproc/apertium (Re: FreeBSD ports you maintain which are out of date)

[Mikhail T.]

On 16.05.2016 05:34, portsc...@freebsd.org wrote:
> textproc/apertium   | 3.4.0   | 3.4.2

This would bring useful improvements
,
but configure insists on lttoolbox-3.3.*3*... Mykola, could you look
into upgrading both, perhaps? Thanks!

-mi

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

x11-toolkits/rep-gtk2 (Re: FreeBSD ports you maintain which are out of date)

[Mikhail T.]

On 27.05.2016 06:18, portsc...@freebsd.org wrote:
> x11-toolkits/rep-gtk2   | 0.90.8.2| 0.90.8.3

The differences here consist only of updates to build glue,
syntax-changes in comments, and updates to the FSF postal address. Not
worth updating at this time, in my opinion.

-mi

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

Building JAVA-applications with maven

[Mikhail T.]

Application-authors using maven tend to rely on the tool to download -- 
at build-time -- the third-party JARs their application needs to build 
and/or run. The number of such downloads can be substantial.


For example, to build jruby from source (which the port is not currently 
doing), mvn downloads over 300 JAR-files.


This poses obvious challenges for all porters -- be they FreeBSD ports, 
Net/OpenBSD pkgsrc, or even Linux RPM/deb maintainers. I think, we'd all 
like:


1. the downloads to happen at the download stage (a.k.a. make fetch)
2. the checksums of the downloaded files to be verified (although maven
   can do this itself)
3. the downloaded JARs to be shared between multiple users -- mvn would
   stick them into ${HOME}/.m2 if allowed
4. the downloaded JARs to survive make clean -- so they should not be
   under ${WRKDIR} either
5. to avoid downloads and bundling of JARs, which are parts of other,
   already ported packages and applications -- right now I count 18 (!)
   ports, which bundle junit.jar, for example -- a shame.

Currently the ports of maven-using applications seem to either resign to 
simply installing pre-built JAVA-applications (instead of building them 
from source as port ought to), or -- like eclipse -- using pre-bundled 
dependencies. Neither is very satisfactory...


Ports-system needs some way of dealing with these issues properly and 
orderly. What should the strategy be?


How about allowing a port to declare the following needs, which would be 
taken care of for it:


1. It needs the following JARs, which /aren't/ already available from
   other ports, downloaded -- into ${DISTDIR}/jars or some such.
2. It needs its pom.xml file(s) patched to use the following list of
   JARs, which /are/ available from other ports, directly. (Hopefully,
   the JARs on the first list of each port will gradually make its way
   into the second.)

This may still leave the a. and b. unsatisfied -- or partially satisfied 
-- but those really are the least important of the problems. The item 2. 
may be "hairy" -- somewhat like the patching of libtool and friends 
we've had for some time. But it is doable...


Does this seem like a valid concern? Does the proposal seem like a good 
idea? Anyone up to creating Uses/maven.mk? Even just testing the new 
facility with a port of their own would be helpful...


   -mi

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

gem, pip et al vs. pkg

[Mikhail T.]

The ports tree has thousands of entries, which are simply thin wrappers 
around Ruby's gem or Perl's and/or Python's pip.


Most of these ports conWhy do we need them? Obviously, it is primarily 
for other ports to be able to depend on them. But why can't we satisfy 
this need without creating a port for each such little package?


If a port declares:

   RUN_DEPENDS= /foo/:gem//bar/[:/version/]

why can't the /bar/-gem (with the latest or specified version) be 
automatically installed -- and/or registered as a dependency -- without 
there being a dedicated port for it?


The biggest problem here is that neither Python's 
 
nor Ruby's  packages are normally 
/signed/ (not sure about Perl's), so simply downloading them is 
dangerous (not that this stops all people from using them anyway). But 
this can be side-stepped by us maintaining a checksum file of our own -- 
it would still be easier and more concise to maintain such a table with 
one row per package, instead of an entire port-directory with multiple 
files in it.


In the other direction, if someone were to install a Ruby gem using the 
gem-utility (or pip-perl, or pip-python, or even rpm), why aren't the 
installed files registered in the pkg's database? We have the sources 
for all of these utilities -- we can modify them to register the package 
and its files with the pkg.


The changes may even be welcomed upstream, if they are abstract enough 
to allow registration with the Operating System's package-manager on 
/all/ OSes, which would bother implementing a custom backend...


   -mi

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

Seeking testers for port of SikuliX-2014

[Mikhail T.]

I got the code to build and install on FreeBSD. The application starts,
but I don't really know, how to use it.

If you, or someone you know, do -- and have used it before on other
platforms -- please, contact me directly.

Thank you!

-mi

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

base components should always be default (Re: change in default openssl coming)

[Mikhail T.]

On 08.07.2016 02:26, Mathieu Arnold wrote:
> During this summer (sometime in August I think) I will be changing the 
> default OpenSSL for the ports tree from the base system version to 
> security/openssl.
The short answer is "Why?!" The longer reaction is: "please don't".

Certainly not without a lengthy and exhaustive discussion (or flame-war,
if you will), which shall arrive at a consensus -- and, if it does not,
then no change shall happen.

Generally, we should be eating our own dog-food -- using base-provided
components for everything by default where at all possible. If the base
OpenSSL is in some way(s) deficient, well, that's an argument for
updating the base. The base comes with not just the libraries, but withe
accompanying header-files -- meaning, the developers are free to use
those libraries. So the ports certainly should be doing just that.

Our ports and the packages derived from them are part of FreeBSD -- and
the various components need to remain tightly integrated.

Yes, I understand, you intend for there to remain an option, which the
holdouts like myself will be able to use to retain the old behavior. But
that's not good enough -- if the default packages will be built
differently, then bitrot will creep in and building against the base
will slowly become more and more difficult.

> I will also, because it goes with it, change the default GSSAPI from base to 
> something else,
Sorry, what goes with what? Are you saying, Heimdal can't be built with
port's OpenSSL or vice versa?

-mi


___
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: base components should always be default (Re: change in default openssl coming)

[Mikhail T.]

On 09.07.2016 18:25, Kevin Oberman wrote:
> This discussion has now been going on for a while. Several times the
> question "Why should be do this?" has been asked and answered, but I want
> to know why it is desirable to have ports use the base OpenSSL.
I thought, I explained my thinking for this -- I'll try again: FreeBSD
ports come with the OS and should be integrated as tightly as possible.
If the base's OpenSSL is deficient -- that's an argument for updating
the base.

I'll now expand, if I may: where do we stop? If base OpenSSL is not used
by default, how about C or C++ compiler? There is precedent, our
OpenOffice port used to have its very own version of gcc
... I always thought it
grotesque and am glad, we are past that, but would you see "clear
advantages" to the approach?
> Other than the time and disk space required to install the OpenSSL package, I 
> fail to see the point.
Ever heard the expression "DLL Hell"
? The reference to "DLL"
implies, the expression was born in the Windows world -- and I for one
would like to keep FreeBSD clear of this problem.

But why do you dismiss the time and space considerations? It is not just
"disk space", you know -- it is also memory at run time, because
different processes loading up different shared libraries require more
memory if the libraries aren't loaded from the same file... But even if
it were just disk space -- what advantage are you buying with it?
> There are clear advantages to making the base library private to the base 
> system but I have seen no real, significant reason to use the base library.
What are the "clear advantages" to making a major component of the OS
inaccessible to application-writers? And what are the qualifications,
that a reason must pass to be accepted as "real" and "significant"?
> It would be nice if a response or two could be technically supportable, but 
> that might be asking a bit too much. The initial post to this was mostly 
> "because I like it this way" and was lacking in technical basis.
You seem preparing yourself for disappointment. Did I fail your
expectations?..

-mi

___
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: Deluge 1.3.x and libtorrent-rasterbar v1.1.0

[Mikhail T.]

On 11.07.2016 09:46, Bendik wrote:
> Latest version of libtorrent-rasterbar is now 1.1.0, and ports has v1.0.9
> so it might be tempting to update it (like Arch did without testing).
Khm, I have the update (almost) ready here -- and testing it with
net-p2p/qbittorrent...
> However, libtorrent v1.1.0 introduces backwards incompatible changes, and
> will not work with Deluge 1.3.x.
Is it difficult to patch up Deluge? libtorrent-rasterbar has a CVE

against it -- including version 1.1.0 -- and so sticking to the old
version for very long is not going to work...

-mi

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

binary packages and CPU-features

[Mikhail T.]

Hello!

What is the general approach to porting software, which uses advanced
CPU-features (like SSE), but has no run-time detection of them?

I just added graphics/lepton, for example, which has some functions
implemented with AVX2 intrinsics -- but whether or not to use them is
determined at compile-time... The original code also required SSE4, but
I managed to patch it to lower the requirements to SSSE3.

Typically, pre-built packages target the lowest, but this particular
program will not build without at least SSSE3 available at all.

Should there be three separate packages: lepton-avx2, lepton-ssse3, and
lepton-sse4? Maybe, our package-building infrastructure should
automatically produce different packages from ports expressing such a
desire by declaring, for example:

CPUSPECIFIC=avx2 ssse3 sse4
CPUSPECIFIC_AVX2=   -mavx2
CPUSPECIFIC_SSSE3=  -mssse3
CPUSPECIFIC_SSE4=   -msse4.1

Should I simply set NO_PACKAGE -- to avoid a situation when a prebuilt
binary will not even start for some users (such as on older Opterons)?

-mi

-mi

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