Re: [sabayon-dev] Status of ebuilds in Bugzilla
On 07/24/2014 01:09 AM, Mitch Harder wrote: On Wed, Jul 23, 2014 at 11:11 PM, NP Hardass np.hard...@gmail.com wrote: I've submitted two ebuilds to the Sabayon bugzilla at this point. The first of which has been sitting, without any interaction for around 8 months. I wanted to find out what is going on. https://bugs.sabayon.org/buglist.cgi?email1=np.hardass%40gmail.comemailassigned_to1=1emailreporter1=1emailtype1=substringorder=Importancequery_format=advancedresolution=--- Thanks in advance for your time. -- NP-Hardass I agree, 8 months is too long. The issue with media-sound/pithos should be solved (I hope). Fabio dropped the Sabayon overlay version in favor of the version now in the main Gentoo portage tree. This just happened a few days ago. Let us know if this solves the problem. As far as pipelight goes, we'll try to have a look at that one. At this time, I dont' have a Netflix account, so we'll need to attract the attention of a Sabayon developer who does. It seems that there was some duplication of effort between Sabayon and Gentoo with regard to pipelight. I had started packaging pipelight last year, but the build system had issues that made it inappropriate for the main tree until about 6 months ago. Unfortunately, fixing it was a low priority until a week or two ago when I finally took the time to finish the packaging process. This was a joint effort between myself and pipelight upstream, which did ebuild review. The result is now in the main tree. I suggest removing pipelight from the sabayon overlay to resolve sabayon bug #4758. signature.asc Description: OpenPGP digital signature
Re: [sabayon-dev] Sabayon Development
On 02/03/2013 07:31 PM, Johannes Findeisen wrote: Hello all, I switched from Gentoo to Sabayon some weeks ago. After a try in a virtual machine some month ago I decided to run Gentoo in a virtual machine and as host to use Sabayon. I am very impressed about the stability and work you all have done to make this wonderful Gentoo based distribution possible. Thanks! Since I am using Gentoo since 2001 or 2002 am very deep into that distribution. I wrote at that time some ebuilds and switched some servers from distribution X to Gentoo for getting more performance... ;) My servers are still running Gentoo but my desktop is Sabayon. My question: Is there some documentation about the development workflow for Sabayon? I really would like to come deep into Sabayon like I was in Gentoo. Some entry points would be very nice! Thank you very much. Regards, hanez The emerge and ebuild commands are available on Sabayon. I am not familiar with Sabayon's entropy, but lxnay et al use emerge to build binary packages, which are distributed in entropy's binary package format. If you have special needs, you can develop ebuilds on Sabayon just like you did on Gentoo. Bugs for things that apply to both (e.g. new packages) could be filed with either Gentoo or Sabayon. If in doubt, you should file them with Sabayon. signature.asc Description: OpenPGP digital signature
Re: [sabayon-dev] Raspberry Pi
On 06/22/2012 02:08 PM, Anthony G. Basile wrote: On 06/22/2012 09:58 AM, Fabio Erculiani wrote: Last I knew is that Ras Pi is ARMv6... We have two armv7 repos already (softfp and hardfp). I don't have a ras pi, so I don't know. Anyhow, I mentioned that I hardened the armv7a toolchain and binaries because of the discussion on hardening on this list some time ago. I should also add that the hardened/arm profiles are now on the gentoo tree. Armv7 is incompatible with Armv6. This is why Ubuntu will not run on the Raspberry Pi: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=9t=5150 signature.asc Description: OpenPGP digital signature
Re: [sabayon-dev] [gentoo-dev] Killing UEFI Secure Boot
On 06/20/2012 04:08 PM, Greg KH wrote: On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote: I know that there is a great deal of discussion on the effect that UEFI Secure Boot will have on us. As far as I know, Secure Boot is implemented in the UEFI firmware and if we replace the firmware, Secure Boot issues disappear. Stop right there. That's just not going to happen, sorry. You aren't going to be able to get a user to replace their BIOS, nor should you ever want to. You are not going to be able to keep up with the hundreds, if not thousands, of different motherboards being introduced every month, in order to just get rid of the secure boot option. OpenWRT does that with routers and Cyanogenmod does that with phones. It seems reason for us to offer it as an option to users. With that said, this probably won't happen. One of the Core Boot developers informed me of what is involved in setting up the address space and it is infeasible for us to do. And I want secure boot on my machines, with a key I trust, don't you? If not, why not? I know lots of others that also want this, why deny them the ability to run Gentoo on their hardware? To be clear, I was not talking about taking away options from users. I was talking about giving them options.
[sabayon-dev] Killing UEFI Secure Boot
I know that there is a great deal of discussion on the effect that UEFI Secure Boot will have on us. As far as I know, Secure Boot is implemented in the UEFI firmware and if we replace the firmware, Secure Boot issues disappear. With that in mind, I believe we can solve the Secure Boot problem by installing Gentoo on PC hardware like how OpenWRT is installed on routers. http://wiki.openwrt.org/doc/techref/flash.layout We can extend genkernel to produce images similar OpenWRT images. This image would have partitions. In particular, it would have one for the bootloader, another for the kernel and a third for an optional root filesystem. The bootloader partition would be further divided between boot code and the NVRAM, which would contain bootloader settings. The bootloader would read the NVRAM to obtain the kernel command line that it provides to the kernel and then boot it. THe kernel would then be responsible for initializing hardware and mounting the rootfs. We will need boot code designed to start after RESET, read the NVRAM, configure the memory address space, load the kernel and jump into it. It would also handle any other things that either the kernel requires or that users want, such as a VGA text console before the kernel boots. A VGA console will require additional documentation from vendors, but routers seem to boot fine without it and our systems should too. x86 hardware emulates an 80386 environment at RESET, so we should be able to use documentation on 80386 to assist in development: http://css.csail.mit.edu/6.858/2011/readings/i386.pdf Das U-Boot and RedBoot are typically used on routers, but unlike RedBoot, Das U-Boot supports x86. In addition, the knowledge and tools necessary to develop on physical hardware are quite accessible: http://openschemes.com/2009/10/20/installing-a-plcc-eeprom-socket-onto-a-mobo/ http://www.sivava.com/EPROM_Programmer_5.html Developing on physical hardware could be tedious and time consuming, so it would probably be best to develop this on virtual hardware first. VMWare in particular uses a Phoenix BIOS. My expectation is that developing this on VMware's virtual hardware will help avoid issues when development moves to physical hardware. In addition, instructions are available for booting custom BIOS images, which is precisely what we need to develop this: http://pete.akeo.ie/2011/06/extracting-and-using-modified-vmware.html I know that the Core Boot project also tries to accomplish this, but their development process is slow and their approach seems to make the boot process more complicated than it needs to be. Since Secure Boot will force us to flash our BIOS chips (or stick to old hardware), I think it would be worthwhile to develop our own solution by extending genkernel. This should have the benefit of making our systems boot faster. This should open the door to further genkernel extensions, such as the creation of an initramfs that provides a general purpose GRUB replacement. This would enable us to flash the BIOS only once and then boot newer kernels (or even other operating systems) by adding entries to the NVRAM. It would still be faster than Core Boot because the kernel in the BIOS chip should still be able to mount the rootfs and boot the system. Does anyone have any thoughts, comments or suggestions? signature.asc Description: OpenPGP digital signature
Re: [sabayon-dev] [gentoo-dev] Killing UEFI Secure Boot
On 06/19/2012 08:22 PM, Rich Freeman wrote: On Tue, Jun 19, 2012 at 6:11 PM, Richard Yao r...@gentoo.org wrote: I know that the Core Boot project also tries to accomplish this, but their development process is slow and their approach seems to make the boot process more complicated than it needs to be. Since Secure Boot will force us to flash our BIOS chips (or stick to old hardware), I think it would be worthwhile to develop our own solution by extending genkernel. This should have the benefit of making our systems boot faster. So, replacing a BIOS is a fairly tall order - I'm not convinced that Core Boot is slow simply because they're doing it wrong. They're also looking to add value (like booting a diskless server off of a random website or whatever - not just simple disk/PXE like most BIOS). My understanding is that clusters are one of their big use cases. Core Boot is a Linux distribution. I do not think that we should boot Gentoo using their distribution any more than we boot Gentoo using RHEL. I also don't get the claim that we need to flash our BIOS chips to get around secure boot. If you don't want to use secure boot just disable it - it is no harder than changing your boot device order, system time, or any of a myriad of other firmware settings. It gets more complicated if you want to keep secure boot but boot your own OS, since you have to manage the keys/signing/etc. In theory, the kernel could be modified to only execute signed binaries and portage could be modified to produce signed binaries. The user could build a system that required everything to be signed with the private key of his choice. A hardened system that required signed binaries would be even more secure than a typical system using Secure Boot where only the bootloader, kernel and kernel modules are signed. The user would be in full control of his hardware. The user would not need to pay for this and the system would also boot faster. Nothing is keeping anybody from creating their own firmware. However, I doubt we'll see 25 devs take this on as a full-time job, which is probably what it would take to support the bazillions of boards out there. Keep in mind that many motherboard vendors require signed firmware so you'll need to find an exploit for every make/model out there to even load your firmware. That seems a bit much compared to just disabling secure boot... The 80386's RESET state is emulated uniformly across all x86 and amd64, so it should not take much effort to support the basic functions of setting up the CPU, loading the kernel (from the EEPROM) and jumping into it. Everything else is secondary. Those are the only things that a BIOS replacement needs to do. As you pointed out, Core Boot is trying to add value. That means that they are doing far more than those basic functions. Other features are nice, but not if they get in the way of being able to boot. Other things can come the system boot process works. Basic functionality would only require the work of a few people. Things beyond that (e.g. pre-kernel VGA console initialization, pre-kernel networking, etcetera) might require vendor support through documentation. I would be thrilled if 25 developers wanted to work on this full time, but I am not certain that would make sense. Linux already has thousands of developers working on hardware support, including developers from Intel. We should be able to leverage that. Did I miss any technical obstacles?
