Package Details: plasma-desktop-git 6.0.80_r11524.gf3a8cd50e-1

Git Clone URL: https://aur.archlinux.org/plasma-desktop-git.git (read-only, click to copy)
Package Base: plasma-desktop-git
Description: KDE Plasma Desktop
Upstream URL: https://kde.org/plasma-desktop/
Licenses: LGPL-2.0-or-later
Groups: plasma-git
Conflicts: knetattach, knetattach-git, plasma-desktop, user-manager, user-manager-git
Provides: knetattach, knetattach-git, plasma-desktop, user-manager, user-manager-git
Replaces: knetattach-git, user-manager-git
Submitter: arojas
Maintainer: IslandC0der (chaotic-aur)
Last Packager: IslandC0der
Votes: 9
Popularity: 0.000001
First Submitted: 2014-03-31 06:31 (UTC)
Last Updated: 2024-03-02 13:37 (UTC)

Dependencies (85)

Required by (46)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 Next › Last »

IslandC0der commented on 2021-08-08 01:01 (UTC)

@Neko-san Hmmm, do you get any error message?

Neko-san commented on 2021-08-07 06:41 (UTC)

@IslandC0der And say I try to adapt the script to include other asp packages like this:

#!/usr/bin/env bash

asp update
for dir in */; do (
  cd $dir
  git fetch

  ## If there are upstream changes, apply them, apply ours and rebuild
  if [[ $(git rev-parse master) != $(git rev-parse master@{upstream}) ]]; then
    git reset --hard origin
    ## sed or EOF cat commands go here
    if [ $dir ==  "plasma-desktop" ]; then
      cat << \EOF >> PKGBUILD
      build() {
        cmake -B build -S $pkgname-$pkgver \
          -DCMAKE_INSTALL_LIBEXECDIR=lib \
          -DBUILD_TESTING=OFF \
          -DCMAKE_CXX_COMPILER=clang++ \
          -DCMAKE_C_COMPILER=clang \
          -DUSE_NATIVE_INSTRUCTIONS=ON \
          -DCMAKE_BUILD_TYPE=Release
        sed -i 's/O2/O3/g' "$srcdir/build/CMakeCache.txt"
        sed -i 's/O1/O3/g' "$srcdir/build/CMakeCache.txt"
        sed -i 's/-march=x86-64/-march=native/g' "$srcdir/build/CMakeCache.txt"
        sed -i 's/-mtune=generic/-mtune=native/g' "$srcdir/build/CMakeCache.txt"
        CXXFLAGS+=" -minline-all-stringops -flto=16 -flto-compression-level=19 -fuse-linker-plugin -stdlib=libc++ -lstdc++"
        CFLAGS+=" -minline-all-stringops -flto=16 -flto-compression-level=19 -fuse-linker-plugin"
        cmake --build build -j 16
      }
      EOF

    elif [ $dir == "dolphin-emu" ]; then
      cat << \EOF >> PKGBUILD
      build() {
        cmake -S dolphin-emu -B build \
          -DCMAKE_BUILD_TYPE=Release \
          -DCMAKE_INSTALL_PREFIX=/usr \
          -DUSE_SHARED_ENET=ON \
          -DCMAKE_CXX_COMPILER=clang++ \
            -DCMAKE_C_COMPILER=clang \
          -DUSE_NATIVE_INSTRUCTIONS=ON \
          -DDISTRIBUTOR=archlinux.org
        sed -i 's/O2/O3/g' "$srcdir/build/CMakeCache.txt"
        sed -i 's/O1/O3/g' "$srcdir/build/CMakeCache.txt"
        sed -i 's/-march=x86-64/-march=native/g' "$srcdir/build/CMakeCache.txt"
        sed -i 's/-mtune=generic/-mtune=native/g' "$srcdir/build/CMakeCache.txt"
        CXXFLAGS+=" -minline-all-stringops -flto=16 -fuse-linker-plugin -flto-compression-level=19 -stdlib=libc++ -lstdc++"
        CFLAGS+=" -minline-all-stringops -flto=16 -fuse-linker-plugin -flto-compression-level=19"
        make -j 16 -C build
      }
      EOF

    fi

    cd trunk
    makepkg -srci
  fi
) done

This fails, and I don't understand why?

IslandC0der commented on 2021-08-04 20:46 (UTC) (edited on 2021-08-04 21:01 (UTC) by IslandC0der)

@Neko-san Glad I could help! :D

Anyways, this sed command seems to work:

sed -i -e '/-DBUILD_TESTING=OFF/s/$/ \\/' \
       -e '/-DBUILD_TESTING=OFF/a \
    -DCMAKE_CXX_COMPILER=clang++ \\\
    -DCMAKE_C_COMPILER=clang \\\
    -DUSE_NATIVE_INSTRUCTIONS=ON \\\
    -DCMAKE_BUILD_TYPE=Release\
  sed -i 's/O2/O3/g' "$srcdir/build/CMakeCache.txt"\
  sed -i 's/O1/O3/g' "$srcdir/build/CMakeCache.txt"\
  sed -i 's/-march=x86-64/-march=native/g' "$srcdir/build/CMakeCache.txt"\
  CXXFLAGS+=" -minline-all-stringops -flto=16" -flto-compression-level=19 -fuse-linker-plugin -stdlib=libc++ -lstdc++"\
  CFLAGS+=" -minline-all-stringops -flto=16 -flto-compression-level=19 -fuse-linker-plugin"' \
       -e '/cmake --build build/s/$/ -j 16/' PKGBUILD

EDIT: As you can see, it gets quite complicated. A better option would be to simply append your new build() function to the end of the PKGBUILD, which will override the one that is already there when makepkg sources it:

cat << \EOF >> PKGBUILD
build() {
  cmake -B build -S $pkgname-$pkgver \
    -DCMAKE_INSTALL_LIBEXECDIR=lib \
    -DBUILD_TESTING=OFF \
    -DCMAKE_CXX_COMPILER=clang++ \
    -DCMAKE_C_COMPILER=clang \
    -DUSE_NATIVE_INSTRUCTIONS=ON \
    -DCMAKE_BUILD_TYPE=Release
  sed -i 's/O2/O3/g' "$srcdir/build/CMakeCache.txt"
  sed -i 's/O1/O3/g' "$srcdir/build/CMakeCache.txt"
  sed -i 's/-march=x86-64/-march=native/g' "$srcdir/build/CMakeCache.txt"
  CXXFLAGS+=" -minline-all-stringops -flto=16 -flto-compression-level=19 -fuse-linker-plugin -stdlib=libc++ -lstdc++"
  CFLAGS+=" -minline-all-stringops -flto=16 -flto-compression-level=19 -fuse-linker-plugin"
  cmake --build build -j 16
}
EOF

Neko-san commented on 2021-08-04 18:03 (UTC) (edited on 2021-08-04 19:48 (UTC) by Neko-san)

@IslandC0der Thanks! That's really helpful :D

I had just changed the build function a bit:

build() {
  cmake -B build -S $pkgname-$pkgver \
    -DCMAKE_INSTALL_LIBEXECDIR=lib \
    -DBUILD_TESTING=OFF \
    -DCMAKE_CXX_COMPILER=clang++ \
    -DCMAKE_C_COMPILER=clang \
    -DUSE_NATIVE_INSTRUCTIONS=ON \
    -DCMAKE_BUILD_TYPE=Release
  sed -i 's/O2/O3/g' "$srcdir/build/CMakeCache.txt"
  sed -i 's/O1/O3/g' "$srcdir/build/CMakeCache.txt"
  sed -i 's/-march=x86-64/-march=native/g' "$srcdir/build/CMakeCache.txt"
  CXXFLAGS+=" -minline-all-stringops -flto=16 -flto-compression-level=19 -fuse-linker-plugin -stdlib=libc++ -lstdc++"
  CFLAGS+=" -minline-all-stringops -flto=16 -flto-compression-level=19 -fuse-linker-plugin"
  cmake --build build -j 16
}

And about the git packages, I tend to use an AUR helper (Paru) normally to keep track of updates (it also updates PKGBUILDs in order do the AUR helping); would I have to abandon it in favor of automating the new changes via script? (Since Paru would have no knowledge of this?)

IslandC0der commented on 2021-08-04 14:35 (UTC)

@Neko-san pacman will only update "native" packages (binaries you installed from a repo). In the case of packages you compiled yourself using makepkg (you can see these packages using pacman -Qm), there's no way for pacman to update them, since they aren't being distributed in a repo.

This is also the reason why you couldn't use pacman-key before: pacman can't handle anything related to package building, it only manages binaries.

We will be using 3 distinct tools: asp, makepkg and pacman. You use asp to fetch the PKGBUILDs, makepkg to compile the packages using said PKGBUILDs (turning source code into binaries), and then pacman to install those binaries on your system.

The first step is doing asp checkout $package, which will create a git repo on the asp database, that tracks the arch developers' changes to that PKGBUILD. It will then clone that repo to the folder where it was run.

Then we need to make our changes, and run makepkg -srci: this will install any missing dependencies with pacman (s), build the package, remove unneeded build-time dependencies (r), clean up after it's done (c), and then install the compiled package with pacman (i).

Now let's say there's a new release for the package, and the PKGBUILD gets updated (usually just a version bump). We need to run asp update, to update the asp database of all the PKGBUILDs you are using. However, we can't just run git pull on our PKGBUILD directory to pull these changes from the asp database, because we also made our own changes and git can't reconcile them. So, we git fetch them and then run git reset --hard origin, which will discard our changes and apply the ones from the arch developers.

At this point, we want to automatically add our changes back before we build the new version. If you only modified a few lines, sed will do just fine. If you want some help with this, feel free to send me your changes and I'll provide you with the sed commands for them :)

Adding all of this together, you would run something like this script (you could maybe run it on a schedule or something) in the same folder where you did asp checkout $package:

asp update
for dir in */; do (
  cd $dir
  git fetch

  ## If there are upstream changes, apply them, apply ours and rebuild
  if [[ $(git rev-parse master) != $(git rev-parse master@{upstream}) ]]; then
    git reset --hard origin
    ## sed commands go here
    cd trunk
    makepkg -srci
  fi
) done

Another option would be to simply run asp export $package to get all the PKGBUILDs, make your changes, and then manually do the version bumps every time there's an upstream update, and rebuild.

If you want to use the -git PKGBUILDs instead of the stable ones, it will force you to also compile and install all the corresponding kde -git dependencies whether you want to change them or not, because kde -git packages are generally not compatible with kde stable dependencies. However, you don't have to rebuild them every time there's a new upstream change, since we never do version bumps for -git PKGBUILDs. You would just run makepkg -srci whenever you want to do an update, and the pkgver() function inside the PKGBUILD would take care of doing the version bump. Also, you would no longer use asp (asp checkout $package becomes git clone https://aur.archlinux.org/$package.git, and asp update disappears).

Hope this helps :)

Neko-san commented on 2021-08-04 06:45 (UTC) (edited on 2021-08-04 06:48 (UTC) by Neko-san)

@IslandC0der So... about updating the PKGBUILD, making sure it's up-to-date, and patching it to include what I want... (By the way, I have very little experience with sed and no experience with patch)

Can you explain to me how that can be automated? I imagine that pacman would just update to whatever's newest in the repos on every update that includes a package that's installed this way and do away with it :/

And if I were to change my mind at some point and try this package out, I imagine the dozens of other (conflicting) git packages that need to be installed would have no chance of being automated the same way? (As I imagine that would be a big deal given the frequency of changes to AUR git packages)

Neko-san commented on 2021-08-03 07:23 (UTC) (edited on 2021-08-03 17:15 (UTC) by Neko-san)

@IslandC0der Ooo! That's cool

Unfortunately though... attempting to use the PKGBUILD as a result of that as guided me down to the path of PGP key hell x_x

Every time I've ever had this problem with the AUR, I've never been able to solve it even after trying seemingly everything I can after reading how to import and sign them...

EDIT: Nevermind, I was unaware that keys had to be imported for the user and not with pacman-key as but with just gpg; I find this strange because makepkg only runs with sudo privileges so this just seems backwards to me but at least I understand how it works now Lol; thanks, by the way

IslandC0der commented on 2021-08-03 00:50 (UTC) (edited on 2021-08-03 01:03 (UTC) by IslandC0der)

@Neko-san

What you're trying to accomplish is exactly what asp was made for :)

By running asp checkout $package, you can fetch the official PKGBUILD which is used to build that package on the arch repos, and then make any changes you like and compile it

You could even make a script that runs asp update && git fetch && git reset --hard origin to update the PKGBUILD every time there's a new release, and then automatically add your changes (for example, using sed or patch)

Let me know if you need any further help :)

Neko-san commented on 2021-08-01 06:15 (UTC) (edited on 2021-08-01 06:15 (UTC) by Neko-san)

@IslandC0der

I think providing an AUR package for Plasma is great, however given that doing so straight from git means that it's always in need of an "update" so to speak, would it be alright to ask if a "release" AUR option was available so it can be "-03" optimized and compiled with Clang?

I think the normal package(s) available in the repos is fine, but I was interested in optimizing Plasma as hard as possible without going too-too far, but I don't want to be even further on the razor's edge than what's in latest releases Lol

IslandC0der commented on 2020-11-17 22:19 (UTC)

Ahhh what an oversight, thank you

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 Next › Last »