Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Alias-1.20-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.x86_64 requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Data-Alias-1.20-2.fc24.i686 requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Data-Alias-1.20-2.fc24.armv7hl requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.armv7hl requires perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

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

Re: Improvements of Fedora Sponsorship process

[Ben Rosser]

On Fri, Aug 5, 2016 at 10:35 AM, Neal Gompa  wrote:

> On Fri, Aug 5, 2016 at 3:32 AM, Miroslav Suchý  wrote:
> > I had the talk [1] about Fedora Sponsorship process at Flock. And we had
> > very interesting follow-up discussion.
> >
> > We come up with several improvements, which should be easy to implement
> and
> > may improve the process a lot. I am posting it here so more people can
> see
> > that and join the discussion.
> >
>
> Overall, I think the biggest problem with our Fedora contributor
> on-boarding process is that it's not so easy to discover people to
> help people get started. One thing I think Mageia (the other
> distribution I'm primarily involved in) does better is the discovery
> bit. As part of the on-boarding process[1], new contributors are
> encouraged to jump into a dedicated IRC channel (#mageia-mentoring)
> where they can meet people to help them through the process. Something
> like this might make it easier for people to find sponsors and find a
> mentor to teach them about how to make packages and be a Fedora packager.
> Perhaps having a mailing list and an IRC channel for this in Fedora
> might help make this process smoother.
>
> [1]: https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
>
>
Yeah, one thing that I remember when I was trying to become a packager is
that the instructions for how to get sponsored on the wiki contained (and
still contain) the phrase "When submitting a new package, usually a sponsor
finds you", which I think is a bit... overly optimistic in many situations.
Also at the time I was intimidated by the prospect of getting involved with
discussions on this list and IRC, which didn't help.

I looked at the Mageia how-to-become-a-packager process briefly a while ago
(my laptop dual-boots Fedora and Mageia, although I am primarily a Fedora
person), and I did notice how it seemed more hands on than ours. A
dedicated place for new contributors to go and meet potential sponsors or
other mentors, be that IRC or a mailing list, would probably be a good idea.

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

Re: Improvements of Fedora Sponsorship process

[Ben Rosser]

On Sun, Aug 7, 2016 at 12:24 AM, Parag Nemade  wrote:

> Right not for all SIGs but at least for those where its possible. Just
> see there are many such common pattern named packages are waiting in
> queue for their package review. I can think of some patterns like
> perl, python, golang, nodejs, ruby, ghc, mingw, php etc.
>
> Regards,
> Parag.
> --
>

You could maybe also search the summaries of packages for certain keywords
for some other SIGs that don't have common naming schemes? For example, I
just went through the review queue looking for packages with the word
"game" somewhere in the summary to build a list of unreviewed packages for
the Games SIG.

Admittedly, I'm struggling to think of another group of packages this sort
of pattern would be as easily applicable to, and you won't be as accurate
as you would be with getting, say, Python or NodeJS packages, but it might
help if we want to automatically catalog the queue.

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

Re: Improvements of Fedora Sponsorship process

[Parag Nemade]

Hi,

On Sat, Aug 6, 2016 at 1:49 AM, Mikolaj Izdebski  wrote:
> On 08/05/2016 10:31 AM, Parag Nemade wrote:
>>> b) fedora-review is run automatically by some bot/script just after review
>>> have been submitted.
>>
>>  Can a new utility be written for this as I don't think that long
>> fedora-review output is helpful? Most checks have no markings in them.
>> How can it be helpful to package submitter?
>
> You can configure which fedora-review checks are ran, for example
> exclude any non-automated checks.

I suppose then Generic group checks are sufficient here.

>
>>> c) Create wiki page with list of sponsors willing to accept new sponsoree.
>>> And list area of expertise of sponsors (e.g. java, python, IoT...). This
>>> will make for sponsoree easier to find right sponsor. Because we have some
>>> sponsors, who are active but are not willing to accept new sponsoree right
>>> now.
>>
>> This can be in addition to above, Why not run a script frequently and
>> check bugzilla and based on common naming CC the related SIG group?
>> e.g. if a package review is submitted whose name contains python then
>> add cc python SIG group that will notify actual group people and
>> someone can find interest and review the package. I know this is in
>> general suggestion but I suppose every SIG is also having some
>> Sponsors who can sponsor new contributor packages.
>
> This won't work for all SIGs. For example, Java packages don't have any
> common naming scheme. If you just search for "Java" in review requests,
> almost all results will be false-positives (eg. from "JavaScript") and
> you won't find most of relevant reviews this way.
>
> I think that wiki page could work for this purpose.

Right not for all SIGs but at least for those where its possible. Just
see there are many such common pattern named packages are waiting in
queue for their package review. I can think of some patterns like
perl, python, golang, nodejs, ruby, ghc, mingw, php etc.

Regards,
Parag.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Pending ACLs

[Parag Nemade]

Hi,

On Sat, Aug 6, 2016 at 11:07 PM,   wrote:
> Sometimes a maintainer doesn't want to approve ACLs for "reasons" but
> doesn't want to reject the request for various reasons including the
> requestor re-request of denied requests.
>

To add few things here,

1) Why do we need such "Pending ACLs" weekly emails? The package owner
already gets notifications when someone requests ACLs. Now if you say
people forgets then why not implement something in pkgdb only which
will keep sending weekly notification again to package owners that
someone has requested ACLs on their packages? What benefit will others
get by reading these emails that someone requested ACLs on some
package and its owner still not approving?

2) Sometime back I don't remember if I filed issue against pkgdb but I
discussed on IRC why not add some text entry box while requesting
ACLs. Not everyone knows everyother one here. Let the package owner
know why the ACL requestor need other package access. That will help
package owners to decide to approve or deny quickly. There can be some
people who want to have access/co-maintainer for some packages where
they really not needed to be.

3) I am not sure but I think there is some automation for something in
pkgdb which automatically grants package access to requstor if package
owner do not take action. Correct me if I am wrong here.

Regards,
Parag.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Can I request update of mock with fedora-25 configurations ?

[Sérgio Basto]

On Sáb, 2016-08-06 at 20:40 -0500, Rex Dieter wrote:
> Sérgio Basto wrote:
> 
> > 
> > Hello,
> > After Fedora 25 Mass Branching , should be mock update with fedora-
> > 25
> > configurations  ?
> > Other question where I should ask it ? bugzilla ?
> bugzilla +1

Thanks, https://bugzilla.redhat.com/show_bug.cgi?id=1364754 
-- 
Sérgio M. B.

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

Re: Can I request update of mock with fedora-25 configurations ?

[Rex Dieter]

Sérgio Basto wrote:

> Hello,
> After Fedora 25 Mass Branching , should be mock update with fedora-25
> configurations  ?
> Other question where I should ask it ? bugzilla ?

bugzilla +1

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

Re: Redefinition of the primary and secondary architectures

[Kevin Kofler]

Peter Robinson wrote:
> There will be a slight change that a failure in an arch won't cancel
> the other arches and each one will run to completion (pass/fail) but
> the overall primary task will still fail.

I don't see how wasting Koji resources on completing an already failed build 
helps anybody.

> The data we have for build failures across all the arches show that
> not to be the case.

Having been plagued by obscure architecture-specific toolchain bugs several 
times (see also my other mail in this thread), I don't think you are seeing 
the whole picture there.

> All the pure noarch packages, which is over 50% of the distribution,

Noarch packages are by their very nature unaffected by the vast majority of 
architecture-specific issues. (Also because they are typically interpreted 
packages where the "build" process is trivial.) They are not a 
representative sample in any way.

> currently can and are regularly built on ppc64/ppc64le builders now
> anyway due to them being in primary koji for EPEL so for a large
> percentage it's already dealing with a lot of the arches we're due to
> cover anyway and there's not been a single issue reported there in the
> 12 months that ppc64le has been present.

Are you sure that Fedora noarch packages are actually being built on ppc64 
builders? They would need a ppc64 Fedora in the buildroot for that. I 
remember that back when PPC was demoted to secondary, Fedora noarch builds 
stopped happening on PPC builders for the releases where PPC was no longer 
primary (while still happening for the updates of the last PPC-as-primary 
release), because of that buildroot thing. It was similar the other way 
round when ARM was added to the primary Koji instance, only the new release 
was able to use ARM builders for noarch packages.

> And in response to the "slow built times" the builders in the non
> primary koji instance are of equivalent or faster than the x86
> builders. EG the ppc64 builders use to be a LOT slower than x86 back
> when we had Power6 builders, but that hasn't been the case for over 3
> years, and the current Power8 generation builders are actually faster
> than the x86 builders.

Does that also hold for build tasks that cannot be parallelized (e.g.: 
custom specfile scripts, handwritten build scripts from upstream, Makefiles 
that do not support %{_smp_mflags} due to race conditions, etc.)?

And is this really a strength of the new architectures? To me, it sounds 
more like a sign that the x86 builders need to be renewed. Or is aarch64 
really competitive at performance with x86 now?

> For ARMv7 (which is not part of this because it's already in primary) will
> actually get faster builders on aarch64 as part of this change.

And making ARMv7 primary was a big mistake that ought to be corrected now 
that it is clear that Fedora will never (or at least not in the foreseeable 
future) run on the ARM devices 99% of ARM users out there use (smartphones), 
and that the remaining ARM niche is being obsoleted by aarch64. ARMv7 should 
become secondary again (with the "old" definition of "secondary", not your 
proposed one). Then you can also (instead of your proposed change) easily 
put your fancy new builders on the ARM Koji instance and build both ARMv7 
and aarch64 on them without bothering the x86 builds.

> In most cases the maintainers are still bothered by failures even from
> the secondary arches anyway, it will certainly be more up front to
> them but the core packages that historically have issues (toolchains
> etc) already have maintainers that actively test and support the non
> x86  architectures anyway.

Well, I care about the primary architectures mainly, and usually leave 
issues on the secondary architectures to the secondary architecture 
maintainer. And IMHO, that's how it should be. The people who care about 
exotic niche architectures should be the ones doing the work for them.

> Yes, but how would you deal with a soname bump where if it's not fatal
> on an arch what happens when something is then rebuilt against one
> version on one arch and a different version on a different arch. You
> end up in a big mess really quickly. It ends up being a lot less work
> (even in the current situation with non x86 arches) if the issue is
> fixed from the outset.

The "big mess" you describe is how Debian does things, it works well for 
them. The alternative approach is how koji-shadow does things: just hold all 
builds that have the failed build in the buildroot. (And the easiest way to 
implement that is to just keep using koji-shadow. I don't see why we have to 
shoehorn everything into the main Koji instance.)

Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Redefinition of the primary and secondary architectures

[Kevin Kofler]

Peter Robinson wrote:
> We are planning to change the way Alternate Architectures (non x86_64)
> are handled in terms of "primary" vs "secondary".

Let me repost here what I already posted at:
https://fedorahosted.org/fesco/ticket/1592#comment:14

There, I wrote:
| IMHO, it is entirely unacceptable to let toolchain bugs on obscure
| architectures (bugs that, in my experience, are much more frequent than
| the OP is claiming) hold our builds hostage (through the proposed "fail on
| one = fail on all" principle). It is already painful enough with ARM
| (e.g., this showstopper: 
| https://bugzilla.redhat.com/show_bug.cgi?id=1342095 has been breaking
| builds of several Qt/KDE packages for months and is still not fixed – the
| only workaround that makes the affected packages build on ARM makes the
| output not Fedora-complaint (it is not allowed to require NEON)). I have
| seen even worse architecture-specific bugs and limitations (e.g. on the
| number of relocations) from targets such as ppc64 (the obscure "number of
| relocations" thing is a real ppc64 example) that this proposal would also
| make blocking for builds.
|
| IMHO, only ONE architecture (probably x86_64) should block builds. A
| failure on any other architecture (including ARM) should affect only the
| failing architecture.

Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bodhi UI Redesign User Survey

[Björn Persson]

rkolathu wrote:
> Hi Bjorn,
> 
> Thanks for the feedback
> 
> It will be great if you could share your thoughts on improving the 
> interface. It will be useful for incorporating that into our survey 
> which ultimately will benefit the re-design process.


On my relation to Bodhi:

I've been using Fedora since Red Hat Linux 6.1, but I've only been
making packages for seven years. I use Bodhi to release updates to my
packages, and sometimes to vote on others' updates that are related to
my packages. This happens infrequently and irregularly as I do most
version upgrades during the Rawhide phase. It looks like the user
interface has already been redesigned once since the latest time I used
Bodhi.


On question 5:

Is the green icon a link to the tarball? Would one click on the green
icon to get the tarball and on the blue text to get the source RPM
package? Does the icon link to the upstream download site, or to some
Fedora server that provides copies of upstream tarballs?

On an actual page I could find out the answers by pointing to the links
to see the URLs, but in the mockup there are no URLs, so I'm not sure
what the mockup is supposed to show.


On question 6:

I'm at first confused by the term "Bugzilla Updates". A Bugzilla update
is a new version of the Bugzilla server software. The term you want is
"bug reports".

I don't much like the icons that look like "done" and "delete". I can
figure out that they're probably supposed to mean "solved by this
update" and "not solved", but I don't want to play the "guess the
symbol" game while I'm working on package updates.

After carefully studying the pictures I conclude that the question
you're trying to ask is: "Should complete bug reports with comment
threads be displayed in the Bodhi user interface, instead of just
titles with links to Bugzilla?" Well, it's not very important to me but
I suppose it could be useful if it doesn't hurt performance.


On question 7:

We're playing "guess the symbol" again, but this time we're given the
choices "delete", "empty box" and "done".


On question 8:

I'm at first confused about the "Page Version" and "Tab Version". It
sounds like two different versions of the user interface or something.
Comparing the pictures I find out that the "tab version" is just an
enlarged picture of the important part of the "page version".

Once that confusion is cleared up, I wonder what the hell "Overall
Metrics" and "Masher Status" are doing in a list of Fedora releases.


On question 9:

"Guess the symbol" once more. The first one looks like an Atom or RSS
feed, but it's not at all clear what messages that feed would contain.
The second looks like some kind of list. It's in the Builds field, so
it might be a list of the builds that are included in this update. But
aren't those already listed right there in the Builds field (only one
in this example)? The third symbol looks like "out", but I have no idea
what would be going out from where.

I suppose the choice "I have no idea what these are used for" is close
enough, although "some vague idea" would be more true.


Björn Persson


pgpvCuCQyo8Wb.pgp
Description: OpenPGP digital signatur
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

WwSww

[Mark Rader]

Sent from my iPhonesA
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Can I request update of mock with fedora-25 configurations ?

[Sérgio Basto]

Hello, 
After Fedora 25 Mass Branching , should be mock update with fedora-25
configurations  ? 
Other question where I should ask it ? bugzilla ? 

Thanks,
-- 
Sérgio M. B.

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

Re: Improvements of Fedora Sponsorship process

[Michael Scherer]

On Fri, Aug 05, 2016 at 09:32:28AM +0200, Miroslav Suchý wrote:
> I had the talk [1] about Fedora Sponsorship process at Flock. And we
> had very interesting follow-up discussion.

So I kinda missed it, since for some reason, i tought this was
about financial sponsorship.
(Given that I forgot words in each title of my own talks, I can't
really complain much)


> c) Create wiki page with list of sponsors willing to accept new
> sponsoree. And list area of expertise of sponsors (e.g. java,
> python, IoT...). This will make for sponsoree easier to find right
> sponsor. Because we have some sponsors, who are active but are not
> willing to accept new sponsoree right now.

I think that's a good idea, but wouldn't it risk getting out
of date after some time ?

Should someone be in charge of it ?
 
> d) When sponsors is not active for 2 years [*] - that means not just
> in sponsoring work, but there is no activity in BZ, koji, wiki and
> any other Fedora service at all (guessed by reading log of fedmsg),
> then his sponsor status is removed. We will assume that the sponsor
> is gone for good.

what happen to the existing sponsored packagers ? (ie, do they get reassigned
to a new sponsor ?)

-- 
Michael Scherer
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1364730] New: DKIM signing of originating mail stopped working after upgrade from 2.10.1-5 to 2.11.0-3

[bugzilla]

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

Bug ID: 1364730
   Summary: DKIM signing of originating mail stopped working after
upgrade from 2.10.1-5 to 2.11.0-3
   Product: Fedora
   Version: 24
 Component: amavisd-new
  Assignee: j.orti.alca...@gmail.com
  Reporter: m...@cipixia.com
QA Contact: extras...@fedoraproject.org
CC: j.orti.alca...@gmail.com,
perl-devel@lists.fedoraproject.org, st...@silug.org,
vanmeeuwen+fed...@kolabsys.com



Created attachment 1188215
  --> https://bugzilla.redhat.com/attachment.cgi?id=1188215=edit
Patch file from
https://lists.amavis.org/pipermail/amavis-users/2016-July/004428.html

Description of problem:

Hello, after updating to the latest amavisd-new package I noticed that DKIM
signing no longer works with existing configs.

Running amavisd-new in debug mode, I can confirm that locally generated mail
(in this example sent from root to another local user) is getting routed to the
corrected port for the ORIGINATING policy bank (10026):

Aug  6 18:36:05.865 cipixia.com /usr/sbin/amavisd[2709]: (02709-01) LMTP :10026
/var/spool/amavisd/tmp/amavis-20160806T183605-02709-mYQagKcY:
 ->  Received: from cipixia.com
([127.0.0.1]) by localhost (cipixia.com [127.0.0.1]) (amavisd-new, port 10026)
with LMTP for ; Sat,  6 Aug 2016 18:36:05 +0200 (CEST)

but then a little bit later it decides that the mail is not considered
originating (relevant bits pasted from log):

Aug  6 18:36:05.905 cipixia.com /usr/sbin/amavisd[2709]: (02709-01) Checking:
wVqqBSZuYzR0 ORIGINATING [127.0.0.1]  -> 
...
...
Aug  6 18:36:05.906 cipixia.com /usr/sbin/amavisd[2709]: (02709-01) Open relay?
Nonlocal recips but not originating: m...@localhost.com
...
...
Aug  6 18:36:05.931 cipixia.com /usr/sbin/amavisd[2709]: (02709-01) dkim: not
signing mail which is not originating from our site


I Googled around and found this relevant post on the amavisd-new mailing list,
which actually solved my problem:
https://lists.amavis.org/pipermail/amavis-users/2016-July/004428.html

In the related message, Giovanni provides a simple patch for /usr/sbin/amavisd
that restores expected functionality.

I tested this patch against my current amavisd-new install by applying it like
so:
patch -b /usr/sbin/amavisd < /tmp/amavisd_dkim_fix.patch 

I then reran the the same test as before by sending an email from root to
another localhost user with amavisd-new in debug mode, and the output now shows
the expected behavior:

Aug  6 18:44:48.246 cipixia.com /usr/sbin/amavisd[2882]: (02882-01) LMTP :10026
/var/spool/amavisd/tmp/amavis-20160806T184448-02882-LhR01zY9:
 ->  Received: from cipixia.com
([127.0.0.1]) by localhost (cipixia.com [127.0.0.1]) (amavisd-new, port 10026)
with LMTP for ; Sat,  6 Aug 2016 18:44:48 +0200 (CEST)
...
...
Aug  6 18:44:48.286 cipixia.com /usr/sbin/amavisd[2882]: (02882-01) Checking:
r89s629QBf_0 ORIGINATING [127.0.0.1]  -> 
...
...
Aug  6 18:44:48.309 cipixia.com /usr/sbin/amavisd[2882]: (02882-01) dkim:
candidate originators: From:
..
..
Aug  6 18:44:48.310 cipixia.com /usr/sbin/amavisd[2882]: (02882-01) dkim:
signing (author), From:  (From:),
KEY.key_ind=>0, a=>rsa-sha256, c=>relaxed/simple, d=>cipixia.com, s=>dkimkey,
ttl=>1814400, x=>1472316289

and so on.

I am not subscribed to the amavisd user's mailing list so I'm not sure if the
upstream developers have responded to or acknowledged Giovanni's message, but
his patch worked for me and solved the issue.


Version-Release number of selected component (if applicable):
amavisd-new-2.11.0-3.fc24.noarch

How reproducible:
Always


Steps to Reproduce:
1.  Setup dkim signing for the originating policy bank
2.  Verify in the logs that your test mail is being routed to the correct port
3.  Observe that dkim signing is not performed and the message is not
considered "local", despite being in the right policy bank

Actual results:
No dkim signing, log messages indicate local mail is not considered as
originating.


Expected results:
Dkim signing performed and triggered by ORIGINATING mail


Additional info:
I've attached the patch from the mailing list to this bug, for convenience

-- 
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-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Pending ACLs

[Kalev Lember]

On 08/06/2016 05:36 PM, Richard W.M. Jones wrote:
> On Sat, Aug 06, 2016 at 03:48:36PM +0100, Fabio Alessandro Locati wrote:
>> On Thu, Aug 04, 2016 at 08:41:56PM +0100, Richard W.M. Jones wrote:
>>> Your email needs a "call to action" link, otherwise no one will know
>>> what they are supposed to do about it.  In this case it's probably:
>>>
>>>   https://admin.fedoraproject.org/pkgdb/acl/pending/
>>>
>>> However I visited the above URL, logged in, and it says:
>>>
>>>   Pending ACLs
>>>   No pending ACLs for you 
>>>
>>> So I guess this is wrong or perhaps refers to something else:
>>>
>>> ...
 3  rjones
>>> ...
>>
>> Hi Richard,
>>
>> It seems like pkgdb is hiding those ACL requests on the page you linked.
>> It seems like the following requests could/should be approved by you:
>>
>>  requester |   req_acl   | package | distro | version | approver 
>> ---+-+-++-+--
>>  epienbro  | commit  | mingw32-gtk-vnc | Fedora | devel   | rjones
>>  epienbro  | approveacls | mingw32-gtk-vnc | Fedora | devel   | rjones
>>  ktietz| approveacls | mingw32-openssl | Fedora | devel   | rjones
> 
> I've checked again just now, and I still don't see those ACLs.
> It still says:
> 
>   Pending ACLs
> 
>   No pending ACLs for you 

We retired all mingw32- packages a few years ago and renamed them to
mingw-, so I think pkgdb is correct here to not show these to you.

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

Re: Pending ACLs

[dennis]

Sometimes a maintainer doesn't want to approve ACLs for "reasons" but doesn't 
want to reject the request for various reasons including the requestor 
re-request of denied requests.

Dennis 

On August 5, 2016 3:34:58 PM GMT+02:00, Helio Chissini de Castro 
 wrote:
>I have a strong opinion over this
>
>All the ACL's should be accepted, doesn't matter the level.
>And why i think of this ?
>
>Two simple reasons:
>- The packager abandoned the package, because several reasons, and then
>is
>far away from Fedora systems for some time
>- The packager is actively using Fedora, but seen not care to even
>properly
>take care of his package, not in the minimal sense to deny the ACL,
>which
>would be acceptable.
>
>In both cases, the package became hostage to someone that for sure
>aren't
>caring much for the distro, unless prove me wrong.
>
>
>
>On Fri, Aug 5, 2016 at 3:07 PM, Pierre-Yves Chibon
>
>wrote:
>
>> On Fri, Aug 05, 2016 at 11:14:02AM +0200, Dan Horák wrote:
>> > On Thu, 4 Aug 2016 20:41:56 +0100
>> > "Richard W.M. Jones"  wrote:
>> >
>> > > On Thu, Aug 04, 2016 at 04:43:40PM +0200, Fabio Alessandro Locati
>> > > wrote:
>> > > > Hi all,
>> > > >
>> > > > This morning, during the automation workshop, I had the
>occasion of
>> > > > speaking about this with Pingou and Threebean.
>> > > > Thanks to Pingou hints, I've created a query to get pending ACL
>from
>> > > > pkgdb.
>> > > > What I'd like to share with you all is the list of users that
>can
>> > > > approve/deny ACL requests (older than 1 month) but have not
>done it
>> > > > yet (the number refers to the number of ACL pending).
>> > > >
>> > > > I think that people should take care of the pending ACL they
>can
>> > > > approve/deny and actually approve or deny them ASAP.
>> > >
>> > > Your email needs a "call to action" link, otherwise no one will
>know
>> > > what they are supposed to do about it.  In this case it's
>probably:
>> > >
>> > >   https://admin.fedoraproject.org/pkgdb/acl/pending/
>> > >
>> > > However I visited the above URL, logged in, and it says:
>> > >
>> > >   Pending ACLs
>> > >   No pending ACLs for you
>> >
>> > also there should be no action required from the owner for
>"watchcommit"
>> > or "watchbugzilla" requests, looks as a bug in the conversion when
>> > deploying the recent pkgdb
>>
>> Well, the recent pkgdb is already quite a bit old and it should
>> definitively
>> auto-accept the watch* ACLs.
>> Do you have a link so I could look at the package/history?
>>
>> Thanks,
>> Pierre
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>>
>https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>>
>
>
>
>
>--
>devel mailing list
>devel@lists.fedoraproject.org
>https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

pghmcfc pushed to perl-DateTime (perl-DateTime-1.35-1.fc26). "Update to 1.35 (..more)"

[notifications]

This commit already existed in another branch.

http://pkgs.fedoraproject.org/cgit/perl-DateTime.git/commit/?h=perl-DateTime-1.35-1.fc26=fd8c4d5e019d0466888e76727d411aac114ceaad
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

pghmcfc pushed to perl-DateTime (perl-DateTime-1.35-1.fc25). "Update to 1.35 (..more)"

[notifications]

From fd8c4d5e019d0466888e76727d411aac114ceaad Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Sat, 6 Aug 2016 17:33:22 +0100
Subject: Update to 1.35

- New upstream release 1.35
  - Use namespace::autoclean in all packages that import anything; without
cleaning the namespace, DateTime ends up with "methods" like try and catch
(from Try::Tiny), which can lead to very confusing bugs (CPAN RT#115983)
---
 perl-DateTime.spec | 10 --
 sources|  2 +-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/perl-DateTime.spec b/perl-DateTime.spec
index 8e0cf89..ef9811e 100644
--- a/perl-DateTime.spec
+++ b/perl-DateTime.spec
@@ -1,6 +1,6 @@
 Name:   perl-DateTime
 Epoch:  2
-Version:1.34
+Version:1.35
 Release:1%{?dist}
 Summary:Date and time object for Perl
 License:Artistic 2.0
@@ -23,13 +23,13 @@ BuildRequires:  perl(DateTime::Locale) >= 1.05
 BuildRequires:  perl(DateTime::TimeZone) >= 2.00
 BuildRequires:  perl(Dist::CheckConflicts) >= 0.02
 BuildRequires:  perl(integer)
+BuildRequires:  perl(namespace::autoclean)
 BuildRequires:  perl(overload)
 BuildRequires:  perl(Params::Validate) >= 1.03
 BuildRequires:  perl(POSIX)
 BuildRequires:  perl(Scalar::Util)
 BuildRequires:  perl(strict)
 BuildRequires:  perl(Try::Tiny)
-BuildRequires:  perl(vars)
 BuildRequires:  perl(warnings)
 BuildRequires:  perl(warnings::register)
 # Optional Run-time:
@@ -92,6 +92,12 @@ make test
 %{_mandir}/man3/DateTime::LeapSecond.3*
 
 %changelog
+* Sat Aug  6 2016 Paul Howarth  - 2:1.35-1
+- Update to 1.35
+  - Use namespace::autoclean in all packages that import anything; without
+cleaning the namespace, DateTime ends up with "methods" like try and catch
+(from Try::Tiny), which can lead to very confusing bugs (CPAN RT#115983)
+
 * Wed Jul  6 2016 Paul Howarth  - 2:1.34-1
 - Update to 1.34
   - Added the leap second coming on December 31, 2016
diff --git a/sources b/sources
index 963bf2c..68143b8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-80b4befaaeb7de8dcc79f80a874bbf2f  DateTime-1.34.tar.gz
+db8f0c5d0d8109c026ba4722a842edc9  DateTime-1.35.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-DateTime.git/commit/?h=perl-DateTime-1.35-1.fc25=fd8c4d5e019d0466888e76727d411aac114ceaad
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: fortran

[bitlord]

On Sat, 06 Aug 2016 15:26:12 -
ba...@laposte.net wrote:

> Hello,
> 
> i use fortran in my university : is it possible to have the last GNU
> fortran (version 6) integrated in the spin distribution !
> 
gcc-gfortran package (6.1.x on >=f23)?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Pending ACLs

[Kevin Fenzi]

On Sat, 6 Aug 2016 17:23:31 +0100
Fabio Alessandro Locati  wrote:

> On Sat, Aug 06, 2016 at 04:36:34PM +0100, Richard W.M. Jones wrote:
> > I've checked again just now, and I still don't see those ACLs.  
> 
> My guess is that it's a PkgDB bug and for this reason I'm trying to
> get in touch with Pingou.

Note that he is traveling back from flock now, so I'm sure he will get
in contact once he is back home. :) 

kevin


pgpHU53UrNyvp.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

pghmcfc pushed to perl-DateTime (f25). "Update to 1.35 (..more)"

[notifications]

From fd8c4d5e019d0466888e76727d411aac114ceaad Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Sat, 6 Aug 2016 17:33:22 +0100
Subject: Update to 1.35

- New upstream release 1.35
  - Use namespace::autoclean in all packages that import anything; without
cleaning the namespace, DateTime ends up with "methods" like try and catch
(from Try::Tiny), which can lead to very confusing bugs (CPAN RT#115983)
---
 perl-DateTime.spec | 10 --
 sources|  2 +-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/perl-DateTime.spec b/perl-DateTime.spec
index 8e0cf89..ef9811e 100644
--- a/perl-DateTime.spec
+++ b/perl-DateTime.spec
@@ -1,6 +1,6 @@
 Name:   perl-DateTime
 Epoch:  2
-Version:1.34
+Version:1.35
 Release:1%{?dist}
 Summary:Date and time object for Perl
 License:Artistic 2.0
@@ -23,13 +23,13 @@ BuildRequires:  perl(DateTime::Locale) >= 1.05
 BuildRequires:  perl(DateTime::TimeZone) >= 2.00
 BuildRequires:  perl(Dist::CheckConflicts) >= 0.02
 BuildRequires:  perl(integer)
+BuildRequires:  perl(namespace::autoclean)
 BuildRequires:  perl(overload)
 BuildRequires:  perl(Params::Validate) >= 1.03
 BuildRequires:  perl(POSIX)
 BuildRequires:  perl(Scalar::Util)
 BuildRequires:  perl(strict)
 BuildRequires:  perl(Try::Tiny)
-BuildRequires:  perl(vars)
 BuildRequires:  perl(warnings)
 BuildRequires:  perl(warnings::register)
 # Optional Run-time:
@@ -92,6 +92,12 @@ make test
 %{_mandir}/man3/DateTime::LeapSecond.3*
 
 %changelog
+* Sat Aug  6 2016 Paul Howarth  - 2:1.35-1
+- Update to 1.35
+  - Use namespace::autoclean in all packages that import anything; without
+cleaning the namespace, DateTime ends up with "methods" like try and catch
+(from Try::Tiny), which can lead to very confusing bugs (CPAN RT#115983)
+
 * Wed Jul  6 2016 Paul Howarth  - 2:1.34-1
 - Update to 1.34
   - Added the leap second coming on December 31, 2016
diff --git a/sources b/sources
index 963bf2c..68143b8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-80b4befaaeb7de8dcc79f80a874bbf2f  DateTime-1.34.tar.gz
+db8f0c5d0d8109c026ba4722a842edc9  DateTime-1.35.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-DateTime.git/commit/?h=f25=fd8c4d5e019d0466888e76727d411aac114ceaad
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

pghmcfc pushed to perl-DateTime (master). "Update to 1.35 (..more)"

[notifications]

From fd8c4d5e019d0466888e76727d411aac114ceaad Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Sat, 6 Aug 2016 17:33:22 +0100
Subject: Update to 1.35

- New upstream release 1.35
  - Use namespace::autoclean in all packages that import anything; without
cleaning the namespace, DateTime ends up with "methods" like try and catch
(from Try::Tiny), which can lead to very confusing bugs (CPAN RT#115983)
---
 perl-DateTime.spec | 10 --
 sources|  2 +-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/perl-DateTime.spec b/perl-DateTime.spec
index 8e0cf89..ef9811e 100644
--- a/perl-DateTime.spec
+++ b/perl-DateTime.spec
@@ -1,6 +1,6 @@
 Name:   perl-DateTime
 Epoch:  2
-Version:1.34
+Version:1.35
 Release:1%{?dist}
 Summary:Date and time object for Perl
 License:Artistic 2.0
@@ -23,13 +23,13 @@ BuildRequires:  perl(DateTime::Locale) >= 1.05
 BuildRequires:  perl(DateTime::TimeZone) >= 2.00
 BuildRequires:  perl(Dist::CheckConflicts) >= 0.02
 BuildRequires:  perl(integer)
+BuildRequires:  perl(namespace::autoclean)
 BuildRequires:  perl(overload)
 BuildRequires:  perl(Params::Validate) >= 1.03
 BuildRequires:  perl(POSIX)
 BuildRequires:  perl(Scalar::Util)
 BuildRequires:  perl(strict)
 BuildRequires:  perl(Try::Tiny)
-BuildRequires:  perl(vars)
 BuildRequires:  perl(warnings)
 BuildRequires:  perl(warnings::register)
 # Optional Run-time:
@@ -92,6 +92,12 @@ make test
 %{_mandir}/man3/DateTime::LeapSecond.3*
 
 %changelog
+* Sat Aug  6 2016 Paul Howarth  - 2:1.35-1
+- Update to 1.35
+  - Use namespace::autoclean in all packages that import anything; without
+cleaning the namespace, DateTime ends up with "methods" like try and catch
+(from Try::Tiny), which can lead to very confusing bugs (CPAN RT#115983)
+
 * Wed Jul  6 2016 Paul Howarth  - 2:1.34-1
 - Update to 1.34
   - Added the leap second coming on December 31, 2016
diff --git a/sources b/sources
index 963bf2c..68143b8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-80b4befaaeb7de8dcc79f80a874bbf2f  DateTime-1.34.tar.gz
+db8f0c5d0d8109c026ba4722a842edc9  DateTime-1.35.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-DateTime.git/commit/?h=master=fd8c4d5e019d0466888e76727d411aac114ceaad
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

pghmcfc uploaded DateTime-1.35.tar.gz for perl-DateTime

[notifications]

db8f0c5d0d8109c026ba4722a842edc9  DateTime-1.35.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-DateTime/DateTime-1.35.tar.gz/md5/db8f0c5d0d8109c026ba4722a842edc9/DateTime-1.35.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Pending ACLs

[Fabio Alessandro Locati]

On Sat, Aug 06, 2016 at 10:26:36AM -0400, Neal Gompa wrote:
> On Sat, Aug 6, 2016 at 10:24 AM, Fabio Alessandro Locati
>  wrote:
> > On Fri, Aug 05, 2016 at 03:34:58PM +0200, Helio Chissini de Castro wrote:
> >> I have a strong opinion over this
> >>
> >> All the ACL's should be accepted, doesn't matter the level.
> >> And why i think of this ?
> >>
> >> Two simple reasons:
> >> - The packager abandoned the package, because several reasons, and then is
> >> far away from Fedora systems for some time
> >> - The packager is actively using Fedora, but seen not care to even properly
> >> take care of his package, not in the minimal sense to deny the ACL, which
> >> would be acceptable.
> >>
> >> In both cases, the package became hostage to someone that for sure aren't
> >> caring much for the distro, unless prove me wrong.
> >
> > Hi,
> >
> > On one hand I agree with you, on the other hand I do think that
> > sometimes pkgdb notifications are not so visible and therefore someone
> > could inadvertly loose track of some notifications and with your
> > proposal, this would trigger an auto-approval.
> 
> The last time someone requested ACLs from one of my packages, I
> received an email about it. So if they're not reading email about
> their package, then that's a problem.

Sometimes an email could get missplaced. I think that at least an
(additional) weekly recap email should be sent (only to people with
pending ACL approval).

Best,
Fale
-- 
Fabio Alessandro Locati
Red Hat - Senior Consultant

PGP Fingerprint: E815 3C49 2A8D FD8B 1CBD  BC85 FDB3 DF20 B2DC 9C1B


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

Re: Pending ACLs

[Fabio Alessandro Locati]

On Sat, Aug 06, 2016 at 04:36:34PM +0100, Richard W.M. Jones wrote:
> I've checked again just now, and I still don't see those ACLs.

My guess is that it's a PkgDB bug and for this reason I'm trying to get
in touch with Pingou.

Cheers,
Fale

-- 
Fabio Alessandro Locati
Red Hat - Senior Consultant

PGP Fingerprint: E815 3C49 2A8D FD8B 1CBD  BC85 FDB3 DF20 B2DC 9C1B


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

Re: Pending ACLs

[Richard W.M. Jones]

On Sat, Aug 06, 2016 at 03:48:36PM +0100, Fabio Alessandro Locati wrote:
> On Thu, Aug 04, 2016 at 08:41:56PM +0100, Richard W.M. Jones wrote:
> > Your email needs a "call to action" link, otherwise no one will know
> > what they are supposed to do about it.  In this case it's probably:
> > 
> >   https://admin.fedoraproject.org/pkgdb/acl/pending/
> > 
> > However I visited the above URL, logged in, and it says:
> > 
> >   Pending ACLs
> >   No pending ACLs for you 
> > 
> > So I guess this is wrong or perhaps refers to something else:
> > 
> > ...
> > > 3 rjones
> > ...
> 
> Hi Richard,
> 
> It seems like pkgdb is hiding those ACL requests on the page you linked.
> It seems like the following requests could/should be approved by you:
> 
>  requester |   req_acl   | package | distro | version | approver 
> ---+-+-++-+--
>  epienbro  | commit  | mingw32-gtk-vnc | Fedora | devel   | rjones
>  epienbro  | approveacls | mingw32-gtk-vnc | Fedora | devel   | rjones
>  ktietz| approveacls | mingw32-openssl | Fedora | devel   | rjones

I've checked again just now, and I still don't see those ACLs.
It still says:

  Pending ACLs

  No pending ACLs for you 

   Copyright © 2013-2016 Red Hat pkgdb2 -- 2.4.3 -- Documentation -- API

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

fortran

[bad00]

Hello,

i use fortran in my university : is it possible to have the last GNU fortran 
(version 6) integrated in the spin distribution !

bests regards
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Redefinition of the primary and secondary architectures

[Peter Robinson]

>>> On the subject of RISC-V, I'm still plugging away at this.  It's
>>> rather slow going, but you can take a look at:
>>>
>>>   http://git.annexia.org/?p=fedora-riscv.git;a=summary
>>>
>>> There is nothing much usable at the moment, and many stumbling blocks.
>>
>>
>> Yes, but this is an "experimental arch" and is completely out of scope
>> of this proposal.
>
>
> True, but it does beg the question, how will future new arches (e.g. riscv,
> or mips) be handled?  Will koji-shadow still have a place in that, and what
> criteria will be established for merging into primary?

It would be a different set of requirements.

It's more similar to how architectures achieved the former "secondary"
status. These requirements basically equate to:
* availability of decent enterprise hardware that can be added to the
Fedora data centre for build systems and other requirements (rel-eng,
QA etc)
* proven commitment from a company/team/community to support the architecture
* reasonable availability of hardware. It's a lot of work for the
various Fedora teams to support any architecture, even as a secondary
architecture.

Likely a lot of other stuff that I've missed out but I think it gives
a general idea.

In the time between bring up phase and acceptance of the above
koji-shadow still remains the proper means of ensuring builds are as
close to Fedora mainline as possible.

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

Re: Pending ACLs

[Fabio Alessandro Locati]

On Thu, Aug 04, 2016 at 08:41:56PM +0100, Richard W.M. Jones wrote:
> Your email needs a "call to action" link, otherwise no one will know
> what they are supposed to do about it.  In this case it's probably:
> 
>   https://admin.fedoraproject.org/pkgdb/acl/pending/
> 
> However I visited the above URL, logged in, and it says:
> 
>   Pending ACLs
>   No pending ACLs for you 
> 
> So I guess this is wrong or perhaps refers to something else:
> 
> ...
> > 3   rjones
> ...

Hi Richard,

It seems like pkgdb is hiding those ACL requests on the page you linked.
It seems like the following requests could/should be approved by you:

 requester |   req_acl   | package | distro | version | approver 
---+-+-++-+--
 epienbro  | commit  | mingw32-gtk-vnc | Fedora | devel   | rjones
 epienbro  | approveacls | mingw32-gtk-vnc | Fedora | devel   | rjones
 ktietz| approveacls | mingw32-openssl | Fedora | devel   | rjones

Best,
Fale
-- 
Fabio Alessandro Locati
Red Hat - Senior Consultant

PGP Fingerprint: E815 3C49 2A8D FD8B 1CBD  BC85 FDB3 DF20 B2DC 9C1B


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

Penging ACLs - 06 Aug 2016

[Fabio Alessandro Locati]

Hello everyone,

As promised in the previous email thread, I've updated my db with today
dump and I've improved the query to exclude watchbugzilla and
watchcommits reuqests.

Please take care of your ACL requests!
You should be able to see those in:

  https://admin.fedoraproject.org/pkgdb/acl/pending/

However it seems like sometimes they do not show up (I pinged Pingou
about it).

263 cwickert
123 bkabrda
106 patches
92  anishpatil
89  devrim
78  salimma
62  laxathom
57  mtasaka
50  mmorsi
43  chkr
41  huzaifas
41  goldmann
39  timn
34  ausil
31  hvad
31  mmahut
30  willb
30  sxw
29  dcallagh
27  mclasen
27  lystor
25  pwouters
25  rmeggins
25  nhosoi
25  amigadave
25  awjb
24  adev
24  corsepiu
24  ralph
23  nkinder
21  mfojtik
21  fnasser
21  rishi
21  yyang
20  nb
20  jsteffan
19  jcapik
19  steve
19  mharmsen
19  tieugene
19  jamielinux
19  dwmw2
18  apevec
18  dsd
18  pbrobinson
17  sdz
17  dvratil
17  gomix
16  dwalluck
16  tomprince
16  brouhaha
16  mebrown
16  smilner
16  jskarvad
15  gecko-maint
15  walters
15  thias
15  dwalsh
15  vcrhonek
15  otaylor
15  kanarip
14  gholms
14  flaper87
14  s4504kr
14  jstanley
14  sgallagh
13  lucilanga
13  tagoh
13  jvcelak
13  rlandmann
13  xavierb
13  spike
13  stingray
12  mbarnes
12  elwell
12  susmit
12  chitlesh
12  sophiekovalevsky
12  weli
12  bpepple
12  melmorabity
12  caillon
12  kylev
12  npmccallum
12  geoff
12  elad
12  dcbw
12  pvoborni
11  fkocina
11  thomasvs
11  richardfearn
11  oron
11  tuxbrewr
11  madko
10  dmach
10  steved
10  zaitcev
10  tdabasin
10  potty
10  imcleod
10  clalance
10  giallu
10  fkluknav
10  jamielennox
9   rclark
9   cjb
9   nucleo
9   gemi
9   shreyankg
9   jklimes
9   stransky
9   pmatilai
9   uraeus
9   larsks
9   msivak
9   whot
9   ajax
9   stevetraylen
9   hubbitus
9   erikos
9   praveenp
9   mgrepl
9   sundaram
8   puiterwijk
8   radez
8   jeckersb
8   lmacken
8   petersen
8   echevemaster
8   sseago
8   averi
8   jaruga
7   timj
7   lsm5
7   abo
7   terminalmage
7   mchehab
7   djuran
7   abbot
6   jistone
6   zironid
6   sadmac
6   matriux
6   pmachata
6   john2583
6   ianweller
6   rvokal
6   phatina
6   aalam
6   robmv
6   izhar
6   pfrankli
6   nathans
6   ingvar
6   ellert
6   fche
6   elanthis
6   rcritten
6   hpejakle
6   lzap
6   radford
6   lberk
6   peter
6   zeenix
6   cleech
6   alvesadrian
6   matthicksj
6   anttix
6   bkearney
6   ivazquez
6   tomeu
6   drsmith2
6   jstanek
6   dbhole
6   jpo
6   wcohen
6   skottler
6   ewan
6   tonet666p
6   twoerner
6   alcapcom
6   cerberus
6   rspanton
6   wolfy
6   nushio
6   jgarzik
6   sgrubb
6   renich
6   pravins
6   rmyers
6   lennart
6   mstuchli
6   scox
6   mjw
6   firnsy
6   karsten
6   mhlavink
5   rohara
5   ndipanov
5   jcp
5   somlo
5   filiperosset
5   pavlix
5   delete
5   sross
5   tbreeds
5   sejeff
5   nsantos
5   adalloz
5   ixs
5   mikeb
5   alikins
5   jjh
5   ssalevan
5   strobert
5   dougsland
4   rajalakshmi
4   toshio
4   denisarnaud
4   mdomsch
4   rcurtin
4   nbecker
4   besser82
4   than
4   nacho
4   daveisfera
4   aviram
3   oliver
3   dwrobel
3   abompard
3   beckerde
3   mso
3   veillard
3   vbatts
3   kjaleel
3   katzj
3   olea
3   linuxdonald
3   ssp
3   rakesh
3   williamjmorenor
3   hicham
3   mathstuf
3   jdennis
3   leonn
3   itamarjp
3   tomspur
3   davidx
3   yselkowitz
3   jlaska
3   xhorak
3   neugens
3   marx
3   krege
3   amluto
3   omajid
3   jamesni
3   bentiss
3   alexises
3   fonts-sig
3   perex
3   kevin
3   magcius
3   zoglesby
3   jsynacek
3   jussilehtola
3   elsupergomez
3   xinwu
3   mmuzila
3   zpavlas
3   pjp
3   jbernard
3   bioinfornatics
3   johnp
3   dwayne
3   nalin
3   meyering
3   rkennke
3   fabiand
3   pjones
3   hhorak
3   alexl
3   jimi
3   pbrady
3   rjones
3   cbb
3   gerd
3   dborkmann
3   jbowes
3   nkumar
3   svashisht
3   junghans
3   

Re: Pending ACLs

[Fabio Alessandro Locati]

On Fri, Aug 05, 2016 at 03:34:58PM +0200, Helio Chissini de Castro wrote:
> I have a strong opinion over this
> 
> All the ACL's should be accepted, doesn't matter the level.
> And why i think of this ?
> 
> Two simple reasons:
> - The packager abandoned the package, because several reasons, and then is
> far away from Fedora systems for some time
> - The packager is actively using Fedora, but seen not care to even properly
> take care of his package, not in the minimal sense to deny the ACL, which
> would be acceptable.
> 
> In both cases, the package became hostage to someone that for sure aren't
> caring much for the distro, unless prove me wrong.

Hi,

On one hand I agree with you, on the other hand I do think that
sometimes pkgdb notifications are not so visible and therefore someone
could inadvertly loose track of some notifications and with your
proposal, this would trigger an auto-approval.

Best,
Fale
-- 
Fabio Alessandro Locati
Red Hat - Senior Consultant

PGP Fingerprint: E815 3C49 2A8D FD8B 1CBD  BC85 FDB3 DF20 B2DC 9C1B


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

Re: Fedora IRC channels on FreeNode

[Kevin Fenzi]

On Sat, 6 Aug 2016 07:24:51 +0100
"Richard W.M. Jones"  wrote:

> On Fri, Aug 05, 2016 at 04:29:19PM -0600, Kevin Fenzi wrote:
> > On Fri, 5 Aug 2016 22:10:14 +0100
> > "Richard W.M. Jones"  wrote:
> >   
> > > I might have imagined this, but I'm sure I read that the Fedora
> > > Project reserves all/some #fedora-* channels on FreeNode.
> > > 
> > > Anyway if this is true, I'd like to request that the Fedora
> > > Project reserves #fedora-riscv
> > > 
> > > The question is .. how?  
> > 
> > It's self service:
> > https://infrastructure.fedoraproject.org/infra/docs/freenode-irc-channel.rst
> >   
> 
> Thanks.  I added you & spot as co-admins, hope that's OK.

Sure, happy to help out if needed. 

kevin


pgp6mINrpuhea.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Alias-1.20-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.x86_64 requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Data-Alias-1.20-2.fc24.i686 requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Data-Alias-1.20-2.fc24.armv7hl requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.armv7hl requires perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

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

[Test-Announce] Fedora 25 Branched 20160806.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 25 Branched 20160806.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
python-blivet - 20160803.n.0: python-blivet-2.1.1-2.fc25.src, 20160806.n.0: 
python-blivet-2.1.2-1.fc25.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/25

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160806.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160806.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160806.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160806.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160806.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160806.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160806.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relval: https://www.happyassassin.net/relval/
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora IRC channels on FreeNode

[Richard W.M. Jones]

On Fri, Aug 05, 2016 at 04:29:19PM -0600, Kevin Fenzi wrote:
> On Fri, 5 Aug 2016 22:10:14 +0100
> "Richard W.M. Jones"  wrote:
> 
> > I might have imagined this, but I'm sure I read that the Fedora
> > Project reserves all/some #fedora-* channels on FreeNode.
> > 
> > Anyway if this is true, I'd like to request that the Fedora Project
> > reserves #fedora-riscv
> > 
> > The question is .. how?
> 
> It's self service:
> https://infrastructure.fedoraproject.org/infra/docs/freenode-irc-channel.rst

Thanks.  I added you & spot as co-admins, hope that's OK.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org