Re: CFT upgrade to xorg 1.18.4 and newer intel/ati DDX

[Andrea Venturoli]

On 02/09/17 19:03, Pete Wright wrote:


I have run into the same issue, and I have reported this to the
maintainers.  This diff resolved the issue on my end, which allowed all
Xorg packages to build:


Thanks.
Solved here too.

 bye
av.
___
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't set maintainer-approval+ flag on an attachment

[Adam Weinberger]

> On 9 Feb, 2017, at 18:51, Mel Pilgrim  wrote:
> 
> A PR for a port I maintain includes a patch. I'm supposed to set the 
> maintainer-approval flag to + to approve the patch, but it doesn't seem to be 
> working.  When I go to the patch details page, I can set 
> maintainer-approval+, but it doesn't stick, even if I include a comment.  I 
> found an older thread[1] from this list which mentions the patch has to be 
> set to maintainer-approval? with my email address before I'm able to set 
> maintainer-approval+.  The patch did not have maintainer-approval? set.  Is 
> that bug still unfixed?
> 
> 1: https://lists.freebsd.org/pipermail/freebsd-ports/2015-March/098255.html

Which PR?

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.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"

Can't set maintainer-approval+ flag on an attachment

[Mel Pilgrim]

A PR for a port I maintain includes a patch. I'm supposed to set the 
maintainer-approval flag to + to approve the patch, but it doesn't seem 
to be working.  When I go to the patch details page, I can set 
maintainer-approval+, but it doesn't stick, even if I include a comment. 
 I found an older thread[1] from this list which mentions the patch has 
to be set to maintainer-approval? with my email address before I'm able 
to set maintainer-approval+.  The patch did not have 
maintainer-approval? set.  Is that bug still unfixed?


1: https://lists.freebsd.org/pipermail/freebsd-ports/2015-March/098255.html
___
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: ports and dependency hell

[Martin Waschbüsch]

> Am 09.02.2017 um 18:14 schrieb Julian Elischer :
> 
> Commercial products are Hardly EVER rolling releases.
> they lurch from point of stability to point of stability, with large amounts 
> of testing between releases.
>>> On the pkg side of things we need the ability for pkg to say "yeah I
>>> know I'm looking for foo-1.2.3.txz as a perfect match, but I've been
>>> given some slack on the third digit and I can see a foo-1.2.1.txz, so
>>> I'll install that instead".
>> I'm not sure how you would do that in a general way that didn't add
>> extra work for package maintainers.
> pkg would have to do it looking in the pkg index.

For every package depending on another as a building block, there are
constraints as to which version (or range of versions) can satisfy the
dependency.
If more than one package depend on the same building blocks but (which
is more likely than not) depend on different versions (or ranges of
versions) of that package, the constraints become ever stricter,
narrowing down the possible combinations.

When installing just a limited few packages then maybe knowing about
compatible ranges of versions of those packages would allow for more
flexibility, but it does not sound practical at all:
A specific version of package A can be compiled against all versions of
library B v1.1, 1.2 or 1.3. Now, unless the exposed symbols where
identical for all three versions, we would need to build a binary
package for every combination of A and B. And we have not even
considered what other versions of package A people might want to
install...
REALLY few packages and versions are needed before this becomes totally
unfeasible.

Now, as I see it, what pkg tries to do is for each snapshot to have as
few conflicts as possible when you mix and match arbitrary packages by
doing pkg install   .
I am not saying there are no conflicts, but the system and the package
maintainers(!) do a great job of keeping packages both up to date and
compatible to each other.
You get that stability by not having a lot of choice where versions are
concerned.
But if you need more control over versions and package options,
poudriere offers a very flexible way to create a customized (sub)set of
pkgs tailored to your needs.
Do the default pkg repo or poudriere cover all possible scenarios? No
way! But I fail to understand how they could be expected to do that.
Thus, what you describe sounds, imho, like wanting to eat the cake
and have it.

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"

Re: pkg upgrade deletes firefox?

[Domagoj Stolfa]

This is due to the DTRACE option breaking the Firefox build currently. You can
compile it from ports by disabling the DTRACE option.

--
Best regards,
Domagoj Stolfa

On Thu, Feb 09, 2017 at 09:21:18PM +0100, Ronald Klop wrote:
> Interesting:
>
> # 21:12:51 root@sjakie [~]
> pkg install firefox
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up-to-date.
> All repositories are up-to-date.
> pkg: No packages available to install matching 'firefox' have been found
> in the repositories
>
> I guess this is a temporary hickup.
>
> Ronald.
>
>
>
> On Thu, 09 Feb 2017 21:12:28 +0100, Ronald Klop 
> wrote:
>
> > Hi,
> >
> > Today I get this...
> >
> > # 21:08:42 root@sjakie [~]
> > pkg upgrade
> > Updating FreeBSD repository catalogue...
> > Fetching meta.txz: 100%944 B   0.9kB/s00:01
> > Fetching packagesite.txz: 100%6 MiB   3.0MB/s00:02
> > Processing entries: 100%
> > FreeBSD repository update completed. 25950 packages processed.
> > Checking for upgrades (13 candidates): 100%
> > Processing candidates (13 candidates): 100%
> > The following 13 package(s) will be affected (of 0 checked):
> >
> > Installed packages to be REMOVED:
> > firefox-51.0.1,1
> >
> > Installed packages to be UPGRADED:
> > xkeyboard-config: 2.19 -> 2.20
> > xconsole: 1.0.6_1 -> 1.0.7
> > xauth: 1.0.9_1 -> 1.0.10
> > vim-lite: 8.0.0252 -> 8.0.0301
> > tmux: 2.3 -> 2.3_1
> > opencollada: 1.6.25 -> 1.6.37
> > mplayer: 1.3.0.20161228_2 -> 1.3.0.20161228_3
> > libevent2: 2.0.22_1 -> 2.1.8
> > libass: 0.13.5 -> 0.13.6
> > gstreamer1: 1.8.0 -> 1.8.0_1
> > gstreamer: 0.10.36_5 -> 0.10.36_6
> > ffmpeg: 3.2.2_5,1 -> 3.2.2_6,1
> >
> > Number of packages to be removed: 1
> > Number of packages to be upgraded: 12
> >
> > The operation will free 124 MiB.
> > 25 MiB to be downloaded.
> >
> > Proceed with this action? [y/N]:
> >
> >
> > Why would upgrade want to remove firefox?
> >
> > Regards,
> > Ronald.
> > ___
> > freebsd-sta...@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-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"


signature.asc
Description: PGP signature

Re: pkg upgrade deletes firefox?

[Ronald Klop]

Interesting:

# 21:12:51 root@sjakie [~]
pkg install firefox
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
pkg: No packages available to install matching 'firefox' have been found  
in the repositories


I guess this is a temporary hickup.

Ronald.



On Thu, 09 Feb 2017 21:12:28 +0100, Ronald Klop   
wrote:



Hi,

Today I get this...

# 21:08:42 root@sjakie [~]
pkg upgrade
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%944 B   0.9kB/s00:01
Fetching packagesite.txz: 100%6 MiB   3.0MB/s00:02
Processing entries: 100%
FreeBSD repository update completed. 25950 packages processed.
Checking for upgrades (13 candidates): 100%
Processing candidates (13 candidates): 100%
The following 13 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
firefox-51.0.1,1

Installed packages to be UPGRADED:
xkeyboard-config: 2.19 -> 2.20
xconsole: 1.0.6_1 -> 1.0.7
xauth: 1.0.9_1 -> 1.0.10
vim-lite: 8.0.0252 -> 8.0.0301
tmux: 2.3 -> 2.3_1
opencollada: 1.6.25 -> 1.6.37
mplayer: 1.3.0.20161228_2 -> 1.3.0.20161228_3
libevent2: 2.0.22_1 -> 2.1.8
libass: 0.13.5 -> 0.13.6
gstreamer1: 1.8.0 -> 1.8.0_1
gstreamer: 0.10.36_5 -> 0.10.36_6
ffmpeg: 3.2.2_5,1 -> 3.2.2_6,1

Number of packages to be removed: 1
Number of packages to be upgraded: 12

The operation will free 124 MiB.
25 MiB to be downloaded.

Proceed with this action? [y/N]:


Why would upgrade want to remove firefox?

Regards,
Ronald.
___
freebsd-sta...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-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: CFT upgrade to xorg 1.18.4 and newer intel/ati DDX

[Pete Wright]

On 02/09/2017 08:57, Andrea Venturoli wrote:

On 01/24/17 00:55, Baptiste Daroussin wrote:

Hi all,

This is a call for testing for newer Xorg along with newer drivers: 
intel and

ati.


Hello.
Thanks for your work.

I'm willing to test this, since I'm experiencing frequent X lock ups 
on an Intel-based laptop.


I applied your patch to my port tree and added the following to my 
poudriere's build list:

x11-drivers/xf86-video-ati (this is for another PC)
x11-drivers/xf86-input-keyboard
x11-drivers/xf86-input-mouse
x11-drivers/xf86-video-intel

However xf86-input-keyboard and xf86-input-mouse fail with:
> ...

checking for asprintf... (cached) yes
checking for XORG... no
configure: error: Package requirements (xorg-server >= 1.7 xproto 
inputproto) were not met:


Package dri3proto was not found in the pkg-config search path.
Perhaps you should add the directory containing `dri3proto.pc'
to the PKG_CONFIG_PATH environment variable
Package 'dri3proto', required by 'xorg-server', not found


Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables XORG_CFLAGS
and XORG_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
===>  Script "configure" failed unexpectedly.




I have run into the same issue, and I have reported this to the 
maintainers.  This diff resolved the issue on my end, which allowed all 
Xorg packages to build:


$ git diff Mk/bsd.xorg.mk
diff --git a/Mk/bsd.xorg.mk b/Mk/bsd.xorg.mk
index 295d7b9112a6..6110936583a3 100644
--- a/Mk/bsd.xorg.mk
+++ b/Mk/bsd.xorg.mk
@@ -59,7 +59,7 @@ USE_XORG+=  xorg-macros

 . if ${XORG_CAT} == "driver"
 USE_XORG+= xorg-server xproto randrproto xi renderproto xextproto \
-   inputproto kbproto fontsproto videoproto dri2proto 
xf86driproto \
+ inputproto kbproto fontsproto videoproto dri2proto dri3proto 
xf86driproto \
presentproto glproto xineramaproto resourceproto 
scrnsaverproto

 # work around a llvm bug on i386, llvm bug #15806
 # reproduced with clang 3.2 (current release) and 3.1


I believe this fix will be included in the upcoming release. basically 
we need to ensure that dri3proto is built along with Xorg as I believe 
some of the newer xorg drivers have a hard dependency on dri3.


HTH,
-pete

___
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: ports and dependency hell

[Julian Elischer]

On 9/2/17 11:02 pm, Steve Wills wrote:

Hi Julian,

On 02/07/2017 13:03, Julian Elischer wrote:
[...]
I found this all confusing and vague, but it sounds like what's
happening is you need older versions of some software for whatever
reason and to provide that you are pulling older versions of ports into
a newer ports tree. Is that right?


the problem is that the internal APIs of ports are changing too much.

Sorry, what do you mean? Can you define "too much" change?
the specification of what you are getting is intermixed too much with 
the makefile components that

interact with the .mk files.

In a slightly theoretical world you would have two files..
one says "MAJOR=2 ; MINOR=2" (or similar) , and specifies the 
checksums etc
and the other gives options and dependencies (which don't usually 
change as fast as you think) but uses all the

complicted USES stuff for example.
so you couth PROBABLY get a range of module versions to compile with 
the same base makefile as long as it matches the .mk

files.





If you are going to change the API, then you need to be able to declare
the version separately, maybe in a version/distinfo file that can be
pulled in separately at a different rev, rather than having it built
into the main Makefile of each port. Maybe the Makefile specifies a
revision range it can be used with, but that would make a huge
improvement right there.

The idea of having ports/packages support a version range for
dependencies is an interesting one, but I'm not sure how that would work.


You can not just slide one port up by 3 months, and another down by 3
months to get the revs one needs because the damned Mk files have
changed. If I coudl leave the bulk of the Makefile alone and just slide
the 'distingo/rev' file, (or be able to select a rev from one htat gives
many alternatives, that woudl be "wonderful".

You're better off finding the tree that has the right version of the
oldest thing you need to use and then updating the things that you need
updated.

but that is not reproducible in source control



Please, ports framework people,  think about how this can be done, If I
have to edit a file, the game is lost.

Can we please get some understanding from ports people that they are
making things REALLY HARD on vendors and it really strengthens the hands
of  the "ditch FreeBSD and go to Linux" crowd when I need to spend a
whole week trying to integrate in a set of 5 new ports into the product.

The call "It just works under linux, select the versions you want of
each package and type make" is often heard around the company. And
management is not totally deaf.

If you want to see how its' done better (still not perfect), go build a
busybox system. you can effectively select any version of any tool and
they all communicate via the pkgconf mechanism and you get the result
you want.(mostly). And the API is stable.

Sounds like you've got a lot of folks who are used to the "LTS" mindset
where they never have to update their software to work with newer
versions. But ports is a rolling release in the head branch and
quarterly for those branches, and that's how it is going to be unless
someone wants to volunteer to maintain branches for longer. The LTS
thing works because people are paid to back port fixes and you can get
those for free.

Commercial products are Hardly EVER rolling releases.
they lurch from point of stability to point of stability, with large 
amounts of testing between releases.

On the pkg side of things we need the ability for pkg to say "yeah I
know I'm looking for foo-1.2.3.txz as a perfect match, but I've been
given some slack on the third digit and I can see a foo-1.2.1.txz, so
I'll install that instead".

I'm not sure how you would do that in a general way that didn't add
extra work for package maintainers.

pkg would have to do it looking in the pkg index.




Otherwise we just have to spend WAY too much time generating dozens of
"matching sets" of packages , that must be kept around forever if just
one machine shipped with that set, not to mention the fact that making
the matching set is often a real task.

Packages should generally be maintained as sets, rather than individual
packages, IMHO.

See "required by different teams" in the first email.




The way to get around the problem above CAN be (not always) to install
foo.1.2.1 first and THEN install the package you actually want, and pkg
will accept it. The problem comes when pkg needs to install a dependency
itself. Then it becomes "super picky", when there is actually a range of
package revisions that would do. Instead of letting pkg install what it
needs, we need to manually set up scripts to install the dependencies.
so that all the work done by pkg is wasted.


Please think about these two issues..

You can always use 'pkg lock' to lock a particular version of a package.

Steve

solution by sledgehammer





___
freebsd-ports@freebsd.org mailing list

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Matthew Seaman]

On 02/09/17 16:44, Miroslav Lachman wrote:
> Why don't add some check in to "pkg" to deny (or warn user) upgrade or
> install on unsupported / EOLed system?
> Just check version on current system against some metadata info in
> repository.

Actually the metadata should be in the package, rather than the
repository.  We need to record the OS version the package was compiled
under at the point the package is created, and then pkg(8) can compare
that to the OS version at install time.  This will work not just for the
FreeBSD pkg repos, but for packages built for private repos too.  And it
will still work, even if you grab a bunch of packages from somewhere
else and make your own repo from them.

Even so, pkg(8) should not refuse to install the newer package on the
older system; just emit a big fat warning that what you're doing is
dangerous, and may lead you into regret and grief.  (Unix has a
tradition of not stopping users from doing stupid things, because that
also makes it possible to do amazingly clever things...)

This is complicated by such things as 'NO_ARCH' packages -- your pure
perl/ruby/python code is still going to work almost regardless of the OS
version.  As will all sorts of type fonts or collections of desktop
icons and so forth.

Plus this will need to be carefully debugged when packages are
cross-compiled or compiled in jails on a host system with a different
kernel version.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 6:03 PM, Steve Wills  wrote:
> 
> Just because you don't use any features of the newer version doesn't
> mean it's safe to run binaries built for the newer version on the older
> version, as far as I understand it.

True.  :)

Yet the reports are for missing symbols in pkg and how to fix.  It
beats pulling a ports tree and rebuilding pkg which may or may not
end up being replaced by a newer repo version on the next pkg upgrade.

Plus you still get to garbage-collect compatibility features during
major upgrade jumps.

Fixing this issue in 25k at the same times ends up delaying a workable
solution, whatever it may be.

pkg first, then the rest, no?


Cheers,
Franco
___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Konstantin Belousov]

On Thu, Feb 09, 2017 at 04:42:45PM +, Matthew Seaman wrote:
> Why do you think it is not being enforced?  Forwards compatibility means
> that during the lifetime of a major branch you can only *add* symbols to
> the system shared libraries, not remove them nor modify any existing
> symbols.  The project has held to that for many years -- not breaking
> ABI forwards compatibility is a really big deal amongst developers.

We try hard to not break ABI backward compatibility between branches
as well, at least for user code (see below). In particular, versioned
libraries in base must be fully backward compatible between branches.
Whole set of the base C runtime libraries is versioned, i.e.
rtld/libc/libthr/libm. libc++ is versioned as well.

For non-versioned libraries, our promise is that on ABI breakage of
any kind, the library version (the libXXX.so.N, the N part) is bumped
so backward compatibility can be provided in some form by installing
previous version of the library. This is done, besides other means, by
misc/compatX ports.

The explanation above is of course, simplified, and somewhat incorrect.
To make it correct would require amount of work which is apparently too
much for single person to do and still be sane.  You can see it that
the project' ABI promise is not formalized even on wiki.

Place were ABI is very badly broken regularly is the management interfaces.
For instance, you are almost guaranteed that ifconfig(8) from a major
branch works only with the kernels on the same branch, and even then,
you must have the binary built with headers from very close kernel
version.  Same for cam(4).

Formalizing these exceptions is the hard part of writing the
ABI guarantee document.
___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Steve Wills]

Hi,

On 02/09/2017 12:00, Franco Fichtner wrote:
> 
> Let me try another way:
> 
> Since pkg has feature macros for building correctly on different
> FreeBSD versions, namely 10.0, 10.1, 10.2 and 10.3, the way to
> provide binaries without missing symbols is to build pkg with a
> fixed set of feature macros for 10.0.
> 
> I've done this for projects to retain upgrade paths.  It's not
> hard.  It doesn't violate a policy or promise FreeBSD makes, does
> it?
> 

Just because you don't use any features of the newer version doesn't
mean it's safe to run binaries built for the newer version on the older
version, as far as I understand it.

Steve




signature.asc
Description: OpenPGP digital signature

Re: CFT upgrade to xorg 1.18.4 and newer intel/ati DDX

[Andrea Venturoli]

On 01/24/17 00:55, Baptiste Daroussin wrote:

Hi all,

This is a call for testing for newer Xorg along with newer drivers: intel and
ati.


Hello.
Thanks for your work.

I'm willing to test this, since I'm experiencing frequent X lock ups on 
an Intel-based laptop.


I applied your patch to my port tree and added the following to my 
poudriere's build list:

x11-drivers/xf86-video-ati (this is for another PC)
x11-drivers/xf86-input-keyboard
x11-drivers/xf86-input-mouse
x11-drivers/xf86-video-intel

However xf86-input-keyboard and xf86-input-mouse fail with:
> ...

checking for asprintf... (cached) yes
checking for XORG... no
configure: error: Package requirements (xorg-server >= 1.7 xproto inputproto) 
were not met:

Package dri3proto was not found in the pkg-config search path.
Perhaps you should add the directory containing `dri3proto.pc'
to the PKG_CONFIG_PATH environment variable
Package 'dri3proto', required by 'xorg-server', not found


Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables XORG_CFLAGS
and XORG_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
===>  Script "configure" failed unexpectedly.




I had never built these ports with poudriere before and they build 
manually, so I'm not saying these patches are the culprit... I'm just 
quite new to poudriere and looking for hints.


Thanks for any pointer.

 bye
av.
___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Steve Wills]

Hi,

On 02/09/2017 11:44, Miroslav Lachman wrote:
> Why don't add some check in to "pkg" to deny (or warn user) upgrade or
> install on unsupported / EOLed system?
> Just check version on current system against some metadata info in
> repository.

I would be happy to see a patch that showed how this might be done.

> Is it too much to ask?

It's always too much to ask another to do work for you for free. :)

Steve



signature.asc
Description: OpenPGP digital signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 5:53 PM, Steve Wills  wrote:
> 
> What would enforcement look like? Something like "Sorry, you can't pkg
> update because this system isn't supported any more."? But how would
> that be possible without also breaking things for those who build/ship
> their own OS and packages?

Let me try another way:

Since pkg has feature macros for building correctly on different
FreeBSD versions, namely 10.0, 10.1, 10.2 and 10.3, the way to
provide binaries without missing symbols is to build pkg with a
fixed set of feature macros for 10.0.

I've done this for projects to retain upgrade paths.  It's not
hard.  It doesn't violate a policy or promise FreeBSD makes, does
it?


Cheers,
Franco
___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 5:53 PM, Steve Wills  wrote:
> 
> What would enforcement look like? Something like "Sorry, you can't pkg
> update because this system isn't supported any more."? But how would
> that be possible without also breaking things for those who build/ship
> their own OS and packages?

Let me try another way:

Since pkg has feature macros for building correctly on different
FreeBSD versions, namely 10.0, 10.1, 10.2 and 10.3, the way to
provide binaries without missing symbols is to build pkg with a
fixed set of feature macros for 10.0.

I've done this for projects to retain upgrade paths.  It's not
hard.  It doesn't violate a policy or promise FreeBSD makes, does
it?


Cheers,
Franco
___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Konstantin Belousov]

On Thu, Feb 09, 2017 at 05:26:00PM +0100, Kurt Jaeger wrote:
> Hi!
> 
> > On Thu, Feb 09, 2017 at 04:30:20PM +0100, Franco Fichtner wrote:
> > > FreeBSD package management makes an ABI promise in the form of
> > > "FreeBSD:10:amd64", but not even pkg code itself adheres to this,
> > > and thus we have had subtle and yet fatal breakage in 10.2 and 10.3.
> > Stop spreading FUD. There is no ABI breakage on stable/10 branch,
> > nor there is a breakage in the package sets.
> 
> On the one hand:
> 
> Maybe we can agree that the pkg binary breaking between different
> 10.x versions was unfortunate ? I understand that it was not a
> break of the ABI promises per se, but I can tell you, I was surprised
> as well, when it bite me 8-}
The pkg did not break.  Your usage of it and probably assumptions which
lead to that usage, are broken.  It is as simple as never use a binary
which was built for later system, on earlier.  Even if the binary run, you
get undefined results, e.g. data corruption.

We even grow kern.disallow_high_osrel knob to help people, who cannot
manage herself, to avoid shooting into their foot.  There are some obvious
drawbacks from setting this knob on by default, which explains why it
is not set (it makes recovering from other user mistakes much harder
and the failure mode much more fatal).

> 
> On the other hand:
> 
> Getting the ports/pkg tree moving with the velocity necessary
> to cope with the fast-changing world, sometimes things break
> and we all try to prevent this. Sometimes, mistakes happen...
> 
> -- 
> 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"

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Steve Wills]

Hi,

On 02/09/2017 11:24, Franco Fichtner wrote:
> 
>> On 9 Feb 2017, at 5:21 PM, Steve Wills  wrote:
>>
>> We provide backwards compatibility, not forwards compatibility.
> 
> But don't you see that users won't know this?

Users who don't know their software is no longer supported and refuse to
update can't be helped, IMHO.

> This is a good theory, yet it is difficult in practice because it is
> not being enforced.

What would enforcement look like? Something like "Sorry, you can't pkg
update because this system isn't supported any more."? But how would
that be possible without also breaking things for those who build/ship
their own OS and packages?

Steve




signature.asc
Description: OpenPGP digital signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Miroslav Lachman]

Kurt Jaeger wrote on 2017/02/09 17:26:

Hi!


On Thu, Feb 09, 2017 at 04:30:20PM +0100, Franco Fichtner wrote:

FreeBSD package management makes an ABI promise in the form of
"FreeBSD:10:amd64", but not even pkg code itself adheres to this,
and thus we have had subtle and yet fatal breakage in 10.2 and 10.3.

Stop spreading FUD. There is no ABI breakage on stable/10 branch,
nor there is a breakage in the package sets.


On the one hand:

Maybe we can agree that the pkg binary breaking between different
10.x versions was unfortunate ? I understand that it was not a
break of the ABI promises per se, but I can tell you, I was surprised
as well, when it bite me 8-}

On the other hand:

Getting the ports/pkg tree moving with the velocity necessary
to cope with the fast-changing world, sometimes things break
and we all try to prevent this. Sometimes, mistakes happen...


I don't have a problem with pkg / ports but I see the point from some 
others perspective.


Why don't add some check in to "pkg" to deny (or warn user) upgrade or 
install on unsupported / EOLed system?
Just check version on current system against some metadata info in 
repository.


Is it too much to ask?

Miroslav Lachman

___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Matthew Seaman]

On 2017/02/09 16:24, Franco Fichtner wrote:
>> On 9 Feb 2017, at 5:21 PM, Steve Wills  wrote:
>>
>> We provide backwards compatibility, not forwards compatibility.

> But don't you see that users won't know this?

Forward compatibility has been the ABI stability guarantee basically
ever since there has been a FreeBSD project.   Anything you compile now
will continue to work on later OS versions.  However you cannot
guarantee it will work on earlier versions.

The fact that newer binaries frequently will still work on older
releases in no way invalidates this claim.  That's just a reflection of
the fact that the system ABIs do not change particularly frequently.

> This is a good theory, yet it is difficult in practice because it is
> not being enforced.

Why do you think it is not being enforced?  Forwards compatibility means
that during the lifetime of a major branch you can only *add* symbols to
the system shared libraries, not remove them nor modify any existing
symbols.  The project has held to that for many years -- not breaking
ABI forwards compatibility is a really big deal amongst developers.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Kurt Jaeger]

Hi!

> On Thu, Feb 09, 2017 at 04:30:20PM +0100, Franco Fichtner wrote:
> > FreeBSD package management makes an ABI promise in the form of
> > "FreeBSD:10:amd64", but not even pkg code itself adheres to this,
> > and thus we have had subtle and yet fatal breakage in 10.2 and 10.3.
> Stop spreading FUD. There is no ABI breakage on stable/10 branch,
> nor there is a breakage in the package sets.

On the one hand:

Maybe we can agree that the pkg binary breaking between different
10.x versions was unfortunate ? I understand that it was not a
break of the ABI promises per se, but I can tell you, I was surprised
as well, when it bite me 8-}

On the other hand:

Getting the ports/pkg tree moving with the velocity necessary
to cope with the fast-changing world, sometimes things break
and we all try to prevent this. Sometimes, mistakes happen...

-- 
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"

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 5:21 PM, Steve Wills  wrote:
> 
> We provide backwards compatibility, not forwards compatibility.

But don't you see that users won't know this?

This is a good theory, yet it is difficult in practice because it is
not being enforced.


Cheers,
Franco
___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 5:21 PM, Steve Wills  wrote:
> 
> We provide backwards compatibility, not forwards compatibility.

But don't you see that users won't know this?

This is a good theory, yet it is difficult in practice because it is
not being enforced.


Cheers,
Franco
___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Steve Wills]

Hi,

On 02/09/2017 11:14, Franco Fichtner wrote:
> 
> You're contradicting yourself here.  Either it's compatible or it isn't?
> 

Not at all. There's a difference between backwards compatibility (binary
built on older release works on newer release) and forwards
compatibility (binary built on newer release works on older release).

We provide backwards compatibility, not forwards compatibility.

Steve



signature.asc
Description: OpenPGP digital signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 5:12 PM, Konstantin Belousov  wrote:
> 
> On Thu, Feb 09, 2017 at 04:30:20PM +0100, Franco Fichtner wrote:
>> FreeBSD package management makes an ABI promise in the form of
>> "FreeBSD:10:amd64", but not even pkg code itself adheres to this,
>> and thus we have had subtle and yet fatal breakage in 10.2 and 10.3.
> Stop spreading FUD. There is no ABI breakage on stable/10 branch,
> nor there is a breakage in the package sets. We only promise
> backward-compatibility, and this works as advertized. A binary compiled
> on later system, is not guaranteed to work on the early system even on
> the same branch.
> 
> The current package set for stable/10 is built on 10.3 and is only
> guaranteed to work on 10.3 and later. Trying to make arbitrary
> combinations of binaries and base systems outside of the scope of the
> project.

You're contradicting yourself here.  Either it's compatible or it isn't?


Cheers,
Franco
___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Konstantin Belousov]

On Thu, Feb 09, 2017 at 04:30:20PM +0100, Franco Fichtner wrote:
> FreeBSD package management makes an ABI promise in the form of
> "FreeBSD:10:amd64", but not even pkg code itself adheres to this,
> and thus we have had subtle and yet fatal breakage in 10.2 and 10.3.
Stop spreading FUD. There is no ABI breakage on stable/10 branch,
nor there is a breakage in the package sets. We only promise
backward-compatibility, and this works as advertized. A binary compiled
on later system, is not guaranteed to work on the early system even on
the same branch.

The current package set for stable/10 is built on 10.3 and is only
guaranteed to work on 10.3 and later. Trying to make arbitrary
combinations of binaries and base systems outside of the scope of the
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"

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Steve Wills]

Hi,

On 02/09/2017 11:01, Franco Fichtner wrote:
> 
>> On 9 Feb 2017, at 4:47 PM, Steve Wills  wrote:
>>
>> They're supposed to upgrade to a supported version of FreeBSD.
> 
> pkg won't refuse the upgrade.  And at least if it upgraded, it
> should not break itself.

Even if the update of pkg were done before the upgrade of the OS, if the
user ran "freebsd-update" to upgrade to 10.3, the version of pkg that it
updated to would work properly.

> Imagine a GUI-driven appliance being bricked.  There is nobody
> who can tell it "fetch ports and build pkg to keep using it".

Vendors should be building their own packages.

> Don't get me wrong.  Automation around pkg is really good, though
> that doesn't warrant it's perfect (yet).

I agree it's good, and nothing is ever perfect.

Steve



signature.asc
Description: OpenPGP digital signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 4:47 PM, Steve Wills  wrote:
> 
> They're supposed to upgrade to a supported version of FreeBSD.

pkg won't refuse the upgrade.  And at least if it upgraded, it
should not break itself.

Imagine a GUI-driven appliance being bricked.  There is nobody
who can tell it "fetch ports and build pkg to keep using it".

Don't get me wrong.  Automation around pkg is really good, though
that doesn't warrant it's perfect (yet).


Cheers,
Franco
___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Steve Wills]

Hi,

On 02/09/2017 10:30, Franco Fichtner wrote:
> Hi Steve,
> 
>> On 9 Feb 2017, at 4:09 PM, Steve Wills  wrote:
>>
>> Ports and packages are maintained on the assumption that the user is
>> using a supported version of the OS. We didn't decide when to end
>> support for 10.1 or 10.2. How long after the end of life for 10.1 would
>> you have ports maintain support?
> 
> The issue is quite simple and cause of multiple issues:
> 
> FreeBSD package management makes an ABI promise in the form of
> "FreeBSD:10:amd64", but not even pkg code itself adheres to this,
> and thus we have had subtle and yet fatal breakage in 10.2 and 10.3.
> 
> And since pkg acts according to the imposed paradigm of a unified
> ABI, this will continue to be a source of problems for users who
> cannot know what's going on, lest even know how to fix it.
> 
> They simply run:
> 
> # pkg upgrade
> 
> And then their systems are unusable *and* not fixable with pkg.
> 
> What are they supposed to do?  They come here.  They want to make
> everyone aware that this is a serious issue that shouldn't repeat
> in FreeBSD 11.  It's not to late to do that by pinning the pkg ABI
> to 11.0 by forcing the proper feature macros.

They're supposed to upgrade to a supported version of FreeBSD.

Steve




signature.asc
Description: OpenPGP digital signature

r313305 libevent2 problem and workaround NEED FIXING...

[Jeffrey Bouquet]

A huge six-day fix of seamonkey breakage on 11-CURRENT of april 2016, upgraded
finally last night to pkg 12-CURRENT feb 2017 working and etc by base.txz 
overwrite etc...
...
I've many many hours to restore the desktop to full how-it-was-before, but as it
is working, now, a wholesale 3xxx reinstall of ports by pkg (which had to
occur OUT OF Xorg for stall issues... and lack of granularity in the
use of "pkg upgrade"  (ie thirty-by-thirty) or lack of code in
"pkg install" (terse deinstalls necc. where reinstalls were needed)
as of this date
.
Mostly fixed as I write from the fixed system, but the only reason I am using 
seamonkey
now, and also fixed firefox, just then, is the series of commands... which I 
expect to
maybe re-break when v12 upgrades _4 seamonkey to _5 which broke (segfaults) here
from ports the port... but in the meantime
..
cp -iv /[backup mount}/usr/local/lib/libevent-2.0.so.5.10 
/usr/local/lib/compat/libevent-2.0.so.5
cp -iv /usr/local/lib/compat/libevent-2.0.so.5 
/usr/ports/www/seamonkey/libevent-2.0.so.5-NECC-FOR-SEAMONKEY
..
backup restored a newly overnight broken seamonkey AND firefox, the former not 
as of a day or
so from ports being able to run.
.
This is quite the showstopper here... almost forced a reinstall of 2004-2017 ( 
this desktop)
to a 2016-STABLE v11 new disk which I may have to revert to if seamonkey 
breaks again or
the next iteration of libevent/seamonkey/firefox does not fix up with CLI such 
as this time.

Out of time for a PR or bug report offically, and hope to gain more
pressing urgency to this problem than might be attained, that way... out of 
time also.
...
Thanks for reading, and thanks for putting up with interim list messages in the 
last few
days which still had a bit of almost PBKAC combined with lack of documentation 
combined with
newbie-ness here which had yet to resolve... 
and thanks for the forum post(s) which helped resolve the seemingly-lost-cause 
issue of the
v11-CURRENT upgrade to  v12-CURRENT which appears to have worked today vs 
several
days ago, IF seamonkey continues to be fixable locally.

J. Bouquet 
___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

Hi Steve,

> On 9 Feb 2017, at 4:09 PM, Steve Wills  wrote:
> 
> Ports and packages are maintained on the assumption that the user is
> using a supported version of the OS. We didn't decide when to end
> support for 10.1 or 10.2. How long after the end of life for 10.1 would
> you have ports maintain support?

The issue is quite simple and cause of multiple issues:

FreeBSD package management makes an ABI promise in the form of
"FreeBSD:10:amd64", but not even pkg code itself adheres to this,
and thus we have had subtle and yet fatal breakage in 10.2 and 10.3.

And since pkg acts according to the imposed paradigm of a unified
ABI, this will continue to be a source of problems for users who
cannot know what's going on, lest even know how to fix it.

They simply run:

# pkg upgrade

And then their systems are unusable *and* not fixable with pkg.

What are they supposed to do?  They come here.  They want to make
everyone aware that this is a serious issue that shouldn't repeat
in FreeBSD 11.  It's not to late to do that by pinning the pkg ABI
to 11.0 by forcing the proper feature macros.


Cheers,
Franco
___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Steve Wills]

Hi,

On 02/09/2017 03:55, Franco Fichtner wrote:
> 
>> On 9 Feb 2017, at 9:49 AM, Kirill Ponomarev  wrote:
>>
>> I don't understand all critics I see in this thread and in your mail,
>> the fate of this project is all in your hands - try to contribute more,
> 
> I'm going to stop you right there.
> 
> That's not entirely true.  Too few committers, substantial lack of
> maintainer feedback, apparently no mentors to pick up newcomers, and
> worst of all no newcomers.

I'm currently mentoring or co-mentoring 5 people. I've done everything
else I can to encourage others to mentor, I think. If you have
suggestions of someone who needs mentoring, let us know and we can try
to find a mentor.

There's nothing we can do about lack of maintainer feedback except reset
maintainers. But keep in mind that lack of maintainer feedback shouldn't
be an issue, we can commit changes after maintainer feedback timeout.

> Decide for yourself which of these are true and which are self-made
> due to project management policies.

What policies do you think need to be changed and in what specific ways?

Steve



signature.asc
Description: OpenPGP digital signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Steve Wills]

Hi,

On 02/08/2017 12:34, scratch65...@att.net wrote:
> 
> I *did* check for bug reports.  I did a search on "utimenstat"
> and found exactly one, which had been withdrawn as not being a
> bug. 
> 
> But it *is* a bug.  It's a bug on several levels, the most
> significant of which is that the overly frantic schedule makes
> versions have the lifespan of a mayfly.   And we're told "just
> upgrade", as though there's some physical law mandating the
> craziness.

Ports and packages are maintained on the assumption that the user is
using a supported version of the OS. We didn't decide when to end
support for 10.1 or 10.2. How long after the end of life for 10.1 would
you have ports maintain support?

> There are people for whom the system is a tool, not a hobby. They
> don't want to have to rebuild their tools any more than
> carpenters want to replace their hammers and levels every year or
> two.  

If you've having trouble upgrading that are causing you to rebuild, then
that's a different issue, but not one I can help with. It doesn't change
the fact that we don't support unsupported versions of the OS.

> For those people (I'm one) long version lifespans and bug-free
> operation  is a much bigger desideratum than winning the secret
> race (I presume there is some kind of secret race going on, since
> otherwise the crazy scheduling makes No Sense At All).  I can't
> work out what the strategy for winning is, if there is a
> strategy, but I do know that it's not working.   Linux has all
> but won already, and that's sickening.

Ports are maintained by volunteers. If you would like to volunteer to
support branches for longer periods of time, let's talk about that.

> I've been using the o/s since before v2 (I still have the cds)
> and have watched FreeBSD go from being the leading Unix on Intel
> boxes to all-but-dead.  I don't know how to express how saddened
> I feel about that.

I think ports are really improving and the rate of improvement is going up.

Steve



signature.asc
Description: OpenPGP digital signature

Re: Firefox build broken

[Andriy Gapon]

On 09/02/2017 16:17, Dimitry Andric wrote:
> On 9 Feb 2017, at 14:03, Domagoj Stolfa  wrote:
>>
>> It would seem that the firefox build is broken on 12.0-CURRENT. I've been
>> getting the same error as seem on [1]. Has anyone else experienced this?
>>
>> [1] 
>> https://lists.freebsd.org/pipermail/freebsd-pkg-fallout/Week-of-Mon-20170206/408053.html
> 
> It's a problem in the DTRACE option.  See https://bugs.freebsd.org/216871 .
> 
> For now, if you don't need DTrace support, just turn it off.

Can this be done by default?  So, that the binary packages for "FreeBSD 12" can
be built.


-- 
Andriy Gapon
___
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: ports and dependency hell

[Steve Wills]

Hi Julian,

On 02/07/2017 13:03, Julian Elischer wrote:
> This is a serious post  on a serious issue that ports framework people
> seem unaware of.

To be honest, it's kind of a confusing post, at least to me.

> It' getting too easy to get into dependency hell here (I've spent the
> last week fighting this)
> 
> In  a production system we have to choose packages from different eras.
> 
> This is because on an average product different teams are responsible
> for different parts of the product, and they all have their own
> requirements. Not to mention the stuff that comes in from third party
> vendors which "must use version X of bar and Version Z of foo". This is
> something that is a fact of life in commercial vendors. Ports needs to
> support it, and fast because currently ports is a reason to switch to
> Linux. (ammunition for the Linux fanboys). We are only staying for the
> ZFS support but that reason will evaporate soon.
> 
> We may need node.js 6.95 and a particular version of an apache mod for
> example, and a specific version off npm, which all only appeared in the
> ports tree at different times, so either we completely ditch the ports
> tree all together and import buildroot2 , which allows every package to
> have its own revision (but is Linux centric), or we need to generate
> frankenports trees. My curent iteration has 359 different packages, so
> you an imagine the hilarity  if I need to slide 20 of those back or
> forth, all independently.
> 
> There doesn't seem to be any understanding of this fact from the ports
> framework, and it means one has to keep one's own ports tree in source
> control, as a branch off the FreeBSD one. (maybe I should look at pkgsrc)..

I found this all confusing and vague, but it sounds like what's
happening is you need older versions of some software for whatever
reason and to provide that you are pulling older versions of ports into
a newer ports tree. Is that right?

> the problem is that the internal APIs of ports are changing too much.

Sorry, what do you mean? Can you define "too much" change?

> If you are going to change the API, then you need to be able to declare
> the version separately, maybe in a version/distinfo file that can be
> pulled in separately at a different rev, rather than having it built
> into the main Makefile of each port. Maybe the Makefile specifies a
> revision range it can be used with, but that would make a huge
> improvement right there.

The idea of having ports/packages support a version range for
dependencies is an interesting one, but I'm not sure how that would work.

> You can not just slide one port up by 3 months, and another down by 3
> months to get the revs one needs because the damned Mk files have
> changed. If I coudl leave the bulk of the Makefile alone and just slide
> the 'distingo/rev' file, (or be able to select a rev from one htat gives
> many alternatives, that woudl be "wonderful".

You're better off finding the tree that has the right version of the
oldest thing you need to use and then updating the things that you need
updated.

> Please, ports framework people,  think about how this can be done, If I
> have to edit a file, the game is lost.
> 
> Can we please get some understanding from ports people that they are
> making things REALLY HARD on vendors and it really strengthens the hands
> of  the "ditch FreeBSD and go to Linux" crowd when I need to spend a
> whole week trying to integrate in a set of 5 new ports into the product.
> 
> The call "It just works under linux, select the versions you want of
> each package and type make" is often heard around the company. And
> management is not totally deaf.
> 
> If you want to see how its' done better (still not perfect), go build a
> busybox system. you can effectively select any version of any tool and
> they all communicate via the pkgconf mechanism and you get the result
> you want.(mostly). And the API is stable.

Sounds like you've got a lot of folks who are used to the "LTS" mindset
where they never have to update their software to work with newer
versions. But ports is a rolling release in the head branch and
quarterly for those branches, and that's how it is going to be unless
someone wants to volunteer to maintain branches for longer. The LTS
thing works because people are paid to back port fixes and you can get
those for free.

> On the pkg side of things we need the ability for pkg to say "yeah I
> know I'm looking for foo-1.2.3.txz as a perfect match, but I've been
> given some slack on the third digit and I can see a foo-1.2.1.txz, so
> I'll install that instead".

I'm not sure how you would do that in a general way that didn't add
extra work for package maintainers.

> Otherwise we just have to spend WAY too much time generating dozens of
> "matching sets" of packages , that must be kept around forever if just
> one machine shipped with that set, not to mention the fact that making
> the matching set is often a real task.

Packages should 

Re: updating ruby

[Steve Wills]

Hi,

On 02/09/2017 09:55, Herbert J. Skuhra wrote:
> 
> DEFAULT_VERSIONS+=ruby=2.3

Err, yeah, sorry, was too early for me... Thanks for the correction.

Steve




signature.asc
Description: OpenPGP digital signature

Re: updating ruby

[Herbert J. Skuhra]

Steve Wills skrev:
> 
> Hi,
> On 02/08/2017 11:20, Gerard Seibert wrote:
>> On or about 20170109, the default version of ruby was updated from 2.2
>> to 2.3. However, "pkg install" wants to install version 2.2 for ports
>> that require ruby. Is there a way to override this behavior?
>> 
> 
> The packages are built from the quarterly branch, where 2.2 is still
> default.
> 
> You could build your own packages from the head branch, or build from
> quarterly branch with RUBY_DEFAULT=2.3 in /etc/make.conf.

DEFAULT_VERSIONS+=ruby=2.3

--
Herbert
___
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 Port: gatling-0.13_1

[Ulrich Kalloch]

The gatling Webserver is updatet and its a importent Security fix.

Please upgarde ASAP

Thanks

sokrates


signature.asc
Description: OpenPGP digital signature

Re: Firefox build broken

[Dimitry Andric]

On 9 Feb 2017, at 14:03, Domagoj Stolfa  wrote:
> 
> It would seem that the firefox build is broken on 12.0-CURRENT. I've been
> getting the same error as seem on [1]. Has anyone else experienced this?
> 
> [1] 
> https://lists.freebsd.org/pipermail/freebsd-pkg-fallout/Week-of-Mon-20170206/408053.html

It's a problem in the DTRACE option.  See https://bugs.freebsd.org/216871 .

For now, if you don't need DTrace support, just turn it off.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: updating ruby

[Steve Wills]

Hi,

On 02/08/2017 11:20, Gerard Seibert wrote:
> On or about 20170109, the default version of ruby was updated from 2.2
> to 2.3. However, "pkg install" wants to install version 2.2 for ports
> that require ruby. Is there a way to override this behavior?
> 

The packages are built from the quarterly branch, where 2.2 is still
default.

You could build your own packages from the head branch, or build from
quarterly branch with RUBY_DEFAULT=2.3 in /etc/make.conf.

Steve



signature.asc
Description: OpenPGP digital signature

Firefox build broken

[Domagoj Stolfa]

Hello,

It would seem that the firefox build is broken on 12.0-CURRENT. I've been
getting the same error as seem on [1]. Has anyone else experienced this?

[1] 
https://lists.freebsd.org/pipermail/freebsd-pkg-fallout/Week-of-Mon-20170206/408053.html

--
Best regards,
Domagoj Stolfa


signature.asc
Description: PGP signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 10:03 AM, Kirill Ponomarev  wrote:
> 
> On 02/09, Franco Fichtner wrote:
>> 
>>> On 9 Feb 2017, at 9:49 AM, Kirill Ponomarev  wrote:
>>> 
>>> I don't understand all critics I see in this thread and in your mail,
>>> the fate of this project is all in your hands - try to contribute more,
>> 
>> I'm going to stop you right there.
>> 
>> That's not entirely true.  Too few committers, substantial lack of
>> maintainer feedback, apparently no mentors to pick up newcomers, and
>> worst of all no newcomers.
>> 
>> Decide for yourself which of these are true and which are self-made
>> due to project management policies.
> 
> I think I've dejavu, as I've been reading these statements since 15
> years, and they've the same meaning and context, with the same
> argumentations and facts.  The truth is - the dogs bark, but the
> caravan moves on.

The lack of an open reply is exactly what I was arguing for, so I'm not
sure how much this stance helps your case.  ;)


Cheers,
Franco
___
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: Nim Port Update Needs Committer

[Kirill Ponomarev]

On 02/09, Neal Nelson wrote:
> Hi al.
> 
> Sorry to hassle the committers, but I filed bug #215941, an update to
> the lang/nim port to the latest version a month ago and it has just
> languished in the bugs database ever since. If someone could look at
> committing it I would be very grateful.
> 
> There's also bug #215304 for a new port for the Nimble package manager
> for the Nim language, which I think that all Nim users would find
> useful. This has been languishing for a couple of months now, but is
> very simple, so if someone could commit it, I would be very grateful.

Sorry for delay, I'll try to take care of both reports.

K.


signature.asc
Description: PGP signature

Nim Port Update Needs Committer

[Neal Nelson]

Hi al.

Sorry to hassle the committers, but I filed bug #215941, an update to
the lang/nim port to the latest version a month ago and it has just
languished in the bugs database ever since. If someone could look at
committing it I would be very grateful.

There's also bug #215304 for a new port for the Nimble package manager
for the Nim language, which I think that all Nim users would find
useful. This has been languishing for a couple of months now, but is
very simple, so if someone could commit it, I would be very grateful.

Regards,

Neal.

___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Kirill Ponomarev]

On 02/09, Franco Fichtner wrote:
> 
> > On 9 Feb 2017, at 9:49 AM, Kirill Ponomarev  wrote:
> > 
> > I don't understand all critics I see in this thread and in your mail,
> > the fate of this project is all in your hands - try to contribute more,
> 
> I'm going to stop you right there.
> 
> That's not entirely true.  Too few committers, substantial lack of
> maintainer feedback, apparently no mentors to pick up newcomers, and
> worst of all no newcomers.
> 
> Decide for yourself which of these are true and which are self-made
> due to project management policies.

I think I've dejavu, as I've been reading these statements since 15
years, and they've the same meaning and context, with the same
argumentations and facts.  The truth is - the dogs bark, but the
caravan moves on.

K.


signature.asc
Description: PGP signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Franco Fichtner]

> On 9 Feb 2017, at 9:49 AM, Kirill Ponomarev  wrote:
> 
> I don't understand all critics I see in this thread and in your mail,
> the fate of this project is all in your hands - try to contribute more,

I'm going to stop you right there.

That's not entirely true.  Too few committers, substantial lack of
maintainer feedback, apparently no mentors to pick up newcomers, and
worst of all no newcomers.

Decide for yourself which of these are true and which are self-made
due to project management policies.


Cheers,
Franco
___
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: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Kirill Ponomarev]

On 02/08, list-freebsd-po...@jyborn.se wrote:
> On Wed, Feb 08, 2017 at 12:34:36PM -0500, scratch65...@att.net wrote:
> > For those people (I'm one) long version lifespans and bug-free
> > operation  is a much bigger desideratum than winning the secret
> > race (I presume there is some kind of secret race going on, since
> > otherwise the crazy scheduling makes No Sense At All).  I can't
> > work out what the strategy for winning is, if there is a
> > strategy, but I do know that it's not working.   Linux has all
> > but won already, and that's sickening.
> > 
> > I've been using the o/s since before v2 (I still have the cds)
> > and have watched FreeBSD go from being the leading Unix on Intel
> > boxes to all-but-dead.  I don't know how to express how saddened
> > I feel about that.
> 
> My feelings exactly. I've been a FreeBSD user and strong advocater
> since around FreeBSD v1/v2. But the last few years the management
> of FreeBSD has steered away from making the best server OS, and
> instead focusing on ... what exactly?

Your statement is based on what?

> Making the ports system capable of handling a totally overwhelming
> number of more or less meaningless ports of different versions and
> flavours, and rolling/retiring the base releases at high speed just
> to avoid drowning under the workload of keeping all those ports
> functional?
> 
> Who needs/wants this evolution in a server OS?
> (Linux already owns the desktop, let's not waste any time
> discussing that regrettable fact.)
> 
> I'm sorry, and apologies to all great heroes doing all the
> volunteer work on both FreeBSD base and the ports system,
> but this is how I feel about what is going on with FreeBSD.
> 
> As I have never contributed to FreeBSD in any way, other than
> promoting it to others, I don't have a say in the matter, nor
> do I expect anyone to care about my view. But I'm just really,
> really sad to follow what in my opinion is the slow demise of
> FreeBSD.
> 
> Sorry about all the negativism.

I don't understand all critics I see in this thread and in your mail,
the fate of this project is all in your hands - try to contribute more,
collaborate with developers more, give your ideas and proposals, think
about its future and try to improve it, particiapte in FreeBSD
conferences and workshops, read code and code.

Rephrasing famous quote - if you judge something, you have no time to
love it.

K.


signature.asc
Description: PGP signature

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
audio/libebur128| 1.2.0   | v1.2.2
+-+
textproc/py-cloud_sptheme   | 1.8.0   | 1.8.3
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

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"