Re: py-twisted, py-treq updates
Le Wed, May 04, 2022 at 09:47:09PM +0100, Stuart Henderson a écrit :
> I've tested with deluge and magic-wormhole. Can you check synapse please?
> OK?
i think twisted misses an RDEP on py3-typing_extensions, because
otherwise buildbot wouldnt start:
Traceback (most recent call last):
File "/usr/local/bin/buildbot", line 33, in
sys.exit(load_entry_point('buildbot==3.5.0', 'console_scripts',
'buildbot')())
File "/usr/local/bin/buildbot", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/local/lib/python3.9/importlib/metadata.py", line 86, in load
module = import_module(match.group('module'))
File "/usr/local/lib/python3.9/importlib/__init__.py", line 127, in
import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1030, in _gcd_import
File "", line 1007, in _find_and_load
File "", line 986, in _find_and_load_unlocked
File "", line 680, in _load_unlocked
File "", line 850, in exec_module
File "", line 228, in _call_with_frames_removed
File "/usr/local/lib/python3.9/site-packages/buildbot/scripts/runner.py",
line 32, in
from buildbot.scripts import base
File "/usr/local/lib/python3.9/site-packages/buildbot/scripts/base.py", line
27, in
from buildbot.config.errors import ConfigErrors
File "/usr/local/lib/python3.9/site-packages/buildbot/config/__init__.py",
line 17, in
from .builder import BuilderConfig # noqa pylint: disable=unused-import
File "/usr/local/lib/python3.9/site-packages/buildbot/config/builder.py",
line 17, in
from buildbot.config.checks import check_param_length
File "/usr/local/lib/python3.9/site-packages/buildbot/config/checks.py", line
17, in
from buildbot.process.properties import Interpolate
File "/usr/local/lib/python3.9/site-packages/buildbot/process/properties.py",
line 21, in
from twisted.internet import defer
File "/usr/local/lib/python3.9/site-packages/twisted/internet/defer.py", line
42, in
from typing_extensions import Literal
ModuleNotFoundError: No module named 'typing_extensions'
with the RDEP added my buildbot instance runs fine with this updated twisted,
thanks !
Re: firefox 99.0.1 fails to start on -current
Le Wed, May 04, 2022 at 09:53:14PM +0200, Volker Schlecht a écrit : > > > On 5/3/22 21:20, Mihai Popescu wrote: > > It starts and runs fine for _me_: > > > > _me_ is: > > I tracked it down to a few user settings that seemed to break with (I > presume) the recent mesa/libdrm changes. All of them labeled > "use-at-your-own-risk", so yeah ... > might still be interesting for the list to know 'which' user settings, if someone else stumbles on the same issue ;) Landry
Re: use libtls in mail/msmtp
Stuart Henderson wrote:
> On 2022/04/12 12:45, Nihal Jere wrote:
> > Hi,
> >
> > msmtp has had libtls support for a while, so I think using
> > it would be preferable to GnuTLS. Here is an (untested) diff
> > which replaces GnuTLS with libtls.
>
> checking for libtls >= 0.0... no
> configure: WARNING: library libtls not found:
> configure: WARNING: Package libtls was not found in the pkg-config search path
> configure: WARNING: libtls is provided by LibreSSL
> configure: WARNING: Disabling TLS support, which is very bad. Consider using
> GnuTLS!
>
> it wants a pkg-config file for libtls, which is not included in OpenBSD
>
> > -WANTLIB = c iconv idn2 intl gnutls
> > +WANTLIB = c iconv idn2 intl
>
> When it does actually build against libtls the library dependency should
> show up in "make port-lib-depends-check" too, for adding to WANTLIB.
>
> > MASTER_SITES =https://marlam.de/msmtp/releases/
> > EXTRACT_SUFX =.tar.xz
> >
> > -LIB_DEPENDS =devel/libidn2 \
> > -security/gnutls
> > +LIB_DEPENDS =devel/libidn2
>
> There is now no dependency path to libintl, devel/gettext must be added
> to LIB_DEPENDS.
The attached updates to 1.8.20, hooks the build to skip pkg-config
lookup for libtls, adds the devel/gettext dependency, and patches an
incompatibility between our makeinfo and the author's. I am able to send
email with TLS using the resulting binary. It seems unlikely that my
patch to the info page entirely matches the author's intent but I have
expended all my available patience for deciphering info errors for
today.
--Evan
---
commit 9a498564345734c603e56197fa0d067d920244c5 (master)
from: Evan Silberman
date: Thu May 5 04:46:17 2022 UTC
Update msmtp to 1.8.20 and build with libtls
diff 2d1d2ac39b5b1483e919c50455e13a1c16726af5
34555dd922eb703cb99963441b1686a3d427e082
blob - 8559134974b9a5c885fc1357f007a80bb70edbe0
blob + f2d39e507c6a889139ca8f8432e5474ad8976c88
--- mail/msmtp/Makefile
+++ mail/msmtp/Makefile
@@ -1,6 +1,6 @@
COMMENT = SMTP plugin for MUAs
-DISTNAME = msmtp-1.8.19
+DISTNAME = msmtp-1.8.20
CATEGORIES = mail
HOMEPAGE = https://marlam.de/msmtp/
@@ -8,20 +8,22 @@ HOMEPAGE =https://marlam.de/msmtp/
# GPLv3+
PERMIT_PACKAGE = Yes
-WANTLIB = c iconv idn2 intl gnutls
+WANTLIB = c iconv idn2 intl tls
MASTER_SITES = https://marlam.de/msmtp/releases/
EXTRACT_SUFX = .tar.xz
LIB_DEPENDS = devel/libidn2 \
- security/gnutls
+ devel/gettext
SEPARATE_BUILD = Yes
CONFIGURE_STYLE = gnu
CONFIGURE_ARGS = --with-libgsasl=no \
--with-libidn=yes \
- --with-tls=gnutls \
+ --with-tls=libtls \
--without-libsecret
+CONFIGURE_ENV += libtls_LIBS="-L/usr/lib -l tls" \
+ libtls_CFLAGS="-I/usr/include"
post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/msmtp
blob - 68906af7403e8ac4e6c4f13a0d0e690f46ca78df
blob + d2eefeec5c7757e5f7bc3fdba33d69c1022cfe6e
--- mail/msmtp/distinfo
+++ mail/msmtp/distinfo
@@ -1,2 +1,2 @@
-SHA256 (msmtp-1.8.19.tar.xz) = NKHhmBF2h02+TuZu4NkQPJCYmqTc3Ehh5N4Fzn5EUms=
-SIZE (msmtp-1.8.19.tar.xz) = 383100
+SHA256 (msmtp-1.8.20.tar.xz) = 2TriqvwPSK99ydCzlN8buABYi4tOjQltizzyJTROsRE=
+SIZE (msmtp-1.8.20.tar.xz) = 385696
blob - /dev/null
blob + 3af164c7669d9092bcc17beaa972d7b5608f3911 (mode 644)
--- /dev/null
+++ mail/msmtp/patches/patch-doc_msmtp_texi
@@ -0,0 +1,21 @@
+Index: doc/msmtp.texi
+--- doc/msmtp.texi.orig
doc/msmtp.texi
+@@ -1477,7 +1477,7 @@ just like @ref{passwordeval} in msmtp) or, if none is
+ from the key ring or, if that fails, from a prompt.
+ @end table
+
+-@node Example using msmtpd as a system service
++@node Example using msmtpd as a system service,,,Minimal SMTP server (msmtpd)
+ @section Example: using msmtpd as a system service
+
+ Only use a local interface to listen on. Run msmtpd with correct user rights
+@@ -1494,7 +1494,7 @@ start-stop-daemon --start --pidfile /var/run/msmtpd.pi
+ start-stop-daemon --stop --pidfile /var/run/msmtpd.pid --remove-pidfile
--quiet --signal TERM
+ @end example
+
+-@node Example using msmtpd to handle outgoing mail for an SMTP-based mail
client
++@node Example using msmtpd to handle outgoing mail for an SMTP-based mail
client,,,Minimal SMTP server (msmtpd)
+ @section Example: using msmtpd to handle outgoing mail for an SMTP-based mail
client
+
+ Some mail clients cannot send outgoing mail with a program like msmtp and
blob - f96d077bb49242d5ee6de42ebd8616aa9da5dfd2
blob + f6ef771f20351e64afacf6d9f891affcff48155c
--- mail/msmtp/pkg/PLIST
+++ mail/msmtp/pkg/PLIST
@@ -18,6 +18,8 @@ share/locale/eo/LC_MESSAGES/msmtp.mo
share/locale/fr/LC_MESSAGES/msmtp.mo
share/locale/pt_BR/LC_MESSAGES/msmtp.mo
share/locale/sr/LC_MESSAGES/msmtp.mo
+share/locale/ta/
+share/
Re: mail/procmail CVE-2017-16844
On Thu, May 05, 2022 at 12:09:37AM +0100, Stuart Henderson wrote: > It has been de-abandoned upstream, there is a new release from earlier this > year. Update diff for that below FWIW. It builds, runtime not tested, I > have forgotten how to use it. I've just tested it on amd64, and it works fine with my narrow use case: as an mda which routes to Maildirs, and has a simple SpamAssasin header inspection for routing to the user's spam Maildir.
Re: READMEs files for ports
Hello Marc, Folks regarding the READMEs in ports there is a wide variance in the writing style, sections, verbosity of the READMEs, as far as I can tell there does not seem to be a Template README ( I could be wrong but I have searched ports briefly )and the READMEs across a sampling of ports shows a wide variety of approaches Do we want to standardise the Readmes with a template perhaps with the following headings and advice about what the content of each headings should be ? 1) minimal / basic install - get users started on the port useful for newer users and students trying out a specific ports 2) known Issues perhaps OpenBSD specific - alert users to issues / features that dont work in the port 3) Performance Optimisation 4) security hardening / attack surface reduction steps 4a) sample additional BasicPF config required to allow the port to function 4b) doas configuration 4c) logging configuration 4c) chroot jail guidance ... (if not already supported) even if it may be chroot glamping rather than a chroot jail... do we want the READMEs in mdoc(7) or just txt 5) Example configs (for testing the port and for giving user configuration ideas ?) Hope this helps On Sun, 1 May 2022 at 20:44, Marc Espie wrote: > > You guys got to remember those are mostly written by developers. > > There's a bit of a chicken&egg problem: when you've been playing with > software for a while, it's difficult to figure out what might be a problem > for newcomers. > > That said READMEs files should reflect stuff that's a good idea to do if > you're using that package PREFERABLY IN A VERY TERSE MANNER. > > If you are using packages YOU CAN HELP. > > Yeah. > > What do you think is hard to figure out and could use a mention in a > pkg-readme ? > > Bear in mind that we're mostly talking OpenBSD specific related stuff. > > But personally, I don't mind a quickstart on "unfriendly" opensource > that's hard to get to work without looking at their docs. > > THIS IS AN OPPORTUNITY PEOPLE!!! > > You are using OpenBSD and you thing it's difficult to contribute ? > > Maybe you can share your experiences about making things work and what was > hard to figure out ? > > (Side note: pkg land is very tricky to automate. Some of what you're going to > say I'm probably already aware of, but nevertheless this might give an idea > about priorities on what to work on first) > -- Kindest regards, Tom Smyth.
Re: mail/procmail CVE-2017-16844
On 2022/05/04 23:42, Martin Schröder wrote:
> Am Mi., 6. Dez. 2017 um 13:06 Uhr schrieb Stuart Henderson
> :
> > OK for the fix. But guenther@'s comment from 2015 still stands -
> >
> > "Executive summary: delete the procmail port; the code is not safe and
> > should not be used as a basis for any further work."
> >
> > (https://marc.info/?l=openbsd-ports&m=141634350915839&w=2)
>
> See also https://anarc.at/blog/2022-03-02-procmail-considered-harmful/
>
> "TL;DR: procmail is a security liability and has been abandoned upstream
> for the last two decades. If you are still using it, you should probably drop
> everything and at least remove its SUID flag. There are plenty of alternatives
> to choose from, and conversion is a one-time, acceptable trade-off."
>
> Can we please drop the port (which hasn't been updated since 2017)?
>
> Best
> Martin
>
It has been de-abandoned upstream, there is a new release from earlier this
year. Update diff for that below FWIW. It builds, runtime not tested, I
have forgotten how to use it.
(btw it has never been installed SUID from ports/packages).
The scripts in smstools3 use formail from the procmail distribution and
I never found a working alternative (though I don't run the sms-email
gateway I was using it for any more and all the mobile broadband devices
I have available are either umb or completely unsupported in OpenBSD so
I can't spin it up again to test..) That could be split off like we did
for lockfile though.
Index: Makefile
===
RCS file: /cvs/ports/mail/procmail/Makefile,v
retrieving revision 1.45
diff -u -p -r1.45 Makefile
--- Makefile11 Mar 2022 19:34:53 - 1.45
+++ Makefile4 May 2022 22:57:57 -
@@ -1,23 +1,15 @@
COMMENT= filtering local mail delivery agent
-DISTNAME= procmail-3.22
-CATEGORIES=mail
-REVISION= 8
-
-MASTER_SITES= ${HOMEPAGE} \
- http://mirror.switch.ch/ftp/mirror/procmail/ \
- http://ftp.kfki.hu/packages/mail/procmail/ \
- http://ftp.ucsb.edu/pub/mirrors/procmail/ \
- http://www.ring.gr.jp/archives/net/mail/procmail/ \
- ftp://ftp.informatik.rwth-aachen.de/pub/packages/procmail/ \
- ftp://ftp.fu-berlin.de/pub/unix/mail/procmail/
+GH_ACCOUNT=BuGlessRB
+GH_PROJECT=procmail
+GH_TAGNAME=v3.24
-HOMEPAGE= http://www.procmail.org/
+CATEGORIES=mail
# GPLv2+
PERMIT_PACKAGE=Yes
-WANTLIB= c m
+WANTLIB= c m
FLAVORS= lmtp
FLAVOR?=
Index: distinfo
===
RCS file: /cvs/ports/mail/procmail/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo18 Jan 2015 03:14:25 - 1.4
+++ distinfo4 May 2022 22:57:57 -
@@ -1,2 +1,2 @@
-SHA256 (procmail-3.22.tar.gz) = CHx1s03TPYud9a/p5CgByTlfS/Nzp4TZvJcVOwBi4Rc=
-SIZE (procmail-3.22.tar.gz) = 226817
+SHA256 (procmail-3.24.tar.gz) = UU6kMzOXg+ld+TIeeUdx5Ih7mCOsVf2yRpcCz2m9OYk=
+SIZE (procmail-3.24.tar.gz) = 299704
Index: patches/patch-man_procmailrc_man
===
RCS file: patches/patch-man_procmailrc_man
diff -N patches/patch-man_procmailrc_man
--- patches/patch-man_procmailrc_man11 Mar 2022 19:34:53 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,14 +0,0 @@
-Fix escaping error that causes information loss.
-
-Index: man/procmailrc.man
man/procmailrc.man.orig
-+++ man/procmailrc.man
-@@ -779,7 +779,7 @@ one trailing newline will be stripped.
- .PP
- Some non-optimal and non-obvious regexps set MATCH to an incorrect
- value. The regexp can be made to work by removing one or more unneeded
--'*', '+', or '?' operator on the left-hand side of the \e/ token.
-+\&'*', '+', or '?' operator on the left-hand side of the \e/ token.
- .SH MISCELLANEOUS
- If the regular expression contains `\fB@TO_key@\fP' it will be substituted by
- .na
Index: patches/patch-src_comsat_c
===
RCS file: patches/patch-src_comsat_c
diff -N patches/patch-src_comsat_c
--- patches/patch-src_comsat_c 11 Mar 2022 19:34:53 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,15 +0,0 @@
-A patch from Philip Guenther (procmail maintainer) fixing a
-crash when procmail is invoked without arguments and then
-receive a ^C.
-
src/comsat.c.orig Tue Sep 11 06:55:46 2001
-+++ src/comsat.c Wed Dec 2 23:13:21 2009
-@@ -120,7 +120,7 @@ void sendcomsat(folder)const char*folder;
- { int s;const char*p;
- if(!csvalid||!buf)/* is comat on and set to a valid address? */
- return;
-- if(!*cslgname||strlen(cslgname)+2>linebuf) /* is $LOGNAME bogus? */
-+ if(!cslgname||!*cslgname||strlen(cslgname)+2>linebuf)/* is $LOGNAME bogus?
*/
- return;
- if(!(p=folder?folder:cslastf)) /* do we have a folder? *
Re: nsh manual rewrite in mandoc draft feedback requested style ideas etc
Hello folks, Attached is the latest iteration of the proposed manual for nsh it is not complete yet, but I have tried to take on board Ingo@ very helpful feedback, it has been run through mandoc -Tlint It needs a number of more passes im sure, some additional changes made since last time, removed Appendix A through Appendix E titles and references... as I have not come across Appendices in manual pages (if i recall correctly ) .. I have added more tags to make content more searchable... I do have an issue with presenting " ? " as an argument to commands in the options /arguments for commands as a hack im puting .Op Cm \ ? | other |Command Options the escaped space is to centre the ? in the option Square brackets which I think is more readable bgp [ ? | enable | disable | edit] [options] vs without the escaped space bgp [? | enable | disable | edit] [options] Any other adivice / feedback welcome, as im still updating and improving it ... (it will need a few more passes for certain On Tue, 26 Apr 2022 at 14:28, Tom Smyth wrote: > > Hello Ingo, > Thanks for all your feedback, It s very much appreciated. > Re mandoc(1) vs mdoc(7) thanks for the clarification for me, I will > try to use mdoc(7) when referring to the manpage language > > Your formatting advice was very helpful > > I have tried to fully implement your feedback as best I can with a couple of > exceptions. > .Ss section overuse for trivial commands have been removed but I propose > to retain .Ss for commands with a large subset of commands / sub menu > of commands > > is this appropiate use of the .Ss sections ? > > regarding Sorting ...I agree it needs to be improved, > Im caught between 3 conflicting methods > 1) I think certain commands should be presented in the manual sooner > rather than later > (eg enable, show , ip , ip6 and interface ) > 2) anything else alphabetically > 3) match the ordering of commands in the nsh program ... (some of the > commands probably should be re-ordered Ill discuss > this with Chris, > > I think a hybrid between 1 and 2 options is probably best ... > (aphabetical by default and then present important basic commands > first (as an exception)) > > I will look at the tg macro again (i missed this completely but I > plan to incorporate your advice below shortly > > .Tg rtable > .It Oo Ic no Oc Ic rtable Oo Ar table-id Oc Op name > > In such cases, the .Tg macro is useful to make ":t rtable" work in man(1). > > > Re Upstream Inclusion of the manual I have been discussing with Chris > and once I get a final draft (with current features documented) it > will be checked by Chris and included in the nsh source. > > Attached is the updated version > any other feedback / adivce would be appreciated > > Thanks again > > Tom > > > > > On Mon, 25 Apr 2022 at 21:59, Ingo Schwarze wrote: > > > > Hi Tom, > > > > Tom Smyth wrote on Mon, Apr 25, 2022 at 11:08:26AM +0100: > > > > > I have been translating the txt of MANUAL of nsh port to mandoc > > > > In fact, you have started translating it to mdoc(7) - which is a markup > > language - rather than to mandoc(1) - which is a parsing and formatting > > program for multiple markup languages including mdoc(7). > > > > > there is quite alot of features and syntax to document > > > > Wow, indeed. What a beast! > > > > > so I figured that before I complete the first redraft (that is fit for > > > human consumption) I would get feedback on what I have done so far. > > > > > > do you like the bullets are they too much > > > > My impression is that bullet lists are indeed overused. > > > > > what I should do more of? > > > what i should do less of? > > > > I suggest making sure that features are described completely and > > consisely and not only demonstrated by examples. You certainly > > do not need to add more examples. Wording, grammar, and punctuation > > might profit from some polishing throughout. Some text feels rather > > wordy and repetitive for a manual page but somewhat vague at the > > same time. > > > > In a manual page, the DESCRIPTION needs particular attention because > > it's the first part readers look at. Choosing a good order and > > weeding out repetions is particularly important in that section. > > > > > any advice comments would be appreciated > > > > OK, let's have a stab at it: > > > > > .\" NSH is BSD licensed > > > > Instead of this line, insert the complete text of the license that > > applies to the manual page file, including a "Copyright" line. > > Look in /usr/share/man/man8/ for examples. > > > > > .Nd Network configuration shell > > > > Use lower case instead of sentence case in the .Nd line. > > > > > .Bk -words ... .Ek > > > > No need for that, just delete both the .Bk and the .Ek line. > > > > > .Op Fl i Ar rcfile > > > .Op Fl c Ar rcfile > > > > Use different placeholder names for different option arguments. > > Make them as descriptive as possible. > > > > > for other daemons into one place, providing an alternativ
Re: mail/procmail CVE-2017-16844
Am Mi., 6. Dez. 2017 um 13:06 Uhr schrieb Stuart Henderson : > OK for the fix. But guenther@'s comment from 2015 still stands - > > "Executive summary: delete the procmail port; the code is not safe and > should not be used as a basis for any further work." > > (https://marc.info/?l=openbsd-ports&m=141634350915839&w=2) See also https://anarc.at/blog/2022-03-02-procmail-considered-harmful/ "TL;DR: procmail is a security liability and has been abandoned upstream for the last two decades. If you are still using it, you should probably drop everything and at least remove its SUID flag. There are plenty of alternatives to choose from, and conversion is a one-time, acceptable trade-off." Can we please drop the port (which hasn't been updated since 2017)? Best Martin
maintainer update: net/swirc: 3.3.3 -> 3.3.4
Hi ports@, Here comes an update for net/swirc: ## [3.3.4] - 2022-05-04 ## - **Added** a TLS server (to be used in a future version) - **Added** config option `mouse` (defaults to **no**) - **Added** config option `server_cipher_suite` - **Added** creation of OpenSSL scripts - **Added** event 335 (`RPL_WHOISBOT`) - **Added** global hashfunctions - **Added** preprogrammed IRC network [AlphaChat](https://www.alphachat.net/) - **Added** scrolling using the mouse - **Added** theme item: - `nicklist_my_nick_color` - `whois_bot` - **Added** translations - **Changed** the statusbar to display readline stats - **Converted** - `commands/services.c` -> `commands/services.cpp` - `config.c` -> `config.cpp` - **Defined** `SLASH` once - **Defined** and made use of: - `UNUSED_PARAM()` - `UNUSED_VAR()` - `colorarray_t` - `g_beginthread_failed` - `g_received_welcome` - `usage_t` - **Fixed** bugs discovered with protocol fuzzing - Handle PRIVMSGs from "my" server - Handle truncation of ICB messages, i.e. allow longer messages than `ICB_MESSAGE_MAX`. - Improved scrolling - Made refactoring to multiple files - Moved the names hash table modify API - Print PRIVMSGs to irc channels from users that aren't in them. (No lookup error.) - Reduced code duplication - Reformatted and reindented files ### Windows ### - **Added** GNU LibIntl 0.19.8.1 which is part of [gettext](https://www.gnu.org/software/gettext/) - [Curl](https://curl.se/) 7.83.0 - [LibreSSL](https://www.libressl.org/) 3.5.2 I attach a cvs diff. Markus Index: Makefile === RCS file: /cvs/ports/net/swirc/Makefile,v retrieving revision 1.15 diff -u -p -r1.15 Makefile --- Makefile 11 Mar 2022 19:47:37 - 1.15 +++ Makefile 4 May 2022 19:25:13 - @@ -1,5 +1,5 @@ COMMENT = curses icb and irc client -DISTNAME = swirc-3.3.3 +DISTNAME = swirc-3.3.4 CATEGORIES = net HOMEPAGE = https://www.nifty-networks.net/swirc/ Index: distinfo === RCS file: /cvs/ports/net/swirc/distinfo,v retrieving revision 1.13 diff -u -p -r1.13 distinfo --- distinfo 7 Dec 2021 15:19:36 - 1.13 +++ distinfo 4 May 2022 19:25:13 - @@ -1,2 +1,2 @@ -SHA256 (swirc-3.3.3.tgz) = Kb2OzjhFJ6si7plMAABJukYj6M5uDKgCPhOGumDnKs8= -SIZE (swirc-3.3.3.tgz) = 258705 +SHA256 (swirc-3.3.4.tgz) = KoQEll55amdVWxC1Sq9T0yu9Y+FwfNg2TFcqXtfj+Dc= +SIZE (swirc-3.3.4.tgz) = 271603
Re: chromium disk write directories
Il Mer 4 Mag 2022, 22:57 Mihai Popescu ha scritto: https://wiki.archlinux.org/title/chromium#Tmpfs Ciao, David
chromium disk write directories
Hello, I am trying to make chromium use an mfs partition for temporary files used to display web pages. I already mounted /tmp as an mfs partition. I used XDG_CACHE_HOME=/tmp chrome to force it use the /tmp for cache. I'm not sure if it does. I still see some disk usage, especially when loading youtube start page, I can see disk usage when doing a page down multiple times - pictures are not displayed fast, the disks spins, then they are displayed one by one. If my question and challenge are not failures, can someone tell where chomium is keeping web page bits like pictures and so on the disk? Thank you.
py-twisted, py-treq updates
I've tested with deluge and magic-wormhole. Can you check synapse please?
OK?
Index: devel/py-twisted/Makefile
===
RCS file: /cvs/ports/devel/py-twisted/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- devel/py-twisted/Makefile 11 Mar 2022 18:53:01 - 1.21
+++ devel/py-twisted/Makefile 4 May 2022 20:44:52 -
@@ -1,11 +1,9 @@
COMMENT = asynchronous networking Python framework
-MODPY_EGG_VERSION =20.3.0
+MODPY_EGG_VERSION =22.4.0
-EXTRACT_SUFX = .tar.bz2
DISTNAME = Twisted-${MODPY_EGG_VERSION}
PKGNAME = py-twisted-${MODPY_EGG_VERSION}
-REVISION = 4
CATEGORIES = devel
Index: devel/py-twisted/distinfo
===
RCS file: /cvs/ports/devel/py-twisted/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- devel/py-twisted/distinfo 17 Jun 2020 07:49:59 - 1.6
+++ devel/py-twisted/distinfo 4 May 2022 20:44:52 -
@@ -1,2 +1,2 @@
-SHA256 (Twisted-20.3.0.tar.bz2) = 1yxVtdVuF2VjuR0RlS0TsBr4clxiPkmNtVB7ZhT8HhA=
-SIZE (Twisted-20.3.0.tar.bz2) = 3127793
+SHA256 (Twisted-22.4.0.tar.gz) = oEeZD1ffrh4L0rffJSbU8W3NyEN3TcEIt4xS8qXxNoA=
+SIZE (Twisted-22.4.0.tar.gz) = 3744412
Index: devel/py-twisted/patches/patch-src_twisted_internet_test_test_tcp_py
===
RCS file:
/cvs/ports/devel/py-twisted/patches/patch-src_twisted_internet_test_test_tcp_py,v
retrieving revision 1.3
diff -u -p -r1.3 patch-src_twisted_internet_test_test_tcp_py
--- devel/py-twisted/patches/patch-src_twisted_internet_test_test_tcp_py
11 Mar 2022 18:53:01 - 1.3
+++ devel/py-twisted/patches/patch-src_twisted_internet_test_test_tcp_py
4 May 2022 20:44:52 -
@@ -1,7 +1,7 @@
Index: src/twisted/internet/test/test_tcp.py
--- src/twisted/internet/test/test_tcp.py.orig
+++ src/twisted/internet/test/test_tcp.py
-@@ -3037,7 +3037,11 @@ class SimpleUtilityTests(TestCase):
+@@ -2925,7 +2925,11 @@ class SimpleUtilityTests(TestCase):
accidentally block if it receives bad input.)
"""
err = self.assertRaises(socket.gaierror, _resolveIPv6, "::1", "http")
@@ -12,5 +12,5 @@ Index: src/twisted/internet/test/test_tc
+else:
+self.assertEqual(err.args[0], socket.EAI_NONAME)
- if platform.isWindows():
- test_resolveNumericService.skip = ("The AI_NUMERICSERV flag is not "
+ def test_resolveIPv6(self):
+ """
Index: devel/py-twisted/pkg/PLIST
===
RCS file: /cvs/ports/devel/py-twisted/pkg/PLIST,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST
--- devel/py-twisted/pkg/PLIST 11 Mar 2022 18:53:01 - 1.9
+++ devel/py-twisted/pkg/PLIST 4 May 2022 20:44:52 -
@@ -218,6 +218,7 @@ lib/python${MODPY_VERSION}/site-packages
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/twisted/conch/ssh/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/twisted/conch/ssh/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/twisted/conch/ssh/${MODPY_PYCACHE}_kex.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/twisted/conch/ssh/${MODPY_PYCACHE}_keys_pynacl.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/twisted/conch/ssh/${MODPY_PYCACHE}address.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/twisted/conch/ssh/${MODPY_PYCACHE}agent.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/twisted/conch/ssh/${MODPY_PYCACHE}channel.${MODPY_PYC_MAGIC_TAG}pyc
@@ -233,6 +234,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/twisted/conch/ssh/${MODPY_PYCACHE}transport.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/twisted/conch/ssh/${MODPY_PYCACHE}userauth.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/twisted/conch/ssh/_kex.py
+lib/python${MODPY_VERSION}/site-packages/twisted/conch/ssh/_keys_pynacl.py
lib/python${MODPY_VERSION}/site-packages/twisted/conch/ssh/address.py
lib/python${MODPY_VERSION}/site-packages/twisted/conch/ssh/agent.py
lib/python${MODPY_VERSION}/site-packages/twisted/conch/ssh/channel.py
@@ -465,16 +467,16 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/twisted/internet/iocpreactor/${MODPY_PYCACHE}abstract.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/twisted/internet/iocpreactor/${MODPY_PYCACHE}const.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/twisted/internet/iocpreactor/${MODPY_PYCACHE}interfaces.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/twisted/internet/iocpreactor/${MODPY_PYCACHE}iocpsupport.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/twis
Re: UPDATE rdiff-backup-2.0.5
On 2022/05/04 16:18, Megerman, Joshua wrote:
> This is my first time ever working with source ports, so I don't claim
> to know what I'm doing but I tried my best to follow the ports guide.
> I also don't really know what I'm doing with python, but I think I got
> it done right and it appears to be working as expected with my limited
> testing, so I'm hopeful it's correct. I emailed the listed maintainer of
> the rdiff-backup port last week and haven't heard anything, so I don't
> know if this is still maintained or not. I don't really have time to
> be a package maintainer (nor do I know the ins and outs of doing so,
> especially for OpenBSD), but since it seems that the previous version of
> this package hasn't changed in a long time, maybe it doesn't need active
> "maintaining" per se...
>
> Anyway, here's the patch to the rdiff-backup port to build
> rdiff-backup-2.0.5, which is needed to get away from python 2.7 if you
> want to use rdiff-backup. I haven't changed the maintainer email address
> on it yet as I don't want to step on toes, but I suspect that may be
> inevitable. I'm not sure what the next steps are, but I figure if I'm
> going to figure out how to make it work for myself, I might as well give
> back to the community as well.
Hi, this is a good first submission, thanks. The maintainer of this
port often takes a while to respond to mails. I'll comment inline and
include a new diff below.
> COMMENT = incremental backup
>
> -MODPY_EGG_VERSION =1.2.8
> +MODPY_EGG_VERSION =2.0.5
> DISTNAME = rdiff-backup-${MODPY_EGG_VERSION}
> -REVISION = 8
> +REVISION = 0
ports standard is to just remove the REVISION line when updating to
a new version
> CATEGORIES = sysutils
>
> HOMEPAGE = http://www.nongnu.org/rdiff-backup/
> @@ -16,10 +16,14 @@
>
> LIB_DEPENDS += net/librsync
>
> -MASTER_SITES = ${MASTER_SITE_SAVANNAH:=rdiff-backup/}
> +GH_ACCOUNT =rdiff-backup
> +GH_PROJECT =rdiff-backup
> +GH_TAGNAME =v2.0.5
these would be better placed at the top with DISTNAME etc,
and use ${MODPY_EGG_VERSION} to construct GH_TAGNAME,
but see below
> +MASTER_SITES = ${MASTER_SITES_GITHUB}
with GH_* this is set automatically and best not listed separately
>
> MODULES= lang/python
> -MODPY_VERSION =${MODPY_DEFAULT_VERSION_2}
> +MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
python 3.x is the default, no need to set it
> +--- setup.py.orig Sat Jul 25 04:53:18 2020
> setup.py Fri Apr 29 11:00:32 2022
> +@@ -133,10 +133,12 @@
[...]
> + setup(
> + name="rdiff-backup",
> +-use_scm_version=True,
this should be kept and set a dependency on setuptools_scm,
however that often doesn't work with github autogenerated archives.
generally with Python ports the best method is to fetch the distfile
from pypi instead; set MODPY_PI in the port Makefile, clean the old
github tarball (make clean=dist) and refetch/regen checksum
(make makesum)
> + define_macros=librsync_macros,
> +-include_dirs=incdir_list,
> +-library_dirs=libdir_list,
> +-libraries=libname,
> +-extra_link_args=lflags_arg,
> ++libraries=["rsync"],
> ++include_dirs=include_dirs,
> ++library_dirs=library_dirs,
it does seem to pick up the library ok, just has a bit of trouble finding
headers. it's simpler to avoid these chunks of patch to setup.py and
pass that in via CFLAGS instead.
> + ),
> + ],
> + scripts=["src/rdiff-backup", "src/rdiff-backup-statistics",
> "src/rdiff-backup-delete"],
> + data_files=[
> +-("share/man/man1", ["build/rdiff-backup.1",
> "build/rdiff-backup-statistics.1"]),
> ++("man/man1", ["build/rdiff-backup.1",
> "build/rdiff-backup-statistics.1"]),
good
> + "share/doc/rdiff-backup",
> + [
> + "CHANGELOG.md",
> +-"COPYING",
no need to trim that
> + "README.md",
> + "docs/FAQ.md",
> + "docs/examples.md",
> +@@ -207,7 +207,6 @@
> + "docs/Windows-DEVELOP.md",
> + ],
> + ),
> +-("share/bash-completion/completions",
> ["tools/bash-completion/rdiff-backup"]),
or that
> + ],
> + # options is a hash of hash with command -> option -> value
> + # the value happens here to be a list of file couples/tuples
> +@@ -223,5 +222,4 @@
> + 'clean': clean,
> + },
> + install_requires=['setuptools'],
> +-setup_requires=['setuptools_scm'],
and that does want to be kept
> -lib/python${MODPY_VERSION}/site-packages/rdiff_backup-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info
> -lib/python${MODPY_VERSION}/site-packages/rdiff_backup/C.so
> +lib/python${MODPY_VERSION}/site-packages/rdiff_backup-0.0.0-py${MODPY_VERSION}.egg-info/
> +lib/python${MODPY_VERSION}/site-packages/rdiff_bac
Re: [new] mail/aerc - terminal email client
Omar Polo wrote: > "James Cook" wrote: > > > It's based on a previous submission by Raymond (+cc). I've enabled the > > > notmuch support (but not really tried it yet) and updated it, plus some > > > other minor tweaks. > > > > It is working for me with notmuch. I'm sending this with your aerc port. > > This is my first time using aerc. Thanks for porting it! > > thanks for testing! I'm using aerc in a box where I don't want to sync > locally the mail (otherwise I'd be using mu+mblaze there too probably), > so I didn't have an (easy) mean to test notmuch. > > I've also find out why `make clean' failed: I'm not propagating > MODGO_FLAGS to the upstream makefile. With that fixed, cleaning works > fine. this broke with go.port.mk, but it's now fixed; make sure to update the port tree before trying the tarball. Stuart hit the crash in the setup too, I've reported it upstream and added a README for time being. aerc.tar.gz Description: GNU Zip compressed data
Re: [new] mail/aerc - terminal email client
"James Cook" wrote: > > It's based on a previous submission by Raymond (+cc). I've enabled the > > notmuch support (but not really tried it yet) and updated it, plus some > > other minor tweaks. > > It is working for me with notmuch. I'm sending this with your aerc port. > This is my first time using aerc. Thanks for porting it! thanks for testing! I'm using aerc in a box where I don't want to sync locally the mail (otherwise I'd be using mu+mblaze there too probably), so I didn't have an (easy) mean to test notmuch. I've also find out why `make clean' failed: I'm not propagating MODGO_FLAGS to the upstream makefile. With that fixed, cleaning works fine. aerc.tar.gz Description: GNU Zip compressed data
UPDATE rdiff-backup-2.0.5
This is my first time ever working with source ports, so I don't claim to know
what I'm doing but I tried my best to follow the ports guide. I also don't
really know what I'm doing with python, but I think I got it done right and it
appears to be working as expected with my limited testing, so I'm hopeful it's
correct. I emailed the listed maintainer of the rdiff-backup port last week
and haven't heard anything, so I don't know if this is still maintained or not.
I don't really have time to be a package maintainer (nor do I know the ins and
outs of doing so, especially for OpenBSD), but since it seems that the previous
version of this package hasn't changed in a long time, maybe it doesn't need
active "maintaining" per se...
Anyway, here's the patch to the rdiff-backup port to build rdiff-backup-2.0.5,
which is needed to get away from python 2.7 if you want to use rdiff-backup. I
haven't changed the maintainer email address on it yet as I don't want to step
on toes, but I suspect that may be inevitable. I'm not sure what the next
steps are, but I figure if I'm going to figure out how to make it work for
myself, I might as well give back to the community as well.
Thanks,
Josh
Joshua Megerman
Sr. Systems Engineer
IWCO Direct
diff -urN rdiff-backup.orig/Makefile rdiff-backup/Makefile
--- rdiff-backup.orig/Makefile Fri Mar 11 14:57:55 2022
+++ rdiff-backup/Makefile Fri Apr 29 10:47:33 2022
@@ -1,8 +1,8 @@
COMMENT = incremental backup
-MODPY_EGG_VERSION =1.2.8
+MODPY_EGG_VERSION =2.0.5
DISTNAME = rdiff-backup-${MODPY_EGG_VERSION}
-REVISION = 8
+REVISION = 0
CATEGORIES = sysutils
HOMEPAGE = http://www.nongnu.org/rdiff-backup/
@@ -16,10 +16,14 @@
LIB_DEPENDS += net/librsync
-MASTER_SITES = ${MASTER_SITE_SAVANNAH:=rdiff-backup/}
+GH_ACCOUNT =rdiff-backup
+GH_PROJECT =rdiff-backup
+GH_TAGNAME =v2.0.5
+MASTER_SITES = ${MASTER_SITES_GITHUB}
MODULES= lang/python
-MODPY_VERSION =${MODPY_DEFAULT_VERSION_2}
+MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
+MODPY_SETUPTOOLS = Yes
NO_TEST = Yes
diff -urN rdiff-backup.orig/distinfo rdiff-backup/distinfo
--- rdiff-backup.orig/distinfo Sat Jan 17 22:15:14 2015
+++ rdiff-backup/distinfo Thu Apr 28 16:25:11 2022
@@ -1,2 +1,2 @@
-SHA256 (rdiff-backup-1.2.8.tar.gz) =
DZGoW0CUkRb6iq8V2hZcNKLRVEmzy+AcgCY5ExCslds=
-SIZE (rdiff-backup-1.2.8.tar.gz) = 196526
+SHA256 (rdiff-backup-2.0.5.tar.gz) =
/Trz05/pHvKygeapBkRREsW3GGQOSQyLb4OolgMYNSs=
+SIZE (rdiff-backup-2.0.5.tar.gz) = 441475
diff -urN rdiff-backup.orig/patches/patch-_librsyncmodule_c
rdiff-backup/patches/patch-_librsyncmodule_c
--- rdiff-backup.orig/patches/patch-_librsyncmodule_c Fri Mar 11 14:57:55 2022
+++ rdiff-backup/patches/patch-_librsyncmodule_cWed Dec 31 19:00:00 1969
@@ -1,22 +0,0 @@
-Fix with librsync v1.0.0; similar to
-https://bugs.launchpad.net/duplicity/+bug/1416344
-
-This uses the backwards-compatible format that uses the insecure
-truncated MD4 hash.
-
_librsyncmodule.c.orig Wed Aug 19 20:33:42 2015
-+++ _librsyncmodule.c Wed Aug 19 20:34:42 2015
-@@ -59,8 +59,13 @@ _librsync_new_sigmaker(PyObject* self, PyObject* args)
- if (sm == NULL) return NULL;
- sm->x_attr = NULL;
-
-+#ifdef RS_DEFAULT_STRONG_LEN
- sm->sig_job = rs_sig_begin((size_t)blocklen,
-
(size_t)RS_DEFAULT_STRONG_LEN);
-+#else
-+ sm->sig_job = rs_sig_begin((size_t)blocklen,
-+ (size_t)8,
RS_MD4_SIG_MAGIC);
-+#endif
- return (PyObject*)sm;
- }
-
diff -urN rdiff-backup.orig/patches/patch-rdiff_backup_SetConnections_py
rdiff-backup/patches/patch-rdiff_backup_SetConnections_py
--- rdiff-backup.orig/patches/patch-rdiff_backup_SetConnections_py Fri Mar
11 14:57:55 2022
+++ rdiff-backup/patches/patch-rdiff_backup_SetConnections_py Wed Dec 31
19:00:00 1969
@@ -1,18 +0,0 @@
-Bugfix: DeprecationWarning: os.popen2 is deprecated
-cf http://bugs.gentoo.org/attachment.cgi?id=216585&action=view
-
rdiff_backup/SetConnections.py.origMon Mar 16 14:36:21 2009
-+++ rdiff_backup/SetConnections.py Wed Aug 19 20:31:28 2015
-@@ -135,10 +135,10 @@ def init_connection(remote_cmd):
- if not remote_cmd: return Globals.local_connection
-
- Log("Executing " + remote_cmd, 4)
-- if os.name == "nt":
-+ if map(int, sys.version.split()[0].split('.')[:2]) >= [2, 6]:
- import subprocess
- try:
-- process = subprocess.Popen(remote_cmd, shell=False,
bufsize=0,
-+ process = subprocess.Popen(remote_cmd, shell=True,
bufsize=0,
-
stdin=subprocess.PIPE,
-
stdout=subprocess.PIPE)
-
Re: [new] www/py-httpretty-1.1.4
On 2022/05/04 12:30, portno12 wrote:
> got it.
>
> new tarball with your previous diff and the tests i ignored removed. i left
> the link for documentation of the failing tests.
>
> any other changes you can see that i might need to make and learn from?
I don't think so, this is OK with me (ifor reviewers: the other port
needed is in https://marc.info/?l=openbsd-ports&m=165159894521779&w=2)
>
> --- Original Message ---
> On Wednesday, May 4th, 2022 at 12:23 PM, Stuart Henderson
> wrote:
>
>
> > On 2022/05/04 12:07, portno12 wrote:
> >
> > > thanks for the help with the missing port and diff.
> > >
> > > adding your diff and the missing port got this further. there were a
> > > number of tests still failing. i ignored the broken tests as its a known
> > > issue (https://github.com/gabrielfalcao/HTTPretty/issues/449), i also
> > > added py-requests as a needed test dep.
> > >
> > > a couple warnings (also known in the same issue above) still present but
> > > they didnt fail any tests.
> > >
> > > updated tarball attached for py-httpretty.
> >
> >
> > Better to not disable tests which are just failing, unless they prevent
> > other tests from running (as was the case with some of the tests with
> > missing dep's)
> >
> > I don't expect tests to always all pass, in most cases it's more about
> > getting a feel for whether the software in general is going to work ok
> > on OpenBSD
> >
> > > --- Original Message ---
> > > On Tuesday, May 3rd, 2022 at 5:29 PM, Stuart Henderson
> > > s...@spacehopper.org wrote:
> > >
> > > > On 2022/05/02 23:55, portno12 wrote:
> > > >
> > > > > created by portgen and seems fine on amd64, no tests due to needing a
> > > > > lot of new or updated ports. its a dep for another port i am working
> > > > > on so will get tested via that soon
> > > >
> > > > portgen isn't really good at python ports at the moment.
> > > >
> > > > Here are some changes on top and the 1 new port needed to enable most
> > > > tests.
> > > >
> > > > diff --git www/py-httpretty/Makefile www/py-httpretty/Makefile
> > > > index f29b61f..8d28950 100644
> > > > --- www/py-httpretty/Makefile
> > > > +++ www/py-httpretty/Makefile
> > > > @@ -16,12 +16,22 @@ MODULES = lang/python
> > > >
> > > > MODPY_PI = Yes
> > > > MODPY_SETUPTOOLS = Yes
> > > > -MODPY_TEST = Yes
> > > > -MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
> > > > +MODPY_PYTEST = Yes
> > > >
> > > > -# many test deps either need ported or updated
> > > > -NO_TEST = Yes
> > > > +# need https, eventlet - not ported
> > > > +MODPY_PYTEST_ARGS = --ignore
> > > > tests/bugfixes/nosetests/test_414_httpx.py \
> > > > + --ignore tests/bugfixes/nosetests/test_eventlet.py \
> > > > + --ignore tests/functional/test_httplib2.py
> > > > +
> > > > +FLAVOR = python3
> > > > +FLAVORS = python3
> > > > +
> > > > +TEST_DEPENDS = devel/py-freezegun${MODPY_FLAVOR} \
> > > > + devel/py-sure${MODPY_FLAVOR} \
> > > > + net/py-boto3${MODPY_FLAVOR} \
> > > > + www/py-httplib2${MODPY_FLAVOR} \
> > > > + www/py-tornado${MODPY_FLAVOR}
> > > >
> > > > -# Lines below not in the template
> > > > FIX_EXTRACT_PERMISSIONS = Yes
> > > > +
> > > > .include
> >
> >
UPDATE: Tor Browser 11.0.11
Hi,
Here is an update to Tor Browser 11.0.11. Tested on amd64.
More information here:
https://blog.torproject.org/new-release-tor-browser-11011/
Caspar Schutijser
Index: meta/tor-browser/Makefile
===
RCS file: /cvs/ports/meta/tor-browser/Makefile,v
retrieving revision 1.54
diff -u -p -r1.54 Makefile
--- meta/tor-browser/Makefile 12 Apr 2022 20:40:05 - 1.54
+++ meta/tor-browser/Makefile 4 May 2022 15:05:14 -
@@ -2,11 +2,11 @@ COMMENT= Tor Browser meta package
MAINTAINER=Caspar Schutijser
-PKGNAME= tor-browser-11.0.10
+PKGNAME= tor-browser-11.0.11
ONLY_FOR_ARCHS = amd64
-RUN_DEPENDS= www/tor-browser/browser>=11.0.10 \
- www/tor-browser/noscript>=11.4.3 \
- net/tor>=0.4.6.10
+RUN_DEPENDS= www/tor-browser/browser>=11.0.11 \
+ www/tor-browser/noscript>=11.4.5 \
+ net/tor>=0.4.7.7
.include
Index: www/tor-browser/Makefile.inc
===
RCS file: /cvs/ports/www/tor-browser/Makefile.inc,v
retrieving revision 1.52
diff -u -p -r1.52 Makefile.inc
--- www/tor-browser/Makefile.inc12 Apr 2022 20:40:05 - 1.52
+++ www/tor-browser/Makefile.inc4 May 2022 15:05:14 -
@@ -3,7 +3,7 @@ HOMEPAGE ?= https://www.torproject.org
PERMIT_PACKAGE ?= Yes
CATEGORIES = www
BROWSER_NAME = tor-browser
-TB_VERSION = 11.0.10
+TB_VERSION = 11.0.11
TB_PREFIX =tb
SUBST_VARS += BROWSER_NAME TB_VERSION
Index: www/tor-browser/browser/Makefile
===
RCS file: /cvs/ports/www/tor-browser/browser/Makefile,v
retrieving revision 1.79
diff -u -p -r1.79 Makefile
--- www/tor-browser/browser/Makefile12 Apr 2022 20:40:05 - 1.79
+++ www/tor-browser/browser/Makefile4 May 2022 15:05:14 -
@@ -15,7 +15,7 @@ EXTRACT_SUFX =.tar.xz
PATCHORIG =.pat.orig
PKGNAME = ${TB_PREFIX}-browser-${TB_VERSION}
-DISTNAME = src-firefox-tor-browser-91.8.0esr-11.0-1-build1
+DISTNAME = src-firefox-tor-browser-91.9.0esr-11.0-1-build1
FIX_EXTRACT_PERMISSIONS= Yes
EXTRACT_ONLY +=${DISTNAME}.tar.xz \
@@ -84,7 +84,7 @@ BUILD_DEPENDS += devel/py-virtualenv
BUILD_DEPENDS += archivers/unzip archivers/zip
-RUN_DEPENDS += net/tor>=0.4.6.10
+RUN_DEPENDS += net/tor>=0.4.7.7
CONFIGURE_ARGS += --enable-release #1386371
CONFIGURE_ARGS += --enable-sandbox
Index: www/tor-browser/browser/distinfo
===
RCS file: /cvs/ports/www/tor-browser/browser/distinfo,v
retrieving revision 1.50
diff -u -p -r1.50 distinfo
--- www/tor-browser/browser/distinfo12 Apr 2022 20:40:05 - 1.50
+++ www/tor-browser/browser/distinfo4 May 2022 15:05:14 -
@@ -1,8 +1,8 @@
SHA256 (mozilla/https-everywhere-2021.4.15-eff.xpi) =
fl9ygI6hSL7M1BbsvfM+oevEOkMuTnhbXl4TObeitwg=
-SHA256 (mozilla/src-firefox-tor-browser-91.8.0esr-11.0-1-build1.tar.xz) =
fEH0W0zIL1Ag/+AJRk/OPctGPcaWViUTmq5ucOqhtsY=
+SHA256 (mozilla/src-firefox-tor-browser-91.9.0esr-11.0-1-build1.tar.xz) =
Pt1ltzyYS68FDIn1BHhvoNgPbJEVJqrZKuZ9CkziMgw=
SHA256 (mozilla/src-tor-launcher-0.2.33.tar.xz) =
ZG7lH5mBhkCRA26AEdCo52HP0iNlHKbRKl/BKyP0C9U=
-SHA256 (mozilla/tor-browser-linux64-11.0.10_en-US.tar.xz) =
l95Me9hKfKiS0sPu6pmUGnizq/P9/O0mnPCktQLYacg=
+SHA256 (mozilla/tor-browser-linux64-11.0.11_en-US.tar.xz) =
bflHNUQPYIy4DFtFx3eiWprqpbXwE32rKPzobZsUqbc=
SIZE (mozilla/https-everywhere-2021.4.15-eff.xpi) = 1746434
-SIZE (mozilla/src-firefox-tor-browser-91.8.0esr-11.0-1-build1.tar.xz) =
412536840
+SIZE (mozilla/src-firefox-tor-browser-91.9.0esr-11.0-1-build1.tar.xz) =
413171628
SIZE (mozilla/src-tor-launcher-0.2.33.tar.xz) = 229992
-SIZE (mozilla/tor-browser-linux64-11.0.10_en-US.tar.xz) = 86532224
+SIZE (mozilla/tor-browser-linux64-11.0.11_en-US.tar.xz) = 86558040
Index: www/tor-browser/noscript/Makefile
===
RCS file: /cvs/ports/www/tor-browser/noscript/Makefile,v
retrieving revision 1.42
diff -u -p -r1.42 Makefile
--- www/tor-browser/noscript/Makefile 12 Apr 2022 20:40:05 - 1.42
+++ www/tor-browser/noscript/Makefile 4 May 2022 15:05:14 -
@@ -1,5 +1,5 @@
ADDON_NAME = noscript
-V =11.4.3
+V =11.4.5
COMMENT = Tor Browser add-on: flexible JS blocker
HOMEPAGE = https://noscript.net
MASTER_SITES = https://secure.informaction.com/download/releases/
Index: www/tor-browser/noscript/distinfo
===
RCS file: /cvs/ports/www/tor-browser/noscript/distinfo,v
retrieving revision 1.37
diff -u -p -r1.37 distinfo
UPDATE: Nextcloud-23.0.4
Hello, Update for Nextcloud to 23.0.4: https://nextcloud.com/changelog/#latest23 OK? Comments? Cheers.- -- %gonzalo Index: Makefile === RCS file: /cvs/ports/www/nextcloud/23/Makefile,v retrieving revision 1.5 diff -u -p -r1.5 Makefile --- Makefile24 Mar 2022 16:36:17 - 1.5 +++ Makefile4 May 2022 10:36:46 - @@ -1,4 +1,3 @@ -NC_VERSION=23.0.2 -NC_VERSION=23.0.3 +NC_VERSION=23.0.4 .include Index: distinfo === RCS file: /cvs/ports/www/nextcloud/23/distinfo,v retrieving revision 1.3 diff -u -p -r1.3 distinfo --- distinfo24 Mar 2022 16:36:17 - 1.3 +++ distinfo4 May 2022 10:36:46 - @@ -1,2 +1,2 @@ -SHA256 (nextcloud-23.0.3.tar.bz2) = OUAdQA+rAqhKF16m6ZW47UEQ+66kjIdiMLTwl1WmKYY= -SIZE (nextcloud-23.0.3.tar.bz2) = 139983015 +SHA256 (nextcloud-23.0.4.tar.bz2) = ZxkcK4tBWRrkKsz7MiFjE/3g4QcgFoLLOQKfiQcSvGo= +SIZE (nextcloud-23.0.4.tar.bz2) = 140409123 Index: pkg/PLIST === RCS file: /cvs/ports/www/nextcloud/23/pkg/PLIST,v retrieving revision 1.4 diff -u -p -r1.4 PLIST --- pkg/PLIST 24 Mar 2022 16:36:17 - 1.4 +++ pkg/PLIST 4 May 2022 10:36:48 - @@ -8517,6 +8517,8 @@ nextcloud/apps/accessibility/l10n/es_DO. nextcloud/apps/accessibility/l10n/es_DO.json nextcloud/apps/accessibility/l10n/es_EC.js nextcloud/apps/accessibility/l10n/es_EC.json +nextcloud/apps/accessibility/l10n/es_GT.js +nextcloud/apps/accessibility/l10n/es_GT.json nextcloud/apps/accessibility/l10n/es_MX.js nextcloud/apps/accessibility/l10n/es_MX.json nextcloud/apps/accessibility/l10n/et_EE.js @@ -8694,6 +8696,8 @@ nextcloud/apps/activity/l10n/ast.js nextcloud/apps/activity/l10n/ast.json nextcloud/apps/activity/l10n/az.js nextcloud/apps/activity/l10n/az.json +nextcloud/apps/activity/l10n/be.js +nextcloud/apps/activity/l10n/be.json nextcloud/apps/activity/l10n/bg.js nextcloud/apps/activity/l10n/bg.json nextcloud/apps/activity/l10n/bn_BD.js @@ -9074,8 +9078,10 @@ nextcloud/apps/admin_audit/lib/Actions/U nextcloud/apps/admin_audit/lib/Actions/Versions.php nextcloud/apps/admin_audit/lib/AppInfo/ nextcloud/apps/admin_audit/lib/AppInfo/Application.php +nextcloud/apps/admin_audit/lib/AuditLogger.php nextcloud/apps/admin_audit/lib/BackgroundJobs/ nextcloud/apps/admin_audit/lib/BackgroundJobs/Rotate.php +nextcloud/apps/admin_audit/lib/IAuditLogger.php nextcloud/apps/admin_audit/lib/Listener/ nextcloud/apps/admin_audit/lib/Listener/CriticalActionPerformedEventListener.php nextcloud/apps/circles/ @@ -9423,6 +9429,7 @@ nextcloud/apps/circles/lib/Exceptions/Gr nextcloud/apps/circles/lib/Exceptions/GroupNotFoundException.php nextcloud/apps/circles/lib/Exceptions/InitiatorNotConfirmedException.php nextcloud/apps/circles/lib/Exceptions/InitiatorNotFoundException.php +nextcloud/apps/circles/lib/Exceptions/InsufficientPermissionException.php nextcloud/apps/circles/lib/Exceptions/InvalidIdException.php nextcloud/apps/circles/lib/Exceptions/InvalidModelException.php nextcloud/apps/circles/lib/Exceptions/JsonException.php @@ -9455,6 +9462,7 @@ nextcloud/apps/circles/lib/Exceptions/Ow nextcloud/apps/circles/lib/Exceptions/ParseMemberLevelException.php nextcloud/apps/circles/lib/Exceptions/PayloadDeliveryException.php nextcloud/apps/circles/lib/Exceptions/RemoteAlreadyExistsException.php +nextcloud/apps/circles/lib/Exceptions/RemoteCircleException.php nextcloud/apps/circles/lib/Exceptions/RemoteInstanceException.php nextcloud/apps/circles/lib/Exceptions/RemoteNotFoundException.php nextcloud/apps/circles/lib/Exceptions/RemoteResourceNotFoundException.php @@ -9468,6 +9476,7 @@ nextcloud/apps/circles/lib/Exceptions/Sh nextcloud/apps/circles/lib/Exceptions/SharingFrameDoesNotExistException.php nextcloud/apps/circles/lib/Exceptions/SharingFrameSourceCannotBeAppCirclesException.php nextcloud/apps/circles/lib/Exceptions/SingleCircleNotFoundException.php +nextcloud/apps/circles/lib/Exceptions/SuperSessionException.php nextcloud/apps/circles/lib/Exceptions/TokenDoesNotExistException.php nextcloud/apps/circles/lib/Exceptions/UnknownFederatedItemException.php nextcloud/apps/circles/lib/Exceptions/UnknownInterfaceException.php @@ -9572,6 +9581,7 @@ nextcloud/apps/circles/lib/Migration/Ver nextcloud/apps/circles/lib/Migration/Version0023Date20211216113101.php nextcloud/apps/circles/lib/Migration/Version0024Date20220203123901.php nextcloud/apps/circles/lib/Migration/Version0024Date20220203123902.php +nextcloud/apps/circles/lib/Migration/Version0024Date20220317190331.php nextcloud/apps/circles/lib/Model/ nextcloud/apps/circles/lib/Model/BaseCircle.php nextcloud/apps/circles/lib/Model/BaseMember.php @@ -9647,6 +9657,7 @@ nextcloud/apps/circles/lib/Service/Migra nextcloud/apps/circles/lib/Service/MiscService.php nextcloud/apps/circles/lib/Service/NotificationServi
UPDATE: Nextcloud-21.0.9
Hello, Update for Nextcloud to 21.0.9: https://nextcloud.com/changelog/#latest21 OK? Comments? Cheers.- -- %gonzalo Index: Makefile === RCS file: /cvs/ports/www/nextcloud/21/Makefile,v retrieving revision 1.12 diff -u -p -r1.12 Makefile --- Makefile23 Mar 2022 23:58:30 - 1.12 +++ Makefile4 May 2022 12:59:11 - @@ -1,4 +1,3 @@ -NC_VERSION=21.0.8 -REVISION= 0 +NC_VERSION=21.0.9 .include Index: distinfo === RCS file: /cvs/ports/www/nextcloud/21/distinfo,v retrieving revision 1.8 diff -u -p -r1.8 distinfo --- distinfo16 Feb 2022 15:34:25 - 1.8 +++ distinfo4 May 2022 12:59:11 - @@ -1,2 +1,2 @@ -SHA256 (nextcloud-21.0.8.tar.bz2) = 39TtWUIV1k7iYD+rM39Rjinmu8lmwrUAqddqZy4/gwE= -SIZE (nextcloud-21.0.8.tar.bz2) = 127759792 +SHA256 (nextcloud-21.0.9.tar.bz2) = p6bvgTXmmjGN3TRQpG88f3YPksh0QzWG9j9KnEjcrqE= +SIZE (nextcloud-21.0.9.tar.bz2) = 128237860 Index: pkg/PLIST === RCS file: /cvs/ports/www/nextcloud/21/pkg/PLIST,v retrieving revision 1.10 diff -u -p -r1.10 PLIST --- pkg/PLIST 11 Mar 2022 20:10:09 - 1.10 +++ pkg/PLIST 4 May 2022 12:59:13 - @@ -8932,6 +8932,8 @@ nextcloud/apps/admin_audit/l10n/et_EE.js nextcloud/apps/admin_audit/l10n/et_EE.json nextcloud/apps/admin_audit/l10n/eu.js nextcloud/apps/admin_audit/l10n/eu.json +nextcloud/apps/admin_audit/l10n/fa.js +nextcloud/apps/admin_audit/l10n/fa.json nextcloud/apps/admin_audit/l10n/fi.js nextcloud/apps/admin_audit/l10n/fi.json nextcloud/apps/admin_audit/l10n/fr.js @@ -14883,54 +14885,72 @@ nextcloud/apps/privacy/js/ nextcloud/apps/privacy/js/chunks/ nextcloud/apps/privacy/js/chunks/0-67bdb1018507b71d5d1a.js nextcloud/apps/privacy/js/chunks/0-67bdb1018507b71d5d1a.js.map +nextcloud/apps/privacy/js/chunks/0-9ea6a34ed60ea48eec27.js +nextcloud/apps/privacy/js/chunks/0-9ea6a34ed60ea48eec27.js.map nextcloud/apps/privacy/js/chunks/0-cb3756be5d83e6808ba0.js nextcloud/apps/privacy/js/chunks/0-cb3756be5d83e6808ba0.js.map nextcloud/apps/privacy/js/chunks/0-d52ff358baed002ec5de.js nextcloud/apps/privacy/js/chunks/0-d52ff358baed002ec5de.js.map nextcloud/apps/privacy/js/chunks/1-67bdb1018507b71d5d1a.js nextcloud/apps/privacy/js/chunks/1-67bdb1018507b71d5d1a.js.map +nextcloud/apps/privacy/js/chunks/1-9ea6a34ed60ea48eec27.js +nextcloud/apps/privacy/js/chunks/1-9ea6a34ed60ea48eec27.js.map nextcloud/apps/privacy/js/chunks/1-cb3756be5d83e6808ba0.js nextcloud/apps/privacy/js/chunks/1-cb3756be5d83e6808ba0.js.map nextcloud/apps/privacy/js/chunks/1-d52ff358baed002ec5de.js nextcloud/apps/privacy/js/chunks/1-d52ff358baed002ec5de.js.map nextcloud/apps/privacy/js/chunks/2-67bdb1018507b71d5d1a.js nextcloud/apps/privacy/js/chunks/2-67bdb1018507b71d5d1a.js.map +nextcloud/apps/privacy/js/chunks/2-9ea6a34ed60ea48eec27.js +nextcloud/apps/privacy/js/chunks/2-9ea6a34ed60ea48eec27.js.map nextcloud/apps/privacy/js/chunks/2-cb3756be5d83e6808ba0.js nextcloud/apps/privacy/js/chunks/2-cb3756be5d83e6808ba0.js.map nextcloud/apps/privacy/js/chunks/2-d52ff358baed002ec5de.js nextcloud/apps/privacy/js/chunks/2-d52ff358baed002ec5de.js.map nextcloud/apps/privacy/js/chunks/3-67bdb1018507b71d5d1a.js nextcloud/apps/privacy/js/chunks/3-67bdb1018507b71d5d1a.js.map +nextcloud/apps/privacy/js/chunks/3-9ea6a34ed60ea48eec27.js +nextcloud/apps/privacy/js/chunks/3-9ea6a34ed60ea48eec27.js.map nextcloud/apps/privacy/js/chunks/3-cb3756be5d83e6808ba0.js nextcloud/apps/privacy/js/chunks/3-cb3756be5d83e6808ba0.js.map nextcloud/apps/privacy/js/chunks/3-d52ff358baed002ec5de.js nextcloud/apps/privacy/js/chunks/3-d52ff358baed002ec5de.js.map nextcloud/apps/privacy/js/chunks/5-67bdb1018507b71d5d1a.js nextcloud/apps/privacy/js/chunks/5-67bdb1018507b71d5d1a.js.map +nextcloud/apps/privacy/js/chunks/5-9ea6a34ed60ea48eec27.js +nextcloud/apps/privacy/js/chunks/5-9ea6a34ed60ea48eec27.js.map nextcloud/apps/privacy/js/chunks/5-cb3756be5d83e6808ba0.js nextcloud/apps/privacy/js/chunks/5-cb3756be5d83e6808ba0.js.map nextcloud/apps/privacy/js/chunks/5-d52ff358baed002ec5de.js nextcloud/apps/privacy/js/chunks/5-d52ff358baed002ec5de.js.map nextcloud/apps/privacy/js/chunks/6-67bdb1018507b71d5d1a.js nextcloud/apps/privacy/js/chunks/6-67bdb1018507b71d5d1a.js.map +nextcloud/apps/privacy/js/chunks/6-9ea6a34ed60ea48eec27.js +nextcloud/apps/privacy/js/chunks/6-9ea6a34ed60ea48eec27.js.map nextcloud/apps/privacy/js/chunks/6-cb3756be5d83e6808ba0.js nextcloud/apps/privacy/js/chunks/6-cb3756be5d83e6808ba0.js.map nextcloud/apps/privacy/js/chunks/6-d52ff358baed002ec5de.js nextcloud/apps/privacy/js/chunks/6-d52ff358baed002ec5de.js.map nextcloud/apps/privacy/js/chunks/7-67bdb1018507b71d5d1a.js nextcloud/apps/privacy/js/chunks/7-67bdb1018507b71d5d1a.js.map +nextcloud/apps/privacy/js/chunks/7-9ea6a34ed60ea48eec27.js +nextcloud/apps/privac
UPDATE: Nextcloud-22.2.7
Hello, Update for Nextcloud to 22.2.7: https://nextcloud.com/changelog/#latest22 OK? Comments? Cheers.- -- %gonzalo Index: Makefile === RCS file: /cvs/ports/www/nextcloud/22/Makefile,v retrieving revision 1.10 diff -u -p -r1.10 Makefile --- Makefile24 Mar 2022 16:39:18 - 1.10 +++ Makefile4 May 2022 12:59:27 - @@ -1,4 +1,3 @@ -NC_VERSION=22.2.4 -NC_VERSION=22.2.6 +NC_VERSION=22.2.7 .include Index: distinfo === RCS file: /cvs/ports/www/nextcloud/22/distinfo,v retrieving revision 1.7 diff -u -p -r1.7 distinfo --- distinfo24 Mar 2022 16:39:18 - 1.7 +++ distinfo4 May 2022 12:59:27 - @@ -1,2 +1,2 @@ -SHA256 (nextcloud-22.2.6.tar.bz2) = Dx0PDLAAxRsRiGviWorc5HiEbDIzVy/PKLRMXUA24jU= -SIZE (nextcloud-22.2.6.tar.bz2) = 131746258 +SHA256 (nextcloud-22.2.7.tar.bz2) = WtpByz5pZl6KE5RvcZeIKcCgFj0Cd6SeWZyejM+WDqs= +SIZE (nextcloud-22.2.7.tar.bz2) = 131669340 Index: pkg/PLIST === RCS file: /cvs/ports/www/nextcloud/22/pkg/PLIST,v retrieving revision 1.9 diff -u -p -r1.9 PLIST --- pkg/PLIST 24 Mar 2022 16:39:18 - 1.9 +++ pkg/PLIST 4 May 2022 12:59:31 - @@ -8951,6 +8951,8 @@ nextcloud/apps/accessibility/l10n/es_DO. nextcloud/apps/accessibility/l10n/es_DO.json nextcloud/apps/accessibility/l10n/es_EC.js nextcloud/apps/accessibility/l10n/es_EC.json +nextcloud/apps/accessibility/l10n/es_GT.js +nextcloud/apps/accessibility/l10n/es_GT.json nextcloud/apps/accessibility/l10n/es_MX.js nextcloud/apps/accessibility/l10n/es_MX.json nextcloud/apps/accessibility/l10n/et_EE.js @@ -9124,6 +9126,8 @@ nextcloud/apps/activity/l10n/ast.js nextcloud/apps/activity/l10n/ast.json nextcloud/apps/activity/l10n/az.js nextcloud/apps/activity/l10n/az.json +nextcloud/apps/activity/l10n/be.js +nextcloud/apps/activity/l10n/be.json nextcloud/apps/activity/l10n/bg.js nextcloud/apps/activity/l10n/bg.json nextcloud/apps/activity/l10n/bn_BD.js @@ -9502,8 +9506,10 @@ nextcloud/apps/admin_audit/lib/Actions/U nextcloud/apps/admin_audit/lib/Actions/Versions.php nextcloud/apps/admin_audit/lib/AppInfo/ nextcloud/apps/admin_audit/lib/AppInfo/Application.php +nextcloud/apps/admin_audit/lib/AuditLogger.php nextcloud/apps/admin_audit/lib/BackgroundJobs/ nextcloud/apps/admin_audit/lib/BackgroundJobs/Rotate.php +nextcloud/apps/admin_audit/lib/IAuditLogger.php nextcloud/apps/admin_audit/lib/Listener/ nextcloud/apps/admin_audit/lib/Listener/CriticalActionPerformedEventListener.php nextcloud/apps/circles/ @@ -9883,6 +9889,7 @@ nextcloud/apps/circles/lib/Exceptions/Ow nextcloud/apps/circles/lib/Exceptions/ParseMemberLevelException.php nextcloud/apps/circles/lib/Exceptions/PayloadDeliveryException.php nextcloud/apps/circles/lib/Exceptions/RemoteAlreadyExistsException.php +nextcloud/apps/circles/lib/Exceptions/RemoteCircleException.php nextcloud/apps/circles/lib/Exceptions/RemoteInstanceException.php nextcloud/apps/circles/lib/Exceptions/RemoteNotFoundException.php nextcloud/apps/circles/lib/Exceptions/RemoteResourceNotFoundException.php @@ -9896,6 +9903,7 @@ nextcloud/apps/circles/lib/Exceptions/Sh nextcloud/apps/circles/lib/Exceptions/SharingFrameDoesNotExistException.php nextcloud/apps/circles/lib/Exceptions/SharingFrameSourceCannotBeAppCirclesException.php nextcloud/apps/circles/lib/Exceptions/SingleCircleNotFoundException.php +nextcloud/apps/circles/lib/Exceptions/SuperSessionException.php nextcloud/apps/circles/lib/Exceptions/TokenDoesNotExistException.php nextcloud/apps/circles/lib/Exceptions/UnknownFederatedItemException.php nextcloud/apps/circles/lib/Exceptions/UnknownInterfaceException.php @@ -1,6 +10008,7 @@ nextcloud/apps/circles/lib/Migration/Ver nextcloud/apps/circles/lib/Migration/Version0023Date20211216113101.php nextcloud/apps/circles/lib/Migration/Version0024Date20220203123901.php nextcloud/apps/circles/lib/Migration/Version0024Date20220203123902.php +nextcloud/apps/circles/lib/Migration/Version0024Date20220317190331.php nextcloud/apps/circles/lib/Model/ nextcloud/apps/circles/lib/Model/BaseCircle.php nextcloud/apps/circles/lib/Model/BaseMember.php @@ -14997,6 +15006,8 @@ nextcloud/apps/lookup_server_connector/l nextcloud/apps/lookup_server_connector/l10n/es.json nextcloud/apps/lookup_server_connector/l10n/eu.js nextcloud/apps/lookup_server_connector/l10n/eu.json +nextcloud/apps/lookup_server_connector/l10n/fi.js +nextcloud/apps/lookup_server_connector/l10n/fi.json nextcloud/apps/lookup_server_connector/l10n/fr.js nextcloud/apps/lookup_server_connector/l10n/fr.json nextcloud/apps/lookup_server_connector/l10n/gl.js @@ -18155,12 +18166,8 @@ nextcloud/apps/text/l10n/eo.js nextcloud/apps/text/l10n/eo.json nextcloud/apps/text/l10n/es.js nextcloud/apps/text/l10n/es.json -nextcloud/apps/text/l10n/es_AR.js -nextcloud/apps/text/l
Re: [new] www/py-httpretty-1.1.4
On 2022/05/04 12:07, portno12 wrote:
> thanks for the help with the missing port and diff.
>
> adding your diff and the missing port got this further. there were a number
> of tests still failing. i ignored the broken tests as its a known issue
> (https://github.com/gabrielfalcao/HTTPretty/issues/449), i also added
> py-requests as a needed test dep.
>
> a couple warnings (also known in the same issue above) still present but they
> didnt fail any tests.
>
> updated tarball attached for py-httpretty.
Better to not disable tests which are just failing, unless they prevent
other tests from running (as was the case with some of the tests with
missing dep's)
I don't expect tests to always all pass, in most cases it's more about
getting a feel for whether the software in general is going to work ok
on OpenBSD
> --- Original Message ---
> On Tuesday, May 3rd, 2022 at 5:29 PM, Stuart Henderson
> wrote:
>
>
> > On 2022/05/02 23:55, portno12 wrote:
> >
> > > created by portgen and seems fine on amd64, no tests due to needing a lot
> > > of new or updated ports. its a dep for another port i am working on so
> > > will get tested via that soon
> >
> >
> > portgen isn't really good at python ports at the moment.
> >
> > Here are some changes on top and the 1 new port needed to enable most
> > tests.
> >
> > diff --git www/py-httpretty/Makefile www/py-httpretty/Makefile
> > index f29b61f..8d28950 100644
> > --- www/py-httpretty/Makefile
> > +++ www/py-httpretty/Makefile
> > @@ -16,12 +16,22 @@ MODULES = lang/python
> >
> > MODPY_PI = Yes
> > MODPY_SETUPTOOLS = Yes
> > -MODPY_TEST = Yes
> > -MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
> > +MODPY_PYTEST = Yes
> >
> > -# many test deps either need ported or updated
> > -NO_TEST = Yes
> > +# need https, eventlet - not ported
> > +MODPY_PYTEST_ARGS = --ignore tests/bugfixes/nosetests/test_414_httpx.py \
> > + --ignore tests/bugfixes/nosetests/test_eventlet.py \
> > + --ignore tests/functional/test_httplib2.py
> > +
> > +FLAVOR = python3
> > +FLAVORS = python3
> > +
> > +TEST_DEPENDS = devel/py-freezegun${MODPY_FLAVOR} \
> > + devel/py-sure${MODPY_FLAVOR} \
> > + net/py-boto3${MODPY_FLAVOR} \
> > + www/py-httplib2${MODPY_FLAVOR} \
> > + www/py-tornado${MODPY_FLAVOR}
> >
> > -# Lines below not in the template
> > FIX_EXTRACT_PERMISSIONS = Yes
> > +
> > .include
Re: [new] net/gmid -- a gemini server
Stuart Henderson wrote:
> On 2022/05/02 21:25, Omar Polo wrote:
> > here's another try for net/gmid
>
> : @newuser _gmid:878:878:default:Gmid User:/var/empty:/sbin/nologin
>
> just blank rather than "default", i.e.
>
> @newuser _gmid:878:878::Gmid User:/var/empty:/sbin/nologin
>
> : daemon="${LOCALBASE}/bin/gmid"
> : daemon_flags="-c /etc/gmid.conf"
>
> if it's using variables then it should be ${TRUEPREFIX}, ${SYSCONFDIR}
> for these two
>
> (if it's not using variables then probably better not to have some lines
> using vars and some not)
woops, sorry. this was written before i got the difference between
TRUEPREFIX and LOCALBASE, and I haven't spotted it when revieving the
port before sending it.
gmid.tar.gz
Description: GNU Zip compressed data
Re: [update) math/arpack to arpack-ng 3.8.0
Am 02.05.2022 um 20:40 schrieb Volker Schlecht: Bump. Anyone to import arpack-ng? I will try to pursue this further, but time is scarce. We need to get someone else to OK for import apart from Stuart. Volker, if you can you check the SUBPACKAGES work and everything is in place including DESCR plus maybe some extra tests on other platforms? This would help.
Re: [new] x11/papirus-icon-theme
David Demelier wrote:
> Hi,
>
> This is a new port for a rich and modern papirus icon theme. It's my
> first submission, *any* comment is welcome.
>
> https://github.com/PapirusDevelopmentTeam/papirus-icon-theme
I'd avoid rolling a custom do-install if possible: it can get
out-of-sync with updates and it's difficult to notice. gmake would be a
build-only dependency anyway, not something the users needs to have
installed in order to use this package.
Here's a diff on top of your makefile. (I'm setting PREFIX to
TRUEPREFIX instead of setting an empty DESTDIR because the port'
makefile generates the icons cache if DESTDIR is empty.) With the tabs
vs. spaces thing mentioned by landry@ fixed I'm ok too :)
--- /tmp/papirus-icon-theme/MakefileWed May 4 08:34:12 2022
+++ MakefileWed May 4 09:22:52 2022
@@ -15,11 +15,8 @@
NO_BUILD= yes
RUN_DEPENDS=x11/gtk+3,-guic
-# avoid GNU make dependency
-do-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/share/icons
-.for t in Papirus Papirus-Dark Papirus-Light ePapirus ePapirus-Dark
- cp -R ${WRKBUILD}/${t} ${PREFIX}/share/icons/${t}
-.endfor
+USE_GMAKE= Yes
+
+FAKE_FLAGS=PREFIX="${TRUEPREFIX}"
.include
Re: 7.1 ports.tar.gz slightly corrupted?
The simplest solution would be to add write support for extended headers in bin/tar It was done for reading, which is a way more complicated endeavor, so it's probably just a question of spending a bit of time (and probably putting it outside of #define SMALL) (I've written the read/write support for OpenBSD::UStar, so it's not incredibly complicated. Roughly 50 lines of perl, probably 200 in C. The most annoying part will be figuring out where to put it inside tar(1) )
Re: [new] x11/papirus-icon-theme
Le Wed, May 04, 2022 at 08:46:30AM +0200, David Demelier a écrit : > Hi, > > This is a new port for a rich and modern papirus icon theme. It's my > first submission, *any* comment is welcome. > > https://github.com/PapirusDevelopmentTeam/papirus-icon-theme for a first submission it looks nice ! i was a bit concerned by the licence marker as paper (which is used as a base/inspiration) is cc-sa-4.0 but it's been cleared by paper's author in https://github.com/PapirusDevelopmentTeam/papirus-icon-theme/issues/1049#issuecomment-356630452 also, we use tabs after = in Makefile - other than that, ok with me to import. Landry
Re: 7.1 ports.tar.gz slightly corrupted?
On 2022/05/04 08:58, Thomas Dettbarn wrote: > Hello. > > Chipping in my 2 cents here: I would suggest stricter rules for > the ports rather than a hacking the tools. > > > We are talking about the OpenBSD ports, right? > So if it is the ports, the name of the file should not > matter that much, as long as the build process can find it. To be clear, the problem is in pathnames of some patch files, which are generated by "make update-patches" and stored in the ports tree, and the problem only occurs when a tar of the ports tree is produced with /bin/tar, something which is done for releases by someone who isn't working on ports, and the produced file is typically not used by ports developers (we work on -current not a frozen snapshot of old source, so we update from the repository often). It doesn't affect anything in packages, which are produced by Perl ustar which does use extended headers for long path names. > In other words: > Since the build process has control over the filenames, it > is also possible to change them, and apply a patch to the > Makefile (or whichever), so that it can find it. > > So, in my opinion, a too long filename in a port can be seen > as breaking said port, something which can be checked before > the tar is being generated. And in that case, an alert > could be send out the maintainers. (That is what perl is for...) > > The maintainer could then shorten the filename, patch, and reupload. It's not that big a problem in ports. Only a couple of ports are likely to have pathnames this long and people fetching this tar are unlikely to build them. Adding a hack to the ports tools to avoid tickling a deficiency in a base OS tool doesn't seem the right way. To be honest the bigger problem is if people use tar for their own backups unaware of the restriction (which after all is not a problem with the standard tar on most other OS they might be using). Someone might be using tar themselves to backup a ports tree in a different location (say, home/user/ports/XX rather than ports/XX) and they'll hit the problem with a shorter patch filename so some auto check win't pick that up. More importantly they might be backing up a personal file rather than some patchfile in a widely mirrored repo and make the mistake of failing to review stderr messages.
Re: Is there a way to display the block of another man page inside a man page
The point is that anyone reading the manual can look up a reference on the fly. No need for full text inclusion or fancy schemes. tilo
Re: 7.1 ports.tar.gz slightly corrupted?
Hello. Chipping in my 2 cents here: I would suggest stricter rules for the ports rather than a hacking the tools. We are talking about the OpenBSD ports, right? So if it is the ports, the name of the file should not matter that much, as long as the build process can find it. In other words: Since the build process has control over the filenames, it is also possible to change them, and apply a patch to the Makefile (or whichever), so that it can find it. So, in my opinion, a too long filename in a port can be seen as breaking said port, something which can be checked before the tar is being generated. And in that case, an alert could be send out the maintainers. (That is what perl is for...) The maintainer could then shorten the filename, patch, and reupload. That would be an intermediate (and safer) solution, until somebody starts working on tar 2.0. Thomas > Stuart Henderson hat am 03.05.2022 16:45 geschrieben: > > > On 2022/05/03 15:13, Solène Rapenne wrote: > > Le Tue, 3 May 2022 14:10:19 +0100, > > Stuart Henderson a écrit : > > > > > On 2022/05/02 20:35, Jonathan Thornburg wrote: > > > > The 7.1 ports.tar.gz (I tried downloading from both > > > > https://ftp.openbsd.org/pub/OpenBSD/ > > > > https://openbsd.cs.toronto.edu/pub/OpenBSD/ > > > > and verified that they gave identical files; checksums are below) > > > > appears to have a slightly corrupted 'graphics/libraw' port: > > > > > > > > % /bin/tar xzf /tmp/ports.tar.gz > > > > % cd ports > > > > % ls -d g* > > > > games/geo/ gnome/graphics/ grapics/ > > > > > > > > I was curious about the directory name 'grapics' (which looks like a > > > > 1-letter typo from 'graphics'), so I looked around. 'grapics' contains > > > > only a single port, libraw, and that port is missing various files: > > > > > > These directories are present in the cvs tree due to broken imports in the > > > past (there are a bunch of others). This one was from 2010. I think that > > > when the tar was created it was done from a checkout without -d. > > > > > > It also misses some files with names which are too long for the default > > > tar format. > > > > > > I recommend ignoring this file and doing a checkout from anoncvs. > > > > > > > Should we continue to distribute that file is it's broken due to tar > > limitations? > > Another option would be to distribute a file that works ok with OpenBSD > (and FreeBSD, but not GNU) tar: > > cd /usr/ports > cvs up -Pd -r OPENBSD_X_Y_BASE > cd .. > pax -x cpio -w ports | gzip -9 > ports.tar.gz > > A better option would be to add support for writing extended headers > in tar(1), it already handles reading them (so, if the tree was archived > with bsdtar/gtar which do this it would include all the files and tar(1) > could unpack them OK, but using a non-OpenBSD archiver to produce a > file distributed by OpenBSD would be quite distasteful). > > anoncvs is usually not all that slow though.
