Re: Welcome flavors! portmaster now dead? synth?
On Mon, 2017-12-04 at 18:10 +0100, Jan Beich wrote: > Dennis Glatting <free...@pki2.com> 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 <free...@pki2.com> 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 omp.h
#include stdio.h
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: 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 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
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 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
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: 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 free...@pki2.com 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
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
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 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-mgmtportname=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
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
[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 cm-...@users.sf.net 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' repeats 2048= times= 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 d...@pki2.com ___ 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 d...@freebsd.org:
On 09 Feb 2014, at 20:16, Dennis Glatting free...@pki2.com 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 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 Sun, 2014-02-09 at 19:37 +0100, Dimitry Andric wrote:
On 07 Feb 2014, at 14:24, Pavel Timofeev tim...@gmail.com wrote:
Sorry, it has to be in freebsd-ports@ too.
2014-02-07 Pavel Timofeev tim...@gmail.com:
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
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 d...@pki2.com ___ 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
