Add a PPA or APT repo

[pizzadude]

Hi, interesting project.

Is it possible for you to setup a Ubuntu PPA so Ubuntu/Mint/[insert derivative here] users could easily be up to date?

[Eloston]

I like the idea, but I don't have time to maintain a PPA manually. If this can be automated in some way, I would like to hear it.

If you or someone else would like to maintain a PPA or repository, go right ahead. I can add a link to it from the README.

[pizzadude]

I'm not sure how to make a PPA, I'm not a developer. But PPA's can be automated. http://askubuntu.com/questions/550012/how-to-create-a-automatic-ppa

Sorry if this is too much to ask. :<

[Eloston]

Well the link you provided basically says that a CI can push packages to a PPA server, which means that I would need to figure out how to use Travis CI (or some other CI system) and find a server to host a PPA.

That sounds nice, so I might look into this in the future when I have more time.

[hrj]

@Eloston As a first step, you could also consider pushing the build from Travis-CI to Github Releases pages as per this doc. That will take care of hosting atleast.

[Eloston]

@hrj: I'm not sure if I trust Travis CI enough to give it the public_repo permission to this account. But what really bugs me is that they telll you to use their magic command travis setup releases that obscures how things are setup:

Instead of setting it up manually, it is highly recommended to use travis setup releases, which will automatically create a GitHub oauth token with the correct scopes and encrypts it.

I could make another GitHub account that mirrors this repository and integrates with Travis CI, but that would require me to manage another GitHub account on top of Travis CI. Though this option seems more appealing the more I think about it.

[hrj]

@Eloston Oh, that's an overarching permission. I understand your hesitation.

I wonder how the permission system works. If you create a dummy Github account, add it as a collaborator on this repository (without write permissions), create an oauth token for the dummy account and give it to Travis, will Github allow code writes through that token? If it allows releases but not code-writes, then it might be worth exploring.

[Eloston]

@hrj: I'm pretty sure you have to own the repository. I'm a collaborator on another repository (with write access), and I couldn't get Travis CI to see it.

Fortunately, there are commands in git that make it easy to mirror a remote repository. Here's GitHub's documentation on them. This way my dummy account can be separate from this account.

[hrj]

@Eloston Ah, ok.

FWIW, Github seems to have come out with a new auth system yesterday. Here's hoping that Travis-CI leaps on to it quickly.

[Eloston]

@hrj: Huh, looks interesting. That would solve the hassle of setting up a separate account.

I'm a bit worried about the build environment they provide us. They allocate 7.5 GB (since I have to use a Docker image of Ubuntu Xenial), which might be enough to link if I set the right flags. However, I'm not sure how much disk space they allocate -- my whole build directory is taking 4 GB, which is pretty small by Chromium standards. Also, I'm not clear what Travis considers a "job". From what I've read, a single job can only last for about 50 minutes maximum (assuming it prints output at at least 10 minute intervals), but the build can take as long as it needs to. Are jobs the processes Travis directly invokes? Does this include subprocesses? Threads? A build takes about 3 hours, so the definition is pretty crucial.

[code-of-kpp]

Launchpad can automate on-commit build, packaging and publishing of deb packages
You just need

1. a debian/ directory
2. bzr-script https://help.launchpad.net/Packaging/SourceBuilds/Recipes
3. setup launchpad mirror of source repo

[Eloston]

@podshumok Good to know. I might consider it if Travis doesn't work out. Would you mind linking some documentation to do this? Thanks.

[code-of-kpp]

Some docs are available here https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted
The hardest part is to actually make a debian/ directory, everything else is more or less obvious, although may seem not so easy at the beginning...

You may want to look at https://code.launchpad.net/~chromium-team/chromium-browser/chromium-browser.head

Best thing is that Launchpad provides separate everyday builds for different platforms and Ubuntu versions

[Eloston]

@podshumok Alright thanks.

[MikolajQ]

PPA would be great!
+1 for PPA

[kirylrb]

Please add the PPA.
And great thanks for you work, really.

[Lesik]

I oppose the use of PPAs/Launchpad.

I don't understand why using the OBS as suggested in #17 and #59 was rejected. The OBS allows building binaries for Debian, Ubuntu, Fedora, CentOS/RHEL, Arch Linux and many more distributions. By investing some time into this you receive a unified build/hosting service serving packages for all distributions, not just Ubuntu. Launchpad, on the other hand, only supports Ubuntu (and while it would theoretically work to install a PPA on Debian, you should never do that!)

[hrj]

I don't understand why using the OBS as suggested in #17 and #59 was rejected.

It wasn't rejected. #59 was closed as a duplicate of #17, which is still open.

[zabbal]

Using OBS does not contradict using Launchpad - those are orthogonal things. Having ppa would be really convenient for Ubuntu users which would greatly help with wider adoption and testing.

[Lesik]

@zabbal How do Ubuntu users benefit from Launchpad more than from OBS? Why maintain two services? OBS does everything Launchpad can, and much more. Or am I mistaken?

[message]

bump

[Eloston]

I'm not quite sure how APT or PPA repos work, but are they basically retrieving files from a web server? If so, it may be possible to generate these files and upload them to the GitHub pages repo of the downloads repository.

[pseudoj]

+1 for a PPA repository.

[kirylrb]

@Eloston Personal Package Archive (PPA) only works with launchpad
https://askubuntu.com/questions/71510/how-do-i-create-a-ppa

[pcraciunoiu]

Subscribed, and

👍 for anyone who can figure this out or provide instructions for figuring it quickly / others to help unblock

[code-of-kpp]

@T-vK you may want to add some information-gathering script (like (pwd; lstree /) > lstree_gitliab_artifact to debuild's signing-hook (see man)

[T-vK]

@podshumok
I just tried. Unfortunately it didn't seem to work.
I basically did this:

# export DEBUILD_SIGNING_HOOK='(pwd; lstree /) > lstree_gitliab_artifact.txt'
# debuild -i -S || echo

And then I checked for the file:

# ls -la
total 32
drwxr-xr-x. 4 root root 4096 Nov 18 06:37 .
drwxr-xr-x. 3 root root 4096 Nov 18 06:38 ..
drwxr-xr-x. 6 root root 4096 Nov 18 06:38 debian
drwxr-xr-x. 3 root root 4096 Nov 18 06:37 third_party
# cat lstree_gitliab_artifact.txt
cat: lstree_gitliab_artifact.txt: No such file or directory

https://gitlab.com/T-vK/ungoogled-chromium-launchpad/-/jobs/121993418

[code-of-kpp]

@T-vK

hmm. I think it should be a separate script with +x attr and variable should have its path as a value

[T-vK]

@podshumok that doesn't appear to work either..

$ echo "#!/usr/bin/env bash" > signing-hook-script.sh
$ echo "(pwd; ls -la; tree /) > lstree_gitliab_artifact.txt" >> signing-hook-script.sh
$ chmod +x signing-hook-script.sh
$ export DEBUILD_SIGNING_HOOK='signing-hook-script.sh'

https://gitlab.com/T-vK/ungoogled-chromium-launchpad/-/jobs/122212458

Maybe the current directory is not the one I expected during the execution of the signing hook. I'll try to specify absolute paths.

Edit: Nope, it's still not working. Even if I specify absolute paths.

[code-of-kpp]

Well.
First, looks like I was wrong about environment variables.

HOOK should be specified in config file or as an argument to debuild script. For some reason documentation mentions this hook as --signing-hook-foo while I thing it should be --signing-hook=/signing-hook-script.sh

Second, looks like we need to see what gpg is doing:

gpg --verbose  --local-user "tavk tavk <t-v.k@gmx.net>" --clearsign \
    --list-options no-show-policy-urls \
    --armor --textmode --output "/build/test-signature"\
    "/build/ungoogled-chromium-browser_*.dsc"

(or maybe try to sign any other file)

[T-vK]

@podshumok
The man page is indeed wrong.
Here is the output of the signing hook. (ls -la / followed by tree /) https://t-vk.gitlab.io/-/ungoogled-chromium-launchpad/-/jobs/123825062/artifacts/build/lstree_gitliab_artifact.txt

While attempting to sign a file using gpg I made a very helpful observation.
When the file to be signed does not exist you get an error like this:

gpg: can't open '/non-existing-file.txt': No such file or directory
gpg: /non-existing-file.txt: clear-sign failed: No such file or directory

And when only the output directory does not exist, you get an error like this:

gpg: writing to '/non-existing-output-dir'
gpg: pinentry launched (585 curses 1.1.0 not a tty - -)
gpg: signing failed: No such file or directory
gpg: /existing-file.txt: clear-sign failed: No such file or directory

Comparing that to the error that is currently preventing the ungoogled chromium file from being signed:

gpg: signing failed: No such file or directory
gpg: /tmp/debsign.hwokAatw/ungoogled-chromium-browser_68.0.3440.106-1~bionic.dsc: clear-sign failed: No such file or directory

the issue might actually be that the output directory that debuild passes to gpg doesn't exist.

[code-of-kpp]

This is some progress! (almost :)) What is the devscripts version?

debsign should create /tmp.debsign.XXXXXXX directory (mktemp) and through an error if fails to do so.

Meanwhile in directory listing you provided /tmp folder is completely empty and I find it surprising.
Perhaps it is somehow weirdly mounted? Can you manually run mktemp and see if you can interact with directory?

[T-vK]

The devscripts package version is 2.17.12ubuntu1.1.
Unfortunately mktemp seems to work :(

$ TMP_FILE="$(mktemp)"
$ ls -la /tmp
total 20
drwxrwxrwt. 1 root root 4096 Nov 23 10:17 .
drwxr-xr-x. 1 root root 4096 Nov 23 10:17 ..
-rw-------. 1 root root    0 Nov 23 10:17 tmp.nKYuLBJlJm
$ echo "test 123" >> "$TMP_FILE"
$ ls -la "$TMP_FILE"
-rw-------. 1 root root 9 Nov 23 10:17 /tmp/tmp.nKYuLBJlJm
$ cat "$TMP_FILE"
test 123

[T-vK]

@Eloston Hey, I just wanted to give it another try with the current master and I see a lot of things have changed. The CI script used to replace some values in packaging/ubuntu_bionic/changelog.ungoogin, so that they match the GPG key, but that file does not exist anymore. Is there a different file that takes care of this now?

[Eloston]

@T-vK All Debian code has moved to ungoogled-chromium-debian. The file structure follows that of Debian's chromium package git repo.

FYI, I don't really mind if we keep this issue open or open a new one on that repo. Unfortuantely, GitHub can't transfer this issue over to ungoogled-chromium-debian.

[code-of-kpp]

Hi! Here is how vscodium guys solved this puzzle https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo/blob/master/updaterepos.sh

[Eloston]

@podshumok That's quite the hack they've put together, but it's not very robust. At least on GitHub, there is a git blob limit of 100 MB (we aren't hitting it yet, though). Also, their solution involves uploading the private .deb signing key to the repo, which is less than an ideal solution for security reasons (users would need to trust the public key, which opens them up to security problems). If there's a good solution to the private key security problem, then we can adopt their solution here.

[code-of-kpp]

The key is encrypted and they decrypt it using CI secrets. I think it is more or less fine, but it also should be possible to have private key completely stored in CI secrets. What I don't like in their solution is the way original deb files are downloaded: they just curl github releases page and grep links to the latest deb's. I think at least some sort of verification is required here - maybe signing. In that case if for example their github account gets hacked authors still can revoke the key and my system wouldn't get forged package update.

[Eloston]

@podshumok

The key is encrypted and they decrypt it using CI secrets

Ah, I missed that crucial detail in my haste. Thanks. In that case, that part is fine as long as there's strong security around how those variables can be used; e.g. if the variables can be used in PRs, then maybe it's possible modify the CI script in the PR to redirect the key somewhere else.

What I don't like in their solution is the way original deb files are downloaded: they just curl github releases page and grep links to the latest deb's. I think at least some sort of verification is required here - maybe signing

At that point, it's hard to say if the repo containing the key to decrypt the private key is any safer. In our scenario, we are trusting that all those pushing binaries to ungoogled-chromium-binaries will keep their accounts secure. If we really want a secure pipeline for building and publishing binaries, we should consider automating the build on a more trustworthy server.

However, using an encrypted private key and retrieving deb packages from ungoogled-chromium-binaries as it is now is not much more dangerous than users manually downloading the deb packages themselves. In addition, the largest deb packages we have now are around 50 MB, which is still well below the limit of 100 MB. For now, we could implement a solution like the one you found.

[mckaygerhard]

PPA are not good idea.. due only winbutu shit will be easy to setup.. all of the debian derivatives will not be easy installable for newbie Debian or realted Debian users..

so OBS will benefit all the required if a proper rules are made.. of course the build enviroment are too exquisite.. that's the problem.. (specific python version .. specific engines for realted libraries etc)

[ghost]

A repo would be a very good idea, the updates woundnt require manual installation and the install itself would be eaaier

[trymeouteh]

I would like to see this app preferably in the debian repos and always be the latest version. But if there can be PPA that is the latest version then that is good enough for me.

I know I can get the latest version if I switched to Arch based distro but I would like the latest version of Ungoogled Chromium on my Debian/Ubuntu based distro since Debian and Ubuntu based distro are more stable compared to Arch and I like using a stable distro for my work computer.

[hrj]

Replying to @mckaygerhard comment:

of course the build enviroment are too exquisite.. that's the problem.. (specific python version .. specific engines for realted libraries etc)

Solution could be to use a container based build. The container has all the dependencies, and doesn't depend on or pollute the host.

I made a start here: ungoogled-software/ungoogled-chromium-portablelinux#22

The build just requires a single command to be executed, and a single dependency on docker. Since this is the portable version, the compiled binary will work on all linux platforms, and since the build is inside a container, it will build on all linux platforms.

If we all focus on this path, we could reduce the effort involved in building, as people using different distributions could use the same build scripts.

Eventually, we can derive debs and other packages out of these binaries. These may not be acceptable to official repositories (because of bundled libraries) but might help us get there eventually, by getting more adoption.

[markstos]

There is a Ubuntu PPA for this now but oddly this is the first result when you search for it and no one here seems to mentioned the link. It's here:

https://launchpad.net/~braewoods/+archive/ubuntu/ungoogled-chromium

[mbakke]

An alternative way to get the latest ungoogled-chromium on any GNU/Linux distribution is to install GNU Guix. Then you can simply guix install ungoogled-chromium (and any other Guix package), no root privileges needed.

[trymeouteh]

There is a Ubuntu PPA for this now but oddly this is the first result when you search for it and no one here seems to mentioned the link. It's here:

https://launchpad.net/~braewoods/+archive/ubuntu/ungoogled-chromium

Is there a PPA without any added extensions like keepassxc? I want a plain vanilla ungoogled chromium PPA that keeps ungoogled chromium up to date, no added extensions or anything.

[ghost]

@trymeouteh why is that a problem? They're not pulled in when you install the main packages. They're only intended for people that would like a systematic replacement for automatic extension updates which appears to not work otherwise with ungoogled-chromium.

[nicoroeser]

@braewoods, has your PPA been moved or removed?

[ghost]

@nicoroeser It was replaced by the OBS repository that I now manage via automated uploads from the official github Debian repository. Switch over to using that and you should be able to update just fine. Just note that it doesn't provide extensions anymore as I found out you apparently don't need that. There's better ways to install them from what I was reading.

[Eloston]

Closing because OBS is rolled out.