[gentoo-dev] Last rites: sys-fs/cloudfuse

[Erik Mackdanz]

# 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

[Erik Mackdanz]

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

[Erik Mackdanz]

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

[Erik Mackdanz]

Matthew Thode prometheanf...@gentoo.org 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

[Erik Mackdanz]

William Hubbs willi...@gentoo.org 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

[Erik Mackdanz]

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