Re: bugzilla.redhat.com vs upstream bug trackers

[David Tardon]

On Mon, Jun 17, 2013 at 09:49:37PM +, Jóhann B. Guðmundsson wrote:
 On 06/17/2013 07:57 PM, Jeffrey Ollie wrote:
 In my view these expectations imply that a packager has some
 involvement with upstream.  I think that the level of involvement is
 going to depend on the packager and the package.  I don't think that a
 hard and fast rule can be developed to cover every case without
 becoming ridiculously long and complex.  Other than generally
 encouraging packagers to become involved with upstream development it
 should be left up to the conscience of the packager.
 
 From my point of view If you are not involved with upstream ( at
 least subscribed to their mailing list and have a account in their
 upstream tracker ) you should not be maintaining package in the
 distribution but should instead just be maintaining it in a side
 repo.

That is your opinion. Others can have their own opinions about the
matter.

 
 In no way should packagers be expected to provide end-user support for
 packages, be an expert in every aspect of a package, or be expected to
 work with upstream to debug issues because the end user is unwilling
 to do the work themselves (in essence becoming an upstream developer
 themselves).
 
 Agreed but at least they should know how to debug their own
 components which when I started the how to debug initiative a while
 back in QA revealed many of them did not even know how to do that.
 

And how is this relevant here?

 1)  There's a 99.999% chance that I don't have the resources (either
 hardware or software) to reproduce the bug.
 Then you should not be maintaining that component
 In some cases you may be right.  But in most cases I was the only
 person to step up and package a particular piece of software.  Also,
 in most cases I'm willing to step aside as the owner of a package if
 someone wants to take over the responsibility.  In every case I've
 been willing to take on co-maintainers to help out with the packaging
 duties.
 
 So here is where I see things go wrong for many packagers they fail
 to understand or rather we fail to provide proper info on how much
 time it takes to maintain a package in the distribution.

Because there is no way to quantify that. Because the world is not black
and white and it differs from package to package.

 
 2) There's a 100% chance that I don't have the time between work and
 family obligations.
 We do not need unresponsive or poor maintained packages in the distribution
 and if there is really need or demand for the component you maintain,
 co-maintainers will appear or people to pick it up if you drop it so if you
 dont have the time to properly maintain your component(s) in the
 distribution then either find yourself co-maintainers or drop the package.
 Again, our key disagreement here is on the definition of proper
 maintenance.  I have more than enough time to keep up with new
 versions as they are released (most of the time) or to pull a patch
 out of the upstream's version control and add it to the package. But
 even if I had the hardware I don't have the kind of time it takes to
 set up test environments to reproduce a bug, and then dig into the
 code and find the bug, develop a fix and then test it.
 
 When you decide to maintain a component in the distribution you need
 to ensure that you have enough time to perform steps a) b) c) d) and
 e) not only steps a),b) and c).

What are these steps?

 
 The load or rather the time of the maintenance can however be
 distributed between co-maintainers and between existing sub
 communites in the distribution or for packagers/maintainers
 themselves by building a sub-community surrounding the component(s)
 in question.

I see two interpretations of the above paragraph:
1. You imply that the solution is to put every existing maintainer into
   several groups/sub-communities.
2. You think that there are hordes of people eager to become
   co-maintaineres, if only we had given them the chance.

Both are wrong.

 
 
 It's component's owner responsibility to be in touch and contact with
 upstream and the man in the middle role of the packager/maintainer can never
 be entirely gotten rid of.
 Playing man in the middle is inefficient.  Unless it's an issue with
 packaging or Fedora-specific patches the reporter should work with the
 upstream developers to identify and fix the issue.  Once a fix is
 available then it's the package maintainers responsibility to pull
 that fix into Fedora (either as a patch or a new release).  That way
 the upstream developers can work directly with the user that is having
 the problem and ultimately every distribution benefits from the bug
 fix.  The package maintainer should certainly be kept in the loop so
 that they know an update/patch is imminent.
 
 Agreed that's inefficient but it's still a necessary and unavoidable
 part of maintainers responsibility from my point of view.

It is by no means unavoidable. In fact, it is very easy to avoid.

 
 
 I personally think 

Re: option to ignore flash memory device at USB1.1 full speed

[Hans de Goede]

Hi,

On 06/17/2013 10:37 PM, Adam Williamson wrote:

On Sun, 2013-06-16 at 22:33 +0100, Matthew Garrett wrote:

On Sun, Jun 16, 2013 at 10:11:42PM +0100, David Woodhouse wrote:

On Sun, 2013-06-16 at 05:38 +0100, Matthew Garrett wrote:

On Sat, Jun 15, 2013 at 08:24:33AM -0700, John Reiser wrote:

How can I force the system not to recognize a USB2.0 flash memory

device at USB1.1 speed?

You can't - it's negotiated at the host controller level, the OS isn't
involved.


You can't force it to use USB2 mode when for some reason it's negotiated
something slower. But you can *detect* that it's connected as a USB1
device and refuse to mount it, surely? And then the user will unplug it
and plug it in again, until it works correctly.


Yeah, I guess you could write a udev rule that detected that case and
flagged it such that it didn't get automounted.


IIRC, Windows pops up one of its little yellow warnings associated with
a notification tray icon when this happens - the medium is mounted but
you get a warning that it's running at a slow speed. That seems
reasonable.


And IIRC the kernel will log a message when plugging a usb-2 device into
a port which is not usb-2 capable. But if I understand correctly, that is
not the issue here?

The issue seems to be that sometimes a usb-2 device connects at usb-1 speed
even though plugged into a usb-2 port, right ?

That is just buggy hardware, and I don't think that warrants any special
handling. I would try cleaning the contacts of both the usb-port and
the usb-stick. Also if a usb-extension cable is involved, try replacing it,
or taking it out of the loop all-together.

I've seen similar issue in the past and sofar it has always been bad hardware.

Sometimes things like cleaning contacts help, sometimes the contacts on the
usb-port side are simply worn out / too loose.

Regards,

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

Re: bugzilla.redhat.com vs upstream bug trackers

[David Tardon]

On Mon, Jun 17, 2013 at 03:55:57PM +, Jóhann B. Guðmundsson wrote:
 Because if you cannot properly maintain the component in the
 distribution the community is better of without it.
 
 ...

 Then you should not be maintaining that component
 
 ...

 We do not need unresponsive or poor maintained packages in the
 distribution and if there is really need or demand for the component
 you maintain, co-maintainers will appear or people to pick it up if
 you drop it so if you dont have the time to properly maintain your
 component(s) in the distribution then either find yourself
 co-maintainers or drop the package.

You have this persistent idea that there are hordes of potential new
maintainers out there. Well, there are not. Trust me. I looked.

In all likelihood, what is going to happen if someone orphans a package
is that some other _existing_ maintainer picks it up. Either because he
uses it or because one of his packages depends on it (I had been a
maintainer of bsh for more than a year. I have never used it and have
only a vague idea what it does. All I know is that it is used by
libreoffice's scripting framework.)

 
 
 3) Even though I'm an excellent programmer, well versed in C and
 Python, and decent in Perl, Ruby, et. al.  I probably don't have the
 familiarity with the codebase to even know where to start looking for
 a bug.
 
 If you aren't familiar with the component you are packaging and
 maintaining why are you doing it et all?

Have you even read the sentence? He does not talk about using something,
but about _debugging_ it. We do not expect maintainers to be developers.
And even if they are, we definitely do not expect them to be faimiliar
with the source code of every package they maintain.

 
 
 4) Most software is complex enough that even configuration problems
 are best handled by upstream because I'd be familiar with a small set
 of configuration scenarios, but everyone's situation is unique and
 understanding what exactly a configuration option does (especially in
 edge cases) often requires an understanding of the code behind it.
 
 All of this means that I'm a speedbump in the way of getting the bug
 fixed, at least until there's a patch that needs to be applied to the
 package, or a new release to upgrade to.
 
 It's component's owner responsibility to be in touch and contact
 with upstream and the man in the middle role of the
 packager/maintainer can never be entirely gotten rid of.

Yes, it can.

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

Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Michael Schwendt]

On Tue, 18 Jun 2013 01:37:19 +0300, Oron Peled wrote:

 Let me be more specific:
  * If upstream uses a modern autotools, than autoreconf should be preferred 
 (IMO).
  * If not, we should advise them to modernize (and if we can, try to help 
 them).


IIRC, that has been suggested in the many aarch64 bz tickets recently as
one of several options to fix the issue.

However, to repeat, often one only touches the Autotools files when one
really needs to do that. One doesn't regularly examine them for whether
they contain hacks or other problems that only turn up when regenerating
the files in an env that differs from upstream's. Some contain surprises,
such as but not limited to losing preprocessor definitions or using
conflicting variable names.

-- 
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.5-301.fc19.x86_64
loadavg: 0.62 0.23 0.19
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: icedtea-web installed and enabled by default in Fedora 19

[Mateusz Marzantowicz]

On 17.06.2013 21:26, Dan Mashal wrote:
 On Mon, Jun 17, 2013 at 8:25 AM, Mateusz Marzantowicz
 mmarzantow...@osdf.com.pl wrote:
 On 17.06.2013 17:18, Heiko Adams wrote:

 From my point of view the java-plugin is a big security hole and should be
 kicked from default installations ASAP.



 Then, why not fix it?


 Mateusz Marzantowicz
 There is no way in hell anyone here is going to fix the security holes
 in Java (open or closed).

 The only way to avoid the security holes caused by java is to not use it.

Is java environment the only security flawed software distributed in
Fedora by default? I don't think so. Please, correct me if I'm wrong.
Does it mean Fedora should drop about 1/3 of packages because they have
security bugs? What about Linux Kernel? It's also buggy. Should it be
not included in Fedora?


 That's like telling someone not to use Firefox because it has security holes.
Isn't it what *-nix geeks tell to M$ people about using IE? Don't use
IE - it's buggy!


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

Re: option to ignore flash memory device at USB1.1 full speed

[Adam Williamson]

On Tue, 2013-06-18 at 08:26 +0200, Hans de Goede wrote:
 Hi,
 
 On 06/17/2013 10:37 PM, Adam Williamson wrote:
  On Sun, 2013-06-16 at 22:33 +0100, Matthew Garrett wrote:
  On Sun, Jun 16, 2013 at 10:11:42PM +0100, David Woodhouse wrote:
  On Sun, 2013-06-16 at 05:38 +0100, Matthew Garrett wrote:
  On Sat, Jun 15, 2013 at 08:24:33AM -0700, John Reiser wrote:
  How can I force the system not to recognize a USB2.0 flash memory
  device at USB1.1 speed?
 
  You can't - it's negotiated at the host controller level, the OS isn't
  involved.
 
  You can't force it to use USB2 mode when for some reason it's negotiated
  something slower. But you can *detect* that it's connected as a USB1
  device and refuse to mount it, surely? And then the user will unplug it
  and plug it in again, until it works correctly.
 
  Yeah, I guess you could write a udev rule that detected that case and
  flagged it such that it didn't get automounted.
 
  IIRC, Windows pops up one of its little yellow warnings associated with
  a notification tray icon when this happens - the medium is mounted but
  you get a warning that it's running at a slow speed. That seems
  reasonable.
 
 And IIRC the kernel will log a message when plugging a usb-2 device into
 a port which is not usb-2 capable. But if I understand correctly, that is
 not the issue here?

Oh yeah, that might be the Windows warning I'm remembering.

 The issue seems to be that sometimes a usb-2 device connects at usb-1 speed
 even though plugged into a usb-2 port, right ?

AIUI, yes.

 That is just buggy hardware, and I don't think that warrants any special
 handling. I would try cleaning the contacts of both the usb-port and
 the usb-stick. Also if a usb-extension cable is involved, try replacing it,
 or taking it out of the loop all-together.

Well, yes, those are all perfectly sensible steps: I think the idea of
the OP was to alert people that this was happening precisely so they
could take the sensible debugging steps :)
-- 
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: bugzilla.redhat.com vs upstream bug trackers

[Jóhann B. Guðmundsson]

On 06/18/2013 06:24 AM, David Tardon wrote:

On Mon, Jun 17, 2013 at 09:49:37PM +, Jóhann B. Guðmundsson wrote:


 From my point of view If you are not involved with upstream ( at
least subscribed to their mailing list and have a account in their
upstream tracker ) you should not be maintaining package in the
distribution but should instead just be maintaining it in a side
repo.

That is your opinion. Others can have their own opinions about the
matter.


I never said they could not are you implying that I cant?




Agreed but at least they should know how to debug their own
components which when I started the how to debug initiative a while
back in QA revealed many of them did not even know how to do that.


And how is this relevant here?


This for example is relevant to debug the component in question and or 
provide that reporter with that debug information encase he needs to 
provide the packager with the proper report so the packager can forward 
the proper information upstream.


Basic triage stuff really...


So here is where I see things go wrong for many packagers they fail
to understand or rather we fail to provide proper info on how much
time it takes to maintain a package in the distribution.

Because there is no way to quantify that. Because the world is not black
and white and it differs from package to package.



Yes there is a way to quantify that and provide an base time at best 
conditions



2) There's a 100% chance that I don't have the time between work and
family obligations.

We do not need unresponsive or poor maintained packages in the distribution
and if there is really need or demand for the component you maintain,
co-maintainers will appear or people to pick it up if you drop it so if you
dont have the time to properly maintain your component(s) in the
distribution then either find yourself co-maintainers or drop the package.

Again, our key disagreement here is on the definition of proper
maintenance.  I have more than enough time to keep up with new
versions as they are released (most of the time) or to pull a patch
out of the upstream's version control and add it to the package. But
even if I had the hardware I don't have the kind of time it takes to
set up test environments to reproduce a bug, and then dig into the
code and find the bug, develop a fix and then test it.

When you decide to maintain a component in the distribution you need
to ensure that you have enough time to perform steps a) b) c) d) and
e) not only steps a),b) and c).

What are these steps?


The once that you conveniently cut out when responding to this.




The load or rather the time of the maintenance can however be
distributed between co-maintainers and between existing sub
communites in the distribution or for packagers/maintainers
themselves by building a sub-community surrounding the component(s)
in question.

I see two interpretations of the above paragraph:
1. You imply that the solution is to put every existing maintainer into
several groups/sub-communities.
2. You think that there are hordes of people eager to become
co-maintaineres, if only we had given them the chance.

Both are wrong.


No you interpretation of my response is wrong.


Agreed that's inefficient but it's still a necessary and unavoidable
part of maintainers responsibility from my point of view.

It is by no means unavoidable. In fact, it is very easy to avoid.


Yes at this point in time you can ignore bugs all you want and nobody 
said you could not but rather you should not.

Says who? The people around here are _volunteers_, not slaves. One does
not create a community by forcing rules on others.



Trying to follow your logic hence the question do o you think we 
increase our user and contributing pool by delivering broken components 
in the hands of our userbase?


Anyway just because you are volunteering does not mean that you are an 
slave, cannot follow a set or rule or we cant have one.



This is purely your interpretation.


Yes this is my interpretation and findings after being over 5 years in 
the QA community, working on feature that spans multiple packages and more.


I'm allowed to have one right?

JBG

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

Re: Retrospective license change heads-up: Roundcubemail changed to GPLv3+ with exceptions and GPLv3+ and GPLv2 and LGPLv2+ and CC-BY-SA and (MIT or GPLv2)

[Jon Ciesla]

On Mon, Jun 17, 2013 at 10:32 PM, Adam Williamson awill...@redhat.comwrote:

 Hey, fun times!

 I'm not the roundcubemail maintainer, but as a user and provenpackager I
 more or less co-maintain it with Jon. I was just doing a 'routine' bump
 to 0.9.2 and noticed the license situation was rather more complex than
 appeared.

 Up to 0.9.0 our package has claimed the license to be GPLv2. This was
 probably never strictly true, but never mind. It was the license on most
 of the core code prior to version 0.8.0 beta. Upstream in fact changed
 the license on the core code to GPLv3+ with exceptions at version
 0.8.0 beta, something Jon and I presumably missed. That's the main
 change here.

 The exception in question is the following:

 This file forms part of the Roundcube Webmail Software for which the
 following exception is added: Plugins and Skins which merely make
 function calls to the Roundcube Webmail Software, and for that purpose
 include it by reference shall not be considered modifications of
 the software.

 If you wish to use this file in another project or create a modified
 version that will not be part of the Roundcube Webmail Software, you
 may remove the exception above and use this source code under the
 original version of the license.

 Usually legal@ would have to review and approve this exception, but as
 we've actually been distributing the code for some time, it seems better
 to correct it immediately. I'm in the process of building and testing
 0.9.2 with the license field corrected; if I don't hear otherwise I'll
 just submit it as an update as usual. If legal thinks we need to do
 anything drastic here, please advise: to me the exception doesn't seem
 like a problem in any way, it's just intended to make sure plugins and
 themes aren't automatically GPLv3+. Worst impact if it's invalid is that
 plugins and themes are actually GPLv3+, which wouldn't be a problem for
 us.

 While checking that I noticed that the overall license situation of the
 package is rather more complex. Several other Things are embedded in
 Roundcube. None of them actually happens to constitute an embedding
 violation, happily, but they do muddy the licensing waters.

 It has embedded copies of the Javascript libraries jQueryUI and tinyMCE
 (javascript is excepted from the embedding policy) and an old copy of
 the Pear library Crypt_GPG - that would be a violation, only we don't
 actually have a php-pear-Crypt-GPG package, so we're okay until it gets
 packaged. I have raised a ticket with upstream -
 http://trac.roundcube.net/ticket/1489182 - suggesting this should be
 taken out of roundcube's no-dependencies tarball; if that happens
 we'll have to package it ourselves and modify the roundcube package
 appropriately. These are variously licensed as LGPLv2 (tinymce and
 crypt_gpg) and MIT or GPLv2 (jqueryui).

 RC's plugins themselves are all licensed either GPLv2 or GPLv3+. As the
 'exception' is specifically intended to apply to RC's *core code* and
 let plugins *not* be versioned the same way if they don't want to be, it
 seems odd to suggest the GPLv3+ plugins are actually under RC's GPLv3+
 with exceptions license, so I'd hold them to be under pure GPLv3+,
 hence GPLv3+ with exceptions and GPLv3+. Finally, RC's themes are
 licensed CC-BY-SA, which ultimately gives the final string GPLv3+ with
 exceptions and GPLv3+ and GPLv2 and LGPLv2+ and CC-BY-SA and (MIT or
 GPLv2) in all its glory. I may well have got the details a bit wrong
 there, so please, corrections welcome: I'm always around on IRC to
 discuss the details with reference to the source tarball, which is
 available at

 http://downloads.sourceforge.net/roundcubemail/roundcubemail-0.9.2-dep.tar.gzfor
  anyone who wants to poke at it. CCing upstream's contact email address
 for feedback from them, in case I misunderstood anything. Upstream, our
 licensing guidelines are at
 https://fedoraproject.org/wiki/Packaging:LicensingGuidelines and
 https://fedoraproject.org/wiki/Licensing:Main , for your reference.

 Yeesh, who'd be a webapp packager.
 --
 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


Good catches, thanks Adam!

-J

-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

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

Re: bugzilla.redhat.com vs upstream bug trackers

[David Tardon]

On Tue, Jun 18, 2013 at 09:13:23AM +, Jóhann B. Guðmundsson wrote:
 On 06/18/2013 06:24 AM, David Tardon wrote:
 
 Agreed but at least they should know how to debug their own
 components which when I started the how to debug initiative a while
 back in QA revealed many of them did not even know how to do that.
 
 And how is this relevant here?
 
 This for example is relevant to debug the component in question and
 or provide that reporter with that debug information encase he needs
 to provide the packager with the proper report so the packager can
 forward the proper information upstream.

Or the packager can send the reporter upstream, where there are people
who understand the package.

 
 Basic triage stuff really...

All right, if you want triaging, you can try to resurrect the old
BugTriagers SIG... Btw, in libreoffice upstream it is QA who is doing
the triaging (Hint .-)

 
 So here is where I see things go wrong for many packagers they fail
 to understand or rather we fail to provide proper info on how much
 time it takes to maintain a package in the distribution.
 Because there is no way to quantify that. Because the world is not black
 and white and it differs from package to package.
 
 
 Yes there is a way to quantify that and provide an base time at best
 conditions

So, since you are so confident about it and since you are part of the
we who fail to provide proper info to packagers, would you care to do
it?

 
 When you decide to maintain a component in the distribution you need
 to ensure that you have enough time to perform steps a) b) c) d) and
 e) not only steps a),b) and c).
 What are these steps?
 
 The once that you conveniently cut out when responding to this.

I thought so, but that list was denoted by numbers, not letters... So I
was not sure if there was another list.

 
 
 The load or rather the time of the maintenance can however be
 distributed between co-maintainers and between existing sub
 communites in the distribution or for packagers/maintainers
 themselves by building a sub-community surrounding the component(s)
 in question.
 I see two interpretations of the above paragraph:
 1. You imply that the solution is to put every existing maintainer into
 several groups/sub-communities.
 2. You think that there are hordes of people eager to become
 co-maintaineres, if only we had given them the chance.
 
 Both are wrong.
 
 No you interpretation of my response is wrong.

What is the right interpretation then? Neither co-maintainers nor
sub-communities can be created without _new_ packagers. Otherwise the
load on the _current_ packagers will not be alleviated, just shuffled
around a bit. And new packagers are not there. That is the main fallacy
in your reasoning.

 Says who? The people around here are _volunteers_, not slaves. One does
 not create a community by forcing rules on others.
 
 
 Trying to follow your logic hence the question do o you think we
 increase our user and contributing pool by delivering broken
 components in the hands of our userbase?

Which components are broken, concretely? That a packager does not
respond to bugs reported to his component does not mean anything is
broken, except maybe your idea about how package maintenance works.

 This is purely your interpretation.
 
 Yes this is my interpretation and findings after being over 5 years
 in the QA community, working on feature that spans multiple packages
 and more.
 
 I'm allowed to have one right?

Yes, you are.

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

rawhide report: 20130618 changes

[Fedora Rawhide Report]

Compose started at Tue Jun 18 08:15:03 UTC 2013

Broken deps for x86_64
--
[PyQwt]
PyQwt-5.2.0-20.fc19.2.i686 requires sip-api(9) = 0:9.1
PyQwt-5.2.0-20.fc19.2.x86_64 requires sip-api(9) = 0:9.1
[aries-blueprint]
aries-blueprint-0.3.1-5.fc19.noarch requires asm2
[cxf]
1:cxf-rt-2.6.6-1.fc19.noarch requires asm2
[drbd]
drbd-heartbeat-8.4.2-2.fc19.x86_64 requires heartbeat
[ekiga]
ekiga-4.0.1-1.fc19.x86_64 requires libedata-book-1.2.so.17()(64bit)
[eruby]
eruby-libs-1.0.5-23.fc20.i686 requires ruby(abi) = 0:1.9.1
eruby-libs-1.0.5-23.fc20.x86_64 requires ruby(abi) = 0:1.9.1
[evolution-rss]
1:evolution-rss-0.3.93-3.fc20.x86_64 requires libeutil.so()(64bit)
1:evolution-rss-0.3.93-3.fc20.x86_64 requires libeshell.so()(64bit)
[ffgtk]
ffgtk-plugin-evolution-0.8.5-1.fc19.x86_64 requires libeutil.so()(64bit)
ffgtk-plugin-evolution-0.8.5-1.fc19.x86_64 requires 
libeshell.so()(64bit)
[gdb-heap]
gdb-heap-0.5-12.fc19.x86_64 requires glibc(x86-64) = 0:2.17
[gnuplot]
gnuplot-4.6.2-2.fc20.x86_64 requires libgd.so.2()(64bit)
gnuplot-minimal-4.6.2-2.fc20.x86_64 requires libgd.so.2()(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
[koji]
koji-vm-1.8.0-1.fc20.noarch requires python-virtinst
[kyua-cli]
kyua-cli-0.5-3.fc19.x86_64 requires liblutok.so.0()(64bit)
kyua-cli-tests-0.5-3.fc19.x86_64 requires liblutok.so.0()(64bit)
[lancet]
lancet-1.0.1-6.fc19.noarch requires ant-nodeps = 0:1.7.1
[mail-notification]
mail-notification-evolution-plugin-5.4-71.git.eab5c13.fc20.x86_64 
requires libeutil.so()(64bit)
mail-notification-evolution-plugin-5.4-71.git.eab5c13.fc20.x86_64 
requires libeshell.so()(64bit)
[nodejs-better-assert]
nodejs-better-assert-1.0.0-1.fc20.noarch requires npm(callsite) = 
0:1.0.0
[openbox]
gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel
gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires 
gnome-panel
[openlierox]
openlierox-0.59-0.11.beta10.fc20.x86_64 requires libgd.so.2()(64bit)
[ovirt-engine]
ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires 
classpathx-mail
[ovirt-guest-agent]
ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires 
libgdmsimplegreeter.so.1()(64bit)
[oyranos]
oyranos-libs-0.4.0-7.fc19.i686 requires libraw.so.5
oyranos-libs-0.4.0-7.fc19.x86_64 requires libraw.so.5()(64bit)
[perl-Bio-ASN1-EntrezGene]
perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires 
perl(Bio::Index::AbstractSeq)
[perl-Bio-SamTools]
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires 
perl(Bio::SeqFeature::Lite)
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq)
[perl-PDL]
perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit)
[python-TraitsBackendQt]
python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI
[python-flask-admin]
python-flask-admin-1.0.5-3.fc20.noarch requires python-wtf-peewee
[qgis]
qgis-python-1.8.0-13.fc19.i686 requires sip-api(9) = 0:9.1
qgis-python-1.8.0-13.fc19.x86_64 requires sip-api(9) = 0:9.1
[ruby-RMagick]
ruby-RMagick-2.13.1-11.fc20.1.x86_64 requires ImageMagick = 0:6.8.3.9
[rubygem-openshift-origin-common]
rubygem-openshift-origin-common-1.8.10-1.fc20.noarch requires 
rubygem(safe_yaml)
[rubygem-openshift-origin-node]
rubygem-openshift-origin-node-1.9.15-1.fc20.noarch requires 
rubygem(safe_yaml)
rubygem-openshift-origin-node-1.9.15-1.fc20.noarch requires 
openshift-origin-node-proxy
[rubygem-qpid]
rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidtypes.so.1()(64bit)
rubygem-qpid-0.16.0-14.fc20.x86_64 requires 
libqpidmessaging.so.3()(64bit)
rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidcommon.so.5()(64bit)
rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidclient.so.5()(64bit)
[rubygem-qpid_messaging]
rubygem-qpid_messaging-0.20.2-1.fc19.x86_64 requires 
libqpidtypes.so.1()(64bit)
rubygem-qpid_messaging-0.20.2-1.fc19.x86_64 requires 
libqpidmessaging.so.3()(64bit)
rubygem-qpid_messaging-0.20.2-1.fc19.x86_64 requires 
libqpidcommon.so.5()(64bit)
rubygem-qpid_messaging-0.20.2-1.fc19.x86_64 requires 
libqpidclient.so.5()(64bit)
[sagemath]
sagemath-core-5.9-5.fc20.i686 requires libgd.so.2
sagemath-core-5.9-5.fc20.x86_64 requires libgd.so.2()(64bit)
[scala]
scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library)
[shim-signed]
shim-0.2-4.4.fc20.x86_64 requires shim-unsigned = 0:0.3-2.fc20
[spacewalk-web]
spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup)
[spring]
spring-94.1-1.fc20.x86_64 requires 

Re: Need some advices moving a fedora package from sysVinit to systemd t

[Lennart Poettering]

On Mon, 17.06.13 19:50, Jean-Marc Pigeon (j...@safe.ca) wrote:

 I just understood I need Requires= instead of After= as the application
 require the data-base daemon to be up and running in order to be
 operational.

Requirement dependencies and ordering dependencies in systemd are
orthogonal, meaning that Requires= alone has no effect on ordering, and
might result in the two services being started
simultaneously. Conversely, After= alone has no effect on requiring, and
it won't pull in any units if not conbined with Requires=.

After= alone is hence useful to order units against others without
needing that other ones to be enabled or even installed. 

 Then (to do some testing), I required spamassassin.service
 dovecot.service bigre.service
 sure enough bigre.service is unknown (as expected) and systemctl complain
 Failed to issue method call: Unit bigre.service failed to load: No
 such file or directory
 (as it should).
 Such I can't require a service the sysadmin don't want to use (lets
 say he want just
 use Posgresql but not want to start Mysqld at all and didn't bother to
 install it).
 So it will be nice to have a way to do conditional require, if not,
 we are asking the
 sysadmin to mess up with the service definition file (which is not
 good)...

As suggested before, use After=, and that's it. Also, please read the
documentation, such as systemd.unit(5).

 It's usually a bad idea to run systemctl from ExecStartPre= since that
 hides dependencies. With Wants= and After= you should have all you need
 to make these depdendencies explicit
 
 Agreed, dependency are nicely resolved by Requires= directive, but while
 doing the first start config I need (at least) to restart httpd.service
 once a new WEB interface is automatically defined by application first
 start config.

You really shouldn't do stuff like that as part of the normal boot
process. Starting and then restarting things in the same boot process is
really the wrong thing to do. What exactly are you trying to do here?

 Use Type=forking. That will cause systemd wait for the initial process
 to exit before checking for the PID file.
 
 Was already with Type=forking, the initial process start, initiate the
 daemon itself, starting in background (which set-up a lock file with
 its own process PID)
 once some checking is done.
 Timing are such, systemctl check for pid befor lock file is in place.
 A timer capability of some kind, would be nice?.

The parent process needs to wait until the PID file is fully written
before exiting. If it exits earlier than that things are racy, and that
not only on systemd but the same on sysv too because service foo start
; service foo stop might fail because the stop might not be able to
read the PID file. Please get the service in question fixed first, in
the meantime you can remove the PIDFile= setting in the unit file. That
way systemd might not be able to recognize what the main process of your
daemon is, but it should mostly work.

Lennart

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

Re: icedtea-web installed and enabled by default in Fedora 19

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/17/2013 06:31 PM, Matthew Garrett wrote:
 On Mon, Jun 17, 2013 at 11:03:26AM -0400, Bill Nottingham wrote:
 The one issue I can see with removing it is that the plugin
 finder you then get in Firefox if you hit a Java site doesn't
 work to actually get you the Fedora version.
 
 Well, if we're looking at this for F20, it's probably worth
 figuring out whether we can integrate the Firefox plugin finder
 with Packagekit in some meaningful way.
 

This sounds like a great candidate for a Change (formerly Feature):
https://fedoraproject.org/wiki/Changes/Policy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHAVsoACgkQeiVVYja6o6Oh7gCdGR+unxZNpFATVjRPmYt39i2j
MekAnA8HUsBXfIDykv776YJigQD3c4eh
=InuU
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F-19 Branched report: 20130618 changes

[Fedora Branched Report]

Compose started at Tue Jun 18 09:15:03 UTC 2013

Compose finished at Tue Jun 18 12:49:06 UTC 2013

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

Re: Need some advices moving a fedora package from sysVinit to systemd t

[Jean-Marc Pigeon]

Hello lennart,

Lets forget about question#1 (conditionnal dependancy) for now

About question#2 (systemctl within ExecStartPre script).


You really shouldn't do stuff like that as part of the normal boot
process. Starting and then restarting things in the same boot process is
really the wrong thing to do. What exactly are you trying to do here?

As said previously, on the FIRST  application starting, it try to configure
itself, one of the configuration component is an httpd configuration file
which is added, a nice way for httpd daemon to know about it, is a reload.
I am not trying to override starting sequence (this is systemd very
strong point),
just trying a way to advice another application something change.
this is for the first start, next start (or restart) is a very
straightforward because all configuration is detected already done and
systemd just need to make sure other
Required component are up and running.

About question#3 (timing delay within systemd to catch PIDfile).
I was totally wrong, problem is not a timing/race condition while starting
the daemon. Problem is a bug (rather a discrepancy) within systemd.
PIDfile is scanned as %D while ours was written/scanned as %d.
So systemd was understanding PID as an octal (our PID included leading 0).
The way PID are stored within a pidfile doesn't mater as long it is
consistent within the application component. Now we have an external
component (systemd) we need to agree on a standard, may be you should
update the manual to specify pid number iexpected format is %D.

For now, I decided to not use PIDfile and rely only on
ExecStart and ExecStop.
Question#3 is resolved, lets concentrate on question #2.

Just a Note: that would be very nice to have a incremental verbose mode
within systemctl such we could follow what is doing in (near) real time
when trying to debug an application.service.

--
A bientôt
===
Jean-Marc PigeonE-Mail: j...@safe.ca
SAFE Inc. Phone: (514) 493-4280
  Clement, 'a kiss solution' to get rid of SPAM (at last)
 Clement' Home base http://www.clement.safe.ca;
===


smime.p7s
Description: S/MIME Cryptographic Signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rpmbuild --rebuild does not result in hardened build

[Reindl Harald]

can someone lokk at this?
https://bugzilla.redhat.com/show_bug.cgi?id=975273

why are the hardening-macros not respected with rpmbuild?





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

Re: bugzilla.redhat.com vs upstream bug trackers

[Kevin Fenzi]

On Tue, 18 Jun 2013 08:58:04 +0800
Christopher Meng cicku...@gmail.com wrote:

 Is it possible to add a virtual team for each package(or some
 packages with a lot of bugs)?

yes, we have done so for a number of places. Currently the 'teams' are
just an alias however. Hopefully in pkgdb2.0 we will finally have some
real support for groups of people. 

 I mean, since upstream may ignore the bugs in bugzilla, we can add a
 maintainer team like kernel,  or a sig like java, to cope with many
 bugs reported everyday if some programs really have so many. And this
 team/sig contains email address of upstream developers if they are
 willing to get notifications of bugs in bugzilla but don't wish to
 create an account.

I suppose, but creating an account is pretty easy, doing things with an
alias means they actually will have less control over what is sending
them email, so I suspect not many people would go for this. 
 
 I think being a liaison is not only
 I wish abrt can report bugs to external bug trackers,  but it's
 impossible. And some upstream developers may not interested in
 bugzilla, too.

Sure, there's no one true answer here. Every package/upstream is
different, IMHO. 

kevin


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

Re: bugzilla.redhat.com vs upstream bug trackers

[Jason L Tibbitts III]

 MT == Miloslav Trmač m...@volny.cz writes:

MT For example, right now the easiest way to become a Fedora packager
MT is still to learn RPM packaging (only) and add a new package (which
MT will, by now, fairly often be something obscure with a few hundred
MT of users), 

That is actually quite untrue, you know.  You can see various routes to
becoming a package maintainer at
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

MT when quite a few existing packages with hundreds of
MT thousands of users could use much help with debugging/bug
MT fixing/programming, with fairly little focus on RPM.

Then if they want additional maintainers, why not use the existing
procedure for that?  It only takes one trac ticket.

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

Re: F-19 Branched report: 20130618 changes

[Kevin Fenzi]

On Tue, 18 Jun 2013 13:01:06 +
Fedora Branched Report rawh...@fedoraproject.org wrote:

 Compose started at Tue Jun 18 09:15:03 UTC 2013
 
 Compose finished at Tue Jun 18 12:49:06 UTC 2013

No broken deps! Hurray!

But seriously, the reason for this was that the langtable update that
anaconda requires missed the last stable push, resulting in anaconda
having broken deps and the branched compose being unable to init a base
setup in mock. 

We have pushed the langtable update 
https://admin.fedoraproject.org/updates/FEDORA-2013-10789/langtable-0.0.6-1.fc19
to stable and are re-running the branched compose. Should land in a few
hours. 

kevin


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

Re: rpmbuild --rebuild does not result in hardened build

[Panu Matilainen]

On 06/18/2013 04:21 PM, Reindl Harald wrote:

can someone lokk at this?
https://bugzilla.redhat.com/show_bug.cgi?id=975273

why are the hardening-macros not respected with rpmbuild?


Because of this (from 
https://bugzilla.redhat.com/show_bug.cgi?id=975273#c3):



[builduser@buildserver64:~]$ cat .rpmrc
optflags: x86_64 -m64 -O3 -march=corei7 -mtune=corei7 -fopenmp -mmmx 
-msse2 -msse3 -msse4.1 -msse4.2 -maes -pipe -fstack-protector 
--param=ssp-buffer-size=4 -mfpmath=sse -D_FORTIFY_SOURCE=2 -fexceptions


You're overriding the distro defaults and not including
%{__global_cflags} which a part of how the hardening flags (among all 
sorts of other distro defaults) get set for builds.


- Panu -

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

Re: icedtea-web installed and enabled by default in Fedora 19

[Pete Travis]

On Jun 17, 2013 9:03 AM, Bill Nottingham nott...@redhat.com wrote:
...
  
 
  I think given all the trouble this plugin has caused recently, it
wouldn't
  be wise to install it for everyone. If you need it, great, install it,
but
  if a users doesn't need it, it's really just creating a level of risk we
  probably don't want.
 
  Fedora currently has a reputation for being pretty secure, I think this
  could damage that reputation.

 The one issue I can see with removing it is that the plugin finder you
 then get in Firefox if you hit a Java site doesn't work to actually get
you
 the Fedora version.

 Bill
 --

+1

This is a strong argument for installing it by default. What would be more
secure - the distro maintained package or the user maintained tarball or
rpm without repo? The users that need help with security the most are the
users that will follow the inline instructions by rote, without searching
the repositories.

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

Re: icedtea-web installed and enabled by default in Fedora 19

[Josh Bressers]

 
 Is java environment the only security flawed software distributed in
 Fedora by default? I don't think so. Please, correct me if I'm wrong.
 Does it mean Fedora should drop about 1/3 of packages because they have
 security bugs? What about Linux Kernel? It's also buggy. Should it be not
 included in Fedora?
 

This is probably the wrong way to think of it. We're not telling anyone
they shouldn't be using the web plugin, we're saying it carries with it a
certain amount of risk. Should we subject all users, even the ones who
don't use this plugin, to that risk?

We've made similar decisions in the past. Why do we turn on the firewall,
or make Sendmail only listen on localhost? Sometimes it makes sense to make
a decision that lowers potential risk for most users while being a slight
inconvenience for other users. I think this plugin falls into that
category.

Thanks.

-- 
Josh Bressers / Red Hat Product Security Team
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: icedtea-web installed and enabled by default in Fedora 19

[Ismael Olea]

On Mon, Jun 17, 2013 at 4:32 PM, Bill Nottingham nott...@redhat.com wrote:


   We cannot really remove installed packages after the release, so I'm
  wondering if we still can fix this prior to release.

 We could, I suppose. What do people think? (It's just one line in comps.)


When I needed a java plugin (particularly for some government websites) I
always should got to install the Sun/Oracle one. In those cases icedtea-web
has been 100% useless to me :-/

My 2¢

-- 

Ismael Olea

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

Re: rpmbuild --rebuild does not result in hardened build

[Reindl Harald]

Am 18.06.2013 19:18, schrieb Panu Matilainen:
 On 06/18/2013 04:21 PM, Reindl Harald wrote:
 can someone lokk at this?
 https://bugzilla.redhat.com/show_bug.cgi?id=975273

 why are the hardening-macros not respected with rpmbuild?
 
 Because of this (from https://bugzilla.redhat.com/show_bug.cgi?id=975273#c3):
 
 [builduser@buildserver64:~]$ cat .rpmrc
 optflags: x86_64 -m64 -O3 -march=corei7 -mtune=corei7 -fopenmp -mmmx -msse2 
 -msse3 -msse4.1 -msse4.2 -maes -pipe
 -fstack-protector --param=ssp-buffer-size=4 -mfpmath=sse -D_FORTIFY_SOURCE=2 
 -fexceptions
 
 You're overriding the distro defaults and not including
 %{__global_cflags} which a part of how the hardening flags (among all sorts 
 of other distro defaults) get set for
 builds

because it ends in double options with different values
-O3 -O2 makes little sense and looks not predictable

IMHO the hardening-macro should ADD his params to whatever existing ones

-m64 -O3 -march=corei7 -mtune=corei7 -fopenmp -mmmx -msse2 -msse3 -msse4.1 
-msse4.2 -maes -pipe -fstack-protector
--param=ssp-buffer-size=4 -mfpmath=sse -D_FORTIFY_SOURCE=2 -fexceptions -O2 -g 
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4




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

Re: rpmbuild --rebuild does not result in hardened build

[Dan Horák]

On Tue, 18 Jun 2013 21:41:37 +0200
Reindl Harald h.rei...@thelounge.net wrote:

 
 
 Am 18.06.2013 19:18, schrieb Panu Matilainen:
  On 06/18/2013 04:21 PM, Reindl Harald wrote:
  can someone lokk at this?
  https://bugzilla.redhat.com/show_bug.cgi?id=975273
 
  why are the hardening-macros not respected with rpmbuild?
  
  Because of this (from
  https://bugzilla.redhat.com/show_bug.cgi?id=975273#c3):
  
  [builduser@buildserver64:~]$ cat .rpmrc
  optflags: x86_64 -m64 -O3 -march=corei7 -mtune=corei7 -fopenmp
  -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -maes -pipe -fstack-protector
  --param=ssp-buffer-size=4 -mfpmath=sse -D_FORTIFY_SOURCE=2
  -fexceptions
  
  You're overriding the distro defaults and not including
  %{__global_cflags} which a part of how the hardening flags (among
  all sorts of other distro defaults) get set for builds
 
 because it ends in double options with different values
 -O3 -O2 makes little sense and looks not predictable

the latter wins, it's specified by gcc docs


Dan

 IMHO the hardening-macro should ADD his params to whatever existing
 ones
 
 -m64 -O3 -march=corei7 -mtune=corei7 -fopenmp -mmmx -msse2 -msse3
 -msse4.1 -msse4.2 -maes -pipe -fstack-protector
 --param=ssp-buffer-size=4 -mfpmath=sse -D_FORTIFY_SOURCE=2
 -fexceptions -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
 -fstack-protector --param=ssp-buffer-size=4
 
 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Schedule for Wednesday's FESCo Meeting (2013-06-19)

[Kevin Fenzi]

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2013-06-19 18:00 UTC'

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

= Followups =

none

= New business =

#topic ticket #1123 Request owner change for dkms
.fesco 1123
https://fedorahosted.org/fesco/ticket/1123

#topic ticket #1125 httpd-itk broken over release because httpd updated without 
dependencies caring and maintainer refuse fixing
.fesco 1125
https://fedorahosted.org/fesco/ticket/1125

#topic ticket #1126 Need a procedure for tracking FESCo release blockers
.fesco 1126
https://fedorahosted.org/fesco/ticket/1126

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


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

Re: icedtea-web installed and enabled by default in Fedora 19

[Rahul Sundaram]

On 06/18/2013 02:59 PM, Ismael Olea wrote:



When I needed a java plugin (particularly for some government 
websites) I always should got to install the Sun/Oracle one. In those 
cases icedtea-web has been 100% useless to me :-/


The plugin used to be problematic before but have you tried it 
recently?  Do file a bug report if there are still issues


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

F-19 Branched report: 20130618 changes

[Fedora Branched Report]

Compose started at Tue Jun 18 17:12:36 UTC 2013

Broken deps for x86_64
--
[avgtime]
avgtime-0-0.5.git20120724.fc19.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[derelict]
derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg
derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG
derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg
derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG
derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq
derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires PQ
derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq
derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ
derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires pq
derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires PQ
derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq
derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ
derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires tcod
derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD
derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod
derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD
derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires tcod
derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD
derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod
derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD
[dragonegg]
dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19
[dsqlite]
dsqlite-1.0-4.fc19.i686 requires libphobos-ldc.so.60
dsqlite-1.0-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit)
[dustmite]
dustmite-1-8.20121031git1fb3ac4.fc18.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[freeipa]
freeipa-server-strict-3.2.1-1.fc19.x86_64 requires pki-ca = 0:10.0.2
freeipa-server-strict-3.2.1-1.fc19.x86_64 requires 389-ds-base = 
0:1.3.1.0
[gl3n]
gl3n-0.20120813-4.fc19.i686 requires libphobos-ldc.so.60
gl3n-0.20120813-4.fc19.x86_64 requires libphobos-ldc.so.60()(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
[koji]
koji-vm-1.8.0-1.fc19.noarch requires python-virtinst
[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
[nodejs-tilelive]
nodejs-tilelive-4.4.3-2.fc19.noarch requires npm(optimist)  0:0.4
[openbox]
gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel
gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires 
gnome-panel
[ovirt-engine]
ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires 
classpathx-mail
[ovirt-guest-agent]
ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires 
libgdmsimplegreeter.so.1()(64bit)
[perl-Bio-ASN1-EntrezGene]
perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires 
perl(Bio::Index::AbstractSeq)
[perl-Bio-SamTools]
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires 
perl(Bio::SeqFeature::Lite)
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq)
[python-TraitsBackendQt]
python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI
[scala]
scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library)
[spacewalk-web]
spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup)
[tango]
tango-2-12.20120821git7b92443.fc19.i686 requires libphobos-ldc.so.60
tango-2-12.20120821git7b92443.fc19.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[zarafa]
php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64
php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64



Broken deps for i386
--
[avgtime]
avgtime-0-0.5.git20120724.fc19.i686 requires libphobos-ldc.so.60
[derelict]
derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg
derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG
derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq
derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires PQ

Fedora 19 Final status, testing/karma requests and needed fixes

[Adam Williamson]

It feels like time for a status summary mail again!

Fedora 19 Final TC5 is the current compose: it contains most of the
final churn for F19, change should be fairly restricted from here on
out. So this is a good time to take stock of where we are and get all
testing done.

tl;dr summary
-

Desktop team: please look at reducing size of desktop live (958426)
Installer team: please fix 924162
Selinux team: please roll a new selinux-policy ASAP (964006)
Releng team: when a new selinux-policy is available, roll some new cloud
test images (964006)

Karma required for:

https://admin.fedoraproject.org/updates/gnome-initial-setup-0.12-1.fc19
https://admin.fedoraproject.org/updates/gnome-packagekit-3.8.2-2.fc19
https://admin.fedoraproject.org/updates/livecd-tools-19.5-1.fc19
https://admin.fedoraproject.org/updates/python-meh-0.25-1.fc19
https://admin.fedoraproject.org/updates/xorg-x11-drv-qxl-0.1.1-0.9.20130514git77a1594.fc19

Blocker status
--

https://qa.fedoraproject.org/blockerbugs/milestone/19/final/buglist is
the current list of proposed and accepted blockers and freeze exception
bugs.

There are a half dozen proposed blockers that we will be voting on at
tomorrow's blocker review meeting. Please do come out to the blocker
review meeting and provide your input if you possibly can, especially if
you're a reporter of a proposed blocker or a maintainer of an affected
component.

975159  anacondaMODIFIEDUnicodeDecodeError: 'ascii' codec can't 
decode byte 0xc4 in position 0: ordinal not in range(128)   
975537  anacondaASSIGNEDBootLoaderError: failed to remove old 
efi boot entry
974711  fedora-logosNEW Drop HAL and beefy install 'ad banners' 
for F19 final(?)
975204  mesaMODIFIEDradeon card lost opengl 3.1 support 
974691  rsyslog NEW Since cleaning up from #974132, nothing 
gets written to /var/log/messages   
679486  xorg-x11-xauth  ASSIGNEDLiveinst doesn't start if hostname 
changes

Here's the status of the accepted blockers:

964586 - Anaconda does not isntall ntfs tools to allow OS-Prober to
find windows partition and therefore creates no grub.cfg entry - this
ought to be fixed in Final TC5 and just needs to be tested. The test is
to do a (BIOS) minimal install of Fedora 19 alongside a (BIOS) install
of Windows and check that a grub entry for the Windows install is
created.

971191 - DVD install option unavailable in TUI - a fix for this
narrowly missed TC5, and will be in the next build. We could test it
with an updates.img in the mean time.

971763 - disable updates-testing - this is mostly a 'reminder' bug to
put a 'final' version of fedora-release into RC1. No action needed yet.

968951 - g-i-s created user's accounts and settings are copied to new
users created after g-i-s completes but before a reboot - the fix for
this is in Final TC5, I have verified it appears to work. Further
verification would be welcome, and the update that fixes it -
https://admin.fedoraproject.org/updates/gnome-initial-setup-0.12-1.fc19
- needs karma.

969852 - Software Update fails to update - two people have verified
the fix for this. The update that fixes it -
https://admin.fedoraproject.org/updates/gnome-packagekit-3.8.2-2.fc19 -
needs karma.

958426 - 19 Final TC1 x86_64 Desktop Live is oversized (larger than 1
GB) - we need the desktop team to look at fixing this. At this point,
as noted above, repo and spin-kickstarts churn should be mostly done, so
now's the time to take a look at what's in the TC5 image and start
cutting.

974784 - live image composing in koji broken - the fix for this,
https://admin.fedoraproject.org/updates/livecd-tools-19.5-1.fc19 , is
clearly good, or else we wouldn't have TC5 lives. The update has
sufficient karma to go stable, so no action needed here.

974032 - bug reporting doesn't work from LiveCD - the update that
fixes this just barely missed TC5. It may be possible to test it by
booting the TC5 live and doing 'yum update python-meh' before
installing, otherwise it may have to wait for TC6. The update that
should fix it,
https://admin.fedoraproject.org/updates/python-meh-0.25-1.fc19 , needs
karma.

964006 - cloud-init hostname service failing on initial boot - we have
initial indication that the planned fix for this works, but we need a
new selinux-policy to be built and new cloud images built with that
selinux-policy to confirm.

974198 - missing letters on various anaconda screens with spice
graphics - the fix for this has been reported to work by one tester,
but it'd be good if other testers could confirm it. The update that
fixes it -
https://admin.fedoraproject.org/updates/xorg-x11-drv-qxl-0.1.1-0.9.20130514git77a1594.fc19
 - needs karma.

924162 - A software selection with dependency errors is allowed to
proceed if the dependency check runs twice - we are waiting on a fix
for this one. Looks like progress is being made in that direction,

[Test-Announce] 2013-06-19 @ 16:00 UTC - F19 Final Blocker Bug Review #7

[Tim Flink]

# F19 Final Blocker Review meeting #7
# Date: 2013-06-19
# Time: 16:00 UTC (12:00 EDT, 09:00 PDT)
# Location: #fedora-blocker-review on irc.freenode.net

F19 final freeze has set in and it's once again time to review blocker
and freeze exception bugs!

We'll be running through the final blockers and freeze exception bugs.
The current list is available at:
http://qa.fedoraproject.org/blockerbugs/current

We'll be reviewing the bugs to determine ...

1. Whether they meet the final release criteria [1] and should stay
  on the list
2. Whether they are getting the attention they need

[1] http://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria

For guidance on Blocker and FreezeException bugs, please refer to
  - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
  - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

For the blocker review meeting protocol, see
  - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting


signature.asc
Description: PGP 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: icedtea-web installed and enabled by default in Fedora 19

[Dhiru Kholia]

On 06/18/13 at 01:50pm, Josh Bressers wrote:
  Is java environment the only security flawed software distributed in
  Fedora by default? I don't think so. Please, correct me if I'm
  wrong.  Does it mean Fedora should drop about 1/3 of packages
  because they have security bugs? What about Linux Kernel? It's also
  buggy. Should it be not included in Fedora?

 This is probably the wrong way to think of it. We're not telling anyone
 they shouldn't be using the web plugin, we're saying it carries with it a
 certain amount of risk. Should we subject all users, even the ones who
 don't use this plugin, to that risk?

Some recent news,

http://www.theregister.co.uk/2013/06/14/java_june_critical_patch_update/

The majority are vulnerable through browser plugins, 11 of which are
exploitable for complete control of the underlying operating system,
said Ross Barrett, senior manager of security engineering at Rapid7.

...

This is not the first time that so many (40!) security bugs have been
found and fixed in Java.

I don't think that any Fedora package has a worse security record than
Java stuff in recent times.

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

[Bug 971721] perl-Locale-Codes-3.26 is available

[bugzilla]

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

--- Comment #7 from Fedora Update System upda...@fedoraproject.org ---
perl-Locale-Codes-3.26-1.fc19 has been pushed to the Fedora 19 stable
repository.  If problems still persist, please make note of it in this bug
report.

-- 
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=TFRPZxlLEVa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 971726] perl-Test-Reporter-1.59 is available

[bugzilla]

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

--- Comment #5 from Fedora Update System upda...@fedoraproject.org ---
perl-Test-Reporter-1.59-1.fc19 has been pushed to the Fedora 19 stable
repository.  If problems still persist, please make note of it in this bug
report.

-- 
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=9efO1qDlLDa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 971725] perl-Term-UI-0.36 is available

[bugzilla]

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

--- Comment #3 from Fedora Update System upda...@fedoraproject.org ---
perl-Term-UI-0.36-1.fc19 has been pushed to the Fedora 19 stable repository. 
If problems still persist, please make note of it in this bug report.

-- 
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=vt980Hw5Ika=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 957931] perl-Carp-1.26-242.fc18.noarch remains following fedup f18 -- f19 upgrade

[bugzilla]

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

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
   Assignee|mmasl...@redhat.com |ppi...@redhat.com
Last Closed||2013-06-18 03:10:49

-- 
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=7DnAzkF2FUa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl/f19] Remove bundled CPANPLUS-Dist-Build

[Petr Pisar]

commit 7efddc19e9d38350ec9fc0d9ca73cda5c7bf
Author: Petr Písař ppi...@redhat.com
Date:   Fri Jun 14 12:58:56 2013 +0200

Remove bundled CPANPLUS-Dist-Build

 perl.spec |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index 96e6ee4..f9f722b 100644
--- a/perl.spec
+++ b/perl.spec
@@ -520,6 +520,7 @@ The CPANPLUS library is an API to the CPAN mirrors and a 
collection of
 interactive shells, commandline programs, etc, that use this API.
 %endif
 
+%if %{dual_life} || %{rebuild_from_scratch}
 %package CPANPLUS-Dist-Build
 Summary:Module::Build extension for CPANPLUS
 Group:  Development/Libraries
@@ -535,6 +536,7 @@ BuildArch:  noarch
 CPANPLUS::Dist::Build is a distribution class for Module::Build related
 modules. With this package, you can create, install and uninstall
 Module::Build-based perl modules by calling CPANPLUS::Dist methods.
+%endif
 
 %if %{dual_life} || %{rebuild_from_scratch}
 %package Data-Dumper
@@ -2673,11 +2675,13 @@ sed \
 %{_mandir}/man3/CPANPLUS*
 %endif
 
+%if %{dual_life} || %{rebuild_from_scratch}
 %files CPANPLUS-Dist-Build
 %{privlib}/CPANPLUS/Dist/Build/
 %{privlib}/CPANPLUS/Dist/Build.pm
 %{_mandir}/man3/CPANPLUS::Dist::Build.3*
 %{_mandir}/man3/CPANPLUS::Dist::Build::*
+%endif
 
 %if %{dual_life} || %{rebuild_from_scratch}
 %files Data-Dumper
@@ -3233,6 +3237,7 @@ sed \
 - Move CPAN-Meta-Requirements files from CPAN-Meta
 - Add perl-Scalar-List-Utils to perl-core dependencies
 - Do not distribute File::Spec::VMS (bug #973713)
+- Remove bundled CPANPLUS-Dist-Build (bug #973041)
 
 * Mon May 13 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-264
 - Use lib64 directories on aarch64 architecture (bug #961900)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl/f19] Move CPAN-Meta-Requirements files from CPAN-Meta

[Petr Pisar]

commit e7d6490e40037d9c16c85098247775ee4e1e5859
Author: Petr Písař ppi...@redhat.com
Date:   Tue Jun 11 16:39:12 2013 +0200

Move CPAN-Meta-Requirements files from CPAN-Meta

 perl.spec |   31 ++-
 1 files changed, 30 insertions(+), 1 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index e74f2c3..f5a2a28 100644
--- a/perl.spec
+++ b/perl.spec
@@ -468,6 +468,23 @@ in CPAN::Meta::Spec.
 %endif
 
 %if %{dual_life} || %{rebuild_from_scratch}
+%package CPAN-Meta-Requirements
+Summary:Set of version requirements for a CPAN dist
+Epoch:  0
+Version:2.120.630
+License:GPL+ or Artistic
+Group:  Development/Libraries
+Requires:   %perl_compat
+BuildArch:  noarch
+
+%description CPAN-Meta-Requirements
+A CPAN::Meta::Requirements object models a set of version constraints like
+those specified in the META.yml or META.json files in CPAN distributions.
+It can be built up by adding more and more constraints, and it will reduce
+them to the simplest representation.
+%endif
+
+%if %{dual_life} || %{rebuild_from_scratch}
 %package CPAN-Meta-YAML
 Version:0.007
 Epoch:  0
@@ -1602,7 +1619,8 @@ Requires:   perl-macros
 Requires:   perl-Archive-Extract, perl-Archive-Tar, perl-autodie
 Requires:   perl-B-Lint, perl-Compress-Raw-Bzip2,
 Requires:   perl-Carp, perl-Compress-Raw-Zlib, perl-CGI, perl-CPAN,
-Requires:   perl-CPAN-Meta, perl-CPAN-Meta-YAML, perl-CPANPLUS
+Requires:   perl-CPAN-Meta, perl-CPAN-Meta-Requirements
+Requires:   perl-CPAN-Meta-YAML, perl-CPANPLUS
 Requires:   perl-CPANPLUS-Dist-Build, perl-Encode
 Requires:   perl-Data-Dumper, perl-Digest, perl-Digest-MD5, 
perl-Digest-SHA,
 Requires:   perl-ExtUtils-CBuilder, perl-ExtUtils-Embed,
@@ -2024,6 +2042,10 @@ sed \
 %exclude %{privlib}/CPAN/Meta/Validator.pm
 %exclude %{_mandir}/man3/CPAN::Meta*
 
+# CPAN-Meta-Requirements
+%exclude %{privlib}/CPAN/Meta/Requirements.pm
+%exclude %{_mandir}/man3/CPAN::Meta::Requirements.3*
+
 # CPAN-Meta-YAML
 %exclude %{privlib}/CPAN/Meta/YAML.pm
 %exclude %{_mandir}/man3/CPAN::Meta::YAML*
@@ -2622,6 +2644,12 @@ sed \
 %endif
 
 %if %{dual_life} || %{rebuild_from_scratch}
+%files CPAN-Meta-Requirements
+%{privlib}/CPAN/Meta/Requirements.pm
+%{_mandir}/man3/CPAN::Meta::Requirements.3*
+%endif
+
+%if %{dual_life} || %{rebuild_from_scratch}
 %files CPAN-Meta-YAML
 %{privlib}/CPAN/Meta/YAML.pm
 %{_mandir}/man3/CPAN::Meta::YAML*
@@ -3197,6 +3225,7 @@ sed \
 %changelog
 * Tue Jun 18 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-265
 - Move CPANPLUS-Dist-Build files from perl-CPANPLUS
+- Move CPAN-Meta-Requirements files from CPAN-Meta
 
 * Mon May 13 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-264
 - Use lib64 directories on aarch64 architecture (bug #961900)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl/f19] Add perl-Scalar-List-Utils to perl-core dependencies

[Petr Pisar]

commit 45c089c0c000d8b7bd1c287f89891e83f6dba40f
Author: Petr Písař ppi...@redhat.com
Date:   Tue Jun 11 17:11:48 2013 +0200

Add perl-Scalar-List-Utils to perl-core dependencies

 perl.spec |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index f5a2a28..3e8febb 100644
--- a/perl.spec
+++ b/perl.spec
@@ -1637,7 +1637,7 @@ Requires:   perl-Module-Pluggable, 
perl-Object-Accessor, perl-Package-Consta
 Requires:   perl-Params-Check, perl-Parse-CPAN-Meta, perl-Perl-OSType
 Requires:   perl-Pod-Checker, perl-Pod-Escapes, perl-Pod-LaTeX
 Requires:   perl-Pod-Parser, perl-Pod-Perldoc, perl-Pod-Usage
-Requires:   perl-podlators, perl-Pod-Simple
+Requires:   perl-podlators, perl-Pod-Simple, perl-Scalar-List-Utils
 Requires:   perl-Socket, perl-Sys-Syslog, perl-Term-UI, perl-Test-Harness,
 Requires:   perl-Test-Simple
 Requires:   perl-Text-ParseWords, perl-Text-Soundex, perl-Thread-Queue
@@ -3226,6 +3226,7 @@ sed \
 * Tue Jun 18 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-265
 - Move CPANPLUS-Dist-Build files from perl-CPANPLUS
 - Move CPAN-Meta-Requirements files from CPAN-Meta
+- Add perl-Scalar-List-Utils to perl-core dependencies
 
 * Mon May 13 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-264
 - Use lib64 directories on aarch64 architecture (bug #961900)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl/f19] Move CPANPLUS-Dist-Build files from perl-CPANPLUS

[Petr Pisar]

commit 93f3edbb0c973ab9d55e5987de1d826079350fc8
Author: Petr Písař ppi...@redhat.com
Date:   Tue Jun 11 15:40:07 2013 +0200

Move CPANPLUS-Dist-Build files from perl-CPANPLUS

 perl.spec |   34 ++
 1 files changed, 30 insertions(+), 4 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index f9936d8..e74f2c3 100644
--- a/perl.spec
+++ b/perl.spec
@@ -31,7 +31,7 @@
 Name:   perl
 Version:%{perl_version}
 # release number must be even higher, because dual-lived modules will be 
broken otherwise
-Release:264%{?dist}
+Release:265%{?dist}
 Epoch:  %{perl_epoch}
 Summary:Practical Extraction and Report Language
 Group:  Development/Languages
@@ -496,8 +496,6 @@ Requires:   perl(Digest::SHA)
 Requires:   perl(Module::Pluggable) = 2.4
 Requires:   perl(Module::CoreList)
 Requires:   %perl_compat
-Provides:   perl-CPANPLUS-Dist-Build = 0.54
-Obsoletes:  perl-CPANPLUS-Dist-Build = 0.05
 BuildArch:  noarch
 
 %description CPANPLUS
@@ -505,6 +503,22 @@ The CPANPLUS library is an API to the CPAN mirrors and a 
collection of
 interactive shells, commandline programs, etc, that use this API.
 %endif
 
+%package CPANPLUS-Dist-Build
+Summary:Module::Build extension for CPANPLUS
+Group:  Development/Libraries
+License:GPL+ or Artistic
+Epoch:  0
+Version:0.62
+Requires:   %perl_compat
+# This is a plug-in for CPANPLUS, specify reverse dependency here
+Requires:   perl(CPANPLUS)
+BuildArch:  noarch
+
+%description CPANPLUS-Dist-Build
+CPANPLUS::Dist::Build is a distribution class for Module::Build related
+modules. With this package, you can create, install and uninstall
+Module::Build-based perl modules by calling CPANPLUS::Dist methods.
+
 %if %{dual_life} || %{rebuild_from_scratch}
 %package Data-Dumper
 Summary:Stringify perl data structures, suitable for printing and eval
@@ -1588,7 +1602,8 @@ Requires:   perl-macros
 Requires:   perl-Archive-Extract, perl-Archive-Tar, perl-autodie
 Requires:   perl-B-Lint, perl-Compress-Raw-Bzip2,
 Requires:   perl-Carp, perl-Compress-Raw-Zlib, perl-CGI, perl-CPAN,
-Requires:   perl-CPAN-Meta, perl-CPAN-Meta-YAML, perl-CPANPLUS, perl-Encode
+Requires:   perl-CPAN-Meta, perl-CPAN-Meta-YAML, perl-CPANPLUS
+Requires:   perl-CPANPLUS-Dist-Build, perl-Encode
 Requires:   perl-Data-Dumper, perl-Digest, perl-Digest-MD5, 
perl-Digest-SHA,
 Requires:   perl-ExtUtils-CBuilder, perl-ExtUtils-Embed,
 Requires:   perl-ExtUtils-Install, perl-ExtUtils-MakeMaker
@@ -2020,6 +2035,7 @@ sed \
 %exclude %{_mandir}/man3/Parse::CPAN::Meta.3*
 
 # CPANPLUS
+# CPANPLUS-Dist-Build
 %exclude %{_bindir}/cpan2dist
 %exclude %{_bindir}/cpanp
 %exclude %{_bindir}/cpanp-run-perl
@@ -2618,11 +2634,18 @@ sed \
 %{_bindir}/cpanp-run-perl
 %{privlib}/CPANPLUS/
 %{privlib}/CPANPLUS.pm
+%exclude %{privlib}/CPANPLUS/Dist/Build/
 %{_mandir}/man1/cpan2dist.1*
 %{_mandir}/man1/cpanp.1*
 %{_mandir}/man3/CPANPLUS*
 %endif
 
+%files CPANPLUS-Dist-Build
+%{privlib}/CPANPLUS/Dist/Build/
+%{privlib}/CPANPLUS/Dist/Build.pm
+%{_mandir}/man3/CPANPLUS::Dist::Build.3*
+%{_mandir}/man3/CPANPLUS::Dist::Build::*
+
 %if %{dual_life} || %{rebuild_from_scratch}
 %files Data-Dumper
 %dir %{archlib}/auto/Data
@@ -3172,6 +3195,9 @@ sed \
 
 # Old changelog entries are preserved in CVS.
 %changelog
+* Tue Jun 18 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-265
+- Move CPANPLUS-Dist-Build files from perl-CPANPLUS
+
 * Mon May 13 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-264
 - Use lib64 directories on aarch64 architecture (bug #961900)
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl/f19] Do not distribute File::Spec::VMS

[Petr Pisar]

commit 16fe23a87f79cc839c032168b270dd2b678c6f3c
Author: Petr Písař ppi...@redhat.com
Date:   Fri Jun 14 11:15:16 2013 +0200

Do not distribute File::Spec::VMS

 perl.spec |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index 3e8febb..96e6ee4 100644
--- a/perl.spec
+++ b/perl.spec
@@ -1855,6 +1855,11 @@ ln -s ../../../bin/xsubpp %{build_privlib}/ExtUtils/
 # Don't need the .packlist
 rm %{build_archlib}/.packlist
 
+# Do not distribute File::Spec::VMS as it works on VMS only (bug #973713)
+# We cannot remove it in %%prep because dist/Cwd/t/Spec.t test needs it.
+rm %{build_archlib}/File/Spec/VMS.pm
+rm $RPM_BUILD_ROOT%{_mandir}/man3/File::Spec::VMS.3*
+
 # Fix some manpages to be UTF-8
 mkdir -p $RPM_BUILD_ROOT%{_mandir}/man1/
 pushd $RPM_BUILD_ROOT%{_mandir}/man1/
@@ -3227,6 +3232,7 @@ sed \
 - Move CPANPLUS-Dist-Build files from perl-CPANPLUS
 - Move CPAN-Meta-Requirements files from CPAN-Meta
 - Add perl-Scalar-List-Utils to perl-core dependencies
+- Do not distribute File::Spec::VMS (bug #973713)
 
 * Mon May 13 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-264
 - Use lib64 directories on aarch64 architecture (bug #961900)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 973713] File::Spec::VMS not usable due missing VMS/Filespec.pm

[bugzilla]

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

--- Comment #3 from Fedora Update System upda...@fedoraproject.org ---
perl-5.16.3-265.fc19,perl-CPANPLUS-Dist-Build-0.70-2.fc19,perl-CPANPLUS-0.91.38-1.fc19
has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/perl-5.16.3-265.fc19,perl-CPANPLUS-Dist-Build-0.70-2.fc19,perl-CPANPLUS-0.91.38-1.fc19

-- 
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=tHJgObGLzBa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Bio-ASN1-EntrezGene

[buildsys]

perl-Bio-ASN1-EntrezGene has broken dependencies in the rawhide tree:
On x86_64:
perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires 
perl(Bio::Index::AbstractSeq)
On i386:
perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires 
perl(Bio::Index::AbstractSeq)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-PDL

[buildsys]

perl-PDL has broken dependencies in the rawhide tree:
On x86_64:
perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit)
On i386:
perl-PDL-2.4.10-6.fc19.i686 requires libgd.so.2
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Bio-SamTools

[buildsys]

perl-Bio-SamTools has broken dependencies in the rawhide tree:
On x86_64:
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires 
perl(Bio::SeqFeature::Lite)
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq)
On i386:
perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite)
perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[pkgdb] perl-Gtk2-Ex-FormFactory ownership changed

[Fedora PackageDB]

Package perl-Gtk2-Ex-FormFactory in Fedora devel is now owned by ppisar

To make changes to this package see:
  https://admin.fedoraproject.org/pkgdb/acls/name/perl-Gtk2-Ex-FormFactory
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[pkgdb] perl-Gtk2-Ex-FormFactory ownership changed

[Fedora PackageDB]

Package perl-Gtk2-Ex-FormFactory in Fedora 19 is now owned by ppisar

To make changes to this package see:
  https://admin.fedoraproject.org/pkgdb/acls/name/perl-Gtk2-Ex-FormFactory
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Gtk2-Ex-FormFactory] Modernize spec file

[Petr Pisar]

commit 5e41237a9ab54427f90b5f1d8c808c215a82b069
Author: Petr Písař ppi...@redhat.com
Date:   Tue Jun 18 16:49:30 2013 +0200

Modernize spec file

 perl-Gtk2-Ex-FormFactory.spec |   81 -
 1 files changed, 40 insertions(+), 41 deletions(-)
---
diff --git a/perl-Gtk2-Ex-FormFactory.spec b/perl-Gtk2-Ex-FormFactory.spec
index 707c999..80c9eaf 100644
--- a/perl-Gtk2-Ex-FormFactory.spec
+++ b/perl-Gtk2-Ex-FormFactory.spec
@@ -1,77 +1,76 @@
 Name:   perl-Gtk2-Ex-FormFactory
 Version:0.67
-Release:4%{?dist}
-Summary:Framework for Gtk2 perl applications
-
+Release:5%{?dist}
+Summary:Framework for GTK2 Perl applications
 Group:  Development/Libraries
 License:LGPLv2+
 URL:http://www.exit1.org/Gtk2-Ex-FormFactory/
 Source0:
http://www.exit1.org/packages/Gtk2-Ex-FormFactory/dist/Gtk2-Ex-FormFactory-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
 BuildArch:  noarch
+BuildRequires:  perl
 BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(strict)
+# Run-time:
+BuildRequires:  perl(base)
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(Data::Dumper)
+BuildRequires:  perl(File::Basename)
 BuildRequires:  perl(Gtk2)
+BuildRequires:  perl(Gtk2::SimpleList)
+BuildRequires:  perl(Gtk2::SimpleMenu)
+BuildRequires:  perl(POSIX)
+BuildRequires:  perl(Scalar::Util)
+# Time::Local not used by tests
+# Tests:
 BuildRequires:  perl(Test::More)
-
-Requires:  perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
 
 %description
-Gtk2::Ex::FormFactory is a framework for Perl Gtk2 developers.
+This is a framework which tries to make building complex GUI's easy, by
+offering these two main features:
+
+Consistent looking GUI without the need to code resp. tune each widget by
+hand. Instead you declare the structure of your GUI, connect it to the data of
+your program (which should be a well defined set of objects) and control how
+this structure is transformed into a specific layout in a very generic way.
+
+Automatically keep widget and object states in synchronization (in both
+directions), even with complex data structures with a lot of internal
+dependencies, object nesting etc.
+
+%{?perl_default_filter}
 
 %prep
 %setup -q -n Gtk2-Ex-FormFactory-%{version}
-# Make it so that the .pl scripts in %%doc don't add bogus requirements
-chmod -x examples/* tutorial/*
 # Convert encoding
 for f in $(find lib/ -name *.pm) README tutorial/README; do
-cp -p ${f} ${f}.noutf8
-iconv -f ISO-8859-1 -t UTF-8 ${f}.noutf8  ${f}
-touch -r ${f}.noutf8 ${f}
-rm ${f}.noutf8
+cp -p ${f} ${f}.noutf8
+iconv -f ISO-8859-1 -t UTF-8 ${f}.noutf8  ${f}
+touch -r ${f}.noutf8 ${f}
+rm ${f}.noutf8
 done
 
-# Filter unwanted Provides:
-cat  \EOF  %{name}-prov
-#!/bin/sh
-%{__perl_provides} $* |\
-  sed -e '/^perl(Music/d'
-
-EOF
-
-%define __perl_provides 
%{_builddir}/Gtk2-Ex-FormFactory-%{version}/%{name}-prov
-chmod +x %{name}-prov
-
-
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
 
-
 %install
-rm -rf $RPM_BUILD_ROOT
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-
-chmod 644 $RPM_BUILD_ROOT%{_mandir}/man3/*
-
+chmod -R u+w $RPM_BUILD_ROOT/*
 
 %check
 make test
 
-
-%clean
-rm -rf $RPM_BUILD_ROOT
-
-
 %files
-%defattr(-,root,root,-)
-%doc Changes examples/ LICENSE README tutorial/
+%doc examples/ Changes LICENSE README tutorial/
 %{perl_vendorlib}/Gtk2/
 %{_mandir}/man3/*.3*
 
-
 %changelog
+* Tue Jun 18 2013 Petr Pisar ppi...@redhat.com - 0.67-5
+- Modernize spec file
+
 * Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.67-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Bio-ASN1-EntrezGene

[buildsys]

perl-Bio-ASN1-EntrezGene has broken dependencies in the F-19 tree:
On x86_64:
perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires 
perl(Bio::Index::AbstractSeq)
On i386:
perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires 
perl(Bio::Index::AbstractSeq)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Bio-SamTools

[buildsys]

perl-Bio-SamTools has broken dependencies in the F-19 tree:
On x86_64:
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires 
perl(Bio::SeqFeature::Lite)
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq)
On i386:
perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite)
perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 971714] perl-Date-Manip-6.40 is available

[bugzilla]

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

--- Comment #5 from Fedora Update System upda...@fedoraproject.org ---
perl-Date-Manip-6.40-1.fc17 has been pushed to the Fedora 17 stable repository.
 If problems still persist, please make note of it in this bug report.

-- 
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=1ioevbc9RUa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 971714] perl-Date-Manip-6.40 is available

[bugzilla]

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

--- Comment #6 from Fedora Update System upda...@fedoraproject.org ---
perl-Date-Manip-6.40-1.fc18 has been pushed to the Fedora 18 stable repository.
 If problems still persist, please make note of it in this bug report.

-- 
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=fVyfI96AYKa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[389-devel] WinSync: uniquemember not updated if user moved from one OU to an other OU

[Carsten Grzemba]

In an Winsync setup AD-DS (oneWay: fromWindows) we have the problem that the 
uniquemember attribute of groups will not updated if a user moved from on OU to 
an other.
Winsync will only update the user itself and not the groups where it is 
memberof. 
This behaviour is similar like described in ticket 31 manager attribute not 
updated.

Referential integrity plugin is enabled and setup for uniquemember, but I don't 
know if this work in a winsync environment.

Is this a know problem?

observed in version 1.2.11.15
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

[389-devel] please review: Ticket 47389 - Non-directory manager can change the individual userPassword's storage scheme

[Mark Reynolds]

https://fedorahosted.org/389/ticket/47389

https://fedorahosted.org/389/attachment/ticket/47389/0001-Ticket-47389-Non-directory-manager-can-change-the-in.patch

Thanks,
Mark

--
Mark Reynolds
Red Hat, Inc
mreyno...@redhat.com

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