Re: *countable infinities only

2012-06-05 Thread Tomas Mraz
On Mon, 2012-06-04 at 21:30 -0500, Dennis Gilmore wrote: 
 El Sat, 2 Jun 2012 12:18:17 -0400
 Orcan Ogetbil oget.fed...@gmail.com escribió:
  On Sat, Jun 2, 2012 at 12:05 PM, Jesse Keating wrote:
  
   The only Freedom you've lost is that now, in addition to the
   person-hours to do the work and monetary cost to host your bits or
   generate physical media, you have an additional cost if you wish to
   have your own cert that will be accepted out of the box by the next
   generation of PC hardware.  You have as much equal footing as
   Fedora does to plunk down the $99 and play along in the PC sandbox.
That's a better deal than Fedora's gpg signing setup.
  
  
  Hmm, will the package maintainers have the freedom to not support
  users who have the secureboot enabled? How are we going to detect
  this?
 
 i look at it this way. if you patch your software to only run on
 machines with secureboot disabled your software then becomes non free
 and has to be removed from fedora.  this is becasuse you are placing
 usage restrictions on it. depending on the license of the software
 adding such a restriction would violate the license. I am not a lawyer
 at all and never pretend to play one, but i do not think you as a
 package maintainer can do that. an upstream could, but i imagine it
 would be viewed in the same light as a commercial use restriction and
 become non-free.

That's a total nonsense unless the restriction is by-license and not
just technical obstacle. If it is just a technical obstacle in the code,
you can remove it and run the software on any crippled machine at your
will. So no, making your software not to work on particular machines
does not make it non-free at all.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

Re: Notice: Retiring vbetool in F18

2012-06-05 Thread Petr Pisar
On 2012-06-04, Adam Jackson a...@redhat.com wrote:

 Historically the only thing requiring vbetool was pm-utils, but that's
 not been true in a nice long time:

 * Fri Oct 08 2010 Adam Jackson a...@redhat.com 1.3.1-2
 - Drop the vbetool dependency, suspend is only supported on KMS drivers.

 That was F14 gold:

 % koji -q latest-pkg dist-f14 pm-utils
 pm-utils-1.3.1-2.fc14 dist-f14  ajax

 In lieu of flowers, please send patches for KMS drivers to
 dri-de...@lists.freedesktop.org.

How can I reset the graphics card using KMS (vbetool post)?

-- Petr

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

Guacamole Java Web Application

2012-06-05 Thread Simone Caronni
Hello,

sorry for double posting to devel and java-devel but the last seems not so
crowded.

On 24 May 2012 12:04, Simone Caronni negativ...@gmail.com wrote:

 following the mail in fedora-devel, I'm posting here some progress in
 packaging the Guacamole stack for Fedora. I hope to get some advice
 from Fedora Java gurus...


guacamole-common and guacamole-common-ext are now into rawhide and I've
been struggling a couple of days for the next parts.
I need some help with the guacamole-common-js [1][2]; the last step before
packaging the web application itself [3].

The build itself is normally generated with the command maven package; so
replacing it with mvn-rpmbuild package generates the following file.

How's the supposed guideline for packaging it? Where should I put the zip
file and how should the spec file be structured?
All the other java classes for Guacamole are into jars in
/usr/share/java/guacamole/.

I can't find any useful information for it in the Java packaging pages [4].
I tried to look at at least 20 java packages in fedora and could not find
one that was not packaging a jar file.

$ unzip -l ./target/guacamole-common-js-
0.6.0-guacamole-common-js.zip
Archive:  ./target/guacamole-common-js-0.6.0-guacamole-common-js.zip
  Length  DateTimeName
-  -- -   
0  05-05-2012 04:32   guacamole-common-js/
17214  05-05-2012 04:32   guacamole-common-js/mouse.js
31710  05-05-2012 04:32   guacamole-common-js/guacamole.js
17640  05-05-2012 04:32   guacamole-common-js/oskeyboard.js
12621  05-05-2012 04:32   guacamole-common-js/keyboard.js
24977  05-05-2012 04:32   guacamole-common-js/tunnel.js
37152  05-05-2012 04:32   guacamole-common-js/layer.js
- ---
   141314 7 files

[1] http://guac-dev.org/guacamole-common-js
[2]
http://slaanesh.fedorapeople.org/guacamole-common-js-0.6.0-1.fc17.src.rpm
[3] http://guac-dev.org/guacamole
[4] https://fedoraproject.org/wiki/Packaging:Java


Thanks,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: supercat anybody working on it?

2012-06-05 Thread Michael Schwendt
On Sat, 02 Jun 2012 20:16:49 -0700, Garrett Holmstrom wrote:

 On 6/2/2012 7:03 PM, Adrian Alves wrote:
  am not following what u mean?

Please don't top-post, Adrian. Top-posting makes it much more difficult to
understand what you refer to, especially since you've asked a question.

  On Sat, Jun 2, 2012 at 5:30 AM, Michael Schwendt wrote:
  On Fri, 1 Jun 2012 23:00:29 -0300, Adrian Alves wrote:
  done I built it, check this out:
 
  Spec URL: http://alvesadrian.fedorapeople.org/supercat.spec
 
  Check this out:
 
 This means to read the following link because it describes a mistake 
 that your spec file makes:

Exactly. After reading the following page, you should be able to find
the unowned directory in your package. At least try to find it.
And if you don't find it or if you think there is no unowned directory
in your spec file, mention that and it could be discussed further.

  https://fedoraproject.org/wiki/Packaging:UnownedDirectories
 
  And the following page is _not_ just for reviewers: ;-)
 
 This means to read the following link because it is wise to follow the 
 packaging guidelines even before formally submitting a package for review:
 
  https://fedoraproject.org/wiki/Packaging:ReviewGuidelines

A sponsored packager should be capable of reviewing others' packages,
for example to offer trading reviews. With the help of the ReviewGuidelines
page -- and particularly, the first MUST item on that list -- you should
find more mistakes in your supercat.spec file. It is good habit to not just
wait for a reviewer to do all the work, but perform a self-review and
declare whether a spec file is supposed to meet the guidelines or whether
there is something questionable you would like to discuss with a reviewer.

-- 
Fedora release 17 (Beefy Miracle) - Linux 3.3.7-1.fc17.x86_64
loadavg: 0.09 0.28 0.29
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: wine font changes system look and feel

2012-06-05 Thread Kamil Paral
Andreas wrote:
 Hi,
 
 first I would like to point out that I am totally open for a
 discussion
 about this. IMO bugzilla is just not the right place for it.

Thanks, that's great.

Chris wrote:
 Well, no they don't.  They are requesting the font Microsoft calls
 Tahoma, not a Wine-provided imitation of Tahoma.

I didn't know that wine-provided Tahoma is not exactly the same as Microsoft 
Tahoma. I just knew it looked horrible. That is an important information, thank 
you. From now on I'll write wine-Tahoma when talking about wine-provided 
Tahoma to make it clear.

Chris wrote:
 Providing a font called Tahoma that isn't Tahoma is a bad idea.  In
 general, the fonts that are designed to copy other fonts get a different
 name.  In many cases, this is required because some font names are
 trademarked (IIRC Helvetica is an example).
 
 Wine should not call their font Tahoma.  They should call it something
 else and then map requests for Tahoma to their imitation font.

Is someone knowledgeable enough to put all the details and information together 
and open a ticket in wine bug-tracker? I can do it, but since I know nothing 
about fonts, my bug description might not explain the issue properly.

Felix wrote:
 It happens because:
 
 1-Microsoft's TTF fonts are not in the browser's font path
 
 2-a poor imitation of Tahoma named Tahoma is in the browser's font
 path
 
 3-Clueless web authors include Tahoma as a fallback to Verdana, which
 is not
 part of a standard Wine install, while the Tahoma impostor is

This is a nice summary. Now, are we able to circumvent other people's mistakes 
and obstacles?

I have to stress out one very important thing in case someone missed it: It is 
extremely easy to make a font available only to wine itself, it has a special 
directory for that. No other applications would see it.

Andreas wrote:
 As a packager I, however, find it important that for the
 use-case of wine the best available user experience is provided.
 Hence
 this font needs to be included an pulled in by wine like it is
 today.

Let's assume we have moved wine-Tahoma to wine-specific font directory:
1. Wine users experience stays the same - all wine applications are still 
rendered correctly
2. General users experience improves - web browser doesn't display a lot of 
favorite web pages (like Facebook) with an ugly-looking font

Now, what is wrong about that?

Andreas, if there are packaging guidelines that would be broken, I'm sure we 
can receive an exception. I can find out the correct approach and I will gladly 
help you discuss that with relevant people.
If you are afraid there might be people out there who want wine-Tahoma as a 
system font, it is important to realize that those people are probably just a 
tiny fraction of the other side of the argument (users who prefer good-looking 
websites) and we can easily adjust the README to explain how to make the font 
user-wide or system-wide if required (together with a note that this is *not* 
Microsoft Tahoma and final appearance will differ).

Or is there any other reason why you feel reluctant to make wine-Tahoma 
available only to wine by default?

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

Re: How to proceed with MiniDebugInfo

2012-06-05 Thread Alexander Larsson
On Tue, 2012-05-29 at 21:49 +0200, Lennart Poettering wrote:
 On Thu, 24.05.12 09:28, Alexander Larsson (al...@redhat.com) wrote:
 
  I'm at a loss to how to proceed with the MiniDebugInfo work. I have
  patches to rpmbuild that creates the compressed minidebuginfo putting
  them in the main binaries, and I have patches to gdb that reads the
  compressed debuginfo on demand. 
  
  However, the whole thing is useless unless we agree that we want to
  enable this by default. It seems some people like the idea, whereas
  others disagree that its worth the increased binary size. It doesn't
  look like either side is gonna be able to convince the other side, so
  how do we get to a decision here?
 
 The right way is probably to write a feature page for F18 for it, and
 then get it through Fedora 18 feature process. With FESCO accepting the
 feature you should have all you need to get your work accepted by the
 various stakeholders.

I did write a feature page for it. Thats how these threads started.


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

octave-struct and octave-optim: license change from GPLv2+ to GPLv3+

2012-06-05 Thread Thomas Sailer
I'd like to push octave-struct v1.0.10 and octave-optim v1.1.0 to 
rawhide; octave-struct and octave-optim change, like the rest of the 
octave forge repository, the license from GPLv2+ to GPLv3+.


The only package that depends on octave-struct in the repository
that I am aware of is octave-optim, and octave-optim is only required by 
octave-signal, which is already GPLv3+.


Are there any objections?

Thanks,
Tom

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

Re: wine font changes system look and feel

2012-06-05 Thread Nicolas Mailhot

Le Mar 5 juin 2012 10:59, Kamil Paral a écrit :

 If you are afraid there might be people out there who want wine-Tahoma as a
 system font, it is important to realize that those people are probably just a
 tiny fraction of the other side of the argument

That's a dangerous argument, looks are subjective and every time someone
touches a font it deems ugly others disagree.

It'd be much better if
1. the wine font didn't declare a name too heavy for it
2. the font package was made technically optionnal so people who love the font
(I'm sure there are some like all the other times) can still use it

-- 
Nicolas Mailhot

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

Re: Update ImageMagick in Fedora 16

2012-06-05 Thread Pavel Alexeev

04.06.2012 21:11, Pete Walter написал:

Pavel Alexeevforumat  hubbitus.com.ru  writes:

May be in next time? What disadvantages you are seen proceed with that
update? Do you try test it?

No, I did not test this. And here's a few reasons why I think this
shouldn't be pushed:

  - You are forcing others to do work they otherwise wouldn't need to
do.  Why do you want me to test ImageMagick functionality in 57
dependant packages?  Fix your security bugs and leave other
packages alone.  F16 is supposed to be stable.

  - A major ImageMagick update that introduces new features and new code
invalidates the QA that has gone into the packages that use
ImageMagick.

  - Needless update churn.  We have the Stable Updates Policy for a
reason.  Do you development on rawhide and let stable Fedora
release be stable.

  - The soname bump breaks third party packages that use ImageMagick
libraries.  An example is 'transcode' from rpmfusion.


http://fedoraproject.org/wiki/Updates_Policy explicitly says that such
ABI bumps are left to the discretion of FESCO and the packager.  Have
you already asked FESCO for their blessing?

Note that you should open this dialog _BEFORE_ you build or push updates.


   Pete

Ok. I understand you point. I do not share your point of view, but the 
respect among others to speak out. But as I mention and thankfully also 
Johannes Lips (thanks for some positive words) such argue was much more 
appreciated before all work had been done. For that I announce my 
intentions for the week ago.


I'll plan unpush that update and work on patching ImageMagick to handle 
these issues locally. But I'm not security expert and can't guarantee 
something except mentioned patch apply (contrary leave it on upstream 
authors, as I was want do first).


Only one other think before I do that. Is it will be needed then 
introduce epoch in Fedora 16 IM build to push less version in stable 
branch? Is it normal introduce epoch tag only in that branch, and not on 
all others?

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

Re: Update ImageMagick in Fedora 16

2012-06-05 Thread Pavel Alexeev

04.06.2012 22:26, Michael Schwendt написал:

On Mon, 04 Jun 2012 19:36:29 +0400, Pavel Alexeev wrote:


Additionally have worth I try read carefully all docs about
provenpackager and such updates and have not found how deal with such
versions.

It's not provenpackager specific stuff, but found in the basic packaging
guidelines:

https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag


I had look in my packages and few others and found it was
updated many times in that way.

Just read the page linked above. There is no strict requirement to
apply this release versioning scheme for old branches. If newer branches
would always win RPM Version Comparison because their %version field
is _higher_, you can bump %release in older branches without risk.


In packages were was present subrelease
after %{?dist} - I increase it.
Should or must in next time I add it in any package even it does not
have it??

As the guidelines say: Be careful with this!

Thank you very much Michael. It's helpful.
But what still is not clear to me - if it secure, may it be applied to 
all packages on update in stable releases? Or instead I should check if 
increasing release do not break version sequence in branches - do that. 
And only if it false, introduce subrelease like %{?dist}.1?


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

Re: Update ImageMagick in Fedora 16

2012-06-05 Thread Michael Schwendt
On Tue, 05 Jun 2012 13:55:21 +0400, Pavel Alexeev wrote:

 Only one other think before I do that. Is it will be needed then 
 introduce epoch in Fedora 16 IM build to push less version in stable 
 branch? 

Could you explain _why_ you think you need to increase the Epoch?

Last package in F-16 updates: ImageMagick-6.7.0.10-4.fc16

 Is it normal introduce epoch tag only in that branch, and not on 
 all others?

No. That sounds as if you've misunderstood something completely. :-(

-- 
Fedora release 17 (Beefy Miracle) - Linux 3.3.7-1.fc17.x86_64
loadavg: 0.80 0.65 0.53
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F17: fatal errors on install

2012-06-05 Thread Paul Howarth
On Mon, 04 Jun 2012 20:01:15 -0400
Gerry Reno gr...@verizon.net wrote:

 On 06/04/2012 07:44 PM, Kevin Fenzi wrote:
  On Mon, 04 Jun 2012 19:37:07 -0400
  Gerry Reno gr...@verizon.net wrote:
 
  Burned another DVD and booting it got some other errors (rpcbind?)
  but it runs the installer at least.
 
  I'm doing custom partitioning and I selected to encrypt the LVM
  physical volume (LUKS) but now it is also asking about encrypting
  the filesystem for logical volume.
 
  Do I need both of these?
 
  And another problem.  You cannot edit the Volume Group name
  field.  I need several Volume Groups but now I have no way to do
  this since there's no way to make them unique.  :-(
  The install guide might be of help... 
 
  http://docs.fedoraproject.org/en-US/Fedora/17/html-single/Installation_Guide/index.html#encrypt-x86
 
  And this is really the sort of question best suited to the users
  list: http://lists.fedoraproject.org/mailman/listinfo/users
 
  not the devel list. ;) 
 
  kevin
 
 
 
 Hey Kevin, I've been custom partitioning Fedora installs since the
 beginning of anaconda.
 
 Look back several years and you'll find still unaddressed
 installation bugs for anaconda/preupgrade.  For example /boot on RAID.

Hmm, I did a fresh F17 install two days ago with /boot on (MD) RAID1
and it worked just fine, with none of the grub issues F16 had with that.

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

Re: F17: fatal errors on install

2012-06-05 Thread Tom Hughes

On 05/06/12 11:15, Paul Howarth wrote:


On Mon, 04 Jun 2012 20:01:15 -0400
Gerry Renogr...@verizon.net  wrote:


Look back several years and you'll find still unaddressed
installation bugs for anaconda/preupgrade.  For example /boot on RAID.


Hmm, I did a fresh F17 install two days ago with /boot on (MD) RAID1
and it worked just fine, with none of the grub issues F16 had with that.


Yes you can install (or upgrade with anaconda I think) but what you 
can't do is upgrade using preupgrade if you have a mirrored system disk.


Which is just one of the reasons I do all my upgrades with yum...

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Update ImageMagick in Fedora 16

2012-06-05 Thread Michael Schwendt
On Tue, 05 Jun 2012 14:05:13 +0400, Pavel Alexeev wrote:

 04.06.2012 22:26, Michael Schwendt написал:
  On Mon, 04 Jun 2012 19:36:29 +0400, Pavel Alexeev wrote:
 
  Additionally have worth I try read carefully all docs about
  provenpackager and such updates and have not found how deal with such
  versions.
  It's not provenpackager specific stuff, but found in the basic packaging
  guidelines:
 
  https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag
 
  I had look in my packages and few others and found it was
  updated many times in that way.
  Just read the page linked above. There is no strict requirement to
  apply this release versioning scheme for old branches. If newer branches
  would always win RPM Version Comparison because their %version field
  is _higher_, you can bump %release in older branches without risk.
 
  In packages were was present subrelease
  after %{?dist} - I increase it.
  Should or must in next time I add it in any package even it does not
  have it??
  As the guidelines say: Be careful with this!
 Thank you very much Michael. It's helpful.
 But what still is not clear to me - if it secure, may it be applied to 
 all packages on update in stable releases? Or instead I should check if 
 increasing release do not break version sequence in branches - do that. 
 And only if it false, introduce subrelease like %{?dist}.1?

Well, if you want to spare yourself the extra check, simply use the
%{?dist}.N scheme for old branches _always_. Then you're on the safe side.

[That means: If you see only a %{?dist} in an old branch, introduce the
%{?dist}.N scheme even if it's not strictly necessary. If you see the
%{?dist}.N scheme is used already, increase N appropriately. Then it's
up to the package owner, or anyone else who touches the package, to
check whether the normal %{?dist} scheme would be fine when preparing
another bug-fix release sometime after you.]

-- 
Fedora release 17 (Beefy Miracle) - Linux 3.3.7-1.fc17.x86_64
loadavg: 0.57 0.65 0.61
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

2012-06-05 Thread inode0
On Tue, Jun 5, 2012 at 1:15 AM, Tomas Mraz tm...@redhat.com wrote:
 On Mon, 2012-06-04 at 21:30 -0500, Dennis Gilmore wrote:
 El Sat, 2 Jun 2012 12:18:17 -0400
 Orcan Ogetbil oget.fed...@gmail.com escribió:
  On Sat, Jun 2, 2012 at 12:05 PM, Jesse Keating wrote:
  
   The only Freedom you've lost is that now, in addition to the
   person-hours to do the work and monetary cost to host your bits or
   generate physical media, you have an additional cost if you wish to
   have your own cert that will be accepted out of the box by the next
   generation of PC hardware.  You have as much equal footing as
   Fedora does to plunk down the $99 and play along in the PC sandbox.
    That's a better deal than Fedora's gpg signing setup.
  
 
  Hmm, will the package maintainers have the freedom to not support
  users who have the secureboot enabled? How are we going to detect
  this?

 i look at it this way. if you patch your software to only run on
 machines with secureboot disabled your software then becomes non free
 and has to be removed from fedora.  this is becasuse you are placing
 usage restrictions on it. depending on the license of the software
 adding such a restriction would violate the license. I am not a lawyer
 at all and never pretend to play one, but i do not think you as a
 package maintainer can do that. an upstream could, but i imagine it
 would be viewed in the same light as a commercial use restriction and
 become non-free.

 That's a total nonsense unless the restriction is by-license and not
 just technical obstacle. If it is just a technical obstacle in the code,
 you can remove it and run the software on any crippled machine at your
 will. So no, making your software not to work on particular machines
 does not make it non-free at all.

Aside from being distasteful it is wildly at odds with the goal of the
proposed feature. If the proposal before us is accepted with the
expressed purpose of making Fedora usable out of the box on this
hardware I have a hard time accepting that Fedora would view requiring
patching and recompiling components by the end user to remove
obstructions to such use as acceptable packaging behavior.

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

Re: Notice: Retiring vbetool in F18

2012-06-05 Thread Adam Jackson

On 6/5/12 4:05 AM, Petr Pisar wrote:


How can I reset the graphics card using KMS (vbetool post)?


You've needed to?

There's no direct equivalent to vbetool post.  KMS drivers handle 
suspend/resume in the kernel.  Some of them have lockup detection and 
have implemented GPU resets internally (which is far more complex than 
vbetool post); others don't and haven't.


I'm curious what you think the use case is.

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

Re: Update ImageMagick in Fedora 16

2012-06-05 Thread Pavel Alexeev

05.06.2012 16:09, Michael Schwendt wrote:

On Tue, 05 Jun 2012 14:05:13 +0400, Pavel Alexeev wrote:


04.06.2012 22:26, Michael Schwendt написал:

On Mon, 04 Jun 2012 19:36:29 +0400, Pavel Alexeev wrote:


Additionally have worth I try read carefully all docs about
provenpackager and such updates and have not found how deal with such
versions.

It's not provenpackager specific stuff, but found in the basic packaging
guidelines:

https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag


I had look in my packages and few others and found it was
updated many times in that way.

Just read the page linked above. There is no strict requirement to
apply this release versioning scheme for old branches. If newer branches
would always win RPM Version Comparison because their %version field
is _higher_, you can bump %release in older branches without risk.


In packages were was present subrelease
after %{?dist} - I increase it.
Should or must in next time I add it in any package even it does not
have it??

As the guidelines say: Be careful with this!

Thank you very much Michael. It's helpful.
But what still is not clear to me - if it secure, may it be applied to
all packages on update in stable releases? Or instead I should check if
increasing release do not break version sequence in branches - do that.
And only if it false, introduce subrelease like %{?dist}.1?

Well, if you want to spare yourself the extra check, simply use the
%{?dist}.N scheme for old branches _always_. Then you're on the safe side.

[That means: If you see only a %{?dist} in an old branch, introduce the
%{?dist}.N scheme even if it's not strictly necessary. If you see the
%{?dist}.N scheme is used already, increase N appropriately. Then it's
up to the package owner, or anyone else who touches the package, to
check whether the normal %{?dist} scheme would be fine when preparing
another bug-fix release sometime after you.]


Ok, thank you for the explanation.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How to proceed with MiniDebugInfo

2012-06-05 Thread Miloslav Trmač
On Tue, Jun 5, 2012 at 11:08 AM, Alexander Larsson al...@redhat.com wrote:
 On Tue, 2012-05-29 at 21:49 +0200, Lennart Poettering wrote:
 The right way is probably to write a feature page for F18 for it, and
 then get it through Fedora 18 feature process. With FESCO accepting the
 feature you should have all you need to get your work accepted by the
 various stakeholders.

 I did write a feature page for it. Thats how these threads started.

It is in Category:FeaturePageIncomplete , which means FESCo will not
see it on its agenda.  Please see
http://fedoraproject.org/wiki/Features/Policy/Process .
   Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Notice: Retiring vbetool in F18

2012-06-05 Thread Petr Pisar
On 2012-06-05, Adam Jackson a...@redhat.com wrote:
 On 6/5/12 4:05 AM, Petr Pisar wrote:

 How can I reset the graphics card using KMS (vbetool post)?

 You've needed to?

It's long time when I used the tool. After getting my nvidia card into
undefined state (X server crash, relicts after playing with video
overlay or directfb console etc.).

 There's no direct equivalent to vbetool post.  KMS drivers handle 
 suspend/resume in the kernel.  Some of them have lockup detection and 
 have implemented GPU resets internally (which is far more complex than 
 vbetool post); others don't and haven't.

 I'm curious what you think the use case is.


Maybe the drivers are much better today. I just worry about removing
functionality.

-- Petr

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

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-05 Thread Michal Schmidt

On 06/05/2012 03:52 AM, Kay Sievers wrote:

Systemd includes libudev.so.1, while the old libudev.rpm provided
libudev.so.0. Therefore, all packages using udev need to be rebuilt.


Here's a list of owners with packages that currently require 
libudev.so.0 in Rawhide.


# repoquery --whatrequires libudev.so.0 --qf '%{sourcerpm}' | rev | cut 
-f3- -d- | rev | sort | uniq | fedoradev-pkgowners | sort | column -t


ajax   libdrm
bskeggsxorg-x11-drv-nouveau
davidz udisks
lennartlibatasmart
lennartlibcanberra
lennartpulseaudio
libvirt-maint  libvirt
lvm-team   lvm2
pgfolpc-kbdshim
rdieterqt-mobility
rhughesweston
rrelyeapcsc-lite
twaugh system-config-printer
udev-maint udev
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: wine font changes system look and feel

2012-06-05 Thread Andreas Bierfert
On Tue, 2012-06-05 at 11:49 +0200, Nicolas Mailhot wrote:
 Le Mar 5 juin 2012 10:59, Kamil Paral a écrit :
 
  If you are afraid there might be people out there who want wine-Tahoma as a
  system font, it is important to realize that those people are probably just 
  a
  tiny fraction of the other side of the argument
 
 That's a dangerous argument, looks are subjective and every time someone
 touches a font it deems ugly others disagree.

That is exactly how I see this. On a side note: I personally have the
package installed and don't find e. g. facebook particularly ugly or
pretty.

 It'd be much better if
 1. the wine font didn't declare a name too heavy for it

I am no font expert but from my understanding it does not. Its name is
WineTahoma (and WineTahomaBold respectively). Both fonts declare them to
be part of the Tahoma family. From my understanding this is perfectly
alright as they share some of the defining features of the MS Tahoma
font (so maybe the looks differ).

 2. the font package was made technically optionnal so people who love the font
 (I'm sure there are some like all the other times) can still use it

Well this is the tricky part as I believe them essential for a standard
wine setup. We could of course aim for a dual-solution: Let
wine-tahoma-fonts put the fonts in the wine font dir (mandatory for
wine) and add a wine-tahoma-fonts-system package (names suggestions
welcome) which also puts the fonts in the system wide font path
(optional).

If this would be a feasible solution I would still like some opinions if
this should be done for both fonts or just for the reported bugs about
the bold version.

-- 
Andreas Bierfert andreas.bierf...@lowlatency.de


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Notice: samba 4.0 beta1 and what will be available in Fedora

2012-06-05 Thread Alexander Bokovoy

Hi!

Samba team has released Samba 4.0 beta 1 today. This is important
milestone in a more than 8 years of Samba 4 development.

This mail attempts to explain what will be and will not be available in
Fedora (Rawhide first, 
http://koji.fedoraproject.org/koji/taskinfo?taskID=4128906,
we are considering to discuss with all affected maintainers if and how an
update to F17 would be possible).

Sorry for longer than perhaps needed write up as this topic wasn't covered
before apart from discussions in Samba and FreeIPA upstreams.

Samba 4 is a combined set of daemons, client utilities, and Python
bindings that allow communicating using SMB1, SMB2, and soon SMB3
protocols. It also implements Active Directory domain controller (DC)
functionality as an integrated Kerberos DC, LDAP server, DNS server, 
and SMB/CIFS server.


Samba 4 AD DC functionality relies heavily on Heimdal Kerberos
implementation. Samba 4 includes the embedded Heimdal, if your system
misses it, like we have in Fedora. When embedded Heimdal is in use,
all Samba 4 code is compiled against this Kerberos implementation,
including client side libraries and tools, and traditional file serving
smbd daemon we know as 'samba' package in Fedora.

Fedora uses MIT Kerberos implementation, both server and client side.
Heimdal and MIT Kerberos are targetting to implement the same Keberos V
protocol but have their own extensions API and certain semantical
differences. They also have slightly different meaning to Kerberos
credential cache files format where Kerberos-aware applications store
their Kerberos keys. While this is not an issue for client-server 
communication over a network (a Heimdal client does talk the same

Kerberos V protocol that MIT Kerberos server understands and vice
versa), interoperability of the client or server code using the same
credential cache files on the same system is much less supported for
advanced features like S4U2Proxy and S4U2Self.

It is generally not advisable to load two different API implementations
into the same address space either. When the rest of the system
libraries is compiled against MIT Kerberos, use of them within Samba 4
code brings in MIT Kerberos as well. This happens, for example, when
linking against OpenLDAP client libraries and using SASL authentication.

As part of work we are doing on FreeIPA v3, we have made possible to
compile Samba 4 code against MIT Kerberos implementation. Unfortunately,
MIT Kerberos does not give option of embedding Kerebros KDC server within
another process which is required for Samba 4 AD DC functionality. Thus,
when compiled with MIT Kerberos, Samba 4 currently does not provice Active
Directory Domain Controller functionality at all, only client side
libraries and tools to the extent that does not involve AD DC
operations. Also, smbd is compiled against MIT Kerberos and provides
functionality equivalent to what is provided by Samba 3's smbd.

We are intending to make possible use of AD DC functionality with MIT
Kerberos but this is longer term project that requires cooperation
between Samba, MIT, and FreeIPA.

For GNU/Linux-based clients FreeIPA already provides functionality
similar to the one of Active Directory. With FreeIPA v3 we'll have
cross-realm trusts support with Active Directory that will allow
seamlessly integrating GNU/Linux-based machines into existing AD-based
infrastructure. You can get details about implementation from our talk
at SambaXP 2012 conference (http://abbra.fedorapeople.org/freeipa.pdf) and
earlier roadmap talk at Fedora Devconf in Brno in February 2012
(http://blip.tv/fedoracz/dmitripal-idenitymanagementroadmap-6071539)

One consequence of Samba 4 built with MIT Kerberos is that Openchange
server code will not be working in Fedora either. Openchange server code
requires working Samba 4 DC server with proper AD provisioning. This only
affects server side and does not affect Openchange client side support
which is used in Evolution MAPI plugin, which will continue to work.

Rawhide is already providing Samba 4  built with MIT Kerberos,
and Openchange package was modified to include only client side support.
The latter also submitted and merged to Openchange upstream.

What is available in Rawhide right now?

* samba4-* 4.0.0-53beta1 packages are built against system-wide MIT Kerberos 
  libraries. These packages are made conflicting with samba-* packages in areas

  where they provide the same binaries and/or libraries. You don't need
  to install samba4-* packages unless you want to use Evolution MAPI
  plugin and (soon FreeIPA v3 server).

* openchange is built to provide client-side libraries to allow Evolution
  MAPI plugin to work.

* Evolution MAPI plugin is rebuilt against new openchange build.

What will not be available in Rawhide in time for Fedora 18?

* Samba 4 AD DC implementation

What about samba and samba4 packages?

As samba4 is a superset of Samba 3 packages in Fedora, we are also
considering to discuss renaming samba4 back to 

Re: *countable infinities only

2012-06-05 Thread Przemek Klosowski

On 06/02/2012 06:27 PM, drago01 wrote:


No one is preventing anyone from providing instructions on how to
disable secure boot. We should definitely do that.
But those are not mutually exclusive ... i.e we can have both
documentation *and* an OS that just works.


Everyone, including Microsoft, agrees that the secure boot system can be 
disabled. Currently the only envisioned mechanism is via a firmware 
(UEFI) setup, therefore subject to vagaries of different firmware 
implementations. The firmware is beyond our control: we can't give 
reliable and meaningful instructions to the user on how to set it, and 
AFAIK there is no API that would allow the bootloader, or other software 
layers we control, to reach back and set it for future boots.


Therefore(*), it is reasonable and fair to implement an equivalent 
facility in the signed bootloader, by offering the end user a choice to 
leave the signed environment. The bootloader might enumerate 
signed/secure kernels (Windows and official Fedora), but also offer an 
extra choice, educating the end user by warning that it not only results 
in booting into a non-secure environment but also opens the possibility 
of subverting one of the signed/secure environments.


I believe(*) this is a defensible position---the choice is left to the 
end user, and the security implications are almost identical to doing it 
in firmware. A residual risk of exploits needs to be dealt with, just 
like vulnerabilities in the rest of the secure boot process; the only 
downside being that firmware implementations are diverse, and this 
option would present a single target for exploit attempts, so it would 
need a heightened level of review.


 Greetings
 przemek


(*) These are my personal opinions based solely on my own judgement and 
experience as the technology user. As such, they express only my own 
personal preferences and are not to be construed in any broader sense.

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

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-05 Thread Adam Jackson

On 6/4/12 9:52 PM, Kay Sievers wrote:

We merged the upstream udev repository entirely into the systemd
repository. There is no standalone upstream udev project anymore.

The version of systemd which includes udev has landed in rawhide a
couple of days ago. Fedora 18 will not have a udev.rpm, no libudev.rpm
and no libudev-devel.rpm.


I think we can also take this to mean that an explicit:

Requires: udev

is now redundant?  In which case the following (F17) packages can be 
cleaned up:


% repoquery --disablerepo=* --enablerepo=fedora --qf=%{sourcerpm} 
--whatrequires udev | sort -u

aic94xx-firmware-30-3.fc17.src.rpm
alsa-firmware-1.0.25-1.fc17.src.rpm
alsa-tools-1.0.25-2.fc17.src.rpm
android-tools-20111220git1b251bd-2.fc17.src.rpm
ar9170-firmware-2009.05.28-4.fc17.src.rpm
argyllcms-1.3.6-2.fc17.src.rpm
b43-openfwwf-5.2-7.fc17.src.rpm
barry-0.17.1-7.fc17.src.rpm
bfa-firmware-3.0.0.0-2.fc17.src.rpm
biosdevname-0.3.11-6.fc17.src.rpm
bluez-4.98-3.fc17.src.rpm
btkbdd-1.2-1.fc17.src.rpm
clamtk-4.39-1.fc17.src.rpm
crda-1.1.2_2011.04.28-2.fc17.src.rpm
cups-1.5.2-12.fc17.src.rpm
device-mapper-multipath-0.4.9-25.fc17.src.rpm
dracut-018-35.git20120510.fc17.src.rpm
drbd-8.3.11-5.fc17.src.rpm
em8300-0.18.0-6.fc17.src.rpm
fbterm-1.6-5.fc17.src.rpm
fxload-2002_04_11-11.fc17.src.rpm
gpsd-3.4-1.fc17.src.rpm
hplip-3.12.4-2.fc17.src.rpm
i2c-tools-3.1.0-1.fc17.src.rpm
initscripts-9.37-1.fc17.src.rpm
iscan-firmware-2.26.4-2.fc17.src.rpm
isdn4k-utils-3.2-81.fc17.src.rpm
isight-firmware-tools-1.6-2.fc17.src.rpm
iwl1000-firmware-39.31.5.1-2.fc17.src.rpm
iwl100-firmware-39.31.5.1-3.fc17.src.rpm
iwl5150-firmware-8.24.2.2-3.fc17.src.rpm
iwl6000-firmware-9.221.4.1-3.fc17.src.rpm
iwl6000g2a-firmware-17.168.5.3-2.fc17.src.rpm
iwl6000g2b-firmware-17.168.5.2-2.fc17.src.rpm
iwl6050-firmware-41.28.5.1-4.fc17.src.rpm
libconcord-0.23-9.fc17.src.rpm
libdrm-2.4.33-1.fc17.src.rpm
libertas-sd8686-firmware-9.70.20.p0-2.fc17.src.rpm
libftdi-0.19-3.fc17.src.rpm
libgpod-0.8.2-4.fc17.src.rpm
libguestfs-1.17.36-2.fc17.src.rpm
libmtp-1.1.3-2.fc17.src.rpm
libnjb-2.2.7-2.fc17.src.rpm
libosinfo-0.1.1-1.fc17.src.rpm
libphidget-2.1.8.20120123-1.fc17.src.rpm
libvirt-0.9.11.3-1.fc17.src.rpm
linux-firmware-20120206-0.3.git06c8f81.fc17.src.rpm
lvm2-2.02.95-6.fc17.src.rpm
MAKEDEV-3.24-10.fc17.src.rpm
mdadm-3.2.3-6.fc17.src.rpm
media-player-info-16-1.fc17.src.rpm
microcode_ctl-1.17-24.fc17.src.rpm
NetworkManager-0.9.4.0-7.git20120403.fc17.src.rpm
netxen-firmware-4.0.534-5.fc17.src.rpm
nut-2.6.3-2.fc17.src.rpm
olpc-utils-2.0.7-1.fc17.src.rpm
openct-0.6.20-3.fc17.src.rpm
openni-primesense-5.0.3.3-2.fc17.src.rpm
os-prober-1.53-1.fc17.src.rpm
ovirt-node-2.3.0-1.fc17.src.rpm
pcmciautils-018-2.fc17.src.rpm
pulseaudio-1.1-9.fc17.src.rpm
rdma-1.0-11.fc17.src.rpm
sane-backends-1.0.22-9.fc17.src.rpm
svxlink-11.11.1-4.fc17.src.rpm
synce-sync-engine-0.15.1-3.fc17.src.rpm
systemd-44-8.fc17.src.rpm
udev-182-1.fc17.src.rpm
udisks-1.0.4-6.fc17.src.rpm
udisks2-1.94.0-4.fc17.src.rpm
upower-0.9.16-1.fc17.src.rpm
usb_modeswitch-data-20111023-2.fc17.src.rpm
util-linux-2.21.1-1.fc17.src.rpm
v4l-utils-0.8.7-1.fc17.src.rpm
vdr-1.7.27-1.fc17.src.rpm
vdr-remote-0.4.0-19.fc17.src.rpm
xen-4.1.2-15.fc17.src.rpm
xorg-x11-drv-synaptics-1.6.0-1.fc17.src.rpm
xorg-x11-drv-vmmouse-12.8.0-1.fc17.src.rpm
xorg-x11-drv-wacom-0.14.0-2.fc17.src.rpm

- ajax

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

File SQL-Library-0.0.4.tar.gz uploaded to lookaside cache by psabata

2012-06-05 Thread Petr Šabata
A file has been added to the lookaside cache for perl-SQL-Library:

e77199d4d71eac25cc82b2a86711052c  SQL-Library-0.0.4.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-SQL-Library] 0.0.4 bump and some cleanup

2012-06-05 Thread Petr Šabata
commit 721bdcf49db6c40c40dda0357c545848fd39ca2b
Author: Petr Šabata con...@redhat.com
Date:   Tue Jun 5 17:35:46 2012 +0200

0.0.4 bump and some cleanup

 .gitignore|1 +
 perl-SQL-Library.spec |   25 ++---
 sources   |2 +-
 3 files changed, 12 insertions(+), 16 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 55a6d8c..195972f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 SQL-Library-0.0.3.tar.gz
+/SQL-Library-0.0.4.tar.gz
diff --git a/perl-SQL-Library.spec b/perl-SQL-Library.spec
index ac84578..ea57520 100644
--- a/perl-SQL-Library.spec
+++ b/perl-SQL-Library.spec
@@ -1,15 +1,15 @@
 Name:   perl-SQL-Library
-Version:0.0.3
-Release:12%{?dist}
+Version:0.0.4
+Release:1%{?dist}
 Summary:Manage libraries of SQL easily 
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/SQL-Library/
 Source0:
http://www.cpan.org/authors/id/D/DG/DGORLEY/SQL-Library-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
-BuildRequires:  perl(ExtUtils::MakeMaker), perl(Test::More)
-Requires:   perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
+BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(Test::More)
+Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
 
 %description
 This is a perl module for managing simple SQL libraries stored in
@@ -20,35 +20,30 @@ OUTSIDE of their perl code.
 %setup -q -n SQL-Library-%{version}
 
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
 
 %install
-rm -rf %{buildroot}
-
 make pure_install PERL_INSTALL_ROOT=%{buildroot}
-
 find %{buildroot} -type f -name .packlist -exec rm -f {} \;
 find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
-
 %{_fixperms} %{buildroot}/*
-
 # the better to doc it later...
 cp t/sqltest.lib example.lib
 
 %check
 make test
 
-%clean
-rm -rf %{buildroot}
-
 %files
-%defattr(-,root,root,-)
 %doc Changes LICENSE README example.lib
 %{perl_vendorlib}/*
 %{_mandir}/man3/*
 
 %changelog
+* Tue Jun 05 2012 Petr Šabata con...@redhat.com - 0.0.4-1
+- 0.0.4 bump
+- Modernize spec (remove buildroot, defattr, and command macros)
+
 * Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.0.3-12
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
 
diff --git a/sources b/sources
index e0d2188..4019cc6 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-75b80cb27775bb61f90fbd5b835032ec  SQL-Library-0.0.3.tar.gz
+e77199d4d71eac25cc82b2a86711052c  SQL-Library-0.0.4.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

rawhide report: 20120605 changes

2012-06-05 Thread Fedora Rawhide Report
Compose started at Tue Jun  5 08:15:03 UTC 2012

Broken deps for x86_64
--
[389-admin]
389-admin-1.1.28-1.fc18.i686 requires libicuuc.so.48
389-admin-1.1.28-1.fc18.i686 requires libicui18n.so.48
389-admin-1.1.28-1.fc18.i686 requires libicudata.so.48
389-admin-1.1.28-1.fc18.x86_64 requires libicuuc.so.48()(64bit)
389-admin-1.1.28-1.fc18.x86_64 requires libicui18n.so.48()(64bit)
389-admin-1.1.28-1.fc18.x86_64 requires libicudata.so.48()(64bit)
[389-dsgw]
389-dsgw-1.1.9-2.fc17.x86_64 requires libicuuc.so.48()(64bit)
389-dsgw-1.1.9-2.fc17.x86_64 requires libicui18n.so.48()(64bit)
389-dsgw-1.1.9-2.fc17.x86_64 requires libicudata.so.48()(64bit)
[OpenGTL]
OpenGTL-0.9.16-4.fc18.x86_64 requires libLLVM-3.0.so()(64bit)
OpenGTL-devel-0.9.16-4.fc18.i686 requires libLLVM-3.0.so
OpenGTL-devel-0.9.16-4.fc18.x86_64 requires libLLVM-3.0.so()(64bit)
OpenGTL-libs-0.9.16-4.fc18.i686 requires libLLVM-3.0.so
OpenGTL-libs-0.9.16-4.fc18.x86_64 requires libLLVM-3.0.so()(64bit)
[PackageKit]
PackageKit-zif-0.7.4-6.fc18.x86_64 requires libzif.so.3()(64bit)
[aeolus-all]
aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-doc = 
0:0.4.0-2.fc17
aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-daemons = 
0:0.4.0-2.fc17
[aeolus-configserver]
aeolus-configserver-0.4.5-1.fc18.noarch requires ruby-nokogiri
[axis2c]
axis2c-1.6.0-4.fc17.i686 requires httpd-mmn = 0:20051115-x86-32
axis2c-1.6.0-4.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64
[boost141]
boost141-graph-1.41.0-2.fc17.i686 requires libicuuc.so.48
boost141-graph-1.41.0-2.fc17.i686 requires libicui18n.so.48
boost141-graph-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit)
boost141-graph-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit)
boost141-regex-1.41.0-2.fc17.i686 requires libicuuc.so.48
boost141-regex-1.41.0-2.fc17.i686 requires libicui18n.so.48
boost141-regex-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit)
boost141-regex-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit)
[calligra]
calligra-core-2.4.90-1.fc18.x86_64 requires 
calligra-kexi-map-form-widget  0:2.4.90-1.fc18
[dustmite]
dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires 
libphobos2-ldc.so()(64bit)
[evolution-couchdb]
evolution-couchdb-0.5.91-10.fc18.x86_64 requires 
libedata-cal-1.2.so.15()(64bit)
evolution-couchdb-0.5.91-10.fc18.x86_64 requires 
libedata-book-1.2.so.13()(64bit)
evolution-couchdb-0.5.91-10.fc18.x86_64 requires 
libecal-1.2.so.11()(64bit)
evolution-couchdb-0.5.91-10.fc18.x86_64 requires 
libcamel-1.2.so.33()(64bit)
[evolution-rss]
1:evolution-rss-0.3.91-1.fc18.x86_64 requires 
libedataserverui-3.0.so.1()(64bit)
1:evolution-rss-0.3.91-1.fc18.x86_64 requires 
libcamel-1.2.so.33()(64bit)
[gcc-python-plugin]
gcc-python2-debug-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18
gcc-python2-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18
gcc-python3-debug-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18
gcc-python3-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18
[gdb-heap]
gdb-heap-0.5-8.fc17.x86_64 requires glibc(x86-64) = 0:2.15
[gnome-pilot]
gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires 
libedataserverui-3.0.so.1()(64bit)
gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires 
libecal-1.2.so.11()(64bit)
[gnome-python2-desktop]
gnome-python2-evolution-2.32.0-9.fc17.x86_64 requires 
libecal-1.2.so.11()(64bit)
[hekafs]
hekafs-0.7-30.fc18.x86_64 requires glusterfs = 0:3.2.6
[inkscape]
inkscape-0.48.2-5.fc17.x86_64 requires libpoppler.so.19()(64bit)
inkscape-view-0.48.2-5.fc17.x86_64 requires libpoppler.so.19()(64bit)
[kdeplasma-addons]
kdeplasma-addons-4.8.3-1.fc18.x86_64 requires libkexiv2.so.10()(64bit)
plasma-wallpaper-marble-4.8.3-1.fc18.x86_64 requires 
libmarblewidget.so.13()(64bit)
[mail-notification]
mail-notification-evolution-plugin-5.4-56.fc18.x86_64 requires 
libcamel-1.2.so.34()(64bit)
[mapnik]
mapnik-2.0.0-4.fc17.i686 requires libicuuc.so.48
mapnik-2.0.0-4.fc17.x86_64 requires libicuuc.so.48()(64bit)
mapnik-utils-2.0.0-4.fc17.x86_64 requires libicuuc.so.48()(64bit)
[matreshka]
matreshka-0.1.1-9.fc17.i686 requires libgnat-4.6.so
matreshka-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit)
matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnat-4.6.so
matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnarl-4.6.so
matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit)
matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnarl-4.6.so()(64bit)
matreshka-sql-core-0.1.1-9.fc17.i686 requires libgnat-4.6.so
   

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-05 Thread Adam Jackson

On 6/5/12 10:33 AM, Michal Schmidt wrote:


Here's a list of owners with packages that currently require
libudev.so.0 in Rawhide.

# repoquery --whatrequires libudev.so.0 --qf '%{sourcerpm}' | rev | cut
-f3- -d- | rev | sort | uniq | fedoradev-pkgowners | sort | column -t

ajax libdrm
bskeggs xorg-x11-drv-nouveau
davidz udisks

 rhughes weston

Fixed.

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

Releasing ownership of many audio packages (and a little more)

2012-06-05 Thread Anthony Green
Fedora developers,

While I brought many of these into Fedora, I have not been an active maintainer 
for these packages for a very long time.  Most of them have very responsible 
and active co-maintainers already.  I am about to release ownership of the 
following packages:


ardour -- Multichannel Digital Audio Workstation
aubio -- An audio labelling library
dssi -- Disposable Soft Synth Interface
fluidsynth -- Real-time software synthesizer
fluidsynth-dssi -- DSSI implementation of Fluidsynth
hydrogen -- Advanced drum machine for GNU/Linux
jack-audio-connection-kit -- The Jack Audio Connection Kit
ladspa-swh-plugins -- A set of audio plugins for LADSPA
lash -- LASH Audio Session Handler
libfreebob -- FreeBoB firewire audio driver library
liblo -- Open Sound Control library
liblrdf -- Library for manipulating RDF files describing LADSPA plugins
lv2core -- Audio Plugin Standard
mxml -- Miniature XML development library
phasex -- PHASEX -- Phase Harmonic Advanced Synthesis EXperiment
raptor -- Raptor RDF Parser Toolkit for Redland
seq24 -- Real-time midi sequencer
vkeybd -- Virtual MIDI keyboard
whysynth-dssi -- DSSI software synthesizer plugin
ws-commons-util -- Common utilities from the Apache Web Services Project
zynaddsubfx -- Real-time software synthesizer


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

Re: Releasing ownership of many audio packages (and a little more)

2012-06-05 Thread Jon Ciesla
On Tue, Jun 5, 2012 at 11:53 AM, Anthony Green gr...@redhat.com wrote:
 Fedora developers,

 While I brought many of these into Fedora, I have not been an active 
 maintainer for these packages for a very long time.  Most of them have very 
 responsible and active co-maintainers already.  I am about to release 
 ownership of the following packages:


 hydrogen -- Advanced drum machine for GNU/Linux

I'll take this if none of the co-maintainers steps up soon.

-J


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



-- 
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: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-05 Thread Jon Ciesla
On Tue, Jun 5, 2012 at 10:30 AM, Adam Jackson a...@redhat.com wrote:
 On 6/4/12 9:52 PM, Kay Sievers wrote:

 We merged the upstream udev repository entirely into the systemd
 repository. There is no standalone upstream udev project anymore.

 The version of systemd which includes udev has landed in rawhide a
 couple of days ago. Fedora 18 will not have a udev.rpm, no libudev.rpm
 and no libudev-devel.rpm.


 I think we can also take this to mean that an explicit:

 Requires: udev

 is now redundant?  In which case the following (F17) packages can be cleaned
 up:

 % repoquery --disablerepo=* --enablerepo=fedora --qf=%{sourcerpm}
 --whatrequires udev | sort -u

 argyllcms-1.3.6-2.fc17.src.rpm
 clamtk-4.39-1.fc17.src.rpm

Fixed.

-J

 - ajax

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



-- 
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: Releasing ownership of many audio packages (and a little more)

2012-06-05 Thread Kevin Kofler
Anthony Green wrote:
 raptor -- Raptor RDF Parser Toolkit for Redland

I picked up this one (Fedora only, it's still up for grabs in EPEL 5). I was 
already a comaintainer. It's part of the Redland stack, which is required by 
Soprano, which is required by the Nepomuk stack, which is required by the 
KDE world. ;-)

Kevin Kofler

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

Re: Releasing ownership of many audio packages (and a little more)

2012-06-05 Thread Kevin Kofler
I wrote:

 Anthony Green wrote:
 raptor -- Raptor RDF Parser Toolkit for Redland
 
 I picked up this one (Fedora only, it's still up for grabs in EPEL 5). I
 was already a comaintainer. It's part of the Redland stack, which is
 required by Soprano, which is required by the Nepomuk stack, which is
 required by the KDE world. ;-)

Hmmm, looking at it, Redland and most other stuff is using raptor2 these 
days. The only packages still dependent on raptor 1 in Rawhide are:

raptor-devel-0:1.4.21-11.fc17.i686 (obviously)

flickcurl-0:1.18-2.fc15.i686

librawstudio-0:2.0-5.fc18.i686
rawstudio-0:2.0-5.fc18.i686

So can we get flickcurl and (lib)rawstudio ported to raptor2? I think raptor 
1 needs to be retired sooner or later.

Kevin Kofler

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

Re: *countable infinities only

2012-06-05 Thread Kevin Kofler
Tomas Mraz wrote:
 That's a total nonsense unless the restriction is by-license and not
 just technical obstacle. If it is just a technical obstacle in the code,
 you can remove it and run the software on any crippled machine at your
 will. So no, making your software not to work on particular machines
 does not make it non-free at all.

That doesn't mean we should ship it in that state.

If Fedora decides to support Secure Boot, it needs to be distro-wide.

Kevin Kofler

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

Re: wine font changes system look and feel

2012-06-05 Thread Kevin Kofler
Kamil Paral wrote:
 Let's assume we have moved wine-Tahoma to wine-specific font directory:
 1. Wine users experience stays the same - all wine applications are still
 rendered correctly 2. General users experience improves - web browser
 doesn't display a lot of favorite web pages (like Facebook) with an
 ugly-looking font
 
 Now, what is wrong about that?

Can we make the font available as Tahoma to WINE only and as Wine Tahoma 
or something like that (with font substitutions for plain Tahoma NOT 
configured by default) to systemwide fontconfig?

Kevin Kofler

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

Re: Releasing ownership of many audio packages (and a little more)

2012-06-05 Thread Brendan Jones

On 06/05/2012 06:53 PM, Anthony Green wrote:
 liblo -- Open Sound Control library
 lv2core -- Audio Plugin Standard
 mxml -- Miniature XML development library
 phasex -- PHASEX -- Phase Harmonic Advanced Synthesis EXperiment
 seq24 -- Real-time midi sequencer

whysynth-dssi -- DSSI software synthesizer plugin

 vkeybd -- Virtual MIDI keyboard

zynaddsubfx -- Real-time software synthesizer




I'll take these, co-maintainers welcome.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

svn2cl orphaned

2012-06-05 Thread Ville Skyttä
Hello,

I've released svn2cl's ownership in pkgdb as I don't use it any longer.
 There were no co-maintainers so it's orphaned now, go grab it if you
use it.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Releasing ownership of many audio packages (and a little more)

2012-06-05 Thread Orcan Ogetbil
On Jun 5, 2012 12:58 PM, Jon Ciesla limburg...@gmail.com wrote:

 On Tue, Jun 5, 2012 at 11:53 AM, Anthony Green gr...@redhat.com wrote:
  Fedora developers,
 
  While I brought many of these into Fedora, I have not been an active
maintainer for these packages for a very long time.  Most of them have very
responsible and active co-maintainers already.  I am about to release
ownership of the following packages:
 

  hydrogen -- Advanced drum machine for GNU/Linux

 I'll take this if none of the co-maintainers steps up soon.

Hi Jon,
As one of the comaintainers, I have been doing the actual maintaining of
Hydrogen for the last few years. Do you mind if I take the ownership?

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

Re: *countable infinities only

2012-06-05 Thread Tomas Mraz
On Tue, 2012-06-05 at 19:54 +0200, Kevin Kofler wrote: 
 Tomas Mraz wrote:
  That's a total nonsense unless the restriction is by-license and not
  just technical obstacle. If it is just a technical obstacle in the code,
  you can remove it and run the software on any crippled machine at your
  will. So no, making your software not to work on particular machines
  does not make it non-free at all.
 
 That doesn't mean we should ship it in that state.
And I did not say that either. I just said that such hypothetical
technical obstacle by no means make the software non-free.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

Re: *countable infinities only

2012-06-05 Thread drago01
On Tue, Jun 5, 2012 at 10:42 PM, Tomas Mraz tm...@redhat.com wrote:
 On Tue, 2012-06-05 at 19:54 +0200, Kevin Kofler wrote:
 Tomas Mraz wrote:
  That's a total nonsense unless the restriction is by-license and not
  just technical obstacle. If it is just a technical obstacle in the code,
  you can remove it and run the software on any crippled machine at your
  will. So no, making your software not to work on particular machines
  does not make it non-free at all.

 That doesn't mean we should ship it in that state.
 And I did not say that either. I just said that such hypothetical
 technical obstacle by no means make the software non-free.

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

koji servers and the caname

2012-06-05 Thread john maclean

Hi,

When setting up a koji server, does one have to use a caname of koji? 
Surely one should be able to use a server's FDQN?


Thanks  - john

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

Re: Releasing ownership of many audio packages (and a little more)

2012-06-05 Thread Jon Ciesla
On Tue, Jun 5, 2012 at 3:32 PM, Orcan Ogetbil oget.fed...@gmail.com wrote:

 On Jun 5, 2012 12:58 PM, Jon Ciesla limburg...@gmail.com wrote:

 On Tue, Jun 5, 2012 at 11:53 AM, Anthony Green gr...@redhat.com wrote:
  Fedora developers,
 
  While I brought many of these into Fedora, I have not been an active
  maintainer for these packages for a very long time.  Most of them have very
  responsible and active co-maintainers already.  I am about to release
  ownership of the following packages:
 

  hydrogen -- Advanced drum machine for GNU/Linux

 I'll take this if none of the co-maintainers steps up soon.

 Hi Jon,
 As one of the comaintainers, I have been doing the actual maintaining of
 Hydrogen for the last few years. Do you mind if I take the ownership?

Certainly not.  Re-orphaned.  I don't particularly care who owns it,
so long as it's well cared for. :)

-J

 Thanks,
 Orcan


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



-- 
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: glusterfs rename

2012-06-05 Thread Robyn Bergeron
On Wed, May 30, 2012 at 12:25 PM, Peter Robinson pbrobin...@gmail.com wrote:
 On Wed, May 30, 2012 at 8:03 PM, Kaleb S. KEITHLEY kkeit...@redhat.com 
 wrote:
 On 05/30/2012 02:23 PM, Peter Robinson wrote:

 Yes, for the Fedora side of things I think gluster 3.2 is the best
 strategy with a fedorapeople repo of 3.3 if it's considered worthwhile
 for those that wish to play. For gluster 3.3 I suggest a feature page
 for F-18 / rawhide. Is it feasible for the missing hekafs features to
 be merged into the 3.3 release train by October when F-18 is due to be
 released?


 I was under the impression that glusterfs would be automatically carried
 forward from f17 into f18, as it apparently was from f16 into f17.

 It will be carried forward but a major change of features and
 enhancements is worth doing a feature page to advertise the feature
 improvements (see the gnome feature page as an example[1] ), it's
 something for marketing to use and allows you to also detail things
 like the removal or merge of HekaFS.

 F18 builds (of 3.2.6) are already available in koji. Until now I haven't
 heard that a feature page is needed for 3.2.x (or 3.3.x) to be included in
 f18. (But how to deprecate HekaFS on f18 once the glusterfs-3.3.0 build is
 available.)

 See above for feature page details. For deprecate HekaFS you add the
 the appropriate obsoletes/provides as necessary to the gluster package
 and follow the process for removing/obsoleteing a package in the wiki.

 The features that are in HekaFS (in f16 and f17) will get merged into
 glusterfs-3.3.1+, as I indicated previously, but I won't promise how many of
 them will be there when f18 ships. We certainly hope that all of them will
 be, but we aren't making any promises.

 So that's something that can be documented in a feature page in the
 wiki and updated as things progress through both the gluster devel
 process and the fedora release process :)

Okay, as a slightly more detailed version:

You should follow the full feature process, to be put in the
FeatureList for F18.  If you want to see what that process looks like,
you probably want to look at this diagram:

https://fedoraproject.org/wiki/Features/Policy/Process

And make your feature page according to the template noted on that
wiki page, and submit it to the feature wrangler (via a wiki category
change) so that they can have it approved by fesco, at which point it
can be added to the actual feature list :)

-robyn




 Peter

 [1] https://fedoraproject.org/wiki/Features/Gnome3.4
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Update ImageMagick in Fedora 16

2012-06-05 Thread Tadej Janež
On Tue, 2012-06-05 at 13:55 +0400, Pavel Alexeev wrote:

 I'll plan unpush that update and work on patching ImageMagick to handle 
 these issues locally. But I'm not security expert and can't guarantee 
 something except mentioned patch apply (contrary leave it on upstream 
 authors, as I was want do first).

Even though this means a lot of your work has been waisted, I think it's
the right decision to patch ImageMagick to fix the security issues
instead of doing a large-scale update of Fedora 16.

With regard to the packages that depend on ImageMagick that you already
updated: will you revert those commits in git and delete the
corresponding builds in koji?

Regards,
Tadej Janež


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

Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild

2012-06-05 Thread Sandro Mani


On 06/05/2012 03:52 AM, Kay Sievers wrote:

Systemd includes libudev.so.1, while the old libudev.rpm provided
libudev.so.0. Therefore, all packages using udev need to be rebuilt.


Here is what's happening on my x86_64 rawhide install which has some 
i686 packages (in particular, mesa) installed due to wine:


#yum update mesa-libgbm
[...]
--- Package mesa-libgbm.i686 0:8.1-0.5.fc18 will be updated
--- Package mesa-libgbm.x86_64 0:8.1-0.5.fc18 will be updated
--- Package mesa-libgbm.i686 0:8.1-0.6.fc18 will be an update
-- Processing Dependency: libudev.so.1(LIBUDEV_183) for package: 
mesa-libgbm-8.1-0.6.fc18.i686
-- Processing Dependency: libudev.so.1 for package: 
mesa-libgbm-8.1-0.6.fc18.i686

--- Package mesa-libgbm.x86_64 0:8.1-0.6.fc18 will be an update
-- Running transaction check
--- Package systemd.i686 0:185-2.fc18 will be installed

After having had some funny issues in the past due to there being two 
systemds (x86_64, i686) installed for some reason, something tells me 
that it's a bad idea to proceed with the update. Or am I wrong?

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

Re: another upgrade, another disaster

2012-06-05 Thread Brian C. Lane
On Sun, Jun 03, 2012 at 10:32:37PM +0200, Björn Persson wrote:
 Tomasz Torcz wrote:
  You can write .iso image to USB key¹ and boot from it, you know.
 
 Even the installation DVD images? What I've heard is that that only works 
 with 
 the live CD images.

You can dd all of the iso's to USB or you can use livecd-iso-to-disk for
a bit more control over things (despite its name it also works with the
dvd iso).

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)


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

Re: another upgrade, another disaster

2012-06-05 Thread Adam Williamson
On Tue, 2012-06-05 at 16:28 -0700, Brian C. Lane wrote:
 On Sun, Jun 03, 2012 at 10:32:37PM +0200, Björn Persson wrote:
  Tomasz Torcz wrote:
   You can write .iso image to USB key¹ and boot from it, you know.
  
  Even the installation DVD images? What I've heard is that that only works 
  with 
  the live CD images.
 
 You can dd all of the iso's to USB or you can use livecd-iso-to-disk for
 a bit more control over things (despite its name it also works with the
 dvd iso).

The best documentation for this at present is
https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB - the
installation guide is a bit out of date (through no fault of the
authors, rather our fault in not notifying them of the various recent
improvements to the tools).
-- 
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: another upgrade, another disaster

2012-06-05 Thread Brian C. Lane
On Fri, Jun 01, 2012 at 09:48:37AM -0700, Adam Williamson wrote:
 On Fri, 2012-06-01 at 10:37 +0200, Caterpillar wrote:
 
   I am very disappointed with that, because preupgrade is the official
  supported way to upgrade Fedora versions
 
 Strictly, no. It's *a* supported way.
 
 Frankly, I'd prefer it if we more strongly recommended that people do
 DVD/netinst upgrades. That path is less complex than preupgrade and
 involves fewer moving parts; it's easier to test and easier to fix and
 more likely, in general, to be working at any given point.
 
 I'd put the possible upgrade methods in this order of
 likely-to-workness:
 
 1. netinst.iso / DVD.iso with 'updates' repo enabled
 2. DVD.iso without 'updates' repo
 3. yum *if you follow the instructions carefully*
 4. preupgrade
 5. yum by the He-Man method ('instructions are for wusses')

It should be possible to make preupgrade always work the best. It has
the most knowledge about the running system so it can pass that on to
Aanconda. We really need to work on making it more reliable for F18.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)


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

Re: another upgrade, another disaster

2012-06-05 Thread Brian C. Lane
On Mon, Jun 04, 2012 at 10:03:24AM +0200, Andrea Musuruane wrote:
 On Mon, Jun 4, 2012 at 8:50 AM, Adam Williamson awill...@redhat.com wrote:
  * 3rd attempt:
  Same as options as the 2nd attempt but this time I chose to enable
  only the F17 remote repositories and I disabled the Install repo so
  I presume all the packages were downloaded from the net. At about 85%
  of installation I got a kernel panic - this time I took care of the
  message unable to handle kernel NULL pointer dereference at
  0088.
 
  Frankly, I wouldn't trust your hardware.

ditto. Kernel panics are not normal :) The above info isn't enough to
track down what caused it, we need a picture of the screen.

[snip]

 
 Everything can be and I will run memtest as you advised.
 
 But I didn't had any kernel problem in the past - and I've used every
 Fedora release on the same PC for about 4 years. After I could bypass
 this problem - I could install the system, including I think all the
 RPMs anaconda was trying to install without any problem. Note that I
 don't run the same kernel used by anaconda because in fedora updates
 there is available a newer one.

Things work, until they don't. It is interesting that a minimal install
worked though. I would suspect bad ram as a possibility.

 
 Anyway, in case I hit this issue again, I would be interested to know
 how to get the log of this kind of error.

If it isn't a kernel panic you can get all the logs from Anaconda from
/tmp/*log -- switch to tty2 and you will have a shell where you can copy
them off the system. File a bug and attach the files as individual
text/plain attachments.

Failure to read the install media usually shows up as errors in syslog.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)


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

Re: Releasing ownership of many audio packages (and a little more)

2012-06-05 Thread Orcan Ogetbil
On Tue, Jun 5, 2012 at 12:53 PM, Anthony Green wrote:
 Fedora developers,

 While I brought many of these into Fedora, I have not been an active 
 maintainer for these packages for a very long time.  Most of them have very 
 responsible and active co-maintainers already.  I am about to release 
 ownership of the following packages:


Hi Anthony,
Thank you for all your services. Good work. I hope you will continue
to be a Fedora audio user.


 ardour -- Multichannel Digital Audio Workstation
 dssi -- Disposable Soft Synth Interface
 fluidsynth -- Real-time software synthesizer
 fluidsynth-dssi -- DSSI implementation of Fluidsynth
 hydrogen -- Advanced drum machine for GNU/Linux
 lash -- LASH Audio Session Handler
 libfreebob -- FreeBoB firewire audio driver library
 liblo -- Open Sound Control library
 liblrdf -- Library for manipulating RDF files describing LADSPA plugins
 whysynth-dssi -- DSSI software synthesizer plugin

I took the ownership of the above, as I was the one maintaining them lately.


 jack-audio-connection-kit -- The Jack Audio Connection Kit

I was already the primary maintainer of this. I think Anthony just
dropped his comaintainership.

As always, comaintainers welcome with any of these packages.


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

Re: *countable infinities only

2012-06-05 Thread Dennis Gilmore
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

El Tue, 05 Jun 2012 08:15:57 +0200
Tomas Mraz tm...@redhat.com escribió:
 On Mon, 2012-06-04 at 21:30 -0500, Dennis Gilmore wrote: 
  El Sat, 2 Jun 2012 12:18:17 -0400
  Orcan Ogetbil oget.fed...@gmail.com escribió:
   On Sat, Jun 2, 2012 at 12:05 PM, Jesse Keating wrote:
   
The only Freedom you've lost is that now, in addition to the
person-hours to do the work and monetary cost to host your bits
or generate physical media, you have an additional cost if you
wish to have your own cert that will be accepted out of the box
by the next generation of PC hardware.  You have as much equal
footing as Fedora does to plunk down the $99 and play along in
the PC sandbox. That's a better deal than Fedora's gpg signing
setup.
   
   
   Hmm, will the package maintainers have the freedom to not support
   users who have the secureboot enabled? How are we going to detect
   this?
  
  i look at it this way. if you patch your software to only run on
  machines with secureboot disabled your software then becomes non
  free and has to be removed from fedora.  this is becasuse you are
  placing usage restrictions on it. depending on the license of the
  software adding such a restriction would violate the license. I am
  not a lawyer at all and never pretend to play one, but i do not
  think you as a package maintainer can do that. an upstream could,
  but i imagine it would be viewed in the same light as a commercial
  use restriction and become non-free.
 
 That's a total nonsense unless the restriction is by-license and not
 just technical obstacle. If it is just a technical obstacle in the
 code, you can remove it and run the software on any crippled machine
 at your will. So no, making your software not to work on particular
 machines does not make it non-free at all.

We don't allow software in fedora that has a license that has a usage
restriction that says it can not be used in a commercial environment
for instance. I do not see why we would allow software that says you can
use this as long as secureboot is off. it is essentially the same
thing. its a usage restriction. 

im pretty sure that patching the GPL software to only run on a system
that does not have secureboot enabled at least falls into a grey area
if not plain violating the gpl
http://www.gnu.org/licenses/gpl-faq.html#OrigBSD 
Why is the original BSD license incompatible with the GPL? (#OrigBSD)

Because it imposes a specific requirement that is not in the GPL; namely, 
the requirement on advertisements of the program. Section 6 of GPLv2 states:

You may not impose any further restrictions on the recipients'
exercise of the rights granted herein.

by patching software to only work on secureboot free systems your
placing additional restrictions on the user thats not covered by the
GPL thats my take, i dont profess to be a lawyer or to play one on tv
so there is every chance i am wrong.

Dennis

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk/Ow7cACgkQkSxm47BaWffpvQCdHdtHKjZhBBMrbyX7BzadREij
PysAn3gdnKoe3n7K7g27NopWC5UF+s8T
=4r1U
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

2012-06-05 Thread Matthew Garrett
On Tue, Jun 05, 2012 at 09:43:03PM -0500, Dennis Gilmore wrote:

 We don't allow software in fedora that has a license that has a usage
 restriction that says it can not be used in a commercial environment
 for instance. I do not see why we would allow software that says you can
 use this as long as secureboot is off. it is essentially the same
 thing. its a usage restriction. 

There's a distinction between something that's enforced by the license 
and something that's merely code. We may not agree with maintainer 
decisions, and we (as a project) may even require that they be reverted, 
but we have the freedom to remove that restriction and therefore it's 
not an issue as far as free software is concerned.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

2012-06-05 Thread Dennis Gilmore
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

El Wed, 6 Jun 2012 03:58:14 +0100
Matthew Garrett mj...@srcf.ucam.org escribió:
 On Tue, Jun 05, 2012 at 09:43:03PM -0500, Dennis Gilmore wrote:
 
  We don't allow software in fedora that has a license that has a
  usage restriction that says it can not be used in a commercial
  environment for instance. I do not see why we would allow software
  that says you can use this as long as secureboot is off. it is
  essentially the same thing. its a usage restriction. 
 
 There's a distinction between something that's enforced by the
 license and something that's merely code. We may not agree with
 maintainer decisions, and we (as a project) may even require that
 they be reverted, but we have the freedom to remove that restriction
 and therefore it's not an issue as far as free software is concerned.
 

im talking purely about the wording of the license in that paragraph.
if someone sumbited a license that had something along the lines of
software under this license can not be used on UEFI systems with
secure mode enabled  we would reject the license as unfree.


Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk/OyacACgkQkSxm47BaWff8HgCfUDzTBYg/Y4tZjejbzUQASGGA
QvIAnRlkViNXPyd2uHZyGdMZAmWJwpfX
=IATT
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

2012-06-05 Thread Rahul Sundaram
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/06/2012 08:38 AM, Dennis Gilmore wrote:

 
 im talking purely about the wording of the license in that
 paragraph. if someone sumbited a license that had something along
 the lines of software under this license can not be used on UEFI
 systems with secure mode enabled  we would reject the license as
 unfree.

Nobody else was talking about license restrictions.  If such a license
is written, then, yes it would be non-free.

Rahul
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPzua5AAoJELauRe7G9dGM6j8H/Aq9iETe9BpG/kPvIChaZYL+
xWUgP7b8w4p4yP7W8omV2Wl/kKI88vhy32lRr9Ax+HdQXHMn/e33DC/ZQYoGC3ZJ
eBzwxB0llxrqKciVJsQFkdNdufcx/50t30T3ZjwhIPv6Rni4M1U1M5drYwUgUoOz
Jm0UxjgYt7toHdjTZUh8DivhTRpcUA+/eH2zmZA/lwjzD+/yQNmNXzPIzZ2sn1pf
o14akH6NeQN4BQa3Nh0GvT528iNfgUeCJPMdTIGa7f/Fur4T0RHXXQD8blgagFEz
1tPZKLsjZw7ddv+SfuLZuy2nO8h7rwLr9H1RFTLCZjk8iKQSMYlLfrO3XrR0xKQ=
=xMmu
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 823390] Please upgrade to FC16's perl-URI to = 1.59

2012-06-05 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=823390

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

   What|Removed |Added

 CC||ppi...@redhat.com

--- Comment #4 from Petr Pisar ppi...@redhat.com ---
$ koji list-tag-history --build=perl-URI-1.60-1.fc16
Warning: the pkgurl option is obsolete, using
topurl='http://koji.fedoraproject.org'
Mon May 21 09:34:48 2012: perl-URI-1.60-1.fc16 tagged into
f16-updates-candidate by pghmcfc
Mon May 21 09:40:25 2012: perl-URI-1.60-1.fc16 tagged into
f16-updates-testing-pending by bodhi
Mon May 21 21:29:33 2012: perl-URI-1.60-1.fc16 untagged from
f16-updates-candidate by bodhi
Mon May 21 21:29:33 2012: perl-URI-1.60-1.fc16 tagged into f16-updates-testing
by bodhi [still active]
Mon May 21 21:36:29 2012: perl-URI-1.60-1.fc16 untagged from
f16-updates-testing-pending by bodhi

That's not two weeks yet.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 828689] New: Upgrade to new upstream version

2012-06-05 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=828689

Bug ID: 828689
QA Contact: extras...@fedoraproject.org
  Severity: unspecified
   Version: el6
  Priority: unspecified
CC: perl-devel@lists.fedoraproject.org,
steve.tray...@cern.ch
  Assignee: steve.tray...@cern.ch
   Summary: Upgrade to new upstream version
Regression: ---
  Story Points: ---
Classification: Fedora
OS: Unspecified
  Reporter: lionel.c...@cern.ch
  Type: Bug
 Documentation: ---
  Hardware: Unspecified
Mount Type: ---
Status: NEW
 Component: perl-Directory-Queue
   Product: Fedora EPEL

The latest version of Directory::Queue on CPAN is now 1.6.

This is the version to use everywhere. Please upgrade in EPEL.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 823390] Please upgrade to FC16's perl-URI to = 1.59

2012-06-05 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=823390

--- Comment #5 from Petr Pisar ppi...@redhat.com ---
My calendar has different rules :) I've just submitted it for stable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File POE-Component-Client-HTTP-0.947.tar.gz uploaded to lookaside cache by psabata

2012-06-05 Thread Petr Šabata
A file has been added to the lookaside cache for perl-POE-Component-Client-HTTP:

43f600c77ccf40b44c585955d5656ae4  POE-Component-Client-HTTP-0.947.tar.gz
--
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-POE-Component-Client-HTTP] 0.947 bump

2012-06-05 Thread Petr Šabata
commit 59d6a8c3c451d2fe900ea62de1558938cbc52b4b
Author: Petr Šabata con...@redhat.com
Date:   Tue Jun 5 11:00:14 2012 +0200

0.947 bump

 .gitignore  |1 +
 perl-POE-Component-Client-HTTP.spec |   14 --
 sources |2 +-
 3 files changed, 10 insertions(+), 7 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 75c1ddb..c62296c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ POE-Component-Client-HTTP-0.895.tar.gz
 /POE-Component-Client-HTTP-0.944.tar.gz
 /POE-Component-Client-HTTP-0.945.tar.gz
 /POE-Component-Client-HTTP-0.946.tar.gz
+/POE-Component-Client-HTTP-0.947.tar.gz
diff --git a/perl-POE-Component-Client-HTTP.spec 
b/perl-POE-Component-Client-HTTP.spec
index 0b01697..be44d80 100644
--- a/perl-POE-Component-Client-HTTP.spec
+++ b/perl-POE-Component-Client-HTTP.spec
@@ -7,7 +7,7 @@
 #   define _with_network_tests 1 in your ~/.rpmmacros
 
 Name:   perl-POE-Component-Client-HTTP
-Version:0.946
+Version:0.947
 Release:1%{?dist}
 Summary:A non-blocking/parallel web requests engine for POE
 Group:  Development/Libraries
@@ -30,7 +30,7 @@ BuildRequires:  perl(IO::Handle)
 BuildRequires:  perl(IO::Socket::INET)
 BuildRequires:  perl(Net::HTTP::Methods) = 5.812
 BuildRequires:  perl(POE) = 1.312
-# Original perl(POE::Component::Client::Keepalive) = 0.268 rounded to
+# Original perl(POE::Component::Client::Keepalive) = 0.271 rounded to
 # 4 digit precision
 BuildRequires:  perl(POE::Component::Client::Keepalive) = 0.2710
 BuildRequires:  perl(POE::Driver::SysRW)
@@ -40,8 +40,7 @@ BuildRequires:  perl(POE::Filter::Stackable)
 BuildRequires:  perl(POE::Filter::Stream)
 BuildRequires:  perl(POE::Session)
 BuildRequires:  perl(Scalar::Util)
-BuildRequires:  perl(Socket)
-BuildRequires:  perl(Socket::GetAddrInfo) = 0.19
+BuildRequires:  perl(Socket) = 2.001
 BuildRequires:  perl(URI) = 1.37
 BuildRequires:  perl(Test::Pod)
 BuildRequires:  perl(Test::Pod::Coverage)
@@ -55,10 +54,10 @@ Requires:   perl(HTTP::Response) = 5.813
 Requires:   perl(HTTP::Status) = 5.811
 Requires:   perl(Net::HTTP::Methods) = 5.812
 Requires:   perl(POE) = 1.312
-# Original perl(POE::Component::Client::Keepalive) = 0.268 rounded to
+# Original perl(POE::Component::Client::Keepalive) = 0.271 rounded to
 # 4 digit precision
 Requires:   perl(POE::Component::Client::Keepalive) = 0.2710
-Requires:   perl(Socket::GetAddrInfo) = 0.19
+Requires:   perl(Socket) = 2.001
 Requires:   perl(URI) = 1.37
 Requires:  perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
 
@@ -97,6 +96,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Tue Jun 05 2012 Petr Šabata con...@redhat.com - 0.947-1
+- 0.947 bump
+
 * Tue May 15 2012 Petr Šabata con...@redhat.com - 0.946-1
 - 0.946 bump
 
diff --git a/sources b/sources
index 1d66bd0..e1746d7 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6fcd1d7d4a7e62d4bedf25341038c450  POE-Component-Client-HTTP-0.946.tar.gz
+43f600c77ccf40b44c585955d5656ae4  POE-Component-Client-HTTP-0.947.tar.gz
--
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 828230] perl-POE-Component-Client-HTTP-0.947 is available

2012-06-05 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=828230

Petr Šabata psab...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-POE-Component-Client-H
   ||TTP-0.947-1.fc18
 Resolution|--- |RAWHIDE
Last Closed||2012-06-05 05:35:23

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 828216] perl-DBD-CSV-0.35 is available

2012-06-05 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=828216

Petr Šabata psab...@redhat.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||psab...@redhat.com
   Assignee|mmasl...@redhat.com |psab...@redhat.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File DBD-CSV-0.35.tgz uploaded to lookaside cache by psabata

2012-06-05 Thread Petr Šabata
A file has been added to the lookaside cache for perl-DBD-CSV:

90e1635b1b2e4605f5dc6939c41e3087  DBD-CSV-0.35.tgz
--
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-DBD-CSV] 0.35 bump

2012-06-05 Thread Petr Šabata
commit 7ea5ec0627d12b4dbf2ddd93cc41c114ec30bae8
Author: Petr Šabata con...@redhat.com
Date:   Tue Jun 5 14:21:22 2012 +0200

0.35 bump

 .gitignore|1 +
 perl-DBD-CSV.spec |6 --
 sources   |2 +-
 3 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d5641bc..b434b70 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ DBD-CSV-0.30.tgz
 /DBD-CSV-0.31.tgz
 /DBD-CSV-0.33.tgz
 /DBD-CSV-0.34.tgz
+/DBD-CSV-0.35.tgz
diff --git a/perl-DBD-CSV.spec b/perl-DBD-CSV.spec
index 9a3ddbc..5b5c3de 100644
--- a/perl-DBD-CSV.spec
+++ b/perl-DBD-CSV.spec
@@ -1,5 +1,5 @@
 Name:   perl-DBD-CSV
-Version:0.34
+Version:0.35
 Release:1%{?dist}
 Summary:DBI driver for CSV files
 Group:  Development/Libraries
@@ -13,7 +13,6 @@ BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(SQL::Statement) = 1.33
 BuildRequires:  perl(Text::CSV_XS) = 0.71
 BuildRequires:  perl(Test::Harness)
-# BuildRequires = 0.90, but 0.98 is recommended
 BuildRequires:  perl(Test::More) = 0.98
 Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
 Requires:   perl(DBD::File) = 0.40
@@ -62,6 +61,9 @@ make test
 %{_mandir}/man3/*.3pm*
 
 %changelog
+* Tue Jun 05 2012 Petr Šabata con...@redhat.com - 0.35-1
+- 0.35 bump (documentation changes)
+
 * Tue May 15 2012 Petr Šabata con...@redhat.com - 0.34-1
 - 0.34 bump (no code changes)
 - Drop commands macros
diff --git a/sources b/sources
index e70aaea..7a8d82f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-03109a9f2cf52da45aa5d7635d8d2dea  DBD-CSV-0.34.tgz
+90e1635b1b2e4605f5dc6939c41e3087  DBD-CSV-0.35.tgz
--
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 828216] perl-DBD-CSV-0.35 is available

2012-06-05 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=828216

Petr Šabata psab...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-DBD-CSV-0.35-1.fc18
 Resolution|--- |RAWHIDE
Last Closed||2012-06-05 08:33:26

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 828819] New: annoying warning

2012-06-05 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=828819

Bug ID: 828819
QA Contact: extras...@fedoraproject.org
  Severity: unspecified
   Version: 17
  Priority: unspecified
CC: david.hanneq...@gmail.com,
perl-devel@lists.fedoraproject.org
  Assignee: david.hanneq...@gmail.com
   Summary: annoying warning
Regression: ---
  Story Points: ---
Classification: Fedora
OS: Unspecified
  Reporter: abartrav...@gmail.com
  Type: Bug
 Documentation: ---
  Hardware: Unspecified
Mount Type: ---
Status: NEW
 Component: perl-Curses-UI
   Product: Fedora

Created attachment 589517
  -- https://bugzilla.redhat.com/attachment.cgi?id=589517action=edit
test program

Description of problem:

Prototype after '@' for Curses::UI::Widget::width_by_windowscrwidth : $@; at
/usr/share/perl5/vendor_perl/Curses/UI/Widget.pm line 356.
Prototype after '@' for Curses::UI::Widget::height_by_windowscrheight : $@; at
/usr/share/perl5/vendor_perl/Curses/UI/Widget.pm line 380.
Prototype after '@' for Curses::UI::Widget::set_binding : $@; at
/usr/share/perl5/vendor_perl/Curses/UI/Widget.pm line 898.
Prototype after '@' for Curses::UI::Widget::set_mouse_binding : $@; at
/usr/share/perl5/vendor_perl/Curses/UI/Widget.pm line 924.
Prototype after '@' for Curses::UI::Container::add : $@; at
/usr/share/perl5/vendor_perl/Curses/UI/Container.pm line 67.
Prototype after '@' for Curses::UI::Container::set_focusorder : @; at
/usr/share/perl5/vendor_perl/Curses/UI/Container.pm line 475.
Prototype after '@' for Curses::UI::Container::set_draworder : @; at
/usr/share/perl5/vendor_perl/Curses/UI/Container.pm line 483.


Version-Release number of selected component (if applicable):
perl-Curses-UI-0.9607-8.fc17.noarch.rpm

How reproducible:
always

Steps to Reproduce:
1.run edit.pl
2.
3.

Actual results:


Expected results:


Additional info:
solved in upstream Curses-UI-0.9609.tar.gz

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 828819] annoying warning

2012-06-05 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=828819

antb52 abartrav...@gmail.com changed:

   What|Removed |Added

   Hardware|Unspecified |x86_64
 OS|Unspecified |Linux

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File File-MMagic-1.28.tar.gz uploaded to lookaside cache by psabata

2012-06-05 Thread Petr Šabata
A file has been added to the lookaside cache for perl-File-MMagic:

ea74f4c817229117f4e9341889430308  File-MMagic-1.28.tar.gz
--
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-File-MMagic] 1.28 bump and some cleanup

2012-06-05 Thread Petr Šabata
commit ff5cf966f0806acc0934067d52356e0d2f4fc618
Author: Petr Šabata con...@redhat.com
Date:   Tue Jun 5 15:11:17 2012 +0200

1.28 bump and some cleanup

 .gitignore|1 +
 perl-File-MMagic.spec |   46 --
 sources   |2 +-
 3 files changed, 22 insertions(+), 27 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index df53593..64ab20f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@ File-MMagic-1.22.tar.gz
 File-MMagic-1.25.tar.gz
 File-MMagic-1.26.tar.gz
 File-MMagic-1.27.tar.gz
+/File-MMagic-1.28.tar.gz
diff --git a/perl-File-MMagic.spec b/perl-File-MMagic.spec
index 5932c5c..4b5768f 100644
--- a/perl-File-MMagic.spec
+++ b/perl-File-MMagic.spec
@@ -1,56 +1,50 @@
 Name:   perl-File-MMagic
-Version:1.27
-Release:13%{?dist}
+Version:1.28
+Release:1%{?dist}
 Summary:A Perl module emulating the file(1) command
-
 Group:  Development/Libraries
 License:ASL 1.0 and BSD
 URL:http://search.cpan.org/dist/File-MMagic/
 Source0:
http://www.cpan.org/authors/id/K/KN/KNOK/File-MMagic-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
 BuildArch:  noarch
 BuildRequires:  perl(ExtUtils::MakeMaker)
-Requires:   perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
+BuildRequires:  perl(Scalar::Util)
+BuildRequires:  perl(Test)
+Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
 
 %description
 This module attempts to guess file type from its contents like file(1)
 command.
 
-
 %prep
-%setup -q -n File-MMagic-%{version} 
-
+%setup -q -n File-MMagic-%{version}
+iconv -f ISO-2022-JP -t utf8 README.ja  README.ja.utf8  mv README.ja.utf8 
README.ja
 
 %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
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
-
+make pure_install PERL_INSTALL_ROOT=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+find %{buildroot} -type d -depth -exec rmdir {} 2/dev/null ';'
+chmod -R u+w %{buildroot}/*
 
 %check
 make test
 
-
-%clean
-rm -rf $RPM_BUILD_ROOT
-
-
 %files
-%defattr(-,root,root,-)
-%doc ChangeLog COPYING README.en
+%doc ChangeLog COPYING README.en README.ja
 %{perl_vendorlib}/File/
 %{_mandir}/man3/*.3*
 
-
 %changelog
+* Tue Jun 05 2012 Petr Šabata con...@redhat.com - 1.28-1
+- 1.28 bump
+- Modernizing spec (removing buildroot, defattr, and command macros)
+- Removing trailing whitespace
+- Packaging README.ja
+
 * Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 1.27-13
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
 
@@ -123,4 +117,4 @@ rm -rf $RPM_BUILD_ROOT
 - update to 1.15
 
 * Fri Dec 7 2001 root r...@redhat.com
-- Spec file was autogenerated. 
+- Spec file was autogenerated.
diff --git a/sources b/sources
index e158e90..4302e74 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4ffb13b6587888e6e455c22988abce5e  File-MMagic-1.27.tar.gz
+ea74f4c817229117f4e9341889430308  File-MMagic-1.28.tar.gz
--
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 828232] perl-SQL-Library-0.0.4 is available

2012-06-05 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=828232

Petr Šabata psab...@redhat.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|mmasl...@redhat.com |psab...@redhat.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[abi-compliance-checker/el6] Drop gcc version requirement

2012-06-05 Thread Orion Poplawski
commit 68018535d8d44bb876662c84af8928aa02b9d633
Author: Orion Poplawski or...@cora.nwra.com
Date:   Tue Jun 5 09:50:49 2012 -0600

Drop gcc version requirement

 abi-compliance-checker.spec |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/abi-compliance-checker.spec b/abi-compliance-checker.spec
index ad57d08..9119f9e 100644
--- a/abi-compliance-checker.spec
+++ b/abi-compliance-checker.spec
@@ -8,7 +8,7 @@ URL:
http://ispras.linuxbase.org/index.php/ABI_compliance_checker
 Source0:
https://github.com/lvc/%{name}/downloads/%{name}-%{version}.tar.gz
 
 BuildArch:  noarch
-Requires:   gcc = 4.5
+Requires:   gcc
 Requires:   binutils
 
 %{?perl_default_filter}
--
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 828232] perl-SQL-Library-0.0.4 is available

2012-06-05 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=828232

Petr Šabata psab...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-SQL-Library-0.0.4-1.fc
   ||18
 Resolution|--- |RAWHIDE
Last Closed||2012-06-05 12:24:12

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 823390] Please upgrade to FC16's perl-URI to = 1.59

2012-06-05 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=823390

--- Comment #6 from Ralf Corsepius rc040...@freenet.de ---

(In reply to comment #5)
From comment #3: Fedora Update System 2012-05-21 22:20:32 EDT ...

... Today is June 5th ...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 818651] Conflicts with my package apache-1.3.42-3.fc16.x86_64

2012-06-05 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=818651

Sergio Monteiro Basto ser...@serjux.com changed:

   What|Removed |Added

   Severity|high|low

--- Comment #3 from Sergio Monteiro Basto ser...@serjux.com ---
and also, not severity high

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 828203] Locale-Codes 3.22 is available

2012-06-05 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=828203

Fedora Update System upda...@fedoraproject.org changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA

--- Comment #4 from Fedora Update System upda...@fedoraproject.org ---
Package perl-Locale-Codes-3.22-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing perl-Locale-Codes-3.22-1.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-8841/perl-Locale-Codes-3.22-1.fc16
then log in and leave karma (feedback).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 828234] perl-URI-Title-1.86 is available

2012-06-05 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=828234

Fedora Update System upda...@fedoraproject.org changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA

--- Comment #2 from Fedora Update System upda...@fedoraproject.org ---
Package perl-URI-Title-1.86-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing perl-URI-Title-1.86-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-8847/perl-URI-Title-1.86-1.fc17
then log in and leave karma (feedback).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-CHI] Upstream update.

2012-06-05 Thread corsepiu
commit 32a04c1d7b7923aca6fe6d43c001c91fc96cfe1b
Author: Ralf Corsépius corse...@fedoraproject.org
Date:   Wed Jun 6 04:29:14 2012 +0200

Upstream update.

- Cleanup perl module filters.

 .gitignore|2 +-
 perl-CHI.spec |   16 +++-
 sources   |2 +-
 3 files changed, 9 insertions(+), 11 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 68bedbc..2dcf302 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/CHI-0.52.tar.gz
+/CHI-0.53.tar.gz
diff --git a/perl-CHI.spec b/perl-CHI.spec
index b7f1957..46d209c 100644
--- a/perl-CHI.spec
+++ b/perl-CHI.spec
@@ -1,5 +1,5 @@
 Name:   perl-CHI
-Version:0.52
+Version:0.53
 Release:1%{?dist}
 Summary:Unified cache handling interface
 License:GPL+ or Artistic
@@ -28,6 +28,7 @@ BuildRequires:  perl(Log::Any::Adapter::Dispatch) = 0.05
 BuildRequires:  perl(Module::Load::Conditional)
 BuildRequires:  perl(Moose) = 0.66
 BuildRequires:  perl(Storable)
+BuildRequires:  perl(String::RewritePrefix)
 BuildRequires:  perl(Task::Weaken)
 BuildRequires:  perl(Test::Builder)
 BuildRequires:  perl(Test::Class)
@@ -52,12 +53,7 @@ BuildRequires:   perl(Cache::FastMmap)
 
 %{?perl_filter_default}
 
-# RPM 4.8 style
 %{?filter_setup:
-%filter_from_provides /^perl(Bar)/d
-%filter_from_provides /^perl(Baz)/d
-%filter_from_provides /^perl(DummySerializer)/d
-%filter_from_provides /^perl(Foo)/d
 # Replace unversioned dependencies with versioned ones.
 %filter_from_requires s/^perl(Carp::Assert)$/perl(Carp::Assert) = 0.20/
 %filter_from_requires s/^perl(List::MoreUtils)$/perl(List::MoreUtils) = 0.13/
@@ -67,12 +63,10 @@ BuildRequires:  perl(Cache::FastMmap)
 %filter_from_requires 
s/^perl(Time::Duration::Parse)$/perl(Time::Duration::Parse) = 0.03/
 %filter_setup
 }
-# RPM 4.9 style
+
 %global __provides_exclude 
%{?__provides_exclude:__provides_exclude|}^perl\\(Bar\\)
 %global __provides_exclude %__provides_exclude|^perl\\(DummySerializer\\)
 %global __provides_exclude %__provides_exclude|^perl\\(Foo\\)
-# Replace unversioned dependencies with versioned ones.
-# Already auto-discovered. In addition, RPM 4.9 does not offer replacing.
 
 %description
 CHI provides a unified caching API, designed to assist a developer in
@@ -131,6 +125,10 @@ make test %{?with_author_tests:AUTHOR_TESTING=1} 
%{?with_smoke_tests:AUTOMATED_T
 %{perl_vendorlib}/CHI/Test*
 
 %changelog
+* Wed Jun 06 2012 Ralf Corsépius corse...@fedoraproject.org - 0.53-1
+- Upstream update.
+- Cleanup perl module filters.
+
 * Mon Mar 19 2012 Ralf Corsépius corse...@fedoraproject.org - 0.52-1
 - Upstream update.
 
diff --git a/sources b/sources
index a160fd2..9fa1a8b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b608caf538c6b012f4c0ca5337771972  CHI-0.52.tar.gz
+2e35d6819725e0b4decdabb00bdb23fa  CHI-0.53.tar.gz
--
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-CHI/f17] Upstream update.

2012-06-05 Thread corsepiu
Summary of changes:

  32a04c1... Upstream update. (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-CHI/f16] (2 commits) ...Merge remote-tracking branch 'origin/f17' into f16

2012-06-05 Thread corsepiu
Summary of changes:

  32a04c1... Upstream update. (*)
  0009b4f... Merge remote-tracking branch 'origin/f17' into f16

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-CHI/f16: 2/2] Merge remote-tracking branch 'origin/f17' into f16

2012-06-05 Thread corsepiu
commit 0009b4f03365c354520f3e7c5bde9fa2e9073d93
Merge: 4655b80 32a04c1
Author: Ralf Corsépius corse...@fedoraproject.org
Date:   Wed Jun 6 04:31:39 2012 +0200

Merge remote-tracking branch 'origin/f17' into f16

 .gitignore|2 +-
 perl-CHI.spec |   16 +++-
 sources   |2 +-
 3 files changed, 9 insertions(+), 11 deletions(-)
---
--
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

File CHI-0.54.tar.gz uploaded to lookaside cache by corsepiu

2012-06-05 Thread corsepiu
A file has been added to the lookaside cache for perl-CHI:

2b638e3887497bee4a0d3eb3e7e407ad  CHI-0.54.tar.gz
--
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-CHI] Upstream update.

2012-06-05 Thread corsepiu
commit f3b910dc187ecca4b2ffb9bca2871537b8b4e428
Author: Ralf Corsépius corse...@fedoraproject.org
Date:   Wed Jun 6 04:44:58 2012 +0200

Upstream update.

 .gitignore|2 +-
 perl-CHI.spec |5 -
 sources   |2 +-
 3 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 2dcf302..c1bde9d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/CHI-0.53.tar.gz
+/CHI-0.54.tar.gz
diff --git a/perl-CHI.spec b/perl-CHI.spec
index 46d209c..13c3acc 100644
--- a/perl-CHI.spec
+++ b/perl-CHI.spec
@@ -1,5 +1,5 @@
 Name:   perl-CHI
-Version:0.53
+Version:0.54
 Release:1%{?dist}
 Summary:Unified cache handling interface
 License:GPL+ or Artistic
@@ -125,6 +125,9 @@ make test %{?with_author_tests:AUTHOR_TESTING=1} 
%{?with_smoke_tests:AUTOMATED_T
 %{perl_vendorlib}/CHI/Test*
 
 %changelog
+* Wed Jun 06 2012 Ralf Corsépius corse...@fedoraproject.org - 0.54-1
+- Upstream update.
+
 * Wed Jun 06 2012 Ralf Corsépius corse...@fedoraproject.org - 0.53-1
 - Upstream update.
 - Cleanup perl module filters.
diff --git a/sources b/sources
index 9fa1a8b..260d71d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2e35d6819725e0b4decdabb00bdb23fa  CHI-0.53.tar.gz
+2b638e3887497bee4a0d3eb3e7e407ad  CHI-0.54.tar.gz
--
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