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

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/v

Re: misc/jive deleted

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

Re: misc/jive deleted

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 b

Re: Re: misc/jive deleted

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 cro

Port-request: graphics/skia

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 p

binary packages and CPU-features

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 comp

Re: Deluge 1.3.x and libtorrent-rasterbar v1.1.0

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.

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

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

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

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

Seeking testers for port of SikuliX-2014

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

gem, pip et al vs. pkg

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 po

Building JAVA-applications with maven

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 downl

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

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 opi

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

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

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

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 woul

devel/poco (Re: FreeBSD ports you maintain which are out of date)

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 ___

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

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

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

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

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

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

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

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 stop

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

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

Support for "partial upgrades"

Hello! A prominent committer stated today : "We do not support partial upgrades, never had, never will." He then elaborated, that by "partial upgrades" he meant building a port from an updated tree without first rebuilding all of t

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

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

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

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 mult

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

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 stabi

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

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

Re: FreeBSD ports which are currently scheduled for deletion

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 o

Re: FreeBSD ports which are currently scheduled for deletion

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 comp

Re: FreeBSD ports which are currently scheduled for deletion

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 r

Re: graphics/libfpx fails to build

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,

Re: graphics/libfpx fails to build

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

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

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

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

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

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

15.02.2013 23:21, Ian Lepore ???(??): > Since /home/ian/foo/BSDmakefile is not building something that is part > of the freebsd world, or the freebsd kernel, then according to that > paragraph, a build using that makefile should not be affected > by /etc/src.conf. Maybe it should not be affect

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

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

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

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

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

14.02.2013 08:55, Tom Evans написав(ла): > On Thu, Feb 14, 2013 at 1:12 PM, Mikhail T. wrote: >> > I may sound defensive here, but I'll still repeat, that "this singular >> > port" >> > (and I do, in fact, have other ones like it) started using bsd

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

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

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

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,

Re: Why delete KDE3 ports?

On 09.01.2013 14:53, Adam Vande More wrote: I don't use knotes, but have you tried the solution here? http://forum.kde.org/viewtopic.php?f=22&t=84823 Obviously, knotes was just an example. All other customizations (such as menus, backgrounds&screen-savers, email accounts -- everything under ~/.k

Re: Why delete KDE3 ports?

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 additio

Re: Why delete KDE3 ports?

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"

Re: Why delete KDE3 ports?

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

Why delete KDE3 ports?

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:

Should USE_UNZIP be deprecated?

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,

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

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.fre

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

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 ___

Re: How to fetch files from GitHub?

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 a

How to fetch files from GitHub?

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

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

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 alre

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

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/f

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

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.F

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

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 c

Re: how do you specify a minimum lib version?

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 so

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

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

Re: recent portrevision bump for libvpx

On 17.02.2012 17:05, Zhihao Yuan wrote: On Fri, Feb 17, 2012 at 2:57 PM, Mikhail T. wrote: On 17.02.2012 14:24, Zhihao Yuan wrote: I regard this as a wrong practice. Here is why: 1. The way you specify the version in LIB_DEPENDS has NO relation with how the port link to the lib. The port can

Re: recent portrevision bump for libvpx

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

Re: recent portrevision bump for libvpx

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

Re: Re: recent portrevision bump for libvpx

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 wid

Re: Installing executables with generic names

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@free

Re: Installing executables with generic names

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.

Installing executables with generic names

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

Re: Recent ports removal

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 b

Re: Recent ports removal

On -10.01.-28163 14:59, Doug Barton wrote: Yes, we realize that you, and a small minority of other interested parties, have this belief in spite of endless repetition of the reasoning, by the people who do the actual work to keep the ports tree functional, as to why your desire to keep every port

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

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 por

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

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 suppor

Re: sysutils/cfs

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, certainl

Re: sysutils/cfs

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 ul

Re: sysutils/cfs

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

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

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) rec

Re: sysutils/cfs

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 (bef

Re: Re: sysutils/cfs

On -10.01.-28163 14:59, Chris Rees wrote: I've had to deprecate sysutils/cfs -- there's a confirmed issue with failing locks [1] which has been open for two years with no fix. Whoops, also missed a CVE -- buffer overflows can cause a DoS. Expiration date altered to 1 month accordingly. Is thi

Re: FreeBSD unmaintained ports which are currently scheduled for deletion

On 25.08.2011 08:48, Chris Rees wrote: On 24 August 2011 14:47, Mikhail T. wrote: Can it be unbroken by using the Internet archive? ... If so, quite a few other victims of this latest purging can be given a new life. Matthias recently made reference on this subject, if you care to take a

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

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

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

On 22.08.2011 04:46, Chris Rees wrote: On 22 August 2011 03:24, Mikhail T. wrote: On -10.01.-28163 14:59, lini...@freebsd.org wrote: portname: audio/adpcm description:An Intel/DVI IMA ADPCM codec library maintainer:po...@freebsd.org deprecated because: No more public

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

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.F

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

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 perfect

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

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 a

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

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) absenc

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

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 (

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

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/l

Turning APNG to on by default in graphics/png

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

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

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

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

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 por

Re: saving a few ports from death

Eitan, you are entitled to your opinions, but not to your own facts. My factual corrections are inline below. Arguing about opinions and policy is useless until the facts are accepted as such by all participants: On 27.04.2011 16:54, Eitan Adler wrote: The upstream maintainer already called

Re: saving a few ports from death

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 conven

Re: saving a few ports from death

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

Re: Re: saving a few ports from death

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

Re: FreeBSD Port: minidlna-2010.12.12

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

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

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

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

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 ptli

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

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

Re: devel/icu does not build with gcc 4.5.1

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 ic

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

Hello! "Digital Life Network Alliance " is a standard newer than UPnP -- some devices on the market are not satisfied with plain UPnP-servers like mediatomb ... As far as I understand, the only DLNA-capable server por

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

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

Re: Re: Recent massive port update.

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"

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

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 u

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

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

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

01/08/10 13:10, John Merryweather Cooper написав(ла): Well, the [Ada -mi] compiler needs to be upgraded to the latest version. Linux gets a compiler out of the box, but we have to bend one to shape. I remain convinced, that the "bending into shape" ought to begin with making the additional GNU

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

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:

  1   2   >