Re: CFT: FreeBSD Package Base
On Mon, Apr 29, 2019 at 10:09 AM Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > Correct, this is ZFS only. And it's something we're using specific to > FreeNAS / TrueOS, which is why I didn't originally mention it as apart of > our CFT. > > Then please it is "CFT: FreeNAS/TrueOS pkg base, ZFS only", > calling this FreeBSD pkg base when it is not was wrong, > and miss leading. > Sorry, I disagree. This pkg base is independent of the ZFS tool we're using to wrangle boot-environments. Hence why it wasn't mentioned in the CFT. These base packages work the same as existing in-tree pkg base on UFS, no difference. If anything are probably safer due to being able to update all of userland in single extract operation, so you don't have out of order extraction of libc or some such. > > > For UFS, there will need to be additional care taken when doing updates. > > > > -- > > Kris Moore > > Vice President of Engineering > > iXsystems, Inc > > Ph: (408) 943-4100 > > Ph: (408) 943-4101 > > The Groundbreaking TrueNAS M-Series - > > Enterprise Storage & Servers Driven By Open Source > > > > -Original Message- > > From: Goran Meki? > > Sent: Monday, April 29, 2019 9:43 AM > > To: Kris Moore > > Cc: Emmanuel Vadot ; FreeBSD Stable < > freebsd-sta...@freebsd.org>; FreeBSD Current ; > freebsd-pkgb...@freebsd.org; freebsd-...@freebsd.org; > freebsd-hack...@freebsd.org; freebsd-ports@freebsd.org > > Subject: Re: CFT: FreeBSD Package Base > > > > On Mon, Apr 29, 2019 at 09:25:05AM -0400, Kris Moore wrote: > > > We've written our own tool "sysutils/sysup" in GO which handles this. > > > It performs updates using Boot-Environments to ensure that > > > kernel/world are updated at same time. > > > > If I'm right, UFS doesn't support boot environments, so how would it > work for UFS based installs? > > > > I personally feel GO is a bit ackward choice of language for something > that practically should be part of base. At least I would expect OS > update/upgrade not to require any external package. > > > > Regards, > > meka > > > > ___ > > freebsd-curr...@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > > > > > -- > Rod Grimes > rgri...@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: CFT: FreeBSD Package Base
On Mon, Apr 29, 2019 at 9:55 AM Emmanuel Vadot wrote: > On Mon, 29 Apr 2019 09:25:05 -0400 > Kris Moore wrote: > > > On Mon, Apr 29, 2019 at 8:12 AM Emmanuel Vadot > > wrote: > > > > > > > > Hi Kris, > > > > > > On Sun, 28 Apr 2019 15:52:21 -0400 > > > wrote: > > > > > > > FreeBSD Community, > > > > > > > > > > > > > > > > I'm pleased to announce a CFT for builds of FreeBSD 12-stable and > > > 13-current > > > > using "TrueOS-inspired" packaged base. These are stock FreeBSD images > > > which > > > > will allow users to perform all updating via the 'pkg' command > directly. > > > > Rather than trying to answer all questions in this announcement, > we've > > > > created a FAQ page with more details. Please refer to this page, and > let > > > us > > > > know if you have additional questions that we can include on that > page > > > going > > > > forward. > > > > > > > > > > While I appreciate the effort I have some doubt about your > > > "re-implementation" of pkgbase. I don't see any improvement compared to > > > what is in base currently, I even see downside of your implementation. > > > > > > - How do you plan with the need of updating kernel first, reboot and > > > updating the rest of the userland after ? (Needed for major and minor > > > upgrade, 12.0 to 12.1 for example, and simple update in -STABLE and > > > -HEAD branch). This is still a problem with the base pkgbase. > > > > > > > We've written our own tool "sysutils/sysup" in GO which handles this. It > > performs updates using Boot-Environments to ensure that kernel/world are > > updated at same time. > > > > Which could never be imported into FreeBSD. > Not suggesting it should be. Just information on how we solved that problem in our own appliance / platforms. For FreeBSD it would need some tooling still to handle this style of updating, regardless of which pkg base is used. And for what it's worth, FreeBSD is all the poorer for not being able to bring modern language based tools into the base. Personally I'm hoping the shift to base-packages makes this a moot point since the idea of 'what is base' can be diluted to just a manifest of what gets installed out of box. Just my 2C on the matter though :) > > > > > > > > - This is even worse because you are using the same repository for > > > base and pkg so if a user pkg update and both kernel and pkg(8) needs > > > to be updated and pkg use a new syscall or capsicum thing it will be > > > updated first and couldn't proceed with the rest of the update (this is > > > a supposition, I haven't personally tested). > > > > > > > See above. > You can selectively update os/kernel and reboot before doing rest. > > > > > > > - It seems that multiple kernels isn't supported in your > > > implementation, this is already supported in pkgbase but still need > > > some love. This is an important point as it will allow user to choose > > > easily the kernel that they want to use and will also allow us > > > developper to push kernels with new features to help testing. > > > > > > > Incorrect, on the 13-CURRENT build if you install kernel-debug, you'll > get > > the Witness-enabled kernel installed alongside non-debugging one. > > Mhm no, the kernel-debug packages only add the debug file > in /usr/lib/debug/boot/ > I'm talking about installing multiple kernels in // > (i.e. /boot/kernel.GENERIC /boot/kernel.MYFEATUREIWANTTOTEST) like > describe here : > > https://wiki.freebsd.org/PkgBase#Project_goals_and_additional_unresolved_issues > in the "How to handle /boot/kernel and /boot/kernel.$KERNCONF" point. > > Incorrect, os/kernel-debug installs /boot/kernel-debug which is (on 13-CURRENT) the Witness enabled kernel. os/kernel-debug-symbols are the /usr/lib/debug bits. > > > > > > > I think that the only advantage that your solution offers is that if > > > we remove a componant of base (rcmds for example in 12-CURRENT) those > > > files would be removed as they are in the userland-base package while > > > for pkgbase the FreeBSD-rcmd package will be deleted in the repo and > > > will not be deleted in the user computer. > > > > > > > > > Correct, this is one of the things which prompted us to go this >
Re: CFT: FreeBSD Package Base
On Mon, Apr 29, 2019 at 8:12 AM Emmanuel Vadot wrote: > > Hi Kris, > > On Sun, 28 Apr 2019 15:52:21 -0400 > wrote: > > > FreeBSD Community, > > > > > > > > I'm pleased to announce a CFT for builds of FreeBSD 12-stable and > 13-current > > using "TrueOS-inspired" packaged base. These are stock FreeBSD images > which > > will allow users to perform all updating via the 'pkg' command directly. > > Rather than trying to answer all questions in this announcement, we've > > created a FAQ page with more details. Please refer to this page, and let > us > > know if you have additional questions that we can include on that page > going > > forward. > > > > While I appreciate the effort I have some doubt about your > "re-implementation" of pkgbase. I don't see any improvement compared to > what is in base currently, I even see downside of your implementation. > > - How do you plan with the need of updating kernel first, reboot and > updating the rest of the userland after ? (Needed for major and minor > upgrade, 12.0 to 12.1 for example, and simple update in -STABLE and > -HEAD branch). This is still a problem with the base pkgbase. > We've written our own tool "sysutils/sysup" in GO which handles this. It performs updates using Boot-Environments to ensure that kernel/world are updated at same time. > - This is even worse because you are using the same repository for > base and pkg so if a user pkg update and both kernel and pkg(8) needs > to be updated and pkg use a new syscall or capsicum thing it will be > updated first and couldn't proceed with the rest of the update (this is > a supposition, I haven't personally tested). > See above. > - It seems that multiple kernels isn't supported in your > implementation, this is already supported in pkgbase but still need > some love. This is an important point as it will allow user to choose > easily the kernel that they want to use and will also allow us > developper to push kernels with new features to help testing. > Incorrect, on the 13-CURRENT build if you install kernel-debug, you'll get the Witness-enabled kernel installed alongside non-debugging one. > - Since you reduced the granularity on the userland bits it would mean > that if we use your implementation for -p updates we would download the > whole userland packages instead of just updating the package that was > patched. For example with pkgbase, updating from 12.0 to 12.0p1 will > only update the FreeBSD-runtime package. Yes this package is still big > to download when you compare to what have changed but until pkg(8) have > delta pkg supports (and if it will have support, I don't know if > this is a wish or not) this is the best way to go. > Correct, this is by design. We used the in-tree pkg base for nearly a year, and found that the granularity didn't really offer any savings from a download or time perspective. Updating 100+ packages took far longer than a single one, due to all the meta operations. Additionally in real-world usage, we found that base packages tended to all get updated at the same time, which took far longer via pkg, since it had to go and perform 100+ fetch operations just to download the base system bits. > - I see that you are sorting the plist for kernel and userland based > on the line length [1], why is that ? Whoops! I'll fix :) > > I think that the only advantage that your solution offers is that if > we remove a componant of base (rcmds for example in 12-CURRENT) those > files would be removed as they are in the userland-base package while > for pkgbase the FreeBSD-rcmd package will be deleted in the repo and > will not be deleted in the user computer. > Correct, this is one of the things which prompted us to go this direction. Being able to handle crazy mixed WITH/WITHOUT flags was important to us, current pkg base did not handle that so gracefully. Additionally we've added some additional features, such as being able to 'pkg install os/src' to get system sources used in exact build, as well as being able to rebuild your local world / kernel packages using ports "make config" framework is super handy. > > > > > Additionally, I will be hosting a Package Base working group at BSDCan > 2019, > > and welcome user and developer attendance to discuss this and other > ongoing > > package work: > > > > > > > > https://wiki.freebsd.org/DevSummit/201905/PackageBase > > > > I will be present and looking forward to work with you on this. > > Cheers, > > P.S. : FYI I'm working on pkgbase currently and I will have some > patches to commit soon (bsdinstall support, memstick creation that > install a pkgbase aware installaton etc ...). > Great! Looking forward to discussion then! > > [1] : > > https://github.com/trueos/trueos-ports/blob/trueos-master/os/userland-base/Makefile#L35 > > -- > Emmanuel Vadot > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To un
Re: FreeBSD Port: devel/cmake - cannot build without py-babel
On 07/15/2015 10:57, Miroslav Lachman wrote: > Hi, > cmake cannot be built in my poudriere setup. It always ends with the > same error (on FreeBSD 8.4 and 10.1) > > [ 99%] Building CXX object Source/CMakeFiles/cpack.dir/CPack/cpack.cxx.o > Linking CXX executable ../bin/cpack > [ 99%] Built target cpack > Scanning dependencies of target ctest > [ 99%] Building CXX object Source/CMakeFiles/ctest.dir/ctest.cxx.o > Linking CXX executable ../bin/ctest > [ 99%] Built target ctest > Scanning dependencies of target documentation > [100%] sphinx-build man: see Utilities/Sphinx/build-man.log > Traceback (most recent call last): > File "/usr/local/bin/sphinx-build", line 5, in > from pkg_resources import load_entry_point > File > "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", > line 3074, in > @_call_aside > File > "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", > line 3060, in _call_aside > f(*args, **kwargs) > File > "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", > line 3087, in _initialize_master_working_set > working_set = WorkingSet._build_master() > File > "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", > line 645, in _build_master > ws.require(__requires__) > File > "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", > line 946, in require > needed = self.resolve(parse_requirements(requirements)) > File > "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", > line 833, in resolve > raise DistributionNotFound(req, requirers) > pkg_resources.DistributionNotFound: The 'babel>=1.3' distribution was > not found and is required by Sphinx > *** Error code 1 > > Stop in /wrkdirs/usr/ports/devel/cmake/work/cmake-3.2.3. > *** Error code 1 > > Stop in /wrkdirs/usr/ports/devel/cmake/work/cmake-3.2.3. > *** Error code 1 > > Stop in /wrkdirs/usr/ports/devel/cmake/work/cmake-3.2.3. > *** Error code 1 > > Stop in /usr/ports/devel/cmake. > >> Cleaning up wrkdir > ===> Cleaning for cmake-3.2.3_1 > build of devel/cmake ended at Wed Jul 15 16:11:15 CEST 2015 > build time: 00:05:20 > !!! build failure encountered !!! > > > > The full log is here http://pastebin.com/5MxnT3K5 > > It worked two weeks ago without babel. > > Now Sphinx (py27-Jinja2) requires Babel extension. > > Is this intentional? > > Miroslav Lachman > ___ > 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" Yea, the update to sphinx looks like it needs babel for some functionality now. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201587 I've just commited this fix, let me know if it still fails. -- Kris Moore PC-BSD Software / iXsystems Enterprise Storage & Servers Driven By Open Source ___ 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: CentOS 6.6 base + userland
On 11/05/2014 14:24, Sergey V. Dyatko wrote:
> On Wed, 05 Nov 2014 14:21:36 -0500
> Kris Moore wrote:
>
>> On 11/05/2014 13:28, Sergey V. Dyatko wrote:
>>> On Wed, 05 Nov 2014 01:42:35 -0500
>>> Kris Moore wrote:
>>>
>>>> On 11/05/2014 00:07, Johannes Meixner wrote:
>>>>> On Tue, Nov 04, 2014 at 04:14:05PM -0500, Kris Moore wrote:
>>>>>> Does running skype require the lemul branch still, or what minimum
>>>>>> version of FreeBSD?
>>>>> It's a variant of Skype 4.2.0.13 which disguises itself as 4.3.0.37. So,
>>>>> actually, neither (yet). It's been floating around on IRC, mostly.
>>>>>
>>>>>
>>>>>
>>>> I've merged in the patch here. It mostly works, it was just missing this
>>>> port for www/linux-c6-flashplugin11 to function:
>>>>
>>>> https://github.com/pcbsd/freebsd-ports/tree/master/graphics/linux-c6-gdk-pixbuf
>>>>
>>>> I've tested skype4. It starts up, but I can't seem to connect. Might be
>>> deinstall linux*pulseaudio* (-force) and try again ;-)
>> Yea, don't have that installed. XMJ said something about it needing some
>> kludge of running 4.3 first, then grabbing a modified special binary? ;)
> login to 4.3 with autologin checked, after that replace skype with 'special
> binary' ;)
>
And that made it work, very cool! ;)
>>>> crappy hotel wifi though. I do see a bunch of these on the console:
>>>>
>>>> linux: pid 10892 (skype): ioctl fd=25, cmd=0x8b01 ('\M^K',1) is not
>>>> implemented
>>>>
>>>> This is on 10.1-RC4 freebsd world / kernel.
>>>>
>>>
>>> --
>>> wbr, tiger
>>>
>>> ___
>>> 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"
>>
>
>
> --
> wbr, tiger
>
> ___
> 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"
--
Kris Moore
PC-BSD Software
iXsystems
___
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: CentOS 6.6 base + userland
On 11/05/2014 13:28, Sergey V. Dyatko wrote:
> On Wed, 05 Nov 2014 01:42:35 -0500
> Kris Moore wrote:
>
>> On 11/05/2014 00:07, Johannes Meixner wrote:
>>> On Tue, Nov 04, 2014 at 04:14:05PM -0500, Kris Moore wrote:
>>>> Does running skype require the lemul branch still, or what minimum
>>>> version of FreeBSD?
>>> It's a variant of Skype 4.2.0.13 which disguises itself as 4.3.0.37. So,
>>> actually, neither (yet). It's been floating around on IRC, mostly.
>>>
>>>
>>>
>> I've merged in the patch here. It mostly works, it was just missing this
>> port for www/linux-c6-flashplugin11 to function:
>>
>> https://github.com/pcbsd/freebsd-ports/tree/master/graphics/linux-c6-gdk-pixbuf
>>
>> I've tested skype4. It starts up, but I can't seem to connect. Might be
> deinstall linux*pulseaudio* (-force) and try again ;-)
Yea, don't have that installed. XMJ said something about it needing some
kludge of running 4.3 first, then grabbing a modified special binary? ;)
>
>> crappy hotel wifi though. I do see a bunch of these on the console:
>>
>> linux: pid 10892 (skype): ioctl fd=25, cmd=0x8b01 ('\M^K',1) is not
>> implemented
>>
>> This is on 10.1-RC4 freebsd world / kernel.
>>
>
>
> --
> wbr, tiger
>
> ___
> 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"
--
Kris Moore
PC-BSD Software
iXsystems
___
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: CentOS 6.6 base + userland
On 11/05/2014 00:07, Johannes Meixner wrote:
> On Tue, Nov 04, 2014 at 04:14:05PM -0500, Kris Moore wrote:
>> Does running skype require the lemul branch still, or what minimum
>> version of FreeBSD?
> It's a variant of Skype 4.2.0.13 which disguises itself as 4.3.0.37. So,
> actually, neither (yet). It's been floating around on IRC, mostly.
>
>
>
I've merged in the patch here. It mostly works, it was just missing this
port for www/linux-c6-flashplugin11 to function:
https://github.com/pcbsd/freebsd-ports/tree/master/graphics/linux-c6-gdk-pixbuf
I've tested skype4. It starts up, but I can't seem to connect. Might be
crappy hotel wifi though. I do see a bunch of these on the console:
linux: pid 10892 (skype): ioctl fd=25, cmd=0x8b01 ('\M^K',1) is not
implemented
This is on 10.1-RC4 freebsd world / kernel.
--
Kris Moore
PC-BSD Software
iXsystems
signature.asc
Description: OpenPGP digital signature
Re: CFT: CentOS 6.6 base + userland
On 11/04/2014 15:41, Johannes Meixner wrote: > Hello, > > I've spent the last few hours porting CentOS 6.6 to FreeBSD. > > Given RHEL6 (and derived CentOS 6.x) policy of no-surprises, it was pretty > easy > to bump those versions that actually did change. > > I've tested it with poudriere locally, verified that Skype still works ;-), > and would be happy if you could all test away. > > Please check if your favorite games, things like crashplan, matlab, and other > Linux software still works, and notify me if it doesn't for any reason. > > You can find a patch to ports revision 372146 here: > > http://xmj.me/freebsd/centos-6.6.diff > > Best regards, > > -xmj > > Does running skype require the lemul branch still, or what minimum version of FreeBSD? -- Kris Moore PC-BSD Software iXsystems signature.asc Description: OpenPGP digital signature
Re: pkg: Cannot get a read lock on a database, it is locked by another process
On 07/27/2014 10:51, Stefan Esser wrote: > The locking of the pkg database leads to soft failures, but I'm afraid, > if these soft failures happen to coincide with certain administrative > tasks, they can lead to unexpected results. > > One example is that portmaster fails to detect PKGNG (and then assumes > to be working in a pre-PKGNG environment), if some pkg subcommand locks > the database. To repeat: > > # pkg version -Bs & > # pkg info > > As long as pkg version runs, pkg info fails to get the read lock (at > least in the large majority of my tests). You can also prevent any pkg > command from running, if you STOP (kill -STOP / ^Z) pkg version. Any > other pkg command will fail, until "pkg version" has been "unstopped" > and run to completion. This might even be a local DoS, if any command > that read-locks the package DB for extended time can be executed by > an unprivileged user. > > Similar error messages are reported by pkg_libcheck, which issues > lots of pkg commands in parallel. (I have observed some 5 lock > failures per 1000 installed packages on my system). > > > I did not try to test all combinations of simultanous pkg commands > and did not verify, whether e.g. "pkg upgrade" might be stopped > half way through because of an error accessing the pkg database, > but I have seen SQLITE error messages that indicated failed write > operations (INSERT/UPDATE). > > Either the timeouts are too low, or the duration during which the > database is locked by a single operation is too large (or there is > no fairness and some processes never get access to the database?). > > > I think this should be fixed, since pkg commands that lock the > database can be run from CRON or by other means in the background > and the operator who issues pkg commands in the foreground (or runs > portmaster) receives spurious error messages (which might still be > better than the batch jobs doing silly things, after they failed to > obtain information from the pkg database ...) > > Regards, STefan > ___ > 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" +1 to this whole thing. I would prefer that pkg commands simply wait for the DB to become unlocked again, instead of just failing outright. We have many scripts which monitor the system, check for updates, display our GUI store-front, and its really annoying to have random bits of it fail simply because of bad timing with another pkg process. -- Kris Moore PC-BSD Software iXsystems ___ 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: Question about WITHOUT_X11 / Poudriere
On 07/15/2014 18:04, Michelle Sullivan wrote: > Bryan Drewery wrote: >> On 7/15/2014 3:29 PM, Kris Moore wrote: >> >>> Porters, >>> >>> We are trying to get a build of the entire ports tree done, using the >>> WITHOUT_X11=yes in poudriere make.conf. This keeps bailing with these >>> errors: >>> >>> >> Creating the reference jail... done >>> >> Mounting system devices for trueos-100-RELEASE-t10e >>> >> Mounting ports/packages/distfiles >>> >> Mounting packages from: >>> /usr/local/poudriere/data/packages/trueos-100-RELEASE-t10e >>> >> Logs: >>> /usr/local/poudriere/data/logs/bulk/trueos-100-RELEASE-t10e/2014-07-15_14h49m12s >>> >> Appending to make.conf: >>> /usr/local/etc/poudriere.d/trueos-100-RELEASE-make.conf >>> /etc/resolv.conf -> >>> /usr/local/poudriere/data/build/trueos-100-RELEASE-t10e/ref/etc/resolv.conf >>> >> Starting jail trueos-100-RELEASE-t10e >>> >> Loading MOVED >>> >> Calculating ports order and dependencies >>> >> Error: Duplicated origin for ImageMagick-nox11-6.8.9.4_1,1: >>> graphics/ImageMagick-nox11 AND graphics/ImageMagick. Rerun with -vv to >>> see which ports are depending on these. >>> >> Error: Duplicated origin for ImageMagick-nox11-6.8.9.4_1,1: >>> graphics/ImageMagick-nox11 AND graphics/ImageMagick. Rerun with -vv to >>> see which ports are depending on these. >>> >> Cleaning up >>> >> Umounting file systems >>> >>> Is WITHOUT_X11 supposed to work universally or is this a bug in some of >>> our ports? >>> >>> I can track down and fix the broken ports, but I wanted to see if this >>> was something we even expect to work for bulk port builds. >>> > I'm not building all ports, but I am building ImageMagick with nox11... > > This is what I have in my 10.0 make.conf for poudriere: > > OPTIONS_UNSET=X11 NLS > > > Using the old WITHOUT_X11=yes builds -nox11 versions of the package ... > using the UNSET=X11 builds the package without X11 support (same name > rather than a -nox11 variant) > > Michelle > That may be the solution then. I assumed (wrongly) that the WITHOUT_ would trigger the same behavior as UNSET. I'll try a build with that now. (And yes, I'm using -a for poudriere) Here's my make.conf if you want to see though: https://raw.githubusercontent.com/pcbsd/pcbsd/master/build-files/conf/trueos/port-make.conf -- Kris Moore PC-BSD Software iXsystems ___ 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"
Question about WITHOUT_X11 / Poudriere
Porters, We are trying to get a build of the entire ports tree done, using the WITHOUT_X11=yes in poudriere make.conf. This keeps bailing with these errors: >> Creating the reference jail... done >> Mounting system devices for trueos-100-RELEASE-t10e >> Mounting ports/packages/distfiles >> Mounting packages from: /usr/local/poudriere/data/packages/trueos-100-RELEASE-t10e >> Logs: /usr/local/poudriere/data/logs/bulk/trueos-100-RELEASE-t10e/2014-07-15_14h49m12s >> Appending to make.conf: /usr/local/etc/poudriere.d/trueos-100-RELEASE-make.conf /etc/resolv.conf -> /usr/local/poudriere/data/build/trueos-100-RELEASE-t10e/ref/etc/resolv.conf >> Starting jail trueos-100-RELEASE-t10e >> Loading MOVED >> Calculating ports order and dependencies >> Error: Duplicated origin for ImageMagick-nox11-6.8.9.4_1,1: graphics/ImageMagick-nox11 AND graphics/ImageMagick. Rerun with -vv to see which ports are depending on these. >> Error: Duplicated origin for ImageMagick-nox11-6.8.9.4_1,1: graphics/ImageMagick-nox11 AND graphics/ImageMagick. Rerun with -vv to see which ports are depending on these. >> Cleaning up >> Umounting file systems Is WITHOUT_X11 supposed to work universally or is this a bug in some of our ports? I can track down and fix the broken ports, but I wanted to see if this was something we even expect to work for bulk port builds. -- Kris Moore PC-BSD Software iXsystems ___ 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: Integrating Custom Ports
On 12/10/2013 09:37, Rick Miller wrote: > Hi all, > > I have a need to create a custom Ports tree for my organization containing > custom Ports that currently do not exist as well as existing Ports modified > with our organization's customizations. I intend to create a new physical > category according to the instructions in the Committer's Handbook ( > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#idp65956656) > where our organization's Ports will be included. > > This is my first foray into Ports beyond just installing what is available. > So, just looking for some feedback from others doing similar. Is there > someone that can provide a few pointers in putting together and managing > such a system? > Rick, So the way we've been doing it is with git. I started by forking the ports tree from here: https://github.com/freebsd/freebsd-ports/ After cloning the fork to disk, I added a new "remote" for the original ports tree: % git remote add freebsd https://github.com/freebsd/freebsd-ports.git I then added any custom ports / patches to our fork. When I want to import changes from upstream I just go to my fork and do a new pull: % git pull freebsd master Merge any conflicts and commit. -- Kris Moore PC-BSD Software iXsystems ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Proposal for Authors / Vendors in ports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/14/2013 03:39, Baptiste Daroussin wrote: > On Thu, Nov 14, 2013 at 08:30:08AM +0100, Erwin Lansing wrote: >> On Wed, Nov 13, 2013 at 04:47:20PM -0500, Eitan Adler wrote: >>> On Wed, Nov 13, 2013 at 3:27 PM, Melvyn Sopacua wrote: >>>> On Wed, 13 Nov 2013, Kris Moore wrote: >>>> >>>>> >>>>> Wanted to run this by the ports community, see your thoughts. We build >>>>> our PBIs from the ports system, and are able to parse most of the >>>>> information out for display graphically, like descriptions, maintainers, >>>>> website, License, etc. However we currently don't have a way to pull the >>>>> actual name of the upstream vendor / author. I.E. for Firefox the vendor >>>>> would be "Mozilla". >>>> >>>> >>>> WWW: [Mozilla](http://www.mozilla.org/) >>>> >>>> So, markdown format in pkg-descr. Seems the least amount of work? >>> >>> This adds a lot of work to the parser. >>> >>> IMHO we should have VENDOR_WWW and possibly VENDOR_NAME in the port's >>> Makefile. It should not be hard to automate this for VENDOR_WWW since >>> we already have the WWW: lines in pkg-descr. >>> >> >> That sounds like an excellent idea. I'm just a bit worried about >> spreading the information over too many places, and would rather split >> content from logic and add these to pkg-descr as well next to the >> current WWW. I know we're not consistent already with things like >> COMMENT and LICENSE already in the Makefile, so won't ojbect too much to >> where these end up. >> >> Erwin >> > That is easy to fix: > VENDOR= MOZILLA > MOZILLA_VENDOR_NAME= mozilla > MOZILLA_VENDOR_WWW= http://www.mozilla.org/ > > and a bsd.vendor.mk the same way we have bsd.options.mk > > if MOZILLA_VENDOR_NAME and MOZILLA_VENDOR_WWW are already in bsd.vendor.mk the > port just have to specify VENDOR: MOZILLA > > Don't know if it is worth capitalizing :) > > regards, > Bapt This seems a great way to do it. I'm not picky as to how its done, just as long as in PKGNG I can use pkg query '%foo' and pull the information ;) - -- Kris Moore PC-BSD Software iXsystems -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJShQQvAAoJEH/cIgwwV3zXYmUIAJsSvj9llOtyYgC/ri6pzCtn DkWniQB4zZzjShyq6DIFXAb2DiCwFicjm368U76PbiixH2JLGlLrG7lxBuZsZAqt W4vt+RifcEUSVsCCXP/Z8qItVL0cW2wEiWujqDhcWJSdZ7iPgcNyhEERkBpe67Dl e4C8OpznljVE1lplDdWUCD8y8UUPTnpHOSPkx/t1KJxZIsIKFzkuPT1hArYZ4Cpn wokJU2z+8uB9jmYq2QlOe4sFn9P07ZxBNGI1tCuTH1q9PNhj2xPK7y9GmGchv4GP sh++Z/CxeDFKXKP/ex+wiogx0r7Mn3kqlb2A6zWSSO8tBHszVvAumJMPRXh8QHY= =H8hI -END PGP SIGNATURE- ___ 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"
Proposal for Authors / Vendors in ports
Wanted to run this by the ports community, see your thoughts. We build our PBIs from the ports system, and are able to parse most of the information out for display graphically, like descriptions, maintainers, website, License, etc. However we currently don't have a way to pull the actual name of the upstream vendor / author. I.E. for Firefox the vendor would be "Mozilla". This information is useful to use, because we want to be able to show users who exactly is the author of the software, not just the maintainer, which may only be gnome@ or ports@ or whatever. Does anybody have any thoughts on if this could be something we support in the tree? While I'm on the topic, how about a broader "type" for ports as well? Something like "gui/cli/library/data/doc/meta/foo" would be helpful to further categorize applications. -- Kris Moore PC-BSD Software iXsystems ___ 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"
Broken linux-seamonkey / linux-thunderbird builds
Just a FYI, the recent update to those ports are causing it to fail in poudriere. >> Calculating ports order and dependencies >> Error: Duplicated origin for linux-seamonkey-2.21: www/linux-seamonkey AND mail/linux-thunderbird/../../www/linux-seamonkey. Rerun with -vv to see which ports are depending on these. >> Error: Duplicated origin for linux-seamonkey-2.21: www/linux-firefox/../../www/linux-seamonkey AND mail/linux-thunderbird/../../www/linux-seamonkey. Rerun with -vv to see which ports are depending on these. Killed -- Kris Moore PC-BSD Software iXsystems ___ 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: pkgng default schedule... registering a few reasons for rethinking the final implementation...
On 08/23/2012 16:31, olli hauer wrote: > On 2012-08-23 21:50, Kris Moore wrote: >> On 08/23/2012 13:10, Jeremy Messenger wrote: >>> On Thu, Aug 23, 2012 at 11:49 AM, Kris Moore wrote: >>>> On 08/23/2012 12:26, Jeffrey Bouquet wrote: >>>>> I am following with dread the planned implementation of the deprecation >>>>> of /var/db/pkg as a package registry... I use each /var/db/pkg directory >>>>> as a database into the port installation/status, using >>>>> sed/grep/portmaster/portmanager/.sh scripts/find/pipes etc... to fix >>>>> stuff. For instance, an upgrade py26 > py27. >>>>> cd /var/db/pkg >>>>> ls -lac | grep py26 >>>>> ls -lac | grep python >>>>> as the more simple example. >>>>> >>>>> With due respect to its developers and the persons who agree that >>>>> the package tools could be upgraded, the mandatory >>>>> usage of a front-end database to a file directory one >>>>> is here viewd as mutt-only-mbox, registry-and-bsod rather >>>>> than /etc/local/rc files, deprecation of >>>>> sed/grep/find/locate/.sh/portmaster/portmanager as tools to fixup/upgrade >>>>> the ports that are registered; >>>>> ... >>>>> I see concurrently too few tests on lower-end p2, p3 as to whether >>>>> pkg can run with lesser memory machines (routers...) (pfsense) >>>>> ... >>>>> I suspect stalling of successful frontends to bsd (pc-bsd, ghostbsd, >>>>> pfsense..) due to less-reliability, more-possibility of bugs.. >>>>> >>>> This is of some concern to me as well. A number of our utilities / >>>> scripts rely on checking /var/db/pkg as a means to test if a particular >>>> package is installed. This is often much faster than running the pkg_* >>>> commands, especially when we may be checking thousands of packages in a >>>> single run. It will be some work to adjust our utilities to using the >>>> various "pkg" commands now, but it can be done. What worries me is >>>> performance. If this is significantly slower, it may cause some issues >>>> on our end. >>> Guys, please test it before you say anything. Otherwise it's going to >>> be moved forward without you. >>> >>> >> Well, it was about time I got to doing a benchmark of this anyway :) >> >> I did quick benchmark of how one of our utilities parses through a list >> of 1k packages on a newer i5 system: >> >> First test, using /var/db/pkg/ check we have been doing: >> >> 0.178s 0:00.31 54.8% >> 0.123s 0:00.26 61.5% >> 0.099s 0:00.15 60.0% >> >> Second test, using "pkg info ": >> >> 5.347s 0:11.41 91.7% >> 5.444s 0:11.52 91.3% >> 5.878s 0:11.32 91.4% >> >> The pkg info command is quite a bit slower in this case, but 5 seconds >> isn't horrible. >> >> Now I ran the same benchmark on a slower 1.66gz Atom system, checking >> about 1200~ packages: >> >> First test, using /var/db/pkg/ check we have been doing: >> >> 0.604s 0:00.76 86.8% >> 0.622s 0:00.77 84.4% >> 0.614s 0:00.73 90.4% >> >> Second test, using "pkg info ": >> >> 28.507s 0:54.80 99.1% >> 28.282s 0:54.60 99.4% >> 28.302s 0:54.52 99.4% >> >> Now this is what concerns me a bit. It took closer to 30 seconds, which >> is quite a while to wait, especially if a utility like ours has to run >> these checks when it starts up, to show the user whats installed / not >> installed on the system. >> >> The only way around It I've found is to do a quick "pkg info" on the >> entire DB, dump that to a list, then begin to grep through that list for >> each item, but it still takes 10~ seconds on the atom. That may be what >> I end up having to do, but it still stinks to go from a half a second >> startup, to 10 seconds each time. Any other ideas on how to do this >> faster with the new pkgng? >> > Hi Kris, > > can you describe what exactly the script is doing. > > Are you aware that you can feed direct SQL to pkg ? > $> echo 'select origin,name,version,comment from packages;' | pkg shell > > At the beginning I was also a little skeptic, but even for older (slow) > machines it works well here. > One note, on small systems keep an eye on /var/cache/pkg > > -- > Regards, > olli >
Re: pkgng default schedule... registering a few reasons for rethinking the final implementation...
On 08/23/2012 13:10, Jeremy Messenger wrote: > On Thu, Aug 23, 2012 at 11:49 AM, Kris Moore wrote: >> On 08/23/2012 12:26, Jeffrey Bouquet wrote: >>> I am following with dread the planned implementation of the deprecation of >>> /var/db/pkg as a package registry... I use each /var/db/pkg directory as a >>> database into the port installation/status, using >>> sed/grep/portmaster/portmanager/.sh scripts/find/pipes etc... to fix stuff. >>> For instance, an upgrade py26 > py27. >>> cd /var/db/pkg >>> ls -lac | grep py26 >>> ls -lac | grep python >>> as the more simple example. >>> >>> With due respect to its developers and the persons who agree that >>> the package tools could be upgraded, the mandatory >>> usage of a front-end database to a file directory one >>> is here viewd as mutt-only-mbox, registry-and-bsod rather >>> than /etc/local/rc files, deprecation of >>> sed/grep/find/locate/.sh/portmaster/portmanager as tools to fixup/upgrade >>> the ports that are registered; >>> ... >>> I see concurrently too few tests on lower-end p2, p3 as to whether >>> pkg can run with lesser memory machines (routers...) (pfsense) >>> ... >>> I suspect stalling of successful frontends to bsd (pc-bsd, ghostbsd, >>> pfsense..) due to less-reliability, more-possibility of bugs.. >>> >> This is of some concern to me as well. A number of our utilities / >> scripts rely on checking /var/db/pkg as a means to test if a particular >> package is installed. This is often much faster than running the pkg_* >> commands, especially when we may be checking thousands of packages in a >> single run. It will be some work to adjust our utilities to using the >> various "pkg" commands now, but it can be done. What worries me is >> performance. If this is significantly slower, it may cause some issues >> on our end. > Guys, please test it before you say anything. Otherwise it's going to > be moved forward without you. > > Well, it was about time I got to doing a benchmark of this anyway :) I did quick benchmark of how one of our utilities parses through a list of 1k packages on a newer i5 system: First test, using /var/db/pkg/ check we have been doing: 0.178s 0:00.31 54.8% 0.123s 0:00.26 61.5% 0.099s 0:00.15 60.0% Second test, using "pkg info ": 5.347s 0:11.41 91.7% 5.444s 0:11.52 91.3% 5.878s 0:11.32 91.4% The pkg info command is quite a bit slower in this case, but 5 seconds isn't horrible. Now I ran the same benchmark on a slower 1.66gz Atom system, checking about 1200~ packages: First test, using /var/db/pkg/ check we have been doing: 0.604s 0:00.76 86.8% 0.622s 0:00.77 84.4% 0.614s 0:00.73 90.4% Second test, using "pkg info ": 28.507s 0:54.80 99.1% 28.282s 0:54.60 99.4% 28.302s 0:54.52 99.4% Now this is what concerns me a bit. It took closer to 30 seconds, which is quite a while to wait, especially if a utility like ours has to run these checks when it starts up, to show the user whats installed / not installed on the system. The only way around It I've found is to do a quick "pkg info" on the entire DB, dump that to a list, then begin to grep through that list for each item, but it still takes 10~ seconds on the atom. That may be what I end up having to do, but it still stinks to go from a half a second startup, to 10 seconds each time. Any other ideas on how to do this faster with the new pkgng? -- Kris Moore PC-BSD Software iXsystems ___ 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: pkgng default schedule... registering a few reasons for rethinking the final implementation...
On 08/23/2012 12:26, Jeffrey Bouquet wrote: > I am following with dread the planned implementation of the deprecation of > /var/db/pkg as a package registry... I use each /var/db/pkg directory as a > database into the port installation/status, using > sed/grep/portmaster/portmanager/.sh scripts/find/pipes etc... to fix stuff. > For instance, an upgrade py26 > py27. > cd /var/db/pkg > ls -lac | grep py26 > ls -lac | grep python > as the more simple example. > > With due respect to its developers and the persons who agree that > the package tools could be upgraded, the mandatory > usage of a front-end database to a file directory one > is here viewd as mutt-only-mbox, registry-and-bsod rather > than /etc/local/rc files, deprecation of > sed/grep/find/locate/.sh/portmaster/portmanager as tools to fixup/upgrade the > ports that are registered; > ... > I see concurrently too few tests on lower-end p2, p3 as to whether > pkg can run with lesser memory machines (routers...) (pfsense) > ... > I suspect stalling of successful frontends to bsd (pc-bsd, ghostbsd, > pfsense..) due to less-reliability, more-possibility of bugs.. > This is of some concern to me as well. A number of our utilities / scripts rely on checking /var/db/pkg as a means to test if a particular package is installed. This is often much faster than running the pkg_* commands, especially when we may be checking thousands of packages in a single run. It will be some work to adjust our utilities to using the various "pkg" commands now, but it can be done. What worries me is performance. If this is significantly slower, it may cause some issues on our end. -- Kris Moore PC-BSD Software iXsystems ___ 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: gdm-2.30.5_1
On Wed, Dec 15, 2010 at 04:42:11PM +0100, Troels Just wrote: > Greetings maintainers of GNOME on FreeBSD. > > I just set up a FreeBSD workstation and I wanted to use GDM + Xfce, > however when I tried starting GDM, it just beeped when I clicked on > my user account, and said some quick error (It was on screen for like > 1/4 of a second) that said something like "error initiating ...", > I looked at the prompt and noticed several errors about the file > /usr/local/lib/pam_gnome_keyring.so not existing. I looked around and > I found that I had to install the port security/gnome-keyring as it had > not been pulled in by the GDM dependencies. > > I just thought I would bring this to your attention, in case you hear > similar problems. > > Thanks for the work all of you do, greatly appreciated! :) > > Yours sincerely, > > Troels Just, Denmark. I've also noticed that it needs sysutils/gnome-power-manager installed when running on a laptop, otherwise GDM starts and keeps a busy indicator since it cant start the battery monitor. -- Kris Moore PC-BSD Software ___ 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: xorg-server 1.7.7
On Sun 14/11/10 3:44 PM , Anonymous wrote: > Kris Moore writes: > > On Sun, Nov 14, 2010 at 12:24:44PM -0700, Warren Block wrote: > >> On Sun, 14 Nov 2010, Andriy Gapon wrote: > >> > >> > on 14/11/2010 18:18 Warren Block said the following: > >> >> On Sat, 13 Nov 2010, Andriy Gapon wrote: > >> >> > >> >>> I agree, but I am not sure how in the ports land we do an > application testing in > >> >>> general. That is, I am sure there will be a lot of testers if > the port update > >> >>> is actually committed :-) but I am not sure how to test it in > advance (given all > >> >>> the possible hardware and software configurations). > >> >> > >> >> Why not just create a new xorg-server177 or xorg-server-devel > port as has been > >> >> done with other ports? > >> > > >> > Would it be really worth it? > >> > 1.7.7 is just couple of minor releases ahead of what we have now > and the latest > >> > _release_ is 1.9.2. > >> > So, xorg-server-devel for 1.9.2 - that would make sense for my > taste. > >> > xorg-server-devel for 1.7.7 - just an overcautiousness and, IMO, > a waste of > >> > resources. > >> > >> It would depend on how compatible the newer server is with the > existing > >> xorg ports. But sure, go with the newest one that still works. > >> > >> If these ports are too shaky for normal users, they wouldn't even > have > >> to go in the tree. Put them on a web page somewhere. But this > would > >> ast least allow a wider range of testing. > > > > Does the xorg porting team have a repo somewhere for port work, ala > area51 > > for KDE4? If not, would setting one up be of interest to people > here? That > > probably be a service we could easily provide, since we are > particularly > > attached to having a working Xorg ;) > It has one > http://wiki.freebsd.org/ModularXorg/7.5 > Not sure about previous major updates. With history scattered across > several development repos[*] it can be quite hard to track. > [*] no one uses branches in ports tree (shuns CVS?) > > Are those SVN services still in use? Looking at the http links on that page I assumed it was old and no longer usable. -- Kris Moore PC-BSD / iXsystems Message sent via Atmail Open - http://atmail.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: xorg-server 1.7.7
On Sun, Nov 14, 2010 at 12:24:44PM -0700, Warren Block wrote: > On Sun, 14 Nov 2010, Andriy Gapon wrote: > > > on 14/11/2010 18:18 Warren Block said the following: > >> On Sat, 13 Nov 2010, Andriy Gapon wrote: > >> > >>> I agree, but I am not sure how in the ports land we do an application > >>> testing in > >>> general. That is, I am sure there will be a lot of testers if the port > >>> update > >>> is actually committed :-) but I am not sure how to test it in advance > >>> (given all > >>> the possible hardware and software configurations). > >> > >> Why not just create a new xorg-server177 or xorg-server-devel port as has > >> been > >> done with other ports? > > > > Would it be really worth it? > > 1.7.7 is just couple of minor releases ahead of what we have now and the > > latest > > _release_ is 1.9.2. > > So, xorg-server-devel for 1.9.2 - that would make sense for my taste. > > xorg-server-devel for 1.7.7 - just an overcautiousness and, IMO, a waste of > > resources. > > It would depend on how compatible the newer server is with the existing > xorg ports. But sure, go with the newest one that still works. > > If these ports are too shaky for normal users, they wouldn't even have > to go in the tree. Put them on a web page somewhere. But this would > ast least allow a wider range of testing. Does the xorg porting team have a repo somewhere for port work, ala area51 for KDE4? If not, would setting one up be of interest to people here? That probably be a service we could easily provide, since we are particularly attached to having a working Xorg ;) -- Kris Moore PC-BSD Software ___ 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: [kde-freebsd] Catch up with xz import
"Max Brazhnikov" wrote: >On Wed, 19 May 2010 19:42:44 +0200, Christian Weisgerber wrote: >> (This goes to all the maintainers of ports with an archivers/xz >> dependency.) >> >> The xz utils and lzma library have been imported into base for >> 9.0-CURRENT and 8.0-STABLE. The patch below makes the dependency >> on the archivers/xz port conditional on OSVERSION. >> >> I have not bumped PORTREVISION. (People might update the ports >> right now, but base only later, so incrementing PORTREVISION doesn't >> really help, I think.) >> >> Please check and comment. I intend to commit this soon. > >Ok for KDE ports. > >Max >___ >kde-freebsd mailing list >kde-free...@kde.org >https://mail.kde.org/mailman/listinfo/kde-freebsd >See also http://freebsd.kde.org/ for latest information Looks fine for warden as well! -- Kris Moore PC-BSD / iXsystems ___ 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: qtcreator-1.2.1: Not installable
On Wed, 28 Oct 2009, Adrian Glaubitz wrote: Hi Alexey, On Wed, Oct 28, 2009 at 2:25 PM, Alexey Shuvaev wrote: The base system (more or less what consists a RELEASE) and ports are mostly independent of each other. Normal FreeBSD user will have some RELEASE (say 7.2R) and up-to-date version of ports. There is no separate STABLE or CURRENT versions of ports, there is only one. (Well, there are marcuscom and area51 for testing new gnome and kde releases, respectively, but you don't need to mess with them). Ok, thanks alot for shedding some light here. I am not really into FreeBSD but long term Linux user, so consider me being a noob here ;-). FreeBSD 7 will be ok too. You can add some phrase like "Before the software can be built, the following ports/packages have to be installed: devel/qtcreator audio/taglib devel/glib20 audio/sox audio/libmad security/libmcrypt. Note that ports tree newer than 7 May 2009 is needed to build qtcreator." This is FreeBSD-user friendly. Thanks alot, I will put into our wiki like this. Is there actually a command to upgrade the ports tree, so that I can use the latest ports with FreeBSD 7.2? What would be the proper instructions to install the necessary ports, I want to try compiling our software on FreeBSD. BTW: Whom should I contact to get our project into the ports? I guess a fully fledged MiniDisc transfer software could be interesting for alot of FreeBSD users as well ;-). Thanks alot, Adrian Adrian, What other apps do you need besides qtcreator? We have that built in binary format for PC-BSD right now, which doesn't require any other compiling to run: http://www.pbidir.com/bt/pbi/269 If you are trying to get some end users to simply install BSD, and run QTCreator or some other app, PC-BSD may be an option, since it is FreeBSD under the hood. Plus if we don't have some app you need, you can always request it here: http://wiki.pcbsd.org/index.php/PBI_Requests -- Kris Moore PC-BSD Software ___ 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: [kde-freebsd] Call for Testing KDE 4.2 for FreeBSD
David Naylor wrote:
On Tuesday 03 February 2009 15:05:19 Max Brazhnikov wrote:
On Tue, 3 Feb 2009 08:31:10 +0200, David Naylor wrote:
On Monday 02 February 2009 12:01:10 David Naylor wrote:
Just finished compiling on FreeBSD 7.1 and have found the following
problems: 1. The fonts are not being anti-aliased? (Using default fonts
and "Use anti-aliasing: Enabled {with sub-pixel rendering [RGB]}).
man fonts-conf? Never had problems with fonts, can't help here :(
I suspect this has something to do with nvidia driver. If one changes the
fonts to bitstream then anti-aliasing does work (but not with the default
fonts).
Have any of you guys been able to get KDE 4.2 to work with the latest
Xorg 7.4 in ports, and the nvidia driver? I'm playing with it here, and
it always seems to crash X right after KDE finishes logging into my
desktop. When I switch to "vesa" it works just fine.
Using nvidia 180.25, Xorg 7.4, KDE 4.2, etc.
--
Kris Moore
PC-BSD Software
http://www.pcbsd.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"
Re: Compile error on: devel/ORBit2
Jeremy Messenger wrote: On Wed, 28 May 2008 10:56:46 -0500, Jeremy Messenger <[EMAIL PROTECTED]> wrote: On Wed, 28 May 2008 09:01:05 -0500, Kris Moore <[EMAIL PROTECTED]> wrote: Having some trouble here getting Orbit2 to compile on a 7-Stable system: ../../../src/idl-compiler/orbit-idl-2 -I../../../src/idl/CORBA_PIDL -I../../../s rc/idl/CORBA -I../../../src/idl/misc -I../../../src/idl/interop -I. -D_PRE_3_0_C OMPILER_ --noskels --nodefskels --nostubs --noidata --noheaders --define=Object= OObject --define=TypeCode=TTypeCode --showcpperrors --deps ../../../include/orbi t/orb-core/.deps/orbit-interface.idl.P ../../../include/orbit/orb-core/../../../ src/orb/orb-core/orbit-interface.idl orbit-idl-2 2.14.12 compiling mode, show preprocessor errors, passes: common Processing file ../../../include/orbit/orb-core/../../../src/orb/orb-core/orbit- interface.idl cc1: note: obsolete option -I- used, please use -iquote instead ../../../include/orbit/orb-core/../../../src/orb/orb-core/orbit-interface.idl:15 : Error: `TTypeCode' undeclared identifier ** (orbit-idl-2:73495): WARNING **: ../../../include/orbit/orb-core/../../../src /orb/orb-core/orbit-interface.idl compilation failed gmake[4]: *** [../../../include/orbit/orb-core/orbit-interface.h] Error 1 gmake[4]: Leaving directory `/usr/ports/devel/ORBit2/work/ORBit2-2.14.12/src/orb /orb-core' gmake[3]: *** [install] Error 2 gmake[3]: Leaving directory `/usr/ports/devel/ORBit2/work/ORBit2-2.14.12/src/orb /orb-core' gmake[2]: *** [install-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/devel/ORBit2/work/ORBit2-2.14.12/src/orb ' gmake[1]: *** [install-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/devel/ORBit2/work/ORBit2-2.14.12/src' gmake: *** [install-recursive] Error 1 *** Error code 2 Stop in /usr/ports/devel/ORBit2. Any ideas? No idea, but I have found in about it in google (third link of result, first page). http://bugs.gentoo.org/109681 Did you custom the CPUTYPE, CFLAG and -jN? BTW: Is your clock in sync? Cheers, Mezz No custom build flags, but I think this may be a clock issue. I just noticed that the date is off by a few days, and others have reported problems compiling with a out-of-sync clock as well. I'll setup ntpd and try again. Thanks! -- Kris Moore PC-BSD Software http://www.pcbsd.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Compile error on: devel/ORBit2
Having some trouble here getting Orbit2 to compile on a 7-Stable system: ../../../src/idl-compiler/orbit-idl-2 -I../../../src/idl/CORBA_PIDL -I../../../s rc/idl/CORBA -I../../../src/idl/misc -I../../../src/idl/interop -I. -D_PRE_3_0_C OMPILER_ --noskels --nodefskels --nostubs --noidata --noheaders --define=Object= OObject --define=TypeCode=TTypeCode --showcpperrors --deps ../../../include/orbi t/orb-core/.deps/orbit-interface.idl.P ../../../include/orbit/orb-core/../../../ src/orb/orb-core/orbit-interface.idl orbit-idl-2 2.14.12 compiling mode, show preprocessor errors, passes: common Processing file ../../../include/orbit/orb-core/../../../src/orb/orb-core/orbit- interface.idl cc1: note: obsolete option -I- used, please use -iquote instead ../../../include/orbit/orb-core/../../../src/orb/orb-core/orbit-interface.idl:15 : Error: `TTypeCode' undeclared identifier ** (orbit-idl-2:73495): WARNING **: ../../../include/orbit/orb-core/../../../src /orb/orb-core/orbit-interface.idl compilation failed gmake[4]: *** [../../../include/orbit/orb-core/orbit-interface.h] Error 1 gmake[4]: Leaving directory `/usr/ports/devel/ORBit2/work/ORBit2-2.14.12/src/orb /orb-core' gmake[3]: *** [install] Error 2 gmake[3]: Leaving directory `/usr/ports/devel/ORBit2/work/ORBit2-2.14.12/src/orb /orb-core' gmake[2]: *** [install-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/devel/ORBit2/work/ORBit2-2.14.12/src/orb ' gmake[1]: *** [install-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/devel/ORBit2/work/ORBit2-2.14.12/src' gmake: *** [install-recursive] Error 1 *** Error code 2 Stop in /usr/ports/devel/ORBit2. Any ideas? -- Kris Moore PC-BSD Software http://www.pcbsd.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hal: port build fails at patching with FIXED_MOUNTPOINTS
Ditto here, just had a failure on my ISO build server with 0.5.11, FIXED_MOUNTPOINTS is enabled also. -- Kris Moore PC-BSD Software http://www.pcbsd.com Andriy Gapon wrote: ===> Found saved configuration for hal-0.5.11 ===> Extracting for hal-0.5.11 => MD5 Checksum OK for hal-0.5.11.tar.gz. => SHA256 Checksum OK for hal-0.5.11.tar.gz. ===> Patching for hal-0.5.11 ===> hal-0.5.11 depends on file: /usr/local/bin/libtool - found ===> Applying extra patch /usr/ports/sysutils/hal/files/extra-patch-tools_hal-storage-mount.c 1 out of 1 hunks failed--saving rejects to tools/hal-storage-mount.c.rej *** Error code 1 I have FIXED_MOUNTPOINTS enabled. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CrossOver Games port for PC-BSD / FreeBSD
I've been working with Jeremy White over at CodeWeavers, and he has now gone ahead and created an unsupported build of CrossOver Games for PC / FreeBSD. http://crossover.codeweavers.com/pipermail/announce/2008-April/42.html Jeremy has also issued a challenge to the FreeBSD / PC-BSD communities, to show their support for these releases, in order for them to 'move up the ladder' in terms of priority. http://www.codeweavers.com/support/forums/unsupported/?t=23;msg=32282 If you can, please help us out in showing support for these releases. I'm hearing that we should see an unsupported build of CrossOver Office as well in the near future. Also, before anybody asks, yes you can run the install-crossover-pcbsdgames*.sh installer on vanilla FreeBSD. Since PC-BSD isn't a fork, the only thing you need to ensure, is that if you are on FreeBSD 6.3, you must apply the Wine patch at http://wiki.freebsd.org/Wine. Users on FreeBSD 7.0 or higher do not need this patch applied. -- Kris Moore PC-BSD Software http://www.pcbsd.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CrossOver Games port for PC-BSD / FreeBSD
I've been working with Jeremy White over at CodeWeavers, and he has now gone ahead and created an unsupported build of CrossOver Games for PC / FreeBSD. http://crossover.codeweavers.com/pipermail/announce/2008-April/42.html Jeremy has also issued a challenge to the FreeBSD / PC-BSD communities, to show their support for these releases, in order for them to 'move up the ladder' in terms of priority. http://www.codeweavers.com/support/forums/unsupported/?t=23;msg=32282 If you can, please help us out in showing support for these releases. I'm hearing that we should see an unsupported build of CrossOver Office as well in the near future. Also, before anybody asks, yes you can run the install-crossover-pcbsdgames*.sh installer on vanilla FreeBSD. Since PC-BSD isn't a fork, the only thing you need to ensure, is that if you are on FreeBSD 6.3, you must apply the Wine patch at http://wiki.freebsd.org/Wine. Users on FreeBSD 7.0 or higher do not need this patch applied. -- Kris Moore PC-BSD Software http://www.pcbsd.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Port: games/frozenbubble
Thanks! I was doing searches for "SDL Init + Bad system call and not finding anything before. I was able to fix it with the LD_PRELOAD command shown here: http://www.perl.com/pub/a/2004/12/29/3d_engine.html -- Kris Moore PC-BSD Software http://www.pcbsd.com Robert Huff wrote: Kris Moore writes: I've just tried to compile the frozenbubble game, and it installs fine, but refuses to run, giving this error: [SDL Init] Bad system call Any ideas? Something broken with the SDL lib? FB uses SDL-perl, which also could be causing the problem. Try Googling "frozenbubble" + "Bad system call", and look at the first result. Robert Huff !DSPAM:1,47865283588511734118063! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD Port: games/frozenbubble
Hey there! I've just tried to compile the frozenbubble game, and it installs fine, but refuses to run, giving this error: [SDL Init] Bad system call Not sure what the problem is, I have 3d support enabled, tried it on two different systems, same error on both. Using FreeBSD 6.3-PRE / PC-BSD 1.4.x Any ideas? Something broken with the SDL lib? FB uses SDL-perl, which also could be causing the problem. -- Kris Moore PC-BSD Software http://www.pcbsd.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Are we ready for Native Flash?
Hey, just wanted to give folks a heads up. I'm hearing that we may be seeing a native Flash binary for FreeBSD in the future, depending on how quick we can port over Tamarin: http://www.mozilla.org/projects/tamarin/ They are working on a Linux port now, if anybody is interested in getting a FBSD port done that will help us a TON in getting Adobe to release Flash9 in a native FreeBSD format. No more Linux-emulation just to surf the web! -- Kris Moore PC-BSD Software http://www.pcbsd.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
