Re: Welcome flavors! portmaster now dead? synth?
On Mon, 2017-12-04 at 18:10 +0100, Jan Beich wrote: > Dennis Glatting writes: > > > 1) I am tired of port breakage. I am past tired of being told to > > read > > UPDATEs when UPDATEs often has limited information, including > > install > > conflicts. > > > > 2) "Error 70" on installs with no indication of where the error > > was > > incurred and thus requiring me to make with debug flags and then > > dig > > deep is past annoying. > > [...] > > Further: > > > > 1) Under FreeBSD I do not do binaries, rather I do source and I do > > source for reasons. Under Linux, source is troublesome. > > I'm curious what are those "reasons" that don't affect Linux. Those > may > be valid FreeBSD shortcomings unlike what you've listed above which > is > mainly about source vs. binary packages. Source verses binaries are valid "reasons" and are based on application and operation placement. With source, I can compile out optional code (e.g., SQL hooks in OpenLDAP) whereas binary packages are often compiled to be all things to all people (i.e., more functionality is offered). Although one can argue that inclusion of compile-time optional code into a binary is only operationally enabled through a proper configuration, there are problems with that argument: 1) The compile-time optional code may not be truly disabled through configuration files, 2) Some functions are enabled by default, and 3) They represent threat vectors. If you do not include compile-time optional code then reduced threat vectors. Linux is a series of trade offs. If application code is written with CUDA then you have to support the application with all of its warts and baggage. If I /have/ to do source under Linux then I have to do source but I don't /want/ to do source because the process is often ugly. Another trade off, which annoys the hell out of me, is NetworkManager verses other "helpful" tools. None of those tools are fun when doing custom networking, which includes VLANs and IPv6 as if those are new advanced concepts, and configuration is different across Linux distributions including Debian Stretch and Raspberry PI3 although they're running nearly the same version of Debian. It is maddening. Hulk want to smash! With FreeBSD, I simply hack a few files in /etc and I'm good to go. Also under FreeBSD, what I need to configure in /etc is often obvious and I don't have to waddle through gobs of confusing, unrelated, and often erroneous documents and Internet posts. FreeBSD isn't perfect but FreeBSD has this useful thing called a Handbook. I can, and do, enable IPTables in Linux and IPFW in FreeBSD for added protections but if a threat vector isn't there (i.e., not in the binary) then there are less exploitable threat vectors - it's discernible math at that point. Do I want to manage lists of IPTables and IPFW? No. They get complex and create breakage paths. When one is required to have heterogeneous infrastructures one wants commonness and simplicity while at the same time not admitting to that bottle of whiskey in one's desk drawer. I often strip stupid stuff, such as NetworkManager, and life gets simpler and less migraine prone. That all said, my response was based on the point of that the finite resource sword cuts both ways. If one operating system increases my annoyance and another does not, there is a point where my bias leans. Oh, and "hell no" to Windows. It's evil and I live across Lake Sammamish from the Evil Empire. -- Dennis Glatting Numbers Skeptic ___ 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: Welcome flavors! portmaster now dead? synth?
On Sun, 2017-12-03 at 20:07 +, Steven Hartland wrote: > People really seem to miss the point that there are only finite > resources > and as an open source project that depends on people volunteering > their > time to add new features and maintain tools. Missing the point cuts both ways. If you have a a couple swaths of servers managed to certain tool chains then the conversion process is an unnecessary and non-trivial resource consumption. I have moved servers to Ubuntu and (groan) other Linux flavors and customized the processes because: 1) I am tired of port breakage. I am past tired of being told to read UPDATEs when UPDATEs often has limited information, including install conflicts. 2) "Error 70" on installs with no indication of where the error was incurred and thus requiring me to make with debug flags and then dig deep is past annoying. 3) Nvidia does not support CUDA under FreeBSD and this is a problem for TensorFlow and other applications. If I went the OpenCL route (e.g., AMD GPUs) then my application base would be significantly limited. I don't consider Intel a serious solution. Further: 1) Under FreeBSD I do not do binaries, rather I do source and I do source for reasons. Under Linux, source is troublesome. 2) I had no hope of getting Intel Phi processors working under FreeBSD but I do have them working under Linux, including the older Phis under CentOS. I recognize this is an Intel problem which is one of the reasons I do not consider Intel a serious solution, not to mention the requirements and cost of an Intel compiler and Intel libraries. 3) FreeBSD offers me ZFS and FreeNAS as an alternative, particularly for HyperV/VMware SANS. Under Linux, ZFS has historically been troublesome. These are nothing more than a few data points. Please do not bother with the "then become a maintainer" response. It is not that I do not appreciate the efforts of others but that statement is a BS response, you know it, and I'll simply delete your message. ___ 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: cups-filters 1.13.4 failures
On Tue, 2017-03-28 at 15:34 +1300, Jonathan Chen wrote: > On 27 March 2017 at 18:51, Dennis Glatting wrote: > [..] > > > > I have the same problem and traced it to something between pdftopdf > > and > > pdftops (pdftopdf exits with no errors). Pdftopdf creates a file in > > /var/spool/cups/tmp but when pdftops is called the file doesn't > > exist. > > No idea why. Changing permissions didn't help. Truss didn't help. > > To my > > surprise, swearing didn't help either. > I've submitted a PR and a patch to fix this problem. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218175 > That fixed my print problem too. Thanks. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: cups-filters 1.13.4 failures
On Mon, 2017-03-27 at 18:37 +1300, Jonathan Chen wrote: > Hi, > > I recently updated to cups-filters 1.13.4, and it appears that I now > cannot print PDF files. The port is built with the default options. > The logs indicate: > > D [27/Mar/2017:17:24:32 +1300] [Job 631] Running command line for > pdftops: pdftops -level3 /var/spool/cups/tmp/0410d58dfd707 - > D [27/Mar/2017:17:24:32 +1300] [Job 631] Started filter pdftops (PID > 16655) > D [27/Mar/2017:17:24:32 +1300] [Job 631] Unable to execute pdftops > program: No such file or directory > D [27/Mar/2017:17:24:32 +1300] [Job 631] Started filter pstops (PID > 16656) > D [27/Mar/2017:17:24:32 +1300] [Job 631] PID 16655 (pdftops) stopped > with status 1! > D [27/Mar/2017:17:24:32 +1300] [Job 631] The print file is empty. > D [27/Mar/2017:17:24:32 +1300] [Job 631] PID 16656 (pstops) stopped > with status 1! > D [27/Mar/2017:17:24:32 +1300] [Job 631] Sent 0 bytes... > D [27/Mar/2017:17:24:32 +1300] [Job 631] Waiting for read thread to > exit... > D [27/Mar/2017:17:24:32 +1300] [Job 631] PID 16653 > (/usr/local/libexec/cups/filter/pdftops) stopped with status 1. > > I am not sure why its complaining that pdftops is not there because > both the filter and the main program are there: > 6:27pm# ls -l /usr/local/libexec/cups/filter/pdftops > -rwxr-xr-x 1 root wheel 36672 25 Mar 15:05 > /usr/local/libexec/cups/filter/pdftops > 6:32pm# ls -l /usr/local/bin/pdftops > -rwxr-xr-x 1 root wheel 18744 8 Jan 13:43 /usr/local/bin/pdftops* > > Is the filter looking for pdftops in the wrong place? > > 6:36pm# strings /usr/local/libexec/cups/filter/pdftops | grep > bin.pdftops > /usr/bin/pdftops > I have the same problem and traced it to something between pdftopdf and pdftops (pdftopdf exits with no errors). Pdftopdf creates a file in /var/spool/cups/tmp but when pdftops is called the file doesn't exist. No idea why. Changing permissions didn't help. Truss didn't help. To my surprise, swearing didn't help either. > Cheers. ___ 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: Does OpenMP (iomp5) work for clang-devel?
On Tue, 2015-07-21 at 01:07 +, Brooks Davis wrote:
> On Mon, Jul 20, 2015 at 05:48:58PM -0700, Dennis Glatting wrote:
> > I can't seem to get this working and it appears not to emit code. I have
> > libiomp5 installed and I compile specifying:
> >
> > clang++-devel -fopenmp=libiomp5 ...
> >
> > And the compiler says:
> >
> > clang: warning: argument unused during compilation: '-fopenmp=libiomp5'
>
> The most recent clang-devel port doesn't include the bits to make iomp
> support automatic (it came not long after the update). I'm working on
> a update, but the ability to build clang and llvm separately appears to
> have been broken quite badly so it's taking a while and the only port to
> install will be devel/llvm-devel.
>
> Simple programs to work if you link with -liomp5 manually.
>
They link but aren't OpenMP:
root@Tasha# cat foo.cc
#include
#include
int
main( void ) {
printf( "max=%d\n", omp_get_max_threads());
#pragma omp parallel for
for( int i = 0; i < 5; ++i ) {
printf( "tid=%d\n", omp_get_thread_num());
}
return 0;
}
root@Tasha# clang++-devel -fopenmp -liomp5 foo.cc
-L /usr/local/llvm-devel/lib/
root@Tasha# ./a.out
max=8
tid=0
tid=0
tid=0
tid=0
tid=0
I have a couple of blocks under GNURadio (3.7.7.1) that need OpenMP, and
run under Ubuntu. I'd like to get them running on the minnowboard
(FreeBSD10) and they already run on the Cubieboard4 (some version of
Ubuntu gunk). Unfortunately not all of GNURadio's dependencies compile
with using GCC49/5 under FreeBSD.
> > Is there a compile-time test involved somewhere, perhaps in llvm build?
>
> Assuming I manage to include the openmp runtime in the next update, I think
> it will work and I plan to configure the
>
Kewlness. Thanks.
> > Should /usr/local/llvm-devel/lib/ be in /etc/ld.so.conf? (That doesn't
> > seem to help).
>
> ldconfig should be handled correctly by the ports infrastructure.
>
> -- Brooks
___
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"
Does OpenMP (iomp5) work for clang-devel?
I can't seem to get this working and it appears not to emit code. I have libiomp5 installed and I compile specifying: clang++-devel -fopenmp=libiomp5 ... And the compiler says: clang: warning: argument unused during compilation: '-fopenmp=libiomp5' Is there a compile-time test involved somewhere, perhaps in llvm build? Should /usr/local/llvm-devel/lib/ be in /etc/ld.so.conf? (That doesn't seem to help). ___ 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: HEADS UP: Berkeley DB 4...4.7 port removals/upgrades may require manual preparation
On Sun, 2014-08-24 at 15:08 +0200, olli hauer wrote:
> On 2014-08-24 14:37, Michael Gmelin wrote:
> >
> >
> > On Sun, 24 Aug 2014 14:30:06 +0200
> > Kurt Jaeger wrote:
> >
> >> Hi!
> >>
> Hm, using USE_BDB=$numble looks wrong to me in devel/ice.
>
> Can you test the following patch.
>
> Index: Makefile
> ===
> --- devel/ice/Makefile(revision 365910)
> +++ devel/ice/Makefile(working copy)
> @@ -27,7 +27,8 @@
> .endif
>
> USES= iconv gmake
> -USE_BDB= 5
> +USE_BDB= yes
> +WANT_BDB_VER= 5
> INVALID_BDB_VER= 40 41 42 43 44 46 47 48 6
> USE_LDCONFIG= yes
> BUILD_WRKSRC?= ${WRKSRC}/cpp
> >>
> >>> @Kurt: Could you test and confirm? If this works, I'll commit the
> >>> patch.
> >>
> >> Yes, it builds.
> >>
> >
> > I created a commit request
> >
> > https://reviews.freebsd.org/D679
> >
>
> Kurt, or you can commit this even w.o. PR.
> The patch does not break anything but allows the port to build as required.
> I assume there are even more easter eggs in the tree, specially for USE_BDB.
>
Yep:
root@Junker# more databases/evolution-data-server/Makefile
...
USE_BDB=41+
___
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
On Wed, 2014-08-13 at 18:43 +0200, Kurt Jaeger wrote: > Hi! > > > On Tue, 2014-08-12 at 23:42 -0500, Matthew D. Fuller wrote: > > > On Tue, Aug 12, 2014 at 09:31:08PM -0700 I heard the voice of > > > Dennis Glatting, and lo! it spake thus: > > > > > > > > do_install in the Makefile does the chown. > > > > > > Generally you'd want to do something more like using @owner/@group in > > > plist, rather than chown'ing in the stage. Doing that would break > > > building as non-root, too. > > > > What's the order? plist cannot change owner/group unless it is defined. > > Or, does plist execution happen /after/ the make process creates the > > owner/group entries? > > If you some file bin/myfile1 in the pkg-plist which need to be owned by some > user etc, then: > > [...] > bin/myfile0 > @owner www > @group www > bin/myfile1 > @owner root > @group wheel > bin/myfile2 > [...] > > should probably work. Can you try it ? > I am setting permissions on directories and the man page for pkg-create isn't clear. It says: @owner user Set default ownership for all subsequent files to user. Use without an arg to set back to default (root) ownership. Perhaps it means "files" in the generic? Another issue I is the directories are made in the Makefile (do_install) because pkg-create doesn't mention a "mkdir" function. The Porter's Handbook mentions "@exec mkdir" however the StageDir WIKI states it is ignored and directory creation should remain in post-install, specifically: Directory creation should remain in the post-install: target (in particular because pkgng doesn't work like pkg_install in that area and pkgng ignores the @exec mkdir, and directly packs the directory even if empty). Consequently, I have no idea how to set the owner/group on those directories in stagedir. ___ 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
On Tue, 2014-08-12 at 23:42 -0500, Matthew D. Fuller wrote: > On Tue, Aug 12, 2014 at 09:31:08PM -0700 I heard the voice of > Dennis Glatting, and lo! it spake thus: > > > > do_install in the Makefile does the chown. > > Generally you'd want to do something more like using @owner/@group in > plist, rather than chown'ing in the stage. Doing that would break > building as non-root, too. What's the order? plist cannot change owner/group unless it is defined. Or, does plist execution happen /after/ the make process creates the owner/group entries? ___ 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
On Wed, 2014-08-13 at 06:17 +0200, Kurt Jaeger wrote: > Hi! > > > > I'll test it on poudriere, but it's CEST here and I have to get up > > > early, so it will take probably until tomorrow evening to get to it. > > There is one issue with the ordering of 'add the cacti user/group' and > 'using it for a chown', but I do not know the fix right away. Will look > at it when I find a bit more time. > > ===> Generating temporary packing list > ===> Creating users and/or groups. > /bin/mkdir -p > /usr/local/home/pi/myp/net-mgmt/cacti/work/stage//usr/local/share/cacti > /bin/mkdir -p /usr/local/home/pi/myp/net-mgmt/cacti/work/stage/var/log/cacti > /bin/mkdir -p > /usr/local/home/pi/myp/net-mgmt/cacti/work/stage/var/db/cacti/rra > /bin/mkdir -p > /usr/local/home/pi/myp/net-mgmt/cacti/work/stage/var/db/cacti/scripts > /usr/sbin/chown -R cacti:cacti > /usr/local/home/pi/myp/net-mgmt/cacti/work/stage/var/log/cacti > /usr/local/home/pi/myp/net-mgmt/cacti/work/stage/var/log/cacti > chown: cacti: illegal group name > *** Error code 1 > do_install in the Makefile does the chown. The user+group "cacti" is defined (USERS+GROUPS) but I guess its installation in passwd/group comes later in the process. The passwd/group insertion use to be done in a script in files, which I did away with. Hmm... ___ 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
On Tue, 2014-08-12 at 21:34 +0200, Kurt Jaeger wrote: > Hi! > > > Done. Thanks. > > Found it at: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192618 > > Looks cool! > > I'll test it on poudriere, but it's CEST here and I have to get up > early, so it will take probably until tomorrow evening to get to it. > Kewlness. I'm interested in what comes out. ___ 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
Done. Thanks. On Tue, 2014-08-12 at 06:58 +0200, Kurt Jaeger wrote: > Hi! > > > > > On Thu, 2014-08-07 at 08:29 +, lini...@freebsd.org wrote: > > > > > portname: net-mgmt/cacti > > > > > description:Web-driven graphing interface for RRDTool > > > > > maintainer: po...@freebsd.org > > > > > deprecated because: Not staged. See > > > > > Deleting Cacti would be a problem. > > > > Can you submit a patch ? > > > I have a directory tree tested and ready. There are changes, deletions, > > and additions so I did not create a diff tree against what is currently > > in the ports tree. > > I normally use > > diff -r -u -N old-dir new-dir > > to create diffs if there are changes, deletions and additions. > > You can also create a shar of the whole directory: > > tar cf cacti.shar --format shar cacti > > > What do I do with this? > > Then you can either create a new problem report (PR) on the bug tracker > and add the shar/diff to that problem report as attachment. > > The bug tracker can be found here: > > https://bugs.freebsd.org/bugzilla/ > > Or you put it on some website, post/mail the URL and I'll create > the PR. > ___ 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
On Thu, 2014-08-07 at 17:36 +0200, Kurt Jaeger wrote: > Hi! > > > On Thu, 2014-08-07 at 08:29 +, lini...@freebsd.org wrote: > > > portname: net-mgmt/cacti > > > description:Web-driven graphing interface for RRDTool > > > maintainer: po...@freebsd.org > > > deprecated because: Not staged. See > > > Deleting Cacti would be a problem. > > Can you submit a patch ? > I have a directory tree tested and ready. There are changes, deletions, and additions so I did not create a diff tree against what is currently in the ports tree. What do I do with this? ___ 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: po...@freebsd.org
On Sun, 2014-08-10 at 10:58 +0200, Marko Cupać wrote: > On Sat, 09 Aug 2014 12:13:46 -0700 > Dennis Glatting wrote: > > > I am working on updating Cacti to StageDir and have a question on web > > log access policies. > > > > Cacti creates a log directory under /usr/local/share/cacti where the > > poller stuffs log and other information into a file named cacti.log. > > There is a .htaccess file in that directory too. The log file is > > accessible though Cacti's web interface 'Console -> Utilities -> View > > Cacti Log File' and displayed in a 'tail -f' related way. > > > > Hier says /var/log/ is: > > > > miscellaneous system log files > > > > What is application preferential log file locations? Follow hier or > > application dependent? > > > > > > Cacti also manages RRD files under /usr/local/share/cacti/rra/. Hier > > says about /var/db/: > > > > miscellaneous automatically generated > > system-specific database files > > Hi Dennis, > > thanx for staging Cacti port. If you are changing log location outside > cacti web dir, how do you plan to make it accessible from web > interface? Do you intend to symlink it or something else? > > Perhaps it would be best to stage the port without any other changes > first, and consider improvements later? > The patches I have now, and NOT yet submitted, patch the settings files. I also patch the PERL load path in the .pl files from /usr/bin to /usr/local/bin. I am currently working on updating pkg-message and a verification install. The package passes the install checks (finally) mentioned in the Porter's Handbook. In my personal installation I've had the log files in /var/log since the beginning (several years) however access to the web interface is limited to three people. Of those three, I am the only one who looks at the logs. I DO NOT have a symlink in cacti/log. I am concerned about .htaccess in other installations which is why I posted, although I believe (falsely?) it isn't much of an issue. I also personally do not like applications stuffing their output (e.g., logs) into /usr/local. It's cumbersome from a management perspective and out of hier norm. That said, the application is the application and we want it to exist for a reason. If that means to respect where the application wants to put things, then that's what needs to happen. For example, I am assuming the specification of log files is in a single place (it is) but if it wasn't then I'm not here to correct many hard codings. ___ 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"
web application logs (Cacti)
I am working on updating Cacti to StageDir and have a question on web log access policies. Cacti creates a log directory under /usr/local/share/cacti where the poller stuffs log and other information into a file named cacti.log. There is a .htaccess file in that directory too. The log file is accessible though Cacti's web interface 'Console -> Utilities -> View Cacti Log File' and displayed in a 'tail -f' related way. Hier says /var/log/ is: miscellaneous system log files What is application preferential log file locations? Follow hier or application dependent? Cacti also manages RRD files under /usr/local/share/cacti/rra/. Hier says about /var/db/: miscellaneous automatically generated system-specific database files ___ 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
On Thu, 2014-08-07 at 17:36 +0200, Kurt Jaeger wrote: > Hi! > > > On Thu, 2014-08-07 at 08:29 +, lini...@freebsd.org wrote: > > > portname: net-mgmt/cacti > > > description:Web-driven graphing interface for RRDTool > > > maintainer: po...@freebsd.org > > > deprecated because: Not staged. See > > > Deleting Cacti would be a problem. > > Can you submit a patch ? > Is it not being maintained? I hate this tool (Cacti) but I have to support it for a client. If that means taking over maintenance, then I offer to do so. However, I am not a port maintainer, although I have done some local stuff, so there is a learning curve. A mentor would help. Ditto www/squid where the latest rev is 3.5 but ports is 3.3. I am running a patched 3.4. ___ 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
On Thu, 2014-08-07 at 08:29 +, lini...@freebsd.org wrote: > portname: net-mgmt/cacti > description:Web-driven graphing interface for RRDTool > maintainer: po...@freebsd.org > deprecated because: Not staged. See > > http://lists.freebsd.org/pipermail/freebsd-ports-announce/2014-May/80.html > expiration date:2014-08-31 > build errors: none. > overview: > http://portsmon.FreeBSD.org/portoverview.py?category=net-mgmt&portname=cacti > > Deleting Cacti would be a problem. ___ 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"
[Fwd: [opendmarc:tickets] #94 core dump in mlfi_eom()]
I generated a temporary patch and forwarded it to the email address in the OpenDMARC Makefile and filed a ticket. I got this response from the ticket but 1.3.0 is BETA, not RELEASE. Forwarded Message From: Murray S. Kucherawy Reply-to: "[opendmarc:tickets] " <9...@tickets.opendmarc.p.re.sf.net> To: [opendmarc:tickets] <9...@tickets.opendmarc.p.re.sf.net> Subject: [opendmarc:tickets] #94 core dump in mlfi_eom() Date: Thu, 31 Jul 2014 17:57:56 + * status: open --> closed * Comment: This is a duplicate of bug #72. This is fixed in 1.3.0. [tickets:#94] core dump in mlfi_eom() Status: closed Target: 1.2.0 Created: Wed Jul 30, 2014 11:43 PM UTC by Dennis Glatting Last Updated: Wed Jul 30, 2014 11:43 PM UTC Owner: nobody I am getting a core dump in mlfi_eom() under FreeBSD 10.0 where the OpenDMARC milter is followed by the OpenDKIM milter. According to gdb (below) dmarcf_findheader() fails to find the header and returns NULL but the code does not check for that condition. In my case, OpenDKIM reports: Daffy# grep s6UN87aC042254: /var/log/maillog 2014-07-30T17:08:08.440548-06:00 daffy sm-mta-in[42254]: s6UN87aC042254: from=bounce-1928280_html-805635706-13686654-17255...@bounce.email.ally.com, size=24697, class=0, nrcpts=1, msgid=566686d5-a4ce-4cc7-937c-a41b2540a...@xtinmta410.xt.local, bodytype=8BITMIME, proto=ESMTP, daemon=MTA-v4, relay=mta.email.ally.com [66.231.92.124] 2014-07-30T17:08:08.440971-06:00 daffy opendkim[1078]: s6UN87aC042254: mta.email.ally.com [66.231.92.124] not internal 2014-07-30T17:08:08.440982-06:00 daffy opendkim[1078]: s6UN87aC042254: not authenticated 2014-07-30T17:08:08.440988-06:00 daffy opendkim[1078]: s6UN87aC042254: no signing domain match for 'auto.ally.com' 2014-07-30T17:08:08.440993-06:00 daffy opendkim[1078]: s6UN87aC042254: no signing subdomain match for 'auto.ally.com' 2014-07-30T17:08:18.520076-06:00 daffy sm-mta-in[42254]: s6UN87aC042254: Milter (filter3): timeout before data read, where=eom 2014-07-30T17:08:18.520107-06:00 daffy sm-mta-in[42254]: s6UN87aC042254: Milter (filter3): to error state 2014-07-30T17:08:18.520112-06:00 daffy sm-mta-in[42254]: s6UN87aC042254: Milter: data, reject=451 4.3.2 Please try again later 2014-07-30T17:08:18.520140-06:00 daffy sm-mta-in[42254]: s6UN87aC042254: to=xy...@penford.com, delay=00:00:10, pri=54697, stat=Please try again later 2014-07-30T17:08:24.591284-06:00 daffy opendkim[1078]: s6UN87aC042254: ADSP query: A query failed for 'auto.ally.com' 2014-07-30T17:08:24.591326-06:00 daffy opendkim[1078]: s6UN87aC042254: Authentication-Results header add failed Daffy# gdb /usr/local/sbin/opendmarc opendmarc.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `opendmarc'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libopendmarc.so.1...done. Loaded symbols for /usr/local/lib/libopendmarc.so.1 Reading symbols from /usr/lib/libmilter.so.5...done. Loaded symbols for /usr/lib/libmilter.so.5 Reading symbols from /usr/lib/librt.so.1...done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 0 0x00407ae6 in mlfi_eom (ctx=0x801c1e800) at opendmarc.c:2049 2049 strncpy(addrbuf, from->hdr_value, sizeof addrbuf - 1); [New Thread 801c09000 (LWP 100894/opendmarc)] [New Thread 801c07400 (LWP 100683/opendmarc)] [New Thread 801c07000 (LWP 100681/opendmarc)] [New Thread 801c06400 (LWP 100169/opendmarc)] (gdb) p addrbuf $1 = '\0' Current language: auto; currently minimal (gdb) p from $2 = (struct dmarcf_header *) 0x0 Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/opendmarc/tickets/94/ To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ -- Dennis Glatting ___ 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: Squid aufs crashes under 10.0
On Mon, 2014-02-10 at 20:11 +0100, Florian Smeets wrote: > On 10/02/14 16:21, Dennis Glatting wrote: > > On Mon, 2014-02-10 at 11:15 +0400, Pavel Timofeev wrote: > >> So what should I do? > >> Write a PR to squid's bugzilla with link to this thread? > >> Fill FreeBSD ports' PR? (it seems like maintainer of squid doesn't > >> look at PRs about squid). > >> And it seems like this problem is retaled to all of squid ports, not > >> only to www/squid33. > >> > > > > Good question. I don't know. I ported 3.4 and sent email to the > > maintainer and to the list. Zip in response. > > > > I plan to take care of it this week. (squid34 + aufs patches) > My stuff here: fetch http://www.pki2.com/squid34.tar > Florian > ___ 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: Squid aufs crashes under 10.0
On Mon, 2014-02-10 at 11:15 +0400, Pavel Timofeev wrote:
> So what should I do?
> Write a PR to squid's bugzilla with link to this thread?
> Fill FreeBSD ports' PR? (it seems like maintainer of squid doesn't
> look at PRs about squid).
> And it seems like this problem is retaled to all of squid ports, not
> only to www/squid33.
>
Good question. I don't know. I ported 3.4 and sent email to the
maintainer and to the list. Zip in response.
My 3.4 patch to the Makefile, based on the 3.3 Makefile, are specific to
FreeBSD 10 and clang++ std=c++11 but I'm not a ports Makefile hack (it
leaves me bewildered at times) and that patch reflects it. Tutoring may
be required. :)
Dimitry's insight to cstring was insightful but that needs to be fed
back to the Squid developers.
I recall compiling 3.4 using GCC 4.8 and 4.9 but I don't recall the
results.
> 2014-02-09 23:56 GMT+04:00 Dimitry Andric :
> > On 09 Feb 2014, at 20:16, Dennis Glatting wrote:
> >> On Sun, 2014-02-09 at 19:37 +0100, Dimitry Andric wrote:
> > ...
> >>> Very bad coding practice, obviously. It should call Find() first, and
> >>> if that returns NULL, it should abort in some sort of controlled way.
> >>>
> >>
> >> Found that too but not the reason why:
> >>
> >> (lldb) run -d -z -F -f /root/squid.conf
> >> Process 23598 launched: './src/squid' (x86_64)
> >> Find(): Mmapped
> >> Find(): IpcIo
> >> Find(): DiskDaemon
> >> Find(): Blocking
> >> Find(): AIO
> >> Returning NULL
> >>
> >> There's a lot of faulty (i.e., a lack thereof) checking in Squid. For
> >> example, I replaced strlen() with a custom version that first checks for
> >> NULL and returns 0 if that is the case (strlen() was often called by
> >> std::cstring::c_str() that was not yet initialized). That small code
> >> fragment resolved a lot of SEGVs.
> >
> > There are a bunch of places where they use std::ostream::operator<< to
> > output e.g. configuration strings to the debug stream, for example in
> > uniqueHostname(), in src/tools.cc:
> >
> > const char *
> > uniqueHostname(void)
> > {
> > debugs(21, 3, HERE << " Config: '" << Config.uniqueHostname << "'");
> > return Config.uniqueHostname ? Config.uniqueHostname : getMyHostname();
> > }
> >
> > The problem case is when Config.uniqueHostname is NULL: this gets
> > converted into a std::string first (which is _undefined behavior_), then
> > it gets streamed to the debug stream.
> >
> > However, there is a difference between libstdc++ and libc++ here: the
> > former silently accepts NULL arguments passed to the std::string
> > constructor, creating a sort of "empty" string for you, which seems to
> > work as normal. The latter just stores your NULL pointer, and if you
> > actually try to do anything with it, the program will crash.
> >
> > To fix at least two places where this is done, drop the attached patches
> > in www/squid33/files.
> >
> > -Dimitry
> >
> >
> >
___
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: Squid aufs crashes under 10.0
On Sun, 2014-02-09 at 19:37 +0100, Dimitry Andric wrote:
> On 07 Feb 2014, at 14:24, Pavel Timofeev wrote:
> > Sorry, it has to be in freebsd-ports@ too.
> >
> > 2014-02-07 Pavel Timofeev :
> >> Hi!
> >> There is a problem with squid under FreeBSD10.0.
> >> Squid crashes immediately if storage type is set to aufs.
> >> It goes down during read of config file.
> >>
> >> No problem with diskd. No problem with aufs under FreeBSD9.2.
> >>
> >> Someone thinks that it's related to clang which is default compiler on
> >> FreeBSD 10.0.
>
> Nope, it is a bug in Squid's configure script. It recognizes FreeBSD
> 10.x and later as FreeBSD 1.x, causing it to disable pthreads support.
> This leads to the required DiskThreads module being disabled too. It
> then crashes when it tries to access a NULL pointer returned by
> DiskIOModule::Find("DiskThreads"), in src/fs/ufs/UFSSwapDir.cc:
>
> Fs::Ufs::UFSSwapDir::UFSSwapDir(char const *aType, const char *anIOType) :
> SwapDir(aType), IO(NULL), map(new FileMap()), suggest(0), swaplog_fd (-1),
> currentIOOptions(new ConfigOptionVector()), ioType(xstrdup(anIOType)),
> cur_size(0), n_disk_objects(0)
> {
> /* modulename is only set to disk modules that are built, by configure,
> * so the Find call should never return NULL here.
> */
> IO = new
> Fs::Ufs::UFSStrategy(DiskIOModule::Find(anIOType)->createStrategy());
> }
>
> Very bad coding practice, obviously. It should call Find() first, and
> if that returns NULL, it should abort in some sort of controlled way.
>
Found that too but not the reason why:
(lldb) run -d -z -F -f /root/squid.conf
Process 23598 launched: './src/squid' (x86_64)
Find(): Mmapped
Find(): IpcIo
Find(): DiskDaemon
Find(): Blocking
Find(): AIO
Returning NULL
There's a lot of faulty (i.e., a lack thereof) checking in Squid. For
example, I replaced strlen() with a custom version that first checks for
NULL and returns 0 if that is the case (strlen() was often called by
std::cstring::c_str() that was not yet initialized). That small code
fragment resolved a lot of SEGVs.
> In any case, the cause is the following fragment in the configure
> script:
>
> freebsd)
> if test `echo "$squid_host_os_version" | cut -b1` -lt 7 ; then
> { $as_echo "$as_me:${as_lineno-$LINENO}: pthread library
> requires FreeBSD 7 or later" >&5
> $as_echo "$as_me: pthread library requires FreeBSD 7 or later" >&6;}
> squid_opt_use_diskthreads="no"
> else
>
> which was edited here:
>
> http://bazaar.launchpad.net/~squid/squid/3-trunk/revision/11124
>
> I have attached a tentative patch for the port. However, this causes
> the configure script logic to run a little differently, and there is
> some sort of very strange bug in it, that leads to the SQUID_CFLAGS and
> SQUID_CXXFLAGS values being mangled in the default case.
>
> With my patch the DiskThreads detection runs again, but the variables
> are not mangled anymore, and this leads to -Werror being enabled again,
> causing errors about deprecated kerberos5 functions later on in the
> build.
>
> For now, I would not bother with -Werror and Squid, but just add
> --disable-strict-error-checking to CONFIGURE_ARGS in the Makefile.
>
> That is, until somebody with autoconf knowledge can fix the badly broken
> configure script...
>
>
> >> I recompiled www/squid33 with DEBUG option. Got coredump.
> >> Then I did and got this:
> >> gdb /usr/local/sbin/squid /var/squid/squid.core
> >>
> >> Reading symbols from /usr/lib/private/libheimipcc.so.11...done.
> >> Loaded symbols for /usr/lib/private/libheimipcc.so.11
> >> Reading symbols from /libexec/ld-elf.so.1...done.
> >> Loaded symbols for /libexec/ld-elf.so.1
> >> Segmentation fault (core dumped)
> >>
> >> Gdb goes down too =)
> >> Any ideas?
>
> Yes, please don't use gdb in base for anything serious. Use ports gdb
> instead. :-)
>
> -Dimitry
___
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"
Squid34 port
I am not a ports person but I have ported Squid34 to FreeBSD-10. It is an ugly hack of the 3.3 Makefile but the changes can be found here: http://www.pki2.com/squid34.tar Hopefully someone with ports update access and can better code Makefiles will update ports. ___ 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"
bind99 port
It's not nice to replace named.conf if it exists. I just wiped out three doing a portmaster under BETA4 to bind99-9.9.4_2. -- Dennis Glatting ___ 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"
openmpi doesn't install under F10
OpenMPI fails to install under FreeBSD-10 BETA4. It previously installed under BETA3. The key difference appears to be version _1 vs _2. Data follows. The system: Coke# uname -a FreeBSD Coke 10.0-BETA4 FreeBSD 10.0-BETA4 #1 r258932: Wed Dec 4 14:57:28 PST 2013 root@Coke:/usr/obj/usr/src/sys/XYZZY-FBSD10 amd64 Key part of the Makefile: PORTNAME= openmpi DISTVERSION=1.7.3 PORTREVISION= 2 The relevant diagnostic output: Coke# make -dA install ... + echo '===> Registering installation for openmpi-1.7.3_2' Execute: '/usr/bin/env FORCE_POST="rmdir kldxref mkfontscale mkfontdir fc-cache fonts.dir fonts.scale gtk-update-icon-cache gio-querymodules gtk-query-immodules ldconfig load-octave-pkg update-desktop-database update-mime-database gdk-pixbuf-query-loaders catalog.ports glib-compile-schemas" /usr/local/sbin/pkg-static register -i /usr/ports/net/openmpi/work/stage -m /usr/ports/net/openmpi/work/.metadir -f /usr/ports/net/openmpi/work/.PLIST.mktmp' + /usr/bin/env 'FORCE_POST=rmdir kldxref mkfontscale mkfontdir fc-cache fonts.dir fonts.scale gtk-update-icon-cache gio-querymodules gtk-query-immodules ldconfig load-octave-pkg update-desktop-database update-mime-database gdk-pixbuf-query-loaders catalog.ports glib-compile-schemas' /usr/local/sbin/pkg-static register -i /usr/ports/net/openmpi/work/stage -m /usr/ports/net/openmpi/work/.metadir -f /usr/ports/net/openmpi/work/.PLIST.mktmp pkg-static: lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/ompi-iof): No such file or directory pkg-static: lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/ompi-probe): No such file or directory pkg-static: lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/ompi-profiler): No such file or directory pkg-static: lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/orte-bootproxy.sh): No such file or directory pkg-static: lstat(/usr/ports/net/openmpi/work/stage/usr/local/mpi/openmpi/bin/orte-iof): No such file or directory pkg info from working installation: root@Monster:~ # pkg info | grep -i openmpi openmpi-1.7.3_1High Performance Message Passing Library ___ 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/gdal: gifdataset.cpp:599:23: error: 'PrintGifError' was not declared in this scope
On Mon, 4 Jun 2012, O. Hartmann wrote:
Since the last port update, I get this sticky error in gdal:
PrintGifError() was removed from giflib resulting in libraries that used
it to cause the error. I temp-hack a fix in my set-up by adding a line of
code to one of the files that form giflib:
void PrintGifError( void ) {}
Ugly.
libtool: compile: g++46 -O3 -pipe -fno-strict-aliasing -march=native
-Wl,-rpath=/usr/local/lib/gcc46 -Wall
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/port
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/gcore
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/alg
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/ogr
-I/usr/ports/graphics/gdal/work/gdal-1.9.0/ogr/ogrsf_frmts -DOGR_ENABLED
-I/usr/local/include -I/usr/ports/graphics/gdal/work/gdal-1.9.0/port
-I/usr/local/include -I/usr/local -I/usr/local/include
-I/usr/local/include -I/usr/local -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr/local/include -I/usr/local
-I/usr/local/include -I/usr/local -I/usr/local/include -I/usr
-I/usr/include -c gifdataset.cpp -fPIC -DPIC -o ../o/.libs/gifdataset.o
gifdataset.cpp: In static member function 'static GDALDataset*
GIFDataset::CreateCopy(const char*, GDALDataset*, int, char**,
GDALProgressFunc, void*)':
gifdataset.cpp:599:23: error: 'PrintGifError' was not declared in this scope
gifdataset.cpp:625:23: error: 'PrintGifError' was not declared in this scope
gmake[2]: *** [../o/gifdataset.lo] Error 1
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.9.0/frmts/gif'
gmake[1]: *** [gif-install-obj] Error 2
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.0/frmts'
gmake: *** [frmts-target] Error 2
*** [do-build] Error code 1
Stop in /usr/ports/graphics/gdal.
*** [build] Error code 1
Stop in /usr/ports/graphics/gdal.
===>>> make failed for graphics/gdal
===>>> Aborting update
Terminated
===>>> You can restart from the point of failure with this command line:
portmaster graphics/gdal
Regards,
Oliver
___
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"
