Re: FreeBSD Port: teamspeak3-server-3.13.2,1

[Ultima]

Hello Thomas,

This has been updated.

Best regards,
Richard Gallamore

On Thu, Feb 18, 2021 at 2:10 AM Thomas Besoke (Administrator)
my-data-cloud.de  wrote:

> Hello,
>
> there is a new version of Teamspeak available. Version 3.13.3.
>
> Thanks in advance for the update.
>
> With kind regards
> Thomas Besoke
>
___
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"

website scraper to detect changes

[Ultima]

Hey there,

I'm looking for a website scraper that detects changes and then notifies
you of said changes. Is there a port that does this? or is there an
application someone would recommend?

Best regards,
Richard Gallamore
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: teamspeak3-server-3.12.1_1,1

[Ultima]

Hello Thomas,

It has been updated in r557862.

Best regards,
Richard Gallamore

On Fri, Dec 11, 2020 at 3:02 AM Thomas Besoke <
thomas.bes...@my-data-cloud.de> wrote:

> Hello,
>
> there is a new version of Teamspeak available. Version 3.13.2.
>
> I would be happy to receive an update.
>
> With kind regards
> Thomas Besoke
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: teamspeak3-server-3.11.0,1

[Ultima]

It has just been updated.

Best regards,
Richard Gallamore

On Tue, Mar 31, 2020 at 3:00 AM Thomas Besoke <
thomas.bes...@my-data-cloud.de> wrote:

> Hello dear maintainer,
>
> there is a new TeamSpeak Server version 3.12.0 available for FreeBSD (
> teamspeak.com)
>
> Thanks in advance for adding it to the ports.
>
> Sincerely yours
>
> Thomas Besoke
>
___
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: Changes to USE_GNOME to USES=gnome

[Ultima]

Why was the change made to add additional requirements for
using USE_GNOME? I'm not seeing what value this provides.
Is this to make the use of USES followed by USE_* more
standardized?

Best regards,
Richard Gallamore

On Thu, Mar 28, 2019 at 4:26 PM Mathieu Arnold  wrote:

> On Thu, Mar 28, 2019 at 03:44:45PM -0700, Ultima wrote:
> > Hello ports,
> >
> > USE_GNOME has been deprecated in favor of USES=gnome.
> > My question is that when removing USE_GNOME, USES=gnome
> > takes no arguments, so how do you select which components to
> > use when using USES=gnome, is USE_GNOME still used for this
> > part?
>
> What is deprecated is using USE_GNOME without USES=gnome.  Of course you
> still need USE_GNOME to bring in the components that are required.
>
> --
> Mathieu Arnold
>
___
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"

Changes to USE_GNOME to USES=gnome

[Ultima]

Hello ports,

USE_GNOME has been deprecated in favor of USES=gnome.
My question is that when removing USE_GNOME, USES=gnome
takes no arguments, so how do you select which components to
use when using USES=gnome, is USE_GNOME still used for this
part?

Best regards,
Richard Gallamore
___
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"

poudriere: make: don't know how to make check-sanity. Stop

[Ultima]

Hello FreeBSD porters,

Keep running into an issue where poudriere will return "make: don't know
how to make check-sanity. Stop" when modifying a Makefile. This is very
troublesome when attempting to test patches. Does anyone have an idea why
this would occur?

[1] is an example of testing a patch for bug #231397 and [2] is without the
patch, working as expected.

[1]
https://poudriere.ultimasbox.com/data/104i386-test/2018-09-17_13h00m20s/logs/errors/gpxsee-5.18.log
[2]
https://poudriere.ultimasbox.com/data/104i386-test/2018-09-17_13h02m29s/logs/gpxsee-5.16_2.log

Thanks and best regards,
Richard Gallamore
___
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: unable to set maintainer-approval?

[Ultima]

Fairly certain this is because the maintainer approval must be requested
before it can be approved.

Hope this helps,
Richard Gallamore

On Sun, Mar 25, 2018 at 9:54 AM, Martin Waschbüsch 
wrote:

> Hi,
>
> can anyone tell me why I am unable to set the maintainer approval flag for
> the proposed patch in PR
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225377
> ?
>
> Thanks,
>
> Martin
> ___
> 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"
>
___
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: www/rubygem-passenger creating slave ports

[Ultima]

This is an example of a perfect use case for flavors. Instead of
a slave port, creating an nginx flavor and apache flavor would
be a better approach.

Best regards,
Richard Gallamore

On Fri, Jan 12, 2018 at 7:23 AM, Dan Langille  wrote:

> > On Jan 12, 2018, at 10:18 AM, Dan Langille  wrote:
> >
> > Sergey,
> >
> > We have a need to use rubygem-passenger with both Nginx and with Apache
> (on different servers).
> >
> > I propose to create two new slave ports:
> >
> > * www/rubygem-passenger-nginx
> > * www/rubygem-passenger-passenger
>
> That should be:
>
> > * www/rubygem-passenger-apache
> > * www/rubygem-passenger-nginx
>
> Sorry.
>
> ___
> 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"
>
___
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: Vote: making wayland=on default

[Ultima]

I support adding wayland support on by default as well. It
still is WIP in several areas one I have not seen mentioned
yet includes nvidia graphics cards. Needing to rebuild
several ports just to test does seem a bit too much though.

Best regards,
Richard Gallamore

On Wed, Dec 20, 2017 at 11:14 AM, Johannes Lundberg 
wrote:

> Hi Yuri
>
> To be clear, we're not transitioning to anything, we're simply adding
> more options. Compare it to adding a new window manager for X, it
> doesn't mean you have to stop using the existing ones...
>
>
> On Wed, Dec 20, 2017 at 5:39 PM, Yuri  wrote:
> > On 12/20/17 01:20, Johannes Lundberg wrote:
> >>
> >> For any Desktop user (as well as embedded devices
> >> like IVI-systems and whatnot), Wayland is the future. There's no
> >> escaping that.
> >
> >
> > Over the history of its development, Wayland could never clearly answer
> the
> > question "What are the benefits of Wayland for the end user?".
> > Additionally, they always advocated the removal of features like
> networked
> > connections, window manager features.
> >
> > It appears that this is the case of fixing of something (xorg) that
> > wasn't/isn't broken in the first place. And if it is considered broken,
> then
> > how, in which way?
> >
> > But you are right, it is a reality that Wayand devs had enough
> horsepower to
> > eventually, after many years, make it and now impose it on everybody, and
> > force it to be a future reality.
> >
> > There are a lot of things that need to be verified that they work:
> x11vnc,
> > the ability to connect to a display remotely, every window manager should
> > work with it, ex. xfce4, dwm.
> >
> > People should be asking the question "What's the benefit of the
> transition
> > to X?". The answer should include the functional benefits to users, not
> just
> > "We need to switch to something called X." What new features or
> improvements
> > will users actually see?
> >
> >
> > Just my 2c.
> > Yuri
> >
> ___
> 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"
>
___
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: Flavors *COMPLETELY* break the port system (synth and poudriere are useless)

[Ultima]

I wonder if making a simple man page for general users would be wise and
referencing the fully featured man page in it for more experienced users?
It seems that many users want a simple route and the current man page is
simply too intimidating for them to even consider attempting to use. A
small how to at the bottom like how Bryan suggested would be helpful as
well. (Maybe leave out the amount of characters used bit =)

Poudriere is a powerful beast and I personally love it because of this. I
felt very overwhelmed when I first started using it but not everyone is
willing to take the time to get up to speed.

Best regards,
Richard Gallamore

On Dec 5, 2017 3:30 PM, "Mark Linimon"  wrote:

> On Tue, Dec 05, 2017 at 05:25:13PM -0500, Baho Utot wrote:
> > Thank you for taking a perfectly good system and breaking it as well as
> > making it unusable, unstable.
>
> You made your point 10 posts ago.
>
> You are repeating yourself.
>
> Why???
>
> mcl
> ___
> 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"
>
___
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: Can a port directory name have capital letters when the project name has them: audio/abGate-lv2 ?

[Ultima]

I prefer lowercase as well. I don't think there is anything wrong with
audio/abgate-lv2 with PORTNAME= abGate-lv2

On Fri, Nov 10, 2017 at 11:41 PM, Kurt Jaeger  wrote:

> Hi!
>
> > There are two competing directory name suggestions for the project with
> > the name abGate:
> >
> > audio/abGate-lv2
> >
> > audio/abgate-lv2
> >
> >
> > Should I choose the former one or the latter one?
>
> I prefer lowercase 8-}
>
> --
> p...@opsec.eu+49 171 3101372 3 years to
> go !
> ___
> 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"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: RetroArch-1.3.6_7

[Ultima]

Err, sorry still waking up... s/ffmpeg/FreeBSD developers push changes
without testing/

On Wed, Aug 23, 2017 at 7:23 AM, Ultima <ultima1...@gmail.com> wrote:

> Are you positive ffmpeg is the issue? I just did a clean build on 110amd64
> and 12 current and ffmpeg built just fine. Also build fairly recent (less
> than a week) on the other releases/tier 1 arch.
>
> On Wed, Aug 23, 2017 at 5:03 AM, David Demelier <demelier.da...@gmail.com>
> wrote:
>
>> 2017-07-11 10:02 GMT+02:00 bluesky <blue...@airmail.cc>:
>> > Hello. The Retroarch port seems a bit out of date. Retroarch is on
>> version
>> > 1.6.0 now.
>>
>> Hi,
>>
>> I'm sorry I'm unable to update it at the moment because ffmpeg does
>> not compile since many FreeBSD developers push changes without
>> testing:
>>
>> https://lists.freebsd.org/pipermail/freebsd-ports/2017-July/109566.html
>>
>> I'll postpone that update once it has been fixed.
>>
>> --
>> Demelier David
>> ___
>> 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"
>>
>
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: RetroArch-1.3.6_7

[Ultima]

Are you positive ffmpeg is the issue? I just did a clean build on 110amd64
and 12 current and ffmpeg built just fine. Also build fairly recent (less
than a week) on the other releases/tier 1 arch.

On Wed, Aug 23, 2017 at 5:03 AM, David Demelier 
wrote:

> 2017-07-11 10:02 GMT+02:00 bluesky :
> > Hello. The Retroarch port seems a bit out of date. Retroarch is on
> version
> > 1.6.0 now.
>
> Hi,
>
> I'm sorry I'm unable to update it at the moment because ffmpeg does
> not compile since many FreeBSD developers push changes without
> testing:
>
> https://lists.freebsd.org/pipermail/freebsd-ports/2017-July/109566.html
>
> I'll postpone that update once it has been fixed.
>
> --
> Demelier David
> ___
> 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"
>
___
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: Repository statistics

[Ultima]

Thanks for sharing, this is motivational. =]

On Tue, Aug 1, 2017 at 8:39 AM, Miroslav Lachman <000.f...@quip.cz> wrote:

> There is some interesting project - repository statistics - comparison
> with many different OS package repositories like Ubuntu, Fedora, Debian etc.
>
> https://repology.org/maintainers/
>
> 1st - FreeBSD
> 2nd - DPorts
> 3rd - Ubuntu 17.10
>
> Miroslav Lachman
>
> PS: I am not related to this project
> ___
> 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"
>
___
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: Keeping -CURRENT up to date with Poudriere

[Ultima]

I haven't tried attempted setting up the snapshot route, but that
seems like it would be better choice. I'm sure it is possible.

On Sun, Jun 18, 2017 at 9:49 AM, Ben Lavery-Griffiths <
ben.lav...@hashbang0.com> wrote:

> Hi all,
>
> I’ve got a 12.0-CURRENT Poudriere jail for ports testing.  Am I right in
> thinking that when Poudriere updates a jail it uses freebsd-update?  In
> which case, -STABLE and -CURRENT jails can’t be updated - correct?
>
> In this case, if I want to get the latest -STABLE or -CURRENT snapshot,
> will I need to recreate my jail?  Or can Poudriere do it a different way?
>
> Currently when I try to update I get this:
>
> > [00:00:00] >> Upgrading using ftp
> > /etc/resolv.conf -> /poudriere/jails/12Ci386/etc/resolv.conf
> > mount: /poudriere/jails/12Ci386/compat: No such file or directory
> > Bad system call (core dumped)
> > 12.0-CURRENT
> > [00:00:01] >> Recording filesystem state for clean… done
>
>
> Many thanks,
> Ben
> ___
> 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"
___
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: Keeping -CURRENT up to date with Poudriere

[Ultima]

Poudriere will update based on how it initially was created
unless it was modified in
/usr/local/etc/poudriere.d/jails/$JAIL/method. For the
-STABLE and -CURRENT branch, It *may* somehow be
obtained another way, but usually it has to be compiled
from the respected branch. So it needs to be manually
compiled in /usr/src before doing a poudriere update.

The way I handle multiple branches is adding adding
multiple in /usr/src, eg /usr/src/head, /usr/src/11-stable,
then setting the src in that directory with obj in it as well.

/usr/src/head/src and obj /usr/src/head/obj the method
will need to be set to src=/usr/src/head/src and object
export MAKEOBJDIRPREFIX=/usr/src/head/obj in the
${JAIL}-poudriere.conf.

I also make a dataset for each target branch so it can
be zfs send/received.


I hope this helps
Ultima

On Sun, Jun 18, 2017 at 9:49 AM, Ben Lavery-Griffiths <
ben.lav...@hashbang0.com> wrote:

> Hi all,
>
> I’ve got a 12.0-CURRENT Poudriere jail for ports testing.  Am I right in
> thinking that when Poudriere updates a jail it uses freebsd-update?  In
> which case, -STABLE and -CURRENT jails can’t be updated - correct?
>
> In this case, if I want to get the latest -STABLE or -CURRENT snapshot,
> will I need to recreate my jail?  Or can Poudriere do it a different way?
>
> Currently when I try to update I get this:
>
> > [00:00:00] >> Upgrading using ftp
> > /etc/resolv.conf -> /poudriere/jails/12Ci386/etc/resolv.conf
> > mount: /poudriere/jails/12Ci386/compat: No such file or directory
> > Bad system call (core dumped)
> > 12.0-CURRENT
> > [00:00:01] >> Recording filesystem state for clean… done
>
>
> Many thanks,
> Ben
> ___
> 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"
___
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: Looking for good sould with a commit bit

[Ultima]

done!

On Mon, Jun 12, 2017 at 1:31 PM, Łukasz Wąsikowski 
wrote:

> I'm looking for someone with a commit bit to look at
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208147 - new port
> [sysutils/modman]
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219825 - maintainer
> approves [security/rkhunter]
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219726 - maintainer
> update [www/mod_mpm_itk]
>
> Thank you!
>
> --
> best regards,
> Lukasz Wasikowski
> ___
> 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"
>
___
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: Ada and GNAT maintainership proposition

[Ultima]

The best way to get started with porting is reading the FreeBSD porters
handbook.

https://www.freebsd.org/doc/en/books/porters-handbook/

In order to take maintainership, a pr needs to be filled on bugzilla
requesting the port.



Porting on the most recent -RELEASE version is fine, however It is
recommended to test on current as well. I don't think its a huge issue if
you can't do this though. if it fails on current you will get fallout
messages. It is important to test on all supported releases which can be
found here.

https://www.freebsd.org/releases/

The testing are needed on tier 1 supported architectures which currently
are amd64/i386, of course more is better but not required. The tiers can be
found here.

https://www.freebsd.org/platforms/



All these tests aren't necessarily required by the port maintainer, but it
wont be committed unless they pass these tests. So it is definitely easier
and less time consuming for both committer and maintainer if tests are
completed.


Hope this helps,
Ultima

On Wed, May 10, 2017 at 7:43 AM, Natasha Kerensikova <nat...@instinctive.eu>
wrote:

> Hello,
>
> I'm an insignificant FreeBSD user and Ada developer, and over the years
> I've come to rely a lot of both technologies together. I'm very worried
> now that I discovered that Ada-related ports no longer have a maintainer.
> Having thought a lot about it in the past day, I don't have a workable
> exit strategy for either technology, and I don't want to need one.
>
> So the whole point of this e-mail is, what happens now?
>
>
> As far as I can tell, if nobody steps up to take over the
> maintainership, the ports will eventually be considered dead and be
> removed. I think I saw ports stay maintainerless for a long while before
> being dropped, but here we have a lively compiler and a moving standard,
> so it's likely things will break sooner rather than later. Once a port
> is broken, even if it's not reported as broken, its days of
> maintainerless existence are numbered.
>
> So, does anyone care?
>
> I do, but I mean, besides me?
>
> Is there anybody ready to step up and take maintainership and ensure
> these ports continue to work?
> (If there is, don't read the rest of the e-mail, it's moot.)
>
>
> I'm afraid there isn't anybody, and that's why I'm asking here whether I
> can be that somebody.
>
> It would be nice there was some way to make an official distinction
> between standard maintainership and maintainership-by-default-because-I-
> want-it-to-work-but-I-would-gladly-hand-it-to-anyone-interested.
>
> The problem is that Marino's shoes are difficult to fill. I'm basically
> applying for a position while I have no experience (I only compiled gcc
> three times in my life), no relevant skill (except reading C), and
> almost no time. The only thing preventing me from being the most
> ill-suited person for the role is that I care. Is it enough?
>
> I'm used to imposter's syndrome, but taking for example the recent thread
> https://lists.freebsd.org/pipermail/freebsd-ports/2017-April/108130.html
> that's already way beyond my league.
>
> On top of that, I'm only running recent -RELEASE, I'm not sure I can
> find a box on which to run -CURRENT, and I don't hope having some
> -STABLE or older -RELEASE available. That limits quite a bit my testing
> capabilities.
>
> I think I can handle the load of being the contact person for these
> ports and dealing with the bugtracker and things like that. So if there
> is anyone reading this with a bit of technical expertise to help but who
> doesn't want to deal with the communication part of the maintainership,
> please let me know, so I can volunteer less shakily.
>
>
> So at this point, is there anybody to talk me out of trying to maintain
> gcc-aux and some of the Ada ports left behind?
>
> What is the procedure to ask for maintainership on these?
>
> I still haven't fully sketched the exact list of package I would try to
> claim, but I use daily lang/gcc6-aux, www/aws, devel/florist-gpl, and
> devel/gprbuild; I occasionally use devel/adacurses and devel/gnatcoll;
> and I could easy integrate into my workflow lang/adacontrol and
> lang/asis. I would take some more, going out of my way to test them, but
> I'll have to think about which ones are within my reach. The gnatdroid
> and gnatcross ones are almost certainly not.
>
>
> Thanks for your patience,
> Natasha
> ___
> 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"
>
___
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: flavors and subpackages

[Ultima]

Thanks for the update and working on this bapt, it will be a nice feature
to have in the port tree.

On Sat, Apr 8, 2017 at 6:00 PM, Baptiste Daroussin  wrote:

> Hi all,
>
> I have started to merge subpackages and flavors to the ports tree.
>
> While for subpackages I'm only committing for now modifications of
> bsd.port.mk
> that needs to be made in preparation for proper subpackages
>
> For flavours, I have a working patch for a first easy step which should
> cover
> for examples all the py2/py3 mess we have now
>
> https://reviews.freebsd.org/D10327
>
> basically if a port can have multiple variation then it just have to define
> FLAVORS= foo bar
>
> Committing the infrastructure part will not break anything but actually
> using
> it in ports will break portmaster, portupgrade, synth, poudriere and others
> which should be easily fixable on each end
>
> I haven't yet written a patch for poudriere but I plan to do it as soon as
> I
> can. For others I will let their maintainers doing it
>
> In my opinion it should be used with a proper policy from portmgr.
>
> If I take the python as an example:
> we should imho provide flavors for major version of the languages, meaning
> py27
> and py35 right now, but not for all possible version of the languages.
>
> only libs should provide flavors, end user programs should not.
>
> Best regards,
> Bapt
>
___
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: unable to build java in poudriere

[Ultima]

I just finished building openjdk8 with a fresh repo and it built just fine.

poudriere bulk -p git -j 103amd64 java/openjdk8
ref:
https://poudriere.ultimasbox.com/build.html?mastername=103amd64-git=2017-01-25_14h51m15s



A google search on the error suggests that it is most likely related to
some form of memory issue.

If you follow this post from a few years ago, it could lead you to the same
conclusion. More or less it seemed to be a problem with java determining
incorrect memory values which was causing that error. Could be completely
wrong but it is worth looking into.

https://lists.freebsd.org/pipermail/freebsd-java/2013-December/010441.html

Explicit setting maximum memory starts the vm, but being that this is a
port building, I'm not really sure what to suggest. I guess you could try
add an arg on the Makefile setting max memory, but I'm not sure how much
memory it requires to build. I know building openjdk does need quite a bit.
Another solution, likely less desired is using another system to build it
or using the FreeBSD repo to download it. Sorry if this isn't helpful.
Someone else may have a better solution.

Good luck,
Ultima

On Wed, Jan 25, 2017 at 5:48 AM, Julian Elischer <jul...@freebsd.org> wrote:

> On 25/1/17 6:30 pm, Julian Elischer wrote:
>
>> On 25/1/17 10:36 am, Ultima wrote:
>>
>>> Sorry Julian but your details are kind of vague. Are you on head? I'm
>>> not sure when my last build for openjdk7 or 8 were but I have them built in
>>> my repo. Is there enough memory on the system building it? or is it
>>> limited? that is usually the culprit for the openjdk ports.
>>>
>>> I ask if you were on head because I know java was broken for sometime in
>>> January but was fixed, or at least r312388 is working.
>>>
>> Sorry, one item missing..  compile is on FreeBSD 10.3
>>
>> Poudriere is populated with the head ports tree as of yesterday, but I
>> had hte same problem a few weeks ago.
>> the list of packages includes openjdk8
>> it would probably have the same issue if openjdk8 was the ONLY port to
>> make, because jdk8 wants jdk7 to jdb7 won't build.
>> Should poudriere or ports give a warning "you need to install package X
>> before we can do this compile"?
>>
>
> I will add that bootstrap-openjdk-r351880_1.txz  is already finished and
> available.
> I'm guessing that openjdk7 should be using that, but isn't for some reason.
>
> in fact is it possible that 8 should be using that to bootstrap itself up
> as well instead of using 7?
>
> I'm not experienced with java, I just need to get it into the machine
> image at $JOB for others to use.
>
>
>
>>
>>
>>
>>> On Tue, Jan 24, 2017 at 8:56 PM, Julian Elischer <jul...@freebsd.org
>>> <mailto:jul...@freebsd.org>> wrote:
>>>
>>> from he log file:  (see below)
>>>
>>> This dies almost immediately.
>>> Do we need to prime the build with an older java? (e.g. the
>>> bootstrap pkg)?
>>> If so why does  poudriere not do this?
>>> I actually want jdk8 but iti insists on building 7 first, which
>>> fails.
>>> Since I don't care about 7 I can prime the pump by downloading a
>>> 7 pkg but should all this be automatic somehow?
>>>
>>> Log:
>>>
>>> 
>>>
>>> 
>>>
>>> # Entering langtools for target(s) all#
>>> 
>>>
>>>
>>> (cd  ./langtools/make && \
>>>   gmake
>>> JDK_TOPDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk
>>> JDK_MAKE_SHARED_DIR=/wrkdirs/usr/ports/java/openjdk7/work/op
>>> enjdk/jdk/make/common/shared
>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
>>> TARGET_CLASS_VERSION=7 MILESTONE=fcs BUILD_NUMBER=b01
>>> JDK_BUILD_NUMBER=b01 FULL_VERSION=1.7.0_111-b01
>>> PREVIOUS_JDK_VERSION=1.6. JDK_VERSION=1.7.0_111
>>> JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7
>>> JDK_MICRO_VERSION=0_111 PREVIOUS_MAJOR_VERSION=1
>>> PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=
>>> PAX_COMMAND=/usr/sbin/paxmark.sh PAX_COMMAND_ARGS="-vm"
>>> ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=1
>>> ANT_HOME="/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7"
>>> ALT_OUTPUTDIR=/wrkdirs/usr/ports/java/openjdk

Re: unable to build java in poudriere

[Ultima]

Sorry Julian but your details are kind of vague. Are you on head? I'm not
sure when my last build for openjdk7 or 8 were but I have them built in my
repo. Is there enough memory on the system building it? or is it limited?
that is usually the culprit for the openjdk ports.

I ask if you were on head because I know java was broken for sometime in
January but was fixed, or at least r312388 is working.

On Tue, Jan 24, 2017 at 8:56 PM, Julian Elischer  wrote:

> from he log file:  (see below)
>
> This dies almost immediately.
> Do we need to prime the build with an older java? (e.g. the bootstrap pkg)?
> If so why does  poudriere not do this?
> I actually want jdk8 but iti insists on building 7 first, which fails.
> Since I don't care about 7 I can prime the pump by downloading a 7 pkg but
> should all this be automatic somehow?
>
> Log:
>
> 
> 
> # Entering langtools for target(s) all #
> 
>
> (cd  ./langtools/make && \
>   gmake JDK_TOPDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk
> JDK_MAKE_SHARED_DIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk/make/common/shared
> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7
> MILESTONE=fcs BUILD_NUMBER=b01 JDK_BUILD_NUMBER=b01
> FULL_VERSION=1.7.0_111-b01 PREVIOUS_JDK_VERSION=1.6. JDK_VERSION=1.7.0_111
> JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7
> JDK_MICRO_VERSION=0_111 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
> PREVIOUS_MICRO_VERSION= PAX_COMMAND=/usr/sbin/paxmark.sh
> PAX_COMMAND_ARGS="-vm" ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=1
> ANT_HOME="/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7"
> ALT_OUTPUTDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools
> ALT_BOOTDIR=/usr/local/bootstrap-openjdk all)
> gmake[3]: Entering directory '/wrkdirs/usr/ports/java/openj
> dk7/work/openjdk/langtools/make'
> JAVA_HOME=/usr/local/bootstrap-openjdk ANT_OPTS=-Djava.io.tmpdir='/wr
> kdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-tmp'
> /wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7/bin/ant
> -diagnostics > /wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-
> amd64/langtools/build/ant-diagnostics.log ; \
>   JAVA_HOME=/usr/local/bootstrap-openjdk ANT_OPTS=-Djava.io.tmpdir='/wr
> kdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-tmp'
> /wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7/bin/ant -version
> >> /wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-
> amd64/langtools/build/ant-diagnostics.log
> Could not create the Java virtual machine.
> Could not create the Java virtual machine.
> gmake[3]: *** [Makefile:196: /wrkdirs/usr/ports/java/openjd
> k7/work/openjdk/build/bsd-amd64/langtools/build/ant-diagnostics.log]
> Error 1
> gmake[3]: Leaving directory '/wrkdirs/usr/ports/java/openj
> dk7/work/openjdk/langtools/make'
> gmake[2]: *** [make/langtools-rules.gmk:39: langtools-build] Error 2
> gmake[2]: Leaving directory '/wrkdirs/usr/ports/java/openj
> dk7/work/openjdk'
> gmake[1]: *** [Makefile:251: build_product_image] Error 2
> gmake[1]: Leaving directory '/wrkdirs/usr/ports/java/openj
> dk7/work/openjdk'
> *** Error code 1
>
>
> ___
> 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"
>
___
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: Correct order when upgrading to 11.0 Release with Poudriere

[Ultima]

This is more or less how it is if you have custom options for ports. It is
best to have a second machine for poudriere building if you're looking for
no downtime. I suppose another alternative could be running a virtual
machine, bhyve/virtualbox and building the packages moving them over to
host before the upgrade but that seems a bit tedious.

On Sun, Jan 22, 2017 at 12:01 PM, Grzegorz Junka  wrote:

> Is there a canonical way of upgrading FreeBSD to a newer major version?
>
> The handbook https://www.freebsd.org/doc/handbook/updating-upgrading-free
> bsdupdate.html says:
>
> Major versions use different Application Binary Interfaces (ABIs), which
> will break most third-party applications. After a major version upgrade,
> all installed packages and ports need to be upgraded.
>
> So, it seems that I need to have the packages ready and compiled before
> attempting an upgrade of the base. However, poudriere says:
>
> [00:00:00] >> Warning: !!! Jail is newer than host. (Jail: 1100122,
> Host: 1003000) !!!
> [00:00:00] >> Warning: This is not supported.
> [00:00:00] >> Warning: Host kernel must be same or newer than jail.
> [00:00:00] >> Warning: Expect build failures.
>
> So, it seems that I need to upgrade the base first before being able to
> build packages.
>
> If I upgrade base and it breaks poudriere's ABI, I won't be able to build
> new packages. One workaround would be to install the official poudriere
> package and then attempt to rebuild all applications.
> In either case it seems that the system would be unusable between the time
> of upgrading the base and finishing compiling all packages and reinstalling
> them, which may take a day or so. Is there any other way?
>
> Grzegorz
> ___
> 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"
>
___
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"

Advise requested when a repo split occurs

[Ultima]

 Hello,

 Some what recently a couple of the ports I maintain split into two, one
being -server, and the other being -client. The code was more or less
cloned then removed some make args/files that one would be used to enable
both.

 Currently the code is so similar it would be possible to create a slave
port and use the same patches, makefile and plist with minimal changes,
however I have no idea the direction this split may go and this maybe short
lived. So onto my topic for this post.

Would it be better to create a new port with mostly duplicate code and
remove/add the little changes required? Or as previously stated make a
slave port and use the common code.

I am struggling to decide on this and would appreciate opinions.

Thanks


Ultima
___
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: Error in a package?

[Ultima]

Yeah, this is a bit annoying and needs to get fixed. The -f option IMO
should as the option suggests, forcefully upgrade the package even on an
error like this. I haven't really looked into why this package is
constantly causing this error, but manually deleting the pkg and installing
it works. Careful tho, all the pkg's depending on it will be removed and
will need to be reinstalled as well.

On Sun, Sep 11, 2016 at 4:55 PM, Grzegorz Junka  wrote:

> Why I can not upgrade this package, even forcefully?
>
> root@ultrabook:~ # pkg upgrade -f javavmwrapper
> Updating ultrabook repository catalogue...
> ultrabook repository is up-to-date.
> All repositories are up-to-date.
> The following 1 package(s) will be affected (of 0 checked):
>
> Installed packages to be UPGRADED:
> javavmwrapper: 2.5_1 -> 2.5_2
>
> Number of packages to be upgraded: 1
>
> 16 KiB to be downloaded.
>
> Proceed with this action? [y/N]: y
> Fetching javavmwrapper-2.5_2.txz: 100%   16 KiB  16.4kB/s 00:01
> Checking integrity... done (0 conflicting)
> [1/1] Upgrading javavmwrapper from 2.5_1 to 2.5_2...
> [1/1] Extracting javavmwrapper-2.5_2: 100%
> You may need to manually remove /usr/local/etc/javavm_opts.conf if it is
> no longer needed.
> pkg: Fail to rename /usr/local/bin/.checkvms.cSKXJhAdFAsw ->
> /usr/local/bin/checkvms: No such file or directory
>
> ___
> 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"
>
___
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"

Need help debugging rc script

[Ultima]

 Hello, I'm dealing with an odd issue with an rc script working pre-11. The
change that is causing the prog to fail seems to be the new limits feature,
$name_login_class. After commenting out the limits command in rc.subr, the
script starts as expected. Adding limits directly in the rc script with the
daemon class will also start the script as expected (with limits commented
out in rc.subr). For some reason that I cannot fathom it will just not
start correctly with limits in rc.subr.

 So as the topic suggests, are they're better way to debug this? I'll also
provide the scripts used in case someone may see something I'v missed. The
jail is running on current, however this exists in 11 as well.

12.0-CURRENT FreeBSD 12.0-CURRENT #21 r304105
audio/teamspeak3-server

# cat /usr/local/etc/rc.d/teamspeak
#!/bin/sh

# $FreeBSD$
#
# PROVIDE: teamspeak
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf.local or /etc/rc.conf
# to enable this service:
#
# teamspeak_enable (bool):   Set to NO by default.
#   Set it to YES to enable teamspeak server.
#

. /etc/rc.subr

name="teamspeak"
rcvar=teamspeak_enable

db_dir=/var/db/teamspeak
log_dir=/var/log/teamspeak

pidfile=/var/db/teamspeak/teamspeak_server.pid
procname=/usr/local/libexec/ts3server
command=/usr/sbin/daemon
command_args="-fp $pidfile -u teamspeak /usr/local/libexec/ts3server
dbsqlpath=/usr/local/share/teamspeak/server/sql/
inifile=/usr/local/etc/teamspeak/ts3server.ini
licensepath=/usr/local/etc/teamspeak/ logpath=$log_dir"
teamspeak_chdir=$db_dir
required_dirs="$db_dir $log_dir"

load_rc_config $name

: ${teamspeak_enable="NO"}

LD_LIBRARY_PATH=/usr/local/lib/teamspeak/server:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

run_rc_command "$1"



This script causes an error,
2016-09-01 16:53:09.510292|ERROR   |DatabaseQuery |   |db_connect() failed
unable to open database file
2016-09-01 16:53:09.510352|CRITICAL|ServerLibPriv |   |Server()
DatabaseError out of memory


Commenting line 1075 in /etc/rc.subr, the program starts successfully

Keeping line 1075 commented, change rc script to this.

# cat /usr/local/etc/rc.d/teamspeak
#!/bin/sh

# $FreeBSD$
#
# PROVIDE: teamspeak
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf.local or /etc/rc.conf
# to enable this service:
#
# teamspeak_enable (bool):   Set to NO by default.
#   Set it to YES to enable teamspeak server.
#

. /etc/rc.subr

name="teamspeak"
rcvar=teamspeak_enable

db_dir=/var/db/teamspeak
log_dir=/var/log/teamspeak

pidfile=/var/db/teamspeak/teamspeak_server.pid
procname=/usr/local/libexec/ts3server
command=/usr/bin/limits
command_args="-C daemon /usr/sbin/daemon -fp $pidfile -u teamspeak
/usr/local/libexec/ts3server
dbsqlpath=/usr/local/share/teamspeak/server/sql/
inifile=/usr/local/etc/teamspeak/ts3server.ini
licensepath=/usr/local/etc/teamspeak/ logpath=$log_dir"
teamspeak_chdir=$db_dir
required_dirs="$db_dir $log_dir"

load_rc_config $name

: ${teamspeak_enable="NO"}

LD_LIBRARY_PATH=/usr/local/lib/teamspeak/server:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

run_rc_command "$1"


This is also start successfully.
___
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: poudriere: howto build ports with 'make -j x'?

[Ultima]

 Chromium and Libreoffice are two programs that are massive and have the
longest compile times in the ports tree along with eclipse. If the system
only has 2 cpus I would expect those to take at least 4-8 hours minimum. If
they are also building in parallel you can expect that to also increase. My
system takes 40 minutes for Chromium and 50 for Libreoffice, and thats with
jobs=40 on 2.0 cores.

Sorry if my comment was confusing, this variable's use-case is better to
limit the amount of jobs per jail on a given system. Enabling
ALLOW_MAKE_JOBS=yes will set the makejobs on all jails to maximum amount of
cpu's, in you're case 2.

The reason I made my comment, if makejobs > 64 some ports will begin to
fail to build due to too many makejobs. Also, for multiple threaded cpu's
it may increase performance setting it lower when running many jails in
parallel.

> These I do run as single steps each from a shell script

> poudriere bulk -j freebsd-head -p ports-head www/firefox
> poudriere bulk -j freebsd-head -p ports-head www/chromium

It may run faster, but only because they are not building in parallel.

On Thu, Aug 11, 2016 at 3:49 AM, Matthias Apitz <g...@unixarea.de> wrote:

> El día Saturday, August 06, 2016 a las 02:13:39PM -0400, Ultima escribió:
>
> > If you plan on running build in parallel it maybe necessary to also
> > set MAKE_JOBS_NUMBER_LIMIT= into the make.conf file as well.
>
> I have a list of some 270 ports which poudriere should work through with
> 3 builders, resulting in some 1700 ports to build:
>
> poudriere bulk -f /usr/local/etc/poudriere-list -J 3 -j freebsd-head -p
> ports-head
>
> This list does not include some ports which are verry time consuming on
> my hardware (2 CPU 3.7 GHz) like
>
> www/firefox
> www/chromium
> editors/openoffice-devel
> editors/libreoffice
> ...
>
> These I do run as single steps each from a shell script
>
> poudriere bulk -j freebsd-head -p ports-head www/firefox
> poudriere bulk -j freebsd-head -p ports-head www/chromium
> ...
>
> matthias
> --
> Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎
> +49-176-38902045
> "Ohne die Mauer hätte es Krieg gegeben" Fritz Streletz u.a.
> "Sin el Muro hubiese habido guerra."
>
___
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: poudriere: howto build ports with 'make -j x'?

[Ultima]

If you plan on running build in parallel it maybe necessary to also
set MAKE_JOBS_NUMBER_LIMIT= into the make.conf file as well.

On Sat, Aug 6, 2016 at 11:49 AM, Michael Grimm  wrote:

> Christian Schwarz  wrote:
>
> > From my poudriere.conf:
> >
> >  # By default MAKE_JOBS is disabled to allow only one process per cpu
> >  # Use the following to allow it anyway
> >  ALLOW_MAKE_JOBS=no
> >
> >  # List of packages that will always be allowed to use MAKE_JOBS
> >  # regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports
> >  # which holdup the rest of the queue to build more quickly.
> >  ALLOW_MAKE_JOBS_PACKAGES="pkg ccache py* perl5.20"
> >
> > Hope this helps!
>
> Yes, it helped. Especially me being blind to find that in the first place
> :-(
>
> Thanks to all who helped me finding these knobs.
>
> Regards,
> Michael
>
> ___
> 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"
>
___
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: x11/nvidia-driver issues compiling on 9.X

[Ultima]

 Thank you Jan Beich. That was it!. Also thanks for providing all the
detailed information. Vary helpful =]

On Sun, Jan 10, 2016 at 11:59 PM, Jan Beich <jbe...@vfemail.net> wrote:

> Ultima <ultima1...@gmail.com> writes:
>
> > nvidia-modeset-freebsd.c:563:29: error: sys/caprights.h: No such file or
> > directory
>
> Drop the line.  is implicitly included on 10+ systems.
>
> > nvidia-modeset-freebsd.c:593: warning: implicit declaration of function
> > 'cap_rights_init'
>
> See how nv-freebsd.h and nvidia_linux.c fixed this issue and also use
> slightly more correct __FreeBSD_version.
>
> // before r255219
> status = fget(curthread, fd, CAP_IOCTL, );
>
> // after  r255219
> cap_rights_t rights;
> status = fget(curthread, fd, cap_rights_init(, CAP_IOCTL), );
>
> https://svnweb.freebsd.org/changeset/base/255219
>
___
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"

x11/nvidia-driver issues compiling on 9.X

[Ultima]

 Working on updating nvidia-driver to the newest version (361.16) and stuck
with an issue building on 9.X. there is a new kernel module that calls a
function cap_rights_init, which does not exist on 9.X. It looks like it was
new code added in 10.X. The patch builds perfectly in 10.X and head. If
someone is willing to take a look at this It would be appreciated!

  The patch is on PR 201340 called nvidia-driver-test,not-ready.diff

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201340

Here is the build log

>> Building x11/nvidia-driver
build started at Sun Jan 10 19:48:21 EST 2016
port directory: /usr/ports/x11/nvidia-driver
building for: FreeBSD 93amd64-test-job-01 9.3-RELEASE-p32 FreeBSD
9.3-RELEASE-p32 amd64
maintained by: da...@freebsd.org
Makefile ident:  $FreeBSD: head/x11/nvidia-driver/Makefile 399346
2015-10-15 14:55:14Z mat $
Poudriere version: 3.1.10
Host OSVERSION: 1002502
Jail OSVERSION: 903000

---Begin Environment---
SHELL=/bin/csh
OSVERSION=903000
UNAME_v=FreeBSD 9.3-RELEASE-p32
UNAME_r=9.3-RELEASE-p32
BLOCKSIZE=K
MAIL=/var/mail/root
STATUS=1
WARNING_WAIT=0
SAVED_TERM=screen
MASTERMNT=/usr/local/poudriere/data/.m/93amd64-test/ref
NO_WARNING_PKG_INSTALL_EOL=yes
FORCE_PACKAGE=yes
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
POUDRIERE_BUILD_TYPE=bulk
PKGNAME=nvidia-driver-361.16
OLDPWD=/
PWD=/usr/local/poudriere/data/.m/93amd64-test/ref/.p/pool
MASTERNAME=93amd64-test
SCRIPTPREFIX=/usr/local/share/poudriere
USER=root
HOME=/root
POUDRIERE_VERSION=3.1.10
SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
LIBEXECPREFIX=/usr/local/libexec/poudriere
LOCALBASE=/usr/local
PACKAGE_BUILDING=yes
DEV_WARNING_WAIT=0
---End Environment---

---Begin OPTIONS List---
===> The following configuration options are available for
nvidia-driver-361.16:
 ACPI_PM=off: ACPI Power Management support
 DOCS=on: Build and/or install documentation
 LINUX=on: Linux compatibility support
 WBINVD=off: Flush CPU caches directly with WBINVD
===> Use 'make config' to modify these settings
---End OPTIONS List---

--CONFIGURE_ARGS--

--End CONFIGURE_ARGS--

--CONFIGURE_ENV--
XDG_DATA_HOME=/wrkdirs/usr/ports/x11/nvidia-driver/work
 XDG_CONFIG_HOME=/wrkdirs/usr/ports/x11/nvidia-driver/work
 HOME=/wrkdirs/usr/ports/x11/nvidia-driver/work TMPDIR="/tmp" SHELL=/bin/sh
CONFIG_SHELL=/bin/sh
--End CONFIGURE_ENV--

--MAKE_ENV--
NVIDIA_ROOT=/wrkdirs/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-361.16
X11BASE=/usr/local KMODDIR="/boot/modules" SYSDIR="/usr/src/sys"
NO_XREF=yes XDG_DATA_HOME=/wrkdirs/usr/ports/x11/nvidia-driver/work
 XDG_CONFIG_HOME=/wrkdirs/usr/ports/x11/nvidia-driver/work
 HOME=/wrkdirs/usr/ports/x11/nvidia-driver/work TMPDIR="/tmp" NO_PIE=yes
NO_DEBUG_FILES=yes SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local
 LOCALBASE=/usr/local  LIBDIR="/usr/lib"  CC="cc" CFLAGS="-O2 -pipe
-fno-strict-aliasing"  CPP="cpp" CPPFLAGS=""  LDFLAGS="" LIBS=""  CXX="c++"
CXXFLAGS="-O2 -pipe -fno-strict-aliasing"  MANPREFIX="/usr/local"
BSD_INSTALL_PROGRAM="install   -m 555"  BSD_INSTALL_LIB="install   -m 444"
 BSD_INSTALL_SCRIPT="install  -m 555"  BSD_INSTALL_DATA="install  -m 0644"
 BSD_INSTALL_MAN="install  -m 444"
--End MAKE_ENV--

--PLIST_SUB--
LINUXBASE=/compat/linux
SHLIB_VERSION=361.16
MODULESDIR=lib/xorg/modules
LINUX=""
KMODDIR="boot/modules"
OSREL=9.3
PREFIX=%D
LOCALBASE=/usr/local
RESETPREFIX=/usr/local
PORTDOCS=""
PORTEXAMPLES=""
LIB32DIR=lib
DOCSDIR="share/doc/NVIDIA_GLX-1.0"
EXAMPLESDIR="share/examples/nvidia-driver"
DATADIR="share/nvidia-driver"
WWWDIR="www/nvidia-driver"
ETCDIR="etc/nvidia-driver"
--End PLIST_SUB--

--SUB_LIST--
PREFIX=/usr/local
LOCALBASE=/usr/local
DATADIR=/usr/local/share/nvidia-driver
DOCSDIR=/usr/local/share/doc/NVIDIA_GLX-1.0
EXAMPLESDIR=/usr/local/share/examples/nvidia-driver
WWWDIR=/usr/local/www/nvidia-driver
ETCDIR=/usr/local/etc/nvidia-driver
--End SUB_LIST--

---Begin make.conf---
USE_PACKAGE_DEPENDS=yes
BATCH=yes
WRKDIRPREFIX=/wrkdirs
PORTSDIR=/usr/ports
PACKAGES=/packages
DISTDIR=/distfiles
 /usr/local/etc/poudriere.d/102amd64-make.conf 
DISABLE_LICENSES=yes
#DEFAULT_MYSQL_VER=101m
DISABLE_MAKE_JOBS=poudriere
---End make.conf---
===
===
===
===>   nvidia-driver-361.16 depends on file: /usr/local/sbin/pkg - not found
===>   Installing existing package /packages/All/pkg-1.6.2.txz
[93amd64-test-job-01] Installing pkg-1.6.2...
[93amd64-test-job-01] Extracting pkg-1.6.2: .. done
Message from pkg-1.6.2:
If you are upgrading from the old package format, first run:

  # pkg2ng
===>   nvidia-driver-361.16 depends on file: /usr/local/sbin/pkg - found
===>   Returning to build of nvidia-driver-361.16
===
===