On 2020/01/28 08:51, Landry Breuil wrote:
> On Mon, Jan 27, 2020 at 09:33:58AM +0100, Landry Breuil wrote:
> > On Sun, Jan 26, 2020 at 09:42:38PM -0500, Brian Callahan wrote:
> > > Hi ports --
> > >
> > > qgis will pick up ccache if you have it installed, and the build fails (at
> > > least, it do
On Tue, Jan 28 2020, Rafael Sadowski wrote:
> Facts: Qt4 OAuth support library with no consumers, last update 2013.
> Need I say more? OK to nuke it?
ok
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
On 2020/01/28 07:03, Rafael Sadowski wrote:
> Yet another switch from qt4 to qt5. Update qgit to the latest stable
> version from github.
>
> "QGit's project management has now moved to GitHub." --
> http://libre.tibirna.org/
>
> Tested on amd64 with some git repos.
>
> OK?
>
> Index: Makefile
On Tue, Jan 28 2020, Stuart Henderson wrote:
> On 2020/01/28 07:03, Rafael Sadowski wrote:
>> Yet another switch from qt4 to qt5. Update qgit to the latest stable
>> version from github.
>>
>> "QGit's project management has now moved to GitHub." --
>> http://libre.tibirna.org/
>>
>> Tested on am
Bulk build on sparc64-0.ports.openbsd.org
Started : Sun Jan 26 16:35:54 MST 2020
Finished: Tue Jan 28 03:44:27 MST 2020
Duration: 1 Days 11 hours 9 minutes
Built using OpenBSD 6.6-current (GENERIC.MP) #197: Sun Jan 26 06:53:42 MST 2020
Built 9110 packages
Number of packages built each day:
Jan
On Tue, Jan 28, 2020 at 09:49:26AM +, Stuart Henderson wrote:
> On 2020/01/28 08:51, Landry Breuil wrote:
> > On Mon, Jan 27, 2020 at 09:33:58AM +0100, Landry Breuil wrote:
> > > On Sun, Jan 26, 2020 at 09:42:38PM -0500, Brian Callahan wrote:
> > > > Hi ports --
> > > >
> > > > qgis will pick
On Tue, Jan 28, 2020 at 06:23:46AM +, Mikolaj Kucharski wrote:
> Hi,
>
> At the end of this mail, Joerg's diff with plist regenerated.
Forgot to add, with my below diff I tested kcaldav on:
OpenBSD 6.6-current (GENERIC.MP) #622: Mon Jan 27 00:12:59 MST 2020
dera...@amd64.openbsd.org:/usr
Hi Tracey,
On Mon, 27 Jan 2020, Tracey Emery wrote:
> Hello ports,
>
> Attached is a python tool for burning firmware to esp8266 and esp32
> chips. It is a heavily edited version of a port I previously submitted.
>
> devel/py-esptool: A Python-based, open source, platform independent, utility
>
On Tue, Jan 28, 2020 at 07:42:04AM +0100, Martin Reindl wrote:
> On Mon, Jan 27, 2020 at 04:06:03PM -0700, Tracey Emery wrote:
> > Hello ports,
> >
> > Attached is a new port to work with firmware for ESP8266 chips. It's an
> > updated and slightly revised version of a previous submission.
> >
>
On Tue, Jan 28, 2020 at 07:44:49AM +0100, Martin Reindl wrote:
> On Mon, Jan 27, 2020 at 04:06:03PM -0700, Tracey Emery wrote:
> > Hello ports,
> >
> > Attached is a new port to work with firmware for ESP8266 chips. It's an
> > updated and slightly revised version of a previous submission.
> >
>
This isn't a py-port. I did submit a py-esptool port, which is separate
from this. Paco has edited it for py3, which I will check out in a bit.
Thanks.
On Tue, Jan 28, 2020 at 07:50:14AM +0100, Rafael Sadowski wrote:
> On Mon Jan 27, 2020 at 04:06:03PM -0700, Tracey Emery wrote:
> > Hello ports,
>
On Tue, Jan 28, 2020 at 02:51:28PM +0100, Paco Esteban wrote:
> Find attached a modified version of your port. It did not build for me
> as you sent it, as they were some missing dependencies. I also made it
> py3 only.
This looks great.
>
> I'm working on the tests part now. This is a bit of
On 2020-01-22, Christian Weisgerber wrote:
> These failed to build:
multimedia/gstreamer-0.10/plugins-base fixed
devel/libfirmfixed
emulators/mame commit pending
devel/jdk/11 tentative upstream fix available
> T
On Tue, Jan 28, 2020 at 06:30:37AM +0100, Rafael Sadowski wrote:
> Facts: Qt4 synergy application, last update 2010, upstream dead.
>
> Synergy looks also more or less dead as open-source:
> https://en.wikipedia.org/wiki/Synergy_(software)
> https://synergy-foss.org/
>
> BTW, Qt4 ports in the cat
On Tue, 28 Jan 2020, Solene Rapenne wrote:
> ok for removing net/qsynergy but net/synergy is still useful, I
> installed it last week for openbsd->windows and it works fine. I've
> tried qsynergy and it wasn't helpful at all.
The version of net/synergy is quite outdated, and the newer versions of
On Tue, Jan 28, 2020 at 07:33:41AM -0700, Tracey Emery wrote:
> On Tue, Jan 28, 2020 at 07:42:04AM +0100, Martin Reindl wrote:
> > On Mon, Jan 27, 2020 at 04:06:03PM -0700, Tracey Emery wrote:
> > > Hello ports,
> > >
> > > Attached is a new port to work with firmware for ESP8266 chips. It's an
>
1.8.26: Ludovic Rousseau
3 January 2020
- Use poll() instead of select() to allow file descriptor higher than FD_SETSIZE
- Enable reader filtering by default
- pcsc-spy:
. Do not read output buffer after error
. Adjust code to handle autoallocated buffers
. fix year-2038 issue by using long
Dear prots@,
There is a new CVE for libxml2:
https://nvd.nist.gov/vuln/detail/CVE-2020-7595
The diff is available here:
https://gitlab.gnome.org/GNOME/libxml2/commit/0e1a49c89076
make test passes without errors.
The diff is attached. There is a CVE list supposed to be in devel/quirks
but I don'
On Tue, Jan 28, 2020 at 08:18:07PM +0100, Moritz Buhl wrote:
> Dear prots@,
>
> There is a new CVE for libxml2:
> https://nvd.nist.gov/vuln/detail/CVE-2020-7595
Well, it doesn't look that harsh, it's just an infinite loop...
These days, everything ends up being a CVE, it seems.
> The diff is ava
Lots of new support, improvements but also CVE fixes, see
https://github.com/OpenSC/OpenSC/wiki#news
The shared libraries gained exported symbols but did not lose any, so
I'm bumping their minors.
Keeps working for me on amd64
OK?
Index: Makefile
On Tue, 28 Jan 2020 at 16:50:11 +0100, Solene Rapenne wrote:
> On Tue, Jan 28, 2020 at 06:30:37AM +0100, Rafael Sadowski wrote:
> > Facts: Qt4 synergy application, last update 2010, upstream dead.
> >
> > Synergy looks also more or less dead as open-source:
> > https://en.wikipedia.org/wiki/Synerg
Hi,
I've found out that the newest devel/libiscsi can't be built in the current
powerpc bulk due to `-Werror':
> cc1: warnings being treated as errors
> [...]
> At top level:
> cc1: error: unrecognized command line option "-Wno-stringop-truncation"
> Error while executing cc -DHAVE_CONFIG_H -I.
On 2020/01/27 18:53, Nam Nguyen wrote:
> ping. Can someone run bulk builds using this devel/boost diff?
Here it is with some tweaks:
- add dep on py3-numpy as well as py-numpy
- set MODPY_VERSION to use py3 by default to provide py3-flavoured
MODPY variables and use them in some places (INCDIR in
On Tue Jan 28, 2020 at 12:53:32PM -0700, Aaron Bieber wrote:
> On Tue, 28 Jan 2020 at 16:50:11 +0100, Solene Rapenne wrote:
> > On Tue, Jan 28, 2020 at 06:30:37AM +0100, Rafael Sadowski wrote:
> > > Facts: Qt4 synergy application, last update 2010, upstream dead.
> > >
> > > Synergy looks also mor
Here's a Reddit client for your terminal. From time to time it's nice
to browse your favourite subreddit in a terminal^Wenvironment of your
choice instead of a webbrowser.
This port requires the recent devel/py-kitchen submission to work,
otherwise it just works for me.
tuir is surprisingly vers
On 2020/01/28 22:34, Klemens Nanni wrote:
> Here's a Reddit client for your terminal. From time to time it's nice
> to browse your favourite subreddit in a terminal^Wenvironment of your
> choice instead of a webbrowser.
>
> This port requires the recent devel/py-kitchen submission to work,
> othe
On 2020/01/28 21:03, Stuart Henderson wrote:
> On 2020/01/27 18:53, Nam Nguyen wrote:
> > ping. Can someone run bulk builds using this devel/boost diff?
>
> Here it is with some tweaks:
> - add dep on py3-numpy as well as py-numpy
> - set MODPY_VERSION to use py3 by default to provide py3-flavoure
Thanks to sthen@ i've found out that i'm dead wrong, here is some
better output from clang on i386:
> login.c:1245:52: error: comparison of integers of different signs:
> 'long' and 'uint32_t' (aka 'unsigned int') [-Werror,-Wsign-compare]
Upstream fixed the issue [0] already. That allows libisc
On Wed, 29 Jan 2020 00:09:33 +0100
Charlene Wendling wrote:
>
> Thanks to sthen@ i've found out that i'm dead wrong, here is some
> better output from clang on i386:
>
> > login.c:1245:52: error: comparison of integers of different signs:
> > 'long' and 'uint32_t' (aka 'unsigned int') [-Werror,-
On 2020/01/28 22:42, Stuart Henderson wrote:
> On 2020/01/28 21:03, Stuart Henderson wrote:
> > On 2020/01/27 18:53, Nam Nguyen wrote:
> > > ping. Can someone run bulk builds using this devel/boost diff?
> >
> > Here it is with some tweaks:
> > - add dep on py3-numpy as well as py-numpy
> > - set
Hi,
> http://build-failures.rhaalovely.net/sparc64/2020-01-26/security/ophcrack.log
(and in the current powerpc bulk)
In ${WRKSRC}/src/samdump2/samdump2.c:44, a bundled bswap.h is #include'd
when built on big endian archs, pulling itself the generated
${WRKSRC}/config.h, and that one is not in th
On 1/28/2020 6:42 PM, Charlene Wendling wrote:
On Wed, 29 Jan 2020 00:09:33 +0100
Charlene Wendling wrote:
Thanks to sthen@ i've found out that i'm dead wrong, here is some
better output from clang on i386:
login.c:1245:52: error: comparison of integers of different signs:
'long' and 'uint32
Hello ports!
In OpenBSD macppc, clang and gcc use incompatible ABIs to return small
structs: gcc defaults to -msvr4-struct-return, but clang always acts
like gcc -maix-struct-return. This causes crashes at runtime: for
example, clang code can't call libxcb (in Xenocara built by gcc).
This diff f
On Wed, Jan 29, 2020 at 02:38:59AM +0100, Charlene Wendling wrote:
> Hi,
>
> > http://build-failures.rhaalovely.net/sparc64/2020-01-26/security/ophcrack.log
> (and in the current powerpc bulk)
>
> In ${WRKSRC}/src/samdump2/samdump2.c:44, a bundled bswap.h is #include'd
> when built on big endian
On Wed, Jan 29, 2020 at 12:39:20AM +, Stuart Henderson wrote:
> On 2020/01/28 22:42, Stuart Henderson wrote:
> > On 2020/01/28 21:03, Stuart Henderson wrote:
> > > On 2020/01/27 18:53, Nam Nguyen wrote:
> > > > ping. Can someone run bulk builds using this devel/boost diff?
> > >
> > > Here it
The project and the vulknut DC looks quit dead upstream. Last release
2009. From the homepage: "Unfortunately it has no support for the new
ADC protocol from the DC++ team". Thus it does not support a "newer"
DC protocols.
Time to go to Attic?
I would like get rid of productivity/qhacc. It's a terrible accounting
tool (independently of Qt3). We have much more feature-rich, stable,
easy to use accounting tools for web,qt,gtk,cli in the tree.
OK to remove?
Rafael
Hi ports@,
Upstream has decide to go its own way[1]. Which is fine for me but we
should get rid our devel/bouml port, or does it make sense to support
it? I'm not a bouml user but our version is from 2010.
Opinions? Oks to remove?
Rafael
[1] https://marc.info/?l=openbsd-ports&m=157934986528326&
On 29/01/2020 04:55, Kurt Mosiejczuk wrote:
On Wed, Jan 29, 2020 at 02:38:59AM +0100, Charlene Wendling wrote:
Hi,
http://build-failures.rhaalovely.net/sparc64/2020-01-26/security/ophcrack.log
(and in the current powerpc bulk)
In ${WRKSRC}/src/samdump2/samdump2.c:44, a bundled bswap.h is
39 matches
Mail list logo