Search results for "arm" - Aur-requests

Re: [PRQ#62090] Deletion Request for pencil2d-mypaint-git

by Popolon

Hi, It would be better to report in AUR comments, the fact that the package doesn't work first, instead of asking for deletion as first, sot I believe. This version of pencil2d with MyPaint lib is still very interesting as a very light animation tool working on low end device, but with interesting brush system. The 5200.78b1993c-1 revision is still working on my system. I will look at what I can to to make this tool survive in this state. I put a compiled package fox x86_64 at this place: https://popolon.org/depots/ArchLinuxX86/pencil2d-mypaint-git-5200.78b1993c-… There are some older version for ARM too in dedicated folder, I will compile one for RISC-V (RV64) Are there some AUR rules in regard of this kind of case, to freeze git version to an older one ? Else I would at least try to patch it. Looks like the compilation problem is only related to a string comparaison version. Regards, Le 15/08/2024 à 16:36, notify(a)aur.archlinux.org a écrit : > MarsSeed [1] filed a deletion request for pencil2d-mypaint-git [2]: > > Broken, obsolete package The feature branch used by this fork package > has been abandoned by the fork creator since May 2023. [a] > > Also this fails to build from source. > > At this point, it might be enough to keep only the vanilla > AUR/pencil2d-git [b] package, which builds directly from upstream's > latest commits from their master branch, and which works fine. > > [a]: > https://github.com/MrStevns/pencil/tree/implement_mypaint_nobitmapsurface > [b]: > https://aur.archlinux.org/pkgbase/pencil2d-git > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/pencil2d-mypaint-git/

11 months, 4 weeks

Re: [PRQ#59772] Deletion Request for widevine

by Dan Johansen

Den 29.04.2024 kl. 20.09 skrev notify(a)aur.archlinux.org: > MarsSeed [1] filed a deletion request for widevine [2]: > > Re-filing a deletion request due to not receiving any response [a] as > to the rationale to keep this duplicate of the properly packaged > AUR/chromium-widevine. [b] > > The AUR/widevine package was created with the sole purpose of offering > ARM support, and x86_64 was only added to mask its intent. > > Also I believe it is not okay to create duplicates on AUR when there > is already a maintained package which works with Arch Linux. > AUR/widevine's maintainer should collaborate with that of > AUR/chromium-widevine and suggest enhancements there, if there are > relevant ones. > > In addition, AUR/widevine has other problems. As its used release > deliverables for different platforms diverge in their version: > > - AUR/widevine pkgver: 4.10.2252.0 > - x86_64: upstream - 4.10.2710.0 (released 2024-02-12) > - aarch64/armhf: RaspberryPi.org/Debian - 4.10.2252.0 (released > 2023-10-05) > - (AUR/chromium-widevine pkgver: 4.10.2710.0, released 2024-02-12) > > As the RPI distro does not carry the latest version, it seems not to > be viable to carry binaries for different architectures in the same > PKGBUILD. > > Which leads me to conclude that a PKGBUILD for the RPI releases should > be submitted to the ArchLinuxARM.org repositories only. The problem with that is that widevine is not open source and not distributable, so the package is not allowed to be in any repository, thus an AUR package is required. > > That would actually benefit users more, while not cluttering the AUR. > > [a]: > https://lists.archlinux.org/archives/list/aur- > requests@lists.archlinux.org/thread/IAHLWRGRNHHUZRU2LRMX5UTZUNGJBAUO/#5CT5XAQZNIHQYPSRZ6CMDTY67XE3QOU2 > [b]: > https://aur.archlinux.org/packages/chromium-widevine > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/widevine/ -- Med venlig hilsen Dan Johansen

1 year, 3 months

Re: [PRQ#59772] Deletion Request for widevine

by Marcell Meszaros

On 29 April 2024 20:16:54 GMT+02:00, Dan Johansen <danjohansen(a)strits.dk> wrote: > >Den 29.04.2024 kl. 20.09 skrev notify(a)aur.archlinux.org: >> MarsSeed [1] filed a deletion request for widevine [2]: >> >> Re-filing a deletion request due to not receiving any response [a] as >> to the rationale to keep this duplicate of the properly packaged >> AUR/chromium-widevine. [b] >> >> The AUR/widevine package was created with the sole purpose of offering >> ARM support, and x86_64 was only added to mask its intent. >> >> Also I believe it is not okay to create duplicates on AUR when there >> is already a maintained package which works with Arch Linux. >> AUR/widevine's maintainer should collaborate with that of >> AUR/chromium-widevine and suggest enhancements there, if there are >> relevant ones. >> >> In addition, AUR/widevine has other problems. As its used release >> deliverables for different platforms diverge in their version: >> >> - AUR/widevine pkgver: 4.10.2252.0 >> - x86_64: upstream - 4.10.2710.0 (released 2024-02-12) >> - aarch64/armhf: RaspberryPi.org/Debian - 4.10.2252.0 (released >> 2023-10-05) >> - (AUR/chromium-widevine pkgver: 4.10.2710.0, released 2024-02-12) >> >> As the RPI distro does not carry the latest version, it seems not to >> be viable to carry binaries for different architectures in the same >> PKGBUILD. >> >> Which leads me to conclude that a PKGBUILD for the RPI releases should >> be submitted to the ArchLinuxARM.org repositories only. >The problem with that is that widevine is not open source and not distributable, so the package is not allowed to be in any repository, thus an AUR package is required. >> >> That would actually benefit users more, while not cluttering the AUR. >> >> [a]: >> https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/… >> [b]: >> https://aur.archlinux.org/packages/chromium-widevine >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/widevine/ Hm, in that case, I believe the best course of action would be yet to add the RaspberryPi release tarballs to AUR/chromium-widevine, and its pkgver could reflect the divergent versions in the following way (example): pkgver=4.10.2710.0_rpi4.10.2252.0 Can you maybe request collaboration with AUR/chromium-widevine's maintainer to make the necessary changes in that PKGBUILD? That would be the best in my opinion. Thank you for considering my proposal.

1 year, 3 months

Re: [aur-requests] Why were my makepkg forks deleted?

by Caleb Maclennan

Having any recopies on the AUR that blow up systems (such as destroying pacman) even for a few minutes could be considered a few minutes too much. I wasn't involved with the deletion and haven't even looked up who was, but I can easily defend that decision. Packages that broken can and should be removed post-haste and fixed versions discussed and posted later. In this case it looks like you have fixed the sources so it's probably fine to upload them again. You'll notice when you do that you need to pick up with the Git repository where you left off. Also if you still expect this to be deployed only in an environment where `pacman` is not present or that has any other conflicting tooling I suggest adding `conflicts=(pacman)` or similar to block installation on places it does not belong. But also if that is the case you should know that you're pretty deep in a grey area on the AUR where packages are *expected* to make some sense on regular Arch Linux systems even if they are only applicable for certain hardware or environments. Have you been following the aur-general discussions along those lines (e.g. Manjaro, arm platforms, etc) Caleb On 2021-08-01 23:23, Hunter Wittenborn via aur-requests wrote: > As of this morning, it looks like the following packages I'm > maintaining were deleted: > > - makedeb-makepkg > - makedeb-makepkg-beta > - makedeb-makepkg-alpha > > The reasoning for deletion for all three was as follows: > > "this package replace pacman with a empty file" > > This can be seen in the sources for the PKGBUILDs [1], but this was > just a packaging mistake that was left over from the Debian releases of > makepkg [2, 3] that I'm packaging (where pacman wouldn't normally be > present). > > These appear to have been deleted in less than 24 hours of the deletion > request going through, without me even having a chance to be able to > fix anything. > > Is it OK if I republish the packages? I can fix the issue, but I'm not > really sure what I did wrong in the first place that even deemed a > deletion that quickly. > > [1]: https://github.com/makedeb/makepkg/tree/alpha/PKGBUILDs/AUR > [2]: https://github.com/makedeb/makepkg/tree/alpha/PKGBUILDs/MPR > [3]: https://github.com/makedeb/makepkg/tree/alpha/PKGBUILDs/LOCAL > > --- > Hunter Wittenborn > https://www.hunterwittenborn.com > https://github.com/hwittenborn

4 years

[PRQ#54031] Deletion Request for prusa-slicer-git

by notify＠aur.archlinux.org

klickmo [1] filed a deletion request for prusa-slicer-git [2]: I've installed the prusa-slicer-git in my Endeavouros Cassini OS and I can neither use it nor remove it. What else can I do to use or remove it properly? [paul@Kallisto ~]$ git clone https://aur.archlinux.org/prusa-slicer- git.git Klone nach 'prusa-slicer-git'... remote: Enumerating objects: 225, done. remote: Counting objects: 100% (225/225), done. remote: Compressing objects: 100% (186/186), done. remote: Total 225 (delta 41), reused 218 (delta 37), pack-reused 0 Empfange Objekte: 100% (225/225), 80.06 KiB | 1.23 MiB/s, fertig. Löse Unterschiede auf: 100% (41/41), fertig. [paul@Kallisto ~]$ cd prusa-slicer-git [paul@Kallisto prusa-slicer-git]$ ls PKGBUILD [paul@Kallisto prusa-slicer-git]$ makepkg -si ==> Erstelle Paket: prusa-slicer-git 2.6.0.beta4.r1.gdbc2584d8-1 (Lu 19 feb 2024 22:22:27 +0200) ==> Prüfe Laufzeit-Abhängigkeiten... ==> Prüfe Buildtime-Abhängigkeiten... ==> Installiere fehlende Abhängigkeiten... [sudo] Passwort für paul: Abhängigkeiten werden aufgelöst … Nach in Konflikt stehenden Paketen wird gesucht … Paket (4) Neue Version Netto-Veränderung Größe des Downloads extra/compiler-rt 16.0.6-3 36,95 MiB 3,16 MiB extra/clang 16.0.6-2 209,20 MiB 42,43 MiB extra/eigen 3.4.0-2 8,37 MiB 1,05 MiB extra/gtest 1.14.0-1 2,14 MiB 0,46 MiB Gesamtgröße des Downloads: 47,10 MiB Gesamtgröße der installierten Pakete: 256,66 MiB :: Installation fortsetzen? [J/n] J :: Pakete werden empfangen … gtest-1.14.0-1-x... 468,8 KiB 2,74 MiB/s 00:00 [----------------------] 100% eigen-3.4.0-2-any 1077,6 KiB 3,54 MiB/s 00:00 [----------------------] 100% compiler-rt-16.0... 3,2 MiB 1446 KiB/s 00:02 [----------------------] 100% clang-16.0.6-2-x... 42,4 MiB 8,77 MiB/s 00:05 [----------------------] 100% Gesamt (4/4) 47,1 MiB 9,68 MiB/s 00:05 [----------------------] 100% (4/4) Schlüssel im Schlüsselbund werden geprüft [----------------------] 100% (4/4) Paket-Integrität wird überprüft [----------------------] 100% (4/4) Paket-Dateien werden geladen [----------------------] 100% (4/4) Auf Dateikonflikte wird geprüft [----------------------] 100% :: Paketänderungen werden verarbeitet … (1/4) Installiert wird compiler-rt [----------------------] 100% (2/4) Installiert wird clang [----------------------] 100% Optionale Abhängigkeiten für clang openmp: OpenMP support in clang with -fopenmp python: for scan-view and git-clang-format [Installiert] llvm: referenced by some clang headers (3/4) Installiert wird eigen [----------------------] 100% (4/4) Installiert wird gtest [----------------------] 100% Optionale Abhängigkeiten für gtest python: gmock generator [Installiert] :: Post-transaction-Hooks werden gestartet … (1/1) Arming ConditionNeedsUpdate... ==> Empfange Quellen... -> Klone das PrusaSlicer git Repo... Klone in Bare-Repository '/home/paul/prusa-slicer-git/PrusaSlicer' ... remote: Enumerating objects: 263654, done. remote: Counting objects: 100% (2847/2847), done. remote: Compressing objects: 100% (1408/1408), done. remote: Total 263654 (delta 1983), reused 2118 (delta 1435), pack- reused 260807 Empfange Objekte: 100% (263654/263654), 419.56 MiB | 4.77 MiB/s, fertig. Löse Unterschiede auf: 100% (206384/206384), fertig. ==> Überprüfe source Dateien mit sha256sums... PrusaSlicer ... Übersprungen ==> Entpacke Quellen... -> Erstelle Arbeitskopie des PrusaSlicer git Repos... Klone nach 'PrusaSlicer'... Fertig. ==> Beginne prepare()... Schwerwiegend: bad object 72f6a4e7c7dccc47f203ce8c27b3022c6d7743e8 ==> FEHLER: Ein Fehler geschah in prepare(). Breche ab... [paul@Kallisto prusa-slicer-git]$ ls PKGBUILD PrusaSlicer src [paul@Kallisto prusa-slicer-git]$ cd PrusaSlicer [paul@Kallisto PrusaSlicer]$ ls branches config description HEAD hooks info objects packed-refs refs [paul@Kallisto PrusaSlicer]$ cd .. [paul@Kallisto prusa-slicer-git]$ cd .. [paul@Kallisto ~]$ sudo pacman -R prusa-slicer-git Fehler: Ziel nicht gefunden: prusa-slicer-git [paul@Kallisto ~]$ yay -R prusa-slicer-git Fehler: Ziel nicht gefunden: prusa-slicer-git -> exit status 1 [1] https://aur.archlinux.org/account/klickmo/ [2] https://aur.archlinux.org/pkgbase/prusa-slicer-git/

1 year, 5 months

Aur-requests search results for query "arm"