Port Update format

[Doug Hardie]

I am the maintainer of the qpopper port.  I now have the IPv6 patches  
working for qpopper-4.0.9 and would like to update the port with  
them.  What is the proper format to submit the update?

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

sendip port

[Doug Hardie]

Has anyone managed to get sendip on 7.2 to work for IPv6?  No matter  
what I have tried it always sets the next header field to 'ff'.

___
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: "stable" ports?

[Doug Hardie]

On 29 March 2010, at 08:57, Ivan Voras wrote:

> In some cases the burdens are obvious - the maintainer(s) would need to
> e.g. maintain three versions of the ports - a random example would be
> e.g. X.Org 7.0 for 6.x, 7.2 for 7.x and 7.4 for 8.x. Another would be
> keeping PHP 5.2 for 7.x and 8.x and having 5.3 in the future
> (CURRENT/9.x) branch.

I am a bit concerned about your concept of maintain, being able to build a port 
successfully, does not necessarily mean it will work properly.  For example, 
qpopper (which I maintain) has an issue where one feature does not work 
properly on 64 bit machines where it works fine on 32 bit machines.  In 
addition, there are a number of other machine types that are currently not 
heavily used but might become so in the future.  Thats a lot of different 
combinations of hardware and OSs to keep running for the maintainers.  
___
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"

Request for qpopper testers

[Doug Hardie]

I didn't see my first announcement come back to me so am trying again.

Qpopper 4.1.0 has been released and I have a first cut at the port files ready 
for testing.  It builds fine with and without APOP.  Presently I don't have a 
way to actually run it as my test machine is setup for a client who absolutely 
needs dovecot.  If you would like to test it, email me and I will send the port 
files.  I should be able to start testing in about 2 
weeks.___
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"

spamd port

[Doug Hardie]

I am trying to get the port mail/spamd to work on FreeBSD 6.2.  There  
is not a lot of information on actually using spamd.  So far I have  
figured out that I have to kldload pf and then a pfctl -e before  
attempting to start spamd.  However, spamd-setup actually does  
nothing.  pfctl -s rules shows an error message:


No ALTQ support in kernel
ALTQ related functions disabled

I have no idea what ALTQ is (or if its even required) since I can find  
no references to it in the kernel config files or kld modules.  There  
is a page on setting up spamd at http://www.bgnett.no/~peter/pf/en/spamd.setup.html 
 but it doesn't address this issue or have any extra steps that need  
to be done.  Any ideas what is going on here?

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Package location

[Doug Hardie]

Adding ports to FreeBSD 7 I normally build from source and create a  
package.  With previous versions the created packages went into /usr/ 
ports/packages/All.  However the packages directory was not created on  
a new installation.  The packages were being built in the ports top  
level directory.  Before I noticed that, I created a packages  
directory and the remaining packages are being built in it as before.   
I didn't find any indications of a change in the various notes with  
the release.  Has there been a change in the package structure?

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Package location

[Doug Hardie]

On Mar 2, 2008, at 23:50, Scot Hetzel wrote:


On 3/2/08, Doug Hardie <[EMAIL PROTECTED]> wrote:

Adding ports to FreeBSD 7 I normally build from source and create a
package.  With previous versions the created packages went into /usr/
ports/packages/All.  However the packages directory was not created  
on

a new installation.  The packages were being built in the ports top
level directory.  Before I noticed that, I created a packages
directory and the remaining packages are being built in it as before.
I didn't find any indications of a change in the various notes with
the release.  Has there been a change in the package structure?


That is how it always worked.

If you don't create the /usr/ports/packages directory, then make
package in /usr/ports// will place the newly created
package in this directory.


I don't recall ever having to create the directory.  Seems like the  
base install created it for me.  Anyway, I have moved all of them  
there and everything seems to work fine.  Thanks.

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Package location

[Doug Hardie]

On Mar 3, 2008, at 11:43, Ion-Mihai Tetcu wrote:


On Mon, 3 Mar 2008 00:39:54 -0800
Doug Hardie <[EMAIL PROTECTED]> wrote:



On Mar 2, 2008, at 23:50, Scot Hetzel wrote:


On 3/2/08, Doug Hardie <[EMAIL PROTECTED]> wrote:

Adding ports to FreeBSD 7 I normally build from source and create a
package.  With previous versions the created packages went
into /usr/ ports/packages/All.  However the packages directory was
not created on
a new installation.  The packages were being built in the ports top
level directory.  Before I noticed that, I created a packages
directory and the remaining packages are being built in it as
before. I didn't find any indications of a change in the various
notes with the release.  Has there been a change in the package
structure?


That is how it always worked.

If you don't create the /usr/ports/packages directory, then make
package in /usr/ports// will place the newly created
package in this directory.


I don't recall ever having to create the directory.  Seems like the
base install created it for me.  Anyway, I have moved all of them
there and everything seems to work fine.  Thanks.


Probably you chose not to install the ports tarball.


Nope.  That was selected and installed.


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Qpopper 4.0.12

[Doug Hardie]

Qpopper 4.0.12 has recently been released.  However there are a few  
bugs in that version.  It can be made to work, but it requires  
altering the format of the config file.  I have been working with the  
qpopper developers to get those fixed and a new config file parser has  
been created that will properly parse the file is going to be  
incorporated into 4.1.x.  Apparently there will be a 4.0.13 that backs  
out the changes in .12 that are causing most of the problems.


4.0.12/13 does not incorporate any significant updates or changes.  In  
addition, the IPv6 patches have not yet been tested.  My thoughts are  
to not update the qpopper port until 4.1.x is released which will have  
the problems resolved as well as incorporate IPv6.  If this is a  
problem for anyone, please let me know.

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

qpopper update

[Doug Hardie]

I am in the final stages of updating the qpopper port from version 4.0  
to 4.1.  However, there are a number of patches that have been  
incorporated into qpopper in the past that raise some questions.   
qpopper alters the names of all the binaries from popper* to  
qpopper*.  I first thought that was done to avoid name conflicts with  
the port popper.  However, upon investigating, the popper port is an  
older version of qpopper.  Is there a reason to maintain two different  
versions of qpopper?  Could we just have the current version as popper  
and use the original names for things?  Is there a reason the qpopper  
binary is stored in /usr/local/libexec where the default qpopper  
installation is in /usr/local/sbin?



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Port abcde and cdparanoia

[Doug Hardie]

I am converting a system from 8.2 to 9.0 and have encountered a significant 
problem with abcde and cdparanoia.  On the new system, both of them believe the 
CD is blank.  Here is the output of cdparanoia as its a bit more informative:

> master# cdparanoia -vsQ
> cdparanoia III release 9.8 (March 23, 2001)
> (C) 2001 Monty  and Xiphophorus
> FreeBSD porting (c) 2003
>   Simon 'corecode' Schubert 
> 
> Report bugs to paran...@xiph.org
> http://www.xiph.org/paranoia/
> 
> Checking /dev/cd0 for cdrom...
> 
> CDROM model sensed: HL-DT-ST CDRW/DVD GCC4244 B101 
> 
> Checking for ATAPICAM...
>   Drive is ATAPI (using ATAPICAM or direct CAM (S)ATA transport)
> 
> Checking for MMC style command set...
>   Drive does not have MMC CDDA support
> 003: CDROM reporting illegal number of tracks
> 
> Unable to open disc.  Is there an audio CD in the drive?

However cdcontrol has no problem obtaining the track list:

> master# cdcontrol -f/dev/cd0 info
> Starting track = 1, ending track = 6, TOC size = 58 bytes
> track start  duration   block  length   type
> -
> 1   0:02.00  10:09.73   0   45748  audio
> 2  10:11.73   9:35.45   45748   43170  audio
> 3  19:47.43   6:48.08   88918   30608  audio
> 4  26:35.51   9:34.64  119526   43114  audio
> 5  36:10.40   8:01.63  162640   36138  audio
> 6  44:12.28   1:20.14  1987786014  audio
>   170  45:32.42 -  204792   -  -
> 

I need to be able to rip the cd to mp3 format.  I don't see anyway to start 
that with cdcontrol.  cdcontrol is also able to play the cd.  I have tried 
another drive and it gives exactly the same results.  Any ideas how to get 
around this?


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

New Port Options

[Doug Hardie]

I just converted a port over to the new options structure and have a few 
observations.  I have not been involved in any of the discussions about the 
structure as I didn't have the time to get involved.  However, a couple things 
came to mind during the process:

1.  The Port handbook is actually quite good in the information it provides.  
However, it does presume that you know a few things about the port structure 
that are probably common knowledge to anyone involved with it, but not to those 
of us who just "use" it.  The first update I made to the Makefile cause a slew 
of make errors that were pretty much useless.  They meant nothing to me.  My 
first thought was that somehow I had munged one of the includes and managed to 
include some random file rather than the right one.

My second idea was that I had typed the option names wrong, but that didn't 
seem to fit with the error messages either.  After quite a while of reading the 
handbook, I noticed that in the PORT_OPTIONS clause you have to precede the 
option name with a M.  That is not at all obvious and is easily missed. Why an 
M is also baffling.  I am sure there is a reason other then it just won't work 
otherwise.

2.  The syntax for a conditional expression for an option that is selected is 
completely different from that for an option that is not selected.  That is 
just weird.  The use of {} for one and () for the other again must have some 
reason other than it just won't work otherwise.  No clue is given in the 
handbook.

3.  The examples are a bit difficult to distinguish between {} and ().  I had 
to look quite a few times before I figured that out.

4.  The handbook shows for submitting a change to a port the use of a regular 
diff.  My recollection is that the last time a unified diff was requested so 
that things like the file names show.

I only maintain one port so the effort to make the changes would have been 
quite minor for additional ports.  Its really not that big a change from the 
maintainer's point of view.___
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: New Port Options

[Doug Hardie]

On 6 October 2012, at 06:32, Eitan Adler wrote:

> On 6 October 2012 01:01, Doug Hardie  wrote:
>> I just converted a port over to the new options structure and have a few 
>> observations.  I have not been involved in any of the discussions about the 
>> structure as I didn't have the time to get involved.  However, a couple 
>> things came to mind during the process:
> 
> Thank you very much for this mail. Since the people writing the
> documentation are often the people "very involved" it can be hard to
> understand what may confuse someone that isn't insane^W^W doesn't work
> on ports all the time.

For me (and possibly others) the makefile is a necessary "evil" to get things 
to work.  Its not something we spend any more time on than necessary.

> 
>> 1.  The Port handbook is actually quite good in the information it provides. 
>>  However, it does presume that you know a few things about the port 
>> structure that are probably common knowledge to anyone involved with it, but 
>> not to those of us who just "use" it.  The first update I made to the 
>> Makefile cause a slew of make errors that were pretty much useless.  They 
>> meant nothing to me.  My first thought was that somehow I had munged one of 
>> the includes and managed to include some random file rather than the right 
>> one.
> 
> make(1) errors can be pretty obtuse at times. It is hard to account
> for all the errors here, but is there something specific that would
> have helped you?

Thats really difficult to say at this point - now that I have read all the 
comments and understand whats actually happening.  I had a number of options 
and there were complaints about single letters.  Eventually I noticed that they 
matched the first letter of each option.  That led me to the M in the example.

> 
>> My second idea was that I had typed the option names wrong, but that didn't 
>> seem to fit with the error messages either.  After quite a while of reading 
>> the handbook, I noticed that in the PORT_OPTIONS clause you have to precede 
>> the option name with a M.  That is not at all obvious and is easily missed. 
>> Why an M is also baffling.  I am sure there is a reason other then it just 
>> won't work otherwise.
> 
> make(1) allows processing on variable contents.  In particular the 'M' option:
> 
> :Mpattern   Select only those words that match the rest of the modifier.
> The standard shell wildcard characters (`*', `?', and `[]')
> may be used.  The wildcard characters may be escaped with a
> backslash (`\').
> 
> 
> This should be made more clear in the handbook.

Perhaps a note in the handbook prior to the examples that when referencing an 
option name, the letter M must be prepended because of the way make works.  
Forgetting to include the M will cause some really weird error messages.

> 
>> 2.  The syntax for a conditional expression for an option that is selected 
>> is completely different from that for an option that is not selected.  That 
>> is just weird.  The use of {} for one and () for the other again must have 
>> some reason other than it just won't work otherwise.  No clue is given in 
>> the handbook.
> 
> See bapt@'s comments. That said, it should be made more clear ;)

I would have used some of the alternate expressions if I had known about them.  
I will never remember what those mean the next time I have to look at the 
makefile.

> 
>> 3.  The examples are a bit difficult to distinguish between {} and ().  I 
>> had to look quite a few times before I figured that out.
> 
> Was this a font issue? Is there something we could do to help? Perhaps
> add more spacing?

Perhaps its a font issue, but I am not sure I would have noticed it the first 
time anyway.  I was just quickly scanning to see what needed to be done.  I 
make no pretense of understanding makefiles.  I just use them.  Perhaps a note 
where the constructs are introduced would catch the reader's attention.

> 
>> 4.  The handbook shows for submitting a change to a port the use of a 
>> regular diff.  My recollection is that the last time a unified diff was 
>> requested so that things like the file names show.
> 
> This is likely an oversight. Unified diffs are much preferred.  I've
> sent in a patch for approval to correct this issue.
> 
>> I only maintain one port so the effort to make the changes would have been 
>> quite minor for additional ports.
> 
> As I said above, your perspective is needed when it comes to the
> documentation.
> 
>> Its really not that big a change from the maintainer

Upgrading to 12.0

[Doug Hardie]

I upgraded via pkg a test system from 11.0 to 12.0 a couple days ago.  After 
getting everything there working, I upgraded a 11.1 production system to 12.0.  
Things are a bit weird with this one.  The htmldoc port never got updated on 
either system.  It asks for libssl.so.8.  That doesn't exist anymore on 12.0.  
I copied it, along with libcrypto and libarchive, over from a production system 
to the test system and things worked.

I ran pkg upgrade on the production system and it has the same problem.  It 
first appeared that for some reason htmldoc was never compiled on 12.0.  Then I 
investigated farther and things are quite unusual.

>From the test system:

test# ldd /usr/local/bin/htmldoc
/usr/local/bin/htmldoc:
libssl.so.8 => /usr/lib/libssl.so.8 (0x800683000)
libcrypto.so.8 => /lib/libcrypto.so.8 (0x800a0)
libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x8008f6000)
libz.so.6 => /lib/libz.so.6 (0x800933000)
libjpeg.so.8 => /usr/local/lib/libjpeg.so.8 (0x80094d000)
libm.so.5 => /lib/libm.so.5 (0x800e6f000)
libc++.so.1 => /usr/lib/libc++.so.1 (0x800ea1000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800f7)
libc.so.7 => /lib/libc.so.7 (0x800f91000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8009e3000)
test# ll /lib/libssl*
ls: No match.
test# ll /usr/lib/libssl*
-r--r--r--  1 root  wheel  4395354 Dec 12 23:27 /usr/lib/libssl.a
lrwxr-xr-x  1 root  wheel   13 Dec 12 23:27 /usr/lib/libssl.so -> 
libssl.so.111
-r--r--r--  1 root  wheel   604936 Dec 12 23:27 /usr/lib/libssl.so.111
-r--r--r--  1 root  wheel   470352 Dec 14 18:22 /usr/lib/libssl.so.8
-r--r--r--  1 root  wheel  4502998 Dec 12 23:27 /usr/lib/libssl_p.a
test# uname -a
FreeBSD test 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC  amd64



>From the production system:

master# ldd /usr/local/bin/htmldoc
/usr/local/bin/htmldoc:
libssl.so.8 => not found (0)
libcrypto.so.8 => not found (0)
libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x800683000)
libz.so.6 => /lib/libz.so.6 (0x8006c)
libjpeg.so.8 => /usr/local/lib/libjpeg.so.8 (0x8006da000)
libm.so.5 => /lib/libm.so.5 (0x80077)
libc++.so.1 => /usr/lib/libc++.so.1 (0x8007a2000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800871000)
libc.so.7 => /lib/libc.so.7 (0x800892000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800c85000)
master# ll /usr/local/lib/libssl*
-rw-r--r--  1 root  wheel  664692 Dec  8 11:46 /usr/local/lib/libssl.a
lrwxr-xr-x  1 root  wheel  16 Dec  8 11:46 /usr/local/lib/libssl.so@ -> 
libssl.so.45.0.1
lrwxr-xr-x  1 root  wheel  16 Dec  8 11:46 /usr/local/lib/libssl.so.45@ -> 
libssl.so.45.0.1
-rw-r--r--  1 root  wheel  350496 Dec  8 11:46 /usr/local/lib/libssl.so.45.0.1
master# uname -a
FreeBSD master 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC  amd64


The two versions of htmldoc appear to be identical and old.  They never got 
updated.  However, the versions of libssl don't match at all.  One is version 
111 and the other 45.  The version 45 is older date wise, and almost twice as 
big.  There was only a couple days between the runs of pkg on those systems.  I 
can't imagine why the version numbers are so different.  I expected to find the 
version numbers and the dates identical between the two systems.

For the time being I'll copy the old versions of libssl, libcrypto, and 
libarchive back onto the production system, but that doesn't seem like the 
right way to be running the system.  It seems to work though.

-- Doug

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

Dovecot packages

[Doug Hardie]

Some years ago I setup a server with dovecot2 package.  At that time there were 
2 dovecot packages: dovecot which had a version of 1.x and dovecot2 which had a 
version of 2.x.  That made sense since dovecot v2 is quite different from v1.

As time went on I was upgrading that server to FreeBSD 12-RELEASE and just did 
a pkg upgrade during the upgrade process.  Dovecot upgraded to a more recent 
v2.x.  However, it no longer worked.  There were numerous error messages 
logged.  I thought that was strange since I had another system with dovecot v2 
running just fine.  Eventually I discovered that the two dovecot packages have 
changed.  The working system was a dovecot package which is now v2.y where y is 
significantly greater than dovecot2 v2.x.  It appears that the dovecot package 
is now the one that is maintained and dovecot2 package has remained stagnant.  

Unless you notice this interesting anomaly, you can get easily burned like I 
did.  I would recommend that either the dovecot2 package be deleted, or at 
least kept current with the dovecot package.

-- Doug

___
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: Dovecot packages

[Doug Hardie]

> On 22 May 2019, at 16:23, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> Doug Hardie wrote on 2019/05/23 00:41:
> 
> [...]
> 
>> Unless you notice this interesting anomaly, you can get easily burned like I 
>> did.  I would recommend that either the dovecot2 package be deleted, or at 
>> least kept current with the dovecot package.
> 
> There is no dovecot2 package in the official FreeBSD repository / ports tree: 
> https://www.freshports.org/search.php?query=dovecot
> 
> You have very stale packages on your machines and you didn't read 
> instructions in UPDATING file of "pkg updating" command:

Thats quite interesting.  When I run pkg updating command, the first entry is 
dated 20160616.

pkg-1.10.5_5   Package manager

# freebsd-version -ku
12.0-RELEASE-p3
12.0-RELEASE-p3

brain# pkg update
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
brain# pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (0 candidates): 100%
Processing candidates (0 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.



Same results on all my machines.


> 
> 
> 20170807:
>  AFFECTS: users of mail/dovecot2 and mail/dovecot2-pigeonhole
>  AUTHOR: ad...@freebsd.org
> 
>  Now that dovecot1 has been removed from the ports tree, dovecot2
>  and dovecot2-pigeonhole have been renamed to simply dovecot and
>  dovecot-pigeonhole.
> 
>  pkg should handle the rename automatically, but if you run into
>  trouble, you can point pkg at the new origin via:
> 
>  # pkg set -o mail/dovecot2:mail/dovecot
>  # pkg set -o mail/dovecot2-pigeonhole:mail/dovecot-pigeonhole
> 
>  Similarly, you can point portmaster at the new location via:
> 
>  # portmaster -o mail/dovecot mail/dovecot2
> 
>  If all else fails, just remove and reinstall the package:
> 
>  # pkg delete dovecot2
>  # pkg install dovecot

That was the approach I used.  Worked fine.  Dovecot now works properly again.

> 
> Miroslav Lachman

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

Re: Dovecot packages

[Doug Hardie]

Correct. There is no port tree. Packages are used exclusively 

> On May 23, 2019, at 01:16, @lbutlr  wrote:
> 
>> On 22 May 2019, at 16:41, Doug Hardie  wrote:
>> It appears that the dovecot package is now the one that is maintained and 
>> dovecot2 package has remained stagnant.  
> 
> You didn't replace your port tree when you upgraded to 12.0-RELEASE.
> 
> I think that portsnap fetch extract ensures your ports tree matches the 
> current ports.
> 
> Ah, yes, from the man -8 portsnap:
> 
> extract  Extract a ports tree, replacing existing files and
>  directories.  NOTE: This will remove anything occupying the
>  location where files or directories are being extracted; in
>  particular, any changes made locally to the ports tree (for
>  example, adding new patches) will be silently obliterated.
> 
> ===>
>  Only run this command to initialize your portsnap-maintained
>  ports tree for the first time, if you wish to start over
>  with a clean, completely unmodified tree, or if you wish to
>  extract a specific part of the tree (using the path option).
> ===>
> 
> -- 
> Whoever had created humanity had left in a major design flaw. It was its
> tendency to bend at the knees. --Feet of Clay
> 
> 
> ___
> 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: fetch is tarpitted by Texas Instruments and/or Akamai and can not download distfiles for TI-related ports.

[Doug Hardie]

> On 2 April 2020, at 11:22, Lev Serebryakov  wrote:
> 
> 
> It is true for both IPv4 and IPv6, and for Russia and Germany (I can
> not test from USA, though).
> 
> You could try it yourself:
> 
> http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/8_3_2_2/export/msp430-gcc-support-files-1.209.zip
> 
> http://www.ti.com/lit/ug/slau646e/slau646e.pdf
> 

Both links work for me in southern California.

-- Doug


___
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: [HEADS UP] Planned deprecation of portsnap

[Doug Hardie]

> On 5 August 2020, at 21:30, Eugene Grosbein  wrote:
> 
> 06.08.2020 6:02, Tatsuki Makino wrote
> :
>> Is there any command other than "rm -rf /usr/ports ; portsnap extract"
>> that can be easily repaired?
> 
> svnlite revert -R /usr/ports


master# svnlite revert -R /usr/ports
svn: E155007: '/usr/ports' is not a working copy
master# 
master# rm -rf /usr/ports/*
master# svnlite revert -R /usr/ports
svn: E155007: '/usr/ports' is not a working copy

-- Doug

___
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: [HEADS UP] Planned deprecation of portsnap

[Doug Hardie]

> On 5 August 2020, at 23:57, Eugene Grosbein  wrote:
> 
> 06.08.2020 13:23, Doug Hardie wrote:
> 
>>> On 5 August 2020, at 21:30, Eugene Grosbein  wrote:
>>> 
>>> 06.08.2020 6:02, Tatsuki Makino wrote
>>> :
>>>> Is there any command other than "rm -rf /usr/ports ; portsnap extract"
>>>> that can be easily repaired?
>>> 
>>> svnlite revert -R /usr/ports
>> 
>> 
>> master# svnlite revert -R /usr/ports
>> svn: E155007: '/usr/ports' is not a working copy
>> master# 
>> master# rm -rf /usr/ports/*
>> master# svnlite revert -R /usr/ports
>> svn: E155007: '/usr/ports' is not a working copy
> 
> If portsnap's deprecated, one uses "svnlite checkout" to replace portsnap's 
> data
> with data of Subversion, then "svnlite revert" would work.
> 

Thanks,

-- Doug


___
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: Dropbox on FreeBSD

[Doug Hardie]

On 5 March 2013, at 11:20, Wojciech Puchar  
wrote:

>>> place. One was to eliminate multiple votes from the same IP I believe.
>> 
>>  Hrm. That sounds silly. The Dropbox voting actually encourages it's
> 
> can anyone explain me what is so great in that software.
> 
> got into webpage, and it looks like detailless advert just like plenty of 
> others.
> 
> Found that it "simplify sharing", get quite bored after trying to find out 
> WHAT and HOW it actually provides.

Yep its quite boring.  However, it can provide a useful service.  I use it to 
transfer large audio files from a few people who are not strong computer users 
and its very simple interface is easy for them to use.  They will actually 
remember how to use it and do it and there are clients available for windows 
machines (which they all use).



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

Package issue updating a packag3

[Doug Hardie]

I posted this on questions earlier and got no response.  In the meantime, I 
have a system that is not really functional.

I needed to update clamav-milter.  I used:

pkg upgrade clamav-milter

The result was an error:

Checking integrity... done (1 conflicting)
pkg: Cannot solve problem using SAT solver:
conflict rule: The following packages conflict with each other: 
clamav-milter-0.98.5_1(r), clamav-0.98.5_1(r)
conflict rule: The following packages conflict with each other: 
clamav-milter-0.98.5_1(r), clamav-milter-0.98.5_1(r)
upgrade rule: upgrade local clamav-milter-0.98.4_1 to remote 
clamav-milter-0.98.5_1
cannot install package clamav-milter, remove it from request? [Y/n]: n


pkg list only shows clamav-milter, not clamav.  At one time I did have clamav 
installed, but deleted it.

So I used pkg delete clamav-milter.  That worked.

Then, pkg install clamav-milter.  Same errors.  How do I recover and get an 
updated clamav-milter?

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

Approving a patch

[Doug Hardie]

I am the maintainer for a port.  I received a suggested patch for the port that 
is good.  There used to be a link in the notification email to click on to 
approve the patch.  With the new port system, that is gone (or at least I 
didn’t find it).  I went through the porters manual and didn’t find anything on 
how to approve a patch.  How do I do that?

___
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: Approving a patch

[Doug Hardie]

> On 3 March 2015, at 22:45, Kubilay Kocak  wrote:
> 
> 
> Canonically and preferred:
> 
> Set maintainer-approval flag to + *on the attachment/patch*.
> 
> The maintainer-feedback flag is at the issue/bug scope, not the
> attachment/patch scope.
> 
> This of course requires the maintainer-approval flag was set to ? with
> your email as the value first.
> 
> Currently this is not automatic, but *should be* if there is an
> attachment of type: patch in the issue. I'll create an issue for that
> now for bugmeister@ to look into addressing.
> 
> Only in cases where maintainer-approval is *not* already set to"?", is
> using the maintainer-feedback flag + comment flow OK.
> 
> Setting maintainer-feedback is ambiguous, and is used to prove
> 'acknowledgement' of an issue or question.
> 
> This is especially the case when there are multiple version of patches,
> or patches from multiple contributors. In future it will be used to
> derive "maintainer timeouts" to kick issues along, and open them up for
> someone else to make a decision on.
> 
> tldr; Set the maintainer-approval flag to +
> 

Thanks to all who replied.  I found and set the maintainer-feedback flag at the 
issue/bug scope.  I couldn’t find any similar flag at the attachment/patch 
scope.  Nothing there was really applicable.

___
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: Pourdriere produces faulty build results due to bsd.openssl.mk bug

[Doug Hardie]

> On 1 April 2015, at 14:21, Yuri  wrote:
> 
> On 04/01/2015 14:17, Jung-uk Kim wrote:
>> I know bsd.openssl.mk has been broken for very long time.  For example,
>> 
>> http://docs.freebsd.org/cgi/mid.cgi?50108FEF.3030405
>> 
>> However, I am not sure whether entirely removing it is the best way
>> going forward.
> 
> I mean, removing of the dependency on base. Ports should use only openssl 
> port.
> 
> If you think this isn't a good idea, and ports should still occasionally use 
> base openssl, would you care to explain why you think so?
> 
> Yuri

Some of us don’t use the ports version of openssl because of the issues with 
v1.xxx.  
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

pkg upgrade issue

[Doug Hardie]

On a FreeBSD 9.3 P33 system, I don't seem to be able to upgrade packages:

sermons# pkg upgrade
Updating repository catalogue
pkg: 
ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest//repo.txz:
 File unavailable (e.g., file not found, no access)


— Doug

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

Re: pkg upgrade issue

[Doug Hardie]

/etc/pkg/FreeBSD.conf contains (comments removed):

FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest";,
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
~
That appears to match with your entry below.


> On 22 February 2016, at 00:56, Lars Engels  wrote:
> 
> On Sun, Feb 21, 2016 at 10:03:14PM -0800, Doug Hardie wrote:
>> On a FreeBSD 9.3 P33 system, I don't seem to be able to upgrade packages:
>> 
>> sermons# pkg upgrade
>> Updating repository catalogue
>> pkg: 
>> ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest//repo.txz:
>>  File unavailable (e.g., file not found, no access)
>> 
> 
> Most probably your repository config is wrong.
> Try pkg+http://pkg.FreeBSD.org/${ABI}/latest 

— Doug

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

Re: pkg upgrade issue

[Doug Hardie]

> On 22 February 2016, at 02:13, Baptiste Daroussin  wrote:
> 
> On Sun, Feb 21, 2016 at 10:03:14PM -0800, Doug Hardie wrote:
>> On a FreeBSD 9.3 P33 system, I don't seem to be able to upgrade packages:
>> 
>> sermons# pkg upgrade
>> Updating repository catalogue
>> pkg: 
>> ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest//repo.txz:
>>  File unavailable (e.g., file not found, no access)
>> 
> Can you show the output of pkg -vv please?
> 
> I'm more interested in the lines below "Repositories:"


I copied /usr/local/etc/pkg.conf from another 9.3 system that works:

sermons# pkg -vv
pkg: Invalid configuration format, ignoring the configuration file
version: 1.0.11
abi: freebsd:9:x86:64
db dir: /var/db/pkg
cache dir: /var/cache/pkg
ports dir: /usr/ports
Log into syslog: yes
Assume always yes: no
Repository: none


Removing /usr/local/etc/pkg.conf (original status):
sermons# pkg -vv
version: 1.0.11
abi: freebsd:9:x86:64
db dir: /var/db/pkg
cache dir: /var/cache/pkg
ports dir: /usr/ports
Log into syslog: yes
Assume always yes: no
Repository: none

sermons# pkg update
Updating repository catalogue
pkg: PACKAGESITE is not defined.


PACKAGESITE was defined in ~/.cshrc as:
setenv PACKAGESITE 
ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/

That was removed for the above test.  It was present for the previously report 
pkg output.

As I remember this system was updated to 9.x when there were issues with the 
package system being rebuilt and a workaround was needed.  I no longer recall 
where all the pieces of that were.

___
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: Mail services checking - URGENT

[Doug Hardie]

On Sep 8, 2008, at 06:04, Jeremy Chadwick wrote:


On Mon, Sep 08, 2008 at 05:59:54AM -0700, David Southwell wrote:

On Monday 08 September 2008 05:19:51 Jeremy Chadwick wrote:

On Mon, Sep 08, 2008 at 05:10:27AM -0700, David Southwell wrote:
I have had a series of attacks on a system which resulted in a  
hijack of

our mail system.

I believe I have now fixed the main problem but I need a tool  
that will
reliably, and independently of the mail logs check my network for  
all

outgoing mails and hold them up until I am certain that there all
loopholes have been closed.

Can anyone please let me have some recomendations on the best way  
of

going about this




You might want to look at the clamav port.  If there are examples of  
the things you would be checking for, you can create your own  
signatures for those and clamav will do the monitoring for you.  You  
can configure it to quarantine messages which have the signature for  
manual review.  It won't find anything new, it just does a better job  
of finding things you have seen before.

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Bug in OpenBSD spamd

[Doug Hardie]

There is a bug in OpenBSD's spamd.  The value for the whitelist  
expiration that can be set with the arguments to spamd is not used by  
spamlogd.  It uses the hard-coded value of 36 days in grey.h.  As a  
result if you think you are changing the time a whitelist entry is  
retained, you are actually not.  It will always be 36 days.  The  
easiest way to correct this is to add an argument to spamlogd with the  
desired value and overwrite the default.

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD Port: qpopper-4.0.9_1

[Doug Hardie]

On Oct 16, 2007, at 04:52, Walter Ian Kaye wrote:


Hi,

I tried to [mostly] follow instructions at 
but I don't know if ./configure overrides the port's "Options"  
screen or vice versa, so I don't know if I turned things on or off.


I did

CONFIGURE_ENV=  LIBS="-lcrypt -lmd -lutil -L${LOCALBASE}/lib" \
OS_DEFS="-DSETPROCTITLE ${OS_DEFS}"
--without-gdbm \
--enable-keep-temp-drop \
--disable-update-abort \
--enable-bulletins=/var/spool/bulls \
--enable-log-login \
--enable-new-bulls=3 \
--enable-shy \
--enable-timing \
--enable-log-facility=LOG_MAIL \
--with-openssl=/usr/bin/openssl \
--with-pam=pop3

and then the Options screen

 . 
.
 |   Options for qpopper  
4.0.9_1  |
  
| .. |
 | | [ ] APOP_ONLYbuild with APOP authentication only
| |
 | | [X] APOP build with APOP
| |
 | | [ ] DOCUMENTATIONinstall pdf documentation  
| |
 | | [ ] DRAC build with Dynamic Relay Authorization 
| |
 | | [ ] FULL_POPD_DEBUG  build with more verbose debugging  
| |
 | | [X] PAM  build with PAM authentication  
| |
 | | [ ] POPPASSD build the poppassd daemon  
| |
 | | [X] QPOPAUTH_SETUID  install qpopauth setuid to pop user
| |
 | | [ ] SAMPLE_POPUSERS  build a default reject file
| |
 | | [X] SHY_ENABLED  hide qpopper version in POP3 banner
| |
 | | [X] SSL  build with SSL/TLS support 
| |
 | | [ ] STANDALONE_MODE  build qpopper to be run without inetd  
| |
 | | [X] U_OPTION include support for user .qpopper-options  
| |
 | | 
| |
 | | 
| |
 +-+ 
+-+
 |   [  OK  ]
Cancel|
  
`'


I am trying to set it up so that port 110 requires APOP/AUTH (that  
works) and port 995 allows USER (clear-text-password) via SSL  
(fails; asks for APOP/AUTH, despite 'set' command in config file).


I believe to do what you want will require two instatiations of  
qpopper with different configuration files.  The first one is used on  
port 110 and has APOP enabled.  The second on is on port 995 and has  
APOP disabled.  However, you may also have to have a separate binary  
for the second one that has APOP not compiled in.  I had a difficult  
time getting rid of the APOP messages as we do not use APOP at all.   
I seem to recall that turning it off in the configuration file  
worked, but every connection logged a couple of APOP error messages. 
 
___

freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Clamd core dumps

[Doug Hardie]

I just upgraded a mail server from 9.3 to 11.0-BETA4.  clamav worked fine on 
9.3.  However, after upgrading it and reinstalling the package clamd core dumps 
just after reading all the signatures.  Ktrace shows nothing other than the sig 
11.  I then built clamav from ports so I would have source.  The bt from the 
core dump shows:

#0  0x000800f94b09 in cli_printcxxver () from /usr/local/lib/libclamav.so.7
#1  0x0008010e7d2b in cli_printcxxver () from /usr/local/lib/libclamav.so.7
#2  0x000800d3eee9 in cli_printcxxver () from /usr/local/lib/libclamav.so.7
#3  0x000800d5ebd3 in cli_printcxxver () from /usr/local/lib/libclamav.so.7
#4  0x000800d5e256 in cli_printcxxver () from /usr/local/lib/libclamav.so.7
#5  0x000800d5df16 in cli_printcxxver () from /usr/local/lib/libclamav.so.7
#6  0x000800d03283 in cli_printcxxver () from /usr/local/lib/libclamav.so.7
#7  0x000800d034a4 in cli_printcxxver () from /usr/local/lib/libclamav.so.7
#8  0x000800c118d0 in cli_pcre_scanbuf () from /usr/local/lib/libclamav.so.7
#9  0x000800b675e8 in cli_bytecode_prepare2 () from 
/usr/local/lib/libclamav.so.7
#10 0x000800aba3b9 in cl_engine_compile () from 
/usr/local/lib/libclamav.so.7
#11 0x00408fec in main ()

I am going to try rebuilding with symbols.

Any ideas what is causing this or how to get around it?

pkg is clamav-milter-0.99.2

— Doug

___
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: [exp - 103i386-default-build-as-user][mail/qpopper] Failed for qpopper-4.1.0_5 in package

[Doug Hardie]

I can't reproduce this problem.  The GUIDE.pdf file is built properly in 
/usr/local/share/doc/qpopper.  I am at a loss as to what to do about this.


> Begin forwarded message:
> 
> From: pkg-fall...@freebsd.org 
> Subject: [exp - 103i386-default-build-as-user][mail/qpopper] Failed for 
> qpopper-4.1.0_5 in package
> Date: October 25, 2016 at 11:16:16 PDT
> To: bc...@lafn.org 
> Cc: pkg-fall...@freebsd.org 
> 
> You are receiving this mail as a port that you maintain
> is failing to build on the FreeBSD package build server.
> Please investigate the failure and submit a PR to fix
> build.
> 
> Maintainer: bc...@lafn.org 
> Last committer: m...@freebsd.org 
> Ident:  $FreeBSD: head/mail/qpopper/Makefile 424560 2016-10-24 
> 10:18:50Z mat $
> Log URL:
> http://package19.nyi.freebsd.org/data/103i386-default-build-as-user/424593/logs/qpopper-4.1.0_5.log
>  
> 
> Build URL:  
> http://package19.nyi.freebsd.org/build.html?mastername=103i386-default-build-as-user&build=424593
>  
> 
> Log:
> 
> >> Building mail/qpopper
> build started at Tue Oct 25 18:15:43 UTC 2016
> port directory: /usr/ports/mail/qpopper
> building for: FreeBSD 103i386-default-build-as-user-job-24 10.3-RELEASE-p10 
> FreeBSD 10.3-RELEASE-p10 i386
> maintained by: bc...@lafn.org 
> Makefile ident:  $FreeBSD: head/mail/qpopper/Makefile 424560 2016-10-24 
> 10:18:50Z mat $
> Poudriere version: 3.1.14
> Host OSVERSION: 125
> Jail OSVERSION: 1003000
> 
> ---Begin Environment---
> SHELL=/bin/csh
> UNAME_p=i386
> UNAME_m=i386
> UNAME_v=FreeBSD 10.3-RELEASE-p10
> UNAME_r=10.3-RELEASE-p10
> BLOCKSIZE=K
> MAIL=/var/mail/root
> STATUS=1
> OPSYS=FreeBSD
> ARCH=i386
> SAVED_TERM=
> MASTERMNT=/poudriere/data/.m/103i386-default-build-as-user/ref
> FORCE_PACKAGE=yes
> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
> _JAVA_VERSION_LIST_REGEXP=1.6\|1.7\|1.8\|1.6+\|1.7+\|1.8+
> POUDRIERE_BUILD_TYPE=bulk
> PKGNAME=qpopper-4.1.0_5
> OSREL=10.3
> _OSRELEASE=10.3-RELEASE-p10
> PYTHONBASE=/usr/local
> OLDPWD=/
> _SMP_CPUS=32
> PWD=/poudriere/data/.m/103i386-default-build-as-user/ref/.p/pool
> MASTERNAME=103i386-default-build-as-user
> SCRIPTPREFIX=/usr/local/share/poudriere
> _JAVA_VENDOR_LIST_REGEXP=openjdk\|oracle\|sun
> USER=root
> HOME=/root
> POUDRIERE_VERSION=3.1.14
> SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
> CONFIGURE_MAX_CMD_LEN=262144
> LIBEXECPREFIX=/usr/local/libexec/poudriere
> LOCALBASE=/usr/local
> PACKAGE_BUILDING=yes
> _JAVA_OS_LIST_REGEXP=native\|linux
> OSVERSION=1003000
> ---End Environment---
> 
> ---Begin OPTIONS List---
> ===> The following configuration options are available for qpopper-4.1.0_5:
> APOP=on: build with APOP
> APOP_ONLY=off: build with APOP authentication only
> DOCUMENTATION=off: install pdf documentation
> DRAC=off: build with Dynamic Relay Authorization
> FULL_POPD_DEBUG=off: build with more verbose debugging
> PAM=off: build with PAM authentication
> POPPASSD=off: build the poppassd daemon
> SAMPLE_POPUSERS=off: build a default reject file
> SHY_ENABLED=off: hide qpopper version in POP3 banner
> SSL=on: build with SSL/TLS support
> STANDALONE_MODE=off: build qpopper to be run without inetd
> U_OPTION=on: include support for user .qpopper-options
> ===> Use 'make config' to modify these settings
> ---End OPTIONS List---
> 
> --CONFIGURE_ARGS--
> --enable-nonauth-file=/usr/local/etc/qpopper/popusers  --without-gdbm  
> --enable-keep-temp-drop --enable-apop=/usr/local/etc/qpopper/pop.auth  
> --with-popuid=pop --with-openssl=/usr --prefix=/usr/local 
> ${_LATE_CONFIGURE_ARGS}
> --End CONFIGURE_ARGS--
> 
> --CONFIGURE_ENV--
> OS_DEFS="-DSETPROCTITLE " XDG_DATA_HOME=/wrkdirs/usr/ports/mail/qpopper/work  
> XDG_CONFIG_HOME=/wrkdirs/usr/ports/mail/qpopper/work  
> HOME=/wrkdirs/usr/ports/mail/qpopper/work TMPDIR="/tmp" SHELL=/bin/sh 
> CONFIG_SHELL=/bin/sh  AUTOCONF=/usr/local/bin/autoconf-2.69  
> AUTOCONF_DIR=/usr/local/share/autoconf-2.69  
> AUTOHEADER=/usr/local/bin/autoheader-2.69  
> AUTOIFNAMES=/usr/local/bin/ifnames-2.69  
> AUTOM4TE=/usr/local/bin/autom4te-2.69  
> AUTORECONF=/usr/local/bin/autoreconf-2.69  
> AUTOSCAN=/usr/local/bin/autoscan-2.69  
> AUTOUPDATE=/usr/local/bin/autoupdate-2.69  AUTOCONF_VERSION=2.69 
> CONFIG_SITE=/usr/ports/Templates/config.site lt_cv_sys_max_cmd_len=262144
> --End CONFIGURE_ENV--
> 
> --MAKE_ENV--
> OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include 
> OPENSSLLIB=/usr/lib XDG_DATA_HOME=/wrkdirs/usr/ports/mail/qpopper/work  
> XDG_CONFIG_HOME=/wrkdirs/usr/ports/mail/qpopper/work  
> HOME=/wrkdirs/usr/

Re: Of LSOF

[Doug Hardie]

> On 27 December 2017, at 13:26, Dave Horsfall  wrote:
> 
> On Tue, 26 Dec 2017, Kevin Oberman wrote:
> 
>> [...] Putting header files into the port is a non-starter as they MUST match 
>> the kernel on which lsof is built. I added lsof to PORTS_MODULES so it is 
>> rebuilt with any new kernel on my stable system and on one release system so 
>> I can use that package to install elsewhere rather then use the repo package.
> 
> Good point; thanks.  "lsof" is a superb tool, BTW...
> 
>> Now that 10.3 is EOL I would expect that the package built for 10-STABLE 
>> would be built on 10.4-RELEASE, but I don't know for sure. It should be and 
>> the next quarterly should be 10.4 based, too.
> 
> OK.
> 
> The history is that I used to build from ports because the then-boss did, and 
> I didn't even know about pre-built packages.  Then, one day, Ruby needed to 
> be rebuilt, which promptly blew away /tmp i.e. swap...  I'm a big fan of 
> TMPFS; I had it on the old BSDi box (where it was "mfs"), and even my old 
> CP/M box (where it was "M:").

Why not add losf to the base?  Its a useful tool like ping, traceroute etc.

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

Re: Of LSOF

[Doug Hardie]

> On 27 December 2017, at 16:05, Kevin Oberman  wrote:
> 
> On Wed, Dec 27, 2017 at 3:47 PM, Doug Hardie  wrote:
> > On 27 December 2017, at 13:26, Dave Horsfall  wrote:
> >
> > On Tue, 26 Dec 2017, Kevin Oberman wrote:
> >
> >> [...] Putting header files into the port is a non-starter as they MUST 
> >> match the kernel on which lsof is built. I added lsof to PORTS_MODULES so 
> >> it is rebuilt with any new kernel on my stable system and on one release 
> >> system so I can use that package to install elsewhere rather then use the 
> >> repo package.
> >
> > Good point; thanks.  "lsof" is a superb tool, BTW...
> >
> >> Now that 10.3 is EOL I would expect that the package built for 10-STABLE 
> >> would be built on 10.4-RELEASE, but I don't know for sure. It should be 
> >> and the next quarterly should be 10.4 based, too.
> >
> > OK.
> >
> > The history is that I used to build from ports because the then-boss did, 
> > and I didn't even know about pre-built packages.  Then, one day, Ruby 
> > needed to be rebuilt, which promptly blew away /tmp i.e. swap...  I'm a big 
> > fan of TMPFS; I had it on the old BSDi box (where it was "mfs"), and even 
> > my old CP/M box (where it was "M:").
> 
> Why not add losf to the base?  Its a useful tool like ping, traceroute etc.
> 
> While I can't say the exact reason, though I'd guess that it might be a 
> licensing issue, though the license is very similar to a BSD license. Another 
> possible issue is that lsof is frequently updated and that would mean that 
> the version in FreeBSD base would get fairly old before EOL.
> 
> fstat(1) does much of what lsof does.  
> 

I can't speak to the licensing issue as I have never looked into that.  
However, the frequently updated issue doesn't seem to be an issue for openssl.  
The base version is sometimes old, and the port versions are newer.  At least 
lsof would be a working version for those who only use packages.  If you need 
the newer features, then you would need to install the port.


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

Qpopper and openssl on FreeBSD 11.x

[Doug Hardie]

I have encountered an interesting situation while trying to resolve a PR on 
qpopper.  I am unable to build qpopper on 11.1 (and probably 11.0) because the 
openssl function SSLv3_server_method has been removed.  I can see where the 
SSLv2 functions are disabled in ssl.h, but the SSLv3 functions appear that they 
should be there.  nm on libssl shows they are there.  Clang's linker can't link 
to them.  One of the qpopper users' indicates that the problem does not exist 
on 10.4.  I believe the loss of the SSLv3 methods is a bug and have filed Bug 
report.

Resolution of that PR will obviously take some time.  The question at hand is 
what to do in the meantime. I am guessing the packages must be built on 10.x or 
there would be a report of the problem.  I can easily change the code, via a 
patch, to use SSLv23_server_method in all cases, or the preferred 
TLSv1_server_method.  That will eliminate the options to restrict qpopper to 
SSLv2 or SSLv3.  This does not appear to be an issue for those running 11.x.  
However, it is for those using 10.x and earlier.  Given the security issues 
today, I can't imagine anyone wanting to use those options, but it is possible 
someone is using them.  Switching to the TLSv1_server_method will remove that 
capability for them.  

-- Doug

___
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: Qpopper and openssl on FreeBSD 11.x

[Doug Hardie]

> On 23 March 2018, at 02:40, Matthias Andree  wrote:
> 
> Am 17.02.2018 um 04:22 schrieb Doug Hardie:
>> I have encountered an interesting situation while trying to resolve a PR on 
>> qpopper.  I am unable to build qpopper on 11.1 (and probably 11.0) because 
>> the openssl function SSLv3_server_method has been removed.  I can see where 
>> the SSLv2 functions are disabled in ssl.h, but the SSLv3 functions appear 
>> that they should be there.  nm on libssl shows they are there.  Clang's 
>> linker can't link to them.  One of the qpopper users' indicates that the 
>> problem does not exist on 10.4.  I believe the loss of the SSLv3 methods is 
>> a bug and have filed Bug report.
> 
> It is a deliberate security measure to remove SSLv3 methods, and not a
> bug. The protocol is broken.

Granted those protocols are broken, but removing the calls to disable them 
means that for systems that still support them, you have no real option to 
disable them.  Its like you are pretending they never existed.  However, they 
still do in 10.x which is still supported.

> 
>> Resolution of that PR will obviously take some time.  The question at hand 
>> is what to do in the meantime. I am guessing the packages must be built on 
>> 10.x or there would be a report of the problem.  I can easily change the 
>> code, via a patch, to use SSLv23_server_method in all cases, or the 
>> preferred TLSv1_server_method.  That will eliminate the options to restrict 
>> qpopper to SSLv2 or SSLv3.  This does not appear to be an issue for those 
>> running 11.x.  However, it is for those using 10.x and earlier.  Given the 
>> security issues today, I can't imagine anyone wanting to use those options, 
>> but it is possible someone is using them.  Switching to the 
>> TLSv1_server_method will remove that capability for them.  
> 
> Use SSLv23_server_method(), and use code to block out SSLv2 + SSLv3 on
> those systems that still support them - which depends on the
> OpenSSL/LibreSSL version, however:
> Older OpenSSL and LibreSSL require SSL_OP_NO_SSLv3 and SSL_OP_NO_SSLv2
> set through ..._set_options() on the SSL or CTX,
> newer OpenSSL (1.1.0+) have ..._set_min_proto_version(..., TLS1_VERSION).

The simple approach for 11 is to use SSLv23_server_method() as it handles 
everything and no extra calls are required.  However, that doesn't work for 
10.x  Adding in all the checks you mention is a lot of development and testing 
effort.  I don't have the resources or desire to do all that.  I have not found 
a hardware system that will run 10.x.  Everything I have runs 11 just fine...

-- Doug

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

portconf port

[Doug Hardie]

I have been trying to figure out how to configure portconf.  The 3  
examples given are not much help with complex ports.  I am starting  
with the dspam port (mail/dspam) as if I can figure that one out the  
rest should be easy.  I first tried to use the arguments from the  
configure command:


mail/dspam: CONFIGURE_ARGS=--with-logdir=/var/log/dspam \
--with-dspam-home=/var/db/dspam \
--with-dspam-home-owner=root \
--with-dspam-home-group=mail  \
--with-dspam-home-mode=0770 \
--with-dspam-owner=root \
--with-dspam-group=mail \
--enable-homedir \
--with-storage-driver=hash_drv \
--with-delivery-agent=/usr/sbin/sendmail \
--with-dspam-mode=4511 \
--prefix=/usr/local

That still brought up the options selection menu.  Hitting cancel on  
that caused the port to start to build, but it still tried to  
download mysql 5.0 which I don't want.  The above configure command  
is how I normall build dspam - in the dspam directory.


Then I tried to select the options from Makefile entering the options  
I wanted (haven't figured out how to sent the drectories though):


mail/dspam:  WITH SYSLOG | DEBUG | HASH USER_HOMEDIR | SENDMAIL |  
SENDMAIL_LDA


That skips the options selection menu fine, but still tries to  
download mysql 5.0 which I don't want.  I then tried to add the  
WITHOUT options:


mail/dspam:  WITH SYSLOG | DEBUG | HASH USER_HOMEDIR | SENDMAIL |  
SENDMAIL_LDA WITHOUT DAEMON | MYSQL50 | POSTGRESQL | SQLITE3


Same results.  What am I doing wrong?


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Qpopper Port

[Doug Hardie]

I am going to have to give up maintaining qpopper.  Not because I don't have 
the interest or time, but because I simply cannot update any port.  The old 
port system may have had issues, but it worked!!!  The new one does not.  I am 
completely unable to upgrade or install any ports on a 9.1 or higher system.  I 
have a number of those in production and will have to now resort to obtaining 
ports from the original sources and making them work on my systems.  Its a 
colossal pain in the *&^*&^.

I tried portmaster qpopper to get the latest source.  That failed with lots of 
errors in other ports.  Too many to try to do individually.  I then used 
pkg_delete to delete all ports.  Repeated portmaster qpopper.  Portmaster no 
longer exists.  Tried pkg_add -r portmaster.  Message to setsomething in 
/etc/make.conf.  Did that and then tried to run pkg2ng as it requested.  pkg2ng 
does not exist.  Its not a port either.  Dead end.  Went to 
/usr/ports/port-mgmt/portmaster and did a make.  Get errors that file names are 
misspelled.

Perhaps the new port system can be used by those who spend their day using it, 
but for those of us who have real work to do and only use it when needed, its 
just not viable.
___
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"

Upgrading a Port on 8.2

[Doug Hardie]

I have an older, but basically clean, install of 8.2 on a production system.  
It has a few ports that were installed back when 8.2 was new.  However, I need 
to add pdftk.  Pkg_add did that nicely.  HOwever, it added version 1.44.  The 
history for pdftk shows that a major problem was fixed in 1.45 and I am 
encountering that problem and need to upgrade.  Portupgrade pdftk does nothing. 
 It seems to decide that the latest version is 1.44.  However, on a 9.2 system, 
I get a much higher version number.  Is there any way to determine if 1.44 is 
the latest version that will run with 8.2 or is there another way I need to 
upgrade to ports files?  Its my understanding that cvsup is no longer with us.

-- Doug

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

Re: Upgrading a Port on 8.2

[Doug Hardie]

On 17 February 2014, at 21:43, Erich Dollansky  
wrote:

> Hi,
> 
> On Mon, 17 Feb 2014 21:07:43 -0800
> Doug Hardie  wrote:
> 
>> I have an older, but basically clean, install of 8.2 on a production
>> system.  It has a few ports that were installed back when 8.2 was
>> new.  However, I need to add pdftk.  Pkg_add did that nicely.
>> HOwever, it added version 1.44.  The history for pdftk shows that a
>> major problem was fixed in 1.45 and I am encountering that problem
>> and need to upgrade.  Portupgrade pdftk does nothing.  It seems to
>> decide that the latest version is 1.44.  However, on a 9.2 system, I
>> get a much higher version number.  Is there any way to determine if
>> 1.44 is the latest version that will run with 8.2 or is there another
>> way I need to upgrade to ports files?  Its my understanding that
>> cvsup is no longer with us.
> 
> how I understand your problem, the behaviour of the machine is normal
> as you kept the old ports tree.
> 
> If you would like to have a newer version of a port, you would have to
> update the ports tree first. The big but is then that you will have to
> update all installed ports too and then install the program you need.
> 
> If you have real bad luck, this could force you even to upgrade from
> 8.2 to 8.4. So, be careful.

Thats what I expected, but the question remains:  how?  Cvsup I believe is no 
longer with us and purtupgrade apparently doesn't do that either.
___
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"