[perl-HTML-TableExtract/epel7] (3 commits) ...Fix requires.

[Bill Nottingham]

Summary of changes:

  51dda63... Perl 5.18 rebuild (*)
  567181b... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*)
  f5efb4b... Fix requires.

(*) 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: boot.fedoraproject.org (BFO)

[Peter Lemenkov]

2014/1/23 Kevin Kofler :

> IMHO, projects where Fedora is upstream MUST be on fedorahosted.org, we
> should enforce that at least for our infrastructure.

IMHO you're absolutely wrong. Fortunately it seems that not so much
people agree with you since I see a lot of activily on a given
third-party proprietary web service (compared with a dead silence at
fedorahosted). So actually people already voted, and they voted
against Fedorahosted. You just need to realize that we already "lost"
"control" here. I understand that numbers could be much more
convincing and I hope somebody will measure activity at fedorahosted
and at GitHub but I doubt the results disprove my point.

Just for the starters the main part of a source code of almost all our
packages hosted somewhere else. I think this makes us much more
vulnerable than git mirroring of a small fraction of homecooked stuff
in a place where all the developers are.

-- 
With best regards, Peter Lemenkov.
-- 
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: RFC - Downgrade BlueZ to v4.101 in Fedora 20

[David Sommerseth]

On 23/01/14 19:58, Frank Murphy wrote:
> On Thu, 23 Jan 2014 19:53:19 +0100
> David Sommerseth  wrote:
> 
>>
>> Hi all,
>>
>> This might be a viewed as a fire torch, but there is, IMO, a major
>> regression in BlueZ 5 which is shipped in Fedora 20.  It doesn't
>> support HSP/HFP headset profiles, which enables the microphone on
>> many bluetooth headsets.  It's already tracked in this BZ:
>>
>>
> 
> is just downgrading bluez any help?
> yum downgrade bluez* --releasever=19

Nope, several packages depends on the bluez-5.13-1 package.

---
--> Finished Dependency Resolution
Error: Package: pulseaudio-module-bluetooth-4.0-9.gitf81e3.fc20.x86_64
(@updates/20)
   Requires: bluez >= 5.0
   Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
   bluez = 5.13-1.fc20
   Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
   bluez = 4.101-9.fc19
   Available: bluez-4.101-6.fc19.x86_64 (fedora)
   bluez = 4.101-6.fc19
Error: Package: 1:gnome-bluetooth-3.10.0-1.fc20.x86_64 (@anaconda/20)
   Requires: bluez >= 5.0
   Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
   bluez = 5.13-1.fc20
   Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
   bluez = 4.101-9.fc19
   Available: bluez-4.101-6.fc19.x86_64 (fedora)
   bluez = 4.101-6.fc19
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest


Might even be a worse conflict for other users, depending on installed
packages.  I believe there's no way around re-compiling NetworkManager,
pulseaudio and other GNOME and KDE packages depending on bluez.


--
kind regards,

David Sommerseth

-- 
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: RFC - Downgrade BlueZ to v4.101 in Fedora 20

[Frank Murphy]

On Thu, 23 Jan 2014 19:53:19 +0100
David Sommerseth  wrote:

> 
> Hi all,
> 
> This might be a viewed as a fire torch, but there is, IMO, a major
> regression in BlueZ 5 which is shipped in Fedora 20.  It doesn't
> support HSP/HFP headset profiles, which enables the microphone on
> many bluetooth headsets.  It's already tracked in this BZ:
> 
> 

is just downgrading bluez any help?
yum downgrade bluez* --releasever=19

___
Regards,
Frank 
www.frankly3d.com

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

RFC - Downgrade BlueZ to v4.101 in Fedora 20

[David Sommerseth]

Hi all,

This might be a viewed as a fire torch, but there is, IMO, a major
regression in BlueZ 5 which is shipped in Fedora 20.  It doesn't support
HSP/HFP headset profiles, which enables the microphone on many bluetooth
headsets.  It's already tracked in this BZ:

   

It seems a solution for BlueZ 5 isn't close, especially not for F20.
Upstream is looking at this issue, but not much news have been told yet:


Anyhow, not supporting HSP/HSP profiles is at least hitting my work
ability, and I doubt I'm alone in this situation.

Now, if I had known this before I started upgrading to F20, I wouldn't
have upgraded yet but stayed on F19 a bit longer.  However, that's too
late now.  This was first listed as a "common bug" about three weeks
after the release.

So, I wonder if it can be considered to enable a "downgrade path" for
bluez and depending packages, as described in the "Contingency Plan":


The other alternative is to tell users to re-install Fedora 19, which I
doubt is such a good alternative in the long run.  But I need to
consider that if BlueZ isn't downgraded somehow.

As a side note, it also needs to be discussed how such a key feature of
the bluetooth stack could go unnoticed through QA, and how to avoid this
from happening again.


--
kind regards,

David Sommerseth
-- 
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-DateTime-Set] Created tag perl-DateTime-Set-0.33-2.el7

[Paul Howarth]

The lightweight tag 'perl-DateTime-Set-0.33-2.el7' was created pointing to:

 271802c... Bootstrap epel7 build
--
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: boot.fedoraproject.org (BFO)

[Kevin Kofler]

Kevin Fenzi wrote:
> While github is nice for pulls and patches, it's not so great for
> tickets and support needs.
> 
> github issues are very primitive last I looked and wouldn't meet Fedora
> Infrastructures needs, IMHO.

I also object to the idea of hosting critical parts of our infrastructure on 
third-party proprietary web services completely out of our control, as I 
already pointed out in the pkgdb2 thread.

IMHO, projects where Fedora is upstream MUST be on fedorahosted.org, we 
should enforce that at least for our infrastructure.

Kevin Kofler

-- 
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: Fedora.next in 2014 -- Big Picture and Themes

[Josh Boyer]

On Thu, Jan 23, 2014 at 1:38 PM, Tom Hughes  wrote:
> On 23/01/14 18:26, Josh Boyer wrote:
>>
>> On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis 
>> wrote:
>>
>>> And I really wonder if Fedora.next is really backed by those community
>>> contributors that are not involved in Fedora to deeply. One reason for
>>
>>
>> I wonder the same.  However, I don't think it's because we haven't
>> necessarily asked in all of the usual places, or haven't tried to
>> reach as many people as possible.  There has been very little response
>> from anyone and I can't tell if it's from indifference or from a lack
>> of them even being aware.  It's really hard to tell.
>
>
> Personally I think a lot of it has to do with the way the whole thing seemed
> to be a fait accompli such that there seemed to be little point doing
> anything other than sitting back and seeing what happened.
>
> You know, the way one minute it was just a suggestion from one member of the
> community and the next minute it was all decided and people were busy
> forming working groups to sort out the details. Apparently that miraculous
> transition happened at Flock, but for anybody that wasn't there it was as if
> it was a god given edict that had been handed down on tablets of stone that
> Fedora.next was happening and we should all just be good little children and
> get on with it.

There _was_ a lot that was discussed and presented at Flock.  It's
kind of the purpose of Flock (and FUDCon before that).  Get people
together to have big discussions in a high bandwith fashion.  And yes,
that can mean that those not in attendance are left to catch up a bit
(though at least with Flock we tried to stream all the sessions to
help with that).

However, it wasn't decided at Flock.  It was presented after Flock to
FESCo, in the normal, online FESCo meetings.  It went further from
there to the Board via the usual channels.  All of this was done as
any other proposal would normally be handled.  Perhaps the only
unusual thing was the relative lack of debate and delay.

> Even the formation of the working groups was odd - the original decision to
> form them, as I read it, was that they were to explore the idea of doing
> these three streams but within days it seemed that the question was no
> longer whether to do them but rather how to do them.

I can see how that would be confusing.  I always understood it to be
"these WGs will be formed and they will be tasked with figuring out
how to create their respective products".  Perhaps some lack of
clarity in the proposal?

>>> That's why I got the feeing a lot of contributors are simply waiting
>>> for more concrete details to emerge before deciding what to make of
>>> Fedora.next; or they simply at all don't care to much what the higher
>>> ups do, as getting involved on that level can cost quite a lot of time
>>> and can be frustrating (that's not a complaint, that's simply how it
>>> is often; wasn't much different in my days, but noticed that more when
>>> I wasn't that active an more myself).
>>
>>
>> If they are waiting, what are they waiting for?  If they don't care,
>> and they just want to maintain a package or 30 packages, is there
>> anything that you see in Fedora.next that would prevent them from
>> doing that?  There will always be varied level of participation, and I
>> think we need to have a development model that encourages that and
>> allows for growth.  I don't think Fedora.next gets in the way of that,
>> but I would love to have other opinions.
>
>
> To be honest my concerns are more with my user hat on than my contributor
> hat - that we will lose the gold standard unified packaging standards and
> single source and mechanism for installing packages.

I haven't seen anything from any WG that would suggest a deviation
from RPM packaging guidelines or using separate repositories.  It is a
valid concern and one we need to keep an eye on.

> The actual spins (or whatever you want to call them) aren't something that
> bother me at all, as they are to my mind largely irrelevant for anybody
> other than a new user. When I bring a new machine up I just want to get a
> base OS on and access to the package repository and what packages are
> installed by default doesn't really bother me.

So... Fedora.next is essentially irrelevant to you?  That's OK, it
doesn't have to be relevant to everyone.  And meeting the needs of
existing users is definitely something that should be taken into
account.  Would you use e.g. Workstation as it's the most equivalent
to the default Fedora install today?  (I realize it's difficult to say
for sure, given nothing actually exist yet so please allow a little
latitude in the question.)

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

[Bug 1056804] (possibly) branch for EPEL 7

[bugzilla]

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

Bill Nottingham  changed:

   What|Removed |Added

 Status|CLOSED  |NEW
 Resolution|NOTABUG |---
  Flags||fedora-cvs?
   Keywords||Reopened



--- Comment #5 from Bill Nottingham  ---
Package Change Request
==
Package Name: perl-HTML-Element-Extended
New Branches: epel7
Owners: notting

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

Re: What to do about packaging beta, or rc as alternate installable

[Kevin Kofler]

Christopher Meng wrote:
> But you can do this on copr IMO.  Also update-testing is not just a place
> for updates to have a break, you can let it satisfy the needs of testing
> for unstable.

Well, that's kinda abusing updates-testing. IMHO, COPR is the much better 
option until you have something reasonably close to going stable.

Kevin Kofler

-- 
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: Fedora.next in 2014 -- Big Picture and Themes

[Tom Hughes]

On 23/01/14 18:26, Josh Boyer wrote:

On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis  wrote:


And I really wonder if Fedora.next is really backed by those community
contributors that are not involved in Fedora to deeply. One reason for


I wonder the same.  However, I don't think it's because we haven't
necessarily asked in all of the usual places, or haven't tried to
reach as many people as possible.  There has been very little response
from anyone and I can't tell if it's from indifference or from a lack
of them even being aware.  It's really hard to tell.


Personally I think a lot of it has to do with the way the whole thing 
seemed to be a fait accompli such that there seemed to be little point 
doing anything other than sitting back and seeing what happened.


You know, the way one minute it was just a suggestion from one member of 
the community and the next minute it was all decided and people were 
busy forming working groups to sort out the details. Apparently that 
miraculous transition happened at Flock, but for anybody that wasn't 
there it was as if it was a god given edict that had been handed down on 
tablets of stone that Fedora.next was happening and we should all just 
be good little children and get on with it.


Even the formation of the working groups was odd - the original decision 
to form them, as I read it, was that they were to explore the idea of 
doing these three streams but within days it seemed that the question 
was no longer whether to do them but rather how to do them.



That's why I got the feeing a lot of contributors are simply waiting
for more concrete details to emerge before deciding what to make of
Fedora.next; or they simply at all don't care to much what the higher
ups do, as getting involved on that level can cost quite a lot of time
and can be frustrating (that's not a complaint, that's simply how it
is often; wasn't much different in my days, but noticed that more when
I wasn't that active an more myself).


If they are waiting, what are they waiting for?  If they don't care,
and they just want to maintain a package or 30 packages, is there
anything that you see in Fedora.next that would prevent them from
doing that?  There will always be varied level of participation, and I
think we need to have a development model that encourages that and
allows for growth.  I don't think Fedora.next gets in the way of that,
but I would love to have other opinions.


To be honest my concerns are more with my user hat on than my 
contributor hat - that we will lose the gold standard unified packaging 
standards and single source and mechanism for installing packages.


The actual spins (or whatever you want to call them) aren't something 
that bother me at all, as they are to my mind largely irrelevant for 
anybody other than a new user. When I bring a new machine up I just want 
to get a base OS on and access to the package repository and what 
packages are installed by default doesn't really bother me.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
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: Git repos location

[Tim Flink]

On Thu, 23 Jan 2014 05:48:00 -0500 (EST)
Kamil Paral  wrote:

> > https://phab.qadevel-stg.cloud.fedoraproject.org/
> > 
> > The hosting does work over ssh, but I'm noticing some quirks
> >  - the ssh urls are displayed incorrectly. This may be fixed in the
> >latest upstream (the version we're using is several weeks old)
> > but I haven't checked yet. For the dummy repo I created:
> >* shown:
> >   ssh://phab.qadevel-stg.cloud.fedoraproject.org/diffusion/PON/
> >* actual thing to clone if you want it to succeed:
> >   g...@phab.qadevel-stg.cloud.fedoraproject.org:diffusion/PON
> > 
> >  - http hosting doesn't work yet. I have some more tweaking to do in
> >order to get that functional but it's do-able
> 
> Does this mean that phab repos can't be accessed publicly at this
> moment? What about public git:// access, is that supported/working?

There is no public access at the moment - just ssh based cloning. There
is no git:// access, just http(s) and ssh.

> Does the http hosting require fixing some bugs, or is it purely a
> configuration issue?

It's a configuration issue - phabricator can't find the git tool used
to html-ize repo interactions and I don't think it'll be a huge
problem to fix.

It would need to be fixed before deploying anything to production,
though. I'm not willing to lose anonymous access, even if we did have
mirrors on gh/bb

> >  - The repo names are ... weird. I understand why they end up like
> > they do, but I was hoping the uris would contain the repo name, not
> > the callsign.
> 
> That's a bit unfortunate. Does it mean that we need to differentiate
> all our repos by 4-letter access codes?

Yep, that's what it means.

> That would also mean that people cloning the repos need either
> provide a reasonable name to the git clone command, or they'll end up
> with cryptic directory names for our projects.

Yeah. I can see if that's what upstream's intention was - code hosting
is a relatively new feature and something may have changed but I doubt
it.

> > 
> > The setup is pretty straightforward and doesn't really mess with the
> > git hosting itself - just injects phabricator into the ssh auth
> > mechanism in a similar way to how gitolite works. If we did
> > decide to go this route for code hosting and something did go
> > horribly wrong, we have backups of the raw repos and it would be
> > pretty easy to resurrect them outside of phabricator.
> > 
> > Another feature that I haven't looked at much is mirroring - you can
> > configure repos to push commits to a remote repository. The
> > advantage here is that we could have the canonical upstream under
> > our control and have bitbucket/github mirrors that other folks
> > could use to create diffs from.
> 
> This might be a very good idea. We can use our system while the
> public can easily find and access our code, fork it, send a pull
> request.

I'm not sure how pull requests would work with reviews in phabricator
but that would be the general idea, yeah.

If we're thinking it's a good idea to host repos in phabricator, I'll
try to get the last config stuff done in the next day or so. I still
want to test everything thoroughly in stg first but assuming that we
don't hit any big problems, we can look at migrating next weekend.
 
> Or, if we find git hosting in Phab unsatisfactory, we can do it the
> other way round - host code on Github/Bitbucket and clone to Phab (if
> it helps something, for example reviews).

Yeah, the libtaskotron repo that's currently on production is a mirror
of bitbucket. Either way will work well enough for code reviews.

> When it comes to Github/Bitbucket choice, I played with them a bit
> and both seem pretty equal. They are closed-source, they support
> teams, and because we won't need issue tracking there's not many
> other differences. Only Github is more popular and more people have
> an account there, so I think that would be the only reason to pick
> Github over Bitbucket.

I agree that the two systems are pretty much equivalent for what we're
using. The one bit that's relevant to how we'd use either one is team
management. I really don't like how github does team/group management
and bitbucket's interface is easier to use.

I don't see how the benefit of switching to github outweighs the cost
of doing so. The last time I talked to infra, they hadn't really seen
an increase in contributions since they moved to github and I sincerely
doubt that we would either. Their workflow has improved with the switch
but almost all new contributors were already interested and involved in
fedora.

I'd really like to put this discussion to bed - it keeps coming up and
to be quite frank, we have more important things to do than talking
about which site we're using to host code when there's so little
difference between the two. I'm a big believer of choosing your battles
and I'm not going to fight a migration to github but I'm not going to
do the migration work, either. If there's enough sup

[perl-Date-Simple] Created tag perl-Date-Simple-3.03-13.el7

[Paul Howarth]

The lightweight tag 'perl-Date-Simple-3.03-13.el7' was created pointing to:

 138c886... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass
--
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; F22 will require applications to ship appdata to be listed in software center

[Rahul Sundaram]

Hi


On Thu, Jan 23, 2014 at 1:18 PM, "Jóhann B. Guðmundsson" wrote:

>
> Oh I see you apparently have no idea what we in the QA community do but
> since you dont we dont handle this matters so there is no point for me to
> file a ticket it would not lead anywhere
>

This seems pretty incoherent and I cannot parse it.   I don't know you
define QA community but I have participated in QA activities before and
understand the process just fine.  In any case, you were the one proposing
to file a ticket yourself to bring up your ideas to the QA team just a few
mails back and I suggested you follow up on it.  If you think you will fail
to build any kind of consensus even before trying, I guess we can drop your
idea and move on

Rahul
-- 
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: Fedora.next in 2014 -- Big Picture and Themes

[Josh Boyer]

On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis  wrote:
> Verbose: Yes, I really think the Fedora needs changes -- at some point
> a few years ago we mostly continued to do things as they have "always"
>  been done (read: since Core and Extras merged), without thinking if
> those ways are still the best.
>
> So I welcomed Fedora.next in the beginning. But I, as someone that is
> not involved very much in Fedora any more, still fail to fully grasp
> it. Yes, there are many mailing list or blog posts and some docs in
> the wiki. But most of them are really way too long for people that
> have busy days; a lot of those docs are also quite "meta",
> nevertheless afaics failing to give a goal. Take
> https://fedoraproject.org/wiki/Fedora.next for example. It more a
> description of a vague idea without saying much concrete besides
> "design, build, and market three distinct Fedora products" (what is a
> Fedora product?). There are a few links there, but even
> https://fedoraproject.org/wiki/Fedora.next/boardproposal is still
> quite meta for something which is supposed to be the base for a
> release that is eight months or so away. It doesn't explain what
> problems are being solved or what happens to spins (KDE and such) or
> how often (according to current plans) Fedora will be released in the
> future.

You make a fair point.  There are many unanswered questions around
Fedora.next (like spins?).  Asking those questions or pointing out
inconsistencies does help though :).

> What really gives me the creeps on those pages: "sub-committees of
> FESCo, with individual governance structures". Those afaics are three
> Product Working Groups Workgroups, two Fedora Rings Working Groups and
> the Inter-WG for coordination. That sounds like a awful lot of
> overhead an even more bureaucracy than we already have. And we imho
> have way to much already (part of it is my fault!) – something I had
> hoped Fedora.next would try to fix.

It is more overhead to a degree.  On the other hand, the idea is to
enable people that are interested in specific areas to go forth and
create a Fedora deliverable that they think meets the needs of those
areas best, without having to pass everything through FESCo.  FESCo
just doesn't scale like that.

> I these days wouldn't start contributing to Fedora, as all those rules
> and guidelines that the wiki provides would scare me off. That's what
> Fedora.next should fix imo, as we afaics need more contributors: I
> more often than a few years ago find packages in Fedora that are badly
> maintained or outdated. Contributing must be as easy as editing a

The packaging guidelines are very daunting.  Automating as much of
that as possible, either through spec creation tooling or package
review tooling would help.

> wikipedia page. Further: kororaproject.org, fedorautils-installer and
> similar project show that there are people that want to make Fedora
> better. But they do their work outside of Fedora and RPM Fusion;
> fixing the issues directly at the root would be better for all of us.

Small note:  The two projects you use as an example are required to do
what they're doing (in part) outside of Fedora for legal reasons.  I
don't believe Fedora.next will change how US law works, so it might
not be the best of examples.

(And we have a Board meeting to discuss related things that are not
legally prohibited.)

> And I really wonder if Fedora.next is really backed by those community
> contributors that are not involved in Fedora to deeply. One reason for

I wonder the same.  However, I don't think it's because we haven't
necessarily asked in all of the usual places, or haven't tried to
reach as many people as possible.  There has been very little response
from anyone and I can't tell if it's from indifference or from a lack
of them even being aware.  It's really hard to tell.

> that: Fedora.next mails like the one I'm replying to seem to get very
> few responses -- especially considering the fact that Fedora.next is
> something really important and brought to a list where small details
> quite often spawn very long discussions. Sometimes it's different --
> like the ongoing and long "3rd party and non-free software"
> discussion. That shows that a lot of people still care, but don't
> bother follow to closely what the workgroups discuss before it someone
> gets to a point where it's more visible.

Yes, that thread shows a lot of people caring.  However, those people
are still people that I consider "core contributors".

> That's why I got the feeing a lot of contributors are simply waiting
> for more concrete details to emerge before deciding what to make of
> Fedora.next; or they simply at all don't care to much what the higher
> ups do, as getting involved on that level can cost quite a lot of time
> and can be frustrating (that's not a complaint, that's simply how it
> is often; wasn't much different in my days, but noticed that more when
> I wasn't that active an more myself).

If they a

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

[Jóhann B. Guðmundsson]

On 01/23/2014 06:09 PM, Rahul Sundaram wrote:


I don't agree with the premise at all and therefore unsurprising I 
don't agree with this conclusion.  In any case, I sincerely doubt you 
will get even a single person other than yourself to agree with this 
proposal but feel free to try filing a ticket with the QA team.


Oh I see you apparently have no idea what we in the QA community do but 
since you dont we dont handle this matters so there is no point for me 
to file a ticket it would not lead anywhere , however FESCO does and 
last time I knew they where trying to deal with this effectively with 
infra ( I have filed ticket about this before as have others )  but as 
you can see they are not doing very god job of dealing with it ( last 
result lead to them trying to find co-maintainers before removing a 
package as you have proposed but as you can see it has lead nowhere ) 
And this is a manually run process ( which Bill usually runs I think ) 
which they have in place which must have fallen through the cracks due 
the whole .next or wg stuff. ( which is not surprising )


JBG
--
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-Set-Infinite] Created tag perl-Set-Infinite-0.65-9.el7

[Paul Howarth]

The lightweight tag 'perl-Set-Infinite-0.65-9.el7' was created pointing to:

 47a8651... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass
--
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; F22 will require applications to ship appdata to be listed in software center

[Rahul Sundaram]

Hi


Cutting off inactively maintained packages being the only way we can deal
> with that which in turn will reduce the size of the distribution to
> something we actually can maintain or cover ( which probably is around 5k
> components )
>

I don't agree with the premise at all and therefore unsurprising I don't
agree with this conclusion.  In any case, I sincerely doubt you will get
even a single person other than yourself to agree with this proposal but
feel free to try filing a ticket with the QA team.

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

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

El Wed, 22 Jan 2014 12:09:25 +
Richard Hughes  escribió:
> Hi,
> 
> As the subject suggests, Fedora 22 will require applications to have a
> long description to be shown in the software center. We're introducing
> this change so that we can show a powerful application full of
> high-quality content, rather than what we have now which is a equal
> mixture of awesome and sadness.

Its a fine idea but not feasible if we can not work out how to
pull the data together and make it available.

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

iQIcBAEBAgAGBQJS4VsLAAoJEH7ltONmPFDR8KMP/3Lvx0tvrR/sOvWSgwiMmmX3
QVVPtHxgjM8X1C2o8GFZ685BjfOrqGYT4Iu7cFeyHaojFENG3mDw5nbbfhbEBQ1s
5CP/v/z4ZK3gaUfSdcYTX4DXdUX1pct6nEatBqon32aqcm+hn2dw2CYqx/aoV0uU
akqEOh0TPbpsKNuqn4EIu7Hcv8FV4rcyscOVMu78IBIVDYhvrU7fJU1yQs2qfc88
/g0E8gNZzoj8+lTdnKljrPnEijoio0PCPKoMv5ZLnko8ZY2m6Fd/cbVZiBxK/LlJ
VvapJyxHGv99iClVULV6LHitFUdxtK+nOOhTtCY4xpHFEgZK7XUBbSC6iCFszax3
4/nwQ1qos51Dp9F5k9oUn7dBR3Lw+bBRjwxgMJTWZ00JoSswWHZwobWOpJQplGwO
en4t2gATraoDUFPlHcSCpRljK2WuHFQCd+7+SldayKmLdCOpluRzCXk1bksvQ7d/
zGIPcg9RbmJdBFdEFCTInGsl49iHrNRb5LtRccsY8jD7cNdPkduMZEgcmh8wzkHD
n7z6t6VLQoWAy54gcVzy5JW+1ZAVtK92oFA8WRE5ea6ZbnElhHxFbT0QXH/i91U8
j3uUGUWbDFnDyV1zcs2RIlknd5D2rr1wd6EV6g546XAM/TIqsRf19t0Jis8Uzo06
tPluJ3Gn69GRntB+bIia
=Kd7Z
-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

[Chris Murphy]

On Jan 23, 2014, at 5:09 AM, David Tardon  wrote:
> And at what point does package become
> unmaintained?

It seems self evident that it's at least insufficiently maintained, if it 
doesn't meet the long description requirement to appear in software center. I 
don't know how else you expect this to work.


> What I wanted to point out is that forced removal
> of packages _is not_ going to guarantee more packager's attention to
> the rest of the distribution.

Is there a reading comprehension problem in this thread? I don't recall seeing 
any suggestion that packages will be removed, let alone with force. They simply 
won't appear in software center if they don't meet the requirements for 
appearing in software center.

Chris Murphy

-- 
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: Fedora.next in 2014 -- Big Picture and Themes

[Thorsten Leemhuis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi!

On 03.01.2014 19:14, Matthew Miller wrote:
> […] So those are my things. What do you think about them? What
> else should be included? What different directions should we
> consider? How will we make Fedora more awesome than ever in the
> coming year?

Okay, I'll bite (after thinking whether writing this mail is worth it):

I'm still undecided if I overall like Fedora.next or fear it. But more
and more I tend to the latter position and wonder if it might be wise
to slow things down: Do one more Fedora release the old style in round
about June; that would give us more time to better discuss and work
out Fedora.next and get contributors involved better in the planing.

The main reason for that: Fedora.next is a huge effort that seems to
make everything even more complicated. It imho is also sold pretty
badly right now, as you have to invest quite a lot of time to
understand what Fedora.next actually is. And Fedora.next to me seems
like something the core contributors push forward without having
really abort those Fedora contributors who don't have Fedora as one of
their top priorities in life.


Verbose: Yes, I really think the Fedora needs changes -- at some point
a few years ago we mostly continued to do things as they have "always"
 been done (read: since Core and Extras merged), without thinking if
those ways are still the best.

So I welcomed Fedora.next in the beginning. But I, as someone that is
not involved very much in Fedora any more, still fail to fully grasp
it. Yes, there are many mailing list or blog posts and some docs in
the wiki. But most of them are really way too long for people that
have busy days; a lot of those docs are also quite "meta",
nevertheless afaics failing to give a goal. Take
https://fedoraproject.org/wiki/Fedora.next for example. It more a
description of a vague idea without saying much concrete besides
"design, build, and market three distinct Fedora products" (what is a
Fedora product?). There are a few links there, but even
https://fedoraproject.org/wiki/Fedora.next/boardproposal is still
quite meta for something which is supposed to be the base for a
release that is eight months or so away. It doesn't explain what
problems are being solved or what happens to spins (KDE and such) or
how often (according to current plans) Fedora will be released in the
future.

What really gives me the creeps on those pages: "sub-committees of
FESCo, with individual governance structures". Those afaics are three
Product Working Groups Workgroups, two Fedora Rings Working Groups and
the Inter-WG for coordination. That sounds like a awful lot of
overhead an even more bureaucracy than we already have. And we imho
have way to much already (part of it is my fault!) – something I had
hoped Fedora.next would try to fix.

I these days wouldn't start contributing to Fedora, as all those rules
and guidelines that the wiki provides would scare me off. That's what
Fedora.next should fix imo, as we afaics need more contributors: I
more often than a few years ago find packages in Fedora that are badly
maintained or outdated. Contributing must be as easy as editing a
wikipedia page. Further: kororaproject.org, fedorautils-installer and
similar project show that there are people that want to make Fedora
better. But they do their work outside of Fedora and RPM Fusion;
fixing the issues directly at the root would be better for all of us.

And I really wonder if Fedora.next is really backed by those community
contributors that are not involved in Fedora to deeply. One reason for
that: Fedora.next mails like the one I'm replying to seem to get very
few responses -- especially considering the fact that Fedora.next is
something really important and brought to a list where small details
quite often spawn very long discussions. Sometimes it's different --
like the ongoing and long "3rd party and non-free software"
discussion. That shows that a lot of people still care, but don't
bother follow to closely what the workgroups discuss before it someone
gets to a point where it's more visible.

That's why I got the feeing a lot of contributors are simply waiting
for more concrete details to emerge before deciding what to make of
Fedora.next; or they simply at all don't care to much what the higher
ups do, as getting involved on that level can cost quite a lot of time
and can be frustrating (that's not a complaint, that's simply how it
is often; wasn't much different in my days, but noticed that more when
I wasn't that active an more myself).

I have many more thoughts in my head, but I'll stop here, as those are
basically the most important things that bother me right now when
looking at Fedora and Fedora.next.

CU
knurd

P.S.: Fixed subject (s/2013/2014/)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJS4VlWAAoJEHK25u9MWD0tjR0QAJAe7Z35vN90Moq1mXGRpiMJ
n6qYwGFiORpnzLkO

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

[Jóhann B. Guðmundsson]

On 01/23/2014 05:41 PM, Rahul Sundaram wrote:

Hi


On Thu, Jan 23, 2014 at 12:20 PM, "Jóhann B. Guðmundsson" wrote:


On 01/23/2014 05:06 PM, Rahul Sundaram wrote:

By going through those reports you will notice how long it took
for those patches to be applied as well as see all those that have
yet to be applied.


Yep but these are not unique to components with an inactive upstream.  
All such enhancements take time to get through.   Any changes in the 
packages guidelines unless they break packages from building take a 
significant amount of time to work through.  I still see packages that 
are just now adopting to using systemd macros for instance or 
guidelines from years back and sometimes they are deliberately doing 
so to maintain compatibility with older releases but in many cases, it 
has just not been urgent enough to look into them until now.  I have 
been working on a package  (quassel) where upstream is very active but 
the Fedora package maintainer has been AWOL for a long time.


You have identified a problem but you are misattributing it.


No I'm not in-activity is still in-activity,,

In both these cases it falls on the hands of the packager/maintainer ( 
or none if he no longer is with us ).


Now

A)

You cannot help those packages to get more attention.

B)

Even if you did our current package maintenance framework does not allow 
for drive by patching/helping


C)

Even if that was not the case as you correctly pointed out Fedora 
suffers from general resource shortage.


all leading up to...

Cutting off inactively maintained packages being the only way we can 
deal with that which in turn will reduce the size of the distribution to 
something we actually can maintain or cover ( which probably is around 
5k components )


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

[Rahul Sundaram]

Hi


On Thu, Jan 23, 2014 at 12:20 PM, "Jóhann B. Guðmundsson" wrote:

>
> On 01/23/2014 05:06 PM, Rahul Sundaram wrote:
>
> By going through those reports you will notice how long it took for those
> patches to be applied as well as see all those that have yet to be applied.
>

Yep but these are not unique to components with an inactive upstream.  All
such enhancements take time to get through.   Any changes in the packages
guidelines unless they break packages from building take a significant
amount of time to work through.  I still see packages that are just now
adopting to using systemd macros for instance or guidelines from years back
and sometimes they are deliberately doing so to maintain compatibility with
older releases but in many cases, it has just not been urgent enough to
look into them until now.  I have been working on a package  (quassel)
where upstream is very active but the Fedora package maintainer has been
AWOL for a long time.

You have identified a problem but you are misattributing it.  Even my own
packages there are times where I haven't touched them for a while because I
have been busy with other things.  I would love to get more co-maintainers
and I have requested that from time to time.  What we have in Fedora is a
general resource shortage and that is not particularly uncommon in any open
source project.  The question we need to be asking ourselves is not whether
upstream is active but whether those package maintainers are active on
those specific packages and if they are not, how can we identify those
unattended packages and how can we help them get more attention?  Cutting
of random packages off the distribution is the wrong way to solve that.

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

[Jóhann B. Guðmundsson]

On 01/23/2014 05:06 PM, Rahul Sundaram wrote:
If you have specific problems in any packages, feel free to point them 
out. 


Tracker bug [1] which fixes requirements on crontab as got approved by 
the FPC [2].


Each of those ca 50 components contains a patch submitted by myself in 
last July which updates those components to be in compliance with FPG.


By going through those reports you will notice how long it took for 
those patches to be applied as well as see all those that have yet to be 
applied.


I myself spent several hours of my contributing time patching, 
rebuilding and test installing packages with those changes with this end 
result.


JBG

1. https://bugzilla.redhat.com/show_bug.cgi?id=947037
2. https://fedorahosted.org/fpc/ticket/261
--
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

[Rahul Sundaram]

Hi

On Thu, Jan 23, 2014 at 12:08 PM, "Jóhann B. Guðmundsson" wrote:

>
> On 01/23/2014 05:06 PM, Rahul Sundaram wrote:
>
>>
>> That doesn't answer the question.  You keep using the word "we".  Who is
>> we?
>>
>
> We in quality assurance if you want us to come up with an official respond
> regarding inactively maintained packages I can put it on the meeting agenda.
>

Sure.  Feel free to do that.  As I have noted before, if you are just
expressing your own opinion,  you need to differentiate between that and
the QA team.   To speak on behalf of the entire team. you need to make sure
there is consensus within that team that your opinion is shared by them.
Bringing it up in a meeting is an excellent way to ensure that.   If the QA
team on the whole believes that packages without an active upstream are a
significant resource drain on them and especially if they have any kind of
metrics confirming this,  we can and should look into ways to mitigating
that problem.  Thanks!

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

[Rahul Sundaram]

Hi


On Thu, Jan 23, 2014 at 11:56 AM, "Jóhann B. Guðmundsson"  wrote:

>
>
> Obviously not you...
>

That doesn't answer the question.  You keep using the word "we".  Who is we?

> To me this is pure community resources leakage due to distribution
litterers with the mentality of >packaging *everything* regardless if
upstream is dead or not because it works for *them*.

It is not packaging everything.  It is packaging things that someone cares
enough to volunteer to maintain and there is no reason to cut them off.  If
you have specific problems in any packages, feel free to point them out.
Otherwise, just presuming that they are somehow a problem is unconvincing.

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

[Jóhann B. Guðmundsson]

On 01/23/2014 05:06 PM, Rahul Sundaram wrote:


That doesn't answer the question.  You keep using the word "we".  Who 
is we?


We in quality assurance if you want us to come up with an official 
respond regarding inactively maintained packages I can put it on the 
meeting agenda.


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

[Jóhann B. Guðmundsson]

On 01/23/2014 04:27 PM, Rahul Sundaram wrote:

Hi


On Thu, Jan 23, 2014 at 11:08 AM, "Jóhann B. Guðmundsson" wrote:


On 01/23/2014 03:55 PM, Matthew Miller wrote:

> >So, one possibility would be to move
less-maintained packages to a separate
> >repository tree still included as Fedora and
enabled by default

>That wont reduce the bugs reported against it...

That's not necessarily bad. And by categorizing those bugs
separately, it
would be easier to treat them differently.


We dont want QA community members testers/reporters/triagers ( and
general end users ) wasting their contributed time reporting bugs
that wont get fixed.


Who is we?



Obviously not you...



Just because upstream is inactive doesn't mean that there are bugs and 
just because upstream is inactive doesn't mean package maintainers 
won't fix bug reports.



If a package maintainer fixes bug the package is no longer inactive 
since it's being actively maintained which is what matters regardless if 
upstream or just downstream with us...


Quite frankly it amazes me how much people put themselves on a pedestole 
for maintaining a component in a distribution and at the same time 
either fail  to understand or simply disregard the time,resources and 
scope the service sub-community as well as feature owners have to put 
into that component.


QA/Releng/Infra/Doc all have to spend contributed time and resources 
into that same component for the duration of the lifetime of the 
component in the distribution which more often than not, is long time 
after it's maintainer has "vanished" or the component simply is no 
longer being maintained downstream/upstream...


And all of the above is *beside* the negative effect such components 
have on end users that expect it to work since it's available to them 
through an application installer of any kind.


How much time would it have saved Richard not having to go through those 
dead or semi-dead components and how willing do you think people are 
jumping to assist him when they know there is 40% that the time they are 
contribute to that work will be for nothing since those app apps are 
dead or semi-dead upstream?


To me this is pure community resources leakage due to distribution 
litterers with the mentality of packaging *everything* regardless if 
upstream is dead or not because it works for *them*.


JBG

-- 
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 23 January 2014 15:55, Reindl Harald  wrote:
> consider packages for removal because upstream does not jump around
> and release at least once per year a new version is hmmm... i
> must not say the words in public

Please stop posting to this thread.

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: Heads up; F22 will require applications to ship appdata to be listed in software center

[Rahul Sundaram]

Hi


On Thu, Jan 23, 2014 at 11:08 AM, "Jóhann B. Guðmundsson" wrote:

>
> On 01/23/2014 03:55 PM, Matthew Miller wrote:
>
>> > >So, one possibility would be to move less-maintained packages to a
 separate
 > >repository tree still included as Fedora and enabled by default

>>> >That wont reduce the bugs reported against it...
>>>
>> That's not necessarily bad. And by categorizing those bugs separately, it
>> would be easier to treat them differently.
>>
>
> We dont want QA community members testers/reporters/triagers ( and general
> end users ) wasting their contributed time reporting bugs that wont get
> fixed.
>

Who is we?

Just because upstream is inactive doesn't mean that there are bugs and just
because upstream is inactive doesn't mean package maintainers won't fix bug
reports.  Most such components don't receive any bug reports whatsoever
because they are stable and work just fine for the niche users who need
them.   They don't add any real overhead to Fedora and cutting them will
just piss off users without any benefits.   As long as package maintainers
are willing to maintain them,  there is no reason to mess with the
process.   If we want to have a way to show that upstream is inactive, that
is pretty reasonable thing to do.

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

[Jóhann B. Guðmundsson]

On 01/23/2014 03:55 PM, Matthew Miller wrote:

> >So, one possibility would be to move less-maintained packages to a separate
> >repository tree still included as Fedora and enabled by default

>That wont reduce the bugs reported against it...

That's not necessarily bad. And by categorizing those bugs separately, it
would be easier to treat them differently.


We dont want QA community members testers/reporters/triagers ( and 
general end users ) wasting their contributed time reporting bugs that 
wont get fixed.

( I assume infra/releng dont want to spent resources in those either )

Or to put this differently if the WG's expect QA to spend *any* 
resources in the output they deliver, we in QA need to free up 
contributed time time in the QA community to do so and one way to achive 
that is for us to plug resources leakage like this one.


So do you want us being able to help you with your cloud effort or do 
you want us to waste time on dead components?


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

[Matthew Miller]

On Thu, Jan 23, 2014 at 03:49:17PM +, "Jóhann B. Guðmundsson" wrote:
> >So, one possibility would be to move less-maintained packages to a separate
> >repository tree still included as Fedora and enabled by default
> That wont reduce the bugs reported against it...

That's not necessarily bad. And by categorizing those bugs separately, it
would be easier to treat them differently.

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

[Bug 1057063] perl-Test-Moose-More-0.023 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Test-Moose-More-0.023-
   ||1.fc21
 Resolution|--- |RAWHIDE
Last Closed||2014-01-23 10:53:43



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

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

[Jóhann B. Guðmundsson]

On 01/23/2014 01:48 PM, Matthew Miller wrote:

So, one possibility would be to move less-maintained packages to a separate
repository tree still included as Fedora and enabled by default


That wont reduce the bugs reported against it...
--
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

[Reindl Harald]

Am 23.01.2014 16:49, schrieb Jóhann B. Guðmundsson:
> 
> On 01/23/2014 01:48 PM, Matthew Miller wrote:
>> So, one possibility would be to move less-maintained packages to a separate
>> repository tree still included as Fedora and enabled by default
> 
> That wont reduce the bugs reported against it...

well, why not remove all packages so no bugs get reported at all?

consider packages for removal because upstream does not jump around
and release at least once per year a new version is hmmm... i
must not say the words in public



signature.asc
Description: OpenPGP digital 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

[perl-Lucy: 23/28] - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild

[Lubomir Rintel]

commit 0c79fffcb9e01e3989f5b4364ef9602276f8f09a
Author: Dennis Gilmore 
Date:   Fri Jul 20 11:26:26 2012 -0500

- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild

 perl-KinoSearch.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-KinoSearch.spec b/perl-KinoSearch.spec
index 9419d6e..2ba49f5 100644
--- a/perl-KinoSearch.spec
+++ b/perl-KinoSearch.spec
@@ -5,7 +5,7 @@
 
 Name:   perl-KinoSearch
 Version:
%{cpan_version_major}%{?cpan_version_minor:.}%{cpan_version_minor}
-Release:2%{?dist}
+Release:3%{?dist}
 Epoch:  1
 Summary:Search engine library
 # ApacheLicense2.0.txt included is included just becuase the upstream
@@ -94,6 +94,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 20 2012 Fedora Release Engineering  
- 1:0.31.5-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
+
 * Wed Jun 20 2012 Petr Pisar  - 1:0.31.5-2
 - Perl 5.16 rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Lucy: 22/28] Perl 5.16 rebuild

[Lubomir Rintel]

commit be9ced862029eaa246aab0beaedbda820859d2a2
Author: Petr Písař 
Date:   Wed Jun 20 22:55:14 2012 +0200

Perl 5.16 rebuild

 perl-KinoSearch.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-KinoSearch.spec b/perl-KinoSearch.spec
index d8b7049..9419d6e 100644
--- a/perl-KinoSearch.spec
+++ b/perl-KinoSearch.spec
@@ -5,7 +5,7 @@
 
 Name:   perl-KinoSearch
 Version:
%{cpan_version_major}%{?cpan_version_minor:.}%{cpan_version_minor}
-Release:1%{?dist}
+Release:2%{?dist}
 Epoch:  1
 Summary:Search engine library
 # ApacheLicense2.0.txt included is included just becuase the upstream
@@ -94,6 +94,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Wed Jun 20 2012 Petr Pisar  - 1:0.31.5-2
+- Perl 5.16 rebuild
+
 * Wed Jun 20 2012 Petr Pisar  - 1:0.31.5-1
 - 0.315 bump
 
--
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-Lucy: 17/28] add BR

[Lubomir Rintel]

commit eff1b259ab55eb1b6970f90613ae13d9d71f2733
Author: Marcela Mašláňová 
Date:   Tue Dec 21 10:28:51 2010 +0100

add BR

 perl-KinoSearch.spec |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)
---
diff --git a/perl-KinoSearch.spec b/perl-KinoSearch.spec
index 3287f1f..d0bdcdd 100644
--- a/perl-KinoSearch.spec
+++ b/perl-KinoSearch.spec
@@ -12,7 +12,6 @@ Group:  Development/Libraries
 URL:http://search.cpan.org/dist/KinoSearch/
 Source0:
http://www.cpan.org/authors/id/C/CR/CREAMYG/KinoSearch-%{version}.tar.gz
 Source1:LICENSING.mbox
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildRequires:  perl(Compress::Zlib)
 BuildRequires:  perl(ExtUtils::CBuilder)
 BuildRequires:  perl(ExtUtils::ParseXS)
@@ -22,6 +21,8 @@ BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(Test::Pod::Coverage) >= 1.04
 BuildRequires:  perl(Test::Pod) >= 1.14
 BuildRequires:  perl(Time::HiRes)
+BuildRequires:  perl(JSON::XS)
+BuildRequires:  perl(Parse::RecDescent)
 Requires:   perl(Compress::Zlib)
 Requires:   perl(Lingua::Stem::Snowball) >= 0.94
 Requires:   perl(Lingua::StopWords) >= 0.02
@@ -69,6 +70,7 @@ rm -rf $RPM_BUILD_ROOT
 %changelog
 * Mon Dec 20 2010 Marcela Maslanova  - 1:0.31-2
 - 661697 rebuild for fixing problems with vendorach/lib
+- add BR
 
 * Sun Dec 12 2010 Lubomir Rintel  - 1:0.31-1
 - BR Time::HiRes to fix el6 build
--
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-Lucy: 15/28] Filter useless provide

[Lubomir Rintel]

commit 7e278932d2872263ac7a25f122b4533ee6491e87
Author: Lubomir Rintel 
Date:   Sun Dec 12 16:11:03 2010 +0100

Filter useless provide

 perl-KinoSearch.spec |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
---
diff --git a/perl-KinoSearch.spec b/perl-KinoSearch.spec
index f6c8f12..b7e8e5c 100644
--- a/perl-KinoSearch.spec
+++ b/perl-KinoSearch.spec
@@ -28,6 +28,8 @@ Requires:   perl(Lingua::StopWords) >= 0.02
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 Requires:   perl(Time::HiRes)
 
+%{?perl_default_filter}
+
 %description
 KinoSearch is a loose port of the Java search engine library Apache Lucene,
 written in Perl and C. The archetypal application is website search, but it
--
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-Lucy: 13/28] dist-git conversion

[Lubomir Rintel]

commit 2fe799fe2f02ad50608729f96dcb12df0301a34f
Author: Fedora Release Engineering 
Date:   Thu Jul 29 07:06:02 2010 +

dist-git conversion

 .cvsignore => .gitignore |0
 Makefile |   21 -
 import.log   |1 -
 3 files changed, 0 insertions(+), 22 deletions(-)
---
diff --git a/.cvsignore b/.gitignore
similarity index 100%
rename from .cvsignore
rename to .gitignore
--
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-Lucy: 8/28] - Upstream applied our PowerPC patch

[Lubomir Rintel]

commit 2ad1e209c36e91a10656f7df9ced468e330bdb0a
Author: Lubomir Rintel 
Date:   Mon Apr 13 16:17:04 2009 +

- Upstream applied our PowerPC patch

 .cvsignore   |2 +-
 perl-KinoSearch.spec |7 ---
 sources  |2 +-
 3 files changed, 6 insertions(+), 5 deletions(-)
---
diff --git a/.cvsignore b/.cvsignore
index 311dd9f..691c164 100644
--- a/.cvsignore
+++ b/.cvsignore
@@ -1 +1 @@
-KinoSearch-0.164.tar.gz
+KinoSearch-0.165.tar.gz
diff --git a/perl-KinoSearch.spec b/perl-KinoSearch.spec
index 2fb8e2f..60227d1 100644
--- a/perl-KinoSearch.spec
+++ b/perl-KinoSearch.spec
@@ -1,5 +1,5 @@
 Name:   perl-KinoSearch
-Version:0.164
+Version:0.165
 Release:1%{?dist}
 Summary:Search engine library
 # ApacheLicense2.0.txt included is included just becuase the upstream
@@ -11,7 +11,6 @@ Group:  Development/Libraries
 URL:http://search.cpan.org/dist/KinoSearch/
 Source0:
http://www.cpan.org/authors/id/C/CR/CREAMYG/KinoSearch-%{version}.tar.gz
 Source1:LICENSING.mbox
-Patch0: KinoSearch-0.164-ppc.patch
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildRequires:  perl(Compress::Zlib)
 BuildRequires:  perl(ExtUtils::CBuilder)
@@ -33,7 +32,6 @@ can be put to many different uses.
 
 %prep
 %setup -q -n KinoSearch-%{version}
-%patch0 -p1 -b .ppc
 cp %{SOURCE1} LICENSING.mbox
 
 %build
@@ -64,6 +62,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Mon Apr 13 2009 Lubomir Rintel  - 0.165-1
+- Upstream applied our PowerPC patch
+
 * Sun Mar 29 2009 Lubomir Rintel  - 0.164-1
 - Update to 0.164
 - Add missing Pod::Coverage BRs (Robert Scheck)
diff --git a/sources b/sources
index 3f3b18a..8cf29cc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9fd011170455974544af83005f0cb350  KinoSearch-0.164.tar.gz
+c191fd096aaf4d6219bbb36812551693  KinoSearch-0.165.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Lucy: 10/28] Fix typo that causes a failure to update the common directory. (releng #2781)

[Lubomir Rintel]

commit a3b0855529b189fa3fce927e44b26d51317b5083
Author: Bill Nottingham 
Date:   Wed Nov 25 23:30:57 2009 +

Fix typo that causes a failure to update the common directory. (releng
#2781)

 Makefile |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/Makefile b/Makefile
index 6d8bb0d..b8d4037 100644
--- a/Makefile
+++ b/Makefile
@@ -4,7 +4,7 @@ NAME := perl-KinoSearch
 SPECFILE = $(firstword $(wildcard *.spec))
 
 define find-makefile-common
-for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ; 
then if [ -f $$d/CVS/Root -a -w $$/Makefile.common ] ; then cd $$d ; cvs -Q 
update ; fi ; echo "$$d/Makefile.common" ; break ; fi ; done
+for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ; 
then if [ -f $$d/CVS/Root -a -w $$d/Makefile.common ] ; then cd $$d ; cvs -Q 
update ; fi ; echo "$$d/Makefile.common" ; break ; fi ; done
 endef
 
 MAKEFILE_COMMON := $(shell $(find-makefile-common))
--
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-Lucy: 9/28] - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild

[Lubomir Rintel]

commit 588c2846f5dd6cc34ee19c4f5d48c16a77bfab6e
Author: Jesse Keating 
Date:   Sun Jul 26 08:52:26 2009 +

- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild

 perl-KinoSearch.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-KinoSearch.spec b/perl-KinoSearch.spec
index 60227d1..581fa19 100644
--- a/perl-KinoSearch.spec
+++ b/perl-KinoSearch.spec
@@ -1,6 +1,6 @@
 Name:   perl-KinoSearch
 Version:0.165
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Search engine library
 # ApacheLicense2.0.txt included is included just becuase the upstream
 # author decided to include it and is only for informative purposes.
@@ -62,6 +62,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Sun Jul 26 2009 Fedora Release Engineering  
- 0.165-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
+
 * Mon Apr 13 2009 Lubomir Rintel  - 0.165-1
 - Upstream applied our PowerPC patch
 
--
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: Unannounced soname bump: libdbi?

[jpac...@redhat.com]

Hi,

that was my mistake. Now both libdbi and libdbi-drivers are in new
version in rawhide.

-- Jan Pacner

On 01/21/2014 09:53 PM, Ville Skyttä wrote:
> Hi,
> 
> Looks like yet another unannounced soname bump has occurred in
> Rawhide, this time libdbi. If there was an announcement, I haven't
> noticed it, and neither apparently have maintainers of dependent
> packages, and they haven't been addressed by anyone else either except
> for rrdtool which is currently being rebuilt.
> 
> libdbi owners, comments? Please observe
> https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages
> 
> Affected packages include at least:
> 
> Io-language
> collectd-dbi
> gammu-libs
> gnucash
> python-gammu
> rrdtool
> rrdtool-lua
> rsyslog-libdbi
> syslog-ng-libdbi
> ulogd-libdbi
-- 
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

[Matthew Miller]

On Thu, Jan 23, 2014 at 09:23:49AM +, "Jóhann B. Guðmundsson" wrote:
> "A*lot* of those applications haven't seen an upstream release in
> half a decade"
> Which poses security risk and bugs not being dealt and bad end user
> experience if our end user base chooses to install it.
> ( because if they were actually being maintained here with us those
> fixes would have found it's way upstream and new releases been made
> right ).

So, one possibility would be to move less-maintained packages to a separate
repository tree still included as Fedora and enabled by default (but maybe
removed from any references in comps). That could serve as a signal to both
users (who could see that the package comes from a different place) and
maintainers (who wouldn't have their package just _dropped_). And it would
make it more obvious when packages that are maintained have
possibly-dangerous dependencies on unmaintained ones.

I'm not sure the benefits of that are worth the effort, but if someone is
interested in working on it, it could be worth exploring.



> But clearly you dont understand that.

Jóhann, please review Fedora Code of Conduct:
http://fedoraproject.org/code-of-conduct. Let's keep this conversation both
civil and focused on the issue itself.

-- 
Matthew Miller--   Fedora Project--
-- 
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

[Reindl Harald]

Am 23.01.2014 14:06, schrieb Jóhann B. Guðmundsson:
> On 01/23/2014 12:09 PM, David Tardon wrote:
>> No, I think your reasoning is faulty and your attempts to see everything
>> in just black and white is fundamentally flawed. Anyway, that_was not_
>> the point of my mail. What I wanted to point out is that forced removal
>> of packages_is not_  going to guarantee more packager's attention to
>> the rest of the distribution. And it can in fact have the opposite
>> effect, by alienating and losing existing packagers.
> 
> I never implied that it would guarantee any more package attention that's an 
> assumption you made

so what is the benefit then in propose drop packages where *upstream not* every
2-3 years starts a complete rewrite with only half of the features, a lot of
bugs and regressions to qualify the next 3 years updates and after all the mess
is fixed start the next rewrite to qualify "ongoing development" for a lifetime?

if it ain't broken don't fix it!




signature.asc
Description: OpenPGP digital 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: LibRaw soname bump

[Christopher Meng]

It built very well(I did it this afternoon), you can check it out from Koji.

Hmm...Only some tiny issues need to be solved.
-- 
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

[Jóhann B. Guðmundsson]

On 01/23/2014 12:09 PM, David Tardon wrote:

No, I think your reasoning is faulty and your attempts to see everything
in just black and white is fundamentally flawed. Anyway, that_was not_
the point of my mail. What I wanted to point out is that forced removal
of packages_is not_  going to guarantee more packager's attention to
the rest of the distribution. And it can in fact have the opposite
effect, by alienating and losing existing packagers.


I never implied that it would guarantee any more package attention 
that's an assumption you made.


JBG
--
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 23 January 2014 12:37, David Howells  wrote:
> What constitutes an 'application' in this sense?  Does 'gcc' count for
> instance?  How about 'find'?

No. In the AppStream and AppData definitions, a program is an
application if "it has a .desktop file that is visible in the menu".
i.e. not NoDisplay=true and that has at least one valid category.

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: LibRaw soname bump

[Jon Ciesla]

It doesn't build anyway.  I've found that the latest release, 0.9.4, does,
but I see you've discovered that as well. :)

-J


On Wed, Jan 22, 2014 at 6:06 PM, Christopher Meng wrote:

> Jon please don't rebuild oyranos, I'm working on this now.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>



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

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

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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

[David Howells]

Richard Hughes  wrote:

> As the subject suggests, Fedora 22 will require applications to have a
> long description to be shown in the software center.

What constitutes an 'application' in this sense?  Does 'gcc' count for
instance?  How about 'find'?

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

[David Tardon]

Hi,

On Thu, Jan 23, 2014 at 08:51:53AM +, Richard Hughes wrote:
> On 23 January 2014 08:34, David Tardon  wrote:
> > I have noticed that there are applications on the list that have
> > NoDisplay=true in their desktop file, e.g., libreoffice-startcenter.
> 
> I've just downloaded libreoffice-4.2.0.2-2.fc21 and it has:
> 
> [Desktop Entry]
> Version=1.0
> Terminal=false
> NoDisplay=false
> Icon=libreoffice-startcenter
> ...

Sigh, it was changed by commit 78e4c8a925f4735a7e9a4c32a29b19fd2b77670d
"fdo#70553: Fix Unity Quicklists". So back to changing it in the spec...

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

[David Tardon]

On Thu, Jan 23, 2014 at 09:23:49AM +, "Jóhann B. Guðmundsson" wrote:
> 
> On 01/23/2014 08:07 AM, David Tardon wrote:
> >On Wed, Jan 22, 2014 at 04:37:07PM +, "Jóhann B. Guðmundsson" wrote:
> >>On 01/22/2014 03:47 PM, Richard Hughes wrote:
> >>>On 22 January 2014 12:09, Richard Hughes  wrote:
> >That's a long way from what I'd like to see, but it's going up at about 
> >1% per
> >month, which is encouraging.
> >>>Replying to my own email, apologies. I've now gone through the entire
> >>>list of applications-in-fedora-without-appdata. A*lot*  of those
> >>>applications haven't seen an upstream release in half a decade, some
> >>>over a decade. I would estimate that 40% of all the apps in Fedora are
> >>>dead or semi-dead upstream. Excluding the KDE/XFCE/LXDE applications,
> >>>I'd say we had a 70% completion of the applications I'd like to see in
> >>>the software center. I've filed a lot of upstream bugs in the last two
> >>>hours, so hopefully that's another few percent sorted.
> >>I wished we could simply just clean those bits out of our
> >>distribution because quite frankly we have 14+k components in the
> >>distribution and not nearly enough manpower to cover that all.
> >You seem to be operating under a delusion that, if someone's package is
> >forcibly dropped, (s)he will automatically seek comaintainership of
> >another package "to fill the vacuum". That is not very likely. What is
> >likely, however, is that (s)he will become angered, orphan the rest of
> >his/her packages and disappear.
> 
> I was operating under the *assumption* that the package was not
> being maintained as Richard said here...

But he did not said that. "There have been any upstream release" and
"the package is not maintained in _the distribution_" are two completely
different statements.

> "A*lot* of those applications haven't seen an upstream release in
> half a decade"

So? Maybe there have not been any bugs for half a decade that would
justify a new release? Or maybe the maintainer just keeps a lot of
patches in the package?

> Which poses security risk and bugs not being dealt

Says you. Again, what if there are not any bugs? Hard to tell, because
Richard did not list any names. And at what point does package become
unmaintained? If I look at a couple of not-so-randomly selected
packages, I see libreoffice has got 66 unresolved bugs, evolution 126
and gnome-shell 903... So which of these (if any) are "not being
maintained"?

> and bad end user
> experience if our end user base chooses to install it.
> ( because if they were actually being maintained here with us those
> fixes would have found it's way upstream and new releases been made
> right ).

Which fixes again?

> 
> But clearly you dont understand that.

No, I think your reasoning is faulty and your attempts to see everything
in just black and white is fundamentally flawed. Anyway, that _was not_
the point of my mail. What I wanted to point out is that forced removal
of packages _is not_ going to guarantee more packager's attention to
the rest of the distribution. And it can in fact have the opposite
effect, by alienating and losing existing packagers.

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

[389-devel] Running lib389 tests

[Roberto Polli]

Hi Thierry + @all,

I'd like to play with the new lib389 and try to split DirSrv in two layers:
 - the "old approach" DSAdmin for TCP communication
 - DirSrv implementing your interface

essentially I would put
class DirSrv(DSAdmin):
# ...new stuff go here ...

class DSAdmin(SimpleLDAPObject):
# TCP stuff goes here

Can you please tell me:
 1- how to run tests
 2- which tests should work
 3- which is the test environment.

Thx+Peace,
R.




On Thursday 09 January 2014 10:29:10 thierry bordaz wrote:
> On 01/08/2014 12:54 PM, Roberto Polli wrote:
> > Hi Thierry,
> > 
> > before all sorry if in the rest of the answer I may seem too direct. All I
> > say is obviously imh(opinion|experience) Time is a tyrant :(
> > 
> > On Friday 03 January 2014 16:36:17 thierry bordaz wrote:
> >>  Thanks, I also wish you an happy new year and you recover well. It
> >>  is great to talk to you again :-) .
> > 
> > Thx++!
> > 
> >>  I am quite novice with python and my first approach was to use it as
> >>  a real object oriented language,
> > 
> > It *is* a real OOL ;)
> > 
> >> it is a
> >> 
> >>  common use to wrap methods of class and rather use python as a
> >>  functional language (e.g. self.backend.setProperties(...) rather
> >>  than 'backend=Backend(); backend.setProperties(..) ')
> > 
> > I'm not indepth with functional programming. Why do you think that's a
> > functional approach?
> > 
> >>  ...the 'object'...are... the configuration object stored in
> >>  'cn=config'. So it prevents the problem of synchronizing the python
> >>  object with the 'cn=config' object.
> > 
> > To me that's mostly an ORM approach: in any case that's ok
> 
> Hi Roberto,
> 
> I will try to answer your concerns but as all of them are valid I
> will only give some reasons for the approach I choose.
> 
> About OOL vs. functional programing this is not IMH that important.
> For example for an instance with N replicas, we can imagine DSAdmin
> having N Replica/Backend/Suffix/MappingTree... objects. Instead we
> have only one, let's say Replica object, allocated in
> __add_brookers__ but this object is not a real object but just gives
> access all methods of  Replica class.
> As I said, having N Replica objects brings a big drawback to
> synchronize the objects with what is in the server config. So I
> think the __add_brookers__ approach is better.
> 
> >>  So the only remaining object is
> >>  the DS instance (dirsrv/dsadmin) and methods to access its config.
> >>  
> >>  Does it prevent to use fake directory ? I am not enough familiar
> >>  with fakeldap, would you give me an example of why the current
> >>  implement would not work with fakeldap ?
> > 
> > Let's see how do we setup the client now:
> >  args = {SER_HOST:  LOCALHOST,
> >  
> >  SER_PORT:  INSTANCE_PORT,
> >  SER_DEPLOYED_DIR:  INSTANCE_PREFIX,
> >  SER_SERVERID_PROP: INSTANCE_SERVERID
> >  }
> >  
> >  1- instance = DirSrv(verbose=False)
> >  2- instance.allocate(args)
> >  3- if instance.exists(): instance.delete()
> >  4- instance.create()
> >  5- instance.open()
> > 
> > That's quite different from the (imho cleaner) old approach - similar to
> > the> 
> > SimpleLDAPObject superclass:
> > args = {'host': LOCALHOST, 'sslport': 10636}
> > 1- instance = DSAdmin(**args)
> 
> I agree with you DSAdmin approach looks definitely simpler. Now
> there is some magic behind DSAdmin().
> It actually checks if the instance exists, if not it creates it,
> then it opens a connection to it.
> What I wanted to do in a lib is to give an interface to each
> individual action. We may want to create an instance without
> establishing a connection to it, or (re)create an instance even if
> one already exists.
> Your point is valid, we need something simple. So what about adding
> a new interface to DirSrv (e.g. NewAndConnect) that would do all the
> steps 1-5 ?
> 
> > Obviously there are plenty of functionalities DSAdmin didn't implement: I
> > would have put those functionalities (eg. filesystem related, instance
> > creation & removal) in the DSAdminTool class.
> > 
> > You may ask: why having two class DSAdminTool and DSAdmin instead of just
> > one? 1- clear design: as DSAdmin extends SimpleLDAPObject, it should
> > require just a tcp connection (like SimpleLDAPObject). In this way I can
> > use a mock ldap implementation to test the LDAP behavior of DSAdmin.
> 
> DirSrv also extends SimpleLDAPObject and wrap all its methods
> (search/add...) what would prevent it to be use as mock ldap ?
> 
> > 2- all the functionalities requiring filesystem access and instance
> > management (eg. outside LDAP scope) couldn't be tested by a mock ldap
> > implementation, so we can just extend the m

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

[Reindl Harald]

Am 23.01.2014 12:13, schrieb Richard Hughes:
> On 23 January 2014 10:12, Reindl Harald  wrote:
>> have you ever considered software as done and no known bugs?
> 
> Okay, I'll bite.
> 
>> ftp://ftp.ibiblio.org/pub/linux/apps/sound/mp3-utils/mp3info/
>> upstream may dead, upstream my be alive but nothing to do
>> the software does what it is expected to do
>> so why should there be a new release?
> 
> From the README of mp3info-0.8.5a.tgz:
> 
> ---
> TO DO
> =
> 
> * ID3v2 support is the most often-requested feature and is badly needed,
>   however this will entail an almost complete rewrite and I'm a lazy SOB,
>   so it's going to be a while yet...  Anybody wanna volunteer?
> ---
> 
> So, a command line program for getting info from an MP3 that doesn't
> support ID3v2, which is a 16 year old protocol that basically every CD
> ripping program defaults to? I'm not sure that supports your argument
> much

well, my usage of that tool is simply to get the duration from
files with a PHP script indexing my music archive, that call is
unchanged the last 7 years and so i continue to refuse the benefit
of throw a package out of the distribution because there is no
new upstream release

$handle = popen($GLOBALS['music_bin_mp3info'] . ' -p "%S" ' . 
escapeshellarg($path), 'r');

yes, i know that it is not a fedora package
mp3info-0.8.5a-20.fc20.20131231.rh.x86_64

but it is a good example of something used and just works with our
witout new upstream releases



signature.asc
Description: OpenPGP digital 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 23 January 2014 10:12, Reindl Harald  wrote:
> have you ever considered software as done and no known bugs?

Okay, I'll bite.

> ftp://ftp.ibiblio.org/pub/linux/apps/sound/mp3-utils/mp3info/
> upstream may dead, upstream my be alive but nothing to do
> the software does what it is expected to do
> so why should there be a new release?

From the README of mp3info-0.8.5a.tgz:

---
TO DO
=

* ID3v2 support is the most often-requested feature and is badly needed,
  however this will entail an almost complete rewrite and I'm a lazy SOB,
  so it's going to be a while yet...  Anybody wanna volunteer?
---

So, a command line program for getting info from an MP3 that doesn't
support ID3v2, which is a 16 year old protocol that basically every CD
ripping program defaults to? I'm not sure that supports your argument
much.

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: Heads up; F22 will require applications to ship appdata to be listed in software center

[Reindl Harald]

Am 23.01.2014 10:23, schrieb Jóhann B. Guðmundsson:
> "A*lot* of those applications haven't seen an upstream release 
> in half a decade" Which poses security risk and bugs not being dealt 
> and bad end user experience if our end user base chooses to install it

have you ever considered software as done and no known bugs?

> ( because if they were actually being maintained here with us those fixes 
> would have found it's way upstream and new releases been made right ).
> 
> But clearly you dont understand that

maybe you do not understand that there is no golden rule
to fix bugs and release updates for no reason

ftp://ftp.ibiblio.org/pub/linux/apps/sound/mp3-utils/mp3info/

upstream may dead, upstream my be alive but nothing to do
the software does what it is expected to do
so why should there be a new release?

not every software developer makes changes for the sake of the change



signature.asc
Description: OpenPGP digital 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

[Jóhann B. Guðmundsson]

On 01/23/2014 08:07 AM, David Tardon wrote:

On Wed, Jan 22, 2014 at 04:37:07PM +, "Jóhann B. Guðmundsson" wrote:

On 01/22/2014 03:47 PM, Richard Hughes wrote:

On 22 January 2014 12:09, Richard Hughes  wrote:

That's a long way from what I'd like to see, but it's going up at about 1% per
month, which is encouraging.

Replying to my own email, apologies. I've now gone through the entire
list of applications-in-fedora-without-appdata. A*lot*  of those
applications haven't seen an upstream release in half a decade, some
over a decade. I would estimate that 40% of all the apps in Fedora are
dead or semi-dead upstream. Excluding the KDE/XFCE/LXDE applications,
I'd say we had a 70% completion of the applications I'd like to see in
the software center. I've filed a lot of upstream bugs in the last two
hours, so hopefully that's another few percent sorted.

I wished we could simply just clean those bits out of our
distribution because quite frankly we have 14+k components in the
distribution and not nearly enough manpower to cover that all.

You seem to be operating under a delusion that, if someone's package is
forcibly dropped, (s)he will automatically seek comaintainership of
another package "to fill the vacuum". That is not very likely. What is
likely, however, is that (s)he will become angered, orphan the rest of
his/her packages and disappear.


I was operating under the *assumption* that the package was not being 
maintained as Richard said here...
"A*lot* of those applications haven't seen an upstream release in half a 
decade"
Which poses security risk and bugs not being dealt and bad end user 
experience if our end user base chooses to install it.
( because if they were actually being maintained here with us those 
fixes would have found it's way upstream and new releases been made 
right ).


But clearly you dont understand that.

JBG
--
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 23 January 2014 08:34, David Tardon  wrote:
> I have noticed that there are applications on the list that have
> NoDisplay=true in their desktop file, e.g., libreoffice-startcenter.

I've just downloaded libreoffice-4.2.0.2-2.fc21 and it has:

[Desktop Entry]
Version=1.0
Terminal=false
NoDisplay=false
Icon=libreoffice-startcenter
...

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: Heads up; F22 will require applications to ship appdata to be listed in software center

[David Tardon]

Hi,

On Wed, Jan 22, 2014 at 12:09:25PM +, Richard Hughes wrote:
> Hi,
> 
> As the subject suggests, Fedora 22 will require applications to have a
> long description to be shown in the software center. We're introducing
> this change so that we can show a powerful application full of
> high-quality content, rather than what we have now which is a equal
> mixture of awesome and sadness.
> 
> If you're interested you can see the number of applications with
> appdata without installing gnome-software from rawhide here:
> http://alt.fedoraproject.org/pub/alt/screenshots/f21/status.html
> (warning; huge generated HTML file).

I have noticed that there are applications on the list that have
NoDisplay=true in their desktop file, e.g., libreoffice-startcenter.
Should these be skipped?

D.
-- 
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 23 January 2014 08:07, David Tardon  wrote:
> You seem to be operating under a delusion that, if someone's package is
> forcibly dropped, (s)he will automatically seek comaintainership of
> another package "to fill the vacuum". That is not very likely. What is
> likely, however, is that (s)he will become angered, orphan the rest of
> his/her packages and disappear.

I don't think we need to drop any packages, unless keeping that
package is actually making our life harder in a significant way. What
I think it's makes a lot of sense doing is -hiding- the applications
that are abandonware. Users that really want some low level tool using
GTK-1 already know the package name, and are likely very familiar with
the command line.

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: Heads up; F22 will require applications to ship appdata to be listed in software center

[Richard Hughes]

On 22 January 2014 21:44, Matthew Miller  wrote:
>> Richard already wrote a plugin :)
>> https://github.com/GNOME/gnome-software/blob/e80d751ae0768a8969ff52e1cfc29a692a79bda0/src/plugins/gs-plugin-fedora-tagger.c
> Clearly, an excellent idea, then. :)

Yes, it's all wired up and working in Fedora rawhide. The ratings flow
both ways, so that if the user clicks on the star rating widget then
it gets pushed back to fedora-tagger, and if the user hasn't got the
app installed then the fedora-tagger rating is shown. It works pretty
well now, but when the masses start (hopefully) using it in F21 it'll
be more statistically sound.

> But actually what I meant was whether it would be valuable for the tagger
> app to _also_ let you add descriptions to applications which should have
> appdata but don't. This is probably a less-good idea... I was just thinking
> that since we have a program for user-created package metadata of one sort,
> maybe it could also help here.

I don't think that works, as there's often an n:1 ratio of
applications to packages.

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: Heads up; F22 will require applications to ship appdata to be listed in software center

[David Tardon]

On Wed, Jan 22, 2014 at 04:37:07PM +, "Jóhann B. Guðmundsson" wrote:
> 
> On 01/22/2014 03:47 PM, Richard Hughes wrote:
> >On 22 January 2014 12:09, Richard Hughes  wrote:
> >>>That's a long way from what I'd like to see, but it's going up at about 1% 
> >>>per
> >>>month, which is encouraging.
> >Replying to my own email, apologies. I've now gone through the entire
> >list of applications-in-fedora-without-appdata. A*lot*  of those
> >applications haven't seen an upstream release in half a decade, some
> >over a decade. I would estimate that 40% of all the apps in Fedora are
> >dead or semi-dead upstream. Excluding the KDE/XFCE/LXDE applications,
> >I'd say we had a 70% completion of the applications I'd like to see in
> >the software center. I've filed a lot of upstream bugs in the last two
> >hours, so hopefully that's another few percent sorted.
> 
> I wished we could simply just clean those bits out of our
> distribution because quite frankly we have 14+k components in the
> distribution and not nearly enough manpower to cover that all.

You seem to be operating under a delusion that, if someone's package is
forcibly dropped, (s)he will automatically seek comaintainership of
another package "to fill the vacuum". That is not very likely. What is
likely, however, is that (s)he will become angered, orphan the rest of
his/her packages and disappear.

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