MySQL ports and DTRACE options
Some time ago the port of mysql-server has an option to turn DTRACE support via HAVE_DTRACE. Currently this option is not available and the dtrace -l on startup of the MySQL server does not show any mysql-related probes, so this feature is disabled by default. For whatever reason this support has been removed, can we expect it to return as an option? Thanks. ___ 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: Who was the mental genius
On 6/6/2014 05:37, Paul Schmehl wrote: Something like that would have been more than adequate. As I pointed out, the warning you get about pkgng and the 9/1/2014 deadline is perfect. It's been there for a couple of months, and it pops up ever time you do a port. If you miss that and don't convert, you don't have anyone but yourself to blame. Which is exactly the same case with you and the 8.3 EOL. If your business relies involves server maintenance, it's entirely your responsibility to track EOL. How somebody with senior in their job title is looking to blame everyone else for failing something so basic is rich. You say semantics isn't important? You say 8.3 isn't old? It may not be old compared to a dog, but it reached its published end-of-life. Any expectation you have about support after EOL where probably forged by watching Microsoft support XP. That's not the model to expect. Install some mirrors in your house. ___ 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: print/cups-base web interface broken unable to print
On Thu, 5 Jun 2014 10:00:39 -0700 (PDT), Beeblebrox wrote: Anyone per chance with insight into filter failed error? I have already removed and re-created the printer several times. Installed cups related packages: cups-base-1.7.2_1, cups-client-1.7.2, cups-filters-1.0.53_1, cups-pdf-2.6.1_1, cups-pstoraster-8.15.4_7, foomatic-db-20140425, gutenprint-5.2.8, gutenprint-base-5.2.8, gutenprint-cups-5.2.8_1, gutenprint-foomatic-5.2.8_1, gutenprint-ijs-5.2.8 I vaguely remember similar problems when updating CUPS lately. After the update I had to install another package[*] to get printing working again. In addition to your list I have cups-image installed, maybe that helps. [*] I can't remember details which package I had to install, I do remember wondering if port dependencies or an UPDATING entry was missing. -- Thomas Mueller ___ 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: print/cups-base web interface broken unable to print
That port is 'cups-filters', which Beeblebrox already has. You'll want to check the cups log file. First edit your local/etc/cups/cupsd.conf file to enable logging, then try to print. That will give you a huge amount of entries in the log file, but somewhere there will be the name of the crashing filter. If you can't find it, post your logfile somewhere (beware that it may contain personal information, though), and we'll take a look at it. You can post it direct to me if you don't want to annoy the list with a large logfile. On 6 June 2014 16:51, Thomas Mueller tmuel...@sysgo.com wrote: On Thu, 5 Jun 2014 10:00:39 -0700 (PDT), Beeblebrox wrote: Anyone per chance with insight into filter failed error? I have already removed and re-created the printer several times. Installed cups related packages: cups-base-1.7.2_1, cups-client-1.7.2, cups-filters-1.0.53_1, cups-pdf-2.6.1_1, cups-pstoraster-8.15.4_7, foomatic-db-20140425, gutenprint-5.2.8, gutenprint-base-5.2.8, gutenprint-cups-5.2.8_1, gutenprint-foomatic-5.2.8_1, gutenprint-ijs-5.2.8 I vaguely remember similar problems when updating CUPS lately. After the update I had to install another package[*] to get printing working again. In addition to your list I have cups-image installed, maybe that helps. [*] I can't remember details which package I had to install, I do remember wondering if port dependencies or an UPDATING entry was missing. -- Thomas Mueller ___ 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 ___ 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: print/cups-base web interface broken unable to print
Hi Thomas, In addition to your list I have cups-image installed, maybe that helps. I traced the immediate problem to this missing file: /usr/local/libexec/cups/filter/commandtops The printer is ps-capable, and the ppd file was installed by hplip (which would have selected the most appropriate ppd). I also seem to have misunderstood what was advised in 20140331: Before upgrading you should force the removal of cups-image port, otherwise it will conflict with the new one. I understood this to mean print/cups-image is no longer needed and will cause conflict if it's still on the system. I'm going to try and completely re-build in poudriere reinstall all cups-related ports, then see where that leaves me. In the mean time, input as to which port should have built commandtops would be usefull (I assume print/cups-filter is the one). Thanks and Regards. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/print-cups-base-web-interface-broken-unable-to-print-tp5918098p5918390.html Sent from the freebsd-ports mailing list archive at Nabble.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: Portmaster -g no longer builds packages for dependencies?
On 05/06/2014 17:04, Dave Mischler wrote: I built a clean jail yesterday, portsnapped a new ports tree (i.e. fetch and extract) and built portmaster. Then I did portmaster -dgGH x11/xorg. It seemed to build Xorg properly, but there were no packages built for any of the many dependencies. I tried an older portmaster version that used to work and it seemed to have the same problem. Is this difficulty due to changes in the ports tree that broke dependent package building? Any suggestions? I have avoided poudriere so far because I like having no ports tree except in the jail. Given the case you use portmaster + pkgng, than package building is not supported yet. portmaster prints this into the console: === Package installation support cannot be used with pkgng yet, it will be disabled ___ 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: Who was the mental genius
On 6/06/2014 11:05 AM, Erich Dollansky wrote:
Hi,
On Thu, 05 Jun 2014 15:09:53 -0500
Paul Schmehl pschmehl_li...@tx.rr.com wrote:
That decided it was a good idea to completely break ports to force
people to upgrade? You couldn't come up with a warning system
instead of outright breaking ports? The idiots are apparently
running the asylum. {{sigh}}
this is the reason why I am asking for versions on the ports tree since
a decade. Ok, we have the revision now. Just go back in the revision
until it works. It is a good practice to make a note of the revision of
the running ports tree you have before updating it.
Erich
___
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
Paul,
I would echo Enrich's advise. Occassionally over the last 18 months my
ports tree build (of 487 ports) would fail. A workaround, for me, was
to update the ports tree and then revert /usr/ports/Mk - sometimes I'd
search through the svn logs for a clue, but more recently I'd revert a
week at a time. This being done to get something urgent out of the way
until a PR or fix was acted upon, and the folks supporting ports
meta-system are extremely responsive. Of course if a port needs
something that was changed under /usr/ports/Mk then you'll probably have
to revert the port as well and change the VERSION info as needed - this
is time-consuming and you really need to set aside some time for
testing. Its a real kludge but if you're stuck...
As I recall the change to ports to use a different make was tied to EOL
for 8.3, seems reasonable though something of a paradigm shift for ol'
timers (I'm a 2.2.5 person) that are used to building ports on a system
long after the base system has been EOL.
However it does lend itself to the argument that if changes to the ports
system is tied to the base operating system, then the meta-ports ie
/usr/ports/Mk should also. Unfortunately release management of the
ports meta-system, after a decade, remains elusive. Though it should be
noted that preparatory communication is improving - thanks to the team
and Eitan's contributions.
During some side-conversations I was surprised to learn that there is
some back-porting of fixes taking place in the ports branches ref:
http://svnweb.freebsd.org/ports/branches/2014Q2/ (thanks to Guido for bringing
that to our attention). So maybe this is your starting point and svn update the
particular ports you require is another option (as a temporary workaround)?
Dewayne.
___
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
Eclipse, git and source bundles
Hi, There's an outstanding PR which brings Eclipse up to 4.3.2: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188659 Unfortunately, this has been rejected as it clones a git-repo in order to run a build. I've had a look around the 'Net, and I can't seem to find a source download for the Eclipse 4.3.2. The older bundles can be found at: http://download.eclipse.org/technology/linuxtools/eclipse-build/ ; but this appears for have been discontinued for later versions. What should be the course of action if the upstream does not provide a source-bundle and expects a developer to check out the version from git in order to build a proejct? Cheers -- Jonathan Chen j...@chen.org.nz ___ 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: Eclipse, git and source bundles
On 6/6/2014 09:31, Jonathan Chen wrote: Hi, There's an outstanding PR which brings Eclipse up to 4.3.2: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188659 Unfortunately, this has been rejected as it clones a git-repo in order to run a build. I've had a look around the 'Net, and I can't seem to find a source download for the Eclipse 4.3.2. The older bundles can be found at: http://download.eclipse.org/technology/linuxtools/eclipse-build/ ; but this appears for have been discontinued for later versions. What should be the course of action if the upstream does not provide a source-bundle and expects a developer to check out the version from git in order to build a proejct? One solution is roll your own tarball and host it. You'd just clone the repo, rsync it to remove all the .gitignore / .git SVN CVS directories, tar it and upload it. Then you become the trusted source. :) I do this sometimes when I need the top of a repo between releases. John ___ 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: Who was the mental genius
On 6/5/14, 11:35 PM, John Marino wrote: On 6/6/2014 05:37, Paul Schmehl wrote: Something like that would have been more than adequate. As I pointed out, the warning you get about pkgng and the 9/1/2014 deadline is perfect. It's been there for a couple of months, and it pops up ever time you do a port. If you miss that and don't convert, you don't have anyone but yourself to blame. Which is exactly the same case with you and the 8.3 EOL. If your business relies involves server maintenance, it's entirely your responsibility to track EOL. How somebody with senior in their job title is looking to blame everyone else for failing something so basic is rich. You say semantics isn't important? You say 8.3 isn't old? It may not be old compared to a dog, but it reached its published end-of-life. Any expectation you have about support after EOL where probably forged by watching Microsoft support XP. That's not the model to expect. Install some mirrors in your house. Sure, but really a couple of lines to warn people and wave them towards next steps is probably advisable next time. -Alfred ___ 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: Who was the mental genius
On 6/6/2014 10:18, Alfred Perlstein wrote: Sure, but really a couple of lines to warn people and wave them towards next steps is probably advisable next time. Maybe we can alter the uname -a string to show the EOL so that every time the machine boots you see it on top of the MOTD. :) Of course, that won't help for the turn-on-and-forget servers with uptime measured in years... As a serious questions, where should such a you have X months/days remaining before server is EOL, update before then messages pop up? weekly cron messages sent to root? John ___ 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: Who was the mental genius
On 06 Jun 2014, at 10:22, John Marino freebsd.cont...@marino.st wrote: On 6/6/2014 10:18, Alfred Perlstein wrote: Sure, but really a couple of lines to warn people and wave them towards next steps is probably advisable next time. Maybe we can alter the uname -a string to show the EOL so that every time the machine boots you see it on top of the MOTD. :) Of course, that won't help for the turn-on-and-forget servers with uptime measured in years... As a serious questions, where should such a you have X months/days remaining before server is EOL, update before then messages pop up? weekly cron messages sent to root? periodic/security/450-check_eol ?(info if 90 days left, error if past eol) John ___ 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 ___ 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: print/cups-base web interface broken unable to print
@Robert I ran poudriere for the installed cups* ports and did an upgrade. The missing commandtops file was restored when upgrade installed cups-image (not cups-filter), so that problem is resolved. Printing still fails though. I have a Virtual-PDF printer defined in cups with Generic PPD. To simplify, I decided to test with this printer and again got Filter Failed message. Link to log with level debug for this job: https://docs.google.com/document/d/1YDWcTll0IFu-JUfhGCX1m2IT7gPxwqw0qoEa9_7X2J0/edit?usp=sharing Virtual-PDF PPD: DeviceURI cups-pdf:/ *FormatVersion: 4.3 *FileVersion: 1.1 *LanguageVersion: English *LanguageEncoding: ISOLatin1 *PCFileName:CUPS-PDF.PPD *Manufacturer: Generic *Product: (CUPS v1.1) *ModelName: Generic CUPS-PDF Printer *1284DeviceID: MFG:Generic;MDL:CUPS-PDF Printer;DES:Generic CUPS-PDF Printer;CLS:PRINTER;$ *% cupsFilter:application/vnd.cups-postscript 0 pstitleiconv *PSVersion: (2017.000) 0 *LanguageLevel: 2 *ColorDevice: True *DefaultColorSpace: RGB *FileSystem:False *Throughput:8 *LandscapeOrientation: Plus90 *TTRasterizer: Type42 Separately, I have noticed a potentially incompatible option setting as below: print/cups-base (MDNSRESPONDER or AVAHI) print/cups-filters (AVAHI) I don't want to use Zeroconf at all, so I prefer to turn these options off. While print/cups-filters gets built with UNSET AVAHI, print/cups-base does not and requires that at least ONE of the Zeroconf options have been enabled. I have no idea how compatible the resulting binaries will be when Avahi is used in port but MDNS in another. Thanks Regards. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/print-cups-base-web-interface-broken-unable-to-print-tp5918098p5918422.html Sent from the freebsd-ports mailing list archive at Nabble.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: Who was the mental genius
On 06/06/14 04:32, Paul Schmehl wrote:
--On June 5, 2014 at 11:50:38 PM +0200 Guido Falsi m...@madpilot.net
wrote:
On 06/05/14 23:43, Paul Schmehl wrote:
--On June 5, 2014 at 11:18:31 PM +0200 A.J. 'Fonz' van Werven
free...@skysmurf.nl wrote:
Paul Schmehl wrote:
That decided it was a good idea to completely break ports to force
people to upgrade? You couldn't come up with a warning system instead
of outright breaking ports? The idiots are apparently running the
asylum. {{sigh}}
It might help to know exactly what you're talking about... What is it
that
broke?
The change to make that causes this when you run pkg commands or try to
build ports:
Unknown modifier 't'
It was done deliberately to break ports so that people would be forced
to upgrade to a supported version.
https://forums.freebsd.org/viewtopic.php?f=5t=46291
No it was not done deliberately
Newer freebsd version moved to a newer make utility, and support for the
old one has been dropped after support for all old releases containing
it was ceased.
So they dropped the support accidentally? Is this really the time to
argue semantics?
No, in fact I'm stating the opposite, it was removed on purpose, BUT
care was taken to remove it once all releases without the needed code
were become unsupported, so no promise was broken.
Which releases are supported and for how long is well known, and
published in here when a new release is published:
http://www.freebsd.org/security/security.html#sup
The updates are free, as in no payment needed. What's keeping you from
performing a binary update of the base system every year or so?
I have two hosts on the internet for which the backup system failed. I
didn't catch it right away, so now I'm several days behind on backups.
I need to install a new system, but it requires ports I don't yet have
installed. So now I have two options; upgrade with my fingers crossed
and hope it works or scramble to find some way to backup before I
upgrade just in case the upgrade fails.
Running such an old system as any of the unsupported releases is also
most probably exposing you to security vulnerabilities.
First of all, 8.3 is not an old system. Secondly, you used to be able
to run old systems for a long time after support was dropped without
encountering issues like this. Finally, I'm a port maintainer of a fair
number of ports, so FreeBSD isn't free for me. I put a lot of time into
it.
When such a drastic change is made, it should be well advertised in
advance (think the pkgng announcement you get every time you install a
port) and not implemented in such a disruptive manner. It's clear from
the forum announcement that I linked to that I was not the only one
caught by surprise and that it didn't even work on supported versions
when the change was first implemented.
There are two arguments you make. In my opinion one is not acceptable
the other is quite acceptable:
you ask for advertisement before breaking things, I agree this is a
reasonable request. Discussion has been already started by others in
this thread about the best way to convey the information.
My opinion on this is that nagging people with automatic messages isn't
really a good idea, better have a well known place where to look and
people can look there, but I see that many people think the opposite,
this is just me though. If the nag message way is taken I only suggest
that a knob to disable such nagging is also made available.
You seem also to ask for not breaking things in unsupported releases,
this is not a reasonable request.
Which releases are supported or not is well known, documented and
declared in advance at release time. Things WILL anyway break
unexpectedly in unsupported releases, because changes in the supported
part of the tree are simply not tested in unsupported ones (that's part
of the definition of supported vs unsupported...)
--
Guido Falsi m...@madpilot.net
___
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
Unable to build graphics/libEGL on 10.0 but not on 9.2
Hi all, is there differences with make.conf beetwen 9.2 and 10.0? I have this make.conf (into poudriere) : http://bpaste.net/show/347960/ On the 9.2 graphics/libEGL compiles, but on 10.0 it is ignored with this message : Ignored: Please enable WITH_NEW_XORG, libEGL needs libdrm higher then 2.4.24. This errors comes from https://github.com/freebsd/freebsd-ports/blob/master/graphics/libEGL/Makefile#L26 but what's weird is that I have this WITH_NEW_XORG=yes at line 1 which might evaluate .if ! defined(WITH_NEW_XORG) to false. Thanks by advance for your 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
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ devel/libbobcat | 3.18.01 | 3.23.00 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ 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: print/cups-base web interface broken unable to print
Hmm. I can't see any attempts to print in that log file. Perhaps I could find it if you told me the name of the file you printed, or of the name of the program you printed from. On 6 June 2014 19:15, Beeblebrox zap...@berentweb.com wrote: @Robert I ran poudriere for the installed cups* ports and did an upgrade. The missing commandtops file was restored when upgrade installed cups-image (not cups-filter), so that problem is resolved. Printing still fails though. I have a Virtual-PDF printer defined in cups with Generic PPD. To simplify, I decided to test with this printer and again got Filter Failed message. Link to log with level debug for this job: https://docs.google.com/document/d/1YDWcTll0IFu-JUfhGCX1m2IT7gPxwqw0qoEa9_7X2J0/edit?usp=sharing Virtual-PDF PPD: DeviceURI cups-pdf:/ *FormatVersion: 4.3 *FileVersion: 1.1 *LanguageVersion: English *LanguageEncoding: ISOLatin1 *PCFileName:CUPS-PDF.PPD *Manufacturer: Generic *Product: (CUPS v1.1) *ModelName: Generic CUPS-PDF Printer *1284DeviceID: MFG:Generic;MDL:CUPS-PDF Printer;DES:Generic CUPS-PDF Printer;CLS:PRINTER;$ *% cupsFilter:application/vnd.cups-postscript 0 pstitleiconv *PSVersion: (2017.000) 0 *LanguageLevel: 2 *ColorDevice: True *DefaultColorSpace: RGB *FileSystem:False *Throughput:8 *LandscapeOrientation: Plus90 *TTRasterizer: Type42 Separately, I have noticed a potentially incompatible option setting as below: print/cups-base (MDNSRESPONDER or AVAHI) print/cups-filters (AVAHI) I don't want to use Zeroconf at all, so I prefer to turn these options off. While print/cups-filters gets built with UNSET AVAHI, print/cups-base does not and requires that at least ONE of the Zeroconf options have been enabled. I have no idea how compatible the resulting binaries will be when Avahi is used in port but MDNS in another. Thanks Regards. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/print-cups-base-web-interface-broken-unable-to-print-tp5918098p5918422.html Sent from the freebsd-ports mailing list archive at Nabble.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 ___ 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: print/cups-base web interface broken unable to print
Hmm. I can't see any attempts to print in that log file. Perhaps I could
find it if you told me the name of the file you printed, or of the name of
the program you printed from.
It was a simple text file in mousepad - it was probably unnamed
No matter though, same result with file named msci.gnumeric printed from
gnumeric table:
Printed to Virtual-pdf printer:
https://docs.google.com/document/d/1N9iVnHXT2T8fHn-SW2JmrC8DVeSt0uIDBnJN9F4EkDE/edit?usp=sharing
Printed to HP2100:
https://docs.google.com/document/d/1aO2wHr1S_tSO7GuHyvl9DSsVOUgiBUtW3e0-412Fia4/edit?usp=sharing
I recalled that the cups-pdf.conf file has separate settings, and I checked
those before printing. Unfortunately, does not log to the file specified
but populates cups/error_log. Settings in cups/cups-pdf.conf
Out ${HOME}/Print
Spool /var/spool/cups-pdf
Grp daemon
Log /var/log/cups/cups-pdf
LogType 4
GhostScript /usr/local/bin/gs
GSTmp /tmp
DecodeHexStrings 1
FixNewlines 1
Regards.
___
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: print/cups-base web interface broken unable to print
Yes, no wonder I couldn't find anything there. /var/log/cups/error_log is
the one that will contain the information. That is where the text about
what filter program is crashing will be. It is probably a missing library
somewhere.
On 6 June 2014 21:36, Beeblebrox zap...@berentweb.com wrote:
Hmm. I can't see any attempts to print in that log file. Perhaps I could
find it if you told me the name of the file you printed, or of the name
of
the program you printed from.
It was a simple text file in mousepad - it was probably unnamed
No matter though, same result with file named msci.gnumeric printed from
gnumeric table:
Printed to Virtual-pdf printer:
https://docs.google.com/document/d/1N9iVnHXT2T8fHn-SW2JmrC8DVeSt0uIDBnJN9F4EkDE/edit?usp=sharing
Printed to HP2100:
https://docs.google.com/document/d/1aO2wHr1S_tSO7GuHyvl9DSsVOUgiBUtW3e0-412Fia4/edit?usp=sharing
I recalled that the cups-pdf.conf file has separate settings, and I checked
those before printing. Unfortunately, does not log to the file specified
but populates cups/error_log. Settings in cups/cups-pdf.conf
Out ${HOME}/Print
Spool /var/spool/cups-pdf
Grp daemon
Log /var/log/cups/cups-pdf
LogType 4
GhostScript /usr/local/bin/gs
GSTmp /tmp
DecodeHexStrings 1
FixNewlines 1
Regards.
___
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
___
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
error during cups compilation
Dear FreeBSD friends, The following error popped up during installation of cups: ~/portupgrade -R -N cups dirsvc.o: In function `cupsdStartBrowsing': /usr/ports/print/cups-base/work/cups-1.7.2/scheduler/dirsvc.c:244: undefined reference to `dnssdRegisterAllPrinters' dirsvc.o: In function `cupsdStopBrowsing': /usr/ports/print/cups-base/work/cups-1.7.2/scheduler/dirsvc.c:262: undefined reference to `dnssdDeregisterAllPrinters' cc: error: linker command failed with exit code 1 (use -v to see invocation) gmake[3]: *** [cupsd] Error 1 gmake[3]: Leaving directory `/usr/ports/print/cups-base/work/cups-1.7.2/scheduler' gmake[2]: *** [all] Error 1 gmake[2]: Leaving directory `/usr/ports/print/cups-base/work/cups-1.7.2' === Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Has anyone an idea how to solve this? Does ``undefined reference'' mean that there is no definition for this function or that the appropriate library is missing? How can I determine the required libraries? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans ___ 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: error during cups compilation
Enable one of the Zeroconf options. See http://freebsd.1045724.n5.nabble.com/print-cups-base-not-possible-to-build-without-Zeroconf-td5916416.html - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/error-during-cups-compilation-tp5918456p5918461.html Sent from the freebsd-ports mailing list archive at Nabble.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: Portmaster -g no longer builds packages for dependencies?
Given the case you use portmaster + pkgng, than package building is not supported yet. portmaster prints this into the console: === Package installation support cannot be used with pkgng yet, it will be disabled This worked the last time I rebuilt everything from scratch (December 19,2013): portmaster 3.17.3. I have built packages that way since but didn't build Xorg so I'm not sure that everything was still working right after that. In case it matters, I am running amd64 9-stable (now showing as 9.3-beta1). ___ 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: print/cups-base web interface broken unable to print
/var/log/cups/error_log is the one that will contain the information. That is where the text about what filter program is crashing will be. It is probably a missing library somewhere. * The files sent to you were all from error_log. File was cleaned out before starting the server, to provide per-event results. * What ports is it that's missing a library - cups-filter? No options other then AVAHI there, and it's disabled... - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/print-cups-base-web-interface-broken-unable-to-print-tp5918098p5918463.html Sent from the freebsd-ports mailing list archive at Nabble.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: Who was the mental genius
On Fri, 6 Jun 2014, John Marino wrote: On 6/6/2014 10:18, Alfred Perlstein wrote: Sure, but really a couple of lines to warn people and wave them towards next steps is probably advisable next time. Maybe we can alter the uname -a string to show the EOL so that every time the machine boots you see it on top of the MOTD. :) Of course, that won't help for the turn-on-and-forget servers with uptime measured in years... As a serious questions, where should such a you have X months/days remaining before server is EOL, update before then messages pop up? weekly cron messages sent to root? It could reasonably be added to /etc/periodic/security. Updating the EOL date would have to be part of the release process. And the message might point people to the list of EOL dates on freebsd.org for additional information. ___ 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: To all port maintainers: libtool
Quoting Tijl Coosemans t...@freebsd.org (from Thu, 5 Jun 2014 18:53:03 +0200): On Thu, 05 Jun 2014 09:39:21 -0500 Bryan Drewery wrote: I don't know what .la files are used for and have no time currently to research it. What is the impact to non-ports consumers of removing .la files? Do they also need patches to make them build? Removing a .la file is somewhat like a library version bump. Anything that depends on it needs to be recompiled. I remember from tests way in the past that not all programs will be happy when the .la files are not there. I remember that I once tried to remove the .la files but it didn't work as the program wanted to open the .la files (after recompile). Maybe libltdl is openening them? Did you make some checks/tests in this regard? Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Who was the mental genius
On 2014-06-05 15:51, Dewayne Geraghty wrote:
On 6/06/2014 6:09 AM, Paul Schmehl wrote:
That decided it was a good idea to completely break ports to force
people to upgrade? You couldn't come up with a warning system instead
of outright breaking ports? The idiots are apparently running the
asylum. {{sigh}}
Are you referring to the /usr/ports/UIDs going away? I experienced a
ports build failure attributable to that. Fortunately the person
responsible redressed within 62 minutes. But it does raise the spectre
of change control over components that are effectively live.
That was me -- sorry! I would have seen the handful of mails I was sent
if my spam filters at work hadn't immediately gone crazy. Whoops!
___
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: Who was the mental genius
--On June 6, 2014 at 8:35:06 AM +0200 John Marino freebsd.cont...@marino.st wrote: On 6/6/2014 05:37, Paul Schmehl wrote: Something like that would have been more than adequate. As I pointed out, the warning you get about pkgng and the 9/1/2014 deadline is perfect. It's been there for a couple of months, and it pops up ever time you do a port. If you miss that and don't convert, you don't have anyone but yourself to blame. Which is exactly the same case with you and the 8.3 EOL. If your business relies involves server maintenance, it's entirely your responsibility to track EOL. How somebody with senior in their job title is looking to blame everyone else for failing something so basic is rich. You say semantics isn't important? You say 8.3 isn't old? It may not be old compared to a dog, but it reached its published end-of-life. Any expectation you have about support after EOL where probably forged by watching Microsoft support XP. That's not the model to expect. Install some mirrors in your house. I have no idea why you've decided to assume the role of preacher and tell me what to do, but I can assure you that you are completely ignorant of the circumstances behind my complaints. They have absolutely nothing to do with my professional position. Regarding your comment about EOL, one thing has been almost constant throughout my professional career. When a system goes EOL it isn't deliberately broken by the vendor. The system will happily hum along and function for years after EOL without problems. Breaking something as vital as the ports system without proper warning is not a way to win converts to your platform or to retain those who have used it for a long time. Again. I think FreeBSD is a great OS. It's the only Unix platform I use (and I've tried them all, trust me.) It saddens me to see it losing market share because of tone deaf development processes that ignore the end user. If I didn't give a shit, I wouldn't have complained. Your reference to Microsoft is laughable. I haven't done support or admin work on a Windows platform in more than sixteen years. As for your idiotic advice, not everyone in the world has the wherewithal to install some mirrors in your house, but my recommendation to you would be to look in the ones at your house before you ignorantly criticize others. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson There are some ideas so wrong that only a very intelligent person could believe in them. George Orwell ___ 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: To all port maintainers: libtool
On Fri, 06 Jun 2014 15:02:24 +0200 Alexander Leidinger wrote: Quoting Tijl Coosemans t...@freebsd.org (from Thu, 5 Jun 2014 18:53:03 +0200): On Thu, 05 Jun 2014 09:39:21 -0500 Bryan Drewery wrote: I don't know what .la files are used for and have no time currently to research it. What is the impact to non-ports consumers of removing .la files? Do they also need patches to make them build? Removing a .la file is somewhat like a library version bump. Anything that depends on it needs to be recompiled. I remember from tests way in the past that not all programs will be happy when the .la files are not there. I remember that I once tried to remove the .la files but it didn't work as the program wanted to open the .la files (after recompile). Maybe libltdl is openening them? Did you make some checks/tests in this regard? Essentially .la files are small shell scripts that set some variables so in theory they can be used in all kinds of places, but this seems of little practical value. Libltdl can open and parse .la files (to find the name of the .so file it can dlopen) but it can also work directly with .so files. If a program uses .la files directly then the port can't delete them of course, but so far I haven't encountered such programs. ___ 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: Who was the mental genius
--On June 6, 2014 at 5:27:58 PM +1000 Dewayne Geraghty
dewayne.gerag...@heuristicsystems.com.au wrote:
On 6/06/2014 11:05 AM, Erich Dollansky wrote:
Hi,
On Thu, 05 Jun 2014 15:09:53 -0500
Paul Schmehl pschmehl_li...@tx.rr.com wrote:
That decided it was a good idea to completely break ports to force
people to upgrade? You couldn't come up with a warning system
instead of outright breaking ports? The idiots are apparently
running the asylum. {{sigh}}
this is the reason why I am asking for versions on the ports tree since
a decade. Ok, we have the revision now. Just go back in the revision
until it works. It is a good practice to make a note of the revision of
the running ports tree you have before updating it.
Erich
___
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
Paul,
I would echo Enrich's advise. Occassionally over the last 18 months my
ports tree build (of 487 ports) would fail. A workaround, for me, was
to update the ports tree and then revert /usr/ports/Mk - sometimes I'd
search through the svn logs for a clue, but more recently I'd revert a
week at a time. This being done to get something urgent out of the way
until a PR or fix was acted upon, and the folks supporting ports
meta-system are extremely responsive. Of course if a port needs
something that was changed under /usr/ports/Mk then you'll probably have
to revert the port as well and change the VERSION info as needed - this
is time-consuming and you really need to set aside some time for
testing. Its a real kludge but if you're stuck...
As I recall the change to ports to use a different make was tied to EOL
for 8.3, seems reasonable though something of a paradigm shift for ol'
timers (I'm a 2.2.5 person) that are used to building ports on a system
long after the base system has been EOL.
However it does lend itself to the argument that if changes to the ports
system is tied to the base operating system, then the meta-ports ie
/usr/ports/Mk should also. Unfortunately release management of the
ports meta-system, after a decade, remains elusive. Though it should be
noted that preparatory communication is improving - thanks to the team
and Eitan's contributions.
During some side-conversations I was surprised to learn that there is
some back-porting of fixes taking place in the ports branches ref:
http://svnweb.freebsd.org/ports/branches/2014Q2/ (thanks to Guido for
bringing that to our attention). So maybe this is your starting point and
svn update the particular ports you require is another option (as a
temporary workaround)?
I appreciate the advice. I've elected to setup an alternate form of backup
(using rsync over ssh to backup each server to its sibling) so I can
upgrade to 8.4 without worrying about a loss. Once that's complete, I'll
get the new backup system in place (using Storgrid backing up to a SAN at
the hosting provider).
After that I can comfortably move to 9 or 10. I don't like running
bleeding edge releases on production servers. This work I'm doing is
entirely voluntary, for a hobby website with a small budget, so I have to
be very careful about not breaking anything.
When I installed one of these servers 9 wouldn't even install (missing RAID
drivers), which is why I used 8.
--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead. Thomas Jefferson
There are some ideas so wrong that only a very
intelligent person could believe in them. George Orwell
___
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: Who was the mental genius
On 6/6/2014 16:19, Paul Schmehl wrote: --On June 6, 2014 at 8:35:06 AM +0200 John Marino I have no idea why you've decided to assume the role of preacher and tell me what to do, but I can assure you that you are completely ignorant of the circumstances behind my complaints. They have absolutely nothing to do with my professional position. That doesn't excuse your first post or any after it. Regarding your comment about EOL, one thing has been almost constant throughout my professional career. When a system goes EOL it isn't deliberately broken by the vendor. The system will happily hum along and function for years after EOL without problems. Breaking something as vital as the ports system without proper warning is not a way to win converts to your platform or to retain those who have used it for a long time. The situation already been clearly explained to you. EOL has a clear definition. Again. I think FreeBSD is a great OS. It's the only Unix platform I use (and I've tried them all, trust me.) It saddens me to see it losing market share because of tone deaf development processes that ignore the end user. If I didn't give a shit, I wouldn't have complained. Yes, if indeed it is losing market share, that is why. Your reference to Microsoft is laughable. I haven't done support or admin work on a Windows platform in more than sixteen years. Whoosh. As for your idiotic advice, not everyone in the world has the wherewithal to install some mirrors in your house, but my recommendation to you would be to look in the ones at your house before you ignorantly criticize others. Said the guy titling his post, Who is the mental genius? It was lost on you, so again more clearly: Any issue you suffered as a result of intentionally or negligently ignoring EOL is your own fault, so stop blaming others. Since I am not blaming others for my failings, why do I need to install mirrors in my house? Another nonsense gem from Paul Schmehl. John ___ 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: Who was the mental genius
--On June 6, 2014 at 10:51:04 AM +0200 Michael Gmelin gre...@freebsd.org wrote: On 06 Jun 2014, at 10:22, John Marino freebsd.cont...@marino.st wrote: On 6/6/2014 10:18, Alfred Perlstein wrote: Sure, but really a couple of lines to warn people and wave them towards next steps is probably advisable next time. Maybe we can alter the uname -a string to show the EOL so that every time the machine boots you see it on top of the MOTD. :) Of course, that won't help for the turn-on-and-forget servers with uptime measured in years... As a serious questions, where should such a you have X months/days remaining before server is EOL, update before then messages pop up? weekly cron messages sent to root? periodic/security/450-check_eol ?(info if 90 days left, error if past eol) EOL notification is not the problem. The problem is breaking ports at EOL. That's a special circumstance and begs for notification. This isn't rocket science. For at least two months now this notification has been popping up every time I work on ports. /!\ WARNING /!\ pkg_install EOL is scheduled for 2014-09-01. Please consider migrating to pkgng http://blogs.freebsdish.org/portmgr/2014/02/03/time-to-bid-farewell-to-the-old-pkg_-tools/ If you do not want to see this message again set NO_WARNING_PKG_INSTALL_EOL=yes in your make.conf Do you think I would miss the 9/1 deadline? Not a chance. But the advance warning gives me time to plan the change when it's convenient for me. This change has me scrambling to adapt. Granted, it only took me a few minutes to figure out what to do, but not everyone has the background and experience to do that. Some will simply panic. Others will switch to Linux. That doesn't seem like a goal FreeBSD should support. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson There are some ideas so wrong that only a very intelligent person could believe in them. George Orwell ___ 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: To all port maintainers: libtool
On 6/6/14, 9:27 AM, Tijl Coosemans wrote: On Fri, 06 Jun 2014 15:02:24 +0200 Alexander Leidinger wrote: Quoting Tijl Coosemans t...@freebsd.org (from Thu, 5 Jun 2014 18:53:03 +0200): On Thu, 05 Jun 2014 09:39:21 -0500 Bryan Drewery wrote: I don't know what .la files are used for and have no time currently to research it. What is the impact to non-ports consumers of removing .la files? Do they also need patches to make them build? Removing a .la file is somewhat like a library version bump. Anything that depends on it needs to be recompiled. I remember from tests way in the past that not all programs will be happy when the .la files are not there. I remember that I once tried to remove the .la files but it didn't work as the program wanted to open the .la files (after recompile). Maybe libltdl is openening them? Did you make some checks/tests in this regard? Essentially .la files are small shell scripts that set some variables so in theory they can be used in all kinds of places, but this seems of little practical value. Libltdl can open and parse .la files (to find the name of the .so file it can dlopen) but it can also work directly with .so files. If a program uses .la files directly then the port can't delete them of course, but so far I haven't encountered such programs. My main question was non-ports consumers though. What is the impact on them? We're talking a lot about bumping revisions and forcing rebuilds. Will non-ports consumers require rebuild or changes if .la files are missing? Would these non-ports consumers be able to properly build and link without .la files and without modifications? These .la files seem similar to .pc files which are often critical to out-of-tree consumers that assume Linux /usr paths instead of /usr/local paths. -- Regards, Bryan Drewery ___ 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: Who was the mental genius
On Fri, Jun 06, 2014 at 09:34:26AM -0500, Paul Schmehl wrote: --On June 6, 2014 at 10:51:04 AM +0200 Michael Gmelin gre...@freebsd.org wrote: On 06 Jun 2014, at 10:22, John Marino freebsd.cont...@marino.st wrote: On 6/6/2014 10:18, Alfred Perlstein wrote: Sure, but really a couple of lines to warn people and wave them towards next steps is probably advisable next time. Maybe we can alter the uname -a string to show the EOL so that every time the machine boots you see it on top of the MOTD. :) Of course, that won't help for the turn-on-and-forget servers with uptime measured in years... As a serious questions, where should such a you have X months/days remaining before server is EOL, update before then messages pop up? weekly cron messages sent to root? periodic/security/450-check_eol ?(info if 90 days left, error if past eol) EOL notification is not the problem. The problem is breaking ports at EOL. That's a special circumstance and begs for notification. This isn't rocket science. For at least two months now this notification has been popping up every time I work on ports. /!\ WARNING /!\ pkg_install EOL is scheduled for 2014-09-01. Please consider migrating to pkgng http://blogs.freebsdish.org/portmgr/2014/02/03/time-to-bid-farewell-to-the-old-pkg_-tools/ If you do not want to see this message again set NO_WARNING_PKG_INSTALL_EOL=yes in your make.conf Do you think I would miss the 9/1 deadline? Not a chance. But the advance warning gives me time to plan the change when it's convenient for me. This change has me scrambling to adapt. Granted, it only took me a few minutes to figure out what to do, but not everyone has the background and experience to do that. Some will simply panic. Others will switch to Linux. That doesn't seem like a goal FreeBSD should support. The mental genius is me apparently (thanks for the kind words, btw) I'm responsible for both the pkg_install EOL message and for breaking ports tree with older make (btw you can recover with installing manually bmake). Yes it would have been a good idea to give a warning to the user about the fact that the ports tree won't be support long on after EOL of 8.3, given the ports tree will break again quite soon after EOL of 8.4 I should think about adding such a message right now (btw this is not that easy in the case we are talking about because I have no way to differentiate a fmake with support for :tl from a fmake without support for :tu same goes for :tu) hence it is hard to print a message. Concerning breaking after 8.4 EOL it might be easier. The reason why I haven't added a warning like I did for pkg_install is that: 1. it is hard to detect when to print the warning (more complicated that one can imagine first) 2. freebsd-update is already issueing a warning about EOL coming soon so I would have expected user to already know when EOL is coming and/or getting the info from freebsd-update. regards, Bapt pgpUm0hoynrFf.pgp Description: PGP signature
[QAT] 356377: 4x leftovers
- STAGEify - Add LICENSE - Build ID: 20140603162401-12058 Job owner: jh...@freebsd.org Buildtime: 3 days Enddate: Fri, 06 Jun 2014 15:21:07 GMT Revision: 356377 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=356377 - Port:audio/waheela 0.3_5 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~jh...@freebsd.org/20140603162401-12058-346262/waheela-0.3_5.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~jh...@freebsd.org/20140603162401-12058-346263/waheela-0.3_5.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~jh...@freebsd.org/20140603162401-12058-346264/waheela-0.3_5.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~jh...@freebsd.org/20140603162401-12058-346265/waheela-0.3_5.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140603162401-12058 redports https://qat.redports.org/ ___ 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: Who was the mental genius
--On June 6, 2014 at 5:17:40 PM +0200 Baptiste Daroussin b...@freebsd.org wrote: On Fri, Jun 06, 2014 at 09:34:26AM -0500, Paul Schmehl wrote: --On June 6, 2014 at 10:51:04 AM +0200 Michael Gmelin gre...@freebsd.org wrote: On 06 Jun 2014, at 10:22, John Marino freebsd.cont...@marino.st wrote: On 6/6/2014 10:18, Alfred Perlstein wrote: Sure, but really a couple of lines to warn people and wave them towards next steps is probably advisable next time. Maybe we can alter the uname -a string to show the EOL so that every time the machine boots you see it on top of the MOTD. :) Of course, that won't help for the turn-on-and-forget servers with uptime measured in years... As a serious questions, where should such a you have X months/days remaining before server is EOL, update before then messages pop up? weekly cron messages sent to root? periodic/security/450-check_eol ?(info if 90 days left, error if past eol) EOL notification is not the problem. The problem is breaking ports at EOL. That's a special circumstance and begs for notification. This isn't rocket science. For at least two months now this notification has been popping up every time I work on ports. /!\ WARNING /!\ pkg_install EOL is scheduled for 2014-09-01. Please consider migrating to pkgng http://blogs.freebsdish.org/portmgr/2014/02/03/time-to-bid-farewell-to-t he-old-pkg_-tools/ If you do not want to see this message again set NO_WARNING_PKG_INSTALL_EOL=yes in your make.conf Do you think I would miss the 9/1 deadline? Not a chance. But the advance warning gives me time to plan the change when it's convenient for me. This change has me scrambling to adapt. Granted, it only took me a few minutes to figure out what to do, but not everyone has the background and experience to do that. Some will simply panic. Others will switch to Linux. That doesn't seem like a goal FreeBSD should support. The mental genius is me apparently (thanks for the kind words, btw) I'm responsible for both the pkg_install EOL message and for breaking ports tree with older make (btw you can recover with installing manually bmake). No offense was meant. I deliberately chose the subject to stimulate discussion, which it has obviously done. Yes it would have been a good idea to give a warning to the user about the fact that the ports tree won't be support long on after EOL of 8.3, given the ports tree will break again quite soon after EOL of 8.4 I should think about adding such a message right now (btw this is not that easy in the case we are talking about because I have no way to differentiate a fmake with support for :tl from a fmake without support for :tu same goes for :tu) hence it is hard to print a message. I fully understand this. Sometimes figuring out how to warn a user is complex and difficult. However, the decision to inform should not hinge on the difficulty of the implementation but on the criticality of the change. However, you can detect the RELEASE version and you do know the EOL date, so you could base detection on that. Pseudo warning triggered with every port install or upgrade: WARNING!!! 8.4 goes EOL on m/d/yy and ports will break. Be sure to plan an upgrade before EOL or, alternatively, use svn -rev to retain your current version of ports until you can successfully upgrade. Concerning breaking after 8.4 EOL it might be easier. Well, I'm glad you tipped me off to that since I'm presently upgrading to 8.4. That *might* have influenced me to go to 9 instead, had I known it before deciding. The reason why I haven't added a warning like I did for pkg_install is that: 1. it is hard to detect when to print the warning (more complicated that one can imagine first) 2. freebsd-update is already issueing a warning about EOL coming soon so I would have expected user to already know when EOL is coming and/or getting the info from freebsd-update. Again, this isn't an EOL issue. EOL is a fact of life. RELEASES go EOL all the time. They have for decades. What's different about this is that it broke ports. THAT should not be taken lightly and should require thorough thought about how to notify end users in a significant way that's not likely to be missed. The pkg_install message is a *perfect* way of notifying the end user. It can't be missed. And it nags you every time you install or upgrade a port. Something similar should have been done for the change to fmake, and certainly needs to be done before 8.4 goes EOL. I appreciate your willingness to engage on this point, because I think it's a critical issue that impacts a lot of users. Very few of those users will complain effectively or in the right forums. Some of them will simply give up and change OSes. That would be a shame. The issue wasn't that difficult for me to recover from, and I am proceeding with my work. Others may not be so fortunate. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't
Re: Who was the mental genius
On Fri, 6 Jun 2014, Paul Schmehl wrote: No offense was meant. I deliberately chose the subject to stimulate discussion, which it has obviously done. Stimulating discussion without insulting people generally gives better results. Look, we are all doing the best we can with what we've got. The ports people have been trying to accomplish the equivalent of turning a cruise ship around in a bathtub without rattling the silverware. It's not possible to anticipate every issue, particularly when there are so many. The way improvements are made is for interested people (that is, you) to get involved and help to improve it. The challenge you have created is to anticipate the next issue and report it, preferably with a plan for a solution, before it happens. ___ 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
libiconv problems
According to UPDATING, I should be able to do this to resolve issues with libiconv: pkg query %ro libiconv ports_to_update On my system, running 8.4 RELEASE with the old packaging system, this command doesn't do anything. I ran pkg_info to get a list of dependent apps and then piped that into xargs portmaster, but I got errors. # cat dependencies.txt | xargs portmaster === /var/db/pkg/Information does not exist === Aborting update === Killing background jobs Terminated Terminated Terminated Terminated Terminated Terminated Terminated Terminated Terminated Terminated Terminated === Exiting So how can I fix this problem without updating to the new pkg system? -- Paul Schmehl (pa...@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/infosecurity/ ___ 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: Who was the mental genius
On Fri, 6 Jun 2014 11:02:48 -0600 (MDT), Warren Block stated: Stimulating discussion without insulting people generally gives better results. That is debatable. After spending much of my life in a managerial role of one kind or another, I have determined that you either have to kick them in the ass, insult them or threaten them before they actually accomplish anything. Look, we are all doing the best we can with what we've got. The ports people have been trying to accomplish the equivalent of turning a cruise ship around in a bathtub without rattling the silverware. It's not possible to anticipate every issue, particularly when there are so many. Absolutely true. The real trick is where do you find a bathtub that large? The way improvements are made is for interested people (that is, you) to get involved and help to improve it. Adding more generals doesn't improve the battle plan. The challenge you have created is to anticipate the next issue and report it, preferably with a plan for a solution, before it happens. Really ... Hi, I am a FreeBSD user, and I would like to report a problem that doesn't exist. I have a theoretical solution for this unknown problem, but I cannot test it because I cannot create the environment. Seriously, there are plenty of real problems. Attempting to anticipate theoretical ones and then devise hypothetical solutions is a job best left to those working on quantum physics. -- Jerry ___ 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: print/cups-base web interface broken unable to print
In all fairness, I have often found this type of strange error to be a culmination of several different problems getting rolled into one symptom. * I was trying to print a pdf with two-pages on one A4 paper, when I realized the problem. * When I could not print on my FreeBSD system, I copied the pdf files to an old linux laptop and tried printing from there. Surprise! evince was unable to display the pdf file (some error I can't do this). * I went back to my FreeBSD PC and noticed that evince fails to show the pdf in proper format, but shows some (not all) pages upside-down. * I opened Okular, saved the pdf files with a new name and copied those files to the old linux laptop. I opened the okular transformed files with evince; no problems, and printed the files exactly as I wanted to. What the hell does this all mean? I have no idea! But, * I am merging gnome3 (marcusom) ports into my tree, so there's the first clue. * I tried printing a PDF file from Okular (KDE related, not Gnome) from the FreeBSD OS but failed for the same reason, and that's a second clue. * I wonder if ghostscript + Gnome3 merging has any relation to the problem? * As reminder, LPT printing to HP2100 is working (have not setup filters for LPT yet) for text files only. That's all I've got for now... - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/print-cups-base-web-interface-broken-unable-to-print-tp5918098p5918572.html Sent from the freebsd-ports mailing list archive at Nabble.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
[QAT] 356395: 4x leftovers
- STAGEDIR support. - Simplify PORT_OPTIONS handling. - Fix pkg-plist and remove extra mktexlsr(1). - Fix pkg-message. - Build ID: 20140603193400-6327 Job owner: h...@freebsd.org Buildtime: 3 days Enddate: Fri, 06 Jun 2014 18:16:57 GMT Revision: 356395 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=356395 - Port:print/auctex 11.87_2 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~h...@freebsd.org/20140603193400-6327-346350/auctex-emacs24-11.87_2.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~h...@freebsd.org/20140603193400-6327-346351/auctex-emacs24-11.87_2.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~h...@freebsd.org/20140603193400-6327-346352/auctex-emacs24-11.87_2.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~h...@freebsd.org/20140603193400-6327-346353/auctex-emacs24-11.87_2.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140603193400-6327 redports https://qat.redports.org/ ___ 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: libiconv problems
--On June 6, 2014 at 12:46:09 PM -0500 Bryan Drewery bdrew...@freebsd.org wrote: On 6/6/14, 12:25 PM, Paul Schmehl wrote: According to UPDATING, I should be able to do this to resolve issues with libiconv: pkg query %ro libiconv ports_to_update On my system, running 8.4 RELEASE with the old packaging system, this command doesn't do anything. I ran pkg_info to get a list of dependent apps and then piped that into xargs portmaster, but I got errors. # cat dependencies.txt | xargs portmaster === /var/db/pkg/Information does not exist === Aborting update === Killing background jobs Terminated Terminated Terminated Terminated Terminated Terminated Terminated Terminated Terminated Terminated Terminated === Exiting So how can I fix this problem without updating to the new pkg system? You don't. UPDATING says: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv 8.4 not affected, according to the entry. All well and good, except for one problem: ls /usr/ports/devel/libiconv* ls: /usr/ports/devel/libiconv*: No such file or directory And yes my ports are current. -- Paul Schmehl (pa...@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/infosecurity/ ___ 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: libiconv problems
On 6/6/14, 1:18 PM, Paul Schmehl wrote: --On June 6, 2014 at 12:46:09 PM -0500 Bryan Drewery bdrew...@freebsd.org wrote: On 6/6/14, 12:25 PM, Paul Schmehl wrote: According to UPDATING, I should be able to do this to resolve issues with libiconv: pkg query %ro libiconv ports_to_update On my system, running 8.4 RELEASE with the old packaging system, this command doesn't do anything. I ran pkg_info to get a list of dependent apps and then piped that into xargs portmaster, but I got errors. # cat dependencies.txt | xargs portmaster === /var/db/pkg/Information does not exist === Aborting update === Killing background jobs Terminated Terminated Terminated Terminated Terminated Terminated Terminated Terminated Terminated Terminated Terminated === Exiting So how can I fix this problem without updating to the new pkg system? You don't. UPDATING says: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv 8.4 not affected, according to the entry. All well and good, except for one problem: ls /usr/ports/devel/libiconv* ls: /usr/ports/devel/libiconv*: No such file or directory And yes my ports are current. It's a typo, should say converters/libiconv. I've fixed it. -- Regards, Bryan Drewery ___ 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: Who was the mental genius
On Jun 6, 2014, at 10:02 AM, Warren Block wbl...@wonkity.com wrote: On Fri, 6 Jun 2014, Paul Schmehl wrote: No offense was meant. I deliberately chose the subject to stimulate discussion, which it has obviously done. Stimulating discussion without insulting people generally gives better results. Look, we are all doing the best we can with what we've got. The ports people have been trying to accomplish the equivalent of turning a cruise ship around in a bathtub without rattling the silverware. It's not possible to anticipate every issue, particularly when there are so many. The way improvements are made is for interested people (that is, you) to get involved and help to improve it. The challenge you have created is to anticipate the next issue and report it, preferably with a plan for a solution, before it happens. Let's not overly tone police folks. If no one can constructively criticize then we don't get any feedback. Anyone's tone can be attacked I firmly believe that Paul's tone matches the way we east coasters chide each other to provoke debate. ___ 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: To all port maintainers: libtool
On Fri, 06 Jun 2014 09:54:37 -0500 Bryan Drewery wrote: On 6/6/14, 9:27 AM, Tijl Coosemans wrote: On Fri, 06 Jun 2014 15:02:24 +0200 Alexander Leidinger wrote: Quoting Tijl Coosemans t...@freebsd.org (from Thu, 5 Jun 2014 18:53:03 +0200): On Thu, 05 Jun 2014 09:39:21 -0500 Bryan Drewery wrote: I don't know what .la files are used for and have no time currently to research it. What is the impact to non-ports consumers of removing .la files? Do they also need patches to make them build? Removing a .la file is somewhat like a library version bump. Anything that depends on it needs to be recompiled. I remember from tests way in the past that not all programs will be happy when the .la files are not there. I remember that I once tried to remove the .la files but it didn't work as the program wanted to open the .la files (after recompile). Maybe libltdl is openening them? Did you make some checks/tests in this regard? Essentially .la files are small shell scripts that set some variables so in theory they can be used in all kinds of places, but this seems of little practical value. Libltdl can open and parse .la files (to find the name of the .so file it can dlopen) but it can also work directly with .so files. If a program uses .la files directly then the port can't delete them of course, but so far I haven't encountered such programs. My main question was non-ports consumers though. What is the impact on them? We're talking a lot about bumping revisions and forcing rebuilds. Will non-ports consumers require rebuild or changes if .la files are missing? If they have a .la file that links to the .la file that went missing then their .la file needs to be rebuilt. Like I said before, this is very similar to .so version bumps. If they have a program (or library) that links to another library that goes from .so.X to .so.(X+1) then their program (or library) needs to be rebuilt too. This is nothing out of the ordinary. If you update a dependency that exists in the ports tree you might have to rebuild stuff that exists outside the tree. This is something you always have to keep in mind. Would these non-ports consumers be able to properly build and link without .la files and without modifications? These .la files seem similar to .pc files which are often critical to out-of-tree consumers that assume Linux /usr paths instead of /usr/local paths. You specifically asked about the impact of the removal of .la files so I restricted my answer to just that, but now I suspect you really want to know about all impacts of USES=libtool. So here it goes. A .la file operates one level below a .pc file so to speak. A libfoo.pc file gives you information about a libfoo package (what compiler and linker flags to use to link with libfoo), while a libfoo.la file will give you information about the dependencies of libfoo. Currently all forms of USES=libtool erase this dependency information or erase the .la file altogether. Suppose you have a program (or library) X outside the ports tree which links to libfoo inside the tree which in turn links to libbar. The command to link X looks roughly like this: libtool --mode=link cc -o X X1.o X2.o -L/usr/local/lib -lfoo Without USES=libtool in the libfoo port, the libtool script will turn that cc command into cc -o X X1.o X2.o -L/usr/local/lib -lfoo -lbar and the resulting binary X will link to both libfoo.so and libbar.so. If X is a library, libtool will also generate X.la which lists libfoo.la and libbar.la as dependencies. Note that these dependencies accumulate. A binary Y that links to library X ends up linking to X.so, libfoo.so and libbar.so. That's what we want to get rid of. With USES=libtool (any form) in the libfoo port, there's no dependency information in libfoo.la so the above libtool command does not add -lbar to the cc command line. X only links with libfoo.so and X.la only lists libfoo.la as a dependency (if it exists, otherwise just -lfoo). This may fail if X uses libbar API directly. The modification you have to make then is to add libbar as a dependency of X in your makefile. USES=libtool exposes these kinds of hidden dependencies. It forces direct dependencies to be listed explicitly. So far the case of libfoo being a shared library. Things may break if it's a static library. If a program X uses functions from a file in the static libfoo.a archive and that file requires functions from libbar then you must also specify -lbar on the command line so it was very convenient for libtool to add -lbar automatically. With USES=libtool (any form) in the libfoo port you must now add libbar as a dependency of X in your makefile even if X doesn't use libbar API directly. We may always revisit this of course but at the time of the creation of USES=libtool this was considered an acceptable loss for the following reasons: 1) Static linking with libtool outside the ports tree is assumed to be used rarely and if it's
Re: Who was the mental genius
Hello, On 6/6/14, 2:24 PM, Alfred Perlstein wrote: On Jun 6, 2014, at 10:02 AM, Warren Block wbl...@wonkity.com wrote: On Fri, 6 Jun 2014, Paul Schmehl wrote: No offense was meant. I deliberately chose the subject to stimulate discussion, which it has obviously done. Stimulating discussion without insulting people generally gives better results. Look, we are all doing the best we can with what we've got. The ports people have been trying to accomplish the equivalent of turning a cruise ship around in a bathtub without rattling the silverware. It's not possible to anticipate every issue, particularly when there are so many. The way improvements are made is for interested people (that is, you) to get involved and help to improve it. The challenge you have created is to anticipate the next issue and report it, preferably with a plan for a solution, before it happens. Let's not overly tone police folks. If no one can constructively criticize then we don't get any feedback. Anyone's tone can be attacked I firmly believe that Paul's tone matches the way we east coasters chide each other to provoke debate. Not to get too far off topic but as a life long east coaster (except for a short sojourn in the flatlands of Kansas), and being old enough to know better, that is not normal east coast chiding. Maybe that's normal northeast talk, but here in the south people have manners. Having said that, this is what I infer from the situation. With all due respect Paul, you have said you are 18 months from retirement. Most folks are kinda coasting by that point. I'm guessing that's why you were running your servers on a no longer supported version of FreeBSD. Unfortunately, no longer supported *really* meant no longer supported in this case, and you got bit, and got angry. Sadly, you have no one to blame but yourself, since this was in fact well documented. If I was not a polite southerner, perhaps I'd ask who was the mental genius that expected to run an unsupported OS for the next 18 months? But I'm too polite to ask. -- Jim Ohlstein Never argue with a fool, onlookers may not be able to tell the difference. - Mark Twain ___ 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
[QAT] 356449: 4x fail
Convert to USES=pgsql - Build ID: 20140604092000-6650 Job owner: b...@freebsd.org Buildtime: 2 days Enddate: Fri, 06 Jun 2014 20:41:13 GMT Revision: 356449 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=356449 - Port:databases/postgis21 2.1.0_3 Buildgroup: 8.4-QAT/amd64 Buildstatus: FAIL Buildgroup: 8.4-QAT/i386 Buildstatus: FAIL Buildgroup: 9.2-QAT/amd64 Buildstatus: FAIL Buildgroup: 9.2-QAT/i386 Buildstatus: FAIL -- Buildarchive URL: https://qat.redports.org/buildarchive/20140604092000-6650 redports https://qat.redports.org/ ___ 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: Firefox chokes up for several seconds... frequently
On 2014-06-04, Chris Whitehouse cwhi...@onetel.com wrote: I have experienced firefox and/or xorg apparently freezing for several seconds which seems to be due to loading a page with a large image. That's a well-known problem. It can be worked around by setting MOZ_DISABLE_IMAGE_OPTIMIZE=1 in the environment before starting firefox. This is on 10.0-RELEASE, firefox-27.0.1,1, xorg-7.7. It isn't even specific to FreeBSD. Mark Kettenis (OpenBSD) analyzed the underlying problem, but I can't remember where he posted it. Here's a related comment by him: http://lists.x.org/archives/xorg-devel/2014-March/041541.html -- Christian naddy Weisgerber na...@mips.inka.de ___ 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
[QAT] 356500: 4x fail, 4x compiler_error, 16x success
These ports are no longer used or cared for. Dave Shar koalative at gmail.com wishes to maintain these ports with my help. deskutils/py-send2trash - Change Makefile header, use my name and @FreeBSD.org email - Pass maintainership to koalative at gmail.com - Change license BSD to BSD3CLAUSE - Use USE_PYDISTUTILS=yes instead of easy_install - Remove PYDISTUTILS_PKGNAME and add PYDISTUTILS_AUTOPLIST graphics/founts - Change Makefile header, use my name and @FreeBSD.org email - Pass maintainership to koalative at gmail.com - Add REINPLACE, fix ELAST - Change distinfo, remove supplied icon graphics/py-pyggel - Pass maintainership to koalative at gmail.com graphics/radius-engine - Change Makefile header, use my name and @FreeBSD.org email - Pass maintainership to koalative at gmail.com irc/py-fishcrypt - Pass maintainership to koalative at gmail.com sysutils/gigolo - Change Makefile header, use my name and @FreeBSD.org email - Pass maintainership to koalative at gmail.com - Use tar:bzip2 instead of USE_BZIP2=yes - Remove TODO from DOCS - Remove useless .include bsd.port.options.mk - Change pkg-plist, remove mtree - Build ID: 20140604141600-15538 Job owner: nemy...@freebsd.org Buildtime: 2 days Enddate: Fri, 06 Jun 2014 23:32:24 GMT Revision: 356500 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=356500 - Port:deskutils/py-send2trash 1.3.0 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~nemy...@freebsd.org/20140604141600-15538-346930/py27-send2trash-1.3.0.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~nemy...@freebsd.org/20140604141600-15538-346931/py27-send2trash-1.3.0.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~nemy...@freebsd.org/20140604141600-15538-346932/py27-send2trash-1.3.0.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~nemy...@freebsd.org/20140604141600-15538-346933/py27-send2trash-1.3.0.log - Port:graphics/founts 13 Buildgroup: 8.4-QAT/amd64 Buildstatus: COMPILER_ERROR Log: https://qat.redports.org//~nemy...@freebsd.org/20140604141600-15538-346934/founts-13.log Buildgroup: 8.4-QAT/i386 Buildstatus: COMPILER_ERROR Log: https://qat.redports.org//~nemy...@freebsd.org/20140604141600-15538-346935/founts-13.log Buildgroup: 9.2-QAT/amd64 Buildstatus: COMPILER_ERROR Log: https://qat.redports.org//~nemy...@freebsd.org/20140604141600-15538-346936/founts-13.log Buildgroup: 9.2-QAT/i386 Buildstatus: COMPILER_ERROR Log: https://qat.redports.org//~nemy...@freebsd.org/20140604141600-15538-346937/founts-13.log - Port:graphics/py-pyggel 0.08 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~nemy...@freebsd.org/20140604141600-15538-346938/py27-pyggel-0.08.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~nemy...@freebsd.org/20140604141600-15538-346939/py27-pyggel-0.08.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~nemy...@freebsd.org/20140604141600-15538-346940/py27-pyggel-0.08.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~nemy...@freebsd.org/20140604141600-15538-346941/py27-pyggel-0.08.log - Port:graphics/radius-engine 1.1_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: FAIL Buildgroup: 8.4-QAT/i386 Buildstatus: FAIL Buildgroup: 9.2-QAT/amd64 Buildstatus: FAIL Buildgroup: 9.2-QAT/i386 Buildstatus: FAIL - Port:irc/py-fishcrypt 4.21 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~nemy...@freebsd.org/20140604141600-15538-346946/py-fishcrypt-4.21.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~nemy...@freebsd.org/20140604141600-15538-346947/py-fishcrypt-4.21.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~nemy...@freebsd.org/20140604141600-15538-346948/py-fishcrypt-4.21.log Buildgroup: 9.2-QAT/i386
env: NO_PIE: No such file or directory
I'm seeing this after updating my ports tree (to r356864): . . === Building for openjdk6-b31_3,1 env: NO_PIE: No such file or directory . . Commenting out the recent MAKE_ENV+=NO_PIE in bsd.port.mk got me going forward. Maybe it should be MAKE_ENV+=NO_PIE=yes although I didn't find a reference to this knob anywhere yet in order to confirm that. ___ 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
ghostscript8-nox11 installation failed: CIDFont: Cannot stat: No such file or directory
Hi, I tried to install ghostscript8-nox11 on freshly installed FreeBSD 8.4, but it ends with following error: tar: /usr/local/share/ghostscript/8.71/Resource/CIDFont: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 The installation failed in staging phase. I found out, that there are missing directories which are not created by any port before, but are targeted by symlinks from stage dir: # ls -l /usr/ports/print/ghostscript8-nox11/work/stage/usr/local/share/ghostscript/8.71/Resource/ total 18 lrwxr-xr-x 1 root wheel30 Jun 6 18:11 CIDFont - /usr/local/share/fonts/CIDFont drwxr-xr-x 2 root wheel 5632 Jun 6 18:11 CMap drwxr-xr-x 2 root wheel 512 Jun 6 18:11 ColorSpace drwxr-xr-x 2 root wheel 512 Jun 6 18:11 Decoding drwxr-xr-x 2 root wheel 512 Jun 6 18:11 Encoding drwxr-xr-x 2 root wheel 1536 Jun 6 18:11 Font drwxr-xr-x 2 root wheel 1536 Jun 6 18:11 Init drwxr-xr-x 2 root wheel 512 Jun 6 18:11 SubstCID # ls -l /usr/local/share/fonts/CIDFont ls: /usr/local/share/fonts/CIDFont: No such file or directory # ls -l /usr/local/share/ghostscript/8.71/Resource/CIDFont/ ls: /usr/local/share/ghostscript/8.71/Resource/CIDFont/: No such file or directory After I created those directories manually, installation went fine. # mkdir -p /usr/local/share/fonts/CIDFont # mkdir -p /usr/local/share/ghostscript/8.71/Resource/CIDFont ghostscript8-nox11/# make package === Building package for ghostscript8-nox11-8.71_15 Creating package /usr/ports/print/ghostscript8-nox11/work/pkg/ghostscript8-nox11-8.71_15.tbz Registering depends: libiconv-1.14_3 jasper-1.900.1_14 jbig2dec-0.11_1 tiff-4.0.3_2 jpeg-8_5 png-1.5.18 freetype2-2.5.3_2 gsfonts-8.11_6 libpaper-1.1.24_1 expat-2.1.0. Registering conflicts: gambc-[0-9]* ghostscript[79]-[0-9]* ghostscript[79]-nox11-[0-9]* ghostscript9-agpl-[0-9]* ghostscript9-agpl-nox11-[0-9]* ghostscript8-[0-9]*. Creating bzip'd tar ball in '/usr/ports/print/ghostscript8-nox11/work/pkg/ghostscript8-nox11-8.71_15.tbz' tar: Removing leading '/' from member names Usr: 9.714s Krnl: 0.270s Totl: 0:09.95s CPU: 100.3% swppd: 0 I/O: 0+88 I don't know where and how it should be fixed. -- S pozdravem Miroslav Lachman PS: details about system after successful installation of Ghostscript and ImageMagick # uname -srmi FreeBSD 8.4-RELEASE-p11 amd64 GENERIC # pkg_info -E \* ImageMagick-nox11-6.8.0.7_9,1 adns-1.4_1 ap22-mod_bw-0.8_1 ap22-mod_proctitle-0.4.1 apache22-2.2.27_2 apachetop-0.12.6_4 apr-1.5.1.1.5.3 autoconf-2.69 autoconf-wrapper-20131203 automake-1.14 automake-wrapper-20131203 awstats-7.3,1 bash-4.3.18_2 bison-2.7.1,1 bsdstats-5.5_5 ca_root_nss-3.16 catdoc-0.94.2_2 cclient-2007f_1,1 ccze-0.2.1_4 cmake-2.8.12.1_4 cmake-modules-2.8.12.1_1 curl-7.37.0 db5-5.3.28 dialog4ports-0.1.5_2 dmidecode-2.12 easy-rsa-2.2.0.m en-freebsd-doc-41380_1,1 expat-2.1.0 fastresolve-2.10_4 fontconfig-2.11.0_3,1 freetds-msdblib-0.64_10,1 freetype2-2.5.3_2 gawk-4.1.1 ghostscript8-nox11-8.71_15 gmake-3.82_1 gsfonts-8.11_6 heirloom-mailx-12.4_3 help2man-1.43.3_1 ifstat-1.1_5 iftop-0.17 innotop-1.9.1 jasper-1.900.1_14 jbig2dec-0.11_1 jbigkit-1.6 jpeg-8_5 jpegoptim-1.4.1 libevent-1.4.14b_3 libevent2-2.0.21_1 libexecinfo-1.1_3 libgd-2.1.0_3,1 libiconv-1.14_3 libltdl-2.4.2_3 libmcrypt-2.5.8 libmemcached-1.0.7_2 libpaper-1.1.24_1 libsigsegv-2.10 libtool-2.4.2_3 libxml2-2.9.1_1 libxslt-1.1.28_3 lighttpd-1.4.35_2 lzo2-2.06_3 m4-1.4.17_1,1 mariadb55-client-5.5.37_1 mariadb55-server-5.5.37 mc-light-4.1.40.p9_9 memcached-1.4.17_2 mhash-0.9.9.9_1 mrtg-2.17.4_4,1 mytop-1.6_11 oniguruma4-4.7.1 openvpn-2.3.4 p5-BerkeleyDB-0.54 p5-DBD-mysql-4.027 p5-DBI-1.631 p5-Net-XWhois-0.90_4 p5-SNMP_Session-1.13_2 p5-Term-ReadKey-2.32 p5-URI-1.60 patch-2.7.1 pcre-8.34_1 pear-1.9.4_3 pear-Net_DNS-1.0.7_1 pear-Net_IDNA-0.8.1 pear-OLE-1.0.0.r2 pear-Spreadsheet_Excel_Writer-0.9.3 pecl-dbase-5.1.0 pecl-memcached-2.2.0_1 perl5-5.16.3_10 pftop-0.7_2 phantomjs-1.9.2_3 php53-5.3.28_2 php53-bz2-5.3.28_2 php53-calendar-5.3.28_2 php53-ctype-5.3.28_2 php53-curl-5.3.28_2 php53-dom-5.3.28_2 php53-exif-5.3.28_2 php53-extensions-1.6 php53-fileinfo-5.3.28_2 php53-ftp-5.3.28_2 php53-gd-5.3.28_2 php53-hash-5.3.28_2 php53-iconv-5.3.28_1 php53-imap-5.3.28_2 php53-json-5.3.28_2 php53-mbstring-5.3.28_2 php53-mcrypt-5.3.28_2 php53-mssql-5.3.28_2 php53-mysql-5.3.28_2 php53-mysqli-5.3.28_2 php53-openssl-5.3.28_2 php53-pdo-5.3.28_2 php53-pdo_mysql-5.3.28_2 php53-posix-5.3.28_2 php53-session-5.3.28_2 php53-simplexml-5.3.28_2 php53-soap-5.3.28_2 php53-sockets-5.3.28_2 php53-sqlite-5.3.28_2 php53-tokenizer-5.3.28_2 php53-xml-5.3.28_2 php53-xmlreader-5.3.28_2 php53-xmlwriter-5.3.28_2 php53-xsl-5.3.28_2 php53-zip-5.3.28_2 php53-zlib-5.3.28_2 pkg_tree-1.1_2 pkgconf-0.9.5 png-1.5.18 portaudit-0.6.2 portmaster-3.17.5 proftpd-1.3.5_2 proftpd-mod_sql_mysql-1.3.5_2 pstree-2.36 rsync-3.1.0_3 screen-4.2.1_1 sphinxsearch-2.1.8
Re: env: NO_PIE: No such file or directory
On Fri, Jun 06, 2014 at 05:25:58PM -0600, John Hein wrote: I'm seeing this after updating my ports tree (to r356864): . . === Building for openjdk6-b31_3,1 env: NO_PIE: No such file or directory . . Commenting out the recent MAKE_ENV+=NO_PIE in bsd.port.mk got me going forward. Maybe it should be MAKE_ENV+=NO_PIE=yes although I didn't find a reference to this knob anywhere yet in order to confirm that. A fix has been committed, sorry about that regards, Bapt pgpWLXvhE72fG.pgp Description: PGP signature
Re: env: NO_PIE: No such file or directory
On 2014-06-06 19:30, Baptiste Daroussin wrote: On Fri, Jun 06, 2014 at 05:25:58PM -0600, John Hein wrote: I'm seeing this after updating my ports tree (to r356864): . . === Building for openjdk6-b31_3,1 env: NO_PIE: No such file or directory . . Commenting out the recent MAKE_ENV+=NO_PIE in bsd.port.mk got me going forward. Maybe it should be MAKE_ENV+=NO_PIE=yes although I didn't find a reference to this knob anywhere yet in order to confirm that. A fix has been committed, sorry about that regards, Bapt Sorry! -- Regards, Bryan Drewery ___ 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: Who was the mental genius
On Fri, Jun 06, 2014 at 04:10:03PM -0400, Jim Ohlstein wrote: Not to get too far off topic but as a life long east coaster (except for a short sojourn in the flatlands of Kansas), and being old enough to know better, that is not normal east coast chiding. Maybe that's normal northeast talk, but here in the south people have manners. I was going to say something along these same lines ... but to me this message, as well, comes off a bit harsh. I understand Paul's point even if I found the initial tone abrasive. But I know a lot of context is lost when conversations are down-converted to keystrokes. Perhaps Paul can understand why, for a native southerner, seeing that kind of Subject: line can be demotivating, especially in the light of how hard it has been in the past to make such large changes to the infrastructure. Please remember folks: one person's blowing off steam can lead to another person's why do I bother trying to fix things anyways. mcl ___ 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
Integrating with pkg
I'm looking to port a utility from Ubuntu, and need to know what hooks there are in pkg. I want to port etckeeper, a tool that automates version control for /etc (and in our case $PREFIX/etc). Its current implementation uses hooks in apt to automatically check in changes when a package is installed/updated; I'm wondering what I can do to support that functionality (checking in changes when a package or the base system is installed/updated) in FreeBSD. Thanks, Jim Trigg ___ 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: Who was the mental genius
On 6/6/14, 7:52 PM, Mark Linimon wrote: On Fri, Jun 06, 2014 at 04:10:03PM -0400, Jim Ohlstein wrote: Not to get too far off topic but as a life long east coaster (except for a short sojourn in the flatlands of Kansas), and being old enough to know better, that is not normal east coast chiding. Maybe that's normal northeast talk, but here in the south people have manners. I was going to say something along these same lines ... but to me this message, as well, comes off a bit harsh. I understand Paul's point even if I found the initial tone abrasive. But I know a lot of context is lost when conversations are down-converted to keystrokes. Perhaps Paul can understand why, for a native southerner, seeing that kind of Subject: line can be demotivating, especially in the light of how hard it has been in the past to make such large changes to the infrastructure. Please remember folks: one person's blowing off steam can lead to another person's why do I bother trying to fix things anyways. Agreed. I would like to raise one other point. For every brash new yorker (like myself) that blows off steam, there are likely very many people who just don't complain and remain silent on issues like usability. It important to be able to take the feedback apart from the obvious frustration. We are after all a software project, we want users. Another point is that it's obvious that Paul is passionate about FreeBSD, he is a long long long time user. In addition he took the time to let us know what broke, he took the time to comment on usability, and it's obvious he's a huge fan of FreeBSD and that it was personally upsetting that he saw a usability issue that he felt would hurt the OS. It's very obvious that Paul has a lot of love for FreeBSD otherwise he would have just shrugged and installed $penguin_os. I like Paul. I also like Bapt, I hope both can be OK and the passion and love of the OS can come out of this as opposed to the negatives mentioned earlier in the thread. -Alfred ___ 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
