from:"Michael"

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

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

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

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

2021-04-02 Thread 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: git-tiny or git-lite - Re: No update for a day on ports?

2021-04-02 Thread 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: devel/git: Git via Apache 2.4 HTTPS - info/refs not valid: could not determine hash algorithm

2021-03-29 Thread 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=0=0=FreeBSD+12.2-RELEASE+and+Ports=default=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: devel/git: Git via Apache 2.4 HTTPS - info/refs not valid: could not determine hash algorithm

2021-03-29 Thread 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=0=0=FreeBSD+12.2-RELEASE+and+Ports=default=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: Testing www/chromium before installing

2021-03-13 Thread 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"

vm-bhyve vale support

2021-03-09 Thread Michael Pounov

Hi Matt Churchyard

I made usable and working vale switch support in vm-bhyve project from FreeBSD 
12 and above.

Now vale switches are near the same behaviour and view as standard and other 
supported types of switches.

If you thinking my contributed code is ok to be part of yours project is free 
to merge, modify and using these patches to the vm-bhyve project.

Best Regards
Michael Pounov

elwix.org
--- /usr/local/lib/vm-bhyve/vm-switch	2020-01-14 12:15:58.0 +0200
+++ vm-switch	2021-03-09 23:43:17.880167000 +0200
@@ -49,7 +49,7 @@
 case "${_type}" in
 vxlan)  switch::vxlan::init "${_switch}" ;;
 manual) switch::manual::init "${_switch}" ;;
-vale)   ;;
+vale)   switch::vale::init "${_switch}" ;;
 *)  switch::standard::init "${_switch}" ;;
 esac
 done
--- /usr/local/lib/vm-bhyve/vm-switch-vale	2020-01-14 12:15:58.0 +0200
+++ vm-switch-vale	2021-03-09 23:43:17.886736000 +0200
@@ -32,26 +32,79 @@
 switch::vale::show(){
 local _name="$1"
 local _format="$2"
-local _id
+local _id _mtu
 
+config::core::get "_ports" "ports_${_name}"
+config::core::get "_bridge" "bridge_${_name}"
+
+[ -n "${_ports}" ] && _mtu=$(ifconfig ${_ports} | awk '($(NF - 1) == "mtu") { printf("%u", $NF); exit }')
+
 switch::vale::id "_id" "${_name}"
-printf "${_format}" "${_name}" "vale" "${_id}" "n/a" "n/a" "n/a" "n/a" "n/a"
+printf "${_format}" "${_name}" "vale" "${_id}" "${_bridge:--}" "n/a" "${_mtu:--}" "n/a" "${_ports:--}"
 }
 
+switch::vale::init(){
+local _name="$1"
+
+config::core::get "_ports" "ports_${_name}"
+config::core::get "_bridge" "bridge_${_name}"
+
+switch::vale::id "_vale" "${_name}"
+
+if [ -n "${_ports}" ]; then
+	valectl -a ${_vale}:${_ports}
+fi
+
+valectl -n ${_bridge}
+valectl -a ${_vale}:${_bridge}
+}
+
 # create a vale switch
 #
 # @param string _switch the name of the switch
 #
 switch::vale::create(){
+local _br="${_bridge}"
 
+switch::vale::id _vale ${_switch}
+
+if [ -n "${_if}" ]; then
+	valectl -a ${_vale}:${_if} || util::err "cannot create vale switch with interface ${_if}"
+	
+	[ -z "${_br}" ] && switch::vale::bridge _br ${_switch}
+fi
+
+if [ -z "${_br}" ]; then
+	valectl -d ${_vale}:${_if}
+	util::err "cannot create vale switch without name for bridge"
+fi
+
+valectl -n ${_br} || util::err "cannot create vale switch bridge interface ${_br}"
+valectl -a ${_vale}:${_br} || util::err "cannot create vale switch with bridge ${_br}"
+
 config::core::set "switch_list" "${_switch}" "1"
 config::core::set "type_${_switch}" "vale"
+
+config::core::set "bridge_${_switch}" "${_br}"
+[ -n "${_if}" ] && config::core::set "ports_${_switch}" "${_if}"
 }
 
 # remove a vale switch
 #
-switch::vale::remove(){ }
+switch::vale::remove(){
+config::core::get "_if" "ports_${_switch}"
+config::core::get "_br" "bridge_${_switch}"
 
+switch::vale::id _vale ${_switch}
+
+valectl -d ${_vale}:${_br}
+valectl -r ${_br}
+
+[ -n "${_if}" ] && valectl -d ${_vale}:${_if}
+
+return 0
+}
+
 # add a new interface to this switch
 # at the moment we require the user to manually
 # set up any vale switches
@@ -60,7 +113,14 @@
 # @param string _if the interface to add
 #
 switch::vale::add_member(){
-util::err "physical interfaces must be added to the vale switch manually"
+config::core::get "_chkif" "ports_${_switch}"
+[ -n "${_chkif}" ] && util::err "we already have physical interface attached to the vale switch"
+
+switch::vale::id _vale ${_switch}
+
+valectl -a ${_vale}:${_if} || util::err "physical interfaces must be added to the vale switch manually"
+
+config::core::set "ports_${_switch}" "${_if}"
 }
 
 # remove an interface
@@ -69,7 +129,14 @@
 # @param string _if the interface to remove
 #
 switch::vale::remove_member(){
-util::err "physical interfaces must be removed from the vale switch manually"
+config::core::get "_chkif" "ports_${_switch}"
+[ "${_chkif}" != "${_if}" ] && util::

Re: having trouble "svn up"-ing /usr/ports/

2021-02-06 Thread Michael Schuster

On Fri, Feb 5, 2021 at 8:29 PM Guido Falsi  wrote:

> On 05/02/21 18:11, Michael Schuster wrote:
> > Hi,
> >
> > sorry if this is the wrong group - please point me to the proper place if
> > that's the case.
> >
> > I updated to Current (14) on Feb 2nd from source (including running
> > mergemaster)
> >
> > Since at least yesterday any attempt at "svn up" in /usr/ports either
> times
> > out, or rather, fails after some time (over a minute) with:
> > "svn: E170013: Unable to connect to a repository at URL '
> > https://svn.freebsd.org/ports/head/graphics'
> > svn: E120108: Error running context: The server unexpectedly closed the
> > connection."
> > or just "hangs", ie doesn't do anything but has one core quite busy, and
> > when I truss it, I see it opening /etc/ssl/cert.pem over and over again
> (~
> > 10 per second)
> >
> > I just checked https://cgit.freebsd.org/; ports isn't there yet, so I
> would
> > assume that svn still holds source code for me :-)
> >
> > Can anyone point out where I need to investigate, or what I may be doing
> > wrong ... any and all hints appreciated!
> > thx
> > Michael
> >
>
> You could have been hit by this bug:
>
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253135
>
> You should update to a more recent head (after commit cb7cc72c546e) and
> also make sure you have the www/serf PORTREVISION 6 or later
> (serf-1.3.9_6 or newer)
>

that did it, thanks!
Michael
-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'
___
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"

having trouble "svn up"-ing /usr/ports/

2021-02-05 Thread Michael Schuster

Hi,

sorry if this is the wrong group - please point me to the proper place if
that's the case.

I updated to Current (14) on Feb 2nd from source (including running
mergemaster)

Since at least yesterday any attempt at "svn up" in /usr/ports either times
out, or rather, fails after some time (over a minute) with:
"svn: E170013: Unable to connect to a repository at URL '
https://svn.freebsd.org/ports/head/graphics'
svn: E120108: Error running context: The server unexpectedly closed the
connection."
or just "hangs", ie doesn't do anything but has one core quite busy, and
when I truss it, I see it opening /etc/ssl/cert.pem over and over again (~
10 per second)

I just checked https://cgit.freebsd.org/; ports isn't there yet, so I would
assume that svn still holds source code for me :-)

Can anyone point out where I need to investigate, or what I may be doing
wrong ... any and all hints appreciated!
thx
Michael
-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'
___
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?

2021-02-02 Thread 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: List of packages upgraded last time `pkg upgrade` was executed

2021-01-27 Thread 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: List of packages upgraded last time `pkg upgrade` was executed

2021-01-27 Thread 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"

Step back as maintainer

2021-01-05 Thread Michael Beer


Hi,

because of lack of time, I step back as the maintainer of following ports:
devel/sord
audio/sratom
audio/lilv
audio/suil
audio/lv2
audio/ardour6

Volunteers feel free to take over the one or other!

Regards,
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: REINPLACE_CMD QA causing pkg-fallout

2021-01-04 Thread 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=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: REINPLACE_CMD QA causing pkg-fallout

2021-01-04 Thread 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=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"

REINPLACE_CMD QA causing pkg-fallout

2021-01-02 Thread 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=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: portmaster new development

2020-12-28 Thread Michael Grimm

Hi

> On 28. Dec 2020, at 21:41, Stefan Esser  wrote:
> 
> Poudriere works best on sufficiently powerful build servers and it
> often requires rebuilding dependencies over hours when I just want to
> test a new port before committing it.

Excuse me, but that is not true in this generality. I do run poudriere on ZFS 
in a cloud instance with 7G of memory and a CPU of 2.1 MHz. Never had to wait 
for more then one hour for recompiling *all* of my 240+ ports for STABLE-12. 
YMMV, yes, but stating that in that totality is nonsense, at least IMHO.

Regards,
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: portmaster new development

2020-12-27 Thread Michael Grimm

Matthias Apitz  wrote:
> El día domingo, diciembre 27, 2020 a las 09:22:42a. m. +0100, Kurt Jaeger 
> escribió:

>> That works as well. I have a checkout of the ports tree, use
>> make config to define non-default port options. This stores the
>> selected OPTIONs in /var/db/ports/, and poudriere uses those options
>> just fine.

> Re/ the options, I copy them into the jail with something like this
> procedure:
> 
> # cd /usr/ports/mail/mutt
> # make config
> 
> # mkdir -p /usr/local/etc/poudriere.d/freebsd-head-options/mail_mutt
> # cp /var/db/ports/mail_mutt/options 
> /usr/local/etc/poudriere.d/freebsd-head-options/mail_mutt
> 
> 'freebsd-head' is the name of the poudriere jail (I have some of them)
> and the ports options stay there, as well the make.conf options in
> /usr/local/etc/poudriere.d/freebsd-head-make.conf


I am following stable, and my jail's name has been set to stable.

All of poudriere's settings/configs are kept in:

/usr/local/etc/poudriere.d

Whenever I do feel the need for non-default port options, I do use poudriere's 
functionality to define and store those options:

poudriere options -n -j stable mail/postfix

These non-default options are then put into:

/usr/local/etc/poudriere.d/stable-options/mail_postfix

This way one can keep separate options for different jails in one space. But, 
there are obviously different approaches possible ;-)

Regards,
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: portsnap

2020-12-26 Thread Michael Schuster

On Sat, Dec 26, 2020, 20:04 LuMiWa via freebsd-ports <
freebsd-ports@freebsd.org> wrote:

> On Sat, 26 Dec 2020 19:51:37 +0100
> Stefan Esser  wrote:
>
> > Am 26.12.20 um 18:41 schrieb LuMiWa via freebsd-ports:
> > > Hi!
> > >
> > > Today I red again an email:
> > >
> > > Subject:[HEADS UP] Planned deprecation of portsnap
> > > From:   Steve Wills 
> > > Date:   2020-08-04 18:43:20
> > >
> > > And as portsnap user I have a question: Do they planning
> > > deprecation of portmaster too?
> >
> > No, I'm actively working on portmaster and have rewritten it from
> > scratch for better performance (and additional features, e.g. building
> > in a clean chroot jail, similar to synth or poudriere).
> >
> > I have been using that version for more than one year, but the
> > functionality is not complete, yet.
> >
> > On a test system with > 2200 installed ports it takes less than 10
> > seconds to identify the ~600 out-of-date ports (that I keep in this
> > state for testing of the upgrade strategy function), which is more
> > than 30 times faster than the same operation with the "official"
> > portmaster.
> >
> > Until completion of that version, I'll continue to maintain and
> > update the current portmaster port ...
> >
> > Regards, STefan
> >
>
> ...and I will continue to use portmaster. But I don't understand why
> we should no keep portsnap.
>

IIRC, there was an email a while ago announcing the discontinuation of
portsnap and explaining the reasoning behind this move.

Regards
Michael


> --
> “Waiter! A cup of coffee without cream, please!
> I’m sorry, sir, we have no cream, only milk, so can it be a coffee
> without milk?”
>
> ― Ernst Lubitsch’s Ninotchka
> ___
> 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: SVN r556157 breaks firefox, thunderbird

2020-11-25 Thread Michael Butler via freebsd-ports


On 11/24/20 10:21 PM, Jan Beich wrote:

Michael Butler via freebsd-ports  writes:


The removal of the packed_simd patch might be premature.

I now cannot build either firefox or thunderbird. Both fail with
something like ..

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `packed_simd`


Can you reproduce after https://svnweb.freebsd.org/changeset/ports/556251 ?


They build correctly - thanks,

imb


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

SVN r556157 breaks firefox, thunderbird

2020-11-24 Thread Michael Butler via freebsd-ports


The removal of the packed_simd patch might be premature.

I now cannot build either firefox or thunderbird. Both fail with 
something like ..


error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `packed_simd`

imb

___
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: botan2-2.17.1 error build

2020-11-12 Thread Michael Butler via freebsd-ports

Uninstall the previous version and rebuild. It will complete and install 
successfully,


imb

On 11/12/20 8:29 PM, Alex V. Petrov wrote:

c++ -L/usr/local/lib -fstack-protector -pthread build/obj/cli/argon2.o
build/obj/cli/asn1.o build/obj/cli/bcrypt.o build/obj/cli/cc_enc.o
build/obj/cli/cli.o build/obj/cli/cli_rng.o build/obj/cli/codec[10/1463]
obj/cli/compress.o build/obj/cli/encryption.o build/obj/cli/entropy.o
build/obj/cli/hash.o build/obj/cli/hmac.o build/obj/cli/main.o
build/obj/cli/math.o build/obj/cli/pbkdf.o build/obj/cli/pk_crypt.o
build/obj
/cli/psk.o build/obj/cli/pubkey.o build/obj/cli/roughtime.o
build/obj/cli/sandbox.o build/obj/cli/speed.o
build/obj/cli/timing_tests.o build/obj/cli/tls_client.o
build/obj/cli/tls_http_server.o build/obj/cli/tl
s_proxy.o build/obj/cli/tls_server.o build/obj/cli/tls_utils.o
build/obj/cli/tss.o build/obj/cli/utils.o build/obj/cli/x509.o -pthread
-Wl,-rpath,/usr/local/lib -fstack-protector-strong  -L. -lbotan-2 -lboost_s
ystem -lbz2 -lcrypto -llzma -lz -o botan


ld: error: undefined symbol: Botan::Stateful_RNG::add_entropy(unsigned
char const*, unsigned long)


referenced by cli_rng.cpp






build/obj/cli/cli_rng.o:(Botan_CLI::cli_make_rng(std::__1::basic_string, std::__1::allocator > const&,
std::__1::basic_string, std::__1::allocator > const&))





ld: error: undefined symbol:
Botan::HMAC_DRBG::HMAC_DRBG(std::__1::basic_string, std::__1::allocator > const&)


referenced by speed.cpp
   build/obj/cli/speed.o:(Botan_CLI::Speed::go())



ld: error: undefined symbol: Botan::vartime_divide(Botan::BigInt const&,
Botan::BigInt const&, Botan::BigInt&, Botan::BigInt&)


referenced by speed.cpp


build/obj/cli/speed.o:(Botan_CLI::Speed::bench_mp_div(std::__1::chrono::duration >))


referenced by speed.cpp


build/obj/cli/speed.o:(Botan_CLI::Speed::bench_mp_div10(std::__1::chrono::duration >))

ld: error: undefined symbol: Botan::operator/(Botan::BigInt const&,
unsigned long)


referenced by speed.cpp


build/obj/cli/speed.o:(Botan_CLI::Speed::bench_random_prime(std::__1::chrono::duration >))

referenced by speed.cpp


build/obj/cli/speed.o:(Botan_CLI::Speed::bench_random_prime(std::__1::chrono::duration >)::'lambda3'()::operator()() const)

ld: error: undefined symbol:
Botan::ASN1_Time::ASN1_Time(std::__1::chrono::time_point > >
const&)

referenced by x509.cpp
   build/obj/cli/x509.o:(Botan_CLI::Sign_Cert::go())



referenced by x509.cpp
   build/obj/cli/x509.o:(Botan_CLI::Sign_Cert::go())



ld: error: undefined symbol:
Botan::X509_CA::sign_request(Botan::PKCS10_Request const&,
Botan::RandomNumberGenerator&, Botan::ASN1_Time const&, Botan::ASN1_Time
const&) const

referenced by x509.cpp
   build/obj/cli/x509.o:(Botan_CLI::Sign_Cert::go())


c++: error: linker command failed with exit code 1 (use -v to see
invocation)

gmake[2]: *** [Makefile:73: botan] Error 1

gmake[2]: Leaving directory
'/usr/ports/security/botan2/work/Botan-2.17.1'


*** Error code 1

Stop.
make[1]: stopped in /usr/ports/security/botan2

*** Error code 1



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

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

2020-09-17 Thread 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"

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

2020-09-16 Thread 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?

2020-09-01 Thread 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: Squid 4.13 (security update)

2020-08-31 Thread 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?

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

2020-08-26 Thread 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=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"

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

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

2020-08-16 Thread 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=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"

Re: Error: MOVED: net/kblog EXPIRED 2020-08-13 No longer shipped

2020-08-15 Thread 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=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: [HEADS UP] Planned deprecation of portsnap

2020-08-10 Thread 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: [HEADS UP] Planned deprecation of portsnap

2020-08-07 Thread 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

2020-08-07 Thread 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

2020-08-06 Thread 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

2020-08-05 Thread 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"

postfix-current marked erroneously broken for 12.1-STABLE and OpenSSL 1.1.1g

2020-07-27 Thread Michael Grimm

Hi,

postfix-current has been marked broken recently:

BROKEN_FreeBSD_11= error: OpenSSL-1.1.1 is the minimum supported 
version
 

My system:

root>   uname -v
FreeBSD 12.1-STABLE r363443 CUSTOM 

root>   openssl version
OpenSSL 1.1.1g  21 Apr 2020

root>   grep openssl /usr/local/etc/poudriere.d/stable-make.conf 
DEFAULT_VERSIONS+= ssl=openssl


The patch applied fixed it for me, but I am not sure whether it fixes it in all 
thinkable combinations of OSVERION and openssl version, though.

Regards,
Michael




Makefile-postfix-curretn.patch
Description: Binary data
___
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

2020-07-21 Thread 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: amdgpu on Ryzen 4700 w. Vega10 Renoir Graphics

2020-07-16 Thread Michael Schuster

Hi all,

I know I'm top-posting (this note) AND cross-posting - please bear(sp?)
with me, I think I'm somewhat justified:


On Wed, Jul 15, 2020 at 9:46 PM Niclas Zeising 
wrote:

>
> > On 2020-07-15 14:25, Michael Schuster wrote:
> >  > Hi all,
> >  >
> >  > I got a new HP laptop (455 G7) and put latest GhostBSD
> > (20.04, based on
> >  > 12.1 release) on it. During installation, the only graphics
> > selection that
> >  > didn't fail was 'scfb', which I'm still using.
> >  >
> >  > AFAICT from my research, Renoir is supported by latest drm
> > driver/module,
> >  > so I installed that (
> >  >
> > https://github.com/FreeBSDDesktop/kms-drm/tree/drm-v5.0-fbsd12.1
> ).
> >
> > That branch isn't used, and may be broken.
> > If you want to get anything more recent than drm-fbds12.0-kmod,
> > which
> > tracks Linux 4.16, you have to upgrade to current and use
> > drm-devel-kmod
> > (which currently is at 5.3).
> >
> >
> > just to be clear: by "current", you mean FreeBSD 13.0-current, right?
> > thx
> >
> >
> > so I went ahead and installed FreeBSD-current on this machine, and then
> > drm-devel-kmodas you recommended. Alas, I'm getting an error:
> >
> > KLD amdgpu.ko: depends on kernel - not available or version mismatch
> >
> > some googling showed that - since I did a fresh install of -current just
> > now - amdgpu must be out of sync. the version I have installed is:
> >
> > xf86_video-amdgpu-19.1.0_1.
>
> This means that your kernel and the drm-devel-kmod package are out of
> sync.  drm-devel-kmod installs the kernel graphics drivers, such as
> amdgpu.ko, and it has to be in sync with your kernel.  Depending a bit
> on which svn revision of current you have, you should be able to build
> drm-devel-kmod (and preferably gpu-firmware-kmod) from ports.


@Niclas,
I followed your instructions; when I try to build gpu-firmware-kmod, here's
what I get:

ports/graphics/gpu-firmware-kmod:16:33:50 $ pwd
/usr/ports/graphics/gpu-firmware-kmod
ports/graphics/gpu-firmware-kmod:16:33:51 $ make
make: "/usr/ports/Mk/bsd.port.mk" line 2096: warning: String comparison
operator should be either == or !=
make: "/usr/ports/Mk/bsd.port.mk" line 2096: Malformed conditional
(defined(MAKE_JOBS_NUMBER_LIMIT) && ( ${MAKE_JOBS_NUMBER_LIMIT} <
${_MAKE_JOBS_NUMBER} ))
make: Fatal errors encountered -- cannot continue
make: stopped in /usr/ports/graphics/gpu-firmware-kmod

@ports:
I found
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=51789+0+current/freebsd-ports
(which points to contrib/bmake svn commit: r363031). I 'git clone'd
/usr/src this morning (European time) and find "reverted r363031" in the
logs, so I would have assumed this is fixed ... though perhaps not in a way
I can make use of. Doing "sudo ./boot-strap" in contrib/bmake didn't help
(I don't know whether it should have .. it seemed the next logical step).

so, in short, what can I do to get back to building ports?

TIA
Michael
-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'
___
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"

latest Makefile breaks compilation of security/clamav if base is lacking sendmail

2020-07-05 Thread Michael Grimm

Hi,

I am running 12.1-STABLE (r362940), ports head (541271) and compile all my 
ports with poudriere-devel

My /etc/src.conf contains …

WITHOUT_SENDMAIL=yes

… thus I do not have /usr/lib/libmilter.so in base.

The recent modification of security/clamav/Makefile breaks my setup (again [1], 
see 
https://lists.freebsd.org/pipermail/freebsd-ports/2018-December/115116.html).

Error message ...

checking for mi_stop in -lmilter… no
configure: error: Cannot find libmilter
...
*** Error code 1

… and after having that fixed another error:

checking for mi_stop in -lmilter… yes
checking libmilter/mfapi.h usability… no
checking libmilter/mfapi.h presence… no
checking for libmilter/mfapi.h… no
configure: error: Please install mfapi.h from the sendmail distribution
===>  Script "configure" failed unexpectedly.
...
*** Error code 1


I managed to get compilation working with the attached, surely crude and dirty 
hack (due to my lack of knowledge regarding ports Makefiles), by adding 
'MILTER_LDFLAGS= -L${LOCALBASE}/lib' and 'MILTER_CFLAGS= 
-I${LOCALBASE}/include'  in order to help finding relevant files from port 
mail/libmilter.

What worries my somehow, although clamav is working as usual, is the following 
part in poudrier's log:

checking for mi_stop in -lmilter… yes
checking libmilter/mfapi.h usability… yes
checking libmilter/mfapi.h presence… no
configure: WARNING: libmilter/mfapi.h: accepted by the compiler, 
rejected by the preprocessor!
configure: WARNING: libmilter/mfapi.h: proceeding with the compiler's 
result
checking for libmilter/mfapi.h... yes


Here my question: Is this the right way to fix this issue?

Thanks and regards,
Michael

[1] no pun intended



patch
Description: Binary data
___
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: Recent wordpress, huge compiling effort, needed?

2020-07-01 Thread Michael Grimm

Kurt Jaeger  wrote:

>> The recent update of www/wordpress ended in a compilation 'nightmare', 
>> because this port newly depends on ImageMagick:
> [...]
>> 1) Why does one need this dependency?
> 
> The wordpress install script checks if imagemagick is available, and
> I'm not sure it's still optional.


The only option available currently is whether to build/install the 
documentation

> Does your blog do lots of picture resizings etc ?

No. I am running a rather static website, only. No blog.

>> 3) If 2) is a safe way to use wordpress remotely from a web browser, then 
>> would it possible to remove the dependency by an option? (CC'd this mail to 
>> maintainer)
> 
> Give it a try to use wordpress without that RUN_DEPENDS. If it
> can be installed without it, and you don't need it...

I did install it successfully, already, and everything is working as usual. But 
I wonder if this might break something I didn't run about my tests a couple of 
minutes ago.

Regards,
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"

Recent wordpress, huge compiling effort, needed?

2020-07-01 Thread Michael Grimm

Hi

I am running 12.1-STABLE (r362720), ports (head, revison 540950) and 
poudriere-devel for ports compilations.

The recent update of www/wordpress ended in a compilation 'nightmare', because 
this port newly depends on ImageMagick:

MWN> cat diff-wordpress 
2c2
< # $FreeBSD: head/www/wordpress/Makefile 534850 2020-05-10 13:51:37Z joneum $
---
> # $FreeBSD: head/www/wordpress/Makefile 540837 2020-06-29 22:24:46Z joneum $
5c5
< DISTVERSION=  5.3.3
---
> DISTVERSION=  5.4.2
20c20,21
< USE_PHP=  curl ftp gd hash json mysqli pcre tokenizer xml zip zlib
---
> USE_PHP=  curl exif fileinfo ftp gd hash json mysqli pcre tokenizer xml 
> zip zlib
> RUN_DEPENDS=  
> ${LOCALBASE}/lib/php/${PHP_EXT_DIR}/imagick.so:graphics/pecl-imagick@${PHP_FLAVOR}

Due to this dependeny the following ports need tp be compiled:

devel/llvm80
devel/gobject-introspection
graphics/ImageMagick6-nox11
graphics/cairo
graphics/mesa-libs
graphics/pecl-imagick 
net/avahi-app 
print/cups 
print/ghostscript9-agpl-base 
print/harfbuzz 
print/libraqm

(BTW: llvm80 runs into an error after 2.5 hours compilation time)

Here is my questions:

1) Why does one need this dependency?
2) I could compile and install the updated port by removing RUN_DEPENDS within 
a couple of minutes. 
   Is this a safe approach, though?
3) If 2) is a safe way to use wordpress remotely from a web browser, then would 
it possible to remove the dependency by an option? (CC'd this mail to 
maintainer)

Thanks and regards,
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: Port maintenance

2020-06-29 Thread 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: Port maintenance

2020-06-28 Thread 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: WITH_META_MODE and poudriere: *.meta files, where?

2020-06-23 Thread Michael Grimm

matt...@freebsd.org  wrote:
> On 23/06/2020 12:08, Michael Grimm wrote:

>> Hmm, but that information doesn't help me regarding my question above:
>> Where does poudriere store .meta files during compilations?
>> META_MODE doesn't make sense, IMHO, if this information isn't stored 
>> somewhere before being reused in subsequent compilations of a given port. Or 
>> am I mistaken?
> 
> META_MODE is a feature of building FreeBSD itself, not for building ports.  
> So, unless you're using the rather bleeding edge poudriere(1) work to be able 
> to build base system packages, poudriere is simply not going to be dealing 
> with .meta files.

Thanks, that's what I have "feared": I misunderstood the scope of bdrewery's 
commit regarding /etc/src-env.conf

> What you can do for poudriere is enable CCACHE -- as described in the 
> referenced article.  This makes quite a bit of difference to recompiling some 
> of the bigger ports like LLVM, but will have very little effect on the 
> majority of ports that only take a matter of a few seconds to compile.  Even 
> so, it's well worth doing overall.

My first reaction after anticipating increase in compilation times has been: 
activating CCACHE ;-) 
And thanks again, you clarified yet another "fear" of mine, namely, that it 
will only speed-up larger ports.

Thanks to all,
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: WITH_META_MODE and poudriere: *.meta files, where?

2020-06-23 Thread Michael Grimm

[restored crossposting to ML]

David Wolfskill  wrote:
> On Tue, Jun 23, 2020 at 01:08:30PM +0200, Michael Grimm wrote:

>> ...
>> Hmm, but that information doesn't help me regarding my question above:
>> 
>> Where does poudriere store .meta files during compilations?
> 
> At this point, I'm very confused.
> 
> I use META_MODE for building FreeBSD -- that's why 'WITH_META_MODE=yes'
> is in /etc/src-env.conf.
> 
> I use poudriere for building packages from the ports tree (in a clean
> environment).
> 
> There's no point in the dependency-tracking that META_MODE provides
> when using poudriere, as far as I know.  (poudriere's "granularity"
> is at the port/package level: if a package is outdated, it's removed,
> and a new one built, recursively.)
> 
> I am completely failing to understand how META_MODE and poudriere are
> involved in the same discussion.

Yeah, me as well ;-) 

That's why I want to understand, how this is supposed to work.

I cam across https://github.com/freebsd/poudriere/issues/457 recently:

"Since we stopped pulling in /etc/src-env.conf to poudriere builds, we can't 
benefit from features like WITH_META_MODE. Please implement 
poudriere.d/jail-set-src-env.conf functionality."

And bdrewery reimplemented in 
https://github.com/freebsd/poudriere/commit/1191f9f1356beaa481df9d5db3e8567449840d07

Again, I want to understand how this is supposed to work, or if I have 
misunderstood that commit completey?

Thanks, and regards,
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: WITH_META_MODE and poudriere: *.meta files, where?

2020-06-23 Thread Michael Grimm

Torfinn Ingolfsen  wrote:
> On Mon, Jun 22, 2020 at 8:56 PM Michael Grimm  wrote:

>> I do have activated 'WITH_META_MODE=yes' in > to>/poudriere.d/src-env.conf [1].
>> 
>> Now, I would like to double-check if poudriere is following my "advice". For 
>> buildworld I do find *.meta files in /usr/obj/…, but I do not have any clue 
>> where poudriere would keep this information for subsequent compilations?
>> 
> 
> The is some information here
> https://xmj.github.io/articles/sysadmin/builds_ccache_memcached.html
> and link to a presentation with more about (among otter things)  metamode.

Hmm, but that information doesn't help me regarding my question above:

Where does poudriere store .meta files during compilations?

META_MODE doesn't make sense, IMHO, if this information isn't stored somewhere 
before being reused in subsequent compilations of a given port. Or am I 
mistaken?

Regards,
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"

WITH_META_MODE and poudriere: *.meta files, where?

2020-06-22 Thread Michael Grimm

Hi,

I do have activated 'WITH_META_MODE=yes' in /poudriere.d/src-env.conf 
[1].

Now, I would like to double-check if poudriere is following my "advice". For 
buildworld I do find *.meta files in /usr/obj/…, but I do not have any clue 
where poudriere would keep this information for subsequent compilations?

Any help in understanding this is highly appreciated.

Thanks,
Michael

[1] according 
https://github.com/freebsd/poudriere/commit/1191f9f1356beaa481df9d5db3e8567449840d07
___
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

2020-06-18 Thread 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: cups-pdf crash status -139

2020-06-17 Thread 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

2020-06-16 Thread 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: FreeBSD Port: phabricator-php73-20200514_1

2020-06-16 Thread 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

2020-06-15 Thread 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: cups-pdf crash status -139

2020-06-15 Thread 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: LibreOffice 6.4.4 is coming!

2020-06-11 Thread 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: Recommendation softether

2020-05-15 Thread Michael Butler via freebsd-ports

On 5/15/20 5:50 PM, The Doctor via freebsd-ports wrote:
> This a VPN product yet to be ported to FreeBSD.
> 
> IT is a open source and we can contribute.  Originators:
> 
> University of Tsukba, Japan.
> 

It's already there ..

security/softether-devel Softether VPN 4 (stable beta version)
security/softether SoftEther VPN 4 (RTM version)
security/softether5 SoftEther VPN 5 (Developer Edition)

imb
___
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: Bind 9.16 port error still lingers

2020-05-02 Thread Michael Butler via freebsd-ports

On 5/2/20 11:16 AM, The Doctor via freebsd-ports wrote:
> On Sat, May 02, 2020 at 04:32:10PM +0200, Christoph Moench-Tegeder wrote:
>> ## The Doctor via freebsd-ports (freebsd-ports@freebsd.org):
>>
>>> Subject: Bind 9.16 port error still lingers
>>
>> "Still"?
>>
>>> May  1 21:29:02 gallifrey named[90441]: Required root permissions to open 
>>> '/var/run/named.pid'.
>>> May  1 21:29:02 gallifrey named[90441]: Please check file and directory 
>>> permissions or reconfigure the filename.
>>
>> Did you?
>> BTW the default location for named's pidfile on FreeBSD is
>> /var/run/named/pid.
>>
>>> May  1 21:29:02 gallifrey named[90441]: parser.c:950: REQUIRE(obj != ((void 
>>> *)0) && obj->type->rep == _rep_uint32) failed, back trace
>>
>> Some (configuration) value should be an integer, but isn't.
>>
> 
> cat /var/run/named.pid
> 15640
> 
> running bind911
> 
> and ls -Fail /var/run/named.pid
> 
> -rw-r--r-- 1 root wheel 6 May 1 21:38 /var/run/named.pid

By default, you need 'root' permissions to write to the /var/run
directory. As the port is configured on FreeBSD, BIND drops privileges
as soon as practical to that of the 'bind' user and group. For example:

imb@sarah:/home/imb> ls -l /var/run/named/
total 8
-rw-r--r--  1 bind  bind4 Apr 30 21:05 pid
-rw---  1 bind  bind  102 Apr 30 21:05 session.key

It seems you have incorrectly changed the configuration by not taking
these permissions into account. Check your named.conf for the incorrect
definition of pid-file - it should be "/var/run/named/pid",


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

2020-04-07 Thread 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: reccomendations of conference / party audio video software ?

2020-03-27 Thread 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: Alternatives to security/swatch

2020-03-15 Thread 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: Alternatives to security/swatch

2020-03-15 Thread 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: Pkg repository is broken...



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



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




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

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




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



> 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 devi

Re: Xorg 1.20 no mouse buttons

2020-03-05 Thread 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: Cannot build qt5-webkit with debug

2020-02-28 Thread Michael Osipov


Am 2020-02-26 um 17:52 schrieb Marcin Cieslak:

On Wed, 26 Feb 2020, Miroslav Lachman wrote:


Marcin Cieslak wrote on 2020/02/26 13:50:

On Wed, 26 Feb 2020, Miroslav Lachman wrote:


And what is not working now with the line fontFamilyList->append...
removed()?



Should I report it upstream or is it FreeBSD specific problem?


I think it is a bit too early to tell. I think it is not really
FreeBSD-specific
but there might be some quirks.

I am rebuilding qt5-webkit now with debug symbols using your phantomfs
port (thanks!) and I'll poke around a bit with debugger.


Just the small update.
phantomjs with modified version of qt5-webkit does not render any text
/ fonts on the web page screenshots taken by
page.render('/tmp/page.png');

So... it builds, it does not crashes but rendered pages are "empty"
(pictures, background colors etc are rendered OK, but no fonts)


This is expected. This line is responsible for finding fonts
used to render the webpage. Michael just wanted to confirm
this line is indeed causing the problem; we now have to figure
out what exactly is going wrong here.


Miroslav,

this is exactly what I expected. So did Marcin.
This is *not* a bugfix, but simply a proof for source the segfault.

Let's now remove the comment and try to narrow down the issue. Since the
code passes this assert:


ASSERT(m_valueList->size() == 1);


and since


RenderTheme::defaultTheme()->systemFont(systemFontID, fontDescription);


seems to work I assume that


CSSValuePool::singleton().createFontFamilyValue()


is the problem.

Someone needs now to debug and check the systemFontID/fontDescription
value and report to upstream.

Since your simple webpage does not use any CSS, WebKit has to use some
internal basic CSS with font information and that one causes to fail for
some reason.

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: Cannot build qt5-webkit with debug

2020-02-25 Thread Michael Osipov

Am 2020-02-24 um 22:52 schrieb Miroslav Lachman:

Michael Osipov wrote on 2020/02/24 21:40:

Am 2020-02-24 um 20:56 schrieb Miroslav Lachman:

[..]

I tried it on simpler website on HTTP without external fonts etc. but
it is still crashing

Example JS code and truss output is on hastebin
https://hastebin.com/sizefupiki.pl

No fopen found there :(

Can you also please provide the backtrace from lldb for this core dump?

lldb backtrace
https://hastebin.com/ovufejevil.bash

Surprisingly, the last call is:

stat("/usr/local/share/icu/65.1/icudt65l/iso-8859_16-2001.cnv",0x7fffc998)

which comes from ICU. The entire website has been read from the
socket, as you can see from the read in 2246.
Maybe it to convert the "charset=iso-8859-2" to LC_ALL value.

I would recommend to have a simple server built in PHP or Python and
try the simplest site possible w/o CSS and then add one w/o fonts first.

I tried it on the simplest web page without any fonts, css etc. but it
is still crashing. I removed the charset from the page so it is now not
using ICU.

https://hastebin.com/iyonapasuz.bash

Let me know if I can try anything else.

OK, it is getting closer.

The crash comes from this call:
https://github.com/qtwebkit/qtwebkit/blob/qtwebkit-5.212.0-alpha3/Source/WebCore/css/CSSParser.cpp#L6907

Can you commet comment this line, recompile qtwebkit and see what happens?

Either this line:
https://github.com/qtwebkit/qtwebkit/blob/qtwebkit-5.212.0-alpha3/Source/WebCore/css/CSSParser.cpp#L6897
does not work properly or this is broken:
https://github.com/qtwebkit/qtwebkit/blob/qtwebkit-5.212.0-alpha3/Source/WebCore/css/CSSValuePool.cpp#L121-L134

I'd like to see to see the content of familyName when passed. Either via
breakpoint or with std::cout. Unfortunately, my C++ knowledge is
minimal. I recommend to write a minimal C++ app with a function call and
signature "const String& str" and then pass the string [1]. Since this
is a custom type, I don't know whether cout will work. You have to try.

Michael

[1]
https://github.com/adobe/webkit/blob/master/Source/WTF/wtf/text/WTFString.h
___
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 build qt5-webkit with debug


Am 2020-02-24 um 20:56 schrieb Miroslav Lachman:

Michael Osipov wrote on 2020/02/24 20:35:

Am 2020-02-24 um 19:10 schrieb Miroslav Lachman:




Looking at your sample code and the website, there are several issues:

* The resource employs mixed site content HTTPS loads HTTP. Firefox 
blocks this, I guess WebKit blocks it too.

* Result: Droid Sans is not loaded [1], like the CSS
* The CSS has this:

body {
  font-family: 'Droid Sans','Lucida Grande',sans-serif;
  line-height: 1.125em;
  color: #444; }


Lucida Grande isn't there either. It must choke somewhere.

See also

frame #10: 0x0008039cf92c 
libQt5WebKit.so.5`WebCore::CSSParser::parseSystemFont


I assume it does some fopen() and chokes on when looking for 
sans-serif replacement.


Can you run the application with truss? We should see the fopen() and 
shortly after the crash. Upload the truss output.


I tried it on simpler website on HTTP without external fonts etc. but it 
is still crashing



Example JS code and truss output is on hastebin
https://hastebin.com/sizefupiki.pl

No fopen found there :(


Can you also please provide the backtrace from lldb for this core dump?

Surprisingly, the last call is:

stat("/usr/local/share/icu/65.1/icudt65l/iso-8859_16-2001.cnv",0x7fffc998)


which comes from ICU. The entire website has been read from the socket, 
as you can see from the read in 2246.

Maybe it to convert the "charset=iso-8859-2" to LC_ALL value.

I would recommend to have a simple server built in PHP or Python and try 
the simplest site possible w/o CSS and then add one w/o fonts first.


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: Cannot build qt5-webkit with debug


Am 2020-02-24 um 19:10 schrieb Miroslav Lachman:

Marcin Cieslak wrote on 2020/02/24 18:51:

On Mon, 24 Feb 2020, Marcin Cieslak wrote:


On Mon, 24 Feb 2020, Miroslav Lachman wrote:

   frame #13: 0x0008039aa3ed 
libQt5WebKit.so.5`WebCore::CSSParser::parseSheet(this=0x7fffa490, 
sheet=0x0008155f5e40, string=0x7fffb888, 
textPosition=0x7fffb650, 
ruleSourceDataResult=0x, logErrors=false) at 
CSSParser.cpp:423:5


Looks like it has some trouble parsing font declarations in the 
HTML/CSS code you have been testing

on. This can be a webkit bug...

Would be good to have a minimal HTML/CSS testcase to reproduce this 
and this should

probably be reported upstream.


There is this report:

https://github.com/qtwebkit/qtwebkit/issues/933

It says it crashes if you have no fonts installed (no TTF).

Could this "fix" it?


Thank you for the tip, I will look at it.


This is the code of the tested example - fetching from 
https://phantomjs.org/


(root@testjail) ~/# cat /tmp/phantom.2.js
var page = require('webpage').create();
page.onConsoleMessage = function(str) {
    console.log(str);
}
page.open('https://phantomjs.org/api/phantom/', function(status) {
    page.render('/tmp/beforeclick.png');
    console.log(page.url);

    var element = page.evaluate(function() {
   return document.querySelector('img[src = 
"https://phantomjs.org/img/phantomjs-logo.png;]');

    });
    page.sendEvent('click', element.offsetLeft, element.offsetTop, 'left');

    window.setTimeout(function () {
   console.log(page.url);
   page.render('/tmp/afterclick.png');
   phantom.exit();
    }, 5000);
    console.log('element is ' + element);
});


Looking at your sample code and the website, there are several issues:

* The resource employs mixed site content HTTPS loads HTTP. Firefox 
blocks this, I guess WebKit blocks it too.

* Result: Droid Sans is not loaded [1], like the CSS
* The CSS has this:

body {
  font-family: 'Droid Sans','Lucida Grande',sans-serif;
  line-height: 1.125em;
  color: #444; }


Lucida Grande isn't there either. It must choke somewhere.

See also


frame #10: 0x0008039cf92c 
libQt5WebKit.so.5`WebCore::CSSParser::parseSystemFont


I assume it does some fopen() and chokes on when looking for sans-serif 
replacement.


Can you run the application with truss? We should see the fopen() and 
shortly after the crash. Upload the truss output.


[1] http://fonts.googleapis.com/css?family=Droid+Sans:400,700

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: Cannot build qt5-webkit with debug


Am 2020-02-24 um 16:35 schrieb Miroslav Lachman:

Michael Osipov wrote on 2020/02/24 16:00:

Am 2020-02-24 um 15:50 schrieb Miroslav Lachman:

Miroslav Lachman wrote on 2020/02/24 12:48:


[..]


There are 2 core dumps

-rw---  1 root  wheel   327M Feb 24 14:36 gdb.core
-rw---  1 root  wheel   4.9M Feb 24 14:36 phantomjs.core

What more can I try?
I am not a C / C++ skilled person. All these things are new to me.


You can load the coredump into GDB and say "where" [1]. It will tell 
you the last frame it executed before it crashed. Make sure that your 
objects contains debug symbols. This mostly helped me to get a grasp 
of failures on FreeBSD and HP-UX.


Thank you!

I tried to debug gdb.core with this result

(root@testjail) ~/# gdb /usr/bin/gdb gdb.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you 
are
welcome to change it and/or distribute copies of it under certain 
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by 'gdb /usr/local/bin/phantomjs'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libm.so.5...Reading symbols from 
/usr/lib/debug//lib/libm.so.5.debug...done.

done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libncursesw.so.8...Reading symbols from 
/usr/lib/debug//lib/libncursesw.so.8.debug...done.

done.
Loaded symbols for /lib/libncursesw.so.8
Reading symbols from /usr/lib/libgnuregex.so.5...Reading symbols from 
/usr/lib/debug//usr/lib/libgnuregex.so.5.debug...done.

done.
Loaded symbols for /usr/lib/libgnuregex.so.5
Reading symbols from /lib/libc.so.7...Reading symbols from 
/usr/lib/debug//lib/libc.so.7.debug...done.

done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/lib/libthread_db.so...Reading symbols from 
/usr/lib/debug//usr/lib/libthread_db.so.3.debug...done.

done.
Loaded symbols for /usr/lib/libthread_db.so
Reading symbols from /libexec/ld-elf.so.1...Reading symbols from 
/usr/lib/debug//libexec/ld-elf.so.1.debug...done.

done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x000801327fd6 in memcpy () from /lib/libc.so.7
(gdb) where
#0  0x000801327fd6 in memcpy () from /lib/libc.so.7
#1  0x0008012fcfab in __fread (buf=0x8163f6704, size=1, 
count=2391484440, fp=0x80158a698)

     at /usr/src/lib/libc/stdio/fread.c:101
#2  0x0008012fceb3 in fread (buf=0x815d32940, size=1, 
count=2391484440, fp=0x80158a698)

     at /usr/src/lib/libc/stdio/fread.c:58
#3  0x005671c0 in cache_bread ()
#4  0x0059d8f8 in bfd_bread ()
#5  0x005356c7 in dwarf2_read_section ()
#6  0x00535080 in dwarf2_build_psymtabs ()
#7  0x005297a2 in elf_symfile_read ()
#8  0x004d233a in syms_from_objfile ()
#9  0x004d267b in symbol_file_add_with_addrs_or_offsets ()
#10 0x004d2479 in symbol_file_add ()
#11 0x0048f9f4 in symbol_add_stub ()
#12 0x004ac696 in catcher ()
#13 0x004ac830 in catch_errors ()
#14 0x0048f6c2 in solib_add ()
#15 0x0052041b in handle_inferior_event ()
#16 0x0051f588 in wait_for_inferior ()
#17 0x0051f3c8 in proceed ()
#18 0x004acda9 in execute_command ()
#19 0x00466725 in command_handler ()
#20 0x0046645a in command_line_handler ()
#21 0x005e4f0f in rl_callback_read_char ()
#22 0x004660c9 in rl_callback_read_char_wrapper ()
#23 0x00466f22 in gdb_do_one_event ()
#24 0x004ac696 in catcher ()
#25 0x004ac830 in catch_errors ()
#26 0x005537e9 in tui_command_loop ()
#27 0x00448609 in captured_command_loop ()
#28 0x004ac696 in catcher ()
#29 0x004ac830 in catch_errors ()
#30 0x00448446 in captured_main ()
#31 0x004ac696 in catcher ()
#32 0x004ac830 in catch_errors ()
#33 0x00447974 in gdb_main ()
#34 0x00447931 in main (argc=, argv=optimized out>)

     at /usr/src/contrib/gdb/gdb/gdb.c:35



As far as I can see this is the result of the crash below.


When I tried to debug phantomjs.core it crashed again

(root@testjail) ~/# gdb /usr/local/bin/phantomjs phantomjs.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you 
are
welcome to change it and/or distribute copies of it under certain 
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging 
symbols found)...

Core was generated by `/usr/local/bin/phantomjs /tmp/phantom.2.js'.
Program terminated with signal 5, Trace/breakpoint trap.
Reading symbols from /usr/

Re: Cannot build qt5-webkit with debug