[gentoo-dev] Re: [RFC] News item: 2010-03-01 MythTV 0.22 Upgrade Database Corruption
-- Forwarded message -- From: Alec Warner anta...@gentoo.org Date: 26 February 2010 04:52 Subject: Re: [RFC] News item: 2010-03-01 MythTV 0.22 Upgrade Database Corruption To: Ben de Groot yng...@gentoo.org Cc: p...@gentoo.org Is there a simple way for users to determine what client versions they may have? -A On Thu, Feb 25, 2010 at 7:13 PM, Ben de Groot yng...@gentoo.org wrote: Forgot to send it to pr@ -- Forwarded message -- From: Ben de Groot yng...@gentoo.org Date: 26 February 2010 02:19 Subject: [RFC] News item: 2010-03-01 MythTV 0.22 Upgrade Database Corruption To: gentoo-dev@lists.gentoo.org I think this is good to go, let's get some comments from the list. Ben -- Forwarded message -- From: Richard Freeman ri...@gentoo.org Date: 24 February 2010 16:57 Subject: Re: [gentoo-dev] Re: Pending mask of Qt3 and MythTV To: gentoo-dev@lists.gentoo.org How about this revised news item: Title: MythTV 0.22 Upgrade Database Corruption Author: Richard Freeman ri...@gentoo.org Content-Type: text/plain Posted: 2010-03-01 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 -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Re: [RFC] News item: 2010-03-01 MythTV 0.22 Upgrade Database Corruption
On 02/26/2010 07:06 AM, Ben de Groot wrote: Is there a simple way for users to determine what client versions they may have? Forwarding my reply: Well, they can always just ask the package manager what version is installed. The news item is targeted only at users who do not already have mythtv 0.22 installed, so only potentially impacted users will get the announcement. The guide includes instructions for determining whether a particular database has problems. mythfrontend also has a --version option that returns some useful information. However, anybody getting the news item has a potential issue, and since mythtv isn't compatible across client versions if their gentoo install has a problem then all of their clients should need an upgrade. Rich
Re: [gentoo-dev] [rfc] Making repoman/metagen check for validity of herds
Am Donnerstag, den 25.02.2010, 19:06 +0100 schrieb Sebastian Pipping: I agree that additional repoman checks can help to improve quality in Gentoo... It seems that currently neither metagen nor repoman check what I put in for herd (i.e. if such a herd exists or not). Does anyone feel like getting his hands on that or like teaming up on it? Since the value for herd is a distinct set of values it could be easily done using a xsd or relax-ng schema plus XIncludes. See http://dev.gentoo.org/~dev-zero/metadata/ for my earlier experiments. -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-dev] metadata.xml: changepolicies
On Thu, Feb 25, 2010 at 12:53 PM, Sebastian Pipping sp...@gentoo.org wrote: Stop. Is introduction of such a high level of bureaucracy really a good idea? In my eyes it could backfire and make matters worse as people either - start ignoring it due to high noise - reduce people's activity below set permissions To summarize presented proposal has a few points that may not work well with humans. To my understanding we have the assumption in Gentoo that a Gentoo dev is at least willing to use his brain most of the time. To me such a machine only makes sense when assuming the opposite(!) You mistake the intent I think. We deploy automation because humans fail; even when they have the best intentions. We make typos, copy and paste errors, accidentally leave whitespace, type commands into the wrong shell, hit the wrong key that kills our session, etc. Smart people avoid work by making a computer do parts that are easily automated; which is why the proposed system is so fine-grained. We can likely add some logic to our current toolset to remind the human that they may have further obligations than just typing repoman commit (like asking on a bug, a mailing list, irc, etc.) With a really simple system; we cannot easily automate when to do what because the criteria are so broad. I agree that a moderately complex system is useless for humans (I'd ignore it straight out) which is why we should write software to do the work for us. I am much more likely to respond to a message from repoman telling me I need to file a bug first as opposed to me looking at metadata.xml every time I commit something. Sure there are people who never read repoman output and commit utter crap to the tree; but I do not really expect 100% success from any system we deploy; I'd be happy with 60% honestly. So I would like to propose a much more loose and simple approach: A distinction - between major and minor changes - need for prior interaction or not A sensible default may differ from developer to developer. I propose collecting these defaults somewhere and make it overridable per maintainer per package in metadata.xml (just as robbat2 did). One question to decide would be if access is allowed iff - no one is objecting or - everyone is acknowledging Once all defaults are collected the options are equal, before they are not. How to best handle herds is not clear to me in detail, yet. Anyone seing potential in this minimalistic with a natural extension on herds in mind? Sebastian
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/samhain: ChangeLog samhain-2.6.2.ebuild
On 02/26/2010 10:49 PM, Patrick Lauer (patrick) wrote:
patrick 10/02/26 20:49:19
Modified: ChangeLog
Added:samhain-2.6.2.ebuild
Log:
Bump
(Portage version: 2.2_rc63/cvs/Linux x86_64)
Index: samhain-2.6.2.ebuild
===
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/app-forensics/samhain/samhain-2.6.2.ebuild,v 1.1
2010/02/26 20:49:18 patrick Exp $
KEYWORDS=~amd64 ~x86
DESCRIPTION=Advanced file integrity and intrusion detection tool.
HOMEPAGE=http://la-samhna.de/samhain/;
SRC_URI=http://la-samhna.de/archive/samhain_signed-${PV}.tar.gz;
LICENSE=GPL-2
SLOT=0
IUSE=crypt debug login-watch mounts-check mysql netclient netserver postgres
prelude static suidcheck userfiles xml
RESTRICT=strip
Why restricting strip on source based package? It's wrong, at least if
it's to supress QA warnings from Portage. It only hides them.
make || die compile failed
}
src_install() {
make DESTDIR=${D} install || die make install failed
Use emake instead of make.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/zzuf: ChangeLog zzuf-0.13.ebuild
On 02/26/2010 10:50 PM, Patrick Lauer (patrick) wrote:
patrick 10/02/26 20:50:29
Modified: ChangeLog
Added:zzuf-0.13.ebuild
Log:
Bump
(Portage version: 2.2_rc63/cvs/Linux x86_64)
1.1 app-forensics/zzuf/zzuf-0.13.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/zzuf/zzuf-0.13.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/zzuf/zzuf-0.13.ebuild?rev=1.1content-type=text/plain
Index: zzuf-0.13.ebuild
===
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/app-forensics/zzuf/zzuf-0.13.ebuild,v 1.1
2010/02/26 20:50:28 patrick Exp $
[ .. ]
src_test() {
if hasq sandbox ${FEATURES}; then
ewarn zzuf tests don't work correctly when sandbox is enabled,
ewarn skipping tests. If you want to run the testsuite, please
ewarn disable sandbox for this build.
return
fi
Testing FEATURES from ebuild? You shouldn't do that.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/samhain: ChangeLog samhain-2.6.2.ebuild
On 02/26/10 22:01, Samuli Suominen wrote:
On 02/26/2010 10:49 PM, Patrick Lauer (patrick) wrote:
patrick 10/02/26 20:49:19
Modified: ChangeLog
Added:samhain-2.6.2.ebuild
Log:
Bump
(Portage version: 2.2_rc63/cvs/Linux x86_64)
Index: samhain-2.6.2.ebuild
===
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/app-forensics/samhain/samhain-2.6.2.ebuild,v 1.1
2010/02/26 20:49:18 patrick Exp $
KEYWORDS=~amd64 ~x86
DESCRIPTION=Advanced file integrity and intrusion detection tool.
HOMEPAGE=http://la-samhna.de/samhain/;
SRC_URI=http://la-samhna.de/archive/samhain_signed-${PV}.tar.gz;
LICENSE=GPL-2
SLOT=0
IUSE=crypt debug login-watch mounts-check mysql netclient netserver
postgres prelude static suidcheck userfiles xml
RESTRICT=strip
Why restricting strip on source based package? It's wrong, at least if
it's to supress QA warnings from Portage. It only hides them.
If that's your largest criticism ... ;)
This ebuild is in a rather sorry state, and no one has found the
motivation to just package.mask it.
Of course you're right, that RESTRICT shouldn't be there (and I have no
idea how that came to happen) - ChangeLog mentions:
02 Jul 2007; Piotr JaroszyC584ski pe...@gentoo.org
samhain-2.1.3.ebuild,
samhain-2.2.0.ebuild:
(QA) RESTRICT clean up.
where this happened:
-RESTRICT=nostrip
+RESTRICT=strip
Impressive. And will be fixed very soonish. I hope. Sigh :)
make || die compile failed
}
src_install() {
make DESTDIR=${D} install || die make install failed
Use emake instead of make.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/zzuf: ChangeLog zzuf-0.13.ebuild
On 02/26/10 22:02, Samuli Suominen wrote:
On 02/26/2010 10:50 PM, Patrick Lauer (patrick) wrote:
src_test() {
if hasq sandbox ${FEATURES}; then
ewarn zzuf tests don't work correctly when sandbox is enabled,
ewarn skipping tests. If you want to run the testsuite, please
ewarn disable sandbox for this build.
return
fi
Testing FEATURES from ebuild? You shouldn't do that.
I disagree. That's a good way not to fail there, unless someone has a
better idea how to make that work.
And I'd appreciate it if PMS would stop refusing to document FEATURES.
(Double negative? I mean: PMS should document reality)
I won't mind if someone fixes that in a way that still has the same
functionality, but I honestly don't see it as a bug, so I'll leave it as
it is.
[gentoo-dev] Marking bugs for bugday?
Hello! I'm surprised that there is no keyword in Gentoo's bugzilla [1] to mark bugs for bugday. Is there a good reason why such a keyword does not exist? Would it be hard to set up? Thanks, Sebastian [1] https://bugs.gentoo.org/describekeywords.cgi
[gentoo-portage-dev] [PATCH] Move regex creation out of PhaseCheck constructor (Revision: 15458)
From a07a07166354e328711d1574eb06f7d357f21907 Mon Sep 17 00:00:00 2001
From: Sebastian Pipping sebast...@pipping.org
Date: Fri, 26 Feb 2010 21:19:06 +0100
Subject: [PATCH] Move regex creation out of PhaseCheck constructor
---
pym/repoman/checks.py | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/pym/repoman/checks.py b/pym/repoman/checks.py
index 27e02d2..02b8d03 100644
--- a/pym/repoman/checks.py
+++ b/pym/repoman/checks.py
@@ -30,21 +30,23 @@ class LineCheck(object):
def end(self):
pass
+
+_ebuild_phases = ('pkg_pretend', 'pkg_setup', 'src_unpack', 'src_prepare',
'src_configure', 'src_compile',
+ 'src_test', 'src_install', 'pkg_preinst',
'pkg_postinst', 'pkg_prerm', 'pkg_postrm', 'pkg_config')
+_phase_re = '(%s)' % '|'.join(_ebuild_phases)
+del _ebuild_phases
+
+
class PhaseCheck(LineCheck):
basic class for function detection
ignore_line = re.compile(r'(^\s*#)')
func_end_re = re.compile(r'^\}$')
+ phases_re = re.compile(_phase_re)
in_phase = ''
def __init__(self):
- self.phases = ('pkg_pretend', 'pkg_setup', 'src_unpack',
'src_prepare', 'src_configure', 'src_compile',
- 'src_test', 'src_install', 'pkg_preinst',
'pkg_postinst', 'pkg_prerm', 'pkg_postrm', 'pkg_config')
- phase_re = '('
- for phase in self.phases:
- phase_re += phase + '|'
- phase_re = phase_re[:-1] + ')'
- self.phases_re = re.compile(phase_re)
+ pass
def check(self, num, line):
m = self.phases_re.match(line)
--
1.6.6
Re: [gentoo-portage-dev] [PATCH] Move regex creation out of PhaseCheck constructor (Revision: 15458)
Thanks, your patch is in svn r15470 (with tweaks by myself). -- Thanks, Zac
[gentoo-portage-dev] Composite exceptions?
Hello! I was wondering how to best handle a case with functions that I would like to collect several exceptions from. Is there an existing standard way to solve this? I was thinking of using the composite pattern for this allowing to throw a tree of exceptions with the option to flatten it for display later. How far off does that sound to you? Sebastian
[gentoo-portage-dev] VCS used for development of portage
Hello! Is moving portage development over to Git planned anytime soon? Anything keeping you from the move? Anything I can do to speed it up? Sebastian
Re: [gentoo-portage-dev] Composite exceptions?
On 02/26/2010 07:11 PM, Sebastian Pipping wrote: Hello! I was wondering how to best handle a case with functions that I would like to collect several exceptions from. Is there an existing standard way to solve this? I was thinking of using the composite pattern for this allowing to throw a tree of exceptions with the option to flatten it for display later. How far off does that sound to you? Do you have an example case where you want to use this? Is this a common practice? Maybe other approaches are better? -- Thanks, Zac
Re: [gentoo-portage-dev] VCS used for development of portage
On 02/26/2010 07:18 PM, Sebastian Pipping wrote: Hello! Is moving portage development over to Git planned anytime soon? Yes, we've been discussing it on this bug: http://bugs.gentoo.org/show_bug.cgi?id=196025 Anything keeping you from the move? Well, the repository layout is somewhat non-trivial, but I think we have a plan that will work. See discussion on bug 196025. Anything I can do to speed it up? Robbin would know better than me. -- Thanks, Zac
Re: [gentoo-portage-dev] Composite exceptions?
On 02/27/10 04:20, Zac Medico wrote: Do you have an example case where you want to use this? Multiple defects in metadata.xml are such a case. At some point all the exceptions will have to collected, e.g. two invalid herds are mentioned. In that case a single exception with a list of invalid herds may suffice but it gets worse when combining errors of slightly different types. Is this a common practice? Maybe other approaches are better? No idea. Sebastian
Re: [gentoo-portage-dev] Composite exceptions?
On Sat, Feb 27, 2010 at 05:02:18AM +0100, Sebastian Pipping wrote: On 02/27/10 04:20, Zac Medico wrote: Do you have an example case where you want to use this? Multiple defects in metadata.xml are such a case. At some point all the exceptions will have to collected, e.g. two invalid herds are mentioned. In that case a single exception with a list of invalid herds may suffice but it gets worse when combining errors of slightly different types. I'd suggest looking at pchecks design instead of trying to do composite exceptions- essentially pass in a reporter that is invoked w/ the failure/'exception' instead passed in. Doing what you're suggesting (catching all exceptions at the top and trying sum them essentially) results in screwy code flow in the specific check- consider a check that can flag multiple issues. Chucking an exception means you get the first warning spotted (and just that). Do the reporter/observer/tweaked visitor approach, you get all of the issues, and it's left to the reporter to decide what to output (and how to format it). Also makes it a helluva lot easier to serialize the results into pickles, or go parallel (multiple processes running, the reporter in the subprocess just serializes the issue to a central process that then amalgamates the results). ~harring pgpoMPmfDsQs1.pgp Description: PGP signature
Re: [gentoo-portage-dev] Composite exceptions?
On 02/26/2010 08:27 PM, Brian Harring wrote: On Sat, Feb 27, 2010 at 05:02:18AM +0100, Sebastian Pipping wrote: On 02/27/10 04:20, Zac Medico wrote: Do you have an example case where you want to use this? Multiple defects in metadata.xml are such a case. At some point all the exceptions will have to collected, e.g. two invalid herds are mentioned. In that case a single exception with a list of invalid herds may suffice but it gets worse when combining errors of slightly different types. I'd suggest looking at pchecks design instead of trying to do composite exceptions- essentially pass in a reporter that is invoked w/ the failure/'exception' instead passed in. Doing what you're suggesting (catching all exceptions at the top and trying sum them essentially) results in screwy code flow in the specific check- consider a check that can flag multiple issues. Chucking an exception means you get the first warning spotted (and just that). Do the reporter/observer/tweaked visitor approach, you get all of the issues, and it's left to the reporter to decide what to output (and how to format it). Good idea. It's similar to the os.walk() 'onerror' argument. -- Thanks, Zac
