Re: Why has fedpkg suddenly grown a dependency on MySQL-python?

[Toshio Kuratomi]

On Tue, Nov 22, 2011 at 01:16:01AM -0500, Tom Lane wrote:
> I was rather surprised to find a routine "yum update" on my F14 system
> suddenly wanting to pull in a lot of mysql stuff that I'd not had
> installed at the moment.  Investigation showed that if I try to remove
> MySQL-python again, yum wants to take all this stuff with it:
> 
> Removing:
>  MySQL-python x86_64  1.2.3-1.fc14  @updates  228 
> k
> Removing for dependencies:
>  TurboGears   noarch  1.0.9-8.fc14  @updates  7.6 
> M
>  bodhi-client noarch  0.8.0-1.fc14  @updates   25 
> k
>  fedora-easy-karmanoarch  0-0.15.20110825git36efb338.fc14   @updates   75 
> k
>  fedora-packager  noarch  0.5.9.2-2.fc14@updates   72 
> k
>  fedpkg   noarch  0.5.9.2-2.fc14@updates  248 
> k
>  python-fedoranoarch  0.3.25.1-1.fc14.1 @updates  1.7 
> M
>  python-sqlobject noarch  0.10.2-6.fc14 @fedora   1.6 
> M
> 
> Needless to say, that would put rather a crimp in my ability to do any
> Fedora packaging work on this machine.
> 
> AFAIK, there is no legitimate reason for fedpkg or fedora-packager to
> need to talk to a mysql database, so I'd really like to see this
> dependency go away again.  I have routine occasion to shuffle mysql
> packages in and out, and I don't want entirely-unnecessary dependencies
> getting in the way.
> 
Are you able to upgrade to a later Fedora?  I think you're seeing this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=754538

which is a confluence of the update policy and conflicting use cases wanting
a bug to either be fixed or not.  In Fedora > 14, this shouldn't be an
issue.

Note that for your use case, this dep chain might also be breakable in
python-sqlobject.  For python-sqlalchemy we decide that we only explicitly
rely on sqlite (which is provided by python itself these days).  We treat
MySQL and postgres backends as optional deps that users or applications must
explicitly install if they want to use them.

-Toshio


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

Re: Why has fedpkg suddenly grown a dependency on MySQL-python?

[Mathieu Bridon]

On Tue, 2011-11-22 at 01:16 -0500, Tom Lane wrote:
> I was rather surprised to find a routine "yum update" on my F14 system
> suddenly wanting to pull in a lot of mysql stuff that I'd not had
> installed at the moment.  Investigation showed that if I try to remove
> MySQL-python again, yum wants to take all this stuff with it:

You forgot to paste the most important:
# yum remove MySQL-python
[... snip ...]
---> Package MySQL-python.x86_64 0:1.2.3-1.fc14 set to be erased
--> Processing Dependency: MySQL-python for package:
python-sqlobject-0.10.2-6.fc14.noarch
--> Running transaction check
---> Package python-sqlobject.noarch 0:0.10.2-6.fc14 set to be erased
--> Processing Dependency: python-sqlobject >= 0.8 for package:
TurboGears-1.0.9-8.fc14.noarch
--> Running transaction check
---> Package TurboGears.noarch 0:1.0.9-8.fc14 set to be erased
--> Processing Dependency: TurboGears for package:
python-fedora-0.3.25.1-1.fc14.1.noarch
--> Running transaction check
---> Package python-fedora.noarch 0:0.3.25.1-1.fc14.1 set to be erased
--> Processing Dependency: python-fedora for package:
fedpkg-1.3.0.1-1.fc14.noarch
[... snip ...]
> Removing:
>  MySQL-python x86_64  1.2.3-1.fc14  @updates  228 
> k
> Removing for dependencies:
>  TurboGears   noarch  1.0.9-8.fc14  @updates  7.6 
> M
>  bodhi-client noarch  0.8.0-1.fc14  @updates   25 
> k
>  fedora-easy-karmanoarch  0-0.15.20110825git36efb338.fc14   @updates   75 
> k
>  fedora-packager  noarch  0.5.9.2-2.fc14@updates   72 
> k
>  fedpkg   noarch  0.5.9.2-2.fc14@updates  248 
> k
>  python-fedoranoarch  0.3.25.1-1.fc14.1 @updates  1.7 
> M
>  python-sqlobject noarch  0.10.2-6.fc14 @fedora   1.6 
> M
> 
> Needless to say, that would put rather a crimp in my ability to do any
> Fedora packaging work on this machine.
> 
> AFAIK, there is no legitimate reason for fedpkg or fedora-packager to
> need to talk to a mysql database,

They don't.

They require python-fedora, which provides a client library (used by
fedpkg iirc) as well as the necessary integration with FAS for
TurboGears, TurboGears2, Django, etc...

Perhaps python-fedora would need to be splitted then? That would have
the added benefit to remove those web stacks, rather than just the mere
228kB taken by MySQL-python.

I guess it just takes someone to do it. ;)


-- 
Mathieu


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

Why has fedpkg suddenly grown a dependency on MySQL-python?

[Tom Lane]

I was rather surprised to find a routine "yum update" on my F14 system
suddenly wanting to pull in a lot of mysql stuff that I'd not had
installed at the moment.  Investigation showed that if I try to remove
MySQL-python again, yum wants to take all this stuff with it:

Removing:
 MySQL-python x86_64  1.2.3-1.fc14  @updates  228 k
Removing for dependencies:
 TurboGears   noarch  1.0.9-8.fc14  @updates  7.6 M
 bodhi-client noarch  0.8.0-1.fc14  @updates   25 k
 fedora-easy-karmanoarch  0-0.15.20110825git36efb338.fc14   @updates   75 k
 fedora-packager  noarch  0.5.9.2-2.fc14@updates   72 k
 fedpkg   noarch  0.5.9.2-2.fc14@updates  248 k
 python-fedoranoarch  0.3.25.1-1.fc14.1 @updates  1.7 M
 python-sqlobject noarch  0.10.2-6.fc14 @fedora   1.6 M

Needless to say, that would put rather a crimp in my ability to do any
Fedora packaging work on this machine.

AFAIK, there is no legitimate reason for fedpkg or fedora-packager to
need to talk to a mysql database, so I'd really like to see this
dependency go away again.  I have routine occasion to shuffle mysql
packages in and out, and I don't want entirely-unnecessary dependencies
getting in the way.

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

Re: Fedora clean up process seems to be seriously broken...

[Kevin Kofler]

Jóhann B. Guðmundsson wrote:
> Instead of everybody that are doing needed work in the distribution
> having to run around after maintainers trying to find out if they are
> still active or not and initiate the unresponsive maintainer policy,
> cant we revert the process and have maintainer(s) having to reassure
> their ownership on their package(s) at the begin of each development
> cycle and if they dont do that before x time, the package(s) they
> maintain will be automatically orphaned and given up for someone else to
> grab and take ownership before x time runs out and if nobody does they
> get remove from the distribution?

That is only going to annoy existing active contributors, who have really 
other things to do than to go clicking on a button for every package every 6 
months!

It's bad enough that we had that FPCA to agree on (in a big hurry, after the 
old ICLA had served us well for years) and now the password and SSH key to 
change (for no reason). Hassling us with even more "hey, I'm still there" 
buttons to click on won't help at all.

> I cant image how much resources across the project have been spent on
> packages that no longer are being actively maintained but have not been
> removed from the distribution.

I think actually not that much. And for a user, it's usually better to have 
a package available, even if it's poorly maintained, than to not have it at 
all! Removing a package also leads to upgrade path issues such as broken 
dependencies in the dropped package when the user upgrades to a newer 
Fedora. This really should only be an absolute last resort if the package 
cannot be made to work at all.

Kevin Kofler

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

Re: (re)introducing - fedora-review - tool to help with package reviews

[Nathan O.]

Well there may be a chance this tool may eventually become officially
adopted by QA after it gets tested and used long enough to consider it
safe/stable.

On Mon, Nov 21, 2011 at 7:48 AM, Stanislav Ochotnicky <
sochotni...@redhat.com> wrote:

> Excerpts from "Jóhann B. Guðmundsson"'s message of Mon Nov 21 14:25:22
> +0100 2011:
> > > [1] https://fedorahosted.org/FedoraReview
> > > [2] https://fedorahosted.org/FedoraReview/browser/api/README
> >
> > Is this not something that releng/autoqa could use as well as in run
> > against all already existing specs and automatically file bugs if they
> > aren't ( and to keep things ) up to guidelines?
>
> I wouldn't be against it, but I can imagine all the shouting on the
> bugzilla and mailing lists this would cause(i.e. "But my package is
> working!!").
>
> Plus output of our tool is more verbose than rpmlint (thought it does
> more as well). There will always be tests that cannot be automated for
> one reason or the other. In cases like that we have ways to add
> helpful information to the template (for example output of
> "licensecheck" run on all files in tarball could be added to licensing
> part). This helpful output would be considered noise for a lot of
> packagers I guess.
>
> And there will always be false positives. I would hope none of
> our checks will have false negative (i.e. check will report "A-OK",
> but the guidelines would be broken).
>
> All that said: If our QA/releng guys find some part of fedora-review
> needs some tweaks to be usable for tasks they have to do: file issues
> in our trac and we'll do our best.
>
> --
> Stanislav Ochotnicky 
> Software Engineer - Base Operating Systems Brno
>
> PGP: 7B087241
> Red Hat Inc.   http://cz.redhat.com
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Changing kernel API / Breaking VirtualBox - update criteria violation?

[Toshio Kuratomi]

On Mon, Nov 21, 2011 at 02:58:32PM -0600, Michael Cronenworth wrote:
> Till Maas wrote:
> > a recent kernel update[0] broke Fedora's ability to be a VirtualBox
> > host, because asm/amd_iommu.h was removed. The removal of the file was
> > noticed during testing, but it seems nobody noticed that this affects
> > VirtualBox. Is this kind of change sanctioned by the
> > current update criteria?
> 
> Till,
> 
> The amd_iommu.h header was moved from asm/ to linux/ in kernel 3.1. The 
> VirtualBox source has a define for version < 3.1 use asm/, else use 
> linux/. This problem won't be seen by F16 users. It's a small 
> side-effect in F15 as it is still using 2.6.x kernel versioning.
> 
> As to the update criteria, it would be allowed. VirtualBox is not a 
> Fedora package. AFAIK the only thing stopping VBox from being a Fedora 
> package is its required kernel module and Fedora's policy against 
> out-of-kernel modules.

Actually, this isn't correct.  Or rather, the update may or may not be
allowed by the crieria but it certainly is not allowed for the reason
cited.  Here's some sippets from the Policy:

Introduction:
"In general, releases should go from less conservative (rawhide) to more so
(the oldest supported stable release)."


Beta To Pre Release:
[By the Beta stage of a release cycle maintainers MUST::]
"# Avoid Major version updates, ABI breakage or API changes if at all
possible. "


Stable release: Philosophy:
"Updates should aim to fix bugs, and not introduce features, particularly
when those features would materially affect the user or developer
experience"

"ABI changes in general are very strongly discouraged, they force larger
update sets on users and they make life difficult for third-party
packagers."


Stable Release: All other updates:
"Package maintainers MUST:
* Avoid Major version updates, ABI breakage or API changes if at all possible. 
"

The updates policy is meant to protect users of Fedora within reason.
Compiling, writing, and using third party software on Fedora is a valid use
of Fedora whether or not that software exists within Fedora.  This update
may be acceptable because the bugs fixed were deemed more worthwhile than
the changes that were introduced but that decision should not hinge upon the
availability of affected software within Fedora but upon the popularity of
such software among users of Fedora, the ease with which that software can
be made to work with Fedora once the change goes in, and how those questions
weigh against the issues that are resolved by the new version.

If those aren't the criteria that we want to use then the updats policy (and
possibly the updates vision) should be amended.

-Toshio


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

Re: gdk-pixbuf being retired

[Kevin Fenzi]

On Mon, 21 Nov 2011 18:40:14 -0600
Bruno Wolff III  wrote:

> I picked up gdk-pixbuf because freetennis supposedly depended on it
> but actually doesn't. (Though freetennis if also FTBFS for another
> reason so clearing the dependency isn't simple.) Though only thing
> that really depends on it is xosd-xmms and I have checked with Kevin
> about that and he will remove that subpackage or retire xosd.
> 
> gdk-pixbuf is FTBFS because it won't build without rerunning some of
> the autotools programs and does not build with the currently available
> autotools versions available. There are a number of errors reported
> that would need to get this building again and the effort doesn't seem
> worth it.
> 
> So I have now retired the package in rawhide (f17).

To go along with this, I am retiring xosd. There are still a few things
that use it or have xosd subpackages. If any of those folks want to
take it over, they would need both it and gdk-pixbuf. 

ekg2-xosd-0:0.2-0.17.rc1.fc16.x86_64
lcdproc-0:0.5.4-1.fc16.x86_64
licq-osd-0:1.3.5-10.fc15.x86_64
xmms-xosd-0:2.2.14-14.fc15.x86_64
xneur-0:0.13.0-1.fc16.x86_64

kevin


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

gdk-pixbuf being retired

[Bruno Wolff III]

I picked up gdk-pixbuf because freetennis supposedly depended on it but
actually doesn't. (Though freetennis if also FTBFS for another reason so
clearing the dependency isn't simple.) Though only thing that really
depends on it is xosd-xmms and I have checked with Kevin about that and
he will remove that subpackage or retire xosd.

gdk-pixbuf is FTBFS because it won't build without rerunning some of
the autotools programs and does not build with the currently available
autotools versions available. There are a number of errors reported
that would need to get this building again and the effort doesn't seem
worth it.

So I have now retired the package in rawhide (f17).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora clean up process seems to be seriously broken...

[Jóhann B. Guðmundsson]

On 11/21/2011 11:21 PM, "Jóhann B. Guðmundsson" wrote:
> On 11/21/2011 10:50 PM, Michael Schwendt wrote:
>> I understand this thread as a comment on improving the detection of
>> inactive maintainers and unmaintained packages.
>
> It is indeed intended as such.
>

BTW does anyone have any insight on how other distributions are solving 
this Debian/Suse/Gentoo/Arch etc. since we are all faced with this 
problem and surely some distribution might have solved this problem already.

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

Re: Fedora clean up process seems to be seriously broken...

[Jóhann B. Guðmundsson]

On 11/21/2011 10:50 PM, Michael Schwendt wrote:
> I understand this thread as a comment on improving the detection of
> inactive maintainers and unmaintained packages.

It is indeed intended as such.

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

Re: Fedora clean up process seems to be seriously broken...

[Jóhann B. Guðmundsson]

On 11/21/2011 11:00 PM, Miloslav Trmač wrote:
> [1] It does matter because there is a risk of security vulnerabilities
> being unaddressed - but, hopefully, at least for the frequently used
> packages somebody would notice.

This in itself should be valid enough point to have proper clean up 
process in place.

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

Re: Fedora clean up process seems to be seriously broken...

[Jóhann B. Guðmundsson]

On 11/21/2011 10:36 PM, Kevin Fenzi wrote:
> On Mon, 21 Nov 2011 14:03:43 -0800
> Jesse Keating  wrote:
>
>> This has come up nearly every release cycle.  Problem is that nobody
>> can seem to agree on what an appropriate "sign of life" would be, no
>> has made a serious FESCo proposal for a contrived sign of life.
>>
>> I don't think anybody disagrees (well maybe KKoffler) that
>> unmaintained software should be discovered and ejected from the
>> distro, the entirety of the problem lies how to discover (as well as
>> side issues about what to do about maintainers that are active for
>> one package, but completely ignore 3 others, etc…)
>>
>> So if you are serious about wanting this fixed, draft a proposal,
>> figure out who's going to do the coding work, and bring it to FESCo.
> To quote Ajax: +!
>
> I think the current policy is not very ideal either, but haven't had
> time/energy to work out a new one. ;)
>
> My last thought was to come up with a automated/script way to gather
> info from: bugzilla, pkgdb, koji, git, mailing lists, etc and output a
> list of 'likely inactive people'. Then, have a group of humans look at
> the list, and try and contact/ping people. With no reply after a
> timeperiod, orphan their packages.

Hum not so sure that will effectively work at least the cleanup process 
needs have take place before we start the next development cycle atleast 
no later then GA so basically the "performance" review of the maintainer 
would have taken place in F15 for F17 and would take place in F16 for 
F18 etc...

>
> Note that we need to balance here cases like:
>
> * maintainer is very active, just ignoring $leafpackage right now.

Indicator that the maintainer needs comaintainers

> * maintainer is on vacation/sick/etc

Indicator that the maintainer needs comaintainers

> * maintainer needs help, we should try and help them out.


Indicator that the maintainer needs comaintainers if not that, workload 
could be spread out to other community groups ( provenpackager/QA etc )

>
> * maintainer doesn't use our bugzilla as their primary bug zone.

That problem can be solved technically as in be made transparent to 
reports and maintainers ( reporters using our bugzilla but maintainers 
using their relevant upstream one )

> * maintainer maintains a software that has a vast number of bugs and
>they can't deal with them all.

True but you would actually see that on the activity on the bug report

>
> * maintainer is working on higher priority bug, so ignoring feature
>requests/etc.

Again that would be seen on the activity on the bug report

Encase we are "short" on maintainers one way to increase that pool would 
be to drop the ownership model essentially making everybody 
provenpackager and allow everbody to play in everybody's pool...

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

Re: Fedora clean up process seems to be seriously broken...

[Reindl Harald]

Am 21.11.2011 23:50, schrieb Michael Schwendt:
> On Mon, 21 Nov 2011 22:58:50 +0100, RH (Reindl) wrote:
> 
>> +1
>>
>> nothing is more frustrating for users as ignored bugreports reintroduced from
>> release to relase while th eonly response is from bugzapper about EOL of the
>> release
> 
> Well, that's not the same problem as this thread is about.
> 
> There a very active packagers (and developers who also do packaging tasks)
> who don't respond to [all] tickets due to various reasons. Some of the
> reasons are valid. Become a package maintainer yourself, Harald, before
> you judge about them all.

i do not judge!

in my opinion there is no reason to not respond
respond can be negative with a short "why"
well, this would be much more helpful as bugzapper-mails

it is a hughe difference if you give no feedback to anyone
who took the time to make a bugreport or ignore it

if the respponse is "sorry no time yet" is would be much
morehelpful than no response at all

> I understand this thread as a comment on improving the detection of
> inactive maintainers and unmaintained packages.

yes - and bugzapper-messages should be sorted out to find
inactive maintainers - i do not say that every ignored
report is a inactive maintainer but it is a possible sign

we all know that nothing will be perfect now or in future but
give users the feeling that they are not ignored is a high value



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

Re: Fedora clean up process seems to be seriously broken...

[Miloslav Trmač]

On Mon, Nov 21, 2011 at 11:50 PM, Michael Schwendt  wrote:
> Nothing is in place to detect inactive maintainers automatically.

We don't really need absolute automation - if a package is not
actively maintained but nobody notices, does it really matter?[1]

The case that has motivated this particular thread could be handled by
FESCo declaring that $feature is a "must-have" for F17, and the
feature owner collecting a list of packages that were not updated
despite a specified amount of interaction and offers to help.  Then,
for F17, work with that list.  (And there are even various levels of
"must have"-ness - e.g. keep the package but blacklist it from any of
the shipped spins.)
Mirek

[1] It does matter because there is a risk of security vulnerabilities
being unaddressed - but, hopefully, at least for the frequently used
packages somebody would notice.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Packaging Yorick

[Stephen John Smoogen]

On 21 November 2011 14:43, Jonathan Underwood
 wrote:
> Hi,
>
> I have just started looking at packaging Yorick[1][2], an interpreted
> programming language for scientific simulations. It seems that this is
> BSD licensed and so would be suitable for packaging in Fedora.
>
> However, by default and design it has a really horrible filesystem
> layout[3], with files under the following directory:
>
>
> relocate/  files required for building compiled packages, and:
>  bin/     binary executables
>  lib/     binary libraries for compiled packages
>  include/ header files for compiled package APIs
>  i0/      interpreted code required for yorick to start
>  i/       optional interpreted code libraries
>  i-start/ interpreted code that autoloads at startup
>  g/       graphics style files, palettes, and templates
>  doc/     documentation files
>
> According to the docs[3], it's possible to move the whole "relocate"
> directory elsewhere (eg. to be under /usr), but not to move
> directories underneath the main directory. This of course violates our
> packaging guidelines in many ways.
>
> Before I look into what's required to patch this beast to meet the
> packaging guidelines, I wonder if anyone else has tried packaging it,
> and/or wants to help?

The last time I tried packaging this I am not sure Fedora was around.
It was a bear at that point and it doesn't seem to have gotten any
better. What I remember happening was it ended up being better to use
tar balls and their own methods because it was too painful otherwise.
But I am talking about something I did several job lifetimes ago.

-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Review swap

[Till Maas]

Hi,

I want to offer a review swap for hxtools:
https://bugzilla.redhat.com/show_bug.cgi?id=683610

It is a dependency I need to update and probably fix several bugs in
pam_mount.

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

Re: Fedora clean up process seems to be seriously broken...

[Michael Schwendt]

On Mon, 21 Nov 2011 22:58:50 +0100, RH (Reindl) wrote:

> +1
> 
> nothing is more frustrating for users as ignored bugreports reintroduced from
> release to relase while th eonly response is from bugzapper about EOL of the
> release

Well, that's not the same problem as this thread is about.

There a very active packagers (and developers who also do packaging tasks)
who don't respond to [all] tickets due to various reasons. Some of the
reasons are valid. Become a package maintainer yourself, Harald, before
you judge about them all.


I understand this thread as a comment on improving the detection of
inactive maintainers and unmaintained packages.

Existing procedures only cover the case when an inactive (or "non-responsive
maintainer") has been detected already:
http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

Nothing is in place to detect inactive maintainers automatically. FTBFS
can help with detecting unmaintained packages, but sometimes this leads to
discovering that the packager has stopped using Fedora package git many
months ago already, for example.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora clean up process seems to be seriously broken...

[Till Maas]

On Mon, Nov 21, 2011 at 02:03:43PM -0800, Jesse Keating wrote:

> This has come up nearly every release cycle.  Problem is that nobody
> can seem to agree on what an appropriate "sign of life" would be, no
> has made a serious FESCo proposal for a contrived sign of life.

I remember that there has been a script that checked the health status
of packages in Fedora by examining when the last build happened and
maybe other facts. What happened to it?

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

Re: Fedora clean up process seems to be seriously broken...

[Bruno Wolff III]

On Mon, Nov 21, 2011 at 22:22:56 +,
  "\"Jóhann B. Guðmundsson\""  wrote:
> 
> Well comes logically to me that at least the maintainer would be 
> stripped of those packages he is ignoring.

That doesn't help. It is reasonable to orphan a package that isn't being
adequately maintained, but removing the ability for someone to help
maintain it doesn't make sense. It isn't like people are being paid based
on how many packages they maintain, so that preventing them from helping
is a punishment.

What would really help is getting more people maintaining packages.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora clean up process seems to be seriously broken...

[Kevin Fenzi]

On Mon, 21 Nov 2011 14:03:43 -0800
Jesse Keating  wrote:

> This has come up nearly every release cycle.  Problem is that nobody
> can seem to agree on what an appropriate "sign of life" would be, no
> has made a serious FESCo proposal for a contrived sign of life.
> 
> I don't think anybody disagrees (well maybe KKoffler) that
> unmaintained software should be discovered and ejected from the
> distro, the entirety of the problem lies how to discover (as well as
> side issues about what to do about maintainers that are active for
> one package, but completely ignore 3 others, etc…)
> 
> So if you are serious about wanting this fixed, draft a proposal,
> figure out who's going to do the coding work, and bring it to FESCo.

To quote Ajax: +!

I think the current policy is not very ideal either, but haven't had
time/energy to work out a new one. ;) 

My last thought was to come up with a automated/script way to gather
info from: bugzilla, pkgdb, koji, git, mailing lists, etc and output a
list of 'likely inactive people'. Then, have a group of humans look at
the list, and try and contact/ping people. With no reply after a
timeperiod, orphan their packages. 

Note that we need to balance here cases like: 

* maintainer is very active, just ignoring $leafpackage right now. 
* maintainer is on vacation/sick/etc
* maintainer needs help, we should try and help them out. 
* maintainer doesn't use our bugzilla as their primary bug zone. 
* maintainer maintains a software that has a vast number of bugs and
  they can't deal with them all. 
* maintainer is working on higher priority bug, so ignoring feature
  requests/etc. 

Anyhow, I for one would welcome written up, concrete proposals here. 

kevin




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

Re: Fedora clean up process seems to be seriously broken...

[Jesse Keating]

On Nov 21, 2011, at 2:22 PM, Jóhann B. Guðmundsson wrote:
> 
>> So if you are serious about wanting this fixed, draft a proposal, figure out 
>> who's going to do the coding work, and bring it to FESCo.
> 
> I would think this work directly falls under releng jurisdiction ( given 
> that releng is ultimately responsible for the bits being shipped to end 
> users and at the same time are the once most familiar with the inner 
> packaging process ) in accordance with what FPC or FESCO decide.


Unless you get the volunteer release engineers on board with doing the work, 
this is a non-starter.

- jlk

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

Re: Fedora clean up process seems to be seriously broken...

[Jesse Keating]

On Nov 21, 2011, at 2:29 PM, Jóhann B. Guðmundsson wrote:
> 
> So who's ultimately responsible for making sure that packagers are 
> following the current guidelines set by FPC releng?

"the community".  You see, the problem with a volunteer community is that 
"enforcement" basically boils down to A) take away your commit access, and/or 
B) $somebody corrects the violation.

- jlk

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

Re: Fedora clean up process seems to be seriously broken...

[Jóhann B. Guðmundsson]

On 11/21/2011 10:24 PM, Jason L Tibbitts III wrote:
>> "JBG" == Jóhann B Guðmundsson  writes:
> JBG>  How does FPC handle packagers that violate the packaging
> JBG>  guidelines?
>
> FPC is not tasked with enforcing the packaging guidelines.

So who's ultimately responsible for making sure that packagers are 
following the current guidelines set by FPC releng?

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

Re: Fedora clean up process seems to be seriously broken...

[Jason L Tibbitts III]

> "JBG" == Jóhann B Guðmundsson  writes:

JBG> How does FPC handle packagers that violate the packaging
JBG> guidelines?

FPC is not tasked with enforcing the packaging guidelines.

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

Re: Fedora clean up process seems to be seriously broken...

[Jóhann B. Guðmundsson]

On 11/21/2011 09:58 PM, Reindl Harald wrote:
> +1
>
> nothing is more frustrating for users as ignored bugreports reintroduced from
> release to relase while th eonly response is from bugzapper about EOL of the
> release

That's one symptom of the underlying problem and with my QA hat on I can 
tell you all that I know for a fact that we have lost reporters due to 
that.

I have also come across several bugs which seem to be related to some 
other community process that directly falls under packager 
maintainership which was related to the maintainer having to update the 
%ghost section of the package in question.

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

Re: Fedora clean up process seems to be seriously broken...

[Jóhann B. Guðmundsson]

On 11/21/2011 10:03 PM, Jesse Keating wrote:
> This has come up nearly every release cycle.  Problem is that nobody can seem 
> to agree on what an appropriate "sign of life" would be, no has made a 
> serious FESCo proposal for a contrived sign of life.
>
> I don't think anybody disagrees (well maybe KKoffler) that unmaintained 
> software should be discovered and ejected from the distro, the entirety of 
> the problem lies how to discover (as well as side issues about what to do 
> about maintainers that are active for one package, but completely ignore 3 
> others, etc…)

Well comes logically to me that at least the maintainer would be 
stripped of those packages he is ignoring.

>
> So if you are serious about wanting this fixed, draft a proposal, figure out 
> who's going to do the coding work, and bring it to FESCo.

I would think this work directly falls under releng jurisdiction ( given 
that releng is ultimately responsible for the bits being shipped to end 
users and at the same time are the once most familiar with the inner 
packaging process ) in accordance with what FPC or FESCO decide.

How does FPC handle packagers that violate the packaging guidelines?

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

Re: Packaging Yorick

[Tom Callaway]

On 11/21/2011 04:43 PM, Jonathan Underwood wrote:
> Before I look into what's required to patch this beast to meet the
> packaging guidelines, I wonder if anyone else has tried packaging it,
> and/or wants to help?

I'm always hesitant to package stuff like that, especially because:

A) All the upstream docs will refer to the layout we don't use
B) Patching it to use the different layout is almost always
super-intrusive and painful to maintain forever, especially as upstream
puts out new releases that require the patchset to not only be rediffed,
but redone, as they add new places that use the brain-damaged layout.

It might be worth having a friendly conversation with upstream and ask
them to consider moving to a standard FHS layout, however, in all the
cases I've tried, I've never had success. More often than not, the
layout on some of these projects was inherited from a "time before UNIX"
or a custom academic/scientific mindset, where they "know better" (tm).

~tom

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

Re: Fedora clean up process seems to be seriously broken...

[Jesse Keating]

On Nov 21, 2011, at 1:53 PM, Jóhann B. Guðmundsson wrote:
> On 11/21/2011 09:25 PM, Michael Schwendt wrote:
>> Unconvincing. To "reassure ownership" periodicially won't be sufficient.
>> It would be just another button to click (like FAS password or cert
>> renewal) and would not guarantee that the packages would be maintained
>> properly and that tickets would be dealt with. A "sign of life" from a
>> person does not imply that the person's packages are (well-)maintained.
>> 
> 
> Well if people want more controversial proposal of sign of live that's 
> relatively easier to accomplish.
> 
> Revoke that maintainers package privileges for $next-release if he does 
> not respond to bug reports in timely manner in GA releases and orphan 
> his package.
> 
> Arguable a bit drasting but at the same time far more effective clean up 
> process.
> 
 I cant image how much resources across the project have been spent on
 packages that no longer are being actively maintained but have not been
 removed from the distribution.
>> Might be true. I agree with your concerns, just not with how you'd
>> like to tackle the problem.;)
> 
> I think the "soft" approach will still be more efficient then current 
> implemented solution.
> 
> The "hard" approach would certainly be the most efficient one and at the 
> same time teach packager/maintainers a thing or two against their 
> responsibility towards the community and least but not least towards our 
> end user base and arguably it might be doing the relevant maintainers a 
> favour as in they have not realised or have not come in terms with the 
> fact that they no longer have the time to maintain their package(s) and 
> that approach would serve as a bit of a wakeup call but as I mention 
> some people might find that a bit of an harsh approach to the problem.
> 
> I'm all ears for any solutions to the task at hand that you might have 
> up your sleeve.
> 
> JBG


This has come up nearly every release cycle.  Problem is that nobody can seem 
to agree on what an appropriate "sign of life" would be, no has made a serious 
FESCo proposal for a contrived sign of life.

I don't think anybody disagrees (well maybe KKoffler) that unmaintained 
software should be discovered and ejected from the distro, the entirety of the 
problem lies how to discover (as well as side issues about what to do about 
maintainers that are active for one package, but completely ignore 3 others, 
etc…)

So if you are serious about wanting this fixed, draft a proposal, figure out 
who's going to do the coding work, and bring it to FESCo.

- jlk


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

Re: Fedora clean up process seems to be seriously broken...

[Reindl Harald]

Am 21.11.2011 22:53, schrieb "Jóhann B. Guðmundsson":
> On 11/21/2011 09:25 PM, Michael Schwendt wrote:
>> Unconvincing. To "reassure ownership" periodicially won't be sufficient.
>> It would be just another button to click (like FAS password or cert
>> renewal) and would not guarantee that the packages would be maintained
>> properly and that tickets would be dealt with. A "sign of life" from a
>> person does not imply that the person's packages are (well-)maintained.
>>
> 
> Well if people want more controversial proposal of sign of live that's 
> relatively easier to accomplish.
> 
> Revoke that maintainers package privileges for $next-release if he does 
> not respond to bug reports in timely manner in GA releases and orphan 
> his package.
> 
> Arguable a bit drasting but at the same time far more effective clean up 
> process.

+1

nothing is more frustrating for users as ignored bugreports reintroduced from
release to relase while th eonly response is from bugzapper about EOL of the
release



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

Re: Fedora clean up process seems to be seriously broken...

[Jóhann B. Guðmundsson]

On 11/21/2011 09:25 PM, Michael Schwendt wrote:
> Unconvincing. To "reassure ownership" periodicially won't be sufficient.
> It would be just another button to click (like FAS password or cert
> renewal) and would not guarantee that the packages would be maintained
> properly and that tickets would be dealt with. A "sign of life" from a
> person does not imply that the person's packages are (well-)maintained.
>

Well if people want more controversial proposal of sign of live that's 
relatively easier to accomplish.

Revoke that maintainers package privileges for $next-release if he does 
not respond to bug reports in timely manner in GA releases and orphan 
his package.

Arguable a bit drasting but at the same time far more effective clean up 
process.

>> >  I cant image how much resources across the project have been spent on
>> >  packages that no longer are being actively maintained but have not been
>> >  removed from the distribution.
> Might be true. I agree with your concerns, just not with how you'd
> like to tackle the problem.;)

I think the "soft" approach will still be more efficient then current 
implemented solution.

The "hard" approach would certainly be the most efficient one and at the 
same time teach packager/maintainers a thing or two against their 
responsibility towards the community and least but not least towards our 
end user base and arguably it might be doing the relevant maintainers a 
favour as in they have not realised or have not come in terms with the 
fact that they no longer have the time to maintain their package(s) and 
that approach would serve as a bit of a wakeup call but as I mention 
some people might find that a bit of an harsh approach to the problem.

I'm all ears for any solutions to the task at hand that you might have 
up your sleeve.

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

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

[Michael Schwendt]

On Mon, 21 Nov 2011 16:26:02 -0500, TL (Tom) wrote:

> > With
> 
> >   pkgconfig(libpng) = 1.2.46
> >   pkgconfig(libpng12) = 1.2.46
> 
> > once libpng12.pc gets removed from the distribution, the dep-chains
> > break, of course.
> 
> > As a temporary work-around, you could have provided that thing manually
> > in the libpng-devel upgrade instead of including the actual libpng12.pc
> > file:
> 
> >   Provides: pkgconfig(libpng12) = %{version}-%{release}
> 
> > Any configure script or .pc file using a hardcoded "libpng12" name
> > would fail to build, but that would be better IMO than offering an
> > incomplete broken compat package that confuses the buildroots.
> 
> Well, I don't have any objection to doing it that way, but exactly what
> about this "confuses the buildroots"?

In the buildroot, pkg-config queries on 'libpng12' succeed and let the
build job continue when in fact it should terminate early ... because
even if the source were compatible with the new headers, -lpng12 would
fail due to missing files.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Packaging Yorick

[Jonathan Underwood]

Hi,

I have just started looking at packaging Yorick[1][2], an interpreted
programming language for scientific simulations. It seems that this is
BSD licensed and so would be suitable for packaging in Fedora.

However, by default and design it has a really horrible filesystem
layout[3], with files under the following directory:


relocate/  files required for building compiled packages, and:
  bin/ binary executables
  lib/ binary libraries for compiled packages
  include/ header files for compiled package APIs
  i0/  interpreted code required for yorick to start
  i/   optional interpreted code libraries
  i-start/ interpreted code that autoloads at startup
  g/   graphics style files, palettes, and templates
  doc/ documentation files

According to the docs[3], it's possible to move the whole "relocate"
directory elsewhere (eg. to be under /usr), but not to move
directories underneath the main directory. This of course violates our
packaging guidelines in many ways.

Before I look into what's required to patch this beast to meet the
packaging guidelines, I wonder if anyone else has tried packaging it,
and/or wants to help?

Cheers,
Jonathan

[1] http://dhmunro.github.com/yorick-doc/
[2] http://sourceforge.net/projects/yorick/
[3] https://github.com/dhmunro/yorick/blob/master/README.md
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Systemd unit file alias question

[Richard Shaw]

I'm working on improving how akmods are built and had an idea[1] I
need input/confirmation on.

Instead of the akmods packaging assuming when it needs to run, why
can't each akmod driver package provide it's own unit file?

Since the service would run as type "oneshot", am I correct in
assuming that no matter how many times it's started, it will only
start for real on the first (earliest) occurrence?

My idea is that each akmod driver package would provide a service file
with the same name as the package but include an alias to
"akmods.service".

What's the consequences of multiple unit files claiming the same
alias? Is this safe?

Thanks,
Richard

[1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=1712#c16
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora clean up process seems to be seriously broken...

[Michael Schwendt]

On Mon, 21 Nov 2011 20:56:02 +, JBG (Jóhann) wrote:

> Instead of everybody that are doing needed work in the distribution 
> having to run around after maintainers trying to find out if they are 
> still active or not and initiate the unresponsive maintainer policy, 
> cant we revert the process and have maintainer(s) having to reassure 
> their ownership on their package(s) at the begin of each development 
> cycle and if they dont do that before x time, the package(s) they 
> maintain will be automatically orphaned and given up for someone else to 
> grab and take ownership before x time runs out and if nobody does they 
> get remove from the distribution?

Unconvincing. To "reassure ownership" periodicially won't be sufficient.
It would be just another button to click (like FAS password or cert
renewal) and would not guarantee that the packages would be maintained
properly and that tickets would be dealt with. A "sign of life" from a
person does not imply that the person's packages are (well-)maintained.

> I cant image how much resources across the project have been spent on 
> packages that no longer are being actively maintained but have not been 
> removed from the distribution.

Might be true. I agree with your concerns, just not with how you'd
like to tackle the problem. ;)

-- 
Fedora release 16 (Verne) - Linux 3.1.1-1.fc16.x86_64
loadavg: 0.07 0.14 0.13
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

[Tom Lane]

Michael Schwendt  writes:
> With

>   pkgconfig(libpng) = 1.2.46
>   pkgconfig(libpng12) = 1.2.46

> once libpng12.pc gets removed from the distribution, the dep-chains
> break, of course.

> As a temporary work-around, you could have provided that thing manually
> in the libpng-devel upgrade instead of including the actual libpng12.pc
> file:

>   Provides: pkgconfig(libpng12) = %{version}-%{release}

> Any configure script or .pc file using a hardcoded "libpng12" name
> would fail to build, but that would be better IMO than offering an
> incomplete broken compat package that confuses the buildroots.

Well, I don't have any objection to doing it that way, but exactly what
about this "confuses the buildroots"?

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

[Bug 755720] New: /etc/rc.d/init.d/mldonkey BY DEFAULT FOR A PID FILE CALLS /var/run/mldonkey/ THAT DOES NOT EXIST...

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: /etc/rc.d/init.d/mldonkey BY DEFAULT FOR A PID FILE CALLS 
/var/run/mldonkey/  THAT DOES NOT EXIST...

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

   Summary: /etc/rc.d/init.d/mldonkey BY DEFAULT FOR A PID FILE
CALLS /var/run/mldonkey/  THAT DOES NOT EXIST...
   Product: Fedora
   Version: 16
  Platform: Unspecified
OS/Version: Unspecified
Status: NEW
  Severity: unspecified
  Priority: unspecified
 Component: mldonkey
AssignedTo: lemen...@gmail.com
ReportedBy: pawel.elj...@jatymy.org
 QAContact: extras...@fedoraproject.org
CC: rjo...@redhat.com, lemen...@gmail.com,
fedora-ocaml-l...@redhat.com
Classification: Fedora
  Story Points: ---
  Type: ---


Description of problem:

unless pid-dir manually created start by /etc/rc.d/init.d/mldonkey start -
FAILS

script mldonkey-server.rpm to create above pid-directory at rpm-installation
time

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
ocaml-devel mailing list
ocaml-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel

Re: Changing kernel API / Breaking VirtualBox - update criteria violation?

[Michael Cronenworth]

Till Maas wrote:
> a recent kernel update[0] broke Fedora's ability to be a VirtualBox
> host, because asm/amd_iommu.h was removed. The removal of the file was
> noticed during testing, but it seems nobody noticed that this affects
> VirtualBox. Is this kind of change sanctioned by the
> current update criteria?

Till,

The amd_iommu.h header was moved from asm/ to linux/ in kernel 3.1. The 
VirtualBox source has a define for version < 3.1 use asm/, else use 
linux/. This problem won't be seen by F16 users. It's a small 
side-effect in F15 as it is still using 2.6.x kernel versioning.

As to the update criteria, it would be allowed. VirtualBox is not a 
Fedora package. AFAIK the only thing stopping VBox from being a Fedora 
package is its required kernel module and Fedora's policy against 
out-of-kernel modules.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora clean up process seems to be seriously broken...

[Jóhann B. Guðmundsson]

Given that I'm migrating bunch of legacy init script to native systemd 
ones and I have come many packages that seem that maintainer(s) have 
deserted them but for some bizarre reason we still continue to package 
and keep rolling them between release and now I came across bug 738442 
which seriously begs the question that the whole cleanup process needs 
to be revisited.

Instead of everybody that are doing needed work in the distribution 
having to run around after maintainers trying to find out if they are 
still active or not and initiate the unresponsive maintainer policy, 
cant we revert the process and have maintainer(s) having to reassure 
their ownership on their package(s) at the begin of each development 
cycle and if they dont do that before x time, the package(s) they 
maintain will be automatically orphaned and given up for someone else to 
grab and take ownership before x time runs out and if nobody does they 
get remove from the distribution?

I cant image how much resources across the project have been spent on 
packages that no longer are being actively maintained but have not been 
removed from the distribution.

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

Re: Changing kernel API / Breaking VirtualBox - update criteria violation?

[Reindl Harald]

Am 21.11.2011 21:32, schrieb Till Maas:
> Hi,
> 
> a recent kernel update[0] broke Fedora's ability to be a VirtualBox
> host, because asm/amd_iommu.h was removed. The removal of the file was
> noticed during testing, but it seems nobody noticed that this affects
> VirtualBox. Is this kind of change sanctioned by the
> current update criteria?

virtualbox is not part of fedora
and vmware is running great after some changes of version.checks
but vmware is also not part of fedora

better breaking some non-distribution-stuff than as happened with
F14 that current intel machiens with sandy-bridge was not supportted
and forced eople with new hardware way too early to F15/systemd



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

Re: Changing kernel API / Breaking VirtualBox - update criteria violation?

[Haïkel Guémar]

Le 21/11/2011 21:32, Till Maas a écrit :
> Hi,
>
> a recent kernel update[0] broke Fedora's ability to be a VirtualBox
> host, because asm/amd_iommu.h was removed. The removal of the file was
> noticed during testing, but it seems nobody noticed that this affects
> VirtualBox. Is this kind of change sanctioned by the
> current update criteria?
>
> Kind regards
> Till
>
> [0] 
> https://admin.fedoraproject.org/updates/FEDORA-2011-15856/kernel-2.6.41.1-1.fc15

This has been fixed upstream but F15 kernel is a specific case since it 
doesn't follow upstream versionning. If we were shipping VirtualBox, 
this would be quite trivial to fix but we don't (maybe upstream or third 
party packagers may fix their F15 packages accordingly)
http://repo.or.cz/w/virtualbox.git/commit/7456c49fab948cdf02fec626fe87c4e764d75901

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

Re: Request update of shared-mime-info

[Matthias Runge]

On 21/11/11 20:36, Jon Masters wrote:
> Can someone please push the update that I made (with permission) to
> shared-mime-info? I'm getting "jcm does not have commit access" when I
> try to make the F16 update. This fix is required to actually be able to
> play many MP3 files (including all purchased from Amazon.com) on F16.
> 
> Tested Koji builds:
> 
> F16: http://koji.fedoraproject.org/koji/taskinfo?taskID=3530557
> F17: http://koji.fedoraproject.org/koji/taskinfo?taskID=3530543
Hi,

hopefully not disturbing someones circles; I just tried to push it a few
minutes ago.
https://admin.fedoraproject.org/updates/shared-mime-info
(it looks like proven-testers are able to submit any package to testing).
Is this correct?

Matthias

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

Changing kernel API / Breaking VirtualBox - update criteria violation?

[Till Maas]

Hi,

a recent kernel update[0] broke Fedora's ability to be a VirtualBox
host, because asm/amd_iommu.h was removed. The removal of the file was
noticed during testing, but it seems nobody noticed that this affects
VirtualBox. Is this kind of change sanctioned by the
current update criteria?

Kind regards
Till

[0] 
https://admin.fedoraproject.org/updates/FEDORA-2011-15856/kernel-2.6.41.1-1.fc15
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Minutes from today's town hall meeting for FESCo election candidates

[Robyn Bergeron]

Minutes and logs from today's town hall for the FESCo candidates can be 
seen here:

Minutes: 
http://meetbot.fedoraproject.org/fedora-townhall/2011-11-21/fedora_townhall.2011-11-21-18.01.html
Log: 
http://meetbot.fedoraproject.org/fedora-townhall/2011-11-21/fedora_townhall.2011-11-21-18.01.log.html

Cheers,

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

Re: Reminder of FESCo town hall meeting today

[Jared K. Smith]

On Mon, Nov 21, 2011 at 2:21 PM, Bill Nottingham  wrote:
> In the future, can we ensure that the FESCo town hall doesn't directly
> conflict with a FESCo meeting? (Alternatively, we could take the FESCo
> meeting slot for the week.)

Sure... I didn't realize the conflict until I saw the FESCo meeting
announcement earlier today, and the Town Hall reminders had already
been sent.  In the future, I'll pay closer attention to this.

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

Request update of shared-mime-info

[Jon Masters]

Folks,

Can someone please push the update that I made (with permission) to
shared-mime-info? I'm getting "jcm does not have commit access" when I
try to make the F16 update. This fix is required to actually be able to
play many MP3 files (including all purchased from Amazon.com) on F16.

Tested Koji builds:

F16: http://koji.fedoraproject.org/koji/taskinfo?taskID=3530557
F17: http://koji.fedoraproject.org/koji/taskinfo?taskID=3530543

Jon.


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

Re: Reminder of FESCo town hall meeting today

[Bill Nottingham]

Jared K. Smith (jsm...@fedoraproject.org) said: 
> I want to remind everyone of the upcoming FESCo town hall meeting today,
> Monday November 21st at 18:00 UTC.  For more details, see
> https://fedoraproject.org/wiki/Elections#IRC_Town_Halls.

In the future, can we ensure that the FESCo town hall doesn't directly
conflict with a FESCo meeting? (Alternatively, we could take the FESCo
meeting slot for the week.)

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

Re: Rethinking proventester and critpath

[Bruno Wolff III]

On Mon, Nov 21, 2011 at 10:32:06 -0800,
  Adam Williamson  wrote:
> That's about all the concrete thoughts / suggestions I can filter out of
> the log.

I don't remember which meeting I noted it at, but another idea is to
weight proventester feedback higher (maybe count as +2 or -2) in the
short term (until we have something more than a running count).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

fedorahosted.org: Call for RHEL6 testing

[Kevin Fenzi]

Greetings. 

As we recently announced, we are working on migrating fedorahosted.org
over to a newer instance or instances. We announced and held a activity
day:
http://lists.fedoraproject.org/pipermail/devel-announce/2011-November/000857.html

Which resulted in the following plans: 
http://lists.fedoraproject.org/pipermail/infrastructure/2011-November/011140.html

Per those plans, we have setup a RHEL6 test instance of
fedorahosted.org and would like to ask people to test against it for
issues or problems. 

How to test: 

edit your local /etc/hosts file and add: 

66.135.62.191   fedorahosted.org git.fedorahosted.org svn.fedorahosted.org 
hg.fedorahosted.org

Then your requests will go against the new instance. 
Simply use trac, your scm and anything else as normal and note any
issues or problems. If you have any non standard trac plugins, please do
test them. 

Email is disabled on this instance: Lists will not work and any changes you 
make that would normally generate an email will not do so. 

Also, note that this is a test copy of fedorahosted.org data. From time to time
we will remigrate the data and convert it over, causing any changes you 
made to be LOST. Do remember to change your /etc/hosts entry back 
to commit real changes to your projects. 

If you could collect results and mail them to this list
(infrastructure) that would be best for now. 

Please do remember to remove the /etc/hosts entry when you are going to
go back to the live/production instance. 

Please send feedback to infrastruct...@lists.fedoraproject.org or reply to
me directly.

Thanks in advance for any testing. 

kevin


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

Re: Rethinking proventester and critpath

[Adam Williamson]

On Tue, 2011-11-01 at 13:59 +, Matthew Garrett wrote:
> It's a common complaint that it's too difficult to get updates to 
> critpath packages through the update system at the moment. We've been 
> looking into trying to make that easier without just dropping the 
> critpath requirements, and one thing we looked at was whether the 
> requirement for positive karma from proventesters was a net benefit.
> 
> Thankfully this is the kind of thing that we can actually generate 
> numbers for. Luke pulled some statistics which are available at 
> http://lists.fedoraproject.org/pipermail/test/2011-October/104084.html . 
> The relevant section here is the set of packages that have (a) 
> sufficient positive karma to be pushed, but (b) negative proventester 
> karma - that is, the packages where negative proventester karma 
> prevented a push.
> 
> Straight off, we can see that these amount to 1-2% of all critpath 
> updates. It's simply not common for proventester to make a difference to 
> the outcome. If we look at the individual packages, things get even more 
> interesting. Many of the updates receive a mixture of proventester 
> karma, so even with the negative the push would still go ahead. As far 
> as I can tell:
> 
> https://admin.fedoraproject.org/updates/xorg-x11-drv-geode-2.11.9-1.fc14
> https://admin.fedoraproject.org/updates/system-setup-keyboard-0.8.6-2.fc14
> 
> are the only two updates where the proventester karma requirement would 
> have made a difference, out of 1942 critpath updates that made it to 
> stable. That doesn't seem like a great hit rate.
> 
> So, assuming I'm not grossly misanalysing the data, it seems that we 
> could drop the proventester requirement from critical path updates with 
> a negligable change in the quality of the updates. Thoughts?

So, we discussed this at the QA meeting a couple of weeks back.
Initially the plan was for anyone who had concerns to reply to this
mail, but that doesn't seem to have happened, so I will try to summarize
the various responses from that meeting. You can check the full summary
and log of the meeting:

https://fedoraproject.org/wiki/QA/Meetings/2007

if you want to make sure I'm not misrepresenting anything.

adamw: 1-2% of all critpath updates (where proventester process is seen
to have 'had an impact') is a small number, but it is not 0. It only
takes *one* really bad update to cause big problems.

adamw: it's possible we could use proven tester feedback more
effectively: there have been cases where bad updates went out despite
negative feedback, because we currently don't give negative feedback -
even from proventesters - much significance at all. So there may have
been more cases where proventester input *may have been significant*
with a system where negative karma is more strongly considered. e.g.
updates could be blocked from being auto-pushed if there is any negative
feedback from a proven tester

red_alert (sandro mathys): critpath packages should have detailed test
plans, as currently proventesters often do not know exactly what they
need to verify with some critpath packages: "the process as its done
right now doesn't work (i.e. is no improvement to not having pts) but
having pts with a better process would surely add to the overall
quality"

tflink: we have to keep in mind the reason for the proposal -
maintainers frustrated that packages get stuck in updates-testing for
weeks - is a valid reason and a significant problem. "if we object to
getting rid of the proventester process, do we have any solutions to the
root of their complaints?"

brunowolff: how about keeping the PT karma requirement but adopting the
plan to allow critpath updates to go through without 'required' karma
after a two week wait

adamw: "i assume the stats made the assumption that the proventester
feedback on any update would still have been present but treated it no
different from regular feedback. so, that's not necessarily a safe
assumption: proventesters may feel a stronger 'responsibility to test',
and if you cancel the process, they might stop doing so. but that's hard
to gauge."

red_alert: proposes a meeting during FUDCon NA to try and come up with a
better pt process

That's about all the concrete thoughts / suggestions I can filter out of
the log.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

F16 on refit, does it work?

[Andreas Tunek]

On my iMac using refit I have triplebooted MacOS, Windows 7 and F15.
Yesterday I tried to upgrade (with preupgrade) to F16. In the end of
that updgrade process (when all rpm files have been installed and
cleaned up) process anaconda crashed leaving me with and unbootable
Linux partition. (I could not submit the bug report because there was no
network access during upgrade.)

I tried install F16 using a live cd. I created two partitions, one
MSBoot and on ext 4 / . The install seemed to go fine, but when I tried
to boot into F16 from refit I came to a grub prompt. Also, now I can not
boot into windows any more from refit, or by any other way that I tried.
So I am a bit sad right now.

Anyway, has anyone installed F16 on a Mac running refit? Did you have to
do anything special?

Also, is anyone triple booting with F16 on a mac? In that case, do you
have any pointers?

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

Review swaps

[Jerry James]

Is anyone willing to swap a couple of reviews?  I need reviews for:

cryptominisat: https://bugzilla.redhat.com/show_bug.cgi?id=721174
In spite of the name, there's nothing cryptographic about this
package.  The author thinks it would be a useful tool for
cryptographers, but it is just another SAT solver.  This is a new
dependency for stp, which I would like to upgrade.

polybori: https://bugzilla.redhat.com/show_bug.cgi?id=742388
This is a package rename.  The current package, python-polybori, mixes
the C++ and python interfaces into a single package.  This rename
separates the C++ and python interfaces into separate packages.

Thanks!
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Heads-Up][ABI Change] Boost has been upgraded to 1.48.0 on Rawhide

[Denis Arnaud]

2011/11/21 Bruno Wolff III 

> I talked to some of the active Wesnoth developers and they told me it (the
> BOOST_FOREACH problem affecting Wesnoth) is an upstream bug with a fix
> already.
> Can we get this fix cherry picked for rawhide?
>

Yes, we shall add the patch into the Boost package. I would prefer to wait
a little bit before, just to know whether Boost own "tests explode" or not (
https://svn.boost.org/trac/boost/ticket/6131#comment:2)... I'll prepare the
patch, so that it can be fired up very soon, when the lights will be green.

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

[Test-Announce] FUDCon Blacksburg subsidies announcement, and general planning update.

[Robyn Bergeron]

Greetings everyone,

A few updates on the upcoming FUDCon in Blacksburg, VA in January 2012:

* We will be having our second subsidy meeting on Wednesday, November 
23rd.  This meeting will be for evaluating and processing any available 
subsidy monies for international attendees, as well as processing any 
new North America-based subsidy requests.  If you are requesting a 
subsidy, please ensure that your Trac ticket for requesting subsidies is 
complete, particularly and especially with detail to what you plan to 
accomplish / do while at FUDCon.  With more than ten international 
requests, and limited funding, it is especially important for the people 
attending the meeting to have a clear picture of your plans in order to 
make a decision on funding.

The subsidy meeting is open for anyone to attend.  Please feel free to 
participate, especially if you have requested funding, so that we may 
ask questions and get answers in a timely manner.  The meeting occurs 
this Wednesday (during the normal FUDCon planning meeting time) at 17:00 
UTC in #fedora-meeting on irc.freenode.net (9am Pacific, Noon Eastern).

For more information on applying for a subsidy, please read 
https://fedorahosted.org/fudcon-planning/wiki/FundingRequest

* Pre-registration for FUDCon is open. If you are planning to attend, 
please visit the event wiki page at 
http://fedoraproject.org/wiki/FUDCon:Blacksburg_2012 to add your name to 
the registration list.

* Rooms at the hotel for FUDCon can be booked now.  The block is open 
until December 28, 2011. Details on booking your room can be seen here: 
https://fedoraproject.org/wiki/FUDCon:Blacksburg_2012#Lodging_.2F_Hotel

* As always, your participation is welcomed, and your help is 
appreciated.  Signing up on the fudcon-planning mailing list is a great 
way to find out how you can help, and to get more details about FUDCon 
as the event draws near.  Sign up at  
https://admin.fedoraproject.org/mailman/listinfo/fudcon-planning to get 
on the list.

Thanks, and I hope to see you at FUDCon! :)

-Robyn


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

[Bug 755638] New: Odd number of hash elements passed to XML::RPC->new

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: Odd number of hash elements passed to XML::RPC->new

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

   Summary: Odd number of hash elements passed to XML::RPC->new
   Product: Fedora
   Version: 16
  Platform: Unspecified
OS/Version: Unspecified
Status: NEW
  Severity: unspecified
  Priority: unspecified
 Component: perl-Fedora-Bugzilla
AssignedTo: cw...@alumni.drew.edu
ReportedBy: ppi...@redhat.com
 QAContact: extras...@fedoraproject.org
CC: cw...@alumni.drew.edu,
fedora-perl-devel-l...@redhat.com
Classification: Fedora
  Story Points: ---
  Type: ---


perl-Fedora-Bugzilla-0.13-9.fc16.noarch (and also all older versions).

While connecting to Bugzilla I get following warning: Odd number of elements in 
hash assignment at /usr/share/perl5/RPC/XML/Client.pm line 81,  line 1.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 755638] Odd number of hash elements passed to XML::RPC->new

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

Petr Pisar  changed:

   What|Removed |Added

External Bug ID||CPAN 67217

--- Comment #1 from Petr Pisar  2011-11-21 11:43:03 EST ---
Patch is attached on CPAN RT #67217.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
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

Bodhi 0.8.4 in production

[Luke Macken]

Hi!

A new bugfix release of bodhi has just hit production.

https://admin.fedoraproject.org/updates

Changes
---

- A new URL structure implemented, based on discussions from fedora devel
  list[0]. Testing & stable updates will now have the following URLs:

  /updates//

  Bodhi only cares about the ID of the update, as the builds may be edited
  over time. This new URL scheme is complementary, and all previous URLs
  will continue to work.

- Fixed an issue with email encoding using TurboMail 3.0[1].
  This bug prevented various email notifications from going out
  properly[2]

- Changed the login link so that it can be friendlier if only a missing
  csrf_token is preventing a use from being deemed logged in.

- Allow provenpackagers to submit any buildroot override

- Added some new critical path proventester metrics[3]

- Less update comment spam when we have to resume failed pushes.

- Fixed a bug in the auto-obsoletion code that occurs when a multi-build
  update contains the same number of builds as a previous update for
  that package, but with at least one different package.[4]

- Fixed a CSS bug that prevented the unit tests from being visible in
  some browsers[5]

[0]: https://lists.fedoraproject.org/pipermail/devel/2011-October/158770.html
[1]: https://fedorahosted.org/bodhi/ticket/648
[2]: https://fedorahosted.org/bodhi/ticket/647
[3]: https://fedorahosted.org/fesco/ticket/517#comment:7
[4]: https://fedorahosted.org/bodhi/ticket/617
[5]: https://fedorahosted.org/bodhi/ticket/598
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Heads-Up][ABI Change] Boost has been upgraded to 1.48.0 on Rawhide

[Bruno Wolff III]

I talked to some of the active Wesnoth developers and they told me it (the
BOOST_FOREACH problem affecting Wesnoth) is an upstream bug with a fix already.
Can we get this fix cherry picked for rawhide?

See the upstream ticket:
https://svn.boost.org/trac/boost/ticket/6131
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Reminder of FESCo town hall meeting today

[Jared K. Smith]

I want to remind everyone of the upcoming FESCo town hall meeting today,
Monday November 21st at 18:00 UTC.  For more details, see
https://fedoraproject.org/wiki/Elections#IRC_Town_Halls.

If you have questions you'd like to ask the candidates but can't
attend the meeting, please email them to me directly with "Town Hall"
in the subject, and I will try to ask your questions during the town
hall meeting.

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

Re: syslinux package spec file

[David Cantrell]

On 11/17/2011 04:10 PM, Michael Schwendt wrote:
> Main package "syslinux" does:
>
>Obsoletes: syslinux-devel<  %{version}-%{release}
>Provides: syslinux-devel
>
> However, a syslinux-devel subpackage definition is present. A -devel
> package is built. No comment explains above Obs/Prov pair.
>
> %changelog only says:
>
> * Thu Dec 17 2009 Peter Jones … - 3.83-2
> - Split out -devel
>
> * Tue Aug 22 2006 Jesse Keating … - 3.11-4
> - Obsolete syslinux-devel.
> - Couple cleanups for packaging guidelines
>
> * Mon Jun 12 2006 Peter Jones … - 3.11-2
> - Fold -devel subpackage into "syslinux"
>
>
> # repoquery --archlist=src --whatrequires syslinux --disablerepo='*' 
> --enablerepo=fedora-source
> gpxe-0:1.0.1-4.fc16.src
> ltsp-0:5.1.95-3.fc16.src
>
> # repoquery --archlist=src --whatrequires syslinux-devel --disablerepo='*' 
> --enablerepo=fedora-source
> #
>

That is unusual.  Please file a bug for this.

Thanks,

-- 
David Cantrell 
Supervisor, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: review swap: chromaprint - Library implementing the AcoustID fingerprinting

[Ismael Olea]

On Mon, Nov 21, 2011 at 2:28 PM, Nikos Roussos  wrote:


> Here is mine for review:
> https://bugzilla.redhat.com/show_bug.cgi?id=754698
>

deal!

-- 

Ismael Olea

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

Re: (re)introducing - fedora-review - tool to help with package reviews

[Stanislav Ochotnicky]

Excerpts from "Jóhann B. Guðmundsson"'s message of Mon Nov 21 14:25:22 +0100 
2011:
> > [1] https://fedorahosted.org/FedoraReview
> > [2] https://fedorahosted.org/FedoraReview/browser/api/README
>
> Is this not something that releng/autoqa could use as well as in run
> against all already existing specs and automatically file bugs if they
> aren't ( and to keep things ) up to guidelines?

I wouldn't be against it, but I can imagine all the shouting on the
bugzilla and mailing lists this would cause(i.e. "But my package is
working!!").

Plus output of our tool is more verbose than rpmlint (thought it does
more as well). There will always be tests that cannot be automated for
one reason or the other. In cases like that we have ways to add
helpful information to the template (for example output of
"licensecheck" run on all files in tarball could be added to licensing
part). This helpful output would be considered noise for a lot of
packagers I guess.

And there will always be false positives. I would hope none of
our checks will have false negative (i.e. check will report "A-OK",
but the guidelines would be broken).

All that said: If our QA/releng guys find some part of fedora-review
needs some tweaks to be usable for tasks they have to do: file issues
in our trac and we'll do our best.

--
Stanislav Ochotnicky 
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com


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

Agenda for today's FESCo meeting (21st November, 2011)

[Matthew Garrett]

Note: The FESCo election townhall occurs simultaneously with today's 
meeting.

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

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

= Followups =

#topic #667 Request to fix CRITPATH update process
.fesco 667

#topic #692 Adjust FESCo election policy
.fesco 692

= New business =

#topic #699 Proposal to remove the package "tzdata" from Critical Path
.fesco 699

= Fedora Engineering Services tickets =

https://fedorahosted.org/fedora-engineering-services/report/6

= Open Floor =

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

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


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

Re: (re)introducing - fedora-review - tool to help with package reviews

[Pierre-Yves Chibon]

On Mon, 2011-11-21 at 13:25 +, "Jóhann B. Guðmundsson" wrote:
> On 11/21/2011 01:14 PM, Stanislav Ochotnicky wrote:
> > Hello fellow devs,
> >
> > I am sure quite a few of you have done some reviews and thought "Hey,
> > a,b,c and d could be automated. For E I could use some more
> > information that can be automatically gathered". Some of you even
> > wrote your own tools to do some of these things.
> >
> > Yet there is no unified tool, nor format for package reviews. There
> > are more reasons, but I guess biggest one is there are just too many
> > guidelines and there is probably no one who knows all of them. So few
> > of us got together and hopefully created something that can be used by
> > everyone.
> >
> > fedora-review[1] is now in updates-testing. It provides several checks:
> >   66 generic tests (licensing, md5sum sources, bundling, etc.)
> >   9  c/c++ specific checks (static libs, ldconfig, headers, rpath etc.)
> >   13 java specific checks (javadoc, depmaps, jpackage-utils reqs)
> >   8  R specific checks
> >
> > There are still many more checks waiting to be written. I'd like to
> > see Perl, Python and Ruby checks, though I am not *that* familiar with
> > their guidelines. I think the important thing here is that checks can
> > be written in basically any language. We have simple JSON api[2] using
> > stdin/stdout for communication. There is an example external plugin in
> > documentation in perl and shell (though that's just mock-check).
> >
> > Our goal is for each language SIG (or other specific package group) to
> > maintain their own checks together with their guidelines.
> >
> > * How you can help *
> >- Tell us what checks are missing
> >- Tell us if you think checks are doing it wrong
> >- Create new checks (in language of your choice - we have JSON api)
> >- do this even if the test cannot be automated. At least it will
> >  appear on the checklist for your packages!
> >- Any ideas, bugreports etc will be much appreciated
> >
> >
> > [1] https://fedorahosted.org/FedoraReview
> > [2] https://fedorahosted.org/FedoraReview/browser/api/README
> 
> Is this not something that releng/autoqa could use as well as in run 
> against all already existing specs and automatically file bugs if they 
> aren't ( and to keep things ) up to guidelines?

As more and more extended tests become available one could think of
this. However there are a number of cases where packages go against
guideline (especially the rpmlint output must be clean)* for valid
reasons.
So running blindly the tool without a human look to the output to fill
bug reports might not be such a good idea.

Pierre


* Ok, here we could use the integration between fedpkg lint and
the .rpmlint file in the repo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: review swap: chromaprint - Library implementing the AcoustID fingerprinting

[Nikos Roussos]

On Mon, Nov 21, 2011 at 3:25 PM, Ismael Olea  wrote:

>
> Looking for a swap reviewer
>
> I think it's a non complex review
>
> https://bugzilla.redhat.com/show_bug.cgi?id=755066
> Spec URL: http://olea.org/tmp/chromaprint-rpms/chromaprint.spec
> SRPM URL:
> http://olea.org/tmp/chromaprint-rpms/chromaprint-0.5-2.fc15.src.rpm
>
>
I can do it.

Here is mine for review:
https://bugzilla.redhat.com/show_bug.cgi?id=754698



-- 
Nikos Roussos
about  | linkedin
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

review swap: chromaprint - Library implementing the AcoustID fingerprinting

[Ismael Olea]

Looking for a swap reviewer

I think it's a non complex review

https://bugzilla.redhat.com/show_bug.cgi?id=755066
Spec URL: http://olea.org/tmp/chromaprint-rpms/chromaprint.spec
SRPM URL:
http://olea.org/tmp/chromaprint-rpms/chromaprint-0.5-2.fc15.src.rpm

A deeply related review is pending in RPM Fusion if interested too:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=2036

-- 

Ismael Olea

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

Re: (re)introducing - fedora-review - tool to help with package reviews

[Jóhann B. Guðmundsson]

On 11/21/2011 01:14 PM, Stanislav Ochotnicky wrote:
> Hello fellow devs,
>
> I am sure quite a few of you have done some reviews and thought "Hey,
> a,b,c and d could be automated. For E I could use some more
> information that can be automatically gathered". Some of you even
> wrote your own tools to do some of these things.
>
> Yet there is no unified tool, nor format for package reviews. There
> are more reasons, but I guess biggest one is there are just too many
> guidelines and there is probably no one who knows all of them. So few
> of us got together and hopefully created something that can be used by
> everyone.
>
> fedora-review[1] is now in updates-testing. It provides several checks:
>   66 generic tests (licensing, md5sum sources, bundling, etc.)
>   9  c/c++ specific checks (static libs, ldconfig, headers, rpath etc.)
>   13 java specific checks (javadoc, depmaps, jpackage-utils reqs)
>   8  R specific checks
>
> There are still many more checks waiting to be written. I'd like to
> see Perl, Python and Ruby checks, though I am not *that* familiar with
> their guidelines. I think the important thing here is that checks can
> be written in basically any language. We have simple JSON api[2] using
> stdin/stdout for communication. There is an example external plugin in
> documentation in perl and shell (though that's just mock-check).
>
> Our goal is for each language SIG (or other specific package group) to
> maintain their own checks together with their guidelines.
>
> * How you can help *
>- Tell us what checks are missing
>- Tell us if you think checks are doing it wrong
>- Create new checks (in language of your choice - we have JSON api)
>- do this even if the test cannot be automated. At least it will
>  appear on the checklist for your packages!
>- Any ideas, bugreports etc will be much appreciated
>
>
> [1] https://fedorahosted.org/FedoraReview
> [2] https://fedorahosted.org/FedoraReview/browser/api/README

Is this not something that releng/autoqa could use as well as in run 
against all already existing specs and automatically file bugs if they 
aren't ( and to keep things ) up to guidelines?

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

(re)introducing - fedora-review - tool to help with package reviews

[Stanislav Ochotnicky]

Hello fellow devs,

I am sure quite a few of you have done some reviews and thought "Hey,
a,b,c and d could be automated. For E I could use some more
information that can be automatically gathered". Some of you even
wrote your own tools to do some of these things.

Yet there is no unified tool, nor format for package reviews. There
are more reasons, but I guess biggest one is there are just too many
guidelines and there is probably no one who knows all of them. So few
of us got together and hopefully created something that can be used by
everyone.

fedora-review[1] is now in updates-testing. It provides several checks:
 66 generic tests (licensing, md5sum sources, bundling, etc.)
 9  c/c++ specific checks (static libs, ldconfig, headers, rpath etc.)
 13 java specific checks (javadoc, depmaps, jpackage-utils reqs)
 8  R specific checks

There are still many more checks waiting to be written. I'd like to
see Perl, Python and Ruby checks, though I am not *that* familiar with
their guidelines. I think the important thing here is that checks can
be written in basically any language. We have simple JSON api[2] using
stdin/stdout for communication. There is an example external plugin in
documentation in perl and shell (though that's just mock-check).

Our goal is for each language SIG (or other specific package group) to
maintain their own checks together with their guidelines.

* How you can help *
  - Tell us what checks are missing
  - Tell us if you think checks are doing it wrong
  - Create new checks (in language of your choice - we have JSON api)
  - do this even if the test cannot be automated. At least it will
appear on the checklist for your packages!
  - Any ideas, bugreports etc will be much appreciated


[1] https://fedorahosted.org/FedoraReview
[2] https://fedorahosted.org/FedoraReview/browser/api/README

--
Stanislav Ochotnicky 
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com


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

Re: libcdio update coming to rawhide

[Kevin Kofler]

Adrian Reber wrote:
> gvfs
> http://koji.fedoraproject.org/koji/getfile?taskID=3527348&name=build.log
> File not found:
> /builddir/build/BUILDROOT/gvfs-1.11.0-4.fc17.x86_64/usr/libexec/gvfsd-smb
> File not found:
> /builddir/build/BUILDROOT/gvfs-1.11.0-4.fc17.x86_64/usr/libexec/gvfsd-smb-browse
> File not found:
> /builddir/build/BUILDROOT/gvfs-1.11.0-4.fc17.x86_64/usr/share/gvfs/mounts/smb-browse.mount
> File not found:
> /builddir/build/BUILDROOT/gvfs-1.11.0-4.fc17.x86_64/usr/share/gvfs/mounts/smb.mount

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

> pragha   http://koji.fedoraproject.org/koji/taskinfo?taskID=3527953
> current-playlist.c:2772:2: error: 'g_strncasecmp' is deprecated (declared
> at /usr/include/glib-2.0/glib/gstrfuncs.h:182)
> [-Werror=deprecated-declarations]

GLib now warns about deprecated functions, and this package uses -Werror. I
can only suggest to stop using -Werror. Or at least using
-Wno-error=deprecated-declarations.

Kevin Kofler

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

Re: Review Swaps

[Hedayat Vatankhah]

On ۱۱/۱۱/۲۱  03:06, Jiri Popelka wrote:

> I've taken them.
>
> Here is mine (SpliX - Driver for QPDL/SPL2 printers)
> https://bugzilla.redhat.com/show_bug.cgi?id=755069
>
> Thanks,
>
> Jiri

Thanks, I took yours.

Hedayat


>
> On 11/21/2011 11:15 AM, Hedayat Vatankhah wrote:
>>
>> Hi all,
>>
>> I'd like to swap these reviews with some other (not-so-complicated) ones:
>>
>> Saaghar[1]- A Cross-Platform Persian Poetry Software
>>
>> This is a Qt based application, and should not be complicated.
>>
>> jcal[2] - Unix cal-like interface to libjalali
>>
>> A small C application & library with almost zero dependency. Should 
>> be fairly easy to review.
>>
>>
>> Thanks!
>>
>> Hedayat
>>
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=678634
>>
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=755358
>>
>>
>

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

Re: Review Swaps

[Hedayat Vatankhah]

* Sorry, it was supposed to be in both HTML and text formats *


Hi all,

I'd like to swap these reviews with some other (not-so-complicated) ones:

Saaghar[1]- A Cross-Platform Persian Poetry Software

This is a Qt based application, and should not be complicated.

jcal[2] - Unix cal-like interface to libjalali

A small C application & library with almost zero dependency. Should be 
fairly easy to review.


Thanks!

Hedayat


[1] https://bugzilla.redhat.com/show_bug.cgi?id=678634

[2] https://bugzilla.redhat.com/show_bug.cgi?id=755358



On ۱۱/۱۱/۲۱  02:00, Petr Šabata wrote:

> On Mon, Nov 21, 2011 at 01:45:25PM +0330, Hedayat Vatankhah wrote:
>> 
>>
>>
>>  body
>>p { margin-bottom: 0cm; margin-top: 0pt; }
>>
>>>  bidimailui-detected-decoding-type="UTF-8" bgcolor="#FF"
>>  text="#00">
>>  Hi all,
>>  I'd like to swap these reviews with some other
>>(not-so-complicated) ones:
>>  Saaghar[1]->id="short_desc_nonedit_display">A Cross-Platform Persian
>>Poetry Software
>>  This is a Qt based application, and should not be complicated.
>>>id="short_desc_nonedit_display">>  id="summary_alias_container">>id="short_desc_nonedit_display">
>>  >id="short_desc_nonedit_display">jcal[2] - Unix cal-like
>>interface to libjalali
>>  >id="short_desc_nonedit_display">
>>  A small C application& library with almost zero dependency.
>>Should be fairly easy to review.
>>  
>>  
>>  Thanks!
>>  Hedayat
>>  
>>  
>>[1]> href="https://bugzilla.redhat.com/show_bug.cgi?id=678634";>https://bugzilla.redhat.com/show_bug.cgi?id=678634
>>  [2]> href="https://bugzilla.redhat.com/show_bug.cgi?id=755358";>https://bugzilla.redhat.com/show_bug.cgi?id=755358
>>  
>>
>> 
> Ugh, please don't send HTML-only emails to the list...
>
> -- Petr
>
>
> N�n�r)em�h�yhiם�w^��

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

Re: Review Swaps

[Jiri Popelka]

I've taken them.

Here is mine (SpliX - Driver for QPDL/SPL2 printers)
https://bugzilla.redhat.com/show_bug.cgi?id=755069

Thanks,

Jiri

On 11/21/2011 11:15 AM, Hedayat Vatankhah wrote:


Hi all,

I'd like to swap these reviews with some other (not-so-complicated) ones:

Saaghar[1]- A Cross-Platform Persian Poetry Software

This is a Qt based application, and should not be complicated.

jcal[2] - Unix cal-like interface to libjalali

A small C application & library with almost zero dependency. Should be 
fairly easy to review.



Thanks!

Hedayat


[1] https://bugzilla.redhat.com/show_bug.cgi?id=678634

[2] https://bugzilla.redhat.com/show_bug.cgi?id=755358




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

Self Introduction

[Nicolas Viéville]

Hello List,

I'm a newcomer to this list. My native language is french, so forgive me
if my English is not correct at all. I'm also a newcomer to the
packaging activity for Fedora. As suggested on the contributors page of
the Fedora site, here's the thread containing the package change request
I made for gnome-shell-extension-system-monitor-applet for F-16 and
F-15:

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

As a newcomer, I need someone to sponsor me to this new activity. Thanks
in advance for sponsoring me.
I will certainly have a few naive questions to ask after reading and
understanding the documentation for contributors, and most probably on
setting-up my environment to begin to contribute (specific tools - koji,
SCM, etc.). Thanks in advance for your advice.

I also began to contribute in packaging activity recently with non-free
RPMFusion broadcom-wl and wl-kmod packages for Fedora.

All questions or comments on these subjects are welcome.

Cordially,


-- 
Nicolas Viéville


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

Re: Review Swaps

[Petr Šabata]

On Mon, Nov 21, 2011 at 01:45:25PM +0330, Hedayat Vatankhah wrote:
> 
>   
> 
> body
>   p { margin-bottom: 0cm; margin-top: 0pt; } 
>   
>bidimailui-detected-decoding-type="UTF-8" bgcolor="#FF"
> text="#00">
> Hi all,
> I'd like to swap these reviews with some other
>   (not-so-complicated) ones:
> Saaghar[1]-id="short_desc_nonedit_display">A Cross-Platform Persian
>   Poetry Software
> This is a Qt based application, and should not be complicated. 
>  id="short_desc_nonedit_display"> id="summary_alias_container">   id="short_desc_nonedit_display">
>id="short_desc_nonedit_display">jcal[2] - Unix cal-like
>   interface to libjalali
>id="short_desc_nonedit_display">
> A small C application & library with almost zero dependency.
>   Should be fairly easy to review.
> 
> 
> Thanks!
> Hedayat
> 
> 
>   [1]  href="https://bugzilla.redhat.com/show_bug.cgi?id=678634";>https://bugzilla.redhat.com/show_bug.cgi?id=678634
> [2]  href="https://bugzilla.redhat.com/show_bug.cgi?id=755358";>https://bugzilla.redhat.com/show_bug.cgi?id=755358
> 
>   
> 

Ugh, please don't send HTML-only emails to the list...

-- Petr


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

Review Swaps

[Hedayat Vatankhah]

  
  
Hi all,
I'd like to swap these reviews with some other
  (not-so-complicated) ones:
Saaghar[1]- A Cross-Platform Persian
  Poetry Software
This is a Qt based application, and should not be complicated. 
  
jcal[2] - Unix cal-like
  interface to libjalali

A small C application & library with almost zero dependency.
  Should be fairly easy to review.


Thanks!
Hedayat


  [1] https://bugzilla.redhat.com/show_bug.cgi?id=678634
[2] https://bugzilla.redhat.com/show_bug.cgi?id=755358

  

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

Re: Libs with applications

[Tomas Mraz]

On Sun, 2011-11-20 at 21:36 +, John5342 wrote: 
> On Sun, Nov 20, 2011 at 19:33, Steve Grubb  wrote:
> > On Sunday, November 20, 2011 02:14:09 PM drago01 wrote:
> >> On Sun, Nov 20, 2011 at 8:03 PM, Kevin Kofler  
> >> wrote:
> >> > Steve Grubb wrote:
> >> >> For example, if a 32 bit library is installed, which application is left
> >> >> - the 64 or 32 bit one?
> >> >
> >> > If you install ONLY the 32-bit multilib, the 32-bit version.
> >> > If you install BOTH the 64-bit and 32-bit packages, the 64-bit version
> >> > (on all the platforms where 64-bit is preferred, which includes x86_64
> >> > and now also ppc64).
> >> > If you install ONLY the 64-bit package, the 64-bit version.
> >>
> >> Yeah which means there isn't really a problem here.
> >
> > Well, yeah there is the other problem of dependencies and getting a smaller 
> > minimal
> > install. For example, libnotify.
> >
> > # ldd /usr/bin/notify-send | wc -l
> > 44
> > # ldd /usr/lib64/libnotify.so.1.2.3 | wc -l
> > 12
> >
> > or how about libmsn
> > # ldd /usr/bin/msntest | wc -l
> > 20
> > # ldd /usr/lib64/libmsn.so.0.3.0 | wc -l
> > 9
> 
> I am the maintainer of libmsn. msntest probably could be moved to a
> subpackage but it is a small program. All of the dependencies found by
> ldd are already required by the applications using libmsn and msntest
> is also very useful for checking if a problem connecting to msn is
> caused by libmsn or the settings/applications using it. I would be
> happy to move msntest into a subpackage if it is specifically
> requested but under the current circumstances it would gain nothing
> and just add an extra package to the repos.

Exactly. In case the binaries shipped along with the library do not pull
any additional dependencies and they are reasonably small, there is no
need to put them into extra subpackages. At least not until rpm drops
the multilib and file-coloring support.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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