Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Mikle Kolyada



28.12.2020 11:56, Michał Górny пишет:

  I would like to propose that we stop patching
packages, discontinue support for it and last rite it.


I second this.



[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs: sys-kernel/bliss-initramfs, sys-kernel/bliss-kernel-bin

2020-10-29 Thread Mikle Kolyada
I wiill take initramfs

29 октября 2020 г. 11:46:50 GMT+03:00, "Michał Górny"  пишет:
>(re-sending with proper Subject)
>
>Hello,
>
>Due to the retirement of their maintainer, the following packages are
>up
>for grabs:
>
>  sys-kernel/bliss-initramfs
>  sys-kernel/bliss-kernel-bin
>
>-- 
>Best regards,
>Michał Górny

-- 
Простите за краткость, создано в K-9 Mail.

Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init

2020-10-18 Thread Mikle Kolyada

18.10.2020 01:05, Aisha Tammy пишет:
> Hi,
>   I'm attaching the news item for the upcoming display-manager-init
> changes
>
> Thanks,
> Aisha
>
> ---
>
> Title: New OpenRC Display Manager Initializer Scripts
> Author: Aisha Tammy 
> Posted: 2020-10-17
> Revision: 1
> News-Item-Format: 2.0
>
>

Systemd users have nothing to do with this news item, so please make it
openrc-dependent.



Re: [gentoo-dev] [virtualization project] Help needed with libvirt virtualization stack

2020-09-22 Thread Mikle Kolyada
I am interested in qemu and libvirt stuff, so I am in :) 

21 сентября 2020 г. 23:25:56 GMT+03:00, Matthias Maier  
пишет:
>Dear all,
>
>Due to some work related crunch time I had very limited time lately to
>properly maintain the following packages of the virtualization stack:
>
>  app-emulation/libvirt
>  app-emulation/libvirt-glib
>  app-emulation/libvirt-snmp
>  app-emulation/lxc
>  app-emulation/lxc-templates
>  app-emulation/qemu
>  app-emulation/qemu-guest-agent
>  app-emulation/qt-virt-manager
>  app-emulation/spice
>  app-emulation/spice-protocol
>  app-emulation/spice-vdagent
>  app-emulation/virt-manager
>  app-emulation/virt-viewer
>  dev-python/libvirt-python
>  media-libs/virglrenderer
>  net-firewall/firewalld
>  net-misc/spice-gtk
>  sys-apps/usbredir
>  sys-firmware/edk2-ovmf
>  sys-firmware/ipxe
>  sys-firmware/seabios
>  sys-firmware/sgabios
>  sys-firmware/vgabios
>  sys-process/criu
>
>If you use these packages and are interested in helping out with
>version
>bumps and maintenance, please contact me over e-mail / IRC and add
>yourself to the virtualization project :-)
>
>Best,
>Matthias

-- 
Простите за краткость, создано в K-9 Mail.

[gentoo-dev] Last rites: dev-tex/detex

2020-09-12 Thread Mikle Kolyada
# Mikle Kolyada  (2020-09-12)
# Merged into the texlive-core package.
# Removal in 30 days
dev-tex/detex




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: dev-tex/csindex

2020-09-12 Thread Mikle Kolyada
# Mikle Kolyada  (2020-09-12)
# Has been a part of a cstex macro for a long time.
# The cstex macro is provided by the
# dev-texlive/texlive-langczechslovak package.
# Removal in 30 days
dev-tex/csindex




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: dev-tex/dvipost

2020-09-12 Thread Mikle Kolyada
# Mikle Kolyada  (2020-09-12)
# Dead upstream and does not build.
# Removal in 30 days
dev-tex/dvipost




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: dev-tex/dvi2tty

2020-09-10 Thread Mikle Kolyada
# Mikle Kolyada  (2020-09-10)
# Merged into the app-text/texlive-core package.
# Removal in 30 days
dev-tex/dvi2tty




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] profiles/targets/desktop: Do not enable ldap USE flag by default

2020-09-10 Thread Mikle Kolyada



On 10.09.2020 08:35, Hans de Graaff wrote:

On Wed, 2020-09-09 at 13:35 +0300, Mikle Kolyada wrote:

Closes: https://bugs.gentoo.org/741380

Could you provide a rationale for removing this? The bug only has a
single anecdotal report of a user who can run a desktop without it. I'm
not sure if that is reason enough to remove this. I guess we won't be
able to figure out easily how many of our desktop profile users are
actually using LDAP, but changing this may cause surprises and I'm not
sure if that's warranted.

Hans



Hi.

It is dictated by common sense.

I barely can imagine a case where you need ldap support in each and 
every package you install.


This should rather be per-package enabled as something non-trivial.




[gentoo-dev] [PATCH] profiles/targets/desktop: Do not enable ldap USE flag by default

2020-09-09 Thread Mikle Kolyada
Closes: https://bugs.gentoo.org/741380
Signed-off-by: Mikle Kolyada 
---
 profiles/targets/desktop/make.defaults | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/profiles/targets/desktop/make.defaults 
b/profiles/targets/desktop/make.defaults
index da96e7830..d7eab4cd0 100644
--- a/profiles/targets/desktop/make.defaults
+++ b/profiles/targets/desktop/make.defaults
@@ -1,4 +1,4 @@
 # Copyright 1999-2020 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
-USE="a52 aac acpi alsa bluetooth branding cairo cdda cdr cups dbus dri dts dvd 
dvdr elogind emboss encode exif flac gif gpm gtk gui icu jpeg lcms ldap 
libnotify mad mng mp3 mp4 mpeg ogg opengl pango pdf png policykit ppds qt5 sdl 
spell startup-notification svg tiff truetype vorbis udev udisks unicode upower 
usb wxwidgets X xcb x264 xml xv xvid"
+USE="a52 aac acpi alsa bluetooth branding cairo cdda cdr cups dbus dri dts dvd 
dvdr elogind emboss encode exif flac gif gpm gtk gui icu jpeg lcms libnotify 
mad mng mp3 mp4 mpeg ogg opengl pango pdf png policykit ppds qt5 sdl spell 
startup-notification svg tiff truetype vorbis udev udisks unicode upower usb 
wxwidgets X xcb x264 xml xv xvid"
-- 
2.26.2




[gentoo-dev] www-servers/lighttpd is up for grabs

2020-09-07 Thread Mikle Kolyada

I have switched to nginx for the most of my services.

There are no critical bugs open, but some may require additional 
investigation.





Re: [gentoo-dev] Crypto/GPG-related packages up for grabs

2020-09-07 Thread Mikle Kolyada



On 07.09.2020 20:44, Michał Górny wrote:

Hi,

The following packages are up for grabs due to their maintainer being
MIA.

acct-group/monkeysphere
acct-user/monkeysphere
app-crypt/ekeyd
app-crypt/monkeysphere
app-crypt/nasty
app-crypt/pinentry
app-eselect/eselect-pinentry
dev-libs/libgcrypt
dev-libs/npth
net-misc/sks
www-apps/ampache



I will take pinentry as I took gnupg in anyway.




[gentoo-dev] Packages are up for grabs: zathura and co

2020-08-24 Thread Mikle Kolyada

dev-libs/girara
app-text/zathura-ps
app-text/zathura-pdf-poppler
app-text/zathura-pdf-mupdf
app-text/zathura-djvu
app-text/zathura-cb
app-text/zathura


Are for grabs now, I do not use them daily anymore. A separate active 
maintainer needed.





[gentoo-dev] Last rites: sys-auth/consolekit and co

2020-08-02 Thread Mikle Kolyada
# Mikle Kolyada  (2020-08-02)
# consolekit is abandoned upstream.
# People are encouraged to switch to any logind
# implementation (systemd/elogind).
# Removal in 60 days (bug #727730)
sys-auth/consolekit
sec-policy/selinux-consolekit

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


[gentoo-dev] Last rites: app-text/{jadetex,passivetex}

2020-07-24 Thread Mikle Kolyada
# Mikle Kolyada  (2020-07-24)
# Both packages is a part of the texlive-formatsextra.collection
# (or dev-texlive/texlive-formatsextra package).
# jadetex abuses kpathsea configuration.
# Both were last released in 2002.
# Removal in 30 days.
app-text/jadetex
app-text/passivetex

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


[gentoo-dev] app-laptop/thinkfan is for grabs

2020-07-13 Thread Mikle Kolyada
I do not have an old thinkpad anymore.
On modern ones this package is irrelevant.

There is a pending version bump and 3 open bugs:

- musl compatibility problem
- 2 bugs are due to problems in upstream unit/init.d files.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: dev-tex/xmltex

2020-07-10 Thread Mikle Kolyada
# Mikle Kolyada  (2020-07-10)
# Last major release in 2001. Was added into texlive
# long ago.
# Use dev-texlive/texlive-formatsextra instead.
# Removal in 30 days.
dev-tex/xmltex



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: dev-tex/cjk-latex

2020-07-03 Thread Mikle Kolyada
# Mikle Kolyada  (2020-07-03)
# Merged into dev-texlive/texlive-langcjk.
# Removal in 30 days.
dev-tex/cjk-latex



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: app-misc/scope

2020-06-28 Thread Mikle Kolyada
# Mikle Kolyada  (2020-06-28)
# Obsolete package.
# Does not build.
# Dead upstream and only gentoo ships it.
# Removal in 30 days.
app-misc/scope



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: dev-tex/circuit_macros

2020-06-26 Thread Mikle Kolyada
# Mikle Kolyada  (2020-06-26)
# Has been a part of dev-texlive/texlive-pictures
# for a lonmg time. Removal in 30 days.
dev-tex/circuit_macros




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: News Item: sys-libs/pam-1.4.0 upgrade

2020-06-20 Thread Mikle Kolyada


On 20.06.2020 16:55, Mikle Kolyada wrote:
> Attached

A bit fixed, wanted another version to show.

Title: sys-libs/pam-1.4.0 upgrade
Author: Mikle Kolyada 
Content-Type: text/plain
Posted: 2020-06-??
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-libs/pam
Display-If-Installed: sys-auth/pambase

Starting with the 1.4.0 release [1], we don't offer these modules anymore:

* pam_tally and pam_tally2 have been deprecated and replaced 
  by the pam_faillock module
* pam_cracklib has been deprecated and replaced
  by the pam_passwdqc module

These changes affected our basic PAM stack configuration.

You only need to take action if:
* you made manual changes to the PAM stack, or
* you use FEATURES="-config-protect-if-modified" option

If this applies to you, please make sure to either run the etc-update or
dispatch-conf command in order to sync your configuration.

Failure to do this may result in your system becoming inaccessible.

[1] - https://github.com/linux-pam/linux-pam/releases/tag/v1.4.0


signature.asc
Description: OpenPGP digital signature


[gentoo-dev] News Item: sys-libs/pam-1.4.0 upgrade

2020-06-20 Thread Mikle Kolyada
Attached

itle: sys-libs/pam-1.4.0 upgrade
Author: Mikle Kolyada 
Content-Type: text/plain
Posted: 2020-06-??
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: >=sys-libs/pam-1.4.0
Display-If-Installed: >=sys-auth/pambase-20200618

Starting with the 1.4.0 release [1], we don't offer these modules anymore:

* pam_tally and pam_tally2 have been deprecated and replaced 
  by the pam_faillock module
* pam_cracklib has been deprecated and replaced
  by the pam_passwdqc module

These changes affected our basic PAM stack configuration.

You only need to take action if:
* you made manual changes to the PAM stack, or
* you use FEATURES="-config-protect-if-modified" option

If this applies to you, please make sure to either run the etc-update or
dispatch-conf command in order to sync your configuration.

Failure to do this may result in your system becoming inaccessible.

[1] - https://github.com/linux-pam/linux-pam/releases/tag/v1.4.0

signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: app-text/xindy dev-tex/tex4ht

2020-06-13 Thread Mikle Kolyada
# Mikle Kolyada  (2020-06-13)
# Multiple forks.
# Merged into the app-text/texlive-core package.
# Removal in 30 days.
app-text/xindy

# Mikle Kolyada  (2020-06-13)
# have been shipped with dev-texlive/texlive-plaingeneric
# for the very long time. Removal in 14 days.
dev-tex/tex4ht



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: sys-apps/hardened-shadow virtual/shadow

2020-03-07 Thread Mikle Kolyada
# Mikle Kolyada  (2020-03-07)
# virtual/shadow has the only alive provider.
# sys-apps/hardened-shadow is unmaintained for the past
# five years (at least). Upstream is dead.
# Removal in 30 days.
sys-apps/hardened-shadow
virtual/shadow




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: media-gfx/cropgui

2020-02-21 Thread Mikle Kolyada
# Mikle Kolyada  (2020-02-21)
# Tiny package with semi-dead upstream. Unlikely useful.
# Blocks pygtk removal.
# Removal in 30 days.
media-gfx/cropgui




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] crypto@ packages up for grabs

2020-01-08 Thread Mikle Kolyada
These are up for grabs due to the crypto@ project being disbanded.

app-admin/ranpwd
app-crypt/aescrypt
app-crypt/aespipe
app-crypt/asedriveiiie-serial
app-crypt/asedriveiiie-usb
app-crypt/asekey
app-crypt/bcwipe
app-crypt/bsign
app-crypt/cardpeek
app-crypt/ccrypt
app-crypt/chntpw
app-crypt/coolkey
app-crypt/dieharder
app-crypt/fcrackzip
app-crypt/gnupg-pkcs11-scd
app-crypt/gpa
app-crypt/gpgme
app-crypt/hmaccalc
app-crypt/libykneomgr
app-crypt/loop-aes-losetup
app-crypt/mcrypt
app-crypt/md6sum
app-crypt/mhash
app-crypt/nasty
app-crypt/nwipe
app-crypt/onak
app-crypt/pdfcrack
app-crypt/pius
app-crypt/pkcrack
app-crypt/pkcs11-data
app-crypt/pkcs11-dump
app-crypt/quickcrypt
app-crypt/rainbowcrack
app-crypt/scrypt
app-crypt/ssdeep
app-crypt/stan
app-crypt/tc-play
app-crypt/tpm-emulator
app-crypt/tpm-tools
app-crypt/tpm2-abrmd
app-crypt/tpm2-tools
app-crypt/tpm2-totp
app-crypt/tpm2-tss-engine
app-crypt/tpm2-tss
app-crypt/trousers
app-crypt/xca
app-eselect/eselect-pinentry
dev-libs/libassuan
dev-libs/libgpg-error
dev-libs/libksba
dev-libs/libmcrypt
dev-libs/libp11
dev-libs/libtasn1
dev-libs/nettle
dev-libs/npth
dev-libs/opencryptoki
dev-libs/openct
dev-libs/opensc
dev-libs/pakchois
dev-libs/pkcs11-helper
dev-libs/softhsm
dev-libs/xmlsec
net-wireless/wepdecrypt
sys-apps/ifd-gempc
sys-apps/pcsc-slb-rf72-drv
sys-auth/pam_p11
sys-fs/ecryptfs-utils
sys-fs/loop-aes




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Mikle Kolyada
+1

5 декабря 2019 г. 19:09:57 GMT+03:00, "Michał Górny"  пишет:
>Signed-off-by: Michał Górny 
>---
> profiles/package.deprecated | 17 +
> 1 file changed, 17 insertions(+)
> create mode 100644 profiles/package.deprecated
>
>diff --git a/profiles/package.deprecated b/profiles/package.deprecated
>new file mode 100644
>index ..b4803a4ce68f
>--- /dev/null
>+++ b/profiles/package.deprecated
>@@ -0,0 +1,17 @@
>+
>+#
>+# This file specifies packages that are considered deprecated (but not
>+# masked yet).  It will trigger pkgcheck warnings whenever other
>+# packages depend on them.
>+#
>+# When you add an entry to the top of this file, add your name, the
>date
>+# in the UTC timezone, and an explanation of why something is getting
>+# deprecated.
>+#
>+## Example:
>+##
>+## # Dev E. Loper  (2019-07-01)
>+## # This is no longer supported upstream, please switch to
>dev-foo/bar.
>+## dev-foo/foo
>+
>+#--- END OF EXAMPLES ---
>-- 
>2.24.0

-- 
Простите за краткость, создано в K-9 Mail.

Re: [gentoo-dev] packages up for grabs

2019-11-19 Thread Mikle Kolyada
I will take app-misc/ranger

19 ноября 2019 г. 3:47:22 GMT+03:00, Tim Harder  пишет:
>The following list of packages are up for grabs that I dropped myself
>as
>as a direct maintainer from. There are probably a significantly larger
>number that I've indirectly maintained hiding under the guise of older
>projects that mostly act likes herds (e.g. graphics, sound, and vim to
>name a few) so interested parties should feel free to directly add
>themselves as maintainers for such packages.
>
>Note that some of the packages in this list already have maintainers,
>but I'm sure most of them wouldn't mind co-maintainers.
>
>app-admin/gopass
>app-admin/lnav
>app-arch/atool
>app-arch/libpar2
>app-arch/par2cmdline
>app-arch/pigz
>app-backup/bup
>app-backup/duplicity
>app-doc/zsh-lovers
>app-editors/hteditor
>app-forensics/libewf
>app-misc/binwalk
>app-misc/dateutils
>app-misc/evemu
>app-misc/fslurp
>app-misc/jq
>app-misc/ltunify
>app-misc/ranger
>app-misc/rq
>app-misc/skim
>app-misc/task
>app-misc/terminal-colors
>app-shells/gentoo-zsh-completions
>app-shells/zsh
>app-text/cpdf
>app-text/csvfix
>app-text/docx2txt
>app-text/extract_url
>app-text/restview
>app-text/txt2man
>app-text/xlsx2csv
>app-text/yodl
>dev-lang/swig
>dev-libs/libyaml
>dev-libs/rremove
>dev-libs/stfl
>dev-ml/camlpdf
>dev-util/archdiff
>dev-util/coccigrep
>dev-util/coccinelle
>dev-util/cpputest
>dev-util/icmake
>dev-vcs/bfg
>dev-vcs/hgview
>dev-vcs/tig
>games-util/wit
>net-dialup/neocon
>net-fs/btfs
>net-fs/sshfs
>net-im/bitlbee
>net-irc/weechat
>net-mail/t-prot
>net-misc/autossh
>net-misc/proxychains
>net-news/newsboat
>net-print/sshlpr
>net-proxy/mitmproxy
>net-proxy/sshuttle
>sys-apps/ack
>sys-apps/moreutils
>sys-apps/pick
>sys-apps/ripgrep
>sys-apps/the_silver_searcher
>sys-fs/archivemount
>sys-fs/avfs
>sys-fs/bindfs
>sys-fs/fuse
>sys-fs/fuse-common
>sys-fs/rar2fs
>sys-process/cronutils
>sys-process/parallel
>sys-process/procenv
>www-client/lynx
>www-client/qutebrowser
>x11-misc/sxhkd
>x11-misc/unclutter-xfixes
>x11-misc/urxvt-font-size
>x11-misc/urxvt-perls
>x11-misc/xdo
>x11-terms/kitty
>x11-wm/bspwm
>x11-wm/herbstluftwm
>x11-wm/qtile
>x11-wm/subtle

-- 
Простите за краткость, создано в K-9 Mail.

[gentoo-dev] acct-user/mpd request for ID

2019-11-10 Thread Mikle Kolyada
It will be 45 as this one was not taken.




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] packages up for grabs net-fs/{mc,minio}

2019-10-25 Thread Mikle Kolyada
net-fs/mc

net-fs/minio

are for grabs now. Upstream is  _very_ active (to say least), be ready
for frequent version bumps.

Also they often changes dependencies as well.




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] New distfile mirror layout

2019-10-21 Thread Mikle Kolyada

On 21.10.2019 3:05, Joshua Kinard wrote:
> So looking at texlive-latexextra-2019-r2.ebuild, it defines three variables:
>
>   - TEXLIVE_MODULE_CONTENTS, with 1,241 space-delimited module names
>   - TEXLIVE_MODULE_DOC_CONTENTS, with 1,227 space-delimited doc names
>   - TEXLIVE_MODULE_SRC_CONTENTS, with 745 space-delimited src names
>
> Then, in texlive-module.eclass, there's these loops:
>
> for i in ${TEXLIVE_MODULE_CONTENTS}; do
> SRC_URI="${SRC_URI} 
> mirror://gentoo/texlive-module-${i}-${PV}.${PKGEXT}"
> done
>
> # Forge doc SRC_URI
> [ -n "${TEXLIVE_MODULE_DOC_CONTENTS}" ] && SRC_URI="${SRC_URI} doc? ("
> for i in ${TEXLIVE_MODULE_DOC_CONTENTS}; do
> SRC_URI="${SRC_URI} 
> mirror://gentoo/texlive-module-${i}-${PV}.${PKGEXT}"
> done
> [ -n "${TEXLIVE_MODULE_DOC_CONTENTS}" ] && SRC_URI="${SRC_URI} )"
>
> # Forge source SRC_URI
> if [ -n "${TEXLIVE_MODULE_SRC_CONTENTS}" ] ; then
> SRC_URI="${SRC_URI} source? ("
> for i in ${TEXLIVE_MODULE_SRC_CONTENTS}; do
> SRC_URI="${SRC_URI} 
> mirror://gentoo/texlive-module-${i}-${PV}.${PKGEXT}"
> done
> SRC_URI="${SRC_URI} )"
> fi
>
> I think this is definitely an issue with how this package is laying out its
> needed distfiles.  It really should be leveraging CTAN system at a minimum
> to fetch all of the needed distfiles so we can get them off of our
> distfiles mirror.  Then it would be interesting to re-run the math on
> the distfiles distribution using the different schemes highlighted in the
> GLEP-75 paper.

TexLive distributes collections of macros, not  packages separately,
they make their packaging based on CTAN. In the meantime CTAN packages
are not versioned, they only have internal release number, no tags,
releases and so on, see [1].

I also fail to see what problem you try to solve when suggest fetching
macros from CTAN, you are going to have the same amount of data mirrored
as a result.

[1] - https://ctan.org/tex-archive/systems/texlive/tlnet/archive



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Support move of genpatches tarballs from /space/distfiles-local to devspace

2019-10-10 Thread Mikle Kolyada

On 10.10.2019 13:04, Mike Pagano wrote:
> On Wed, Oct 09, 2019 at 06:23:06PM -0700, Alec Warner wrote:
>>On Wed, Oct 9, 2019 at 10:01 AM Mike Pagano <[1]mpag...@gentoo.org>
>>wrote:
>>
>>  This change will support moving the genpatches tarballs from
>>  /space/distfiles-local to
>>  the devspace ~developer/public_html/dist/genpatches
>>
>>I think it would help if you discussed why we were making this change.
>>(I mean I can guess why, but it's not obvious.)
>>-A
>>Â
> I was informed that use of /space/distfiles-local is deprecated in favor
> of devspace.
>
>
> https://devmanual.gentoo.org/general-concepts/mirrors/index.html
>
>

This is not really true,  (otherwise we would have to upload literally
8500 tarballs for texlive to my devspace).

I'd say narrowing an eclass' URIs to the selected group of people is
even worse for long-term usage.




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs:

2019-09-25 Thread Mikle Kolyada
I will take a look at mpv and add myself there

25 сентября 2019 г. 20:19:50 GMT+03:00, "Michał Górny"  
пишет:
>On Wed, 2019-09-25 at 12:47 +0200, Michał Górny wrote:
>> Hi,
>> 
>> Due to the proxied maintainer retiring, the following packages are
>now
>> up for grabs:
>
>I should've probably mentioned:
>
>[b ] media-video/mpv
>
>as well since it falls back to media-video@, and has multiple bugs
>open.
>
>> Packages marked with [b] have bugs reported, packages marked with [v]
>> need a version bump, [?] means repology doesn't know the package.
>> 
>
>-- 
>Best regards,
>Michał Górny

-- 
Простите за краткость, создано в K-9 Mail.

Re: [gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering

2019-08-07 Thread Mikle Kolyada

On 07.08.2019 18:49, Michał Górny wrote:
> On Wed, 2019-08-07 at 18:20 +0300, Mikle Kolyada wrote:
>> Signed-off-by: Mikle Kolyada 
>> ---
>> As discussed with mgorny at #gentoo-qa
>>  glep-0081.rst | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/glep-0081.rst b/glep-0081.rst
>> index 082e705..e5a4db2 100644
>> --- a/glep-0081.rst
>> +++ b/glep-0081.rst
>> @@ -107,6 +107,9 @@ a build time dependency (``DEPEND``) must be used.  If 
>> the user is
>>  needed at install and/or run time, a run time dependency (``RDEPEND``)
>>  must be used.
>>  
>> +Both ``acct-group`` and ``acct-user`` eclasses have the ``KEYWORDS``
>> +variable predefined, keywords must not be altered locally via ebuilds.
>> +
>>  
>>  Maintaining users/groups
>>  
> I've told you I don't believe this belongs in the GLEP.  It's
> implementation detail, and if at all, it should go through tree policy.
>
We did not come to a conclusion about where this should be written down
if you remember, in any way I am concerned about the fact, not about a
place where we write it down, the main intention here is that all the
developers must follow the same rules.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering

2019-08-07 Thread Mikle Kolyada

On 07.08.2019 18:32, Brian Evans wrote:
> On 8/7/2019 11:20 AM, Mikle Kolyada wrote:
>> Signed-off-by: Mikle Kolyada 
>> ---
>> As discussed with mgorny at #gentoo-qa
>>  glep-0081.rst | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/glep-0081.rst b/glep-0081.rst
>> index 082e705..e5a4db2 100644
>> --- a/glep-0081.rst
>> +++ b/glep-0081.rst
>> @@ -107,6 +107,9 @@ a build time dependency (``DEPEND``) must be used.  If 
>> the user is
>>  needed at install and/or run time, a run time dependency (``RDEPEND``)
>>  must be used.
>>  
>> +Both ``acct-group`` and ``acct-user`` eclasses have the ``KEYWORDS``
>> +variable predefined, keywords must not be altered locally via ebuilds.
>> +
>>  
>>  Maintaining users/groups
>>  
>>
> I object to this as I feel they can incorrect such as on prefix.
>
> Also, this goes against the established practice of committing directly
> to stable.  These are exactly the same as virtuals as "they install
> nothing" and "just run a script" (to verify dependencies).
>
> Brian


They are not exactly the same as virtuals,  ~arch keywords in virtuals
make sense because they may have dependency providers that are also in
~arch status. These eclasses pull nothing, therefore keywords altering
here meaningless by definition.




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering

2019-08-07 Thread Mikle Kolyada
Signed-off-by: Mikle Kolyada 
---
As discussed with mgorny at #gentoo-qa
 glep-0081.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/glep-0081.rst b/glep-0081.rst
index 082e705..e5a4db2 100644
--- a/glep-0081.rst
+++ b/glep-0081.rst
@@ -107,6 +107,9 @@ a build time dependency (``DEPEND``) must be used.  If the 
user is
 needed at install and/or run time, a run time dependency (``RDEPEND``)
 must be used.
 
+Both ``acct-group`` and ``acct-user`` eclasses have the ``KEYWORDS``
+variable predefined, keywords must not be altered locally via ebuilds.
+
 
 Maintaining users/groups
 
-- 
2.21.0




[gentoo-dev] Last rites: app-text/winefish, dev-tex/oesch

2019-08-05 Thread Mikle Kolyada
# Mikle Kolyada  (2019-08-05)
# dead upstream, does not work and compile
#(bug #688006, bug #686630)
# masked for removal in 14 days
app-text/winefish
dev-tex/oesch




signature.asc
Description: OpenPGP digital signature


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

2019-05-20 Thread Mikle Kolyada


On 20.05.2019 18:53, Michał Górny wrote:
> Hello,
>
> The following packages are now up for grabs:
>
> app-portage/conf-update
> app-admin/logrotate
> app-admin/mktwpol
> app-admin/swatchdog
> app-admin/tripwire
> app-emulation/free42
> app-emulation/libdsk
> app-emulation/x48
> app-emulation/xcpc
> app-misc/linux-logo
> app-misc/muttprint
> app-misc/vifm
> x11-wm/stumpwm-contrib
> x11-wm/stumpwm
>

I will rake logrotate




Re: [gentoo-dev] [PATCH] glep-0063: Allow a single primary/signing key for smartcards

2019-04-25 Thread Mikle Kolyada


On 25.04.2019 14:32, Rich Freeman wrote:
> [snip]

> Patch follows:
>
>
> diff --git a/glep-0063-v3.rst b/glep-0063-v3.rst
> index 5895873..86e5fd9 100644
> --- a/glep-0063-v3.rst
> +++ b/glep-0063-v3.rst
> @@ -12,6 +12,12 @@ OpenPGP key management policies for the Gentoo
> Linux distribution.
>  Changes
>  ===
>
> +v3
> +  The requirement to have a separate signing and primary key was removed
> +  in the case of keys generated/stored on smartcards, to encourage the use
> +  of these keys, and acknowledging that the main use case for a separate
> +  primary key is largely fulfilled by having all the keys stay offline.
> +
>  v2
>The distinct minimal and recommended expirations have been replaced
>by a single requirement. The rules have been simplified to use
> @@ -69,7 +75,8 @@ not be used to commit.
> at least 256-bit.  All subkey self-signatures must use this digest.
>
>  2. Signing subkey that is different from the primary key, and does not
> -   have any other capabilities enabled.
> +   have any other capabilities enabled.  This requirement does not apply
> +   if the primary key was generated on a smartcard.
>
>  3. Primary key and the signing subkey are both of type EITHER:
>
>
>
I strongly disagree with this change. If you generated your keys
straight on the device you are not able to make a backup later.
The best practice here is to have a separate USB stick that is never
used for purposes other than private keys storing.
Also paperkey backups should serve as the last resort.






signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] adding more entries to profiles/info_pkgs

2018-12-15 Thread Mikle Kolyada

On 15.12.2018 5:00, Georgy Yakovlev wrote:
> Hi,
>
> while lurking on bugzilla lately I noticed that package part of 
> "emerge --info" output may be lacking in some cases.
>
> Good candidates for adding to that file are:
>
> virtual/rust
> llvm ?
> dev-util/meson
> dev-util/ninja
>
> that should be enough to provide a bit more to initial information without 
> going crazy and clobbering output too much.
>
> Thoughts?
>
> Regards,
> Georgy Yakovlev
> Gentoo Linux Developer


They all are not way too much spread, especially rust.

Do not think it worth to include them.

meson can be reconsidered later, as more and more people are using this one.




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs from xmw@g.o

2018-11-25 Thread Mikle Kolyada

On 25.11.2018 13:04, Michał Górny wrote:
> Hello, everyone.
>
> Due to long-time inactivity, the following packages are now up for
> grabs.  Given the length of the list, please forgive me for any
> mistakes.
[snip]
> app-text/zathura-cb
> app-text/zathura-djvu
> app-text/zathura-meta
> app-text/zathura-pdf-mupdf
> app-text/zathura-pdf-poppler
> app-text/zathura-ps
> app-text/zathura
> dev-libs/girara
I will take zathura and co (already on this)
>
> sys-auth/pam_fprint
>
pam team added here



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] app-emulation/libvirt-snmp: version bump to 0.0.4

2018-10-25 Thread Mikle Kolyada


On 26.10.2018 04:04, Matthias Maier wrote:
>> could you please stop sending project related stuff to the -dev mailing
>> list? It is irrelevant place to provide bump patches
> Why? What's the purpose of a developer mailing list then?
Because we have github/project alias for that purpose



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] app-emulation/libvirt-snmp: version bump to 0.0.4

2018-10-25 Thread Mikle Kolyada


On 25.10.2018 18:31, Michal Privoznik wrote:
> Signed-off-by: Michal Privoznik 
> ---
>  app-emulation/libvirt-snmp/Manifest   |  1 +
>  .../libvirt-snmp/libvirt-snmp-0.0.4.ebuild| 40 +++
>  2 files changed, 41 insertions(+)
>  create mode 100644 app-emulation/libvirt-snmp/libvirt-snmp-0.0.4.ebuild
>
> diff --git a/app-emulation/libvirt-snmp/Manifest 
> b/app-emulation/libvirt-snmp/Manifest
> index ea3d956712a..b7eb38bce37 100644
> --- a/app-emulation/libvirt-snmp/Manifest
> +++ b/app-emulation/libvirt-snmp/Manifest
> @@ -1,2 +1,3 @@
>  DIST libvirt-snmp-0.0.2.tar.gz 152790 BLAKE2B 
> b2e5eee2d67283112556c52921b14029a90d5cedf0c4575e056475191470a4b6bf5d837f1ca942b848f6509da4aa12daa508bbfc5272e1435e73fbfc290e1967
>  SHA512 
> 13a522c765d278d3b8f8ab9f32f97c8531f6d131afcb0ce62ae397631db92ed3b585ad221a1f2b3bc17907cc4d61adca4a2071b0458a05f2bff5ca06191e1478
>  DIST libvirt-snmp-0.0.3.tar.gz 161186 BLAKE2B 
> 1b43e7e81a43d4e969e2e30d7d62776743b3c5fb19929fb1606850946c665ad1ca662bee88743f60f202cd92fc42be1cc2cc94e99bf1d137df61bec09850de93
>  SHA512 
> 6ffda3594ddc513e05e31e7d347a12e371dca3cc698ca790a70e2d01b2ceac6acb5dd6e3cd19723817b41aa62e0c0a49c01c47cb9ce379ac491856a7e88e5a08
> +DIST libvirt-snmp-0.0.4.tar.gz 157859 BLAKE2B 
> e2c8fcdd97ba9b55bd4d318c63f7738024c1360ee10aa4e685c2ea6ca02478206febff30f3e1a82eb1a2dadaa52a377cfbce538e12e33f4ea2fe10b1a089945d
>  SHA512 
> dbf47e7983f9bd6fcff205fffd1f6006268cca774cf427d39dec84dc7de37b545c0dfcbb2c6f171f55d73487cdec13341097137e24de2dea58ce90494d281162
> diff --git a/app-emulation/libvirt-snmp/libvirt-snmp-0.0.4.ebuild 
> b/app-emulation/libvirt-snmp/libvirt-snmp-0.0.4.ebuild
> new file mode 100644
> index 000..f0eb657001f
> --- /dev/null
> +++ b/app-emulation/libvirt-snmp/libvirt-snmp-0.0.4.ebuild
> @@ -0,0 +1,40 @@
> +# Copyright 1999-2018 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=7
> +
> +inherit eutils
> +
> +DESCRIPTION="Provides SNMP functionality for libvirt"
> +HOMEPAGE="http://libvirt.org;
> +SRC_URI="http://www.libvirt.org/sources/snmp/${P}.tar.gz;
> +
> +LICENSE="GPL-2"
> +SLOT="0"
> +KEYWORDS="~amd64 ~x86"
> +IUSE=""
> +
> +DEPEND=""
> +RDEPEND="${DEPEND}
> + app-emulation/libvirt
> + net-analyzer/net-snmp"
> +BDEPEND="
> + virtual/pkgconfig"
> +
> +src_install() {
> + default
> + newinitd "${FILESDIR}/libvirt-snmp.initd-r1" "${PN}"
> + newconfd "${FILESDIR}/libvirt-snmp.confd" "${PN}"
> +}
> +
> +pkg_postinst() {
> + elog "This daemon runs as an AgentX sub-daemon for snmpd. You should 
> therefore"
> + elog "enable the AgentX functionality in snmpd by specifying the 
> following"
> + elog "in /etc/snmp/snmpd.conf:"
> + elog "  master agentx"
> + elog "It is further recommended to send traps to the localhost as well 
> using"
> + elog "this option:"
> + elog "  trap2sink localhost"
> + elog "More information is available here:"
> + elog "  http://wiki.libvirt.org/page/Libvirt-snmp;
> +}
could you please stop sending project related stuff to the -dev mailing
list? It is irrelevant place to provide bump patches



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] net-dns/dnssec-root: Blind stable on arm, critical bug 667774

2018-10-20 Thread Mikle Kolyada



On 20.10.2018 15:26, Andreas Sturmlechner wrote:
> On Samstag, 20. Oktober 2018 14:22:04 CEST Mikle Kolyada wrote:
>> No, keywords status is irrelevant, it is for the security team meaning
>> that they can
>> release a glsa w/o waiting for the stabilization of the security
>> unsupported arches
> In my experience glsa only happens after cleanup, and cleanup only happens 
> after every arch was done.
>
>
>
that's not mandatory, that is what security support means



Re: [gentoo-dev] net-dns/dnssec-root: Blind stable on arm, critical bug 667774

2018-10-20 Thread Mikle Kolyada


On 20.10.2018 15:19, Andreas Sturmlechner wrote:
> On Freitag, 12. Oktober 2018 14:50:55 CEST Rich Freeman wrote:
>> ARM is not a Gentoo security supported arch.
>>
>> If the ARM maintainers feel that stable keywords make the lives of
>> their users better, and it isn't causing problems for anybody else,
>> I'm not sure why we should be interfering with this.
> That's interesting. If it's not security supported, does that mean we can 
> simply clean up vulnerable versions and drop every arm revdep to ~arm?
>
> Or are we supposed to keep vulnerable versions around and drop every keyword 
> except arm?
>
> Either way means extra care for this arch.
>
>
>
>
No, keywords status is irrelevant, it is for the security team meaning
that they can
release a glsa w/o waiting for the stabilization of the security
unsupported arches



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Is there any way I can help with pull requests?

2018-10-20 Thread Mikle Kolyada


On 20.10.2018 03:33, Michael Orlitzky wrote:
> On 10/13/2018 02:32 PM, Mikle Kolyada wrote:
>> Quizzes are irrelevant, a person does the quizzes when he/she is
>> ready to be the dev, doing quizzes for quizzes or quizzes to become a
>> developer is the best way to get rejected by the recruiters team.
> I thought this was kind of a strange thing to say, but just ignored
> it... not realizing that you were the recruiters lead.

Well, people know that recruiters have the opinion about quizzes,
so they think it is pointless to discuss :)
>
> Why do you say that working on the quizzes will get you rejected? I had
> a very positive experience while taking them and learned a lot.
The main problem is that lots of (not all) people think, if they have
quizzes done,
they are ready to be developers, some of them even think if they copy-pasted
the answer and give us the quote it is ok and they will pass. The answer for
both statements is no.

>  I've
> recommended them to potential contributors in the past as a way to
> highlight the areas where they might need to improve, and to generally
> improve their knowledge of the devmanual.
Quzzes are being treated as an obstacle to be a dev, like "wow, I have
to answer
so much questions to be the dev, I have no time for this". The short
answer is:
"if you have no time to fill quizzes you are not ready to be the dev", 
people
who are ready spend very little amount of time filling them with zero
difficulty.
>
> Once the new developer finds a mentor, I would think it saves everyone
> valuable time if he has a first draft of the quiz prepared.
>




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Is there any way I can help with pull requests?

2018-10-13 Thread Mikle Kolyada


On 13.10.2018 15:59, James Le Cuirot wrote:

[snip]
>  Such contributions also frequently have issues as the authors have not done
> the developer quizzes. We try to guide contributors through the
> necessary changes but this can lead to fatigue on both sides.

Quizzes are irrelevant, a person does the quizzes when he/she is ready
to be the dev,
doing quizzes for quizzes or quizzes to become a developer is the best
way to get
rejected by the recruiters team.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: net-dns/dnssec-root: Blind stable on arm, critical bug 667774

2018-10-12 Thread Mikle Kolyada


On 11.10.2018 18:10, Thomas Deutschmann wrote:
> Let me quote 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f6f6bb91b7f134a121ef9fa1dd504b9ca52c5aa8:
>
>> net-dns/dnssec-root: Blind stable on arm, critical bug 667774
>>
>> Note that this is a major fail for a stable architecture.
>> In addition, all arm devboxes are currently offline.
>>
>> Bug: https://bugs.gentoo.org/667774
>> Signed-off-by: Andreas K. Hüttel 
>> Package-Manager: Portage-2.3.49, Repoman-2.3.11
> ...and now let's all sit down and enjoy how stable ARM users lose access
> to the Internet and have to figure out how to deactivate DNSSEC to get
> back online. ;]
>
> Maybe it is time to destabilize ARM on Gentoo to stop the impression
> that we really support ARM.
>
>
Your statement is totally inappropriate, to stabilize a package on arm
you have to test the
package on all gentoo supported arm varieties what usually takes a lot
of time



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] [PATCH] appimage.eclass: new eclass

2018-10-07 Thread Mikle Kolyada


On 06.10.2018 14:17, Mykyta Holubakha wrote:
> Signed-off-by: Mykyta Holubakha 
>
> I'm proposing to add a new eclass: appimage.eclass, to facilitate
> extraction off AppImage bundles. The rationale is that some upstreams
> have migrated to distributing their proprietary software exclusively as
> AppImage bundles. 

Why making the separate eclass? Merge it with the unpacker one.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] New project: Gentoo Proctors

2018-09-29 Thread Mikle Kolyada
Good evening community!

It is my pleasure to announce, that after almost 1,5 years of the hard
work, the Gentoo Proctors project [1] starts working as was discussed
and approved by the Council at their last meeting [2]. 
The main purpose of the project is to create the disciplinary body
handling direct Code of Conduct violations (this allows the Comrel team
to focus on the most serious violations). The Code of Conduct page was
updated accordingly [3].

I also want to give a shout out to dilfridge for his patience during
making it fly!


[1] - https://wiki.gentoo.org/wiki/Project:Proctors
[2] - https://projects.gentoo.org/council/meeting-logs/20180909-summary.txt
[3] - https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: sys-process/vixie-cron

2018-09-20 Thread Mikle Kolyada
# Mikle Kolyada  (20 Sep 2018)
# Dead upstream and unmaintained for a long time,
# has multiple bugs open, use sys-process/cronie
# instead (the fork). Removal in 30 days.
sys-process/vixie-cron



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: sys-boot/winusb

2018-08-30 Thread Mikle Kolyada
# Mikle Kolyada  (30 Aug 2018)
# Dead upstream, does not work properly.
# Unmaintained.
# Use sys-boot/woeusb instead.
sys-boot/winusb



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: rfc: [QA] Ban policy introduction

2018-07-29 Thread Mikle Kolyada


On 29.07.2018 00:40, Mikle Kolyada wrote:
> Hello,
>
> The Gentoo QA team would like to introduce the following policy that
> would be applied to individuals breaking the state and quality of the
> main gentoo.git tree
>
> ( as we do not have this strictly documented yet):
>
> 
>
> If recommended Gentoo workflow policies are not followed by an
> individual developer
> (e.g make major changes to the widely used eclasses without prior
> discussion on the mailing list or
> commit changes that lead to multiple CI checks failure), the standard QA
> procedure is:
>
> 1.) Two warnings granted by QA team, after two independent breakages
> 2.) Revoking the commit access for 14 days
>
> These violations will be evaluated individually by all QA team members.
> Warnings can be revoked, if during 6 months period a developer makes at
> least 20 non trivial changes not producing more breakages.
>
> 
>
>
>
>
Meh, I sent this one a bit prematurely, sorry for the spam, we will work
on it a bit more before it reaches an official point



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] rfc: [QA] Ban policy introduction

2018-07-28 Thread Mikle Kolyada
Hello,

The Gentoo QA team would like to introduce the following policy that
would be applied to individuals breaking the state and quality of the
main gentoo.git tree

( as we do not have this strictly documented yet):



If recommended Gentoo workflow policies are not followed by an
individual developer
(e.g make major changes to the widely used eclasses without prior
discussion on the mailing list or
commit changes that lead to multiple CI checks failure), the standard QA
procedure is:

1.) Two warnings granted by QA team, after two independent breakages
2.) Revoking the commit access for 14 days

These violations will be evaluated individually by all QA team members.
Warnings can be revoked, if during 6 months period a developer makes at
least 20 non trivial changes not producing more breakages.








signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Mikle Kolyada


On 20.07.2018 04:42, Andrew Savchenko wrote:
> On Thu, 19 Jul 2018 16:51:17 -0500 Ben Kohler wrote:
>> Hello,
>>
>> I'd like to propose adding USE=udev to our linux profiles (in 
>> profiles/default/linux/make.defaults probably).  This flag is already 
>> enabled on desktop profiles but it also affects quite a few packages 
>> used on non-desktop linux systems.
>>
>> This flag provides useful functionality that most linux users will want. 
>>   I'm a bit surprised that we still don't have it in all linux profiles, 
>> but I think we've worked around this in the past by adding IUSE=+udev to 
>> quite a few of those packages (33 packages, 116 ebuilds, by my count).
>>
>> This missing flag came to my attention again on bug 661584 where lvm2 
>> has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop users 
>> have a bit of a mismatch between the 2 and get ugly errors on cryptsetup.
>>
>> Since this flag only affects linux, I think it makes more sense to set 
>> it in linux profiles than to use IUSE defaults.
>>
>> Any objections to this idea?
> I have server setups with udev disabled for most packages. So udev
> enabled by default will create maintenance problems. While I'm
> perfectly fine with udev enabled by default on desktops, it should
> not be forced on minimalistic setups like servers or containers.
>
> Best regards,
> Andrew Savchenko
+1. widely used profiles should have as least flags enabled by default
as possible, I would not be happy with +udev on my servers.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: What means bup?

2018-07-19 Thread Mikle Kolyada


On 18.07.2018 19:57, Matthew Thode wrote:
> On 18-07-18 11:28:16, Mike Gilbert wrote:
>> On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode
>>  wrote:
>>> On 18-07-18 09:16:07, Johannes Huber wrote:
 Hi all,

 english is not my mother language, so please clarify what bup means, just
 seen here:

 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397

 Just checked if it was a typo, but can't be:
 git log --oneline --grep bup | count -l
 Expected 0 lines, got 1248.

>>> It's similiar to a sound you make when you touch something's nose.
>>> *boop*
>>>
>>> I just prefer bup instead.  I generally only use it when doing simple
>>> bumps of packages (copy ebuilds with only keyword edits).
>> My preference is to mention the version being added when committing a
>> version bump. eg. "cat/pkg: bump to x.y.z".
>>
>> Yes, it does take a few more seconds, but I think it is worth the effort.
>>
> I think more recently I've been following this format.
>
> cat/pkg: x.y.z bup
>

But can you please *stop* doing this as well? It is neither clear
language *nor* useful reduction.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs: app-backup/fsarchiver, app-cdr/daa2iso...

2018-07-19 Thread Mikle Kolyada


On 19.07.2018 11:10, Michał Górny wrote:
> Hello,
>
> Due to Markos Chandras' prolonged absence, the following packages are up
> for grabs now:
[snip]
> sys-auth/sssd
>
>

Will take this one, someone else is welcome to help :)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Idea for a new project: gentoo-libs

2018-06-23 Thread Mikle Kolyada


On 23.06.2018 05:50, Marty E. Plummer wrote:
> So, as you may be aware I've been doing some work on moving bzip2 to an
> autotools based build. Recently I've ran into app-crypt/mhash, which is
> in a semi-abandoned state (talking with the maintainer on twitter atm),
> and I was thinking it may be a good idea to set up a project for keeping
> these semi-abandoned and really-abandoned libraries and projects up to
> date and such.

But how would it serve gentoo itself? Lots of packages in the distro
have dead upstream but still work.
Why would you want to make gentoo an upstream area rather than moving a
dead project itself, say,
to github and do the job there?
>
> Basically, an upstream for packages who's upstream is either
> uncontactable or is otherwise not accepting bug fixes and patches. So
> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
> there are others in this state.
>




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: sys-fs/yaffs-utils

2018-06-09 Thread Mikle Kolyada
# Mikle Kolyada  (9 June 2018)
# Fails to buil, dead upstream, EAPI=2
# Only the live enuild in the tree.
# Masked for removal in 30 days
sys-fs/yaffs-utils




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: app-emulation/armv8-fast-model

2018-04-28 Thread Mikle Kolyada
# Mikle Kolyada <zlog...@gentoo.org> (27 Apr 2018)
# Upstream is dead, the site with the sources is down.
# There's no chance to get the sources (fetch restricted)
# Removal in 30 days (bug #642866)
app-emulation/armv8-fast-model


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Deleting old news items

2018-01-02 Thread Mikle Kolyada
+1

There is also https://www.gentoo.org/support/news-items/ if needed


signature.asc
Description: Digital signature


[gentoo-dev] Last rites:sys-apps/more

2017-08-26 Thread Mikle Kolyada
# Mikle Kolyada <zlog...@gentoo.org> (26 Aug 2017)
# Masked for removal in 30 days.
# No major keywords,  old EAPI, no maintainer.
# Use sys-apps/less instead.
sys-apps/more


signature.asc
Description: Digital signature


Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

2017-05-08 Thread Mikle Kolyada


08.05.2017 22:21, David Seifert пишет:
> On Mon, 2017-05-08 at 22:08 +0300, Mikle Kolyada wrote:
>> We have appropriate hardware if people wanna do the work, jut go &
>> make
>> things better :), I do not think someone from existing arch teams has
>> something against that
> Ok so let me get the logic right:
>
> 1) Arch teams can add their keywords to ebuilds in general, without the
> maintainer having a say in that.
> 2) Arch team goes MIA because .
> 3) Now the maintainer has to chase down machines and do KEYWORDREQ
> testing on other arches because we cannot admit that some archs are not
> maintained.
>
> Please confirm the above logic. If that logic is about right, I am
> sorry, but I disagree. I will rather dekeyword unmaintained archs. I am
> not going to babysit arch teams in doing their work for them.
>
To clarify:

I have not seen the draft of proper reverting these arches to exp or
dev, if it will be like sh or s390, better kill the horse like debian
did to alpha and hppa, without riding it.




Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

2017-05-08 Thread Mikle Kolyada


08.05.2017 21:55, Andreas K. Huettel пишет:
> Am Montag, 8. Mai 2017, 12:49:32 CEST schrieb Mikle Kolyada:
>> Against. Do not touch things you are not working on, council has already
>> dropped m68k s390 and sh to exp few years ago. Now we have a big mess
>> there and only, while ia64 sparc and co have slow but progress and
>> mature enough stable profiles.
> No objections against having many arches, but:
>
> If an arch is keyworded / stable on more packages than that team can 
> reasonably take care of, that needs to be corrected somehow. 
>
> The easiest solution is for the arch team to remove keywords until they have 
> a 
> reasonable response time again. And if the arch team doesn't do that by 
> itself, well, ...
>
> Having one-man teams block everybody else hurts Gentoo as a whole.
>
We have appropriate hardware if people wanna do the work, jut go & make
things better :), I do not think someone from existing arch teams has
something against that



Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

2017-05-08 Thread Mikle Kolyada


07.05.2017 22:23, David Seifert пишет:
> TL;DR
> ia64/ppc/sparc teams are pretty much dead. They have been for a long
> time and this won't change any time soon. Gentoo should focus its
> resources on archs that are important and has the manpower to support.
> Let us please drop these 3 archs to dev profiles to ease maintenance.
>
> Dear all,
> I'd like to request Council to consider my motion to drop the
> ia64/ppc/sparc profiles to dev (or exp). These arches are pretty much
> dead, minus the automated workflows of ago. Two months ago I have
> written to these 3 archs, and only received one reply from ppc agreeing
> with my sentiment, with no response from ia64 or sparc, which in itself
> is pretty telling.
>
> Currently, architecture projects think adding their keywords is a
> right, which I strongly disagree with. I believe being able to add (and
> stable) your keywords is a privilege - namely it carries with it the
> duty to react to keywording and stabilization requests in a timely
> manner. Let's compare the state of ia64/ppc/sparc to, say alpha:
>
> https://bugs.gentoo.org/show_bug.cgi?id=605278
>
> alpha was keyworded within 6 hours. To date ia64/ppc/sparc are still
> not keyworded (the bot had some breakages due to jer again shifting
> around all the bugs). Within 4 months these arches have not managed to
> keyword those 4 packages. This is I believe the most striking example
> of how the only work done for these archs are ago's automated stablereq
> scripts. Why do I saw that keywording+stabling your arch is a
> privilege? Maintenance of packages is hampered by archs not stabling,
> because we cannot clean up broken packages. Adding keywords is a two-
> way street - if you don't act speedily, you're breaking part of the
> maintainer-arch social contract.
>
> Please don't turn this into a massive bikeshedding contest and just
> admit that it is extremely unlikely that these archs will see more
> activity in the near future. We should focus our resources on more
> important archs (arm64 maybe?) instead of these. I know you have that
> old Mac G4 or UltraSPARC sitting in your closet that you're 2 days away
> from installing Gentoo on, but the pain for maintainers and the rest of
> the community is just too great. If someone steps up to do the work, we
> can then move archs back to a stable profile, but so long as they
> linger in their present state, let's call a spade a spade.
>
> Anyhow, I formally request the Council to vote on dropping these archs
> to unstable/exp profiles for the next Council meeting, explicitly
> overriding any arch concerns that are likely to awake now and going to
> be running around like headless chicken.
>
> David
>
Against. Do not touch things you are not working on, council has already
dropped m68k s390 and sh to exp few years ago. Now we have a big mess
there and only, while ia64 sparc and co have slow but progress and
mature enough stable profiles.



Re: [gentoo-dev] Looking for a new mentor...

2016-07-20 Thread Mikle Kolyada



21.07.2016 03:58, Manuel Rüger пишет:

On 21.07.2016 02:46, Mikle Kolyada wrote:


21.07.2016 02:41, Manuel Rüger пишет:

Hey,

have you tried contacting recruit...@gentoo.org?

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

Cheers,

Manuel

On 20.07.2016 21:13, alexmcwhir...@triadic.us wrote:

I've been working towards becomming a gentoo developer for while now in
order to bring the sparc port up to speed with the rest of the gentoo
project. In short there appear to be no active gentoo developers working
on sparc.

I had a mentor earlier this year, but i can no longer get in touch with
him.

I have both quizzes nearly complete, i just need someone to look over
them and answer a question or two. Any help would be greatly
appreciated.


Recruiters take care of recruitment process, not about mentors:)


They do. But they usually are aware of possible and active mentors and
can recommend some.

Cheers,

Manuel.

Well, I have been recruiting people for more than a year, we can only 
recommend, but usually it is not our work.




Re: [gentoo-dev] Looking for a new mentor...

2016-07-20 Thread Mikle Kolyada



21.07.2016 02:41, Manuel Rüger пишет:

Hey,

have you tried contacting recruit...@gentoo.org?

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

Cheers,

Manuel

On 20.07.2016 21:13, alexmcwhir...@triadic.us wrote:

I've been working towards becomming a gentoo developer for while now in
order to bring the sparc port up to speed with the rest of the gentoo
project. In short there appear to be no active gentoo developers working
on sparc.

I had a mentor earlier this year, but i can no longer get in touch with
him.

I have both quizzes nearly complete, i just need someone to look over
them and answer a question or two. Any help would be greatly appreciated.





Recruiters take care of recruitment process, not about mentors:)



Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

2016-06-16 Thread Mikle Kolyada



15.06.2016 22:11, Michał Górny пишет:

Hello, everyone.

On bug #577398, Pacho has requested removing the 'Development'
component that's rarely used according to its description. However, I'd
rather not remove a single component when it fits the component split
currently used there.

Right now we have the following components:

- Applications,
- baselayout,
- Core system,
- Development,
- Eclasses and Profiles,
- Games,
- GCC Porting,
- GNOME,
- Hardened,
- Java,
- KDE,
- Keywording & Stabilization,
- Library,
- New packages ('New ebuilds' previously),
- Printing,
- SELinux,
- Server,
- Unspecified.

[snip]


I would personally go for the following layout:

- All packages,
- Core system [includes baselayout],
- Eclasses and Profiles,
- GCC Porting,
- Hardened,
- Keywording & Stabilization,
- New packages ('New ebuilds' previously),
- SELinux.

[snip]
I'd drop keywording & stabilization at all, using bug filtering based on 
keywords field. (STABLEREQ/KEYWORDREQ ones).




Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/intelhex/

2015-10-21 Thread Mikle Kolyada


21.10.2015 02:25, hasufell пишет:
> On 10/20/2015 04:02 PM, Mike Frysinger wrote:
>> commit: a68f2479fba9422913cb760166316bf489d72ca8
>> Author: Vincent Palatin  chromium  org>
>> AuthorDate: Tue Oct 20 14:01:34 2015 +
>> Commit: Mike Frysinger  gentoo  org>
>> CommitDate: Tue Oct 20 14:01:50 2015 +
>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a68f2479
>>
>> dev-python/intelhex: new package from Chromium OS
>>
>>  dev-python/intelhex/Manifest|  1 +
>>  dev-python/intelhex/intelhex-2.0.ebuild | 18 ++
>>  dev-python/intelhex/metadata.xml|  9 +
>>  3 files changed, 28 insertions(+)
>>
> [...]
>
>> +
>> +EAPI="5"
>> +
>> +PYTHON_COMPAT=( python{2_7,3_3,3_4,3_5} )
>> +
>> +inherit distutils-r1
>> +
>> +DESCRIPTION="Python library for Intel HEX files manipulations"
>> +HOMEPAGE="http://pypi.python.org/pypi/IntelHex/ 
>> https://github.com/bialix/intelhex;
>> +SRC_URI="mirror://pypi/I/IntelHex/${P}.tar.gz"
>> +
>> +LICENSE="BSD"
>> +SLOT="0"
>> +KEYWORDS="*"
> What does that KEYWORDS mean? Unless I read PMS wrong [0][1], this isn't
> even allowed. And I don't see a single ebuild in the tree with that syntax.
>
> Also, my package manager chokes on it. Repoman not, so that looks like a
> bug.
>
>
> [0] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-260003.1.6
> [1] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-690007.3.2
>
As per commit message, it was imported from chromium os, AFAIR, they
have their own rules about how to write ebuilds, and of course our PMS
doesn't allow such things.



Re: [gentoo-dev] Is the $Id$ line in our ebuilds still useful?

2015-08-13 Thread Mikle Kolyada


13.08.2015 18:36, William Hubbs пишет:
 All,

 I understood the usefulness of this line to some when we were using CVS
 since it expanded into the ebuild revision, date, etc.

 This expansion doesn't take place under git, so now I don't understand
 the usefulness of this line. If I have missed something, can someone
 fill me in, or if it isn't useful any more can we consider removing it?

 Thanks,

 William

Hmm, the same question here. As far as i remember git does not depend on
any ebuild's header.



Re: [gentoo-dev] Summary line

2015-08-11 Thread Mikle Kolyada


11.08.2015 17:36, hasufell пишет:
 On 08/11/2015 04:28 PM, Ian Stakenvicius wrote:
 On 11/08/15 04:57 AM, Tobias Klausmann wrote:
 The more we stuff into the summary line, the harder it will be to 
 write meaningful summaries. And thus, people will write crappy ones
 or ignore the length limit. I recommend against any more 
 prescription over Add the the cat/pn if meaningful, don't use more
 than 75 characters.
 The cat/pn rule is tricky anyway: what if one commit touches 100 
 packages? Or should that be split into 100 commits for easier 
 partial rollback?
 Regards, Tobias


 The summary line limit is going to be a real issue, tbh.  I think it
 would probably be best to adopt the convention of putting a few
 choice, perhaps even canned, phrases in the summary line, and ensure
 any and all details (effectively what the summary line used to be for
 when it had practically no limit) within the commit message body instead
 .

 Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn:
 adjusted dependencies' are generic (and short) enough yet descriptive
 enough to see what went on while scanning the log.  'Fix bug' IMO in
 the summary doesn't work at all because, although its accurate, that
 bug could literally be anything at all.

 Multi-package commits are going to be more of an issue of course..  I
 did one last night, fortunately I think I can get away with using
 mozilla packages in place of cat/pn since it is a very specific set
 of packages.  Perhaps for sweeping changes like that we can use the
 herdname or projectname or the category name (if its a particular
 category only)?



 The CATEGORY: prefix is already in the wiki. Interesting idea about
 projectname/herdname prefix.

 I've already seen someone (I think ulm) prefixing with [QA].

 I don't feel strong about this. IMO, if there is no useful prefix...
 just don't use any. The lack of prefix will make it obvious that this is
 a larger change. But project/herd specific prefixes could still make sense.

Mgorny has commited a fix to live portage

https://github.com/gentoo/portage/commit/46dafadff58da0220511f20480b73ad09f913430

I think it will be in the tree soon.



Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub

2015-08-11 Thread Mikle Kolyada


11.08.2015 17:32, Michał Górny пишет:
 Hello, everyone.

 Now that we're officially on git and can officially use pull requests
 to provide rapid community interaction, it'd be convenient to have
 a little better framework for pinging package maintainers.

 With the unofficial mirror/pull request project, I was either looking
 for project member GitHub accounts and pinging found project members by
 name, or talking to them directly on IRC. However, with the growth in
 number of pull requests this will become more and more inconvenient.
 Therefore, I think it's time to be able to mirror teams willing to work
 with GitHub community there for easier 'pings'.

 I have two ideas right now:

 1. creating GitHub Gentoo project teams corresponding to willing Gentoo
 teams,

 2. preparing lists of GitHub usernames on project wiki pages.

 Solution 1. is cleaner. In this case, we create GitHub teams under
 the Gentoo projects, and add appropriate Gentoo developers having
 GitHub accounts to the teams. Then, in PRs we can just ping the whole
 team like @Gentoo/Qt or like.

 Solution 2. avoids adding any GitHub teams. In this case, in team wiki
 page we collect team member usernames like @Pesa, @kensington, ... so
 we could copy-paste it to pull requests. We still require extra effort
 when 'assigning' PRs but at least I don't have to lookup the same
 people over and over again.

 With some Wiki people help, we could even implement updating GitHub
 teams automatically following Wiki member changes.

 Your thoughts?


First one more clear. Jut don't forget update it, when someone new join
the team, as usual.



Re: [gentoo-dev] Git Migration: launch plan schedule (2015/Aug/08-09)

2015-08-09 Thread Mikle Kolyada


08.08.2015 20:47, Robin H. Johnson пишет:
 On Thu, Jul 02, 2015 at 09:39:52PM +, Robin H. Johnson wrote:
 2015/08/08 15:00 UTC - Freeze
 2015/08/08 19:00 UTC - Git commits open for developers
 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
 2015/08/11   - History repo available to graft
 2015/08/12   - rsync mirrors carry up-to-date changelogs again

 I've allocated time for an 8 hour freeze, but hope to be completed much
 sooner than that.
 Starting late due to $reasons, freeze is now at 18:00 UTC (14 minutes
 from now).

hat type=recruiter
Where and how should we add new developers these days to grant them
access to the portage tree?
/hat



Re: [gentoo-dev] Git Migration: launch plan schedule (2015/Aug/08-09)

2015-07-03 Thread Mikle Kolyada


03.07.2015 00:39, Robin H. Johnson пишет:
 Hi all,

 The Git migration is moving forward, and I'd like to announce a
 tentative schedule for that end.
 https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Status

 2015/08/08 15:00 UTC - Freeze
 2015/08/08 19:00 UTC - Git commits open for developers
 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
 2015/08/11   - History repo available to graft
 2015/08/12   - rsync mirrors carry up-to-date changelogs again

 I've allocated time for an 8 hour freeze, but hope to be completed much
 sooner than that.

Thanks Robbin and whole the Infrastructure team! Great and i'd even say
historical news!



Re: [gentoo-dev] RFC: ban EAPI 1

2015-06-11 Thread Mikle Kolyada


10.06.2015 23:43, Ulrich Mueller пишет:
 Hi,
 The number of EAPI 1 ebuilds in the Portage tree has decreased to
 a total of 60, corresponding to 0.16 %.

 We briefly discussed in the QA team if we should demote EAPI 1 in
 layout.conf from eapis-deprecated to eapis-banned. This would
 have the consequence that repoman would refuse to commit packages
 containing such ebuilds. AFAICS there would be no impact on users.

 What do you think?

 Ulrich

lets do it quick. :)



Re: [gentoo-dev] Sparc and Ia64 keyword clean up

2015-05-15 Thread Mikle Kolyada


15.05.2015 02:33, Jack Morgan пишет:
 I'm actively working on stablereq for sparc and ia64. It took some
 weeks to get my systems and process working. I hope to reduce the open
 bugzilla in the next several weeks. Please don't just drop stable
 keywords, even though the bugzilla has been open for a long time. I'd
 appreciate it if you could send me a quick email asking to do your
 package first, instead of just dropping the keyword. I'll put your
 request at the top of my queue.

 Once I’m done with stablereq queue, I'll look to keywordreq queue. My
 over plan is to reduce the total number of keyworded packages to a
 more maintainable level. I'll send out more specific details for each
 arch this week. Any help is greatly appreciated


 Thanks,

++

I went through some sparc STABLEREQs too.



Re: [gentoo-dev] Hey arch teams, we need your input!

2015-04-11 Thread Mikle Kolyada


11.04.2015 23:51, Pacho Ramos пишет:
 El sáb, 11-04-2015 a las 21:50 +0200, Andreas K. Huettel escribió:
 Hi all, 

 the debate about arches, keywording and stabilization procedures is
 coming up again.

 People have told me that the whole debate seems to turn into some sort
 of arch-team bashing. That is definitely not the plan. Also,
 supporting many different types of hardware is actually one of the
 strong points of Gentoo.

 So, it would be absolutely great to have more feedback from the arch
 teams, especially suggestions 
 * how to improve procedures, 
 * where you see the main problems, and 
 * where you don't see problems...

 Please make your voice heard. Noone wants to overrule an active team.

 Cheers, 
 Andreas

 PS. I've ommitted amd64, hppa, and arm from the manual CC list because
 these are the stable arches I'm definitely not worried about.
 Obviously feedback is appreciated anyway.

 I think we need a common place to share all the scripts we are needing
 to use to:
 - Stabilize a bunch of packages from different bug reports
 - Stabilize big lists from *one* bug report
 - All the bug handling (unCC arches when needed, close the bug when it's
 the last arch)
 - The scripts running repoman full on the stable candidates to report
 if they are not ok due to missing deps.
 - ...

 And, ideally, that multiple script should be unified if possible once we
 can see them all in that repo and take the best from them :)



Ok. Here is my small input. I've been around arch teams and testing for
a long time. And i'm mainly taking care of system-important packages. In
my opinion the main problem is.. people. Now we have lack of manpower as
usual.
So i think, we have to drop stable packages for some so-called fun
packages. I've noticed for example, that gimp has stable alpha keyword.
Have you ever run gimp on alpha servers?
I am sure, there are more stable-unneeded packages like games, maybe
some programming languages, and so on for others non-mainstream arches.




Re: [gentoo-dev] Maintainer stabilizations

2015-01-08 Thread Mikle Kolyada

08.01.2015 20:15, Michael Orlitzky пишет:
 I vaguely remember a discussion about maintainers stabilizing their own
 packages -- maybe just on x86 and amd64 -- to take the load off of the
 arch teams.

 Did that really happen or am I making it up? Is it written down anywhere?


amd64/x86 are major arches. They can be stabilized if package maintainer
has appropriate hardware. Even without arch teams membership.



Re: [gentoo-dev] Maintainer stabilizations

2015-01-08 Thread Mikle Kolyada

08.01.2015 21:12, Michael Orlitzky пишет:
 On 01/08/2015 12:57 PM, Mikle Kolyada wrote:
 08.01.2015 20:15, Michael Orlitzky пишет:
 I vaguely remember a discussion about maintainers stabilizing their own
 packages -- maybe just on x86 and amd64 -- to take the load off of the
 arch teams.

 Did that really happen or am I making it up? Is it written down anywhere?

 amd64/x86 are major arches. They can be stabilized if package maintainer
 has appropriate hardware. Even without arch teams membership.

 What's a major arch? The devmanual still says[0],

   Moving a package from ~arch to arch is done only by the relevant arch
   teams.

 According to [1] that section is no longer correct, but only x86 and
 amd64 are exceptions to the rule that used to be exceptions but then
 weren't anymore.

 I'm going to write a devmanual patch but don't want to sound like a lunatic.


 [0] http://devmanual.gentoo.org/keywording/index.html
 [1] http://article.gmane.org/gmane.linux.gentoo.devel/89711



Major arches are amd64 and x86, nothing more. There is a bug for it
already [1]

[1] - https://bugs.gentoo.org/show_bug.cgi?id=510198



Re: [gentoo-dev] Nominate global USE-flag harfbuzz

2015-01-07 Thread Mikle Kolyada

07.01.2015 22:00, Mart Raudsepp пишет:
 On K, 2015-01-07 at 07:29 +0100, Peter Stuge wrote:
 $ grep :harfbuzz profiles/use*desc
 profiles/use.local.desc:dev-libs/efl:harfbuzz - Enable complex text shaping 
 and layout support.
 profiles/use.local.desc:dev-qt/qtgui:harfbuzz - Use media-libs/harfbuzz for 
 text shaping (experimental in Qt 5.3.x, default in Qt 5.4.0 and later). If 
 enabled, it can still be disabled at runtime by setting QT_HARFBUZZ 
 environment variable to old.
 profiles/use.local.desc:media-libs/freetype:harfbuzz - Use 
 media-libs/harfbuzz for auto-hinting OpenType fonts. WARNING: may trigger 
 circular dependencies!
 profiles/use.local.desc:media-libs/libass:harfbuzz - Enables OpenType 
 shaping via media-libs/harfbuzz.

 Or isn't 4 enough?
 I don't know about that, but I would say at least half of them should
 continue to carry on a specific description of what the USE flag does in
 its metadata.xml.
 I guess consider this just a friendly slightly unrelated reminder that
 when making USE flags global, please don't end up losing information by
 deleting the specific description. And consider adding a local
 description to a packages global USE flag usage if you can describe its
 effect more specifically.
 And if some tooling doesn't support that, well, bad luck. My tool does
 (less metadata.xml)


 Mart
It must be at least 5 packages, as per our policy.



Re: [gentoo-dev] Gentoo-sources - should we stable?

2015-01-02 Thread Mikle Kolyada

02.01.2015 20:25, Mike Pagano пишет:
 This is in no way complaining about how long it takes to stabilize a kernel. 

As for this fact.

hat type=arch teams developer

The main problem is that: we only can test sources on machine we can
reboot. For example me and Agostino
have access to the rest hardware like alpha, ia64 and so on. But we
can't reboot it for clear reason i think.
Another side is that: not all hardware i have around can use
gentoo-sources, so it works with custom kernels.

/hat




[gentoo-dev] [ GLSA 201412-50 ] getmail: Information disclosure

2014-12-28 Thread Mikle Kolyada
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory   GLSA 201412-50
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: Normal
Title: getmail: Information disclosure
 Date: December 28, 2014
 Bugs: #524684
   ID: 201412-50

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis


Multiple vulnerabilities have been discovered in getmail, allowing
remote attackers to obtain sensitive information.

Background
==

getmail is a POP3 mail retriever with reliable Maildir and mbox
delivery.

Affected packages
=

---
 Package  / Vulnerable /Unaffected
---
  1  net-mail/getmail  4.46.0  = 4.46.0 

Description
===

Multiple vulnerabilities have been discovered in getmail. Please review
the CVE identifiers referenced below for details.

Impact
==

A remote attacker could cause a man-in-the-middle attack via multiple
vectors to obtain sensitive information.

Workaround
==

There is no known workaround at this time.

Resolution
==

All getmail users should upgrade to the latest version:

  # emerge --sync
  # emerge --ask --oneshot --verbose =net-mail/getmail-4.46.0

References
==

[ 1 ] CVE-2014-7273
  http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7273
[ 2 ] CVE-2014-7274
  http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7274
[ 3 ] CVE-2014-7275
  http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7275

Availability


This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

 http://security.gentoo.org/glsa/glsa-201412-50.xml

Concerns?
=

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users' machines is of utmost
importance to us. Any security concerns should be addressed to
secur...@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
===

Copyright 2014 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [ GLSA 201412-50 ] getmail: Information disclosure

2014-12-28 Thread Mikle Kolyada

28.12.2014 20:38, Mikle Kolyada пишет:
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Gentoo Linux Security Advisory   GLSA 201412-50
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 http://security.gentoo.org/
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
 Title: getmail: Information disclosure
  Date: December 28, 2014
  Bugs: #524684
ID: 201412-50

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Synopsis
 

 Multiple vulnerabilities have been discovered in getmail, allowing
 remote attackers to obtain sensitive information.

 Background
 ==

 getmail is a POP3 mail retriever with reliable Maildir and mbox
 delivery.

 Affected packages
 =

 ---
  Package  / Vulnerable /Unaffected
 ---
   1  net-mail/getmail  4.46.0  = 4.46.0 

 Description
 ===

 Multiple vulnerabilities have been discovered in getmail. Please review
 the CVE identifiers referenced below for details.

 Impact
 ==

 A remote attacker could cause a man-in-the-middle attack via multiple
 vectors to obtain sensitive information.

 Workaround
 ==

 There is no known workaround at this time.

 Resolution
 ==

 All getmail users should upgrade to the latest version:

   # emerge --sync
   # emerge --ask --oneshot --verbose =net-mail/getmail-4.46.0

 References
 ==

 [ 1 ] CVE-2014-7273
   http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7273
 [ 2 ] CVE-2014-7274
   http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7274
 [ 3 ] CVE-2014-7275
   http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7275

 Availability
 

 This GLSA and any updates to it are available for viewing at
 the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201412-50.xml

 Concerns?
 =

 Security is a primary focus of Gentoo Linux and ensuring the
 confidentiality and security of our users' machines is of utmost
 importance to us. Any security concerns should be addressed to
 secur...@gentoo.org or alternatively, you may file a bug at
 https://bugs.gentoo.org.

 License
 ===

 Copyright 2014 Gentoo Foundation, Inc; referenced text
 belongs to its owner(s).

 The contents of this document are licensed under the
 Creative Commons - Attribution / Share Alike license.

 http://creativecommons.org/licenses/by-sa/2.5


Sorry for mailspam, wrong list :/



Re: [gentoo-dev] Make 'vaapi' USE flag global

2014-11-29 Thread Mikle Kolyada

28.11.2014 15:20, Sergey Popov пишет:
 Packages that uses 'vaapi' local USE-flag:

 media-libs/avidemux-core
 media-libs/xine-lib
 media-tv/mythtv
 media-tv/xbmc
 media-video/avidemux
 media-video/ffmpeg
 media-video/hwdecode-demos
 media-video/libav.
 media-video/mpv
 media-video/vlc
 virtual/ffmpeg
 www-plugins/gnash

 Descriptions for that flag are pretty the same and we already have
 'vdpau' USE flag, which is for someway similar technology.

 So, how about making this flag global too?

works for me.



RE: [gentoo-dev] PowerPC status

2014-09-23 Thread Mikle Kolyada


 Исходное сообщение 
От Jack Morgan jmor...@gentoo.org 
Дата: 18.09.2014  3:31  (GMT+04:00) 
Кому gentoo-dev@lists.gentoo.org 
Тема [gentoo-dev] PowerPC status 
 
Hello,

The PowerPC development team has had our 2nd monthly meeting and I
wanted to provide an update on where we are. 


1) Active Developers

The following are activly working on PPC/PPC64 as far as I know.
If I've listed you in error, please let me know.


Agostino Sarubbo (ago) - stablereq
Anthony G. Basile (blueness) - keywordreq, profiles 
Jeroen Roovers (jer) - developer
Jack Morgan  (jmorgan) - lead, keywordreq
Joseph Jezak (josejx) - docs, keywordreq 
Luca Barbato (lu_zero) - keywordreq
Mikle Kolyada (zlongene) - developer


-- I could not visit our meetings for some personal reasons + I am in Barcelona 
for about last two weeks. But I think I can do some work for 2 ways (I will try 
to keep these 2 ways at least) keywordreqs and stablereqs together.

Re: [gentoo-dev] splitting out arm keywords

2014-07-09 Thread Mikle Kolyada

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


09.07.2014 20:10, Manuel Rüger ?:
 On 07/09/2014 01:40 PM, Anthony G. Basile wrote:
 On 07/09/14 05:09, Joshua Kinard wrote:
 On 07/08/2014 21:48, Matthew Thode wrote:
 arm has a historical problem with stabilization, while keywording
 doesn't require access to all arm sub-arches the problem with the
 stabilization slowness causes running a full ~arm to become hard.  By
 that I mean that if someone keywords something for arm because it works
 on armv7 and I run ~arm because stabilization takes forever then my
 system may break because of both non-stabilized packages and because I
 could be running armv6.

 In any case I propose splitting out arm into armv4, armv5, armv6 and
 armv7.  armv8 seems to be here already as arm64.
 Couldn't this be better handled with some profile work?  These sound
like
 versions of Instruction Set Architectures.  In the MIPS world, you
 have your
 original ISAs, mips1 through mips4, then you have the newer variants of
 mips32r* (branches from mips2) and mips64r* (branches from mips4).
 Anything
 supporting mips4 could also support earlier ISAs.  Throw in our three
 supported ABIs (o32, n32, n64), and machine-specific curiosities (SGI,
 Cobalt, Yeelong/Loongson, etc), and life can be quite fun.  But we can
 cover
 all of this with just a single 'mips' keyword in the tree.

 Yes, this should be done via the profiles.  Code requiring later ISAs
 and/or with extensions like thumb and neon will probably break on lower
 ISAs.  These should be masked on the profiles.

 Is that similar to how these ARM variants work?  Can an armv7 run code
 for
 armv6 and earlier?

 Its a bit more complicated that MIPS.  You can test for yourself.  I did
 this via a chromebook (cortex-a15) using my hardened stages
 (march=armv7a) available at mirror/experimental/arm/hardened, so you
 can test too:

 chrome ~ # echo int main() { return 0; }  test.c
 chrome ~ # gcc  -march=armv7-a -o test test.c
 chrome ~ # gcc  -march=armv6 -o test test.c
 chrome ~ # gcc  -march=armv5 -o test test.c
 chrome ~ # gcc  -march=armv4 -o test test.c
 chrome ~ # gcc  -march=armv3 -o test test.c
 /tmp/ccZjsI2O.s: Assembler messages:
 /tmp/ccZjsI2O.s:45: Error: selected processor does not support ARM mode
 `bx lr'
 chrome ~ # gcc  -march=armv3m -o test test.c
 /tmp/cc1o59kQ.s: Assembler messages:
 /tmp/cc1o59kQ.s:45: Error: selected processor does not support ARM mode
 `bx lr'
 chrome ~ # gcc  -march=armv2 -o test test.c
 /tmp/ccmTNSyh.s: Assembler messages:
 /tmp/ccmTNSyh.s:45: Error: selected processor does not support ARM mode
 `bx lr'
 chrome ~ # gcc  -march=armv2a -o test test.c
 /tmp/ccTIXZ46.s: Assembler messages:
 /tmp/ccTIXZ46.s:45: Error: selected processor does not support ARM mode
 `bx lr'
 chrome ~ # gcc --version
 gcc (Gentoo Hardened 4.7.3-r1 p1.4, pie-0.5.5) 4.7.3
 Copyright (C) 2012 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There
is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.


 So it looks like gcc can emit compat code back to armv4.  This doesn't
 necessarily mean that armv2 code won't run on an armv7a, but that
 gcc-4.7.3-r1 can't produce such code, which is sufficient for our
 purposes of masking.



 Splitting 'arm' into four new keywords, on top of 'arm64' is just
 going to
 give you guys major headaches later.  You might even consider
 dedicated USE
 flags for the arm subvariants and use those to control things in an
 ebuild
 where applicable.

 arm64 might as well be a totally different arch.  There is no
 compatibility between 32-bit and 64-bit arm variants --- at least not
 that I know of, its a new arch that I'm just now getting familiar with.
 On the other hand ppc and ppc64 should never have been split, but that's
 another story.

 We do not want keywords for every subarch otherwise we'll go crazy
 stabilizing.  We could adopt a policy of stabilizing on armv7a and when
 a package doesn't build on a lower ISA, just mask it in the profiles.


 I think this would be beneficial because of not all developers that
want
 to help with arm have or what all the sub-arches necessary.  It also
 allows us to move faster on stabilization because most of us have
access
 to armv7 a bit easier.  This would take some pressure off of the people
 doing stabilization for older sub-arches, but not much.
 What's the support status of Gentoo on the older variants, such as
 armv4 and
 armv5 stuff?  How fast is the CPU clock on those?  Do they include L2/L3
 cache?  Lots of memory?  Generally, anything that could be a
 bottleneck or
 severely increase the build time should be weighed against the potential
 number of users and possibly support dropped if there aren't enough
 developers or contributing users to maintain it.

 I.e., w/ MIPS, we don't support anything under the mips3 ISA, which
 includes
 DECStations (Debian does support those).  Build times would just be
 tremendously 

Re: [gentoo-dev] Packages up for grabs

2014-06-09 Thread Mikle Kolyada

08.06.2014 16:25, Fabio Erculiani пишет:
 Due to permanent lack of time, I'm unable to properly maintain the
 packages below.
 Feel free to take them over. I'll remove myself from metadata.xml in 14 days.

 app-admin/389-admin-console
 app-admin/389-console
 app-admin/389-ds-console
 app-admin/aws-as-tools
 app-admin/aws-elb-tools
 app-admin/aws-iam-tools
 app-admin/aws-rds-tools
 app-emulation/edumips64
 dev-java/idm-console-framework
 dev-libs/389-adminutil
 dev-libs/mozldap
 dev-libs/svrcore
 dev-perl/perl-mozldap
 net-nds/389-admin
 net-nds/389-ds-base
 net-libs/libgrss
 www-apache/mod_nss
 www-apps/389-dsgw
 x11-apps/ardesia
 x11-apps/spotlighter
 x11-apps/python-whiteboard
 x11-apps/whyteboard
 x11-drivers/cwiid

 dev-perl/perl-mozldap

perl herd will take care.



Re: [gentoo-dev] Packages up for grabs

2014-06-09 Thread Mikle Kolyada

09.06.2014 21:47, Jeroen Roovers пишет:
 On Mon, 09 Jun 2014 21:34:06 +0400
 Mikle Kolyada zlog...@gentoo.org wrote:

 app-admin/389-admin-console
 app-admin/389-console
 app-admin/389-ds-console
 app-admin/aws-as-tools
 app-admin/aws-elb-tools
 app-admin/aws-iam-tools
 app-admin/aws-rds-tools
 app-emulation/edumips64
 dev-java/idm-console-framework
 dev-libs/389-adminutil
 dev-libs/mozldap
 dev-libs/svrcore
 dev-perl/perl-mozldap
 net-nds/389-admin
 net-nds/389-ds-base
 net-libs/libgrss
 www-apache/mod_nss
 www-apps/389-dsgw
 x11-apps/ardesia
 x11-apps/spotlighter
 x11-apps/python-whiteboard
 x11-apps/whyteboard
 x11-drivers/cwiid

 dev-perl/perl-mozldap
 perl herd will take care.
 It looks like you mean perl@ will take care of all of them.


  jer



no, only dev-perl/perl-mozldap. I just use wrong quotes:/



Re: [gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention

2014-06-01 Thread Mikle Kolyada

01.06.2014 15:18, Samuli Suominen пишет:
 http://bugs.gentoo.org/show_bug.cgi?id=505962#c6 is blocking stabilizing
 the new virtuals,
 and thus, converting the tree, and also blocking stabilization of the
 already converted packages (gnome seems to have some)
 pending for 3 months already

 thanks,
 samuli

Is compile only test enough for you? If so, i can take care about it
right now.



Re: [gentoo-dev] ARM64 stable keyword

2014-04-22 Thread Mikle Kolyada

22.04.2014 21:40, Mike Gilbert пишет:
 I see that vapier has been adding arm64 as a stable keyword to lots of 
 packages.

 When I am requesting stabilization for newer versions these packages,
 is there an arm64 arch team I should copy? If not, these stable
 keywords are just going to get lost as old ebuilds get dropped.

 For an example, see my last commit to dev-util/scons. I moved the
 stable keyword forward from scons-2.2.0 to scons-2.3.0 myself, but I
 am not sure if this was the right thing to do.

   
You should not add this, only vapier and probably armin76 have arm64
hardware (hardware?).  Mike stabilize for minor arches  if needed. (like
sh/s390/m68k).



Re: [gentoo-dev] ARM64 stable keyword

2014-04-22 Thread Mikle Kolyada

22.04.2014 21:59, Mike Gilbert пишет:
 On Tue, Apr 22, 2014 at 2:01 PM, Mikle Kolyada zlog...@gentoo.org wrote:
 22.04.2014 21:40, Mike Gilbert пишет:
 I see that vapier has been adding arm64 as a stable keyword to lots of 
 packages.

 When I am requesting stabilization for newer versions these packages,
 is there an arm64 arch team I should copy? If not, these stable
 keywords are just going to get lost as old ebuilds get dropped.

 For an example, see my last commit to dev-util/scons. I moved the
 stable keyword forward from scons-2.2.0 to scons-2.3.0 myself, but I
 am not sure if this was the right thing to do.


 You should not add this, only vapier and probably armin76 have arm64
 hardware (hardware?).  Mike stabilize for minor arches  if needed. (like
 sh/s390/m68k).

 Ok, then the stable keyword is going to get lost when I drop old versions.

Vapier can  restore stable keywords for newest version if needed, i think



Re: [gentoo-dev] Change or revert the 30 days maintainer timeout stabilization policy

2014-04-03 Thread Mikle Kolyada

02.04.2014 20:52, Samuli Suominen пишет:
 The 30 days maintainer time out stabilization policy isn't working
 when package has multiple SLOTs, because
 the bugs are filed for only latest SLOT, where as some packages require
 stabilization in sync at both SLOTs

 Option 1:

 Either revert the whole policy, and never CC arches on unanswered bugs
 when the package has a maintainer,
 and let him do it when he finds the time himself, and if that doesn't
 happen, wait until it's dropped to maintainer-needed@

 Option 2:

 Or, the person who is CCing the arches in 30 days timeout, needs to make
 sure the bug covers all SLOT at the same time


 The status quo no longer allows me to maintain stable version of
 dev-libs/girara, app-text/zathura*, and the issue needs
 to be addressed, see http://bugs.gentoo.org/502714 for what inspired
 this mail

 - Samuli
Agreed. If package have active maintainer(s), i think they can file
stablereq when they wants (i think all maintainers have stabilization
scheme at least). As arch teams developer i'm annoyed when i see 80 (or
even more) messages like *maintainer timeout, go ahead* Moreover last
time i'm noticed, that this script CC s390/sh/m68k automatically, and we
need remove it manually. Seems script stil has no fix at all.

-- 
Mikle Kolyada
Gentoo Linux Developer




Re: [gentoo-dev] Perl 5.18.2 unmasking

2014-03-20 Thread Mikle Kolyada

16.03.2014 23:51, Mikle Kolyada пишет:
 Hello.

 We are willing to unmask perl-5.18.2 in a couple of days. It seems that
 most fatal issues are fixed now, and we, perl herd, are using perl 5.18
 in daily life for quite a some time. So if there is no objections, we
 will unmask it soon. As usual, if you find any issues, please file a bug
 about it and block  tracker[1].

 [1] - https://bugs.gentoo.org/show_bug.cgi?id=perl-5.18

unmasked.

-- 
Mikle Kolyada
Gentoo Linux Developer




[gentoo-dev] Last rites: app-misc/bins

2014-03-19 Thread Mikle Kolyada
# Mikle Kolyada zlog...@gentoo.org (19 Mar 2014)
# Dead upstream (no releases since 2006),
# GUI no longer supported (bug #250971).
# Removal in 30 days.
app-misc/bins

-- 
Mikle Kolyada
Gentoo Linux Developer




[gentoo-dev] Perl 5.18.2 unmasking

2014-03-16 Thread Mikle Kolyada
Hello.

We are willing to unmask perl-5.18.2 in a couple of days. It seems that
most fatal issues are fixed now, and we, perl herd, are using perl 5.18
in daily life for quite a some time. So if there is no objections, we
will unmask it soon. As usual, if you find any issues, please file a bug
about it and block  tracker[1].

[1] - https://bugs.gentoo.org/show_bug.cgi?id=perl-5.18

-- 
Mikle Kolyada
Gentoo Linux Developer




[gentoo-dev] About perl-5.18 unmasking

2013-09-08 Thread Mikle Kolyada

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi guys!

Few days ago i was surprised, when i saw perl-5.18 unhardmasked.
So, i want ask here.


@Patrick, why you unmask it? You even not ack perl herd about it. It was
in the tree about two weeks, too early for unmasking, furthermore, you
added not all modules need for perl-5.18 in the tree. Now many users ask
us why perl 5.18 broke our modules? Its not good. Testing on three
boxes w/o  problems, no major reason for unmasking. And also, many CPAN
guys still no fix own modules for compile with-5.18
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)

iJwEAQECAAYFAlIsdO0ACgkQG9wOWsQutdat/QQAsLcbqEn6NZGFAoipWZuBCxMM
Q5BPj7a43vLEuI08aCbOeiihVWqEEVqPOWJyXAoSohkOL5DhmRfv1e6z4JPX2BGv
dH/HFBkFtWH3gVOg7BV+rvecSb/ds6M2zufjnSHfBxomAuSKiFru1lQGYoVbPOrZ
Gwpy66uY2LZ9kBNkM/Q=
=USUZ
-END PGP SIGNATURE-




Re: [gentoo-dev] Moving more arches to dev profiles

2013-08-21 Thread Mikle Kolyada
21.08.2013 15:04, Markos Chandras пишет:
 Hi,

 It's time of year again to consider moving a few arches to dev-only status.

 I propose the following arches to lose their stable keywords

 - s390
 - sh
 - ia64
 - alpha
 - m68k
 - sparc

+1 for that. Perl herd has *really* many work with stabilization, it's
difficult because it's taking over a month in some cases.



[gentoo-dev] perl herd needs your help

2013-07-30 Thread Mikle Kolyada
Hi folks!

We need new active devs. Now we have ~200 bugs assigned to perl, but we
have new tracker too. (https://bugs.gentoo.org/show_bug.cgi?id=478714).

469 packages to update to EAPI = 4. We have no enough time/resources to
do it singly. Please help us!

-- 
Best regards, Mikle Kolyada.
Gentoo Linux Developer.




[gentoo-dev] Last rites: dev-perl/Date-ISO

2013-07-16 Thread Mikle Kolyada
# Mikle Kolyada zlog...@gentoo.org (16 Jul 2013)
# Upstream dead.
# No license info (bug #381283).
# Removal in 30 days.
dev-perl/Date-ISO

-- 
Best regards, Mikle Kolyada.
Gentoo Linux Developer.




[gentoo-dev] Last rites: dev-perl/Date-ISO

2013-07-16 Thread Mikle Kolyada
# Mikle Kolyada zlog...@gentoo.org (16 Jul 2013)
# Upstream dead.
# No license info (bug #381283).
# Removal in 30 days.
dev-perl/Date-ISO

-- 
Best regards, Mikle Kolyada.
Gentoo Linux Developer.




  1   2   >