qupzilla, etc. bus error at FreeBSD-current (was: Re: please fix the pkg downloads system)

[Boris Samorodov]

08.02.2017 20:20, Jeffrey Bouquet via freebsd-ports пишет:


qupzilla-qt4 bus error


As for this particular error. I have seen those at FreeBSD-12
with qupzilla, otter browser, diligent and some other applications.
All of them are regularly updated from the official repository.

And only if I 'pkg remove' openssl package all applications
work fine (guess with base openssl?).

HTH
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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!?!

[list-freebsd-ports]

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?

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.

Peter
___
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: Seamonkey update

[Jeffrey Bouquet]

On Sun, 5 Feb 2017 20:05:51 -0500, roberth...@rcn.com wrote:

> 
> Jeffrey Bouquet writes:
> 
> >  pkg today updated seamonkey, now it segfaults, 
> >  every which way I try to run it.
> 
>   I am running SeaMonkey 2.46_5 (compiled today) under:
>   
>   FreeBSD 11.0-RC2 #0 r304729: Wed Aug 24 06:59:03 UTC 2016 amd64
> 
>   .
>   So far, indistinguishable from _4.
> 
> 
> 
>   Respectfully,
> 
> 
>   Robert Huff


About to reinstall the 2004-2017 disk, when a forum tar -C of base.txz etc
fixed the pkg v11 > v12 issue, which caused _4 to reinstall from pkg.
Built from ports. _5 on i386 segfaults.  
GENERIC was missing axe0 and ums0 in my kernel which I reverted (the kernel)
.
So aside from a wholesale from-backup of configuration files (the MANIFEST
in /usr/lib/freebsd-dist did not contain the 'motd' etc which it overwrote with
new, unfortunately... two concerns remain.
.
Building from ports again works, seamonkey _5 segfaults. I restored _4 from 
pkg. (v12)
pf is nowhere to be found.  Even if in the directory where I kldload pf.ko, I 
receive
a 'no such file' message from kldload.  
As it was not my primary firewall, it is not a huge problem, but I would like to
know if something has changed in CURRENT.  

As another aside, I could maybe 'jail' _4 seamonkey for a number of years so
that it is effecively 'pkg lock seamonkey' without chance for error.  But maybe
that is a pipe dream...

Apologies to the lists for recent messages needed newbie help which I got 
elsewhere
but may still have questions unanswered, besides the one above and
the seamonkey i386 _4 _5 breakage I assume to happen someday.

Thanks for reading.  Very relieved at the moment.

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"

misc/e2fsprogs-libuuid Issue

[The Doctor]

===>>> Launching child to install misc/e2fsprogs-libuuid

===>>> All >> misc/e2fsprogs-libuuid (1/5)

===>>> Currently installed version: e2fsprogs-libuuid-1.43.3_1
===>>> Port directory: /usr/ports/misc/e2fsprogs-libuuid

===>>> Starting check for build dependencies
===>>> Gathering dependency list for misc/e2fsprogs-libuuid from ports
===>>> Dependency check complete for misc/e2fsprogs-libuuid

===>>> All >> e2fsprogs-libuuid-1.43.3_1 (1/5)

===>  Cleaning for e2fsprogs-libuuid-1.43.4
===>  License GPLv2 accepted by the user
===>   e2fsprogs-libuuid-1.43.4 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by e2fsprogs-libuuid-1.43.4 for building
===>  Extracting for e2fsprogs-libuuid-1.43.4
=> SHA256 Checksum OK for e2fsprogs-1.43.4.tar.xz.
===>  Patching for e2fsprogs-libuuid-1.43.4
===>  Applying FreeBSD patches for e2fsprogs-libuuid-1.43.4
/usr/bin/sed -i.bak -e 's,/var/lib/libuuid,/var/run/libuuid,g'  -e 
's,/usr/sbin/uuidd,/usr/local/sbin/uuidd,'  
/usr/ports/misc/e2fsprogs-libuuid/work/e2fsprogs-1.43.4/lib/uuid/*.[ch]
===>   e2fsprogs-libuuid-1.43.4 depends on executable: gmake - found
===>   e2fsprogs-libuuid-1.43.4 depends on package: pkgconf>=0.9.10 - found
===>  Configuring for e2fsprogs-libuuid-1.43.4
configure: loading site script /usr/ports/Templates/config.site
Generating configuration file for e2fsprogs version 1.43.4
Release date is January, 2017
checking build system type... amd64-portbld-freebsd11.0
checking host system type... amd64-portbld-freebsd11.0
checking for gcc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking for dlopen in -ldl... no
checking for gcc... (cached) cc
checking whether we are using the GNU C compiler... (cached) yes
checking whether cc accepts -g... (cached) yes
checking for cc option to accept ISO C89... (cached) none needed
checking how to run the C preprocessor... cpp
checking for additional special compiler flags... (none)
checking for grep that handles long lines and -e... (cached) /usr/bin/grep
checking for egrep... (cached) /usr/bin/egrep
checking for ANSI C header files... (cached) yes
checking for sys/types.h... (cached) yes
checking for sys/stat.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for memory.h... (cached) yes
checking for strings.h... (cached) yes
checking for inttypes.h... (cached) yes
checking for stdint.h... (cached) yes
checking for unistd.h... (cached) yes
checking for minix/config.h... (cached) no
checking whether it is safe to define __EXTENSIONS__... yes
Disabling maintainer mode by default
Disabling symlinks for install by default
Disabling relative symlinks for install by default
Disabling symlinks for build by default
Disabling verbose make commands
Enabling ELF shared libraries
Disabling BSD shared libraries by default
Disabling profiling libraries by default
Disabling journal debugging by default
Disabling blkid debugging by default
Enabling testio debugging by default
checking pkg-config is at least version 0.9.0... yes
checking for uuid_generate in -luuid... yes
Using system uuid by default
checking pkg-config is at least version 0.9.0... yes
checking for blkid_get_cache in -lblkid... no
Enabling private blkid library by default
Enabling use of backtrace by default
Enabling debugfs support by default
Enabling e2image support by default
Enabling e2resize support by default
Enabling e4defrag support by default
Not building fsck wrapper
Not building e2initrd helper
Try using thread local support by default
checking for thread local storage (TLS) class... __thread
Disabling uuidd by default
Enabling mmp support by default
Enabling mmp support by default
Enabling bitmap statistics support by default
Disabling additional bitmap statistics by default
checking whether gmake sets $(MAKE)... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p
checking for a sed that does not truncate output... (cached) /usr/bin/sed
checking whether NLS is requested... no
checking for msgfmt... /usr/local/bin/msgfmt
checking for gmsgfmt... /usr/local/bin/msgfmt
checking for xgettext... /usr/local/bin/xgettext
checking for msgmerge... /usr/local/bin/msgmerge
checking whether we are using the GNU C Library 2 or newer... no
checking for ranlib... ranlib
checking whether the -Werror option is usable... yes
checking for simple visibility declarations... yes
checking for inline... inline
checking for size_t... (cached) yes
checking for stdint.h... (cached) yes
checking for working alloca.h... no
checking for alloca... yes
checking for stdlib.h... (cached) yes

Re: ports and dependency hell

[Grzegorz Junka]

On 08/02/2017 08:03, Julian Elischer wrote:

On 8/2/17 3:17 am, Grzegorz Junka wrote:


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

(...)

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.




Hi Julian,
I may not fully understand how it works but what prevents you from 
getting sources for the version you want and typing make in them, 
exactly the way you do it in Linux? It should pick up the versions of 
dependencies currently installed in the system and compile for them. 
Is it only when you want to use the ports infrastructure that poses a 
problem?


Nothing stops me from doing that. It's just that means that the ports 
infrastructure is useless and a complete waste of time right?

I'm no ready to admit that, however I may just be in denial.

also, downsides to doing that include:

* not getting any FreeBSD related fixes (many packages don't work well 
on FreeBSD without patches)

* not being able to play nice with software installed by packages
* having a hard time installing FreeBSD specific software that is 
delivered by ports and pkg as it's primary means of delivery.
* having to manually chase package revisions. In areas where I have no 
expertise.




Re 1, I believe you can still apply FreeBSD related patches after you 
have unpacked sources and before compiling them?


Is 2 and 4 from your list somehow easier on Linux than on FreeBSD?

As for 3, why would you need to compile them from sources, can't you 
just install them either from the official or a custom poudriere repository?


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

Re: please fix the pkg downloads system

[Jeffrey Bouquet via freebsd-ports]

On 02/ 8/17 08:06 AM, Julian Elischer wrote:
please work on having the "Latest" image in a directory that has the 
cvs revision number in its name


and make the current names just be links to there.

I ONCE AGAIN (for the third time) got half of one release (432891) and 
half of another (433120) because the newest snapshot of the pkgs was 
replaced half way through my process of downloading a large set of 
packages.  Then a couple of days later I managed to get all the files 
of 433274, but by the time I got to downloading the metadata it was 
changed to the next snapshot (433341), making my mirror pointless. 
(unless there is a script I can run to regenerate the metadata from 
the actual files. (I'm guessing there is).


Please consider keeping two copies, at any time. this measn that 
someonewho starts copying the latest set has at least a couple of days 
to get it.


So FreeBSD http://pkg.freebsd.org/FreeBSD:10:amd64/latest/ would be a 
link to the latest but someone who followed the link 20 minutes 
earlier and was copying files would keep getting a consistent set.


the actual backing set would be called

something like:

FreeBSD-pkg/head/r433274/FreeBSD:10:amd64/All

and the next would be:

FreeBSD-pkg/head/r433341/FreeBSD:10:amd64/All

then

FreeBSD-pkg/head/r433529/FreeBSD:10:amd64/All

etc. (real snapshot numbers)

but
http://pkg.freebsd.org/FreeBSD:10:amd64/latest/ would always point to 
the latest one.


this would ensure that I don't keep getting HALF A RELEASE!

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

and include a /usr/src/USING_PKG to put methodologies,
how to get sets for supported versions,
for CURRENT if available,
migration methods,
reinstall methods,
across-version upgrade CLI,
formats for each of the three files (three or more)
FreeBSD.conf and pkg.conf,
their precedence,
cli for sqlite3> fixing or altering of metadata,
etc etc
...
I've a v12-CURRENT and a v11-CURRENT, the former suddenly has
between feb 04 feb 06 all except ONE of its browsers
unuseable

qupzilla "cant load freebsd.org"... etc for ALL tested url
seamonkey segfault
firefox   cannot accept 2 as input Anywhere
qupzilla-qt4 bus error

vs opera, which TLS - hardened cannot see freebsd.org
..
and am in the process of for the first time since 2004
having to *maybe* reinstall or redo /usr/local,  due to pkg not being able
to have a v12 repository and/or a hosed set of libraries
for seamonkey

and it means about a months of downtime, relative to how efficiently
I used the desktop previously...

Not wishing to come across as complaining.  Newbie still in many ways.
___
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!?!

[scratch65535]

On Wed, 8 Feb 2017 14:43:25 +, Matthew Seaman
 wrote:

>On 02/08/17 11:56, scratch65...@att.net wrote:
>> So, what's the deal here?  To "encourage" people to upgrade, pkg
>> will break their existing install?  That is both hostile and
>> deeply arrogant!
>
>mat's response is more exasperation than anything else.  This is a well
>known problem for which there have been /numerous/ bug reports.  You're
>meant to check that there isn't already a relevant bug report when
>creating a PR in bugzilla.

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.

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.  

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.
___
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: please fix the pkg downloads system

[Russell L. Carter]

On 02/08/17 09:06, Julian Elischer wrote:

please work on having the "Latest" image in a directory that has the cvs
revision number in its name

and make the current names just be links to there.

I ONCE AGAIN (for the third time) got half of one release (432891) and
half of another (433120) because the newest snapshot of the pkgs was
replaced half way through my process of downloading a large set of
packages.  Then a couple of days later I managed to get all the files of
433274, but by the time I got to downloading the metadata it was changed
to the next snapshot (433341), making my mirror pointless. (unless there
is a script I can run to regenerate the metadata from the actual files.
(I'm guessing there is).


I must be missing something.  For that I am sorry.  But...  if I was
confronted with this problem I would just say f*ck it, I'll use
poudriere.  I think you've mentioned you've got a package set of
something less than 400 packages.  I use an 8 core AMD cpu + a big ssd
+ 32G of memory (~$500) to maintain nightly updates of an ~1300
package set.  It's efficient enough that I can usually drop a new port
into my ports file and run a bulk build that completes anywhere from a
couple of minutes to less than an hour.  (Though sometimes that
stretches out to 6 hrs or more) With not very much capital in disk you
could maintain as many sets of packages as you cared, with varying svn
revisions, local options, local branches, etc.  I know if my job
depended on "reproducible" package sets that would be the only
technique I trusted.

Best,
Russell


Please consider keeping two copies, at any time. this measn that
someonewho starts copying the latest set has at least a couple of days
to get it.

So FreeBSD http://pkg.freebsd.org/FreeBSD:10:amd64/latest/ would be a
link to the latest but someone who followed the link 20 minutes earlier
and was copying files would keep getting a consistent set.

the actual backing set would be called

something like:

FreeBSD-pkg/head/r433274/FreeBSD:10:amd64/All

and the next would be:

FreeBSD-pkg/head/r433341/FreeBSD:10:amd64/All

then

FreeBSD-pkg/head/r433529/FreeBSD:10:amd64/All

etc. (real snapshot numbers)

but
http://pkg.freebsd.org/FreeBSD:10:amd64/latest/ would always point to
the latest one.

this would ensure that I don't keep getting HALF A RELEASE!

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


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

updating ruby

[Gerard Seibert]

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?

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

please fix the pkg downloads system

[Julian Elischer]

please work on having the "Latest" image in a directory that has the 
cvs revision number in its name


and make the current names just be links to there.

I ONCE AGAIN (for the third time) got half of one release (432891) and 
half of another (433120) because the newest snapshot of the pkgs was 
replaced half way through my process of downloading a large set of 
packages.  Then a couple of days later I managed to get all the files 
of 433274, but by the time I got to downloading the metadata it was 
changed to the next snapshot (433341), making my mirror pointless. 
(unless there is a script I can run to regenerate the metadata from 
the actual files. (I'm guessing there is).


Please consider keeping two copies, at any time. this measn that 
someonewho starts copying the latest set has at least a couple of days 
to get it.


So FreeBSD http://pkg.freebsd.org/FreeBSD:10:amd64/latest/ would be a 
link to the latest but someone who followed the link 20 minutes 
earlier and was copying files would keep getting a consistent set.


the actual backing set would be called

something like:

FreeBSD-pkg/head/r433274/FreeBSD:10:amd64/All

and the next would be:

FreeBSD-pkg/head/r433341/FreeBSD:10:amd64/All

then

FreeBSD-pkg/head/r433529/FreeBSD:10:amd64/All

etc. (real snapshot numbers)

but
http://pkg.freebsd.org/FreeBSD:10:amd64/latest/ would always point to 
the latest one.


this would ensure that I don't keep getting HALF A RELEASE!

___
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 02/08/17 11:56, scratch65...@att.net wrote:
> So, what's the deal here?  To "encourage" people to upgrade, pkg
> will break their existing install?  That is both hostile and
> deeply arrogant!

mat's response is more exasperation than anything else.  This is a well
known problem for which there have been /numerous/ bug reports.  You're
meant to check that there isn't already a relevant bug report when
creating a PR in bugzilla.

Anyhow:

Your installation is *not* broken.  If you build net-mgmt/pkg (yes, the
latest one) from sources using the ports, you will find it works
perfectly well.

Or you can simply use pkg-static

However, there is no guarantee that

  a) some other package will not suffer from the same utimensat problem
 (so be very wary of using the pre-compiled FreeBSD packages)

  b) or that the package you want will compile properly on 10.2-RELEASE
 (most will, but a number of packages will fall foul of compiler
  problems and the like which have been solved in 10.3-RELEASE.)

Yes, pkg(8) should issue prominent warnings when used on a system that
is out of support.  However, your best recourse is to update your
system, and then all of this grief will cease to bother you.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: ports and dependency hell

[RW via freebsd-ports]

On Wed, 8 Feb 2017 16:03:56 +0800
Julian Elischer wrote:

> On 8/2/17 3:17 am, Grzegorz Junka wrote:
> >
> > On 07/02/2017 18:03, Julian Elischer wrote:  
> >> This is a serious post  on a serious issue that ports framework 
> >> people seem unaware of.
> >> (...)
> >>
> >> 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.
> >>  
> >
> > Hi Julian,
> > I may not fully understand how it works but what prevents you from 
> > getting sources for the version you want and typing make in them, 
> > exactly the way you do it in Linux? It should pick up the versions 
> > of dependencies currently installed in the system and compile for 
> > them. Is it only when you want to use the ports infrastructure that 
> > poses a problem?  
> 
> Nothing stops me from doing that. It's just that means that the ports 
> infrastructure is useless and a complete waste of time right?
> I'm no ready to admit that, however I may just be in denial.


It wasn't entirely clear what you were comparing FreeBSD ports with,
is it specifically buildroot2?

___
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

[George Mitchell]

On 02/08/17 03:03, Julian Elischer wrote:
> [...]
> I'm discouraged to not hear back from any of the ports 'committee'.
> [...]
Possibly because this has been the topic of a number of rancorous
mail threads in the last few months already, and everybody is
fatigued.  What there *hasn't* been is a consensus on what to do
about it.  And with all respect perhaps that's inevitable in a
vibrant and active open-source project run entirely by volunteers.
I wish I could omnisciently propound the right thing to do(tm)
so persuasively that everybody would immediately set to work on
it.  But I can't, even in my own overactive imagination.   -- George




signature.asc
Description: OpenPGP digital signature

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

[scratch65535]

[Default] On Wed, 8 Feb 2017 12:46:09 +0100, Franco Fichtner
 wrote:

>
>> On 8 Feb 2017, at 12:29 PM,   
>> wrote:
>> 
>> I just tried to install the fuse-nfts pkg under 10.2 on my
>> server-of-all-work.  But after requiring me to "upgrade" pkg, the
>> fuse-ntfs install failed, apparently because there's an undefined
>> symbol ("utimenstat") in pkg itself!
>> 
>> How do I extricate myself?
>
>The latest supported release is FreeBSD 10.3 and packages are therefore
>build against it.  It creates this soft breakage inside the fixed ABI,
>which quite a few people run into.
>
>There are two solutions:
>
>(a) Build the packages yourself on a FreeBSD 10.2.
>
>(b) Upgrade to FreeBSD 10.3 and do a "pkg upgrade -f" run.

Perhaps it's just that I've spent too much of my life doing
human-factors work, but if pkg doesn't want to do anything for me
once my version has passed its use-by date, it damned well
shouldn't do ANYTHING.  It should just tell me "nope, 10.2 is too
old, entirely too oll.  No packages for you!"  

The one thing it should NEVER do is break its existing install!  

I agree with your urging, Franco, that the problem be solved in a
general and non-hostile way.

Now, how do I revert the pkg version? :-(
___
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!?!

[scratch65535]

My bug report just got closed by Mathieu Arnold because "You are
using an obsolete FreeBSD version, you need to update to 10.3."

So, what's the deal here?  To "encourage" people to upgrade, pkg
will break their existing install?  That is both hostile and
deeply arrogant!

I don't want to upgrade because (a) I'm perfectly happy with 10.2
and (b) I've never been able to upgrade in place.  Every attempt
has ended in my having scour everything down to the metal and
reinstall.  I'm not willing to waste days doing that for no good
reason.
___
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 8 Feb 2017, at 12:29 PM,   
> wrote:
> 
> I just tried to install the fuse-nfts pkg under 10.2 on my
> server-of-all-work.  But after requiring me to "upgrade" pkg, the
> fuse-ntfs install failed, apparently because there's an undefined
> symbol ("utimenstat") in pkg itself!
> 
> How do I extricate myself?

The latest supported release is FreeBSD 10.3 and packages are therefore
build against it.  It creates this soft breakage inside the fixed ABI,
which quite a few people run into.

There are two solutions:

(a) Build the packages yourself on a FreeBSD 10.2.

(b) Upgrade to FreeBSD 10.3 and do a "pkg upgrade -f" run.

And for the wicked:

(c) Let's please address this issue within FreeBSD so users don't run into 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"

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

[scratch65535]

I just tried to install the fuse-nfts pkg under 10.2 on my
server-of-all-work.  But after requiring me to "upgrade" pkg, the
fuse-ntfs install failed, apparently because there's an undefined
symbol ("utimenstat") in pkg itself!

How do I extricate myself?
___
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

[Kurt Jaeger]

Hi!

> I'm discouraged to not hear back from any of the ports 'committee'.

I'm not from the committee 8-), but I think you raise relevant points.
It is not easy to cover them.

All of the pkg-developers have their tables full of work, so ...

Crafting a well-reflected answer takes time.

-- 
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: (Relevant?) article on package mgmt at lwn.net

[Julian Elischer]

On 5/2/17 7:18 pm, Kurt Jaeger wrote:

Hi!

There's an article on package mgmt, also referencing the
topic of language-specific package mgmt, at lwn.net:

Package managers all the way down
https://lwn.net/Articles/712318/


very relevant


FreeBSD ports/pkg issues are taking close to 50% of my time these days,

and we are just using 400 or so packages.


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

FreeBSD ports 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
+-+
graphics/opencollada| 1.6.37  | v1.6.38
+-+
math/giacxcas   | 1.2.2-57| 1.2.3-25
+-+
science/gromacs | 5.0.6   | 2016.2
+-+


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"

Re: ports and dependency hell

[Julian Elischer]

On 8/2/17 3:17 am, Grzegorz Junka wrote:


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

(...)

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.




Hi Julian,
I may not fully understand how it works but what prevents you from 
getting sources for the version you want and typing make in them, 
exactly the way you do it in Linux? It should pick up the versions 
of dependencies currently installed in the system and compile for 
them. Is it only when you want to use the ports infrastructure that 
poses a problem?


Nothing stops me from doing that. It's just that means that the ports 
infrastructure is useless and a complete waste of time right?

I'm no ready to admit that, however I may just be in denial.

also, downsides to doing that include:

* not getting any FreeBSD related fixes (many packages don't work well 
on FreeBSD without patches)

* not being able to play nice with software installed by packages
* having a hard time installing FreeBSD specific software that is 
delivered by ports and pkg as it's primary means of delivery.
* having to manually chase package revisions. In areas where I have no 
expertise.


upsides include the ability to use autotools etc as they are designed 
to be used and pkgconf to knit everything together without worring 
about version problems. (downside is using autotools :-)  )


So there is a price to pay each way..

I'm discouraged to not hear back from any of the ports 'committee'.





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




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