Re: Upgrade ruby 1.8 to 1.9 failed
Thanks for the your feedback. Problem is solved simply: # portmaster lang/ruby19 On 24.08.2011 04:34, Stanislav Sedov wrote: On Tue, 23 Aug 2011 13:36:34 +0300 Antongni...@gmail.com mentioned: Upgrade to the latest version failed: # portmaster -o lang/ruby19 lang/ruby18 . compiling zlib cc -shared -o ../../.ext/i386-freebsd8/zlib.so zlib.o -L. -L../.. -L. -rdynamic -Wl,-soname,../../.ext/i386-freebsd8/zlib.so -Wl,-R -Wl,/usr/local/lib -L/usr/local/lib -lruby19 -lz -lcrypt -lm -L/usr/local/lib -rpath=/usr/lib:/usr/local/lib -pthread -lc making ruby19 make: don't know how to make NO_DEPENDS. Stop *** Error code 2 This is most likely due to the bug in the ruby build system we need to fix. It seems it tries to run the inernal make with the same argument the port make has been called with. For now, you can either work around this by building and installing ruby 1.9 manually (via make install), or just keep 1.8 which we returned to as default ruby for now due to a big list of problems we didn't anticipated. Sorry for the inconveniencies! -- best regards, Anton ___ 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
[Request for Comments] Add a AFFECT relationship between ports
Hi people, I would like to propose a new feature/ports relationship/variable on ports management. We could call this feature AFFECT and it exports a kind of dependency. I'd explain the behavior with an example: nvidia-driver port. During the installation process, this port moves the official Xorg openGL installing the NVidia ones. Removing nvidia-driver port, the old official libraries are restored. libGL port C. ignore this kind of stuff and if you update them with the nvidia-driver port installed, you overwrite the Nvidia libraries and the restore procedure (of the nvidia-driver) restores the not-updated official Xorg libraries. This kind of relationship is not a CONFLICT or a DEPEND, it's something different. nvidia-driver AFFECT graphics/libGL, but graphics/libGL must ignore the presence of nvidia-driver. The AFFECT should state: libGL is affected by nvidia-driver, then the update procedure is: * deinstall nvidia-driver * update libGL * reinstall nvidia-driver Comments ideas are really welcome! If you agree, we could start implementationtest of this feature. Best regards, Luca Conrad On 08/23/11 11:38, Conrad J. Sabatier wrote: On Tue, 23 Aug 2011 10:53:48 +0200 Luca Pizzamigliol.pizzamig...@bally-wulff.de wrote: On 08/23/11 10:35, Conrad J. Sabatier wrote: On Tue, 23 Aug 2011 10:08:22 +0200 Luca Pizzamigliol.pizzamig...@bally-wulff.de wrote: There is no conflict: you need to install openGL before and then nvidia Driver. the nvidia driver install procedure renames the original library and install the nvidia version one (look at /usr/local/lib and /usr/local/lib/xorg/modules/extensions, there are XXX-lib* old library) both libraries has the same API, but the nvidia one uses some legacy stuffs on the nvidia kernel driver. Yes, of course, it works fine *if* you make sure to install libGL first. The thing that concerns me is if at some point, say, during a forced portupgrade, the libGL port may overwrite the nvidia library once again. It just seems that there should be something in place to prevent this from happening. Tschüß! :-) Yes, you're right. If you update openGL library later, NVidia driver installation is brocken. Yes, I've already been bitten by this at least once. The right procedure should be: deinstall nvidia driver upgrade openGL libraries reinstall nvidia driver This is a kind of half-conflict: openGL library conflicts with nvidia driver, but nvidia driver doesn't. Or: nvidia-driver installation should block openGL library upgrade. Or: nvidia-driver should be deinstalled before and reinstalled after. This is a more general problem, ports infrastructure doesn't model this kind of dependencies/conflicts. I don't think openGL library maintainer wanna manage others ports that breaks its libraries... We should propose to add to the ports infrastructure this kind of relationship (AFFECTS could be a name) and its management... That would be an interesting proposal to put forth. Not sure how warm of a reception it will be met with, though. :-) Do we need to map out some sort of formal proposal, including a possible implementation, or just toss the idea out for discussion? What do you think? Ciao! (I live in Germany, but I'm still Italian :-) Ah, OK. :-) Well, in that case...Ciao to you, too! :-) ___ 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: [Request for Comments] Add a AFFECT relationship between ports
On 24/08/2011 08:02, Luca Pizzamiglio wrote: I'd explain the behavior with an example: nvidia-driver port. During the installation process, this port moves the official Xorg openGL installing the NVidia ones. Removing nvidia-driver port, the old official libraries are restored. nvidia-driver is pretty much a special case in the ports. I think it (and its slave ports) are the only ports that do anything like that. Your idea is interesting however. Do you have any other examples where this would apply? Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
ports/sysutils/diskcheckd (Re: bad sector in gmirror HDD)
When the specified or calculated rate exceeds 64KB/sec, the
required sleep interval between 64KB chunks is less than one
second. Since diskcheckd calculates the interval in whole seconds
-- because it calls sleep() rather than usleep() or nanosleep()
-- an interval of less than one second is calculated as zero ...
I suspect the fix will be to calculate in microseconds, and call
usleep() instead of sleep().
I think I may have this fixed.
Could one of you try the attached patch? I'm especially interested
to see if this also clears up the issues reported as connected with
gmirror (http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/143566),
since I haven't been able to reproduce that part here.
Summary of changes:
* Calculate delays in microseconds, so that delays of less than
one second between reads (needed to implement rates exceeding
64KB/sec) do not get rounded down to zero.
* Fix a reinitialization problem when handling SIGHUP.
* Additional debug messages (only with -d).
* Comment and manpage improvememts.
diff -ruN diskcheckd.old/files/diskcheckd.8 diskcheckd.new/files/diskcheckd.8
--- diskcheckd.old/files/diskcheckd.8 2001-08-28 22:16:22.0 -0700
+++ diskcheckd.new/files/diskcheckd.8 2011-08-24 07:09:16.0 -0700
@@ -58,15 +58,16 @@
The second format consists of four white space separated
fields,
which are the full pathname of the disk device,
-the size of that disk,
-the frequency in days at which to check that disk,
+the size of this disk,
+the frequency in days at which to check this disk,
and the rate in kilobytes per second at which to check this disk.
-Naturally,
-it would be contradictory to specify both the frequency and the rate,
-so only one of these should be specified.
-Additionally,
-the size of the disk should not be specified if the rate is specified,
-as this information is unnecessary.
+.Pp
+Either the frequency or the rate should be specified, not both,
+since a specified frequency will be internally converted to whatever
+rate will result in the disk being scanned at (approximately) that
+frequency.
+The size of the disk should not be specified if the rate is specified,
+since the size is used only to convert a specified frequency into a rate.
.Pp
If the disk is specified as
.Dq * ,
@@ -89,7 +90,7 @@
Note that
.Nm
always reads data from the disk in 64KB blocks,
-so the rate your specify may not be the exact rate at which the disk is
+so the rate you specify may not be the exact rate at which the disk is
actually checked.
Similarly,
if you specify the third field (days for complete scan) it is unlikely
@@ -132,8 +133,14 @@
If this flag is specified,
.Nm
will not fork into the background and detach from its controlling terminal
-to become a daemon.
-This flag is primarily used for debugging.
+to become a daemon,
+and it will duplicate its system log messages on its standard error output.
+.Pp
+This flag is primarily used for debugging,
+and may be specified more than once.
+Additional instances will result in additional
+debugging messages on standard error;
+these added messages will not be written to the system log.
.It Fl f
Specify the configuration file to use,
instead of the default
@@ -143,6 +150,13 @@
instead of the default
.Pa /var/db/diskcheckd.offsets .
.El
+.Sh PROGRESS REPORTING
+After every 5 minutes or so of sleep time between reads
+(not including time spent waiting for the reads themselves to complete),
+.Nm
+will update its command parameter space to show its progress
+in scanning each disk. This report can be viewed using
+.Xr ps 1 .
.Sh FILES
.Bl -tag -width /var/db/diskcheckd.offsets -compact
.It Pa /usr/local/etc/diskcheckd.conf
@@ -188,3 +202,6 @@
.Sh BUGS
.Nm
assumes all disks have 512 byte sectors.
+.Pp
+The code that attempts to identify and report which slice and partition
+contain a detected error does not understand GPT partitions.
diff -ruN diskcheckd.old/files/diskcheckd.c diskcheckd.new/files/diskcheckd.c
--- diskcheckd.old/files/diskcheckd.c 2004-10-27 22:18:33.0 -0700
+++ diskcheckd.new/files/diskcheckd.c 2011-08-24 07:05:00.0 -0700
@@ -63,10 +63,12 @@
char *device;
off_t size;
int secsize;
- int days, rate, errors, interval, next;
+ int days, rate, errors;
+ long long interval, next;
};
volatile sig_atomic_t got_sighup = 0, got_sigterm = 0;
+volatile int debug = 0;
char **getdisknames(char **, int);
off_t dseek(struct disk *, off_t, int);
@@ -85,9 +87,11 @@
main(int argc, char *argv[]) {
char *buf;
struct disk *disks, *dp;
- int ch, ok, minwait, nextwait;
+ int ch, ok;
+ long long minwait, nextwait;
struct sigaction sa;
- int counter, debug;
+ long long counter;
+ int initial_debug;
const char *conf_file, *save_file;
conf_file = _PATH_CONF;
@@ -97,7 +101,10 @@
while ((ch = getopt(argc, argv, df:o:)) != -1)
switch (ch)
Re: sysutils/diskcheckd needs fixing and a maintainer
Is it logging to syslog? I haven't seen anything in /var/log/messages or on ttyv0 ... It does log errors to syslog. The informational message when reaching the end of the disk is discarded with default syslog.conf, but presumably would be logged if syslog were so configured. Also, would you be happy to take maintainership of this port? Not at this point, given that I would be taking on maintainance not only of the port but also of the application itself. I'm not at all sure that I understand it well enough for that, yet. In the course of fixing what now appears to be the underlying cause of http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/143566 and http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/115853, I have gotten much more familiar with diskcheckd :) The patch I've sent for testing touches only the code and the manpage, but once that is verified I'll send a larger patch that also updates the Makefile (and one other). ___ 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: [Request for Comments] Add a AFFECT relationship between ports
On 08/24/11 10:27, Matthew Seaman wrote: On 24/08/2011 08:02, Luca Pizzamiglio wrote: I'd explain the behavior with an example: nvidia-driver port. During the installation process, this port moves the official Xorg openGL installing the NVidia ones. Removing nvidia-driver port, the old official libraries are restored. nvidia-driver is pretty much a special case in the ports. I think it (and its slave ports) are the only ports that do anything like that. Your idea is interesting however. Do you have any other examples where this would apply? Cheers, Matthew Hi Matthew, at the moment I have no other examples. nvidia-driver is a special case, I know. I guess that some other ports could have the same behavior, but maintainers choose the CONFLICT relationship to solve this issue. It's possible to have devel ports or patched version of some ports that don't conflict with the original one, but just AFFECT them... Best regards, Luca ___ 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: [Request for Comments] Add a AFFECT relationship between ports
On Wed, 24 Aug 2011 09:27:27 +0100 Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 24/08/2011 08:02, Luca Pizzamiglio wrote: I'd explain the behavior with an example: nvidia-driver port. During the installation process, this port moves the official Xorg openGL installing the NVidia ones. Removing nvidia-driver port, the old official libraries are restored. nvidia-driver is pretty much a special case in the ports. I think it (and its slave ports) are the only ports that do anything like that. Your idea is interesting however. Do you have any other examples where this would apply? Luca and I were discussing just that before he submitted this proposal. I have to admit that, other than the nvidia-driver port, nothing else of a similar nature leaps to mind, but that doesn't necessarily mean that such a beast isn't already lurking somewhere in the ports tree, just waiting to be discovered/reported, nor does it preclude the possibility of a similar situation arising in the future. I don't know if the amount of effort needed to implement such a feature can actually be justified at this point. Luca and I didn't discuss any actual implementation details, and to be honest, I'm not even sure where one would begin. But it does seem to me that there should be *some* sort of standardized mechanism for dealing with cases like this, rather than leaving it up to the user to improvise his own workaround. Even with a well-posted advisory notice (This port requires special handling. Here's what you have to do...), one can't escape the conclusion that this is one area where the ports collection simply breaks down, or at least, breaks away from the usual convention of supporting fully automated handling of the low-level details of building a package. To require this sort of hands-on intervention on the user's part just seems to be completely contrary to the entire design/philosophy. The ports collection really is quite a marvel of ingenuity in dealing with a lot of very complicated issues in a very methodical and organized fashion. It bothers me greatly to think that there's this one weakness in an otherwise brilliant design. Just my $.02 worth. :-) -- Conrad J. Sabatier conr...@cox.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
Libreoffice plan
Hi all,
First of all I'd like to apologise about the mess with the update of
libreoffice 3.4, that lead us to the new policy about how to manage the
libreoffice ports.
From now we will be more respectful of what upstream do, which mean we
will maintain two version of libreoffice, the legacy one (thanks crees
for adding it) currently 3.3.3 that I will upgrade soon to 3.3.4 and the
newer one currently the broken 3.4.2 which need fixes and will be
upgraded soon to 3.4.3.
As soon as 3.5 will be out the editors/libreoffice will follow that new
branch, and editors/libreoffice-legacy will become 3.4 which hopefully
will be stabilized at the time.
Concerning how we will maintain the port them self, we are working to
continue unbundling stuff from libreoffice, that should save some
compilation time for users.
You may have noticed some activity around hunspell/mythes/hyphen when
fixed libreoffice 3.4 will be able to use the local
dictionaries/hyphenation/thesaurus installed from ports, which mean you
will be able to have the ${randomlang} dictionaries just by installing
the concerned ports without having to rebuild a new LOCALIZED_LANG
version of libreoffice. thanks sunpoet for the work he has done, and is
still doing on that area.
pgj has also been working a lot on libreoffice, he added the ability to
built the sdk, and has done a great job concerning the l10n.
libreoffice as openoffice are difficult ports to maintain, to not
hesitate to join the office@ team to help, test, discuss about the
office related task.
regards,
Bapt
___
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
libnotify
My system: FreeBSD 8.2-RELEASE-p1 I did: portmaster -r libnotify-0.\* libproxy-0.\* portmaster -a And it stopped at: === License check disabled, port has not defined LICENSE === Found saved configuration for gimp-gmic-plugin-1.4.8.1 === Extracting for gimp-gmic-plugin-1.5.0.0 = SHA256 Checksum OK for gmic_1.5.0.0.tar.gz. === Patching for gimp-gmic-plugin-1.5.0.0 === Applying FreeBSD patches for gimp-gmic-plugin-1.5.0.0 === gimp-gmic-plugin-1.5.0.0 depends on executable: gmake - found === gimp-gmic-plugin-1.5.0.0 depends on file: /usr/local/libdata/pkgconfig/x11.pc - found === gimp-gmic-plugin-1.5.0.0 depends on file: /usr/local/libdata/pkgconfig/xext.pc - found === gimp-gmic-plugin-1.5.0.0 depends on file: /usr/local/libdata/pkgconfig/xrandr.pc - found === gimp-gmic-plugin-1.5.0.0 depends on file: /usr/local/bin/intltool- extract - found === gimp-gmic-plugin-1.5.0.0 depends on executable: pkg-config - found === gimp-gmic-plugin-1.5.0.0 depends on shared library: GraphicsMagick++.6 - found === gimp-gmic-plugin-1.5.0.0 depends on shared library: IlmImf.6 - found === gimp-gmic-plugin-1.5.0.0 depends on shared library: Magick++.4 - found === gimp-gmic-plugin-1.5.0.0 depends on shared library: avcodec.1 - found === gimp-gmic-plugin-1.5.0.0 depends on shared library: opencv_legacy.2 - found === gimp-gmic-plugin-1.5.0.0 depends on shared library: fftw3.5 - found === gimp-gmic-plugin-1.5.0.0 depends on shared library: gimp-2.0 - found === gimp-gmic-plugin-1.5.0.0 depends on shared library: atk-1.0.0 - found === gimp-gmic-plugin-1.5.0.0 depends on shared library: glib-2.0.0 - found === gimp-gmic-plugin-1.5.0.0 depends on shared library: gtk-x11-2.0.0 - found === gimp-gmic-plugin-1.5.0.0 depends on shared library: pango-1.0.0 - found === Configuring for gimp-gmic-plugin-1.5.0.0 checking whether to enable maintainer-specific portions of Makefiles... no checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p checking for gawk... gawk checking whether gmake sets $(MAKE)... yes checking whether the C++ compiler works... yes checking for C++ compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking for style of include used by gmake... GNU checking dependency style of c++... none checking for gcc... cc checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking dependency style of cc... none checking whether gmake sets $(MAKE)... (cached) yes checking for pkg-config... /usr/local/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for GIMP... yes checking for main in -lXext... yes checking for main in -lXrandr... yes checking for main in -lavcodec... yes checking for main in -lavformat... yes checking for main in -lswscale... yes checking for main in -ljpeg... yes checking for main in -lm... yes checking for main in -lpng... yes checking for main in -lpthread... yes checking for main in -lrt... yes checking for main in -ltiff... yes checking for main in -lz... yes checking for main in -lfftw3... yes checking for ImfInputReadPixels in -lIlmImf... yes checking for cvSobel in -lopencv_legacy... yes checking for main in -lopencv_legacy... yes checking how to run the C preprocessor... cpp checking for X... libraries /usr/local/lib, headers /usr/local/include checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking for unistd.h... (cached) yes checking for stdbool.h that conforms to C99... yes checking for _Bool... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for size_t... yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for uint8_t... yes checking for working volatile... yes checking for error_at_line... no checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking for ANSI C header files... (cached) yes checking for vprintf... yes checking for _doprnt... no checking for floor... yes checking for
Re: libnotify
ajtiM wrote on 24.08.2011 14:38: Stop in /usr/ports/graphics/gimp-gmic-plugin. *** Error code 1 Stop in /usr/ports/graphics/gimp-gmic-plugin. === make failed for graphics/gimp-gmic-plugin === Aborting update Too bad. I did not deal with recent updates yet, so i'll try to realize what is wrong some time later this week. -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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
Horde: No such file or directory errors
Sorry for the cross posting but I am really not sure where this belongs. The performance of our H4 test install is not good at the moment and I need to find out why. In looking at the Apache process with truss there are lots of errors like the below. How can I make Horde look in /usr/local/share/pear/Horde/ instead of first trying the webroot? This is on FreeBSD 8-STABLE. access(/usr/local/www/horde4/imp/lib/../../lib/Alarm/Handler.php,0) ERR#2 'No such file or directory' access(/usr/local/www/horde4/lib/Alarm/Handler.php,0) ERR#2 'No such file or directory' access(/usr/local/www/horde4/lib/Horde/Alarm/Handler.php,0) ERR#2 'No such file or directory' access(/usr/local/share/pear/Horde/Alarm/Handler.php,0) = 0 (0x0) 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: libnotify
On Wed, 2011-08-24 at 14:45 +0400, Ruslan Mahmatkhanov wrote: ajtiM wrote on 24.08.2011 14:38: Stop in /usr/ports/graphics/gimp-gmic-plugin. *** Error code 1 Stop in /usr/ports/graphics/gimp-gmic-plugin. === make failed for graphics/gimp-gmic-plugin === Aborting update Too bad. I did not deal with recent updates yet, so i'll try to realize what is wrong some time later this week. This build failure seems to be caused by the recent opencv update to 2.3.1. -Koop ___ 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: Re: FreeBSD unmaintained ports which are currently scheduled for deletion
On -10.01.-28163 14:59, Peter Jeremy wrote:
portname: sysutils/cpuburn
Actually, the mastersite has been discontinued by the ISP. It looks
like it's still available elsewhere but I can't find a replacement
mastersite.
So this one is correct???
It seems to be - which is unfortunate.
Can it be unbroken by using the Internet archive?
--- Makefile2 Aug 2011 17:03:41 - 1.9
+++ Makefile24 Aug 2011 13:46:21 -
@@ -9,5 +9,5 @@
PORTVERSION= 1.4
CATEGORIES=sysutils
-MASTER_SITES= http://pages.sbcglobal.net/redelm/
+MASTER_SITES=
http://web.archive.org/web/20070304200856/http://pages.sbcglobal.net/redelm/
DISTNAME= cpuburn_${PORTVERSION:S/./_/g}
EXTRACT_SUFX= _tar.gz
If so, quite a few other victims of this latest purging can be given a
new life. Yours,
-mi
___
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
vbox-manager shows nissan.de as background
Hi list, i was suprised to see the nissan.de webpage starting up in the background of my Virtualbox-Manager window. I coud not create a screenshot, i had to use my camera:) www.augenstein.net/auge/vbox_nissan.jpg rebuilding vbox and/or the kernel module does not help. Does anyone else see this? Regards, -- auge ___ 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: libnotify
On Wed, 24 Aug 2011 05:38:50 -0500 ajtiM lum...@gmail.com wrote: My system: FreeBSD 8.2-RELEASE-p1 I did: portmaster -r libnotify-0.\* libproxy-0.\* portmaster -a It's not clear to me exactly what you were trying to accomplish there, but a few notes The -r option can only be run for one port at a time. Portmaster glob patterns do not need (and in fact strip) a * from the end of the input. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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
libreoffice 3.4.2 again
Hi! I built LibreOffice 3.4.2 and was not a problem. It works but it doesn't open anymore word doc files. I made a doc file with a previous version of LibreOffice but 3.4.2 doesn't open and I got an error: General Error General input/output error Thanks. Mitja http://jpgmag.com/people/lumiwa ___ 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: libnotify
On Wednesday 24 August 2011 16:51:57 Doug Barton wrote: On Wed, 24 Aug 2011 05:38:50 -0500 ajtiM lum...@gmail.com wrote: My system: FreeBSD 8.2-RELEASE-p1 I did: portmaster -r libnotify-0.\* libproxy-0.\* portmaster -a It's not clear to me exactly what you were trying to accomplish there, but a few notes The -r option can only be run for one port at a time. Portmaster glob patterns do not need (and in fact strip) a * from the end of the input. hth, Doug I did what i red in /usr/ports/UPDATE but gimp-gmic-plugin doesn't want to built after updtae of libnotify. BTW; there are many problems after update of libnotify and opencv too. Mitja http://jpgmag.com/people/lumiwa ___ 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
UPDATING entry incorrect (20110823: AFFECTS: users of devel/libnotify and net/libproxy)
Hello! kwm 2011-08-23 18:37:22 UTC FreeBSD ports repository Modified files: .UPDATING Log: Add instructions for the libnotify and libproxy shlib bumps. ... # portmaster -r libnotify-0.\* libproxy-0.\* It's really a pity, but portmaster (unlike portupgrade) doesn't support several '-r' targets at once - which is exactly what is needed here. It just ignores second package specification. Here is result of this command on my workstation: portmaster -r libnotify-0.\* libproxy-0.\* Installation of devel/libtool (libtool-2.4) Upgrade of libnotify-0.5.2 to libnotify-0.7.3_1 Upgrade of poppler-0.14.5 to poppler-0.16.7 Upgrade of poppler-gtk-0.14.5 to poppler-gtk-0.16.7 Upgrade of xfce4-tumbler-0.1.21 to xfce4-tumbler-0.1.21_1 Upgrade of pcre-8.13 to pcre-8.13_1 Upgrade of Thunar-1.2.2_1 to Thunar-1.2.2_2 Upgrade of cueplayer-0.28 to cueplayer-0.28_1 Upgrade of apache-ant-1.8.2 to apache-ant-1.8.2_1 Installation of devel/automake-wrapper (automake-wrapper-20101119) Installation of devel/automake (automake-1.11.1) Installation of devel/patch (patch-2.6.1_1) Installation of devel/autoconf213 (autoconf-2.13.000227_6) Upgrade of libxul-1.9.2.17 to libxul-1.9.2.17_1 Re-installation of eclipse-3.6.2 Upgrade of firefox-3.6.20,1 to firefox-3.6.20_1,1 Installation of devel/yasm (yasm-1.1.0) Upgrade of firefox-6.0,1 to firefox-6.0_1,1 Upgrade of gnome-mplayer-1.0.0_1 to gnome-mplayer-1.0.0_2 Re-installation of gecko-mediaplayer-1.0.0 Upgrade of py27-notify-0.1.1_7 to py27-notify-0.1.1_8 Re-installation of ibus-1.3.9_1 Re-installation of moonshine-0.7_2 Re-installation of orage-4.8.1 Re-installation of squeeze-0.2.3_2 Upgrade of thunderbird-6.0 to thunderbird-6.0_1 Re-installation of xfce4-mixer-4.8.0 Re-installation of xfce4-appfinder-4.8.0_1 Upgrade of xfce4-settings-4.8.2_1 to xfce4-settings-4.8.2_2 Upgrade of xfce4-desktop-4.8.2_3 to xfce4-desktop-4.8.2_4 Re-installation of xfce4-session-4.8.1 Re-installation of xfce4-wm-4.8.1 Re-installation of xfce-4.8 Note that libproxy is NOT upgraded. So we need to compensate: portmaster -r libproxy-0.\* === The following actions were performed: Installation of devel/cmake (cmake-2.8.4_1) Upgrade of libproxy-0.2.3_1 to libproxy-0.4.6 Installation of x11-fonts/cantarell-fonts (cantarell-fonts-0.0.6) Installation of devel/gsettings-desktop-schemas (gsettings-desktop-schemas-3.0.1) Upgrade of lzo2-2.05 to lzo2-2.06 Installation of security/p11-kit (p11-kit-0.3) Upgrade of gnutls-2.12.7_2 to gnutls-2.12.9 Installation of net/glib-networking (glib-networking-2.28.7_3) Upgrade of libsoup-2.32.2_3 to libsoup-2.34.3 Upgrade of libsoup-gnome-2.32.2_1 to libsoup-gnome-2.34.3_1 Re-installation of gvfs-1.6.6_1 Re-installation of Thunar-1.2.2_2 Re-installation of libgnomeui-2.24.4 Re-installation of eclipse-3.6.2 Re-installation of firefox-3.6.20_1,1 Re-installation of firefox-6.0_1,1 Re-installation of glade3-gnome-3.7.3 Re-installation of libxfce4gui-4.8.1 Re-installation of orage-4.8.1 Re-installation of squeeze-0.2.3_2 Re-installation of thunderbird-6.0_1 Re-installation of xfce4-mixer-4.8.0 Re-installation of xfce4-appfinder-4.8.0_1 Re-installation of xfce4-utils-4.8.2 Re-installation of xfce4-desktop-4.8.2_4 Re-installation of xfce4-wm-4.8.1 Re-installation of xfce-4.8 Re-installation of xfce4-cpugraph-plugin-1.0.1_1 Re-installation of xfce4-genmon-plugin-3.3.0 Now note HUGE amount of duplicate work (only firefox-6 recompiles ~ 20 mins on my Q6600). Alas, but I see no easy workaround short of splitting the command: portmaster -r libnotify-0.\* portmaster -r libproxy-0.\* -- Sincerely, Dmytro ___ 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: libreoffice 3.4.2 again
On Wed, 24 Aug 2011 18:09:04 -0500, ajtiM wrote: Hi! I built LibreOffice 3.4.2 and was not a problem. It works but it doesn't open anymore word doc files. I made a doc file with a previous version of LibreOffice but 3.4.2 doesn't open and I got an error: General Error General input/output error Thanks. Mitja http://jpgmag.com/people/lumiwa ___ 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 Thanks for reporting, we are working one this. I CCed office@ which is the maintainer list regards, Bapt ___ 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
