[gentoo-dev] Re: News Item v2: Portage rsync tree verification unstable

2018-03-10 Thread Duncan
Zac Medico posted on Sat, 10 Mar 2018 15:16:29 -0800 as excerpted:

> Changes:
>   * First paragraph rewritten by Robin Johnson 
>   * Fixes spelling of 'following' reported by Michael Everitt
> 
> 
> Title: Portage rsync tree verification unstable
> Author: Zac Medico 
> Posted: 2018-03-13
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: sys-apps/portage
> 
> Portage rsync tree verification is being temporarily turned off by
> default, starting with sys-apps/portage-2.3.24. This permits
> stabilization of sys-apps/portage-2.3.24 while still working on bugs
> relating to tree verification [1]: deadlocks [2] & key fetching [3].

> [...]

With robbat2's first paragraph rewrite the effect isn't quite as bad
as that of the first draft, but the title still refers to "unstable",
which in addition to the intended package-stability meaning, has a
number of more severe and thus unnecessarily alarming meanings not
intended here.

FWIW, being security minded and knowing verification related to
security, my own first thought was an app instability due to a
potentially exploitable buffer-overflow... in code dealing with
verification and thus potentially remotely triggerable during
verification itself, definitely more alarming than intended!

Thankfully robbat2's rewrite clarifies in the body now, but
I still think the title remains overly alarming.

Maybe "... remains unstable" or "not yet stable", as in:

Title: Portage rsync tree verification not yet stable

Or better, refer to the FEATURE flag "rsync-verify" in the title,
so it's clear it's not a portage/emerge-executable instability,
and clarify that it's the stable keyword, something like this
(but might be too long, do those news item short title limits
still apply?):

Title: Portage rsync-verify feature not yet stable-keyworded

Perhaps omit the -keyworded if that's too long:

Title: Portage rsync-verify feature not yet stable

Feel free to revise further...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




[gentoo-dev] Re: Packages up for grabs

2018-03-10 Thread Michael Palimaka
On 03/11/2018 12:12 AM, Pacho Ramos wrote:
> This packages are now up for grabs:
...
> net-irc/unrealircd

I can take this one.




[gentoo-dev] Last rites: app-i18n/libguess

2018-03-10 Thread Andreas Sturmlechner
# Andreas Sturmlechner  (11 Mar 2018)
# Dead upstream, no revdeps left. Bug #639358
app-i18n/libguess






[gentoo-dev] News Item v2: Portage rsync tree verification unstable

2018-03-10 Thread Zac Medico
Changes:
  * First paragraph rewritten by Robin Johnson 
  * Fixes spelling of 'following' reported by Michael Everitt


Title: Portage rsync tree verification unstable
Author: Zac Medico 
Posted: 2018-03-13
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-apps/portage

Portage rsync tree verification is being temporarily turned off by
default, starting with sys-apps/portage-2.3.24. This permits
stabilization of sys-apps/portage-2.3.24 while still working on bugs
relating to tree verification [1]: deadlocks [2] & key fetching [3].

If users wish to enable the 'rsync-verify' USE flag for sys-apps/portage,
they need to follow these steps:

1) In order to unmask the 'rsync-verify' USE flag, create a file named
/etc/portage/profile/package.use.mask containing a line like the
following:

sys-apps/portage -rsync-verify

2) Once the 'rsync-verify' USE flag has been unmasked as described
in step 1, it can be enabled with a line like the following in
/etc/portage/package.use:

sys-apps/portage rsync-verify

3) After the configuration changes in steps 1 and 2 have been made, run
the following command:

emerge --oneshot --newuse '>=sys-apps/portage-2.3.24'

After all above steps are successfully completed, a line like the
following should appear in the emerge --info output for the gentoo
repository:

sync-rsync-verify-metamanifest: yes

If you wish to disable it for some reason, you can set
'sync-rsync-verify-metamanifest = no' in your repos.conf.

[1] https://bugs.gentoo.org/650144 sys-apps/portage: [TRACKER] issues
related to 'rsync-verify' USE flag
[2] https://bugs.gentoo.org/647964 app-portage/gemato-11.2: deadlock?
[3] https://bugs.gentoo.org/649276 sys-apps/portage: gpg key refresh
needs exponential backoff with jitter
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] News Item: Portage rsync tree verification unstable

2018-03-10 Thread Robin H. Johnson
On Sat, Mar 10, 2018 at 01:22:49PM -0800, Zac Medico wrote:
> Please review. This is needed in order to resolve
> https://bugs.gentoo.org/650072.
> 
> Title: Portage rsync tree verification unstable
> Author: Zac Medico 
> Posted: 2018-03-13
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: sys-apps/portage
> 
> Starting with sys-apps/portage-2.3.24, Portage will no longer verify
> the Gentoo repository after rsync by default, which contradicts the
> earlier "Portage rsync tree verification" news item.
Can we have something in this message that tells users WHY it's
unstable, beyond just linking to bug 650144? I also don't see any
stablereq bug for gemato yet, which should probably also be tracked.

A rewrite of this first paragraph to that effect:

]] Portage rsync tree verification is being temporarily turned off by
]] default, starting with sys-apps/portage-2.3.24. This permits
]] stabilization of sys-apps/portage-2.3.24 while still working on bugs
]] relating to tree verification [1]: deadlocks [2] & key fetching [3]
]] 
]] [1] https://bugs.gentoo.org/650144 sys-apps/portage: [TRACKER] issues 
related to 'rsync-verify' USE flag
]] [2] https://bugs.gentoo.org/647964 app-portage/gemato-11.2: deadlock?
]] [3] https://bugs.gentoo.org/649276 sys-apps/portage: gpg key refresh needs 
exponential backoff with jitter

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: Digital signature


Re: [gentoo-dev] Packages up for grabs

2018-03-10 Thread Ilya Tumaykin
I'll take dev-python/typing if nobody minds.

On Saturday, 10 March 2018 17:52:21 MSK Pacho Ramos wrote:
> This packages are now up for grabs:
> app-text/pspdftool
> app-admin/supernova
> dev-python/args
> dev-python/attrdict
> dev-python/behave
> dev-python/clint
> dev-python/dockerpty
> dev-python/doublex-expects
> dev-python/doublex
> dev-python/expects
> dev-python/ghp-import
> dev-python/linecache2
> dev-python/livereload
> dev-python/mamba
> dev-python/mando
> dev-python/mkdocs-bootstrap
> dev-python/mkdocs
> dev-python/monotonic
> dev-python/mypy
> dev-python/nose2
> dev-python/os-client-config
> dev-python/paramunittest
> dev-python/parse
> dev-python/parse-type
> dev-python/pycallgraph
> dev-python/pyhamcrest
> dev-python/pytest-raisesregexp
> dev-python/python-termstyle
> dev-python/radon
> dev-python/sphinxcontrib-cheeseshop
> dev-python/sphinxcontrib-newsfeed
> dev-python/sphinxcontrib-spelling
> dev-python/stormpath
> dev-python/texttable
> dev-python/torment
> dev-python/traceback2
> dev-python/typing
> 
> 
> 
-- 
Best regards.
Ilya Tumaykin.

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


Re: [gentoo-dev] News Item: Portage rsync tree verification unstable

2018-03-10 Thread Zac Medico
On 03/10/2018 01:42 PM, Michał Górny wrote:
> W dniu sob, 10.03.2018 o godzinie 13∶22 -0800, użytkownik Zac Medico
> napisał:
>> Please review. This is needed in order to resolve
>> https://bugs.gentoo.org/650072.
>>
>> Title: Portage rsync tree verification unstable
>> Author: Zac Medico 
>> Posted: 2018-03-13
>> Revision: 1
>> News-Item-Format: 2.0
>> Display-If-Installed: sys-apps/portage
>>
>> Starting with sys-apps/portage-2.3.24, Portage will no longer verify
>> the Gentoo repository after rsync by default, which contradicts the
>> earlier "Portage rsync tree verification" news item.
>>
>> If users wish to enable the 'rsync-verify' USE flag for sys-apps/portage,
>> they need to follow these steps:
>>
>> 1) In order to unmask the 'rsync-verify' USE flag, create a file named
>> /etc/portage/profile/package.use.mask containing a line like the
>> following:
>>
>> sys-apps/portage -rsync-verify
> 
> Why do you need to mask it in the first place? The dependencies are
> stable, and it's not like having it unmasked-but-off-by-default is going
> to cause any major harm.

It's only in packages.use.stable.mask, but it simplifies the
instructions for users if we simply refer to package.use.mask here.

Since gemato doesn't have stable keywords yet, the
packages.use.stable.mask is needed so that repoman will allow us
stabilize the latest sys-apps/portage.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] News Item: Portage rsync tree verification unstable

2018-03-10 Thread Michał Górny
W dniu sob, 10.03.2018 o godzinie 13∶22 -0800, użytkownik Zac Medico
napisał:
> Please review. This is needed in order to resolve
> https://bugs.gentoo.org/650072.
> 
> Title: Portage rsync tree verification unstable
> Author: Zac Medico 
> Posted: 2018-03-13
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: sys-apps/portage
> 
> Starting with sys-apps/portage-2.3.24, Portage will no longer verify
> the Gentoo repository after rsync by default, which contradicts the
> earlier "Portage rsync tree verification" news item.
> 
> If users wish to enable the 'rsync-verify' USE flag for sys-apps/portage,
> they need to follow these steps:
> 
> 1) In order to unmask the 'rsync-verify' USE flag, create a file named
> /etc/portage/profile/package.use.mask containing a line like the
> following:
> 
> sys-apps/portage -rsync-verify

Why do you need to mask it in the first place? The dependencies are
stable, and it's not like having it unmasked-but-off-by-default is going
to cause any major harm.

> 
> 2) Once the 'rsync-verify' USE flag has been unmasked as described
> in step 1, it can be enabled with a line like the folling in
> /etc/portage/package.use:
> 
> sys-apps/portage rsync-verify
> 
> 3) After the configuration changes in steps 1 and 2 have been made, run
> the following command:
> 
> emerge --oneshot --newuse '>=sys-apps/portage-2.3.24'
> 
> After all above steps are successfully completed, a line like the
> following should appear in the emerge --info output for the gentoo
> repository:
> 
> sync-rsync-verify-metamanifest: yes
> 
> If you wish to disable it for some reason, you can set
> 'sync-rsync-verify-metamanifest = no' in your repos.conf.
> 
> Problems related to the 'rsync-verify' USE flag are tracked here:
> 
> https://bugs.gentoo.org/650144
> 

-- 
Best regards,
Michał Górny




Re: [gentoo-dev] News Item: Portage rsync tree verification unstable

2018-03-10 Thread M. J. Everitt
On 10/03/18 21:22, Zac Medico wrote:
> Please review. This is needed in order to resolve
> https://bugs.gentoo.org/650072.

> 2) Once the 'rsync-verify' USE flag has been unmasked as described
> in step 1, it can be enabled with a line like the folling in
> /etc/portage/package.use:
s/folling/following/

:)




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] News Item: Portage rsync tree verification unstable

2018-03-10 Thread Zac Medico
Please review. This is needed in order to resolve
https://bugs.gentoo.org/650072.

Title: Portage rsync tree verification unstable
Author: Zac Medico 
Posted: 2018-03-13
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-apps/portage

Starting with sys-apps/portage-2.3.24, Portage will no longer verify
the Gentoo repository after rsync by default, which contradicts the
earlier "Portage rsync tree verification" news item.

If users wish to enable the 'rsync-verify' USE flag for sys-apps/portage,
they need to follow these steps:

1) In order to unmask the 'rsync-verify' USE flag, create a file named
/etc/portage/profile/package.use.mask containing a line like the
following:

sys-apps/portage -rsync-verify

2) Once the 'rsync-verify' USE flag has been unmasked as described
in step 1, it can be enabled with a line like the folling in
/etc/portage/package.use:

sys-apps/portage rsync-verify

3) After the configuration changes in steps 1 and 2 have been made, run
the following command:

emerge --oneshot --newuse '>=sys-apps/portage-2.3.24'

After all above steps are successfully completed, a line like the
following should appear in the emerge --info output for the gentoo
repository:

sync-rsync-verify-metamanifest: yes

If you wish to disable it for some reason, you can set
'sync-rsync-verify-metamanifest = no' in your repos.conf.

Problems related to the 'rsync-verify' USE flag are tracked here:

https://bugs.gentoo.org/650144

-- 
Thanks,
Zac
Title: Portage rsync tree verification unstable
Author: Zac Medico 
Posted: 2018-03-13
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-apps/portage

Starting with sys-apps/portage-2.3.24, Portage will no longer verify
the Gentoo repository after rsync by default, which contradicts the
earlier "Portage rsync tree verification" news item.

If users wish to enable the 'rsync-verify' USE flag for sys-apps/portage,
they need to follow these steps:

1) In order to unmask the 'rsync-verify' USE flag, create a file named
/etc/portage/profile/package.use.mask containing a line like the
following:

sys-apps/portage -rsync-verify

2) Once the 'rsync-verify' USE flag has been unmasked as described
in step 1, it can be enabled with a line like the folling in
/etc/portage/package.use:

sys-apps/portage rsync-verify

3) After the configuration changes in steps 1 and 2 have been made, run
the following command:

emerge --oneshot --newuse '>=sys-apps/portage-2.3.24'

After all above steps are successfully completed, a line like the
following should appear in the emerge --info output for the gentoo
repository:

sync-rsync-verify-metamanifest: yes

If you wish to disable it for some reason, you can set
'sync-rsync-verify-metamanifest = no' in your repos.conf.

Problems related to the 'rsync-verify' USE flag are tracked here:

https://bugs.gentoo.org/650144


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs

2018-03-10 Thread Matthew Thode
On 18-03-10 15:52:21, Pacho Ramos wrote:
> This packages are now up for grabs:
> app-text/pspdftool
> app-admin/supernova
> dev-python/args
> dev-python/attrdict
> dev-python/behave
> dev-python/clint
> dev-python/dockerpty
> dev-python/doublex-expects
> dev-python/doublex
> dev-python/expects
> dev-python/ghp-import
> dev-python/linecache2
> dev-python/livereload
> dev-python/mamba
> dev-python/mando
> dev-python/mkdocs-bootstrap
> dev-python/mkdocs
> dev-python/monotonic
> dev-python/mypy
> dev-python/nose2
> dev-python/os-client-config
> dev-python/paramunittest
> dev-python/parse
> dev-python/parse-type
> dev-python/pycallgraph
> dev-python/pyhamcrest
> dev-python/pytest-raisesregexp
> dev-python/python-termstyle
> dev-python/radon
> dev-python/sphinxcontrib-cheeseshop
> dev-python/sphinxcontrib-newsfeed
> dev-python/sphinxcontrib-spelling
> dev-python/stormpath
> dev-python/texttable
> dev-python/torment
> dev-python/traceback2
> dev-python/typing
> 

I took app-admin/supernova and dev-python/os-client-config for
openstacky stuff

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Packages up for grabs

2018-03-10 Thread Mike Auty
On 10/03/18 14:52, Pacho Ramos wrote:
> This packages are now up for grabs:
> ...
> dev-python/mypy
> ...

I can look after this one if nobody else wants it?

Mike  5:)



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Packages up for grabs

2018-03-10 Thread Pacho Ramos
This packages are now up for grabs:
dev-embedded/mcu8051ide




[gentoo-dev] Packages up for grabs

2018-03-10 Thread Pacho Ramos
This packages are now up for grabs:
x11-misc/kbdd
x11-themes/comix-xcursors



[gentoo-dev] Packages up for grabs

2018-03-10 Thread Pacho Ramos
This packages are now up for grabs:
app-text/pspdftool
app-admin/supernova
dev-python/args
dev-python/attrdict
dev-python/behave
dev-python/clint
dev-python/dockerpty
dev-python/doublex-expects
dev-python/doublex
dev-python/expects
dev-python/ghp-import
dev-python/linecache2
dev-python/livereload
dev-python/mamba
dev-python/mando
dev-python/mkdocs-bootstrap
dev-python/mkdocs
dev-python/monotonic
dev-python/mypy
dev-python/nose2
dev-python/os-client-config
dev-python/paramunittest
dev-python/parse
dev-python/parse-type
dev-python/pycallgraph
dev-python/pyhamcrest
dev-python/pytest-raisesregexp
dev-python/python-termstyle
dev-python/radon
dev-python/sphinxcontrib-cheeseshop
dev-python/sphinxcontrib-newsfeed
dev-python/sphinxcontrib-spelling
dev-python/stormpath
dev-python/texttable
dev-python/torment
dev-python/traceback2
dev-python/typing




[gentoo-dev] Project:Lisp without members

2018-03-10 Thread Pacho Ramos
>From now Project:Lisp has no members... that doesn't seem an issue as it
contains multiple subprojects that maintain relevant packages... but, for the
case anyone wants to join the main project...
https://wiki.gentoo.org/wiki/Project:Lisp



[gentoo-dev] Packages up for grabs

2018-03-10 Thread Pacho Ramos
This packages are now up for grabs:
dev-lang/gnu-smalltalk
x11-misc/fluxter
x11-themes/commonbox-styles-extra
x11-themes/commonbox-styles
x11-themes/fluxbox-styles-fluxmod
x11-wm/fluxbox




[gentoo-dev] Packages up for grabs

2018-03-10 Thread Pacho Ramos
This packages are now up for grabs:
app-text/pspdftool
sys-power/acpid
x11-libs/libyui-gtk
x11-libs/libyui
x11-libs/libyui-ncurses
x11-libs/libyui-qt




[gentoo-dev] Packages up for grabs

2018-03-10 Thread Pacho Ramos
This packages are now up for grabs:
app-portage/repo-commit
dev-libs/libstrl
net-irc/unrealircd




[gentoo-dev] Project:SuSE without members

2018-03-10 Thread Pacho Ramos
>From now Project:SuSE has no members anymore, they maintain this packages (that
will go to maintainer-needed in a week if Project is still without members at
that time)
Thanks
app-arch/rpm
app-backup/kfoldersync
app-backup/snapper
app-benchmarks/os-autoinst
app-text/diction
dev-lang/inform
dev-python/pyinsane
dev-util/hxtools
dev-util/icemon
dev-util/obs-service-cpanspec
dev-util/obs-service-download_files
dev-util/obs-service-download_src_package
dev-util/obs-service-download_url
dev-util/obs-service-extract_file
dev-util/obs-service-format_spec_file
dev-util/obs-service-generator_driver_update_disk
dev-util/obs-service-github_tarballs
dev-util/obs-service-git_tarballs
dev-util/obs-service-meta
dev-util/obs-service-rearchive
dev-util/obs-service-recompress
dev-util/obs-service-set_version
dev-util/obs-service-source_validator
dev-util/obs-service-tar_scm
dev-util/obs-service-update_source
dev-util/obs-service-verify_file
dev-util/osc
dev-util/quilt
dev-util/spec-cleaner
dev-util/suse-build
media-fonts/fifth-leg
sys-devel/icecream




[gentoo-dev] Packages up for grabs

2018-03-10 Thread Pacho Ramos
This packages are now up for grabs:
app-editors/xmlcopyeditor
app-pda/barry
dev-libs/chmlib
dev-util/ftjam
net-p2p/nicotine+




[gentoo-dev] Packages up for grabs

2018-03-10 Thread Pacho Ramos
This packages are now up for grabs:
app-crypt/kali-archive-keyring
net-wireless/orinoco-fwutils
x11-terms/tilda




Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

2018-03-10 Thread Michael Orlitzky
On 03/08/2018 10:40 AM, Michał Górny wrote:
> 
> So, developers, please *stop adding USE=static-libs* to random libraries
> that have no reason whatever to be statically linked to. And by that I
> mean a good reason, not creeping featurism, not 'user asked for it', not
> 'this broken package hardcodes libfoo.a'.
> 
> If upstream doesn't build static libraries by default, don't add flags
> to make it do it.

I've felt the same way for a long time. Flexibility is usually good, but
we shouldn't be going out of our way to add time bombs just because
"safe OR fragile" is technically added flexibility.



Re: [gentoo-dev] Integrating Portage with other package managers

2018-03-10 Thread Kent Fredric
On Wed, 7 Mar 2018 14:55:43 -0600
R0b0t1  wrote:

> I think you missed my point: Why are they easier to use?

Because it decouples your projects requirements from your OS and Vendor
requirements.

This becomes really useful if your OS/Vendor wishes to upgrade things
and force people to upgrade things, but your production software isn't
ready for it yet.

Having to block your entire OS from critical upgrades simply because of
that is just not great.

That doesn't mean I think this is the right approach, but it does
explain why people do that sort of thing. 

*especially* for people who aren't using Gentoo.


pgpC0PcxZZwZZ.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 3/8] linux-info.eclass: linux-info_get_any_version, die on failure

2018-03-10 Thread Michał Górny
W dniu sob, 10.03.2018 o godzinie 01∶05 +, użytkownik Robin H.
Johnson napisał:
> On Thu, Mar 08, 2018 at 06:05:43PM +0100, Michał Górny wrote:
> > Make linux-info_get_any_version die if it can't determine any version
> > of the Linux kernel. This indicates a problem with the eclass code
> > (as it should not happen on Linux) and the missing KV_* variables
> > are going to cause random misbehavior and failures.
> 
> This change worries me a bit. get_running_version calls get_version in
> some cases, and there are corner cases there which could trip this up.
> 
> linux-info_get_any_version -> get_running_version -> get_version
> with get_version returning non-zero.
> 
> get_version has ALREADY returned non-zero once in that path, and we're
> potentially tweaking KERNEL_DIR/KBUILD_OUTPUT before calling it again.
> 
> Most of the breakage cases IIRC are where
> /lib/modules/${KV_FULL}/*/Makefile still exist, but point to kernel
> sources in weird places that are broken.

Yes, and this needs to be fixed one way or another. Otherwise you don't
get KV_* exported and a lot of other logic trips on unset variables.

-- 
Best regards,
Michał Górny