Why are deltarpms missing in F-17 branched?

[Jonathan Dieter]

Deltarpms seem to be missing
from /fedora/linux/development/17/*/os/drpms

They are there for Rawhide, so I'm guessing it's a mash
misconfiguration, but I don't have the necessary rights to check.

Jonathan


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

Re: firewalld / iptables.service past F17

[Oron Peled]

On Monday, 23 בApril 2012 18:56:23 Reindl Harald wrote:
> Am 23.04.2012 17:32, schrieb Miloslav Trmač:
> > On Tue, Apr 17, 2012 at 10:40 PM, Reindl Harald  
wrote:
> >> http://fedoraproject.org/wiki/Features/firewalld-default
> >>
> >>> An explicit transition is planned after Fedora 18 with dropping support 
for the
> >>> static firewall with system-config-firewal/lokkit. A migration from the 
static
> >>> firewall model will be needed then.

Looks like this transition (as is currently planned) is going to
break many setups. I want to show the three following use-cases
which may be severely broken by this transition.

1. The simplest desktop case (firewalld is designed for such users).
   This is what I personally use on most of my desktops/laptops:

   * The user previously only used system-config-firewall (without
 custom rules -- we talk about simplest case)

   * The firewalld package does not even try to convert existing rules
 (just looked at the .spec file for the post*/pre*/trans*)

   * Results:
 - The user looses all her existing firewall settings without a warning
   (security).

 - If they had NAT (masquarading) -- pooof, no more Internet for you...

 - Almost all record of their previous settings is lost (sans .rpmsave)

 - If the poor user make another mistake (e.g: tries to re-install
   system-config-firewall), it may even clobber the .rpmsave
   [this is DATA-LOSS!]

2. Custom made firewall (e.g: hand-written script. I personally
   use this in rare/complex cases):

   * It obviously cannot be migrated automatically.

   * That's OK, as someone that can maintain the custom script, can
 migrate it manually.

   * But:
 - Just like item 1. above, we cannot take the risk that old
   data (e.g: existing /etc/sysconfig/iptables) would be somehow
   clobbered by install/upgrade/re-install of
   firewalld/system-config-firewall.
   [although the "customization" user is more likely to have backup
of said script, unlike the naive user from item 1.]

 - As others mentioned before, this use-case may contain features
   not (yet/ever?) in firewalld. So they need a (long-term) way
   to keep using their custom scripts (yes, even in F-21 unless
   by that time firewalld can have the full power of raw
   iptables script).
   [note: however, this use-case does *not* need system-config-firewall]

3. Complex firewall made by external tools (similar to 2.)
   My personal example is fwbuilder (packaged in Fedora):

   * I use it to centrally manage several firewalls

   * If firewalld becomes default after some upgrade, then:
 - Poof, some of these cannot be accessed (NAT...)

 - ... and alternative access (physical) is Hmmm problematic

 - I would call this super "uncool" (just a bit less uncool
   than the potential data-loss I mentioned before...)

Summary:
  * Regretfully, I think it's clear that firewalld as *default* is
a complete show-stopper (for now).

  * One (not hard) improvement is to preserve old data. E.g:
- During firewalld postinst (in install, upgrade is not
  the problem here), save a copy of all previous iptables
  config in a well defined location -- e.g:
   /etc/firewalld/old-iptables-data

- Make this data time-stamped to prevent overwriting in
  repeated (maybe mistaken) install/remove attempts. E.g:
   /etc/firewalld/.../2012-04-24_02-28/iptables
   /etc/firewalld/.../2012-04-24_02-28/iptables-config

- Also echo a message about it to stderr (I know its against
  the policy, but critical data-loss is more important IMO).

  * Try to migrate system-config-firewall data:
- That is harder, but even doing only the "no-custom-rules" case
  would prevent tons of problems for most (normal/naive) users.

- This would help even without/before firwalld is default.

  * Make installation/activate of firewalld optional even after
it is good enough to be default:
- Custom/complex setups will not be migrated (surely not before
  firewalld cannot cover the flexibility of raw iptables)

- So when people install servers, they may not want firewalld
  at all (regardless of system-config-firewall existance)

- Don't assume a "live-cd" is only used only for desktop installs.
  Many people (me included) install servers from a live-cd
  and add the rest later.

  Why? Because many times these are isolated servers (not on my
  kickstart-configured network), the live-cd image is smaller
  to download than a DVD, its already in my pocket on a DOK,
  etc, etc.

- So I think that even when firewalld is (eventually) good enough
  for a *default* install and even when system-config-firewall will
  already be a relic from the past -- we should allow power-users
  not to install it in the first place.

  I.e: it should be a *suggested* option.
  From a (future) UI per

Re: RFC: Primary architecture promotion requirements

[Matthew Garrett]

On Mon, Apr 23, 2012 at 10:08:54PM +, "Jóhann B. Guðmundsson" wrote:

> What is the justification for the need for the seperation in the firstplace?

You'd be fine with Fedora m68k? We have the separation because it's not 
just about scratching your own itch. Each additional supported 
architecture means that teams who are already overworked have to look 
after even more moving parts. Architecture-specific bugs are a pain for 
package maintainers to deal with. Attaching the Fedora name to poorly 
maintained ports weakens our brand. If we're going to support an 
architecture then its maintainers need to prove that they can maintain 
it.

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

Re: RFC: Primary architecture promotion requirements

[Jóhann B. Guðmundsson]

On 04/23/2012 09:07 PM, Bill Nottingham wrote:

Fedora's about providing a consistent experience wherever possible; this
means using consistent interactive installation tools


It's not enough to always be using the same tools but those tools need 
to be consitent in usage as well so for your noble goal now try putting 
consistency and Anaconda in the same sentence =)


All jokes aside and focusing on a bit more broader but fundemental 
question so I and perhaps some others can get a better understanding why 
things are as they are in the 21 first century.


Why do we distinquish between architectures in the first place and what 
do we hope to achive or otherwise gain from doing that in a community 
that first and foremost is about scratching your own itch ( at least for 
some of us )?


What is the justification for the need for the seperation in the firstplace?

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

Re: Recent Rawhide kernels unbootable?

[Jerry James]

On Mon, Apr 23, 2012 at 3:03 PM, Frank Murphy  wrote:
> Check your dracut version:
> https://bugzilla.redhat.com/show_bug.cgi?id=814625

That was the problem.  Thanks for the bug pointer.  After fixing the
path to udevd and regenerating the initramfs, the recent kernels are
booting.  Hurrah!
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[389-devel] Please review: Take 2: Ticket #347 - IPA dirsvr seg-fault during system longevity test

[Rich Megginson]

Ticket #347 - IPA dirsvr seg-fault during system longevity test

https://fedorahosted.org/389/attachment/ticket/347/0001-Ticket-347-IPA-dirsvr-seg-fault-during-system-longev.patch
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: RFC: Primary architecture promotion requirements

[Bill Nottingham]

"Jóhann B. Guðmundsson" (johan...@gmail.com) said: 
> On 04/23/2012 08:14 PM, Jared K. Smith wrote:
> >>>  Fesco is saying that if you have hardware that can install via Anaconda,
> >>>  you must support installing via Anaconda. It's legitimate for you to
> >>>  also have other install mechanisms, and hardware that's incapable of
> >>>  supporting Anaconda installs isn't required to have them.
> >Thanks for the clarification.  I just wanted to make sure I understood that.
> 
> FESCo should make that more clear in the requirements but even if
> they do they still make secondary architecture solely depended upon
> the will and the time of someone within the "Installer team" to
> implement the solution required to install Fedora for their
> architecture before they can become primary architecture.

There are these magical things called patches that can be submitted.
Much like the secondary arch team would need to do so for the kernel
(also mentioned in the guidelines), the X maintainers (also mentioned
in the guidelines), etc. Unless you're suggesting secondary arch
maintainers are somehow unable to do so?

Fedora's about providing a consistent experience wherever possible; this
means using consistent interactive installation tools, consistent image
creation tools, and so on.

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

Re: Recent Rawhide kernels unbootable?

[Frank Murphy]

On 23/04/12 20:34, Jerry James wrote:

I haven't been able to boot the last 3 Rawhide kernels,



Have I done something wrong, or are the recent kernels busted?


Check your dracut version:
https://bugzilla.redhat.com/show_bug.cgi?id=814625


--
Regards,
Frank
"Jack of all, fubars"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Matthew Garrett]

On Mon, Apr 23, 2012 at 08:57:47PM +, "Jóhann B. Guðmundsson" wrote:
> On 04/23/2012 08:14 PM, Jared K. Smith wrote:
> >>>  Fesco is saying that if you have hardware that can install via Anaconda,
> >>>  you must support installing via Anaconda. It's legitimate for you to
> >>>  also have other install mechanisms, and hardware that's incapable of
> >>>  supporting Anaconda installs isn't required to have them.
> >Thanks for the clarification.  I just wanted to make sure I understood that.
> 
> FESCo should make that more clear in the requirements but even if
> they do they still make secondary architecture solely depended upon
> the will and the time of someone within the "Installer team" to
> implement the solution required to install Fedora for their
> architecture before they can become primary architecture.

Yes, in the same way that they need someone in the kernel team to build 
them a kernel. It's a package. It's under active development. It just 
needs someone on the architecture to write the code.

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

Re: RFC: Primary architecture promotion requirements

[Jóhann B. Guðmundsson]

On 04/23/2012 08:14 PM, Jared K. Smith wrote:

>  Fesco is saying that if you have hardware that can install via Anaconda,
>  you must support installing via Anaconda. It's legitimate for you to
>  also have other install mechanisms, and hardware that's incapable of
>  supporting Anaconda installs isn't required to have them.

Thanks for the clarification.  I just wanted to make sure I understood that.


FESCo should make that more clear in the requirements but even if they 
do they still make secondary architecture solely depended upon the will 
and the time of someone within the "Installer team" to implement the 
solution required to install Fedora for their architecture before they 
can become primary architecture.


That can mean from never to having to wait for several release cycles 
before becoming primary architecture for the distribution.


From my point of view that makes absolutly no sense and the 
requirements should be refactored to require an working installation 
method...


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

Re: Recent Rawhide kernels unbootable?

[Richard W.M. Jones]

On Mon, Apr 23, 2012 at 01:34:04PM -0600, Jerry James wrote:
> I haven't been able to boot the last 3 Rawhide kernels,
> kernel-3.4.0-0.rc3.gitX.1.fc18.x86_64, where X = 2, 3, 4.  The kernel
> with X = 1 boots fine.  When I try to boot the other 3, I get dropped
> into a debug shell with dracut complaining about being unable to find
> various devices.  Today I got around to trying to figure out why.
> Manually running "new-kernel-pkg --package kernel --mkinitrd --dracut
> --depmod --update 3.4.0-0.rc3.git4.1.fc18.x86_64" spewed a large
> number of lines like this:
> 
> WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/802/psnap.ko
> needs unknown symbol llc_sap_close
> WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/802/psnap.ko
> needs unknown symbol llc_sap_open
> WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/802/stp.ko
> needs unknown symbol llc_sap_close
> WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/802/stp.ko
> needs unknown symbol llc_sap_open
> WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/802/garp.ko
> needs unknown symbol llc_mac_hdr_init
> WARNING: 
> /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/bridge/bridge.ko
> needs unknown symbol llc_mac_hdr_init
> 
> In the working kernel (X = 1), these symbols are provided by
> /lib/modules/3.4.0-0.rc3.git1.1.fc18.x86_64/kernel/net/llc/llc.ko.  On
> the broken kernels, the llc directory is still there, but it is empty.
>  What happened to the llc module?  The pps_core module
> (kernel/drivers/pps/pps_core.ko) has also gone missing in the more
> recent kernels, accounting for still more unknown symbols.  I ran "rpm
> -V" on the recent kernel packages and just got the expected:
> 
> ...T./lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/modules.devname
> ...T./lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/modules.softdep
> 
> Have I done something wrong, or are the recent kernels busted?

I built libguestfs today, which as part of the Koji build will boot
and run the current kernel.  It *didn't* fail, indicating that the
kernel is good.  Here are the build logs if you want to look further:

http://kojipkgs.fedoraproject.org/packages/libguestfs/1.17.33/1.fc18/data/logs/x86_64/

(It might just be a problem confined to 802.x and bridge devices,
which we don't test.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Matthew Garrett]

On Mon, Apr 23, 2012 at 08:29:59PM +, "Jóhann B. Guðmundsson" wrote:
> On 04/23/2012 07:45 PM, Bill Nottingham wrote:
> >We shouldn't be promoting anything to primary arch that you can't install.
> 
> Valid point but it still does not explain why FESCo chose to limit
> that exclusively to Anaconda and the "Installer team" and their
> installation methods or lack there of.

ARM is moving into the server and laptop space. There's an expectation 
that devices of that nature can be installed using Anaconda. If a port 
is only supporting embedded devices where Anaconda makes no sense then 
that's fine, but if it's supporting other hardware classes then it needs 
to have a working Anaconda. I've no idea why this is controversial.

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

Re: RFC: Primary architecture promotion requirements

[Jóhann B. Guðmundsson]

On 04/23/2012 07:45 PM, Bill Nottingham wrote:

We shouldn't be promoting anything to primary arch that you can't install.


Valid point but it still does not explain why FESCo chose to limit that 
exclusively to Anaconda and the "Installer team" and their installation 
methods or lack there of.



Sorry guys your arch will have to wait to become primary until Anaconda 
and the "Installer team" has


a) Decided
b) Designed
c) Implemented

How to install your arch.



But our user base already can install via this method here and we 
actually preferred they did..



Sorry no flag no country those are the rules so if you want to sail 
under the Fedora flag you have to ride the snake...


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

Re: RFC: Primary architecture promotion requirements

[Jon Ciesla]

On Mon, Apr 23, 2012 at 3:13 PM, Jared K. Smith
 wrote:
> On Mon, Apr 23, 2012 at 3:42 PM, Matthew Garrett  wrote:
>> Because if you have hardware that can install via Anaconda and you don't
>> support installing via Anaconda, you're not Fedora.
>
> Just for the sake of argument, our Amazon EC2 images aren't using
> Anaconda for installation, but they're still considered part of
> Fedora.

I think that's more akin to a spin.

> I agree with the sentiment that Anaconda should be a requirement for
> instances where it makes sense to boot from bootable media
> (DVD/CD/USB) and install via Anaconda, but in the case of ARM, the
> traditional installation method is often "copy an image to an SD (or
> micro-SD) card and then boot from that card.  Just to make sure I'm
> clear, are you insisting that the software tool that puts the image on
> the SD card be Anaconda, or are you OK with some other Fedora-approved
> tool for doing so?
>
> --
> Jared Smith
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel



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

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

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

Re: GPT

[Nikos Roussos]

On Apr 23, 2012 1:12 AM, "Chris Murphy"  wrote:
>
> On Apr 22, 2012, at 2:55 PM, Nikos Roussos wrote:
> > I already have a GPT partition (from my previous installation), but
> > Anaconda complains that my boot partition should be of type msdos. The
> > only way to proceed seems to be discarding all partitions and creating
> > an msdos partition table.
>
> Well that's kinda unfortunate behavior. I think the blacklist should
cause just "Use All Space" to force a new or existing GPT to be MBR. But
really, I've advocated the exact opposite you are, which is I think BIOS
hardware with disks < 2TB should default to MBR, not GPT. There's minimal
advantage, and more trouble.
>
> However, if you're really committed to GPT, convert the MBR to GPT using
gdisk after the fact. I suggest custom partitioning to reserve 1MB
unallocated. Post install, gdisk to add a BIOS Boot partition, gdisk type
code 0xEF02. Then when you reinstall GRUB2, it will automatically stuff
core.img in it.

Well.. considering that I have no special reason to want GPT, I guess it's
easier to go with the Msdos partition table. It's just that it surprises me
that there is no obvious way to override the default Anaconda behaviour
within the installation DVD, since my laptop supports GPT.

My previous installation, where GPT worked just fine, was done with F16
Beta, so maybe at the time Lenovos were not blacklisted yet.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GitHub is a terrible upstream

[Josh Stone]

On 04/23/2012 01:08 PM, Orion Poplawski wrote:
> Nice!  I'll note explicitly that this also works with short git tags, so:
> 
> 
> %global commit bd245c9
> 
> Source0: 
> https://github.com/jukka/pcfi/tarball/%{commit}/jukka-pcfi-%{commit}.tar.gz
> 
> %setup -q -n jukka-pcfi-%{commit}
> 
> works.

Even if that works, it has the potential for collision on some future
date, when that hash prefix is no longer unique.  I see no reason to
prefer brevity here.

Josh

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

Re: RFC: Primary architecture promotion requirements

[Jared K. Smith]

On Mon, Apr 23, 2012 at 4:00 PM, Matthew Garrett  wrote:
> Fesco is saying that if you have hardware that can install via Anaconda,
> you must support installing via Anaconda. It's legitimate for you to
> also have other install mechanisms, and hardware that's incapable of
> supporting Anaconda installs isn't required to have them.

Thanks for the clarification.  I just wanted to make sure I understood that.

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

Re: RFC: Primary architecture promotion requirements

[Jared K. Smith]

On Mon, Apr 23, 2012 at 3:42 PM, Matthew Garrett  wrote:
> Because if you have hardware that can install via Anaconda and you don't
> support installing via Anaconda, you're not Fedora.

Just for the sake of argument, our Amazon EC2 images aren't using
Anaconda for installation, but they're still considered part of
Fedora.

I agree with the sentiment that Anaconda should be a requirement for
instances where it makes sense to boot from bootable media
(DVD/CD/USB) and install via Anaconda, but in the case of ARM, the
traditional installation method is often "copy an image to an SD (or
micro-SD) card and then boot from that card.  Just to make sure I'm
clear, are you insisting that the software tool that puts the image on
the SD card be Anaconda, or are you OK with some other Fedora-approved
tool for doing so?

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

Re: GitHub is a terrible upstream

[Orion Poplawski]

On 04/23/2012 11:21 AM, Patrick Monnerat wrote:

On Mon, 2012-04-23 at 14:27 +0100, Adam Williamson wrote:

On Fri, 2012-04-20 at 20:51 -0700, Eric Smith wrote:

Corey Richardson wrote:

Getting source tarballs from github is a nightmare. See
http://lists.fedoraproject.org/pipermail/devel/2011-February/148676.html


I noticed putting what you want after .../tarball/ has no effect,
thus I have good results by using URLs like:

https://github.com/user/app/tarball/gittag/user-app-gittag.tar.gz

where user and app identify the repository target and gittag is the hex
code of the desired commit. This satisfies rpmbuild and the URL is
valid.

The downloaded tar contains everything under directory user-app-gittag.

Of course, this works as long as the target data (i.e.: repository)
lives on github :-/

Patrick



Nice!  I'll note explicitly that this also works with short git tags, so:


%global commit bd245c9

Source0: 
https://github.com/jukka/pcfi/tarball/%{commit}/jukka-pcfi-%{commit}.tar.gz


%setup -q -n jukka-pcfi-%{commit}

works.

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

[perl-AnyEvent] Disable SSL test

[Nicolas Chauvet]

commit e58dcc0ba811fc69b59dbd9efca083f806f2d08b
Author: Nicolas Chauvet 
Date:   Mon Apr 23 22:04:27 2012 +0200

Disable SSL test

 perl-AnyEvent.spec |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
---
diff --git a/perl-AnyEvent.spec b/perl-AnyEvent.spec
index bd55c12..242e4a2 100644
--- a/perl-AnyEvent.spec
+++ b/perl-AnyEvent.spec
@@ -18,7 +18,6 @@ BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(EV)
 # Needed for test
 BuildRequires:  perl(Test::Simple)
-BuildRequires:  perl(Net::SSLeay)
 
 # RPM 4.8 style
 %{?filter_setup:
--
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: RFC: Primary architecture promotion requirements

[Matthew Garrett]

On Mon, Apr 23, 2012 at 07:54:57PM +, "Jóhann B. Guðmundsson" wrote:
> On 04/23/2012 07:42 PM, Matthew Garrett wrote:
> >Because if you have hardware that can install via Anaconda and you don't
> >support installing via Anaconda, you're not Fedora.
> So FESCo is in otherwords saying that other installers and even
> installing methods ( think like the distribution would be flashed to
> a device in the maybe not to distant future instead of being
> installed in the traditional sense as we know it to be ) are not
> allowed or otherwise considered to be part of the distribution
> should some community members want to writer and or package an
> alternative installer to ship and use on their spin?

Fesco is saying that if you have hardware that can install via Anaconda, 
you must support installing via Anaconda. It's legitimate for you to 
also have other install mechanisms, and hardware that's incapable of 
supporting Anaconda installs isn't required to have them.

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

Re: RFC: Primary architecture promotion requirements

[Brendan Conoboy]

On 04/23/2012 12:54 PM, "Jóhann B. Guðmundsson" wrote:

So FESCo is in otherwords saying that other installers and even
installing methods ( think like the distribution would be flashed to a
device in the maybe not to distant future instead of being installed in
the traditional sense as we know it to be ) are not allowed or otherwise
considered to be part of the distribution should some community members
want to writer and or package an alternative installer to ship and use
on their spin?


It's not about anaconda specifically, it's about having a standard 
installer experience across all PAs to the extent technically sensible. 
 Maybe something else will supplant anaconda in time.


--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jon Ciesla]

2012/4/23 "Jóhann B. Guðmundsson" :
> On 04/23/2012 07:42 PM, Matthew Garrett wrote:
>>
>> Because if you have hardware that can install via Anaconda and you don't
>> support installing via Anaconda, you're not Fedora.
>
> So FESCo is in otherwords saying that other installers and even installing
> methods ( think like the distribution would be flashed to a device in the
> maybe not to distant future instead of being installed in the traditional
> sense as we know it to be ) are not allowed or otherwise considered to be
> part of the distribution should some community members want to writer and or
> package an alternative installer to ship and use on their spin?

I think it wasn't so much forbidding alternate methods as requiring
that the primary one be supported.

-J

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



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

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

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

Re: RFC: Primary architecture promotion requirements

[Jóhann B. Guðmundsson]

On 04/23/2012 07:42 PM, Matthew Garrett wrote:

Because if you have hardware that can install via Anaconda and you don't
support installing via Anaconda, you're not Fedora.
So FESCo is in otherwords saying that other installers and even 
installing methods ( think like the distribution would be flashed to a 
device in the maybe not to distant future instead of being installed in 
the traditional sense as we know it to be ) are not allowed or otherwise 
considered to be part of the distribution should some community members 
want to writer and or package an alternative installer to ship and use 
on their spin?


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

[389-devel] Please review: [389 Project] #19: Convert entryUSN plugin to transaction aware type

[Noriko Hosoi]

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

https://fedorahosted.org/389/attachment/ticket/19/0001-Trac-Ticket-19-Convert-entryUSN-plugin-to-transactio.patch

 Fix description:
 * Separated usn_bepreop operations from usn_betxnpreop operations.
   usn_bepreop_modify and _modrdn add "entryusn: #" to the mods,
   which should be handled before the transaction starts.
 * Introduced SLAPI_PLUGIN_BE_TXN_PRE_DELETE_TOMBSTONE_FN plugin
   hook to modify the tombstone entry at the betxn timing.
 * Eliminated preventryusn (SLAPI_ATTR_ENTRYUSN_PREV). It was used
   to undo the incremented entryusn when the deletion fails.
   Since the operation is now executed in the transaction and it
   is aborted if the operation fails, the explicit undo is not
   needed in the usn postop.


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

[perl-AnyEvent] Fix provides

[Nicolas Chauvet]

commit 3349c0f34bf8f07b5aa60e4429a2d21d81bc89af
Author: Nicolas Chauvet 
Date:   Mon Apr 23 21:55:20 2012 +0200

Fix provides

 perl-AnyEvent.spec |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
---
diff --git a/perl-AnyEvent.spec b/perl-AnyEvent.spec
index 2f55c4c..bd55c12 100644
--- a/perl-AnyEvent.spec
+++ b/perl-AnyEvent.spec
@@ -18,11 +18,12 @@ BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(EV)
 # Needed for test
 BuildRequires:  perl(Test::Simple)
+BuildRequires:  perl(Net::SSLeay)
 
 # RPM 4.8 style
 %{?filter_setup:
 %filter_from_requires /perl(Tk)/d; /perl(EV)/d; /perl(Irssi)/d; /perl(Qt/d; 
/perl(IO::Async::Loop/d; /perl(AnyEvent::Impl::Qt/d; /perl(FLTK/d; 
/perl(Cocoa/d;
-%filter_from_provides /perl(AnyEvent::Impl::Qt/d /perl(AnyEvent::Impl::Cocoa/d
+%filter_from_provides /perl(AnyEvent::Impl::Cocoa/d
 %filter_setup
 }
 # RPM 4.9 style
--
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: Recent Rawhide kernels unbootable?

[Josh Boyer]

On Mon, Apr 23, 2012 at 3:34 PM, Jerry James  wrote:
> I haven't been able to boot the last 3 Rawhide kernels,
> kernel-3.4.0-0.rc3.gitX.1.fc18.x86_64, where X = 2, 3, 4.  The kernel
> with X = 1 boots fine.  When I try to boot the other 3, I get dropped
> into a debug shell with dracut complaining about being unable to find
> various devices.  Today I got around to trying to figure out why.
> Manually running "new-kernel-pkg --package kernel --mkinitrd --dracut
> --depmod --update 3.4.0-0.rc3.git4.1.fc18.x86_64" spewed a large
> number of lines like this:
>
> WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/802/psnap.ko
> needs unknown symbol llc_sap_close



> Have I done something wrong, or are the recent kernels busted?

There was a change in how modules were put into the -modules-extra
subpackage with those 3 builds.  It has since been fixed.

However, unless you needed those modules for booting for some
reason, I doubt that is actually the problem.

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

Re: RFC: Primary architecture promotion requirements

[Bill Nottingham]

"Jóhann B. Guðmundsson" (johan...@gmail.com) said: 
> On 04/23/2012 07:00 PM, Matthew Garrett wrote:
> >After some tweaking, these are now accepted as
> >https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements
> >
> 
> Fail to see the reasoning why Anaconda and the "Installer team" are
> involved in these requirements care to elaborate how/why FESCo fits
> them into the bigger picture?

We shouldn't be promoting anything to primary arch that you can't install.

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

Re: RFC: Primary architecture promotion requirements

[Matthew Garrett]

On Mon, Apr 23, 2012 at 07:33:44PM +, "Jóhann B. Guðmundsson" wrote:
> On 04/23/2012 07:00 PM, Matthew Garrett wrote:
> >After some tweaking, these are now accepted as
> >https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements
> >
> 
> Fail to see the reasoning why Anaconda and the "Installer team" are
> involved in these requirements care to elaborate how/why FESCo fits
> them into the bigger picture?

Because if you have hardware that can install via Anaconda and you don't 
support installing via Anaconda, you're not Fedora.

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

Re: RFC: Primary architecture promotion requirements

[Jóhann B. Guðmundsson]

On 04/23/2012 07:00 PM, Matthew Garrett wrote:

After some tweaking, these are now accepted as
https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements



Fail to see the reasoning why Anaconda and the "Installer team" are 
involved in these requirements care to elaborate how/why FESCo fits them 
into the bigger picture?


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

Recent Rawhide kernels unbootable?

[Jerry James]

I haven't been able to boot the last 3 Rawhide kernels,
kernel-3.4.0-0.rc3.gitX.1.fc18.x86_64, where X = 2, 3, 4.  The kernel
with X = 1 boots fine.  When I try to boot the other 3, I get dropped
into a debug shell with dracut complaining about being unable to find
various devices.  Today I got around to trying to figure out why.
Manually running "new-kernel-pkg --package kernel --mkinitrd --dracut
--depmod --update 3.4.0-0.rc3.git4.1.fc18.x86_64" spewed a large
number of lines like this:

WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/802/psnap.ko
needs unknown symbol llc_sap_close
WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/802/psnap.ko
needs unknown symbol llc_sap_open
WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/802/stp.ko
needs unknown symbol llc_sap_close
WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/802/stp.ko
needs unknown symbol llc_sap_open
WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/802/garp.ko
needs unknown symbol llc_mac_hdr_init
WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/bridge/bridge.ko
needs unknown symbol llc_mac_hdr_init

In the working kernel (X = 1), these symbols are provided by
/lib/modules/3.4.0-0.rc3.git1.1.fc18.x86_64/kernel/net/llc/llc.ko.  On
the broken kernels, the llc directory is still there, but it is empty.
 What happened to the llc module?  The pps_core module
(kernel/drivers/pps/pps_core.ko) has also gone missing in the more
recent kernels, accounting for still more unknown symbols.  I ran "rpm
-V" on the recent kernel packages and just got the expected:

...T./lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/modules.devname
...T./lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/modules.softdep

Have I done something wrong, or are the recent kernels busted?
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GitHub is a terrible upstream

[Ville Skyttä]

On 2012-04-23 20:56, Orion Poplawski wrote:
> My problem is I'm wedded to spectool -g and it doesn't use
> --content-disposition.  Would it be safe to have spectool always use
> that option?
No, because the Content-Disposition header from the server may result in
changing the downloaded file's name to something else than what its
"basename" in the URL is, and that won't work with rpmbuild.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Matthew Garrett]

After some tweaking, these are now accepted as 
https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements

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

Re: GitHub is a terrible upstream

[Andy Grover]

On 04/23/2012 10:48 AM, Adam Williamson wrote:
> On Mon, 2012-04-23 at 10:37 -0700, Andy Grover wrote:
> 
>> "wget --content-disposition https://github.com/$user/$project/tarball/$tag";
>>
>> lets you download a tarball named $user-$project-$tag-0-$gitsha1.tar.gz.
>> That saves the maintainer from having to document how to generate the
>> tarball, in exchange for dealing with a tarball name that contains
>> random content (the sha1). The path of files in the tarball also
>> contains the sha1.
>>
>> Even so, this still seems preferable to me than making packagers
>> generate the tarball each time and document the process, which seems
>> very prone to error.
> 
> Yup, if that's reliable, it's certainly superior. Thanks!

Here's what I've come up with so far for a pkg I'm working on. This is
to deal with the resulting source file name not matching the %{source}
URL when using --content-disposition:

Name:   python-symmetric-jsonrpc
...
Version:0.1
Release:1%{?dist}
URL:https://github.com/niligulmohar/%{name}/
Source:
https://github.com/niligulmohar/%{name}/tarball/release-%{version}
# using wget --content-disposition %{source} yields this filename:
Source1:niligulmohar-%{name}-release-%{version}-0-g0599f28.tar.gz

...
%prep
%setup -q -T -b 1 -n niligulmohar-%{name}-06189d9

Any further recommendations?

Thanks -- Andy

p.s. tried editing the wiki but didn't have privs, so may need to defer
to an admin once we figure out the best github hack^Wprocedure.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Summary/Minutes from today's FESCo Meeting (2012-04-23)

[Matthew Garrett]

===
#fedora-meeting: FESCO (2012-04-23)
===


Meeting started by mjg59 at 17:00:08 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-04-23/fesco.2012-04-23-17.00.log.html
.



Meeting summary
---
* init process  (mjg59, 17:00:08)

* #829 New proven packagers request: Pavel Alexeev (hubbitus)
  .fesco 829  (mjg59, 17:02:29)

* #838 https://fedoraproject.org/wiki/Features/firewalld-default
  status  (mjg59, 17:03:01)
  * AGREED: Feature should be deferred to F18, appropriate changes made
to F17 (+7, -0)  (mjg59, 17:36:45)

* #839 Proposal for revitalizing the packager sponsorship model
  (mjg59, 17:37:50)
  * AGREED: Raise proposal on devel@, bring it back to fesco once
there's been wider discussion  (mjg59, 17:47:08)

* #830 define requirements for secondary arch promotion  (mjg59,
  17:47:32)
  * LINK:

http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29
(mjg59, 17:49:08)
  * AGREED: Secondary architecture promotion requirements are approved,
we'll continue followup discussions with secondary architectures
over plans to implement them  (mjg59, 18:15:20)

* Next week's chair  (mjg59, 18:17:02)
  * AGREED: limburgher chairs next week  (mjg59, 18:19:11)

* Open Floor  (mjg59, 18:19:15)

Meeting ended at 18:22:00 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* mjg59 (116)
* mitr (56)
* nirik (48)
* jonmasters (42)
* pjones (41)
* twoerner (33)
* notting (30)
* sgallagh (29)
* limburgher (24)
* tibbs (20)
* t8m (16)
* bconoboy (12)
* zodbot (9)
* mmaslano (7)
* jwb (4)
* adamw (3)
* gholms (3)
* cmurf (1)
* pknirsch (1)


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

Re: GitHub is a terrible upstream

[Orion Poplawski]

On 04/23/2012 11:37 AM, Andy Grover wrote:

"wget --content-disposition https://github.com/$user/$project/tarball/$tag";

lets you download a tarball named $user-$project-$tag-0-$gitsha1.tar.gz.
That saves the maintainer from having to document how to generate the
tarball, in exchange for dealing with a tarball name that contains
random content (the sha1). The path of files in the tarball also
contains the sha1.

Even so, this still seems preferable to me than making packagers
generate the tarball each time and document the process, which seems
very prone to error.

Regards -- Andy

ps btw that wget w/o --content-disposition gets you a tarball named $tag.
pps I both package and maintain upstream code in github, guidelines on
the wiki would be great.


My problem is I'm wedded to spectool -g and it doesn't use 
--content-disposition.  Would it be safe to have spectool always use that option?


--
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: GitHub is a terrible upstream

[Adam Williamson]

On Mon, 2012-04-23 at 10:37 -0700, Andy Grover wrote:

> "wget --content-disposition https://github.com/$user/$project/tarball/$tag";
> 
> lets you download a tarball named $user-$project-$tag-0-$gitsha1.tar.gz.
> That saves the maintainer from having to document how to generate the
> tarball, in exchange for dealing with a tarball name that contains
> random content (the sha1). The path of files in the tarball also
> contains the sha1.
> 
> Even so, this still seems preferable to me than making packagers
> generate the tarball each time and document the process, which seems
> very prone to error.

Yup, if that's reliable, it's certainly superior. Thanks!
-- 
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: usrmove breaks on directory name conflict

[Kevin Kofler]

Sérgio Basto wrote:
> you should open a bug report in rhbz , with component preupgrade .

Isn't the usrmove script actually part of dracut?

Kevin Kofler

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

[389-devel] revised ticket #337 - improve CLEANRUV functionality

[Mark Reynolds]

Thanks Rich and Noriko for your comments, changes applied...

Thanks,
Mark

 Original Message 
Subject: 	[389-devel] please review ticket #337 - improve CLEANRUV 
functionality

Date:   Fri, 20 Apr 2012 13:05:00 -0400
From:   Mark Reynolds 
Reply-To: 	389 Directory server developer discussion. 
<389-de...@lists.fedoraproject.org>
To: 	389 Directory server developer discussion. 
<389-de...@lists.fedoraproject.org>




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

https://fedorahosted.org/389/attachment/ticket/337/0001-Ticket-337-RFE-Improve-CLEANRUV-functionality.patch

Previously the steps to remove a replica and its RUV was problematic. I 
created two new "tasks" to take care of the entire replication environment.


[1] The new task "CLEANALLRUV" - run it once on any master

 * This marks the rid as invalid. Used to reject updates to the
   changelog, and the database RUV
 * It then sends a "CLEANRUV" extended operation to each agreement.
 * Then it cleans its own RUV.

 * The CLEANRUV extended op then triggers that replica to send the same
   CLEANRUV extop to its replicas, then it cleans its own RID.
   Basically this operation cascades through the entire replication
   environment.

[2] The "RELEASERUV" task - run it once on any master

 * Once the RUV's have been cleaned on all the replicas, you need to
   "release" the rid so that it can be reused. This operation also
   cascades through the entire replication environment. This also
   triggers changelog trimming.

For all of this to work correctly, there is a list of steps that needs 
to be followed. This procedure is attached to the ticket.


https://fedorahosted.org/389/attachment/ticket/337/cleanruv-proceedure

Thanks,
Mark

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

Re: GitHub is a terrible upstream

[Andy Grover]

On 04/23/2012 06:27 AM, Adam Williamson wrote:
> On Fri, 2012-04-20 at 20:51 -0700, Eric Smith wrote:

>> #!/bin/sh
>> # usage: tcplay-get-snapshot.sh 
>> git clone git://github.com/bwalex/tc-play
>> ( cd tc-play && \
>>git archive --format=tar --prefix=tcplay-$1/ $1 \
>> ) | xz - >tcplay-$1.tar.xz
> 
> We could probably add something like this to the 'snippets' bit of the
> packaging guidelines, since github is pretty significant. Just to try
> and help packagers do it in a uniform and guideline-complaint way.
> 
> As a reminder for packagers following the thread - any time you have to
> 'generate' a source tarball like this (i.e. it is not possible to
> provide a Source: URL that can be expected to remain valid), you should
> ensure the tarball is reliably reproducible by others and include all
> necessary instructions to produce it, using comments in the .spec file
> and/or a script like Eric's - so if you wanted to use Eric's script, you
> should ensure you actually check the script itself into git (and
> probably cite it as a Source itself, so it winds up in the .src.rpm),
> then have a comment in the .spec file which specifies the invocation of
> the script that was used to generate the source tarball.

"wget --content-disposition https://github.com/$user/$project/tarball/$tag";

lets you download a tarball named $user-$project-$tag-0-$gitsha1.tar.gz.
That saves the maintainer from having to document how to generate the
tarball, in exchange for dealing with a tarball name that contains
random content (the sha1). The path of files in the tarball also
contains the sha1.

Even so, this still seems preferable to me than making packagers
generate the tarball each time and document the process, which seems
very prone to error.

Regards -- Andy

ps btw that wget w/o --content-disposition gets you a tarball named $tag.
pps I both package and maintain upstream code in github, guidelines on
the wiki would be great.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Package libsmbclient needs to be rebuild against new samba4-common

[Kevin Kofler]

Kalev Lember wrote:
> It's your call to make, but I wouldn't base the decision on whether it
> was in stable updates or updates-testing.

There is no expectation of upgrade path for updates-testing.

> Both are currently enabled by default in F17.

And that's where the problem really lies.

Kevin Kofler


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

Re: GitHub is a terrible upstream

[Patrick Monnerat]

On Mon, 2012-04-23 at 14:27 +0100, Adam Williamson wrote: 
> On Fri, 2012-04-20 at 20:51 -0700, Eric Smith wrote:
> > Corey Richardson wrote:
> > > Getting source tarballs from github is a nightmare. See
> > > http://lists.fedoraproject.org/pipermail/devel/2011-February/148676.html

I noticed putting what you want after .../tarball/ has no effect,
thus I have good results by using URLs like:

https://github.com/user/app/tarball/gittag/user-app-gittag.tar.gz

where user and app identify the repository target and gittag is the hex
code of the desired commit. This satisfies rpmbuild and the URL is
valid.

The downloaded tar contains everything under directory user-app-gittag.

Of course, this works as long as the target data (i.e.: repository)
lives on github :-/

Patrick

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

Outage: fedorahosted.org - 2012-04-25 21:00 UTC

[Kevin Fenzi]

Outage: fedorahosted.org - 2012-04-25 21:00 UTC

There will be an outage starting at 2012-04-25 21:00 UTC, which will
last approximately 2 hours.

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

date -d ' 2012-04-25 21:00 UTC'

Reason for outage:

We are finally ready to move fedorahosted to a new pair of machines.
This should balance load out over 2 nodes instead of the current single
node, and allow smooth reboots of nodes. Data will be replicated with
the help of glusterfs.

Affected Services:

Fedora Hosted -  https://fedorahosted.org/

Unaffected Services:

Ask Fedora -  http://ask.fedoraproject.org/

BFO -  http://boot.fedoraproject.org/

Bodhi -  https://admin.fedoraproject.org/updates/

Buildsystem -  http://koji.fedoraproject.org/

GIT / Source Control

DNS - ns1.fedoraproject.org, ns2.fedoraproject.org

Docs -  http://docs.fedoraproject.org/

Email system

Fedora Account System -  https://admin.fedoraproject.org/accounts/

Fedora Community -  https://admin.fedoraproject.org/community/

Fedora Insight -  https://insight.fedoraproject.org/

Fedora People -  http://fedorapeople.org/

Main Website -  http://fedoraproject.org/

Mirror List -  https://mirrors.fedoraproject.org/

Mirror Manager -  https://admin.fedoraproject.org/mirrormanager/

Package Database -  https://admin.fedoraproject.org/pkgdb/

QA Services

Secondary Architectures

Smolt -  http://smolts.org/

Spins -  http://spins.fedoraproject.org/

Start -  http://start.fedoraproject.org/

Torrent -  http://torrent.fedoraproject.org/

Wiki -  http://fedoraproject.org/wiki/

Ticket Link:  https://fedorahosted.org/fedora-infrastructure/ticket/3250

Contact Information:

Please join #fedora-admin or #fedora-noc on irc.freenode.net or add
comments to the ticket for this outage above.


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

Re: firewalld / iptables.service past F17

[Reindl Harald]

Am 23.04.2012 17:32, schrieb Miloslav Trmač:
> On Tue, Apr 17, 2012 at 10:40 PM, Reindl Harald  
> wrote:
>> http://fedoraproject.org/wiki/Features/firewalld-default
>>
>>> An explicit transition is planned after Fedora 18 with dropping support for 
>>> the
>>> static firewall with system-config-firewal/lokkit. A migration from the 
>>> static
>>> firewall model will be needed then.
>>
>> are there only the ui-interfaces meant or do someone
>> consider drop "iptbales.service" at all? if so please
>> re-consider this!
> 
> I was pushing for the deprecation to avoid a NetworkManager-like
> duplication for the long term.

i really, really like the idea of "firewalld" for many setups!
it is a really nice improvement for desktops over the long

but please consider that network-manager and desktop is not
all and on servers with vpn-gateways, routings and such
things you do not really like it

please do not start seeing linux as desktop-only OS, it is not
cool that it works for desktops and servers and this should
be considered in big changes

> AFAICS you can s/iptables/firewall-cmd --direct --passthrough ipv4/,
> and things should continue to work (perhaps with minor modifications
> to avoid collisions with firewalld's default rule chains).

i simply do not need want any default chains
the first in a iptables-script is reset them

the iptables.sh for the environment where i work is currently
50 KB large, distributed and for all machines in the network
the same

> Or, if you insist, disable firewalld (... which might break some
> applications), and turn your shell script into a systemd service; but
> --direct --passthrough should be the preferred route.

how to replace such things?

cat /etc/sysconfig/iptables-config
IPTABLES_MODULES="ip_nat_sip ip_nat_ftp nf_conntrack_ftp nf_nat_ftp"


cat /etc/sysconfig/iptables-config
IPTABLES_MODULES="nf_conntrack_ftp  nf_nat_ftp"

cat /etc/modprobe.d/local.conf
options nf_conntrack_ftp ports=21,4559
options ipt_recent ip_list_tot=5000 ip_pkt_list_tot=200




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

Re: Fedora 17 Beta Observations

[Mark Bidewell]

>
>
> OK, so Mark, it looks like we need you to file a bug on the segfault you
> hit when trying to run anaconda with the vmwlegacy driver (as long as
> I'm interpreting the log right). Can you do that and link to the bug?
> Thanks!
> --
> 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
>

The bug is reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=815467

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

Re: usrmove breaks on directory name conflict

[Sérgio Basto]

On Mon, 2012-04-23 at 09:45 -0600, Daniel Drake wrote: 
> Hi,
> 
> Last week I tried a preupgrade from F16 to F17 beta.
> 
> When rebooting into the preupgrade environment, the upgrade failed in usrmove:
> 
> Make a copy of /mnt/sysimage/usr/bin
> Merge the copy with /mnt/sysimage/bin
> cp: cannot overwrite directory /mnt/sysimage/usr/bin.usrmove-new/mkdir
> with non-directory
> Something failed. Move back to the original state.
> 
> 
> Rebooted back into F16. It looks like the issue was that I had a
> directory at "/usr/bin/mkdir/". No idea how, looks like it was from
> December. Probably my fault, but perhaps usrmove shouldn't fall over
> when facing this situation.
> 
> After removing that weird directory, I rebooted into preupgrade and it
> worked fine. Now running F17 beta.

you should open a bug report in rhbz , with component preupgrade .  

Tks, 
-- 
Sérgio M. B.

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

Re: usrmove breaks on directory name conflict

[Michal Schmidt]

On 04/23/2012 05:45 PM, Daniel Drake wrote:

cp: cannot overwrite directory /mnt/sysimage/usr/bin.usrmove-new/mkdir
with non-directory
Something failed. Move back to the original state.


Rebooted back into F16. It looks like the issue was that I had a
directory at "/usr/bin/mkdir/". No idea how, looks like it was from
December. Probably my fault, but perhaps usrmove shouldn't fall over
when facing this situation.


If usrmove really reverted everything to its original state, it seems to 
me like a case of well-behaving error handling after encountering an 
unusual situation that cannot be resolved automatically and safely.


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

Re: Reviving podcatcher

[goeran]

Jon Ciesla:
> If it's been retired more than two weeks, it'll need a new review.

Ah!  Looking closer I now see the rawhide branch says "deprecated"
rather than "orphaned".  That explains it.

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

Re: Fedora 18 Release name voting and Poll for whether to continue naming releases

[Przemek Klosowski]

On 04/23/2012 11:50 AM, Tomas Radej wrote:


I think numbering/naming problem is only about the target audience.
If Non-geek users tend to stick with names (Karmic Koala,
Gingerbread, Belle) and devs/powerusers prefer numbering, what's the
problem? I don't see much confusion about naming and numbering on the
message boards.


I think it's the other way around---geeks get excited about clever 
names, and Aunt Tillie uses Fedora 12 :)

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

Re: Fedora 17 Beta Observations

[Adam Williamson]

On Mon, 2012-04-23 at 11:33 -0400, Adam Jackson wrote:
> On Mon, 2012-04-23 at 14:02 +0100, Adam Williamson wrote:
> > On Thu, 2012-04-19 at 21:32 -0400, Mark Bidewell wrote:
> > > 
> > > 
> > > On Thu, Apr 19, 2012 at 2:23 PM, Adam Williamson 
> > > wrote:
> > > On Thu, 2012-04-19 at 07:29 -0400, Mark Bidewell wrote:
> > > > The VM I used had 1GB of memory.
> > 
> > > Does the 'basic graphics mode' option work?
> > 
> > > OK, dug into the logs, at the tail end of the X.log file is a Seg
> > > Fault loading.  I am attaching the X.log file.  Basic graphics mode
> > > does work, however the buttons along the bottom are not visible.
> > 
> > So it looks for the VMWare 'vmwgfx' driver and it's not there (I'm not
> > sure if that driver is something Fedora would be expected to include, or
> > if it's a 'guest additions' kind of thing). Then it falls back on
> > 'vmwlegacy', which promptly blows up.
> > 
> > ajax, airlied, are we expecting this 'vmwlegacy' driver to work, or
> > should it be suppressed in favour of vesa or something?
> 
> Yes, if it's loaded it should work and be preferable to vesa.

OK, so Mark, it looks like we need you to file a bug on the segfault you
hit when trying to run anaconda with the vmwlegacy driver (as long as
I'm interpreting the log right). Can you do that and link to the bug?
Thanks!
-- 
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: Reviving podcatcher

[Jon Ciesla]

On Mon, Apr 23, 2012 at 10:34 AM,   wrote:
> When I reported a bug on Armangil's podcatcher the other day, I
> noticed that the package had been orphaned.  (Some time ago, actually,
> but I missed it at the time.)  I still use it, so I decided to take
> over.
>
> This is the first time I take over an orphaned package, and I'm
> slightly confused by the process.  There was a "Take Ownership" button
> for the F16 branch.  The packages wasn't branched for F17, so I assume
> I should make an SCM admin request in the original package review
> bugzilla to have one.  So far so good.
>
> But what about the devel branch?  There isn't any "take ownership"
> button for it.  Is there a special process for the rawhide version?
> The web page about orphaned packages
>
> https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers

If it's been retired more than two weeks, it'll need a new review.

-J

> doesn't mention anything special.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel



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

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

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

Re: Fedora 18 Release name voting and Poll for whether to continue naming releases

[Frank Murphy]

On 23/04/12 16:50, Tomas Radej wrote:



I think numbering/naming problem is only about the target audience.


That's just it, most Fedora non-geek users, use numbering.
You see it on the  mailing list(s) daily.
Rarely do you see a Fedora N by it's name.




I didn't know Jules Verne was superman's nemesis.


Zod was.


But he didn't come before the Beefy Miracle.
It was one in, one out for a while.

Me ducks for cover again.


Zod was mentioned one paragraph above.



Yes, but my point to the original Zod post,
was he didn't come before the sausage.


--
Regards,
Frank
"Jack of all, fubars"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Release name voting and Poll for whether to continue naming releases

[Tomas Radej]

On Mon, 23 Apr 2012 16:01:56 +0100
Frank Murphy  wrote:

> On 23/04/12 14:50, Tomas Radej wrote:
> 
> >>
> >> But their numbering is crap.
> >> 12.04 ?
> >
> > April 2012
> 
> My point exactly, name fits better in their scenario.
> "Ah Jules, are you on April or October,
> tweleve, I believe?"
> 
> Me ducks for cover.

I think numbering/naming problem is only about the target audience. If Non-geek 
users tend to stick with names (Karmic Koala, Gingerbread, Belle) and 
devs/powerusers prefer numbering, what's the problem? I don't see much 
confusion about naming and numbering on the message boards.

> >> I didn't know Jules Verne was superman's nemesis.
> >
> > Zod was.
> 
> But he didn't come before the Beefy Miracle.
> It was one in, one out for a while.
> 
> Me ducks for cover again.

Zod was mentioned one paragraph above. 

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

usrmove breaks on directory name conflict

[Daniel Drake]

Hi,

Last week I tried a preupgrade from F16 to F17 beta.

When rebooting into the preupgrade environment, the upgrade failed in usrmove:

Make a copy of /mnt/sysimage/usr/bin
Merge the copy with /mnt/sysimage/bin
cp: cannot overwrite directory /mnt/sysimage/usr/bin.usrmove-new/mkdir
with non-directory
Something failed. Move back to the original state.


Rebooted back into F16. It looks like the issue was that I had a
directory at "/usr/bin/mkdir/". No idea how, looks like it was from
December. Probably my fault, but perhaps usrmove shouldn't fall over
when facing this situation.

After removing that weird directory, I rebooted into preupgrade and it
worked fine. Now running F17 beta.

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

Reviving podcatcher

[goeran]

When I reported a bug on Armangil's podcatcher the other day, I
noticed that the package had been orphaned.  (Some time ago, actually,
but I missed it at the time.)  I still use it, so I decided to take
over.

This is the first time I take over an orphaned package, and I'm
slightly confused by the process.  There was a "Take Ownership" button
for the F16 branch.  The packages wasn't branched for F17, so I assume
I should make an SCM admin request in the original package review
bugzilla to have one.  So far so good.

But what about the devel branch?  There isn't any "take ownership"
button for it.  Is there a special process for the rawhide version?
The web page about orphaned packages

https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers

doesn't mention anything special.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 17 Beta Observations

[Adam Jackson]

On Mon, 2012-04-23 at 14:02 +0100, Adam Williamson wrote:
> On Thu, 2012-04-19 at 21:32 -0400, Mark Bidewell wrote:
> > 
> > 
> > On Thu, Apr 19, 2012 at 2:23 PM, Adam Williamson 
> > wrote:
> > On Thu, 2012-04-19 at 07:29 -0400, Mark Bidewell wrote:
> > > The VM I used had 1GB of memory.
> 
> > Does the 'basic graphics mode' option work?
> 
> > OK, dug into the logs, at the tail end of the X.log file is a Seg
> > Fault loading.  I am attaching the X.log file.  Basic graphics mode
> > does work, however the buttons along the bottom are not visible.
> 
> So it looks for the VMWare 'vmwgfx' driver and it's not there (I'm not
> sure if that driver is something Fedora would be expected to include, or
> if it's a 'guest additions' kind of thing). Then it falls back on
> 'vmwlegacy', which promptly blows up.
> 
> ajax, airlied, are we expecting this 'vmwlegacy' driver to work, or
> should it be suppressed in favour of vesa or something?

Yes, if it's loaded it should work and be preferable to vesa.

- ajax


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

Re: firewalld / iptables.service past F17

[Miloslav Trmač]

On Tue, Apr 17, 2012 at 10:40 PM, Reindl Harald  wrote:
> Hi
>
> one question before decisions are nailed down
>
> http://fedoraproject.org/wiki/Features/firewalld-default
>
>> An explicit transition is planned after Fedora 18 with dropping support for 
>> the
>> static firewall with system-config-firewal/lokkit. A migration from the 
>> static
>> firewall model will be needed then.
>
> are there only the ui-interfaces meant or do someone
> consider drop "iptbales.service" at all? if so please
> re-consider this!

I was pushing for the deprecation to avoid a NetworkManager-like
duplication for the long term.

AFAICS you can s/iptables/firewall-cmd --direct --passthrough ipv4/,
and things should continue to work (perhaps with minor modifications
to avoid collisions with firewalld's default rule chains).

Or, if you insist, disable firewalld (... which might break some
applications), and turn your shell script into a systemd service; but
--direct --passthrough should be the preferred route.
   Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[389-devel] Please review: Ticket #347 - IPA dirsvr seg-fault during system longevity test

[Rich Megginson]

Ticket #347 - IPA dirsvr seg-fault during system longevity test

https://fedorahosted.org/389/attachment/ticket/347/0001-Ticket-347-IPA-dirsvr-seg-fault-during-system-longev.patch
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: Fedora 18 Release name voting and Poll for whether to continue naming releases

[Frank Murphy]

On 23/04/12 14:50, Tomas Radej wrote:



But their numbering is crap.
12.04 ?


April 2012


My point exactly, name fits better in their scenario.
"Ah Jules, are you on April or October,
tweleve, I believe?"

Me ducks for cover.

ame from...).


I didn't know Jules Verne was superman's nemesis.


Zod was.


But he didn't come before the Beefy Miracle.
It was one in, one out for a while.

Me ducks for cover again.
--
Regards,
Frank
"Jack of all, fubars"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Release name voting and Poll for whether to continue naming releases

[Tomas Radej]

On Mon, 23 Apr 2012 14:43:41 +0100
Frank Murphy  wrote:

> On 23/04/12 14:36, Mark Bidewell wrote:
> 
> >
> > I think it has as much to do with the names as anything else.  Ubuntu
> > names are short and easy.
> 
> But their numbering is crap.
> 12.04 ?

April 2012

>   I am still not sure how we got from
> > Superman's nemesis to hot dogs (at least I think that is where "beefy
> > miracle" came from...).
> 
> I didn't know Jules Verne was superman's nemesis.

Zod was.

> 
> 
> -- 
> Regards,
> Frank
> "Jack of all, fubars"
> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

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

Re: general problem -> Re: Fedora 16 and the 3.3.1-3 kernel

[Reindl Harald]

Am 23.04.2012 05:32, schrieb Chris Murphy:
> 
> On Apr 22, 2012, at 5:10 PM, Reindl Harald wrote:
>>>
>>
>> no 3.3.1 is the current one, 3.3.2 is current
>>
>> but the whole 3.3 line until now elaborates on the same problem
>> not at each boot, mostly only slower but terrible at all
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=806548
>> https://bugzilla.redhat.com/show_bug.cgi?id=805317
>>
>> i post a copy to the devel-list
>> maybe someone cosiders "CONFIG_RCU_FAST_NO_HZ=n" because
>> this is the change in 3.3 and seems to be the root cause
>> of all this troubles
> 
>> my first bug report is now more than a month old and
>> there are built one kernel after the next with the
>> same problem
> 
> http://cateee.net/lkddb/web-lkddb/RCU_FAST_NO_HZ.html
> 
> The description suggests it may not be suitable as default for a distro 
> issued kernel. Maybe ask about it on the kernel list?

oh no, please not another mailing-list for me :-(
hopefully the fedora.kernel developers are reading fedora-devel
and disable "CONFIG_RCU_FAST_NO_HZ"



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

rawhide report: 20120423 changes

[Fedora Rawhide Report]

Compose started at Mon Apr 23 08:15:02 UTC 2012

Broken deps for x86_64
--
[389-admin]
389-admin-1.1.28-1.fc18.i686 requires libicuuc.so.48
389-admin-1.1.28-1.fc18.i686 requires libicui18n.so.48
389-admin-1.1.28-1.fc18.i686 requires libicudata.so.48
389-admin-1.1.28-1.fc18.x86_64 requires libicuuc.so.48()(64bit)
389-admin-1.1.28-1.fc18.x86_64 requires libicui18n.so.48()(64bit)
389-admin-1.1.28-1.fc18.x86_64 requires libicudata.so.48()(64bit)
[389-adminutil]
389-adminutil-1.1.15-2.fc17.i686 requires libicuuc.so.48
389-adminutil-1.1.15-2.fc17.i686 requires libicui18n.so.48
389-adminutil-1.1.15-2.fc17.i686 requires libicudata.so.48
389-adminutil-1.1.15-2.fc17.x86_64 requires libicuuc.so.48()(64bit)
389-adminutil-1.1.15-2.fc17.x86_64 requires libicui18n.so.48()(64bit)
389-adminutil-1.1.15-2.fc17.x86_64 requires libicudata.so.48()(64bit)
[389-ds-base]
389-ds-base-1.2.11-0.1.a1.fc18.x86_64 requires libicuuc.so.48()(64bit)
389-ds-base-1.2.11-0.1.a1.fc18.x86_64 requires libicui18n.so.48()(64bit)
389-ds-base-1.2.11-0.1.a1.fc18.x86_64 requires libicudata.so.48()(64bit)
389-ds-base-1.2.11-0.1.a1.fc18.x86_64 requires libdb-5.2.so()(64bit)
[389-dsgw]
389-dsgw-1.1.9-2.fc17.x86_64 requires libicuuc.so.48()(64bit)
389-dsgw-1.1.9-2.fc17.x86_64 requires libicui18n.so.48()(64bit)
389-dsgw-1.1.9-2.fc17.x86_64 requires libicudata.so.48()(64bit)
[R]
R-core-2.15.0-1.fc18.i686 requires libicuuc.so.48
R-core-2.15.0-1.fc18.i686 requires libicui18n.so.48
R-core-2.15.0-1.fc18.x86_64 requires libicuuc.so.48()(64bit)
R-core-2.15.0-1.fc18.x86_64 requires libicui18n.so.48()(64bit)
[aeolus-conductor]
aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8
[aeolus-configserver]
aeolus-configserver-0.4.5-1.fc18.noarch requires ruby-nokogiri
[axis2c]
axis2c-1.6.0-4.fc17.i686 requires httpd-mmn = 0:20051115-x86-32
axis2c-1.6.0-4.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64
[bibletime]
bibletime-2.9.1-1.fc18.x86_64 requires libicuuc.so.48()(64bit)
bibletime-2.9.1-1.fc18.x86_64 requires libicui18n.so.48()(64bit)
[boost141]
boost141-graph-1.41.0-2.fc17.i686 requires libicuuc.so.48
boost141-graph-1.41.0-2.fc17.i686 requires libicui18n.so.48
boost141-graph-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit)
boost141-graph-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit)
boost141-regex-1.41.0-2.fc17.i686 requires libicuuc.so.48
boost141-regex-1.41.0-2.fc17.i686 requires libicui18n.so.48
boost141-regex-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit)
boost141-regex-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit)
[calibre]
calibre-0.8.47-1.fc18.x86_64 requires libicuuc.so.48()(64bit)
calibre-0.8.47-1.fc18.x86_64 requires libicuio.so.48()(64bit)
calibre-0.8.47-1.fc18.x86_64 requires libicui18n.so.48()(64bit)
calibre-0.8.47-1.fc18.x86_64 requires libicudata.so.48()(64bit)
[cifs-utils]
cifs-utils-5.4-1.fc18.x86_64 requires 
libwbclient.so.0(WBCLIENT_0)(64bit)
[couchdb]
couchdb-1.1.1-1.fc18.x86_64 requires libicuuc.so.48()(64bit)
couchdb-1.1.1-1.fc18.x86_64 requires libicui18n.so.48()(64bit)
couchdb-1.1.1-1.fc18.x86_64 requires libicudata.so.48()(64bit)
[digikam]
kipi-plugins-2.6.0-0.4.beta3.fc18.x86_64 requires 
libusbmuxd.so.1()(64bit)
kipi-plugins-2.6.0-0.4.beta3.fc18.x86_64 requires 
libimobiledevice.so.2()(64bit)
[dustmite]
dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires 
libphobos2-ldc.so()(64bit)
[dwdiff]
dwdiff-1.9-4.fc17.x86_64 requires libicuuc.so.48()(64bit)
dwdiff-1.9-4.fc17.x86_64 requires libicui18n.so.48()(64bit)
dwdiff-1.9-4.fc17.x86_64 requires libicudata.so.48()(64bit)
[fcitx]
fcitx-qt4-4.2.0-1.fc17.i686 requires libicuuc.so.48
fcitx-qt4-4.2.0-1.fc17.x86_64 requires libicuuc.so.48()(64bit)
[gcc-python-plugin]
gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 
0:4.7.0-0.10.fc17
gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17
gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 
0:4.7.0-0.10.fc17
gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17
[gearmand]
gearmand-0.28-3.fc18.x86_64 requires libmemcached.so.9()(64bit)
[gnome-applet-sensors]
gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0
gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
[gnome-chemistry-utils]
gnome-chemistry-utils-gnumeric-0.13.6-2.fc18.x86_64 requires 
libspreadsheet-1.11.2.so()(64bit)
[gnome-phone-manager]
gnome-phone-manager-0.68-1.fc18.x86_64 requires libgnokii.so.6()(64bit)

[perl-Package-DeprecationManager] Upstream has dropped Kwalitee test, so drop BR: perl(Test::Kwalitee)

[Paul Howarth]

commit e849679cde3809bfa9db269e4ccecddfbe1becb7
Author: Paul Howarth 
Date:   Mon Apr 23 15:10:38 2012 +0100

Upstream has dropped Kwalitee test, so drop BR: perl(Test::Kwalitee)

 perl-Package-DeprecationManager.spec |   11 ---
 1 files changed, 4 insertions(+), 7 deletions(-)
---
diff --git a/perl-Package-DeprecationManager.spec 
b/perl-Package-DeprecationManager.spec
index 809d4a0..42c6fe4 100644
--- a/perl-Package-DeprecationManager.spec
+++ b/perl-Package-DeprecationManager.spec
@@ -1,15 +1,12 @@
 # We need to patch the test suite if we have an old version of Test::More
 %global old_test_more %(perl -MTest::More -e 'print (($Test::More::VERSION < 
0.88) ? 1 : 0);' 2>/dev/null || echo 0)
 
-# Test::Kwalitee not yet available in EPEL < 6
-%global extra_tests_available %(expr 0%{?fedora} + 0%{?rhel} '>' 5)
-
 # Test::CPAN::Changes isn't available in EPEL-6 either, due to requirement of 
perl(version) ≥ 0.79
 %global cpan_changes_available %(expr 0%{?fedora} + 0%{?rhel} '>' 6)
 
 Name:  perl-Package-DeprecationManager
 Version:   0.13
-Release:   1%{?dist}
+Release:   2%{?dist}
 Summary:   Manage deprecation warnings for your distribution
 Group: Development/Libraries
 License:   Artistic 2.0
@@ -37,9 +34,6 @@ BuildRequires:perl(Test::Pod)
 BuildRequires: perl(Test::Pod::Coverage)
 BuildRequires: perl(Test::Requires)
 BuildRequires: perl(Test::Spelling), aspell-en
-%if %{extra_tests_available}
-BuildRequires: perl(Test::Kwalitee)
-%endif
 Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 
 %description
@@ -82,6 +76,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/Package::DeprecationManager.3pm*
 
 %changelog
+* Mon Apr 23 2012 Paul Howarth  - 0.13-2
+- Upstream has dropped Kwalitee test, so drop BR: perl(Test::Kwalitee)
+
 * Fri Mar  9 2012 Paul Howarth  - 0.13-1
 - Update to 0.13:
   - Fix dist.ini to not add Test::Spelling as a requirement
--
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

Broken dependencies: perl-RPM2

[buildsys]

perl-RPM2 has broken dependencies in the rawhide tree:
On x86_64:
perl-RPM2-1.0-2.fc17.x86_64 requires librpmio.so.2()(64bit)
perl-RPM2-1.0-2.fc17.x86_64 requires librpm.so.2()(64bit)
On i386:
perl-RPM2-1.0-2.fc17.i686 requires librpmio.so.2
perl-RPM2-1.0-2.fc17.i686 requires librpm.so.2
Please resolve this as soon as possible.


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

Broken dependencies: perl-AnyEvent

[buildsys]

perl-AnyEvent has broken dependencies in the rawhide tree:
On x86_64:
perl-AnyEvent-6.14-1.fc18.x86_64 requires perl(IO::Async::Loop) >= 
0:0.33
perl-AnyEvent-6.14-1.fc18.x86_64 requires perl(FLTK) >= 0:0.532
perl-AnyEvent-6.14-1.fc18.x86_64 requires perl(Cocoa::EventLoop)
On i386:
perl-AnyEvent-6.14-1.fc18.i686 requires perl(IO::Async::Loop) >= 0:0.33
perl-AnyEvent-6.14-1.fc18.i686 requires perl(FLTK) >= 0:0.532
perl-AnyEvent-6.14-1.fc18.i686 requires perl(Cocoa::EventLoop)
Please resolve this as soon as possible.


--
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: Private-libraries in /usr/lib* - invalid soname.

[Alec Leamas]

On 04/23/2012 03:11 PM, Adam Williamson wrote:

On Fri, 2012-04-20 at 17:20 +0200, Alec Leamas wrote:


Thanks again. Following this advice when packaging makes perfect sense
to me. Still, when reviewing, my question is how hard I should push
it. If I understand Kevin correct I shouldn't push it all (?). Is your
position  that  private, unversioned libs in /usr/lib* is a problem,
but not a blocker?

I may just be dumb,


Doubt that. Really ;)


but I find myself not entirely sure what Alec is
asking about here - his asterisks seem ambiguous.

To be perfectly clear, are you talking about this case:

Package 'foo' provides, on i686:

/usr/lib/libfoo.so

on x86_64:

/usr/lib64/libfoo.so

Yes, that's the one.


which is used as a private library, not intended to be shared with other
apps

Or this case:

Package 'foo' provides, on i686:

/usr/lib/foo/libfoo.so

on x86_64:

/usr/lib64/foo/libfoo.so

which is used as a private library, not intended to be shared with other
apps
No, this is OK as long as  /usr/lib64/foo is not added to 
/etc/ld.so.conf (there are such things out there...)



or some other case?

No


In my understanding, the first is not really 'kosher' for the reasons
Toshio states; the second is fine. I've always understood that
$libdir/appname is exactly where apps should put such 'private libs'.

Agreed.



To avoid any confusion I suggest in future referring to 'that directory
which is /usr/lib on i686 and /usr/lib64 on x86-64' as $libdir, not as
'/usr/lib*'.

Agreed. I guess %{_libdir} is fine as well.


Problem is that this understanding is not spread to all of us. A simple 
google reveals things like


http://markmail.org/message/piawu2c44fe5touj
https://bugzilla.redhat.com/show_bug.cgi?id=713461
https://bugzilla.redhat.com/show_bug.cgi?id=524283
https://bugzilla.redhat.com/show_bug.cgi?id=799651

The interesting point is that neither the wisdom of Toshio nor you are 
not reflected in any of those matches. On the contrary, all these 
discussion and bugs seems to boil down to that private libs should be 
stored in $libdir.


So it seems that a clarification is really needed here.

I am am a newbie, and although the overall wiki rule is "Be Bold" this 
is not really the place for me to be that IMHO. So, I have prepared a 
draft in https://fedoraproject.org/wiki/Talk:Common_Rpmlint_issues  (the 
"Discussion" tab). My plan is to become bold and move that into the wiki 
page later on. Would really need som input before doing that, though.



Thanks,

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

Re: Fedora 18 Release name voting and Poll for whether to continue naming releases

[Mark Bidewell]

>
>
>  I am still not sure how we got from
>
>> Superman's nemesis to hot dogs (at least I think that is where "beefy
>> miracle" came from...).
>>
>
> I didn't know Jules Verne was superman's nemesis.
>
>
>
> --
> Regards,
> Frank
> "Jack of all, fubars"
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.**org/mailman/listinfo/devel
>

"Verne" wasn't "Zod" was. However, given that each name has a relationship
to the one before, there is a linkage.  But to your point Jules Verne ->
Hot dogs?  Not exactly clear.

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

Re: Fedora 18 Release name voting and Poll for whether to continue naming releases

[Frank Murphy]

On 23/04/12 14:46, Seth Vidal wrote:





But their numbering is crap.
12.04 ?


To be fair their numbering is:

YY.MM


So 12.04 means April, 2012

-sv



But, are you going to say in converation
"Yes, I'm using Ubuntu release twelve zero four",
or "Lucid"
Does anyone know the full two words sans Google.


--
Regards,
Frank
"Jack of all, fubars"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Release name voting and Poll for whether to continue naming releases

[Seth Vidal]

On Mon, 23 Apr 2012, Frank Murphy wrote:


On 23/04/12 14:36, Mark Bidewell wrote:



I think it has as much to do with the names as anything else.  Ubuntu
names are short and easy.


But their numbering is crap.
12.04 ?


To be fair their numbering is:

YY.MM


So 12.04 means April, 2012

-sv

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

Re: Fedora 18 Release name voting and Poll for whether to continue naming releases

[Frank Murphy]

On 23/04/12 14:36, Mark Bidewell wrote:



I think it has as much to do with the names as anything else.  Ubuntu
names are short and easy.


But their numbering is crap.
12.04 ?


 Fedora names tend to be more obscure "Lucid"

or "Precise" makes more sense than "Zod" or "Beefy" (forget the fat
distro connotation...).  Also the Ubuntu pattern is clear and wellknown
(Adjective and animal name).


Not to me.
My hard disk has monogamous relationship with Fedora.

 I am still not sure how we got from

Superman's nemesis to hot dogs (at least I think that is where "beefy
miracle" came from...).


I didn't know Jules Verne was superman's nemesis.


--
Regards,
Frank
"Jack of all, fubars"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Release name voting and Poll for whether to continue naming releases

[Adam Williamson]

On Mon, 2012-04-23 at 15:21 +0200, Ralf Corsepius wrote:
> On 04/23/2012 03:06 PM, Adam Williamson wrote:
> > On Fri, 2012-04-20 at 09:58 +0200, Ralf Corsepius wrote:
> >
> >> Why isn't adding a link to an explanation to avoid misunderstandings
> >> originating from conotations sufficient anymore? This is at least what
> >> had been done in the past.
> >
> > 'sufficient' to what purpose?
> 
> To explain the intentional co-notations and if necessary, whose which 
> were not meant.

Well, as I suggested with my personal position in the bit of my mail you
cut out, I don't think the proposal to stop doing release names is
actually motivated by any kind of worries about the connotations of
'beefy miracle'. I've always thought the names were a waste of time so I
was more than happy to jump on a 'no more names' bandwagon when it came
along, and it's been stated elsewhere in the thread that those who
initiated the 'no more names' proposal are not the same people who were
apparently offended by the beef.
-- 
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: Fedora 18 Release name voting and Poll for whether to continue naming releases

[Frank Murphy]

On 23/04/12 14:21, Ralf Corsepius wrote:

On 04/23/2012 03:06 PM, Adam Williamson wrote:

On Fri, 2012-04-20 at 09:58 +0200, Ralf Corsepius wrote:


Why isn't adding a link to an explanation to avoid misunderstandings
originating from conotations sufficient anymore? This is at least what
had been done in the past.


'sufficient' to what purpose?


To explain the intentional co-notations and if necessary, whose which
were not meant.

Ralf


Pandering to gobsheens.

--
Regards,
Frank
"Jack of all, fubars"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 17 Beta Observations

[Frank Murphy]

On 18/04/12 12:47, Mark Bidewell wrote:

After trying the F17 Alpha with no success, I tried the F17 Beta.  I
installed in the VMWare Fusion Technical Preview


F17 Beta Xfce.x86_64 spin,
Happily ran on F16.x86_64 host,
and installed just dandy.
firewalld service by default.

But OT for this list, I perfume.

--
Regards,
Frank
"Jack of all, fubars"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Release name voting and Poll for whether to continue naming releases

[Mark Bidewell]

On Fri, Apr 20, 2012 at 6:33 PM, Matej Cepl  wrote:

> On 20.4.2012 18:09, Ralf Corsepius wrote:
>
>> Never. Nobody uses the code names. It's a waste of time and choosing
 names like "Beefy Miracle" is a good way of making the distro look a
 whole lot less professional.

>>>
>> Well, as far as I can tell, many Ubuntu and Debian users prefer to call
>> their release "by name".
>>
>
> Yes, and I wonder why Fedora users just don't it. Nobody knows why, either
> we have too stupid names, or we are too geeky, or something. And I have to
> admit, that although my first Debian was potato and I have switched to
> Fedora just before etch (and I have no idea, what was the number of these
> releases), I have never felt the smallest inclination to call my first
> Fedora distro anything else than Fedora Core 6.
>
> Matěj
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.**org/mailman/listinfo/devel
>


I think it has as much to do with the names as anything else.  Ubuntu names
are short and easy.  Fedora names tend to be more obscure "Lucid" or
"Precise" makes more sense than "Zod" or "Beefy" (forget the fat
distro connotation...).  Also the Ubuntu pattern is clear and wellknown
(Adjective and animal name).  I am still not sure how we got from
Superman's nemesis to hot dogs (at least I think that is where "beefy
miracle" came from...).

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

Re: Fedora 17 Beta Observations

[Tom Hughes]

On 23/04/12 14:27, Mark Bidewell wrote:


>   So it looks for the VMWare 'vmwgfx' driver and it's not there (I'm not
>   sure if that driver is something Fedora would be expected to include, or
>   if it's a 'guest additions' kind of thing). Then it falls back on
>   'vmwlegacy', which promptly blows up.

Given that installing GNOME desktop and Base X via yum yields a
functioning desktop, I would assume that the driver is included with Fedora.


Well F16 seems to have drivers called "vmware" and "vmlegacy" and F17 
has "vmware" only, all in the xorg-x11-drv-vmware package. Neither has a 
driver called "vmwgfx".


Tom

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

Re: Login on Fedora 17

[Adam Williamson]

On Sat, 2012-04-21 at 23:59 +0900, Joel Rees wrote:

> > Note that we actually have a test case which is run during validation
> > testing and is intended to ensure that the same keyboard layout is used
> > for setting passwords during installation and entering them
> > post-install, because we had a lot of this kind of trouble back before
> > we did that. To my knowledge we haven't had a major bug of this type
> > since F15 or so.
> 
> Well, maybe that doesn't get applied to some of the spins?

You can only rely on its having been run on the GNOME and KDE spins,
indeed. Those are the only release-blocking desktops, and therefore the
only spins for which it is required that the desktop validation tests be
completed. The tests often _are_ completed for the Xfce and LXDE spins
also, but this cannot be entirely relied upon. I think the security spin
is based on the LXDE spin?

> I'm pretty sure I ended up with keys moving on a password on a live
> USB of the F16 security spin. If I notice it again and have time,
> maybe I should file a bug?

Yes, definitely.
-- 
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: Fedora 17 Beta Observations

[Mark Bidewell]

>
>
> So it looks for the VMWare 'vmwgfx' driver and it's not there (I'm not
> sure if that driver is something Fedora would be expected to include, or
> if it's a 'guest additions' kind of thing). Then it falls back on
> 'vmwlegacy', which promptly blows up.
>
> ajax, airlied, are we expecting this 'vmwlegacy' driver to work, or
> should it be suppressed in favour of vesa or something?
> --
> 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
>


Given that installing GNOME desktop and Base X via yum yields a functioning
desktop, I would assume that the driver is included with Fedora.
-- 
Mark Bidewell
http://www.linkedin.com/in/markbidewell
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GitHub is a terrible upstream

[Adam Williamson]

On Fri, 2012-04-20 at 20:51 -0700, Eric Smith wrote:
> Corey Richardson wrote:
> > Getting source tarballs from github is a nightmare. See
> > http://lists.fedoraproject.org/pipermail/devel/2011-February/148676.html
> >
> > The debian tool doesn't help very much because one still needs revision
> > garbage in the specfile. Is there any more recent ways to mitigate this?
> > Perhaps we could "lobby" github to change their ways, at least partially?
> 
> I don't know if this will be of any use to you, but for tcplay there 
> isn't a tagged release, so I use this script to create an suitable 
> tarball from a github commit with a known hash, by doing a clone then 
> archiving it locally.  Certainly this doesn't solve the problem of not 
> having a source URL.
> 
> #!/bin/sh
> # usage: tcplay-get-snapshot.sh 
> git clone git://github.com/bwalex/tc-play
> ( cd tc-play && \
>git archive --format=tar --prefix=tcplay-$1/ $1 \
> ) | xz - >tcplay-$1.tar.xz

We could probably add something like this to the 'snippets' bit of the
packaging guidelines, since github is pretty significant. Just to try
and help packagers do it in a uniform and guideline-complaint way.

As a reminder for packagers following the thread - any time you have to
'generate' a source tarball like this (i.e. it is not possible to
provide a Source: URL that can be expected to remain valid), you should
ensure the tarball is reliably reproducible by others and include all
necessary instructions to produce it, using comments in the .spec file
and/or a script like Eric's - so if you wanted to use Eric's script, you
should ensure you actually check the script itself into git (and
probably cite it as a Source itself, so it winds up in the .src.rpm),
then have a comment in the .spec file which specifies the invocation of
the script that was used to generate the source tarball.
-- 
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: Fedora 18 Release name voting and Poll for whether to continue naming releases

[Ralf Corsepius]

On 04/23/2012 03:06 PM, Adam Williamson wrote:

On Fri, 2012-04-20 at 09:58 +0200, Ralf Corsepius wrote:


Why isn't adding a link to an explanation to avoid misunderstandings
originating from conotations sufficient anymore? This is at least what
had been done in the past.


'sufficient' to what purpose?


To explain the intentional co-notations and if necessary, whose which 
were not meant.


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

Re: Fedora 18 Release name voting and Poll for whether to continue naming releases

[Adam Williamson]

On Sat, 2012-04-21 at 00:33 +0200, Matej Cepl wrote:
> On 20.4.2012 18:09, Ralf Corsepius wrote:
> >>> Never. Nobody uses the code names. It's a waste of time and choosing
> >>> names like "Beefy Miracle" is a good way of making the distro look a
> >>> whole lot less professional.
> >
> > Well, as far as I can tell, many Ubuntu and Debian users prefer to call
> > their release "by name".
> 
> Yes, and I wonder why Fedora users just don't it. Nobody knows why, 

I thought Przemek's explanation (upthread a couple of posts) was
precisely correct, in fact.

Android and Ubuntu names are alphabetized. There have been so few Debian
releases that it's easy to keep the names straight (plus their naming
scheme includes their development releases; our development release
names, Rawhide and Branched, *are* commonly used, but are not tied in
any way at all to the stable release naming system). Fedora has tons of
releases - so many you would need some kind of aide-memoire in the
system to keep them straight - but there is none (unless you can somehow
remember, or reconstruct, all the 'X is also a Y' associations in the
right order).

Also, Fedora uses a simple, clear and consistent numbering scheme.
Ubuntu's is clear and rules-based, but a bit tricky to remember, because
they don't always hit the six month cycle exactly, so the 'month'
portion of the release number changes from release to release. With
Fedora it's just an incremented integer every time, and we've never done
any crazy scheme changes or big bumps or 'reset to V1's like some
distros have.
-- 
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: Private-libraries in /usr/lib* - invalid soname.

[Adam Williamson]

On Fri, 2012-04-20 at 17:20 +0200, Alec Leamas wrote:

> Thanks again. Following this advice when packaging makes perfect sense
> to me. Still, when reviewing, my question is how hard I should push
> it. If I understand Kevin correct I shouldn't push it all (?). Is your
> position  that  private, unversioned libs in /usr/lib* is a problem,
> but not a blocker?

I may just be dumb, but I find myself not entirely sure what Alec is
asking about here - his asterisks seem ambiguous.

To be perfectly clear, are you talking about this case:

Package 'foo' provides, on i686:

/usr/lib/libfoo.so

on x86_64:

/usr/lib64/libfoo.so

which is used as a private library, not intended to be shared with other
apps

Or this case:

Package 'foo' provides, on i686:

/usr/lib/foo/libfoo.so

on x86_64:

/usr/lib64/foo/libfoo.so

which is used as a private library, not intended to be shared with other
apps

or some other case?

In my understanding, the first is not really 'kosher' for the reasons
Toshio states; the second is fine. I've always understood that
$libdir/appname is exactly where apps should put such 'private libs'.

To avoid any confusion I suggest in future referring to 'that directory
which is /usr/lib on i686 and /usr/lib64 on x86-64' as $libdir, not as
'/usr/lib*'.
-- 
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: Orphaning eog

[Kalev Lember]

On 04/23/2012 03:17 PM, Siddhesh Poyarekar wrote:
> I took eog over when it was orphaned last time, since I though I could
> work on it some more. I never got around to anything but a couple of
> bug reports though and I don't think I'm really going to get around to
> it in the future either, so I'll just orphan it again so that someone
> who is really interested (or the desktop team, who probably should have
> been owning it in the first place and I shouldn't have just butted in
> that way) can pick it up.

Hi Siddhesh,

Thanks for taking care of eog, I'll pick it up in pkgdb.

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

Re: general problem -> Re: Fedora 16 and the 3.3.1-3 kernel

[Josh Boyer]

On Sun, Apr 22, 2012 at 11:32 PM, Chris Murphy  wrote:
>
> On Apr 22, 2012, at 5:10 PM, Reindl Harald wrote:
>>>
>>
>> no 3.3.1 is the current one, 3.3.2 is current
>>
>> but the whole 3.3 line until now elaborates on the same problem
>> not at each boot, mostly only slower but terrible at all
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=806548
>> https://bugzilla.redhat.com/show_bug.cgi?id=805317
>>
>> i post a copy to the devel-list
>> maybe someone cosiders "CONFIG_RCU_FAST_NO_HZ=n" because
>> this is the change in 3.3 and seems to be the root cause
>> of all this troubles
>
>> my first bug report is now more than a month old and
>> there are built one kernel after the next with the
>> same problem
>
> http://cateee.net/lkddb/web-lkddb/RCU_FAST_NO_HZ.html
>
> The description suggests it may not be suitable as default for a distro 
> issued kernel. Maybe ask about it on the kernel list?

We're well aware of it.  Upstream is working through the issue.  It
isn't a wide-spread issue from what we've seen, but we did discuss
disabling the option.

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

Re: Fedora 18 Release name voting and Poll for whether to continue naming releases

[Adam Williamson]

On Fri, 2012-04-20 at 09:58 +0200, Ralf Corsepius wrote:

> Why isn't adding a link to an explanation to avoid misunderstandings 
> originating from conotations sufficient anymore? This is at least what 
> had been done in the past.

'sufficient' to what purpose?

I'm not against release names because some people are supposed to have
been offended by the words 'Beefy Miracle', I'm against release names
because they're usually a giant waste of everyone's time: almost no-one
ever remembers them, or refers to Fedora releases by their names, so
we're going through the time of whichever poor sod has to co-ordinate
the naming process, and of the Red Hat legal team in vetting a giant
pile of absurd suggestions, for no decent reason at all.
-- 
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: Fedora 17 Beta Observations

[Adam Williamson]

On Thu, 2012-04-19 at 21:32 -0400, Mark Bidewell wrote:
> 
> 
> On Thu, Apr 19, 2012 at 2:23 PM, Adam Williamson 
> wrote:
> On Thu, 2012-04-19 at 07:29 -0400, Mark Bidewell wrote:
> > The VM I used had 1GB of memory.

> Does the 'basic graphics mode' option work?

> OK, dug into the logs, at the tail end of the X.log file is a Seg
> Fault loading.  I am attaching the X.log file.  Basic graphics mode
> does work, however the buttons along the bottom are not visible.

So it looks for the VMWare 'vmwgfx' driver and it's not there (I'm not
sure if that driver is something Fedora would be expected to include, or
if it's a 'guest additions' kind of thing). Then it falls back on
'vmwlegacy', which promptly blows up.

ajax, airlied, are we expecting this 'vmwlegacy' driver to work, or
should it be suppressed in favour of vesa or something?
-- 
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

[perl-YAML] Fix build and runtime dependencies

[Paul Howarth]

commit 48fd123ff83d853a4db030374bda66e1b84cae0f
Author: Paul Howarth 
Date:   Mon Apr 23 13:11:31 2012 +0100

Fix build and runtime dependencies

- R: perl(Carp) and perl(Data::Dumper)
- BR: perl(Carp), perl(constant) and perl(Exporter)
- Release tests no longer shipped, so drop buildreqs for them and don't 
bother
  setting AUTOMATED_TESTING; run tests even when bootstrapping

 perl-YAML.spec |   26 --
 1 files changed, 16 insertions(+), 10 deletions(-)
---
diff --git a/perl-YAML.spec b/perl-YAML.spec
index b989cd4..de75c06 100644
--- a/perl-YAML.spec
+++ b/perl-YAML.spec
@@ -1,18 +1,20 @@
 Name:   perl-YAML
 Version:0.81
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:YAML Ain't Markup Language (tm)
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/YAML/
 Source0:
http://search.cpan.org/CPAN/authors/id/I/IN/INGY/YAML-%{version}.tar.gz
 BuildArch:  noarch
-BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(constant)
 BuildRequires:  perl(Data::Dumper)
-%if !%{defined perl_bootstrap}
-BuildRequires:  perl(Test::CPAN::Meta), perl(Test::MinimumVersion), 
perl(Test::Pod)
-%endif
+BuildRequires:  perl(Exporter)
+BuildRequires:  perl(ExtUtils::MakeMaker)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+Requires:   perl(Carp)
+Requires:   perl(Data::Dumper)
 
 %description
 The YAML.pm module implements a YAML Loader and Dumper based on the
@@ -49,9 +51,7 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2>/dev/null \;
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-%if !%{defined perl_bootstrap}
-make test AUTOMATED_TESTING=1
-%endif
+make test
 
 %files
 %doc Changes README LICENSE
@@ -59,9 +59,15 @@ make test AUTOMATED_TESTING=1
 %{_mandir}/man3/YAML*.3*
 
 %changelog
+* Mon Apr 23 2012 Paul Howarth  - 0.81-2
+- R: perl(Carp) and perl(Data::Dumper)
+- BR: perl(Carp), perl(constant) and perl(Exporter)
+- Release tests no longer shipped, so drop buildreqs for them and don't bother
+  setting AUTOMATED_TESTING; run tests even when bootstrapping
+
 * Mon Apr 23 2012 Marcela Mašláňová  - 0.81-1
-- update to 0.81
-- add BR Data::Dumper
+- Update to 0.81
+- Add BR Data::Dumper
 
 * Fri Jan 13 2012 Fedora Release Engineering  
- 0.73-3
 - 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

Orphaning eog

[Siddhesh Poyarekar]

Hi,

I took eog over when it was orphaned last time, since I though I could
work on it some more. I never got around to anything but a couple of
bug reports though and I don't think I'm really going to get around to
it in the future either, so I'll just orphan it again so that someone
who is really interested (or the desktop team, who probably should have
been owning it in the first place and I shouldn't have just butted in
that way) can pick it up.

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

F-17 Branched report: 20120423 changes

[Fedora Branched Report]

Compose started at Mon Apr 23 08:15:05 UTC 2012

Broken deps for x86_64
--
[aeolus-conductor]
aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8
[aeolus-configserver]
aeolus-configserver-0.4.5-1.fc17.noarch requires ruby-nokogiri
[dh-make]
dh-make-0.55-4.fc17.noarch requires debhelper
[dustmite]
dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires 
libphobos2-ldc.so()(64bit)
[egoboo]
egoboo-2.7.5-11.fc17.x86_64 requires libenet-1.2.1.so()(64bit)
[gcc-python-plugin]
gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 
0:4.7.0-0.10.fc17
gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17
gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 
0:4.7.0-0.10.fc17
gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17
[gorm]
gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3
gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20
gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23
gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit)
gorm-1.2.13-0.2.20110331.fc17.x86_64 requires 
libgnustep-gui.so.0.20()(64bit)
gorm-1.2.13-0.2.20110331.fc17.x86_64 requires 
libgnustep-base.so.1.23()(64bit)
[ibus-panel-extensions]
ibus-panel-extensions-1.4.99.20111207-2.fc17.i686 requires 
libibus-1.0.so.0
ibus-panel-extensions-1.4.99.20111207-2.fc17.x86_64 requires 
libibus-1.0.so.0()(64bit)
[matreshka]
matreshka-0.1.1-9.fc17.i686 requires libgnat-4.6.so
matreshka-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit)
matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnat-4.6.so
matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnarl-4.6.so
matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit)
matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnarl-4.6.so()(64bit)
matreshka-sql-core-0.1.1-9.fc17.i686 requires libgnat-4.6.so
matreshka-sql-core-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit)
matreshka-sql-postgresql-0.1.1-9.fc17.i686 requires libgnat-4.6.so
matreshka-sql-postgresql-0.1.1-9.fc17.x86_64 requires 
libgnat-4.6.so()(64bit)
matreshka-sql-sqlite-0.1.1-9.fc17.i686 requires libgnat-4.6.so
matreshka-sql-sqlite-0.1.1-9.fc17.x86_64 requires 
libgnat-4.6.so()(64bit)
[mcollective]
mcollective-common-1.3.1-7.fc17.noarch requires ruby(abi) = 0:1.8
[meshlab]
meshlab-1.3.1-2.fc17.x86_64 requires libmuparser.so.0()(64bit)
[moksha]
moksha-0.5.0-5.fc15.noarch requires pyevent
[natus]
libnatus-V8-0.1.5-2.fc15.x86_64 requires libv8-3.0.0.1.so()(64bit)
[ocaml-augeas]
ocaml-augeas-0.4-9.fc15.x86_64 requires ocaml(runtime) = 0:3.12.0
[openvrml]
libopenvrml-0.18.8-2.fc16.i686 requires libboost_thread-mt.so.1.47.0
libopenvrml-0.18.8-2.fc16.i686 requires libboost_system-mt.so.1.47.0
libopenvrml-0.18.8-2.fc16.i686 requires libboost_filesystem-mt.so.1.47.0
libopenvrml-0.18.8-2.fc16.x86_64 requires 
libboost_thread-mt.so.1.47.0()(64bit)
libopenvrml-0.18.8-2.fc16.x86_64 requires 
libboost_system-mt.so.1.47.0()(64bit)
libopenvrml-0.18.8-2.fc16.x86_64 requires 
libboost_filesystem-mt.so.1.47.0()(64bit)
libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_thread-mt.so.1.47.0
libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_system-mt.so.1.47.0
libopenvrml-gl-0.18.8-2.fc16.i686 requires 
libboost_filesystem-mt.so.1.47.0
libopenvrml-gl-0.18.8-2.fc16.x86_64 requires 
libboost_thread-mt.so.1.47.0()(64bit)
libopenvrml-gl-0.18.8-2.fc16.x86_64 requires 
libboost_system-mt.so.1.47.0()(64bit)
libopenvrml-gl-0.18.8-2.fc16.x86_64 requires 
libboost_filesystem-mt.so.1.47.0()(64bit)
openvrml-java-0.18.8-2.fc16.x86_64 requires 
libboost_thread-mt.so.1.47.0()(64bit)
openvrml-java-0.18.8-2.fc16.x86_64 requires 
libboost_system-mt.so.1.47.0()(64bit)
openvrml-java-0.18.8-2.fc16.x86_64 requires 
libboost_filesystem-mt.so.1.47.0()(64bit)
openvrml-java-0.18.8-2.fc16.x86_64 requires java-1.6.0-openjdk(x86-64)
openvrml-javascript-0.18.8-2.fc16.x86_64 requires 
libboost_thread-mt.so.1.47.0()(64bit)
openvrml-javascript-0.18.8-2.fc16.x86_64 requires 
libboost_system-mt.so.1.47.0()(64bit)
openvrml-javascript-0.18.8-2.fc16.x86_64 requires 
libboost_filesystem-mt.so.1.47.0()(64bit)
openvrml-nodes-0.18.8-2.fc16.x86_64 requires 
libboost_thread-mt.so.1.47.0()(64bit)
openvrml-nodes-0.18.8-2.fc16.x86_64 requires 
libboost_system-mt.so.1.47.0()(64bit)
openvrml-nodes-0.18.8-2.fc16.x86_64 requires 
libboost_filesystem-mt.so.1.47.0()(64bit)
openvrml-xembed-0.18.8-2.fc16.x86_64 requires 
libboost_thread-mt.so.1.47.0()(64bit)
openvrml-xembed-0.18.8-2.fc16.x86_6

[Test-Announce] 2012-04-23 @ 15:00 UTC - Fedora QA Meeting

[Adam Williamson]

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

Greetings testers!

There's going to be a meeting, again. It seems to happen a lot. We've
got several things to follow up on from last week, and it's time to
start planning for Final too!

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

The current proposed agenda is included below.

== Proposed Agenda Topics ==
1. Previous meeting follow-up
2. Fedora 17 Beta retrospective
3. Test Day report
4. Upcoming QA events
5. AutoQA update
6. 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

Re: Package libsmbclient needs to be rebuild against new samba4-common

[Stephen Gallagher]

On Mon, 2012-04-23 at 13:57 +0300, Kalev Lember wrote:
> On 04/23/2012 06:22 AM, Simo Sorce wrote:
> > On Sun, 2012-04-22 at 20:53 +0300, Kalev Lember wrote:
> >> libsmbclient has been now removed from samba4 package (see bug #814451),
> >> but what you have installed is a leftover from the earlier packaging
> >> error. Incrementing the epoch number in the samba 3 package would fix
> >> the upgrade paths again, making sure everybody gets back the samba 3
> >> libsmbclient.
> > 
> > As far as I know that package never reached the stable repository, can
> > you confirm you use updates-testing ?
> > If that's the case I do not think we are going to up the epoch.
> 
> Yes, the samba4 updates was only in updates-testing. However,
> updates-testing is turned on by default in F17 and because of that,
> every F17 user still got the libsmbclient update.
> 
> It's your call to make, but I wouldn't base the decision on whether it
> was in stable updates or updates-testing. Both are currently enabled by
> default in F17.


There is a reasonable expectation that when using a Fedora Beta you may
end up in a situation that requires manual effort to get out of. I agree
with Simo that no epoch bump is needed here.

I do maintain that we should stop leaving updates-testing enabled once
we hit Beta. (Alpha is fine). This would also help with getting testing
for the bits that will ultimately be the final release.


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

Re: Package libsmbclient needs to be rebuild against new samba4-common

[Kalev Lember]

On 04/23/2012 06:22 AM, Simo Sorce wrote:
> On Sun, 2012-04-22 at 20:53 +0300, Kalev Lember wrote:
>> libsmbclient has been now removed from samba4 package (see bug #814451),
>> but what you have installed is a leftover from the earlier packaging
>> error. Incrementing the epoch number in the samba 3 package would fix
>> the upgrade paths again, making sure everybody gets back the samba 3
>> libsmbclient.
> 
> As far as I know that package never reached the stable repository, can
> you confirm you use updates-testing ?
> If that's the case I do not think we are going to up the epoch.

Yes, the samba4 updates was only in updates-testing. However,
updates-testing is turned on by default in F17 and because of that,
every F17 user still got the libsmbclient update.

It's your call to make, but I wouldn't base the decision on whether it
was in stable updates or updates-testing. Both are currently enabled by
default in F17.

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

Re: Review swaps

[Richard W.M. Jones]

On Mon, Apr 23, 2012 at 09:34:35AM +0100, Pádraig Brady wrote:
> Hi!
> 
> I've a simple new package containing some
> support scripts for the OpenStack packages:
> https://bugzilla.redhat.com/show_bug.cgi?id=811601

This looks very simple, so I took it.

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 Xen guests.
http://et.redhat.com/~rjones/virt-p2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Review swaps

[Pádraig Brady]

Hi!

I've a simple new package containing some
support scripts for the OpenStack packages:
https://bugzilla.redhat.com/show_bug.cgi?id=811601

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel