1

Topic: [Hyperbola] Going the way and packaging, the roadmap after 0.4

Hello dear community,

as you all know we are heading from now on directly towards HyperbolaBSD and our project needs to focus. So first and clear up: There will be no more new packages included with problematic dependencies or hard to be ported.

We will maintain our GNU/Linux-libre with most focus for sure, correcting problems and solve issues with you all together. But we won't add more packages like for example 0 A.D.. Yes, I can imagine that many are now frustrated but the reasoning is easy: We would be stuck forever for the last version without Rust. We have tried in the last weeks to find common points for solving the issues with Rust. The point stands we will not include the following packages and don't work any longer for searching solutions for them:

0ad: Reasoning is newer versions go for Rust in the making.
cinelerra-gg: Reasoning is the package is not compliant with our guides and won't compile clean, nevertheless you are able to build it local at your own wish and run it (when there is interest I will share everything for sure as there are no secrets doing that).
timeshift: Reasoning more or less the same as before, besides the package is also not clean at all and only builds local but not on our build-server.

We will also leave the points to add further big applications for now and near future. Our roadmap behind 0.4 stands right for the further development of HyperbolaBSD and maintaining what we have now with our wonderful 0.4. So 0.4.1 will include further additions of little helpers and bugfixing. We will also add missing packages in the pipeline for sure.

Please be reminded: This is in general no further discussion-point. Nevertheless the thread is being left open. If you think nevertheless you can add 0ad on your own for example: Feel free to do and share your experiences here in the forum, including the PKGBUILD. If you think you need more proposals? Okay do the same, but we won't add them when they have complex dependencies. Remember: We need to port everything then and we don't want to make our circumstances even impossible. The road is going for HyperbolaBSD and there is no turning back towards GNU/Linux-libre as this platform is in our viewpoint irreversible damaged. GNU/Linux-libre is a chaotic part full with security-issues, GNU/Linux is only a pragmatic approach and Linux further has turned away from freedom of choice. Building our own was from the beginning a perspective and will be part of this project. So be also prepared that Hyperbola is not treated fair. Nevertheless we stay honest and fair to all others. No need for being harsh, but facts are there said. Either to recognize or to ignore them further. When ignoring the outcome won't be good. wink

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

2 (edited by dikasp2 2022-03-19 03:45:06)

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

heya sorry for intrusion, maybe here a easy tips on what packages that would be likely accepted into hyperbola:

first get info of [your package suggestion], you can look it on archlinux package search, aur website, author github etc..
second after you get enough information of [your package suggestion] make sure:
1. the software and license are free libre open source software (FLOSS)
2. its doenst depend on enormous depedencies
3. it doesnt depends,use or contain:
    rust,java,mono
    D-Bus
    Bluetooth
    PAM
    systemd / elogind
    PolicyKit
    ConsoleKit
    PulseAudio
    Avahi
third thats it, hyperbola devs would gladly consider inclusion of your package smile

neverteless if you prefer the looong explanation:
1.technical packaging guidelines https://wiki.hyperbola.info/doku.php?id … guidelines
2.what software hyperbola its agaisnt and their reason https://www.hyperbola.info/todo/
3.hyperbola phylosophy (browse the wiki menu for more (especially rust)) https://wiki.hyperbola.info/doku.php?id … redirect=1

3

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

Well, thanks for adding big_smile
But you would be surprised how complex nevertheless packaging could be even there are no unwanted dependencies to be seen first place. We had much work to get packages running with gettext-tiny for example. It was a surprise for us also. But we have now a stable base and we want to port that for sure towards HyperbolaBSD.

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

4

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

We will remove and blacklist the following packages for 0.4.x to come also:

libvirt
libvirt-python
libvirt-glib
spice-gtk
virt-manager
osinfo-db
libosinfo

libvirt and all resulting is not possible to function without D-Bus and all other packages in relation have no further sense. It was a last tryout with the best thoughts, nevertheless internal structures are only based on D-Bus and don't function correct.

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

5

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

The following packages will be removed also:

wine-stable
winetricks-libre

You can compile wine without greater problems local in your HOME-folder and create there your own portable version. Nevertheless there won't be further support heading into HyperbolaBSD.

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

6

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

throgh wrote:

The following packages will be removed also:

wine-stable
winetricks-libre

You can compile wine without greater problems local in your HOME-folder and create there your own portable version. Nevertheless there won't be further support heading into HyperbolaBSD.

I am not sure if wine would work in HyperbolaBSD, even if we knew what parts of the kernel needed to be enabled, etc anyhow though right?

Whether they are completely ripped out, or individuals readd them, etc...

Also, its a massive security hole anyhow right?

Mostly because wine doesn't know how to stay grounded from accessing the internet in its entirety.    wink

HyperbolaBSD: The Future of Secure Libre Lightweight Operating Systems!

7

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

The reasoning for removing wine-stable is more about the point that for the concurrent moment we have no final decision if it will work in the future. Nevertheless wine itself is massively based also onto multilib-architectures when using 64bit and that is not possible for us. Having one clear architecture is okay, but pure wine on 64bit is not working without multilib-support. So this package makes no sense at all!

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

8 (edited by zapper 2022-03-26 23:20:23)

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

throgh wrote:

The reasoning for removing wine-stable is more about the point that for the concurrent moment we have no final decision if it will work in the future. Nevertheless wine itself is massively based also onto multilib-architectures when using 64bit and that is not possible for us. Having one clear architecture is okay, but pure wine on 64bit is not working without multilib-support. So this package makes no sense at all!

I had thought removing it had to do with security more than anything and btw, you said 64 bit did work...

Well... either way, I think it is more than enough to just turn off the part of the kernel that allows wine if its still in there, which I kind of doubt anyhow and say, we don'r support this because its an enormous security hole, etc...

Since friggin wine's biggest issue is that it cannot be disconnected from internet while being used as option at all or in some cases, there is no protection from guest to host, even if it could be offline.  Aka, some executables probably work even offline especially if the GNU/Linux & BSD parts are online.

If it weren't for that,  I might have a different opinion. 

Proceed though, at this point, I hardly ever use wine anymore, unless the situation is desperate enough, but for that, I am probably better off using a different installation as a whole for that specific purpose, on a different SSD drive, since I am not experienced enough to do multiboot...

Although, using any proprietary operating system, even ones with that garbage that most mainstream distros allow to be forced on them, some of which is on this thread, in combination alongside Hyperbola is just not wise... quite the opposite, wink

That being said, its also better for my mind to avoid most of that stuff anyhow, aka the online gaming stuff.

Especially if chatting is an option!

Anywho just my two cents on this, not sure if everyone agrees though.

So, I don't care one way for the most part or the other, as I won't lose sleep over it, but on occasion it could be useful.

Mildly interesting, but not crucial aka to sum it up.

Peace man, will see if I have any other thoughts later.

HyperbolaBSD: The Future of Secure Libre Lightweight Operating Systems!

9

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

Removing multilib is in fact a decision for security. wink
And disconnecting wine from network is not the real point. In fact wine has become a complete different entrypoint for unfree software over time. To run old games from times without broad internet-connection is no problem. But nevertheless it is the wrong way for sure with most modern parts: It has lost the way and got out of control long ago. Now parts and projects like dxvk have taken over, making it somewhat possible to run modern games. The question would be: Is this the way to run a free system? It is one point running old software with no further issues, but another to just copy all problems back to back into GNU/Linux and even some parts BSD. So just for having "modern games" running DRM-platforms and the unfree parts are included into free systems.

That's another point wine has to go also. There is no compromise! Doing something within the own HOME-folder is okay and the user decision. The rest of the system should stay free and libre, or another system should be used.

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

10 (edited by HarvettFox96 2022-04-02 10:11:40)

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

This post was erased due to the wrong thread and moved to the issue FS#1603.

11

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

Sorry, but we don't integrate new packages that way any longer as we also don't have time and persons for. Please remember: This thread is not about wishes as every new package for 0.4.x needs also to be ported. Please look therefore into the roadmap: https://wiki.hyperbola.info/doku.php?id … la_roadmap

EDIT: I have also closed the issue you have created because the PKGBUILD is not following our packaging-guidelines. Please take into note: We stop further and step by step integration of new packages. We are a small team and need our time to focus.

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

12

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

We also won't include further packages with problematic background. The meaning here is clear: JavaScript is nothing to build on top of. There are enough reasons to remove nodejs in a whole, not to use npm and also not include gjs. JavaScript was build once for other purpose, not for server-applications and also not for applications outside the web. It is the reason for many problems known and many to come.

We don't want to risk stability of Hyperbola GNU/Linux-libre and HyperbolaBSD in any way.
It is also a point about security: Applications should be most offline and not use more and more dependencies like gjs. So it is a reason for us to stop the integration of complex software complete. We want to fix packages when needed, we don't want to add even more. Quality is right more important than quantity. And yes: Hard decisions for some, but better outcome at all. If you want to enhance your local installation of Hyperbola, feel free to do and share your impressions. But we can't include everything for sure when we are heading into the direction of HyperbolaBSD.

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

13 (edited by zapper 2022-04-04 20:47:20)

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

throgh wrote:

We also won't include further packages with problematic background. The meaning here is clear: JavaScript is nothing to build on top of. There are enough reasons to remove nodejs in a whole, not to use npm and also not include gjs. JavaScript was build once for other purpose, not for server-applications and also not for applications outside the web. It is the reason for many problems known and many to come.

We don't want to risk stability of Hyperbola GNU/Linux-libre and HyperbolaBSD in any way.
It is also a point about security: Applications should be most offline and not use more and more dependencies like gjs. So it is a reason for us to stop the integration of complex software complete. We want to fix packages when needed, we don't want to add even more. Quality is right more important than quantity. And yes: Hard decisions for some, but better outcome at all. If you want to enhance your local installation of Hyperbola, feel free to do and share your impressions. But we can't include everything for sure when we are heading into the direction of HyperbolaBSD.

Is it even possible to completely get rid of javascript?

A lot of python packages seem to need it...

Hmmm on further inspection, I was able to remove most of it! except one thing...

perl-json...

Seems its needed for spamassassin...

...

HyperbolaBSD: The Future of Secure Libre Lightweight Operating Systems!

14

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

json is a dataformat, not of a problem (https://en.wikipedia.org/wiki/JSON). It has its roots within JavaScript but can be used without. It is for sure possible to get rid of JavaScript or just keep it there where needed within the browser mostly and control the websites being in use. The situation is then different when JavaScript is essential part within a server- or client-application, being used within a library for a kind of making functionalities available or used for code-execution. And as we are onto looking for lightweight packages there are also those using those parts. In the first place looking harmless, nevertheless they are not. JavaScript was just done for dynamic interactions within the context of web-browsers, using it for more is in the perspective of security and stability not working.

The difference for Python is there that it can be used for web-software also. So having parts integrated carefully for JavaScript is in some situations okay. But it ends already at nodejs completely with more and more projects going that way.

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

15

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

Another package which won't be any longer available is hplip. The reasoning here for the removal: D-Bus is a mandatory dependency. Even though there are options to leave out for compilation the resulting binaries are not working. So we have to remove that package completely for upcoming 0.4.1.

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

16

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

throgh wrote:

Another package which won't be any longer available is hplip. The reasoning here for the removal: D-Bus is a mandatory dependency. Even though there are options to leave out for compilation the resulting binaries are not working. So we have to remove that package completely for upcoming 0.4.1.

I managed to setup my HP printer using CUPS but I didn't manage to use sane without hplip (it seems the scanner uses hpaio). hplip seems to contain several components some of which work without dbus such as hp-scan (for scanning), hp-print (for printing) and hp-levels (to show ink levels). Some of these can be replaced by generic packages such as libinklevel and ink from AUR (these two packages when installed together show the ink levels). Can Hyperbola simply remove or disable the elements of hplip that require dbus (such as hp-setup) instead of removing the entire package? If not, is it possible to create a package with only the scanner and printer drivers without the additional software layer?

17

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

We can for sure rework the whole package, but to remember: This is a bit of a problem for sure. The point: We would only be able to do that for a concrete version. If the next version and release is changing the structure of files and folders, remove further parts within the build-process or something else: All is going back to zero and we can restart that package from this point. So the proposal would be that we all work together onto a concrete package and build-script. After essential testing we can take it into the repositories for sure. But the problem with hplip was only discovered thankfully throughout you and others in IRC. It is a pity this was not part of testing as it seems people demanded never tested it before. So therefore a more community-close proposal and we can overcome that problem perhaps on this way. smile

For now hplip is going to get removed from testing. When we can finish another renamed and better PKGBUILD, this will be resolved. libinklevel and ink are there now and ready for building:

https://git.hyperbola.info:50100/~team/ … d7730e82c9

https://git.hyperbola.info:50100/~team/ … 8320bc8d71

So things to check:

1. Rebuild hplip and check all contained programs and parts (here is the package-sourcetree: https://git.hyperbola.info:50100/~team/ … 267ac87e11
2. Remove all components being marked as dysfunctional, not working without dbus and all dependencies within included (a clean package is needed, no further parts on the system should remain being useless)
3. Only left included what is working and needed, including free and libre drivers.

The point is just: This is not possible without so much work, that we could either fork the whole hplip or better search for alternatives. Personally I don't see there much effort into and we should find all together a possible alternative being clean and lightweight. hplip seems to be not the way, especially in question when heading more for HyperbolaBSD. hplip is a problem as the build-process is only done in a whole from my concurrent understanding, the package left then too much bloat for the binaries mentioned and we have no time to sort everything out alone. Either the community helps here or we would be sorry but then there can't be a further solution.

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

18 (edited by aloniv 2022-04-06 15:01:50)

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

Actually it appears that CUPS used the PPD file provided by hplip (from the directory /usr/share/ppd/HP/) - it did recognise the existence of the USB printer but my model's PPD file isn't part of CUPS.

In Debian scanning using hpaio is provided via libsane-hpaio and the PPD files are provided via packages such as printer-driver-postscript-hp, printer-driver-hpcups, printer-driver-hpijs, hp-ppd and hpijs-ppds. Perhaps similar packages could be made for Hyperbola as well to replace the full hplip.
https://packages.debian.org/unstable/libsane-hpaio
https://packages.debian.org/unstable/pr … tscript-hp
https://packages.debian.org/unstable/pr … ver-hpcups
https://packages.debian.org/unstable/pr … iver-hpijs
https://packages.debian.org/unstable/hp-ppd
https://packages.debian.org/unstable/hpijs-ppds

19

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

If you look closer many of those packages are built from the same source named hplip. And as to mention: We cannot provide the time to recreate that all from scratch. To provide hplip as a whole was the last possible tryout from us. Now we cannot go further alone to recreate that: Again to mention we had a long testing-time for 0.4 and either the community now takes over for helping clear for that packages or hplip will be left out for good.

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

20 (edited by aloniv 2022-04-06 16:28:24)

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

I managed to build hplip with working hp-setup by disabling GUI in the config settings of Hyperbola's PKGBUILD smile
I used the setting --enable-gui-build=no and removed the lines --enable-qt5 and --disable-qt4 in the PKGBUILD.
It appears that hp-setup without GUI simply runs hp-probe which also works in Hyperbola's hplip.

21

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

Okay, thanks for noting. I will try to recreate than hplip with the corresponding parameters. But it will have to get another name for sure now as it is listed now in our blacklist. Proposal hplip-libre than?

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

22

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

The built package from Hyperbola's PKGBUILD with GUI disabled still creates the packages that were disabled such as hp fax and plugin related packages. It appears that disabling settings in hplip still creates the packages but they might not be functional.

23

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

I see already, but especially that is not acceptable: Those parts need to be removed. We cannot add binaries being completely useless as this violates our package-quality and for sure also the definition of "lightweight". Only what is working, nothing more. hplip is not a very friendly package at all and very bloated.

Feedback: Nope, there are enough leftovers within, binaries and libraries, wanting and demanding dbus. So there is no solution in reach also with that. hplip stays a broken package at all, for now no reason to keep it. sad

You see it here:

https://packages.debian.org/bullseye/libsane-hpaio (dbus-dependency needed)

Even if we go for the drivers, we won't be able to include any further binary. So the best guess will stay for now: If you need hplip, please compile it your own with accepting there are broken leftovers. That package is for sure not working any point without dbus.

Many binaries complain about missing python-dbus. That is not working at all: I have rechecked now with different options and leaving out the GUI-options also. A warning is acceptable for some applications, but essential ones like driver-packages should work without errors and warnings at all. And when users execute hp-check they will get immediately to the point where python-dbus is marked as required and mandatory. If you need hplip it is okay, but for now we can only stay at the point to define it as too broken for repositories. The only alternative would be: Define what parts are needed essential, deleting all the rest. That is the only way I see for now.

Or we try another way. Let me try out and I report back with a possible working PKGBUILD, hope so. big_smile

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

24

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

This is the one working for now, but well? No binaries included any longer. Just the drivers and base-files. The binaries are damaged as mentioned.

# Maintainer (Arch): Andreas Radke <andyrtr@archlinux.org>
# Maintainer (Arch): Tom Gundersen <teg@jklm.no>
# Contributor (Arch): Rémy Oudompheng <remy@archlinux.org>
# Contributor (Arch): Morgan LEFIEUX <comete@archlinuxfr.org>
# Maintainer: André Silva <emulatorman@hyperbola.info>
# Contributor: Jorge López <jorginho@hyperbola.info>
# Contributor: Márcio Silva <coadde@hyperbola.info>
# Contributor: Tobias Dausend <throgh@hyperbola.info>

pkgname=hplip-libre
_pkgname=hplip
pkgver=3.21.2
_debver=3.21.2+dfsg1
_debrel=2
pkgrel=1
pkgdesc="Drivers for HP DeskJet, OfficeJet, Photosmart, Business Inkjet and some LaserJet"
arch=('i686' 'x86_64')
url="https://developers.hp.com/hp-linux-imaging-and-printing"
license=('GPL-2')
depends=('ghostscript' 'net-snmp' 'foomatic-db-engine')
makedepends=('sane' 'cups' 'libusb' 'quilt')
optdepends=('cups: for printing support'
            'sane: for scanner support'
            'xsane: sane scanner frontend'
            'python-pillow: for commandline scanning support'
            'python-reportlab: for pdf output in hp-scan'
            'libusb: for advanced usb support')
backup=('etc/hp/hplip.conf'
        'etc/sane.d/dll.d/hpaio')
source=(https://downloads.sourceforge.net/${_pkgname}/$_pkgname-$pkgver.tar.gz{,.asc}
        https://deb.debian.org/debian/pool/main/h/hplip/hplip_$_debver-$_debrel.debian.tar.xz
        disable_upgrade.patch
        0022-Add-include-cups-ppd.h-in-various-places-as-CUPS-2.2.patch
        remove-systemd-support.patch)
sha512sums=('73ba37275cfe34a58b81c9656514e15da67c1a69af5471ad132a1538d324efe640879cb7e60c359915607e41b63e653e7ae757661e553235f6e83e378ab46474'
            'SKIP'
            '771bfae13f452f637696ef7947e95c21e5cb514cd613fb15d182f0e0fbb02ce60684c75a7cb8245423bbcffe2c7d1a155f4109fe1769b0badb7d006bb9406ff2'
            'd6a6b1de0fb6a0d6af6badd81088bc2b493d894057a520ccd70abee0adc7e1b019aae641600c10d4d2053c8677b14897b40a0a306374a5702a7cd7bdeabd736e'
            '22aeb5b851f78bc6bc62e0bc3da99fecaf42d7604af41e2f3343f8d3666541f7b06b7d1a7d0ddf24f1731ac7b12dfe582375a98e3b94dfa323d6ce954549ca67'
            'abd64e02965190cdfb7f7fd65d1875da4420594b627cd85b7f1da1f69a823b55358146e02d81e50e90000e21ba6e69d25fbb785dd489f1f3f461e50ce16f11e7')
validpgpkeys=('4ABA2F66DBD5A95894910E0673D770CDA59047B9') # HPLIP (HP Linux Imaging and Printing) <hplip@hp.com>

prepare() {
  cd $_pkgname-$pkgver

  if [[ ${pkgver%.*} = ${_debver%.*} ]]; then
    # Debian patches
    export QUILT_PATCHES=debian/patches
    export QUILT_REFRESH_ARGS='-p ab --no-timestamps --no-index'
    export QUILT_DIFF_ARGS='--no-timestamps'

    mv "$srcdir"/debian .

    # Doesn't apply
    rm -v debian/patches/0022-LaserJet-PostScript-4000-PPD-bugfix.patch || true
    rm -v debian/patches/0052-IEEE1284-Device-ID-for-HP-LaserJet-4000.patch || true
    rm -v debian/patches/0053-Fix-ImageableArea-for-Laserjet-8150-9000.patch || true

    quilt push -av
  else
    # add missing 'include <cups/ppd.h>' at various places
    patch -Np1 -i ${srcdir}/0022-Add-include-cups-ppd.h-in-various-places-as-CUPS-2.2.patch
  fi

  # based on https://devel.trisquel.info/trisquel/package-helpers/raw/master/helpers/make-hplip
  # keep header license
  sed  '/\[/,99999d' data/models/models.dat > mktemp

  for model in $(grep '\[' data/models/models.dat | sed 's/\[//; s/\]//'); do
    sed -n "/\[$model\]/,/^$/p;" data/models/models.dat > mktemp1
    grep '^download=True' -q mktemp1 && continue
    grep '^plugin=1' -q mktemp1 && continue
    grep '^support-type=0' -q mktemp1 && continue
    cat mktemp1 >> mktemp
  done

  sed -i 's/plugin=2/plugin=0/g' mktemp

  cp mktemp data/models/models.dat

  rm -v mktemp{,1}

  # remove systemd support
  patch -p1 -i ../remove-systemd-support.patch

  # remove nonfree software recommendation
  sed -i 's/\, requires proprietary plugin//' $(grep -rlI '[,] requires proprietary plugin')

  # disable insecure update
  patch -Np0 -i ${srcdir}/disable_upgrade.patch

  export AUTOMAKE='automake --foreign'
  autoreconf --force --install
}

build() {
  cd $_pkgname-$pkgver

  # disable dbus for build including fax
  # avahi is needed for network, also disabled
  ./configure --prefix=/usr \
             --with-cupsbackenddir=/usr/libexec/cups/backend \
             --with-cupsfilterdir=/usr/libexec/cups/filter \
             --enable-hpcups-install \
             --enable-new-hpcups \
             --enable-cups-ppd-install \
             --enable-cups-drv-install \
             --enable-foomatic-drv-install \
             --enable-foomatic-ppd-install \
             --enable-pp-build \
             --enable-lite-build \
             --disable-dbus-build \
             --disable-fax-build \
             --disable-gui-build \
             --disable-qt3 \
             --disable-qt4 \
             --disable-qt5 \
             --disable-foomatic-rip-hplip-install \
             --disable-polkit \
             --disable-network-build
  make
}

package() {
  cd $_pkgname-$pkgver
  make -j1 rulesdir=/lib/udev/rules.d DESTDIR="$pkgdir/" install

  # install license
  install -Dm644 COPYING "$pkgdir"/usr/share/licenses/$_pkgname/COPYING

  # remove config provided by sane and autostart of hp-daemon
  rm -rf "$pkgdir"/etc/{sane.d,xdg}
  install -dm755 ${pkgdir}/etc/sane.d/dll.d
  echo hpaio > ${pkgdir}/etc/sane.d/dll.d/hpaio

  # remove HAL .fdi file because HAL is no longer used
  rm -vrf "$pkgdir"/usr/share/hal
}

So this package would provide finally only scanner- and printer-drivers. But we need for sure a test before re-adding hplip-libre as alternative marked into our blacklist and to the repositories. smile

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

25

Re: [Hyperbola] Going the way and packaging, the roadmap after 0.4

Another point: We won't update packages outside the Debian-context. This means: Our orientation is and will be Debian Bullseye. Why do I write that? Because there is an update for tblock possible. But this is not working with Hyperbola GNU/Linux-libre 0.4 as it demands python-requests in version 2.26.0 or higher. Quote to follow:

pkg_resources.DistributionNotFound: The 'requests>=2.26.0' distribution was not found and is required by tblock

This is part of the roadmap: We only do fixing, slightly additions. There won't be great more applications added!
If you wish for that: Please take action and share your own here in the forum. smile
One major problem of the GNU/Linux-sphere is the neverending search for "updates". This cannot be part of a system oriented onto stable packaging. We are not a big system at all, so we are even oriented onto selected packages and also selecting further going for BSD leaving all GNU/Linux behind. core will be complete based onto BSD, while extra can and will also include more as it is now. But please: Not this on-going "search" for the next big update. Security and stability, absolutely. But especially therefore we will and can never copy from rolling-releases. We have left this sphere long ago: Hyperbola is not Arch Linux and only shares the package-management, nothing more! It is free software, so please share your freedom and modify as you wish. But also: Please have understanding that we cannot include problematic packages from elsewhere or modify them to fit into. The result would not be that much of happiness for all of us, just for one version foremost perhaps. It is a pity, I know that for sure: But that's the reasoning for cutting out others like 0ad. We would end at a version not being able to be upgraded at any point.

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!