[gentoo-dev] Package up for grabs: www-client/httrack
Hi! Just a quick note that I have just dropped maintainership of package… www-client/httrack …, about 8 years after my first commit on the package and after bumping to 3.49.5 and asking for its stabilization due to a security fix about a minute ago or two, as my last action on the package. I have dropped the package now because of upstream behavior in recent years; issues… https://github.com/xroche/httrack/issues/243 https://github.com/xroche/httrack/issues/244 https://github.com/xroche/httrack/issues/245 https://github.com/xroche/httrack/issues/247 …would be the places to look for details of their and my actions, if curious. Regarding open bugs about www-client/httrack in Gentoo: - https://bugs.gentoo.org/917589 and https://bugs.gentoo.org/923034 and https://bugs.gentoo.org/923035 are all about stabilization, keywording, a fixed vulnerability - https://bugs.gentoo.org/768186 is unconfirmed (i.e. not reproducible) and of unclear importance Have a nice day Sebastian
Re: [gentoo-dev] Last rites: www-client/chromium-bin
On 04.05.23 20:59, Maciej Barć wrote: R.i.p. to a lot od desktop users on non-state-of-the-art HW. Building Chromium inside a cloud VM may be an option for some users with older hardware. When using e.g. https://github.com/hartwork/binary-gentoo for that, the VM doesn't even have to run Gentoo.
Re: [gentoo-dev] About EGO_SUM
On 08.06.22 22:42, Robin H. Johnson wrote: EGO_SUM vs dependency tarballs: [..] - EGO_SUM is verifiable/reproducible from Upstream Go systems Let's be explicit, there is a _security_ threat here: as a user of an ebuild, dependency tarballs now take effort in manual review just to confirm that the content full matches its supposed list of ingredients. They are the perfect place to hide malicious code in plain sight. Now with dependency tarballs, there is a new layer that by design will likely be chronically under-audited. It gives me shivers, frankly. Previously with a manifest and upstream-only URLs, only upstream can add malicious code, not downstream in Gentoo. Best Sebastian
[gentoo-dev] Package up for grabs: >=app-emulation/docker-compose-2.0.0 (1.x.x was Python, 2.0.0 is Go)
Hi! docker-compose upstream has apparently re-written docker-compose in Golang from scratch. While I'm happy to keep maintaining the current python-based =2.0.0 in Gentoo. Thanks in advance! Best Sebastian
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
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
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
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
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
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)
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
# 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?
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?
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?
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
Stefan, thanks for your work on Gentoo! All the best Sebastian
[gentoo-dev] Merge 7 Fedora wallpapers packages to single one with slots?
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
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
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
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
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
# 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"
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"
-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"
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/
-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
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
-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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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?
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}
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
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
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?
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?
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?
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
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
# 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
# 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
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
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)
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
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
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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?
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?
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?
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?
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
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
-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)
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)
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)
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
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
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
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
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
