Newbie maintainer, question regarding patches

[Michael Gmelin]

Hi,

I recently took over maintainership of the devel/ice port and trying to get 
familiar with the dos and don'ts of porting. In the past I contributed only by 
sending PRs, which would have been approved by the maintainer. Since I'm the 
maintainer now, will I still open normal PRs, which will then be taken by the 
committer? The Porter's Handbook seems a little bit thin on this (or I'm unable 
to distill .

Also I have an additional question regarding how to patch - as far as I 
understand, usually there should be one patch per patched file. I have the 
following situation changing the port:

a) I created a massive patch that enables the port to compile using modern 
compilers (gcc >= 4.7 and clang >= 3.0). Since this patch touches many files I 
was wondering if it wouldn't be better to keep this in one patch file instead 
of creating 20+ patch files which then have very little coherence (this patch 
fixes the same things in all files, as devel/ice violates the C++ standard in 
many places)

b) I also have another massive patch which touches another 20 files which 
enables some new security features in ice (the history of this patch is that I 
developed it at first and submitted it to the vendor, who refined it and sent 
it back to me). I might want to make this patch optional as well (using a 
dialog style menu to enable it). In this case it also seems like it would be 
better not to split the patch up to all that many sources, but keep it as one 
feature that's contained in one patch.

Especially when combining a) and b) (which both touch some of the same files 
and therefore will get more or less interleaved) it seems problematic (yet 
possible) to split them into many separate files.

So the general question is:
Is "one patch per file" a golden rule or are there exceptions in cases where 
one logical patch touches dozens of files?

Thanks,
Michael

___
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: Newbie maintainer, question regarding patches

[Michael Gmelin]

On Feb 24, 2012, at 14:55, Eitan Adler wrote:

> On Fri, Feb 24, 2012 at 7:39 AM, Michael Gmelin  wrote:
>> b) I also have another massive patch which touches another 20 files which 
>> enables some new security features in ice (the history of this patch is that 
>> I developed it at first and submitted it to the vendor, who refined it and 
>> sent it back to me). I might want to make this patch optional as well (using 
>> a dialog style menu to enable it). In this case it also seems like it would 
>> be better not to split the patch up to all that many sources, but keep it as 
>> one feature that's contained in one patch.
> 
> Just replying to this question: The ports tree is not meant for
> software development. I would much rather you try to get the patch
> into the upstream source than keep it as an optional patch in the
> ports tree.
In general I agree with your reasoning. The feature I'm talking about has been 
approved and will be in the next version (this happened almost half a year 
ago). Unfortunately Ice has a slow release cycle, as it is dual licensed 
(GPLv2+commercial). The next release of Ice is quite a while away and will 
probably a major release, as they only create releases that are also 
commercially supported. The vendor doesn't provide any source repository access 
or anything else that could be used to track new features or patches, they only 
get announced in the forums. So as a heavy user of this software package I 
would like to have access to these vendor approved and backwards compatible 
optional features without working outside of the ports tree. To a certain 
degree this is comparable to other ports that pull in optional features through 
patches (djbdns, qmail, nginx, php, etc.).

Alternatively an devel/ice-devel port could be created, that brings in more of 
these new features, but that would of course create more overhead - I could 
also host these feature patches outside of ports (as PATCHFILES) or create a 
forked project to track them, but all of this seems a little bit like over 
engineering, given the fact that the changes are fairly minimal (even though 
they're touching many files).

Michael

> 
> 
> 
> -- 
> Eitan Adler

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

Problems submitting patch containing UTF-8 characters

[Michael Gmelin]

Hi,

I recently ran into a problem submitting a PR containing UTF-8
characters, they ended up garbled, so the maintainer couldn't apply the
patch cleanly.

http://www.freebsd.org/cgi/query-pr.cgi?pr=171645

The characters included were 0xe4 0xb8 0xad and 0xe5 0x9b 0xbd (two
three byte characters). The code affected is about testing utf-8, so
the characters are required. And even if not, patching them away would
require stating them as part of the patch.

The original e-mail was created using porttools and therefore had no
character set specification, which usually shouldn't be a problem. The
patch was just inline as part of the body.

http://www.freebsd.org/cgi/query-pr.cgi?pr=171645&getpatch=1

The character sequence had been recoded to
0xc3 0xa4 0xc2 0xb8 0xc2 0xad 0xc3 0xa5 0xc2 0x9b 0xc2 0xbd

It seems like it had been interpreted as latin1 on receipt and then
reencoded as utf-8:
0xe4 => 0xc3 0xa4
0xb8 => 0xc2 0xb8
0xad => 0xc2 0xad
0xe5 => 0xc3 0xa5
0x9b => 0xc2 0x9b
0xbd => 0xc2 0xbd

Which is obviously not what should happen. The recipient shouldn't make
any assumptions about the character set used.

The next attempt was sending the patch as a bug-followup through a
graphical MUA. The patch was attached and had been encoded as
quoted-printable (no specific charset specification):

+-configPath =3D u"./config/=E4=B8=AD=E5=9B=BD_client.config"
++configPath =3D
u"./config/=E4=B8=AD=E5=9B=BD_client.config".encode("utf-8=")

http://www.freebsd.org/cgi/query-pr.cgi?pr=171645&getpatch=2

Unfortunately the results are the same. I did not try forcing a charset
by manually modifying the email (not sure if this will work, I'm
willing to test, but I don't want to further litter that PR).

At this point I figured, that sending the patch in gzipped format might
help. Said and done, the patch shows up as base64 in the PR. When
copy and pasting and decoding the base64 text, the resulting .gz can be
decompressed correctly and the content is what I expected. When
clicking the download link though:

http://www.freebsd.org/cgi/query-pr.cgi?pr=171645&getpatch=3

The resulting .gz file has the correct file size, but is corrupted.
Checking it using the hex editor it looks like it has been reencoded as
utf-8 (and then truncated at the expected file size):

Hex of the original file (first 16 bytes):
1f 8b 08 08 ad 79 65 50  00 03 70 79 32 37 2d 49

Hex of the file downloaded by using the link:
1f c2 8b 08 08 c2 ad 79  65 50 00 03 70 79 32 37

As you can see, all non 7bit characters have been utf-8 encoded, which
is pretty suboptimal in a binary file.

0x8b => 0xc2 0x8b
0xad => 0xc2 0xad
...

As a result the truncated and utf-8 encoded gzip file cannot be
decompressed.

I'm relatively certain that this has worked at some point in the past.

Ideas anyone?

Thanks,

-- 
Michael Gmelin
___
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: Problems submitting patch containing UTF-8 characters

[Michael Gmelin]

On Sun, 30 Sep 2012 05:08:03 +0200
Michael Gmelin  wrote:

> Hi,
> 
> I recently ran into a problem submitting a PR containing UTF-8
> characters, they ended up garbled, so the maintainer couldn't apply
> the patch cleanly.
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=171645
> 
> The characters included were 0xe4 0xb8 0xad and 0xe5 0x9b 0xbd (two
> three byte characters). The code affected is about testing utf-8, so
> the characters are required. And even if not, patching them away would
> require stating them as part of the patch.
> 
> The original e-mail was created using porttools and therefore had no
> character set specification, which usually shouldn't be a problem. The
> patch was just inline as part of the body.
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=171645&getpatch=1
> 
> The character sequence had been recoded to
> 0xc3 0xa4 0xc2 0xb8 0xc2 0xad 0xc3 0xa5 0xc2 0x9b 0xc2 0xbd
> 
> It seems like it had been interpreted as latin1 on receipt and then
> reencoded as utf-8:
> 0xe4 => 0xc3 0xa4
> 0xb8 => 0xc2 0xb8
> 0xad => 0xc2 0xad
> 0xe5 => 0xc3 0xa5
> 0x9b => 0xc2 0x9b
> 0xbd => 0xc2 0xbd
> 
> Which is obviously not what should happen. The recipient shouldn't
> make any assumptions about the character set used.
> 
> The next attempt was sending the patch as a bug-followup through a
> graphical MUA. The patch was attached and had been encoded as
> quoted-printable (no specific charset specification):
> 
> +-configPath =3D u"./config/=E4=B8=AD=E5=9B=BD_client.config"
> ++configPath =3D
> u"./config/=E4=B8=AD=E5=9B=BD_client.config".encode("utf-8=")
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=171645&getpatch=2
> 
> Unfortunately the results are the same. I did not try forcing a
> charset by manually modifying the email (not sure if this will work,
> I'm willing to test, but I don't want to further litter that PR).
> 
> At this point I figured, that sending the patch in gzipped format
> might help. Said and done, the patch shows up as base64 in the PR.
> When copy and pasting and decoding the base64 text, the resulting .gz
> can be decompressed correctly and the content is what I expected. When
> clicking the download link though:
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=171645&getpatch=3
> 
> The resulting .gz file has the correct file size, but is corrupted.
> Checking it using the hex editor it looks like it has been reencoded
> as utf-8 (and then truncated at the expected file size):
> 
> Hex of the original file (first 16 bytes):
> 1f 8b 08 08 ad 79 65 50  00 03 70 79 32 37 2d 49
> 
> Hex of the file downloaded by using the link:
> 1f c2 8b 08 08 c2 ad 79  65 50 00 03 70 79 32 37
> 
> As you can see, all non 7bit characters have been utf-8 encoded, which
> is pretty suboptimal in a binary file.
> 
> 0x8b => 0xc2 0x8b
> 0xad => 0xc2 0xad
> ...
> 
> As a result the truncated and utf-8 encoded gzip file cannot be
> decompressed.
> 
> I'm relatively certain that this has worked at some point in the past.
> 
> Ideas anyone?
> 
> Thanks,
> 

By the way, the two three byte sequences mean
"China", see also http://goo.gl/4muUF

-- 
Michael Gmelin
___
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: Problems submitting patch containing UTF-8 characters

[Michael Gmelin]

On 30 Sep 2012, at 16:19, Shaun Amott  wrote:

> On Sun, Sep 30, 2012 at 05:08:03AM +0200, Michael Gmelin wrote:
>> I recently ran into a problem submitting a PR containing UTF-8
>> characters, they ended up garbled, so the maintainer couldn't apply the
>> patch cleanly.
> 
> GNATS, unfortunately, records no information about character encoding.
> To make matters worse, it actually removes many headers from e-mail
> replies, meaning query-pr.cgi can usually only work on guesses and
> assumptions.
> 
> Headers are however preserved inside MIME parts, and if there are any of
> these headers, they are used; but in this case your MUA hasn't included
> encoding information here.
> 
> Shaun
> 
> -- 
> Shaun Amott // PGP: 0x6B387A9A
> "A foolish consistency is the hobgoblin
> of little minds." - Ralph Waldo Emerson

The question remains though, why is it trying to re-encode characters as UTF8 
when it just received what should be 8bit ASCII to it (passing it through 
transparently should work)? Especially in case of a binary attachment (which it 
shows correctly in base64 encoded form but tries to UTF-8 encode on download). 
To me this looks like a (web server?) configuration 
issue.___
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: Problems submitting patch containing UTF-8 characters

[Michael Gmelin]

On Sun, 30 Sep 2012 16:33:15 +0200
Michael Gmelin  wrote:

> 
> 
> On 30 Sep 2012, at 16:19, Shaun Amott  wrote:
> 
> > On Sun, Sep 30, 2012 at 05:08:03AM +0200, Michael Gmelin wrote:
> >> I recently ran into a problem submitting a PR containing UTF-8
> >> characters, they ended up garbled, so the maintainer couldn't
> >> apply the patch cleanly.
> > 
> > GNATS, unfortunately, records no information about character
> > encoding. To make matters worse, it actually removes many headers
> > from e-mail replies, meaning query-pr.cgi can usually only work on
> > guesses and assumptions.
> > 
> > Headers are however preserved inside MIME parts, and if there are
> > any of these headers, they are used; but in this case your MUA
> > hasn't included encoding information here.
> > 
> > Shaun
> > 
> > -- 
> > Shaun Amott // PGP: 0x6B387A9A
> > "A foolish consistency is the hobgoblin
> > of little minds." - Ralph Waldo Emerson
> 
> ...
>

I tries setting the character encoding of the attachment, which fixes
the problem only for viewing the patch on the PR website (so one could
copy and paste the patch). The download links will still deliver
a corrupted patch though, so basically it is impossible to submit a
patch containing UTF-8 characters that can be downloaded from the PR
website correctly*.

I created a bug describing/demonstrating the issue, maybe a member of
portmgr or www could check this.

http://www.freebsd.org/cgi/query-pr.cgi?pr=172195

Michael

* unless one encodes it into a special ASCII format
like base64 and attaches this as text/plain us ascii and of course
tells people how to use it - this is neither practical nor desirable
since it makes it impossible to discuss a patch by just looking at it
on the website.

-- 
Michael Gmelin
___
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: sudo-1.8.6.p3_1 is broken on ia64 -current. What svn revision do I need to get back to sudo-1.8.5.p3

[Michael Gmelin]

On Tue, 2 Oct 2012 12:30:26 +0100 (BST)
Anton Shterenlikht  wrote:

> 
> I updated from sudo-1.8.5.p3 to sudo-1.8.6.p3_1
> on ia64 r235474. The new version segfaults all
> the time. I'm in a hurry to get a working sudo
> back, because it's required for the portscluster
> builds. Please advise what svn revision I need
> to go back to get to sudo-1.8.5p3.
> 
> Thanks
> 
> Anton
> ___
> 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"

Rev 302692

See also
http://www.freebsd.org/cgi/cvsweb.cgi/ports/security/sudo/Makefile


-- 
Michael Gmelin
___
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 to check out ports

[Michael Gmelin]

On Tue, 02 Oct 2012 14:14:26 -0500
Paul Schmehl  wrote:

> --On October 2, 2012 2:44:46 PM -0400 Eitan Adler
>  wrote:
> > On 2 October 2012 14:37, Paul Schmehl 
> > wrote:
> >> I obviously wasn't very clear.  I'm a port maintainer.  I need to
> >> update one of my ports.  I used to do this by checking out the
> >> port into a purpose-created directory in which I would use cvs to
> >> make changes and test. After everything checked out, I would
> >> submit the diff.
> >
> > We need to be better about announcing these changes as not to
> > frustrate maintainers. :)
> >
> >> Now cvs isn't working, so how, as a port maintainer, do I check
> >> out a single port so I can update it and submit it in a PR?
> >
> > You should do things the same way you did before, but instead you
> > should use svn to checkout out your port. Note that 'module names'
> > no longer work so you must use the full name:
> > e..g., svn checkout svn://svn.freebsd.org/ports/head/editors/nano
> >
> > It may help to keep a folder of "ports-I-maintain" with the ports
> > you maintain checked out. Before you update them do "svn update *"
> > and to generate a diff do "svn diff foldername"
> I got on the wiki and figured out how to check ou the port using svn,
> but now I'm stuck again.  This port has moved to github, and I don't
> have a clue how to download it in the Makefile.  There's no mention
> of github in /usr/ports/Mk, so I assume the method hasn't even been
> written yet. The source is here:
> <https://github.com/firnsy/barnyard2/>, but I don't see a tarball,
> and I don't know enough about ports to know if it's even possible to
> fetch it from github.

Hi Paul,

What about using the ZIP

https://github.com/firnsy/barnyard2/zipball/master

(this will give you the current master branch in a ZIP file)

or a tarball

https://github.com/firnsy/barnyard2/tarball/master

If you want to keep things more stable (since the master branch might
change frequently and break your build), limit yourself to a specific
version. Fortunately this software is using tags for versioning, so
it's easy to get zips from github, e.g.:

https://github.com/firnsy/barnyard2/zipball/v2-1.10

or if you prefer a tarball (which is usually nicer to have)

https://github.com/firnsy/barnyard2/tarball/v2-1.10

Github provides tarballs (and zipballs) for all branches and tags.

See also:

https://github.com/blog/12-tarball-downloads

Hope that helps

-- 
Michael Gmelin
___
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 to check out ports

[Michael Gmelin]

On Tue, 02 Oct 2012 21:54:31 -0500
Paul Schmehl  wrote:

> --On October 2, 2012 11:28:12 PM +0200 Michael Gmelin
>  wrote:
> 
> >
> >
> > On Tue, 02 Oct 2012 14:14:26 -0500
> > Paul Schmehl  wrote:
> >
> >> --On October 2, 2012 2:44:46 PM -0400 Eitan Adler
> >>  wrote:
> >> > On 2 October 2012 14:37, Paul Schmehl 
> >> > wrote:
> >> >> I obviously wasn't very clear.  I'm a port maintainer.  I need
> >> >> to update one of my ports.  I used to do this by checking out
> >> >> the port into a purpose-created directory in which I would use
> >> >> cvs to make changes and test. After everything checked out, I
> >> >> would submit the diff.
> >> >
> >> > We need to be better about announcing these changes as not to
> >> > frustrate maintainers. :)
> >> >
> >> >> Now cvs isn't working, so how, as a port maintainer, do I check
> >> >> out a single port so I can update it and submit it in a PR?
> >> >
> >> > You should do things the same way you did before, but instead you
> >> > should use svn to checkout out your port. Note that 'module
> >> > names' no longer work so you must use the full name:
> >> > e..g., svn checkout svn://svn.freebsd.org/ports/head/editors/nano
> >> >
> >> > It may help to keep a folder of "ports-I-maintain" with the ports
> >> > you maintain checked out. Before you update them do "svn update
> >> > *" and to generate a diff do "svn diff foldername"
> >> I got on the wiki and figured out how to check ou the port using
> >> svn, but now I'm stuck again.  This port has moved to github, and
> >> I don't have a clue how to download it in the Makefile.  There's
> >> no mention of github in /usr/ports/Mk, so I assume the method
> >> hasn't even been written yet. The source is here:
> >> <https://github.com/firnsy/barnyard2/>, but I don't see a tarball,
> >> and I don't know enough about ports to know if it's even possible
> >> to fetch it from github.
> >
> > Hi Paul,
> >
> > What about using the ZIP
> >
> > https://github.com/firnsy/barnyard2/zipball/master
> >
> > (this will give you the current master branch in a ZIP file)
> >
> > or a tarball
> >
> > https://github.com/firnsy/barnyard2/tarball/master
> >
> > If you want to keep things more stable (since the master branch
> > might change frequently and break your build), limit yourself to a
> > specific version. Fortunately this software is using tags for
> > versioning, so it's easy to get zips from github, e.g.:
> >
> > https://github.com/firnsy/barnyard2/zipball/v2-1.10
> >
> > or if you prefer a tarball (which is usually nicer to have)
> >
> > https://github.com/firnsy/barnyard2/tarball/v2-1.10
> >
> > Github provides tarballs (and zipballs) for all branches and tags.
> >
> > See also:
> >
> > https://github.com/blog/12-tarball-downloads
> >
> > Hope that helps
> 
> How do I handle this?
> 
> firnsy-barnyard2-v2-1.10-0-g2f5d496.tar.gz
> 
> Is the string at the end (g2f5d496) auto-generated?  If so, that's
> another problem.
> 
> I guess something like this?  Sheesh.  What a PITA.
> 
> PORTNAME=   barnyard2-v2
> PORTVERSION=1.10
> PKGNAMEPREFIX=  firnsy-
> PKGNAMESUFFIX=  -0-g2f5d496
> 

The file name is the result of the command "git describe" and is
therefore stable. It consists of three parts:

tag - number of commits - commit hash

This project uses tags for versioning (which makes sense), so this file
name tells you that you're dealing with version v2-1.10, there have
been no commits to the tree since this version (it's unaltered) and the
commit id is g2f5d496 (which is a short but unique version of the
original sha1). You can use this commit id to get exactly this version
from a git repository (git clone ...; git checkout g2f5d496). If
somebody commited to the repository, the number in the middle would
increase and the hash change - but this will not happen in this
scenario, since github creates the tarball by checking out the tag (git
clone ...; git checkout v2-1.10), so as long as the project owner
doesn't change the meaning of the tag (which he usually won't since he
would redefine what vesion v2-1.10 means) this file name is stable.

That said, when you're fetching using the fetch command (this is
what ports uses) things look different anyway. L

Re: How to check out ports

[Michael Gmelin]

On 3 Oct 2012, at 19:40, Paul Schmehl  wrote:

> --On October 3, 2012 1:21:47 PM +0200 Michael Gmelin  wrote:
> 
>> 
>> The file name is the result of the command "git describe" and is
>> therefore stable. It consists of three parts:
>> 
>> tag - number of commits - commit hash
>> 
>> This project uses tags for versioning (which makes sense), so this file
>> name tells you that you're dealing with version v2-1.10, there have
>> been no commits to the tree since this version (it's unaltered) and the
>> commit id is g2f5d496 (which is a short but unique version of the
>> original sha1). You can use this commit id to get exactly this version
>> from a git repository (git clone ...; git checkout g2f5d496). If
>> somebody commited to the repository, the number in the middle would
>> increase and the hash change - but this will not happen in this
>> scenario, since github creates the tarball by checking out the tag (git
>> clone ...; git checkout v2-1.10), so as long as the project owner
>> doesn't change the meaning of the tag (which he usually won't since he
>> would redefine what vesion v2-1.10 means) this file name is stable.
>> 
>> That said, when you're fetching using the fetch command (this is
>> what ports uses) things look different anyway. Let's assume you're
>> fetching a tag (= a version) and not master (which is not a version, but
>> basically the current stable environment) and you're using the fetch
>> program to get it, then the resulting file name is NOT
>> firnsy-barnyard2-v2-1.10-0-g2f5d496.tar.gz but "v2-1.10".
>> 
>> [dev@bsd64 /tmp]$ fetch
>> https://github.com/firnsy/barnyard2/tarball/v2-1.10
>> v2-1.10   100% of  409 kB  414 kBps
>> ...
>> 
>> Like Eitan pointed out, fortunately there are github supporting options
>> in bsd.ports.mk. So if you use the following settings you should be fine
>> (just tested this here and ended up creating an almost complete port
>> skeleton - I turned v2-1.10 into 2.1.10 in the process, since v2-1.10
>> would not be supported by the ports system - so this installs as
>> barnyard2-2.1.10, which should be ok for future updates).
>> 
>> Makefile:
>> # Whom:pschmehl_li...@tx.rr.com
>> # $FreeBSD:$
>> #
>> 
>> PORTNAME=barnyard2
>> PORTVERSION=2.1.10
>> CATEGORIES=security
>> GH_ACCOUNT=firnsy
>> GH_PROJECT=barnyard2
>> GH_TAGNAME=v2-1.10
>> GH_COMMIT=2f5d496
>> USE_GITHUB= YES
>> GNU_CONFIGURE=yes
>> MAKE_JOBS_UNSAFE=YES
>> 
>> MAINTAINER=pschmehl_li...@tx.rr.com
>> COMMENT=Barnyard2 is a dedicated spooler\
>>for Snorts unified2 binary output format.
>> 
>> pre-configure:
>>cd ${WRKSRC}; ${SH} autogen.sh
>> 
>> .include 
>> 
>> distinfo:
>> SHA256 (barnyard2-2.1.10.tar.gz) =
>> 31d4e3745606489658bd411f74ffeb8a27573fdc08d0b51a6a71e1bf4dece8a2 SIZE
>> (barnyard2-2.1.10.tar.gz) = 419781
>> 
>> pkg-descr:
>> Barnyard2 is a dedicated spooler for Snort's
>> unified2 binary output format.
>> 
>> https://github.com/firnsy/barnyard2/
>> 
>> pkg-plist:
>> bin/barnyard2
>> etc/barnyard2.conf
>> 
>> I attached the full port skeleton in a tarball, it might need some
>> checking, I just did the usual (make install, make reinstall,
>> pkg_create, pkg_delete).
>> 
>> Maybe somebody could use this information to create a page about using
>> github in the porter's handbook (it won't be me :D)?
> 
> Thanks, Michael.  You've been a huge help.  I had earlier searched 
> /usr/ports/Mk for any sign of github and found none.  Your email made me 
> realize my ports were out of date, a problem I need to fix.
> 
> With your help I now have a distinfo file and am working on figuring out why 
> it won't make.
> 
> -- 
> Paul Schmehl, Senior Infosec Analyst
> As if it wasn't already obvious, my opinions
> are my own and not those of my employer.
> ***
> "It is as useless to argue with those who have
> renounced the use of reason as to administer
> medication to the dead." Thomas Jefferson
> "There are some ideas so wrong that only a very
> intelligent person could believe in them." George Orwell
> 

Check the tarball I sent in my last mail (attachments get purged on the mailing 
list but I CCed you directly, should untar that in /usr/ports/security, it's 
safer than copy and paste). That one built and installed ok on 9.0 amd64. What 
I could imagine is that autogen.sh is calling some autoconf/automake/lib tool 
magic that's already installed on my system and that should be made a 
dependency of the port. Let me know if you can't figure it out, once I'm back 
tomorrow I can try building it in a clean jail on 8.2 to see what's up.

(Sorry or the messy formatting, traveling means using the 
phone)___
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/portupgrade: ** Database file locked. Waiting.

[Michael Gmelin]

On Fri, 05 Oct 2012 10:47:33 -0500
Bryan Drewery  wrote:

> On 10/5/2012 10:40 AM, O. Hartmann wrote:
> > Am 10/05/12 17:28, schrieb Bryan Drewery:
> >> On 10/5/2012 3:24 AM, O. Hartmann wrote:
> >>> Using pkg(ng) in conjunction with the port ports/mgmt/portupgrade
> >>> results in long waiting cycles when portupgrade is updating the
> >>> local database, it is even on fast boxes sometimes in the range
> >>> of a minute or even two.
> >>
> >> You mean ports-mgmt/portupgrade-devel right?
> > 
> > Of course, yes.
> > 
> >>
> >>>
> >>> Is this usual or is there something wrong with my setup?
> >>>
> >>> Regards,
> >>> Oliver
> >>> ---
> >>>
> >>> [Updating the pkgdb  in /var/db/pkg ... - 1114
> >>> packages found (-0 +1) . done]
> >>> --->  Cleaning out obsolete shared libraries
> >>> [Updating the pkgdb  in /var/db/pkg ... USING
> >>> PKGNG ** Database file locked. Waiting.
> >>
> >> I have not experienced this. Are you running multiple portupgrade
> >> tools at once?
> > 
> > No, there is only one instance running at the same time, but apart
> > from the usual installations, I use Ruby 1.9 on all machines, I
> > guess Ruby 1.8 is still the default.
> 
> I am using 1.9 as well.
> 
> > 
> > But anyway, the long locking time is a bit of frustrating, since it
> > takes ages for updating large sets of ports (as done recently on
> > FreeBSD 9.1-PRE).
> > 
> 
> 
> Strange, I am unable to recreate this.
> 

I've been experiencing the same issue on various machines (different
versions of portupgrade and portupgrade-devel, different versions of
ruby etc.) for years. Some machines seem more prone to it than others
(only had the issue on machines using UFS+SU, but that might be
coincidental).
___
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"

Taking over maintainership of devel/py-ice, next steps

[Michael Gmelin]

Hi,

After some complications while submitting a patch to devel/py-ice
(getting a patch containing UTF-8 characters through the PR
system) the maintainer finally managed to apply the patch successfully,
but also decided to give up maintainership. Since I'm already managing
devel/ice and the two ports work closely together, I offered to take
over maintainership.

Tony (the maintainer) wrote "Ok this all worked fine so can commit and
make yourself maintainer, thanks!"
( http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/171645#reply9 )

I'm not the maintainer yet and I don't hold any commit bits, so I don't
think I can do any of these things myself. So what is the exact
process at this point? I understand how this works for abandoned
ports, but this is new to me and I couldn't find anything about such
a process in the Porter's Handbook[1], Contributing to the FreeBSD
Ports Collection[2] or Writing FreeBSD Problem Reports[3].

Thanks,
Michael

1. http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html
2. 
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/article.html
3. 
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/article.html

-- 
Michael Gmelin
___
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: [REMINDER] Please convert your ports to the new options framework

[Michael Gmelin]

On Sat, 6 Oct 2012 02:25:11 +0200
Baptiste Daroussin  wrote:

> Hi,
> 
> There are still 1590 ports to be converted, more than 1600 has
> already been converted, please consider converting yours.
> 
> Here is a list of ports to be converted:
> http://wiki.freebsd.org/Ports/Options/ConvertingToOptionsNG
> 
> Here is the list of maintainers having ports to be converted:
> http://people.freebsd.org/~bapt/optionsng-per-maintainer.txt
> 
> regards,
> Bapt

There are currently 18 ports without a maintainer (MAINTAINER =
po...@freebsd.org).

I would volunteer working on converting those, assuming I'm not
duplicating somebody else's work. I can't take over maintainership
afterwards though. I assume submitting individual PRs is preferred?

devel/binutils   po...@freebsd.org 
graphics/xfig-devel  po...@freebsd.org 
net/clickpo...@freebsd.org 
net/xorp-devel   po...@freebsd.org 
polish/gnugadu2  po...@freebsd.org 
print/advi   po...@freebsd.org 
security/libpreludedbpo...@freebsd.org 
security/openssh-portablepo...@freebsd.org 
sysutils/bacula2-server  po...@freebsd.org 
sysutils/jfbterm po...@freebsd.org 
textproc/openvanilla-modules po...@freebsd.org 
textproc/xalan-c po...@freebsd.org 
textproc/xerces-c2   po...@freebsd.org 
textproc/xmlwrapppo...@freebsd.org 
www/cgiwrap  po...@freebsd.org 
www/openacs  po...@freebsd.org 
x11-toolkits/tk84po...@freebsd.org 
x11-toolkits/tk86po...@freebsd.org 

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

Portscout.org

[Michael Gmelin]

Is there any chance to get portscout.org back? It hasn't been
working in quite a while, but portscout.cc does and this situation
hasn't change in the last 15 months (seems like miwi@ has problems
getting DNS service for the domain)

See also: http://miwi.bsdcrew.de/2011/07/portscout-is-back/

If not, the Porter's Handbook should probably be changed to contain the
new link (only one appearance in the whole document).

Cheers,
Michael

[developer@bsd64 ~]$ host portscout.org
Host portscout.org not found: 3(NXDOMAIN)
[developer@bsd64 ~]$ host www.portscout.org
Host www.portscout.org not found: 3(NXDOMAIN)

-- 
Michael Gmelin
___
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: [REMINDER] Please convert your ports to the new options framework

[Michael Gmelin]

On Sat, 6 Oct 2012 13:02:25 +0100
Chris Rees  wrote:

> On 6 Oct 2012 12:27, "Michael Gmelin"  wrote:
> >
> >
> >
> > On Sat, 6 Oct 2012 02:25:11 +0200
> > Baptiste Daroussin  wrote:
> >
> > > Hi,
> > >
> > > There are still 1590 ports to be converted, more than 1600 has
> > > already been converted, please consider converting yours.
> > >
> > > Here is a list of ports to be converted:
> > > http://wiki.freebsd.org/Ports/Options/ConvertingToOptionsNG
> > >
> > > Here is the list of maintainers having ports to be converted:
> > > http://people.freebsd.org/~bapt/optionsng-per-maintainer.txt
> > >
> > > regards,
> > > Bapt
> >
> > There are currently 18 ports without a maintainer (MAINTAINER =
> > po...@freebsd.org).
> >
> > I would volunteer working on converting those, assuming I'm not
> > duplicating somebody else's work. I can't take over maintainership
> > afterwards though. I assume submitting individual PRs is preferred?
> >
> > devel/binutils   po...@freebsd.org
http://www.freebsd.org/cgi/query-pr.cgi?pr=172422

> > graphics/xfig-devel  po...@freebsd.org
http://www.freebsd.org/cgi/query-pr.cgi?pr=172436

> > net/clickpo...@freebsd.org
http://www.freebsd.org/cgi/query-pr.cgi?pr=172425

> > net/xorp-devel   po...@freebsd.org
http://www.freebsd.org/cgi/query-pr.cgi?pr=172438

> > polish/gnugadu2  po...@freebsd.org
http://www.freebsd.org/cgi/query-pr.cgi?pr=172427

> > print/advi   po...@freebsd.org
xxx

> > security/libpreludedbpo...@freebsd.org
http://www.freebsd.org/cgi/query-pr.cgi?pr=172426

> > security/openssh-portablepo...@freebsd.org
http://www.freebsd.org/cgi/query-pr.cgi?pr=172429

> > sysutils/bacula2-server  po...@freebsd.org
xxx

> > sysutils/jfbterm po...@freebsd.org
http://www.freebsd.org/cgi/query-pr.cgi?pr=172424

> > textproc/openvanilla-modules po...@freebsd.org
http://www.freebsd.org/cgi/query-pr.cgi?pr=172430

> > textproc/xalan-c po...@freebsd.org
http://www.freebsd.org/cgi/query-pr.cgi?pr=172433

> > textproc/xerces-c2   po...@freebsd.org
http://www.freebsd.org/cgi/query-pr.cgi?pr=172434

> > textproc/xmlwrapppo...@freebsd.org
http://www.freebsd.org/cgi/query-pr.cgi?pr=172437

> > www/cgiwrap  po...@freebsd.org
http://www.freebsd.org/cgi/query-pr.cgi?pr=172423

> > www/openacs  po...@freebsd.org
http://www.freebsd.org/cgi/query-pr.cgi?pr=172428

> > x11-toolkits/tk84po...@freebsd.org
http://www.freebsd.org/cgi/query-pr.cgi?pr=172431

> > x11-toolkits/tk86po...@freebsd.org
http://www.freebsd.org/cgi/query-pr.cgi?pr=172432

> 
> Individual PRs allow workload to be spread.  You'll find it all goes
> in quicker that way :)
> 
> Chris
> ___
> 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"

I submitted patches for all of the above except

print/advi - Already fixed by Eitan Adler
sysutils/bacula2-server - Is deprecated and will be removed from the
  ports tree in two weeks anyway.

Cheers,
Michael



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

General usefulness of option descriptions

[Michael Gmelin]

Hi,

This probably has been discussed before, but I think in many cases
using the default descriptions of OptionsNG is more harm than good.

I converted security/libpreludedb to OptionsNG yesterday and
left in most of the descriptions and therefore overrode them. I did
that for a good reason, since I believe that the description of the
option should be more than just repeating the option name.
Unfortunately the portmgr in charge disagreed and removed all
description overrides, figuring that I must have forgotten to remove
them. That's why I raise this topic on the list - I feel like we're
using a lot of information if we converting ports like this.

In this specific example this means:

Before:
 PERL=off: Include Perl bindings
 PYTHON=off: Include Python bindings
 MYSQL=on: Use MySQL backend
 PGSQL=off: Use PostgreSQL backend
 SQLITE=off: Use SQLite backend

Afterwards:
 DOCS=on: Build and/or install documentation
 MYSQL=on: MySQL database
 PERL=off: Perl scripting language
 PGSQL=off: PostgreSQL database
 PYTHON=off: Python bindings
 SQLITE=off: SQLite database

This might not seem dramatic at a first glance, but something
bad just happened here. We moved from describing what the option
actually means to the user in the context of the port ("Include Perl
binding", "Use MySQL backend") to what it means to the ports tree
("Perl scripting language", "MySQL database"). The purpose of using the
option in context of the port is not visible anymore and at this point
showing the user MYSQL PERL PGSQL PYTHON SQLITE as options without any
descriptions would provide just as much information.

One could argue that if a different description is necessary, a
different option name should be chosen. But this doesn't really work,
since the meaning to the ports tree in fact *is* that a dependency to
Perl or MySQL should be introduced, so using the global option names
makes sense. If one wants to install all ports with their Perl or MySQL
features enabled, just flipping that one switch should do it, regardless
of the exact meaning in the context of the port.

Conclusion:

1. Option names are for the ports tree structure, there should be as
   little as possible and global option names are to be preferred. The
   more generic the better, they express a software dependency between
   ports on the level of "give me support for xyz", but not the purpose
   of this dependency in context of the port.

2. Option descriptions are for the user of the port and should be as
   contextual as possible. In the end it makes a difference to the
   user what feature/functionality is actually accomplished by
   introducing/installing a dependency. There are always options where
   this is just fine  and the meaning is clear (e.g. THREADS,
   OPTIMIZE_CFLAGS), but blindly removing this information from a
   port is harmful.

3. Global option descriptions seem inconsistent as well (all kinds
   exist like support/backend/bindings etc., probably depending on the
   first port that used them) and to make matters worse, they're
   actually changing, e.g. bsd.options.desc.mk from 2012/08/31 said:
   MYSQL_DESC?= MySQL backend
   While the one from 2012/10/07 says:
   MYSQL_DESC?= MySQL database
   So even if using the default was contextually correct at some point,
   it could just be changed without the maintainer noticing it.

What are your thoughts on this?

Cheers,
Michael

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

HAVE_GNOME vs. bsd.ports.options.mk

[Michael Gmelin]

Hi

I noticed that HAVE_GNOME doesn't work properly with
bsd.ports.options.mk yet, so

.include 
.if ${HAVE_GNOME:Mgnomelibs}!=""
# ...
.endif
.include 

won't work, while this

.include 
.if ${HAVE_GNOME:Mgnomelibs}!=""
# ...
.endif
.include 

does.

AFAIK bsd.port.pre.mk/bsd.port.post.mk should be replaced by
bsd.port.options.mk/bsd.port.mk in the long term, so having this work
or documenting a workaround would help port maintainers who are
in the process of updating the port structure.

Michael

-- 
Michael Gmelin
___
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: HAVE_GNOME vs. bsd.ports.options.mk

[Michael Gmelin]

On Wed, 10 Oct 2012 12:25:27 +0200
Baptiste Daroussin  wrote:

> On Wed, Oct 10, 2012 at 12:18:50PM +0200, Michael Gmelin wrote:
> > Hi
> > 
> > I noticed that HAVE_GNOME doesn't work properly with
> > bsd.ports.options.mk yet, so
> > 
> > .include 
> > .if ${HAVE_GNOME:Mgnomelibs}!=""
> > # ...
> > .endif
> > .include 
> > 
> > won't work, while this
> > 
> > .include 
> > .if ${HAVE_GNOME:Mgnomelibs}!=""
> > # ...
> > .endif
> > .include 
> > 
> > does.
> > 
> > AFAIK bsd.port.pre.mk/bsd.port.post.mk should be replaced by
> > bsd.port.options.mk/bsd.port.mk in the long term, so having this
> > work or documenting a workaround would help port maintainers who are
> > in the process of updating the port structure.
> > 
> > Michael
> > 
> > -- 
> > Michael Gmelin
> > ___
> > 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"
> 
> Which ports are you speaking about? given that HAVE_GNOME:#gnomelibs
> is refering to gnome 1.4 I think this part can safely be dropped out.
> 
> regards,
> Bapt

I'm talking about the feature in general, it also applies to
HAVE_GNOME:Mesound, HAVE_GNOME:Mpygnomeextras etc.

I stumbled over this while converting polish/gnugadu2 to OptionsNG
(http://www.freebsd.org/cgi/query-pr.cgi?pr=172427).

Michael

-- 
Michael Gmelin
___
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: HAVE_GNOME vs. bsd.ports.options.mk

[Michael Gmelin]

On Wed, 10 Oct 2012 12:57:57 +0200
Baptiste Daroussin  wrote:

> On Wed, Oct 10, 2012 at 12:33:22PM +0200, Michael Gmelin wrote:
> > On Wed, 10 Oct 2012 12:25:27 +0200
> > Baptiste Daroussin  wrote:
> > 
> > > On Wed, Oct 10, 2012 at 12:18:50PM +0200, Michael Gmelin wrote:
> > > > Hi
> > > > 
> > > > I noticed that HAVE_GNOME doesn't work properly with
> > > > bsd.ports.options.mk yet, so
> > > > 
> > > > .include 
> > > > .if ${HAVE_GNOME:Mgnomelibs}!=""
> > > > # ...
> > > > .endif
> > > > .include 
> > > > 
> > > > won't work, while this
> > > > 
> > > > .include 
> > > > .if ${HAVE_GNOME:Mgnomelibs}!=""
> > > > # ...
> > > > .endif
> > > > .include 
> > > > 
> > > > does.
> > > > 
> > > > AFAIK bsd.port.pre.mk/bsd.port.post.mk should be replaced by
> > > > bsd.port.options.mk/bsd.port.mk in the long term, so having this
> > > > work or documenting a workaround would help port maintainers
> > > > who are in the process of updating the port structure.
> > > > 
> > > > Michael
> > > > 
> > > > -- 
> > > > Michael Gmelin
> > > > ___
> > > > 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"
> > > 
> > > Which ports are you speaking about? given that
> > > HAVE_GNOME:#gnomelibs is refering to gnome 1.4 I think this part
> > > can safely be dropped out.
> > > 
> > > regards,
> > > Bapt
> > 
> > I'm talking about the feature in general, it also applies to
> > HAVE_GNOME:Mesound, HAVE_GNOME:Mpygnomeextras etc.
> > 
> > I stumbled over this while converting polish/gnugadu2 to OptionsNG
> > (http://www.freebsd.org/cgi/query-pr.cgi?pr=172427).
> > 
> > Michael
> > 
> > -- 
> > Michael Gmelin
> 
> imho HAVE_GNOME should die, as autodectection of what you have does
> not fit at all with package building. Thing shouldn't been added
> magically because they are on your system but only on explicit demand
> of the maintainer/user.
> 
> That said I'll have a look at the PR.
> 
> regards,
> Bapt

I found this behaviour in many ports and I agree that by
default people should be able to explicitly state what they want. On
the other hand it can be extremely convenient to get all plugins your
system supports by default (for those of us you build their ports
themselves). I solved this in this PR by adding an "AUTODETECT" option,
that allows the port to detect automatically only when explicitly asked
by the builder. I had that turned on by default to make sure
the port behaves exactly like it did before conversion to OptionsNG
(it's not my lawn, you know). The committer changed that to be off by
default, since this is a better solution for package building and I
agree with him.

Also note that there are a lot of ports that use either techniques for
auto detection (e.g. checking for the existence of libraries to bring
in functionality) and that those should be covered as well - simply not
allowing auto detection will massively reduce functionality, so using
an OPTION to allow it might be the way to go. I think AUTODETECT might
be an interesting candidate for bsd.options.mk though.

Michael

-- 
Michael Gmelin
___
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: HAVE_GNOME vs. bsd.ports.options.mk

[Michael Gmelin]

On Wed, 10 Oct 2012 16:27:58 +0200
Baptiste Daroussin  wrote:

> On Wed, Oct 10, 2012 at 12:49:38PM +0200, Michael Gmelin wrote:
> > On Wed, 10 Oct 2012 12:57:57 +0200
> > Baptiste Daroussin  wrote:
> > 
> > > On Wed, Oct 10, 2012 at 12:33:22PM +0200, Michael Gmelin wrote:
> > > > On Wed, 10 Oct 2012 12:25:27 +0200
> > > > Baptiste Daroussin  wrote:
> > > > 
> > > > > On Wed, Oct 10, 2012 at 12:18:50PM +0200, Michael Gmelin
> > > > > wrote:
> > > > > > Hi
> > > > > > 
> > > > > > I noticed that HAVE_GNOME doesn't work properly with
> > > > > > bsd.ports.options.mk yet, so
> > > > > > 
> > > > > > .include 
> > > > > > .if ${HAVE_GNOME:Mgnomelibs}!=""
> > > > > > # ...
> > > > > > .endif
> > > > > > .include 
> > > > > > 
> > > > > > won't work, while this
> > > > > > 
> > > > > > .include 
> > > > > > .if ${HAVE_GNOME:Mgnomelibs}!=""
> > > > > > # ...
> > > > > > .endif
> > > > > > .include 
> > > > > > 
> > > > > > does.
> > > > > > 
> > > > > > AFAIK bsd.port.pre.mk/bsd.port.post.mk should be replaced by
> > > > > > bsd.port.options.mk/bsd.port.mk in the long term, so having
> > > > > > this work or documenting a workaround would help port
> > > > > > maintainers who are in the process of updating the port
> > > > > > structure.
> > > > > > 
> > > > > > Michael
> > > > > > 
> > > > > > -- 
> > > > > > Michael Gmelin
> > > > > > ___
> > > > > > 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"
> > > > > 
> > > > > Which ports are you speaking about? given that
> > > > > HAVE_GNOME:#gnomelibs is refering to gnome 1.4 I think this
> > > > > part can safely be dropped out.
> > > > > 
> > > > > regards,
> > > > > Bapt
> > > > 
> > > > I'm talking about the feature in general, it also applies to
> > > > HAVE_GNOME:Mesound, HAVE_GNOME:Mpygnomeextras etc.
> > > > 
> > > > I stumbled over this while converting polish/gnugadu2 to
> > > > OptionsNG (http://www.freebsd.org/cgi/query-pr.cgi?pr=172427).
> > > > 
> > > > Michael
> > > > 
> > > > -- 
> > > > Michael Gmelin
> > > 
> > > imho HAVE_GNOME should die, as autodectection of what you have
> > > does not fit at all with package building. Thing shouldn't been
> > > added magically because they are on your system but only on
> > > explicit demand of the maintainer/user.
> > > 
> > > That said I'll have a look at the PR.
> > > 
> > > regards,
> > > Bapt
> > 
> > I found this behaviour in many ports and I agree that by
> > default people should be able to explicitly state what they want. On
> > the other hand it can be extremely convenient to get all plugins
> > your system supports by default (for those of us you build their
> > ports themselves). I solved this in this PR by adding an
> > "AUTODETECT" option, that allows the port to detect automatically
> > only when explicitly asked by the builder. I had that turned on by
> > default to make sure the port behaves exactly like it did before
> > conversion to OptionsNG (it's not my lawn, you know). The committer
> > changed that to be off by default, since this is a better solution
> > for package building and I agree with him.
> > 
> > Also note that there are a lot of ports that use either techniques
> > for auto detection (e.g. checking for the existence of libraries to
> > bring in functionality) and that those should be covered as well -
> > simply not allowing auto detection will massively reduce
> > functionality, so using an OPTION to allow it might be the way to
> > go. I think AUTODETECT might be an interesting candidate for
> > bsd.options.mk though.
> > 
> > Michael
> 
> Autodetection will only work in the case a ports is build on a
> end-user machine directly, as soon as it is build in a sane
> environmenent like poudriere/tinderbox/pointyhat then it will
> completly fail, and won't bring the feature.

Not correct, on poudriere/tinderbox/pointyhat the AUTODETECT flag won't
be set, so it won't cause any harm (and will not "completely fail"). You
still can set the features you want explicitly, so it's useful to
package builders as well as users.

Regardless of the topic of auto detection though - HAVE_GNOME breaks
when things are done the new way, it should be noted somewhere that
this is the case, so people won't waste their time on figuring out
what's going wrong.

Michael

-- 
Michael Gmelin
___
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: HAVE_GNOME vs. bsd.ports.options.mk

[Michael Gmelin]

On Wed, 10 Oct 2012 16:40:39 +0100
Chris Rees  wrote:

> On 10 Oct 2012 11:19, "Michael Gmelin"  wrote:
> >
> > Hi
> >
> > I noticed that HAVE_GNOME doesn't work properly with
> > bsd.ports.options.mk yet, so
> >
> > .include 
> > .if ${HAVE_GNOME:Mgnomelibs}!=""
> > # ...
> > .endif
> > .include 
> >
> > won't work, while this
> >
> > .include 
> > .if ${HAVE_GNOME:Mgnomelibs}!=""
> > # ...
> > .endif
> > .include 
> >
> > does.
> >
> > AFAIK bsd.port.pre.mk/bsd.port.post.mk should be replaced by
> > bsd.port.options.mk/bsd.port.mk in the long term, so having this
> > work or documenting a workaround would help port maintainers who are
> > in the process of updating the port structure.
> 
> No. They are two separate methods with two different reasons for
> using them.
> 
> You have discovered a case of pre.mk being the correct one to use,
> which is unusual :)
> 
> Chris
> ___
> 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"

In which case the Porter's Handbook gives little to no advice what the
actual differences are.

The only time bsd.port.options.mk is mentioned is in the context of
OptionsNG (5.12.2.2) where it says:

"OPTIONS definitions must appear before the inclusion of
bsd.port.options.mk. The PORT_OPTIONS variable can only be tested after
the inclusion of bsd.port.options.mk. Inclusion of bsd.port.pre.mk can
be used instead, too, and is still widely used in ports written before
the introduction of bsd.port.options.mk. But be aware that some
variables will not work as expected after the inclusion of
bsd.port.pre.mk, typically some USE_* flags."

Which sounds to me like: "Yes, you can still use bsd.port.pre.mk, but
it's the old way of doing things and expect bad things to happen."

It would probably make sense to refine that section in the Porter's
Handbook - I know that this is a moving target right now, but since it
is it either needs to be adapted or at least fact that this is the case
should be stated somewhere (potentially with a link to the wiki).

I would be willing to propose a refined version of this section in the
Porter's Handbook - might take me a while though since I'm pretty busy
at the moment. But if nobody else has the resources I would do it myself
for the sake of making things easier for maintainers.

Michael

-- 
Michael Gmelin
___
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: HAVE_GNOME vs. bsd.ports.options.mk

[Michael Gmelin]

On Wed, 10 Oct 2012 11:59:03 -0400
Eitan Adler  wrote:

> On 10 October 2012 06:49, Michael Gmelin  wrote:
> ... > I had that turned on by default to make sure
> > the port behaves exactly like it did before conversion to OptionsNG
> > (it's not my lawn, you know).
> 
> Hehe, this is good thing. Normally you want to try to replicate
> existing behavior.
> 
> > The committer changed that to be off by
> > default, since this is a better solution for package building and I
> > agree with him.
> 
> But... in this case the previous behavior was "buggy" so it had to be
> changed.

That's why I agree with him, it was the right thing to do. Ah.. I
just realized "he" was you, so yes, I totally agree with you that this
was the right thing to do and as a committer you're in the position to
do that. It wouldn't have been appropriate to change this myself though,
since I claimed to do a conversion, which wouldn't have
been correct otherwise.

> 
> > Also note that there are a lot of ports that use either techniques
> > for auto detection (e.g. checking for the existence of libraries to
> > bring in functionality) and that those should be covered as well -
> > simply not allowing auto detection will massively reduce
> > functionality, so using an OPTION to allow it might be the way to
> > go. I think AUTODETECT might
> 
> I agree.
> 
> 
> P.S. I never did properly thank you for all those OptionsNG PRs. Most
> of them went in without any changes at all, which is unusual. Thanks!
> 
> 

You're welcome :)


-- 
Michael Gmelin
___
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: HAVE_GNOME vs. bsd.ports.options.mk

[Michael Gmelin]

On Wed, 10 Oct 2012 10:56:32 -0500
Jeremy Messenger  wrote:

> On Wed, Oct 10, 2012 at 10:54 AM, Jeremy Messenger
>  wrote:

> > See here: http://markmail.org/message/vmjueo2chuub5m2p  (read all
> > threads, please)
> >
> > I have made suggests on what to do. Please contact with A.J. Kehoe
> > IV. I suggested him to create a team to work on get rid of
> > HAVE_GNOME. He even has created a wiki page about it at
> > http://wiki.freebsd.org/Gnome .
> 
> http://wiki.freebsd.org/Gnome#WANT_GNOME_Decommission
> 
> > A.J. Kehoe IV, sorry, my time is very limit right now. Maybe now you
> > will have more people that can help you after this email. Who knows.
> >
> > Cheers,
> > Mezz
> >

Thanks for enlightening me, getting rid of WANT_GNOME actually seems
like a great idea to reduce dependency hell.

-- 
Michael Gmelin
___
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: truncated attachment in gnats

[Michael Gmelin]

On 16 Oct 2012, at 13:35, Ruslan Mahmatkhanov  wrote:

> 
> Hi,
> 
> Please compare:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports%2F172280&getpatch=1
> 
> and the patch in pr:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/172280
> 
> Look at last line in both cases. I can't reproduce it with other pr's, so may 
> this be related to non-ascii chars in the attachment?
> 
> -- 
> Regards,
> Ruslan
> 
> Tinderboxing kills... the drives.
> ___
> 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"

Hi Ruslan,

I faced a similar problem recently and opened a PR.

You might want to send a follow up:

http://www.freebsd.org/cgi/query-pr.cgi?pr=172195

-- Michael
___
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: something had broken in *.mk?

[Michael Gmelin]

On Wed, 17 Oct 2012 14:20:45 +0200
Baptiste Daroussin  wrote:

> On Wed, Oct 17, 2012 at 01:55:37PM +0200, Baptiste Daroussin wrote:
> > On Wed, Oct 17, 2012 at 02:58:50PM +0400, Ruslan Mahmatkhanov wrote:
> > > John Marino wrote on 17.10.2012 14:52:
> > > > You're building with bmake and not make.
> > > > bmake uses :tu and :tl where make uses :U and :L, among other
> > > > things. It's the :L modifier that's causing your errors.
> > > > use the FreeBSD version of make instead.
> > > > John
> > > 
> > > Yes, you are right. I just remember that I decided to check
> > > WITH_BMAKE. Just rebuild usr.bin/make without this knob and
> > > everything now ok. Thanks.
> > > 
> > > -- 
> > > Regards,
> > > Ruslan
> > > 
> > > Tinderboxing kills... the drives.
> > > ___
> > > 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"
> > 
> > We will be able to switch the ports tree to bmake after 9.0 and 8.2
> > are EOLed
> > 
> > regards,
> > Bapt
> 
> 
> I meant 8.3 and 9.0 sorry
> regards,
> Bapt

Is there any background information about this planned switch to bmake
(beyond http://wiki.freebsd.org/201110DevSummit/bmake).


-- 
Michael Gmelin
___
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: Taking over maintainership of devel/py-ice, next steps

[Michael Gmelin]

On Sat, 6 Oct 2012 13:00:05 +0200
Michael Gmelin  wrote:

> Hi,
> 
> After some complications while submitting a patch to devel/py-ice
> (getting a patch containing UTF-8 characters through the PR
> system) the maintainer finally managed to apply the patch
> successfully, but also decided to give up maintainership. Since I'm
> already managing devel/ice and the two ports work closely together, I
> offered to take over maintainership.
> 
> Tony (the maintainer) wrote "Ok this all worked fine so can commit and
> make yourself maintainer, thanks!"
> ( http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/171645#reply9 )
> 
> I'm not the maintainer yet and I don't hold any commit bits, so I
> don't think I can do any of these things myself. So what is the exact
> process at this point? I understand how this works for abandoned
> ports, but this is new to me and I couldn't find anything about such
> a process in the Porter's Handbook[1], Contributing to the FreeBSD
> Ports Collection[2] or Writing FreeBSD Problem Reports[3].
> 
> Thanks,
> Michael
> 
> 1.
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html
> 2.
> http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/article.html
> 3.
> http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/article.html
> 

Hi,

Sorry to bother the list about this again, but I would really like to
finish upgrading the port - since the maintainer is really short in
time this got kind of stuck in the middle. He's fine with passing on
maintainership and also with the patch - if the PR is too messy for a
committer (there were a couple of - unresolved - encoding issues) I
would suggest to close it, pass maintainership to me and I will open a
new PR to get the updates in.

Thanks,
Michael

-- 
Michael Gmelin
___
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: Taking over maintainership of devel/py-ice, next steps

[Michael Gmelin]

On Fri, 26 Oct 2012 23:43:11 +0400
Ruslan Mahmatkhanov  wrote:

> Hi Michael,
> 
> Michael Gmelin wrote on 26.10.2012 23:30:
> > Hi,
> >
> > Sorry to bother the list about this again, but I would really like
> > to finish upgrading the port - since the maintainer is really short
> > in time this got kind of stuck in the middle. He's fine with
> > passing on maintainership and also with the patch - if the PR is
> > too messy for a committer (there were a couple of - unresolved -
> > encoding issues) I would suggest to close it, pass maintainership
> > to me and I will open a new PR to get the updates in.
> >
> > Thanks,
> > Michael
> 
> I already taken this pr at 17 October and request you to send the
> patch to me directly, because I wasn't able to make it usable:
> 
> """
> I will take it. Hi Michael. Would you please put your patch somewhere
> and post the link there. I always got 'not in gzip format' using your
> latest submission. Thank you
> """
> 


Hi Ruslan,

Sorry, I wasn't informed by GNATS about your offer to help (double
checked junk and trash). This seems to happen once in a while lately.

The gzipped version of the patch didn't work, since there is an
encoding problem with patches sent through the PR system (I think the
both of us emailed about this earlier this month - binary patches as
well as UTF-8 encoded patches [PR 172195]) - it should work if you
copy and paste the base64 encoded text and base64 decode it and then
gunzip (which is of course a ridiculous procedure to follow).

So please find attached the original patch as well as the gzipped
version (just to make sure no MUA encoding issue gets in our way). I
assume at least the gzipped version will be stripped by the mailing
list, so I Cced you directly.

Note that the patch doesn't include the maintainer change - so please
let me know in case there is an additional procedure I should follow
to accomplish this.

Apply the patch by doing (assuming it's stored in /tmp):

cd /usr/ports/devel/py-ice
zcat /tmp/py27-Ice-3.4.2_3.patch.gz | patch -p0 -E
find . -name \*.orig -delete

Checksums are:

MD5 (py27-Ice-3.4.2_3.patch) = 27f1b4aeb4ae2c85aeb0445ae4fb493f
MD5 (py27-Ice-3.4.2_3.patch.gz) = 92b70f01768e54441dff4f68676e48ab

If something goes wrong you can also fetch it for a limited amount of
time at this URL:

http://blog.grem.de/py27-Ice-3.4.2_3.patch.gz

Thanks for your help,
Michael

-- 
Michael Gmelin
diff -ruN --exclude=CVS ../py-ice.orig/Makefile ./Makefile
--- ../py-ice.orig/Makefile 2012-08-22 17:18:15.0 +0200
+++ ./Makefile  2012-09-12 02:37:38.254057273 +0200
@@ -5,56 +5,69 @@
 # $FreeBSD: ports/devel/py-ice/Makefile,v 1.20 2012/08/22 15:18:15 jgh Exp $
 #
 
-PORTNAME=  Ice
-PORTVERSION=   3.4.2
-PORTREVISION=  2
-CATEGORIES=devel python
-MASTER_SITES=  http://download.zeroc.com/Ice/3.4/ \
-   http://www.dirk.sh/dirk/Ice/
-PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}
-
-MAINTAINER=tonyma...@optusnet.com.au
-COMMENT=   An Ice (Internet Communications Engine) language mapping for 
Python
-
-BUILD_DEPENDS= mcpp:${PORTSDIR}/devel/mcpp
-LIB_DEPENDS=   Ice.${LIB_VRS}:${PORTSDIR}/devel/ice
-
-USE_GMAKE= yes
-USE_PYTHON=yes
-BUILD_WRKSRC=  ${WRKSRC}/py
-INSTALL_WRKSRC=${WRKSRC}/py
-
-LIB_VRS=   ${PORTVERSION:S|.||g:C|2$||}
-PLIST_SUB= LIB_VERSION="${PORTVERSION}" LIB_VRS="${LIB_VRS}"
-MAKE_ENV=  ICE_HOME="${LOCALBASE}/share/Ice"
-
-CFLAGS+=   -ftemplate-depth-128 -fPIC -DPIC -Wall -D_REENTRANT 
${PTHREAD_CFLAGS}
-.if defined(DEBUG)
-CFLAGS+=   -g
-.else
-CFLAGS+=   -DNDEBUG
+PORTNAME=  Ice
+PORTVERSION=   3.4.2
+PORTREVISION=  3
+CATEGORIES=devel python
+MASTER_SITES=  http://download.zeroc.com/Ice/3.4/ \
+   http://www.dirk.sh/dirk/Ice/
+PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}
+
+MAINTAINER=tonyma...@optusnet.com.au
+COMMENT=   An Ice (Internet Communications Engine) language 
mapping for Python
+
+BUILD_DEPENDS= mcpp:${PORTSDIR}/devel/mcpp
+LIB_DEPENDS=   Ice.${LIB_VRS}:${PORTSDIR}/devel/ice
+
+USE_GMAKE= yes
+USE_PYTHON=yes
+BUILD_WRKSRC=  ${WRKSRC}/py
+INSTALL_WRKSRC=${WRKSRC}/py
+
+LIB_VRS=   ${PORTVERSION:S|.||g:C|2$||}
+PLIST_SUB= LIB_VERSION="${PORTVERSION}" LIB_VRS="${LIB_VRS}"
+MAKE_ENV=  ICE_HOME="${LOCALBASE}/share/Ice"
+
+OPTIONS_DEFINE=DEBUG DOCS TESTS
+OPTIONS_DEFAULT=   TESTS
+TESTS_DESC=Run tests
+
+# bypass infrastructure bug (taken from www/py-django)
+OPTIONSFILE=   ${PORT_DBDIR}/py-${PORTNAME}/options
+
+.include 
+
+CFLAGS+=   -ftemplate-depth-128 -fPI

Re: Taking over maintainership of devel/py-ice, next steps

[Michael Gmelin]

On 27 Oct 2012, at 22:01, Ruslan Mahmatkhanov  wrote:

> Hi Michael,
> 
> Michael Gmelin wrote on 27.10.2012 00:09:
>> If something goes wrong you can also fetch it for a limited amount of
>> time at this URL:
>> 
>> http://blog.grem.de/py27-Ice-3.4.2_3.patch.gz
>> 
>> Thanks for your help,
>> Michael
> 
> Just committed with couple of change from mine (see commit message). And I 
> also decide to keep original indentation, because there is actually no reason 
> to double them, imho. Thank you for the patch and patience ;).
> 
> -- 
> Regards,
> Ruslan
> 
> Tinderboxing kills... the drives.
> ___
> 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"

Hi Ruslan,

Thanks for your work, I just checked the commit message and agree with your 
changes. Eitan Adler informed me about the convention of not changing a 
Makefile's indentation just for Options NG, but that was after I submitted this 
patch ;)

Cheers,
Michael
___
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: Github problems

[Michael Gmelin]

On 8 Nov 2012, at 22:05, Paul Schmehl  wrote:

> I'm working on a new port, and I'm having problems with Github.
> 
> The url to the tarball is:
> 
> 
> This is what I have in the Makefile:
> 
> # $FreeBSD$
> 
> PORTNAME=   snorby
> PORTVERSION=2.5.3
> CATEGORIES= security
> 
> MAINTAINER= pa...@utdallas.edu
> COMMENT=Frontend for snort
> 
> USE_GITHUB= yes
> GH_ACCOUNT= Snorby
> GH_PROJECT= ${PORTNAME}
> GH_TAGNAME= master
> #GH_COMMIT= master
> 
> When I run make makesum I get this:
> 
> => snorby-2.5.3.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
> => Attempting to fetch 
> https://nodeload.github.com/Snorby/snorby/tarball/master?dummy=/snorby-2.5.3.tar.gz
> 
> Obviously that fails.  I looked through /usr/ports/Mk/bsd.sites.mk, but I 
> don't see any way to override the part after dummy=.  I tried making 
> GH_COMMIT= master, but that did nothing.
> 
> What's the correct solution to this?  There doesn't seem to be anything in 
> the Porters Handbook about github.
> 
> -- 
> Paul Schmehl, Senior Infosec Analyst
> As if it wasn't already obvious, my opinions
> are my own and not those of my employer.
> ***
> "It is as useless to argue with those who have
> renounced the use of reason as to administer
> medication to the dead." Thomas Jefferson
> "There are some ideas so wrong that only a very
> intelligent person could believe in them." George Orwell
> 
> ___
> 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"

Try searching the mailing list archives, this topic has been discussed in quite 
detail a few weeks ago.
___
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: Removing git dependencies on perl5 and python27

[Michael Gmelin]

> On 15. Jun 2018, at 05:57, Adam Weinberger  wrote:
> 
>> On Thu, Jun 14, 2018 at 8:16 PM Mahmoud Al-Qudsi  wrote:
>> 
>> Hello list,
>> 
>> I'm probably not alone in considering git to be a core development tool,
>> perhaps just a notch or two below the C compiler. `git` and `sudo` are the 
>> two
>> packages I first install (after `pkg` itself) on any machine, and in many
>> cases that suffices to get a basic development environment going.
>> 
>> However, the git package currently brings in a host of unwanted dependencies,
>> and I *believe* they can be done without.
>> 
>> This is the complete dependency graph for the git package [0] (generated with
>> the newly-minted pkg-graph [1]). It pulls in perl5 and python27, both 
>> sizeable
>> packages and both not required to use git.
>> 
>> While git can be compiled without some of the additional dependencies such as
>> expat or pcre, this results in a "crippled" git lacking in some core 
>> features,
>> and requires special build-time definitions like NO_EXPAT or NO_PCRE passed 
>> to
>> the git Makefile. The other dependencies like curl, pcre, and gettext are 
>> also
>> relatively small and typically part of even the most minimal system, but 
>> perl5
>> and python27 are full-blown runtimes for interpreted languages that have
>> fallen out of favor and have been successfully stripped from FreeBSD core 
>> (and
>> even many Linux distributions).
>> 
>> I'm sure these packages are not just there to have a good time and they serve
>> some purpose and enable a subset of the git functionality, but my question
>> here today is whether that functionality is worth its weight in dependencies,
>> and whether the ports team is open to seeing the git package stripped of 
>> these
>> dependencies.
>> 
>> (Obviously the option of adding a "git-lite" package à la "vim-lite" also
>> exists, but I think it's fair to say that would be an ugly and unnecessary
>> compromise.)
>> 
>> [0]: https://goo.gl/hozu1b
>> [1]: https://github.com/neosmart/pkg-graph
> 
> Agreed. I'd personally much rather see small default packages and
> -kitchensink slaves, than massive default packages and -lite slaves.
> It's always struck me as odd that our git package comes with CVS and
> Perforce support.
> 
> # Adam
> 
> 

Last time I checked, building git without Perl broke submodules (which is a 
core feature that should work with a default installation).

Michael


___
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 git dependencies on perl5 and python27

[Michael Gmelin]

Hm, seems like you're right, which is good news for me, I always built
it without perl until this commit:

r396048 | garga | 2015-09-04 00:00:03 +0200 (Fri, 04 Sep 2015) | 5 lines

- Update to 2.5.1
- Fix build with NO_PERL set backporting a commit from git repo
  (82aec45)
- Add git-submodile, git-am and git-request-pull to the list of commands
  that doesn't work without perl

@@ -86,7 +86,7 @@
mv $@+ $@
  else # NO_PERL
 -$(SCRIPT_PERL_GEN) git-instaweb: % : unimplemented.sh
-+$(SCRIPT_PERL_GEN) git-instaweb git-submodule git-am
git-request-pull: % : unimplemented.sh ++$(SCRIPT_PERL_GEN)
git-instaweb git-submodule git-request-pull: % : unimplemented.sh


Seems like it was removed again here:

r416890 | garga | 2016-06-14 16:52:40 +0200 (Tue, 14 Jun 2016) | 4 lines

Update devel/git to 2.9.0

@@ -88,7 +38,7 @@
mv $@+ $@
  else # NO_PERL
 -$(SCRIPT_PERL_GEN) git-instaweb: % : unimplemented.sh
-+$(SCRIPT_PERL_GEN) git-instaweb git-submodule git-request-pull: % :
unimplemented.sh ++$(SCRIPT_PERL_GEN) git-instaweb git-request-pull:
% : unimplemented.sh

Thanks,
Michael


On Fri, 15 Jun 2018 03:10:37 -0500
Mahmoud Al-Qudsi  wrote:

> On Fri, Jun 15, 2018 at 2:57 AM, Michael Gmelin 
> wrote:
> > Last time I checked, building git without Perl broke submodules
> > (which is a core feature that should work with a default
> > installation).  
> 
> I fully agree. Fortunately, (at least at a first glance) that does not
> seem to be the case.
> 
> I just built and installed git from source on a clean FreeBSD 12
> install:
> 
> ```
> mqudsi@freebsd12:/easyre % mkdir test
> mqudsi@freebsd12:/easyre % cd test
> mqudsi@freebsd12:/easyre/test % git init .
> Initialized empty Git repository in /easyre/test/.git/
> mqudsi@freebsd12:/easyre/test % git submodule add
> https://github.com/neosmart/pkg-graph
> Cloning into '/easyre/test/pkg-graph'...
> remote: Counting objects: 41, done.
> remote: Compressing objects: 100% (27/27), done.
> remote: Total 41 (delta 16), reused 38 (delta 13), pack-reused 0
> Unpacking objects: 100% (41/41), done.
> mqudsi@freebsd12:/easyre/test % perl
> perl: Command not found.
> mqudsi@freebsd12:/easyre/test % perl5
> perl5: Command not found.
> mqudsi@freebsd12:/easyre/test % fd '^perl$' /
> /easyre/git/perl
> /easyre/git/t/t4034/perl
> mqudsi@freebsd12:/easyre/test % git --version
> git version 2.18.0.rc2.dirty
> mqudsi@freebsd12:/easyre/test %
> ```
> 
> Mahmoud Al-Qudsi
> NeoSmart Technologies



-- 
Michael Gmelin
___
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 Git and M$

[Michael Gmelin]

> On 15. Jun 2018, at 16:26, Dave Horsfall  wrote:
> 
> A related discussion reminded me of this: how would Microsoft's purchase of 
> GitHub affect future development?  After all, they'll get to call the 
> shots...[*]  The only good thing that came out of M$ is their RTF document 
> format (used natively by the Mac's TextEdit utility, for example), which 
> being plain ASCII can be edited directly if necessary (and I have).
> 
> I've been looking at BitKeeper, for example, the author of which (Larry 
> McEvoy) I happen to know from another mailing list.  Apparently, converting 
> from Git is as simple as: "git fast-export | bk fast-import".
> 
> And no, before some here accuse me of being a shill for BK, I have nothing to 
> do with the product whatsoever, other than as someone looking for an 
> alternative to something now owned by M$ (and I've used just about everything 
> since SCCS).
> 

github != git


> [*]
> Remember their motto: "Embrace, extend, extinguish".
> 
> -- Dave, who has been called paranoid before
> ___
> 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: Of Git and M$

[Michael Gmelin]

> On 15. Jun 2018, at 18:37, Dave Horsfall  wrote:
> 
>> On Fri, 15 Jun 2018, Michael Gmelin wrote:
>> 
>> github != git
> 
> I didn't say that it was; did you misunderstand my message or something?

> someone looking for an alternative to something now owned by M$

Your email sounded like you’re looking for an alternative to git because MS 
bought github. As git doesn’t require github (and there are alternatives to 
that too, including hosting a git repo yourself) your logic didn’t add up and I 
assumed you thought that owning github means owning git, which is not the case.

-m

> 
> -- Dave
> ___
> 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: git checkout branch in makefile

[Michael Gmelin]

> On 9. Jul 2018, at 19:34, blubee blubeeme  wrote:
> 
> Is it possible to do a git checkout of a specific branch in a ports
> makefile?
> 
> How would I go about checking out a particular branch from a github project.

As branches aren’t stable this won’t buy you anything, that’s why you should 
always go for a tag or commit (which is branch agnostic).

Michael

> ___
> 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: pkg version is slowwww

[Michael Gmelin]

> On 26. Oct 2018, at 20:03, Steve Kargl  
> wrote:
> 
> I recently updated to pkg-1.10.5_5, and I now
> find to command "pkg version -vl '<'" to be
> much slower than previous versions.
> 
> Four consecutive executions of "time pkg version -vl '<'"
> yields
> 
>  54.15 real27.28 user25.66 sys
>  48.80 real26.04 user23.01 sys
>  48.35 real26.30 user22.59 sys
>  48.43 real26.54 user22.32 sys
> 
> During one of these timings, top(1) shows
> 
> 47519 root1  -8021M12M piperd   0   0:00   0.20% pkg
> 
> Is slow down expected?
> 
> Note, "time pkg info" gives
> 
>0.01 real 0.00 user 0.00 sys
> 

What is the timing when using “-R” and when using “-I”?

Michael


> -- 
> Steve
> ___
> 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: Best way to deal with .pyc files?

[Michael Gmelin]

> On 6. Dec 2018, at 19:21, John Baldwin  wrote:
> 
> The devel/gdb port installs python scripts into 
> /usr/local/share/gdb/python.
> If you then run kgdb as root (not that unusual), it will generate .pyc files 
> in
> those directories that are not deleted by 'pkg delete'.  What is the best way 
> to
> handle this case?  Should the pkg-plist include @rmtry entries for each pyc
> file or is there a better way?

Pre-generate the pyc files on package build and install them with the port, so 
they become part of plist (there are examples of that in the ports tree, 
whenever possible for both py27 and py3x).

Best,
Michael


> -- 
> John Baldwin
> 
> 
> ___
> 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: force github file extension for fetch? (tar.bz2 instead of tar.gz)

[Michael Gmelin]

> On 3. Jun 2019, at 19:03, Gary Aitken  wrote:
> 
> In attempting to build a new port (prusa3d slicer) I need another new
> port (wxWidgets).  The original distfile fetch of wxWidgets was a .tar.gz.
> The configure phase had an error; a search for the source of the error
> turned up a bug (old) which claimed the error was solved by fetching the
> distfile as a .tar.bz2.
> .tar.bz2 is the github *nix distfile for the port.
> 
> Is it possible to force fetching of .tar.bz2 instead of .tar.gz if both are
> available?  Or how does one get around the problem?
> 
> 11.2-RELEASE-p4
> relevant Makefile details:
> 
> PORTNAME=   wxwidgets
> DISTVERSIONPREFIX=  v
> DISTVERSION=3.1.2
> USE_GITHUB= yes
> GH_ACCOUNT= wxWidgets
> GH_PROJECT= wxWidgets
> 

See 5.4.5 in the porters handbook (EXTRACT_SUFX)

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html

-m


> Thanks,
> 
> Gary
> ___
> 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: force github file extension for fetch? (tar.bz2 instead of tar.gz)

[Michael Gmelin]

On Mon, 3 Jun 2019 12:46:32 -0600
Gary Aitken  wrote:

> On 6/3/19 11:19 AM, Michael Gmelin wrote:
> > 
> >   
> >> On 3. Jun 2019, at 19:03, Gary Aitken 
> >> wrote:
> >>
> >> In attempting to build a new port (prusa3d slicer) I need another
> >> new port (wxWidgets).  The original distfile fetch of wxWidgets
> >> was a .tar.gz. The configure phase had an error; a search for the
> >> source of the error turned up a bug (old) which claimed the error
> >> was solved by fetching the distfile as a .tar.bz2.
> >> .tar.bz2 is the github *nix distfile for the port.
> >>
> >> Is it possible to force fetching of .tar.bz2 instead of .tar.gz if
> >> both are available?  Or how does one get around the problem?
> >>
> >> 11.2-RELEASE-p4
> >> relevant Makefile details:
> >>
> >> PORTNAME=   wxwidgets
> >> DISTVERSIONPREFIX=  v
> >> DISTVERSION=3.1.2
> >> USE_GITHUB= yes
> >> GH_ACCOUNT= wxWidgets
> >> GH_PROJECT= wxWidgets
> >>  
> > 
> > See 5.4.5 in the porters handbook (EXTRACT_SUFX)
> > 
> > https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html
> >   
> 
> Thanks; unfortunately it doesn't seem to work
> If I set
>EXTRACT_SUFX=   .tar.bz2
> it still fetches .tar.gz
> If I set
>DISTFILES=  wxWidgets-wxWidgets-v3.1.2_GH0.tar.bz2
> it also still fetches .tar.gz
> 
> If I manually fetch the file and set the above variables (separate
> attempts), make makesum will compute the checksum for both files (if
> both are present), but a make extract uses the .gz, not the .bz2
> If I get rid of (rename) the .gz, it ignores the .bz2 and tries to
> fetch the .gz.
> 
> Does EXTRACT_SUFX conflict with USE_GITHUB?
> 

Github support is using _GITHUB_EXTRACT_SUFX (see bsd.sites.mk line
450):

  _GITHUB_REV=0
  _GITHUB_EXTRACT_SUFX=   .tar.gz

So this can't be overridden on purpose.

Are you sure you need a new wxWidgets port though? Won't
x11-toolkits/wxgtk31 be sufficient (see also:
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/using-wx.html
)

-m

> Thanks,
> Gary
> ___
> 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"



-- 
Michael Gmelin
___
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: Clang8 crash on rpi3 at r349989 building openjdk8

[Michael Gmelin]

> On 1. Sep 2019, at 18:07, bob prohaska  wrote:
> 
> On Sun, Sep 01, 2019 at 12:07:15PM +0200, Mika??l Urankar wrote:
 openjdkd11 is not affected by this bug (and it's the 'mixed' mode
 version), if you want to try it  :
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239246
 you'll probably need #237054
>>> It's a happy thought, but openjdk11 seems to be amd64 and i386 only.
>>> I'm on aarch64.
>>> 
>>> Thanks for writing!
>> 
>> Support for jdk11/aarch64 has landed in the ports tree.
> 
> When the present (likely futile) attempt to compile www/firefox ends
> I'll give jdk11 a try on aarch64. 
> 
> IIRC, www/chromium tried to compile java/openjdk8 as a dependency. 
> Will having openjdk11 already built (before attempting www/chromium)
> satisfy the dependency requirement? If more intelligent intervention
> is needed please tell me how.
> 
> Many thanks!

Not sure if it helps, but I had to build ports on the rPI3 last year and ended 
up cross compiling on amd64. I wrote down what I did back then here: 
https://blog.grem.de/sysadmin/FreeBSD-On-rpi3-With-crochet-2018-10-27-18-00.html

Best,
Michael


> bob prohaska
> 
> ___
> 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: Xorg 1.20 no mouse buttons

[Michael Gmelin]



> On 5. Mar 2020, at 14:46, Ronald Klop  wrote:
> 
> Hi,
> 
> I needed "sysctl kern.evdev.rcpt_mask=6" to switch from sysmouse to "hardware 
> mouse". That fixed mouse integration with VirtualBox.
> 
> Still have weird behaviour. Two finger swipe down & up (which normally only 
> scrolls) makes the browser go back. With xev I see that next to logical 
> button 4 & 5 for scrolling this also triggers logical buttons 8 & 9. Swipe 
> down presses 8 & 9 and up releases the buttons. Why?

Hi,

Please check/post the outputs of:
libinput list-devices 
xinput list
xinput list-props 

-m


> Regards,
> Ronald.
> 
> 
>>> On Thu, 27 Feb 2020 19:42:34 +0100, Daniel Morante via freebsd-ports 
>>>  wrote:
>> Roland,
>> Your issue might be related to this bug: 
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244110
>>> On 2/26/2020 5:29 PM, Ronald Klop wrote:
>>> It works again.
>>> Changed back from virtualboxvideo from drm-devel-kmod to the driver from 
>>> virtualbox-ose-additions. But did some other changes at the same time also. 
>>> Not sure yet what happened, but it was integration of the mouse with 
>>> virtualbox which failed somehow.
>>> Regards,
>>> Ronald.
 On Wed, 26 Feb 2020 20:40:14 +0100, Ronald Klop  
 wrote:
 Hello,
 Since my upgrade to Xorg 1.20 things seem to work except that no mouse 
 buttons work. Pointer movement works good still.
 I'm running a fairly recent FreeBSD 13-CURRENT in VirtualBox (On Windows 
 10). The mouse is a touchpad on my Lenovo IdeaPad laptop.
 Previously it worked using fine.
 What can I do or debug to fix this?
 Regards,
 Ronald.
 [23.241]
 X.Org X Server 1.20.7
 X Protocol Version 11, Revision 0
 [23.241] Build Operating System: FreeBSD 13.0-CURRENT amd64
 [23.241] Current Operating System: FreeBSD sjakie 13.0-CURRENT FreeBSD
 13.0-CURRENT #4 r357762M: Sun Feb 16 12:16:08 CET 2020
 builder@sjakie:/data/src/obj-freebsd-current/data/src/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG
  amd64
 [23.241] Build Date: 22 February 2020  07:06:47AM
 [23.241]
 [23.241] Current version of pixman: 0.38.4
 [23.241] Before reporting problems, check http://wiki.x.org
   to make sure that you have the latest version.
 [23.241] Markers: (--) probed, (**) from config file, (==) default
 setting,
   (++) from command line, (!!) notice, (II) informational,
   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
 [23.241] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Feb 24
 19:18:14 2020
 [23.244] (==) Using system config directory
 "/usr/local/share/X11/xorg.conf.d"
 [23.246] (==) No Layout section.  Using the first Screen section.
 [23.246] (==) No screen section available. Using defaults.
 [23.246] (**) |-->Screen "Default Screen Section" (0)
 [23.246] (**) |   |-->Monitor ""
 [23.247] (==) No monitor specified for screen "Default Screen Section".
   Using a default monitor configuration.
 [23.247] (==) Automatically adding devices
 [23.247] (==) Automatically enabling devices
 [23.247] (==) Not automatically adding GPU devices
 [23.247] (==) Max clients allowed: 256, resource mask: 0x1f
 [23.262] (==) FontPath set to:
   /usr/local/share/fonts/misc/,
   /usr/local/share/fonts/TTF/,
   /usr/local/share/fonts/OTF/,
   /usr/local/share/fonts/Type1/,
   /usr/local/share/fonts/100dpi/,
   /usr/local/share/fonts/75dpi/,
   catalogue:/usr/local/etc/X11/fontpath.d
 [23.263] (==) ModulePath set to "/usr/local/lib/xorg/modules"
 [23.263] (II) The server relies on udev to provide the list of input
 devices.
   If no devices become available, reconfigure udev or disable
 AutoAddDevices.
 [23.263] (II) Loader magic: 0x435010
 [23.263] (II) Module ABI versions:
 [23.263] X.Org ANSI C Emulation: 0.4
 [23.263] X.Org Video Driver: 24.1
 [23.263] X.Org XInput driver : 24.1
 [23.263] X.Org Server Extension : 10.0
 [23.263] (--) PCI:*(0@0:2:0) 80ee:beef:: rev 0, Mem @
 0xe000/134217728, BIOS @ 0x/65536
 [23.263] (II) LoadModule: "glx"
 [23.265] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
 [23.292] (II) Module glx: vendor="X.Org Foundation"
 [23.292] compiled for 1.20.7, module version = 1.0.0
 [23.292] ABI class: X.Org Server Extension, version 10.0
 [23.292] (==) Matched vboxvideo as autoconfigured driver 0
 [23.292] (==) Matched modesetting as autoconfigured driver 1
 [23.292] (==) Matched scfb as autoconfigured driver 2
 [23.292] (==) Matched vesa as autoconfigured driver 3
 [23.292] (==) Assigned the driver to the xf86ConfigLayout
 [23.292] (II) LoadModule: "vboxvideo"
>>>

Re: Xorg 1.20 no mouse buttons

[Michael Gmelin]

> On 7. Mar 2020, at 10:48, Ronald Klop  wrote:
> 
> On Thu, 05 Mar 2020 23:24:46 +0100, Michael Gmelin  wrote:
> 
>> 
>> 
>>>> On 5. Mar 2020, at 14:46, Ronald Klop  wrote:
>>> 
>>> Hi,
>>> 
>>> I needed "sysctl kern.evdev.rcpt_mask=6" to switch from sysmouse to 
>>> "hardware mouse". That fixed mouse integration with VirtualBox.
>>> 
>>> Still have weird behaviour. Two finger swipe down & up (which normally only 
>>> scrolls) makes the browser go back. With xev I see that next to logical 
>>> button 4 & 5 for scrolling this also triggers logical buttons 8 & 9. Swipe 
>>> down presses 8 & 9 and up releases the buttons. Why?
>> 
>> Hi,
>> 
>> Please check/post the outputs of:
>> libinput list-devices
>> xinput list
>> xinput list-props 
> 
> See atttachments. "unnamed" is the vboxmouse driver which comes with the 
> virtualbox-ose-additions pkg.

What do you see when running

xev

libinput debug-events

while two-finger scrolling?

Do you see XF86Back and XF86Forward events?

-m

> Ronald.
> 
> 
> 
> 
>> 
>> -m
>> 
>> 
>>> Regards,
>>> Ronald.
>>> 
>>> 
>>>>> On Thu, 27 Feb 2020 19:42:34 +0100, Daniel Morante via freebsd-ports 
>>>>>  wrote:
>>>> Roland,
>>>> Your issue might be related to this bug: 
>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244110
>>>>> On 2/26/2020 5:29 PM, Ronald Klop wrote:
>>>>> It works again.
>>>>> Changed back from virtualboxvideo from drm-devel-kmod to the driver from 
>>>>> virtualbox-ose-additions. But did some other changes at the same time 
>>>>> also. Not sure yet what happened, but it was integration of the mouse 
>>>>> with virtualbox which failed somehow.
>>>>> Regards,
>>>>> Ronald.
>>>>>> On Wed, 26 Feb 2020 20:40:14 +0100, Ronald Klop  
>>>>>> wrote:
>>>>>> Hello,
>>>>>> Since my upgrade to Xorg 1.20 things seem to work except that no mouse 
>>>>>> buttons work. Pointer movement works good still.
>>>>>> I'm running a fairly recent FreeBSD 13-CURRENT in VirtualBox (On Windows 
>>>>>> 10). The mouse is a touchpad on my Lenovo IdeaPad laptop.
>>>>>> Previously it worked using fine.
>>>>>> What can I do or debug to fix this?
>>>>>> Regards,
>>>>>> Ronald.
>>>>>> [23.241]
>>>>>> X.Org X Server 1.20.7
>>>>>> X Protocol Version 11, Revision 0
>>>>>> [23.241] Build Operating System: FreeBSD 13.0-CURRENT amd64
>>>>>> [23.241] Current Operating System: FreeBSD sjakie 13.0-CURRENT 
>>>>>> FreeBSD
>>>>>> 13.0-CURRENT #4 r357762M: Sun Feb 16 12:16:08 CET 2020
>>>>>> builder@sjakie:/data/src/obj-freebsd-current/data/src/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG
>>>>>>  amd64
>>>>>> [23.241] Build Date: 22 February 2020  07:06:47AM
>>>>>> [23.241]
>>>>>> [23.241] Current version of pixman: 0.38.4
>>>>>> [23.241] Before reporting problems, check http://wiki.x.org
>>>>>>  to make sure that you have the latest version.
>>>>>> [23.241] Markers: (--) probed, (**) from config file, (==) default
>>>>>> setting,
>>>>>>  (++) from command line, (!!) notice, (II) informational,
>>>>>>  (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>>>>>> [23.241] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Feb 24
>>>>>> 19:18:14 2020
>>>>>> [23.244] (==) Using system config directory
>>>>>> "/usr/local/share/X11/xorg.conf.d"
>>>>>> [23.246] (==) No Layout section.  Using the first Screen section.
>>>>>> [23.246] (==) No screen section available. Using defaults.
>>>>>> [23.246] (**) |-->Screen "Default Screen Section" (0)
>>>>>> [23.246] (**) |   |-->Monitor ""
>>>>>> [23.247] (==) No monitor specified for screen "Default Screen 
>>>>>> Section".
>>>>>>  Using a default monitor configuration.
>>>>>> [23.247] (==) Automatically adding

Re: Pkg repository is broken...

[Michael Gmelin]

On Sat, 07 Mar 2020 10:10:43 +0100
"Ronald Klop"  wrote:

> On Sat, 07 Mar 2020 01:38:55 +0100, Greg 'groggy' Lehey
>  wrote:
> 
> > On Friday,  6 March 2020 at 12:29:44 +0100, Lars Engels wrote:  
> >> On Wed, Mar 04, 2020 at 03:16:14PM +1100, Greg 'groggy' Lehey
> >> wrote:  
> >>>
> >>> Any workarounds in the meantime?  This must affect a lot of
> >>> people, including those who use 12-:
> >>>
> >>>   pkg: wrong architecture: FreeBSD:12.0:amd64 instead of  
> >>> FreeBSD:12:amd64
> >>>   pkg: repository FreeBSD contains packages with wrong ABI:  
> >>> FreeBSD:12.0:amd64  
> >>
> >> Still broken for me on 12.1.  
> >
> > Strange.  Mine cleared up automatically the following day.
> >
> > It's also strange how few replies I have received.  Two private
> > messages (why?), yours, and that was it.  You'd think that people
> > would be screaming.
> >
> > Greg  
> 
> 
> I'm not screaming because I'm settling with the situation and
> starting to make workarounds.
> And wondering where the official communication of the community is.  
> Nothing about this situation on www.freebsd.org. All information
> about the situation seems scattered through the mailinglists.
> 
> Things are working for me on 13-CURRENT again, but still broken on  
> 12.1-RELEASE. See attachment.
> 

I worked around the situation locally by setting ALTABI
on `pkg update':

  # ALTABI=FreeBSD:12.0:amd64 pkg update -f

This allowed me to run

  # pkg upgrade

without any issues, so I assume none of the about 30 packages I updated
contained a wrong ABI/architecture.

I verified this by checking:

  # pkg query "%q" | sort | uniq -c
   112 FreeBSD:12:*
   219 FreeBSD:12:amd64

Note that you could also export ALTABI to the environment or set it
in /usr/local/etc/pkg.conf, but I figured that I might forget it in
there.

Also, it seems like none of my packages were affected and not setting
it on `pkg upgrade' meant that pkg checks for that (at least that's
what I assume it does) and therefore I won't have to deal with
different ABIs in my installed packages later.

All of this should be really temporary anyway and hopefully be resolved
soon.

Cheers,
Michael

-- 
Michael Gmelin
___
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: Xorg 1.20 no mouse buttons

[Michael Gmelin]

On Sat, 07 Mar 2020 10:48:05 +0100
"Ronald Klop"  wrote:

> On Thu, 05 Mar 2020 23:24:46 +0100, Michael Gmelin 
> wrote:
> 
> > 
> >  
> >> On 5. Mar 2020, at 14:46, Ronald Klop  wrote:
> >>
> >> Hi,
> >>
> >> I needed "sysctl kern.evdev.rcpt_mask=6" to switch from sysmouse
> >> to "hardware mouse". That fixed mouse integration with VirtualBox.
> >>
> >> Still have weird behaviour. Two finger swipe down & up (which
> >> normally only scrolls) makes the browser go back. With xev I see
> >> that next to logical button 4 & 5 for scrolling this also triggers
> >> logical buttons 8 & 9. Swipe down presses 8 & 9 and up releases
> >> the buttons. Why?  
> >
> > Hi,
> >
> > Please check/post the outputs of:
> > libinput list-devices
> > xinput list
> > xinput list-props   
> 
> See atttachments. "unnamed" is the vboxmouse driver which comes with
> the virtualbox-ose-additions pkg.
> 

I reproduced the problem here in virtualbox (on a MacBook +
12.1-RELEASE, but close enough). Note that I didn't need the vmmouse
driver to reproduce it. It also doesn't seem to come with the
virtualbox-ose-additions package [anymore]?!

That said:
I could see the issue you're talking about when two finger scrolling
sideways - this means, if I'm not scrolling 100% straight. When running
xev and being really focused to move two fingers vertically, I don't get
buttons 8 and 9. This is not practical though and I can see why you're
annoyed by that.

Fortunately, buttons 8 and 9 can be disabled quite easily:

  # xinput set-button-map 9 1 2 3 4 5 6 7 0 0

This is for device id 9 (intellimouse), which did the trick in my setup.

In case device id 10 is relevant in your setup, you can also try:

  # xinput set-button-map 10 1 2 3 4 5 6 7 0 0

And in case of 11 (this is the one from the vmmouse driver):

  # xinput set-button-map 11 1 2 3 4 5 6 7 0 0

You can verify that the setting caught on by calling:

  # xinput get-button-map 

If this does the trick for you, you can simply put it into your
~/.xinitrc to set it automatically on startx.

Cheers,
Michael


-- 
Michael Gmelin
___
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 repository is broken...

[Michael Gmelin]

On Sat, 07 Mar 2020 11:30:58 -0400
Waitman Gobble  wrote:

> On 2020-03-07 05:10, Ronald Klop wrote:
> > On Sat, 07 Mar 2020 01:38:55 +0100, Greg 'groggy' Lehey
> >  wrote:
> >   
> >> On Friday,  6 March 2020 at 12:29:44 +0100, Lars Engels wrote:  
> >>> On Wed, Mar 04, 2020 at 03:16:14PM +1100, Greg 'groggy' Lehey
> >>> wrote:  
> >>>> 
> >>>> Any workarounds in the meantime?  This must affect a lot of
> >>>> people, including those who use 12-:
> >>>> 
> >>>>   pkg: wrong architecture: FreeBSD:12.0:amd64 instead of 
> >>>> FreeBSD:12:amd64
> >>>>   pkg: repository FreeBSD contains packages with wrong ABI: 
> >>>> FreeBSD:12.0:amd64  
> >>> 
> >>> Still broken for me on 12.1.  
> >> 
> >> Strange.  Mine cleared up automatically the following day.
> >> 
> >> It's also strange how few replies I have received.  Two private
> >> messages (why?), yours, and that was it.  You'd think that people
> >> would be screaming.
> >> 
> >> Greg  
> > 
> > 
> > I'm not screaming because I'm settling with the situation and
> > starting to make workarounds.
> > And wondering where the official communication of the community is.
> > Nothing about this situation on www.freebsd.org. All information
> > about the situation seems scattered through the mailinglists.
> > 
> > Things are working for me on 13-CURRENT again, but still broken on
> > 12.1-RELEASE. See attachment.
> > 
> > Ronald.
> > ___
> > freebsd-curr...@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to 
> > "freebsd-current-unsubscr...@freebsd.org"  
> 
> 
> Did you try:
> pkg update -f
> 
> 
> I installed 12.1 on a new laptop yesterday, I have not experienced 
> issues with pkg.
> 

This was only an issue on the "latest" branch. If you don't alter
"/etc/pkg/FreeBSD.conf", you'll get packages from the "quarterly"
branch, which fortunately wasn't affected.

Anyway, this has been fixed as of today 13:30 UTC, see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244549#c43

-m

-- 
Michael Gmelin
___
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 repository is broken...

[Michael Gmelin]

> On 7. Mar 2020, at 23:39, Greg 'groggy' Lehey  wrote:
> 
> On Saturday,  7 March 2020 at 16:46:58 +0100, Michael Gmelin wrote:
> 
> [much irrelevant text deleted]
> 
> People, please trim your replies.  Only relevant text should remain
> 
>>> On Sat, 07 Mar 2020 11:30:58 -0400 Waitman Gobble  
>>> wrote:
>>> 
>>> I installed 12.1 on a new laptop yesterday, I have not experienced
>>> issues with pkg.
>> 
>> This was only an issue on the "latest" branch. If you don't alter
>> "/etc/pkg/FreeBSD.conf", you'll get packages from the "quarterly"
>> branch, which fortunately wasn't affected.
> 
> No, this isn't necessarily correct.  I have never modified this file,
> but I ended up with a copy of /usr/src/usr.bin/pkg/FreeBSD.conf.latest
> with this revision string:
> 
>  # $FreeBSD: stable/11/etc/pkg/FreeBSD.conf 263937 2014-03-30 15:24:17Z 
> bdrewery $
> 
> Despite the age, this appears to identical to the current version,
> according to svn blame.  Arguably this should be the default anyway.
> 

Installing 12.1 from install media gives you quarterly.

-m


> Greg
> --
> Sent from my desktop computer.
> Finger g...@freebsd.org for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA

___
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 repository is broken...

[Michael Gmelin]

> On 8. Mar 2020, at 00:04, Greg 'groggy' Lehey  wrote:
> 
> On Saturday,  7 March 2020 at 23:55:33 +0100, Michael Gmelin wrote:
> 
> [More irrelevant text deleted, also dropping current@]
> 
> Is it really so difficult to trim your replies?
> 
>>>>>> On 7. Mar 2020, at 23:39, Greg 'groggy' Lehey  wrote:
>>>>> ???On Saturday,  7 March 2020 at 16:46:58 +0100, Michael Gmelin wrote:
>>>>>> This was only an issue on the "latest" branch. If you don't alter
>>>>>> "/etc/pkg/FreeBSD.conf", you'll get packages from the "quarterly"
>>>>>> branch, which fortunately wasn't affected.
>>>>> No, this isn't necessarily correct.  I have never modified this file,
>>>>> but I ended up with a copy of /usr/src/usr.bin/pkg/FreeBSD.conf.latest
>>>>> with this revision string:
>>>>> # $FreeBSD: stable/11/etc/pkg/FreeBSD.conf 263937 2014-03-30 15:24:17Z 
>>>>> bdrewery $
>>>>> Despite the age, this appears to identical to the current version,
>>>>> according to svn blame.  Arguably this should be the default anyway.
>> Installing 12.1 from install media gives you quarterly.
> 
> Yes, quite possibly.  But as I said, it's not always the case.

In the part you trimmed he wrote:

>>>>>> I installed 12.1 on a new laptop yesterday, I have not experienced
>>>>>> issues with pkg.

my comment

>>>>> 
>>>>> This was only an issue on the "latest" branch. If you don't alter
>>>>> "/etc/pkg/FreeBSD.conf", you'll get packages from the "quarterly"
>>>>> branch, which fortunately wasn't affected.
>>>>> 

was a direct response to that (fresh install of a 12.1 system). This obviously 
doesn’t necessarily apply to systems that have been updated from previous 
releases.

-m




___
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 security/swatch

[Michael Gmelin]

> On 15. Mar 2020, at 18:10, Andrea Venturoli  wrote:
> 
> Hello.
> 
> I'm using security/swatch to look *in real time* for specific strings in my 
> logs, but now it's deprecated because it's unfetchable.
> 
> Can someone suggest an alternative?
> 
> N.B. I'm not looking for something that will parse logs at specified times 
> (e.g. run from cron); I already have logcheck.
> I'm using swatch, in addition to that, to look for things that require 
> immediate attention, by piping syslogd into it.
> 
> Bonus for not requiring too many dependencies :)

swatch is still available as a new version on sourceforge (3.2.4). So someone 
(maybe the maintainer, put him on Cc), could update/unbreak the port.

Maybe I’ll take a look myself later, would you be willing to test?

-m


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

___
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 security/swatch

[Michael Gmelin]

On Sun, 15 Mar 2020 18:26:53 +0100
Andrea Venturoli  wrote:

> On 2020-03-15 18:16, Michael Gmelin wrote:
> 
> > swatch is still available as a new version on sourceforge (3.2.4).  
> 
> Hmm...
>  From the port, website is here:
> > http://swatch.sourceforge.net/  
> Nothing to download, it seems, from there.
> 
> There's also:
> https://sourceforge.net/p/swatch/
> It was last updated in 2015, though and there are a lot of open
> issues.
> 
> I'm not sure it's still developed...
> 
> 
> 
> > So someone (maybe the maintainer, put him on Cc), could
> > update/unbreak the port.  
> 
> I don't think I have the expertise to do this, as I'm totally
> ignorant in PERL.
> 
> 
> 
> > Maybe I’ll take a look myself later, would you be willing to test?  
> 
> Of course I would!
> 

Hi Andrea,

The project was renamed from "swatch" to "swatchdog", I renamed it in
the ports tree to match upstream and updated it to 3.2.4. Please note
that everything inside was renamed to swatchdog, including the service
script and variable prefixes in /etc/rc.conf.

You can install it using

portsnap fetch update
cd /usr/ports/security/swatchdog
make install clean

(deinstall swatch beforehand)

Cheers,
Michael

-- 
Michael Gmelin
___
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: reccomendations of conference / party audio video software ?

[Michael Gmelin]

On Wed, 25 Mar 2020 00:14:01 +1100
Kubilay Kocak  wrote:

> On 24/03/2020 9:31 pm, Baptiste Daroussin wrote:
> > On Sat, Mar 21, 2020 at 04:38:11PM +, Bob Eager wrote:  
> >> People have been saying good things about jitsi (Java based) bu the
> >> port didn't work on a quick try (my ports tree isn't very new
> >> though and there was no time to update it).
> >>  
> > The port is about a previous thing from jitsi (a SIP client) when
> > people speak about Jitsi c'est speak about https://meet.jit.si aka
> > https://jitsi.org/
> > 
> > The video bridge is in java and the frontend is in javascript with
> > desktop apps iirc for those who do not want to use a browser. Note
> > that on freebsd desktops it works well in firefox browser.
> > 
> > No login required, no decidated required it just works fine.
> > 
> > There is no port yet of the server part on freebsd but should not
> > be hard to do as it is fully opensource.  
> 
> Working on it already
> 

Please let me know if you make progress/need help testing.

-m

-- 
Michael Gmelin
___
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: Linux-foldingathome

[Michael Gmelin]

Based on the error message I assume you have to mount procfs (and maybe 
linprocfs), See the respective man pages.

You also have to enable Linux support (sysrc linux_enable=YES ; service linux 
start).

-m

> On 7. Apr 2020, at 14:33, @lbutlr  wrote:
> 
> Has anyone had any experience with installing the port 
> biology/linux-foldingathome?
> 
> After installing it and editing the configuration file I try to start it and 
> get the following:
> 
> # service fahclient start
> Starting fahclient.
> 13:33:52:WARNING:Exception: Failed to open '/proc/bus/pci/devices': Failed to 
> open '/proc/bus/pci/devices': No such file or directory: No such file or 
> directory
> 13:33:52:ERROR:Exception: Could not read link /proc/self/exe
> /usr/local/etc/rc.d/fahclient: WARNING: failed to start fahclient
> 
> /proc/ is empty.
> 
> There were no errors when installing the port.
> 
> # kldstat
> Id Refs AddressSize Name
> 1   57 0x8020  2448d90 kernel
> 21 0x82649000   3a99a8 zfs.ko
> 32 0x829f3000 a5b8 opensolaris.ko
> 41 0x82f11000 4260 ng_ubt.ko
> 56 0x82f16000 9e30 netgraph.ko
> 62 0x82f2 91b8 ng_hci.ko
> 73 0x82f2a000  9c0 ng_bluetooth.ko
> 81 0x82f2b000 cad0 ng_l2cap.ko
> 91 0x82f380001ba00 ng_btsocket.ko
> 101 0x82f54000 21c0 ng_socket.ko
> 111 0x82f57000  acf mac_ntpd.ko
> 121 0x82f58000 18a0 uhid.ko
> 131 0x82f5a000 1aa0 wmt.ko
> 141 0x82f5c000 2928 ums.ko
> 151 0x82f5f00035b20 linux64.ko
> 163 0x82f95000 3178 linux_common.ko
> 171 0x82f99000 494c linprocfs.ko
> 181 0x82f9e000 1eae linsysfs.ko
> 
> 
> -- 
> Traveling through hyperspace ain't like dusting crops, boy.
> 
> 
> ___
> 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: LibreOffice 6.4.4 is coming!

[Michael Gmelin]

> On 11. Jun 2020, at 17:10, Dima Panov  wrote:
> 
> Hello!
> 
> We know, all FreeBSD users waits for new release of LireOffice.
> And now it almost here.
> But before land it to the ports, we want to inform community about some 
> important changes to build options.
> 
> At first, GTK3 option is not more set by default and there are the reasons:
> a) our gtk30 port and all needed gnome dependencies are dramatically outdated
> b) LibreOffice64’s gtk3 visual content library is broken — missed critical 
> buttons, dropdown menus, scrollbars
> c) previously uses gtk2 vcl is dropped upstream since LibreOffice 6.4.0 is 
> branched
> 
> Second, we decided to make QT5 VCL option is set by default to provide comfy 
> visual style for every users. One small note — since upcoming Qt5-5.15 will 
> drop binary support for FreeBSD 11.x due to outdated OpenSSL 1.0 in base, 
> here is not reason to enable QT5 option on FreeBSD <12+ by default.
> 
> Release will be landed to the ports at this weekend.
> 
> Early access, as always, available at out WIP stage on GitHub:
> https://github.com/lwhsu/freebsd-ports-libreoffice
> 
> Discussions, patches, proposals are welcome.
> 
> We're sorry for the inconvenience.
> 

Thanks for the notice and your work, much appreciated.

-m


___
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: cups-pdf crash status -139

[Michael Gmelin]

> On 15. Jun 2020, at 09:45, Per olof Ljungmark  wrote:
> 

What happens if you run the gs command on the pdf you’re printing directly:


> gs -q -dNOPAUSE -dBATCH -dSAFER -dNOMEDIAATTRS -sstdout=? -sDEVICE=ps2write 
> -dShowAcroForm -sOUTPUTFILE=? -dLanguageLevel=2 -r300 -dCompressFonts=false 
> -dNoT3CCITT -dNOINTERPOLATE ? ? -f ?

Cheers,
Michael


___
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: cups-pdf crash status -139

[Michael Gmelin]

On Mon, 15 Jun 2020 12:03:17 +0200
Per olof Ljungmark  wrote:

> On 2020-06-15 09:50, Michael Gmelin wrote:
> > 
> >   
> >> On 15. Jun 2020, at 09:45, Per olof Ljungmark 
> >> wrote: 
> > 
> > What happens if you run the gs command on the pdf you’re printing
> > directly:
> > 
> >   
> >> gs -q -dNOPAUSE -dBATCH -dSAFER -dNOMEDIAATTRS -sstdout=?
> >> -sDEVICE=ps2write -dShowAcroForm -sOUTPUTFILE=? -dLanguageLevel=2
> >> -r300 -dCompressFonts=false -dNoT3CCITT -dNOINTERPOLATE ? ? -f ?  
> 
> A PDF is created.
> 
> And, according to logs gs is OK:
> 
> D [15/Jun/2020:09:16:23 +0200] [Job 1070] Wrote 1 pages...
> D [15/Jun/2020:09:16:23 +0200] [Job 1070] PID 37126 (pstops) exited
> with no errors.
> D [15/Jun/2020:09:16:23 +0200] [Job 1070] PID 37125 (gs) exited with
> no errors.
> D [15/Jun/2020:09:16:23 +0200] [Job 1070] PID 37123 
> (/usr/local/libexec/cups/filter/pdftops) exited with no errors.
> I [15/Jun/2020:09:16:23 +0200] [Job 1070] Backend returned status
> -139 (crashed)

Are you printer(s) shown as okay in the cups web UI? (like, not
temporarily halted, stopped, etc.?). I sometimes had some issues after
upgrading, especially with hplip.

This upstream issue reported earlier this year sounds similar to what
you're seeing, maybe it helps: https://github.com/apple/cups/issues/5765

-m

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

Re: FreeBSD Port: phabricator-php73-20200514_1

[Michael Gmelin]

> On 16. Jun 2020, at 08:41, Fabian Abplanalp - Legatech GmbH 
>  wrote:
> 
> Hi
> 
> Since we updated the Port to 20200514_1 we can't create milestones anymore 
> with the following information... Is there anything known about that problem 
> or should we place a bugreport at phabricator?
> 
> Reproducible case (on our phab-test):
> 
> Get PHID of the project where I want to add a milestone:
> https://phab-test.neratec.com/conduit/method/phid.lookup/
> names: ["#software_team"]
> result:
> { "#software_team":
>   { "phid": "PHID-PROJ-32jtopr6klyrrpxe3pow",
> "uri": "https://phab-test.neratec.com/tag/software_team/";,
> "typeName": "Project",
> "type": "PROJ",
> "name": "Software Team",
> "fullName": "Software Team",
> "status": "open"
>   }
> }
> Try to create milestone of "Software Team" project
> https://phab-test.neratec.com/conduit/method/project.edit/
> transactions: 
> [{"type":"milestone","value":"PHID-PROJ-32jtopr6klyrrpxe3pow"},{"type":"name","value":"2020.15"},{"type":"description","value":"=
>  Sprint 2020.15"}]
> Conduit > Unhandled Exception ("Error")
> Call to a member function getPHID() on null
> Error on server shows: EXCEPTION: (Error) Call to a member function getPHID() 
> on null at 
> [/src/applications/project/editor/PhabricatorProjectTransactionEditor.php:358]
> 

Based on staring at the code[0], my wild guess is that your conduit user has no 
or insufficient access to the parent project (above the code referenced a copy 
of parent is created and adjusted for permissions).

The ticket referenced in the code can be found here[1].

Best,
Michael

[0] 
https://github.com/phacility/phabricator/blob/d203a1004c7509109fccdf526e9941b89eeef662/src/applications/project/editor/PhabricatorProjectTransactionEditor.php#L349

[1] https://secure.phabricator.com/T13462

> 
> -- 
> Fabian Abplanalp
> Senior IT System Administrator
> 
> Legatech GmbH
> Etzelstrasse 14
> 8634 Hombrechtikon
> Switzerland
> Tel 055 244 36 39 / https://www.legatech.ch
___
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: cups-pdf crash status -139

[Michael Gmelin]

> On 16. Jun 2020, at 11:47, Per olof Ljungmark  wrote:
> 
> On 2020-06-15 16:14, Michael Gmelin wrote:
>>> On Mon, 15 Jun 2020 12:03:17 +0200
>>> Per olof Ljungmark  wrote:
>>> On 2020-06-15 09:50, Michael Gmelin wrote:
>>>> 
>>>>   
>>>>> On 15. Jun 2020, at 09:45, Per olof Ljungmark 
>>>>> wrote:
>>>> 
>>>> What happens if you run the gs command on the pdf you’re printing
>>>> directly:
>>>> 
>>>>   
>>>>> gs -q -dNOPAUSE -dBATCH -dSAFER -dNOMEDIAATTRS -sstdout=?
>>>>> -sDEVICE=ps2write -dShowAcroForm -sOUTPUTFILE=? -dLanguageLevel=2
>>>>> -r300 -dCompressFonts=false -dNoT3CCITT -dNOINTERPOLATE ? ? -f ?
>>> 
>>> A PDF is created.
>>> 
>>> And, according to logs gs is OK:
>>> 
>>> D [15/Jun/2020:09:16:23 +0200] [Job 1070] Wrote 1 pages...
>>> D [15/Jun/2020:09:16:23 +0200] [Job 1070] PID 37126 (pstops) exited
>>> with no errors.
>>> D [15/Jun/2020:09:16:23 +0200] [Job 1070] PID 37125 (gs) exited with
>>> no errors.
>>> D [15/Jun/2020:09:16:23 +0200] [Job 1070] PID 37123
>>> (/usr/local/libexec/cups/filter/pdftops) exited with no errors.
>>> I [15/Jun/2020:09:16:23 +0200] [Job 1070] Backend returned status
>>> -139 (crashed)
>> Are you printer(s) shown as okay in the cups web UI? (like, not
>> temporarily halted, stopped, etc.?). I sometimes had some issues after
>> upgrading, especially with hplip.
>> This upstream issue reported earlier this year sounds similar to what
>> you're seeing, maybe it helps: https://github.com/apple/cups/issues/5765
> 
> The cups-pdf printer is paused with "Backend failed" but all other printers 
> are OK. HPLIP is not installed.
> 

Can you enable the cups-pdf printer using the “cupsenable” command? And if so, 
will it stay enabled or go back to paused/failed at the next attempt?

Cheers,
Michael



> The info from the link you sent looks related although the configs are not 
> the same, but it is an interesting lead that I will pursue further. There is 
> a severe lack of debug info though, the error_log is not helpful at all.
> 
> Also, that thread is dated April 6 which is about the same time that the 
> problem showed up here too.
> 
> Thanks,
> 
> Per
> ___
> 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: cups-pdf crash status -139

[Michael Gmelin]

On Wed, 17 Jun 2020 09:43:35 +0200
Per olof Ljungmark  wrote:

> On 2020-06-16 12:15, Michael Gmelin wrote:
> > 
> >   
> >> On 16. Jun 2020, at 11:47, Per olof Ljungmark 
> >> wrote:
> >>
> >> On 2020-06-15 16:14, Michael Gmelin wrote:  
> >>>> On Mon, 15 Jun 2020 12:03:17 +0200
> >>>> Per olof Ljungmark  wrote:
> >>>> On 2020-06-15 09:50, Michael Gmelin wrote:  
> >>>>>
> >>>>>  
> >>>>>> On 15. Jun 2020, at 09:45, Per olof Ljungmark 
> >>>>>> wrote:  
> >>>>>
> >>>>> What happens if you run the gs command on the pdf you’re
> >>>>> printing directly:
> >>>>>
> >>>>>  
> >>>>>> gs -q -dNOPAUSE -dBATCH -dSAFER -dNOMEDIAATTRS -sstdout=?
> >>>>>> -sDEVICE=ps2write -dShowAcroForm -sOUTPUTFILE=?
> >>>>>> -dLanguageLevel=2 -r300 -dCompressFonts=false -dNoT3CCITT
> >>>>>> -dNOINTERPOLATE ? ? -f ?  
> >>>>
> >>>> A PDF is created.
> >>>>
> >>>> And, according to logs gs is OK:
> >>>>
> >>>> D [15/Jun/2020:09:16:23 +0200] [Job 1070] Wrote 1 pages...
> >>>> D [15/Jun/2020:09:16:23 +0200] [Job 1070] PID 37126 (pstops)
> >>>> exited with no errors.
> >>>> D [15/Jun/2020:09:16:23 +0200] [Job 1070] PID 37125 (gs) exited
> >>>> with no errors.
> >>>> D [15/Jun/2020:09:16:23 +0200] [Job 1070] PID 37123
> >>>> (/usr/local/libexec/cups/filter/pdftops) exited with no errors.
> >>>> I [15/Jun/2020:09:16:23 +0200] [Job 1070] Backend returned status
> >>>> -139 (crashed)  
> >>> Are you printer(s) shown as okay in the cups web UI? (like, not
> >>> temporarily halted, stopped, etc.?). I sometimes had some issues
> >>> after upgrading, especially with hplip.
> >>> This upstream issue reported earlier this year sounds similar to
> >>> what you're seeing, maybe it helps:
> >>> https://github.com/apple/cups/issues/5765  
> >>
> >> The cups-pdf printer is paused with "Backend failed" but all other
> >> printers are OK. HPLIP is not installed. 
> > 
> > Can you enable the cups-pdf printer using the “cupsenable” command?
> > And if so, will it stay enabled or go back to paused/failed at the
> > next attempt? 
> 
> It reverts to "Backend failed".
> 
> Just tried to add the cups-pdf printer to the 12-STABLE workstation
> I'm writing this on with identical result so by now I see this on
> three different boxes, all running 12-STABLE. Also, I am confident
> that the problem surfaced after the updates to cups in late March.
> 
> If I have the time at some point I could try to revert to an older 
> version but it would be nicer to sort the problem.
> 
> Not sure how to proceed from here...
> 

Could you share your relevant config files, so I can try to reproduce
the problem?

Thanks,
Michael


-- 
Michael Gmelin
___
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: cups-pdf crash status -139

[Michael Gmelin]

On Thu, 18 Jun 2020 08:16:19 +0200
Per olof Ljungmark  wrote:

> On 2020-06-17 23:30, Tatsuki Makino wrote:
> > Hello.
> > 
> > If you want a quick solution, create the following symlink.
> > ln -s /usr/local/etc/cups /etc/cups
> > 
> > There are two bug reports about it.
> > Bug 244530, 246955.
> > 244530 also describes how to fix it.
> > 
> > If the queue gets corrupted, use the following command to delete
> > them all. /usr/local/bin/cancel -a -x  
> 
> Thank you for pointing this out, problem solved.
> 

Good to hear, big thanks to Tatsuki for helping before I invested a lot
of time.

Cheers,
Michael

-- 
Michael Gmelin
___
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 maintenance

[Michael Gmelin]

> On 29. Jun 2020, at 00:18, Brandon helsley  
> wrote:
> 
> 
> 
> 
> 
> 
> I'm getting started reading the porters handbook. I was wondering if I can 
> adopt a port to practice maintaining one without the experience to keep it 
> properly updated at first. I'm a little intimidated by contributing and not 
> sure how best to learn the porters handbook. I guess read it multiple times?
> 
> 

Just pick a port that’s unmaintained and that you’re actually using yourself 
(ideally on a daily basis). When you do changes, make sure:

- it builds cleanly in poudriere.
- it passes portlint.
- you follow the porter’s handbook as good as you can, but without freaking out 
about it.

In case you’re uncertain, ask questions on this mailing list.

Open PRs in bugzilla or (in the beginning) reviews in phabricator.

Committers will help you. Either it will work, or you will learn. No one will 
judge you, so no worries.

Cheers,
Michael


> 
> 
> 
> 
> 
> 
> 
> ___
> 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: Port maintenance

[Michael Gmelin]

> On 29. Jun 2020, at 23:20, Brandon helsley  
> wrote:
> 
> Okay, I use the nvidia 390 driver

That one is already maintained by danfe@.

> and nvidia-xsettings

I only see nvidia-xconfig and nvidia-settings, both which have no maintainer.

> , but they both have no maintainer. I read all the material about what the 
> responsibilitys are for a maintainer and I think I can do a couple. I got a 
> message from portscout about a couple of ports that needed updated. I didn't 
> sign up for any yet but could start there. How do I set my email address to 
> maintainer?

Assuming maintainership is done through sending in a patch in form of a PR (the 
handbook describes this).

I would recommend that you first open a few PRs with patches for one or two 
unmaintained ports, then, once you’re comfortable with the process (and 
committers are too, especially when it comes to attention to detail), you open 
a PR to take maintainership.

-m


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

Re: FreeBSD Port: phabricator-php73-20200514_1

[Michael Gmelin]

On Tue, 16 Jun 2020 10:39:30 +0200
Michael Gmelin  wrote:

> > On 16. Jun 2020, at 08:41, Fabian Abplanalp - Legatech GmbH
> >  wrote:
> > 
> > Hi
> > 
> > Since we updated the Port to 20200514_1 we can't create milestones
> > anymore with the following information... Is there anything known
> > about that problem or should we place a bugreport at phabricator?
> > 
> > Reproducible case (on our phab-test):
> > 
> > Get PHID of the project where I want to add a milestone:
> > https://phab-test.neratec.com/conduit/method/phid.lookup/
> > names: ["#software_team"]
> > result:
> > { "#software_team":
> >   { "phid": "PHID-PROJ-32jtopr6klyrrpxe3pow",
> > "uri": "https://phab-test.neratec.com/tag/software_team/";,
> > "typeName": "Project",
> > "type": "PROJ",
> > "name": "Software Team",
> > "fullName": "Software Team",
> > "status": "open"
> >   }
> > }
> > Try to create milestone of "Software Team" project
> > https://phab-test.neratec.com/conduit/method/project.edit/
> > transactions:
> > [{"type":"milestone","value":"PHID-PROJ-32jtopr6klyrrpxe3pow"},{"type":"name","value":"2020.15"},{"type":"description","value":"=
> > Sprint 2020.15"}] Conduit > Unhandled Exception ("Error") Call to a
> > member function getPHID() on null Error on server shows: EXCEPTION:
> > (Error) Call to a member function getPHID() on null at
> > [/src/applications/project/editor/PhabricatorProjectTransactionEditor.php:358]
> >  
> 
> Based on staring at the code[0], my wild guess is that your conduit
> user has no or insufficient access to the parent project (above the
> code referenced a copy of parent is created and adjusted for
> permissions).
> 
> The ticket referenced in the code can be found here[1].
> 
> Best,
> Michael
> 
> [0]
> https://github.com/phacility/phabricator/blob/d203a1004c7509109fccdf526e9941b89eeef662/src/applications/project/editor/PhabricatorProjectTransactionEditor.php#L349
> 
> [1] https://secure.phabricator.com/T13462
> 

Hi Fabian,

I could reproduce the problem locally and found a fix:
https://github.com/grembo/phabricator/commit/0851b89eb6633dd792cd4eb10c26f86c2f0da56a

I also reported it upstream (where there was already a six month old,
unsolved report of that specific problem):
https://discourse.phabricator-community.org/t/call-to-a-member-function-getphid-on-a-non-object-while-creating-milestone-using-conduit/3370/4

I already incorporated it as a patch into the port, so
phabricator-php73-20200514_2 will solve this problem for you.

The new version is committed and should be available over portsnap
for source builds shortly and as a binary package to be used with pkg
within the next couple of days.

Cheers,
Michael

-- 
Michael Gmelin
___
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

[Michael Gmelin]

> On 4. Aug 2020, at 20:43, Steve Wills  wrote:
> 
> 
> We are planning to deprecate use of portsnap in ports.
> 
> The reasons are as follows (in no particular order):
> 
> * Portsnap doesn't support quarterly branches, even years after quarterly 
> branches were created and changed to the default for non-HEAD packages.
> 
> * Portsnap doesn't seem to save disk space compared to svn or git, if you 
> count the metadata (stored in /var/db/portsnap by default) and you do an 
> apples-to-apples comparison of svn or git without history and ignoring 
> possible ZFS compression. That is, you use "svn export" or git "clone --depth 
> 1", you see this disk usage:
> 
>342Msvnexport
>426Mgit
>477Mportsnap
> 
> * Portsnap also doesn't work offline which git does. With git, you can also 
> easily add the history by running "git pull --unshallow"
> 
> * This migration away from portsnap fits well with the planned migration to 
> git.
> 
> * Also based on the patches we've seen in Bugzilla for some time, usage of 
> portsnap causes folks to too easily accidentally submit patches to Bugzilla 
> which don't apply easily.
> 
> * Since portsnap doesn't support quarterly branches, it often causes users to 
> build on the wrong branch or end up with mismatched packages. That is, they 
> install packages from quarterly via pkg, then want to customize so run 
> portsnap and build from head, which can cause problems, as we often see. Even 
> when this doesn't happen, it adds to troubleshooting to verify that it didn't.
> 
> We are aware people have gotten used to portsnap, but believe:
> 
> * People should be able to easily use svnlite in base or git from pkgs. (Very 
> few people seem to actually use WITHOUT_SVNLITE).
> 
> * There is also the possibility of falling back to fetching a tar or zip from 
> https://cgit-beta.freebsd.org/ports/ although this does make updating harder.
> 
> How it will be done, in order:
> 
> * Update poudriere to use svn by default. This is already done:
> 
>  https://github.com/freebsd/poudriere/pull/764
> https://github.com/freebsd/poudriere/commit/bd68f30654e2a8e965fbdc09aad238c8bf5cdc10
> 
> * Update docs not to mention portsnap. This is already in progress:
> 
>  https://reviews.freebsd.org/D25800
>  https://reviews.freebsd.org/D25801
>  https://reviews.freebsd.org/D25803
>  https://reviews.freebsd.org/D25805
>  https://reviews.freebsd.org/D25808
>  https://svnweb.freebsd.org/changeset/base/363798
> 
>  Many thanks to the folks who have worked and are working on this!
> 
> * Make WITHOUT_PORTSNAP default in base. Currently not certain when this will 
> happen. May not happen before 13.0, but hopefully it will.
> 
> * Eventually, portsnap servers will see low enough usage they can be disabled.
> 
> We welcome any constructive feedback. All input would be heard, and if the 
> plans need to be amended, we will come back to you with the amended plan in a 
> couple of weeks. This process will take some time and hopefully won't be too 
> disruptive to anyone's usual workflow.

What will be the process to bootstrap git?

Thanks


> 
> Steve (with portmgr@ hat)
> ___
> 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: [HEADS UP] Planned deprecation of portsnap

[Michael Gmelin]

> On 6. Aug 2020, at 13:58, Mathieu Arnold  wrote:
> 
> On Thu, Aug 06, 2020 at 12:17:37AM +0200, Michael Gmelin wrote:
>>> We welcome any constructive feedback. All input would be heard, and if the 
>>> plans need to be amended, we will come back to you with the amended plan in 
>>> a couple of weeks. This process will take some time and hopefully won't be 
>>> too disruptive to anyone's usual workflow.
>> 
>> What will be the process to bootstrap git?
> 
> pkg install git comes to mind.
> 

I obviously meant bootstrapping without relying on binary packages (for 
multiple reasons) >_<

E.g., pulling a tarball (from a github mirror or some other place) using 
“fetch” to populate an intermediate ports tree to build git/other dependencies. 
Shouldn’t be hard to do and easy to document.

-m




___
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

[Michael Gmelin]

On Fri, 7 Aug 2020 01:24:00 -0400
Steve Wills  wrote:

> Hi,
> 
> On 8/5/20 6:17 PM, Michael Gmelin wrote:
> > 
> > 
> > What will be the process to bootstrap git?
> >   
> 
> There are several options:

Thanks for your response - ideally there would be a lean default way
users can rely on (hence my question, I probably should've injected the
word "standard" in there).

> 
> 1. Install the git package provided by the FreeBSD project
In many cases this is the obvious choice, but in some scenarios not
possible.

> 2. Use svnlite to checkout a ports tree. (There will be git -> svn 
> replication.

Will this be a long-term option? I would very much like that - not for
development, I'm more than happy that I can *finally* use git there in
the future - but to have a chance to get and update a ports tree on
hosts (and inside of jails etc.) without installing git and all its
dependencies:

(typical dependency output from some older host)
git-2.27.0:
p5-CGI-4.47
expat-2.2.8
p5-IO-Socket-SSL-2.068
p5-Authen-SASL-2.16_1
python37-3.7.7
perl5-5.30.3
p5-Error-0.17029
curl-7.70.0_1
pcre-8.44
p5-subversion-1.14.0
p5-Term-ReadKey-2.38_1
gettext-runtime-0.20.2
cvsps-2.1_2

This would also allow to write a simple/lean wrapper that can act as a
drop-in replacement for portsnap, as it doesn't require a special
bootstrap procedure and doesn't install any additional
packages/binaries on the system - therefore existing jail managers and
people's automation won't break.

> 3. Download a tar of the ports tree either from:
>  https://download.freebsd.org/ftp/ports/ports/
> 
> or cgit.

Would work too, but relatively expensive. Also, how often would it be
updated?

Thanks,
Michael

-- 
Michael Gmelin
___
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

[Michael Gmelin]

> On 7. Aug 2020, at 15:26, Steve Wills  wrote:
> 
> Hi,
> .
> I believe that's updated daily and the tars from cgit are generated at least 
> that frequently, if not more.
> 

The real question is: Will we design things in a way that we expect ports tree 
users to always install git and its dependencies on their system or not (long 
term)?

For developers it’s a no-brainer (obviously yes), but ports tree users aren’t 
developers. 

Ideally, from a user perspective, “portsnap fetch/extract/update” would just 
work as it did before (maybe running “portsnap reset/migrate” once after the 
change).

Cheers,
Michael


___
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

[Michael Gmelin]

> On 10. Aug 2020, at 16:22, Steve Wills  wrote:
> 
> Hi,
> 
>> On 8/10/20 9:28 AM, Lars Engels wrote:
>> On Tue, Aug 04, 2020 at 02:43:20PM -0400, Steve Wills wrote:
>> I'm probably fine with this and I think that all of the (now) supported
>> methods have pros and cons.
>> To leverage the UX flaws of git and svn(lite) compared to portsnap
>> having a wrapper script around the two tools would be very appreciated.
>> Something like
>> # portsnap-ng --mode git --branch 2020Q2 --destination /ports/2020Q2 fetch 
>> extract
>>   The package devel/git does not seem to be installed, do you want to 
>> install it? (Y/n) _
>> With sane defaults, so you can just run portsnap fetch extract like
>> you're used to and this
>> downloads the latest ports tree to /usr/ports using base svnlite(1).
>> While we're here: Can we please have a separate user that is used to
>> checkout the tree?
>> Lars
>> P.S.: Please DO NOT name the wrapper portsnap-ng. :-)
> 
> I think something like this will likely in many ways perpetuate many of the 
> problems I listed in my original email, particularly with folks being on the 
> wrong branch and not properly generating patches.

There are many users who never create any patches, but simply use the ports 
tree to install software. Please make sure the ports collection keeps working 
for them.

Michael



___
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: Error: MOVED: net/kblog EXPIRED 2020-08-13 No longer shipped

[Michael Gmelin]

> On 15. Aug 2020, at 23:55, Carmel  wrote:
> 
> When I attempted to do a bulk build with poudriere today, I was greeted
> with this rather disturbing message.
> 
> ~ # poudriere bulk -f ./port-list.txt -j 114Ramd64
> [00:00:00] Creating the reference jail... done
> [00:00:00] Mounting system devices for 114Ramd64-default
> [00:00:00] Mounting ports/packages/distfiles
> [00:00:00] Using packages from previously failed build: 
> /usr/local/poudriere/data/packages/114Ramd64-default/.building
> [00:00:00] Mounting ccache from: /usr/home/gerard/.ccache
> [00:00:00] Mounting packages from: 
> /usr/local/poudriere/data/packages/114Ramd64-default
> [00:00:00] Copying /var/db/ports from: 
> /usr/local/etc/poudriere.d/114Ramd64-options
> [00:00:00] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
> /etc/resolv.conf -> 
> /usr/local/poudriere/data/.m/114Ramd64-default/ref/etc/resolv.conf
> [00:00:00] Starting jail 114Ramd64-default
> [00:00:01] Logs: 
> /usr/local/poudriere/data/logs/bulk/114Ramd64-default/2020-08-15_17h45m52s
> [00:00:01] WWW: 
> http://seibercom.net/poudriere/build.html?mastername=114Ramd64-default&build=2020-08-15_17h45m52s
> [00:00:01] Loading MOVED for 
> /usr/local/poudriere/data/.m/114Ramd64-default/ref/usr/ports
> [00:00:01] Ports supports: FLAVORS SELECTED_OPTIONS
> [00:00:01] Gathering ports metadata
> [00:00:01] Error: MOVED: net/kblog EXPIRED 2020-08-13 No longer shipped
> [00:00:01] Error: Fatal errors encountered gathering initial ports metadata
> [00:00:01] Cleaning up
> [00:00:01] Unmounting file systems
> 
> Has anyone seen this before, and how do I rectify it?

What’s in port-list.txt?


> 
> System: FreeBSD 11.4-RELEASE-p2
> 
> -- 
> Jerry
> 

___
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: Error: MOVED: net/kblog EXPIRED 2020-08-13 No longer shipped

[Michael Gmelin]

> On 16. Aug 2020, at 02:16, Carmel  wrote:
> 
> On Sun, 16 Aug 2020 01:22:35 +0200, Christoph Moench-Tegeder stated:
>> ## Carmel (carmel...@outlook.com):
>> 
>>> [00:00:01] Error: MOVED: net/kblog EXPIRED 2020-08-13 No longer
>>> shipped [00:00:01] Error: Fatal errors encountered gathering initial
>>> ports metadata  
>> 
>>> Has anyone seen this before, and how do I rectify it?  
>> 
>> What it says: net/kblog is gone (with the latest KDE Application update
>> in r544824, see
>> https://svnweb.freebsd.org/ports?limit_changes=0&view=revision&revision=544824
>> for the full commit).
>> You need to remove that from your ports-list.txt.
> 
> I would have expected to see something in"UPDATING". The only mention
> is in "MOVED": net/kblog||2020-08-13|No longer shipped

MOVED is the documented location for this kind of information, see

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/moved-and-updating-files.html

> 
> Obviously, poudriere cannot handle this situation on its own. To bad.

Well, it kind of did. You explicitly asked it to build a port that has been 
removed and it informed you about the fact that the port no longer exists (and 
why). What else would you expect it to do?

Best,
Michael


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

How do port man pages get into https://www.freebsd.org/cgi/man.cgi?

[Michael Gmelin]

Hi,

I maintain at least one port that installs a man page that doesn't show
up in https://www.freebsd.org/cgi/man.cgi. Also, there seem to be cases
where man pages of ports are outdated (e.g.,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248927 was opened
today, the man page of the port in question was fixed on May 3rd 2020).

Is there any documentation explaining how port man pages are generated
for man.cgi and how frequently they're updated? Like, are they taken
from binary packages every few months or are they maybe created from the
ports tree that's current at the time of a release (so "FreeBSD
12.1-RELEASE and Ports" contains man pages based on
https://download.freebsd.org/ftp/releases/amd64/12.1-RELEASE/ports.txz)?

Cheers,
Michael

-- 
Michael Gmelin
___
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 port man pages get into https://www.freebsd.org/cgi/man.cgi?

[Michael Gmelin]

On Wed, 26 Aug 2020 16:53:30 +0200
Kurt Jaeger  wrote:

> Hi!
> 
> > Is there any documentation explaining how port man pages are
> > generated for man.cgi  
> 
> The man.cgi script itself is in the docs svn repo:
> 
> https://svnweb.freebsd.org/doc/head/en_US.ISO8859-1/htdocs/cgi/man.cgi?revision=54262&view=markup

Thanks.

> 
> We find that each released version has that version's ports tree.
> 
> > and how frequently they're updated? Like, are they taken
> > from binary packages every few months or are they maybe created
> > from the ports tree that's current at the time of a release (so
> > "FreeBSD 12.1-RELEASE and Ports" contains man pages based on
> > https://download.freebsd.org/ftp/releases/amd64/12.1-RELEASE/ports.txz)?
> >  
> 
> Yes, exactly.
> 
> Any ideas on how man.cgi can be made to also display ports head man
> pages ?

One way would be to extract man pages from the binary packages we
provide - this would allow to have man pages for head and quarterly
branches. This could be implemented as a poudriere feature while
building (so it collects man pages as a side effect of bulk builds), or
based on the artifacts/binary package produced by poudriere. The former
would probably be more elegant and less resource intensive, but also
more intrusive.

Naive implementation:

Get list of man pages:

find /usr/local/poudriere/data/packages/121amd64-default/All/ \
  -name "*.txz" -exec tar -tf {} /usr/local/man 2>/dev/null \;

Extract man pages to /tmp/manpages:

find /usr/local/poudriere/data/packages/121amd64-default/All/ \
  -name "*.txz" -exec tar \
-C /tmp/manpages \
--strip-components 4 \
-xf {} \
/usr/local/man 2>/dev/null \;

Test if it works:

MANPATH=/tmp/manpages man XGrabButton

Cheers,
Michael

-- 
Michael Gmelin
___
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 port man pages get into https://www.freebsd.org/cgi/man.cgi?

[Michael Gmelin]

On Wed, 26 Aug 2020 18:37:51 +0200
Kurt Jaeger  wrote:

> Hi!
> 
> > > Any ideas on how man.cgi can be made to also display ports head
> > > man pages ?  
> 
> > One way would be to extract man pages from the binary packages we
> > provide - this would allow to have man pages for head and quarterly
> > branches. [...]  
> 
> man.cgi has provisions for most of this already, it's only missing
> some job to regulary extract the latest
> 
> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/13.0-CURRENT/ports.txz
> 
> for the current tree of the manuals.

How does it actually create the pages though? E.g., the
man page paperless(7) created by deskutils/py-paperless [0] still isn't
available over man.cgi, even though the port was created a long time
before 12.1 was released and is in 12.1's ports.txz.

Cheers,
Michael

[0]https://svnweb.freebsd.org/ports/head/deskutils/py-paperless/

-- 
Michael Gmelin
___
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: Squid 4.13 (security update)

[Michael Gmelin]

> On 31. Aug 2020, at 16:31, Kurt Jaeger  wrote:
> 
> Hi!
> 
>> I see Squid 4.13 was released 8 days ago: it's "strongly suggested"
>> everyone updates, as it fixes "serious" security issues.
>> 
>> I don't see it coming in the port tree and neither in the pkg audit
>> vulnerability database.
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248856
> 
> has a patch from the maintainer. @work
> 

CVEs should be:
CVE-2020-15810 and
CVE-2020-15811

https://access.redhat.com/security/cve/cve-2020-15810

https://access.redhat.com/security/cve/cve-2020-15811



> -- 
> 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: How do port man pages get into https://www.freebsd.org/cgi/man.cgi?

[Michael Gmelin]

On Mon, 31 Aug 2020 20:33:34 +0200
Wolfram Schneider  wrote:

> On Wed, 26 Aug 2020 at 18:50, Kurt Jaeger  wrote:
> >
> > Hi!
> >  
> > > > man.cgi has provisions for most of this already, it's only
> > > > missing some job to regulary extract the latest
> > > >
> > > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/13.0-CURRENT/ports.txz
> > > >
> > > > for the current tree of the manuals.  
> > >
> > > How does it actually create the pages though?  
> >
> > wosch probably knows this.  
> 
> Indeed ;-)

Thanks!

> 
> The ports manual pages will be updated once when a new release comes
> out. Maybe every 3-9 months. The update takes hours and a lot of
> resources (60GB download of all packages and unpacking).
> 

It would be cool if you could share the scriptwork that does this.
Getting to a higher update frequency for ports would be really useful,
but it feels like that this will require coordination between different
teams/individuals.

> -Wolfram

Do you have any idea why the man page below isn't included?

> > > E.g., the
> > > man page paperless(7) created by deskutils/py-paperless [0] still
> > > isn't available over man.cgi, even though the port was created a
> > > long time before 12.1 was released and is in 12.1's ports.txz.  

Cheers,
Michael

-- 
Michael Gmelin
___
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 port man pages get into https://www.freebsd.org/cgi/man.cgi?

[Michael Gmelin]

@Wolfram: Do you think you could look into this (paperless man page). Thanks!

-m

> On 1. Sep 2020, at 11:55, Michael Gmelin  wrote:
> 
> 
> 
>> On Mon, 31 Aug 2020 20:33:34 +0200
>> Wolfram Schneider  wrote:
>> 
>>> On Wed, 26 Aug 2020 at 18:50, Kurt Jaeger  wrote:
>>> 
>>> Hi!
>>> 
>>>>> man.cgi has provisions for most of this already, it's only
>>>>> missing some job to regulary extract the latest
>>>>> 
>>>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/13.0-CURRENT/ports.txz
>>>>> 
>>>>> for the current tree of the manuals.  
>>>> 
>>>> How does it actually create the pages though?  
>>> 
>>> wosch probably knows this.  
>> 
>> Indeed ;-)
> 
> Thanks!
> 
>> 
>> The ports manual pages will be updated once when a new release comes
>> out. Maybe every 3-9 months. The update takes hours and a lot of
>> resources (60GB download of all packages and unpacking).
>> 
> 
> It would be cool if you could share the scriptwork that does this.
> Getting to a higher update frequency for ports would be really useful,
> but it feels like that this will require coordination between different
> teams/individuals.
> 
>> -Wolfram
> 
> Do you have any idea why the man page below isn't included?
> 
>>>> E.g., the
>>>> man page paperless(7) created by deskutils/py-paperless [0] still
>>>> isn't available over man.cgi, even though the port was created a
>>>> long time before 12.1 was released and is in 12.1's ports.txz.  
> 
> Cheers,
> Michael
> 
> -- 
> Michael Gmelin
> ___
> 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: How do port man pages get into https://www.freebsd.org/cgi/man.cgi?

[Michael Gmelin]

Hi Wolfram,

> On 17. Sep 2020, at 11:44, Wolfram Schneider 
> wrote:
> 
> On Wed, 16 Sep 2020 at 20:34, Michael Gmelin  wrote:
>> 
>> @Wolfram: Do you think you could look into this (paperless man
>> page). Thanks!
> 
> the page https://man.freebsd.org/paperless
> 
> looks fine for me. What are you missing?
> 

When I checked yesterday, it just returned an empty page (I only tried
once though).

Today it shows up, but it has some serious[0] rendering issues (starting
at about "Install and configure uwsgi"), which are probably caused by
misinterpreting '\\"' at the end of line 135 of the man page.

It renders fine using man(1) on the console (which uses mandoc(1)) and
also when converting it to html using `mandoc -T html'.

`mandoc -T lint' is also happy with the man page.

`groff -T html -man' does complain though, shows these issues at
line 135:

:135: a space character is not allowed in an escape name
:135: warning: numeric expression expected (got `u')
:135: warning: can't find font `['

and creates output like the one seen on man.freebsd.org.

Based on this, I assume that man.cgi uses groff or a similar tool and
not mandoc to create html output.

I'll change literal parts of the paperless man page later today, so that
examples render nicer using `mandoc -T html', which will also fix groff
output as a side-effect by getting rid of the offending escape
sequence. I'll bump the revision and hope that it will be picked up
sooner or later.

Since we switched to mandoc(1) being the default for man(1) in HEAD
more than five years ago, I think it would make sense to do the same
for man.cgi to keep things consistent. QA is usually done
using mandoc -T lint for syntax, igor for style, and by checking
manually on the console, none of which would have revealed that problem
(not just for ports, but also in base).

Adapting the style sheet shouldn't be too hard. I'm happy to help with
that, if needed.

Thanks
Michael

[0]Serious in the sense that relevant information is lost.

> -Wolfram
> 
> 
>> -m
>> 
>>>> On 1. Sep 2020, at 11:55, Michael Gmelin  wrote:
>>> 
>>> 
>>> 
>>>> On Mon, 31 Aug 2020 20:33:34 +0200
>>>> Wolfram Schneider  wrote:
>>>> 
>>>>> On Wed, 26 Aug 2020 at 18:50, Kurt Jaeger  wrote:
>>>>> 
>>>>> Hi!
>>>>> 
>>>>>>> man.cgi has provisions for most of this already, it's only
>>>>>>> missing some job to regulary extract the latest
>>>>>>> 
>>>>>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/13.0-CURRENT/ports.txz
>>>>>>> 
>>>>>>> for the current tree of the manuals.
>>>>>> 
>>>>>> How does it actually create the pages though?
>>>>> 
>>>>> wosch probably knows this.
>>>> 
>>>> Indeed ;-)
>>> 
>>> Thanks!
>>> 
>>>> 
>>>> The ports manual pages will be updated once when a new release
>>>> comes out. Maybe every 3-9 months. The update takes hours and a
>>>> lot of resources (60GB download of all packages and unpacking).
>>>> 
>>> 
>>> It would be cool if you could share the scriptwork that does this.
>>> Getting to a higher update frequency for ports would be really
>>> useful, but it feels like that this will require coordination
>>> between different teams/individuals.
>>> 
>>>> -Wolfram
>>> 
>>> Do you have any idea why the man page below isn't included?
>>> 
>>>>>> E.g., the
>>>>>> man page paperless(7) created by deskutils/py-paperless [0] still
>>>>>> isn't available over man.cgi, even though the port was created a
>>>>>> long time before 12.1 was released and is in 12.1's ports.txz.
>>> 
>>> Cheers,
>>> Michael
>>> 
>>> --
>>> Michael Gmelin
>>> ___
>>> 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"
>> 
> 
> 
> -- 
> Wolfram Schneider  https://wolfram.schneider.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"

REINPLACE_CMD QA causing pkg-fallout

[Michael Gmelin]

Hi,

I updated the devel/phabricator port yesterday, which included running
the usual QA steps (`poudriere testport', also running "make
check-plist" on a local ports tree).

Later, after committing the change and when updating on a production
machine, I noticed a problem with the package list, which I first
corrected in-place and then committed the corrections. Today I started
receiving pkg-fallout messages - seems like timing was quite
unfortunate. Those messages motivated me to look into the issue
and I figured out why it failed:

It turns out that if DEVELOPER is set, it worked fine (which is
also what is set when `poudriere testport' is run). Without DEVELOPER
set (e.g., in `poudriere bulk') it failed.

The reason is that this port sets REINPLACE_ARGS to override the "-i"
argument to $REINPLACE_CMD like this:

  REINPLACE_ARGS= -i ""

which seems to be the intended use of this variable, according to
bsd.port.mk:

  # Macro for doing in-place file editing using regexps.
  # REINPLACE_ARGS may only be used to set or override the -i
  # argument. Any other use is considered invalid.

Now, since r522484[0], reviewed in [1], REINPLACE_CMD is set to
sed_checked.sh (which now is ${SCRIPTSDIR}/sed_checked.sh), which
hardcodes the call to `/usr/bin/sed -i.bak "$@"'.

Therefore, this is what made me create the broken pkg-plist:
- I had "DEVELOPER=yes" in /etc/make.conf.
- I used `make makeplist' to create a new pkg-list.
- The new pkg-plist contained .bak files created by sed_checked.sh
  without me noticing.
- `make stage-qa' and `poudriere testport' worked just fine, as the
  .bak files are created there as well.
- Once building without "DEVELOPER" set (production server with ports
  tree, `poudriere bulk', project build servers), it failed, as
  sed_checked.sh isn't involved there, so no .bak files are created, as
  REINPLACE_ARGS is applied.

To keep supporting overriding "-i" and making sure that DEVELOPER
builds are the same as non-DEVELOPER builds, I would suggest to modify
sed_checked.sh like this:

- Change the call to sed: /usr/bin/sed -i.sedcheck "$@"
- Move the backup file back to the original file after checking:
  mv "$@".sedcheck "$@"
- Run sed again, this time passing $REINPLACE_ARGS

Maybe @swills has time to look into this, if not, I'll try to find the
time to come up with a patch and open a review.

Cheers,
Michael

[0] https://svnweb.freebsd.org/ports?view=revision&revision=522484
[1] https://reviews.freebsd.org/D22174

-- 
Michael Gmelin
___
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: REINPLACE_CMD QA causing pkg-fallout

[Michael Gmelin]

On Sat, 2 Jan 2021 18:33:12 +0100
Michael Gmelin  wrote:

> Hi,
> 
> I updated the devel/phabricator port yesterday, which included running
> the usual QA steps (`poudriere testport', also running "make
> check-plist" on a local ports tree).
> 
> Later, after committing the change and when updating on a production
> machine, I noticed a problem with the package list, which I first
> corrected in-place and then committed the corrections. Today I started
> receiving pkg-fallout messages - seems like timing was quite
> unfortunate. Those messages motivated me to look into the issue
> and I figured out why it failed:
> 
> It turns out that if DEVELOPER is set, it worked fine (which is
> also what is set when `poudriere testport' is run). Without DEVELOPER
> set (e.g., in `poudriere bulk') it failed.
> 
> The reason is that this port sets REINPLACE_ARGS to override the "-i"
> argument to $REINPLACE_CMD like this:
> 
>   REINPLACE_ARGS= -i ""
> 
> which seems to be the intended use of this variable, according to
> bsd.port.mk:
> 
>   # Macro for doing in-place file editing using regexps.
>   # REINPLACE_ARGS may only be used to set or override the -i
>   # argument. Any other use is considered invalid.
> 
> Now, since r522484[0], reviewed in [1], REINPLACE_CMD is set to
> sed_checked.sh (which now is ${SCRIPTSDIR}/sed_checked.sh), which
> hardcodes the call to `/usr/bin/sed -i.bak "$@"'.
> 
> Therefore, this is what made me create the broken pkg-plist:
> - I had "DEVELOPER=yes" in /etc/make.conf.
> - I used `make makeplist' to create a new pkg-list.
> - The new pkg-plist contained .bak files created by sed_checked.sh
>   without me noticing.
> - `make stage-qa' and `poudriere testport' worked just fine, as the
>   .bak files are created there as well.
> - Once building without "DEVELOPER" set (production server with ports
>   tree, `poudriere bulk', project build servers), it failed, as
>   sed_checked.sh isn't involved there, so no .bak files are created,
> as REINPLACE_ARGS is applied.
> 
> To keep supporting overriding "-i" and making sure that DEVELOPER
> builds are the same as non-DEVELOPER builds, I would suggest to modify
> sed_checked.sh like this:
> 
> - Change the call to sed: /usr/bin/sed -i.sedcheck "$@"
> - Move the backup file back to the original file after checking:
>   mv "$@".sedcheck "$@"
> - Run sed again, this time passing $REINPLACE_ARGS
> 
> Maybe @swills has time to look into this, if not, I'll try to find the
> time to come up with a patch and open a review.
> 
> Cheers,
> Michael
> 
> [0] https://svnweb.freebsd.org/ports?view=revision&revision=522484
> [1] https://reviews.freebsd.org/D22174
> 

I implemented a simple fix and opened a review:
https://lists.freebsd.org/pipermail/freebsd-ports/2021-January/119978.html

-m

-- 
Michael Gmelin
___
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: REINPLACE_CMD QA causing pkg-fallout

[Michael Gmelin]

On Mon, 4 Jan 2021 18:56:31 +0100
Michael Gmelin  wrote:

> On Sat, 2 Jan 2021 18:33:12 +0100
> Michael Gmelin  wrote:
> 
> > Hi,
> > 
> > I updated the devel/phabricator port yesterday, which included
> > running the usual QA steps (`poudriere testport', also running "make
> > check-plist" on a local ports tree).
> > 
> > Later, after committing the change and when updating on a production
> > machine, I noticed a problem with the package list, which I first
> > corrected in-place and then committed the corrections. Today I
> > started receiving pkg-fallout messages - seems like timing was quite
> > unfortunate. Those messages motivated me to look into the issue
> > and I figured out why it failed:
> > 
> > It turns out that if DEVELOPER is set, it worked fine (which is
> > also what is set when `poudriere testport' is run). Without
> > DEVELOPER set (e.g., in `poudriere bulk') it failed.
> > 
> > The reason is that this port sets REINPLACE_ARGS to override the
> > "-i" argument to $REINPLACE_CMD like this:
> > 
> >   REINPLACE_ARGS= -i ""
> > 
> > which seems to be the intended use of this variable, according to
> > bsd.port.mk:
> > 
> >   # Macro for doing in-place file editing using regexps.
> >   # REINPLACE_ARGS may only be used to set or override the -i
> >   # argument. Any other use is considered invalid.
> > 
> > Now, since r522484[0], reviewed in [1], REINPLACE_CMD is set to
> > sed_checked.sh (which now is ${SCRIPTSDIR}/sed_checked.sh), which
> > hardcodes the call to `/usr/bin/sed -i.bak "$@"'.
> > 
> > Therefore, this is what made me create the broken pkg-plist:
> > - I had "DEVELOPER=yes" in /etc/make.conf.
> > - I used `make makeplist' to create a new pkg-list.
> > - The new pkg-plist contained .bak files created by sed_checked.sh
> >   without me noticing.
> > - `make stage-qa' and `poudriere testport' worked just fine, as the
> >   .bak files are created there as well.
> > - Once building without "DEVELOPER" set (production server with
> > ports tree, `poudriere bulk', project build servers), it failed, as
> >   sed_checked.sh isn't involved there, so no .bak files are created,
> > as REINPLACE_ARGS is applied.
> > 
> > To keep supporting overriding "-i" and making sure that DEVELOPER
> > builds are the same as non-DEVELOPER builds, I would suggest to
> > modify sed_checked.sh like this:
> > 
> > - Change the call to sed: /usr/bin/sed -i.sedcheck "$@"
> > - Move the backup file back to the original file after checking:
> >   mv "$@".sedcheck "$@"
> > - Run sed again, this time passing $REINPLACE_ARGS
> > 
> > Maybe @swills has time to look into this, if not, I'll try to find
> > the time to come up with a patch and open a review.
> > 
> > Cheers,
> > Michael
> > 
> > [0] https://svnweb.freebsd.org/ports?view=revision&revision=522484
> > [1] https://reviews.freebsd.org/D22174
> >   
> 
> I implemented a simple fix and opened a review:
> https://lists.freebsd.org/pipermail/freebsd-ports/2021-January/119978.html
> 
> -m
> 

Breaking the recursion, here's the correct link to the review:
https://reviews.freebsd.org/D27954

-m


-- 
Michael Gmelin
___
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

[Michael Gmelin]

On Wed, 27 Jan 2021 10:35:38 +0200
Peter Pentchev  wrote:

> On Wed, Jan 27, 2021 at 10:57:22AM +0900, Yasuhiro Kimura wrote:
> > From: Freddie Cash 
> > Subject: Re: List of packages upgraded last time `pkg upgrade` was
> > executed Date: Tue, 26 Jan 2021 17:26:29 -0800
> >   
> > > /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.  
> > 
> > Thank you for reply. But my intention is to write shell script that
> > gets the list of upgraded packages and does something by using
> > it. Because of that the list need to be gotton without any user
> > interaction. So unfortunately your method is not applicable to my
> > case.  
> 
> Well, there is the option of running a pkg query before and after
> the upgrade and comparing the results... especially if you write it in
> a higher-level language than the shell, it Should Not Be Too Hard(tm)
> to figure out which packages have changed their version, what new
> ones have appeared, which ones have been removed...
> 
> But, yeah, it is certainly easy for me to suggest that somebody else
> write something "simple" :)
> 

This will give you a list of all packages that were updated/installed
last:

  pkg query -e %t=$(pkg query %t | sort -n | tail -n1) %n-%v

Explained:

$(pkg query %t | sort -n | tail -n1)
- Get timestamps of when packages were installed
- Sort numerically
- Take the last one (which is the latest)

Feed this into `pkg query %t=x %n-%v` which returns all packages
matching that latest timestamp (== when last set of packages were
installed) and outputs their name and version.

As far as I can tell, packages installed by the same pkg invocation run
share the same installation timestamp (I didn't check the pkg sources,
but that's what appears to be the case), that's why this works. This
resulting list won't include the pkg package itself in case it was
updated as part as the run. There might also be other multi-pass
scenarios of pkg I'm not aware of though.

In case you know when pkg upgrade was called last, you can simply feed
it the timestamp directly, like in:

  pkg query -e "%t>=1609545326" %n-%v

If you use a script to do upgrades, you could store the timestamp as
part of that and do something like this:

  touch /tmp/lastupgrade
  pkg upgrade
  # then, later:
  pkg query -e "%t>=$(stat -f %m /tmp/lastupgrade)" %n-%v
  

Cheers,
Michael

-- 
Michael Gmelin
___
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

[Michael Gmelin]

On Thu, 28 Jan 2021 03:23:57 +0900 (JST)
Yasuhiro Kimura  wrote:

> From: Michael Gmelin 
> Subject: Re: List of packages upgraded last time `pkg upgrade` was
> executed Date: Wed, 27 Jan 2021 10:05:57 +0100
> 
> > This will give you a list of all packages that were
> > updated/installed last:
> > 
> >   pkg query -e %t=$(pkg query %t | sort -n | tail -n1) %n-%v  
> 
> I tried this but unfortunately it doesn't seem to work as is expected.
> 
> On the host I tried it, following packages are upgraded when I did
> `pkg upgrade` last time.
> 
> p5-URI-5.06
> p5-Module-CoreList-5.20210120
> rubygem-bundler-2.2.7_1,1
> sudo-1.9.5p2 1611721387
> 
> And I got following result.
> 
> yasu@eastasia[1213]% pkg query -e %t=$(pkg query %t | sort -n | tail
> -n1) %n-%v p5-Module-CoreList-5.20210120
> p5-URI-5.06
> yasu@eastasia[1213]%
> 
> So I checked timestamp of install packages.
> 
> yasu@eastasia[1216]% pkg query -a '%n-%v %t'  | sort -k 2 -n -r |
> head -10   ~ p5-URI-5.06
> 1611721389 p5-Module-CoreList-5.20210120 1611721389
> rubygem-bundler-2.2.7_1,1 1611721388
> sudo-1.9.5p2 1611721387
> p5-Config-General-2.63 1611685127
> libunwind-20201110 1611685127
> bind916-9.16.11 1611685127
> zstd-1.4.8 1611685126
> sqlite3-3.34.1,1 1611685126
> bind-tools-9.16.11 1611685125
> yasu@eastasia[1217]%
> 
> As you can see timestamps of rubygem-bundler-2.2.7_1,1 and
> sudo-1.9.5p2 are smaller than that of p5-URI-5.06 and
> p5-Module-CoreList-5.20210120. So they aren't included in the list.
> 
> > As far as I can tell, packages installed by the same pkg invocation
> > run share the same installation timestamp (I didn't check the pkg
> > sources, but that's what appears to be the case),  
> 
> According to the above result, it doesn't seem to be true. And I think
> it's quite possible. When packages are upgraded they are upgraded not
> in parallel but sequentially. So let me assume following situation.
> 
> * Pakcage A and B are to be upgraded.
> * A is upgraded first and B is next.
> * Both are quite large package.
> * Host is low-spec.
> 
> In this case upgrade of each package may take a few minutes. And it
> result in that there is difference of a few minites between the
> timestamps of them after upgrade.

I could reproduce your results easily by running `pkg install llvm10
rust gcc10`, so my bad, sorry.

I could have sworn that this behaved differently in the past though.

> 
> > If you use a script to do upgrades, you could store the timestamp as
> > part of that and do something like this:
> > 
> >   touch /tmp/lastupgrade
> >   pkg upgrade
> >   # then, later:
> >   pkg query -e "%t>=$(stat -f %m /tmp/lastupgrade)" %n-%v  
> 
> This didn't hit upon me and I think it's really excellent way to use
> file for timestamp. I'll use it in my shell script. Thank you for
> letting me know.

That's good to hear :)

Cheers,
Michael

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



-- 
Michael Gmelin
___
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: broken vuln.xml?

[Michael Gmelin]

On Tue, 2 Feb 2021 08:09:41 -0500
Robert Huff  wrote:

> Hell:
> 
> >   Robert Huff  wrote:
> > 
> >   > Hello:
> >   > This appears to have broken (Sunday?) on one of my
> >   > systems. What is the correct way to download/regenerate this
> >   > file?  
> >   
> >   portaudit is being replaced by pkg audit.
> >   
> >   This may already have happened - I am not sure.  
> 
>Uh ... ok.  With no warning?  No entry in
> UPDATING?
>   
> 
> 

I think there is some misunderstanding - like bapt wrote, portaudit was
removed years ago, when we retired the old pkg_tools and introduced pkg
(see MOVED). `pkg audit -F` (again, like bapt already wrote) might do
the trick.

Best,
Michael


-- 
Michael Gmelin
___
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: Testing www/chromium before installing

[Michael Gmelin]

> On 13. Mar 2021, at 18:51, bob prohaska  wrote:
> 
> On Sat, Mar 13, 2021 at 06:11:06PM +0100, Michael Gmelin wrote:
>> 
>> 
>>> On Sat, 13 Mar 2021 08:50:07 -0800
>>> bob prohaska  wrote:
>>> 
>>> Hi Michel,
>>> 
>>> On Sat, Mar 13, 2021 at 05:01:16PM +0100, Michael Gmelin wrote:
>>>> What about ???make stage
>>>> 
>>> Never heard of it, and can't find any obvious references.
>>> Is there a description somewhere?
>> 
>> It's one of the seven main targets of building a port:
>> 
>> - extract
>> - patch
>> - configure
>> - build
>> - stage
>> - install
>> - package
>> 
>> It installs the port into STAGEDIR (by default work/stage). Install and
>> package copy files from STAGEDIR, so usually stage is run implicitly.
>> See /usr/ports/Mk/bsd.port.mk for details (documentation isn't great,
>> most of it is from when the big conversion to STAGEDIR happened a
>> couple of years ago).
>> 
>> To give you a simple port as an example
>> 
>> # cd /usr/ports/editors/joe
>> # make stage
>> ...
>> # find work/stage -type f -perm +111
>> work/stage/usr/local/bin/joe
>> 
>> Same should work with chromium (you might need to set LD_LIBRARY_PATH
>> in case chromium comes with its own libraries).
>> 
> 
> Thank you! Found the executable, and it suffers from the same problem
> as the old version: The controls drop-down menu (right of the URL bar)
> is non-persistent and can't be used. The new version does seem to run
> faster, which is a step forward.
> 
> It's surprising that a simple
> find . -name stage 
> didn't discover the directory, but did discover those for node, 
> in the same subtree.  The exact syntax you provided seems to be 
> required.
> 
>> Oh, alternatively you could of course simply make a backup of your
>> current chromium package:
>> 
>>  pkg create chromium
>> 
>> Which you then can re-install in case the new version doesn't work as
>> expected: pkg add chromium-someversion.txz
>> 
> 
> The sources for the existing version of chromium are long overwritten,
> can a package be constructed from installed files?  

Yes, “pkg create” creates a package from what is installed on a system (package 
database and installed files).

You can use “pkg create -a” to create tarballs for all installed packages 
(useful before doing major surgery or to transfer a full package set to a 
different system). Check “man pkg-create” for details.

-m


> 
> bob prohaska
> 
> 
>> Best,
>> Michael
>> 
>>> 
>>> Thanks for writing!
>>> 
>>> bob prohaska
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>>> On 13. Mar 2021, at 16:49, bob prohaska 
>>>>> wrote:
>>>>> 
>>>>> ???After a _very_ long time www/chromium finished compiling on a
>>>>> Pi3B+. I'd like to test it before installing, since I have a
>>>>> (mostly) working version in /usr/local/bin and don't want to
>>>>> overwrite it until I know the new version works at least as
>>>>> well as the old one. 
>>>>> 
>>>>> Poking around in the source tree didn't disclose any obvious 
>>>>> executable, could somebody offer a hint at test methods, if any?
>>>>> 
>>>>> Thanks for reading,
>>>>> 
>>>>> bob prohaska
>>>>> 
>>>>> ___
>>>>> 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"  
>>>> 
>>>> 
>> 
>> 
>> 
>> -- 
>> Michael Gmelin
> ___
> 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: devel/git: Git via Apache 2.4 HTTPS - info/refs not valid: could not determine hash algorithm

[Michael Gmelin]

On Sun, 28 Mar 2021 13:08:19 +0200
"Hartmann, O."  wrote:

> What am I missing here?
> 

The man page of git-http-backend has an apache2 example[0].
Also, the top answer to this stackoverflow question might give you a
hint: https://stackoverflow.coo-set-up-git-over-http

Best,
Michael

[0]https://www.freebsd.org/cgi/man.cgi?query=git-http-backend&apropos=0&sektion=0&manpath=FreeBSD+12.2-RELEASE+and+Ports&arch=default&format=html


-- 
Michael Gmelin
___
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: devel/git: Git via Apache 2.4 HTTPS - info/refs not valid: could not determine hash algorithm

[Michael Gmelin]

On Mon, 29 Mar 2021 20:26:24 +0200
"Hartmann, O."  wrote:

> On Mon, 29 Mar 2021 11:42:28 +0200
> Michael Gmelin  wrote:
> 
> > On Sun, 28 Mar 2021 13:08:19 +0200
> > "Hartmann, O."  wrote:
> >   
> > > What am I missing here?
> > > 
> > 
> > The man page of git-http-backend has an apache2 example[0].
> > Also, the top answer to this stackoverflow question might give you a
> > hint: https://stackoverflow.coo-set-up-git-over-http
> > 
> > Best,
> > Michael
> > 
> > [0]https://www.freebsd.org/cgi/man.cgi?query=git-http-backend&apropos=0&sektion=0&manpath=FreeBSD+12.2-RELEASE+and+Ports&arch=default&format=html
> > 
> >   
> 
> Hello Michael,
> 
> thanks for responding.
> The first tip I came across was the Stackoverflow HowTo - whatever I
> did and do, it doesn't work. I also tried the several variants shown
> in [0], starting with the simplest towards more complex ones.
> 
> Following strictly the reference at 
> 
> https://stackoverflow.com/questions/26734933/how-to-set-up-git-over-http
> 
> with minor local adaptions (for FreeBSD and the Git base folder),
> even with anonymous access allowed the failure is the same as with
> some Basic authentication via LDAP.
> 
> As decribed in my initial email: first access with a "git push -u
> origin master" is logged by Apache with 401, requesting credentials.
> If provided, the line (httpd-access.log):
> 
> xx.xx.xx.xx - USERNAME [29/Mar/2021:17:44:55 +] "GET \
> /git/test.git/info/refs?service=git-upload-pack HTTP/1.1" 200 1689032
> "-" "git/2.31.0" \ 323 1691601
> 
> status code 200 indicates OK - so authetication is all right and I
> should proceed, but I get on the client
> 
> fatal: https://[url]/git/test.git/info/refs not valid: could not
> determine hash algorithm; is this a git repository?
> 
> On both sides, I had disabled sslVerify (due to self signed cert
> issue with git, another pitfall) and according to stackoverflow
> howto, hooks are also prepared and the root folder and its subsequent
> folders /pool/gitbase (PROJECT_ROOT) is owned by www:www and has ACL
> 0775 set.
> 
> And this is why it gets desperate to me ...

I played a bit with this - turns out that the key is to make sure that
the cgi module is loaded (e.g., mod_cgi).

This is the simple basic setup I tested (using bash):

pkg install apache24 git
service apache24 enable

cat >/usr/local/etc/apache24/Includes/git.conf<<"EOF"
LoadModule cgi_module libexec/apache24/mod_cgi.so
LoadModule rewrite_module libexec/apache24/mod_rewrite.so
ServerName 127.0.0.1

SetEnv GIT_PROJECT_ROOT /usr/local/www/git/
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/local/libexec/git-core/git-http-backend/

RewriteCond %{QUERY_STRING} service=git-receive-pack [OR]
RewriteCond %{REQUEST_URI} /git-receive-pack$
RewriteRule ^/git/ - [E=AUTHREQUIRED:yes]


  Order Deny,Allow
  Deny from env=AUTHREQUIRED

  AuthType Basic
  AuthName "Git Access"
  Require group committers
  Satisfy Any

EOF

mkdir -p /usr/local/www/git/test.git
git init --bare /usr/local/www/git/test.git
service apache24 start

git clone http://localhost/git/test


Cheers,
Michael

> 
> Kind regards,
> 
> O. Hartmann



-- 
Michael Gmelin
___
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: git-tiny or git-lite - Re: No update for a day on ports?

[Michael Gmelin]

On Fri, 2 Apr 2021 12:31:30 +0200 (CEST)
Ronald Klop  wrote:

> Hi,
> 
> I like pkg install git-tiny or git-lite so much more. If I
> install git I don't see why I need to install subversion as a
> dependency. And 50+ other direct or indirect dependencies.

We might remove SVN from OPTIONS_DEFAULT once the dust of the
transition has settled, I opened PR254719[0] asking for it

-m

[0]https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254719.

> 
> But gitup also helps for port users.
> 
> Regards,
> Ronald.
> 
>  
> Van: Mathieu Arnold 
> Datum: donderdag, 1 april 2021 10:01
> Aan: Milan Obuch 
> CC: freebsd-ports@freebsd.org
> Onderwerp: Re: No update for a day on ports?
> > 
> > On Thu, Apr 01, 2021 at 09:54:16AM +0200, Milan Obuch wrote:  
> > > On Thu, 1 Apr 2021 09:47:04 +0200, Mathieu Arnold
> > >  wrote:
> > >  
> > > > On Thu, Apr 01, 2021 at 09:16:15AM +0200, Milan Obuch wrote:  
> > > > > Also, what about svn mirror, as is done for src repository,
> > > > > for 11 and 12 branches at least? I did not tried it recently,
> > > > > but it used to work. For some boxes, adding git to the mix
> > > > > would be big PITA.
> > > >
> > > > There will be no Git to Subversion conversion for ports, like
> > > > for docs. The only reason there is for the base system on 11
> > > > and 12 is because Subversion was the source control software
> > > > used when they were released.
> > > >  
> > >
> > > This is unpleasant move for me. This means git or equivalent (and
> > > dependencies) must be installed on any box where tracking ports
> > > tree is planned/needed... and no tool like svnlite could be
> > > expected in base system for some time.
> > >
> > > So I need some work on my local infrastructure to adjust to this
> > > move. C'est la vie...  
> > 
> > If you actually need a repository, and not just the latest files,
> > all you need is run pkg install git on the machines you are
> > actually using a ports tree on, if you have more than one machine,
> > you should probably be using binary packages anyway, either the
> > ones provided by FreeBSD, or ones built yourself using
> > ports-mgmt/poudriere.  If you only need the latest files, you can
> > probably use something like net/gitup.
> > 
> > -- 
> > Mathieu Arnold
> > 
> > 
> > 
> >
> ___
> 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"



-- 
Michael Gmelin
___
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: Proposed ports git transition schedule

[Michael Gmelin]

> On 2. Apr 2021, at 16:27, Kevin Oberman  wrote:
> 
> On Fri, Apr 2, 2021 at 4:53 AM Robert Huff  wrote:
> 
>> 
>>The transition has happened.
>>Where do I find the authoritative guide for non-committers?
>> 
>> 
>>Respectfully,
>> 
>> 
>>Robert Huff
>> 
>> --
>> Hello ... my name is SARS-CoV-2.
>> You are not wearing a mask?
>> Prepare to die!
>> 
> And where do I find the repository? I look at https://cgit.freebsd.org and
> see only doc and src. Is there a delay in the move of the repo? Or, am I
> looking in the wrong place?

According to https://wiki.freebsd.org/git the final run of subversion-git 
conversion hasn’t started yet (was planned for yesterday). So I guess we just 
have to be patient.

-m



> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> ___
> 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: cannot git clone into /usr/ports when separate filesystem

[Michael Gmelin]

> On 6. Apr 2021, at 13:10, Marco Beishuizen 
> wrote:
> 
> Hi,
> 
> I'm trying to git clone the portstree into /usr/ports. /usr/ports is
> a separate filesystem so it contains a .sujournal file. But now git
> complains "fatal: destination path 'ports' already exists and is not
> an empty directory."
> 
> So my question is what to do next? Recreating a new .sujournal every
> time a ports tree needs to be cloned is quite annoying.

Like Felix wrote, you clone exactly once and then you only pull for
updates.

Assuming /usr/ports is empty besides the .sujournal file, I would do:

  cd /usr/ports
  git clone https://git.freebsd.org/ports.git removeme
  mv removeme/.* removeme/* .
  rmdir removeme
  git status
  git pull

Note that "Invalid Arguments" errors are expected on the mv command
(this could be replaced by a fancy find command, like `find removeme \
-mindepth 1 -maxdepth 1 -exec mv {} . \;`, but this was easier).

Also, in case "git status" shows something like "Untracked filed
.sujournal", add ".sujournal" to your global git excludes file.

Example:

  git config core.excludesFile=$HOME/.gitexcludes
  echo .sujournal >>$HOME/.gitexcludes

In case you don't want to override the excludesFile setting, alter one
of the config files in the default global location
$XDG_CONFIG_HOME/git/ignore[0].

Best,
Michael

[0] `man git-config` says:
   core.excludesFile
   Specifies the pathname to the file that contains patterns to
   describe paths that are not meant to be tracked, in addition
   to .gitignore (per-directory) and .git/info/exclude. Defaults to
   $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either
   not set or empty, $HOME/.config/git/ignore is used instead. See
   gitignore(5).
___
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: cannot git clone into /usr/ports when separate filesystem

[Michael Gmelin]

On Tue, 6 Apr 2021 15:12:42 +0200 (CEST)
free...@oldach.net (Helge Oldach) wrote:

> Marco Beishuizen wrote on Tue, 06 Apr 2021 14:25:51 +0200 (CEST):
> > On Tue, 6 Apr 2021, the wise Helge Oldach wrote:  
> > > cd /usr/ports
> > > git init .
> > > git remote add -t main -f freebsd
> > > https://git.freebsd.org/ports.git  
> > 
> > This created new .git subdirectories but still cannot clone into 
> > /usr/ports.  
> 
> Sorry, I forgot: git checkout main
> 
> Once done, just regularly: git pull --ff-only
> 
> Explanation: "clone" is roughly equivalent to "init + remote add +
> checkout". Separating the three steps will allow for the -f (--force)
> option on "remote add" which will ignore already existing files.
> 

Kind of re-sending what I wrote earlier, as I managed to have diverging
HTML and plain text alternatives in my previous email (facepalm).

I wouldn't bother to get all these details right and instead just clone
somewhere else and move files into place, e.g.:

  cd /usr/ports
  git clone https://git.freebsd.org/ports.git removeme
  mv removeme/.* removeme/* .
  rmdir removeme
  git status
  git pull

Note that "Invalid Arguments" errors are expected on the mv command
(this could be replaced by a fancy find command, like `find removeme \
-mindepth 1 -maxdepth 1 -exec mv {} . \;`, but this was easier).

Also, in case "git status" shows something like "Untracked filed
.sujournal", add ".sujournal" to your global git excludes file.

Example:

  git config core.excludesFile=$HOME/.gitexcludes
  echo .sujournal >>$HOME/.gitexcludes

In case you don't want to override the excludesFile setting, alter one
of the config files in the default global location
$XDG_CONFIG_HOME/git/ignore[0].

Best,
Michael

[0] `man git-config` says:
   core.excludesFile
   Specifies the pathname to the file that contains patterns to
   describe paths that are not meant to be tracked, in addition
   to .gitignore (per-directory) and .git/info/exclude. Defaults to
   $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either
   not set or empty, $HOME/.config/git/ignore is used instead. See
   gitignore(5).


___
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: cannot git clone into /usr/ports when separate filesystem

[Michael Gmelin]

On Tue, 6 Apr 2021 18:40:44 +0200 (CEST)
Marco Beishuizen  wrote:

> On Tue, 6 Apr 2021, the wise Helge Oldach wrote:
> 
> > Marco Beishuizen wrote on Tue, 06 Apr 2021 15:59:48 +0200 (CEST):  
> >> To avoid possible future problems I placed .sujournal into
> >> $HOME/.gitexcludes as you suggested.  
> >
> > That would work as there is no good reason a .sujournal file would
> > be tracked by any git repo on your system but is kind of an odd
> > placement. I would have added it to /usr/ports/.gitignore - that's
> > the common file name, and this exclusion is obviosuly not global or
> > system related, but specific to your /usr/ports repo being on a
> > file system mount point.

It's very common for .gitgnore to be checked into repos, so local
customizations should never go there. Unsurprisingly, the FreeBSD ports
repo also comes with a .gitignore file, see:
https://cgit.freebsd.org/ports/tree/.gitignore

So you really don't want to touch this for your local changes. Like I
suggested, I would place .sujournal in my user's global exclusion file,
as IMHO this is very specific to the system in question (and as
.sujournal is something you never would want in any repo). If you
really want to store this for some reason inside the /usr/ports tree
(and lose the setting, next time you do a fresh checkout and long have
forgotten about it), you would place it in /usr/ports/.git/info/exclude.

Best,
Michael

> 
> Ok thanks. Will do that.
> 
> Regards,
> Marco
> 



-- 
Michael Gmelin
___
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: cannot git clone into /usr/ports when separate filesystem

[Michael Gmelin]

Hi Jose,

On Tue, 6 Apr 2021 08:33:27 -0700
Jose Quinteiro  wrote:

> On 4/6/21 6:28 AM, Michael Gmelin wrote:
> > Example:
> > 
> >   git config core.excludesFile=$HOME/.gitexcludes
> >   echo .sujournal >>$HOME/.gitexcludes
> > 
> > In case you don't want to override the excludesFile setting, alter
> > one of the config files in the default global location
> > $XDG_CONFIG_HOME/git/ignore[0].
> >   
> The default name for these files is .gitignore. A file with that name
> in your home directory will be honored in all git repositories with no
> further configuration.

This information is not correct.

Example:

  [root@testhost /usr/ports]# cat $HOME/.gitconfig
  [user]
  email = free...@grem.de
  name = Michael Gmelin
  [root@testhost /usr/ports]# cat $HOME/.gitignore
  t.ignoreme
  [root@testhost /usr/ports]# touch t.ignoreme
  [root@testhost /usr/ports]# git status
  On branch main
  Your branch is up to date with 'origin/main'.

  Untracked files:
(use "git add ..." to include in what will be committed)
  t.ignoreme

  nothing added to commit but untracked files present (use "git add" to
  track)
  [root@testhost /usr/ports]# Oh no!

> 
> A file called .gitignore in the current directory will add and/or
> override patterns to/in the global .gitignore in your home directory.
> See
> 
> https://git-scm.com/docs/gitignore

You link to the correct man page. This man page describes the behavior
perceived in the example above accurately though (and also repeats parts
of what I quoted from git-config(1) about the default locations of these
files in in my previous email):

  "Which file to place a pattern in depends on how the pattern is meant
  to be used:

  - Patterns which should be version-controlled and distributed to other
repositories via clone (i.e., files that all developers will want to
ignore) should go into a .gitignore file.
  - Patterns which are specific to a particular repository but which do
not need to be shared with other related repositories (e.g.,
auxiliary files that live inside the repository but are specific to
one user's workflow) should go into the $GIT_DIR/info/exclude
file.
  - Patterns which a user wants Git to ignore in all situations (e.g.,
backup or temporary files generated by the user's editor of choice)
generally go into a file specified by core.excludesFile in the
user's ~/.gitconfig. Its default value is
$XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set
or empty, $HOME/.config/git/ignore is used instead."

   -- Quoted from gitignore(5)

As you can see, $HOME/.gitignore is not part of it. As .gitignore is
meant to be checked into repos, I would also advise against setting
`core.excludesFile=$HOME/.gitignore'. Instead I would either set it to
a distinct filename (e.g., $HOME/.gitexcludes) or stick with the
default location ($HOME/.config/git/ignore) for per-user global
excludes.

Best,
Michael
___
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: Deprecation of portsnap (was: Proposed ports git transition schedule)

[Michael Gmelin]

> On 12. Apr 2021, at 13:12, Peter Jeremy via freebsd-ports 
>  wrote:
> 
> On 2021-Apr-11 14:27:27 +0200, Helge Oldach  wrote:
>> Peter Jeremy via freebsd-ports wrote on Sun, 11 Apr 2021 00:52:11 +0200 
>> (CEST):
>>> Following the SVN to GIT migration, portsnap is now the only practical
>>> way to use ports on a low-memory system.  I've done some experiments
>>> and standard git has a 2GB working set to checkout a ports tree.
>> 
>> However checking out is a one-time action with ports as there is only
>> one branch (switching frequently between main and quarterly is probably
>> not very sensible on a limited machine). git pull is significantly more
>> lightweight, I've just seen some 200M RSS. That should work well even on
>> a 512M machine. Probably much better than gitup in constrained memory?
> 
> Except that git will arbitrarily and randomly decide that it needs to
> run "gc" -

See https://git-scm.com/docs/git-gc for an explanation of how git decides when 
to run gc and how you can control it (e.g., by setting gc.auto to 0).

-m

> which is similarly extravagant in memory usage.  Last time
> I found one running, it thrashed that poor VM for 3 days.
> 
> Ignoring that, a "git up -ff" on a ports tree peaks with 2×1GB processes,
> though it looks like the working set size might only be ~350MB.
> 
> -- 
> Peter Jeremy
___
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: Deprecation of portsnap (was: Proposed ports git transition schedule)

[Michael Gmelin]

> On 14. Apr 2021, at 00:54, Dave Horsfall  wrote:
> 
> On Mon, 12 Apr 2021, Peter Jeremy via freebsd-ports wrote:
> 
>> Except that git will arbitrarily and randomly decide that it needs to run 
>> "gc" - which is similarly extravagant in memory usage.  Last time I found 
>> one running, it thrashed that poor VM for 3 days.
> Would this be a good time to mention the https://ohshitgit.com/ site? 
> Warning: it contains strong language...

I prefer this site: https://git-man-page-generator.lokaltog.net/

-m

> 
> -- Dave
> ___
> 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: Ports recompile for 13.0-RELEASE

[Michael Gmelin]

On Tue, 4 May 2021 08:10:38 -0600
"@lbutlr"  wrote:

> With the move to FreeBSD 13.0 is there a simple (single step) way to
> reinstall all the current ports other than saving off a list of the
> ports and then stepping through that list to reinstall them?
> It was very inefficient when moving to 12.0 as many ports in the
> list, of course, were dependent on other ports, but then got
> recompiled, sometimes multiple times. I know I ended up in a make
> loop where came was compiled over and over again until I aborted,
> listed the current ports, differ on the previous ports, and picked a
> port I though would have a lot of reps to restart the compile. I then
> did this several more times to get back to where I had been on 11.x

Using a local poudriere repo fixes all of the above ;)

> 
> And there's still no way to tell if a port was installed from pkg or
> from ports, correct? Since I use MariaDB instead of MySQLI have to be
> sure I don't try to use package for anything that will try to install
> MySQL instead.

The repository the package came from is stored in the annotation tag
named "repository".

You can see this, e.g., by using

  pkg query "%n %At %Av"

or

  pkg info -R 

By default this is "FreeBSD" for the official repos. If you install
locally ("make install"), it's not set.

> 
> And finally, the release of 13.0 ends the 12.x versions, right? There
> will not be a 12.3.

See https://www.freebsd.org/security/#sup, there will be a 12.3.

> 
> (And yes, I've tried moving to poudrerie several times and we do not
> get on. At all.)

Well, that's the recommended way of doing what you're trying to
accomplish, otherwise you'll be in dependency hell like we've all
been updating our machines in the 2000s.

Alternatively, you could create a jail or VM manually, install all
packages you need in there from ports using make install. You
can retrieve the list of what you need on your target host using

  pkg query -e "%a = 0" %o

Then run "pkg create -a" on that machine to get a set of all binary
packages. Then copy those over to your target machine and install them
using pkg add. Will be messy, but kind of work. I really would prefer
poudriere over that though.

Best
Michael

-- 
Michael Gmelin
___
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: Maintainer timeout on textproc/py-markdown update on Bugzilla - safe to commit?

[Michael Gmelin]

> On 4. May 2021, at 22:45, Neel Chauhan  wrote:
> 
> Hi,
> 
> There is an update to the port textproc/py-markdown but the maintainer, 
> koobs@ has not responded even when (I believe) it could be committed.
> 
> Bugzilla PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239070
> 
> Assuming no dependent ports have an issue with this update, would it be safe 
> to commit this with a maintainer timeout if koobs@ hasn't responded?
> 
> I'm asking since I don't want to prematurely commit ports.
> 
> This port needs to be updated in order to import GTK+ 4 which in turn needs 
> to update x11-toolkits/pango (which in turn needs this update).
> 

Cc Koobs - looking at the pr, it seems like it was complicated and a lot of 
other work had to be done first.

-m


> -Neel (nc@)
> ___
> 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: Making a port to use OpenSSL of ports collection on FreeBSD 11.x

[Michael Gmelin]

> On 4. May 2021, at 21:50, Yasuhiro Kimura  wrote:
> 
> Hello,
> 
> Of the currently supported FreeBSD versions, base system of FreeBSD
> 11.x uses OpenSSL 1.0.2 and that of FreeBSD 12.x or later use OpenSSL
> 1.1.1.
> 
> Then when new version of an application dropped suport of OpenSSL
> 1.0.2, is there any way to make the port of it to use OpenSSL of ports
> collection if the system is FreeBSD 11.x?
> 

See https://docs.freebsd.org/en/books/porters-handbook/uses/#uses-ssl

Best

> Best Regards.
> 
> ---
> Yasuhiro Kimura
> ___
> 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: Making a port to use OpenSSL of ports collection on FreeBSD 11.x

[Michael Gmelin]

On Wed, 05 May 2021 23:22:08 +0900 (JST)
Yasuhiro Kimura  wrote:

> From: Michael Gmelin 
> Subject: Re: Making a port to use OpenSSL of ports collection on
> FreeBSD 11.x Date: Tue, 4 May 2021 23:05:06 +0200
> 
> > See
> > https://docs.freebsd.org/en/books/porters-handbook/uses/#uses-ssl
> > 
> > Best  
> 
> I checked it but couldn't find proper solution.
> 
> I think what is necessary in my case is something like version-spec
> argument of 'USES=python'.
> 
> For example, if 'USES=python:3.8+' is specified in Makefile of a port,
> lang/python38 is used for it even if user sets
> 'DEFAULT_VERSIONS+=python=3.7' in /etc/make.conf.
> 
> But 'USES=ssl' doesn't provide such argument.

Which port are you talking about by the way?

This worked for me just fine in the past (placed in make.conf):

  DEFAULT_VERSIONS+=ssl=libressl

for LibreSSL and

  DEFAULT_VERSIONS+=ssl=openssl

for openssl from ports.

See also:

$ head -n12 /usr/ports/Mk/Uses/ssl.mk 
# Handle dependency on *ssl ports.
#
# Feature:  SSL_DEFAULT
# Usage:USES=ssl
# Valid ARGS:   none (build and run), build, run
#
# The user can choose which ssl library he wants with:
#
# DEFAULT_VERSIONS+=ssl=
#
# Variants being base, openssl, libressl, and libressl-devel.
#

Cheers,
Michael

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



-- 
Michael Gmelin
___
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: Making a port to use OpenSSL of ports collection on FreeBSD 11.x

[Michael Gmelin]

> On 5. May 2021, at 18:56, Stefan Esser  wrote:
> 
> Am 05.05.21 um 18:00 schrieb Yasuhiro Kimura:
>> You misunderstand my intention. What I would like to do is to make a
>> port use security/openssl instead of base OpenSSL even if user sets
>> 'DEFAULT_VERSIONS+=ssl=base' in /etc/make.conf (or user doesn't
>> customize setting about ssl at all).

Stefan‘s suggestion is AFAIK the best we can do.

mail/opensmtpd has an example of that, but it still requires the user to 
actively select the OpenSSL library (mixing OpenSSL libraries in a package set 
is problematic).

Best,
Michael

> 
> You can mark the port as broken if the user has selected "base" and
> this is incompatible with the port's requirements. E.g.:
> 
> .include 
> 
> .if ${SSL_DEFAULT} == base
> BROKEN_FreeBSD_11=  OpenSSL 1.1 required
> .endif
> 
> .include 
> 
> You can of course add a better message, and the user can decide to
> try the compilation again after changing the default. But this will
> of course prevent the building of official packages for FreeBSD-11.
> 
>> As I wrote previous mail, if 'USES=python:3.8+' is specified in
>> Makefile of a port, lang/python38 is used for the port event if user
>> adds 'DEFAULT_VERSIONS+=python=3.7' in /etc/make.conf. I'm looking for
>> similar way about ssl setting.
> 
> You could add a dependency on the openssl port and make sure, that
> the port's include file and library is used in preference of the
> base version on FreeBSD-11.
> 
> But you have to consider the risk of mixing references to the base and
> the ports version in one binary (e.g. other libraries are linked in that
> had been built against the base version).
> 
> Regards, STefan
> 

___
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

[Michael Gmelin]

> On 5. May 2021, at 20:25, Christian Weisgerber  wrote:
> 
> On 2021-05-04, 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.
> 
> pkg-which(1)
> 
> $ pkg which /usr/local/bin/g-ir-scanner
> /usr/local/bin/g-ir-scanner was installed by package 
> gobject-introspection-1.66.1,1
> 

This only works if the package it came from is still installed. Robert was 
trying to find the package that will give him that file, as he deleted that 
package by accident.

Best
Michael

> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> ___
> 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: Additional filtering on pkg-status.freebsd.org url

[Michael Gmelin]

On Sat, 8 May 2021 17:46:03 +0800
Simon Wright  wrote:

> Hi all,
> 
> The move to git for ports is more or less OK for me now, thanks to
> several for the various pointers. I still have issues with accessing
> the individual build machine due to IPv6 issues on my side so am using
> pkg-status.freebsd.org to check the status of the build cluster rather
> than the specific machine that is building for my desired
> architecture.
> 
> My (minor) issue now is that accessing:
> 
> https://pkg-status.freebsd.org/builds?type=package
> 
> gives me a long list of builds. I'm looking for a way to pass a search
> string of '130amd64' in the URL so that I can go straight to the
> builds that I'm interested in. Is this possible? Encoding
> 
> AND Search='130amd64'
> 
> in the URL does not work. Can anyone point me in the right direction
> for this?

Does this show what you want?

https://pkg-status.freebsd.org/builds?jailname=130amd64&type=package

Best

> 
> Thanks,
> 
> Simon Wright.
> ___
> 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"



-- 
Michael Gmelin
___
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 there a way to subscribe to the commit messages for only ports you maintain?

[Michael Gmelin]

On Tue, 18 May 2021 03:17:03 +0200
"Julian H. Stacey"  wrote:

> Chris wrote:
> > On 2021-05-17 16:30, Jan Beich wrote:  
> > > Chris  writes:
> > >   
> > >> I'd like to subscribe to the commit messages
> > >> ( dev-commits-ports-all )
> > >> but only receive messages that affect me -- the
> > >> ports I currently maintain. Is it possible? Or
> > >> am I just dreaming? ;-)  
> > > 
> > > No clue but I use Herald rules for something similar.  
> > Thanks for the hints, Jan. :-)  
> 
> Herald ? Nothing from
>   https://www.freebsd.org/cgi/ports.cgi?query=herald&stype=all&sektion=all
> ...
>   https://en.wikipedia.org/wiki/Phabricator
> ...
>   https://cgit.freebsd.org/ports/tree/devel/phabricator/pkg-descr

Google "phabricator herald"[0] :)

It's part of phabricator and quite useful for automation, see
https://reviews.freebsd.org/herald/create/

In Chris' case, he would probably create one or more personal commit
rules:
https://reviews.freebsd.org/herald/edit/?content_type=commit&rule_type=personal

  Rule Name: Inform me about changes to my ports
  When **all of** these conditions are met:
  **Repository** **is any of** R11 FreeBSD ports repository
  **Affected Files** **matches regexp** @devel/myporta|sysutils/myportb@

  Take these actions **every time this rule matches:**
  **Send me an email**

  Click Save Rule

Mind the special regexp syntax.

I created a publicly visible rule as an example:
https://reviews.freebsd.org/H142

You can test your rules on the test console:
https://reviews.freebsd.org/herald/test/

(you would enter an existing commit id in there for testing, e.g.,
R11:305f148f482daf30dcf728039d03d019f88344eb)

Best
Michael

[0] Other ways to discover phabricator apps:
- Enter "herald" in phabricator (search box at the top)
- The phabricator application list
  https://reviews.freebsd.org/applications/

-- 
Michael Gmelin
___
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: reading epub files?

[Michael Gmelin]

On Tue, 13 Nov 2012 13:54:03 -0800
Freddie Cash  wrote:

> Okular, the main document viewer for KDE4, supports ePub.
> On Nov 13, 2012 12:17 PM, "Robert Huff"  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"

deskutils/calibre
deskutils/fbreader




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