Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files
Santiago M. Mola wrote: e) use a hook around unpack on your local system to detect new build.xml for a list of packages. AFAIK, checking changes is part of the bump process, so I think that's a check you can do either at hand, with a script (it's always a good thing to look for new files in the project, or look at the diffs), or as I said in 'e)', use some tricks with /etc/portage/bashrc. That looks interesting. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
[gentoo-dev] Advice regarding backporting to Gentoo from Tin Hat.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, It was suggested to me that I write this list about backporting something to gentoo from Tin Hat which is a distro derived from hardened gentoo. First a bit of history: Last year a group of us decided to put together a linux distribution which aimed at the ideal that physical access to a box (at least when powered down) meant the attacker could get *no* information whatsover about the running system. (We concerned ourselves with issues like hard drive encryption hides the data, but some implementations like cryptsetup put down a header which would reveal to the attacker that there plausibly *is* encrypted data present. So we chose implementations in which the attacker would not be able to tell if he/she were looking at an encrypted drive or just random bits. Real toil foil hat stuff.) We also wanted a system that would be useful as a desktop and secure from all the usual suspects when running. We decided to use hardened gentoo as a base, but had to branch because 1) we had to restrict the choice of profile/USE flags, 2) we had to do unspeakably nasty things to the kernel, like compiling it monolithically for a wide range of hardware, 3) we had to build our own customized busybox, initramfs image and boot scripts up to /sbin/init and 4) we put the entire OS in RAM. Literally *everything* is done in RAM in tmpfs: updates pulled down with portage, compiling kernels, building ISO images for releases, etc, all done purely in RAM. Just using Tin Hat requires 4GB of RAM, while developing/building new releases requires 6GB-8GB. These number are no longer out of the range of reasonably priced computers. Point 4 is what I think would be useful to Gentoo mainstream. The speed one gets from RAM totally beats a LiveCD using unionfs which has to periodically return to the slow cdrom. I've tried building custom LiveCDs for courses that I've taught but the students (=users) hated them. In contrast I am now teaching an embedded systems course and I put all the needed utilities (eg. crosscompilers, qemu, etc) into a ramified system which the students love because of the speed. So I think many Gentoo users might like this feature and we could simultaneously develop the scripts for both Gentoo and its derivative Tin Hat. We have written a series of scripts to ramify a system. There are two versions: A) take an OS bound to the hard drive and build an ISO image which will boot and put the system totally into tmpfs, B) take a system which is already ramified and build an ISO which will again boot purely into RAM, ie build a snapshot. A user could use scprits A to ramify a custom built system and maintain it in ram with scripts B. Also, Gentoo releases could be distributed already ramified. To port this back, I would have to modify the scripts to deal with a modular kernel and the way initramfs is built using genkernel. I would also need to write the ebuild. No problem, but I would like some feed back from the list regarding whether this is something worth trying and any advice on how to proceed, eg. should we write our own portage overlay? The Tin Hat homepage is at http://opensource.dyc.edu/tinhat The repository is at http://opensource.dyc.edu/pub/TinHat - -- Anthony G. Basile, Ph.D. Chair of Information Technology D'Youville College Buffalo, NY 14201 USA (716) 829-8197 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmEbHoACgkQl5yvQNBFVTW61wCdFZHuxi8dtNCOfQh7VEYwv1q8 /zkAoKbanGQaCC6X1Nm7xKnSuNKUmXvw =k0KG -END PGP SIGNATURE-
Re: [gentoo-dev] Packages up for grabs
Donnie Berkholz wrote: app-misc/colordiff sys-process/iotop I picked up these two. metadata changed. I'll get to the bugs next week sometime. -Jeremy
Re: [gentoo-dev] Advice regarding backporting to Gentoo from Tin Hat.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiya Anthony, First off, it certainly sounds interesting and making it more accessible (simple ebuild setup and so on) seems like a good plan even if it doesn't get picked up officially. The best way to start development would probably be an overlay, which will make it easy to bring into the tree if/when a developer wants to pick it up officially. You might also want to look into integrating your ramification process into catalyst the gentoo release building tool (the release engineering team can probably tell you more about that than I can). Also, reading the TinHat front page and mention of ram dumping, you might be interested in [2]. It suggests not leaving the key in RAM when it's not necessary, but shoving it into the CPU cache... Mike 5:) [1] http://www.gentoo.org/proj/en/releng/catalyst/ [2] http://frozencache.blogspot.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmEcQgACgkQu7rWomwgFXp+3ACghLB+686vqMLqcEm9Ye3gM1JN KKQAoJ4R3dyx5KcVeg6+9OugRsCA0nha =MCQf -END PGP SIGNATURE-
Re: [gentoo-dev] Advice regarding backporting to Gentoo from Tin Hat.
basile wrote: Point 4 is what I think would be useful to Gentoo mainstream. The speed one gets from RAM totally beats a LiveCD using unionfs which has to periodically return to the slow cdrom. This is already possible. With current genkernel (genkernel- or genkernel-3.4.10.903), you can boot with 'docache unionfs', which will copy the squashfs to tmpfs, mount it, and then use unionfs-fuse to create a union with another tmpfs. Genkernel has offered the 'docache' option for quite a while, which has mostly the safe effect, but without the unionfs, it uses nasty tricks like copying some stuff to a tmpfs and then doing lots of symlinks into the squashfs. Either way, it's entirely memory based after initial boot. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] PR Project Activity Issues
On Fri, Jan 30, 2009 at 10:20 PM, Donnie Berkholz dberkh...@gentoo.org wrote: On 01:55 Tue 27 Jan , Alec Warner wrote: Getting Index2 live is I think a different operational issue (that changes to the website are very slow) and really has nothing to do with PR aside from them not nagging someone to commit it ;) In this case, Xavier had it ready in early January, and I was blocking on it for the last 2 weeks to write up an announcement. PR@ is a nghtmare of spam and what I'll term 'crap.' having real things marked as such with informative subjects would be useful. having some kind of rotation would be useful having some kind of vague 'we will read and respond within 3 days unless its a holiday' would be useful. Right now the expectations of pr@ are non-existent and apparently think the mail is read and answered quickly. In reality only Donnie reads it and replies; he has a busy as hell personal life and I'm surprised he manages to read it at all. So I would like to set expectations ;) Yes, it would be a good idea to put expectations wherever people find our contact info. Here's roughly what they are: 1. If it is a prewritten news item that needs editing, it will get a quick response. 2. If it is news that is not accompanied by a draft of some sort, no estimated response time. This point is where I think we have the biggest opportunity for improvement. 3. If it is an additional vendor listing for CDs, no estimated response time. These generally get batched and done at extended intervals. 4. If it is a user support request, no estimated response time. Occasionally someone will respond to say that we don't do support at pr@ and point at appropriate places like forums, lists, IRC. I'll try and transcribe these somewhere; email is not a good place for them. -Alec -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com
