[gentoo-dev] Package removal without proper last-riting
Hi, I recently noticed it twice, that it seems to be common practice to remove a package without using the methods described in [1], but just dropping it from cvs. From my observations packages removed without last-rites could be characterized by this: - it was a dependency of another package - this package dropped / incorporated the dependency - no other packages depend on it - there are possible forks or updates, but maintainer doesn't care^W^W has no interest This might work for the main tree, but it won't for overlays, that might also depend on these packages (because they have a patched / older version of your maintained package). Please stop killing user experience or document this feature in [1]. Best regards, Manuel [1] http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Package removal without proper last-riting
11.11.2013 13:32, Manuel Rüger wrote: Hi, I recently noticed it twice, that it seems to be common practice to remove a package without using the methods described in [1], but just dropping it from cvs. From my observations packages removed without last-rites could be characterized by this: - it was a dependency of another package - this package dropped / incorporated the dependency - no other packages depend on it - there are possible forks or updates, but maintainer doesn't care^W^W has no interest +1, this should be documented IMO. I last-rite games-strategy/seven-kingdoms-data recently without sending notice, cause last versions of games-strategy/seven-kingdoms includes all of it's data. This might work for the main tree, but it won't for overlays, that might also depend on these packages (because they have a patched / older version of your maintained package). We are trying not to break overlays, but we also can not guarantee full support for them. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Package removal without proper last-riting
Dnia 2013-11-11, o godz. 13:38:56 Sergey Popov pinkb...@gentoo.org napisał(a): 11.11.2013 13:32, Manuel Rüger wrote: Hi, I recently noticed it twice, that it seems to be common practice to remove a package without using the methods described in [1], but just dropping it from cvs. From my observations packages removed without last-rites could be characterized by this: - it was a dependency of another package - this package dropped / incorporated the dependency - no other packages depend on it - there are possible forks or updates, but maintainer doesn't care^W^W has no interest +1, this should be documented IMO. I last-rite games-strategy/seven-kingdoms-data recently without sending notice, cause last versions of games-strategy/seven-kingdoms includes all of it's data. How hard would it be to send proper last rites for that package and add it to package.mask explaining the move? Silent removals do us no good. The only valid reason to remove a package without lastriting it is when it is package-moved with proper 'updates' entry. However, that won't work for package merges, so the usual lastriting procedure applies. Overlays are just one of the potential issues. Another issue is users who ended up with that package in @world. If it were masked, they would know why they need to remove it. Now, they will just get awful blockers. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Package removal without proper last-riting
On Mon, 11 Nov 2013 10:47:30 +0100 Michał Górny mgo...@gentoo.org wrote: Silent removals do us no good. (Disabled wrapping due to table size) We get mails about these; so, we can enumerate them to tell those doing it incorrectly to ensure that they correct their way of doing it. Since there are multiple people involved, this is in no way a way to blame them but rather to ensure we restore a sane way of doing it. + means properly announced, - means unannounced and () is location; proper assumes announcement in mask, dev and dev-announce. The last month or so: +dev-games/neoengine 2013-10-03 04:39:14 creffett +dev-games/neotools2013-10-03 13:37:49 creffett +dev-python/pyme 2013-10-05 18:40:23 mgorny -net-irc/ezbounce (dev-only) 2013-10-12 12:01:50 pacho -app-misc/gpsdrive (dev-only) 2013-10-12 12:02:26 pacho -sys-fs/cdfs (dev-only)2013-10-12 12:04:00 pacho +virtual/python-json 2013-10-12 12:19:49 pacho +dev-php/symfony 2013-10-12 12:22:32 pacho -dev-vcs/bzr-svn (mask-only) 2013-10-12 12:23:34 pacho +dev-tex/natbib2013-10-12 20:15:11 dilfridge -dev-db/edb (dev-only) 2013-10-19 06:08:25 mr_bones_ -x11-plugins/yawmppp (dev-only)2013-10-19 06:09:06 mr_bones_ -x11-plugins/mountapp (dev-only) 2013-10-19 06:09:07 mr_bones_ -net-p2p/lopster (dev-only)2013-10-19 06:09:46 mr_bones_ -net-p2p/gnapster (dev-only) 2013-10-19 06:09:46 mr_bones_ -net-dialup/gcdial (dev-only) 2013-10-19 06:10:17 mr_bones_ -dev-embedded/xgpasm (dev-only)2013-10-19 06:10:54 mr_bones_ -app-mobilephone/tsemgr (dev-only) 2013-10-19 06:11:21 mr_bones_ -app-dicts/babytrans (dev-only)2013-10-19 06:12:29 mr_bones_ -app-dicts/babytrans-en (dev-only) 2013-10-19 06:12:29 mr_bones_ -app-dicts/babytrans-en2en (dev-only) 2013-10-19 06:12:29 mr_bones_ -app-dicts/babytrans-en2fre (dev-only) 2013-10-19 06:12:30 mr_bones_ -app-dicts/babytrans-en2ger (dev-only) 2013-10-19 06:12:30 mr_bones_ -app-dicts/babytrans-en2ita (dev-only) 2013-10-19 06:12:30 mr_bones_ -app-dicts/babytrans-en2pt (dev-only) 2013-10-19 06:12:30 mr_bones_ -app-dicts/babytrans-en2spa (dev-only) 2013-10-19 06:12:30 mr_bones_ +sys-firmware/amd-ucode2013-10-21 19:48:13 hwoarang +virtual/pyparsing 2013-10-22 15:42:19 mgorny +net-news/raggle 2013-10-29 03:48:16 mrueg +app-office/tpp2013-10-29 03:49:10 mrueg +dev-ruby/ncurses-ruby 2013-10-29 03:50:27 mrueg +dev-ruby/main 2013-10-29 03:51:53 mrueg +dev-ruby/rcov 2013-10-29 03:52:19 mrueg +dev-ruby/ruby-svg 2013-10-29 03:52:53 mrueg +dev-ruby/rqr 2013-10-29 03:53:15 mrueg +dev-ruby/heckle 2013-10-29 03:53:39 mrueg -x11-themes/qtcurve-qt4 (pkg-move) 2013-11-04 04:54:16 yngwin -net-im/python-otr (pkg-move) 2013-11-09 18:10:16 hanno -dev-games/gigi (mask-only)2013-11-10 14:14:48 tomka -games-strategy/seven-kingdoms-data (none) 2013-11-10 15:38:27 pinkbyte Two interesting things to note here are that 1) dev-only seems to be the main cause of lost announcements, which isn't that worry some as most of us still receive them but it would be nice for them to be in dev-announce as well; 2) pkg-moves land up in removals, we might want to see if we can bring these under a separate list in the automatic script by hwoarang. After all there seem to be no worrying removals in this set, which is good; we might want to follow this up slightly more closely though. We also get to see some timed out last rites that were not removed yet: # Vicente Olivert Riera vinc...@gentoo.org (08 Jul 2013) # Fails to install. Maintainer suggested treeclean. # Masked for removal in 30 days, bug #440670. dev-java/pat-1.5.3 ^ This is an interesting one, still exists in tree; not in package.mask and also not in the ChangeLog of package.mask. What happened here? # Justin Lecher j...@gentoo.org (17 Jul 2013) # superseeded by sci-biology/allpathslg # Upstream wants anybody to move over sci-biology/allpaths # Ian Stakenvicius a...@gentoo.org (20 Sep 2013) # on behalf of mozi...@gentoo.org # Severely outdated, no interest in maintaining, # only a matter of time before it breaks, # major QA issues with newer versions # See bug #442122 for discussion # Masked for removal in 30 days www-plugins/mozplugger These persons were reminded on IRC. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34
Re: [gentoo-dev] Package removal without proper last-riting
On 11/11/2013 01:51 PM, Tom Wijsman wrote: On Mon, 11 Nov 2013 10:47:30 +0100 Michał Górny mgo...@gentoo.org wrote: -dev-games/gigi (mask-only)2013-11-10 14:14:48 tomka This was also dev-only not mask-only: http://article.gmane.org/gmane.linux.gentoo.devel/88455/match=gigi Two interesting things to note here are that 1) dev-only seems to be the main cause of lost announcements, which isn't that worry some as most of us still receive them but it would be nice for them to be in dev-announce as well; I simply last-rite so seldom that I forgot that they go to dev-announce. Cheers, Thomas -- Thomas Kahle signature.asc Description: OpenPGP digital signature
[gentoo-dev] qmake-utils.eclass: new eclass with eqmake4/eqmake5 functions
Some work on splitting these helper functions was done earlier, and then
we have got request(bug #479744), so, with ACK from pesa, i would like
to propose this new eclass here and some times after - another proposal
with making qt4-r2 eclass depends on this one to prevent code duplication.
So, here it is(directly from qt overlay):
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: qmake-utils.eclass
# @MAINTAINER:
# Qt herd q...@gentoo.org
# @AUTHOR:
# Davide Pesavento p...@gentoo.org
# @BLURB: Common functions for qmake-based packages.
# @DESCRIPTION:
# Utility eclass providing wrapper functions for Qt4 and Qt5 qmake.
if [[ ${___ECLASS_ONCE_QMAKE_UTILS} != recur -_+^+_- spank ]]; then
___ECLASS_ONCE_QMAKE_UTILS=recur -_+^+_- spank
inherit eutils multilib toolchain-funcs
# @FUNCTION: qmake-utils_find_pro_file
# @RETURN: zero or one qmake .pro file names
# @INTERNAL
# @DESCRIPTION:
# Outputs a project file name that can be passed to eqmake.
# 0 *.pro files found -- outputs null string;
# 1 *.pro file found -- outputs its name;
# 2 or more *.pro files found -- if ${PN}.pro or
# $(basename ${S}).pro are there, outputs one of them.
qmake-utils_find_pro_file() {
local dir_name=$(basename ${S})
# set nullglob to avoid expanding *.pro to the literal
# string *.pro when there are no matching files
eshopts_push -s nullglob
local pro_files=(*.pro)
eshopts_pop
case ${#pro_files[@]} in
0)
: ;;
1)
echo ${pro_files}
;;
*)
for pro_file in ${pro_files[@]}; do
if [[ ${pro_file%.pro} == ${dir_name} ||
${pro_file%.pro} == ${PN}
]]; then
echo ${pro_file}
break
fi
done
;;
esac
}
# @VARIABLE: EQMAKE4_EXCLUDE
# @DEFAULT_UNSET
# @DESCRIPTION:
# List of files to be excluded from eqmake4 CONFIG processing.
# Paths are relative to the current working directory (usually ${S}).
#
# Example: EQMAKE4_EXCLUDE=ignore/me.pro foo/*
# @FUNCTION: eqmake4
# @USAGE: [project_file] [parameters to qmake]
# @DESCRIPTION:
# Wrapper for Qt4's qmake. If project_file isn't specified, eqmake4 will
# look for it in the current directory (${S}, non-recursively). If more
# than one project file are found, then ${PN}.pro is processed, provided
# that it exists. Otherwise eqmake4 fails.
#
# All other arguments are appended unmodified to qmake command line.
#
# For recursive build systems, i.e. those based on the subdirs template,
# you should run eqmake4 on the top-level project file only, unless you
# have a valid reason to do otherwise. During the building, qmake will
# be automatically re-invoked with the right arguments on every directory
# specified inside the top-level project file.
eqmake4() {
debug-print-function ${FUNCNAME} $@
has ${EAPI:-0} 0 1 2 use !prefix EPREFIX=
ebegin Running qmake
local qmake_args=($@)
# check if project file was passed as a first argument
# if not, then search for it
local regexp='.*\.pro'
if ! [[ ${1} =~ ${regexp} ]]; then
local project_file=$(qmake-utils_find_pro_file)
if [[ -z ${project_file} ]]; then
echo
eerror No project files found in '${PWD}'!
eerror This shouldn't happen - please send a bug
report to
https://bugs.gentoo.org/;
echo
die eqmake4 failed
fi
qmake_args+=(${project_file})
fi
# make sure CONFIG variable is correctly set
# for both release and debug builds
local config_add=release
local config_remove=debug
if has debug ${IUSE} use debug; then
config_add=debug
config_remove=release
fi
local awkscript='BEGIN {
printf ### eqmake4 was here ###\n file;
printf CONFIG -= debug_and_release %s\n,
remove file;
printf CONFIG += %s\n\n, add file;
fixed=0;
}
/^[[:blank:]]*CONFIG[[:blank:]]*[\+\*]?=/ {
if (gsub(\\(( remove
)|(debug_and_release))\\, ) 0) {
fixed=1;
}
}
/^[[:blank:]]*CONFIG[[:blank:]]*-=/ {
if (gsub(\\ add \\, ) 0) {
fixed=1;
}
}
{
print file;
Re: [gentoo-dev] GLEP proposal: Gentoo GPG key policies
On Sun, 2013-11-10 at 17:45 -0800, Brian Dolbec wrote:
On Mon, 2013-11-11 at 00:01 +, Robin H. Johnson wrote:
Gentoo LDAP:
All developers must list the complete GPG fingerprint for their root
keys in the gpgfingerprint LDAP field.
It should be exactly 40 hex digits, uppercase, with optional spaces
every 8 hex digits. Regular expression for validation: ^[[:xdigit]]{8}(
?[[:xdigit]]{8}){4}$
The problem I can see happening allowing the optional spaces is that
currently the fingerpint field is a space separated list of
fingerprints. In the ldap-seeds code used to generate the
developer.seeds file. I am splitting that field data on the spaces to
get a python list of individual fingerprints. There are developers that
have 2 fingerprints listed. If spaces are to be allowed in the
fingerprint then we will need to use and enforce a different separator
to divide the fingerprints. Currently in gentoo-keys I use the : as a
separator in the gpgkey and fingerprint fields of the seed file. A |
is used to separate the fields of the seed info.
Forget I said the above. I should have re-read my code first. Multiple
fingerprints are already returned as a list from python ldap. I already
had code in place to condense spaces in the fingerprint before the
checks.
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] About preferred ntp provider
Reading: https://bugs.gentoo.org/show_bug.cgi?id=489044 https://bugs.gentoo.org/show_bug.cgi?id=489040 I don't know what should be preferred, personally I use net-misc/ntp simply because I have always being using it, also looks like we don't have any virtual that could point me about the preferred provider on Gentoo. Do you know that? Thanks a lot
Re: [gentoo-dev] Package removal without proper last-riting
On 11/11/2013 06:51, Tom Wijsman wrote: On Mon, 11 Nov 2013 10:47:30 +0100 Michał Górny mgo...@gentoo.org wrote: Silent removals do us no good. ... 1) dev-only seems to be the main cause of lost announcements, which isn't that worry some as most of us still receive them but it would be nice for them to be in dev-announce as well; This is actually the reason I subscribed to -dev in the first place. I started noticing that some packages I needed/used/used to use/etc. were being removed and I wanted to find out why. At first, I subscribed to -announce and -dev-announce, but I found that I still wasn't being notified. I know overlays aren't officially supported, but the courtesy of announcing package removals, especially libraries, would be much appreciated. There have been times that a library I use for an internal project, for example, was removed without notice, forcing me to look at the CVS attic to find out why. More often than not, though, the commit message is simply removed or clean up, which is just as unhelpful. While I have no problem copying stuff back out of the attic into a local overlay, it would be nice to prepare for that before something breaks. Thank you, -- ♫Dustin http://dustin.hatch.name/
Re: [gentoo-dev] Package removal without proper last-riting
12.11.2013 03:55, Dustin C. Hatch пишет: On 11/11/2013 06:51, Tom Wijsman wrote: On Mon, 11 Nov 2013 10:47:30 +0100 Michał Górny mgo...@gentoo.org wrote: Silent removals do us no good. ... 1) dev-only seems to be the main cause of lost announcements, which isn't that worry some as most of us still receive them but it would be nice for them to be in dev-announce as well; This is actually the reason I subscribed to -dev in the first place. I started noticing that some packages I needed/used/used to use/etc. were being removed and I wanted to find out why. At first, I subscribed to -announce and -dev-announce, but I found that I still wasn't being notified. And this is bad thing, cause IIRC devmanual says that such removals should be sent to -dev-announce. I know overlays aren't officially supported, but the courtesy of announcing package removals, especially libraries, would be much appreciated. There have been times that a library I use for an internal project, for example, was removed without notice, forcing me to look at the CVS attic to find out why. More often than not, though, the commit message is simply removed or clean up, which is just as unhelpful. While I have no problem copying stuff back out of the attic into a local overlay, it would be nice to prepare for that before something breaks. Thank you, -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
