Re: wireless-tools is DEPRECATED

[Petr Pisar]

On 2011-03-26, Xose Vazquez Perez  wrote:
> wireless-tools is deprecated since time ago. iw/rfkill
> should be used instead it.
>
Really? I thought iw can control mac80211 drivers only and not all
wireless drivers have been ported to mac80211 yet
.

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Shared library permissions in Debian-land and Red Hat-land

[Hans de Goede]

Hi,

On 03/28/2011 10:11 PM, Nathaniel McCallum wrote:
> On Mon, 2011-03-28 at 16:05 -0400, Przemek Klosowski wrote:
>> On 03/24/2011 02:49 PM, Kevin Kofler wrote:
>>> On Thursday 24 March 2011, you wrote:
 Hmm, I thought there'd be a catch. What's executable permission needed
 for? Isn't that just reading/parsing? I can do some work but I am
 totally unfamiliar with this area.
>>>
>>> Files which aren't executable aren't even considered as candidates for being
>>> ELF files to extract debuginfo from.
>>>
>>> Without execute permission, you'd have to check EVERY SINGLE installed FILE
>>> for being ELF, that might be a significant performance hit. It'd have to be
>>> tried at least.
>>
>> OK, so executable permission is used as a tag for identifying ELF files.
>> It's a little inelegant because there are some negative side effects
>> from executing those non-executable files.
>>
>> If, hypothetically, we wanted to change that, is there any other way to
>> reliably mark ELF files? I could think of those:
>>
>> - extended  filesystem attributes? works but might be FS-dependent
>> - make the files owned by a special ELF group
>> - a system-level directory of ELF files maintained by e.g. RPM
>
> Well, technically you could still use +x for other non-shared library
> ELF files, you'd just also need to look for .so files.  That seems to me
> the simplest solution and should still be fast since the filename is in
> the directory inode (which you have to read anyway).
>

Note that while discussing things it would be good to fix the long
standing rpm feature of auto generating provides for .so files even though
they are intended for dl-opening only.

Currently rpm needs to know if something is an elf shared object for 2
reasons:

1) To generate debuginfo
2) To generate an auto provides of the soname

If we're going to make changes here I would really to see the heuristic
for 2 changed from is it executable to does it live under /lib[64] or
/usr/lib[64]. This will remove the need to add tons of provides filters
to perl or python packages which contain some native bits.

Yes this will break the provides generation for packages which install
real / normal libraries under a different dir. Well good for them that
moves the pain of dealing with special cases wrt auto Provides to the
special cases, rather then making any packages which has plugins or
other wise dlopen only shared objects deal with it.

Also note that packages installing libraries under a different dir
often do so, because they offer replacement libs for a system
library (ie libGL from the binary nvidia driver from a 3th party repo)
and in this case actually not having the Provides for the soname is
the right thing to do!

Regards,

Hans







-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Shared library permissions in Debian-land and Red Hat-land

[drago01]

On Thu, Mar 24, 2011 at 7:08 PM, Kevin Kofler  wrote:
> Adam Williamson wrote:
>> So, I just ran into an interesting issue talking over Fedora patches
>> with the upstream glew maintainer. glew installs its shared libraries
>> 'manually', not using autotools / libtools; upstream installs them with
>> permissions of 0644, and we patch this to 0755. After talking to
>> upstream, they say they're following Debian conventions here; I don't
>> have a Debian-land system to confirm, but they say on Debian and Ubuntu,
>> all shared libs have 0644 permissions.
>
> This is true. AFAIK, the Debian policy is because those shared libraries
> crash when some idiot tries to run them as programs.

Why does that matter?
They run them notice the crash and learn from it. It is not like
running shared libraries as programs is an every day task.
This is really a fringe corner case and should simply be ignored it is
not worth basing distribution policy around that.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Updated VIPS available

[Rahul Sundaram]

On 03/29/2011 09:29 AM, W. Michael Petullo wrote:
> I am interested in seeing Bugzilla #676945, VIPS package is out of date,
> addressed before Fedora 15 is released. The reason for my interest is that
> one of my packages, dmapd, requires the new version of VIPS. The new VIPS
> provides additional functionality that can be used to efficiently create
> thumbnail images and read existing thumbnails from EXIF metadata.

Looks like packages were built long back but maintainer forgot to push
the update via Bodhi.  Done

Rahul

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Shared library permissions in Debian-land and Red Hat-land

[Miloslav Trmač]

On Tue, Mar 29, 2011 at 10:32 AM, Hans de Goede  wrote:
> If we're going to make changes here I would really to see the heuristic
> for 2 changed from is it executable to does it live under /lib[64] or
> /usr/lib[64]. This will remove the need to add tons of provides filters
> to perl or python packages which contain some native bits.
>
> Yes this will break the provides generation for packages which install
> real / normal libraries under a different dir.
I guess that checking if the package also installs a config file into
/etc/ld.so.conf.d/ and if it does, also checking the directories setup
in the config file, would handle most of these cases.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-File-Slurp] Misc. spec fixes.

[corsepiu]

commit be7d027e0487f82b1151082cc7f9cfbececf163f
Author: Ralf Corsépius 
Date:   Tue Mar 29 14:49:42 2011 +0200

Misc. spec fixes.

 perl-File-Slurp.spec |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)
---
diff --git a/perl-File-Slurp.spec b/perl-File-Slurp.spec
index 75262ac..ddc9328 100644
--- a/perl-File-Slurp.spec
+++ b/perl-File-Slurp.spec
@@ -14,6 +14,8 @@ BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires: perl(Test::Pod::Coverage) >= 1.04
 BuildRequires: perl(Test::Pod) >= 1.14
 
+%{?perl_default_filter}
+
 %description
 This module provides subs that allow you to read or write entire files with
 one simple call. They are designed to be simple to use, have flexible ways
@@ -25,7 +27,10 @@ pseudo-files, and DATA.
 
 %prep
 %setup -q -n File-Slurp-%{version}
-chmod 0644 lib/File/Slurp.pm extras/slurp_bench.pl
+iconv -f iso8859-1 -t UTF-8 Changes > Changes~
+mv Changes~ Changes
+
+find \( -executable -a -type f \) -exec chmod -x {} \;
 %{__perl} -pi -e 's|^#!/usr/local/bin/perl\b|#!%{__perl}|' 
extras/slurp_bench.pl
 
 %build
@@ -51,6 +56,8 @@ make test
 %changelog
 * Tue Mar 29 2011 Ralf Corsépius  - .15-1
 - Upstream update.
+- Add perl_default_filter.
+- Fix encoding of "Changes".
 - Spec cleanup.
 
 * Tue Feb 08 2011 Fedora Release Engineering  
- .13-10
--
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: Shared library permissions in Debian-land and Red Hat-land

[John Reiser]

>> This is true. AFAIK, the Debian policy is because those shared libraries
>> crash when some idiot tries to run them as programs.
> 
> Why does that matter?

Some Debian maintainer(s) got tired of getting bug reports for this case.

> They [the users] run them notice the crash and learn from it. 

It was [is] a resource drain on the project as a whole when the unknowledgeable
user does not think enough before filing a bug report.  Having the shell
give a [localized!] message for ENOEXEC is even instructive.

-- 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: wireless-tools is DEPRECATED

[John W. Linville]

On Tue, Mar 29, 2011 at 07:24:01AM +, Petr Pisar wrote:
> On 2011-03-26, Xose Vazquez Perez  wrote:
> > wireless-tools is deprecated since time ago. iw/rfkill
> > should be used instead it.
> >
> Really? I thought iw can control mac80211 drivers only and not all
> wireless drivers have been ported to mac80211 yet
> .

Yes, sadly, that is correct.

John
-- 
John W. LinvilleThe truth will set you free, but first it will
linvi...@redhat.com make you miserable. -- James A. Garfield
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bugs in debuginfo packages

[Mark Wielaard]

On Mon, 2011-03-28 at 16:55 +0200, Karel Klíč wrote:
> Mark Wielaard  writes:
> > eu-readelf does a lot more than you seem to need (you want to at least
> > use --numeric-addresses, so it doesn't try to map all addresses it
> > prints out to the associated symbol names).
> >
> > Attached is a little C program that just gets the associated source
> > files and nothing else. It might help go through the whole repository
> > quicker. It simply goes through all Compile Units, prints the comp_dir
> > and name, and then everything from the associated files table.
> 
> thank you for the program, I'll use it to speed up the check.

Please let me know if I can help in any way, or if there are other
places in your script that rely on eu-readelf output parsing that could
use some speed up.

> I'm also going to verify how well .debug_info sections match the source
> files included in debuginfo packages using `eu-readelf -winfo` data
> (-wline checking would be too complicated for this script). I have
> observed GDB displaying wrong source file lines when stepping through a
> program several times, and I think such a check could discover some
> issues.

I am not exactly sure what you are thinking of here. Could you give an
example of what you would be looking for and how that would be wrong?

We are working on a dwarflint tool, which is somewhat lower level (deals
only with the .debug_* sections in the ELF files directly, not with any
higher level cross file/package things) that might be able to detect
some things. It isn't currently finished, but we hope to polish it for
f16. See https://fedorahosted.org/elfutils/wiki/DwarfLint

Maybe it could be combined with your scans over all packages somehow to
produce reports on "the health of debuginfo in Fedora"?

Thanks,

Mark

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-LWP-Protocol-https] Disable tests because they need network access

[Petr Pisar]

commit 2994349c276eb8955b861a00cbaf8a2881ecf3be
Author: Petr Písař 
Date:   Tue Mar 29 16:27:24 2011 +0200

Disable tests because they need network access

 perl-LWP-Protocol-https.spec |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)
---
diff --git a/perl-LWP-Protocol-https.spec b/perl-LWP-Protocol-https.spec
index ff9ad3d..d59f7aa 100644
--- a/perl-LWP-Protocol-https.spec
+++ b/perl-LWP-Protocol-https.spec
@@ -1,6 +1,7 @@
+%bcond_with tests # Tests require network access
 Name:   perl-LWP-Protocol-https
 Version:6.02
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Provide HTTPS support for LWP::UserAgent
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -8,12 +9,14 @@ URL:
http://search.cpan.org/dist/LWP-Protocol-https/
 Source0:
http://www.cpan.org/authors/id/G/GA/GAAS/LWP-Protocol-https-%{version}.tar.gz
 BuildArch:  noarch
 BuildRequires:  perl(ExtUtils::MakeMaker)
+%if %{with tests}
 # Tests:
 BuildRequires:  perl(IO::Socket::SSL) >= 1.38
 BuildRequires:  perl(LWP::Protocol::http)
 BuildRequires:  perl(LWP::UserAgent) >= 6.02
 BuildRequires:  perl(Mozilla::CA) >= 20110101
 BuildRequires:  perl(Net::HTTPS) >= 6
+%endif
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 Requires:   perl(IO::Socket::SSL) >= 1.38
 Requires:   perl(LWP::UserAgent) >= 6.02
@@ -44,7 +47,7 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2>/dev/null \;
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-make test
+%{?with_tests:make test}
 
 %files
 %defattr(-,root,root,-)
@@ -53,6 +56,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Mar 29 2011 Petr Pisar  - 6.02-2
+- Disable tests because they need network access
+
 * Mon Mar 28 2011 Petr Pisar  6.02-1
 - Specfile autogenerated by cpanspec 1.78.
 - Remove BuildRoot stuff
--
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

mpich2 soname bump

[Deji Akingunola]

Hi all,

In the process of releasing a bug-fix update to mpich2-1.3.x series,
the upstream developers encountered an error that had to be fixed but
would change the ABI version. Therefore, to avoid ABI incompatible
changes in the 1.3.x series, the 1.3.3 release was cancelled and
renaming that to 1.4 instead.

I know this is late in Fedora 15 development cycle, but I will like to
squeeze mpich2-1.4 in so we can continue to receive fixes and update
to mpich2's new process manager.

I will apply for commit access to dependent packages for which I don't
already have access. The list of affected packages includes;
blacs
boost
gromacs
hdf5
mpi4py
orsa
paraview
pypar
scalapack
scotch
towhee


Cheers,
Deji
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for f14?

[Kevin Kofler]

Genes MailLists wrote:
> Some have argued that fedora itself is a rolling release - others
> look for something more closely resembling the kernel dev model (there
> are some differences between kernel dev and distro however ... tho more
> in detail than idea)

And others (like me) look for something more closely resembling how Fedora 
used to work, how the kernel used to work before the stable subbranches were 
introduced or how the KDE 3.5.x branch worked: a release branch with some 
expectations of stability and compatibility, but with a relaxed freeze 
policy.

And no, I do not believe that those goals are necessarily incompatible. They 
can be conflicting at times, but the maintainer should be able to make an 
informed call of whether the update is welcome or unwelcome in a stable 
distribution. I believe that in most cases, the decision is obvious. (That 
said, not everyone agrees with me on that.)

If you want to read or reread the discussions on that subject, search the 
mailing list archives.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: gtkpod version 2 spec file

[Kevin Kofler]

phantomjinx wrote:
> Since I uploaded gtkpod version 2 to sourceforge, I thought it would be
> helpful if I made available my unstable build version of the gtkpod spec
> file to the fedora package maintainers. Anyway, please find it attached
> and I hope its useful. I am quite happy to develop it further myself but
> I am relatively new to rpm building so it would take a while.

* %{REVISION} isn't defined anywhere in the specfile.
* Please update the %changelog when you make changes to a specfile.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: manually fixing IPs

[Adam Williamson]

On Tue, 2011-03-29 at 02:35 -0400, Jon Masters wrote:

> For clarification, I usually do have NM_CONTROLLED set for every
> interface, except on laptops. In this case, I just wanted to instead
> turn off NetworkManager and configure the interface manually. I see no
> reason why it shouldn't be possible to tell a system service to stop and
> expect it to stay stopped until I turn it back on again. That way, I can
> tell NM to shutdown, do something I need to do, then get the prettified
> laptop experience back again when I'm done (on the netbook).
> 
> This was all to tftp various firmwares over to routers I was playing
> with over the weekend. Soldering surface mount bits, placing wires, and
> poking at serial consoles and firmware setup was trivial. The hardest
> bit was telling a system service to stay stopped :)

If just stopping it with 'systemctl stop NetworkManager.service' didn't
do the job, I would imagine you were running up against systemd's bus
activation feature; when something tried to poke NM via dbus, systemd
would fire it up. Lennart may be able to suggest how you can avoid this,
if it's possible.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File Perl-Critic-StricterSubs-0.03.tar.gz uploaded to lookaside cache by ppisar

[Petr Pisar]

A file has been added to the lookaside cache for perl-Perl-Critic-StricterSubs:

f92c089422f7eea8d51c542997d351c1  Perl-Critic-StricterSubs-0.03.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: manually fixing IPs

[Lennart Poettering]

On Tue, 29.03.11 10:12, Adam Williamson (awill...@redhat.com) wrote:

> 
> On Tue, 2011-03-29 at 02:35 -0400, Jon Masters wrote:
> 
> > For clarification, I usually do have NM_CONTROLLED set for every
> > interface, except on laptops. In this case, I just wanted to instead
> > turn off NetworkManager and configure the interface manually. I see no
> > reason why it shouldn't be possible to tell a system service to stop and
> > expect it to stay stopped until I turn it back on again. That way, I can
> > tell NM to shutdown, do something I need to do, then get the prettified
> > laptop experience back again when I'm done (on the netbook).
> > 
> > This was all to tftp various firmwares over to routers I was playing
> > with over the weekend. Soldering surface mount bits, placing wires, and
> > poking at serial consoles and firmware setup was trivial. The hardest
> > bit was telling a system service to stay stopped :)
> 
> If just stopping it with 'systemctl stop NetworkManager.service' didn't
> do the job, I would imagine you were running up against systemd's bus
> activation feature; when something tried to poke NM via dbus, systemd
> would fire it up. Lennart may be able to suggest how you can avoid this,
> if it's possible.

http://0pointer.de/blog/projects/three-levels-of-off

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Perl-Critic-StricterSubs] Import

[Petr Pisar]

commit 189583efe130c090f939dc360493c0ca087c8765
Author: Petr Písař 
Date:   Tue Mar 29 19:14:56 2011 +0200

Import

 .gitignore |1 +
 perl-Perl-Critic-StricterSubs.spec |   62 
 sources|1 +
 3 files changed, 64 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..04a01bc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Perl-Critic-StricterSubs-0.03.tar.gz
diff --git a/perl-Perl-Critic-StricterSubs.spec 
b/perl-Perl-Critic-StricterSubs.spec
new file mode 100644
index 000..ce9a7f7
--- /dev/null
+++ b/perl-Perl-Critic-StricterSubs.spec
@@ -0,0 +1,62 @@
+Name:   perl-Perl-Critic-StricterSubs
+Version:0.03
+Release:1%{?dist}
+Summary:Perl::Critic plugin for stricter subroutine checks
+License:GPL+ or Artistic
+Group:  Development/Libraries
+URL:http://search.cpan.org/dist/Perl-Critic-StricterSubs/
+Source0:
http://www.cpan.org/authors/id/T/TH/THALJEF/strictersubs/Perl-Critic-StricterSubs-%{version}.tar.gz
+BuildArch:  noarch
+BuildRequires:  perl(Exporter)
+BuildRequires:  perl(File::PathList)
+BuildRequires:  perl(Module::Build)
+BuildRequires:  perl(Perl::Critic) >= 1.08
+BuildRequires:  perl(Perl::Critic::Policy)
+BuildRequires:  perl(Perl::Critic::TestUtils) >= 1.08
+BuildRequires:  perl(Perl::Critic::Utils) >= 1.08
+BuildRequires:  perl(Perl::Critic::Violation) >= 1.08
+BuildRequires:  perl(PPI::Document)
+# Non-author tests only:
+BuildRequires:  perl(Test::Pod) >= 1.00
+BuildRequires:  perl(Test::Pod::Coverage) >= 1.04
+# Only in META.yml, RT#66863: BuildRequires:  perl(Test::Deep)
+BuildRequires:  perl(Test::More)
+Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+Requires:   perl(Perl::Critic) >= 1.08
+Requires:   perl(Perl::Critic::TestUtils) >= 1.08
+Requires:   perl(Perl::Critic::Utils) >= 1.08
+Requires:   perl(Perl::Critic::Violation) >= 1.08
+
+%description
+As a dynamic language, Perl doesn't require you to define subroutines until
+run-time. Although this is a powerful feature, it can also be a major
+source of bugs. For example, you might mistype the name of a subroutine, or
+call a subroutine from another module without including that module or
+importing that subroutine. And unless you have very good test coverage, you
+might not know about these bugs until you have already launched your code.
+
+%prep
+%setup -q -n Perl-Critic-StricterSubs-%{version}
+
+%build
+%{__perl} Build.PL installdirs=vendor
+./Build
+
+%install
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+./Build test
+
+%files
+%defattr(-,root,root,-)
+%doc Changes LICENSE README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Thu Mar 24 2011 Petr Pisar  0.03-1
+- Specfile autogenerated by cpanspec 1.78.
+- Remove BuildRoot stuff
diff --git a/sources b/sources
index e69de29..d28e6ab 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+f92c089422f7eea8d51c542997d351c1  Perl-Critic-StricterSubs-0.03.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

KDE-SIG meeting report (13/2011)

[Jaroslav Reznik]

This is a report of the weekly KDE-SIG-Meeting with a summary of the
topics that were discussed. If you want to add a comment please reply
  to this email or add it to the related meeting page.

= Weekly KDE Summary =

Week: 13/2011

Time: 2011-03-29 15:00 UTC

Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-03-29

Meeting minutes: http://meetbot.fedoraproject.org/fedora-meeting/2011-03-29/kde-
sig.2011-03-29-15.01.html 

Meeting log: http://meetbot.fedoraproject.org/fedora-meeting/2011-03-29/kde-
sig.2011-03-29-15.01.log.html


= Participants =
* Kevin Kofler
* Jaroslav Reznik
* Lukas Tinkl
* Than Ngo
* Radek Novacek


= Agenda =
topics to discuss:
* NM 0.9 status
* f14/kde46 status update, [[SIGs/KDE/KDE46_for_Fedora_14]]
* F15 artwork status
recent bugs:
* https://bugzilla.redhat.com/show_bug.cgi?id=683855

= Summary =
== Summary ==
f14/kde46 status update
* we have two remaining F14 bugs - auto-unhide bug and kdebindings build issue 
(not reported upstream yet)
** https://bugzilla.redhat.com/show_bug.cgi?id=690450 auto-unhide annoyances, 
proposed patch attached to the upstream bug report, we should apply it 
** https://bugzilla.redhat.com/show_bug.cgi?id=684419 pykdeuic4 breakage
* ACTION: jreznik to try to build kdebase-workspace with auto-unhide patch
* ACTION: Kevin_Kofler to report kdebindings/PyQt 4.8 issue upstream

NM 0.9 status
* grouped NM update including KDE patches got pushed
* Kevin_Kofler restored VPN subpackage split (as can be found in NM)

F15 artwork status
* jreznik prepared kde-lovelock-theme for F15 to match current wp
* karma (and testing of course) is needed, see attached link

Bug #683855 -  gtk unthemed (ugly) when gnome-themes-standard not present
https://bugzilla.redhat.com/show_bug.cgi?id=683855#c2

= Next Meeting =
http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-04-05

= Links =
[1] https://bugzilla.redhat.com/show_bug.cgi?id=683855
-- 
Jaroslav Řezník 
Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc.   http://cz.redhat.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: gtkpod version 2 spec file

[phantomjinx]

On 29/03/11 17:42, Kevin Kofler wrote:
> phantomjinx wrote:
>
>> Since I uploaded gtkpod version 2 to sourceforge, I thought it would be
>> helpful if I made available my unstable build version of the gtkpod spec
>> file to the fedora package maintainers. Anyway, please find it attached
>> and I hope its useful. I am quite happy to develop it further myself but
>> I am relatively new to rpm building so it would take a while.
>>  
> * %{REVISION} isn't defined anywhere in the specfile.
> * Please update the %changelog when you make changes to a specfile.
>
>  Kevin Kofler
>
>
Thanks Kevin,

This spec file has come from a bash script so the revision was added 
through rpmbuild -r 2.0.0.

Certainly, I will update the changelog if I work on it but I wasnt sure 
if I should or whether someonelse would take it on.

I think I need to split it as rpmlint has quite a few warnings.

Cheers

Paul (a.k.a. phantomjinx)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Axel Thimm: Unresponsive maintainer?

[Stephen John Smoogen]

On Mon, Mar 28, 2011 at 18:00, Kurt Seifried  wrote:
>> Who? I need help on them for the new mediawiki packages.
>
> I'm more than willing to help, the mediawiki packages appear to have
> about a half dozen outstanding security bugs =(.

Ouch email me what ones and I will get cracking on them.

>> --
>> Stephen J Smoogen.
>
> --
> Kurt Seifried
> k...@seifried.org
> skype: 1-703-879-3176
> --
> 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

Plan for tomorrow's FESCo meeting (2011-03-30)

[Kevin Fenzi]

Following is the list of topics that will be discussed in the FESCo
meeting tomorrow at 17:30UTC (1:30pm EDT) in #fedora-meeting on
irc.freenode.net. 

Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #515 Investigate a "features" repo for stable releases
.fesco 515

#topic #517 Updates Metrics
.fesco 517

#563 suggested policy: all daemons must set RELRO and PIE flags
.fesco 563

= New business =

#576 Encourage to be package maintainers to introduce themselves in devel list
.fesco 576

#577 FHS exception for Heimdal
.fesco 577

= Fedora Engineering Services tickets = 

https://fedorahosted.org/fedora-engineering-services/report/6

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Beta change freeze

[Dennis Gilmore]

Hi All a heads up that change freeze for the Fedora 15 Beta is Tuesday April 
5th.  after this point only accepted blocker bugs will be pulled in.  Please 
limit your changes to try and avoid unintended breakages.


thanks

Dennis


signature.asc
Description: This is a digitally signed message part.
___
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: manually fixing IPs

[Ian Pilcher]

On 03/29/2011 12:14 PM, Lennart Poettering wrote:
> http://0pointer.de/blog/projects/three-levels-of-off

Any ideas why this is happening?

[pilcher@ian ~]$ systemctl is-enabled bluetooth.service && echo ENABLED
[pilcher@ian ~]$ systemctl status bluetooth.service
bluetooth.service - Bluetooth Manager
  Loaded: loaded (/lib/systemd/system/bluetooth.service)
  Active: active (running) since Tue, 29 Mar 2011 09:16:39
-0500; 5h 4min ago
Main PID: 2140 (bluetoothd)
  CGroup: name=systemd:/system/bluetooth.service
  └ 2140 /usr/sbin/bluetoothd -n

(And, yes, I've rebooted many times since disabling it.)

-- 

Ian Pilcher arequip...@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: manually fixing IPs

[Lennart Poettering]

On Tue, 29.03.11 14:23, Ian Pilcher (arequip...@gmail.com) wrote:

> On 03/29/2011 12:14 PM, Lennart Poettering wrote:
> > http://0pointer.de/blog/projects/three-levels-of-off
> 
> Any ideas why this is happening?
> 
> [pilcher@ian ~]$ systemctl is-enabled bluetooth.service && echo ENABLED
> [pilcher@ian ~]$ systemctl status bluetooth.service
> bluetooth.service - Bluetooth Manager
>   Loaded: loaded (/lib/systemd/system/bluetooth.service)
>   Active: active (running) since Tue, 29 Mar 2011 09:16:39
> -0500; 5h 4min ago
> Main PID: 2140 (bluetoothd)
>   CGroup: name=systemd:/system/bluetooth.service
>   └ 2140 /usr/sbin/bluetoothd -n
> 
> (And, yes, I've rebooted many times since disabling it.)

Please paste "systemctl show bluetooth.service", which should tell us
what pulled it in.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Bluetooth service - was manually fixing IPs

[Ian Pilcher]

On 03/29/2011 02:31 PM, Lennart Poettering wrote:
> Please paste "systemctl show bluetooth.service", which should tell us
> what pulled it in.

Here it is.

Id=bluetooth.service
Names=bluetooth.service
Requires=systemd-logger.socket dbus.target basic.target
Conflicts=shutdown.target
Before=shutdown.target
After=syslog.target systemd-logger.socket dbus.target basic.target
Description=Bluetooth Manager
LoadState=loaded
ActiveState=active
SubState=running
FragmentPath=/lib/systemd/system/bluetooth.service
InactiveExitTimestamp=Tue, 29 Mar 2011 09:16:39 -0500
ActiveEnterTimestamp=Tue, 29 Mar 2011 09:16:39 -0500
CanStart=yes
CanStop=yes
CanReload=no
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=yes
DefaultControlGroup=name=systemd:/system/bluetooth.service
ControlGroup=cpu:/system/bluetooth.service
name=systemd:/system/bluetooth.service
NeedDaemonReload=no
JobTimeoutUSec=0
Type=dbus
Restart=no
NotifyAccess=none
RestartUSec=100ms
TimeoutUSec=3min
ExecStart={ path=/usr/sbin/bluetoothd ; argv[]=/usr/sbin/bluetoothd -n ;
ignore=no ; start_time=[Tue, 29 Mar 2011 09:16:39 -0500] ; stop_time=[n/a
UMask=0002
LimitCPU=18446744073709551615
LimitFSIZE=18446744073709551615
LimitDATA=18446744073709551615
LimitSTACK=18446744073709551615
LimitCORE=18446744073709551615
LimitRSS=18446744073709551615
LimitNOFILE=1024
LimitAS=18446744073709551615
LimitNPROC=59941
LimitMEMLOCK=65536
LimitLOCKS=18446744073709551615
LimitSIGPENDING=59941
LimitMSGQUEUE=819200
LimitNICE=0
LimitRTPRIO=0
LimitRTTIME=18446744073709551615
OOMScoreAdjust=0
Nice=0
IOScheduling=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=5
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=syslog
StandardError=inherit
SyslogPriority=30
SyslogLevelPrefix=yes
SecureBits=0
CapabilityBoundingSetDrop=0
MountFlags=1048576
PrivateTmp=no
SameProcessGroup=no
KillMode=control-group
KillSignal=15
PermissionsStartOnly=no
RootDirectoryStartOnly=no
RemainAfterExit=no
GuessMainPID=yes
ExecMainStartTimestamp=Tue, 29 Mar 2011 09:16:39 -0500
ExecMainExitTimestamp=Tue, 29 Mar 2011 09:16:39 -0500
ExecMainPID=2140
ExecMainCode=0
ExecMainStatus=0
MainPID=2140
ControlPID=0
BusName=org.bluez
SysVStartPriority=-1
FsckPassNo=0

-- 

Ian Pilcher arequip...@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bluetooth service - was manually fixing IPs

[Lennart Poettering]

On Tue, 29.03.11 14:39, Ian Pilcher (arequip...@gmail.com) wrote:

> On 03/29/2011 02:31 PM, Lennart Poettering wrote:
> > Please paste "systemctl show bluetooth.service", which should tell us
> > what pulled it in.
> 
> Here it is.
> 
> Id=bluetooth.service
> Names=bluetooth.service
> Requires=systemd-logger.socket dbus.target basic.target
> Conflicts=shutdown.target
> Before=shutdown.target
> After=syslog.target systemd-logger.socket dbus.target basic.target

It's not pulled in by anything at all according to this, so the
disabling worked.

Maybe something started it manually?

Try to boot with "systemd.log_level=debug systemd.log_target=kmsg
log_buf_len=2M" on the kernel cmdline. Then keep an eye on dmesg, look
for "bluetooth.service" being mentioned. If you find something, tell me
and paste those lines and the context around it and I might be able to
tell you what activated it.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bluetooth service - was manually fixing IPs

[Ian Pilcher]

On 03/29/2011 02:44 PM, Lennart Poettering wrote:
> Maybe something started it manually?

Looks like it happens when I log in to KDE.

I assume this means that KDE isn't using D-BUS to start the service,
right?  If it were, disabling it with systemctl would have worked.

Thanks!

-- 

Ian Pilcher arequip...@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 691451] Rebuild required to work correctly with perl 5.012003.

[bugzilla]

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=691451

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA

--- Comment #2 from Fedora Update System  2011-03-29 
15:51:26 EDT ---
Package perl-Devel-Cover-0.66-2.fc14:
* should fix your issue,
* was pushed to the Fedora 14 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing perl-Devel-Cover-0.66-2.fc14'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/perl-Devel-Cover-0.66-2.fc14
then log in and leave karma (feedback).

-- 
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: Bluetooth service - was manually fixing IPs

[Lennart Poettering]

On Tue, 29.03.11 14:54, Ian Pilcher (arequip...@gmail.com) wrote:

> 
> On 03/29/2011 02:44 PM, Lennart Poettering wrote:
> > Maybe something started it manually?
> 
> Looks like it happens when I log in to KDE.
> 
> I assume this means that KDE isn't using D-BUS to start the service,
> right?  If it were, disabling it with systemctl would have worked.

I have no idea what KDE does.

If it really manually runs "systemctl start bluetooth.service" (or
"/sbin/service bluetooth start") then the KDE folks should stop doing
that. They should respect system configuration, and not manually start
something the admin explicitly didn't want to get started.

Can you paste the kmsg context of the starting please?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[389-devel] Please review: Bug 668385 - DS pipe log script is executed as many times as the dirsrv service is restarted

[Rich Megginson]

https://bugzilla.redhat.com/show_bug.cgi?id=668385

https://bugzilla.redhat.com/attachment.cgi?id=488552&action=diff

https://bugzilla.redhat.com/attachment.cgi?id=488552&action=edit
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

[Bug 676688] Upgrade to version 8.3

[bugzilla]

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=676688

Jerry James  changed:

   What|Removed |Added

 Depends on||691896

-- 
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.
___
ocaml-devel mailing list
ocaml-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel

[Bug 631302] FTBFS coq-8.2pl1-1.fc12

[bugzilla]

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=631302

Jerry James  changed:

   What|Removed |Added

 Depends on||691896

-- 
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.
___
ocaml-devel mailing list
ocaml-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel

[Bug 691896] gas: .size expression does not evaluate to a constant

[bugzilla]

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=691896

Jakub Jelinek  changed:

   What|Removed |Added

 CC||fedora-ocaml-l...@redhat.co
   ||m, rjo...@redhat.com
  Component|binutils|ocaml
 AssignedTo|ni...@redhat.com|rjo...@redhat.com

--- Comment #1 from Jakub Jelinek  2011-03-29 16:21:32 EDT ---
Manual inspection has been insufficient then.  You have:
   .text
...
.L124:  callcaml_call_gc@PLT
.L125:  jmp .L123
.section.rodata.cst8,"a",@progbits
.L122:  .quad   0x4000
.type   camlSegmenttree__log2_1037,@function
.size   camlSegmenttree__log2_1037,.-camlSegmenttree__log2_1037
.text
thus obviously the size can't be constant, as . in the size expression
is in .rodata.cst8 section (in particular .L122+8), while
camlSegmenttree__log2_1037 is in .text section.

-- 
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.
___
ocaml-devel mailing list
ocaml-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel

[Bug 691896] gas: .size expression does not evaluate to a constant

[bugzilla]

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=691896

Stéphane Glondu  changed:

   What|Removed |Added

 CC||st...@glondu.net

--- Comment #2 from Stéphane Glondu  2011-03-29 16:24:18 EDT 
---
See http://caml.inria.fr/mantis/view.php?id=5237

-- 
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.
___
ocaml-devel mailing list
ocaml-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel

Re: Bluetooth service - was manually fixing IPs

[Ian Pilcher]

On 03/29/2011 03:01 PM, Lennart Poettering wrote:
> Can you paste the kmsg context of the starting please?

[   42.087581] systemd[1]: Got D-Bus activation request for
bluetooth.service
[   42.099029] systemd[1]: Trying to enqueue job
bluetooth.service/start/replace
[   42.099342] systemd[1]: Installed new job bluetooth.service/start as 382
[   42.099351] systemd[1]: Enqueued job bluetooth.service/start as 382
[   42.099407] systemd[1]: About to execute: /usr/sbin/bluetoothd -n
[   42.112528] systemd[1]: Forked /usr/sbin/bluetoothd as 2103
[   42.112627] systemd[1]: bluetooth.service changed dead -> start
[   42.168637] bluetoothd[2103]: bluetoothd[2103]: Bluetooth deamon 4.87
[   42.183808] systemd[1]: Got D-Bus request:
org.freedesktop.DBus.NameOwnerChanged() on /org/freedesktop/DBus
[   42.184485] systemd[1]: Got D-Bus request:
org.freedesktop.DBus.NameOwnerChanged() on
/org/freedesktop/DBusbluetoothd[2103]: bluetoothd[2103]:
Starting SDP server
[   42.184491]
[   42.184496] systemd[1]: bluetooth.service's D-Bus name org.bluez now
registered by :1.23
[   42.184528] systemd[1]: bluetooth.service changed start -> running
[   42.184536] systemd[1]: Job bluetooth.service/start finished, result=done

So it looks like it is being started via D-BUS, even though the service
is disabled.  (I just re-re-re-verified that.)

-- 

Ian Pilcher arequip...@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F-15 Branched report: 20110329 changes

[Branched Report]

Compose started at Tue Mar 29 13:16:36 UTC 2011

Broken deps for x86_64
--
balsa-2.4.9-5.fc15.x86_64 requires libnm-glib.so.2()(64bit)
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Ograph2way) = 
0:7442f647b0a74ed48a5c9361fc42ccc4
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Flag) = 
0:522d7f86f1236405e53271ff74923515
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Osetb) = 
0:8f21a0a4f771662673604ed92a237d79
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Oassocb) = 
0:d873c4a1eeb6fa5c5333f8658c49d1db
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Setb) = 
0:93bdb588146a13126bfad4eab6c58206
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Oassoc_buffer) = 
0:cf6fbee4fcc6644a0a90f07da8eb6c7b
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Mapb) = 
0:617c09a110cef9f040335b35078c7234
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Sexplib) = 
0:a990ea80438337d5407bbc0343c7236a
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Dumper) = 
0:76126ba149caeb2d34f12e11187a9d4e
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Oassoch) = 
0:87f7dc2635e5a7ed1ab03b7cd5380ace
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(SetPt) = 
0:b69c030e8ca717d556d3d9bd2a5d22fd
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(ANSITerminal) = 
0:3d0d1700618d8b3a4e4b2308f28cefb6
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Oseti) = 
0:a937e7661f510c17bfd21d4372507795
conmux-0.0-12.493svn.fc15.noarch requires perl(Payload)
conmux-0.0-12.493svn.fc15.noarch requires perl(Client)
cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit)
db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0
dbmail-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit)
dbmail-auth-ldap-3.0.0-0.3.rc1.fc15.x86_64 requires 
libevent-1.4.so.2()(64bit)
dh-make-0.55-3.fc15.noarch requires debhelper
dogtag-pki-1.3.0-2.fc13.noarch requires dogtag-pki-ca-ui
dogtag-pki-1.3.0-2.fc13.noarch requires dogtag-pki-tps-ui
dogtag-pki-1.3.0-2.fc13.noarch requires dogtag-pki-common-ui
dogtag-pki-1.3.0-2.fc13.noarch requires dogtag-pki-ra-ui
dogtag-pki-1.3.0-2.fc13.noarch requires dogtag-pki-console-ui
dogtag-pki-1.3.0-2.fc13.noarch requires dogtag-pki-ocsp-ui
dogtag-pki-1.3.0-2.fc13.noarch requires dogtag-pki-kra-ui
dogtag-pki-1.3.0-2.fc13.noarch requires dogtag-pki-tks-ui
drupal-service_links-6.x.2.0-2.fc15.noarch requires drupal >= 0:6.0
drupal-workspace-6.x.1.4-2.rc1.fc15.1.noarch requires drupal >= 0:6.0
drupal6-advanced-help-1.2-3.fc15.noarch requires drupal >= 0:6.0
drupal6-flexifilter-1.2-2.fc15.noarch requires drupal >= 0:6.0
drupal6-footnotes-2.5-2.fc15.noarch requires drupal >= 0:6.0
eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit)
1:fife-0.3.2-1.fc15.i686 requires libboost_regex.so.1.44.0
1:fife-0.3.2-1.fc15.i686 requires libboost_system.so.1.44.0
1:fife-0.3.2-1.fc15.i686 requires libboost_filesystem.so.1.44.0
1:fife-0.3.2-1.fc15.x86_64 requires libboost_regex.so.1.44.0()(64bit)
1:fife-0.3.2-1.fc15.x86_64 requires libboost_system.so.1.44.0()(64bit)
1:fife-0.3.2-1.fc15.x86_64 requires 
libboost_filesystem.so.1.44.0()(64bit)
file-browser-applet-0.6.6-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::ScrolledWindow)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Dialog)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Toolbar)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::TreeView)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MenuBar)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::VBox)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Window)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MessageDialog)
glom-1.16.1-2.fc15.x86_64 requires libgdamm-4.0.so.12()(64bit)
glom-libs-1.16.1-2.fc15.i686 requires libgdamm-4.0.so.12
glom-libs-1.16.1-2.fc15.x86_64 requires libgdamm-4.0.so.12()(64bit)
glunarclock-0.34.1-1.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-cpufire-1.6-3.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-music-2.5.1-5.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0
gnome-applet-senso

[Test-Announce] Fedora 15 Beta TC1 Available Now!

[Andre Robatino]

Fedora 15 Beta TC1 is now available [1].  Please refer to the following
pages for download links and testing instructions.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Ideally, all Alpha and Beta priority test cases for installation [2] and
desktop [3] should pass in order to meet the Beta Release Criteria [4].
 Help is available on #fedora-qa on irc.freenode.net [5], or on the test
list [6].

[1] http://rbergero.fedorapeople.org/schedules/f-15/f-15-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[3] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
[4] https://fedoraproject.org/wiki/Fedora_15_Beta_Release_Criteria
[5] irc://irc.freenode.net/fedora-qa
[6] https://admin.fedoraproject.org/mailman/listinfo/test



signature.asc
Description: OpenPGP digital signature
___
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

Re: Bluetooth service - was manually fixing IPs

[Michal Schmidt]

On Tue, 29 Mar 2011 17:34:39 -0500 Ian Pilcher wrote:
> On 03/29/2011 03:01 PM, Lennart Poettering wrote:
> > Can you paste the kmsg context of the starting please?
> 
> [   42.087581] systemd[1]: Got D-Bus activation request for
> bluetooth.service

The bluez D-Bus service activates bluetooth.service directly.
See /usr/share/dbus-1/system-services/org.bluez.service:
  ...
  SystemdService=bluetooth.service

Compare this with org.freedesktop.NetworkManager.service which uses an
indirect alias that can be enabled/disabled by systemctl:
  SystemdService=dbus-org.freedesktop.NetworkManager.service

This was discussed in February on systemd-devel:
http://lists.freedesktop.org/archives/systemd-devel/2011-February/001384.html

Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Compiz crashes after plugging in external monitor

[valent.turko...@gmail.com]

On Tue, Mar 29, 2011 at 12:56 PM, valent.turko...@gmail.com
 wrote:
>>
>> Thanks Marko,
>> glad to see compiz working for you. In the meanwhile I found this bug
>> already reported:
>> https://bugzilla.redhat.com/show_bug.cgi?id=653085
>>
>> So anybody please join in if you have this issue also to that we can
>> help developers fix it easier.
>>
>> Cheers,
>> Valent.
>>
>
> Is there anybody else using compiz and external monitors without
> problems? If so please reply so we can faster troubleshoot this bug.
>
> Thanks.

After further testing it looks like compiz crashes only when both
monitors are active, if you configure xrandr to enable only external
monitor and to disable laptop screen then compiz works without
problems.

I'm not X.org or Intel driver expert by far, but this feels more like
an intel driver issue than compiz bug.

Do you have any suggestion what I can do to help troubleshoot this
issue further?

Cheers,
Valent.



-- 
follow me - www.twitter.com/valentt & http://kernelreloaded.blog385.com
linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave
ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel