date:20130204

On Mon, 04 Feb 2013 08:35:43 +0100 
Kevin Kofler wrote:

 PPS: Oh, and this:
  The /usr/bin/soffice alias is still a problem since (in the Fedora
  packages) it would conflict between LibreOffice and Apache
  OpenOffice: it is recommended to fix it in the LibreOffice packages
  too, at least using the Alternatives system.
 is just not acceptable. Alternatives is the wrong solution for this
 (in fact, I'd argue it's always the wrong solution), because it is
 systemwide. Why can't you just rename or delete /usr/bin/soffice?
+1 from me as well. Having alternatives for this is just bad. Either
you're saying you're packaging something different -- then alternatives
is out of question -- or you're packaging something that is 1:1
interchangeable, but than I don't see a reason to actually ship
both.

I disagree with your previous mail though (even though I don't
necessarily disagree with your reasoning against - i.e. waste of
resources *is* a strong argument). While AOO and LO started from the
same point, they're not doing the same *and* in the future you can
expect further divergence. Fedora has always been the one to bring new
things first, we should do so, IMHO, in this case as well. 

Also, going by your reasoning there would be no point in having
Calligra either... Furthermore, technically LO is the fork ;-) 

I don't think Oracle has anything to do with it any more, they just got
rid of unwanted spoils of war. Although, I might be wrong.

Martin



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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Mon, 04 Feb 2013 08:34:03 +0100 
Kevin Kofler wrote:

 I wrote:
 
  Sandro Mani wrote:
  Can't we simply re-organize the fedoraproject website in such way
  that the download button points to something similar to the
  current More options page, maybe with a small description for
  each desktop like easy to use / feature rich and
  customizable / based on the traditional desktop / etc and
  possibly sorted by popularity, i.e. number of downloads?
  
  +1, I've been asking for that ever since the get-fedora redesign
  and the introduction of that misguided direct link to the wrong ISO
  (GNOME-only and 32-bit-only).
 
 PS: It's actually 64-bit-only now, but that doesn't solve the issue,
 it'll just be wrong for a different category of users. Whatever you
 pick, it's always wrong for somebody, which is why bypassing the
 choice of ISO doesn't make any sense whatsoever.
 
Big +1. What will an unsuspecting user think when he downloads, burns
and tries Fedora on 32bit machine? That it's broken, because the
download link actually links to the 64bit iso (and yes, I just tried it
on a 32bit machine and it still links to the 64bit image) :-/ The best
thing to drive potential users away is to give them one-click download
that is broken...

Martin


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

rawhide report: 20130204 changes

2013-02-04 Thread Fedora Rawhide Report

Compose started at Mon Feb  4 08:15:37 UTC 2013

Broken deps for x86_64
--
[bootconf]
bootconf-1.4-6.fc18.noarch requires grub
[compat-gcc-34]
compat-gcc-34-c++-3.4.6-24.fc17.x86_64 requires libstdc++  0:4.8.0
[couchdb]
couchdb-1.2.1-2.fc19.x86_64 requires libicuuc.so.49()(64bit)
couchdb-1.2.1-2.fc19.x86_64 requires libicui18n.so.49()(64bit)
couchdb-1.2.1-2.fc19.x86_64 requires libicudata.so.49()(64bit)
[dragonegg]
dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19
[eclipse-linuxtools]
eclipse-systemtap-1.2.0-4.fc19.noarch requires kernel-debuginfo
[epiphany-extensions]
epiphany-extensions-3.6.0-1.fc19.x86_64 requires epiphany(abi) = 0:3.6
[fawkes]
fawkes-guis-0.5.0-5.fc19.i686 requires libgraph.so.5
fawkes-guis-0.5.0-5.fc19.x86_64 requires libgraph.so.5()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libgeos-3.3.6.so()(64bit)
[fcitx-keyboard]
fcitx-keyboard-0.1.3-1.fc18.x86_64 requires libicuuc.so.49()(64bit)
[flowcanvas]
flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5
flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit)
[frysk]
frysk-0.4-37.fc19.x86_64 requires libgcj.so.13()(64bit)
[gcc-python-plugin]
gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 
0:4.7.2-8.fc19
gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19
gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 
0:4.7.2-8.fc19
gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19
[gdcm]
gdcm-2.0.18-6.fc18.i686 requires libpoppler.so.26
gdcm-2.0.18-6.fc18.x86_64 requires libpoppler.so.26()(64bit)
[gfal]
gfal-1.14.0-1.fc18.i686 requires libgsoap.so.2
gfal-1.14.0-1.fc18.x86_64 requires libgsoap.so.2()(64bit)
gfal-doc-1.14.0-1.fc18.x86_64 requires libgsoap.so.2()(64bit)
gfal-python-1.14.0-1.fc18.x86_64 requires libgsoap.so.2()(64bit)
[ghc-wai-extra]
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSzlib-conduit-0.4.0.2-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSzlib-bindings-0.1.0.1-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSzlib-0.5.3.3-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSwai-1.2.0.3-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSvoid-0.5.6-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSvault-0.2.0.0-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSunordered-containers-0.2.1.0-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSunix-2.5.1.0-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHStransformers-base-0.4.1-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHStransformers-0.3.0.0-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHStime-1.4-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHStext-0.11.2.0-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSresourcet-0.3.2.2-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSparsec-3.1.2-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSold-time-1.1.0.0-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSold-locale-1.0.0.4-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSnetwork-2.3.0.13-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSmtl-2.1.1-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSmonad-control-0.3.1.3-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSlifted-base-0.1.1-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSinteger-gmp-0.4.0.0-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHShttp-types-0.6.11-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHShashable-1.1.2.3-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSghc-prim-0.2.0.0-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSfilepath-1.3.0.0-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSfast-logger-0.0.2-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSdlist-0.5-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSdirectory-1.1.0.2-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires 
libHSdeepseq-1.3.0.0-ghc7.4.1.so()(64bit)

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Mon, 04 Feb 2013 06:36:23 +0100 
Kevin Kofler wrote:

 Eric Smith wrote:
 
  On 01/28/2013 08:47 AM, Máirín Duffy wrote:
  I think switching the desktop that has been our default for over 10
  years and 18 releases requires just a bit more research and reason
  than that. ~m
  
  I don't disagree with the more research and reason part, but the
  current default desktop has only been our default for four
  releases, F15 through F18.  I don't recall any serious research
  and reason having been involved in the switch that occurred when
  F15 was being developed.  As far as I can tell, it was just thrust
  upon us without much consideration as to whether it was good, bad,
  or indifferent.  My proposal is at least only that, a proposal, and
  is not being thrust upon anyone without discussion and ultimately a
  vote.
 
 +1, what is the default now is a very different (and much less
 popular) beast from what had been the default for over 10 years.
 
Totally agree, but I have to say -- unless you get rid of *default*
altogether -- that the default has to be supported rather well, and you
cannot force devs to start working on Cinnamon, XFCE, KDE, or whatever
based on a popularity poll. If we have a default, it should have a
strong developer backing and, as much as I don't like it, for Fedora
that currently (sadly) means Gnome Shell.

Martin


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

Re: Proposed F19 Feature: Apache OpenOffice

2013-02-04 Thread Michael Stahl

On 04/02/13 13:59, Martin Sourada wrote:
 Also, going by your reasoning there would be no point in having
 Calligra either... Furthermore, technically LO is the fork ;-) 

technically, both Apache OpenOffice and LibreOffice are forks, since
neither of them:

a) are under the OpenOffice.org governance scheme
b) are developed under the processes that OpenOffice.org used
c) require a copyright assignment to Sun/Oracle to contribute
d) license the code under LGPLv3 as OpenOffice.org always was
   [this is technically still true for LibreOffice but will change]
e) are developed by the Sun/Oracle staff that have always
   done the majority of the programming on OpenOffice.org in its time
f) run on the infrastructure in Sun/Oracle's Hamburg lab


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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-02-04 Thread Mark Bidewell

On Mon, Feb 4, 2013 at 12:49 AM, Kevin Kofler kevin.kof...@chello.atwrote:

 Matthias Clasen wrote:
  - Cinnamon started out as 'using GNOME components', but it is [now] a
 full
  fork of mutter, gnome-shell and nautilus, at least, and bug-fixes are not
  going either way...

 Those are applications which form the workspace, not random components.
 I'm fairly sure that when they speak about reusing GNOME components, they
 really mean the libraries and the standalone applications, not the
 workspace.

 (For those familiar with KDE, what they're forking is only the GNOME
 equivalent of kde-workspace and not all the other components of GNOME.)

 Kevin Kofler

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


I would oppose Cinnamon as a default on stability/maturity grounds.  The
last time I tried Cinnamon (granted this was on Ubuntu) it had a lot of
problems.  For example Nemo would get into fights with the default
installed nautilus resulting in no desktop icons. The massive forking of
underlying components could easily create problems. KDE however is a tested
desktop which I would love to see as the default (or as others have
proposed a no default).  In my opinion Fedora ships the best KDE around.
 Although early signs seem to point to Kubuntu 13.04 really improving under
Blue Systems TLC.

-- 
Mark Bidewell
http://www.linkedin.com/in/markbidewell
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-02-04 Thread Jan Kratochvil

On Mon, 04 Feb 2013 14:16:58 +0100, Martin Sourada wrote:
 Big +1. What will an unsuspecting user think when he downloads, burns
 and tries Fedora on 32bit machine? That it's broken,

From what I have reports even Fedora 32-bit does not boot on such machines
because nobody tests the bleeding edge Fedora kernels on such obsolete
hardware.


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

[Bug 907464] New: cpanm bundle lots of library and is not listed on fesco page

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

Bug ID: 907464
   Summary: cpanm bundle lots of library and is not listed on
fesco page
   Product: Fedora
   Version: 18
 Component: perl-App-cpanminus
  Severity: unspecified
  Priority: unspecified
  Reporter: m...@zarb.org
Blocks: 504493 (DuplicSysLibsTracker)

According to the comment in the spec, and the source of cpanm, there is lots of
perl modules bundle into the main software. While the way cpanm work kinda
mandate it, I think there should be some tracking for it, only for security
update reasons.

I would suggest to contact fesco and see what to do ( ie, either unbundle, or
get a bundle exception, and list the module on the appropriate page, with
appropriate provides bundled(foo) tags )

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=ZNgmNZvNOVa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: [HEADS UP] I've just built Erlang R16A in Rawhide.

On Mon, Feb 04, 2013 at 12:29:04PM +0300, Peter Lemenkov wrote:
 Hello All!
 
 As a part of the planned Erlang upgrade to R16 I updated it to the
 recently released R16A (Release Candidate). I'm expecting a lot of
 breakage. Unfortunately all incompatibilities are hidden from end
 users, and some applications will install fine but refuse to start.
 Instead they will throw up unexpected (by end user, I'm aware of this
 issue) message to the console - Driver compiled with incorrect
 version of erl_driver.h. I'm working on tracking them down and
 rebuilding them. Also I plan to add another one constraint to these
 packages - a dependency on a Port protocol version (additional
 Requires:), so a major update will pull affected packages into
 Broken Dependencies list thus preventing from disruptive updates.
 
 Note - I won't plan to upgrade Fedora 17/18 to R16 to not to hurt our
 current users. Instead I encourage everyone who's interested in trying
 a very latest Erlang to upgrade to Rawhide/F19 asap.

Are any changes required to C erl_interface / ei.h users?  I mean
at the source level, not just recompiling.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names

2013-02-04 Thread Kay Sievers

On Thu, Jan 31, 2013 at 2:45 PM, Scott Schmit i.g...@comcast.net wrote:

 Current:
 em1 - enp2s0

That is expected, and actually the right thing to do. Udev cannot
apply such it looks like it is embedded heuristics for very
practical technical reasons. There is no reliable information about
that on the system, so this logic will break sooner or later.

There is also no sane way to share the namespace with the embedded
interface indices defined by the firmware. It should never have been
done by biosdevname that way.

 em2 - eno1
 em3 - eno2

Ouch, is that really the case? If that's what you see on your box,
then biosdevname would have invented its own numbers for the *fixed*
SMBIOS provided index numbers, and rebased them to something
different. That would be really weird.

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-02-04 Thread Stef Walter

On 02/04/2013 06:28 AM, Kevin Kofler wrote:
 M. Edward (Ed) Borasky wrote:
 I love GNOME 3 and detest KDE 4. I've tried MATE and Cinnamon on both
 Linux Mint and Fedora and don't really see the point of either of them
 as long as GNOME 3 offers fallback mode.
 
 Fallback mode is going away in F19, it's already gone upstream.

FWIW, see its replacement Classic Mode here:

http://blogs.gnome.org/mclasen/2013/01/25/gnome-3-7-at-the-halfway-mark/

Stef

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

[perl-Log-Dispatch/f18] Upstream update.

Summary of changes:

  f3bdf5f... 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-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File Regexp-Grammars-1.026.tar.gz uploaded to lookaside cache by wfp

A file has been added to the lookaside cache for perl-Regexp-Grammars:

6d75f337154bbbcd754e75ba7dd48bdd  Regexp-Grammars-1.026.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-02-04 Thread Ralf Corsepius


On 02/04/2013 02:42 PM, Jan Kratochvil wrote:

On Mon, 04 Feb 2013 14:16:58 +0100, Martin Sourada wrote:

Big +1. What will an unsuspecting user think when he downloads, burns
and tries Fedora on 32bit machine? That it's broken,


 From what I have reports even Fedora 32-bit does not boot on such machines
because nobody tests the bleeding edge Fedora kernels on such obsolete
hardware.


Could you provide more details? I have Fedora 18 running on several 
32bit machines and am wondering what you are referring to.


Ralf

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

Re: Proposed F19 Feature: Apache OpenOffice

2013-02-04 Thread James Hogarth

On 4 February 2013 12:39, Andrea Pescetti pesce...@apache.org wrote:

 Kevin Kofler wrote:

 * What benefit does this package have over LibreOffice, to justify
 carrying
2 packages doing essentially the same thing?


 They are indeed two productivity suites, but they are evolving in
 different directions. There's a Features link in the proposal
 https://fedoraproject.org/**wiki/Features/ApacheOpenOfficehttps://fedoraproject.org/wiki/Features/ApacheOpenOffice
 that lists unique features of OpenOffice 4.0, including the new user
 interface (sidebar), the new accessibility support (a key factor for
 adoption by institutions), interoperability enhancements and performance
 improvements. Again, the proposal is not saying or implying in any way
 which of the two is better, and this might vary by user, or even by single
 task.


When this hit the fedora-devel mailing list it actually spurred me to look
at the AOO mailing list and compare features between OO.org/AOO and LO...

The first problem here is that the rough target for release  as it has
been named is in April... the branch from rawhide is currently estimated to
be end of February - AOO isn't even packaged and in rawhide yet - forget
the main release - and for such a large package with the issues pointed out
about conflicting names in soffice, oocalc, oowriter and so on (which has a
knock on effect on LO packaging) is up for question - assuming AOO gets
packaged at all.

We all know how releases can get delayed as well and as this is the first
*major* release of AOO with the IBM Symphony code being merged in (with the
new look and so on) it would seem logical to have a higher chance of delay
or have a higher level of bugs or kinks to be worked out due to the
Symphony merge ongoing rather than the older (but stable) oo.org code/UI.

So it would seem advisable to take the 4.0 release out of scope and focus
on whether 3.4.1 (current) can be packaged given the issues already raised
and then look at 4.0 as and when AOO complete their work.

I followed the links from your fedora proposal page to look at features...

The release planning link for 4.0 has no details as to when a beta might
be available and everything is 'in progress' or 'proposed'  with not much
detail and fairly vague descriptions.

The 'code' link is to the branches directory of the openoffice code - but
it's not clear what you intend to build/package/release from that which is
perhaps not that surprising given that 4.0 doesn't even exist yet in alpha
much less beta state.

The 'document fidelity' and 'sidebar' links are for proposals/work for 4.0
and given the high likelihood of not making F19 (even the proposal page
acknowledges this and suggests falling back to the stable 3.4.1 code) I
submit should not be used in evaluating this proposal at this time... the
4.0 page doesn't even have any test details, and the release notes are very
empty:

Now taking the assumption of AOO 3.4 (which I b
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS UP] I've just built Erlang R16A in Rawhide.

2013-02-04 Thread Peter Lemenkov

2013/2/4 Richard W.M. Jones rjo...@redhat.com:

 Are any changes required to C erl_interface / ei.h users?  I mean
 at the source level, not just recompiling.

Nope, no changes are necessary.

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Regexp-Grammars/f18] Update to version 1.026

Summary of changes:

  5c4099c... Update to version 1.026 (*)

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

Re: Proposed F19 Feature: Apache OpenOffice

2013-02-04 Thread James Hogarth

Apologies for the accidental send before...

On 4 February 2013 12:39, Andrea Pescetti pesce...@apache.org wrote:

 Kevin Kofler wrote:

 * What benefit does this package have over LibreOffice, to justify
 carrying
2 packages doing essentially the same thing?


 They are indeed two productivity suites, but they are evolving in
 different directions. There's a Features link in the proposal
 https://fedoraproject.org/**wiki/Features/ApacheOpenOfficehttps://fedoraproject.org/wiki/Features/ApacheOpenOffice
 that lists unique features of OpenOffice 4.0, including the new user
 interface (sidebar), the new accessibility support (a key factor for
 adoption by institutions), interoperability enhancements and performance
 improvements. Again, the proposal is not saying or implying in any way
 which of the two is better, and this might vary by user, or even by single
 task.



When this hit the fedora-devel mailing list it actually spurred me to look
at the AOO mailing list and compare features between OO.org/AOO and LO...

The first problem here is that the rough target for release  as it has
been named is in April... the branch from rawhide is currently estimated to
be end of February - AOO isn't even packaged and in rawhide yet - forget
the main release - and for such a large package with the issues pointed out
about conflicting names in soffice, oocalc, oowriter and so on (which has a
knock on effect on LO packaging) is up for question - assuming AOO gets
packaged at all.

We all know how releases can get delayed as well and as this is the first
*major* release of AOO with the IBM Symphony code being merged in (with the
new look and so on) it would seem logical to have a higher chance of delay
or have a higher level of bugs or kinks to be worked out due to the
Symphony merge ongoing rather than the older (but stable) oo.org code/UI.

So it would seem advisable to take the 4.0 release out of scope and focus
on whether 3.4.1 (current) can be packaged given the issues already raised
and then look at 4.0 as and when AOO complete their work.

I followed the links from your fedora proposal page to look at features...

The release planning link for 4.0 has no details as to when a beta might be
available and everything is 'in progress' or 'proposed'  with not much
detail and fairly vague descriptions.

The 'code' link is to the branches directory of the openoffice code - but
it's not clear what you intend to build/package/release from that which is
perhaps not that surprising given that 4.0 doesn't even exist yet in alpha
much less beta state.

The 'document fidelity' and 'sidebar' links are for proposals/work for 4.0
and given the high likelihood of not making F19 (even the proposal page
acknowledges this and suggests falling back to the stable 3.4.1 code) I
submit should not be used in evaluating this proposal at this time... the
4.0 page doesn't even have any test details, and the release notes are very
empty:

https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes

Now taking the assumption of AOO 3.4 (which I believe is sane) what does
this bring over LO?

Reading the release notes of that release it looks like everything is in
either the current stable LO or the LO 4.0 release which is just about to
happen well ahead of a rawhide branch...

Might I suggest focusing on packaging 3.4.1 for rawhide and dealing with
the issues surrounding conflicts and if that gies well consider the 4.0
release (or whatever lines up then) for F20?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Dracut HostOnly

2013-02-04 Thread John Reiser

 = Features/DracutHostOnly =
 https://fedoraproject.org/wiki/Features/DracutHostOnly

 ... This results in a very big initramfs, which takes a long time to 
 load on system start and a long time to create on kernel updates.

For speed in creating an initramfs, please consider Requiring
the package 'pigz' (Parallel Implementation of GZip), or at least highlight
this feature in the documentation.  If pigz is present in $PATH,
then already today dracut uses it, and this speeds up the compression
by a factor equal to the number of CPUs.  On my 3GHz box with 2 CPUs
the gzip time is about 20 seconds, but using pigz takes only 10 seconds.

-- 

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

[perl-Regexp-Grammars/f17] Update to version 1.026

Summary of changes:

  5c4099c... Update to version 1.026 (*)

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

[Bug 907124] perl-Regexp-Grammars-1.026 is available

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

--- Comment #1 from Fedora Update System upda...@fedoraproject.org ---
perl-Regexp-Grammars-1.026-1.fc18 has been submitted as an update for Fedora
18.
https://admin.fedoraproject.org/updates/perl-Regexp-Grammars-1.026-1.fc18

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=cKhDlDAZFXa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Test-Announce] 2013-02-04 @ 16:00 UTC - Fedora QA Meeting

# Fedora Quality Assurance Meeting
# Date: 2013-02-04
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

It's meeting time again tomorrow. This week we'll be covering stuff we
didn't get around to last week, mostly.

This is a reminder of the upcoming QA meeting. Please add any topic
suggestions to the meeting wiki page:
https://fedoraproject.org/wiki/QA/Meetings/20130204

The current proposed agenda is included below.

== Proposed Agenda Topics ==
1. Criteria Revision
2. Test Case Revision 
3. Fedora 19 Feature list review
4. Open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 907124] perl-Regexp-Grammars-1.026 is available

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

--- Comment #2 from Fedora Update System upda...@fedoraproject.org ---
perl-Regexp-Grammars-1.026-1.fc17 has been submitted as an update for Fedora
17.
https://admin.fedoraproject.org/updates/perl-Regexp-Grammars-1.026-1.fc17

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=YYNW0ZCzTJa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Regexp-Grammars/el6] Update to version 1.026

Summary of changes:

  5c4099c... Update to version 1.026 (*)

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

File Text-vFile-asData-0.08.tar.gz uploaded to lookaside cache by corsepiu

A file has been added to the lookaside cache for perl-Text-vFile-asData:

39fad8c1ca12d44a1bde955f74b3d470  Text-vFile-asData-0.08.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-Text-vFile-asData] Upstream update.

commit d224f0dc1f3216ee2b83d20a61b249750e61e480
Author: Ralf Corsépius corse...@fedoraproject.org
Date:   Mon Feb 4 16:06:19 2013 +0100

Upstream update.

- Modernize spec.
- Drop obsoletes/provides %{name}-utils.

 .gitignore  |2 +-
 perl-Text-vFile-asData.spec |   19 +++
 sources |2 +-
 3 files changed, 9 insertions(+), 14 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 644251e..5f822df 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-Text-vFile-asData-0.07.tar.gz
+/Text-vFile-asData-0.08.tar.gz
diff --git a/perl-Text-vFile-asData.spec b/perl-Text-vFile-asData.spec
index 3cd1b13..9897c45 100644
--- a/perl-Text-vFile-asData.spec
+++ b/perl-Text-vFile-asData.spec
@@ -1,21 +1,16 @@
 Name:   perl-Text-vFile-asData
-Version:0.07
-Release:8%{?dist}
+Version:0.08
+Release:1%{?dist}
 Summary:Parse vFile formatted files into data structures
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Text-vFile-asData/
 Source0:
http://www.cpan.org/authors/id/R/RC/RCLAMP/Text-vFile-asData-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
 BuildRequires:  perl(Class::Accessor::Chained)
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(Test::More)
 
-# To be dropped in Fedora 16
-Obsoletes:  %{name}-utils  %{version}-%{release}
-Provides:   %{name}-utils = %{version}-%{release}
-
 # for improved tests
 BuildRequires:  perl(Test::Pod) = 1.00
 
@@ -35,8 +30,6 @@ vCalendar (RFC 2445).
 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 -depth -type d -exec rmdir {} 2/dev/null \;
@@ -46,9 +39,6 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2/dev/null \;
 %check
 make test
 
-%clean
-rm -rf $RPM_BUILD_ROOT
-
 %files
 %defattr(-,root,root,-)
 %doc Changes
@@ -56,6 +46,11 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Mon Feb 04 2013 Ralf Corsépius corse...@fedoraproject.org - 0.08-1
+- Upstream update.
+- Modernize spec.
+- Drop obsoletes/provides %%{name}-utils.
+
 * Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.07-8
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
 
diff --git a/sources b/sources
index e1eaf96..39557e0 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1f0fc1fbef2111a936db3eb4678ddccc  Text-vFile-asData-0.07.tar.gz
+39fad8c1ca12d44a1bde955f74b3d470  Text-vFile-asData-0.08.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Proposed F19 Feature: Dracut HostOnly

2013-02-04 Thread Reindl Harald



Am 04.02.2013 15:47, schrieb John Reiser:
 = Features/DracutHostOnly =
 https://fedoraproject.org/wiki/Features/DracutHostOnly
 
 ... This results in a very big initramfs, which takes a long time to 
 load on system start and a long time to create on kernel updates.
 
 For speed in creating an initramfs, please consider Requiring
 the package 'pigz' (Parallel Implementation of GZip), or at least highlight
 this feature in the documentation.  If pigz is present in $PATH,
 then already today dracut uses it, and this speeds up the compression
 by a factor equal to the number of CPUs.  On my 3GHz box with 2 CPUs
 the gzip time is about 20 seconds, but using pigz takes only 10 seconds

thanks for that

below the output of a HostOnly one before
and after yum install pigz and so i take
this package in my base-metapackage

[root@rh:~]$ date; dracut -f; date
Mo 4. Feb 15:47:50 CET 2013
Mo 4. Feb 15:48:02 CET 2013

[root@rh:~]$ date; dracut -f; date
Mo 4. Feb 15:48:31 CET 2013
Mo 4. Feb 15:48:36 CET 2013




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

Re: Mass changing 500 packages BR:maven to BR:maven-local - TOMORROW(ish)

2013-02-04 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon 04 Feb 2013 04:56:23 AM EST, Stanislav Ochotnicky wrote:
 Now that I have your attention...

 Fedora Maven package is currently a mix of upstream release and our changes 
 that
 we need for building RPMs. We can clean it up, but we need to move packages 
 from
 BR: maven to BR:maven-local. That will enable users to install Maven package
 without installing a lot of other stuff they don't necessarily need.

 This change will not affect buildroots because maven-local pulls in maven
 package.

 The only issue is: there's mass rebuild scheduled for 8.2. I would like to
 rebuild Maven packages before that. We have a modified mass-rebuild script 
 that
 can do the change of maven - maven-local automatically. Strictly speaking 
 this
 change is also breaking current Java guidelines, but I believe for the better
 (change proposal should be up today/tomorrow, with SIG meeting following).

 I am looking for a blessing from a community to do this change
 tomorrow/Wednesday so that F19 is even more awesome :-) Is there anyone who
 feels strongly against this change? I realize this is very short-notice, but
 I believe disruption this change will cause is nil.


If this change is in violation of policy, PLEASE refrain from
performing it until such time as the FPC reviews the proposed changes.
Also, if this is going to impact a large number of packages, it should
either be coordinated with the existing mass-rebuild plan or else
performed in a private branch and then merged in. If something goes
wrong with your mass-rebuild, it will be difficult to address in
Rawhide with some packages updated and some not.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEP0y8ACgkQeiVVYja6o6N/QgCgqV/MUC8rHH/orUP/9mX7ZVvN
hiIAnjWLiX8fqakYTELuzfFy5bVsH933
=SC/v
-END PGP SIGNATURE-

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

Re: polkit changes in f19

2013-02-04 Thread Florian Weimer


On 02/04/2013 08:52 AM, Kevin Kofler wrote:

Matthias Clasen wrote:

I just realized that there is a change to the way polkit is packaged in
f19 that spin maintainers should be aware of: the polkit package is just
the service, which only provides the default policy as specified in the
action definitions now. If you want or need support for js rules, you need
to pull in the polkit-js-engine package. I've just made this change for
the desktop spin.


I added the dependency to kde-settings, which ships a .rules file.


Are packages really expected to ship .rules files?  I don't think so:

Authorization rules are intended for two specific audiences

System Administrators

Special-purpose Operating Systems / Environments

and those audiences only. In particular, applications, mechanisms and 
general-purpose operating systems must never include any authorization 
rules.


http://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html

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

Re: polkit changes in f19

2013-02-04 Thread Matthew Miller

On Mon, Feb 04, 2013 at 04:31:10PM +0100, Florian Weimer wrote:
 Are packages really expected to ship .rules files?  I don't think so:

Right, as I understand it, with the new system, applications are never ever
supposed to ship such rules files.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-02-04 Thread Jan Kratochvil

On Mon, 04 Feb 2013 15:23:45 +0100, Ralf Corsepius wrote:
 On 02/04/2013 02:42 PM, Jan Kratochvil wrote:
  From what I have reports even Fedora 32-bit does not boot on such machines
 because nobody tests the bleeding edge Fedora kernels on such obsolete
 hardware.
 
 Could you provide more details?

Unfortunately I cannot, I said reports. A friend of mine has various old
machines and this is what he reported.  (I have one 32-bit machine and Fedoras
work there.)

Still I believe it is probably true as I doubt Fedora QA tests compatibility
with old hosts.


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

Re: rawhide report: 20130203 changes

2013-02-04 Thread Jerry James

On Sun, Feb 3, 2013 at 1:03 PM, Kevin Fenzi ke...@scrye.com wrote:
 Rebuilt by me:

 4ti2

Actually, 4ti2 has been obsoleted by latte-integrale.  I've reminded
the maintainer that he needs to retire this package.
--
Jerry James
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Text-vFile-asData/f17] (4 commits) ...Merge cleanup.

Summary of changes:

  1d5afe2... Perl 5.16 rebuild (*)
  565c469... - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass (*)
  d224f0d... Upstream update. (*)
  847d97c... Merge cleanup.

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

[perl-Text-vFile-asData/f17: 4/4] Merge cleanup.

commit 847d97c16d16fee47da03deef3335132fca001c3
Author: Ralf Corsépius corse...@fedoraproject.org
Date:   Mon Feb 4 16:13:14 2013 +0100

Merge cleanup.

 perl-Text-vFile-asData.spec |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)
---
diff --git a/perl-Text-vFile-asData.spec b/perl-Text-vFile-asData.spec
index 9897c45..5d41676 100644
--- a/perl-Text-vFile-asData.spec
+++ b/perl-Text-vFile-asData.spec
@@ -51,12 +51,6 @@ make test
 - Modernize spec.
 - Drop obsoletes/provides %%{name}-utils.
 
-* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.07-8
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
-
-* Tue Jun 12 2012 Petr Pisar ppi...@redhat.com - 0.07-7
-- Perl 5.16 rebuild
-
 * Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.07-6
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Proposed F19 Feature: Dracut HostOnly

2013-02-04 Thread Martin Langhoff

On Tue, Jan 29, 2013 at 6:22 PM, Dennis Gilmore den...@ausil.us wrote:
 that are built at kernel build time? the issue with building it at
 build time was making sure we knew exactly what sourcs we needed to
 ship to match all the binaries in the initramfs. the initramfs's we
 build and ship as part of teh install tree we know exactly what sources
 because they match what is in the release tree rather than what was in
 the buildroot at build time.

That _is_ a missing piece of the dracut/initramfs toolchain: we need
something in dracut that scans what files have been included from the
buildhost, finds what rpm they belong to and writes down the NEVRA
into a file that goes _into_ the initramfs.

Right now, it is impossible to trace back the origin of an arbitrary
initramfs built by dracut. Unless you find the build host (and it
hasn't changed!).

At OLPC we've had a few incidents of where the hell did you build
this initramfs? and how can I respin this initramfs with only this
patch applied, no other changes whatsoever?.

cheers,


m
--
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: glpk soname bump expected?

2013-02-04 Thread Orion Poplawski


On 02/03/2013 03:47 AM, Michael Schwendt wrote:

On Sat, 02 Feb 2013 19:54:23 -0700, Orion Poplawski wrote:


Looks like going from glpk 4.47 to 4.48 bumped the soname from
libglpk.so.0 to libglpk.so.33.  Something tells me this was not expected
and is not correct.  Can this be verified?



Could be an accident in the upstream tarball indeed, because I only
checked that it's not a package where the spec file messes with the
soname and the library links.

rpmsodiff and rpmsoname are helpful for library maintainers!


http://koji.fedoraproject.org/koji/rpminfo?rpmID=3671777

/usr/lib64/libglpk.so   17
/usr/lib64/libglpk.so.3317
/usr/lib64/libglpk.so.33.0.0978392


http://koji.fedoraproject.org/koji/rpminfo?rpmID=3220245

/usr/lib64/libglpk.so   17
/usr/lib64/libglpk.so.0 17
/usr/lib64/libglpk.so.0.32.0962056



Hmm, that makes it seem even more likely that upstream fat-fingered something.

Although: http://upstream-tracker.org/versions/glpk.html
does indicate that ABI has been broken (although it has been done so in the 
past without bumping the soname).



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

Re: glpk soname bump expected?

2013-02-04 Thread Jerry James

On Mon, Feb 4, 2013 at 9:07 AM, Orion Poplawski or...@cora.nwra.com wrote:
 Hmm, that makes it seem even more likely that upstream fat-fingered
 something.

 Although: http://upstream-tracker.org/versions/glpk.html
 does indicate that ABI has been broken (although it has been done so in the
 past without bumping the soname).

Looks like this has been brought up on an upstream mailing list:

http://lists.gnu.org/archive/html/help-glpk/2013-01/msg00081.html
--
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Strange yum update hang (or something else) in Rawhide .. how to debug this further?


  Cleanup: cpp-4.8.0-0.7.fc19.x86_64215/262 
  Cleanup: gdb-7.5.50.20130118-2.fc19.x86_64216/262 
  Cleanup: 1:findutils-4.5.10-7.fc19.x86_64 217/262 
  Cleanup: spice-server-0.12.2-2.fc19.x86_64218/262 
  Cleanup: cracklib-2.8.22-2.fc19.x86_64219/262 
  Cleanup: libvirt-daemon-driver-interface-1.0.1-6.fc19.x86_64  220/262 
  Cleanup: libvirt-daemon-driver-nodedev-1.0.1-6.fc19.x86_64221/262 
  Cleanup: libvirt-daemon-driver-nwfilter-1.0.1-6.fc19.x86_64   222/262 
  Cleanup: libvirt-daemon-driver-secret-1.0.1-6.fc19.x86_64 223/262 
  Cleanup: libvirt-daemon-1.0.1-6.fc19.x86_64   224/262 
  Cleanup: libvirt-client-1.0.1-6.fc19.x86_64   225/262 
  Cleanup: cyrus-sasl-2.1.25-2.fc19.x86_64  226/262 
  Cleanup: openldap-2.4.33-3.fc19.x86_64227/262 
  Cleanup: nss-tools-3.14.1-3.fc19.x86_64   228/262 
  Cleanup: nss-sysinit-3.14.1-3.fc19.x86_64 229/262 
  Cleanup: nss-3.14.1-3.fc19.x86_64 230/262 
(and here it hangs, for at least 20 minutes)

There's nothing obviously going on inside the virtual machine.  Load
average is 0.00.  The VM is still perfectly responsive, plenty of
free memory and so on.

It appears as if it's yum itself which is stuck:

 4223 ?Ss 0:00  \_ sshd: rjones [priv] 
 4226 ?S  0:09  \_ sshd: rjones@pts/1  
 4227 pts/1Ss 0:00  \_ -bash
13396 pts/1S+ 0:00  \_ sudo yum update
13397 pts/1Sl+1:01  \_ /usr/bin/python /bin/yum update

Yum is blocked on a futex:

$ sudo strace -p 13397
Process 13397 attached
futex(0x7f908292fc0c, FUTEX_WAIT, 1, NULL

Is there a way I can see what (if anything) is holding on to this
mutex?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Strange yum update hang (or something else) in Rawhide .. how to debug this further?

On Mon, Feb 04, 2013 at 04:38:08PM +, Richard W.M. Jones wrote:
 Yum is blocked on a futex:

I should add:

yum-3.4.3-57.fc19.noarch

Rawhide 64 bit, almost(!) up to date.

It looks as if rpm-libs was also updated moments earlier to
4.11.0-0.beta1.3.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-02-04 Thread Kévin Raymond

Le lundi 04 févr. 2013 à 14:42:35 (+0100), Jan Kratochvil a écrit : 
 On Mon, 04 Feb 2013 14:16:58 +0100, Martin Sourada wrote:
  Big +1. What will an unsuspecting user think when he downloads, burns
  and tries Fedora on 32bit machine? That it's broken,
 
 From what I have reports even Fedora 32-bit does not boot on such machines
 because nobody tests the bleeding edge Fedora kernels on such obsolete
 hardware.

Hi guys,
I think you are completely off-topic here. You are discussing about the
fedoraproject.org website design, with devels about the Cinnamon Feature
proposal...

This is a decent discussion that should appear on the websites mailing list. But
I agree, we won't ask everyone to register on every mailing list... Hyperkitty,
where are you? :)

So let's try to resolve that here. (moreover we want to refresh the websites).
First of all, we updated a lot the get-fedora-options[1] page, which is clearer
and includes more choices now. It's not perfect. Nothing is perfect. But
improving is the way to go.

The get-fedora default download page[2] is linked from the main page, on the
first slide when you ask to learn more. The download button there gives you
directly the iso.

From the main page, on the righ side, you have the full set of downdoal
options who direct users to [1], the page that you guys prefer I think.
Yes, the Fedora banner on the right side (and from every websites including the
banner) link to the get-fedora[2] page. This was done that way to help people
getting Fedora right now, without having to choose between so many options.
People knowing options will look for them and find the right page. Which is
linked 6 times from there.

The page that I don't really find usefull is get-fedora-all[3]. It could be
included on the other ones. But guys like it. We already spoke about this with
Sijis.
But new input is welcome.

If you guys can come up with a clear and brillant proposal, we would be happy to
read it and apply it if better.

The idea is to only propose ISO that has QA, which are defined as possible
blockers from the main websites. spins.fpo of course show links to all available
spins.
That is not perfect. But we don't want to give too many choices to the users, we
want to be consistent between releases, and the new websites design was clearly
defined for the end user, and not for deep programmers. (That look for the alt
nightly ISOs).

For the 32Vs64 bits ISOs, we moved by default to 64 bits for F17 (as approved by
FESCo) because Fedora is a leading edge GNU/Linux distribution, we don't have
LTS and don't want to mainain software for the whole informatic history.
Mostly all Intel CPUs now are 64 bits. If the ISO does not boot, guys will have
to ask or read for help, and we provid(ed?) docs about how to check the CPU
arch. Regarding the doc, the were updating it with regards to UEFI. Not sure if
it is in prod, I have to check.

As requested, we removed the most compatible label for the 32bits, is this ISO
was not booting under UEFI.

What we should really add, is a nice page helping people to install (change) a
new DE after the default Fedora install. They should not really care about which
iso to download. If they have a good internet connexion, they should be able to
easily change their DE. Or install yum groups. In an other way, we should
provide a nice page to get the spin once they have installed Fedora. Or write
a simple app for that..?
Oh also, we try to feature a new spin everytime on the main slideshow. But we
can't print them all..

Any help appreciated of course.

[1] http://fedoraproject.org/en/get-fedora-options
[2] http://fedoraproject.org/get-fedora
[3] http://fedoraproject.org/en/get-fedora-all

-- 
Kévin Raymond
(Shaiton)


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

[389-devel] Regarding changing instance specific scripts to be global/generic

2013-02-04 Thread Mark Reynolds

There has been a request to remove instance specific scripts, and make 
them generic and placed in /usr/sbin/


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


Should we remove all the scripts from /usr/lib64/dirsrv/slapd-INSTANCE:

bak2db  db2index dn2rdnldif2ldap
ns-newpwpolicy.pl  start-slapd usn-tombstone-cleanup.pl
bak2db.pl   db2index.pl  fixup-linkedattrs.pl  monitor  
restart-slapd  stop-slapd  verify-db.pl
cleanallruv.pl  db2ldif  fixup-memberof.pl ns-accountstatus.pl  
restoreconfig  suffix2instance vlvindex
db2bak  db2ldif.pl   ldif2db   ns-activate.pl   
saveconfig syntax-validate.pl
db2bak.pl   dbverify ldif2db.plns-inactivate.pl 
schema-reload.pl   upgradednformat


It appears almost of these are all instance specific.  Do we want to 
make all of these generic and stick them in /usr/sbin?


However, I think it makes sense to keep some instance specific scripts: 
monitor, stop/start/restart, maybe the task scripts too (like schema 
reload, cleanallruv, fix-memberof, etc).  Then only make the database 
scripts generic: db2ldif db2index, ldif2db, db2bak, bak2db, etc.


Just curious what everyone thinks about this.

Thanks,
Mark

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

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

Re: Strange yum update hang (or something else) in Rawhide .. how to debug this further?

On Mon, Feb 04, 2013 at 04:41:25PM +, Richard W.M. Jones wrote:
 It looks as if rpm-libs was also updated moments earlier to
 4.11.0-0.beta1.3.

Correction: RPM was just updated from 4.11.0-0.beta1.3 to 4.11.0.1-1.

It was beta1.2 which was the dodgy version, but I didn't have
that installed at any point.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 907464] cpanm bundle lots of library and is not listed on fesco page

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

Michael Scherer m...@zarb.org changed:

   What|Removed |Added

 Status|CLOSED  |ASSIGNED
 Resolution|NOTABUG |---
   Keywords||Reopened

--- Comment #2 from Michael Scherer m...@zarb.org ---
Yes, I have read the source code, and I am aware of the reason on why cpanm do
it ( hence the While the way cpanm work kinda mandate it part in my first
comment ).

But as I said, I think this should be tracked somewhere. I have seen how the
code is bundled and I know this would be quite hard to unbundle, but I am not
FPC, so in the end, it is up to them to decide, not to me, hence the request to
see with them. If I was the one to decide, I would grant a exception, provided
we can find what is bundled, so if any security issue arise, we can quickly see
this should be fixed in cpanm too.

For example there is a bundle of JSON::PP or HTTP::Tiny, and I picking these 2
because they are either consuming untrusted input or network stuff, so could in
theory be problematic. 

And in all case, the packaging guidelines are quite clear on what to do if
there if there is a bundle :
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Requirement_if_you_bundle

This include adding a link to the ticket for the exception. And while the
ticket look like bureaucracy ( since I think the exception would be granted ),
I think only FPC can edit the wiki page with bundled exceptions list, and that
would be used as a reference source, and so must be up to date.

The fact that only part of the code is copied doesn't make it less a
problematic copy from a tracking point of view.

So yes, i think something should be done, and the current process and
documentation requires some group to do it, and that's FPC as you correctly
said.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=tq7AaveoREa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-02-04 Thread Kévin Raymond

  From what I have reports even Fedora 32-bit does not boot on such machines
 because nobody tests the bleeding edge Fedora kernels on such obsolete
 hardware.
 
 Could you provide more details? I have Fedora 18 running on several
 32bit machines and am wondering what you are referring to.

From releng, I got the confirmation that some new computers does boot only UEFI
OS by default. And we don't provide UEFI on the 32bit ISO. Therefor, it is not
compatible.

Comes from the following report:
https://fedorahosted.org/fedora-websites/ticket/176


-- 
Kévin Raymond
(Shaiton)


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

Re: Strange yum update hang (or something else) in Rawhide .. how to debug this further?

On Mon, Feb 04, 2013 at 04:38:08PM +, Richard W.M. Jones wrote:
 
   Cleanup: cpp-4.8.0-0.7.fc19.x86_64
 215/262 
   Cleanup: gdb-7.5.50.20130118-2.fc19.x86_64
 216/262 
   Cleanup: 1:findutils-4.5.10-7.fc19.x86_64 
 217/262 
   Cleanup: spice-server-0.12.2-2.fc19.x86_64
 218/262 
   Cleanup: cracklib-2.8.22-2.fc19.x86_64
 219/262 
   Cleanup: libvirt-daemon-driver-interface-1.0.1-6.fc19.x86_64  
 220/262 
   Cleanup: libvirt-daemon-driver-nodedev-1.0.1-6.fc19.x86_64
 221/262 
   Cleanup: libvirt-daemon-driver-nwfilter-1.0.1-6.fc19.x86_64   
 222/262 
   Cleanup: libvirt-daemon-driver-secret-1.0.1-6.fc19.x86_64 
 223/262 
   Cleanup: libvirt-daemon-1.0.1-6.fc19.x86_64   
 224/262 
   Cleanup: libvirt-client-1.0.1-6.fc19.x86_64   
 225/262 
   Cleanup: cyrus-sasl-2.1.25-2.fc19.x86_64  
 226/262 
   Cleanup: openldap-2.4.33-3.fc19.x86_64
 227/262 
   Cleanup: nss-tools-3.14.1-3.fc19.x86_64   
 228/262 
   Cleanup: nss-sysinit-3.14.1-3.fc19.x86_64 
 229/262 
   Cleanup: nss-3.14.1-3.fc19.x86_64 
 230/262 
 (and here it hangs, for at least 20 minutes)

So how odd is this?  Suddenly it leaps back into life, after maybe
30-40 minutes.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Fedora Upgrade - using yum

2013-02-04 Thread Miroslav Suchý


On 01/29/2013 12:59 AM, Adam Williamson wrote:

Well, the other thing fedup does - and the other reason it's necessary
compared to a simple online yum upgrade - is provide a mechanism for
pretty much any package to hook in pretty much any action to be
performed as part of the upgrade. To be sure of what's going to happen
during a given fedup transaction, you should also check what scripts are
going to get fired as part of the upgrade. In F18 I'm not sure there are
any, but this is the kind of mechanism we would use, fr'instance, to
switch the default bootloader as part of an upgrade in future, if we
decided we wanted to do that again. The kind of stuff that can't be done
in %pre/%post etc.


Is this documented somewhere? I would like to read more about this feature.

--
Miroslav Suchy
Red Hat Systems Management Engineering
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Strange yum update hang (or something else) in Rawhide .. how to debug this further?

2013-02-04 Thread Panu Matilainen


On 02/04/2013 07:01 PM, Richard W.M. Jones wrote:

On Mon, Feb 04, 2013 at 04:38:08PM +, Richard W.M. Jones wrote:


   Cleanup: cpp-4.8.0-0.7.fc19.x86_64215/262
   Cleanup: gdb-7.5.50.20130118-2.fc19.x86_64216/262
   Cleanup: 1:findutils-4.5.10-7.fc19.x86_64 217/262
   Cleanup: spice-server-0.12.2-2.fc19.x86_64218/262
   Cleanup: cracklib-2.8.22-2.fc19.x86_64219/262
   Cleanup: libvirt-daemon-driver-interface-1.0.1-6.fc19.x86_64  220/262
   Cleanup: libvirt-daemon-driver-nodedev-1.0.1-6.fc19.x86_64221/262
   Cleanup: libvirt-daemon-driver-nwfilter-1.0.1-6.fc19.x86_64   222/262
   Cleanup: libvirt-daemon-driver-secret-1.0.1-6.fc19.x86_64 223/262
   Cleanup: libvirt-daemon-1.0.1-6.fc19.x86_64   224/262
   Cleanup: libvirt-client-1.0.1-6.fc19.x86_64   225/262
   Cleanup: cyrus-sasl-2.1.25-2.fc19.x86_64  226/262
   Cleanup: openldap-2.4.33-3.fc19.x86_64227/262
   Cleanup: nss-tools-3.14.1-3.fc19.x86_64   228/262
   Cleanup: nss-sysinit-3.14.1-3.fc19.x86_64 229/262
   Cleanup: nss-3.14.1-3.fc19.x86_64 230/262
(and here it hangs, for at least 20 minutes)


So how odd is this?  Suddenly it leaps back into life, after maybe
30-40 minutes.


Sounds like https://bugzilla.redhat.com/show_bug.cgi?id=860500

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

Re: Proposed F19 Feature: Replace MySQL with MariaDB

2013-02-04 Thread Henrique Junior

It looks like openSUSE is providing both, MariaDB and MySQL, with MariaDB
as a default[1].

[1] - http://michal.hrusecky.net/2013/01/mysql-mariadb-and-opensuse-12-3/


2013/2/4 Honza Horak hho...@redhat.com

 On 02/03/2013 06:24 PM, Pavel Alexeev wrote:

 01.02.2013 00:42, James Hogarth wrote:

 I'd still say yes since the context of this discussion is mysql 5.5 to
 mariadb 5.5 and nothing to do with mysql 5.6 and the time for mariadb
 10/11 to become fully compatible to what's brought to the table in
 that which was the relevant discussion in those blog posts...

 And if someone is using upstream themselves they are responsible to
 manage that ... and assuming the versioned obsoletes is used as
 discussed yesterday then there would be no accidental overwrite and
 compatibility if mysql-5.6 is on the system and the admin updated
 without thinking...

 Is it really hard maintain both? May be it have worth also package and
 support Percona with XtraDB?


 The question of maintaining both will be probably re-evaluate in the
 future again, there may be some new opinions for any way.

 Speaking about XtraDB -- MariaDB includes this engine so feel free to test
 it.


 Honza

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




-- 
Henrique LonelySpooky Junior
http://about.me/henriquejunior
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Strange yum update hang (or something else) in Rawhide .. how to debug this further?

2013-02-04 Thread Kevin Fenzi

I've not run into this on my rawhide laptop or rawhide vm today... 

Perhaps some kind of race condition there?

kevin


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

Re: Proposed F19 Feature: Virtio RNG

2013-02-04 Thread Cole Robinson

amit's response:

On (Sun) 03 Feb 2013 [10:30:49], Cole Robinson wrote:
 On 02/01/2013 04:39 PM, Bill Nottingham wrote:
 Jaroslav Reznik (jrez...@redhat.com) said:
 Feature owner(s): Cole Robinson crobi...@redhat.com, Amit Shah
 amit.s...@redhat.com

 Provide a paravirtual random number generator to virtual machines, to 
 prevent
 entropy starvation in guests.

 == Detailed description ==
 The linux kernel collects entropy from various non-deterministic hardware
 events, like mouse and keyboard input, and network traffic. This entropy
is then
 exposed through /dev/random, commonly used by cryptographic applications 
 that
 need true randomness to maintain security. However if more entropy is being
 consumed than is being produced, we have entropy starvation: reading from
 /dev/random will block, which can cause a denial of service. A common 
 example
 here is use of /dev/random by SSL in various services.

 VirtIO RNG (random number generator) is a paravirtualized device that is
 exposed as a hardware RNG device to the guest. Virtio RNG just appears as a
 regular hardware RNG to the guest, which the kernel reads from to fill its
 entropy pool. This effectively allows a host to inject entropy into a
guest via
 several means: The default mode uses the host's /dev/random, but a
physical HW
 RNG device or EGD (Entropy Gathering Daemon) source can also be used.


 Amit can give more authoritative answers, but here's my understanding:

 What exactly feeds /dev/random in the guest in the cases where this doesn't
 exist,

 Same things that feed entropy on a physical machine: VM keyboard + mouse
 movement, VM hardware events, etc. The entropy starvation risk isn't much
 different for a headless server VM than for a headless server physical
 machine, AIUI.

That's right.

 and how do we cope with this obviously making /dev/random exhaustion
 in the host much more likely? (Other than assume that a HW RNG is in the
 host.)

1. The host has more sources of entropy than a single guest -- it has
   more network and disk activity going on due to all the guests,
   contributing to the host's entropy pool

2. qemu has an option to rate-limit the amount of data sent to a
   single guest, so any one guest won't starve other guests as well as
   the host of entropy.

However, having only one physical hwrng in the host scales much better
than having one for each VM, so it's expected server admins will have
one hwrng.  Newer Intel processors have the RDRAND instruction, which
is an endless supply of entropy as well.

 The default mode of pulling from host /dev/random certainly does not scale
 unless there's something feeding your host's entropy pool. And this won't be
 enabled by default, just new opt in functionality. I think anyone with a
 non-trivial setup and need for more entropy in their guests will use this to
 share a single hwrng or a more involved setup with EGD.

I sure hope virtio-rng is made a default device -- always having high-quality
entropy when randomness is needed is always preferable.  Not now,
though -- maybe in a couple of releases (when we have the RDRAND
backend in qemu, and the new Intel CPUs are readily available).

 Peter Krempa, who is implementing the libvirt side of things, had some ideas
 about a virt entropy daemon that could do more advanced rate limiting to stave
 off entropy exhaustion across hosts/guests:

 https://www.redhat.com/archives/libvir-list/2012-December/msg00937.html

The qemu feature page has info on qemu's options for rate-limiting.
However, qemu doesn't have knowledge of the entire host -- how many
guests exist, how many guests are asking for entropy, and at what
rate, etc.  libvirt has that info, and can provide a fair sharing of
the host's entropy among all the guests and the host itself.

 Given FIPS paranoia about RNG sources, does this have knock-on effects in
 the FIPS compliance of guests depending on how it's fed in the host?

 No clue about that, I've added that to the comments section of the feature 
 page.

Studies show even feeding host's /dev/urandom to guests is sufficient
and even if the host doesn't receive fresh entropy for several years,
all the guests and the host will be fine.  However, /dev/urandom is a
very poor source of entropy to feed into guests (it's a PRNG, not a
DRNG that a guest's hwrng input expects), so we never use the host's
/dev/urandom to send data to the guest.  Using host's /dev/random is
much better, but using a real hwrng or RDRAND on the host are the
optimal solutions.  The choice of input sources to feed in to the
guest rests on the admin, but the default of /dev/random is not going
to invalidate any certification.

Additionally, if a guest is rate-limited for entropy for some reason,
like starving the host itself, it won't be much worse-off than without
the virtio-rng.  So only the source of the entropy is a concern for
certification, and from what I know, we're fine with the defaults that
qemu provides.

Amit


--

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-02-04 Thread Ralf Corsepius


On 02/04/2013 05:47 PM, Kévin Raymond wrote:

 From what I have reports even Fedora 32-bit does not boot on such machines
because nobody tests the bleeding edge Fedora kernels on such obsolete
hardware.


Could you provide more details? I have Fedora 18 running on several
32bit machines and am wondering what you are referring to.


 From releng, I got the confirmation that some new computers does boot only UEFI
OS by default. And we don't provide UEFI on the 32bit ISO. Therefor, it is not
compatible.

Ah, OK - My 32bit machines all predate UEFI ;)

[2 ca. 4 year old, still-inuse Atom-N270 netbooks and a 10years+ old 
PIII, which serves as testing machine ;)]


Ralf


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

[perl-Pod-Parser] Sub-package Pod-Usage

2013-02-04 Thread Petr Pisar

commit 4218ec632154822d30632f9620f3b707492e2ab2
Author: Petr Písař ppi...@redhat.com
Date:   Mon Feb 4 17:11:56 2013 +0100

Sub-package Pod-Usage

 perl-Pod-Parser.spec |   42 +-
 1 files changed, 37 insertions(+), 5 deletions(-)
---
diff --git a/perl-Pod-Parser.spec b/perl-Pod-Parser.spec
index 134cc40..fe9c0d8 100644
--- a/perl-Pod-Parser.spec
+++ b/perl-Pod-Parser.spec
@@ -1,6 +1,6 @@
 Name:   perl-Pod-Parser
 Version:1.51
-Release:247%{?dist}
+Release:248%{?dist}
 Summary:Basic perl modules for handling Plain Old Documentation (POD)
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -13,13 +13,9 @@ BuildRequires:  perl(Carp)
 BuildRequires:  perl(Cwd)
 BuildRequires:  perl(Exporter)
 BuildRequires:  perl(File::Spec)
-# Pod::Usage execute perldoc from perl-Pod-Perldoc by default
-BuildRequires:  perl-Pod-Perldoc
 # Tests:
 BuildRequires:  perl(Test::More) = 0.6
 Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-# Pod::Usage execute perldoc from perl-Pod-Perldoc by default
-Requires:   perl-Pod-Perldoc
 
 # Filter under-specified depenedencies
 %global __requires_exclude 
%{?__requires_exclude|%__requires_exclude|}^perl\\(Pod::Parser\\)$
@@ -29,6 +25,27 @@ This software distribution contains the packages for using 
Perl5 POD (Plain
 Old Documentation). See the perlpod and perlsyn manual pages from your
 Perl5 distribution for more information about POD.
 
+%package -n perl-Pod-Usage
+Summary:Print a usage message from embedded pod documentation
+License:GPL+ or Artistic
+Group:  Development/Libraries
+# Pod::Usage execute perldoc from perl-Pod-Perldoc by default
+BuildRequires:  perl-Pod-Perldoc
+Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+# Pod::Usage executes perldoc from perl-Pod-Perldoc by default
+Requires:   perl-Pod-Perldoc
+Requires:   perl(Pod::Text)
+Conflicts:  perl-Pod-Parser  1.51-248
+
+%description -n perl-Pod-Usage
+pod2usage will print a usage message for the invoking script (using its
+embedded POD documentation) and then exit the script with the desired exit
+status. The usage message printed may have any one of three levels of
+verboseness: If the verbose level is 0, then only a synopsis is printed.
+If the verbose level is 1, then the synopsis is printed along with a
+description (if present) of the command line options and arguments. If the
+verbose level is 2, then the entire manual page is printed.
+
 %prep
 %setup -q -n Pod-Parser-%{version}
 find -type f -exec chmod -x {} +
@@ -58,7 +75,22 @@ make test
 %{_mandir}/man1/*
 %{_mandir}/man3/*
 
+%exclude %{_bindir}/pod2usage
+%exclude %{perl_vendorlib}/Pod/Usage.pm
+%exclude %{_mandir}/man1/pod2usage.*
+%exclude %{_mandir}/man3/Pod::Usage.*
+
+%files -n perl-Pod-Usage
+%doc ANNOUNCE CHANGES README TODO
+%{_bindir}/pod2usage
+%{perl_vendorlib}/Pod/Usage.pm
+%{_mandir}/man1/pod2usage.*
+%{_mandir}/man3/Pod::Usage.*
+
 %changelog
+* Mon Feb 04 2013 Petr Pisar ppi...@redhat.com - 1.51-248
+- Sub-package Pod-Usage
+
 * Wed Jan 16 2013 Petr Pisar ppi...@redhat.com - 1.51-247
 - Increase release to supersede perl sub-package
 
--
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-Pod-Parser] Sub-package Pod-Checker

2013-02-04 Thread Petr Pisar

commit 33aa8a21436966587bb3cac303a4e6bb7b2693fd
Author: Petr Písař ppi...@redhat.com
Date:   Mon Feb 4 17:31:16 2013 +0100

Sub-package Pod-Checker

 perl-Pod-Parser.spec |   26 ++
 1 files changed, 26 insertions(+), 0 deletions(-)
---
diff --git a/perl-Pod-Parser.spec b/perl-Pod-Parser.spec
index fe9c0d8..e182aba 100644
--- a/perl-Pod-Parser.spec
+++ b/perl-Pod-Parser.spec
@@ -25,6 +25,17 @@ This software distribution contains the packages for using 
Perl5 POD (Plain
 Old Documentation). See the perlpod and perlsyn manual pages from your
 Perl5 distribution for more information about POD.
 
+%package -n perl-Pod-Checker
+Summary:Check POD documents for syntax errors
+License:GPL+ or Artistic
+Group:  Development/Libraries
+Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Conflicts:  perl-Pod-Parser  1.51-248
+
+%description -n perl-Pod-Checker
+Module and tools to verify POD documentation contents for compliance with the
+Plain Old Documentation format specifications.
+
 %package -n perl-Pod-Usage
 Summary:Print a usage message from embedded pod documentation
 License:GPL+ or Artistic
@@ -75,11 +86,25 @@ make test
 %{_mandir}/man1/*
 %{_mandir}/man3/*
 
+# Pod-Checker
+%exclude %{_bindir}/podchecker
+%exclude %{perl_vendorlib}/Pod/Checker.pm
+%exclude %{_mandir}/man1/podchecker.*
+%exclude %{_mandir}/man3/Pod::Checker.*
+
+# Pod-Usage
 %exclude %{_bindir}/pod2usage
 %exclude %{perl_vendorlib}/Pod/Usage.pm
 %exclude %{_mandir}/man1/pod2usage.*
 %exclude %{_mandir}/man3/Pod::Usage.*
 
+%files -n perl-Pod-Checker
+%doc ANNOUNCE CHANGES README TODO
+%{_bindir}/podchecker
+%{perl_vendorlib}/Pod/Checker.pm
+%{_mandir}/man1/podchecker.*
+%{_mandir}/man3/Pod::Checker.*
+
 %files -n perl-Pod-Usage
 %doc ANNOUNCE CHANGES README TODO
 %{_bindir}/pod2usage
@@ -90,6 +115,7 @@ make test
 %changelog
 * Mon Feb 04 2013 Petr Pisar ppi...@redhat.com - 1.51-248
 - Sub-package Pod-Usage
+- Sub-package Pod-Checker
 
 * Wed Jan 16 2013 Petr Pisar ppi...@redhat.com - 1.51-247
 - Increase release to supersede perl sub-package
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Proposed F19 Feature: Fedora Upgrade - using yum

2013-02-04 Thread Miroslav Suchý


On 01/25/2013 12:12 AM, Lennart Poettering wrote:

So, you can ignore all of that, but then you have to think about what
you actually accomplished by your upgrade? You updated a couple of
libraries, and maybe managed to restart a few processes using them, but
for the rest of them the vulnerable openssl version is still in memory,
still actively used, even though your update script exited successfully
leaving the user under the impression that all was good now and that
after he made this upgrade his machine was not vulnerable anymore.


And how this differ from
  yum upgrade
which I'm doing every day/week?

Lets pretend I'm still running Fedora 16 and every day I do yum-upgrade 
and not rebooted from day zero.
I have exactly the same problem as during yum upgrade to next Fedora 
release.


So we are ignoring this behaviour in middle of release, but it is very 
serious problem between releases?


--
Miroslav Suchy
Red Hat Systems Management Engineering
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: #5467: 2 Packages missing from mirrors

2013-02-04 Thread Fedora Release Engineering

#5467: 2 Packages missing from mirrors
--+---
  Reporter:  limb |  Owner:  rel-eng@…
  Type:  task | Status:  new
 Milestone:  Fedora 19 Alpha  |  Component:  koji
Resolution:   |   Keywords:
Blocked By:   |   Blocking:
--+---
Changes (by rdieter):

 * cc: jcifs-owner@…, rt3-owner@… (added)


Comment:

 {{{
 $ koji latest-pkg f18-updates jcifs rt3
 Build Tag   Built by
   
 
 jcifs-1.3.17-5.fc18   f18   gil
 rt3-3.8.15-2.fc18 f18-updates   corsepiu

 }}}

 Looks like these both went stable at the same time:
 https://admin.fedoraproject.org/updates/FEDORA-2012-18354/jcifs-1.3.17-6.fc18
 https://admin.fedoraproject.org/updates/FEDORA-2012-18054/jcifs-1.3.17-5.fc18

 https://admin.fedoraproject.org/updates/FEDORA-2012-20847/rt3-3.8.15-2.fc18
 https://admin.fedoraproject.org/updates/FEDORA-2012-21093/rt3-3.8.15-3.fc18

 and one tagged last wins.

 I can fix rt3 in updates by retagging things, but jcifs is in the base
 repo, the only way to fix that one is to issue an new update at this
 point.

-- 
Ticket URL: https://fedorahosted.org/rel-eng/ticket/5467#comment:2
Fedora Release Engineering http://fedorahosted.org/rel-eng
Release Engineering for the Fedora Project
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: releasing ownership (maintainers/co-maintainers required)

2013-02-04 Thread Pavel Alexeev


04.02.2013 13:28, Petr Šabata пишет:

On Mon, Feb 04, 2013 at 11:14:48AM +0200, Rakesh Pandit wrote:

On 3 February 2013 17:20, Pavel wrote:

I would like take dvtm and pstreams-devel.


I have released the ownership. You can claim them. Thank you.

I've taken dvtm as I've been more or less maintaining it for
a while now (I missed it in the original list).  I'd welcome
Pavel as a comaintainer, of course.

Thank you.
I had taken pstreams-devel and apply as co-maintainer to dvtm.

P


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

Re: Proposed F19 Feature: Fedora Upgrade - using yum

2013-02-04 Thread Rahul Sundaram

Hi


On Mon, Feb 4, 2013 at 12:35 PM, Miroslav Suchý wrote:


 Lets pretend I'm still running Fedora 16 and every day I do yum-upgrade
 and not rebooted from day zero.
 I have exactly the same problem as during yum upgrade to next Fedora
 release.

 So we are ignoring this behaviour in middle of release, but it is very
 serious problem between releases?


https://fedoraproject.org/wiki/Features/OfflineSystemUpdates

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

Re: Proposed F19 Feature: Replace MySQL with MariaDB

2013-02-04 Thread Toshio Kuratomi

On Mon, Feb 04, 2013 at 12:16:36AM -0500, Rahul Sundaram wrote:
 Hi
 
 
 But the fact that the packages conflict should stand in the way.
 
 
 We don't have any guidelines that forbids it.
  
 
Just a note for people searching the mailing list later:

We do have Guidelines that prohibit Conflicts in many cases:

https://fedoraproject.org/wiki/Packaging:Conflicts

However, the FPC recently (in the last year) added this general exception:

 However, if neither upstream is willing to rename the binaries to resolve
the conflict, AND the binaries are not viable candidates for alternatives or
environment modules (incompatible runtimes), as long as there are no clear
cases for both packages to be installed simultaneously, explicit Conflicts
are permitted at the packager's discretion. Both packages must carry
Conflicts in this case.

which this case seems to fall under.

-Toshio


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

Re: Proposed F19 Feature: Apache OpenOffice

2013-02-04 Thread Luya Tshimbalanga


On 30/01/13 05:22 AM, Stephen Gallagher wrote:

-BEGIN PGP SIGNED MESSAGE-
Given that OpenOffice and LibreOffice share a common history (and not
that far back), are there going to be any efforts made to allow them
to be parallel-installable on the system, or will they be
fully-fledged Conflicts: packages?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEJHpoACgkQeiVVYja6o6NKTwCdHQNiLQ2/0hvnPEool39c/EHG
QYsAoKcrEJFBrYnh6rhUpFJZ/1B70OyL
=/hEX
-END PGP SIGNATURE-


My issue with Apache OpenOffice can be seen on LWN: 
https://lwn.net/Articles/532665/

Here is an extract:

-- Beginning quote
The Apache Software Foundation releases code under the Apache license; 
they are, indeed, rather firm on that point. The Symphony repository, 
though, as checked out from svn.apache.org, contains nearly 3,600 files 
with the following text:


* Licensed Materials - Property of IBM.
* (C) Copyright IBM Corporation 2003, 2011.  All Rights Reserved.

That, of course, is an entirely non-free license header. Interestingly, 
over 2,000 of those files /also/ have headers indicating that they are 
distributable under the GNU Lesser General Public License (version 3). 
These files, in other words, contain conflicting license information but 
neither case (proprietary or LGPLv3) is consistent with the Apache 
license. So it would not be entirely surprising to see a bit of 
confusion over what IBM has really donated.


The conflicting licenses are almost certainly an artifact of how 
Symphony was developed. IBM purchased the right to take the code 
proprietary from Sun; when IBM's code was added to existing, 
LGPLv3-licensed files, the new headers were added without removing the 
old. Since this code has all been donated to the Foundation, clearing up 
the confusion should just be a matter of putting in new license headers. 
But that has not yet happened.

-- End quote

Licensing is the problem. I think it is too early to add Apache 
OpenOffice as feature in Fedora repository due to this ambiguity and 
legal matter.


Luya


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

Re: [389-devel] Regarding changing instance specific scripts to be global/generic

2013-02-04 Thread Mark Reynolds




On 02/04/2013 12:16 PM, Rich Megginson wrote:

On 02/04/2013 09:42 AM, Mark Reynolds wrote:
There has been a request to remove instance specific scripts, and 
make them generic and placed in /usr/sbin/


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


Should we remove all the scripts from /usr/lib64/dirsrv/slapd-INSTANCE:

bak2db  db2index dn2rdn ldif2ldap
ns-newpwpolicy.pl  start-slapd usn-tombstone-cleanup.pl
bak2db.pl   db2index.pl  fixup-linkedattrs.pl 
monitor  restart-slapd  stop-slapd verify-db.pl
cleanallruv.pl  db2ldif  fixup-memberof.pl ns-accountstatus.pl  
restoreconfig  suffix2instance vlvindex
db2bak  db2ldif.pl   ldif2db ns-activate.pl   
saveconfig syntax-validate.pl
db2bak.pl   dbverify ldif2db.pl ns-inactivate.pl 
schema-reload.pl   upgradednformat


It appears almost of these are all instance specific.  Do we want to 
make all of these generic and stick them in /usr/sbin?


Yes.

Works for me.


However, I think it makes sense to keep some instance specific 
scripts: monitor, stop/start/restart, maybe the task scripts too 
(like schema reload, cleanallruv, fix-memberof, etc).  Then only make 
the database scripts generic: db2ldif db2index, ldif2db, db2bak, 
bak2db, etc.


One of the goals is to get any dynamic files out of /usr.  Most 
installations want to mount /usr read-only.  They do not want to mount 
/usr read-write in order to create or update a 389 instance.


IPA works around this by putting the instance specific scripts in 
/var/lib/dirsrv/scripts-INSTANCE - but most people aren't looking for 
389 maintenance commands under /var.


I don't think we need any instance specific scripts, but if we do, 
they should not be in /usr or /var.
Ok,  I don't think we need them, but if someone really wants them, they 
could go in a new directory under /etc/dirsrv/*


We have already started to do this with the 
start-dirsrv/stop-dirsrv/restart-dirsrv scripts in /usr/sbin.  With no 
argument, they work on all instances, or accept the instance name as 
an argument.  This is fine for start/stop/restart, but might be a bit 
surprising for something like db2ldif, if it then does an export of 
all instances.  For all scripts other than start/stop/restart, I think 
the command should fail if the instance is not specified e.g.

# db2ldif ...
Error: More than one instance - specify the instance name as one of: 
foo bar ...other instance names...
One request was to check if there is only a single instance and then use 
that one by default, otherwise error out.  I think this makes sense, and 
should be easy to do.


The other nice thing about the start-dirsrv etc. scripts is that they 
use the instance information from /etc/sysconfig/dirsrv-* to look for 
the dse.ldif, log files, etc.  That removes the need for an instance 
specific script created during instance creation time with hardcoded 
instance specific values.

Yup, sounds like a plan.

Thanks for your input Rich!

Mark




Just curious what everyone thinks about this.

Thanks,
Mark





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

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

Re: polkit changes in f19

2013-02-04 Thread Matthias Clasen

- Original Message -
 On Mon, Feb 04, 2013 at 04:31:10PM +0100, Florian Weimer wrote:
  Are packages really expected to ship .rules files?  I don't think
  so:
 
 Right, as I understand it, with the new system, applications are
 never ever supposed to ship such rules files.

Yes, that's the idea. But we're not quite there - gnome-control-center also 
ships a rules file, currently.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: glpk soname bump expected?

2013-02-04 Thread Michael Schwendt

On Mon, 4 Feb 2013 09:13:33 -0700, Jerry James wrote:

 On Mon, Feb 4, 2013 at 9:07 AM, Orion Poplawski wrote:
  Hmm, that makes it seem even more likely that upstream fat-fingered
  something.
 
  Although: http://upstream-tracker.org/versions/glpk.html
  does indicate that ABI has been broken (although it has been done so in the
  past without bumping the soname).
 
 Looks like this has been brought up on an upstream mailing list:
 
 http://lists.gnu.org/archive/html/help-glpk/2013-01/msg00081.html

Yes, using the libtool versioning scheme enforces a soname change for
changed/added/removed symbols. It's weird to do that in a minor release
4.47 - 4.48, however. And one would need to examine the releases prior
to 4.47 to understand history (i.e. whether it has arrived at -version-info
32:0:32 without bumping the soname before because of keeping cur=age).

-- 
Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc6.git0.1.fc19.x86_64
loadavg: 0.32 0.38 0.24
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Apache OpenOffice

2013-02-04 Thread Andrea Pescetti


Luya Tshimbalanga wrote:

My issue with Apache OpenOffice can be seen on LWN:
https://lwn.net/Articles/532665/ [...]
The Apache Software Foundation releases code under the Apache license;
they are, indeed, rather firm on that point. The Symphony repository,
though [...]


It's an outdated article and not much relevant to the current discussion 
(you see, it says the Symphony repository...). But I'm very happy to 
address the parts that can be relevant to this discussion, leaving 
politics aside. See below.



Licensing is the problem. I think it is too early to add Apache
OpenOffice as feature in Fedora repository due to this ambiguity and
legal matter.


The Apache Foundation is absolutely paranoid on license clarity in the 
software it releases. The trunk of Apache OpenOffice is subject to 
periodic, full, automated, scans that ensure that all files are properly 
licensed. Apache calls them RAT Scans, see

http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Rat_Scan

It is part of the Apache OpenOffice mission to make sure that everybody, 
including of course other software projects, can confidently use the 
code it releases. The license check is one of the mandatory steps in 
approving a release. So I'm positive that Apache OpenOffice receives at 
least the same level of scrutiny on licenses as any other software 
included in Fedora.


It is important to understand (and this is a common misunderstanding, so 
thank you for raising it) that this applies to the OpenOffice trunk and 
to releases. The OpenOffice SVN repository contains a lot of other 
stuff, including two (yes, two) websites, development branches, and 
materials the project inherited, like the Symphony code. They are hosted 
for convenience, but they are not subject to scans and may not have 
up-to-date licensing information. Whatever is packaged for Fedora won't, 
of course, be taken from the convenience directories.


The Symphony code is like everything else in this respect: all Symphony 
code that OpenOffice will choose to use will sooner or later go to trunk 
and into a release, receiving the same paranoid attention as the rest 
and a crystal clear license notice (the Apache 2 License in this case) 
allowing anybody to use it.


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

Static Analysis: some UI ideas

2013-02-04 Thread David Malcolm

I've been experimenting with some UI ideas for reporting static analysis
results: I've linked to two different UI reports below.

My hope is that we'll have a server in the Fedora infrastructure for
browsing results, marking things as false positives etc.

However, for the purposes of simplicity during experimentation I'm
simply building static HTML reports.

My #1 requirement when I'm viewing static analysis results is that I
want to *see the code* with the report, so I've attempted to simply show
the code with warnings shown inline.

Note also that when we have a server we can do all kinds of
auto-filtering behaviors so that e.g. package maintainers only see
warnings from tests that have decent signal:noise ratio (perhaps with
other warnings greyed out, or similar).


Results of an srpm build

The first experimental report can be seen here:
http://fedorapeople.org/~dmalcolm/static-analysis/2013-02-01/policycoreutils-2.1.13-27.2.fc17.src.rpm-001.html

It shows warnings from 4 different static analyzers when rebuilding a
particular srpm (policycoreutils-2.1.13-27.2.fc17).  There's a summary
table at the top of the report showing for each source files in the
build which analyzers found reports (those that found any are
highlighted in red).  Each row has a a linking you to a report on each
source file.  Those source files that have issues have a table showing
the issues, with links to them.  The issue are shown inline within the
syntax-colored source files.

Ideally there'd by support for using n and p to move to
next/previous error (with a little javascript), but for now I've been
using back in the browser to navigate through the tables.

An example of an error shown inline:
http://fedorapeople.org/~dmalcolm/static-analysis/2013-02-01/policycoreutils-2.1.13-27.2.fc17.src.rpm-001.html#file-868b5c03918269eaabebfedc41eaf32e390357be-line-791
shows a true error in seunshare.c found by cppcheck (foo =
realloc(foo, , )  is always a mistake, since if realloc fails you get
NULL back, but still have responsibility for freeing the old foo).


Comparison report
=
The second experimental report can be seen here:
http://fedorapeople.org/~dmalcolm/static-analysis/2013-02-04/comparison-of-python-ethtool-builds.html

It shows a comparison of the results of two different builds of a
package (python-ethtool), again running multiple analyzers.
(specifically, a comparison between 0.7 and an snapshot of upstream
git).

It's similar to the first report, but instead of showing one file at a
time, it shows a side-by-side diff of old vs new file.

Any issues found in old or new source code are shown inline, so you can
see issues that are fixed, issues that are newly introduced, and issues
that are present in both old and new code.

Both reports could use some javascript to let you use n and p to go
to next/previous errors.  Also my CSS is ugly.

Any javascript/css experts out there who can help with those areas?

(FWIW, the code that generates these are in:
https://github.com/fedora-static-analysis/mock-with-analysis/tree/master/reports
specifically make-simple-report.py and make-comparative-report.py;
they're reading the output from mock-with-analysis)

Dave

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

Re: Static Analysis: some UI ideas

2013-02-04 Thread Kamil Dudka

On Monday, February 04, 2013 15:04:36 David Malcolm wrote:
 I've been experimenting with some UI ideas for reporting static analysis
 results: I've linked to two different UI reports below.
 
 My hope is that we'll have a server in the Fedora infrastructure for
 browsing results, marking things as false positives etc.
 
 However, for the purposes of simplicity during experimentation I'm
 simply building static HTML reports.
 
 My #1 requirement when I'm viewing static analysis results is that I
 want to *see the code* with the report, so I've attempted to simply show
 the code with warnings shown inline.

Does it mean you need to keep the unpacked source files for all scanned 
packages?  Then you will easily run out of disk space after scanning a few 
versions of libreoffice.
 
 Note also that when we have a server we can do all kinds of
 auto-filtering behaviors so that e.g. package maintainers only see
 warnings from tests that have decent signal:noise ratio (perhaps with
 other warnings greyed out, or similar).

It would be cool if the auto-filtering techniques were implemented in 
standalone utilities operating on text files so that we have separated 
algorithms from presentation of the results.  It is easy to use a filter-like 
utility on a server, but painful to use a server for processing local text 
files.

 Results of an srpm build
 
 The first experimental report can be seen here:
 http://fedorapeople.org/~dmalcolm/static-analysis/2013-02-01/policycoreutils
 -2.1.13-27.2.fc17.src.rpm-001.html
 
 It shows warnings from 4 different static analyzers when rebuilding a
 particular srpm (policycoreutils-2.1.13-27.2.fc17).  There's a summary
 table at the top of the report showing for each source files in the
 build which analyzers found reports (those that found any are
 highlighted in red).  Each row has a a linking you to a report on each
 source file.  Those source files that have issues have a table showing
 the issues, with links to them.  The issue are shown inline within the
 syntax-colored source files.
 
 Ideally there'd by support for using n and p to move to
 next/previous error (with a little javascript), but for now I've been
 using back in the browser to navigate through the tables.
 
 An example of an error shown inline:
 http://fedorapeople.org/~dmalcolm/static-analysis/2013-02-01/policycoreutils
 -2.1.13-27.2.fc17.src.rpm-001.html#file-868b5c03918269eaabebfedc41eaf32e3903
 57be-line-791 shows a true error in seunshare.c found by cppcheck (foo =
 realloc(foo, , )  is always a mistake, since if realloc fails you get
 NULL back, but still have responsibility for freeing the old foo).

The limitation of javascript-based UIs is that they are read-only.  Some 
developers prefer to go through the defects using their own environment 
(eclipse, vim, emacs, ...) rather than a web browser so that they can fix
them immediately.  We should support both approaches I guess.

 Comparison report
 =
 The second experimental report can be seen here:
 http://fedorapeople.org/~dmalcolm/static-analysis/2013-02-04/comparison-of-p
 ython-ethtool-builds.html
 
 It shows a comparison of the results of two different builds of a
 package (python-ethtool), again running multiple analyzers.
 (specifically, a comparison between 0.7 and an snapshot of upstream
 git).
 
 It's similar to the first report, but instead of showing one file at a
 time, it shows a side-by-side diff of old vs new file.

Does it assume that you have 1:1 file mapping between old and new versions of 
the package?  What will happen if the source files are renamed, moved, merged, 
split, etc.?

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

Re: Proposed F19 Feature: Fedora Upgrade - using yum

On Mon, 2013-02-04 at 18:11 +0100, Miroslav Suchý wrote:
 On 01/29/2013 12:59 AM, Adam Williamson wrote:
  Well, the other thing fedup does - and the other reason it's necessary
  compared to a simple online yum upgrade - is provide a mechanism for
  pretty much any package to hook in pretty much any action to be
  performed as part of the upgrade. To be sure of what's going to happen
  during a given fedup transaction, you should also check what scripts are
  going to get fired as part of the upgrade. In F18 I'm not sure there are
  any, but this is the kind of mechanism we would use, fr'instance, to
  switch the default bootloader as part of an upgrade in future, if we
  decided we wanted to do that again. The kind of stuff that can't be done
  in %pre/%post etc.
 
 Is this documented somewhere? I would like to read more about this feature.

https://ohjeezlinux.wordpress.com/2012/11/13/fedup-a-little-background/ ... 
kinda. That's the best that I know of.
-- 
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: Static Analysis: some UI ideas

2013-02-04 Thread David Malcolm

On Mon, 2013-02-04 at 22:13 +0100, Kamil Dudka wrote:
 On Monday, February 04, 2013 15:04:36 David Malcolm wrote:
  I've been experimenting with some UI ideas for reporting static analysis
  results: I've linked to two different UI reports below.
  
  My hope is that we'll have a server in the Fedora infrastructure for
  browsing results, marking things as false positives etc.
  
  However, for the purposes of simplicity during experimentation I'm
  simply building static HTML reports.
  
  My #1 requirement when I'm viewing static analysis results is that I
  want to *see the code* with the report, so I've attempted to simply show
  the code with warnings shown inline.
 
 Does it mean you need to keep the unpacked source files for all scanned 
 packages?  Then you will easily run out of disk space after scanning a few 
 versions of libreoffice.

Content-addressed storage: they're named by SHA-1 sum of their contents,
similar to how git does it, so if the bulk of the files don't change,
they have the same SHA-1 sum and are only stored once.  See e.g.:
http://fedorapeople.org/~dmalcolm/static-analysis/2013-01-30/python-ethtool-0.7-4.fc19.src.rpm/static-analysis/sources/
I probably should gzip them as well.

Currently it's capturing all C files that have GCC invoked on them, or
are mentioned in a warning (e.g. a .h file with an inline function with
a bug).  I could tweak things so it only captures files that are
mentioned in a warning.

 
  Note also that when we have a server we can do all kinds of
  auto-filtering behaviors so that e.g. package maintainers only see
  warnings from tests that have decent signal:noise ratio (perhaps with
  other warnings greyed out, or similar).
 
 It would be cool if the auto-filtering techniques were implemented in 
 standalone utilities operating on text files so that we have separated 
 algorithms from presentation of the results.  It is easy to use a filter-like 
 utility on a server, but painful to use a server for processing local text 
 files.

I guess the issue is: where do you store the knowledge about good vs bad
warnings?   My plan was to store it server-side.  But we could generate
summaries and have them available client-side.  For example, if, say
cppcheck's useClosedFile test has generated 100 issues of which 5 have
received human attention: 1 has been marked as a true positive, and 4
has been marked as false positives.  We could then say (cppcheck,
useClosedFile) has a signal:noise ratio of 1:4.   We could then
generate a summary of these (tool, testID) ratios for use by clients,
which could then a user-configurable signal:noise threshold, so you can
say: only show me results from tests that achieve 1:2 or better.


  Results of an srpm build
  
  The first experimental report can be seen here:
  http://fedorapeople.org/~dmalcolm/static-analysis/2013-02-01/policycoreutils
  -2.1.13-27.2.fc17.src.rpm-001.html
  
  It shows warnings from 4 different static analyzers when rebuilding a
  particular srpm (policycoreutils-2.1.13-27.2.fc17).  There's a summary
  table at the top of the report showing for each source files in the
  build which analyzers found reports (those that found any are
  highlighted in red).  Each row has a a linking you to a report on each
  source file.  Those source files that have issues have a table showing
  the issues, with links to them.  The issue are shown inline within the
  syntax-colored source files.
  
  Ideally there'd by support for using n and p to move to
  next/previous error (with a little javascript), but for now I've been
  using back in the browser to navigate through the tables.
  
  An example of an error shown inline:
  http://fedorapeople.org/~dmalcolm/static-analysis/2013-02-01/policycoreutils
  -2.1.13-27.2.fc17.src.rpm-001.html#file-868b5c03918269eaabebfedc41eaf32e3903
  57be-line-791 shows a true error in seunshare.c found by cppcheck (foo =
  realloc(foo, , )  is always a mistake, since if realloc fails you get
  NULL back, but still have responsibility for freeing the old foo).
 
 The limitation of javascript-based UIs is that they are read-only.  Some 
 developers prefer to go through the defects using their own environment 
 (eclipse, vim, emacs, ...) rather than a web browser so that they can fix
 them immediately.  We should support both approaches I guess.

Both approaches.  What we could do is provide a tool (fedpkg
get-errors ?)  that captures the errors in the same output format as
gcc.  That way if you run it from say gcc, the *compilation* buffer has
everything in the right format, and emacs' goto-next-error stuff works.

 
  Comparison report
  =
  The second experimental report can be seen here:
  http://fedorapeople.org/~dmalcolm/static-analysis/2013-02-04/comparison-of-p
  ython-ethtool-builds.html
  
  It shows a comparison of the results of two different builds of a
  package (python-ethtool), again running multiple analyzers.
  (specifically, a

Re: Proposed F19 Feature: Apache OpenOffice

On Mon, 4 Feb 2013 14:31:11 + 
James Hogarth wrote:
 Might I suggest focusing on packaging 3.4.1 for rawhide and dealing
 with the issues surrounding conflicts and if that gies well consider
 the 4.0 release (or whatever lines up then) for F20?
That's mostly how I understand the proposal. The goal for F19 is to get
it in and solve (potential) conflicts. It should probably either drop
the mentions of 4.0 or clearly state that 4.0 is going (unless some
kind of miracle happens) in F20 and this is just preparation stage --
i.e. getting the latest stable in, working and without conflicts.

Martin


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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Mon, 4 Feb 2013 16:34:18 +0100 
Jan Kratochvil wrote:
 Still I believe it is probably true as I doubt Fedora QA tests
 compatibility with old hosts.
 
Fedora QA AFAIK tests on their own hardware only + virtual machines. I
don't know about kernel upstream QA/devs though.

I'm running F18 on a 32bit machine as well.

Martin


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

Re: glpk soname bump expected?

2013-02-04 Thread Orion Poplawski


On 02/04/2013 09:13 AM, Jerry James wrote:

On Mon, Feb 4, 2013 at 9:07 AM, Orion Poplawski or...@cora.nwra.com wrote:

Hmm, that makes it seem even more likely that upstream fat-fingered
something.

Although: http://upstream-tracker.org/versions/glpk.html
does indicate that ABI has been broken (although it has been done so in the
past without bumping the soname).


Looks like this has been brought up on an upstream mailing list:

http://lists.gnu.org/archive/html/help-glpk/2013-01/msg00081.html


Thanks, I've replied (hopefully).  So, while the bump was a big change, and 
while the maintainer perhaps didn't fully understand the ramifications of the 
ABI change, it was changed and a soname bump was appropriate.



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

Re: Strange yum update hang (or something else) in Rawhide .. how to debug this further?

On Mon, Feb 04, 2013 at 07:17:35PM +0200, Panu Matilainen wrote:
 On 02/04/2013 07:01 PM, Richard W.M. Jones wrote:
 On Mon, Feb 04, 2013 at 04:38:08PM +, Richard W.M. Jones wrote:
 
Cleanup: cpp-4.8.0-0.7.fc19.x86_64
  215/262
Cleanup: gdb-7.5.50.20130118-2.fc19.x86_64
  216/262
Cleanup: 1:findutils-4.5.10-7.fc19.x86_64 
  217/262
Cleanup: spice-server-0.12.2-2.fc19.x86_64
  218/262
Cleanup: cracklib-2.8.22-2.fc19.x86_64
  219/262
Cleanup: libvirt-daemon-driver-interface-1.0.1-6.fc19.x86_64  
  220/262
Cleanup: libvirt-daemon-driver-nodedev-1.0.1-6.fc19.x86_64
  221/262
Cleanup: libvirt-daemon-driver-nwfilter-1.0.1-6.fc19.x86_64   
  222/262
Cleanup: libvirt-daemon-driver-secret-1.0.1-6.fc19.x86_64 
  223/262
Cleanup: libvirt-daemon-1.0.1-6.fc19.x86_64   
  224/262
Cleanup: libvirt-client-1.0.1-6.fc19.x86_64   
  225/262
Cleanup: cyrus-sasl-2.1.25-2.fc19.x86_64  
  226/262
Cleanup: openldap-2.4.33-3.fc19.x86_64
  227/262
Cleanup: nss-tools-3.14.1-3.fc19.x86_64   
  228/262
Cleanup: nss-sysinit-3.14.1-3.fc19.x86_64 
  229/262
Cleanup: nss-3.14.1-3.fc19.x86_64 
  230/262
 (and here it hangs, for at least 20 minutes)
 
 So how odd is this?  Suddenly it leaps back into life, after maybe
 30-40 minutes.
 
 Sounds like https://bugzilla.redhat.com/show_bug.cgi?id=860500

Yes, this looks similar.

It's possible that I ran a non-root yum command in another terminal.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Mon, 2013-02-04 at 06:56 +0100, Kevin Kofler wrote:
 Adam Williamson wrote:
  2. Can't we just not have a default?
  
  Not really. Others have touched on this, but the websites team really
  wants the simplicity of a straightforward 'Download' link that gets you
  a live image, and that pretty much requires a default desktop.
 
 And just because the websites team wants that nonsense, we have to keep 
 it? Seriously? That one-click download is utter nonsense: No matter what you 
 pick, it will always be the wrong thing for many people. The step to 
 actually pick the correct download cannot be skipped.

...and forcing a choice - possibly between several things they are not
familiar with either in detail or in nature - is equally wrong for many
people. Probably *more* people. Lots of people don't really care what
desktop they get, and lots of people don't know what a desktop is or
what are the differences between GNOME and KDE and Xfce and LXDE and and
and and...

You're a new Linux user, you go to our download page, and instead of a
simple big green Download button, it starts asking you questions about
what 'desktop environment' you want? What the hell is this crap?

Getting this right was one of the simple things Ubuntu did that helped
its initial surge in popularity over other distros at the time, BTW.
They didn't make you pass a test to download the product.
-- 
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: Proposed F19 Feature: Apache OpenOffice

On Mon, 2013-02-04 at 07:47 +0100, Kevin Kofler wrote:
 Jaroslav Reznik wrote:
  = Features/ApacheOpenOffice =
  https://fedoraproject.org/wiki/Features/ApacheOpenOffice
  
  Feature owner(s): Andrea Pescetti pesce...@apache.org
  
  Add Apache OpenOffice, the free productivity suite, to Fedora.
 
 A big -1 to this feature, and in fact I'd urge FESCo to veto that package 
 outright (or if it somehow already made it into Fedora, to get it blocked in 
 Koji and Obsoleted by libreoffice ASAP).

Kevin, could you *please* stop essentially sending the same mail seven
times? I mean, I know I'm guilty of over-posting at times, but this is
just ludicrous. I think by the fourth mail in this little set you just
spammed, everyone was pretty clear where you stood on the *Office
question.

If you get behind on reading the list, it is not a good idea to just
read through one mail at a time and send replies to each one as soon as
they spring into your head. Read *all* the posts first, then write one
or two mails that include any points you have to add to the discussion
that are actually original and haven't been posted by five other people
already. And make it just one or two mails, not seven in a row.
-- 
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: Proposed F19 Feature: Cinnamon as Default Desktop

On Mon, 2013-02-04 at 18:19 +0100, Ralf Corsepius wrote:
 On 02/04/2013 05:47 PM, Kévin Raymond wrote:
   From what I have reports even Fedora 32-bit does not boot on such 
  machines
  because nobody tests the bleeding edge Fedora kernels on such obsolete
  hardware.
 
  Could you provide more details? I have Fedora 18 running on several
  32bit machines and am wondering what you are referring to.
 
   From releng, I got the confirmation that some new computers does boot only 
  UEFI
  OS by default. And we don't provide UEFI on the 32bit ISO. Therefor, it is 
  not
  compatible.
 Ah, OK - My 32bit machines all predate UEFI ;)
 
 [2 ca. 4 year old, still-inuse Atom-N270 netbooks and a 10years+ old 
 PIII, which serves as testing machine ;)]

I doubt that's what the OP was talking about, as he mentioned obsolete
hardware. There was exactly one set of systems, ever, that used EFI-ish
firmware but were 32-bit not 64-bit: the very early Intel Macs. We do
not support those by policy. There's no practical reason to want to boot
a 32-bit Fedora image as UEFI native - if you're doing it, it means you
got something wrong. But people do get things wrong, and it was
reasonable to stop labelling the 32-bit image as 'most compatible' to
try and stop people getting this thing wrong.
-- 
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

NSS in Rawhide updated to nss-3.12.4

2013-02-04 Thread Elio Maldonado

To all interested,

This is the upstream announcement:

[NOTE: NSS 3.14.2 does not include a fix for the attacks described
in
the paper "Lucky Thirteen: Breaking the TLS and DTLS Record
Protocols"
(http://www.isg.rhul.ac.uk/tls/).
An upcoming NSS patch release will
address the attacks.]

Network Security Services (NSS) 3.14.2 is a patch release for NSS
3.14.
The bug fixes in NSS 3.14.2 are described in the "Bugs Fixed"
section
below. NSS 3.14.2 should be used with NSPR 4.9.5 or newer.

The release is available for download from
https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_14_2_RTM/src/

For the primary NSS documentation pages please visit
https://developer.mozilla.org/en-US/docs/NSS

New in NSS 3.14.2

* NSS will now make use of the Intel AES-NI and AVX instruction sets
for hardware-accelerated AES-GCM on 64-bit Linux systems.

* Initial manual pages for some NSS command line tools have been
added.
They are still under review, and contributions are welcome. The
documentation is in the docbook format and can be rendered as HTML
and UNIX-style manual pages using an optional build target.

New Types:
* in certt.h
- cert_pi_useOnlyTrustAnchors
* in secoidt.h
- SEC_OID_MS_EXT_KEY_USAGE_CTL_
SIGNING

Notable Changes in NSS 3.14.2

* Bug 805604 - Support for AES-NI and AVX accelerated AES-GCM was
contributed by Shay Gueron of Intel. If compiled on Linux
systems in
64-bit mode, NSS will include runtime detection to check if the
platform supports AES-NI and PCLMULQDQ. If so, NSS uses the
optimized
code path, reducing the CPU cycles per byte to 1/20 of what was
required before the patch
( https://bugzilla.mozilla.org/show_bug.cgi?id=805604
and
https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pdf).
Support for other platforms, such as Windows, will follow in a
future
NSS release. ( https://bugzilla.mozilla.org/show_bug.cgi?id=540986
)
* SQLite has been updated to 3.7.15.
* Bug 816853 - When using libpkix for certificate validation,
applications may now supply additional application-defined trust
anchors to be used in addition to those from loaded security
tokens,
rather than as an alternative to.
( https://bugzilla.mozilla.org/show_bug.cgi?id=816853
)
* Bug 772144 - Basic support for running NSS test suites on
Android
devices.This is currently limited to running tests from a Linux
host
machine using an SSH connection. Only the SSHDroid app has been
tested.
* Bug 373108 - Fixed a bug where, under certain circumstances,
when
applications supplied invalid/out-of-bounds parameters for AES
encryption, a double free may occur.
* Bug 813857 - Modification of certificate trust flags from
multiple
threads is now a thread-safe operation.
* Bug 618418 - C_Decrypt/C_DecryptFinal now correctly validate the
PKCS #7 padding when present.
* Bug 807890 - Add support for Microsoft Trust List Signing EKU.
* Bug 822433 - Fix a crash in dtls_FreeHandshakeMessages.
* Bug 823336 - Reject invalid LDAP AIA URIs sooner.

Bugs fixed in NSS 3.14.2

* https://bugzilla.mozilla.org/buglist.cgi?list_id=5502456;resolution=FIXED;classification=Components;query_format=advanced;target_milestone=3.14.2;product=NSS

Compatibility

NSS 3.14.2 shared libraries are backward compatible with all older
NSS
3.x shared libraries. A program linked with older NSS 3.x shared
libraries will work with NSS 3.14.2 shared libraries without
recompiling
or relinking. Furthermore, applications that restrict their use of
NSS
APIs to the functions listed in NSS Public Functions will remain
compatible with future versions of the NSS shared libraries.

Feedback

Bugs discovered should be reported by filing a bug report with
bugzilla.mozilla.org
(product NSS).

---

Working now on bringing it to F-18 and F-17.

-Elio

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Mon, 2013-02-04 at 23:27 +0100, Martin Sourada wrote:
 On Mon, 4 Feb 2013 16:34:18 +0100 
 Jan Kratochvil wrote:
  Still I believe it is probably true as I doubt Fedora QA tests
  compatibility with old hosts.
  
 Fedora QA AFAIK tests on their own hardware only + virtual machines. I
 don't know about kernel upstream QA/devs though.
 
 I'm running F18 on a 32bit machine as well.

The RH staff on the QA team have access to RH's test farm if we need it,
though we generally use it only for testing specific hardware we don't
happen to have ourselves (mainly enterprise storage/networking stuff).
Mostly we test on 'whatever we have lying around the office', which I
think does include a few 32-bit only hosts.
-- 
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: Strange yum update hang (or something else) in Rawhide .. how to debug this further?

On Mon, 2013-02-04 at 19:17 +0200, Panu Matilainen wrote:
 On 02/04/2013 07:01 PM, Richard W.M. Jones wrote:
  On Mon, Feb 04, 2013 at 04:38:08PM +, Richard W.M. Jones wrote:
 
 Cleanup: cpp-4.8.0-0.7.fc19.x86_64
  215/262
 Cleanup: gdb-7.5.50.20130118-2.fc19.x86_64
  216/262
 Cleanup: 1:findutils-4.5.10-7.fc19.x86_64 
  217/262
 Cleanup: spice-server-0.12.2-2.fc19.x86_64
  218/262
 Cleanup: cracklib-2.8.22-2.fc19.x86_64
  219/262
 Cleanup: libvirt-daemon-driver-interface-1.0.1-6.fc19.x86_64  
  220/262
 Cleanup: libvirt-daemon-driver-nodedev-1.0.1-6.fc19.x86_64
  221/262
 Cleanup: libvirt-daemon-driver-nwfilter-1.0.1-6.fc19.x86_64   
  222/262
 Cleanup: libvirt-daemon-driver-secret-1.0.1-6.fc19.x86_64 
  223/262
 Cleanup: libvirt-daemon-1.0.1-6.fc19.x86_64   
  224/262
 Cleanup: libvirt-client-1.0.1-6.fc19.x86_64   
  225/262
 Cleanup: cyrus-sasl-2.1.25-2.fc19.x86_64  
  226/262
 Cleanup: openldap-2.4.33-3.fc19.x86_64
  227/262
 Cleanup: nss-tools-3.14.1-3.fc19.x86_64   
  228/262
 Cleanup: nss-sysinit-3.14.1-3.fc19.x86_64 
  229/262
 Cleanup: nss-3.14.1-3.fc19.x86_64 
  230/262
  (and here it hangs, for at least 20 minutes)
 
  So how odd is this?  Suddenly it leaps back into life, after maybe
  30-40 minutes.
 
 Sounds like https://bugzilla.redhat.com/show_bug.cgi?id=860500

Sure does. Funnily enough, when I first encountered it no-one else was,
and now other people are seeing it, I never seem to any more :/ So I
haven't been able to contribute any more to the report.
-- 
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: Proposed F19 Feature: Cinnamon as Default Desktop

2013-02-04 Thread Orcan Ogetbil

On Mon, Feb 4, 2013 at 6:53 PM, Adam Williamson wrote:

 You're a new Linux user, you go to our download page, and instead of a
 simple big green Download button, it starts asking you questions about
 what 'desktop environment' you want?


As I said earlier in this thread, and as the Fedora Board ratified
(link given in my previous post), this is not the type of the user
base we are targeting. There is a perfect distro for such users, and
its called Ubuntu.

  What the hell is this crap?

rant
I really don't enjoy supporting users who are unable to read 10 lines
of documentation. What the hell this crap is to be explained there
concisely so that they will be able to make a more informed decision
and increase their productivity.

 Getting this right was one of the simple things Ubuntu did that helped
 its initial surge in popularity over other distros at the time, BTW.
 They didn't make you pass a test to download the product.

Promoting laziness is a dangerous path.
/rant

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

On Mon, 2013-02-04 at 20:14 -0500, Orcan Ogetbil wrote:
 On Mon, Feb 4, 2013 at 6:53 PM, Adam Williamson wrote:
 
  You're a new Linux user, you go to our download page, and instead of a
  simple big green Download button, it starts asking you questions about
  what 'desktop environment' you want?
 
 
 As I said earlier in this thread, and as the Fedora Board ratified
 (link given in my previous post), this is not the type of the user
 base we are targeting. There is a perfect distro for such users, and
 its called Ubuntu.

Sorry, but I don't agree with your interpretation of the Board's list:

- Voluntary Linux consumer
- Computer-friendly
- Likely collaborator
- General productivity user

Which of those screams 'will clearly be familiar with the concepts of
'desktop environment', 'KDE', and 'GNOME' to you?

'Voluntary Linux consumer' doesn't mean they *already know about Linux*,
just that they have chosen to go out and try Fedora of their own accord.
So far as I can see, the classic 'been using Windows and poking around
for a while, read a news article about this Linux thing, wants to try it
out' person meets those requirements just fine. This person does not
know what a 'KDE' is.
-- 
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: Proposed F19 Feature: Cinnamon as Default Desktop

2013-02-04 Thread Jon VanAlten

- Original Message -
 From: Adam Williamson awill...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Monday, February 4, 2013 6:53:20 PM
 Subject: Re: Proposed F19 Feature: Cinnamon as Default Desktop

 On Mon, 2013-02-04 at 06:56 +0100, Kevin Kofler wrote:
  Adam Williamson wrote:
   2. Can't we just not have a default?

   Not really. Others have touched on this, but the websites team
   really
   wants the simplicity of a straightforward 'Download' link that
   gets you
   a live image, and that pretty much requires a default desktop.

  And just because the websites team wants that nonsense, we have
  to keep
  it? Seriously? That one-click download is utter nonsense: No matter
  what you
  pick, it will always be the wrong thing for many people. The step
  to
  actually pick the correct download cannot be skipped.

 ...and forcing a choice - possibly between several things they are
 not
 familiar with either in detail or in nature - is equally wrong for
 many
 people. Probably *more* people. Lots of people don't really care what
 desktop they get, and lots of people don't know what a desktop is or
 what are the differences between GNOME and KDE and Xfce and LXDE and
 and
 and and...

 You're a new Linux user, you go to our download page, and instead of
 a
 simple big green Download button, it starts asking you questions
 about
 what 'desktop environment' you want? What the hell is this crap?

 Getting this right was one of the simple things Ubuntu did that
 helped
 its initial surge in popularity over other distros at the time, BTW.
 They didn't make you pass a test to download the product.

There's a lot of things that Ubuntu does that Fedora will probably
never do, so that's not really an argument.

I don't have a horse in the default desktop race, being one of
those weirdo tiling window manager users, which is possibly the
exact reason why the idea of not having a default appeals to me.
Maybe, if your objection is that the choice is too hard, you are
making it too hard artificially?  For those who really are brand
new and won't really have any idea what's going to be under the
hood of any one DE, wouldn't a simple screen shot highlighting
some of the primary interfaces of the home screen be enough for
that person to say, Hey that one looks pretty (or maybe similar
to my current desktop, or some other property that motivates my
software choices).  Now I shall click the download button below
the picture, and presumably I will get something that will look
like the picture?  I think this is a test that most people
can handle (and if they can't, I frankly don't want to be the
one to support them!).  And beside the download button for each
DE can be a more info link, for those (possibly majority?) of
users who are more interested in learning about the image they
are about to download.  I haven't yet met a linux user who was
not driven in part by curiosity.  Maybe I don't get out enough.

This is just one idea of how a selection of different DE can be
presented without it being an onerous choice, I'm sure the most
excellent UI-oriented people we have contributing to Fedora can
come up with something much much better.

tl'dr: Please leave the straw man new users won't be able to
decide argument at the door, there's a way around it if we can
think about the *best* way to do it, rather than the *worst*.

cheers,
jon

ps: the horse I *do* have a race in is which ever one can stop
this endless mine is better and should be the default
argument (not that this is the position I think you're taking,
Adam!!).  The way it seems to be going now, there will be some
group(s) left offended at the end of F19 release cycle, and
then we'll have the same thread during F20, rinse, repeat.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Replace MySQL with MariaDB

2013-02-04 Thread Kevin Kofler

Rahul Sundaram wrote:
 You are putting the cart before the horse.  You have to demonstrate its
 feasible to fix them before excluding future uses.   I don't see how it is
 possible to fix the entire distribution to never use conflicts.

Aggressive renaming (see e.g. what I did to kdelibs to allow kdelibs-devel 
and kdelibs3-devel to coexist; renaming is also the solution in the case of 
completely different binaries which happen to conflict), and dropping of 
unneeded compatibility cruft (where nothing really needs the compatibility 
version anymore, which seems to be the case here).

Kevin Kofler

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-02-04 Thread Kevin Kofler

Adam Williamson wrote:
 ...and forcing a choice - possibly between several things they are not
 familiar with either in detail or in nature - is equally wrong for many
 people. Probably *more* people. Lots of people don't really care what
 desktop they get, and lots of people don't know what a desktop is or
 what are the differences between GNOME and KDE and Xfce and LXDE and and
 and and...
 
 You're a new Linux user, you go to our download page, and instead of a
 simple big green Download button, it starts asking you questions about
 what 'desktop environment' you want? What the hell is this crap?
 
 Getting this right was one of the simple things Ubuntu did that helped
 its initial surge in popularity over other distros at the time, BTW.
 They didn't make you pass a test to download the product.

I don't think distro XYZ did that is a reasonable argument for doing 
something in Fedora, but since you started it: OpenSUSE is doing just fine 
doing exactly what I suggest (making people actually pick their download). 
Their download button actually points to a selector, not directly to an ISO.

Kevin Kofler

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

Re: Proposed F19 Feature: Apache OpenOffice

2013-02-04 Thread Kevin Kofler

Martin Sourada wrote:

 On Mon, 4 Feb 2013 14:31:11 +
 James Hogarth wrote:
 Might I suggest focusing on packaging 3.4.1 for rawhide and dealing
 with the issues surrounding conflicts and if that gies well consider
 the 4.0 release (or whatever lines up then) for F20?
 That's mostly how I understand the proposal. The goal for F19 is to get
 it in and solve (potential) conflicts. It should probably either drop
 the mentions of 4.0 or clearly state that 4.0 is going (unless some
 kind of miracle happens) in F20 and this is just preparation stage --
 i.e. getting the latest stable in, working and without conflicts.

And what would be the benefit of that way of proceeding to the user?

It seems to me that this feature needs to be punted from F19 and reevaluated 
for F20, after F19 branches.

Kevin Kofler

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

2013-02-04 Thread Orcan Ogetbil

On Mon, Feb 4, 2013 at 8:32 PM, Adam Williamson  wrote:
 On Mon, 2013-02-04 at 20:14 -0500, Orcan Ogetbil wrote:
 On Mon, Feb 4, 2013 at 6:53 PM, Adam Williamson wrote:
 
  You're a new Linux user, you go to our download page, and instead of a
  simple big green Download button, it starts asking you questions about
  what 'desktop environment' you want?
 

 As I said earlier in this thread, and as the Fedora Board ratified
 (link given in my previous post), this is not the type of the user
 base we are targeting. There is a perfect distro for such users, and
 its called Ubuntu.

 Sorry, but I don't agree with your interpretation of the Board's list:


Okay, that's fair. I respect your interpretation

 - Voluntary Linux consumer
 - Computer-friendly
 - Likely collaborator
 - General productivity user

 Which of those screams 'will clearly be familiar with the concepts of
 'desktop environment', 'KDE', and 'GNOME' to you?


The combination of all of the above 4 screams to me that the target
user base shall be:
- capable of comprehend some short documentation and make a decision
on what could be the best candidate to fit in his workflow, if not
already familiar with the concepts of  'desktop environment 'KDE',
and 'GNOME'

The documentation can include some nice and fancy screenshots and
demonstrations as Jon proposed.

The user should also be informed that the choice is not final, and the
DE can be switched after the installation via package manager.
Does the current webpage indicate this somewhere? I could not see it.
Note that this is a side-topic, and can be discussed exclusively on
its own.

 'Voluntary Linux consumer' doesn't mean they *already know about Linux*,
 just that they have chosen to go out and try Fedora of their own accord.
 So far as I can see, the classic 'been using Windows and poking around
 for a while, read a news article about this Linux thing, wants to try it
 out' person meets those requirements just fine. This person does not
 know what a 'KDE' is.

Then tell him.

Honestly, what kind of benefit to the community do you expect from a
user who gets confused just by looking at a couple nice screenshots
and reading some brief explanation? Have you ever met such a person
(incapable of understanding two sentences but useful to the
community)? Don't you think regarding your users this way a tad
disrespectful?

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop