Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
El jue, 01-01-1970 a las 00:00 +, Ulrich Mueller escribió: > > > > > > On Mon, 17 Jul 2023, Mike Gilbert wrote: > > > On Mon, Jul 17, 2023 at 4:27 PM Sam James wrote: > > > > Haven't we been keeping these because we still need to decide > > > > on a > > > > policy about what to do with dead acct-*/* packages? > > > > > > Right. https://bugs.gentoo.org/781881 is still open. Flow could > > > ping > > > the QA team and ask if it should be closed, given the opinion > > > there > > > seems to be that there's no need to keep them, but I think it's > > > wrong > > > to do this pre-empting a policy decision, given it essentially > > > forces > > > the "don't keep them" path. > > > The bug has been open for several months without comment. If a > > policy > > were going to materialize, I think it would have happened by now. > > > Forcing the issue by sending this last rites notice seems > > acceptable > > to me. > > I'd say we remove the packages, because system user and group ids are > a somewhat scarce resource. I agree because of the same reasons signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/3] autotools.eclass: Downgrade eqawarn for renaming configure.in
El dom, 28-05-2023 a las 15:16 +0200, Ulrich Müller escribió: > At this point, almost all upstreams will have switched to > configure.ac. > Therefore, configure.in is most likely an indication of an inactive > upstream, and there is no useful way for the ebuild maintainer to > silence the warning (other than the ebuild renaming the file). > > Keep the message as einfo, so there is still an indication that the > file > was renamed. > > Bug: https://bugs.gentoo.org/426262 > Signed-off-by: Ulrich Müller > --- > eclass/autotools.eclass | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass > index 91046b9f82f3..3a040b863eea 100644 > --- a/eclass/autotools.eclass > +++ b/eclass/autotools.eclass > @@ -400,7 +400,7 @@ eautoconf() { > *) > # Move configure file to the new > location only on newer EAPIs to ensure > # checks are done rather than > retroactively breaking ebuilds. > - eqawarn "Moving configure.in to > configure.ac (bug #426262)" > + einfo "Moving configure.in to > configure.ac (bug #426262)" > mv configure.{in,ac} || die > ;; > esac LGTM Thanks! signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: sys-power/dptfxtract
# Pacho Ramos (2023-02-27) # No longer needed by thermald-2, discontinued by upstream # Removal: 2023-03-29. Bug #898164. sys-power/dptfxtract signature.asc Description: This is a digitally signed message part
[gentoo-dev] desktop.eclass: allow 1024 as a size for icons
Hello, As discussed in https://bugs.gentoo.org/888635 , 1024x1024 icons are starting to be deployed in some apps as they start to be used in MacOSX environment. Some weeks ago I needed to skip their installation for net-im/rocketchat-desktop-bin and I saw that net-analyzer/wireshark is workarounding the problem by manually installing them without desktop.eclass helpers. I would then simply add 1024 to the list of allowed sizes too Thanks diff --git a/desktop.eclass~ b/desktop.eclass index aa1b9ac..ea5c84c 100644 --- a/desktop.eclass~ +++ b/desktop.eclass @@ -311,7 +311,7 @@ _iconins() { size=${2} fi case ${size} in - 16|22|24|32|36|48|64|72|96|128|192|256|512) + 16|22|24|32|36|48|64|72|96|128|192|256|512|1024) size=${size}x${size};; symbolic|scalable) ;; @@ -369,7 +369,7 @@ _iconins() { #!!! must specify to install into /usr/share/icons/... !!! #size of the icon, like 48 or 48x48 #supported icon sizes are: -#16 22 24 32 36 48 64 72 96 128 192 256 512 scalable +#16 22 24 32 36 48 64 72 96 128 192 256 512 1024 scalable # -c, --context #defaults to "apps" # -t, --theme signature.asc Description: This is a digitally signed message part
[gentoo-dev] profiles/targets/desktop: enable "sound" USE by default
This morning I was surprised about a clanlib game consumer no having sound, and I noticed sound USE flag wasn't enabled. I think "sound" should be expected on most "desktop" systems. Any thoughts on enabling it by default on these profiles? Thanks signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: net-wireless/bluez-hcidump
# Pacho Ramos (2022-12-18) # Dead for ages, still included and barely maintained in bluez[deprecated]. # See bug #885459 # Removal: 2023-01-17. Bug #885459. net-wireless/bluez-hcidump signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: app-admin/abrt, app-admin/gnome-abrt, dev-libs/libreport, dev-libs/satyr
# Pacho Ramos (2022-09-18) # ABRT environment keeps breaking more and more on non-Fedora systems. # Removal: 2022-10-18. Bugs #849305, #849092, #849095, #713858. app-admin/abrt app-admin/gnome-abrt dev-libs/libreport dev-libs/satyr signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: media-sound/pulseaudio-modules-bt
# Pacho Ramos (2022-09-18) # Unmaintained for a long time and unneeded with current pulseaudio and # pipewire versions. # Removal: 2022-10-18. media-sound/pulseaudio-modules-bt signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/5] ninja-utils.eclass: Support dev-util/samurai
El lun, 09-05-2022 a las 13:50 +0200, Pacho Ramos escribió: > El dom, 08-05-2022 a las 23:07 +, Sam James escribió: > > From: orbea > > > > samurai is a ninja-compatible build tool written in C which > > works with cmake, meson and other users of ninja. > > > > It is feature-complete and supports most of the same options > > as ninja. > > > > Signed-off-by: orbea > > Signed-off-by: Sam James > > --- > > eclass/ninja-utils.eclass | 24 +++- > > 1 file changed, 23 insertions(+), 1 deletion(-) > > > > diff --git a/eclass/ninja-utils.eclass b/eclass/ninja-utils.eclass > > index c5f34934192f..67f7a6b5e8a7 100644 > > --- a/eclass/ninja-utils.eclass > > +++ b/eclass/ninja-utils.eclass > > @@ -26,6 +26,15 @@ esac > > if [[ -z ${_NINJA_UTILS_ECLASS} ]]; then > > _NINJA_UTILS_ECLASS=1 > > > > +# @ECLASS_VARIABLE: NINJA > > +# @PRE_INHERIT > > +# @DEFAULT_UNSET > > +# @DESCRIPTION: > > +# Specify a compatible ninja implementation to be used by eninja. > > +# At this point only "ninja" and "samu" are supported. > > +# The default is set to "ninja". > > +: ${NINJA:=ninja} > > + > > # @ECLASS_VARIABLE: NINJAOPTS > > # @DEFAULT_UNSET > > # @DESCRIPTION: > > @@ -35,6 +44,19 @@ _NINJA_UTILS_ECLASS=1 > > > > inherit multiprocessing > > > > +case "${NINJA}" in > > + ninja) > > + NINJA_DEPEND=">=dev-util/ninja-1.8.2" > > + ;; > > + samu) > > + NINJA_DEPEND="dev-util/samurai" > > + ;; > > + *) > > + eerror "Unknown value for \${NINJA}" > > + die "Value ${NINJA} is not supported" > > + ;; > > +esac > > + > > Personally I would add "samurai" as value instead of the abbreviated "samu" > form > (that could come from other words than "samurai")... but has you wish :), it > is > only a cosmetic change anyway > > Thanks > > *as you wish signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/5] ninja-utils.eclass: Support dev-util/samurai
El dom, 08-05-2022 a las 23:07 +, Sam James escribió: > From: orbea > > samurai is a ninja-compatible build tool written in C which > works with cmake, meson and other users of ninja. > > It is feature-complete and supports most of the same options > as ninja. > > Signed-off-by: orbea > Signed-off-by: Sam James > --- > eclass/ninja-utils.eclass | 24 +++- > 1 file changed, 23 insertions(+), 1 deletion(-) > > diff --git a/eclass/ninja-utils.eclass b/eclass/ninja-utils.eclass > index c5f34934192f..67f7a6b5e8a7 100644 > --- a/eclass/ninja-utils.eclass > +++ b/eclass/ninja-utils.eclass > @@ -26,6 +26,15 @@ esac > if [[ -z ${_NINJA_UTILS_ECLASS} ]]; then > _NINJA_UTILS_ECLASS=1 > > +# @ECLASS_VARIABLE: NINJA > +# @PRE_INHERIT > +# @DEFAULT_UNSET > +# @DESCRIPTION: > +# Specify a compatible ninja implementation to be used by eninja. > +# At this point only "ninja" and "samu" are supported. > +# The default is set to "ninja". > +: ${NINJA:=ninja} > + > # @ECLASS_VARIABLE: NINJAOPTS > # @DEFAULT_UNSET > # @DESCRIPTION: > @@ -35,6 +44,19 @@ _NINJA_UTILS_ECLASS=1 > > inherit multiprocessing > > +case "${NINJA}" in > + ninja) > + NINJA_DEPEND=">=dev-util/ninja-1.8.2" > + ;; > + samu) > + NINJA_DEPEND="dev-util/samurai" > + ;; > + *) > + eerror "Unknown value for \${NINJA}" > + die "Value ${NINJA} is not supported" > + ;; > +esac > + Personally I would add "samurai" as value instead of the abbreviated "samu" form (that could come from other words than "samurai")... but has you wish :), it is only a cosmetic change anyway Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] readme.gentoo-r1.eclass: Document the DOC_CONTENTS variable
El sáb, 01-01-2022 a las 12:04 +0100, Ulrich Müller escribió: > This fixes a spurious "UnusedInherits" warning from pkgcheck. > > Signed-off-by: Ulrich Müller > --- > eclass/readme.gentoo-r1.eclass | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/eclass/readme.gentoo-r1.eclass b/eclass/readme.gentoo-r1.eclass > index 3ad36fac2588..0d302179127b 100644 > --- a/eclass/readme.gentoo-r1.eclass > +++ b/eclass/readme.gentoo-r1.eclass > @@ -1,4 +1,4 @@ > -# Copyright 1999-2021 Gentoo Authors > +# Copyright 1999-2022 Gentoo Authors > # Distributed under the terms of the GNU General Public License v2 > > # @ECLASS: readme.gentoo-r1.eclass > @@ -25,6 +25,11 @@ case ${EAPI} in > *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; > esac > > +# @ECLASS-VARIABLE: DOC_CONTENTS > +# @DEFAULT_UNSET > +# @DESCRIPTION: > +# The information that is used to create the README.gentoo file. > + > # @ECLASS-VARIABLE: DISABLE_AUTOFORMATTING > # @DEFAULT_UNSET > # @DESCRIPTION: LGTM Thanks! signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] USE-flag gnome-keyring isn't accurate anymore
El jue, 23-12-2021 a las 17:46 -0500, Matt Turner escribió: > On Thu, Dec 23, 2021 at 4:36 PM tastytea wrote: > > I think “secret” may be too generic and “libsecret” is not ideal in case > > an implemention comes along that is named differently. How about > > “secret-service”? > > I think this is a good idea. > And "keyring"? I am not sure if users not familiar with "libsecret" will understand what "secret*" means in this context signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item
El jue, 25-11-2021 a las 09:20 -0500, Mike Gilbert escribió [...] > I don't like the phrase "forcefully downgraded" here. This implies > > > that something happened without the user's consent. emerge would have > > > informed them of the downgrade before it happened. I would suggest > > > removing the word "forcefully" from these paragraphs. > > > > If you do a normal world upgrade, this is the default portage behavior, > > not? I.e. package manager will downgrade if you don't stop. And > > especially on servers, people tend to use cronjobs/scripts to do that... > > Something happening by default is not the same as forcing it to happen. > > Using a cron job or other blind automation to do package upgrades on > any production system is a bad idea. We certainly do not recommend > that to people, nor force them to do it. > > As a side note, maybe ebuild should add sanity checks (like those from glibc) to prevent downgrades, otherwise people could still accidentally hit the issue Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval
El jue, 11-11-2021 a las 12:48 +0100, Ulrich Mueller escribió: > > > > > > On Thu, 11 Nov 2021, Florian Schmaus wrote: > > > > We could: > > > - Open some part of the range between 500 and 1000. For example, > > > 500..799, which would leave 200 IDs for dynamic allocation. > > > +1, since I am not aware of any significant downsides doing so. > > > Could you elaborate why the range 500-799 only leaves us with 200 IDs? > > We still need some range for dynamic allocation. Currently that is > 500..999, and would be reduced to 800..999. That seems to be on the low > side already. > > In any case, 300 additional IDs may not be future proof at the rate > we're currently allocating them. So I wonder if we shouldn't move to > above 6 immediately, or alternatively, give up the whole concept. > > Ulrich Personally I would move to >6 and keep the 300 additional IDs for the case some software really really needs them signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
El mié, 03-11-2021 a las 21:15 -0500, John Helmert III escribió: > On Thu, Nov 04, 2021 at 12:09:28AM +, Sam James wrote: > > On 4 Nov 2021, at 00:02, Sam James wrote: > > > > On 3 Nov 2021, at 23:53, Aaron Bauman wrote: > > > > Is that where the policy belongs? > > > > If so, shouldn't the council update it based on their decisions? > > > > "patches are welcome" doesn't fit every scenario. > > > Got to agree here. If there's a gap in the documentation, > > > let's file a bug -- irrespective of if someone is going to give > > > a patch. > > > Just commenting this on the ML means it'll get lost > > > and we'll forget about it... > > > > Filed https://bugs.gentoo.org/821553. Please > > feel free to clarify it. > > Thank you! Many of us apparently have differing interpretations of the > policy (and it's somewhat hidden), so a clear policy in an obvious > place will be a huge improvement! I haven't tried yet as, fortunately, I have been able to deal with the conflicts most of the times but, I was wondering if one workaround would be to simply try to use emerge-webrsync --revert= option. That way, people could try to upgrade their old systems going from the oldest tree to, for example, the tree from August of this year. Later they could update to a newer snapshot and follow until the end signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [PATCH v2 2/2] readme.gentoo-r1.eclass: Standardize EAPI guard
El mar, 17-08-2021 a las 06:51 +0200, Ulrich Müller escribió: > Signed-off-by: Ulrich Müller > --- > eclass/readme.gentoo-r1.eclass | 12 +++- > 1 file changed, 3 insertions(+), 9 deletions(-) > > diff --git a/eclass/readme.gentoo-r1.eclass b/eclass/readme.gentoo-r1.eclass > index e47e1ac20af6..3ad36fac2588 100644 > --- a/eclass/readme.gentoo-r1.eclass > +++ b/eclass/readme.gentoo-r1.eclass > @@ -20,15 +20,9 @@ > if [[ -z ${_README_GENTOO_ECLASS} ]]; then > _README_GENTOO_ECLASS=1 > > -case "${EAPI:-0}" in > - 0|1|2|3|4|5) > - die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" > - ;; > - 6|7|8) > - ;; > - *) > - die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" > - ;; > +case ${EAPI} in > + 6|7|8) ;; > + *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; > esac > > # @ECLASS-VARIABLE: DISABLE_AUTOFORMATTING LGTM Thanks a lot! signature.asc Description: This is a digitally signed message part
[gentoo-dev] Package up for grabs: sys-boot/woeusb
No longer interested on it, pending a major version bump after upstream splitting: https://github.com/slacka/WoeUSB/issues/209 Thanks a lot for taking it signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
El lun, 08-02-2021 a las 12:19 +0100, Michał Górny escribió: > Hi, > > FYI the developers of dev-python/cryptography decided that Rust is going > to be mandatory for 1.5+ versions. It's unlikely that they're going to > provide LTS support or security fixes for the old versions. > > Since cryptography is a very important package in the Python ecosystem, > and it is an indirect dependency of Portage, this means that we will > probably have to entirely drop support for architectures that are not > supported by Rust. > > According to upstream platform support information [1], this probably > means (eventually) entirely removing the following architectures: > - alpha (stable) > - hppa (stable) > - ia64 (stable) > - m68k (exp) > - s390 (except for s390x, exp) > > Furthermore, the Gentoo Rust packages are missing support > for the following platforms, apparently supported upstream: > - mips (exp) > - ppc (32) (stable) > - sparc (stable) > - s390x (exp) > - riscv (stable) > > Apparently it's non-trivial to bootstrap Rust on these platforms, > so it's unclear when Gentoo is going to start providing Rust on them. > > I've raised a protest on the cryptography bug tracker [2] but apparently > upstream considers Rust's 'memory safety' more important than ability to > actually use the package. > > Honestly, I don't think it likely that Rust will gain support for these > platforms. This involves a lot of work, starting with writing a new > LLVM backend and getting it accepted (getting new code into LLVM is very > hard unless you're doing that on behalf one of the big companies). You > can imagine how much effort that involves compared to rewriting the new > code from Cryptography into C. > > If we can't convince upstream, I'm afraid we'll either have to drop > these architectures entirely or fork Cryptography. > > > [1] https://doc.rust-lang.org/nightly/rustc/platform-support.html > [2] https://github.com/pyca/cryptography/issues/5771 > It will also affect non-SSE2 x86 setups as upstream is neither providing prebuilt package for them :/ https://bugs.gentoo.org/741708 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: sys-power/bbswitch up for grabs
El jue, 14-01-2021 a las 15:15 +0700, Vadim A. Misbakh-Soloviov escribió: > В письме от суббота, 26 декабря 2020 г. 20:22:33 +07 пользователь Piotr > Karbowski написал: > > Hi, > > > > I've been maintaining sys-power/bbswitch in the recent times, however, I > > no longer have any hardware where I can even test it. If anyone sees it > > fit, feel free to grab it and join other maintainers there. I just > > dropped myself out of metadata.xml. > > > > Open bugs: > > - https://bugs.gentoo.org/761370 > > - https://bugs.gentoo.org/613338 > > > > -- Piotr. > > Actually, I've also almost no Optimus hardware ATM. Maybe, I'll drop myself > from metadata too > I joined :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] depend.apache.eclass: support EAPI-7
El mar, 03-11-2020 a las 17:25 +0100, Marek Szuba escribió: > Signed-off-by: Marek Szuba > --- > eclass/depend.apache.eclass | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/eclass/depend.apache.eclass b/eclass/depend.apache.eclass > index 79bfdcc493f..5aa55254268 100644 > --- a/eclass/depend.apache.eclass > +++ b/eclass/depend.apache.eclass > @@ -1,10 +1,10 @@ > -# Copyright 1999-2012 Gentoo Foundation > +# Copyright 1999-2020 Gentoo Authors > # Distributed under the terms of the GNU General Public License v2 > > # @ECLASS: depend.apache.eclass > # @MAINTAINER: > # apache-d...@gentoo.org > -# @SUPPORTED_EAPIS: 0 2 3 4 5 6 > +# @SUPPORTED_EAPIS: 0 2 3 4 5 6 7 > # @BLURB: Functions to allow ebuilds to depend on apache > # @DESCRIPTION: > # This eclass handles depending on apache in a sane way and provides > information > @@ -44,7 +44,7 @@ case ${EAPI:-0} in > 0|2|3|4|5) > inherit multilib > ;; > - 6) > + 6|7) > ;; > *) > die "EAPI=${EAPI} is not supported by depend.apache.eclass" If I remember correctly, some important bugs were pending and affecting to eapi6... then, I guess they would also affect eapi7 https://bugs.gentoo.org/616612 signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] Speeding up Tree Verification
El mar, 30-06-2020 a las 08:20 +0200, Fabian Groffen escribió: > Hi, > > On 29-06-2020 21:13:43 -0500, Sid Spry wrote: > > Hello, > > > > I have some runnable pseudocode outlining a faster tree verification > > algorithm. > > Before I create patches I'd like to see if there is any guidance on making > > the > > changes as unobtrusive as possible. If the radical change in algorithm is > > acceptable I can work on adding the changes. > > > > Instead of composing any kind of structured data out of the portage tree my > > algorithm just lists all files and then optionally batches them out to > > threads. > > There is a noticeable speedup by eliding the tree traversal operations which > > can be seen when running the algorithm with a single thread and comparing it > > to > > the current algorithm in gemato (which should still be discussed here?). > > I remember something that gemato used to use multiple threads, but > because it totally saturated disk-IO, it was brought back to a single > thread. People were complaining about unusable systems. > > In any case, can you share your performance results? What speedup did > you see, on warm and hot FS caches? Which type of disk do you use? > > You could compare against qmanifest, which uses OpenMP-based > paralllelism while verifying the tree. On SSDs this does help. > > Thanks, > Fabian I am talking only based on my own experience but, at least on my case, there are noticeable differences between I/O schedulers. That is something that maybe could affect that tests... with latest kernels we only have noop, deadline (default) and bfq... in my case bfq works far better for keeping the system responsible (on both, rotational and SSDs). But you can test different combinations to see the one that fits better for you. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
El sáb, 06-06-2020 a las 15:09 -0400, Aaron Bauman escribió: > On Sat, Jun 06, 2020 at 02:50:31PM -0400, Aaron Bauman wrote: > > All, the graphics project has now been disbanded. > > > > All packages have been reassigned to maintainer-needed. Bugs will be > > reassigned soon. > > > > Here are a list of the packages that are now up for grabs: > > > > dev-cpp/pngpp > > To expound on this, the graphics project has a quite a few bugs assigned > to them (169). A few packages have co-maintainers, but these are still > reflected in the metadata as required. > > If anyone else has time to address the bugs or wants to take the package > over please do. > > If you hit a package with a co-maintainer then my apologies. > I think this is the list of completely unmaintained packages now (indeed most of them, around 100) :) dev-cpp/pngpp media-gfx/apng2gif media-gfx/apngasm media-gfx/apngdis media-gfx/apngopt media-gfx/autopano-sift-C media-gfx/cellwriter media-gfx/chafa media-gfx/cptutils media-gfx/darktable media-gfx/dcraw media-gfx/duhdraw media-gfx/enblend media-gfx/exact-image media-gfx/exif media-gfx/fim media-gfx/fr0st media-gfx/gif2apng media-gfx/gif2png media-gfx/gifsicle media-gfx/gimageview media-gfx/gmic media-gfx/gnofract4d media-gfx/graphicsmagick media-gfx/grub-splashes media-gfx/gtkimageview media-gfx/hugin media-gfx/icon-slicer media-gfx/igal media-gfx/imagemagick media-gfx/jhead media-gfx/jigl media-gfx/jpeginfo media-gfx/jpegoptim media-gfx/jpegpixi media-gfx/libimagequant media-gfx/luminance-hdr media-gfx/mandelbulber media-gfx/metapixel media-gfx/mscgen media-gfx/nvidia-cg-toolkit media-gfx/openclipart media-gfx/panini media-gfx/pdf2svg media-gfx/png2ico media-gfx/pngcheck media-gfx/pngcrush media-gfx/pngquant media-gfx/pngrewrite media-gfx/povtree media-gfx/pqiv media-gfx/pqstego media-gfx/qiv media-gfx/qvv media-gfx/raw-thumbnailer media-gfx/rotoscope media-gfx/scantailor-advanced media-gfx/scour media-gfx/sfftobmp media-gfx/sxiv media-gfx/tintii media-gfx/tuxpaint-stamps media-gfx/tuxpaint media-gfx/ufraw media-gfx/uniconvertor media-gfx/wkhtmltopdf media-gfx/xli media-gfx/xloadimage media-gfx/xzgv media-libs/cimg media-libs/esdl media-libs/flickcurl media-libs/gd media-libs/giblib media-libs/giflib media-libs/imlib media-libs/jbigkit media-libs/jpeg media-libs/lensfun media-libs/libexif-gtk media-libs/libexif media-libs/libfpx media-libs/libheif media-libs/libicns media-libs/libjpeg-turbo media-libs/libmng media-libs/libpano13 media-libs/libpgf media-libs/libpqstego media-libs/libraw media-libs/netpbm media-libs/opencolorio media-libs/openimageio media-libs/openjpeg media-libs/pnglite media-libs/stimg media-libs/tiff media-libs/urt virtual/imagemagick-tools virtual/jpeg-compat virtual/jpeg x11-misc/gromit x11-misc/shutter signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
El sáb, 06-06-2020 a las 14:50 -0400, Aaron Bauman escribió: > All, the graphics project has now been disbanded. > > All packages have been reassigned to maintainer-needed. Bugs will be > reassigned soon. > > Here are a list of the packages that are now up for grabs: > [...] I have seen that many of them already have maintainers or co-maintainers, maybe listing only those that are going to maintainer-needed would be more useful to catch packages needing attention Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About merging "ayatana", "indicator", "libindicate", "appindicator" in one global USE flag
El jue, 02-04-2020 a las 16:28 +0200, Pacho Ramos escribió: > Hello, > > I was reviewing about how to enable globally on my system the usage of > libappindicator and I realized that we have multiple names for that in the > tree. > "ayatana" is the only global one, while other packages are using "indicator", > "libindicate", "appindicator"... > > Personally I would merge all them in only one, and I wonder if maybe > "indicator" > or "appindicator" would be more meaningful for most users than "ayatana", what > do you think? > > Thanks Personally I would opt for global "appindicator" as it seems to be more widely used and I think it is a bit more self-explanatory :/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] About merging "ayatana", "indicator", "libindicate", "appindicator" in one global USE flag
Hello, I was reviewing about how to enable globally on my system the usage of libappindicator and I realized that we have multiple names for that in the tree. "ayatana" is the only global one, while other packages are using "indicator", "libindicate", "appindicator"... Personally I would merge all them in only one, and I wonder if maybe "indicator" or "appindicator" would be more meaningful for most users than "ayatana", what do you think? Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: games-misc/OilWar
El sáb, 21-03-2020 a las 22:47 +0100, Jonas Stein escribió: > profiles: Last rite games-misc/OilWar > > Package masked for removal. Broken SRC_URI, > Bug: https://bugs.gentoo.org/458662 > > -- > Best regards, > Jonas Stein > As far as I remember, if the only issue with the package is that upstream is dead, we can simply point to https://wiki.gentoo.org/wiki/No_homepage and rely on our mirrors for the source files (as the package is GPL-2 and has no mirror restriction) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [PATCH] profiles: Enable USE=user-session on systemd profiles
El sáb, 21-03-2020 a las 09:01 -0400, Mike Gilbert escribió: > On Sat, Mar 21, 2020 at 6:43 AM Mart Raudsepp wrote: > > Ühel kenal päeval, L, 21.03.2020 kell 11:16, kirjutas Pacho Ramos: > > > I agree, I see that also Debian is applying it unconditionally even > > > when running > > > systemd > > > > But I assume it would be a problem with USE=systemd + USE=-user-session > > dbus, so how about instead of this profile business, we then just go > > with: > > > > * Revbump bluez to drop IUSE=user-session, unconditionally apply the > > patch and change the dbus dep in systemd conditional to > > > =sys-apps/dbus-1.6:=[user-session(+)] > > * Fix bluez USE=systemd handling in above revbump as well: --enable- > > systemd should always be passed, not controlled by a USE=systemd, > > because all it appears to do is decide whether to install systemd > > service files, and that should be always done per the small files > > policy. > > > > * Revbump dbus, dropping user-session IUSE and unconditionally passing > > --enable-user-session > > I think we should probably move it behind USE=systemd. It should > probably be that way already, but I missed it when adding the > user-session flag to the dbus ebuild. > > There is a quite a bit of conditionally compiled code in dbus-daemon > that gets disabled if --disable-systemd is passed to configure. I > would guess that dbus.service will not function properly if this code > is not enabled. > > Since we are dropping user-session from IUSE, the following should suffice: > > $(use_enable systemd user-session) > > > * After some time (dbus revision with IUSE=user-session has been gone > > for a while), remove all of the IUSE=systemd handling from bluez, as > > the user-session matching enforcement isn't needed anymore (and the > > configure systemd conditional has been nuked per above) > > * At that point the package.use entries can be removed altogether as > > well, instead of migrating to systemd target profile. > > Agreed on the rest of the plan. Yes, we can try in that way signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [PATCH] profiles: Enable USE=user-session on systemd profiles
El jue, 19-03-2020 a las 10:35 -0400, Mike Gilbert escribió: > On Thu, Mar 19, 2020 at 9:41 AM Mart Raudsepp wrote: > > Ühel kenal päeval, K, 18.03.2020 kell 16:43, kirjutas Mike Gilbert: > > > Seems good to me in principle, but I'm not sure it is something we > > > > should do until we haven't promoted this into a global USE flag. > > > > > > An alternative would be to add entries in package.use. > > > > Yeah, that'd be what it is now, just done in systemd profile, not most > > of the separate systemd profiles. > > > > > > With the disclaimer of not knowing anything about dbus[user- > > > > session] on > > > > a non-systemd system - maybe it's just time to make user-session > > > > unconditionally enabled on dbus (and then bluez) instead? > > > > All it seems to do (on a very quick look) is install some extra > > > > systemd > > > > files - can't they just be always installed (by always passing -- > > > > enable-user-session) and call it a day? > > > > > > It looks like user-session has no effect if systemd is not in use. > > > > > > On systems running systemd, having the units installed automatically > > > enables the systemd user bus, and the only way to disable it is to > > > mask the units. Having the user bus enabled generally prevents > > > display > > > managers and startx from starting individual session buses, since > > > they > > > will use the user bus instead. That's probably fine, but I wanted to > > > note it. > > > > So how about we try to just always enable this instead in dbus and > > bluez? Anyone got any objections, provided the below can be handled? > > > > I peeked at bluez, and there USE=user-session exists to apply a patch > > to unbreak things when user-session is disabled. Unfortunately it seems > > to be needed there for non-systemd systems as well. I think we should > > be able to figure things out to work in all situations there, or make > > it be applied for USE=-systemd only (that's already the case there, > > just it is not applied for USE="systemd -user-session" right now). > > I think we can apply > 0001-Allow-using-obexd-without-systemd-in-the-user-session-r2.patch > unconditionally. > > The patched unit should work just fine with systemd, provided the user > bus is available. > I agree, I see that also Debian is applying it unconditionally even when running systemd signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH news] 2020-02-06-python-2-7-eol: news item for py2.7 EOL
El mié, 05-02-2020 a las 22:20 +0100, Michał Górny escribió: > [...] > +If you are still using Python 2 for your projects, we strongly recommend > +you to migrate away. For the time being, it is preferable to use > +dev-python/virtualenv or a similar solution rather than ebuilds, > +to install the dependencies for your projects locally. Is there any link that could provide some guidance about the usage of pip+virtualenv? I could only find this https://wiki.gentoo.org/wiki/Pip relying on https://wiki.archlinux.org/index.php/Python/Virtual_environment for virtualenv information. In my case I am used to pip (as regular user of course), but not with virtualenv... then, maybe pointing people to some instructions about how to properly use virtualenv+pip in Gentoo would be useful Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: sci-astronomy/celestia
El sáb, 25-01-2020 a las 22:11 +0100, Lars Wendler escribió: > On Wed, 22 Jan 2020 22:48:22 +0100 Pacho Ramos wrote: > > > El mié, 22-01-2020 a las 10:18 +0100, Lars Wendler escribió: > > > On Wed, 22 Jan 2020 00:56:48 +0100 David Seifert wrote: > > > > > > > # David Seifert (2020-01-21) > > > > # All released versions depend on EOL gtkglext, no revdeps. > > > > # Bug #644334, #694834. Removal in 30 days. > > > > sci-astronomy/celestia > > > > > > I've adjusted the mask to not cover the live ebuild. I am still > > > actively maintaining it and the live ebuild already dropped gtkglext > > > dependency. Once a new release was rolled I will add that to Gentoo. > > > The old releases can go. They're way too old and even don't run > > > anymore with recent nvidia display drivers. > > > > > > Lars > > > > > > > Why not provide a git snapshot? At least in Mageia they are relying in > > one snapshot from the end of Dec 2019 > > > > Thanks > > Hi Pacho, > > once I recover from being sick I can do that. > > Cheers > Lars > Thanks a lot :) Take care signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: sci-astronomy/celestia
El mié, 22-01-2020 a las 10:18 +0100, Lars Wendler escribió: > On Wed, 22 Jan 2020 00:56:48 +0100 David Seifert wrote: > > > # David Seifert (2020-01-21) > > # All released versions depend on EOL gtkglext, no revdeps. > > # Bug #644334, #694834. Removal in 30 days. > > sci-astronomy/celestia > > I've adjusted the mask to not cover the live ebuild. I am still > actively maintaining it and the live ebuild already dropped gtkglext > dependency. Once a new release was rolled I will add that to Gentoo. > The old releases can go. They're way too old and even don't run > anymore with recent nvidia display drivers. > > Lars > Why not provide a git snapshot? At least in Mageia they are relying in one snapshot from the end of Dec 2019 Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH] repoman: add --include-profiles=PROFILES
El mar, 19-11-2019 a las 00:21 +, Sergei Trofimovich escribió: > repoman slows down ~linearly with amount of profiles being scanned. > In case of amd64 we have 28 stable profiles. > > To speed up processing and fit into time budged of various CIs we can > split the work across different processes that handle different profiles. > > Example benchmark on ::haskell overlay: > $ ./repoman full --include-arches=amd64 > ~65 minutes > $ ./repoman full --include-profiles=default/linux/amd64/17.0 > ~4 minutes > This allows for a crude sharding of work across processes and allows for > cheap tree-wide scans for early failures. > Just for knowing (as I guess there is a technical issue preventing that), why repoman is not trying to check one profile per core in parallel by default by itself? Thanks a lot for the info :) signature.asc Description: This is a digitally signed message part
[gentoo-dev] net-print/cndrvcups* up for grabs
Hello I almost lost access to the unique printer that was relying on this driver. Also, even if the current latest version was still working there, it will need a major update to newer cnRdrvcups driver sooner or later https://aur.archlinux.org/packages/cnrdrvcups-lb/ https://www.canon-europe.com/support/products/imagerunner/imagerunner-1730i.html?type=drivers=en=linux Hence, the following packages are up for grabs now net-print/cndrvcups-common-lb net-print/cndrvcups-lb Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] use.desc: Introduce global USE=magic
El dom, 11-08-2019 a las 13:21 +0200, Michał Górny escribió: > USE=magic is currently used consistently by 12 packages: > > app-arch/engrampa[magic] Enable filetype auto-detection via > sys-apps/file > app-editors/nano[magic] Add magic file support (sys-apps/file) to > automatically detect appropriate syntax highlighting > app-misc/vifm[magic] Use libmagic to determine mimetypes > app-misc/worker[magic] Add magic file support from sys-apps/file to > automatically detect file types > app-text/zathura[magic] Use libmagic to determine mimetypes > media-gfx/qiv[magic] Use libmagic to determine mimetypes > media-libs/libextractor[magic] Enable magic support using sys-apps/file > media-sound/moc[magic] Use libmagic to determine mimetypes > net-misc/gerbera[magic] Use libmagic to determine file types > net-p2p/mldonkey[magic] enable use of libmagic > sci-geosciences/viking[magic] Use libmagic to determine mimetypes > www-servers/pshs[magic] Enable automatic detection of Content-Type using > libmagic (sys-apps/file) It seems it should also cover, if possible, this to packages that use an alternative name: dev-python/jira:filemagic - Include filemagic support (for identifying uploaded filetypes) dev-vcs/git-annex:magicmime - Use libmagic to determine file MIME types signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 6/9] acct-{group,user}.eclass: WIP eclasses to maintain users/groups
El mié, 05-06-2019 a las 11:12 +0200, Michał Górny escribió: > [...] > +# Then you add appropriate dependency to your package. The dependency > +# type(s) should be: > +# - DEPEND (+ RDEPEND) if the group is already needed at build time, > +# - RDEPEND if it is needed at install time (e.g. you 'fowners' files > +# in pkg_preinst), > +# - PDEPEND if it is only needed at runtime. Maybe is a stupid question but, why is PDEPEND preferred over RDEPEND for packages needing the group only at runtime? If I don't misremember, PDEPEND was meant to be used to avoid circular deps issues, while using RDEPEND otherwise Thanks :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] How to deal with defunct projects (whose purpose makes sense)?
El jue, 28-03-2019 a las 15:53 +0100, Michał Górny escribió: > Hello, > > In context of the recent plan of disbanding the Samba team, I'd like to > ask for better ideas on how to deal with projects that technically make > sense but are currently dead/defunct. This means that either they have > no members, all their members are inactive or simply don't want to work > on the specific project anymore. > > Of course, the first step is to look for new project members. However, > let's assume we've already done that and unsuccessfully. What should > happen next? > > So far I've been leaning towards disbanding the project and moving > packages to maintainer-needed. This has the advantage of clearly > indicating that those packages are unmaintained, with all the common > implications of that. > > However, it also has been pointed out that this frequently 'ungroups' > packages while being maintained by a single project makes sense for > them. I don't really have a strong opinion on this -- especially that > sometimes this actually helped people decide to take at least some of > the packages. On the other hand, Ada is an example of project that has > been recreated after being disbanded. > > Do you have any suggestions how we could effectively achieve the effect > similar to 'maintainer-needed' without disbanding projects? > Personally I would keep moving them to maintainer-needed. If some packages really need to be bumped in sync, we can add a comment to the affected ebuilds to remember it for any developer taking the package or going to fix some issue for it. About recreating the project after, it's ok for me as soon as the new project has active people for it. Regards signature.asc Description: This is a digitally signed message part
[gentoo-dev] Lastrites: x11-libs/gksu, x11-libs/libgksu, dev-java/ant-nodeps, dev-java/ant-trax, app-admin/localepurge, net-p2p/ppcoind, media-libs/libptp2, sci-libs/spqr...
# Pacho Ramos (11 Nov 2018) # Dead for years (#425156) with security issues (#534540). Removal in a # month. x11-libs/gksu x11-libs/libgksu # Pacho Ramos (11 Nov 2018) # Both are part of ant-core for years (#466558). Removal in a month. dev-java/ant-nodeps dev-java/ant-trax # Pacho Ramos (11 Nov 2018) # Unmaintained for years, buggy (#183273, #491010, #605544). You can rely on # INSTALL_MASK to skip unwanted locales and install only foo locale: # INSTALL_MASK="/usr/share/locale -/usr/share/locale/foo" # Removal in a month. app-admin/localepurge # Pacho Ramos (11 Nov 2018) # Unmaintained, really old version in the tree with someone needs to get # bumped (#622572). Removal in a month. net-p2p/ppcoind # Pacho Ramos (11 Nov 2018) # Our current version is broken for ages (#622722), no maintained, needs to # be bumped, no reverse deps in the tree. Removal in a month. media-libs/libptp2 # Pacho Ramos (11 Nov 2018) # Completely broken for a long time and uninstallable (#492484, #585516, # #586582, #627094, #654548). sci-libs/spqr dev-lang/julia sci-libs/suitesparse # Pacho Ramos (11 Nov 2018) # Dead for years, last package depending on old musicbrainz:3 (#629392). # Removal in a month. media-video/gnome-mplayer www-plugins/gecko-mediaplayer # Pacho Ramos (11 Nov 2018) # Upstream dead for years and marked EOL (#629676, #665850). Removal in a # month. dev-db/mysql-proxy # Pacho Ramos (11 Nov 2018) # Unmaintained, fails to build, nothing requires it anymore (#630400). # Removal in a month. app-forensics/libbfio # Pacho Ramos (11 Nov 2018) # Needs someone to finally take care of it, bump it and let it be # installable again (#635476, #645740). Removal in a month. net-analyzer/nessus-bin # Pacho Ramos (11 Nov 2018) # Pending version bump (#648380), doesn't build (#637350). Removal in a # month. sys-apps/likwid # Pacho Ramos (11 Nov 2018) # Doesn't build for a long time (#638096). Removal in a month. games-action/rafkill # Pacho Ramos (11 Nov 2018) # Dead for a long time, failing tests (#638376), nothing requires it # anymore. Removal in a month. dev-python/flask-testing # Pacho Ramos (11 Nov 2018) # Doesn't build for a long time (#638710), nothing requires it. Removal in a # month. app-emulation/vpcs # Pacho Ramos (11 Nov 2018) # Fails to build with current glibc (#638840). Removal in a month. sys-devel/heirloom-devtools # Pacho Ramos (11 Nov 2018) # Fails to build for a long time (#639844). Removal in a month. dev-embedded/scratchbox2 # Pacho Ramos (11 Nov 2018) # Fails to build with current gcc (#640926), file collisions (#630668), no # reverse deps. Removal in a month. media-video/sswf # Pacho Ramos (11 Nov 2018) # Replaced by libunibreak and no reverse deps (#640974). Removal in a month. dev-libs/liblinebreak # Pacho Ramos (11 Nov 2018) # Fails at runtime (#645690). Removal in a month. dev-lang/gnu-smalltalk # Pacho Ramos (11 Nov 2018) # Replaced by dev-db/percona-toolkit, cannot be fetched (#645984). Removal # in a month. dev-db/maatkit # Pacho Ramos (11 Nov 2018) # Unmaintained and buggy (#648204). Removal in a month. mail-filter/razor # Pacho Ramos (11 Nov 2018) # Unmaintained, upstream dead, fails to build (#650084). Removal in a month. sys-power/suspend # Pacho Ramos (11 Nov 2018) # Merged into >=app-portage/gentoolkit-0.4 (#659412). Removal in a month. app-portage/gentoolkit-dev # Pacho Ramos (11 Nov 2018) # Broken since python 3.6 (#659414), buggy (#640372, #607666). Removal in a # month. app-portage/gs-pypi # Pacho Ramos (11 Nov 2018) # Fails at runtime (#661746). Removal in a month. games-roguelike/mangband # Pacho Ramos (11 Nov 2018) # Nobody is taking care of them, use the ones provided by the maintained # sys-kernel/linux-firmware package (#661884). Removal in a month. net-dialup/ueagle-atm net-dialup/ueagle4-atm # Pacho Ramos (11 Nov 2018) # Fails to build (#662000), not compatible with kernel-4, use kernel driver rtsx_pci # instead. Removal in a month. sys-block/rts_pstor # Pacho Ramos (11 Nov 2018) # Fails to run (#662180). Removal in a month. app-text/chm2pdf # Pacho Ramos (11 Nov 2018) # Unmaintained, security issues (#630796, #663164). Removal in a month. dev-db/couchdb # Pacho Ramos (11 Nov 2018) # Unkeyworded since 2008, non-installable (#664680). Removal in a month. sys-fs/devfsd # Pacho Ramos (11 Nov 2018) # Orphan, no reverse deps, dead since 2003 (#665046, #521242). Removal in a # month. app-text/clara # Pacho Ramos (11 Nov 2018) # Merged into >=media-tv/mythtv-29, bug #665924. Removal in a month. media-plugins/mythplugins # Pacho Ramos (11 Nov 2018) # No reverse deps, obsoleted in 2016 (#666130). Removal in a month. dev-python/jenkins-webapi # Pacho Ramos (11 Nov 2018) # Build issues (#666166), upstream dead for years (#619624). Removal in a # month. media-plugins/vdr-image media-plugins/vdr-picselshow # Pacho Ramos (11 Nov 2018) # Dead for years, no reverse deps (#665046). Removal in a month. app-tex
Re: [gentoo-dev] Add GOBIN to ENV_UNSET in make.defaults
El sáb, 20-10-2018 a las 18:59 -0700, Zac Medico escribió: > On 10/20/2018 04:21 AM, Pacho Ramos wrote: > > It seems that random values in GOBIN can affect the building of some > > packages: > > https://bugs.gentoo.org/631776 > > https://bugs.gentoo.org/636506 > > https://bugs.gentoo.org/638572 > > > > I would then append it to ENV_UNSET in make.defaults to get that variable > > unset > > without needing to do the same for every ebuild that could be affected by > > this > > > > Any issues against this? > > Seems reasonable, since the only purpose of GOBIN is to override the > directory where 'go install' will install a command. If we unset it > unconditionally, it means that the location will predictably default to > GOPATH/bin, which is exactly what we want. > > We could handle it in the golang-build_src_install function, but that > wouldn't cover things that call 'go install' via a script or Makefile. > > > Thanks > > Done: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c06caedd7c6bb91be0b8e963eb2 cb98e74448f67 signature.asc Description: This is a digitally signed message part
[gentoo-dev] Lastrites: dev-java/ant-nodeps, dev-java/ant-trax, dev-python/pyramid, dev-libs/libstrl, dev-util/difffilter, app-crypt/tinyca...
# Pacho Ramos (04 Nov 2018) # Both are part of ant-core for years (#466558). Removal in a month. dev-java/ant-nodeps dev-java/ant-trax # Pacho Ramos (04 Nov 2018) # Unmaintained, needs someone to take care of bumping and maintaining it # (#509518). Removal in a month. dev-python/pyramid # Pacho Ramos (04 Nov 2018) # Fails to build (#538174), upstream dead for ages. Removal in a month. dev-libs/libstrl dev-util/difffilter # Pacho Ramos (04 Nov 2018) # Upstream dead, multiple unresolved bugs (#540622). Removal in a month. app-crypt/tinyca # Pacho Ramos (04 Nov 2018) # gitorious was closed (#544812), nothing needs it in the tree and we only # provide a live ebuild. Removal in a month. app-benchmarks/os-autoinst # Pacho Ramos (04 Nov 2018) # Pending version bumps (with security fixes) for a long time (#550188, # #544568, #227993). Removal in a month. www-apps/moinmoin # Pacho Ramos (04 Nov 2018) # Nobody willing to update and maintain this for years (#556306, #554488). # Removal in a month. net-proxy/squidclamav net-proxy/c-icap # Pacho Ramos (04 Nov 2018) # Outdated, doesn't respect CC, installs files in /usr/local (#565894, # #664370). Removal in a month. www-client/dooble # Pacho Ramos (04 Nov 2018) # Outdated, move to media-gfx/slic3r or other online alternatives (#570324). # Removal in a month. media-gfx/replicatorg # Pacho Ramos (04 Nov 2018) # Build issues (#587866), outdated, nothing needs it in the tree. Removal in # a month. dev-libs/libsolv # Pacho Ramos (04 Nov 2018) # Build issues (#590316, #603300), no reverse deps, needs a major version # bump. Removal in a month. dev-lua/lua-openssl # Pacho Ramos (04 Nov 2018) # Upstream dead for ages, crashes (#637286), build issues (#592580). # Migration to Google fork or other alternative will be needed. Removal in a # month. net-misc/tlsdate # Pacho Ramos (04 Nov 2018) # Hard to bump (#480160), uses get_libdir at global scope (#593400). Removal # in a month. net-analyzer/w3af # Pacho Ramos (04 Nov 2018) # pkg_postinst calls pkg_config (#596648), upstream dead for ages. Removal # in a month. sys-auth/bioapi sys-auth/tfm-fingerprint sys-auth/pam_bioapi # Pacho Ramos (04 Nov 2018) # Dead for ages, not needed anymore (#596988). Removal in a month. sys-power/upower-pm-utils # Pacho Ramos (04 Nov 2018) # Broken and outdated (#445476, #448934, #599580). Removal in a month. media-plugins/mediastreamer-silk # Pacho Ramos (04 Nov 2018) # Fails to build (#601886), dead for a long time. Removal in a month. media-gfx/gimmage # Pacho Ramos (04 Nov 2018) # Fringe format, nothing really uses it, upstream disappeared, not really # working for some time (#602938). Removal in a month. media-libs/schroedinger # Pacho Ramos (04 Nov 2018) # Needs someone to maintain it and bump to a snapshot not relying on # gstreamer:0.10 (#610434, #560254). Removal in a month. app-accessibility/pocketsphinx # Pacho Ramos (04 Nov 2018) # Fails to build, hard to bump (#608908). Removal in a month. net-nntp/inn # Pacho Ramos (04 Nov 2018) # Dead since 2005, nobody else still ships it, it creates cruft dirs in / # (#565592). Removal in a month. app-admin/syslogread signature.asc Description: This is a digitally signed message part
[gentoo-dev] Lastrites: sys-cluster/cman and co.
# Pacho Ramos (04 Nov 2018) # Upstream dead for many years and nobody taking care of them, bug #443842, # bug #618050. Removal in a month. sys-cluster/cman sys-cluster/ccs sys-cluster/rgmanager sys-cluster/rgmanager-agents sys-cluster/libdlm sys-cluster/fence-agents sys-cluster/libccs sys-cluster/libccs-perl sys-cluster/libcman sys-cluster/libfence sys-cluster/liblogthread signature.asc Description: This is a digitally signed message part
[gentoo-dev] Lastrites: mail-filter/assp, www-apps/lxr, app-misc/iguanaIR, net-analyzer/nagvis, media-plugins/alsaequal...
# Pacho Ramos (01 Nov 2018) # Outdated, security issues (#629442), dead since 2014 (#405527). # Removal in a month. mail-filter/assp # Pacho Ramos (01 Nov 2018) # Outdated, needs to be bumped to latest release to fix multiple security # bugs (#444368). Removal in a month. www-apps/lxr # Pacho Ramos (01 Nov 2018) # Needs to be bumped (#475330), build issues (#521094), install files in # /dev (#452248), ignores CFLAGS (#452244). Removal in a month. app-misc/iguanaIR # Pacho Ramos (01 Nov 2018) # Needs a major version bump to a version that is security audited # (#477742). Removal in a month. net-analyzer/nagvis # Pacho Ramos (01 Nov 2018) # Buggy (#499298), upstream is dead for a long time, maybe a switch to one # of the existing forks would be needed, abi_x86_32 doesn't work (#524498). # Removal in a month. media-plugins/alsaequal # Pacho Ramos (01 Nov 2018) # Unmaintained, installs files in runtime dirs (#520626), requires old # libosip. Removal in a month. net-misc/siproxd # Pacho Ramos (01 Nov 2018) # Needs a major version bump to work with recent db versions (#529966). # Removal in a month. net-proxy/c-icap-modules # Pacho Ramos (01 Nov 2018) # 2.90 slot of VTE is deprecated for a long time in favor of 2.91, no # reverse deps (#538140). Removal in a month. =x11-libs/vte-0.36.5 # Pacho Ramos (01 Nov 2018) # All this packages are broken and need major version bumps to fix them. See # bug #504114, #486510, #510550, #511096, #517260, #551784, #616490, # net-voip/linphone net-libs/libeXosip net-libs/libosip signature.asc Description: This is a digitally signed message part
[gentoo-dev] Lastrites: media-gfx/splashutils
# Pacho Ramos (21 Oct 2018) # Lots of pending bugs for years, this needs a dedicated maintainer that # fixes them: bug #354157, #354639, #398075, #398077, #417375, #499654, # #539358, #591682, #625798, #639912, #662316, #664270... # Removal in a month. media-gfx/splashutils media-gfx/bootsplash-themes media-gfx/splash-themes-gentoo media-gfx/splash-themes-livecd media-gfx/splash-themes-livedvd signature.asc Description: This is a digitally signed message part
[gentoo-dev] Add GOBIN to ENV_UNSET in make.defaults
It seems that random values in GOBIN can affect the building of some packages: https://bugs.gentoo.org/631776 https://bugs.gentoo.org/636506 https://bugs.gentoo.org/638572 I would then append it to ENV_UNSET in make.defaults to get that variable unset without needing to do the same for every ebuild that could be affected by this Any issues against this? Thanks signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: app-admin/sysrqd app-antivirus/skyldav app-misc/blink1 app-misc/digitemp dev-db/sqldeveloper dev-libs/cyberjack dev-util/sel net-dns/dnscap net-im/mcabber net-libs/loudmouth net-misc/connect net-misc/gwhois sys-apps/dstat sys-auth/ykneo-ccid-tools sys-auth/yubikey-personalization-gui sys-power/sispmctl
[gentoo-dev] Lastrites: net-misc/whatportis
# Pacho Ramos (28 Jun 2018) # Doesn't work at all (#645388). Removal in a month net-misc/whatportis
[gentoo-dev] Lastrites: dev-python/pyrtf
# Pacho Ramos (28 Jun 2018) # Doesn't work, dead since 2005, bug #658984. Removal in a month. dev-python/pyrtf
[gentoo-dev] Lastrites: app-misc/jira-cli
# Pacho Ramos (28 Jun 2018) # Cannot be imported, bug #659410. Removal in a month. app-misc/jira-cli
Re: [gentoo-dev] [PATCH 02/10] gnome2.eclass: move icon handling code to xdg.eclass
El mar, 26-06-2018 a las 20:27 -0500, Marty E. Plummer escribió: > Package-Manager: Portage-2.3.40, Repoman-2.3.9 > --- > eclass/gnome2.eclass | 9 + gnome2.eclass would also need to fix this regression in eapi6 (https://bugs.gent oo.org/613364) and to deprecate ltprune.eclass usage (https://bugs.gentoo.org/65 8638)
Re: [gentoo-dev] [PATCH 1/2] gnome2-utils.eclass: make EAPI 7 ready
El dom, 17-06-2018 a las 19:47 -0500, Marty E. Plummer escribió: > Use ${EROOT%/} whereever possible, as most of the directories and files > used in conjunction with it have a leading /; add missing leading / > where apropriate. Put sys-apps/sed into BDEPEND if EAPI 7, as it need to > be executable on CBUILD. > > Signed-off-by: Marty E. Plummer > Package-Manager: Portage-2.3.40, Repoman-2.3.9 > --- > eclass/gnome2-utils.eclass | 43 +++--- > 1 file changed, 22 insertions(+), 21 deletions(-) > We would need to handle: https://bugs.gentoo.org/615144#c12 to not need to workaround it in gimp ebuild (or any other using their customized "DEPRECATED" macros) forever I have also just seen this bug about needing to use EROOT in some tools: https://bugs.gentoo.org/611030
Re: [gentoo-dev] Lastrites: games-arcade/xevil, x11-plugins/wmlaptop, dev-java/servletapi, dev-java/sun-jacc-api...
El dom, 17-06-2018 a las 16:14 +0300, Mart Raudsepp escribió: > Ühel kenal päeval, P, 17.06.2018 kell 14:24, kirjutas Pacho Ramos: > > # Pacho Ramos (17 Jun 2018) > > # Needs someone to maintain this package and bump it to newer > > versions > > # stopping to rely on dead gstreamer:0.10 (#438972). Removal in a > > month. > > media-video/aravis > > lu_zero bumped this to 0.5.10 with gstreamer:1.0 usage 2 weeks ago.. > I don't know why he didn't check and update bugs. > > > Mart Just unmasked
[gentoo-dev] Lastrites: games-arcade/xevil, x11-plugins/wmlaptop, dev-java/servletapi, dev-java/sun-jacc-api...
# Pacho Ramos (17 Jun 2018) # Doesn't work on amd64, upstream dead for ages, bug #254510 # Removal in a month. games-arcade/xevil # Pacho Ramos (17 Jun 2018) # Doesn't work (#348124), dead since 2004. Removal in a month. x11-plugins/wmlaptop # Pacho Ramos (17 Jun 2018) # Package obsolete since many years ago (#398689). Removal in a month. dev-java/servletapi dev-java/sun-jacc-api # Pacho Ramos (17 Jun 2018) # Needs a major version bump to stop relying on old versions of other libs # (#421427). Removal in a month. dev-java/easyneurons # Pacho Ramos (17 Jun 2018) # Needs someone to maintain this package and bump it to newer versions # stopping to rely on dead gstreamer:0.10 (#438972). Removal in a month. media-video/aravis # Pacho Ramos (17 Jun 2018) # Fails to run because it requires a bundled lib as unmaintained as this # package by upstream (#472752). Removal in a month. net-misc/nemesis # Pacho Ramos (17 Jun 2018) # Upstream dead for ages, relies on dead gstreamer:0.10 (#552528). Removal # in a month. x11-misc/winswitch # Pacho Ramos (17 Jun 2018) # Obsolete package not needed for a long time, bug #559994. Removal in a # month. dev-java/jdom-jaxen =dev-java/jdom-1.0-r4 # Pacho Ramos (17 Jun 2018) # Fails to build, nothing requires it (#561366, #579600, #618936). Removal # in a month. net-misc/openvpn-auth-ldap # Pacho Ramos (17 Jun 2018) # Supposedly working with wxGTK:3.0 but with bugs that upstream never fixed, # this would be the last package still needing old wxGTK:2.8 to workaround # this bugs (#597194). Removal in a month except if someone figures out # about how to solve this bugs. net-p2p/amule # Pacho Ramos (17 Jun 2018) # Upstream dead for a long time, bug #606194. Removal in a month. dev-libs/DirectFB # Pacho Ramos (17 Jun 2018) # Not usable anymore after server shutdown (#608806). Removal in a month. games-fps/postal2mp-demo # Pacho Ramos (17 Jun 2018) # Segfaults at start (#612322). Removal in a month. games-arcade/snake3d # Pacho Ramos (17 Jun 2018) # tests fail with python >= 3.4 (#620082), nothing requires this package, # removal in a month. dev-python/eliot # Pacho Ramos (17 Jun 2018) # Not compatible with recent python versions (#624668), needs a major # version bump. Removal in a month. dev-python/django-two-factor-auth # Pacho Ramos (17 Jun 2018) # Fails to build (#624688). Removal in a month. sci-physics/hoomd-blue # Pacho Ramos (17 Jun 2018) # Upstream dead, relies on obsolete gstreamer:0.10. Please use alternatives # (like soundconverter) instead (#629182). Removal in a month. media-sound/gnac # Pacho Ramos (17 Jun 2018) # Fails to run (#630576). Removal in a month. games-simulation/dangerdeep # Pacho Ramos (17 Jun 2018) # frogr is a good replacement for this old package still relying on dead # gnome2 python bindings (#640046). Removal in a month. media-gfx/postr # Pacho Ramos (17 Jun 2018) # Fails to fetch (#640572). Removal in a month. games-puzzle/triptych-demo # Pacho Ramos (17 Jun 2018) # Fails to fetch (#640584). Removal in a month. games-strategy/gorky17-demo # Pacho Ramos (17 Jun 2018) # Dead since 2013, not compatible with latest profiles (#642568). Removal in # a month net-vpn/miredo # Pacho Ramos (17 Jun 2018) # Fails to build (#642996). Removal in a month. games-engines/gargoyle # Pacho Ramos (17 Jun 2018) # Fails to compile (#648430), crashes from time to time (#222065). Removal # in a month. app-misc/wyrd # Pacho Ramos (17 Jun 2018) # Not compatible with recent perl, not needed by anything in the tree # (#648582). Removal in a month. app-doc/mkdoxy # Pacho Ramos (17 Jun 2018) # Not compatible with recent PHP, upstream dead for ages (#650870, #650934) #, removal in a month. www-apps/gnopaste www-apps/openwebstats # Pacho Ramos (17 Jun 2018) # Upstream dead, security vulnerable (#650936). Removal in a month. www-apps/phprojekt # Pacho Ramos (17 Jun 2018) # Doesn't run, cannot bump it (#651146). Removal in a month. games-emulation/hatari # Pacho Ramos (17 Jun 2018) # Doesn't work even with current PHP versions, upstream dead (#651148), # removal in a month. www-apps/mypictures # Pacho Ramos (17 Jun 2018) # Doesn't work with PHP7, dead upstream (#651184, #651194), removal in a month. www-apps/phpmp www-apps/polarblog # Pacho Ramos (17 Jun 2018) # Multiple bugs (#424383, #554944), upstream dead (#651340). Removal in a # month. net-irc/ircservices # Pacho Ramos (17 Jun 2018) # Dead since 2002, orphan, nothing requires it (#651344). Removal in a # month. app-text/rhyme # Pacho Ramos (17 Jun 2018) # Dead lib not used by anything in the tree (#652186). Removal in a month. net-libs/libwhisker # Pacho Ramos (17 Jun 2018) # Obsolete package for the old documentation system (#653168). Removal in a # month. app-text/gentoo-guide-xml-dtd # Pacho Ramos (17 Jun 2018) # Dead for ages, nothing requires it, needs klibc (that is also completely # unmaintained in our side) (#653390). Removal in a month. sys-b
Re: [gentoo-dev] Current status with openssl-1.1
El sáb, 09-06-2018 a las 10:22 +0200, Lars Wendler escribió: > > [...[ > some point. > > So, basically openssl is the last big showstopper for openssl-1.1 to > get out of p.mask. There are some inofficial patches floating around in > the WWW but each one of them has some issues and they all are not > really small in size. > Last time I checked, the most complete (but still to some degree > broken) patch had 2800+ LOC and was 80K in size. This is definitely > nothing I want to maintain as downstream, left aside the fact that > openssh should not be messed with lightly regarding security > implications. Why don't try to use RedHat/Fedora patch for openssl-1.1 compat? It seems they are taking care of maintaining that patch on their side > > My biggest concern right now is that openssh might still block > openssl-1.1.1 once that got released. openssl-1.1.1 provides TLSv1.3 > which is something we should provide to our users as soon as possible > and is also targeted as next LTS release. > > > > [1] https://bugs.gentoo.org/592438 > [2] https://bugs.gentoo.org/592578 >
Re: [gentoo-dev] rfc: virtual/init for init process
El vie, 27-04-2018 a las 00:48 -0700, Zac Medico escribió: > On 04/26/2018 11:34 PM, Kent Fredric wrote: > > On Thu, 26 Apr 2018 13:35:15 -0700 > > Zac Medicowrote: > > > > > emerge --depclean, resulting in an unbootable system. Just say-in. > > > > And depclean being very verbose doesn't do many favours here either. > > > > ( I regularly do >500 package depcleans and spotting things that aren't > > meant to be > > culled amongst that list is a bit of a challenge )> > > At least for system packages, it will show a warning like the one shown > here: > >https://bugs.gentoo.org/642484#c0 > > Hopefully that message helps those that are paying enough attention. > What can we do for those that overlook the warning message, other than > give them some rescue instructions for making their system boot again? Have you think in changing a bit the behavior of depclean to *not* depclean system packages and ask administrator to do something like "emerge -a --depclean --force" to force the depclean of that packages? That could help to prevent that mistakes I think Thanks
Re: [gentoo-dev] Project:Lisp without members
El mié, 21-03-2018 a las 10:51 +0200, Mart Raudsepp escribió: > Ühel kenal päeval, L, 10.03.2018 kell 13:26, kirjutas Pacho Ramos: > > From now Project:Lisp has no members... that doesn't seem an issue as > > it > > contains multiple subprojects that maintain relevant packages... but, > > for the > > case anyone wants to join the main project... > > https://wiki.gentoo.org/wiki/Project:Lisp > > This is a valid setup of projects to my knowledge. Please correct me if > I'm wrong. Don't undertake parent projects if they have subprojects > with active members please. In other words, please don't undertake a > project if it has active subprojects, if that was your mails intention > here. > https://wiki.gentoo.org/wiki/Project:Lisp even lists subprojects and > their members as part of lisp project. Though it seems to have gotten a > direct member now too to prevent the implicit undertaking intention > (which I think is unnecessary). > > There were no "undertaking intention" for that parent project as the mail states showing no warning about removing it and even suggesting that "it doesn't seem an issue"... the intention was merely to inform people for the case someone wanted to joing the Project
[gentoo-dev] Lastrites: net-dns/hesiod, games-arcade/monkey-bubble, app-shells/scsh-install-lib, dev-db/mysql-udf-infusion...
# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Unresolved security issues (#606652), tests fail (#628622, #337249). # Removal in a month. net-dns/hesiod # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Depends on gstreamer:0.10 and many more dead libs (#629174), upstream dead # for ages (#634490). Removal in a month. games-arcade/monkey-bubble # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Fails to build (#629622, #614576, #627408). Removal in a month. app-shells/scsh-install-lib # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Upstream dead, not compatible with MariaDB (#629902). Removal in a month. dev-db/mysql-udf-infusion # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Doesn't build (#630252). Removal in a month. dev-python/visual # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Version bump pending for a long time, depends in QT4 (#630476). Removal in # a month. x11-misc/treeline # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Security vulnerable (#630954, #635548). Removal in a month. media-sound/mp3gain media-sound/aacgain # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Security vulnerable (#631602). Removal in a month. net-proxy/httpush # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Security vulnerable (#631720), dead since 2008, uses doman with compressed # man pages (#619952). Removal in a month. mail-filter/p3scan # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Doesn't build (#634116), use games-action/dxx-rebirth instead. Removal in # a month. games-action/d2x-rebirth # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Fails at runtime (#634258). Removal in a month. net-irc/savirc # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Fails to build (#634662), version bump long time pending (#596162). # Removal in a month. games-emulation/sdlmame # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Multiple vulnerabilities (#635598). Removal in a month. www-apps/b2evolution # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Superseeded by adwaita-icon-theme for years, also having both installed at # the same time causes some apps to use old icons over new ones (#638142). # Removal in a month. x11-themes/gnome-icon-theme # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Completely dead and unmaintained for years, multiple alternatives in the # tree (#638812). Removal in a month. media-gfx/pornview # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Not installable (#639130), version bump long time pending (#489156), # restricts userpriv (#516578). Removal in a month. mail-filter/qmail-scanner # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Fail to fetch (#640544, #640596, #640602). Removal in a month. media-video/vcdgear net-misc/yangcli-pro # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Outdated and useless (#642158). Removal in a month. app-i18n/man-pages-ro # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Forces the usage of obsolete dev-python/mysql-python (#643502). Dead since # 2013. Removal in a month. app-backup/holland-lib-mysql app-backup/holland-backup-mysqldump app-backup/holland-backup-mysql-meta app-backup/holland-backup-mysql-lvm app-backup/holland-backup-mysqlhotcopy # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Forces downgrade of mock (#643506). Removal in a month. dev-python/django-social-auth # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Requires old dev-python/oauth2client (#643534), tests fail (#527608). # Removal in a month. net-misc/gsutil # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Requires old psycopg (#643614). Removal in a month. dev-python/adodb-py # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Requires old whoosh (#643690). Removal in a month. dev-python/flask-whooshalchemy # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Requires old redis-py and gevent (#643692). Removal in a month. dev-python/pyzor # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Requires old leveldb, live ebuild, dead since 2013 (#644310). Removal in a # month. net-p2p/datacoin-hp # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Dead since 2011, relies on dead libraries (#644322, #644326, #644330, #644332 # #644340, #647600, #647608, #647698, #647700, #648998). Removal in a month. dev-util/alleyoop gnome-extra/gnome-color-chooser media-sound/neutrino media-video/camorama www-misc/gurlchecker games-board/gnome-mastermind media-sound/quark app-office/gtimelog x11-libs/libdesktop-agnostic x11-misc/dockmanager games-arcade/monster-masher # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Relies on dead QT4 (#644422), build issues (#629728). Removal in a month. media-video/videocut # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Depends on dead QT4 (#644480). Removal in a month. sci-electronics/plcedit # Pacho Ramos <pa...@gentoo.org> (18 Mar 2018) # Tests fail, package has no reverse deps an
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: app-arch/rpm app-benchmarks/os-autoinst dev-util/hxtools dev-util/obs-service-cpanspec dev-util/obs-service-download_files dev-util/obs-service-download_src_package dev-util/obs-service-download_url dev-util/obs-service-extract_file dev-util/obs-service-format_spec_file dev-util/obs-service-generator_driver_update_disk dev-util/obs-service-github_tarballs dev-util/obs-service-git_tarballs dev-util/obs-service-meta dev-util/obs-service-rearchive dev-util/obs-service-recompress dev-util/obs-service-set_version dev-util/obs-service-source_validator dev-util/obs-service-tar_scm dev-util/obs-service-update_source dev-util/obs-service-verify_file dev-util/osc dev-util/spec-cleaner dev-util/suse-build
[gentoo-dev] Lastrites: net-libs/netembryo, net-misc/netkit-rwall, sci-electronics/balsa, media-tv/me-tv, sci-biology/beast-mcmc, sys-power/phc-k8...
# Pacho Ramos <pa...@gentoo.org> (13 Mar 2018) # Tests need network, nothing requires this old lib anymore and upstream is # dead for a long time (#335233). Removal in a month. net-libs/netembryo # Pacho Ramos <pa...@gentoo.org> (13 Mar 2018) # Fails to build (#371401, #642676). Removal in a month. net-misc/netkit-rwall # Pacho Ramos <pa...@gentoo.org> (13 Mar 2018) # Incomplete and unclear LICENSE, missing files in SRC_URI (#472602). # Removal in a month. sci-electronics/balsa # Pacho Ramos <pa...@gentoo.org> (13 Mar 2018) # Upstream dead for a long time, requires obsolete gstreamer and other old # libs (#629192), buggy (#490344). Removal in a month. media-tv/me-tv # Pacho Ramos <pa...@gentoo.org> (13 Mar 2018) # Doesn't build for a long time (#514432). Removal in a month. sci-biology/beast-mcmc # Pacho Ramos <pa...@gentoo.org> (13 Mar 2018) # Fails to build (#514632, #585606, #588710). Removal in a month. sys-power/phc-k8 # Pacho Ramos <pa...@gentoo.org> (13 Mar 2018) # Fails to build for a long time (#515734, 649840). Removal in a month. sys-fs/gfs2-utils # Pacho Ramos <pa...@gentoo.org> (13 Mar 2018) # Dead driver and with many incompatibilities with current kernels (#517250, # #523356, #551834, #646106). Removal in a month. Possible alternative # #device/driver: https://bugs.gentoo.org/517250#c5 net-wireless/broadcom-sta # Pacho Ramos <pa...@gentoo.org> (13 Mar 2018) # Not buildable for a long time (#531586), pending many version bumps. # Removal in a month. media-sound/mup # Pacho Ramos <pa...@gentoo.org> (13 Mar 2018) # Many other ident daemons in the tree over this completely dead and # unmaintained (since 2003) implementation (#535868). Removal in a month. net-misc/linux-identd # Pacho Ramos <pa...@gentoo.org> (13 Mar 2018) # Major version bump pending (#540322), current version in the tree is # completely broken in several ways (#471428, #598260, #621784, #638364). # Removal in a month. sys-cluster/gearmand dev-php/pecl-gearman # Pacho Ramos <pa...@gentoo.org> (13 Mar 2018) # Not buildable and ends up needing old guile-1.8 (#547186, #617802), major # version bump pending (#515888). Removal in a month. media-sound/denemo # Pacho Ramos <pa...@gentoo.org> (13 Mar 2018) # Hard to bump (#547418), build issues (#600308). Removal in a month. app-forensics/libewf app-forensics/rdd # Pacho Ramos <pa...@gentoo.org> (13 Mar 2018) # Many pending version bumps (#574874), doesn't run (#587112), doesn't use # python eclasses (#613892), needs obsolete libs (#640888). Removal in a # month. net-p2p/tribler
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: net-irc/anope net-irc/ircservices net-irc/psybnc net-wireless/hostapd
Re: [gentoo-dev] Project:SuSE without members
El dom, 11-03-2018 a las 11:32 +0100, Andreas Sturmlechner escribió: > On Samstag, 10. März 2018 14:20:45 CET Pacho Ramos wrote: > > From now Project:SuSE has no members anymore, they maintain this packages > > (that will go to maintainer-needed in a week if Project is still without > > members at that time) > > Just in case this is the list you use for dropping to maintainer needed as > well - at least > > > app-backup/kfoldersync > > app-text/diction > > are false positives, and probably several others. Your 'suse' grep matches > packages with opensuse URLs or words like 'misused' in description text. > > Regards > Ah, yes, this is the list then app-arch/rpm app-benchmarks/os-autoinst dev-util/hxtools dev-util/icemon dev-util/obs-service-cpanspec dev-util/obs-service-download_files dev-util/obs-service-download_src_package dev-util/obs-service-download_url dev-util/obs-service-extract_file dev-util/obs-service-format_spec_file dev-util/obs-service-generator_driver_update_disk dev-util/obs-service-github_tarballs dev-util/obs-service-git_tarballs dev-util/obs-service-meta dev-util/obs-service-rearchive dev-util/obs-service-recompress dev-util/obs-service-set_version dev-util/obs-service-source_validator dev-util/obs-service-tar_scm dev-util/obs-service-update_source dev-util/obs-service-verify_file dev-util/osc dev-util/quilt dev-util/spec-cleaner dev-util/suse-build media-fonts/fifth-leg sys-devel/icecream
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: dev-embedded/mcu8051ide
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: x11-misc/kbdd x11-themes/comix-xcursors
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: app-text/pspdftool app-admin/supernova dev-python/args dev-python/attrdict dev-python/behave dev-python/clint dev-python/dockerpty dev-python/doublex-expects dev-python/doublex dev-python/expects dev-python/ghp-import dev-python/linecache2 dev-python/livereload dev-python/mamba dev-python/mando dev-python/mkdocs-bootstrap dev-python/mkdocs dev-python/monotonic dev-python/mypy dev-python/nose2 dev-python/os-client-config dev-python/paramunittest dev-python/parse dev-python/parse-type dev-python/pycallgraph dev-python/pyhamcrest dev-python/pytest-raisesregexp dev-python/python-termstyle dev-python/radon dev-python/sphinxcontrib-cheeseshop dev-python/sphinxcontrib-newsfeed dev-python/sphinxcontrib-spelling dev-python/stormpath dev-python/texttable dev-python/torment dev-python/traceback2 dev-python/typing
[gentoo-dev] Project:Lisp without members
>From now Project:Lisp has no members... that doesn't seem an issue as it contains multiple subprojects that maintain relevant packages... but, for the case anyone wants to join the main project... https://wiki.gentoo.org/wiki/Project:Lisp
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: dev-lang/gnu-smalltalk x11-misc/fluxter x11-themes/commonbox-styles-extra x11-themes/commonbox-styles x11-themes/fluxbox-styles-fluxmod x11-wm/fluxbox
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: app-text/pspdftool sys-power/acpid x11-libs/libyui-gtk x11-libs/libyui x11-libs/libyui-ncurses x11-libs/libyui-qt
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: app-portage/repo-commit dev-libs/libstrl net-irc/unrealircd
[gentoo-dev] Project:SuSE without members
>From now Project:SuSE has no members anymore, they maintain this packages (that will go to maintainer-needed in a week if Project is still without members at that time) Thanks app-arch/rpm app-backup/kfoldersync app-backup/snapper app-benchmarks/os-autoinst app-text/diction dev-lang/inform dev-python/pyinsane dev-util/hxtools dev-util/icemon dev-util/obs-service-cpanspec dev-util/obs-service-download_files dev-util/obs-service-download_src_package dev-util/obs-service-download_url dev-util/obs-service-extract_file dev-util/obs-service-format_spec_file dev-util/obs-service-generator_driver_update_disk dev-util/obs-service-github_tarballs dev-util/obs-service-git_tarballs dev-util/obs-service-meta dev-util/obs-service-rearchive dev-util/obs-service-recompress dev-util/obs-service-set_version dev-util/obs-service-source_validator dev-util/obs-service-tar_scm dev-util/obs-service-update_source dev-util/obs-service-verify_file dev-util/osc dev-util/quilt dev-util/spec-cleaner dev-util/suse-build media-fonts/fifth-leg sys-devel/icecream
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: app-editors/xmlcopyeditor app-pda/barry dev-libs/chmlib dev-util/ftjam net-p2p/nicotine+
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: app-crypt/kali-archive-keyring net-wireless/orinoco-fwutils x11-terms/tilda
[gentoo-dev] Lastrites: media-plugins/npapi-vlc, sci-chemistry/platon, sys-fs/ocfs2-tools, net-nds/ypserv, net-nds/ypbind...
# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Nobody bothered to bump it for ages, NPAPI is phased out (#468772). # Removal in a month. media-plugins/npapi-vlc # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Fails to fetch (#597424). Removal in a month. sci-chemistry/platon # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Multiple build issues (#423471, #529772, #558206, #574910, #603304, # #638602), problems with init.d scripts (#390231), major version bump # #pending to be done (#610744). Removal in a month. sys-fs/ocfs2-tools # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Fails to build, a major version bump is needed but it's hard to bump # (#626050, #626052). Removal in a month. net-nds/ypserv net-nds/ypbind # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Unmaintained, no server still usable for this software (#626676). Removal # in a month. app-text/antixls # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Upstream is died, no server still usable for this (#626770). Removal in a # month. games-arcade/bloboats # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Upstream dead, not compatible with latest mariadb, nothing requires this # in the tree (#628526, #629470, #629552, #629712, #629978, #630002, # #630098, #630650). Removal in a month. dev-db/lib_mysqludf_fPROJ4 dev-db/lib_mysqludf_preg dev-db/lib_mysqludf_ta dev-db/lib_mysqludf_stat dev-db/lib_mysqludf_str dev-db/lib_mysqludf_udf dev-db/lib_mysqludf_sys dev-db/lib_mysqludf_json # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Not properly mirrored, 14 years old and not really useful this days # (#629328). Removal in a month. x11-themes/lush # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Fails multilib-strict check (#628836). Nothing requires it. Removal in a # month. dev-libs/dclog # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Tries to install at pkg_postinst phase (#628804). Removal in a month. app-misc/misterhouse # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Configure hangs (#628726), a major version bump is needed (#510050). # Removal in a month. app-forensics/autopsy # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Multiple security issues, init scripts need a major rework (#629416, # #629412, #631068, #623806). Removal in a month. net-im/jabberd2 net-im/mu-conference # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Not compatible with current libmowgli, no reverse deps (#630030). Removal # in a month. dev-libs/libmcs # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Upstream dead, QT4 consumer (#630550). Removal in a month. x11-libs/qwtplot3d # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # No reverse deps, fails to build (#630866). Removal in a month. dev-libs/libmowgli-glib # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Deprecated tools replace by dev-python/awscli (#633374). Removal in a # month. app-admin/aws-as-tools app-admin/aws-cw-tools app-admin/aws-iam-tools app-admin/aws-rds-tools # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Relies on obsolete code.google, nothing uses it at present time (#633984). # Removal in a month. net-misc/slimrat # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Upstream dead, fails to fetch (#586504, #640546, #636466). Removal in a # month. games-emulation/xe # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Fails to build (#637612). Removal in a month. net-vpn/htun # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Unmaintained, fails to build (#638628). Removal in a month. media-sound/nted # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Fails to build (#638634). Removal in a month. sys-apps/raidutils # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Tries to download and compile other tools, build fails then (#639060). # Removal in a month. dev-lang/fsharp # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Dead since 2007, fails to build (#639510). Removal in a month. net-irc/ultimate # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Relies on dead gnome2 python bindings, seems dead since 2009 (#640028), # removal in a month. sys-power/phctool # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Upstream stopped its development as recent Gnome versions don't need it, # it relies on gnome2 python bindings and many other dead libs (#640032). # Removal in a month. app-misc/specto # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Upstream dead, relies on gnome2 python bindings and other dead libs # (#640070). Removal in a month. x11-plugins/thinkhdaps # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Cannot be installed (#640414). Removal in a month. net-misc/asterisk-rate_engine # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Dead for ages and replaced by app-admin/procinfo-ng (#641016). Removal in # a month. app-admin/procinfo # Pacho Ramos <pa...@gentoo.org> (04 Jan 2018) # Upstream dead, fails to b
Re: [gentoo-dev] [PATCH 1/2] preserve-libs.eclass: Split off preserve_old_lib from eutils.
El mié, 03-01-2018 a las 17:13 +0100, Ulrich Müller escribió: > Split off functions preserve_old_lib and preserve_old_lib_notify from > eutils.eclass into a dedicated preserve-libs.eclass. These functions > are rarely used and are independent of the rest of eutils, therefore > moving them into their own eclass will help clarifying eclass > inheritance in ebuilds. > > For backwards compatibility, eutils inherits the new eclass in > existing EAPIs. > --- > eclass/eutils.eclass| 65 ++- > eclass/preserve-libs.eclass | 74 > + > 2 files changed, 76 insertions(+), 63 deletions(-) > create mode 100644 eclass/preserve-libs.eclass > > diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass > index 7d4193e76b51..91d329e99c9e 100644 > --- a/eclass/eutils.eclass > +++ b/eclass/eutils.eclass > @@ -1,4 +1,4 @@ > -# Copyright 1999-2017 Gentoo Foundation > +# Copyright 1999-2018 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > > # @ECLASS: eutils.eclass > @@ -20,7 +20,7 @@ _EUTILS_ECLASS=1 > # implicitly inherited (now split) eclasses > case ${EAPI:-0} in > 0|1|2|3|4|5|6) > - inherit desktop epatch estack ltprune multilib toolchain-funcs > + inherit desktop epatch estack ltprune multilib preserve-libs > toolchain-funcs > ;; > esac > > @@ -172,67 +172,6 @@ _eutils_eprefix_init() { > has "${EAPI:-0}" 0 1 2 && : ${ED:=${D}} ${EPREFIX:=} > ${EROOT:=${ROOT}} > } > > -# @FUNCTION: preserve_old_lib > -# @USAGE: [more libs] > -# @DESCRIPTION: > -# These functions are useful when a lib in your package changes ABI SONAME. > -# An example might be from libogg.so.0 to libogg.so.1. Removing libogg.so.0 > -# would break packages that link against it. Most people get around this > -# by using the portage SLOT mechanism, but that is not always a relevant > -# solution, so instead you can call this from pkg_preinst. See also the > -# preserve_old_lib_notify function. > -preserve_old_lib() { > - _eutils_eprefix_init > - if [[ ${EBUILD_PHASE} != "preinst" ]] ; then > - eerror "preserve_old_lib() must be called from pkg_preinst() > only" > - die "Invalid preserve_old_lib() usage" > - fi > - [[ -z $1 ]] && die "Usage: preserve_old_lib > [more libraries to preserve]" > - > - # let portage worry about it > - has preserve-libs ${FEATURES} && return 0 > - > - local lib dir > - for lib in "$@" ; do > - [[ -e ${EROOT}/${lib} ]] || continue > - dir=${lib%/*} > - dodir ${dir} || die "dodir ${dir} failed" > - cp "${EROOT}"/${lib} "${ED}"/${lib} || die "cp ${lib} failed" > - touch "${ED}"/${lib} > - done > -} > - > -# @FUNCTION: preserve_old_lib_notify > -# @USAGE: [more libs] > -# @DESCRIPTION: > -# Spit helpful messages about the libraries preserved by preserve_old_lib. > -preserve_old_lib_notify() { > - if [[ ${EBUILD_PHASE} != "postinst" ]] ; then > - eerror "preserve_old_lib_notify() must be called from > pkg_postinst() only" > - die "Invalid preserve_old_lib_notify() usage" > - fi > - > - # let portage worry about it > - has preserve-libs ${FEATURES} && return 0 > - > - _eutils_eprefix_init > - > - local lib notice=0 > - for lib in "$@" ; do > - [[ -e ${EROOT}/${lib} ]] || continue > - if [[ ${notice} -eq 0 ]] ; then > - notice=1 > - ewarn "Old versions of installed libraries were > detected on your system." > - ewarn "In order to avoid breaking packages that > depend on these old libs," > - ewarn "the libraries are not being removed. You need > to run revdep-rebuild" > - ewarn "in order to remove these old dependencies. If > you do not have this" > - ewarn "helper program, simply emerge the 'gentoolkit' > package." > - ewarn > - fi > - ewarn " # revdep-rebuild --library '${lib}' && rm '${lib}'" > - done > -} > - > # @FUNCTION: built_with_use > # @USAGE: [--hidden] [--missing ] [-a|-o] flags> > # @DESCRIPTION: > diff --git a/eclass/preserve-libs.eclass b/eclass/preserve-libs.eclass > new file mode 100644 > index ..548c6411fcf0 > --- /dev/null > +++ b/eclass/preserve-libs.eclass > @@ -0,0 +1,74 @@ > +# Copyright 1999-2018 Gentoo Foundation > +# Distributed under the terms of the GNU General Public License v2 > + > +# @ECLASS: preserve-libs.eclass > +# @MAINTAINER: > +# base-sys...@gentoo.org > +# @BLURB: preserve libraries after SONAME changes > + > +if [[ -z ${_PRESERVE_LIBS_ECLASS} ]]; then > +_PRESERVE_LIBS_ECLASS=1 > + > +# @FUNCTION: preserve_old_lib > +# @USAGE: [more libs] > +# @DESCRIPTION: > +# These functions are useful when a lib in your package changes ABI SONAME. > +# An example might
Re: [gentoo-dev] [PATCH] skel.ebuild: Update comments for inherit, SLOT, KEYWORDS.
El dom, 31-12-2017 a las 12:12 -0600, William Hubbs escribió: > On Sun, Dec 31, 2017 at 06:44:39PM +0100, Michał Górny wrote: > > W dniu nie, 31.12.2017 o godzinie 14∶31 +0100, użytkownik Ulrich Müller > > napisał: > > > epatch() is provided by epatch.eclass now. Also comment the inherit > > > line, since not every ebuild will use it. > > > > > > Empty SLOT doesn't disable slots, but is outright illegal in all EAPIs. > > > Similar for KEYWORDS="*", which isn't "deprecated" but invalid. > > > --- > > > skel.ebuild | 9 - > > > 1 file changed, 4 insertions(+), 5 deletions(-) > > > > > > diff --git a/skel.ebuild b/skel.ebuild > > > index 7ac9dfb7d6d8..4c19b1de4cb8 100644 > > > --- a/skel.ebuild > > > +++ b/skel.ebuild > > > @@ -13,9 +13,9 @@ > > > EAPI=6 > > > > > > # inherit lists eclasses to inherit functions from. For example, an > > > ebuild > > > -# that needs the epatch function from eutils.eclass won't work without > > > the > > > +# that needs the epatch function from epatch.eclass won't work without > > > the > > > # following line: > > > -inherit eutils > > > +#inherit epatch > > > > Well, given that it's EAPI 6 and we do not want to encourage people to > > use epatch there, I would prefer if we replaced that example with > > something else. But it's just a wishful thinking here. > > +1, but I'm not going to suggest what to replace it with. > > William Why not eapply (and drop inherit then)? :/
[gentoo-dev] Lastrites: media-libs/libdvb, sys-cluster/drbd, dev-lang/blassic, app-text/nfoview, dev-python/ssh, media-gfx/aqsis...
# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017) # Dead since 2005, nothing requires it, installs object files in # /usr/share/doc (#451792). Removal in a month. media-libs/libdvb # Pacho Ramos <pa...@gentoo.org> (28 Dec 2017) # This was replaced by sys-cluster/drbd-utils (#590872), reverse deps were # already migrated to it, doesn't build with latest glibc (#616510). Removal # in a month. sys-cluster/drbd # Pacho Ramos <pa...@gentoo.org> (28 Dec 2017) # Fails to build (#595706), nothing requires it. Removal in a month. dev-lang/blassic # Pacho Ramos <pa...@gentoo.org> (28 Dec 2017) # Fails at runtime (#614314). Removal in a month. app-text/nfoview # Pacho Ramos <pa...@gentoo.org> (28 Dec 2017) # Needs to be migrated to pycryptodome, this was merged into paramiko # (#611616). Removal in a month. dev-python/ssh dev-python/starcluster # Pacho Ramos <pa...@gentoo.org> (28 Dec 2017) # Fails with recent boost (#617060, #598702). Removal in a month. media-gfx/aqsis # Pacho Ramos <pa...@gentoo.org> (28 Dec 2017) # A major version bump is needed (#412447), fails with multilib-strict # (#613542), not compatible with newer imagemagick (#619514), cannot be # downloaded (#635566). Removal in a month. media-libs/vips media-gfx/nip2 # Pacho Ramos <pa...@gentoo.org> (28 Dec 2017) # Multiple build failures and bugs (#634316), fails with recent lua # (#434242), init script is buggy (#496724), bash completion files installed # wrongly (#526280), fails with newer botan (#537572). Removal in a month. dev-vcs/monotone # Pacho Ramos <pa...@gentoo.org> (28 Dec 2017) # Fails to build (#622110), upstream dead for years. Removal in a month. app-misc/tasque # Pacho Ramos <pa...@gentoo.org> (28 Dec 2017) # Needs a major version bump and relies on lots of dead libs (#624160). # Removal in a month. x11-terms/terminator # Pacho Ramos <pa...@gentoo.org> (28 Dec 2017) # Requires dead gnome2 python bindings (#629180) and old gstreamer, also all # zeitgeist stack has important bugs and upstream is gone (#629180#c2): # zeitgeist-explorer doesn't start (#622084), activity-log-manager fails to # build (#625140), gnome-extra/gnome-activity-journal gnome-extra/zeitgeist-explorer gnome-extra/activity-log-manager gnome-extra/zeitgeist # Pacho Ramos <pa...@gentoo.org> (28 Dec 2017) # Dead for ages, relies on old gnome2 python bindings (#640036). Removal in # a month. gnome-extra/cameramonitor # Pacho Ramos <pa...@gentoo.org> (28 Dec 2017) # Upstream gone, relies on old gnome2 python bindings (#640042). Removal in # a month. media-gfx/gnome-specimen # Pacho Ramos <pa...@gentoo.org> (28 Dec 2017) # Upstream dead for ages, relies on old gnome2 python bindings (#640050). # Removal in a month. net-misc/polly # Pacho Ramos <pa...@gentoo.org> (28 Dec 2017) # Upstream gone, relies on old gnome2 python bindings (#640052). Removal in # a month. sys-apps/pyrenamer # Pacho Ramos <pa...@gentoo.org> (28 Dec 2017) # Upstream dead since 2006, relies on old gnome2 python bindings and many # other dead libs (#640068). Removal in a month. media-sound/ifp-gnome
[gentoo-dev] Lastrites: compiz and related packages
# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017) # Remove all Compiz related packages: they all need major work/bumps to fix # lots of pending issues and they need a dedicated maintainer (bug #339622 # and many others). Removal in a month. x11-wm/compiz x11-apps/fusion-icon x11-libs/compizconfig-backend-gconf x11-libs/libcompizconfig dev-python/compizconfig-python x11-misc/ccsm x11-misc/simple-ccsm x11-plugins/compiz-plugins-extra x11-plugins/compiz-plugins-main x11-plugins/compiz-plugins-unsupported x11-wm/compiz-fusion x11-wm/emerald x11-themes/emerald-themes x11-libs/compiz-bcop
[gentoo-dev] Lastrites: dev-java/jikes, net-misc/netkit-rusers, net-print/xerox-drivers, dev-dotnet/gnome-sharp...
# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017) # Dead for ages, not needed, for java 1.5 (#638036). Removal in a month. dev-java/jikes # Pacho Ramos <pa...@gentoo.org> (27 Dec 2017) # Dead for ages, requires glibc with rpc (#371391). Removal in a month. net-misc/netkit-rusers # Pacho Ramos <pa...@gentoo.org> (27 Dec 2017) # Out ebuild is completely obsolete (#381073), download manually PPD is # preferred, current tarballs cannot be downloaded even (#635146). Removal # in a month. net-print/xerox-drivers # Pacho Ramos <pa...@gentoo.org> (27 Dec 2017) # Dead and broken for a long time (#427876), nothing requires this. Removal # in a month. dev-dotnet/gnome-sharp # Pacho Ramos <pa...@gentoo.org> (27 Dec 2017) # Dead and broken for a long time (#428354, #562772, #624956, #558120, # #585222, #585548, #605706, #612368), nothing requires this. Removal # in a month. # Mikhail Pukhlikov <cyn...@gentoo.org> (20 Jul 2017) # Old mono/dotnet packages (used on GNOME2 stack) # also some deprecated forks used for monodevelop # awhile they are very unstable they will live in dotnet overlay gnome-extra/docky dev-dotnet/gnome-desktop-sharp dev-dotnet/gtksourceview-sharp dev-dotnet/rsvg-sharp dev-dotnet/vte-sharp dev-dotnet/wnck-sharp dev-dotnet/xdt-for-monodevelop dev-dotnet/nuget dev-dotnet/referenceassemblies-pcl # Pacho Ramos <pa...@gentoo.org> (27 Dec 2017) # Dead for ages, rely on deprecated/dead libs (#447466). Removal in a month. dev-vcs/bzr-gtk dev-vcs/bzr-explorer # Pacho Ramos <pa...@gentoo.org> (27 Dec 2017) # Completely broken for years (#514400, #596078, #598609, #640096, #641428). # Removal in a month. dev-cpp/pficommon # Pacho Ramos <pa...@gentoo.org> (27 Dec 2017) # Dead for a long time, failing tests (#526900), nothing requires it. # Removal in a month. net-misc/ytalk # Pacho Ramos <pa...@gentoo.org> (27 Dec 2017) # Upstream dead, SRC_URI dead, nothing requires it (#533812). Removal in a # month. media-video/replex # Pacho Ramos <pa...@gentoo.org> (27 Dec 2017) # Not compatible with mono-4 (#557588, #562546, #569252, #581920, #585860, #596652), # nothing requires them. Removal in a month. dev-dotnet/xsp dev-dotnet/nini dev-lang/mono-basic dev-util/jay # Pacho Ramos <pa...@gentoo.org> (27 Dec 2017) # python files installed in wrong path (#580328), relies on qt4 and cannot # be bumped (#585328), fails with gcc6 (#630332), fails to build (#641514). # Removal in a month. sci-visualization/qtiplot # Pacho Ramos <pa...@gentoo.org> (27 Dec 2017) # Dead upstream for a long time, relies on dead gnome-icon-theme and has # some crashes (#602144). Removal in a month. app-doc/podbrowser # Pacho Ramos <pa...@gentoo.org> (27 Dec 2017) # Dead upstream for a long time, relies on dead gnome-icon-theme and nothing # requires it (#602146). Removal in a month. games-emulation/gxmame # Pacho Ramos <pa...@gentoo.org> (27 Dec 2017) # All Ekiga set is dead and broken for years, it relies on obsolete # dead/libs that are also old and broken and upstream looks to not release # newer ekiga ever. To keep this please go ahead and take care of it *and # all the dependencies it also needs*. See bugs #626176, #460458, #589276, # #638122, #641990, #633670, #624578, #600398, #627868. # Removal in a month. net-libs/ptlib net-libs/opal net-voip/openmcu net-voip/ekiga
Re: [gentoo-dev] RFC: news item for the 17.0 profiles
El mar, 10-10-2017 a las 00:23 +0200, Toralf Förster escribió: > On 10/09/2017 11:40 PM, Pacho Ramos wrote: > > Could anyone with enough knowledge finally give a look to the patched vapier > > s/patched/patches/ > > or ? :-) > Yes :)
Re: [gentoo-dev] RFC: news item for the 17.0 profiles
El lun, 09-10-2017 a las 22:58 +0200, Andreas K. Huettel escribió: > = > Title: New 17.0 profiles in the Gentoo repository > Author: Andreas K. Hüttel> Posted: xxx > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: >=sys-devel/gcc-6.4.0 > > We have just added a new set of profiles with release version 17.0 > to the Gentoo repository. These bring two changes: > 1) The default C++ language version for applications is now C++14. >This change is mostly relevant to Gentoo developers. It also >means, however, that compilers earlier than GCC 6 are masked >and not supported for use as a system compiler anymore. Feel >free to unmask them if you need them for specific applications. > 2) Where supported, GCC will now build position-independent >executables (PIE) by default. This improves the overall >security fingerprint. The switch from non-PIE to PIE binaries, >however, requires some steps by users, as detailed below. > > Please consider switching from your current 13.0 profile to the > corresponding 17.0 profile soon after GCC-6.4.0 has been > stabilized on your architecture. The 13.0 profiles will be deprecated > and removed in the near future. > > Switching involves the following steps: > If not already done, > * Use gcc-config to select gcc-6.4.0 or later as system compiler > * Re-source /etc/profile: > . /etc/profile > * Re-emerge libtool Could anyone with enough knowledge finally give a look to the patched vapier provided in https://bugs.gentoo.org/88596 but never got committed? Thanks!
Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer
El mié, 26-07-2017 a las 13:46 +, Lucas Ramage escribió: > I am not yet an official developer but I am interested in assisting in > maintaining this. > Then, please take a look on: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers In summary, you will need to open a bug asking proxy-maint to set you as maintainer and, for fixing bugs, usually sending github PR is the preferred method Thanks
[gentoo-dev] Lastrites: dev-lang/gnat-gcc, x11-apps/spotlighter, dev-scheme/stalin...
# Pacho Ramos <pa...@gentoo.org> (26 Jul 2017) # Severely broken with lots of unresolved bugs, outdated, needs a dedicated # maintainer (#402157). Removal in a month. dev-lang/gnat-gcc virtual/gnat # Pacho Ramos <pa...@gentoo.org> (26 Jul 2017) # Upstream dead, cannot be bumped, buggy (#468128). Removal in a month. x11-apps/spotlighter # Pacho Ramos <pa...@gentoo.org> (26 Jul 2017) # Fails to build (#542108), relies on dead DirectFB. Removal in a month. dev-libs/DFB++ # Pacho Ramos <pa...@gentoo.org> (26 Jul 2017) # Upstream dead, vulnerable (#569980), removal in a month. dev-scheme/stalin # Pacho Ramos <pa...@gentoo.org> (26 Jul 2017) # Orphan, severely outdated and vulnerable to security issues (#585940). # Removal in a month. sys-apps/pacman # Pacho Ramos <pa...@gentoo.org> (26 Jul 2017) # One of the last consumers of old udisks:0, upstream dead for ages # (#601358). Removal in a month. x11-misc/tinymount # Pacho Ramos <pa...@gentoo.org> (26 Jul 2017) # EOL, severely broken, impossible to bump (#624966). Removal in a month. sci-geosciences/googleearth # Pacho Ramos <pa...@gentoo.org> (26 Jul 2017) # Dead for ages, not usable at present time (#625596). Removal in a month. app-mobilephone/linuxsms # Pacho Ramos <pa...@gentoo.org> (26 Jul 2017) # Upstream dead, last consumer of obsolete cegui version (#625604). Removal # in a month. games-arcade/smc # Pacho Ramos <pa...@gentoo.org> (26 Jul 2017) # Dead for a long time, relies on also dead DirectFB lib (#625608). Removal # in a month. media-gfx/DFBPoint # Pacho Ramos <pa...@gentoo.org> (26 Jul 2017) # Upstream dead, relies on also dead DirectFB lib (#625610). Removal in a # month. media-video/dfbsee # Pacho Ramos <pa...@gentoo.org> (26 Jul 2017) # Upstream dead, relies on also dead DirectFB lib (#625612). Removal in a # month. net-misc/directvnc
[gentoo-dev] sys-boot/plymouth needs major fixes/maintainer
sys-boot/plymouth is orphan for a long time. Its old 0.8.x versions where having important bugs that were fixed in 0.9.x, but 0.9 is also plenty of issues. Then, either this is adopted by someone able to handle all that issues or we will need to finally treeclean (and drop its support for dependant packages) Thanks
[gentoo-dev] sys-kernel/openvz-sources needs a dedicated maintainer
Currently is maintained needed, and going ahead and bumping it when we notice how outdated and vulnerable to security issues is not enough. This needs a dedicated maintainer taking care of bumping when needed. Hence, feel free to get it if you want to still keep it alive. Thanks
Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
El mar, 25-07-2017 a las 23:10 +1000, Michael Palimaka escribió: > On 07/25/2017 05:22 PM, Dirkjan Ochtman wrote: > > First, the assumption in our processes seems to be that many or > > important bugs will be due to architecture-specific differences, and I > > wonder if that assumption really holds up. Do arch testers for a smaller > > arch often find problems that were not noticed on one of the larger > > arches? With the languages and tools that we have today, it seems like > > for many of our packages, bugs due to architectural differences > > represent a minority of the problems we found. In this case, the whole > > idea of per-arch stabilization does not really make sense, and doing > > away with that idea could drastically shortcut our process. > > This would be really interesting to know. Anyway, I think it depends on the arch you are running. I remember to have seen specific issues for ia64, hppa, ppc64 or arm. But, for example, I agree that, *at present time*, I don't remember to have seen a package failing on x86 and not on amd64 for example (well, I now remember a past systemd upstream runtime bug that was catched in testing period ;)). Then, I guess it depends on each arch. For example, for x86 it could be probably done if things work on amd64 :/. Between ppc and ppc64 I don't know. For the others, I don't think that we can extrapolate between amd64 and ia64 for example (I remember important runtime issues to be catched only affecting ia64 for example).
Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
El mar, 25-07-2017 a las 22:59 +1000, Michael Palimaka escribió: > On 07/25/2017 07:22 AM, Sergei Trofimovich wrote: > > 2. Q: How to make arch testing faster and easier? > > > > A: - KEYWORDREQ/STABLEREQ bugs not marked as "runtime testing > > required" will be automatically tested and keyworded. > > > > [handwave] automated tinderbox setup would help a lot > > to now upfront what fails to built, fails tests. > > I've had similar thoughts about this and have already been working on > some tooling for this. > > We would need to establish exactly what criteria must be met for an > automated test to be considered as successful. > > Here's a sample report that my tool produces: > https://dev.gentoo.org/~kensington/tinderbox/sys-apps/dbus/dbus-1.6.18-r1/df01 > 7e14-bd68-47e2-9738-554e7ba1cf10.html > > In this case, would it be enough that it builds and tests pass? What > about the QA issues? Personally, I don't feel QA issues as major enough to block a stabilization, usually they won't cause major issues for stable users and, if they do, for sure they shouldn't be only QA issues :/ > Do we need someone to review them to determine if > they should block stabilisation, or if they're even a regression or not? > Regarding general regressions, that is probably the harder point to handle automatically. In the past, the scripts in arch-tools.git were avoiding to open automated stable bug reports for packages having opened bugs (excluding enhancement and QA bug reports), but that approach is not too good as, for example, having a bug report asking for a version bump but tagged as "normal" and not "enhancement" will lead to the bug not being opened :S Then, I am unsure about if that part can be done automatically :/
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
El mar, 25-07-2017 a las 15:19 +0200, Michał Górny escribió: > On wto, 2017-07-25 at 14:15 +0200, Pacho Ramos wrote: > > El mar, 25-07-2017 a las 13:54 +0200, Michał Górny escribió: > > > Dnia 25 lipca 2017 11:18:21 CEST, Pacho Ramos <pa...@gentoo.org> > > > napisał(a): > > > > El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió: > > > > > On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote: > > > > > > > > > > > > I hold a perhaps radical view: I would like to simply remove > > > > > > > > stable. > > > > > > > > > > > > [snip] > > > > > > > > > > > > I consider dev time a precious resource. > > > > > > > > > > If we were to drop stable I would have to start maintaining my own > > > > > stable lists to determine what would be ready to into production for > > > > > > > > my > > > > > company. In production "works most of the time" and "good enough" > > > > > simply aren't good enough. > > > > > > > > > > I estimate that would at least equal the amount of time I'm currently > > > > > spending on Gentoo work, and consequently my contributions to Gentoo > > > > > would dwindle to a halt. Most likely I would start looking at other > > > > > solutions altogether. > > > > > > > > > > > More troubleshooting and fixing "hard" problems, less routine work. > > > > > > > > > > Except that some of that routine work is actually what I enjoy doing > > > > > > > > in > > > > > Gentoo. I already get plenty of the other two in my day job. > > > > > > > > > > Hans > > > > > > > > If stable goes away I will simply switch to other distribution and > > > > retire > > > > > > What's the "over my dead commit access" spirit? > > > > > > > Jumping from trying to maintain stable tree to arches dead for ages to drop > > all > > stable trees looks to me like a joke promoted by people that has never > > handled > > any stabilization request and saw on them how running a pure "testing" > > system is > > impossible on many conditions. It seems that some people think that if it > > fits > > ok for them, it will fit for all others like we were all using Gentoo for > > doing > > the same. > > > > I'm sorry, that was supposed to be 'where', not 'what' (stupid > autocompletion!). I simply meant to say that you should have said 'over > my dead commit access' there ;-). > > Ah, no problem. I am also sorry for my quick response to the thread but, seriously, when I read the suggestion I was like =O Best regards!
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
El mar, 25-07-2017 a las 13:54 +0200, Michał Górny escribió: > Dnia 25 lipca 2017 11:18:21 CEST, Pacho Ramos <pa...@gentoo.org> napisał(a): > > El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió: > > > On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote: > > > > > > > > I hold a perhaps radical view: I would like to simply remove > > > > stable. > > > > > > > > [snip] > > > > > > > > I consider dev time a precious resource. > > > > > > If we were to drop stable I would have to start maintaining my own > > > stable lists to determine what would be ready to into production for > > > > my > > > company. In production "works most of the time" and "good enough" > > > simply aren't good enough. > > > > > > I estimate that would at least equal the amount of time I'm currently > > > spending on Gentoo work, and consequently my contributions to Gentoo > > > would dwindle to a halt. Most likely I would start looking at other > > > solutions altogether. > > > > > > > More troubleshooting and fixing "hard" problems, less routine work. > > > > > > Except that some of that routine work is actually what I enjoy doing > > > > in > > > Gentoo. I already get plenty of the other two in my day job. > > > > > > Hans > > > > If stable goes away I will simply switch to other distribution and > > retire > > What's the "over my dead commit access" spirit? > Jumping from trying to maintain stable tree to arches dead for ages to drop all stable trees looks to me like a joke promoted by people that has never handled any stabilization request and saw on them how running a pure "testing" system is impossible on many conditions. It seems that some people think that if it fits ok for them, it will fit for all others like we were all using Gentoo for doing the same. I could of course deal with things in my personal computer like, for example, needing to run gcc-6 (current testing) and having tons of packages failing to build, or run python-3.6 with only a few subset of packages, or running latest ffmpeg with random packages going to fail with it, or many other issues that anyone doing some stabilization work would have noticed. But, of course, I cannot pretend that all the people using Gentoo systems for working or doing something productive and that for now rely on me for maintaining or helping them with the issues that could arise, will now be also forced to run systems that are likely going to break in different and new ways every time they pretend to update. I am also really surprised to see how we can jump from some people that were fighting in the past against we running automatic scripts that already existed to fill stabilization bug reports and CC arches after timeouts, to a new situation of "oh, testing tree is good enough for all the people". We will jump for some people asking for things like doing deeper tests runs for packages going to stable (at a level that was really unfeasible on a large scale) to a situation in that nothing (even no compile test) will be checked at all. Additionally, this will also cause new issues between people that were used to run "testing" in the way they are running it now and they pushing to unmask things faster and, others used to "stable", pushing to keep more things hard masked until they are fixed. It's not the first time that we see that, for example, a new glibc version is unmasked when maintainer feels it's ready to allow people to catch the bugs before it going to be stable. If we have no stable tree, that couldn't be done as we couldn't use "testing" for the purpose of "lets unmask X package it give it more visibility and let people catch the bugs". Then, either we keep breaking "testing" even knowing there is no stable, or we will start getting lots of packages in package.mask leading to new issues (like those packages having less visibility and fights between people thinking that a mid breakage is ok and others that not). Then, in my case it will be as simply as, if Gentoo becomes testing only, I won't be able to use it for anything productive, only for "playing" with it... and then, I won't see much sense on staying while I will need to use a different distribution de facto for the work and any computer that is not the laptop I use for committing and doing Gentoo dev work.
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió: > On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote: > > > > I hold a perhaps radical view: I would like to simply remove stable. > > > > [snip] > > > > I consider dev time a precious resource. > > If we were to drop stable I would have to start maintaining my own > stable lists to determine what would be ready to into production for my > company. In production "works most of the time" and "good enough" > simply aren't good enough. > > I estimate that would at least equal the amount of time I'm currently > spending on Gentoo work, and consequently my contributions to Gentoo > would dwindle to a halt. Most likely I would start looking at other > solutions altogether. > > > More troubleshooting and fixing "hard" problems, less routine work. > > Except that some of that routine work is actually what I enjoy doing in > Gentoo. I already get plenty of the other two in my day job. > > Hans If stable goes away I will simply switch to other distribution and retire
[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
El lun, 24-07-2017 a las 22:22 +0100, Sergei Trofimovich escribió: > 4. Q: How to push more packages into STABLE? > > A: File automatic STABLEREQ bugs more aggressively if no known bugs > exist for a package version. The rough workflow is the following: > > - Grab a list of candidates for stabilization (will need > additional tooling) > - File STABLEREQ against maintainer only first. > - Maintainer will have a 2-week timeout to either proceed with > request: > - add "runtime testing required fields", CC relevant arches to > start stabilization > - or set blocking bugs against STABLEREQ to stop stabilization > - After 2-week timeout tooling automatically CCes arches and > stabilization happens (ideally with minimal manual work) > - Profit! I think the tools for this were already developed... but they were relying on some of us remembering to run them from time to time :/ https://gitweb.gentoo.org/proj/arch-tools.git/tree/file-stabilization-bugs.py https://gitweb.gentoo.org/proj/arch-tools.git/tree/maintainer-timeout.py https://gitweb.gentoo.org/proj/arch-tools.git/tree/stabilization-candidates.py Thanks specially for sharing https://wiki.gentoo.org/wiki/Package_testing#Tools link, it summarizes all the process really well :O Also, it seems that tatt- is able to do most of the work... then only thing that maybe has no official script to get it, for example, what would be the best way of getting the list of bug numbers that are pending to handle? For example, if I go to the list manually and pick 10 random bugs, it's ok to run tatt and copy every bug number but, if the arch queue has 300 pending bugs. Do we have a way to simply get a plain text with all the bug numbers from bugzilla interface? Having links per arch pointing to that list of bugs with arches CCed and sanity-check=+ would be probably helpful ;) Thanks
[gentoo-dev] Lastrites: app-mobilephone/esms, sci-chemistry/icm, dev-python/south...
# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Not usable, dead since 2003, removal in a month (#24706) app-mobilephone/esms # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Proprietary software, fetch restricted, not actively maintained, needs to # be updated, with multiple QA issues, bug #622414. Removal in a month. sci-chemistry/icm # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Doesn't work with >=openvpn-2.3, removal in a month (#470696). net-vpn/kvpnc # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Doesn't work with any django version in the tree, tests fail, removal in a # month (#482498). dev-python/south # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # No reverse deps, doesn't build, bug #569068. Removal in a month. net-misc/jumpgate # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Lots of unresolved bugs, not compatible with QT 5.7 either, bug #574672. # Removal in a month. net-p2p/bitcoinxtd net-p2p/bitcoinxt-qt # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Our package is completely outdated and needs a major version bump (and # pkgmove). Bug #541410. Removal in a month. dev-util/febootstrap # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Buggy, doesn't compile for a long time, bug #575772. Removal in a month. dev-python/python-sipsimple net-voip/blink # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Doesn't compile, one of the last consumers of obsolete gnet library # (#579400). Removal in a month. net-irc/loqui # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Doesn't compile (#579948). Removal in a month. net-nntp/leafnode # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Doesn't compile, upstream dead, removal in a month (#584296). dev-util/mutrace # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # QA issues, upstreams dead, multiple alternatives, bug #587284 and bug # #587288. Removal in a month. sys-libs/libacpi sys-power/yacpi # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # games-engines/renpy cannot be used with its only reverse dep in the tree # as-is, it needs a major version bump and build fixing too, bug #587872. # Removal in a month. games-engines/renpy # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Doesn't build for a long time, bug #587942 sci-mathematics/cado-nfs # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Doesn't build (#592992), dead since 2011 and nothing needs it in the tree. # Removal in a month. dev-libs/mozldap # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Not compatible with gcc6 (#594390), also removed from other distributions # due it being unmaintained and buggy. Removal in a month. net-analyzer/nepenthes # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Upstream inactive, not buildable with gcc6, not needed by anything in the # tree (#594668). Removal in a month. app-text/mbtpdfasm # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # No reverse deps, not buildable with gcc6 (#595396). Removal in a month. media-libs/embree # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Not compatible with QT 5.7, bug #595452. Removal in a month. net-p2p/litecoin-qt # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Not buildable (#596602), no reverse deps, removal in a month. app-pda/fusepod # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Not buildable for a long time (#597040). Removal in a month. dev-util/lorax # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Security issues (#600524), upstream dead, removal in a month. dev-db/recutils # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Multiple unresolved bugs (#600680), need major version bumps and a # maintainer, removal in a month. dev-libs/libRocket games-fps/warsow # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Fails to build, no reverse deps (#600768). Removal in a month. app-editors/mp # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Needs obsolete splitted dev-dotnet/gnome-sharp (#600960). Removal in a # month. media-video/gnome-subtitles # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Development stopped 4 years ago, relies on dead vte:2.90 and upstream # refused to even try to migrate it (#601350). Also security issues # (#611290). Removal in a month. x11-terms/evilvte # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Not compatible with gcc6, nothing needs this in the tree (#603900). # Removal in a month. dev-libs/qcodeedit # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Not compatible with gperf-3.1 (#604816). Removal in a month. app-misc/flasm # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Upstream is dead, lots of unresolved bug reports (#606154), it needs a # real maintainer taking care about fixing this. Removal in a month. sys-apps/v86d # Pacho Ramos <pa...@gentoo.org> (14 Jul 2017) # Doesn't build anymore (#607482). Removal in a month. net-irc/irssi-xmpp # Pacho Ramos <pa...@gentoo.org
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
El mié, 12-07-2017 a las 12:38 -0400, William L. Thomson Jr. escribió: > On Wed, 12 Jul 2017 17:23:43 +0100 > "M. J. Everitt"wrote: > > > On 12/07/17 17:07, Gordon Pettey wrote: > > > On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr. > > > > wrote: > > > That is my point. That message is always there. The chance that > > > it is ignored is very high. > > > > > > > > > Stop signs on the road are also always there. If you get arrested > > > for ignoring it, it is not because the stop signs are always there, > > > it is because you ignored it. Don't ignore the warning. > > > > Can't help but think of "special snowflake" here > > More like saying something to me because it is me, despite that I > literally pointed that out to others. In a situation that actually > matters. This should be said to others not me. But everyone feels ilke > they need to comment something to me, that applies to another, but not > said to that other. > > Again > https://archives.gentoo.org/gentoo-dev/message/a0470e1cc2c05afc1e30c09f3f239b2 > 4 > > Really funny stuff > > -- After re-reading all the thread again: https://lists.gt.net/gentoo/dev/327773/?page=1;mh=-1; I think there is no point in continuing replying forever to this thread as I think all the technical issues has now being, at least, clarified and forwarded to the right people. As I have understood most of them belong to Portage team and now that the bug reports with the concrete suggestions were filled, they will be able to deal with them (either working on implementing the desired changes or either declining to do that if they have other opinions based on the way portage is supposed to be used by us). Then, can we please switch to different and more productive things to do? :) Thanks a lot!
Re: [gentoo-dev] Re: taking a break from arches stabilization
El mié, 12-07-2017 a las 09:13 -0500, William Hubbs escribió: > On Wed, Jul 12, 2017 at 02:30:34PM +0200, Kristian Fiskerstrand wrote: > > On 07/12/2017 01:59 PM, Michael Palimaka wrote: > > > If it's not a stable candidate then why do you use this as an example > > > against build testing-based stabilisations? If there are known issues it > > > should never reach the arch teams in the first place. > > > > This might be the crux of things, as long as automatic stabilization is > > not triggered by some set of rules (e.g 30 days in ~arch) , and still > > requires manual trigger by, preferably, the maintainer there is likely > > no issue. > > This doesn't make sense. If I have to trigger automatic stabilization, it > isn't automatic any more. > > I think with an appropriate set of rules automatic stabilization would > be fine. For example: > > - foo-2.0 has been in ~arch for 30 days > - there are no open bugs against foo-2.0 > - an older version of foo is stable > - all of the dependencies of foo-2.0 are stable > > If those conditions are met, in theory there shouldn't be any problem > with stabilizing foo-2.0. > > If foo-2.0 is not a stabilization candidate, there probably should be an > open bug in bugzilla stating why it isn't. > > Thanks, > > William > Also please note that, when we were filling that automatic bug reports, there were still an additional 60 days timeout (I think it was 60 days.. but I don't remember if even 90 days) to allow maintainers to react. Only if nothing was noted in relevant bug reports, arches were CCed automatically by the script
Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values
El lun, 10-07-2017 a las 11:55 -0500, William Hubbs escribió: > On Mon, Jul 10, 2017 at 01:04:10PM +0200, Pacho Ramos wrote: > > Hello > > > > Looking to the list of packages still not supporting python 3.5: > > https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt > > > > and considering that we should even start testing python 3.6, I think it > > would > > be nice if we could make portage to warn when PYTHON_COMPAT value is not > > updated. It's really frustrating to still see new ebuilds being added with > > obsolete values for PYTHON_COMPAT and relying on a few people looking to > > update > > this. This is also causing huge delays to migrate to newer python versions > > and I > > think it's responsibility of the maintainer to ensure his/her package is > > supported on newer versions or, at least, have a bug and ping upstream for > > the > > cases they need further fixing. > > > > Of course, this wouldn't be a fatal check preventing you from committing a > > package with outdated PYTHON_COMPAT, it would be a warning to remind you to > > update it as soon as possible. > > > > Any issues on trying to go further into implementing this warning? > > What about the situation where a package is not compatible with newer > versions of python so does not need a PYTHON_COMPAT change? > > I don't think you can assume PYTHON_COMPAT is outdated for a package > just because it doesn't have the latest versions of python > listed. The only time you can know for sure that it is outdated is if it > lists a version of python that no longer exists in the tree. > > William > Maybe we could handle it like other warnings: ignore it but ensure we have a bug report to track the issue (I have seen cases of a comment being added showing that a package wasn't ready for python 3.5 but no bug reference listed :/). It looks to me like the same we do for parallel build warnings
Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values
El lun, 10-07-2017 a las 13:12 +0200, Kristian Fiskerstrand escribió: > On 07/10/2017 01:04 PM, Pacho Ramos wrote: > > Any issues on trying to go further into implementing this warning? > > Not an issue per se, but it should be pointed out that python 3.5 only > has a testing visibility, so this at the very least requires maintainers > to potentially have a separate testing chroot/VM to test when adding the > compat. > Yes, but it's similar as the cases when we need to fix our packages to work with a newer library they depend on. In this case it would be even easier as we can have multiple python versions and switch to the newer one for testing while going back to the stable one (if preferred) later.
[gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values
Hello Looking to the list of packages still not supporting python 3.5: https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt and considering that we should even start testing python 3.6, I think it would be nice if we could make portage to warn when PYTHON_COMPAT value is not updated. It's really frustrating to still see new ebuilds being added with obsolete values for PYTHON_COMPAT and relying on a few people looking to update this. This is also causing huge delays to migrate to newer python versions and I think it's responsibility of the maintainer to ensure his/her package is supported on newer versions or, at least, have a bug and ping upstream for the cases they need further fixing. Of course, this wouldn't be a fatal check preventing you from committing a package with outdated PYTHON_COMPAT, it would be a warning to remind you to update it as soon as possible. Any issues on trying to go further into implementing this warning? Thanks a lot
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: dev-ml/fort media-libs/embree x11-wm/i3
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: dev-lua/messagepack dev-python/doit net-news/rssguard eclass/l10n.eclass
[gentoo-dev] Lastrites: 4 packages incompatible with ffmpeg-3
# Pacho Ramos <pa...@gentoo.org> (17 Jun 2017) # Not compatible with ffmpeg-3 (#602786), other bug reports and NPAPI # plugins support in main browsers is dying. Removal in a month. www-plugins/gnash # Pacho Ramos <pa...@gentoo.org> (17 Jun 2017) # Not compatible with ffmpeg-3 (#591946), neither builds without ffmpeg # support (#607492) and NPAPI plugins are dying. Removal in a month. www-plugins/lightspark # Pacho Ramos <pa...@gentoo.org> (17 Jun 2017) # Not compatible with ffmpeg-3 (#589806) and needs vulnerable qtwebkit:4 # (#620740). Removal in a month. net-voip/homer # Pacho Ramos <pa...@gentoo.org> (17 Jun 2017) # Dead for ages, relies on google-code for fetching, not compatible with # ffmpeg-3 neither with latest imagemagick (#575988). Removal in a month. media-sound/gejengel
[gentoo-dev] Lastrites: dev-libs/radlib, net-voip/gnugk, sci-electronics/ghdl...
# Pacho Ramos <pa...@gentoo.org> (14 Jun 2017) # Fails to build, nothing needs it in the tree, bug #557450. Removal in a # month. dev-libs/radlib # Pacho Ramos <pa...@gentoo.org> (14 Jun 2017) # Relies on lots of dead old gnome libs, relies also on berlios.de and it is # dead for more than 8 years, bug #537708. Removal in a month. app-office/rubrica # Pacho Ramos <pa...@gentoo.org> (14 Jun 2017) # Deprecated in favor of media-fonts/dejavu since many years ago, see bug # #282754. Removal in a month. media-fonts/ttf-bitstream-vera # Pacho Ramos <pa...@gentoo.org> (14 Jun 2017) # Not needed by anything in the tree, requires an obsolete texinfo version # and is also the last consumer of gnat-gcc, bug #620982. Removal in a # month. sci-electronics/ghdl # Pacho Ramos <pa...@gentoo.org> (14 Jun 2017) # Not needed by anything in the tree, unmaintained and waiting for a major # version bump if someone wants to take care of it, bug #474738. Removal in # a month. net-voip/gnugk # Pacho Ramos <pa...@gentoo.org> (14 Jun 2017) # All consumers of this newer versions never got ported, if finally we need # to readd a even newer version of this packages with an hypothetical newer # Ekiga, we will need to work on new ebuilds anyway, bug #474740. Removal in # a month. # # Chí-Thanh Christopher Nguyễn <chith...@gentoo.org> (25 Jun 2013) # Mask new ptlib/opal for breakage, tracked in bug #474742 # Lars Wendler <polynomia...@gentoo.org> (29 Apr 2014) # Adjusted mask so newer versions get covered as well. >=net-libs/ptlib-2.12.0 >=net-libs/opal-3.12.0 # Pacho Ramos <pa...@gentoo.org> (14 Jun 2017) # Not needed by anything in the tree, dead since 2006 and also needing our # rpm package that is buggy and unmaintained, bug # 620986. Removal in a # month. app-emulation/domi # Pacho Ramos <pa...@gentoo.org> (14 Jun 2017) # Needs someone with the hardware to test how to install it (and its # configuration files) properly. Dead since 2007, bug #493898. Removal in a # month. dev-lang/nqc
Re: [gentoo-dev] Last rites: www-client/phantomjs and dev-ruby/poltergeist
El lun, 05-06-2017 a las 13:42 -0400, Michael Orlitzky escribió: > On 06/05/2017 07:06 AM, Kent Fredric wrote: > > On Mon, 05 Jun 2017 09:11:27 +0200 > > Hans de Graaffwrote: > > > > > # Hans de Graaff (05 Jun 2017) > > > # Bundles obsolete and vulnerable webkit version. > > > # Upstream has stopped development and recommends using > > > # headless mode in >=www-client/chromium-59. > > > # Masked for removal in 30 days. Bug #589994. > > > www-client/phantomjs > > > > Can phantomjs be simply masked for a longer period until the development > > world has had an opportunity to catch up? > > > > The real reason for the mask is that it bundles an ancient version of > qtwebkit with a ton of known security vulnerabilities. Hans was > attempting to fix it, but now that upstream is dead, it will remain > insecure forever. > Also, current stable version cannot be built with stable gcc, and latest version also have lots of unresolved bugs (some building bugs) apart of the security issues affecting all versions
[gentoo-dev] Lastrites: x11-misc/rednotebook
# Pacho Ramos <pa...@gentoo.org> (02 Jun 2017) # Relies on obsolete and vulnerable webkit-gtk version and bundles some libs # (#597532). Removal in a month. x11-misc/rednotebook
[gentoo-dev] Lastrites: x11-misc/outwiker and www-client/xombrero
# Pacho Ramos <pa...@gentoo.org> (02 Jun 2017) # This package needs a maintainer to take care of updating this to a working # version not requiring obsolete wxwidgets and webkit versions (#584170). # Removal in a month. x11-misc/outwiker # Pacho Ramos <pa...@gentoo.org> (02 Jun 2017) # Still relies on old and vulnerable webkit-gtk versions, bug #608626. # Removal in a month. www-client/xombrero