Re: Review swap

[T.C. Hollingsworth]

On Thu, Apr 18, 2013 at 3:04 PM, Lokesh Mandvekar  wrote:
> I'd like to offer a review swap.

I've taken both.  In return, you may choose from:

https://bugzilla.redhat.com/show_bug.cgi?id=894724
https://bugzilla.redhat.com/show_bug.cgi?id=921847
https://bugzilla.redhat.com/show_bug.cgi?id=953699
https://bugzilla.redhat.com/show_bug.cgi?id=953701

Thanks!
-T.C.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Login to Koji

[Mathieu Bridon]

On Thu, 2013-04-18 at 15:05 -0600, Kevin Fenzi wrote:
> On Thu, 18 Apr 2013 11:17:13 -0700 (PDT)
> Ravindra Kumar  wrote:
> 
> > Hi, 
> > 
> > I have setup my certificate today using "fedora-packager-setup".
> > However, when I try to login to https://koji.fedoraproject.org/koji/
> > after importing "fedora-browser-cert.p12" into Firefox, it keeps
> > timing out. 
> > 
> > I have tried with Firefox 19.0.2 on Windows and 17.0.1 on Fedora 18. 
> > 
> > Any ideas what could be the problem? 
> 
> Others have reported this in the past. 
> 
> However, it's not worth debugging. 
> 
> There's no reason you ever need to login to the web interface, so just
> don't bother and move on. ;) 
> 
> We are adjusting anything that tells you you need to set this up. 
> Where did you see it? From fedora-packager-setup? 

The Koji web interface still has a "login" button, maybe it should be
removed completely?


-- 
Mathieu

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

Re: [Test-Announce] Fedora 19 Alpha Release Candidate 4 (RC4) Available Now!

[Phil Dobbin]

On 04/17/2013 02:35 PM, Andre Robatino wrote:

> NOTE: All DVD and Live images except KDE Live and SoaS Live are still
> oversize (as they have been since 19 Alpha TC3).
> 
> As per the Fedora 19 schedule [1], Fedora 19 Alpha Release Candidate 4
> (RC4) is now available for testing. Content information, including
> changes, can be found at
> https://fedorahosted.org/rel-eng/ticket/5545#comment:25 . Please see the
> following pages for download links (including delta ISOs) and testing
> instructions. Normally dl.fedoraproject.org should provide the fastest
> download, but download-ib01.fedoraproject.org is available as a mirror
> (with an approximately 1 hour lag) in case of trouble. To use it, just
> replace "dl" with "download-ib01" in the download URL.

[snip for brevity]

19 Alpha RC4 _x86_64 net install with Gnome Desktop installs no problem
on Fedora 17 KVM on a dual-core 2GHz with 2GB RAM.

Took a while & the 'Green Screen of Nearly Death' on boot & shutdown was
particularly tedious but I put that down mostly to the paucity of the
RAM. Desktop is pretty slow but better than your average Live CD.

Cheers,

  Phil...

-- 
currently (ab)using
CentOS 5.9 & 6.4, Debian Squeeze & Wheezy, Fedora Beefy & Spherical,
Lubuntu 12.10, OpenSuSE 12.3, OS X Snow Leopard & Ubuntu Precise & Quantal
GnuPG Key : http://www.horse-latitudes.co.uk/publickey.asc


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

Re: Expanding the list of "Hardened Packages"

[Chris Adams]

Once upon a time, Richard W.M. Jones  said:
> Whatever you think.  But it means you can't just write:
> 
>   $dom = Sys::Virt->get_domain_by_name ("foo");
>   $g = Sys::Guestfs->create ();
>   $g->add_libvirt_domain ($dom);

And that has nothing to do with what you said, languages being able (or
not) to pass pointers.  That's the API of the two modules not supporting
what you want to do.  I'm pretty sure the APIs of the modules could be
changed to support this, assuming the underlying libraries support it.

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

Package-split upgrade path

[Sandro Mani]

Hello,

In python-pillow (the python imaging fork which replaced PIL in F19+), 
there is a module (ImageQt) which requires PyQt4, but that dependency is 
missing in python-pillow (and in python-imaging before). I don't really 
like adding PyQt4 as a dependency to the main package, since it pulls in 
lots of stuff. So, I'd go for creating a python-pillow-qt subpackage 
(albeit with just one file), and now am wondering about the upgrade 
path. From what I can see, there is just one package which uses the 
ImageQt module (pony, which actually looks to be rather unmaintained).

Question: What is the best way to proceed?

Thanks,
Sandro

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

Review swap

[Lokesh Mandvekar]

I'd like to offer a review swap.

Here are my review requests:

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

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

Let me know.
Thanks,
-- 
Lokesh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Expanding the list of "Hardened Packages"

[Richard W.M. Jones]

Whatever you think.  But it means you can't just write:

  $dom = Sys::Virt->get_domain_by_name ("foo");
  $g = Sys::Guestfs->create ();
  $g->add_libvirt_domain ($dom);

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://people.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Login to Koji

[Ravindra Kumar]

> We are adjusting anything that tells you you need to set this up. 
> Where did you see it? From fedora-packager-setup? 

Yes. It generates a cert for browser and asks it to be imported
in the browser.

BTW, fedora-packager-setup has not generated ~/.koji directory
for me, https://fedoraproject.org/wiki/Using_the_Koji_build_system#Koji_Config

Hopefully, last problem is how do I specify proxy for koji commands?
Does it not support proxies? I found this being asked earlier,
http://www.redhat.com/archives/rhl-devel-list/2008-August/msg00667.html?

Thanks in advance,
Ravindra
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Login to Koji

[Kevin Fenzi]

On Thu, 18 Apr 2013 11:17:13 -0700 (PDT)
Ravindra Kumar  wrote:

> Hi, 
> 
> I have setup my certificate today using "fedora-packager-setup".
> However, when I try to login to https://koji.fedoraproject.org/koji/
> after importing "fedora-browser-cert.p12" into Firefox, it keeps
> timing out. 
> 
> I have tried with Firefox 19.0.2 on Windows and 17.0.1 on Fedora 18. 
> 
> Any ideas what could be the problem? 

Others have reported this in the past. 

However, it's not worth debugging. 

There's no reason you ever need to login to the web interface, so just
don't bother and move on. ;) 

We are adjusting anything that tells you you need to set this up. 
Where did you see it? From fedora-packager-setup? 

kevin


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

Re: Appropriate location for cmake support files

[Orion Poplawski]

On 04/18/2013 02:23 PM, Rex Dieter wrote:

Mario Ceresa wrote:


Hi all,
does anybody know where should I put cmake support files such as:

OpenIGTLinkBuildSettings.cmake
OpenIGTLinkConfig.cmake
UseOpenIGTLink.cmake

in order for cmake to find them automatically? Can I put them in
/usr/share/cmake/Modules/ ?

I read a lot of tutorials on how cmake's find_package works, but I'm
still a bit confused... Maybe there is a packaging guideline somewhere
and I missed it?


Under something like %_datadir/cmake/ or %_libdir/cmake/ depending
on if this is arch-specific or not (I'm guessing yes, so most often the
latter)

-- rex



Where  is probably %{name}.  There probably should be a guideline for 
this somewhere, but hopefully projects will install them in the proper place.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 Alpha status, karma requests

[Adam Williamson]

On 17/04/13 04:46 PM, Adam Williamson wrote:

Hi folks!

So, good news: following the blocker review meeting this morning, we're
looking quite close to signing off on Alpha. We just need to fill out
the RC4 test matrices before tomorrow's go/no-go meeting, and hope we
don't find any more blocker bugs. Of course, if you do, please nominate
them!

We also need to get karma for the following updates, that are part of
RC4 but not yet stable:

*
https://admin.fedoraproject.org/updates/FEDORA-2013-5795/lorax-19.2-1.fc19,python-blivet-0.11-1.fc19,anaconda-19.20-1.fc19

* https://admin.fedoraproject.org/updates/gnome-session-3.8.0-2.fc19
*
https://admin.fedoraproject.org/updates/FEDORA-2013-5084/libreoffice-4.0.2.2-2.fc19

*
https://admin.fedoraproject.org/updates/FEDORA-2013-5400/mesa-9.1-6.fc19,xorg-x11-glamor-0.5.0-5.20130401git81aadb8.fc19,xorg-x11-drv-ati-7.1.0-5.20130408git6e74aacc5.fc19

*
https://admin.fedoraproject.org/updates/FEDORA-2013-5244/python-pillow-2.0.0-3.1.gitde210a2.fc19

*
https://admin.fedoraproject.org/updates/FEDORA-2013-5224/kernel-3.9.0-0.rc6.git2.3.fc19


Thanks a lot folks, we now have karma on all of those. There's one I 
inadvertently left off the list:


https://admin.fedoraproject.org/updates/FEDORA-2013-5045/selinux-policy-3.12.1-28.fc19

That's the last one that needs karma now.
--
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: Appropriate location for cmake support files

[Orion Poplawski]

On 04/18/2013 07:55 AM, Richard Shaw wrote:

On Thu, Apr 18, 2013 at 8:40 AM, Mario Ceresa mailto:mrcer...@gmail.com>> wrote:

Hi all,
does anybody know where should I put cmake support files such as:

OpenIGTLinkBuildSettings.cmake
OpenIGTLinkConfig.cmake
UseOpenIGTLink.cmake


CMake upstream doesn't mind including them upstream as long as you're willing
to maintain them, but I'm assuming they would prefer ones that work on all
platforms the project builds on.


No, cmake upstream wants to get out of the business of handling this.  Various 
projects should provide their on cmake configs, as this project is doing.





--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Appropriate location for cmake support files

[Rex Dieter]

Mario Ceresa wrote:

> Hi all,
> does anybody know where should I put cmake support files such as:
> 
> OpenIGTLinkBuildSettings.cmake
> OpenIGTLinkConfig.cmake
> UseOpenIGTLink.cmake
> 
> in order for cmake to find them automatically? Can I put them in
> /usr/share/cmake/Modules/ ?
> 
> I read a lot of tutorials on how cmake's find_package works, but I'm
> still a bit confused... Maybe there is a packaging guideline somewhere
> and I missed it?

Under something like %_datadir/cmake/ or %_libdir/cmake/ depending 
on if this is arch-specific or not (I'm guessing yes, so most often the 
latter)

-- rex

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

Re: kdm sessions in EL6

[Rex Dieter]

Eugene Pivnev wrote:

> https://bugzilla.redhat.com/show_bug.cgi?id=953101
> As for Fedora - I can remove %_datadir}/apps/kdm/ (in my package) -
> %_datadir/xsessions/* still works.
> What about EL6?

It is the same

-- rex

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

Re: Expanding the list of "Hardened Packages"

[Chris Adams]

Once upon a time, Richard W.M. Jones  said:
> I shouldn't say "not possible", but not very easy.  A virDomainPtr in
> Sys::Virt is wrapped in some object which is very specific to the
> internals of Sys::Virt, thus cannot be extracted by Sys::Guestfs.  It
> would require Sys::Virt to have a separate C library to provide this.

No, it wouldn't require a separate C library, just a way to export it.
This has nothing to do with it being a pointer (or the language being
perl); something that is internal to one object/library/module/etc. and
not exported can't be accessed from another object/library/module/etc.

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

Login to Koji

[Ravindra Kumar]

Hi, 

I have setup my certificate today using "fedora-packager-setup". However, when 
I try to login to https://koji.fedoraproject.org/koji/ after importing 
"fedora-browser-cert.p12" into Firefox, it keeps timing out. 

I have tried with Firefox 19.0.2 on Windows and 17.0.1 on Fedora 18. 

Any ideas what could be the problem? 

Thanks, 
Ravindra 

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

Re: Expanding the list of "Hardened Packages"

[Björn Persson]

Richard W.M. Jones wrote:
> On Thu, Apr 18, 2013 at 01:14:33AM +0200, Björn Persson wrote:
> [...]
> > > Passing pointers to objects from one language to another is likely
> > > *not* possible however.
> > 
> > Ada imports and exports C pointers just fine, including pointers to
> > functions and records.
> 
> I should have been clearer.  I meant passing pointers between non-C
> languages is likely not possible.

If you mean some kind of fat pointer, that the compiler implements as
more than just a memory address, then the one compiler would have to
know how the other compiler implements those pointers, and the source
code would need to contain an instruction to the compiler to use the
other compiler's convention. If both compilers are GCC this should be
possible. With compilers from different vendors the coordination could
be more of a problem.

It seems to me that it's not a matter of pointers so much as the
datatypes that the pointers point to. If a type can be represented in
both languages, then both objects of that type and pointers to objects
can be passed around and used in both languages, as long as at least
one of the compilers has appropriate interfacing features. If a type in
one language can't be represented in the other language, then objects
of that type can't be passed to the other language, and pointers can
only be handled as opaque handles to be kept and passed to callbacks.

If you mean purely high-level languages that don't even have pointers
on the source code level, then yes, handling pointers in those
languages could be problematic. Still, any language that can interface
with C and deal with C pointers can also share C pointers with any
other language that can interface with C.

Björn Persson


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

Re: [RFE] lua 5.2

[Luya Tshimbalanga]

On Wed 17 Apr 2013 08:13:31 AM PDT, Toshio Kuratomi wrote:
>
> lua bug with the current status and work being done:
> https://bugzilla.redhat.com/show_bug.cgi?id=815263
>
> -Toshio
>
>

Thanks Toshio,
Lets hope the issue will be resolved soon. It is a shame such issue 
prevents updating other packages depending on newest version of 
upstream. :(

--
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net

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

Re: Using fedora-packager-setup behind a proxy

[Ravindra Kumar]

> This looks like a bug that we recently closed in python-requests. See if 
> there's an update for that package available. 

Thanks Toshio. "yum update python-requests" solved it. 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Expanding the list of "Hardened Packages"

[Richard W.M. Jones]

On Thu, Apr 18, 2013 at 10:39:43AM -0500, Chris Adams wrote:
> Once upon a time, Richard W.M. Jones  said:
> > We also suffer this problem in reverse: passing a pointer between two
> > C libraries is not possible in another non-C language.  eg.  Passing a
> > libvirt virDomainPtr from (Perl) Sys::Virt to Sys::Guestfs.
> 
> Why do you say that?  I'm pretty sure you can.

I shouldn't say "not possible", but not very easy.  A virDomainPtr in
Sys::Virt is wrapped in some object which is very specific to the
internals of Sys::Virt, thus cannot be extracted by Sys::Guestfs.  It
would require Sys::Virt to have a separate C library to provide this.

One advantage of gobject is it can do this sort of thing, although IME
gobject has so many other disadvantages that it's not worth
considering for serious bindings.

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://people.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Expanding the list of "Hardened Packages"

[Chris Adams]

Once upon a time, Richard W.M. Jones  said:
> I should have been clearer.  I meant passing pointers between non-C
> languages is likely not possible.

Well, it depends on the language, but it is probably possible with some
glue code (not necessarily practical though).  For example, giving perl
code a pointer isn't particularly useful, since perl doesn't provide for
random memory access that way.  It would be possible for an XS module to
provide access to the memory at the location though.

> We also suffer this problem in reverse: passing a pointer between two
> C libraries is not possible in another non-C language.  eg.  Passing a
> libvirt virDomainPtr from (Perl) Sys::Virt to Sys::Guestfs.

Why do you say that?  I'm pretty sure you can.
-- 
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: Trimming (or obsoleting) %changelog?

[Richard W.M. Jones]

On Wed, Apr 17, 2013 at 12:10:20PM +0900, Florian Festi wrote:
> For limiting the change log entries in the binary packages
> %_changelog_trimtime can be used that take a unix time stamp as an
> integer value. This way the whole history is still available in the spec
> file.

IIUC, this (untested) should trim RPM change logs older than 1 year?

%global _changelog_trimtime %(date +%s -d "1 year ago")

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: Expanding the list of "Hardened Packages"

[Richard W.M. Jones]

On Thu, Apr 18, 2013 at 01:14:33AM +0200, Björn Persson wrote:
[...]
> > Passing pointers to objects from one language to another is likely
> > *not* possible however.
> 
> Ada imports and exports C pointers just fine, including pointers to
> functions and records.

I should have been clearer.  I meant passing pointers between non-C
languages is likely not possible.

We also suffer this problem in reverse: passing a pointer between two
C libraries is not possible in another non-C language.  eg.  Passing a
libvirt virDomainPtr from (Perl) Sys::Virt to Sys::Guestfs.

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: Appropriate location for cmake support files

[Mario Ceresa]

Thanks Richard, I'll include them in cmake modules then!

Mario

On 18 April 2013 15:55, Richard Shaw  wrote:
> On Thu, Apr 18, 2013 at 8:40 AM, Mario Ceresa  wrote:
>>
>> Hi all,
>> does anybody know where should I put cmake support files such as:
>>
>> OpenIGTLinkBuildSettings.cmake
>> OpenIGTLinkConfig.cmake
>> UseOpenIGTLink.cmake
>
>
> CMake upstream doesn't mind including them upstream as long as you're
> willing to maintain them, but I'm assuming they would prefer ones that work
> on all platforms the project builds on.
>
>
>> in order for cmake to find them automatically? Can I put them in
>> /usr/share/cmake/Modules/ ?
>
>
> I don't think there are any guidelines here, at least not that I'm aware of.
> I don't see any problem putting them there as long as your package requires
> cmake, since it owns that directory.
>
> Richard
>
> --
> 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

File Debug-Client-0.25.tar.gz uploaded to lookaside cache by jplesnik

[Jitka Plesnikova]

A file has been added to the lookaside cache for perl-Debug-Client:

b4e55a7d2111c8599b03cbd78d10be28  Debug-Client-0.25.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 Request 20: Rework Logging Mechanisms

[Tim Flink]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard-tflink.rhcloud.com/r/20/
---

(Updated April 18, 2013, 3:03 p.m.)


Review request for blockerbugs.


Changes
---

updated with merge from develop and fixes for issues noticed during review


Bugs: 374
https://fedorahosted.org/fedora-qa/ticket/374


Repository: blockerbugs


Description
---

This is code to rework logging mechanisms for fedora-infra standards. It 
changed a bit from martin's original code, so I'm creating a new review request.


Diffs (updated)
-

  sass/app.scss 0f81cbd6d740ff7325ec080c5ccb33ecf642e0b7 
  conf/settings.py.example 7c45c785fa05c12f2c36f2ca06b99bcd41b318ce 
  conf/blockerbugs.cron.example ddfe8f5661854e76887cd727f187f219c80ffdae 
  blockerbugs/util/update_sync.py 9c46ffc7b3c2f07a73c899165044059447858a48 
  blockerbugs/util/bz_interface.py 7dedce924c2f96110ed98bd311b870e03e617887 
  blockerbugs/util/bug_sync.py 6e092aa35c04ec9a7a4b03653fddf2cef27e4ba1 
  blockerbugs/templates/thanks.html f5432900daae6af4d22b3e5abbbc7092df868c4a 
  blockerbugs/templates/layout.html a0b5ebda3ff61a3fa2647d96ef77037ed0d729d2 
  blockerbugs/static/img/repeater-stg.png 
24c56fd10da38d7d6f8a3f684a811bc4b04b56a4 
  blockerbugs/static/img/blockerbugs-logo-light-stg.png 
b94f3891dd4726eac435c8a03c2ac0a2daafef39 
  blockerbugs/static/css/app.css 26e177c1e5c7cec716db5b2bcd428bb4e6a92505 
  blockerbugs/static/css/app-foundation.css 
852272bf1bd1c629b30933b451daceec31812de7 
  blockerbugs/config.py cecca7c88ef25ee9fd81df0cd2aeb2f84030559f 
  blockerbugs/cli.py 5cfc306a9051555ad972fd05c627f906d3b2 
  blockerbugs/__init__.py aebfe96cc9268f6bbeab3d0bb0c9ae3a4218986b 
  blockerbugs.spec 012e980b5d0cf57c09bd9f993b6c21d29c5cc3d8 

Diff: http://reviewboard-tflink.rhcloud.com/r/20/diff/


Testing
---

local and dev VM testing, currently running on 
qa.stg.fedoraproject.org/blockerbugs/ - no issues noticed thus far


Thanks,

Tim Flink

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

Re: Review Request 20: Rework Logging Mechanisms

[Tim Flink]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard-tflink.rhcloud.com/r/20/#review22
---



blockerbugs/__init__.py


because at the point when this code is run, the app.logger is already set 
up and isn't affected by any changes to the root_logger.



blockerbugs/__init__.py


becuase it should be set on the root logger as well, and isn't



blockerbugs/__init__.py


huh, I thought I fixed that. obviously not.


- Tim Flink


On April 17, 2013, 5:22 p.m., Tim Flink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard-tflink.rhcloud.com/r/20/
> ---
> 
> (Updated April 17, 2013, 5:22 p.m.)
> 
> 
> Review request for blockerbugs.
> 
> 
> Bugs: 374
> https://fedorahosted.org/fedora-qa/ticket/374
> 
> 
> Repository: blockerbugs
> 
> 
> Description
> ---
> 
> This is code to rework logging mechanisms for fedora-infra standards. It 
> changed a bit from martin's original code, so I'm creating a new review 
> request.
> 
> 
> Diffs
> -
> 
>   testing/test_updatesync_extract_information.py 
> 1884dabb577515720c19b167a58fdb0559ba273c 
>   testing/test_update_sync.py 1bc7b7c9d43bb0f526611aef872ace85918fc3ad 
>   sass/app.scss 0f81cbd6d740ff7325ec080c5ccb33ecf642e0b7 
>   runapp.py 736ec65bd25962180559d783a155c7ac1c5da285 
>   conf/settings.py.example 7c45c785fa05c12f2c36f2ca06b99bcd41b318ce 
>   conf/blockerbugs.cron.example ddfe8f5661854e76887cd727f187f219c80ffdae 
>   blockerbugs/util/update_sync.py f6469da84ce9e60d65521535a07fe511fa668e1e 
>   blockerbugs/util/bz_interface.py 7dedce924c2f96110ed98bd311b870e03e617887 
>   blockerbugs/util/bug_sync.py 6e092aa35c04ec9a7a4b03653fddf2cef27e4ba1 
>   blockerbugs/templates/thanks.html f5432900daae6af4d22b3e5abbbc7092df868c4a 
>   blockerbugs/templates/layout.html a0b5ebda3ff61a3fa2647d96ef77037ed0d729d2 
>   blockerbugs/static/img/repeater-stg.png 
> 24c56fd10da38d7d6f8a3f684a811bc4b04b56a4 
>   blockerbugs/static/img/blockerbugs-logo-light-stg.png 
> b94f3891dd4726eac435c8a03c2ac0a2daafef39 
>   blockerbugs/static/css/app.css 26e177c1e5c7cec716db5b2bcd428bb4e6a92505 
>   blockerbugs/static/css/app-foundation.css 
> 852272bf1bd1c629b30933b451daceec31812de7 
>   blockerbugs/config.py cecca7c88ef25ee9fd81df0cd2aeb2f84030559f 
>   blockerbugs/cli.py 0166b0fddcacc79c81f0f111317df6208c35fb12 
>   blockerbugs/__init__.py cf068ed33799a5426e297ab9ed269c513079f726 
>   blockerbugs.spec 012e980b5d0cf57c09bd9f993b6c21d29c5cc3d8 
> 
> Diff: http://reviewboard-tflink.rhcloud.com/r/20/diff/
> 
> 
> Testing
> ---
> 
> local and dev VM testing, currently running on 
> qa.stg.fedoraproject.org/blockerbugs/ - no issues noticed thus far
> 
> 
> Thanks,
> 
> Tim Flink
> 
>

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

Re: OSSD motivations

[Richard Vickery]

On Apr 18, 2013 7:48 AM, "Richard Vickery" 
wrote:
>
>
> On Apr 18, 2013 1:55 AM, "Mohamed Lamine Aknouche" 
wrote:
> >
> > Hi
> >
> >
> > Don't know if this is a bit off topic, but I am in real need of you.
Thing is, I am a frequent user of open source software, and I am often
amazed by the efforts people make in order to provide me with products and
services for free. I am now conducting research for a masters' thesis
trying to find out what motivates developers to participate in open source
projects. I would be pleased if you could fill out a survey and pass it on
within the community mail list. The survey only takes 3-5 minutes to fill
out, and all information is kept confidential. Again, thank you for your
efforts. Please click on this link to get to the survey:
> >
> >
https://docs.google.com/forms/d/1XL16GisKPCjw8uk8xdoVDl6mSPN5-d1c8ZX3NKSmLEo/viewform
> >
> >
> > Lamine Aknouche
> >
> > Lund University
> >
> >
>
> Go Mohammed,
>
> You might want to post this to the users list and various LUG's, like
vanlug, as well for a wider response.
>
> Hope this helps,
> Richard

Hi Lamine,

Sorry, I made the comment before looking at the survey, and thought that it
might be programmer-focused rather than developer-focused.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: OSSD motivations

[Richard Vickery]

On Apr 18, 2013 1:55 AM, "Mohamed Lamine Aknouche" 
wrote:
>
> Hi
>
>
> Don't know if this is a bit off topic, but I am in real need of you.
Thing is, I am a frequent user of open source software, and I am often
amazed by the efforts people make in order to provide me with products and
services for free. I am now conducting research for a masters' thesis
trying to find out what motivates developers to participate in open source
projects. I would be pleased if you could fill out a survey and pass it on
within the community mail list. The survey only takes 3-5 minutes to fill
out, and all information is kept confidential. Again, thank you for your
efforts. Please click on this link to get to the survey:
>
>
https://docs.google.com/forms/d/1XL16GisKPCjw8uk8xdoVDl6mSPN5-d1c8ZX3NKSmLEo/viewform
>
>
> Lamine Aknouche
>
> Lund University
>
>

Go Mohammed,

You might want to post this to the users list and various LUG's, like
vanlug, as well for a wider response.

Hope this helps,
Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bundled copies of the Porter stemmer library

[Petr Pisar]

On 2013-04-17, Florian Weimer  wrote:
> Ugh, hit "Send" too soon.
>
> I found some packages which embed copies of the Porter stemmer library
> (PostgreSQL, tracker, pl, etc.).  Should I file bugs once I have the
> full list, or should I apply for a bundling exception?
>
> I don't know if the existing copies are patched in significant ways.

The SWI Prologue (pl package) modifies the code and modifes the old
Relase 1 (current Porter's release is
2 ). I worry unbundling
will not be easy because upstream does not provide a library but
a simple C code (no headers, no interface) and because pl changes some
prototypes to fit better to the pl and of course adds the binding
helpers. Unified diff has 980 lines of 383 upstream lines now.

-- Petr

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

[Bug 952184] perl-Test-Class-0.39 is available

[bugzilla]

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=952184

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ppi...@redhat.com
   Assignee|st...@silug.org |ppi...@redhat.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=YS0OZ8vh1c&a=cc_unsubscribe
--
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: Appropriate location for cmake support files

[Richard Shaw]

On Thu, Apr 18, 2013 at 8:40 AM, Mario Ceresa  wrote:

> Hi all,
> does anybody know where should I put cmake support files such as:
>
> OpenIGTLinkBuildSettings.cmake
> OpenIGTLinkConfig.cmake
> UseOpenIGTLink.cmake
>

CMake upstream doesn't mind including them upstream as long as you're
willing to maintain them, but I'm assuming they would prefer ones that work
on all platforms the project builds on.


in order for cmake to find them automatically? Can I put them in
> /usr/share/cmake/Modules/ ?
>

I don't think there are any guidelines here, at least not that I'm aware
of. I don't see any problem putting them there as long as your package
requires cmake, since it owns that directory.

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

Appropriate location for cmake support files

[Mario Ceresa]

Hi all,
does anybody know where should I put cmake support files such as:

OpenIGTLinkBuildSettings.cmake
OpenIGTLinkConfig.cmake
UseOpenIGTLink.cmake

in order for cmake to find them automatically? Can I put them in
/usr/share/cmake/Modules/ ?

I read a lot of tutorials on how cmake's find_package works, but I'm
still a bit confused... Maybe there is a packaging guideline somewhere
and I missed it?

Thanks and regards,

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

F-19 Branched report: 20130418 changes

[Fedora Branched Report]

Compose started at Thu Apr 18 09:15:19 UTC 2013

Broken deps for x86_64
--
[aeolus-conductor]
aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1
[alexandria]
alexandria-0.6.9-4.fc19.noarch requires ruby(abi) >= 0:1.9.1
[amide]
amide-1.0.0-4.fc19.x86_64 requires libvolpack.so.1()(64bit)
[clementine]
clementine-1.1.1-1.fc19.x86_64 requires libprotobuf.so.7()(64bit)
clementine-1.1.1-1.fc19.x86_64 requires libimobiledevice.so.3()(64bit)
[connman]
connman-1.5-4.fc19.i686 requires libxtables.so.7
connman-1.5-4.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4)
connman-1.5-4.fc19.i686 requires libgnutls.so.26
connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit)
connman-1.5-4.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit)
connman-1.5-4.fc19.x86_64 requires libgnutls.so.26()(64bit)
[deltacloud-core]
deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1
[denemo]
denemo-0.9.4-0.fc18.x86_64 requires libgtksourceview-3.0.so.0()(64bit)
[dragonegg]
dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19
[eruby]
eruby-1.0.5-19.fc18.x86_64 requires libruby.so.1.9()(64bit)
eruby-libs-1.0.5-19.fc18.i686 requires ruby(abi) >= 0:1.9.0
eruby-libs-1.0.5-19.fc18.i686 requires libruby.so.1.9
eruby-libs-1.0.5-19.fc18.x86_64 requires ruby(abi) >= 0:1.9.0
eruby-libs-1.0.5-19.fc18.x86_64 requires libruby.so.1.9()(64bit)
[fawkes]
fawkes-firevision-0.5.0-5.fc19.i686 requires libjpeg.so.8(LIBJPEG_8.0)
fawkes-firevision-0.5.0-5.fc19.i686 requires libjpeg.so.8
fawkes-firevision-0.5.0-5.fc19.x86_64 requires 
libjpeg.so.8(LIBJPEG_8.0)(64bit)
fawkes-firevision-0.5.0-5.fc19.x86_64 requires libjpeg.so.8()(64bit)
fawkes-guis-0.5.0-5.fc19.i686 requires libgraph.so.5
fawkes-guis-0.5.0-5.fc19.x86_64 requires libgraph.so.5()(64bit)
fawkes-plugin-clips-0.5.0-5.fc19.i686 requires libclipsmm.so.2
fawkes-plugin-clips-0.5.0-5.fc19.x86_64 requires 
libclipsmm.so.2()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libgeos-3.3.6.so()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libboost_thread-mt.so.1.50.0()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libboost_system-mt.so.1.50.0()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libboost_signals-mt.so.1.50.0()(64bit)
fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires 
libboost_thread-mt.so.1.50.0()(64bit)
fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires 
libboost_system-mt.so.1.50.0()(64bit)
[flowcanvas]
flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5
flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit)
[gcc-python-plugin]
gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 
0:4.7.2-8.fc19
gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19
gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 
0:4.7.2-8.fc19
gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19
[gdcm]
gdcm-2.0.18-6.fc18.i686 requires libpoppler.so.26
gdcm-2.0.18-6.fc18.x86_64 requires libpoppler.so.26()(64bit)
[gearbox]
gearbox-10.11-3.fc19.i686 requires libIceUtil.so.35b
gearbox-10.11-3.fc19.x86_64 requires libIceUtil.so.35b()(64bit)
[gnome-applets]
1:gnome-applets-3.5.92-3.fc18.x86_64 requires 
libgweather-3.so.1()(64bit)
[gnome-panel]
gnome-panel-3.6.2-6.fc19.x86_64 requires 
libgnome-desktop-3.so.5()(64bit)
gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5
gnome-panel-devel-3.6.2-6.fc19.x86_64 requires 
libgnome-desktop-3.so.5()(64bit)
[gnome-pie]
gnome-pie-0.5.3-3.20120826git1b93e1.fc19.x86_64 requires 
libbamf3.so.0()(64bit)
[gnomint]
gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_2_8)(64bit)
gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit)
gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26()(64bit)
[gooddata-cl]
gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java
[gorm]
gorm-1.2.18-1.fc19.i686 requires libgnustep-gui.so.0.22
gorm-1.2.18-1.fc19.x86_64 requires libgnustep-gui.so.0.22()(64bit)
[kawa]
1:kawa-1.11-5.fc19.x86_64 requires servlet25
[libkolab]
php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64
php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64
[matreshka]
matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-mofext-0.3.0-3.fc19.i68

rawhide report: 20130418 changes

[Fedora Rawhide Report]

Compose started at Thu Apr 18 08:15:41 UTC 2013

Broken deps for x86_64
--
[aeolus-conductor]
aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1
[amide]
amide-1.0.0-4.fc19.x86_64 requires libvolpack.so.1()(64bit)
[clementine]
clementine-1.1.1-1.fc19.x86_64 requires libprotobuf.so.7()(64bit)
clementine-1.1.1-1.fc19.x86_64 requires libimobiledevice.so.3()(64bit)
[connman]
connman-1.5-4.fc19.i686 requires libxtables.so.7
connman-1.5-4.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4)
connman-1.5-4.fc19.i686 requires libgnutls.so.26
connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit)
connman-1.5-4.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit)
connman-1.5-4.fc19.x86_64 requires libgnutls.so.26()(64bit)
[deltacloud-core]
deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1
[diet]
diet-2.8.1-5.fc19.i686 requires libxqilla.so.5
diet-2.8.1-5.fc19.x86_64 requires libxqilla.so.5()(64bit)
diet-examples-2.8.1-5.fc19.x86_64 requires libxqilla.so.5()(64bit)
[dragonegg]
dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19
[eg]
eg-1.7.5.2-1.fc20.noarch requires perl(one)
eg-1.7.5.2-1.fc20.noarch requires perl(it)
eg-1.7.5.2-1.fc20.noarch requires perl(an)
[flowcanvas]
flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5
flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit)
[gcc-python-plugin]
gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 
0:4.7.2-8.fc19
gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19
gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 
0:4.7.2-8.fc19
gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19
[gnome-applets]
1:gnome-applets-3.5.92-3.fc18.x86_64 requires 
libgweather-3.so.1()(64bit)
[gnome-panel]
gnome-panel-3.6.2-6.fc19.x86_64 requires 
libgnome-desktop-3.so.5()(64bit)
gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5
gnome-panel-devel-3.6.2-6.fc19.x86_64 requires 
libgnome-desktop-3.so.5()(64bit)
[gnome-pie]
gnome-pie-0.5.3-3.20120826git1b93e1.fc19.x86_64 requires 
libbamf3.so.0()(64bit)
[gnomint]
gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_2_8)(64bit)
gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit)
gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26()(64bit)
[gooddata-cl]
gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java
[kawa]
1:kawa-1.11-5.fc19.x86_64 requires servlet25
[libkolab]
php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64
php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64
[mapserver]
php-mapserver-6.0.3-9.fc19.x86_64 requires php(zend-abi) = 
0:20100525-x86-64
php-mapserver-6.0.3-9.fc19.x86_64 requires php(api) = 0:20100412-x86-64
[matreshka]
matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-mofext-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-mofext-0.3.0-3.fc19.x86_64 requires 
libgnat-4.7.so()(64bit)
matreshka-amf-ocl-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-ocl-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-uml-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-uml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-utp-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-utp-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnarl-4.7.so
matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnarl-4.7.so()(64bit)
matreshka-sql-core-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-sql-core-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-sql-postgresql-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-sql-postgresql-0.3.0-3.fc19.x86_64 requires 
libgnat-4.7.so()(64bit)
matreshka-sql-sqlite-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-sql-sqlite-0.3.0-3.fc19.x86_64 requires 
libgnat-4.7.so()(64bit)
matreshka-xml-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-xml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
[mygui]
mygui-3.2.0-4.fc20.i686 requires libCommon.so
mygui-3.2.0-4.fc20.x86_64 requires libCommon.so()(64bit)
mygui-demos-3.2

OSSD motivations

[Mohamed Lamine Aknouche]

*

Hi


Don't know if this is a bit off topic, but I am in real need of you. Thing
is, I am a frequent user of open source software, and I am often amazed by
the efforts people make in order to provide me with products and services
for free. I am now conducting research for a masters' thesis trying to find
out what motivates developers to participate in open source projects. I
would be pleased if you could fill out a survey and pass it on within the
community mail list. The survey only takes 3-5 minutes to fill out, and all
information is kept confidential. Again, thank you for your efforts. Please
click on this link to get to the survey:

https://docs.google.com/forms/d/1XL16GisKPCjw8uk8xdoVDl6mSPN5-d1c8ZX3NKSmLEo/viewform


Lamine Aknouche

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

Re: Broken dependencies: rubygem-pam

[Vít Ondruch]

Dear Bryan,

If you think you fixed your package by changing ruby(abi) to 
ruby(release) then you don't. Quick look on the RPMs will reveal:


$ rpm -qp -l 
http://kojipkgs.fedoraproject.org//packages/rubygem-pam/1.5.4/15.fc19/x86_64/rubygem-pam-1.5.4-15.fc19.x86_64.rpm

/builddir/.gem/ruby/cache/pam-1.5.4.gem
/builddir/.gem/ruby/doc
/builddir/.gem/ruby/doc/pam-1.5.4
/builddir/.gem/ruby/doc/pam-1.5.4/ri
/builddir/.gem/ruby/doc/pam-1.5.4/ri/cache.ri
/builddir/.gem/ruby/gems/pam-1.5.4
/builddir/.gem/ruby/gems/pam-1.5.4/COPYING
/builddir/.gem/ruby/gems/pam-1.5.4/ChangeLog
/builddir/.gem/ruby/gems/pam-1.5.4/LICENSE
/builddir/.gem/ruby/gems/pam-1.5.4/MANIFEST
/builddir/.gem/ruby/gems/pam-1.5.4/README
/builddir/.gem/ruby/gems/pam-1.5.4/Rakefile
/builddir/.gem/ruby/gems/pam-1.5.4/lib
/builddir/.gem/ruby/gems/pam-1.5.4/lib/pam.rb
/builddir/.gem/ruby/gems/pam-1.5.4/test
/builddir/.gem/ruby/gems/pam-1.5.4/test/check_conv.rb
/builddir/.gem/ruby/gems/pam-1.5.4/test/check_get_item.rb
/builddir/.gem/ruby/gems/pam-1.5.4/test/check_user.rb
/builddir/.gem/ruby/specifications/pam-1.5.4.gemspec
/usr/local/lib64/ruby/site_ruby/_pam.so

$ rpm -qp -l 
http://kojipkgs.fedoraproject.org//packages/rubygem-pam/1.5.4/15.fc19/x86_64/ruby-pam-1.5.4-15.fc19.x86_64.rpm

/usr/local/share/ruby/site_ruby/pam.rb


That is not how the content of RPM should look like. I offered you help 
with the package more than year ago [1] but you did not used it. I 
offered you help again in this thread, but you ignore it again. Package 
in such state has no meaning for Fedora, causing more harm then help, so 
I suggest you to retire the package.


Thank you.


Vít


[1] https://bugzilla.redhat.com/show_bug.cgi?id=790454



Dne 15.4.2013 13:54, Bryan Kearney napsal(a):
I am not sure how to fix this. The current spec file in master and f19 
has the following requires:


BuildRequires:  ruby-devel >=  1.9
Requires:   ruby(abi) >= 1.9

The current package is at 2.0 which should be ok. Is there an obvious 
change I need to make?

-- bk




 Original Message 
Subject: Broken dependencies: rubygem-pam
Date: Mon, 15 Apr 2013 11:49:52 + (UTC)
From: build...@fedoraproject.org
To: rubygem-pam-ow...@fedoraproject.org



rubygem-pam has broken dependencies in the F-19 tree:
On x86_64:
rubygem-pam-1.5.4-14.fc19.x86_64 requires ruby(abi) >= 0:1.9
On i386:
rubygem-pam-1.5.4-14.fc19.i686 requires ruby(abi) >= 0:1.9
Please resolve this as soon as possible.








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

kdm sessions in EL6

[Eugene Pivnev]

https://bugzilla.redhat.com/show_bug.cgi?id=953101
As for Fedora - I can remove %_datadir}/apps/kdm/ (in my package) - 
%_datadir/xsessions/* still works.

What about EL6?

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

Re: Plan to drop php-pecl-apc from Fedora - Urgent review needed

[Remi Collet]

Le 16/04/2013 20:50, Jared K. Smith a écrit :

> 1/ php-pecl-zendopcache, the Zend OPcache for php 5.3 / 5.4
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=91
> 
> Target version is EPEL-6 and Fedora <= 18 as Fedora >= 19 already have
> php-opcache (subpackage of main php, same code)
> 
> 
> Review done and approved.

Great thanks for the review.

php-pecl-zendopcache is build and should be soon in updates-testing for
Fedora 17, 18 and EPEL-6.

php-pecl-apc 3.1.15-dev is also in updates-testing with the
apc.enable_opcode_cache directive (default=1, must be set to 0 to work
with Zend OPcache)

Remi.

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