Re: pkg 1.5.0 is out
2015-07-01 13:38 GMT+02:00 Baptiste Daroussin : > > On Wed, Jul 01, 2015 at 01:36:14PM +0200, Hans Petter Selasky wrote: > > On 04/21/15 12:34, Slawa Olhovchenkov wrote: > > > On Tue, Apr 14, 2015 at 10:05:00PM +0200, Baptiste Daroussin wrote: > > > > > >> Hi all, > > >> > > >> Final pkg 1.5.0 has been released. > > > > > > > Hi, > > > > Is there a way the external SAT solver functionality can be memory > > optimised? When trying to use this feature having +750 packages > > installed, the memory usage starts growing and growing beyond 4GBytes > > until PKG segfaults, even before the CNF export has started. > > > > env SAT_SOLVER=mysolver pkg upgrade > > Probably, but given the little amount of time pkg developers has we will > greatly > appreciate patches :) > > AKA this would be greatly appreciated, but very low on the priority list :( > > Best regards, > Bapt Hijacking this, I managed to mess up my local pkg repo somehow. I build my own set of packages, and typically do pkg upgrade on the clients. This time, I tried pkg upgrade -F, which went and downloaded everything and that's fine. But now when I run "pkg upgrade" it claims everything is already updated? root@coyote:~# pkg --version 1.5.4 root@coyote:~# pkg upgrade Updating acme repository catalogue... acme repository is up-to-date. All repositories are up-to-date. Checking for upgrades (68 candidates): 100% Processing candidates (68 candidates): 100% Checking integrity... done (0 conflicting) Your packages are up to date. So let's try brute forcing this: root@coyote:~# pkg install `pkg info -aqo` Updating acme repository catalogue... acme repository is up-to-date. All repositories are up-to-date. databases/db48 has no direct installation candidates, change it to db5? [Y/n]: Y Assertion failed: (0), function pkg_jobs_try_remote_candidate, file pkg_jobs.c, line 821. Child process pid=60776 terminated abnormally: Abort trap Exit 250 Using more force: root@coyote:~# pkg upgrade -f db48 Updating acme repository catalogue... acme repository is up-to-date. All repositories are up-to-date. db48 has no direct installation candidates, change it to db5? [Y/n]: y pkg: sqlite error while executing UPDATE packages SET name=?1 WHERE name=?2; in file pkg_jobs.c:1658: UNIQUE constraint failed: packages.name The following 1 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: db5: 4.8.30.0_2 -> 5.3.28_2 The process will require 37 MiB more space. 12 MiB to be downloaded. Proceed with this action? [y/N]: y Fetching db5-5.3.28_2.txz: 100% 12 MiB 6.4MB/s00:02 Checking integrity...Assertion failed: (strcmp(uid, p->uid) != 0), function pkg_conflicts_check_local_path, file pkg_jobs_conflicts.c, line 368. Child process pid=60922 terminated abnormally: Abort trap Exit 250 the -debug output has nothing of interest that I can see. What's up? ___ 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: ports repository exporting to github?
Sorry for the delayed response, feel free to contact me directly whenever this happens, I'm slow to read all the mailinglists. For the record, there was a problem with the jail that this converter runs in, then we decided to move it to a newer machine altogether and that resulted in a couple more problems. If someone wants to setup blackbox monitoring for github "staleness", please get in contact with me, thanks! Uli On Wed, 2013-04-24 at 12:30:05 +0900, Koichiro IWAO wrote: > Anyway, github repository is up to date again now. Thanks! > > 2013-04-23 10:49 に Koichiro IWAO さんは書きました: > > official mirrors for ports repository on github hasn't been updated > > for a few days. > > Does FreeBSD project quit to provide mirrors on github? or suspended > > temporarily? > > -- > `whois vmeta.jp | nkf -w` > meta > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: CURRENT: Changes in lib/msun/math.h make ports to fail
On Fri, 2013-07-12 at 09:02:31 +0200, O. Hartmann wrote:
>
> Updating CURRENT from r253216 to r253252 triggers an updating of
> several ports to fail, namely, for instance,
>
> www/firefox
> graphiks/webkit-gtk2
> deskuitls/fbreader
> graphics/gdal
>
> The error is in all ports when compiled with CLANG 3.3 -std=c++11
> -stdlib=libc++ similar, routing to math.h. I will show the error for
> www/firefox:
>
> [...]
> In file included from ./../../dist/include/mozilla/MathAlgorithms.h:15:
> /usr/include/c++/4.2/cmath:468:44: error: __builtin_types_compatible_p
> is not valid in C++ __capture_fpclassify(_Tp __f) { return
> fpclassify(__f); } ^~~
> /usr/include/math.h:104:2: note: expanded from macro 'fpclassify'
> __fp_type_select(x, __fpclassifyf, __fpclassifyd, __fpclassifyl)
> ^~~~
> /usr/include/math.h:91:2: note: expanded from macro '__fp_type_select'
> __builtin_types_compatible_p(__typeof(x), long double),
> ld(x),
>
>
> [...]
>
> I was wondering why /usr/include/c++/4.2/cmath gets included and not
> the header provided for CLANG. I guess this is a typo/bug. I did do dig
> deeper into it.
>
> Hope someone can fix this.
It also breaks a simple buildworld. Coverity Scan broke like this:
===> gnu/lib/libstdc++ (all)
c++ -O2 -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H
-I/data/src/freebsd-head/gnu/lib/libstdc++
-I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++
-I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/gcc -I/data/src/fre
c++ -O2 -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H
-I/data/src/freebsd-head/gnu/lib/libstdc++
-I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++
-I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/gcc -I/data/src/fre
c++ -O2 -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H
-I/data/src/freebsd-head/gnu/lib/libstdc++
-I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++
-I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/gcc -I/data/src/fre
c++ -O2 -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H
-I/data/src/freebsd-head/gnu/lib/libstdc++
-I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++
-I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/gcc -I/data/src/fre
c++ -O2 -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H
-I/data/src/freebsd-head/gnu/lib/libstdc++
-I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++
-I/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/gcc -I/data/src/fre
In file included from
/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/libstdc++/src/compatibility.cc:53:
/usr/obj/data/src/freebsd-head/tmp/usr/include/c++/4.2/cmath:468:44: error:
__builtin_types_compatible_p is not valid in C++
__capture_fpclassify(_Tp __f) { return fpclassify(__f); }
^~~
/usr/obj/data/src/freebsd-head/tmp/usr/include/math.h:104:2: note: expanded
from macro 'fpclassify'
__fp_type_select(x, __fpclassifyf, __fpclassifyd, __fpclassifyl)
^~~~
/usr/obj/data/src/freebsd-head/tmp/usr/include/math.h:91:2: note: expanded from
macro '__fp_type_select'
__builtin_types_compatible_p(__typeof(x), long double), ld(x),\
^~
In file included from
/data/src/freebsd-head/gnu/lib/libstdc++/../../../contrib/libstdc++/src/compatibility.cc:53:
/usr/obj/data/src/freebsd-head/tmp/usr/include/c++/4.2/cmath:472:42: error:
__builtin_types_compatible_p is not valid in C++
__capture_isfinite(_Tp __f) { return isfinite(__f); }
^
/usr/obj/data/src/freebsd-head/tmp/usr/include/math.h:105:21: note: expanded
from macro 'isfinite'
#define isfinite(x) __fp_type_select(x, __isfinitef, __isfinite, __isfinitel)
^
/usr/obj/data/src/freebsd-head/tmp/usr/include/math.h:91:2: note: expanded from
macro '__fp_type_select'
__builtin_types_compatible_p(__typeof(x), long double), ld(x),\
^~
and many more.
___
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: [HEADSUP] Staging, packaging and more
2013/10/4 Bryan Drewery : > On Fri, Oct 04, 2013 at 09:01:58AM +0200, Baptiste Daroussin wrote: >> On Fri, Oct 04, 2013 at 08:57:53AM +0200, Erwin Lansing wrote: >> > On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin wrote: >> > > > > > > >> > > > > > > Please no devel packages. >> > > > > > >> > > > > > Seconded. >> > > > > >> > > > > What's wrong with devel packages? >> > > > >> > > > It complicates things for developers and custom software on >> > > > FreeBSD. The typical situation that I see on most Linux platforms is a >> > > > lot of confusion by people, why their custom software XYZ does not >> > > > properly build - the most common answer: they forgot to install a >> > > > tremendous amount of dev packages, containing headers, build tools and >> > > > whatnot. >> > > > On FreeBSD, you can rely on the fact that if you installed e.g. libGL, >> > > > you can start building your own GL applications without the need to >> > > > install several libGL-dev, libX11-dev, ... packages first. >> > > > This is something, which I personally see as a big plus of the FreeBSD >> > > > ports system and which makes FreeBSD attractive as a development >> > > > platform. >> > > > >> > > >> > > On the other ends, that makes the package fat for embedded systems, that >> > > also >> > > makes some arbitrary runtime conflicts between packages (because they >> > > both >> > > provide the same symlink on the .so, while we could live with 2 version >> > > at >> > > runtime), that leads to tons of potential issue while building locally, >> > > and >> > > that makes having sometime insane issues with dependency tracking. Why >> > > having >> > > .a, .la, .h etc in production servers? It could greatly reduce PBI size, >> > > etc. >> > > >> > > Personnaly I do have no strong opinion in one or another direction. >> > > Should we be >> > > nicer with developers? with end users? with embedded world? That is the >> > > question >> > > to face to decide if -devel packages is where we want to go or not. >> > > >> > >> > If we chose to go down that path, at least we should chose a different >> > name as we've used the -devel suffix for many years for developmental >> > versions. >> > >> > I must agree that it is one of the things high on my list of things that >> > irritate me with several Linux distributions but I can see the point for >> > for embedded systems as well. But can't we have both? Create three >> > packages, a default full package and split packages of -bin, -lib, >> > and even -doc. My first though twas to make the full package a >> > meta-package that would install the split packages in the background, >> > but that would probably be confusing for users at the end of the day, so >> > rather just have it be a real package. >> > >> I do like that idea very much, and it is easily doable with stage :) > > +1 to splitting packages for embedded usage. -1 for the split, as it will not fix anybody's problem. On regular machines, disk space is cheap and having to install more packages is just annoying to users. Think of the time wasted that people are told to apt-get libfoo-dev before they can build anything from github, or similar. If you actually *are* space constricted on your tiny embedded machine, what the fuck are you doing with the sqlite database and all the metadata about ports/packages anyway? Just rm /usr/include and /usr/share/doc, /usr/share/man, etc. when building your disk image. But you are doing that already anyway, so this solves no actual problem for you. My two cents Uli ___ 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: [HEADSUP] Staging, packaging and more
2013/10/7 Bryan Drewery : > On 10/6/2013 9:16 PM, Dewayne Geraghty wrote: >>> -Original Message- >>> From: owner-freebsd-po...@freebsd.org >>> [mailto:owner-freebsd-po...@freebsd.org] On Behalf Of Ulrich Spörlein >>> Sent: Sunday, 6 October 2013 11:20 PM >>> To: Bryan Drewery >>> Cc: po...@freebsd.org; Baptiste Daroussin; Fernando Apesteguía >>> Subject: Re: [HEADSUP] Staging, packaging and more >>> Importance: Low >>> >>> 2013/10/4 Bryan Drewery : >>>> On Fri, Oct 04, 2013 at 09:01:58AM +0200, Baptiste Daroussin wrote: >>>>> On Fri, Oct 04, 2013 at 08:57:53AM +0200, Erwin Lansing wrote: >>>>>> On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste >>> Daroussin wrote: >>>>>>>>>>> >>>>>>>>>>> Please no devel packages. >>>>>>>>>> >>>>>>>>>> Seconded. >>>>>>>>> >>>>>>>>> What's wrong with devel packages? >>>>>>>> >>>>>>>> It complicates things for developers and custom software on >>>>>>>> FreeBSD. The typical situation that I see on most Linux >>>>>>>> platforms is a lot of confusion by people, why their custom >>>>>>>> software XYZ does not properly build - the most >>> common answer: >>>>>>>> they forgot to install a tremendous amount of dev packages, >>>>>>>> containing headers, build tools and whatnot. >>>>>>>> On FreeBSD, you can rely on the fact that if you >>> installed e.g. >>>>>>>> libGL, you can start building your own GL >>> applications without >>>>>>>> the need to install several libGL-dev, libX11-dev, >>> ... packages first. >>>>>>>> This is something, which I personally see as a big >>> plus of the >>>>>>>> FreeBSD ports system and which makes FreeBSD >>> attractive as a development platform. >>>>>>>> >>>>>>> >>>>>>> On the other ends, that makes the package fat for embedded >>>>>>> systems, that also makes some arbitrary runtime >>> conflicts between >>>>>>> packages (because they both provide the same symlink >>> on the .so, >>>>>>> while we could live with 2 version at runtime), that leads to >>>>>>> tons of potential issue while building locally, and that makes >>>>>>> having sometime insane issues with dependency >>> tracking. Why having .a, .la, .h etc in production servers? >>> It could greatly reduce PBI size, etc. >>>>>>> >>>>>>> Personnaly I do have no strong opinion in one or another >>>>>>> direction. Should we be nicer with developers? with end users? >>>>>>> with embedded world? That is the question to face to >>> decide if -devel packages is where we want to go or not. >>>>>>> >>>>>> >>>>>> If we chose to go down that path, at least we should chose a >>>>>> different name as we've used the -devel suffix for many >>> years for >>>>>> developmental versions. >>>>>> >>>>>> I must agree that it is one of the things high on my >>> list of things >>>>>> that irritate me with several Linux distributions but I >>> can see the >>>>>> point for for embedded systems as well. But can't we >>> have both? >>>>>> Create three packages, a default full package and split >>> packages of >>>>>> -bin, -lib, and even -doc. My first though twas to make >>> the full >>>>>> package a meta-package that would install the split >>> packages in the >>>>>> background, but that would probably be confusing for >>> users at the >>>>>> end of the day, so rather just have it be a real package. >>>>>> >>>>> I do like that idea very much, and it is easily doable >>> with stage :) >>>> >>>> +1 to splitting packages for embedded usage. >>> >>> -1 for the split, as it will not fix anybody's problem. >>> >>> On regular machines, disk space is cheap and having to >>> install more packages is just annoying to us
Re: [HEADSUP] Staging, packaging and more
2013/10/8 Baptiste Daroussin : > On Sun, Oct 06, 2013 at 02:20:21PM +0200, Ulrich Spörlein wrote: >> 2013/10/4 Bryan Drewery : >> > On Fri, Oct 04, 2013 at 09:01:58AM +0200, Baptiste Daroussin wrote: >> >> On Fri, Oct 04, 2013 at 08:57:53AM +0200, Erwin Lansing wrote: >> >> > On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin wrote: >> >> > > > > > > >> >> > > > > > > Please no devel packages. >> >> > > > > > >> >> > > > > > Seconded. >> >> > > > > >> >> > > > > What's wrong with devel packages? >> >> > > > >> >> > > > It complicates things for developers and custom software on >> >> > > > FreeBSD. The typical situation that I see on most Linux platforms >> >> > > > is a >> >> > > > lot of confusion by people, why their custom software XYZ does not >> >> > > > properly build - the most common answer: they forgot to install a >> >> > > > tremendous amount of dev packages, containing headers, build tools >> >> > > > and >> >> > > > whatnot. >> >> > > > On FreeBSD, you can rely on the fact that if you installed e.g. >> >> > > > libGL, >> >> > > > you can start building your own GL applications without the need to >> >> > > > install several libGL-dev, libX11-dev, ... packages first. >> >> > > > This is something, which I personally see as a big plus of the >> >> > > > FreeBSD >> >> > > > ports system and which makes FreeBSD attractive as a development >> >> > > > platform. >> >> > > > >> >> > > >> >> > > On the other ends, that makes the package fat for embedded systems, >> >> > > that also >> >> > > makes some arbitrary runtime conflicts between packages (because they >> >> > > both >> >> > > provide the same symlink on the .so, while we could live with 2 >> >> > > version at >> >> > > runtime), that leads to tons of potential issue while building >> >> > > locally, and >> >> > > that makes having sometime insane issues with dependency tracking. >> >> > > Why having >> >> > > .a, .la, .h etc in production servers? It could greatly reduce PBI >> >> > > size, etc. >> >> > > >> >> > > Personnaly I do have no strong opinion in one or another direction. >> >> > > Should we be >> >> > > nicer with developers? with end users? with embedded world? That is >> >> > > the question >> >> > > to face to decide if -devel packages is where we want to go or not. >> >> > > >> >> > >> >> > If we chose to go down that path, at least we should chose a different >> >> > name as we've used the -devel suffix for many years for developmental >> >> > versions. >> >> > >> >> > I must agree that it is one of the things high on my list of things that >> >> > irritate me with several Linux distributions but I can see the point for >> >> > for embedded systems as well. But can't we have both? Create three >> >> > packages, a default full package and split packages of -bin, -lib, >> >> > and even -doc. My first though twas to make the full package a >> >> > meta-package that would install the split packages in the background, >> >> > but that would probably be confusing for users at the end of the day, so >> >> > rather just have it be a real package. >> >> > >> >> I do like that idea very much, and it is easily doable with stage :) >> > >> > +1 to splitting packages for embedded usage. >> >> -1 for the split, as it will not fix anybody's problem. >> >> On regular machines, disk space is cheap and having to install more >> packages is just annoying to users. Think of the time wasted that >> people are told to apt-get libfoo-dev before they can build anything >> from github, or similar. >> >> If you actually *are* space constricted on your tiny embedded machine, >> what the fuck are you doing with the sqlite database and all the >> metadata about ports/pac
multimedia/xbmc's default dependency on lame
Hey Mickael, Baptiste, multimedia/xbmc is currently broken for me on 10.x (worked fine about 1-2 months ago) and I wanted to check the build cluster to see if the problem is on my end. The problem? multimedia/xbmc is skipped because of the default dependency on lame (and that is restricted). So this http://beefy1.isc.freebsd.org/bulk/head-i386-default/2013-10-17_19h54m49s/ will not show me if xbmc builds for other people. Mickael, is the default dependency on lame required? It means we'll never ship a pre-built port for it .. Baptiste, is it possible to still build these packages and packages that depend on them, but just not publish/distribute them? Thanks! UIi ___ 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: multimedia/xbmc's default dependency on lame
I'll try and send a patch for this soon. In the meantime, any idea why this fails on 10.x? gmake[2]: Entering directory `/usr/ports/multimedia/xbmc/work/xbmc-12.2/xbmc/cores/dvdplayer/DVDCodecs/Video' CPP xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoCodecFFmpeg.o CPP xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoCodecLibMpeg2.o CPP xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoPPFFmpeg.o CPP xbmc/cores/dvdplayer/DVDCodecs/Video/VAAPI.o VAAPI.cpp:77:10: error: unknown type name 'weak_ptr' static weak_ptr display_global; ^ VAAPI.cpp:77:18: error: expected unqualified-id static weak_ptr display_global; ^ VAAPI.cpp:79:23: error: use of undeclared identifier 'display_global' CDisplayPtr display(display_global.lock()); ^ VAAPI.cpp:120:3: error: use of undeclared identifier 'display_global' display_global = display; ^ VAAPI.cpp:233:25: warning: cast to 'unsigned char *' from smaller integer type 'VASurfaceID' (aka 'unsigned int') [-Wint-to-pointer-cast] pic->data[3]= (uint8_t*)surface; ^ 1 warning and 4 errors generated. I have boost installed and it has the definitions for weak_ptr, so I'm not sure what's going on here. gmake(1) tries to compile like this: root@coyote:/usr/ports/multimedia/xbmc/work/xbmc-12.2/xbmc/cores/dvdplayer/DVDCodecs/Video# gmake -n rm -f VAAPI.o echo "CPP xbmc/cores/dvdplayer/DVDCodecs/Video/VAAPI.o"; c++ -MF VAAPI.d -MD -c -O2 -O2 -pipe -fno-strict-aliasing -fPIC -DPIC -D_REENTRANT -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DNDEBUG=1 -I/usr/local/include -DTARGET_POSIX -DTARGET_FREEBSD -D_LINUX -D_FILE_DEFINED -D__STDC_CONSTANT_MACROS -DBIN_INSTALL_PATH="\"/usr/local/lib/xbmc\"" -DINSTALL_PATH="\"/usr/local/share/xbmc\"" -DHAS_SDL_JOYSTICK -D'GIT_REV="Unknown"' -DHAVE_CONFIG_H -I/usr/ports/multimedia/xbmc/work/xbmc-12.2/xbmc/cores/dvdplayer -I/usr/ports/multimedia/xbmc/work/xbmc-12.2/lib -I/usr/ports/multimedia/xbmc/work/xbmc-12.2/xbmc -DDBUS_API_SUBJECT_TO_CHANGE -D_GNU_SOURCE=1 -D_REENTRANT -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include/SDL -I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include -I/usr/local/include/freetype2 -I/usr/local/include/fribidi -I/usr/local/include/hal -I/usr/local/include/libcec -I/usr/local/include/libpng15 -I/usr/local/include/taglib -I/usr/ports/multimedia/xbmc/work/xbmc-12.2 -I/usr/ports/multimedia/xbmc/work/xbmc-12.2/lib/ffmpeg -I/usr/ports/multimedia/xbmc/work/xbmc-12.2/xbmc/linux -I/usr/ports/multimedia/xbmc/work/xbmc-12.2/xbmc/cores/dvdplayer VAAPI.cpp -o VAAPI.o \ && cp VAAPI.d VAAPI.P && sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$//' -e '/^$/ d' -e 's/$/ :/' < VAAPI.d >> VAAPI.P && rm -f VAAPI.d || ( rm -f VAAPI.P VAAPI.o && exit 1 ) echo "AR xbmc/cores/dvdplayer/DVDCodecs/Video/Video.a"; ar crus Video.a DVDVideoCodecFFmpeg.o DVDVideoCodecLibMpeg2.o DVDVideoPPFFmpeg.o VAAPI.o ... Oh, then I tried being explicit about that namespace, et voila! It compiles fine. See attached patch. But then the pkg-plist somehow doesn't match any longer :( ===> Installing for xbmc-12.2_1 ===> Checking if multimedia/xbmc already installed ===> Registering installation for xbmc-12.2_1 pkg-static: lstat(/usr/ports/multimedia/xbmc/work/stage/usr/local/lib/xbmc/system/libcmyth-x86_64-freebsd.so): No such file or directory *** Error code 74 Sigh. The generated Makefile has ifeq (0,1) LIB_DIRS += lib/cmyth CMYTH=cmyth endif so it's unlikely I'll get it built, config.log has nothing about this and I have no idea what that java thing at the start of the build tries to do. Now I only need to figure out why all the unicode conversions are broken with that new internal iconv support in 10.x :( Cheers, Uli 2013/10/19 Mickaël Maillot : > You can remove LAME from default options. > it's just used for MP3 encoding from CD, not really used by people. > > > 2013/10/18 Ulrich Spörlein >> >> Hey Mickael, Baptiste, >> >> multimedia/xbmc is currently broken for me on 10.x (worked fine about >> 1-2 months ago) and I wanted to check the build cluster to see if the >> problem is on my end. The problem? multimedia/xbmc is skipped because >> of the default dependency on lame (and that is restricted). >> >> So this >> http://beefy1.isc.freebsd.org/bulk/head-i386-default/2013-10-17_19h54m49s/ >> will not show me if xbmc builds for other people. >> >> Mickael, is the default dependency on lame required? It means we'll >> never ship a pre-built port for it .. >> >> Baptiste, is it possible to still build these packages and packages >> that depend on them, but just not publish/distribute them? >> >> Thanks! >> UIi > > ___ 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"
iconv in base breaks multiple ports
Hey all, ever since that iconv thing replaced the ports version, I run into trouble with several ports that I have installed on a -CURRENT (now stable/10 system). These are not compile-time errors, but crashes or limited functionality where I blame iconv :) 1. www/newsbeuter crashes during startup, somewhere in the stfl code that deals with wide char functions. 2. devel/git: when using git-svn, it'll segfault in the perl code, not sure how to get a backtrace here as gdb's follow-fork doesn't quite work. 3. multimedia/xbmc is no longer able to decode unicode filenames and other things are broken. It spews an endless stream of 19:36:00 T:34594644992 ERROR: convert_checked iconv_open() failed from WCHAR_T to UTF-8, errno=22(Invalid argument) 19:36:00 T:34594644992 ERROR: convert_checked iconv_open() failed from UTF-8 to WCHAR_T, errno=22(Invalid argument) 19:37:00 T:34594644992 ERROR: Previous line repeats 9656 times. Is my system hexed? I've rebuilt the ports/packages a dozen times now. Am I seeing ghosts? Thanks, Uli ___ 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: iconv in base breaks multiple ports
On Sun, 2013-10-20 at 23:20:10 +0200, Tijl Coosemans wrote: > On Sun, 20 Oct 2013 20:27:23 +0200 Ulrich Spörlein wrote: > > ever since that iconv thing replaced the ports version, I run into > > trouble with several ports that I have installed on a -CURRENT (now > > stable/10 system). > > > > These are not compile-time errors, but crashes or limited functionality > > where I blame iconv :) > > > > 1. www/newsbeuter crashes during startup, somewhere in the stfl code > > that deals with wide char functions. > > > > 2. devel/git: when using git-svn, it'll segfault in the perl code, not > > sure how to get a backtrace here as gdb's follow-fork doesn't quite > > work. > > > > 3. multimedia/xbmc is no longer able to decode unicode filenames and > > other things are broken. It spews an endless stream of > > 19:36:00 T:34594644992 ERROR: convert_checked iconv_open() failed from > > WCHAR_T to UTF-8, errno=22(Invalid argument) > > 19:36:00 T:34594644992 ERROR: convert_checked iconv_open() failed from > > UTF-8 to WCHAR_T, errno=22(Invalid argument) > > 19:37:00 T:34594644992 ERROR: Previous line repeats 9656 times. > > > > Is my system hexed? I've rebuilt the ports/packages a dozen times now. > > Am I seeing ghosts? > > Can you try the attached patch? It includes the one from > http://www.freebsd.org/cgi/query-pr.cgi?pr=182994 Sure, I fail to see however how this locking could cause the problems with crashes and failures to convert strings. I've rebuild libc with this and it does nothing for the newsbeuter or perl crashes :( Thanks Uli ___ 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: iconv in base breaks multiple ports
On Mon, 2013-10-21 at 13:18:55 +0200, Tilman Keskinöz wrote: > hi Ulrich, > > * Ulrich Spörlein [Sun, 20 Oct 2013 20:27:23 +0200]: > > ever since that iconv thing replaced the ports version, I run into > > trouble with several ports that I have installed on a -CURRENT (now > > stable/10 system). > > > > These are not compile-time errors, but crashes or limited functionality > > where I blame iconv :) > > > > > > 1. www/newsbeuter crashes during startup, somewhere in the stfl code > > that deals with wide char functions. > > > > > Is my system hexed? I've rebuilt the ports/packages a dozen times now. > > Am I seeing ghosts? > > > I don't run Current, but according to the pkg-fallout mails i am > receiving, newsbeuter shouldn't even compile on CURRENT. Maybe there are > some stale files on your system? > > There is also an update in the PR system, you might want to try, > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/182896 Right, I had to set USE_GCC=any and muck with -liconv flags of course to get it to build. Lemme whip up a proper patch though, I got it to build fine on -CURRENT with clang now, doesn't fix the crash though :(. Here's a build with USE_GCC=any: https://redports.org/buildarchive/20131021191400-36506/ Here is a more proper fix: https://redports.org/buildarchive/20131021203201-51496/ Cheers, Uli ___ 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: iconv in base breaks multiple ports
2013/10/22 Tijl Coosemans : > On Mon, 21 Oct 2013 22:34:45 +0200 Ulrich Spörlein wrote: >> On Mon, 2013-10-21 at 13:18:55 +0200, Tilman Keskinöz wrote: >>> * Ulrich Spörlein [Sun, 20 Oct 2013 20:27:23 +0200]: >>>> ever since that iconv thing replaced the ports version, I run into >>>> trouble with several ports that I have installed on a -CURRENT (now >>>> stable/10 system). >>>> >>>> These are not compile-time errors, but crashes or limited functionality >>>> where I blame iconv :) >>>> >>>> 1. www/newsbeuter crashes during startup, somewhere in the stfl code >>>> that deals with wide char functions. >>>> >>>> Is my system hexed? I've rebuilt the ports/packages a dozen times now. >>>> Am I seeing ghosts? >>> >>> I don't run Current, but according to the pkg-fallout mails i am >>> receiving, newsbeuter shouldn't even compile on CURRENT. Maybe there are >>> some stale files on your system? >>> >>> There is also an update in the PR system, you might want to try, >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/182896 >> >> Right, I had to set USE_GCC=any and muck with -liconv flags of course to >> get it to build. > > Hmm, does this mean you still have libiconv installed? Because then > your crashes may be because some libraries use libc iconv and others > libiconv iconv. No no, the port just blindly links against libiconv and I had to patch that, obviously. My system is clean of any libiconv-from-ports. But as a next step, I shall now build base w/o iconv and bring back libiconv from ports to see if that fixes my issues. ttyl Uli ___ 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: iconv in base breaks multiple ports
2013/10/22 Ulrich Spörlein : > 2013/10/22 Tijl Coosemans : >> On Mon, 21 Oct 2013 22:34:45 +0200 Ulrich Spörlein wrote: >>> On Mon, 2013-10-21 at 13:18:55 +0200, Tilman Keskinöz wrote: >>>> * Ulrich Spörlein [Sun, 20 Oct 2013 20:27:23 +0200]: >>>>> ever since that iconv thing replaced the ports version, I run into >>>>> trouble with several ports that I have installed on a -CURRENT (now >>>>> stable/10 system). >>>>> >>>>> These are not compile-time errors, but crashes or limited functionality >>>>> where I blame iconv :) >>>>> >>>>> 1. www/newsbeuter crashes during startup, somewhere in the stfl code >>>>> that deals with wide char functions. >>>>> >>>>> Is my system hexed? I've rebuilt the ports/packages a dozen times now. >>>>> Am I seeing ghosts? >>>> >>>> I don't run Current, but according to the pkg-fallout mails i am >>>> receiving, newsbeuter shouldn't even compile on CURRENT. Maybe there are >>>> some stale files on your system? >>>> >>>> There is also an update in the PR system, you might want to try, >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/182896 >>> >>> Right, I had to set USE_GCC=any and muck with -liconv flags of course to >>> get it to build. >> >> Hmm, does this mean you still have libiconv installed? Because then >> your crashes may be because some libraries use libc iconv and others >> libiconv iconv. > > No no, the port just blindly links against libiconv and I had to patch > that, obviously. My system is clean of any libiconv-from-ports. > > But as a next step, I shall now build base w/o iconv and bring back > libiconv from ports to see if that fixes my issues. ... and the verdict is in. Building src w/o iconv, then re-installing converters/libiconv and rebuilding the ports fixes at least newsbeuter, I'll now let multimedia/xbmc (and requirements) rebuild over night and then prepare a patch to allow -CURRENT + libiconv for those people that like a working system. I'm also looping re@ in, as they might want to hear about showstoppers for the 10.0 release. Cheers, Uli ___ 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: iconv in base breaks multiple ports
2013/10/23 Sergio de Almeida Lenzi : > ... and the verdict is in. Building src w/o iconv, then re-installing > converters/libiconv and rebuilding the ports fixes at least > newsbeuter, I'll now let multimedia/xbmc (and requirements) rebuild > over night and then prepare a patch to allow -CURRENT + libiconv for > those people that like a working system. > > I'm also looping re@ > in, as they might want to hear about showstoppers > for the 10.0 release. > > Cheers, > Uli > > I have built a system from scratch freeBSD11 all without libiconv > because I need to test the radeonkm (everything works as expected with > accelerated video) > and than full gnome2 (about 980 packages) including libreoffice, firefox, > vlc, > mono, monodevelop, gnome-subtilles... and everything works > in the libiconv port there is a trap that prevents it from building in a > system > freeBSD10... > the only problem was: inkscape and net-snmp... but the last version of svn > works... > > > Hope clarify things for you if you need the packages I can give access > in the internet... Well, it doesn't match my experience. xbmc also seems to no longer spew thousands of errors per second now that I've rebuild it with ports' libiconv. Could you please install www/newsbeuter on your system and see if it starts up correctly? (you might need to wait for my build-fix on -CURRENT to go in). Are you actually using a locale/encoding different from 'C'? Are you using a wide encoding like UTF-8? Maybe that can narrow down the source of the problem. Cheers, Uli ___ 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: Hash changes in the freebsd-ports GitHub mirror
Sorry for seeing this message so late, here's what happened:
1. There was metadata corruption in the SVN repo that is used as the source
for the svn2git conversion, this repo is kept up-to-date using svnsync, and
it turns out svnsync does not operate atomically.
2. Someone "fixed" the corrupt SVN repos, but that means we can no longer
reproduce what is published on github <- this happened last year and we've
had this Damocles sword dangling above the repos for that long
3. bitbucket changed their permissions model and somehow this caused git to
chew up 100% cpu when doing anything inside the "src" repo (wtf?)
4. I stopped everything, fixed bitbucket ssh keys, started deleting
bitbucket branches as we're approaching the 2G limit
5. seeing that a proper repack was in order, I did a git repack on
base/ports/doc
6. ???
7. svn2git started to re-convert freebsd-ports from rev 1 (wtf wtf?)
Because (7) used the fixed repo, this should now actually be the proper 1:1
conversion from SVN ... unless there's more metadata corruption that we did
not fix. I am currently checking this with another run on a different
machine, but that machine is slower and not even half done yet.
The interesting thing to note is that:
a) obviously no one is doing the conversion in-house and found out that
they get different hashes, although this is documented on
https://wiki.freebsd.org/GitWorkflow
b) we still have the same problem for src and doc. We can *not* reproduce
the version that is published on github (different timestamps/authors on
the commit metadata)
Expect more turbulences
Uli
2016-12-02 10:40 GMT+01:00 Raphael Kubo da Costa :
> Hi all,
>
> I tried running `git pull` a few minutes ago and had a ton of conflicts.
>
> It turns out all hashes after c96fb0418e545a569b5975b4d878a30a948c29d5
> ("fix issues related with USES=fonts" from 2015-07-18, aka r392404) are
> now different in all GitHub branches.
>
> Is anyone else experiencing this? Was this change intentional?
>
___
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: [FreeBSD-Announce] FreeBSD bug tracking moves from GNATS to Bugzilla
2014-06-03 14:16 GMT+02:00 David Chisnall : > On 3 Jun 2014, at 13:09, Vitaly Magerya wrote: > > > It doesn't seem to be possible to post comments (or bugs) without > creating an account and logging in. > > That is correct. The current leaning is towards not providing such > functionality as: > > - It makes spamming easy > > - If someone can't be bothered to make an account, they are unlikely to > provide the feedback required to correctly diagnose the bug. > > I don't know that this decision is final, but it's certainly unlikely to > be high up the priority list to implement it. For FreeBSD 11, we'd like to > have an HTTP-based send-pr replacement, which will not be able to enforce a > valid email address, but which will at least request one. Although, again, > we'll have to be careful to prevent it from being used as a spam tool (send > a pr claiming to be from a different email address with a spam message and > that person gets notified) and so it will likely add the bug to a private > queue where it can be checked for spam before appearing in the main db. > Volunteers to be spam filters welcome... > > Please reconsider this. I have come up with bug reports for various projects only to find out that I'd need YET ANOTHER FRIGGING PASSWORD just to send them my bug report. In the end, the report was not send, as yes, I cannot be bothered to create another account that I'll use essentially for sending an email. I'm surely not the only one avoiding even more accounts and password. At the very least think about implementing OAuth/OpenID or whatever it's called this days. A mood point for me, as I'll need a full account, but the Project should not make reporting bugs harder than it is already ... have you considered using reCATPCHA or something to fend of at least some of the spam? Cheers and thanks for the migration!! Uli ___ 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: Any plan to fix ports git main history compatibility with old GitHub master?
On Mon, 2021-04-05 at 21:45:57 +, Brooks Davis wrote: On Mon, Apr 05, 2021 at 05:33:08PM -0300, Eric Turgeon wrote: Today when trying to sync the GhostBSD ports tree with the FreeBSD ports tree, I found out the main branch history is not compatible with the old GitHub master. Any plan to migrate to main with hold git history as we had with freebsd-src? The main branch will contain a commit which is identical to the last commit of the old master branch (except for the hash). If the GhostBSD repo is merged up to that point, you can then merge the matching commit from main and proceed with using main as the source for future merges. If you have outstanding WIPs the process of updating them to the new history should be about the same as the one for source: https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/articles/committers-guide/_index.adoc#562-migrating-from-github-fork This special commit was only provided for the `src` repo and will not be provided for the ports repo. It is fairly trivial to do this yourself and there's documentation around this here: https://github.com/freebsd/git_conv/wiki/Migrating-merge-based-project-from-legacy-git-tree It should roughly go like this: 1. add both remotes and fetch from them 2. merge into old master as usual (this is e010feae47ac7fda1354fb3b12290a5ee42ef590) 3. merge into main at the same instant in time, using your own tree: git merge -s ours --allow-unrelated-histories 3cc0c0d66a065554459bd2f9b4f80cc07426464a 4. now merge into the new origin/main from now on and forevermore hth, please let me know if you need further help! Uli ___ 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: [HEADSUP] New framework options aka optionng
On Wed, 2012-05-30 at 23:48:03 +0200, Baptiste Daroussin wrote: > On Wed, May 30, 2012 at 05:38:26PM -0400, Michael Scheidell wrote: > > > > > > On 5/30/12 5:33 PM, Kevin Oberman wrote: > > >> would only cause confusion. > > > I'll go one further and suggest that the vast majority who don't want > > > these features are building specialized systems and they know very > > > well what they are doing. A global setting for these would be > > > desirable, though, as someone building a specialized distribution for, > > > say, an embedded system, will want no docs or examples for any port. I > > > suspect it is ALMOST always an all or nothing issue, not per port. > > > -- > > for our commercial systems, we don't install man, docs, examples. > > and, I would suspect that I would be a little peeved if next time I > > recompile all the ports, I had to stop and hit 'WITHOUT_PORTDOCS, > > WITHOUT_PORTEXAMPLES' on every port. > > > > Upward compatibility folks, if at all possible. You are not guaranteed that all ports implement NOPORTDOCS, so what do you do with those? If folks really are that allergic against docs, then they need to do rm -rf /usr/local/share/doc anyway. I don't quite get why people think WITHOUT_NLS and NO_PORTDOCS are useful or even worth the burden they put on the porters and maintainers. > echo "OPTIONS_UNSET+= DOCS" >> /etc/make.conf > echo "NO_DIALOG=yes" >> /etc/make.conf > > having NOPORTSDOC and NOPORTEXAMPLES, KNOBS and OPTIONS has been a constant > demand by lots of users that is why I wrote it that way and merged NOPORTDOCS > and NOPORTEXAMPLES and WITHOUT_NLS btw to optionsng, I may be wrong, if that > is > the case please speak loudly, saying why, what would be best what do you > expect. > > Keep in mind that currently lots of ports already define OPTIONS only > concerning > documentation, also note that some DOCS might bring some heavy depencies like > doxygen. That's about the only justifiable use-case IMHO. There should be a DOC_DEPENDS that pulls in ports necessary for building documentation (if required) and perhaps (perhaps!) a knob to not pull that in and install documentation. A better solution, saving hundreds of cpu-hours world-wide, would be to persuade upstream to include fully rendered documentation (HOW HARD CAN IT BE?). The fall-back could be to have the maintainer provide the set of documentation. It will usually not change between distfile releases, so re-rolling the documentation could be part of the port update that the maintainer does. > Last but not least, by chance (for once I'm happy with chance :)) you do not > have to add DOCS or EXAMPLES to OPTIONS_DEFINE to be able to use them in your > ports! So you can use it just like NOPORTDOCS and NOPORTEXAMPLES use to work. > IE without and make config needed. > > that mean a single way to define/check for it but 2 different kind of options. > > Not sure this mail is clear :) I hate WITHOUT_NLS and NO_PORTDOCS with a passion. They work for 80% of the ports you are likely to install, so they are not a safe way to escape docs or NLS. Why bother? Seriously, could someone give me a usecase for them? Cheers, Uli ___ 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: git repositories of ports broken?
On Sat, 2012-06-02 at 17:27:16 -0400, Daniel Hagerty wrote: > Most of the git based repositories(*) I know of for the ports > collection all seem to stop around March 1st, 2012. The one at > git://git.freebsd.org/freebsd-ports stops in 1996! > > Have these been desupported, or is something broken? > > (*) > git://gitorious.org/freebsd/freebsd-ports.git > git://github.com/freebsd/freebsd-ports.git > git://git.freebsd.your.org/freebsd-ports They will come back, once ports has switched over to SVN. The conversions from CVS are all sorts of broken and shouldn't be used. hth Uli ___ 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: (semi-)official git mirror of ports svn repo?
On Tue, 2012-07-24 at 00:05:49 +0300, Andriy Gapon wrote: > > Do we have a (semi-)official git mirror of the new ports _svn_ repo? > Something either FreeBSD hosted/managed or maintained by prominent ports > developers on github/gitorious/elsewhere? > > I looked at gitorious, github and freebsd.your.org and only this github > repository seems to be active: > https://github.com/freebsd/freebsd-ports/commits/master > But note sure if it based off svn. Yes, it's to become the official one, once I get my act together. It's still missing the git-notes, but that will be fixed later and doesn't impact anything, really. So please use git://github.com/freebsd/freebsd-ports.git or the source as a fallback git://git.freebsd.org/freebsd-ports.git Cheers, Uli ___ 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: General usefulness of option descriptions
On Sun, 2012-10-07 at 15:24:28 +0200, Michael Gmelin wrote: > Hi, > > This probably has been discussed before, but I think in many cases > using the default descriptions of OptionsNG is more harm than good. > > I converted security/libpreludedb to OptionsNG yesterday and > left in most of the descriptions and therefore overrode them. I did > that for a good reason, since I believe that the description of the > option should be more than just repeating the option name. > Unfortunately the portmgr in charge disagreed and removed all > description overrides, figuring that I must have forgotten to remove > them. That's why I raise this topic on the list - I feel like we're > using a lot of information if we converting ports like this. > > In this specific example this means: > > Before: > PERL=off: Include Perl bindings > PYTHON=off: Include Python bindings > MYSQL=on: Use MySQL backend > PGSQL=off: Use PostgreSQL backend > SQLITE=off: Use SQLite backend > > Afterwards: > DOCS=on: Build and/or install documentation > MYSQL=on: MySQL database > PERL=off: Perl scripting language > PGSQL=off: PostgreSQL database > PYTHON=off: Python bindings > SQLITE=off: SQLite database Just picking on these couple of examples, pretty much all of them are worse afterwards. Does PERL for this port mean that it adds perl bindings or perl scripting support? PYTHON wasn't changed. It really is worse afterwards ... hth Uli ___ 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: bump of PORTREVISION mandatory?
On Thu, 27.01.2011 at 13:02:30 -0500, Eitan Adler wrote: > > Do I need to bump PORTREVISION before I submit the updated port? Is > > that mandatory? > > > > PORTREVISION should only be changed if you need the users of a port to > recompile the port. > Typos and documentation typically don't require such a change. PORTREVISION should be bumped, whenever the resulting binary package changes (different checksums, etc.). As pkg-descr is part of the package, yes this should have a PORTREVISION bump. OTOH this will "force" all ports-user to rebuild the port, which surely is a waste for the change to a desc. file that nobody looks at anyway. So, choose wisely. Uli ___ 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: Fwd: prelminary analysis of the gmake3.82 -exp run
On Sat, 12.03.2011 at 19:44:55 -0600, Mark Linimon wrote: > A greatly expanded version of my original message is now at: > > http://wiki.freebsd.org/GmakeTODO > > Note: the second run is currently paused while we are working on hardware. Augmented with a crude estimate of ports affected by these breakages (via grepping INDEX, basically). Only 7 ports have more than 10 deps, fixing these (for real) might be a good start. I couldn't find a link to the actual gmake-3.82 update patch. How do people actually test their changes? Uli ___ 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: [HEADS UP] Ports Infrastructure Changes
On Sat, 19.03.2011 at 09:49:39 +0800, Martin Wilke wrote: > Hey, > > as the Ports Collection continue to grow, we have decided to > do some changes to the category layout. The www category, second > largest with over 2000 individual ports, will have three subcategories > spinned out. On the other side, x11-servers category, with only > 10 ports, will be folded into regular x11 category. Why? I can understand you'd like to move the handful of x11-servers into x11, but what do you gain by splitting www? The time and repo-churn could probably be spent on something more constructive than moving ports around. Uli -- "Hierarchies don't work!" ___ 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: [HEADS UP] Ports Infrastructure Changes
On Fr, 25.03.2011 at 07:11:42 +0800, Martin Wilke wrote:
> On Fri, Mar 25, 2011 at 4:06 AM, Ulrich Spörlein wrote:
>
> > On Sat, 19.03.2011 at 09:49:39 +0800, Martin Wilke wrote:
> > > Hey,
> > >
> > > as the Ports Collection continue to grow, we have decided to
> > > do some changes to the category layout. The www category, second
> > > largest with over 2000 individual ports, will have three subcategories
> > > spinned out. On the other side, x11-servers category, with only
> > > 10 ports, will be folded into regular x11 category.
> >
> > Why? I can understand you'd like to move the handful of x11-servers into
> > x11, but what do you gain by splitting www?
> >
> > The time and repo-churn could probably be spent on something more
> > constructive than moving ports around.
>
> so can u guys please come back to the review of the ports for the categorie
> move?
It would still be nice to know, what you think this move will improve.
Because it will fuck over people who have for example the following in
their make.conf
.if ${.CURDIR:M*/www/apache2*}
WITH_APR_FROM_PORTS=true
WITH_LDAP=true
WITH_AUTHNZ_LDAP=true
.endif
Let alone people who have used the OPTIONS framework and saved their
settings to /var/db/ports/.
So, again, what is gained by that move and how does it offset those
people's inconvenience?
Regards,
Uli
___
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: Migration to new SourceForge URL scheme part 2, SFE and some statistics
On Wed, 02.09.2009 at 19:45:45 +0400, Dmitry Marakasov wrote: > * Dmitry Marakasov (amd...@amdmi3.ru) wrote: > > Thanks a lot for replies! The patch is now committed. Really, the > more results I got the more compicated it was to choose the best > mirror order so I did stick with fastest mirrors for Europe and US, > as other countries like Japan and Indonesia just give opposite > results and have fastest mirrors which are slowest for the other > world. Well, make.conf is your friend for now, also we can think > of adding more localization options, including localized mirror sets. Thanks for all the effort! Cheers, Uli ___ 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: Open discution for a fakeroot support for the ports infrastructure
On Mon, 31.08.2009 at 23:26:43 +0200, Baptiste Daroussin wrote: > Hi, > > I've written some patches for the ports infrastructure importing the > fakeroot implementation from midnightbsd ports. > > In my first implementation the fake directory was enabled by default, no > ports had to be modified to support it. > My second implementation added a knob to add to make.conf (USE_FAKE) to > enable it for people wanting it and want to tested. still no ports to be > modified (except perhaps some buggy one) > > Now the patches are quite old (they won't apply cleanly) so I'm on updating > it again. > > Before rewriting it, I think it is a better idea to first discuss about it, > to improve it, see if there are interests, etc. > > So basically here is what is done and how it works. > the changes are only in the infrastructure not in ports themselves (except > that some will be able to benefit some cleanup) > > do-fake (with post and pre) replaces do-install (pre/post) it creates a > $WRKSRC/fakeroot where the binaries are copied by the ports (during the > do-install of the port) > > then do-package create a package using pkg-plist (or the generated one) > using the binary in fakeroot. > > do-install (ie make install) now only does a pkg_add of the created pkg. This is exactly what we need and kudos to you for taking on this task. I fail to see however, how this can "just work" for all the ports. Most of them are configured with --prefix=/usr/local so you cannot simply run 'gmake install' for them and have stuff show up in the fake root. How is this actually solved (the proposed patch did not enlighten me in that regard). Regards, Uli ___ 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 do I make npviewer.bin respect $TMPDIR ??
On Sun, 06.12.2009 at 12:18:21 -0800, Doug Barton wrote: > Howdy, > > I'm -current, i386, linux_base-f10-10_2, and > linux-f10-flashplugin-10.0r32; all with the latest firefox 35. It all > works fine, until my teeny tiny (24M) memory disk /tmp gets full. > > I have created a wrapper script for firefox to set TMPDIR (and TMP and > TEMPDIR just in case) to a large partition on local disk, which works > for firefox proper, but npviewer.bin is still putting its temp files > on the real /tmp. So, how do I whip it into shape? Haven't tried this, but there's a slight chance that the linux binary will prefer /compat/linux paths over / paths, and since there seems to be no /compat/linux/tmp, please try creating or symlinking one ... Cheers, Uli ___ 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: New version of the fakeroot patch
On Tue, 15.12.2009 at 10:00:18 +0100, Tijl Coosemans wrote:
> On Tuesday 15 December 2009 09:10:47 Matthew Seaman wrote:
> > Uh -- is it actually possible to create an empty directory when
> > installing from a pkg tarball?
> >
> > I ran into this problem with the phpMyAdmin port, and the only good
> > way I found to solve it was to add a stub file into any empty
> > directories. You could use a post install script or an mtree file,
> > but that seems like overkill for such a trivial operation.
>
> If you want to create ${PREFIX}/somedir you can add this line
> to pkg-plist:
>
> @exec mkdir -p %D/somedir
... and then you still need to chmod/chown to fix permissions. I wonder
why that doesn't work with tar. Is that a limitation of the format,
should we perhaps use cpio (with bsdtar, it would be transparent
anyway).
All in all, this is the right way for package creation and will result
in way better binary packages than before.
Regards,
Uli
___
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: New version of the fakeroot patch
On Thu, 24.12.2009 at 13:22:40 +0100, Tijl Coosemans wrote:
> On Thursday 24 December 2009 06:43:02 Ulrich Spörlein wrote:
> > On Tue, 15.12.2009 at 10:00:18 +0100, Tijl Coosemans wrote:
> >> On Tuesday 15 December 2009 09:10:47 Matthew Seaman wrote:
> >>> Uh -- is it actually possible to create an empty directory when
> >>> installing from a pkg tarball?
> >>>
> >>> I ran into this problem with the phpMyAdmin port, and the only good
> >>> way I found to solve it was to add a stub file into any empty
> >>> directories. You could use a post install script or an mtree file,
> >>> but that seems like overkill for such a trivial operation.
> >>
> >> If you want to create ${PREFIX}/somedir you can add this line
> >> to pkg-plist:
> >>
> >> @exec mkdir -p %D/somedir
> >
> > ... and then you still need to chmod/chown to fix permissions. I
> > wonder why that doesn't work with tar. Is that a limitation of the
> > format, should we perhaps use cpio (with bsdtar, it would be
> > transparent anyway).
>
> Ownership and permissions are restored by tar. It's just that empty
> directories aren't added to the archive by pkg_create.
For me, pkg_create does not even add non-empty directories to the tar,
just the files. Case in point: games/bsdgames
1. Remove all "chmod" calls in pkg-plist (won't affect install target)
2. make package
3. find /var/games -ls > /tmp/dir.port
4. pkg_delete bsdgames-\*
5. rm -rf /var/games
6. pkg_add /usr/ports/packages/All/bsdgames-2.4_1,1.tbz
7. find /var/games -ls > /tmp/dir.pkg
8. Compare and find out that all directories have 0755, which is wrong.
Or simply run tar tvf on the package and see all files, but no
directories.
Adding the directory itself to the PLIST would work, but then everything
under /var/games would get sucked up by pkg_create, no matter if it's
relevant or not. (Cpio would have that feature ...)
Tricky, huh?
Regards,
Uli
___
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 behavior of 'exists' function. Need help with Makefile.
On Mon, 28.12.2009 at 10:13:42 +0200, Yevgen Krapiva wrote:
> Hi guys,
>
> I'm trying to create my own port. I'm stucked with the following
> Makefile:
>
> PORTNAME= openjsip
> PORTVERSION= 0.0.4
> ...
> ...
> MY_FILE= proxy.properties
>
> do-check:
>
> #FIRST TEST
> . if !exists(/usr/local/share/openjsip/conf/proxy.properties)
> @${ECHO_MSG} ">> /usr/local/share/openjsip/conf/proxy.properties
> doesn't exist"
> . else
> @${ECHO_MSG} ">> /usr/local/share/openjsip/conf/proxy.properties
> exists"
> . endif
>
> #SECOND TEST
> @${ECHO_MSG} ">> DATADIR=${DATADIR}"
>
> .for f in ${MY_FILE}
> . if !exists(${DATADIR}/conf/${f})
> @${ECHO_MSG} ">> File ${DATADIR}/conf/${f} doesn't exist"
> . else
> @${ECHO_MSG} ">> File ${DATADIR}/conf/${f} exists"
> . endif
> .endfor
>
>
> I'm trying to make script to check the existence of proxy.properties
> file.
> The first test works well while to other one (with the use of 'for')
> doesn't.
> Can you help me, I don't understand why the second test fails.
First of all, please do not use "empty" lines inside a Makefile, it is
not an imperative language and care must be taken so that the parser
gets things right.
Doing a minimal test, I cannot confirm your findings, perhaps you should
try to trim down your example and see where it breaks or starts to work.
Example:
FILES=/etc/rc.conf /etc/doener.conf
all:
.for f in ${FILES}
.if !exists(${f})
@echo "${f} does not exist"
.else
@echo "${f} does exist"
.endif
.endfor
% make all
/etc/rc.conf does exist
/etc/doener.conf does not exist
hth,
Uli
___
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: Porting question
On Mon, 25.01.2010 at 10:54:01 -0600, Larry Rosenman wrote:
> I've asked portmgr before, but still haven't found a decent way to do what I
> want, so let me post this publicly.
>
> I want to make the sysutils/lsof port fail early with a decent message if
> the kernel sources aren't loaded on the system.
>
> The most common question/problem report I get is when the lsof configure
> script fails due to a lack of the system sources.
>
> Ideas on how to do this cleanly in the port Makefile?
from sysutils/fusefs-kmod:
.include
.if !exists(${SRC_BASE}/sys/Makefile)
IGNORE= requires the Kernel source to be installed. Set SRC_BASE if it
is not in /usr/src
.endif
.if !exists(${SRC_BASE}/sbin/mount)
IGNORE= requires the userland sources to be installed. Set SRC_BASE if
it is not in /usr/src
.endif
Me, I would not test for the Makefile, but one of the actually required headers.
Regards,
Uli
___
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: net-im/ejabberd 2.0.5 to 2.1.0
On Wed, 03.02.2010 at 22:10:51 +0100, Nicolas Raspail wrote: > Le 03/02/2010 20:29, Kamigishi Rei a écrit : > > Hello > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 03.02.2010 22:12, Nicolas Raspail wrote: > > > >> Do you have time to update the port's file to the new 2.1.2 > >> release of Ejabberd ? > >> > > The port was updated on Jan 20th and I have been running it ever since: > > > > r...@jail-0-4-2_im ~ # pkg_info|grep ejabberd > > ejabberd-2.1.2 Free and Open Source distributed fault-tolerant > > Jabber serv > > > I have been on your blog but I don't have seen any update, that's why I > have asked on the list. But I'm happy to hear that there is a new version. > > > You can fetch the updated port directory at > > http://media.fujibayashi.jp/software/ejabberd.txz (you'll probably > > need archivers/xz to unpack it). Note: it extracts as net-im/ejabberd. > > > I have downloaded it and will try to install it during the week. > Thank you for the updated port Update has just been comitted. Simply update your ports tree and update it in the usual way. Bye, Uli ___ 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: Best way to have a port...
On Mon, 01.03.2010 at 23:51:25 -0700, M. Warner Losh wrote: > ... that builds part of FreeBSD? > > Let me back up... > > I'm trying to create a port for gcc and binutils that is configured > for FreeBSD for a given machine. FreeBSD mips, say. binutils was > relatively easy (once I ported our mips support forward). However, > gcc vexes me. It requires, to build libgcc and friends, a fully > populated include tree. And it wants to use > /usr/local/freebsd-mips/include instead of /usr/include (which is > good). However, the former doesn't exist. I'd like to create a port > for it, but I'm unclear how to even start. This port should consist > of all files from make includes TARGET_ARCH=mips. > > So, some questions: First, how do I know where the FreeBSD source tree > is? Is there some standard define like SYSDIR that contains this > infomration? Simply take a look at ports that required /src or /sys to compile, eg. lsof or fusefs-kmod: lsof has: FREEBSD_SYS?= /usr/src/sys fusefs-kmod has: SRC_BASE?= /usr/src So neither of them use a predefined var. > Second, I need to invoke make includes (and a few other things), with > some slightly non-standard args. is there a stylied way to do this? > I'd like to avoid extracting everything into myport/work/FreeBSD :) Not quite sure on *when* you want to run make includes and if you want to run it for the port or for /usr/src? You could override the "pre-build:" target with stuff necessary pre build :) > Without solving these problems, the notion that we can use a ports > compiler to build FreeBSD becomes less viable... > > Comments? Not sure if they were helpful ... Bye, Uli ___ 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: Old ports bugs analyzis
On Wed, 31.03.2010 at 14:28:46 +0400, Arseny Nasokin wrote: > I've talked about custom built-in settings. Different options are need > in different situations. We doesn't have any real statistics about > options use. > > For example, gvim(1) is good idea on most desktop systems, but after > some issue, I build vim without GUI support. Issue is simple: > > Start x11, run xterm, run screen in it, detach, shutdown x11 server. > Attach to screen from text mode and run vim. You'll get at least > warning and slow startup. > Second issue about is why should X11 be on headless server? > > What should we do in this case? Create 10-20 packages for every > program? Or provide customisation interface (ports tree)? > > If second we can provide ports tree, which can download prebuild > package if common options are used or build it in other case or if > user want it. This has been floated around in this thread as "fat packages", where you basically have the build cluster build a port, eg. three ways. In our case vim-lite (no x11), vim (gui) and vim-full (perl, cscope, ...). These three runs can than be combined into one fat package. As they share documentation and other "share/" data, only the binaries/libraries need to be stored 3x in the package and compression should nullify the .tbz growth further. Same could be done for mplayer, an mplayer-full "flavour" an mplayer-free flavour using only free codecs, etc. Similar things can be done for mysql's or openldap's -client and -server packages. In summary, pkg_add vim on a server without X11 libs can then decide to extract the non-X11 variant, while someone on a desktop system will get a bigger version. This however, needs better pkg_ tools, more/faster hardware in the build cluster and a ton of volunteer work that is hard to come by these days ... Regards, Uli ___ 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: Manually registering dependencies for ports
On Mon, 07.06.2010 at 01:53:32 +0200, Thomas Rasmussen wrote: > Hello, > > I've been wondering about something: When I write a script or webapp that > needs some port to run, like a perl module, I install the needed port and > life is good (tm). A year later when I've completely forgotten about the > script I go do some spring-cleaning of the ports on the server, and I see > some perl module that doesn't have any dependencies, and delete it. Fast > forward a few days when I discover the script doesn't work anymore, cue > face-palm, remove bullet from foot, etc. Been there, done that. Apart from all that has already been suggested, you might want to take a look at pkg_cutleaves. You can make an exclude list of ports you don't want to have removed, other than that, it really helps when doing the spring cleaning :) Regards, Uli ___ 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: redports.org - The public FreeBSD ports development infrastructure
On Thu, 2011-12-29 at 12:44:58 +0100, Bernhard Froehlich wrote: > Hi Porters! > > I am happy to announce that redports.org has finally > reached the point where I think It's safe to be used > by everybody! In case you never heard of it before > redports is the result of an idea born at EuroBSDCon > 2011 in Karlsruhe to give Port Maintainers and Port > Committers a public service to test their new ports > or ports patches during development or before > submitting a ports PR. > > Many people test ports only on their own machine > because of lack of hardware. Redports gives you > instant access to build environments for FreeBSD 7.4, > 8.2, 9-CURRENT, 10-CURRENT on i386 and amd64 and even > special ones that use CLANG/LLVM or GCC 4.5 as ports > compiler. > > For everyone familiar with FreeBSD Ports Tinderbox [1] > it's pretty obvious how it works. In fact redports is > build on top of multiple Tinderboxes so it is > scalable, fast and reliable. With your account you get > your own Subversion Repository to maintain your ports > and with every commit to the repository all affected > ports are automatically built. > > When registering an account please read the UserGuide > [2] first to get an idea of how to work with it. > Feedback and new Ideas are welcome! > > > Best regards, > Bernhard Fröhlich (decke@) > > [1] http://tinderbox.marcuscom.com/ > [2] http://redports.org/wiki/UserGuide This is awesome, thanks! Uli ___ 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: Call for potential ports maintainers
On Thu, 12.02.2009 at 12:32:13 -0500, Thomas Abthorpe wrote: > This topic came up in IRC, and I was encouraged to go out, and find some new > maintainers. > > At any given time, approximately 20 - 25% of all ports are unmaintained. Not > all unmaintained ports need updating, but some do. That is where you folks > come in. > [...] > The gauntlet has been thrown down, who among you is prepared to pick it up? Not sure if these have already been taken, but sign me up for: audio/mp32ogg games/freebsd-games graphics/feh sysutils/wmtop x11-clocks/wmtimer x11/wmcliphist Cheers, Ulrich Spörlein -- None are more hopelessly enslaved than those who falsely believe they are free -- Johann Wolfgang von Goethe ___ 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: Make package-recursive problem
On Fri, 22.05.2009 at 12:17:44 -0400, Matt Juszczak wrote: > Hi all, > > I've started noticing more and more that packages I build are missing files > after they are rebuilt. I've tested this time and time again, and seem to > be able to show that about 10 ports (gettext, apache, net-snmp, some php > modules, etc.) are built correctly the first time, but when later > re-packaged, do not contain all the files they need. > [...] I have no clue as to what is causing this, but this is probably the reason why people use the tinderbox or roll their own system to build consistent packages. I have rolled my own, too. Consisting of a Makefile and a couple of scripts. It gathers all missing packages to build, uses a common make.conf and clean system for the compile, starts by building the leaf packages first. I never came around to using ZFS + clones for the package creation, which would have cut the time to setup the required base for each build significantly. Another approach had even the package dependency inside a Makefile, so rebuilding the gettext package would trigger all dependent packages to get rebuilt too (I haven't tackled the problem of *reinstalling* them on the target hosts, though) You see, everybody serious about using packages on a farm should create his own system :) It's not too hard anyway. Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Make package-recursive problem
On Sun, 24.05.2009 at 14:11:26 -0400, Matt Juszczak wrote: > > I have no clue as to what is causing this, but this is probably the > > reason why people use the tinderbox or roll their own system to build > > consistent packages. > > I feel like I am though? I have a dedicated box just for building > packages. make package creates a tbz file of all packages, and is > supposed to be reliable. It should be under the following circumstances: - You don't update /usr/ports - You don't change /etc/make.conf - You don't deinstall packages > > Another approach had even the package dependency inside a Makefile, so > > rebuilding the gettext package would trigger all dependent packages to > > get rebuilt too (I haven't tackled the problem of *reinstalling* them on > > the target hosts, though) > > Doesn't this already occur with the default tools in the port system? No, installed packages will be updated only (by portmaster or portupgrade) if their PKGVERSION changes. To force the update when a new gettext hits the tree, we have these !...@$!#% awful PORTREVISION bumps across a gazillion ports. I chose a bad example. Consider Perl was upgraded from 5.8.8 to 5.8.9, so the target "perl.tbz" changes mtime (at least), then make(1) would rebuild every port/package that depended on the Perl package. That was what my special Makefile was doing. Plus, you get nice Graphviz input, but a 20,000 node graph is useless to print. Extracting subgraphs for, eg. OpenOffice was nice, though. Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: make.conf no x option
On Wed, 27.05.2009 at 05:01:31 +0900, Randy Bush wrote:
> >> i think this whole thing is worth a few days to settle in our heads.
> >> essentially, if we believe that freebsd is used extensively in
> >> headless server deployments, we should make that easy and smooth.
> > But even a headless server can run X clients with the display being on
> > some other (presumably non-headless) machine. That is on of the
> > beauties of the X Windowing System.
>
> [ thanks, but i am overly-familiar with the beauties and the some of the
> warts of x. ]
>
> someone installing a server may or may not want the x client version of
> a package as opposed to readline or curses. but, imiho, it would be
> good to make such decisions centralized, somewhat strong, and pretty
> clear.
>
> > The only part that would make no sense to install on a headless
> > machine is the X server itself
>
> and the support for it and the toys it occasionally seems to drag in.
>
> i really do not want the x client versions of emacs, cvsup, ...
> actually, i can not think of any ports i run on headless machines that i
> want spawning windows on my glass. ymmv, of course.
>
> i think that i would like to be able to say headless install and have to
> ack any port which wants to drag in x.
First of all, try figuring out which ports got you into the X11 mess. On
my server I got:
% pkg_info -R libX11-1.2.1,1
Information for libX11-1.2.1,1:
Required by:
jabber-pyicq-transport-0.8.1.3,1
jdk-1.6.0.3p4_9
libXext-1.0.5,1
libXi-1.2.1,1
libXtst-1.0.3_1
py25-imaging-1.1.6_2
py25-tkinter-2.5.4_3
tk-8.4.19_2,2
Then, adjust their flags and options to not get there again. Then,
instead of patch bsd.port.mk you could try something like this in your
/etc/make.conf
.if ${.CURDIR:M*/x11/libX11}
.error "me no want X11"
.endif
Which will work only when building the packages by yourself. To not
break 'make index' you should wrap the error in .if
target(do-build)/.endif or other suitable make targets.
I cannot test the idiom right now, but there's little need to change the
WITHOUT_X11 meaning globally for all users. Besides, the approach above
can also be used to "break" other ports and keep them from installing.
Cheers,
Ulrich Spörlein
--
http://www.dubistterrorist.de/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: make.conf no x option
On Sun, 31.05.2009 at 21:25:33 +0900, Randy Bush wrote: > >>>> i think this whole thing is worth a few days to settle in our heads. > >>>> essentially, if we believe that freebsd is used extensively in > >>>> headless server deployments, we should make that easy and smooth. > >>> But even a headless server can run X clients with the display being on > >>> some other (presumably non-headless) machine. That is on of the > >>> beauties of the X Windowing System. > >> > >> [ thanks, but i am overly-familiar with the beauties and the some of the > >> warts of x. ] > >> > >> someone installing a server may or may not want the x client version of > >> a package as opposed to readline or curses. but, imiho, it would be > >> good to make such decisions centralized, somewhat strong, and pretty > >> clear. > >> > >>> The only part that would make no sense to install on a headless > >>> machine is the X server itself > >> > >> and the support for it and the toys it occasionally seems to drag in. > >> > >> i really do not want the x client versions of emacs, cvsup, ... > >> actually, i can not think of any ports i run on headless machines that i > >> want spawning windows on my glass. ymmv, of course. > >> > >> i think that i would like to be able to say headless install and have to > >> ack any port which wants to drag in x. > > > > First of all, try figuring out which ports got you into the X11 mess. On > > my server I got: > > > > % pkg_info -R libX11-1.2.1,1 > > Information for libX11-1.2.1,1: > > my point was specifically that, if we believe that freebsd is used by a > major server population, that having to know/do this kind of cruft is > ill-advised. Please step back a moment and think about what you're trying to accomplish. Specifically, *why* (and you should give technical reasons) are you opposing some random X11 libraries in your installation? They don't take up space, having vim with X support (not gvim!) is nice, as you can use the mouse to scroll around, resize windows, etc. and for most of the ports, WITHOUT_X11 already DTRT, if not please provide examples so they may be fixed. I am sure, the major population of server admins in this part of town don't care about whether gvim is installed as part of vim or not. YMMV, of course, but since you want to change the status quo, the burden of proving the benefit of such action is on you. Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: can you PLEASE _read_ the QAT mails? (was: Re: Question about a failure report)
On Mon, 06.07.2009 at 00:51:48 +0300, Ion-Mihai Tetcu wrote: > On Sun, 05 Jul 2009 13:49:49 -0500 > Paul Schmehl wrote: > > > > For short, your port's configure script fails to search for mysql > > > headers in the right place; QATty has LOCALBASE and PREFIX set > > > to /usr/PPP. If you can't sorted out in a few days drop me an email > > > and I'll take a look. > > > > No offense taken. The thing that confused me is that I always build > > my ports in /tmp/portname when testing, but barnyard still managed to > > find mysql headers when building. > > Yes, that's PREFIX (ie. you install in /tmp/portname) but LOCALBASE I > bet it's /usr/local. > > > So I didn't understand why it was failing in QAT. I followed all the > > links in the email and read the materials, but I still didn't > > understand why the build failed in QAT. > > It failed on QATty, not on QAT. > > QAT has -DNOPORT* while > QATty has PREFIX and LOCALBASE = /usr/PPP Hi Ion-Mihai, this is the first time, I hear there are different QAT setups (although it makes sense, doesn't it?). So I was wondering where this is documented. I am always confused about what portsmon is doing vs. pointyhat. Then we have tinderbox for src and other ones for ports. Now there are multiple QAT setups! Searching for 'qat' on wiki.freebsd.org revealed no hits, although I think that would be a good place to document all "official" port/package "linters" So I would kindly ask you, if you could put some information and links regarding QAT on the wiki. Other people will probably fill in the details for pointyhat, portsmon, etc. That would be great, thanks! Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ejabberd 2.0.5 + erlang-r13b01_5 : failure
On Tue, 14.07.2009 at 09:34:10 +0200, Olivier Mueller wrote: > Hello, > > For the people around using ejabberd: > > erlang-r13b01_5,1 A functional programming language from Ericsson > erlang-mysql-1.0_2 Native MySQL driver for Erlang > ejabberd-2.0.5 Free and Open Source distributed fault-tolerant Jabber > serv > > doesn't seem to work (epmd starts, but then nothings seems to happen and > no log written), but after downgrading erlang, it's ok again: > > erlang-r12b5_2,1A functional programming language from Ericsson > erlang-mysql-1.0_2 Native MySQL driver for Erlang > ejabberd-2.0.5 Free and Open Source distributed fault-tolerant Jabber > serv > > I don't see the reason yet, I just get a bunch of > erl_crash_20090714-n.dump files in /var/log/ejabberd with r13 and > everything is fine with r12. But it is maybe related to a rather old > freebsd version (7.0-RELEASE-p11). (no, it's not related to the > uid/gid port change as specified in ports/UPDATING). Hi Olivier, peruse the ejabberd forums/mailing lists. They don't support building with erlang-r13 yet. It's as simple as that, and I, too, wasted a whole day figuring that out. A suitable CONFLICT in the ejabberd port would be nice. Cheers, Ulrich Spörlein ___ 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: ejabberd 2.0.5 + erlang-r13b01_5 : failure
On Tue, 14.07.2009 at 15:21:16 +0200, Alexander Leidinger wrote: > Quoting Ulrich Spörlein (from Tue, 14 Jul 2009 > 10:35:51 +0200): > > > peruse the ejabberd forums/mailing lists. They don't support building with > > erlang-r13 yet. It's as simple as that, and I, too, wasted a whole day > > figuring that out. > > Patches at (I haven't tested any patch): > http://bugs.gentoo.org/show_bug.cgi?id=267524 > https://support.process-one.net/browse/EJAB-919 > > Bye, > Alexander. Tested patch attached to http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/135593 , thanks for the tip regarding EJAB-919. If someone would be so kind to commit the changes; shaun@ has relinquished maintainership recently :( Bye, Uli ___ 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: multimedia/avidemux2
On Tue, 18.08.2009 at 22:59:05 +0300, Sergey V. Dyatko wrote: > Hi, > > subj is marked as 'BROKEN' (need a update for Qt 4.5). We have qt4-4.5.2 > now. Can you fix avidemux2 build? > With removed 'BROKEN' string on Makefile I got error. Build log: > http://tiger.ipfw.ru/files/avidemux2build.txt See http://www.freebsd.org/cgi/query-pr.cgi?pr=137621 (yes, I messed up the Synopsis, could someone fix that?) Uli ___ 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"
