Fedora repository?

[d33tah]

It would be nice to have a Fedora repository for this one. Are there any plans to create one?

[9Morello]

Currently, there is no support for Linux distributions that aren't Debian-based. If you want to use ungoogled-chromium in Fedora, you can check Google's official instructions to build Chromium on Fedora and apply the patches manually. You can have more info in the building page.

[Eloston]

Sure, Fedora support could be added. Though I don't have a Fedora system, so someone else would have to figure out how to get it to build and possibly make a pull request.

If you don't care about using system libraries, you could wait until #41 is finished.

[logic]

As an FYI to anyone looking at this, Chromium finally made it into Fedora proper recently, and a good starting point for this task might be the chromium RPM git repository to get a feel for how the upstream projects were packaged.

[neurodiverseEsoteric]

It seems that the only thing needed is to change the naming conventions for the libav-FFMPEG suite of libraries. Fedora's libav and FFMPEG packages don't add a -FFMPEG to the end of their libraries. Making symbolic links doesn't work either:

/usr/lib/chromium/chromium: /lib64/libavcodec-ffmpeg.so.56: version LIBAVCODEC_FFMPEG_56' not found (required by /usr/lib/chromium/chromium) /usr/lib/chromium/chromium: /lib64/libavutil-ffmpeg.so.54: versionLIBAVUTIL_FFMPEG_54' not found (required by /usr/lib/chromium/chromium)
/usr/lib/chromium/chromium: /lib64/libavformat-ffmpeg.so.56: version LIBAVFORMAT_FFMPEG_56' not found (required by /usr/lib/chromium/chromium) /usr/lib/chromium/chromium: /lib64/libswresample.so.1: versionLIBSWRESAMPLE_1' not found (required by /lib64/libavcodec-ffmpeg.so.56)

If you can fix that, then simply converting the deb packages to rpm's with alien and rpmrebuild should be enough, right? Oh and libjpeg.so.8 needs to be built for fc24, as well...

[Eloston]

@esotericDisciple That's unpredictable, since more components can break if Debian changes its packages.

It'll be better to have a Fedora builder so Fedora-specific patches can be applied.

[Lesik]

It's a horrible idea to use alien for this. A native Fedora specfile should be created, possibly on the basis of Fedora's chromium spec as @logic mentioned.

[Gridlocked]

AppImage would be a good way to bring this to Fedora, SuSe and all the other rpm based distros. Right now in yumex Fedora's Chromium is stuck at 55 anyway.

While the privacy aspect of ungoogled chromium is certainly attractive - not being able to disable plugins (a coming change in Chrome/Chromium) makes this a superior build from a security pov also.

[probonopd]

See https://github.com/probonopd/AppImageKit/wiki/Bundling-Google-Chrome for an example on how to bundle Google Chrome as an AppImage.

[Gridlocked]

I'd probably need some hand holding the 1st time doing that such as there are 3 .deb packages that have to be melded together. But I would gladly offer my computer time to compile these and then test. I try that exact example Saturday and see how far I can get.

[probonopd]

Run on a debian or Ubuntu system:

wget "https://github.com/probonopd/AppImages/raw/master/recipes/meta/Recipe"
wget "https://github.com/probonopd/AppImages/raw/master/recipes/meta/Ungoogled_Chromium.yml"
bash -ex Recipe Ungoogled_Chromium.yml

This will use the latest ungoogled-chromium deb files available on GitHub Releases and convert them into an AppImage. Please provide wheezy packages that could be used as ingredients for the AppImage. This would make the AppImage run on older but the most recent systems, too.

[Gridlocked]

I'll run that tonight. It should work on Fedora after creating the appimage?

[probonopd]

It should. Let me know if it doesn't.

[Lesik]

This is a horrible solution. Packaging precompiled binaries including all libraries into some container isn't a real repo. What's next, we bundle openssl into our binaries? The packages need to be dynamically linked and natively compiled on the OS they're built for. If you don't have enough horsepower for that, use COPR or OBS. This is what the people want, a real repo, not some AppImage one-archive-fits-them-all-but-in-a-really-crappy-way solution.

[probonopd]

@Lesik it's not an either-or. Why not have both. Strange as it may feel to you, a "real repo" is not what all people prefer, because it's always targeting only one specific distro. And yes, if you download Chromium for macOS or Windows, too, it comes with its own set of libraries that are not shared with other applications.

[Lesik]

@probonopd The way software is distributed on OS X and Windows is wrong and broken in my opinion, and also the reason why the security on those systems is laughable. As an example, if your application bundles openssl, and a critical vulnerability in openssl is discovered, your system won't be patched right when the openssl update is released, it will stay unpatched until your application delivers an update.

[probonopd]

Which is why the application should try to work with the system openssl instead. Which openssl does the official Google Chrome use?

[Lesik]

I assume the bundled one. But that's kinda acceptable because Google is quick to release an update in a matter of hours, and Chrome auto-updates itself without user confirmation, whereas we are a volunteer project and it might take days until someone gets his hands to building the binary, then a few more days until the AppImage is updated and distributed, and only then the users receive the patch.

[Eloston]

There is no clearly better option. Both options have their benefits and drawbacks that end up making them useful in different scenarios. A debate about this specific topic (i.e. whether bundled packages or dynamically-linking packages are universally better) is thus pointless. As seen in your last few posts, real applications have their own situations and objectives that makes one or the other the "better" option.

it's not an either-or. Why not have both.

This is the solution we're aiming for. AppImage and the semi-static Linux build will cover the platforms that would be too much for the current contributors to handle. Until someone adds support for Fedora (presumably after 56 has been released), Fedora users will have to use the aforementioned options.

[Gridlocked]

[QUOTE]Run on a debian or Ubuntu system:

wget "https://github.com/probonopd/AppImages/raw/master/recipes/meta/Recipe"
wget "https://github.com/probonopd/AppImages/raw/master/recipes/meta/Ungoogled_Chromium.yml"
bash -ex Recipe Ungoogled_Chromium.yml

This will use the latest ungoogled-chromium deb files available on GitHub Releases and convert them into an AppImage. Please provide wheezy packages that could be used as ingredients for the AppImage. This would make the AppImage run on older but the most recent systems, too.[/QUOTE]

1st 2 commands no problem, at the very end of a lengthy response to the bash command I get this -

--2017-02-11 11:14:07-- https://github.com/Eloston/ungoogled-chromium/releases/download/55.0.2883.87-1/chromedriver_.deb
Resolving github.com (github.com)... 192.30.253.112, 192.30.253.113
Connecting to github.com (github.com)|192.30.253.112|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2017-02-11 11:14:07 ERROR 404: Not Found.

[probonopd]

Should be fixed in AppImageCommunity/pkg2appimage@cb68c17

[Gridlocked]

That did the trick. I now have -

Ungoogled_Chromium_Web_Browser-55.0.2883.87.glibc2.15-x86_64.AppImage

I'll try it on Fedora later today.

[probonopd]

Some fine tuning will probably be necessary. Specifically, be aware that it will only run on Linux distributions no older than the one this was compiled on. So to maximize compatibility, compile on an older system.

[Gridlocked]

I've got it on Mint right now. I wanted to try running the appimage in firejail but I'm doing something wrong.12.02.2017, 16:20, "probonopd" <notifications@github.com>:Some fine tuning will probably be necessary. Specifically, be aware that it will only run on Linux distributions no older than the one this was compiled on. So to maximize compatibility, compile on an older system. —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.

[probonopd]

@Gridlocked what error did you get?

[Gridlocked]

firejail --appimage Ungoogled_Chromium_Web_Browser-55.0.2883.87.glibc2.15-x86_64.AppImage
Error: cannot access AppImage file

[probonopd]

That sounds more like a generic firejail issue on the system than something with this specific AppImage. Do other AppImages run?

[Gridlocked]

It runs great without firejail so I agree.12.02.2017, 17:55, "probonopd" <notifications@github.com>:That sounds more like a generic firejail issue on the system than something with this specific AppImage. Do other AppImages run? —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

[probonopd]

May be worth reporting at https://github.com/netblue30/firejail/issues.

[Gridlocked]

Works on Fedora!!

[probonopd]

@Gridlocked personally I wouldn't want to get into the habit of downloading AppImages from "random" dropbox links, so possibly this project may consider to do official AppImages and upload them to GitHub Releases?

[Gridlocked]

I'll remove that - I just thought I'd make it available for someone to look at.

[probonopd]

@Gridlocked perfectly fine with a Dropbox link for such testing reasons, just wanted to suggest additionally a more official one ;-)

[Gridlocked]

Okay!14.02.2017, 14:12, "probonopd" <notifications@github.com>:@Gridlocked perfectly fine with a Dropbox link for such testing reasons, just wanted to suggest additionally a more official one ;-) —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

[Gridlocked]

Yes, that gives their project a huge number of possible users with a simple build process for Fedora, Suse, Korora, Redhat, Centos & likely some others I have left out.

[bill-mcgonigle]

The Appimage is cool - thanks to those who worked on building that. But just a little comment on direction:

The reason I'm running Chromium from the Fedora repo is because I thought, erroneously apparently, that the delta between Chrome and Chromium was what it turns out is the delta between Chrome and ungoogled-chromium. Some of the behaviours of regular Chromium, as outlined on this project page, run contrary to Fedora Packaging Guidelines for including non-free code, so there must be exceptions currently granted to Chromium to make it into Fedora.

Long story short - if a version of ungoogled-chromium were packaged as a standard Fedora package, using the existing chromium.spec as a baseline, I would not be surprised if the Fedora steering committee decided that ungoogled-chromium should be the version officially shipped and supported in Fedora. It's definitely more in line with the free software ethos of the Fedora Project.

[eLement87]

+1
It would be awesome to have a Fedora Version of ungoogled-chromium.

[probonopd]

The Appimage is cool - thanks to those who worked on building that.
if (...) I would not be surprised if the Fedora steering committee decided that ungoogled-chromium should be the version officially shipped

That is the main philosophical difference - with distribution packaging, applications must be "in line with" and "supported by" the distribution in order to have a good user experience, whereas AppImage is explicitly built to enable upstream application authors to provide their software in a format that runs well without such approval.

[eLement87]

Excuse me for report an issue in the wrong repository. But i believe, it helps others to create the Ungoogled-Chromium AppImage.

@probonopd - in your Ungoogled_Chromium.yml
in Line 14
| cut -d "/" -f 8)
must be
| cut -d "/" -f 6) to get the Version

and in Line 15 the Packename
chromedriver_${VERSION}amd64.deb
must be
chromium-driver${VERSION}_amd64.deb

After that Changes i'm able to "Compile" the AppImage.
In Fedora 25 it works so far. Thank You.

[probonopd]

@eLement87 thanks, changed.

[intika]

AppImages builds are now available... ;)

[qvint]

I would like to present to you ungoogled-chromium-fedora which was forked from the Fedora chromium package to make it possible to build ungoogled-chromium as RPM-files.