[gentoo-dev] Re: News Item v2: Portage rsync tree verification unstable
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
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
# 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
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
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
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
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
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
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
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
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
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
This packages are now up for grabs: dev-embedded/mcu8051ide
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: x11-misc/kbdd x11-themes/comix-xcursors
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: app-text/pspdftool app-admin/supernova dev-python/args dev-python/attrdict dev-python/behave dev-python/clint dev-python/dockerpty dev-python/doublex-expects dev-python/doublex dev-python/expects dev-python/ghp-import dev-python/linecache2 dev-python/livereload dev-python/mamba dev-python/mando dev-python/mkdocs-bootstrap dev-python/mkdocs dev-python/monotonic dev-python/mypy dev-python/nose2 dev-python/os-client-config dev-python/paramunittest dev-python/parse dev-python/parse-type dev-python/pycallgraph dev-python/pyhamcrest dev-python/pytest-raisesregexp dev-python/python-termstyle dev-python/radon dev-python/sphinxcontrib-cheeseshop dev-python/sphinxcontrib-newsfeed dev-python/sphinxcontrib-spelling dev-python/stormpath dev-python/texttable dev-python/torment dev-python/traceback2 dev-python/typing
[gentoo-dev] Project:Lisp without members
>From now Project:Lisp has no members... that doesn't seem an issue as it contains multiple subprojects that maintain relevant packages... but, for the case anyone wants to join the main project... https://wiki.gentoo.org/wiki/Project:Lisp
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: dev-lang/gnu-smalltalk x11-misc/fluxter x11-themes/commonbox-styles-extra x11-themes/commonbox-styles x11-themes/fluxbox-styles-fluxmod x11-wm/fluxbox
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: app-text/pspdftool sys-power/acpid x11-libs/libyui-gtk x11-libs/libyui x11-libs/libyui-ncurses x11-libs/libyui-qt
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: app-portage/repo-commit dev-libs/libstrl net-irc/unrealircd
[gentoo-dev] Project:SuSE without members
>From now Project:SuSE has no members anymore, they maintain this packages (that will go to maintainer-needed in a week if Project is still without members at that time) Thanks app-arch/rpm app-backup/kfoldersync app-backup/snapper app-benchmarks/os-autoinst app-text/diction dev-lang/inform dev-python/pyinsane dev-util/hxtools dev-util/icemon dev-util/obs-service-cpanspec dev-util/obs-service-download_files dev-util/obs-service-download_src_package dev-util/obs-service-download_url dev-util/obs-service-extract_file dev-util/obs-service-format_spec_file dev-util/obs-service-generator_driver_update_disk dev-util/obs-service-github_tarballs dev-util/obs-service-git_tarballs dev-util/obs-service-meta dev-util/obs-service-rearchive dev-util/obs-service-recompress dev-util/obs-service-set_version dev-util/obs-service-source_validator dev-util/obs-service-tar_scm dev-util/obs-service-update_source dev-util/obs-service-verify_file dev-util/osc dev-util/quilt dev-util/spec-cleaner dev-util/suse-build media-fonts/fifth-leg sys-devel/icecream
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: app-editors/xmlcopyeditor app-pda/barry dev-libs/chmlib dev-util/ftjam net-p2p/nicotine+
[gentoo-dev] Packages up for grabs
This packages are now up for grabs: app-crypt/kali-archive-keyring net-wireless/orinoco-fwutils x11-terms/tilda
Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo
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
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
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