Re: Postponing August ISO due to kernel bug
Hi, On 1/08/2022 20:43, Pierre Schmitz wrote: Hi all, nl6720 informed me about a recent kernel bug that prevents some older CPU models to boot*. While a simple workaround exists, I agree that this issue might be quite unexpected and frustrating for users. Especially since releasing a new install media on the 1st each month is more a tradition than an actual need. Therefore I'll wait for a fixed linux package. (the July ISO is still pretty recent :-)) Greetings, Pierre *) https://bugs.archlinux.org/task/75478 The only issue now is you have to update the archlinux-keyring package on the live iso to avoid having stuff popping up of "invalid keys" or keys with marginal trust. This is ofcourse less of an issue versus not booting. Greets, Ike
Looking for maintainer of kodi-addon-game-libretro
Hi, Since I only build these related extensions and never test or use them myself I'm looking for someone who wants to take care of the "gaming" part of Kodi. As part of the update to Kodi 20 I'll rebuild them but if nobody is interested I will drop all of kodi-addon-game-libretro to AUR. -- Ike
dropping opera
Hi, Since I have not really used opera for years, I'm finally going to drop it from the repo's. If someone wants it, feel free to adopt it. Else I will drop it to AUR in 2 weeks. --Ike signature.asc Description: This is a digitally signed message part
Re: dropping opera
Hi, On Thu, 2024-01-25 at 21:01 +0100, Ike Devolder wrote: > Hi, > > Since I have not really used opera for years, I'm finally going to > drop > it from the repo's. If someone wants it, feel free to adopt it. Else > I > will drop it to AUR in 2 weeks. > > --Ike I have dropped opera[1] and opera-ffmpeg-codecs[2] to AUR. If someone with more permissions could archive the package repos in our gitlab it is done. --Ike [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/opera [2]: https://gitlab.archlinux.org/archlinux/packaging/packages/opera-ffmpeg-codecs
Re: [arch-dev-public] Spring cleanup '21
On 28/04/2021 18:16, Antonio Rojas via arch-dev-public wrote: It's been over a year since our last package cleanup and orphans keep piling up. Please head to https://archlinux.org/devel/reports/unneeded-orphans/ and adopt packages you'd like to keep in the repos. If you are not a dev and would like to adopt some orphan in [extra], reply here or ping me on IRC and I'll move it. I'll start dropping the remaining packages to AUR in about 10 days. I have taken - projectm - copyq --Ike OpenPGP_0xDB323392796CA067.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] archlinux.org update
On 29/04/2021 00:00, Jelle van der Waa via arch-dev-public wrote: Hi All, Today I've updated archlinux.org with some interesting changes for packagers. Two new reports have been added: * A new report which includes all required orphan packages in our repositories. [1] * A new report which which includes all orphan non reproducible packages [2] The non reproducible packages dashboard now includes links to the build log and diffoscope output of the packages. Which should help fixing those packages. Lastly archweb now parses the links databases which exists in our repository. So as alternative to 'sogrep' curl -s "https://archlinux.org/packages/sonames?name=libwebsockets.so"; | jq '.[].pkgname' "kismet" "libwebsockets" "ardour" "csound" "mosquitto" "kismet" "libwebsockets" This is still a bit alpha-ish as there seems to be some issues with updating the data. [4] Feedback is welcome, as I just realized it shows packages for all repositories so some people might want a filter on "stable" or "testing" or "staging" repositories. Finally what sonames the package requires is shown in the package detail page [6] [1] https://archlinux.org/devel/reports/required-orphan/ [2] https://archlinux.org/devel/reports/orphan-non-reproducible-packages/ [3] https://archlinux.org/devel/reports/non-reproducible-packages/jelle/ [4] https://github.com/archlinux/archweb/issues/342 [5] https://archlinux.org/packages/extra/x86_64/libwebsockets/ [6] https://archlinux.org/packages/extra/x86_64/libwebsockets/ Greeting, Jelle van der Waa Awesome work, thanks --Ike OpenPGP_0xDB323392796CA067.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] Library dependencies
Hi, On 17/12/2021 04:42, Xyne via arch-dev-public wrote: On 2021-12-16 19:53 +1000 Allan McRae via arch-dev-public wrote: Assuming that dependent library is not used elsewhere in the package, and the extra library had a provide of its library version, then this would add an extra dependency. There are several options: 1) disable autodeps - these really do not need used everywhere... 2) split the package 3) move the binary into /usr/lib/ and add a symlink to /usr/bin. Then (assuming BIN_DIR=usr/bin is the usual search path), the dependency would not be added. Saying that, I am against optional dependencies that are genuinely needed for a binary to run. I think these should be used for features that could be dynamically loaded if the optional dependency is present. I prefer package splitting if that is not the case. I thought it was a supported use case but I agree with you that it's better to split. You can have multiple packages that provide the same command, but there may be rare cases where two conflicting packages provide unrelated commands with the same name, or a restricted version of a command that may not support the full argument set. It's worth considering how to handle such cases now before settling on a syntax. Do you have an example? I don't like adding complexity for "what if" cases that may never occur. Nope, only a vague memory of some package conflict several years ago with two identically named commands that did completely different things. I think it was eventually solved by renaming one and telling upstream that the name was already used for a common executable. So yeah, it's not really an issue. The example that comes to mind is docker[1]. This existed already (I also think we had it in the repos) as a system tray tool / dock app[2]. The issue then was resolved by changing the tray app's name and binary to docker-tray[3] and let the container tool docker have the docker name. There have been discussions[4] about the name then. But in general we can solve this kind of problems as was done then, by giving the package/binary a suffix in the name. For the case you described, cmd:foo is provided by two packages, foo1 and foo2. foo2 has a subset of the functionality. Then you could depend on cmd:foo if either works, or foo1 if you need the full functionality. Ok For optdeps, what I mean is if the normal dependency would be "lib:libgpgme.so.11", how will you parse the normal optdep syntax of "pkgname: reason"? "lib:libfoo.so.13: required for the command foo". Won't using the same delimiter in two different contexts be problematic? From memory, the space in ": " is important for optdepends. I need to check, but I don't think the PKGBUILD linter will let PKGBUILDs with optdepends without the space build. And pacman will not split the string without it. So this should be fine. I wasn't sure that the space was enforced. If it is, then there's no issue. Coming back to your initial question: Any opinions on this would be greatly appreciated. Is this a better system than the current one? Is adding automatic dependencies against the spirit of makepkg where everything is in the PKGBUILD? It seems better to me. Less tedious and error-prone. Regards, Xyne [1] https://archlinux.org/packages/community/x86_64/docker/ [2] https://aur.archlinux.org/packages/docker-tray/ [3] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=docker-tray#n24 [4] https://lists.archlinux.org/pipermail/aur-general/2013-November/026213.html
