Package for Mobian/Debian/Devuan in the official Debian repository

[EmanuelLoos]

A package in the official Debian repository adds some trust to software, because the package has to meet the DFSG and has to come with a Debian source package the user can build and install easily.

It also

• makes the software findable using apt search <search_term>
• handles dependencies nicely
• installs the software natively

[Schmiddiii]

I think this app already meet the DFSG you linked. As I do not know how to package for Debian (and do not use it), any help packaging would be appreciated.

[EmanuelLoos]

From my understanding, it works like this:
There are RFPs (Requests for Packaging), one can be opened and someone might eventually package the software.
There are IFPs (Intentions for Packaging), you can open one if you decide to package something yourself.
For a software to be packaged for the official repositories all dependencies must be in it first.
Debian avoids code copying, dependencies must be packaged separately. This way they could always be used efficiently by other packages.
Dependencies that are only needed for building must as well be in Debian before packaging the software and meet all requirements (like the DFSG).
Submitted packages are checked by the Debian QA team before being included which takes time.
There are mailing lists if you need help.

I never packaged any software for anything, but I think these resources might be helpful:
Debian Social Contract
HowToPackageForDebian
Introduction for maintainers: How will my package get into Debian?
Debian New Maintainers' Guide

Regarding Rust packaging I found only information on how to package "crates" from crates.io which worried me. I asked a few questions on the mailing list and got an answer:
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-February/018521.html

PS: I am curious: What do you prefer over Debian/Devuan?

[Schmiddiii]

Sounds interesting, but as I do not use any Debian-based distributions (I use Arch on my PinePhone, Arco-Linux on my laptop and Manjaro on my desktop) and as the flatpak should already run fine on mentioned distributions, I see no reason for me to work on this. If you or someone else is willing to:

• Read about Debian packaging (you already seemed to have done that)
• Open a RFP
• Assisting in the creation of the package (I will help there if needed, e.g. needed dependencies)
• Maintaining the package (I will inform about needed changes)

I will give the person the permission (I do not know if he really needs it, but just to make sure) to package and redistribute it.

Regarding Rust packaging, this project is a "crate" (basically a fancy name for a Rust-project), but not on crates.io, as this is almost exclusively used for libraries (there are some binaries over there, but these mostly assist in Rust-development and are not intended for consumers).

[hwittenborn]

@Schmiddiii: Since you use Arch Linux, makedeb could probably work quite well, as it uses the same PKGBUILD format seen for their packaging format.

If need be, I could help maintain the package as well. Regarding distribution, it wouldn't work for the native Debian and Ubuntu repos, but you could add it to releases or the MPR, an AUR-like platform for makedeb.

[Schmiddiii]

Seems to be worth looking into, but as I currently do not even have (or know how to make) a Arch-PKGBUILD this will take some time. I do not know whether I will have the time to do that in the next few weeks but I will play around with it a little bit.

[EmanuelLoos]

@hwittenborn: Thank you for offering your help, but your proposed solution is not really what I was looking for when creating this issue:

it wouldn't work for the native Debian and Ubuntu repos

I would very much prefer the official (native) package repositories. Debian has high requirements and a QA (quality assurance) team. With official Debian packages, one can be quite sure that everything is legal and also does not include any malware. Dependencies are resolved automatically (installing packages from the repository made for exactly the version of Debian/Devuan/Mobian that is installed). Dependencies are separate packages avoiding usage of more disk space as would be needed and usage of more CPU power. This also gives the user the possibility to choose which package to use if Tubefeeder could either use this or that package as a dependency.

An installable package is not so hard to create but without the metadata a package can carry within it I do not see that much of a benefit over just using binaries, the package pretty much would miss the benefits of an official Debian package. In fact new users of Debian are advised to not create FrankenDebian.

The MPR says in the guide to installing packages:

Verify that the package and any other used files don’t contain malicious (or otherwise untrustworthy) code or links.

Having the user check if the software is okay does not seem to be a very promising solution to me. A user might not even be able to understand the source code.

[hwittenborn]

An installable package is not so hard to create but without the metadata a package can carry within it I do not see that much of a benefit over just using binaries

Using makedeb would still have package metadata, at least in the sense of that in a standard Debian package, as the packages made from makedeb are still Debian packages themselves.

In fact new users of Debian are advised to not create FrankenDebian.

That's a fair argument, though I've found a fair amount of people do prefer their users to always have the latest versions of packages. I'd care to argue that as long as you aren't using core system packages, a users system should be pretty much as stable as it was before installing the new packages.

I appreciate the thoughts though! I know makedeb won't work for everyone, but I'd thought I'd just propose it and see what would happen :)

[EmanuelLoos]

It is never bad to propose something, your proposal is just different from what I would consider a well done solution for this issue. However, it might even be a first step: Does makedeb create separate packages for each dependency?

[hwittenborn]

Does makedeb create separate packages for each dependency?

It can if you so choose to - you'd need to package each dependency separately, though nothing is stopping you from doing so with makedeb. Pretty much everything you can do with standard Debian packaging you can currently do with makedeb (there's a few tiny limitations rn, though nothing related to your issue of creating separate packages for dependencies).

[Schmiddiii]

[...], your proposal is just different from what I would consider a well done solution for this issue.

I can understand that this might not be the most optimal solution, but it is probably still the best solution until the day someone comes along and packages the application for Debian in the official way. I will certainly not be this person as I do not use any Debian-based distributions. Futhermore, I do not think anyone will package this the official way any time soon as I am still the only contributor to the application (apart from recently added italic translation).

Using makedeb would enable me to provide Debian-packaging for free (with maybe some minor package renaming in the PKGBUILD) once I packaged it for Arch (something I already wanted to learn some day).

Dependencies are resolved automatically (installing packages from the repository made for exactly the version of Debian/Devuan/Mobian that is installed). Dependencies are separate packages avoiding usage of more disk space as would be needed and usage of more CPU power. This also gives the user the possibility to choose which package to use if Tubefeeder could either use this or that package as a dependency.

As far as I understood (@hwittenborn correct me if I am wrong), makedeb just builds a .deb-file. As Debian-packaging is basically just .deb files stored on some server, the capabilities of makedeb and official packages are equivalent (apart from previously mentioned tiny limitations that are probably not important in my simple package). Official packaging just adds the convenience-factor that one does not have to build the package himself and maybe minor security benefits.

All in all, official Debian-packaging would still be preferable, but as this is probably not going to happen any time soon and makedeb is basically free (as in no work at all), I would definitly say makedeb is worth a try.

P.S.: @hwittenborn would it maybe be possible for makedeb to generate a package that can be accepted by the Debian repositories or do the repositories need a different file format? I know too little about Debian and packaging to answer this question.

[hwittenborn]

Yes, makedeb just makes .deb files @Schmiddiii.

Official packaging just adds the convenience-factor that one does not have to build the package himself and maybe minor security benefits.

More or less, though creating an official Debian package from source would still involve building. In practice you can still do the build step yourself or something and then still distribute the .deb file like you would a normal package (except for into the official Debian/Ubuntu repos, as mentioned below).

would it maybe be possible for makedeb to generate a package that can be accepted by the Debian repositories or do the repositories need a different file format?

You would not, as Debian repository packages require a source package. The end result that both makedeb and standard Debian packaging creates is a binary package. The former is meant for building, while the latter is what's actually installable.

The underlying philosophy of makedeb is to try to avoid that Debian source package format though, as I saw it as a bit verbose in the amount of configuration required to set up and maintain one. So that ends in packages that can't be uploaded to Debian, though the maintainability of the makedeb-based source package is arguably more maintainable imo.

[Schmiddiii]

@hwittenborn There is now a PKGBUILD in the AUR, both for git and stable. Feel free to use those to package tubefeeder in the MPR.

• https://aur.archlinux.org/packages/tubefeeder
• https://aur.archlinux.org/packages/tubefeeder-git

I do not have that much experience in packaging using PKGBUILDs so my results might be suboptimal.

[hwittenborn]

Looks great @Schmiddiii, I'll see what I can do

[mickenordin]

This is a PKGBUILD-file that I got working with makedeb (just slightly modified from the original)

# Maintainer: Julian Schmidhuber <aur at schmiddi dot anonaddy dot com>
pkgname=tubefeeder
pkgver=1.6.6.r2.6151151
pkgrel=1
pkgdesc="A Youtube, Lbry and Peertube client made for the Pinephone"
arch=('amd64' 'arm64')
url="https://www.tubefeeder.de"
license=('GPL')
groups=()
depends=('libadwaita-1-0' 'libadwaita-1-dev')
optdepends=('mpv: Play the videos', 'youtube-dl: Play and download the videos')
makedepends=('git' 'cargo' 'libxml2-utils')
provides=("${pkgname}")
conflicts=("${pkgname}")
replaces=()
backup=()
options=()
install=
source=("$pkgname::git+https://github.com/Tubefeeder/Tubefeeder.git")
noextract=()
md5sums=('SKIP')

pkgver() {
        echo ${pkgver}  
}

prepare() {
        cd "$srcdir/${pkgname}"
        cargo fetch --locked --target "$CARCH-unknown-linux-gnu"
}

build() {
        cd "$srcdir/${pkgname}"
        export RUSTUP_TOOLCHAIN=stable
        export CARGO_TARGET_DIR=target
        cargo build --frozen --release --all-features
}

package() {
        cd "$srcdir/${pkgname}"
        # Binary
        install -Dm0755 -t "$pkgdir/usr/bin/" "target/release/tubefeeder"
        # Desktop-file
        sed -i 's_/app/bin/tubefeeder_/usr/bin/tubefeeder_' packaging/tubefeeder.desktop
        install -D packaging/tubefeeder.desktop $pkgdir/usr/share/applications/de.schmidhuberj.tubefeeder.desktop
        # Icon
        install -D packaging/tubefeeder.png $pkgdir/usr/share/icons/hicolor/512x512/apps/de.schmidhuberj.tubefeeder.png

        # Localization
        ls -ld po/locale/*/ | sed 's|.*po/locale/||' | xargs -I % install -D "po/locale/%LC_MESSAGES/de.schmidhuberj.tubefeeder.mo" "$pkgdir/usr/share/locale/%LC_MESSAGES/de.schmidhuberj.tubefeeder.mo"
}

[Schmiddiii]

Looks good for my (pretty untrained) eye. Just some minor things:

• You named the package tubefeeder, but as you are building from git, should it not be tubefeeder-git (naming conventions might differ from the AUR and MPR so not sure).
• echo ${pkgver}: What was written there before was supposed to generate the pkgver as far as I understood, but not really detremental to the packaging.
• # Maintainer: Julian Schmidhuber <aur at schmiddi dot anonaddy dot com> if one wants to publish this to the MPR, I would probably not be the maintainer but the person publishing it, but this again does not change the build process.
• sed -i 's_/app/bin/tubefeeder_/usr/bin/tubefeeder_' packaging/tubefeeder.desktop: Nice that you spotted it, this was missing from my PKGBUILD. I just added it.

Otherwise this looks good for me. If you want, you may publish this to the MPR after fixing (but you do not have to if you do not want).

[mickenordin]

There is still some work to do. The PKGBUILD works on my debian testing install on amd64, but not on my pinephone or pinephone pro. But it seems related to something rusty, I get this backtrace when buildning from the 1.6.6 release:

error: failed to run custom build command for `tubefeeder v1.6.6 (/home/mobian/src/tubefeeder/src/Tubefeeder-1.6.6)`

Caused by:
  process didn't exit successfully: `/home/mobian/src/tubefeeder/src/Tubefeeder-1.6.6/target/release/build/tubefeeder-e9a32f5be1447cc7/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=resources.gresource.xml
  cargo:rerun-if-changed=ui
  cargo:rerun-if-changed=po

  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', build.rs:37:18
  stack backtrace:
     0:     0xaaaabb399ec4 - std::backtrace_rs::backtrace::libunwind::trace::h129e00118d9f766e
                                 at /usr/src/rustc-1.58.1/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
     1:     0xaaaabb399ec4 - std::backtrace_rs::backtrace::trace_unsynchronized::h50b6efba3d9d4c8d
                                 at /usr/src/rustc-1.58.1/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
     2:     0xaaaabb399ec4 - std::sys_common::backtrace::_print_fmt::he0eae45d1a016f50
                                 at /usr/src/rustc-1.58.1/library/std/src/sys_common/backtrace.rs:67:5
     3:     0xaaaabb399ec4 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hc06868b45e2c4bb4
                                 at /usr/src/rustc-1.58.1/library/std/src/sys_common/backtrace.rs:46:22
     4:     0xaaaabb3be680 - core::fmt::write::hcdedbc05e38a6115
                                 at /usr/src/rustc-1.58.1/library/core/src/fmt/mod.rs:1149:17
     5:     0xaaaabb38f344 - std::io::Write::write_fmt::h06c74556923038e0
                                 at /usr/src/rustc-1.58.1/library/std/src/io/mod.rs:1697:15
     6:     0xaaaabb390a70 - std::sys_common::backtrace::_print::h05be5f3575c807ce
                                 at /usr/src/rustc-1.58.1/library/std/src/sys_common/backtrace.rs:49:5
     7:     0xaaaabb390a70 - std::sys_common::backtrace::print::he4fdcc4533b8f81a
                                 at /usr/src/rustc-1.58.1/library/std/src/sys_common/backtrace.rs:36:9
     8:     0xaaaabb390a70 - std::panicking::default_hook::{{closure}}::h3b8cca7a0570392b
                                 at /usr/src/rustc-1.58.1/library/std/src/panicking.rs:211:50
     9:     0xaaaabb3905f4 - std::panicking::default_hook::he1775adaac99ae80
                                 at /usr/src/rustc-1.58.1/library/std/src/panicking.rs:228:9
    10:     0xaaaabb390fd8 - std::panicking::rust_panic_with_hook::h9838d954e44ff636
                                 at /usr/src/rustc-1.58.1/library/std/src/panicking.rs:606:17
    11:     0xaaaabb39a7b0 - std::panicking::begin_panic_handler::{{closure}}::ha0117cb8d4163170
                                 at /usr/src/rustc-1.58.1/library/std/src/panicking.rs:502:13
    12:     0xaaaabb399fe8 - std::sys_common::backtrace::__rust_end_short_backtrace::h6797a3541ca4c7de
                                 at /usr/src/rustc-1.58.1/library/std/src/sys_common/backtrace.rs:139:18
    13:     0xaaaabb390b60 - rust_begin_unwind
                                 at /usr/src/rustc-1.58.1/library/std/src/panicking.rs:498:5
    14:     0xaaaabb387d6c - core::panicking::panic_fmt::hff0da6549cd2d2ce
                                 at /usr/src/rustc-1.58.1/library/core/src/panicking.rs:107:14
    15:     0xaaaabb387bc8 - core::result::unwrap_failed::hc5fdafff3b413bac
                                 at /usr/src/rustc-1.58.1/library/core/src/result.rs:1613:5
    16:     0xaaaabb38c478 - core::result::Result<T,E>::unwrap::h32a9e0a3c36c8767
    17:     0xaaaabb38a820 - build_script_build::main::h680b5d656203f574
    18:     0xaaaabb38b274 - core::ops::function::FnOnce::call_once::h84603523d2b2c1c6
    19:     0xaaaabb38cf7c - std::sys_common::backtrace::__rust_begin_short_backtrace::h3ed4f376dddb5f79
    20:     0xaaaabb38c698 - std::rt::lang_start::{{closure}}::h8ca9fa8a82d665c3
    21:     0xaaaabb38df50 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hc7be548fe023abb1
                                 at /usr/src/rustc-1.58.1/library/core/src/ops/function.rs:259:13
    22:     0xaaaabb38df50 - std::panicking::try::do_call::he1bbc547dfe16af2
                                 at /usr/src/rustc-1.58.1/library/std/src/panicking.rs:406:40
    23:     0xaaaabb38df50 - std::panicking::try::h16e067a9ec6d7888
                                 at /usr/src/rustc-1.58.1/library/std/src/panicking.rs:370:19
    24:     0xaaaabb38df50 - std::panic::catch_unwind::h6bba0d79af97d0b8
                                 at /usr/src/rustc-1.58.1/library/std/src/panic.rs:133:14
    25:     0xaaaabb38df50 - std::rt::lang_start_internal::{{closure}}::h03c14055a7f6ce5d
                                 at /usr/src/rustc-1.58.1/library/std/src/rt.rs:128:48
    26:     0xaaaabb38df50 - std::panicking::try::do_call::h44dbafd4d68c4f63
                                 at /usr/src/rustc-1.58.1/library/std/src/panicking.rs:406:40
    27:     0xaaaabb38df50 - std::panicking::try::h62036b9eb365e42e
                                 at /usr/src/rustc-1.58.1/library/std/src/panicking.rs:370:19
    28:     0xaaaabb38df50 - std::panic::catch_unwind::h3f0248700651f43b
                                 at /usr/src/rustc-1.58.1/library/std/src/panic.rs:133:14
    29:     0xaaaabb38df50 - std::rt::lang_start_internal::heff6f8e7e4ffb6dc
                                 at /usr/src/rustc-1.58.1/library/std/src/rt.rs:128:20
    30:     0xaaaabb38c674 - std::rt::lang_start::h47649d54108bc5e5
    31:     0xaaaabb38a868 - main
    32:     0xffff94ce4614 - __libc_start_main
    33:     0xaaaabb388178 - _start
    34:                0x0 - <unknown>
warning: build failed, waiting for other jobs to finish...
error: build failed
[!] A failure occurred in build().
    Aborting...

Is that something you recognize?

The PKGBUILD I used look like this now:

# Maintainer: Julian Schmidhuber <aur at schmiddi dot anonaddy dot com>
pkgname=tubefeeder
pkgver=1.6.6
pkgrel=2
pkgdesc="A Youtube, Lbry and Peertube client made for the Pinephone"
arch=('amd64' 'arm64')
url="https://www.tubefeeder.de"
license=('GPL')
groups=()
depends=('libadwaita-1-0' 'libadwaita-1-dev')
optdepends=('mpv: Play the videos', 'youtube-dl: Play and download the videos')
makedepends=('cargo' 'libxml2-utils')
provides=("${pkgname}")
conflicts=("${pkgname}")
replaces=()
backup=()
options=()
install=
source=("$pkgname.tar.gz::https://github.com/Schmiddiii/Tubefeeder/archive/refs/tags/v$pkgver.tar.gz")
noextract=()
md5sums=('1ac142037f2044b93496026785821f5f')

prepare() {
        cd "$srcdir/Tubefeeder-${pkgver}"
        cargo fetch --locked --target "$CARCH-unknown-linux-gnu"
}

build() {
        cd "$srcdir/Tubefeeder-${pkgver}"
        export RUSTUP_TOOLCHAIN=stable
        export CARGO_TARGET_DIR=target
        cargo build --frozen --release --all-features
}

package() {
        cd "$srcdir/Tubefeeder-${pkgver}"
        # Binary
        install -Dm0755 -t "$pkgdir/usr/bin/" "target/release/tubefeeder"
        # Desktop-file
        sed -i 's_/app/bin/tubefeeder_/usr/bin/tubefeeder_' packaging/tubefeeder.desktop
        install -D packaging/tubefeeder.desktop $pkgdir/usr/share/applications/de.schmidhuberj.tubefeeder.desktop
        # Icon
        install -D packaging/tubefeeder.png $pkgdir/usr/share/icons/hicolor/512x512/apps/de.schmidhuberj.tubefeeder.png

        # Localization
        ls -ld po/locale/*/ | sed 's|.*po/locale/||' | xargs -I % install -D "po/locale/%LC_MESSAGES/de.schmidhuberj.tubefeeder.mo" "$pkgdir/usr/share/locale/%LC_MESSAGES/de.schmidhuberj.tubefeeder.mo"
}

Same thing happens with the other PKGBUILD

[Schmiddiii]

Seems like a failure in the build.rs? Do you have the command glib-compile-resources available? The command is needed to build gtk related things and is (as far as I know) inside a indirect dependency of libadwaita-dev for Arch, but I do not know about Debian.

Similar to glib-compile-resources, msgfmt also needs to be available for internationalization.

P.S.: Note that it will take a long time (probably hours) to compile Tubefeeder on the PP because of its very weak hardware.

[hwittenborn]

You named the package tubefeeder, but as you are building from git, should it not be tubefeeder-git

That's true, the MPR does use pretty much the same naming convention as the AUR. If it's compiling from the latest git tag, the you should suffix the pkgname with -git.

[mickenordin]

It seems crosscompiling is not a thing with makedeb(?), so I am building on the ppp.

msgfmt is in a package called gettext in debian, and that was missing as well as libssl-dev.

I now have some issue with building ring which is a dependency through something else. I will see if I can get that sorted, do you have any input regarding cross-compiling @hwittenborn?

[hwittenborn]

do you have any input regarding cross-compiling @hwittenborn?

What do you mean by cross compiling? I'm not too familiar with the term myself.

[mickenordin]

do you have any input regarding cross-compiling @hwittenborn?

What do you mean by cross compiling? I'm not too familiar with the term myself.

It should be possible to build tubefeeder on a machine running a amd64 processor for the arm64 cpu used on the pinephone. Building a binary for another architecture than the one used on the host machine is called "cross compiling".

When I run makedeb it will produce a package for the architecture of my host machine, rather than for all architectures specified in the arch array in th PKGBUILD. That is what I mean when I say that makedeb doesn't handle cross compilation. If it did, I would expect a package with arch=('amd64' 'arm64') in the PKGBUILD to produce two .deb-files, one for amd64 and one for arm64.

[Schmiddiii]

I personally think cross-compiling Tubefeeder is mostly infeasible because of the many dependencies. See #46 for more information. I would just recommend just using Flatpak instead of cross-compiling (or compiling on PPP may also be feasible depending on its processor, or maybe use virtual machines, but this is probably not a lot faster than the PP).

Can you also share the problem you have with ring if you still have problems?

[hwittenborn]

I didn't think of that, makedeb doesn't currently support that, no. The main purpose of arch is to say what architectures are allowed for a build, but that's it.

This is definitely something I think should be supported though. It shouldn't be too much to add, and I can add support for it later today.

I'm not sure if it'll work right now as I haven't tested today, but you might be able to override the ${CARCH} variable in your environment to set that in your build() function. The architecture variable for the stuff in arch, ${MAKEDEB_DPKG_ARCHITECTURE}, can't currently be overwritten though.

I'm not sure if CARCH is set for builds either anymore, but I can get that checked later when I get home.

[Schmiddiii]

This is definitely something I think should be supported though. It shouldn't be too much to add, and I can add support for it later today.

I think you underestimate how hard cross-compiling can be. The best somewhat-reliable way is to start a virtual machine using qemu, and that (to my knowledge) is not that easy. I do not know how makepkg handles it, but I always found cross-compiling pretty hard.

If you want to feel the pain of cross-compiling, just try to cross compile Tubefeeder (and please consider sharing results if you found a easy way as I was searching for many hours for a good solution until I gave up).

[hwittenborn]

Does setting that CARCH variable not work @Schmiddiii? I can try some stuff when I get home as well though.

[Schmiddiii]

I was speaking about general cross compilation beeing hard.

Regarding Arch, the man-page specifies that CMAKE only takes i686 or x86_64 so I honestly do not have an idea how this works for aarch64. And even if something like that works for other distributions, the cross compilation would likely take place in qemu, which is in my experience on a ok-ish laptop not really faster than the PP. The main hard thing is making cross-compilation have an acceptable speed, which I already failed to do many times.

But you should not be stopped by me if you want to implement cross-compilation for makedeb, I just wanted to make clear that I had a hard time cross-compiling Tubefeeder efficiently and would not consider trying it again.

[mickenordin]

Can you also share the problem you have with ring if you still have problems?

Sure, this is the error message I get now:

error: failed to run custom build command for `ring v0.16.20`

Caused by:
  process didn't exit successfully: `/home/mobian/src/tubefeeder/src/Tubefeeder-1.6.6/target/release/build/ring-e602e52d481900e8/build-script-build` (exit status: 101)
  --- stdout
  OPT_LEVEL = Some("3")
  TARGET = Some("aarch64-unknown-linux-gnu")
  HOST = Some("aarch64-unknown-linux-gnu")
  CC_aarch64-unknown-linux-gnu = None
  CC_aarch64_unknown_linux_gnu = None
  HOST_CC = None
  CC = None
  CFLAGS_aarch64-unknown-linux-gnu = None
  CFLAGS_aarch64_unknown_linux_gnu = None
  HOST_CFLAGS = None
  CFLAGS = Some("-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection")
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("false")
  CARGO_CFG_TARGET_FEATURE = None

  --- stderr
  running "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-march=x86-64" "-mtune=generic" "-O2" "-pipe" "-fno-plt" "-fexceptions" "-Wp,-D_FORTIFY_SOURCE=2" "-Wformat" "-Werror=format-security" "-fstack-clash-protection" "-fcf-protection" "-I" "include" "-pedantic" "-pedantic-errors" "-Wall" "-Wextra" "-Wcast-align" "-Wcast-qual" "-Wconversion" "-Wenum-compare" "-Wfloat-equal" "-Wformat=2" "-Winline" "-Winvalid-pch" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wsign-conversion" "-Wundef" "-Wuninitialized" "-Wwrite-strings" "-fno-strict-aliasing" "-fvisibility=hidden" "-fstack-protector" "-g3" "-DNDEBUG" "-c" "-o/home/mobian/src/tubefeeder/src/Tubefeeder-1.6.6/target/release/build/ring-ccfc52d9df21f3fa/out/aesv8-armx-linux64.o" "/home/mobian/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/pregenerated/aesv8-armx-linux64.S"
  cc1: error: unknown value ‘x86-64’ for ‘-march’
  cc1: note: valid arguments are: armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a armv8.6-a armv8-r native
  cc1: error: ‘-fcf-protection=full’ is not supported for this target
  Assembler messages:
  Error: unknown architecture `x86-64'

  Error: unrecognized option -march=x86-64
  thread 'main' panicked at 'execution failed', /home/mobian/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/build.rs:656:9
  stack backtrace:
     0:     0xaaaac312c688 - std::backtrace_rs::backtrace::libunwind::trace::h129e00118d9f766e
                                 at /usr/src/rustc-1.58.1/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
     1:     0xaaaac312c688 - std::backtrace_rs::backtrace::trace_unsynchronized::h50b6efba3d9d4c8d
                                 at /usr/src/rustc-1.58.1/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
     2:     0xaaaac312c688 - std::sys_common::backtrace::_print_fmt::he0eae45d1a016f50
                                 at /usr/src/rustc-1.58.1/library/std/src/sys_common/backtrace.rs:67:5
     3:     0xaaaac312c688 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hc06868b45e2c4bb4
                                 at /usr/src/rustc-1.58.1/library/std/src/sys_common/backtrace.rs:46:22
     4:     0xaaaac3153bbc - core::fmt::write::hcdedbc05e38a6115
                                 at /usr/src/rustc-1.58.1/library/core/src/fmt/mod.rs:1149:17
     5:     0xaaaac31207e8 - std::io::Write::write_fmt::h06c74556923038e0
                                 at /usr/src/rustc-1.58.1/library/std/src/io/mod.rs:1697:15
     6:     0xaaaac3122b2c - std::sys_common::backtrace::_print::h05be5f3575c807ce
                                 at /usr/src/rustc-1.58.1/library/std/src/sys_common/backtrace.rs:49:5
     7:     0xaaaac3122b2c - std::sys_common::backtrace::print::he4fdcc4533b8f81a
                                 at /usr/src/rustc-1.58.1/library/std/src/sys_common/backtrace.rs:36:9
     8:     0xaaaac3122b2c - std::panicking::default_hook::{{closure}}::h3b8cca7a0570392b
                                 at /usr/src/rustc-1.58.1/library/std/src/panicking.rs:211:50
     9:     0xaaaac31226b0 - std::panicking::default_hook::he1775adaac99ae80
                                 at /usr/src/rustc-1.58.1/library/std/src/panicking.rs:228:9
    10:     0xaaaac3123094 - std::panicking::rust_panic_with_hook::h9838d954e44ff636
                                 at /usr/src/rustc-1.58.1/library/std/src/panicking.rs:606:17
    11:     0xaaaac31076a4 - std::panicking::begin_panic::{{closure}}::hc475e1a13698ae48
    12:     0xaaaac3108c14 - std::sys_common::backtrace::__rust_end_short_backtrace::hc22253593bd6146c
    13:     0xaaaac3107604 - std::panicking::begin_panic::h16c30b87d1807425
    14:     0xaaaac30c1cb8 - build_script_build::run_command::hefb35c36250526bb
    15:     0xaaaac30c0dd8 - build_script_build::compile::hdb6c4b29dd9295d3
    16:     0xaaaac30c0a28 - build_script_build::build_library::{{closure}}::h0902fa92d6b61ded
    17:     0xaaaac30bebd4 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once::hd71a9a818f1118b8
    18:     0xaaaac30c4750 - core::option::Option<T>::map::h86d0abe7964ac609
    19:     0xaaaac30c7d58 - <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::next::h73d0282c86f68f57
    20:     0xaaaac30bc998 - <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter::h426a3093785ace3e
    21:     0xaaaac30be9e8 - <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter::ha31c3a5b926325de
    22:     0xaaaac30be4a8 - <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter::h59254fe6d726dd19
    23:     0xaaaac30c8264 - core::iter::traits::iterator::Iterator::collect::h304c841a80ff6fbd
    24:     0xaaaac30c0430 - build_script_build::build_library::h4d3b93fb9fc8ad5d
    25:     0xaaaac30c0234 - build_script_build::build_c_code::{{closure}}::hc785c7456688dd79
    26:     0xaaaac30c7760 - <core::slice::iter::Iter<T> as core::iter::traits::iterator::Iterator>::for_each::hf38f2484d4a4b14d
    27:     0xaaaac30bff60 - build_script_build::build_c_code::hb357383e956929c9
    28:     0xaaaac30bf2f4 - build_script_build::ring_build_rs_main::ha0f376a0536fe75c
    29:     0xaaaac30bed80 - build_script_build::main::hb8be7f1923118964
    30:     0xaaaac30cca9c - core::ops::function::FnOnce::call_once::h97dea20b209a057c
    31:     0xaaaac30c34d4 - std::sys_common::backtrace::__rust_begin_short_backtrace::hb255864fd5ff5df1
    32:     0xaaaac30cc824 - std::rt::lang_start::{{closure}}::h4d5f1e280c4bf82d
    33:     0xaaaac311ee7c - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hc7be548fe023abb1
                                 at /usr/src/rustc-1.58.1/library/core/src/ops/function.rs:259:13
    34:     0xaaaac311ee7c - std::panicking::try::do_call::he1bbc547dfe16af2
                                 at /usr/src/rustc-1.58.1/library/std/src/panicking.rs:406:40
    35:     0xaaaac311ee7c - std::panicking::try::h16e067a9ec6d7888
                                 at /usr/src/rustc-1.58.1/library/std/src/panicking.rs:370:19
    36:     0xaaaac311ee7c - std::panic::catch_unwind::h6bba0d79af97d0b8
                                 at /usr/src/rustc-1.58.1/library/std/src/panic.rs:133:14
    37:     0xaaaac311ee7c - std::rt::lang_start_internal::{{closure}}::h03c14055a7f6ce5d
                                 at /usr/src/rustc-1.58.1/library/std/src/rt.rs:128:48
    38:     0xaaaac311ee7c - std::panicking::try::do_call::h44dbafd4d68c4f63
                                 at /usr/src/rustc-1.58.1/library/std/src/panicking.rs:406:40
    39:     0xaaaac311ee7c - std::panicking::try::h62036b9eb365e42e
                                 at /usr/src/rustc-1.58.1/library/std/src/panicking.rs:370:19
    40:     0xaaaac311ee7c - std::panic::catch_unwind::h3f0248700651f43b
                                 at /usr/src/rustc-1.58.1/library/std/src/panic.rs:133:14
    41:     0xaaaac311ee7c - std::rt::lang_start_internal::heff6f8e7e4ffb6dc
                                 at /usr/src/rustc-1.58.1/library/std/src/rt.rs:128:20
    42:     0xaaaac30cc800 - std::rt::lang_start::h0f5c02928f47173a
    43:     0xaaaac30c3484 - main
    44:     0xffffa9feb614 - __libc_start_main
    45:     0xaaaac30bc6b8 - _start
    46:                0x0 - <unknown>
warning: build failed, waiting for other jobs to finish...
error: build failed
[!] A failure occurred in build().
    Aborting...

[Schmiddiii]

Weird that CFLAGS is set? Did you set it somewhere as it should not be set I think.

And also very weird that x86_64 is mentioned in those flags.

Maybe try to unset this? But I am not sure this will work as I have not seen this one yet.

[mickenordin]

Yes, something is weird. It seems rings build.rs sets CFLAGS

[mickenordin]

Yes, something is weird. It seems rings build.rs sets CFLAGS

Yes, there is a bug on line 220 in build.rs for ring. If I remove:

("x86_64", None, Some("elf")),

It will correctly find the aarch64 entries and set CFLAGS correctly

[Schmiddiii]

Very weird indeed. Probably a detailed bug report to their repo would be good.

Have you tried compiling just ring without Tubefeeder? I can compile just ring on my PP just fine.

[mickenordin]

Very weird indeed. Probably a detailed bug report to their repo would be good.

briansmith/ring#1497

Have you tried compiling just ring without Tubefeeder? I can compile just ring on my PP just fine.

I can compile the whole thing if I fix ring. So yes, it works for me now :).

This is the PKGBUILD that worked for me:

pkgname=tubefeeder
pkgver=1.6.6
pkgrel=2
pkgdesc="A Youtube, Lbry and Peertube client made for the Pinephone"
arch=('arm64')
url="https://www.tubefeeder.de"
license=('GPL')
groups=()
depends=('libadwaita-1-0' 'libadwaita-1-dev' 'libssl-dev')
optdepends=('mpv: Play the videos', 'youtube-dl: Play and download the videos')
makedepends=('cargo' 'libxml2-utils' 'gettext' 'musl-tools' 'librust-ring-dev')
provides=("${pkgname}")
conflicts=("${pkgname}")
replaces=()
backup=()
options=()
install=
source=("$pkgname.tar.gz::https://github.com/Schmiddiii/Tubefeeder/archive/refs/tags/v$pkgver.tar.gz")
noextract=()
md5sums=('1ac142037f2044b93496026785821f5f')

prepare() {
        cd "$srcdir/Tubefeeder-${pkgver}"
        cargo fetch --locked --target "$CARCH-unknown-linux-gnu"
}

build() {
        cd "$srcdir/Tubefeeder-${pkgver}"
        export RUSTUP_TOOLCHAIN=stable
        export CARGO_TARGET_DIR=target
        export CARGO_CFG_TARGET_ARCH=aarch64-unknown-linux-gnu
        unset CFLAGS
        cargo build --frozen --release --all-features
}

package() {
        cd "$srcdir/Tubefeeder-${pkgver}"
        # Binary
        install -Dm0755 -t "$pkgdir/usr/bin/" "target/release/tubefeeder"
        # Desktop-file
        sed -i 's_/app/bin/tubefeeder_/usr/bin/tubefeeder_' packaging/tubefeeder.desktop
        install -D packaging/tubefeeder.desktop $pkgdir/usr/share/applications/de.schmidhuberj.tubefeeder.desktop
        # Icon
        install -D packaging/tubefeeder.png $pkgdir/usr/share/icons/hicolor/512x512/apps/de.schmidhuberj.tubefeeder.png

        # Localization
        ls -ld po/locale/*/ | sed 's|.*po/locale/||' | xargs -I % install -D "po/locale/%LC_MESSAGES/de.schmidhuberj.tubefeeder.mo" "$pkgdir/usr/share/locale/%LC_MESSAGES/de.schmidhuberj.tubefeeder.mo"
}

I maintain a couple of apps for the pinephone my self, and I have been meaning to put up a repo with deb-packages for mobian for them. I could put tubefeeder there as well if you like, so it can be installed through the software center and people don't have to go through the hassel of buildning them selfs...

[Schmiddiii]

Sounds great, thank you. I think it would still be worth putting the PKGBUILDs on the MPR, but a repository with pre-built packages would also be good.

[mickenordin]

@hwittenborn if you would like to add and maintain the PKGBUILD for tubefeeder to MPR that would be great, the one I went with is here: https://code.smolnet.org/micke/external_builds/src/branch/main/tubefeeder/PKGBUILD

I have also added binary packages for arm64 and amd64 to https://repo.mic.ke

Tubefeeder 1.6.6 can be installed by adding the repo and signing key to apt and then simply install using apt, like so:

wget -O - https://repo.mic.ke/PUBLIC.KEY | gpg --dearmor --output micke-archive-unstable.gpg && sudo mv micke-archive-unstable.gpg /usr/share/keyrings
sudo wget -O /etc/apt/sources.list.d/debian-micke-unstable.list   https://repo.mic.ke/debian/debian-micke-unstable.list
sudo apt update && sudo apt install tubefeeder

[hwittenborn]

I was probably a bit misleading @mickenordin, I planned on mostly helping with the setup procedure with makedeb, but I don't think I could be much of the primary maintainer of the package as I don't use Tubefeeder myself.

Since you've already gotten the PKGBUILD set up though, is there anything that's stopping you from just maintaining the package yourself?