Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake

2019-12-19 Thread Sebastian Pipping
On 19.12.19 18:37, Michał Górny wrote:
> We have a better alternative that lets us limit the impact on the users.
> Why not use it?

Which one?  The CMake bootstrap copy?  The adding to stage3 one?




Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake

2019-12-19 Thread Sebastian Pipping
Hey!


On 19.12.19 17:03, Michał Górny wrote:
>> B) Introduce USE flag "system-expat" to CMake similar to existing
>>flag "system-jsoncpp", have it off by default, keep reminding
>>CMake upstream to update their bundle
>>
>> [..]
> 
> It violates the policy on bundled libraries.

Same for the dev-util/cmake-bootstrap approach, right?


>  What's worse, the awful
> USE flags solution means that most of the Gentoo devs end up using
> bundled libraries just because people are manually required to figure
> out what to do in order to disable them.

I didn't say that it's perfect :)  It's the same approach that we have
have with the system-jsoncpp USE flag already so that was considered
good enough at some point in the past.  I guess we want the same for
Expat and jsoncpp?  Which alternative do you see as better than a new
flag system-expat?

Best



Sebastian



Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake

2019-12-19 Thread Sebastian Pipping
Hey!


Thanks everyone for your thoughts so far!

>From what I heard, these two options seem realistic to me:

A) Ask the KDE team for help with teaming up on a new package
   dev-util/cmake-bootstrap, keep it in sync with dev-util/cmake,
   make sure both packages co-exists with full disjoint operation,
   i.e. zero file conflicts + zero cross package file usage (tricky?).

B) Introduce USE flag "system-expat" to CMake similar to existing
   flag "system-jsoncpp", have it off by default, keep reminding
   CMake upstream to update their bundle

I favor (B) by more than just a bit.  Does anyone have strong concerns
against moving in the dev-util/cmake[-system-expat] (B) direction?  Is
it acceptable if I make those changes to the CMake ebuild myself?

Thanks again



Sebastian



Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake

2019-12-19 Thread Sebastian Pipping
On 19.12.19 14:32, Rolf Eike Beer wrote:
> These things _are_ updated regularly

To be fair they update because I keep opening update requests:

https://gitlab.kitware.com/cmake/cmake/issues?scope=all=%E2%9C%93=closed=expat+update



[gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake

2019-12-18 Thread Sebastian Pipping
Hi all,


I noticed that dev-util/cmake depends on dev-libs/expat and that
libexpat upstream (where I'm involved) is in the process of
dropping GNU Autotools altogether in favor of CMake in the near future,
potentially the next release (without any known target release date).

CMake bundles a (previously outdated and vulnerable) copy of expat so
I'm not sure if re-activating that bundle — say with a new use flag
"system-expat" — would be a good thing to resort to for breaking the
cycle, with regard to security in particular.

Do you have any ideas how to avoid a bad circular dependency issue for
our users in the future?  Are you aware of similar problems and
solutions from the past?

Thanks and best



Sebastian




[gentoo-dev] Packages up for grabs: Gimp and related (gegl, babl, mypaint)

2019-10-28 Thread Sebastian Pipping
Hello,


I need to admit that I don't have enough time to keep up with
maintaining the Gimp-related packages well enough in Gentoo.

Latest ebuild of Babl and Gegl ebuilds are using Meson by now, Gimp is
up next and 2.10.14 is just out the door.

These packages are up for grabs now:

  media-gfx/gimp

  media-libs/babl
  media-libs/gegl

  media-gfx/mypaint  (not mine but maintainer-needed and related)
  media-gfx/mypaint-brushes
  media-libs/libmypaint

Best



Sebastian



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

2019-05-22 Thread Sebastian Pipping
# Sebastian Pipping  (22 May 2019)
# Masked for removal in 30 days (bug #686562)
# Unfixed bug, dead upstream, not relevant enough
sys-fs/pytagsfs



Re: [gentoo-dev] Merge 7 Fedora wallpapers packages to single one with slots?

2018-02-01 Thread Sebastian Pipping
Hi Alec,


On 27.01.2018 22:58, Alec Warner wrote:
> > I noticed that we have 7 packages on Fedora wallpapers with names that
> > only explain themselves to Fedora insiders:
> 
> So traditionally we follow upstream package naming. If we aim to
> deviate, I'd prefer we have strong reasons for it.

good point.


> > I was thinking that we could merge these packages into a new package
> > "x11-themes/fedora-backgrounds" or so with slots 11 to 16 so that people
> > can still install them in parallel, get slot updates automatically,
> > adding more recent ones does not add more packages, and the package name
> > explains itself.
> 
> Why not just make x11-themes/fedora-backgrounds, a metapackage that
> includes all of the packages?

With one file and use flags for each version or with one ebuild file per
slot?  Fedora 21 was the last release with a release name so if we
package 22+ later, their ebuilds would be non-meta in nature.  I'm not
sure how to blend that into the use-flag version (yet for a meta package
all these files seem overkill too).  Do you have some third option in mind?

Best



Sebastian



Re: [gentoo-dev] Merge 7 Fedora wallpapers packages to single one with slots?

2018-01-27 Thread Sebastian Pipping
On 27.01.2018 19:06, Sebastian Pipping wrote:
>   11-solar
>   12-constantine
>   13-goddard
>   14-laughlin
>   15-lovelock
>   16-verne

Correction:

  10-solar
  11-leonidas
  12-constantine
  13-goddard
  14-laughlin
  15-lovelock
  16-verne



Re: [gentoo-dev] Merge 7 Fedora wallpapers packages to single one with slots?

2018-01-27 Thread Sebastian Pipping
Hi,


On 27.01.2018 17:32, Michael Orlitzky wrote:
> If you do merge them, then it might be better to use flags for the
> different sub-packages rather than slots. There's no place to describe
> what a slot is for, but having a local USE=solar with a corresponding
> description in metadata.xml is (relatively) discoverable.

use flags work well if we make a single ebuild offering to install one
to all of these.  That would be natural if the goddard/13 source rpm
included files of constantine/12 and solar/11 as well and so on but it
doesn't seem to.  I would rather go with one ebuild per mayor release
number of Fedora: Needs less use flag configuration as well.

About slot names, if "12" is not good enough we could use

  11-solar
  12-constantine
  13-goddard
  14-laughlin
  15-lovelock
  16-verne

or so for SLOT to have a mapping to names?

Best



Sebastian



Re: [gentoo-dev] time to retire

2018-01-27 Thread Sebastian Pipping
Stefan,


thanks for your work on Gentoo!

All the best



Sebastian




[gentoo-dev] Merge 7 Fedora wallpapers packages to single one with slots?

2018-01-27 Thread Sebastian Pipping
Hi!


I noticed that we have 7 packages on Fedora wallpapers with names that
only explain themselves to Fedora insiders:


# eix background | fgrep -B3 Fedora
* x11-themes/constantine-backgrounds
 Available versions:  12.1.1.4-r1
 Homepage:https://fedoraproject.org/wiki/F12_Artwork
 Description: Fedora official background artwork
--
* x11-themes/goddard-backgrounds
 Available versions:  13.0.0.3-r1
 Homepage:https://fedoraproject.org/wiki/F13_Artwork
 Description: Fedora official background artwork
--
* x11-themes/laughlin-backgrounds
 Available versions:  14.1.0.3-r1
 Homepage:https://fedoraproject.org/wiki/F14_Artwork
 Description: Fedora official background artwork
--
* x11-themes/leonidas-backgrounds
 Available versions:  11.0.0.2-r1
 Homepage:https://fedoraproject.org/wiki/F11_Artwork
 Description: Fedora official background artwork
--
* x11-themes/lovelock-backgrounds
 Available versions:  14.91.1.1-r1
 Homepage:https://fedoraproject.org/wiki/F15_Artwork
 Description: Fedora official background artwork
--
* x11-themes/solar-backgrounds
 Available versions:  0.92.0.5-r1
 Homepage:https://fedoraproject.org/wiki/F11_Artwork
 Description: Fedora official background artwork
--
* x11-themes/verne-backgrounds
 Available versions:  (~)15.91.0.1-r1
 Homepage:https://fedoraproject.org/wiki/F16_Artwork
 Description: Fedora official background artwork


I was thinking that we could merge these packages into a new package
"x11-themes/fedora-backgrounds" or so with slots 11 to 16 so that people
can still install them in parallel, get slot updates automatically,
adding more recent ones does not add more packages, and the package name
explains itself.

Any objections?

Best



Sebastian



Re: [gentoo-dev] [RFC] Addition of a new field to metadata.xml

2017-08-30 Thread Sebastian Pipping
On 01.06.2017 23:18, Jonas Stein wrote:
> 2. Specification
> 
> A space separated list of the corresponding debian packages should be
> written in the field
>  
> 
> It should be NONE, if debian has no corresponding package.
> UNSET or no field, if the creator of the ebuild did not set the field (yet).

Please pick NONE or require absence eventually, but not multiple
options.  Else we're asking for inconsistent data from the beginning.


> example:
> app-arch/tar/metadata.xml
> tar
> 
> app-office/libreoffice-bin/metadata.xml
> libreoffice libreoffice-base libreoffice-base
> libreoffice-dev libreoffice-dmaths libreoffice-draw
> libreoffice-evolution libreoffice-impress

Since the difference between source and binary packages has already been
brought up, please adjust "" some way to
indicating if the text content is a source or a binary package (even if
we don't end up supporting both) to be 100% clear.  Otherwise people
will mix it up, and may not even notice.

Best



Sebastian



Re: [gentoo-dev] [rfc] dev-libs/expat[unicode] and dev-libs/libbsd dependency

2017-06-07 Thread Sebastian Pipping
Hi!


Just quick note for the record: 2.2.0-r2 has these changes now, no need
to have that wait for the next release:

https://github.com/gentoo/gentoo/commit/715a2315ee2b841e38843e61b43ee058b5678cab

Best



Sebastian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [rfc] dev-libs/expat[unicode] and dev-libs/libbsd dependency

2017-05-31 Thread Sebastian Pipping
Hi,


On 31.05.2017 21:16, Michał Górny wrote:
>> How do you evaluate these options:
>>
>>  a) Keep libexpatu.so + change libexpatw.so to CPPFLAGS=-DXML_UNICODE
>>
>>  b) Drop libexpatu.so + change libexpatw.so to CPPFLAGS=-DXML_UNICODE
> 
> Does any other distribution use libexpatu.so? If not, then there's
> probably no point in keeping it.

I found none but CoreOS, which is derived from Gentoo (..).


>>  A) libbsd should be a default-off use dependency
>>   IUSE="libbsd"  RDEPEND="libbsd? ( dev-libs/libbsd )"
>>
>>  B) libbsd could be a default-on use dependency
>>   IUSE="+libbsd"  RDEPEND="libbsd? ( dev-libs/libbsd )"
> 
> I'd dare say the feature is 'arc4random', then that should be the name
> of the flag.

Good point.

Best



Sebastian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [rfc] dev-libs/expat[unicode] and dev-libs/libbsd dependency

2017-05-31 Thread Sebastian Pipping
Hi!


The next release of dev-libs/expat is not far away and there are two
things that I would appreciate input with, before the next bump in Gentoo:


-DXML_UNICODE_WCHAR_T issues and Gentoo/Debian mismatch
===

With USE=unicode, on Gentoo two extra libraries are built:

 * libexpatu.so (with CPPFLAGS=-DXML_UNICODE)
 * libexpatw.so (with CPPFLAGS=-DXML_UNICODE_WCHAR_T)
   ^
However, -DXML_UNICODE_WCHAR_T has only ever worked with 2-byte wchar_t,
while 4-byte wchar_t seems mainstream on Linux (and GCC -fshort-wchar
would required libc to have the same, if you actually wanted to pass
those wchar_t strings to wprintf and friends).

So libexpatw.so in Gentoo is not functional at the moment.

To make things worse, Debian has libexpatw.so with
CPPFLAGS=-DXML_UNICODE, which corresponds to current libexpatu.so in
Gentoo, rather than libexpatw.so.


How do you evaluate these options:

 a) Keep libexpatu.so + change libexpatw.so to CPPFLAGS=-DXML_UNICODE

 b) Drop libexpatu.so + change libexpatw.so to CPPFLAGS=-DXML_UNICODE


Depend on dev-libs/libbsd
=

The next release is very likely to add (optional but helpful) support
for arc4random_buf that dev-libs/libbsd provides (especially on systems
with glibc prior to 2.25) [1].  I wonder if Expat's proximity to @system
has any strong implications on whether

 A) libbsd should be a default-off use dependency
  IUSE="libbsd"  RDEPEND="libbsd? ( dev-libs/libbsd )"

 B) libbsd could be a default-on use dependency
  IUSE="+libbsd"  RDEPEND="libbsd? ( dev-libs/libbsd )"

 C) libbsd could even go into DEPEND and RDEPEND directly, or
  RDEPEND="dev-libs/libbsd"

 D) libbsd should not become any kind of future dependency of
dev-libs/expat.


Thanks for your time!

Best



Sebastian


[1] https://github.com/libexpat/libexpat/pull/30



[gentoo-dev] Last rites: media-gfx/drqueue

2016-10-08 Thread Sebastian Pipping
# Sebastian Pipping <sp...@gentoo.org> (08 Oct 2016)
# Dead upstream for years, ebuild needs work, 5 open bugs
# Masked for removal in 30 days.
media-gfx/drqueue



Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

2016-01-06 Thread Sebastian Pipping
On 05.01.2016 20:35, Michael Orlitzky wrote:
> I just pushed a new revision with this fix. In eselect-php-0.8.2-r1,
> we ship both the new 70_mod_php.conf and the old 70_mod_php5.conf. The
> latter comes with a big warning at the top of it, stating that it is for
> backwards compatibility only.

Cool, sounds like a great idea to me.

I guess we don't need a news item any more then?



Sebastian




Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

2016-01-06 Thread Sebastian Pipping
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04.01.2016 11:45, Lars Wendler wrote:
> Hi Sebastian,
> 
> to be honest I was very upset when I first stumbled upon this
> problem. And yes I only found about it when my apache webserver
> started to deliver php source code instead of the real sites.

Exactly the same with me.


> Doing such a change without getting in contact with me as apache 
> maintainer before the change was done is very... eh... impolite at
> best.

Just for the record, it wasn't me :)

Best



Sebastian

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlaNbXwACgkQsAvGakAaFgDNmgCfXwHI2i15LT30MFw6eV7cDgyk
sZYAnRwFHtwDAG/Z/p5zS4UvFXyvemGX
=Xlrd
-END PGP SIGNATURE-



[gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

2016-01-03 Thread Sebastian Pipping
Hi!


Better late then never.  Posting 72 hours from now the earliest as
advised by GLEP 42.  Feedback welcome as usual.


===
Title: Apache "-D PHP5" needs update to "-D PHP"
Author: Sebastian Pipping <sp...@gentoo.org>
Content-Type: text/plain
Posted: 2016-01-04
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: app-eselect/eselect-php[apache2]

With >=app-eselect/eselect-php-0.8.1, to enable PHP support
for Apache 2.x file /etc/conf.d/apache2 no longer
needs to read

  APACHE2_OPTS=". -D PHP5"

but

  APACHE2_OPTS=". -D PHP"

, i.e. without "5" at the end.  This change is related to
unification in context of the advent of PHP 7.x.

With that change, guard "" in file
/etc/apache2/modules.d/70_mod_php.conf
has a chance to actually pull in PHP support.

Without updating APACHE2_OPTS, websites could end up serving
PHP code (include configuration files with passwords)
unprocessed to website visitors!


The origin of this news item is:
https://bugs.gentoo.org/show_bug.cgi?id=569042
===


Best



Sebastian



[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/gegl/

2015-12-09 Thread Sebastian Pipping
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09.12.2015 07:41, Michał Górny wrote:
> On Tue,  8 Dec 2015 21:54:44 + (UTC) "Sebastian Pipping"
> <sp...@gentoo.org> wrote:
> 
>> commit: a1ea06b430e14f68b5b7bf1947a681215157c034 Author:
>> Sebastian Pipping  gentoo  org> AuthorDate: Tue
>> Dec  8 21:49:31 2015 + Commit: Sebastian Pipping >  gentoo  org> CommitDate: Tue Dec  8 21:54:00 2015
>> + URL:
>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a1ea06b4
>> 
>> media-libs/gegl: Fix ffmpeg/libav dependency (bug #567638)
>> 
>> Package-Manager: portage-2.2.26
>> 
>> media-libs/gegl/gegl-0.3.4.ebuild | 10 ++ 1 file changed,
>> 6 insertions(+), 4 deletions(-)
>> 
>> diff --git a/media-libs/gegl/gegl-0.3.4.ebuild
>> b/media-libs/gegl/gegl-0.3.4.ebuild index 764b6c9..c2b9409
>> 100644 --- a/media-libs/gegl/gegl-0.3.4.ebuild +++
>> b/media-libs/gegl/gegl-0.3.4.ebuild @@ -18,7 +18,7 @@ if [[ ${PV}
>> == ** ]]; then SRC_URI="" else 
>> SRC_URI="http://download.gimp.org/pub/${PN}/${PV:0:3}/${P}.tar.bz2;
>>
>> 
- - KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~sparc ~x86
~amd64-fbsd ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos
~x86-macos ~x64-solaris ~x86-solaris"
>> +KEYWORDS="~alpha ~amd64 ~arm ~hppa ~mips ~ppc ~ppc64 ~x86
>> ~amd64-fbsd ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos
>> ~x64-macos ~x86-macos ~x64-solaris ~x86-solaris"
> 
> ...which change is put silently under 'dependency fix' with no
> explicit warning, and effectively breaks ~ia64 reverse
> dependencies:
> 
> https://qa-reports.gentoo.org/output/gentoo-ci/42f623e/output.html#med
ia-gfx/gimp

There
> 
is

https://bugs.gentoo.org/show_bug.cgi?id=567824

for that now.  If I don't hear from ia64 and/or sparc until tomorrow
night, I will drop those keywords from Gimp as well.  If it's more
urgent, I'm happy with anyone else doing that before me.  I hope
that's okay for everyone.  Else, please let me know.

Best,



Sebastian

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlZoxEkACgkQsAvGakAaFgBvmACfRDY19JxNYqClQaYfVREJevp/
GzAAoMHIWJGN39fyNgvL8+RCxvaKbl36
=1w1B
-END PGP SIGNATURE-



Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit

2015-08-19 Thread Sebastian Pipping
On 19.08.2015 18:33, hasufell wrote:
 I don't want to start a lot of bikeshed, but I think this information is
 practically useless.
 
 If there has been a problem with a commit, ask the developer about his
 repoman version (which I believe was the reason for this, unless you
 want me to add Package-Manager: paludis-2.4.0 to every commit ;).
 
 Let's just remove it.
 

With that line removed, how do we notice that people are committing
without repoman or not running repoman checks at least?

There is quite a risk of things going straight into stable by mistake
when repoman is not used.

Best,



Sebastian




Re: [gentoo-dev] [RFC] Rebooting the Installer Project

2015-07-20 Thread Sebastian Pipping
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 20.07.2015 10:51, Michał Górny wrote:
 [..] I think we'd really benefit from having some kind of helper
 scripts / checklist of tasks to be done prior to/after install.
 
 For example, you'd run 'check-my-install' script and it'd tell you
 what you likely forgot to set up :).

+1



Sebastian




[gentoo-dev] Problems updating Qt from 4.8.6 to 4.8.7

2015-07-05 Thread Sebastian Pipping
Hi there!


I'm having trouble updating Qt:4 (dev-qt/qt*-4.8*:4) from 4.8.6 to 4.8.7.
Looking at the ebuilds, they require some 4.8.7 versions to be installed
already that in turn cannot be installed because other ebuilds require
4.8.6 while not yet upgraded.

I am running the latest version of portage.  Is there some trick I
should know about or am I stuck with Qt 4.8.6 on that box forever?  How
did you update?

Thanks for your help, best,



S



Re: [gentoo-dev] Problems updating Qt from 4.8.6 to 4.8.7

2015-07-05 Thread Sebastian Pipping
On 05.07.2015 20:44, Alexandre Rostovtsev wrote:
 What I usually end up doing is listing my installed dev-qt/qt* ebuilds, and
 updating all of them together explicitly:
 
 emerge -1 qtcore:4 qtgui:4 qtsql:4 etc.

That's what I tried but it doesn't seem to work with this update.

Looking at the dependencies of qtgui

  dev-qt/qtgui-4.8.6-r4
DEPEND
  ~dev-qt/qtcore-4.8.6

  dev-qt/qtgui-4.8.7
DEPEND
  ~dev-qt/qtcore-4.8.7

I really wonder if there is any update path from having

  dev-qt/qtcore-4.8.6-r2
  dev-qt/qtgui-4.8.6-r4

installed before to

  dev-qt/qtcore-4.8.7
  dev-qt/qtgui-4.8.7

after.  Right now, it looks like I have to use emerge -C .. to
un-install them completely, temporary breaking Qt and installing 4.8.7
fresh.  I'm still hoping for some way to not needing to do that.


 Alternatively, just try emerge --update --deep world - it probably should
 work if you have a consistent, complete and updateable world set.

That's where I'm coming from.  It doesn't stop complaining because of Qt.

Best,



Sebastian




Re: [gentoo-dev] Re: Review: Apache AddHandler news item

2015-04-06 Thread Sebastian Pipping
Hello Duncan,


On 06.04.2015 06:53, Duncan wrote:
 Sebastian Pipping posted on Mon, 06 Apr 2015 01:29:19 +0200 as excerpted:
 
 Published a slightly improved version now:

 https://gitweb.gentoo.org/proj/gentoo-news.git/tree/2015/2015-04-06-
 apache-addhandler-addtype

 If there's anything wrong with it, please mail me directly (or put me in
 CC) so there is zero chance of slipping through.  Thanks!
 
 [also mailing sp...@gentoo.org as requested]

thanks!


 $ echo Apache AddHandler/AddType vulnerability protection | wc -c
 51
 
 GLEP 42 says max title length 44 chars.  51-44=7 chars too long.

Actually, echo prints a newline that is also counted.  So it's 50 and 6
characters too much but you still have a point :)


 Off the top of my head, maybe just s/vulnerability/vuln/ ?  That'd cut 9 
 chars for 42, leaving two to spare.  Anyone with a better idea?

I made it say exploit now:

  # echo -n 'Apache AddHandler/AddType exploit protection' | wc -c
  44

I hope that's correct enough in terms of security language.
The fix protections against exploits of the related vulnerability.


 That's the big one.  Here's a couple more minor English usage change 
 suggestions as well. (Changes denoted in caps here, obviously lowercase 
 them):
 
 Line 25, add also:
 
 may be helpful.  Unfortunately, it can ALSO be a security threat.

Fixed.


 Line 74 s/at/in/: 
 
 You may be using AddHandler or AddType IN other places,

Fixed.


https://gitweb.gentoo.org/proj/gentoo-news.git/commit/?id=a63ce98a6297bf371488c26c034dc22f6d8877b9


Thanks for the review.

Best,



Sebastian




Re: [gentoo-dev] Review: Apache AddHandler news item

2015-04-05 Thread Sebastian Pipping
Published a slightly improved version now:

https://gitweb.gentoo.org/proj/gentoo-news.git/tree/2015/2015-04-06-apache-addhandler-addtype

If there's anything wrong with it, please mail me directly (or put me in
CC) so there is zero chance of slipping through.  Thanks!

Best,



Sebastian




[gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

2015-03-29 Thread Sebastian Pipping
Hi!


For the current Gentoo Git setup I found these methods working for
accessing a repository, betagarden in this case:

  git://anongit.gentoo.org/proj/betagarden.git
 (git://git.gentoo.org/proj/betagarden.git)
 (git://git.overlays.gentoo.org/proj/betagarden.git)

  http://anongit.gentoo.org/git/proj/betagarden.git

 (http://cgit.gentooexperimental.org/proj/betagarden.git)

  git+ssh://g...@git.gentoo.org/proj/betagarden.git
 (git+ssh://g...@git.overlays.gentoo.org/proj/betagarden.git)

Those without braces are the ones announced at the repository's page [1].

My concerns about the current set of supported ways of transfer are:

 * There does not seem to be support for https://.  Please add it.

 * Why do we serve Git over git:// and http:// if those are vulnerable
   to man-in-the-middle attacks (before having waterproof GPG
   protection for whole repositories in place)?
   Especially with ebuilds run by root, we cannot afford MITM.


So I would like to propose that

 * support for Git access through https:// is activated,

 * Git access through http:// and git:// is deactivated, and

 * the URLs on gitweb.gentoo.org and the Layman registry are
   updated accordingly.  (Happy to help with the latter.)


Thanks for your consideration.

Best,



Sebastian


[1] https://gitweb.gentoo.org/proj/betagarden.git/



Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

2015-03-29 Thread Sebastian Pipping
On 29.03.2015 19:39, Andrew Savchenko wrote:
 On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote:
 So I would like to propose that
 
 * support for Git access through https:// is activated,
 
 * Git access through http:// and git:// is deactivated, and
 
 Some people have https blocked. http:// and git:// must be 
 available read-only.

They would not do online banking over http, right?  Why would they run
code with root privileges from http?

Best,



Sebastian




Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

2015-03-29 Thread Sebastian Pipping
On 29.03.2015 19:56, Diamond wrote:
 Doesn't git:// uses SSH wich is secure? I think that was on github.

git:// is the git protocol [1] with absolutely no authentication and
no encryption.

GitHub does not support git:// but only secure protocols (HTTPS, SSH),
see [2].

Best,



Sebastian


[1]
http://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#The-Git-Protocol
[2] https://help.github.com/articles/which-remote-url-should-i-use/




Re: [gentoo-dev] Review: Apache AddHandler news item

2015-03-29 Thread Sebastian Pipping
Next round:

 * Recipe for handling \.(php|php5|phtml|phps)\. manually added

 * AddType (with similar problems) mentioned, too

 * Typo momment fixed

(* Internel revision bump to 3, will be committed as revision 1)

(* Date bumped to today)

(* Links renumbered due to new link [2])



Title: Apache AddHandler/AddType vulnerability protection
Author: Sebastian Pipping sp...@gentoo.org
Content-Type: text/plain
Posted: 2015-03-30
Revision: 3
News-Item-Format: 1.0
Display-If-Installed: www-servers/apache

Apache's directives AddHandler [1] (and AddType [2]) can be used
to map certain file name extensions (e.g. .php) to a handler
(e.g. application/x-httpd-php).  While a line like

  AddHandler application/x-httpd-php .php .php5 .phtml

matches index.php, it also matches index.php.png.

Apache's notes on multiple file extensions [3] document
a multi-language website as a context where that behavior
may be helpful.  Unfortunately, it can be a security threat.

Combined with (not just PHP) applications that support
file upload, the AddHandler/AddType directive can get you into
remote code execution situations.

That is why app-admin/eselect-php now avoids AddHandler
and is shipping

  FilesMatch \.(php|php5|phtml)$
SetHandler application/x-httpd-php
  /FilesMatch

instead.


Why this news entry?

 * Since Apache configuration lives below /etc,
   you need to run etc-update (or a substitute)
   to actually have related fixes applied.

 * If you are currently relying on AddHandler to execute
   secret_database_stuff.php.inc, moving away from AddHandler
   could result in serving your database credentials in plain
   text.  A command like

 find /var/www/ -name '*.php.*' \
 -o -name '*.php5.*' \
 -o -name '*.phtml.*'

   may help discovering PHP files that would no longer be executed.

   Shipping automatic protection for this scenario is not trivial,
   but you could manually install protection based on this recipe:

 FilesMatch \.(php|php5|phtml|phps)\.
   # a) Apache 2.2 / Apache 2.4 + mod_access_compat
   #Order Deny,Allow
   #Deny from all

   # b) Apache 2.4 + mod_authz_core
   #Require all denied

   # c) Apache 2.x + mod_rewrite
   #RewriteEngine on
   #RewriteRule .* - [R=404,L]
 /FilesMatch

 * You may be using AddHandler (or AddType) at other places,
   including off-package files.  Please have a look.

 * app-admin/eselect-php is not the only package
   affected.  There is a dedicated tracker bug at [4].
   As of the moment, affected packages include:

 app-admin/eselect-php[apache2]
 dev-lang/php[apache2]
 net-nds/gosa-core
 www-apache/mod_fastcgi
 www-apache/mod_flvx
 www-apache/mod_python
 www-apache/mod_suphp
 www-apps/moinmoin
 www-apps/rt[-lighttpd]


Thanks to Nico Suhl, Michael Orlitzky and Marc Schiffbauer.

[1] https://httpd.apache.org/docs/current/mod/mod_mime.html#addhandler
[2] https://httpd.apache.org/docs/current/mod/mod_mime.html#addtype
[3] https://httpd.apache.org/docs/current/mod/mod_mime.html#multipleext
[4] https://bugs.gentoo.org/show_bug.cgi?id=544560




Re: [gentoo-dev] Should Gentoo do https by default?

2015-03-28 Thread Sebastian Pipping
On 27.03.2015 15:33, Hanno Böck wrote:
 I think defaulting the net to HTTPS is a big step for more security and
 I think Gentoo should join the trend here.

Yes please!



Sebastian




Re: [gentoo-dev] Re: Review: Apache AddHandler news item

2015-03-28 Thread Sebastian Pipping
Hi!


I was wondering about the same thing, too.
I can commit it as revision 1 for a workaround.

If you have some time, please take this question/issue further with the
related software and people.

Thanks in advance,



Sebastian




[gentoo-dev] Review: Apache AddHandler news item

2015-03-26 Thread Sebastian Pipping
Hi!


In context of

  https://bugs.gentoo.org/show_bug.cgi?id=538822

mjo and agreed that a portage news item would be a good idea.
Please review my proposal below.  Thank you!

Best,



Sebastian


===
Title: Apache AddHandler vulnerability protection
Author: Sebastian Pipping sp...@gentoo.org
Content-Type: text/plain
Posted: 2015-03-26
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: www-servers/apache

Apache's directive AddHandler [1] can be used to map
certain file name extensions (e.g. .php) to a handler
(e.g. application/x-httpd-php).  While a line like

  AddHandler application/x-httpd-php .php .php5 .phtml

matches index.php, it also matches index.php.png.

Apache's notes on multiple file extensions [2] document
a multi-language website as a context where that behavior
may be helpful.  Unfortunately, it can be a security threat.

Combined with (not just PHP) applications that support
file upload, the AddHandler directive can get you into
remote code execution situations.

That is why app-admin/eselect-php now avoids AddHandler
and is shipping

  FilesMatch \.(php|php5|phtml)$
SetHandler application/x-httpd-php
  /FilesMatch

instead.


Why this news entry?

 * Since Apache configuration lives below /etc,
   you need to run etc-update (or a substitute)
   to actually have related fixes applied.

 * You may be using AddHandler at other places,
   including off-package files.  Please have a look.

 * app-admin/eselect-php is not the only package
   affected.  There is a dedicated tracker bug at [3].
   As of the momment, affected packages include:

 app-admin/eselect-php[apache2]
 dev-lang/php[apache2]
 net-nds/gosa-core
 www-apache/mod_fastcgi
 www-apache/mod_flvx
 www-apache/mod_python
 www-apache/mod_suphp
 www-apps/moinmoin
 www-apps/rt[-lighttpd]


[1] https://httpd.apache.org/docs/current/mod/mod_mime.html#addhandler
[2] https://httpd.apache.org/docs/current/mod/mod_mime.html#multipleext
[3] https://bugs.gentoo.org/show_bug.cgi?id=544560



Re: [gentoo-dev] Review: Apache AddHandler news item

2015-03-26 Thread Sebastian Pipping
On 26.03.2015 18:02, Michael Orlitzky wrote:
 The most important reason is missing =)
 
 If you are relying on the AddHandler behavior to execute
 secret_database_stuff.php.inc, then once the change is made, Apache will
 begin serving up your database credentials in plain text.

Good point.


Changes:

 * Revision bump

 * Add section on .php.inc

 * Add thanks line



Title: Apache AddHandler vulnerability protection
Author: Sebastian Pipping sp...@gentoo.org
Content-Type: text/plain
Posted: 2015-03-26
Revision: 2
News-Item-Format: 1.0
Display-If-Installed: www-servers/apache

Apache's directive AddHandler [1] can be used to map
certain file name extensions (e.g. .php) to a handler
(e.g. application/x-httpd-php).  While a line like

  AddHandler application/x-httpd-php .php .php5 .phtml

matches index.php, it also matches index.php.png.

Apache's notes on multiple file extensions [2] document
a multi-language website as a context where that behavior
may be helpful.  Unfortunately, it can be a security threat.

Combined with (not just PHP) applications that support
file upload, the AddHandler directive can get you into
remote code execution situations.

That is why app-admin/eselect-php now avoids AddHandler
and is shipping

  FilesMatch \.(php|php5|phtml)$
SetHandler application/x-httpd-php
  /FilesMatch

instead.


Why this news entry?

 * Since Apache configuration lives below /etc,
   you need to run etc-update (or a substitute)
   to actually have related fixes applied.

 * If you are currently relying on AddHandler to execute
   secret_database_stuff.php.inc, moving away from AddHandler
   could result in serving your database credentials in plain
   text.  A command like

 find /var/www/ -name '*.php.*' \
 -o -name '*.php5.*' \
 -o -name '*.phtml.*'

   may help discovering PHP files that would no longer be executed.

 * You may be using AddHandler at other places,
   including off-package files.  Please have a look.

 * app-admin/eselect-php is not the only package
   affected.  There is a dedicated tracker bug at [3].
   As of the momment, affected packages include:

 app-admin/eselect-php[apache2]
 dev-lang/php[apache2]
 net-nds/gosa-core
 www-apache/mod_fastcgi
 www-apache/mod_flvx
 www-apache/mod_python
 www-apache/mod_suphp
 www-apps/moinmoin
 www-apps/rt[-lighttpd]


Thanks to Nico Suhl and Michael Orlitzky.

[1] https://httpd.apache.org/docs/current/mod/mod_mime.html#addhandler
[2] https://httpd.apache.org/docs/current/mod/mod_mime.html#multipleext
[3] https://bugs.gentoo.org/show_bug.cgi?id=544560




Re: [gentoo-dev] Review: Apache AddHandler news item

2015-03-26 Thread Sebastian Pipping
On 26.03.2015 20:50, Marc Schiffbauer wrote:
 * Sebastian Pipping schrieb am 26.03.15 um 19:15 Uhr:
 As of the momment, affected packages include:
 ^ Typo

Thanks.  Fixed in my local copy.  No need to re-paste, I believe.

Best,



Sebastian



Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted

2015-03-26 Thread Sebastian Pipping
On 14.03.2015 23:25, Robin H. Johnson wrote:
 Trying to explain to a new user that the Portage tree refers to the
 collection of ebuilds used by a PMS-compliant package manager (eg
 Portage) is problematic.

Full ack.  Let's limit portage to the piece of software, please.


 Questions: 0. What names for the tree/repository.

It's not a tree.  Ideally, it would be a directed acyclic graph (DAG),
there maybe be some loops, even.

I would therefore object to any name that has tree in it.


Since there are other Gentoo-based distros, I would say the word
gentoo should be in there.

Plain gentoo may work.  I would be happy with any of
gentoo-{core,main,master} as well, if plain gentoo causes trouble
for a name in some context.


 1. We have some namespaces in Git: proj, dev, priv, data, sites,
 exp; should the tree be in one of those namespaces, a new
 namespace, or be without a namespace?
 git://anongit.gentoo.org/NEW-NAME.git.

Not in any of those namespace, please.

If in any, make it repos or repositories, please.


Thanks for your consideration.

Best,



Sebastian



Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted

2015-03-26 Thread Sebastian Pipping
On 15.03.2015 10:48, Ulrich Mueller wrote:
 If we want a separate repo/ namespace, we would probably need to 
 consider moving other repositories there -- at least the
 official ones. Of course, it would be a nice result, having
 everything hosted on git.g.o as git.g.o/repo/${repo_name}.git.
 
 Isn't repo fairly redundant? Everything there is a repository.

There are Git repositories that do not contain ebuilds up there.  So
repo is not redundant if it refers to its overlays kind of meaning.

Two examples:

  http://gitweb.gentoo.org/proj/portage-utils.git/
  http://gitweb.gentoo.org/proj/userinfo-scripts.git/

Best,



Sebastian



Re: [gentoo-dev] [rfc] Rendering the official Gentoo logo / Blender,2.04, Python 2.2

2015-03-25 Thread Sebastian Pipping
On 07.06.2011 11:15, Mario Bodemann wrote:
 Hi folks,
 
 Sebastian told me about the problem of not being able to render the
 logo in recent blender versions. So this is were I stepped in: I tried
 it and used the geometries from the old .blender file, and the
 yellowish reflecting image.
 
 Problem was to recreate the exact representation of the original logo,
 by new means of rendering and relighting. I tried to solve them by
 creating a new material for the g and carefully adjusting the
 parameters. Also I added a new modifier for the geometry to get rid of
 the ugly seam at the sharp edge. (This does not modify the geometry,
 only the rendering of it)
 
 However, here are my preliminary results:
 
  - the modified .blend-file[1] (tested with blender 2.57b)
  - new rendered logo image [2]
  - original logo image (for comparison)[3]
 
 What do you think?
 
 Greetings, Mario.
 
 [1]
 http://git.goodpoint.de/?p=g-metal-blend.git;a=blob_plain;f=g-metal.blend;hb=master
 [2]
 http://git.goodpoint.de/?p=g-metal-blend.git;a=blob_plain;f=g-metal.png;hb=images
 [3]
 http://git.goodpoint.de/?p=g-metal-blend.git;a=blob_plain;f=g-metal-orig.png;hb=images

For the record, I have resurrected that repository at

  https://github.com/gentoo/blender-gentoo-logo

now.  For the images [2][3], have a look at the images branch:

  https://github.com/gentoo/blender-gentoo-logo/tree/images

Best,



Sebastian




Re: [gentoo-dev] collab herd for cooperative pkg maintenance

2015-03-25 Thread Sebastian Pipping
On 23.03.2015 18:22, Tim Harder wrote:
 With that in mind, I think it would be an interesting experiment if
 we had a collaborative herd (probably named collab) that signals
 the status that anyone is generally free to fix, bump, or do sane
 things to the pkgs with the caveat that you fix what you break.

+1

(to any other non-herd marker in metadata.xml to achieve the same
effect, too)



Sebastian




Re: [gentoo-dev] Re: [rfc] Rendering the official Gentoo logo / Blender 2.04, Python 2.2

2015-03-02 Thread Sebastian Pipping
On 23.02.2015 23:34, Daniel Campbell wrote:
 Can't the logo be remade in a more recent version of Blender? Assuming
 you can run two separate Blender instances, it would mostly be copying
 the poly/vertex values from one to the other.
 
 I'm not versed in 3-D but it would surprise me if there wasn't a
 standard mesh format.

There was an attempt to port to a recent version of Blender.  When
comparing renderings, the result is close, but not 1:1.  Please check
Mario's reply of 2011 in this very thread
(http://thread.gmane.org/gmane.linux.gentoo.devel/70870).

Best,



Sebastian




Re: [gentoo-dev] Re: [rfc] Rendering the official Gentoo logo / Blender 2.04, Python 2.2

2015-02-23 Thread Sebastian Pipping
Hi!


Please excuse bringing up a topic as old as this, again.
Only bringing up half, actually.


On 05.05.2011 07:36, Sebastian Pipping wrote:
 On 05/01/2011 06:10 AM, Ulrich Mueller wrote:
 Could you bisect Blender to find out why it doesn't work with the new
 version?
 
 I tried a few more versions now.  While Blender 2.31a still applies the
 reflection texture, Blender 2.32 does not anymore.  At least on
 http://download.blender.org/source/ these two appear as consecutive
 releases.

While doing digital cleaning over here I ran into my patches to make
ancient Blender compile again for Gentoo logo rendering.

I have streamlined those into ebuilds and a dedicated overlay

  https://github.com/gentoo/blender-gentoo-logo-overlay

and filled the void in the Gentoo wiki

  https://wiki.gentoo.org/wiki/Project:Artwork/Artwork#The_blue_.22g.22_logo

with a few words and pointers.

The ebuilds are:

  dev-lang/python/
python-2.2-r8.ebuild

  media-gfx/blender/
blender-2.26.ebuild
blender-2.31a.ebuild

So whoever needs to render Blender files from 2003 again at some point
should find working ebuilds to do that.  Feel free to join keeping them
in good installable shape.

Thanks and best,



Sebastian




Re: [gentoo-dev] CPU_FLAGS_X86 gentoo repository migration complete

2015-02-01 Thread Sebastian Pipping
On 01.02.2015 23:17, Michał Górny wrote:
 Hi, developers.
 
 Just a quick note: the CPU_FLAGS_X86 conversion of the Gentoo 
 repository is complete now.

Cool!  Thanks for fixing the freeverb3 ebuild, too.

Best,



Sebastian




Re: [gentoo-dev] arm64

2015-02-01 Thread Sebastian Pipping
Thanks!

The issue and fix are clear by now (for details:
http://sourceforge.net/p/uriparser/bugs/24/).

So I don't need shell access any more, at least not in this context.

Best, Sebastian


On 25.01.2015 18:49, Tom Gall wrote:
 Least speaking for myself I can help you out starting Feb 15th, presuming all 
 the stars are in alignment. If someone else doesn’t help you before, please 
 mark it on your calendar and bug me again then cause I’m sure I’ll forget!
 
 Best,
 Tom
 
 
 On Jan 25, 2015, at 11:43 AM, Sebastian Pipping sp...@gentoo.org wrote:

 Hi!


 I got a bug report for arm64 against the test suite of uriparser.  If I
 could get a temporary arm64 shell somewhere, that could help me
 understand the issue.

 Best,



 Sebastian


 
 




Re: [gentoo-dev] arm64

2015-01-25 Thread Sebastian Pipping
Hi!


I got a bug report for arm64 against the test suite of uriparser.  If I
could get a temporary arm64 shell somewhere, that could help me
understand the issue.

Best,



Sebastian




[gentoo-dev] Where to install Grub2 background images too?

2015-01-12 Thread Sebastian Pipping
Hi!


Debian is putting Grub2 background (or splash) images into
/usr/share/images/grub/ [1] but we do no not have an /usr/share/images/
folder.
(I'm not referring to full themes, just background images.)

If I were to make media-gfx/grub-splashes:2, where would it install to?

Thanks,



Sebastian


[1] https://packages.debian.org/de/squeeze/all/grub2-splashimages/filelist



Re: [gentoo-dev] debootstrap equivalent for Gentoo?

2015-01-01 Thread Sebastian Pipping
Hi!


On 28.12.2014 11:26, Johann Schmitz (ercpe) wrote:
 I wrote gentoo-bootstrap
 (https://github.com/ercpe/gentoo-bootstrap) some time ago to
 automate the creation of Gentoo Xen DomU's at work. It can do a lot
 of more things (e.g. installing packages, overlays, etc.).

Interesting tool!


 (shame on me) it doesn't do signature verification yet.

I've opened a ticket for it on GitHub now:

https://github.com/ercpe/gentoo-bootstrap/issues/1

Best,



Sebastian



[gentoo-dev] debootstrap equivalent for Gentoo?

2014-12-27 Thread Sebastian Pipping
Hi!


I'm wondering if there is an equivalent of debootstrap of Debian
anywhere.  By equivalent I mean a tool that ..

 * I can run like command FOLDER with a chroot-able
   Gentoo system in FOLDER after and

 * for both stage3 and portage tarballs
   * Downloading tarball
   * Downloading signature file
   * Verifying signature
   * Extracting

Has anyone seen something like that?

Thanks,



Sebastian



Re: [gentoo-dev] Last rites: dev-php/{adodb-ext,eaccelerator,pecl-apc,pecl-id3,pecl-mogilefs,pecl-sca_sdo,suhosin}

2014-10-05 Thread Sebastian Pipping
Hi Brian,


On 02.10.2014 20:29, Brian Evans wrote:
 # Brian Evans grkni...@gentoo.org ( 1 Oct 2014 ) # Masked for
 removal in 30 days. # Broken on =dev-lang/php-5.4.  No
 replacements known. [..] dev-php/suhosin

is that true for suhosin?

Upstream reads

  has been tested with PHP 5.4 and 5.5 [1]

and there is

  dev-php/suhosin: version bump - 0.9.36 is available and has been
  tested with PHP 5.4 and 5.5
  https://bugs.gentoo.org/show_bug.cgi?id=520178

too.

So at least to me this looks like to early or potentially not even
needed.  If it is broken fro 5.4/5.5 please share details on why it
really is and update the bug mentioned above too, please.

Thanks!

Best,



Sebastian


[1] http://suhosin.org/stories/install.html



[gentoo-dev] Packages up for grabs

2014-09-18 Thread Sebastian Pipping
Hello!


Below are some packages that I fail to take care of as needed and have
not been using myself for a while.  Please take over whatever you have
interest in:

   Latest  Open bugs
  
  app-text/xmlstarlet  yes no

  media-libs/libmp3spltyes yes
  media-sound/mp3splt-gtk  yes yes
  media-sound/mp3splt  yes yes

  dev-python/html2text no/2014.9.8 no
  dev-python/inotifyx  no/0.2.2no
  games-action/openlierox  no/0.59_beta10  no
  media-gfx/drqueueyes yes
  media-libs/opencollada   no/?yes
  sys-fs/pytagsfs  yes yes


Many thanks,



Sebastian



Re: [gentoo-dev] New Python eclasses -- a summary and reminder

2013-02-24 Thread Sebastian Pipping
Looks like great work so far.


On 11.02.2013 01:20, Michał Górny wrote:
 Secondly, I'd like to make it clear that the old python.eclass is 
 'almost' deprecated. We're in process of converting the in-tree 
 packages to use the new eclasses but that's a lot of work [3].
 
 [..]
 
 [3]:http://dev.gentoo.org/~mgorny/python-r1/conversion.xhtml

I wonder what would be the best way to help with conversion for devs
with a few hours to contribute?

 - Where does one go for peer review and how many eyes should be on
   related commits?

 - Should package owners be contacted in all cases?

 - Are there any conversion sprints already or in the future?

Best,



Sebastian




Re: [gentoo-dev] What did we achieve in 2012? What are our resolutions for 2013?

2013-01-04 Thread Sebastian Pipping
Coming to my mind:


There have been continued regular releases of genkernel integrating
patches from various people:
http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=tags

And there has been a constant stream of people asking for user overlay
hosting or getting an existing overlay being added to the layman
registry that we could serve.


Ben, I hope you have the time to make a news post from this thread's
collection?


Best,



Sebastian




Re: [gentoo-dev] Is /var/cache the right place for repositories?

2012-12-23 Thread Sebastian Pipping
On 20.12.2012 19:14, Ciaran McCreesh wrote:
 The tree is a database. It belongs in /var/db/.

I don't see /var/db in the latest release of the Filesystem Hierarchy
Standard:

  http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY

I would prefer something that blends with FHS.

Best,



Sebastian



Re: [gentoo-dev] Is /var/cache the right place for repositories?

2012-12-23 Thread Sebastian Pipping
On 20.12.2012 18:27, Ulrich Mueller wrote:
 Now I wonder: After removal of e.g. the Portage tree from a system, it
 is generally not possible to restore it. (It can be refetched, but not
 to its previous state.)
 
 Same is true for distfiles, at least to some degree. They may have
 vanished upstream or from mirrors.
 
 Maybe /var/lib would be a better choice? It would also take care of
 the issue with fetch-restricted files.

Thanks for bringing it up.  What you address above is the exact reason
why Layman's home was moved to /var/lib/layman/ eventually.  It has a
cache aspect, bit it's not a true cache.

Best,



Sebastian




Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele

2012-12-02 Thread Sebastian Pipping
On 11/24/2012 10:12 PM, Pacho Ramos wrote:
 # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Upstream dead and
 no longer runs (#402669). # Removal in a month app-cdr/dvd95

Bug fixed.  I just ripped a DVD with dvd95 successfully.

+  02 Dec 2012; Sebastian Pipping sp...@gentoo.org package.mask:
+  Keep dvd95 since bug #402669 is now fixed
+


 # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Fails to build
 with gcc-4.7 and maintainer is ok with dropping (#424723). #
 Removal in a month. app-shells/localshell

FYI bug fixed, removal prevented by robbat2.

Best,



Sebastian




[gentoo-dev] Last rites: app-admin/smolt

2012-11-27 Thread Sebastian Pipping
# Sebastian Pipping sp...@gentoo.org (27 Nov 2012)
# Masked for removal in 30 days.
# Server and software development discontinued upstream (bug #438082)
app-admin/smolt




[gentoo-dev] Last rites: app-admin/profiler

2012-11-27 Thread Sebastian Pipping
# Sebastian Pipping sp...@gentoo.org (27 Nov 2012)
# Masked for removal in 30 days.
# Licensing issues, turned out not distributable (bug #444332)
app-admin/profiler



Re: [gentoo-dev] License groups in ebuilds

2012-06-16 Thread Sebastian Pipping
On 05/10/2012 11:39 AM, Ulrich Mueller wrote:
 Are there any other licenses besides *GPL and FDL that would require such a 
 file?
 
 What do you think?

The GPL-2+ file workaround doesn't sound to bad.

Call be picky, but we could actually use a GPL-3+ file, too.  With
that we could distinguish exactly GPL 3 and GPL 3 or later properly
on our end, no matter if GPL 4 ever comes or not.

Best,



Sebastian



Re: [gentoo-dev] gtk3 useflag and support of older toolkits

2012-06-10 Thread Sebastian Pipping
On 06/10/2012 05:54 AM, Alexandre Rostovtsev wrote:
 For libraries, if possible, try splitting gtk2 and gtk3 support into
 different slots (see net-libs/webkit-gtk for an example; the gtk2-based
 versions have -r2xx revision numbers and go in slot 2, while the
 gtk3-based versions have -r3xx revision numbers and go in slot 3).

That's a crazy but interesting approach.

Best,



Sebastian



[gentoo-dev] Re: [gentoo-dev-announce] Lastrite: 4suite, amara and testoob (mostly for security)

2012-05-16 Thread Sebastian Pipping
On 05/16/2012 10:40 AM, Samuli Suominen wrote:
 # Samuli Suominen ssuomi...@gentoo.org (16 May 2012)
 # Internal copy of vulnerable dev-libs/expat wrt #250930,
 # CVE-2009-{3720,3560} and CVE-2012-{0876,1147,1148}.
 #
 # Fails to compile wrt bug #368089
 # Bad migration away from dev-python/pyxml wrt #367745
 #
 # Removal in 30 days.
 dev-python/4suite

Can I veto on 4suite (without fixing things myself yet) ?

Thanks,



Sebastian



Re: [gentoo-dev] Arbitrary breakage: sys-fs/cryptsetup

2012-03-29 Thread Sebastian Pipping
On 03/22/2012 03:20 PM, Alexandre Rostovtsev wrote:
 [1] For one, genkernel should bomb out if it can't comply with a
 command-line arg instead of just putting non-alert text up.
 
 There is already a bug open about this issue:
 https://bugs.gentoo.org/show_bug.cgi?id=409277

With that bug fixed by now is there still need for a news entry?

Best,



Sebastian



[gentoo-dev] Re: [gentoo-dev-announce] Last rites: Various horde packages

2012-03-28 Thread Sebastian Pipping
Hello!


Would it make sense to move these ebuilds to a dedicated overlay?
I can think of one IPS that uses both Gentoo and Horde [1] (though I'm
not sure which version and if in combination).  A imagine that a
dedicated overlay could be both a service to people who still rely on
horde and at the same time encourage them to step up to maintenance.
With a dedicated overlay we wouldn't need to worry about write access
as much as with the main tree.


[1] https://webmail.df.eu/horde/login.php


On 03/28/2012 06:26 PM, Alex Legler wrote:
 Up for removal in 4 weeks:
 
 # Alex Legler a...@gentoo.org (28 Nov 2010) # Not maintained,
 multiple security issues. # Use the split horde ebuilds instead.

While I don't use horde from a Gentoo perspective, I'm curious: which
remaining split ebuilds are you referring to?  For Horde 3 webmail:
which ebuild would a user need now?


 www-apps/horde-webmail www-apps/horde-groupware
 
 # Alex Legler a...@gentoo.org (28 Mar 2012) # Leftover packages
 from a packaging attempt of Horde-4 # These can be readded when
 someone picks the package up dev-php/Horde_ActiveSync [..] 
 dev-php/Horde_Yaml

For those interested a diff says that these Horde packages remain:

  www-apps/horde
  www-apps/horde-chora
  www-apps/horde-dimp
  www-apps/horde-gollem
  www-apps/horde-hermes
  www-apps/horde-imp
  www-apps/horde-ingo
  www-apps/horde-jeta
  www-apps/horde-kronolith
  www-apps/horde-mimp
  www-apps/horde-mnemo
  www-apps/horde-nag
  www-apps/horde-passwd
  www-apps/horde-pear
  www-apps/horde-turba

Best,



Sebastian



Re: [gentoo-dev] [rfc] Which ebuild category should these ebulds go into?

2012-02-01 Thread Sebastian Pipping
On 02/01/2012 09:42 AM, ScytheMan wrote:
 Take a look at g15daemon (useful for some logitech keyboards).
 
 There you have:
 
 app-misc/g15daemon
 dev-libs/libg15
 

Great, thanks!

Best,




Sebastian



[gentoo-dev] [rfc] Which ebuild category should these ebulds go into?

2012-01-31 Thread Sebastian Pipping
Hello!


Anthoine and I are working on some new ebuilds related to a 3D mouse at
the moment.  For two of these I wonder what package category makes a
good fit.  While I would save your time on such a simple thing, I would
like to avoid moving around things later, too.  I have inspected the
related metadata.xml files already.

Which categories do you advise for?

  spacenavd
driver daemon (with optional X support)
  -- sys-apps/spacenavd ?
  -- app-misc/spacenavd ?
  -- .. ?

  libspnav
library accessing before-mentioned daemon
  -- dev-libs/libspnav ?
  -- media-libs/libspnav ?
  -- sys-libs/libspnav ?
  -- .. ?

  spnavcfg
X11/GTK GUI tool for configuration
  -- x11-misc/spnavcfg seems right

Thanks in advance!

Best,



Sebastian



[gentoo-dev] New maintainer needed: net-misc/aria2

2012-01-11 Thread Sebastian Pipping
Hello!


While someone else is the official maintainer of net-misc/aria2, I have
done the last 5 version bumps or so on net-misc/aria.

I have gotten a little behind with it lately: 1.12.1 is the latest in
tree, upstream has 1.13.0, 1.14.0 and the very fresh 1.14.1.
One reason for that is that I don't use aria2 myself that much if at
all.  Another is that the next version bump needs more care than just
copy-and-commit: some dependencies have changed.

I would like to pass package net-misc/aria2 on to one of you.  With the
help of the proxy maintainer team this could even be someone who is not
yet a Gentoo developer.

Besides the test suite, nothing needs patching in the latest ebuild of
1.12.1.  There is three open bugs [1].

If you want to take over, please go ahead.  Maybe leave a short reply in
this thread.  Thanks!

Best,



Sebastian


[1]
https://bugs.gentoo.org/buglist.cgi?quicksearch=net-misc%2Faria2;list_id=712171



 Original Message 
Subject: aria2 maintenance
Date: Sat, 31 Dec 2011 19:00:56 +0100
From: Sebastian Pipping sp...@gentoo.org
To: ..@gentoo.org

Hello ..,


it looks like you don't really have time or interest to keep aria2 up to
speed.  More or less the same on my end.

Would you mind if I publicly ask for a new maintainer for aria2?
If I do not hear from you within a week I take no answer as a yes.

Best,



Sebastian



[gentoo-dev] unison needs some love

2011-08-03 Thread Sebastian Pipping
Hello!


Version in Gentoo: 2.32.52
Version upstream:  2.40.63


https://bugs.gentoo.org/show_bug.cgi?id=353282

The bug is old enough to justify a takeover to me, provided you act with
resonable care.




Sebastian




Re: [gentoo-dev] unison needs some love

2011-08-03 Thread Sebastian Pipping
On 08/03/2011 07:37 PM, Alexis Ballier wrote:
 I'm more or less alone in the ml herd (maintainer) and I don't use
 unison :(

While you mention the herd: how come this is herd=ml?

Best,




Sebastian



Re: [gentoo-dev] Last Rites: sys-fs/evms

2011-07-03 Thread Sebastian Pipping
On 07/03/2011 11:34 AM, Markos Chandras wrote:
 Hi Sebastian,
 
 sys-fs/evms is now gone

Thanks for the notification.

I have updated genkernel 3.4.17 accordingly.



Sebastian



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/aria2: aria2-1.12.0.ebuild ChangeLog

2011-07-01 Thread Sebastian Pipping
On 07/01/2011 10:03 AM, Peter Volkov wrote:
 В Чтв, 30/06/2011 в 19:27 +, Sebastian Pipping (sping) пишет: 
 Log:
   net-misc/aria2: Bump to 1.12.0, looks trivial
  
 EAPI=2

 inherit bash-completion
 ...
 pkg_setup() {
  if use scripts  use !xmlrpc  use !metalink; then
  ewarn Please also enable the 'xmlrpc' USE flag to actually use 
 the additional scripts
  fi
 }
 
 This really calls for REQUIRED_USE from EAPI=4.
 
 REQUIRED_USE=scripts? ( ^^ ( xmlrpc metalink ) )

If we use EAPI 4 in that ebuild we cannot make it stable anytime soon,
correct?



Sebastian



Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml

2011-06-10 Thread Sebastian Pipping
On 06/09/2011 03:37 PM, Rich Freeman wrote:
 do we need some kind of policy around membership on special
 project teams. QA and Devrel are the most obvious examples, Infra might
 be another.

in my eyes we do.  too much power to be unregulated.

what does it take to get this rolling?



sebastian



Re: [gentoo-dev] Reviving webapp-config

2011-06-10 Thread Sebastian Pipping
Questions:

 - What does reviving mean in detail?
 A re-write?  A somewhat compatible re-write?
 Getting back to maintaining the current code?
 Why did you choose how you did?

 - Have you spoken to Andreas Nüsslein who worked on a
   re-write in context of an earlier GSoC?

Best,




Sebastian



Re: [gentoo-dev] Reviving webapp-config

2011-06-10 Thread Sebastian Pipping
On 06/10/2011 05:38 PM, Matthew Summers wrote:
 Why did you choose how you did?
 
 I do not understand this sentence, 

I intended to write as you did, sorry.  If that's still bad English: I
wanted to hear about your rationale, which you have explained by now.
Thanks.


 [..] this tool has an
 important role in Gentoo and therefore needs to be revived.

I wished people were thinking like that about genkernel :-)

Best,



Sebastian



Re: [gentoo-dev] Gentoo package statistics -- GSoC 2011

2011-06-10 Thread Sebastian Pipping
On 06/08/2011 04:36 PM, Vikraman wrote:
 * Repository, Keyword, Useflags (plus,minus,unset), Counter, Size,
   and Build   time for each installed package

How many operations do you expect for a submissions with 1000 packages
on SQL level?  Will that be around 1000 inserts?

Best,



Sebastian



Re: [gentoo-dev] Last Rites: sys-fs/evms

2011-06-06 Thread Sebastian Pipping
On 06/03/2011 11:32 PM, Markos Chandras wrote:
 # Markos Chandras hwoar...@gentoo.org (3 Jun 2011)
 # Dead upstrea, many open bugs, partially working with
 # kernel-2.6
 # Bugs #159741, #159838, #165120, #165200, #231459,
 # #273902, #278949, #305155, #330523, #369293
 # Masked for removal in 30 days
 # Alternative: sys-fs/lvm2
 sys-fs/evms

EVMS is a soft dependency of genkernel.  If sys-fs/evms is removed, EVMS
support will have to be removed from genkernel, too.

If you go forward please notify the genkernel team once EVMS has been
removed so we can update genkernel accordingly.  Thanks!

Best,



Sebastian



[gentoo-dev] Test request: open-iscsi 2.0.872

2011-06-05 Thread Sebastian Pipping
Hello!


Would be great to have a few people test open-iscsi 2.0.872 before
moving it from overlay betagarden to the main tree.  To get it installed
please run:

  # layman -a betagarden
  # emerge -av =sys-block/open-iscsi-2.0.872

Important: Please include a description of what you did while testing in
your feedback.  At best, post your feedback as a reply to bug 340425:

  https://bugs.gentoo.org/show_bug.cgi?id=340425

Thanks in advance!

Best,



Sebastian



[gentoo-dev] Re: Test request: open-iscsi 2.0.872

2011-06-05 Thread Sebastian Pipping
PS: I noticed the typo in

  gentoo-users@lists.g.o
 ^
and sent a new mail to gentoo-user@lists.g.o now.



Sebastian



[gentoo-dev] Genkernel needs more hands

2011-05-17 Thread Sebastian Pipping
Hello,


Genkernel's situation (reduced to the three currently most active
players) looks like this to me:

 - aidecoe
   - is focussed on the transition to Dracut and related things
   - is fixing bugs in present genkernel from time to time

 - xake
   - is fixing bugs in the current genkernel releases
   - likes his patches to be reviewed
   - cannot do releases as he has no developer account, yet

 - sping (me)
   - writes and applies patches from time to time.
   (Commitment varies, at a low right now.)
   - has never used half of the many technologies involved himself
   (iSCSI, dmraid, netboot, ...)
   - is the bottleneck on some reviews and releases

There are various bugs around, some just need attention, some could use
insider knowledge that we lack.  Furthermore the kernel configs shipped
by Genkernel are mainly from a time before the three of us took over and
need fixes, a concept and documentation too.  There is no test suite
(virtual machines?) that I knew of catching regressions (of which we had
few only, in that light).


Nevertheless genkernel has fun aspects: it's in much better shape than
3.4.10.907 was, including documentation.  It's a core Gentoo tool used
by quite a few people so the work you do on Genkernel matters.
With that in mind:

Are you interested in joining Genkernel?

Thanks,



Sebastian



Re: [gentoo-dev] Re: [rfc] Rendering the official Gentoo logo / Blender 2.04, Python 2.2

2011-05-04 Thread Sebastian Pipping
On 05/01/2011 06:10 AM, Ulrich Mueller wrote:
 Could you bisect Blender to find out why it doesn't work with the new
 version?

If 2.26 still produced good results, 2.37a already does not.  Bisecting
involves fixing compilation for each version.  I stopped getting 2.30 to
compile because it seemed to take forever (longer than fixing 2.26,
2.37a and 2.40 together) and two people had their hands on a port of the
logo to Blender 2.57 by then, one of them still has.  It's too early to
give details.  What I can say is that personally I would want a very
close match in case of a Blender-based replacement, closer than what I
have seen so far.  It still seems possible though.

Best,



Sebastian



Re: [gentoo-dev] Re: [rfc] Rendering the official Gentoo logo / Blender 2.04, Python 2.2

2011-05-04 Thread Sebastian Pipping
On 05/01/2011 08:06 AM, Michał Górny wrote:
 Isn't it possible to create a better SVG then?

It may be.  Of the three variants trying to match the Blender version
that I have seen so far, none is a replacement of equal quality on the
bling scale to my impression.  They feel like tradeoffs, not like the
real thing.  Maybe they try to come too close to the ray-traced
rendering, but I'm not sure if I really want to propose a different
direction either.


 I think such a variant
 would be much more portable and reproducible than blender files.

What I dislike about the idea of moving to a new logo is that we would
give up part of our culture just because we were unable to move it from
past to present to future.  Imagine this dialog:

 A: Hey guys, I noticed you have a new logo?
 B: Yeah, blender rendering changed - so we dropped it.

I don't really want to be B in that dialog.  I see the pragmatic aspect
of moving to SVG but it also has the taste of giving up to me.  To
vercome that taste, a very strong replacement would be needed.

If we replace the Blender g we may also need a substitute for the
red-white Blender gentoo as seen at
http://sources.gentoo.org/cgi-bin/viewvc.cgi/*docroot*/images/gentoo-new.gif
if just for the sake of consistency.

I am wondering what effect the Blender nature of a logo does have on the
capability and will of people to create fan art based on it compared to
an SVG version.  It seems like there is only a handful of 3D Gentoo
wallpapers but does that mean it would have been more with an SVG
version, instead?  On what levels could SVG work as a catalyst?

If we ported the logo to Blender 2.57 now: what can we do to not be
running after Blender rendering changes for all time or to reduce their
impact on us?  Is this a natural cost or an evil one?

Just my 2 cents.

Best,



Sebastian



Re: [gentoo-dev] Re: [rfc] Rendering the official Gentoo logo / Blender 2.04, Python 2.2

2011-05-04 Thread Sebastian Pipping
On 05/01/2011 06:10 AM, Ulrich Mueller wrote:
 Could you bisect Blender to find out why it doesn't work with the new
 version?

I tried a few more versions now.  While Blender 2.31a still applies the
reflection texture, Blender 2.32 does not anymore.  At least on
http://download.blender.org/source/ these two appear as consecutive
releases.  Both of these seem to run fine with Python 2.4.6, which is
still in Gentoo.  Without good image diffs, I cannot tell for sure if
the rendering has changed since Blender 2.04.

Best,



Sebastian



[gentoo-dev] [rfc] Rendering the official Gentoo logo / Blender 2.04, Python 2.2

2011-04-28 Thread Sebastian Pipping
Hello!


Gentoo's official logo originates from a Blender file [1] created by
Daniel Robbis over 8 years ago.  He used Blender 2.04 and Python 1.6 at
that time.

When rendering that .blend file with Blender 2.49b (or a more recent
version), Blender does not apply the reflection texture needed [2] to
give the metal look that you know.  I don't know why that is.  All I
know is that Blender does find the file: it's not about the location.

Trying Blender 2.04 binaries on a Windows VM, it turned out that Blender
2.04 is still able to render our logo as expected.  In my eyes rendering
our logo should not depend on a proprietary operating system or binary
blobs.  The source tarball of Blender 2.04 is hard to find (if available
at all), the available sources of 2.03 [7] are incomplete.  Binaries of
2.04 [8] are 32bit only and crash on startup on my system.

The earliest source tarball after 2.04 that upstream offers for download
[3] is Blender 2.26.  That version does not compile with GCC 4.4 and
turns out to be home with Python 2.2.  In hope that this version would
be able to render our logo in the way that Blender 2.04 did, I tried
fixing compilation against GCC 4.4.5.  That worked [4].  The need for
Python 2.2 became clear when all of Python 2.4, 2.4 and 2.6 made it
segfault in Python related code instantly.  Therefore I tried bringing
our old Python 2.2-r7 ebuild to life.  Smaller changes like -fPIC were
needed but it wasn't too hard.  You can find the Python 2.2-r8 in the
betagarden overlay [6].  In the end I could do

  sudo eselect python set python2.2

to compile and run Blender 2.26 and make it render g-metal.blend (after
adjusting the path to the reflection texture) with metal look in a
resolution of a few megapixel on transparent background.
I have the impression, that the rending is the same as of Blender 2.04.


However, this is not a good long-term solution.  For instance Portage
doesn't operate under Python 2.2 so an ebuild for Blender 2.25 is a
tricky thing to do nowadays.

Among the options I see is the following:

 A) Find out how to render g-metal.blend with recent Blender
(2.57b at best) to give pixel-identical results to Blender 2.04.
Needs an advanced Blender user ideally.

 B) Port Blender 2.26 to a recent version of Python.

Are there any other options?

What do you think?

I would also like to encourage you to reproduce the process I described
to spot any problems I overlooked.

Thanks for reading up to this point.

Best,



Sebastian


[1]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/gentoo-web/blend/g-metal.blend
[2]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/gentoo-web/blend/metallandscape1.jpg
[3] http://download.blender.org/source/
[4] http://git.goodpoint.de/?p=blender-2.26.git;a=summary
[5]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-lang/python/python-2.2-r7.ebuild?hideattic=0view=markup
[6]
http://git.overlays.gentoo.org/gitweb/?p=proj/betagarden.git;a=commitdiff;h=a3712c45dee61717cbc09b39ff868af7a3ccaa89
[7] http://download.blender.org/source/chest/blender_2.03_tree.tar.gz
[8] http://download.blender.org/release/Blender2.04/



[gentoo-dev] Why a betagarden overlay

2011-03-15 Thread Sebastian Pipping
Hello!


First: If betagarden were a normal overlay, I would not be writing about
it here.

If you're in a hurry just skip the introduction and jump down to section
Betagarden overlay.


Introduction

The betagarden overlay has been around for a while.  I always wanted to
write about its purpose and invite you to collaboration but I haven't
got to it before.

I understand betagarden as a third place supplementing the Gentoo main
tree (sometimes known as gentoo-x86 or portage) and the special
overlay of Project Sunrise [1].  It fills a gap that these other two
repositories leave open.  Let's have a look:


  Gentoo Main tree
  
  - Post-publishing review
  - Territorial write access: Gentoo Developers (only)
  - Full write access: Gentoo QA maybe?
  - High quality standards

  sunrise overlay
  ---
  - Pre-publishing review
  - Reduced write access: Anyone passing a simple test [2]
  - Full write access: Project Sunrise developers (only)
  - High quality standards


From these lists a few things can be observed:

 1. Both trees require high quality from ebuilds.  This includes
- Full integration with Gentoo (menu entries, init scripts, etc.)
- Cleaning the ebuild
- Support for LDFLAGS
- ...

 2. Gentoo developers who are not fully committed to sunrise
do not have full write access to it


--  Wouldn't it be nice to have a place where polishing is optional
 (as long as the ebuilds are still safe) with more liberal write
 access?

But there's another group of repositories that I would also like to have
a look at:


Gentoo developer overlays
-
When you go to http://git.overlays.gentoo.org/gitweb/ you see them
instantly - most Gentoo devs have one:

  dev/aballier.git  Developer overlay  Alexis Ballier
  dev/alexxy.gitDeveloper overlay  Alexey Shvetsov
  dev/anarchy.git   Developer overlay  Jory Pratt
  dev/angelos.git   Developer overlay  Christoph Mende
  [..]

Many of these overlays currently combine two groups of ebuilds:

 - Stuff useful to themselves, only

 - Stuff useful to a wider audience
   (that they didn't feel like adding to the Gentoo main tree)


With such a mix it often makes no sense for somebody else to keep that
overlay installed over time.

--  Wouldn't it be nice to have the stuff useful to others in a more
 central place (and reduce your developer to stuff that basically is
 only interesting to you)?

Hollow and I (sping) have been trying to do that with our overlays:
moving stuff useful to others over to betagarden, a shared overlay.



Betagarden overlay
==
So now that I have shared my view on the Gentoo main tree, the sunrise
overlay and developer overlays let me summarize how betagarden fits in:

 - Full write access to all Gentoo Developers
   That means more freedom than in the main tree or sunrise.

 - Reduced (but essential) quality standards
   (hence the beta in betagarden)

 - Keeping really useful stuff off the developer overlays


How to join
---
All devs have write access to betagarden already.

 1. Clone git+ssh://g...@git.overlays.gentoo.org/proj/betagarden.git

 2. Add yourself to the betagar...@gentoo.org alias:
# ssh dev.gentoo.org
# nano -w /var/mail/alias/misc/betagarden

 3. Start adding (or moving over existing) ebuilds

If you have trouble pushing commits please contact overl...@gentoo.org.

In bugzilla, you can assign bugs to betagar...@gentoo.org by now.


Expected criticism
--
I expect some of you to be worried: does that mean people stop adding
quality ebuilds to the Gentoo main tree and move on to betagarden?

No.  If an ebuild is really important it belongs into the main tree.  In
that case someone will take the time to ensure high quality standards
and move it from betagarden to the main tree.


I hope some of you do see something good in this project.

Thanks for your interest,



Sebastian


[1] http://overlays.gentoo.org/proj/sunrise
[2] http://overlays.gentoo.org/proj/sunrise/wiki/HowToCommit#Password



Re: [gentoo-dev] News item: Dropping Java support on ia64 (retry)

2011-02-15 Thread Sebastian Pipping
The sentence

  If there is no interest, the removal of Java support well be done
   during the second half of March 2011.

seems to have some bugs.

I suppose well be done was meant to be will be done?
   ^
But maybe the removal [..] will be done could use re-writing, too.
How about this:

  If there is no interest, Java support will be removed
   from IA64 during the second half of March 2011.

Best,



Sebastian



[gentoo-dev] Downgrading glibc?

2011-02-11 Thread Sebastian Pipping
Hello!


In relation to bug 354395 [1] I would like to downgrade my glibc back to
2.12.2.  Portage doesn't allow me to do that:

 * Sanity check to keep you from breaking your system:
 *  Downgrading glibc is not supported and a sure way to destruction
 * ERROR: sys-libs/glibc-2.12.2 failed (setup phase):
 *   aborting to save your system

Can anyone guide me or point me to a guide how to savely do that manually?

Thanks,



Sebastian


[1] https://bugs.gentoo.org/show_bug.cgi?id=354395



Re: [gentoo-dev] Downgrading glibc?

2011-02-11 Thread Sebastian Pipping
A little update from my side:


I was abe to downgrade glibc to 2.12.2 and my sound problem [1] is now
gone again!  If it's not glibc itself, it's one of the packages
re-installed after (again, see [1] for the list).

If anyone considers masking glibc 2.13 for now: please take my vote.

Best,



Sebastian


[1] https://bugs.gentoo.org/show_bug.cgi?id=354395



Re: [gentoo-dev] Downgrading glibc?

2011-02-11 Thread Sebastian Pipping
On 02/11/11 13:26, Paweł Hajdan, Jr. wrote:
 Just curious, what downgrade method did you use? Just untaring an older
 glibc package?

This is what I did:

 0) Log out of X, log in to root console

 1) Collect packages emerged after previous update to glibc from
files in PORT_LOGDIR (using simple shell scripting)

 2) Emerge glibc 2.12.2

 3) Re-emerge packages from (1)

 4) Reboot

WARNING: It may not work as well on your system.

Best,



Sebastian



Re: [gentoo-dev] Re: Downgrading glibc?

2011-02-11 Thread Sebastian Pipping
On 02/11/2011 01:27 PM, Diego Elio Pettenò wrote:
 It should have been masked _beforehand_, masking it now is going to
 cause more trouble.

Portage will propose a downgrade of glibc on emerge-update-world, okay.
How bad would that be?  Does it cause any other trouble?


 Remember: unless you're able to rebuild everything that was built
 afterwards without _using_ it, your system is going to be totally
 broken.
 
 Sure it sucks, haven't I said that enough times, regarding pushing stuff
 that's going to break other stuff straight to ~arch?

In your eyes, is there anything we can do to improve the current situation?

Best,



Sebastian



Re: [gentoo-dev] Unused eclasses

2011-02-04 Thread Sebastian Pipping
On 02/01/11 19:57, Tomáš Chvátal wrote:
 Hello ladies,
 Following cleanup of eclasses in main tree there still are few eclasses
 that are not used at all.

I guess that applies to the main tree.
If we do care if any of them are used in an overlay, Ycarus of
gpo.zugaina.org may find an answer rather quickly.


 I would like to ask you to reply to this mail that you want them to
 survive or I will just mark them as @DEAD in 30 days and remove from the
 tree in another 30.
 
 The list of sad lonely things:
 eclipse-ext.eclass
 fortran.eclass
 games-q3mod.eclass
 mozconfig-2.eclass
 mozreconf.eclass
 php-pear.eclass
 php5_2-sapi.eclass
 poppler.eclass
 ruby-gnome2.eclass
 tla.eclass
 
 
 Cheers
 
 Your favorite treecleaning gremlin



Re: [gentoo-dev] Unused eclasses

2011-02-04 Thread Sebastian Pipping
-base:inherit
 eutils php-pear-manylibs-r1
 kolab/dev-php/horde-framework-kolab/.svn/text-base/horde-framework-kolab-3.2_rc3-r20080528.ebuild.svn-base:inherit
 eutils php-pear-manylibs-r1
 kolab/dev-php/horde-framework-kolab/horde-framework-kolab-3.2_rc3-r20080529.ebuild:inherit
 eutils php-pear-manylibs-r1
 kolab/dev-php/horde-framework-kolab/horde-framework-kolab-3.2_rc1.ebuild:inherit
 eutils php-pear-manylibs-r1
 kolab/dev-php/Horde_iCalendar/Horde_iCalendar-0.1.0.ebuild:inherit
 php-pear-r1 eutils
 kolab/dev-php/Horde_iCalendar/.svn/text-base/Horde_iCalendar-0.1.0.ebuild.svn-base:inherit
 php-pear-r1 eutils
 kolab/dev-php/Horde_Serialize/Horde_Serialize-0.0.2.ebuild:inherit
 php-pear-r1 eutils
 kolab/dev-php/Horde_Serialize/.svn/text-base/Horde_Serialize-0.0.2.ebuild.svn-base:inherit
 php-pear-r1 eutils
 kolab/dev-php/Horde_DataTree/Horde_DataTree-0.0.3.ebuild:inherit
 php-pear-r1 eutils
 kolab/dev-php/Horde_DataTree/.svn/text-base/Horde_DataTree-0.0.3.ebuild.svn-base:inherit
 php-pear-r1 eutils
 laurentb/dev-php5/phpunit/phpunit-3.5.10.ebuild:inherit php-pear-lib-r1
 lordvan/dev-php/PEAR-XML_Feed_Parser/PEAR-XML_Feed_Parser-1.0.3.ebuild:inherit
 php-pear-r1
 ohnobinki/dev-php/PEAR-Services_Yadis/PEAR-Services_Yadis-0.2.3.ebuild:inherit
 php-pear-r1
 ohnobinki/dev-php/PEAR-Services_Facebook/PEAR-Services_Facebook-0.2.8.ebuild:inherit
 php-pear-r1
 php/dev-php/PEAR-PHP_CodeSniffer/PEAR-PHP_CodeSniffer-1.3.0_rc1.ebuild:inherit
 php-pear-r1
 php/dev-php/PEAR-Net_DNS/PEAR-Net_DNS-1.0.1.ebuild:inherit php-pear-r1
 depend.php
 php/dev-php/PEAR-I18Nv2/PEAR-I18Nv2-0.11.4.ebuild:inherit php-pear-r1
 php/dev-php/PEAR-Net_Sieve/PEAR-Net_Sieve-1.2.1.ebuild:inherit php-pear-r1
 php/dev-php/PEAR-XML_Util/PEAR-XML_Util-1.1.4.ebuild:inherit php-pear-r1
 depend.php
 php-4/dev-php4/phpunit/phpunit-1.3.2.ebuild:inherit php-pear-lib-r1
 php-4/dev-php4/phpunit/.svn/text-base/phpunit-1.3.2.ebuild.svn-base:inherit
 php-pear-lib-r1
 webapps-experimental/dev-php/PEAR-Net_GeoIP/PEAR-Net_GeoIP-1.0.0_rc1.ebuild:inherit
 php-pear-r1 depend.php
 webapps-experimental/dev-php/PEAR-Net_GeoIP/.svn/text-base/PEAR-Net_GeoIP-1.0.0_rc1.ebuild.svn-base:inherit
 php-pear-r1 depend.php
 webapps-experimental/dev-php/PEAR-Structures_Graph/.svn/text-base/PEAR-Structures_Graph-1.0.2.ebuild.svn-base:inherit
 php-pear-r1
 webapps-experimental/dev-php/PEAR-Structures_Graph/PEAR-Structures_Graph-1.0.2.ebuild:inherit
 php-pear-r1
 zugaina/dev-php/PEAR-Net_Sieve/PEAR-Net_Sieve-1.2.1.ebuild:inherit
 php-pear-r1
 
 php5_2-sapi.eclass :
 dev-zero/dev-lang/php/php-5.2.12.ebuild:inherit versionator php5_2-sapi
 apache-module
 
 poppler.eclass :
 devnull/dev-libs/poppler-glib/poppler-glib-0.10.7.ebuild:inherit
 autotools poppler flag-o-matic
 kde-sunset/dev-libs/poppler-qt3/poppler-qt3-0.12.1.ebuild:inherit qt3
 poppler
 kde-sunset/dev-libs/poppler-qt3/poppler-qt3-0.12.0.ebuild:inherit qt3
 poppler
 kde-sunset/dev-libs/poppler-qt3/poppler-qt3-0.12.3.ebuild:inherit qt3
 poppler
 kde-sunset/dev-libs/poppler-qt3/poppler-qt3-0.10.7.ebuild:inherit qt3
 poppler
 kde-sunset/dev-libs/poppler-qt3/poppler-qt3-0.10.6.ebuild:inherit qt3
 poppler
 
 tla.eclass :
 sunrise/dev-util/tla-tools/tla-tools-20060509.ebuild:inherit tla
 sunrise/dev-util/tla-tools/.svn/text-base/tla-tools-20060509.ebuild.svn-base:inherit
 tla
 
 Ycarus
 
 Le 04/02/2011 15:03, Sebastian Pipping a écrit :
 On 02/01/11 19:57, Tomáš Chvátal wrote:
 Hello ladies,
 Following cleanup of eclasses in main tree there still are few eclasses
 that are not used at all.
 I guess that applies to the main tree.
 If we do care if any of them are used in an overlay, Ycarus of
 gpo.zugaina.org may find an answer rather quickly.


 I would like to ask you to reply to this mail that you want them to
 survive or I will just mark them as @DEAD in 30 days and remove from the
 tree in another 30.

 The list of sad lonely things:
 eclipse-ext.eclass
 fortran.eclass
 games-q3mod.eclass
 mozconfig-2.eclass
 mozreconf.eclass
 php-pear.eclass
 php5_2-sapi.eclass
 poppler.eclass
 ruby-gnome2.eclass
 tla.eclass


 Cheers

 Your favorite treecleaning gremlin
 




Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

2011-01-22 Thread Sebastian Pipping
On 01/22/11 13:32, Theo Chatzimichos wrote:
 Well, the distinction for unofficial/official overlays happen mostly in 
 layman 
 -L, I don't think users pay attention to our git repo list. Furthermore, I 
 got 
 at least three requests from developers to move their repo from user/ to dev/ 
 (same problem when devs retired). This distinction doesn't make any sense.

Three request over what time?  Compared to a screen height of user repos
created, maybe that's not much.



Sebastian



Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

2011-01-22 Thread Sebastian Pipping
On 01/22/11 09:55, Robin H. Johnson wrote:
 - On one hand, I would like user repositories to have a separate
   namespace, so that other users realize a given repo is NOT from a
   developer. 

Seconding that.


   - On the other side, what do we do when a user with a repo becomes a
   developer (and when they retire?)

To avoid a move, you'd have to give away distinction.  To be able to do
path-based distinction, you have to move on status updates.  It seems
that you cannot have both at the same time.



Sebastian



Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

2011-01-21 Thread Sebastian Pipping
On 01/21/11 23:15, Robin H. Johnson wrote:
 On Fri, Jan 21, 2011 at 03:47:03PM -0600, Donnie Berkholz wrote:
 Sweet, we actually got an invitation to bikeshed! Here's my contributions:

 gentoo-tree.git
 gentoo-portage-tree.git
 portage-tree.git
   (the name 'portage' derives from bsd ports, so it makes sense to keep
that connection to make it recognizable to that audience)
 Please note that I said _location_.
 I'm not so happy about putting them in in the toplevel namespace.

I see.  If the long-term goal is too have multiple packages trees, than
maybe

  tree/main.git

or

  tree/core.git

would make sense and go well with proj/, as that is not plural either:
no projs/, no trees/.  It could make

  tree/core.git
  tree/science.git
  tree/games.git
  tree/...

some day.


 You need to provide TWO names:
 1. The current tree that we will start with.
 2. The read-only graftable tree with full history (going back to the
start of Gentoo commits).

Any of these suffixes for the other one would work for me:
* past
* before
* old
* history

historical is fine, just a bit long, maybe without need to.


 As much as I like the original Portage tree, I do agree it's lead to
 confusing of the source code of the package manager vs. the ebuild tree.

Great to hear that you share this worry.

Best,



Sebastian



[gentoo-dev] genkernel 3.4.11.1 released

2011-01-20 Thread Sebastian Pipping
Hello!


This release fixes two bugs both affecting 3.4.11 (not earlier releases).


Bugs fixed
==
351906  Move application of kernel config after make mrproper as that
  deletes .config (whereas make clean does not)
351909  busybox 1.18.1: Return of mdstart as an applet (regression)


Special thanks go to Xake.

Thanks for your interest.



Sebastian



Re: [gentoo-dev] genkernel 3.4.11.1 released

2011-01-20 Thread Sebastian Pipping
On 01/20/11 21:08, Jeroen Roovers wrote:
 On Thu, 20 Jan 2011 16:00:06 +0100
 Sebastian Pipping sp...@gentoo.org wrote:
 
 This release fixes two bugs both affecting 3.4.11 (not earlier
 releases).
 
 I'm a Gentoo developer.
 I've never used genkernel for private purposes.
 So I don't see why you would send this to gentoo-dev@ and
 gentoo-dev-announce@.

I don't think a bit of extra visibility can hurt with this.

Still, I may take it off the list if another Gentoo developer seconds
that request.



Sebastian



Re: [gentoo-dev] genkernel 3.4.11.1 released

2011-01-20 Thread Sebastian Pipping
On 01/20/11 21:38, Fabian Groffen wrote:
 Like Jeroen, I don't think new package releases should be announced on
 these developer-related lists.

It's not about the package, it's about the release itself.
I don't send mails on package bumps I do.



Sebastian



Re: [gentoo-dev] genkernel 3.4.11.1 released

2011-01-20 Thread Sebastian Pipping
On 01/20/11 21:45, Rich Freeman wrote:
 On Thu, Jan 20, 2011 at 3:38 PM, Fabian Groffen grob...@gentoo.org wrote:
 Like Jeroen, I don't think new package releases should be announced on
 these developer-related lists.
 
 Tend to agree, at least in general.  If a genkernel upgrade impacted
 multiple teams/etc, such as requiring changes to install media, or the
 handbooks, etc, then I'd consider it completely fair game for the
 lists.  Likewise if some big change that will really impact the distro
 is being considered I'd consider that fair game as well.

Fair point.

I'll keep posting to Planet Gentoo.  How about gentoo-dev-announce?


 That said, there are some nice genkernel changes being made and I for
 one appreciate them (even though I don't yet run it - the mdadm
 inclusion will probably push me over the edge)!

If you get the chance please try genkernel-9 (five nines) exposing
the experimental branch.  That may save both of us the trouble to fix
things post release.

Best,



Sebastian



Re: [gentoo-dev] genkernel 3.4.11.1 released

2011-01-20 Thread Sebastian Pipping
On 01/20/11 21:55, Fabian Groffen wrote:
 Unless if you are on some git repo, we have commit mails which can serve
 this purpose very well.

I am on a git repo, and a commit list serves a different purpose: low
level tracking of changes.



Sebastian



Re: [gentoo-dev] genkernel 3.4.11.1 released

2011-01-20 Thread Sebastian Pipping
On 01/20/11 22:06, Jeroen Roovers wrote:
 Version bumps have no place on the dev-announce list /unless/ they
 impact developers' work directly.

Fine.


 (and not because you want to celebrate the glory of another version release).

I'm not sure if I'm just interpreting things, but I wish you would speak
to me in a way, where I would not have to wonder on each mail, if you're
just trying to piss me off.  Thanks.



Sebastian



Re: [gentoo-dev] Tomoyo tools need attention

2011-01-17 Thread Sebastian Pipping
Bumped to 2.3.0-p20100820.



Sebastian



[gentoo-dev] genkernel 3.4.11 released

2011-01-16 Thread Sebastian Pipping
Hello!


I have just released genkernel 3.4.11 to the testing tree.

From a high level point of view this release brings:
- Slightly faster startup
- Updated versions of busybox, LVM, e2fsprogs/blkid
- A few new features, e.g. GnuPG support
- A bunch of bug fixes (see below)

Below you can find details on the changes since 3.4.10.908.

Besides the people contributing bug reports special thanks go to:
- Amadeusz Zolnowski (LVM update)
- Christian Giessner (UUID crypt_root)
- dacook (GnuPG 1.x support)
- Denis Kaganovich (Busybox patch porting)
- devsk (Multi-device patch)
- Fabio Erculiani (Slowusb fixes)
- Kai Dietrich (Symlink analysis)
- Kolbjorn Barmen (Arithmetic fix)

Please open bugs for any issues you run into.


New features

217959  Add GnuPG 1.x support
315467  Add support for UUID to crypt_root
303529  Add minimal btrfs support
267383  Add virtio support by updating LVM
244651  Run make firmware_install if CONFIG_FIRMWARE_IN_KERNEL != y

Component updates
=
291822  Update e2fsprogs/blkid to 1.41.14
331971  Update busybox to 1.18.1
255196  Update LVM to 2.02.74

Bug fixes
=
351047  Do not sleep after vgscan
271528  Handle missing kernel .config better
323317  Improve slowusb handling
246370  Check return codes of cpio
307855  Create /bin/vg* symlinks when called as /linuxrc, too
303531  Pick first device when several devices are matching real_root
347213  Fix warning cannot remove `/var/cache/genkernel/src'
326593  Allow configuring the list of busybox applets
339789  Fix arithmetic bug in defaults/initrd.scripts


Thanks for your interest.



Sebastian



  1   2   3   4   5   >