aports issueshttps://gitlab.alpinelinux.org/alpine/aports/-/issues2023-11-20T18:31:34Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9074Aports contributions - license & copyright?2023-11-20T18:31:34ZTBKAports contributions - license & copyright?The question was brought up with this PR -
https://github.com/alpinelinux/aports/pull/4490/files and has also
previously been touched in https://bugs.alpinelinux.org/issues/7423
The https://git.alpinelinux.org/cgit/aports/tree/README.md...The question was brought up with this PR -
https://github.com/alpinelinux/aports/pull/4490/files and has also
previously been touched in https://bugs.alpinelinux.org/issues/7423
The https://git.alpinelinux.org/cgit/aports/tree/README.md file nor is
there another file mentioning it in the git repo.
and I have searched the sites and wiki and can not find the answer.
So I have the following questions:
- Which license are the aports themselves (APKBUILD, pre, post…)
under?
- Who are the copyright holders (the contributor or given to the
project)?
- Should AL have a CLA
(https://en.wikipedia.org/wiki/Contributor\_License\_Agreement)?
*(from redmine: issue id 9074, created on 2018-07-11)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10154watchman 4.9.0-r2 does not create a states directory for watchman on installa...2019-07-12T15:45:56ZViraj Trivediwatchman 4.9.0-r2 does not create a states directory for watchman on installationI tried using the watchman package from the Alpine Repository with
Docker https://pkgs.alpinelinux.org/package/edge/testing/x86/watchman
And I get error when I am running watchman.
$ watchman --foreground --logfile=/dev/stdout
...I tried using the watchman package from the Alpine Repository with
Docker https://pkgs.alpinelinux.org/package/edge/testing/x86/watchman
And I get error when I am running watchman.
$ watchman --foreground --logfile=/dev/stdout
2019-03-23T05:47:33,674: [] while computing sockname: failed to create /var/run/watchman/root-state: No such file or directory
ERROR: Job failed: exit code 1
Similar to this issue https://github.com/facebook/watchman/issues/640.
Which I fixed by creating the missing directory manually. Is it supposed
to be like that? Or the Alpine Installation should be generating that
Package? Since the build log of the alpine package did log the state
directory
https://build.alpinelinux.org/buildlogs/build-edge-x86/testing/watchman/watchman-4.9.0-r2.log
. Shouldn’t it be creating directory post installing the package.
*(from redmine: issue id 10154, created on 2019-03-25)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10267nmtui can not configure wlan02024-03-19T16:16:23Zxrsnmtui can not configure wlan0I’m using the NetworkManager. I installed the package networkmanager and
started the service. The service is working perfectly since a few
months. Wifi works and connection are established automatically.
But since the beginning it was n...I’m using the NetworkManager. I installed the package networkmanager and
started the service. The service is working perfectly since a few
months. Wifi works and connection are established automatically.
But since the beginning it was not possible to use nmtui to configure my
wlan0 interface, only eth0 and lo. I also added my user to the groups
plugdev and netdev and restarted.
nmcli -d:
DEVICE TYPE STATE CONNECTION
eth0 ethernet unavailable —
wlan0 wifi unavailable —
lo loopback unmanaged —
Currently I use wpa\_supplicant to configure my wifi.
*(from redmine: issue id 10267, created on 2019-04-16)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10603When should -dbg packages be added?2021-09-09T10:18:02ZRasmus Thomsenoss@cogitri.devWhen should -dbg packages be added?Right now we don’t really have a policy for when to add -dbg packages
(at least I can’t seem to find anything)? As a result we mostly don’t
use them (there are about 80 dbg packages, apparently). It’d be nice if
we provided -dbg packages...Right now we don’t really have a policy for when to add -dbg packages
(at least I can’t seem to find anything)? As a result we mostly don’t
use them (there are about 80 dbg packages, apparently). It’d be nice if
we provided -dbg packages for more (if not all) packages to make
debugging possible.
Pro:
\+ Without -dbg packages for a package *and all of its (recursive)
dependencies)* it’s usually impossible to properly debug a program.
Stacktraces won’t have any info for where errors occured and won’t
contain function names (due to them being optimized away), making
debugging via gbd/lldb or similiar somewhat impossible.
Neutral:
o These -dbg packages won’t take up space on the user’s setup unless he
explicitly installs them (maybe we could add a dbg package which just
installs them all, like doc)
Con:
- Dbg packages can be massive, especially for already big packages. This
would mean that we’d need quite a bit more disk spaces on the mirrors.
We could disable -dbg packages for super big packages like webkit2gtk
though.
*(from redmine: issue id 10603, created on 2019-06-22)*
Subtasks:
- [ ] Make debugoptimized the default for meson
- [ ] Make RelWithDebInfo the default for CMake
- [ ] Make `$pkgname-dbg` a default subpkg in newapkbuild
- [ ] Add `-g` to CFLAGSRasmus Thomsenoss@cogitri.devRasmus Thomsenoss@cogitri.devhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/11701Ensure valid AppStream metadata2023-05-09T14:22:44ZRasmus Thomsenoss@cogitri.devEnsure valid AppStream metadataCurrently we're having many faulty (e.g. missing description, missing icons etc.) AppStream files in our packages. This isn't necessarily because of packaging error but because upstream didn't follow the AppStream policies while writing ...Currently we're having many faulty (e.g. missing description, missing icons etc.) AppStream files in our packages. This isn't necessarily because of packaging error but because upstream didn't follow the AppStream policies while writing the file for their project. As such we should probably poke upstreams about these issues when we discover them.
See https://appstream.alpinelinux.org/20200628/html/edge/community/issues/index.html for a list of issues. Note that the data is regenerated daily, so you might have to change the date. Also see the main and testing repos.3.19.0Rasmus Thomsenoss@cogitri.devRasmus Thomsenoss@cogitri.devhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12030all java version: Using AWT in non-headless JRE yields NPE in internal class2021-06-07T05:07:52ZSimon Fsimon-alpine@fraho.euall java version: Using AWT in non-headless JRE yields NPE in internal classInstalling the non-headless version of a JRE should include everything needed to run applications in non-headless modes. This mainly affects drawing / printing applications using `jfreechart` or `batik`.
This is not the case with current...Installing the non-headless version of a JRE should include everything needed to run applications in non-headless modes. This mainly affects drawing / printing applications using `jfreechart` or `batik`.
This is not the case with current java packages in alpine, but also affects other vendors like AdoptOpenJDK (https://github.com/AdoptOpenJDK/openjdk-docker/issues/75).
The stacktrace differes between Java-Version, but looks like this:
```
Caused by: java.lang.NullPointerException
at sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
at sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:219)
at sun.awt.FontConfiguration.init(FontConfiguration.java:107)
at sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:774)
at sun.font.SunFontManager$2.run(SunFontManager.java:431)
at java.security.AccessController.doPrivileged(Native Method)
at sun.font.SunFontManager.<init>(SunFontManager.java:376)
at sun.awt.FcFontManager.<init>(FcFontManager.java:35)
at sun.awt.X11FontManager.<init>(X11FontManager.java:57)
and
Caused by: java.lang.NullPointerException
at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1262)
at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:225)
at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:107)
at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:719)
```
The error can be reproduced with the following class:
```java
import java.awt.image.BufferedImage;
public class Test {
public static void main(String[] args) {
BufferedImage image = new BufferedImage(10, 10, BufferedImage.TYPE_INT_RGB);
System.out.println(image.getGraphics());
}
}
```
The issue can be fixed quite easily by installing a font. But as this error is not intuitive we should install some font by default wehn installing the JRE.
- [ ] openjdk7
- [x] openjdk8 (!13758)
- [ ] openjdk9
- [ ] openjdk10
- [ ] openjdk11
- [ ] openjdk12
- [ ] openjdk13
- [ ] openjdk14
- [ ] openjdk15
- [ ] openjdk16https://gitlab.alpinelinux.org/alpine/aports/-/issues/13306community/bareos: split sd, fd and director into subpackages2022-05-25T06:45:39ZSimon Fsimon-alpine@fraho.eucommunity/bareos: split sd, fd and director into subpackagesCurrently the `bareos` aport ships all applications in a single aport. As this is not always needed (e.g. you don't need the director when you just want to backup a new server) this aport should be split just like other distros do.
Plea...Currently the `bareos` aport ships all applications in a single aport. As this is not always needed (e.g. you don't need the director when you just want to backup a new server) this aport should be split just like other distros do.
Please add subpackages for the storage-daemon, file-daemon and director, e.g. `bareos-dir`, `bareos-sd` and `bareos-fd`Francesco ColistaFrancesco Colistahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15221Upgrade OCaml to 5.x and add community/ocaml42023-08-29T11:52:25Zomniomni+alpine@hack.orgUpgrade OCaml to 5.x and add community/ocaml4Chatting with @Celeste the other day about the future of OCaml, I open this issue to plan what, how and when.
I've kept `community/ocaml` at 4.x since 5.x only have native compiler for a limited set of architectures. It is still possibl...Chatting with @Celeste the other day about the future of OCaml, I open this issue to plan what, how and when.
I've kept `community/ocaml` at 4.x since 5.x only have native compiler for a limited set of architectures. It is still possible to use the bytecode compiler for the other architectures but the programs will be less performant for those architectures than built with the native compiler. More architectures will be added to future OCaml 5.x releases but 32bit architectures are unlikely and those are generally more resource constrained, why I am hesitant to drop OCaml 4.x and accept using the 5.x bytecode compiler.
My suggestion is to, at some point, upgrade `community/ocaml` to latest version 5, add `community/ocaml` at latest version 4 and have a case statement for OCaml aports like:
```
case "$CARCH" in
arm*|x86) makedepends="$makedepends ocaml4" ;;
*) makedepends="$makedepends ocaml" ;;
esac
```
The only issue I currently see here is that 32bit/OCaml4 packages will be rebuilt when there's a new OCaml5 release and vice versa for 64bit packages, not sure if that's much of an issue if we use a generic commit message like `community/*: rebuild against ocaml`.
So if, then when to do this?
- Now? There's still a few months until our 3.19 release to try it out in edge.
- When more/all of our 64bit architectures are added to a OCaml 5.x release?
- Right after our 3.19 release? So we'll have ~half a year to try it in edge before our next release.
- Other?omniomni+alpine@hack.orgomniomni+alpine@hack.org