Re: math/R maintenance

[Fernando Herrero Carrón]

Hi,

I submitted a new patch for math/R 3.3.0 (
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207425). Could someone
please take look at it?

Thanks a lot!

2016-05-22 22:31 GMT+02:00 Fernando Herrero Carrón :

>
> El 22 may. 2016 11:59 a. m., "Kurt Jaeger"  escribió:
> >
> > Hi!
> >
> > > > Ignore that, it was a simple ${PORTSDIR} removal. I'm testing right
> now.
> >
> > > Thanks a lot, Kurt. I am rechecking in any case to see if it still
> works.
> >
> > Turns out, there are quite a few other sleeper PRs for R,
> > for example the one to update to 3.3.0.
> >
> > Can you provide a patch that's working with the state after
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209315
> >
> > Thanks!
> >
>
> I see the port has been updated today, I'll try to get a new patch this
> week.
>
> Thanks!
>
___
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: Facter 3.X questions

[Kurt Jaeger]

Hi!

> Since Facter's move to a C/C++ codebase, a lot of facts have gone missing
> on FreeBSD machines. As a dabbler in FreeBSD I want to help fix this! :)

Very nice! I'm no puppet or facter user, but I can probably help
with the ports part.

Can you explain the state of factor for us ? We have 3.1.3 in
the ports, and upstream is @3.1.8. Have you tried to provide
a patch to the ports to get the port up2date ?

Then: What are those 'facts' ? Are they modules for facter to
collect specific info on a system etc ? Are they part of facter itself
or do you want to provide seperate ports for this ?

What kind of facts are generally available ?

The WWW in pkg-descr is https://puppetlabs.com/facter, which
no longer works -- what would be the correct link ?

How/when should facter replace rubygem-facter in the ports tree ?
Right now puppet depends on rubygem-facter, which is only at 2.4.4 ?
Upstream is at 2.4.6.

> more difficult missing areas such as determining swap space, networks and
> such, that would be greatly appreciated. Getting kenv and sysctl settings
> has been fairly simple, these ones have been a little bit more complex...

For this, we probably need more understanding of facter 8-}
Any links that you can share that bring us up to speed ?

> 3) How difficult is it to become a maintainer?

Submit PRs for sysutils/facter and sysutils/rubygem-facter.
robak@ is the maintainer for rubygem-facter, so maybe he's willing
to step down ?

> I notice that facter is
> currently under the ruby maintainer email namespace, but right now it's not
> released to Rubygems since 2.4 and the code is 85% C++ now. I wouldn't mind
> throwing my hat in and becoming a maintainer if that would help? :)

Submit PRs requesting maintainer, and if they come with
patches that bring the ports up2date, you're maintainer
if the previous maintainer agrees.

> PS. Sorry if this is the wrong way to do this, first time emailing to a
> port maintainer list. I asked in the FreeBSD freenode room and people said
> this was the way to do it and to CC the Ports mailing list also :)

Both lists are fine. As this is more a general ports question,
-ports is probably fine for further discussion. There's not much
discussion on -ruby.

-- 
p...@opsec.eu+49 171 3101372 4 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"

Facter 3.X questions

[Peter M Souter]

Hello Facter FreeBSD maintainers!

Since Facter's move to a C/C++ codebase, a lot of facts have gone missing
on FreeBSD machines. As a dabbler in FreeBSD I want to help fix this! :)

I've opened a ticket to track it here (
https://tickets.puppetlabs.com/browse/FACT-1428) and I've been working on
getting those missing facts back. So far I've managed to get the DMI (bios
and manufacturer facts) and processor info working.

I have a few questions:

1) Are there any FreeBSD Puppet users out there on Puppet 4 with Facter 3,
who could give some feedback, see if there's anything else I've missed
from Facter 3 that they've noticed?

2) If anyone has some C knowledge and wants to help hack on some of the
more difficult missing areas such as determining swap space, networks and
such, that would be greatly appreciated. Getting kenv and sysctl settings
has been fairly simple, these ones have been a little bit more complex...

3) How difficult is it to become a maintainer? I notice that facter is
currently under the ruby maintainer email namespace, but right now it's not
released to Rubygems since 2.4 and the code is 85% C++ now. I wouldn't mind
throwing my hat in and becoming a maintainer if that would help? :)

Thanks!

Regards

Peter Souter

PS. Sorry if this is the wrong way to do this, first time emailing to a
port maintainer list. I asked in the FreeBSD freenode room and people said
this was the way to do it and to CC the Ports mailing list also :)
___
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: old ports/packages

[Jeffrey Bouquet via freebsd-ports]

On 06/ 3/16 08:17 AM, Franco Fichtner wrote:
> Hi there,
>
>> On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
>>
>> There is a main difference - if you upgraded from 9.2 to 9.3, you don't need 
>> to recompile (reinstall) all ports, but if you upgraded from 9.3 to 10.x you 
>> need to reinstall all your packages and then remove old 9.x libraries from 
>> the base system.
>> On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
>>
>> There is a main difference - if you upgraded from 9.2 to 9.3, you don't need 
>> to recompile (reinstall) all ports, but if you upgraded from 9.3 to 10.x you 
>> need to reinstall all your packages and then remove old 9.x libraries from 
>> the base system.
> This is very much true for a single user point of view, but
> the devil is in the details.  Let's go through the transition
> that we as the OPNsense project went through in the FreeBSD 10
> series...  Not a rant, just facts.
>
> The initial release was 10.0, which was phased out after a
> year, leaving us no choice but to go 10.1 just two months
> after our initial release in order to receive official security
> updates.  Worst case it takes a few months to adapt to the
> major transition so that's 12 months minus X months of internal
> engineering, depending on your staff expertise.  In that case
> we started in 2014, took us 4 months, that's 6 months including
> the time 10.0 was officially available, so 6 months left for
> support, when you actually start adapting to 10 as soon as it
> comes out.  For many that's a luxury not going to happen.  One
> can blame anyone for starting late, but it's not going to solve
> the real world problem.
>
> 10.1 went really well.  When 10.2 happened for us in January
> 2016, however, we've already went testing 3 months before and
> had a number of issues that were not being addressed upstream
> for a longer amount of time:
>
> o HyperV disks stopped registering as ada(4) devices, killing
>   installs that were not using labels.  Never fixed.
>
> o Hyper-V NAT broken for a very long time, only fixed in 10.2
>   after active polling for an errata[1]
>
> o pf checksumming broke with offloading[2]
>
> But the kicker was that building pkg on 10.2 suddenly changed
> the ABI behaviour in at least two ways that we know of:
>
> (1) The reaper for package scripts was now suddenly active,
> making it a lot harder to restart a service on package upgrade
> from their own scripts.  We hat do investigate and disable the
> reaper code in pkg itself in order to retain functionality.  I
> would think that others ran into this silently as well.
>
> (2) 10.1 systems preloading the "new" pkg for 10.2 were unable
> to upgrade certain packages, in this instance isc-dhcp43-*.
> It took a few months to even get to the point of triggering
> this.  In short, we pinned down the pkg ABI to 10.1[3] in order
> to allow our older 10.1 systems to upgrade.  This should not be
> happening in a "ABI stable" environment. There is pkg-static,
> but at least in the scope of FreeBSD it's only used when pkg
> fails for this or that reason, which is very hard to explain to
> a GUI or backend script.  Why not make it the default?
>
> 10.2 was the proverbial rollercoaster ride that some would not
> like to see repeated.  10.3 looks better, but what does that say
> about 10.4 or 11.0?
>
> But 10.3 already had a major speed regression during package
> installation only caught after the release[4].  Who knows what
> our users will be facing once we go live in a few months.
>
> For downstream projects, this is at least an order of magnitude
> worse than the simple user that sits in a shell and runs a magical
> fix command to amend its upgrade path.  fir some it's even impossible
> to get into a shell.  Most of downstream projects have automated
> processes, upgrade features that rely on certain behaviour, well,
> rely on behaviour to stay stable for at least 10.x, which would
> make sense.  ;)
>
> And now we run for each 10.x, every time just run for it in order
> to make sure that we're not missing an iteration that would amplify
> the problems we'll be facing with upgrading later.
>
> And mind you, this is *with* rebuilding everything from scratch
> for each minor update just to be on the safe side.  :)
>
>
> Cheers,
> Franco
>
> --
> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203630
> [2] https://www.freebsd.org/security/advisories/FreeBSD-EN-16:02.pf.asc
> [3] https://github.com/opnsense/ports/commit/76975890103
> [4] https://www.freebsd.org/security/advisories/FreeBSD-EN-16:06.libc.asc
> ___
> 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"
Yahoo mail refused to send my full reply to the recipients.   Suffice to
say I
recommended a backup to the pkg problem by a secondary
/var/db/pkg concurrent methodology.  

Re: old ports/packages

[Jeffrey Bouquet via freebsd-ports]

On 06/ 3/16 08:17 AM, Franco Fichtner wrote:
> Hi there,
>
>> On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
>>
>> There is a main difference - if you upgraded from 9.2 to 9.3, you don't need 
>> to recompile (reinstall) all ports, but if you upgraded from 9.3 to 10.x you 
>> need to reinstall all your packages and then remove old 9.x libraries from 
>> the base system.
>> On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
>>
>> There is a main difference - if you upgraded from 9.2 to 9.3, you don't need 
>> to recompile (reinstall) all ports, but if you upgraded from 9.3 to 10.x you 
>> need to reinstall all your packages and then remove old 9.x libraries from 
>> the base system.
> This is very much true for a single user point of view, but
> the devil is in the details.  Let's go through the transition
> that we as the OPNsense project went through in the FreeBSD 10
> series...  Not a rant, just facts.
>
> The initial release was 10.0, which was phased out after a
> year, leaving us no choice but to go 10.1 just two months
> after our initial release in order to receive official security
> updates.  Worst case it takes a few months to adapt to the
> major transition so that's 12 months minus X months of internal
> engineering, depending on your staff expertise.  In that case
> we started in 2014, took us 4 months, that's 6 months including
> the time 10.0 was officially available, so 6 months left for
> support, when you actually start adapting to 10 as soon as it
> comes out.  For many that's a luxury not going to happen.  One
> can blame anyone for starting late, but it's not going to solve
> the real world problem.
>
> 10.1 went really well.  When 10.2 happened for us in January
> 2016, however, we've already went testing 3 months before and
> had a number of issues that were not being addressed upstream
> for a longer amount of time:
>
> o HyperV disks stopped registering as ada(4) devices, killing
>   installs that were not using labels.  Never fixed.
>
> o Hyper-V NAT broken for a very long time, only fixed in 10.2
>   after active polling for an errata[1]
>
> o pf checksumming broke with offloading[2]
>
> But the kicker was that building pkg on 10.2 suddenly changed
> the ABI behaviour in at least two ways that we know of:
>
> (1) The reaper for package scripts was now suddenly active,
> making it a lot harder to restart a service on package upgrade
> from their own scripts.  We hat do investigate and disable the
> reaper code in pkg itself in order to retain functionality.  I
> would think that others ran into this silently as well.
>
> (2) 10.1 systems preloading the "new" pkg for 10.2 were unable
> to upgrade certain packages, in this instance isc-dhcp43-*.
> It took a few months to even get to the point of triggering
> this.  In short, we pinned down the pkg ABI to 10.1[3] in order
> to allow our older 10.1 systems to upgrade.  This should not be
> happening in a "ABI stable" environment. There is pkg-static,
> but at least in the scope of FreeBSD it's only used when pkg
> fails for this or that reason, which is very hard to explain to
> a GUI or backend script.  Why not make it the default?
>
> 10.2 was the proverbial rollercoaster ride that some would not
> like to see repeated.  10.3 looks better, but what does that say
> about 10.4 or 11.0?
>
> But 10.3 already had a major speed regression during package
> installation only caught after the release[4].  Who knows what
> our users will be facing once we go live in a few months.
>
> For downstream projects, this is at least an order of magnitude
> worse than the simple user that sits in a shell and runs a magical
> fix command to amend its upgrade path.  fir some it's even impossible
> to get into a shell.  Most of downstream projects have automated
> processes, upgrade features that rely on certain behaviour, well,
> rely on behaviour to stay stable for at least 10.x, which would
> make sense.  ;)
>
> And now we run for each 10.x, every time just run for it in order
> to make sure that we're not missing an iteration that would amplify
> the problems we'll be facing with upgrading later.
>
> And mind you, this is *with* rebuilding everything from scratch
> for each minor update just to be on the safe side.  :)
>
>
> Cheers,
> Franco
>
> --
> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203630
> [2] https://www.freebsd.org/security/advisories/FreeBSD-EN-16:02.pf.asc
> [3] https://github.com/opnsense/ports/commit/76975890103
> [4] https://www.freebsd.org/security/advisories/FreeBSD-EN-16:06.libc.asc
> ___
> 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"
I again wonder whether the old /var/db/pkg [ flat files rather
than an ABI ] could serve as a secondary means  to the pkg upgrade
of port/packages that was
problematic 

Re: old ports/packages

[Konstantin Belousov]

On Sat, Jun 04, 2016 at 06:20:24PM +0100, Matthew Seaman wrote:
> On 2016/06/04 16:14, William A. Mahaffey III wrote:
> > One point of order if I may: It was stated earlier in the thread that
> > binary compatibility throughout a major release cycle (X.n-R, as 'n'
> > varies) is a specification. That is not explicitly addressed in the
> > above URL's, as far as I can see. Is that indeed considered a
> > specification ? If so, it would seem to satisfy the LTS desire
> > implicitly. TIA & have a good one.
> 
> At the moment we have a guarantee of binary compatibility for any
> software compiled on release X.n to be able to run on any release X.m
> where m >= n.  This is not going to change with the new support model.
> 
> ie. Something compiled for 11.0 will run on any subsequent 11.x release,
> but something compiled on 11.3 (say) would not necessarily run on 11.2.
>  Now, in fact, that sort of backwards compatibility usually does work,
> but it isn't guaranteed.  Putting in this sort of backwards incompatible
> change is something that is avoided unless there is some very good
> reason to introduce it.
> 
> Also recognize that libc.so in 11.x will support ABI multi-versions --
> so you can run anything that needs an earlier ABI version without any
> special configuration[*].  This does not apply to all of the shlibs
> provided by the system, so you may get mixed results depending on what
> your applications link against.
We ship libc.so+libpthread.so+libm.so+rtld which support backward
compatibility up to FreeBSD 7.0.  This means that the 'core' C runtime
is ABI-stable.

It is not true for the less 'core' FreeBSD shlibs indeed, but that other
libraries are typically OS-depended and are used for system management
or configuration.

More severe cause of ABI breakage are the third-party shlibs, which ABI
is not maintained by the project and which updates cause at least incompatible
shlib version bumps.  Examples are openssl and ncurses.

This explains the reason why the packages are still have to be build per
major branch.

> 
> This is why the FreeBSD packages are always built on the earliest still
> supported release from the same major branch.  The difference implied by
> the new support model is that the package building machines would be
> updated more frequently as they track the earliest still-supported
> release.  Practically speaking, as a pkg user you're unlikely to
> experience any difficulties even if you aren't up to date with your OS
> patching, but there may be some rare occasions where you will need to
> update your OS before you can update your ports.
> 
>   Cheers,
> 
>   Matthew
> 
> [*] IIRC the available version history goes back to 10.0-RELEASE; you'll
> definitely need compat libs for anything compiled earlier than that, but
> you may well be able to run 10.x applications on an 11.x system with no
> compatibility shims required.
> 



___
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: old ports/packages

[Matthew Seaman]

On 2016/06/04 16:14, William A. Mahaffey III wrote:
> One point of order if I may: It was stated earlier in the thread that
> binary compatibility throughout a major release cycle (X.n-R, as 'n'
> varies) is a specification. That is not explicitly addressed in the
> above URL's, as far as I can see. Is that indeed considered a
> specification ? If so, it would seem to satisfy the LTS desire
> implicitly. TIA & have a good one.

At the moment we have a guarantee of binary compatibility for any
software compiled on release X.n to be able to run on any release X.m
where m >= n.  This is not going to change with the new support model.

ie. Something compiled for 11.0 will run on any subsequent 11.x release,
but something compiled on 11.3 (say) would not necessarily run on 11.2.
 Now, in fact, that sort of backwards compatibility usually does work,
but it isn't guaranteed.  Putting in this sort of backwards incompatible
change is something that is avoided unless there is some very good
reason to introduce it.

Also recognize that libc.so in 11.x will support ABI multi-versions --
so you can run anything that needs an earlier ABI version without any
special configuration[*].  This does not apply to all of the shlibs
provided by the system, so you may get mixed results depending on what
your applications link against.

This is why the FreeBSD packages are always built on the earliest still
supported release from the same major branch.  The difference implied by
the new support model is that the package building machines would be
updated more frequently as they track the earliest still-supported
release.  Practically speaking, as a pkg user you're unlikely to
experience any difficulties even if you aren't up to date with your OS
patching, but there may be some rare occasions where you will need to
update your OS before you can update your ports.

Cheers,

Matthew

[*] IIRC the available version history goes back to 10.0-RELEASE; you'll
definitely need compat libs for anything compiled earlier than that, but
you may well be able to run 10.x applications on an 11.x system with no
compatibility shims required.



signature.asc
Description: OpenPGP digital signature

Re: old ports/packages

[William A. Mahaffey III]

On 06/04/16 09:24, Matthew Seaman wrote:

On 04/06/2016 14:50, Grzegorz Junka wrote:

On 04/06/2016 13:45, Matthew Seaman wrote:

On 03/06/2016 17:23, Bob Eager wrote:

Why not just use odd numbered releases? That's what I do. They have a
longer support cycle.

Remember though that this model is changing with 11.0 release.  With the
new model, it's the 11.x family as a whole that has the long term
support and individual releases such as 11.0 or 11.1 will cease to be
supported very shortly after the next release in that series comes out.
The last release in that series will then have a long support life so
that 11.x as a whole has something like a 5 year lifecycle[*].  The
transitions from 11.0 -> 11.1 -> 11.2 -> ... are meant to be something
you could apply pretty much routinely; much as you'ld apply a new
patch-level today.

 Cheers,

 Matthew

[*] which is pretty much the same length as the the lifecycle of
previous major branches has been up to now.


Is there somewhere any more information available about this change?


https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html

https://news.ycombinator.com/item?id=8991960

Cheers,

Matthew





One point of order if I may: It was stated earlier in the thread that 
binary compatibility throughout a major release cycle (X.n-R, as 'n' 
varies) is a specification. That is not explicitly addressed in the 
above URL's, as far as I can see. Is that indeed considered a 
specification ? If so, it would seem to satisfy the LTS desire 
implicitly. TIA & have a good one.



--

William A. Mahaffey III

 --

"The M1 Garand is without doubt the finest implement of war
 ever devised by man."
   -- Gen. George S. Patton Jr.

___
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: old ports/packages

[Matthew Seaman]

On 04/06/2016 14:50, Grzegorz Junka wrote:
> 
> On 04/06/2016 13:45, Matthew Seaman wrote:
>> On 03/06/2016 17:23, Bob Eager wrote:
>>> Why not just use odd numbered releases? That's what I do. They have a
>>> longer support cycle.
>> Remember though that this model is changing with 11.0 release.  With the
>> new model, it's the 11.x family as a whole that has the long term
>> support and individual releases such as 11.0 or 11.1 will cease to be
>> supported very shortly after the next release in that series comes out.
>> The last release in that series will then have a long support life so
>> that 11.x as a whole has something like a 5 year lifecycle[*].  The
>> transitions from 11.0 -> 11.1 -> 11.2 -> ... are meant to be something
>> you could apply pretty much routinely; much as you'ld apply a new
>> patch-level today.
>>
>> Cheers,
>>
>> Matthew
>>
>> [*] which is pretty much the same length as the the lifecycle of
>> previous major branches has been up to now.
>>
> 
> Is there somewhere any more information available about this change?
> 

https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html

https://news.ycombinator.com/item?id=8991960

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: how do you force make install to overwrite conflicting files from another port?

[Patrick Powell]

On 06/03/16 10:53, Lowell Gilbert wrote:

Patrick Powell  writes:


Suppose that you have a portA which is a dependency of a lot of other ports.

You also have a portB which is a replacement/update/upgrade for portA.

PortB provides replacements for the executables generated/supplied by
PortA but for various reasons you still want to use some of PortA
installed items such as libraries,  etc.

I tried doing the following:

# pkg install PortA
# cd /usr/ports/xxx/PortB
# make install

Installing PortB...
pkg-static: PortB conflicts with PortA (installs files into the same
place).  Problematic file: /usr/local/bin/utilityl
*** Error code 70

Is there an option, or a way similar to using 'make
FORCE_PGK_REGISTER=YES install'
to force overwriting the conflicting files?

Not directly, no. The way to do it straight from the ports tree is to
remove the "PortA" *first* (with "pkg delete -f"), and then install
"PortB". You end up losing the dependency information that PortA had
formerly had, but things will work.

Upgrade tools (pkg, portmaster, portupgrade, at least) have a "-o"
option that fixes up the dependency information.

When you do the 'pkg delete -f PortA' then it will also delete the 
libraries installed by PortA.
if you do 'cd ...PortB; make install' and it will now install the files 
that were in conflict,

but there are now some libraries installed by PortA which are missing.

I understand that this is on the outskirts of package/port management,  
but there are times when
you want to install a test version of a utility which has only part of 
the functionality of another port.


--
Patrick Powell Astart Technologies
papow...@astart.com1530 Jamacha Rd, Suite X
Network and System San Diego, CA 92019
  Consulting   858-874-6543 FAX 858-751-2435
Web: www.astart.com

___
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: old ports/packages

[Grzegorz Junka]

On 04/06/2016 13:45, Matthew Seaman wrote:

On 03/06/2016 17:23, Bob Eager wrote:

Why not just use odd numbered releases? That's what I do. They have a
longer support cycle.

Remember though that this model is changing with 11.0 release.  With the
new model, it's the 11.x family as a whole that has the long term
support and individual releases such as 11.0 or 11.1 will cease to be
supported very shortly after the next release in that series comes out.
The last release in that series will then have a long support life so
that 11.x as a whole has something like a 5 year lifecycle[*].  The
transitions from 11.0 -> 11.1 -> 11.2 -> ... are meant to be something
you could apply pretty much routinely; much as you'ld apply a new
patch-level today.

Cheers,

Matthew

[*] which is pretty much the same length as the the lifecycle of
previous major branches has been up to now.



Is there somewhere any more information available about this change?

Cheers
Greg
___
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: old ports/packages

[Matthew Seaman]

On 03/06/2016 17:23, Bob Eager wrote:
> Why not just use odd numbered releases? That's what I do. They have a
> longer support cycle.

Remember though that this model is changing with 11.0 release.  With the
new model, it's the 11.x family as a whole that has the long term
support and individual releases such as 11.0 or 11.1 will cease to be
supported very shortly after the next release in that series comes out.
The last release in that series will then have a long support life so
that 11.x as a whole has something like a 5 year lifecycle[*].  The
transitions from 11.0 -> 11.1 -> 11.2 -> ... are meant to be something
you could apply pretty much routinely; much as you'ld apply a new
patch-level today.

Cheers,

Matthew

[*] which is pretty much the same length as the the lifecycle of
previous major branches has been up to now.




signature.asc
Description: OpenPGP digital signature

x11/nvidia-driver and CURRENT: update results in full fan blow on MSI GTX 960 Gaming 4G

[O. Hartmann]

Three months ago I purchased a new GPU to replace a non-UEFI capable GTX560 Ti 
(MSI). The
choice was the MSI GTX 960 Gaming 4G. Apart from the part, that this GPU 
doesn't show the
performance boost on FreeBSD CURRENT, even with the most recent BLOB from 
nVidia, 367.18,
I realized that after the update from FreeBSD 11-CURRENT r300830 to r300956 (I 
guess,
Forgot the exact revision number, but it was > 300950), the fans of that 
specific GPU
blow at full speed when xdm/Xorg server has been started. This is annoying, 
since the
noise is incredible.

I tried to recompile the whole ports xorg relies on via

portmaster -df xorg xdm

hoping, that some sort of bug or API incompatibility could have caused the 
problems, but
that wasn't at all the case.

I run now r301300 and the "problem" is still present.

The environmental conditions did not change - not in a way that the full speed 
fan of the
GPU could be explained by raised temperatures of the environment. I tried to 
find via
Google some help, but it seems that I'm the first and only one having this 
problem,
especially with FreeBSD and this type of GPU. I also tried the official 
supported
x11/nvidia-driver (346.96 and the proposed 364.19) with no success.

Below, You will find some data I picked up from the kernel environment (if 
there are
other ways, please tell me) and the logfile of Xorg/X server.


[...]
hw.nvidia.gpus.0.type: PCIe
hw.nvidia.gpus.0.uuid: GPU-85fde95a-7974-9962-f1a4-d7c164413929
hw.nvidia.gpus.0.vbios: 84.06.26.00.21
hw.nvidia.gpus.0.irq: 270
hw.nvidia.gpus.0.model: GeForce GTX 960
hw.nvidia.registry.dwords: 
hw.nvidia.registry.TCEBypassMode: 0
hw.nvidia.registry.MemoryPoolSize: 0
hw.nvidia.registry.EnablePCIeGen3: 1
hw.nvidia.registry.CheckPCIConfigSpace: 4294967295
hw.nvidia.registry.RegisterForACPIEvents: 1
hw.nvidia.registry.MapRegistersEarly: 0
hw.nvidia.registry.EnableMSI: 1
hw.nvidia.registry.UsePageAttributeTable: 4294967295
hw.nvidia.registry.InitializeSystemMemoryAllocations: 1
hw.nvidia.registry.UpdateMemoryTypes: 4294967295
hw.nvidia.registry.DeviceFileMode: 438
hw.nvidia.registry.DeviceFileGID: 0
hw.nvidia.registry.DeviceFileUID: 0
hw.nvidia.registry.ModifyDeviceFiles: 1
hw.nvidia.registry.RmLogonRC: 1
hw.nvidia.registry.ResmanDebugLevel: 4294967295
hw.nvidia.registry.Mobile: 4294967295
hw.nvidia.version: NVIDIA UNIX x86_64 Kernel Module  367.18  Mon May 16 
18:13:16 PDT 2016
dev.nvidia.0.%parent: vgapci0
dev.nvidia.0.%pnpinfo: 
dev.nvidia.0.%location: 
dev.nvidia.0.%driver: nvidia
dev.nvidia.0.%desc: GeForce GTX 960
dev.nvidia.%parent: 


Hopefully someone can give some hints what could trigger the problem ...

Thanks in advance and please CC me (due to not subscribing this list).

Kind regards,

Oliver


pgp567nHhF1UE.pgp
Description: OpenPGP digital signature