Re: [gentoo-dev] Sandbox violation?
On Tuesday, January 11, 2011 20:53:13 Ajai Khattri wrote: > VERSION 1.0 > FORMAT: F - Function called > FORMAT: S - Access Status > FORMAT: P - Path as passed to function > FORMAT: A - Absolute Path (not canonical) > FORMAT: R - Canonical Path > FORMAT: C - Command Line using the legend ... > F: open_wr > S: deny > P: /usr/share/snmp/mibs/.index > A: /usr/share/snmp/mibs/.index > R: /usr/share/snmp/mibs/.index > C: /usr/bin/php-cgi -v -d session.save_path=/tmp ... the program `/usr/bin/php-cgi -v -d session.save_path=/tmp` was executed and it tried to write to the file "/usr/share/snmp/mibs/.index" i imagine if you search bugzilla for that path you'll find that this might be a common issue and not specific to php -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Sandbox violation?
--- ACCESS VIOLATION SUMMARY --- LOG FILE "/var/log/sandbox/sandbox-24173.log" VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /usr/share/snmp/mibs/.index A: /usr/share/snmp/mibs/.index R: /usr/share/snmp/mibs/.index C: /usr/bin/php-cgi -v -d session.save_path=/tmp OK, this is a masked ebuild but what does this actually mean and how can we fix it? -- Ajai Khattri Systems Admin | Web / Mobile Developer
[gentoo-dev] Re: Ebuild- and CPAN-versions compatibility
* Torsten Veller :
> CPAN and ebuild versions are ordered in different ways. The idea here is
> to change the ebuild versions to be predictable and CPAN compatible.
I've committed dev-perl/Gentoo-PerlMod-Version which contains a perl module and
a scipt to convert the versions. gentoo-perlmod-version.pl maps given
perlish versions to ebuild versions (perl => ebuild):
$ gentoo-perlmod-version.pl 0.9 0.98 0.987 v0.{900,980,987} 0.{900,980,987}.0
0.9 => 0.900
0.98 => 0.980
0.987 => 0.987
v0.900 => 0.900
v0.980 => 0.980
v0.987 => 0.987
0.900.0 => 0.900
0.980.0 => 0.980
0.987.0 => 0.987
gentoo-perlmod-version.pl 0.9 0.08 0.007 0.0006 0.5 0.04 0.003
0.9 => 0.900
0.08 => 0.80
0.007 => 0.7
0.0006 => 0.0.600
0.5 => 0.0.50
0.04 => 0.0.4
0.003 => 0.0.0.300
Using version.pm the ebuild and perl versions can be compared:
The ebuild version just needs to be prefixed with a 'v'.
$ perl -wE 'while(@ARGV){say version->parse(shift) <=> version->parse(shift)}'
v1.1 1.001 v1.190 1.19
The given perl distribution version will be recorded as MODULE_VERSION in
the ebuild. (For ease of use s/^MODULE_VERSION=(['"]?)(.+)\1/$2/ should
return the version if not PV.)
Diff of the perl-module.eclass is attached.
The change of versioning will result in ~22 downgrades:
$ find dev-perl -name "*.ebuild" | egrep '\.[1-9][0-9]{3}'
dev-perl/POE-Component-IKC/POE-Component-IKC-0.2200.ebuild
dev-perl/Class-Accessor-Grouped/Class-Accessor-Grouped-0.1.ebuild
dev-perl/IO-Moose/IO-Moose-0.1004.ebuild
dev-perl/DBD-mysql/DBD-mysql-2.9007.ebuild
dev-perl/text-autoformat/text-autoformat-1.669002.ebuild
dev-perl/text-autoformat/text-autoformat-1.669001.ebuild
dev-perl/CPAN-Mini/CPAN-Mini-1.100630.ebuild
dev-perl/Tie-Cache-LRU/Tie-Cache-LRU-20081023.2116.ebuild
dev-perl/DateTime-Format-Strptime/DateTime-Format-Strptime-1.5000.ebuild
dev-perl/DateTime-Format-Strptime/DateTime-Format-Strptime-1.4000.ebuild
dev-perl/Net-Twitter/Net-Twitter-3.14001.ebuild
dev-perl/Net-Twitter/Net-Twitter-3.13009.ebuild
dev-perl/XML-RAI/XML-RAI-1.3031.ebuild
dev-perl/XML-RAI/XML-RAI-1.3022.ebuild
dev-perl/Algorithm-Diff/Algorithm-Diff-1.1902.ebuild
dev-perl/Throwable/Throwable-0.102080.ebuild
dev-perl/Email-Sender/Email-Sender-0.102370.ebuild
dev-perl/Email-Sender/Email-Sender-0.101760.ebuild
dev-perl/Convert-BER/Convert-BER-1.3200.ebuild
dev-perl/Convert-BER/Convert-BER-1.3101.ebuild
dev-perl/Scalar-Properties/Scalar-Properties-1.100860.ebuild
dev-perl/DateTime-Format-Mail/DateTime-Format-Mail-0.3001.ebuild
dev-perl/File-chdir/File-chdir-0.1002.ebuild
dev-perl/File-chdir/File-chdir-0.1003.ebuild
dev-perl/Net-Netmask/Net-Netmask-1.9015.ebuild
dev-perl/PlRPC/PlRPC-0.2020-r1.ebuild
dev-perl/SQL-Translator/SQL-Translator-0.11006.ebuild
dev-perl/SQL-Translator/SQL-Translator-0.11007.ebuild
dev-perl/Perl6-Junction/Perl6-Junction-1.4.ebuild
dev-perl/MP3-Tag/MP3-Tag-0.9709.ebuild
- Die on unsupported EAPI
- Die if PERL_EXPORT_PHASE_FUNCTIONS not yes or no
- Add support for MY_PN, MY_PV, MODULE_VERSION
- Allow use of myconf, mymake, myinst as arrays
- Use Module::Build even if Module::Build is not prefered but no Makefile.PL is
found
--- a/eclass/perl-module.eclass
+++ b/eclass/perl-module.eclass
@@ -34,7 +34,7 @@
esac
;;
*)
- DEPEND="EAPI-UNSUPPORTED"
+ die "EAPI=${EAPI} is not supported by perl-module.eclass"
;;
esac
@@ -46,7 +46,7 @@
debug-print "PERL_EXPORT_PHASE_FUNCTIONS=no"
;;
*)
- DEPEND+=" PERL_EXPORT_PHASE_FUNCTIONS-UNSUPPORTED"
+ die "PERL_EXPORT_PHASE_FUNCTIONS=${PERL_EXPORT_PHASE_FUNCTIONS}
is not supported by perl-module.eclass"
;;
esac
@@ -54,6 +54,10 @@
LICENSE="${LICENSE:-|| ( Artistic GPL-1 GPL-2 GPL-3 )}"
+if [[ -n ${MY_PN} || -n ${MY_PV} || -n ${MODULE_VERSION} ]] ; then
+ : ${MY_P:=${MY_PN:-${PN}}-${MY_PV:-${MODULE_VERSION:-${PV
+ S=${MY_S:-${WORKDIR}/${MY_P}}
+fi
[[ -z "${SRC_URI}" && -z "${MODULE_A}" ]] && MODULE_A="${MY_P:-${P}}.tar.gz"
[[ -z "${SRC_URI}" && -n "${MODULE_AUTHOR}" ]] && \
SRC_URI="mirror://cpan/authors/id/${MODULE_AUTHOR:0:1}/${MODULE_AUTHOR:0:2}/${MODULE_AUTHOR}/${MODULE_SECTION:+${MODULE_SECTION}/}${MODULE_A}"
@@ -97,21 +101,31 @@
# Disable ExtUtils::AutoInstall from prompting
export PERL_EXTUTILS_AUTOINSTALL="--skipdeps"
- if [[ ${PREFER_BUILDPL} == yes && -f Build.PL ]] ; then
+ if [[ $(declare -p myconf 2>&-) != "declare -a myconf="* ]]; then
+ local myconf_local=(${myconf})
+ else
+ local myconf_local=("${myco...@]}")
+ fi
+
+ if [[ ( ${PREFER_BUILDPL} == yes || ! -f Makefile.PL ) && -f Build.PL
]] ; then
einfo "Using Module::Build"
if [[ ${DEPEND} != *virtual/perl-Module-Build* && ${PN} !=
Module-Build ]] ; then
eqawarn "QA Notice: The ebuild uses Module::Build b
Re: [gentoo-dev] mysterious change of system python to python3
On Tue, 11 Jan 2011 20:34:45 +0100, Sebastian Pipping wrote:
On 01/11/11 20:13, Jeremy Olexa wrote:
Both of those threads were on new installs. There was a regression
in
stage building for some time that set python3 as the default system
python. That was fixed here:
5 01 Jan 2011; Jorge Manuel B. S. Vicetto
6 python-2.6.6-r1.ebuild:
7 Non-maintainer commit.
8 Reverting commit that broke stage generation for
python-2.6.6-r1
as it wasn't
9 reverted before - bug 347867.
10 This commit was accepted by Arfrever.
See also, bug 330655. FWIW, I have recently confirmed that there is
expected behavior now in the stage3-amd64-20110106 tarball.
The commit that was reverted was the one breaking the stages (my
fault).
You may be mixing something up.
Jorge's "revert" fixed the overall issue that I mentioned and the
issues that Paweł and Dale are referring to in the very recent
troubleshooting mediums. I may be mixing up some of the bug numbers, but
it is hard to keep track of all the python3/stage3 issues. So, at least
the week of 20101228 stage3's had python3 set as default python and the
week of 20110106 stage3's had python2.6 again, based on my personal
testing.
15:06 <@darkside_> jmbsvicetto: mr releng. :) the 20101228 i{4,6}86
stages have python-3.1 set as the default system python. is this
intended?
15:07 < jmbsvicetto> darkside_: no :\
15:08 < jmbsvicetto> darkside_: and that would explain some of the
recent mails
15:08 < jmbsvicetto> darkside_: I'll do more tests tonight to see if we
can fix that
<... some days elapsed>
13:50 < jmbsvicetto> darkside_: python-2.6.6-r1 hadn't been reverted.
Now that it is, stage3 shouldn't have python-3.1 as default
-Jeremy
Re: [gentoo-dev] mysterious change of system python to python3
On 01/11/11 20:13, Jeremy Olexa wrote: > On Tue, 11 Jan 2011 19:30:03 +0100, Paweł Hajdan, Jr. wrote: >> I've noticed at least two forums threads that suggest there might be a >> bug resulting in automatic "flip" of system python to python3: >> >> http://forums.gentoo.org/viewtopic-t-859654-highlight-.html >> http://forums.gentoo.org/viewtopic-p-6541077.html >> >> Do you think it may be a bug, and if so, how can we debug it? > > Both of those threads were on new installs. There was a regression in > stage building for some time that set python3 as the default system > python. That was fixed here: > > 5 01 Jan 2011; Jorge Manuel B. S. Vicetto > 6 python-2.6.6-r1.ebuild: > 7 Non-maintainer commit. > 8 Reverting commit that broke stage generation for python-2.6.6-r1 > as it wasn't > 9 reverted before - bug 347867. > 10 This commit was accepted by Arfrever. > > See also, bug 330655. FWIW, I have recently confirmed that there is > expected behavior now in the stage3-amd64-20110106 tarball. The commit that was reverted was the one breaking the stages (my fault). You may be mixing something up. Sebastian
Re: [gentoo-dev] mysterious change of system python to python3
"Paweł Hajdan, Jr." wrote: I've noticed at least two forums threads that suggest there might be a bug resulting in automatic "flip" of system python to python3: http://forums.gentoo.org/viewtopic-t-859654-highlight-.html http://forums.gentoo.org/viewtopic-p-6541077.html Do you think it may be a bug, and if so, how can we debug it? I have seen this on the gentoo-user mailing list as well. Dale :-) :-)
Re: [gentoo-dev] mysterious change of system python to python3
On Tue, 11 Jan 2011 19:30:03 +0100, Paweł Hajdan, Jr. wrote: I've noticed at least two forums threads that suggest there might be a bug resulting in automatic "flip" of system python to python3: http://forums.gentoo.org/viewtopic-t-859654-highlight-.html http://forums.gentoo.org/viewtopic-p-6541077.html Do you think it may be a bug, and if so, how can we debug it? Both of those threads were on new installs. There was a regression in stage building for some time that set python3 as the default system python. That was fixed here: 5 01 Jan 2011; Jorge Manuel B. S. Vicetto 6 python-2.6.6-r1.ebuild: 7 Non-maintainer commit. 8 Reverting commit that broke stage generation for python-2.6.6-r1 as it wasn't 9 reverted before - bug 347867. 10 This commit was accepted by Arfrever. See also, bug 330655. FWIW, I have recently confirmed that there is expected behavior now in the stage3-amd64-20110106 tarball. -Jeremy
[gentoo-dev] mysterious change of system python to python3
I've noticed at least two forums threads that suggest there might be a bug resulting in automatic "flip" of system python to python3: http://forums.gentoo.org/viewtopic-t-859654-highlight-.html http://forums.gentoo.org/viewtopic-p-6541077.html Do you think it may be a bug, and if so, how can we debug it? signature.asc Description: OpenPGP digital signature
[gentoo-dev] QA last rites for net-mail/cyrus-imspd
# Diego E. Pettenò (11 Jan 2011) # on behalf of QA team # # Fails to build (but does not die in compile), see bug # #298587. The package fails to build since January 2006. # # Removal on 2011-03-12 net-mail/cyrus-imspd
