Bug 193106 - New-port: emulators/linux_base-f20 : Add a port with the base libraries for Fedora 20.
Summary: New-port: emulators/linux_base-f20 : Add a port with the base libraries for F...
Status: Closed Not Accepted
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-emulation (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-28 22:23 UTC by Vassilis Laganakos
Modified: 2018-01-16 19:52 UTC (History)
7 users (show)

See Also:


Attachments
the .shar file for linux_base-f20 (132.40 KB, application/x-shar)
2014-08-28 22:23 UTC, Vassilis Laganakos
no flags Details
poudriere build log for linux_base-f20 (22.26 KB, text/plain)
2014-08-30 11:02 UTC, Vassilis Laganakos
no flags Details
the .shar file for linux_base-f20 (132.74 KB, text/plain)
2014-09-05 19:08 UTC, Vassilis Laganakos
no flags Details
poudriere build log for linux_base-f20 (23.15 KB, text/plain)
2014-09-05 19:09 UTC, Vassilis Laganakos
no flags Details
the .shar file for linux_base-f20 (132.74 KB, text/plain)
2014-12-14 23:25 UTC, Vassilis Laganakos
no flags Details
poudriere build log for linux_base-f20 - 11amd64 (21.93 KB, text/plain)
2014-12-14 23:26 UTC, Vassilis Laganakos
no flags Details
poudriere build log for linux_base-f20 - 10amd64 (21.71 KB, text/plain)
2014-12-14 23:26 UTC, Vassilis Laganakos
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vassilis Laganakos 2014-08-28 22:23:44 UTC
Created attachment 146474 [details]
the .shar file for linux_base-f20

This is the base for the rest of the Fedora 20 ports that I've put together.

It installs in /compat/linux some of the basic Fedora 20 packages. It has been tested with the rest of the -f20 ports, and when you have all of them installed you can have Firefox, with the flashplugin and nsplugin wrapper for -f20, to be able to play videos from youtube with sound (oss).

The system these were developed and tested is FreBSD 11.0-CURRENT amd64, built from lemul branch.
Comment 1 Carlo Strub freebsd_committer freebsd_triage 2014-08-29 19:47:11 UTC
Please provide us with redports.org or poudriere logs that confirm your port is working fine.
Comment 2 Vassilis Laganakos 2014-08-30 11:02:47 UTC
Created attachment 146527 [details]
poudriere build log for linux_base-f20

Atached linux_base-f20 poudriere build log, as requested.
Comment 3 Vassilis Laganakos 2014-08-31 14:13:37 UTC
Please let me know if there's anything else I should provide :)
Comment 4 Vassilis Laganakos 2014-09-05 19:08:16 UTC
Created attachment 146880 [details]
the .shar file for linux_base-f20

Updated the base port with a missing dependecy, nss-softokn-freebl.
Comment 5 Vassilis Laganakos 2014-09-05 19:09:09 UTC
Created attachment 146881 [details]
poudriere build log for linux_base-f20

and the respective poudriere build log.
Comment 6 Kurt Jaeger freebsd_committer freebsd_triage 2014-10-05 15:53:51 UTC
(In reply to Vassilis Laganakos from comment #3)
> Please let me know if there's anything else I should provide :)

In the meantime, linux-c6 was committed. This port probably conflicts with
that, am I correct ?
Comment 7 Kurt Jaeger freebsd_committer freebsd_triage 2014-10-05 16:18:04 UTC
(In reply to Vassilis Laganakos from comment #3)
> Please let me know if there's anything else I should provide :)

If I build it using poudriere on 10.0-amd64 or 9.1-amd64 or 8.4-i386,
it has this error:

====> Running Q/A tests (stage-qa)
====> Checking for pkg-plist issues (check-plist)
===> Parsing plist
===> Checking for items in STAGEDIR missing from pkg-plist
Error: Orphaned: usr/bin/bin
Error: Orphaned: usr/lib/lib
Error: Orphaned: usr/sbin/sbin
Error: Orphaned: var/lock/lock
===> Checking for items in pkg-plist which are not in STAGEDIR
Comment 8 Kurt Jaeger freebsd_committer freebsd_triage 2014-10-05 16:22:11 UTC
(In reply to Kurt Jaeger from comment #7)
> Error: Orphaned: usr/bin/bin
> Error: Orphaned: usr/lib/lib
> Error: Orphaned: usr/sbin/sbin
> Error: Orphaned: var/lock/lock

Those are symlinks from /usr/bin/bin to /compat/linux/bin. Are they needed ?
Comment 9 Vassilis Laganakos 2014-10-12 12:07:36 UTC
(In reply to Kurt Jaeger from comment #6)
> (In reply to Vassilis Laganakos from comment #3)
> > Please let me know if there's anything else I should provide :)
> 
> In the meantime, linux-c6 was committed. This port probably conflicts with
> that, am I correct ?

I believe so, I'll fix the linux_base-c- to cover the CONFLICT with that.
Comment 10 Bartek Rutkowski freebsd_committer freebsd_triage 2014-10-20 08:26:32 UTC
Removing from PatchReady pool as it needs some more work.
Comment 11 Vassilis Laganakos 2014-12-14 23:25:26 UTC
Created attachment 150588 [details]
the .shar file for linux_base-f20

Updated SHAR file for linux_base-f20 - includes the conflict with linux_base-c6-*
Comment 12 Vassilis Laganakos 2014-12-14 23:26:04 UTC
Created attachment 150589 [details]
poudriere build log for linux_base-f20 - 11amd64
Comment 13 Vassilis Laganakos 2014-12-14 23:26:25 UTC
Created attachment 150590 [details]
poudriere build log for linux_base-f20 - 10amd64
Comment 14 Vassilis Laganakos 2014-12-14 23:31:47 UTC
Register the conflict with linux_base-c6 port.

I built it for 10am64 jail in poudriere but it didn't give me any errors.
The links in should be from /compat/linux/{bin,lib,sbin} to /compat/linux/usr/{bin,lib,sbin}; Do you still get orphaned links from /usr/{bin,lib,sbin,lock}?
Comment 15 Johannes Jost Meixner freebsd_committer freebsd_triage 2015-01-27 17:28:22 UTC
Have you tried what happens when you use linux_base-f20 with the linux-c6-* ports?

I remember doing that with linux_base-c6 and linux-f10- ports, and I'm curious to see if something like that works with a modern / F20 base + glibc, etc.
Comment 16 Johannes Jost Meixner freebsd_committer freebsd_triage 2015-01-27 17:28:44 UTC
Reassign to emulation@
Comment 17 Vassilis Laganakos 2015-03-23 20:27:51 UTC
Any chance this is going to be reviewed soon? I have about another 100 ports for fedora 20 that get flashplugin to work in Firefox (and Skype messaging as well) on lemul branch :)
Comment 18 Ivan 2015-06-19 08:25:32 UTC
What's the status of this project? I'm using f20 repo on FreeBSD11-CURRENT, as c6 is too outdated. We already have knobs to choose what base port fetch, why not add this and bump to f22 after that?
Comment 19 Piotr Kubaj freebsd_committer freebsd_triage 2015-07-21 10:59:42 UTC
(In reply to Ivan from comment #18)
It seems we're going to get CentOS 7 ports.
https://www.freebsd.org/news/status/report-2015-04-2015-06.html#Linux-Binary-Emulation-Layer-Upgrade


IMHO it's a better choice than Fedora, since it's supported for 10 years, instead of 13 months.
Comment 20 Ivan 2015-07-21 18:22:52 UTC
New emulation can run linux games, they generally required more up-to-date libraries that CentOS can provide.
Comment 21 Piotr Kubaj freebsd_committer freebsd_triage 2015-07-21 18:35:46 UTC
(In reply to Ivan from comment #20)
I believe CentOS 7 is actually quite up to date as well. Of course, it would be better to follow Fedora, but that requires:
1. manpower to maintain always-changing new Fedora packages,
2. manpower to maintain Linuxulator, since packages from e.g. Fedora 25 may start to depend on syscalls that are not available in FreeBSD.
Comment 22 Johannes Jost Meixner freebsd_committer freebsd_triage 2015-07-21 20:51:58 UTC
(In reply to pkubaj from comment #21)
> I believe CentOS 7 is actually quite up to date as well. Of course, it would be better to follow Fedora

CentOS 6 was based off Fedora 12.
CentOS 7 is based off Fedora 19.
By the time we're talking about Fedora 25,
RedHat will do a RHEL 8.0.

ScientificLinux is the closest to RHEL, and CentOS is the friendliest in that the community is great to work with (especially #centos-social on Freenode!) and the longest-maintained distribution.

> but that requires:
> 1. manpower to maintain always-changing new Fedora packages,

Updating the packages isn't the Hard Part(tm). I updated the whole portstree's CentOS 6.5 base to 6.6 in four hours.

The hard part is making sure nothing that uses Linux in any currently maintained FreeBSD release breaks. Including Sun/Oracle Java, Flash, all Linux Games, etc.

> 2. manpower to maintain Linuxulator, since packages from e.g. Fedora 25 may start to depend on syscalls that are not available in FreeBSD.

In that Quarterly Report, we do send out a call for helpers. :-)
Comment 23 Piotr Kubaj freebsd_committer freebsd_triage 2015-07-21 20:56:55 UTC
(In reply to Johannes Jost Meixner from comment #22)
> In that Quarterly Report, we do send out a call for helpers. :-)


I really would like to help, but I don't really have skills enough for kernel programming :( Still, I'd like to somewhen get engaged in ports stuff.
Comment 24 Ivan 2015-07-22 13:09:19 UTC
(In reply to Johannes Jost Meixner from comment #22)
>The hard part is making sure nothing that uses Linux in any currently maintained >FreeBSD release breaks. Including Sun/Oracle Java, Flash, all Linux Games, etc.

To say the truth, most of that stuff is abandonware. Especially Linux games. Even firefox is crashing on youtube. The only useful stuff there is skype and flash
Comment 25 Johannes Jost Meixner freebsd_committer freebsd_triage 2015-07-23 08:58:21 UTC
(In reply to Ivan from comment #24)
The fact that you don't use them does not make the games abandonware.
You'd be surprised how many interactions with (FreeBSD) gamers I had after staging most of games/linux-* last year.
Comment 26 Johannes Jost Meixner freebsd_committer freebsd_triage 2015-07-23 08:59:41 UTC
(In reply to pkubaj from comment #23)
(offtopic) There are many ways in which you can help; one is testing the to-be-finished CentOS 6.6 64bit ports framework. With a bit of luck, it could work on FreeBSD 10.2-RELEASE already. We'll see.
Comment 27 Ivan 2015-07-23 09:32:11 UTC
(In reply to Johannes Jost Meixner from comment #25)
I can assure you, FreeBSD gamers will be happy if they will get access to f20 (or higher libraries), for example, f20 can run Unity engine (without a sound, to say the  truth, as pulseaudio require pi mutexes or more complex pulse wrapper we use to power skype).

And, I don't ask to scrap c6. We have f20 ports ready in Vassilis repository and we already have necessary knobs for make.conf 
Make c6 default, leave the possibility to use f20+. It's simple, isn't it?
Comment 28 Johannes Jost Meixner freebsd_committer freebsd_triage 2015-07-24 12:20:38 UTC
(In reply to Ivan from comment #27)
The f20 ports were never ready to begin with, and by now f20 is outdated. Plus, using fedora is not a good idea, because you'll continuously have to keep bumping their version (every six months, afair).

That being said: Chances are excellent things will run with CentOS 7, and we're obviously looking for contributors and every help possible to have it by early 2016.
Comment 29 Vassilis Laganakos 2015-07-28 13:01:45 UTC
Depends what do you mean by "ready".

The only thing that didn't work was the things that were depending on the pi stuff that wasn't yet supported in the linux emulation layer at the time. And that affected sound in skype for one.

Essentially the ports for f20 have been in place for about a year. So if the pi stuff is working now in the linux emulation layer, I see no reason why f20 wouldn't work.

I could easily bump the version of my set of ports to fedora 25; I've done the work already for all the f20 once, so it shouldn't take much time for it.

I think it would be good to give the users the option to chose which linux distro they would like to use, imho.
Comment 30 Ivan 2015-07-28 13:19:23 UTC
pi stuff is not working. dchagin had plans to implement it eventually, but without any ETA.
So, no pulseaudio support, yes. But that's applies to all distros. Wrapper was added to skype, but it's not enough to power any significant applications depending on pulseaudio.
Comment 31 Walter Schwarzenfeld 2018-01-14 04:11:11 UTC
No statement since 2015-07-28. I think this could be closed.
Comment 32 Tijl Coosemans freebsd_committer freebsd_triage 2018-01-16 19:52:17 UTC
Closing as rejected.  The problem is that Fedora doesn't support older releases with security updates long enough.  If we add a Fedora release to the ports tree then at some point it will have to be removed again and that never goes without complaints.  Users of older versions of FreeBSD may not be able to update to a newer Fedora release because their kernel lacks new Linux features that the new Fedora release needs.  Or worse, there's no FreeBSD release that can run the new Fedora release.  It happened with the f10 ports.

If people want more recent versions of some Linux packages then rather than trying to track Fedora it would be better to work on ports tree infrastructure that allows us to build our own Linux packages.