[Base] WGs Technical Specifications and Base WG

[Jaroslav Reznik]

Hi!
Matthias presented on Desktop list [1] initial Technical Specification 
document for Workstation product [2]. I expect other WGs will come with
similar document soon to fulfil FESCo request. But the discussion on
desktop list steered towards what should be in Base and what in products
and if bottom up or top down approach should be used to define Base (and
truth is probably as always somewhere in the middle). It's great to see
technical requirements from WS WG that could help our group see if it
fits to our vision, if we want to extend it based on this document etc.
And there are sections we already decided this functionality belong to
Base aka installer (even WS has a bit different requirements compared
to current installer so flexibility in design should be let in this WG).

Let's discuss it on Friday's Base WG meeting, Phil, could you add to
the agenda?

Btw. as Base use devel list - I'd like to ask other WGs to ping us
once they have tech spec document available for review.

Jaroslav

[1] https://lists.fedoraproject.org/pipermail/desktop/2014-February/009136.html
[2] https://fedoraproject.org/wiki/Workstation/Technical_Specification

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Renaming the cloud-utils package

[Matthias Runge]

On Wed, Feb 19, 2014 at 06:18:30PM +0100, Juerg Haefliger wrote:
> Hi,
> 
> I'm trying to figure out if it makes sense to rename the cloud-utils
> (sub-)package for EPEL7 and F21.
> 
> Upstream (Ubuntu) used to have a single package named cloud-utils which we
> decided to split up into two packages, cloud-utils and
> cloud-utils-growpart. The reason being that cloud-utils pulls in a lot of
> additional packages which is sub-optimal for cloud images.
> 
> Now Ubuntu followed suit and provides cloud-guest-utils and
> cloud-image-utils sub-packages. My question is if we should align with
> Ubuntu and rename our packages or stick with what we have?
> 
> I admit I'm ignorant to all the ramifications of renaming a package but
> from a user's perspective it's definitely a benefit if package names match
> across distros.

It makes sense to follow upstream here. The process is documented
here[1]. I'd inform the cloud WG, because they might be interested ;-)

Matthias


[1]
https://fedoraproject.org/wiki/Package_Renaming_Process
-- 
Matthias Runge 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM

[Florian Festi]

 Original Message 
Subject: [Rpm-maint] Heads up: Weak and rich dependencies in RPM
Date: Thu, 20 Feb 2014 13:12:43 +0100
From: Florian Festi 
To: rpm-ma...@lists.rpm.org, rpm-l...@lists.rpm.org

Hi!

We are currently working on adding weak and rich dependencies to
upstream RPM. There are basically two parts:

#1 Adding weak dependencies as already used by SuSE and others:
Recommends:, Suggests:, Supplements: and Enhances:. We agreed with
Michael Schröder to not use SuSE's current implementation but to add new
tags for a cleaner interface and an easy update path for already
existing packages. This is planned to be part of the next RPM version.

As old tools will just ignore the new tags this isn't a big
compatibility issue. Support in rpmbuild can probably back ported easily.

#2 Allow Boolean expressions of (Name Flag Version) terms in Requires:,
Conflicts: and the new weak dependencies (rich dependencies). This will
add a new expressive strength to RPM's dependency model and allow fixing
a couple of packaging problems we don't have a solution for
right now and also get rid of some special case solutions like hand
coded language pack support. As we are still figuring out some of the
implementation details and implications this feature may or may not make
it in the next release.

Packages using such Boolean expressions will not work with old versions
of rpm and other related tools and it is still unclear to what extend
this feature can be back ported.



What implication does this have on your distribution?




Getting the support into createrepo and libsolv is taken care of. This
should cover Fedora and OpenSUSE and may be others.



I wrote a document describing more technical details. Find it attached
to this mail.

Florian






rich_relations.odt
Description: application/vnd.oasis.opendocument.text
___
Rpm-maint mailing list
rpm-ma...@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Base] WGs Technical Specifications and Base WG

[Phil Knirsch]

On 02/20/2014 11:43 AM, Jaroslav Reznik wrote:

Hi!
Matthias presented on Desktop list [1] initial Technical Specification
document for Workstation product [2]. I expect other WGs will come with
similar document soon to fulfil FESCo request. But the discussion on
desktop list steered towards what should be in Base and what in products
and if bottom up or top down approach should be used to define Base (and
truth is probably as always somewhere in the middle). It's great to see
technical requirements from WS WG that could help our group see if it
fits to our vision, if we want to extend it based on this document etc.
And there are sections we already decided this functionality belong to
Base aka installer (even WS has a bit different requirements compared
to current installer so flexibility in design should be let in this WG).

Let's discuss it on Friday's Base WG meeting, Phil, could you add to
the agenda?

Btw. as Base use devel list - I'd like to ask other WGs to ping us
once they have tech spec document available for review.

Jaroslav

[1] https://lists.fedoraproject.org/pipermail/desktop/2014-February/009136.html
[2] https://fedoraproject.org/wiki/Workstation/Technical_Specification



Hi Jaroslav.

Thanks for the heads up, i'll add it for tomorrows agenda.

Regards, Phil

--
Philipp Knirsch  | Tel.:  +49-711-96437-470
Manager Core Services| Fax.:  +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch 
Wankelstrasse 5  | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2014-02-19)

[Josh Boyer]

On Wed, Feb 19, 2014 at 2:57 PM, Tomas Mraz  wrote:
> * Open floor  (t8m, 19:45:44)
>   * AGREED: FESCo expects the Tech specs/docs from working groups by
> March 3rd at the latest (+7, -0, 0:0)  (t8m, 19:50:38)
>   * ACTION: t8m will update the weekly reports ticket with this request
> (t8m, 19:53:08)

It would help if FESCo had a set of specific things they are looking
for by that date.  Otherwise you're going to get varied information
and detail from each of the WGs.  Guidance is requested.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: arm builder versus buildvm-26.phx2 , different results ?

[Kyle McMartin]

On Thu, Feb 20, 2014 at 06:39:38AM +, Sérgio Basto wrote:
> > The answer appears to be because dpkg thinks DEB_BUILD_ARCH and
> > DEB_HOST_ARCH are different for us (arm versus armel respectively.) and
> > this means it doesn't run dh_auto_test properly.
> > 
> > The reason for that is more complicated, and it appears to think we're
> > cross-compiling because dpkg --print-architecture and gcc -dumpmachine
> > lead dpkg to think we're arm in one case and armel in the other through
> > the archtable.
> 
> so is dpkg fault ? 
> 
> Thanks, but what should I do ? report upstream ? 
> 

Well, given for armv7hl-redhat-linux-gnu, I think we want "armhfp" to be
our architecture... I wouldn't quite "blame" anyone, but we probably
need a translation layer between our triplet, and Debian's idea of what
it means.

--Kyle
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM

[Colin Walters]

On Thu, Feb 20, 2014 at 7:27 AM, Florian Festi  
wrote:


We are currently working on adding weak and rich dependencies to
upstream RPM. There are basically two parts:

Is someone signed up to do the necessary frontend work for this on the 
dnf/yum side?  If we're allowing choice of "A | B" like this, there 
needs to be a frontend that actually allows choosing, like aptitude.


I guess one could go with the "shortest package name wins" approach or 
whatever the current heuristic is for now...


This is also relevant with things like kickstart files, where there is 
no interactivity allowed.


(For what it's worth I think making packaging even more complex and 
less predictable in order to increase flexibility is precisely the 
opposite direction of what we should be doing...but that's OK because I 
am coming at this from the other direction.  We'll meet in the middle 
somehow ;) )



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

EPEL Issue with koji?

[Dave Johansen]

I'm trying to do a build on koji and ran into an error during the mock
buildroot setup ( http://koji.fedoraproject.org/koji/taskinfo?taskID=6488038
).

I posted previously on the Fedora devel mailing list but haven't figured it
out yet (
https://lists.fedoraproject.org/pipermail/devel/2014-February/195111.html ).

Is this something wrong with koji? Or with the EL6/EPEL packages?

Thanks,
Dave
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Query about package versioning

[Vivek Goyal]

Hi All,

We are trying to sort out how to do kexec-tools package version, release
number management in fedora across various branches, hence this query.

I quickly went through following.

https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Naming_and_Versioning_Guidelines

So far we do following.

- In master branch keep on doing development and keep on bumping release
  at regular intervals.

  kexec-tools-2.0.4-1.fc21
  kexec-tools-2.0.4-2.fc21
  kexec-tools-2.0.4-3.fc21
  ...
  ...
  kexec-tools-2.0.4-23.fc21

Lets say now FC21 forks off and a new branch is created. We keep on
bumping release number in FC21 branch also.

  kexec-tools-2.0.4-24.fc21
  kexec-tools-2.0.4-25.fc21
  ...
  ...
  kexec-tools-2.0.4-30.fc21

And master will continue. 
  kexec-tools-2.0.4-24.fc22
  kexec-tools-2.0.4-25.fc22
  ...
  ...
  kexec-tools-2.0.4-30.fc22

Are we doing the right thing here.

I have few problems with above model.

- By bumping release version, we kind of lose the information what was
  our base at the time of fork of branch. 

- Release numbers of released branch can get ahead of master branch
  depending on how many releases were done on master and how many releases
  were done on released branches.

So instead of increasing release number on released branches, why don't
we append additional number after dist and bump that up in released
branch. So FC21 releases will look like.

  kexec-tools-2.0.4-24.fc21.1
  kexec-tools-2.0.4-24.fc21.2
  ...
  ...
  kexec-tools-2.0.4-23.fc21.10

That way we clearly know that FC21 was forked off master release .24. And
upgradability of package will be maintained without any change of older
release versions getting ahead of newer release versions.

Thanks
Vivek




-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Query about package versioning

[Marcin Juszkiewicz]

W dniu 20.02.2014 17:16, Vivek Goyal pisze:

> So instead of increasing release number on released branches, why don't
> we append additional number after dist and bump that up in released
> branch. So FC21 releases will look like.
> 
>   kexec-tools-2.0.4-24.fc21.1
>   kexec-tools-2.0.4-24.fc21.2
>   ...
>   ...
>   kexec-tools-2.0.4-23.fc21.10
> 
> That way we clearly know that FC21 was forked off master release .24. And
> upgradability of package will be maintained without any change of older
> release versions getting ahead of newer release versions.

%dist should be at the end.

So rather kexec-tools-2.0.4-23.X.fc21 where X means x-th revision of
fc21 package after distribution release.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Query about package versioning

[Mikolaj Izdebski]

On 02/20/2014 05:16 PM, Vivek Goyal wrote:
> So instead of increasing release number on released branches, why don't
> we append additional number after dist and bump that up in released
> branch. So FC21 releases will look like.
> 
>   kexec-tools-2.0.4-24.fc21.1
>   kexec-tools-2.0.4-24.fc21.2
>   ...
>   ...
>   kexec-tools-2.0.4-23.fc21.10
> 
> That way we clearly know that FC21 was forked off master release .24. And
> upgradability of package will be maintained without any change of older
> release versions getting ahead of newer release versions.

IMO it's best to do fast-forward merges between branches when possible.
 In particular merging mass rebuild commits is OK.

In case FF merge is impossible I agree with the procedure you described.
 You need to increase release tag in a way that assures upgrade path and
one way to do that is adding .1 after dist tag.

-- 
Mikolaj Izdebski
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Query about package versioning

[Mikolaj Izdebski]

On 02/20/2014 05:28 PM, Marcin Juszkiewicz wrote:
> W dniu 20.02.2014 17:16, Vivek Goyal pisze:
> 
>> So instead of increasing release number on released branches, why don't
>> we append additional number after dist and bump that up in released
>> branch. So FC21 releases will look like.
>>
>>   kexec-tools-2.0.4-24.fc21.1
>>   kexec-tools-2.0.4-24.fc21.2
>>   ...
>>   ...
>>   kexec-tools-2.0.4-23.fc21.10
>>
>> That way we clearly know that FC21 was forked off master release .24. And
>> upgradability of package will be maintained without any change of older
>> release versions getting ahead of newer release versions.
> 
> %dist should be at the end.
> 
> So rather kexec-tools-2.0.4-23.X.fc21 where X means x-th revision of
> fc21 package after distribution release.

That won't work if both branches already have the same release number
and you need to bump release in older branch.  That can happen for
example if you were fast-forwarding commits from f21 to f20 and at some
point you need to add a bugfix only for f20.  Adding .1 after dist-tag
will work in this case.

-- 
Mikolaj Izdebski
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

[Przemek Klosowski]

On 02/19/2014 01:16 PM, Adam Williamson wrote:

On Sun, 2014-02-16 at 14:38 +, Richard Hughes wrote:

On 14 February 2014 21:43, Przemek Klosowski  wrote:

If we are providing a next-generation UI for installing, to replace yum

That's not what we're doing.

To expand a bit: insofar as Software - the tool we're discussing here,
and the tool to which the "require applications to ship appdata"
requirement applies - replaces anything, it replaces gnome-packagekit.
It is not replacing yum.

The old gnome-packagekit was a 'graphical package installer', just like
yumex and apper. The new gnome-software is (with a bit of a handwave) an
'application installer'. That's a difference, but it's not relevant to
yum at all, and I doubt many people used gpk to install gcc. For those
who really want a GUI package installer, the old gpk is still available
in a not-installed-by-default package (though I assume Richard will
eventually drop it), and yumex is always an option.
Thanks for the context. The reason I keep on droning about it is well 
explained by the old military saying "What is worse than a bad general? 
Two good generals.".  I.e., it would be nice if there was one go-to 
application for GUI software installation that everyone uses and 
improves. As it is, we have four: yumex, gpk, apper and now Richard's, 
and every one has some unique nice and/or niche features (*). It's just 
a better user experience when there's one GUI installer with simple 
default choice and advanced options, rather than having to explain that 
if you're installing development tools, use this, else if you're 
installing graphics apps, use that, else if you're installing 
commandline tools use the other thing.


Speaking for myself, I use yum all the time, but I do find GUIs useful, 
for instance when I remember that there's a useful structural chemistry 
app called A--something... angstrom? asteroid? haemoroid? ahh, 
Avogadro!!!. Just happened to me recently. It's much easier to find it 
in a GUI browser.


I feel I said everything that I can say about this, so I will sit down 
and be quiet now.


Greetings

p

(*) I never really used apper, and when I just brought it up, I liked 
its broad selection of filters (free/nonfree, native, developer/end 
user, commandline/graphical, etc). They turn out to be more useful than 
I expected them to be---for instance the non-free filter surprised me by 
when I looked at OpenCASCADE---I didn't realize it came from  
rpmfusion-nonfree (this is actually changing as we speak, its license 
was just changed and a large body of software including FreeCAD, and 
other sci/eng visualization stuff is moving to the mainline Fedora repo).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

[Adam Williamson]

On Thu, 2014-02-20 at 12:01 -0500, Przemek Klosowski wrote:
> On 02/19/2014 01:16 PM, Adam Williamson wrote:
> > On Sun, 2014-02-16 at 14:38 +, Richard Hughes wrote:
> >> On 14 February 2014 21:43, Przemek Klosowski  
> >> wrote:
> >>> If we are providing a next-generation UI for installing, to replace yum
> >> That's not what we're doing.
> > To expand a bit: insofar as Software - the tool we're discussing here,
> > and the tool to which the "require applications to ship appdata"
> > requirement applies - replaces anything, it replaces gnome-packagekit.
> > It is not replacing yum.
> >
> > The old gnome-packagekit was a 'graphical package installer', just like
> > yumex and apper. The new gnome-software is (with a bit of a handwave) an
> > 'application installer'. That's a difference, but it's not relevant to
> > yum at all, and I doubt many people used gpk to install gcc. For those
> > who really want a GUI package installer, the old gpk is still available
> > in a not-installed-by-default package (though I assume Richard will
> > eventually drop it), and yumex is always an option.

> Thanks for the context. The reason I keep on droning about it is well 
> explained by the old military saying "What is worse than a bad general? 
> Two good generals.".  I.e., it would be nice if there was one go-to 
> application for GUI software installation that everyone uses and 
> improves. As it is, we have four: yumex, gpk, apper and now Richard's, 
> and every one has some unique nice and/or niche features (*). It's just 
> a better user experience when there's one GUI installer with simple 
> default choice and advanced options,

One app "with simple default choice and advanced options" effectively
*is* two apps, uncomfortably shoehorned into one UI. You get all the
disadvantages of complexity with none of the benefits of simplicity.
This is why it's a model most apps have moved away from.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2014-02-19)

[Kevin Fenzi]

On Thu, 20 Feb 2014 07:53:01 -0500
Josh Boyer  wrote:

> On Wed, Feb 19, 2014 at 2:57 PM, Tomas Mraz  wrote:
> > * Open floor  (t8m, 19:45:44)
> >   * AGREED: FESCo expects the Tech specs/docs from working groups by
> > March 3rd at the latest (+7, -0, 0:0)  (t8m, 19:50:38)
> >   * ACTION: t8m will update the weekly reports ticket with this
> > request (t8m, 19:53:08)
> 
> It would help if FESCo had a set of specific things they are looking
> for by that date.  Otherwise you're going to get varied information
> and detail from each of the WGs.  Guidance is requested.

Well, (not speaking for all of FESCo), I was thinking first it would be
the next expected deliverable: 

"The second deliverable should be a list of necessary changes from
existing Fedora procedures needed to release the product. This should
be ordered to show what things depend on other changes and at which
point the changes will mean that we can no longer produce the current
type of Fedora. This will allow us to identify the resources needed by
what teams in order to implement the plan and at what point we may need
to have a longer than normal release cycle to do tooling work."

I think thats still not very detailed tho, so for me at least, I would
love to see: 

* What are your working groups deliverables? The actual thing we will
  be giving our users? (ie, a 1gb live iso image, or a netinstall.iso,
  or a cloud qcow2 image) with (these workstation/server/cloud
  components on it in configuration X)

* based on that, what changes to our current setup would you need to
  make that happen? (changes to livecd-creator, cloud image production,
  pungi) and/or (websites showing all products) and/or (what would
  marketing be able to hand out at events) and/or ... 

Basically data so we can all discuss what we can bite off for f21 and
hopefully make some awesome compelling products. 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

[Richard Hughes]

On 20 February 2014 17:44, Adam Williamson  wrote:
> You get all the disadvantages of complexity with none of the benefits of 
> simplicity.

"Jack of all trades, master of none".

Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Query about package versioning

[Vivek Goyal]

On Thu, Feb 20, 2014 at 05:28:02PM +0100, Marcin Juszkiewicz wrote:
> W dniu 20.02.2014 17:16, Vivek Goyal pisze:
> 
> > So instead of increasing release number on released branches, why don't
> > we append additional number after dist and bump that up in released
> > branch. So FC21 releases will look like.
> > 
> >   kexec-tools-2.0.4-24.fc21.1
> >   kexec-tools-2.0.4-24.fc21.2
> >   ...
> >   ...
> >   kexec-tools-2.0.4-23.fc21.10
> > 
> > That way we clearly know that FC21 was forked off master release .24. And
> > upgradability of package will be maintained without any change of older
> > release versions getting ahead of newer release versions.
> 

> %dist should be at the end.

[ Can you please keep me in "To" list. I don't want to scan mailing list
  to figure out if somebody responded to my mail or not ]

Why %dist should be at the end? html page I referenced previously mentions
that one can use x.%{dist}.y kind of release number in select cases.

> 
> So rather kexec-tools-2.0.4-23.X.fc21 where X means x-th revision of
> fc21 package after distribution release.

I think this will work too. As 23 got frozen in time and master and later
releases will always be higher. And that would not break upgradability.

Thanks
Vivek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Query about package versioning

[Vivek Goyal]

On Thu, Feb 20, 2014 at 05:39:17PM +0100, Mikolaj Izdebski wrote:
> On 02/20/2014 05:28 PM, Marcin Juszkiewicz wrote:
> > W dniu 20.02.2014 17:16, Vivek Goyal pisze:
> > 
> >> So instead of increasing release number on released branches, why don't
> >> we append additional number after dist and bump that up in released
> >> branch. So FC21 releases will look like.
> >>
> >>   kexec-tools-2.0.4-24.fc21.1
> >>   kexec-tools-2.0.4-24.fc21.2
> >>   ...
> >>   ...
> >>   kexec-tools-2.0.4-23.fc21.10
> >>
> >> That way we clearly know that FC21 was forked off master release .24. And
> >> upgradability of package will be maintained without any change of older
> >> release versions getting ahead of newer release versions.
> > 
> > %dist should be at the end.
> > 
> > So rather kexec-tools-2.0.4-23.X.fc21 where X means x-th revision of
> > fc21 package after distribution release.
> 
> That won't work if both branches already have the same release number
> and you need to bump release in older branch.  That can happen for
> example if you were fast-forwarding commits from f21 to f20 and at some
> point you need to add a bugfix only for f20.  Adding .1 after dist-tag
> will work in this case.

What is fast forwarding commits from f21 to f20. I guess you are saying
there are bunch of commits in master branch and you want to now apply
those commits to f20 branch too?

If yes, one can simply do another release on master branch if there is
a need to commit a patch in f20 only.

Say master is at kexec-tools-2.0.4-23.0.fc21 and has bunch of more commits
on top.

FC21 forks off and has kexec-tools-2.0.4-23.0.fc21 and a patch needs to
applied to FC21 only. Then one can do another release on master to avoid
any kind of upgradability conflicts.

master will be kexec-tools-2.0.4-24.0.fc22
FC21  will be kexec-tools-2.0.4-23.1.fc21

So I don't see why above will not work?

IOW, it is better to use an extra field for versioning of released
branches to avoid any kind of conflicts with master. Instead of
overloading same release field for all the branches.

Not sure why more package not follow this extra field thing. I am trying
to find out if anything is fundamentally wrong if we try to pursue this
scheme in kexec-tools pacakge.

Thanks
Vivek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Query about package versioning

[Michael Schwendt]

On Thu, 20 Feb 2014 17:28:02 +0100, Marcin Juszkiewicz wrote:

> W dniu 20.02.2014 17:16, Vivek Goyal pisze:
> 
> > So instead of increasing release number on released branches, why don't
> > we append additional number after dist and bump that up in released
> > branch. So FC21 releases will look like.
> > 
> >   kexec-tools-2.0.4-24.fc21.1
> >   kexec-tools-2.0.4-24.fc21.2
> >   ...
> >   ...
> >   kexec-tools-2.0.4-23.fc21.10
> > 
> > That way we clearly know that FC21 was forked off master release .24. And
> > upgradability of package will be maintained without any change of older
> > release versions getting ahead of newer release versions.
> 
> %dist should be at the end.

No. See:

https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bumps_for_old_branches
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Broken dependencies: mojomojo

[buildsys]

mojomojo has broken dependencies in the rawhide tree:
On x86_64:
mojomojo-1.10-1.fc20.noarch requires 
perl(HTML::FormFu::Element::reCAPTCHA)
On i386:
mojomojo-1.10-1.fc20.noarch requires 
perl(HTML::FormFu::Element::reCAPTCHA)
On armhfp:
mojomojo-1.10-1.fc20.noarch requires 
perl(HTML::FormFu::Element::reCAPTCHA)
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-Language-Expr

[buildsys]

perl-Language-Expr has broken dependencies in the rawhide tree:
On x86_64:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On i386:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On armhfp:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.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-Catalyst-Controller-HTML-FormFu

[buildsys]

perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide 
tree:
On x86_64:
perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires 
perl(HTML::FormFu::MultiForm)
On i386:
perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires 
perl(HTML::FormFu::MultiForm)
On armhfp:
perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires 
perl(HTML::FormFu::MultiForm)
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: python-django update to Django-1.6

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/26/2013 08:41 AM, Pierre-Yves Chibon wrote:
> On Mon, Nov 25, 2013 at 09:07:55AM +0100, Matthias Runge wrote:
>> Hey,
>> 
>> recently, I saw a few requests to update python-django to
>> Django-1.6, the corresponding bug is [1].
>> 
>> As there are quite a few changes, I'd expect this update to be
>> harmful, at least - python-django-openstack-auth -
>> openstack-dashboard
>> 
>> will break, and won't even build any more (because they also
>> execute sanity checks during build).
>> 
>> So, the current plan is, to fix both packages upstream and then
>> to update python-django to Django 1.6 in rawhide. I'd expect this
>> to happen within the next two weeks and I'd update python-django
>> to Django-1.6 around Dec 16th.
>> 
>> Because of bad timing, we won't have Django-1.6 in f20.
> 
> Just an idea, but what about providing Django 1.6 via copr for
> F{20,19}? That might also help testing current apps against the new
> Django.


Just to bring this thread back to life, we're getting to a point where
support for Django 1.6 is becoming more and more necessary. Is there
an ETA on its inclusion in Rawhide or COPR?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMGVUsACgkQeiVVYja6o6PmHgCfec4kS0V/rj2GHFYxU6bgsuXs
duAAnRuGWvXnfu087Zed23uSLzvnrxAp
=BM6s
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

[Przemek Klosowski]

On 02/20/2014 12:44 PM, Adam Williamson wrote:
One app "with simple default choice and advanced options" effectively 
*is* two apps, uncomfortably shoehorned into one UI. You get all the 
disadvantages of complexity with none of the benefits of simplicity. 
This is why it's a model most apps have moved away from. 

OK, I lied---I will respond with one more post.

You'd be right if it really was two apps, shoehorned---but I really 
think this case wants to be one software installation UI with several 
search selectors, just like apper, which actually has a 
'graphical/non-graphical' search selector. Use the 💻 
 glyph at low-res as a 
screenshot/logo, to show our disdain for older apps, if we must.


Surely you agree that it's possible to overdo such app specialization; 
my favorite example of such specious differentiation is dedicated 
droid/ios apps for every website (reddit/slashdot/whatever).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

libcogl soname bump

[Kalev Lember]

Hello,

I've just built cogl 1.17.4 for rawhide, which includes a soname bump. I
am going to run a script to rebuild all consumers (38, list below), but
since it's quite a few packages, some of them might fail to rebuild, for
unrelated reasons. Help appreciated if one of these shows up in the
rawhide broken dep list tomorrow.

$ repoquery -q --disablerepo='*' --enablerepo=rawhide-koji --whatrequires 
'libcogl*.so.19*' -s | sort | uniq | rev | cut -f 3- -d - | rev
bijiben
caribou
cheese
cinnamon
clutter
clutter-gst
clutter-gst2
clutter-gtk
cogl
empathy
eog-plugins
gnome-boxes
gnome-contacts
gnome-nibbles
gnome-shell
gpx-viewer
gthumb
libchamplain
libmash
libmx
lightsoff
media-explorer
muffin
mutter
mutter-wayland
nemo-extensions
pinpoint
quadrapassel
rhythmbox
snappy-player
sushi
swell-foop
totem
xfdashboard


-- 
Thanks,
Kalev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM

[Florian Festi]

On 02/20/2014 03:44 PM, Colin Walters wrote:
> On Thu, Feb 20, 2014 at 7:27 AM, Florian Festi  wrote:
>> We are currently working on adding weak and rich dependencies to
>> upstream RPM. There are basically two parts: 
> 
> Is someone signed up to do the necessary frontend work for this on the
> dnf/yum side?  If we're allowing choice of "A | B" like this, there
> needs to be a frontend that actually allows choosing, like aptitude.

Yes and no. Right now there is no plan to allow the user to do the
choosing. This ambiguity already exists in the current relations and we
will continue to handle it automatically.

> I guess one could go with the "shortest package name wins" approach or
> whatever the current heuristic is for now...

The heuristics will improved though. Libsolv already uses weak
dependencies to choose the "more desired" package. I hope we can add
support for preferring the more left packages over later packages in
such or-clauses. That way
Requires: sendmail or postfix
would prefer sendmail while
Requires: MTA
chooses one of them the by some unrelated criteria.

> This is also relevant with things like kickstart files, where there is
> no interactivity allowed.
> 
> (For what it's worth I think making packaging even more complex and less
> predictable in order to increase flexibility is precisely the opposite
> direction of what we should be doing...but that's OK because I am coming
> at this from the other direction.  We'll meet in the middle somehow ;) )

Actually I am on your side of the argument. This effort is supposed to
give better control over how packages behave and relate to each other
*to the packager*.

While "A or B" is an often demanded feature the main reason for this are
relations that span a longer distance. E.g. Foo-langpack-es could
Supplement: Foo and langsupport-es
Or to implement the same behaviour with a forward dependency
package Foo could
Requires: Foo-langpack-es if langsupport-es

Both variants pull in a intermediate package (Foo-langpack-es) if two
packages are present (Foo and langsupport-es).

Florian

PS: I actually do think that we need to give the user more control over
the packages, too. The current tools are completely inadequate to manage
the number of packages we have in the distribution or even just on a
system. But this is a story for another time.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM

[Adam Williamson]

On Thu, 2014-02-20 at 14:44 +, Colin Walters wrote:
> On Thu, Feb 20, 2014 at 7:27 AM, Florian Festi  
> wrote:
> > 
> > We are currently working on adding weak and rich dependencies to
> > upstream RPM. There are basically two parts:
> > 
> Is someone signed up to do the necessary frontend work for this on the 
> dnf/yum side?  If we're allowing choice of "A | B" like this, there 
> needs to be a frontend that actually allows choosing, like aptitude.

Fedora isn't signed up to *use* it yet. We can still make the choice
whether we want to or not, I believe.

> I guess one could go with the "shortest package name wins" approach or 
> whatever the current heuristic is for now...
> 
> This is also relevant with things like kickstart files, where there is 
> no interactivity allowed.

Typical approach there is simply to come up with a 'default' approach,
and that's what kickstarts use. If we use 'rich' dependencies, the
questions would be to set policies for the use of each type of
dependency in Fedora, and decide what level of 'weak' dependency to
install by default. kickstart installs and live image creation would
then, one expects, use that same level.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Self Introduction: Sean Burke

[Sean Burke]

Hello,

My name is Sean Burke, but I also go by Seán de Búrca on some projects.
I have been a Linux user for a while now and started using Fedora a few
years ago. I have contributed to a number of FLOSS projects over the years,
though most of my work has been for the GNOME project in the form of
patches and translations. I also contribute data and code to MusicBrainz. I
believe strongly in the benefits of FLOSS and seek to improve it wherever I
am able.

I am hoping to expand the selection of open fonts available in Fedora.
To this end, I've created a review request for the Junicode font family[1]
and have contacted several font authors about acquiring source for their
fonts (when the font is adequately licensed) or changing the license for
existing free fonts to meet Fedora licensing standards. In the long run, I
am sure I will encounter other packages I would like to see picked up in
Fedora's repos. To this end, I am seeking packager sponsorship and am
hoping to find someone willing to work with me toward this.


Sean Burke


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1005518
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-DBD-ODBC/f18] Updated to upstream version 1.47

[Jan Holcapek]

Summary of changes:

  8b7289a... Updated to upstream version 1.47 (*)

(*) 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-DBD-ODBC/f19] Updated to upstream version 1.47

[Jan Holcapek]

Summary of changes:

  8b7289a... Updated to upstream version 1.47 (*)

(*) 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-DBD-ODBC/f20] Updated to upstream version 1.47

[Jan Holcapek]

Summary of changes:

  8b7289a... Updated to upstream version 1.47 (*)

(*) 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: python-django update to Django-1.6

[Matthias Runge]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/20/2014 08:19 PM, Stephen Gallagher wrote:

> 
> Just to bring this thread back to life, we're getting to a point
> where support for Django 1.6 is becoming more and more necessary.
> Is there an ETA on its inclusion in Rawhide or COPR?
> 

Whah, thank you!

There's a Django-1.6 build here in copr[1], and I'd like to push an
update to rawhide in about 14 days.

Any feedback is appreciated!

What about pushing Django-1.6 to epel7, too?

[1] https://copr.fedoraproject.org/coprs/mrunge/Django-1.6/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTBwTWAAoJEOnz8qQwcaIWpr8IAKZnHbn0NFkgqHACL6x11mCj
CSmo/3FIAfeG6PCUY/9lJ6brZhrDx0YCnFG5E5mfG2vph4dcQ4IZixmiQKsunHb0
Duiy/aODhiCSBss2DJLChOY+EYJckJ+zZd/tfSQE4ifsAhj+6NH5qdg/KGe6NRfP
F0eghLxhZifh1f82UunhNUy/TkCEQvVUSptI4dq9s8lbAMRvcUKrHOXxabiTjOus
uXqNrcKrUNukidl0KBdQh5oQvbU+5xzeqaM0aHyWqga3mEB9o6ZqZABMS44Xmp8z
H9DeIGuqnLq/FH/nPtFbv4kR9UqOB2t06Q2VoHElRa8bTiAN1vdnif8jp8AAVs0=
=gmXo
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct