Re: Crashing chromium/iridium
j...@chen.org.nz (Jonathan Chen) writes:
>On 7 October 2017 at 08:39, Grzegorz Junka <li...@gjunka.com> wrote:
>> Just wanted to check if anybody else observed this annoying behaviour in
>> Chromium/Iridium browsers. Randomly, in about 10-40% of cases, the new tab
>> hangs loading for 30-60 seconds, after which time the browser shows a dialog
>> that the webpage doesn't load and I can either kill or wait.
>This bug has been around for a very long time:
>https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212812
>There was some anecdotal evidence that it was related to code-caching,
>with a possible workaround, but no fixes for it have been committed.
>The workarounds do not appear to work anymore with the latest updates,
>though.
The following applies to FreeBSD 11-stable.
I did not experience the issue with 51.0.2704.84, but have seen it
since chrome 59.0.3071.115. I also tried 60.0.3112.101 and 61.0.3163.100
(more recent versions of the www/chromium port) with no improvement.
Might be an independent bug, but I am also getting a "file not found"
error when I click on "options" for the three different plugins I was
using ("ublock origin", "tabs outliner", and "go back with backspace").
This broken behavior could be fixed temporarily by deleting and then
reinstalling the plugin, but after a day or so it would return.
I found that I could recover from the "some tabs hanging forever" state by:
1. Quit chrome browser
2. Delete cache in ~/.cache/chromium or wherever (I am using
--user-data-dir=/my/homedir/.config/chrome-myhostname, and
it appears to affect the path in ~/.cache as well)
3. Delete user data dir (in my case, /my/homedir/.config/chrome-myhostname)
4. Restore Bookmarks file (I copy it via cron every day)
5. Reinstall "ublock origin". I abandoned the other two plugins
because T.O. couldn't access its configuration and the backspace
plugin stopped working (grr)
That is a drastic approach because all configuration and state is
lost, but it did seem to overcome the hanging tab problem. It makes
me think that there is some persistent state in chrome's user directory
that is related to this issue.
I tried building www/chromium 61 with DEBUG, but the build failed, and I
have not pursued it further.
--
G. Paul Ziemba
FreeBSD unix:
1:41PM up 9 days, 23:29, 14 users, load averages: 0.38, 0.35, 0.29
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
SIGSEGV due to different options for amanda-server and amanda-client
e9d0800 ^... 2950b0 819d0800 cb9d0800 2950c0 049e0800 4b9e0800 K... 2950d0 889e0800 bd9e0800 2950e0 fb9e0800 189f0800 2950f0 Contents of section .dynamic: 2950f8 0100 6331 c1.. 295108 0100 7231 r1.. 295118 0100 7c31 0000 ....|1.. Note that version_info size here is 0xd8 = 216 decimal. -- G. Paul Ziemba FreeBSD unix: 9:31PM up 1 day, 11:57, 9 users, load averages: 1.13, 1.21, 1.28 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: suggested patch for bsd.ports.mk
jul...@freebsd.org (Julian Elischer) writes: >Sometime ago I proposed the following change. >I got several "yes please" from members of the public, >but no actionable response from members of the ports group >So I am asking again. >> +# EXTRA_PATCH_TREE - where to find extra 'out-of-tree' patches >> +# Points to a directory hierarchy with the same >> layout >> +# as the ports tree, where local patches can be >> found. >> +# This allows a third party to keep their patches in >> +# some other source control system if needed. > [...] Thank you for raising this question. I may have given one of the above-mentioned "yes" responses, and am still enthusiastically in favor of this patch. We have been discussing it for at least the last eight years (CF the thread started at <http://docs.FreeBSD.org/cgi/mid.cgi?gh1l3n$22rv$1> on Dec 1, 2008, which references this very patch from Dmitry Marakasov). I have used it in my (admittedly very small) network since then, first for building ports in situ and more recently with poudriere. It's been invaluable in helping me manage site-local changes. -- G. Paul Ziemba FreeBSD unix: 10:11AM up 135 days, 13:50, 17 users, load averages: 0.42, 0.28, 0.25 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: patch to bsd.ports.mk to support out-of-tree patches.
m...@freebsd.org (Marcus von Appen) writes:
Julian Elischer jul...@freebsd.org:
[...]
esac | ${PATCH} ${PATCH_DIST_ARGS} `patch_dist_strip $$i` ; \
done )
.endif
+.if defined(EXTRA_PATCH_TREE)
[...]
+.endif
.if defined(EXTRA_PATCHES)
@set -e ; \
for i in ${EXTRA_PATCHES}; do \
Nice. I'd however change the patch behaviour to the following:
- patch-* from FreeBSD
- EXTRA_PATCHES from FreeBSD
- local patches
Your patch looks like it appleis the out-of-tree patches prior
to any EXTRA_PATCHES defined by the port itself. This should not be
the case, in my opinion. Locally managed patches should always come
last to ensure that all FreeBSD/maintainer-specific bits have been
applied and the local changes are just added on top of those.
Julian and others, I am wholly in favor of this capability. I have
been using a similar bsd.port.mk patch for some years based on
the discussions in this thread:
http://lists.freebsd.org/pipermail/freebsd-ports/2008-December/051767.html
I also agree with Marcus above regarding the order of application of patches.
Looking forward to its inclusion in the ports tree.
--
G. Paul Ziemba
FreeBSD unix:
1:16PM up 13 days, 12:51, 5 users, load averages: 1.36, 1.08, 0.97
___
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
whither linux-f10-expat and friends?
In the last few months, several linux-f10 application ports have been marked forbidden due to security issues, for example, textproc/linux-f10-expat. This blocks builds of, among other things, www/opera-linuxplugins. I appreciate the vigilance and attentiveness to security, but I'm not sure where that leaves us users of the emulated linux environment (maybe I missed an announcement - searches via the big G didn't turn up anything). Is anyone working on updating the recently-forbidden linux-f10-* applications so they can be used again? Is there some alternate method we should use instead of the linux-f10-* ports? thanks, ~!paul -- G. Paul Ziemba FreeBSD unix: 9:41AM up 4 days, 1:21, 10 users, load averages: 1.32, 1.29, 1.30 ___ 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: zoneminder staging patches in the works
I wrote: I'm happy to say that I have made good progress on stagifying this port and hope to submit patches in the next day or two. I'm working with the existing version (1.25.0) because I want to get the staging support added ASAP. Patch submitted with bugzilla entry 192123 [patch] multimedia/zoneminder: Enable STAGE support -- G. Paul Ziemba FreeBSD unix: 4:16PM up 12 days, 4:45, 13 users, load averages: 1.26, 1.31, 1.44 ___ 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
zoneminder staging patches in the works
I haven't seen any activity on the zoneminder port recently, and I think I saw that it was slated for removal in a week because it had not been modified to supoprt staging. I'm happy to say that I have made good progress on stagifying this port and hope to submit patches in the next day or two. I'm working with the existing version (1.25.0) because I want to get the staging support added ASAP. -- G. Paul Ziemba FreeBSD unix: 10:16AM up 10 days, 22:45, 16 users, load averages: 1.46, 1.43, 1.37 ___ 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: poudriere and local patches to ports
d...@langille.org (Dan Langille) writes:
I have a local patch =
(https://dan.langille.org/wp-content/uploads/2014/04/nagios-default-commen=
t-cmd-cgi.c.diff_.txt) which I wish to apply to net-mgmt/nagios before =
it is compiled by poudriere).
I have looked at ports-mgmt/portshaker but that seems to be related to =
merging rather than patching.
Any suggestions?
Disclaimer: I set up my poudriere environment almost a year ago,
so there could be new poudriere features to address this issue
that I'm not aware of.
I maintain a tree of local patches matching the structure of the
ports tree (e.g., ./category/port-name/patch-files...). This
is not critical but just helps me keep track of things.
In the /usr/local/etc/poudriere.d/*-make.conf files, I call out
local patches this way:
LOCALPATCHDIR=/usr/ports/LocalPatches
.if ${.CURDIR:M*/graphics/xpdf}
EXTRA_PATCHES=${LOCALPATCHDIR}/graphics/xpdf/patch-xpdf-3.03-rotate-cmd
.endif
[Aside: I'm not completely happy with using EXTRA_PATCHES because
sometimes it collides with use by the port itself. I wish there
were an additional LOCAL_PATCHES feature in the ports makefiles
specifically for this purpose, but EXTRA_PATCHES is adequate for
me at the moment. I haven't studied that issue in a couple of years,
so maybe there is a new ports feature addressing it.]
Before I run poudriere bulk, I rsync my local patch tree to the
ports tree that will be used by poudriere so that it shows up at
/usr/ports/LocalPatches in the jail.
--
G. Paul Ziemba
FreeBSD unix:
11:01AM up 136 days, 12 hrs, 22 users, load averages: 1.45, 1.34, 1.37
___
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
thinkingrock installs xdg-open, conflicts with xdg-utils port
I'm migrating to pkgng, so maybe there is now more rigorous checking
for conflicts between files installed by different ports which didn't
occur previously. pkg2ng complained about the conflict and refused to
register xdg-utils because of conflicts with thinkingrock.
I currently have deskutils/thinkingrock and devel/xdg-utils installed.
These ports both install /usr/local/bin/xdg-{email,open}, and they
seem to be identical versions of the files.
As many ports depend on devel/xdg-utils, it seems to me that the
correct approach would be to patch the thinkingrock port to:
1. not install its own xdg-{email,open}; and
2. add a dependency on devel/xdg-utils
Another possibility might be to have thinkingrock install
its xdg-{email,open} as tr-xdg-{email,open} but I have not
looked at the port enough to know if it is possible to change
TR to call the new names.
I'll try to work up a patch for the first approach and submit
a PR, pending any followups to this message.
--
G. Paul Ziemba
FreeBSD unix:
3:01PM up 143 days, 2:19, 1 user, load averages: 1.15, 0.97, 0.87
___
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 3.13.13 real endless loop Waiting on fetch checksum..
I think my original reply did not go out on 8/27, so here it is: do...@freebsd.org (Doug Barton) writes: On 08/25/2012 16:58, G. Paul Ziemba wrote: The second scenario exhibits the problem. Here, I delete the distfile and just run portmaster without -F. The fetch completes, but portmaster does not seem to notice. Can you try that second test again, and add -D to the command line? The good news is that I removed the distfile and than ran portmaster -D devel/gsoap, and it worked. The bad news is that I killed it before it installed, went back and deleted the distfile again and deleted devel/gsoap/work and ran just portmaster devel/gsoap, and that also worked. I must have done something in the meantime that caused it to work. I didn't do anything with that specific port, and portmaster lists it as a root port, so I'm not sure what would have made a difference. I was monkeying aroung with libpng and some other ports, but didn't keep an exact record. Argh. One thing I did notice was that in the failed scenario (described in my previous message), the tmp file named /tmp/fooDI-FILESbar was incomplete, but in the run today with -D, the corresponding tmp file was much larger (48851 bytes) and had a lot more ports listed. No idea if that's significant. ~!paul -- G. Paul Ziemba FreeBSD unix: 12:46PM up 2 days, 32 mins, 8 users, load averages: 1.05, 1.26, 1.66 ___ 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 3.13.13 real endless loop Waiting on fetch checksum..
do...@freebsd.org (Doug Barton) writes: I will need some time to address this, I'll try to get a patch out by the end of this weekend. Thanks for your efforts Doug. I'm not blocked by this issue but I'll bet your fix will save time for others down the road. ~!paul -- G. Paul Ziemba FreeBSD unix: 10:46PM up 2 days, 10:32, 12 users, load averages: 0.01, 0.02, 0.13 ___ 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 3.13.13 real endless loop Waiting on fetch checksum..
openexr-1.6.1.tar.gz OpenSP-1.5.2.tar.gz WebMagick-2.03pre15.tar.gz XPostitPlus-2.3.tar.gz Xaw3d-1.5E.tar.gz a2ps-4.13b.tar.gz i18n-fonts-0.1.tar.gz aalib-1.4rc5.tar.gz acroread/AdobeReader_enu-8.1.7-1.i486.tar.bz2 linux_adobe_kmod-20110920.tar.gz adns-1.4.tar.gz adzap-20110915.tar.gz afm-tar.Z amanda-3.3.2.tar.gz amanda-3.3.2.tar.gz amarok-2.6.0.tar.bz2 % sudo cat /tmp/f-86431-fetchlog-gsoap.uObJLmDH === Found saved configuration for gsoap-2.8.8 = gsoap_2.8.8.zip doesn't seem to exist in /usr/ports/distfiles//. = Attempting to fetch http://heanet.dl.sourceforge.net/project/gsoap2/gSOAP/gsoap_2.8.8.zip gsoap_2.8.8.zip Terminated = Attempting to fetch http://sunet.dl.sourceforge.net/project/gsoap2/gSOAP/gsoap_2.8.8.zip gsoap_2.8.8.zip 13 MB 153 kBps -- G. Paul Ziemba FreeBSD unix: 4:56PM up 122 days, 14:42, 19 users, load averages: 0.41, 0.33, 0.27 ___ 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: Mason 2 - anyone updating? (www/p5-HTML-Mason)
5u623...@gmail.com (Muhammad Moinur Rahman) writes: I have submitted a PR for Mason 2. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/166952 Great work! Thanks for your efforts. I look forward to using this port. ~!paul -- G. Paul Ziemba FreeBSD unix: 11:56AM up 56 days, 20:49, 34 users, load averages: 0.30, 0.25, 0.19 ___ 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: Mason 2 - anyone updating? (www/p5-HTML-Mason)
5u623...@gmail.com (Muhammad Moinur Rahman) writes: Can you give any link towards 2.X branch? Ports tree has 1.45 while CPAN has 1.48. http://search.cpan.org/~jswartz/Mason-2.17/ -- G. Paul Ziemba FreeBSD unix: 1:56AM up 42 days, 10:49, 29 users, load averages: 0.21, 0.19, 0.17 ___ 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
Mason 2 - anyone updating? (www/p5-HTML-Mason)
Ports has version 1.45 of Mason. Is anyone doing an update to 2.X? cheers, ~!paul -- G. Paul Ziemba FreeBSD unix: 10:41PM up 42 days, 7:34, 30 users, load averages: 0.29, 0.20, 0.16 ___ 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: Help test aqbanking-4.0.0 (especially with gnucash)
I picked up the new ports: gnucash-2.2.9_2 aqbanking-4.1.0 gwenhywfar-3.9.0 libgmp-4.3.1 guile-1.8.6_1 goffice-0.7.7 libgsf-1.14.14 and was able to build gnucash and aqbanking together successfully; I am able to do ofx operations (get statements) so it seems to work. I think there is some minor issue with regard to money market accounts (specifically, how the account type is represented within aqbanking) but I have patches to send upstream for it. Thanks for putting together the patches for the update, and thanks to amdmi3 for the commits. -- G. Paul Ziemba FreeBSD unix: 9:01AM up 12 days, 6:34, 16 users, load averages: 1.24, 1.18, 1.34 ___ 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: Proposal: mechanism for local patches
[EMAIL PROTECTED] (Dmitry Marakasov) writes: 1. Good that it's at the end of the do-patch target - that way local patches can happen after the official patches Not sure if it's good actually. On the one hand, you usually have patches against vanilla sources, and just want to drop them to some dir and have them applied. Also, there's USE_DOS2UNIX that comes before any actual patching, so for ports that use USE_DOS2UNIX you'll have to adapt patches by hand. On the other hand, this may cause conflicts with patches from ports, If the local patches were applied before the official ports patches, the official patches could fail, or they could undo some of the modifications made by local patches. I think it would be an incorrect result. From the point of view of the local patches, there is potential for variation in the upstream files regardless of whether they are modified by official ports patches, so doing local patching first doesn't let you avoid tweaking local patches from time to time. Updated version here: http://people.freebsd.org/~amdmi3/local-patchdir.patch It looks good to me. Thanks! -- G. Paul Ziemba FreeBSD unix: 12:11AM up 3 days, 9:41, 12 users, load averages: 0.42, 0.40, 0.37 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Proposal: mechanism for local patches
[Site-local patches to ports]
[EMAIL PROTECTED] (Wesley Shields) writes:
On Tue, Dec 02, 2008 at 09:07:43PM +0300, Dmitry Marakasov wrote:
Here's the draft patch for this functionality:
http://people.freebsd.org/~amdmi3/local-patchdir.patch
Other than the above comment I like the patch and would love to see it
implemented. I think it can provide a benefit in situations where
companies/people are doing things with ports that they do not want to
contribute back.
I, too, am happy with the idea of an administrator-specifiable parallel
tree that would have the same structure as /usr/ports. So this approach
involves, for the administrator (I am restating Dmitry's comments):
1. in /etc/make.conf, define USE_LOCALPATCHES=patch-path
2. put patches in patch-path/category/portname/patch-*
If I may offer comments on Dmitry's draft patch:
1. Good that it's at the end of the do-patch target - that way local
patches can happen after the official patches
2. I'm not sure we need the test for *.orig|*.rej|*~|*,v, but it
wouldn't hurt. Maybe it helps admins who are actively developing
local patches. I see that it's in the existing do-patch code above.
3. Does ${OPSYS} belong in the echoed messages for local patches?
--
G. Paul Ziemba
FreeBSD unix:
2:31PM up 2 days, 1 min, 8 users, load averages: 1.36, 1.30, 1.33
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Proposal: mechanism for local patches
[EMAIL PROTECTED] (Scott Lambert) writes:
How about something like WRKDIRPREFIX?
Presumably the logic for dealing with that structure is already in
the system. Maybe you could have USE_LOCAL_PATCHES boolean which
uses ${CATEGORY}/${PORTNAME}/files subdirs in WRKDIRPREFIX, or
LOCALPATCHDIRPREFIX if you want to keep your patches in CVS/SVN without
polluting the CVS/SVN working directory.
I'm not sure I undersand - do you mean that you'd pick one of
$(WRKDIRPREFIX)/${CATEGORY}/${PORTNAME}/files or
$(LOCALPATCHDIRPREFIX)/${CATEGORY}/${PORTNAME}/files to get
patches from, based on the state of USE_LOCAL_PATCHES? But I was
hoping to augment $(WRKDIRPREFIX)/${CATEGORY}/${PORTNAME}/files
instead of replacing it.
--
G. Paul Ziemba
FreeBSD unix:
6:06PM up 2 days, 3:36, 8 users, load averages: 1.55, 1.38, 1.31
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Proposal: mechanism for local patches
[EMAIL PROTECTED] (John Marshall) writes:
On Tue, 02 Dec 2008, 21:07 +0300, Dmitry Marakasov wrote:
I think the most convenient way of implementing this is having
a directory hierarchy (either two level ${CATEGORY}/${PORTNAME}/patch-*)
or single level ${PORTNAME}/patch-*) and a single variable that makes
port system look there for patches in addition to ${PATCHDIR}.
Or keep local patches under /var/db/ports/port rather than building a
new tree?
Hmm. I haven't really understood the way directories get named in
/var/db/ports/ - what happens when there is a collision in the
base name of two ports? It seems less obvious than
/foo/${CATEGORY}/${PORTNAME}/
--
G. Paul Ziemba
FreeBSD unix:
6:11PM up 2 days, 3:41, 8 users, load averages: 1.58, 1.39, 1.31
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Proposal: mechanism for local patches
Hi Folks, I sometimes have local patches that I need to apply to ports. For various reasons, these patches are not available in the ports tree (e.g., bug fixes could be still propagating, or I'm trying out a bug fix locally before submitting it, or the local patches might be inappropriate or unwanted for the general FreeBSD populace, etc.) My current practice is to maintain my own tree of patch files and then reference them via EXTRA_PATCHES in /etc/make.conf. Mostly the patches get applied automatically when I upgrade my ports, and when the patches fail I learn about it immediately - no additional recordkeeping is required. However, I am looking for a better way. It's probably an unnatural use of EXTRA_PATCHES. Some ports define EXTRA_PATCHES themselves and override what I have defined in /etc/make.conf, so I have to resort to modifying the ports tree in place and keep yet another list of items to pay attention to when upgrading my ports. In hopes of stimulating some discussion, I propose a new variable, LOCAL_PATCHES (or maybe SITE_PATCHES), that would behave just like EXTRA_PATCHES, except that it would be designated specifically for site-local patches. It would be implemented in the do-patch target in bsd.port.mk at the end, after patches from PATCHDIR are applied, and patch Makefiles would, by convention, leave it unmolested. Have I overlooked some better approach to integrating site-local fixes? -- G. Paul Ziemba FreeBSD unix: 1:31PM up 23:01, 5 users, load averages: 0.20, 0.37, 0.72 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: net/linux-nx-client
[EMAIL PROTECTED] (Boris Samorodov) writes: G. Paul Ziemba [EMAIL PROTECTED] writes: I have been manually creating symlinks in /usr/compat/linux/usr/local/lib, e.g., cd /usr/compat/linux/usr/local/lib ln -s ../../X11R6/lib/libXext.so.6 I'm not sure why I need to make these links or if there is a better approach, but it works for me. By default linuxulator looks for files first at /usr/compat/linux directories and only if it fails then /usr/local is used. I.e. if you have /usr/compat/linux/usr/X11R6/lib/libXext.so.6 than it should be found by linuxulator and no symlinking is needed. My observations come mainly from getting linux plugins working for the FreeBSD native Opera. I wonder if operapluginwrapper.linux is influencing the library search path in some way. -- G. Paul Ziemba FreeBSD unix: 10:06PM up 10 days, 22:44, 6 users, load averages: 0.56, 0.54, 0.40 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: aqbanking update?
[EMAIL PROTECTED] (Beech Rintoul) writes: On Tuesday 09 October 2007, Mattias Lindgren said: I tried to install gnucash2 tonight and it complained about aqbanking being quite out of date. Are there any plans in the works for updating to a newer version? Are there build problems with the newer versions? The current version is 1.0.11, and gnucash is wanting at least 1.6. Thanks, The port isn't maintained, I'll take a look at it and see if I can update it. I made some (locally) updated ports for aqbanking-2.3.1, libofx-0.8.3, gwenhywfar-2.6.0, and gnucash-2.2.0 which I have been using for a few months with no problems. I haven't gotten around to submitting them, but if you're interested, I'd be happy to send them your way. cheers, ~!paul -- G. Paul Ziemba FreeBSD unix: 1:56AM up 20 days, 12:06, 9 users, load averages: 2.52, 2.61, 2.59 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
