Re: Plans for Matplotlib 3.0+

[Elliott Sales de Andrade]

On Fri, 17 Aug 2018 at 18:42, Miro Hrončok  wrote:

> On 17.8.2018 21:51, Elliott Sales de Andrade wrote:
> > On Fri, 17 Aug 2018 at 15:18, Miro Hrončok  > > wrote:
> >
> >
> >
> > On 17.8.2018 20:20, José Abílio Matos wrote:
> >  > On Friday, 17 August 2018 18.54.59 WEST Miro Hrončok wrote:
> >  >> Is there an upstream schedule? That would very much help us to
> > determine
> >  >> if this is F29 material.
> >  >
> >  > You know the answer: when it is ready. :-)
> >  >
> >  > Now on more serious note and judging from the previous releases I
> > would expect
> >  > this to be release in 3 to 5 weeks (see the time difference
> > between the last
> >  > rc release and the official release):
> >  > https://github.com/matplotlib/matplotlib/releases
> >  >
> >  > Or can always ask to Thomas, the matplotlib leader. :-)
> >
> > OK, let's just do this in rawhide only and only push to f29 if the
> > release is not too late?
> >
> >
> > At the moment, there are some issues to work out with the new automatic
> > backend selection:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=29102643
> > but otherwise, I don't see any major issues.
>
> Oh. So you have this ready? Can you open a WIP pull request for review?
> I was just starting to dig into the specfile.
>
>
Opened https://src.fedoraproject.org/rpms/python-matplotlib/pull-request/9
for 3.0.0rc2. I believe there are still issues with the backend tests.


> BTW I've invited you to https://github.com/fedora-python/matplotlib so
> we can have the patches in Fedora manged github org.
>

Yep, I noticed that and have pushed the patches there already.


>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>

-- 
Elliott
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27) - js-jqeury1

[Christopher]

On Tue, Aug 28, 2018 at 10:44 AM Vít Ondruch  wrote:

>
>
> Dne 28.8.2018 v 15:58 Christopher napsal(a):
>
> On Tue, Aug 28, 2018 at 8:49 AM Vít Ondruch  wrote:
>
>>
>> So this is the email announcing orphaning js-jquery1:
>>
>>
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MI7W7TT3MUGMQTLYZYE5FKXUJCKFUXU7/
>>
>> But apparently it is used by more packages then just a few. So is there
>> somebody, who would be willing (more than me) to keep the package alive?
>>
>>
>> V.
>>
>>
> Given the security vulnerabilities in jQuery 1 (and 2) and the fact that
> upstream dropped them a long time ago, I strongly recommend the packages be
> retired than kept alive. Packagers depend on the newer js-jquery (3)
> instead, patching as needed.
>
>
> Of course I see your point. Nevertheless, I still believe that it is
> better to have the CVEs in one package where they will be eventually fixed
> then spread across the whole Fedora bundled in all packages, because I am
> quite sure this will be the result of retiring js-jquery1.
>
>
That's fair.


> Speaking of the two rubygem- packages from the list:
>
> 1. rubygem-cucumbe is going to be migrated to the latest jQuery. Anyway,
> this is testing framework, so I don't see the old and vulnerable jQuery as
> a big deal.
>
> 2. I opened ticket to migrate rubygem-apipie-rails to the most recent
> version of jQuery, but I don't think it is going to happen soon. Also, it
> is probably used in some generated documentation, not sure how critical the
> old jQuery is.
>
> And in addition:
>
> 3. There is jQuery embedded in every rubygem-*-doc package from
> rubygem-rdoc. You can use it as and example of bundling. But anyway, this
> is again "just" documentation, if used, then typically used just locally
> (although somebody might expose the documentation externally).
>
> V.
>
>
> [1] https://github.com/Apipie/apipie-rails/issues/628
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Dan Callaghan]

Excerpts from Zbigniew Jędrzejewski-Szmek's message of 2018-08-28 08:38 +00:00:
> On Tue, Aug 28, 2018 at 04:56:58PM +1000, Dan Callaghan wrote:
> > What does it mean for a package to be owned by orphan while it still 
> > has other admins who are real people?
> > 
> > Is this some kind of edge case where the package was owned by 
> > a maintainer who was inactive, and thus their packages got "orphaned", 
> > even though there are still other maintainers? Is there any record where 
> > we can see when or why these changes were made?
> 
> Hi,
> 
> FESCo voted yesterday to "send info to all co-maintainers and
> fedora-devel, [...] after a week reassign to one co-maintainer, if no
> co-maintainers, retire". The text in Till's mail was not adjusted to
> reflect this. Nevertheless, the plan is to do what was voted.
> 
> The reason why we don't just reassign all packages to co-maintainers
> right now is that often it's not clear which if any of the other
> maintainers are active. So in this first round we ask people to
> take ownership explicitly, and will do the automatic procedure for
> the rest.
> 
> > And is the solution here that one of the existing co-maintainers should 
> > just go into the Pagure settings and click... some button to become the 
> > "main admin" so that it's no longer orphaned?
> 
> Unfortunately there is no "button" in pagure, and the process to take
> a package is a manual releng ticket.
> 
> Yeah, it's all quite a bit more manual and messy than it should be.

Thanks for the explanation, this was the context I was missing.

I have filed a ticket about reassigning python-configobj, we can sort it 
out between the existing co-maintainers (whichever are still active) in 
the ticket:

https://pagure.io/releng/issue/7727

-- 
Dan Callaghan 
Senior Software Engineer, Products & Technologies DevOps
Red Hat


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Rawhide python3-devel conflict issue

[Robert-André Mauchin]

On mardi 28 août 2018 22:24:09 CEST BJH2017 wrote:
> Hi,
> 
> I build Vim (bleeding-edge package, updated within a day of the latest
> upstream release) for Fedora Rawhide, among many other platforms,
> using the openSUSE Build Service and the delightful issue I've found
> is that python3-devel cannot be installed by the OBS due to a conflict
> between python3-rpm-generators and python-rpm-macros. If you suggest I
> should ask the OBS developers for help on this don't bother because
> I've asked them and they've told me this is an upstream issue you
> folks need to fix. This issue has existed for over a week now, so it'd
> be delightful if it could be fixed.
> 
> Thanks for your time and patience,
> Brenton
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Here we go: you have created a python-rpm-macros repository: 

https://build.opensuse.org/package/binaries/home:fusion809/python-rpm-macros/Fedora_Rawhide

which is used during your vim build.

Thus it leads to this issue:

package python3-rpm-generators-5-4.fc29.noarch conflicts with python-rpm-macros 
< 3-35 provided by python-rpm-macros-3-12.237.noarch

python-rpm-generators was modified a month ago to add:

26 + # Breaking change, change a way how depgen is enabled
27 + Conflicts:  python-rpm-macros < 3-35

Thus the problem only appeared recently.

The solution would be to either delete your python-rpm-macros or update it to 
the latest version.

Best regards,

Robert-André

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] 2018-08-29 EPEL Steering Committee Meeting Agenda

[Stephen John Smoogen]

#startmeeting EPEL (2018-08-29)
#meetingname epel
#topic Chair and Introductions
#chair avij bstinson Evolution nirik smooge

#topic Emergency Business
#info This is where items needing to be discussed right away go

#topic EL-6 end of life
#info EL-6 will be reaching its end of life in late 2020.

#topic EL-7.6 beta
#info time to update/remove packages

#topic certbot is broke due to EL7.5 conflicts

#topic gnome-shell-extension-dash-to-dock in EPEL works / 7.5 broke?

#topic FLOCK 2018 Report (nirik)

#topic EPEL/EPIC proposal
#info where do I file a change request?
#info dealing with centos-extras conflicts? EPEL-supplemental?
#info next

#topic Next Meeting
#info Scheduled for 2018-09-12
#info Need agenda items

#topic Open Floor

-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Heads-up: ImageMagick SONAME bump

[Michael Cronenworth]

On 08/28/2018 01:34 PM, Michael Cronenworth wrote:
ImageMagick 6.9.9 => 6.9.10 introduces a SONAME bump from .so.5 to .so.6. I'll 
rebuild what I can, but please help out if you have some spare cycles. Owners have 
been BCC'd. 


Rebuilds are complete. A handful of FTBFS bugs have been filed. Many packages were 
already FTBFS.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL-7 x86_64 repoclosure failure

[Eli Young]

Slight correction: both python2-crypto and python2-libcomps exist in upstream 
as python2-*. I got confused while generating the list because they both have 
previous versions in upstream as python-*, but those have been obsoleted by 
newer packages with name python2-*. As a result, removing them from EPEL isn't 
as important as removing (or at least replacing with dummy packages) the other 
packages that actually are in upstream as python-* and in EPEL as python2-*, 
like python2-s3transfer.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL-7 x86_64 repoclosure failure

[Eli Young]

Breaking it down a bit more, the following EPEL7 packages are in the CentOS 7.5 
base and/or updates repositories:

cloud-utils-growpart
finch
finch-devel
fio
gnome-shell-extension-dash-to-dock
golang-github-godbus-dbus-devel
hsakmt
hsakmt-devel
ima-evm-utils
ima-evm-utils-devel
libappindicator
libappindicator-devel
libappindicator-docs
libappindicator-gtk3
libappindicator-gtk3-devel
libdbusmenu
libdbusmenu-devel
libdbusmenu-doc
libdbusmenu-gtk2
libdbusmenu-gtk2-devel
libdbusmenu-gtk3
libdbusmenu-gtk3-devel
libdbusmenu-jsonloader
libdbusmenu-jsonloader-devel
libdbusmenu-tools
libdnet
libdnet-devel
libdnet-progs
libdnet-python
libindicator
libindicator-devel
libindicator-gtk3
libindicator-gtk3-devel
libindicator-gtk3-tools
libindicator-tools
libmspack
libmspack-devel
libnetfilter_cthelper
libnetfilter_cthelper-devel
libnetfilter_cttimeout
libnetfilter_cttimeout-devel
libntlm
libntlm-devel
libpmem
libpmem-devel
libpmemblk
libpmemblk-devel
libpmemlog
libpmemlog-devel
libpmemobj
libpmemobj-devel
libpmempool
libpmempool-devel
librepo
librepo-devel
libsmbios
libsmbios-devel
libva
libva-devel
libvmem
libvmem-devel
libvmmalloc
libvmmalloc-devel
libvncserver
libvncserver-devel
lz4
lz4-devel
lz4-static
memkind
memkind-devel
mpg123
mpg123-devel
mpg123-libs
mpg123-plugins-pulseaudio
nvml-tools
perl-Crypt-PasswdMD5
pidgin
pidgin-devel
pidgin-perl
python-appindicator
python-isodate
python-librepo
python-oauthlib
python-smbios
python2-adal*
python2-azure-sdk*
python2-boto3*
python2-msrest*
python2-msrestazure*
python2-s3transfer*
smbios-utils
smbios-utils-bin
smbios-utils-python
tpm2-tools
tpm2-tss
tpm2-tss-devel

And the following are in the CentOS 7.5 extras repository:

WALinuxAgent
ansible
ansible-doc
clang
clang-analyzer
clang-devel
cloud-utils
createrepo_c
createrepo_c-devel
createrepo_c-libs
epel-release
euca2ools
koji
koji-builder
koji-hub
koji-hub-plugins
koji-utils
koji-vm
koji-web
libcomps
libcomps-devel
libcomps-doc
libev
libev-devel
libev-libevent-devel
libev-source
libtomcrypt
libtomcrypt-devel
libtomcrypt-doc
libtommath
libtommath-devel
libtommath-doc
lldb
lldb-devel
llvm
llvm-devel
llvm-doc
llvm-libs
llvm-ocaml
llvm-ocaml-devel
llvm-ocaml-doc
llvm-static
mock
mock-lvm
mock-scm
pigz
python-cheetah
python-construct
python-httplib2
python-libcomps-doc
python-lockfile
python-markdown
python-multilib-conf
python-munch
python-paramiko
python-paramiko-doc
python-passlib
python-pyelftools
python-qpid-proton-docs
python-requests-kerberos
python-saslwrapper
python2-boto*
python2-createrepo_c*
python2-crypto*
python2-ecdsa*
python2-jmespath
python2-koji
python2-koji-cli-plugins
python2-libcomps*
python2-multilib
python2-pytoml*
python2-qpid*
python2-qpid-proton*
python2-sphinx-theme-alabaster*
qpid-proton-c
qpid-proton-c-devel
qpid-proton-c-docs
qpid-proton-cpp
qpid-proton-cpp-devel
qpid-proton-cpp-docs
ruby-saslwrapper
saslwrapper
saslwrapper-devel
sshpass
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[Bug 1623265] CVE-2011-2767 mod_perl: arbitrary Perl code execution in the context of the user account via a user-owned .htaccess

[bugzilla]

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

Laura Pardo  changed:

   What|Removed |Added

 Blocks||1623271



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Rawhide python3-devel conflict issue

[Robert-André Mauchin]

On mardi 28 août 2018 22:24:09 CEST BJH2017 wrote:
> Hi,
> 
> I build Vim (bleeding-edge package, updated within a day of the latest
> upstream release) for Fedora Rawhide, among many other platforms,
> using the openSUSE Build Service and the delightful issue I've found
> is that python3-devel cannot be installed by the OBS due to a conflict
> between python3-rpm-generators and python-rpm-macros. If you suggest I
> should ask the OBS developers for help on this don't bother because
> I've asked them and they've told me this is an upstream issue you
> folks need to fix. This issue has existed for over a week now, so it'd
> be delightful if it could be fixed.
> 
> Thanks for your time and patience,
> Brenton
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

I can't reproduce in Rawhide:

Dependencies resolved.

 Package

Installing:
 python3-devel  
Installing dependencies:
 python-rpm-macros  
 python3
 python3-rpm-generators  
 python3-rpm-macros  
 python3-setuptools  

Transaction Summary
=
Install  6 Packages

Total size: 1.5 M
Total download size: 1.5 M
Installed size: 5.6 M
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing:
  Installing   : python3-setuptools-39.2.0-7.fc30.noarch
  Installing   : python3-rpm-generators-5-4.fc29.noarch
  Installing   : python3-rpm-macros-3-37.fc30.noarch
  Installing   : python-rpm-macros-3-37.fc30.noarch
  Installing   : python3-devel-3.7.0-8.fc30.x86_64 
  Running scriptlet: python3-devel-3.7.0-8.fc30.x86_64
  Verifying: python-rpm-macros-3-37.fc30.noarch
  Verifying: python3-3.7.0-8.fc30.x86_64
  Verifying: python3-devel-3.7.0-8.fc30.x86_64
  Verifying: python3-rpm-generators-5-4.fc29.noarch
  Verifying: python3-rpm-macros-3-37.fc30.noarch
  Verifying: python3-setuptools-39.2.0-7.fc30.noarch

Complete!


Both python3-rpm-generators and python-rpm-macros install together and there 
was no new recent builds that might explain a conflict.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1623267] CVE-2011-2767 mod_perl: arbitrary Perl code execution in the context of the user account via a user-owned .htaccess [fedora-all]

[bugzilla]

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

Laura Pardo  changed:

   What|Removed |Added

 Blocks||1623265 (CVE-2011-2767)




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1623265
[Bug 1623265] CVE-2011-2767 mod_perl: arbitrary Perl code execution in the
context of the user account via a user-owned .htaccess
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1623265] CVE-2011-2767 mod_perl: arbitrary Perl code execution in the context of the user account via a user-owned .htaccess

[bugzilla]

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

Laura Pardo  changed:

   What|Removed |Added

 Depends On||1623268, 1623267, 1623269



--- Comment #1 from Laura Pardo  ---
Created mod_perl tracking bugs for this issue:

Affects: epel-7 [bug 1623268]
Affects: fedora-all [bug 1623267]


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1623267
[Bug 1623267] CVE-2011-2767 mod_perl: arbitrary Perl code execution in the
context of the user account via a user-owned .htaccess [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1623268
[Bug 1623268] CVE-2011-2767 mod_perl: arbitrary Perl code execution in the
context of the user account via a user-owned .htaccess [epel-7]
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1623268] CVE-2011-2767 mod_perl: arbitrary Perl code execution in the context of the user account via a user-owned .htaccess [epel-7]

[bugzilla]

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

Laura Pardo  changed:

   What|Removed |Added

 Blocks||1623265 (CVE-2011-2767)




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1623265
[Bug 1623265] CVE-2011-2767 mod_perl: arbitrary Perl code execution in the
context of the user account via a user-owned .htaccess
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1623268] CVE-2011-2767 mod_perl: arbitrary Perl code execution in the context of the user account via a user-owned .htaccess [epel-7]

[bugzilla]

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



--- Comment #1 from Laura Pardo  ---
Use the following template to for the 'fedpkg update' request to submit an
update for this issue as it contains the top-level parent bug(s) as well as
this tracking bug.  This will ensure that all associated bugs get updated
when new packages are pushed to stable.

=

# bugfix, security, enhancement, newpackage (required)
type=security

# testing, stable
request=testing

# Bug numbers: 1234,9876
bugs=1623265,1623268

# Description of your update
notes=Security fix for [PUT CVEs HERE]

# Enable request automation based on the stable/unstable karma thresholds
autokarma=True
stable_karma=3
unstable_karma=-3

# Automatically close bugs when this marked as stable
close_bugs=True

# Suggest that users restart after update
suggest_reboot=False

==

Additionally, you may opt to use the bodhi web interface to submit updates:

https://bodhi.fedoraproject.org/updates/new

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1623268] New: CVE-2011-2767 mod_perl: arbitrary Perl code execution in the context of the user account via a user-owned .htaccess [epel-7]

[bugzilla]

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

Bug ID: 1623268
   Summary: CVE-2011-2767 mod_perl: arbitrary Perl code execution
in the context of the user account via a user-owned
.htaccess [epel-7]
   Product: Fedora EPEL
   Version: epel7
 Component: mod_perl
  Keywords: Security, SecurityTracking
  Severity: medium
  Priority: medium
  Assignee: ppi...@redhat.com
  Reporter: lpa...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jkal...@redhat.com, jor...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com




This is an automatically created tracking bug!  It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of epel-7.

For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.

For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs

When submitting as an update, use the fedpkg template provided in the next
comment(s).  This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.

Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1623267] New: CVE-2011-2767 mod_perl: arbitrary Perl code execution in the context of the user account via a user-owned .htaccess [fedora-all]

[bugzilla]

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

Bug ID: 1623267
   Summary: CVE-2011-2767 mod_perl: arbitrary Perl code execution
in the context of the user account via a user-owned
.htaccess [fedora-all]
   Product: Fedora
   Version: 28
 Component: mod_perl
  Keywords: Security, SecurityTracking
  Severity: medium
  Priority: medium
  Assignee: ppi...@redhat.com
  Reporter: lpa...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jkal...@redhat.com, jor...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com




This is an automatically created tracking bug!  It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-all.

For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.

For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs

When submitting as an update, use the fedpkg template provided in the next
comment(s).  This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.

Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.

NOTE: this issue affects multiple supported versions of Fedora. While only
one tracking bug has been filed, please correct all affected versions at
the same time.  If you need to fix the versions independent of each other,
you may clone this bug as appropriate.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1623267] CVE-2011-2767 mod_perl: arbitrary Perl code execution in the context of the user account via a user-owned .htaccess [fedora-all]

[bugzilla]

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



--- Comment #1 from Laura Pardo  ---
Use the following template to for the 'fedpkg update' request to submit an
update for this issue as it contains the top-level parent bug(s) as well as
this tracking bug.  This will ensure that all associated bugs get updated
when new packages are pushed to stable.

=

# bugfix, security, enhancement, newpackage (required)
type=security

# testing, stable
request=testing

# Bug numbers: 1234,9876
bugs=1623265,1623267

# Description of your update
notes=Security fix for [PUT CVEs HERE]

# Enable request automation based on the stable/unstable karma thresholds
autokarma=True
stable_karma=3
unstable_karma=-3

# Automatically close bugs when this marked as stable
close_bugs=True

# Suggest that users restart after update
suggest_reboot=False

==

Additionally, you may opt to use the bodhi web interface to submit updates:

https://bodhi.fedoraproject.org/updates/new

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1623265] New: CVE-2011-2767 mod_perl: arbitrary Perl code execution in the context of the user account via a user-owned .htaccess

[bugzilla]

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

Bug ID: 1623265
   Summary: CVE-2011-2767 mod_perl: arbitrary Perl code execution
in the context of the user account via a user-owned
.htaccess
   Product: Security Response
 Component: vulnerability
  Keywords: Security
  Severity: medium
  Priority: medium
  Assignee: security-response-t...@redhat.com
  Reporter: lpa...@redhat.com
CC: hho...@redhat.com, jkal...@redhat.com,
jor...@redhat.com, perl-devel@lists.fedoraproject.org,
perl-maint-l...@redhat.com, ppi...@redhat.com



A flaw was found in mod_perl 2.0 through 2.0.10 which allows attackers to
execute arbitrary Perl code by placing it in a user-owned .htaccess file,
because (contrary to the documentation) there is no configuration option that
permits Perl code for the administrator's control of HTTP request processing
without also permitting unprivileged users to run Perl code in the context of
the user account that runs Apache HTTP Server processes.


References:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644169

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL-7 x86_64 repoclosure failure

[Eli Young]

I did a bit more digging and found that the following packages in EPEL7 also 
exist in upstream CentOS 7.5. Note that many of the python2-* packages are in 
upstream as python-*. I have marked these with a * at the end. These are 
particularly troublesome because, while fully-overlapping names is suboptimal, 
partially-overlapping names that provide the same actual package leads to 
issues like [1] and [2].

WALinuxAgent
ansible
ansible-doc
clang
clang-analyzer
clang-devel
cloud-utils
cloud-utils-growpart
createrepo_c
createrepo_c-devel
createrepo_c-libs
epel-release
euca2ools
finch
finch-devel
fio
gnome-shell-extension-dash-to-dock
golang-github-godbus-dbus-devel
hsakmt
hsakmt-devel
ima-evm-utils
ima-evm-utils-devel
koji
koji-builder
koji-hub
koji-hub-plugins
koji-utils
koji-vm
koji-web
libappindicator
libappindicator-devel
libappindicator-docs
libappindicator-gtk3
libappindicator-gtk3-devel
libcomps
libcomps-devel
libcomps-doc
libdbusmenu
libdbusmenu-devel
libdbusmenu-doc
libdbusmenu-gtk2
libdbusmenu-gtk2-devel
libdbusmenu-gtk3
libdbusmenu-gtk3-devel
libdbusmenu-jsonloader
libdbusmenu-jsonloader-devel
libdbusmenu-tools
libdnet
libdnet-devel
libdnet-progs
libdnet-python
libev
libev-devel
libev-libevent-devel
libev-source
libindicator
libindicator-devel
libindicator-gtk3
libindicator-gtk3-devel
libindicator-gtk3-tools
libindicator-tools
libmspack
libmspack-devel
libnetfilter_cthelper
libnetfilter_cthelper-devel
libnetfilter_cttimeout
libnetfilter_cttimeout-devel
libntlm
libntlm-devel
libpmem
libpmem-devel
libpmemblk
libpmemblk-devel
libpmemlog
libpmemlog-devel
libpmemobj
libpmemobj-devel
libpmempool
libpmempool-devel
librepo
librepo-devel
libsmbios
libsmbios-devel
libtomcrypt
libtomcrypt-devel
libtomcrypt-doc
libtommath
libtommath-devel
libtommath-doc
libva
libva-devel
libvmem
libvmem-devel
libvmmalloc
libvmmalloc-devel
libvncserver
libvncserver-devel
lldb
lldb-devel
llvm
llvm-devel
llvm-doc
llvm-libs
llvm-ocaml
llvm-ocaml-devel
llvm-ocaml-doc
llvm-static
lz4
lz4-devel
lz4-static
memkind
memkind-devel
mock
mock-lvm
mock-scm
mpg123
mpg123-devel
mpg123-libs
mpg123-plugins-pulseaudio
nvml-tools
perl-Crypt-PasswdMD5
pidgin
pidgin-devel
pidgin-perl
pigz
python-appindicator
python-cheetah
python-construct
python-httplib2
python-isodate
python-libcomps-doc
python-librepo
python-lockfile
python-markdown
python-multilib-conf
python-munch
python-oauthlib
python-paramiko
python-paramiko-doc
python-passlib
python-pyelftools
python-qpid-proton-docs
python-requests-kerberos
python-saslwrapper
python-smbios
python2-adal*
python2-azure-sdk*
python2-boto*
python2-boto3*
python2-createrepo_c*
python2-crypto*
python2-ecdsa*
python2-jmespath
python2-koji
python2-koji-cli-plugins
python2-libcomps*
python2-msrest*
python2-msrestazure*
python2-multilib
python2-pytoml*
python2-qpid*
python2-qpid-proton*
python2-s3transfer*
python2-sphinx-theme-alabaster*
qpid-proton-c
qpid-proton-c-devel
qpid-proton-c-docs
qpid-proton-cpp
qpid-proton-cpp-devel
qpid-proton-cpp-docs
ruby-saslwrapper
saslwrapper
saslwrapper-devel
smbios-utils
smbios-utils-bin
smbios-utils-python
sshpass
tpm2-tools
tpm2-tss
tpm2-tss-devel

[1]: https://github.com/certbot/certbot/issues/6314
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1578071
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Rawhide python3-devel conflict issue

[Miro Hrončok]

On 28.8.2018 22:24, BJH2017 wrote:

Hi,

I build Vim (bleeding-edge package, updated within a day of the latest
upstream release) for Fedora Rawhide, among many other platforms,
using the openSUSE Build Service and the delightful issue I've found
is that python3-devel cannot be installed by the OBS due to a conflict
between python3-rpm-generators and python-rpm-macros. If you suggest I
should ask the OBS developers for help on this don't bother because
I've asked them and they've told me this is an upstream issue you
folks need to fix. This issue has existed for over a week now, so it'd
be delightful if it could be fixed.


Hi Brenton,

It would help if you provide details. E.g. what conflict are you 
getting, what version of packages are there, etc...


Also, to report a bug, use bugzilla:

https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=rawhide=python3

https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=rawhide=python-rpm-macros

https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=rawhide=python-rpm-generators

(Either will do, we can sort that out.)

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Rawhide python3-devel conflict issue

[BJH2017]

Hi,

I build Vim (bleeding-edge package, updated within a day of the latest
upstream release) for Fedora Rawhide, among many other platforms,
using the openSUSE Build Service and the delightful issue I've found
is that python3-devel cannot be installed by the OBS due to a conflict
between python3-rpm-generators and python-rpm-macros. If you suggest I
should ask the OBS developers for help on this don't bother because
I've asked them and they've told me this is an upstream issue you
folks need to fix. This issue has existed for over a week now, so it'd
be delightful if it could be fixed.

Thanks for your time and patience,
Brenton
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Idea: let's use Pagure to track Changes

[Brian (bex) Exelbierd]

On Fri, Aug 24, 2018 at 6:39 AM, Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Thu, Aug 23, 2018 at 11:52:57PM +0200, Miro Hrončok wrote:
> > On 23.8.2018 22:43, Ben Cotton wrote:
> > >Hi community,
> > >
> > >We've traditionally used the wiki for Change proposals because it's
> > >the tool we had. But, it's not necessarily well-suited to the purpose.
> > >But now we have Pagure, which can help address some of the
> > >shortcomings of using the wiki: poor scriptability, no reporting, and
> > >a lot of copy/paste.
> >
> > Good idea!
> >
> > >So I've come up with a plan that would use Pagure instead:
> > >https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges
> >
> > > 6. FESCo votes on change.
> >
> > On the Pagure ticket with the change or in a separate FESCo Pagure
> ticket?
>
> I think we should vote in the Change bug. I don't see advantages to
> opening a new ticket.
>
> > >You can read the full details on the wiki page above, but the general
> > >idea is that we won't change the policy for Changes, just how we store
> > >and manipulate them. My intent is to make it nearly seamless for the
> > >community while giving us a platform for building on the process in
> > >the future. Note that this would run parallel to Bugzilla for a
> > >release or two and then replace Bugzilla for Changes tracking.
> >
> > The good thing about Bugzilla trackers is that they can be used
> > as... Bugzilla trackers. I mean you can block/depend other bugs on
> > it.
> >
> > See for example http://bugzilla.redhat.com/show_bug.cgi?id=PYTHON37
> > and the dependent bugs. Of course, this might be relevant to some
> > kind of Changes only, so the Bugzilla tracker can be optional, but
> > I'd rather keep it as part of the process.
>
> I think we might want to make it an optional element. If the Change
> needs a tracking bug, create it, otherwise not. I think most Changes
> don't do any real tracking in bugzilla, except to change the bug as
> "done" at some point.
>
>
> One more thing that I didn't see explicitly mentioned in the proposal
> is the fact that Change pages are also documentation, fairly widely
> accessed, also long after the Change has been implemented. For this,
> the fact that the Change page show no context by default is an advantage.
> I wonder if we could request an enhancement to pagure to have a view
> where just the main text is shown, without the side bar, comments,
> headers, etc.
>

It'd be great if we could end this practice by having our documentation
updated as a part of the change.  Consumers of our software shouldn't need
to know to check what will feel like "random" wiki pages to many of them
for more docs.

regards,

bex


>
> Also, it should be clarified if Change owners should edit the original
> text.
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
> fedoraproject.org/message/VSTCNQXOVJWSOJQBE6CXAIJ3XUMKFVDM/
>



-- 
Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads-up: ImageMagick SONAME bump

[Adam Williamson]

On Tue, 2018-08-28 at 13:34 -0500, Michael Cronenworth wrote:
> ImageMagick 6.9.9 => 6.9.10 introduces a SONAME bump from .so.5 to .so.6. 
> I'll 
> rebuild what I can, but please help out if you have some spare cycles. Owners 
> have 
> been BCC'd.

This is STILL not how you are supposed to do this. You are supposed to
notify *at least a week before* you do the build, so people can plan
and test rebuilds. Not just do it and then send a mail out asking
people to fix the mess.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] Fedora 29 blocker review for this week

[Adam Williamson]

Hi folks! So, sorry I did not schedule or cancel a blocker review
meeting for this week - I kinda overlooked it, and also thought there
were fewer blockers to discuss than there actually are.

Problem is, I can't really run a blocker meeting any other day this
week either, as I'll be at Open Source Summit all week. So, I'm gonna
suggest two options. If someone else wants to pick a day and schedule
and run a blocker review meeting - please go ahead and do that! See the
SOP: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting .

Otherwise, can folks who usually participate in blocker review please
vote on the proposed blockers in-bug? Just add a comment to the bug
with your vote. You can see the lists here:

https://qa.fedoraproject.org/blockerbugs/milestone/29/beta/buglist

thanks a lot!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Heads-up: ImageMagick SONAME bump

[Michael Cronenworth]

ImageMagick 6.9.9 => 6.9.10 introduces a SONAME bump from .so.5 to .so.6. I'll 
rebuild what I can, but please help out if you have some spare cycles. Owners have 
been BCC'd.


dnf repoquery --whatrequires libMagickCore-6.Q16.so.5\(\)\(64bit\) 
--releasever=30:

WINGs-libs-0:0.95.8-10.fc29.x86_64
WindowMaker-0:0.95.8-10.fc29.x86_64
autotrace-0:0.31.1-52.fc29.x86_64
chafa-0:0.9.0-1.fc29.x86_64
converseen-0:0.9.6.2-9.fc29.x86_64
dmtx-utils-0:0.7.6-2.fc29.x86_64
drawtiming-0:0.7.1-28.fc29.x86_64
emacs-1:26.1-6.fc29.x86_64
emacs-lucid-1:26.1-6.fc29.x86_64
gtatool-imagemagick-0:2.2.0-11.fc28.x86_64
imageinfo-0:0.05-31.fc29.x86_64
inkscape-0:0.92.3-5.fc29.x86_64
inkscape-view-0:0.92.3-5.fc29.x86_64
kxstitch-0:2.0.0-4.fc28.x86_64
perl-Image-SubImageFind-0:0.03-17.fc29.x86_64
pfstools-0:2.0.6-8.fc29.x86_64
pfstools-imgmagick-0:2.0.6-8.fc29.x86_64
php-pecl-imagick-0:3.4.3-8.fc29.x86_64
psiconv-0:0.9.8-25.fc28.x86_64
python2-vips-0:8.6.5-2.fc29.x86_64
q-magick-0:7.11-33.fc29.x86_64
ripright-0:0.11-10.fc29.x86_64
rss-glx-0:0.9.1.p-35.fc29.x86_64
rubygem-rmagick-0:2.16.0-16.fc29.x86_64
synfig-0:1.2.1-3.fc28.x86_64
synfigstudio-0:1.2.1-3.fc28.x86_64
vdr-scraper2vdr-0:1.0.9-4.20180104gitef448e1.fc29.x86_64
vips-0:8.6.5-2.fc29.x86_64
vips-tools-0:8.6.5-2.fc29.x86_64

Thanks,
Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Maintenance of arbitrary branches of orphaned package

[Kevin Fenzi]

On 08/27/2018 04:24 PM, Mikolaj Izdebski wrote:
> Suppose I am main admin of a package which I would like to orphan in
> release branches, but keep maintaining the package in arbitrary [1]
> branches, which are used for building modules.  Would this considered
> as a valid approach?

I would think we should support it, yes.

> How should I handle orphaning the package in this case?  I can think
> of at least two possibilities:
> 1. Keep myself as admin and set bugzilla_contact for product Fedora to
>orphan.
> 2. Set orphan as main admin and demote myself to just admin.

Well, I would say 1 is better than 2, but also note that bugs may well
be misrouted here. I guess that they should be filed against the module,
but people might file them against the rpm component since thats what
they are used to, so having that be orphan with you watching it might be
ideal.

We could also try and improve our scripts here and close the rpm version
to new bugs with a note to file on the module? that would take some
coding however.

> In case no one adopts orphaned package and it is retired by Release
> Engineering, should commiters be still able to commit to non-retired
> arbitrary branches?  I assume yes, but I'd rather ask in advance.

I think yes... but not 100% sure.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Buildroot-only modules

[Kevin Fenzi]

On 08/27/2018 04:22 PM, Mikolaj Izdebski wrote:
> Some modules are built in MBS/Koji but are never released to users.
> Currently such modules can only be used as build dependencies of other
> modules.  In future, if solution like "ursa-major" [1] is implemented,
> such modules could also be used as build dependencies for non-modular
> packages.
> 
> An example of buildroot-only module is javapackages-tools.  This
> module is used as build dependency for 4 modules, but it is not
> included in any compose and it's not shipped to users.
> 
> Should such modules be considered as allowed in Fedora?  I am not
> aware of any policy that would disallow them, but I would rather ask
> in advance and not be surprised if one day I find out that I have to
> ship such modules to users and support them.

I'd say they were allowed. I would assume they would also be
downloadable / usable by others if they wanted to, but that doesn't mean
you would need to 'support' them.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [modularity] Managing module lifecycles — let's talk!

[Paul Frields]

On Wed, Aug 22, 2018 at 7:26 AM Adam Samalik  wrote:
> == Approaches
>
> Option 1: The current, yet unfinished approach
>
> We specify an EOL (end of life) date for each stream branch of individual 
> packages. This is done when requesting a new stream branch for a package [2] 
> by passing "--sl rawhide:2020-12-01" to fedpkg. This value is stored, but not 
> yet consumed by anything.
>
> The next step would be having the build system to be smart enough to:
>
> 1) Figure out the module's EOL based on its packages' EOLs.
> 2) Only build the module for the Fedora releases that have their EOL before 
> the module stream's EOL.
>
> There is a caveat, however:  Giving dates like this might be hard for the 
> maintainer. The upstream project might not have one, etc. In that case the 
> maintainer needs to come up with a date — even one closer in the future, and 
> increase it gradually (and think about it, and do it for all the packages), 
> or one much further in the future which could imply promises the maintainer 
> had no intention to make.
>
> Option 2: More dynamic, based on rawhide
>
> Simply put, we wouldn't specify an EOL as a date, but as a Fedora release. 
> And if a maintainer indicates that a certain stream branch of a package is 
> maintained in rawhide, it would mean it's maintained for all active Fedora 
> releases + the next one + potentially forever or until it's retired in 
> rawhide.
>
> The build system would then do the same thing as above:
>
> 1) Figure out the module's EOL based on its packages' EOLs.
> 2) Only build the module for the Fedora releases that have their EOL before 
> the module stream's EOL.

Would it be necessary for us to pick one or the other here? IOW,
whether the maintainer picked a specific date or a release, the EOL
would resolve to a date. If they pick none, or explicitly choose
'rawhide,' then the artifact is essentially on a rolling window.

It seems to me this is also an opportunity, through automation, to
converge some conventional package activities as well. So whether
dealing with a module or a conventional package, we might have the
opportunity to set a EOL date, a Fedora release, or nothing/rawhide.
The work of retiring packages or modules could be automated based on
specifying a date (with appropriate warnings to the maintainers and
public).

-- 
Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Mikolaj Izdebski]

On 08/28/2018 02:56 PM, Zamir SUN wrote:
> Seems zopfli is used for fedora-logos[1], and this causes a lot of
> package to be listed here.

I've just adopted rpms/zopfli.

> 
> I am just curious if there are any plan for fedora-logos to switch to
> new optimizing tools, or the better choice can be pickup zopfli again?
> 
> [1]
> https://src.fedoraproject.org/rpms/fedora-logos/blob/master/f/fedora-logos.spec#_30
> 

-- 
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: Alternative -devel packaging

[Nicolas Mailhot]

Le 2018-08-28 16:58, Vít Ondruch a écrit :


Just FTR, the logic is more or less there.

https://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping
https://pagure.io/packaging-committee/issue/789

together with:

https://src.fedoraproject.org/rpms/fedora-release/pull-request/7


I hadn't seen the PR, it's a nice enhancement over what guidelines 
already included. Kudos to everyone involved.



So as long as you do the boostrapping iteration first with "%global
boostrap 1", then the packages have the "~bootstrap" suffix, if you do
subsequent build without the %{boostrap} macro defined, the suffix is
omitted.


Having to set manually
  %global boostrap 1
is the missing part I had in mind.

You need build tool support to scale to language-wide or distro-wide 
mass rebuilds:
  1. you do not want to waste time building in bootstrap mode anything 
that could build directly in full mode
  2. you do not want humans to baby sit the progress of the whole mass 
rebuild


So the system should
  A. build by itself as much as possible without bootstrapping anything,
  B. if A does not succeed, try to solve holdovers (anything that failed 
build) with a bootstrap pass,
  C. if B succeeds, rebuild everything that built in B and includes 
bootstrap conditionals in full mode
  D. if A or C succeeded, rebuild everything against the result to make 
sure it is actually self hosting.


All this without human intervention to set a specific mode or select 
what to bootstrap or not.


(even without bootstrapping we should do the last D. part but I fear we 
often forget it expect for specific package sets where the maintainer 
has already been bitten)


Regards,

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Mikolaj Izdebski]

On 08/28/2018 06:04 PM, Jason L Tibbitts III wrote:
>> "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:
> 
> ZJ> Unfortunately there is no "button" in pagure, and the process to
> ZJ> take a package is a manual releng ticket.
> 
> If you're an admin then you can click the "Give the XXX project" button
> at the bottom.  That will change the "main admin", and I'm pretty sure
> you can use it to promote yourself from admin to main admin.

I don't think that's true. You can change main admin of any package
because you are cvsadmin, but others won't be able to do that.


-- 
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Jason L Tibbitts III]

> "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:

ZJ> Unfortunately there is no "button" in pagure, and the process to
ZJ> take a package is a manual releng ticket.

If you're an admin then you can click the "Give the XXX project" button
at the bottom.  That will change the "main admin", and I'm pretty sure
you can use it to promote yourself from admin to main admin.  But if
there are no remaining admins then obviously someone with privileges
would have to do it.  That's basically what happens when you file a
ticket in any case.

 - J<
 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 29 Beta Freeze

[Miro Hrončok]

On 28.8.2018 17:25, Fabio Valentini wrote:

On Tue, Aug 28, 2018 at 2:57 PM Mohan Boddu  wrote:


Hi all,

Today's an important day on the Fedora 29 schedule[1], with several significant 
cut-offs. First of all today is
the Bodhi activation point [2]. That means that from now all Fedora 29 packages 
must be submitted to
updates-testing and pass the relevant requirements[3] before they will be 
marked as 'stable' and moved to the
fedora repository.

Today is also the Beta freeze[4]. This means that only packages which fix 
accepted blocker or freeze exception
bugs[5][6] will be marked as 'stable' and included in the Beta composes. Other 
builds will remain in updates-
testing until the Beta release is approved, at which point the Beta freeze is 
lifted and packages can move to
'stable' as usual until the Final freeze.


So, does this mean that it is now too late to retire packages in
fedora 29 in addition to rawhide?

No. You can do that until the Final Freeze.

https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Adam Jackson]

On Tue, 2018-08-28 at 00:03 +0200, Till Maas wrote:

> waffle orphan 24 weeks ago  

Dependency for piglit, taken.

- ajax
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Golang SIG primary goals?

[Nicolas Mailhot]

Le 2018-08-28 13:49, Jakub Cajka a écrit :

Hi Jakub


I could spend some time on most of those (though I'd rather pass on B,
already done my part, and D/E would be the most fun and probably the
most useful for the rest of the SIG).


For B I would much appreciate if you would mark which parts of your
proposals got implemented and in which way. It would greatly help
anyone picking this topic after you. If you really do not plan to
finish all the work that you have started.


I'm pretty sure most of what's on the page is now done and can be used 
to package Go in Fedora (kudos to jchaloup who did a huge part of the 
work).


But sure, I'll make a pass to check if it contains references to stuff 
that turned out slightly differently than the initial plan


Regards,

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

f29-backgrounds theme ready for testing

[Luya Tshimbalanga]

Hello team,

f29-backgrounds is ready for testing towards Fedora 29 Beta release.

https://bodhi.fedoraproject.org/updates/desktop-backgrounds-29.0.0-1.fc29%20f29-backgrounds-29.0.0-2.fc29

Please rate it to push

to the stable repository. Thank you.

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 29 Beta Freeze

[Fabio Valentini]

On Tue, Aug 28, 2018 at 2:57 PM Mohan Boddu  wrote:
>
> Hi all,
>
> Today's an important day on the Fedora 29 schedule[1], with several 
> significant cut-offs. First of all today is
> the Bodhi activation point [2]. That means that from now all Fedora 29 
> packages must be submitted to
> updates-testing and pass the relevant requirements[3] before they will be 
> marked as 'stable' and moved to the
> fedora repository.
>
> Today is also the Beta freeze[4]. This means that only packages which fix 
> accepted blocker or freeze exception
> bugs[5][6] will be marked as 'stable' and included in the Beta composes. 
> Other builds will remain in updates-
> testing until the Beta release is approved, at which point the Beta freeze is 
> lifted and packages can move to
> 'stable' as usual until the Final freeze.

So, does this mean that it is now too late to retire packages in
fedora 29 in addition to rawhide?

Fabio

> Finally, Today is the '100% code complete deadline' Change Checkpoint[5], 
> meaning that Fedora 29 Changes
> must now be code complete, meaning all the code required to enable to the new 
> change is finished. The level
> of code completeness is reflected as tracker bug state ON_QA. The change does 
> not have to be fully tested
> by this deadline'.
>
> Finally, today is also the Software String freeze[7], which means that 
> strings marked for translation in Fedora-
> translated projects should not now be changed for Fedora 29.
>
> Mohan Boddu
>
> [1] https://fedoraproject.org/wiki/Releases/29/Schedule
> [2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
> [3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
> [4] https://fedoraproject.org/wiki/Milestone_freezes
> [5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
> [6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
> [7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1619655] Upgrade perl-Lingua-EN-Sentence to 0.31

[bugzilla]

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



--- Comment #1 from Ralf Corsepius  ---
Jitka, who do you think you are? 

With all due respect, I consider what you did here to be disrespectful and rude
and a provocation.

I neither welcome you spamming BZ with your "upgrade notices" nor do I welcome
you to touch my packages without waiting for feedback - Never do this again!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1622999] perl-POE-Component-SSLify-1.012-13.fc30 FTBFS: t/ connect_hook_nodata.t fails with OpenSSL 1.1.1

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-POE-Component-SSLify-1.012-14.fc29 has been submitted as an update to
Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3c95db499a

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1622999] perl-POE-Component-SSLify-1.012-13.fc30 FTBFS: t/ connect_hook_nodata.t fails with OpenSSL 1.1.1

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
Version|rawhide |29
   Fixed In Version||perl-POE-Component-SSLify-1
   ||.012-14.fc30



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: python-pycrypto package?

[Paul Howarth]

On Sun, 26 Aug 2018 10:55:28 -0400
Stephen John Smoogen  wrote:

> On Sun, 26 Aug 2018 at 00:49, Joseph D. Wagner
>  wrote:
> >
> > Is python-pycrypto a package?  If not, I'm starting to think it
> > should be.  I'm seeing it show up as requirements for some python
> > projects I'd like to work on.
> >
> > Thoughts?
> >  
> 
> It is called python2-crypto or python3-crypto in the distribution
> 
> 
> > https://pypi.org/project/pycrypto/

It's also pretty dead upstream and many of its downstream users have
migrated to a another project called python-cryptography:

https://pypi.org/project/cryptography/

Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: Alternative -devel packaging

[Vít Ondruch]

Dne 28.8.2018 v 13:47 Nicolas Mailhot napsal(a):
> Le 2018-08-07 17:33, Adam Jackson a écrit :
>> Consider a library like libGL. At runtime, you want the drivers it
>> might load to be installed. But when building an application, you just
>> need the library itself. If the drivers themselves have non-trivial
>> dependencies, the buildroot is more likely to fail to compose.
>
> That's a boostraping problem. The general solution is to make our
> build tools bootstrap aware, so they activate bootstrap mode as needed
> automatically, instead of forcing packagers to switch the conditional
> manually in spec files each time a bootstraping situation arises.
>

Just FTR, the logic is more or less there.

https://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping
https://pagure.io/packaging-committee/issue/789

together with:

https://src.fedoraproject.org/rpms/fedora-release/pull-request/7

So as long as you do the boostrapping iteration first with "%global
boostrap 1", then the packages have the "~bootstrap" suffix, if you do
subsequent build without the %{boostrap} macro defined, the suffix is
omitted.

Now the only issue is how to inject the "bootstrap 1" macro into the
buildroot. Obviously the tooling does not support it directly, but:

1) Modules can do this AFAIK
2) It is not that hard to adjust some basic RPM package shipping some
%{_rpmconfigdir}/macros.d/macros.* file to have this macro set.



V.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Vít Ondruch]

Dne 28.8.2018 v 16:15 Till Maas napsal(a):
> On Tue, Aug 28, 2018 at 04:04:37PM +0200, Vít Ondruch wrote:
>
>> I'd like to keep the packages above.
>>
>> And I'll be very happy if the packages listed bellow are retired. Most
>> of them are orphaned without comaintainers, that is fine. However some
>> appears to have co-maintainers, which is not really the case. I.e:
>>
>> Michale Stahnke (stahnma) -
>> http://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VBUPHRBDMQTF44FJX2ABXCIVDMKV3SXP/
>> ruby-packagers-sig - Obviously I hope this group won't become dumping
>> ground of packages which nobody wants/maintains, because although I am
>> admin of that group, I'm not sure I can retire the packages. I am pretty
>> sure I cannot drop the commit bit for that group.
> If you have commit access, you can retire the packages because "fedpkg
> retire" will just add the dead.package file and the remaining actions
> should happen automatically internally.

Interesting. Previously, in PkgDB days, it definitely was not that
straight forward, even though I am proven packager. Thx for the info.

Anyway, I still hope you will somehow reflect this email in your
script/list of packages and I won't need to use this ;) I'll definitely
wait how this pans out.


V.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27) - js-jqeury1

[Vít Ondruch]

Dne 28.8.2018 v 15:58 Christopher napsal(a):
> On Tue, Aug 28, 2018 at 8:49 AM Vít Ondruch  > wrote:
>
>
> So this is the email announcing orphaning js-jquery1:
>
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MI7W7TT3MUGMQTLYZYE5FKXUJCKFUXU7/
>
> But apparently it is used by more packages then just a few. So is
> there
> somebody, who would be willing (more than me) to keep the package
> alive?
>
>
> V.
>
>
> Given the security vulnerabilities in jQuery 1 (and 2) and the fact
> that upstream dropped them a long time ago, I strongly recommend the
> packages be retired than kept alive. Packagers depend on the newer
> js-jquery (3) instead, patching as needed.

Of course I see your point. Nevertheless, I still believe that it is
better to have the CVEs in one package where they will be eventually
fixed then spread across the whole Fedora bundled in all packages,
because I am quite sure this will be the result of retiring js-jquery1.

Speaking of the two rubygem- packages from the list:

1. rubygem-cucumbe is going to be migrated to the latest jQuery. Anyway,
this is testing framework, so I don't see the old and vulnerable jQuery
as a big deal.

2. I opened ticket to migrate rubygem-apipie-rails to the most recent
version of jQuery, but I don't think it is going to happen soon. Also,
it is probably used in some generated documentation, not sure how
critical the old jQuery is.

And in addition:

3. There is jQuery embedded in every rubygem-*-doc package from
rubygem-rdoc. You can use it as and example of bundling. But anyway,
this is again "just" documentation, if used, then typically used just
locally (although somebody might expose the documentation externally).

V.


[1] https://github.com/Apipie/apipie-rails/issues/628


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1622483] perl-MCE-1.837 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-MCE-1.837-1.fc29 perl-MCE-Shared-1.839-1.fc29 has been submitted as an
update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-fadf157880

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1622484] Upgrade perl-MCE-Shared to 1.839

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
perl-MCE-1.837-1.fc29 perl-MCE-Shared-1.839-1.fc29 has been submitted as an
update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-fadf157880

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Build failure with -Wl,--as-needed

[Scott Talbert]

On Tue, 28 Aug 2018, Marek Kasik wrote:

I'm not the maintainer of this package (iaxclient), but I ran into this 
build failure while working on a pull request.  It seems to be fallout from 
the -Wl,--as-needed change.  Any idea why this is happening?


it could be a consequence of the bug #1623078 (partially hidden by #1622611). 
Lets wait for its fix and try again :).


Yes, I think you are probably right.  iaxclient seems to use the system 
copy of libtool so this probably explains it.  Jerry provided some fixes 
to use the generated copy of libtool so that seems to resolve the problem 
as well.


Thanks,
Scott___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Rpm-ecosystem] lazy loading of filelists.xml to speed up dnf

[Vít Ondruch]

Dne 28.8.2018 v 13:56 Nicolas Mailhot napsal(a):
> Le 2018-08-08 22:48, Jeff Johnson a écrit :
>> My issue is the misdirection discussing lazy filelist downloading as a
>> "solution" to the "problem" of huge amounts of data that is forced to
>> be downloaded and loaded.
>>
>> The issue has been discussed repeatedly without a solution.
>>
>> Adding -- and maintaining -- patterns or whitelist exceptions, which
>> moves file dependencies into primary.xml is actually an approach that
>> solves the problem, and scales to multiple repos as well, each of
>> which also will have their own patterns and whitelist.
>
> Actually, you do not need to maintain whitelists manually, just having
> createrepo automatically whitelist all the file deps it finds
> referenced in the indexed repo would solve most of the problem.

+1. Proposed it already on some other place.


> If you want to be fancy, you could also add an option to pass it the
> url of another repo is should inherit whitelists from (for updates,
> epel, etc)

+1. This could be nice improvement of the idea above.


V.
>
> Manual whitelists will go stale fast
>
> Regards,
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Miro Hrončok]

On 28.8.2018 16:04, Vít Ondruch wrote:



Dne 28.8.2018 v 00:03 Till Maas napsal(a):

The following packages are orphaned or depend on an orphaned package
and will be retired, soon, unless someone adopts them. If you know for sure that
the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
adjust your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

   Package(co)maintainers  Status Change
===
rubygem-fattr  orphan, stahnma45 weeks ago


https://pagure.io/releng/issue/7713


rubygem-pdf-core   fale, jstribny, orphan,45 weeks ago
pvalena


https://pagure.io/releng/issue/7716


rubygem-prawn  fale, jstribny, orphan,45 weeks ago
pvalena


https://pagure.io/releng/issue/7714


rubygem-prawn-tablefale, orphan   48 weeks ago


https://pagure.io/releng/issue/7721


I'd like to keep the packages above.

And I'll be very happy if the packages listed bellow are retired. Most
of them are orphaned without comaintainers, that is fine. However some
appears to have co-maintainers, which is not really the case. I.e:

Michale Stahnke (stahnma) -
http://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VBUPHRBDMQTF44FJX2ABXCIVDMKV3SXP/
ruby-packagers-sig - Obviously I hope this group won't become dumping
ground of packages which nobody wants/maintains, because although I am
admin of that group, I'm not sure I can retire the packages.


I think you can.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Till Maas]

On Tue, Aug 28, 2018 at 04:04:37PM +0200, Vít Ondruch wrote:

> I'd like to keep the packages above.
> 
> And I'll be very happy if the packages listed bellow are retired. Most
> of them are orphaned without comaintainers, that is fine. However some
> appears to have co-maintainers, which is not really the case. I.e:
> 
> Michale Stahnke (stahnma) -
> http://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VBUPHRBDMQTF44FJX2ABXCIVDMKV3SXP/
> ruby-packagers-sig - Obviously I hope this group won't become dumping
> ground of packages which nobody wants/maintains, because although I am
> admin of that group, I'm not sure I can retire the packages. I am pretty
> sure I cannot drop the commit bit for that group.

If you have commit access, you can retire the packages because "fedpkg
retire" will just add the dead.package file and the remaining actions
should happen automatically internally.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: Alternative -devel packaging

[Nicolas Mailhot]

Le 2018-08-28 15:27, Adam Jackson a écrit :

On Tue, 2018-08-28 at 13:47 +0200, Nicolas Mailhot wrote:

Le 2018-08-07 17:33, Adam Jackson a écrit :
> Consider a library like libGL. At runtime, you want the drivers it
> might load to be installed. But when building an application, you just
> need the library itself. If the drivers themselves have non-trivial
> dependencies, the buildroot is more likely to fail to compose.

That's a boostraping problem. The general solution is to make our 
build

tools bootstrap aware, so they activate bootstrap mode as needed
automatically, instead of forcing packagers to switch the conditional
manually in spec files each time a bootstraping situation arises.


If you consider buildroot size to be a metric to be reduced - and
clearly people do, see BuildRequires: gcc - then this is not just a
bootstrapping issue.


Sure. However I suspect your solution would work fine at first and then 
quickly degenerate in tricky situations as soon as the two packages 
which are supposed to provide the same files lose sync (especially if 
several elements in the build compose use your pattern).


Losing sync can be just: full version can not install due to broken 
deps, so your builds work with the reduced version, and is then used on 
user systems with previous full versions, as the new one does not 
install. Of course you could add a version-lock between full and reduced 
version, so your build refuses to install if there is not an exact 
match, but then you have poisoned the repo with a package that built, 
but is not instalable.



Is there a proposal anywhere for the kind of bootstrap awareness you
describe?


It was described about a month ago as part of the discussion on mass 
rebuild tools.


Basically, if building a set of packages does not succeed, and part of 
the failing packages have bootstraping logic, the build tool should try 
to rebuild those in reduced mode automatically, use the result to finish 
all the other builds, and then rebuild everything that was build in 
reduced mode in full mode. At every step in the process there is only 
one package that provides the same dep.


Regards,

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1622481] Upgrade perl-IO-AIO to 4.6

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
perl-IO-AIO-4.60-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-5f72203fc8

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

pghmcfc pushed to perl-MCE-Shared (f29). "Update to 1.839 (..more)"

[notifications]

Notification time stamped 2018-08-28 14:08:24 UTC

From b3435a0b63ff82fa87e424ba95d6abd39b1ca05e Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Aug 28 2018 14:01:49 +
Subject: Update to 1.839


- New upstream release 1.839
  - Seeds the Math::Random::MT::Auto generator automatically when present in
MCE::Hobo, similarly to Math::Random and Math::Prime::Util, to avoid child
processes sharing the same seed value as the parent and each other; the new
seed is computed using the current seed
  - Updated MCE::Shared::Cache to support optional argument "expires_in" for
set and sugar methods
  - Updated MCE::Shared documentation
  - Bumped MCE dependency to 1.837

---

diff --git a/.rpmlint b/.rpmlint
deleted file mode 100644
index 52ea5aa..000
--- a/.rpmlint
+++ /dev/null
@@ -1,2 +0,0 @@
-from Config import *
-addFilter("spelling-error %description -l en_US parallelization -> ");
diff --git a/perl-MCE-Shared.rpmlintrc b/perl-MCE-Shared.rpmlintrc
new file mode 100644
index 000..52ea5aa
--- /dev/null
+++ b/perl-MCE-Shared.rpmlintrc
@@ -0,0 +1,2 @@
+from Config import *
+addFilter("spelling-error %description -l en_US parallelization -> ");
diff --git a/perl-MCE-Shared.spec b/perl-MCE-Shared.spec
index 79ab8a2..01b8908 100644
--- a/perl-MCE-Shared.spec
+++ b/perl-MCE-Shared.spec
@@ -1,6 +1,6 @@
 Name:  perl-MCE-Shared
-Version:   1.838
-Release:   3%{?dist}
+Version:   1.839
+Release:   1%{?dist}
 Summary:   MCE extension for sharing data, supporting threads and processes
 License:   GPL+ or Artistic
 URL:   https://metacpan.org/release/MCE-Shared
@@ -19,7 +19,7 @@ BuildRequires:perl(base)
 BuildRequires: perl(bytes)
 BuildRequires: perl(Carp)
 BuildRequires: perl(constant)
-BuildRequires: perl(MCE) >= 1.836
+BuildRequires: perl(MCE) >= 1.837
 BuildRequires: perl(MCE::Mutex)
 BuildRequires: perl(MCE::Signal)
 BuildRequires: perl(MCE::Util)
@@ -44,7 +44,7 @@ BuildRequires:perl(Test::More) >= 0.88
 # Runtime
 Requires:  perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo $version))
 Requires:  perl(IO::FDPass) >= 1.2
-Requires:  perl(MCE) >= 1.836
+Requires:  perl(MCE) >= 1.837
 Requires:  perl(overloading)
 Requires:  perl(POSIX)
 Requires:  perl(Storable) >= 2.04
@@ -98,6 +98,17 @@ make test
 %{_mandir}/man3/MCE::Shared::Server.3*
 
 %changelog
+* Tue Aug 28 2018 Paul Howarth  - 1.839-1
+- Update to 1.839
+  - Seeds the Math::Random::MT::Auto generator automatically when present in
+MCE::Hobo, similarly to Math::Random and Math::Prime::Util, to avoid child
+processes sharing the same seed value as the parent and each other; the new
+seed is computed using the current seed
+  - Updated MCE::Shared::Cache to support optional argument "expires_in" for
+set and sugar methods
+  - Updated MCE::Shared documentation
+  - Bumped MCE dependency to 1.837
+
 * Fri Jul 13 2018 Fedora Release Engineering  - 
1.838-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
 
diff --git a/sources b/sources
index f9629c9..eaadf5a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (MCE-Shared-1.838.tar.gz) = 
618651b90a7a6580f49e55a45d1087ed8a2f25bb693228fdcc1eaa7caa2622c062493615bebc1216cbd39796c5e57b21167ae4f848e125aa2aeca80ed68bf19b
+SHA512 (MCE-Shared-1.839.tar.gz) = 
f31786a2453667dbd5a810c4cbdcf143162749512f290ca264ec02c196d33acf668bdce74731d887822fdf0a334740828f39fd40aea79756d862790c3b064d0f



https://src.fedoraproject.org/rpms/perl-MCE-Shared/c/b3435a0b63ff82fa87e424ba95d6abd39b1ca05e?branch=f29
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Christopher]

On Tue, Aug 28, 2018 at 8:49 AM Vít Ondruch  wrote:

>
> So this is the email announcing orphaning js-jquery1:
>
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MI7W7TT3MUGMQTLYZYE5FKXUJCKFUXU7/
>
> But apparently it is used by more packages then just a few. So is there
> somebody, who would be willing (more than me) to keep the package alive?
>
>
> V.
>
>
Given the security vulnerabilities in jQuery 1 (and 2) and the fact that
upstream dropped them a long time ago, I strongly recommend the packages be
retired than kept alive. Packagers depend on the newer js-jquery (3)
instead, patching as needed.

I plan on migrating accumulo to use the newer js-jquery soon, but I need
the maintainer of nodejs-flot to do so first. (
https://bugzilla.redhat.com/show_bug.cgi?id=1623115)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Vít Ondruch]

Dne 28.8.2018 v 00:03 Till Maas napsal(a):
> The following packages are orphaned or depend on an orphaned package
> and will be retired, soon, unless someone adopts them. If you know for sure 
> that
> the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> adjust your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
>   Package(co)maintainers  Status Change 
> ===
> rubygem-fattr  orphan, stahnma45 weeks ago  

https://pagure.io/releng/issue/7713

> rubygem-pdf-core   fale, jstribny, orphan,45 weeks ago  
>pvalena 

https://pagure.io/releng/issue/7716

> rubygem-prawn  fale, jstribny, orphan,45 weeks ago  
>pvalena

https://pagure.io/releng/issue/7714

> rubygem-prawn-tablefale, orphan   48 weeks ago  

https://pagure.io/releng/issue/7721


I'd like to keep the packages above.

And I'll be very happy if the packages listed bellow are retired. Most
of them are orphaned without comaintainers, that is fine. However some
appears to have co-maintainers, which is not really the case. I.e:

Michale Stahnke (stahnma) -
http://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VBUPHRBDMQTF44FJX2ABXCIVDMKV3SXP/
ruby-packagers-sig - Obviously I hope this group won't become dumping
ground of packages which nobody wants/maintains, because although I am
admin of that group, I'm not sure I can retire the packages. I am pretty
sure I cannot drop the commit bit for that group.

Should I open releng ticket to get these retired?


> rubygem-activerecord-nulldb-   orphan 55 weeks ago  
> adapter 
> rubygem-acts-as-taggable-onorphan, ruby-packagers-sig 55 weeks ago  
> rubygem-arrayfieldsorphan, stahnma45 weeks ago  
> rubygem-attributes orphan, stahnma45 weeks ago  
> rubygem-axiom-typesorphan 55 weeks ago  
> rubygem-bogus  orphan 55 weeks ago  
> rubygem-bourne orphan 55 weeks ago  
> rubygem-bunny  orphan 31 weeks ago  
> rubygem-capillary  orphan 55 weeks ago  
> rubygem-coercible  orphan 55 weeks ago  
> rubygem-columnize  orphan, stahnma45 weeks ago  
> rubygem-dependor   orphan 55 weeks ago  
> rubygem-descendants_trackerorphan 55 weeks ago  
> rubygem-equalizer  orphan 55 weeks ago  
> rubygem-escape_utils   orphan 55 weeks ago  
> rubygem-   orphan, ruby-packagers-sig 17 weeks ago  
> exception_notification  
> rubygem-facade orphan 30 weeks ago  
> rubygem-facets orphan, stahnma45 weeks ago
> rubygem-ferret orphan 46 weeks ago
> rubygem-gemcutter  orphan, stahnma46 weeks ago  
> rubygem-gemnasium-parser   orphan 55 weeks ago  
> rubygem-geoip  orphan 55 weeks ago  
> rubygem-haml-rails orphan 46 weeks ago  
> rubygem-hawler orphan 46 weeks ago  
> rubygem-hipchatorphan 55 weeks ago  
> rubygem-innertube  orphan 55 weeks ago  
> rubygem-joiner orphan 55 weeks ago  
> rubygem-just_paginate  orphan 55 weeks ago  
> rubygem-literati   orphan 55 weeks ago  
> rubygem-loggingorphan 46 weeks ago  
> rubygem-main   orphan 46 weeks ago  
> rubygem-markabyorphan 46 weeks ago  
> rubygem-middleware orphan 55 weeks ago  
> rubygem-net-dnsorphan 38 weeks ago  
> rubygem-pathname2  orphan 30 weeks ago  

pghmcfc pushed to perl-MCE-Shared (master). "Update to 1.839 (..more)"

[notifications]

Notification time stamped 2018-08-28 14:02:22 UTC

From b3435a0b63ff82fa87e424ba95d6abd39b1ca05e Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Aug 28 2018 14:01:49 +
Subject: Update to 1.839


- New upstream release 1.839
  - Seeds the Math::Random::MT::Auto generator automatically when present in
MCE::Hobo, similarly to Math::Random and Math::Prime::Util, to avoid child
processes sharing the same seed value as the parent and each other; the new
seed is computed using the current seed
  - Updated MCE::Shared::Cache to support optional argument "expires_in" for
set and sugar methods
  - Updated MCE::Shared documentation
  - Bumped MCE dependency to 1.837

---

diff --git a/.rpmlint b/.rpmlint
deleted file mode 100644
index 52ea5aa..000
--- a/.rpmlint
+++ /dev/null
@@ -1,2 +0,0 @@
-from Config import *
-addFilter("spelling-error %description -l en_US parallelization -> ");
diff --git a/perl-MCE-Shared.rpmlintrc b/perl-MCE-Shared.rpmlintrc
new file mode 100644
index 000..52ea5aa
--- /dev/null
+++ b/perl-MCE-Shared.rpmlintrc
@@ -0,0 +1,2 @@
+from Config import *
+addFilter("spelling-error %description -l en_US parallelization -> ");
diff --git a/perl-MCE-Shared.spec b/perl-MCE-Shared.spec
index 79ab8a2..01b8908 100644
--- a/perl-MCE-Shared.spec
+++ b/perl-MCE-Shared.spec
@@ -1,6 +1,6 @@
 Name:  perl-MCE-Shared
-Version:   1.838
-Release:   3%{?dist}
+Version:   1.839
+Release:   1%{?dist}
 Summary:   MCE extension for sharing data, supporting threads and processes
 License:   GPL+ or Artistic
 URL:   https://metacpan.org/release/MCE-Shared
@@ -19,7 +19,7 @@ BuildRequires:perl(base)
 BuildRequires: perl(bytes)
 BuildRequires: perl(Carp)
 BuildRequires: perl(constant)
-BuildRequires: perl(MCE) >= 1.836
+BuildRequires: perl(MCE) >= 1.837
 BuildRequires: perl(MCE::Mutex)
 BuildRequires: perl(MCE::Signal)
 BuildRequires: perl(MCE::Util)
@@ -44,7 +44,7 @@ BuildRequires:perl(Test::More) >= 0.88
 # Runtime
 Requires:  perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo $version))
 Requires:  perl(IO::FDPass) >= 1.2
-Requires:  perl(MCE) >= 1.836
+Requires:  perl(MCE) >= 1.837
 Requires:  perl(overloading)
 Requires:  perl(POSIX)
 Requires:  perl(Storable) >= 2.04
@@ -98,6 +98,17 @@ make test
 %{_mandir}/man3/MCE::Shared::Server.3*
 
 %changelog
+* Tue Aug 28 2018 Paul Howarth  - 1.839-1
+- Update to 1.839
+  - Seeds the Math::Random::MT::Auto generator automatically when present in
+MCE::Hobo, similarly to Math::Random and Math::Prime::Util, to avoid child
+processes sharing the same seed value as the parent and each other; the new
+seed is computed using the current seed
+  - Updated MCE::Shared::Cache to support optional argument "expires_in" for
+set and sugar methods
+  - Updated MCE::Shared documentation
+  - Bumped MCE dependency to 1.837
+
 * Fri Jul 13 2018 Fedora Release Engineering  - 
1.838-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
 
diff --git a/sources b/sources
index f9629c9..eaadf5a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (MCE-Shared-1.838.tar.gz) = 
618651b90a7a6580f49e55a45d1087ed8a2f25bb693228fdcc1eaa7caa2622c062493615bebc1216cbd39796c5e57b21167ae4f848e125aa2aeca80ed68bf19b
+SHA512 (MCE-Shared-1.839.tar.gz) = 
f31786a2453667dbd5a810c4cbdcf143162749512f290ca264ec02c196d33acf668bdce74731d887822fdf0a334740828f39fd40aea79756d862790c3b064d0f



https://src.fedoraproject.org/rpms/perl-MCE-Shared/c/b3435a0b63ff82fa87e424ba95d6abd39b1ca05e?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[389-devel] Logout not supported by the browser

[Stephen Osella]

When I click on the logout popup button for the "tpsadmin" user, a dialog pops 
up with the error message:  "Logout not supported by the browser. Please clear 
Active Logins or close the browser."  

As far as I can tell, the logout doesn't actually do anything.  Is this a bug, 
or unimplemented feature?
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: Fedora 29 Beta Freeze

[Miro Hrončok]

On 28.8.2018 02:06, Mohan Boddu wrote:

Hi all,

Today's an important day on the Fedora 29 schedule[1], with several 
significant cut-offs. First of all today is
the Bodhi activation point [2]. That means that from now all Fedora 29 
packages must be submitted to
updates-testing and pass the relevant requirements[3] before they will 
be marked as 'stable' and moved to the

fedora repository.



Hi. I have 2 builds in f29-pending.

https://koji.fedoraproject.org/koji/builds?inherited=0=3430=-build_id=1

Are those to be submitted trough bodhi, or I just wait?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Rpm-ecosystem] lazy loading of filelists.xml to speed up dnf

[Nicolas Mailhot]

Le 2018-08-28 15:00, Nico Kadel-Garcia a écrit :


And no, I'm
afraid it does *not* scale since the exclusions from another
repository may not be appropriate to the repository one is currently
building, and automatically including that whitelist is automatically
mismatching the content database to the actual content of the
repository *every time*.


The whole point is to separate the file indexes in two files, one 
downloaded by default the other as-needed.


It is trivially obvious that putting automatically the file deps the 
repo uses itself in the first index cuts down drastically on the 
situations when you need to download the second index file (only needed 
to handle the situations when the user explicitly requests a file dep 
not used by the repo itself, or when resolving for a third party 
package). We know the number of file deps used by our repos is small, as 
they are used for special cases, so it's not as if putting all of them 
automatically in the first index is going to bloat it.


It is trivially obvious than when a repo, is intended to be used on top 
of another repo (fedora updates over fedora, epel over centos), you want 
to extend this file to the file deps, referenced by this other repo, so 
you need to point createrepo to this (or these) other repo indexes to 
check what they need (and save in the repo metadata the list of the file 
deps it uses, but that's trivial if you do the first step and this list 
would be only downloaded by createrepo, not the average dnf user).


And doing the second part requires passing an explicit parameter to 
createrepo because it can not guess that inheriting centos rules for 
epel is appropriate. But the person indexing epel bloody well knows it 
is appropriate.


That's the basic idea. One would probably want to handle BR file deps 
too to cut down on build farm processing times, that requires pointing 
createrepo to the SRPM repo metadata.


Regards

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1622483] perl-MCE-1.837 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-MCE-1.837-1.fc29
   ||perl-MCE-1.837-1.fc30
 Resolution|--- |RAWHIDE
Last Closed||2018-08-28 09:31:09



--- Comment #1 from Paul Howarth  ---
Builds done:

F-29:
https://koji.fedoraproject.org/koji/taskinfo?taskID=29347962

Rawhide:
https://koji.fedoraproject.org/koji/taskinfo?taskID=29347774

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: RFC: Alternative -devel packaging

[Adam Jackson]

On Tue, 2018-08-28 at 13:47 +0200, Nicolas Mailhot wrote:
> Le 2018-08-07 17:33, Adam Jackson a écrit :
> > Consider a library like libGL. At runtime, you want the drivers it
> > might load to be installed. But when building an application, you just
> > need the library itself. If the drivers themselves have non-trivial
> > dependencies, the buildroot is more likely to fail to compose.
> 
> That's a boostraping problem. The general solution is to make our build 
> tools bootstrap aware, so they activate bootstrap mode as needed 
> automatically, instead of forcing packagers to switch the conditional 
> manually in spec files each time a bootstraping situation arises.

If you consider buildroot size to be a metric to be reduced - and
clearly people do, see BuildRequires: gcc - then this is not just a
bootstrapping issue.

Is there a proposal anywhere for the kind of bootstrap awareness you
describe?

- ajax
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Build failure with -Wl,--as-needed

[Marek Kasik]

Hi,

On 08/28/2018 04:32 AM, Scott Talbert wrote:

Hi,

I'm not the maintainer of this package (iaxclient), but I ran into this 
build failure while working on a pull request.  It seems to be fallout 
from the -Wl,--as-needed change.  Any idea why this is happening?


it could be a consequence of the bug #1623078 (partially hidden by 
#1622611). Lets wait for its fix and try again :).



https://koji.fedoraproject.org/koji/taskinfo?taskID=29342306

Thanks,
Scott


Regards
Marek


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Zamir SUN]

On 08/28/2018 06:03 AM, Till Maas wrote:
> Depending on: zopfli (22), status change: 2017-11-05 (42 weeks ago)
>   fedora-logos (maintained by: alexl, caillon, caolanm, johnp, mbarnes, 
> rhughes, rstrode, spot, ssp)
>   fedora-logos-28.0.3-2.fc29.src requires zopfli = 1.0.1-7.fc29
> 
>   google-noto-emoji-fonts (maintained by: mfabian, pwu)
>   google-noto-emoji-fonts-20180814-1.fc29.src requires zopfli = 
> 1.0.1-7.fc29
> 
>   twitter-twemoji-fonts (maintained by: mavit)
>   twitter-twemoji-fonts-11.0.1-1.fc29.src requires zopfli = 
> 1.0.1-7.fc29
> 
>   fedora-business-cards (maintained by: bex)
>   fedora-business-cards-1-0.12.beta1.fc29.noarch requires 
> fedora-logos = 28.0.3-2.fc29
> 
>   lxqt-themes (maintained by: lxqt-sig, raphgro, zsun)
>   lxqt-themes-0.13.0-4.fc30.noarch requires fedora-logos = 
> 28.0.3-2.fc29
> 
>   nimbus (maintained by: cwickert)
>   nimbus-icon-theme-0.1.4-17.fc29.noarch requires fedora-logos = 
> 28.0.3-2.fc29
> 
>   rhn-client-tools (maintained by: msuchy, tkasparek)
>   rhn-client-tools-2.9.12-2.fc29.src requires fedora-logos = 
> 28.0.3-2.fc29
>   rhn-check-2.9.12-2.fc29.noarch requires dnf-plugin-spacewalk = 
> 2.7.9-4.fc29
> 
>   vacuum-im (maintained by: martinkg)
>   vacuum-im-1.3.0-0.9.20180214git01910e9.fc29.i686 requires 
> fedora-logos = 28.0.3-2.fc29
> 
>   pdfbox (maintained by: gil, java-sig, orion)
>   pdfbox-2.0.9-2.fc29.src requires google-noto-emoji-fonts = 
> 20180814-1.fc29
> 
>   lxqt-themes-fedora (maintained by: zsun)
>   lxqt-themes-fedora-1.0-0.2.fc30.noarch requires lxqt-themes = 
> 0.13.0-4.fc30
> 
>   dnf-plugin-spacewalk (maintained by: mmraka, tkasparek)
>   dnf-plugin-spacewalk-2.7.9-4.fc29.noarch requires 
> rhn-client-tools = 2.9.12-2.fc29
> 
>   yum-rhn-plugin (maintained by: msuchy, tkasparek)
>   yum-rhn-plugin-2.8.9-2.fc29.noarch requires rhn-client-tools = 
> 2.9.12-2.fc29
> 
>   hibernate-search (maintained by: gil, goldmann, lef)
>   hibernate-search-5.5.4-2.fc26.src requires 
> mvn(org.apache.pdfbox:pdfbox) = 2.0.9
> 
>   jabref (maintained by: dchen)
>   jabref-2.10-5.fc28.noarch requires pdfbox = 2.0.9-2.fc29
>   jabref-2.10-5.fc28.src requires pdfbox = 2.0.9-2.fc29
> 
>   javadocofflinesearch (maintained by: jvanek)
>   javadocofflinesearch-2.2-7.fc29.src requires pdfbox = 
> 2.0.9-2.fc29
> 
>   tika (maintained by: gil, lef)
>   tika-1.17-2.fc29.src requires mvn(org.apache.pdfbox:pdfbox) = 
> 2.0.9
>   tika-parsers-1.17-2.fc29.noarch requires 
> mvn(org.apache.pdfbox:pdfbox) = 2.0.9
> 
>   lxqt-session (maintained by: lxqt-sig, rdieter, tieugene)
>   lxqt-session-0.13.0-3.fc30.i686 requires lxqt-themes-fedora = 
> 1.0-0.2.fc30
> 
>   rhn-custom-info (maintained by: msuchy, tkasparek)
>   rhn-custom-info-5.4.43-3.fc29.noarch requires 
> dnf-plugin-spacewalk = 2.7.9-4.fc29
> 
>   annox (maintained by: gil)
>   annox-1.0.1-6.fc29.src requires 
> mvn(org.hibernate:hibernate-search-engine) = 5.5.4.Final
> 
>   hibernate-hql (maintained by: gil, goldmann, lef)
>   hibernate-hql-1.3.0-0.2.Alpha2.fc26.noarch requires 
> mvn(org.hibernate:hibernate-search-engine) = 5.5.4.Final
>   hibernate-hql-1.3.0-0.2.Alpha2.fc26.src requires 
> mvn(org.hibernate:hibernate-search-engine) = 5.5.4.Final
> 
>   eclipse-mylyn (maintained by: akurtakov, arobinso, eclipse-sig, 
> jjohnstn, kdaniel, rgrunber)
>   eclipse-mylyn-3.25.0-0.1.fc30.src requires tika = 1.17-2.fc29
>   eclipse-mylyn-docs-epub-3.25.0-0.1.fc30.noarch requires 
> mvn(org.apache.tika:tika-core) = 1.17
> 
>   vorbis-java (maintained by: gil)
>   vorbis-java-0.8-5.fc29.src requires 
> mvn(org.apache.tika:tika-core) = 1.17
>   vorbis-java-tika-0.8-5.fc29.noarch requires 
> mvn(org.apache.tika:tika-core) = 1.17
> 
>   Too many dependencies for zopfli, not all listed here

Seems zopfli is used for fedora-logos[1], and this causes a lot of
package to be listed here.

I am just curious if there are any plan for fedora-logos to switch to
new optimizing tools, or the better choice can be pickup zopfli again?

[1]
https://src.fedoraproject.org/rpms/fedora-logos/blob/master/f/fedora-logos.spec#_30

-- 
Ziqian SUN (Zamir)
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/
Ready to contribute? See https://whatcanidoforfedora.org/
想了解更多中文资讯，访问 https://zh.fedoracommunity.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: [Rpm-ecosystem] lazy loading of filelists.xml to speed up dnf

[Nico Kadel-Garcia]

On Tue, Aug 28, 2018 at 7:57 AM Nicolas Mailhot
 wrote:
>
> Le 2018-08-08 22:48, Jeff Johnson a écrit :
> > My issue is the misdirection discussing lazy filelist downloading as a
> > "solution" to the "problem" of huge amounts of data that is forced to
> > be downloaded and loaded.
> >
> > The issue has been discussed repeatedly without a solution.
> >
> > Adding -- and maintaining -- patterns or whitelist exceptions, which
> > moves file dependencies into primary.xml is actually an approach that
> > solves the problem, and scales to multiple repos as well, each of
> > which also will have their own patterns and whitelist.
>
> Actually, you do not need to maintain whitelists manually, just having
> createrepo automatically whitelist all the file deps it finds referenced
> in the indexed repo would solve most of the problem.
>
> If you want to be fancy, you could also add an option to pass it the url
> of another repo is should inherit whitelists from (for updates, epel,
> etc)

There is a very old joke about a man visiting a tailor and buying a
very nice suit that does not fit, so he lifts one arm, sticks his leg
out to the side, bends to the left, etc. And people look at him and
say "that poor man" and are told, "yes, but look at that wonderful
suit!".

The man is walking funny with all the filters applied. As soon as he
stands up straight, it's apparent that the actual content in the
repository does not match the dnf reported contents. And no, I'm
afraid it does *not* scale since the exclusions from another
repository may not be appropriate to the repository one is currently
building, and automatically including that whitelist is automatically
mismatching the content database to the actual content of the
repository *every time*.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 29 Beta Freeze

[Mohan Boddu]

Hi all,

Today's an important day on the Fedora 29 schedule[1], with several
significant cut-offs. First of all today is
the Bodhi activation point [2]. That means that from now all Fedora 29
packages must be submitted to
updates-testing and pass the relevant requirements[3] before they will be
marked as 'stable' and moved to the
fedora repository.

Today is also the Beta freeze[4]. This means that only packages which fix
accepted blocker or freeze exception
bugs[5][6] will be marked as 'stable' and included in the Beta composes.
Other builds will remain in updates-
testing until the Beta release is approved, at which point the Beta freeze
is lifted and packages can move to
'stable' as usual until the Final freeze.

Finally, Today is the '100% code complete deadline' Change Checkpoint[5],
meaning that Fedora 29 Changes
must now be code complete, meaning all the code required to enable to the
new change is finished. The level
of code completeness is reflected as tracker bug state ON_QA. The change
does not have to be fully tested
by this deadline'.

Finally, today is also the Software String freeze[7], which means that
strings marked for translation in Fedora-
translated projects should not now be changed for Fedora 29.

Mohan Boddu

[1] https://fedoraproject.org/wiki/Releases/29/Schedule
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 29 Beta Freeze

[Mohan Boddu]

Hi all,

Today's an important day on the Fedora 29 schedule[1], with several
significant cut-offs. First of all today is
the Bodhi activation point [2]. That means that from now all Fedora 29
packages must be submitted to
updates-testing and pass the relevant requirements[3] before they will be
marked as 'stable' and moved to the
fedora repository.

Today is also the Beta freeze[4]. This means that only packages which fix
accepted blocker or freeze exception
bugs[5][6] will be marked as 'stable' and included in the Beta composes.
Other builds will remain in updates-
testing until the Beta release is approved, at which point the Beta freeze
is lifted and packages can move to
'stable' as usual until the Final freeze.

Finally, Today is the '100% code complete deadline' Change Checkpoint[5],
meaning that Fedora 29 Changes
must now be code complete, meaning all the code required to enable to the
new change is finished. The level
of code completeness is reflected as tracker bug state ON_QA. The change
does not have to be fully tested
by this deadline'.

Finally, today is also the Software String freeze[7], which means that
strings marked for translation in Fedora-
translated projects should not now be changed for Fedora 29.

Mohan Boddu

[1] https://fedoraproject.org/wiki/Releases/29/Schedule
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

[Bug 1622999] perl-POE-Component-SSLify-1.012-13.fc30 FTBFS: t/ connect_hook_nodata.t fails with OpenSSL 1.1.1

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

External Bug ID||CPAN 126976



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Vít Ondruch]

Dne 28.8.2018 v 00:03 Till Maas napsal(a):
>
>   Package(co)maintainers  Status Change 
> ===
> js-jquery1 ctubbsii, jamielinux,  5 weeks ago   
>nodejs-sig, orphan, patches  
>
> Depending on: js-jquery1 (23), status change: 2018-07-19 (5 weeks ago)
>   accumulo (maintained by: ctubbsii, milleruntime, mizdebsk)
>   accumulo-monitor-1.9.2-1.fc29.noarch requires js-jquery1 = 
> 1.12.4-6.fc29
>
>   copr-frontend (maintained by: clime, dturecek, frostyx, msuchy)
>   copr-frontend-1.133-3.fc29.noarch requires js-jquery1 = 
> 1.12.4-6.fc29
>
>   ghc-pretty-show (maintained by: mathstuf)
>   ghc-pretty-show-1.6.16-1.fc29.i686 requires js-jquery1 = 
> 1.12.4-6.fc29
>
>   lazygal (maintained by: rathann)
>   lazygal-0.9.1-7.fc29.noarch requires js-jquery1 = 1.12.4-6.fc29
>   lazygal-0.9.1-7.fc29.src requires js-jquery1 = 1.12.4-6.fc29
>
>   mkdocs (maintained by: carlwgeorge, williamjmorenor)
>   mkdocs-0.16.3-8.fc29.noarch requires js-jquery1 = 1.12.4-6.fc29
>   mkdocs-0.16.3-8.fc29.src requires 
> /usr/share/javascript/jquery/1.12.4/jquery.min.js, js-jquery1 = 1.12.4-6.fc29
>
>   nodejs-flot (maintained by: nodejs-sig, rathann, vjancik, 
> williamjmorenor)
>   nodejs-flot-0.8.3-7.fc29.noarch requires js-jquery1 = 
> 1.12.4-6.fc29
>
>   pl (maintained by: bagnara, mef, ppisar)
>   pl-7.6.4-4.fc29.i686 requires js-jquery1 = 1.12.4-6.fc29
>   pl-7.6.4-4.fc29.src requires js-jquery1 = 1.12.4-6.fc29
>
>   python-XStatic-jQuery (maintained by: mrunge, rdopiera)
>   python2-XStatic-jQuery-1.10.2.1-11.fc29.noarch requires 
> js-jquery1 = 1.12.4-6.fc29
>   python3-XStatic-jQuery-1.10.2.1-11.fc29.noarch requires 
> js-jquery1 = 1.12.4-6.fc29
>
>   python-sphinx-bootstrap-theme (maintained by: besser82, sic)
>   python2-sphinx-bootstrap-theme-0.4.13-9.fc29.noarch requires 
> js-jquery1 = 1.12.4-6.fc29
>   python3-sphinx-bootstrap-theme-0.4.13-9.fc29.noarch requires 
> js-jquery1 = 1.12.4-6.fc29
>
>   rubygem-apipie-rails (maintained by: jaruga, ruby-packagers-sig, 
> vondruch)
>   rubygem-apipie-rails-0.5.5-3.fc29.noarch requires js-jquery1 = 
> 1.12.4-6.fc29
>
>   rubygem-cucumber (maintained by: clalance, jstribny, mmorsi, tdawson, 
> vondruch)
>   rubygem-cucumber-2.4.0-5.fc29.noarch requires js-jquery1 = 
> 1.12.4-6.fc29
>   rubygem-cucumber-2.4.0-5.fc29.src requires js-jquery1 = 
> 1.12.4-6.fc29
>
>   zabbix (maintained by: sharkcz, volter, wakko666)
>   zabbix-web-3.0.16-4.fc29.noarch requires js-jquery1 = 
> 1.12.4-6.fc29
>
>   ghc-gi-gio (maintained by: dshea, weldr-sig)
>   ghc-gi-gio-2.0.18-1.fc29.i686 requires 
> libHSpretty-show-1.6.16-4yL3QMm4omX5sydQq6eqFv-ghc8.2.2.so
>
>   ghc-gi-glib (maintained by: dshea, weldr-sig)
>   ghc-gi-glib-2.0.17-1.fc29.i686 requires 
> libHSpretty-show-1.6.16-4yL3QMm4omX5sydQq6eqFv-ghc8.2.2.so
>
>   ghc-gi-gobject (maintained by: dshea, weldr-sig)
>   ghc-gi-gobject-2.0.16-5.fc29.i686 requires 
> libHSpretty-show-1.6.16-4yL3QMm4omX5sydQq6eqFv-ghc8.2.2.so
>
>   ghc-gi-ostree (maintained by: dshea, weldr-sig)
>   ghc-gi-ostree-1.0.6-5.fc29.i686 requires 
> libHSpretty-show-1.6.16-4yL3QMm4omX5sydQq6eqFv-ghc8.2.2.so
>
>   ghc-haskell-gi (maintained by: dshea, weldr-sig)
>   ghc-haskell-gi-0.21.3-1.fc29.i686 requires 
> libHSpretty-show-1.6.16-4yL3QMm4omX5sydQq6eqFv-ghc8.2.2.so
>   ghc-haskell-gi-devel-0.21.3-1.fc29.i686 requires 
> libHSpretty-show-1.6.16-4yL3QMm4omX5sydQq6eqFv-ghc8.2.2.so
>
>   hledger (maintained by: mathstuf)
>   ghc-hledger-1.5-9.fc29.i686 requires 
> libHSpretty-show-1.6.16-4yL3QMm4omX5sydQq6eqFv-ghc8.2.2.so
>   hledger-1.5-9.fc29.i686 requires 
> libHSpretty-show-1.6.16-4yL3QMm4omX5sydQq6eqFv-ghc8.2.2.so
>
>   ghc-hledger-lib (maintained by: mathstuf)
>   ghc-hledger-lib-1.5.1-4.fc29.i686 requires 
> libHSpretty-show-1.6.16-4yL3QMm4omX5sydQq6eqFv-ghc8.2.2.so
>
>   mkdocs-alabaster (maintained by: williamjmorenor)
>   mkdocs-alabaster-0.7.4-6.fc29.noarch requires mkdocs = 
> 0.16.3-8.fc29
>
>   mkdocs-basic-theme (maintained by: williamjmorenor)
>   mkdocs-basic-theme-1.0.1-10.fc29.noarch requires mkdocs = 
> 0.16.3-8.fc29
>
>   mkdocs-cinder (maintained by: williamjmorenor)
>   mkdocs-cinder-0.9.3-8.fc29.noarch requires mkdocs = 
> 0.16.3-8.fc29
>
>   mkdocs-material (maintained by: williamjmorenor)
>   mkdocs-material-0.2.2-8.fc29.noarch requires mkdocs = 
> 0.16.3-8.fc29
>
>   Too many dependencies for js-jquery1, 

Re: fedora-tagger sunset - week post F29 beta freeze

[Björn Persson]

Mattia Verga wrote:
> The Group tag would not fix exactly what I mean. I wouldn't want to create 
> groups of packages, but apply descriptive tags of the abilities of the 
> package.
> For example, in some of the packages I maintain:
> ccdciel: astronomy, astrophotography, imaging, telescope
> skychart: astronomy, telescope, planetarium
> kpmcore: administration, disk, partition, utility
> 
> ... so that a user can search for those tags in a package manager, instead of 
> searching Google to find what software can do what he's searching for and 
> then search for that package in the package manager to find if Fedora ships 
> it.

Why don't you just write your descriptions to include those words?

One can already find CCDciel with "yum search all telescope", Skychart
with "yum search all planetarium", and KPMcore with "yum search all
partition". Searching for "astronom" (to catch both "astronomy" and
"astronomer") finds both CCDciel and Skychart.

You can improve on this by expanding your packages' descriptions to
include the words you listed. If you can't come up with a sentence that
describes your package and includes the word you want, then perhaps
that word isn't actually a good tag for that package?

Björn Persson


pgp4_sYGQi_UN.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Rpm-ecosystem] lazy loading of filelists.xml to speed up dnf

[Nicolas Mailhot]

Le 2018-08-08 22:48, Jeff Johnson a écrit :

My issue is the misdirection discussing lazy filelist downloading as a
"solution" to the "problem" of huge amounts of data that is forced to
be downloaded and loaded.

The issue has been discussed repeatedly without a solution.

Adding -- and maintaining -- patterns or whitelist exceptions, which
moves file dependencies into primary.xml is actually an approach that
solves the problem, and scales to multiple repos as well, each of
which also will have their own patterns and whitelist.


Actually, you do not need to maintain whitelists manually, just having 
createrepo automatically whitelist all the file deps it finds referenced 
in the indexed repo would solve most of the problem.


If you want to be fancy, you could also add an option to pass it the url 
of another repo is should inherit whitelists from (for updates, epel, 
etc)


Manual whitelists will go stale fast

Regards,

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Golang SIG primary goals?

[Jakub Cajka]

- Original Message -
> From: "Nicolas Mailhot" 
> To: gol...@lists.fedoraproject.org
> Cc: devel@lists.fedoraproject.org
> Sent: Tuesday, August 28, 2018 10:37:06 AM
> Subject: Re: Golang SIG primary goals?
> 
> Hi,
> 
> Just to get people thinking before the meet…
> 
> IMHO, the core objective of the SIG should be to maintain a consistent
> self-hosting up-to-date baseline of Go software in rpm form, that can
> then be used to build other forms of Fedora deliverables (flatpacks,
> coreos images, etc)
> 
> That implies:
> — continuing to improve the go/rpm plumbing
>(packager time should be spent on fixing project-specific problems,
> not writing lots of generic automatable declarations)
> – getting one form of Go packaging guidelines approved by FPC
> – producing a package set that conforms to the above
> – refreshing periodically the set (at least one mass rebuild/version
> refresh per Fedora release).
> – reporting upstream everything that fails in the set to raise the bar
> on the bits we package, gain legitimacy and provide value to upstream –
> ideally also work on fixes but just identifying and reporting problems
> regularly would be a huge first step
> – scrapping all the Fedora Go packages that do not comply. Not a fan of
> zero defect approaches but there is a point where keeping lots of
> obsolete/non conformant packages discourages old and new packagers alike
> 
> I don't really see the point of producing another set of
> bundled/containerized/imaged Go software, there are lots of them on the
> market, the drawbacks are increasingly well known (lots of rotting
> insecure third party code squirreled away inside the bundled sets), I'd
> rather have a smaller breadth of software that can demonstrate a
> software engineering approach than lots of half-assed packages that
> muddle waters and satisfy no one. Though given how Go software in
> massively reusing other code even focusing on a small set of apps will
> require a huge number of packages.
> 
> The areas that need work short term are:
> 
> A packaging
> 
> B cleaning up and consolidating guidelines (need to spread the load as
> it is quite soul crushing work).
> 
> C defining an org to import sets of Go packages within the SIG. Get
> approval to whatever changes in the Fedora process necessary to review
> and import easily apps spread over hundreds of packages (the Fedora
> process is really not geared towards apps that reuse hundreds of other
> projects and require hundreds of packages imported as a set)
> 
> D investigate vgo:
>1. get POC support in go-macros (go-compiler & go-srpm-macros)
>2. test if the result can be used :
>   — are the module definitions written upstream forward-facing or
> locking specific version we can not use
>   – Go devs could not write a dep engine that worked like the rest of
> the software world, rpm included, does it matter in practice if
> dependency declarations written for the Go dep engine are dumped in the
> rpm dep engine, that follows differing resolution rules
>3. decide if we adopt vgo or not. If yes, probably easier to define
> how to write Fedora-friendly module definitions for projects that lack
> them than try to support an hybrid set of packages (with and without
> module defs). Module defs can be upstreamed as part of the packaging
> 
> E investigate automation of build requires (other SIGs did it but
> there's no support in rpm syntax for it, you need to talk to mock over a
> socket ie code a specific utility)
> 
> D. finishing a working baseline for Fedora Next, then rebase EPEL on it
> and forget about the past (the Go non compiler parts in EPEL have rotten
> to much for anyone to use, and I don't see anyone willing to invest the
> effort that would be required to salvage them in an evolutionary way,
> just accept it, get an exemption, and reboot from working Fedora state)

Could you please turn those in to issue in 
pagure(https://pagure.io/GoSIG/go-sig/issues)? I don't believe that these ML 
will be best for keeping track of those and I'm afraid that they might stay 
rotting here.

> 
> I could spend some time on most of those (though I'd rather pass on B,
> already done my part, and D/E would be the most fun and probably the
> most useful for the rest of the SIG).

For B I would much appreciate if you would mark which parts of your proposals 
got implemented and in which way. It would greatly help anyone picking this 
topic after you. If you really do not plan to finish all the work that you have 
started.

Thanks,

JC

> 
> However, my initial objectives were to produce clean prometheus and
> grafana Fedora packages, I finished the Go part a few months ago, but
> they both include a javascript layer, so I'll probably have to spend
> part of my packaging time on the js front. I'd really prefer if someone
> started a javascript SIG I could offload those to, I really don't have
> the cycles to progress quickly on packaging rules and tooling for two
> 

Re: RFC: Alternative -devel packaging

[Nicolas Mailhot]

Le 2018-08-07 17:33, Adam Jackson a écrit :

Consider a library like libGL. At runtime, you want the drivers it
might load to be installed. But when building an application, you just
need the library itself. If the drivers themselves have non-trivial
dependencies, the buildroot is more likely to fail to compose.


That's a boostraping problem. The general solution is to make our build 
tools bootstrap aware, so they activate bootstrap mode as needed 
automatically, instead of forcing packagers to switch the conditional 
manually in spec files each time a bootstraping situation arises.


Regards,

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Golang SIG primary goals?

[Neal Gompa]

On Tue, Aug 28, 2018 at 7:06 AM Nicolas Mailhot
 wrote:
>
>
> However, my initial objectives were to produce clean prometheus and
> grafana Fedora packages, I finished the Go part a few months ago, but
> they both include a javascript layer, so I'll probably have to spend
> part of my packaging time on the js front. I'd really prefer if someone
> started a javascript SIG I could offload those to, I really don't have
> the cycles to progress quickly on packaging rules and tooling for two
> separate programming languages.
>

The NodeJS SIG absorbed the JavaScript SIG, so those are the folks to talk to.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1622999] New: perl-POE-Component-SSLify-1.012-13.fc30 FTBFS: t/ connect_hook_nodata.t fails with OpenSSL 1.1.1

[bugzilla]

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

Bug ID: 1622999
   Summary: perl-POE-Component-SSLify-1.012-13.fc30 FTBFS:
t/connect_hook_nodata.t fails with OpenSSL 1.1.1
   Product: Fedora
   Version: rawhide
 Component: perl-POE-Component-SSLify
  Assignee: ppi...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: andrea.v...@gmail.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



perl-POE-Component-SSLify-1.012-13.fc30 fails to build in F30 because a test
fails:

$ perl -Ilib t/connect_hook_nodata.t 
ok 1 - SERVER: SSLify_Options 
ok 2 - SERVER: Server_SSLify 
ok 3 - SERVER: SSLify_GetStatus is pending
ok 4 - SERVER: accepted
ok 5 - CLIENT: Client_SSLify 
ok 6 - CLIENT: SSLify_GetStatus is pending
ok 7 - CLIENT: connected
ok 8 - CLIENT: Got callback hook
ok 9 - CLIENT: Status received from callback is OK
ok 10 - CLIENT: SSLify_GetCipher: TLS_AES_256_GCM_SHA384
ok 11 - CLIENT: SSLify_GetStatus is done
ok 12 - SERVER: Got callback hook
not ok 13 - SERVER: Status received from callback is OK
#   Failed test 'SERVER: Status received from callback is OK'
#   at t/connect_hook_nodata.t line 57.
#  got: '0'
# expected: '1'
ok 14 - SERVER: SSLify_GetCipher: TLS_AES_256_GCM_SHA384
not ok 15 - SERVER: SSLify_GetStatus is done
#   Failed test 'SERVER: SSLify_GetStatus is done'
#   at t/connect_hook_nodata.t line 62.
ok 16 - SERVER: client disconnected
1..16
# Looks like you failed 2 tests of 16.

This is triggered by upgrading openssl from 1.1.0 to 1.1.1.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1622996] perl-Git-Repository-1.322-3.fc30 FTBFS: t/ 24-errors.t fails with git 2.19.0

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

Summary|perl-Git-Repository-1.322-3 |perl-Git-Repository-1.322-3
   |.fc30 FTBFS:|.fc30 FTBFS: t/24-errors.t
   ||fails with git 2.19.0



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1622996] New: perl-Git-Repository-1.322-3.fc30 FTBFS:

[bugzilla]

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

Bug ID: 1622996
   Summary: perl-Git-Repository-1.322-3.fc30 FTBFS:
   Product: Fedora
   Version: rawhide
 Component: perl-Git-Repository
  Assignee: jpazdzi...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jpazdzi...@redhat.com,
perl-devel@lists.fedoraproject.org



perl-Git-Repository-1.322-3.fc30 fails to build in F30 because a test fails:

t/23-quiet.t ... ok
#   Failed test '... expected warning'
#   at t/24-errors.t line 216.
#   'error: pathspec 'does-not-exist' did not match any file(s)
known to git at t/24-errors.t line 207.
# '
# doesn't match '(?^:^error: pathspec 'does-not-exist' did not match any
file\(s\) known to git\.)'
#   Failed test 'checkout does-not-exist: died'
#   at t/24-errors.t line 209.
#   'error: pathspec 'does-not-exist' did not match any file(s)
known to git at t/24-errors.t line 207.
# '
# doesn't match '(?^:^error: pathspec 'does-not-exist' did not match any
file\(s\) known to git\.)'
#   Failed test 'checkout does-not-exist: died'
#   at t/24-errors.t line 209.
#   'error: pathspec 'does-not-exist' did not match any file(s)
known to git at t/24-errors.t line 207.
# '
# doesn't match '(?^:^error: pathspec 'does-not-exist' did not match any
file\(s\) known to git\.)'
# Looks like you failed 3 tests of 65.
t/24-errors.t .. 
Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/65 subtests 

This is triggered by upgrading git from 2.18.0-2.fc29.4 to 2.19.0-0.0.rc0.fc30.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Golang SIG primary goals?

[Nicolas Mailhot]

Hi,

Just to get people thinking before the meet…

IMHO, the core objective of the SIG should be to maintain a consistent 
self-hosting up-to-date baseline of Go software in rpm form, that can 
then be used to build other forms of Fedora deliverables (flatpacks, 
coreos images, etc)


That implies:
— continuing to improve the go/rpm plumbing
  (packager time should be spent on fixing project-specific problems, 
not writing lots of generic automatable declarations)

– getting one form of Go packaging guidelines approved by FPC
– producing a package set that conforms to the above
– refreshing periodically the set (at least one mass rebuild/version 
refresh per Fedora release).
– reporting upstream everything that fails in the set to raise the bar 
on the bits we package, gain legitimacy and provide value to upstream – 
ideally also work on fixes but just identifying and reporting problems 
regularly would be a huge first step
– scrapping all the Fedora Go packages that do not comply. Not a fan of 
zero defect approaches but there is a point where keeping lots of 
obsolete/non conformant packages discourages old and new packagers alike


I don't really see the point of producing another set of 
bundled/containerized/imaged Go software, there are lots of them on the 
market, the drawbacks are increasingly well known (lots of rotting 
insecure third party code squirreled away inside the bundled sets), I'd 
rather have a smaller breadth of software that can demonstrate a 
software engineering approach than lots of half-assed packages that 
muddle waters and satisfy no one. Though given how Go software in 
massively reusing other code even focusing on a small set of apps will 
require a huge number of packages.


The areas that need work short term are:

A packaging

B cleaning up and consolidating guidelines (need to spread the load as 
it is quite soul crushing work).


C defining an org to import sets of Go packages within the SIG. Get 
approval to whatever changes in the Fedora process necessary to review 
and import easily apps spread over hundreds of packages (the Fedora 
process is really not geared towards apps that reuse hundreds of other 
projects and require hundreds of packages imported as a set)


D investigate vgo:
  1. get POC support in go-macros (go-compiler & go-srpm-macros)
  2. test if the result can be used :
 — are the module definitions written upstream forward-facing or 
locking specific version we can not use
 – Go devs could not write a dep engine that worked like the rest of 
the software world, rpm included, does it matter in practice if 
dependency declarations written for the Go dep engine are dumped in the 
rpm dep engine, that follows differing resolution rules
  3. decide if we adopt vgo or not. If yes, probably easier to define 
how to write Fedora-friendly module definitions for projects that lack 
them than try to support an hybrid set of packages (with and without 
module defs). Module defs can be upstreamed as part of the packaging


E investigate automation of build requires (other SIGs did it but 
there's no support in rpm syntax for it, you need to talk to mock over a 
socket ie code a specific utility)


D. finishing a working baseline for Fedora Next, then rebase EPEL on it 
and forget about the past (the Go non compiler parts in EPEL have rotten 
to much for anyone to use, and I don't see anyone willing to invest the 
effort that would be required to salvage them in an evolutionary way, 
just accept it, get an exemption, and reboot from working Fedora state)


I could spend some time on most of those (though I'd rather pass on B, 
already done my part, and D/E would be the most fun and probably the 
most useful for the rest of the SIG).


However, my initial objectives were to produce clean prometheus and 
grafana Fedora packages, I finished the Go part a few months ago, but 
they both include a javascript layer, so I'll probably have to spend 
part of my packaging time on the js front. I'd really prefer if someone 
started a javascript SIG I could offload those to, I really don't have 
the cycles to progress quickly on packaging rules and tooling for two 
separate programming languages.


Regards,

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Antonio Trande]

Hello everyone.

> sagitter: lzma


Although LZMA Utils are no longer developed and replaced by XZ, they're
still required by other packages on Fedora.
lzma package is still correctly compiled on fedora 28+, it can endure
for a little while yet as long as all dependent software migrate to XZ.

https://pagure.io/releng/issue/7712


-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Richard W.M. Jones]

On Tue, Aug 28, 2018 at 12:03:26AM +0200, Till Maas wrote:
> dpkg  0 weeks ago   

So this one has caused us trouble.

virt-dib depends on debootstrap (a Debian tool for installing
chroots), and debootstrap obviously depends quite fundamentally on
dpkg.

Apparently virt-dib doesn't fundamentally depend on debootstrap so the
dependency might be removed or downgraded to Recommends/Suggests.

Question:

>   libguestfs (maintained by: mdbooth, ptoscano, rjones)
>   libguestfs-1.39.8-1.fc29.src requires debootstrap = 
> 1.0.102-1.fc29
>   virt-dib-1.39.8-1.fc29.i686 requires debootstrap = 
> 1.0.102-1.fc29

If we change this from a hard requires to a Recommends or Suggests
will that get around the immediate issue?

Of course I understand that it won't provide a maintainer for dpkg,
but will it stop libguestfs from being blocked?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Tomasz Kłoczko]

I think that this list way longer.
It is other quite easy method to filter all those packages which are
now under thread to be removed,
Below oneliner has been executed in directory with yesterday synced
rawhide src.rpm mirror:

[tkloczko@domek fedora]$ for i in {20..30}; do echo "fc$i $( ls -1
?/*fc$i.src.rpm | wc -l)"; done
fc20 1
fc21 29
fc22 22
fc23 33
fc24 117
fc25 18
fc26 85
fc27 107
fc28 391
fc29 20100
fc30 744

Whatever what is <= f28 is potentially already dead or still needs to be fixed.

[tkloczko@domek fedora]$ echo "1+29+22+33+117+18+85+107+391"| bc
803
[tkloczko@domek fedora]$ echo "scale=3; (803*100)/21784" | bc
3.686

So about 3.7% of all Fedora packages are now dead and/or unmaintained.
This number maybe even a bit bigger as similar problem may have some
non-zero number of the *f29.src.rpm packages as well.

IMO first move after bumping Fedora version in rawhide should be
remove all packages from rawhide after finishing mass rebuild of all
packages as it can be done without touching spec files (bumping
%{dist} macro allows to do this).
This should open clean situation on start next Fedora development cycle.
On next %{dist} bump whatever what was not possible successfully
rebuild from FedoraVer-2 should be *automatically orphaned*.

Additionally on moving every few days new batches of packages to
rawhide IMO it may be published list of the packages which will be
automatically orphaned if no one will take care of correcting build of
those packages against rawhide.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Automating Package Review

[Nicolas Mailhot]

Le 2018-08-16 22:09, Stephen Gallagher a écrit :


I'd *really* like to see us get to a point where package review is
fully-automated. Basically we could just have a web-service that you
pass a URL to an SRPM plus authenticate with your FAS account and it
will perform all of the validity checks and if they all pass would go
ahead and request the branches for you and import the SRPM.


Please oh please make it an SRPM set. Broadband and git made it so easy 
to reuse other software projects, software is increasingly spread over 
many many components. So old-style "review srpm in isolation, because it 
uses at most a dozen other first-level projects, that are probably 
already packaged" does not work anymore.


Better guidelines and rpm tooling made it easy to create unbundled srpm 
sets, but review didn't evolve and is a painful choke point.


So one of the main reasons for Fedora manual reviews (catching bundling) 
is also one of the main reasons people push for bundling exemptions 
(manual review of unbundled packages does not scale). The current 
process is actively working against its stated objectives.


Regards,

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1619655] Upgrade perl-Lingua-EN-Sentence to 0.31

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Lingua-EN-Sentence-0.3
   ||1-1.fc30
   ||perl-Lingua-EN-Sentence-0.3
   ||1-1.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-08-28 05:58:05



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Akira TAGOH]

On Tue, Aug 28, 2018 at 7:04 AM Till Maas  wrote:
> VLGothic-fonts orphan 55 weeks ago

This has been renamed to vlgothic-fonts quite while ago so we could
safely remove it.

> The following packages require above mentioned packages:
> Depending on: Canna (2), status change: 2017-11-09 (41 weeks ago)
> kinput2 (maintained by: tagoh)
> kinput2-v3.1-60.fc29.i686 requires Canna = 3.7p3-55.fc29, 
> libcanna16.so.1
> kinput2-v3.1-60.fc29.src requires Canna-devel = 3.7p3-55.fc29

I've orphaned it too.

> uim (maintained by: tagoh)
> uim-1.8.6-18.fc29.src requires Canna-devel = 3.7p3-55.fc29
> uim-canna-1.8.6-18.fc29.i686 requires Canna = 3.7p3-55.fc29

Dropped deps.

--
Akira TAGOH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Bastien Nocera]

- Original Message -
> So audiofile has eight current maintainers (plus all of gnome-sig) but
> somehow none of those maintainers has admin privileges on the
> repository.  Would any of the maintainers like be made an admin so that
> SDL and everything that depends on it can drop out of this report?
> 
> Just let me know and I'll make the change for you.

Please consider it to be orphan, for all intents and purposes.

audiofile hasn't been a dependency of GNOME since the days of esound, so
somebody will need to pick it up and care for it.

Cheers
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Till Maas]

Hi,

On Tue, Aug 28, 2018 at 11:00:54AM +0200, Bob Mauchin wrote:
> 
> Can someone reassign dnscrypt-proxy to me, eclipseo, I have updated the
> project recently and I follow upstream closely. What's the procedure to
> adopt it?

I assigned it to you. The usual process is to file a releng ticket at
https://pagure.io/releng/new_issue

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Till Maas]

Hi,

On Tue, Aug 28, 2018 at 04:56:58PM +1000, Dan Callaghan wrote:
> Excerpts from Till Maas's message of 2018-08-28 00:03 +02:00:
> > python-configobj   fale, lmacken, orphan, 45 weeks ago  
> >terjeros 
> [...]
> 
> I will take python-configobj if nobody else will... BUT I don't quite 
> understand what this means.
> 
> Pagure shows the owners as:
> 
> orphan (orphan) - main admin
> Fabio Alessandro Locati (fale) - admin
> lmacken (lmacken) - admin
> Terje Røsten (terjeros) - commit
> 
> The package has no open bugs and is not failing in Koschei so I do not 
> see any reason why it needs to be retired.
> 
> What does it mean for a package to be owned by orphan while it still has 
> other admins who are real people?

Technically it means that new bug reports will not be assigned to any of
these admins but the orphan user. It will make the support status of the
package unclear for everyone looking at it. For example Luke (lmacken)
does not appear to be active in Fedora anymore (IIRC there was also a
non-responsive maintainer process initiated).

> Is this some kind of edge case where the package was owned by 
> a maintainer who was inactive, and thus their packages got "orphaned", 
> even though there are still other maintainers? Is there any record where 
> we can see when or why these changes were made?

Unfortunately, there does not seem to be a record anymore since pkgdb
was retired. I assumed it would be visible in fedmsg/datagrepper but it
does not seem to be. However, this might also mean that co-maintainer do
not get a notification when a package is orphaned.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Miro Hrončok]

On 28.8.2018 11:00, Bob Mauchin wrote:



On Tue, 28 Aug 2018, 00:04 Till Maas, > wrote:


The following packages are orphaned or depend on an orphaned package
and will be retired, soon, unless someone adopts them. If you know
for sure that
the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the
affected
packages or a package that depends on one. Please adopt the affected
package or
adjust your depending package to avoid broken dependencies,
otherwise your
package will be retired when the affected package gets retired.

           Package                    (co)maintainers 
Status Change

===
dnscrypt-proxy                 comzeradd, eclipseo, orphan    5
weeks ago


Can someone reassign dnscrypt-proxy to me, eclipseo, I have updated the 
project recently and I follow upstream closely. What's the procedure to 
adopt it?


https://pagure.io/releng/issues


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Bob Mauchin]

On Tue, 28 Aug 2018, 00:04 Till Maas,  wrote:

> The following packages are orphaned or depend on an orphaned package
> and will be retired, soon, unless someone adopts them. If you know for
> sure that
> the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the
> affected
> packages or a package that depends on one. Please adopt the affected
> package or
> adjust your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
>   Package(co)maintainers  Status
> Change
> ===
> dnscrypt-proxy comzeradd, eclipseo, orphan5 weeks ago
>

Can someone reassign dnscrypt-proxy to me, eclipseo, I have updated the
project recently and I follow upstream closely. What's the procedure to
adopt it?

Best regards,

Robert-André

>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fwd: fedora-tagger sunset - week post F29 beta freeze

[Petr Pisar]

On 2018-08-28, Mattia Verga  wrote:
>> On 2018-08-26, Mattia Verga >  :(
>> 
>> -- Petr
> The Group tag would not fix exactly what I mean. I wouldn't want to
> create groups of packages, but apply descriptive tags of the abilities
> of the package.
>
I was proposing repurposing the Group tag. Nobody uses it for installing
package groups nowadays. Actually I don't think it ever was used like
that. It was always used more like a category.

> For example, in some of the packages I maintain:
> ccdciel: astronomy, astrophotography, imaging, telescope

For example in ccdciel package:
Group: astronomy, astrophotography, imaging, telescope

However I don't know if Group is a scalar or a vector. Vector tag would
be more suitable, so that a package manager got the list already parsed
as:

Group: astronomy
Group: astrophotography
Group: imaging
Group: telescope

> ... so that a user can search for those tags in a package manager,
> instead of searching Google to find what software can do what he's
> searching for and then search for that package in the package manager
> to find if Fedora ships it.
>
This works now:

$ dnf -q repoquery --qf '%{GROUP} %{NAME}' | grep Games

If yum repodata provided a reverse index (a mapping from a group to
package names), then "dnf -q repoqeury --what-group Games" would also
work.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Zbigniew Jędrzejewski-Szmek]

On Tue, Aug 28, 2018 at 04:56:58PM +1000, Dan Callaghan wrote:
> Excerpts from Till Maas's message of 2018-08-28 00:03 +02:00:
> What does it mean for a package to be owned by orphan while it still has 
> other admins who are real people?
> 
> Is this some kind of edge case where the package was owned by 
> a maintainer who was inactive, and thus their packages got "orphaned", 
> even though there are still other maintainers? Is there any record where 
> we can see when or why these changes were made?
> 

Hi,

FESCo voted yesterday to "send info to all co-maintainers and
fedora-devel, [...] after a week reassign to one co-maintainer, if no
co-maintainers, retire". The text in Till's mail was not adjusted to
reflect this. Nevertheless, the plan is to do what was voted.

The reason why we don't just reassign all packages to co-maintainers
right now is that often it's not clear which if any of the other
maintainers are active. So in this first round we ask people to
take ownership explicitly, and will do the automatic procedure for
the rest.

> And is the solution here that one of the existing co-maintainers should 
> just go into the Pagure settings and click... some button to become the 
> "main admin" so that it's no longer orphaned?

Unfortunately there is no "button" in pagure, and the process to take
a package is a manual releng ticket.

Yeah, it's all quite a bit more manual and messy than it should be.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1622479] perl-Gearman-2.004.015 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Gearman-2.004.015-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-e35dce1f57

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1622479] perl-Gearman-2.004.015 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Gearman-2.004.015-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-2f51eeccf0

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1622479] perl-Gearman-2.004.015 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Gearman-2.004.015-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-6f39f62cb5

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1622479] perl-Gearman-2.004.015 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Gearman-2.004.015-1.fc
   ||30



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fwd: fedora-tagger sunset - week post F29 beta freeze

[Mattia Verga]

> On 2018-08-26, Mattia Verga   :(
> 
> -- Petr
The Group tag would not fix exactly what I mean. I wouldn't want to create 
groups of packages, but apply descriptive tags of the abilities of the package.
For example, in some of the packages I maintain:
ccdciel: astronomy, astrophotography, imaging, telescope
skychart: astronomy, telescope, planetarium
kpmcore: administration, disk, partition, utility

... so that a user can search for those tags in a package manager, instead of 
searching Google to find what software can do what he's searching for and then 
search for that package in the package manager to find if Fedora ships it.

Mattia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Dan Callaghan]

Excerpts from Till Maas's message of 2018-08-28 00:03 +02:00:
> python-configobj   fale, lmacken, orphan, 45 weeks ago  
>terjeros 
[...]

I will take python-configobj if nobody else will... BUT I don't quite 
understand what this means.

Pagure shows the owners as:

orphan (orphan) - main admin
Fabio Alessandro Locati (fale) - admin
lmacken (lmacken) - admin
Terje Røsten (terjeros) - commit

The package has no open bugs and is not failing in Koschei so I do not 
see any reason why it needs to be retired.

What does it mean for a package to be owned by orphan while it still has 
other admins who are real people?

Is this some kind of edge case where the package was owned by 
a maintainer who was inactive, and thus their packages got "orphaned", 
even though there are still other maintainers? Is there any record where 
we can see when or why these changes were made?

And is the solution here that one of the existing co-maintainers should 
just go into the Pagure settings and click... some button to become the 
"main admin" so that it's no longer orphaned?

-- 
Dan Callaghan 
Senior Software Engineer, Products & Technologies DevOps
Red Hat


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org