Re: [gentoo-dev] New project: binhost

[Andreas K . Hüttel]

> Some ideas for portage enhancements:
> 
> 1.  Ability to fetch binary packages from some kind of repo.
> 2.  Ability to have multiple binary packages co-exist in a repo (local
> or remote) with different build attributes (arch, USE, CFLAGS,
> DEPENDS, whatever).
> 3.  Ability to pick the most appropriate binary packages to use based
> on user preferences (with a mix of hard and soft preferences).

The more definite answer should come from Zac, but I think a good part of this 
is already implemented. :)



-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] New project: binhost

[Andreas K . Hüttel]

Hi all, 

I'm announcing a new project here - "binhost"

"The Gentoo Binhost project aims to provide readily installable, precompiled 
packages for a subset of configurations, via central binary package hosting. 
Currently we are still in the conceptual planning stage. "

https://wiki.gentoo.org/wiki/Project:Binhost

If you're interested in helping out, feel free to add yourself on the wiki 
page.

Note that I see actually *building* the packages not as the central point of 
the project (that could be e.g. a side effect of a tinderbox). I'm more 
concerned about
* what configurations should we use
* what portage features are still needed or need improvements (e.g. binpkg 
signing and verification)
* how should hosting look like
* and how we can test this on a limited scale before it goes "into production"
* ...

Comments, ideas, flamebaits? :D

Cheers, 
Andreas

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?

[Andreas K . Hüttel]

Am Freitag, 8. Januar 2021, 14:26:32 EET schrieb Joonas Niilola:

> # Now my question is, does anyone find any of these packages useful?
> Should we go ahead and last-rite them, since it doesn't seem useful to
> carry these in Gentoo? The ones broken are heading towards last-riting
> nevertheless.

We have done such cleanups in the past. Libraries without consumers in the 
Gentoo tree make in general only limited sense.

That said, if they build and have an active maintainer, why not keep them for 
now.

This is more or less a cost/benefit question.

> 
> # So the final list of "useless" libs is:
> dev-libs/atcore
> dev-libs/bcm2835
> dev-libs/bitset
> dev-libs/boost-mpl-cartesian_product
> dev-libs/caliper
> dev-libs/clhpp
> dev-libs/distorm64
> dev-libs/editline
> dev-libs/faxpp
> dev-libs/go-usb
> dev-libs/gtx
> dev-libs/igraph
> dev-libs/ilbc-rfc3951
> dev-libs/injeqt
> dev-libs/jthread
> dev-libs/kqoauth
> dev-libs/libdivsufsort
> dev-libs/libdnsres
> dev-libs/libezV24
> dev-libs/libgcrypt-compat
> dev-libs/libpcre-debian
> dev-libs/libtomfloat
> dev-libs/libtompoly
> dev-libs/libtreadstone
> dev-libs/log4sh
> dev-libs/nss-pem
> dev-libs/OpenSRF
> dev-libs/pigpio
> dev-libs/processor-trace
> dev-libs/rapidxml
> dev-libs/redland-bindings
> dev-libs/rinutils
> dev-libs/rocm-hostcall
> dev-libs/smack
> dev-libs/squareball
> dev-libs/ustr
> dev-libs/vc-intrinsics
> dev-libs/xbyak
> dev-libs/zookeeper-c
> media-libs/cimg
> media-libs/elles_icc_profiles
> media-libs/esdl
> media-libs/fluidsynth-dssi
> media-libs/freeverb3
> media-libs/gmtk
> media-libs/gnonlin
> media-libs/guilib
> media-libs/intel-mediasdk
> media-libs/kodi-platform
> media-libs/libggigcp
> media-libs/libggimisc
> media-libs/libgroove
> media-libs/liblingoteach
> media-libs/libyami
> media-libs/memphis
> media-libs/noise-suppression-for-voice
> media-libs/raul
> media-libs/sdl-terminal
> media-libs/volpack
> 
> 
> -- juippis


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Dissolving project desktop-misc

[Andreas K . Hüttel]

>
> x11-misc/xsnow
>

And this one of course. There's a version bump available that works in modern 
window managers. :)

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Dissolving project desktop-misc

[Andreas K . Hüttel]

> x11-misc/xosview
> x11-misc/xteddy

Taking these two.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Dissolving project desktop-misc

[Andreas K . Hüttel]

Am Donnerstag, 26. November 2020, 22:20:55 EET schrieb Jonas Stein:
> Dear all,
> 
> sorting packages in a group of "misc" packages was not useful.
> We have to dissolve the project desktop-misc
[snip]

List of packages, please adopt:

app-admin/usbview
app-editors/beaver
app-misc/banner
app-misc/emelfm2
app-misc/gentoo
app-misc/logitech-applet
app-misc/oneko
app-misc/remind
app-text/xchm
dev-util/regexxer
gnome-extra/synapse
sys-apps/mount-gtk
sys-apps/pmount-gui
www-client/dillo
www-plugins/adobe-flash (last rited)
x11-apps/amlc
x11-libs/c++-gtk-utils
x11-libs/fltk
x11-misc/3ddesktop
x11-misc/accessx
x11-misc/apwal
x11-misc/arandr
x11-misc/autocutsel
x11-misc/bbacpi
x11-misc/cairo-clock
x11-misc/cbatticon
x11-misc/chgres
x11-misc/dclock
x11-misc/devilspie
x11-misc/devilspie2
x11-misc/dunst
x11-misc/dxpc
x11-misc/dzen
x11-misc/easystroke
x11-misc/efax-gtk
x11-misc/evolvotron
x11-misc/fbpanel
x11-misc/fireflies
x11-misc/fracplanet
x11-misc/fraqtive
x11-misc/gbase
x11-misc/gmrun
x11-misc/grabc
x11-misc/grun
x11-misc/gtk2fontsel
x11-misc/gtkdialog
x11-misc/gxmessage
x11-misc/habak
x11-misc/hsetroot
x11-misc/i3lock
x11-misc/i3status
x11-misc/i855crt
x11-misc/iconbox
x11-misc/idesk
x11-misc/imwheel
x11-misc/kapow
x11-misc/lineak-defaultplugin
x11-misc/lineak-xosdplugin
x11-misc/lineakd
x11-misc/macopix
x11-misc/menulibre
x11-misc/mgm
x11-misc/nitrogen
x11-misc/numlockx
x11-misc/openbox-menu
x11-misc/parcellite
x11-misc/piedock
x11-misc/read-edid
x11-misc/rofi
x11-misc/rss-glx
x11-misc/simpleswitcher
x11-misc/sisctrl
x11-misc/skippy
x11-misc/sselp
x11-misc/superswitcher
x11-misc/sux
x11-misc/svkbd
x11-misc/synergy
x11-misc/trayer
x11-misc/unclutter
x11-misc/vnc2swf
x11-misc/vym
x11-misc/wayv
x11-misc/wbar
x11-misc/wdm
x11-misc/wininfo
x11-misc/x2vnc
x11-misc/x2x
x11-misc/xautolock
x11-misc/xautomation
x11-misc/xbatt
x11-misc/xbattbar
x11-misc/xbindkeys
x11-misc/xcalendar
x11-misc/xcave
x11-misc/xcb
x11-misc/xclip
x11-misc/xdaliclock
x11-misc/xdesktopwaves
x11-misc/xdialog
x11-misc/xdiskusage
x11-misc/xdotool
x11-misc/xearth
x11-misc/xfe
x11-misc/xfishtank
x11-misc/xhkeys
x11-misc/xkbd
x11-misc/xkeycaps
x11-misc/xlockmore
x11-misc/xmountains
x11-misc/xnee
x11-misc/xnots
x11-misc/xosview
x11-misc/xpad
x11-misc/xplanet
x11-misc/xrestop
x11-misc/xrootconsole
x11-misc/xscreensaver
x11-misc/xscreensaver-app
x11-misc/xsel
x11-misc/xsensors
x11-misc/xsetleds
x11-misc/xsnap
x11-misc/xsnow
x11-misc/xsri
x11-misc/xstroke
x11-misc/xteddy
x11-misc/xtoolwait
x11-misc/xtrlock
x11-misc/xvkbd
x11-misc/xwit
x11-misc/xwrits
x11-misc/xxkb
x11-terms/guake
x11-terms/lilyterm
x11-terms/sakura
x11-themes/blueglass-xcursors
x11-themes/faenza-icon-theme
x11-themes/flatsvg
x11-themes/fvwm-themes-extra
x11-themes/gargantuan-icon-theme
x11-themes/gartoon
x11-themes/gartoon-redux
x11-themes/gnome-colors-common
x11-themes/gnome-colors-themes
x11-themes/golden-xcursors
x11-themes/greybird
x11-themes/gtk-engines-aurora
x11-themes/gtk-engines-candido
x11-themes/gtk-engines-rezlooks
x11-themes/gtk-engines-ubuntulooks
x11-themes/gtk-theme-switch
x11-themes/haematite-xcursors
x11-themes/human-icon-theme
x11-themes/nimbus
x11-themes/nou-icon-theme
x11-themes/nuovo-icon-theme
x11-themes/obsidian-xcursors
x11-themes/pearlgrey-xcursors
x11-themes/redhat-artwork
x11-themes/shiki-colors
x11-themes/silver-xcursors
x11-themes/tactile
x11-themes/tactile3
x11-themes/tangerine-icon-theme
x11-themes/yasis-icon-theme
x11-themes/zukini


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] A feedback about the CI bug reporting system

[Andreas K . Hüttel]

Am Samstag, 7. November 2020, 10:26:27 EET schrieb Agostino Sarubbo:
> On sabato 7 novembre 2020 07:15:31 CET Robin H. Johnson wrote:
> > Can you please tell us what you need to let others contribute to
> > improving the quality of the reports from your CI system?
> 
> Hello Robin,
> 
> I don't understand why in general people focus on what is missing into a
> simple script that merges packages instead of ask himself where this feature
> should go.

Ago, 

this whole thread started out about the quality of the bug reports. However... 
Seriously, with the insistence to keep your setup closed-source, you are not 
helping your case. 

If you want this to be an in any way official Gentoo project, you'll have to 
stick to the Gentoo social contract just like everyone else.

Cheers,
Andreas

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement

[Andreas K . Hüttel]

For the record, 

> net-dns/libidn2

* added also toolchain (glibc dependency)

> net-misc/chrony

* added also base-system



-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Deprecating AMD64 17.0 profiles?

[Andreas K . Hüttel]

Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny:
> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
> > Users frequently are choosing the wrong profile versions in new installs
> > and accidentally downgrading to 17.0 with some saying they see it first.
> > 
> > A simple reordering could help new installs.

Independent of this useful change, it's probably time to deprecate the amd64 
17.0 profiles!

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] news item: riscv multilib profile is going away

[Andreas K . Hüttel]

[** Note 1: This only affects one specific profile. **]
[** Note 2: I am still testing the migration process proposed here. **]

Title: riscv multilib profile is going away
Author: Andreas K. Hüttel 
Posted: 2020-09-06
Revision: 1
News-Item-Format: 2.0
Display-If-Profile: default/linux/riscv/17.0/rv64gc

The Gentoo RISC-V team is discontinuing the riscv64 multilib stages and
profile. The main reason for this is that with the upcoming introduction
of riscv32 a multilib stage would contain both 32bit and 64bit binaries,
and so far no hardware exists that is able to run both and thus update
the stage or installation (unless you use qemu).

Please switch to the rv64gc/lp64d profile. This is done by
* selecting default/linux/riscv/17.0/rv64gc/lp64d with eselect profile
* rebuilding gcc
emerge -1 sys-devel/gcc
* and then rebuilding your system
emerge -ev @world

The default/linux/riscv/17.0/rv64gc profile will stop functioning soon.



-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Fwd: [JuliaLang] Pkg downtime incident

[Andreas K . Hüttel]

/unsubscribe/
5dcc8fe0a5dab8380516e5d33481407163067880c0e37e4db5d9c1772dabf1d2).

-
-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] last rites: sys-kernel/genkernel-next

[Andreas K . Hüttel]

# Andreas K. Hüttel  (2020-07-11)
# Fails to build with recent glibc, bug 719968
# Removal in 30 days
sys-kernel/genkernel-next


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Last 24h for voting in council election

[Andreas K . Hüttel]

Hi all, 

the last 24 for voting in the council election start soon...

GO VOTE :)

Cheers -A

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [RFC] Codec project

[Andreas K . Hüttel]

> 1. Should the project be focused on reference/most common
> implementations, or maybe more of them?  Say, giflib vs libnsgif.
> I think the latter library is specific to a few programs right now but
> if it gets more popular, it would fit.

It's mostly a question of critical mass. To give an example from a different 
corner of Gentoo...

Initially net-libs/libtirpc was more of an obscurity, a more feature-complete 
replacement for code within glibc. Back then it didn't matter so much who 
maintained it.
In the meantime, the corresponding part of glibc has been phased out, and 
everyone is relying on libtirpc. So now it's important that it is well-
maintained, and it's taken care of by base@.

> 2. How many kinds of media should the project accept?  Audio, graphics,
> video seem pretty obvious.  Containers too.  libass makes sense as it is
> specifically for video subtitles.  Anything else?

Again, critical mass should be the main criterion. Things that are used by 
many different packages, with many different maintainers.

If a library is only used by LibreOffice, it makes more sence that it is 
maintained by office@. If a library is used exclusively via kde-frameworks, 
the same for kde@.

I wouldn't be too restrictive regarding the type of media.

> 3. What about libraries implementing media-specific streaming protocols?
> E.g. libshout, live...  I suppose the ones specific to voip would fall
> into voip project's domain instead.

Same arguments...

> 
> 
> [1]
> https://archives.gentoo.org/gentoo-dev/message/79073ab9c7cebd79fc12e897e110
> bc3c [2] https://wiki.gentoo.org/wiki/Project:Codec_project


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]

[Andreas K . Hüttel]

Am Montag, 8. Juni 2020, 19:02:51 EEST schrieb Michał Górny:
> Maybe it'd make sense to create a new project that is focused
> on maintaining core libraries for gfx/audio/video formats (technical
> name: codec project)?  Right now, sound and video teams are also
> suffering from similar problems.  On one hand, it makes little sense to
> create huge projects that maintain every single kind of gfx/sound/video-
> related tool ever made, on the other it doesn't exactly make sense to
> require every single core library to have an individual maintainer.

Count me in. 

https://wiki.gentoo.org/wiki/Project:Codec_project

Here's the page. I consider this started once 3 other people have joined...

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?

[Andreas K . Hüttel]

> Project Graphics was now deleted 

Inofficially a graphics@ maintainership of a package meant "fix the bugs 
yourself" for quite some time already. So I doubt the current state got worse 
via the removal of the project. 

That said, this is actually for a subset of the packages one of the cases 
where a project would really make sense. We have a lot of central libraries 
here that are used by many other software. libpng, jpeg, tiff, ... These are 
definitely worth a team of maintainers.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?

[Andreas K . Hüttel]

> Now for the future, I wouldn't mind having a "last rite: XYV Project" or
> similar e-mail sent to gentoo-dev{-announce} before action to ebuilds is
> taken, so the project members/lead has one final chance to stop it.

Good plan.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]

[Andreas K . Hüttel]

OK so if you really want to go through with this then I'll take these.

> media-gfx/album
> media-gfx/enblend
> media-gfx/exiv2
> media-gfx/gphoto2
> media-gfx/hugin
> media-gfx/imagemagick
> media-gfx/jpeg2ps
> media-gfx/jhead
> media-gfx/luminance-hdr
> media-gfx/pngquant
> media-libs/lensfun
> media-libs/libgphoto2

That said, I think the basic action is in this case pretty unproductive. We 
now have a large number of central libraries maintainer-needed (libpng, jpeg, 
tiff, ...) which would really merit a team...


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests

[Andreas K . Hüttel]

> Works great for whom?  How many deployments are we talking about?  To be
> honest, I don't think I've stumbled upon a single instance.
> On the other hand, GitLab deployments are pretty common -- GNOME, Xfce,
> Debian come instantly to my mind.  Then, there's Heptapod -- the GitLab
> fork for Mercurial.

KDE also just migrated to GitLab.

> 
> > Gerrit is widely used for large projects and I'm not worried for ::gentoo
> > and we have deployed gerrit and it seems to work fine. Gerrit doesn't have
> > CI (we would need to deploy something) and it uses gitweb for repository
> > browsing (which we use today.)
> 
> Not to mention it's ugly and I found it cumbersome to use.

Everytime I tried to use Gerrit I got so thouroughly confused that I gave up 
after a while.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

[Andreas K . Hüttel]

> This patch makes migrating mandatory by forcing ebuilds to die if they
> have EGO_VENDOR set and are using go-module.eclass.

You can't commit this as long as there is a single such ebuild in the tree. 



-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [gentoostats continued] Collected data and justification for it

[Andreas K . Hüttel]

> 
> I think we shouldn't collect any data unless we have a good plan on how
> we'd be able to use it.  In this thread, I'd like to collect ideas
> on what data to collect and how it could realistically be used.
> 

5) CFLAGS and possibly related variables
6) "active" version of slotted system packages (gcc, binutils, python, ???)

I see this as interesting for the toolchain maintenance, but also interesting 
in general since we are a source-based distro.

* How many users are running LTO? doing Profiling? building generic (-
march=x86_64) packages? using -Os or -O3, -funroll-loop (just kidding)
* How quick is gcc / binutils / ... adoption?
* clang usage?


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] De-stabilizing and re-stabilizing (on amd64 only)

[Andreas K . Hüttel]

Hi all, 

quite some packages were un-stabilized across the tree recently. 

In general that is in my opinion a good thing if it helps us keep up, in 
particular where many arches are involved.

What's the general opinion on re-stabilizing things on *amd64* only?

I would say that maintaining a larger stable tree is comparatively easy there, 
since everyone of us devs is running (I guess) an amd64 machine and can 
stabilize own packages.

Background, I tried to locally emulate www.g.o using jekyll, and ran into 
troubles because lots of dev-ruby/* lost stable keywords. Newest ~arch didn't 
do the job, so I needed to figure out the config of www.g.o (corresponding to 
former stable) first... 

Cheers, 
Andreas

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Cleaning up the installation handbook (Legacy boot / MBR / ...)

[Andreas K . Hüttel]

Hey all, 

our installation handbook is right now something of a mess (in particular 
regarding partitioning, bootloader, gpt/uefi, ...)

I'm hereby volunteering to clean things up. But - I'll go the brutal way:

* Legacy boot and MBR will get kicked out. *

This is your chance to protest or support.

Cheers,
Andreas


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] last rites: dev-tex/revtex

[Andreas K . Hüttel]

# Andreas K. Hüttel  (2020-05-02)
# Included in recent texlive versions. Please uninstall.
# Removal in 30 days.
dev-tex/revtex

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation

[Andreas K . Hüttel]

Am Sonntag, 26. April 2020, 12:09:59 EEST schrieb Ulrich Mueller:
> >>>>> On Sun, 26 Apr 2020, Michał Górny wrote:
> > The other major problem is spam protection.  The best semi-anonymous way
> > I see is to use submitter's IPv4 addresses (can we support IPv6 then?).
> > We could set a limit of, say, 10 submissions per IPv4 address per week.
> > If some address would exceed that limit, we could require CAPTCHA
> > authorization.
> 
> Instead of using the IP address, you could generate a UUID when
> installing the tool. This would also take care of clusters with machines
> that are clones of each other.
> 

TBH, for clusters I would insert a sentence like
"If you are administering a cluster of many identical Gentoo machines, please 
see $WIKIPAGE before enabling submission"

and there then have a few more instructions (like how to enable only for one 
machine, and additionally provide us with the cluster size). I guess in this 
case we can add this further step, since whoever is doing that will be both 
invested in Gentoo and able to read docs.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [RFC] CC-ARCHES keyword on Bugzilla

[Andreas K . Hüttel]

> let's
> add a 'CC-ARCHES' keyword to Bugzilla.  If a bug is marked with that
> keyword and passes sanity check, NATTkA will automatically CC all
> relevant arch teams (based on keyword list).
> 
> What do you think?

Sounds great. Do it! :)

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [PATCH v3 6/9] glep-0072: Combine and amend description of states

[Andreas K . Hüttel]

> > [Maybe someone who actually does slow-arch work should speak up. Anyone
> > out
> > there still reading g-dev?]
> 
> I'm lost.  The original definition said that this state is for arches
> that use stable only on subset of packages needed for stage building.
> Why would people file streqs for other packages then?

Shrug. I'm not going to fight here for anything. 

Just my experience after some arches lost stable status was that these arch 
people still wanted to get CC'ed in stabilization requests. If only to keep 
track.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [PATCH v3 6/9] glep-0072: Combine and amend description of states

[Andreas K . Hüttel]

> +Transitional architectures are generally listed after stable architectures,
> +possibly mixed with testing.  Developers are not expected to file
> stabilization +requests.

I'm still claiming that it would be more useful to have the stable requests 
for transitional arches, even if we explicitly state that they can't block 
anything. 

Otherwise these arches will never be able to get out of the transitional hole.

[Maybe someone who actually does slow-arch work should speak up. Anyone out 
there still reading g-dev?]

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [PATCH 03/10] glep-0072: Rename bad depgraph state to 'degraded'

[Andreas K . Hüttel]

Am Samstag, 11. April 2020, 14:23:48 EEST schrieb Michał Górny:
> On Sat, 2020-04-11 at 12:08 +0200, Ulrich Mueller wrote:
> > > > > > > On Sat, 11 Apr 2020, Michał Górny wrote:
> > > Thinking about it, all these terms seem too generic.  Would be nice to
> > > find one that clearly suggests it's between testing and stable, and not
> > > 'lenient' in ~arch.  How about 'transitional' or 'incomplete-stable'?
> > 
> > "interim"?
> 
> half-ass-stable?  ;-)

transcendent ...

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [PATCH 00/10] GLEP 72 (arches.desc) revival

[Andreas K . Hüttel]

> 
> => Keep it simple: Stable should mean the same across all architectures

OK, this is a definite statement, so stable remains stable, and we introduce no 
additionally different status. 

I'd recommend that you drop the "security-supported arches" list from the 
security team web page too.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [PATCH 07/10] glep-0072: Combine and amend description of states

[Andreas K . Hüttel]

> > "Developers should file stabilization requests, however, pending
> > stabilization on these arches alone cannot block any further steps (as,
> > e.g., cleanup of old versions)."
> 
> Isn't that implied by exp status, i.e. separate from this?

Hmm... do all "degraded" profiles have to be "exp"?
(Need to get the coffee first.)

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [PATCH 00/10] GLEP 72 (arches.desc) revival

[Andreas K . Hüttel]

Am Freitag, 10. April 2020, 09:58:37 EEST schrieb Michał Górny:
> 
> 1. 'Broken' status was removed, as it is redundant to profile status.
> 
> 2. State names were changed from 'testing' and 'unstable' to 'degraded'
>(broken stable tree) and 'testing' (pure ~arch) to avoid confusion.
> 

Back in time there was also the idea to use this file to indicate security 
support of an arch. The suggestion was to introduce another column, but I 
found that rather horrible.

So a better idea would be to introduce an additional status "security", 
designating "stable with security support".

(Acts in every other respect exactly like "stable".)

What do you think?

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [PATCH 07/10] glep-0072: Combine and amend description of states

[Andreas K . Hüttel]

Am Freitag, 10. April 2020, 09:58:44 EEST schrieb Michał Górny:

>  Developers are not expected to file
> stabilization +requests.

This kinda changed in usage in the meantime (for, say, stuff like sparc and 
s390). The request was to CC them in the stabilization bugs if relevant.

How about
"Developers should file stabilization requests, however, pending stabilization 
on these arches alone cannot block any further steps (as, e.g., cleanup of old 
versions)."

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] [PATCH 3/5] depend.apache.eclass: Add missing function want_apache2_4

[Andreas K . Hüttel]

---
 eclass/depend.apache.eclass | 17 +
 1 file changed, 17 insertions(+)

diff --git a/eclass/depend.apache.eclass b/eclass/depend.apache.eclass
index e858a85..a51ec55 100644
--- a/eclass/depend.apache.eclass
+++ b/eclass/depend.apache.eclass
@@ -225,6 +225,23 @@ want_apache2_2() {
RDEPEND="${RDEPEND} ${myiuse}? ( ${APACHE2_2_DEPEND} )"
 }
 
+# @FUNCTION: want_apache2_4
+# @USAGE: [myiuse]
+# @DESCRIPTION:
+# An ebuild calls this to get the dependency information for optional
+# apache-2.4.x support. If the myiuse parameter is not given it defaults to
+# apache2.
+# An ebuild should additionally call depend.apache_pkg_setup() in pkg_setup()
+# with the same myiuse parameter.
+want_apache2_4() {
+   debug-print-function $FUNCNAME $*
+
+   local myiuse=${1:-apache2}
+   IUSE="${IUSE} ${myiuse}"
+   DEPEND="${DEPEND} ${myiuse}? ( ${APACHE2_4_DEPEND} )"
+   RDEPEND="${RDEPEND} ${myiuse}? ( ${APACHE2_4_DEPEND} )"
+}
+
 # @FUNCTION: need_apache
 # @DESCRIPTION:
 # An ebuild calls this to get the dependency information for apache.
-- 
2.11.0.rc2

[gentoo-dev] [PATCH 5/5] depend.apache.eclass: Restructure pkg_setup so in_iuse is used from EAPI=6 on

[Andreas K . Hüttel]

---
 eclass/depend.apache.eclass | 31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/eclass/depend.apache.eclass b/eclass/depend.apache.eclass
index 8582396..2d7b062 100644
--- a/eclass/depend.apache.eclass
+++ b/eclass/depend.apache.eclass
@@ -176,21 +176,28 @@ depend.apache_pkg_setup() {
fi
 
local myiuse=${1:-apache2}
-   if has ${myiuse} ${IUSE}; then
-   if use ${myiuse}; then
-   case ${EAPI:-0} in
-   0|2|3|4|5)
+
+   case ${EAPI:-0} in
+   0|2|3|4|5)
+   if has ${myiuse} ${IUSE}; then
+   if use ${myiuse}; then
_init_apache2
-   ;;
-   *)
+   else
+   _init_no_apache
+   fi
+   fi
+   ;;
+   *)
+   if in_iuse ${myiuse}; then
+   if use ${myiuse}; then
_init_apache2
_init_apache2_late
-   ;;
-   esac
-   else
-   _init_no_apache
-   fi
-   fi
+   else
+   _init_no_apache
+   fi
+   fi
+   ;;
+   esac
 }
 
 # @FUNCTION: want_apache
-- 
2.11.0.rc2

[gentoo-dev] [PATCH 2/5] depend.apache.eclass: Disallow EAPI=1

[Andreas K . Hüttel]

---
 eclass/depend.apache.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/depend.apache.eclass b/eclass/depend.apache.eclass
index a7d206f..e858a85 100644
--- a/eclass/depend.apache.eclass
+++ b/eclass/depend.apache.eclass
@@ -43,7 +43,7 @@
 inherit multilib
 
 case ${EAPI:-0} in
-   0|1|2|3|4|5)
+   0|2|3|4|5)
;;
6)
ewarn
-- 
2.11.0.rc2

[gentoo-dev] [PATCH 1/5] depend.apache.eclass: Replace build_with_use with has_version

[Andreas K . Hüttel]

From: Doug Freed 

---
 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 b69c2ec..a7d206f 100644
--- a/eclass/depend.apache.eclass
+++ b/eclass/depend.apache.eclass
@@ -290,7 +290,7 @@ has_apache() {
 has_apache_threads() {
debug-print-function $FUNCNAME $*
 
-   if ! built_with_use www-servers/apache threads; then
+   if ! has_version 'www-servers/apache[threads]'; then
return
fi
 
@@ -313,14 +313,14 @@ has_apache_threads() {
 has_apache_threads_in() {
debug-print-function $FUNCNAME $*
 
-   if ! built_with_use www-servers/apache threads; then
+   if ! has_version 'www-servers/apache[threads]'; then
return
fi
 
local myforeign="$1"
local myflag="${2:-threads}"
 
-   if ! built_with_use ${myforeign} ${myflag}; then
+   if ! has_version "${myforeign}[${myflag}]"; then
echo
eerror "You need to enable USE flag '${myflag}' in ${myforeign} 
to"
eerror "build a thread-safe version of ${CATEGORY}/${PN} for 
use"
-- 
2.11.0.rc2

[gentoo-dev] [PATCH 4/5] depend.apache.eclass: For EAPI=6, move initialization of APACHE_BASEDIR and APACHE_MODULESDIR into pkg_setup

[Andreas K . Hüttel]

---
 eclass/depend.apache.eclass | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/eclass/depend.apache.eclass b/eclass/depend.apache.eclass
index a51ec55..8582396 100644
--- a/eclass/depend.apache.eclass
+++ b/eclass/depend.apache.eclass
@@ -40,17 +40,11 @@
 # }
 # @CODE
 
-inherit multilib
-
 case ${EAPI:-0} in
0|2|3|4|5)
+   inherit multilib
;;
6)
-   ewarn
-   ewarn "EAPI=${EAPI} is not supported by depend.apache.eclass."
-   ewarn "This means that ${CATEGORY}/${PF} is most likely buggy."
-   ewarn "Please file a report on https://bugs.gentoo.org/;
-   ewarn
;;
*)
die "EAPI=${EAPI} is not supported by depend.apache.eclass"
@@ -84,7 +78,8 @@ esac
 # @ECLASS-VARIABLE: APACHE_BASEDIR
 # @DESCRIPTION:
 # Path to the server root directory.
-# This variable is set by the want/need_apache functions.
+# This variable is set by the want/need_apache functions (EAPI=0 through 5)
+# or depend.apache_pkg_setup (EAPI=6 and later).
 
 # @ECLASS-VARIABLE: APACHE_CONFDIR
 # @DESCRIPTION:
@@ -104,7 +99,8 @@ esac
 # @ECLASS-VARIABLE: APACHE_MODULESDIR
 # @DESCRIPTION:
 # Path where we install modules.
-# This variable is set by the want/need_apache functions.
+# This variable is set by the want/need_apache functions (EAPI=0 through 5)
+# or depend.apache_pkg_setup (EAPI=6 and later).
 
 # @ECLASS-VARIABLE: APACHE_DEPEND
 # @DESCRIPTION:
@@ -141,10 +137,19 @@ _init_apache2() {
APACHE_BIN="/usr/sbin/apache2"
APACHE_CTL="/usr/sbin/apache2ctl"
APACHE_INCLUDEDIR="/usr/include/apache2"
-   APACHE_BASEDIR="/usr/$(get_libdir)/apache2"
APACHE_CONFDIR="/etc/apache2"
APACHE_MODULES_CONFDIR="${APACHE_CONFDIR}/modules.d"
APACHE_VHOSTS_CONFDIR="${APACHE_CONFDIR}/vhosts.d"
+
+   case ${EAPI:-0} in
+   0|2|3|4|5)
+   _init_apache2_late
+   ;;
+   esac
+}
+
+_init_apache2_late() {
+   APACHE_BASEDIR="/usr/$(get_libdir)/apache2"
APACHE_MODULESDIR="${APACHE_BASEDIR}/modules"
 }
 
@@ -173,7 +178,15 @@ depend.apache_pkg_setup() {
local myiuse=${1:-apache2}
if has ${myiuse} ${IUSE}; then
if use ${myiuse}; then
-   _init_apache2
+   case ${EAPI:-0} in
+   0|2|3|4|5)
+   _init_apache2
+   ;;
+   *)
+   _init_apache2
+   _init_apache2_late
+   ;;
+   esac
else
_init_no_apache
fi
-- 
2.11.0.rc2

Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)

[Andreas K. Hüttel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Montag, 15. August 2016, 15:03:08 schrieb Kristian Fiskerstrand:
> On 08/15/2016 02:49 PM, Dirkjan Ochtman wrote:
> > On Mon, Aug 15, 2016 at 6:29 AM, Kent Fredric <ken...@gentoo.org> wrote:
> >> This sort of stuff makes me feel bugzilla is entirely the wrong platform
> >> for handling stabilizations and keywords :/
> > 
> > I very much agree; some kind of minimal web app/API would probably be
> > better.
> 
> Could you please elaborate a bit? In particular from perspective of (i)
> integration into current workflow, (ii) complexity in application
> maintenance/hosting (iii) cost/benefit considerations

I agree that BZ is not the best platform for stabilizations (and keywording). 
(It's the one we have now, anything else creates maintenance.)

Now, if we want to come up with radical solutions...

1) Stabilization is a simpler and much more formalized process compared to 
normal bug resolution.
* There is one version to be stabilized. 
* Stabilization can be blocked by bugs of that version.
* If there are no blocking bugs, stabilization can go ahead.
Which means 
* No requirement for free-text fields
* One precise package version
Of course this does not handle the more complex cases like perl/gnome stable 
lists.

2) *If* we introduce a "Fixed-in" and maybe an "Introduced-in" field in 
Bugzilla, which gives a precise $CATEGORY/$PVR where a problem is resolved or 
introduced, the extraction of fixed or non-fixed bugs might even be 
automatized. 

- -- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXshg9AAoJEHRrah2soMK+JawQAK7c2oizH6Vu4EgDpr05y1Fi
BWFvJrqxdgyvUCxwaZMk90j88zlXvvXkbZR6xMxZytZPpXh5FVtadVmElqYJIXiD
G71Gqf0dDMuH9sku7rU9Mmm5WIzJtG0WE2b/FIddG8C5BpuaiqhDKUZcnvW5r3BW
CoLqYWfG5W5A0DiKuZbbTI4jIeHLd8BykitB8dGhT3Lvse52IAMY+9X/BCLfX0lh
WjBh4LszaEIK11zD/EEqSpCd8q6t2A52h//Xpe4a8vrY4fyvxbnULYxm088UBMuV
oOZ5cLKUSqx7BqaDoPaY5vYPBXbQkKsPFDkzEx2B115Ep9fPGpom+MrcLN3JCmL7
fk6R+K9eeACZPHqf2WiNICKnN/l6NQVrrPukDgDWZ9vGvSr1XjhnMdiKVuWOaJki
0vmYtaLJF0Aadwzwp93u/Ii1HIiy7nPU9om3LSOLMnrGbq4I9YzCiX0Az98zCPQw
DABWDOPSdNnkqwexhmlhl9xkO0LDpjbMtWlKufZY9y1mOXUatAK38iD6mcErRuxI
dSz/odmpwpmNvIx7yPc1TwRKkn7Hmr/DkHecMMnmEfqqFn2cy1FkQIMvntx5kLTY
NfS8n90UqCPcZ66xgr5MhxQMV0GKfCwQ1uS4pr9spnVUXyT/gGTnPUs8dswcFA2e
ZyTnnA+fS3uFot25Sl76
=OtNn
-END PGP SIGNATURE-

Re: [gentoo-dev] On banning merge commits

[Andreas K. Hüttel]

Am Sonntag, 8. Mai 2016, 01:52:22 schrieb Patrice Clement:
>
> What is the correct course of action? I would very much like it to be
> worded in a document (GLEP and/or Wiki page) so that confusion is avoided
> and we all are on the same page on this topic.
> 

OK here's my 2ct: 

* I'm not opposed to merge commits in principle, and see a few cases where 
they have advantages.

* Git has the provisions for nonlinear history, and just not liking spaghetti 
is no sufficient reason to castrate the entire version control system.

* However... as the past months have shown, when using merges it is much 
easier to accidentally mess up the entire tree than using rebases alone.

* So, in an ideal world we would use merges wisely and sparingly.

* In the real world, we risk less and also lose less if we ban and technically 
prevent them.

* The only alternative would be to come up with criteria for merges and 
actually enforce them (meaning, if you mess up the tree more than twice you 
lose your push access. Hello QA.).

-- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] On banning merge commits

[Andreas K. Hüttel]

Am Sonntag, 8. Mai 2016, 07:09:31 schrieb Michał Górny:
> > What is the correct course of action? I would very much like it to be
> > worded in a document (GLEP and/or Wiki page) so that confusion is
> > avoided and we all are on the same page on this topic.
> 
> You start by accepting my retirement.

I think you should take a vacation for a while... Preferably somewhere 
tropical, with no internet access and lots of beach... 

-- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/

[gentoo-dev] Last rites x11-libs/libview

[Andreas K. Hüttel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

# Andreas K. Huettel <dilfri...@gentoo.org> (19 Mar 2016)
# Dead upstream since 2010, new VMware uses new incompatible
# proprietary libview. No other consumers. Removal in 30 days.
# Bug 569930
x11-libs/libview

- -- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJW7ZA8AAoJEHRrah2soMK+m6oQAJjwn8HtkdnKSIE1R4BqbLUd
6oJ4GeOD8Pbae2VzLEMc4xe/NiV11xyh1n/bGVf5v3x0OS3E4gMZarBHTRxkuETk
XzxXkY7ZhoD1tFZX0sTmbShLMccRNPjwjc7pgc/Uq+G9atAT/KsX4WtsygGm341m
GcNpcdHro0XVcFa1cPUZjJ4DyBIIEvRBgNhuXBKWPE62TRveF4NUBraU0BLRUFDw
zrgGnXAc8Q7UUTV6DoO4VEOPGKSo43fpnrRziSkYw/PE4RtNqffsBtO2udozpKh/
gpQT355kAG/U9cuhj46eDq3bJMsuUdhlBOhyfLkYFACzd3KdwkKzW8cjKVzffjfW
z+1R5IRvFkeInUhKPDv+TVPJJ4tmL9tkESidIESRaLbRmLN1/t1MHypk/MUPZVmE
QKzUvfYUYuz2V+gNPd8Vdc65Ee84VenHstGlhfmSvzGbrL8FptxKAxaXLBcW7j60
R9C6O/BfYAvPEfenIY8e9T9Lb0zPJZIiNQMwrn7RCWXjFIRxwGIiuFBW6An8jee5
fIqdt+ZYzRj1AmFvdrIIDTzgLvQ/irKuZa5oif91T2MlKjtdBW7ys7lcI8duUADG
pWo0X3vJDkg9qOsj/4rj/Ckw/JUA8ytJ+J1+NTr+By255jZHvQxwWNPQDiTdf9nk
8+wBF1N58L1WHzZwjXz0
=XyFP
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: games.eclass policy

[Andreas K. Hüttel]

Am Samstag, 20. Februar 2016, 02:25:08 schrieb Ryan Hill:
> > 
> > Good for you. So... ignoring majority is fine as long as you can prove
> > that they don't ignore one of their old fellows. Good.
> 
> I have never had a problem talking to the games team, and I suspect the
> same is true for anyone who isn't just communicating with them to push
> their agenda.

Sadly that seems to be the case only for a select few.

I have never had any interest in games, but was in the past downright ignored 
with respect to sensible, useful, more and more urgent and while at first 
nice, polite, and respectful, later more and more forthright e-mails and other 
communication attempts regarding other aspects of gentoo. There's a certain 
overlap of persons with the games team involved. 

If you're part of a community you're expected to cooperate with the community 
(and stick to the rules of the community, but that's a different issue).

If you try to ignore everyone with a differing opinion and push your will 
through by just doing whatever you want, at some point you'll be so much in 
the minority that your opinion doesnt count anymore.

-- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/

[gentoo-dev] games.eclass deprecation - repoman warning in next portage release

[Andreas K. Hüttel]

Dear all, 

while we have taken a lot of time and called for feedback repeatedly, in the 
December 2015 meeting the council has decided (among other things, see [1])
* that /usr/games and /etc/games should not be used anymore
* that games.eclass should not be used anymore
* that games.eclass may not provide support for EAPI=6

This is to announce that starting with the next portage release, repoman will 
consider games.eclass deprecated and issue a QA warning if it is used in an 
ebuild.

For the council, 
Andreas

[1] https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt

-- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] libressl: proposing a new project and calling for help

[Andreas K. Hüttel]

On Sunday 14 February 2016 22:38:19 Anthony G. Basile wrote:
> Hi everyone,
> 
> We discussed the state of libressl today in the council.  Proceeding
> forward with that work, I'm going to propose a new project and getting
> together a team.  Much of the work has already done by hasufell and what
> remain is just following through on his plan.
> 
> Before I put up a project page, can I ask who is interested in this?

I'd gladly take part, though sadly my Gentoo time is pretty much approaching 
zero these days. But maybe that will improve some day.

-- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] Uncoordinated changes

[Andreas K. Hüttel]

On Sunday 14 February 2016 13:18:30 Rich Freeman wrote:
> 
> Feel free to peruse the various list discussions and council logs.
> Most of what you're bringing up has come up before.

Thanks rich0, you seem to be reading my mind.

This is turning into a severe case of "I didn't bother to speak up earlier or 
volunteer to improve something, and now I'm unhappy with what was decided and 
implemented."

-- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[Andreas K. Hüttel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Summarizing some (not all) points from Ian's mail:


The proxy-maintainers project is nowadays very active on the channel #gentoo-
proxy-maint. Several new and very promising contributors are showing up there, 
and generating a flurry of activity.

Since the initial purpose of proxy-maintainers was to allow users to pick up 
orphaned packages, that team has volunteered also to look at maintainer-wanted 
bugs. Sorting them is something that can also be done by not-yet-devs under 
supervision. Right now the team is discussing criteria how to handle the old 
bugs, see [1].

[1] https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Maintainer_Wanted
###

... and here's some personal remark from me: The proxy-maint project seems to 
have gotten a good start now, with an active but informal community of 
interested users forming on the channel, submitting e.g. pull requests and 
discussing ebuild topics. As dev, please consider helping out there; more eyes 
not just improve code quality, but also response times and community 
coherence.

Cheers, 
Andreas

- -- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWpPAoAAoJEHRrah2soMK+yj0QAMuNz82REqd2FofJ5OAWyMNI
8giKqlB5cOIz2I14jVa2WfizQ0EP/LpVGFpAD5bVNy4/gvgFUr6fDfJfF3onhpS8
sLika3JngeGgALYB131l0flavm1jsNdE67ysxcCsb4ilsVjHw5eEOCDonRR2fMIY
RmuzyH2wimH1yM9DP7MvniRDqbAFvsMWz+7UZferZF9NCAnpLJJuYD+T/jgbZ/G4
M47mc0JEkNEcenz0f/ZHKNcyG37oXz3ZCG4IWhGl93tw449xF0VQXbyxk4HAqR6C
oYZPRvIXVqaou8ONcxsIqxITSaxBfNbx49oHWXKdbnMTwhO66mflZ4TegCpLBBhA
9k1oYgE7wdUGB8lg2FDecNy0sSkmHH0BZS1eYJcn6uCXor6gF+jr/LkrHPpp9OD3
XfkZ3p1CGmUUQoA908cZ8KDEP66FPmxqud+HUDAHk64ah7ohlwv2Qhe7nvvSCFPA
T34MfrPm2QfQ2HZq9PSj/uagwBixovnmED/tghosJaThlLkFdc5kVSp3qiSidbT1
y8e9pOWSCm4dax6EM/MXZdW9EDHqlCPmkfeHke9vrx9Im7U6nEVMZbF8xSegjkEk
hfmR8gn6otf3dbmVl/wA6SLuyTF6yaXtZyTRp/2idEKwTeLvHttzDQJaUOAoI7y+
NwRuxVUA7cfEWUMp3g/a
=xyEX
-END PGP SIGNATURE-

[gentoo-dev] Gentoostats

[Andreas K. Hüttel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sunday 24 January 2016 16:50:46 Göktürk Yüksek wrote:
> 
> I don't want to go off-topic here too much but this is more than a
> missing tools issue. There are privacy concerns regarding the
> collection of such information. I recall this proposed idea from
> Google Summer of Code:
> 
> https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2012/Ideas#Package_stati
> stics_reporting_tool

This has been debated to death. As long as noone is forced to use it, privacy 
concerns shouldnt be a problem. And it would be extremely useful how many of 
our maintainer-needed packages are actually still compiled once per year. (Or 
if any one single person even uses KDE on ppc64.)

Gentoostats is a typical stillbirth of the Gentoo Google Summer of Soon-
Obsolete Code. Would I be happy if someone were to revive and actually deploy 
it (the last point is important!)? YES!

- -- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWpPT9AAoJEHRrah2soMK+WjoP/2zsgRV565keOQdPaya/j5ak
0ga6F4xjf+XdAg4soPG+c0guN/Qz3tZtuIdDnl7NDaWBUBWGvA6DuqcKxPj3g0EQ
X9EZTCigAsO+0d1F4cLMqW7JsL5YqTL4wHftzjuCqqSTD7OtX6NtOBA1namIDCoz
MpmSArjjBy31oiJgDRRBDwCRAMoSErKEnkeyXVyuFyD4yV9E8PMOFcrNkeO2MFHy
/Ehy0v14F5pTiGNeDnt7EDXNf5rcOFGUYTUitNyrhotUuX7sobcS9RfX2B9VtWUF
pgg3zRKGJdpeKwRx3MFZZA/O8f5bPT3ne1dMLZ/LOjxgvt/CglG5G4K+iL3lFC9v
WEeHj4zejXQuKlX1olWOgZdAYlt9bUmg7YO2K+OOPfQrTmqbShlnPFiAXuMTIS0h
elnKY8I5e1flHbFicQg6lnT+qBriy7afYhj7WkGypzC8DAhI1N4/eROavrALCkMW
nqNbEM0x4RiNdpgmdoN4L8dFBygXW73O4G8Iu5xjE1hKA6xUCmYitP3AsI5rVx1A
Jt6A2edk3Zk/g584nZ07GIt4W5AceFlFhBaYxKNgAo8MZUUE5gzvcblbPTF7Si4t
gTkjyXy0qabpvDBlimWxFENxGSIUqM/8N0YB1xba/FXNLn4KmTmD8Tezvze2c5Al
Htxql3SYp7YaY0HFrYdx
=lclI
-END PGP SIGNATURE-

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Andreas K. Hüttel]

Ack.. both makes definitely sense.



 -- Přeposlaná zpráva --
 Od: Tomáš Chvátal tomas.chva...@gmail.com
 Datum: 5. září 2011 18:08
 Předmět: Re: [gentoo-dev-announce] Call for items for September 13
 council meeting
 Komu: gentoo-dev@lists.gentoo.org
 
 
 Start collecting ideas for EAPI5.
 
 I myself would like PATCHES array to be default in src_prepare phase
 and some solution for runtime optional deps, Instead of elog in
 postinst something like Recommended from rpm.
 
 Cheers
 
 Tom