Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

2013-01-18 Thread Benedikt Böhm
On Fri, Jan 18, 2013 at 9:13 AM, Michael Weber x...@gentoo.org wrote:

 I wonder if anybody uses unattended [backup+]emerge as cron job.
 I'm really temped to do so, but with users relying on these machines I'm
 always chicken-out.


i've refrained from doing unattended upgrades for a long time, but i'm
quite confident in updateworld these days and i usually test it on 2-3
machines and then let the other 50+ machines do it unattended and it has
been working fine so far ...

but - and that's quite important i guess - i only use my own clone of the
portage tree which i sync from time to time and i also keep different
versions stable, etc.


Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

2013-01-18 Thread Benedikt Böhm
On Fri, Jan 18, 2013 at 9:41 AM, Michael Weber x...@gentoo.org wrote:

 On 01/18/2013 09:28 AM, Benedikt Böhm wrote:
  but - and that's quite important i guess - i only use my own clone of
  the portage tree which i sync from time to time and i also keep
  different versions stable, etc.
 HEAVY USER! But you have full control.
 Do you have any sophisticated mechanism to detect tree breakage (i.e. us
 f*** up), like Samuli replying -commit to -dev or irc activity?

 Or do you simply delay commit? (re-schedule on weekends/nights)


i manually sync with the gentoo-x86 repo from time to time (except security
issues, which i sync as soon as they are fixed)

i have no automated way to detect any tree breakage, but when i sync the
complete tree i do extensive manual testing on a handfull of machines
(either staging machines, or ones that are not really important)

but the main reason i even have a clone is to sync updates in batches. it's
really a hassle to keep servers in sync when changes to gentoo-x86 happen
any other minute. i also need to adapt my chef cookbooks for some updates,
so i do it all in one batch (sync, test, adapt, test, deploy)


 Delaying stabilization seems legit, but on Gentoo-stable ?!


it's not really about delaying stabilization ... there is quite a big list
of packages in my repo where i always stabilize the latest version(s) even
if gentoo-x86 is unstable. e.g. i've stabled openrc a looong time before
gentoo-x86 had it stable, etc.

it's also a lot easier to add new packages because i don't have to support
everything and the kitchen sink ... my repo just supports amd64 and it also
has quite a few binary ebuilds which would not be a good fit for gentoo-x86

if you're interested, it's all on github:
https://github.com/zentoo/zentoo(all the sync tools are in the script
directory and were initially copied
from the prefix guys, but have been heavily modified since ...)

Cheers,
Bene


Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

2013-01-18 Thread Benedikt Böhm
On Fri, Jan 18, 2013 at 2:13 PM, Benedikt Böhm hol...@gentoo.org wrote:

 On Fri, Jan 18, 2013 at 9:41 AM, Michael Weber x...@gentoo.org wrote:

 On 01/18/2013 09:28 AM, Benedikt Böhm wrote:
  but - and that's quite important i guess - i only use my own clone of
  the portage tree which i sync from time to time and i also keep
  different versions stable, etc.
 HEAVY USER! But you have full control.
 Do you have any sophisticated mechanism to detect tree breakage (i.e. us
 f*** up), like Samuli replying -commit to -dev or irc activity?

 Or do you simply delay commit? (re-schedule on weekends/nights)


 i manually sync with the gentoo-x86 repo from time to time (except
 security issues, which i sync as soon as they are fixed)

 i have no automated way to detect any tree breakage, but when i sync the
 complete tree i do extensive manual testing on a handfull of machines
 (either staging machines, or ones that are not really important)

 but the main reason i even have a clone is to sync updates in batches.
 it's really a hassle to keep servers in sync when changes to gentoo-x86
 happen any other minute. i also need to adapt my chef cookbooks for some
 updates, so i do it all in one batch (sync, test, adapt, test, deploy)


i forgot to add one main difference here: i only have ~1000 packages in my
repo, which makes it a lot faster for metadata, rsync, eix and all that ...
the repo is only used for server deployments. no desktop, no games, only
very few X11 ebuilds for headless testing etc.


Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

2013-01-17 Thread Benedikt Böhm
On Fri, Jan 18, 2013 at 8:27 AM, Michael Weber x...@gentoo.org wrote:

 Hi,

 I'd like to drop one strong suggestion about configuration management
 that might be beneficial here: use version control software!

 Some machines (esp. those with shared administration) have /etc/portage
 under git [1] with


or even /etc/.git ... it saved my life on numerous occasions

The update is almost unattended with [2].


for reference, here is my updateworld script, which also handles python,
ruby, perl, revdep-rebuild and all that crap:
https://github.com/zenops/cookbooks/blob/master/cookbooks/portage/files/default/scripts/updateworld

- Bene


[gentoo-dev] Packages up for grabs

2012-12-10 Thread Benedikt Böhm
Due to limited time and resources these packages are up for grabs:

- app-shells/shish
- dev-db/mysqltuner
- dev-libs/dietlibc
- dev-libs/gecode
- net-analyzer/bwm-ng
- net-analyzer/nagios-check_mysql_health

These packages have been reduced to herd maintainers:

- media-libs/libraw
- media-libs/gexiv2


[gentoo-dev] net-misc/rabbitmq-server up for grabs

2012-07-18 Thread Benedikt Böhm
All,

i'm not using rabbitmq-server except as a dependency for
app-admin/chef and i've no interest or time to fix it. Feel free to
take it.

Regards,
Bene



Re: [gentoo-dev] The Python problem

2011-06-27 Thread Benedikt Böhm
On Mon, Jun 27, 2011 at 2:28 PM, Dirkjan Ochtman d...@gentoo.org wrote:
 So I know a bunch of people have already looked at it, and I'd like to
 know: what do you find better about the Ruby approach compared to the
 Python approach? Is it just the size of python.eclass, or are there a
 number of other issues?

the way python applications are built currently renders all binary
packages useless, since portage does not know which version of python
it was built against. the explicit selection with RUBY_TARGETS or
PHP_TARGETS solves this problem at the small cost of commiting new
values to these variables from time to time.



Re: [gentoo-dev] Thoughts about broken package handling

2011-06-25 Thread Benedikt Böhm
On Sun, Jun 26, 2011 at 4:59 AM, Stuart Longland redhat...@gentoo.org wrote:
 - revdep-rebuild (handles packages broken by soname changes, etc)

solved by preserved-libs in portage-2.2

 - python-updater (handles Python module rebuilds after upgrading Python)
 - perl-cleaner (handles Perl module rebuilds after upgrading Perl)

these just exist because python and perl ebuilds are horribly broken.
take a look at RUBY_TARGETS or PHP_TARGETS for an example of how to do
it right. this would also fix all the failures that python and perl
introduce to binary packages.

-Bene



[gentoo-dev] Resigning from apache herd

2011-02-18 Thread Benedikt Böhm
Hi!

due to work and family related time shortage i'm not able to lead the
apache team any longer and have removed myself from the herd. there
are a lot of open bugs, many of them results from the various
autotools/libtool hacks added by upstream. any help is appreciated i
guess and a new apache team lead should be found/elected by the
remaining two members nelchael and trapni if they desire to still work
on apache ebuilds.

Greetings,
Bene



Re: [gentoo-dev] openrc stabilization update

2010-09-20 Thread Benedikt Böhm
On Mon, Sep 20, 2010 at 10:29 AM, Tobias Klausmann klaus...@gentoo.org wrote:
 Hi!

 On Mon, 20 Sep 2010, Michał Górny wrote:
 William Hubbs willi...@gentoo.org wrote:
  What about newnet.  Should we keep it at all?  If we do, should we put
  it behind a use flag which would be off by default?

 I insist on keeping it as I use it myself. The new approach seems more
 desktop-targeted to me. The network script sets the domain name
 and bonding, dhcpcd script starts dhcpcd (which can control more than
 a single interface) and wpa_supplicant script is responsible for wifi.

 I'm with nightmorph: we should have exactly one way to configure
 networking (i.e. exactly one syntax).

 That said, switching to newnet would be a huge mess for everybody
 who runs servers: DHCP is uncommon there, WLAN is very unusual,
 as a result, they would not only have to switch the way they
 configure their nets (people don't like that kind of stuff if the
 machine is 400 miles away); they would also have to find a way to
 build their setups in the new language. Servers tend to have
 more complicated setups network-wise than workstations (think
 firewalls, VPN endpoint, traffic observation, ...).

the same is true for everyone who already runs newnet (like me). in
fact, i do not even use the newnet conf.d stuff, but rather take
advantage of support for /etc/ifup.eth* in /etc/init.d/network. that
way i can configure the networking with iproute2 or any other tool
that i already know the syntax of. no need to learn ridiculously
convoluted array syntax foo for /etc/init.d/net.eth*.

so please just keep the network init script as a use flag or extra
package or something, so that one is not forced to use the old net
stuff (again).

P.S.: newnet does not in any way force you to use DHCP or WLAN or
anything like that, so please stop spreading misinformation.

-Bene



Re: [gentoo-dev] [RFC][NEW] Utility to find orphaned files

2010-04-25 Thread Benedikt Böhm
On Sun, Apr 25, 2010 at 1:18 PM, Angelo Arrifano mik...@gentoo.org wrote:
 Hello developers developers and developers,

 Ever wondered how much crap is left in your X-years old Gentoo box?

 I just developed a python utility to efficiently find orphaned files in
 the system. By orphaned files I mean the files that are present on
 system directories and don't belong to any installed package.

 The package builds a virtual filesystem (cache) on the RAM using python
 hash tables. Then it uses the cache to find the ownership of files
 inside user-specified dirs.

 Building the cache takes less than 10 seconds here in a system with 1366
 installed packages.

 This is not intended to be a finished program yet, I'm looking forward
 for your constructive commentaries.

i have refactored findcruft (search the forums) two years ago (see
http://git.xnull.de/cgit/findcruft2/), maybe you can take a look at
it, especially the false-positives handling.

HTH,
Bene



Re: [gentoo-dev] webapp-config needs a new maintainer

2010-03-10 Thread Benedikt Böhm
On Wed, Mar 10, 2010 at 4:09 PM, Maciej Mrozowski reave...@gmail.com wrote:
 On Wednesday 10 of March 2010 07:52:28 Benedikt Böhm wrote:
 On Wed, Mar 10, 2010 at 4:30 AM, Sebastian Pipping sp...@gentoo.org wrote:
  There are quite a few bugs open for it plus the latest version (1.50.18)
  is not even in Gentoo but on SourceForge only.

 The release on sourceforge is not compatible with the current
 implementation in Gentoo AFAIK.

 webapp-config is in a horrible shape and also has several design
 flaws. i wouldn't touch it. that's why i already added an idea to the
 GSoC list for a complete w-c rewrite. i talked to gunnar in 2008 or
 2009 at chemnitz linux days, and we agreed that w-c needs a rewrite.
 but none of us had/has time to do it. hopefully gsoc can change this
 situation.

 This issue always bothered me. Why do we need exclusive web-app config
 application that effectively mirrors what emerge is supposed to do?

as you obviously figured the replicated package manager behaviour is
for installing apps into multiple vhosts. at first i thought this was
a nice idea, but after some time managing webapps with w-c, i really
hate it and install most things manually nowadays ;-)

 Don't bash me, maybe I'm obviously missing something but I'd really prefer
 simpler, Debian-like approach to webapps, so:
 - web-apps installed in /usr/share instead of /var/www (is there any benefit
 from polluting /var/www with system-managed applications?)
 - webapp-specific apache config installed in let's say /etc/apache2/conf.d/
 and included from httpd.conf so that any application works out of the box
 (Alias directive may be suitable in example below)

i am in favour of debian-like approach too, but i think there are
people relying on the w-c approach now, so an optimal solution would
be to just make webapp-config optional, but this may be an impossible
task, i don't really know.

Bene



Re: [gentoo-dev] webapp-config needs a new maintainer

2010-03-09 Thread Benedikt Böhm
Hi!

On Wed, Mar 10, 2010 at 4:30 AM, Sebastian Pipping sp...@gentoo.org wrote:
 There are quite a few bugs open for it plus the latest version (1.50.18)
 is not even in Gentoo but on SourceForge only.

The release on sourceforge is not compatible with the current
implementation in Gentoo AFAIK.

 So your first task would be a proper bump and a maybe few bug fixes after:

webapp-config is in a horrible shape and also has several design
flaws. i wouldn't touch it. that's why i already added an idea to the
GSoC list for a complete w-c rewrite. i talked to gunnar in 2008 or
2009 at chemnitz linux days, and we agreed that w-c needs a rewrite.
but none of us had/has time to do it. hopefully gsoc can change this
situation.

Greetings,
Bene



Re: [gentoo-dev] The feature patch mess in the webalizer ebuild (and how to deal with it)

2010-03-09 Thread Benedikt Böhm
On Wed, Mar 10, 2010 at 3:43 AM, Sebastian Pipping sp...@gentoo.org wrote:
 Solution
 
 1) Add two new packages to the tree:
   - app-admin/geolizer (/usr/bin/geolizer)
   - app-admin/webalizer-xtended (/usr/bin/webalizer-xtended)

 2) Bump webalizer to 2.21 while
  - no longer applying either feature patch
  - removing use flag xtended
  - keeping now hollow use flag geoip to reduce breakage

 3) Close related bug 231859
   https://bugs.gentoo.org/show_bug.cgi?id=231859

+1. please do it. and please help out the web-apps herd in the future
if you have the time. the herd really needs some love ;-)



Re: [gentoo-dev] Add NGINX_MODULES to USE_EXPAND

2010-03-05 Thread Benedikt Böhm
Hi Tiziano,

i already implemented it in my overlay too, but it seems you have done
more DEPEND research ;-)

at first i had NGINX_MODULES with stuff like http_rewrite and
mail_pop3 in my ebuild. then i found an ebuild on bugzilla which just
used rewrite and pop3 not caring about the http or mail prefix. i
don't have a preference, so your approach is totally fine too.

are you interested in taking care of nginx too? i just took over
maintainance from djc ...

Greetings,
Bene


On Thu, Mar 4, 2010 at 10:27 PM, Tiziano Müller dev-z...@gentoo.org wrote:
 Hi Benedikt

 Did you look at the nginx ebuild in my overlay? I already created an
 ebuild with USE flags for the different features and with USE_EXPANDable
 flags in mind.
 Even though there are only 3 mail modules I'd prefer two USE_EXPAND
 vars: NGINX_HTTP_MODULES and NGINX_MAIL_MODULES, since upstream makes a
 difference between http-modules and mail-modules.

 Cheers,
 Tiziano

 Am Donnerstag, den 04.03.2010, 21:27 +0100 schrieb Benedikt Böhm:
 Hi all,

 i'd like to add NGINX_MODULES to USE_EXPAND. If there are no
 objections i will commit it end of the week.

 Thanks,
 Bene


 --
 Tiziano Müller
 Gentoo Linux Developer
 Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
 E-Mail   : dev-z...@gentoo.org
 GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30




[gentoo-dev] Add NGINX_MODULES to USE_EXPAND

2010-03-04 Thread Benedikt Böhm
Hi all,

i'd like to add NGINX_MODULES to USE_EXPAND. If there are no
objections i will commit it end of the week.

Thanks,
Bene



Re: [gentoo-dev] Re: [rfc] layman storage location (again)

2010-01-17 Thread Benedikt Böhm
On Sun, Jan 17, 2010 at 12:55 AM, Sebastian Pipping sp...@gentoo.org wrote:
 On 01/16/10 23:46, Benedikt Böhm wrote:
 One thing all you /usr naggers forget is, that /var cannot be shared
 read-only via nfs (or bind mounts in case of virtual servers).

 Why is that?  Please tell more.

Maybe you should actually read the FHS. You can of course share
specific subdirectories of /var read-only and still be compliant, but
/usr is specifically designed to be completely shareable read-only.



Re: [gentoo-dev] Re: [rfc] layman storage location (again)

2010-01-16 Thread Benedikt Böhm
On Sat, Jan 16, 2010 at 8:38 PM, Michael Higgins li...@evolone.org wrote:
 Yes, PORTDIR default location under /usr was a totally stupid thing.
 Please don't repeat it...

One thing all you /usr naggers forget is, that /var cannot be shared
read-only via nfs (or bind mounts in case of virtual servers). most
single-machine users probably don't care, but there is more out there
than just your workstations. so putting portage into /usr is perfectly
valid. The only thing that violates the FHS is that Large software
packages must not use a direct subdirectory under the /usr hierarchy.
A location beneath /usr/share probably would have been more compliant.

Anyway, since i'll keep my overlays in /usr/local regardless of the
outcome this thread has, i don't care :)

Bene



[gentoo-dev] last rites: www-apache/mod_auth_pam

2009-07-05 Thread Benedikt Böhm
# Benedikt Böhm hol...@gentoo.org (5 Jul 2009)
# superseded by www-apache/mod_authn_pam, #222159
# removal: 31 Aug 2009
www-apache/mod_auth_pam


pgpKmSVGoic58.pgp
Description: PGP signature


[gentoo-dev] Apache herds needs your help

2009-06-08 Thread Benedikt Böhm
Hi all,

currently I am the only active developer in the apache herd, but
quite busy with work and life, so I'd like to ask all of you to fix bugs
assigned to apache-bugs@ if you come across them/if they annoy you etc,
since i cannot keep up with bugs currently. I'd also like to see more
active members in the herd as well in the future, so that bugs can be
resolved in a reasonable time again. If you're interested, feel free to
add yourself to herds.xml and join #gentoo-apache.

Thanks,
Bene


pgpQdQmH0YBmh.pgp
Description: PGP signature


Re: [gentoo-dev] Arches: please nominate files in experimental/ to move to purgatory

2009-04-17 Thread Benedikt Böhm
On Thu, Apr 16, 2009 at 06:27:40PM -0700, Robin H. Johnson wrote:
 Hi Arches,
 
 I started to move some files matching *2005* in experimental/ where they
 were obviously obsoleted by something else, however I'd like I hand in
 files that are no longer needed on the mirrors.
 
 Please reply to this post with a list of the filenames under
 experimental/

the vserver directories in amd64 and x86 can be removed.

Bene


pgpZ6g3vUpP3m.pgp
Description: PGP signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: package.mask

2009-01-11 Thread Benedikt Böhm
On Sun, Jan 11, 2009 at 01:56:52AM +0100, Friedrich Oslage wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Benedikt Boehm (hollow) schrieb:
  hollow  09/01/10 21:41:41
  
Modified: package.mask
Log:
mask sys-apps/baselayout-vserver for removal
  
  Revision  ChangesPath
  1.9378   profiles/package.mask
  
  file : 
  http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/package.mask?rev=1.9378view=markup
  plain: 
  http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/package.mask?rev=1.9378content-type=text/plain
  diff : 
  http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/package.mask?r1=1.9377r2=1.9378
  
  Index: package.mask
  ===
  RCS file: /var/cvsroot/gentoo-x86/profiles/package.mask,v
  retrieving revision 1.9377
  retrieving revision 1.9378
  diff -u -r1.9377 -r1.9378
  --- package.mask10 Jan 2009 17:17:32 -  1.9377
  +++ package.mask10 Jan 2009 21:41:41 -  1.9378
  @@ -1,5 +1,5 @@
   
  -# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.9377 
  2009/01/10 17:17:32 ulm Exp $
  +# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.9378 
  2009/01/10 21:41:41 hollow Exp $
   #
   # When you add an entry to the top of this file, add your name, the date, 
  and
   # an explanation of why something is getting masked. Please be extremely
  @@ -31,6 +31,11 @@
   
   #--- END OF EXAMPLES ---
   
  +# Benedikt Böhm hol...@gentoo.org (10 Jan 2009)
  +# baselayout-vserver is unmaintained and obsoleted by
  +# baselayout-2/openrc. please upgrade. removal in 30 days.
  +sys-apps/baselayout-vserver
  +
   # Rémi Cardona r...@gentoo.org (09 Jan 2009)
   # old virtual left from the transition from monolithic
   # to modular X. Use x11-libs/libXft directly
  
  
  
  
 
 This is bad, because:
 
 - - you forgot the ChangeLog entry

`cvs log` is the changelog, i don't see why i should add a changelog entry.

 - - you forgot the last rites mail

indeed

 - - baselayout-2/openrc isn't stable yet, in fact it's even masked in
 profiles/targets/vserver/package.mask

i don't care. baselayout-vserver is a hack, the vserver profiles are
deprecated since ages (although i think the restructuring revived them),
and the vserver team (that's only me currently) doesn't support anything
else beside openrc.

Greets,
Bene


pgpTyRoGxJdYC.pgp
Description: PGP signature


[gentoo-dev] Last rites: www-apps/gallery-1*

2008-02-03 Thread Benedikt Böhm
+# Benedikt Böhm [EMAIL PROTECTED] (03 Feb 2008)
+# Masked for removal in 30 days wrt #208584
+# Does not use webapp/depend.apache eclass correctly
+# Obsoleted by =www-apps/gallery-2*
+=www-apps/gallery-1*


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Last rites: www-servers/apache-2.0 friends

2008-01-12 Thread Benedikt Böhm
+# Benedikt Böhm [EMAIL PROTECTED] (12 Jan 2008)
+# Masked for apache-2.0 removal, bug #203578
+dev-cpp/cppserv
+=dev-libs/apr-0*
+=dev-libs/apr-util-0*
+=dev-util/subversion-1.3*
+=www-servers/apache-2.0*


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] apache-2.0* and apr{,-util}-0* removal

2007-12-28 Thread Benedikt Böhm
As previously announced apache-2.0 support ends as of 31-12-2007 and will be 
masked (together with apr{,-util}-0*) end of january.

A tracker bug exists at https://bugs.gentoo.org/203578

Greets,
Bene


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Add USE_EXPAND for apache

2007-11-29 Thread Benedikt Böhm
On Thursday 29 November 2007 09:46:01 Josh Saddler wrote:
 Josh Saddler wrote:
  Benedikt Böhm wrote:
 
  If this goes through, please look over our existing apache-related
  documentation and file a bug with any necessary changes.

 I updated our documentation, thanks to the massive patch sent my way by
 hollow. (Thanks, Benedikt!)

 As mentioned in an email to hollow though, I notice that speling is
 listed in the variables, but it is itself misspelled -- it should be
 spelling. ;)

Well, the name is mod_speling unfortunately :)


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Add USE_EXPAND for apache

2007-11-24 Thread Benedikt Böhm
Hi all,

the current behaviour of the apache ebuild -- chosing built-in modules based 
on /etc/apache2/apache-builtin-mods -- is very aweful, especially for binary 
packages.

Therefore, i would like to add APACHE2_MODULES and APACHE2_MPMS to USE_EXPAND. 
I have already converted the ebuild in my local overlay and it works fine.

Currently, there are over 60 modules available in apache. Out of these, a good 
default would look like this IMO:

APACHE2_MODULES=actions alias auth_basic auth_digest authn_alias authn_anon 
authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile 
authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate 
dir disk_cache env expires ext_filter file_cache filter headers include info 
log_config logio mem_cache mime mime_magic negotiation rewrite setenvif 
speling status unique_id userdir usertrack version vhost_alias

If noone objects, I will make these changes to base/make.defaults and commit 
the new ebuild during the next week.

Regards,
Benedikt


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Add USE_EXPAND for apache

2007-11-24 Thread Benedikt Böhm
On Saturday 24 November 2007 20:42:01 Arfrever Frehtes Taifersar Arahesis 
wrote:
 2007-11-24 19:51:23 Benedikt Böhm napisał(a):
  the current behaviour of the apache ebuild -- chosing built-in modules
  based on /etc/apache2/apache-builtin-mods -- is very aweful, especially
  for binary packages.
 
  Therefore, i would like to add APACHE2_MODULES and APACHE2_MPMS to
  USE_EXPAND.

 What with static modules? Will they be available?

yes, you can still USE=static globally, but it is not possible to decide per 
module anymore ...


  Currently, there are over 60 modules available in apache. Out of these, a
  good default would look like this IMO:
 
  APACHE2_MODULES=actions alias auth_basic auth_digest authn_alias
  authn_anon authn_dbm authn_default authn_file authz_dbm authz_default
  authz_groupfile authz_host authz_owner authz_user autoindex cache dav
  dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache
  filter headers include info log_config logio mem_cache mime mime_magic
  negotiation rewrite setenvif speling status unique_id userdir usertrack
  version vhost_alias

 You could also add access_compat, authn_core and authz_core.

these do not exist in apache 2.2


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Virtualization Herd

2006-07-05 Thread Benedikt Böhm
On Wednesday 05 July 2006 14:48, Chris Gianelloni wrote:
 On Mon, 2006-07-03 at 21:09 -0400, Daniel Gryniewicz wrote:
  I'm open to arguments in favor of such a project, tho, if people have
  real plans.  Certainly, an easier way to generate and maintain root
  filesystems for UML would be nice.

 As far as VMware is concerned, I see no point in this herd.  All of the
 VMware stuff is already managed by the VMware team, and is a part of the
 vmware herd.  Adding it to a broader herd won't improve VMware in any
 way.  The only thing it will do is ensure that the members of the VMware
 team get emails about bugs in things they aren't interested in working
 with, or have no knowledge of whatsoever.

i agree, same applies for the vserver herd (currently maintaining openvz and 
linux-vserver)


 If such a herd does form, leave VMware out of it, please.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Virtualization Herd

2006-07-03 Thread Benedikt Böhm
On Monday 03 July 2006 19:49, Nick Devito wrote:
 Looking at the number of virtualization-related packages (xen, openvz,
 and related packages) that are in portage, and the increasing complexity
 of these packages (which means more problems, as usual), I'm suggesting
 that a Virtualization herd be formed to handle these packages. I was
 also going to suggest moving virtualization-related things out of
 app-emulation, since they don't quite fit the bill of emulation. Maybe
 QEMU, Bochs, and VMWare would fit, but, not quite. These are the
 packages that would be affected:

 * Xen/Xen-tools
 * QEMU
 * OpenVZ
 * Bochs
 * VMWare (workstation, server, etc)
 * User-mode Linux

 ..and the list goes on...

the packages related to OS-level virtualization (OpenVZ, Linux-VServer) are 
already in the vserver herd


 Just a suggestion :)

 ~ Nick
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Virtualization Herd

2006-07-03 Thread Benedikt Böhm
On Monday 03 July 2006 21:56, Nick Devito wrote:
 Okay, in that case, extend the vserver herd to include a larger range of
 virtualization stuff, including Xen, Bochs, and so on. It just seems
 more fitting to group those packages together.

not really, bochs, qemu and vmware is emulation, merely used in virtualization 
environments

uml and xen do run with VMMs and don't share anything with 
OpenVZ/Linux-VServer

uml and xen could be integrated into the VPS project (with a different herd) 
but i don't know what their maintainers are thinking about this


 On Mon, 2006-07-03 at 21:48 +0200, Benedikt Böhm wrote:
  On Monday 03 July 2006 19:49, Nick Devito wrote:
   Looking at the number of virtualization-related packages (xen, openvz,
   and related packages) that are in portage, and the increasing
   complexity of these packages (which means more problems, as usual), I'm
   suggesting that a Virtualization herd be formed to handle these
   packages. I was also going to suggest moving virtualization-related
   things out of app-emulation, since they don't quite fit the bill of
   emulation. Maybe QEMU, Bochs, and VMWare would fit, but, not quite.
   These are the packages that would be affected:
  
   * Xen/Xen-tools
   * QEMU
   * OpenVZ
   * Bochs
   * VMWare (workstation, server, etc)
   * User-mode Linux
  
   ..and the list goes on...
 
  the packages related to OS-level virtualization (OpenVZ, Linux-VServer)
  are already in the vserver herd
 
   Just a suggestion :)
  
   ~ Nick

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Virtualization Herd

2006-07-03 Thread Benedikt Böhm
On Monday 03 July 2006 22:28, Benedikt Böhm wrote:
 On Monday 03 July 2006 21:56, Nick Devito wrote:
  Okay, in that case, extend the vserver herd to include a larger range of
  virtualization stuff, including Xen, Bochs, and so on. It just seems
  more fitting to group those packages together.

 not really, bochs, qemu and vmware is emulation, merely used in
 virtualization environments

s/merely/barely/


 uml and xen do run with VMMs and don't share anything with
 OpenVZ/Linux-VServer

 uml and xen could be integrated into the VPS project (with a different
 herd) but i don't know what their maintainers are thinking about this

  On Mon, 2006-07-03 at 21:48 +0200, Benedikt Böhm wrote:
   On Monday 03 July 2006 19:49, Nick Devito wrote:
Looking at the number of virtualization-related packages (xen,
openvz, and related packages) that are in portage, and the increasing
complexity of these packages (which means more problems, as usual),
I'm suggesting that a Virtualization herd be formed to handle these
packages. I was also going to suggest moving virtualization-related
things out of app-emulation, since they don't quite fit the bill of
emulation. Maybe QEMU, Bochs, and VMWare would fit, but, not quite.
These are the packages that would be affected:
   
* Xen/Xen-tools
* QEMU
* OpenVZ
* Bochs
* VMWare (workstation, server, etc)
* User-mode Linux
   
..and the list goes on...
  
   the packages related to OS-level virtualization (OpenVZ, Linux-VServer)
   are already in the vserver herd
  
Just a suggestion :)
   
~ Nick

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Last rites for sys-apps/lmctl

2006-04-20 Thread Benedikt Böhm
Hey all,

lmctl's upstream is dead, and its fork is now called lomoco (supporting
new mice etc)

I have masked lmctl and if noone objects it will go away in the next two
weeks or so..

Cheers!
-- 
gentoo-dev@gentoo.org mailing list