[gentoo-dev] news regarding mysql 5.1 incomplete
Hi, Just noticed yesterday an issue with the upgrade documentation in the news regarding mysql 5.1 and revdep-rebuild. It suggests running # revdep-rebuild --library libmysqlclient.so.15 but this is not enough. mysql has more than one library and not all applications link against the main lib. On a server system (which uses as-needed), I encountered two packages (apr- util and mysql-python) only linking against libmysqlclient_r.so. So at least when mysql 5.1 gets stable, we should correct this. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail:ha...@hboeck.de signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Pending mask of Qt3 and MythTV
On 02/24/2010 02:15 AM, Doug Goldstein wrote: My response was the arch teams haven't stabilized MythTV in years because none of them have a setup to test it, so please stabilize it. I'm running it on a stable machine. Well, to their credit, you CAN'T stabilize a package if you can't test it. I can test it and stabilize it on amd64, but that's it. If there is an arch that nobody has a mythtv setup for testing on then the solution is to drop the stable keyword entirely - not to just mark it stable. As far as the news item goes, as I've said before. Its completely unnecessary since MythTV will handle notifying you properly if you need to do anything to your database. I can count more than a dozen people on Gentoo that have successfully done the conversion without issue. Here is the problem I have with this: doing the migration takes time. Somebody who does an emerge -u world probably doesn't set aside an hour or two to manually fix databases. Anybody doing this for mythtv will at best have a mythtv install that refuses to start until they spend time doing database dumps, sed scripts, and reloads. If for some reason the mythbacked doesn't detect the problem and starts up anyway, then they'll end up with partial database corruptions. I think that if nothing else we should send out a news item warning users that a major mythtv upgrade is coming and that they should exercise care in upgrading it, setting aside time for database cleanup if they are long-time users. I'm completely open to revised wording, but I don't feel comfortable stabilizing this for amd64 without any news at all. I do appreciate all you've done for mythtv, and the time crunch you are in right now. However, if I commit a keyword stabilization I need to be accountable for the results. I suspect the other arch teams feel similarly - nobody wants to just commit something like this without testing and good documentation. How about this revised news item: Title: MythTV 0.22 Upgrade Database Corruption Author: Richard Freeman ri...@gentoo.org Content-Type: text/plain Posted: date Revision: 1 News-Item-Format: 1.0 Display-If-Installed: media-tv/mythtv-0.22 Due to an incompatibility between MythTV 0.21 and the default Gentoo MySQL configuration, it is likely that long-time MythTV users will have databases with a mixture of locale encodings. If you upgrade to 0.22 without following these directions carefully, you could end up with a database that contains errors that are extremely difficult to fix. Note that not all mythtv users need to modify their databases, and this should only be performed at the time of the upgrade. The guide below contains instructions that can be used to determine if this problem pertains to you. Please see the MythTV Upgrade Guide for instructions: http://wiki.mythtv.org/wiki/Fixing_Corrupt_Database_Encoding Be sure to save a database backup before upgrading. Also, be sure to upgrade any other clients/backends you are using to 0.22 at the same time. The upgrade instructions need to be followed once per database - individual client/backend upgrades do not require these steps. If you do run into problems with your upgrade, there is a forum thread where you may be able to find help: http://forums.gentoo.org/viewtopic-t-816566-highlight-.html
[gentoo-dev] Check LICENSE and SRC_URI changes when bumping GNU packages
Hello package maintainers, most of the GNU packages had their LICENSE updated to GPL-3 along with some minor bug fixes or even just documentation changes in recent times. Please do check the LICENSE and adjust it if needed. Oh, and one other thing. Attached is a list of ebuild that use ftp.gnu.org instead of mirror://gnu in their SRC_URI. Please make the switch. Maybe this should be a QA check as well? repoman would have all the information it needed... [if HOMEPAGE matches www.gnu.org, then SRC_URI should NOT match ftp.gnu.org]. Regards, jer gnu-mirror.lst Description: Binary data
Re: [gentoo-dev] Check LICENSE and SRC_URI changes when bumping GNU packages
On Wed, 24 Feb 2010, Jeroen Roovers wrote: Attached is a list of ebuild that use ftp.gnu.org instead of mirror://gnu in their SRC_URI. Please make the switch. Maybe this should be a QA check as well? No, because not all files that are available on ftp://ftp.gnu.org/ are also on mirror://gnu/. For example, this is the case for the ebuilds of app-doc/elisp-manual which are false positives in your list. Ulrich
[gentoo-dev] Proposed change to savedconfig.eclass
Hello developers,
this has annoyed me for a long time.
restore_config() dies when it cannot find a saved config file, while
later on in any ebuild that uses savedconfig.eclass, it will save the
config file anyhow. That means it will not use an edited saved config
file during the first emerge, which is to be expected and should not be
fatal.
The current forces you to emerge the same ebuild twice using _different_
USE flags to achieve anything:
1. USE=-savedconfig emerge cat/foo
2. $EDITOR /etc/portage/savedconfig/cat/foo
3. USE=savedconfig emerge cat/foo
This is quite illogical.
With the patch applied it should be enough to set USE=savedconfig
globally, run `emerge foo', edit the saved config file(s) and run
`emerge foo' again, without having to change the USE flag:
0. euse -E savedconfig # Set USE=savedconfig globally
1. emerge cat/foo
2. $EDITOR /etc/portage/savedconfig/cat/foo
3. emerge cat/foo
4. Profit!
The attached patch actually accomplishes two things:
1) It removes some old code[1] in an elif that apparently never gets
executed (or we would have seen bash syntax bugs filed lng ago).
2) It makes restore_config non-fatal on the first emerge with
USE=savedconfig.
If no one objects, I will look forward to committing the patch in a
week or two.
Regards,
jer
[1] Already present in the first commit.Index: savedconfig.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/savedconfig.eclass,v
retrieving revision 1.12
diff -u -B -r1.12 savedconfig.eclass
--- savedconfig.eclass 30 Oct 2009 16:46:41 - 1.12
+++ savedconfig.eclass 24 Feb 2010 16:52:07 -
@@ -111,16 +111,14 @@
pushd ${found} /dev/null
treecopy . ${dest} || die Failed to restore ${found} to $1
popd /dev/null
- elif [[ -a {found} ]]; then
- die do not know how to handle non-file/directory ${found}
else
# maybe the user is screwing around with perms they shouldnt #289168
if [[ ! -r ${base} ]] ; then
eerror Unable to read ${base} -- perms are screwed ?
die fix your system
fi
- eerror No saved config to restore - please remove USE=savedconfig or
- eerror provide a configuration file in ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${PN}
- die config file needed when USE=savedconfig is specified
+ ewarn No saved config to restore - please remove USE=savedconfig or
+ ewarn provide a configuration file in ${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${PN}
+ ewarn Your config file(s) will not be used this time
fi
}
Re: [gentoo-dev] Check LICENSE and SRC_URI changes when bumping GNU packages
On Wed, 24 Feb 2010 17:47:55 +0100 Ulrich Mueller u...@gentoo.org wrote: On Wed, 24 Feb 2010, Jeroen Roovers wrote: Attached is a list of ebuild that use ftp.gnu.org instead of mirror://gnu in their SRC_URI. Please make the switch. Maybe this should be a QA check as well? No, because not all files that are available on ftp://ftp.gnu.org/ are also on mirror://gnu/. For example, this is the case for the ebuilds of app-doc/elisp-manual which are false positives in your list. OK, then maybe the aberrant ebuilds should document that, just like ebuilds that deviate from the use of emake/econf? Regards, jer
Re: [gentoo-dev] Proposed change to savedconfig.eclass
While you're touching this, could you improve this part a bit:
# maybe the user is screwing around with perms they shouldnt #289168
if [[ ! -r ${base} ]] ; then
eerror Unable to read ${base} -- perms are screwed ?
die fix your system
fi
I understand frustration caused by weird things people are doing with
systems, but sometimes it can be even caused by some tool's error or
whatever. IMHO these are not good error messages. I'd prefer something
like this:
# Make sure we don't hit a problem with permissions, bug #289168
if [[ ! -r ${base} ]] ; then
eerror Unable to read ${base}. Please run chmod 755 ${base}
eerror and try again.
die unable to read ${base}
fi
Thanks,
Paweł Hajdan jr
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Changes to make_desktop_entry in eutils.eclass
El mar, 23-02-2010 a las 20:26 -0500, Jonathan Callen escribió: Attached is a patch to properly comply with the part of the FDO Desktop Menu Specification pertaining to Categories (namely, always ensuring that the list ends in a ;) and the part of the FDO Desktop Entry Specification and Icon Theme Specification pertaining to icons (namely, that non-absolute paths MUST NOT have an extension). Would be nice if you would have time to look at the following old make_desktop_entry bug: http://bugs.gentoo.org/show_bug.cgi?id=191000 Thanks a lot :-D signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] Changes to make_desktop_entry in eutils.eclass
On Wed, 24 Feb 2010, Pacho Ramos wrote: Would be nice if you would have time to look at the following old make_desktop_entry bug: http://bugs.gentoo.org/show_bug.cgi?id=191000 Why should Science be a sub-category of Education? That doesn't make sense to me. Ulrich
Re: [gentoo-dev] upcoming problem? new-style virtuals and USE deps
On Mon, 22 Feb 2010 13:06:37 -0800 Zac Medico zmed...@gentoo.org wrote: There was a bug in sys-apps/portage-2.1.7 (fixed in svn r14281) which prevented propagation of USE deps in virtuals. If you set EAPI=3 in the ebuilds then that will ensure that users will not encounter the bug. Wait, what? If you mean old-style virtuals, the position has always been that it's illegal to dep upon them in any way other than a simple virtual/foo with no operators. If you mean new-style virtuals, then they should be taking care of propagating any relevant use dependencies themselves. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Changes to make_desktop_entry in eutils.eclass
On 02/24/2010 08:40 PM, Ulrich Mueller wrote: On Wed, 24 Feb 2010, Pacho Ramos wrote: Would be nice if you would have time to look at the following old make_desktop_entry bug: http://bugs.gentoo.org/show_bug.cgi?id=191000 Why should Science be a sub-category of Education? That doesn't make sense to me. Ulrich http://standards.freedesktop.org/menu-spec/latest/apa.html Main Category:Education; Additional Category: Education;Science; ( If you don't like it, you need to get a new spec. revision from upstream, so such discussion belongs to freedesktop mailinglist, it's not for distributions to change on their own ) So let's keep this about making make_desktop_entry respect the given spec -Samuli
Re: [gentoo-dev] Changes to make_desktop_entry in eutils.eclass
El mié, 24-02-2010 a las 19:40 +0100, Ulrich Mueller escribió: On Wed, 24 Feb 2010, Pacho Ramos wrote: Would be nice if you would have time to look at the following old make_desktop_entry bug: http://bugs.gentoo.org/show_bug.cgi?id=191000 Why should Science be a sub-category of Education? That doesn't make sense to me. Ulrich I agree with you bad, sadly, spec states it's a sub-category: http://standards.freedesktop.org/menu-spec/latest/apa.html and, for now, we need to use Education,Science if we don't want to see that menu entries showing up in Others menu :-(. This bug is interesting, but I don't think it will be fixed soon :-/ https://bugs.freedesktop.org/show_bug.cgi?id=20186 Best regards signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] Changes to make_desktop_entry in eutils.eclass
El mié, 24-02-2010 a las 19:55 +0100, Pacho Ramos escribió: I agree with you bad... bad - but (sorry for the typo) signature.asc Description: Esta parte del mensaje está firmada digitalmente
[gentoo-dev] Changes to flag-o-matic's _filter-var
Hello everyone,
Here are some minor changes I'd like to propose to flag-o-matic's
_filter-var() to work properly with LDFLAGS.
Without this, things like -Wl,-O1,--as-needed won't be affected by any
kind of filter since there are no spaces to separate each flag.
I don't know of any better way to do this, but here's a patch that works
just fine.
Regards,
Tomas
--- /usr/portage/eclass/flag-o-matic.eclass.old 2010-02-17 16:36:55.0
-0300
+++ /usr/portage/eclass/flag-o-matic.eclass 2010-02-24 17:16:30.0
-0300
@@ -96,14 +96,20 @@
VAR=$1
shift
eval VAL=\${${VAR}}
- for f in ${VAL}; do
- for x in $@; do
+ for f in ${VAL//,/ }; do
+ for x in ${@//,/ }; do
# Note this should work with globs like -O*
[[ ${f} == ${x} ]] continue 2
done
eval new\[\${\#ne...@]}]=\${f}
done
+
eval export ${VAR}=\${new\[*]}
+
+ if [[ ${VAR} == LDFLAGS ]]; then
+ eval VAL=\${${VAR}}
+ eval export ${VAR}=${VAL// /,}
+ fi
}
# @FUNCTION: filter-flags
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Changes to make_desktop_entry in eutils.eclass
On Wed, 24 Feb 2010, Pacho Ramos wrote: Why should Science be a sub-category of Education? That doesn't make sense to me. I agree with you bad, sadly, spec states it's a sub-category: http://standards.freedesktop.org/menu-spec/latest/apa.html Where does it say that Science is a sub-category of Education? It only says: Additional Categories should always be used in combination with *one*of*the Main Categories. and The Related Categories column lists one or more categories that are *suggested* to be used in conjunction with the Additional Category. (my emphasis) and, for now, we need to use Education,Science if we don't want to see that menu entries showing up in Others menu :-(. I don't think that using another main category together with Science is forbidden. This bug is interesting, but I don't think it will be fixed soon :-/ https://bugs.freedesktop.org/show_bug.cgi?id=20186 So they are aware that their classification is stupid. ;-) Ulrich
Re: [gentoo-dev] Changes to make_desktop_entry in eutils.eclass
El mié, 24-02-2010 a las 20:33 +0100, Ulrich Mueller escribió: On Wed, 24 Feb 2010, Pacho Ramos wrote: Why should Science be a sub-category of Education? That doesn't make sense to me. I agree with you bad, sadly, spec states it's a sub-category: http://standards.freedesktop.org/menu-spec/latest/apa.html Where does it say that Science is a sub-category of Education? It only says: Additional Categories should always be used in combination with *one*of*the Main Categories. and The Related Categories column lists one or more categories that are *suggested* to be used in conjunction with the Additional Category. (my emphasis) Maybe I am failing to understand the spec (sorry, I am a bit tired just now), but I am interpreting that Science is not a valid Main category since it's not listed in the first table you can see in link posted before. Also, Science is only listed as a Subcategory under Education main category in the second table and, for now, we need to use Education,Science if we don't want to see that menu entries showing up in Others menu :-(. I don't think that using another main category together with Science is forbidden. I cannot tell you if it's forbidden or not (since I don't know it :-)), but it's currently not supported by, for example, gnome-menus (I don't know about kde, xfce...): https://bugzilla.gnome.org/show_bug.cgi?id=323603 This bug is interesting, but I don't think it will be fixed soon :-/ https://bugs.freedesktop.org/show_bug.cgi?id=20186 So they are aware that their classification is stupid. ;-) Yes, but it won't help as-is to solve current problem or sci-* menu entries being shown in Others menu Best regards signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] Check LICENSE and SRC_URI changes when bumping GNU packages
On 24.2.2010 8.19, Jeroen Roovers wrote: Oh, and one other thing. Attached is a list of ebuild that use ftp.gnu.org instead of mirror://gnu in their SRC_URI. Please make the switch. Maybe this should be a QA check as well? repoman would have all the information it needed... There's already a SRC_URI.mirror check in repoman. Regards, Petteri
[gentoo-dev] Re: Changes to make_desktop_entry in eutils.eclass
On 02/24/2010 01:16 PM, Pacho Ramos wrote:
El mar, 23-02-2010 a las 20:26 -0500, Jonathan Callen escribió:
Attached is a patch to properly comply with the part of the FDO Desktop
Menu Specification pertaining to Categories (namely, always ensuring
that the list ends in a ;) and the part of the FDO Desktop Entry
Specification and Icon Theme Specification pertaining to icons (namely,
that non-absolute paths MUST NOT have an extension).
Would be nice if you would have time to look at the following old
make_desktop_entry bug:
http://bugs.gentoo.org/show_bug.cgi?id=191000
Thanks a lot :-D
I edited the patch to include a fix for but 191000 as well. See attached.
--- eutils.eclass
+++ eutils.eclass.new
@@ -961,6 +961,7 @@ make_desktop_entry() {
news) type=News;;
nntp) type=News;;
p2p)type=FileTransfer;;
+ voip) type=Telephony;;
*) type=;;
esac
type=Network;${type}
@@ -979,7 +980,7 @@ make_desktop_entry() {
visual*) type=DataVisualization;;
*) type=;;
esac
- type=Science;${type}
+ type=Education;Science;${type}
;;
sys)
@@ -991,7 +992,7 @@ make_desktop_entry() {
client) type=WebBrowser;;
*) type=;;
esac
- type=Network
+ type=Network;${type}
;;
*)
@@ -1007,6 +1008,17 @@ make_desktop_entry() {
local desktop=${T}/$(echo ${exec} | sed
's:[[:space:]/:]:_:g')-${desktop_name}.desktop
#local desktop=${T}/${exec%% *:-${desktop_name}}.desktop
+ # Don't append another ; when a valid category value is provided.
+ [[ -n ${type} ${type} != *';' ]] type+=;
+
+ eshopts_push -s extglob
+ if [[ -n ${icon} ${icon} != /* ${icon} == *.@(xpm|png|svg) ]];
then
+ ewarn As described in the Icon Theme Specification, icon file
extensions are not
+ ewarn allowed in .desktop files if the value is not an
absolute path.
+ icon=${icon%.@(xpm|png|svg)}
+ fi
+ eshopts_pop
+
cat -EOF ${desktop}
[Desktop Entry]
Name=${name}
@@ -1015,7 +1027,7 @@ make_desktop_entry() {
Exec=${exec}
TryExec=${exec%% *}
Icon=${icon}
- Categories=${type};
+ Categories=${type}
EOF
[[ ${path} ]] echo Path=${path} ${desktop}
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Changes to make_desktop_entry in eutils.eclass
El mié, 24-02-2010 a las 14:53 -0500, Jonathan Callen escribió: On 02/24/2010 01:16 PM, Pacho Ramos wrote: El mar, 23-02-2010 a las 20:26 -0500, Jonathan Callen escribió: Attached is a patch to properly comply with the part of the FDO Desktop Menu Specification pertaining to Categories (namely, always ensuring that the list ends in a ;) and the part of the FDO Desktop Entry Specification and Icon Theme Specification pertaining to icons (namely, that non-absolute paths MUST NOT have an extension). Would be nice if you would have time to look at the following old make_desktop_entry bug: http://bugs.gentoo.org/show_bug.cgi?id=191000 Thanks a lot :-D I edited the patch to include a fix for but 191000 as well. See attached. Thanks! :-) signature.asc Description: Esta parte del mensaje está firmada digitalmente
[gentoo-dev] Re: Changes to make_desktop_entry in eutils.eclass
On Wed, 24 Feb 2010, Jonathan Callen wrote:
+ # Don't append another ; when a valid category value is provided.
+ [[ -n ${type} ${type} != *';' ]] type+=;
This can be shortened to:
[[ -n ${type} ]] type=${type%;};
or even shorter:
type=${type%;}${type:+;}
Ulrich
Re: [gentoo-dev] upcoming problem? new-style virtuals and USE deps
On 02/24/2010 10:49 AM, Ciaran McCreesh wrote: On Mon, 22 Feb 2010 13:06:37 -0800 Zac Medico zmed...@gentoo.org wrote: There was a bug in sys-apps/portage-2.1.7 (fixed in svn r14281) which prevented propagation of USE deps in virtuals. If you set EAPI=3 in the ebuilds then that will ensure that users will not encounter the bug. Wait, what? If you mean old-style virtuals, the position has always been that it's illegal to dep upon them in any way other than a simple virtual/foo with no operators. If you mean new-style virtuals, then they should be taking care of propagating any relevant use dependencies themselves. The portage bug that I referred to was with new-style virtuals. It was due to complications in the code related to this bug: http://bugs.gentoo.org/show_bug.cgi?id=141118 Due to that code, with sys-apps/portage-2.1.7 you could get some strange results with USE deps inside new-style virtuals. Nobody ever reported a bug though, so maybe it's not very noticeable. -- Thanks, Zac
Re: [gentoo-dev] Re: [RFC] New eclass for x11 packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dne 19.2.2010 02:22, Ryan Hill napsal(a):
On Thu, 18 Feb 2010 23:33:42 +0100
Tomáš Chvátal scarab...@gentoo.org wrote:
Hi,
we prepared new eclass for x11 packages that should be used as
replacement for x-modular.eclass.
After long discussion with others on irc we choose to name it as
xorg-2.eclass.
Whats new/changed:
Fonts handling slightly rewritten to be done as written in specs (or i
hope i did so :]).
It'd be nice to move all of the fonts stuff to font.eclass. Right now we
have two similar-but-not-quite font systems that tend to do the same thing
but drift apart sometimes in incompatible ways.
But I know I don't have time to do it and it seems to work well enough right
now, so
meh. ;)
[[ ${PN} == util-macros ]] || DEPEND+= =x11-misc/util-macros-1.3.0
[[ ${PN} == font-util ]] || DEPEND+= =media-fonts/font-util-1.1.1-r1
Do non-fonts really need font-util there? Looks like that sets up a nice
circular dependency.
The same dep is in x-modular eclass. I spoted it in some fonts packages
as required so i left it there.
Good work/idea would be if someone doublecheck that one :]
Hmm, I don't see it in x-modular. It shouldn't be required for non-fonts
unless something in git needs it for some wacky reason.
remove_font_metadata() {
if [[ ${FONT_DIR} != Speedo ${FONT_DIR} != CID ]]; then
einfo Removing font metadata
rm -rf
${ED}/usr/share/fonts/${FONT_DIR}/fonts.{scale,dir,cache-1}
fi
}
Sorry, I forgot I was going to follow up on this.. FONT_DIR is a
space-separated list of directories. The only example of a font with
multiple directories I know of is font-misc-ethiopic. In that case, the
command run here would be:
rm -rf /usr/share/fonts/TTF OTF/fonts.{scale,dir,cache-1}
:/
cleanup_fonts(), create_fonts_scale(), and create_fonts_dir() are similarly
broken with multiple directories.
create_fonts_scale() {
if [[ ${DIR} != Speedo ${DIR} != CID ]]; then
I think you mean ${FONT_DIR} here.
YEAH :P Fixed in git.
Honestly, you might consider dropping TTF from font-misc-ethiopic and only
install the OTF version. It would simplify things greatly.
Well everywhere the FONT_DIR is treated as one dir, so maybe we should
just bash to submission the one offending ebuild and be done with it.
I can of course write logic to count with space separated list...
You decide, after all you are font guy :P Or actually anyone share your
opinions about this :]
Tomas
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuFkh4ACgkQHB6c3gNBRYfQJQCfZnjWiT6GtKloZCMncnWe/Aas
VRsAoM5nHXldDiygrYMyZPg9aLB46G0V
=Kooc
-END PGP SIGNATURE-
[gentoo-dev] Re: Changes to flag-o-matic's _filter-var
ChIIph posted on Wed, 24 Feb 2010 17:27:21 -0300 as excerpted: Here are some minor changes I'd like to propose to flag-o-matic's _filter-var() to work properly with LDFLAGS. Without this, things like -Wl,-O1,--as-needed won't be affected by any kind of filter since there are no spaces to separate each flag. As one of the guys with such an LDFLAGS set, thanks. =:^) -- 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] metadata.xml: changepolicies
I'm forking this thread from -core, so we can have some useful discussion about the idea, and then somebody can take it to the gentoo-dev list. This needs a lot more polishing still, and I'm not happy with some of the semantics (esp. policy is too harsh a word for what we are trying to convey). Metadata.xml should allow use of a changepolicies element. Within the element, package maintainers should be able to describe how non-maintainer changes to the package are handled. The changepolicy element should contain zero or more change elements, each of which present a tuple of the type of change (type attribute) and the policy (policy attribute) for that type. Proposed types: --- - version-bump - trivial-version-bump - trivial-fixes - fixes - enhancements - qa-fixes - trivial-qa-fixes TODO: I'm not sure what we'd put into some of these type at this point. One dimension of split would be things that require a revbump vs. those that don't. trivial-version-bump is probably the easiest one to handle, simply copying the ebuild with changes to HOMEPAGE/SRC_URI/KEYWORDS. Proposed policies: -- - file-bug: A bug (ideally with patch) should be filed only. - review-requested: Discuss the change with a maintainer via ANY means, get a +1 for it, and then you can commit it. - notify: Do the change AND notify the maintainer. - allowed: Do the change, no notification required. Proposed defaults: -- TODO: I can see a lot of value in motivating developers by declaring the defaults for change policies shall be that all types are notify. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpC22xbi1civ.pgp Description: PGP signature
[gentoo-dev] [rfc] Criticial news item 2010-02-25-layman-storage-path-change (GLEP 42)
Hello! As a proper solution to bug #306233 [1] I have prepared a draft for a related glep-42-style [2] news item, my first such item ever. This is my request for review. If I don't hear anything for the next 72 hours I may put it online, as I understand the GLEP. If you'd need more time for a proper review just let me know. Here we go: === Title: Layman storage path changed from version 1.3.0 on Author: Sebastian Pipping sp...@gentoo.org Content-Type: text/plain Posted: 2010-02-25 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: app-portage/layman-1.3 Layman has been using /usr/local/portage/layman to store overlay checkouts from version 1.2.3 on. As that path was violating the concept of keeping portage away from /usr/local the default of this storage location moves to /var/lib/layman from version 1.3.0 on. If you have never modified /etc/layman.cfg manually before, you may be tempted to let tools like etc-update or cfg-update blindly accept this new version of layman.cfg. As that would hide all your currently installed overlays from layman it's probably not what you want. Your options are: A) Moving Move your current location to /var/lib/layman before upgrading B) A symlink Put a symlink to your current storage location at /var/lib/layman before upgrading layman C) Configuration Reject the path change for layman.cfg when running tools like etc-update or cfg-update blindly. Be aware with this way you'll have to do it for each layman update again. PS: This news item is a reaction to users having run into this problem (see bug #306233). Thanks to Volker Hemmann for reporting. === Thanks for your help, Sebastian [1] http://bugs.gentoo.org/show_bug.cgi?id=306233 [2] http://www.gentoo.org/proj/en/glep/glep-0042.html
Re: [gentoo-dev] news regarding mysql 5.1 incomplete
On Wed, Feb 24, 2010 at 01:45:31PM +0100, Hanno Böck wrote: Just noticed yesterday an issue with the upgrade documentation in the news regarding mysql 5.1 and revdep-rebuild. It suggests running # revdep-rebuild --library libmysqlclient.so.15 but this is not enough. mysql has more than one library and not all applications link against the main lib. On a server system (which uses as-needed), I encountered two packages (apr- util and mysql-python) only linking against libmysqlclient_r.so. So at least when mysql 5.1 gets stable, we should correct this. News item updated now. It looks like qt-sql might have been linking to libmysqlclient_r too. I didn't catch it myself as I used the @preserved-rebuild support in newer Portage. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpej83cwQUQ4.pgp Description: PGP signature
Re: [gentoo-dev] Re: Pending mask of Qt3 and MythTV
On 24 February 2010 08:15, Doug Goldstein car...@gentoo.org wrote: On Sun, Feb 21, 2010 at 11:25 PM, Ben de Groot yng...@gentoo.org wrote: [...] one remaining issue: MythTV. Its current stable version uses Qt3, but there is a Qt4 version in testing. In all this time the MythTV maintainers have not taken any action. Incorrect. You came to me a few months ago and I told you I would not and will not have time to mess with the package at all. I think I've made that clear in past mailing list posts, discussions we've had, and on bugzilla. Many people have spoken up about the situation and time and time again I've said please, take over the package. It needs to be stabilized and a new unstable bump needs to happen. As we are all volunteers, I appreciate that you may not have time to do what this package needs. That is not an accusation, just a statement of facts. What you could maybe have done is reassign this package to maintainer-needed, as that seems to be more accurate. But it is co-assigned to the mythtv herd, and the other herd members have also not helped out in this issue. My response was [...] please stabilize it. I'm running it on a stable machine. [...] So I ask you once again, PLEASE just mark it stable. SOMEONE. Which is why we added arches to the bug for stabilization. But then the issue came up that we really need a news item. As far as the news item goes, as I've said before. Its completely unnecessary since MythTV will handle notifying you properly if you need to do anything to your database. A good number of people seem to disagree. I actually haven't heard anyone saying we don't need a news item, apart from you. But I'm happy to defer to QA, whatever they think is the best solution. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
[gentoo-dev] Re: news regarding mysql 5.1 incomplete
On 02/25/2010 02:44 AM, Robin H. Johnson wrote: On Wed, Feb 24, 2010 at 01:45:31PM +0100, Hanno Böck wrote: Just noticed yesterday an issue with the upgrade documentation in the news regarding mysql 5.1 and revdep-rebuild. It suggests running # revdep-rebuild --library libmysqlclient.so.15 but this is not enough. mysql has more than one library and not all applications link against the main lib. On a server system (which uses as-needed), I encountered two packages (apr- util and mysql-python) only linking against libmysqlclient_r.so. So at least when mysql 5.1 gets stable, we should correct this. News item updated now. It looks like qt-sql might have been linking to libmysqlclient_r too. I didn't catch it myself as I used the @preserved-rebuild support in newer Portage. Doesn't revdep-rebuild support regular expressions? You might want to use one to catch all linkages.
[gentoo-dev] gentoo-sources 2.6.32 stable plans
I'm planning to request the stabling of gentoo-sources-2.6.32 on March 5th, a little more than 1 week from now. We have a few regressions we are tracking but they are not far reaching and most are close to resolution. We will follow up on all unresolved regressions. Regressions in external packages in the stable tree are tracked in bug #300324. If any arise, please make every effort to fix these. Thanks, Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [rfc] Criticial news item 2010-02-25-layman-storage-path-change (GLEP 42)
On 02/25/10 01:15, Sebastian Pipping wrote: === Title: Layman storage path changed from version 1.3.0 on Author: Sebastian Pipping sp...@gentoo.org Content-Type: text/plain Posted: 2010-02-25 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: app-portage/layman-1.3 Layman has been using /usr/local/portage/layman to store overlay checkouts from version 1.2.3 on. As that path was violating the concept of keeping portage away from /usr/local the default of this storage location moves to /var/lib/layman from version 1.3.0 on. If you have never modified /etc/layman.cfg manually before, you may be tempted to let tools like etc-update or cfg-update blindly accept this new version of layman.cfg. Err: /etc/layman/layman.cfg not /etc/layman.cfg Fixed: from version 1.3.0 on. If you have never touched the file /etc/layman/layman.cfg manually before, you may be tempted to let tools like etc-update or cfg-update blindly accept this new version of layman.cfg. As that would hide all your currently installed overlays from layman it's probably not what you want. Your options are: A) Moving Move your current location to /var/lib/layman before upgrading Forgot about PORTDIR_OVERLAY: A) Moving Move your current location to /var/lib/layman before upgrading. Also update PORTDIR_OVERLAY in make.conf accordingly. B) A symlink Put a symlink to your current storage location at /var/lib/layman before upgrading layman. C) Configuration Reject the path change for layman.cfg when running tools like etc-update or cfg-update blindly. Be aware with this way you'll have to do it for each layman update again. PS: This news item is a reaction to users having run into this problem (see bug #306233). Thanks to Volker Hemmann for reporting. ===
Re: [gentoo-dev] metadata.xml: changepolicies
On Wed, 24 Feb 2010, Robin H Johnson wrote: Metadata.xml should allow use of a changepolicies element. Within the element, package maintainers should be able to describe how non-maintainer changes to the package are handled. Could we allow this element in the category metadata files, too? Its value there would be the default for the category, with the possibility to override it for individual packages. Ulrich
