Re: Updating devel/tbb - Introducing devel/onetbb
On Sunday, January 10, 2021 6:29:07 AM CET Shane Ambler wrote: Hello Shane, > You don't have to do it all yourself, you create the bug reports to > change tbb and to create onetbb, one report can depend on the other so > they get committed together. My experience is being told to submit one > report for each port, not one patch to change multiple ports. > > Then you create a report to say blender fails to build with your new > port and add the report number to the Blocks list in your report. That > leaves me to submit a patch to update blender to work with your change > before your update can be committed. I would then add reports to update > other dependencies that block my update. > > At most you submit 20 reports to say xx/yy port needs updating. There is > devel/pybugz and ports-mgmt/freebsd-bugzilla-cli that could automate > that but I haven't used them so can't recommend either. > > Then all the depends and blocks get updated together or some ports can > get marked as broken if they fail to update in a suitable time. OK, using Bugzilla that way will help us synchronize changes and prevent the ports tree from having things depending on both versions. So, finally, here is the plan: - Create a master PR containing expected devel/tbb and devel/onetbb ports (with CONFLICTS). I won't commit devel/onetbb before, to avoid having new ports needing it while others are still not migrated. - Attach a blocking PR for each failing port and wait for patches - At last, commit the new port and all port changes together That should be OK that way :) Thanks again for help! I'll start working on that ASAP, stay tuned! -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org ___ 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: Updating devel/tbb - Introducing devel/onetbb
tbb port can just be deleted. > > If a port or two wants to stay with the old tbb, then let them maintain > the tbb port. Yes, why not. We can imagine keeping the old devel/tbb for a certain time if it still builds. Thanks again for your feedback! Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org ___ 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"
Updating devel/tbb - Introducing devel/onetbb
Hello, First of all, happy new year :) Intel oneAPI tbb (formerly known as Intel tbb) 2021.1 has been released and has deprecated several interfaces over tbb 2020. See: https://software.intel.com/content/www/us/en/develop/articles/intel-oneapi-threading-building-blocks-release-notes.html and: https://software.intel.com/content/www/us/en/develop/articles/tbb-revamp.html As a consequence, I cannot update devel/tbb anymore as most of our dependent ports do *not* build with that new version, that includes: Portname: Maintainer: - --- misc/openvdb y...@freebsd.org misc/dartsim y...@freebsd.org misc/ngraph y...@freebsd.org databases/tiledb sunp...@freebsd.org graphics/py-opencvtcber...@freebsd.org graphics/opencv-java tcber...@freebsd.org graphics/instant-meshes greg@unrelenting.technology graphics/mirtky...@freebsd.org graphics/opensubdiv free...@shaneware.biz graphics/blender free...@shaneware.biz graphics/opencv tcber...@freebsd.org graphics/opencv-core tcber...@freebsd.org graphics/oidn y...@freebsd.org devel/py-numbad...@dal.ca devel/ikosy...@freebsd.org science/pagmo2y...@freebsd.org science/madness y...@freebsd.org www/osrm-backend free...@mosedal.net archivers/par2cmdline-tbb marty...@freebsd.org cad/opencascade thie...@freebsd.org cad/PrusaSlicer teodorsig...@gmail.com math/suitesparse fort...@freebsd.org math/saga rhur...@freebsd.org math/dune-pdelab y...@freebsd.org math/openturnsy...@freebsd.org math/curv y...@freebsd.org The following ports seem to build correctly : Portname: Maintainer: - --- math/dune-gridy...@freebsd.org math/dune-common y...@freebsd.org math/dune-uggrid y...@freebsd.org math/dune-geometryy...@freebsd.org biology/bowtie2 j...@freebsd.org graphics/openimageio free...@shaneware.biz graphics/embree da...@freebsd.org math/deal.ii y...@freebsd.org See: http://box.martymac.org/FreeBSD-Packages/build.html? mastername=FBSD122amd64-default=2021-01-07_12h17m40s for more details. To be able to smoothly introduce onetbb 2021 into the ports tree and let maintainers migrate to that new version, here is my plan : - leave devel/tbb in place and introduce a new port: devel/onetbb - add a PKGNAMESUFFIX to devel/tbb to 'freeze' its version and modify description to indicate the 'legacy' status of the port - design devel/onetbb to install files in dedicated subdirs so that it will not CONFLICT with current devel/tbb (needed during migration phase) - provide a pkgconf file that will be used by dependencies to locate those files and include/link options easily - [let maintainers migrate their ports to that new version] - at some time (?), mark devel/tbb as DEPRECATED with an EXPIRATION_DATE and do the same for remaining (non-updated) deps I would originally have preferred to do the opposite : i.e. move files from devel/tbb to a dedicated subdir and let devel/onetbb install files to the default PREFIX, but that would imply modifying each dependency myself, which is something I won't have time to do (and each port's MAINTAINER is probably the best person do do that). Doing it that way will also incite MAINTAINERs to use the pkgconf file whenever possible to detect onetbb, wich will introduce more flexibility for future updates. Any comment on this ? Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org ___ 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"
[CFT] Simgear and Flightgear updates to 3.2.0
Hi everyone, If you are a Flightgear user, I would be pleased to get feedback on the upcoming update to version 3.2.0. Patches are available here : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194571 Thanks :) -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: emulators/dolphin-emu fails to build on 10.0-RC4
On Wed, 8 Jan 2014 00:15:46 -0500, Henry Hu wrote It seems to be caused by incompatibilities between gcc and clang. If you remove USE_GCC=yes from Makefile, it builds fine. You may try if this works. Yes, sorry, I've got a patch pending to fix that issue (see ports/184540) but I am stuck with an OPTIONS handling bug. Meanwhile, just removing USE_GCC=yes will work. Cheers, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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
New options framework + DEBUG set = wrong INSTALL_TARGET
Hi everyone, I am stuck with the new options framework. I have a port (emulators/dolphin-emu) that defines the DEBUG option. Unfortunately, with the DEBUG option set to on, INSTALL_TARGET keeps being defined to 'install/strip' while it should automatically be set to 'install' by Uses/cmake.mk. I have opened a PR as I think we have a bug somewhere : http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/184540 Any idea ? Am I doing something wrong ? Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: dolphin-emu requires KMS to get OpenGL?
On Fri, 25 Oct 2013 10:55:18 +0200, David Demelier wrote Hi David, I wanted to try out the last version of dolphin-emu (4.0.0). When I try to start any game it stops with : Your card supports OpenGL 2.0? Your card supports OpenGL 3.0? I'm running standard Xorg without KMS with a ATI Radeon 4330. Is KMS mandatory for that card? I am not tried Dolphin without KMS (what works for me is an intel card with KMS + latest Mesa), but you need for sure the latest version of Mesa (9.1.6). This means you will have to upgrade Xorg co with WITH_NEW_XORG set if not done. Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: Dolphin-emu now has OpenGL rendering (was: [CFT] Update of xorg libraries and MESA)
Ganael LAPLANCHE wrote: Works like a charm on my Lenovo X220 (-CURRENT). ... and more than that : with the update of Mesa, dolphin-emu (Wii/GC emulator, see emulators/dolphin-emu-devel) now has a working OpenGL rendering ! It has been successfully tested on my laptop :) Best regards and thanks for your work on this update :) -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: [CFT] Update of xorg libraries and MESA
On Mon, 09 Sep 2013 16:52:03 +0200, Niclas Zeising wrote Hi Nicolas, The patch has been updated, and the updated version is attached. As always, it is possible to find the latest version of the patch at http://people.freebsd.org/~zeising/xorg-mesaupdate.diff Works like a charm on my Lenovo X220 (-CURRENT). Thanks ! -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: FreeBSD can now receive DAB(+) radio (and stereo wideband FM)
On Sun, 28 Apr 2013 16:24:53 -0500, Diane Bruce wrote martymac and I have been working on that. gnuradio 3.6.3 will shortly be in ports and when martymac is back from vaction, we will have gr-osmosdr / gqrx ports. They are now both available in the ports tree ! Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: devel/flatzebra broken, maintainer timeout, please reverse commit
On Thu, 6 Jun 2013 18:43:08 +0100, Chris Rees wrote Hi, That's the proper fix- sorry I was unclear there; I meant if it can't be fixed easily. I have just updated the PR with a fix, see : http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/177949 Anton, can you test it and tell me how it goes ? Thanks, Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: devel/flatzebra broken, maintainer timeout, please reverse commit
On Fri, 7 Jun 2013 09:52:44 +0100 (BST), Anton Shterenlikht wrote Anton, can you test it and tell me how it goes ? works fine on ia64 Thanks. I'll wait for Edwin approval and commit the update. Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: devel/flatzebra broken, maintainer timeout, please reverse commit
On Fri, 7 Jun 2013 10:48:32 +0100, Chris Rees wrote I think maintainer timeout applies here; unless there was an acknowledgement from the maintainer before we shouldn't make people wait any longer. You're right, this PR is quite old now (6 weeks). I've committed the change. Thanks ! -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: devel/flatzebra broken, maintainer timeout, please reverse commit
On Thu, 6 Jun 2013 14:49:19 +0100 (BST), Anton Shterenlikht wrote Hi Anton, Maintainer timeout on http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/177949 Please reverse ports commit r315963, http://www.freebsd.org/cgi/query-pr.cgi?pr=177730 It builds fine on my machine : FreeBSD laptop.martymac.org 10.0-CURRENT FreeBSD 10.0-CURRENT #8 r250591M: Mon May 13 11:36:50 CEST 2013 marty...@laptop.martymac.org:/usr/obj/files/Src/sys/GENERIC amd64 with clang. Could you try un-installing the previous version of flatzebra before building this new version ? It is possible that headers from the previous version make the build fail... Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: devel/flatzebra broken, maintainer timeout, please reverse commit
On Thu, 6 Jun 2013 16:07:08 +0100 (BST), Anton Shterenlikht wrote yes, this helps on ia64, thank you. Probably will help on amd64, will check later. Sorry for not thinking about is myself, I just tried to update with portmaster, as usual. Tested on amd64, I can reproduce the problem. I'll have a look at that, thanks for reporting the problem. Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: updating devel/simgear from a previous version
On Fri, 22 Feb 2013 22:30:30 +0300, Mikhail Tsatsenko wrote Hi Mikhail, Looks like latest simgear 2.10.0 can not be built if a previous version is installed (at least on 9.1 amd64). [...] Thanks for having reported that issue. I have relocated the include_directories(BEFORE ...) patch to main CMakeLists.txt, which fixed the problem. Upgrading should be possible now. Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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
PowerBroker Identity Services (Likewise-open) preliminary port update
Hi Everyone, Following my previous post : http://lists.freebsd.org/pipermail/freebsd-ports/2011-June/068304.html and the acquisition of Likewise by BeyondTrust : http://www.beyondtrust.com/News-and-Events/Press-Releases/2011/BeyondTrust-Introduces-New-PowerBroker-Identity-Services-to-Provide-Secure-Cloud-Authentication-Solution/ here is an update of the preliminary port (v7.1 open edition), now called pb-identity-open : http://contribs.martymac.org/FreeBSD-ports/sandbox/pb-identity-open-7.1.0.r64655-port.tar.gz The HOWTO posted in 2011 is still valid. You can follow step 1), 2) and 3) (do not forget to adapt paths). For step 4), before adding the test user, do the following : # regshell cd HKEY_THIS_MACHINE\Services\lsass\Parameters\Providers set_value LoadOrder Local to ask PBIS to use the local database as a source of authentication. You shoud then be able to identify/authenticate this user. In step 4), I am now stuck with the connection to the c$ share (which does not exist - but I don't know how to create it), and also with lwio-fuse-mount and lwio-copy. As I am not a Likewise (Pbis) expert, help would be greatly appreciated in testing the software / polishing / finishing the port. Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: optionsng and tinderbox?
On Thu, 21 Jun 2012 12:50:56 +0100, Matthew Seaman wrote Fixed in the latest iteration of the patches on Freefall. While I was there, I made the equivalent change with respect to openldap23-server (ie. not using OPTIONS_DIR at all) although that makes little difference as openldap23-client doesn't use any options at all. Good, thanks ! Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: optionsng and tinderbox?
On Wed, 20 Jun 2012 13:28:26 +0100, Matthew Seaman wrote Hi Matthew, Baptiste, Thank you very much for your answers. With your patch, Matthew, setting : openldap24-client_SET+=FETCH in make.conf now works for net/openldap24-client : $ cd /usr/ports/net/openldap24-client $ make -V PORT_OPTIONS DOCS EXAMPLES FETCH NLS Great :) [...] Shouldn't make.conf / commandline settings override OPTIONSFILE rather than the other way round? Seems there's not much point in being able to set options from make.conf unless that is so, as OPTIONSFILE would be created more often than not whenever make(1) was invoked in the port's directory. I think that command-line options should always override file ones, but the main problem here is that we cannot distinguish what comes from the command line from what comes from make.conf. What would sound logical to me would be the following order of precedence : make.conf - overridden by option files - overridden by command line But maybe the idea of setting xxx_SET from the command line was just silly ? [...] Before my patches the port had: % make -V UNIQUENAME -V LATEST_LINK -V OPTIONSFILE openldap24 openldap24-client /var/db/ports/openldap24/options % cd ../openldap24-server % make -V UNIQUENAME -V LATEST_LINK -V OPTIONSFILE openldap24 openldap24-server /var/db/ports/openldap24/options This is no more the case, see : http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/openldap24-server/Makefile.diff?r1=1.200;r2=1.201 $ cd /usr/ports/net/openldap24-client $ make -V UNIQUENAME -V LATEST_LINK -V OPTIONSFILE openldap24-client openldap24-client /var/db/ports/openldap24-client/options $ cd /usr/ports/net/openldap24-server $ make -V UNIQUENAME -V LATEST_LINK -V OPTIONSFILE openldap24-server openldap24-server /var/db/ports/openldap24-server/options However on inspection, openldap24-server and openldap24-client take different sets of options: -server takes a super-set of -client. So having a shared OPTIONSFILE doesn't make sense to me [...] You're right ! This is now fixed in the current ports tree, but your patch reversed that change :p Could you remove the OPTIONS_DIR patch for net/openldap24-server ? Thank you very much, Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: optionsng and tinderbox?
On Wed, 20 Jun 2012 11:13:21 +0200, Baptiste Daroussin wrote Hi Baptiste, make -VUNIQUENAME should show you the right name I have a port where UNIQUENAME is *not* the right prefix to use before '_SET' for positioning this specific port's options : $ pwd /usr/ports/net/openldap24-client $ make -V UNIQUENAME openldap24-client $ make -V PORT_OPTIONS DOCS EXAMPLES NLS $ make openldap24-client_SET=FETCH -V PORT_OPTIONS DOCS EXAMPLES NLS but : $ make openldap24-server_SET=FETCH -V PORT_OPTIONS DOCS EXAMPLES FETCH NLS So, here, I have to set the following in make.conf : openldap24-server_SET+=FETCH and not : openldap24-client_SET+=FETCH which would not work. Are you aware of that specific problem ? Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: [PATCH] multimedia/libdvdnav
On Tue, 7 Feb 2012 15:53:55 +1100, richo wrote Hi Richo, Did you get a chance to look at this? Yes, sorry, I did not get back to you. This has been part of the 4.2.0 libdvdnav/libdvdread update, see : http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/libdvdread/Makefile#rev1.40 I have fixed that issue in a different way of yours as the main problem was a configure2 script issue : http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/libdvdread/files/patch-configure2.diff?r1=1.2;r2=1.3 I have reported the patches upstream here : http://lists.mplayerhq.hu/pipermail/dvdnav-discuss/2012-January/001661.html Thanks for having reported that issue. Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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
Introducing fpart - a file partitioning tool
Hi everyone, Have you ever wondered how you could split a file tree into parts of the same size, or into parts with a limited size or file number ? I have developed a small BSD-licensed tool called fpart that can do that for you (see http://contribs.martymac.org and https://sourceforge.net/projects/fpart). This small C program will crawl a given set of file or directory paths, organize them and print resulting partitions. This can be useful to e.g. launch several rsync(1) in parallel or store files on media of limited size. Here are some examples : 1) Produce 3 partitions, with (approximatively) the same size and number of files : $ fpart -n 3 -o var-parts /var 2) Produce partitions of 4.4 GB, containing music files ready to be burnt to a DVD : $ fpart -s 4724464025 -o music-parts /path/to/my/music 3) Produce partitions containing 1 files each by examining /usr and /home : $ find /usr ! -type d | ./fpart -f 1 -i - /home | grep '^0:' The tool is already available in ports (sysutils/fpart) but has also successfully been used on GNU/Linux. Enjoy ! Best regards, PS : comment and patches are, of course, welcome :) -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: Introducing fpart - a file partitioning tool
On Fri, 06 Jan 2012 04:13:44 -0700, Janketh Jay wrote Hi Janketh, Awesome! This seems like a great idea! Thanks! I'll definitely test and play with it and let you know if I have any issues, bugs, patches, etc.. Great :) Thank you very much ! Cheers, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: [PATCH] multimedia/libdvdnav
On Sat, 22 Oct 2011 15:10:00 +, Alexey Dokuchaev wrote Hi, [...] Can this be included in ports? I would suggest notifying maintainer about this patch. Perhaps filing a PR is a right thing to do. I will update libdvdnav/libdvdread to 4.2.0 once 9.0-RELEASE is out. I will have a look at your patch then. Thanks for your contribution, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: About games/flightgear-aircrafts
On Mon, 17 Oct 2011 11:08:48 +0200 (CEST), Ganael LAPLANCHE wrote They are not included in flightgear-data, so I'll add them to the new flightgear-aircrafts port. The patch has been committed, thanks for your help :) Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: About games/flightgear-aircrafts
On Fri, 14 Oct 2011 12:53:11 +0200, Alexey Shuvaev wrote Hi Alexey, I don't know which aircraft are in the base package (flightgear-data), but IMHO: * harrier : British Aerospace Harrier is something known and interesting (vertical takeoff/landing), * il2 : Ilyoushin IL-2 is also quite famous WWII attack plane and * wrightFlyer1903 : 1903 Wright Flyer is must have :) They are not included in flightgear-data, so I'll add them to the new flightgear-aircrafts port. Thanks for your feedback, Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: About games/flightgear-aircrafts
On Mon, 17 Oct 2011 13:10:26 +0100, Chris Rees wrote Hi Chris, If you haven't committed it yet, can you please drop the 's' from aircraft? Yep, I am aware of that typo (Warren Block wbl...@wonkity.com has previously reported that in a previous mail) ; it's on my TODO list. Once the limited aircraft list is committed (and 9.0 released), I'll ask for a repocopy from : games/flightgear-aircrafts = games/flightgear-aircraft I'll then change PORTNAME. Meanwhile, my awaiting patch already includes COMMENT/pkg-descr fixes. Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: About games/flightgear-aircrafts
On Thu, 6 Oct 2011 10:29:32 +0200 (CEST), Ganael LAPLANCHE wrote Hi Everyone, I've established a first selection by following the main aircraft page : http://www.flightgear.org/download/aircraft-v2-4/ and removing alpha/beta/experimental/early-production planes. I'll try to shorten this list one way or another and come back with a limited aircraft list. If somebody wants a plane to be added to it, just tell me : I'll update it. I'll try to work on that ASAP, but I am currently very busy, so don't expect any change before a few weeks. Following my previous post, here is a selection of planes I've made. They will remain available in the flightgear-aircrafts port, any other plane will be removed and will have to be installed manually : * 737-200_20110713.zip : Boeing 737-200 * A-10_20110629.zip : Fairchild A-10 * A300_20101217.zip : Airbus A300 * Alouette-II_20110523.zip : Alouette II * Alphajet_20110228.zip : Dassault/Dornier Alphajet * B-17_20110516.zip : Boeing B17 * Breguet-XIX_20101217.zip : Breguet XIX * C130_20101217.zip : C130 Hercules * Caravelle_20101217.zip : Caravelle * Caudron-G3_20101217.zip : Caudron G.III * F80C_20101217.zip : Lockheed F-80C Shooting Star * Hurricane_20110815.zip : Hawker Hurricane IIb * Lightning_20110705.zip : English Electric Lightning F.1A * Lockheed1049h_1.0.zip : Lockheed 1049H Super Constellation * Messerschmitt-P1101_20101217.zip : Messerschmitt Me P1101 * MirageIII_20110124.zip : Mirage IIING * PaperAirplane_20110103.zip : Paper airplane * Pond-Racer_20101217.zip : Rutan Pond Racer * R44_20110523.zip : Robinson R44 * Spitfire_20110705.zip : Supermarine Spitfire * Stieglitz_20101217.zip : Focke Wulf FW44 Stiegltz * Super-Etendard_20110324.zip : Dassault-Breguet Super Etendard * Supermarine-S.6B_20110118.zip : Supermarine S6B * Superwal_20101217.zip : Dornier Superwal * airwaveXtreme150_20101217.zip : Airwave Xtreme 150 hang glider * asw20_20101217.zip : ASW-20 sailplane * bf109_20110629.zip : Messerschmitt BF-109 G14 * c310_20110113.zip : Cessna 310 * dhc3_20110411.zip : DHC 3 Otter * f16_20110629.zip : General Dynamics F-16 * pa24-250_20110222.zip : Piper Comanche 250 * tu154_20101217.zip : Tupolev 154 This (now very limited) list includes every plane in the 'production' state, as well as well-known or seemingly interesting ones (no devel, beta, alpha, or pre-production ones). I have also tried to keep a wide variety of planes available. This list will make the port maintainable again. Anyway, it is far from perfect ; also, if a plane is missing, do not hesitate to contact me : I'll just add it. I'll commit the changes within 15 days if there is no complaint about this list. Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: About games/flightgear-aircrafts
On Mon, 3 Oct 2011 23:56:21 +0200, Alexey Shuvaev wrote
Hi Alexey,
Thanks for your answer,
I have not looked what is needed to install new aircraft as a
user, but it it would be something against the habbits of a
typical FreeBSD user. At least I would certainly forget to
update an aircraft installed this way...
You would just have to copy data files to
${PREFIX}/share/flightgear/Aircraft/. Simple but not convenient, I agree.
From my experiency a while ago, the quality of the aircraft
models varied greatly from model to model. I remember, there
was some transition from one simulation engine to another more
advanced one (JSBsim - YASim or vice versa?). For example,
some WW II planes were able to perfom back loop in the
simulator, which is a non-sense... So, my 0.02$ is if you
are somewhat familiar with at least some of aircraft, you can
chose those which are mature enough (such as default Cessna
172).
From another point of view, you are the maintainer of the port,
so it is up to you to decide (according to your personal
prefereces) which aircraft to include in the port. If somebody
lacks his favorite aircraft, he is free to create another
aircraft add-on port, after all...
I've established a first selection by following the main aircraft page :
http://www.flightgear.org/download/aircraft-v2-4/
and removing alpha/beta/experimental/early-production planes. I'll try
to shorten this list one way or another and come back with a limited
aircraft list. If somebody wants a plane to be added to it, just tell me
: I'll update it.
I'll try to work on that ASAP, but I am currently very busy, so don't
expect any change before a few weeks.
Best regards,
--
Ganael LAPLANCHE ganael.laplan...@martymac.org
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac marty...@freebsd.org, http://www.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
About games/flightgear-aircrafts
Hi list, As you may know, games/flightgear-aircrafts is *HUGE*, way too big to be useable and buildable correctly, and, as a maintainer, a real pain to update. Today, if you just need one airplane from flightgear-aircrafts, you would have to download 350+ airplanes and more than 2 GB of data, which makes no sense at all. We have to get rid of that. I am thinking of two options : 1) providing only a subset of available airplanes (i.e. *not* every single airplane available on the FTP servers). This would be nice, but requires to set up a list of the best planes to include (top 30 best planes ?), and that list may not be the one every single user would have established. 2) removing the port and consider users have to install additional planes *manually*. After all, those airplanes are only addons ; limiting the ports to flightgear + flightgear-data, which already ship with several airplanes, does not seem crazy to me. A third option would have been to provide the full list of available airplanes but only select a few of them through OPTIONS, but I'd like to avoid going this way : this will not simplify the port at all, it will only make it harder to maintain as the OPTIONS list will be huge, and (maybe ?) pointless for the end-user. Flightgear users, I would go for option 2), but what do *you* think ? Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: About games/flightgear-aircrafts
On Thu, 22 Sep 2011 10:07:40 +0100, Anton Shterenlikht wrote Chris, Anton, Thanks for your feedback. 4) add-on ports? yes, this seems to be the case with latex, works fine. I am not sure to understand what you mean exactly. Could you be more precise ? -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: About games/flightgear-aircrafts
On Thu, 22 Sep 2011 08:52:56 -0400, Greg Larkin wrote Hi Greg, [...] If you can break the flightgear airplanes (or subsets of airplanes) into a number of add-on ports, that would be one way to avoid the huge download problem, as well as an excessive number of OPTIONS in the base port. Of course, the add-on port idea assumes that airplanes can be downloaded individually in some fashion. Thanks for this explanation. I had thought about that option too, but the same questions as my first solution remain : what should be the list of the available ports ? I really have no idea here : any craft may be interesting to players. Also, if this list could be established, why not keep a single port (which would then be *a lot* easier to maintain) ? To sum um, in my opinion, there are in really 2 options : 1) Limit the port to a few selected aircrafts = (either in one port or split) 2) Remove the port I can go for 1), but I would need help to establish the list of aircrafts you'd like... :p Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: About games/flightgear-aircrafts
On Thu, 22 Sep 2011 09:38:33 -0400, Greg Larkin wrote You can also break them by first letter of the distfile names, combining where appropriate. [...] On Thu, 22 Sep 2011 09:57:58 -0400, Robert Huff wrote my first reaction was to break it into broad categories. For example: aircraft-required aircraft-25-most-popular aircraft-civilian-prop [...] On Thu, 22 Sep 2011 16:58:03 +0200, Guido Falsi wrote A civialian-aerobatic category could be sensible. [...] Greg, Robert, Guido, thanks for your suggestions ; anyway, this would not solve one of the problems : maintainability of the port :/ On Thu, 22 Sep 2011 08:11:39 -0600 (MDT), Warren Block wrote #2 is reasonable, IMO. Other options, like breaking it up into multiple ports, would not make it easier to maintain and might be more difficult for users. Warren, I agree with you : it would make the port even more complex. From a maintainer port of view, we will still have to keep up-to-date with those 350+ zip files which regularly change upstream, but will now have to deal with sorting them and updating several different ports. From a user point of view, it would also be a pain : users would have to browse into each category ports to be able to get all the planes they need. I am not sure this is the right way to go :/ I would also vote for #2, or, if we can get a limited list of good airplanes, option #1. I will try to find if I can get a list of top planes on FLightGear website, but I have not seen such a page so far. (Note: aircraft is both singular and plural, so the port name really should be just flightgear-aircraft.) Thanks, I'll fix its name if we can manage to keep this port alive :) Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: [CFT] Dolphin-emu preliminary port
On Thu, 25 Aug 2011 08:27:05 +0200 (CEST), Ganael LAPLANCHE wrote Hi everyone, The port has been updated : Dolphin now builds and run on amd64 (the MAP_FIXED hack now works). A new version of the port is available, following the integration of several patches into the main branch. I think the port has now reached enough quality to hit the tree : - NLS can be disabled - Options are provided tu enable/disable PortAudio and PulseAudio (OpenAL is used by default). You can try it here : http://contribs.martymac.org/FreeBSD-ports/sandbox/dolphin-emu-3.0.r20110912-port.tgz And follow the thread on Dolphin forums : http://forums.dolphin-emulator.com/showthread.php?tid=8254 OpenGL still needs testing : does it work on your box ? I would be happy to get comments on that. Yes, I'd be glad to get feedback on OpenGL rendering (for those who have support for the GL_EXT_framebufer_object, otherwise, it'll just crash). I've still only been able to test software rendering... Don't hesitate to contact me if you need more info or if you can test the software. Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: [CFT] Dolphin-emu preliminary port
On Tue, 19 Jul 2011 13:38:16 +0200, Ganael Laplanche wrote Hi list, I've been working on a dolphin (Wii/GC emulator) port, see : http://forums.dolphin-emulator.com/showthread.php?tid=8254 The emulator works on i386 with software rendering. Unfortunately, I can't get OpenGL rendering work on my laptop, because of lack of support for GL_EXT_framebufer_object. I would be glad to see if some of you can get it working. Amd64 support is not ready yet because of the lack of a MAP_32BIT flag for mmap(2). I've tried a workaround, but without much luck (using MAP_FIXED). The port has been updated : Dolphin now builds and run on amd64 (the MAP_FIXED hack now works). OpenGL still needs testing : does it work on your box ? I would be happy to get comments on that. Please, see Dolphin's forum thread if you are interested in testing the port. Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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
[CFT] Dolphin-emu preliminary port
Hi everyone, I've been working on a dolphin (Wii/GC emulator) port, see : http://forums.dolphin-emulator.com/showthread.php?tid=8254 The emulator works on i386 with software rendering. Unfortunately, I can't get OpenGL rendering work on my laptop, because of lack of support for GL_EXT_framebufer_object. I would be glad to see if some of you can get it working. Amd64 support is not ready yet because of the lack of a MAP_32BIT flag for mmap(2). I've tried a workaround, but without much luck (using MAP_FIXED). Comments are welcome ! Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.FreeBSD.org signature.asc Description: This is a digitally signed message part.
Re: [CFT] Dolphin-emu preliminary port
On Tue, 19 Jul 2011 13:55:11 +0200, Bernhard Froehlich wrote Dolphin is on our WantedPorts list so I've updated the entry with your infos. http://wiki.freebsd.org/WantedPorts Thanks Bernhard ! -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: [CFT] Likewise-open preliminary port
On Fri, 24 Jun 2011 03:31:00 -0500, Brooks Davis wrote Hi Brooks, Have you tried asking Likewise for the ports they appear to be using internally to build packages for FreeBSD? I have posted a message on likewise-open-dev@ but has not received an answer yet... I don't know if they use proper ports or just a set of script to generate packages. While the normal Likewise install location in /opt/likewise is non- standard, I suspect most likewise users hardcode it in their scripts. I know I do. It seems generally useful to ease the upgrade path from a likewise-open port to likewise-enterprise. You're right, but such a port could not be part of the official tree ; maybe that's why there is no Likewise port yet. Anyway, we are not the only ones to rewrite paths ; Ubuntu also seems to install everything in more standard ones : http://packages.ubuntu.com/natty/amd64/likewise-open/filelist It seems that you are using Likewise, have you given the port a try ? Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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
[CFT] Likewise-open preliminary port
://www.likewise.com/resources/documentation_library/manuals/cifs/likewise- cifs-smb-file-server-guide.html * Forums : http://www.likewise.com/community/index.php/forums * Lists : http://lists.likewiseopen.org * Bug reports : http://lobugs.likewise.com Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.FreeBSD.org signature.asc Description: This is a digitally signed message part.
DATADIR recorded as a relative path in plist ?
Hi !
While struggling with DATADIR-safety messages from portlint, I've
noticed something very odd : DATADIR, which is supposed to be an
absolute path, is recorded as a relative path (to ${PREFIX}, I suppose)
in pkg-plist.
This leads to being unable to deinstall a port which has been installed
with a different DATADIR.
Here is a very simple example, easy to reproduce. It implies
misc/pciids, which is supposed to be DATADIR-safe as it uses the
%%DATADIR%% macro in its plist. Its 'do-install' target is as simple as :
do-install:
${MKDIR} ${DATADIR}
${INSTALL_DATA} ${WRKSRC}/pci.ids ${DATADIR}
So there is no special trick here, everything should go fine, but it
does not :
# cd /usr/ports/misc/pciids make DATADIR=/tmp/pciids install
=== Vulnerability check disabled, database not found
=== License BSD GPLv2 GPLv3 accepted by the user
=== Extracting for pciids-20101124
= SHA256 Checksum OK for pciids-20101124.tar.bz2.
=== Patching for pciids-20101124
=== Configuring for pciids-20101124
=== Installing for pciids-20101124
=== Generating temporary packing list
=== Checking if misc/pciids already installed
/bin/mkdir -p /tmp/pciids
install -o root -g wheel -m 444
/files/Ports/ports/misc/pciids/work/pciids-20101124/pci.ids /tmp/pciids
=== Registering installation for pciids-20101124
# ls /tmp/pciids
pci.ids
So far, so good : DATADIR is handled as an *absolute* path and pci.ids
has been installed into /tmp/.
Unfortunately, here is the content of the plist :
# pkg_info -L pciids-20101124
Information for pciids-20101124:
Files:
/usr/local//tmp/pciids/pci.ids
/usr/local/share/licenses/pciids-20101124/catalog.mk
/usr/local/share/licenses/pciids-20101124/LICENSE
/usr/local/share/licenses/pciids-20101124/BSD
/usr/local/share/licenses/pciids-20101124/GPLv2
/usr/local/share/licenses/pciids-20101124/GPLv3
DATADIR has been recorded as a *relative* path to ${PREFIX}. Obviously,
everything goes wrong when you try to uninstall the package :
# make DATADIR=/tmp/pciids deinstall
=== Deinstalling for misc/pciids
=== Deinstalling pciids-20101124
pkg_delete: file '/usr/local//tmp/pciids/pci.ids' doesn't exist
pkg_delete: file '/usr/local//tmp/pciids' doesn't exist
pkg_delete: unable to completely remove directory '/usr/local//tmp/pciids'
pkg_delete: couldn't entirely delete package (perhaps the packing list is
incorrectly specified?)
Am I missing something here ?
Best regards,
--
Ganael LAPLANCHE ganael.laplan...@martymac.org
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac marty...@freebsd.org, http://www.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: DATADIR recorded as a relative path in plist ?
On Wed, 02 Feb 2011 12:17:13 +0300, Anonymous wrote Hi, You cannot define DATADIR that's PREFIX-unsafe without using @cwd. And using @cwd makes `-p/-P' options in pkg_add(1) less useful. Not sure why portlint even mentions safeness for DOCSDIR/EXAMPLESDIR/DATADIR as they were never safe for *user* to override. Yes, I don't know either. I thought DATADIR could be overridden by users ; thanks for clarifying this. Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: Introducing USE_SRC and ONLY_FOR_*VER (was: CFR: patch to cleanup usage of SRC_BASE in various ports)
On Wed, 1 Dec 2010 10:38:10 +0200, Ion-Mihai Tetcu wrote
Hi,
It would be interesting to provide something like :
USE_BASE= yes
Which would do the following :
= defines ${SRC_BASE}
= checks for ${SRC_BASE}/sys/Makefile
= provides a standard error msg if not found
or, if set to something other than yes :
USE_BASE= some/file/within/src_base
= defines ${SRC_BASE}
= check for ${SRC_BASE}/some/file/within/src_base
= provides a standard error msg if not found
Thus, we would avoid having the same tests again and again, and be
able to provide more standard messages...
What do you think ?
Yes. It would help tracking some errors on automated build systems.
Following this idea, here is a small patch that provides that
functionality :
http://people.freebsd.org/~martymac/patches/20101203-patch-bsd.kmod.mk.txt
It provides :
- USE_SRC : to be set to yes or a space-separated list of files to
check under ${SRC_BASE}
- SRC_BASE : by default /usr/src if ${USE_SRC} is set, can be overridden
A standard message is displayed if kernel sources are missing.
I've also found that the ports that check for presence of kernel sources
also often check for a specific version of FreeBSD, so the patch also
provides :
ONLY_FOR_MINVER / ONLY_FOR_MINVER_REASON : the minimal version of
FreeBSD required to build the port, and a given reason (if any)
ONLY_FOR_MAXVER / ONLY_FOR_MAXVER_REASON : the maximal version of
FreeBSD required to build the port, and a given reason (if any)
Those variables will help us avoid duplicating the same kind of checks
again and again in our ports tree.
Find here :
http://people.freebsd.org/~martymac/patches/20101203-patch-uhso-kmod.txt
an example that shows how those variables could be used
(comms/uhso-kmod). Note that in this example, a change of behaviour is
introduced : the port will now refuse to build if OSVERSION 800500,
while it was only displaying a warning in the previous version. This
patch to hso-kmod is *not* to be committed, but just a showcase.
Comments welcome,
Best regards,
--
Ganael LAPLANCHE ganael.laplan...@martymac.org
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac marty...@freebsd.org, http://www.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: Introducing USE_SRC and ONLY_FOR_*VER (was: CFR: patch to cleanup usage of SRC_BASE in various ports)
On Fri, 3 Dec 2010 14:07:35 +0200, Ion-Mihai Tetcu wrote Submit a PR with it please. Done ports/152804. BTW, there was a mistake in the patch file name. It's been fixed ; the correct URL is now : http://people.freebsd.org/~martymac/patches/20101203-patch-bsd.port.mk.txt Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: CFR: patch to cleanup usage of SRC_BASE in various ports
On Tue, 30 Nov 2010 14:09:35 -0600, Ade Lovett wrote
Hi Ade, hi Mark !
Patch incorporating these suggestions, along with some other edge
cases I found, uploaded:
http://people.freebsd.org/~linimon/patches/diff.out.srcbase
http://people.FreeBSD.org/~ade/bpm.src_base.diff
Trivial addition to Mk/bsd.port.mk to prevent duplication of
SRC_BASE?= ... in individual port Makefiles.
Good patches, thanks ! But couldn't we extend this idea ?
Most of the time, ${SRC_BASE} is used to check whether some file
(mostly ${SRC_BASE}/sys/Makefile) exists or not, to return,
most of the time, the same error :
you need to extract kernel source tree before building this package
It would be interesting to provide something like :
USE_BASE= yes
Which would do the following :
= defines ${SRC_BASE}
= checks for ${SRC_BASE}/sys/Makefile
= provides a standard error msg if not found
or, if set to something other than yes :
USE_BASE= some/file/within/src_base
= defines ${SRC_BASE}
= check for ${SRC_BASE}/some/file/within/src_base
= provides a standard error msg if not found
Thus, we would avoid having the same tests again and again, and be
able to provide more standard messages...
What do you think ?
--
Ganael LAPLANCHE ganael.laplan...@martymac.org
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac marty...@freebsd.org, http://www.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: FreeBSD mencoder port problem
On Sat, 2 Oct 2010 18:21:28 +0200, Zahemszky Gábor wrote Hi, I've just found that libmpcdec has been deprecated in FreeBSD port. Because of it, there was an mplayer modification. The only problem is that mencoder has the same libmpcdec dependency, so it should be updated, too. Yes, you're right ! mencoder had missed libmpcdec removal. This is fixed now. Thanks for your report ! Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.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: FreeBSD Port: amule-10275
On Wed, 22 Sep 2010 12:42:37 +0200, Paolo Bormida wrote To: ganael.laplan...@martymac.org Hi Paolo, (this is a re-post of my previous, private answer) I am sorry but I am no more the maintainer of aMule. You should get in touch with swel...@gmail.com, who is the new maintainer. Sorry to bother you, but I think I understood the problem I described in this post to the freebsd forums: http://forums.freebsd.org/showthread.php?t=17961 Does amule2 port switched from a stable 2.2.5 release to a daily snapshot? Does the sparc64 port still has the daily snapshot instad of the more up-to-date 2.2.6_4 available? You can find the history of the changes made to this port on Freshports here : http://www.freshports.org/net-p2p/amule2 Yes, the ports seems to have switched to using a code snapshot on Aug, 13 2010 with version r.10266, leaving version 2.2.6 behind. Best regards, Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.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: Call for testers - mplayer svn port
On Thu, 7 Jan 2010 22:52:51 +0100, Thomas Zander wrote Hi Thomas, Hi Martin, Happy new year :) thanks to Wes Morgan and Martin Wilke there is something for you to test which approximates what's going to become our next mplayer in the ports tree. Thanks for this update. I have had no time to test the port yet unfortunately, but reading files/patch-stream-stream_dvd.h, I see that you use an included libdvdread. I think it would be great to use our (ports') version. It is the one released by the Mplayer team, so it should build without trouble (I hope so). By the way, Martin, I have an old PR waiting for approval (see http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/131969). It suggests switching to Mplayer's version of libdvdnav. It may be interesting to switch to this version and add libdvdnav support to the new Mplayer port... Best regards, Ganaël LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.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
Switching to MPlayer's libdvdnav (ports/131969)
Hello everyone :) (CC: to freebsd-multimedia@) I have updated PR ports/131969. Could a committer have a look at it ? Thank you very much, Best regards, Ganaël LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.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
Switching to MPlayer's libdvdnav (ports/131969)
Hello everyone :) (CC: to freebsd-multimedia@) I have updated PR ports/131969. Could a committer have a look at it ? Thank you very much, Best regards, Ganaël LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.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: multimedia/pwcbsd fails on up to date current.
On Thu, 04 Jun 2009 08:56:43 -0500, eculp wrote Hello, I can't compile multimedia/pwcbsd on my laptop running current with ports, kernel, userland up to date. See this mail : http://lists.freebsd.org/pipermail/freebsd-usb/2009-May/006866.html USB2 Symbols have been renamed. You'll have to fix the port's patch to make it build under recent -current. Best regards, Ganaël LAPLANCHE ganael.laplan...@martymac.com http://www.martymac.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
USE_LINUX_RPM and PORTDOCS
Hi everybody, One of my ports, archivers/linux-par2cmdline, uses a RPM that contains documentation, but does not (yet) handle the NOPORTDOCS option. An error is generated in Tinderbox and complains that documentation files remain on the filesystem after deinstallation. See : http://t64.tecnik93.com/logs/7-STABLE-FTP/linux-par2cmdline-0.4.log as reported by Itetcu. My port uses both the USE_LINUX_RPM facility and PORTDOCS variable. What happens is that passing NOPORTDOCS=yes to the port is ignored by bsd.linux-rpm.mk's do-install target which installs documentation anyway (as any other file). As I have also declared documentation files with the PORTDOCS variable, they are *not* deinstalled when using NOPORTDOCS=yes. So, I am a bit stuck since bsd.linux-rpm.mk does not seem to provide a way to handle that case... I see two options : - Override the do-install target and do things manually, which seems a bad idea since several actions are involved in installing linux files (brandelf, cpio, ...) - Do not use PORTDOCS option anymore and treat doc files as any other file, but this implies installing documentation files even if it has not been requested by the user. I could even use AUTOMATIC_PLIST for that... What would be the best option ? Would you have any other idea ? Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USE_LINUX_RPM and PORTDOCS
On Sat, 24 May 2008 13:04:57 +0400, Boris Samorodov wrote I'd suggest another option. What about fixing bsd.linux-rpm.mk? Ex., one may introduce, say, a pre-install target (or even do it at the very beginning of a do-install stage) and conditionally delete unneeded files from WRKDIR (so they won't get installed at do-install stage). Thanks for your answer :) Of course, fixing bsd.linux-rpm.mk would be the best option ! Your idea is good, but PORTDOCS would not be useable for that purpose. It cannot be used to identify files to delete because it is relative to the destination target (DOCSDIR), not to WRKDIR or WRKSRC. A good idea may be to introduce a new variable, say RMWRKDIRFILES= (something like that) and a target, as you suggest, that would delete all those files relative to WRKDIR, before the install target. Note that this idea is not limited to bsd.linux.mk and could be introduced more generally in bsd.port.mk. Of course, considering my original post and port problem, I can do this manually if this idea is not a good one :p Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USE_LINUX_RPM and PORTDOCS
On Sat, 24 May 2008 17:27:04 +0200 (CEST), Ganael LAPLANCHE wrote
On Sat, 24 May 2008 13:04:57 +0400, Boris Samorodov wrote
I'd suggest another option. What about fixing bsd.linux-rpm.mk? Ex.,
one may introduce, say, a pre-install target (or even do it at the
very beginning of a do-install stage) and conditionally delete
unneeded files from WRKDIR (so they won't get installed at do-install
stage).
Thanks for your answer :)
Of course, fixing bsd.linux-rpm.mk would be the best option !
Your idea is good, but PORTDOCS would not be useable for that purpose.
It cannot be used to identify files to delete because it is relative
to the destination target (DOCSDIR), not to WRKDIR or WRKSRC.
Wait... DOCSDIR_REL (relative to PREFIX) is derived from DOCSDIR and *may* be
also always relative to WRKDIR for linux RPMs, since RPM installation is just a
copy of a tree structure which is relative to PREFIX. So maybe I was wrong here.
Anyway, if I add that to my archivers/linux-par2cmdline port's Makefile :
.if defined(NOPORTDOCS)
post-extract:
.for x in ${PORTDOCS}
@${RM} ${WRKDIR}/${DOCSDIR_REL}/${x}
.endfor
@${RMDIR} ${WRKDIR}/${DOCSDIR_REL}/
.endif
It works :) So I think I'll stick to that solution at the moment. Note that two
other linux ports are subject to the same problem as mine :
/usr/ports/graphics/linux-png and /usr/ports/graphics/linux-png10.
Best regards,
Ganaël LAPLANCHE
[EMAIL PROTECTED]
http://www.martymac.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USE_LINUX_RPM and PORTDOCS
On Sat, 24 May 2008 20:49:29 +0400, Boris Samorodov wrote Great, but I'd say that it should be done a little bit later (may be at pre-install stage). Not sure about that because when using AUTOMATIC_PLIST in bsd.linux-rpm.mk, pre-install depends on target linux-rpm-generate-plist. So, plist is generated *before* pre-install target. Removing files at pre-install target would break the plist generated. Or am I wrong ? Moreover, I like to know that after the post-extract stage, WRKDIR is clean and has each file I want to work with... Yes, that's why I said that fixing bsd.linux-rpm.mk is a better idea. If you can suggest a patch and send-pr it, that would be great! I'll try to, but I won't have much time these days :p Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USE_LINUX_RPM and PORTDOCS
On Sat, 24 May 2008 19:38:44 +0200, Alexander Leidinger wrote
Not sure about that because when using AUTOMATIC_PLIST in bsd.linux-rpm.mk,
AUTOMATIC_PLIST is evil. For linux-rpm ports I see absolutely no value
in using it (we just added it to cut down the noise from one committer,
one or two ports out of all the ones we have is not going to hurt us
that much). So don't care about it.
Ok.
Great, but I'd say that it should be done a little bit later (may be
at pre-install stage). Extract stage according to bsd.ports.mk
Unpacks ${DISTFILES} into ${WRKDIR}.
Removing unwanted stuff in post-extract is not uncommon. I don't think
a patch for linux-rpm.mk with something like this would be a bad
solution.
Ok, great. As I said earlier, I'll try to provide a patch to bsd.linux-rpm.mk to
handle that.
Thanks for your help :)
Ganaël LAPLANCHE
[EMAIL PROTECTED]
http://www.martymac.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USE_LINUX_RPM and PORTDOCS
On Sat, 24 May 2008 12:17:07 -0600, John E Hein wrote
Why not pre- or post-patch - part of a stage that implies a
modification of unpacked distfile(s)?
You are right, pre-patch may be better than post-extract in this way. I think
pre-patch is better than post-patch because one does not want to patch files
that won't be used in any way. It would also allow to avoid errors, not working
on files that will be deleted :p
I have successfully tested this patch against bsd.linux-rpm.mk with
archivers/linux-par2cmdline, graphics/linux-png and
/usr/ports/graphics/linux-png10 :
8---
--- bsd.linux-rpm.mk.orig 2008-05-24 20:46:04.931665759 +0200
+++ bsd.linux-rpm.mk2008-05-24 21:32:51.721449935 +0200
@@ -105,6 +105,20 @@
BRANDELF_DIRS?=
BRANDELF_FILES?=
+# For ports that define PORTDOCS, be sure not to install
+# documentation if NOPORTDOCS is defined
+.if defined(PORTDOCS) defined(NOPORTDOCS)
+pre-patch: linux-rpm-clean-portdocs
+
+. if !target(linux-rpm-clean-portdocs)
+linux-rpm-clean-portdocs:
+.for x in ${PORTDOCS}
+ @${RM} -f ${WRKDIR}/${DOCSDIR_REL}/${x}
+.endfor
+ @${RMDIR} ${WRKDIR}/${DOCSDIR_REL}
+. endif
+.endif
+
. if defined(AUTOMATIC_PLIST)
.if ${USE_LINUX} == fc4 || ${USE_LINUX:L} == yes
8---
Any opinion welcome ;-)
Ganaël LAPLANCHE
[EMAIL PROTECTED]
http://www.martymac.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USE_LINUX_RPM and PORTDOCS
On Sun, 25 May 2008 00:00:57 +0400, Boris Samorodov wrote Seems that we found a consensus here ;-) The patch is OK to me, thanks! Great, so I'm gonna file a PR for that one... Best regards, Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFT: devel/directfb update to 1.1.1
On Wed, 16 Apr 2008 01:50:46 +0200, Pietro Cerutti wrote Hi guys, Hi Pietro, A patch to update devel/directfb to 1.1.1 is ready to be committed, but I would like to have some feedback first: Unfortunately, it does not compile on my machine (FreeBSD 6.3-STABLE, amd64) : cc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../lib -I../../include -I../../lib -DDATADIR=\/usr/local/share/directfb-1.1.1\ -DMODULEDIR=\/usr/local/lib/directfb-1.1-0\ -D_REENTRANT -pthread -I/usr/local/include -O3 -ffast-math -pipe -O -pipe -D_GNU_SOURCE -Werror-implicit-function-declaration -MT conf.lo -MD -MP -MF .deps/conf.Tpo -c conf.c -fPIC -DPIC -o .libs/conf.o conf.c: In function `direct_config_set': conf.c:210: error: implicit declaration of function `sigaddset' gmake[3]: *** [conf.lo] Erreur 1 gmake[3]: quittant le répertoire « /usr/ports/devel/directfb/work/DirectFB-1.1.1/lib/direct » gmake[2]: *** [all-recursive] Erreur 1 gmake[2]: quittant le répertoire « /usr/ports/devel/directfb/work/DirectFB-1.1.1/lib » gmake[1]: *** [all-recursive] Erreur 1 gmake[1]: quittant le répertoire « /usr/ports/devel/directfb/work/DirectFB-1.1.1 » gmake: *** [all] Erreur 2 *** Error code 2 Stop in /usr/ports/devel/directfb. I've also tried to update directfb for several days, and managed to build it by using additional patches. Unfortunately, it seemed unuseable with mplayer, and crashed every time. Maybe my work can be useful to you : http://contribs.martymac.com/FreeBSD-ports/misc/directfb-1.1.1-port.attempt.tgz Best regards, Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFT: devel/directfb update to 1.1.1
On Wed, 16 Apr 2008 10:38:43 +0200, Pietro Cerutti wrote Sorry, I made an error rolling the patch. Please try again, the patch is always at: http://gahr.ch/FreeBSD/patches/_pending/directfb_complete.diff Thanks! Hi again, the port now builds/installs fine, but unfortunately leads to the same situation as my previous tests :/. I have defined WITH_SDL and WITH_X11, but I still cannot use -vo directfb with mplayer (compiled with directfb support). % env DFBARGS=system=sdl ./mplayer -vo directfb test.avi ===| DirectFB 1.1.1 |=== (c) 2001-2007 The DirectFB Organization (directfb.org) (c) 2000-2004 Convergence (integrated media) GmbH (*) DirectFB/Core: Single Application Core. (2008-04-16 09:15) (!) DirectFB/core/system: No system found! vo_directfb2.c 269: (#) DirectFBError [DirectFBCreate (dfb)]: No (suitable) implementation found! (same error with DFBARGS=system=x11) % dfbinfo --dfb:system=sdl ===| DirectFB 1.1.1 |=== (c) 2001-2007 The DirectFB Organization (directfb.org) (c) 2000-2004 Convergence (integrated media) GmbH (*) DirectFB/Core: Single Application Core. (2008-04-16 09:54) (*) Direct/Memcpy: Using Generic 64bit memcpy() (*) Direct/Thread: Running 'SDL Input' (INPUT, 55714)... (*) DirectFB/Input: SDL Input 0.1 (Denis Oliver Kropp) (*) DirectFB/Graphics: SDL Graphics 0.1 (directfb.org) (*) Direct/Thread: Running 'Screen Update' (OUTPUT, 55714)... (*) DirectFB/Core/WM: Default 0.3 (directfb.org) (!) DirectFB/Genefx: Could not lock destination! -- Not supported! (!) Core/LayerRegion: Could not lock region surface for SetRegion()! -- Not supported! (!) Core/LayerRegion: realize_region() in dfb_layer_region_flip_update() failed! -- Not supported! Screen (00) SDL Primary Screen (primary screen) Caps: Layer (00) SDL Primary Layer (primary layer) Type:GRAPHICS Caps:SURFACE Input (00) SDL Input (primary keyboard) Type: KEYBOARD MOUSE JOYSTICK Caps: KEYS AXES BUTTONS Max. Axis: 0 Max. Button: 0 % dfbinfo --dfb:system=x11 ===| DirectFB 1.1.1 |=== (c) 2001-2007 The DirectFB Organization (directfb.org) (c) 2000-2004 Convergence (integrated media) GmbH (*) DirectFB/Core: Single Application Core. (2008-04-16 09:54) (*) Direct/Memcpy: Using Generic 64bit memcpy() (*) X11/Display: Depth 24 (*) X11/Display: Visual (35) 0x00ff, 0xff00, 0x00ff, 8 bits, 256 entries (*) X11/Display: Visual (36) 0x00ff, 0xff00, 0x00ff, 8 bits, 256 entries (*) X11/Display: Visual (37) 0x00ff, 0xff00, 0x00ff, 8 bits, 256 entries (*) X11/Display: Visual (38) 0x00ff, 0xff00, 0x00ff, 8 bits, 256 entries (*) X11/Display: Visual (39) 0x00ff, 0xff00, 0x00ff, 8 bits, 256 entries (*) X11/Display: Visual (40) 0x00ff, 0xff00, 0x00ff, 8 bits, 256 entries (*) X11/Display: Visual (41) 0x00ff, 0xff00, 0x00ff, 8 bits, 256 entries (*) X11/Display: Visual (42) 0x00ff, 0xff00, 0x00ff, 8 bits, 256 entries (*) X11/Display: Depth 1 (*) X11/Display: Depth 4 (*) X11/Display: Depth 8 (*) X11/Display: Depth 15 (*) X11/Display: Depth 16 (*) X11/Display: Depth 32 (*) X11/Display: Visual (99) 0x00ff, 0xff00, 0x00ff, 8 bits, 256 entries (*) Direct/Thread: Running 'X11 Input' (INPUT, 55718)... (*) DirectFB/Input: X11 Input 0.1 (directfb.org) (*) DirectFB/Graphics: Generic Software Rasterizer 0.6 (directfb.org) (*) DirectFB/Core/WM: Default 0.3 (directfb.org) Screen (00) X11 Primary Screen (primary screen) Caps: Layer (00) X11 Primary Layer (primary layer) Type:GRAPHICS Caps:SURFACE Input (00) X11 Input (primary keyboard) Type: KEYBOARD MOUSE JOYSTICK Caps: KEYS AXES BUTTONS Max. Axis: 0 Max. Button: 0 If I remember correctly, I managed to bypass this 'no system found' error by replacing two readdir_r calls by readdir ones (weird...), but directfb failed afterwards, so I gave up (you can see those two additional patches in the port tarball of my previous post). Best regards, Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFT: devel/directfb update to 1.1.1
On Wed, 16 Apr 2008 16:01:43 +0300, Anatoly Borodin wrote
Hi!
Hi :)
1) Did your mplayer work with the previous version of directfb?
No, since the previous version of directfb didn't install neither sdl nor x11
drivers.
2) Have you rebuilt mplayer?
Yes, using --enable-directfb. The lib is detected, everything is built
(hopefully) correctly.
links doesn't work with directfb on my machine, so I'll investigate
the reason pretty soon. And I think it will good to fix mplayer and
add directfb flags to the ports.
% env DFBARGS=system=sdl ./mplayer -vo directfb test.avi
Try to run it with system=x11 please and tell what happens.
It produces the same error as previously reported : No system found!. Very
strange, but applying those two patches allows the libs to be found and mplayer
to (nearly) start :
--- lib/direct/interface.c.orig 2008-04-12 13:25:57.542006795 +0200
+++ lib/direct/interface.c 2008-04-12 13:26:27.732927708 +0200
@@ -164,7 +164,7 @@
/*
* Iterate directory.
*/
- while (readdir_r( dir, tmp, entry ) == 0 entry) {
+ while (entry = readdir( dir )) {
void *handle = NULL;
char buf[4096];
--- lib/direct/modules.c.orig 2008-04-12 13:25:45.166038341 +0200
+++ lib/direct/modules.c2008-04-12 13:27:56.054698492 +0200
@@ -158,7 +158,7 @@
return 0;
}
- while (readdir_r( dir, tmp, entry ) == 0 entry) {
+ while (entry = readdir( dir )) {
void *handle;
DirectModuleEntry *module;
intentry_len = strlen(entry-d_name);
Best regards,
Ganaël LAPLANCHE
[EMAIL PROTECTED]
http://www.martymac.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: net/grsync fails to build on i386
On Tue, 25 Mar 2008 23:12:56 +0200, Peter Pentchev wrote Hi Peter, It is quite possible that you caught the small time window just after the GNOME upgrade, in which bsd.gnome.mk was missing two lines that recorded LIB_ and RUN_DEPENDS. Thus, even though you specified gtk20 in your port's Makefile, bsd.gnome.mk just didn't add a dependency on libgtk - so your port's build did not find it. Since this was corrected a couple of hours later, I strongly suspect that the next automated build will go just fine. Thank you very much for your answer. It must explain why I was not able to reproduce the problem... I'll wait for the next build :) Best regards, Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: net/grsync fails to build on i386
On Tue, 25 Mar 2008 23:55:06 -0500, Jeremy Messenger wrote Hi Jeremy, No, it's not USE_XLIB. It's bsd.gnome.mk problem that was fixed by marcus yesterday. Two lines were removed by accident. It's what I believe that caused these logs. Yes, Peter told me about that :p Thanks a lot for your answer too ! Best regards, Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
net/grsync fails to build on i386
Hi everybody, I try to understand what happens here : http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.2008032407/grsync-0.6.1.log Since yesterday, my net/grsync port seems to refuse to build on i386. The configure script uses (expanded) : pkg-config --exists --print-errors 'gtk+-2.0' which leads to the error 'No package 'gtk+-2.0' found'. This error message is clear. What I don't understand is that the dependency against gtk20 is explicitly specified in the Makefile, so why has gtk+-2.0 not been installed during the build process (and does not appear in the log file) ? Am I missing something ? Thank you for your help, Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: net/grsync fails to build on i386
On Tue, 25 Mar 2008 20:46:47 +0100 (CET), Ganael LAPLANCHE wrote Am I missing something ? Well, after having read the docs again, it is written here : http://www.freebsd.org/gnome/docs/porting.html If your port needs only GTK2 libraries, the following is the shortest way to define this: USE_XLIB=yes USE_GNOME= gtk20 USE_XLIB= yes is missing is the port. Could that be the problem ? Everything worked fine before yesterday, could that be related to the Gnome update ? Several gnome apps seem not to build anymore since yesterday (e.g.) : http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.2008032407/gsnapshot-1.0.log http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.2008032407/gtick-0.4.1.log Very strange, USE_XLIB= yes is also missing for them... Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
