Hello,

I would like to add new subpackage for main/guile, however to do so, I
need etags program. That is part of community/emacs (emacs-nox is
enough). Obviously I cannot depend on community package in main
repository. So I'm not sure how to proceed.

Options I see:

1. Move guile to community
  -> Just no, I like it in main
2. Move emacs to main
  -> I assume there is a reason it's only community instead of main
3. Make new package community/guile-tags basically extracting the

On 2022-10-08 01:13:21 +0200, alice wrote:
> On Sat Oct 8, 2022 at 12:40 AM CEST, Wolf wrote:
> > Hi,
> >
> > I'm curious about this[0] job that was executed as part of pipeline for my
> > merge request. It looks like it tried to build two packages:
> >
> >     >>> testing/bazel: build succesfully
> >     >>> testing/bazel4: build succesfully
> >
> > Any idea why? My merge request[1] is touching just one of them, so I
> > have no idea why both are built. It seems a bit unnecessary and the
> > build takes quite long.
> >

Hi,

I'm curious about this[0] job that was executed as part of pipeline for my
merge request. It looks like it tried to build two packages:

    >>> testing/bazel: build succesfully
    >>> testing/bazel4: build succesfully

Any idea why? My merge request[1] is touching just one of them, so I
have no idea why both are built. It seems a bit unnecessary and the
build takes quite long.

Given that I do not touch bazel4, I guess following error is expected?

---
 ...-Redefine-strdupa-to-be-valid-C-code.patch | 26 +++++++
 .../0002-Do-not-use-prebuilt-binaries.patch   | 35 +++++++++
 ...er-local_jdk-instead-of-remote_jdk11.patch | 75 +++++++++++++++++++
 ...sh_completion-compatible-with-busybo.patch | 28 +++++++
 ...l-for-generating-the-bash-completion.patch | 34 +++++++++
 testing/bazel/APKBUILD                        | 70 +++++++++++++++++
 6 files changed, 268 insertions(+)
 create mode 100644 testing/bazel/0001-Redefine-strdupa-to-be-valid-C-code.patch
 create mode 100644 testing/bazel/0002-Do-not-use-prebuilt-binaries.patch
 create mode 100644 testing/bazel/0003-Prefer-local_jdk-instead-of-remote_jdk11.patch
 create mode 100644 testing/bazel/0004-Make-generate_bash_completion-compatible-with-busybo.patch
 create mode 100644 testing/bazel/0005-Use-nojdk-bazel-for-generating-the-bash-completion.patch
 create mode 100644 testing/bazel/APKBUILD
[message trimmed]

First, sorry for a bit late response, I did not manage to find a time to
look into this sooner.

On 2022-07-23 12:08:08 +0200, Ruud van Asseldonk wrote:
> LibreSSL 3.5 now supports the same interface as OpenSSL, so the
> compatibility macros are no longer needed, and in fact they break
> compatibility with LibreSSL 3.5, so we can just delete them.
> 
> This breaks compatibility with LibreSSL 3.4, which does not support this
> interface. I think this is acceptable; if you are using a recent
> acme-client, you should probably also be using a recent LibreSSL, but if you
> want to keep compatibility with both, we could keep the macro and make it
> check the version number.

On 2022-07-20 10:41:18 -0500, Ariadne Conill wrote:
> The Rust patches are necessary to make Rust behave as expected on the Alpine
> system, the Rust developers are aware of them, some of them have already
> been upstreamed over the years, while others are planned to eventually be
> replaced with equivalent upstream work that aligns the `-musl` targets, but
> somebody needs to actually implement the work to harmonize the targets,
> which again, everyone including upstream Rust wants[0].
> 
> Needless to say, the Rust developers are aware of them and have raised no
> objection to the patches as they are necessary to make things work as
> expected on Alpine.
> 
> Ariadne
> 

Hello,

I would like to inquire about the `community/rust' package. After
reading this [0] fun debate bug thread over at debian bug tracker, I've
started to wonder what is the state of this in alpine.

It looks like at least some of the patches in community/rust do not fall
under any of these categories (from [1]):

 - porting the software to a different architecture
 - fixing local paths
 - adding patches that have been released upstream
 - adding patches that have been reported upstream, provided that the
   patch is removed if it is not accepted upstream

---
 ...-Redefine-strdupa-to-be-valid-C-code.patch | 26 +++++++
 .../0002-Do-not-use-prebuilt-binaries.patch   | 35 +++++++++
 ...er-local_jdk-instead-of-remote_jdk11.patch | 75 +++++++++++++++++++
 ...sh_completion-compatible-with-busybo.patch | 28 +++++++
 ...l-for-generating-the-bash-completion.patch | 34 +++++++++
 testing/bazel/APKBUILD                        | 70 +++++++++++++++++
 6 files changed, 268 insertions(+)
 create mode 100644 testing/bazel/0001-Redefine-strdupa-to-be-valid-C-code.patch
 create mode 100644 testing/bazel/0002-Do-not-use-prebuilt-binaries.patch
 create mode 100644 testing/bazel/0003-Prefer-local_jdk-instead-of-remote_jdk11.patch
 create mode 100644 testing/bazel/0004-Make-generate_bash_completion-compatible-with-busybo.patch
 create mode 100644 testing/bazel/0005-Use-nojdk-bazel-for-generating-the-bash-completion.patch
 create mode 100644 testing/bazel/APKBUILD
[message trimmed]

---
 main/guile/APKBUILD | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/main/guile/APKBUILD b/main/guile/APKBUILD
index 032b636712..af5721f4fc 100644
--- a/main/guile/APKBUILD
+++ b/main/guile/APKBUILD
@@ -6,15 +6,15 @@
 
 pkgname=guile
 pkgver=3.0.8
-pkgrel=1
+pkgrel=2
[message trimmed]

---
 main/guile/APKBUILD | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/main/guile/APKBUILD b/main/guile/APKBUILD
index 9c863c9106..032b636712 100644
--- a/main/guile/APKBUILD
+++ b/main/guile/APKBUILD
@@ -6,15 +6,15 @@
 
 pkgname=guile
 pkgver=3.0.8
-pkgrel=0
+pkgrel=1
[message trimmed]