Maven 3.2 local repository and macports user

Folks, I am updating the postgresql-jdbc port to version 42.2.8 [1] and switched to maven 3.2 for building. Maven creates a local repository at ~/.m2/repository/. Performing the extract phase then building manually under root or my own user is working fine but the build phase is performed unde

Re: Maven 3.2 local repository and macports user

Indeed... I added this to the build.args: --define maven.repo.local=${workpath}/m2/repository Problem solved... Thanks to both of you, Georges > Le 27 sept. 2019 à 00:51, Joshua Root a écrit : > > On 2019-9-27 08:09 , Chris Jones wrote: >> Hi, >> >> I am not familiar with maven, but

Re: legacy-support and Wayland

I’m no expert on Wayland but I found this discussion on a Darwin port a while back: https://mastodon.technology/@bugaevc/101603518023241841 G. > Le 15 oct. 2019 à 13:31, Jack Howarth a écrit > : > >  > I asked Jeremy about potential Wayland support for macOS awhile back and > his respon

Fwd: Developer mode

> Début du message réexpédié : > > De: Georges Martin > Objet: Re : Developer mode > Date: 30 novembre 2019 à 14:55:11 UTC+1 > À: Rainer Müller > > >> Le 26 nov. 2019 à 16:05, Rainer Müller a écrit : >> >> Sounds very useful to have such a tool. B

Re: port "cask" -- installing prebuilt binaries

> Le 5 août 2020 à 12:52, Lothar Haeger a écrit : > > Even if MacPorts also provided closed source stuff it would still be your > choice to install or not install it. Problem is with dependencies on closed source packages where you have no choice. If I use apt or dnf as part of a Linux distr

Re: port "cask" -- installing prebuilt binaries

Good point. And I just updated postgresql-jdbc, which depends on binary-only openjdk*... :-| > Le 7 août 2020 à 08:59, Ryan Schmidt a écrit : > >  > >> On Aug 5, 2020, at 07:52, Georges Martin wrote: >> >> If MacPorts starts to mix both approaches, I worry

Re: Publicizing MacPorts

> Le 19 avr. 2021 à 16:47, Karl-Michael Schindler > a écrit : > > My next steps is to write to them. That's something that each port maintainers could do with their upstream maintainers. From my experience, upstream maintainers are happy to help if, in addition to code and test patches, you

Re: Publicizing MacPorts

Done: https://github.com/macports/macports-ports/pull/10726 > Le 19 avr. 2021 à 23:46, Clemens Lang a écrit : > > Hi, > > On Mon, Apr 19, 2021 at 07:58:02PM +0200, Georges Martin wrote: >> Speaking of the PR checklist, the "Tested On" section could in

Re: Publicizing MacPorts

> Le 22 avr. 2021 à 17:46, Steven Smith a écrit : > > Another reason major news like M1 support must be announced. May I ask: how do we *define* "M1 support" in MacPorts? What are the *metrics* used to support that statement? - How does the MacPorts base "support the M1"? (I know I had to ins

Re: M1 CPU features

$ sysctl hw.optional | grep -E 'neon|armv8' hw.optional.neon: 1 hw.optional.neon_hpfp: 1 hw.optional.neon_fp16: 1 hw.optional.armv8_1_atomics: 1 hw.optional.armv8_crc32: 1 hw.optional.armv8_2_fhm: 1 hw.optional.armv8_2_sha512: 1 hw.optional.armv8_2_sha3: 1 > Le 26 avr. 2021 à 19:55, Jason Liu a é

Re: M1 CPU features

e Mac Pro ? ;-) G. > Le 26 avr. 2021 à 20:44, Jason Liu a écrit : > > Aha, hw.optional! That's useful, thanks Georges! > > -- > Jason Liu > > > On Mon, Apr 26, 2021 at 2:16 PM Georges Martin <mailto:jrjsm...@gmail.com>> wrote: > $ sysctl hw.opt

Re: M1 CPU features

CPUs pretty much anywhere, including on Arm (using NEON if available). With almost no source code changes, you can recompile your x86 SIMD code for Arm (or POWER, or WebAssembly, etc.). ...that is not yet packaged for MacPorts ;-) ;-) ;-) G. > Le 26 avr. 2021 à 20:56, Georges Martin a éc

Re: MacPorts Base: Support for a lower level of debug output, like ui_trace, or ui_debug2/ui_debug3?

> I personally find debug mode too verbose already and think we should reduce > the amount of information produced by debug mode. I don’t know enough about Tcl logging but in Python you can have separate, hierarchical loggers for each major modules in your system and then activate and set the

Acting on a subport in a development Portfile

When working on a Portfile in a macports-ports clone, it's possible to perform actions in its directory, without giving the port name (and not adding the repo to sources.conf): $ cd ~/repos/macports-ports// $ port info $ port lint $ sudo port build But if the Po

Re: Acting on a subport in a development Portfile

> Le 22 janv. 2022 à 21:31, Joshua Root a écrit : > > No. You can set Portfile variables on the command line for development > purposes, and this includes 'subport'. For example: > > sudo port build subport=thesubportname > > - Josh That's... awesome :-) Thanks, I didn't know that. G. sign

Re: Upstream installation hint about MacPorts

I second both suggestions. Although, as Homebrew and MacPorts are not the only games in town, I would change one paragraph to: « If Homebrew, Fink, NetBSD pkgsrc or Nix are already mentioned, […] » 😉 G. > Le 15 févr. 2022 à 16:45, Karl-Michael Schindler > a écrit : > > Hi. > > In order to

Re: EGL support on MacOS?

I’m no expert on OpenGL either, but Alyssa Rosenzweig (@alyssarzg on Twitter) certainly is. She’s working on OpenGL and Mesa, on macOS and Asahi Linux. G. > Le 23 août 2022 à 17:33, Ken Cunningham a > écrit : > >  > I am not an expert on OpenGL support on any system, just trying to get thing