Re: Ports Crash Report (hplip-3.9.8)
On Wed, 10 Mar 2010 20:12:06 +0530, USM Bish wrote:
snip
...(lots snipped) ...
checking for CRYPTO_free in -lcrypto... yes checking for snmp_timeout in
-lnetsnmp... no checking for snmp_timeout in -lsnmp... no configure:
error: cannot find net/ucd-snmp support (or --disable-network-build)
=== Script configure failed unexpectedly. Please report the problem
to po...@freebsd.org [maintainer] and attach the
/usr/ports/print/hplip3/work/hplip-3.9.8/config.log including the
output of the failure of your make command. Also, it might be a good
idea to provide
an overview of all packages installed on your system (e.g. an `ls
/var/db/pkg`).
*** Error code 1
Stop in /usr/ports/print/hplip3.
*** Error code 1
/snip
See this: http://www.freebsd.org/cgi/query-pr.cgi?pr=144833
As a temporary workaround you can try adding this to make.conf:
.if ${.CURDIR:M/usr/ports/print/hplip3*}
# workaround ports/144833
CFLAGS+=-fstack-protector
.endif
___
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
Truncated package for openjdk6-b17_2
Package for openjdk6 located at: ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/All/openjdk6-b17_2.tbz is truncated: pkg_info openjdk6-b17_2.tbz tar: Truncated input file (needed 3475456 bytes, only -30 available) tar: Error exit delayed from previous errors. pkg_info: tar extract of /home/marcin/openjdk6-b17_2.tbz failed! pkg_info: error during unpacking, no info for 'openjdk6-b17_2.tbz' available ll openjdk6-b17_2.tbz -rw-r--r-- 1 marcin users 4777472 Mar 28 23:55 openjdk6-b17_2.tbz ftp -a ftp.freebsd.org ftp ls /pub/FreeBSD/ports/i386/packages-8-stable/All/openjdk6-b17_2.tbz -rw-r--r--1 110 1002 4777472 Mar 28 21:55 openjdk6-b17_2.tbz According to pointyhat logs, package was successfully built. I don't know how the package uploads are done but they probably could use some more error checking and verification (do pkg_info on uploaded file ?). ___ 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
Strange contents on some ftp mirrors
At this very moment, french package mirror has INDEX newer than in other mirrors: fetch -o INDEX-xx.bz2 http://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/INDEX.bz2 fetch -o INDEX-fr.bz2 http://ftp.fr.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/INDEX.bz2 ls -l total 2656 -rw-r--r-- 1 marcin users 1326192 Jul 27 05:36 INDEX-fr.bz2 -rw-r--r-- 1 marcin users 1352557 Jul 11 03:49 INDEX-xx.bz2 bzgrep ^firefox-3.6 INDEX*.bz2 | cut -f1 -d\| INDEX-fr.bz2:firefox-3.6.7,1 INDEX-xx.bz2:firefox-3.6.4,1 fetch http://ftp.fr.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/All/firefox-3.6.7,1.tbz fetch: http://ftp.fr.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/All/firefox-3.6.7,1.tbz: Not Found fetch http://ftp.fr.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/All/firefox-3.6.4,1.tbz firefox-3.6.4,1.tbz 0% of 18 MB 104 kBps^C yet it does not have those packages. How could something like this happen ? ___ 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: Strange contents on some ftp mirrors
On Tue, 27 Jul 2010 21:03:21 -0700, perryh wrote: Marcin Wisnicki mwisnicki+free...@gmail.com wrote: At this very moment, french package mirror has INDEX newer than in other mirrors: ... yet it does not have those packages. How could something like this happen ? By being examined while a resync was in process: evidently the new INDEX file had been transferred but that package file (and likely others) were still in transit or perhaps not even started yet. Mirroring is not an instantaneous process. Yeah that was it, but it is really, really bad. Mirroring must be atomic (mirror to temporary directory then rename). Otherwise there is a large window of time every couple of days when upgrading packages will at best fail or leave you with broken system. I did binary upgrade with pkg_upgrade yesterday and half of my system was linked against wrong libintl version :( In fact atomic mirroring will not fix it completely, you must keep older versions of packages for at least a few hours after mirroring so anyone that started before mirroring was commited will have a chance to finish. ___ 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: Strange contents on some ftp mirrors
On Wed, 28 Jul 2010 13:15:42 +, Marcin Wisnicki wrote: Yeah that was it, but it is really, really bad. Mirroring must be atomic (mirror to temporary directory then rename). Otherwise there is a large window of time every couple of days when upgrading packages will at best fail or leave you with broken system. I did binary upgrade with pkg_upgrade yesterday and half of my system was linked against wrong libintl version :( In fact atomic mirroring will not fix it completely, you must keep older versions of packages for at least a few hours after mirroring so anyone that started before mirroring was commited will have a chance to finish. Thinking a bit more, even *that* won't save you from broken system at the end of upgrade as it happened to me yesterday since packages keep their versions when rebuilt with different incompatible dependencies. Awww crap, whole package thing on FreeBSD is broken by design :( I guess the only possible fix for upgrades in the middle of mirroring would be to have completely immutable repositories with timestamp in their name and then some file that points to latest complete repository. Older repositories could be deleted after some time. Actually there are even programs based on rsync (liek rsnapshot) that do something similar. ___ 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: Strange contents on some ftp mirrors
On Wed, 28 Jul 2010 15:43:43 +0200, Julian H. Stacey wrote: Mirroring must be atomic (mirror to temporary directory then rename). That could double disc requirement, reduce mirror sites willing to provide space ? Indeed it would. But there is no other way to solve it. Alternatively it could be prevented with no disk cost by putting MIRROR-IN-PROGRESS file and making all package utilities check for its existence and fail with explanation to try again later. Cheers, Julian ___ 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: Strange contents on some ftp mirrors
On Wed, 28 Jul 2010 17:39:17 +0200, Dominic Fandrey wrote: On 28/07/2010 15:15, Marcin Wisnicki wrote: On Tue, 27 Jul 2010 21:03:21 -0700, perryh wrote: Marcin Wisnicki mwisnicki+free...@gmail.com wrote: At this very moment, french package mirror has INDEX newer than in other mirrors: ... yet it does not have those packages. How could something like this happen ? By being examined while a resync was in process: evidently the new INDEX file had been transferred but that package file (and likely others) were still in transit or perhaps not even started yet. Mirroring is not an instantaneous process. Yeah that was it, but it is really, really bad. Mirroring must be atomic (mirror to temporary directory then rename). Otherwise there is a large window of time every couple of days when upgrading packages will at best fail or leave you with broken system. I did binary upgrade with pkg_upgrade yesterday and half of my system was linked against wrong libintl version :( The next version of pkg_upgrade will check every downloaded package against the master server after completing the download. Great, I need this so much. Currently to really upgrade packages I must do something like: rm -rf /usr/ports/packages pkg_upgrade -af to make sure rebuilt packages are refetched. But it's obviously suboptimal. I think you could also detect inconsistent mirror by comparing modification time of package against mtime of INDEX. If pkg is newer than INDEX then it's a sign of incomplete sync. I expect to release it at the end of September. 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: Strange contents on some ftp mirrors
On Wed, 28 Jul 2010 17:11:25 +0200, Julian H. Stacey wrote: Marcin Wisnicki wrote: Alternatively it could be prevented with no disk cost by putting MIRROR-IN-PROGRESS file and making all package utilities check for its existence and fail with explanation to try again later. Perhaps a less visible /or top listing semaphore of ./.MIRROR-IN-PROGRESS ? Content could be empty, or mirror master could generate into it, eg: Version:Number of format of .MIRROR-IN-PROGRESS\n Master-URL: Of master\n Protocol: Of mirror\n Date: (GMT) start of mirror\n Contact:If mirror fails\n Text: Any other text.\n EOR:End of record\n Various FreeBSD etc stuff gets mirrored as nested directories, so one might want to to be able to check up to N steps up the parent tree structure for lock(s). Unfortunately no scheme involving global lock files will really work. I've read http://wiki.freebsd.org/FreeBSDMirrors that you linked and it mentions TIMESTAMP files that it uses to monitor mirrors quality. You just need to visit $random[1] freebsd mirror and look at that file then check packages directory. You will find that it can have latest timestamp yet many months old files. In other words, mirrors cannot be trusted. For now however I've found and suggested in sibling post a workaround that should mostly work assuming INDEX file gets mirrored before packages (and it looks like it is). [1] random = ftp.pl.freebsd.org, but it's not the only one One might also want an optional force- fetch- regardless flag. Awkward conditions to allow for: What if mirror is not mirroring when you start your fetch, but is when you finish ? What if mirror is not mirroring when you start your fetch, then mirror starts finishes a mirror before you finish your fetch ? Solving any of this, in a way that does not require intervention of user if it happens, requires that file content at given url is immutable (or doesn't exist). There is simply no other 100% reliable way. You can however do some sanity checks and fail early if failing is acceptable. Some ideas: 1. if (mtime(pkg) mtime(INDEX)) fail(Mirror sync in progress); 2. Fetch timestamps of all requested packages in one go before fetching contents; do it again and compare to be sure nothing changed; fetch actual packages and fail if mtime/size does not match. 3. Do 1 or 2 but fetch timestamps from well known source or multiple sources. You may also find most up-to-date mirror this way. One might want to generalise a mechanism that could be added to multiple tools, eg ports/net/ mirror/ rdist6/ rsync/ ?... ___ 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: Strange contents on some ftp mirrors
On Wed, 28 Jul 2010 20:02:40 +0200, Dominic Fandrey wrote: On 28/07/2010 17:58, Marcin Wisnicki wrote: I think you could also detect inconsistent mirror by comparing modification time of package against mtime of INDEX. If pkg is newer than INDEX then it's a sign of incomplete sync. True, but if the check does not fail it still doesn't mean that the package is valid. Checking against the master (it will check size and time) is the safest method, I think What do you mean by master ? If you think about ftp-master then it's password protected. AFAIK there is no publicly available ftp site that is an authoritative source, ftp.freebsd.org is synced just like any other mirror. You can see in my initial post that it was even less up-to-date than ftp.fr.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: Strange contents on some ftp mirrors
On Thu, 29 Jul 2010 00:18:01 +0200, Dominic Fandrey wrote:
On 28/07/2010 23:24, Andrew W. Nosenko wrote:
Excuse me? The ports check downloaded source tarball against SHA
checksum. Just for nay case like downloading error or malicious
inject. Did you try to say that binary package have no such safeguard?
Exactly. The INDEX does not contain such information. The thing is to do
that, the pointyhat INDEX format would have to differ from the ports
INDEX format.
It could be renamed to PKGINDEX.
A possiblity of course, but also a source of trouble if the INDEX format
of the ports should ever change, something I desire:
http://www.freebsd.org/cgi/query-pr.cgi?pr=148783
It's also missing ranged versions of dependencies like foo=2.0.
Another solution would be to add an empty column that pointyhat can fill
in.
Actually I'd rather have less data in INDEX.
Some columns have no use in case of packages
({BUILD,FETCH,EXTRACT,PATCH}_DEPENDS).
Additional data can be stored in separate files as long as there is some way
to verify they all belong to same build. It could be some information
in header (does INDEX support comments?) or some assumption such as that
modification times may not differ by more than a couple of seconds
(just touch them all at the end of build).
I think storing all columns in separate files would be better and allow
future extensibility.
For example consider PKGINDEX subdirectory with following files,
each having one entry per line:
# PKGINDEX/format:
MANDATORY org.freebsd.PKGINDEX 1
OPTIONAL com.mycomany.PKGINDEX 1
# this one actually has custom format
# list base format and extensions
# mandatory must be supported by client, optional can be ignored
# i'm probably overengineering here a little ;)
# PKGINDEX/packages.list:
bar-2.0
baz-3.2
foo-1.0
# *.list files are just lists (ordered alphabetically)
# PKGINDEX/run-depends.map:
foo-1.0 bar-2.0
foo-1.0 baz=3.1
# *.map files have key value+ pairs (ordered alphabetically)
# in this case foo needs bar baz
# in future it could support boolean operators
# e.g.:
# foo-1.0 (bar-2.0 || bar-alternate=2.0)
# foo-1.0 (baz=3.1 baz4.0)
# where '-' is soft requirement like currently implemented in pkg_add
# new operators would be strictly enforced
# PKGINDEX/category.map:
foo-1.0 sysutils databases devel
# sysutils is primary category of foo-1.0
# additional categories follow in alphabetic order
# PKGINDEX/origin.map:
foo-1.0 sysutils/foo
# PKGINDEX/description.map:
bar-3.2 Bar is better than foo
foo-1.0 Foo is great
etc...
I have some awk scripts to produce something like that from INDEX ;)
General idea is to have sorted files where first column is always a key.
You can then operate on them using utilities like join(1) and tsort(1).
Having potentially large but rarely used attributes like description
in separate files greatly reduces amount of text needed to be loaded and
parsed by utilities in common operations.
___
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: Strange contents on some ftp mirrors
On Thu, 29 Jul 2010 00:23:58 +0200, Dominic Fandrey wrote: On 28/07/2010 23:36, Marcin Wisnicki wrote: What do you mean by master ? If you think about ftp-master then it's password protected. AFAIK there is no publicly available ftp site that is an authoritative source, ftp.freebsd.org is synced just like any other mirror. You can see in my initial post that it was even less up-to-date than ftp.fr.freebsd.org. Well, I never had a download of an INDEXED package fail from one of the unnumbered servers, so there ought to be something different, because the remaining mirrors normally only are able to provide ~20% of them. Well, ftp.fr.freebsd is not numbered and it just failed. In the past I had problems with ftp.freebsd.org. In fact there may be even problems with ftp-master. Not so long ago uploaded package of openjdk6 was truncated on every mirror. Though it's something that you really can't defend against :( Any way, in pkg_upgrade terms master is whichever server is chosen to provide the index. Everything else downloaded will be checked to be consistent with that one. It's not about getting the latest packages, but about getting a consistent set. Indeed, that's why you can't trust mirrors. And since there is no other source to trust you must do as much sanity checking as possible. ___ 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
[RFC] NO_INSTALL in meta-ports considered harmful
Some metaports (like print/cups) use NO_INSTALL. This will prevent such port from registering its installation in /var/db/ pkg, which is different behaviour from installing it from prebuilt package (where it registers just fine). IMHO not registering installation makes no sense and serves only to confuse users (I've installed cups yet pkg_info claims I didn't!) and causes unnecessary differences between software installed from ports vs pkgs, which may lead to other unexpected problems (like missing RUN_DEPENDS). Thus I advocate for more uniform handling of ports and packages by treating it as a bug and replacing any such use of NO_INSTALL with empty do-install target. Maybe even add a note to Porter's Handbook (though I see no reference to NO_INSTALL there). If anyone has some insightfull comments why NO_INSTALL is not evil then I'm all ears. ___ 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: [RFC] NO_INSTALL in meta-ports considered harmful
On Sun, 10 May 2009 13:08:56 -0400, Glen Barber wrote: I'm not sure if this is the 'right answer', but NO_INSTALL allows the proper installation of numerous ports from one location (the meta-port). An example of this is the misc/instant-server port (though unmaintained, IIRC). If you remove the NO_INSTALL line from the Makefile, 'make' thinks misc/instant-server should be installed, rather than the collection of ports it is intended to install. They will be installed since they are run dependencies. Again, this is my interpretation of it. If I'm wrong, I gladly accept corrections to my thinking. :) ___ 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: [RFC] NO_INSTALL in meta-ports considered harmful
On Sun, 10 May 2009 15:22:04 -0400, Glen Barber wrote: On Sun, May 10, 2009 at 2:51 PM, Marcin Wisnicki mwisnicki+free...@gmail.com wrote: They will be installed since they are run dependencies. From what I can tell (from several metaports) -- they, themselves, are not installed. The ports defined in the metaport are installed. That's the point. The metaports should be installed as well (reasons given in my original mail). There is no source code for, using your example, CUPS[1]. CUPS (in the FreeBSD ports tree) is, for lack of a better explanation, a pointer to which specific ports you need to have in order to get a fully operation CUPS system running. Looking at the Makefile for print/cups [2] you can see the dependencies and that CUPS is not actually built (which in definition is what makes this a metaport). I know this. The proper way to make a metaport is to: 1. use only RUN_DEPENDS 2. set NO_BUILD 3. do *NOT* set NO_INSTALL 4. provide empty do-install target There are several metaports that get it right, like for example x11/gnome2: http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11/gnome2/Makefile?rev=1.155 ___ 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: MOVED and UPDATING delivered with packages
On Tue, 11 Aug 2009 10:52:31 +0200, Dominic Fandrey wrote: The portmgr team has enhanced the pointyhead scripts to publish MOVED and UPDATING files together with the INDEX files that kports and pkg_upgrade use for binary package updating. http://www.freebsd.org/cgi/query-pr.cgi?pr=135024 Very much appreciated but how about also providing them in bzip2 compressed form ? Especially INDEX, since it's is so large and compresses so good: # ls -l /usr/ports/INDEX-8* -rw-r--r-- 1 root wheel 19435698 Jul 25 06:20 /usr/ports/INDEX-8 -rw-r--r-- 1 root wheel 1295390 Jul 23 13:09 /usr/ports/INDEX-8.bz2 ___ 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: RFC: svn for make fetch
On Sun, 08 Nov 2009 17:31:57 +0200, Eitan Adler wrote:
I was hoping to get a bit more of a response to a recent posting of mine
with regard to using svn to fetch files for ports My proposal:
http://www.mail-archive.com/freebsd-ports@freebsd.org/msg23776.html A
summary of what has been going on:
http://wiki.freebsd.org/EitanAdler/ports-svn
This is something that more than 2 people should have an input on
Unless you solve plist problem (and completely automated plist generation
would be a fantastic thing to have!), such functionality should not be
available (or at least advertised) to end-users.
You may also consider moving it to separate file (bsd.maintainer.mk).
I don't quite get the logic behind ${USER} == ${SVN_USER} conditional.
Why do you assume that if my username is the same as username for svn
checkout then I want to upload snapshot to freefall ? In addition not
every maintainer has @freebsd.org account. Uploading should be
customizable (maybe UPLOAD_CMD - like FETCH_CMD).
Other than that I really like the idea (maintainer part) since I had to
do something similar recently with smartmontools and having a
standardised way to prepare ports for svn snapshots would have saved me
some time. FWIW here is how I did it (in port's Makefile):
PORTVERSION=5.38.r${SVNREVISION}
SVNREVISION=2924
# no prebuilt files in svn
USE_AUTOTOOLS= aclocal:110 autoheader:262 automake:110 autoconf:262
# skip...
.if defined(MAINTAINER_MODE)
DISTFILES=
SVN_URL=https://path/to/trunk
x-maintainer-make-snapshot:
svn export -r${SVNREVISION} ${SVN_URL} ${DISTNAME}
${TAR} -cjvf ${DISTNAME}.tar.bz2 ${DISTNAME}
${RM} -rf ${DISTNAME}
post-extract:
svn co -r${SVNREVISION} ${SVN_URL} ${WRKSRC}
.if defined(HEAD_REVISION)
SVNREVISION!= svn info ${SVN_URL} | grep ^Last Changed Rev: \
| awk '{print $$4}'
.endif
# TODO generate plist
.endif # MAINTAINER_MODE
___
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: ruby18, -pthreads, deep recursion
On Thu, 01 Nov 2007 22:02:38 -0500, Josh Paetzel wrote: On Thursday 01 November 2007 04:04:35 pm lemon wrote: [0] http://lists.freebsd.org/pipermail/freebsd-ports/2005- January/019352.html http://lists.freebsd.org/pipermail/freebsd-ports/2006- March/030691.html If it's any consolation, I've emailed the ruby maintainer a few times about why disabling threads in the port's menu doesn't *really* disable threads and have never gotten a reply. As explained in abovementioned links, some of ruby extensions need pthreads but since shared modules on freebsd are never linked with threading libraries (i think it might no longer be true in releng7/ current), you have no other choice than to link ruby interpreter binary with libpthread. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mail/mail-notification 5.4 fails to compile
You will need this patch: http://patch-tracker.debian.org/patch/series/view/mail-notification/5.4.dfsg.1-8/disable-werror.patch from which you have to strip first directory in file name. Unfortunately I don't have the time to test it right now or in the near future. On Sat, Aug 3, 2013 at 3:29 PM, Torfinn Ingolfsen tin...@gmail.com wrote: mail-mailnotification 5.4 fails to compile: === Configuring for mail-notification-5.4_10 cd /usr/ports/mail/mail-notification/work/mail-notification-5.4 jb_cppflags=-I/usr/local/include jb_ldflags= -L/usr/local/lib -Wl,-rpath=/usr/lib:/usr/local/lib ./jb configure cc=cc cflags=-O2 -pipe -fno-strict-aliasing cppflags=-I/usr/local/include ldflags= -L/usr/local/lib -Wl,-rpath=/usr/lib:/usr/local/lib prefix=/usr/local hotmail=no yahoo=no evolution=no mozilla=no building jb... cc1: warnings being treated as errors jbsrc/lib/src/core/jb-main.c: In function 'jb_main': jbsrc/lib/src/core/jb-main.c:164: warning: 'g_type_init' is deprecated (declared at /usr/local/include/glib-2.0/gobject/gtype.h:669) cc1: warnings being treated as errors jbsrc/lib/src/core/jb-util.c: In function 'print_warning_or_error': jbsrc/lib/src/core/jb-util.c:225: warning: function might be possible candidate for 'printf' format attribute ERROR: cannot build jb *** Error code 1 Stop in /usr/ports/mail/mail-notification. *** Error code 1 Stop in /usr/ports/mail/mail-notification. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portinstall20130803-82900-28tjk2 env make ** Fix the problem and try again. ** Listing the failed packages (-:ignored / *:skipped / !:failed) ! mail/mail-notification(unknown build error) This is on: tingo@kg-core1$ uname -a FreeBSD kg-core1.kg4.no 8.4-STABLE FreeBSD 8.4-STABLE #0 r253646: Thu Jul 25 10:12:31 UTC 2013 r...@kg-core1.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 HTH -- Regards Torfinn Ingolfsen ___ 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: mail/mail-notification 5.4 fails to compile
BTW there are no build errors on build cluster. Is there anything non-standard about your build environment ? On Sun, Aug 4, 2013 at 8:42 PM, Marcin Wisnicki mwisnicki+free...@gmail.com wrote: I guess bsd.gnome.mk should be smart enough to `killall -HUP gconfd-2` at package post-install when port uses gconf (has GCONF_SCHEMAS). Please file a PR against gnome ports. On Sun, Aug 4, 2013 at 8:08 PM, Torfinn Ingolfsen tin...@gmail.com wrote: Hi, On Sat, Aug 3, 2013 at 7:32 PM, Marcin Wisnicki mwisnicki+free...@gmail.com wrote: You will need this patch: http://patch-tracker.debian.org/patch/series/view/mail-notification/5.4.dfsg.1-8/disable-werror.patch from which you have to strip first directory in file name. Thanks, testing now: root@kg-core1# pwd /usr/ports/mail/mail-notification/work/mail-notification-5.4 root@kg-core1# patch -p1 /home/tingo/work/disable-werror.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Description: Check for maintainer mode correctly |Author: Stephen Kitt st...@sk2.org | |Maintainer mode was being activated in all cases, which is not |desirable; in particular on buildds it enables -Werror which causes |the build to fail now. | |--- mail-notification-5.4.dfsg.1.orig/jb |+++ mail-notification-5.4.dfsg.1/jb -- Patching file jb using Plan A... Hunk #1 succeeded at 37. done Patched without trouble. root@kg-core1# cd ../.. output from build: === Configuring for mail-notification-5.4_10 cd /usr/ports/mail/mail-notification/work/mail-notification-5.4 jb_cppflags=-I/usr/local/include jb_ldflags= -L/usr/local/lib -Wl,-rpath=/usr/lib:/usr/local/lib ./jb configure cc=cc cflags=-O2 -pipe -fno-strict-aliasing cppflags=-I/usr/local/include ldflags= -L/usr/local/lib -Wl,-rpath=/usr/lib:/usr/local/lib prefix=/usr/local hotmail=no yahoo=no evolution=no mozilla=no [...] building program mail-notification Mail Notification 5.4 was built successfully. Type sudo ./jb install to install Mail Notification 5.4. output from install: Mail Notification 5.4 was installed successfully. === Running ldconfig /sbin/ldconfig -m /usr/local/lib === Registering installation for mail-notification-5.4_10 But upon starting I get this: tingo@kg-core1$ mail-notification -p ** (mail-notification:37126): WARNING **: cannot find default value of configuration key /apps/mail-notification/commands/new-mail/enabled ** (mail-notification:37126): WARNING **: cannot find default value of configuration key /apps/mail-notification/commands/new-mail/command (lots of lines snipped for brevity) It seems this is a known bug: https://bugzilla.redhat.com/show_bug.cgi?id=522363 https://bugzilla.redhat.com/show_bug.cgi?id=682584 Testing with gconftool-2: tingo@kg-core1$ gconftool-2 --get /apps/mail-notification/commands/new-mail/enabled No value set for `/apps/mail-notification/commands/new-mail/enabled' root@kg-core1# pkill gconfd-2 tingo@kg-core1$ gconftool-2 --get /apps/mail-notification/commands/new-mail/enabled false and after that starting mail-notification works. HTH -- Regards, Torfinn Ingolfsen ___ 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: mail/mail-notification 5.4 fails to compile
It's not a workaround - it is a real fix as suggested by gconf documentation and it's used by linux distros (see debian[1] and gentoo[2]). [1] http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gconf/debian/gconf2.postinst?revision=31302view=markup [2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/gnome2-utils.eclass?diff_format=srevision=1.31view=markup On Mon, Aug 5, 2013 at 9:40 PM, Torfinn Ingolfsen tin...@gmail.com wrote: On Sun, Aug 4, 2013 at 8:42 PM, Marcin Wisnicki mwisnicki+free...@gmail.com wrote: I guess bsd.gnome.mk should be smart enough to `killall -HUP gconfd-2` at package post-install when port uses gconf (has GCONF_SCHEMAS). Please file a PR against gnome ports. Are you sure that this way (killall -HUP ...) is the correct fix? It seems like a workaround (instead of a real fix) to me, based on the discussion in the two bugs I listed in my previous message. Also, pkill -HUP gconfd-2 didn't work for me, I had to kill the gconfd-2 process totally. HTH -- Regards, Torfinn Ingolfsen ___ 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: Cups upgrade compile failure
On Fri, 28 Sep 2007 23:48:56 +0200, Christoph Moench-Tegeder wrote: Quoting myself, I'll hold my upgrade-request for cups 1.3.0-1.3.2 until this is fixed :) If anyone's bold enough to test, here's the port: http://www.burggraben.net/hacks/ports/cups_cups-base.tar.gz (containing print/cups and print/cups/base version 1.3.2). Regards Christoph I've submitted update to 1.3.3 so you may want to test that: http://www.freebsd.org/cgi/query-pr.cgi?pr=116743 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with portupgrade xscreensaver-gnome
On Wed, 30 Jul 2008 08:51:23 -0400, Bill Moran wrote: cvsupped my ports tree just this morning. #uname -a FreeBSD vanquish.ws.pitbpa0.priv.collaborativefusion.com 7.0-RELEASE FreeBSD 7.0-RELEASE #4: Wed Jun 25 09:16:13 EDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/ sys/VANQUISH i386 # pkg_info | grep portupgrade portupgrade-2.4.6,2 FreeBSD ports/packages administration and management tool s # portupgrade -a [...] ** Makefile possibly broken: x11/xscreensaver-gnome: Makefile, line 106: warning: Option KEYRING needs PAM, but PAM is disabled. xscreensaver-gnome-5.06_1 You need to either enable PAM (recommended) or disable KEYRING by doing: cd /usr/ports/x11/xscreensaver-gnome/; make config ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with portupgrade xscreensaver-gnome
On Wed, 30 Jul 2008 22:30:50 +0100, RW wrote: I think Bill probably understands that. The issue, as I see it, is that the warning will just be a warning if you build manually, but if you build through portupgrade it causes it to fail. If the intent was to stop the build then IGNORE should have been set instead. Well the intent was to warn the user that without PAM, keyring functionality will be disabled. You are right there needs to be some info about that in KEYRING option description. If .warning breaks portupgrade I can change it to IGNORE. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with portupgrade xscreensaver-gnome
On Wed, 30 Jul 2008 17:45:10 -0400, Bill Moran wrote: In response to Marcin Wisnicki [EMAIL PROTECTED]: On Wed, 30 Jul 2008 08:51:23 -0400, Bill Moran wrote: cvsupped my ports tree just this morning. #uname -a FreeBSD vanquish.ws.pitbpa0.priv.collaborativefusion.com 7.0-RELEASE FreeBSD 7.0-RELEASE #4: Wed Jun 25 09:16:13 EDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/ src/ sys/VANQUISH i386 # pkg_info | grep portupgrade portupgrade-2.4.6,2 FreeBSD ports/packages administration and management tool s # portupgrade -a [...] ** Makefile possibly broken: x11/xscreensaver-gnome: Makefile, line 106: warning: Option KEYRING needs PAM, but PAM is disabled. xscreensaver-gnome-5.06_1 You need to either enable PAM (recommended) or disable KEYRING by doing: cd /usr/ports/x11/xscreensaver-gnome/; make config Are you saying that I can't portupgrade ANY ports on my system until such time as I make this strange decision? Why do you think it is a strange decision? You have set non-default options that don't make sense and the port is warning you about that. Fixing it is quick, easy and painless. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with portupgrade xscreensaver-gnome
On Wed, 30 Jul 2008 17:42:33 -0500, Jeremy Messenger wrote: On Wed, 30 Jul 2008 17:09:11 -0500, Marcin Wisnicki [EMAIL PROTECTED] wrote: If .warning breaks portupgrade I can change it to IGNORE. I prefer remove .warning and IGNORE. If user wants to enable keyring then the WITH_KEYRING should be always enable PAM, no matter if user has selected it disable. And, tweak comment in OPTIONS for (reqiure PAM). OK, I've sent patches to PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=126114 As suggested, .warning was removed, option description improved and KEYRING will force PAM. http://www.freebsd.org/cgi/query-pr.cgi?pr=126115 Like above, gnome-screensaver has similar .warning, but because of partially broken pam support, the logic is reversed: lack of pam will disable keyring. Also I've introduced some anti foot-shooting measures until the problem is fixed, so users of g-s won't end up with broken setup by selecting wrong options. Maybe options should be hidden behind GNOME_SCREENSAVER_WITH_BROKEN_PAM conditional ? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for comments - pkg_trans
On Thu, 31 Jul 2008 06:25:27 +0200, Ivan Voras wrote: Hi, I apologize in advance if what I'm trying to do seems stupid or it has already existed since the Dawn of Time (i.e. when McKusick was in diapers) but I'd like your comments on this idea: http://wiki.freebsd.org/IvanVoras/PkgTransProposal Looking at your use cases I think what you are proposing is overkill. * Install some large group of packages, like KDE or GNOME. Don't like it, want to delete all packages installed during the operation. This could be achieved by tracking which ports were installed explicitly by user. I.e. when I type: (cd /usr/ports/x11/gnome2; make install) or pkg_add -r gnome2 It will install gnome2 along with it's dependencies but in some way mark gnome2 package as installed by user, say, by creating /var/db/pkg/ gnome2-2.22/+USER_INSTALLED or even easier, by maintaing some special unremovable dummy package that would depend on all packages installed explicitly. Then when you decide you want to get rid of gnome something like this could be implemented: pkg_deinstall -Ru gnome2-2.22 where option 'R' (already exists in pkg_deinstall but could be added to pkg_delete) means Deinstall all those packages required by the given packages as well. and option 'u' would be something like keep packages installed explicitly. I think similar solution is/was used in Gentoo. You can even approximate this behaviour with existing tools like pkg_rmleaves or pkg_cutleaves, though you will need to manually maintain a list of packages to keep. * Install a newer version of postgresql, have an OMG moment and remember you need to dump the database with the old version and reaload it with the new version. Revert the install by deleting the new packages and reinstalling the old ones (i.e. undo a removal). pkg_deinstall -R posgtresql-8.4.0; pkg_add postgresql-8.3.0 but you still need to figure out how to get old packages (portupgrade/ portinstall with option -P keeps all packages on disk). Also if not all dependencies of postgres84 could be removed (because some other package needs them) then you could have a problem in either of schemes (yours and mine). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for comments - pkg_trans
On Fri, 01 Aug 2008 17:33:43 +0200, Ivan Voras wrote: Marcin Wisnicki wrote: On Thu, 31 Jul 2008 06:25:27 +0200, Ivan Voras wrote: It will install gnome2 along with it's dependencies but in some way mark gnome2 package as installed by user, say, by creating /var/db/pkg/ gnome2-2.22/+USER_INSTALLED or even easier, by maintaing some special unremovable dummy package that would depend on all packages installed explicitly. This has the same problems as my scheme But is simpler both conceptually and in implementation and I'm not sure the benefits are the same. With pkg_trans, we know explicitly which packages were pulled in when, and the order in which they were pulled. Well I'm not sure why any user would care about order and it can be inferred from mtime of package metadata or new +comment DATE (see http://blogs.freebsdish.org/andenore/) anyway. What is important is to know: 1. Which packages are important to user (most likely the those that he installed explicitly) 2. Which packages can be safely removed = everything that is not (1) or isn't a dependancy of (1) * Install a newer version of postgresql, have an OMG moment and remember you need to dump the database with the old version and reaload it with the new version. Revert the install by deleting the new packages and reinstalling the old ones (i.e. undo a removal). pkg_deinstall -R posgtresql-8.4.0; pkg_add postgresql-8.3.0 Yes, with the exception that something needs to do pkg_create -b postgresql-8.3.0 before it's removed, and I don't trust myself to remember this every time :) (I want it to happen automatically) Or save the package during installation. Like portugprade. Anyway, it is a separate problem. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for comments - pkg_trans
On Fri, 01 Aug 2008 16:51:02 +, Marcin Wisnicki wrote: On Fri, 01 Aug 2008 17:33:43 +0200, Ivan Voras wrote: Marcin Wisnicki wrote: On Thu, 31 Jul 2008 06:25:27 +0200, Ivan Voras wrote: It will install gnome2 along with it's dependencies but in some way mark gnome2 package as installed by user, say, by creating /var/db/pkg/ gnome2-2.22/+USER_INSTALLED or even easier, by maintaing some special unremovable dummy package that would depend on all packages installed explicitly. This has the same problems as my scheme But is simpler both conceptually and in implementation and I'm not sure the benefits are the same. With pkg_trans, we know explicitly which packages were pulled in when, and the order in which they were pulled. Well I'm not sure why any user would care about order and it can be Though it would be usefull to have a full log of package operations in machine and human readable format for review/auditing and similar purposes. inferred from mtime of package metadata or new +comment DATE (see http://blogs.freebsdish.org/andenore/) anyway. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My interactive version of pkg_add
On Sat, 27 Sep 2008 21:11:27 -0700, Garrett Cooper wrote:
On Sat, Sep 27, 2008 at 7:02 AM, Michel Talon [EMAIL PROTECTED]
wrote:
Marin Atanasov wrote:
So what do you think - is it worth improving upon it or it's a waste
of time?
Thanks for any suggestions.
INDEX is made available via to pkg_install within sysinstall and exists
on mirrors in the following location:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/${ARCH}/packages-${VERSION}/
INDEX
Would be nice if there was also INDEX.bz2.
Also to be able to write an effective pkg upgrade tool one would need
something like /usr/ports/MOVED.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My interactive version of pkg_add
On Mon, Sep 29, 2008 at 04:08, Garrett Cooper [EMAIL PROTECTED] wrote: On Sun, Sep 28, 2008 at 2:28 PM, Marcin Wisnicki [EMAIL PROTECTED] wrote: Would be nice if there was also INDEX.bz2. You'd need to talk to the release team about that if you don't agree Indeed with that fact; INDEX.bz2 item is a portupgrade-ism, and has its own collection of drawbacks in addition to it's pro's. Also to be able to write an effective pkg upgrade tool one would need something like /usr/ports/MOVED. INDEX already addresses this. Really? How? [EMAIL PROTECTED]:/usr/ports tail -1 MOVED net/p5-Socket||2008-09-25|Removed because newer version is present inside perl5 [EMAIL PROTECTED]:/usr/ports grep 'p5-Socket-[0-9]' INDEX-7 [EMAIL PROTECTED]:/usr/ports So how would one know that it is safe to remove p5-Socket without consulting MOVED ? Unless I'm missing something there needs to be a MOVED file or ideally something like it that has pkgnames (with versions) for a binary package update tool to work. FWIW, I'd get rid of the All/ indexing as it's just a mass conglomeration of all of the other categories. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Testing ports without using poudriere without building dependencies
Is there a simple way to test port without building its dependencies, instead fetching them from package repository. I've tried `poudriere testport` but it wants to build everything. ___ 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: Testing ports without using poudriere without building dependencies
On Sat, 28 Jun 2014 19:18:25 +, Marcin Wisnicki wrote: Is there a simple way to test port without building its dependencies, instead fetching them from package repository. I've tried `poudriere testport` but it wants to build everything. Please ignore first without in subject, it was meant to be: Testing ports using poudriere without building dependencies ___ 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: Finding files in packages (MANIFEST)
On Sun, 21 Nov 2010 13:25:13 +0100, Anders F Björklund wrote: Chris Rees wrote: For PackageKit's app-install, I wanted to list all ports/packages that had a .desktop file (= an app). I may be misunderstanding you here, but you could just: [ch...@amnesiac]~% echo /usr/ports/*/*/pkg-plist | xargs egrep '\.desktop$' | sed 's|/usr/ports/[a-zA-Z]*/||' contains_desktop That could work too (?), It won't because plist can be generated Just thought the MANIFEST could be generated with the packages ? That way you wouldn't need to install the ports collection first. pkg_info -qL your-package.tbz ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Fri, 25 Mar 2011 11:11:11 +0100, Baptiste Daroussin wrote: pkgng is a binary package manager written from scratch for FreeBSD. Fantastic! I know it is quite too early but I already have one feature request ;) Perhaps it could be added to the TODO as a post-1.0 goal. = Generic extraction filters = Allow registration of custom filters that can alter/exclude/add? files during package extraction (installation). Examples of possible filters: - strip debug info - exclude development files (headers, static libs) - exclude unused translations - exclude documentation (all or just unknown languages) - generic glob/regex path filters - optional file groups defined in package (install time OPTIONS) ? Some sort of configuration mechanism with list of enabled filters and their options (like a list of languages to keep). Most of this can be implemented as a simple glob/regex matching but there are edge cases where packages have some non-standard layout or have to keep certain file in which case a package metadata should contain a list of exclusions/additions from/to above categories. Package manager should register only actually installed files but list of alterations should be also kept somewhere in database. What do you think ? ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Sat, 26 Mar 2011 10:22:50 +, Baptiste Daroussin wrote: This can still be discussed but I don't really like the idea that users may alter packages an installation/extraction time, that would lead to lots of potential buggy installation and report. That's why list of alterations have to be recorded and relevant tools would mark such packages appropriately. Using filters would be considered unsupported (unless maintainer of particular port/package says otherwise). It's no different than doing unsupported things right now, just giving user more tools. Besides, examples mentioned by me like removing docs and unused translations are rather safe and save significant amount of disk space. If user aren't happy with the packaging, they can poke the maintainer, send PR, patch etc. That's not possible unless user is willing to build packages himself. Actually I would rather not have build time options for things that can just as well be performed during installation. Hacking makefiles to implement NOPORTDOCS is quite more complicated than setting a glob pattern. There is also one very important use case I didn't mention before. Such filters could serve as a hooking point for configuration management system. It makes it possible to capture config files as they are installed and perform backups, merges, check-in to vcs etc. 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 ___ 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
How to uninstall pkgng
I've made a mistake of installing pkgng on 9.0-amd64 but since there is no up-to-date repository I want to remove it. What would be the correct procedure to achieve that ? Invoking `pkg delete -a` still leaves some files including /usr/sbin/pkg. ___ 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: How to uninstall pkgng
On Sat, Jun 9, 2012 at 8:23 PM, Jason Hellenthal jhellent...@dataix.net wrote: On Sat, Jun 09, 2012 at 07:03:23PM +0100, Matthew Seaman wrote: On 09/06/2012 18:46, Marcin Wisnicki wrote: I've made a mistake of installing pkgng on 9.0-amd64 but since there is no up-to-date repository I want to remove it. What would be the correct procedure to achieve that ? Invoking `pkg delete -a` still leaves some files including /usr/sbin/pkg. Not easy. You'ld have to delete the pkg port, undo any additional configuration you may have added to eg. /etc/make.conf (ie. remove WITH_PKGNG settings), undo any patches to portmaster (if you're using that) and then reinstall all your ports using the original package tools to rebuild /var/db/pkg/ contents. /usr/sbin/pkg is part of base nowadays. You don't want to delete that. So I guess that if I have empty /usr/local, no make.conf and no /var/db/pkg/local.sqlite then I'm fine ? When was pkgng made part of base ? It seems to be a simple wrapper/bootstrapper (see src/usr.sbin/pkg) that just downloads real thing. /usr/sbin/pkg would be from pkgng if you are using it to delete itself then the problem you are experiencing is the file is busy at the time of deletion. Try pkg_delete instead ? It have deleted itself just fine. -- - (2^(N-1)) ___ 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: How to uninstall pkgng
On Sat, 09 Jun 2012 19:56:56 +0200, Julien Laffaye wrote: On 6/9/2012 7:46 PM, Marcin Wisnicki wrote: I've made a mistake of installing pkgng on 9.0-amd64 but since there is no up-to-date repository I want to remove it. Have you looked at http://pkgbeta.freebsd.org/freebsd-9-amd64/latest/ ? Yes, it was 3 weeks behind -i386 at the time. ___ 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
