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"

Re: misc/jive deleted

[Mikhail T.]

On 24.10.2016 11:51, Mark Linimon wrote:

Or:

  - expired, replaced by newer version
  - unfetchable
  - license does not allow anyone to package it
  - author requested(*) removal

I have personally removed ports fitting each of these criteria at various
times.  I am sure I am missing some other criterion as well.

So, your claim is simply false.


I stand corrected and apologize. Allow me to rephrase my argument:

Technically, the only reasons to remove a port is due to one of the 
following reasons:


 * continuous failure to build
 * expiration, replaced by newer version
 * unfetchable
 * license does not allow anyone to package it
 * author requested(*) removal

None of the above is applicable to jive. Therefore, for purely technical 
reasons, it ought to be put back.



I have personally removed ports fitting each of these criteria at various
times.  I am sure I am missing some other criterion as well.
Yes, I'm sure you could, eventually, think of others -- but, just as 
with the above list, none that would apply to jive. It is -- to my 
knowledge and yours, evidently -- the very first one removed for a 
patently non-technical reason of being "offensive".


Now that we are done with the hairsplitting, and I shall put the port 
back as soon as I have a moment -- unless someone else beats me to it.


I'd also like to ask portmgr@ to avoid taking such steps in the future 
-- inventing a policy in order to immediately act on it. Though we do 
not have a strict separation of powers, portmgr@ is primarily an 
executive body -- and should defer "lawmaking" to the wider audience of 
committers, however cantankerous we may be.


Portmgr's mandate is to ensure, ports continue to build smoothly despite 
changes to the OS and other ports. Policing the contents is a 
regrettable overreach (a.k.a. "powergrab").


   -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: misc/jive deleted

[Mikhail T.]

On 22.10.2016 Mark Linimon wrote:

It's not delusions of moral superiority.  It's common decency.


If it was "decent" in 1997, when obrien added it, it must still be 
decent today, only 19 years later. Nothing has changed about "decency" 
since then.



juvenile junk that makes them look like a bunch of out-of-touch clueless old 
white guys


Somebody got his metaphors mixed up -- if it is "juvenile", then "old 
guys" (of any color) just does not ring true.


On 23.10.2016 12:03, Kurt Jaeger wrote:

So, lets get back to technical stuff 8-}


Technically, the only reason to remove a port is due to a failure to 
build -- and that hasn't happened. Therefore, the removal was in error, 
which should be rectified.


   -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: Re: misc/jive deleted

[Mikhail T.]

On 22.10.2016 05:27, Mark Linimon wrote:

disclaimer: I wasn't the person who made the decision.


You are too humble, Mark. Whoever actually did it, would not have gone 
ahead if you objected.



The "pro" removal points: some of these terms are no longer acceptable
in polite society, and far cross the line from humor to offensive.
If FreeBSD is trying to be more inclusive, having this around isn't
the way.


That begs the question, does not it? Is FreeBSD "trying to be more 
inclusive"? Is this -- being more inclusive (whatever that means) -- 
even a valid goal for a technical project? We aren't curing the world's 
ills nor aiming for a "greater justice" here -- we are simply building 
the best Operating System.


A long as a port keeps building/packaging, it should remain available. 
Please, put it back if only to honor this sentiment:


   http://quoteinvestigator.com/2015/06/01/defend-say/

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"

Port-request: graphics/skia

[Mikhail T.]

The library is used by both firefox and chromium (maybe, other software
as well), but they each bundle their own version.

If we had a port graphics/skia, we could, eventually, patch those
browsers to use it instead. And, of course, we'd give more options to
developers using FreeBSD for their own projects.

The actual sources can be found on GitHub
https://github.com/google/skia, for example. 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"

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"

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"

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"

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"

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"

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"

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"

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"

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"

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"

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"

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"

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

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
https://www.google.com/search?q=JDBC3+obsolete. 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

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

Support for partial upgrades

[Mikhail T.]

Hello!

A prominent committer stated today
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196518#c5:

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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=34126 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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196519#c1.

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

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

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=databasesportname=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=databasesportname=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

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=textprocportname=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

Re: FreeBSD ports which are currently scheduled for deletion

[Mikhail T.]

On 08.04.2014 08:00, freebsd-ports-requ...@freebsd.org wrote:
 If people are using a port, then I would agree it should be kept
 regardless of maintainer status. But that doesn't mean keeping
 everything forever as long as it compiles.
Why not? Why not keep everything forever as long as it compiles? Where
is this idea coming from, that stuff must be continuously updated to be
considered usable?
 It's certainly possible that antoine@ has been a little overzealous in
 deprecating ports, but I don't think it's unreasonable to expect to have
 some evidence that any particular port has actually *worked* in the last
 ten or fifteen years.
There is no evidence it has NOT worked either. And the burden of proof,
that a change is necessary (or even desirable), is on whoever is
suggesting the change.

The most recent list included not only software for interfacing with old
video-cameras -- various modules for xmms, for example, are on the
chopping block too, for just another example. Why?..

-mi

P.S. Please, CC me on any follow-ups -- I'm only getting digests of
freebsd-ports@ making replying difficult.
___
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 which are currently scheduled for deletion

[Mikhail T.]

On 08.04.2014 12:55, Tijl Coosemans wrote:
 On Tue, 08 Apr 2014 09:57:48 -0400 Mikhail T. wrote:
  On 08.04.2014 08:00, freebsd-ports-requ...@freebsd.org wrote:
  If people are using a port, then I would agree it should be kept
  regardless of maintainer status. But that doesn't mean keeping
  everything forever as long as it compiles.
  Why not? Why not keep everything forever as long as it compiles? Where
  is this idea coming from, that stuff must be continuously updated to be
  considered usable?
 It doesn't have to be updated continuously, but it has to be used.
 Keeping a port requires effort.  It needs to be kept up to date with
 infrastructural changes (like staging) and if nobody is using the port
 that's just a waste of effort.
Tijl, there is no indication whatsoever, that ports on the chopping block are
not used. The argument put forth by the proponents of the removals is thus: The
upstream authors haven't made a new release in a long time, therefor the
software must be neither any good, nor see much use.

I find this logic flawed -- some of my favorite books are more than 2000 years
old, for example... Their authors certainly aren't making new releases, yet they
continue to be maintained, built (published), and used by generations.

The closest we've ever come to estimating usage is the following: If there is
any user-base to speak of, then there should be a person among them willing to
maintain the port -- or pay someone to maintain it. This, too, is flawed in my
opinion -- expecting a graphics-artist, a biologist, or an audiophile to also be
a half-decent software engineer is a stretch; expecting them to pay for
port-maintainership is also not fair, when the entire OS is free, done for fun,
rather than profit.

Though I agree, that unmaintained ports should be dropped when they break due to
things like security bugs or compiler-upgrades, the self-inflicted wounds like
infrastructure changes do not qualify. Volunteers taking it upon themselves to
perform such changes, should be prepared to deal with all that's required for 
them.

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 ports which are currently scheduled for deletion

[Mikhail T.]

Once again I am seeing this dreadful list and once again I am wondering... Why
are we removing ports simply for being unmaintained?

Those with build-errors -- Ok, I understand, bit-rot happens. Those with (much)
newer versions available -- sure.

But simply unmaintained -- that does not seem right...

graphics/qvplay is just an example -- linimon's list contains many more ports,
whose only fault is not having an active maintainer...

-mi

On 07.04.2014 07:06, freebsd-ports-requ...@freebsd.org wrote:
 portname:   graphics/qvplay
 description:Digital camera downloading tool for Casio QV series
 maintainer: po...@freebsd.org
 deprecated because: Unmaintained since 2001
 expiration date:2014-04-12
 build errors:   none.
 overview:   
 http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=qvplay

___
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

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: 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: 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. mi+t...@aldan.algebra.com 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: 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=22t=84823
Obviously, knotes was just an example. All other customizations (such as menus, 
backgroundsscreen-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

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=accessibilityportname=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

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

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

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: 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=x11portname=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

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=databasesportname=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: 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

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.mi+t...@aldan.algebra.com  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 upgrade everything to 
the latest, but he is no longer forced to do it just to add one more port to an 
existing install. My proposal 

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

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

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: 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: 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 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: 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.mi+t...@aldan.algebra.com  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 
ATT 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: 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: 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.mi+t...@aldan.algebra.com  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=audioportname=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

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=audioportname=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: 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

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

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

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: 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=243163atid=1121518
   2. 
http://sourceforge.net/tracker/?func=detailaid=3170970group_id=243163atid=1121518
   3. 
http://sourceforge.net/tracker/?func=detailaid=3148380group_id=243163atid=1121518
   4. 
http://sourceforge.net/tracker/?func=detailaid=3090002group_id=243163atid=1121518
   5. 
http://sourceforge.net/tracker/?func=detailaid=3084362group_id=243163atid=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: 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: 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: 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

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

[Mikhail T.]

Hello!

Digital Life Network Alliance http://en.wikipedia.org/wiki/DLNA is a 
standard newer than UPnP -- some devices on the market are not satisfied 
with plain UPnP-servers like mediatomb 
http://www.freshports.org/net/mediatomb... As far as I understand, the 
only DLNA-capable server ported to FreeBSD right now is ushare 
http://www.freshports.org/net/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 
http://minidlna.sourceforge.net/ (which uses SQLite3 database to store 
the collection data between restarts), but I need help with the start-up 
script 
http://www.freebsd.org/doc/en/books/porters-handbook/book.html#RC-SCRIPTS 
-- 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 
http://www.amazon.com/review/R2U4XPXENWU9BC/ref=cm_cr_rdp_perm). 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: 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

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

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=develportname=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

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

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

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