Haven't had time to investigate, but it seems libxul might have
issues.
Errors show up in all 3 ports (www/firefox-esr, www/mozilla-firefox
and mail/thunderbird)
Looks like:
> Extracting debug info from lib/thunderbird/libxul.so.34.0
dwz: lib/thunderbird/.debug/libxul.so.34.0.dbg: Couldn't find D
On Mon, Mar 23, 2020 at 11:21:40AM -0400, Brian Callahan wrote:
>
>
> On 2020-03-23 11:11 AM, Marc Espie wrote:
> > On Mon, Mar 23, 2020 at 11:08:16AM -0400, Brian Callahan wrote:
> > >
> > > On 2020-03-23 10:54 AM, Marc Espie wrote:
> > > > On
On Mon, Mar 23, 2020 at 11:08:16AM -0400, Brian Callahan wrote:
>
>
> On 2020-03-23 10:54 AM, Marc Espie wrote:
> > On Fri, Mar 20, 2020 at 03:22:16PM -0400, Brian Callahan wrote:
> > > Hello ports --
> > >
> > > It was hinted at recently that a port of
On Fri, Mar 20, 2020 at 03:22:16PM -0400, Brian Callahan wrote:
> Hello ports --
>
> It was hinted at recently that a port of dwz might be desirable. Here is
> one.
>
> ---
> pkg/DESCR:
> dwz is a program that attempts to optimize DWARF debugging information
> contained in ELF shared libraries an
892
> diff -u -p -r1.892 Makefile
> --- Makefile 20 Mar 2020 14:46:47 - 1.892
> +++ Makefile 22 Mar 2020 17:03:13 -
> @@ -5,7 +5,7 @@ CATEGORIES = devel databases
> DISTFILES =
>
> # API.rev
> -PKGNAME =quirks-3.283
> +PKGNAME =quirks-3.284
On Sun, Mar 22, 2020 at 01:59:36PM +0100, Marc Espie wrote:
> On Sun, Mar 22, 2020 at 08:20:59AM +, Martin wrote:
> > It looks strange, but
> >
> > make show=PKGNAME
> > uhd-3.15.0.0
> > make show=FULLPKGNAME-
> > uhd-3.15.0.0p0
> > make show=FULLP
On Sun, Mar 22, 2020 at 08:20:59AM +, Martin wrote:
> It looks strange, but
>
> make show=PKGNAME
> uhd-3.15.0.0
> make show=FULLPKGNAME-
> uhd-3.15.0.0p0
> make show=FULLPKGNAME
> uhd-3.15.0.0p0
>
> I attached the new port I do which builds successfully, but make package is
> broken.
No it
On Fri, Mar 20, 2020 at 05:16:12PM +, Stuart Henderson wrote:
> On 2020/03/20 17:41, Jeremie Courreges-Anglas wrote:
> > >> only rc[N], beta[N], pre[N], and pl[N]. Would it makes sense to add a
> > >> alpha[N]? We could of course also use EPOCH here.
> > >
> > > adding support for alpha[N] woul
On Thu, Mar 19, 2020 at 10:38:30PM +0100, Christian Weisgerber wrote:
> Make use of "find -exec {} +" (which is POSIX) and "find -delete"
> (which is not) throughout the ports Makefiles.
>
> Specifically:
>
> * Replace find|xargs with find -exec {} +
> find|xargs is an outdated construct. The
On Mon, Mar 16, 2020 at 08:26:35AM +, Stuart Henderson wrote:
> On 2020/03/16 00:45, Marc Espie wrote:
> > On Sun, Mar 15, 2020 at 08:08:34PM -0300, Elias M. Mariani wrote:
> > > Sure.
> > > + Added https://ftp.lip6.fr/pub/lyx/stable/2.3.x/ to the top of
> >
On Mon, Mar 16, 2020 at 01:25:42AM +0100, Jeremie Courreges-Anglas wrote:
> On Mon, Mar 16 2020, Marc Espie wrote:
> > On Sun, Mar 15, 2020 at 08:08:34PM -0300, Elias M. Mariani wrote:
> >> Sure.
> >> + Added https://ftp.lip6.fr/pub/lyx/stable/2.3.x/ to the top of
>
On Sun, Mar 15, 2020 at 08:08:34PM -0300, Elias M. Mariani wrote:
> Sure.
> + Added https://ftp.lip6.fr/pub/lyx/stable/2.3.x/ to the top of
> MASTER_SITES. (I guess that we want HTTPS first?).
We don't really care about https, but the lip6 server is fairly reliable.
On Sun, Mar 15, 2020 at 12:28:25PM +0100, Paco Esteban wrote:
> oh, that did not occur to me ... You mean that if port foo/bar gets
> EPOCH = 0, then all dependent ports should change it's dependencies
> declarations from foo/bar>=1.1 to foo/bar>=1.1v0 ??
Yes, that's the main reason that led to i
Update for those not in the know:
I think I figured out a limited way to tell dpb
"hey, use a different lock name for that port/flavor
combination please".
To be used *very* sparingly, especially for
multi-packages, because dpb will get 100% confused
if it sees the same fullpkgname attached to two
On Thu, Mar 05, 2020 at 10:59:59PM +, Stuart Henderson wrote:
> On 2020/03/05 23:06, Marc Espie wrote:
> > > Can we do this?
> > >
> > > Index: bsd.port.mk
> > > ===
> > > RCS
On Thu, Mar 05, 2020 at 09:43:24PM +, Stuart Henderson wrote:
> We only use SEPARATE_BUILD=(Yes|No) these days, so this conditional
> isn't needed. But also, it seems like it was the wrong way round anyway?
> I think the idea of =flavored was to allow doing several builds from the
> same unpack
On Thu, Feb 27, 2020 at 12:37:46PM +0100, Jeremie Courreges-Anglas wrote:
> On Thu, Feb 27 2020, Martin Reindl wrote:
> > On Wed, Feb 26, 2020 at 11:17:05AM +0100, Jeremie Courreges-Anglas wrote:
> >> On Sun, Feb 23 2020, Martin Reindl wrote:
> >> > Am 21.02.20 um 15:27 schrieb Bjorn Ketelaars:
>
The few runs of make should just grab the whole file and return an array of
lines, that way I can do proper error handling.
This also fixes the SUBDIR problem.
Create the object in new early so I can do OO as expected...
Index: portbump
===
On Fri, Feb 21, 2020 at 09:34:59PM +0100, Christian Weisgerber wrote:
> Marc Espie:
>
> > --- bin/portbump27 Jun 2018 16:20:08 - 1.22
> > +++ bin/portbump19 Feb 2020 15:52:58 -
> > @@ -98,6 +98,18 @@ my @_REV_NEIGHBORS_WEAK = qw(
> > );
>
Okay, I did something reasonably clean. Adding a second "special comment"
@comment no debug
and turning
@shell into binaries (by default) was fairly straightforward.
As long as we don't gain 20 extra special comments, we should be fine.
On Thu, Feb 20, 2020 at 04:03:29PM +, Stuart Henderson wrote:
> On 2020/02/20 16:27, Marc Espie wrote:
> > Now that we have a settled down workflow, I think this should work just
> > fine, and avoid regenerating that Makefile 30 times in php...
> >
> > Specifically,
Now that we have a settled down workflow, I think this should work just
fine, and avoid regenerating that Makefile 30 times in php...
Specifically, that stuff only depends on static port information, it can't
be generated before fake because it lives in WRKINST, and it only needs
to be re-gen'd ea
All you're saying makes sense to me.
SUBDIR and SUBDIRLIST work like FLAVOR/SUBPACKAGE, they should be passed
through the environment and NOT as variable you can't override on the command
line (see the various unset in bsd.port.subdir.mk and pkgpath.mk)
There might other consumers in the tree. Fix will be the same...
Index: bin/po
On Tue, Feb 18, 2020 at 08:37:07PM +, Stuart Henderson wrote:
> This might help prevent some duff imports.. ok?
>
> Index: portimport
> ===
> RCS file: /cvs/ports/infrastructure/bin/portimport,v
> retrieving revision 1.8
> diff -u
On Thu, Feb 13, 2020 at 11:39:51PM +0100, Christian Weisgerber wrote:
> I tried to add a debug package for shells/bash, but the result would
> only contain debug data for some loadable modules and skip the actual
> bash binary.
>
> Oh, of course. It is marked @shell and not @bin in the PLIST.
>
On Thu, Feb 13, 2020 at 10:35:18PM +, Stuart Henderson wrote:
> On 2020/02/13 17:22, Kurt Mosiejczuk wrote:
> > With the default of 10 seconds with no response, my DPB status screen
> > stays almost entirely red for the duration of the sparc64 bulk.
> >
> > Increasing it to 45 seconds tends to
On Sat, Feb 01, 2020 at 10:53:41PM -0800, Andrew Hewus Fresh wrote:
> On Sat, Feb 01, 2020 at 07:10:40PM -0800, Andrew Hewus Fresh wrote:
> > After the most recent simplification of portgen's port finding code, I
> > think we can stop using sqlports and instead look to see if any
> > $PORTSDIR/*/$P
On Fri, Jan 31, 2020 at 06:27:46AM +0100, Rafael Sadowski wrote:
> The diff contains some forgotten CVE entries in quirks. I went through
> all the January commits and looked for CVE in the commit msg.
>
> I also ran sort over the list.
>
> OK, opinions?
> + 'net/rsync' => 'rsync-<3.1.3p0',
On Fri, Jan 31, 2020 at 06:52:49AM +0100, Rafael Sadowski wrote:
> On Thu Jan 30, 2020 at 01:19:18PM +0100, Marc Espie wrote:
> > On Thu, Jan 30, 2020 at 08:23:22AM +0100, Klemens Nanni wrote:
> > > On Wed, Jan 29, 2020 at 06:44:53AM +0100, Rafael Sadowski wrote:
> > >
On Thu, Jan 30, 2020 at 08:23:22AM +0100, Klemens Nanni wrote:
> On Wed, Jan 29, 2020 at 06:44:53AM +0100, Rafael Sadowski wrote:
> > 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 accou
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
On Mon, Jan 27, 2020 at 03:56:07PM +0100, Moritz Buhl wrote:
> Hi ports@,
>
> The gnu licensed rsync port in it's current release is shipping with a
> few CVEs: CVE-2016-9843, CVE-2016-9842, CVE-2016-9841, CVE-2016-9840
> They all come from the zlib rsync is bundling. The OpenBSD port uses
> this
On Fri, Jan 24, 2020 at 03:25:42PM +0100, Ingo Schwarze wrote:
> Hi,
>
> Claus Assmann wrote on Fri, Jan 24, 2020 at 09:25:27AM +0100:
> > On Thu, Jan 23, 2020, Landry Breuil wrote:
>
> >> have a look at the pkg-readme provided by the package.
>
> > I didn't find a hint about pkg-readmes in the
On Tue, Jan 21, 2020 at 10:10:52AM -0500, Kurt Mosiejczuk wrote:
> On Tue, Jan 21, 2020 at 04:02:34PM +0100, Marc Espie wrote:
>
> > > This happens to me fairly frequently, whether it is on that sparc64 box or
> > > my amd64 laptop. Yes, I use FETCH_PACKAGES. No, m
On Mon, Jan 20, 2020 at 09:51:14PM -0500, Kurt Mosiejczuk wrote:
> I think this following case is when there is a package cached (or created)
> in the ports tree, but one of its dependencies is not there.
>
> devlin$ make
> ===> py-h5py-2.10.0 depends on: py-numpy-* - not found
> ===>
On Tue, Jan 21, 2020 at 11:57:23AM +, cho...@jtan.com wrote:
> Antoine Jacoutot writes:
> > On Mon, Jan 20, 2020 at 11:31:11PM +0100, Christian Weisgerber wrote:
> > > What's the policy for adding debug packages to ports?
> > >
> > > Is the intend to add debug packages...
> > > * eventually to
On Mon, Jan 20, 2020 at 09:58:41AM -0500, Brian Callahan wrote:
> Hi ports --
>
> Attached is an update to gmake.
> A changelog can be found here:
> http://git.savannah.gnu.org/cgit/make.git/tree/NEWS
>
> There is a lot of churn because upstream reworked their directory structure.
>
> All tests
On Fri, Jan 17, 2020 at 09:50:26AM +0100, Matthieu Herrb wrote:
> This looks like the correct fix to me.
> I think only C++ cares about this kind of function signature changes.
Well, that's one instance where C++ is right to care !
Functions that don't return are pretty special.
(it's not even a
On Fri, Jan 17, 2020 at 07:45:09AM +0100, Antoine Jacoutot wrote:
> On Thu, Jan 16, 2020 at 11:24:50PM +0100, Antoine Jacoutot wrote:
> > On Thu, Jan 16, 2020 at 05:26:50PM +0100, Marc Espie wrote:
> > > This font was designed for development, apparently, as part of an IDE,
>
On Thu, Jan 16, 2020 at 09:35:04PM +0100, Christian Weisgerber wrote:
> (ddd is cruft, the latest release dates from 2009, so this isn't
> really important.)
What would you recommend as a "simple" gui frontend to (e)gdb then ?...
This font was designed for development, apparently, as part of an IDE,
and they decided to open up the font (Apache 2.0)
I played with it a bit and it is indeed pleasant.
Fairly straightforward.
jetbrains.tgz
Description: application/tar-gz
On Tue, Jan 14, 2020 at 03:10:11PM +, Stuart Henderson wrote:
> On 2020/01/13 21:34, Mark Hesselink wrote:
> > Dear list,
> >
> > Please find attached a sndio(7) sound driver for Squeak VM 3.10.1
> > (lang/squeak/vm). This driver has been fairly extensively tested by my
> > family over the cou
On Sat, Jan 11, 2020 at 01:08:50PM +0100, Charlene Wendling wrote:
> On Sat, 11 Jan 2020 12:36:00 +0100
> Marc Espie wrote:
>
> > On Sat, Jan 11, 2020 at 08:50:33AM +0100, Rafael Sadowski wrote:
> > > Is there any way to phrase this so that we don't have fix v
On Sat, Jan 11, 2020 at 08:50:33AM +0100, Rafael Sadowski wrote:
> Is there any way to phrase this so that we don't have fix version? This
> would save recurring updates.
Hum... the situation with compilers is confusing enough that having some
kind of handle as to which version is which is actuall
On Sun, Jan 05, 2020 at 06:36:47PM +0100, Marc Espie wrote:
> On Sun, Jan 05, 2020 at 04:57:59PM +0100, Solene Rapenne wrote:
> > I have an error when building stable packages on sparc64 when it comes
> > to www/chromium
> >
> > ===> Checking files for chromium-79
On Sun, Jan 05, 2020 at 04:57:59PM +0100, Solene Rapenne wrote:
> I have an error when building stable packages on sparc64 when it comes
> to www/chromium
>
> ===> Checking files for chromium-79.0.3945.88
> `/mnt/distfiles/chromium-79.0.3945.88.tar.xz' is up to date.
> `/mnt/distfiles/chromium-76
On Sat, Jan 04, 2020 at 12:53:23PM +0900, Bryan Linton wrote:
> Hello ports@
>
> After upgrading to Firefox 71, I was no longer able to input
> Japanese due to the newly-added unveil and pledge support. After
> some debugging, I found that adding the following lines to
> /etc/firefox/unveil.main
On Wed, Jan 01, 2020 at 04:29:26PM +, Edd Barrett wrote:
> On Wed, Jan 01, 2020 at 02:48:52PM +, Stuart Henderson wrote:
> > Either list it as an "extra" WANTLIB (with a comment explaining that this
> > has been done so it doesn't get removed in future) or convert to
> > BUILD+RUN_DEPENDS (
On Mon, Dec 30, 2019 at 01:11:51PM -0800, Xiyue Deng wrote:
> (Adding m...@openbsd.org back to CC.)
>
> Marc Espie writes:
>
> > Just have your ports tree checked out under your mount point.
> > Next time it will be much faster ;)
>
> Unfortunately my loongson box
Just have your ports tree checked out under your mount point.
Next time it will be much faster ;)
We're still shackled to our slow ffs. Copying files does take time.
On Sun, Dec 29, 2019 at 05:46:04AM -0800, Xiyue Deng wrote:
> Xiyue Deng writes:
>
> > Marc Espie writes:
> >
> >> On Sun, Dec 29, 2019 at 02:21:21AM -0800, Xiyue Deng wrote:
> >>> Sure thing. It's not very interesting and looks like below:
> &
On Sun, Dec 29, 2019 at 02:21:21AM -0800, Xiyue Deng wrote:
> (Adding mailing list back to CC which I accidentally dropped in my last mail.)
>
> Marc Espie writes:
>
> > On Sat, Dec 28, 2019 at 03:02:59PM -0800, Xiyue Deng wrote:
> >> > No it doesn'
On Tue, Dec 24, 2019 at 02:11:53PM +, Stuart Henderson wrote:
> > > > g-ir-scanner: link: cc -pthread -o
> > > > /usr/obj/ports/libgweather-3.34.0/build-powerpc/tmp-introspecty_ix5pqn/GWeather-3.0
> > > > -O2 -pipe
> > > > /usr/obj/ports/libgweather-3.34.0/build-powerpc/tmp-introspecty_ix5pq
On Mon, Dec 23, 2019 at 01:22:05PM -0700, c...@openbsd.org wrote:
> Bulk build on macppc-1.ports.openbsd.org
>
> Critical path missing pkgs:
> http://build-failures.rhaalovely.net/powerpc/2019-12-08/summary.log
Lots of stuff because of x11/gnome/libgweather
Failure:
g-ir-scanner: link: cc -pthre
On Fri, Dec 20, 2019 at 09:22:07PM +, Stuart Henderson wrote:
> When updating ports I'd find it helpful to have an easier way to check
> signatures from upstream. What does anyone think about the general idea
> or the specifics of this? List the signature file in SIGFILES, set
> CHECK_PGPSIG=Ye
On Thu, Dec 19, 2019 at 02:58:21PM -0700, Tracey Emery wrote:
> Hello ports,
>
> I was playing with shotcut and saw .txz in the wild. Diff below extracts
> that now.
It will make sense with a port having the same extension. Gratuitously
adding weird extensions that are not in-use can wait.
On Fri, Dec 06, 2019 at 10:52:50AM +, Stuart Henderson wrote:
> On 2019/12/06 10:46, Marc Espie wrote:
> > I'm also wondering about an option to install all available debug packages
> > for a given port (e.g., the debug package for the port, and the debug
> > packag
99% of the way done.
Working:
- the ports infrastructure itself should be 100% finished.
When DEBUG_PACKAGES is set, an extra "generation step" occurs during
make package, any package mentionned in DEBUG_PACKAGES that's not
arch-independent (PKG_ARCH != *) will get a "companion" debug package.
On Thu, Dec 05, 2019 at 11:04:16PM +, Stuart Henderson wrote:
> On 2019/12/04 20:34, Marc Espie wrote:
> > On Wed, Dec 04, 2019 at 04:00:13PM +, Stuart Henderson wrote:
> > > On 2019/12/04 14:35, Marc Espie wrote:
> > > > On Wed, Dec 04, 2019 at 12:45:46PM
On Wed, Dec 04, 2019 at 04:00:13PM +, Stuart Henderson wrote:
> On 2019/12/04 14:35, Marc Espie wrote:
> > On Wed, Dec 04, 2019 at 12:45:46PM +, Stuart Henderson wrote:
> > > On 2019/12/04 12:17, Marc Espie wrote:
> > > > On Wed, Dec 04, 2019 at 10:48:06AM
On Wed, Dec 04, 2019 at 04:29:19PM +, Stuart Henderson wrote:
> On 2019/12/04 14:29, Marc Espie wrote:
> > On Wed, Dec 04, 2019 at 12:55:33PM +, Stuart Henderson wrote:
> > > On 2019/12/04 12:43, Christian Weisgerber wrote:
> > > > On 2019-
On Wed, Dec 04, 2019 at 12:45:46PM +, Stuart Henderson wrote:
> On 2019/12/04 12:17, Marc Espie wrote:
> > On Wed, Dec 04, 2019 at 10:48:06AM +, Stuart Henderson wrote:
> > > Currently LLD_EMUL is only set for LLD_ARCHS (aarch64 amd64 arm i386).
> > > A dif
On Wed, Dec 04, 2019 at 12:55:33PM +, Stuart Henderson wrote:
> On 2019/12/04 12:43, Christian Weisgerber wrote:
> > On 2019-12-03, Antoine Jacoutot wrote:
> >
> > >> # XXX libreoffice has its own way to build things in parallel
> > >> USES_PARALLEL_MAKE = No
> > >>
> > >> ?
> > >
> > > +1
>
On Wed, Dec 04, 2019 at 10:48:06AM +, Stuart Henderson wrote:
> Currently LLD_EMUL is only set for LLD_ARCHS (aarch64 amd64 arm i386).
> A diff to unbreak mupdf build on mips64 requires linking with lld and this
> variable is required. Rather than adding a custom LLD_EMUL definition in
> mupdf
On Tue, Dec 03, 2019 at 03:41:03PM +, Stuart Henderson wrote:
> On 2019/12/03 15:58, Marc Espie wrote:
> > On Tue, Dec 03, 2019 at 12:37:25AM +0100, Antoine Jacoutot wrote:
> > > On Mon, Dec 02, 2019 at 09:46:11PM -, Christian Weisgerber wrote:
> > > > On
On Tue, Dec 03, 2019 at 12:37:25AM +0100, Antoine Jacoutot wrote:
> On Mon, Dec 02, 2019 at 09:46:11PM -, Christian Weisgerber wrote:
> > On 2019-12-01, Marc Espie wrote:
> >
> > > This patch:
> > > - admits that parallel make is going to be used;
> >
On Mon, Dec 02, 2019 at 09:11:39PM +0100, Matthias Kilian wrote:
> Hi,
>
> today, naddy@ ran into this error (for devel/shellcheck, but this doesn't
> matter here):
>
> /usr/local/bin/ghc-pkg recache '--package-db=dist/package.conf.inplace'
> ===> Exiting devel/shellcheck,-lib with an error
> ghc
On Mon, Dec 02, 2019 at 09:46:11PM -, Christian Weisgerber wrote:
> On 2019-12-01, Marc Espie wrote:
>
> > This patch:
> > - admits that parallel make is going to be used;
> > - renames PARALLEL_BUILD to something that reflects its actual usage
> > (and consumer
On Mon, Dec 02, 2019 at 10:17:44AM +0100, Landry Breuil wrote:
> On Sun, Dec 01, 2019 at 11:31:40AM +0100, Marc Espie wrote:
> > So dpb has been using MAKE_JOBS for a while, and landry said it would be
> > cool to actually have it work with regular builds as well.
> >
> &g
So dpb has been using MAKE_JOBS for a while, and landry said it would be
cool to actually have it work with regular builds as well.
This patch:
- admits that parallel make is going to be used;
- renames PARALLEL_BUILD to something that reflects its actual usage
(and consumers as well): PARALLEL_US
On Sat, Nov 30, 2019 at 11:18:51AM +0100, Jeremie Courreges-Anglas wrote:
> On Fri, Nov 29 2019, Stuart Henderson wrote:
> > Currently we require BUILD_DEPENDS to avoid tripping the (very useful)
> > poisoning that we have to detect ports with a missing dependency on
> > gettext-tools. This used t
I added a warning in build-debug-info that says there's actually no debug
info.
The following ports show it.
databases/evolution-data-server
devel/atk
devel/fribidi
devel/glib2
graphics/babl
graphics/gdk-pixbuf2
graphics/gegl04
net/gupnp/core
net/gupnp/tools
sysutils/deja-dup
x11/gnome/gvfs,,-go
People (semarie@ + kmos@) have experienced issues with FETCH_PACKAGES on
ports featuring the new DEBUG_PACKAGES functionality.
Those are now fixed.
In addition, looking for this bug made it clear some shell code
I had written was not behaving like I was expecting. This made
FETCH_PACKAGES grab
On Sat, Nov 23, 2019 at 12:01:34PM +, Stuart Henderson wrote:
> Before:
>
> # spent 125s within DBI::st::execute which was called 33 times, avg
> 3.80s/call:
> # 33 times (125s+0s) by DBD::_::db::selectcol_arrayref at line 1694 of
> DBI.pm, avg 3.80s/call
> sub DBI::st::execute; # xsub
>
>
On Fri, Nov 22, 2019 at 08:47:24AM -0500, Kurt Mosiejczuk wrote:
> On Thu, Nov 21, 2019 at 05:13:50PM -0500, George Rosamond wrote:
>
> > On 11/21/19 2:25 PM, Jeremy Evans wrote:
>
> > > Can you please resubmit without the gratuitous style changes ("VAR=" to
> > > "VAR =")?
>
> > Corrected and a
On Mon, Nov 18, 2019 at 12:09:18PM +, Stuart Henderson wrote:
> On 2019/11/16 10:21, septimiu turcu wrote:
> > Hi,
> > Please find attached 2 patches:
> > 1. vamp.patch for vamp-plugin-sdk; this fixes a typo (extra white space) in
> > the content of /usr/local/lib/libvamp-hostsdk.la
> > 2. aud
On Sun, Nov 17, 2019 at 11:07:11PM +0100, Charlene Wendling wrote:
> Hi,
>
> The latest version was not able to be built on bulk machines. I've
> tried `DPB_PROPERTIES=lonesome` without success.
>
> So i tried at home, with infinite memory limits for _pbuild and 4GB
> (2GB of ram and 2GB for swap
Somewhat simpler.
- still need up-to-date pkg_add
- you should be able to set DEBUG_PACKAGES=${BUILD_PACKAGES} in most cases,
as it will now zap PKG_ARCH=* from the actual list.
- normal work-flow:
build -> fake -> build-debug-info (internal target for now) -> package
(no more back and forth bet
I added a few more bells and whistles for fringe cases:
- build-debug-info now recognizes hard links to that bsd.port.mk won't
do things that don't work (but instead links from one debug info to another)
- fake doesn't stop if the packing-list isn't 100% right, so that you can
still run update-pl
This is still being worked on, but the main code has hit the tree.
*NOTE YOU MUST UPDATE PKG_ADD TO USE THIS*
- update-plist will now annotate static libraries and shared objects as well
- by default, nothing new happens. If DEBUG_PACKAGES is set to non empty, some
magic will happen.
- the prod
On Mon, Nov 04, 2019 at 02:32:03AM +0900, Daniel Dickman wrote:
> > clang doesn't error out, gcc does.
> > Why does numpy use gcc?
>
> Because that’s what upstream recommends in their docs.
>
> “Note that NumPy is developed mainly using GNU compilers. Compilers from
> other vendors such as Intel
On Mon, Oct 28, 2019 at 02:21:48PM +0100, Charlene Wendling wrote:
> On Sun, 27 Oct 2019 10:03:44 +0100
> Marc Espie wrote:
>
>
> As you already know i managed to build it with -O1. It failed early
> with ports-clang, so i've moved it back to ports-gcc, here are
>
On Sat, Oct 26, 2019 at 03:05:19PM +0200, Klemens Nanni wrote:
> On Sat, Oct 26, 2019 at 08:46:41AM -0400, Brian Callahan wrote:
> > This dirtiness is my fault; I needed libmpv shared lib for a new port that I
> > haven't gotten around to submitting yet.
> No harm done.
>
> > Anything that prevent
In case you manage to build it, note that some of the tests
WILL fail.
After all, this is a library of probabilistic software...
some of their thresholds are set up that sometimes, the test
doesn't find the right solution.
Yeah, *facepalm* right ?
This is something I wrote because nothing satisfactory existed.
This takes a webp image or animation, and converts it back into
a gif or a png.
(because the libunwebp tools do NOT do the reassembly part,
and neither *magick nor ffmpeg do either)
Even though it's a small tool, I think it's importa
On Fri, Oct 04, 2019 at 09:39:00AM +0100, Stuart Henderson wrote:
> On 2019/10/03 20:39, Rafael Sadowski wrote:
> > Bugfix update cmake to 3.15.4, From changelog:
> >
> > "In CMake 3.15.0 through 3.15.3, the EXCLUDE_FROM_ALL directory property
> > was regressed from pre-3.14 behavior and caused ta
On Tue, Sep 17, 2019 at 12:51:27AM -0700, Alfred Morgan wrote:
> Confliction:
> The documentation says "It is possible to use a read-only ports tree" but I
> got errors using the config example in:
> https://www.openbsd.org/faq/ports/ports.html#PortsConfig
Read the man page instead, ports(7) is up
By all means, new reasons are indeed cheap, they're just a way to keep
things compact.
I added all the initial ones in one go, there's no reason not to add
new ones as seems fitting.
On Fri, Aug 23, 2019 at 11:47:29PM +0200, Matthias Kilian wrote:
> The only drawback I can see is the update path from the old to the new
> scheme, because pkg_add(8) will complain about collisions when updating
> ghc:
>
> ]# pkg_add -uvx
> Old package ghc-8.2.2p4 will run the following commands
On Tue, Aug 20, 2019 at 01:47:15PM +0100, Stuart Henderson wrote:
> On 2019/08/20 14:39, Marc Espie wrote:
> > On Fri, Aug 16, 2019 at 12:48:09AM +0200, Jan Stary wrote:
> > > On Aug 15 18:30:20, j...@wxcvbn.org wrote:
> > > > Committed, thanks!
> > >
>
On Fri, Aug 16, 2019 at 12:48:09AM +0200, Jan Stary wrote:
> On Aug 15 18:30:20, j...@wxcvbn.org wrote:
> > Committed, thanks!
>
> So now, with openrsync in base (thank you Kristaps),
> rsync can finaly go.
As of now, the main point of openrsync is to be able to test
interoperability of the proto
On Mon, Aug 12, 2019 at 03:27:55PM +, adr wrote:
> >And disabling asm is unappealing on an arch which needs as much
> >help with speed as it can get.
>
> Even worst if you have to play video without hw acc.
>
> I thought that the decision of using --no_unaligned_access was a
> security one, b
On Fri, Aug 09, 2019 at 11:33:52AM -0400, Daniel Jakots wrote:
> Hi,
>
> root@caramel:~# pkg_add -P ftp tree
> quirks-3.165 signed on 2019-08-07T13:50:33Z
> tree-0.62: ok
> root@caramel:~# pkg_delete tree
> tree-0.62: ok
> root@caramel:~# pkg_add -P cdrom tree
> quirks-3.165 signed on 2019-0
Fairly straightforward, it's a template library.
It still builds some tests though.
Need okay before I can proceed with armadillo/mlpack updates
ensmallen.tgz
Description: application/tar-gz
On Fri, Jul 26, 2019 at 02:50:22PM +0200, Charlene Wendling wrote:
>
> > http://build-failures.rhaalovely.net//powerpc/2019-07-14/graphics/aspect-crop.log
> > http://build-failures.rhaalovely.net/sparc64/2019-07-11/graphics/aspect-crop.log
Got it fixed properly, thanks.
(I am upstream, so patche
On Fri, Jul 12, 2019 at 09:21:53AM -0400, Kurt Mosiejczuk wrote:
> On Fri, Jul 12, 2019 at 02:11:21PM +0100, Stuart Henderson wrote:
>
> > This one changes -rar from packages available to packages not
> > available.
>
> Which also answers my questions about the problems with scripting
> multipack
On Thu, Jul 11, 2019 at 11:12:14PM +0200, Christian Weisgerber wrote:
> A few words about cleaning up PERMIT_PACKAGE_*, since I've done
> similar changes before.
>
> You might think this will take care of itself over time, as ports
> are updated and modified, they'll eventually all get cleaned up.
On Wed, Jul 10, 2019 at 11:39:53AM +0100, Stuart Henderson wrote:
> + "skippable frames", the signature could probably live here
As long as the logic is simple enough, because code for grabbing
those frames must be rewritten for signify and be trusted.
On Tue, Jul 09, 2019 at 08:04:23PM +0300, Leonid Bobrov wrote:
> > An all-arches package snapshot currently runs at 200GB and adding
> > symbols across the board would add a lot to this.
>
> Stuart and Espie, have you ever heard of compression?
WTF is wrong with you ?
I haven't participated to t
401 - 500 of 2141 matches
Mail list logo
