Re: [gentoo-dev] [PATCH 1/2] edo.eclass: enhace edob for usage with nosiy commands
Hello,
08.05.2024 19:15:52 Florian Schmaus :
[..]
> # @FUNCTION: edob
> -# @USAGE: [...]
> +# @USAGE: [-m ] [-l ] [...]
^^!
[..]
> -l is provided, then is
[..]
> edob() {
[..]
> + while true; do
> + case "${1}" in
> + -m|-n)
^^! ITYM '-l' here
> + [[ $# -lt 2 ]] && die "Must provide an argument to ${1}"
> + case "${1}" in
> + -m)
> + message="${2}"
> + ;;
> + -n)
^^! ITYM '-l' here
> + log="${2}"
>
[..]
Fix yer option character ;)
-dnh
[gentoo-dev] Last rites: media-libs/ilmbase
# Bernd Waibel (2023-01-28) # Possible security issues, obsolete. Use OpenEXR-3 / Imath instead. # No revdeps and consumers left in ::gentoo # Removal in 30 days. Bug #892375 media-libs/ilmbase -BEGIN PGP SIGNATURE- iQGTBAEBCgB9FiEExIg3+Emk70nqAQ2ybb4K1Uo7McYFAmJOvDBfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM0 ODgzN0Y4NDlBNEVGNDlFQTAxMERCMjZEQkUwQUQ1NEEzQjMxQzYACgkQbb4K1Uo7 McbyjggA40un5MrP8DyyVmJXRUTSrxNHbCFck/7vCRHuHfync2bCFYk3JqvfFcu3 D5ms7sH+3ZBxGgUtCG7LwWOQZ89pSkQFXPCu+4Pb0LlVgz6x+lFyGNXdT1g4RyXu 1TzqQlok5gOmlxJ+aK+C6CmzN7e+0Mfe8lGHVLfcukzjlCglochavIXuiG7KNiTB 4rUSeVLJ6OaLkeqYQ4EYrhU8gkiA8nsH4TqXWxmB6cFhfy0e1wOGlkK31Q9jmmZp R4qpRF2QwH7CAKlIW9TT8fZ0kw06UVoGosm8lxMA2wQ2WycTnPp7kbRaTvdENEqb UggCF7hh2g7Y6LSh33f2l6TNlxH0tA== =G4KG -END PGP SIGNATURE-
[gentoo-dev] [PATCH v2] distutils-r1.eclass: support nonfatal in test
From: Alexey Sokolov
Rationale:
src_test() {
virtx distutils-r1_src_test
}
If the test fails with "die", Xvfb keeps running forever; but it's
cleaned up correctly with die -n
Signed-off-by: Alexey Sokolov
---
eclass/distutils-r1.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 371d52bcb7e..8896768d3ce 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: distutils-r1.eclass
@@ -1559,7 +1559,7 @@ distutils-r1_python_test() {
esac
if [[ ${?} -ne 0 ]]; then
- die "Tests failed with ${EPYTHON}"
+ die -n "Tests failed with ${EPYTHON}"
fi
}
--
2.38.2
[gentoo-dev] [PATCH] distutils-r1.eclass: support nonfatal in test
From: Alexey Sokolov
Signed-off-by: Alexey Sokolov
---
eclass/distutils-r1.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 371d52bcb7e..8896768d3ce 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: distutils-r1.eclass
@@ -1559,7 +1559,7 @@ distutils-r1_python_test() {
esac
if [[ ${?} -ne 0 ]]; then
- die "Tests failed with ${EPYTHON}"
+ die -n "Tests failed with ${EPYTHON}"
fi
}
--
2.38.2
Re: [gentoo-dev] Up for grabs: dev-python/pyside2
Am 13.08.2022 11:51 schrieb Andrew Ammerlaan: On 13/08/2022 11:10, waebbl-gen...@posteo.net wrote: Thanks Andrew for taking care of these packages. Like I said, I'd be happy to comaintain the packages and keep an additional two eyes on them. Great! Would you like me to add you to the metadata.xml files so you'll get CC'ed on the bugs? Best regards, Andrew You're welcome to do so. Don't forget that I'm a proxy-maintainer. Regards, Bernd
Re: [gentoo-dev] Up for grabs: dev-python/pyside2
On Fri, 12 Aug 2022 17:28:49 +0200 Andrew Ammerlaan wrote: > On 29/07/2022 13:06, Ionen Wolkens wrote: > > On Fri, Jul 29, 2022 at 10:30:20AM +, waebbl-gen...@posteo.net wrote: > >> On Sun, 17 Jul 2022 23:11:08 +0100 > >> Sam James wrote: > >> > >>> Up for grabs because of inactivity. > >>> > >>> dev-python/pyside2 has several open bugs and a version bump pending. > >>> > >>> Needs some real love to tidy it up. > >>> > >>> Best, > >>> sam > >> > >> Wouldn't it be applicable to put these packages under the umbrella of > >> the Gentoo Qt project? > > > > It still need someone to maintain it either way, qt@ is rather small > > and Qt6 is likely to use up people's time already. Being m-n at least > > make its current state clear (up to qt@ though). > > > >> They're developed, published and hosted by the The Qt Company (in > >> contrast for example to PyQt5 or QtPy) and are only python > >> bindings for the Qt framework, although they're currently distributed > >> in a separate tarball and not with the Qt tarball. > > > > On a side-note I'll be adding PyQt6 to the tree once I can[1], but I > > don't use pyside for anything and probably won't be looking at pyside6. > > > > [1] https://github.com/gentoo/gentoo/pull/26504 > > I've added myself as the maintainer of shiboken2 and pyside2(-tools). I > also added shiboken6 and pyside6(-tools) (masked for testing). > Unfortunately the latter is stuck on python3_10 only at the moment, > adding python3_11 to this is a whole new can of worms. > > Help with these packages is most welcome. They are notoriously difficult > and fragile. > > Best regards, > Andrew > Thanks Andrew for taking care of these packages. Like I said, I'd be happy to comaintain the packages and keep an additional two eyes on them. In my draft[1] for pyside6, I've also found the python 3.11 incompatibility and removed it for further investigation. However, what I noticed, is, that upstream only has compatibility for python3 up to 3.10. Closing my draft, now that the package has been merged into the tree. [1] https://github.com/gentoo/gentoo/pull/26782 Best, Bernd
Re: [gentoo-dev] USE=ninja to compile by ninja, otherwise by make
On Sat, 30 Jul 2022 00:38:54 +0800 Fabulous Zhang Zheng wrote: > Dear everyone, > > > While gentoo-devhelp is a better place for questions, it's been inactive > for years so I sent an email here. Apologies if this is solely for gentoo > developers. There's #gentoo-dev-help > > After trying to read cmake.eclass source code, I think separately denoting > ninja/make in src_compile and src_install might be possible. But > cmake_build still automatically detects the build type so I am confused. > Take a look at CMAKE_MAKEFILE_GENERATOR variable used in cmake.eclass. You want to change this from the default to emake if you want to use make instead of ninja.
Re: [gentoo-dev] Up for grabs: dev-python/pyside2
On Fri, 29 Jul 2022 07:06:06 -0400 Ionen Wolkens wrote: > On Fri, Jul 29, 2022 at 10:30:20AM +, waebbl-gen...@posteo.net wrote: > > On Sun, 17 Jul 2022 23:11:08 +0100 > > Sam James wrote: > > > > > Up for grabs because of inactivity. > > > > > > dev-python/pyside2 has several open bugs and a version bump pending. > > > > > > Needs some real love to tidy it up. > > > > > > Best, > > > sam > > > > Wouldn't it be applicable to put these packages under the umbrella of > > the Gentoo Qt project? > > It still need someone to maintain it either way, qt@ is rather small > and Qt6 is likely to use up people's time already. Being m-n at least > make its current state clear (up to qt@ though). > I can think of co-maintaining the packages, but it exceeds my resources to being primary maintainer. > > They're developed, published and hosted by the The Qt Company (in > > contrast for example to PyQt5 or QtPy) and are only python > > bindings for the Qt framework, although they're currently distributed > > in a separate tarball and not with the Qt tarball. > > On a side-note I'll be adding PyQt6 to the tree once I can[1], but I > don't use pyside for anything and probably won't be looking at pyside6. > I'm slowly working towards shiboken6 / pyside6. Pyside is needed for the Qt6 move of FreeCAD, at it's current state at least. There are discussion on completely moving to pybind11 instead of pyside, but that's not yet decided. So I will probably need pyside6 for the sake of FreeCAD. > [1] https://github.com/gentoo/gentoo/pull/26504 pgpAfI8Ibfe_d.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Up for grabs: dev-python/pyside2
On Sun, 17 Jul 2022 23:11:08 +0100 Sam James wrote: > Up for grabs because of inactivity. > > dev-python/pyside2 has several open bugs and a version bump pending. > > Needs some real love to tidy it up. > > Best, > sam Wouldn't it be applicable to put these packages under the umbrella of the Gentoo Qt project? They're developed, published and hosted by the The Qt Company (in contrast for example to PyQt5 or QtPy) and are only python bindings for the Qt framework, although they're currently distributed in a separate tarball and not with the Qt tarball. Resending due to wrong sender being used. Regards, Bernd pgpN6407DJvvo.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] proposal
On Mon, 4 Jul 2022 22:49:25 -0400 Ionen Wolkens wrote: On Mon, Jul 04, 2022 at 04:19:12PM +0200, Florian Schmaus wrote: > I'd like to propose a new metadata XML element for packages: > > > > Maintainers can signal to other developers (and of course contributors > in general) that they are happy with others to make changes to the > ebuilds without prior consultation of the maintainer. > > Of course, this is not a free ticket to always make changes to packages > that you do not maintain without prior consultation of the maintainer. I > would expect people to use their common sense to decide if a change may > require maintainer attention or not. In general, it is always a good > idea to communicate changes in every case. > > The absence of the flag does not automatically allow the conclusion that > the maintainer is opposed to non-maintainer commits. It just means that > the maintainer's stance is not known. I do not believe that we need a > flag, but if the need arises, we > could always consider adding one. Although, in my experience, people > mostly like to communicate the "non-maintainer commits welcome" policy > with others. > > WDYT? Personally I think something per-maintainer rather than per package would be simpler, and allow to say more as needed. Think like devaway instructions, but something more permanent and not for being away, e.g. "feel free to touch my packages except this big important one, and or do or do not do this to them" I think it would be more efficient if we use a flag on a per-maintainer basis. But it adds extra overhead, if the maintainer doesn't want some special packages to be touched, or if special cases, like bumps need to be avoided. We could add a central file, something like the metadata/AUTHORS file with this information. Possibly in a structured format like xml or json to make it machine readable as well and the information can be extracted and shown e.g. on the wiki or p.g.o site. Something like the devaway instructions could lock out proxy maintainers, which don't have access to the Gentoo infrastructure. > > - Flow > -BEGIN PGP SIGNATURE- iQGTBAEBCgB9FiEExIg3+Emk70nqAQ2ybb4K1Uo7McYFAmJOvDBfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM0 ODgzN0Y4NDlBNEVGNDlFQTAxMERCMjZEQkUwQUQ1NEEzQjMxQzYACgkQbb4K1Uo7 McbyjggA40un5MrP8DyyVmJXRUTSrxNHbCFck/7vCRHuHfync2bCFYk3JqvfFcu3 D5ms7sH+3ZBxGgUtCG7LwWOQZ89pSkQFXPCu+4Pb0LlVgz6x+lFyGNXdT1g4RyXu 1TzqQlok5gOmlxJ+aK+C6CmzN7e+0Mfe8lGHVLfcukzjlCglochavIXuiG7KNiTB 4rUSeVLJ6OaLkeqYQ4EYrhU8gkiA8nsH4TqXWxmB6cFhfy0e1wOGlkK31Q9jmmZp R4qpRF2QwH7CAKlIW9TT8fZ0kw06UVoGosm8lxMA2wQ2WycTnPp7kbRaTvdENEqb UggCF7hh2g7Y6LSh33f2l6TNlxH0tA== =G4KG -END PGP SIGNATURE-
[gentoo-dev] Last rites: dev-python/pyilmbase: 2.5.7{,-r1}
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Bernd Waibel (2022-04-07) # No consumers left. Superseded by dev-libs/imath[python] # Removal in 30 days. dev-python/pyilmbase -BEGIN PGP SIGNATURE- iQGTBAEBCgB9FiEExIg3+Emk70nqAQ2ybb4K1Uo7McYFAmJOvDBfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM0 ODgzN0Y4NDlBNEVGNDlFQTAxMERCMjZEQkUwQUQ1NEEzQjMxQzYACgkQbb4K1Uo7 McbyjggA40un5MrP8DyyVmJXRUTSrxNHbCFck/7vCRHuHfync2bCFYk3JqvfFcu3 D5ms7sH+3ZBxGgUtCG7LwWOQZ89pSkQFXPCu+4Pb0LlVgz6x+lFyGNXdT1g4RyXu 1TzqQlok5gOmlxJ+aK+C6CmzN7e+0Mfe8lGHVLfcukzjlCglochavIXuiG7KNiTB 4rUSeVLJ6OaLkeqYQ4EYrhU8gkiA8nsH4TqXWxmB6cFhfy0e1wOGlkK31Q9jmmZp R4qpRF2QwH7CAKlIW9TT8fZ0kw06UVoGosm8lxMA2wQ2WycTnPp7kbRaTvdENEqb UggCF7hh2g7Y6LSh33f2l6TNlxH0tA== =G4KG -END PGP SIGNATURE-
Re: [gentoo-dev] Packages up for grabs: dev-db/libzdb, media-libs/libdvbpsi, net-mail/dbmail, x11-wm/treewm
hi. just pointing out that I do intend to maintain them aain when I (hopefully soon) have more time again. Regards On 2021-01-20 19:27, Michał Górny wrote: Hi, The following packages are up for grabs due to their current maintainer being unresponsive: [ ] acct-group/dbmail [ ] acct-user/dbmail [Bv] dev-db/libzdb [ v] media-libs/libdvbpsi [Bv] net-mail/dbmail [ ] x11-wm/treewm B - bugs reported v - version bump pending
[gentoo-dev] [PATCH 2/2] virtualx.eclass: don't skip xvfb dependency on Prefix
From: Alexey Sokolov
Closes: https://bugs.gentoo.org/730190
Signed-off-by: Alexey Sokolov
---
eclass/virtualx.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
index 6aba6bf488d..93b9751cfa6 100644
--- a/eclass/virtualx.eclass
+++ b/eclass/virtualx.eclass
@@ -40,8 +40,8 @@ esac
# complicated dep is needed.
# You can specify the variable BEFORE inherit to add more dependencies.
VIRTUALX_DEPEND="${VIRTUALX_DEPEND}
- !prefix? ( x11-base/xorg-server[xvfb] )
x11-apps/xhost
+ x11-base/xorg-server[xvfb]
"
# @ECLASS-VARIABLE: VIRTUALX_COMMAND
--
2.26.2
[gentoo-dev] [PATCH 1/2] profiles: prefix: mask USE=elogind in x11-base/xorg-server
From: Alexey Sokolov Bug: https://bugs.gentoo.org/730190 Signed-off-by: Alexey Sokolov --- profiles/features/prefix/package.use.mask | 4 1 file changed, 4 insertions(+) diff --git a/profiles/features/prefix/package.use.mask b/profiles/features/prefix/package.use.mask index 07d83215aa7..daa75a307db 100644 --- a/profiles/features/prefix/package.use.mask +++ b/profiles/features/prefix/package.use.mask @@ -1,6 +1,10 @@ # Copyright 1999-2020 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 +# Alexey Sokolov (2020-10-15) +# Requires PAM. +x11-base/xorg-server elogind + # Benda Xu (2019-08-20) # avoid gnome-extra/gnome-user-share, which depends on systemd. gnome-base/gnome-extra-apps share -- 2.26.2
[gentoo-dev] [PATCH 0/2] Xvfb in test dependencies in Prefix
From: Alexey Sokolov I'm running a prefix but tests of various packages are failing in virtx command. I discovered that this is because virtualx doesn't depend on xvfb in prefix. But after installing xorg-server[xvfb,-elogind] tests pass. elogind flag had to be disabled otherwise it brings pam as dependency. So, attached are patches to prefix profile to disable elogind for xorg-server, and to virtualx eclass to depend on it even in prefix. Alexey Sokolov (2): profiles: prefix: mask USE=elogind in x11-base/xorg-server virtualx.eclass: don't skip xvfb dependency on Prefix eclass/virtualx.eclass| 2 +- profiles/features/prefix/package.use.mask | 4 2 files changed, 5 insertions(+), 1 deletion(-) -- 2.26.2
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
Am 23.05.2020 um 22:20 schrieb Zac Medico: On 5/23/20 1:02 PM, magic-gen...@damage.devloop.de wrote: I rewrote e-file in python by using the portage API [1]. But loading the API slows down the whole script. Is there any way to speed up my implementation? Have I done something fundamentally wrong? When I patched the portage API out of your script, I saw the run time drop from 4.2 seconds to 3.2 seconds with this patch: ... Are your results worse than mine? Nope, but maybe the phrase "loading the API" was misleading. I'd like to replace it with: "But using the API slows down the whole script.". This means it is much slower to get the additional informations by portage API than just grep'ing throught the ebuild files. If I run the python e-file on my machine it takes 3.2 seconds for a single file. The bash e-file show the same result within a second or so. regards Daniel
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
Hi, Am 23.05.2020 um 22:08 schrieb Michał Górny: On Sat, 2020-05-23 at 22:02 +0200, magic-gen...@damage.devloop.de wrote: I rewrote e-file in python by using the portage API [1]. But loading the API slows down the whole script. Is there any way to speed up my implementation? Have I done something fundamentally wrong? My only suggestion would be to use pkgcore instead of portage. It is compatible at configuration/data format level, so your script should work out of the box for Portage users. Which makes me feel I did something fundamentally wrong :) I used "portage.db['/']['vartree'].dbapi" and "portage.db['/']['porttree'].dbapi" to get the API for installed (vartree) and available (porttree) packages. This is not available ing pkgcore. I haven't found a quick guide on how to use pkgcore but I will have a further look. Thanks Daniel
[gentoo-dev] speeding up usage of portage in e-file / portage file list
Hi, the current e-file tool of app-portage/pfl is written in bash. e-file is a CLI tool which searches portagefilelist.de for a given file and list additional informations based on the local portage. Latter is done by grep'ing through the ebuild files which is fast but IMHO not very smart. I rewrote e-file in python by using the portage API [1]. But loading the API slows down the whole script. Is there any way to speed up my implementation? Have I done something fundamentally wrong? Thanks in advance Daniel [1] https://github.com/portagefilelist/client/blob/e-file-python/bin/e-file
Bouncing messages from gentoo-dev@lists.gentoo.org
Some messages to you could not be delivered. If you're seeing this message it means things are back to normal, and it's merely for your information. Here is the list of the bounced messages: - 89057
Re: [gentoo-dev] Packages up for grabs: Enlightenment
On 2018-04-16 17:28, Michał Górny wrote: Hello, everyone. The following packages are up for grabs due to the Enlightenment project being disbanded: app-doc/edox-data dev-libs/efl dev-python/python-efl media-libs/elementary media-libs/imlib2 media-plugins/emotion_generic_players media-plugins/evas_generic_loaders media-plugins/imlib2_loaders x11-misc/e16keyedit x11-misc/e16menuedit2 x11-plugins/epplets x11-terms/terminology x11-themes/ethemes x11-wm/enlightenment (+ enlightenment.eclass) The packages have a large number of bugs open. They are outdated, both in terms of releases and EAPI. The eclass needs either a major overhaul, or preferably removal as obsolete boilerplate. On the bright side, there is a certain interest in Enlightenment (including open PRs) from proxied maintainers, so the packages shouldn't have much trouble finding a new maintainer. Hi. As stated before I don't mind taking (some of the) e17 stuff - i have efl and enlightenment in my dev overlay and been using it for several weeks now. The question is .. who wants the e16 stuff / how would maintainership work for x11-wm/enlightenment which is both e16 and e17 ? Regards signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: adding sbin directories to PATH for all users
On Wed, Nov 25, 2015 at 07:51:55PM +0100, Ulrich Mueller wrote: > > On Wed, 25 Nov 2015, William Hubbs wrote: >> From what I've read, the traditional difference between bin and sbin >> was that sbin means static-bin and everything stored in there was to >> be able to come up without libraries. > > Source/reference for this? Some of us are old enough to remember when it happened, sonny. It was Sun's idea. Disks were expensive, so they wanted as much of the OS to be mountable read-only via NFS as possible (remember diskless workstations? no, you probably don't), so they moved /bin and /lib to /usr and replaced them with symlinks. /sbin was created to hold the necessary binaries to get /usr mounted via NFS at boot. They had to be statically-linked because all the shared libraries were in /usr-- hence the "s" in "sbin". If you really want a reference, here you go (page 7): http://chiclassiccomp.org/docs/content/computing/Sun/800-1731-10_SunOS4.0ChangeNotes9May88.pdf >> As mgorny was talking about earlier, a good chunk of what is in sbin >> *can* be run by normal users. > > Then it shouldn't be in sbin, in the first place. That's a separate > discussion though. Bollocks. The whole "/sbin is for admins" meme is an after-the-fact fabrication by those too young to remember the original purpose for it. (Unfortunately, that included people at Sun.) Now, get off my lawn.
Re: [gentoo-dev] Manifest signing
Hi, Am 02.11.2011 17:11, schrieb Robin H. Johnson: On Wed, Nov 02, 2011 at 01:03:21PM +0100, enno+gen...@groeper-berlin.de wrote: I followed the threads about manifest signing with interest and even had a look at the manifest signing guide [4]. Sounds nice at first view. But, please correct me, if I'm wrong. I didn't find a place where these signatures are verified. Is manifest signing for the infrastructure team, enabling them to verify the author of a commit (see GLEP57 [1])? Wouldn't this be obsoleted by commit signing if the move to git is done ([2])? Developer signing is radically altered in the face of git yes, that's one of the reasons not much has happened there. But the other larger reason is that developer signing pales in importance to the signature chain between infra-user. If developer signing works, it could act as a trust chain between (developer-)infra-user. And it could work with good old default emerge --sync, not only with emerge-webrsync and snapshots. If its senseless to do anything in this area as long as the move to git isn't done, there is no need to wine about unsigned manifests. At least if there isn't anyone checking developer signatures at the moment. If it is (also) for the users, why is there no code for it in portage anymore [3]? Hmm, I hadn't see that removal, but it makes sense unless the entire tree is developer-signed, which isn't likely to happen soon. I don't agree here. Of course the implementation shouldn't stop the user from installing an unsigned package at the moment. But it could give a warning instead and ask the user what to do. In this way developers are encouraged to sign their packages (to make the warning go away) and users get the ability to check the signatures, that already exist. Key problem here is the Gentoo keyring (how to ensure it didn't get manipulated). Okay why is clear. Obviously nobody was maintaining it... The code worked when I used it... I didn't check it. All I have are the commit messages and the feature-removal of the portage team. I thought about signing the manifests of my overlay. But this is senseless, if there is no automatic check. I can't think of any user verifying manifest signatures by hand. There's a chicken egg problem with most signing. You need to communicate the valid keys out of band from the actual repo. Maybe the layman data is a good place for that, but until such a location is figured out, you have zero security gain (if the 'correct' keys are only listed in a file in the repo, any attacker just replaces that when he puts his other content in). Of course. But security is always worth thinking about it. First step: What are the possibilities the check the signatures? FAIL. In my case some (most?) of the users of my overlay should know my GPG key already. The web of trust works here. The drawback for possible other users would be a false sense of security. How does infrastructure team check, if a GPG key belongs to a developer? The Manifest signing guide [4] simply says Upload the key to a keyserver. Everbody can upload a key to the public keyservers. An attacker, able to modify a signed Manifest, could simply create a new key on the developers name and use it to sign the modified manifest. Therefore it must be clear which key really belongs to a dev. Developers specify in their LDAP data what keys are theirs, and this gets exported here, amongst other places: http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml Thanks for the enlightenment. But I doubt, if this should be the way to go (see below). There was a prototype keyserver at one point as well, and I can generate new keyrings if needed based on the LDAP data. This could be okay for a first creation. Later I would prefer something like Debian does: http://keyring.debian.org/replacing_keys.html That way you would decouple the LDAP and the keyring and trust only the data, that is already in the keyring (somebody whose key is already in the keyring signing the request for a new key). See also: http://keyring.debian.org/ Perhaps the prototype keyserver already did something like that. Furthermore the Tree-Signing-GLEPs [5] seem to be incomplete. This looks like the right place to continue work on Tree Signing. Those were the draft copies, which were finalized into GLEP 57..61. You are correct that there are two unfinished GLEPs in that directory: 02-developer-process-security 03-gnupg-policies-and-handling Of those, 03 can probably be written at this point. 02 is going to change radically when git comes into play. I had those 2 in mind, yes. Regards, Enno signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Manifest signing
Hello, Am 29.09.2011 17:02, schrieb Anthony G. Basile: Hi everyone, The issue of Manifest signing came up in #gentoo-hardened channel ... again. Its clearly a security issue and yet many manifests in the tree are still not signed. Is there any chance that we can agree to reject unsigned manifests? Possibly a question for the Council to adjudicate? I followed the threads about manifest signing with interest and even had a look at the manifest signing guide [4]. Sounds nice at first view. But, please correct me, if I'm wrong. I didn't find a place where these signatures are verified. Is manifest signing for the infrastructure team, enabling them to verify the author of a commit (see GLEP57 [1])? Wouldn't this be obsoleted by commit signing if the move to git is done ([2])? If it is (also) for the users, why is there no code for it in portage anymore [3]? Okay why is clear. Obviously nobody was maintaining it... I thought about signing the manifests of my overlay. But this is senseless, if there is no automatic check. I can't think of any user verifying manifest signatures by hand. To me it looks like there are repeating complaints about missing signatures, but I don't see any verification methods for existing manifest signatures. At the moment there are 10608 of 15085 manifests signed in my portage tree. But I can't check them, because I don't have the public keys and if I fetch them from a public keyserver, I still don't know, if they really belong to the corresponding Gentoo developers. Is there some kind of Gentoo Keyring I don't know of? How does infrastructure team check, if a GPG key belongs to a developer? The Manifest signing guide [4] simply says Upload the key to a keyserver. Everbody can upload a key to the public keyservers. An attacker, able to modify a signed Manifest, could simply create a new key on the developers name and use it to sign the modified manifest. Therefore it must be clear which key really belongs to a dev. Furthermore the Tree-Signing-GLEPs [5] seem to be incomplete. This looks like the right place to continue work on Tree Signing. Regards, Enno [1] http://www.gentoo.org/proj/en/glep/glep-0057.html [2] http://archives.gentoo.org/gentoo-dev/msg_91813ec042831af2fd688e7ecfae4943.xml [3] http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=4c16649d121dca977b3c569f03c5d1b194b635d4 [4] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=6 [5] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/users/robbat2/tree-signing-gleps/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [RFC] Store [,R,P]DEPEND with unevaluated use conditionals in vdb
On Sat, 2010-04-24 at 20:00 +0200, Sebastian Luther wrote: Am 24.04.2010 13:32, schrieb Gentoo: On Fri, 2010-04-23 at 22:31 -0700, Zac Medico wrote: On 04/23/2010 05:43 AM, Sebastian Luther wrote: Someone might come up with some logic to detect new use flags in *DEPEND, but this looks like a hack to me. It doesn't seem too bad to me. It doesn't work, because it's not guaranteed, that only use flag from IUSE are used in use conditionals. That means you can't do it reliably without the unevaluated value. The clean solution is to store the unevaluated string. Do you want to do this for $PKGDIR/Packages as well? We've always evaluated USE conditionals in there since we were copying the behavior of the older genpkgindex tool and that's how it behaved. We should do it there too for the same reason as for storing it in the vdb. Never heard of that tool, but anyone handling portage's binpkgs should use the portage api which provides an easy way to evaluate the use conditionals. Also note that if we want to rely on having unevaluated strings then we'll probably want to try to get alternative package managers to behave the same way (maybe specify it in PMS). The vdb isn't covered by PMS. Paludis stores the unevaluated value, pkgcore stores the evaluated value. Question is: Does anyone have a good argument to not use the old behavior again? space and ease of parsing for minimal pkg mergers. Minimal mergers have to handle it anyway, since this has been the old behavior until some weeks ago. We actually had flattened R/DEP's before for a while. Then they got removed then noew added back. For portage API users, the difference is a (rather long) one liner. What do you mean with space? The vdb is getting rather bloated. Anything that cuts down excess waste there for the masses I tend to be in favor of. Sebastian [1] commit e6be6590e99522f9be69e2af8eff87919d9bf31f on 2010-02-14 I think we'll have to handle the evaluated strings anyway since this code has already been released and stabilized in portage-2.1.8.x, and USE conditionals have been evaluate in $PKGDIR/Packages for even longer. Because of this, I see little or no benefit in changing it back to unevaluated strings at this point. Good. Thanks for not reverting back to those old behaviors. And the new use case isn't of any relevance? As a compromise: What about storing both values? That just add bloat back. I think the real problem here in the example you listed in the first email, is that ebuild authors should be bumping a package when adding/removing functionaliy provided by IUSE. Infact it's even a policy part of our own ebuild quizzes that they should bump the pkg (eclasses excluded). -- Gentoo so...@gentoo.org Gentoo Linux
Re: [gentoo-dev] gentoo-dev-announce list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seemant Kulleen wrote: FWIW, I like this idea a lot. A lot of devs would rather just read the good stuff happening in -dev and discard the other 85%. I vote yes. Thanks, Seemant +1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGe5VmdXakryvz8lgRApFRAJ4y1oCPSdwqYOr6XKJ/YEQQ3Hpo7QCfS5Yb vlEwq4uGXS7u5/s3/cP6s6I= =Hck1 -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New developer: Ali Polatel (hawking)
welcome here too ;) i assume Petteri means to apply sed s/stupid/student/ ? ;) unfortunately i didn't play chess in way too long so i now suck :( -- Thomas Raschbacher http://www.lordvan.com quote who=Joe Peterson Welcome Ali! And no, I don't think I will challenge you in chess any time soon. :) -Joe Petteri Räty wrote: It's my usual pleasure to introduce to you Ali hawking Polatel who will be joining us to help with the netmon stuff. Ali hails us from Turkey. He is currently a physics engineering stupid in the Istanbul Technical University and a real wizard in chess. He is the National Master to be more exact. Please give him the usual warm welcome and try to beat him in online chess. Regards, Petteri -- Gentoo/Recruiters lead -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] Packagestabilization detection
I wrote a stabilization detector (in Python) that is able to realize when a package was installed as unstable version but became stable through a more recent ebuild. There is a project website [1] and a corresponding bug-report [2] for enhancement. Nice. I've been looking for something like this for a while. I obviously wasn't looking hard enough. I'm writing to you, because I think that just an external program checking for such stabilizations is not good enough and it would be even better to let Portage itself handle this after a sync for example. Now I'm interested in what you think about it. I for one would like to see this kind of functionality added to portage. I regularly use a mixture of stable and unstable packages on the same machine and it can become a real pain working out which entries are still required in package.keywords. I would like an option to automatically remove (or comment) lines like ~cat/pkg-1.2 from package.keywords and package.unmask also - if a feature request isn't too cheeky. :-) NW -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Modular X and hardened
On Sat, 13 May 2006 23:04:10 -0700
Donnie Berkholz [EMAIL PROTECTED] wrote:
Kevin F. Quinn (Gentoo) wrote:
Oh, OK, let's argue semantics. It's suggested by a hardened user on a
bug the hardened team is CC'd on, but the team didn't say anything was
wrong with the change.
That's because for the moment we don't have a better suggestion; we
can't say don't do it in this case until we have a solution. Our
silence doesn't mean we like the solution; it means we haven't got
anything better to suggest for now.
With regards to Duncan's (non-hardened) problem, adding:
filter-ldflags -Wl,-z,now
to x-modular.eclass as he suggests should be fine; his issue is
different to that with the hardened compiler in as much as he has
added the '-Wl,-z,now' to LDFLAGS as advised by the QA message and
the above filter will just remove it again; whereas to deal with
the hardened compiler we need to reliably add a flag to all the
relevant link commands (the bit that takes the effort is working
out which are relevant).
Now I'm confused. Do you want this filter instead of the current
situation, in addition to, or what? This is exactly why I asked for a
patch.
This is a completely separate issue, nothing to do with the hardened
team or the hardened compiler. It causes the same problem in the end,
but a completely different way.
The QA checks in portage advise the user to try:
LDFLAGS='-Wl,-z,now' emerge ${PN}
because the X server is suid, dyn linked and using lazy
bindings. This warning becomes fatal if FEATURES=stricter,
so you may want to RESTRICT it (which doesn't remove the warning, so
you should be able to find it in your build logs for xorg-server).
In summary, for Duncan's issue I suggest adding:
# Xorg server is unaviodably suid with lazy bindings
RESTRICT=stricter
to the xorg-server ebuild to stop it dying for people with
FEATURES=stricter (the comment helps people who have enabled STRICTER
to see why it's disabled, in case anything else crops up) and also to
add:
filter-ldflags -Wl,-z,now
to the eclass (perhaps in x-modular_src_compile, or in both
x-modular_src_config and x-modular_src_make). If you do it just on the
xorg-server ebuild, and people do what Duncan did and set LDFLAGS in
make.conf, it'll set BIND_NOW on everything which at the very least
will cause the radeon and GL drivers to fail to load.
Obviously I haven't tried it so it would be useful if Duncan could
raise a bug with the exact change he made.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Modular X and hardened
On Sun, 14 May 2006 12:46:23 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: The idea of filter-ldflags is a bad one, IMO. There are an infinite number of ways to enable a flag (for -z now: -Wl,-z,now; -Wl,-z -Wl,now; -Xlinker -z -Xlinker -now; -Wl,-O1,-z,now; ...). Even if you restrict yourself to the sane ones, you can't reasonably catch them all. That's true enough, however if people follow the QA instructions they'll do the -Wl,-z,now version. People doing other variations can get picked up when they raise a bug with emerge --info. Or we could make filter-ldflags more intelligent, of course. Normally, the proper fix would be `append-ldflags -Wl,-z,nonow` Ideally, yes - but as you note, -z nonow does not exist. BTW '-nonow' is a separate thing (note, no '-z'), added by us to the hardened compiler specs to switch off the automatic -z,now we do on links. but as binutils completely ignores this, that's not going to work either (as also noted earlier). I think the only sane thing to do (treating -Wl,-z,now -Wl,-O1 differently from -Wl,-z,now,-O1 is not sane) is to give a warning message telling users not to enable -z now even if portage states otherwise. Ideally, binutils would also be patched to support -z nonow, and -Wl,-z,nonow would be appended to LDFLAGS, but that's something for later concern. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Modular X and hardened
On Sat, 13 May 2006 11:32:49 +0200 Simon Strandman [EMAIL PROTECTED] wrote: Kevin F. Quinn (Gentoo) skrev: On Fri, 12 May 2006 10:49:22 +0200 Simon Strandman [EMAIL PROTECTED] wrote: I installed modular X on my server running hardened. X on a server? If it's just for the libs that's ok, but running the X server itself is risky on a server as it's huge and suid so flaws can easily gain root access. One such was discovered just the other week (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1526). I have my reasons. I need to run VNC on it. ok; just remember that by building vanilla you lose PIE and SSP as well (either of which can reduce the impact of buffer overflow exploits from privilege escalation to denial-of-service or less). For anyone else considering it, hardened advise sticking with 6.8 for now. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Modular X and hardened
On Sat, 13 May 2006 13:10:22 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Ned Ludd wrote: This was handled in the 6.8.x series and got dropped for unknown reasons when the modular X porting started happening. Unless your dead set on modular X I'd stick with the 6.8.x series. We are using the solution that was suggested to us by members of the hardened team. The current solution (bail if -z,now is set in the compiler specs) is not one suggested by the hardened team, just need to make that clear, and it's not something we would encourage elsewhere. However until we can provide a solution for such a high-profile package we are not going to make a fuss. Our suggestion was to 'append-flags -nonow' on the server and video driver builds, but when a helpful user tried it, it wasn't enough - we simply haven't had the resource to work it out properly yet. If you have a different solution, please do submit a patch for it. With regards to Duncan's (non-hardened) problem, adding: filter-ldflags -Wl,-z,now to x-modular.eclass as he suggests should be fine; his issue is different to that with the hardened compiler in as much as he has added the '-Wl,-z,now' to LDFLAGS as advised by the QA message and the above filter will just remove it again; whereas to deal with the hardened compiler we need to reliably add a flag to all the relevant link commands (the bit that takes the effort is working out which are relevant). Duncan - perhaps it would be useful if you could raise a separate bug about the QA message and Xorg, and attach the diff you apply to x-modular.eclass. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Modular X and hardened
On Fri, 12 May 2006 10:49:22 +0200 Simon Strandman [EMAIL PROTECTED] wrote: I installed modular X on my server running hardened. X on a server? If it's just for the libs that's ok, but running the X server itself is risky on a server as it's huge and suid so flaws can easily gain root access. One such was discovered just the other week (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1526). It was quite annoying to have to switch back and forth betwen the vanilla gcc and the hardened. I couldn't leave it on compiling over the night but had to monitor it all the time. Is this really necessary? Why can't the modular X eclass just append the appropriate CFLAGS/LDFLAGS that disables bind now or whatever it is thar breaks X instead? It could, if we had the time to get it working. It should work passing '-nonow' to all invocations of gcc that do linking of relevant bits, but for some reason when people have tried that it hasn't worked - see bug #110506. We (hardened) haven't had the time to investigate further, and we don't want to complicate the stabilisation effort of modular X (which is a big enough job as it is) so we've left it as it is for the moment. We'll probably start looking at it again once it becomes stable (also upstream have a pending task to resolve the issue properly, but don't hold your breath). P.S. there's a hardened mailing list that is relevant. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
On Thu, 04 May 2006 16:29:56 -0700 Michael Kirkland [EMAIL PROTECTED] wrote: This leads to people trying to maintain a frankenstinian /etc/portage/package.keywords file, constantly adding to it and never knowing when things can be removed from it. If you use specific versions in the package.keywords file (i.e. do =category/package-version-revision ~arch instead of category/package ~arch, this doesn't happen. You just need to watch for downgrades in case a ~arch version is removed without ever going stable, and every so often go through it looking for package versions that have been superseded. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Packages that need maintainers
On Thu, 4 May 2006 21:20:48 -0500 spradlim [EMAIL PROTECTED] wrote: I have a question that I havn't been able to find that is somewhat related to the following email. I know and understand Linux very well. I also know how ebuilds work. So how do I go about maintaining packages and getting them into portage. For example I would like to maintain a munin, munin-plugin, and tightvnc ebuild. Where can I find this information. I don't know where to start. Gentoo Developer Handbook, Becoming a developer http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=2 In the first instance, do the work on bugzilla. Look for open bugs for existing packages, and post fixes/patches there. For packages not currently in portage, raise a new bug. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
On Fri, 5 May 2006 13:20:09 +0200 Carsten Lohrke [EMAIL PROTECTED] wrote: On Friday 05 May 2006 08:32, Kevin F. Quinn (Gentoo) wrote: If you use specific versions in the package.keywords file (i.e. do =category/package-version-revision ~arch instead of category/package ~arch, this doesn't happen. Hardcoding specific ~arch versions or revisions unless absolutely needed is a bad idea. Remember that we don't do GLSA's for testing stuff. If bleeding edge, then bleeding edge. I disagree. Your argument is for not using ~arch at all, rather than an argument against keeping control of what you have from ~arch. If I want something from ~arch, it's for one of two reasons: 1) There's a feature/fix that I need now 2) I want to try out a new version of something for fun I certainly don't want to take everything from ~arch; that way leads to regular system instability. In practice, I tend to do: =category/package-version* ~arch so that I pick up -rN bumps on unstable versions as this should mean that the maintainer considers the change necessary for users of that version. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
On Fri, 5 May 2006 16:38:57 +0200 Carsten Lohrke [EMAIL PROTECTED] wrote: On Friday 05 May 2006 15:23, Kevin F. Quinn (Gentoo) wrote: I disagree. Your argument is for not using ~arch at all, rather than an argument against keeping control of what you have from ~arch. No. My argument is that category/ebuild is much better than =category/ebuild-x*. If and only if there's a problem with the former, you should take the latter into account and monitor the ebuild changes closely. From my perspective, category/package is worse. It means once a package goes ~arch, it never becomes arch again. My approach means that when I've gone ~arch to get something only available in that version, it becomes arch once the package gets stabilised or a later version is stabilised. In practice, I tend to do: =category/package-version* ~arch so that I pick up -rN bumps on unstable versions as this should mean that the maintainer considers the change necessary for users of that version. So you won't get security updates, when this means it is a version bump. And this is most often the case. Unless you _always_ read the ChangeLogs and referenced bugs of all ebuilds you run testing, this is not safe. First, I'll get the security updates when (1) the relevant updated package goes stable, which is usually pretty quickly, or (2) notification is made in gentoo-announce (which must be the correct place to get such notifications). Secondly, Up-to-date on GLSAs != safe. Not by a long shot. Further, missing GLSAs does not necessarily mean I'm vulnerable. That's what the detail is for in the GLSAs; so I can make a judgement call on whether I need to worry about a vulnerability or not. Lastly, if there are versions of a package in ~arch that have known security flaws, my understanding is that they either get patched with a -rN bump, or they get removed from the tree in favour of a later version that is not vulnerable. Either way, I get notification when I next do an update. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Herds, Teams and Projects
OK; just to clarify my understanding, and perhaps for anyone else watching who saw things as muddled as I did: 1) A herd is a group of packages, no more, no less. A package must be a member of at least one herd (since the herd entry is mandatory in metadata.xml, and metadata.xml is mandatory). 2) A package can belong to more than one herd. 3) A herd does not have an email address - it's not a person or group of people so an email address is nonsensical. 4) In the first instance, a package is maintained by those listed by maintainer entries in the package's metadata.xml 5) In the second instance, a package is maintained by the people indicated by the package's herd entry or entries at /gentoo/misc/herds.xml 6) The herd entry may specify directly a list of maintainers with optional roles, or may refer to projects or other herds to locate maintainers. Another way of looking at it; herds are a mechanism for locating maintainers for packages. Seems simple enough when written out like that - flame me if I have it wrong :) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Herds, Teams and Projects
On Wed, 26 Apr 2006 20:29:32 -0400 Seemant Kulleen [EMAIL PROTECTED] wrote: To that end, it's been brought up that perhaps the metadata.xml files are partly to blame, in that they imply that the package is maintained by a herd. There is not maintainer-team listed, just a herd. So, I would like to propose that we make this distinction clearer in the metadata.xml files. I'm interested in thoughts that people have on this, but please do cc: me in your response to be assured that I read it. I must admit I've assumed that the herd entry in metadata.xml is a reasonable fall-back if the maintainer entry is missing or the listed maintainer is away/not responding. This is implied by http://www.gentoo.org/proj/en/metastructure/herds/index.xml which requires herd but not maintainer - also the description of maintainer says Besides being a member of a herd, a package can also be maintained directly which implies the herd is the default maintainer if maintainer is not present. The herds project description says, The herds project aims to ensure that the growing number of ebuilds do not overwelm (sic) the gentoo project. To this end the herds project aims for the development of infrastructure that will help manage the collection of ebuilds. This clearly indicates herds are supposed to have a maintainer role. A quick scan of the tree shows that some 6k+ packages have no maintainer entry. It would be useful to know how many people think herds are not maintainers - if only a few people think this then I suggest it would be better to accept the common interpretation of herd as a group of people who can maintain a package. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Herds, Teams and Projects
On Thu, 27 Apr 2006 10:27:12 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: On Thu, 2006-04-27 at 09:22 +0200, Kevin F. Quinn (Gentoo) wrote: I must admit I've assumed that the herd entry in metadata.xml is a reasonable fall-back if the maintainer entry is missing or the listed maintainer is away/not responding. This is implied by http://www.gentoo.org/proj/en/metastructure/herds/index.xml which requires herd but not maintainer - also the description of maintainer says Besides being a member of a herd, a package can also be maintained directly which implies the herd is the default maintainer if maintainer is not present. Well, the herd listing shows what herd that it belongs to, not the team that manages that herd. I think that this is the confusion. For example, catalyst has livecd listed as its herd. However, there is not a livecd project, nor team. Instead, the livecd herd is maintained by myself, solely, except for genkernel and catalyst, that have alternate maintainers. In the case of catalyst, an alias is listed as the maintainer, since there *is* a catalyst team, albeit small. The herds project description says, The herds project aims to ensure that the growing number of ebuilds do not overwelm (sic) the gentoo project. To this end the herds project aims for the development of infrastructure that will help manage the collection of ebuilds. This clearly indicates herds are supposed to have a maintainer role. Where? Two places. First, in the description of maintainer: Besides being a member of a herd, a package can also be maintained directly which implies packages can be maintained by being a member of a herd and secondly where it says: [herds] help manage the collection of ebuilds I interpreted manage to include maintain, since I couldn't think of any other management that needs to be done. If we're to distinguish between herds and teams, and it seems that we should, clearly something needs to define which teams maintain which herds. I can see how you can interpret it like that, but it is anything but clear in stating it. In fact, it mentions nothing about maintaining any packages, but rather to manage the collection of them, which leads me to read it as it is there solely for creating a logical grouping of specific packages, much like how categories work in the tree itself. For example, look at openal. It is a package in the sound herd, yet the sound *team* does not maintain it. I do. A quick scan of the tree shows that some 6k+ packages have no maintainer entry. Well, ~700 of those are games, which belong to the games herd, and have no specific maintainer. The games *team* maintains all packages in the games herd that does not have a specific maintainer listed. It just so happens that in *many* cases, the project (or team) has the same name as the herd to which the package belongs. I think that this has been the cause of the confusion, more than the definitions. I do think that metadata.xml should always indicate who maintains a package, whether it's a single maintainer or a team of maintainers - including who is the backup should the primary maintainer be unavailable for an urgent change. If the herd is nothing to do with who maintains a package, then the maintainer entry should be mandatory; there can be multiple entries and it's easy enough to set up team mail aliases. I also think it should be clear in metadata.xml who the backup maintainers are if such exist - i.e. someone who can process stuff in the absence of the primary maintainer. Maybe other people were assuming, like me, that if maintainer is missing then the herd was the mail alias to write to. I can see from what you're saying that the herd name is not a mail alias (since it doesn't refer to people). It definitely seems that we need to define somewhere which teams maintain which herds. The games example is perhaps obvious, but in general that won't be the case. Perhaps for simplicity (and to save having to edit 6k+ metadata.xml files), we could rule that if the maintainer entry is missing, and the herd name is the same as a team name, that team is the maintainer for the package. It would be useful to know how many people think herds are not maintainers - if only a few people think this then I suggest it would be better to accept the common interpretation of herd as a group of people who can maintain a package. I definitely do not think that herds are maintainers. At the same time, I understand that many people do think this, so I'm willing to change *my* definition to match what the in practice definition ends up being, if necessary. So what are the herds supposed to achieve? It would be useful to see some examples of what herds are/could be useful for. I'm happy to go with the intended definition of herd, but it certainly could be clearer in the documentation. -- Kevin F. Quinn -- Kevin F. Quinn signature.asc
Re: [gentoo-dev] Purpose of USE=doc
On Tue, 25 Apr 2006 20:03:00 +0200 Jakub Moc [EMAIL PROTECTED] wrote: I'd like to see some clarification of intended doc use flag usage From what I've gleaned over time, USE=doc is supposed to enable docs that are one or more of: (1) large (2) take a significant amount of resource to build (3) cause extra deps (2) and (3) are usually co-incident. IMHO, of course ;) Whatever we decide USE=doc means, it should be documented as such in use.desc -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
On Sat, 25 Mar 2006 03:31:34 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: Although I don't know darcs at all in terms of use and feature, I would really suggest to _not_ use it. For a simple reason, actually: cvs has almost no cost added, as it's present on every major distribution, system and operating system, being well known and written in plain C with just a few dependencies; svn has a bit more costs, as it requires apr, berkdb and neon, but it's also available on a wide range of different system because it's also in C mainly. If you're suggesting CVS as the second VCS (i.e. in addition to SVN) then I don't see the point - SVN is simply a better CVS and clients should be available on the alt platforms. Darcs, instead, is written in Haskell, which means you need architectures that supports Haskell, and in which it's stable enough to work... considering we have Gentoo/Alt, it's not that good to cut us off (yes I know I should be able to make Gentoo/FreeBSD and maybe other arches to have ghc, but that's not easy and not on my top priority list, while support for overlays can be useful.. for a while we needed java overlay to get kaffe, for example). This is a valid issue, as ghc is only supplied upstream for linux (some older versions available in mingw32). I would be more in favour of GNU arch derived like bzr (bazaar-ng) or mercurial, that are written in Python. While we should know that saying being interpreted means it runs anyway doesn't fly, a working python is already a strict requirement (portage, anyone?) and it's way less pain that ghc, IMHO. I'm also sure bzr works fine on FreeBSD, DragonFly and OSX as I've tried it myself.. Language issues aside, it makes sense to support a distributed VCS in addition to SVN, as that would provide a useful alternative. There's a quick comparison at http://bazaar-vcs.org/RcsComparisons. Of the alternatives to Bazaar-NG, Mercurial (at http://www.selenic.com/mercurial/) looks most interesting, not least because it claims fast local and network performance, which bazaar-ng doesn't. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
On Sat, 25 Mar 2006 11:46:58 + Duncan Coutts [EMAIL PROTECTED] wrote: On Sat, 2006-03-25 at 12:42 +0100, Kevin F. Quinn (Gentoo) wrote: This is a valid issue, as ghc is only supplied upstream for linux (some older versions available in mingw32). I don't think this is right. All the recent ghc versions have been supplied upstream on many OSs including installers for win32 and OSX. The OpenBSD, FreeBSD Darwin ports systems include ghc. Sorry, yes - I looked at the snapshot download pages where it's linux and mingw32) instead of the release download pages (where it's linux x86, x86_64, ppc, ppc64 and windows, FreeBSD x86, OpenBSD x86, MacOS X and AIX). However the issue still remains for non-x86/ppc platforms; sparc in particular is likely to be used as a dev platform by some. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
On Sat, 25 Mar 2006 12:37:45 + Duncan Coutts [EMAIL PROTECTED] wrote: On Sat, 2006-03-25 at 13:32 +0100, Kevin F. Quinn (Gentoo) wrote: On Sat, 25 Mar 2006 11:46:58 + Duncan Coutts [EMAIL PROTECTED] wrote: On Sat, 2006-03-25 at 12:42 +0100, Kevin F. Quinn (Gentoo) wrote: This is a valid issue, as ghc is only supplied upstream for linux (some older versions available in mingw32). I don't think this is right. All the recent ghc versions have been supplied upstream on many OSs including installers for win32 and OSX. The OpenBSD, FreeBSD Darwin ports systems include ghc. Sorry, yes - I looked at the snapshot download pages where it's linux and mingw32) instead of the release download pages (where it's linux x86, x86_64, ppc, ppc64 and windows, FreeBSD x86, OpenBSD x86, MacOS X and AIX). However the issue still remains for non-x86/ppc platforms; sparc in particular is likely to be used as a dev platform by some. I use ghc and darcs on my sparc box all the time. ghc-6.4.1-r2 is currently marked stable on sparc. darcs is currently marked ~sparc. Ahem. Sorry again - I still didn't look at the right page! http://www.haskell.org/ghc/download_ghc_641.html lists sparc, hppa, and also alpha, m68k s390 on debian. I'm currently working on ghc for ia64 since Aron Griffis was interested in using darcs on ia64. It's looking good so far. As Flameeyes pointed out our main problem is with the various Gentoo/ALT systems where we don't have quite enough developer time to allow ghc to get near the top of the TODO list (though we do have it working with ppc osx). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Re: User created package lists
On Tue, 21 Mar 2006 10:50:00 -0600
MIkey [EMAIL PROTECTED] wrote:
Add the capability for emerge to take a category as an argument,
# (cd ${PORTDIR_OVERLAY} emerge -pv category/*)
Then the user can create overlays with their own category names and
symlink in the package directories they want from the real portage
tree.
This won't work, I think, since depend atoms include the category name
so if one package in the new category depends on another one, it will
use the standard category rather than the symlinked one in the new
category.
However with regards the original question about adding '--list
file' to emerge, you can of course to package lists yourself anyway
as portage exists today. Just create a file with a list of atoms in
it, and do for example:
# cat file | xargs emerge -puv
Doesn't get much easier than that - perhaps I'm missing something :)
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] enable UTF8 per default?
On Tue, 28 Feb 2006 11:58:03 +0100 Patrick Lauer [EMAIL PROTECTED] wrote: During that discussion we realized that having utf-8 not enabled by default and no utf8 fonts available by default causes lots of recompilation and reconfiguration. Enabling the unicode useflag in the profiles should help our international users and should not cause any problems. Are there any known bugs / problems this would trigger? Any reasons against that? Enabling support for utf-8 should be fine, but I'd like to sound a note of caution about using a utf-8 locale as a system-wide setting. Since UTF-8 contains holes in the representation (i.e. some sequences of 8-bit values are invalid), when something is asked to parse such invalid data unexpected results can ensue. For an example, see bug #125375 - it turns out that invalid sequences do not match '.' in sed regular expressions (sed-4.1.4). The other gnu tools probably behave similarly. Up to a point this is in line with the UTF-8 spec, which says, When a process interprets a code unit sequence which purports to be in a Unicode character encoding form, it shall treat ill-formed code unit sequences as an error condition, and shall not interpret such sequences as characters. (chapter 3 para 2 rule C12a). This clearly means that the invalid bytes cannot match . (or anything else for that matter). However sed should either generate an error, filter the illegal bytes out of its input, or replace them with a marker (replacement character) - instead it leaves the non-conformant bytes alone. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [rfc] variable naming for marking binaries as QA ignorable
On Wed, 8 Mar 2006 00:17:52 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:
how does the attached patch look ? it allows for regexes in the
ignore list which is why i used gawk ;)
Could we add something so that we can disable these ignore lists in the
hardened profile? At least something like:
if [[ -n ${QA_STRICT_TEXTRELS} ]]; then
f=$(scanelf -qyRF '%t %p' ${D})
else
filter version
fi
...
where we can add QA_STRICT_TEXTRELS to make.defaults.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] [rfc] variable naming for marking binaries as QA ignorable
On Sun, 5 Mar 2006 20:46:25 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: On Sunday 05 March 2006 19:48, Kevin F. Quinn (Gentoo) wrote: This could be done via the profiles, perhaps - package.qa, something like package.mask/use/keywords: i hate such things ... imo this information should stay in the ebuild and nowhere else ... I was thinking that the data would be owned by the QA team rather than the package maintainers. I appreciate your pov, however. There may be benefit in being able to set it differently for each profile; for example a hardened (PaX NOELFRELOCS) profile might always have QA_TEXTRELS set empty (i.e. anything with TEXTRELs would fail to install, as it'd fail to run anyway). However package maintainers in general aren't going to like yet more special-casing for the non-mainstream profiles. Anyway, that aside - if you're going for a QA_feature_arch naming, you could use QA_feature where there's no arch difference, supplying others where necessary such that if QA_feature_arch exists it takes precedence over QA_feature. Otherwise you'll end up adding a whole set of variables to all affected ebuilds. Admittedly there aren't that many of them so it may not be worth the hassle. Heh - here's another idea for you to hate: QA_OVERRIDE=EXECSTACK=... x86? ( TEXTRELS=... ) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [rfc] variable naming for marking binaries as QA ignorable
On Sat, 04 Mar 2006 19:56:41 -0500 Ned Ludd [EMAIL PROTECTED] wrote: On Fri, 2006-03-03 at 23:32 -0500, Mike Frysinger wrote: so we've found some cases where a package installs objects that either need to be ignored by some of the scanelf checks ... ... what this e-mail is about is naming convention ... i'm thinking that an ebuild sets up a variable with a list of relative paths to $D of files that should be skipped for various checks ... so with slmodem, we'd have like: QA_EXEC_STACK=usr/sbin/slmodemd usr/sbin/slmodem_test if, in the future, we need to add an ignore list for TEXTRELs, we'd use QA_TEXTRELS= This becomes tricky when looking at tests across all CHOSTs. What holds true for one arch defiantly is not the case for others. This could be done via the profiles, perhaps - package.qa, something like package.mask/use/keywords: net-dialup/slmodem QA_EXECSTACK=... QA_TEXTRELS=... -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] how to turn off hardened gcc flags reliably?
On Thu, 02 Mar 2006 00:54:25 + Duncan Coutts [EMAIL PROTECTED] wrote: On Thu, 2006-03-02 at 00:41 +, Roy Marples wrote: For the non technically minded folks whats the difference between -fno-stack-protector and -fno-stack-protector-all? [...] It was explained to me like this: -fno-stack-protector makes gcc use a heuristic to decide whether or not change a function to use stack-smashing protection. -fno-stack-protector-all makes gcc just do it for every function. not quite (note the 'no-'!): In gcc-3: -fstack-protector switches on stack protection for functions that gcc decides heuristically to be most vulnerable according to their parameters and local data. -fstack-protector-all switches on stack protection for (almost) all functions -fno-stack-protector switches off -fstack-protector -fno-stack-protector-all switches off -fstack-protector-all Of note is that: ... -fstack-protector -fstack-protector-all -fno-stack-protector results in no ssp at all ... -fstack-protector -fstack-protector-all -fno-stack-protector-all results in heuristic ssp switched on For gcc-4.1, the semantics have changed as RedHat Did Their Own Thing and broke backwards compatibility: 1) -fno-stack-protector-all does not exist 2) stack protection is viewed as a three-state setting configured by the last occurring switch from the set -fno-stack-protector - no stack protection -fstack-protector - heuristic stack protection -fstack-protector-all - stack protection on all functions (imo they should have done something like -fstack-protect[N] for N=0,1,2 which would have been clearer, but I got ignored when I suggested it) Since 'last option wins' in the RedHat version, '-fstack-protector-all -fstack-protector' gives heuristic ssp, whereas on gcc-3 it gives full ssp. Upshot - managing ssp has become a bit of a pita :/ (gcc-4 is currently masked in the hardened profile, primarily because gcc-4.0 has no ssp, but going forward also until we decide what to do with the hardened specs on gcc-4.1). there is also: -fno-stack-protector-to-all which if supplied makes -fno-stack-protector get promoted to -fno-stack-protector-all. Apparently -fno-stack-protector-to-all is on by default in all current gcc profiles so that means that at the moment if you specify -fno-stack-protector you really get -fno-stack-protector-all. there is no '-fno-stack-protector-to-all' as such. the gcc specs we change (in gcc-3) currently switch -fstack-protector-all on if -fstack-protector is set (either on the command line or automatically in the case of the hardened compiler). This occurs also with the vanilla compiler - which is a bug although very few people (if any) come across it as the only supported way to use the stack protector at the moment is by using the hardened compiler. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] enable UTF8 per default?
On Tue, 28 Feb 2006 12:47:33 -0500 solar [EMAIL PROTECTED] wrote: I forget where I read it but I thought that unicode lead to overflows and was considered a general security risk. I wish I knew where I read that but I'm unable to find it. Well, stuff I could find includes: http://www.kde.org/info/security/advisory-20060119-1.txt buggy UTF-8 decoder in KDE - this is an overflow error, which as ciaranm says is a risk applicable to anything. It's a bug in KDE, not in UTF-8 as such. Perhaps this is what was at the back of your mind. http://www.izerv.net/idwg-public/archive/0181.html risks of using UTF-8; in particular the use of separate validators which won't process things exactly the same way the application does. Also homograph risks associated with allowing more than one encoding for a character. http://www.eeye.com/html/Research/Advisories/AD20010705.html example of UTF-8(ish) used to fool IDSs by using alternative non-standard encodings that IDSs aren't aware of. This actually is another example of issues with secondary validators described in the link above - they're not guaranteed to parse things exactly the same way the application does. http://www.microsoft.com/mspress/books/sampchap/5612b.asp describes a number of risks of accepting UTF-8, including the above. So far I haven't found anything that could be considered a general security risk, but that doesn't prove much :) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: seeing a new trend of laziness developing.
On Sun, 26 Feb 2006 12:30:50 -0600 R Hill [EMAIL PROTECTED] wrote: Ned Ludd wrote: 232 matches. http://tinyurl.com/pmrmx The vast majority of which have an explanation in the comment directly preceding. In which case it's a moment's effort to cut-n-paste the text into the reassignment/resolution comment. Hence solar's laziness accusation. I'd go further, and suggest that sometimes it's not just laziness (since cut-n-paste isn't any more effort than typing '.') but a deliberate action to avoid explaining oneself. When re-assigning, it is extremely useful for the new assignee to see some relevant text, as this is the first bit of text they may see. If you just re-assign with '.' then the new assignee has to browse the bug to decide how to prioritise etc - which means flipping from your email client to the web browser or whatever. All of this breaks up processing the stream of stuff coming from bugzilla, causing wasted time - all because someone was deliberately evasive about why they reassigned. Similarly when resolving, just saying '.' means other interested parties have to browse the bug to check whether the resolution is valid or not - if there's a decent comment along with the resolution this becomes unnecessary in the majority of cases. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Putting all log related packages into it's own category (sys-logging)
On Mon, 20 Feb 2006 14:13:46 +0100 Bjarke Istrup Pedersen [EMAIL PROTECTED] wrote: I was thinking, how about putting all log related packages into their own category? Personally I think unless there is a real problem that needs to be resolved, moving packages around should be avoided. We've been over the problems of the concept of categories many times, I don't see any value in going through it in depth again as categories are too deeply embedded to be changed. Suffice to say that any package is likely to have several reasonable categorisations, however the tree only supports one. Different people will prefer different categorisations according to each person's perspective, so moving packages to suit one perspective just messes things up for another perspective. Maybe creating a logging herd would be an idea to, to remove the load from the base-system herd. Creating a herd is not a problem; obviously herds and categories are completely different things. However a quick scan of the logging-related packages in sys-admin shows they mostly do not belong to a herd, so are not imposing any load on the base-system herd as such. Creation of a herd for these packages would be a question for the maintainers of those packages :) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables
On Thu, 9 Feb 2006 22:48:32 +0100 Grobian [EMAIL PROTECTED] wrote: Please find attached GLEP 47: Creating 'safe' environment variables. Could you add a definition of 'safe' to the GLEP? It's not clear what this means at the moment. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thu, 19 Jan 2006 19:28:53 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: On Thursday 19 January 2006 18:52, Mark Loeser wrote: Please lets avoid this assumption. I'd love to make it so we never make this assumption anywhere in the tree so that we could actually build GCC without pie or ssp, instead of generating all of the GCC profiles for every user. SPLIT_SPECS=no in make.conf causes just the profile default to be built - is that good enough? pie is in upstream gcc so your argument here is INVALID and -fno-stack-protector is only a problem if gcc-4.0 is built without the ssp-stubs - from 4.1 onwards that'll be upstream as well. Having said that, I don't think we need -fno-stack-protector in default DEBUG_FLAGS anyway, as it doesn't inhibit debug (unlike -Wl,pie). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thu, 19 Jan 2006 18:33:02 -0500 solar [EMAIL PROTECTED] wrote: On Thu, 2006-01-19 at 17:56 -0500, Mike Frysinger wrote: DEBUG_CFLAGS=DEBUG_CXXFLAGS=-O -g Mike, how about DEBUG_CFLAGS=DEBUG_CXXFLAGS=-O -g -fno-stack-protector -fno-pie It's enough to do LDFLAGS=-nopie to get debuggable executables, which might be better as it'd keep code closer to the non-debug code. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Ada compiler: split complete, naming suggestions for gnat-gpl?
On Sun, 15 Jan 2006 10:44:41 +0100 George Shapovalov [EMAIL PROTECTED] wrote: 1. 2005 stands for the standard revision namme (as in Ada 2005) really rather than for a particular version. To elaborate for those unfamiliar with Ada; this is the same sort of thing as C89, C99. Enforcing the previous 83 standard over the current 95 standard can be done by the switch -gnat83; I imagine the 2005 release will add a switch -gnat95. I see two alternatives here: 1. gnat-gpl-2005.1. This keeps it closer to upstream, makes it look like a more real version number and allows trivial increment if an update is released soon (the nearest one is likely to be 2006.1 already although :)) If the 2005 is the standard version then they won't change it to 2006. If they do change it to 2006, then the 2005 is the release date not a reference to the standard - in which case it is the upstream release number :) 2. gnat-gpl-3.4.5.1 This uses the backend gcc version as a base, adding a gnat release indicator to track gnat-gpl specific changes. Further from upstream naming but simplifies SLOT logic in eclass a lot (in the long run, no need to issue one more conditional for another new version). I am leaning more towards option one (gnat-gpl-2005.1), for consistency with upstream reason, as it will be (potentially) less confusing to the users. However I am interested in opinions.. If the 2005 does turn out to be a release date rather than the standard name, then it makes sense as a release version; gnat-gpl-2005 would be enough. Later releases can add a point revision if necessary; if you do 2005.1 now, what happens if upstream release gnat-gpl-2005.1.tgz? Another possibility is gnat-gpl-3.4.5.2005, but I'm not sure that it's worth it. -- Kevin F. Quinn -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Some new xorg ebuilds
Hi Xorg 6.8.99.5 really works good. I've see that 6.8.99.7 have been released in CVS. Did you make some test ? [ Also, I've made some ebuilds dor XCB, if you are interested : http://bugs.gentoo.org/show_bug.cgi?id=93582 ] See Ya Beber, On 4/19/05, Donnie Berkholz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just added a couple of new xorg-x11 ebuilds. 6.8.2-r2 is a work in progress and will soon be removed from package.mask and unleashed upon the masses. 6.8.99.3 is a development snapshot of CVS HEAD and is part of an occasionally released series (roughly every two weeks). Let me know how things go with them via bugs.gentoo.org. If you hit a bug in 6.8.2, please try out the 6.8.99.* snapshots to see whether it's still present. Thanks! Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCZLqxXVaO67S1rtsRArZcAKC0KPjSd6DVuyRvgu22+Y+o37E1HwCcDDss O9zNijm60QbXWpWRwCtOoZQ= =aC/a -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
