gitip usage.

[Jeffrey Bouquet via freebsd-ports]

running 12.2 STABLE, I would like a complete DEFAULTS and PORTS 
example for gitup.conf.

forums and this list provide changes [ tersely  or sed templating tersely, ] ,  
but no latest
indication in its entirety of which invocation would work that I've been able 
to make
update the ports past april 1 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: freebsd-ports Digest, Vol 882, Issue 2

[Jeffrey Bouquet via freebsd-ports]

 [ top posting cause the browser mandates it sorry ]
I read something suggesting that 
knowledge of pypy may help persons port py27 apps to py37? if
the maintainer knows about the app

or convert it from py27 to pypy? pending py38 rewrite? 
 On Tuesday, April 21, 2020, 12:00:59 PM GMT, 
 wrote:  
 
 Send freebsd-ports mailing list submissions to
    freebsd-ports@freebsd.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.freebsd.org/mailman/listinfo/freebsd-ports
or, via email, send a message with subject or body 'help' to
    freebsd-ports-requ...@freebsd.org

You can reach the person managing the list at
    freebsd-ports-ow...@freebsd.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-ports digest..."


Today's Topics:

  1. Re: python 2.7 marked as deprecated and EOL while 2.7.18 RC
      is available (Thierry Thomas)


--

Message: 1
Date: Mon, 20 Apr 2020 16:28:04 +0200
From: Thierry Thomas 
To: freebsd-ports@freebsd.org,    Christoph Moench-Tegeder
    
Cc: Yuri 
Subject: Re: python 2.7 marked as deprecated and EOL while 2.7.18 RC
    is available
Message-ID: <20200420142804.gy50...@graf.pompo.net>
Content-Type: text/plain; charset="iso-8859-1"

Le dim. 19 avr. 20 ? 11:24:30 +0200, Thierry Thomas 
 ?crivait?:

> > Hmpf - now I _had_ to fix FreeCAD - that thing has it's own dependency
> > on vtk, and we cannot have vtk6 and vtk8 at the same time.
> 
> Thanks, I did not know that.

Christoph,

Unfortunately, I had to switch back to VTK-6.1 because it broke the
build. Thus you have to switch back too for FreeCAD...
-- 
Th. Thomas.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: not available
URL: 


--

Subject: Digest Footer

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


--

End of freebsd-ports Digest, Vol 882, Issue 2
*
  
___
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"

zsh 5.6

[Jeffrey Bouquet via freebsd-ports]

building 5.6 or 5.6.1 results in three errors here.

Most critical is 'bindkey: not found" rendering the terminal near useless.
I restored most functionality putting /usr/local/lib/zsh/5.5.1 files back
where 5.6 can find them but no luck with 5.6.1 either 
___
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: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?

[Jeffrey Bouquet]

On Tue, 3 Oct 2017 10:51:24 +0200, "O. Hartmann"  wrote:

> When using "poudriere", it seems ABI is freebsd:12:x86:64. When using FreeBSD 
> base, it
> seems always to be referred to FreeBSD:12:amd64. What now? All non-BSD world 
> uses x86:64,
> FreeBSD is using amd64, but why is this used inconsistently all over the 
> places?
> 
> I run into trouble setting up some package- and base-servers and ran into the 
> problem
> when deleting - not thinking of this discovered inconsistency - some links on 
> the servers
> regarding FreeBSD:12:x86:64 (the same is for 11-STABLE).
> 
> Can someone shed some light onto this? 
> 
> What am I supposed to use now? The handbook referes to amd64, so I thought 
> poudriere
> would, too. 
> 
> Thanks in advance,
> 
> oh
> -- 
> O. Hartmann
> 
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


[ not using poudriere yet ]
/me too
I think three places [ etc/pkg, /usr/local/etc/pkg/repos, 2nd place in base, ]
  fourth:  hard coded DESPITE the above in the current DB in var/db/pkg?
  fifth: derived somehow from uname -a?

here: freebsd:12:x86:32
... when this issue resolved, could it please be added to 'man 
pkg|poudriere|syntch|portmaster?|portupgrade?  [ the latter two when developed 
further ]'
___
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"

pkg install problem(s)

[Jeffrey Bouquet via freebsd-ports]

pkgdb -u
origins - not a string
(NilClass)
Cannot read the pkgdb!
.
That has just started happening.

pkg update
Shared object 'libarchive.so.7' not found, required by "pkg"
.
that has just started happening [ so using pkg-static...]
12.0-CURRENT r313487 Feb 13 2017  i386
...
On to the Subject:
 Which has plagued my principal method of twice weekly using pkg to
 upgrade going on 3? years now.
 For various reasons, I have to pkg install... only the majority of
 pkgs to be updated.
 For instance, not libxul as of now, cannot afford desktop breakage of
 seamonkey, for instance.
 nor ffmpeg, would prefer not to risk breakage of mplayer, for example 
So I begin typing the subset. pkg-static install p5-This p5-That...
consisting of 40 or so ports.
Upon the 30 typed in, Xorg freezers, reboot.
TEDIOUS.
a better solution,
pkg install works like 'make config' and
one checks off the ones to be updated.
Then, 'is this what you want?
presents
 a subset of the removed/new/upgrade/reinstall
lists, rather than all-or-none brute-force install of all.
.
Kindly prioritize that 'feature' into pkg...?

while I am presenting [re presenting ] q about pkg,
..
make build-depends-list
pkg-static: ignoring bad configuration entry in pkg.conf: "INDEX-12"
   ... it does not say why, what a preferred entry should be...
make: "/usr/ports/Mk/Uses/ncurses.mk: line 67: warning:
 /usr/local/sbin/pkg-static info -g -ql devel/ncurses | grep
 -m 1 "^`pkg query "%p" devel/ncurses` /lib/libncurses.so."" returned
non-zero status.

I am totally perplexed by the above...
.
At least I've workarounds for it all... Kudos to the developers etc.
...
___
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"

perl problem

[Jeffrey Bouquet via freebsd-ports]

  Attachment probably not sent to the list.
  
  CD /usr/ports/devel/p5-List-Regexp  [new june 20 ]
  make build
  ...
  Encode.c: loadable library and perl binaries are mismatched ( got handshake 
key 0x8900080, needed 
  0x7b00080
  *** Error code 1
  Stop.
  make: stopped in /usr/ports/devel/p5-List-Regexp
  
  I've installed perl from v11 pkg because v12-CURRENT has not been updated 
lately
  and binaries fail with 'fstat' or 'stat' errors 

  However, this workaround fails with the exact same Encode.c error when using
  any perl port of note, for instance namefix... 

  
  apologies for the edge-case not-updated-yet question.
  ...
___
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"

ERRATA: 12.0-CURRENT binaries 'stat' errors.

[Jeffrey Bouquet]

ne
/usr/local/bin/ne: Undefined symbol "stat"
ktrace -di ne
/usr/local/bin/ne: Undefined symbol "stat"

I may have posted in error an 'fstat' instead, unsure, to the ports list just 
yesterday or so.
A workaround is to use pkg.freebsd.org to attain compat11x binaries which run.
This is a showstopper here otherwise as some large ports, do not build on the
legacy desktop [ 2004 ] that has been updated numerous times, and for which
I do not wish to reinstall.

And, pkg gives conflicting messages, as pkg binaries are shown ABI v12 whereas 
if I
do build from ports, the ports are shown as v11 ABI. 
Also, ABI changed: 'freebsd:12:x86:32' > 'freebsd:12:*'   upgrades are 
requested making
  things so I have to lock many ports at v11 as the newer have the 'stat' or 
'fstat' error.

  So more than one issue, I think maybe three in tandem making 'which to tackle 
first'
even problematic.

  Any advices?  even a binary editor to examine the /ne for 'stat' code ? 

  Apologies for not being knowledgeable in many of the ways to code a solution 
or even
coding... 
___
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"

12.0-current 'fstat' problem [ workaround in place... ]

[Jeffrey Bouquet via freebsd-ports]

Many ports newly report 'fstat' and refuse to run, and as many don't build 
until I
get around to a buildworld cycle, the workaround is to run v11 pkg 
pkg install -f ...
 on this v12 system, then lock the new port from being re-from-package
or re-built 
..
 Otoh, some like sqlite3 do build, but also have to be locked so they don't
revert to packaging upstream, as in WHERE IS THE  FILE some file somwhere
makes locally built ports freebsd:..v11  ABI rather than the actual uname,
v12.0-CURRENT. 
.
  A... some one /usr/src/usr.bin or something,  or a /lib/ equivalent, that
can be reinstalled singly to omit the fstat error.
  B... another whole problem, why are ports v11 ABI when built on a
ABI machine of v12


  Hoping procedures for this type of breakage are documented in the future
both for these and for other similar problems, such as in a new file
/usr/src/PKG-UPDATING , and a companion /usr/ports/PKG-UPDATING
or some such file more ad-hoc readable without a browser, as in the
wiki... [ for instance the main browser here broke til I installed just within
a few days ago, the v11 gnutls txz ... pkg install -f ... and then locked gnutls
IIRC. ] 
..
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Unable to update repository Synth

[Jeffrey Bouquet via freebsd-ports]

On Fri, 6/9/17, Jonathan Chen  wrote:

 Subject: Re: Unable to update repository Synth
 To: "Bob Willcox" 
 Cc: "ports list" 
 Date: Friday, June 9, 2017, 3:14 PM
 
 On 10 June 2017 at 05:02, Bob
 Willcox 
 wrote:
 > I am running the drm-next-4.7
 and when I ran synth recently on my system
 > up update the ports and at the end of the
 run received these errors:
 >
 > pkg: wrong architecture: freebsd:10:x86:64
 instead of FreeBSD:12:amd64
 > pkg:
 repository Synth contains packages with wrong ABI:
 freebsd:10:x86:64
 > Processing entries:
 100%
 > Unable to update repository
 Synth
 > Error updating repositories!
 > Unfortunately, the system upgrade
 failed.
 
 synth is
 complaining that one or more of the packages in the
 configuration's package directory has
 packages built for
 FreeBSD10/amd64 instead
 of FreeBSD12/amd64. If you have upgraded from
 FreeBSD 10 to FreeBSD 12, you must remove all
 the packages that have
 been built
 previously.
 
 Cheers.
 -- 
 Jonathan Chen 
 ___
 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"
 



pkg: Ignoring bad configuration entry in pkg.conf: "INDEX-12"
If I build from ports pkg thinks it is freebsd:11:x86:32 ... and will replace 
with freebsd:12:x86:32
 with an ABI changed.
however, it is 12.0-CURRENT.

  Any way to make it all consistent? 
..
/etc/pkg has ${ABI}
/usr/local/etc/pkg.conf has freebsd:12:x86:32
/usr/local/etc/.../FreeBSD.conf has ${ABI}
..
  and some script to parse all the files that are relevant and/or the
  --version from all pkg binaries to tell the user where the irrelevant or
   mismatched setting may be, could be coded? 

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

undefined symbol 'stat'

[Jeffrey Bouquet]

  The latest pkg updates broke firefox here, which won't build  [ patches fail 
to apply ]
  Also seamonkey, but building sqlite3 locally fixed that.
  
  [ not that I'd expect firefox to build anyway, not been that lucky 
recently... ] 

  Web search turns up no 'undefined symbol stat' on 12.0-CURRENT that I can 
find.

  Subject give the entirety of the error. 
  Building webkit-gtk2 locally as of now to try to fix it in a third round of 
ports. ... 
___
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: nvidia drivers mutex lock

[Jeffrey Bouquet via freebsd-ports]

I see the same message, upon load, ...

On Thu, 6/1/17, blubee blubeeme  wrote:

 Subject: nvidia drivers mutex lock
 To: freebsd-ports@freebsd.org, freebsd-curr...@freebsd.org
 Date: Thursday, June 1, 2017, 11:35 AM
 
 I'm running nvidia-drivers 375.66 with a GTX
 1070 on FreeBSD-Current
 
 This problem just started happening
 recently but, every so often my laptop
 screen will just blank out and then I
 have to power cycle to get the
 machine up and running again.
 
 It seems to be a problem with nvidia
 drivers acquiring duplicate lock. Any
 info on this?
 
 Jun  2 02:29:41 blubee kernel:
 acquiring duplicate lock of same type:
 "os.lock_mtx"
 Jun  2 02:29:41 blubee kernel: 1st
 os.lock_mtx @ nvidia_os.c:841
 Jun  2 02:29:41 blubee kernel: 2nd
 os.lock_mtx @ nvidia_os.c:841
 Jun  2 02:29:41 blubee kernel:
 stack backtrace:
 Jun  2 02:29:41 blubee kernel: #0
 0x80ab7770 at
 witness_debugger+0x70
 Jun  2 02:29:41 blubee kernel: #1
 0x80ab7663 at
 witness_checkorder+0xe23
 Jun  2 02:29:41 blubee kernel: #2
 0x80a35b93 at
 __mtx_lock_flags+0x93
 Jun  2 02:29:41 blubee kernel: #3
 0x82f4397b at
 os_acquire_spinlock+0x1b
 Jun  2 02:29:41 blubee kernel: #4
 0x82c48b15 at _nv012002rm+0x185
 Jun  2 02:29:41 blubee kernel:
 ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM:
 Argument #4 type mismatch - Found
 [Buffer], ACPI requires [Package]
 (20170303/nsarguments-205)
 Jun  2 02:29:42 blubee kernel:
 nvidia-modeset: Allocated GPU:0
 (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @
 PCI::01:00.0
 
 Best,
 Owen
 ___
 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"
 


... then Xorg will run happily twelve hours or so.  The lockups here happen 
usually
when too large or too many of number of tabs/ large web pages with complex CSS 
etc
are opened at a time.  
So no help, just a 'me too'.  
___
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: Firefox (and other Mozilla products) after ino64

[Jeffrey Bouquet]

On Wed, 31 May 2017 23:27:16 +0200, Dimitry Andric  wrote:

> Hi,
> 
> Due to the recent ino64 update in 12.0-CURRENT, there have been some
> reports by Firefox port users about crashes.  While I personally have
> not experienced these crashes, as I immediately rebuilt all my ports
> from scratch after the ino64 update, I think can explain why the
> following combination is very likely to have problems:
> 
> * kernel+world after ino64
> * www/firefox package from before ino64
> 
> It is because Firefox's JavaScript engine is doing tricks to get at libc
> structures and functions (via an FFI mechanism), and several structure
> layouts and offsets are hardcoded into its engine at build time.
> 
> For instance, here is the place where the engine determines the offset
> of struct dirent's d_name field:
> 
>   
> https://hg.mozilla.org/mozilla-central/file/tip/dom/system/OSFileConstants.cpp#l648
> 
> Further down in the file, several offsets of fields in struct stats are
> similarly determined:
> 
>   
> https://hg.mozilla.org/mozilla-central/file/tip/dom/system/OSFileConstants.cpp#l677
> 
> Now, since ino64 changed quite a number of structure layouts, including
> struct dirent, struct stat, and others, such offsets determined in the
> past will no longer be valid!
> 
> It is pretty likely that Firefox will attempt to access these fields,
> finding bogus values, or simply reading invalid memory, and crashing
> because of this.  Or at the least, the behavior will be unstable.
> 
> This also applies to other Mozilla products, such as Thunderbird,
> SeaMonkey, and so on.  These should all be rebuilt from scratch under
> ino64.
> 
> -Dimitry


What of machines where for some reason ports do not always build? [ for 
instance, 
ones with past workarounds for a
failed installworld...  ]  that still are in critical use daily? And,or where 
the
system has been installed for so long without reinstall that some ports 
segfault unless 'pkg lock'  ... and not usually upgraded... and/or thus using
binaries from backup... 

  Are upstream repositories to have those [ browser, email]  ports?  For 
instance, here iridium I cannot get to build... 
___
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: The future of portmaster

[Jeffrey Bouquet via freebsd-ports]

tl/dr at bottom, repeated here,   flowchart please


On Tue, 5/30/17, Adam Weinberger  wrote:

 Subject: Re: The future of portmaster
 To: me...@bris.ac.uk
 Cc: rollingb...@gmail.com, freebsd-ports@freebsd.org
 Date: Tuesday, May 30, 2017, 7:30 AM
 
 > On 30 May, 2017, at 8:15,
 Anton Shterenlikht 
 wrote:
 > 
 >> From
 ad...@adamw.org
 Tue May 30 15:03:31 2017
 >> 
 >> The ports tree continues to evolve.
 Major new features are planned and in the process of being
 implemented. These changes will break all the port-building
 tools.
 > 
 > oy vei
 > 
 >> poudriere and
 synth are actively developed, so they will quickly support
 the new changes. portmaster and portupgrade are no longer
 being actively developed, so it is anticipated that they
 will stop working until somebody fixes them (if at all).
 > 
 > I last used
 poudriere a couple years back.
 > It is
 much more involved than portmaster
 >
 (obviously, these 2 tools are not doing the same job)
 
 There's definitely more
 work up-front to set up poudriere. You get the effort back,
 though, in long-term viability and not having to chase
 problems up and down the ports tree.
 
 >> So no, portmaster isn't going
 away. But, there's no guarantee that it will keep
 working. We strongly, strongly advise everyone to use
 poudriere or synth to build their ports, and then plain old
 "pkg upgrade" to handle updates.
 > 
 > because my
 experience of poudriere was mixed,
 > I
 haven't used it at all on amd64.
 >
 pkg is great. And when occasionally I need
 > non-default options I use portmaster.
 > 
 >> 
 >> The vast majority of problems reported
 on this mailing list exist only in portmaster/portupgrade,
 because they do not do clean builds. At this point,
 portmaster should only be used by people with enough ports
 development experience to understand and mitigate conflicts
 and various build errors.
 > 
 > I agree that a dirty environement is
 mostly
 > the source of bad portmaster
 builds.
 > 
 > However,
 to create the whole poudriere enviroment
 > to build a port a week, or maybe a month,
 seems
 > like an overkill.
 > 
 > Yes, I know,
 it's a volunteer project, things
 >
 evolve, unless somebody steps in...
 > 
 > If my recollection of poudriere is
 correct,
 > I'll need a separate ports
 tree?
 > And if I only need to build a
 single port
 > with custom settings,
 I'll have to start
 > every time from
 scratch?
 > And if I want to use this
 single port with
 > default settings with
 my other ports, I need
 > to make sure the
 2 port trees are in sync.
 > 
 > Sorry if I don't do poudeire justice,
 it's been a while...
 
 You don't need separate port trees. The
 idea is to use poudriere to build ALL your ports. Just make
 a list of the ports you want, pass it to poudriere, and it
 will keep everything up-to-date, rebuild things when they
 need to be rebuilt, and give you a pkg repository so you can
 just run "pkg install foo" or "pkg
 upgrade" to keep your system running.
 
 Even if you do use poudriere
 to build only a few ports, it's pretty easy. Give your
 own generated packages a higher priority in
 /usr/local/etc/pkg/repos/ and you can transparently layer
 your pkg repo above the upstream repo.
 
 So no, you don't need separate ports trees.
 poudriere is happiest though when you let it manage its own
 ports tree, so I prefer to just symlink /usr/ports to it,
 but you can very easily use a pre-existing ports tree with
 poudriere.
 
 # 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"
 

Sorry for the yahoo webclient not quoting the above.
If applicable.
Leaving aside my wishes for the /usr/ports/MOVED/portmanager *also* eventually 
back
upto speed with portmaster, even as shareware, this poudriere and even synth I 
think
could benefit from a flowchart...  right side differing scenarios what one's 
goals are 
left and work backwards thru all the things can go wrong, dotted boxes 'errors' 
and
arrows to the solution(s) paths, [ and  a third part of this flowchart I just 
thought of
...] and on the left simple boxes, like one server one lan, two servers two lan,
one server a VPN three hundred downstream 'subscriber' clients for the built 
ports,
and any other things, more visually explained than a much longer wiki reading.

tl/dr  flowchart please
___
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"

Xorg error 'alphasort'

[Jeffrey Bouquet via freebsd-ports]

First try, did not build, to try to fix,  Xorg, took the easy way out and 
restored the
/usr/local/bin/Xorg that was working two days ago from backup.

Xorg.log.0 says it is devd???
...
error in Subject is only from memory.
...
Fixed, temporarily, in under 15 minutes here.  No time to investigate further, 
just wondering...
.
1.18.4,1 >> 1.18.4_1,1 
xorg-server
was done within the last 12 hours from pkg 12.0-CURRENT
ino64?  not upto speed... on that either. 

Not tested: 
xorg-vfbserver
xorg-nestserver
___
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: [RFC] rename nvidia-driver port binaries [ and other comments]

[Jeffrey Bouquet]

On Mon, 15 May 2017 23:53:10 +0900, Tomoaki AOKI <junch...@dec.sakura.ne.jp> 
wrote:

> Hi.
> If including its version to nvidia.ko and nvidia-modeset.ko,
> [hard / symbolic] link to it with current name should be needed
> not to bother admins every time upgrading.
> 
> BTW, I personally using below in rc.conf for safety.
> This only helps situations that...
> 
>  *Insufficient loader memory, but OK after kernel is started.
> 
>  *Accidentally backed to older version that doesn't have
>   nvidia-modeset.ko and only nvidia-modeset.ko is written in
>   /boot/loader.conf.
> 
> ## Temporary settings for nvidia-driver when failed loading via loader.conf
> kldstat -q -n nvidia.ko
> if [ 0 -ne $? ] ; then
>   echo "Loading nvidia-driver modules via rc.conf."
> #  kldload nvidia
>   if [ -e /boot/modules/nvidia-modeset.ko ] ; then
> #kldload nvidia-modeset
> kld_list="${kld_list} nvidia-modeset.ko"
>   else
> #kldload nvidia
> kld_list="${kld_list} nvidia.ko"
>   fi
> fi
> 
> 
> On Mon, 15 May 2017 06:41:33 -0700 (PDT)
> "Jeffrey Bouquet" <jbt...@iherebuywisely.com> wrote:
> 
> >  Just had a unique to me, unbootable backup [beside the point,
> > just a sidebar comment... ]  quandry dealing with the nvidia-driver update
> > that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]
> > 
> >   12.0 - CURRENT
> > 
> >   [ my previous 'saves' -- files to consult...  were in .jpg, so no avail 
> > for me to peruse as I was in the terminal ]
> > 
> > Lessons I learned, maybe
> > 
> > [RFC]  rename nvidia-driver.ko to include its version, for instance 
> > nvidia-modeset-37539.ko
> >   which would make one's diagnosis a fix easier. 
> > 
> > [suggestions]
> > 
> > ... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd 
> > thus made it 'unavailable'
> > ... document better that one can load nvidia[modeset] later than 
> > /boot/loader.conf [cli, rc.conf...]
> > 
> > [ mini 'what fixed it for you '  and/or stalled the same ... 
> > ] 
> > ... I had a make.conf in place, 'trapping' a
> > make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] 
> > install in failure
> > ... I had no clue if Xorg was at fault, and luckily did not have to rebuild.
> > ... I had no access to the forums, as the desktop could not be loaded [yet]
> > ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not 
> > usable module numbers,
> > THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include 
> > its 5 digit number
> > as above.
> > ... I was taken aback by the less infomative
> > this client has the .39 but the module has the .26 ... 
> > specifically stating which file/port/kernel module the 'client' refers 
> > to
> >and which specific modules 'this module' was referring to.  Unknown if 
> > that is
> >fixable here in a .c, .h , or is closed-source upstream in nvidia [corp 
> > ] where we can
> > ask them to be more specific or code in some more verbose error 
> > messages.
> > ...  Relieved I did not have to rebuild Xorg nor the kernel, just move 
> > files out of the
> >   way and do a simple rebuild of the nvidia-driver.
> > [... Not relieved that the nvidia-driver needed install during the mesa-lib 
> > reshuffle,  maybe
> >did not need to be, just a hazy recollection on my part.  So ignore this 
> > little bit ]
> > 
> > ... All in all a learning experience.  Howsoever, I would like this nvidia 
> > stuff to be put eventuall
> >  in /usr/src/UPDATING so the half or third of persons who run into this 
> > yearly will have a more
> >  authoritative flowchart of sorts to determine the next course of action.
> >something like
> >   if ... this thta
> >if... this that
> >if ... this that
> >   OTOH... error message... a... you may need to...
> >...
> >error message ... r... you may need to...
> > 
> >  ... And it would have maybe saved a bit of time here, and I would almost 
> > if eventually
> >  possible be sure to copy /usr/src/UPDATING to 
> > /usr/ports/x11/nvidia-driver for
> >  more easy access if the desktop was broken
> > 
> > 
> > Apologies for the hurried post. Indeed, I have tasked myself to write it up 
> > here
> > locally [ still in scribbled notations...] so I can forestall/fix more 
> > quickly this
> > error the next time.

[RFC] rename nvidia-driver port binaries [ and other comments]

[Jeffrey Bouquet]

 Just had a unique to me, unbootable backup [beside the point,
just a sidebar comment... ]  quandry dealing with the nvidia-driver update
that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]

  12.0 - CURRENT

  [ my previous 'saves' -- files to consult...  were in .jpg, so no avail for 
me to peruse as I was in the terminal ]

Lessons I learned, maybe

[RFC]  rename nvidia-driver.ko to include its version, for instance 
nvidia-modeset-37539.ko
  which would make one's diagnosis a fix easier. 

[suggestions]

... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd thus 
made it 'unavailable'
... document better that one can load nvidia[modeset] later than 
/boot/loader.conf [cli, rc.conf...]

[ mini 'what fixed it for you '  and/or stalled the same ... 
] 
... I had a make.conf in place, 'trapping' a
make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] 
install in failure
... I had no clue if Xorg was at fault, and luckily did not have to rebuild.
... I had no access to the forums, as the desktop could not be loaded [yet]
... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not usable 
module numbers,
THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include its 5 
digit number
as above.
... I was taken aback by the less infomative
this client has the .39 but the module has the .26 ... 
specifically stating which file/port/kernel module the 'client' refers to
   and which specific modules 'this module' was referring to.  Unknown if that 
is
   fixable here in a .c, .h , or is closed-source upstream in nvidia [corp ] 
where we can
ask them to be more specific or code in some more verbose error messages.
...  Relieved I did not have to rebuild Xorg nor the kernel, just move files 
out of the
  way and do a simple rebuild of the nvidia-driver.
[... Not relieved that the nvidia-driver needed install during the mesa-lib 
reshuffle,  maybe
   did not need to be, just a hazy recollection on my part.  So ignore this 
little bit ]

... All in all a learning experience.  Howsoever, I would like this nvidia 
stuff to be put eventuall
 in /usr/src/UPDATING so the half or third of persons who run into this yearly 
will have a more
 authoritative flowchart of sorts to determine the next course of action.
   something like
  if ... this thta
   if... this that
   if ... this that
  OTOH... error message... a... you may need to...
   ...
   error message ... r... you may need to...

 ... And it would have maybe saved a bit of time here, and I would almost if 
eventually
 possible be sure to copy /usr/src/UPDATING to /usr/ports/x11/nvidia-driver 
for
 more easy access if the desktop was broken


Apologies for the hurried post. Indeed, I have tasked myself to write it up here
locally [ still in scribbled notations...] so I can forestall/fix more quickly 
this
error the next time.
also...
Running late  in other personal matters, and out of time.

Respectfully..

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"

opera browser crash and recovery

[Jeffrey Bouquet]

About once a year, sometimes more often, sometimes less often, opera 
browser thinks it is not installed, and wishes to reinstall, placing a 
plain-vanilla
version to where years of customization had comfortably attuned the
browser to my workflow due to still-newbie tunings I've backup up.

The following two files, for instance, 
[install dir]/.opera/cache/toolbar/standardtoolbar.ini
[install dir]/.opera/cache/operaprefs.ini
Please double check those...

HOWEVER there may be a third or 4th..

Those two today restored a browser deletion of all the settings [ defaults to
no images, for  instance... ] I've crafted over the years.

So I was thinking maybe a pkg-message may be in order detailing the need
to backup one's files, and which ones, so others or even I may save time
and aggravation etc, should the crash [system, Xorg, etc] occur at n
inconvenient time.

Thanks

Jeff 
ps.  Hurriedly crafted email.  Sorry if any typos. 
___
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"

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

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: 12-CURRENT won't configure to download packagesite.txz yet

[Jeffrey Bouquet via freebsd-ports]

On 02/ 6/17 09:59 PM, Allan Jude wrote:

On February 7, 2017 2:35:16 AM GMT+01:00, Jeffrey Bouquet 
<jbt...@iherebuywisely.com> wrote:

All the files

/etc/FreeBSD.conf
/usr/local/etc/pkg/repos/FreeBSD.conf
/usr/local/etc/pkg.conf

I edit time after time for
{$ABI}  which gives FreeBSD:11:i386  but I am on 12-CURRENT i386
Anytime I try to attune to
freebsd:12:x86:32or
FreeBSD:12:i386   ...
it downloads the packagesite again, as it does in the ABI example, but
a terse
error of wrong architecture, etc, and a fail to do anything to upgrade
to  Pkg-12.

Can the proper file be rename upstream to what its architecture in
simpler terms:
like packagesite-i386-12.txz and a message printed upon de-TXZ the file
so that
the proper nomenclature is given to put into each of those three files
above
so that the generic packagesite.txz will not error out upon download?
Or, put the instructions in /usr/src/UPDATING ?? since it is part of
base?


Or some other way to de-showstopper this v11 April 2016 CURRENT to v12
Feb 2017 CURRENT
upgrade which still has failed to enable seamonkey-2.46_5 to run
non-segfault [ ie cannot run ]
vs seamonkey-2.46_4 which four days ago ran without EVER segfaulting??
And cannot build

>from ports for obscure .h clang-header file related reasons?

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

Please provide the output of:
uname -a

machine on which firefox, thunderbird, seamonkey, cc, pkg work:
...
11.0-CURRENT  #2
R298350
Wed Apr 20 2016
I386
1100105
1100105
DEC22KRNL10 ( not GENERIC )
...
machine on which firefox has broken numeric input [ I cannot log into
the FreeBSD forum as my nickname has a "2" within it...
nor use browser search in firefox that searches for terms with
a "2" within the text field... jumps to another tab..., cc MAY be fixed, 
pkg still works only at v11,
seamonkey segfaults, thunderbird segfaults, otter-browser has bus 
error,  seamonkey won't build

due to maybe clang header files:
..
12.0-CURRENT #3
R313305
Mon Feb 6 2017
i386
1200020   ( guess from strings on the kernel) ... (forgot to run uname 
when booted into the system)

1200020   ( guess from strings on the kernel)   "
DEC22KRNL10 (not GENERIC)
and per pkg -vv, still v11...

uname -K
uname -U

Again, maybe a ${ABI} set of three files (FreeBSD.conf (2) , pkg.conf ) 
that I could use as a template
may fix the package issue and if that is fixed, could fix the 
seamonkey/thunderbird/firefox issues...
Precise documentation is lacking in the limited time I have to test 
solutions in forum and mailing

list posts.
.

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

12-CURRENT won't configure to download packagesite.txz yet

[Jeffrey Bouquet]

All the files

/etc/FreeBSD.conf
/usr/local/etc/pkg/repos/FreeBSD.conf
/usr/local/etc/pkg.conf

I edit time after time for
{$ABI}  which gives FreeBSD:11:i386  but I am on 12-CURRENT i386
Anytime I try to attune to
freebsd:12:x86:32or
FreeBSD:12:i386   ...
it downloads the packagesite again, as it does in the ABI example, but a terse
error of wrong architecture, etc, and a fail to do anything to upgrade to  
Pkg-12.

Can the proper file be rename upstream to what its architecture in simpler 
terms:
like packagesite-i386-12.txz and a message printed upon de-TXZ the file so that
the proper nomenclature is given to put into each of those three files above
so that the generic packagesite.txz will not error out upon download?
Or, put the instructions in /usr/src/UPDATING ?? since it is part of base? 


Or some other way to de-showstopper this v11 April 2016 CURRENT to v12 Feb 2017 
CURRENT
upgrade which still has failed to enable seamonkey-2.46_5 to run non-segfault [ 
ie cannot run ]
vs seamonkey-2.46_4 which four days ago ran without EVER segfaulting??  And 
cannot build
from ports for obscure .h clang-header file related reasons? 
___
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


More progress but not so encouraging.

Rebuilt the machine on which seamonkey segfaulted, to v12-CURRENT 
..
seamonkey still segfaults
after _4 _5   [ a showstopper for the v11 OR v12 desktop on that disk ] 

/usr/bin/cc segfaults, prohibiting port building
after installworld  [ a showstopper for v12 on that disk ]

pkg -vv reports v11

FreeBSD.conf 
   containing FreeBSD:12:x86:32,
   containing /${ABI}/,
   containing FreeBSD:12:i386
each error out in some manner or another, making package not usable.
[a showstopper for pkg usage on that disk ]

Firefox prohibits 2 entry anywhere, so I cannot log into the forums as
jb_fvwm2 on the newer machine to inquire there, not use most any
search query containing the numeric digit(s) 2 and at least two others.
[ a showstopper for firefox usage on that disk ]

.
None of these 4 problems were present on Feb 4 vs by the morning of today Feb 
6...
___
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"

Seamonkey update

[Jeffrey Bouquet]

pkg today updated seamonkey, now it segfaults, 
every which way I try to run it.

[This is from backup and a rewritten fstab. ] 

linux-seamonkey also segfaults, first time I installed it.  Deinstalled.
firefox works only half as efficiently,  but passably.
seamonkey fails to build with gcc, clang49 or default... vs other times.
attempting to fix that with nvidia-driver update, 
which fails to build, API mismatch... which used to work
after installing theolder nvidia.ko and nvidia-modeset from backup, ALSO API 
mismatch.
which I think I used in the past to fix a similar problem...

Seamonkey is currently the 
second most vital part of this 
FreeBSD Jan 2004-2017 5x > v11 ,,,

So the _4 _5 was quite a showstopper.  
Working backup from a day ago was only coincidence.

Any one know where to get _4 etc, i386, without reverting to quarterly repo? 
portsmon is four weeks behind IIRC with a developer working on  a fix... so the 
.txz there
are NGINX 502 or some error...

Inaccuracies in the above, maybe. Apologies.  Rushed today...
And sorry for multi-topic most of which I hardly ever delve into fixing so not 
really qualified nor
time to fix or file PR on...
___
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"

why a persistent GCC GCC49 conflict?

[Jeffrey Bouquet via freebsd-ports]

pkg install driftnet wants to install gcc, and REMOVE
truecrypt, gcc49, xpi-web-developer...[23 more]...sscalc.

This has been going on almost a half-year it seems. 
as gcc49 and gcc install files into the same place.

Before that several years, again IIRC, with no such specific
problem...

___
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: The ports collection has some serious issues

[Jeffrey Bouquet via freebsd-ports]

tacking a slightly off-topic topic onto this one


On 12/15/16 10:31 AM, list-freebsd-po...@jyborn.se wrote:

On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote:

On 12/15/16 09:40, Warren Block wrote:

On Thu, 8 Dec 2016, Matt Smith wrote:


On Dec 08 05:16, Daniil Berendeev wrote:

Although portmaster is not releated to the FreeBSD project and is an
outside tool, there aren't any alternatives from the project itself. So
use it or die. Not a nice situation.

People have been trying to get portmaster deprecated and removed from
the handbook but have met with resistance.

Well, yes.  Because it works, has no dependencies, and there is no
equivalent replacement.  [...]

Warren, you have hit the nail on the head.  -- George

+1

I never have problems with portmaster.
(But portupgrade could at times be an utter mess,
I never looked back after switching to portmaster
many years ago.)

And I'm not at all interested in running poudriere
or synth, thank you.

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"

synth here: silently fails, year in year out
synth on a new install equal to this one: good to go
poudriere:  inexpert, hundreds of .htm saved for howto
portmanager:  MOVED, saved hours debugging portupgrade/portmaster until 
it started not working so well.
custom .sh   :   did most of what portmaster did, sometimes very rarely 
in use

edited locally portmaster:  fail at coding on my part
portmaster:  has worked mostly, gave up recently though.  Really would 
like it fully pkg compliant
portupgrade:  features since /var/db/pkg/DIRECTORIES not front-ended by 
sqlite3 expertise required have not worked, pkgdb -F for example

   IIRC

All of those restored to 2006 goodness and working together seamlessly?  
I cannot wait.  Possible with enough systemd-too-complex

systems migrated to FreeBSD someday may happen...

But the reason for this add-on to that topic:
due to gcc gcc49 conflicts I was forced to desinstall math/ised.
Now:  if one will pardon xclip pasted in formatting:

pkg-static install ised Updating FreeBSD repository catalogue... FreeBSD 
repository is up-to-date. All repositories are up-to-date. pkg-static: 
hugin has a missing dependency: autopano-sift-C pkg-static: truecrypt 
has a missing dependency: fusefs-kmod Checking integrity... done (2 
conflicting) - gcc-4.9.4 conflicts with gcc49-4.9.4_1 on 
/usr/local/bin/i386-portbld-freebsd11.0-c++49 - gcc-4.9.4 conflicts with 
gcc49-4.9.4_1 on /usr/local/bin/i386-portbld-freebsd11.0-c++49 Checking 
integrity... done (0 conflicting) The following 33 package(s) will be 
affected (of 0 checked):


 Installed packages to be REMOVED: truecrypt-7.1a_3 gcc49-4.9.4_1 
ircii-20151120 py34-setuptools_scm-1.10.1 py34-msgpack-python-0.4.7 
3dm-2.11.00.021_1,1 py34-llfuse-1.0 xalarm-3.06_3 p5-PDF-Template-0.22_1 
pdflib-perl-7.0.5_2 xpi-web_developer-1.2.2 pathneck-1.3 mpack-1.6_3 
webcopy-0.98b7 lha-ac-1.14i_10 lv-4.51_3 window-1.0 solarized-1.0.0 
freefonts-0.10_7 weedit-2.0.3 ncp-1.2.4 shorten-3.6.1 jail-primer-0.2 
lynis-2.4.0 win32-codecs-20110131,1 areca-cli-i386-1.14.7.150519,1 
pkg_cleanup-2.1 sscalc-1.0 New packages to be INSTALLED: ised: 2.7.1_1 
gcc: 4.9.4 dejavu: 2.37 Installed packages to be REINSTALLED: pkg-1.9.4 
opera-12.16_6 (options changed)


Number of packages to be removed: 28
Number of packages to be installed: 3
Number of packages to be reinstalled: 2
The operation will free 103 MiB.
13 MiB to be downloaded.
Proceed with this action? [y/N]: n

Additionally, it does not build. Maybe on the other machine that synth 
runs on, I could put it on a thumbdrive and install just

the ised binary...

Also had to deinstall scilab, PDL, py27-game, solarwolf, etc etc. IIRC

Nothing urgent at all but my thoughts on this gcc conflict issue as well 
as maybe chiming into the topic of this thread
Sorry to waste anyone's time, may be a local issue to this particular 
ports tree, some errant file.

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

today "pkg install" not quite smooth... vs the usual [gcc49 ]

[Jeffrey Bouquet via freebsd-ports]

pkg install  [ as always, here, an edge case, ]
some forty  [because not wanting the other thirty that " pkg upgrade"
wants to do ] ran into difficulty with a gcc-4.9 and gcc49 conflict...  [ 
installs into
same place some file ]

[tl;dr a bit of the above, I never answer Y to 'pkg upgrade' but pkg install a 
half
of the suggested ports in a long command line ] 

Seemingly resolved with  Cntl-C some of pkg commands, and "pkg add" a few
that had been downloaded.  ... that quirkiness of this run vs most of the time. 

pkg upgrade shows the upgrade(s) having been complete, and I ran ldd and 
--version on a few,
and it seems good to go.  Too early to be sure. 

Uncertain if some ports have been inadvertantly desinstalled, or some other
not-as-originally-intended glitch from the original command that was run, not 
included
here for brevity.

Posting because this pkg quirkiness hasn't happened in the past half year or so,
though it has in the past, and 'pkg add' eventually resolved it, then also.

Not so important here any longer, today at least, 
however maybe pkg could be made more foolproof with regards
to this specific gcc conflict [ symlinks during the install ?? ] and others 
similar to it that
may occur, python2 and python27, for example, if that were similar.  Or the 
ports tree
more resilient in some way.  Way past my expertise, in either case.  

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

Re: old ports/packages

[Jeffrey Bouquet via freebsd-ports]

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

Re: old ports/packages

[Jeffrey Bouquet via freebsd-ports]

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

Need an expect script or p5-*Expect* to lessen keystrokes upon large ports tree changes

[Jeffrey Bouquet via freebsd-ports]

Today  svn-of-ports has about 600 (tc,mc) /200 (r)  = 800 responses
required (tree and etc conflicts)



1...

Select:
 (mc) prepare for updating moved-away children, if any (recommended),
 (p) postone, (q) quit resolution, (h) help:

[ I need expect to return mc, and a RET ]  IF expect works upon svn
responses

2...
 
Select:
 (p)(df)   (e)   (m)
 (mc)  (tc)
  (s)

[ I need  expect to return tc , and  a RET]  Sorry for the omitted svn
context

3...

Select:
 (r) (p) (q) (h)  [ sorry for the omitted svn
context]

[I need expect to return r , and a RET ]

 

-

Writing this request about 100/800 done for today, so cannot help this
time, not
urgent --  better yet if it was integrated into svn  as a feature...

Seems  that, once-a-year or so, it is way too time consuming all of  a
sudden, and sometimes
exceedingly inconvenient -- so it would be nice to have a backup plan.

I will provide context in a followup, after a few days, if that is necc.
for some expert or
semi-expert in expect to craft a script. 

Thanks in advance, or any other ideas appreciated.  Not wanting to waste
anyone's time.

Jeff
___
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: Removing documentation

[Jeffrey Bouquet via freebsd-ports]

On 02/15/2016 09:32, Roger Marquis wrote:
>> This makes no sense.  Ports are not tied to base releases.
>> And you think lack of developer resources is an invalid reason?
>
> There was no mid-release issue with base as far as I know.  The issue was
> with ports and by extension pkgng (and related -ngs).
>
>> You know good and well that people kick the can down the road FOREVER.
>> You could have announced it 3 years ahead and people would still scream
>> NOT YET!  NOT YET!  This would NEVER happen in Linux!
>
> The announcement
> 
>
> was dated Feb 3 2014, leaving all of 7 months until the planned
> deprecation.  Even if you could make a case that pkgng was ready (it
> wasn't) 7 months is far less than the 2 calendar year and dozens of
> person-year cycles required by some infrastructure-critical production
> environments.  It's even farther from the 7+ years that other FOSS
> distributions support their releases.

> Roger
> ___
> 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"
IIRC pkg(ng) was why I joined the freebsd-current mailing list, arguing
there several times against
its abstraction from command-line pipe tricks on the /var/db/pkg
subfiles... by portmaster etc...
[ if not, it was the second issue posted about... ]


Since upgraded all systems (almost all) to pkg. (Not without breakage,
sorry to say, but did one or two
reinstalls of the OS, thankfully not on often-used systems...)

And have  a near-seamless twice-weekly upgrade.
...
However, I would surmise it best to eventually (as I stated before)
re-enable the pkg_tools as  a
parallel subsystem ( sort of like a shadow fallback /var/db/pkg if one's
sqlite3 file goes missing...)
(or an urgent-upgrade path with portmaster -d -B -P -i -g (or something
if the usual one is broken..)
Or even a 'pkg runs in a sandbox 'pkg upgrade' AND portmaster -d -B -P
-i -g and actually does the
upgrade that completes without error... maybe examinable by the user

However, that is all just a subset of the wish list here (like reverse
engineering the MOVED portmanager
and making it pkg-capable... )

 And some schemes I postulate here may be more doable on paper than
in practice...

BTW made synth ccache-aware and ran it for the first time 'en masse'
today.  Unclear whether it with
the build-only command, did actual installs or not, (some were listed as
FAILED) but it sure was
*pretty* ...  (red, green...) to see.

Apologies for treading off-topic.
___
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"

"synth status" same error as all commands, more data posted.

[Jeffrey Bouquet via freebsd-ports]

synth status

Querying system about current package installations.
Stand by, comparing installed packages against the ports tree.
Stand by, building pkg(8) first ... Failed!!  (Synth must exit)
Unfortunately, the system upgrade failed.

11.0-CURRENT r288246
pkg-1.6.2
synth-0.98_5

/usr/ports
/var/synth/live_packages
/usr/ports/distfiles
/var/db/ports
/var/log/synth
/usr/obj/synth-live
/
disabled
2
2
false
false
true


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

dp_PORTSDIR not set

[Jeffrey Bouquet via freebsd-ports]

This error has recently appeared.  So a make has to be

dp_PORTSDIR=/usr/ports make...

and it seems to ignore it being set in make.conf to try
to fix it, even.

Wondering if it is local to just here...
___
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: distfiles cleaner

[Jeffrey Bouquet via freebsd-ports]

On 10/19/2015 16:41, Julian H. Stacey wrote:
> Bryan Drewery wrote
> 
>> I could go on, but really I think both are pretty bad compared to using
>> Poudriere, which also has a 'distclean' sub-command.
> OK, Thanks for all detail.  I would have run a poudriere to compare
> with the previous 3, but I've just removed my last copy of my 58
> Gig. But I note: one more reason to learn poudriere :-)
>
> Cheers,
> Julian

Just to add to the portmaster V portupgrade ... I recall fondly the
MOVED portmanager.  (binary code).  It had an initial check-dependency
run one could cntl-c out of and have onscreen to update just a few
ports...  and fixed ports often where the others failed for some
reason.

[I tried coding some local variances to portmaster here, but got
lost in the code...]

I read about poudriere daily almost on the ports list, and wish [1] that
before
I use it someone (if ever, not likely  to use it as of now,  not enough
machines) puts together a flowchart of its use cases, edge cases, etc
large enough to preclude reading forum threads or mailing lists...

[1] not for my benefit, but something I could write about in emails...
___
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"

Eventually a must-have pkg feature missing...

[Jeffrey Bouquet via freebsd-ports]

Compounding the problem:
The machine here is usually not running during the nightly pkg backup.

The problem: 
Recently a glitch in a Western digital drive [that fsck_ffs fixed ] lost
/var/db
I restored local.sqlite from the prior days' backup... 
[ and eventually found it renamed within /lost+found ... ] 
but it would be nice
if pkg wrote a duplicate local.sqlite to another place in the filesystem or
a different ?user-selectable? filesystem upon most or all operations, maybe
configurable as default or non-default.
SPECIFICALLY for hardware crashes... if not also for machines running
rm as initally installed vs here, where it is aliased "away" so one has
to type "/bin/rm"  making the command more "think before pressing
the ENTER key..."

{ As before, nice to have "pkg install" more verbose as to desinstalls/
new installs as to which port each deintsall/insall in the two other lists
(upgrade/reinstall)  it outputs ... but I am used to that.  The first issue here
seems to have a higher priority...  }

{ as before,  optionally out put /var/db/pkg folders in legacy style...
{ pkg feature to compare local.sqlite local.sqlite reporting a diff similar to 
  deprecated port pardiff (diffp) as of 4-13-2014...
{ pkg feature to on-the-fly use as its reference a different local.sqlite so
  one could 
  pkg autremove -n local.1;...  pkg autoremove -n local.2  
  and see which local.sqlite one wants to keep/discard... say when
  restoring from backups...

Thanks.
Also, here the new pkg-static 1.6.0 ran as flawlessly as the one installed 
(I ran it from the port /work/ tree..)

Sorry for the duplicate requests below the main one.  Seems easiest way
to request what smaller parts of it all may be planned for first, if not all
written somewhere in the roadmap[s]...

J. Bouquet

Cross-posting to two lists.  Wish to cross-post to five.  Apologies...
___
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"

new firefox, seamonkey problems

[Jeffrey Bouquet via freebsd-ports]

This might be related to a thread (pcmanfm) today in the forums with
similar issues.

Suddenly after today's pkg update of gnome stuff,  firefox and
seamonkey permit browsing UNTIL one tries to save a page, it
seems, then no further interaction with the browser is permitted
until a restart. So only 'scrot' appears useful vs the file
dialog...

Notably on the forums.freebsd.org  page.

Never had this happen in years and years AFAIK.

Only a slight chance it is a cache somewhere not in the usual
Cache but related to the file choose that should be cleared... or
a not-yet-rebuilt component of the browsers that implements the
file chooser dialog functionality.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

devel/subversion staging, won't install.

[Jeffrey Bouquet via freebsd-ports]

I've a note in devel/subversion that it failed to install in March this
year...
Just then (aug 6) it again fails to install [ terse kwallet-dynamic-lib
something, broken
install line in built-already install-from-stage ;  the relevant ??
option is deselected ].

Maybe someone knows if some option is mandatory, or something else...

I've BDB, DOCS, FREEBSD_TEMPLATE, NLS, P4_STYLE_MARKERS, SERF,
SVNSERVE_WRAPPER
but not the maybe relevant KDE_KWALLET ...

As before, reinstalled the older version using pkg.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

pkg problem, not severe but tedious.

[Jeffrey Bouquet via freebsd-ports]

Each time across major versions I find it convenient to install one or two
upgrades ( portupgrade and another, in this case)

pkg install portupgrade   [the installworld just completed an hour or two ago]

I use a 
script reinstall.log pkg install portupgrade

Because
the deinstalls called for are too numerous, no option to delay [ another SQL 
field? ]

For instance 

Those two reinstalls (major version) require removal of some 200-400 of which I 
note
manually 35 or so for immediate reinstall later today.

In this case
Not trivial...

serf
apr 
subversion 
w3m 
firefox
vte
intltool
gnutls
gsasl
gtk2
cups-base
...and twenty-odd others of the several hundred to be removed upon the
upgrade of portupgrade from another major version and another ruby version
to the latest one.

So it is handy workaround, but I wonder if a combination of
1... delay these til later
2... to be removed and logged in a /var/log/pkg-removed.logfile
3... or some other scenario should make it more simple.
4... a 2nd field in the 'to be removed'   ... some removed because of the 
   ruby21 upgrade, some removed for some other reason... one could maybe
  craft the request to pkg in a more orderly fashion if more information was
 known at that step. Maybe. 

Obviously this does not occur in the usual course of upgrading... but those to 
be removed could
probably still be of use in the meantime...   Not that is is too problematic to 
reinstall them (usually but
not always )...  but it is not as automatic as it maybe could be eventually.

Thanks for reading.  
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Trivial bug?

[Jeffrey Bouquet via freebsd-ports]

  /bin/rm -v aclocal-1.10
  /bin/rm -v aclocal14
  cp -iv /usr/local/bin/aclocal-1.4 /usr/local/bin/aclocal-1.14
  cp -iv /usr/local/bin/automake-1.4  /usr/local/bin/automake-1.14

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

Trivial bug? [corrected email, sorry]

[Jeffrey Bouquet via freebsd-ports]

  /bin/rm -v aclocal-1.10
  /bin/rm -v aclocal14
Not relevant, but were not belonging to anything (/usr/local/bin)

  cp -iv /usr/local/bin/aclocal-1.4 /usr/local/bin/aclocal-1.14
  cp -iv /usr/local/bin/automake-1.4  /usr/local/bin/automake-1.14

Those two lines enabled a new port to configure (editors/vanubi).


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

SOLVED: pkg version mismatch [succeeds port...]

[Jeffrey Bouquet via freebsd-ports]

I noticed the ports tree here had net/uget 1.10.4_1 even after svn up... while
pkg upgrading installed 2.0.  pkg version (one of 3 ways) reported 
succeeds port... was about to post a question about pkg, but it can be fixed
by 

cd /usr/ports/net/uget
svn revert . -R 

[found at stackoverflow]

[I've about thirty of so of those directories to fix up, for installed ports... 
it seems].

Wondering if the fix can be put in CAVEATS or something in the pkg version
man page... for those using subversion... 

also if ever a man page with many examples is crafted for subversion on FreeBSD,
that could be one of them.

Others:

cd /usr/ports
svn resolve .


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

Re: SOLVED: pkg version mismatch [succeeds port...]

[Jeffrey Bouquet via freebsd-ports]

On 06/01/15 13:44, Lowell Gilbert wrote:
 [pkg@ snipped, because it's irrelevant]

 Jeffrey Bouquet via freebsd-ports freebsd-ports@freebsd.org writes:

 I noticed the ports tree here had net/uget 1.10.4_1 even after svn up... 
 while
 pkg upgrading installed 2.0.  pkg version (one of 3 ways) reported 
 succeeds port... was about to post a question about pkg, but it can be 
 fixed
 by 

 cd /usr/ports/net/uget
 svn revert . -R 

 [found at stackoverflow]

 [I've about thirty of so of those directories to fix up, for installed 
 ports... it seems].

 Wondering if the fix can be put in CAVEATS or something in the pkg version
 man page... for those using subversion... 

 also if ever a man page with many examples is crafted for subversion on 
 FreeBSD,
 that could be one of them.

 Others:

 cd /usr/ports
 svn resolve .
 These would not be useful to document unless you can document how you
 got into those situations in the first place. 

I think it was disk failure and svn did not like resuming the updates to the
directories newly crafted into a everyday install type system from backup.
[ I prefer keeping the same tree across years of updates because I am used
to saving build logs, .htm and .msg and .txt hint files, etc within the
directories. ... for easier reference]
 svn revert is only
 necessary if you made local changes to the sources under svn control,
I typically use it to build, ports, say, that are broken due to no fetch
possible, for
which I already have the sources, so I can svn revert Makefile and
similar uses.

 and even then usually if svn can't automatically merge upstream changes
 into yours. svn resolve is the way to sort out the merge if svn can't
 do it.
Just a few days ago I used svn resolve to tune the ports tree.  Maybe the
side effects of that, and/or the response I type to the svn questions
(always TC, always
r, for those familiar with the two types...text and tree, respetively)
are what causes the version mismatches
that were present. [  OR the situation in the first paragraph above. ]

Part of  a daily svn log:


 
Updating 'usr/ports':
. [snipped]
 Summary of conflicts:
Text conflicts: 0 remaining (and 2 already resolved)
Tree conflicts: 0 remaining (and 2 already resolved)
..


 I tend to annotate uses into hint files (.txt .msg .dat .how .htm)
in /usr/src RE svn
Has saved a ports tree from newly needing to be downloaded more than once

 It sounds like you're not intending to make local changes at all. In
 that case, I'd recommend you use something else (probably portsnap) to
 maintain your ports tree.
I think, am not sure, that portsnap and svn are the only two. I prefer
the more cvs-like workings
of svn, and have never used portsnap...  I think the former enables one more
fine-grained tuning unless one knows the workings of the latter.  I
could be wrong
but...


Just information for the list... as a followup.  Not wanting to prolong
the thread without
reason.



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

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

Re: Invalid version format (non-numeric data) ... Perl broken...

[Jeffrey Bouquet via freebsd-ports]

On 05/15/15 19:25, Jeffrey Bouquet via freebsd-ports wrote:
 Freebsd 10 STABLE

 perl5-5.20.2_4

 1...
 Error in Makefile.PL line 21
 [building p5-Gtk2]
 while trying to build to fix...

 2...
 Line 49 in gprename (x11-fm)
 line 26 in Gtk2.pm (p5-Gtk2)
 [running gprename]

 Trying to rename files that are slightly too lengthy for
 cli rename tools.  This error appears trying to run or build...
 
 similar
 ..
 3...
 p5-AnyEvent
 Invalid version format (non-numeric data)  at /usr/local/lib/
 perl5/site_perl/ExtUtils/MakeMaker.pm  line 6.

 Slight chance the contexts are off a bit, the the errors in sum total
 are there.  [Like plainly in example # 3]
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Figuring as perl won't rebuild, and many other perl cli won't run, and
most AFAIK or all
perl ports won't build...

I've saved about eight .htm on renaming.
'rename' fails (too many arguments)...

BUT fyi we have a TOOL...  kind of off topic for the perl list; apologies. 
Not my script. 

rename001002.sh
...
#!/bin/sh

filePrefix=$1
sequence=1

for file in $(ls -tr *.jpg) ; do
renamedFile=$filePrefix$sequence.jpg
echo $renamedFile
currentFile=$(echo $file)
echo renaming \$currentFile\ to $renamedFile
mv $currentFile $renamedFile
sequence=$(($sequence+1))
done
exit 0
...
# rename new-file-name-
will rename site_00xxx000xxxjjFFjjFF.jpg   (a slew of whatever *.jpg)
to
new-file-name-001.jpg
new-file-name-002.jpg

Worked here at least once.
pardon for any typos
Hope this saves someone hours of web searching sometime, if
'rename' fails and gprename doesn't load etc...
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Invalid version format (non-numeric data) ... Perl broken...

[Jeffrey Bouquet via freebsd-ports]

Freebsd 10 STABLE

perl5-5.20.2_4

1...
Error in Makefile.PL line 21
[building p5-Gtk2]
while trying to build to fix...

2...
Line 49 in gprename (x11-fm)
line 26 in Gtk2.pm (p5-Gtk2)
[running gprename]

Trying to rename files that are slightly too lengthy for
cli rename tools.  This error appears trying to run or build...

similar
..
3...
p5-AnyEvent
Invalid version format (non-numeric data)  at /usr/local/lib/
perl5/site_perl/ExtUtils/MakeMaker.pm  line 6.

Slight chance the contexts are off a bit, the the errors in sum total
are there.  [Like plainly in example # 3]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: devel/dbus no longer starts at system poweron

[Jeffrey Bouquet via freebsd-ports]

On 03/02/15 06:57, Beeblebrox wrote:
 Using dbus-1.8.12, /etc/rc.conf has (dbus_enable=YES,
 slim_enable=YES). This works no more. X.Org starts, but cannot
 login to any Desktop because dbus actually is not running and has
 not started.

 Kill Xorg, then manually service onestart dbus, and slim.
 I can then start to my desktop managers.
 what do dmesg and /var/log/messages say?
 Erich
 This problem was resolved some time back (through an update I believe) but is 
 now back. No error message is registered in /var/log/messages or any other 
 log. However, combing through the output on TTY0, I found this:
 Starting dbus
 Shared object 'libexpat.so.1' not found required by 'dbus-daemon'
 /etc/rc: WARNING: failed to start dbus

 After system is booted, form any TTY*, # service dbus onestart results in 
 normal startup. Not setting any dbus_flags and not using gdm_enable.

 # pkg info -l expat  expat-2.1.0_2:
 /usr/local/bin/xmlwf
 /usr/local/include/expat.h
 /usr/local/include/expat_external.h
 /usr/local/lib/libexpat.a
 /usr/local/lib/libexpat.so
 /usr/local/lib/libexpat.so.1
 /usr/local/lib/libexpat.so.1.6.0
 /usr/local/lib/libexpat.so.6
 /usr/local/libdata/pkgconfig/expat.pc
 /usr/local/man/man1/xmlwf.1.gz
 (files separately confirmed with ls /usr/local/lib/*expat*)

I've the same problem
(libexpat and dbus-daemon)
and posted to the freebsd-current list a few days ago.
Rebuilt every dependency...  etc. 
One other port also does not start *uuid* ...
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

pkg wondering...

[Jeffrey Bouquet via freebsd-ports]

No pkg failures , but quirks:
.
1.

Backing up pkgng database:
pkg: Ignoring bad configuration entry in /etc/pkg/pkg.conf: /usr/cache/pkg
pkg: Ignoring bad configuration entry in /etc/pkg/pkg.conf: INDEX-10
pkg: Ignoring bad configuration entry in /etc/pkg/pkg.conf: freebsd:10:x86:32

Can pkg be smarter and suggest a proper configuration upon error, test a new 
one locally before 
suggesting it, or have one firmly tested as working...   hesitant to remove the 
improper entries 
because then oftentimes, IIRC, what remains causes, or has caused, pkg-* 
failures with not
solution suggested...

BTW that series of messages obscures  day to day portupgrade updates locally... 
ten or so
lines to each one of the upgrade by portupgrade ...  leaving the latter not in 
context.

Something like a sysinstall for pkg (all its files)  parsing each one for 
errors... would be useful for
new installs as well as existing ones maybe?
..
2.
Another feature maybe missng in pkg-install and pkg-upgrade is the skip  this 
upgrade? new
dependencies ; for instance audio/mous is qt4 so I do upgrades with
... | grep -v mous |   ...
an xargs pipe...  However the particular port has to be tested locally of all 
the list passing
through the pipe to xargs.  Slows it down some.

3. 4.
Less relevant, do not remember them right now...
...
A. 
Don't know if this should fit in this email, but every boot 
libexpect.so.1 not found required by dbus-daemon 
... and another (uuid* ) ...
persists even after reinstall of everything known relevant.

Ignorable here, but...
..

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

Re: BIND REPLACE_BASE option

[Jeffrey Bouquet via freebsd-ports]

On 01/13/15 07:55, Kurt Jaeger wrote:
 Hi!

 customizations you need available.  If the default options don't cut it
 for you, in order to use only binary packages that means you need to run
 your own poudriere setup -- which is well worth it if you're managing
 several machines / jails etc.
 poudriere allows you to manage several seperate pkg trees with different
 options, so you can:

 - build a default tree (and pkg repo), provide it to all generic hosts
 - build a seperate tree (and pkg repo) with modified options, and
   provide it to the special hosts

 It helps to keep the poudriere build tree on fast flash/SSD drives 8-}

 This all works and is very, very good! Thanks for the work!

As I probably won't ever know enough from experience, if one wants a
local lan
build tool is there any flowchart with use cases

1... foo foo bar use case  tinderbox
2... foo foo bar use case  build jail
3... foo foo bar use case  bhyve
4... foo foo bar use case  poudriere
5... foo foo bar use case  csbd OR qjail OR ezjail OR man jail OR
bastille script
6... foo foo bar use case  server on lan serving packages

And where they may overlap, which takes the least setup time, which
takes the
least maintenance time, which can be most easily migrated version 
version ...



Not to mention the wiki, but if that information was [some term ] use
cases like
virtualization or multi-machine or... on the freebsd.org page
prominently, it may
result in a larger userbase... more coders onboard.

Recognizing that a lot of this is emerging technology.  Apologies.  I've
a slight
interest in reading any such document, having read an hour or so
yesterday not
a few htm explaining jails, (10 pages of threads linked from
a search 'ezjail' in the forums, for example) to know that acquiring the
expertise of
a quickstart group of terms to focus on in any particular scenario is
something I don't
easily expect to acquire.

On the other hand, to include the wiki... vs links from it.


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

Re: Opera, still functional, 'one cannot make new configs' etc since v9 v10

[Jeffrey Bouquet via freebsd-ports]

On 01/11/15 22:59, Fred Woods wrote:
 If you run opera from a terminal window, do you get something like the
 problem described in:
 http://stackoverflow.com/questions/2568408/pango-warning-failed-to-choose-a-font-expect-ugly-output

 If yes, then a possible work-around is:

 Move any pango compliant fonts to /usr/local/lib/X11/fonts
 mv /usr/loocal/share/fonts/* /usr/local/lib/X11/fonts

 Create a symlink to make /usr/loocal/share/fonts point to
 /usr/local/lib/X11/fonts.
 ln -sF /usr/local/lib/X11/fonts /usr/loocal/share/fonts
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Did not help, unfortunately.
I've exactly two other ideas, but neither is certain to fix it, and a
few others for which I am still clueless.
Additionally, it seems few (openbsd? debian?) ship by default with opera...
One of the more readable screenshots attached (email, may not make it to
the list...) and inline... in the email. if that
make sense.  Newbie here with thunderbird terms.

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

Opera, still functional, 'one cannot make new configs' etc since v9 v10

[Jeffrey Bouquet via freebsd-ports]

II can browser fine with Opera still [mostly] but cannot interact with its 
dialog. ONLY the lowercase 'a' [and uppercase E] show. For instance, the 
'graphics' button (on off toggle) has [ a ] and the 'open in background tab' is 
[ _ a a ] ...  

 So the prompts and browser action are only by 'what the 'a'
 probably resolves to...

 Even the about:config choices are a bunch of 'a' and no other text nor 
numeric values visibly selected, though the items to choose are in another font 
and are visible. 

 I rebuilt it with/without qt4, gtk2, and the problem persists. NO menu nor 
'preferences' choices to speak of that are a change from what used to be. 
And also practicaly reinstalled, some multiple times, each of its dependencies 
that are listed in ports through the make commands.

 This happened once before,. And was fixed by some random crash and restore...


Freeetype2?
fontconfig?
Some menu option?
gtk2?
font setup?

A new install is missing an so file
so
cp -iv  /usr/local/lib/freetype.so.6 /usr/local/lib/compat/libfreetype.so.9  
fixes that...

Thanks for anyone knowing any probable fix.

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

Re: [Some VERY Solved] minor, for now, pkg/ports problems

[Jeffrey Bouquet via freebsd-ports]

On 12/26/14 17:30, Jeffrey Bouquet via freebsd-ports wrote:
 pkg-static fails to install python27 after v9  v10  (cannot find .so in 
 STAGE)...
 Occurred in some other port also. (openssl or openssh maybe, unsure)

Today after pkg fetching and reinstalling a few ports (v10) pkg fetch
installed
python27...


 pkg-static prints Ignoring bad configuration entry in /etc/pkg/pkg.conf   
 repeatedly, hiding
 portmaster y/n questions behind it...
 However, one of the two is a changed-recently format due to package
 the other invalid IS necessary on this machine
 So maybe a parameter --silent-configuration-warnings 

Removed that file (renamed it).  Warnings gone
 As of today, that configuration however worked nicely on another identical v9 
  v10 that before was
 unworkable.


 pkg fech libxul
 tries, has checksum mismatch. 
 gives up
 Only a few ports so far...
Just downloaded it without problems.  Maybe was rebuilding some port after
v9  10 ... or the removal of the spare pkg.conf file.  Won't probably
ever know.

 Might as well put in another longstanding one... 

 binutils  binutils  binutils binutils  always seems to depend upon itself, 
 esp with
 portmaster,   I believe ar or 'as is needed before its reinstall to 
 reinstall or 
 upgrade it... and is also in base...


 And a fifth...

 I've still the 'open-oasis' docbook error from v9 (building/installing 
 devel/git for example, there
 exist other PR's affect only me... ). 



 Sorry for the grouping of issues.

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

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

A few Somewhat minor, for now, pkg/ports problems

[Jeffrey Bouquet via freebsd-ports]

pkg-static fails to install python27 after v9  v10  (cannot find .so in 
STAGE)...
Occurred in some other port also. (openssl or openssh maybe, unsure)




pkg-static prints Ignoring bad configuration entry in /etc/pkg/pkg.conf   
repeatedly, hiding
portmaster y/n questions behind it...
However, one of the two is a changed-recently format due to package
the other invalid IS necessary on this machine
So maybe a parameter --silent-configuration-warnings 

As of today, that configuration however worked nicely on another identical v9  
v10 that before was
unworkable.


pkg fech libxul
tries, has checksum mismatch. 
gives up
Only a few ports so far...

Might as well put in another longstanding one... 

binutils  binutils  binutils binutils  always seems to depend upon itself, 
esp with
portmaster,   I believe ar or 'as is needed before its reinstall to 
reinstall or 
upgrade it... and is also in base...


And a fifth...

I've still the 'open-oasis' docbook error from v9 (building/installing 
devel/git for example, there
exist other PR's affect only me... ). 



Sorry for the grouping of issues.

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

Just a local workaround for the not-finishing pkg install PR 195471

[Jeffrey Bouquet via freebsd-ports]

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

Just a *local* workaround for the not-finishing pkg install PR 195471

[Jeffrey Bouquet via freebsd-ports]

[ Sorry for the duplicate empty message!]
[ Just for the archives... ]
[ More of a thumbs up to portupgrade than a reposting of the problem...]

Seems to work handily... for the time being anyway.

#portupgrade -P [ -i ] [port ] [2nd port ] [ grep lib somefileofports.dat ] 
once one has made a symlink to /usr/ports/packages/All [test first] making
it reference /var/cache/pkg [tested it here every which way first... ] 


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

Another pkg showstopper, breaking also portupgrade

[Jeffrey Bouquet via freebsd-ports]

pkg info pkg
pkg-1.4.99.0  (pkg-devel)

cd /usr/ports/ports-mgmt/pkg-devel
make deinstall
pkg-devel not installed, skipping
...
Wanted to revert to PKG because pkg-devel after deinstall
pkg fetch  zgv zziplib
pkg install  zgv zziplib
Installs the port, says it is the wrong architecture, says it failed to install
Changed the architecture in a file,  still fails
pkg info  zgv 
not installed
portupgrade zgv  fails to do anything nor graphics/zgv ...

So Portupgrade is silently failing
pkg is not-helpfully failing and not usable until...
Left with ports-only for now as far as installs.  
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Another pkg showstopper-- more information

[Jeffrey Bouquet via freebsd-ports]

Reverted to pkg, by build, and FORCE PKG REGISTER.

pkgs still cannot be installed.

Still stuck with ports ( however portupgrade -- non-packages -- seems to be
working with this pkg  pkg-devel downgrade )

(/ portmaster?  == no, cannot get 
handle, lock on database)  only.

..###...##...

Should pkg and/or pkg-devel be more thoroughly tested before
release into the tree?   No other pkg usually hints at similar pkg
system(s) breakage without a proven recovery/rollback procedure 
already documented...  similar to what portupgrade does with its
saving of shared libraries prior to upgrade of a port.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [CFT] pkg 1.4.0 rc2

[Jeffrey Bouquet via freebsd-ports]

On 12/06/14 04:40, Baptiste Daroussin wrote:
 Hi,

 We have released a new 1.4.0 rc2 version of pkg (available in
 ports-mgmt/pkg-devel) since first beta it has received tons of bug fixes and
 should be now way more reliable and able to handle ootb without mistakes
 upgrades like the gettext one and the perl one.

 All reported issues should have been fixed since.

 Please test that new version I would like to make it the final release if
 possible.

 Best regards,
 Bapt
The upgrade of pkg-devel went slightly more without problems.  Did not test
a direct deinstall/reinstall though.

OTOH pkg install xorriso xombrero still wants to remove w3m-img , install
w3m, guile 1.8, x246,  along with the reinstall of those two.

For which I n and
pkg delete xorriso xombrero
cd ../cache/pkg
pkg clean
pkg install xorr[tab] xomb[tab] to complete and install manually
Works, but a few more commands in the way.

I seem to have no guile installed (was using v2 for mcron) and libx264
installed.
Just ignoring guile for now probably.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: gtk20

[Jeffrey Bouquet via freebsd-ports]

On Sun, 11/23/14, Ajtim lum...@gmail.com wrote:

 Subject: gtk20
 

 The yesterdays update of gtk20 works but I have a problem
 with Firefox and 
 with GIMP:


I'm concerned also, but because of pkg install glib20 gtk20 has to be run like
this ... am waiting for a fix before or after the next thu/fri upgrade...
because it may take way too long to upgrade all the gnome packages piecemeal

pkg install glib20 gtk20
install glib20 gtk20 3rd... 5th ???
y
  proceeds to download the updates to the local cache 
  errors out for the install 

so then it is

pkg delete -f glib20 
pkg add glib20-#-txz
pkg delete -f gtk20
pkg add gtk20-#-txz

which is a workaround for the bug posted previously and to the forum... unless 
it
disappears in the next thu -- fri update sequence. 





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

pkg update pkg install abort traps today Thursday and an off-topic

[Jeffrey Bouquet via freebsd-ports]

pkg update
Downloaded new pkg database today.

pkg install   abort trap
every two of three pkg install ...  (only one has proceeded.)

This browser won't permit paste-ins, I've posted it in the forum in two threads 
(Xorg and Ports sections)

pkg-1.4.0a3

Q 2is this to be addressed to freebsd-ports@freebsd.org OR po...@freebsd.org
Q 3similar for p...@freebsd.org, is that instead or also 
freebsd-...@freeebsd.org

Q 4How is pkg-devel supposed to be installed to fix the OP topic if it 
cannot
  install once it has been deinstalled, no pkg remaining to qualify it 
for registering
  which I think happens before it installs

Q 5 Will we see a /var/db/pkg option in /pkg/ so that the above can be 
'switched over'
  a few weeks of the year during such problematic times for 
reliability, when and if
  we have the time to code one up and beta test it.  
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: pkg problem

[Jeffrey Bouquet via freebsd-ports]

On 11/20/14 04:19, Jeffrey Bouquet wrote:
 Only one port has not failed at pkg install port ... after today's
 update and
 also failed at deinstall pkg  install pkg-devel to try to fix it.

 [ Duplicate post, so I could post the error and this update.  ]


 Script started on Thu Nov 20 04:09:36 2014


 pkg --version
 1.4.0.beta2 # pkg-devel newly installed, did not fix the below.

 pkg install tk86
 Updating FreeBSD repository catalogue...
 FreeBSD repository is up-to-date.
 All repositories are up-to-date.

 Checking integrity...Assertion failed: (pkgdb_ensure_loaded(j-db, p2,
 PKG_LOAD_FILES|PKG_LOAD_DIRS) == EPKG_OK), function
 pkg_conflicts_need_conflict, file pkg_jobs_conflicts.c, line 211. Child
 process pid=41497 terminated abnormally: Abort trap: 6


 Script done on Thu Nov 20 04:10:25 2014

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

Re: Deleting ports distfiles

[Jeffrey Bouquet via freebsd-ports]

On Mon, 11/17/14, Warren Block wbl...@wonkity.com wrote:


 
 Actually, portmaster can do
 that also:
 portmaster -t -y
 -clean-distfiles
 ___
 Test first   I did not want the majority deleted...

#portsclean -DD -n | tee -a /gz_files
#sed -i bak 's.Delete \/usr\/ports\/distfiles\/..g'   /gz_files
. fifteen minutes on the web to find that line above escaping the path
# grep / /gz_files | less   # in another xterm, /bin/rm -rf the extra 
directories
# grep -v / /gz_files | grep bz2 | xargs -J % /bin/rm -iv %... tests it, 
check output
# ..-v %
 does the above
Repeat the immeditate two lines
above (-iv then -v ) for gz, -i zip, xz, 
(the latter I forgot BTW) and that should be most
of them. I deleted 500 files that way, so am done for the year.
.
Easier posting here than in the forum...
Pardon any typos.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Reducing the size of the ports tree (brainstorm v2)

[Jeffrey Bouquet via freebsd-ports]

On 11/07/14 10:32, Bartek Rutkowski wrote:
 On Fri, Nov 7, 2014 at 6:47 PM, Chris H bsd-li...@bsdforge.com wrote:
 On Fri, 7 Nov 2014 09:08:28 + Bartek Rutkowski ro...@freebsd.org wrote

 On Fri, Oct 31, 2014 at 6:56 PM, Baptiste Daroussin b...@freebsd.org 
 wrote:
 Hi all,

 tijl@ spotted an interesting point, distinfo and pkg-descr files files
 convenient are taking a lot of space for free, we can reduce the size of
 the while ports tree by a factor 2 by simply merging them into one of the
 other files (Makefile and/or pkg-plist) from my testing it really devides
 significantly the size of the tree.

 Problem is how to merge them if we want to.

 What we do not want to loose:
 - Easyness of parsing distinfo
 - Easyness to get informations about the description

 so far I have not been able to figure out a user friendly way

 Ideas I got so far only concerns pkg-descr:
 Adding an entry in the Makefile for the WWW:
 WWW= bla
 or an entry in the plist: @www http...

 for the description the Makefile is not suitable as multi line entry in
 Makefiles are painful
 Maybe a new keyword:
 @descr EOD
 mydesc
 in
 multiline
 EOD

 which could easily be added to the plist parser in pkg. But I'm do not find
 that very friendly in particular for make(1) to extract the data.

 Concerning the distinfo I have no idea.

 so this mail is a call of ideas :), if nothing nice ideas is found we will
 just do nothing here :)

 regards,
 Bapt
 At first I liked the idea, since I was wondering on my own if
 pkg-descr and distinfo couldnt be simply part of the Makefile. In vast
 majority of cases that would look good and wouldnt introduce too much
 content into existing Makefiles. There are ports like www/nginx or
 www/tengine that have enourmous distinfo files with number of entries
 that would ruin readability of their Makefiles, but so far I havent
 seen too many of these so I suppose they'd be the liveable drawbacks
 of new approach.

 However, after reading this discussion and some more tinkering about
 the idea I changed my mind - if the goal of current pkgports
 activities is to make the pkg the default way of installing packages
 and 'deprecate' ports when that happens,
 Aak! Seriously?! Eliminate ports? I _sincerely_ hope that isn't the
 intended result of the introduction of pkg(8). That would be a
 _horrible_ decision. For more reasons than I can list in a mailing
 list reply. Honestly. If this is true, has any real thought gone into
 the potential consequences resulting from this? We're not just talking
 about the affects on geeks, and hobbyists here. We're talking about
 Shops, and Businesses that create specific products, for specific needs,
 and chose *BSD for what at least _was_ the freedom, and amount of
 _choices_ it offered. Making it, by comparison, more _flexible_ than
 it's alternatives. You'll effectively eliminate that market, traveling
 in the direction you appear to be going.
 If what I understand you to be saying is true. It appears FreeBSD is
 simply looking to parrot Linux, and relinquish The power to serve.
 In exchange for competing for a strictly Desktop market. If true.
 This will mark a very dark year in history, for FreeBSD.

 Sincerely,
  Disappointed.
 I think we've a little  misunderstanding here. At no point I've said
 nor heard that ports are about to be eliminated. I did hovewer heard
 that the goal is to deprecate them, as in, encourage users to move to
 pkg entirely
Please explain [ not directed to THIS post,  but to the
THREAD maybe... ] the narrowing-of-choice encouragement reasons

I am trying triply to politely address the issues and apologize in
advance for any perceived disrespect to the points I am directly
replying to...
 , once pkg is a viable ports replacement,
Once upon a time /var/db/pkg and upstream .tbz served as a pkg..
that is, a tracking of ports, and a prebuilt subset of ports.  Nowhere did I
ever imagine that a replacment for /var/db/pkg would encourage the non
use, replacement, deprecation, discouragement, ...

Again, with apologies.

  and to make that
 a default way to install/maintain software on FreeBSD.
If that existed before portmaster, portupgrade  were written, how would they
have come into existence? 

How about a convenient and reliable ??   More below...
  At the end, it
 would be very hard to 'eliminate' ports, since we still have to
 generate the packages with something, dont we?
Spot on.
Not only that...  I always thought ports were FreeBSD's
strong point.  Maintainers, ... innovations... new scripts... new
categories...

  ;) Even said that, I
 could be completely wrong here, misunderstood someone else and so on,
 and by no means this discussion is a statement of what is going on to
 happen with ports/pkg oficially, so, to quote D. Adams: DON'T PANIC.
To reiterate, to me, this reducing the size method seems non-trivial,
and not without consequence. 
 from what I have read.

However, into the thread have appeared other alarming concepts... 

Re: Reducing the size of the ports tree (brainstorm v2)

[Jeffrey Bouquet via freebsd-ports]

1... attachment
2 quoted
3... reply Sorry for the formatting... browser crashes with attachments 
often and
   webmail needs a revamp... 



+
WebService::Bloglines priovides you an Object Oriented interface for Bloglines
Web Services (BWS). It currently supports Notifier API and Sync API.

WWW: http://search.cpan.org/dist/WebService-Bloglines/
./p5-WebService-Bloglines
+
ldap-abook provides a web interface for adding, removing and modifying
LDAP addressbook records.  These addressbook records can be used with
mail clients such as Sylpheed, Microsoft Outlook and probably Netscape
and Mozilla.

Attributes such as address details, date of birth and phonelist membership
are also possible, allowing other applications to feed off the same
database.

WWW: http://ldap-abook.sourceforge.net/
./p5-ldap-abook
+
mod_transform is a filter module that allows Apache 2.0 to do dynamic XSL
Transformations on either static XML documents, or XML documents generated
from another Apache module or CGI program.

This module originated from mod_xml_gnome_xslt by WebThing.

WWW: http://www.outoforder.cc/projects/apache/mod_transform/

- Stan
s...@stormier.net
./mod_transform
+
The Apache HTTP Server Project is an effort to develop and maintain an
open-source HTTP server for various modern desktop and server operating
systems, such as UNIX and Windows NT. The goal of this project is to
provide a secure, efficient and extensible server which provides HTTP
services in sync with the current HTTP standards.
The 2.x branch of Apache Web Server includes several improvements like
threading, use of APR, native IPv6 and SSL support, and many more.

WWW: http://httpd.apache.org/
./apache21
+
AutoIndex is a PHP script that makes a table that lists the files in a
directory, and lets users access the files and subdirectories. It includes
searching, icons for each file type, an admin panel, uploads, access logging,
file descriptions, and more. Designed to work with PHP 4.x.

WWW: http://autoindex.sourceforge.net/

- DanGer
dan...@wilbury.sk
./autoindex
+
AutoIndex is a PHP script that makes a table that lists the files in a
directory, and lets users access the files and subdirectories. It includes
searching, icons for each file type, an admin panel, uploads, access logging,
file descriptions, and more. Designed to work with PHP 5.x.

WWW: http://autoindex.sourceforge.net/

- DanGer
dan...@wilbury.sk
./autoindex2
+
Inside Systems Mail is a web mail client that makes heavy use of
JS, CSS, and DOM to create a snappy, easily configurable and
familiar mail interface.

WWW: http://www.insidesystems.net/projects/project.php?projectid=4

- Kelley Reynolds
kel...@insidesystems.net
./ismail
+
Mozilla Firebird is a Web, FTP and gopher browser branched from Mozilla.  It
does not include an HTML editor, e-mail user agent, IRC client, or news reader.

This is a pre-compiled Linux/i386 version, able to run plugins from that
platform.  This port is compatible with the Flash plugin from
ports/www/linux-flashplugin6/ and with the Java plugin from
ports/java/linux-blackdown-jdk14/.

WWW:  http://mozilla.org/projects/firebird/
./linux-firefox
+
Provides an interface to easily send hidden files or any arbitrary data to
HTTP clients. HTTP_Download can gain its data from variables, files or
stream resources.

It features:
- Basic caching capabilities
- Basic throttling mechanism
- On-the-fly gzip-compression
- Ranges (partial downloads and resuming)
- Delivery of on-the-fly generated archives through Archive_Tar and
Archive_Zip

WWW: http://pear.php.net/package/HTTP_Download/
./pear-HTTP_Download
+


On Tue, 11/4/14, Adam Vande More amvandem...@gmail.com wrote:

 Subject: Re: Reducing the size of the ports tree (brainstorm v2)
 To: Matthias Andree matthias.and...@gmx.de
 Cc: Tijl Coosemans t...@freebsd.org, FreeBSD Ports 
freebsd-ports@freebsd.org
 Date: Tuesday, November 4, 2014, 5:59 PM
 
 On Tue, Nov 4, 2014 at
 5:39 PM, Matthias Andree matthias.and...@gmx.de
 wrote:
 
  Am
 03.11.2014 um 21:24 schrieb Tijl Coosemans:
 
   Other tools
 won't change anything.  It's the file system that
 would
   have to change which is not
 going to happen.  When the ports tree was
   created disks were much smaller and
 file systems were better (still not
 
  good) at storing small files.  Today disks are much
 bigger and file
   systems have
 adapted to that.  Now it's time for the ports tree to
 adapt.


  and go away  in a manner of speaking...

Re: Reducing the size of the ports tree (brainstorm v2)

[Jeffrey Bouquet via freebsd-ports]

On 11/05/14 13:30, Mark Felder wrote:

 On Wed, Nov 5, 2014, at 10:16, Roger Marquis wrote:
 Was a time when FreeBSD was believed to be a more stable and compatible
 platform than Linux.  Of course all that backwards compatibility was
 thrown out the window with this year's make and pkg updates, which made
 management at my business much more receptive to the linux admin's calls
 for linux-everywhere, but this is a matter for the community to decide.

 FreeBSD spent 20 years not changing and you know what we got for it? An
 ugly mess. Please keep in mind that nobody is changing the core OS.
 They're simply bringing our package mangement from the 1990s to the
 2000s, and hopefully after that dust settles we can move to the 2010s.
 Yes, through this transition it's painful if you are used to never
 having to touch your custom ports. The change important and the benefits
 are far-reaching.

You are grouping two distinct changes together, and disparaging,
non-specifically, the
old ports (package)  system which served here, well, 2004 January to the
present day.
I sent another email, detailing in which, many  one files in the ports
tree may be a bad idea.

Having transitioned to pkg successfully on one machine,  that I can
still not upgrade
pkg  pkg without hacks, and halfway on another, on which pkg2ng did not
work, and
is sort of in limbo ( an inaccurate pkg database, and buggy operation of
a few pkg
commands, and out of the blue segmentation faults ) I see pkg as more
convenient BUT
less reliable.  

Specifically here,
An ugly mess not
1990s 2000s not reliable enough yet
benefits far-reaching  maybe in the future.  Saving time here but
with uncertainty.


 I don't care how good of a FreeBSD admin anyone is. You can't tell me
 you won't find any of the following instances on your servers before
 pkgng:

 - duplicate packages registered in pkg_info
I could simply /bin/rm -rf  the duplicate subdirectory.

 - leftover files *everywhere*. find /usr/local -type f -print0 | xargs
 -0 -n50 pkg_which | grep not found
A small price to pay for stability.  And what if pkg which (sqlite) is
more prone to
breakage, obsolete libraries, wrong compiler  libmap...  vs pkg_which
which
could be resurrected as a backup... I hope continually

 - broken binaries discovered via pkg_libchk
One can easily have that now,  pkg upgrading to ruby20 default when
ruby19 is still
installed or something...  or my limited experience is not the norm


 This is disgusting. You might as well just be extracting tarballs and
 not using a package manager because the only benefit you're gaining from
 the old ports tree is the automation of *building* and *installing*.
Portmaster handily handled the switches -d -B -P -i -g  (ports unless
packages upstream)
Why disparage that?  Pure packages is not for everyone, and that in
itself AFAIK is a
feature not a bug of FreeBSD... 


 Here's the lifecycle of a typical pre-pkgng server:

 1) Install FreeBSD
 2) Install your ports/packages
 3) Server is in production
 4) Attempt to update ports/packages
 5) Disaster is now waiting to happen
3a... Production?  update on a second machine, roll out to the main one.
No disaster. Less
preplanning or experience, and your scenario may be right, but numerous
blogs of
administering servers I've read over the years, and in FreeBSD books,
paint an easier and
more seamless sequence of events with each upgrade, most of each not
being abstracted
away from the command line, but line-by-line expertly managed.

 Every time you need to update you might as well rm -rf /usr/local and
 start over. 
I upgraded 5  5  5  6  7  8  9  and instances within each one,
losing mutiple
hard drives, but files in /usr/local still exist from 2004...
 Some ports even barfed all over the base system, so
 reinstalling wouldn't be a bad idea either. 
I read reinstalling not a bad idea, but only in the problematic case.

 In fact, that was often the
 solution where I used to work -- wait until a serious enough
 vulnerability is affecting the server and then reinstall from scratch
 with the latest RELEASE.



 For most of us end-users it doesn't matter as we use portsnap
 (and update speed really isn't an issue).

 The goal is to make pkg the norm and ports the very rare exception.
Why 'very rare?  '  I always thought that they were to work in tandem. 
Isn't tweaking of
ports on one's machine consistent with knowing the ins and outs of all
the ports as well
as package workings? Make targets?  etc.

  This
 will increase consistency, lower false bug reports, and greatly
 ease/increase adoption by lowering the barriers


But this here you have included both pkg (not yet seamless or as

reliable in my opinion) and the new scheme of abstracting away the
information in
the smaller files.  I see more bug reports from pkg (from here for
instance)...   It seems
to early to call the above as a certainty. 


Apologies if I am sounding way critical upon wishing to simply advocate
caution on any

Re: Reducing the size of the ports tree (brainstorm v2)

[Jeffrey Bouquet via freebsd-ports]

On 11/05/14 16:42, Mark Felder wrote:

 On Wed, Nov 5, 2014, at 18:01, Jeffrey Bouquet wrote:
 On 11/05/14 13:30, Mark Felder wrote:
 - duplicate packages registered in pkg_info
 I could simply /bin/rm -rf  the duplicate subdirectory.

 Your're treating the symptom not the problem. This solves nothing and
 leaves potentially vulnerable, untracked libraries and binaries on your
 system and you can't be sure which one future port builds are linking
 against. 
Explain please how the problem of one erroneous directory among
thousands means they are
all removed and hidden behind an SQL I know nothing about and which may
segfault.  (Just wishing
pkg recodes a switch to put them back maybe as an optional readout after
each install, if that
does not in and of itself segfault...)   We are trading one
unreliability for another maybe?

 - leftover files *everywhere*. find /usr/local -type f -print0 | xargs
 -0 -n50 pkg_which | grep not found
 A small price to pay for stability.  And what if pkg which (sqlite) is
 more prone to
 breakage, obsolete libraries, wrong compiler  libmap...  vs pkg_which
 which
 could be resurrected as a backup... I hope continually

 I don't understand which faults you're trying to point out here.
 Breakage and obsolete libraries? pkg-static
What if pkg-static does not work?  I deinstalled seven ports to save
space, and pkg-static install -f port wanted to
reinstall them right back.  csound for a non-audio non-multimedia port
for example...  With the old system I could
debug it with pipes.  I've no SQL experience, so that v9 is stagnant for
now, with a local.sqlite too large to email
anywhere...

  
 - broken binaries discovered via pkg_libchk
 One can easily have that now,  pkg upgrading to ruby20 default when
 ruby19 is still
 installed or something...  or my limited experience is not the norm

 No you can't. pkgng doesn't install packages without their dependencies.
 This would all be fixed by the next package set.

No temporary interim breakage?

 This is disgusting. You might as well just be extracting tarballs and
 not using a package manager because the only benefit you're gaining from
 the old ports tree is the automation of *building* and *installing*.
 Portmaster handily handled the switches -d -B -P -i -g  (ports unless
 packages upstream)
 Why disparage that?  Pure packages is not for everyone, and that in
 itself AFAIK is a
 feature not a bug of FreeBSD... 

 Portmaster is not part of FreeBSD, and why are we relying on a third
 party tool to fix bad design?
  
Explain bad design?  Portmaster, which worked well, hours on end at the
end of  a pipe with
xargs?  Or the ports tree again?

 Here's the lifecycle of a typical pre-pkgng server:

 1) Install FreeBSD
 2) Install your ports/packages
 3) Server is in production
 4) Attempt to update ports/packages
 5) Disaster is now waiting to happen
 3a... Production?  update on a second machine, roll out to the main one.
 No disaster.
 But how do you get the updated ports/packages onto the production server
 without building them? I surely hope you're not building and installing
 them on another server and manually copying the files/libraries over. If
 you used a package server (tinderbox) that same concept is what we're
 recommending.
Manually copying the files over, or better mount -o union and
portmaster on the
next machine found them already fetched.  Tinderbox beyond my expertise
and more
expensive than a simple thumbdrive

 Every time you need to update you might as well rm -rf /usr/local and
 start over. 
 I upgraded 5  5  5  6  7  8  9  and instances within each one,
 losing mutiple
 hard drives, but files in /usr/local still exist from 2004...
 This is terrifying for reasons previously explained.
This is not a server.  No worries.
 Some ports even barfed all over the base system, so
 reinstalling wouldn't be a bad idea either. 
 I read reinstalling not a bad idea, but only in the problematic case.

 Untracked libraries and executables all over your OS is a problematic
 case.

I've pipes to take care of them.
 The goal is to make pkg the norm and ports the very rare exception.
 Why 'very rare?  '  I always thought that they were to work in tandem. 
 Isn't tweaking of
 ports on one's machine consistent with knowing the ins and outs of all
 the ports as well
 as package workings? Make targets?  etc.

 Mixing packages and ports is *not* supported and never has been. This is
 another cause of unnecessary bug reports.
Elaborate?   If it can happen, does happen, works, is advantageous,
and does not mean bug reports...  I do not ever recall seeing a
specific warning that it is not supported, just that it may be better to
not mix them.   Not supported would seem to indicate many users should
go to other operating systems...

 The only tweaking you should be doing is changing port build options,
 and they'll be available via (sub)packages according to the current
 roadmap. Only in rare circumstances should you need to manually build

RE: Why is make installing

[Jeffrey Bouquet via freebsd-ports]

I wonder if that has anything with the
child process terminated abnrmally I saw when starting a 
make build in most any, or a number of, port(s) recently...  on another v9 
machine.   
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

RE: RE: reducing the size of the ports tree

[Jeffrey Bouquet via freebsd-ports]

Not initially welcoming this new effort... 
explanation and other PKG problems taking precedence...


I've a few scripts which use the smaller files, and have used them
extensively in pipes.  Syntax within the Makefile would make those
counterintuitive.I would wonder also if it would break port
infrastructure like the Mk and Tools and make search and
portsearch (etc -- ports )... essentially breaking more things than
would be solved.  Indeed, I've many ideas for MORE small
files for people crafting shell scripts that would be of more use
down the road, and incorporated someday into additional port tools,
portmasters, portupgrades, etc...

So as far as this particular suggestion, maybe if someone wants it
bad enough one should build a prototype and test locally several
years with many ports and upgrades to determine what it breaks... and
how to write new tools.

But I conjecture that effort would be better spent with PR backlogs,
fixing pkg2ng (which fails here on one machine ) etc... and
making pkg more robust... (complete recovery if the database is
hosed, with a something local_sqlite_hosed_reuild_sh.sh etc etc
And the documentation.  Many many more examples of everyday usage
over the course of a year and UPDATING scenarious would be 
appreciated...


and also streamlining pkg so it works better on  low power machines with
many ports installed.  Including less segfaults...

As an aside, I am now on a machine which never had the problem before,
after a failed pkg2ng conversion, 

A... pkg install -f nettle
   wants to install csound!   what file is telling it that?  The database ???
... and seven others I had just deinstalled

B... make install ( proceeds with Child process terminated abnomally...
segmentation fault) before the install.  Not known if anything was running
beforehand.  Not problems with the install.  But it keeps occuring...
What process?  Something in the background wanting that nettle 
csound dependency?  Pkg working before the make command? Part
of the make command infrastructure now more buggy?

Thankfully that machine is not the primary one here, and all the programs
installed still work on it as far as I know. But its registration data is 
not exact and pkg-devel as installed on it could be debugged more... as
well as pkg2ng retested to work on v9 more precisely...  It failed three times
to convert that machine.  (not installed unless desinstalling direct from
the port, so could not upgrade.. or pkg info the port)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

pkg install trouble again

[Jeffrey Bouquet via freebsd-ports]

Continuing with the latest pkg2ng failure to actually convert  import another
local.sqlite  pipe to a pkg install [   ] -f -y ...

I deleted a few ports to save space.  Then,
Continuing with the reinstall of not converted but installed reinstalls ...

The following bug persists after a reboot:



pkg install -f nettle(securty/nettle)

New packages to be INSTALLED (i HAD JUST removed these)

gcc49
gutenprint-base
openjdk
mysql55-client
csound
libgda4

Installed packages to be REINSTALLED

nettle...

A few others down the list in n* did not demand reinstalls... so the sql code 
or some file
somewhere is buggy and can be fixed I hope...   

[
Along with the pkg2ng code which started it all as per the previous emails (v9) 
which maybe
only needs a prerequisite file in the environment, an environment variable, or 
is incomplete
and/or buggy... in the v9 upgrades...  I have no idea.  
]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: pkg2ng question -- fails to show converted pkgs in stats

[Jeffrey Bouquet via freebsd-ports]

TOP POSTED SORRY
Moot point on this machine, vs others , probably; also, part of the message 
below was wrong.
they are only installed if desinstalling from the port subdirectory and not 
thru package IIRC
WORKAROUND:
meanwhile I copied a local.sqlite from a more recent machine to the failed 
pkg2ng one

and 
pkg delete -n -g a* | grep -v  requested | grep -v  operation | grep -v REMO| 
grep -v Reinstall

| xargs -J % pkg install -f %

dry runs the a* reinstalls, and -y after -f actually performs...  
takes much  longer though ,  tuning for disk space, ... unwanted reinstalls... 
etc


On Thu, 10/30/14, Jeffrey Bouquet via freebsd-pkg freebsd-...@freebsd.org 
wrote:

 Subject: pkg2ng question -- fails to show converted pkgs in stats
 To: p...@freebsd.org
 Date: Thursday, October 30, 2014, 5:48 AM
 
 v9 
 pkg2ng converts, the local.sqlite is huge...
 
 but pkg stats ... no installed packages.
 
 If one wants to desintall them, they are installed... if one
 wants to install them, they
 are not installed yet, whereas they were converted so
 are...
 
 Some other command to run maybe?  Or pkg2ng is not just
 not reliable yet?
 ___
 freebsd-...@freebsd.org
 mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-pkg
 To unsubscribe, send any mail to freebsd-pkg-unsubscr...@freebsd.org
 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

pkg-devel-1.4.0-a3 works good so far

[Jeffrey Bouquet via freebsd-ports]

Built with clang... none of the problems (so far) from the previous builds 
appear to exist from
initial testing of pkg and of a port install.
v9 
had to use -DFORCE_PKG_REGISTER though...
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Re: custom gcc article outdated?

[Jeffrey Bouquet via freebsd-ports]

 Subject: custom gcc article outdated?
  
 Specifically, is this form still understood:
 
 *quote*
 Add the following lines to the /etc/make.conf file (or
 modify appropriately):
 
 if !empty(.CURDIR:M/usr/ports/*) 
 exists(/usr/local/bin/gcc44)
 CC=gcc44
 CXX=g++44
 CPP=cpp44
 .endif
 
 *end quote*
 
 Thanks
 
 Anton
 

..
RE gcc, I am read the link in the above email, and no answer to what fixes the 
chrome
error 
usr/local/lib/gcc47/libstdc++.so.6: version GLIBCXX_3.4.18 required by 
/usr/local/share/chromium/chrome
not found

I deinstalled and reinstalled *all* of gcc to try and fix it, and toyed with
libmap.conf.   If a fix is found with the latter rather than with ports,
I could write it into the libmap.conf here as a reference.

Additionally, is there some meta documentation about all gcc's 
versions to read, or some line in a file, which shows the minimum]
preferred one two or three GCC's to have installed for less trouble
building ports etc.

Thanks 

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

Pkg regression (1); also a feature request (SEVERAL)

[Jeffrey Bouquet via freebsd-ports]

package install this that this that seems to complete most of the installs, but 
if one of the ports has a conflict 
then the upgrades are not registered.  For example, todays conflict between 
py-pillow and py-imaging resulted
in  (that is, despite of the conflict...) two successful upgrades 

mbuffer --version #   20140302
pkg info ... ... mbuffer   # 
mbuffer-2013.02.20_1  # falsely shows the upgrade as not having been done.

thunderbird --version   # 31.1.2
pkg info ... ... thunderbird  
thunderbird-31.1.0_1  # falsely shows the upgrade as not having been 
done.

Each package was installed by a sequence of five or four ports with ended with 
a failure to install py27-imaging because
of the py27-pillow having been installed. 

This almost never happened the legacy way, or could be fixed or discovered by 
portmaster or portupgrade or pkgdb -F etc
So it seems a serious regression that should be prioritized.

.

The feature request involves pkg upgrade  which is now...

  Ports to be installed   (no particular alphabetical order) 
  Ports to be upgraded
  Ports to be reinstalled (dependency changed)

I'd like to see this more at... (appears to be an improvement from here...) 

  Part 1.  New installs .  Skip this part and proceed to part 2?  y/n
  Ports to be installed
PORT because of PORT listed below
PORT because of PORT listed below# and alphabetical
  Ports to be upgraded
PORT resulitng in new install PORT
PORT resulting in new install PORT
  Ports to be upgraded (dependencies changed)# and alphabetical
   PORT resulting in new install PORT
   PORT resulting in new install PORT

  Part 2.  Do this step now?  y/n
Ports to be upgraded# alphabetical 
  PORT
  PORT
Ports to be reinstalled   # alphabetical
   PORT
   PORT
   

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

Way to debug/fix errors with python ports such as these [py-paragrep]

[Jeffrey Bouquet via freebsd-ports]

   
Traceback (most recent call last):
  File /usr/local/bin/paragrep, line 5, in module
from pkg_resources import load_entry_point
  File /usr/local/lib/python2.7/site-packages/pkg_resources.py, line 2837, in 
module
working_set = WorkingSet._build_master()
  File /usr/local/lib/python2.7/site-packages/pkg_resources.py, line 449, in 
_build_master
ws.require(__requires__)
  File /usr/local/lib/python2.7/site-packages/pkg_resources.py, line 742, in 
require
needed = self.resolve(parse_requirements(requirements))
  File /usr/local/lib/python2.7/site-packages/pkg_resources.py, line 639, in 
resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: grizzled-python=1.0

Methodology or wrapper program or clue as to what to reinstall ???


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

libxul.so rebuilt, still a version error.

[Jeffrey Bouquet via freebsd-ports]

/usr/local/lib/firefox/libxul.so
/usr/local/lib/libxul//libxul.so
/usr/local/lib/libxul/sdk/lib/libxul.so
/usr/local/lib/seamonkey/libxul.so
/usr/local/lib/thunderbird/libxul.so

Rebuilt libxul.  

Seamonkey, firefox would not start still:
XPCOMGlueLoad Error for file ... libxul.so:
/usr/lib/libstdc++.so.6: version GLIBCXX_3.4.15 required by 
/usr/local/lib/seamonkey/libxul.so not found
Couldn't load XPCOM

IIRC that persists even after copying the new libxul to the seamonkey location.
That leaves one browser left, and not time really to proceed further without a 
direction in which to test. 

Possible maybe even to download from a pkg repository and extract a new libxul 
build that would work, even if
not using pkg yet?  Or some procedure I could write into a port-rebuild-hint 
file I've updated here for future use
if it is fixable not, but might recur.

Thanks.  

J. Bouquet 

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

Re: libxul.so rebuilt, still a version error.

[Jeffrey Bouquet via freebsd-ports]

Replies at the bottom,  in a paragraph or two...


On Wed, 7/2/14, Robert Huff roberth...@rcn.com wrote:

 Subject: Re: libxul.so rebuilt, still a version error.
 To: po...@freebsd.org
 Date: Wednesday, July 2, 2014, 8:38 AM
 
 J Bouqet writes:
 
    /usr/local/lib/firefox/libxul.so
    /usr/local/lib/libxul//libxul.so
    /usr/local/lib/libxul/sdk/lib/libxul.so
    /usr/local/lib/seamonkey/libxul.so
    /usr/local/lib/thunderbird/libxul.so
 
    Rebuilt libxul.
 
    IIRC that persists even after copying the new
 libxul to the
    seamonkey location.
 
     Sometime back I was told while doing this
 is unlikely to damage 
 anything, it is in fact The Wrong Answer(tm).
     There are specific reasons why (most)
 Mozilla products build their own 
 versions of libxul, even when the supposedly suitable
 standalone lib is 
 available.  For more information, talk to the folks on
 gecko@.
 
     Which brings up the obvious
 question:  you rebuilt standalone libxul. 
 Did you also rebuild Firefox/Seamonkey/Thunderbird/etc.?
 
 
     Respectfully,
 
 
            
 Robert Huff
 ___
 freebsd-ports@freebsd.org
 mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
 
..

Seamonkey has been rebuilt and fixed.  Starting thunderbird rebuild...

To my recollection, I removed some stale older compat/pkg binaries which caused
the inadvertant rebuild of libxul, in a attempt to fix an mpv segfault (which 
does not
newly build.) 
It turns out that rebuilding libxul often needs a new build (here) of 
seamonkey, 
firefox, and thunderbird...  Some sites only work here on a specific browser or 
two so
it is not non-urgent nor trivial.  I was hoping some LD_PRELOAD  construct or 
env
variable or extraction of an upstream .so file could make a few minutes work of 
a few
hours... and be noted for future reference, for those times it is more urgent.

As a side note, I wonder if the forum having problems with ports and 
workarounds as
a subsection (www ... devel ... lang... ) could put these list inquires into 
something more
useful to FreeBSD users, as the forum common usage, unless I am mistaken, is 
more
user-friendly, a more recent development, etc than the mailing list(s). 

Now that I've a few persons attention, I learned this CLI this week, and had 
been searching for
something that worked similarly for years.  Thanks to a reply this week at 
freebsd-questions.
#for F in www/dillo2 girara ; do { portmaster -d -B -P -i -g --update-if-newer 
lookat $F}; done; echo PMVR
('lookat' included because a port more-than-one is necc for portmaster to 
continue proceeding in this CLI)
(PMVR so one can search history for the specific CLI if one has forgotten it, 
one can put PMVR on the monitor or something)
and one to try debugging mpv
ldd /usr/local/bin/mpv | awk '{print $3}' | xargs -J % ldd % | less 


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

docbook error persisting

[Jeffrey Bouquet via freebsd-ports]

I found a PR which was closed with the same error (Its originator had fixed it 
by reinstalling all ports.)
..
This persists in dbus, po4a, etc and I reinstalled exactly as UPDATING all 
docbook, as well as 
a fix someone recently found for it, to the extent it was described.
I'm guessing... the UPDATING docbook leaves out an edge-case step; and/or the 
error message is too
terse at the xmlto (etc) error lines, etc etc.

I don't consider it urgent here, but would waste time fixing it without 
probable satisfactory outcome.  So
I'm wondering if anyone can investigate furtther and/or knows a workaround, 
even manually copying a
file once, somewhere, that satisfies the parsing error(s) and/or loading errors 
and/or makes them more
precise as to why they occur, a permanent fix, etc...   even removing a minor 
branch of the /usr/local tree before
reinstalling all suggested docbook entries. 
..


then apply 'msggrep',
then convert back to UTF-8 using 'msgconv'.
file:///usr/local/share/xml/catalog.ports:1: parser error : Start tag expected, 
'' not found
PUBLIC -//OASIS//DTD Entity Resolution XML Catalog V1.0//EN http://www.oasis-
^
I/O error : Attempt to load network entity 
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
warning: failed to load external entity 
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl;
cannot parse 
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
Died at Po4aBuilder.pm line 267.
*** [do-build] Error code 4

Stop in /usr/ports/textproc/po4a.

Script done on Sun May 25 12:36:42 2014

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

Build error (somehow can't post the the ports list..is Bcc for now)

[Jeffrey Bouquet]

po4a, dbus, others...
A six-line error..., not new but has persistently broken ports.
I've rebuilt relevant textproc ports...
always involves external entity


file:///usr/local/share/xml/docbook/catalog:1: parser error : Start tag 
expected, '' not found
CATALOG /usr/local/share/xml/xmlcharent/catalog
^
file:///usr/local/share/xml/catalog.ports:1: parser error : Start tag expected, 
'' not found
PUBLIC -//OASIS//DTD Entity Resolution XML Catalog V1.0//EN http://www.oasis-
^
I/O error : Attempt to load network entity 
http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd
warning: failed to load external entity 
http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd;
validity error : Could not load the external subset 
http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd;
Document /usr/ports/devel/dbus/work/dbus-1.8.0/doc/dbus-cleanup-sockets.1.xml 
does not validate
gmake[2]: *** [dbus-cleanup-sockets.1] Error 13

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

Fw: Re: FreeBSD ports which are currently scheduled for deletion

[Jeffrey Bouquet]

Third attempt to send to the list ( a forwarding of a saved SENT message.)
However another question
In the make.conf there is WITH_NEW_XORG
but I've not the vt(9) driver.

UPDATING is not clear (today 4 16) enough as to wheter WITH_NEW_XORG 
should remain, or be replaced with WITHOUT before updating DRI since I've not
a 9-STABLE rebuilt since its introduction probably.

Questions below remain.
Apologizing for top posting, but the bottom posting does not appear at the list 
yet.
Glitch somewhere.

Don't know if the email arriving is more important than the questions in the 
email or not...

--- On Tue, 4/15/14, Jeffrey Bouquet jeffreybouq...@yahoo.com wrote:

 From: Jeffrey Bouquet jeffreybouq...@yahoo.com
 Subject: Re: FreeBSD ports which are currently scheduled for deletion
 To: ports list freebsd-ports@freebsd.org
 Date: Tuesday, April 15, 2014, 6:16 PM
 
 On Sun, 4/13/14, Jeffrey Bouquet jeffreybouq...@yahoo.com
 wrote:
 
  Subject: Re: FreeBSD ports which are currently scheduled
 for deletion
  To: freebsd-ports@freebsd.org
  Date: Sunday, April 13, 2014, 11:45 AM
  
   
   On 4/13/2014 17:46, Matthew Rezny
   wrote:
  
    On this list I see cfv, which I've used for
   years, marked just because
    it's
    not maintained. It works great, it needs no
   changes. 
  
  
    I'm not officially a maintainer on any ports for a
  few
   reasons. I have other 
    areas where I consider spending my time more
  valuable,
   but if I have to waste 
    it on port maintenance, I'll try to do so in the
 most
   efficient way. 
   
   Well, you basically said you're more important than
  anybody
   that
   regularly reads this list, so good luck with that tact.
  
 ...I
  regularly
  
 read
  this list
  
 .and
  also
  
 ..have
  not the
  
 ...experience
  or time
   So you should become a committer.
    
   Try submitting the patches, including staging and
 assuming
   maintainership (and then honestly be the maintainer). 
   
    Staging is not an opt-in feature so as
   harsh as it is to
   say
   
   This indicates that you haven't been paying attention. 
   
   It's not a goal to have the most
   ports possible; 
   
  ...Maybe take
  changes to a 
  subsection of the forum? I've posted there...
  
  A new subsection group: ports
  X11...
  WWW...
  DEVEL...
  maybe one DELETIONS ( a sticky or subsection)
  and/or PENDING DELETIONS ... and/or
  and deleted ports could be bought back again for those
  who find them useful, even if someone was reading about
  a years-ago removal.
  
  Pardiff (diffp ) comes to mind (just removed this week)
  I use the diffp binary for diffing ports-to-upgrade pipe
  results between days (diffp portlist.MON portlist.TUE)
  I suppose mergemaster.sh could even be updated to
  be more similar to the output of diffp.
  .
  gfontview... 
  ...
  
  Just puttting that idea onto the forum expansion, which
  maybe could solve problems quicker than PR's.
  For instance, as of now,
  textproc/po4a
  x11/roxterm
  devel/dconf
  
  all fail to build failed to load exteral entity 
 http://docbook.sourceforge.net/release/
  xsl/current/manpages/docbook.xsl  
  
  and maybe if the forum had been expanded, threads (dconf
  po4a roxterm) would
  have been started/updated explaining the fix, if anyone
 knew
  it. 
  
 
 ...
 Lost post en route to the list [ addressee maybe
 incomplete]   Re-sending from the SENT
 folder. 
 Sorry for the delay...
 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

po4a build failures (RE a thread) and an idea ; also new XORG question

[Jeffrey Bouquet]

Third attempt to send to the list ( a forwarding of a saved SENT message.)
However another question
In the make.conf there is WITH_NEW_XORG
but I've not the vt(9) driver.

UPDATING is not clear (today 4 16) enough as to wheter WITH_NEW_XORG 
should remain, or be replaced with WITHOUT before updating DRI since I've not
a 9-STABLE rebuilt since its introduction probably.

Questions below remain.
Apologizing for top posting, but the bottom posting does not appear at the list 
yet.
Glitch somewhere.

Don't know if the email arriving is more important than the questions in the 
email or not...

--- On Tue, 4/15/14, Jeffrey Bouquet jeffreybouq...@yahoo.com wrote:

 From: Jeffrey Bouquet jeffreybouq...@yahoo.com
 Subject: Re: FreeBSD ports which are currently scheduled for deletion
 To: ports list freebsd-ports@freebsd.org
 Date: Tuesday, April 15, 2014, 6:16 PM
 
 On Sun, 4/13/14, Jeffrey Bouquet jeffreybouq...@yahoo.com
 wrote:
 
  Subject: Re: FreeBSD ports which are currently scheduled
 for deletion
  To: freebsd-ports@freebsd.org
  Date: Sunday, April 13, 2014, 11:45 AM
  
   
   On 4/13/2014 17:46, Matthew Rezny
   wrote:
  
    On this list I see cfv, which I've used for
   years, marked just because
    it's
    not maintained. It works great, it needs no
   changes. 
  
  
    I'm not officially a maintainer on any ports for a
  few
   reasons. I have other 
    areas where I consider spending my time more
  valuable,
   but if I have to waste 
    it on port maintenance, I'll try to do so in the
 most
   efficient way. 
   
   Well, you basically said you're more important than
  anybody
   that
   regularly reads this list, so good luck with that tact.
  
 ...I
  regularly
  
read
  this list
  
.and
  also
  
..have
  not the
  
...experience
  or time
   So you should become a committer.
    
   Try submitting the patches, including staging and
 assuming
   maintainership (and then honestly be the maintainer). 
   
    Staging is not an opt-in feature so as
   harsh as it is to
   say
   
   This indicates that you haven't been paying attention. 
   
   It's not a goal to have the most
   ports possible; 
   
  ...Maybe take
  changes to a 
  subsection of the forum? I've posted there...
  
  A new subsection group: ports
  X11...
  WWW...
  DEVEL...
  maybe one DELETIONS ( a sticky or subsection)
  and/or PENDING DELETIONS ... and/or
  and deleted ports could be bought back again for those
  who find them useful, even if someone was reading about
  a years-ago removal.
  
  Pardiff (diffp ) comes to mind (just removed this week)
  I use the diffp binary for diffing ports-to-upgrade pipe
  results between days (diffp portlist.MON portlist.TUE)
  I suppose mergemaster.sh could even be updated to
  be more similar to the output of diffp.
  .
  gfontview... 
  ...
  
  Just puttting that idea onto the forum expansion, which
  maybe could solve problems quicker than PR's.
  For instance, as of now,
  textproc/po4a
  x11/roxterm
  devel/dconf
  
  all fail to build failed to load exteral entity 
http://docbook.sourceforge.net/release/
  xsl/current/manpages/docbook.xsl  
  
  and maybe if the forum had been expanded, threads (dconf
  po4a roxterm) would
  have been started/updated explaining the fix, if anyone
 knew
  it. 
  
 
 ...
 Lost post en route to the list [ addressee maybe
 incomplete]   Re-sending from the SENT
 folder. 
 Sorry for the delay...


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

Re: FreeBSD ports which are currently scheduled for deletion

[Jeffrey Bouquet]

On Sun, 4/13/14, Jeffrey Bouquet jeffreybouq...@yahoo.com wrote:

 Subject: Re: FreeBSD ports which are currently scheduled for deletion
 To: freebsd-ports@freebsd.org
 Date: Sunday, April 13, 2014, 11:45 AM
 
  
  On 4/13/2014 17:46, Matthew Rezny
  wrote:
 
   On this list I see cfv, which I've used for
  years, marked just because
   it's
   not maintained. It works great, it needs no
  changes. 
 
 
   I'm not officially a maintainer on any ports for a
 few
  reasons. I have other 
   areas where I consider spending my time more
 valuable,
  but if I have to waste 
   it on port maintenance, I'll try to do so in the most
  efficient way. 
  
  Well, you basically said you're more important than
 anybody
  that
  regularly reads this list, so good luck with that tact.
  
...I
 regularly
 
read
 this list
 
.and
 also
 
..have
 not the
 
...experience
 or time
  So you should become a committer.
   
  Try submitting the patches, including staging and assuming
  maintainership (and then honestly be the maintainer). 
  
   Staging is not an opt-in feature so as
  harsh as it is to
  say
  
  This indicates that you haven't been paying attention. 
  
  It's not a goal to have the most
  ports possible; 
  
 ...Maybe take
 changes to a 
 subsection of the forum? I've posted there...
 
 A new subsection group: ports
 X11...
 WWW...
 DEVEL...
 maybe one DELETIONS ( a sticky or subsection)
 and/or PENDING DELETIONS ... and/or
 and deleted ports could be bought back again for those
 who find them useful, even if someone was reading about
 a years-ago removal.
 
 Pardiff (diffp ) comes to mind (just removed this week)
 I use the diffp binary for diffing ports-to-upgrade pipe
 results between days (diffp portlist.MON portlist.TUE)
 I suppose mergemaster.sh could even be updated to
 be more similar to the output of diffp.
 .
 gfontview... 
 ...
 
 Just puttting that idea onto the forum expansion, which
 maybe could solve problems quicker than PR's.
 For instance, as of now,
 textproc/po4a
 x11/roxterm
 devel/dconf
 
 all fail to build failed to load exteral entity 
http://docbook.sourceforge.net/release/
 xsl/current/manpages/docbook.xsl  
 
 and maybe if the forum had been expanded, threads (dconf
 po4a roxterm) would
 have been started/updated explaining the fix, if anyone knew
 it. 
 

...
Lost post en route to the list [ addressee maybe
incomplete]   Re-sending from the SENT folder. 
Sorry for the delay...
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: FreeBSD ports which are currently scheduled for deletion

[Jeffrey Bouquet]

 
 On 4/13/2014 17:46, Matthew Rezny
 wrote:

  On this list I see cfv, which I've used for
 years, marked just because
  it's
  not maintained. It works great, it needs no
 changes. 


  I'm not officially a maintainer on any ports for a few
 reasons. I have other 
  areas where I consider spending my time more valuable,
 but if I have to waste 
  it on port maintenance, I'll try to do so in the most
 efficient way. 
 
 Well, you basically said you're more important than anybody
 that
 regularly reads this list, so good luck with that tact.
 
...I
 regularly
read
 this list
.and
 also
..have
 not the
...experience
 or time
 So you should become a committer.
  
 Try submitting the patches, including staging and assuming
 maintainership (and then honestly be the maintainer). 
 
  Staging is not an opt-in feature so as
 harsh as it is to
 say
 
 This indicates that you haven't been paying attention. 
 
 It's not a goal to have the most
 ports possible; 
 
...Maybe take changes to a 
subsection of the forum? I've posted there...

A new subsection group: ports
X11...
WWW...
DEVEL...
maybe one DELETIONS ( a sticky or subsection)
and/or PENDING DELETIONS ... and/or
and deleted ports could be bought back again for those
who find them useful, even if someone was reading about
a years-ago removal.

Pardiff (diffp ) comes to mind (just removed this week)
I use the diffp binary for diffing ports-to-upgrade pipe
results between days (diffp portlist.MON portlist.TUE)
I suppose mergemaster.sh could even be updated to
be more similar to the output of diffp.
.
gfontview... 
...

Just puttting that idea onto the forum expansion, which
maybe could solve problems quicker than PR's.
For instance, as of now,
textproc/po4a
x11/roxterm
devel/dconf

all fail to build failed to load exteral entity 
http://docbook.sourceforge.net/release/
xsl/current/manpages/docbook.xsl  

and maybe if the forum had been expanded, threads (dconf po4a roxterm) would
have been started/updated explaining the fix, if anyone knew it. 

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

textproc/pardiff Deprecation...

[Jeffrey Bouquet]

Upon noticing this impending deprecation, I toyed around with pardiff and diffp 
(the two binaries)
The latter appears quite worthy of inclusion into BASE if its license or 
rewrite would permit, not to mention
maybe modifying mergemaster to make use of it somehow.   [ I've other 
wish-to-reinstate: 
gfontview, beep etc but they may not be as universally useful eventually to 
most using FreeBSD as this
one at-a-glance appears to be... ]...

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

pkg fails build on v9-STABLE ... LOG attached (long)

[Jeffrey Bouquet]

Tried pasting the error, it was all one huge paragraph, not lines...

Sorry.

It built once, skipping past this error.  Almost always fails.


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

Re: pkg fails build on v9-STABLE ... LOG pasted

[Jeffrey Bouquet]

On 02/21/14 10:11, David Wolfskill wrote:

On Fri, Feb 21, 2014 at 10:05:18AM -0800, Jeffrey Bouquet wrote:

Tried pasting the error, it was all one huge paragraph, not lines...

Sorry.

It built once, skipping past this error.  Almost always fails.
...

Looks as if the attachment wasn't propagated to the list.

Note that there's a 200KB max for message bodies anyway

Peace,
david



9.1-STABLE r250151  (fails also with clang IIRC)
Warning: Object directory not changed from original 
/usr/ports/ports-mgmt/pkg/work/pkg-1.2.6/pkg


gcc47 -O0 -pipe -s -Wl,-rpath=/usr/local/lib/gcc47 
-DPORTSDIR=\/usr/ports\ -I../libpkg 
-I/usr/ports/ports-mgmt/pkg/work/pkg-1.2.6/pkg/../external/uthash 
-I/usr/ports/ports-mgmt/pkg/work/pkg-1.2.6/pkg/../external/expat/lib 
-std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual 
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -c add.c


gcc47 -O0 -pipe -s -Wl,-rpath=/usr/local/lib/gcc47 
-DPORTSDIR=\/usr/ports\ -I../libpkg 
-I/usr/ports/ports-mgmt/pkg/work/pkg-1.2.6/pkg/../external/uthash 
-I/usr/ports/ports-mgmt/pkg/work/pkg-1.2.6/pkg/../external/expat/lib 
-std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual 
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -c annotate.c


In file included from annotate.c:33:0: 
/usr/local/lib/gcc47/gcc/i386-portbld-freebsd9.2/4.7.4/include-fixed/unistd.h:116:0: 
error: _POSIX_CPUTIME redefined [-Werror]


In file included from 
/usr/local/lib/gcc47/gcc/i386-portbld-freebsd9.2/4.7.4/include-fixed/unistd.h:47:0, 
from annotate.c:33: /usr/include/sys/unistd.h:56:0: note: this is the 
location of the previous definition In file included from add.c:36:0: 
/usr/local/lib/gcc47/gcc/i386-portbld-freebsd9.2/4.7.4/include-fixed/unistd.h:116:0: 
error: _POSIX_CPUTIME redefined [-Werror] In file included from 
/usr/local/lib/gcc47/gcc/i386-portbld-freebsd9.2/4.7.4/include-fixed/unistd.h:47:0, 
from add.c:36: /usr/include/sys/unistd.h:56:0: note: this is the 
location of the previous definition cc1: all warnings being treated as 
errors cc1: all warnings being treated as errors *** [annotate.o] Error 
code 1 *** [add.o] Error code 1 2 errors *** [all] Error code 2 1 error 
=== Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes 
and rebuild before reporting the failure to the maintainer. *** 
[do-build] Error code 1 Stop in /usr/ports/ports-mgmt/pkg. *** 
[/usr/ports/ports-mgmt/pkg/work/.build_done.pkg._usr_local] Error code 1 
Stop in /usr/ports/ports-mgmt/pkg. FreeBSD 9.1-STABLE

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

Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools

[Jeffrey Bouquet]

My first post that quotes good:  Thunderbird rather than the webmail...
[As this one is about to be send, I see that it is a restate/duplicate 
of the one

lost in a webmail glitch ... so apologies...]




On 02/03/14 14:38, Matthew Seaman wrote:

On 03/02/2014 21:24, Julian H. Stacey wrote:

be beneficial in a very short amount of time.  Even if you prefer to
compile from source,

I use source, rarely if ever use packages, (except pkg_delete
to remove old broken dependencies). No opinion which scrips are better.



you will still reap the benefits of the modern
packaging system.

In 10.0 FreeBSD `reaped the benefit` of a default new horrible
registry that smells like Microsoft with quasi binary local.sqlite
needing special tools.  (Yes I know there's an export function.)

For 2 decade we've poured scorn on Microsoft  its opaque easily
damaged hard to access registry,  lauded how with FreeBSD we can
examine  manipulate  repair our text based equivalent with any
number of personal choice text tools,  now FreeSBD is burdened by
this horrible Microsoft style registry.

You're being absurd.  local.sqlite is nothing like the Microsoft
registry[*].  It's a database of all the files etc. that are managed
through the ports system.  No more, no less.

... our TEXT based ...

/# find /var/db/pkg -type d -name p5* | xargs -J % find -type f -name 
+CONTENTS -exec grep -H 5.12 {} \; | grep pm | gtr -s \/ \n | grep 
p5 | sort | uniq | xargs -J % portmaster -d -B -P -i -g %  yell || yell


That pipe, corrected ( the working version includes an incrementing | 
head -NN |  thru hundreds of p5 upgrades,  15-25  at a time,

so easy completion of the upgrade  with
only a repeat with the up arrow and a minor edit ,)  handily upgraded a 
/perl5/ subdirectory to

the default on several installs.



All we have done is replace an unreliable collection of text files --
hard to keep consistent, impossible to update in an atomic fashion and
woefully pessimal for certain quite legitimate queries

A subset of the above pipe?



-- with a RDBMS,

Which a user may be expected to learn


which quite neatly disposes of those problems.  No, it isn't ascii text
which you can grep through.

That here is a source of dismay... less creativity in pipes etc...



   It's a set of relational tables, which you
can query using SQL.

That here is also a lessening of the fun.


  And that is a deal more powerful in many ways than
grep, but not so familiar to most; so we've provided a scripting
interface in the form pf pkg-query(8).



Do you complain because ZFS doesn't have it's configuration data in some
ascii text files?  How about procstat(8)? Or ld.so(1)/ldconfig(8)?



Truth is, unix has always adopted a pragmatic approach to system data
and stored it in whatever form would be most effective.  In our case,
we're pretty clear that a relational database is streaks ahead of a
directory tree full of text files.

For those reluctant to switch over, maybe a concurrent

/usr/ports/ports-mgmt/pkg_legacy_tools

Maybe even concurrent installs [both package systems, ] , if they are 
both tweaked to be co-existable, and each in
parallel improved over time.  What if an urgent upgrade to a server 
failed in one method, the
other could env -i in , this one env -i  out, and the upgrade 
proceed apace.
Or a command to test which method would work best of on a specific 
upgrade, and that pkg system default (the

other backup) until the next switchover

Can't do that in  [ insert other favorite operating system here ]... 







Cheers,

Matthew


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

Re: Upgrading Perl... Somebody just shoot me and put me out of my misery!

[Jeffrey Bouquet]

I *was* equally setback by this upgrade, but am slowly mostly fixing it on a 
build machine to maybe package over to the usual one:

(My quicker pipes have not been working ...)

..

cd /var/db/pkg

gnuls -oSr | grep p5 | head [ increment each time... 10, 20...] | awk 
'{print $8 }' xargs -J % find % -type f

-name +MTREE_DIRS  -exec /bin/ls -lac {} \; 



[ more to the pipe maybe automates the next ...]

...

You'll see ports *since* last upgrading perl and *not since*.  Simply type the 
older ones into

portmaster -d -B -i -g p5-.. p5-... p5-.

.

I am in a rush on some aspects of this update, so on ones which don't install

use something like...

cd /usr/ports/net/p5-Socket

/bin/rm -rf work

make -DNO_STAGE -DMAKE_JOBS_UNSAFE -DNO_PACKAGE reinstall



YMMV.  [ It is quite obviously piecemeal, this method...]

..

Another glitch with this upgrade, every Nth port seemingly wants to revert perl 
5.16  5.14 in the process of

install from a package, so I've often

/bin/rm -v /usr/bin/perl

/bin/rm -v /usr/bin/perl5

/bin/rm -v /usr/local/bin/perl

ln -s /usr/local/bin/perl5.16.3 /usr/local/bin/perl

ln -s /usr/local/bin/perl5.16.3 /usr/bin/perl

ln -s /usr/local/bin/perl5.16.3 /usr/bin/perl5

After cntl-c the new failing install-older-perl package *BEFORE* it installs 
the older perl *ALSO* 

.

If I am wiser next time, and maybe even on this older-perl machine, I'll simply 
delete all p5-s after printing them out,

and awk / gtr /xargs the file into portmaster.   I expect the workarounds to 
still be maybe necc. though.

.



J. Bouquet 

Sorry for typos 




On Friday, November 22, 2013 3:52 AM, Mathieu Arnold m...@mat.cc wrote:
 
+--On 22 novembre 2013 00:25:26 -0800 Ronald F. Guilmette
r...@tristatelogic.com wrote:
|   AUTHOR: m...@freebsd.org

Cough, cough, yeah, I mostly wrote that.

|         portupgrade -o lang/perl5.16 -f perl-5.14.\*

At that time, that line was right. Now, after that, the perl packages name
which had the same name (all named perl) and were conflicting and were
renamed to perl5 for the default perl, that is, 5.16, and perl5.xx for the
non default ones, that are 5.12, 5.14 and 5.18.

| pkg_info says that at present I have perl5.14-5.14.4_3 installed.  So
| excuse my french, but why the fuck didn't the command:
| 
|    portupgrade -o lang/perl5.16 -f perl-5.14.\*

Now, as you can see, your perl is not named perl-5.14 but
perl5.14-5.14.4_3, so, you should change that line to :
portupgrade -o lang/perl5.16 -f perl5.14-5.14.4_3

I'll commit an update to that right now.

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

Fw: Upgrading Perl... yesterday's AWK improved, working...

[Jeffrey Bouquet]

Sorry for top-posting...  [ other email services are on my todo list (  
hushmail, runbox, polarismail,  if/when the

email volume here increases... ]


the +MTREE_DIRS pipe can be extended...

... | grep -v v 2 [OMITTING Nov 21 already-updateds] | awk '{print $9}' | 
gtr -s \/ \n | grep p5 | xargs -J % portmaster -d -B -i -g % 

 yell || yell



If one has gnuls, gtr (coreutils?) installed, and still uses 
/var/db/pkg/PORTNAME-NUMBER, that pipe (the second part above, the
first below...)  just updated at-once 14 of the hundreds of p5 ports as I had 
updated the head -115 to head -135 ( approximately).

I expect to copy [1] that !hint to all /lang/ (perl ) (ruby) (python) to use 
until pkgng, at which point I hope that someone has posted

a PKG equivalent... or evolved a feature of PKG where it writes its /var/db/pkg 
files out again after each operation, so equivalent

pipes can occur. 


1.. actually, scrot of this email before sending, so more information included. 
 ( the .jpg to the /lang/ directories...) 






On Friday, November 22, 2013 4:17 AM, Jeffrey Bouquet 
jeffreybouq...@yahoo.com wrote:
 
I *was* equally setback by this upgrade, but am slowly mostly fixing it on a 
build machine to maybe package over to the usual one:

(My quicker pipes have not been working ...)

..

cd /var/db/pkg

gnuls -oSr | grep p5 | head [ increment each time... 10, 20...] | awk 
'{print $8 }' xargs -J % find % -type f

-name +MTREE_DIRS  -exec /bin/ls -lac {} \; 



[ more to the pipe maybe automates the next ...]

...

You'll see ports *since* last upgrading perl and *not since*.  Simply type the 
older ones into

portmaster -d -B -i -g p5-.. p5-... p5-.

.

I am in a rush on some aspects of this update, so on ones which don't install

use something like...

cd /usr/ports/net/p5-Socket

/bin/rm -rf work

make -DNO_STAGE -DMAKE_JOBS_UNSAFE -DNO_PACKAGE reinstall



YMMV.  [ It is quite obviously piecemeal, this method...]

..

Another glitch with this upgrade, every Nth port seemingly wants to revert perl 
5.16  5.14 in the process of

install from a package, so I've often

/bin/rm -v /usr/bin/perl

/bin/rm -v /usr/bin/perl5

/bin/rm -v /usr/local/bin/perl

ln -s /usr/local/bin/perl5.16.3 /usr/local/bin/perl

ln -s /usr/local/bin/perl5.16.3 /usr/bin/perl

ln -s /usr/local/bin/perl5.16.3 /usr/bin/perl5

After cntl-c the new failing install-older-perl package *BEFORE* it installs 
the older perl *ALSO* 

.

If I am wiser next time, and maybe even on this older-perl machine, I'll simply 
delete all p5-s after printing them out,

and awk / gtr /xargs the file into portmaster.   I expect the workarounds to 
still be maybe necc. though.

.



J. Bouquet 

Sorry for typos 




On Friday, November 22, 2013 3:52 AM, Mathieu Arnold m...@mat.cc wrote:

+--On 22 novembre 2013 00:25:26 -0800 Ronald F. Guilmette
r...@tristatelogic.com wrote:
|   AUTHOR: m...@freebsd.org

Cough, cough, yeah, I mostly wrote that.

|         portupgrade -o lang/perl5.16 -f perl-5.14.\*

At that time, that line was right. Now, after that, the perl packages name
which had the same name (all named perl) and were conflicting and were
renamed to perl5 for the default perl, that is, 5.16, and perl5.xx for the
non default ones, that are 5.12, 5.14 and 5.18.

| pkg_info says that at present I have perl5.14-5.14.4_3 installed.  So
| excuse my french, but why the fuck didn't the command:
| 
|    portupgrade -o lang/perl5.16 -f perl-5.14.\*

Now, as you can see, your perl is not named perl-5.14 but
perl5.14-5.14.4_3, so, you should change that line to :
portupgrade -o lang/perl5.16 -f perl5.14-5.14.4_3

I'll commit an update to that right now.

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

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

Confusion about how to specify and also override ( gcc vs clang and versions)

[Jeffrey Bouquet]

I wonder if anyone knows a page where one can be sure the lines in one's make

conf are correct, and also a command line to override the setting.
For instance

CC=/usr/local/bin/clang33
CXX+= ...
As, how many of those are supposed to exist?
Are the more for some compilers than others?
Other things to consider within the make.conf?
The way they should be written for each of gcc46, gcc47, clang, clang33

And a way to override whatever is in make conf, as...
make CLANG=/usr/local/bin/clang33 build  ...  is supposed to work?  Or 
some other suggested or proven method?

Checking wiki.freebsd.org I don't see any specific page.
Searching for the information in the forums has for a short time not yielded 
much informaiton.

I've six of seven distinct make.conf's (make.conf.clang, make.conf.aria2c, ...) 
that I'd like
to standardize the syntax of the compiler within all of. 

Thanks if anyone knows.

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

UPDATING libtasn1

[Jeffrey Bouquet]

UPDATING says to rebuild all that depend upon libtasn1, but  the +REQUIRED_BY 
lists a large number here that still work without it. (Although they don't 
presently work, being unsed and not having been rebuilt since pixman...not 
really relevant but I neglect on purpose to rebuild many gnome ports each time, 
as many often typicall fail without modifying make.conf or switching compilers, 
they are more or less there for reference in case I want, say, an audio port, I 
would know which to grab a package maybe for.)

  ...(Examples:  qiv, dillo,  which  UPDATING probably says to rebuild 
(untested).)   So while the UPDATING syntax may be useful for production 
machines, many with desktops might benefit from an alternate method which only 
rebuilds, say, a tenth of the huge list, using a more fine-grained method of 
finding those which directly depend upon the library...  


So this message I mean to include all such library bumps in the future, and as 
a suggestion not for the next 2, 3, 4 or so similar entries, but for those more 
distant after something tested and useful has been put maybe into a shell 
script so that the update takes much fewer hours of CPU usage.

Thanks

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

Svn wrapper? [pasted from a Q. on the forum] ... To resolve conflicts remaining

[Jeffrey Bouquet]

On many machines here, the ports or src tree upon  svn up  shows a large number 
of conflicts, half of which want an 
answer such as postpone, the other theirs-full. Re-downloading with svn 
seems to not resolve the conflicts. (Why they 
appear in the first place, nothing changed on this machine in the meantime, is 
a complete mystery.) The often recommended delete-and-re-checkout procedure is 
okay, but takes much more time (preserving extra files etc) than Id like to, 
if there was any svn command that mimics the old 
cvs procedure of remove-directory and re-
cvs it. Anyone 
knows of a succinct svn command for use in such situations, or if a wrapper 
could be crafted that puts forth the series of 
commands that would take less time than a new src or ports checkout? The 
handbook refers to the SVN redbook, it might have the answer, but I am 
reluctant to spend the time reading it thoroughly if someone else has and knows 
the answer(s) already.


Thanks. 
J. Bouquet 
[The forum thread has a few posts in it with a few more details ]...
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Comments on todays non-NEW_XORG update

[Jeffrey Bouquet]

It is done here, for the most part.  (Epiphany remains out of the picture, 
persistent failure to build webkit...) but

there were a few quirks...
The reinstall of gtk20 (which was newly missing a dependency) depended upon 
ibus for the install, but ibus depends
on gtk20... 

gtk20 )  make -k install
ibus ) pkg_delete  make package
gtk20 ) make package

And the rebuild of roxterm, which was missing a vte rebuild, which was missing 
a pango rebuild.   This occurs
here at least once a year or so... 

Here UPDATING usually cannot be followed...  that lists over 300 ports needing 
pixman; I only
use several of them daily, and only had to rebuild a few. 

I'm used to these unexpected less-than-full-rebuild extra-rebuilds occuring,  
but am wondering if FreeBSD could more
precisely anticipate them in the UPDATING instructions someday.  [Revising the 
portmaster -r pixman since that may take
several days, and in two hours I'm already done with it AFAIK.] 
 
[Tangentally, has anyone using pkg only, run across the same situation and 
resolved it with any ease and repeatable
instructions to the ports list??? ] 
 
J. Bouquet
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

v10 pkg question, maybe

[Jeffrey Bouquet]

#/# find /var/db/pkg -type d -name p5* | xargs -J % find -type f -name 
+CONTENTS -exec grep -H 5.12 {} \; | grep pm | gtr -s \/ \n | grep p5 | 
sort | uniq | xargs -J % portmaster -d -B -P -i -g %  yell || yell


If one has gtr (gnu tr) installed, that may work if one has /var/db/pkg...

I had an issue where pkg_which turned up ? for all the perl files it usually 
worked on in /usr/local/lib/perl5/site_perl (etc)
to upgrade, say, 5.12.4 to 5.12.5... suddenly failing a bit into the 5.12.5 
5.14.4 upgrade, meaning each port had to be
entered manually. 

That long CLI pipe at the top is working handily. ( midst of it, a head -110 , 
head -140, head -170 so make its failures
manageble on restart)
And one inserts | grep -v tkdb | , for instance, for p5- ports which won't 
rebuild at the moment.
In fact that script is working way better than any other perl upgrade I recall 
doing that required an UPDATING course of action.

So I am wondering it someone who uses /pkg/ can craft an equivalent CLI, test 
it, and eventually it or its equivalant could be
placed either in the port, or in UPDATING so persons who have many ports could 
upgrade leisurely in a few hours rather than
kludgedly over many more hours than the few.  

Thanks if anyone has the time...  and expertise and experience to look into the 
situation.

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

Wishlist for pkg before it is default on STABLE

[Jeffrey Bouquet]

.Actually, the subject is just a title, probably not the subject (multiple 
issues).


I continue to believe svn, (pkg...) (gpart) should have a *flowchart* so issues 
could be resolved without consulting
forums, wikis, ... quicker.

Should one compose one for svn, the following fixed checksum mismatch svn 
halts on the ports tree.
#problem dir#   svn co --set-depth empty   (or it was svn up...)
#problem dir#  svn co --set-depth infinity  (or it was svn up...)
#/usr/ports#  svn up /usr/ports 
However, that worked only on about ninety percent of the problematic ports, of 
which there were too many.
I quit using it however, and had to re-svn a ports tree, when svn could no 
longer operate because of segfaulting.
(Maybe it is unstable once it is fixed in a nonstandard way...)

Hope that hint helps someone.  One needs a recent version of svn for it to work.
...
Two issues, however, seem problematic here.
.
One, many gnome ports (pkg_add) fail upon the (pkg_delete  pkg_add ) pkg_add,
playpen: cannot change back to ' ' 
and have done so for years, so the machine on which the install is to be done 
(say, an xargs-fed portmaster)
halts with the port newly deinstalled.
(for which I found this week, the following
make install -C /usr/ports/[category][port]  if one is in a hurry...)

(Most Freebsd users probably know it already, I had always changed to the 
directory first.)

Anyway, I am wondering if the unknown cause (year after year here) of that 
pkg_add error will 
occur also in the equivalent command of pkg, if the cause is not known and 
determined to be
a factor in the new code.
..
The other pressing issue,
For instance, today reinstalling p5-Text-RecordParser (which btw wont' patch)
with 
portmaster -d -B -P -i -g ...
installed p5-Pod-* (2 of) into perl 5.14 although I still use 5.12.5
So if I am upgrading hundreds of perl ports at a time, I try to recheck the 
/usr/local/lib/perl5 to see
if  they have installed into 5.14, and recompile them for 5.12.

I expect the same problem will be present in the /pkg/ repository?
IE there is not a
pkg-stable-still-perl-5.12 -v10
pkg-stable-perl-5.14-v10  
branching of either the repository, or some way to know that the slew of 
packages intalling are mismatched
in the dependent langauge to be installed.

Sorry if anything is unclear.  No time to rewrite... 

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

Re: libpkg, sqlite and database problems prevent building any packages

[Jeffrey Bouquet]

Bottom posting below; will reply in better format when/if I get another webmail 
client maybe... the

text is below the next occurance of bottom posting




 From: Thomas Mueller mueller6...@bellsouth.net
To: freebsd-ports@freebsd.org 
Sent: Monday, August 5, 2013 8:36 AM
Subject: Re: libpkg, sqlite and database problems prevent building any packages
 

On 05/08/2013 14:30, Thomas Mueller wrote:
 I could see my pkg client is out of date, but how do I update it?

 Attempts to update all gave me those error messages.  Installation fails.

Matthew Seaman responded:

 Your package database has got into an inconsistent state.  pkg(8) is
 attempting to auto-update the schema to the latest version, but failing
 because it's trying to remove an 'infos' column from a table where that
 column has apparently already been removed.  (Likely this situation has
 come about because pkg got killed in the middle of doing this update
 previously.)

 How happy are you to get down'n'dirty with the source code and running
 SQL from the command line?  If you look at the updates pkg is attempting
 to run shown here:

    https://github.com/freebsd/pkg/blob/master/libpkg/private/db_upgrades.h

 would you be capable of looking at the DB schema, working out which of
 those updates had been applied, aplying any outstanding ones by hand and
 then setting the user version to 19 by:

    sql PRAGMA user_version = 19 ;

?

 If not, check in /var/backups for a good copy of your local.sqlite
 database and try and restore from there.  Unfortunately, there's no
 guarantee that any backup copy doesn't have the same inconsistencies as
 your live copy.

 We need to make pkg(8) databases more resilient to the effects of SIGHUP
 or similar while they are elbows-deep in the bowels of the DB schema...

Trying to do what you suggest would in all likelihood be an exercise in 
futility, especially when I am very tired from being unable to sleep.

I didn't realize pkgng was so non-sturdy.

I wonder what would happen if I delete /var/db/pkg/local.sqlite, or perhaps 
better, move it to another location and name so as not to burn my bridges.

But anything so I can upgrade pkg.

Does pkgng have no means of recovery?  Can pkg regenerate a database, and from 
what?

My /var/backups on the USB-stick 9.2-BETA2 amd64 installation shows


total 280
-rw-r--r--  1 root  wheel    1674 Apr  2  2012 aliases.bak
-rw-r--r--  1 root  wheel     436 Apr  2  2012 group.bak
-rw---  1 root  wheel    1500 Apr  2  2012 master.passwd.bak
-rw-r--r--  1 root  wheel  269144 Dec 13  2012 pkgdb.bak.tbz
-rw-r--r--  1 root  wheel     129 Jul 16  2012 pkgdb.bak.tbz.2


pkg.bak.tbz looks like the database from the old format.

My /var/backups on the USB-stick 9.1-STABLE i386 installation shows


total 140
-rw-r--r--  1 root  wheel    1688 Jan 20  2013 aliases.bak
-rw-r--r--  1 root  wheel    1674 Jun  6  2012 aliases.bak2
-rw-r--r--  1 root  wheel     481 Jan 17  2013 group.bak
-rw-r--r--  1 root  wheel     449 Jul 13  2012 group.bak2
-rw---  1 root  wheel    1761 Jan 17  2013 master.passwd.bak
-rw---  1 root  wheel    1500 Jun  6  2012 master.passwd.bak2
-rw-r--r--  1 root  wheel    8524 May 28 03:01 pkgdb.bak.tbz
-rw-r--r--  1 root  wheel     130 Jan 19  2013 pkgdb.bak.tbz.2
-rw-r--r--  1 root  wheel  100352 May 28 04:29 pkgng.db


pkgng.db looks like the new format, but that was before I built wine and 
dependencies.

..
..
Bottom posting... 

Non-sturdy? , but this sort of showstopper is what IMHO 
should necessite a huge problem-resolving flowchart, 
before pkg(ng)  fully obsoletes its legacy
alternative... not to mention the possibility of 
pkg(ng) not having enough memory, 
on some installs where before /var/db/pkg would have enough.
Just a 2c.    As in, if I *have to* migrate to pkg/, I need something from 
which to
copy the succint parts to a few post-its on the monitor...  (think 
HUGE...FLOWCHART...) 

Thanks. 


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

Re: editors/vim: does not compile on CURRENT

[Jeffrey Bouquet]

I have/had/have had a similar  libintl_textdomain 

in a great many ports (currently pcmanfm and about twenty others), and it has 
persisted on-and-off year after

year.  No amount of dependency rebuild ususally solves it, eventually sometimes 
a remote package is installed
instead (v9)  So I would be interested not so much in those two specific 
errors, but a wrapper under which one
could build a port so that each element of the calling compilation line could 
be analyzed to see from which the
error specifically occurs, no matter how much it slows down the respective port 
build... 



 From: O. Hartmann ohart...@zedat.fu-berlin.de
To: FreeBSD Ports freebsd-ports@freebsd.org 
Sent: Wednesday, July 31, 2013 7:28 AM
Subject: editors/vim: does not compile on CURRENT
 

I have one box that is reluctantly not compiling port editors/vim with
the following error.

main.c:(.text+0xbb7): undefined reference to `libintl_gettext'
main.c:(.text+0xc93): undefined reference to `libintl_gettext'
objects/main.o:main.c:(.text+0xcaf): more undefined references to
`libintl_gettext' follow cc: error: linker command failed with exit

code 1 (use -v to see invocation) link.sh: Linking failed *** Error
code 1
...


J. Bouquet
(Just figured out how to put that top-posting down here, hopefully all the next 
emails I'll remember and
the post will be more readable...) 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: editors/vim: buffer.c:(.text+0x1589): undefined reference to `libintl_gettext'

[Jeffrey Bouquet]

I'd be interested in a solution to this, also, it consistently lets ports such 
as pinot, mc, mutt etc

fail to build, some to be only pkg-added later.  (v9.1-Stable)




 editors/vim: buffer.c:(.text+0x1589): undefined reference to `libintl_gettext'
 

Updating port /editors/vim on a CURRENT box (FreeBSD 10.0-CURRENT #0
r253194: Thu Jul 11 10:45:47 CEST 2013 amd64) ends up in the error
shown below.

Since this happens only on exact one box running CURRENT (out of a
bunch of CURRENT of the same OS revision, the same compiler settings,
the same settings in /etc/src.conf et cetera) while other CURRENT don't
show this weird error, is suspect a faulty local library, like
libintl.so, which belongs to gettext I suppose.

Well, I tried to do a

portmaster -r editors/vim

as well as 

portmaster -r gettext

to compile away the suspected problem in one of the prerquisited
ports, but that didn't end up in success.

The problem is still sticky and I'm a bit out of ideas ...

Has anybody an idea?

Thanks and regards,

Oliver

[...]
link.sh: $LINK_AS_NEEDED set to 'yes': invoking linker directly.
  cc   -L.  -Wl,-rpath=/usr/lib:/usr/local/lib -pthread
-L/usr/local/lib -rdynamic -Wl,-R/usr/local/lib/perl5/5.16/mach/CORE
-L/usr/local/lib -Wl,--as-needed  -o vim objects/buffer.o
objects/blowfish.o  objects/charset.o  objects/diff.o
objects/digraph.o  objects/edit.o  objects/eval.o  objects/ex_cmds.o
objects/ex_cmds2.o  objects/ex_docmd.o  objects/ex_eval.o
objects/ex_getln.o  objects/fileio.o  objects/fold.o
objects/getchar.o  objects/hardcopy.o  objects/hashtab.o
objects/if_cscope.o  objects/if_xcmdsrv.o  objects/mark.o
objects/memline.o  objects/menu.o  objects/message.o  objects/misc1.o
objects/misc2.o  objects/move.o  objects/mbyte.o  objects/normal.o
objects/ops.o  objects/option.o  objects/os_unix.o  objects/pathdef.o
objects/popupmnu.o  objects/quickfix.o  objects/regexp.o
objects/screen.o  objects/search.o  objects/sha256.o  objects/spell.o
objects/syntax.o    objects/tag.o  objects/term.o  objects/ui.o
objects/undo.o  objects/version.o  objects/window.o
objects/if_lua.o    objects/if_perl.o objects/if_perlsfio.o
objects/if_python.o    objects/if_tcl.o  objects/if_ruby.o
objects/netbeans.o    objects/main.o  objects/memfile.o
-lm -lelf  -pthread -ltermlib -liconv
-Wl,-R/usr/local/lib/perl5/5.16/mach/CORE -pthread -Wl,-E
-fstack-protector -L/usr/local/lib
-L/usr/local/lib/perl5/5.16/mach/CORE -lperl -lm -lcrypt -lutil
-L/usr/local/lib/python2.7/config -lpython2.7 -lutil -lm
-Wl,--export-dynamic    -L/usr/local/lib -ltcl86 -lz -lpthread -lm
-Wl,-R -Wl,/usr/local/lib -L/usr/local/lib -lruby19 -lexecinfo
-lpthread -lcrypt -lm -L/usr/local/lib
-Wl,-rpath=/usr/lib:/usr/local/lib -pthread -L/usr/local/lib
objects/buffer.o: In function `open_buffer': buffer.c:(.text+0x1df):
undefined reference to `libintl_gettext' buffer.c:(.text+0x1fb):
undefined reference to `libintl_gettext' objects/buffer.o: In function
`close_buffer': buffer.c:(.text+0x5d3): undefined reference to
`libintl_gettext' objects/buffer.o: In function `do_buffer':
buffer.c:(.text+0x1589): undefined reference to `libintl_gettext'
buffer.c:(.text+0x15bc): undefined reference to `libintl_gettext'
objects/buffer.o:buffer.c:(.text+0x163f): more undefined references to
`libintl_gettext' follow
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org




Bottom posting here.  New webmail won't even let me see it as I type. so top 
posting for now...
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: kde3 ports expired today

[Jeffrey Bouquet]

bsdstats.org  ports stats would have that information probably

Here, I've installed snotes, xxdiff and a few others (qt33...)  not kde3 per 
se...




 
Subject: Re: kde3 ports expired today
 


Are there any numbers how many FreeBSD(!) users are using KDE3 or KDE4?
If not, what about a well organized(!) straw poll? Just to see, if we are all
hunting in the right direction.

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

svn repositories stale?

[Jeffrey Bouquet]

svn0.us-west.freebsd.org, r321412  (not updating ) since subversion upgraded in 
ports (at least

vs freshports.org...) 
Anyone know if it is a configuration at that server, or some other cause, or if 
it is a know problem,
or a PBKAC here at these machines? 

Thanks

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

Re: Rebuild all ports for perl minor version update?

[Jeffrey Bouquet]

--- On Sun, 6/16/13, Thomas Mueller mueller6...@bellsouth.net wrote:

 From: Thomas Mueller mueller6...@bellsouth.net
 Subject: Rebuild all ports for perl minor version update?
 To: freebsd-ports@freebsd.org

 So now I do the massive portmaster upgrade and am stopped by
 silly little things, like a conflict between the old
 transmission-gtk2 and the newer version, and later gcc can't
 make clean because of checksum errors.  It didn't know
 to deinstall the old transmission-gtk2?
 Tom


Provided your pkg_tools still exist the following could be useful, I've 
haphazardly
got it running for several hours (.tbz are present from another machine for
portmaster in portmaster-download...).
Sometimes it freezes, but cntl-c it restarts again ( A directory had disappeared
upon its port reinstall, but the CLI continues .)

cd /usr/local/lib/perl5/site_perl/5.12.4
for i in $(find . -type d), do
find . -type f | xargs -J % pkg_which | xargs -J % portmaster -d -B -P -i -x 
gcc-4.7.3.20130323 -R %  cd /usr/local/lib/perl5/site_perl/5.12.4  pkgdb -u 

Note that only a template to modify-then-test, [ I ran it, it started to update 
too
much, I might have modified it more, OR maybe it restarted as intended upon
cntl-c the first time.  Additionally, the first part (the -type d line) does 
not show in
the history of the command, so I cannot be sure of more than one thing in that
command.  
Howsoever, it has been running over an hour with only occaisional freezes, 
restarting upon cntl-c without reentering the command, and may be useful
for someone more expert in shell mechanisms than I to use to craft an
all-inclusive python-after-upgrade, perl-after-upgrade, ruby-after-upgrade
shell script(s)... 
Several weeks before I can test it on another machine, am out of time.

J. Bouquet 

[It is certainly working better than ANY instance I ever ran a
perl-after-upgrade,... so I apologize for the inexact replication of it in this
email. ]
 

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

Re: Rebuild all ports for perl minor version update? UPDATED

[Jeffrey Bouquet]

Edited inline correction

--- On Sun, 6/16/13, Jeffrey Bouquet jeffreybouq...@yahoo.com wrote:

From: Jeffrey Bouquet jeffreybouq...@yahoo.com
Subject: Re: Rebuild all ports for perl minor version update?
To: freebsd-ports@freebsd.org
Date: Sunday, June 16, 2013, 2:52 PM



--- On Sun, 6/16/13, Thomas Mueller mueller6...@bellsouth.net wrote:

 From: Thomas Mueller mueller6...@bellsouth.net
 Subject: Rebuild all ports for perl minor version update?
 To: freebsd-ports@freebsd.org

 So now I do the massive portmaster upgrade and am stopped by
 silly little things, like a conflict between the old
 transmission-gtk2 and the newer version, and later gcc can't
 make clean because of checksum errors.  It didn't know
 to deinstall the old transmission-gtk2?
 Tom


Provided your pkg_tools still exist the following could be useful, I've 
haphazardly
got it running for several hours (.tbz are present from another machine for
portmaster in portmaster-download...).
Sometimes it freezes, but cntl-c it restarts again ( A directory had disappeared
upon its port reinstall, but the CLI continues .)

cd /usr/local/lib/perl5/site_perl/5.12.4
for i in $(find . -type d), do
find . -type f | xargs -J % pkg_which | xargs -J % portmaster -d -B -P -i -x 
gcc-4.7.3.20130323 -R %  cd /usr/local/lib/perl5/site_perl/5.12.4  pkgdb -u 
EDIT
do find $i ... 
EDIT 2
I had to delete for the duration ports such as PDL which insisted on continual 
reinstall
EDIT 3
finally had to delete several deprecated/broken (p5-Lucene.. p5-Test-Block...)
OTHERWISE 
it ran many hours continually with many cntl-c which did not actually halt it,
just its subprocess at the time.
END  EDITS

Note that only a template to modify-then-test, [ I ran it, it started to update 
too
much, I might have modified it more, OR maybe it restarted as intended upon
cntl-c the first time.  Additionally, the first part (the -type d line) does 
not show in
the history of the command, so I cannot be sure of more than one thing in that
command.  
Howsoever, it has been running over an hour with only occaisional freezes, 
restarting upon cntl-c without reentering the command, and may be useful
for someone more expert in shell mechanisms than I to use to craft an
all-inclusive python-after-upgrade, perl-after-upgrade, ruby-after-upgrade
shell script(s)... 
Several weeks before I can test it on another machine, am out of time.

J. Bouquet 

[It is certainly working better than ANY instance I ever ran a
perl-after-upgrade,... so I apologize for the inexact replication of it in this
email. ]
 

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

Browsers...

[Jeffrey Bouquet]

Firefox 21 would not run (segfaulted).  I pkg_added Firefox 20, and it works, 
but I lost all the sites it for years had open at the start, they are 
nowhere... maybe I'll find them in a backup later.

...
Midori would not run, but midori -d -p'  seems to work.  (The latest one will 
not build, but
that is unique to here probably...) 


This all prompted by one site refusing to proceed to the next clicked action in 
both
opera and seamonkey, which otherwise work fine...

Meant just as a FYI for anyone facing a similar situation, not needing an 
answer to
this post...

J. Bouquet


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