Re: noexec on /dev/shm
On Sat, 2010-12-25 at 19:37 +0100, Lennart Poettering wrote: > That basically means that besides systemd itself and maybe the D-Bus > system bus almost nobody can safely use fixed name abstract namespace > sockets. In particular user code that uses fixed name abstract namespace > sockets is necessarily vulnerable to DoS attacks. > > Yes, abstract namespace sockets only have a very limited use. On my desktop, abstract namespace sockets are twice more popular than the regular ones: ber...@giskard:~$ netstat -ax | grep @ | wc -l 151 ber...@giskard:~$ netstat -ax | grep -v @ | grep / | wc -l 73 Most uses are from dbus, but I'm also seeing gnome-session and gvfsd-trash. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-XML-TreeBuilder/f14/master] Add Test::More to build requires
commit 68e05a4be3ac24496ae66843a53d0e0381b9ef83
Author: Ruediger Landmann
Date: Tue Jan 4 09:01:51 2011 +1000
Add Test::More to build requires
.gitignore |1 +
XML-TreeBuilder-NoExpand.patch | 267
perl-XML-TreeBuilder.spec | 24 +++--
sources|2 +-
4 files changed, 17 insertions(+), 277 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8de7776..24fafa6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
XML-TreeBuilder-3.09.tar.gz
+/XML-TreeBuilder-4.0.tar.gz
diff --git a/perl-XML-TreeBuilder.spec b/perl-XML-TreeBuilder.spec
index e9ab5cc..bb58db2 100644
--- a/perl-XML-TreeBuilder.spec
+++ b/perl-XML-TreeBuilder.spec
@@ -1,22 +1,20 @@
Summary: Parser that builds a tree of XML::Element objects
Name: perl-XML-TreeBuilder
-Version: 3.09
-Release: 19%{?dist}
+Version: 4.0
+Release: 3%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/XML-TreeBuilder/
-# have to:
-# push the patch upstream
-Source:
http://www.cpan.org/modules/by-module/XML/XML-TreeBuilder-%{version}.tar.gz
-Patch0:XML-TreeBuilder-NoExpand.patch
+Source:
http://www.cpan.org/modules/by-authors/id/J/JF/JFEARN/XML-TreeBuilder-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(HTML::Element)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(HTML::Element) >= 4.1
BuildRequires: perl(HTML::Tagset)
BuildRequires: perl(XML::Parser)
-Requires: perl(HTML::Element) perl(HTML::Tagset) perl(XML::Parser)
+Requires: perl(HTML::Element) >= 4.1 perl(HTML::Tagset) perl(XML::Parser)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
%description
@@ -25,7 +23,6 @@ that builds a tree of XML::Element objects.
%prep
%setup -q -n XML-TreeBuilder-%{version}
-%patch0 -p1
%build
%{__perl} Makefile.PL INSTALLDIRS="vendor"
@@ -51,6 +48,15 @@ find $RPM_BUILD_ROOT -name .packlist -exec %{__rm} {} \;
%{perl_vendorlib}/XML/
%changelog
+* Tue Jan 4 2011 Rüdiger Landmann - 4.0-3
+- Add Test::More to build requires
+
+* Thu Dec 23 2010 Marcela Maslanova - 4.0-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
+* Thu Dec 02 2010 Jeff Fearn - 4.0-1
+- New upstream
+
* Fri May 07 2010 Marcela Maslanova - 3.09-19
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index a4a6028..79dccc6 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-49e04fb6ba12b1414cb490e7f0c712a9 XML-TreeBuilder-3.09.tar.gz
+b1190367133fbf2807c488c2704588c4 XML-TreeBuilder-4.0.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-TreeBuilder] Add Test::More to build requires
commit 6ddf5f84df7a6a8a71ddcecbad728bc1840a143d
Author: Ruediger Landmann
Date: Tue Jan 4 08:52:25 2011 +1000
Add Test::More to build requires
perl-XML-TreeBuilder.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-XML-TreeBuilder.spec b/perl-XML-TreeBuilder.spec
index f53fd80..bb58db2 100644
--- a/perl-XML-TreeBuilder.spec
+++ b/perl-XML-TreeBuilder.spec
@@ -1,7 +1,7 @@
Summary: Parser that builds a tree of XML::Element objects
Name: perl-XML-TreeBuilder
Version: 4.0
-Release: 2%{?dist}
+Release: 3%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/XML-TreeBuilder/
@@ -10,6 +10,7 @@ BuildRoot:
%{_tmppath}/%{name}-%{version}-%{release}-root%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More)
BuildRequires: perl(HTML::Element) >= 4.1
BuildRequires: perl(HTML::Tagset)
BuildRequires: perl(XML::Parser)
@@ -47,6 +48,9 @@ find $RPM_BUILD_ROOT -name .packlist -exec %{__rm} {} \;
%{perl_vendorlib}/XML/
%changelog
+* Tue Jan 4 2011 Rüdiger Landmann - 4.0-3
+- Add Test::More to build requires
+
* Thu Dec 23 2010 Marcela Maslanova - 4.0-2
- 661697 rebuild for fixing problems with vendorach/lib
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Making CAPS LOCK another CTRL key in the console
On Mon, Jan 3, 2011 at 15:20, Bernie Innocenti wrote: > In Debian & Ubuntu, this can be done by setting XKBOPTIONS=ctrl:nocaps > in /etc/default/console-setup. > > A program called ckbcomp compiles a keymap file which contains this > line: > > keycode 58 = Control Control Control Control Control Control Control Control > Control Control Control Control Control Control Control Control Control > Control Control Control Control Control Control Control Control Control > Control Control Control Control Control Control Control Control Control > Control Control Control Control Control Control Control Control Control > Control Control Control Control Control Control Control Control Control > Control Control Control Control Control Control Control Control Control > Control Control Control Control Control Control Control Control Control > Control Control Control Control Control Control Control Control Control > Control Control Control Control Control Control Control Control Control > Control Control Control Control Control Control Control Control Control > Control Control Control Control Control Control Control Control Control > Control Control Control Control Control Control Control Control Control > Control Control Control Control Control Control > Control Control Control Control Control Control > > (yes, really this redundant :) Several. The gnome utility for keyboard can map Capslock to Control (as god/Sun intended). Or I use the following: #!/bin/sh xmodmap - < So, what's the moral equivalent of this in Fedora? > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- Stephen J Smoogen. "The core skill of innovators is error recovery, not failure avoidance." Randy Nelson, President of Pixar University. "Let us be kind, one to another, for most of us are fighting a hard battle." -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Making CAPS LOCK another CTRL key in the console
In Debian & Ubuntu, this can be done by setting XKBOPTIONS=ctrl:nocaps in /etc/default/console-setup. A program called ckbcomp compiles a keymap file which contains this line: keycode 58 = Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control Control (yes, really this redundant :) So, what's the moral equivalent of this in Fedora? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
PyPy is now available in Fedora
I've imported pypy and built it into rawhide. I've updated the list on: https://fedoraproject.org/wiki/SIGs/Python#Python_Runtimes moving it from "Awaiting review" to "Within Fedora". Enjoy! Dave --- Begin Message --- I've packaged pypy in RPM form for the Fedora distribution [1] - RPM packages are now built in the development branch targeting the next major release (Fedora 15). So it should now be possible for Fedora users to type # yum install pypy and obtain a precompiled /usr/bin/pypy executable via an rpm package, consisting of the JIT-enabled pypy, with all standard settings, without needing to do the full build themselves. I'll do my best to keep these "downstream" packages promptly updated as further "upstream" releases of PyPy occur. Many thanks to everyone who helped with this, especially fijal, for all his great feedback on the packaging review [2] (Caveat: actually, the build won't be available yet via "yum" until a cronjob runs tonight; for now, the build can be downloaded from: http://koji.fedoraproject.org/koji/buildinfo?buildID=212473 ) Some other links, for the curious, can be seen here: https://admin.fedoraproject.org/pkgdb/acls/name/pypy e.g. to the rpm packaging sources. Hope this is helpful Dave [1] http://fedoraproject.org/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=588941 ___ pypy-...@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev --- End Message --- ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: F14 OOo deltarpms not being generated on releng2
On Sat, 4 Dec 2010 15:58:26 -0700 Kevin Fenzi wrote: > On Sat, 04 Dec 2010 20:50:11 +0200 > Jonathan Dieter wrote: > > ...snip... > > > As far as I can see, this only affected the openoffice.org* and > > autocorr* packages in the 101202 push, and the rest of the packages > > in the push had all the proper deltarpms generated. > > > > I'm not sure where to go from here. Any ideas on how to track this > > down? > > FYI, I talked with Jonathan on irc and we added some debugging to the > deltarpms/createrepo code. Hopefully that will show us more where the > issue is so we can solve it. Just an update on this issue. we added in debugging and finally tracked down the issue to a createrepo bug. It was looking for anything ending in 'rpm' when updating from an old repo, but '.drpm' ends that way, so sometimes it was picking up the old drpms instead of the old rpm and failing to generate a new drpm. ;) We have a fixed createrepo installed now, so hopefully from here on out you will get deltas on everything that can generate them. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New contributed package available for review: ax_emergency_listen
On Mon, 2011-01-03 at 20:22 +0100, Guido Trentalancia wrote: > On Tue, 04/01/2011 at 00.45 +0530, Rahul Sundaram wrote: > > On 01/04/2011 12:38 AM, Guido Trentalancia wrote: > > > > > > The package contains a manual page, it supports building using autoconf > > > and automake and it just needs to be reviewed. > > > > > > I think I might need a so-called sponsor before the package can be > > > included in Fedora. > > > > > > I look forward to hearing from you. > > > > I am not a sponsor but the usual method is to file a review request and > > then request for a sponsor. Have you filed one? > > Hi Rahul, > > yes, of course, I have filed a review request. Hi Guido - thanks for doing this. I think what Rahul was wanting was the URL of the review request. For reference, the URL appears to be: https://bugzilla.redhat.com/show_bug.cgi?id=666763 Hope this is helpful Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
openjpeg-1.4, abi break
I plan on importing openjpeg-1.4 into rawhide soonish (say early next week), which involves an abi break. Affected packages that will require rebuilding include: blender blenderplayer freeimage gdcm koffice openslide poppler xpaint -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] MySQL 5.5 coming soon to rawhide
Orcan Ogetbil writes: > On Wed, Dec 22, 2010 at 5:28 PM, Tom Lane wrote: >> For now I'll include a symlink libmysqlclient_r.so -> libmysqlclient.so, >> so that a simple rebuild with no source-code changes should be >> sufficient. Â Eventually we'll probably want to fix the source code to >> not refer to libmysqlclient_r, but that might take awhile if upstreams >> are worried about portability. > With the above change, is it reasonable to assume that the mysql5.5 > package will not be backwards compatible? In other words, if I build > some software against mysql5.5, can't I use it against mysql5.1 ? If you're building it against libmysqlclient_r, yes you'll have an issue, but ISTM you're likely to have other issues anyway if you expect ABI compatibility in that direction. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] MySQL 5.5 coming soon to rawhide
Jon Ciesla writes:
> Tom Lane wrote:
>> I got tired of the amount of visible churn in exported-symbols-you're-
>> not-supposed-to-use. The new release will use a linker --version-script
>> to hide everything except the documented API functions. This might
>> break any apps that are relying on non-API functions. If so, I'm
>> willing to consider on a case-by-case basis whether to add those symbols
>> back to the ABI or fix the callers.
> Is the following a MySQL issue or a Bacula issue?
> /builddir/build/BUILD/bacula-5.0.3/bacula-mysql/src/cats/mysql.c:295:
> undefined reference to `my_thread_end'
Well, it's certainly a byproduct of that change. So far as I can find,
mysql_thread_end is a documented part of the API and my_thread_end is
not. Is there a good reason for Bacula to be calling the latter?
A quick look into the mysql sources finds
void STDCALL mysql_thread_end()
{
#ifdef THREAD
my_thread_end();
#endif
}
which makes it look like the correct answer is "no" ...
regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] MySQL 5.5 coming soon to rawhide
On Wed, Dec 22, 2010 at 5:28 PM, Tom Lane wrote: > For now I'll include a symlink libmysqlclient_r.so -> libmysqlclient.so, > so that a simple rebuild with no source-code changes should be > sufficient. Eventually we'll probably want to fix the source code to > not refer to libmysqlclient_r, but that might take awhile if upstreams > are worried about portability. > Hi Tom, With the above change, is it reasonable to assume that the mysql5.5 package will not be backwards compatible? In other words, if I build some software against mysql5.5, can't I use it against mysql5.1 ? Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Mon, 03.01.11 09:54, Chris Adams (cmad...@hiwaay.net) wrote: > > Once upon a time, Adam Jackson said: > > Sadly this turns out not to be the case, at least if I'm reading > > fs/pipe.c correctly. O_NOATIME will turn off atime updates, but mtime > > and ctime are still modified on every pipe write, and there's no such > > thing as O_NOCMTIME even though the filesystem layer does have the > > concept internally. Which means device-backed filesystems will see > > write traffic just for using named pipes. > > > > Heck of lame. Someone should fix that. > > The behavior follows the standard, so it shouldn't just be changed by > default without checking if anybody uses the standard behavior. Well, I think introducing O_NOCTIME the same way O_NOATIME was introduced would be unproblematic: only if it is set the normal ctime behaviour would be disabled. But yeah, I agree with ajax, the fact that the ctime of a fifo is updated all the time and there is no way around it is kinda ridiculous... And it gives the jack folks a really good reason not to stick a fifo into /tmp. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] MySQL 5.5 coming soon to rawhide
Tom Lane wrote: > Since MySQL AB^W^WSun^WOracle has now declared the mysql 5.5.x release > series to be GA status, I'm planning to push it into rawhide shortly to > replace the 5.1.x series. Theoretically, this will go pretty smoothly. > > I'm aware of a couple of ABI-level issues: > > 1. libmysqlclient.so, which is linked into all manner of stuff, is > supposed to be ABI-compatible with the previous releases. However, > I got tired of the amount of visible churn in exported-symbols-you're- > not-supposed-to-use. The new release will use a linker --version-script > to hide everything except the documented API functions. This might > break any apps that are relying on non-API functions. If so, I'm > willing to consider on a case-by-case basis whether to add those symbols > back to the ABI or fix the callers. > > 2. libmysqlclient_r.so is gone altogether; there's no need for it since > the regular libmysqlclient.so library is supposed to be thread safe. > AFAIK this will require rebuilding only the following packages: > > mysql++ > mysql-connector-c++ > nekovm > qt-mysql > > For now I'll include a symlink libmysqlclient_r.so -> libmysqlclient.so, > so that a simple rebuild with no source-code changes should be > sufficient. Eventually we'll probably want to fix the source code to > not refer to libmysqlclient_r, but that might take awhile if upstreams > are worried about portability. > > > There are also some SQL-level incompatibilities called out here: > http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html > I'm not sure to what extent these may affect Fedora applications, > but it seems like the easiest way to find out is to try them. > > Any objections? Anything people think should be tested before pushing? > > regards, tom lane > Is the following a MySQL issue or a Bacula issue? /builddir/build/BUILD/bacula-5.0.3/bacula-mysql/src/cats/mysql.c:295: undefined reference to `my_thread_end' http://koji.fedoraproject.org/koji/getfile?taskID=2699251&name=build.log J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Non-responsive maintainer: pysvn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've been trying to contact the maintainer of pysvn for a few weeks (Since December 14th) but have not received a reply. According to Koji, the owner (ravenoak) has not been active since July. I'd like to formally request being added as a comaintainer of this package, as it is a broken dependency in EPEL 6 for one of the packages I maintain (ReviewBoard). I am also willing to assume comaintainership in Fedora. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0iJbwACgkQeiVVYja6o6O2TQCgqcQP7Nxk63xd88wbCBIa4M6a TmYAoIDWaUYlynvgcFy42PyeookyONDU =4Jk1 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New contributed package available for review: ax_emergency_listen
On Tue, 04/01/2011 at 00.45 +0530, Rahul Sundaram wrote: > On 01/04/2011 12:38 AM, Guido Trentalancia wrote: > > > > The package contains a manual page, it supports building using autoconf > > and automake and it just needs to be reviewed. > > > > I think I might need a so-called sponsor before the package can be > > included in Fedora. > > > > I look forward to hearing from you. > > I am not a sponsor but the usual method is to file a review request and > then request for a sponsor. Have you filed one? Hi Rahul, yes, of course, I have filed a review request. > Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New contributed package available for review: ax_emergency_listen
On 01/04/2011 12:38 AM, Guido Trentalancia wrote: > > The package contains a manual page, it supports building using autoconf > and automake and it just needs to be reviewed. > > I think I might need a so-called sponsor before the package can be > included in Fedora. > > I look forward to hearing from you. I am not a sponsor but the usual method is to file a review request and then request for a sponsor. Have you filed one? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New contributed package available for review: ax_emergency_listen
Hello everybody, I would like to contribute a small package that I wrote for inclusion in the Fedora distribution. It falls under Applications/Communications and it is a small utility which can be used to monitor for emergency packets in an APRS network. APRS (Automatic Packet Reporting System) is an amateur radio based digital communication system for real-time exchange of digital information to users on the network. The name of the package is ax_emergency_listen and I have made available version 1.3.2. It is a command-line utility and it can execute commands upon receiving emergency packets on APRS (so, for example, it can send out email or SMS alerts). The package contains a manual page, it supports building using autoconf and automake and it just needs to be reviewed. I think I might need a so-called sponsor before the package can be included in Fedora. I look forward to hearing from you. Kind regards, Guido Trentalancia -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld - A firewall daemon with D-BUS interface providing a dynamic firewall (test version)
On Thu, 2010-12-23 at 17:03 +0100, Thomas Woerner wrote: > Hello, > > as discussed some time ago, I worked on the proof of concept > implementation of firewalld. FirewallD is a service daemon with a D-BUS > interface that provides a dynamic managed firewall. > > For more information on firewalld, please have a look at: > https://fedoraproject.org/wiki/FirewallD/ > (dropping CCs) I can't comment much on firewalls per se, but I just wanted to say that it's exciting to see a plan on the Fedora wiki that covers Fedora 15, 16, 17 and 18. I don't think we do enough long-term planning, and I found it refreshing to see this kind of thing. Just my 2c; good luck! Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd and svn problems (rawhide)
On Mon, Jan 3, 2011 at 08:53, Paul F. Johnson wrote: > > > First is httpd (apache). > > I can do /etc/init.d/httpd stop and the server stops, but when I try to > start the server I get > > Starting httpd (via systemctl): Job failed. See system logs and > 'systemctl status' for details. > > systemctl status httpd.service shows > > httpd.service - LSB: start and stop Apache HTTP Server > Loaded: loaded (/etc/rc.d/init.d/httpd) > Active: failed since Mon, 03 Jan 2011 16:39:18 +; 33s ago > Process: 3902 (/etc/rc.d/init.d/httpd stop, code=exited, > status=0/SUCCESS) > Process: 1959 (/etc/rc.d/init.d/httpd start, code=exited, > status=1/FAILURE) >Main PID: 2054 (code=exited, status=1/FAILURE) > CGroup: name=systemd:/system/httpd.service > └ 2086 /usr/sbin/httpd > > cat /var/log/messages | tail is also unhelpful > > Jan 3 16:41:34 PB3 systemd[1]: httpd.service: control process exited, > code=exited status=1 > Jan 3 16:41:34 PB3 systemd[1]: Unit httpd.service entered failed state. > > The stop command leaves one httpd process running. Kill it off first. httpd fails to start because it is trying to create a file in /var/run/httpd but the directory doesn't exist. As a temporary workaround I've been 1) stop httpd 2) kill the last remaining httpd 3) create /var/run/httpd 4) start http There is a outstanding bug that Lennart created. I also expect that the script will be converted sometime to work natively with systemd. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
httpd and svn problems (rawhide)
Hi, I have two problems which I can't seem to get to the bottom of, both of them are very annoying and I don't know if it's me or the software so would rather check things before putting stuff into the big red lizard. First is httpd (apache). I can do /etc/init.d/httpd stop and the server stops, but when I try to start the server I get Starting httpd (via systemctl): Job failed. See system logs and 'systemctl status' for details. systemctl status httpd.service shows httpd.service - LSB: start and stop Apache HTTP Server Loaded: loaded (/etc/rc.d/init.d/httpd) Active: failed since Mon, 03 Jan 2011 16:39:18 +; 33s ago Process: 3902 (/etc/rc.d/init.d/httpd stop, code=exited, status=0/SUCCESS) Process: 1959 (/etc/rc.d/init.d/httpd start, code=exited, status=1/FAILURE) Main PID: 2054 (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/httpd.service └ 2086 /usr/sbin/httpd cat /var/log/messages | tail is also unhelpful Jan 3 16:41:34 PB3 systemd[1]: httpd.service: control process exited, code=exited status=1 Jan 3 16:41:34 PB3 systemd[1]: Unit httpd.service entered failed state. /var/log/httpd/error_log is showing nothing at all I've also attempted to set up an svn server using the instructions at http://queens.db.toronto.edu/~nilesh/linux/subversion-howto/ using instruction 2. However, when I try to start svnserve I get svnserve -r /svn -d svnserve: Can't bind server socket: Address already in use netstat is showing nothing is binding to the svn port. I've thought it could be an selinux problem, but as I'm running permissive, nothing is being reported back. Any help on either of these would be appreciated :) Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package-specific test case and critical path test case project: drafts for review
On Thu, 2010-12-23 at 14:35 +, Adam Williamson wrote: > On Tue, 2010-12-21 at 17:11 +, Adam Williamson wrote: > > Hi, everyone. So, in the recent debate about the update process it again > > became clear that we were lacking a good process for providing > > package-specific test instructions, and particularly specific > > instructions for testing critical path functions. > > > > I've been working on a process for this, and now have two draft Wiki > > pages up for review which together describe it: > > > > https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_test_case_creation > > https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_package_test_plan_creation > > I've now converted one package's set of test cases to the proposed new > system to serve as an illustration. I used the Radeon driver, > xorg-x11-drv-ati . This was a good example as there's a lot of them, and > they split neatly into critpath, core and extended to illustrate the > optional advanced categorization system. > > So, see: > > https://fedoraproject.org/wiki/Category:Package_xorg-x11-drv-ati_test_cases > > and note that one of the test cases is also in: > > https://fedoraproject.org/wiki/Category:Critical_path_test_cases Nice examples, this really helps to visualize the proposed changes. So if I were acting as f-e-k or bodhi, I would combine the two lists of cases to show the xorg-x11-drv-ati critpath tests... * QA:Testcase radeon basic Did I do that correctly? > you can also see at https://fedoraproject.org/wiki/Category:Test_Cases > how this tracks back to that overall category - no test cases are in it > directly, it's all hierarchical. > [[Category:Test_Cases|X]] I did a minor tweak so that it would show up under 'X' (for xorg-x11...) rather than 'P' (for Package_xorg-x11...). > thanks! I'm planning to work on a mockup for the f-e-k and bodhi > integration this afternoon to show how we envision this all being used > to kick ass, I think that'll make it clearer. Thanks, James signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
Once upon a time, Adam Jackson said: > Sadly this turns out not to be the case, at least if I'm reading > fs/pipe.c correctly. O_NOATIME will turn off atime updates, but mtime > and ctime are still modified on every pipe write, and there's no such > thing as O_NOCMTIME even though the filesystem layer does have the > concept internally. Which means device-backed filesystems will see > write traffic just for using named pipes. > > Heck of lame. Someone should fix that. The behavior follows the standard, so it shouldn't just be changed by default without checking if anybody uses the standard behavior. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package-specific test case and critical path test case project: drafts for review
On Wed, 2010-12-22 at 17:29 +, Adam Williamson wrote:
> On Tue, 2010-12-21 at 18:12 -0500, James Laska wrote:
>
> > > the first isn't particularly specific to this, but it was a prerequisite
> > > that I discovered was missing: it's a guide to test case creation in
> > > general, explaining the actual practical process of how you create a
> > > test case, and the best principles to consider in doing it.
> >
> > Nice job here, this is something that's difficult to explain if you've
> > done it a lot, but I think you've captured the key points. If possible,
> > it might be helpful to highlight a few existing examples that stand out
> > for the different characteristics you mention (comprehensive, but able
> > to stand the test of time).
>
> Thanks. I'll see if I can find some and add them.
>
> > Another thought, any reason that we wouldn't want to keep all wiki tests
> > in the QA: namespace (and with the prefix QA:Testcase_)? The door is
> > left open for other names, I wonder if we want to cut that off ahead of
> > time to keep our sanity by having all tests in the same namespace?
>
> I was a bit unsure on that one. I think I thought of some possible
> scenario where you might want to write a test case in a different name
> space, but I'm not entirely sure I remember what it was. I can just
> change it to say test cases should always go in the qa namespace, I
> guess.
>
> > The page also talks about using [[Category:Test_Cases]]. I worry if we
> > are too lax in categorizing new tests we'll end up with a large amount
> > of random tests in the main [[Category:Test_Cases]] making it a
> > maintenance nightmare to cleanup that category. Should we instead
> > direct users to your other page
> > (https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_package_test_plan_creation)
> > for guidance on categorizing test cases?
>
> This was something I wanted to call out for discussion and forgot - so
> far we've put all test cases directly into the Test_Cases category, but
> like you, I'm worried that really won't scale. I did wonder whether
> others would agree we should stop doing that and instead have them
> usually go into a more specific category which in turn would be a
> sub-category of Test_Cases, and only have test cases be members of
> Test_Cases directly if it really made no sense to have them in a more
> specific category.
Agreed ... I think it makes sense to keep Category:Test_Cases as just a
container for sub-categories if possible. Mainly for the reasons you
note around *trying* to keep content organized.
> > > The second is what's really specific to this subject. It describes how
> > > to create a set of test cases for a particular package, and a proposed
> > > standardized categorization scheme which will allow us to denote test
> > > cases as being associated with specific packages, and also denote them
> > > as concerning critical path functionality.
> >
> > I think I mentioned this previously, in the section 'Preparation', I
> > appreciate the distinction of 'core' and 'extended'. But I it resonates
> > with me better under the context of test "priority". I don't see why we
> > can't keep using the terms 'core' and 'extended', but just want to
> > clarify their purpose. They're intended to add some sense of execution
> > priority to a list of test cases, right? Where critpath comes first,
> > then core, then extended, then other? Also, you describe
> > categorizing/grouping test cases in more detail below, maybe just link
> > to that instead?
Was I accurate in my understanding above of your proposed groupings
(critpath, core and extended)? Are they intended to convey an execution
priority of the tests?
> well, the idea is that the two are complementary: if you're going to
> separate the test cases into 'core' and 'extended' groups, then why not
> identify which functionality is 'core' and which is 'extended' at the
> time you're identifying functionality to write test cases for? I'm not
> quite sure what your proposal is here - could you draft it up in terms
> of an actual change to the page so I can see it more clearly? thanks!
I articulated several layouts in previous comments in the ticket. See
https://fedorahosted.org/fedora-qa/ticket/154#comment:12 and
https://fedorahosted.org/fedora-qa/ticket/154#comment:18.
I guess I'm hesitant about introducing new terminology ("core" and
"extended") when I'm more familiar with prioritizing test cases using
the term "priority". I'm not saying we shouldn't use them, I'm just
trying to understand the context. I'm also trying to ensure your
project ties in nicely with the work Hurry is doing with regards to
scoping out a TCMS (http://fedorahosted.org/fedora-qa/ticket/152). My
question (I guess I already re-stated above) was whether you consider
the terms "core" and "extended" as a designation of test case priority?
Outside of the terminology, I have some concerns whether this is within
the scope of the initial project,
Re: noexec on /dev/shm
On Thu, 2010-12-23 at 22:59 +0100, Lennart Poettering wrote: > On Mon, 20.12.10 19:16, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) > wrote: > > > this isn't exactly correct. > > > > in /dev/shm on linux we have: > > > > (a) unix-domain sockets for non-RT communication with the server > > (b) FIFOs for RT wakeups (this could use semaphores now) > > If this uses O_NOATIME it shouldnt matter whether the backing fs is > tmpfs or real disk. Sadly this turns out not to be the case, at least if I'm reading fs/pipe.c correctly. O_NOATIME will turn off atime updates, but mtime and ctime are still modified on every pipe write, and there's no such thing as O_NOCMTIME even though the filesystem layer does have the concept internally. Which means device-backed filesystems will see write traffic just for using named pipes. Heck of lame. Someone should fix that. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: want to contribute to fedora project
Hello. http://fedoraproject.org/en/join-fedora 03.01.2011 02:34, rohit bishnoi wrote: > i m rohit bishnoi from india. i have knowledge of c, c++ and java > languages. i want to contribute to fedora. > plz help me how can i help fedora project.. > thnks in advance > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110103 changes
Compose started at Mon Jan 3 08:15:06 UTC 2011 Broken deps for x86_64 -- apvlv-0.0.9.8-1.fc15.x86_64 requires libpoppler.so.9()(64bit) bacula-director-mysql-5.0.3-6.fc15.x86_64 requires libmysqlclient_r.so.16()(64bit) bacula-director-mysql-5.0.3-6.fc15.x86_64 requires libmysqlclient_r.so.16(libmysqlclient_16)(64bit) bacula-storage-mysql-5.0.3-6.fc15.x86_64 requires libmysqlclient_r.so.16()(64bit) bacula-storage-mysql-5.0.3-6.fc15.x86_64 requires libmysqlclient_r.so.16(libmysqlclient_16)(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) beagle-0.3.9-19.fc14.x86_64 requires libwv-1.2.so.3()(64bit) calibre-0.7.36-1.fc15.x86_64 requires libpoppler.so.11()(64bit) chess-1.0-30.fc14.x86_64 requires libOgreMain-1.6.4.so()(64bit) chess-1.0-30.fc14.x86_64 requires libCEGUIOgreRenderer-1.6.4.so()(64bit) cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit) darktable-0.7.1-1.fc15.x86_64 requires libexiv2.so.9()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-2.fc15.noarch requires debhelper ember-0.5.6-5.fc13.x86_64 requires libOgreMain-1.6.4.so()(64bit) ember-0.5.6-5.fc13.x86_64 requires libCEGUIOgreRenderer-1.6.4.so()(64bit) eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) gedit-vala-0.10.2-2.fc15.i686 requires libvala-0.10.so.0 gedit-vala-0.10.2-2.fc15.x86_64 requires libvala-0.10.so.0()(64bit) 1:gnome-bluetooth-moblin-2.91.2-1.fc15.x86_64 requires libmoblin-panel.so.0()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-gmail-notifier-0.10.1-1.fc14.x86_64 requires libnotify.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gnotime-2.3.0-7.fc14.x86_64 requires libgtkhtml-3.14.so.19()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) gshutdown-0.2-6.fc12.x86_64 requires libnotify.so.1()(64bit) gsql-0.2.1-4.fc12.i686 requires libnotify.so.1 gsql-0.2.1-4.fc12.x86_64 requires libnotify.so.1()(64bit) gsql-engine-mysql-0.2.1-4.fc12.x86_64 requires libmysqlclient_r.so.16()(64bit) gsql-engine-mysql-0.2.1-4.fc12.x86_64 requires libmysqlclient_r.so.16(libmysqlclient_16)(64bit) gyachi-plugin-libnotify-1.2.10-3.fc14.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) ibus-fbterm-0.9.1-10.fc15.x86_64 requires libibus.so.2()(64bit) intellij-idea-9.0.1.94.399-12.fc15.x86_64 requires commons-collections java-gnome-4.0.16-3.fc14.x86_64 requires libnotify.so.1()(64bit) kphotoalbum-4.1.1-7.fc15.x86_64 requires libexiv2.so.9()(64bit) libnotifymm-0.6.1-8.fc14.i686 requires libnotify.so.1 libnotifymm-0.6.1-8.fc14.x86_64 requires libnotify.so.1()(64bit) libreoffice-pdfimport-3.3.0.2-2.fc15.x86_64 requires libpoppler.so.11()(64bit) log4net-1.2.10-13.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Data) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Web) = 0:1.0.5000.0 1:logjam-4.6.0-1.fc15.x86_64 requires libgtkhtml-3.14.so.19()(64bit) merkaartor-0.17-0.3.rc5.fc15.x86_64 requires libexiv2.so.9()(64bit) meshmagick-0.6.0-1.20090529svn2698.fc13.x86_64 requires libOgreMain-1.6.4.so()(64bit) meshmagick-libs-0.6.0-1.20090529svn2698.fc13.i686 requires libOgreMain-1.6.4.so meshmagick-libs-0.6.0-1.20090529svn2698.fc13.x86_64 requires libOgreMain-1.6.4.so()(64bit) moblin-panel-media-0.0.8-0.2.fc13.x86_64 requires libmoblin-panel.so.0()(64bit) mono-ndoc-1.3.1-8.fc13.x86_6
want to contribute to fedora project
i m rohit bishnoi from india. i have knowledge of c, c++ and java languages. i want to contribute to fedora. plz help me how can i help fedora project.. thnks in advance -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
