[gentoo-user] Re: Anyone running gentoo on AppleTV 1st gen?
Mick gmail.com> writes: > I've come across an AppleTV 1 box and been searching the Interwebs > for gentoo related info. > http://kodi.wiki/view/Archive:HOW-TO:Install_Gentoo_and_XBMC_on_Apple_TV_1 > https://github.com/davilla/atv-bootloader Hello Mick, I just ran across these busybox archives and thought you might peruse the links for info. 'Buildroot: latest "target/device/Atmel" tree' https://git.busybox.net/ Also, follow those folks by name when googling as new projects often have old, familiar hack(ers) underneath. hth, James
[gentoo-user] Re: Anyone running gentoo on AppleTV 1st gen?
James tampabay.rr.com> writes: > I just ran across these busybox archives and thought you might > peruse the links for info. > https://git.busybox.net/ Sorry,I grabbed the wrong text:: ~jacmet/git/atvtool AppleTV utility program jacmet https://git.busybox.net/~jacmet/git/atvtool/ James
[gentoo-user] Re: dev-python sub-categories?
James tampabay.rr.com> writes: > > > So /usr/portage/dev-python is around 1500 packages. Is it time to > > > create some new categories to reduce this size, or is it ok, in the > > > "gentoo-way" for everything /python/ to be lumped into dev-python/? > > I think you have asked this question on the wrong mailing list. > > gentoo-dev would be more appropriate. > > It is rhetorical in nature:: just looking for ideas and wise guidance from > some other old farts and youngsters. Wow, we are now getting close to a portage tree /dev-python/ audit and discussion? >From the gentoo-dev list:: > dev-python/configshell > dev-python/rtslib I looked at whether these should be owned by the Python team, but I don't think they should be. It looks like they're low-level utilities that happen to be written in Python. As such, they probably shouldn't even be in dev-python. (OH)- (S0)- close. Really, somebody with a bit more python expertise than me should really put forward this discussion on gentoo_dev. James
Re: [gentoo-user] Re: Anyone running gentoo on AppleTV 1st gen?
On Thursday 31 Mar 2016 17:32:25 James wrote: > James tampabay.rr.com> writes: > > I just ran across these busybox archives and thought you might > > peruse the links for info. > > https://git.busybox.net/ > > Sorry,I grabbed the wrong text:: > > ~jacmet/git/atvtool AppleTV utility program jacmet > > https://git.busybox.net/~jacmet/git/atvtool/ > > James Thanks James, OSMC have developed an easy to install image, which however does not have APM enabled to handle the buggy BIOS. So I may be rolling my own kernel for this when I get a minute and/or install gentoo if I need to. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: Anyone running gentoo on AppleTV 1st gen?
Mick gmail.com> writes: > > > https://git.busybox.net/ > > ~jacmet/git/atvtool AppleTV utility program jacmet > > https://git.busybox.net/~jacmet/git/atvtool/ > Thanks James, OSMC have developed an easy to install image, which however > does not have APM enabled to handle the buggy BIOS. So > I may be rolling my own kernel for this when I get a minute and/or > install gentoo if I need to. Ah, this is fantastic news. Would it be possible to make your efforts, generic, so that some of the effort and docs might be applicable to anyone that wanted to put 'gentoo' on a samygo capable TV? [1] In fact you might want to google with an additional keyword 'samygo' to see what codes you can discover to simplify your efforts. [2] I guess I'm saying with the proliferations of smart TVs with wifi, it only makes sense to consolidate this intel into a collection somewhere. And Samsung makes chips for both TVs and cell phones that are quite similar:: think exynos. In fact most all cell phones and smart TVs are consolidating codes onto multi-core arm64 processors, so it make a ton of sense to me for gentoo to take a 'gentoo on all' approach to this smorgasbord of arm64 devices. [3] hth, James [1] https://wiki.samygo.tv/index.php5?title=Main_Page [2] http://ericasadun.com/ftp/AirPlay/ [3] http://liliputing.com/2013/03/android-tv-box-with-samsung-exynos-4412-quad-core-chip-now-available-for-120.html
[gentoo-user] embedded (gentoo) cloud?
Well, Just as research was propelling me out of the closet, to proclaim that embedded (linux) systems are to become the backbone of the new clouds and clusters, somebody beat me to the punchline. Linaro, which is pretty much the largest collection of deep pocketed folks in the embedded (arm64) game, has just announced debian and centos versions of embedded Linaro for the cloud [1]. They have a large cache of ported codes including but not limited to cephfs. That makes sense why docker, currently the commercial leader in containers, has subsumed Alpine Linux and it's OpenRC + Eudev platform for speed of deployment and HPC performance advantages. [2] Also, systemd issues abound in the cloud/cluster world. OpenRC's pathway to codes interfaced directly to cgroups is proving to be quite the performance advantage, particularly for specifically tuned clusters. Still, since gentoo supports both OpenRC and Systemd, I'm just not sure why somebody is not promoting gentoo as the best distro reference system for the cloud-of-Things and Hi-Performance-Clusters. Since I have been digging deeply into these and other related issues, Gentoo is everywhere, but just not getting the public recognition it deserves as a distro and cloud/cluster enabler. Perhaps all commercial vendors are actually scared of the power of the Gentoo? Some have projected that if you run your clouds and clusters directly on gentoo, you do not need vendors but more technical (gentoo) experts. Methinks so! enjoy! James [1] http://www.linaro.org/news/linaro-announces-arm-based-developer-cloud-2/ [2] https://www.brianchristner.io/docker-image-base-os-size-comparison/
[gentoo-user] Re: Blacklisting all packages from overlay except a specific group and version
On 31/03/16 09:11, Alan McKinnon wrote: On 31/03/2016 00:13, Nikos Chantziaras wrote: "Invalid atom in /etc/portage/package.unmask/qt: =dev-qt/*-5.6*::qt" (Doesn't work with or without the "::qt".) It's the leading "*" that's wrong there, because it's not a glob or a regex; it's more a placeholder metacharacter with it's own rules. Look at the relevant section in man 5 ebuild. It's not explicit but it does strongly hint that "*" goes at the end of a string It didn't look like it to me at all. From the man page: Examples: # match anything with a version containing , which can be used in # package.mask to prevent emerge --autounmask from selecting live # ebuilds =*/*-** So if that works, one would assume that "=dev-qt/*-*5.6*" should work just as well :-/
