Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
Dnia 18 maja 2017 08:23:26 CEST, Alex Turbov napisał(a): >As for me I'm doing few Python projects and as I said before I prefer >to >have (real) offline docs, cuz often visit places far from >"civilization" >and where 150Kib/s considered as pretty fast Internet connection. Also >I'm >very patient on keeping my Gentoo system under control and minimized >(eliminating unnecessary dependencies and files). I could help with >adding >patches and bug reports for packages I use. Please use pull requests. And focus on easy cases first. For the plugin case, I need to create the necessary logic in the eclass. > >On Thu, May 18, 2017 at 12:10 PM, Michał Górny >wrote: > >> On śro, 2017-05-17 at 21:44 -0700, Daniel Campbell wrote: >> > On Sat, May 13, 2017 at 09:32:46AM +0200, Michał Górny wrote: >> > > On pią, 2017-05-12 at 17:42 -0700, Daniel Campbell wrote: >> > > > On 05/11/2017 12:51 AM, Michał Górny wrote: >> > > > > In fact, I'm personally leaning towards not building docs at >all >> > > > > in ebuilds. It's practically a wasted effort since most of >the time >> > > > > users read docs online anyway. >> > > > >> > > > I believe that's a little myopic; a user (or even developer) >may not >> > > > have Internet access all the time, or may not have it in their >> primary >> > > > development environment. Having a copy of the docs locally (the >> entire >> > > > point of USE="doc") is super valuable to have when you're away >from >> the >> > > > network. I'm sure I'm not alone as one of the people who uses >the >> flag >> > > > and appreciates the work that goes into making sure said flag >works. >> > > > >> > > > Sure, we could yank out every single USE="doc", but then we >lose a >> nice >> > > > feature of the tree and users are back to either (a) trawling >the >> Web to >> > > > find the project site, then hope they have docs in a separate >> download, >> > > > or (b) we end up with foo+1 packages, one extra for any package >that >> has >> > > > documentation. Neither are particularly good solutions; Debian >has >> done >> > > > the latter and it results in a huge number of packages for >little >> gain. >> > > >> > > The Python team mostly focuses on providing packages for >dependencies >> of >> > > other Gentoo packages, not direct Python development. We do not >have >> > > the manpower to go above that. >> > > >> > > -- >> > > Best regards, >> > > Michał Górny >> > >> > Ah, well that at least explains why you're not interested in it. >> > Dependency management alone can be tough; I've not noticed any >Python >> > issues, so it seems like you guys do well. :) If you don't mind me >> > asking, what would it take to solve the USE="doc" issue to the >Python >> > team's standard? I have some personal interest in Python and >wouldn't >> > mind adding 'doc' support for Python packages that users request >docs >> > for. >> > >> > Maybe others are willing to join me on this. Is that something we >can >> > make happen without getting in anyone's hair? >> > >> >> For a start, it'd be nice to figure all the stuff out in detail, >> and document it -- when USEDEP is needed, not needed, when we need >> something else (like the plugin case). Once that is done, it's just >> a matter of checking and fixing existing packages, and being patient >> with devs doing the same mistakes again ;-). >> >> -- >> Best regards, >> Michał Górny >> -- Best regards, Michał Górny (by phone)
Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
As for me I'm doing few Python projects and as I said before I prefer to have (real) offline docs, cuz often visit places far from "civilization" and where 150Kib/s considered as pretty fast Internet connection. Also I'm very patient on keeping my Gentoo system under control and minimized (eliminating unnecessary dependencies and files). I could help with adding patches and bug reports for packages I use. On Thu, May 18, 2017 at 12:10 PM, Michał Górny wrote: > On śro, 2017-05-17 at 21:44 -0700, Daniel Campbell wrote: > > On Sat, May 13, 2017 at 09:32:46AM +0200, Michał Górny wrote: > > > On pią, 2017-05-12 at 17:42 -0700, Daniel Campbell wrote: > > > > On 05/11/2017 12:51 AM, Michał Górny wrote: > > > > > In fact, I'm personally leaning towards not building docs at all > > > > > in ebuilds. It's practically a wasted effort since most of the time > > > > > users read docs online anyway. > > > > > > > > I believe that's a little myopic; a user (or even developer) may not > > > > have Internet access all the time, or may not have it in their > primary > > > > development environment. Having a copy of the docs locally (the > entire > > > > point of USE="doc") is super valuable to have when you're away from > the > > > > network. I'm sure I'm not alone as one of the people who uses the > flag > > > > and appreciates the work that goes into making sure said flag works. > > > > > > > > Sure, we could yank out every single USE="doc", but then we lose a > nice > > > > feature of the tree and users are back to either (a) trawling the > Web to > > > > find the project site, then hope they have docs in a separate > download, > > > > or (b) we end up with foo+1 packages, one extra for any package that > has > > > > documentation. Neither are particularly good solutions; Debian has > done > > > > the latter and it results in a huge number of packages for little > gain. > > > > > > The Python team mostly focuses on providing packages for dependencies > of > > > other Gentoo packages, not direct Python development. We do not have > > > the manpower to go above that. > > > > > > -- > > > Best regards, > > > Michał Górny > > > > Ah, well that at least explains why you're not interested in it. > > Dependency management alone can be tough; I've not noticed any Python > > issues, so it seems like you guys do well. :) If you don't mind me > > asking, what would it take to solve the USE="doc" issue to the Python > > team's standard? I have some personal interest in Python and wouldn't > > mind adding 'doc' support for Python packages that users request docs > > for. > > > > Maybe others are willing to join me on this. Is that something we can > > make happen without getting in anyone's hair? > > > > For a start, it'd be nice to figure all the stuff out in detail, > and document it -- when USEDEP is needed, not needed, when we need > something else (like the plugin case). Once that is done, it's just > a matter of checking and fixing existing packages, and being patient > with devs doing the same mistakes again ;-). > > -- > Best regards, > Michał Górny >
Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
On śro, 2017-05-17 at 21:44 -0700, Daniel Campbell wrote: > On Sat, May 13, 2017 at 09:32:46AM +0200, Michał Górny wrote: > > On pią, 2017-05-12 at 17:42 -0700, Daniel Campbell wrote: > > > On 05/11/2017 12:51 AM, Michał Górny wrote: > > > > In fact, I'm personally leaning towards not building docs at all > > > > in ebuilds. It's practically a wasted effort since most of the time > > > > users read docs online anyway. > > > > > > I believe that's a little myopic; a user (or even developer) may not > > > have Internet access all the time, or may not have it in their primary > > > development environment. Having a copy of the docs locally (the entire > > > point of USE="doc") is super valuable to have when you're away from the > > > network. I'm sure I'm not alone as one of the people who uses the flag > > > and appreciates the work that goes into making sure said flag works. > > > > > > Sure, we could yank out every single USE="doc", but then we lose a nice > > > feature of the tree and users are back to either (a) trawling the Web to > > > find the project site, then hope they have docs in a separate download, > > > or (b) we end up with foo+1 packages, one extra for any package that has > > > documentation. Neither are particularly good solutions; Debian has done > > > the latter and it results in a huge number of packages for little gain. > > > > The Python team mostly focuses on providing packages for dependencies of > > other Gentoo packages, not direct Python development. We do not have > > the manpower to go above that. > > > > -- > > Best regards, > > Michał Górny > > Ah, well that at least explains why you're not interested in it. > Dependency management alone can be tough; I've not noticed any Python > issues, so it seems like you guys do well. :) If you don't mind me > asking, what would it take to solve the USE="doc" issue to the Python > team's standard? I have some personal interest in Python and wouldn't > mind adding 'doc' support for Python packages that users request docs > for. > > Maybe others are willing to join me on this. Is that something we can > make happen without getting in anyone's hair? > For a start, it'd be nice to figure all the stuff out in detail, and document it -- when USEDEP is needed, not needed, when we need something else (like the plugin case). Once that is done, it's just a matter of checking and fixing existing packages, and being patient with devs doing the same mistakes again ;-). -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] mingw-w64 crossdev prefix?
On Thu, May 18, 2017 at 12:42:09AM -0400, Ian Stakenvicius wrote: > On 18/05/17 12:08 AM, Marty Plummer wrote: > > On Thu, May 18, 2017 at 06:46:24AM +0300, Alon Bar-Lev wrote: > >> Hi, > >> You can emerge crossdev and then run crossdev -t x86_64-w64-mingw32 or > >> crossdev -t i686-w64-mingw32 > >> Alon > >> > > I'm aware of that, using it. Its simply the fact that its fairly broken > > for mingw-w64, and requires quite a lot of hackage to get going. > > > > What I'm suggesting is the creation of a profile that should handle this > > sort of thing for you semi-automatically. Something like the > > prefix/windows, but meant more for toolchains. it seems that beber's > > portage tree at git.meleeweb.net/gentoo/portage.git already has a setup > > similar to what I envision already. > > > > There isn't a whole lot that's broken about it actually -- the main > issue is that the default 'embedded' profile doesn't allow all of the > variable overrides in it that are necessary for the crossdev to work > properly. See bug http://bugs.gentoo.org/487310 > > The crossdev that's created will provide all the necessary profile > overrides to allow you to emerge the things you want, and of course > compile your own things as well. There's no need for a special prefix > (or 'prefix/*' profile) in order to support this, IMO, once the > embedded profile permits the overrides necessary to the ARCH, ELIBC, > and KERNEL variables that the crossdev tool already sets. > There's also a host of packages that are pulled in by default which are simply uneeded for this sort of setup, such as coreutils, sed, file, debianutils which have to be manually package.provided away by end users. I'm simply suggesting we should make this a bit more easy for everyone involved, as it could ease use and possibly cut down on spurious bug reports if there was a standardized way of doing things. This is a common enough use case that it should be handled upstream imho. I'm more than willing to help in this matter, but I don't want to be spitting into the wind if nothing will actually come of it.
Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
On Sat, May 13, 2017 at 09:32:46AM +0200, Michał Górny wrote: > On pią, 2017-05-12 at 17:42 -0700, Daniel Campbell wrote: > > On 05/11/2017 12:51 AM, Michał Górny wrote: > > > In fact, I'm personally leaning towards not building docs at all > > > in ebuilds. It's practically a wasted effort since most of the time > > > users read docs online anyway. > > > > I believe that's a little myopic; a user (or even developer) may not > > have Internet access all the time, or may not have it in their primary > > development environment. Having a copy of the docs locally (the entire > > point of USE="doc") is super valuable to have when you're away from the > > network. I'm sure I'm not alone as one of the people who uses the flag > > and appreciates the work that goes into making sure said flag works. > > > > Sure, we could yank out every single USE="doc", but then we lose a nice > > feature of the tree and users are back to either (a) trawling the Web to > > find the project site, then hope they have docs in a separate download, > > or (b) we end up with foo+1 packages, one extra for any package that has > > documentation. Neither are particularly good solutions; Debian has done > > the latter and it results in a huge number of packages for little gain. > > The Python team mostly focuses on providing packages for dependencies of > other Gentoo packages, not direct Python development. We do not have > the manpower to go above that. > > -- > Best regards, > Michał Górny Ah, well that at least explains why you're not interested in it. Dependency management alone can be tough; I've not noticed any Python issues, so it seems like you guys do well. :) If you don't mind me asking, what would it take to solve the USE="doc" issue to the Python team's standard? I have some personal interest in Python and wouldn't mind adding 'doc' support for Python packages that users request docs for. Maybe others are willing to join me on this. Is that something we can make happen without getting in anyone's hair? ~zlg signature.asc Description: Digital signature
Re: [gentoo-dev] mingw-w64 crossdev prefix?
On 18/05/17 12:08 AM, Marty Plummer wrote: > On Thu, May 18, 2017 at 06:46:24AM +0300, Alon Bar-Lev wrote: >> Hi, >> You can emerge crossdev and then run crossdev -t x86_64-w64-mingw32 or >> crossdev -t i686-w64-mingw32 >> Alon >> > I'm aware of that, using it. Its simply the fact that its fairly broken > for mingw-w64, and requires quite a lot of hackage to get going. > > What I'm suggesting is the creation of a profile that should handle this > sort of thing for you semi-automatically. Something like the > prefix/windows, but meant more for toolchains. it seems that beber's > portage tree at git.meleeweb.net/gentoo/portage.git already has a setup > similar to what I envision already. > There isn't a whole lot that's broken about it actually -- the main issue is that the default 'embedded' profile doesn't allow all of the variable overrides in it that are necessary for the crossdev to work properly. See bug http://bugs.gentoo.org/487310 The crossdev that's created will provide all the necessary profile overrides to allow you to emerge the things you want, and of course compile your own things as well. There's no need for a special prefix (or 'prefix/*' profile) in order to support this, IMO, once the embedded profile permits the overrides necessary to the ARCH, ELIBC, and KERNEL variables that the crossdev tool already sets. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] dev-libs/libressl: mingw-w64 build calls wine
On Thu, May 18, 2017 at 07:16:43AM +0300, Alon Bar-Lev wrote: > On 18 May 2017 at 07:10, Marty Plummer wrote: > > On Thu, May 18, 2017 at 06:53:48AM +0300, Alon Bar-Lev wrote: > >> On 18 May 2017 at 06:54, Marty Plummer wrote: > >> > Greetings, > >> > > >> > As the subject states, compiling dev-libs/libressl for x86_64-w64-mingw32 > >> > target via crossdev ends up calling wine to run checks, which fails with > >> > an access violation, and as such emerge cannot finish. > >> > > >> > Would it be an acceptable change to disable emake check for mingw-w64 > >> > crossdev targets? > >> > > >> > >> Why do you enable tests? > >> > > I did not, there is no use flag for dev-libs/libressl I can use to > > disable tests. if there is a global flag I should disable, I'd be > > greatly appreciative of it. > > > > If you enable tests globally, then you can disable them for a specific > build using: > FEATURES="-test" emerge ... > it seems that dev-libs/libressl does not respect this action, just tried again with FEATURES="-test" and had the same result.
Re: [gentoo-dev] mingw-w64 crossdev prefix?
On Wed, May 17, 2017, at 22:53 CDT, Alon Bar-Lev wrote: > On 18 May 2017 at 06:46, Matthias Maier wrote: >> [2] I had to manually disable libsanitizer for gcc-6.3.0. Just set >> EXTRA_ECONF="--disable-libsanitizer" via env/package.env for the >> cross-x86_64-w64-mingw32/gcc package. > > Hi, > You should use the USE flags and not apply such workarounds, for example: > USE="-sanitizer" crossdev ... Yes, correct. It should read USE="-sanitize" though. Best, Matthias
Re: [gentoo-dev] dev-libs/libressl: mingw-w64 build calls wine
On 18 May 2017 at 07:10, Marty Plummer wrote: > On Thu, May 18, 2017 at 06:53:48AM +0300, Alon Bar-Lev wrote: >> On 18 May 2017 at 06:54, Marty Plummer wrote: >> > Greetings, >> > >> > As the subject states, compiling dev-libs/libressl for x86_64-w64-mingw32 >> > target via crossdev ends up calling wine to run checks, which fails with >> > an access violation, and as such emerge cannot finish. >> > >> > Would it be an acceptable change to disable emake check for mingw-w64 >> > crossdev targets? >> > >> >> Why do you enable tests? >> > I did not, there is no use flag for dev-libs/libressl I can use to > disable tests. if there is a global flag I should disable, I'd be > greatly appreciative of it. > If you enable tests globally, then you can disable them for a specific build using: FEATURES="-test" emerge ...
Re: [gentoo-dev] dev-libs/libressl: mingw-w64 build calls wine
On Thu, May 18, 2017 at 06:53:48AM +0300, Alon Bar-Lev wrote: > On 18 May 2017 at 06:54, Marty Plummer wrote: > > Greetings, > > > > As the subject states, compiling dev-libs/libressl for x86_64-w64-mingw32 > > target via crossdev ends up calling wine to run checks, which fails with > > an access violation, and as such emerge cannot finish. > > > > Would it be an acceptable change to disable emake check for mingw-w64 > > crossdev targets? > > > > Why do you enable tests? > I did not, there is no use flag for dev-libs/libressl I can use to disable tests. if there is a global flag I should disable, I'd be greatly appreciative of it.
Re: [gentoo-dev] mingw-w64 crossdev prefix?
On Thu, May 18, 2017 at 06:46:24AM +0300, Alon Bar-Lev wrote: > Hi, > You can emerge crossdev and then run crossdev -t x86_64-w64-mingw32 or > crossdev -t i686-w64-mingw32 > Alon > I'm aware of that, using it. Its simply the fact that its fairly broken for mingw-w64, and requires quite a lot of hackage to get going. What I'm suggesting is the creation of a profile that should handle this sort of thing for you semi-automatically. Something like the prefix/windows, but meant more for toolchains. it seems that beber's portage tree at git.meleeweb.net/gentoo/portage.git already has a setup similar to what I envision already.
Re: [gentoo-dev] dev-libs/libressl: mingw-w64 build calls wine
On 18 May 2017 at 06:54, Marty Plummer wrote: > Greetings, > > As the subject states, compiling dev-libs/libressl for x86_64-w64-mingw32 > target via crossdev ends up calling wine to run checks, which fails with > an access violation, and as such emerge cannot finish. > > Would it be an acceptable change to disable emake check for mingw-w64 > crossdev targets? > Why do you enable tests?
Re: [gentoo-dev] mingw-w64 crossdev prefix?
On 18 May 2017 at 06:46, Matthias Maier wrote: > [2] I had to manually disable libsanitizer for gcc-6.3.0. Just set > EXTRA_ECONF="--disable-libsanitizer" via env/package.env for the > cross-x86_64-w64-mingw32/gcc package. Hi, You should use the USE flags and not apply such workarounds, for example: USE="-sanitizer" crossdev ... Alon
Re: [gentoo-dev] mingw-w64 crossdev prefix?
Hi there, On Wed, May 17, 2017, at 17:25 CDT, Marty Plummer wrote: > Greetings, > > So, I'm a relatively new gentoo user (as of 2016-12) coming from arch, > and one thing I've noticed is the relative difficulty of setting up a > mingw-w64 cross-compile toolchain and libraries. > > I'm considering the idea of setting up a sort of prefix specifically > with the intent of being used on a 'normal' gentoo system with the sole > purpose of creating 'normal' windows binaries; does anyone have > suggestions/objections about the idea? > > As it currently stands I have to use an archlinux chroot to do my > cross-compiling, and I'd really enjoy to be able to do this sort of > thing without depending on an auxiliary distro. You can find some information on the wiki [1] (warning: I might be a bit outdated). But anyway, just check it for you (I haven't set up a cross compilation toolchain for windows for the last ~7 years): From a plain amd64 stage-3 setting up a mingw-264 environment via: # emerge crossdev # crossdev [...] -t x86_64-w64-mingw32 still works with a minor complication [2]. Please verify that this works and open a bug report for the libsanitizer issue mentioning the workaround [2,3]. After that you end up with a cross-compiler toolchain x86_64-w64-mingw32-* and necessary runtime somewhere in /usr/x86_64-w64-mingw32. You can also use $ x86_64-w64-mingw32-emerge to cross compile libraries/packages for mingw. Keep in mind that a cross compilation toolchain is a bit of a rocky journey. You might have to pin certain versions of libraries/programs, and or manually patch some stuff. Best, Matthias [1] https://wiki.gentoo.org/wiki/Mingw [2] I had to manually disable libsanitizer for gcc-6.3.0. Just set EXTRA_ECONF="--disable-libsanitizer" via env/package.env for the cross-x86_64-w64-mingw32/gcc package. [3] https://bugs.gentoo.org/buglist.cgi?quicksearch=mingw&list_id=3536150 signature.asc Description: PGP signature
Re: [gentoo-dev] mingw-w64 crossdev prefix?
Hi, You can emerge crossdev and then run crossdev -t x86_64-w64-mingw32 or crossdev -t i686-w64-mingw32 Alon On 18 May 2017 at 01:25, Marty Plummer wrote: > > Greetings, > > So, I'm a relatively new gentoo user (as of 2016-12) coming from arch, > and one thing I've noticed is the relative difficulty of setting up a > mingw-w64 cross-compile toolchain and libraries. > > I'm considering the idea of setting up a sort of prefix specifically > with the intent of being used on a 'normal' gentoo system with the sole > purpose of creating 'normal' windows binaries; does anyone have > suggestions/objections about the idea? > > As it currently stands I have to use an archlinux chroot to do my > cross-compiling, and I'd really enjoy to be able to do this sort of > thing without depending on an auxiliary distro. > > Marty. >
[gentoo-dev] [PATCH 1/1] kernel-2.eclass: Handle upstream rc kernel file type and, file location change for versions >= 4.12
For the latest rc kernel release, (4.12-rc1), upstream has decided to
change the way the patch is distributed.
The patch now resides in a git repository and is no longer compressed.
Some discussion can be found here[1] if one is interested. They could
reverse this decision.
This patch handles the change for rc kernels >= 4.12.
[1] https://lkml.org/lkml/2017/5/13/182
Signed-off-by: Mike Pagano
---
eclass/kernel-2.eclass | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index db4a3bf72..52749cda9 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -506,10 +506,20 @@ detect_version() {
OKV_DICT=(["2"]="${KV_MAJOR}.$((${KV_PATCH_ARR} - 1))"
["3"]="2.6.39"
["4"]="3.19")
if [[ ${RELEASETYPE} == -rc ]] || [[ ${RELEASETYPE} == -pre ]];
then
+
OKV=${K_BASE_VER:-$OKV_DICT["${KV_MAJOR}"]}
-
KERNEL_URI="${KERNEL_BASE_URI}/testing/patch-${CKV//_/-}.xz
-
${KERNEL_BASE_URI}/linux-${OKV}.tar.xz"
- UNIPATCH_LIST_DEFAULT="${DISTDIR}/patch-${CKV//_/-}.xz"
+
+ # as of 12/5/2017, the rc patch is no longer offered as
a compressed
+ # file, and no longer is it mirrored on kernel.org
+ if [[ ${KV_MAJOR} -ge 4 ]] && [[ ${KV_PATCH} -ge 12 ]];
then
+
KERNEL_URI="https://git.kernel.org/torvalds/p/v${KV}/v${OKV} ->
patch-${KV}
+
${KERNEL_BASE_URI}/linux-${OKV}.tar.xz"
+
UNIPATCH_LIST_DEFAULT="${DISTDIR}/patch-${CKV//_/-}"
+ else
+
KERNEL_URI="${KERNEL_BASE_URI}/testing/patch-${CKV//_/-}.xz
+
${KERNEL_BASE_URI}/linux-${OKV}.tar.xz"
+
UNIPATCH_LIST_DEFAULT="${DISTDIR}/patch-${CKV//_/-}.xz"
+ fi
fi
if [[ ${RELEASETYPE} == -git ]]; then
--
2.13.0
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead
E-Mail : mpag...@gentoo.org
GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137
Public Key :
http://http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137&op=index
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] mingw-w64 crossdev prefix?
Greetings, So, I'm a relatively new gentoo user (as of 2016-12) coming from arch, and one thing I've noticed is the relative difficulty of setting up a mingw-w64 cross-compile toolchain and libraries. I'm considering the idea of setting up a sort of prefix specifically with the intent of being used on a 'normal' gentoo system with the sole purpose of creating 'normal' windows binaries; does anyone have suggestions/objections about the idea? As it currently stands I have to use an archlinux chroot to do my cross-compiling, and I'd really enjoy to be able to do this sort of thing without depending on an auxiliary distro. Marty.
[gentoo-dev] Last rites: mail-client/squirrelmail
# Thomas Deutschmann (17 May 2017) # Unpatched security vulnerability per bug #616700 # Removal in 30 days. mail-client/squirrelmail -- Regards, Thomas Deutschmann / Gentoo Security Team C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: www-apps/joomla
# Thomas Deutschmann (17 May 2017) # Multiple unpatched security vulnerabilities (see bug #603756, #610696, #612650 ...) # Removal in 30 days. www-apps/joomla -- Regards, Thomas Deutschmann / Gentoo Security Team C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Fixing elasticsearch maintainer
Ohey, as you might have noticed I've just corrected the metadata.xml of all elasticsearch-related packages. For some strange reason I was listed there as maintainer, but since no one wanted to listen to my ideas I guess I wasn't. So now last person who touched it gets stuck with it. Since proxy-maint refuses to be removed from packages (especially since they were unconditionally added to all packages with a non-gentoo-dev maintainer in metadata) they are the de facto maintainers, and overrule everything else. I've tried multiple strategies including removing them from metadata, but ... see app-admin/elasticsearch, proxy-maint is like the toe fungus that always comes back (e.g. commit f0925c10834464e62ce7209f2afa7797b594d350 ) Sometimes it's almost absurdly funny, especially when you commit RESTRICT="test" because tests fail reliably just to have that reverted. (See dev-python/elasticsearch-py ) Bonus mention: bbdc5412061adf598ed935697441a7d6b05f7614 app-admin/logstash-bin: drop old Signed-off-by: Andrew Savchenko That removed the versions I was using, so I better maintain the versions I use in an overlay. Well ok then. Since I, as maintainer, can't ... anything, well [CENSORED] this, now they are your packages. Don't try to reassign or drop them: You've demanded, insisted, to be maintainers ... wish granted. So, err, well, is like ... wtf? I'm not sure how this all makes sense, but it's Not My Problem now. Take care now, bye bye then. Oh, and Erki Ferenc was in metadata too, he's been inactive but told me that he wants to continue maintaining these packages in the near future. If he asks I'd recommend adding him back. Patrick P.S. If this sounds a bit incoherent, well ... the whole situation is, I have no idea what's going on or why I was in metadata ;)
[gentoo-dev] net-mail/cyrus-imap-admin dev-libs/cyrus-imap-dev Mask for removal
# Eray Aslan (17 May 2017) # Functionality merged to cyrus-imapd-2.5.x series. # cyrus-imapd-2.5.10 was stabilized in Jan 2017. Upgrade # if you haven't already done so. Removal in 30 days. net-mail/cyrus-imap-admin dev-libs/cyrus-imap-dev # Masking for end-user convenience. Will be dropped once # net-mail/cyrus-imap-admin and dev-libs/cyrus-imap-dev # are tree cleaned. =net-mail/cyrus-imapd-2.4* https://bugs.gentoo.org/show_bug.cgi?id=618716 -- Eray
