[gentoo-dev] Last rites: sys-fs/cloudfuse
# Erik Mackdanz (6 Feb 2019) # Dead upstream #677400 # Masked for removal in 30 days. sys-fs/cloudfuse
[gentoo-dev] package up for grabs: media-sound/forked-daapd
I haven't used or updated this package for a long time. However upstream is still active and there are some users. I've removed myself as maintainer and changed bug ownership to maintainer-nee...@gentoo.org Thanks, Erik
Re: [gentoo-dev] RFC: Eclasses and EAPI
Kristian Fiskerstrand writes: > inherited eclasses. having a whitelist in place and die if eclass is not > updated to handle it solves it. > > Thoughts? comments? cookies? threats? Wouldn't a blacklist be more practical than a whitelist? root# cat /usr/portage/profiles/eclass.eapi.mask fooutils.eclass >=6 The problem seems infrequent enough that a blacklist is sufficient, like all the *.mask files in /usr/portage/profiles. The whitelist places a large testing burden on eclass authors on each EAPI bump, where 99% of the time there won't be any issue to fix. Erik
Re: [gentoo-dev] openstack image update
Matthew Thode writes: > I've updated the openstack images to make them smaller, make them work > with dynamic ethernet interface add/delete, and make the disk resize on > first boot. I've also made nomultilib and hardened images. Good work on these images, prometheanfire. I've launched a few instances and they work nicely. I have some feedback: - root can log in at the console with no password. This may have been intentional but it's unusual in the industry. Consider a 'passwd -l root' to lock the account from any access (until a sudo'ed 'gentoo' user decides to set one). - I noticed there is a reboot during the first launch. I assume this is because of the disk resize. Consider these two other mechanisms for accomplishing the resize (I've implemented both at my job, but in other distros). 1) The initramfs has additional code that grows the / partition before it is mounted. Probably genkernel doesn't support this today, but it could. 2) / is on a small LVM logical volume. At early boot, an 'lvextend' grows the lv to use the full disk without requiring the kernel to re-read the partition table. This is the approach most distros take. Eliminating the reboot would shave some time off the launch. Also cloud-init would be able to execute its new-instance code on the system's final state (larger disk) instead of the intermediate (pre-reboot, small-disk) state. - I see the kernel sources are deleted (and a dangling symlink remains). What Rackspace has done with its Gentoo images (and I've appreciated it) is leave the kernel sources there. If I need some obscure module, I can quickly build the single module and modprobe it. I was able to make kernel adjustments by using /proc/config.gz, re-installing the sources, building, and rebooting. It just took longer. - The root disk is 5GB, and can grow from there. If it could fit into 1G, then m1.tiny's could be launched. This is probably a low-value activity since 1G is hard to achieve (no portage tree!) and m1.tiny's aren't useful generally. Thanks for considering these enhancements for future builds. I'd love to hear feedback on any of these suggestions. -- Erik Mackdanz
Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages
William Hubbs writes: > The only thing locked to their platform really is the web ui or their > api. Even pull requests really aren't, because git has the > "git request-pull" command. Not true. Github pull requests are for pulling from other Github repos/branches only, and they store unique metadata (e.g. comments, issues) outside of the repo. It is truly a lock-in feature. "git request-pull" simply formats an email template to tell someone how they may pull from you, but Github makes no attempt to process such a message or turn it into a Github pull request. Any Github presence of the tree will result in Github issues being submitted and Github pull requests coming across. We'd have to be prepared to chain that into our existing processes or have someone dedicated to closing every issue/pull request with "Use bugzie". -- Erik Mackdanz
Re: [gentoo-dev] [RFC] gentoo-openstack project
At Sun, 10 Mar 2013 16:57:07 -0500, Matthew Thode wrote: > > Starting up a new project (gentoo-openstack). It is currently a > subproject of virtualization and our project page can be found here. > > http://www.gentoo.org/proj/en/virtualization/openstack/ > > The current goals are to flesh out the support for Openstack on Gentoo > (we have the ebuilds in tree, but initscripts and the like need some > work). We also want to maintain better security release upstream (as > they do not make interim security releases during their release cycle. > > We have a bug alias as well as a list (openstack and gentoo-openstack > respectively). > > Any advice is welcome :D > > -- > -- Matthew Thode (prometheanfire) > I'm interested in this, and I think a lot of folks are. I've noticed there's a pretty thorough, active overlay in the wild: https://github.com/hyves-org/openstack-overlay Have you reached out to that guy? Erik