Re: mysql is now a critpath package? WTF?
On Thu, 05 Jan 2012 14:38:57 -0600 Rex Dieter wrote: > Stijn Hoop wrote: > > > Well it also took them two years to consider 'NFS mounted home' a > > valid use case, during which the whole 'you really need MySQL!!!' > > was broken for our site. > > It's easy to switch (maybe I should blog about it... ) > > per user: kcmshell4 akonadi > > per machine/site: create/edit /etc/xdg/akonadi/akonadiserverrc to > contain: [%General] > Driver=QSQLITE3 > > -- rex > Thank you, that is good to know. In the end we worked around it by moving the MySQL socket to a local directory. This was not perfect because accidentally starting KMail on a second machine, while logged in on the first, caused havoc in fun ways, but it did get rid of the occasional "I've lost my mail" NFS+MySQL fun. --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
2012-01-05 20:20 keltezéssel, Kevin Kofler írta: > Rex Dieter wrote: >> I'm of a mind to revisit this (again). > NO, not again!!! > > Can we please stop this nonsense? > > Upstream defaults to MySQL for a reason, and strongly recommends NOT using > the SQLite backend by default. SQLite doesn't support concurrency (i.e. any > Akonadi operation blocks all others) and is slower. Then switch to using PostgreSQL as the database backend. It's secure by default (e.g. only allows localhost connections) and has better concurrency than MySQL. It's also Tom Lane's territory and I like it better too. :-) > I think overriding the upstream default is a very bad idea in this case, and > I'm surprised you are pushing for it that much, you're otherwise always the > "upstream, upstream, upstream" guy. > > Kevin Kofler > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps
Hi, On 01/05/2012 04:31 PM, Brendan Jones wrote: On 12/15/2011 07:14 PM, Brendan Jones wrote: I would like to swap reviews for the following. All are very tiny so feel free to swap 2 for one. Listed in descending priority: https://bugzilla.redhat.com/show_bug.cgi?id=760270 lv2-ams-plugins - LV2 port of the Alsa Modular Synth modules https://bugzilla.redhat.com/show_bug.cgi?id=766154 lv2-kn0ck0ut - An LV2 spectral subtraction plugin (linux audio) https://bugzilla.redhat.com/show_bug.cgi?id=754004 lv2-abGate - an LV2 Noise Gate plugin I will be able to commence reviews from next Wednesday, unless anyone anyone responds this evening. Thanks! Brendan I've knocked one of my list but the 3 above are still outstanding. lv2 plugins are REALLY easy to review. 2 for one offer still stands, and have others ready to package. I would like to do a review swap with you. But the package I want you to review is not ready for review yet... I've recently gotten an ebook reader and sometimes it is useful to edit ebooks a bit to fix them up. For this I would like to see the ebook editor sigil: http://code.google.com/p/sigil/ Packaged. I found someone has already done Fedora packages in his own personal repo (which dropped of the net shortly after because of hardware issues) and contacted him if he wanted to maintain it as an official Fedora package. Unfortunately he has no time for that. But I luckily did save his srpms before his box died. So I plan to clean them up a bit and submit them for review soon-ish. So if you're willing to review sigil when I submit it, I'll gladly review one of your lv2 plugin submissions. No need to do 2 for 1. sigil is not entirely trivial, so that wouldn't be fair :) Let me know which one you want me to review. Regards, Hans p.s. I also maintain a whole bunch of ladspa plugins myself, I don't really use these, but once upon a time when I had more spare time I wanted to try to get as much as possible of planet ccrma into Fedora proper, so that is who I got to own these, you're welcome to co-maintain these if you want :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: qt accessibility, anyone interested?
Rex, count with me, even I'm probably not the right person too but I think it's the must to have it and properly maintained. R. - Original Message - > Being the avid package monkey I am, I whipped up some initial > packaging for > http://gitorious.org/qt-at-spi/ in my space at > http://rdieter.fedorapeople.org/rpms/qt-at-spi/ > > Hoping someone with more interest in this area would be able to pick > this up > to maintain officially. Be happy to help with sponsoring or reviews > if > required. > > In the end, I may end up doing it myself, but would rather this find > a > happier home that could care for it more than I would or could. > > -- rex > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using a macro in ExclusiveArch
On 2012-01-05, Björn Persson wrote: > The simplest solution seems to be to let SIG members co-maintain > redhat-rpm-config. Did you have some more elaborate solution in mind? > My idea is to let SIGs to maintain their specific standalone packages injecting files into /etc/rpm and to ask redhat-rpm-config owner to require the SIG-maintaned packages. This would allow SIGs to tune build-root macros without disturbing redhat-rpm-config. On the other hand it would weaken surveillance over the changes. There is also processing advantage---each SIG has different policy who is core SIG developer (usually co-maintainers of the main intrepreter/compiler). My solution does not hassle redhat-rpm-config with these problems. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Graph-Easy-0.71.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Graph-Easy: e0ff999694110fda648d8b19a2da53df Graph-Easy-0.71.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
Re: Review swaps
Am Donnerstag, 5. Januar 2012, 16:31:49 schrieb Brendan Jones: > On 12/15/2011 07:14 PM, Brendan Jones wrote: > > I would like to swap reviews for the following. All are very tiny so > > feel free to swap 2 for one. Listed in descending priority: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=760270 > > lv2-ams-plugins - LV2 port of the Alsa Modular Synth modules > > > > https://bugzilla.redhat.com/show_bug.cgi?id=766154 > > lv2-kn0ck0ut - An LV2 spectral subtraction plugin (linux audio) > > > > https://bugzilla.redhat.com/show_bug.cgi?id=754004 > > lv2-abGate - an LV2 Noise Gate plugin > > > > I will be able to commence reviews from next Wednesday, unless anyone > > anyone responds this evening. > > > > Thanks! > > > > Brendan > > I've knocked one of my list but the 3 above are still outstanding. lv2 > plugins are REALLY easy to review. 2 for one offer still stands, and > have others ready to package. > > Brendan (bsjones) Hey, Do you want to review https://bugzilla.redhat.com/show_bug.cgi?id=734531 ? Shouldn't be too hard. I can take 2 of yours, if you want. Greg -- If it's working, the diagnostics say it's fine. If it's not working, the diagnostics say it's fine. - A proposed addition to rules for realtime programming 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: Review swaps
On 01/06/2012 10:15 AM, Hans de Goede wrote: https://bugzilla.redhat.com/show_bug.cgi?id=760270 lv2-ams-plugins - LV2 port of the Alsa Modular Synth modules Hans if you could take the lv2-ams-plugins that would be great! I will eagerly await yours ... As for the ladspa plugins, sure, happy to co-maintain, but looking forward to the time when we can obsolete all of them. There are also some exciting LV2 ports and plugins coming soon too... Eventually I would like to include the whole lv2 framework into Fedora properly. At the moment we are only using lv2core, but there are many other libraries which need packaging. My to do list is quite huge!! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
OCaml 3.12.1 (was 3.12.0) in Rawhide
http://caml.inria.fr/ocaml/release.en.html 3.12.1 is a simple bugfix update to the compiler. I'm expecting this may cause some broken dependencies. I intend to fix these as they come up over the next few days, and make sure that all OCaml packages are at the latest upstream versions at the same time. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Gtk3/f16] (2 commits) ...Add BR for ExtUtils::Install
Summary of changes: 16a9d13... Initial import after review (rhbz #754754) (*) d37899b... Add BR for ExtUtils::Install (*) (*) This commit already existed in another branch; no separate mail sent -- 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: Review swaps
On 01/06/2012 12:33 PM, Gregor Tätzner wrote: Am Donnerstag, 5. Januar 2012, 16:31:49 schrieb Brendan Jones: On 12/15/2011 07:14 PM, Brendan Jones wrote: I would like to swap reviews for the following. All are very tiny so feel free to swap 2 for one. Listed in descending priority: https://bugzilla.redhat.com/show_bug.cgi?id=760270 lv2-ams-plugins - LV2 port of the Alsa Modular Synth modules https://bugzilla.redhat.com/show_bug.cgi?id=766154 lv2-kn0ck0ut - An LV2 spectral subtraction plugin (linux audio) https://bugzilla.redhat.com/show_bug.cgi?id=754004 lv2-abGate - an LV2 Noise Gate plugin I will be able to commence reviews from next Wednesday, unless anyone anyone responds this evening. Thanks! Brendan I've knocked one of my list but the 3 above are still outstanding. lv2 plugins are REALLY easy to review. 2 for one offer still stands, and have others ready to package. Brendan (bsjones) Hey, Do you want to review https://bugzilla.redhat.com/show_bug.cgi?id=734531 ? Shouldn't be too hard. I can take 2 of yours, if you want. Greg Thanks Greg, Hans has the first one so if you could take lv2-kn0ck0ut and lv2-abGate that would be fantastic. As I said, really simple and should only take you about 5 minutes each. I should have yours done by the end of the weekend if not earlier. Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Zoltan Boszormenyi wrote: > Then switch to using PostgreSQL as the database backend. > It's secure by default (e.g. only allows localhost connections) and > has better concurrency than MySQL. It's also Tom Lane's territory > and I like it better too. :-) PostgreSQL requires manual intervention at each upgrade (dump BEFORE you upgrade, restore afterwards) and is not automatically integrated into Akonadi the way MySQL is (you have to set up a server manually and configure Akonadi for it). And Akonadi automatically configures its MySQL instances to only allow local connections from the specific user. (It sets it up to only listen on a Unix socket with permissions only for the user owning the instance.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 771781] Numerous Use of qw(...) as parentheses is deprecated messages
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=771781 --- Comment #2 from Miloslav Trmač 2012-01-06 09:32:48 EST --- Created attachment 551153 --> https://bugzilla.redhat.com/attachment.cgi?id=551153 Untested! patch -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: mysql is now a critpath package? WTF?
Kevin Kofler wrote: PostgreSQL requires manual intervention at each upgrade (dump BEFORE you upgrade, restore afterwards) As of PostgreSQL 9.0, there is an upgrade utility[1] that doesn't require a dump/restore. I have used it to go from 8.4 to 9.0 and now 9.0 to 9.1 without an issue. [1] http://www.postgresql.org/docs/9.1/static/pgupgrade.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Moo-0.009013.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Moo: 80ec444a3d274abe66b37ea4e5006ab9 Moo-0.009013.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-Moo] update to 0.009013
commit 21d666541be57b16d95d0241325283775a2570da
Author: Iain Arnell
Date: Fri Jan 6 16:31:42 2012 +0100
update to 0.009013
.gitignore|1 +
perl-Moo.spec | 11 +++
sources |2 +-
3 files changed, 9 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index c5c44ea..b7326f8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/Moo-0.009010.tar.gz
/Moo-0.009011.tar.gz
/Moo-0.009012.tar.gz
+/Moo-0.009013.tar.gz
diff --git a/perl-Moo.spec b/perl-Moo.spec
index c9f3980..d6de831 100644
--- a/perl-Moo.spec
+++ b/perl-Moo.spec
@@ -1,18 +1,18 @@
Name: perl-Moo
-Version:0.009012
+Version:0.009013
Release:1%{?dist}
Summary:Minimalist Object Orientation (with Moose compatibility)
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Moo/
-Source0:
http://www.cpan.org/authors/id/M/MS/MSTROUT/Moo-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/R/RI/RIBASUSHI/Moo-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(Class::Method::Modifiers) >= 1.05
+BuildRequires: perl(Class::Method::Modifiers) >= 1.07
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(strictures) >= 1.001001
BuildRequires: perl(Test::Fatal) >= 0.003
BuildRequires: perl(Test::More) >= 0.96
-Requires: perl(Class::Method::Modifiers) >= 1.05
+Requires: perl(Class::Method::Modifiers) >= 1.07
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
%{?perl_default_filter}
@@ -49,6 +49,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Jan 06 2012 Iain Arnell 0.009013-1
+- update to latest upstream version
+
* Sun Nov 20 2011 Iain Arnell 0.009012-1
- update to latest upstream version
- filter private requires/provides
diff --git a/sources b/sources
index a66768f..e10f150 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-58eb7e75104407bc7380f7019f1e7b75 Moo-0.009012.tar.gz
+80ec444a3d274abe66b37ea4e5006ab9 Moo-0.009013.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
Re: mysql is now a critpath package? WTF?
Michael Cronenworth writes: > Kevin Kofler wrote: >> PostgreSQL requires manual intervention at each upgrade (dump BEFORE you >> upgrade, restore afterwards) > As of PostgreSQL 9.0, there is an upgrade utility[1] that doesn't > require a dump/restore. But it does still require manual intervention, and there are still the macro issues of whether you really want people to have to acquire some DBA skillz to read their mail. I was *not* proposing this approach. I remain of the opinion that mysql is also too heavyweight for this, though. If the akonadi folk don't like sqlite, maybe they should be looking into something like bdb. Embedded databases are simply different critters from database servers, and trying to pretend that code designed as the latter can be used as the former is not going to lead to anything but pain. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Exutils::MakeMaker dual-lives now
On Fri, Jan 06, 2012 at 04:16:59PM +0100, Iain Arnell wrote: > On Fri, Jan 6, 2012 at 4:02 PM, Petr Pisar wrote: > > Hello, > > > > I've just built CPAN variant of ExtUtils::MakeMaker in F17. I've been using > > the version for long time in my F17 virtual machine for doing package > > reviews, > > so I hope there should be no problems. However if your package stops to > > build > > for unkown reason, this could be the culprit. > > I spotted a problem earlier today with EU::MM from Paul's rebuild of > perl itself. For some reason, rpm seems to have stopped automatically > picking up perl-ExtUtils-MakeMaker's requirement on > perl-ExtUtils-Install. Release 207 was okay, but 208 wasn't. I "fixed" > it by rebuilding perl again with the dependency defined explicitly. > > I've still got a few more packages that need updating, so should be > able to give the new EU::MM a brief workout over the weekend. > Yes, somthing has broken in 208. Dependency changes between 207 and 208: * x86_64/perl: removed PROVIDES perl(x86-64) = 4:5.14.2-207.fc17 added PROVIDES perl(x86-64) = 4:5.14.2-208.fc17 removed REQUIRES perl(deprecate) removed REQUIRES perl(Devel::DProf) removed REQUIRES perl(Encode::Alias) removed REQUIRES perl(File::Temp) removed REQUIRES perl(Getopt::Std) removed REQUIRES perl-libs = 4:5.14.2-207.fc17 added REQUIRES perl-libs = 4:5.14.2-208.fc17 removed REQUIRES perl(Pod::Find) removed REQUIRES perl(Pod::Html) removed REQUIRES perl(Pod::Checker) removed REQUIRES perl(Pod::LaTeX) removed REQUIRES perl(Pod::Man) removed REQUIRES perl(Pod::Usage) removed REQUIRES perl >= 0:5.003 removed REQUIRES perl >= 1:5.8.0 * x86_64/perl-Compress-Raw-Bzip2: removed PROVIDES perl-Compress-Raw-Bzip2(x86-64) = 0:2.033-207.fc17 added PROVIDES perl-Compress-Raw-Bzip2(x86-64) = 0:2.033-208.fc17 * x86_64/perl-Compress-Raw-Zlib: removed PROVIDES perl-Compress-Raw-Zlib(x86-64) = 0:2.033-207.fc17 added PROVIDES perl-Compress-Raw-Zlib(x86-64) = 0:2.033-208.fc17 * x86_64/perl-core: removed PROVIDES perl-core(x86-64) = 0:5.14.2-207.fc17 added PROVIDES perl-core(x86-64) = 0:5.14.2-208.fc17 removed REQUIRES perl-devel = 4:5.14.2-207.fc17 added REQUIRES perl-devel = 4:5.14.2-208.fc17 removed REQUIRES perl-libs = 4:5.14.2-207.fc17 added REQUIRES perl-libs = 4:5.14.2-208.fc17 * x86_64/perl-devel: removed PROVIDES perl-devel(x86-64) = 4:5.14.2-207.fc17 added PROVIDES perl-devel(x86-64) = 4:5.14.2-208.fc17 removed PROVIDES perl(MY) removed REQUIRES perl(Carp) removed REQUIRES perl(Config) removed REQUIRES perl(constant) removed REQUIRES perl(DynaLoader) removed REQUIRES perl(Exporter) removed REQUIRES perl(ExtUtils::Constant) removed REQUIRES perl(ExtUtils::Installed) removed REQUIRES perl(ExtUtils::MakeMaker) removed REQUIRES perl(File::Compare) removed REQUIRES perl(File::Find) removed REQUIRES perl(File::Path) removed REQUIRES perl(File::Spec) removed REQUIRES perl(Getopt::Long) removed REQUIRES perl(Getopt::Std) removed REQUIRES perl(IO::File) removed REQUIRES perl(Text::Wrap) removed REQUIRES perl(vars) removed REQUIRES perl(warnings) removed REQUIRES perl >= 1:5.7.2 * x86_64/perl-Digest-MD5: removed PROVIDES perl-Digest-MD5(x86-64) = 0:2.51-207.fc17 added PROVIDES perl-Digest-MD5(x86-64) = 0:2.51-208.fc17 * x86_64/perl-Digest-SHA: removed PROVIDES perl-Digest-SHA(x86-64) = 1:5.61-207.fc17 added PROVIDES perl-Digest-SHA(x86-64) = 1:5.61-208.fc17 removed REQUIRES perl(Getopt::Long) * x86_64/perl-IO-Compress: removed PROVIDES perl-IO-Compress(x86-64) = 0:2.033-207.fc17 added PROVIDES perl-IO-Compress(x86-64) = 0:2.033-208.fc17 * x86_64/perl-libs: removed PROVIDES perl-libs(x86-64) = 4:5.14.2-207.fc17 added PROVIDES perl-libs(x86-64) = 4:5.14.2-208.fc17 * x86_64/perl-macros: removed PROVIDES perl-macros(x86-64) = 4:5.14.2-207.fc17 added PROVIDES perl-macros(x86-64) = 4:5.14.2-208.fc17 * x86_64/perl-PathTools: removed PROVIDES perl-PathTools(x86-64) = 0:3.33-207.fc17 added PROVIDES perl-PathTools(x86-64) = 0:3.33-208.fc17 * x86_64/perl-Scalar-List-Utils: removed PROVIDES perl-Scalar-List-Utils(x86-64) = 0:1.23-207.fc17 added PROVIDES perl-Scalar-List-Utils(x86-64) = 0:1.23-208.fc17 * x86_64/perl-Socket: removed PROVIDES perl-Socket(x86-64) = 0:1.94-207.fc17 added PROVIDES perl-Socket(x86-64) = 0:1.94-208.fc17 * x86_64/perl-tests: removed PROVIDES perl-tests(x86-64) = 4:5.14.2-207.fc17 added PROVIDES perl-tests(x86-64) = 4:5.14.2-208.fc17 * x86_64/perl-threads: removed PROVIDES perl-threads(x86-64) = 0:1.83-207.fc17 added PROVIDES perl-threads(x86-64) = 0:1.83-208.fc17 * x86_64/perl-threads-shared: removed PROVIDES perl-threads-shared(x86-64) = 0:1.37-207.fc17 ad
Re: Review swaps
Hello All! 2011/12/15 Brendan Jones : > I would like to swap reviews for the following. All are very tiny so feel > free to swap 2 for one. Listed in descending priority: > https://bugzilla.redhat.com/show_bug.cgi?id=760270 > lv2-ams-plugins - LV2 port of the Alsa Modular Synth modules > > https://bugzilla.redhat.com/show_bug.cgi?id=766154 > lv2-kn0ck0ut - An LV2 spectral subtraction plugin (linux audio) > > https://bugzilla.redhat.com/show_bug.cgi?id=754004 > lv2-abGate - an LV2 Noise Gate plugin Sorry for grabbing all of these for reviewing (and thus ruining someone's plans) but they weren't marked as w.i.p. when I found them. Brendan, in the meantime could you please try to review this one from me: https://bugzilla.redhat.com/show_bug.cgi?id=772217 -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GCC 4.7 build issues: error: no matching function for call...
openCOLLADA is failing to build with GCC 4.7 in rawhide and I was hoping someone could point me in the right direction for a solution. Below is the build log snippet. Thanks, Richard --- [ 2%] Building CXX object GeneratedSaxParser/CMakeFiles/GeneratedSaxParser_shared.dir/src/GeneratedSaxParserParser.cpp.o cd /builddir/build/BUILD/openCOLLADA-svn864/Build/GeneratedSaxParser && /usr/lib64/ccache/c++ -DGeneratedSaxParser_shared_EXPORTS -DGENERATEDSAXPARSER_XMLPARSER_LIBXML -DXMLPARSER_LIBXML -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -Wextra -Wno-unknown-pragmas -Wno-switch -Wno-reorder -Wno-unused-parameter -Wno-ignored-qualifiers -O2 -g -fPIC -I/builddir/build/BUILD/openCOLLADA-svn864/GeneratedSaxParser/include -I/usr/include/libxml2 -I/builddir/build/BUILD/openCOLLADA-svn864/COLLADABaseUtils/include -I/builddir/build/BUILD/openCOLLADA-svn864/COLLADABaseUtils/include/Math -o CMakeFiles/GeneratedSaxParser_shared.dir/src/GeneratedSaxParserParser.cpp.o -c /builddir/build/BUILD/openCOLLADA-svn864/GeneratedSaxParser/src/GeneratedSaxParserParser.cpp Scanning dependencies of target OpenCOLLADASaxFrameworkLoader_shared In file included from /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWTechniqueFX.h:17:0, from /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/src/COLLADASWTechniqueFX.cpp:12: /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWAnnotation.h: In member function 'void COLLADASW::Annotation::add(const String&, const COLLADASW::ValueType::ColladaType&, T) const': /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWAnnotation.h:224:35: note: candidate is: In file included from /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWTechniqueFX.h:17:0, from /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/src/COLLADASWTechniqueFX.cpp:12: /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWAnnotation.h:164:14: note: void COLLADASW::Annotation::openAnnotation(const String&) /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWAnnotation.h:164:14: note: no known conversion for implicit 'this' parameter from 'const COLLADASW::Annotation*' to 'COLLADASW::Annotation*' In file included from /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWTechniqueFX.h:17:0, from /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/src/COLLADASWTechniqueFX.cpp:12: /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWAnnotation.h:225:38: error: no matching function for call to 'COLLADASW::Annotation::openValuesElement(const COLLADASW::ValueType::ColladaType&) const' /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWAnnotation.h:225:38: note: candidate is: In file included from /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWTechniqueFX.h:17:0, from /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/src/COLLADASWTechniqueFX.cpp:12: /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWAnnotation.h:178:14: note: void COLLADASW::Annotation::openValuesElement(const COLLADASW::ValueType::ColladaType&) /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWAnnotation.h:178:14: note: no known conversion for implicit 'this' parameter from 'const COLLADASW::Annotation*' to 'COLLADASW::Annotation*' In file included from /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWTechniqueFX.h:17:0, from /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/src/COLLADASWTechniqueFX.cpp:12: /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWAnnotation.h:227:33: error: no matching function for call to 'COLLADASW::Annotation::closeValuesElement() const' /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWAnnotation.h:227:33: note: candidate is: In file included from /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWTechniqueFX.h:17:0, from /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/src/COLLADASWTechniqueFX.cpp:12: /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWAnnotation.h:184:14: note: void COLLADASW::Annotation::closeValuesElement() /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWAnnotation.h:184:14: note: no known conversion for implicit 'this' parameter from 'const COLLADASW::Annotation*' to 'COLLADASW::Annotation*' In file included from /builddir/build/BUILD/openCOLLADA-svn864/COLLADAStreamWriter/include/COLLADASWTechniqueFX.h:17:0, from /builddir/build/BUILD/openCOLLADA-svn864/COLLADASt
Re: Review swaps
On 01/06/2012 05:03 PM, Peter Lemenkov wrote: Hello All! 2011/12/15 Brendan Jones: I would like to swap reviews for the following. All are very tiny so feel free to swap 2 for one. Listed in descending priority: https://bugzilla.redhat.com/show_bug.cgi?id=760270 lv2-ams-plugins - LV2 port of the Alsa Modular Synth modules https://bugzilla.redhat.com/show_bug.cgi?id=766154 lv2-kn0ck0ut - An LV2 spectral subtraction plugin (linux audio) https://bugzilla.redhat.com/show_bug.cgi?id=754004 lv2-abGate - an LV2 Noise Gate plugin Sorry for grabbing all of these for reviewing (and thus ruining someone's plans) but they weren't marked as w.i.p. when I found them. Brendan, in the meantime could you please try to review this one from me: https://bugzilla.redhat.com/show_bug.cgi?id=772217 Thanks for that Peter, I will take your review. Sorry Hans, Greg - looks like Peter started before emailing the list - I will still honour my promise for your reviews however. Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anyone interested in abi-compliance-checker?
On 11/14/2011 12:46 PM, Richard Shaw wrote: I was looking for a way to check abi compatibility for a package I maintain that does not control API/ABI compatibility and found this: http://forge.ispras.ru/projects/abi-compliance-checker I already have it packaged for my own use so I thought I'd check to see if anyone else is interested in it, and if so, if someone will want to review it. Thanks, Richard How do you generally make use of it? In the course of my build process I don't normally have two versions of the same library installed on one machine which seems to be what is needed to use it. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: broken dependencies for fawkes-plugin-player
On Tue, 03 Jan 2012 17:14:20 -0800 Adam Williamson wrote: > On Tue, 2011-12-27 at 09:55 -0600, Rex Dieter wrote: > > Michael Schwendt wrote: > > > > > On Tue, 27 Dec 2011 12:43:02 +0100, FD (Francesco) wrote: > > > > > >> fawkes-plugin-player.x86_64 require libgeos-3.3.0.so (64bit) but > > >> geos.x86_64 package provides libgeos-3.3.1.so > > > > > > It has been reported before and in the right place: > > > > > > http://bugz.fedoraproject.org/fawkes > > > > > > An update of "geos" is incompatible and should not have been > > > published: > > > > > https://admin.fedoraproject.org/updates/FEDORA-2011-14436/geos-3.3.1-1.fc16 > > > > And an arguable abuse of the process, a submitter setting karma: 1 > > and then giving their own update the requisite karma++ to get it > > pushed to stable almost immediately. :( > > My recollection is that FESCo has specifically decided that > maintainers must not +1 their own updates, but this does not appear > to be stated anywhere in the updates policy: > > https://fedoraproject.org/wiki/Updates_Policy > > Perhaps it should be updated. Yeah, we should update that. See also: https://fedorahosted.org/bodhi/ticket/277 kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Inactive package maintainers cleanup on 2012-01-10
Greetings. Last year we asked everyone to change their fedora account system password and upload a new ssh public key. The deadline for this was 2011-11-30. Those who had not uploaded a new key or changed their password were marked 'inactive' in the fedora account system. Some subset of those inactive users were/are package maintainers. On 2012-01-10, we are going to remove these inactive users from package acls. This will result in some packages being orphaned and available for other maintainers. Any packages not owned prior to Feature Freeze for Fedora 17 (2012-02-07) will be retired. A full list of users and packages and acls affected as of 2012-01-06 can be found at: https://fedorahosted.org/fedora-infrastructure/ticket/3046 If you know a user who is currently inactive and affected by this process and have a way to contact them, please ask them to change their password and upload a new ssh key and they will continue to hold their package acls. More information: https://fedoraproject.org/wiki/Releases/17/Schedule http://fedoraproject.org/wiki/Deprecate_orphaned_packages https://fedorahosted.org/fedora-infrastructure/ticket/3046 kevin signature.asc Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 3.12.1 (was 3.12.0) in Rawhide
On Fri, Jan 06, 2012 at 12:47:39PM +, Richard W.M. Jones wrote: > > http://caml.inria.fr/ocaml/release.en.html > > 3.12.1 is a simple bugfix update to the compiler. It probably would have been a good idea to link to the release notes ... http://caml.inria.fr/pub/distrib/ocaml-3.12/notes/Changes I've done about 2/3rds of the OCaml packages, and have now got bored. Below are the ones that I HAVEN'T done. Feel free to jump in! However please check the upstream for each package to see if there is a new version, and if so, update to it. ocaml-apron-0.9.10-4.fc17 ocaml-bin-prot-2.0.6-1.fc17 ocaml-bisect-1.0-4.fc15 ocaml-cil-1.3.7-10.fc16 ocaml-cryptokit-1.4-4.fc15 ocaml-dbus-0.29-2.fc15 ocaml-deriving-0.1.1a-12.fc15 ocaml-facile-1.1-14.fc15 ocaml-gsl-0.6.0-12.fc15 ocaml-json-static-0.9.8-4.fc15 ocaml-json-wheel-1.0.6-6.fc17 ocaml-lacaml-5.4.8-2.fc15 ocaml-lwt-2.3.2-1.fc17 ocaml-mikmatch-1.0.3-4.fc16 ocaml-mlgmpidl-1.1-7.fc15 ocaml-mysql-1.0.4-14.fc15 ocaml-newt-0.9-10.fc15 ocaml-ocamlgraph-1.8.1-1.fc17 ocaml-openin-20070524-12.fc15 ocaml-p3l-2.03-8.fc15 ocaml-pa-do-0.8.12-2.fc15 ocaml-pa-monad-6.0-6.fc15 ocaml-postgresql-1.14.0-2.fc15 ocaml-preludeml-0.1-0.18.20100314.fc17 ocaml-reins-0.1a-10.fc15 ocaml-res-3.2.0-6.fc15 ocaml-SDL-0.8.0-3.fc15 cduce coq coccinelle Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 3.12.1 (was 3.12.0) in Rawhide
On Fri, Jan 6, 2012 at 11:16 AM, Richard W.M. Jones wrote: > Below are the ones that I HAVEN'T done. Feel free to jump in! > However please check the upstream for each package to see if there is > a new version, and if so, update to it. > > ocaml-apron-0.9.10-4.fc17 > ocaml-ocamlgraph-1.8.1-1.fc17 > coq These 3 are on my list. I'm attempting to do an ordered rebuild of my packages. Wish me luck. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anyone interested in abi-compliance-checker?
Le 06/01/2012 19:00, Orion Poplawski a écrit : > How do you generally make use of it? In the course of my build process > I don't normally have two versions of the same library installed on one > machine which seems to be what is needed to use it. I use it for some lib I maintain - generate the analysis with version N abi-compliance-checker -l libmemcached \ -dump_abi libmemcached042.xml - build / install new version - generate the analysis with version N+1 abi-compliance-checker -l libmemcached \ -dump_abi libmemcached043.xml - Compare the result abi-compliance-checker -l libmemcached \ -d1 abi_dumps/libmemcached/libmemcached_0.42.abi.tar.gz \ -d2 abi_dumps/libmemcached/libmemcached_0.43.abi.tar.gz \ firefox file:$(pwd)/compat_reports/libmemcached/0.42_to_0.43/abi_compat_report.html or, tips, use http://linuxtesting.org/upstream-tracker/ ;) Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-MIME-Charset] fix typo in changelog date
commit 08e490532d0e52d8cdb44c6aadc3e24ec1a609a0
Author: Xavier Bachelot
Date: Fri Jan 6 18:25:59 2012 +0100
fix typo in changelog date
perl-MIME-Charset.spec |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/perl-MIME-Charset.spec b/perl-MIME-Charset.spec
index b5ab94f..8929ca8 100644
--- a/perl-MIME-Charset.spec
+++ b/perl-MIME-Charset.spec
@@ -62,7 +62,7 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
-* Fri Jan 06 2011 Xavier Bachelot 1.009.1-5
+* Fri Jan 06 2012 Xavier Bachelot 1.009.1-5
- Add BR: for perl(Encode::EUCJPASCII) for better test coverage.
* Wed Dec 21 2011 Xavier Bachelot 1.009.1-4
--
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
Summary: Fedora Kernel Team Meeting 1-6-2012
== #fedora-meeting: Fedora kernel == Meeting started by jwb at 18:00:02 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-01-06/fedora_kernel.2012-01-06-18.00.log.html . Meeting summary --- * fudcon (jwb, 18:02:15) * Fedora 15/16 (jwb, 18:06:09) * Revisit sched_generic bugs with upstream if 3.2 still shows frequent occurances (jwb, 18:18:17) * f15/f16 rebase to 3.2.x around FUDCon timeframe (jwb, 18:19:03) * AGREED: Put various config options we want to try in rawhide but aren't ready for a stable release in 'make release/debug' (jwb, 18:26:06) * f17 (rawhide) (jwb, 18:26:43) * rawhide will have kernels built with debug options disabled once per -rc (jwb, 18:34:48) * Remember to post questions and suggestions to the fedora kernel list (jwb, 18:44:15) Meeting ended at 18:44:19 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * jwb (70) * davej (56) * nirik (9) * zodbot (3) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anyone interested in abi-compliance-checker?
On 01/06/2012 11:34 AM, Remi Collet wrote: Le 06/01/2012 19:00, Orion Poplawski a écrit : How do you generally make use of it? In the course of my build process I don't normally have two versions of the same library installed on one machine which seems to be what is needed to use it. I use it for some lib I maintain - generate the analysis with version N abi-compliance-checker -l libmemcached \ -dump_abi libmemcached042.xml - build / install new version - generate the analysis with version N+1 abi-compliance-checker -l libmemcached \ -dump_abi libmemcached043.xml - Compare the result abi-compliance-checker -l libmemcached \ -d1 abi_dumps/libmemcached/libmemcached_0.42.abi.tar.gz \ -d2 abi_dumps/libmemcached/libmemcached_0.43.abi.tar.gz \ firefox file:$(pwd)/compat_reports/libmemcached/0.42_to_0.43/abi_compat_report.html or, tips, use http://linuxtesting.org/upstream-tracker/ ;) Remi. Thanks! That seems easier than using rpm2cpio as well as keeping history. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps
Am Freitag, 6. Januar 2012, 18:09:08 schrieb Brendan Jones: > On 01/06/2012 05:03 PM, Peter Lemenkov wrote: > > Hello All! > > > > 2011/12/15 Brendan Jones: > >> I would like to swap reviews for the following. All are very tiny so > >> feel free to swap 2 for one. Listed in descending priority: > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=760270 > >> lv2-ams-plugins - LV2 port of the Alsa Modular Synth modules > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=766154 > >> lv2-kn0ck0ut - An LV2 spectral subtraction plugin (linux audio) > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=754004 > >> lv2-abGate - an LV2 Noise Gate plugin > > > > Sorry for grabbing all of these for reviewing (and thus ruining > > someone's plans) but they weren't marked as w.i.p. when I found them. > > Brendan, in the meantime could you please try to review this one from > > me: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=772217 > > Thanks for that Peter, I will take your review. > > Sorry Hans, Greg - looks like Peter started before emailing the list - I > will still honour my promise for your reviews however. > > Brendan np, I'm cool with that :) 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: Review swaps
Hi, On 01/06/2012 06:09 PM, Brendan Jones wrote: On 01/06/2012 05:03 PM, Peter Lemenkov wrote: Hello All! 2011/12/15 Brendan Jones: I would like to swap reviews for the following. All are very tiny so feel free to swap 2 for one. Listed in descending priority: https://bugzilla.redhat.com/show_bug.cgi?id=760270 lv2-ams-plugins - LV2 port of the Alsa Modular Synth modules https://bugzilla.redhat.com/show_bug.cgi?id=766154 lv2-kn0ck0ut - An LV2 spectral subtraction plugin (linux audio) https://bugzilla.redhat.com/show_bug.cgi?id=754004 lv2-abGate - an LV2 Noise Gate plugin Sorry for grabbing all of these for reviewing (and thus ruining someone's plans) but they weren't marked as w.i.p. when I found them. Brendan, in the meantime could you please try to review this one from me: https://bugzilla.redhat.com/show_bug.cgi?id=772217 Thanks for that Peter, I will take your review. Sorry Hans, Greg - looks like Peter started before emailing the list - I will still honour my promise for your reviews however. np, just let me know when you've something else to review and I'll review that instead :) Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Wireless Access at FUDCon Blacksburg
If you are attending FUDCon:Blacksburg next week (January 13-15), you need to request a guest internet access account in order to use the guest wireless access on the Virginia Tech campus. It is requested that you sign up for this account PRIOR to your arrival at FUDCon. Pretty please. Directions for obtaining wireless access are listed on the FUDCon Blacksburg wiki page: https://fedoraproject.org/wiki/FUDCon:Blacksburg_2012#Wireless_Registration However, since I'm really nice, I'll spell it out in this email as well: 1. Go to the guest wireless registration page, here: https://guest.cns.vt.edu/apps/home.action 2. Enter start date: 1/13/2012, for example 3. Enter end date: 1/15/2012, for example 4. Sponsoring Department: Select "Mathematics" 5. Contact Person: Enter "Ben Williams" (our awesome, gracious host and contact at VT) 6. Purpose: FUDCon 7. Click the "Create Request" button 8. Enter email address and select "New Guest" 9. Fill out form including secret questions, password boxes, and agree to the Acceptable Use Policy 10. Click "Create Account" 11. Receive email in your inbox and verify your request. Thanks, and I'm looking forward to seeing everyone next week in Blacksburg! :) -Robyn ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
systemd: How to wait for a device before starting a service
Ok, I didn't know how to make the subject any shorter, but there's a big BUT in this, but (hehe) first a summary. I have a user of MythTV that has capture devices which require a firmware be uploaded. As a consequence, the /dev paths are not always created by the time mythbackend tries to start. A solution to this is to create a mythbackend.path unit file which will wait for the devices to be created, BUT, they occasionally fail to initialize and the path unit file doesn't seem to have a timeout option (or option for what to do once the timeout is reached). A partial solution would be to use a timer unit file, but it too doesn't do quite what I need. It doesn't appear that I can wait for the start of one unit file (mythbackend.path) while starting a different unit file (mythbackend.service) once the timeout is reached. I could use the same 'After=...' as I have on the main service file which would approximate the same startup time, but that's rather hackish. I am assuming that having two unit files (a path and a timer) trying to start the same service isn't an issue and that the first one wins. Below is the entire message I was sent with his solution which is even more complicated than what I'm proposing, but appears to work. Thanks, Richard -- Forwarded message -- From: Gary Date: Fri, Jan 6, 2012 at 1:41 PM Subject: mythbackend.service file questions/suggestions. To: hobbes1...@gmail.com Hi, As the maintainer of the rpmfusion mythtv package, I thought I would provide some feedback on the systemd scripts currently being shipped. I have found that in Fedora 16 to get mythtv backend to (more or less) reliably startup after a system reboot, I have had to modify the service files as shown below. The reason is that for some capture devices, there is additional processing (i.e. firmware downloads) that can take an extended time to complete (in my case, 6 tuners using the pvrusp2 driver, which take around 70 seconds after boot on a slow system). The intent is to wait for the capture device paths to exist, and only when all are there, start the backend. As a fallback, start the backend no matter what after 2 minutes (in the case where one or more capture cards never initialize). I am not entirely sure that this is the correct way to do this, but various other methods I tried did not seem to work. If you, or someone you know, know systemd better, please share, and feel free to use any of this as appropriate. Thanks for the work packaging mythtv for rpmfusion! Gary ---New File: mythbackend-waitdev.path [Unit] Description=MythTV backend service startup delay until capture devices exist [Path] # # "Dummy" (always existing) file to keep systemd happy # (if there is no items in the [Path], systemd complains) # PathExists=/dev/null # # List all devices the mythbackend would try to initialize. # For each (new) device, this unit will try to start the # related service, which will start only when all devices # are ready. These should normally be the udev persistent # rule names to avoid confusion. # # You must also update the service file with the same # capture device paths. # # PathExists=/dev/video300 # PathExists=/dev/video301 [Install] WantedBy=multi-user.target ---New File: mythbackend-waitdev.service [Unit] Description=MythTV backend service startup delay until capture devices exist # # Create an entry for all the capture devices that # one wishes to wait to be created. These normally # should be udev persistent rule names to avoid # confusion. # # You must also update the path unit with the same # device names # # ConditionPathExists=/dev/video300 # ConditionPathExists=/dev/video301 [Service] Type=oneshot ExecStart=/bin/systemctl start mythbackend.service RemainAfterExit=true ---New File: mythbackend.timer # # Normally the MythTV backend will be started # after all capture devices have been initialized, # but if one (or more) does not, we still want # to start the backend. This timer will do that. # [Unit] Description=MythTV backend service startup after delay (failsafe startup) [Timer] OnActiveSec=120 [Install] WantedBy=multi-user.target ---Modified file: mythbackend.service (removed [Install]) [Unit] Description=MythTV backend service After=network.target mysqld.service [Service] Type=simple Environment=MYTHCONFDIR=/etc/mythtv Environment=HOME=/usr/share/mythtv User=mythtv ExecStart=/usr/bin/mythbackend --logfile /var/log/mythtv/mythbackend.log -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: How to wait for a device before starting a service
On Fri, Jan 06, 2012 at 02:55:35PM -0600, Richard Shaw wrote: > Ok, I didn't know how to make the subject any shorter, but there's a > big BUT in this, but (hehe) first a summary. > > I have a user of MythTV that has capture devices which require a > firmware be uploaded. As a consequence, the /dev paths are not always > created by the time mythbackend tries to start. A solution to this is > to create a mythbackend.path unit file which will wait for the devices > to be created, BUT, they occasionally fail to initialize and the path > unit file doesn't seem to have a timeout option (or option for what to > do once the timeout is reached). > > A partial solution would be to use a timer unit file, but it too > doesn't do quite what I need. It doesn't appear that I can wait for > the start of one unit file (mythbackend.path) while starting a > different unit file (mythbackend.service) once the timeout is reached. > > I could use the same 'After=...' as I have on the main service file > which would approximate the same startup time, but that's rather > hackish. I am assuming that having two unit files (a path and a timer) > trying to start the same service isn't an issue and that the first one > wins. We use the following for the libguestfs live service: http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=99-guestfsd.rules;h=ab4f6800bbd847307aceb2cb52e984524eaee52c;hb=HEAD http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=guestfsd.service;h=482d1e2bf1fb1c791e3adfe3f58716c38edb6b3d;hb=HEAD HTH, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
On Thu, 2012-01-05 at 13:13 -0500, Bill Nottingham wrote: > Tom Lane (t...@redhat.com) said: > > So I submitted a routine bodhi request for updating mysql, and was > > astonished to find that it's marked as critpath. It was never that > > before. Who decided this, > > The dependency solver. It's not a manual process. > > > and would it not have been polite to involve > > or at least notify the package maintainer? > > http://lists.fedoraproject.org/pipermail/devel-announce/2011-December/000868.html > > We could consider having pkgdb e-mail the owner when the critpath bit for > the package gets flipped. Toshio, is that possible? > > As to where it came from, the dep chain is: > > kdepim > -> akonadi >-> qt-mysql, mysql-server > > kdepim is in critical path as part of 'critical-path-apps', which is > essentially mail & web. The change that caused this to get added is that the > script prior to early December wasn't actually iterating over the proper > critpath groups, including critical-path-apps. I don't recall mail being a critical path function. I'm not convinced kdepim should be critpath. The wiki states: graphical network install post-install booting decrypt encrypted filesystems graphics login networking get updates minimal buildroot compose new trees compose live None of those includes email, or anything else kdepim handles. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
On Thu, 2012-01-05 at 20:25 +0100, Kevin Kofler wrote: > Bill Nottingham wrote: > > kdepim is in critical path as part of 'critical-path-apps', which is > > essentially mail & web. The change that caused this to get added is that > > the script prior to early December wasn't actually iterating over the > > proper critpath groups, including critical-path-apps. > > I think we should reconsider including these things (also critical-path-kde) > in critpath. We've been working fine for years without those actually being > marked critpath. The critpath process is just an annoyance for these > packages. > > I'd suggest removing all of kde* from critpath, and I think most if not all > of KDE SIG agrees with me on this (if you want an official statement, I can > put it up for the next KDE SIG meeting). Per my reading of critpath, the only desktop-level functions it includes are 'networking' and 'install updates', which would really mean only knetworkmanager (or whatever it's really called) and kpackagekit (ditto) should be critpath. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: How to wait for a device before starting a service
On Fri, Jan 6, 2012 at 3:03 PM, Richard W.M. Jones wrote: > On Fri, Jan 06, 2012 at 02:55:35PM -0600, Richard Shaw wrote: >> Ok, I didn't know how to make the subject any shorter, but there's a >> big BUT in this, but (hehe) first a summary. >> >> I have a user of MythTV that has capture devices which require a >> firmware be uploaded. As a consequence, the /dev paths are not always >> created by the time mythbackend tries to start. A solution to this is >> to create a mythbackend.path unit file which will wait for the devices >> to be created, BUT, they occasionally fail to initialize and the path >> unit file doesn't seem to have a timeout option (or option for what to >> do once the timeout is reached). >> >> A partial solution would be to use a timer unit file, but it too >> doesn't do quite what I need. It doesn't appear that I can wait for >> the start of one unit file (mythbackend.path) while starting a >> different unit file (mythbackend.service) once the timeout is reached. >> >> I could use the same 'After=...' as I have on the main service file >> which would approximate the same startup time, but that's rather >> hackish. I am assuming that having two unit files (a path and a timer) >> trying to start the same service isn't an issue and that the first one >> wins. > > We use the following for the libguestfs live service: > > http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=99-guestfsd.rules;h=ab4f6800bbd847307aceb2cb52e984524eaee52c;hb=HEAD > > http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=guestfsd.service;h=482d1e2bf1fb1c791e3adfe3f58716c38edb6b3d;hb=HEAD I did look at the device unit file but it would probably take me a while to figure out how to use it and this needs to be done in a way an average "techie" user can fix it for their specific hardware. My plan was to create the timer and path files in a way they don't interfere with normal operation such as mine (I have a HDHR network based tuner, so I don't need this) and then leave decent instructions in the files on how to customize it for their setup, including copying the files to /etc/systemd/system so they dont' get overwritten on the next update. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Inactive package maintainers cleanup on 2012-01-10
I had previously taken over the mediawiki-openid package from Axel Thimm in like early 2010. I'd also be willing to take over fail2ban (also Axil Thimm). So that's 2 down, 800 to go =). On Fri, Jan 6, 2012 at 11:01 AM, Kevin Fenzi wrote: > Greetings. > > Last year we asked everyone to change their fedora account system > password and upload a new ssh public key. The deadline for this was > 2011-11-30. Those who had not uploaded a new key or changed their > password were marked 'inactive' in the fedora account system. > > Some subset of those inactive users were/are package maintainers. > On 2012-01-10, we are going to remove these inactive users from package > acls. This will result in some packages being orphaned and available > for other maintainers. Any packages not owned prior to Feature Freeze > for Fedora 17 (2012-02-07) will be retired. > > A full list of users and packages and acls affected as of 2012-01-06 can > be found at: https://fedorahosted.org/fedora-infrastructure/ticket/3046 > > If you know a user who is currently inactive and affected by this > process and have a way to contact them, please ask them to change their > password and upload a new ssh key and they will continue to hold their > package acls. > > More information: > > https://fedoraproject.org/wiki/Releases/17/Schedule > http://fedoraproject.org/wiki/Deprecate_orphaned_packages > https://fedorahosted.org/fedora-infrastructure/ticket/3046 > > kevin > > ___ > devel-announce mailing list > devel-annou...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel-announce > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Kurt Seifried k...@seifried.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
Adam Williamson (awill...@redhat.com) said: > On Thu, 2012-01-05 at 13:13 -0500, Bill Nottingham wrote: > > Tom Lane (t...@redhat.com) said: > > > So I submitted a routine bodhi request for updating mysql, and was > > > astonished to find that it's marked as critpath. It was never that > > > before. Who decided this, > > > > The dependency solver. It's not a manual process. > > > > > and would it not have been polite to involve > > > or at least notify the package maintainer? > > > > http://lists.fedoraproject.org/pipermail/devel-announce/2011-December/000868.html > > > > We could consider having pkgdb e-mail the owner when the critpath bit for > > the package gets flipped. Toshio, is that possible? > > > > As to where it came from, the dep chain is: > > > > kdepim > > -> akonadi > >-> qt-mysql, mysql-server > > > > kdepim is in critical path as part of 'critical-path-apps', which is > > essentially mail & web. The change that caused this to get added is that the > > script prior to early December wasn't actually iterating over the proper > > critpath groups, including critical-path-apps. > > I don't recall mail being a critical path function. I'm not convinced > kdepim should be critpath. http://fedoraproject.org/wiki/Updates_Policy See "Updates to 'critical path' packages". Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: How to wait for a device before starting a service
On Fri, 06.01.12 14:55, Richard Shaw (hobbes1...@gmail.com) wrote: > Ok, I didn't know how to make the subject any shorter, but there's a > big BUT in this, but (hehe) first a summary. > > I have a user of MythTV that has capture devices which require a > firmware be uploaded. As a consequence, the /dev paths are not always > created by the time mythbackend tries to start. A solution to this is > to create a mythbackend.path unit file which will wait for the devices > to be created, BUT, they occasionally fail to initialize and the path > unit file doesn't seem to have a timeout option (or option for what to > do once the timeout is reached). > > A partial solution would be to use a timer unit file, but it too > doesn't do quite what I need. It doesn't appear that I can wait for > the start of one unit file (mythbackend.path) while starting a > different unit file (mythbackend.service) once the timeout is reached. > > I could use the same 'After=...' as I have on the main service file > which would approximate the same startup time, but that's rather > hackish. I am assuming that having two unit files (a path and a timer) > trying to start the same service isn't an issue and that the first one > wins. > > Below is the entire message I was sent with his solution which is even > more complicated than what I'm proposing, but appears to work. Drop a udev rules file into /lib/udev/rules.d (if this is for a package) or /etc/udev/rules.d (if this is just a local installation) where you match the device and add the systemd tag to it: SUBSYSTEM=="foobar", SOMEMOREMATCHESHERE, TAG+="systemd" (Replace foobar with the subsystem name of your device and SOMEMOREMATCHESHERE with some sensible matches that identify your device uniquely). That will result in a .device unit to show up in systemd whenever the device is available, named after the /dev path (or /sys path if it doesn't have a device node). Then, you can add the following to your service: Wants=dev-waldo.device After=dev-waldo.device (Assuming your device is called /dev/waldo) And that should do the job. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: broken dependencies for fawkes-plugin-player
Kevin Fenzi wrote: > Yeah, we should update that. > > See also: https://fedorahosted.org/bodhi/ticket/277 Uh, hasn't FESCo recently voted to allow submitters to karma up their own packages if they're doing it in response to feedback from other people coming through non-Bodhi channels? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 3.12.1 (was 3.12.0) in Rawhide
Richard W.M. Jones wrote: > ocaml-facile-1.1-14.fc15 * Rebuilt * Checked for new upstream version, none (since 2005… but hey, the current version works fine) * Cleaned up the packaging I also rebuilt kalzium which is statically linked against ocaml-facile (it's a C++ app embedding ocamlopt native code). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2012-01-09 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2012-01-09 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! Hope everyone had a good time over the holidays! Now RH staff are back at work, and Fedora 17 and FUDCon Blacksburg are approaching, let's catch up and plan ahead. This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20120109 The current proposed agenda is include below. If no topics beyond the standard "Previous meeting follow-up" and "AutoQA update" topics are present or proposed, the meeting will be canceled. == Proposed Agenda Topics == 1. F16 retrospective task update 2. FUDCon Blacksburg notes 3. AutoQA update 4. Open Discussion - -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2011-12-26 @ 16:00 UTC - Fedora QA Meeting CANCELLED
Just for the historical record: the QA meeting for 2011-12-26 was cancelled, as with the two previous weeks, due to a lack of topics requiring discussion, and many group members being otherwise occupied over the holidays. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
service version disclosure
would it not be a good idea to NOT disclosure service versions? https://bugzilla.redhat.com/show_bug.cgi?id=718133 you will more and more have the "problem" of 3rd party security scans to your servers and currently in the case of openssh the only solution is to tkae the F16-src-rpm and rebuild it for your F15 machines ___ however - why do we spit the current running versions to everyone? Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. SSH-2.0-OpenSSH_5.8 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service version disclosure
On Sat, Jan 07, 2012 at 05:09:42 +0100, Reindl Harald wrote: > > however - why do we spit the current running versions to everyone? It can help when trouble shooting problems. The current version isn't really that helpful to attackers anyway. It's about as easy to just to try an exploit as it is to first test to see if the exploit might work and then try it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service version disclosure
Reindl Harald wrote: > would it not be a good idea to NOT disclosure service versions? > https://bugzilla.redhat.com/show_bug.cgi?id=718133 > > you will more and more have the "problem" of 3rd party > security scans to your servers and currently in the case > of openssh the only solution is to tkae the F16-src-rpm > and rebuild it for your F15 machines If the scan is looking at the version to determine vulnerability, it is completely broken, useless and unsupportable, because fixes can be backported. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service version disclosure
On 01/06/2012 11:09 PM, Reindl Harald wrote: > would it not be a good idea to NOT disclosure service versions? > https://bugzilla.redhat.com/show_bug.cgi?id=718133 > > you will more and more have the "problem" of 3rd party > security scans to your servers and currently in the case > of openssh the only solution is to tkae the F16-src-rpm > and rebuild it for your F15 machines > ___ > > however - why do we spit the current running versions to everyone? > > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > SSH-2.0-OpenSSH_5.8 Security through obscurity... -- Digimer E-Mail: digi...@alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org "omg my singularity battery is dead again. stupid hawking radiation." - epitron -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service version disclosure
On 6 January 2012 21:46, Kevin Kofler wrote: > Reindl Harald wrote: >> would it not be a good idea to NOT disclosure service versions? >> https://bugzilla.redhat.com/show_bug.cgi?id=718133 >> >> you will more and more have the "problem" of 3rd party >> security scans to your servers and currently in the case >> of openssh the only solution is to tkae the F16-src-rpm >> and rebuild it for your F15 machines > > If the scan is looking at the version to determine vulnerability, it is > completely broken, useless and unsupportable, because fixes can be > backported. I am going with Kevin on this one. The real hacking tools check to see if a vulnerability works or not. The broken "audit" scanners only check to see if a header is this or that. Not putting the header only gets you past the auditors and doesn't stop the real hacker from getting in if the vulnerability is there. -- Stephen J Smoogen. "The core skill of innovators is error recovery, not failure avoidance." Randy Nelson, President of Pixar University. "Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service version disclosure
Am 07.01.2012 06:13, schrieb Stephen John Smoogen: > On 6 January 2012 21:46, Kevin Kofler wrote: >> Reindl Harald wrote: >>> would it not be a good idea to NOT disclosure service versions? >>> https://bugzilla.redhat.com/show_bug.cgi?id=718133 >>> >>> you will more and more have the "problem" of 3rd party >>> security scans to your servers and currently in the case >>> of openssh the only solution is to tkae the F16-src-rpm >>> and rebuild it for your F15 machines >> >> If the scan is looking at the version to determine vulnerability, it is >> completely broken, useless and unsupportable, because fixes can be >> backported. if you have a big customer which hires a 3rd party auditor you are NOT in the poisiton to give such arguments or you can give them but you can not change ANYTHING in the fact that finally "fix it or shutdown the service" is what you have to do > I am going with Kevin on this one. The real hacking tools check to see > if a vulnerability works or not. The broken "audit" scanners only > check to see if a header is this or that. Not putting the header only > gets you past the auditors and doesn't stop the real hacker from > getting in if the vulnerability is there. that is not the point the point is why in the wolrd must we spit out versions? yes, i know it is security by obscurity but does it hurt? if i need to know my version of sshd or any other service i make a "rpm -qa | grep package", if somebody else likes to know he has to tell the question as i have for foreign servers signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service version disclosure
On 01/07/2012 12:31 AM, Reindl Harald wrote: > > Am 07.01.2012 06:13, schrieb Stephen John Smoogen: >> On 6 January 2012 21:46, Kevin Kofler wrote: >>> Reindl Harald wrote: would it not be a good idea to NOT disclosure service versions? https://bugzilla.redhat.com/show_bug.cgi?id=718133 you will more and more have the "problem" of 3rd party security scans to your servers and currently in the case of openssh the only solution is to tkae the F16-src-rpm and rebuild it for your F15 machines >>> >>> If the scan is looking at the version to determine vulnerability, it is >>> completely broken, useless and unsupportable, because fixes can be >>> backported. > > if you have a big customer which hires a 3rd party auditor > you are NOT in the poisiton to give such arguments or > you can give them but you can not change ANYTHING in > the fact that finally "fix it or shutdown the service" > is what you have to do If you have a "security expert" who can't grasp the concept of back-ported bug fixes, and is unwilling to test for specific vulnerabilities' existence, it's time to get a new expert. >> I am going with Kevin on this one. The real hacking tools check to see >> if a vulnerability works or not. The broken "audit" scanners only >> check to see if a header is this or that. Not putting the header only >> gets you past the auditors and doesn't stop the real hacker from >> getting in if the vulnerability is there. > > that is not the point > the point is why in the wolrd must we spit out versions? > > yes, i know it is security by obscurity > but does it hurt? > > if i need to know my version of sshd or any other service > i make a "rpm -qa | grep package", if somebody else likes > to know he has to tell the question as i have for foreign > servers Connecting programs don't have the luxury of 'rpm -q', and must rely on the version returned by the server to know how to pass data. Things change over time, and you certainly can't expect a server to behave the same over (sometimes long) periods of time. -- Digimer E-Mail: digi...@alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org "omg my singularity battery is dead again. stupid hawking radiation." - epitron -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service version disclosure
Am 07.01.2012 06:35, schrieb Digimer: >> if you have a big customer which hires a 3rd party auditor >> you are NOT in the poisiton to give such arguments or >> you can give them but you can not change ANYTHING in >> the fact that finally "fix it or shutdown the service" >> is what you have to do > > If you have a "security expert" who can't grasp the concept of > back-ported bug fixes, and is unwilling to test for specific > vulnerabilities' existence, it's time to get a new expert. you are missing the point A BIG CUSTOMER has a security-expert >> if i need to know my version of sshd or any other service >> i make a "rpm -qa | grep package", if somebody else likes >> to know he has to tell the question as i have for foreign >> servers > > Connecting programs don't have the luxury of 'rpm -q', and must rely on > the version returned by the server to know how to pass data. Things > change over time, and you certainly can't expect a server to behave the > same over (sometimes long) periods of time. connecting program rely on the PROTOCL version currently: SSH-2.0-OpenSSH_5.8 but "SSH-2.0" si the only relevant part here! for other services like imap, smtp and whatever there is also no single need for a client to know even the server-software the client only needs to know the capabilities of the server and since you wrote "concept of back-ported bug fixes" you seem to know that the server-software / version in this context is nonsense signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service version disclosure
On 6 January 2012 22:31, Reindl Harald wrote: > > Am 07.01.2012 06:13, schrieb Stephen John Smoogen: >> On 6 January 2012 21:46, Kevin Kofler wrote: >>> Reindl Harald wrote: would it not be a good idea to NOT disclosure service versions? https://bugzilla.redhat.com/show_bug.cgi?id=718133 you will more and more have the "problem" of 3rd party security scans to your servers and currently in the case of openssh the only solution is to tkae the F16-src-rpm and rebuild it for your F15 machines >>> >>> If the scan is looking at the version to determine vulnerability, it is >>> completely broken, useless and unsupportable, because fixes can be >>> backported. > > if you have a big customer which hires a 3rd party auditor > you are NOT in the poisiton to give such arguments or > you can give them but you can not change ANYTHING in > the fact that finally "fix it or shutdown the service" > is what you have to do Yes, if you have a big customer that is the case. I have been on the receiving end of that "shutdown the service". In the case you are mentioning, turning off warnings will not "fix" the problem. Many auditors will use a secondary set of tools on systems that have no version and then will label such systems at fault for falsifying data. >> I am going with Kevin on this one. The real hacking tools check to see >> if a vulnerability works or not. The broken "audit" scanners only >> check to see if a header is this or that. Not putting the header only >> gets you past the auditors and doesn't stop the real hacker from >> getting in if the vulnerability is there. > > that is not the point > the point is why in the wolrd must we spit out versions? Versions can be useful in everything from debugging to security scanning. The difference is whether or not the auditor is going to do a deep scan or not. > yes, i know it is security by obscurity > but does it hurt? I have seen several breakins where the system administrator turned off versions thinking that would protect him from breakins. > if i need to know my version of sshd or any other service > i make a "rpm -qa | grep package", if somebody else likes > to know he has to tell the question as i have for foreign > servers The good auditing tools will make a best guess for a service using either fingerprints or active vulnerability scans to figure out what is running. Now in any case you have a customer who has an audit and they need this fixed. What you need to do is find out what will fix it for that customer without making it worse for them. If the audit rules are they need to run the latest software, then they need to run the latest software because it can cause larger problems if the audit finds that the versions "lied to the auditors" what was run. [In some audits this is not the case, but more seem to be going to this method.] Other audits rules of engagement will want versions not to be printed. In those cases a custom set of packages are usually required if it is hard coded in the software. -- Stephen J Smoogen. "The core skill of innovators is error recovery, not failure avoidance." Randy Nelson, President of Pixar University. "Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service version disclosure
On Fri, Jan 6, 2012 at 10:02 PM, Reindl Harald wrote: > you are missing the point A BIG CUSTOMER has a security-expert And you, as a trusted vendor, have an opportunity to educate your customer about their security expert, and about how the Fedora project works. Fedora's stance is consistent with upstream: http://www.openssh.org/faq.html#2.14 -- Ed Marshall Felix qui potuit rerum cognoscere causas. http://esm.logic.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service version disclosure
On 01/07/2012 01:02 AM, Reindl Harald wrote: > Am 07.01.2012 06:35, schrieb Digimer: >>> if you have a big customer which hires a 3rd party auditor >>> you are NOT in the poisiton to give such arguments or >>> you can give them but you can not change ANYTHING in >>> the fact that finally "fix it or shutdown the service" >>> is what you have to do >> >> If you have a "security expert" who can't grasp the concept of >> back-ported bug fixes, and is unwilling to test for specific >> vulnerabilities' existence, it's time to get a new expert. > > you are missing the point A BIG CUSTOMER has a security-expert No, I'm not missing the point. You're asking for a wholesale change in how a program works so that you can have an easier time with an uneducated customer. Your job, as a consultant or IT support is not make sure that your solution is safe. Making you customer feel comfortable without actually given them security is a bad idea. -- Digimer E-Mail: digi...@alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org "omg my singularity battery is dead again. stupid hawking radiation." - epitron -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service version disclosure
Am 07.01.2012 07:52, schrieb Digimer: > On 01/07/2012 01:02 AM, Reindl Harald wrote: >> Am 07.01.2012 06:35, schrieb Digimer: if you have a big customer which hires a 3rd party auditor you are NOT in the poisiton to give such arguments or you can give them but you can not change ANYTHING in the fact that finally "fix it or shutdown the service" is what you have to do >>> >>> If you have a "security expert" who can't grasp the concept of >>> back-ported bug fixes, and is unwilling to test for specific >>> vulnerabilities' existence, it's time to get a new expert. >> >> you are missing the point A BIG CUSTOMER has a security-expert > > No, I'm not missing the point. You're asking for a wholesale change in > how a program works so that you can have an easier time with an > uneducated customer. Your job, as a consultant or IT support is not make > sure that your solution is safe. Making you customer feel comfortable > without actually given them security is a bad idea. i know about the pros and cons for obscurity but i also know that from "SSH-2.0-OpenSSH_5.8" only "SSH-2.0" is relevant for clients and having backports in mind this must be the truth because if the whole version would matter all LTS distributions would be broken by design signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service version disclosure
On 01/07/2012 01:59 AM, Reindl Harald wrote: > > > Am 07.01.2012 07:52, schrieb Digimer: >> On 01/07/2012 01:02 AM, Reindl Harald wrote: >>> Am 07.01.2012 06:35, schrieb Digimer: > if you have a big customer which hires a 3rd party auditor > you are NOT in the poisiton to give such arguments or > you can give them but you can not change ANYTHING in > the fact that finally "fix it or shutdown the service" > is what you have to do If you have a "security expert" who can't grasp the concept of back-ported bug fixes, and is unwilling to test for specific vulnerabilities' existence, it's time to get a new expert. >>> >>> you are missing the point A BIG CUSTOMER has a security-expert >> >> No, I'm not missing the point. You're asking for a wholesale change in >> how a program works so that you can have an easier time with an >> uneducated customer. Your job, as a consultant or IT support is not make >> sure that your solution is safe. Making you customer feel comfortable >> without actually given them security is a bad idea. > > i know about the pros and cons for obscurity > > but i also know that from "SSH-2.0-OpenSSH_5.8" only "SSH-2.0" > is relevant for clients and having backports in mind this must > be the truth because if the whole version would matter all > LTS distributions would be broken by design This doesn't change the fundamental point; You are asking for a significant change in behaviour to a program that who-knows-how-many apps use, for no real reason other than to make a client feel better. -- Digimer E-Mail: digi...@alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org "omg my singularity battery is dead again. stupid hawking radiation." - epitron -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service version disclosure
Am 07.01.2012 08:02, schrieb Digimer: >> i know about the pros and cons for obscurity >> >> but i also know that from "SSH-2.0-OpenSSH_5.8" only "SSH-2.0" >> is relevant for clients and having backports in mind this must >> be the truth because if the whole version would matter all >> LTS distributions would be broken by design > > This doesn't change the fundamental point; > > You are asking for a significant change in behaviour to a program that > who-knows-how-many apps use, for no real reason other than to make a > client feel better. no, one keys of security is to provide as less informations as absolutely necessary, not only for sshd, for every single service in the best case no single foreign person has an idea what software you are currently running, not what OS nor what service-software and at least no exact version signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service version disclosure
Once upon a time, Reindl Harald said:
> Am 07.01.2012 06:35, schrieb Digimer:
> > If you have a "security expert" who can't grasp the concept of
> > back-ported bug fixes, and is unwilling to test for specific
> > vulnerabilities' existence, it's time to get a new expert.
>
> you are missing the point A BIG CUSTOMER has a security-expert
Well, a big customer has a so-called or self-proclaimed security expert.
That is your opportunity to educate the customer and possibly gain some
security business for yourself.
Do you actually use Fedora for security-conscious big-buisness
customers? I use RHEL, and if they question versions from some external
scan, I quote Red Hat's backport policy. Any sane scan will reference
CVEs, and fixed CVEs are listed in the RPM changelogs (so I can quote
those to show security).
If you filter out versions, you're liable to get a security "report"
that lists every vulnerability in Apache, OpenSSH, sendmail/postfix/etc.
If you manage to filter out program names (not always possible), you'll
get a list of every CVE referencing the service listening on a port
("port 53 looks like it is running a DNS server; here's a list of things
that might be wrong").
--
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: service version disclosure
Once upon a time, Reindl Harald said: > but i also know that from "SSH-2.0-OpenSSH_5.8" only "SSH-2.0" > is relevant for clients That's not actually true for SSH. The additional bits can be used to work around known problems with specific versions. -- 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: service version disclosure
Once upon a time, Reindl Harald said: > no, one keys of security is to provide as less informations as > absolutely necessary, not only for sshd, for every single > service That's a key for a false sense of security. > in the best case no single foreign person has an idea > what software you are currently running, not what OS > nor what service-software and at least no exact version Then go ahead cut the power cord. Things such as TCP fingerprinting will always work (because no two IP stacks are identical). Connecting to a service will often be able to identify it because no two programs implement standards the same way. If you think you need that level of security, you need to run a full application-level proxy in front of every server, and then watch it break regularly (because they never get all the application filtering correct). Then wait for the security holes in the proxy. -- 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: service version disclosure
* Reindl Harald [07/01/2012 08:37] : > > however - why do we spit the current running versions to everyone? In the case of openssh, it's to allow the client to work around known bugs in the server. In other cases, it's simply of case of not wanting to patch gratuitously packages. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
