Re: Is there a way to subscribe to the commit messages for only ports you maintain?
On Tue, 18 May 2021 03:17:03 +0200 "Julian H. Stacey" wrote: > Chris wrote: > > On 2021-05-17 16:30, Jan Beich wrote: > > > Chris writes: > > > > > >> I'd like to subscribe to the commit messages > > >> ( dev-commits-ports-all ) > > >> but only receive messages that affect me -- the > > >> ports I currently maintain. Is it possible? Or > > >> am I just dreaming? ;-) > > > > > > No clue but I use Herald rules for something similar. > > Thanks for the hints, Jan. :-) > > Herald ? Nothing from > https://www.freebsd.org/cgi/ports.cgi?query=herald&stype=all&sektion=all > ... > https://en.wikipedia.org/wiki/Phabricator > ... > https://cgit.freebsd.org/ports/tree/devel/phabricator/pkg-descr Google "phabricator herald"[0] :) It's part of phabricator and quite useful for automation, see https://reviews.freebsd.org/herald/create/ In Chris' case, he would probably create one or more personal commit rules: https://reviews.freebsd.org/herald/edit/?content_type=commit&rule_type=personal Rule Name: Inform me about changes to my ports When **all of** these conditions are met: **Repository** **is any of** R11 FreeBSD ports repository **Affected Files** **matches regexp** @devel/myporta|sysutils/myportb@ Take these actions **every time this rule matches:** **Send me an email** Click Save Rule Mind the special regexp syntax. I created a publicly visible rule as an example: https://reviews.freebsd.org/H142 You can test your rules on the test console: https://reviews.freebsd.org/herald/test/ (you would enter an existing commit id in there for testing, e.g., R11:305f148f482daf30dcf728039d03d019f88344eb) Best Michael [0] Other ways to discover phabricator apps: - Enter "herald" in phabricator (search box at the top) - The phabricator application list https://reviews.freebsd.org/applications/ -- Michael Gmelin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Additional filtering on pkg-status.freebsd.org url
On Sat, 8 May 2021 17:46:03 +0800 Simon Wright wrote: > Hi all, > > The move to git for ports is more or less OK for me now, thanks to > several for the various pointers. I still have issues with accessing > the individual build machine due to IPv6 issues on my side so am using > pkg-status.freebsd.org to check the status of the build cluster rather > than the specific machine that is building for my desired > architecture. > > My (minor) issue now is that accessing: > > https://pkg-status.freebsd.org/builds?type=package > > gives me a long list of builds. I'm looking for a way to pass a search > string of '130amd64' in the URL so that I can go straight to the > builds that I'm interested in. Is this possible? Encoding > > AND Search='130amd64' > > in the URL does not work. Can anyone point me in the right direction > for this? Does this show what you want? https://pkg-status.freebsd.org/builds?jailname=130amd64&type=package Best > > Thanks, > > Simon Wright. > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to > "freebsd-ports-unsubscr...@freebsd.org" -- Michael Gmelin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: looking for port origin for executable
> On 5. May 2021, at 20:25, Christian Weisgerber wrote: > > On 2021-05-04, Robert Huff wrote: > >>Would some kind soul please tell me which port installs the >> executable "g-ir-scanner"? I was purging unused ports and seem to >> have done this one by mistake. > > pkg-which(1) > > $ pkg which /usr/local/bin/g-ir-scanner > /usr/local/bin/g-ir-scanner was installed by package > gobject-introspection-1.66.1,1 > This only works if the package it came from is still installed. Robert was trying to find the package that will give him that file, as he deleted that package by accident. Best Michael > -- > Christian "naddy" Weisgerber na...@mips.inka.de > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Making a port to use OpenSSL of ports collection on FreeBSD 11.x
> On 5. May 2021, at 18:56, Stefan Esser wrote:
>
> Am 05.05.21 um 18:00 schrieb Yasuhiro Kimura:
>> You misunderstand my intention. What I would like to do is to make a
>> port use security/openssl instead of base OpenSSL even if user sets
>> 'DEFAULT_VERSIONS+=ssl=base' in /etc/make.conf (or user doesn't
>> customize setting about ssl at all).
Stefan‘s suggestion is AFAIK the best we can do.
mail/opensmtpd has an example of that, but it still requires the user to
actively select the OpenSSL library (mixing OpenSSL libraries in a package set
is problematic).
Best,
Michael
>
> You can mark the port as broken if the user has selected "base" and
> this is incompatible with the port's requirements. E.g.:
>
> .include
>
> .if ${SSL_DEFAULT} == base
> BROKEN_FreeBSD_11= OpenSSL 1.1 required
> .endif
>
> .include
>
> You can of course add a better message, and the user can decide to
> try the compilation again after changing the default. But this will
> of course prevent the building of official packages for FreeBSD-11.
>
>> As I wrote previous mail, if 'USES=python:3.8+' is specified in
>> Makefile of a port, lang/python38 is used for the port event if user
>> adds 'DEFAULT_VERSIONS+=python=3.7' in /etc/make.conf. I'm looking for
>> similar way about ssl setting.
>
> You could add a dependency on the openssl port and make sure, that
> the port's include file and library is used in preference of the
> base version on FreeBSD-11.
>
> But you have to consider the risk of mixing references to the base and
> the ports version in one binary (e.g. other libraries are linked in that
> had been built against the base version).
>
> Regards, STefan
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Making a port to use OpenSSL of ports collection on FreeBSD 11.x
On Wed, 05 May 2021 23:22:08 +0900 (JST) Yasuhiro Kimura wrote: > From: Michael Gmelin > Subject: Re: Making a port to use OpenSSL of ports collection on > FreeBSD 11.x Date: Tue, 4 May 2021 23:05:06 +0200 > > > See > > https://docs.freebsd.org/en/books/porters-handbook/uses/#uses-ssl > > > > Best > > I checked it but couldn't find proper solution. > > I think what is necessary in my case is something like version-spec > argument of 'USES=python'. > > For example, if 'USES=python:3.8+' is specified in Makefile of a port, > lang/python38 is used for it even if user sets > 'DEFAULT_VERSIONS+=python=3.7' in /etc/make.conf. > > But 'USES=ssl' doesn't provide such argument. Which port are you talking about by the way? This worked for me just fine in the past (placed in make.conf): DEFAULT_VERSIONS+=ssl=libressl for LibreSSL and DEFAULT_VERSIONS+=ssl=openssl for openssl from ports. See also: $ head -n12 /usr/ports/Mk/Uses/ssl.mk # Handle dependency on *ssl ports. # # Feature: SSL_DEFAULT # Usage:USES=ssl # Valid ARGS: none (build and run), build, run # # The user can choose which ssl library he wants with: # # DEFAULT_VERSIONS+=ssl= # # Variants being base, openssl, libressl, and libressl-devel. # Cheers, Michael > > --- > Yasuhiro Kimura > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to > "freebsd-ports-unsubscr...@freebsd.org" -- Michael Gmelin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Making a port to use OpenSSL of ports collection on FreeBSD 11.x
> On 4. May 2021, at 21:50, Yasuhiro Kimura wrote: > > Hello, > > Of the currently supported FreeBSD versions, base system of FreeBSD > 11.x uses OpenSSL 1.0.2 and that of FreeBSD 12.x or later use OpenSSL > 1.1.1. > > Then when new version of an application dropped suport of OpenSSL > 1.0.2, is there any way to make the port of it to use OpenSSL of ports > collection if the system is FreeBSD 11.x? > See https://docs.freebsd.org/en/books/porters-handbook/uses/#uses-ssl Best > Best Regards. > > --- > Yasuhiro Kimura > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Maintainer timeout on textproc/py-markdown update on Bugzilla - safe to commit?
> On 4. May 2021, at 22:45, Neel Chauhan wrote: > > Hi, > > There is an update to the port textproc/py-markdown but the maintainer, > koobs@ has not responded even when (I believe) it could be committed. > > Bugzilla PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239070 > > Assuming no dependent ports have an issue with this update, would it be safe > to commit this with a maintainer timeout if koobs@ hasn't responded? > > I'm asking since I don't want to prematurely commit ports. > > This port needs to be updated in order to import GTK+ 4 which in turn needs > to update x11-toolkits/pango (which in turn needs this update). > Cc Koobs - looking at the pr, it seems like it was complicated and a lot of other work had to be done first. -m > -Neel (nc@) > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Ports recompile for 13.0-RELEASE
On Tue, 4 May 2021 08:10:38 -0600
"@lbutlr" wrote:
> With the move to FreeBSD 13.0 is there a simple (single step) way to
> reinstall all the current ports other than saving off a list of the
> ports and then stepping through that list to reinstall them?
> It was very inefficient when moving to 12.0 as many ports in the
> list, of course, were dependent on other ports, but then got
> recompiled, sometimes multiple times. I know I ended up in a make
> loop where came was compiled over and over again until I aborted,
> listed the current ports, differ on the previous ports, and picked a
> port I though would have a lot of reps to restart the compile. I then
> did this several more times to get back to where I had been on 11.x
Using a local poudriere repo fixes all of the above ;)
>
> And there's still no way to tell if a port was installed from pkg or
> from ports, correct? Since I use MariaDB instead of MySQLI have to be
> sure I don't try to use package for anything that will try to install
> MySQL instead.
The repository the package came from is stored in the annotation tag
named "repository".
You can see this, e.g., by using
pkg query "%n %At %Av"
or
pkg info -R
By default this is "FreeBSD" for the official repos. If you install
locally ("make install"), it's not set.
>
> And finally, the release of 13.0 ends the 12.x versions, right? There
> will not be a 12.3.
See https://www.freebsd.org/security/#sup, there will be a 12.3.
>
> (And yes, I've tried moving to poudrerie several times and we do not
> get on. At all.)
Well, that's the recommended way of doing what you're trying to
accomplish, otherwise you'll be in dependency hell like we've all
been updating our machines in the 2000s.
Alternatively, you could create a jail or VM manually, install all
packages you need in there from ports using make install. You
can retrieve the list of what you need on your target host using
pkg query -e "%a = 0" %o
Then run "pkg create -a" on that machine to get a set of all binary
packages. Then copy those over to your target machine and install them
using pkg add. Will be messy, but kind of work. I really would prefer
poudriere over that though.
Best
Michael
--
Michael Gmelin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation of portsnap (was: Proposed ports git transition schedule)
> On 14. Apr 2021, at 00:54, Dave Horsfall wrote: > > On Mon, 12 Apr 2021, Peter Jeremy via freebsd-ports wrote: > >> Except that git will arbitrarily and randomly decide that it needs to run >> "gc" - which is similarly extravagant in memory usage. Last time I found >> one running, it thrashed that poor VM for 3 days. > Would this be a good time to mention the https://ohshitgit.com/ site? > Warning: it contains strong language... I prefer this site: https://git-man-page-generator.lokaltog.net/ -m > > -- Dave > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation of portsnap (was: Proposed ports git transition schedule)
> On 12. Apr 2021, at 13:12, Peter Jeremy via freebsd-ports > wrote: > > On 2021-Apr-11 14:27:27 +0200, Helge Oldach wrote: >> Peter Jeremy via freebsd-ports wrote on Sun, 11 Apr 2021 00:52:11 +0200 >> (CEST): >>> Following the SVN to GIT migration, portsnap is now the only practical >>> way to use ports on a low-memory system. I've done some experiments >>> and standard git has a 2GB working set to checkout a ports tree. >> >> However checking out is a one-time action with ports as there is only >> one branch (switching frequently between main and quarterly is probably >> not very sensible on a limited machine). git pull is significantly more >> lightweight, I've just seen some 200M RSS. That should work well even on >> a 512M machine. Probably much better than gitup in constrained memory? > > Except that git will arbitrarily and randomly decide that it needs to > run "gc" - See https://git-scm.com/docs/git-gc for an explanation of how git decides when to run gc and how you can control it (e.g., by setting gc.auto to 0). -m > which is similarly extravagant in memory usage. Last time > I found one running, it thrashed that poor VM for 3 days. > > Ignoring that, a "git up -ff" on a ports tree peaks with 2×1GB processes, > though it looks like the working set size might only be ~350MB. > > -- > Peter Jeremy ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: cannot git clone into /usr/ports when separate filesystem
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
> 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?
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
On Mon, 29 Mar 2021 20:26:24 +0200
"Hartmann, O." wrote:
> On Mon, 29 Mar 2021 11:42:28 +0200
> Michael Gmelin wrote:
>
> > On Sun, 28 Mar 2021 13:08:19 +0200
> > "Hartmann, O." wrote:
> >
> > > What am I missing here?
> > >
> >
> > The man page of git-http-backend has an apache2 example[0].
> > Also, the top answer to this stackoverflow question might give you a
> > hint: https://stackoverflow.coo-set-up-git-over-http
> >
> > Best,
> > Michael
> >
> > [0]https://www.freebsd.org/cgi/man.cgi?query=git-http-backend&apropos=0&sektion=0&manpath=FreeBSD+12.2-RELEASE+and+Ports&arch=default&format=html
> >
> >
>
> Hello Michael,
>
> thanks for responding.
> The first tip I came across was the Stackoverflow HowTo - whatever I
> did and do, it doesn't work. I also tried the several variants shown
> in [0], starting with the simplest towards more complex ones.
>
> Following strictly the reference at
>
> https://stackoverflow.com/questions/26734933/how-to-set-up-git-over-http
>
> with minor local adaptions (for FreeBSD and the Git base folder),
> even with anonymous access allowed the failure is the same as with
> some Basic authentication via LDAP.
>
> As decribed in my initial email: first access with a "git push -u
> origin master" is logged by Apache with 401, requesting credentials.
> If provided, the line (httpd-access.log):
>
> xx.xx.xx.xx - USERNAME [29/Mar/2021:17:44:55 +] "GET \
> /git/test.git/info/refs?service=git-upload-pack HTTP/1.1" 200 1689032
> "-" "git/2.31.0" \ 323 1691601
>
> status code 200 indicates OK - so authetication is all right and I
> should proceed, but I get on the client
>
> fatal: https://[url]/git/test.git/info/refs not valid: could not
> determine hash algorithm; is this a git repository?
>
> On both sides, I had disabled sslVerify (due to self signed cert
> issue with git, another pitfall) and according to stackoverflow
> howto, hooks are also prepared and the root folder and its subsequent
> folders /pool/gitbase (PROJECT_ROOT) is owned by www:www and has ACL
> 0775 set.
>
> And this is why it gets desperate to me ...
I played a bit with this - turns out that the key is to make sure that
the cgi module is loaded (e.g., mod_cgi).
This is the simple basic setup I tested (using bash):
pkg install apache24 git
service apache24 enable
cat >/usr/local/etc/apache24/Includes/git.conf<<"EOF"
LoadModule cgi_module libexec/apache24/mod_cgi.so
LoadModule rewrite_module libexec/apache24/mod_rewrite.so
ServerName 127.0.0.1
SetEnv GIT_PROJECT_ROOT /usr/local/www/git/
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/local/libexec/git-core/git-http-backend/
RewriteCond %{QUERY_STRING} service=git-receive-pack [OR]
RewriteCond %{REQUEST_URI} /git-receive-pack$
RewriteRule ^/git/ - [E=AUTHREQUIRED:yes]
Order Deny,Allow
Deny from env=AUTHREQUIRED
AuthType Basic
AuthName "Git Access"
Require group committers
Satisfy Any
EOF
mkdir -p /usr/local/www/git/test.git
git init --bare /usr/local/www/git/test.git
service apache24 start
git clone http://localhost/git/test
Cheers,
Michael
>
> Kind regards,
>
> O. Hartmann
--
Michael Gmelin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: devel/git: Git via Apache 2.4 HTTPS - info/refs not valid: could not determine hash algorithm
On Sun, 28 Mar 2021 13:08:19 +0200 "Hartmann, O." wrote: > What am I missing here? > The man page of git-http-backend has an apache2 example[0]. Also, the top answer to this stackoverflow question might give you a hint: https://stackoverflow.coo-set-up-git-over-http Best, Michael [0]https://www.freebsd.org/cgi/man.cgi?query=git-http-backend&apropos=0&sektion=0&manpath=FreeBSD+12.2-RELEASE+and+Ports&arch=default&format=html -- Michael Gmelin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Testing www/chromium before installing
> On 13. Mar 2021, at 18:51, bob prohaska wrote: > > On Sat, Mar 13, 2021 at 06:11:06PM +0100, Michael Gmelin wrote: >> >> >>> On Sat, 13 Mar 2021 08:50:07 -0800 >>> bob prohaska wrote: >>> >>> Hi Michel, >>> >>> On Sat, Mar 13, 2021 at 05:01:16PM +0100, Michael Gmelin wrote: >>>> What about ???make stage >>>> >>> Never heard of it, and can't find any obvious references. >>> Is there a description somewhere? >> >> It's one of the seven main targets of building a port: >> >> - extract >> - patch >> - configure >> - build >> - stage >> - install >> - package >> >> It installs the port into STAGEDIR (by default work/stage). Install and >> package copy files from STAGEDIR, so usually stage is run implicitly. >> See /usr/ports/Mk/bsd.port.mk for details (documentation isn't great, >> most of it is from when the big conversion to STAGEDIR happened a >> couple of years ago). >> >> To give you a simple port as an example >> >> # cd /usr/ports/editors/joe >> # make stage >> ... >> # find work/stage -type f -perm +111 >> work/stage/usr/local/bin/joe >> >> Same should work with chromium (you might need to set LD_LIBRARY_PATH >> in case chromium comes with its own libraries). >> > > Thank you! Found the executable, and it suffers from the same problem > as the old version: The controls drop-down menu (right of the URL bar) > is non-persistent and can't be used. The new version does seem to run > faster, which is a step forward. > > It's surprising that a simple > find . -name stage > didn't discover the directory, but did discover those for node, > in the same subtree. The exact syntax you provided seems to be > required. > >> Oh, alternatively you could of course simply make a backup of your >> current chromium package: >> >> pkg create chromium >> >> Which you then can re-install in case the new version doesn't work as >> expected: pkg add chromium-someversion.txz >> > > The sources for the existing version of chromium are long overwritten, > can a package be constructed from installed files? Yes, “pkg create” creates a package from what is installed on a system (package database and installed files). You can use “pkg create -a” to create tarballs for all installed packages (useful before doing major surgery or to transfer a full package set to a different system). Check “man pkg-create” for details. -m > > bob prohaska > > >> Best, >> Michael >> >>> >>> Thanks for writing! >>> >>> bob prohaska >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>>> On 13. Mar 2021, at 16:49, bob prohaska >>>>> wrote: >>>>> >>>>> ???After a _very_ long time www/chromium finished compiling on a >>>>> Pi3B+. I'd like to test it before installing, since I have a >>>>> (mostly) working version in /usr/local/bin and don't want to >>>>> overwrite it until I know the new version works at least as >>>>> well as the old one. >>>>> >>>>> Poking around in the source tree didn't disclose any obvious >>>>> executable, could somebody offer a hint at test methods, if any? >>>>> >>>>> Thanks for reading, >>>>> >>>>> bob prohaska >>>>> >>>>> ___ >>>>> freebsd-ports@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-ports >>>>> To unsubscribe, send any mail to >>>>> "freebsd-ports-unsubscr...@freebsd.org" >>>> >>>> >> >> >> >> -- >> Michael Gmelin > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: broken vuln.xml?
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
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
On Wed, 27 Jan 2021 10:35:38 +0200 Peter Pentchev wrote: > On Wed, Jan 27, 2021 at 10:57:22AM +0900, Yasuhiro Kimura wrote: > > From: Freddie Cash > > Subject: Re: List of packages upgraded last time `pkg upgrade` was > > executed Date: Tue, 26 Jan 2021 17:26:29 -0800 > > > > > /var/log/messages and I think /var/log/daemon include the output > > > of the pkg commands. If you have the log files backed up from the > > > last time it was run, you could grep for pkg in those. > > > > > > No idea if this info is also stored in the sqlite databases pkg > > > uses. > > > > Thank you for reply. But my intention is to write shell script that > > gets the list of upgraded packages and does something by using > > it. Because of that the list need to be gotton without any user > > interaction. So unfortunately your method is not applicable to my > > case. > > Well, there is the option of running a pkg query before and after > the upgrade and comparing the results... especially if you write it in > a higher-level language than the shell, it Should Not Be Too Hard(tm) > to figure out which packages have changed their version, what new > ones have appeared, which ones have been removed... > > But, yeah, it is certainly easy for me to suggest that somebody else > write something "simple" :) > This will give you a list of all packages that were updated/installed last: pkg query -e %t=$(pkg query %t | sort -n | tail -n1) %n-%v Explained: $(pkg query %t | sort -n | tail -n1) - Get timestamps of when packages were installed - Sort numerically - Take the last one (which is the latest) Feed this into `pkg query %t=x %n-%v` which returns all packages matching that latest timestamp (== when last set of packages were installed) and outputs their name and version. As far as I can tell, packages installed by the same pkg invocation run share the same installation timestamp (I didn't check the pkg sources, but that's what appears to be the case), that's why this works. This resulting list won't include the pkg package itself in case it was updated as part as the run. There might also be other multi-pass scenarios of pkg I'm not aware of though. In case you know when pkg upgrade was called last, you can simply feed it the timestamp directly, like in: pkg query -e "%t>=1609545326" %n-%v If you use a script to do upgrades, you could store the timestamp as part of that and do something like this: touch /tmp/lastupgrade pkg upgrade # then, later: pkg query -e "%t>=$(stat -f %m /tmp/lastupgrade)" %n-%v Cheers, Michael -- Michael Gmelin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: REINPLACE_CMD QA causing pkg-fallout
On Mon, 4 Jan 2021 18:56:31 +0100
Michael Gmelin wrote:
> On Sat, 2 Jan 2021 18:33:12 +0100
> Michael Gmelin wrote:
>
> > Hi,
> >
> > I updated the devel/phabricator port yesterday, which included
> > running the usual QA steps (`poudriere testport', also running "make
> > check-plist" on a local ports tree).
> >
> > Later, after committing the change and when updating on a production
> > machine, I noticed a problem with the package list, which I first
> > corrected in-place and then committed the corrections. Today I
> > started receiving pkg-fallout messages - seems like timing was quite
> > unfortunate. Those messages motivated me to look into the issue
> > and I figured out why it failed:
> >
> > It turns out that if DEVELOPER is set, it worked fine (which is
> > also what is set when `poudriere testport' is run). Without
> > DEVELOPER set (e.g., in `poudriere bulk') it failed.
> >
> > The reason is that this port sets REINPLACE_ARGS to override the
> > "-i" argument to $REINPLACE_CMD like this:
> >
> > REINPLACE_ARGS= -i ""
> >
> > which seems to be the intended use of this variable, according to
> > bsd.port.mk:
> >
> > # Macro for doing in-place file editing using regexps.
> > # REINPLACE_ARGS may only be used to set or override the -i
> > # argument. Any other use is considered invalid.
> >
> > Now, since r522484[0], reviewed in [1], REINPLACE_CMD is set to
> > sed_checked.sh (which now is ${SCRIPTSDIR}/sed_checked.sh), which
> > hardcodes the call to `/usr/bin/sed -i.bak "$@"'.
> >
> > Therefore, this is what made me create the broken pkg-plist:
> > - I had "DEVELOPER=yes" in /etc/make.conf.
> > - I used `make makeplist' to create a new pkg-list.
> > - The new pkg-plist contained .bak files created by sed_checked.sh
> > without me noticing.
> > - `make stage-qa' and `poudriere testport' worked just fine, as the
> > .bak files are created there as well.
> > - Once building without "DEVELOPER" set (production server with
> > ports tree, `poudriere bulk', project build servers), it failed, as
> > sed_checked.sh isn't involved there, so no .bak files are created,
> > as REINPLACE_ARGS is applied.
> >
> > To keep supporting overriding "-i" and making sure that DEVELOPER
> > builds are the same as non-DEVELOPER builds, I would suggest to
> > modify sed_checked.sh like this:
> >
> > - Change the call to sed: /usr/bin/sed -i.sedcheck "$@"
> > - Move the backup file back to the original file after checking:
> > mv "$@".sedcheck "$@"
> > - Run sed again, this time passing $REINPLACE_ARGS
> >
> > Maybe @swills has time to look into this, if not, I'll try to find
> > the time to come up with a patch and open a review.
> >
> > Cheers,
> > Michael
> >
> > [0] https://svnweb.freebsd.org/ports?view=revision&revision=522484
> > [1] https://reviews.freebsd.org/D22174
> >
>
> I implemented a simple fix and opened a review:
> https://lists.freebsd.org/pipermail/freebsd-ports/2021-January/119978.html
>
> -m
>
Breaking the recursion, here's the correct link to the review:
https://reviews.freebsd.org/D27954
-m
--
Michael Gmelin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: REINPLACE_CMD QA causing pkg-fallout
On Sat, 2 Jan 2021 18:33:12 +0100
Michael Gmelin wrote:
> Hi,
>
> I updated the devel/phabricator port yesterday, which included running
> the usual QA steps (`poudriere testport', also running "make
> check-plist" on a local ports tree).
>
> Later, after committing the change and when updating on a production
> machine, I noticed a problem with the package list, which I first
> corrected in-place and then committed the corrections. Today I started
> receiving pkg-fallout messages - seems like timing was quite
> unfortunate. Those messages motivated me to look into the issue
> and I figured out why it failed:
>
> It turns out that if DEVELOPER is set, it worked fine (which is
> also what is set when `poudriere testport' is run). Without DEVELOPER
> set (e.g., in `poudriere bulk') it failed.
>
> The reason is that this port sets REINPLACE_ARGS to override the "-i"
> argument to $REINPLACE_CMD like this:
>
> REINPLACE_ARGS= -i ""
>
> which seems to be the intended use of this variable, according to
> bsd.port.mk:
>
> # Macro for doing in-place file editing using regexps.
> # REINPLACE_ARGS may only be used to set or override the -i
> # argument. Any other use is considered invalid.
>
> Now, since r522484[0], reviewed in [1], REINPLACE_CMD is set to
> sed_checked.sh (which now is ${SCRIPTSDIR}/sed_checked.sh), which
> hardcodes the call to `/usr/bin/sed -i.bak "$@"'.
>
> Therefore, this is what made me create the broken pkg-plist:
> - I had "DEVELOPER=yes" in /etc/make.conf.
> - I used `make makeplist' to create a new pkg-list.
> - The new pkg-plist contained .bak files created by sed_checked.sh
> without me noticing.
> - `make stage-qa' and `poudriere testport' worked just fine, as the
> .bak files are created there as well.
> - Once building without "DEVELOPER" set (production server with ports
> tree, `poudriere bulk', project build servers), it failed, as
> sed_checked.sh isn't involved there, so no .bak files are created,
> as REINPLACE_ARGS is applied.
>
> To keep supporting overriding "-i" and making sure that DEVELOPER
> builds are the same as non-DEVELOPER builds, I would suggest to modify
> sed_checked.sh like this:
>
> - Change the call to sed: /usr/bin/sed -i.sedcheck "$@"
> - Move the backup file back to the original file after checking:
> mv "$@".sedcheck "$@"
> - Run sed again, this time passing $REINPLACE_ARGS
>
> Maybe @swills has time to look into this, if not, I'll try to find the
> time to come up with a patch and open a review.
>
> Cheers,
> Michael
>
> [0] https://svnweb.freebsd.org/ports?view=revision&revision=522484
> [1] https://reviews.freebsd.org/D22174
>
I implemented a simple fix and opened a review:
https://lists.freebsd.org/pipermail/freebsd-ports/2021-January/119978.html
-m
--
Michael Gmelin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
REINPLACE_CMD QA causing pkg-fallout
Hi,
I updated the devel/phabricator port yesterday, which included running
the usual QA steps (`poudriere testport', also running "make
check-plist" on a local ports tree).
Later, after committing the change and when updating on a production
machine, I noticed a problem with the package list, which I first
corrected in-place and then committed the corrections. Today I started
receiving pkg-fallout messages - seems like timing was quite
unfortunate. Those messages motivated me to look into the issue
and I figured out why it failed:
It turns out that if DEVELOPER is set, it worked fine (which is
also what is set when `poudriere testport' is run). Without DEVELOPER
set (e.g., in `poudriere bulk') it failed.
The reason is that this port sets REINPLACE_ARGS to override the "-i"
argument to $REINPLACE_CMD like this:
REINPLACE_ARGS= -i ""
which seems to be the intended use of this variable, according to
bsd.port.mk:
# Macro for doing in-place file editing using regexps.
# REINPLACE_ARGS may only be used to set or override the -i
# argument. Any other use is considered invalid.
Now, since r522484[0], reviewed in [1], REINPLACE_CMD is set to
sed_checked.sh (which now is ${SCRIPTSDIR}/sed_checked.sh), which
hardcodes the call to `/usr/bin/sed -i.bak "$@"'.
Therefore, this is what made me create the broken pkg-plist:
- I had "DEVELOPER=yes" in /etc/make.conf.
- I used `make makeplist' to create a new pkg-list.
- The new pkg-plist contained .bak files created by sed_checked.sh
without me noticing.
- `make stage-qa' and `poudriere testport' worked just fine, as the
.bak files are created there as well.
- Once building without "DEVELOPER" set (production server with ports
tree, `poudriere bulk', project build servers), it failed, as
sed_checked.sh isn't involved there, so no .bak files are created, as
REINPLACE_ARGS is applied.
To keep supporting overriding "-i" and making sure that DEVELOPER
builds are the same as non-DEVELOPER builds, I would suggest to modify
sed_checked.sh like this:
- Change the call to sed: /usr/bin/sed -i.sedcheck "$@"
- Move the backup file back to the original file after checking:
mv "$@".sedcheck "$@"
- Run sed again, this time passing $REINPLACE_ARGS
Maybe @swills has time to look into this, if not, I'll try to find the
time to come up with a patch and open a review.
Cheers,
Michael
[0] https://svnweb.freebsd.org/ports?view=revision&revision=522484
[1] https://reviews.freebsd.org/D22174
--
Michael Gmelin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How do port man pages get into https://www.freebsd.org/cgi/man.cgi?
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?
@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?
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)
> 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?
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?
On Wed, 26 Aug 2020 16:53:30 +0200
Kurt Jaeger wrote:
> Hi!
>
> > Is there any documentation explaining how port man pages are
> > generated for man.cgi
>
> The man.cgi script itself is in the docs svn repo:
>
> https://svnweb.freebsd.org/doc/head/en_US.ISO8859-1/htdocs/cgi/man.cgi?revision=54262&view=markup
Thanks.
>
> We find that each released version has that version's ports tree.
>
> > and how frequently they're updated? Like, are they taken
> > from binary packages every few months or are they maybe created
> > from the ports tree that's current at the time of a release (so
> > "FreeBSD 12.1-RELEASE and Ports" contains man pages based on
> > https://download.freebsd.org/ftp/releases/amd64/12.1-RELEASE/ports.txz)?
> >
>
> Yes, exactly.
>
> Any ideas on how man.cgi can be made to also display ports head man
> pages ?
One way would be to extract man pages from the binary packages we
provide - this would allow to have man pages for head and quarterly
branches. This could be implemented as a poudriere feature while
building (so it collects man pages as a side effect of bulk builds), or
based on the artifacts/binary package produced by poudriere. The former
would probably be more elegant and less resource intensive, but also
more intrusive.
Naive implementation:
Get list of man pages:
find /usr/local/poudriere/data/packages/121amd64-default/All/ \
-name "*.txz" -exec tar -tf {} /usr/local/man 2>/dev/null \;
Extract man pages to /tmp/manpages:
find /usr/local/poudriere/data/packages/121amd64-default/All/ \
-name "*.txz" -exec tar \
-C /tmp/manpages \
--strip-components 4 \
-xf {} \
/usr/local/man 2>/dev/null \;
Test if it works:
MANPATH=/tmp/manpages man XGrabButton
Cheers,
Michael
--
Michael Gmelin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
How do port man pages get into https://www.freebsd.org/cgi/man.cgi?
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
> On 16. Aug 2020, at 02:16, Carmel wrote: > > On Sun, 16 Aug 2020 01:22:35 +0200, Christoph Moench-Tegeder stated: >> ## Carmel (carmel...@outlook.com): >> >>> [00:00:01] Error: MOVED: net/kblog EXPIRED 2020-08-13 No longer >>> shipped [00:00:01] Error: Fatal errors encountered gathering initial >>> ports metadata >> >>> Has anyone seen this before, and how do I rectify it? >> >> What it says: net/kblog is gone (with the latest KDE Application update >> in r544824, see >> https://svnweb.freebsd.org/ports?limit_changes=0&view=revision&revision=544824 >> for the full commit). >> You need to remove that from your ports-list.txt. > > I would have expected to see something in"UPDATING". The only mention > is in "MOVED": net/kblog||2020-08-13|No longer shipped MOVED is the documented location for this kind of information, see https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/moved-and-updating-files.html > > Obviously, poudriere cannot handle this situation on its own. To bad. Well, it kind of did. You explicitly asked it to build a port that has been removed and it informed you about the fact that the port no longer exists (and why). What else would you expect it to do? Best, Michael ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Error: MOVED: net/kblog EXPIRED 2020-08-13 No longer shipped
> On 15. Aug 2020, at 23:55, Carmel wrote: > > When I attempted to do a bulk build with poudriere today, I was greeted > with this rather disturbing message. > > ~ # poudriere bulk -f ./port-list.txt -j 114Ramd64 > [00:00:00] Creating the reference jail... done > [00:00:00] Mounting system devices for 114Ramd64-default > [00:00:00] Mounting ports/packages/distfiles > [00:00:00] Using packages from previously failed build: > /usr/local/poudriere/data/packages/114Ramd64-default/.building > [00:00:00] Mounting ccache from: /usr/home/gerard/.ccache > [00:00:00] Mounting packages from: > /usr/local/poudriere/data/packages/114Ramd64-default > [00:00:00] Copying /var/db/ports from: > /usr/local/etc/poudriere.d/114Ramd64-options > [00:00:00] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf > /etc/resolv.conf -> > /usr/local/poudriere/data/.m/114Ramd64-default/ref/etc/resolv.conf > [00:00:00] Starting jail 114Ramd64-default > [00:00:01] Logs: > /usr/local/poudriere/data/logs/bulk/114Ramd64-default/2020-08-15_17h45m52s > [00:00:01] WWW: > http://seibercom.net/poudriere/build.html?mastername=114Ramd64-default&build=2020-08-15_17h45m52s > [00:00:01] Loading MOVED for > /usr/local/poudriere/data/.m/114Ramd64-default/ref/usr/ports > [00:00:01] Ports supports: FLAVORS SELECTED_OPTIONS > [00:00:01] Gathering ports metadata > [00:00:01] Error: MOVED: net/kblog EXPIRED 2020-08-13 No longer shipped > [00:00:01] Error: Fatal errors encountered gathering initial ports metadata > [00:00:01] Cleaning up > [00:00:01] Unmounting file systems > > Has anyone seen this before, and how do I rectify it? What’s in port-list.txt? > > System: FreeBSD 11.4-RELEASE-p2 > > -- > Jerry > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
> 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
> 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
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
> 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
> On 4. Aug 2020, at 20:43, Steve Wills wrote: > > > We are planning to deprecate use of portsnap in ports. > > The reasons are as follows (in no particular order): > > * Portsnap doesn't support quarterly branches, even years after quarterly > branches were created and changed to the default for non-HEAD packages. > > * Portsnap doesn't seem to save disk space compared to svn or git, if you > count the metadata (stored in /var/db/portsnap by default) and you do an > apples-to-apples comparison of svn or git without history and ignoring > possible ZFS compression. That is, you use "svn export" or git "clone --depth > 1", you see this disk usage: > >342Msvnexport >426Mgit >477Mportsnap > > * Portsnap also doesn't work offline which git does. With git, you can also > easily add the history by running "git pull --unshallow" > > * This migration away from portsnap fits well with the planned migration to > git. > > * Also based on the patches we've seen in Bugzilla for some time, usage of > portsnap causes folks to too easily accidentally submit patches to Bugzilla > which don't apply easily. > > * Since portsnap doesn't support quarterly branches, it often causes users to > build on the wrong branch or end up with mismatched packages. That is, they > install packages from quarterly via pkg, then want to customize so run > portsnap and build from head, which can cause problems, as we often see. Even > when this doesn't happen, it adds to troubleshooting to verify that it didn't. > > We are aware people have gotten used to portsnap, but believe: > > * People should be able to easily use svnlite in base or git from pkgs. (Very > few people seem to actually use WITHOUT_SVNLITE). > > * There is also the possibility of falling back to fetching a tar or zip from > https://cgit-beta.freebsd.org/ports/ although this does make updating harder. > > How it will be done, in order: > > * Update poudriere to use svn by default. This is already done: > > https://github.com/freebsd/poudriere/pull/764 > https://github.com/freebsd/poudriere/commit/bd68f30654e2a8e965fbdc09aad238c8bf5cdc10 > > * Update docs not to mention portsnap. This is already in progress: > > https://reviews.freebsd.org/D25800 > https://reviews.freebsd.org/D25801 > https://reviews.freebsd.org/D25803 > https://reviews.freebsd.org/D25805 > https://reviews.freebsd.org/D25808 > https://svnweb.freebsd.org/changeset/base/363798 > > Many thanks to the folks who have worked and are working on this! > > * Make WITHOUT_PORTSNAP default in base. Currently not certain when this will > happen. May not happen before 13.0, but hopefully it will. > > * Eventually, portsnap servers will see low enough usage they can be disabled. > > We welcome any constructive feedback. All input would be heard, and if the > plans need to be amended, we will come back to you with the amended plan in a > couple of weeks. This process will take some time and hopefully won't be too > disruptive to anyone's usual workflow. What will be the process to bootstrap git? Thanks > > Steve (with portmgr@ hat) > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: phabricator-php73-20200514_1
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: Port maintenance
> 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
> 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: cups-pdf crash status -139
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
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
> 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
> 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
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
> 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!
> 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: Linux-foldingathome
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 ?
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
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
> 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
Re: Xorg 1.20 no mouse buttons
> 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: Clang8 crash on rpi3 at r349989 building openjdk8
> On 1. Sep 2019, at 18:07, bob prohaska wrote: > > On Sun, Sep 01, 2019 at 12:07:15PM +0200, Mika??l Urankar wrote: openjdkd11 is not affected by this bug (and it's the 'mixed' mode version), if you want to try it : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239246 you'll probably need #237054 >>> It's a happy thought, but openjdk11 seems to be amd64 and i386 only. >>> I'm on aarch64. >>> >>> Thanks for writing! >> >> Support for jdk11/aarch64 has landed in the ports tree. > > When the present (likely futile) attempt to compile www/firefox ends > I'll give jdk11 a try on aarch64. > > IIRC, www/chromium tried to compile java/openjdk8 as a dependency. > Will having openjdk11 already built (before attempting www/chromium) > satisfy the dependency requirement? If more intelligent intervention > is needed please tell me how. > > Many thanks! Not sure if it helps, but I had to build ports on the rPI3 last year and ended up cross compiling on amd64. I wrote down what I did back then here: https://blog.grem.de/sysadmin/FreeBSD-On-rpi3-With-crochet-2018-10-27-18-00.html Best, Michael > bob prohaska > > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: force github file extension for fetch? (tar.bz2 instead of tar.gz)
On Mon, 3 Jun 2019 12:46:32 -0600 Gary Aitken wrote: > On 6/3/19 11:19 AM, Michael Gmelin wrote: > > > > > >> On 3. Jun 2019, at 19:03, Gary Aitken > >> wrote: > >> > >> In attempting to build a new port (prusa3d slicer) I need another > >> new port (wxWidgets). The original distfile fetch of wxWidgets > >> was a .tar.gz. The configure phase had an error; a search for the > >> source of the error turned up a bug (old) which claimed the error > >> was solved by fetching the distfile as a .tar.bz2. > >> .tar.bz2 is the github *nix distfile for the port. > >> > >> Is it possible to force fetching of .tar.bz2 instead of .tar.gz if > >> both are available? Or how does one get around the problem? > >> > >> 11.2-RELEASE-p4 > >> relevant Makefile details: > >> > >> PORTNAME= wxwidgets > >> DISTVERSIONPREFIX= v > >> DISTVERSION=3.1.2 > >> USE_GITHUB= yes > >> GH_ACCOUNT= wxWidgets > >> GH_PROJECT= wxWidgets > >> > > > > See 5.4.5 in the porters handbook (EXTRACT_SUFX) > > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html > > > > Thanks; unfortunately it doesn't seem to work > If I set >EXTRACT_SUFX= .tar.bz2 > it still fetches .tar.gz > If I set >DISTFILES= wxWidgets-wxWidgets-v3.1.2_GH0.tar.bz2 > it also still fetches .tar.gz > > If I manually fetch the file and set the above variables (separate > attempts), make makesum will compute the checksum for both files (if > both are present), but a make extract uses the .gz, not the .bz2 > If I get rid of (rename) the .gz, it ignores the .bz2 and tries to > fetch the .gz. > > Does EXTRACT_SUFX conflict with USE_GITHUB? > Github support is using _GITHUB_EXTRACT_SUFX (see bsd.sites.mk line 450): _GITHUB_REV=0 _GITHUB_EXTRACT_SUFX= .tar.gz So this can't be overridden on purpose. Are you sure you need a new wxWidgets port though? Won't x11-toolkits/wxgtk31 be sufficient (see also: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/using-wx.html ) -m > Thanks, > Gary > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to > "freebsd-ports-unsubscr...@freebsd.org" -- Michael Gmelin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: force github file extension for fetch? (tar.bz2 instead of tar.gz)
> On 3. Jun 2019, at 19:03, Gary Aitken wrote: > > In attempting to build a new port (prusa3d slicer) I need another new > port (wxWidgets). The original distfile fetch of wxWidgets was a .tar.gz. > The configure phase had an error; a search for the source of the error > turned up a bug (old) which claimed the error was solved by fetching the > distfile as a .tar.bz2. > .tar.bz2 is the github *nix distfile for the port. > > Is it possible to force fetching of .tar.bz2 instead of .tar.gz if both are > available? Or how does one get around the problem? > > 11.2-RELEASE-p4 > relevant Makefile details: > > PORTNAME= wxwidgets > DISTVERSIONPREFIX= v > DISTVERSION=3.1.2 > USE_GITHUB= yes > GH_ACCOUNT= wxWidgets > GH_PROJECT= wxWidgets > See 5.4.5 in the porters handbook (EXTRACT_SUFX) https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html -m > Thanks, > > Gary > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Best way to deal with .pyc files?
> On 6. Dec 2018, at 19:21, John Baldwin wrote: > > The devel/gdb port installs python scripts into > /usr/local/share/gdb/python. > If you then run kgdb as root (not that unusual), it will generate .pyc files > in > those directories that are not deleted by 'pkg delete'. What is the best way > to > handle this case? Should the pkg-plist include @rmtry entries for each pyc > file or is there a better way? Pre-generate the pyc files on package build and install them with the port, so they become part of plist (there are examples of that in the ports tree, whenever possible for both py27 and py3x). Best, Michael > -- > John Baldwin > > > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg version is slowwww
> On 26. Oct 2018, at 20:03, Steve Kargl > wrote: > > I recently updated to pkg-1.10.5_5, and I now > find to command "pkg version -vl '<'" to be > much slower than previous versions. > > Four consecutive executions of "time pkg version -vl '<'" > yields > > 54.15 real27.28 user25.66 sys > 48.80 real26.04 user23.01 sys > 48.35 real26.30 user22.59 sys > 48.43 real26.54 user22.32 sys > > During one of these timings, top(1) shows > > 47519 root1 -8021M12M piperd 0 0:00 0.20% pkg > > Is slow down expected? > > Note, "time pkg info" gives > >0.01 real 0.00 user 0.00 sys > What is the timing when using “-R” and when using “-I”? Michael > -- > Steve > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: git checkout branch in makefile
> On 9. Jul 2018, at 19:34, blubee blubeeme wrote: > > Is it possible to do a git checkout of a specific branch in a ports > makefile? > > How would I go about checking out a particular branch from a github project. As branches aren’t stable this won’t buy you anything, that’s why you should always go for a tag or commit (which is branch agnostic). Michael > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Of Git and M$
> On 15. Jun 2018, at 18:37, Dave Horsfall wrote: > >> On Fri, 15 Jun 2018, Michael Gmelin wrote: >> >> github != git > > I didn't say that it was; did you misunderstand my message or something? > someone looking for an alternative to something now owned by M$ Your email sounded like you’re looking for an alternative to git because MS bought github. As git doesn’t require github (and there are alternatives to that too, including hosting a git repo yourself) your logic didn’t add up and I assumed you thought that owning github means owning git, which is not the case. -m > > -- Dave > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Of Git and M$
> On 15. Jun 2018, at 16:26, Dave Horsfall wrote: > > A related discussion reminded me of this: how would Microsoft's purchase of > GitHub affect future development? After all, they'll get to call the > shots...[*] The only good thing that came out of M$ is their RTF document > format (used natively by the Mac's TextEdit utility, for example), which > being plain ASCII can be edited directly if necessary (and I have). > > I've been looking at BitKeeper, for example, the author of which (Larry > McEvoy) I happen to know from another mailing list. Apparently, converting > from Git is as simple as: "git fast-export | bk fast-import". > > And no, before some here accuse me of being a shill for BK, I have nothing to > do with the product whatsoever, other than as someone looking for an > alternative to something now owned by M$ (and I've used just about everything > since SCCS). > github != git > [*] > Remember their motto: "Embrace, extend, extinguish". > > -- Dave, who has been called paranoid before > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Removing git dependencies on perl5 and python27
Hm, seems like you're right, which is good news for me, I always built it without perl until this commit: r396048 | garga | 2015-09-04 00:00:03 +0200 (Fri, 04 Sep 2015) | 5 lines - Update to 2.5.1 - Fix build with NO_PERL set backporting a commit from git repo (82aec45) - Add git-submodile, git-am and git-request-pull to the list of commands that doesn't work without perl @@ -86,7 +86,7 @@ mv $@+ $@ else # NO_PERL -$(SCRIPT_PERL_GEN) git-instaweb: % : unimplemented.sh -+$(SCRIPT_PERL_GEN) git-instaweb git-submodule git-am git-request-pull: % : unimplemented.sh ++$(SCRIPT_PERL_GEN) git-instaweb git-submodule git-request-pull: % : unimplemented.sh Seems like it was removed again here: r416890 | garga | 2016-06-14 16:52:40 +0200 (Tue, 14 Jun 2016) | 4 lines Update devel/git to 2.9.0 @@ -88,7 +38,7 @@ mv $@+ $@ else # NO_PERL -$(SCRIPT_PERL_GEN) git-instaweb: % : unimplemented.sh -+$(SCRIPT_PERL_GEN) git-instaweb git-submodule git-request-pull: % : unimplemented.sh ++$(SCRIPT_PERL_GEN) git-instaweb git-request-pull: % : unimplemented.sh Thanks, Michael On Fri, 15 Jun 2018 03:10:37 -0500 Mahmoud Al-Qudsi wrote: > On Fri, Jun 15, 2018 at 2:57 AM, Michael Gmelin > wrote: > > Last time I checked, building git without Perl broke submodules > > (which is a core feature that should work with a default > > installation). > > I fully agree. Fortunately, (at least at a first glance) that does not > seem to be the case. > > I just built and installed git from source on a clean FreeBSD 12 > install: > > ``` > mqudsi@freebsd12:/easyre % mkdir test > mqudsi@freebsd12:/easyre % cd test > mqudsi@freebsd12:/easyre/test % git init . > Initialized empty Git repository in /easyre/test/.git/ > mqudsi@freebsd12:/easyre/test % git submodule add > https://github.com/neosmart/pkg-graph > Cloning into '/easyre/test/pkg-graph'... > remote: Counting objects: 41, done. > remote: Compressing objects: 100% (27/27), done. > remote: Total 41 (delta 16), reused 38 (delta 13), pack-reused 0 > Unpacking objects: 100% (41/41), done. > mqudsi@freebsd12:/easyre/test % perl > perl: Command not found. > mqudsi@freebsd12:/easyre/test % perl5 > perl5: Command not found. > mqudsi@freebsd12:/easyre/test % fd '^perl$' / > /easyre/git/perl > /easyre/git/t/t4034/perl > mqudsi@freebsd12:/easyre/test % git --version > git version 2.18.0.rc2.dirty > mqudsi@freebsd12:/easyre/test % > ``` > > Mahmoud Al-Qudsi > NeoSmart Technologies -- Michael Gmelin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Removing git dependencies on perl5 and python27
> On 15. Jun 2018, at 05:57, Adam Weinberger wrote: > >> On Thu, Jun 14, 2018 at 8:16 PM Mahmoud Al-Qudsi wrote: >> >> Hello list, >> >> I'm probably not alone in considering git to be a core development tool, >> perhaps just a notch or two below the C compiler. `git` and `sudo` are the >> two >> packages I first install (after `pkg` itself) on any machine, and in many >> cases that suffices to get a basic development environment going. >> >> However, the git package currently brings in a host of unwanted dependencies, >> and I *believe* they can be done without. >> >> This is the complete dependency graph for the git package [0] (generated with >> the newly-minted pkg-graph [1]). It pulls in perl5 and python27, both >> sizeable >> packages and both not required to use git. >> >> While git can be compiled without some of the additional dependencies such as >> expat or pcre, this results in a "crippled" git lacking in some core >> features, >> and requires special build-time definitions like NO_EXPAT or NO_PCRE passed >> to >> the git Makefile. The other dependencies like curl, pcre, and gettext are >> also >> relatively small and typically part of even the most minimal system, but >> perl5 >> and python27 are full-blown runtimes for interpreted languages that have >> fallen out of favor and have been successfully stripped from FreeBSD core >> (and >> even many Linux distributions). >> >> I'm sure these packages are not just there to have a good time and they serve >> some purpose and enable a subset of the git functionality, but my question >> here today is whether that functionality is worth its weight in dependencies, >> and whether the ports team is open to seeing the git package stripped of >> these >> dependencies. >> >> (Obviously the option of adding a "git-lite" package à la "vim-lite" also >> exists, but I think it's fair to say that would be an ugly and unnecessary >> compromise.) >> >> [0]: https://goo.gl/hozu1b >> [1]: https://github.com/neosmart/pkg-graph > > Agreed. I'd personally much rather see small default packages and > -kitchensink slaves, than massive default packages and -lite slaves. > It's always struck me as odd that our git package comes with CVS and > Perforce support. > > # Adam > > Last time I checked, building git without Perl broke submodules (which is a core feature that should work with a default installation). Michael ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Newer FreeBSD version for package breaks binary updates
> On 15. Jan 2018, at 21:04, Jan Beich wrote: > > Michael Gmelin writes: > >> will package builder updates scheduled in a predictable way, so system >> update cycles of users can be aligned, etc.? > > The package cluster starts a build 3 times a week and on amd64/i386 > finishes it within 1-2 days. If unsure check https://pkg-status.freebsd.org/ > aarch64 builder is currently oversubscribed thus struggles to keep /latest > package set in sync with amd64/i386. > Hi, Cool that we start builds three times a week now, I like it. My question was about when the build jails are updated though - is the package cluster always updated to the latest OS version (within the major release) before builds? Thanks, Michael > - Tuesday at 01:00 UTC > - Thursday at 01:00 UTC > - Saturday at 01:00 UTC > ___ > freebsd-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: Newer FreeBSD version for package breaks binary updates
> On 15. Jan 2018, at 16:16, Mathieu Arnold wrote: > >> Le 15/01/2018 à 15:55, Michael Gmelin a écrit : >> Hi Bapt, >> >> I can't get binary updates anymore, because: >> >> pkg: Newer FreeBSD version for package : >> - package: 1200055 >> - running kernel: 1200054 >> pkg: repository FreeBSD contains packages for wrong OS version: >> FreeBSD:12:amd64 >> >> >> Am I misunderstanding this, or does this mean that pkg forces me to >> update my system before I can install any package updates (even super >> small ones). This seems like a bad idea that potentially will break many >> deployments/workflows. > > > pkg is telling you "this package was built with 1200055, you are runing > 1200054, it will probably break" and refuses to install the package. > > If you want to force it, overwrite OSVERSION to 1200055, something like > `pkg -o OSVERSION=1200055 upgrade`. But this will probably break the > packages you install at one point. > I understand that message, but besides that this was hardly a problem in the past (especially for minor version differences), it also forces people to update at the same time as FreeBSD package builders, which has consequences. Is adding this dependency really what we want, will package builder updates scheduled in a predictable way, so system update cycles of users can be aligned, etc.? Otherwise this just adds another way to cut users from updating packages/forces them back to building packages themselves. Yours, 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"
Newer FreeBSD version for package breaks binary updates
Hi Bapt, I can't get binary updates anymore, because: pkg: Newer FreeBSD version for package : - package: 1200055 - running kernel: 1200054 pkg: repository FreeBSD contains packages for wrong OS version: FreeBSD:12:amd64 Am I misunderstanding this, or does this mean that pkg forces me to update my system before I can install any package updates (even super small ones). This seems like a bad idea that potentially will break many deployments/workflows. 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: Vote: making wayland=on default
> On 21. Dec 2017, at 02:14, Chris H wrote: > > On Thu, 21 Dec 2017 00:29:40 +0100 "Michael Gmelin" said > >> > On 20. Dec 2017, at 18:50, Chris H wrote: >> > > On Wed, 20 Dec 2017 17:13:43 + said >> > > On Wed, 20 Dec 2017 16:23:59 + "Johannes Lundberg" >> > > >> > said >> > >> On Wed, Dec 20, 2017 at 4:08 PM, Chris H >> > >> wrote: >> >> > On Wed, 20 Dec 2017 09:20:20 + "Johannes Lundberg" >> >> >> >> > said >> >> > >> >> >> Hi >> >> >> >> >> >> I want to suggest that we enable wayland by default. In current state >> >> >> having some parts of wayland in ports is basically useless the >> >> >> end-users themselves re-build gtk30 and mesa-libs with wayland >> >> >> enabled. >> >> >> >> >> >> libwayland-egl.so from mesa-libs and the extra libraries and headers >> >> >> from gtk30 adds like a few KB, a drop in the ocean compared to xorg >> >> >> packages. (might be something more that I missed) >> >> >> >> >> >> Personally I see no reason not to make it default on, even with >> >> >> flavors coming up. For any Desktop user (as well as embedded devices >> >> >> like IVI-systems and whatnot), Wayland is the future. There's no >> >> >> escaping that. >> >> >> >> >> >> Wayland has been quite usable on FreeBSD for over a year now but >> >> >> access to it is limited due to the extra efforts required to use it. >> >> >> >> >> >> If we are to compare with the other guys, several Linux distros are >> >> >> already switching to wayland-based compositors as default window >> >> >> server. >> >> >> >> >> >> What do you think? >> >> > >> >> > IMHO it's (still) too early. Too much other X(org) related work >> >> > still being completed. In fact, I just built a new dev box to >> >> > track 12 (CURRENT), and this was the first time I was not required >> >> > to pre generate a config file for Xorg. I was only required to >> >> > inform /usr/local/etc/X11/xorg.conf.d/nvidia-driver.conf that >> >> > the driver was "nvidia", not "nv". Everything work(s|ed) famously. >> >> > A real treat. I'm also a bit concerned about the progress (or lack >> >> > there of) on network transparency. >> >> > I (personally) could conceive it as a KERNEL OPTION, but would not >> >> > want to see it in the Default kernel. >> >> > >> >> > Well, those are *my* thoughts. Because you asked. :-) >> >> > >> >> > --Chris >> >> > >> >> Thanks for your feedback! >> >> Just to clarify, we're not talking about changing any defaults that >> >> would impact or change users' choice of desktop. We only want to >> >> enable Wayland compositors as an alternative to X (leaving X as is). >> >> This does not break or modify anything existing. It does not force you >> >> to do anything differently. It simply adds a couple of libraries that >> >> you won't use unless you run Wayland stuff (if you install qt5/gtk30 >> >> and mesa-libs). >> >> The reference to Linux making it default might have been unclear. >> >> Since FreeBSD doesn't have a default desktop, it's hard to change. It >> >> is and will continue to be up to the end user what they choose to use, >> >> we only add more options :) >> > Thanks for the informative reply, Johannes. >> > So no kernel (libs/extensions)? >> > Hmm, gtk3. Why is it not possible to make the Wayland stuff a sub >> > package/option? I think this is the preferred track/policy anyway. >> > I do this for all the ports I currently maintain. IOW any DE related >> > stuff I install, that uses GNOME related material, will pull in gtk3, >> > which, as I understand you say, will ultimately pull in Weston,mesa,... >> > is that correct? While I understand, you indicate it's only a few Kb. >> > I think it's cruft/(unnecessary)overhead. Which, in and of itself >> > seems insignificant. But in the "big picture", and over many (100's) >> > of builds/installations,
Re: Vote: making wayland=on default
> On 20. Dec 2017, at 18:50, Chris H wrote: > > On Wed, 20 Dec 2017 17:13:43 + said > > On Wed, 20 Dec 2017 16:23:59 + "Johannes Lundberg" > said > >> On Wed, Dec 20, 2017 at 4:08 PM, Chris H wrote: >> > On Wed, 20 Dec 2017 09:20:20 + "Johannes Lundberg" >> >> > said >> > >> >> Hi >> >> >> >> I want to suggest that we enable wayland by default. In current state >> >> having some parts of wayland in ports is basically useless the >> >> end-users themselves re-build gtk30 and mesa-libs with wayland >> >> enabled. >> >> >> >> libwayland-egl.so from mesa-libs and the extra libraries and headers >> >> from gtk30 adds like a few KB, a drop in the ocean compared to xorg >> >> packages. (might be something more that I missed) >> >> >> >> Personally I see no reason not to make it default on, even with >> >> flavors coming up. For any Desktop user (as well as embedded devices >> >> like IVI-systems and whatnot), Wayland is the future. There's no >> >> escaping that. >> >> >> >> Wayland has been quite usable on FreeBSD for over a year now but >> >> access to it is limited due to the extra efforts required to use it. >> >> >> >> If we are to compare with the other guys, several Linux distros are >> >> already switching to wayland-based compositors as default window >> >> server. >> >> >> >> What do you think? >> > >> > IMHO it's (still) too early. Too much other X(org) related work >> > still being completed. In fact, I just built a new dev box to >> > track 12 (CURRENT), and this was the first time I was not required >> > to pre generate a config file for Xorg. I was only required to >> > inform /usr/local/etc/X11/xorg.conf.d/nvidia-driver.conf that >> > the driver was "nvidia", not "nv". Everything work(s|ed) famously. >> > A real treat. I'm also a bit concerned about the progress (or lack >> > there of) on network transparency. >> > I (personally) could conceive it as a KERNEL OPTION, but would not >> > want to see it in the Default kernel. >> > >> > Well, those are *my* thoughts. Because you asked. :-) >> > >> > --Chris >> > >> Thanks for your feedback! >> Just to clarify, we're not talking about changing any defaults that >> would impact or change users' choice of desktop. We only want to >> enable Wayland compositors as an alternative to X (leaving X as is). >> This does not break or modify anything existing. It does not force you >> to do anything differently. It simply adds a couple of libraries that >> you won't use unless you run Wayland stuff (if you install qt5/gtk30 >> and mesa-libs). >> The reference to Linux making it default might have been unclear. >> Since FreeBSD doesn't have a default desktop, it's hard to change. It >> is and will continue to be up to the end user what they choose to use, >> we only add more options :) > Thanks for the informative reply, Johannes. > So no kernel (libs/extensions)? > Hmm, gtk3. Why is it not possible to make the Wayland stuff a sub > package/option? I think this is the preferred track/policy anyway. > I do this for all the ports I currently maintain. IOW any DE related > stuff I install, that uses GNOME related material, will pull in gtk3, > which, as I understand you say, will ultimately pull in Weston,mesa,... > is that correct? While I understand, you indicate it's only a few Kb. > I think it's cruft/(unnecessary)overhead. Which, in and of itself > seems insignificant. But in the "big picture", and over many (100's) > of builds/installations, is *not* insignificant. This also dismisses > the security related work, maintaining extra un(used|needed) material. > I suppose some will think that I'm just being nit-picky. But IMHO > I'm not. This sort of thing, if overlooked, *does* affect the bottom > line. > > Thanks again, Johannes! > > P.S. I have nothing against Wayland. I'm just not ready to run it > on anything "production" related, just yet. :-) > > --Chris > The key is to have it in a state that easy to maintain and allows people to install it using pkg install without conflicting with X, so you can switch back and forth easily. I'm also not ready to switch to wayland yet (favorite window manager not available, so many custom configurations I came up with over the years etc.), but giving users an easy way to test it (or use it, as it's becoming more and more mainstream now) is a good thing. Having a modern, working, out of the box desktop (read: no custom kernel builds, no need to use ports, a laptop is the point of first contact for many potential users) is incredibly important for proliferation and compared to the total size of binaries required to run X, I think the usefulness of providing wayland easily outweighs the extra overhead. Yours, Michael >> >> >> >> >> >> /Johannes >> > >> > >>> > > > ___ > freebsd-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: Vote: making wayland=on default
> On 20. Dec 2017, at 13:32, Baptiste Daroussin wrote: > >> On Wed, Dec 20, 2017 at 09:20:20AM +, Johannes Lundberg wrote: >> Hi >> >> I want to suggest that we enable wayland by default. In current state >> having some parts of wayland in ports is basically useless the >> end-users themselves re-build gtk30 and mesa-libs with wayland >> enabled. >> >> libwayland-egl.so from mesa-libs and the extra libraries and headers >> from gtk30 adds like a few KB, a drop in the ocean compared to xorg >> packages. (might be something more that I missed) >> >> Personally I see no reason not to make it default on, even with >> flavors coming up. For any Desktop user (as well as embedded devices >> like IVI-systems and whatnot), Wayland is the future. There's no >> escaping that. >> >> Wayland has been quite usable on FreeBSD for over a year now but >> access to it is limited due to the extra efforts required to use it. >> >> If we are to compare with the other guys, several Linux distros are >> already switching to wayland-based compositors as default window >> server. >> >> What do you think? >> > > I agree on that, we should activate wayland everywhere by defualt, as it does > not prevent at all from having a fully fonctionnal regular X working as well. > > All wayland option should be on, and this as nothing to do with flavors :) > > Please do it :) > > Best regards, > Bapt I add my "vote" from the X11 list: Yes please, I had exactly that problem yesterday. 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: Should a package restart on upgrade itself
> On 27. Jun 2017, at 20:11, Matthias Fechner wrote: > >> Am 27.06.2017 um 18:50 schrieb Vlad K.: >> Will this cover libraries as well? Eg. Libre/Open SSL upgrades, >> restart all services that depend on it? >> >> Meanwhile, there's "lsop": > > thanks for this tool, that is indeed very helpful. > > Maybe it is a good idea if pkg collects the information from each > package what should be restarted if: > > HANDLE_RC_SCRIPTS = true; > > is set. > In this case it is the responsibility of the package maintainer to mark which > service should be started if it was upgraded. > And then do a single bulk restart operation at the end of the complete > upgrade. As default behavior this is not good for admins - you really want to be able to control when a service restarts, especially when running many services, doing multiple updates etc. -m > > Gruß > Matthias > > -- > > "Programming today is a race between software engineers striving to > build bigger and better idiot-proof programs, and the universe trying to > produce bigger and better idiots. So far, the universe is winning." -- > Rich Cook > > ___ > freebsd-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"
No dri and xorg package on FreeBSD:11:aarch64
Hi, It seems like that dri and xorg vanished from pkg+http://pkg.FreeBSD.org/FreeBSD:11:aarch64/latest recently: # pkg version | grep "?" dri-17.0.3,2 ? gbm-17.0.3 ? libEGL-17.0.3 ? libGL-17.0.3 ? libglapi-17.0.3? libglesv2-17.0.3 ? xf86-input-keyboard-1.9.0_1? xf86-input-mouse-1.9.2_1 ? xf86-video-scfb-0.0.4_5? xorg-7.7_2 ? xorg-drivers-7.7_5 ? xorg-server-1.18.4,1 ? Is anyone working on getting them back? 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: Is pkg quarterly really needed?
On Thu, 20 Apr 2017 00:37:22 -0500 Mark Linimon wrote: > I understand that having the quarterlies is not meeting your use case. > You've said that. We get it. > > So you want some kind of running -quarterly branch. > > But where are the N hours of work per week to QA all the patches to > the -quarterly branch, or a -stable branch, or whatever people seem > to demand, to come from? > > This is a serious -- if very irritated -- request. > > We've moved from a "we don't have enough person-power to manage a > ports branch" to "we kinda have enough person-power to manage both > head and a kinda-branch." OK. That isn't meeting all the use > cases. Understood. > > Are you going to volunteer for a team to run that QA? Who else do you > think should be on it? Clearly the current volunteers don't have the > bandwidth. It is hard enough just to kep ports-head building. Where > do the hours come from? > > You're comparing your expectations of the output of what a > professional QA team would do, to the work that N volunteers do. > Obviously the results are not comparable. It's crazy to think that > they would be. > > Honestly without some volunteers to do the _hard_, _unrewarding_, work > to QA the ports tree, this is all either a) just talk, or b) people > wanting volunteers to provide professional-level support, for free. > > tl;dr: provide some resources, or don't. I am getting to the point > where I don't care either way. All I see is the people who are doing > actual work get poked in the eye. > Answering one email in the thread to provide feedback on my experience. After some time it took to adapt, I find quarterly to be extremely useful to me, because a) as a maintainer, it provides a natural deadline when updates should be in the ports tree (as many users will use that for the next three months) b) it's the first time I'm actually using binaries from project servers on a few private hosts and vms c) as professional users, running our own poudriere builders, quarterly branches are useful as a baseline for our ports tree and patches to it. As many things in business are done on a quarterly basis, we simply create a new builder every quarter, build our package set, test the upgrades on staging machines and then change the repo URL on all productions servers and upgrade. So, even though things might not be perfect, to me it's a great improvement compared to the previous situation and I'm grateful to those who put lots of effort into it. -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: LLVM port(s) take very long time to package
> On 14. Apr 2017, at 16:22, Alexey Dokuchaev wrote: > > On Wed, Apr 12, 2017 at 12:06:42PM +0200, Michael Gmelin wrote: >>> On 12. Apr 2017, at 11:37, Alexey Dokuchaev wrote: >>> ... >>> Other alternative to PKG_NOCOMPRESS=1 could be PKGSUFFIX=.tbz (pkg-static >>> create -f tbz ...), will play with that as well. >> >> I don't think bzip will buy you much in terms of performance, > > Surprisingly, it actually did: > > $ time make package PKG_SUFX=.tbz > ===> Building package for llvm40-4.0.0_2 > 565.215u 5.316s 9:34.18 99.3% 7899+502k 1+3020io 0pf+0w >^^^ > Single-threaded bzip2 was faster than multi-threaded xz, at the expense > of larger package of course: > > $ ls -s1 llvm40-4.0.0_2.t* > 386752 llvm40-4.0.0_2.tbz > 286816 llvm40-4.0.0_2.txz >> Interesting, I'll tried that on our high-frequency builders. -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: LLVM port(s) take very long time to package
> On 12. Apr 2017, at 11:37, Alexey Dokuchaev wrote: > > On Wed, Apr 12, 2017 at 10:43:14AM +0200, Michael Gmelin wrote: >>> On 12. Apr 2017, at 05:43, Alexey Dokuchaev wrote: >>> ... >>> pkg was eating 100% (of a single core) during that time, so it looks >>> like it's actually busy (not waiting for I/O or something), but with >>> what? And can it be fixed? LLVM ports are real PITA to (re)build, >>> and while ccache helps to greatly reduce the build times, 3/4-hour >>> package time still cripples it. >> >> It's probably busy compressing the package. Try setting PKG_NOCOMPRESS=1 >> in /etc/make.conf (works ok when just building a package with make, >> didn't test with poudriere[0]). When creating packages, the current >> compression algorithm can't take advantage of multiple cores, so it's >> kind of a bottleneck on modern machines. > > That is my current best guest as well, but I could not confirm it because > /usr/local/sbin/pkg-static is stripped by default and I could not see any > function names when I attached gdb(1) to it. Will rebuild pkg(8) shortly > WITH_DEBUG to get more information. > > Other alternative to PKG_NOCOMPRESS=1 could be PKGSUFFIX=.tbz (pkg-static > create -f tbz ...), will play with that as well. I don't think bzip will buy you much in terms of performance, supporting something like lz4 would be useful. -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: LLVM port(s) take very long time to package
> On 12. Apr 2017, at 05:43, Alexey Dokuchaev wrote: > > Hi there porters, > > It had been annoying me for a while, so I figured I try asking here: > LLVM ports (particularly, llvm39-3.9.1) take abnormally long time to > package, e.g. right now it took 43 minutes (tmpfs-backed build area, > pkg-1.10.0_2.txz, AMD A8 APU @1900 MHz, plenty of RAM, no swap). > > pkg was eating 100% (of a single core) during that time, so it looks > like it's actually busy (not waiting for I/O or something), but with > what? And can it be fixed? LLVM ports are real PITA to (re)build, > and while ccache helps to greatly reduce the build times, 3/4-hour > package time still cripples it. > It's probably busy compressing the package. Try setting PKG_NOCOMPRESS=1 in /etc/make.conf (works ok when just building a package with make, didn't test with poudriere[0]). When creating packages, the current compression algorithm can't take advantage of multiple cores, so it's kind of a bottleneck on modern machines. -m [0] probably not, but it seems like bdrewery is working on this https://github.com/freebsd/poudriere/issues/459 ___ freebsd-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: compiler:c++11-lang doesn't ensure c++11?
On Sat, 18 Mar 2017 15:17:27 -0700 Yuri wrote: > On 03/18/2017 13:59, Michael Gmelin wrote: > > Afaik this is intentional and the point is to depend on a compiler > > that can support those features (hence the comments in compiler.mk: > > "The port needs a compiler understanding Cxx..."), but setting > > CXXFLAGS accordingly is up to the project (through cmake/configure > > etc.) or the port. > > > compiler:c++11-lang is supposed to add the flag when the compiler > doesn't support c++11 by default. (sorry, previous email got butchered) Do you have a reference where this is stated? AFAIK it's only there to make sure to install a compiler that is capable of supporting that version of the C++ standard, not to request the compiler to build each and every translation unit of the port using it. Setting CXXFLAGS is either done by the build system of the software you're porting (which would it allow to use different versions if necessary) or can be requested by setting USE_CXXSTD=c++xx in the port's Makefile. > It is also supposed to upgrade the > compiler (use the higher version from ports) when the base compiler. > Am I misunderstanding the purpose of compiler:c++11-lang? > > See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211134 -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: compiler:c++11-lang doesn't ensure c++11?
On Sat, 18 Mar 2017 15:17:27 -0700 Yuri wrote: > On 03/18/2017 13:59, Michael Gmelin wrote: > > Afaik this is intentional and the point is to depend on a compiler > > that can support those features (hence the comments in compiler.mk: > > "The port needs a compiler understanding Cxx..."), but setting > > CXXFLAGS accordingly is up to the project (through cmake/configure > > etc.) or the port. > > > compiler:c++11-lang is supposed to add the flag when the compiler > doesn't support c++11 by default. Do you have a reference where this is stated? AFAIK it's only there to make sure to install a compiler that is capable of supporting that version of the standard, not to request the compiler to build.Setting the CXXFLAGS is either done by the build system of the software you're porting or can be requested by setting USE_CXXSTD=c++xx in the port's Makefile. > It is also supposed to upgrade the > compiler (use the higher version from ports) when the base compiler. > Am I misunderstanding the purpose of compiler:c++11-lang? > > See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211134 -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: compiler:c++11-lang doesn't ensure c++11?
On Sat, 18 Mar 2017 09:44:12 -0700 Yuri wrote: > On the project that requires c++11, USES=compiler:c++11-lang (also > compiler:c++11-lib) doesn't make the base c++ compiler (clang-3.8.0) > to support c++11. Explicitly adding -std=c++11 to CXXFLAGS does make > it c++11. > > > Is this a bug in Uses/compiler.mk that it fails to set the -std=c++11 > flag for the compiler that doesn't support c++11? > > Afaik this is intentional and the point is to depend on a compiler that can support those features (hence the comments in compiler.mk: "The port needs a compiler understanding Cxx..."), but setting CXXFLAGS accordingly is up to the project (through cmake/configure etc.) or the port. -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: MariaDB 10.1
> On 18 Mar 2017, at 15:09, The Doctor wrote: > > Getting on portmaster > > > ===>>> Launching child to update mariadb101-server-10.1.21 to > mariadb101-server-10.1.22 > > ===>>> All >> mariadb101-server-10.1.21 (2/2) > > ===>>> Currently installed version: mariadb101-server-10.1.21 > ===>>> Port directory: /usr/ports/databases/mariadb101-server > >===>>> This port is marked IGNORE >===>>> You are using OpenSSL from ports and have selected GSSAPI from > base, please select another GSSAPI value > > >===>>> If you are sure you can build it, remove the > IGNORE line in the Makefile and try again. > > ===>>> Update for mariadb101-server-10.1.21 failed > ===>>> Aborting update > > > In client, I removed GSSAPI!! > > What is going on? You need to disable GSSAPI in mariadb-server as well. -m > > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici > doctor@@nl2k.ab.ca > Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist > rising! > http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > God is dead! Yahweh lives! Jesus his only begotten Son is the Risen Saviour!! > ___ > freebsd-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: Writing a port that simply installs a bunch of files
On Mon, 6 Mar 2017 17:45:42 +0100
Andrea Venturoli wrote:
> On 03/06/17 17:05, Michael Gmelin wrote:
>
> >> What about something like this (your files are in files/input.tgz)?
> >> ...
>
> > NO_WRKSUBDIR= yes
> > NO_BUILD= yes
> > NO_INSTALL= yes
> >
> > post-install:
> > @${TAR} -xf ${FILESDIR}/input.tgz -C ${STAGEDIR}
> > @${FIND} ${STAGEDIR} -type f | \
> > ${SED} "s|^${STAGEDIR}||" >> ${TMPPLIST}
> >
> > .include
>
> Guess this is what I was looking for (just the ${TAR} part)...
> basically overriding the "extract" phase.
> I modified ${STAGEDIR} to ${STAGEDIR}/${PREFIX}.
>
> Just why post-install and not do-install?
>
do-install will work as well, assuming you remove 'NO_INSTALL=1' from
the Makefile.
-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: Writing a port that simply installs a bunch of files
On Mon, 6 Mar 2017 16:51:04 +0100
Michael Gmelin wrote:
> On Mon, 6 Mar 2017 16:02:05 +0100
> Andrea Venturoli wrote:
>
> > On 03/06/17 12:50, Michael Gmelin wrote:
> >
> > > Yes, that's possible, see sysutils/bhyve-rc[0] for an example how
> > > to do it.
> >
> > Thanks for your answer: an example is really welcome.
> >
> > However, I might be dumb, but that does not fully cover what I was
> > looking for.
> >
> > I see sysutils/bhyve-rc uses USE_RC_SUBR in order to install its
> > only file, but that's specific to rc.d scripts.
> > Suppose I want a mean to install generic files, should I use
> > SUB_FILES?
> >
> > The first problem I encounter, then, is with subdirectories.
> > Suppose I want to install /usr/local/a/b/c.txt, I would use
> > "SUB_FILES=a/b/c.txt" and provide files/a/b/c.txt.in.
> > However, I'll get:
> > > cannot create /usr/ports/misc/xxx/work/a/b/c.txt: No such file or
> > > directory
> >
> > I've also tried "SUB_FILES=${WRKSRC}/a/b/c.txt", but then make will
> > say:
> > > **
> > > Missing
> > > /usr/ports/misc/xxx/files//usr/ports/misc/xxx/work/xxx-y/a/b/c.txt.in
> > > for xxx-y.
> >
> >
> > Am I missing something obvious?
> >
>
> What about something like this (your files are in files/input.tgz)?
>
> # $FreeBSD: #
>
> PORTNAME= testport
> PORTVERSION=1.0
> CATEGORIES= sysutils
> MASTER_SITES= # none
> DISTFILES= # none
> EXTRACT_ONLY= # none
>
> MAINTAINER= y...@example.org
> COMMENT=Blablabla
>
> NO_WRKSUBDIR= yes
> NO_BUILD= yes
> NO_INSTALL= yes
>
> post-install:
> @${TAR} -xf ${FILESDIR}/input.tgz -C ${STAGEDIR}
> @${FIND} ${STAGEDIR} -type f | ${SED} "s|${STAGEDIR}||" >>
> ${TMPPLIST}
>
> .include
>
>
>
>
Slightly cleaner version below, obviously you could use different
tools to get the files into ${STAGEDIR}.
# $FreeBSD: #
PORTNAME= testport
PORTVERSION=1.0
CATEGORIES= sysutils
MASTER_SITES= # none
DISTFILES= # none
EXTRACT_ONLY= # none
MAINTAINER= y...@example.org
COMMENT=Blablabla
NO_WRKSUBDIR= yes
NO_BUILD= yes
NO_INSTALL= yes
post-install:
@${TAR} -xf ${FILESDIR}/input.tgz -C ${STAGEDIR}
@${FIND} ${STAGEDIR} -type f | \
${SED} "s|^${STAGEDIR}||" >> ${TMPPLIST}
.include
--
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: Writing a port that simply installs a bunch of files
On Mon, 6 Mar 2017 16:02:05 +0100
Andrea Venturoli wrote:
> On 03/06/17 12:50, Michael Gmelin wrote:
>
> > Yes, that's possible, see sysutils/bhyve-rc[0] for an example how
> > to do it.
>
> Thanks for your answer: an example is really welcome.
>
> However, I might be dumb, but that does not fully cover what I was
> looking for.
>
> I see sysutils/bhyve-rc uses USE_RC_SUBR in order to install its only
> file, but that's specific to rc.d scripts.
> Suppose I want a mean to install generic files, should I use
> SUB_FILES?
>
> The first problem I encounter, then, is with subdirectories.
> Suppose I want to install /usr/local/a/b/c.txt, I would use
> "SUB_FILES=a/b/c.txt" and provide files/a/b/c.txt.in.
> However, I'll get:
> > cannot create /usr/ports/misc/xxx/work/a/b/c.txt: No such file or
> > directory
>
> I've also tried "SUB_FILES=${WRKSRC}/a/b/c.txt", but then make will
> say:
> > **
> > Missing
> > /usr/ports/misc/xxx/files//usr/ports/misc/xxx/work/xxx-y/a/b/c.txt.in
> > for xxx-y.
>
>
> Am I missing something obvious?
>
What about something like this (your files are in files/input.tgz)?
# $FreeBSD: #
PORTNAME= testport
PORTVERSION=1.0
CATEGORIES= sysutils
MASTER_SITES= # none
DISTFILES= # none
EXTRACT_ONLY= # none
MAINTAINER= y...@example.org
COMMENT=Blablabla
NO_WRKSUBDIR= yes
NO_BUILD= yes
NO_INSTALL= yes
post-install:
@${TAR} -xf ${FILESDIR}/input.tgz -C ${STAGEDIR}
@${FIND} ${STAGEDIR} -type f | ${SED} "s|${STAGEDIR}||" >>
${TMPPLIST}
.include
--
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: Writing a port that simply installs a bunch of files
> On 6 Mar 2017, at 12:25, Andrea Venturoli wrote:
>
> Hello.
>
> I'm trying to create a small ports for internal use.
> The simplest of these should just place a bunch of files into ${LOCALBASE},
> so I thought I could create a tar archive containing those files, with the
> correct permissions, let "extract" do its work, then have the following:
>
>> do-install:
>>(cd ${WRKSRC} && ${CP} -pR . ${STAGEDIR}${PREFIX})
>
>
> Alas the "extract-fixup-modes" target will ruins all this.
>
> Is there a way to achieve what I'm trying to achieve?
>
>
>
> Better yet, could I just somehow place my content under "files" and do
> without a distfile?
>
>
Yes, that's possible, see sysutils/bhyve-rc[0] for an example how to do it.
-m
[0] https://svnweb.freebsd.org/ports/head/sysutils/bhyve-rc/
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: running poudriere with 8 builders
> On 4 Mar 2017, at 16:32, Matthias Apitz wrote: > >> El día Saturday, March 04, 2017 a las 12:57:40PM +0100, Kurt Jaeger escribió: >> >> Hi! >> Did you use ZFS as file system ? >>> >>> When I did the disk setup, I was also thinking in ZFS, but this would have >>> reduced the netto disk space from 2* 280 GB to the half. >> >> It does not have to be that way. Use only one disk for the system >> and the second disk for a poudriere ZFS pool ? >> >>> I have / for >>> all.the system and /usr/local for poudriere on the 2nd disk. >> >> Use the same setup, but with ZFS. > > I now have made tar-backups of /usr/local/poudiere und /usr/local > (without) poudriere; I will umount the 2nd disk (da1) and restore > /usr/local, which will end up in the 1st disk; > Make sure to initialize poudriere properly on zfs (it will create various filesystems for jails/ports etc). Simply untarring won't cut it. > about the ZFS I'm unsure; the poudriere.conf says: > > ... > #ZPOOL=tank > ... > # root of the poudriere zfs filesystem, by default /poudriere > # ZROOTFS=/poudriere > > Does this mean I should set: > > ZPOOL=poudriere > ZROOTFS=/poudriere > > and do: > > # zpool create poudriere /dev/da1 > > and restore the poudriere.tgz into this having > > /poudriere/poudriere/data/ > /poudriere/poudriere/jails/ > /poudriere/poudriere/ports/ > > or only > > /poudriere/data/ > /poudriere/jails/ > /poudriere/ports/ > > Thanks for clarification. > >matthias > > -- > Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ > +49-176-38902045 > ___ > freebsd-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: Expulsion of John Marino - reasons and impact?
> On 15 Feb 2017, at 00:15, Bryan Drewery wrote: > > On 2/14/2017 2:58 PM, Michael Gmelin wrote: >>>> On 14 Feb 2017, at 22:16, Bryan Drewery wrote: >>>> On 2/14/2017 12:50 PM, Dewayne Geraghty wrote: >>>> https://svnweb.freebsd.org/ports?view=revision&revision=433827 >>> I think that commit message combined with >>> https://www.freebsd.org/internal/code-of-conduct.html is enough. >> The commit message basically says that he misbehaved once too often and the >> CoC defines what "misbehave" might mean. Not over the top >> transparent/detailed to be honest. > > Right, would you want an organization you volunteered for to drag your > name through the mud for some reason? I don't think it's our place (the > project) to say more than we already have publicly. Please drop this > before it gets out of hand. Discussing people personally/negatively in > a public forum is not appropriate. > Well, if it was something he said in public, pointing to it might be enlightening. On the other hand, I assume he could always do that himself if he feels like it. One way or the other, I'll miss his positive contributions and I'm saddened that this happened. -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: Expulsion of John Marino - reasons and impact?
> On 14 Feb 2017, at 22:16, Bryan Drewery wrote: > >> On 2/14/2017 12:50 PM, Dewayne Geraghty wrote: >> https://svnweb.freebsd.org/ports?view=revision&revision=433827 > > I think that commit message combined with > https://www.freebsd.org/internal/code-of-conduct.html is enough. The commit message basically says that he misbehaved once too often and the CoC defines what "misbehave" might mean. Not over the top transparent/detailed to be honest. > >> >> https://svnweb.freebsd.org/ports?view=revision&revision=433856 > > This commit may have been an error and is being discussed. That seems quite draconian and - if it isn't reversed - needs a good explanation. -m > > > -- > Regards, > Bryan Drewery > ___ freebsd-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: cmake release builds don't disable assertions (NDEBUG)
On Mon, 06 Feb 2017 22:27:01 +0100 Raphael Kubo da Costa wrote: > Michael Gmelin writes: > > > While debugging an unexpected assertion problem, I noticed that > > ports using cmake don't set -NDEBUG, even when building in Release > > mode. > > > > Is this intentional? > > Is it the software you're porting that checks for DEBUG or some > library it uses? > > CMake code should check for CMAKE_BUILD_TYPE and adjust the compiler > flags accordingly (if at all); so if the software itself is checking > for DEBUG but not passing (or omitting it) I'd say the bug is there, > not in Mk/Uses/cmake.mk. Well, cmake.mk overwrites the meaning of CMAKE_CXX_FLAGS_RELEASE with the content of CXXFLAGS, are you sure that doing this is the right thing to do? I sampled a couple of smaller projects that use cmake in the ports tree and it seems like many projects don't do anything special to prevent assertions or debug code when built using CMAKE_BUILD_TYPE=Release, which makes me think that the authors depend on the default behaviour of cmake, which includes "-NDEBUG" in Release mode (AFAIK default flags for build types are also compiler and platform dependent, so it kind of makes sense to rely on the defaults, doesn't it?). Thanks, -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"
cmake release builds don't disable assertions (NDEBUG)
While debugging an unexpected assertion problem, I noticed that ports using cmake don't set -NDEBUG, even when building in Release mode. Is this intentional? 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: The ports collection has some serious issues
> On 17 Dec 2016, at 20:47, Alphons van Werven wrote: > > Michael Gmelin wrote: > >> Maybe you could elaborate a bit more what you find so annoying about >> running "poudriere testport origin" before doing "svn commit" that you >> are willing to drop port maintainership over it? > > Sure. In this case it's the precedent that bugs me. > > Needless to say, not being a committer myself, whether/that said folks are > required to use Poudriere and/or Synth for their QA checking is ipso facto > none of my concern. However, I'm pretty sure I know what comes next. When > maintainers need to provide build/QA logs with their PRs (which I think in > many cases makes perfect sense to request, BTW) soon enough Portupgrade or > Portmaster logs, Portlint output, output of explicit > # make check-foo && make bar-qa && make love && make install > and such will cease to suffice and those logs will be going to have to be > Poudriere and/or Synth logs specifically. In other words: I suspect it > won't be long before port maintainership will de facto force maintainers > to install, learn and use Poudriere and/or Synth. And it just so happens > that for me the former in particular is a definite no go for flight. > > To put things into perspective, I do feel compelled to point out that this > is merely the straw that broke the proverbial camel's back. Or the spark > that ignited the gunpowder, if one happens to know what poudriere actually > means. I've been a FreeBSD stalwart since the turn of the century (if not > slightly earlier) and for the most part it has been wonderful. But ever > since some time during the 9.X era I started to pick up signs that the > FreeBSD project as a whole is moving into a direction that troubles me--in > some cases deeply indeed. Particularly during the last few months I found > myself increasingly strongly contemplating moving away from FreeBSD > altogether. And that is exactly what I've now decided to do. > > There's nothing overly dramatic about that; it's a simple observation that > too many things involving the FreeBSD project in general are going in what > I consider undesirable directions, leading to the pragmatic conclusion > that, the past notwithstanding, FreeBSD is unfortunately no longer the > right operating system for me, neither personally nor professionally. > > I'll assume the above was sufficiently elaborate. > It was quite elaborate, but didn't really answer the question - it managed to explain your emotions though, maybe that was more important anyway. Attaching poudriere logs has been best practice for years now and I (using FreeBSD since the mid-90s) adapted quickly, as it made perfect sense to me and getting started with poudriere just took a couple of minutes. If anything, the situation got better this year, as we have a second option (synth) available now. Anyway, it's sad to see you leave, thanks for all your contributions, I've been using some of your ports for years. -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: The ports collection has some serious issues
> On 17 Dec 2016, at 14:26, Alphons van Werven wrote: > > John Marino wrote: > >> In fact, anyone that updates ports should use either poudriere testport >> or synth test. > > Then consider these relinquished: > > /usr/ports/archivers/zip > /usr/ports/astro/wmmoonclock > /usr/ports/astro/xearth > /usr/ports/devel/byaccj > /usr/ports/devel/csmith > /usr/ports/devel/gzstream > /usr/ports/devel/t1lib > /usr/ports/games/xroach > /usr/ports/games/xteddy > /usr/ports/graphics/hsetroot > /usr/ports/mail/xmailbox > /usr/ports/misc/fortune-mod-futurama > /usr/ports/science/gromacs > /usr/ports/security/chaosreader > /usr/ports/www/fcgi > /usr/ports/www/fcgiwrap > /usr/ports/x11/grabc > /usr/ports/x11/xdialog > /usr/ports/x11/xtrlock > /usr/ports/x11-fm/catseye-fm > /usr/ports/x11-fonts/cyberbit-ttfonts > /usr/ports/x11-servers/Xfstt > > Please remove my e-mail address and mirror URL from the relevant > Makefiles. > Maybe you could elaborate a bit more what you find so annoying about running "poudriere testport origin" before doing "svn commit" that you are willing to drop port maintainership over it? -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: wait for mysql availability
> On 11 Jun 2016, at 19:52, abi wrote: > > Yep, that's innodb. It can warm up less than a second, but it's enough > sometimes. Actually, from my point of view, mysql loader should return > control after it's properly initialized. I doubt every port maintainer must > invent their own bicycle if port depends on mysql. At the same time, software that can't automatically recover from the database being unavailable temporarily seems a bit broken to me. - 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: wait for mysql availability
> On 11 Jun 2016, at 08:11, Mathieu Arnold wrote: > > > > +--On 11 juin 2016 13:48:52 +0300 abi wrote: > | Hello, > | > | I have a daemon depended on mysql database, however > | REQUIRE: mysql > | is not enough as mysql databases are not available immediately after > | mysql start, so my daemon fails to start. > | > | Are there any way to check mysql availability that would by mysql setup > | agnostic? > | > | I have 2 ideas: use sleep() or standalone script using application > | credentials in prestart. > > The mysql server should be ready to use after its rc script returns, you > should open a PR with mysql for this to be fixed. > > There's a difference between starting MySQL and it becoming available to clients, e.g. when innodb is recovering from a crash, which can take a long time and is not necessarily something you want to wait for on boot. - 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: Jail's emails
> On 11 Jun 2016, at 15:02, abi wrote: > > Most of work is done by host, so the plan is to disable some of periodic > stuff, leaving only serious matters like port security. > > This can be done by creating /etc/periodic.conf.local file with contents like > this: > ## This is JAILED systems periodic configuration ## > > # Daily options > > daily_status_network_enable="NO" > daily_clean_hoststat_enable="NO" > daily_status_mail_rejects_enable="NO" > daily_status_include_submit_mailq="NO" > daily_status_mailq_enable="NO" > daily_submit_queuerun="NO" > daily_status_disks_enable="NO" # Check disk status > daily_status_rwho_enable="NO" > daily_status_security_pkgaudit_enable="YES" > daily_pgsql_backup_enable="YES" > > daily_show_empty_output="NO" > daily_show_success="NO" > > security_status_kernelmsg_enable="NO" > > security_show_empty_output="NO" > security_show_success="NO" > > # Weekly options > > weekly_whatis_enable="NO" # our jails are read-only /usr > > weekly_show_success="NO" > weekly_show_info="NO" > weekly_show_empty_output="NO" > > With this config files most of the time jail has nothing to report. You can also install ports-mgmt/jailaudit on the host to audit packages in all jails and get the result in the host's security output (afaik this way individual jails won't have to fetch the audit database). - 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"
