Re: Quarterly reports?

[Freddie Cash]

On Sun., May 9, 2021, 12:29 p.m. Kevin Oberman,  wrote:

> Did I somehow miss it or is the first quarter report MIA? I don't think
> I've ever seen it posted more than a month after the start of the new
> quarter.
>

It hit the mailing lists and website on May 5.

Cheers,
Freddie

Typos due to smartphone keyboard.

>
___
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: bash: Undefined symbol "rl_filename_rewrite_hook" referenced from COPY re location in /usr/local/bin/bash

[Freddie Cash]

Run ldd against the bag binary and see if it's picking up /use/lib/
libreadline.8.so

If it is and this is a FreeBSD 12.x system, then just delete (or rename)
that file. Run ldd again, and it should pick up the readline library from
/usr/local/lib.

It seems freebsd-update doesn't remove that library when upgrading from
11.x to 12.x on some systems. I posted about this in the -stable mailing
list a month or so ago.


Cheers,
Freddie

Typos due to smartphone keyboard.

On Sun., May 9, 2021, 1:54 a.m. Kurt Jaeger,  wrote:

> Hello,
>
> on a recently updated system I have this problem with shells/bash,
> it fails to start:
>
> ld-elf.so.1: Undefined symbol "rl_filename_rewrite_hook" referenced from
> COPY relocation in /usr/local/bin/bash
>
> I do not have this on similar systems, also recently updated, so
> any idea where this might coming from ? pkg install bash-static fixes
> it.
>
> With 'recently' I mean: the last 60minutes, from the same repo,
> which is very much up2date.
>
> It is really surprising...
>
> --
> p...@opsec.eu+49 171 3101372Now what ?
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: looking for port origin for executable

[Freddie Cash]

On Tue, May 4, 2021 at 8:33 AM Robert Huff  wrote:

> Would some kind soul please tell me which port installs the
> executable "g-ir-scanner"?  I was purging unused ports and seem to
> have done this one by mistake.
>

http://freshports.org allows you to do searches of pkg-plist files.  It's a
little finicky, though.

Doing a search for "g-ir-scanner" returns 0 hits, regardless of what type
of search is done.

Doing a search for "bin/g-ir-scanner" returns gobject-introspection.

So if you know the path for the file (relative to /usr/local), then the
search works.

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

Re: List of packages upgraded last time `pkg upgrade` was executed

[Freddie Cash]

On Tue., Jan. 26, 2021, 5:18 p.m. Yasuhiro Kimura,  wrote:

> Hello,
>
> Is there any way to get the list of packages upgraded (and installed
> as new dependency if there are) last time `pkg upgrade` was executed?
>
> Best Regards.
>
> ---
> Yasuhiro Kimura
>

/var/log/messages and I think /var/log/daemon include the output of the pkg
commands. If you have the log files backed up from the last time it was
run, you could grep for pkg in those.

No idea if this info is also stored in the sqlite databases pkg uses.

Cheers,
Freddie

Typos due to smartphone keyboard.

>
___
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: streaming from FreeBSD to Roku?

[Freddie Cash]

Using Plex (current) and DNLA (in the past).

FreeBSD 8 up through 11.

Cheers,
Freddie

Typos due to smartphone keyboard.

On Wed., Oct. 14, 2020, 8:57 p.m. Robert Huff,  wrote:

>
> Is anyone out there successfully using FreeBSD as a media server
> for a Roku device?
> If so, please contact me off-list.
>
>
> Respectfully,
>
>
> Robert Huff
>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Gracefully killing and restarting a port build....

[Freddie Cash]

On Wed., Jul. 8, 2020, 2:53 p.m. bob prohaska,  wrote:

> On Wed, Jul 08, 2020 at 09:34:53AM -0600, Janky Jay, III wrote:
> > In the future, if you can, try using "screen" or "tmux" to run these
> > large builds in so you don't take the risk of losing the
> > terminal/console. Or, maybe I'm completely off-base as to how it was
> > lost to begin with.
> >
>
> AIUI, screen runs until the session terminates and then stops. In my case
> the controlling terminal was lost when the ssh connection broke. Thus, I
> think screen would have quit as well.


Nope. Screen (or tmux which is nicer to use, imo) takes over as the
controlling terminal. When the ssh connection terminates, screen continues
running (along with all the processes started in that screen session). You
reconnect via ssh, and connect to the running screen session and carry on
like nothing happened.

Cheers,
Freddie

Typos due to smartphone keyboard.
___
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: Gratuitous port splitting (was: Port Avidemux)

[Freddie Cash]

Perhaps the avidemux port should be renamed to avidemux-libs, and then a
new avidemux meta-port could be created with basically just an OPTIONS
screen where your pick which parts you want installed?

Cheers,
Freddie

Typos due to smartphone keyboard.
___
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: good gui bit-torrent client?

[Freddie Cash]

On Sat, Feb 29, 2020, 11:39 AM Miroslav Lachman, <000.f...@quip.cz> wrote:

> Robert Huff wrote on 2020/02/29 00:49:
> >
> >   I used to use azureus/vuze, but it hasn't been maintained is
> > quite a while.
> >   So I changed to deluge ... which now has a dependency
> > semi-permanently BROKEN.
> >   What can people recommend as a replacement?
>
> I used uTurrent in Windows times. When I switched to FreeBSD on my
> desktop I used Vuze / Azureus. But it was resource hungry and at some
> point in time no longer works for me.
> Then I tried qBittorrent and I am very happy with it. Simple, stable,
> good looking with my KDE.
>
> net-p2p/qbittorrent is my choice
>
> Miroslav Lachman
>

If you like/use KDE, have a look at ktorrent.

Cheers,
Freddie

Typos due to smartphone keyboard.

>
___
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: About protocols in openssl

[Freddie Cash]

On Thu, Feb 27, 2020, 12:37 PM Willem Jan Withagen,  wrote:

>
> Interesting, but not quite what I want
> It is not for personal usage, but for ports that I have commited to the
> ports collection, and want to upgrade.
> And yes, fixing openssl works for this problem, but it is not only my
> problem.
>
> I maintain these Ceph ports, and now upstream uses a python module that
> expects SSlv3 to be available in the openssl that encounters on the system.
> And the question is how to accommodate that?
> Short of embedding my own openssl libs with the ceph-libs, thus creating
> a huge maintenance problem.
>
> I could also argue that switching of SSLv3 in a generic library is sort
> of impractical, even if it is a protocol that we want to erradicate.
> But I guess that the maintainers of openssl have decided that this is
> the smart thing to do.
> And I'm in peace with that, but now require an escape from this catch-22.
>
> --WjW
>

There's no mechanism in the ports tree framework for port X to depend on
feature Y being enabled in port Z.

All you can do is add a pkg-message alert to your ceph port saying the use
needs to compile the openssl port with SSLv3 enabled.

You could create a slave port for openssl that has that option enabled,
then depend on that slave port. But that might create dependency issues
elsewhere.

Sub-packages might (eventually) allow you to work around this.

Cheers,
Freddie

Typos due to smartphone keyboard.

>
___
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: Any alternatives to NONE cipher ssh or bbcp for gigabit+ zfs send/recv?

[Freddie Cash]

On Thu, Aug 8, 2019 at 11:12 AM Ronald Klop  wrote:

> Does mbuffer do the job for you?
> <https://www.freshports.org/misc/mbuffer>


Actually, it appears it does.  :)  Doing google searches for Niclas'
suggestion of netcat brought up mbuffer.  Some quick testing shows that
should work for us.  Just doing a test run of our snapshot sending script
now.

Took a bit of finagling with the options and still have some work to get
the logging right, but it's working.

Thanks for the suggestions, everyone.

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

Any alternatives to NONE cipher ssh or bbcp for gigabit+ zfs send/recv?

[Freddie Cash]

We have gigabit fibre between our main data centre and our off-site data
centre across town.  We do zfs send/recv of our backups between the sites
over a dedicated gigabit fibre link.  Our ZFS storage servers are running
older AMD Opteron (pre-bulldozer) CPUs, so there's very little in the way
of encryption extension support.

Running zfs send/recv over regular SSH gives horrible throughput (100-250
Mbps max).

In the past, we compiled the openssh-portable port with the HPN patches and
NONE cipher.  That allowed us to saturate the gigabit link for zfs
send/recv and rsync transfers.  Then those were removed from the port and
base OpenSSH.  (There were patches floating around for awhile, but we try
not to build from source anymore.)

Then we found bbcp, which works great for the zfs send/recv process,
saturating the gigabit link.  Doesn't work for rsync, but that's okay (we
only use rsync for our regular backup process, and that's limited by the
remote school's Internet link).

An update [1] to the bbcp port broke some things, but we found the magical
combination of command-line options to make it work reliably in our
environment.  And a project was underway to update bbcp [2] to a newer
version and make it work better on FreeBSD, but it fizzled out.  And now
the bbcp port has been removed.

We have an archived copy of the bbcp package that works for us on FreeBSD
12 (amd64).  We'll continue to use that as long as it works (probably until
FBSD 12 is EoL).

Are there any alternatives to HPN/NONE cipher / bbcp to allow an older
Opteron system to saturate a gigabit link with zfs send/recv or rsync?
This is strictly over a private network, so encryption is only needed for
the authentication bit, not for the actual data transfer.  Preferably
something that's available in the ports tree as a binary package.  :)

Suggestions?

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197035
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229115

(Thanks to all who attempted to keep bbcp working on FreeBSD.  Sounds like
it wasn't much fun, but we really appreciate the effort.)

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

Re: FireFox and NFSv4

[Freddie Cash]

On Thu, Jun 13, 2019 at 8:36 AM Andrea Venturoli  wrote:

> Hello.
>
> For years I've had my home on an NFSv3 server.
> Finally I decided to move to NFSv4.
>
> Now the following happens every now and then (let's say, 1 out of 5
> times I launch it):
> _ FireFox is closed (no process running);
> _ I open FireFox and, while it works, a red message appears saying:
> "The bookmarks and history system will not be functional because one of
> Firefox's files is in use by another application. Some security software
> can cause this problem";
> _ I can close FireFox, but I'll have to wait for a while to reopen it,
> or I'll get the "Firefox is already running but not responding" window.
> _ After a while I can open it again with no warning.
>
> Nothing to really worry about, but I'm curious (and would like to be
> sure no latent problem is there).
>
> Of course I beleive the reference to "security software" does not apply
> to UNIX systems; I don't think anything is accessing FF files either.
>
> What should I check?
>

Seems to be a known issue with NFS storage of the .mozilla folder that's
made worse with NFSv4:

https://bugzilla.mozilla.org/show_bug.cgi?id=1428169

Has to do with file locking and race conditions in the multi-process setup,
and using SQLite databases for everything.

There's a couple of workaround listed in there (see comment 29) that work
for most people.

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

Re: Running into a problem with pkg-static install -f pkg

[Freddie Cash]

On Mon, Apr 8, 2019 at 8:06 AM The Doctor via freebsd-ports <
freebsd-ports@freebsd.org> wrote:

> On one server when I run pkg-static install -f pkg
>
> I get
>
> pkg-static install -f pkg
>
> pkg-static: Warning: Major OS version upgrade detected.  Running
> "pkg-static install -f pkg" recommended
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up to date.
> Updating Synth repository catalogue...
> pkg-static: Repository Synth load error: access repo
> file(/var/db/pkg/repo-Synth.sqlite) failed: No such file or directory
> pkg-static: file:///var/synth/live_packages/meta.txz: No such file or
> directory
> repository Synth has no meta file, using default settings
> pkg-static: file:///var/synth/live_packages/packagesite.txz: No such file
> or directory
> Unable to update repository Synth
> Error updating repositories!
>
> Why is this happening?
>

Check your repo configuration file.  It's trying to access a local Synth
repo under /var/synth/live_pacakges/ but there's nothing there, so it's
failing.  Comment out that repo, and it should pull down the pkg package
from the FreeBSD repo.

Check /etc/pkg/ and /usr/local/etc/pkg/ for the repo config files.

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

Re: Any way to prevent do-extract chmod and chown?

[Freddie Cash]

On Thu, Jun 28, 2018, 3:06 PM Mathieu Arnold,  wrote:

> On Thu, Jun 28, 2018 at 01:43:41PM -0400, Joseph Ward wrote:
> > Thank you.  I found that to be the case; even though changing the
> > "do-extract" target successfully staged the files and directories with
> > the original permissions, pkg create seems to strip them out again
> > without the pkg-plist additions.
> >
> > Are you aware of an easy/already existing command to create the
> > pkg-plist with the user/group/permissions items for each file, or is
> > that a script I'm going to have to write manually?  I'm currently using
> > the makeplist target as there are no subsitutions or anything else that
> > would screw up the default scenario.
>
> I am not aware of anything.  But if you already have "stuff" creating a
> big hierarchy with many users and groups, it may be easier to adapt
> "stuff" to generate a pkg-plist file, or maybe to split your ports into
> smaller, more manageable bits.
>
> make makeplist will give you a correct listing of files and
> directories, but as everything runs as a regular user, it cannot be
> aware of the users/groups you intend on using in the plist.
>

Isn't this something mtree can be used for?

Use it to generate a listing of the files, permissions, and ownership of a
tree, include the mtree output file in the port, and use a post-install
script to run mtree to set ownership/permission.

Cheers,
Freddie

Typos courtesy of my phone's keyboard.

>
___
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: When does a newly committed port become installable via 'pkg'?

[Freddie Cash]

On Jan 28, 2018 12:15 PM, "James E Keenan"  wrote:

Earlier today (about 0910 EST), thanks to Po-Chuan Hsieh, a new port I had
created was committed to the repository.  It was very quickly visible at
these locations:

https://svnweb.freebsd.org/ports/head/devel/p5-CPAN-Testers-Common-Client/
https://www.freshports.org/devel/p5-CPAN-Testers-Common-Client/

... and it has since become visible here as well:

https://www.freebsd.org/cgi/ports.cgi?query=p5-CPAN-Testers-
Common-Client=all=all

However, when I try to install that package onto my system (a VM running
FreeBSD-11.0-RELEASE), I continue -- six hours later -- to get messages
saying that the package cannot be located.

#
$> sudo pkg update
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.

$> sudo pkg install p5-CPAN-Testers-Common-Client
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching
'p5-CPAN-Testers-Common-Client' have been found in the repositories
#

What am I not understanding about this process?

Thank you very much.
Jim


The default pkg repository is the "quarterly" one (see /usr/local/etc/pkg)
which only gets new ports every 3 months.

You can switch to the "latest" repo, which gets rebuilt every Tuesday, I
believe.

Or build it from the ports tree which gets updated daily.


Cheers,
Freddie

Typos courtesy of my phone.
___
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: Help with versioning scheme

[Freddie Cash]

On Wed, Jan 17, 2018 at 10:40 AM, Martin Waschbüsch <mar...@waschbuesch.de>
wrote:

> Thanks, Freddie,
>
> Am 17.01.2018 um 19:35 schrieb Freddie Cash <fjwc...@gmail.com>:
>
> On Wed, Jan 17, 2018 at 10:29 AM, Martin Waschbüsch <mar...@waschbuesch.de
> > wrote:
>
>> Hi Adam,
>> > Am 17.01.2018 um 19:19 schrieb Adam Weinberger <ad...@adamw.org>:
>> > Hi Martin,
>> >
>> > You don't want to use the upstream version to represent PORTREVISION.
>> PORTREVISION is for when you need to force rebuilds of the port itself, and
>> so tying it to upstream would make it impossible to bump it ourselves.
>> >
>> > Why do you need to ignore the fourth digit? It's perfectly valid for
>> our purposes.
>>
>> So far, I had (because it coincided with their version number) used it to
>> provide SO_VER. But that breaks now:
>>
>> ---
>> # Created by: adamw
>> # $FreeBSD: head/archivers/liblz4/Makefile 448415 2017-08-20 12:30:25Z
>> sunpoet $
>>
>> PORTNAME=   lz4
>> PORTVERSION=1.8.1
>> DISTVERSIONPREFIX=  v
>> PORTEPOCH=  1
>> CATEGORIES= archivers
>> PKGNAMEPREFIX=  lib
>>
>> MAINTAINER= mar...@waschbuesch.de
>> COMMENT=LZ4 compression library, lossless and very fast
>>
>> LICENSE=BSD2CLAUSE GPLv2
>> LICENSE_COMB=   multi
>>
>> USES=   gmake pathfix pkgconfig
>> USE_GITHUB= yes
>> USE_LDCONFIG=   yes
>> #PATHFIX_MAKEFILEIN=Makefile
>>
>> ALL_TARGET= default # don't remove this
>> SO_VER= ${PORTVERSION}
>> PLIST_SUB+= SO_VER=${SO_VER} SO_VER_MAJ=${SO_VER:R:R}
>>
>
> ​Why can't you do something like the above to get SO_VER?
>
> PORTVERSION=1.8.1.2
> SO_VER=${PORTVERSION:R:R:R)
>
> Similar to how you get SO_VER_MAJ out of SO_VER.​
>
>
> That is true. Do you think this is a robust solution, though?
> Or is the whole relying on upstream variables idea problematic?
>

​So long as they continue to have ​4 digit version numbers (meaning 1.9.0.0
and not just 1.9), then everything will be fine.

If upstream does weird things with their version numbers (1.8.1.2 --> 1.8.2
--> 1.9 --> 2 --> 2.1 --> 2.1.1 --> 2.1.1.1), then you'll have to manually
massage things in the port Makefile with each update.

Hopefully, they don't do that, and keep things logical (1.8.1.2 --> 1.8.2.0
--> 1.9.0.0 --> 2.0.0.0 --> 2.1.0.0 --> 2.1.1.0 --> 2.1.1.1) which would
make things simpler on your end.  :)


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

Re: Help with versioning scheme

[Freddie Cash]

On Wed, Jan 17, 2018 at 10:29 AM, Martin Waschbüsch <mar...@waschbuesch.de>
wrote:

> Hi Adam,
> > Am 17.01.2018 um 19:19 schrieb Adam Weinberger <ad...@adamw.org>:
> > Hi Martin,
> >
> > You don't want to use the upstream version to represent PORTREVISION.
> PORTREVISION is for when you need to force rebuilds of the port itself, and
> so tying it to upstream would make it impossible to bump it ourselves.
> >
> > Why do you need to ignore the fourth digit? It's perfectly valid for our
> purposes.
>
> So far, I had (because it coincided with their version number) used it to
> provide SO_VER. But that breaks now:
>
> ---
> # Created by: adamw
> # $FreeBSD: head/archivers/liblz4/Makefile 448415 2017-08-20 12:30:25Z
> sunpoet $
>
> PORTNAME=   lz4
> PORTVERSION=1.8.1
> DISTVERSIONPREFIX=  v
> PORTEPOCH=  1
> CATEGORIES= archivers
> PKGNAMEPREFIX=  lib
>
> MAINTAINER= mar...@waschbuesch.de
> COMMENT=LZ4 compression library, lossless and very fast
>
> LICENSE=BSD2CLAUSE GPLv2
> LICENSE_COMB=   multi
>
> USES=   gmake pathfix pkgconfig
> USE_GITHUB= yes
> USE_LDCONFIG=   yes
> #PATHFIX_MAKEFILEIN=Makefile
>
> ALL_TARGET= default # don't remove this
> SO_VER= ${PORTVERSION}
> PLIST_SUB+= SO_VER=${SO_VER} SO_VER_MAJ=${SO_VER:R:R}
>

​Why can't you do something like the above to get SO_VER?

PORTVERSION=1.8.1.2
SO_VER=${PORTVERSION:R:R:R)

Similar to how you get SO_VER_MAJ out of SO_VER.​

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

Re: Again, flavors or options?

[Freddie Cash]

On Dec 20, 2017 6:16 PM, "Yuri"  wrote:

I have the port for the digital currency. It has 3 parts that install
non-intersecting file sets: daemon, cli, qt-ui. The commonality: same
repository, same build options, same license, mostly same port options.

I am attracted to the idea to use flavors to let users choose which part do
they want: FLAVORS=default daemon qt cli

"default" will install all of them, others will install individual parts.
Option list will be slightly different for each flavor.

One alternative: only have port options. Then some options can't be
conditional on which parts are built.

Another alternative: 3 slave ports. I don't like this idea at all.

Do you think flavors are a good fit for this task?


Sounds like a textbook example of sub-packages.

Until then, slave ports would be the next-best thing as that provides
separate packages that can be installed.

Cheers,
Freddie
___
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: Re: OSS Audio

[Freddie Cash]

On Fri, Dec 15, 2017 at 2:30 AM, Sid <s...@bsdmail.com> wrote:

> That's good that Jack isn't needed.
> It appears, as of the last few months or year, OSS is able to play sounds
> from different programs simultaneously.
>

​FreeBSD has had the ability to play sounds from multiple programs
simultaneously since the 4.x days.  Back then, the kernel developed a
"virtual channels" layer to accommodate this (program X uses /dev/dsp0,
program Y uses /dev/dsp1, program Z uses /dev/dsp2, audio is mixed and
played out the speakers together).  Later this was done automatically by
multiple programs simply accessing /dev/dsp.

This was one of the nicer features of FreeBSD 4.x; especially considering
the giant cluster-F that audio was on Linux at the time.  Their OSS
implementation was limited to a single program accessing /dev/dsp at a
time, and led to the development of all kinds of userland audio daemons and
mixers, and started them down the road to ALSA and eventually PulseAudio
(rather than simply fixing the issue in their OSS implementation).

KDE 3.x on FreeBSD 4.x was a multimedia wonder and so easy to get working
compared to KDE 3 on Linux.  KDE 4 and Phonon made this even nicer.

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

Re: Updating ports that use FLAVOR with portmaster

[Freddie Cash]

On Fri, Dec 8, 2017 at 12:31 PM, Paul Schmehl <pschmehl_li...@tx.rr.com>
wrote:

> How do you do this? I have a number of py ports that need to be updated,
> but portmaster chokes on them. I don't see anything about FLAVOR in the man
> page. Do we actually have to update all these ports manually, one at a time?
>

​You wait patiently while portmaster is updated to support FLAVORs.  The
work is in progress, although there is no ETA on when it will be ready for
testing.

If you can't wait, then you can look into poudriere or synth.  They both
support FLAVOR already.

Or, do manual "pkg remove; make install" for each one.

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

Fwd: Re: Time for a firefox-56 port?

[Freddie Cash]

Forgot to include the list.

Cheers,
Freddie
-- Forwarded message --
From: "Freddie Cash" <fjwc...@gmail.com>
Date: Nov 25, 2017 8:25 PM
Subject: Re: Time for a firefox-56 port?
To: "Greg 'groggy' Lehey" <g...@freebsd.org>
Cc:

On Nov 25, 2017 6:38 PM, "Greg 'groggy' Lehey" <g...@freebsd.org> wrote:
>
> On Saturday, 25 November 2017 at 19:33:18 -0600, Zhihao Yuan wrote:
> > On Nov 25, 2017 6:31 PM, "Greg 'groggy' Lehey" <g...@freebsd.org> wrote:
> >
> >> I'm sure I'm not the only person who relies on old addons.  How
> >> about a firefox-56 port until the current problems die down?
> >
> > Here is a port for the Palemoon browser:
> >
> >   https://www.freshports.org/www/palemoon/
>
> It doesn't address the addon issue.  I expect that gradually the
> addons will get updated to the new interfaces, so this is just a
> temporary thing.
>
>
> Pale Moon, Water Fox, and another one I can't remember, are forks of
> Firefox. They try to keep up with the latest features under the hood, but
> keep the old XUL based interface, and the older style of default GUI. They
> support add-ons and plugins, but they may lag a version or two behind in
> features.
>
> Haven't personally used them, but everytime Mozilla makes a hard break
> with something (UI, plugins, and now add-ons), more users migrate over to
> them.
>
> Cheers,
> Freddie
>
___
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: Time for a firefox-56 port?

[Freddie Cash]

On Nov 25, 2017 7:50 PM, "Greg 'groggy' Lehey"  wrote:

On Saturday, 25 November 2017 at 22:27:47 -0500, Adam McDougall wrote:
> On 11/23/2017 20:11, Greg 'groggy' Lehey wrote:
>> I've just installed the latest version of firefox and confirmed that
>> it breaks both of the addons that make firefox bearable for me
>> (firemacs, https://addons.mozilla.org/en-US/firefox/addon/firemacs/
>> and It's All Text!,
>> https://addons.mozilla.org/en-US/firefox/addon/its-all-text/).  So I
>> can't use it.
>>
>> I'm sure I'm not the only person who relies on old addons.  How about
>> a firefox-56 port until the current problems die down?
>
> I think www/firefox-esr would give you something like 6 months more of
> pre-57 codebase?

Yes, I saw that, but the pkg-descr doesn't say what good it is, and
the Makefile shows that it's based on 52.5.0, which seems to be rather
older than necessary.

> https://www.mozilla.org/en-US/firefox/organizations/faq/

Thanks.  That helps.  I've updated pkg-descr.  It also shows that
52.5.0 in fact corresponds to Firefox 57, so the port doesn't help
after all.


No, the ESR codebase is still pre-57 for features (meaning add-ons still
work). But it's caught up to 57 for all security/stability fixes.

The ESR version gets updated every 6 weeks, same as the normal version. But
it doesn't get (many) new features and functionality, just security and
stability fixes.

This is what you want to be running if you want if you want to keep using
add-ons (and plugins). They will be supported until June 2018.

It's what we've moved to at work as we (unfortunately) still need Java
plugin support.

Cheers,
Freddie
___
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: Package database problems

[Freddie Cash]

On Thu, Nov 16, 2017 at 11:04 AM, Paul Schmehl <pschmehl_li...@tx.rr.com>
wrote:

> That's the problem. The package that installed that file is not installed.
> Nor is the file in the location pkg complains about. Yet, it still
> complains of a conflict and refuses to install the package I'm trying to
> install.
>
> For example, I tried to upgrade devel/oniguruma. It complained about a
> conflict with oniguruma5, specifically /usr/local/bin/onig-config. That
> file does not exist, nor is onigurum5 installed.
>

​Install onigurum5, then remove it.  Try to install onigurum.  That should
reset things in the database.
​

> I wish there was a pkg command like rebuild-db that would iterate through
> /var/db/pkg and create a valid local.sqlite file that registers the
> packages currently existing on the server.


​There's nothing to iterate over.  There's nothing in /var/db/pkg anymore
except the SQLite databases.

The only way to "rebuild" local.sqlite is to reinstall everything.

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

Re: portmaster, portupgrade, etc

[Freddie Cash]

On Wed, Oct 4, 2017 at 1:56 PM, Grzegorz Junka <li...@gjunka.com> wrote:

>
> On 04/10/2017 20:43, Mark Linimon wrote:
>
>> On Wed, Oct 04, 2017 at 08:13:16PM +, Grzegorz Junka wrote:
>>
>>> I was trying
>>> to compile with the system that was being updated at the
>>> same time - this can't possibly work (or can it?).
>>>
>> It works somewhere between "quite often" to "nearly all
>> the time".  It can vary depending on the complexity of
>>
>
> Well, that's not my experience. For me it worked occasionally at best. A
> few times the system became so broken that many applications couldn't be
> opened any more and I had to spend hours to restore it to some kind of
> usability. Even with poudriere I still manage to break the ports quite
> often by setting various options not to their recommended values - see
> defects I have been raising on https://www.freebsd.org/suppor
> t/bugreports.html But at least I am not able to install them until they
> are fixed.
>
> Maybe I am just too ambitious or maybe poudriere is more idiot-proof? I
> guess portmaster or portupgrade may work fine if one uses the default
> options, but in that case, hey, why bother? Just use the compiled packages!
> If you try to change some ports to non-default options, and something
> doesn't compile, portmaster/portupgrade will leave the system in half-baked
> state. And then only heavens can help...


​The nice thing about poudriere is that it doesn't affect the running
system.  The act of creating the package repo is completely separate from
the act of installing packages.  The two steps can be done on a single
system, or on separate systems.

During the creation of the package repo via poudriere, nothing on the
client system is affected; nothing is installed, nothing is uninstalled.
One can continue to use the system, which is great for desktops and
critical servers alike.

If there's an issue compiling a port in the middle of a long dependency
chain in poudriere, the process stops and you work to fix it.  Nothing you
do at this point affects any of the client(s).  If you can't get it fixed,
you don't have to worry about rolling back versions on the client(s) to get
things back to a working state.

Only once you have everything compiled and packaged up do you worry about
the client system(s).  And there, the pkg system takes over and handles
everything.  It's pretty much a "everything works or nothing gets
installed" process at that time (with very few corner cases that break
things).

It's not bulletproof, but it's a lot safer than compiling things on the
live system where some compiler bits are picked up from the ports build
tree, while other bits are picked up from the live filesystem, while some
things are auto-detected based on other installed ports, while some things
are skipped for the same reason, etc.

Will there be situations where you want to compile directly on the client?
Maybe.  Will there be many people that need that against all other
options?  Not really.

the ports you have installed, what state the tree is in,
>> how much the ports you use are often used by others, and
>> subtle differences in changes to port dependencies.
>>
>> This is complex enough to be indistinguishable from "phase
>> of the moon."
>>
>> In this case I really wish I were joking.
>>
>
​I used to love compiling everything on my home systems and work systems.
Then KDE upgrades kept leaving me with a broken system due to enabling some
esoteric OPTIONS that I thought I needed and portmaster would fail in the
middle of the umpteen-level-deep dependency chain.  I could usually get
things back to a working, upgraded state, but that usually left me without
a working GUI for 2-4 days.  The introduction of pkg has alleviated me of​
that need.  :)  I don't even have /usr/ports installed on my home or work
systems anymore.

After ending up with a broken server at work for the same reason I switched
those to using pkg only.  I played with poudriere back in the early days
and it was easy to work with.  But I found myself setting fewer and fewer
custom OPTIONS so the need for it diminished with time.  Debated playing
with it at work to get a custom OpenSSH package (for NONE encryption), but
I found other ways to do the same.

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

Re: portmaster, portupgrade, etc

[Freddie Cash]

On Wed, Oct 4, 2017 at 10:15 AM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:

> On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:
> >
> > Poudriere really needs its own small book. Yes, you can do simple
> > poudriere installs, but once you start covering it properly the docs
> > quickly expand. My notes alone are longer than my af3e chapter
> > limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
> > 2018).
>
> Please include a discussion on how to use poudriere on
> a system with limited resouces (e.g., 10 GB of free
> diskspace and less than 1 GB free memory).  I know
> portmaster works well [1] within an environment with
> only 4 GB free diskspace and 1 GB memory.
>

​Pretty sure the standard response will be along the lines of:​

By using pkg to fetch/install binary packages that were built by, and are
hosted​ on, a separate box that does nothing but run poudriere to build the
package repo using your custom specifications and OPTIONS, obviously.  :)

Why compile ports directly on a box that is so hardware constrained that it
will take multiple hours to do, when a "pkg update; pkg upgrade" takes only
a few minutes?

​:)


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

Fwd: Re: bapt@ back on portmgr

[Freddie Cash]

-- Forwarded message --
From: "Freddie Cash" <fjwc...@gmail.com>
Date: Jun 8, 2017 9:57 PM
Subject: Re: bapt@ back on portmgr
To: "Thomas Mueller" <mueller6...@twc.com>
Cc:



On Jun 8, 2017 9:54 PM, "Thomas Mueller" <mueller6...@twc.com> wrote:

from René Ladan:

> it is our pleasure to announce that Baptiste Daroussin (bapt@) is back on
portmgr.

Is this a new port in the works, or is portmgr a (confusing) abbreviation
for portmanager?


It's an abbreviation for portmanager, the team that manages the ports tree
infrastructure aka port...@freebsd.org

Cheers,
Freddie
___
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: Hosting distfiles on HTTPS w/Let's Encrypt - how?

[Freddie Cash]

On Jun 1, 2017 4:06 PM, "Marcin Cieslak"  wrote:

On Thu, 1 Jun 2017, Jov wrote:

> can you dowload the file distfiles/INIT.2014-12-24.tgz
>  using
> browser such as chrome？

Yes, Firefox, IE11, no certificate warnings.

> be sure to use full chain cert file，I rember I had similar problem and use
> full chain cert fixed.

(Without the root CA):


Certificate chain
 0 s:/CN=marcincieslak.com
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

How should fetch know that "=Digital Signature Trust Co./CN=DST Root CA X3"
is
a valid CA if none have been installed?

Marcin Cieślak


In your web server configuration, are you using the Let's Encrypt cert.pem
or fullchain.pem?

If you use the former, then any client that doesn't have the DST Root CA
pre-installed will error out. The latest versions of browsers will work, as
they include the DST Root CA.

If you use the latter, then it will just work, as the server will send all
the intermediate certificate info needed to reach the root.

Cheers,
Freddie
___
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: sysutils/tmux - strange behaviour with new version 2.4

[Freddie Cash]

On Tue, May 16, 2017 at 12:51 PM, Miroslav Lachman <000.f...@quip.cz> wrote:

> Freddie Cash wrote on 2017/05/16 21:27:
>
>> On Tue, May 16, 2017 at 12:18 PM, Miroslav Lachman <000.f...@quip.cz>
>> wrote:
>>
>
> [snip]
>
> # env | grep TERM
>>> TERM=screen-256color
>>>
>>> And missing lines are different on each run.
>>>
>>>
>> ​Just curious, but what happens if you set TERM=tmux instead of
>> TERM=screen?  Newer versions of tmux accept that as an option, and the
>> termcap/terminfo should be cleaner/more up-to-date than the screen
>> setting.​
>>
>> ​From:​
>>
>> https://www.freebsd.org/cgi/man.cgi?query=tmux=1
>> opos=0=FreeBSD+11.0-RELEASE+and+Ports
>>
>> ​"​default-terminal terminal
>>  Set the default terminal for new windows created in this session
>>  - the default value of the TERM environment variable.  For tmux
>>  to work correctly, this must be set to `screen', `tmux' or a
>>  derivative of them."
>>
>
> I tried this in ~/.tmux.conf:
>
> set -g default-terminal "tmux"
>
> But when I run tmux command I got this error:
>
> tcsh: Cannot open /etc/termcap.
> tcsh: using dumb terminal settings.
>
> I think there is no tmux entry in /etc/termcap on FreeBSD 10.3
>
> And tmux output with dumb terminal is still misbehaving.


​Yeah, looks like there's no tmux entry in termcap/terminfo on FreeBSD (at
least according to SVN web).  So much for following the man page.  ;)

I'll go back to lurking now ...

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

Re: sysutils/tmux - strange behaviour with new version 2.4

[Freddie Cash]

On Tue, May 16, 2017 at 12:18 PM, Miroslav Lachman <000.f...@quip.cz> wrote:

> Tommy Scheunemann wrote on 2017/05/16 20:48:
>
>> Le 16.05.2017 à 13:53, Miroslav Lachman a écrit :
>>
>>> David Wolfskill wrote on 2017/05/16 13:35:
>>>
>>>> Oddly enough, I saw the distinction you pointed out... even though I
>>>> read mail via mutt in a tmux window  :-}
>>>>
>>>
>>> Uhm... maybe it depends on source of the text? Or locale?
>>>
>>
>> Hi,
>>
>> I've been able to re-produce the issue, though setting:
>>
>> set -g default-terminal "screen-256color"
>>
>> in your tmux.conf seemed to help. Tested both under console and inside a
>> running urxvt.
>> Without that line:
>>
>> env | grep TERM
>>
>> gives me just "screen", having it set the above value. Dunno if that
>> might be related to /etc/termcap the screen line that exists (note -
>> dunno, unsure, just a guess).
>>
>
> I tried your suggestion with screen-256color but it doesn't help.
>
> Many lines are missing:
> ​
>
>
> # env | grep TERM
> TERM=screen-256color
>
> And missing lines are different on each run.
>

​Just curious, but what happens if you set TERM=tmux instead of
TERM=screen?  Newer versions of tmux accept that as an option, and the
termcap/terminfo should be cleaner/more up-to-date than the screen setting.​

​From:​

https://www.freebsd.org/cgi/man.cgi?query=tmux=1=0=FreeBSD+11.0-RELEASE+and+Ports

​"​default-terminal terminal
Set the default terminal for new windows created in this session
- the default value of the TERM environment variable.  For tmux
to work correctly, this must be set to `screen', `tmux' or a
derivative of them."

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

Re: pkg and packages

[Freddie Cash]

On Sun, May 7, 2017 at 4:14 AM, <scratch65...@att.net> wrote:

> [Default] On Sat, 06 May 2017 00:11:00 +0200, Sebastian Schwarz
> <sesch...@gmail.com> wrote:
>
> >On 2017-05-04, scratch65...@att.net wrote:
> >> I can't imagine what code could possibly be in thunar and
> >> samba that the xfce desktop would need, (...)
> >
> >Thunar is used to display the icons on the XFCE desktop.  It
> >depends on gvfs, which is used for accessing remote file systems
> >and the trash inside Thunar.  gvfs in turn depends on samba44 in
> >order to access CIFS/SMB shares.
> >
> >Strictly speaking some of these features might be optional.  But
> >as far I know pkg currently doesn't have a concept of optional
> >dependencies.  So it's an all or nothing decision, when building
> >the packages.
>
> It's really not even "strictly speaking".  They always should be
> separate installs, not ever bundled together.
>
> What use can someone have for samba who doesn't have any windows
> boxes?
>
> And since samba is the guy who does all the work to make  the
> freebsd filesystems look non-threatening to windows, why, really,
> is gvfs needed at all?  As far as I'm aware, there's no way,
> short of finding and installing a copy of that old, unsupported
> windows nfs client, for freebsd to access a windows box..
>

​Samba + GVFS + Thunar doesn't make your FreeBSD filesystems available from
Windows machines.  It makes your Windows file shares available on FreeBSD,
and they show up in Thunar just like other folders.  GVFS uses libsmbclient
and/or smbclient itself to access the CIFS/SMB shares, and abstracts all
that away to make it look like just another folder.​

I'm not sure how Thunar / GVFS would react if you removed support for SMB
shares.  Maybe it just wouldn't show that option in the GUI?  Maybe it
would leave the option in the GUI, but would error out when you try to use
it?


> And thunar doesn't seem to require the desktop (when are icons
> placed on the desktop?  I can't recall ever seeing that), since
> after my desktop was discarded during the general upgrade, the
> panels, icons, and thunar all continued to function as before,
> which since xfce is a modular, loosely-coupled system, was not
> unexpected.


​Icons are placed on the desktop when you place them there.  I don't think
there aren't any there by default.  We use XFce for the desktop GUI in our
schools, and we place a handful of icons on the desktop by default for
students (with a different selection of icons for staff), along with a
small selection of icons in the taskbar as well.

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

Re: How to use cached packages

[Freddie Cash]

On Thu, Apr 20, 2017 at 1:36 PM, Miroslav Lachman <000.f...@quip.cz> wrote:

> Freddie Cash wrote on 2017/04/20 22:17:
>
>> On Thu, Apr 20, 2017 at 11:58 AM, Patrick Powell <papow...@astart.com>
>> wrote:
>>
>> I ran into a problem where I needed to reinstall a package. However,  I
>>> did not have network access to the pkg repository.  I did have a system
>>> which had all of the pkgs which I needed in the pkg cache.  I can easily
>>> copy these to the system,  as well as the pkg database, etc.
>>>
>>> So:  is there a SIMPLE way to have pkg check to see if a pkg is already
>>> in
>>> the pkg cache and use that before trying to go to the repository?
>>>
>>> Is there a SIMPLE way to prevent pkg from trying to check the pkg
>>> repository for an update?
>>>
>>> I strongly suspect that something like:
>>>
>>> pkg --do_not_check_for_latest_version --use_cached_pkg install firefox
>>>
>>> Any help on this before I tear out the three strands of hair I have left
>>> would be appreciated.
>>>
>>
>>
>> ​If you have the .txz/.tbz package file, then it's a simple:
>>
>> # pkg install /path/to/firefox-versions-blahblah.txz
>>
>
> I think it is "pkg add /var/cache/pkg/firefox-versions-blahblah.txz"
>

​Both work.  "pkg add" is there for backward compat with the old way
(pkg_add).  "pkg install" can install from remote repos or local files.
From the man pages:

​DESCRIPTION
 pkg install is used for installation of packages from package reposito-
 ries or local archives.  Multiple package names can be specified on the
 command line, either explicitly or by matching against package names
(or
 origins) in the repository catalogues using shell globbing or regular
 expressions.


DESCRIPTION
 pkg add installs packages from either a local source or a remote one.

 When installing from a remote source you need to specify the protocol
to
 use when fetching the package.


​For ease of use, "pkg install" works for everything.  :)​

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

Re: How to use cached packages

[Freddie Cash]

On Thu, Apr 20, 2017 at 11:58 AM, Patrick Powell <papow...@astart.com>
wrote:

> I ran into a problem where I needed to reinstall a package. However,  I
> did not have network access to the pkg repository.  I did have a system
> which had all of the pkgs which I needed in the pkg cache.  I can easily
> copy these to the system,  as well as the pkg database, etc.
>
> So:  is there a SIMPLE way to have pkg check to see if a pkg is already in
> the pkg cache and use that before trying to go to the repository?
>
> Is there a SIMPLE way to prevent pkg from trying to check the pkg
> repository for an update?
>
> I strongly suspect that something like:
>
> pkg --do_not_check_for_latest_version --use_cached_pkg install firefox
>
> Any help on this before I tear out the three strands of hair I have left
> would be appreciated.


​If you have the .txz/.tbz package file, then it's a simple:

# pkg install /path/to/firefox-versions-blahblah.txz
​
​I believe you can specify multiple packages on the command-line and it
will install them all.  If there are required dependencies, you'll have to
specify them on the command-line as well.  If you specify all the packages
on the CLI, then it won't check the remote repo.

There's also a flag you can add to prevent it from doing a
behind-the-scenes "pkg upgrade" before the​ install.  Ah yes, it's -U or
--no-repo-update.


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

Re: Is pkg quarterly really needed?

[Freddie Cash]

On Tue, Apr 18, 2017 at 7:57 AM, krad <kra...@gmail.com> wrote:

> quarterly does seem very cautious, maybe a monthly might be a good
> alternative. I can understand people being hesitant about latest though. I
> guess these are not the people who ask though. Maybe the real answer though
> is to have a specific repo for that port for the bleeding edge people  much
> like launchpad on ubuntu. It might get complicated though for big
> dependency trees though.
>

​latest/ is good for desktop users who only care about running the very
latest versions of everything.

quarterly/ is good for server users who want to make sure that installing a
new piece of software won't require an upgrade of all the currently
installed software (repo hasn't changed since the last install).  And for
desktop users who prefer to use their computers for doing work instead of
spending all their time chasing after the "latest" flashy bling bling.  :)

quarterly/ also gets security fixes back-ported into it (on a
per-maintainer basis so it's not 100% coverage yet), so you can stay secure
without chasing new software versions.

IOW, don't change the infrastructure, it's working nicely.  Just educate
the users.  :D



>
> On 18 April 2017 at 14:54, qjail1 <qja...@a1poweruser.com> wrote:
>
> > I maintain a port and I have users complaining that the pkg system takes
> > many months before the updated version of my port shows up in the pkg
> > system.
> >
> > My response is I tell them to change a line in their
> /etc/pkg/FreeBSD.conf
> > file
> > from url: "pkg+http://pkg.Freebsd.org/${ABI}/quarterly;,
> > to   url: "pkg+http://pkg.Freebsd.org/${ABI}/latest;,
> >
> > The old pkg system never had this quarterly update cycle and I see no
> > reason to have it now when its so easy to over ride the default.
> >
> > Why not just change the default to "latest" and save on all the overhead
> > of the quarterly cycle?
> > ___
> > freebsd-questi...@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > To unsubscribe, send any mail to "freebsd-questions-unsubscribe
> > @freebsd.org"
> >
> _______
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>



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

Re: Best way to cause synth to ignore rebuilding of a port??

[Freddie Cash]

On Wed, Mar 8, 2017 at 11:57 AM, Bob Willcox <b...@immure.com> wrote:

> On Wed, Mar 08, 2017 at 10:40:11AM -0800, Freddie Cash wrote:
> > On Wed, Mar 8, 2017 at 8:04 AM, Bob Willcox <b...@immure.com> wrote:
> >
> > > What is the best way to get synth to simply ignore certain ports when
> > > running
> > > the upgrade-system command with it? I would like for it to not upgrade
> > > firefox
> > > (don't want to lose my tab groups) so I'd rather that it not even
> consider
> > > updating firefox again, at least not till some form of tab groups are
> again
> > > supported.
> > >
> > > Note that I haven't tried ver 52 of firefox, but from what I've read it
> > > sounds
> > > like all plugins/addons other than flash are no longer supported.
> > >
> >
> > ???Switch to the ESR version, and all NPAPI plugins will be enabled and
> > supported until around May of next year.  :)
> >
> > Firefox 52    disables everything except Flash.
> > Firefox 52ESR leaves everything enabled.???
> >
> > ???https://bugzilla.mozilla.org/show_bug.cgi?id=1269807
> > ???
> >
> > --
> > Freddie Cash
> > fjwc...@gmail.com
>
> Yeah, but isn't the ESR version relatively down-level WRT to version 51
> that
> I'm currently using? The Makefile in www/firefox-esr has a verison of
> 45.8.0.
>
> Not anxious to go backwards on everything.
>
> ​52ESR was just released.  Give the ports maintainer time to get it into
the tree.  :)  (Note, I don't have Firefox on FreeBSD at the moment so just
going by what's released online, not what's available in the ports tree.)​


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

Re: Best way to cause synth to ignore rebuilding of a port??

[Freddie Cash]

On Wed, Mar 8, 2017 at 8:04 AM, Bob Willcox <b...@immure.com> wrote:

> What is the best way to get synth to simply ignore certain ports when
> running
> the upgrade-system command with it? I would like for it to not upgrade
> firefox
> (don't want to lose my tab groups) so I'd rather that it not even consider
> updating firefox again, at least not till some form of tab groups are again
> supported.
>
> Note that I haven't tried ver 52 of firefox, but from what I've read it
> sounds
> like all plugins/addons other than flash are no longer supported.
>

​Switch to the ESR version, and all NPAPI plugins will be enabled and
supported until around May of next year.  :)

Firefox 52disables everything except Flash.
Firefox 52ESR leaves everything enabled.​

​https://bugzilla.mozilla.org/show_bug.cgi?id=1269807
​

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

Re: libstdc++

[Freddie Cash]

On Wed, Jan 11, 2017 at 2:29 PM, Dave Horsfall <d...@horsfall.org> wrote:

> On Wed, 11 Jan 2017, Adam Weinberger wrote:
>
> > Okay. So what command did you use to rebuild all your ports? You won't
> > really be able install anything new until you've rebuilt everything.
> > Everything.
>
> Haven't had a chance to try your script yet; been too busy trying to get
> my nameserver to support my internal domain ".kfu" (yes, it's 10.3); it
> doesn't even work on the box itself, but the resolver is fine.  My guess
> is that something has changed in BIND...
>
> > I'm not aware of any problems building alpine on 10.3. I do see a typo
> > in its OpenSSL handling and I'll fix that shortly.
>
> That's the only problem with Alpine; it's not seeing "1.0.2j" of OpenSSL,
> yet wants ">= 1.0.1c", hence the 9.3 version...  It was critical that I
> get email working ASAP, and this is the only FreeBSD box I have.
>
> > If you keep running into headaches upgrading in-place, you should really
> > switch to poudriere. Even if you get stuff working, you should really
> > switch to poudriere. See
> > https://www.freebsd.org/handbook/ports-poudriere.html for how to get up
> > and running with it.
>
> I thought poudriere was for building packages to support a server farm?
>
> Sorry for all this, but until now this box has always been on 9.x, so this
> is my first major upgrade, hence I have zero experience...
>

​Don't manually "install" libraries from previous versions.  Instead, use
the "compat9x" port; it's what it's there for.  This will install onto a
10.x or 11.x box all the libraries from a 9.x install that are no longer
present, but puts them into /usr/local/.  The linker that comes with
FreeBSD knows to look there​, so no changes required.

An upgrade from 9.x to 10.x looks something like this (for minimal
downtime):
  - upgrade the base OS using freebsd-update or build world
  - install the compat9x port so that your currently installed ports
continue to work
  - rebuild/reinstall *ALL* ports currently installed so that they link
against the new versions of libraries
  - remove the compat9x port
  - reboot to make sure everything is restarted and using the correct
libraries

By using the compat9x port, you can take your time upgrading the installed
ports.  But you *MUST*, eventually, reinstall them all.  Don't try to
upgrade the ports piecemeal.  They all need to be reinstalled when going
across major OS versions.

An easier, "faster", safer way to do an upgrade across major versions is to
use a custom pkg repo (built using poudriere or synth).  That way, all your
ports are built with the options you want, but are not installed anywhere
on the system; just pkg files are created.  You continue to use the
currently installed ports, via the compat9x libs, until the repo is built
with all your desired ports.

Then, the upgrade of the installed ports is as simple as:
  - pkg update
  - pkg upgrade

No muss, no fuss, minimal downtime for replacing the actual ports.

​Between freebsd-update and pkg, maintaining and upgrading FreeBSD boxes
has become almost point-n-click easy.  And with the introduction of
poudriere (and to a lesser extent synth), you can get all the benefits of
custom compiled ports with all the benefits of binary package
installs/upgrades.
​
-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: No port should need root for make fetch

[Freddie Cash]

On Wed, Dec 14, 2016 at 12:37 AM, Akinori MUSHA <k...@idaemons.org> wrote:

> Hi,
>
> Thanks for the info.
>
> On Wed, 14 Dec 2016 05:32:36 +0900,
> Julian H. Stacey wrote:
> > Hi ports@
> > IMO No port should need root for
> >   cd /usr/ports; make -i fetch
> > The first one that broke for me was databases/mysql-q4m
> > (OK might be others before, but I have DUDS =
> >arabic biology chinese hebrew hungarian japanese korean
> >polish portuguese russian ukrainian vietnamese games demime
> >majordomo acroreadwrapper acroread9 chimera dosbox emil
> >firefox freerdp gimp-app gv libcue mp3splt-gtk nut opera
> >ripit vlc xorg xsane
> > )
> > (MAINTAINER CC'd) but there's more ports beyond, usually because
> > some ports also go berserk & install, or mabe install dependents.
>
> Having the dependency as FETCH_DEPENDS [*] was not my idea, but that
> was for a reason: you should not fetch a file while building a port.
>
> * https://svnweb.freebsd.org/ports/head/databases/mysql-
> q4m/Makefile#rev297196


​Shouldn't this be split into two, then?

​FETCH_DEPENDS+=
${NONEXISTENT}:${PORTSDIR}/databases/mysql${MYSQL_VER}-server:fetch

BUILD_DEPENDS+=
${NONEXISTENT}:${PORTSDIR}/databases/mysql${MYSQL_VER}-server:build

​That way, only the fetch target is run on the mysql-server port when
running the fetch target on the mysql-q4m port.  And the build target is
run on the mysql-server port when the build target is run on the mysql-q4m
port.

Or is there no :fetch support in the _DEPENDS framework?​

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

Re: No port should need root for make fetch

[Freddie Cash]

On Tue, Dec 13, 2016 at 2:01 PM, Matthias Andree <matthias.and...@gmx.de>
wrote:

> Am 13.12.2016 um 22:35 schrieb Julian H. Stacey:
> >
> >> How is that a problem of "some" ports? All ports require root for "make
> >> fetch"
> > No they dont.
>
> Given that, then "none do".
>
> I'll do what what you omitted in your blind rage, I've dug the important
> detail up for you, which was the first guess:
>
> $ grep _DEPENDS Makefile /dev/null
> /usr/ports/databases/mysql-q4m/Makefile:FETCH_DEPENDS+=
> ${NONEXISTENT}:${_MYSQL_SERVER}:build
>
> This doesn't say "give me root". It needs to be able to build the
> requisite port.



> Obviously the fix is to make sure that if you want to fetch as
> unprivileged user, that you can also *build*.
> I assume that if you want *fetch* as unprivileged user, that you also
> want to *build* as unprivileged user, so I'd take that for granted, but
> it's not the case on your system.
>
> On my system, which has a WRKDIRPREFIX that I am permitted to write to
> with the unprivileged user account doing the builds, "make fetch" for
> mysql-q4m passes without a hitch.
>
> > Thanks for the well intentioned & good advice Matthias,
> > But some few ports are truly Badly Behaved with make fetch.
>
> Can you cite chapter and verse of the rule that makes such a port "truly
> Badly Behaved", for reference in this list's archives?


​
​I guess the
​better
 question would be, why does one need to BUILD a port when just downloading
the sources for another port?  Shouldn't the fetch process be just that ...
downloading the sources into the DISTDIR?​
​
​Regardless of which user you do things as, it just seems bizarre that you
would need to compile port X in order to fetch the sources for port Y.  Not
saying there's never a situation where that would be needed, it just seems
non-intuitive.​  I can see situations where you'd want to fetch distfiles
ahead of time as a different user from the one used to build the ports,
where this behaviour could break things (like Julian discovered).

What does the a compiled mysql-server port provide that's needed to
download the sources for mysql-q4m?  That can't be put off until the build
phase?


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

Re: Alternatives to rsync

[Freddie Cash]

On Oct 17, 2016 1:21 AM, "Lars Engels"  wrote:
>
> On Mon, Oct 17, 2016 at 09:46:31AM +1100, Greg 'groggy' Lehey wrote:
> > On Friday, 14 October 2016 at  8:01:51 +0300, reko.turja--- via
freebsd-ports wrote:
> > >
> > > Greg, I've actually put some thought in making a local port of
> > > rsync2. I've done some research on it and it seems to be fairly
> > > usable and security patched still.
> >
> > Even simpler, use the old version of the current rsync port.  Check
> > out with svn, which (svn log) can also tell you when the last rsync 2
> > version was.
>
> rsync 2 has a different algorithm for checking if a file changed. The
> new one is much faster.

Rsync 2 also spent a long time building a list of changes files first,
before transferring any data.

Rsync 3 starts building the file list, then starts transferring data while
it continues to build the file list. This drops the total time spent by a
large factor. Our backup times dropped by about an hour per server
switching from 2 to 3.

Something else to consider when looking at resurrecting version 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"

Re: Best way to exterminate a port

[Freddie Cash]

On Jul 11, 2016 10:49 PM, "Kurt Jaeger"  wrote:
>
> Hi!
>
> > > > Is there an easy way to "rip out by the roots" a botched
> > > > port install and start over, including re-doing all the
> > > > configuration dialogs of the port and its dependencies?
> > >
> > > For one port:
> > >
> > > pkg delete port
> > >
> > > cd /usr/ports/<...>
> > >
> > > make rmconfig
> >
> > Isn't there an "rmconfig-recursive" target?
>
> Thanks, I was not aware of that.
>
> > And doesn't pkg delete have -r or -R for recursively deleting
dependencies?
>
> man pkg-delete has
>
>-R
> Delete all packages that require the listed packages as
well.
>
> So it looks that this does something else ?

Hrm, yeah, that's upwards (delete all the other ports that use this one)
and not downwards (all the ports this one needs to install) like the OP
wants. Or vice versa? Either way, not what the OP wants.
___
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: Best way to exterminate a port

[Freddie Cash]

On Jul 11, 2016 10:22 PM, "Kurt Jaeger"  wrote:
>
> Hi!
>
> > Is there an easy way to "rip out by the roots" a botched
> > port install and start over, including re-doing all the
> > configuration dialogs of the port and its dependencies?
>
> For one port:
>
> pkg delete port
>
> cd /usr/ports/<...>
>
> make rmconfig

Isn't there an "rmconfig-recursive" target?

And doesn't pkg delete have -r or -R for recursively deleting dependencies?
___
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: java in firefox and jnlp launch - help needed.

[Freddie Cash]

On Mon, Jul 4, 2016 at 9:13 AM, Grzegorz Junka <li...@gjunka.com> wrote:

> On 04/07/2016 15:53, Freddie Cash wrote:
>
>> On Mon, Jul 4, 2016 at 7:56 AM, Miroslav Lachman <000.f...@quip.cz>
>> wrote:
>>
>> Freddie Cash wrote on 07/04/2016 16:12:
>>>
>>> On Jul 4, 2016 4:40 AM, "Wojciech Puchar" <woj...@puchar.net> wrote:
>>>>
>>>> then you can run your jnlp with
>>>
>>>> /usr/local/linux-oracle-jre1.8.0/bin/javaws
>>>>>
>>>>> this works fine (if slow can be called fine ;).
>>>>>
>>>>> Thank you very much
>>>>>
>>>>> Unless things have changed on the newest SuperMicro motherboards, you
>>>> can
>>>> just use ipmitools to connect via straight IPMI from your favourite
>>>> terminal app. That's how I manage all my H8DG* motherboards. Gives you
>>>> access to all the chassis info (power, temps, fans, etc), access to the
>>>> serial console, ability to reboot into the BIOS, etc. No Java or Linux
>>>> binaries needed.
>>>>
>>>> How you managed to SOL work for you? I tried it many times without
>>> success.
>>> Then the only thing missing will be remote media mount for booting the
>>> installer etc.
>>>
>>
>> ​The ipmitool command I use is:
>>
>> # ​ipmitool -I lanplus -H ​ -U ADMIN -a -o supermicro sol
>> activate
>> ​
>>
>> ​With the normal serial console configuration in FreeBSD
>> (/boot/loader.conf, /etc/ttys, and so on).​
>>
>> I just tried that and I got Segmentation fault. What's the normal serial
> console configuration in FreeBSD?
>

​What's listed in the Handbook, of course.  :)  There's a whole chapter
(25) just for Serial Communications.  That's what I used to configure
things way back when.  These are taken from my notes for my FreeBSD 9.x
installs:

/boot/loader.conf:
### Serial console settings ###
boot_multicons="yes"   # Same as -D in /boot.config
boot_serial="yes"  # Same as -h in /boot.config
console="comconsole vidconsole"# Enable video and serial consoles
comconsole_speed="115200"  # The serial port baud rate
comconsole_port="0x3E8"# The serial port address
hint.uart.2.flags="0x30"   # Enable keyboard support on serial
console


/etc/ttys:
# Serial terminals
# The 'dialup' keyword identifies dialin lines to login, fingerd etc.
ttyu0   "/usr/libexec/getty std.115200"   vt100   onifconsole secure


​I'm not sure if you still need to recompile the kernel to get baud rates
above 9600.  You may need to use 9600 instead of 115200 above.
​
-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: java in firefox and jnlp launch - help needed.

[Freddie Cash]

On Mon, Jul 4, 2016 at 7:56 AM, Miroslav Lachman <000.f...@quip.cz> wrote:

> Freddie Cash wrote on 07/04/2016 16:12:
>
>> On Jul 4, 2016 4:40 AM, "Wojciech Puchar" <woj...@puchar.net> wrote:
>>
>
> then you can run your jnlp with
>>>>
>>> /usr/local/linux-oracle-jre1.8.0/bin/javaws
>>
>>>
>>>
>>> this works fine (if slow can be called fine ;).
>>>
>>> Thank you very much
>>>
>>
>> Unless things have changed on the newest SuperMicro motherboards, you can
>> just use ipmitools to connect via straight IPMI from your favourite
>> terminal app. That's how I manage all my H8DG* motherboards. Gives you
>> access to all the chassis info (power, temps, fans, etc), access to the
>> serial console, ability to reboot into the BIOS, etc. No Java or Linux
>> binaries needed.
>>
>
> How you managed to SOL work for you? I tried it many times without success.
> Then the only thing missing will be remote media mount for booting the
> installer etc.


​The ipmitool command I use is:

# ​ipmitool -I lanplus -H ​ -U ADMIN -a -o supermicro sol
activate
​

​With the normal serial console configuration in FreeBSD
(/boot/loader.conf, /etc/ttys, and so on).​

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

Re: java in firefox and jnlp launch - help needed.

[Freddie Cash]

On Jul 4, 2016 4:40 AM, "Wojciech Puchar"  wrote:
>>>
>>> no iKVM64 in java.library.path
>>>
>>
>> The supermicro java console requires a linux native binary (ikvm64)
which cannot
>> be loaded in freebsd.
>>
>> To have it working you need the linux emulation and linux-oracle-jre18
port
>>
>> then you can run your jnlp with
/usr/local/linux-oracle-jre1.8.0/bin/javaws
>
>
> this works fine (if slow can be called fine ;).
>
> Thank you very much

Unless things have changed on the newest SuperMicro motherboards, you can
just use ipmitools to connect via straight IPMI from your favourite
terminal app. That's how I manage all my H8DG* motherboards. Gives you
access to all the chassis info (power, temps, fans, etc), access to the
serial console, ability to reboot into the BIOS, etc. No Java or Linux
binaries needed.

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

Re: pkg(8) conflicts when install gnome3 - what are they?

[Freddie Cash]

On Wed, Jun 15, 2016 at 2:45 PM, Ben Woods <woods...@gmail.com> wrote:

> Hi everyone,
>
> I have build gnome3 with my local poudriere instance, but when I try to
> install it pkg complains of conflicts.
>
> # pkg install gnome3
><[1526][23:35]]
> Updating FreeBSD-base repository catalogue...
> FreeBSD-base repository is up-to-date.
> Updating poudriere repository catalogue...
> poudriere repository is up-to-date.
> All repositories are up-to-date.
> Checking integrity... done (1 conflicting)
> Cannot solve problem using SAT solver, trying another plan
> Checking integrity... done (0 conflicting)
> The following 169 package(s) will be affected (of 0 checked):
>
> How can I determine what the conflicts are? Is there a way to tell pkg to
> be verbose and explain the conflict?
>
> Regards,
> Ben
>
>
​There's a -d / --debug option that can be passed.  Perhaps that will give
you the info you need.​



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

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

[Freddie Cash]

On Fri, Jun 3, 2016 at 8:26 AM, Patrick Powell <papow...@astart.com> wrote:

> Suppose that you have a portA which is a dependency of a lot of other
> ports.
>
> You also have a portB which is a replacement/update/upgrade for portA.
>
> PortB provides replacements for the executables generated/supplied by
> PortA but for various reasons you still want to use some of PortA installed
> items such as libraries,  etc.
>
> I tried doing the following:
>
> # pkg install PortA
> # cd /usr/ports/xxx/PortB
> # make install
>
> Installing PortB...
> pkg-static: PortB conflicts with PortA (installs files into the same
> place).  Problematic file: /usr/local/bin/utilityl
> *** Error code 70
>
> Is there an option, or a way similar to using 'make FORCE_PGK_REGISTER=YES
> install'
> to force overwriting the conflicting files?


​Split portA into multiple ports that install the libraries and binaries
and what-not separately, then create a meta-port that installs all of the
new portA ports.

Then create portB and have it CONFLICT with the portA-whatever port so that
it's a drop-in replacement (uninstall portA-whatever, install portB).​



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

Re: Post-install messages

[Freddie Cash]

On Fri, Apr 8, 2016 at 11:37 AM, Ronald F. Guilmette <r...@tristatelogic.com>
wrote:

>
> I am bringing up a new 10.3-RELEASE system from scratch.
>
> While doing so, I unfortunately rushed ahead and installed
> several packages I knew I needed using the "pkg install"
> command, but I neglected to look carefully at all of the
> helpful post-install messages for each package.  Most of
> these post-install messages appear to be merely informative,
> however some of these appear to be REALLY critical, e.g. the
> ones you get after "pkg install bash".
>
> Is there a way for me to go back now and see again all of the
> post-install messages for all of the packages that I have
> already installed, so that I can make sure that I've done
> everything that should be done to properly install all these?
>
> I am hoping that there is some way for me to see all these
> messages again *without* having to force re-install all of the
> relevant packages.
>

​man pkg-query

Read up on the %M (message contained in the matched package) option.  That
probably does what you want.​



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

Re: Removing documentation

[Freddie Cash]

On Wed, Feb 10, 2016 at 1:46 PM, John Marino <freebs...@marino.st> wrote:

> On 2/10/2016 10:15 PM, Kevin Oberman wrote:
> >
> > The stale configuration file issue has me a bit confused. The man page
> > does not make it clear just what makes a config "stale". All of my ports
> > are up to date as of 11:00 UTC this morning. As far as I know, all of
> > the configs are "current", although the actual config run may have been
> > for a much older version. "synth status shows 46 cases. I looked at one
> > (sysutils/tmux) and the options listed by "make showconfig" are no
> > different from those in the current Makefile, so I don't understand why
> > they are stale.
>
> Stale isn't the right word.  You could use "invalid" or "obsolete"
> instead.  The saved configuration does not match the current port.
>
> Imagine a month ago you run "make config".  It saves the status of the 4
> options on this imaginary port.  Now imagine any of the following
> happening to the port.
>
> A) An option is added
> B) An option is removed
> C) An option default changed.
> D) Any other option configuration changed.
>
> Now the month-old saved configuration doesn't match the port.  See the
> problem?
>
> Synth is the *only* tool that detects this.


​portmaster used to do this; was this option removed?  It was one of the
nicer features of portmaster and really came in handy in the past.

Haven't used portmaster since 9.something when pkg really became useful and
I stopped building anything from source, so maybe this feature was removed?​


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

Re: [moved from toolchain] GCC5: pkg vs. ports

[Freddie Cash]

On Wed, Feb 3, 2016 at 6:59 AM, William A. Mahaffey III <w...@hiwaay.net>
wrote:

> On 02/03/16 08:49, Torsten Zuehlsdorff wrote:
>
>>
>> On 03.02.2016 15:18, William A. Mahaffey III wrote:
>>
>>> When I checked the port w/ make showconfig. it shows graphite enabled.
>>>
>>
>> make showconfig shows the configuration at your *local* portstree. It
>> does not affect or display the settings of pkg.
>>
>> To check the configuration of "pkg-ports" perform a:
>> $ pkg info gcc5
>>
>> Greetings,
>> Torsten
>> ___
>> 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"
>>
>>
>
> Thanks. Where is the local portstree info stored ? My local (newly
> updated) ports gcc5-devel shows graphite enabled (see previous response), I
> thought a 'portsnap fetch update' would overwrite that, no ? Thanks (again)
> & TIA & have a good one 


​/var/db/ports​//options

That's the file that is read when you run "make showconfig" in a port
directory.  If the file doesn't exist, then it shows the default options
from the Makefile.

"make rmconfig" will remove that saved options file.  Then a "make
showconfig" will show you the default options for the port.

This is all detailed in "man ports".  :)


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

Re: port renaming

[Freddie Cash]

On Thu, Jul 16, 2015 at 10:46 AM, Vsevolod Stakhov vsevo...@highsecure.ru
wrote:

 On 16/07/2015 18:32, Kimmo Paasiala wrote:
  On Thu, Jul 16, 2015 at 8:23 PM, Vsevolod Stakhov
  vsevo...@highsecure.ru wrote:
  On 16/07/2015 18:11, Henry Hu wrote:
 
 
  On Thu, Jul 16, 2015 at 7:04 AM, Vsevolod Stakhov
  vsevo...@highsecure.ru mailto:vsevo...@highsecure.ru wrote:
 
  On Thu, Jul 16, 2015 at 2:56 PM, Anton Yuzhaninov 
 cit...@citrin.ru
  mailto:cit...@citrin.ru wrote:
  
   Port maintainers and port commiters, when
 PORTNAME/PKGNAMEPREFIX/PKGNAMESUFFIX is changed, please note this change in
 commit log and for important ports also in /usr/ports/UPDATING. Any rename
 affect at leas some of FreeBSD users and
  
   Depends in our local ports was broken and I spent some time to
 figure out why.
   It turns out, that PORTNAME for graphics/gd was changed in
 r324437.
   No singe word about this rename was added to commit message or
 UPDATING...
 
  From the perspective of pkg things are even worse, as pkg can no
  longer detect that the renamed package is a replacement for some
  existing one. It breaks many stuff and solver could hardly help to
  resolve this in a pain-less matter. We need something like
 'Replace'
  or 'Obsolete' field badly. 'UPDATING' does NOT help to solve this
 task
  at all.
 
 
  We already have the 'MOVED' file. Does it help?
 
  It doesn't because:
 
  1) it is human readable and not very convenient for parsing;
  2) we must keep this information on per-package basis and not globally;
  3) many items are missing in MOVED (and I've recently missed one when
  changing a port, for example)
  4) MOVED contains too many unnecessary information that is useful merely
  because we are using archaic version control system (namely, subversion)
 
  So the answer is no: we need a special field in manifests to make
  renaming transparent for pkg and, in turn, for users.
 
  --
  Vsevolod Stakhov
 
 
  So basically you need a data structure in the pkg metadata that can
  track all the previous origins for the port (not just the last because
  ports might have multiple renames). That's quite a tall order I might
  say.

 Why? We have already arrays in a package's metadata. For instance,
 licenses or dependencies. And we can obviously avoid that by placing a
 corresponding field 'Obsoleted by' in the *old* package. Then we'd need
 merely the last rename.


​Or a Replaces: field in the new package, similar to how Debian packages
work.​


-- 
Freddie Cash
fjwc...@gmail.com
___
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 1.5.0 is out

[Freddie Cash]

Binary packages are built one per week, starting on Wednesday. Thus, if you
want to use the official binary package repo to upgrade pkg, you'll need to
wait until at least Wednesday evening or maybe even Thursday morning.

If you want to use the ports tree to build your own package, you can so at
any time.
 On Apr 14, 2015 2:54 PM, Royce Williams ro...@tycho.org wrote:

 On Tue, Apr 14, 2015 at 12:05 PM, Baptiste Daroussin b...@freebsd.org
 wrote:
  Final pkg 1.5.0 has been released.

 Great!  How do I upgrade to it?

 $ date
 Tue Apr 14 13:51:47 AKDT 2015

 $ pkg --version
 1.4.12

 $ pkg info | egrep '^pkg-'
 pkg-1.4.12 Package manager

 $ sudo pkg upgrade pkg
 Updating FreeBSD repository catalogue...
 FreeBSD repository is up-to-date.
 All repositories are up-to-date.
 Checking integrity... done (0 conflicting)
 Your packages are up to date.

 $ sudo pkg install pkg
 Updating FreeBSD repository catalogue...
 FreeBSD repository is up-to-date.
 All repositories are up-to-date.
 Checking integrity... done (0 conflicting)
 The most recent version of packages are already installed

 Royce
 ___
 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: pkg 1.5.0 is out

[Freddie Cash]

On Apr 14, 2015 3:04 PM, cpet c...@sdf.org wrote:

 On 2015-04-14 16:59, Freddie Cash wrote:

 Binary packages are built one per week, starting on Wednesday. Thus, if
you
 want to use the official binary package repo to upgrade pkg, you'll need
to
 wait until at least Wednesday evening or maybe even Thursday morning.

 If you want to use the ports tree to build your own package, you can so
at
 any time.

 So according to what you just told the world it would take 28000 weeks to
build all ports with your Binary packages are built one per week :P

Obviously, I meant once per week.

I used to have a tagline that mentioned typos were due to my cell phone
keyboard, but seems I no longer have that configured. :)
___
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

Could someone with a commit bit check this PR: 196814

[Freddie Cash]

It's been exactly 1 month since the patch[1] was posted and the port
maintainer approved it.  :)

There's also a separate PR[2] (197035) that details the issues (with
testing and logs and whatnot) that this PR should fix.

If there's anyone available that could commit this before the automated
package building on Wednesday, it would be muchly appreciated.

Thanks!


​[1] ​https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196814
​[2] ​https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197035


-- 
Freddie Cash
fjwc...@gmail.com
___
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: sysutils/bbcp: Anyone interesting in helping upgrade this port?

[Freddie Cash]

Thanks to all who works on this.  Muchly appreciated!!

I'm guessing this didn't make it into the tree in time for this week's
package building?  No biggie, I'll pick it up next week.

I might spin up a VM and build it from source, if I get impatient.  :)

Again, thanks!

-- 
Freddie Cash
fjwc...@gmail.com
___
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

sysutils/bbcp: Anyone interesting in helping upgrade this port?

[Freddie Cash]

Good morning,

With the requirement for the NONE cipher in OpenSSH requiring a custom
compile of the world or a custom compile of the openssh-portable port (all
my production servers are binary-package-only now), I've started using bbcp
instead of zfs send over SSH.  And looking at using bbcp instead of rsync
over SSH for another system (transfer speed is more important than
encrypting the data as the transfer is done over a very local LAN link).

The bbcp port is version 20120520; the latest version available is
20140902.  There have been several new features added over the past 2 years
that make it (at least on paper) a decent rsync replacement for our uses.

Is there anyone interested in bringing this port up-to-date.  I had a quick
look, but it requires some C hacking that's beyond my skills.  :(  I've
only tried compiling it with clang, which gives lots of errors.  Haven't
tried with gcc, though.

I have 3 FreeBSD 9.3 systems that transfer data to a 4th FreeBSD 9.3 system
using zfs send over bbcp that can be used for testing things.  As well as
a Debian 7.0 box that can be tested for pulling data off a FreeBSD system.

I'd prefer to not install the ports tree on any of the production systems,
but I could spin up a KVM-based VM if needed.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: sysutils/bbcp: Anyone interesting in helping upgrade this port?

[Freddie Cash]

On Tue, Jan 13, 2015 at 10:17 AM, Chris H bsd-li...@bsdforge.com wrote:

 On Tue, 13 Jan 2015 10:08:05 -0800 Freddie Cash fjwc...@gmail.com wrote

  Good morning,
 
  With the requirement for the NONE cipher in OpenSSH requiring a custom
  compile of the world or a custom compile of the openssh-portable port
 (all
  my production servers are binary-package-only now), I've started using
 bbcp
  instead of zfs send over SSH.  And looking at using bbcp instead of
 rsync
  over SSH for another system (transfer speed is more important than
  encrypting the data as the transfer is done over a very local LAN link).
 
  The bbcp port is version 20120520; the latest version available is
  20140902.  There have been several new features added over the past 2
 years
  that make it (at least on paper) a decent rsync replacement for our uses.
 
  Is there anyone interested in bringing this port up-to-date.  I had a
 quick
  look, but it requires some C hacking that's beyond my skills.  :(  I've
  only tried compiling it with clang, which gives lots of errors.  Haven't
  tried with gcc, though.



 I just had a look. Looks interesting. I can't foresee any issue
 moving it ahead. But before I step up, and say I'll take it.
 Have you contacted the maintainer? I don't want to step on any toes. :)

 ​Well, now I feel sheepish.

I was looking at the freshports.org page for it and just saw
portmgr-related commits to the port and assumed it was maintained by
freebsd-ports (aka not maintained).  I completely missed the little
Maintainer line at the top.  :(

I've CC'd the port Maintainer to bring them into the loop.​


​[Being a past port maintainer, I really should know better.]​


-- 
Freddie Cash
fjwc...@gmail.com
___
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)

[Freddie Cash]

On Nov 6, 2014 8:26 PM, Mark Felder f...@freebsd.org wrote:



 On Thu, Nov 6, 2014, at 03:24, Anton Shterenlikht wrote:
 
  I'm not sure what you mean here.
  I've systems where I install 99% of packages
  from official repo servers, and then rebuild
  1% from ports where the default options are
  no good for me. Is this not supported?
  Or do you mean something else?
 

 You're treading dangerous ground unless you can be sure your ports tree
 svn checkout matches the checkout that was used to build the public
 packages. An example would be a situation where there was a library bump
 and your ports and packages don't match and now you have some binaries
 which don't work. If you have problems and you are using ports and
 packages mixed you will not find much sympathy in my experience.

 Bapt has mentioned a desire for tracking packages built from ports and
 making this much easier to support by having pkg upgrade detect the
 need to rebuild the port with your custom options and automatically
 updating the ports tree and building. This would be a supported process.
 I think this sounds like a fantastic way to solve this problem for the
 masses.

I know there was talk about it in the recent past, but has the export the
svn revision of the ports tree used to build packages feature been added
to the repo metadata? That would eliminate a lot of the issues associated
with mixing ports and packages, as one could use the same ports tree
locally as was used to build official packages.

Personally, I've moved all my systems over to binary updates, for the OS
and apps. After watching, with some jealousy, the ease with which our
Debian servers are managed over the years, it's nice to be able to do the
same with our FreeBSD systems.

What's funny/ironic is that it's only now, when compilation times are
measured in minutes and not days, and disk space is virtually unlimited,
that binary updates are finally available. :)

10.x is going to be an exciting time to use FreeBSD
___
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: why is 'make' installing?

[Freddie Cash]

It's installing into the staing directory in order to create the binary
package that actually gets installed. More the full install path.

This is the STAGING work that went on this year.
On Nov 2, 2014 7:02 PM, Waitman Gobble uzi...@da3m0n8t3r.com wrote:


 On Sun, November 2, 2014 5:23 pm, Chris H wrote:
  On Sun, 2 Nov 2014 08:35:33 -0800 Waitman Gobble
  uzi...@da3m0n8t3r.com
  wrote
 
  Issue, help appreciated. Missed day two of MeetBSD sorry alot going on
  today. Day one was great.
 
  I'm updating a port and noticed that 'make' is actually calling install
  in my program Makefile. seems strange. It's not registering the port as
  installed but the compiled binary is going into /usr/local/bin
 
  ie:
 
 
  ls /usr/local/bin/dcraw-m
  ls: /usr/local/bin/dcraw-m: No such file or directory
 
 
  make
  ===  License GPLv2 accepted by the user
  ===  Found saved configuration for dcraw-m-9.22
  ===   dcraw-m-9.22 depends on file: /usr/local/sbin/pkg - found
  === Fetching all distfiles required by dcraw-m-9.22 for building
  ===  Extracting for dcraw-m-9.22
  = SHA256 Checksum OK for dcraw-m-9.22.tar.gz.
  ===  Patching for dcraw-m-9.22
  ===   dcraw-m-9.22 depends on shared library: libjasper.so - found
  (/usr/local/lib/libjasper.so.4.0.0)
  ===   dcraw-m-9.22 depends on shared library: libjpeg.so - found
  (/usr/local/lib/libjpeg.so.11)
  ===   dcraw-m-9.22 depends on shared library: liblcms2.so - found
  (/usr/local/lib/liblcms2.so.2.0.6)
  ===   dcraw-m-9.22 depends on shared library: libMagickWand-6.Q16.so -
  found (/usr/local/lib/libMagickWand-6.Q16.so.2.0.0) ===  Configuring
 for
  dcraw-m-9.22 ===  Building for dcraw-m-9.22
  ===  Staging for dcraw-m-9.22
  ===   Generating temporary packing list
  install -m 0755 -g wheel -o root dcraw-m /usr/local/bin 
 Compressing
  man pages (compress-man)  Running Q/A tests (stage-qa)
 
 
  ls /usr/local/bin/dcraw-m
  /usr/local/bin/dcraw-m
 
 
  AFAIK a port 'make' should not actually call install in the Makefile. ?
 
 
  rm /usr/local/bin/dcraw-m cd work/waitman-dcraw-m-1b90326/ make clean
  make
  cc -O2 -pipe   -Wall -Werror -I/usr/local/include 'MagickWand-config
  --cflags --cppflags' -DMAGICKCORE_HDRI_ENABLE=0
  -DMAGICKCORE_QUANTUM_DEPTH=16 -DNO_JASPER -L/usr/local/lib
  'MagickWand-config --ldflags --libs' -lm -llcms2 -ljpeg -o dcraw-m
  dcraw-m.c
  ls /usr/local/bin/dcraw-m
  ls: /usr/local/bin/dcraw-m: No such file or directory
 
  make install
  install -m 0755 -g wheel -o root dcraw-m /usr/local/bin
  ls /usr/local/bin/dcraw-m
  /usr/local/bin/dcraw-m
 
 
 
  hmmm why is 'make' on the port Makefile calling install?
 
  Because you asserted make install?
 
  make install
  install -m 0755 -g wheel -o root dcraw-m /usr/local/bin
 
  That's all I can gather from the limited output you provided. :)
 
 
  --Chris
 
 
 
  uname -a
  FreeBSD dx.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #2: Mon Oct 27
   18:47:44 PDT 2014 r...@dx.waitman.net:/usr/obj/usr/src/sys/AMINEH
  amd64
 
 
  Thank you,
 
 
  --
  Waitman Gobble
  Los Altos California USA
  +1.510-830-7975
 
 
  ___
  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
 
 
 
 

 no, i was showing that the program Makefile only installs when you
 explicitly do 'make install', but the port Makefile seems to be calling
 'make install' for some reason.


 here's another port that is not mine, it is doing the same thing..


 [1492]  cd /usr/ports/graphics/dcraw
 [1493]  make
 ===   dcraw-9.21 depends on file: /usr/local/sbin/pkg - found
 = dcraw-9.21.tar.xz doesn't seem to exist in /usr/ports/distfiles/.
 = Attempting to fetch
 http://distcache.FreeBSD.org/local-distfiles/sunpoet/dcraw-9.21.tar.xz
 dcraw-9.21.tar.xz 100% of   78 kB  206 kBps
 00m01s
 === Fetching all distfiles required by dcraw-9.21 for building
 ===  Extracting for dcraw-9.21
 = SHA256 Checksum OK for dcraw-9.21.tar.xz.
 ===  Patching for dcraw-9.21
 ===   dcraw-9.21 depends on shared library: libjasper.so - found
 (/usr/local/lib/libjasper.so.4.0.0)
 ===   dcraw-9.21 depends on shared library: libjpeg.so - found
 (/usr/local/lib/libjpeg.so.11)
 ===   dcraw-9.21 depends on shared library: liblcms2.so - found
 (/usr/local/lib/liblcms2.so.2.0.6)
 ===  Configuring for dcraw-9.21
 ===  Building for dcraw-9.21
 dcraw.c:1009:4: warning: add explicit braces to avoid dangling else
   [-Wdangling-else]
   else ip[col][c] = (ip[col-width][c] + ip[col+width][c] + 1)  1;
   ^
 dcraw.c:9038:41: warning: data argument not used by format string
   [-Wformat-extra-args]
 _(Converting to %s colorspace...\n), name[output_color-1]);
^
 dcraw.c:9708:44: warning: adding 'unsigned int' to a string does not
 append to
   the string [-Wstring-plus-int]
   write_ext 

Re: Something's gone pear-shaped

[Freddie Cash]

If 8.4 is still officially supported (I think so), then it's a simple:

rm -rf /usr/ports
mkdir /usr/ports
portsnap fetch extract

Aka nuke and pave. :)
___
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 1.3.X changed behaviour with pkg -fR xxx

[Freddie Cash]

On Wed, Jul 30, 2014 at 3:37 PM, Kevin Oberman rkober...@gmail.com wrote:

 On Wed, Jul 30, 2014 at 3:29 PM, Jos Backus j...@catnook.com wrote:
  My impression was that pkg is supposed to be cross-platform and portable,
  hence not FreeBSD-specific.
  Jos

 I have seen nothing indicating that. It's certainly not going to work with
 any Linux distro. It might be applicable to other BSDs, especially
 DragonFly, but I still believe that FreeBSD bugs belong in the FreeBSD bug
 system. Normally, when maintainers want to dent reports upstream to the
 port developers, it is up to them to do so. So the ports management team
 would be responsible for forwarding bugs to the github system if they think
 it is appropriate.

 ​pkg is the default package manager on DragonflyBSD now.  Their dports
setup switched over to it officially a release or two ago.  I believe
they're even using poudriere to build their packages.

However, I agree that pkg bugs on FreeBSD should be added to the FreeBSD
bug tracker.  At the very least, a FreeBSD PR needs to be entered with the
bug number from the pkg bug tracker.  There needs to be a FreeBSD-specific
papertrail for bugs on FreeBSD.​



-- 
Freddie Cash
fjwc...@gmail.com
___
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: Quickly cleanroom building and installing software from ports

[Freddie Cash]

On Wed, Apr 9, 2014 at 11:36 AM, Chris Rees cr...@bayofrum.net wrote:

 I'd be delighted if out of the box it could *install* just built packages.
  Can it do that?


​Poudriere is a package building tool (and repo building tool), nothing
more.

pkg(8) is how packages are installed​.  It's up to you to decide how you
want the packages installed.  Write a wrapper script around poudriere to
use pkg(8) to install the packages that were just created.



-- 
Freddie Cash
fjwc...@gmail.com
___
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: Mysterious patches

[Freddie Cash]

On Fri, Mar 28, 2014 at 1:47 PM, A.J. 'Fonz' van Werven free...@skysmurf.nl
 wrote:

 Henry Hu wrote:

  They apply to src/raster-png.cxx and src/raster.cxx

 Note to self: look inside the actual patch files themselves, it says right
 there which files they apply to *oops*.

 However, this does leave me puzzled about the file names. If a patch
 applies to, say, src/foo/bar.c, shouldn't it be called
 files/patch-src__foo__bar.c? This is how it's described in the Porter's
 Handbook. Given a filename such as files/patch-png.cxx I would expect that
 patch to apply to a file ${WRKDIR}/png.cxx.

 What am I misunderstanding here?

 ​Patch file naming conventions are just that:  conventions.  It's not
carved in stone and enforced in the tools.  The patch program looks at the
paths in the diff file to figure out which files need to be edited.

The naming convention for patch files has changed over the years.  Maybe
this one is using an older convention?  Or maybe it never followed one to
begin with?

Either way, it you take maintainership of the port, you can make it follow
the current patch file naming convention.  ;)
​

-- 
Freddie Cash
fjwc...@gmail.com
___
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

Fwd: Re: reason 23 why we've moved to linux

[Freddie Cash]

Forgot to reply to list.

Typos and terseness brought to you by the LG G2 running SlimKat.
-- Forwarded message --
From: Freddie Cash fjwc...@gmail.com
Date: Mar 22, 2014 12:09 PM
Subject: Re: reason 23 why we've moved to linux
To: Randy Bush ra...@psg.com
Cc:

On Mar 22, 2014 11:49 AM, Randy Bush ra...@psg.com wrote:

  Honest question, have you been building things from source under
  debian's ports or are you using their version of pkg?

 the latter

 and i have two 9 systems where i try to use freebsd-update.  also a
 time-consuming rabbit hole leading nowhere pleasant.  e.g.

 # freebsd-update upgrade -r 9.2-RELEASE-p3
 Looking up update.FreeBSD.org mirrors... 5 mirrors found.
 Fetching metadata signature for 9.2-RELEASE from update5.freebsd.org...
done.
 Fetching metadata index... done.
 Inspecting system... done.

 The following components of FreeBSD seem to be installed:
 kernel/generic world/base world/doc world/games world/lib32

 The following components of FreeBSD do not seem to be installed:

 Does this look reasonable (y/n)? y

 Fetching metadata signature for 9.2-RELEASE-p3 from
update5.freebsd.org... failed.
 Fetching metadata signature for 9.2-RELEASE-p3 from
update2.freebsd.org... failed.
 Fetching metadata signature for 9.2-RELEASE-p3 from
update3.freebsd.org... failed.
 Fetching metadata signature for 9.2-RELEASE-p3 from
update4.freebsd.org... failed.
 Fetching metadata signature for 9.2-RELEASE-p3 from
update6.freebsd.org... failed.
 No mirrors remaining, giving up.

As a counter-point, I just upgraded 4 systems running different versions of
9.1-STABLE to 9.2-RELEASE-p3 this week. Took only 1 work day to:
  - migrate from single disk to zfs-on-root
  - migrate from gmirror to zfs-on-root
  - create new boot environment
  - rebuild world to get back to stock
  - use freebsd-update to get latest updates
  - upgrade pkg
  - upgrade/reinstall all packages

The longest part was rebuilding world to get things to a state where
freebsd-update could work. Everything after that took maybe an hour. I was
quite impressed by how quickly and easily things were updated/installed
using the binary tools.

Once you start using the binary tools and treat the FreeBSD systems like
Debian systems, everything works the same, with the same ease-of-use.

I did the same at home, going from FreeBSD 9.1 to PC-BSD 9.1 to TruOS 9
(rolling release) to PC-BSD 9.2. Didn't have to compile a thing.

The more I use only the binary tools, the more impressed with FreeBSD I
get. And I've been using it since 3.1/4.0 (although I do have 2.2 on CD).

The pkg team have been doing sine wonderful things. Once they stop changing
the config files, things will get even better. :)

Typos and terseness brought to you by the LG G2 running SlimKat.
___
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: Listing of all available options in ports tree for use in make.conf /ports.conf (WITHOUT_ , WITH_ as well as OPTIONS_SET /UNSET)

[Freddie Cash]

On Tue, Mar 4, 2014 at 9:55 AM, Chad J. Milios mil...@ccsys.com wrote:

 On 3/4/2014 9:40 AM, Thierry Thomas wrote:

 Le mar  4 mar 14 à 15:05:51 +0100, Jakub Lach jakub_l...@mailplus.pl
   écrivait :

 Thanks for reply!

 IMHO, port knobs really should be centrally tracked/standardized.
 When one would like to set some options globally, it gets really
 ugly really fast e.g.

 It used to be in /usr/ports/KNOBS but it was removed some days ago.
 Anyway, it's still available in svn, and most of the knobs are described
 in /usr/ports/Mk/bsd.options.desc.mk .

 from within a port's directory,

 make showconfig

 will show you the current options set and

 make __MAKE_CONF=/dev/null PORT_DBDIR=/var/empty showconfig

 will show you the defaults.

 Hope this is helpful to you


If those two commands aren't in the Handbook (I'm pretty sure the first one
is), then they should be considered for inclusion.​​  Or, maybe in the
Porter's Handbook?  Or maybe ports(7)?  I can see the second command being
very useful, especially during this transitional stage where people will be
migrating/recreating their make.conf files.  Something I could have used
awhile back, before I just moved to using the binary package repos from
PC-BSD.




-- 
Freddie Cash
fjwc...@gmail.com
___
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

[Freddie Cash]

On Thu, Feb 6, 2014 at 8:13 AM, Randy Pratt bsd-u...@embarqmail.com wrote:

 On Wed, 5 Feb 2014 23:26:18 -0800
 Kevin Oberman rkober...@gmail.com wrote:

  On Wed, Feb 5, 2014 at 10:45 PM, Matthew Seaman 
  m.sea...@infracaninophile.co.uk wrote:
 
   On 05/02/2014 23:57, Kevin Oberman wrote:



  One BIG one that I know is being worked is the capability to mix packages
  and ports effectively.  If you use poudriere, you can roll your own
  packages with custom options and maintain things pretty reasonably, but
 for
  a single system (or two), this is a bit of overkill. As things stand,
  this
  is a real pain to use customized ports and packages from the standard
  FreeBSD distributions. I'm waiting with great excitement for this to
  appear, though I have no idea if it is near or far.
  --
  R. Kevin Oberman, Network Engineer, Retired
  E-mail: rkober...@gmail.com
 

 My experience with mixing ports and packages dates back to 2.2.5 and
 the disasters it created.  Most of the problems were created by the
 ports tree and package builds not being syncronized.  I switched to
 ports exclusively and have not had those problems again.  If a
 mechanism existed to svn update a ports tree to the revision level of
 the package build I would probably try to use packages for most
 and limit building to those ports for which non-default OPTIONS were
 employed.  For me, this is the feature that has always been missing.

 I recently switched to pkgng and while there is a learning curve I
 think it is more versatile and efficient than its predecessor.
 Thanks to all who are working to make things better.

 That would be a *very* useful feature.  To be able to query the remote pkg
repo to get the svn revision number of the ports tree that was used to
build the repo.  Then you could pass that to svnup/svn to sync your local
ports tree to the same revision.  Then you could very easily mix/match
local ports installs with remote pkg installs, as the versions for
everything would match.

Once the multi-repo features of pkg are up to snuff, perhaps adding a
local repo would also help.  Any software installed via the ports tree
infrastructure would get tagged as part of the local repo.  Then one
could query the pkg database to get a list of software that came from the
local repo, so we know which bits needs to be reinstalled/upgraded from
the ports tree.

Which, could easily tie into poudriere (or portmaster) for building the
local ports en-masse.​​


-- 
Freddie Cash
fjwc...@gmail.com
___
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 10.0-RC4 pkg upgrade QT conflict

[Freddie Cash]

On Thu, Jan 16, 2014 at 5:26 AM, CeDeROM cede...@tlen.pl wrote:

 I have solved this issue with pkg delete -xf qt4-; pkg upgrade - all
 packages now match binary release, no more conflicts.

 I guess it was produced by compiling+installing some stuff from ports,
 which introduced some inconsistency, even though WITH_PKGNG=yes was set
 in /etc/make.conf...


​The inconsistency comes when you use a different ports tree (different
versions of things in the tree) than what was used to compile the binary
packages; or from selecting non-default OPTIONS when using the ports tree.

If you only use binary packages, there's no inconsistencies, as everything
is build at the same time, using the same ports tree and OPTIONS.

If you only use the ports tree to compile things, there's no
inconsistencies as everything is compiled (and kept up-to-date via
portmaster) using the same ports tree and OPTIONS.​

When you mix the two, inconsistencies abound.  Different ports tree lead to
different versions and/or differenet OPTIONS selected etc.

If you want to custom compile some ports, then using something like
ports-mgmt/poudriere to bulk build binary packages based on a local ports
tree is best.  That gives you the ease of upgrade/install of binary
packages, with the customisability of the ports tree, without any
inconsistencies.

​I used to be a die-hard ports tree user, customising every port and
tailoring everything to the machine.  Since pkg was released as stable,
though, I've compiled fewer and fewer ports.  My home desktop runs PC-BSD
using only binary packages, and the last 2 servers I've installed at work
have used only binary packages.  They really have come a long way ...​

-- 
Freddie Cash
fjwc...@gmail.com
___
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 10.0-RC4 pkg upgrade QT conflict

[Freddie Cash]

On Thu, Jan 16, 2014 at 8:41 AM, CeDeROM cede...@tlen.pl wrote:

 Hello and thank you for all suggestions :-)

 What I mean is that PKG seems to be missing some good mechanism for
 such conflict solution... and this situation WILL happen as users will
 want to rebuild custom options of packages from a different port tree.

 I have compiled by hand hpijs with network backend as my HP use
 JetDirect and this is disabled by default. Because I have compiled a
 port with WITH_PKGNG I assumed that PKG will be engaged and take care
 of proper dependency management or refuse to install as this would
 break binary dependencies tree. I was wrong.

 I also assumed that PKG will manage to handle port renames, dependency
 changes, etc. I was wrong.

 +1 for PKG to be able to handle such situations either by simply
 forcing to set port tree to version that would allow safe build (bad
 for new ports, simple solution), or calculate dependencies so they
 won't break current binary tree when newer ports are installed (good
 for new ports, complex work for pkg) :-)

 Long story short - there should be no conflict situation when I
 install updated port build by hand :-)


I believe a lot of that is planned for future releases, and that 1.3 goes a
long way toward that goal (released Real Soon Now).

However, I'm not directly involved in the development of pkg, so could be
way off in my predictions.  :)​​

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Official FreeBSD Binary Packages now available for pkgng

[Freddie Cash]

On Thu, Oct 31, 2013 at 2:39 PM, Mehmet Erol Sanliturk 
m.e.sanlit...@gmail.com wrote:

 On Thu, Oct 31, 2013 at 4:58 PM, Bryan Drewery bdrew...@freebsd.org
 wrote:

 At present , the packages information and themselves are available from ,
 such as :

 ftp://ftp1.freebsd.org/pub/FreeBSD/ports/amd64/

 It seems that new pkg compatible packages will not be exposed to the
 Internet such as


 http://avalon.dragonflybsd.org/dports/
 http://pkg.wolfpond.org/
 http://mirror.exonetric.net/pub/pkgng/


 This will be a very significant inconvenience for the possible users
 because without an installed FreeBSD , they will not be able to see what
 are the available packages there .


​From the original message:
Mirrors you may use instead of the global
pkg.FreeBSD.orghttp://pkg.freebsd.org/
:

pkg.eu.FreeBSD.org http://pkg.eu.freebsd.org/
pkg.us-east.FreeBSD.org http://pkg.us-east.freebsd.org/
pkg.us-west.FreeBSD.org http://pkg.us-west.freebsd.org/


pkg.freebsd.org is, basically, an alias for the above (and any other
mirrors that come online) and the pkg(1) tool will pick a local mirror
based on the DNS response for pkg.freebsd.org.

However, you are free to manually enter any of the above mirrors into your
pkg.conf.

And, you are free to browse any of the above mirrors via HTTP in any web
browser.

It's not nearly as convenient as just browsing pkg.freebsd.org, but it's
still possible to do so.



-- 
Freddie Cash
fjwc...@gmail.com
___
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: portmaster refuses to use pkgng with local packages

[Freddie Cash]

On Oct 27, 2013 8:35 AM, Axel Rau axel@chaos1.de wrote:


 Am 27.10.2013 um 16:23 schrieb Adam McDougall mcdou...@egr.msu.edu:

  Perhaps 'pkg add' is what you want?
 No, this *installs* a new package.
 I'm using
 postmaster -a
 to *update* everything in a jail.

If you want to do everything using only binary packages, then you can stop
using portmaster. The pkg tool does it all.

pkg update
pkg upgrade

Those two commands do what portmaster -a -PP does.
___
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: portmaster refuses to use pkgng with local packages

[Freddie Cash]

On Oct 27, 2013 8:59 AM, Axel Rau axel@chaos1.de wrote:


 Am 27.10.2013 um 16:41 schrieb Freddie Cash fjwc...@gmail.com:

  On Oct 27, 2013 8:35 AM, Axel Rau axel@chaos1.de wrote:
 
 
  Am 27.10.2013 um 16:23 schrieb Adam McDougall mcdou...@egr.msu.edu:
 
  Perhaps 'pkg add' is what you want?
  No, this *installs* a new package.
  I'm using
 postmaster -a
  to *update* everything in a jail.
 
  If you want to do everything using only binary packages, then you can
stop
  using portmaster. The pkg tool does it all.
 
  pkg update
  pkg upgrade
 
  Those two commands do what postmaster -a -PP does.
 Sure, but I want the flexibility of individually configuring the ports,
which is done on my build jail.

Then you want to convert your build jail setup to use ports-mgmt/poudriere.
That gives you the best of all worlds: individually configure and tweak
each port, build binary packages in bulk, use pkg to install/upgrade on
destination machines.

BSDNow video podcast #2 even includes a nice tutorial and overview of how
it works.
___
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: Should /usr/bin/perl be a link to /usr/local/bin/perl ?

[Freddie Cash]

On Mon, Oct 21, 2013 at 9:47 AM, Yuri y...@rawbw.com wrote:

 I found that many ports specify /usr/bin/perl as an interpreter. This
 comes from Linux. Examples: valgrind-snapshot, windowmaker, enscript-a4,
 a2ps, svgalib
 /usr/bin/perl isn't installed by perl port.

 There are several solutions, in the order of increasing complexity of
 solution:
 1. Install the link /usr/bin/perl (hackish, but it will fix many broken
 ports in one shot)


​That's already there.  A least on all my FreeBSD machines (9.0, 9.1,
9-STABLE, 10-CURRENT).  I believe that's the default for the perl ports and
you have to manually uncheck that option when building the port to break
things.​



 2. Make a package scripts check for interpreter and break the install of
 offending packages
 3. Fix all offending packages

 Which solution should be preferred in your opinion?

 Yuri
 __**_
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/**mailman/listinfo/freebsd-portshttp://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to 
 freebsd-ports-unsubscribe@**freebsd.orgfreebsd-ports-unsubscr...@freebsd.org
 




-- 
Freddie Cash
fjwc...@gmail.com
___
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: NEED_ROOT

[Freddie Cash]

On Fri, Oct 4, 2013 at 2:45 PM, Paul Schmehl pschmehl_li...@tx.rr.comwrote:

 From my reading it appears that one of the goals of STAGE is to allow
 users

 to build and install ports under their UID.  Are the perms in /usr/ports
 changing?


​You've always been able to build ports as non-root, so long as you set
WRKDIRPREFIX and DISTDIR to something you can write to.

You've never been able to install ports as non-root.

What the STAGE support stuff does is allow you to build _packages_ as
non-root.

Previously, to build a package, you first had to install the port (as
root), then build the package (as non-root), then uninstall the port (as
root).

Now, you build the port (as non-root), install into the staging directory
(as non-root), and make the package based on that (as non-root).

​IOW, root is only needed to install the package onto the destination
system.​  It's not needed on the build system.


-- 
Freddie Cash
fjwc...@gmail.com
___
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: Searching the port tree with portmaster?

[Freddie Cash]

On Wed, Aug 14, 2013 at 11:44 PM, LuKreme krem...@kreme.com wrote:

 Am I missing a search feature in postmaster?

 If not, how are people finding where a port is to install it (I had a heck
 of a time finding sudo, for example)


Method 1:
cd /usr/ports
make quicksearch name=sudo

Method 2:
cd /usr/ports/ports-mgmt/psearch
make install clean
rehash
psearch sudo

Method 1 doesn't require any extra software, but requires a lot of typing.

Method 2 is very handy and speedy, and requires much less typing once
psearch is installed.

Portmaster is a ports installation/upgrading tool.  It's not a ports
searching tool.  Remember the Unix philosophy:  do one thing, and do it
well.  :)  Use separate tools for separate functions.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Would software for non-commercial use be acceptable as a port?

[Freddie Cash]

This is how DansGuardian works, and it's a part of the ports tree
(www/dansguardian). The install points the user to the licensing page on
the web. It's up to the user to decide if they're eligible for the non-com
license.
On 2013-07-27 5:37 PM, Peter Looyenga p...@catslair.org wrote:

 Hi gang,

 I've been professionally using FreeBSD for quite some time now (my company
 now uses 4 FreeBSD servers for web services) and during the implementation
 period I've become quite fascinated with the ports system. And this evening
 I suddenly had an idea, but I'm not too sure how feasible this idea is, so
 I'm hoping some of you guys would be willing to give me some suggestions or
 advice.

 I've been using a commercial software product for the past 4 years now; I
 started using it on Linux and nowadays I use it on Windows.

 The company behind this product provides several editions of their product,
 including a community edition which can be used free of charge but
 non-commercial use only. It does have some functional limitations which, in
 my opinion (but I am biased), aren't really intrusive. For example if you
 print some output you'll get a watermark too. Stuff like that.

 Even so; I strongly support this software. Like I said before I've been
 using it myself for the past 4 years (in all fairness: I got myself a
 commercial license too, which wasn't too expensive in my opinion) and even
 now I'm still quite passionate about this stuff.


 Now; I read that the ports collection provides a /truly/ free environment
 and doesn't shun entries which may not match the idea of free and/or open
 source software.

 So my question should be obvious: Would I be right to assume that the
 software product as I described it above could be a liable addition for the
 ports collection, or is there something I'm overlooking?

 Needless to say I'm obviously contacting the company behind it as well, I
 can say I'm in quite good terms with them, and nothing will be done without
 their explicit permission.

 But before I start on such an endeavor I'd really appreciate if you guys
 could confirm (or deny) if my plans are actually feasible?

 Am I right to conclude that the product, with the non-commercial clause I
 described above, could be a candidate for the ports collection or would the
 restriction be a huge obstacle?

 Thanks in advance for any comments, I'd really appreciate some advice
 and/or
 comments here.

 Kind regards,

 Peter

 --
 .\\ S/MIME public key: http://www.catslair.org/pubkey.crt
 +- My semi-private Root CA: http://ssl.losoco.nl/losoco.crt



 ___
 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: shells/bash: Options slightly confusing

[Freddie Cash]

On Thu, May 30, 2013 at 7:57 AM, Jerry je...@seibercom.net wrote:

 On Thu, 30 May 2013 15:09:55 +0200
 Michael Gmelin articulated:

  On Thu, 30 May 2013 14:08:29 +0200
  John Marino freebs...@marino.st wrote:
 
   On 5/30/2013 13:27, Michael Gmelin wrote:
I assume there are better ways to make this clear. It might even
make sense to have a basic distinction on the ports system level -
options that provide additional features vs. options that
change the (default) behavior of the port.
  
   Isn't this implicit in the option default selection?  In other
   words, the fact that it's pre-selected indicates the default
   behavior of the port, right?
  
   Even in the case of a dialog showing where it didn't before isn't a
   logical reason to think pre-selected options are changes in default
   behavior, at least not to me.
  
 
  There's been some debate over the bash port earlier this year, plus it
  has been converted to OptionsNg recently (AFAIK it had no options
  dialog before), therefore my pessimism.
 
  But regardless of default options and updating - if I installed bash
  for the first time and seen an option labeled as Use directory name
  alone to cd into it I would assume that bash will behave like this
  after installation without further configuration - in contrast to
  adding the ability to do that (Support feature).
 
  Maybe it's just me though :)

 I agree whole heartily. Unfortunately, all too many ports have
 options that all cryptic in nature. There really needs to be better
 documentation as to what the options actually do. Perhaps having an
 additional file in each port named OPTDESC, or whatever that would
 list each available option for the port and exactly what it did would
 prove useful. It certainly would not be a burden as over 90% of the
 ports that have either none or just one or two options. Besides, if
 some maintainer created a port with 40 or 50 configurable options, then
 they certainly can take the time to fully document them.

 Isn't long options description support enabled in the ports tree now?  Or
was that only available via Warren Block's dialogwrapper?  Or maybe via
dialog4ports?

I remember reading something about this a few months back, where the bottom
of the screen would show long descriptions of what the option would do, or
a separate help screen would be available.  Or maybe that was just a
proof-of-concept?

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Proposal: do not show up the dialog(1) by default?

[Freddie Cash]

On Thu, May 23, 2013 at 6:58 AM, Lars Engels lars.eng...@0x20.net wrote:

 On Thu, May 23, 2013 at 07:45:42AM +0200, Baptiste Daroussin wrote:
  hi,
 
  A lot of people seems to be complaining about the configuration dialog
 popping
  up all the time.
 
  What if we change the default behaviour to not pop up the dialog each
 time there
  is a changed option but only when the user explicitly type make config?
 
  Just a proposal, please give your opinion.
 
  Of course make config-recursive behaviour won't change.
 
  regards,
  Bapt

 I am strongly against it. Firstly, it's against POLA, secondly, while it
 hides complexity of the ports system it also hides its biggest
 advantage.
 You'll never know which knobs the ports you want to build offer and new
 users will never find out how to build an Apache web server with PHP
 support.

 My proposal get rid of the nagging NLS and DOCS window, ask the user
 initially if they want NLS and DOCS and enable/disable it globally.
 Second, encourage the use of portmaster to install new ports, which
 recursively displays the OPTIONS dialog and does this much faster than
 make config-recursive.
 That way you can set/unset all OPTIONS, go to bed and don't find an
 unanswered dialog in the next morning.


I agree.  The dialog needs to appear if there are no saved options for the
port (thus saving the options).  And it needs to appear if the list of
options has changed or if the defaults have changed from what's saved in
/var/db/ports/.

If the defaults are the same as what's saved in /var/db/ports/ then the
options window does not need to appear.

IOW, the way the ports tree worked before we lost the ability to set things
globally in /etc/make.conf (although it appears a convoluted hack has been
added to make this work).

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Proposal: do not show up the dialog(1) by default?

[Freddie Cash]

On Thu, May 23, 2013 at 7:17 AM, Adam Vande More amvandem...@gmail.comwrote:

 On Thu, May 23, 2013 at 12:45 AM, Baptiste Daroussin b...@freebsd.org
 wrote:
  hi,
 
  A lot of people seems to be complaining about the configuration dialog
 popping
  up all the time.
 
  What if we change the default behaviour to not pop up the dialog each
 time there
  is a changed option but only when the user explicitly type make config?
 
  Just a proposal, please give your opinion.
 
  Of course make config-recursive behaviour won't change.
 
  regards,
  Bapt

 I would rather the current behavior remained or even better would be
 if there was a native way to queue up all the config screen like
 portupgrade does(at least it did when I last used it, it's been
 awhile).  It's not nearly as painful to answer them in bulk even if
 queue generation takes awhile.

 There are already two native ways to do this:
  make config-recursive
  use a ports management tool like portmaster/portupgrade

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Proposal: do not show up the dialog(1) by default?

[Freddie Cash]

On Thu, May 23, 2013 at 8:36 AM, Chris Rees utis...@gmail.com wrote:

 Please read the docs before stating things that are incorrect.


I've read the docs, I've installed ports, I've mangled my make.conf to make
it work in The New World Order.

 We can still set things globally, and it's not a hack.

Compared to the simplicity of how things were before, it's a hack.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: grub2 with libzfs

[Freddie Cash]

I just recently (last week) converted my root on USB; data on ZFS setup
using 2x mirror vdevs to root-on-zfs. Works beautifully, and can boot off
any of the 4 drives in the pool. Using standard loader and gptzfsboot.

PC-BSD 9.1-p3.

And, I just configured a new storage server at work using FreeBSD 9.1 with
root-on-zfs, using standard loader and gptzfsboot. This one with a single
mirror vdev for the OS, and a separate 7x raidz2 vdev storage pool.
 On 2013-05-20 7:26 PM, Wes Morgan morg...@chemikals.org wrote:

 Trying to boot a zfs (GPT) partition with the latest patch gives me an
 unaligned pointer random number sometimes. When I enable all the
 debugging I can also get an error invalid nvlist header. Currently just
 booting from a ufs partition acting as /boot, but my goal would be to get
 rid of that extra partition. I'm sure there is nothing wrong with the pool
 because I just created. Anyone direct booting zfs on GPT?



 On Sun, Apr 14, 2013 at 10:44 PM, Beeblebrox zap...@berentweb.com wrote:

  Jurgen:
 
  Tab-completion does not detect ZFS.
  Will post after I re-compile with latest patch and ZFS-knob disabled per
  your request.
 
  Regards.
 
 
 
  -
  10-Current-amd64-using ccache-portstree merged with marcuscom.gnome3 
  xorg.devel
 
  --
  View this message in context:
 
 http://freebsd.1045724.n5.nabble.com/grub2-with-libzfs-tp5799405p5803882.html
  Sent from the freebsd-ports mailing list archive at Nabble.com.
  ___
  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

Re: Growing list of required(ish) ports

[Freddie Cash]

On Sun, Apr 7, 2013 at 6:47 PM, Robert Simmons rsimmo...@gmail.com wrote:

 Are there plans to get the following ports moved into HEAD?

 1) ports-mgmt/pkg

 The bootstrap code is in base.  There's no need to tie the actual pkg
development to the base, though.


 2) ports-mgmt/dialog4ports

 This is used by the ports tree, and only the ports tree, on all supported
versions of FreeBSD.  Thus, its development should not be tied into the
base OS.


 3) ports-mgmt/portaudit

 This is not needed by pkg; pkg includes its own support for VuXML alerts.
Thus, its not needed in the base.


 4) ports-mgmt/portmaster

 Portmaster works with the ports tree, and works on all supported versions
of FreeBSD.  Thus, there's no point in limiting its development as part of
the base.

IOW, these are all ports tree-related tools, which benefit greatly from
being developed as part of ports tree development.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Growing list of required(ish) ports

[Freddie Cash]

Note:  I may have messed up the quoting/attribution by snipping things.

On Sun, Apr 7, 2013 at 10:11 PM, Kevin Oberman rkober...@gmail.com wrote:

 On Sun, Apr 7, 2013 at 8:34 PM, Kimmo Paasiala kpaas...@gmail.com wrote:

   On the other hand, there are a number of things that I think should be
   pulled out of base.  Some already have ports, and others would need
   ports created.  Examples of things to pull out of base are OpenSSL,
   Heimdal, OpenSSH, PF, ntpd, ipfilter, bind, sendmail, and others.
   Code that is typically way behind the upstream project basically.
  
 
  I think Bryan already explained the reasons why pkg should not be in
  base, it's an external tool that is not strictly required to get a bare
  bones FreeBSD system up and running. Including it in base you create
  yet another maintainance burden and would slow down the development of
  the ports/packages management tools.

 What people seem to miss is that putting tools into the base system
 strangles the tools. Look at the difficulty we have seen in updating
 openssl. perl was removed from base for exactly that reason. Once something
 is in base, it usually can only be updated  on major releases and even then
 it can be very complicated. That is a problem for any dynamically changing
 tool.

 I would love to see BIND removed from base, but most of the things  you
 listed really are hard to remove. I know that I don't want to try bringing
 up a new install of FreeBSD on a remote system without OpenSSH and that
 pulls in openssl.  In the case of many tools, it really turns into a
 bikeshed. But i can see no reason to add any of the new packaging tools
 simply because it is critical that updates be possible far  more often than
 is possible for the base system.

 Moving OpenSSH, OpenSSL, etc into the ports tree, but making the pkgs
available on the installation media, and having a final hook at the end to
install required pkgs, would solve that.  There's already a do you want
to enable OpenSSH daemon question in the installed, so adding pkg add
/path/to/openssh-x.y.z.txz wouldn't be hard.

Same for bind, sendmail, kerberos, etc.  For instance, just add a daemon
selection screen for each bit removed from base, to select which ones you
want installed as part of the OS install.

The hard part comes in finding stub/clients for each item moved to a pkg,
such that a desktop-oriented install is not hampered (ie, SSH client is
usable, DNS lookups can be done, local mail can be generated/delivered,
etc).

The really hard part is coming up with a migration path for those who
upgrade via source builds.
-- 
Freddie Cash
fjwc...@gmail.com
___
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: ports-mgmt/pkg is broken. please fix.

[Freddie Cash]

Why, oh why, oh why, oh why is the ports framework pulling in
/etc/src.conf?  Beyond being the biggest POLA infraction out there, it
blatenly states in many different locations that /etc/src.conf is only to
be used by make(1) when it is invoked within the /usr/src tree.

Please, let's not pollute the ports tree with src.conf, and let's not water
down the clear separation of duties between /etc/make.conf and
/etc/src.conf.


On Tue, Feb 26, 2013 at 9:50 AM, Baptiste Daroussin b...@freebsd.orgwrote:

 On Tue, Feb 26, 2013 at 09:30:34AM -0800, Steve Kargl wrote:
  % portmaster texinfo
 
  leads to
 
  === Currently installed version: texinfo-5.0.20130217
  === Port directory: /usr/ports/print/texinfo
 
  === Gathering distinfo list for installed ports
 
  === Launching 'make checksum' for print/texinfo in background
  === No options to configure
  === Gathering dependency list for print/texinfo from ports
  === Launching child to update pkg-1.0.7 to pkg-1.0.8
 
  ...
 
  === Launching child to update pkg-1.0.7 to pkg-1.0.8
 
  ...
 
  ===  Cleaning for pkg-1.0.8
  ===  License BSD accepted by the user
  ===  Extracting for pkg-1.0.8
  = SHA256 Checksum OK for pkg-1.0.8.tar.xz.
  ===  Patching for pkg-1.0.8
  ===  Configuring for pkg-1.0.8
  ===   FreeBSD 10 autotools fix applied to
 /usr/ports/ports-mgmt/pkg/work/pkg-1.0.8/external/libyaml/aclocal.m4
  ===   FreeBSD 10 autotools fix applied to
 /usr/ports/ports-mgmt/pkg/work/pkg-1.0.8/external/libyaml/configure
  ===  Building for pkg-1.0.8
  /usr/share/mk/bsd.own.mk, line 423: WITH_PROFILE and WITHOUT_PROFILE
 can't both be set.
  *** [do-build] Error code 1
 
  Stop in /usr/ports/ports-mgmt/pkg.
 
  === make failed for ports-mgmt/pkg
  === Aborting update
 
  === Update for pkg-1.0.7 failed
  === Aborting update
 
  Terminated
 
  === You can restart from the point of failure with this command line:
 portmaster flags print/texinfo ports-mgmt/pkg
 

 No pkgng is not broken but it is using bsd.prog.mk and bsd.lib.mk meaning
 it is
 sensitive to any /etc/make.conf and /etc/src.conf configuration.

 Can you try adding the following to
 ports-mgmt/pkg/Makefile
 line 23:
 replace
 MAKE_ENV+= WITHOUT_PROFILE=yes
 by
 MAKE_ENV+= WITHOUT_PROFILE=yes __MAKE_CONF=/dev/null SRCCONF=/dev/null

 And tell me if it fixes the problem for you?

 regards,
 Bapt




-- 
Freddie Cash
fjwc...@gmail.com
___
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: Ports cvs deprecation warning

[Freddie Cash]

On Jan 12, 2013 2:31 PM, Anton Shterenlikht me...@bristol.ac.uk wrote:

 Date: Thu, 10 Jan 2013 08:55:50 -0700 (MST)
 From: Warren Block wbl...@wonkity.com

 Given the upcoming cvs deprecation in a little over a month, how
about
 putting a reminder in /usr/ports/UPDATING now?

 Mention that cvs mirrors will be going away and point to the
portsnap
 and svn update methods shown in the Handbook:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html

 I probably missed something.

 Usually I do a minimal install,
 then pull the ports tree via csup,
 then install subversion, etc.

 If neither csup nor subversion are
 in base, then how do I get the ports
 tree in the first instance, if I
 forgot or intentionally didn't install
 ports as part of bsdinstall?

man portsnap
___
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: Ports cvs deprecation warning

[Freddie Cash]

 man portsnap

 Does is work on non amd64/i386 arches
 (sparc64 and ia64 specifically)?

Honestly couldn't tell you, as I have no experience with or access to
non-x86 systems.
___
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: reading epub files?

[Freddie Cash]

Okular, the main document viewer for KDE4, supports ePub.
On Nov 13, 2012 12:17 PM, Robert Huff roberth...@rcn.com wrote:


  A quick grep of the ports index doesn't find any likely
 candidates.  Does such a port exist?

 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

___
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: Portmaster/Portupgrade | pkg2ng

[Freddie Cash]

On Tue, Oct 16, 2012 at 2:11 PM, Jos Chrispijn ker...@webrz.net wrote:
 Somewhat lost here; just read UPDATING in which is reported about an
 additional function support of pkgng by portupgrade and portmaster:

 PORTMASTER
   # make -C /usr/ports/ports-mgmt/portmaster config build deinstall install
 clean
   # echo 'WITH_PKGNG=yes'  /etc/make.conf
   # pkg2ng*

 PORTUPGRADE
   # echo 'WITH_PKGNG=yes'  /etc/make.conf
   # pkg2ng*
   # pkgdb -fu

 The only issue I have is that this pkg2ng command doesn't work as this
 program* cannot be found so the command returns with a 'pkg2ng: Command not
 found.'
 Can someone tell me what I miss here?

http://www.wonkity.com/~wblock/docs/html/interrupted.html

Check number 3.  :)

-- 
Freddie Cash
fjwc...@gmail.com
___
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: How can I know popularity of ports?

[Freddie Cash]

It includes an option to submit the list of currently installed ports.
On Sep 30, 2012 10:00 PM, Cpet Services cpetserv...@gmail.com wrote:

 Isn't that for OS usage rather ports ?

 On Sun, Sep 30, 2012 at 11:57 PM, Freddie Cash fjwc...@gmail.com wrote:

 Bsdstats port does something similar. It's opt-in, so the stats are
 heavily
 selection biased (similar to popcon).
 On Sep 30, 2012 9:49 PM, meta m...@vmeta.jp wrote:

  Is there any ways to know how popular a port is? For example, Debian
  Popularity Contest http://popcon.debian.org/ tells us usage of
  packages. Does FreeBSD Ports Collection have similar work to popcon?
 
  --
  `whois vmeta.jp | nkf -w`
  meta m...@vmeta.jp
  ___
  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




 --
 
 Chris Petrik
 FreeBSD Contributor
 Reincarnated
 cpet on irc


___
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: How can I know popularity of ports?

[Freddie Cash]

Bsdstats port does something similar. It's opt-in, so the stats are heavily
selection biased (similar to popcon).
On Sep 30, 2012 9:49 PM, meta m...@vmeta.jp wrote:

 Is there any ways to know how popular a port is? For example, Debian
 Popularity Contest http://popcon.debian.org/ tells us usage of
 packages. Does FreeBSD Ports Collection have similar work to popcon?

 --
 `whois vmeta.jp | nkf -w`
 meta m...@vmeta.jp
 ___
 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: [CORRECTION] Change to the header in ports Makefiles, take two

[Freddie Cash]

On Mon, Sep 17, 2012 at 9:33 AM, Thomas Abthorpe
portmgr-secret...@freebsd.org wrote:
 It was recently posted on,
 http://blogs.freebsdish.org/portmgr/2012/09/01/change-to-the-header-in-ports-makefiles/
 that we would adopt a new header for the ports Makefiles.  The initial
 discussion seemed to show enough support for the idea of completely
 stripping the header, leaving only the $FreeBSD$ tag.  After the
 announcement was made, more people stated strong feelings that when and
 where possible attribution be maintained in the header.

 A private discussion was held among ports committers, and while opinions
 were as varied as the individuals who shared them, it was decided to unify
 on a two line header.

 # Created by: J.Q. Public jqpub...@someaddress.com
 # $FreeBSD$

 The Whom line from the classic six line header becomes Created By.

 Sometimes, as a result of a repocopy, or changed maintainership, the
 Created By and MAINTAINER is no longer in synchronisation. To avoid
 confusion, the first line can be removed, optionally leaving us with a one
 line header.

 # $FreeBSD$

Wouldn't it make sense to have the # $FreeBSD$ line be the first
line of the file, so that it never changes?  Having some files where
the FreeBSD tag is first, and other files where it's second seems
arbitrarily inconsistent.

Lines that don't change should come first, so that things are always the same.

IMHO, of course.  :)

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Port system problems

[Freddie Cash]

On Tue, Jun 26, 2012 at 1:56 PM, Peter Jeremy pe...@rulingia.com wrote:
 but I hope the ports build system will not
 be thrown out as part of the pkgng migration.

Where do you think packages would come from, if not built by the ports tree?  ;)

-- 
Freddie Cash
fjwc...@gmail.com
___
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: pkgng beta 11: pkg-static: The database is outdated and opened readonly *** Error code 74

[Freddie Cash]

On Mon, Apr 16, 2012 at 2:05 PM, Baptiste Daroussin b...@freebsd.org wrote:
 Well normally just once you have build your port (before installing) just make
 deinstall, ./work/pkg-beta11/pkg-static/pkg-static info, it should upgrade 
 your
 database.

 Then make install should finish the work.

And, if it doesn't?

Was running beta8.  Tried to upgrade to beta11.  Got the
outdated/opened readonly error.  Doing the deinstall/pkg-static
command above gave the same error the first time it was run.  The
second time it returned successfully but there was 0 output.

Now, running the pkg-static info command from the workdir gives the
exact same outdated/readonly error.

Is there anyway to recover the database?  Especially considering that
/var/db/pkg/ is blank except for the local.sqlite file.


-- 
Freddie Cash
fjwc...@gmail.com
___
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: pkgng beta 11: pkg-static: The database is outdated and opened readonly *** Error code 74

[Freddie Cash]

On Wed, Apr 18, 2012 at 1:46 PM, Baptiste Daroussin b...@freebsd.org wrote:
 On Wed, Apr 18, 2012 at 01:31:37PM -0700, Freddie Cash wrote:
 On Mon, Apr 16, 2012 at 2:05 PM, Baptiste Daroussin b...@freebsd.org wrote:
  Well normally just once you have build your port (before installing) just 
  make
  deinstall, ./work/pkg-beta11/pkg-static/pkg-static info, it should upgrade 
  your
  database.
 
  Then make install should finish the work.

 And, if it doesn't?

 Was running beta8.  Tried to upgrade to beta11.  Got the
 outdated/opened readonly error.  Doing the deinstall/pkg-static
 command above gave the same error the first time it was run.  The
 second time it returned successfully but there was 0 output.

 Now, running the pkg-static info command from the workdir gives the
 exact same outdated/readonly error.

 Is there anyway to recover the database?  Especially considering that
 /var/db/pkg/ is blank except for the local.sqlite file.

 yes there is, are you running what version/arch FreeBSD are you using? 
 depending
 on that I can give you the workaround.

Whew.  Good to hear.  :)

uname -a:
FreeBSD rogue.ashesofthe.net 8.2-STABLE FreeBSD 8.2-STABLE #1 r226546:
Sun Jan 22 02:10:54 PST 2012
r...@rogue.ashesofthe.net:/usr/obj/usr/src-8/sys/ROGUE  i386

 I'm still trying to figure out what is preventing beta11 from being about to
 upgrade from beta8, and fix it, so can you send me you local.sqlite ?

As it's a 50 MB file, you can download it from here:
http://www.sd73.bc.ca/downloads/local.sqlite

-- 
Freddie Cash
fjwc...@gmail.com
___
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: pkgng beta 11: pkg-static: The database is outdated and opened readonly *** Error code 74

[Freddie Cash]

On Wed, Apr 18, 2012 at 2:26 PM, Baptiste Daroussin b...@freebsd.org wrote:
 Just upgrade your ports tree beta11 is fixed
 /me feels really ashamed for that bug :)

It hasn't hit the portsnap servers yet.  I'll try again later tonight
or tomorrow and let you know if things work for me.


-- 
Freddie Cash
fjwc...@gmail.com
___
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: pkgng beta 11: pkg-static: The database is outdated and opened readonly *** Error code 74

[Freddie Cash]

On Wed, Apr 18, 2012 at 2:42 PM, Freddie Cash fjwc...@gmail.com wrote:
 On Wed, Apr 18, 2012 at 2:26 PM, Baptiste Daroussin b...@freebsd.org wrote:
 Just upgrade your ports tree beta11 is fixed
 /me feels really ashamed for that bug :)

 It hasn't hit the portsnap servers yet.  I'll try again later tonight
 or tomorrow and let you know if things work for me.

Aha!  All good things come to those who wait.  :)  The update just
showed up in portsnap.

And the ports-mgmt/pkg port built successfully.  Running pkg-static
info from the workdir was successful.  And, installing the port
completed successfully.

And, doing a portmaster upgrade of another port also completed successfully.

Thanks!!

Keep up the good work on pkg.  All I'm waiting (patiently) for are
some public repos to start cropping online.  :)
-- 
Freddie Cash
fjwc...@gmail.com
___
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: port variants

[Freddie Cash]

On Fri, Apr 13, 2012 at 12:04 PM, Chris Inacio nacho...@gmail.com wrote:
 I was recently asked to do some FreeBSD ports support work.  I mostly use a
 Mac and the MacPorts system.  MacPorts has the concept of a variant for a
 port, but I can't find the analogue in the FreeBSD system.

 Does the FreeBSD ports system have the concept of a variant?  If so, can
 someone point me in the right direction on how to create one?

Describing what a variant is, how it works in MacPorts, and what you
are trying to do would help a lot.  :)

The closest guess I could make would be slave port, but I don't
think that works the same way.

-- 
Freddie Cash
fjwc...@gmail.com
___
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: PORT: multimedia/phonon-xine

[Freddie Cash]

On Mar 3, 2012 4:36 AM, Jerry je...@seibercom.net wrote:

 Attempting to build the multimedia/phonon-xine port produces this
 error message:

 ===  phonon-xine-4.4.4_2 is marked as broken: deprecated upstream;
refuses to build with libxine 1.2.x.
 *** Error code 1

 What is the status of getting this port fixed or the recommended
 procedure to circumvent this problem?

Switch to one of the other phonon backends? There's phonon-vlc and
phonon-gstreamer available.

Perhaps you could leave the xine port at pre-1.2.0 and get phonon-xine to
update. Since I'd already switched to the VLC backend in KDE, I just
uninstalled the xine ports

Cheers,
Freddie Cash
fjwc...@gmail.com
___
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: Fix nvidia-like ports, help needed

[Freddie Cash]

On Fri, Mar 2, 2012 at 10:49 AM, Konstantin Belousov
kostik...@gmail.com wrote:
 And yes, I use a script that checks PCI devices on boot and symlinks
 libGL.so.1 and libglx.so to appropriate implementations. The only trouble
 right now is that reinstall of libGL or nvidia driver ports requires
 manual fixing of the .so.

Ah, but splitting the GL bits out into slave ports would fix that.  :)

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Fix nvidia-like ports, help needed

[Freddie Cash]

On Fri, Mar 2, 2012 at 11:02 AM, Konstantin Belousov
kostik...@gmail.com wrote:
 On Fri, Mar 02, 2012 at 10:54:46AM -0800, Freddie Cash wrote:
 On Fri, Mar 2, 2012 at 10:49 AM, Konstantin Belousov
 kostik...@gmail.com wrote:
  And yes, I use a script that checks PCI devices on boot and symlinks
  libGL.so.1 and libglx.so to appropriate implementations. The only trouble
  right now is that reinstall of libGL or nvidia driver ports requires
  manual fixing of the .so.

 Ah, but splitting the GL bits out into slave ports would fix that.  :)

 No, it moves the moment of problem from mesa/nvidia update to mesa-libGL
 and nvidia-libGL update. And, libGl.so.1 from Mesa is already in the
 separate port, FWIW.

How?  Unless the ports include the creation of the symlink (which they
shouldn't), then there is no problem anymore.

You install nvidia-gl port, you get libGL-nvidia.so installed.

You install mesa-gl port, you get libGL-mesa.so installed.

You run the alternatives script to create the symlink (or manually
create it, or tweak a knob somewhere to create it), and then never
touch it again.

Update nvidia-gl port, only libGL-nvidia.so gets updated.  The symlink
doesn't change.

Update mesa-gl port, only libGL-mesa.so gets updated.  The symlink
doesn't change.

Where's the problem?

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Fix nvidia-like ports, help needed

[Freddie Cash]

The problem is when tools like portmaster notice x11/nvidia-driver
(not installed) has a newer version number than x11/nvidia-driver-173
(installed), and the mesa/dri/drm ports have updates available, and
then builds/installs them in the wrong order such that the
x11/nvidia-driver port is installed first, the x11/nvidia-driver-173
port is removed, and then the x11/meda/dri/drm ports are installed,
leaving you with a broken mess.

You get an nvidia.ko that doesn't support the video card installed in
the machine, an nvidia X11 driver that links against the wrong
libGL.so, and thus a broken X11 setup that can lead to a lot of
frustration, gnashing of teeth, and tearing of sackcloth to get sorted
out.  :(

There are three issues here (at least for me, although it's really
only the last one that's the topic of this thread):
  - the fact that portmaster sees nvidia-driver instead of
nvidia-driver-173 as the port name and installs the wrong port
  - the fact that portmaster installs nvidia-driver before the
x11/mesa/dri/drm ports
  - the fact that both the nvidia-driver* and x11/mesa/dri/drm ports
install libGL.so, and the wrong one is installed last

The combination of those three means that any upgrade of nvidia/x11
ports requires a lot of manual hand-holding to make sure things are
installed in the right order, and that the correct ports are installed
(thank god of -i).

That last option is the one that causes all the issues.  Two ports
install the same file, but they aren't listed as CONFLICTS of each
other, so it's up to the end-user to make it work.

Ideally, the best solution would be to fix those ports such that they
don't install the same file, and that they are listed as CONFLICTS of
each other.  A nice solution would be, as you suggested, separating
out the libGL bits into slave ports and only installing one of them
(and getting the versioning right so that updates only occur in the
right port).

The other issues are slightly annoying, although not really sure how
to fix them permanently, and they're outside the scope of this thread.

(This issue is making me regret installing an nVidia video card into
my home desktop.  Life was so much simpler with Ati and Intel.)
___
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: Input on most correct way to set IS_INTERACTIVE for Postfix ports

[Freddie Cash]

On Tue, Feb 7, 2012 at 12:37 PM, Sahil Tandon sa...@tandon.net wrote:
 On Feb 7, 2012, at 9:44 AM, rfl...@acsalaska.net wrote:

 mail/postfix and its derivatives are interactive when ALL of the
 following conditions are true:

 - PACKAGE_BUILDING is undefined
 - /etc/mail/mailer.conf exists
 - /etc/mail/mailer.conf contains a line beginning with 'purgestat'
   - POSTFIX_DEFAULT_MTA is unset

 Right, but regardless of whether this is set, or what it is set to, the 
 script still asks a question unless other conditions are met, and only the 
 default answer (that is displayed along with the query) is affected.  Are you 
 suggesting that we change the behavior to not ask the question at all, and 
 just leave mailer.conf alone if the latter variable above is unset, and 
 always change mailer.conf if it is set?  I just want to make sure I 
 understand your suggestion.

Couldn't you add an OPTION for updating mailer.conf? Then, if that
OPTION is set, update mailer.conf; and if it isn't set, then leave
mailer.conf alone.

Then remove the IS_INTERACTIVE completely.

-- 
Freddie Cash
fjwc...@gmail.com
___
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