Re: Proposed F19 Feature: Replace MySQL with MariaDB

[Adam Williamson]

On Wed, 2013-01-23 at 02:12 -0500, Tom Lane wrote:
> Bill Nottingham  writes:
> > Tom Lane (t...@redhat.com) said: 
> >> (If the compatibility testing goes *really* smoothly, maybe we could
> >> just drop the requirement for original mysql to still be available,
> >> in which case it reduces to the standard package-replacement problem.
> >> But I'm not prepared to bet on that quite yet.)
> 
> > Honestly, I'd be curious as to whether we could get all the compatibility
> > testing done early enough, and packages changed, such that we could consider
> > dropping MySQL. It's just... cleaner.
> 
> Quite honestly, I'd prefer that too.  But we need to have a good case
> that it's not going to break very many things for very many people.
> Database people hate it when you break their database.  So ... as
> mentioned in the feature page, we really need help testing this during
> the F19 devel cycle.  We'll need to make decisions before we reach
> alpha/beta stage.

Yeah, 'all the compatibility testing' is something of a vague idea to
pin down :) We can certainly run a couple of test days and ask as many
people as possible to try Maria on their setups and make sure nothing's
amiss, but it's the kind of thing where it's pretty hard to know you've
covered everything. I'm no SQL expert and I'm not sure who is; is there
anyone who's well-experienced in this area who would be willing to lead
testing efforts? Is there any kind of well-known, respected test suite
for MySQL?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: Proposed F19 Feature: Replace MySQL with MariaDB

[Tom Lane]

Bill Nottingham  writes:
> Tom Lane (t...@redhat.com) said: 
>> (If the compatibility testing goes *really* smoothly, maybe we could
>> just drop the requirement for original mysql to still be available,
>> in which case it reduces to the standard package-replacement problem.
>> But I'm not prepared to bet on that quite yet.)

> Honestly, I'd be curious as to whether we could get all the compatibility
> testing done early enough, and packages changed, such that we could consider
> dropping MySQL. It's just... cleaner.

Quite honestly, I'd prefer that too.  But we need to have a good case
that it's not going to break very many things for very many people.
Database people hate it when you break their database.  So ... as
mentioned in the feature page, we really need help testing this during
the F19 devel cycle.  We'll need to make decisions before we reach
alpha/beta stage.

It strikes me that we missed a bet in setting up the mariadb package
for only F19-and-up in git.  If we made a version available for F18,
that would allow people to test compatibility without having to run
rawhide, which is something that would give most DBAs the willies.
However, that would require facing the problem of how to declare the
package vis-a-vis mysql, since we surely can't drop mysql from F18.
So I could still use some advice as to how we might work the
provides-obsoletes-conflicts mechanics for that.

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Self introduction

[Juerg Haefliger]

On Tue, Jan 22, 2013 at 8:33 AM, Dan Mashal  wrote:
> On Mon, Jan 21, 2013 at 11:12 PM, Juerg Haefliger  wrote:
>> Hi everyboy,
>>
>> My name is Juerg Haefliger and I'm a software engineer with
>> Hewlett-Packard based in Switzerland. Part of my responsibilities is
>> building guest images for the HP cloud that runs OpenStack. Although
>> we use Ubuntu on bare metal, thanks to my imaging work I'm exposed to
>> different distro flavors and the pain and joy that come with it :-)
>> In terms of open source contributions, I'm a developer and maintainer
>> of two hardware monitoring kernel drivers which are part of the
>> lm-sensors project and I've also contributed to cloud-init which is a
>> customization tool for cloud images.
>>
>> My main interest at the moment is to bring some new packages to Fedora
>> and RHEL to support cloud images, so be on the lookout for a sponsor
>> request shortly :-)
>>
>> Best
>
>
> Welcome Juerg.

Thank Dan

> What packages do you plan on submitting?

cloud-utils and cloud-initramfs-tools to support automatic partition
growing for cloud images.


> Here are some links to help you get started:
>
> http://fedoraproject.org/wiki/How_to_create_an_RPM_package
>
> http://fedoraproject.org/wiki/Packaging:NamingGuidelines
>
> http://fedoraproject.org/wiki/Package_Review_Process
>
> http://fedoraproject.org/wiki/Packaging:Guidelines
>
> http://fedoraproject.org/wiki/Packaging:ReviewGuidelines

Thanks. I went through most of those already. Still need to tweak the
packages a little before I can initiate the review process.

...Juerg



>
> See ya around.
>
> Dan
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora ARM VFAD - 2013-01-23

[Jens Petersen]

> 3) ghc - using LLVM as compiler, as a result incorrect triplet

Not sure what this is referring to: ghc ARM devel for F18 is
basically done (except for a few minor libs appearing
in the Branch report that need rebuilding) and working fine.

Maybe this is referring to this Rawhide llvm issue
https://bugzilla.redhat.com/show_bug.cgi?id=893294
which I don't think should be on the F18ARMBLocker list,
and hopefully will be fixed in llvm-3.1-13.fc19
which is currently building.

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

Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation

[Toshio Kuratomi]

On Wed, Jan 16, 2013 at 08:05:23AM -0500, Jaroslav Reznik wrote:
> As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
> to pass through the community review by announcing them on devel-announce 
> list.
> FESCo votes on new features no sooner than a week from the announcement.
> 
> = Features/JRuby 1.7 =
> https://fedoraproject.org/wiki/Features/JRuby_1.7
> 
> * Detailed description:
> Transition to JRuby 1.7 will consist of 3 basic steps:
> 
> - Updating packages
>  Most of the packages that JRuby depends on are in Fedora just because of 
> JRuby, 
>  so they can be safely updated.
>  Some dependencies are shared with other packages, so they will have to be 
>  discussed with their owners (see #Scope). 
> 
> - Integration with Fedora
>  Normally, each Ruby implementations ships with its own copy of RubyGems 
>  library. This is wrong because a) it's bundling, b) there is no reason 
>  why multiple Ruby implementations wouldn't be able to share one RubyGems 
>  library. There used to be some differencies in JRuby's copy of RubyGems, 
>  but the JRuby upstream has been very cooperative and managed to get them 
>  all merged into upstream RubyGems.
>  The integration will require changing Fedora's operating_system.rb (place 
>  for distro-specific defaults for RubyGems). This change will result into 
>  all Gems with binary extensions having to be recompiled, as the binary 
>  extension placement will change. See [1] for current operating_system.rb 
>  look and its changes from F18.
>  What should "/usr/bin/ruby" point to? During standard Gem packaging process,
>  the executable files in Gems get shebangs according to the binary that they
>  are packaged with (Ruby => "/usr/bin/ruby"; JRuby => "/usr/bin/jruby"). 
>  Therefore executing a Ruby "binary" runs the interpreter that was used for 
>  building (or the hardcoded one, which is usually Ruby). Using alternatives 
>  for "/usr/bin/ruby" doesn't seem to be a very good option, because Ruby and
>  JRuby are not in fact full alternatives, as they for example cannot use same
>  extension Gems (but it still makes sense to allow executing same binaries 
>  with them). Also, alternatives are only switchable on admin level (we want
>  every developer with non-root privileges to be able to choose the 
>  interpreter). Therefore Ruby-SIG has come up with solution of having 
>  "/usr/bin/ruby" as a bash script (currently called rubypick) [2], that 
>  allows user to choose the interpreter as first argument on invocation 
>  (_mri_ or _jruby_), if such a parameter is present. Otherwise it falls 
>  back to a default. For example invoking "ruby_binary _jruby_ --foo=bar" 
>  in fact invokes "/usr/bin/jruby ruby_binary --foo=bar". This bash script 
>  will be in a separate package and both Ruby and JRuby will depend on it.
>  Ruby-SIG knows that this feature might be controversial and we wouldn't 
>  want it to stop us from bringing JRuby's power to Fedora (if met with a 
>  heavy resistance). So if anyone will suggest a more suitable solution, 
>  we'll go with it instead of this one. 
> 
> - Changes in packaging
>  None yet. JRuby will be able to use pure Ruby Gems packaged into RPM out of 
>  the box, but packaging of Gems with JRuby extensions is turning out to be 
>  very complicated, so the guidelines for it will be postponed to next release 
>  (as well as the actual packaging). Users will be still able to install Gems 
>  with JRuby extensions, both system-wide (into /usr/local/) and into their 
>  home directories. 
> 
> [1] 
> https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_system.rb
> [2] https://github.com/bkabrda/rubypick 
>
As JRuby is setup to share pure ruby gems with ruby, I don't think this can
be approved (inlcuding the update to the jruby package to do this) until FPC
rules on whether it's okay for interpreters and languages which are not
completely compatible to share modules.  FPC will hopefully have quorum
tomorrow morning to meet.  If not, or if they have issues with the
guidelines, perhaps slavek and I can meet to try to figure out ways around
the issues.  I'll know more after the FPC meeting time tomorrow morning.

-Toshio


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

Re: 'Nice to have' process is now 'Freeze exception' process, improvements to blocker / freeze exception tracker aliases

[Bruno Wolff III]

On Tue, Jan 22, 2013 at 19:30:25 -0800,
  Adam Williamson  wrote:


There was a very solid consensus that the old scheme sucked and the
final form of the new proposal was miles better, and this is not the
first time the topic has come up (there are various proposals in the
list archives). So I decided to go ahead and Just Do It, putting the
proposal into 'production' today. I have adjusted the tracker bugs
themselves,


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

Re: 'Nice to have' process is now 'Freeze exception' process, improvements to blocker / freeze exception tracker aliases

[Adam Williamson]

On Tue, 2013-01-22 at 19:30 -0800, Adam Williamson wrote:

> I can think of a couple of potential issues with the 'dynamic' tracker
> names (I'm not sure whether nominations will 'transfer' from one release
> to the next when we change where the alias points, and if so, whether we
> want that, especially for closed bugs),

I just tested this in Landfill, it doesn't seem to be a problem -
bugzilla displays the alias, not the bug number, in the Blocks: field
but it actually *uses* the bug number. So if you mark Bug #100 as
blocking AlphaBlocker (the alias of Bug #1), then transfer that alias
from Bug #1 to Bug #2, Bug #100 continues to block Bug #1, not Bug #2.
So that's fine.
-- 
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

'Nice to have' process is now 'Freeze exception' process, improvements to blocker / freeze exception tracker aliases

[Adam Williamson]

Hey folks!

At FUDCon Lawrence, Tim Flink presented on the Fedora blocker bug and
'NTH' processes, and we got some interesting and useful feedback. People
felt that the 'nice to have' / 'accepted' name used in that process was
confusing and difficult to understand, and that the aliases used for the
tracker bugs were inconsistent.

We developed a proposal to rename the aliases and the 'nice to have'
process. This was refined over the period of a few days' discussion on
the test@ mailing list: see
https://lists.fedoraproject.org/pipermail/test/2013-January/113363.html
for the thread.

There was a very solid consensus that the old scheme sucked and the
final form of the new proposal was miles better, and this is not the
first time the topic has come up (there are various proposals in the
list archives). So I decided to go ahead and Just Do It, putting the
proposal into 'production' today. I have adjusted the tracker bugs
themselves,
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers ,
https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process ,
https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting , and renamed
https://fedoraproject.org/wiki/QA:SOP_nth_bug_process to
https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process and
adjusted it. I have also made the obvious changes to the relatively
large number of other wiki pages that link to and talk about the 'nth' /
'freeze exception' process: see my Wiki edit history for those changes.

Here are the practical changes:

The 'nice to have' / 'NTH' process is now the 'freeze exception'
process: thanks to Jared Smith for the name (though I believe it's
actually a resurrection from the old 'freeze exception request' process,
which was a better name but a much worse process). This name, very much
unlike the other one, 'does what it says on the tin': the freeze
exception process is how you request freeze exceptions. Seems pretty
simple. 'Freeze exception' is kind of jargon, but it's pretty standard
terminology in the tech world, doing a web search for it gives you
useful results that explain what it is, as noted it is terminology
Fedora has used in the past, and we could not think of a way of
concisely expressing the concept in non-jargon English.

The 'new style' tracker bug aliases are as follows:

AlphaBlocker
AlphaFreezeException
BetaBlocker
BetaFreezeException
FinalBlocker
FinalFreezeException

These names are consistent and, again, 'do what they say on the tin'. We
were using aliases ending with "-accepted" for NTH bugs before, which
was a really terrible idea (not least because it meant we used the word
'accepted' in two entirely different ways in one process), and the Final
aliases did not follow the same pattern as the Alpha and Beta ones.

These primary aliases do not need to be versioned, as Kamil Paral
perceptively pointed out: as they are only aliases and can be
transferred from bug to bug, we can file a new set of tracker bugs for
each release, but transfer these unversioned aliases at the time of each
release. So right now these aliases are applied to the F19 trackers: at
the time of F19 release, they will be transferred to the F20 trackers.
This basically means that, at any point in time, you can simply mark a
bug as blocking 'AlphaBlocker' and it will be nominated as blocking the
next Alpha release.

Versioned aliases will still be applied to all the tracker bugs, so that
we can find older ones when we need to and so that a consistent naming
scheme is always available for all releases. This format will be used:

F18AlphaBlocker
F18AlphaFreezeExcept
F18BetaBlocker
F18BetaFreezeExcept
F18FinalBlocker
F18FinalFreezeExcept

The shortening of 'Exception' to 'Except' is unfortunately forced upon
us by a Bugzilla limit of 20 characters for alias names. I have
submitted a bug requesting this limit be raised: if this is done, the
versioned aliases will be changed to follow the format of the
unversioned (FreezeException instead of FreezeExcept). I have not yet
filed the Fedora 20 tracker bugs as the text in the tracker bug
descriptions refers to these aliases and cannot easily be changed after
the bug is filed, so I am waiting to see the resolution of this issue
before I file those bugs to ensure accurate text can be included.

As our Bugzilla allows for multiple aliases to be applied to bugs, bugs
can have both the dynamic aliases and their static aliases applied at
once, we can maintain 'backwards compatibility', and old trackers can
have the new-style aliases applied to them so you can always use the
same naming scheme to find the trackers for any release, even old ones.

The Fedora 19 tracker bugs consequently have three aliases each at
present: the 'dynamic' alias, the new-style versioned alias, and the
old-style alias, so people and tools which are used to searching for the
old names can still succeed. For example, the F19 Beta freeze exception
bug has the aliases 'BetaFreezeException', 'F19BetaFreezeExcept', and
'F19Beta-accep

Re: what is the current state of ext4 metadata checksums in Fedora?

[Eric Sandeen]

On 1/22/13 7:10 PM, Michał Piotrowski wrote:
> Hi,
> 
> Ext4 metadata checksums feature was merged into Linux 3.6. Can I use
> it out of the box with Fedora kernel or is there some magic switch to
> enable it?
> 
> Are there any plans to support it in e2fsprogs shipped in Fedora -
> backport or rebase to 1.43 version?
> 
> Last but equally important - how stable this feature is? Do anyone has
> any experience with it?

There is no 1.43 released yet, latest is 1.42.7 which I just built in rawhide.

The "WIP" branch in git has the metadata checksum bits, so you could play
with that if you want.

I have no plans to backport unreleased upstream work in progress to Fedora,
I don't think that'd be wise.

To be honest, I haven't yet done a whole lot of testing with it myself,
yet.

-Eric

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

Schedule for Wednesday's FESCo Meeting (2013-01-23)

[Bill Nottingham]

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC (1:00pm EST, 19:00 CET) in #fedora-meeting on
irc.freenode.net.

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

= Followups =

#topic #896 Refine Feature process
.fesco 896
https://fedorahosted.org/fesco/ticket/896

= New business =

#986F19 Feature: Fix Network Name Resolution - 
https://fedoraproject.org/wiki/Features/FixNetworkNameResolution
.fesco 986
https://fedorahosted.org/fesco/ticket/986

#996F19 Feature: BIND10 - https://fedoraproject.org/wiki/Features/BIND10
.fesco 996
https://fedorahosted.org/fesco/ticket/996

#997F19 Feature: Enlightement - 
https://fedoraproject.org/wiki/Features/Enlightenment
.fesco 997
https://fedorahosted.org/fesco/ticket/997

#998F19 Feature: Erlyvideo 
-https://fedoraproject.org/wiki/Features/Erlyvideo
.fesco 998
https://fedorahosted.org/fesco/ticket/998

#999F19 Feature: Fedora 19 Boost 1.53 Uplift - 
https://fedoraproject.org/wiki/Features/F19Boost153
.fesco 999
https://fedorahosted.org/fesco/ticket/999

#1000   F19 Feature: GCC 4.8.x - https://fedoraproject.org/wiki/Features/GCC48
.fesco 1000
https://fedorahosted.org/fesco/ticket/1000

#1001   F19 Feature: JRuby 1.7 - 
https://fedoraproject.org/wiki/Features/JRuby_1.7
.fesco 1001
https://fedorahosted.org/fesco/ticket/1001

#1002   F19 Feature: Ruby 2.0.0 - 
https://fedoraproject.org/wiki/Features/Ruby_2.0.0
.fesco 1002
https://fedorahosted.org/fesco/ticket/1002

#1003   F19 Feature: RemovePyXML - 
https://fedoraproject.org/wiki/Features/RemovePyXML
.fesco 1003
https://fedorahosted.org/fesco/ticket/1003

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Replace MySQL with MariaDB

[Bill Nottingham]

Tom Lane (t...@redhat.com) said: 
> Yes, that's the general idea --- any dependencies on mysql should result
> in installing mariadb, unless the user takes specific action to get
> mysql instead.  Ideally we'd just do the standard Provides/Obsoletes
> dance for replacing one package with another, but I'm not quite sure how
> that should work if we still want original mysql to be installable.  Any
> thoughts from RPM experts would be welcome.
> 
> (If the compatibility testing goes *really* smoothly, maybe we could
> just drop the requirement for original mysql to still be available,
> in which case it reduces to the standard package-replacement problem.
> But I'm not prepared to bet on that quite yet.)

Honestly, I'd be curious as to whether we could get all the compatibility
testing done early enough, and packages changed, such that we could consider
dropping MySQL. It's just... cleaner.

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

Re: Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Lennart Poettering]

On Mon, 21.01.13 10:25, Daniel P. Berrange (berra...@redhat.com) wrote:

> > The glibc maintainers don't seem to be against this idea and I am
> > willing to put time into design and implementation.
> 
> Perhaps I'm misunderstanding what you're after, but doesn't "getaddrinfo_a"
> already provide an async version of getaddrinfo ?
> 
> "Asynchronous Hostname Lookup API"
>http://www.akkadia.org/drepper/asynchnl.pdf
> 
> That said I don't see the reverse - getnameinfo_a

Bh. It's designed around process signal delivery. I am
shuddering. 

Lennart

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

what is the current state of ext4 metadata checksums in Fedora?

[Michał Piotrowski]

Hi,

Ext4 metadata checksums feature was merged into Linux 3.6. Can I use
it out of the box with Fedora kernel or is there some magic switch to
enable it?

Are there any plans to support it in e2fsprogs shipped in Fedora -
backport or rebase to 1.43 version?

Last but equally important - how stable this feature is? Do anyone has
any experience with it?

-- 
Best regards,
Michal

http://eventhorizon.pl/
https://getactive.pl/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora ARM VFAD - 2013-01-23

[Paul Whalen]

Good evening all, 

Please join us tomorrow in #fedora-arm on Freenode for a VFAD to address our 
final
blockers for F18 RC1 for ARM.
Let's start off with a short meeting beginning at 10am (EST) to discuss the 
remaining 
items - what needs to be done and who will be assisting with each part. 

F18 RC1 Blocker list
-
1) eclipse - build in progress
   - http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=108801
   - https://bugzilla.redhat.com/show_bug.cgi?id=863801

2) js (pkexec/PackageKit) - https://bugzilla.redhat.com/show_bug.cgi?id=892382

3) ghc - using LLVM as compiler, as a result incorrect triplet
  
4) DTB Distribution for F18  - Work currently in progress, kernel-dtb subpackage
 - update on status


Paul

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

x2go and nx-libs

[Orion Poplawski]

I'm starting to look at packaging up x2go (http://x2go.org) which appears to 
be taking up the charge of maintaining the nx libraries as well as developing 
new tools around it.


So the proposal would be to replace the current "nx" packages with a "nx-libs" 
package using the x2go sources.  Some initial notes are here:

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

Existing nx packages (qtnx, remmina-plugins-nx, freenx-client, freenx-server, 
nxssh) would need to be ported to the new nx-libs package, which hopefully is 
just a matter of using the new names.


I have some current and ongoing work up at 
http://www.cora.nwra.com/~orion/fedora/nx/


Please take a look and provide feedback.

Thank you.

--
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: Why do we have a kernel with version number - 20X?

[Peter Robinson]

On 22 Jan 2013 20:35, "Josh Boyer"  wrote:
>
> On Tue, Jan 22, 2013 at 01:23:44PM -0600, Bruno Wolff III wrote:
> > On Tue, Jan 22, 2013 at 14:13:23 -0500,
> >   Przemek Klosowski  wrote:
> > >On 01/19/2013 05:50 PM, Bruno Wolff III wrote
> > >
> > >>>The hundreds series is speific to the fedora version. Currently
> > >>>f17 is 1xx and f18 is 2xx. The purpose is to keep f18 versions
> > >>>ahead of f17 versions so that updates will work better.
> > >..
> > >>Presumably as new kernels come out the base number will change to
> > >>reflect the currently supported versions of Fedora. So that for the
> > >>3.9 kernel, f18  will probably be 1xx and f19 2xx.
> > >
> > >
> > >That's a pretty arcane scheme. Would it work to use 17xx, 18xx and
> > >19xx instead?
> >
> > Probably. Putting the release after the dist tag would also probably
> > work.
>
> We're not changing it again.  It's just a number.  The only reason
> anyone even noticed is because it was a jump, but we've already been
> doing this for months.

I agree. We really don't need a discussion as to the colour of the bike,
the people who are maintaining shed have made the decision it will work.

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

Re: Proposed F19 Feature: Replace MySQL with MariaDB

[Tom Lane]

Kevin Fenzi  writes:
> Would this involve moving around any of the provides for mysql over to
> MariaDB?

Yes, that's the general idea --- any dependencies on mysql should result
in installing mariadb, unless the user takes specific action to get
mysql instead.  Ideally we'd just do the standard Provides/Obsoletes
dance for replacing one package with another, but I'm not quite sure how
that should work if we still want original mysql to be installable.  Any
thoughts from RPM experts would be welcome.

(If the compatibility testing goes *really* smoothly, maybe we could
just drop the requirement for original mysql to still be available,
in which case it reduces to the standard package-replacement problem.
But I'm not prepared to bet on that quite yet.)

> Also, what about those packages depending on unversioned "mysql"? 
> move those in the next cycle when mysql is completely dropped?

We could leave 'em as is, couldn't we?

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Replace MySQL with MariaDB

[Kevin Fenzi]

On Tue, 22 Jan 2013 15:25:46 -0500
Tom Lane  wrote:

> Bill Nottingham  writes:
> > Jaroslav Reznik (jrez...@redhat.com) said: 
> >> We would like to replace MySQL with MariaDB in early development
> >> cycle for Fedora 19. MySQL will continue to be available for at
> >> least one release, but MariaDB will become the default. Also, we
> >> do not intend to support concurrent installation of both packages
> >> on the same machine; pick one or the other.
> 
> > What does it mean to replace it as the default if neither is ever
> > installed in a default 'next -> next -> next' installation?
> 
> "Default" might not be the exactly correct word here.  The main thing
> I'm expecting would be that the "mysql database" package group would
> actually give you mariadb, as would the anaconda checkbox.

Would this involve moving around any of the provides for mysql over to
MariaDB?

Also, what about those packages depending on unversioned "mysql"? 
move those in the next cycle when mysql is completely dropped?

kevin


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

Re: Why do we have a kernel with version number - 20X?

[Josh Boyer]

On Tue, Jan 22, 2013 at 01:23:44PM -0600, Bruno Wolff III wrote:
> On Tue, Jan 22, 2013 at 14:13:23 -0500,
>   Przemek Klosowski  wrote:
> >On 01/19/2013 05:50 PM, Bruno Wolff III wrote
> >
> >>>The hundreds series is speific to the fedora version. Currently
> >>>f17 is 1xx and f18 is 2xx. The purpose is to keep f18 versions
> >>>ahead of f17 versions so that updates will work better.
> >..
> >>Presumably as new kernels come out the base number will change to
> >>reflect the currently supported versions of Fedora. So that for the
> >>3.9 kernel, f18  will probably be 1xx and f19 2xx.
> >
> >
> >That's a pretty arcane scheme. Would it work to use 17xx, 18xx and
> >19xx instead?
> 
> Probably. Putting the release after the dist tag would also probably
> work.

We're not changing it again.  It's just a number.  The only reason
anyone even noticed is because it was a jump, but we've already been
doing this for months.

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

Re: Proposed F19 Feature: GCC48 - switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it

[Jakub Jelinek]

On Tue, Jan 22, 2013 at 09:22:00PM +0100, Erik van Pienbroek wrote:
> Jaroslav Reznik schreef op wo 16-01-2013 om 12:35 [-0500]:
> > See 
> > https://lists.fedoraproject.org/pipermail/devel/2013-January/175876.html 
> > for details. Once gcc-4.8.0-* is built into Fedora, after a few days or 
> > weeks
> > a mass rebuild should be performed. 
> 
> I see that gcc 4.8 was just imported in rawhide some hours ago. What's
> the plan next? Will the rebuilds happen in a side-tag or in the master

It hasn't been imported into rawhide yet, it was just built (first two
non-scratch builds) and (almost) immediately untagged, just so that before
tomorrow's FeSCo meeting there are packages already available and ready to
be tagged into f19 instantly.

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

Re: Proposed F19 Feature: Replace MySQL with MariaDB

[Tom Lane]

Bill Nottingham  writes:
> Jaroslav Reznik (jrez...@redhat.com) said: 
>> We would like to replace MySQL with MariaDB in early development cycle for 
>> Fedora 19. MySQL will continue to be available for at least one release, but
>> MariaDB will become the default. Also, we do not intend to support concurrent
>> installation of both packages on the same machine; pick one or the other.

> What does it mean to replace it as the default if neither is ever installed
> in a default 'next -> next -> next' installation?

"Default" might not be the exactly correct word here.  The main thing
I'm expecting would be that the "mysql database" package group would
actually give you mariadb, as would the anaconda checkbox.

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: GCC48 - switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it

[Erik van Pienbroek]

Jaroslav Reznik schreef op wo 16-01-2013 om 12:35 [-0500]:
> See https://lists.fedoraproject.org/pipermail/devel/2013-January/175876.html 
> for details. Once gcc-4.8.0-* is built into Fedora, after a few days or weeks
> a mass rebuild should be performed. 

I see that gcc 4.8 was just imported in rawhide some hours ago. What's
the plan next? Will the rebuilds happen in a side-tag or in the master
branch and when is it scheduled? We on the Fedora MinGW side are ready
to import mingw-gcc 4.8 in rawhide as well and we would like to know
what's going to happen next so we make the necessary preparations.

Introducing mingw-gcc 4.8 is a bit more painful for us at the moment as
upstream has decided to use a different exception handling model for the
win64 target starting with gcc 4.8 (SEH instead of SjLj). Therefore
various packages need to be rebuilt soon after the introduction of
mingw-gcc 4.8 to avoid broken dependencies.

Regards,

Erik van Pienbroek
Fedora MinGW SIG


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

Self introduction

[Ben Harper]

Hello Fedora faithful,

My name is Ben Harper and work for Rackspace as a RPM developer in 
Austin, TX.  My duties include creating RPMs for internal use, but also 
for iuscommunity.org (IUS).  IUS provides new versions of packages found 
in RHEL.  I am looking to become a package maintainer for EPEL.  There 
are some cases where IUS packages have dependences that are not 
available from packages provided by RHEL and should be provided by EPEL.


Currently I do not have package I am looking to get approved, but just 
looking for a sponsor.  I would like to prove that I can follow the 
documation and create quality packages.  I have been reading over the 
docs and created the needed accounts with this email account.


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

File Sub-Exporter-Progressive-0.001008.tar.gz uploaded to lookaside cache by pghmcfc

[Paul Howarth]

A file has been added to the lookaside cache for perl-Sub-Exporter-Progressive:

d80a27859c13d471019c75494409282e  Sub-Exporter-Progressive-0.001008.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Why do we have a kernel with version number - 20X?

[Matthew Miller]

On Tue, Jan 22, 2013 at 11:44:11AM -0800, Josh Stone wrote:
> > 7xx, 8xx, 9xx, 0xx,
> > The first number of a Fedora release seems mostly superfluous.
> 9xx->0xx breaks the goal "that updates will work better".

Also would be unnecessarily confusing. It's not like we're running out of
numbers here.

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

Re: Strange Build problem....

[Nicolas Mailhot]

Le Sam 19 janvier 2013 13:34, Paulo César Pereira de Andrade a écrit :
> 2013/1/19 Nicolas Mailhot :

>   Do you have any hints on working on option 3? Well, that means not
> using fontconfig, so might not be worth for a generic Linux solution...

What renderer is matplotlib using now ? Because IIRC it could use cairo,
and cairo does support complex font shaping and modern font formats via
pango-cairo. 5-6 years ago at an xorg text summit people agreed to
converge on a single text rendering stack, and we are finally getting
there with QT and GTK both using harfbuzz-ng (+ libreoffice, firefox, etc)

The text stack should look like

freetype
   ↓
fontconfig
   ↓
harfbuzz-ng
   ↓
upper layers : QT, gtk → pango, cairo → pango, etc

-- 
Nicolas Mailhot

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

Re: Why do we have a kernel with version number - 20X?

[Josh Stone]

On 01/22/2013 11:28 AM, Chris Murphy wrote:
> 7xx, 8xx, 9xx, 0xx,
> 
> The first number of a Fedora release seems mostly superfluous.

9xx->0xx breaks the goal "that updates will work better".
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: To the Mate package maintainers

[Nicolas Mailhot]

Le Dim 20 janvier 2013 06:46, David Tardon a écrit :
> Hi,
>
> On Sat, Jan 19, 2013 at 03:20:29PM +0100, Vít Ondruch wrote:
>> Dne 19.1.2013 12:46, Tomasz Torcz napsal(a):
>> >On Sat, Jan 19, 2013 at 11:11:29AM +0100, Michael Schwendt wrote:
>> >>On Fri, 18 Jan 2013 18:10:06 -0500, Sam Varshavchik wrote:
>> >>
>> >>>I see that Gnome's lock screen now shows a pretty clock, after the
>> display
>> >>>wakes up, that must be "swiped" away in order to unlock the desktop.
>> >>I just hit "Enter" or "Return" to achieve the same.
>> >  Or "Esc".
>> >
>>
>> Or scroll by mouse wheel ... I love it :)
>
> Great. That makes third obsucre mechanism just to unlock screen (or,
> rather, just to show the password field).
>

But do not try to wake it up by pressing num lock twice fast. It should be
a noop but you can hit a gnome race and hose the system

-- 
Nicolas Mailhot

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

Re: Why do we have a kernel with version number - 20X?

[Chris Murphy]

On Jan 22, 2013, at 12:13 PM, Przemek Klosowski  
wrote:

> On 01/19/2013 05:50 PM, Bruno Wolff III wrote
> 
>>> The hundreds series is speific to the fedora version. Currently
>>> f17 is 1xx and f18 is 2xx. The purpose is to keep f18 versions
>>> ahead of f17 versions so that updates will work better.
> ..
>> Presumably as new kernels come out the base number will change to
>> reflect the currently supported versions of Fedora. So that for the
>> 3.9 kernel, f18  will probably be 1xx and f19 2xx.
> 
> 
> That's a pretty arcane scheme. Would it work to use 17xx, 18xx and 19xx 
> instead?

7xx, 8xx, 9xx, 0xx,

The first number of a Fedora release seems mostly superfluous.

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

Re: Why do we have a kernel with version number - 20X?

[Bruno Wolff III]

On Tue, Jan 22, 2013 at 14:13:23 -0500,
  Przemek Klosowski  wrote:

On 01/19/2013 05:50 PM, Bruno Wolff III wrote


The hundreds series is speific to the fedora version. Currently
f17 is 1xx and f18 is 2xx. The purpose is to keep f18 versions
ahead of f17 versions so that updates will work better.

..

Presumably as new kernels come out the base number will change to
reflect the currently supported versions of Fedora. So that for the
3.9 kernel, f18  will probably be 1xx and f19 2xx.



That's a pretty arcane scheme. Would it work to use 17xx, 18xx and 
19xx instead?


Probably. Putting the release after the dist tag would also probably 
work.

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

Re: Why do we have a kernel with version number - 20X?

[Przemek Klosowski]

On 01/19/2013 05:50 PM, Bruno Wolff III wrote


The hundreds series is speific to the fedora version. Currently
f17 is 1xx and f18 is 2xx. The purpose is to keep f18 versions
ahead of f17 versions so that updates will work better.

..

Presumably as new kernels come out the base number will change to
reflect the currently supported versions of Fedora. So that for the
3.9 kernel, f18  will probably be 1xx and f19 2xx.



That's a pretty arcane scheme. Would it work to use 17xx, 18xx and 19xx 
instead?

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

Re: Install from ISO file supported

[Sergio Belkin]

2013/1/22 Przemek Klosowski 

> On 01/20/2013 11:43 PM, Rahul Sundaram wrote:
>
>> Hi
>>
>> On Sun, Jan 20, 2013 at 11:22 PM, Ray Strodewrote:
>>
>> Hi,
>>
>>  > I find it easier (and smaller) to download the netinst.iso (like
>>  > Fedora-18-x86_64-netinst.iso)
>>  > Loop-back mount and pull the vmlinuz and initrd.img into /boot
>> The vmlinuz and initrd are made available separately here:
>>
>> http://mirrors.kernel.org/**fedora//releases/18/Fedora/**
>> x86_64/os/images/pxeboot/
>>
>> So you can avoid the loop-back mount.  It's a good tip, though.
>> Sometimes creating a grub entry is the most straightforward way to get
>> things rolling.
>>
>>
>> Ideally, fedup should do this as a option.  If someone wants it, file a
>> RFE
>>
>
> I thought fedup does this already? What am I missing here---I just ran
> fedup for the first time the other day and it created a new default 'Update
> Fedora' entry during boot. How is it different from what you are discussing
> here?
>
>

We're talking about of using a LiveCD ISO file
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump

[Dan Horák]

Alexander Bokovoy píše v Út 22. 01. 2013 v 19:59 +0200: 
> On Tue, 22 Jan 2013, Petr Lautrbach wrote:
> >Hi all,
> >
> >I'm going to push update cyrus-sasl-2.1.26 into Rawhide soon. Part of this 
> >update
> >is also SONAME bump to libsasl2.so.3.
> Are there any reasons for soname bump? Could you please point out for
> those?
> 
> Are there are changes to existing API/structures?

like a report from abi-compliance-checker


Dan


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

Re: [fedora-arm] FUDCon ARM related followup

[Peter Robinson]

On Tue, Jan 22, 2013 at 12:55 PM, Jon Masters  wrote:
> Always was done with yaboot. Do we know if OLPC will move to UEFI?

I very much doubt it

> Sent from my phone. Please excuse formatting and brevity.
>
> Peter Robinson  wrote:
>
>> - Original Message -
>>> From: Peter Robinson 
>>> To: Development discussions related to Fedora 
>>> 
>>> Cc: a...@lists.fedoraproject.org
>>> Sent: Monday, January 21, 2013 6:28 PM
>>> Subject: Re: [fedora-arm] FUDCon ARM related followup
>>>
>>> On Mon, Jan 21, 2013 at 1:57 PM, Bruno Wolff III  wrote:
  On Sun, Jan 20, 2013 at 23:56:49 -0500,
Jonathan Masters  wrote:
>
>
>  We had a number of conversations about how to involve more people in
>  Fedora on ARM. We also had many other conversations that are being
>>> minuted
>  on the wiki, with more notes and links to follow. Now is a great time
>>> to
>  join arm@ and add your input.


  Since a number of Fedora developers where given XO 1.75s last summer,
  getting Fedora builds for those people might be a way to get more testing.
  (Yeah, they mostly use Fedora stuff now, but they don't use a Fedora
  kernel.)

  I have been testing OLPC builds, but that wipes my customizations, and
>>> I'd
  rather do more normal Fedora testing with it.
>>>
>>> Fedora kernels don't support them because they're not all up stream
>>> and we don't have support for OFW even where their kernels are
>>> upstream. That being said you can use Fedora relatively easily while
>>> still doing an initial install with the XO image and getting XO kernel
>>> updates but still receiving standard Fedora updates and installing all
>>> the other standard Fedora stuff using yum. I documented it here:
>>>
>>> http://nullr0ute.com/2012/09/using-fedora-on-your-shiny-new-olpc-xo/
>>
>> It doesn't seem like OF would be that hard to support, given PPC and sparc 
>> both use it, and it isn't -that- different then uBoot.
>
> Probably not too hard to support but I believe PPC support is via
> yaboot (or maybe now grub2) layered on top of OFW rather than directly
> supporting OFW.
>
> Peter
> ___
> arm mailing list
> a...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/arm
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump

[Alexander Bokovoy]

On Tue, 22 Jan 2013, Petr Lautrbach wrote:

Hi all,

I'm going to push update cyrus-sasl-2.1.26 into Rawhide soon. Part of this 
update
is also SONAME bump to libsasl2.so.3.

Are there any reasons for soname bump? Could you please point out for
those?

Are there are changes to existing API/structures?

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

Re: Proposed F19 Feature: Replace MySQL with MariaDB

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
> to pass through the community review by announcing them on devel-announce 
> list.
> FESCo votes on new features no sooner than a week from the announcement.
> 
> = Features/ReplaceMySQLwithMariaDB =
> https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB
> 
> * Detailed description:
> MariaDB is a fork of the MySQL database project that provides a drop-in 
> replacement for MySQL. It preserves API/ABI compatibility with MySQL and 
> adds some new features.
> 
> The original company behind MySQL, MySQL AB, were bought out by Sun which was 
> then bought by Oracle. Recent changes made by Oracle indicate they are moving 
> the MySQL project to be more closed. They are no longer publishing any useful 
> information about security issues (CVEs), and they are not providing complete 
> regression tests any more, and a very large fraction of the mysql bug 
> database 
> is now not public.
> 
> MariaDB, which was founded by some of the original MySQL developers, has a 
> more 
> open-source attitude and an active community. We have found them to be much 
> easier to work with, especially in regards to security matters.
> 
> We would like to replace MySQL with MariaDB in early development cycle for 
> Fedora 19. MySQL will continue to be available for at least one release, but
> MariaDB will become the default. Also, we do not intend to support concurrent
> installation of both packages on the same machine; pick one or the other.

What does it mean to replace it as the default if neither is ever installed
in a default 'next -> next -> next' installation?

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

Re: Coordinating libffi upgrade

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

El Thu, 17 Jan 2013 06:35:08 -0500 (EST)
Anthony Green  escribió:
> Dennis wrote:
> > I am right now building a compat-libffi package that has just the
> > old .so nothing to be built against. so expect that early this week
> > the .so of libffi will be bumped.
> 
> Hey, thanks Dennis!  I really appreciate this.
> 
> I'm hoping to release 3.0.12 soon and get that into the F19 release.
> Among other things, this include AArch64 support.
> 
> Anthony Green

No problem. seemed it was kinda important and needed doing. as long as
the soname of 3.0.12 doesnt change it should be simple. aarch64 support
will be needed :)

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

iEYEARECAAYFAlD+0rcACgkQkSxm47BaWfc8mACdG8ly6e52UA+sxhAe8dn2a+4B
KvwAnjSRnDkECahj6f/7zk0bGPtKkXcM
=k4Nx
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [fedora-arm] FUDCon ARM related followup

[Jon Masters]

Always was done with yaboot. Do we know if OLPC will move to UEFI?
-- 
Sent from my phone. Please excuse formatting and brevity.

Peter Robinson  wrote:

> - Original Message -
>> From: Peter Robinson 
>> To: Development discussions related to Fedora 
>> Cc: a...@lists.fedoraproject.org
>> Sent: Monday, January 21, 2013 6:28 PM
>> Subject: Re: [fedora-arm] FUDCon ARM related followup
>>
>> On Mon, Jan 21, 2013 at 1:57 PM, Bruno Wolff III  wrote:
>>>  On Sun, Jan 20, 2013 at 23:56:49 -0500,
>>>Jonathan Masters  wrote:


  We had a number of conversations about how to involve more people in
  Fedora on ARM. We also had many other conversations that are being
>> minuted
  on the wiki, with more notes and links to follow. Now is a great time
>> to
  join arm@ and add your input.
>>>
>>>
>>>  Since a number of Fedora developers where given XO 1.75s last summer,
>>>  getting Fedora builds for those people might be a way to get more testing.
>>>  (Yeah, they mostly use Fedora stuff now, but they don't use a Fedora
>>>  kernel.)
>>>
>>>  I have been testing OLPC builds, but that wipes my customizations, and
>> I'd
>>>  rather do more normal Fedora testing with it.
>>
>> Fedora kernels don't support them because they're not all up stream
>> and we don't have support for OFW even where their kernels are
>> upstream. That being said you can use Fedora relatively easily while
>> still doing an initial install with the XO image and getting XO kernel
>> updates but still receiving standard Fedora updates and installing all
>> the other standard Fedora stuff using yum. I documented it here:
>>
>> http://nullr0ute.com/2012/09/using-fedora-on-your-shiny-new-olpc-xo/
>
> It doesn't seem like OF would be that hard to support, given PPC and sparc 
> both use it, and it isn't -that- different then uBoot.

Probably not too hard to support but I believe PPC support is via
yaboot (or maybe now grub2) layered on top of OFW rather than directly
supporting OFW.

Peter
___
arm mailing list
a...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Install from ISO file supported

[Przemek Klosowski]

On 01/20/2013 11:43 PM, Rahul Sundaram wrote:

Hi

On Sun, Jan 20, 2013 at 11:22 PM, Ray Strodewrote:

Hi,

 > I find it easier (and smaller) to download the netinst.iso (like
 > Fedora-18-x86_64-netinst.iso)
 > Loop-back mount and pull the vmlinuz and initrd.img into /boot
The vmlinuz and initrd are made available separately here:


http://mirrors.kernel.org/fedora//releases/18/Fedora/x86_64/os/images/pxeboot/

So you can avoid the loop-back mount.  It's a good tip, though.
Sometimes creating a grub entry is the most straightforward way to get
things rolling.


Ideally, fedup should do this as a option.  If someone wants it, file a RFE


I thought fedup does this already? What am I missing here---I just ran 
fedup for the first time the other day and it created a new default 
'Update Fedora' entry during boot. How is it different from what you are 
discussing here?


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

[perl-Sysadm-Install] Update to 0.42

[Paul Howarth]

commit 3060956d5f15186b1b2a84bb4270659254997980
Author: Paul Howarth 
Date:   Tue Jan 22 16:47:00 2013 +

Update to 0.42

- New upstream release 0.42
  - No longer silently remove directories that are in the way before untar()
  - Better error diagnosis on failing untar() tests

 perl-Sysadm-Install.spec |7 ++-
 sources  |2 +-
 2 files changed, 7 insertions(+), 2 deletions(-)
---
diff --git a/perl-Sysadm-Install.spec b/perl-Sysadm-Install.spec
index c7abe7f..291c70e 100644
--- a/perl-Sysadm-Install.spec
+++ b/perl-Sysadm-Install.spec
@@ -1,6 +1,6 @@
 Summary:   Typical installation tasks for system administrators
 Name:  perl-Sysadm-Install
-Version:   0.41
+Version:   0.42
 Release:   1%{?dist}
 License:   GPL+ or Artistic
 Group: Development/Libraries
@@ -74,6 +74,11 @@ find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
 %{_mandir}/man3/Sysadm::Install.3pm*
 
 %changelog
+* Tue Jan 22 2013 Paul Howarth  0.42-1
+- Update to 0.42
+  - No longer silently remove directories that are in the way before untar()
+  - Better error diagnosis on failing untar() tests
+
 * Tue Dec 18 2012 Paul Howarth  0.41-1
 - Update to 0.41
   - Added home_dir() function returning user's home directory
diff --git a/sources b/sources
index 21ac734..0a2f762 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a70c90aaa5b00741f87fb16e6cd31336  Sysadm-Install-0.41.tar.gz
+9f9d3a7b174b8be45a326b833dd8401e  Sysadm-Install-0.42.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File Sysadm-Install-0.42.tar.gz uploaded to lookaside cache by pghmcfc

[Paul Howarth]

A file has been added to the lookaside cache for perl-Sysadm-Install:

9f9d3a7b174b8be45a326b833dd8401e  Sysadm-Install-0.42.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: installer final touches matters

[Máirín Duffy]

Please take discussions like these to the installer development list;
fedora-devel is too broad a list to discuss mintuae like this I think.

On 01/20/2013 05:15 AM, Muayyad AlSadi wrote:
> we see 3 items, one of them "no disk selected"
> it has the same level of importance as the rest two,
> I believe its background or foreground should be made red or orange.

Would it help if the bright orange /!\ icon immediately next to it was
larger?

> choosing the destination is scary, since people know there are some
> steps might wipe the entire disk, the screen below needs a way to gently
> tell the user that this step is not scare "the monster is not in this step"
> 
> http://i.minus.com/jWQMDfIBvDHZZ.png

That's a fair point.

> later steps should *tell* the user what to do
> eg. delete a partition then activate auto partitioning
> or create an ext4 mounted as /
> 
> always tell the user what is the problem and how can he/she fix it

Unfortunately, Anaconda can't read the user's mind as to what the user
is looking to achieve, but if you aren't trying to do something advanced
or complicated you'll be led through the guided installation path which
is very well documented and has a lot of explanatory language to guide
the user through. I noticed you didn't include screenshots of any of that.

~m

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

Re: installer final touches matters

[Máirín Duffy]

On 01/21/2013 07:37 PM, Kevin Kofler wrote:
> * DO NOT REWRITE code! It will ALWAYS break things!

You're joking, right? If nobody ever rewrote code... we wouldn't have Linux.

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

Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump

[Kevin Fenzi]

On Tue, 22 Jan 2013 09:31:37 -0600
Bruno Wolff III  wrote:

> If you expect simple rebuilds (just changing the version in the spec
> file) to work, you can ask for help from proven packagers and
> probably get it. I'd probably be able to help depending on the
> timing. Kevin has been known to do this kind of thing as well. The
> list doesn't look so long that the rebuilds couldn't be done in a
> short period of time manaully.

I'd be happy to help if you need someone with provenpackager. 

kevin


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

Re: installer final touches matters

[Kevin Fenzi]

On Tue, 22 Jan 2013 16:17:48 +0100
Kevin Kofler  wrote:

> John Reiser wrote:
> > I await documentation of claims that anaconda RAM requirements
> > have been "skyrocketing" over the last several releases.
> 
> The officially documented RAM requirements are, at least:
> RHL 9: http://www.gurulabs.com/downloads/RELEASE-NOTES-RHL9.html
> | Memory:
> | - Minimum for text-mode: 64MB
> | - Minimum for graphical: 128MB
> | - Recommended for graphical: 192MB
> F17:
> http://docs.fedoraproject.org/en-US/Fedora/17/html/Release_Notes/sect-
> Release_Notes-Welcome_to_Fedora_17.html#sect-Release_Notes-Hardware_Overview
> | Minimum RAM for text-mode: 768 MiB | Minimum RAM for graphical: 768
> MiB | Recommended RAM for graphical: 1152 MiB
> A 12-fold increase since the inception of Fedora.
> 
> (For F18, the memory requirements are entirely undocumented in the
> release notes.)

I have this strange sense of deja-vu. Like we have had this exact same
thread/conversation before. 

Why yes, yes we have: 
http://lists.fedoraproject.org/pipermail/devel/2012-November/173800.html

Can you please stop the argument by repetition ? 

It's getting very very old. 

kevin


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

Help figure out the debug slowness

[Justin M. Forbes]

As mentioned in the FUDCon kernel talk, we are trying to figure out
exactly what causes the massive slowdown for some people with debug
kernels. At this point, debug is completely off in the rawhide kernel.
Every update this week will turn on more debug options until we find out
which one is causing the slowdown. For this to work, we need people
testing rawhide proper (not rawhide-nodebug). So please, if you can
update daily and give us feedback when you hit a wall, we would really
appreciate it. Feedback should be sent to ker...@lists.fedoraproject.org

Thanks,
Justin

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

Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump

[Bruno Wolff III]

On Tue, Jan 22, 2013 at 16:13:49 +0100,
  Petr Lautrbach  wrote:


The rebuild will likely be in a side tag and things won't be fixed until the 
rebuild is complete. It may be better to do the manual rebuild for the affected 
packages.


At first I'd planned to do it manually so I requested a tag for these rebuilds 
too [1]. But with oncoming mass rebuild
I'm not really sure if I can manage all rebuilds before main rebuild given that 
I'm not a proven packager.

[1] https://fedorahosted.org/rel-eng/ticket/5451


If you expect simple rebuilds (just changing the version in the spec file) to 
work, you can ask for help from proven packagers and probably get it. I'd 
probably be able to help depending on the timing. Kevin has been known to 
do this kind of thing as well. The list doesn't look so long that the 
rebuilds couldn't be done in a short period of time manaully.

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

Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump

[Kevin Fenzi]

On Tue, 22 Jan 2013 08:53:06 -0600
Bruno Wolff III  wrote:

> On Tue, Jan 22, 2013 at 15:19:18 +0100,
>Petr Lautrbach  wrote:
> >It's my understanding that there will be mass rebuild soon so I
> >wouldn't rebuild all of them manually, but I would wait for this
> >rebuild.
> >
> >Comments? Suggestions?
> 
> The rebuild will likely be in a side tag and things won't be fixed
> until the rebuild is complete. It may be better to do the manual
> rebuild for the affected packages.

Yeah, I don't know if we plan to use a side tag or not, but I think
it's better for you to just rebuild all those packages when the change
is made. Are you a provenpackager? Or is there one you know willing to
help rebuild all those?

It's not yet clear when the mass rebuild will be yet... 

kevin


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

Re: New packager: Do the reviewer and the sponsor have to be the same

[Nicolas Mailhot]

Le Lun 21 janvier 2013 16:47, Susi Lehtola a écrit :
> On Mon, 21 Jan 2013 16:30:04 +0100
> Michael J Gruber  wrote:
>> I would like to help this poor soul get his package into Fedora:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=860249
>>
>> (adobe-source-code-pro-fonts)
>>
>> I'm a packager but no sponsor, he's no packager (so needs a sponsor).
>> It's not clear to me whether I can just make a formal review and ask a
>> sponsor to say "yes", or the new packager needs an actual review from
>> a sponsor (different pages seem to disagree somewhat on this).
>>
>> An old request for sponsorship on the fonts-SIG list has not been
>> answered so far, which is why I'm trying to help this way.
>
> Well, my opinion is: go for it. IMHO it's a lot easier to sponsor
> someone who already has shown his/her packaging skills. It's just less
> work for the sponsor... providing the review is of good quality.
>
> Now, of course the package won't make it into the repo before the
> packager has been sponsored.

The request looks good, if I had more free time to help a new packager I
wouldn't have a problem sponsoring him. As things stand I would be an
absentee sponsor which is something I want to avoid.

-- 
Nicolas Mailhot

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

Re: Proposed F19 Feature: Package Signature Checking During Installation

[Bruno Wolff III]

On Thu, Jan 10, 2013 at 23:43:07 +0100,
  Björn Persson  wrote:


And since people don't check the certificate anyway it would be better
if Firefox would silently switch to plain HTTP when it can't verify the
certificate? Not just use the unverified certificate but skip all the
cryptography altogether without even telling the user about it? Would
that improve anything? Because that's the equivalent of what Anaconda
does.


It would be better if it just noted that it didn't trust the certificate 
chain and continued using https, since that would still provide protection 
from eaves dropping by passive attackers.

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

[perl-ZMQ-LibZMQ3/f17] * First Fedora build.

[Jose Pedro Oliveira]

Summary of changes:

  aa1c16c...  * First Fedora build. (*)

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

[perl-ZMQ-LibZMQ3/f18] * First Fedora build.

[Jose Pedro Oliveira]

Summary of changes:

  aa1c16c...  * First Fedora build. (*)

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

Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump

[Marcela Mašláňová]

On 01/22/2013 03:53 PM, Bruno Wolff III wrote:

On Tue, Jan 22, 2013 at 15:19:18 +0100,
   Petr Lautrbach  wrote:

It's my understanding that there will be mass rebuild soon so I
wouldn't rebuild all of them manually,
but I would wait for this rebuild.

Comments? Suggestions?


The rebuild will likely be in a side tag and things won't be fixed until
the rebuild is complete. It may be better to do the manual rebuild for
the affected packages.


I don't think mass rebuilds are done in side tag.

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

Re: installer final touches matters

[Kevin Kofler]

John Reiser wrote:
> I await documentation of claims that anaconda RAM requirements
> have been "skyrocketing" over the last several releases.

The officially documented RAM requirements are, at least:
RHL 9: http://www.gurulabs.com/downloads/RELEASE-NOTES-RHL9.html
| Memory:
| - Minimum for text-mode: 64MB
| - Minimum for graphical: 128MB
| - Recommended for graphical: 192MB
F17: http://docs.fedoraproject.org/en-US/Fedora/17/html/Release_Notes/sect-
Release_Notes-Welcome_to_Fedora_17.html#sect-Release_Notes-Hardware_Overview
| Minimum RAM for text-mode: 768 MiB 
| Minimum RAM for graphical: 768 MiB 
| Recommended RAM for graphical: 1152 MiB
A 12-fold increase since the inception of Fedora.

(For F18, the memory requirements are entirely undocumented in the release 
notes.)

Kevin Kofler

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

Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump

[Petr Lautrbach]

On 01/22/2013 03:53 PM, Bruno Wolff III wrote:

On Tue, Jan 22, 2013 at 15:19:18 +0100,
Petr Lautrbach  wrote:

It's my understanding that there will be mass rebuild soon so I wouldn't 
rebuild all of them manually,
but I would wait for this rebuild.

Comments? Suggestions?


The rebuild will likely be in a side tag and things won't be fixed until the 
rebuild is complete. It may be better to do the manual rebuild for the affected 
packages.


At first I'd planned to do it manually so I requested a tag for these rebuilds 
too [1]. But with oncoming mass rebuild
I'm not really sure if I can manage all rebuilds before main rebuild given that 
I'm not a proven packager.

[1] https://fedorahosted.org/rel-eng/ticket/5451

Petr


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

Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump

[Bruno Wolff III]

On Tue, Jan 22, 2013 at 15:19:18 +0100,
  Petr Lautrbach  wrote:

It's my understanding that there will be mass rebuild soon so I wouldn't 
rebuild all of them manually,
but I would wait for this rebuild.

Comments? Suggestions?


The rebuild will likely be in a side tag and things won't be fixed until 
the rebuild is complete. It may be better to do the manual rebuild for 
the affected packages.

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

Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump

[Petr Lautrbach]

Hi all,

I'm going to push update cyrus-sasl-2.1.26 into Rawhide soon. Part of this 
update
is also SONAME bump to libsasl2.so.3.

The main issue with this update is that it would break buildroot since there is 
the openldap
package requiring libsasl2.so.2 which is part of buildroot. So I'll do needed 
steps in co-operation
with Jan Vcelak - the openldap maintainer - in order not to break it.

There are also several other packages dependent on libsasl2.so.2 [1], which 
will need rebuild.
It's my understanding that there will be mass rebuild soon so I wouldn't 
rebuild all of them manually,
but I would wait for this rebuild.

Comments? Suggestions?

Thanks,

Petr

[1] # repoquery -s --whatrequires --alldeps 'libsasl2.so*' | uniq
389-admin-1.1.31-1.fc19.1.src.rpm
389-ds-base-1.3.0.2-1.fc19.src.rpm
389-dsgw-1.1.9-3.fc18.src.rpm
argus-3.0.4-3.fc18.src.rpm
autofs-5.0.7-10.fc19.src.rpm
claws-mail-3.9.0-1.fc19.src.rpm
cyrus-imapd-2.4.17-1.fc19.src.rpm
cyrus-sasl-2.1.25-2.fc19.src.rpm
ekiga-4.0.0-2.fc19.src.rpm
evolution-data-server-3.7.4-1.fc19.src.rpm
exim-4.80.1-1.fc19.src.rpm
freeipa-3.1.0-1.fc19.src.rpm
gtk-vnc-0.5.1-5.fc19.src.rpm
kdebase3-3.5.10-21.fc18.src.rpm
kdepim-4.9.97-1.fc19.src.rpm
kdepimlibs-4.9.98-1.fc19.src.rpm
libetpan-1.1-3.fc18.src.rpm
libguestfs-1.21.2-2.fc19.src.rpm
libmemcached-1.0.15-1.fc19.src.rpm
nufw-2.4.3-6.fc18.src.rpm
pidgin-2.10.6-4.fc19.src.rpm
libvirt-1.0.1-4.fc19.src.rpm
mozldap-6.0.5-9.fc18.src.rpm
mutt-1.5.21-16.fc19.src.rpm
myproxy-5.9-2.fc19.src.rpm
nss_ldap-265-10.fc17.src.rpm
nufw-2.4.3-6.fc18.src.rpm
openldap-2.4.33-3.fc19.src.rpm
php-5.4.11-1.fc19.src.rpm
postfix-2.9.5-2.fc19.src.rpm
ptlib-2.10.9-1.fc19.src.rpm
qpid-cpp-0.18-5.fc19.src.rpm
saslwrapper-0.16-2.fc18.src.rpm
qca-cyrus-sasl-2.0.0-0.4.beta3.fc18.src.rpm
qemu-1.3.0-3.fc19.src.rpm
qpid-cpp-0.18-5.fc19.src.rpm
rinputd-1.0.5-1.fc19.src.rpm
ruby-qpid-0.8-7.fc18.src.rpm
qpid-cpp-0.18-5.fc19.src.rpm
saslwrapper-0.16-2.fc18.src.rpm
samba-4.0.1-1.fc19.src.rpm
sendmail-8.14.6-2.fc19.src.rpm
spice-gtk-0.16-1.fc19.src.rpm
spice-0.12.2-2.fc19.src.rpm
squid-3.2.5-1.fc19.src.rpm
subversion-1.7.8-3.fc19.src.rpm
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Can't build anything in Koji that uses mdadm: "mdadm conflicts with dracut"

[Mamoru TASAKA]

Richard W.M. Jones wrote, at 01/22/2013 07:43 PM +9:00:

On Tue, Jan 22, 2013 at 09:54:01AM +0100, Dan Horák wrote:

Richard W.M. Jones píše v Út 22. 01. 2013 v 08:19 +:

http://kojipkgs.fedoraproject.org//work/tasks/952/4890952/root.log

There's no conflict in dracut.spec.  However mdadm.spec has the
following lines:

%if "%{fedora}" >= "18"
Conflicts:   dracut < 024-23
[...]
%endif
%if "%{fedora}" >= "17"
Conflicts: dracut < 009-14
[...]
%endif

But as far as I can see from the root.log, dracut isn't installed in
the buildroot.  Maybe dracut is installed implicitly?


the package set being resolved from libguestfs BuildRequires will bring
both dracut and mdadm in


The latest dracut in 'master' is dracut-023-13.git20120821.fc19.
The latest in 'f18' is dracut-024-23.git20130118.fc18.  Which gets
installed and why?


because dracut wasn't ever built from the master branch

"koji latest-pkg f19 dracut" returns dracut-024-18.git20130102.fc18


Why does mdadm conflict with dracut anyway?


So ... the action to fix this is what?

I tried adding a buildoverride of dracut-024-23.git20130118.fc18.  Of
course that didn't work (I now realize) because that only affects F18
builds.  Or perhaps inheritance should pull it into Rawhide?  In any
case, it didn't work -- same conflict.

Rich.


For only a workaround, I just tagged dracut-024-23.git20130118.fc18
as f19, which should appear in F-19 buildroot soon.
dracut maintainer: this is just a workaround, so please build the
"latest" dracut also on F-19, thank you.

Regards,
Mamoru



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

Re: Can't build anything in Koji that uses mdadm: "mdadm conflicts with dracut"

[Richard W.M. Jones]

On Tue, Jan 22, 2013 at 09:54:01AM +0100, Dan Horák wrote:
> Richard W.M. Jones píše v Út 22. 01. 2013 v 08:19 +: 
> > http://kojipkgs.fedoraproject.org//work/tasks/952/4890952/root.log
> > 
> > There's no conflict in dracut.spec.  However mdadm.spec has the
> > following lines:
> > 
> > %if "%{fedora}" >= "18"
> > Conflicts:   dracut < 024-23
> > [...]
> > %endif
> > %if "%{fedora}" >= "17"
> > Conflicts: dracut < 009-14
> > [...]
> > %endif
> > 
> > But as far as I can see from the root.log, dracut isn't installed in
> > the buildroot.  Maybe dracut is installed implicitly?
> 
> the package set being resolved from libguestfs BuildRequires will bring
> both dracut and mdadm in
> 
> > The latest dracut in 'master' is dracut-023-13.git20120821.fc19.
> > The latest in 'f18' is dracut-024-23.git20130118.fc18.  Which gets
> > installed and why?
> 
> because dracut wasn't ever built from the master branch
> 
> "koji latest-pkg f19 dracut" returns dracut-024-18.git20130102.fc18
> 
> > Why does mdadm conflict with dracut anyway?

So ... the action to fix this is what?

I tried adding a buildoverride of dracut-024-23.git20130118.fc18.  Of
course that didn't work (I now realize) because that only affects F18
builds.  Or perhaps inheritance should pull it into Rawhide?  In any
case, it didn't work -- same conflict.

Rich.

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

Re: Can't build anything in Koji that uses mdadm: "mdadm conflicts with dracut"

[Dan Horák]

Richard W.M. Jones píše v Út 22. 01. 2013 v 08:19 +: 
> http://kojipkgs.fedoraproject.org//work/tasks/952/4890952/root.log
> 
> There's no conflict in dracut.spec.  However mdadm.spec has the
> following lines:
> 
> %if "%{fedora}" >= "18"
> Conflicts:   dracut < 024-23
> [...]
> %endif
> %if "%{fedora}" >= "17"
> Conflicts: dracut < 009-14
> [...]
> %endif
> 
> But as far as I can see from the root.log, dracut isn't installed in
> the buildroot.  Maybe dracut is installed implicitly?

the package set being resolved from libguestfs BuildRequires will bring
both dracut and mdadm in

> The latest dracut in 'master' is dracut-023-13.git20120821.fc19.
> The latest in 'f18' is dracut-024-23.git20130118.fc18.  Which gets
> installed and why?

because dracut wasn't ever built from the master branch

"koji latest-pkg f19 dracut" returns dracut-024-18.git20130102.fc18

> Why does mdadm conflict with dracut anyway?


Dan


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

Can't build anything in Koji that uses mdadm: "mdadm conflicts with dracut"

[Richard W.M. Jones]

http://kojipkgs.fedoraproject.org//work/tasks/952/4890952/root.log

There's no conflict in dracut.spec.  However mdadm.spec has the
following lines:

%if "%{fedora}" >= "18"
Conflicts:   dracut < 024-23
[...]
%endif
%if "%{fedora}" >= "17"
Conflicts: dracut < 009-14
[...]
%endif

But as far as I can see from the root.log, dracut isn't installed in
the buildroot.  Maybe dracut is installed implicitly?

The latest dracut in 'master' is dracut-023-13.git20120821.fc19.
The latest in 'f18' is dracut-024-23.git20130118.fc18.  Which gets
installed and why?

Why does mdadm conflict with dracut anyway?

Rich.

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