New font package

[Iñaki Ucar]

Hi,

I've submitted a new font package for review [1], but I have 0
experience with fonts (I need it to unbundle it from [2]), and I found
the documentation about font packages a little bit outdated. It's a
pretty simple font (OFL, single family with a couple of styles), but
it would be great if someone with experience in font packaging could
take the review.

Iñaki

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1807239
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1803528
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

State of FMN (FedMSG Notifications) and Replacement

[Clement Verna]

Hi all,

FMN (https://apps.fedoraproject.org/notifications) is currently one of the
main blocking point for dropping fedmsg in favour of fedora-messaging.
FMN is quite important to the community and the composition of Fedora
because it gives emails and notifications on commits, composes, builds and
updates via email and other tools.

However, the code base is written in Python 2.7 and not maintained anymore.
Currently the service has to run on a Fedora 28 system to continue running.
This causes multiple problems and concerns, and needs to be addressed
before the datacenter move in June.

In order to start putting together a specification for a replacement, we
should try to look at the minimum requirements for a notification system.
For example the current system supports sending notifications to IRC,
emails and SSE (Server Sent Event), Can we live without SSE ? Can we live
without IRC ? Do we need it to monitor everything it does currently or just
a subset of items that the community has found useful.

Let's use this thread to brainstorm ideas on what we need.

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

Re: [Test-Announce] New Release Freeze Times

[Thomas Moschny]

Am Di., 25. Feb. 2020 um 20:37 Uhr schrieb Matthew Miller
:
> > Whereas with 12h clocks, I think midnight is 12:00 PM, and noon is 12:00
> > AM? Which is still confusing me after having known about it for decades.
>
> It's the opposite, which furthers your point. :)

That does not seem to be very clear:
https://www.npl.co.uk/resources/q-a/is-midnight-12am-or-12pm
https://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight

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

Fedora-Cloud-30-20200226.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] 389 DS nightly 2020-02-26 - 96% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/02/26/report-389-ds-base-1.4.3.3-20200226gitea4fa54.fc31.x86_64.html
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: Include non-RPM content in buildroot

[Randy Barlow]

On 2/25/20 3:12 PM, Ankur Sinha wrote:

Basically, packages do not pass review merely because they use good
licenses.


Note that I just said that I thought it was the primary purpose, not the 
only purpose.

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

Re: Unannounced SONAME bump in cantor: libcantorlibs.so.23 → 24

[Adam Williamson]

On Tue, 2020-02-25 at 16:11 +0100, Kevin Kofler wrote:
> Fabio Valentini wrote:
> > The recent update from cantor 19.08 to cantor 12.12 in both fedora 32
> > and rawhide bumped the SONAME of a shared library as mention in
> > $SUBJECT (maintainers in CC).
> > 
> > At least LabPlot still needs to be rebuilt on both f32 and rawhide
> > (maintainers in CC).
> 
> Cantor is really an application rather than a public library. It is 
> interesting that LabPlot now links to libcantorlibs, that is something that 
> the Cantor maintainers (KDE SIG, basically) will have to keep in mind. 
> Hopefully this can be coordinated in a better way next time.

If a library is not intended for use by other things, it should not be
installed to the well-known public shared library path. It should be
installed somewhere private to the application and the application
should handle including it in its own library path when appropriate.

If it installs to /usr/lib64 then it's a public library, whether the
author intended that or not...
-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] Please review: 50618 compiler cleanup

[William Brown]

https://pagure.io/389-ds-base/pull-request/50913



—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[Bug 1807263] perl-Getopt-Long-Descriptive-0.105 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
An HTTP error occurred downloading the package's new Source URLs: Getting
https://cpan.metacpan.org/modules/by-module/Getopt/Getopt-Long-Descriptive-0.105.tar.gz
to ./Getopt-Long-Descriptive-0.105.tar.gz

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Spam on closed bugzilla reports

[Jeff Fearn]

On 25/2/20 20:54, Richard W.M. Jones wrote:
> On Mon, Feb 24, 2020 at 10:07:15PM -0800, Luya Tshimbalanga wrote:
>> Hello team,
>>
>> It looks like spammers use closed bug report for their ads as seen
>> in this one:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1644013
>>
>> Can someone maintaining bugzilla investigate the issue?
> 
> There's a self-service way to fix this (I see it's already been done
> in this case, but here it is for the record):
> 
> (1) On the comment click on the little label icon ("Tags").
> 
> (2) Type "spam" into the field and press enter.
> 
> This will hide the comment as spam.
> 
> These spam comment reports are aggregated by the BZ maintainers and
> they will block the spammers' accounts eventually.

This last bit is not quite correct, the blocking happens automatically
when thresholds are exceeded.

https://bugzilla.redhat.com/page.cgi?id=faq.html#getting-help-spam2

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

[Bug 1807263] New: perl-Getopt-Long-Descriptive-0.105 is available

[bugzilla]

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

Bug ID: 1807263
   Summary: perl-Getopt-Long-Descriptive-0.105 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Getopt-Long-Descriptive
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.105
Current version/release in rawhide: 0.104-4.fc32
URL: http://search.cpan.org/dist/Getopt-Long-Descriptive

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/7110/

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: Proposed official change to EPEL guidelines: modules and RHEL

[Stephen Gallagher]

On Tue, Feb 25, 2020 at 5:05 PM Troy Dawson  wrote:
...
> While I agree that we should be very careful with this, I do not
> believe it should be completely off the table.
> I believe it should be permissible with the EPEL Steering Council's
> blessing, but not otherwise.
> Case in point is libssh2.
> It was provided in the original RHEL 8.0 virt module, but not since
> then.  It's causing all sorts of grief, especially when people are
> using both RHEL8 (where you see it) and CentOS8 (where do you don't).
> There is a bugzilla ticket in with the team, but it looks like it's
> going to take a while before a fix get's implemented.
> My proposal is to create a libssh2 module, with a higher NEVR than in
> that original RHEL8 module.
>

OK, I hadn't considered that aspect and I agree with you. Under
*carefully controlled and approved circumstances*, we can permit
updating a package from a different module.
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: Proposed official change to EPEL guidelines: modules and RHEL

[Troy Dawson]

On Tue, Feb 25, 2020 at 1:16 PM Stephen Gallagher  wrote:
>
> On Tue, Feb 25, 2020 at 3:57 PM Matthew Miller  
> wrote:
> >
> > On Tue, Feb 18, 2020 at 04:06:32PM -0800, Kevin Fenzi wrote:
> > > Consider:
> > >
> > > 1. foo rpm that is in the RHEL baseos. It's not in any module.
> > > Can epel make a foo (non default) module that overrides it?
> > >
>
> This is safe from a technical perspective and should be fully endorsed by 
> EPEL.
>

I agree

> > > 2. foo rpm that is in a RHEL default module.
> > > Can epel make a foo (non default) module that overrides it?
> > >
> > > 3. foo rpm that is in a RHEL non default module.
> > > Can epel make a foo (non default) module that overrides it?
>
>
> 2 and 3 are safe from a technical perspective with one major caveat:
> they can only be replaced by an alternate stream of *the same module*.
> This is because otherwise both RPMs will be visible to the package
> manager and the behavior is complicated. I'm actually not sure which
> way it will break; either both sets of RPMs will be visible to the
> transaction and you'll end up with the highest NEVRA, regardless of
> which one you intended to get; or both modules will suppress each
> other and neither of their RPMs will be available. I think it's the
> first case, but either way it should be avoided.
>

I recently talked with the software support group (I think that's
their new name) asking about this, and it is the first.
If two modules are both enabled, even if one is default and the other
not, and the same package is in both, dnf will pick the highest NEVRA.

While I agree that we should be very careful with this, I do not
believe it should be completely off the table.
I believe it should be permissible with the EPEL Steering Council's
blessing, but not otherwise.
Case in point is libssh2.
It was provided in the original RHEL 8.0 virt module, but not since
then.  It's causing all sorts of grief, especially when people are
using both RHEL8 (where you see it) and CentOS8 (where do you don't).
There is a bugzilla ticket in with the team, but it looks like it's
going to take a while before a fix get's implemented.
My proposal is to create a libssh2 module, with a higher NEVR than in
that original RHEL8 module.

> This is also why we (Merlin and I) determined that the `epel-` prefix
> was a non-starter; this case makes that too risky.
>
> If we want to find a way to highlight where a stream is coming from to
> disambiguate EPEL streams from RHEL streams, I think we need to do
> some UX work on `dnf module list` to display the source repo for each
> available stream in a meaningful way.
>
>
> Lastly, I think Petr Pisar is pretty much spot-on with his explanation
> of the EPEL -> RHEL transition; we need to make sure that the
> V(ersion) field in the module stream's NSVCA is higher for the new
> RHEL version than it is in EPEL, similar to what we do with
> non-modular packages today. In that case, DNF will just select the
> RHEL version of the stream as an update to the EPEL version of the
> stream and things should work out fine. The "gotcha" is those cases
> where the EPEL maintainer doesn't know that a RHEL update is coming
> and inadvertently updates to a higher version than RHEL ends up
> delivering. As this case is basically identical to the non-modular RPM
> case, the same mitigation strategies should work (either drop the
> conflicting module contents from the repo or else release a higher
> version in RHEL as an errata).
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Seeking co-maintainer for libffi package

[Florian Weimer]

* Richard Shaw:

> While API/ABI breaking changes within a release is discouraged, it's
> still might be the right thing to do.

libffi within a Fedora release?  That seems rather ... involved because
Python depends on it.

I don't think we'll need ABI changes for CET support, and we plan to
port CET support into Fedora 31's (and 32's) libffi 3.1 version.  But I
won't be able to work on this before April at least.

The justification for the first soname bump (to .7) does not appear to
be correct to me: introducing symbol versioning does not need a soname
bump with the GNU ELF implementation, and the aarch64 change only
affects Mach-O targets, not ELF targets.  The ELF ABI is in fact
unchanged.

If I'm counting correctly, we currently use only 20 out of 36 bytes for
the aarch64 trampoline, so there's room for future BTI support as well.

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

Fedora-32-20200225.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 25/160 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-32-20200224.n.0):

ID: 527306  Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/527306
ID: 527316  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/527316
ID: 527331  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/527331
ID: 527342  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/527342
ID: 527436  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/527436

Old failures (same test failed in Fedora-32-20200224.n.0):

ID: 527318  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/527318
ID: 527339  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/527339
ID: 527349  Test: x86_64 Workstation-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/527349
ID: 527357  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/527357
ID: 527366  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/527366
ID: 527373  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/527373
ID: 527385  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/527385
ID: 527388  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/527388
ID: 527390  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/527390
ID: 527391  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/527391
ID: 527400  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/527400
ID: 527401  Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/527401
ID: 527408  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/527408
ID: 527413  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/527413
ID: 527416  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/527416
ID: 527429  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/527429
ID: 527441  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/527441
ID: 527448  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/527448
ID: 527449  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/527449
ID: 527454  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/527454
ID: 527455  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/527455

Soft failed openQA tests: 15/160 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-32-20200224.n.0):

ID: 527294  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/527294
ID: 527295  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/527295
ID: 527297  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/527297
ID: 527299  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/527299
ID: 527302  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/527302
ID: 527323  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/527323
ID: 527352  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/527352
ID: 527384  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/527384
ID: 527402  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/527402

Old soft failures (same test soft failed in Fedora-32-20200224.n.0):

ID: 527303  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/527303
ID: 527354  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/527354
ID: 527375  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/527375
ID: 527437  Test: x86_64 universal upgrade_2_kde_64bit
URL: 

Re: Orphaning 'antimony' package

[Elliott Sales de Andrade]

On Tue, 25 Feb 2020 at 12:55, Antonio Trande  wrote:
>
> Hi all.
>
> Antimony (https://src.fedoraproject.org/rpms/antimony) is an orphan
> package since today.

Actually, it's orphaned *and retired*. This is not insurmountable for
anyone who wishes to take over, but one does not necessarily imply the
other.

> Feel free to take it.
>
> --
> ---
> Antonio Trande

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

Re: Ideas and proposal for removing changelog and release fields from spec file

[James Cassell]

On Tue, Feb 25, 2020, at 2:53 PM, Matthew Miller wrote:
> On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> > So these are the results of our current investigations, we are very much 
> > eager
> > to get your feedback on them and even more eager if you have ideas on how to
> > approach/solve some of the challenges mentioned here.
> 
> This all sounds great. I'd also love for there to be a standard way of
> tagging specific git commit log messages as meant for user consumption, and
> use that to prepopulate the bodhi release notes field (with an eventual eye
> towards making this the single source of Fedora package change information).
> 

Indeed, it is unfortunate that the Bodhi info for EOL releases is currently 
lost.

V/r,
James Cassell
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

[Stephen Gallagher]

On Tue, Feb 25, 2020 at 3:57 PM Matthew Miller  wrote:
>
> On Tue, Feb 18, 2020 at 04:06:32PM -0800, Kevin Fenzi wrote:
> > Consider:
> >
> > 1. foo rpm that is in the RHEL baseos. It's not in any module.
> > Can epel make a foo (non default) module that overrides it?
> >

This is safe from a technical perspective and should be fully endorsed by EPEL.

> > 2. foo rpm that is in a RHEL default module.
> > Can epel make a foo (non default) module that overrides it?
> >
> > 3. foo rpm that is in a RHEL non default module.
> > Can epel make a foo (non default) module that overrides it?


2 and 3 are safe from a technical perspective with one major caveat:
they can only be replaced by an alternate stream of *the same module*.
This is because otherwise both RPMs will be visible to the package
manager and the behavior is complicated. I'm actually not sure which
way it will break; either both sets of RPMs will be visible to the
transaction and you'll end up with the highest NEVRA, regardless of
which one you intended to get; or both modules will suppress each
other and neither of their RPMs will be available. I think it's the
first case, but either way it should be avoided.

This is also why we (Merlin and I) determined that the `epel-` prefix
was a non-starter; this case makes that too risky.

If we want to find a way to highlight where a stream is coming from to
disambiguate EPEL streams from RHEL streams, I think we need to do
some UX work on `dnf module list` to display the source repo for each
available stream in a meaningful way.


Lastly, I think Petr Pisar is pretty much spot-on with his explanation
of the EPEL -> RHEL transition; we need to make sure that the
V(ersion) field in the module stream's NSVCA is higher for the new
RHEL version than it is in EPEL, similar to what we do with
non-modular packages today. In that case, DNF will just select the
RHEL version of the stream as an update to the EPEL version of the
stream and things should work out fine. The "gotcha" is those cases
where the EPEL maintainer doesn't know that a RHEL update is coming
and inadvertently updates to a higher version than RHEL ends up
delivering. As this case is basically identical to the non-modular RPM
case, the same mitigation strategies should work (either drop the
conflicting module contents from the repo or else release a higher
version in RHEL as an errata).
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: LWT 5.1.2? (was: Re: OCaml 4.10.0 build in Fedora 32 and 33)

[Richard W.M. Jones]

On Tue, Feb 25, 2020 at 12:22:10PM -0800, Michel Alexandre Salim wrote:
> > On February 25, 2020 3:38 AM Richard W.M. Jones  wrote:
> > 
> >  
> > In the previous mass build LWT FTBFS because the tests failed on POWER
> > and s/390 (https://bugzilla.redhat.com/1792780).  There is also a new
> > version of LWT (https://bugzilla.redhat.com/1755859).  The new version
> > is noted as an API break, although I don't know how that will affect
> > other packages.
> > 
> > Anyway I did manage to update LWT to 5.1.2, fix a few things, and do a
> > scratch build.  The tests even pass on all arches:
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=41885170
> > 
> Sounds great. I'd say push this for Rawhide and FC32, and maybe update FC31 
> later if necessary?

Well I can push it to Rawhide.  I will see how it goes before doing
other branches, as it may require other dependent packages to be
updated also because of the ABI break (I don't know if this is true or
not - will need to see).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Any automatic help to generate extra Require dependencies?

[José Abílio Matos]

On Tuesday, 25 February 2020 17.35.04 WET Miro Hrončok wrote:
> Not yet. See also https://github.com/rpm-software-management/rpm/issues/1061

Thank you. It is nice to know that this is being worked (even if as a thought 
experiment). :-)

Manually working with this is not difficult but it is cumbersome and error 
prone, like it is described by you at some point in the messages.

-- 
José Abílio

___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org

[Bug 1655461] w3c-markup-validator-20.2.26 is available

[bugzilla]

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



--- Comment #9 from Upstream Release Monitoring 
 ---
The following Sources of the specfile are not valid URLs so we cannot
automatically build the new version for you.  Please use URLs in your Source
declarations if possible.

- w3c-markup-validator-20.2.26.tar.xz
- w3c-markup-validator-prepare-tarball.sh

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1655461] w3c-markup-validator-20.2.26 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|w3c-markup-validator-20.1.2 |w3c-markup-validator-20.2.2
   |is available|6 is available



--- Comment #8 from Upstream Release Monitoring 
 ---
Latest upstream release: 20.2.26
Current version/release in rawhide: 1.3-18.fc32
URL: https://validator.github.io/validator/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/5111/

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: Proposed official change to EPEL guidelines: modules and RHEL

[Matthew Miller]

On Tue, Feb 18, 2020 at 04:06:32PM -0800, Kevin Fenzi wrote:
> Consider:
> 
> 1. foo rpm that is in the RHEL baseos. It's not in any module. 
> Can epel make a foo (non default) module that overrides it?
> 
> 2. foo rpm that is in a RHEL default module. 
> Can epel make a foo (non default) module that overrides it?
> 
> 3. foo rpm that is in a RHEL non default module. 
> Can epel make a foo (non default) module that overrides it?
> 
> I think we all agree 3 is fine. 
> I think 2 could cause problems, but perhaps it would work. 
> I would think 1 would be fine also. 

These should all be fine. In the case of 2, it's just now another alternate
non-default stream. It would only override if explicitly asked for. 


-- 
Matthew Miller

Fedora Project Leader
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: Proposed official change to EPEL guidelines: modules and RHEL

[Matthew Miller]

On Tue, Feb 18, 2020 at 05:09:04PM +0100, Petr Pisar wrote:
> So the bottom line is: Prefixed streams should provide a bullet proof
> mitigation. Until DNF gains the ability to obsolete a stream, there will be
> slight risk of creeping out-dated EPEL content into the installation.

A prefix also makes it immediately obvious that a stream is EPEL and not
product or supported.



-- 
Matthew Miller

Fedora Project Leader
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: LWT 5.1.2? (was: Re: OCaml 4.10.0 build in Fedora 32 and 33)

[Michel Alexandre Salim]

> On February 25, 2020 3:38 AM Richard W.M. Jones  wrote:
> 
>  
> In the previous mass build LWT FTBFS because the tests failed on POWER
> and s/390 (https://bugzilla.redhat.com/1792780).  There is also a new
> version of LWT (https://bugzilla.redhat.com/1755859).  The new version
> is noted as an API break, although I don't know how that will affect
> other packages.
> 
> Anyway I did manage to update LWT to 5.1.2, fix a few things, and do a
> scratch build.  The tests even pass on all arches:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=41885170
> 
Sounds great. I'd say push this for Rawhide and FC32, and maybe update FC31 
later if necessary?

Best,

-- 
Michel Alexandre Salim 
 profile: https://keybase.io/michel_slm 
 GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Rawhide-20200225.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 18/160 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-Rawhide-20200224.n.0):

ID: 527154  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/527154
ID: 527190  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/527190

Old failures (same test failed in Fedora-Rawhide-20200224.n.0):

ID: 527156  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/527156
ID: 527211  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/527211
ID: 527223  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/527223
ID: 527226  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/527226
ID: 527228  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/527228
ID: 527229  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/527229
ID: 527238  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/527238
ID: 527239  Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/527239
ID: 527246  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/527246
ID: 527251  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/527251
ID: 527254  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/527254
ID: 527267  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/527267
ID: 527279  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/527279
ID: 527286  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/527286
ID: 527287  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/527287
ID: 527292  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/527292
ID: 527293  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/527293

Soft failed openQA tests: 16/160 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-Rawhide-20200224.n.0):

ID: 527132  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/527132
ID: 527133  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/527133
ID: 527137  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/527137
ID: 527140  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/527140
ID: 527158  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/527158
ID: 527161  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/527161
ID: 527170  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/527170
ID: 527222  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/527222
ID: 527240  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/527240

Old soft failures (same test soft failed in Fedora-Rawhide-20200224.n.0):

ID: 527135  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/527135
ID: 527141  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/527141
ID: 527192  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/527192
ID: 527213  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/527213
ID: 527275  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/527275
ID: 527278  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/527278
ID: 527285  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/527285

Passed openQA tests: 123/160 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20200224.n.0):

ID: 527134  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/527134
ID: 527138  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/527138
ID: 527139  Test: 

Re: Include non-RPM content in buildroot

[Ankur Sinha]

On Tue, Feb 25, 2020 14:41:34 -0500, Matthew Miller wrote:
> On Mon, Feb 24, 2020 at 10:35:08AM +, Ankur Sinha wrote:
> > > One thing that comes to my mind with this proposal is that we still need
> > > some way to vet licenses. Today, this is done via the package review
> > > process, and in my mind is the primary purpose of package review. If we
> > > started having upstream compatible registries, I suppose we could 
> > > introduce
> > > a review process for adding packages to the registries to solve this
> > > concern.
> > Vetting of licenses is only one aspect of the review but not its sole
> > purpose. Apart from all the other checks to ensure that the software
> > follows current best practices in software development, we also verify
> > the correctness of the software during the review.
> 
> That's true, but I think fundamentally I agree with Randy: if the software
> is terrible in some way but still useful to users (hello, Chromium!), we
> probably want to find some room for it in Fedora somehow. 

Sure, but only if it works (correctness).

> But we absolutely need to be sure about licenses.

Yes, the legal requirement merely sets the lowest bar for inclusion of
software: it must be legally allowed to be even considered for
inclusion. So, it is a compulsory part of the review process, but so are
other checks. I give correctness as an example because it's easiest to
understand: if the software is legally acceptable, but doesn't build or
work properly, then it doesn't pass the review either.

Basically, packages do not pass review merely because they use good
licenses.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Autoclosure of review requests?

[Mattia Verga via devel]

Il 24/02/20 23:04, Ben Cotton ha scritto:

> In the weekly Fedora program update that I publish on 
> communityblog.fedoraproject.org, I have started to include a count of the 
> open package review requests. As of this moment, there are ~1300 open review 
> requests. Some of these were opened in 2006.

Have a look at https://mattia.fedorapeople.org/review_stats/

These pages were generated by the script at 
https://pagure.io/Fedora-Infra/review_stats which should replace (?) the actual 
script that generates https://fedoraproject.org/PackageReviewStatus/

In general, both the old and new pages can give you a hint of why a review 
ticket is stuck. The newer script hides less tickets than the older.

Mattia___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas and proposal for removing changelog and release fields from spec file

[Matthew Miller]

On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> So these are the results of our current investigations, we are very much eager
> to get your feedback on them and even more eager if you have ideas on how to
> approach/solve some of the challenges mentioned here.

This all sounds great. I'd also love for there to be a standard way of
tagging specific git commit log messages as meant for user consumption, and
use that to prepopulate the bodhi release notes field (with an eventual eye
towards making this the single source of Fedora package change information).

-- 
Matthew Miller

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

Re: Non installable package on F31: python3-i3ipc

[Eduard Lucena]

Thanks for the answer.

I make a comment in the bug.

El mar., 25 feb. 2020 a las 16:42, Scott Talbert ()
escribió:

> On Tue, 25 Feb 2020, Eduard Lucena wrote:
>
> > Hello team,
> >
> > I'm writing this here, because I don't know of any other place, so if
> there
> > is another place to report it, I'll listen to go there.
> >
> > I'm trying to install the package: python3-i3ipc
> >
> > $ sudo dnf info python3-i3ipc
> > Last metadata expiration check: 0:02:42 ago on Tue 25 Feb 2020 02:18:22
> PM
> > -03.
> > Available Packages
> > Name : python3-i3ipc
> > Version  : 1.5.1
> > Release  : 4.fc31
> > Architecture : noarch
> > Size : 29 k
> > Source   : python-i3ipc-1.5.1-4.fc31.src.rpm
> > Repository   : fedora
> > Summary  : An improved Python library to control i3wm
> > URL  : https://github.com/acrisci/i3ipc-python
> > License  : BSD
> > Description  :
> >  : i3's interprocess communication (or ipc) is the interface
> > i3wm uses to receive
> >  : commands from client applications such as i3-msg. It also
> > features
> >  : a publish/subscribe mechanism for notifying interested
> > parties of window
> >  : manager events.
> >  :
> >  : i3ipc-python is a Python library for controlling the
> window
> > manager. This
> >  : project is intended to be useful for general scripting,
> and
> > for applications
> >  : that interact with the window manager like status line
> > generators, notification
> >  : daemons, and pagers.
> >
> >
> > But I get the following error:
> >
> > $ sudo dnf install python3-i3ipc
> > Last metadata expiration check: 0:03:09 ago on Tue 25 Feb 2020 02:18:22
> PM
> > -03.
> > Error:
> >  Problem: conflicting requests
> >   - nothing provides python3.7dist(enum-compat) needed by
> > python3-i3ipc-1.5.1-4.fc31.noarch
> > (try to add '--skip-broken' to skip uninstallable packages)
> >
> > I'm reporting it, because the package is coming from the Fedora repo, not
> > from a 3rd party repos, so I assume that we should provide it and should
> be
> > installable.
> >
> >
> > If this is the wrong place, please guide me to the right place. Thanks a
> lot
> > for your efforts and time to keep fedora great.
>
> Usually the best place to report a bug about a specific package is
> bugzilla.  It appears this bug has already been reported.  However, it has
> been open for a few months without any response:
> https://bugzilla.redhat.com/show_bug.cgi?id=1770839
>
> Scott



-- 
Eduard Lucena
Móvil: +56962318010
GNU/Linux User #589060
Ubuntu User #8749
Fedora Marketing Representative
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Citing RPM in academic text

[Ankur Sinha]

Hello,

We're drafting a submission to CNS*2020[1] about NeuroFedora. Would
anyone know if there's a way to formally cite RPM?

Google Scholar gives me this document by Mark Ewing and Eric Troan[2]
from 1996. Should one keep citing this, or does someone know a newer
publication that we should use?


[1] https://www.cnsorg.org/cns-2020
[2] http://mirror.ircam.fr/pub/rpm/docs/paper.ps.gz

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Non installable package on F31: python3-i3ipc

[Scott Talbert]

On Tue, 25 Feb 2020, Eduard Lucena wrote:


Hello team,

I'm writing this here, because I don't know of any other place, so if there
is another place to report it, I'll listen to go there.

I'm trying to install the package: python3-i3ipc

$ sudo dnf info python3-i3ipc
Last metadata expiration check: 0:02:42 ago on Tue 25 Feb 2020 02:18:22 PM
-03.
Available Packages
Name         : python3-i3ipc
Version      : 1.5.1
Release      : 4.fc31
Architecture : noarch
Size         : 29 k
Source       : python-i3ipc-1.5.1-4.fc31.src.rpm
Repository   : fedora
Summary      : An improved Python library to control i3wm
URL          : https://github.com/acrisci/i3ipc-python
License      : BSD
Description  :
             : i3's interprocess communication (or ipc) is the interface
i3wm uses to receive
             : commands from client applications such as i3-msg. It also
features
             : a publish/subscribe mechanism for notifying interested
parties of window
             : manager events.
             :
             : i3ipc-python is a Python library for controlling the window
manager. This
             : project is intended to be useful for general scripting, and
for applications
             : that interact with the window manager like status line
generators, notification
             : daemons, and pagers.


But I get the following error:

$ sudo dnf install python3-i3ipc
Last metadata expiration check: 0:03:09 ago on Tue 25 Feb 2020 02:18:22 PM
-03.
Error:
 Problem: conflicting requests
  - nothing provides python3.7dist(enum-compat) needed by
python3-i3ipc-1.5.1-4.fc31.noarch
(try to add '--skip-broken' to skip uninstallable packages)

I'm reporting it, because the package is coming from the Fedora repo, not
from a 3rd party repos, so I assume that we should provide it and should be
installable.


If this is the wrong place, please guide me to the right place. Thanks a lot
for your efforts and time to keep fedora great.


Usually the best place to report a bug about a specific package is 
bugzilla.  It appears this bug has already been reported.  However, it has 
been open for a few months without any response:

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

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

Re: Include non-RPM content in buildroot

[Matthew Miller]

On Mon, Feb 24, 2020 at 10:35:08AM +, Ankur Sinha wrote:
> > One thing that comes to my mind with this proposal is that we still need
> > some way to vet licenses. Today, this is done via the package review
> > process, and in my mind is the primary purpose of package review. If we
> > started having upstream compatible registries, I suppose we could introduce
> > a review process for adding packages to the registries to solve this
> > concern.
> Vetting of licenses is only one aspect of the review but not its sole
> purpose. Apart from all the other checks to ensure that the software
> follows current best practices in software development, we also verify
> the correctness of the software during the review.

That's true, but I think fundamentally I agree with Randy: if the software
is terrible in some way but still useful to users (hello, Chromium!), we
probably want to find some room for it in Fedora somehow. But we absolutely
need to be sure about licenses.


-- 
Matthew Miller

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

Re: [Test-Announce] New Release Freeze Times

[Matthew Miller]

On Sat, Feb 22, 2020 at 11:06:30AM +0100, Fabio Valentini wrote:
> I assume 00:00 UTC was confusing for people used to the AM/PM (12h) time
> format instead of the 24h format.
> 
> For people used to 24h clocks, it's completely obvious that 00:00 is the
> beginning of the day, and 24:00 is the end of the day (= equivalent to
> 00:00 of the following day).
> 
> Whereas with 12h clocks, I think midnight is 12:00 PM, and noon is 12:00
> AM? Which is still confusing me after having known about it for decades.

It's the opposite, which furthers your point. :)



-- 
Matthew Miller

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

Re: Autoclosure of review requests?

[Till Maas]

On Mon, Feb 24, 2020 at 05:04:26PM -0500, Ben Cotton wrote:

> The usual Bugzilla housekeeping (branching, EOL closure, etc) explicitly
> excludes review request bugs. Having a large number of open, ancient review
> requests isn't exactly harmful, but it's not very helpful either.
> 
> Before I make a proposal to FPC, I thought I'd open a conversation here.
> What does a reasonable cleanup of review requests look like?
> 
> My initial thought is to close all review requests that were opened >2
> years ago, to be performed at the EOL closure for each release.

Here are my thoughts: It depends on who is waiting.

If the submitter is not responding to a reviewer, it makes sense to
close the review request rather soon (maybe after 6 weeks).

If the reviewer is not responding after the submitter updated the review
request, the request should be unassigned to show that it is available
for other reviewers. This should happen rather soon for review requests
from new packagers (blocking NEEDSPONSOR) to keep newcomers on the hook
(maybe after 2 weeks).

If the review request is not moving forward in general, the submitter
should be asked if they still have interest and only if there is no
response, it should be closed. Maybe after 6-12 months.

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Logs for Open NeuroFedora Meeting: 1600 UTC on Tuesday 25th February

[Aniket Pradhan]

Hello there

Here are the logs for today's meeting.

HTML Logs: 
https://meetbot.fedoraproject.org/fedora-neuro/2020-02-25/neurofedora.2020-02-25-16.00.log.html
HTML Minutes: 
https://meetbot.fedoraproject.org/fedora-neuro/2020-02-25/neurofedora.2020-02-25-16.00.html

Minutes in plain text are pasted below.

=
#fedora-neuro: NeuroFedora 2020-02-25
=


Meeting started by MeWjOr at 16:00:16 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-neuro/2020-02-25/neurofedora.2020-02-25-16.00.log.html
.



Meeting summary
---
* Agenda Summary  (MeWjOr, 16:01:45)
  *

https://lists.fedoraproject.org/archives/list/neurofed...@lists.fedoraproject.org/thread/S3P27DFONJTKADIPJNNOVEQSYRQHOR35/
(MeWjOr, 16:03:07)
  * Introductions and roll call  (MeWjOr, 16:03:17)
  * Tasks from last meeting  (MeWjOr, 16:03:21)
  * Pagure tickets  (MeWjOr, 16:03:28)
  * Bugs  (MeWjOr, 16:03:34)
  * Neuroscience query of the week
https://pagure.io/neuro-sig/NeuroFedora/issue/318  (MeWjOr,
16:03:43)
  * Open floor  (MeWjOr, 16:03:47)

* Introductions and roll call  (MeWjOr, 16:03:59)

* Tasks from last meeting on 2020-02-11  (MeWjOr, 16:07:12)
  * Minutes:

https://meetbot.fedoraproject.org/fedora-neuro/2020-02-11/neurofedora.2020-02-11-16.04.html
(MeWjOr, 16:07:29)
  * MeWjOr write event report, send to ML, submit to Mindshare ---
Written a draft so far... Will review and add more stuff soon
(MeWjOr, 16:08:37)
  * MeWjOr e-mail ML with other discussion points that came up during
FOSDEM --- Done  (MeWjOr, 16:08:47)
  * LoKoMurdoK file ticket with Mindshare requesting some NeuroFedora
swag --- waiting for a reply from mindshare  (MeWjOr, 16:09:46)
  * Once the badge has been imported to badges, I'll be able to award
them: https://pagure.io/fedora-badges/issue/678#comment-628475
(FranciscoD, 16:11:06)
  * FranciscoD ask bt0 alciregi if they know how badges are to be given
out manually --- Done.  (MeWjOr, 16:11:12)
  * LoKoMurdoK comment on the ticket thanking riecatnor and asking what
needs to be next: how do we give the badges out, manually to start
with. --- done. Waiting for the badges team to push the badge online
(MeWjOr, 16:11:19)
  * Everyone look for nice brain images with a CC license for the banner
image --- let's do this over this week?  (MeWjOr, 16:11:55)
  * ACTION: lbazan ping on the mindshare ticket for swag  (MeWjOr,
16:13:48)
  * ACTION: Everyone look for nice brain images with a CC license for
the banner image  (MeWjOr, 16:13:52)
  * FranciscoD take care of all the other tickets this week --- I'll
help you with this  (MeWjOr, 16:14:17)
  * ACTION: FranciscoD, MeWjOr take care of all the other tickets this
week  (MeWjOr, 16:14:52)
  * FranciscoD write abstract for CNS*2020 this week also --- did you
write it?  (MeWjOr, 16:15:16)
  * ACTION: FranciscoD finalize the draft of the abstract for CNS*2020
this week also  (MeWjOr, 16:16:00)
  * FranciscoD add some packaging tickets to kanban for folks to test
out --- You added the FTBFS bugs, so great  (MeWjOr, 16:16:30)
  * FranciscoD send a list of FTBFS bugs to ML --- done. ^.^  (MeWjOr,
16:16:45)
  * FranciscoD send out logs, update tickets --- done.  (MeWjOr,
16:17:31)

* Pagure tickets  (MeWjOr, 16:21:04)
  *

https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
(MeWjOr, 16:21:14)
  * LinkedIn Group Research
https://pagure.io/neuro-sig/NeuroFedora/issue/338  (MeWjOr,
16:21:53)
  * ACTION: dan1mal create the LinkedIn group and  post it on the
ticket.  (MeWjOr, 16:25:29)
  * Once the group is active, we will have to add it to
neuro{,blog}.fp.o as well  (MeWjOr, 16:28:45)
  * Estimating team resources:
https://pagure.io/neuro-sig/NeuroFedora/issue/337  (MeWjOr,
16:29:27)
  * LINK:

https://neuroblog.fedoraproject.org/2019/08/07/open-position-neurofedora-is-looking-for-a-spin-lab-master.html
(FranciscoD, 16:38:10)
  * Use teams.fedoraproject.org (Taiga) kanban board for better planning
--- https://pagure.io/neuro-sig/NeuroFedora/issue/336  (MeWjOr,
16:41:36)
  * The next issues are for the comp-neuro lab... Featured apps, banner
images, screenshots, summary and content  (MeWjOr, 16:43:37)
  * https://pagure.io/neuro-sig/NeuroFedora/issue/307  (MeWjOr,
16:49:24)
  * Figure out badges rule to award badge automatically to pagure group
members: https://pagure.io/neuro-sig/NeuroFedora/issue/250  (MeWjOr,
16:51:18)

* Open bugs  (MeWjOr, 16:52:39)
  * Open bugs: https://tinyurl.com/neurofedora-bugs  (MeWjOr, 16:52:50)
  * LINK: https://koji.fedoraproject.org/koji/packageinfo?packageID=2729
(FranciscoD, 16:54:34)
  * AGREED: ?  (MeWjOr, 16:57:25)
  * AGREED:   (MeWjOr, 16:57:30)
  * AGREED:   (MeWjOr, 16:57:33)
  * AGREED: Drop paraview from the image  (MeWjOr, 16:57:51)
  * AGREED: 

[389-devel] please review: PR 50911 - Health check tool DSEldif check fails

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/50911

--

389 Directory Server Development Team
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[Test-Announce] Fedora 32 Branched 20200225.n.0 nightly compose nominated for testing

[rawhide]

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

Notable package version changes:
anaconda - 20200221.n.0: anaconda-32.24.1-1.fc32.src, 20200225.n.0: 
anaconda-32.24.2-1.fc32.src

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

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

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

The individual test result pages are:

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

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

python27 license change

[Miro Hrončok]

Hello. I have updated the python27 package to use the bundled wheels of pip and 
setuptools, so we can update setuptools in rawhide to a version that no longer 
works with Python 2.


Unfortunately, that changes the license from "Python" to this beast:

Python and MIT and ASL 2.0 and BSD and ISC and LGPLv2 and MPLv2.0 and (ASL 2.0 
or BSD)


Technically however, nothing should change (there was a pre-exisitng hard 
requirement on pip/setuptools with such licenses (now combined)).

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Non installable package on F31: python3-i3ipc

[Eduard Lucena]

Hello team,

I'm writing this here, because I don't know of any other place, so if there
is another place to report it, I'll listen to go there.

I'm trying to install the package: python3-i3ipc

$ sudo dnf info python3-i3ipc
Last metadata expiration check: 0:02:42 ago on Tue 25 Feb 2020 02:18:22 PM
-03.
Available Packages
Name : python3-i3ipc
Version  : 1.5.1
Release  : 4.fc31
Architecture : noarch
Size : 29 k
Source   : python-i3ipc-1.5.1-4.fc31.src.rpm
Repository   : fedora
Summary  : An improved Python library to control i3wm
URL  : https://github.com/acrisci/i3ipc-python
License  : BSD
Description  :
 : i3's interprocess communication (or ipc) is the interface
i3wm uses to receive
 : commands from client applications such as i3-msg. It also
features
 : a publish/subscribe mechanism for notifying interested
parties of window
 : manager events.
 :
 : i3ipc-python is a Python library for controlling the window
manager. This
 : project is intended to be useful for general scripting, and
for applications
 : that interact with the window manager like status line
generators, notification
 : daemons, and pagers.


But I get the following error:

$ sudo dnf install python3-i3ipc
Last metadata expiration check: 0:03:09 ago on Tue 25 Feb 2020 02:18:22 PM
-03.
Error:
 Problem: conflicting requests
  - nothing provides python3.7dist(enum-compat) needed by
python3-i3ipc-1.5.1-4.fc31.noarch
(try to add '--skip-broken' to skip uninstallable packages)

I'm reporting it, because the package is coming from the Fedora repo, not
from a 3rd party repos, so I assume that we should provide it and should be
installable.


If this is the wrong place, please guide me to the right place. Thanks a
lot for your efforts and time to keep fedora great.

Best Regards,
Eduard "X3MBoy" Lucena


-- 
Eduard Lucena
Móvil: +56962318010
GNU/Linux User #589060
Ubuntu User #8749
Fedora Marketing Representative
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora & Containers

[Clement Verna]

On Tue, 25 Feb 2020 at 17:07, Michal Schorm  wrote:

> Hello,
>
> Will anybody be able to explain to me the current state of the
> containers & containerization in Fedora, please?
>

Hi Michal,

As you mention in the points below the current state of building containers
in Fedora needs a lot of work. I started the Container SIG couple years
ago, but we did not managed to build a good momentum to it. For a year or
so we had a few people attending meeting and going through some of the
tasks but 2019 has been hard on us and all the container activities have
had a lower priority for each of the members

So currently the SIG is kind of dead . I personally try to focus on the
Fedora base image and make sure it has regular releases and I try to
respond to the bugs on BZ. For layered images I just keep OSBS up to date
and running, but I cannot really work on the tooling improvement and policy
improvement.

If this is something you really would like to see improving, maybe you can
try to resurrect the Container SIG and start with the list of issues you
have listed :-).

Hope that helps.
Clément


>
> I have some questions, but the more I searched for whom & where to
> ask, the more confused I became.
>
> --
>
> 1) There ́s an IRC on freenode, '#fedora-containers' channel.
> The TOPIC set contains the following message:
> "The place for container runtimes and application containers.
> Forums @ https://discussion.fedoraproject.org/c/containers,
> visit the site @ https://containers.fedoraproject.org
> (website operational at some point in August)."
> However no link mentioned are accessible.
>
> 2) There is 'Fedora Container & Tools Documentation' [1]
> It is only half-filled with information, some part missing entirely.
> Even parts as 'Container Guidelines' [2].
> Btw the wiki gladly redirects there ^ [3].
> Btw there are some scratch notes about the guidelines from damn 2017
> [4], which google offers me rather than the actual guidelines (because
> they don't exist)
>
> 3) So ... who is in charge of it? Whom to contact? How? Where?
> Does Fedora count with Containers or does it already thrown it overboard?
>
> 4) The container I am maintainer of (in pagure in 'container'
> namespace) is not branched automatically. The last branch is 'f30',
> but now I want to update it and add the missing branches. I have no
> idea how should I do it though, since (1) (2) are such a mess.
> I can try 'git push', but anyway, it won't solve the issue, it's not
> branched automatically.
>
> 5) The Dockerfile (are we still using this name? shouldn't it be
> 'containerfile' now, with podman?)
> starts with line like:
> " FROM registry.fedoraproject.org/f30/."
> How can I substitute the Fedora release version with a variable, so I
> can share the same content amongst branches for different Fedora
> releases?
>
> [1] https://docs.fedoraproject.org/en-US/containers/
> [2] https://docs.fedoraproject.org/en-US/containers/guidelines/guidelines/
> [3] https://fedoraproject.org/wiki/Container:Guidelines
> [4] https://fedoraproject.org/wiki/Talk:Container:Guidelines
>
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Co

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Co on 2020-02-26 from 18:00:00 to 19:00:00 GMT
   At freenode@fedora-meeting

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting. A general agenda is the 
following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-6
#topic EPEL-7
#topic EPEL-8
#topic Openfloor
#endmeeting




Source: https://apps.fedoraproject.org/calendar/meeting/9672/

___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Downgrading from rawhide

[Andreas Tunek]

Den tis 25 feb. 2020 kl 16:10 skrev Christophe de Dinechin <
dinec...@redhat.com>:

> Is there any documented procedure to safely downgrade from rawhide to
> the latest release?
>
> I tried
>
> # dnf update --releasever=32 fedora-release
> # dnf distro-sync --allowerasing --skip-broken
>
> Does something like that have any chance of working? At first sight, it
> seems to be somewhat successful.
>
>
I did just that a couple of days ago and everything seems to work for me. I
had some slow boot and GDM issues first, but the GDM issues seem to be
solved.

/Andreas

> --
> Cheers,
> Christophe de Dinechin (IRC c3d)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaning 'antimony' package

[Antonio Trande]

Hi all.

Antimony (https://src.fedoraproject.org/rpms/antimony) is an orphan
package since today.
Feel free to take it.

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Any automatic help to generate extra Require dependencies?

[Miro Hrončok]

On 25. 02. 20 18:23, José Abílio Matos wrote:

AFAIU the automatic generated dependencies take care of the first step. Is
there any way, automatic or not, to generate the equivalent of
pip install "Nikola[extras]"?


Not yet. See also https://github.com/rpm-software-management/rpm/issues/1061

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org

Any automatic help to generate extra Require dependencies?

[José Abílio Matos]

Hi,
my case study is nikola (a static pages generator).

I am using the automatically generated dependencies but that only covers the 
Requires part of the spec file.

My question is if there are any tools that people use, working from the setup 
file, to generate the addition fields like the BuildRequires.

In the installation instructions it says:
"""
Installation Instructions

Assuming you have pip installed:

pip install Nikola

For optional features:

pip install "Nikola[extras]"

For tests:

pip install "Nikola[extras,tests]"
"""

AFAIU the automatic generated dependencies take care of the first step. Is 
there any way, automatic or not, to generate the equivalent of
pip install "Nikola[extras]"?

Best regards,
-- 
José Abílio

___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org

Re: Seeking co-maintainer for libffi package

[Richard Shaw]

On Tue, Feb 25, 2020 at 9:57 AM Anthony Green  wrote:

> Hello -- I'm the current Fedora maintainer for libffi, as well as the
> upstream author/maintainer.   I'm looking for help with libffi
> packaging.  Specifically, we need to roll out a new ABI-breaking
> release (required for ARM64 and Intel CET support), and I don't have
> the volunteer time available to create the requisite compat packages,
> monitor all of the rebuilds, etc.   It would be best if this person
> had some Fedora packaging experience under their belt, given some of
> the complexities involved and the criticality of libffi to the whole
> platform.
>

While API/ABI breaking changes within a release is discouraged, it's still
might be the right thing to do. You could create a side tag and make sure
all dependent packages have been rebuilt or ported over first, and them
merge them back in with a single bodhi update.

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

Re: Ideas and proposal for removing changelog and release fields from spec file

[Miro Hrončok]

On 25. 02. 20 15:27, Fabio Valentini wrote:

Side note: I've been meaning to propose dropping Epoch because of this
"we don't care about upgrade path anymore", but I've not gotten around
to do that yet


Unfortunately, that breaks rawhide users.

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Seeking co-maintainer for libffi package

[Antonio Trande]

Add me as co-maintainer, please.
I'm using libffi as dependency for a couple of packages.

On 25/02/20 16:56, Anthony Green wrote:
> Hello -- I'm the current Fedora maintainer for libffi, as well as the
> upstream author/maintainer.   I'm looking for help with libffi
> packaging.  Specifically, we need to roll out a new ABI-breaking
> release (required for ARM64 and Intel CET support), and I don't have
> the volunteer time available to create the requisite compat packages,
> monitor all of the rebuilds, etc.   It would be best if this person
> had some Fedora packaging experience under their belt, given some of
> the complexities involved and the criticality of libffi to the whole
> platform.
> 
> Thanks!
> 
> AG
> 

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ideas and proposal for removing changelog and release fields from spec file

[Miro Hrončok]

On 25. 02. 20 9:50, Pierre-Yves Chibon wrote:

Upgrade path may be problematic if you update Fn to a version in less commit
than the update for Fn-1 (ie: you update F32 to 1.0 in 1 commit and update F31
to 1.0 in 2 commits, suddenly you have F32 with 1.0-1 and F31 with 1.0-2).


I don't consider that an issue. It's not super elegant, but since we do 
distro-sync on upgrades, it shuld be fine.


--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

AAA: FAS Replacement project update

[Sarah Finn]

Hi all,

Please see the latest AAA FAS replacement project update below:

AAA: FAS replacement project update 2/25/20


The month of February was a very busy month for the CPE AAA team and
community contributors working on this initiative. Great progress was made
in the development phase of the AAA: FAS replacement build. Sprint 2 and 3
resulted in the completion of multiple user stories which added user
functionality to join groups, change email address and password, disable
account, database access along with putting a mapping solution in place for
users moving from the current FAS to the new FAS (potential name
incoming!). We also came to the end of developing our wireframes and
mapping our user experience flow. Unit tests were carried out regarding
password controller and the current codebase.

We received great support from the wider CPE team as well as Patrick
Uiterwijk to allow us progress with user stories by gaining permissions and
merging PR’s for the integration of CentOS CI. Christian Heimes assisted us
greatly with sharing his knowledge regarding FREE IPA and answered numerous
questions to allow us to move forward.

Sprint 4 began on Thursday the 20th of February. This sprint will focus on
development tasks which will include working on FAS Json, Free IPA,  API,
Fedora Messaging integration, continuous deployment to stage environment,
developing a secure coding tool to ensure code adheres to best practice, as
well as continuing working on user functionality user stories. Please see
our github board here to
view current activity.

We also received some sad news since our last update, that we are losing a
team member, Rick Elrod, as he moves on to pastures new with the Ansible
team. Rick provided an excellent POC for AAA which is leaving us in good
shape to continue on as planned. Thanks Rick and we will hopefully still
see you around as a contributor going forward. We also welcomed a new team
member Leonardo (Leo) Rossetti who joined at the start of Sprint 4 and has
already hit the ground running. Leo is currently working on our FAS JSON
user stories.

Regarding delivery of AAA, we may look at a phased release , this current
phase focus is on the development of AAA to be delivered by 3/31/20. It is
looking likely that the deployment of AAA will happen in a later phase due
to requiring System Admin assistance. We are likely to gain this on the
completion of the Colo Move (which is our planned data center move),
approximately in mid April. We are enquiring to see if deploying to staging
is possible within this phase to allow for a long testing period. I will
provide an update on this in our next blog. The integration of CentOS will
be worked on within an additional phase following the completion of AAA
centric stories for Fedora.

On a final note, I would like to commend the CPE AAA team on their
collaboration
and productivity throughout this initiative even in the face of unknowns,
team changes, cross team dependencies and other challenges, they continued
to proactively work together and find solutions to keep this initiative
moving forward.

We welcome all feedback, thoughts and contributions as we progress through
this project. Please feel free to comment on any issue to log your
thoughts.


For more information regarding outstanding issues, please see here.

To view our current scrum board, please see here.


Thanks all,
-- 

Sarah Finn

She/Her

Agile Practitioner

Red Hat 

Waterford, Ireland

sf...@redhat.com
M: 0879830832
@RedHat    Red Hat
  Red Hat


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

Re: Fedora & Containers

[Michal Schorm]

Hidden from sight of any mortal man, I've found 'Fedora Container SIG'
with as little information as possible [1], although they state, they have 
notes from 2019 DevConf meetup [2], but locked [3].

Atleast I found first place of discussion! [4]
... if you can say that about bunch of threads with 8k views on single thread, 
but no more than 100 replies in all topics & threads together.

[1] https://fedoraproject.org/wiki/Container_SIG
[2] https://fedoraproject.org/wiki/Container_SIG#Notes_from_meetings
[3] https://public.etherpad-mozilla.org/p/fedoracontainerSIG
[4] https://discussion.fedoraproject.org/c/server/containers
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora & Containers

[Michal Schorm]

Hello,

Will anybody be able to explain to me the current state of the
containers & containerization in Fedora, please?

I have some questions, but the more I searched for whom & where to
ask, the more confused I became.

--

1) There ́s an IRC on freenode, '#fedora-containers' channel.
The TOPIC set contains the following message:
"The place for container runtimes and application containers.
Forums @ https://discussion.fedoraproject.org/c/containers,
visit the site @ https://containers.fedoraproject.org
(website operational at some point in August)."
However no link mentioned are accessible.

2) There is 'Fedora Container & Tools Documentation' [1]
It is only half-filled with information, some part missing entirely.
Even parts as 'Container Guidelines' [2].
Btw the wiki gladly redirects there ^ [3].
Btw there are some scratch notes about the guidelines from damn 2017
[4], which google offers me rather than the actual guidelines (because
they don't exist)

3) So ... who is in charge of it? Whom to contact? How? Where?
Does Fedora count with Containers or does it already thrown it overboard?

4) The container I am maintainer of (in pagure in 'container'
namespace) is not branched automatically. The last branch is 'f30',
but now I want to update it and add the missing branches. I have no
idea how should I do it though, since (1) (2) are such a mess.
I can try 'git push', but anyway, it won't solve the issue, it's not
branched automatically.

5) The Dockerfile (are we still using this name? shouldn't it be
'containerfile' now, with podman?)
starts with line like:
" FROM registry.fedoraproject.org/f30/."
How can I substitute the Fedora release version with a variable, so I
can share the same content amongst branches for different Fedora
releases?

[1] https://docs.fedoraproject.org/en-US/containers/
[2] https://docs.fedoraproject.org/en-US/containers/guidelines/guidelines/
[3] https://fedoraproject.org/wiki/Container:Guidelines
[4] https://fedoraproject.org/wiki/Talk:Container:Guidelines

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

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

Seeking co-maintainer for libffi package

[Anthony Green]

Hello -- I'm the current Fedora maintainer for libffi, as well as the
upstream author/maintainer.   I'm looking for help with libffi
packaging.  Specifically, we need to roll out a new ABI-breaking
release (required for ARM64 and Intel CET support), and I don't have
the volunteer time available to create the requisite compat packages,
monitor all of the rebuilds, etc.   It would be best if this person
had some Fedora packaging experience under their belt, given some of
the complexities involved and the criticality of libffi to the whole
platform.

Thanks!

AG

-- 
Anthony Green 
Senior Principal Solutions Architect, Financial Services
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 32 Beta Freeze

[Mohan Boddu]

Hi all,

Today's an important day on the Fedora 32 schedule[1], with several
significant cut-offs. First of all today is the Bodhi activation point
[2]. That means that from now on all Fedora 32 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 32 Changes must now be code
complete, meaning all the code required to enable 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 32.

Mohan Boddu

[1] https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html
[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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Re: Downgrading from rawhide

[Richard W.M. Jones]

On Tue, Feb 25, 2020 at 04:09:32PM +0100, Christophe de Dinechin wrote:
> Is there any documented procedure to safely downgrade from rawhide to
> the latest release?
> 
> I tried
> 
> # dnf update --releasever=32 fedora-release
> # dnf distro-sync --allowerasing --skip-broken
> 
> Does something like that have any chance of working? At first sight, it
> seems to be somewhat successful.

I have downgraded at least a subset of packages from Rawhide to a
released Fedora in the past, and it can work.

However last week when I did this libvirt broke all networking when
doing this (requiring a reboot and IIRC some manual config file
changes to recover).  Now this wasn't necessarily libvirt's fault
because we only test and it's only guaranteed that things like RPM
scriptlets will work in the forwards direction.  While it's _nice_
that they should work in the reverse direction, it's not required and
it's very rarely tested.

So basically it may work, if it doesn't you get to keep all the pieces,
and it has broken in the past.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Open NeuroFedora Meeting: 1600 UTC on Tuesday, 25th February

[Aniket Pradhan]

Hello there

We will be starting in about 15-20 minutes. It would be great if
people could join the meeting. :D

On Mon, Feb 24, 2020 at 6:48 PM Aniket Pradhan
 wrote:
>
> Hey there!
>
> You are invited to attend the next Open NeuroFedora team meeting this
> week on Tuesday at 1600UTC in #fedora-neuro on IRC (Freenode):
>
> https://webchat.freenode.net/?channels=#fedora-neuro
>
> You can convert the meeting time to your local time using:
> $ date --date='TZ="UTC" 1600 next Tue'
>
> or use this link:
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+Meeting=20200225T16=%3A=1
>
> The meeting will be chaired by @major. The agenda for the meeting is:
>
> - Introductions and roll call.
> - Tasks from last week's meeting: NA
> - Pagure tickets:
> https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
> - Neuroscience query of the week.
> - Next meeting day, and chair.
> - Open floor.
>
> In the "Neuroscience query of the week" section, attendees can ask
> about/discuss a neuroscience topic that they are curious about.
>
>
> We hope to see you there! :D
>
> --
> Thanks
> Regards
>
> Aniket Pradhan
> http://home.iiitd.edu.in/~aniket17133/
> Aliases: MeWjOr/major
>
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments



-- 
Thanks
Regards

Aniket Pradhan
http://home.iiitd.edu.in/~aniket17133/
Aliases: MeWjOr/major

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Downgrading from rawhide

[Stephen John Smoogen]

On Tue, 25 Feb 2020 at 10:10, Christophe de Dinechin 
wrote:

> Is there any documented procedure to safely downgrade from rawhide to
> the latest release?
>
> I tried
>
> # dnf update --releasever=32 fedora-release
> # dnf distro-sync --allowerasing --skip-broken
>
> Does something like that have any chance of working? At first sight, it
> seems to be somewhat successful.
>
>
There are no promises that it will work and no promises that it won't work.
Depending on how far and how much difference there is.. it will most likely
not work without a lot of manual intervention as packagers and packages are
not required to be backwards compatible.



> --
> Cheers,
> Christophe de Dinechin (IRC c3d)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


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

Re: Downgrading from rawhide

[Florian Weimer]

* Christophe de Dinechin:

> Is there any documented procedure to safely downgrade from rawhide to
> the latest release?
>
> I tried
>
> # dnf update --releasever=32 fedora-release
> # dnf distro-sync --allowerasing --skip-broken
>
> Does something like that have any chance of working? At first sight, it
> seems to be somewhat successful.

Due to bug 1652867, you may have to run ldconfig in the resulting shell
if you downgrade from rawhide most time of the year (but not currently).

Other things are likely to break, too, though.

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

Downgrading from rawhide

[Christophe de Dinechin]

Is there any documented procedure to safely downgrade from rawhide to
the latest release?

I tried

# dnf update --releasever=32 fedora-release
# dnf distro-sync --allowerasing --skip-broken

Does something like that have any chance of working? At first sight, it
seems to be somewhat successful.

--
Cheers,
Christophe de Dinechin (IRC c3d)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] Fedora 32 Beta Freeze

[Mohan Boddu]

Hi all,

Today's an important day on the Fedora 32 schedule[1], with several
significant cut-offs. First of all today is the Bodhi activation point
[2]. That means that from now on all Fedora 32 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 32 Changes must now be code
complete, meaning all the code required to enable 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 32.

Mohan Boddu

[1] https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html
[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
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Unannounced SONAME bump in cantor: libcantorlibs.so.23 → 24

[Kevin Kofler]

Fabio Valentini wrote:
> The recent update from cantor 19.08 to cantor 12.12 in both fedora 32
> and rawhide bumped the SONAME of a shared library as mention in
> $SUBJECT (maintainers in CC).
> 
> At least LabPlot still needs to be rebuilt on both f32 and rawhide
> (maintainers in CC).

Cantor is really an application rather than a public library. It is 
interesting that LabPlot now links to libcantorlibs, that is something that 
the Cantor maintainers (KDE SIG, basically) will have to keep in mind. 
Hopefully this can be coordinated in a better way next time.

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

[Bug 1806215] perl-experimental-0.021 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
perl-experimental-0.021-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-3b9be5a93a

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1805790] perl-Alien-pkgconf-0.16 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Alien-pkgconf-0.16-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-0e35fb5d31

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Autoclosure of review requests?

[Fabio Valentini]

On Tue, Feb 25, 2020 at 3:43 PM Ben Cotton  wrote:
>
>
>
> On Mon, Feb 24, 2020, 17:32 Fabio Valentini  wrote:
>>
>>
>> It sounds like you are both not aware that there's actually an
>> existing policy that covers stalled Review Requests:
>> https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews

(snip)

> Ah ha! I thought I remembered seeing something before, but it wasn't on 
> docs.fp.o when I was looking yesterday. That's a separate bug to fix. :-)

I got to thank my firefox browser history. It's an endless repository
of knowledge :-)

> The problem with the existing policy is that it's geared toward review 
> requests that someone is actively paying attention to. If neither there's no 
> reviewer and the submitter just walks away from it, this policy is never 
> executed.
>
> What I'm suggesting is a backstop to that.

Sure, I think it's reasonable to close Review Requests that haven't
been touched in over year, or something like that.
The creation date alone might not be accurate enough, as some old
requests are actually getting picked up and are being worked on.

Fabio

>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Haskell on EPEL 8

[Mark Stopka]

I've subscribed to the bug report,  but I've also spoke with Jens Petersen
on IRC and he said it will be available rather soon =)
--
Best regards / S pozdravem,
BSc. Mark Stopka, BBA

mobile: +420 704 373 561


On Tue, Feb 25, 2020 at 3:26 PM Jos Vos  wrote:

> On Tue, Feb 25, 2020 at 08:56:52AM -0500, Stephen John Smoogen wrote:
>
> > [...]  If you need a set of packages, go to https://bugzilla.redhat.com
> > and check to see if there are outstanding bug tickets requesting a
> > maintainer to support it in EPEL-8. If there are add your info to that
> > ticket, if there are not please open a ticket.
>
> There wasn't one AFAICS, so I opened one:
> https://bugzilla.redhat.com/show_bug.cgi?id=1807043
>
> --
> --Jos Vos 
> --X/OS Experts in Open Systems BV   |   Office: +31 20 6938364
> --Amsterdam, The Netherlands|   Mobile: +31 6 26216181
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
>
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Autoclosure of review requests?

[Ben Cotton]

On Mon, Feb 24, 2020, 17:32 Fabio Valentini  wrote:

>
> It sounds like you are both not aware that there's actually an
> existing policy that covers stalled Review Requests:
> https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews


Ah ha! I thought I remembered seeing something before, but it wasn't on
docs.fp.o when I was looking yesterday. That's a separate bug to fix. :-)

The problem with the existing policy is that it's geared toward review
requests that someone is actively paying attention to. If neither there's
no reviewer and the submitter just walks away from it, this policy is never
executed.

What I'm suggesting is a backstop to that.



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

Re: Ideas and proposal for removing changelog and release fields from spec file

[Fabio Valentini]

On Tue, Feb 25, 2020 at 3:12 PM Pierre-Yves Chibon  wrote:
>
> On Tue, Feb 25, 2020 at 02:55:37PM +0100, Fabio Valentini wrote:
> > On Tue, Feb 25, 2020 at 2:47 PM Remi Collet  
> > wrote:
> > >
> > > Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :
> > >
> > > >   - You can easily opt-in by using the macros
> > >
> > > Please keep opt-in as a mandatory need for such a change.
> > >
> > >
> > > To be clear, I will be (perhaps the only) one to not use it.
> > >
> > >
> > > For now spec file are self-contained, which is nice.
> > >
> > > I don't like the idea of generated / external stuff related
> > > to "storage" or "build system"
> > >
> > >
> > > Sorry, to be again the old bad guy which don't like changes.
> > >
> > > Remi
> >
> > FWIW, I agree. Maybe I'm getting old as well >:-D
> >
> > I don't think it's a good idea to use any information from outside the
> > dist-git repository as a source of truth for anything.
> > The big benefit of only using the git repository as source of
> > information is that it is immutable, reproducible, and cannot be
> > changed after commits have been pushed.
> > The git repository data is also available for working on packages
> > *offline*, in contrast to having to ask koji for the number of builds
> > since X ...
>
> The way I see it is this:
> With the number of commits+number of build idea, you get the same results
> locally and in bodhi.
> Locally fedpkg build or rpmbuild -ba will override the existing RPM
> In koji, it will simply append a .1 to the release to avoid overriding the
> existing RPM.
> But the content and release, except for two characters, will be the same.

(snip)

> That being said, there seems to be a consensus forming about wanting to rely
> only on number of commits (though, we still have the upgrade path issue to 
> sort
> out).

Hi Pierre,

After reporting a few upgrade path bugs for (I think) fedora 28 and
29, I was told that "we don't care about upgrade path anymore", since
"dnf system-upgrade" operates in "distro-sync" mode by default, since
a few releases ago.

So I don't see upgrade path as a (big) concern here. There may be
package downgrades at system-upgrade time, but that's already the case
today - most of the time because either people forget to build for
fedora-branched after the branch point, or because they forget to
submit bodhi updates after update-testing activation point. Whereas
those two are "real" downgrades, any downgrades caused by the new
commit counting would only be "downgrade by number but upgrade in
content".

Fabio

Side note: I've been meaning to propose dropping Epoch because of this
"we don't care about upgrade path anymore", but I've not gotten around
to do that yet ️

> Pierre
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Haskell on EPEL 8

[Jos Vos]

On Tue, Feb 25, 2020 at 08:56:52AM -0500, Stephen John Smoogen wrote:

> [...]  If you need a set of packages, go to https://bugzilla.redhat.com
> and check to see if there are outstanding bug tickets requesting a
> maintainer to support it in EPEL-8. If there are add your info to that
> ticket, if there are not please open a ticket.

There wasn't one AFAICS, so I opened one:
https://bugzilla.redhat.com/show_bug.cgi?id=1807043

-- 
--Jos Vos 
--X/OS Experts in Open Systems BV   |   Office: +31 20 6938364
--Amsterdam, The Netherlands|   Mobile: +31 6 26216181
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Ideas and proposal for removing changelog and release fields from spec file

[Pierre-Yves Chibon]

On Tue, Feb 25, 2020 at 02:55:37PM +0100, Fabio Valentini wrote:
> On Tue, Feb 25, 2020 at 2:47 PM Remi Collet  wrote:
> >
> > Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :
> >
> > >   - You can easily opt-in by using the macros
> >
> > Please keep opt-in as a mandatory need for such a change.
> >
> >
> > To be clear, I will be (perhaps the only) one to not use it.
> >
> >
> > For now spec file are self-contained, which is nice.
> >
> > I don't like the idea of generated / external stuff related
> > to "storage" or "build system"
> >
> >
> > Sorry, to be again the old bad guy which don't like changes.
> >
> > Remi
> 
> FWIW, I agree. Maybe I'm getting old as well >:-D
> 
> I don't think it's a good idea to use any information from outside the
> dist-git repository as a source of truth for anything.
> The big benefit of only using the git repository as source of
> information is that it is immutable, reproducible, and cannot be
> changed after commits have been pushed.
> The git repository data is also available for working on packages
> *offline*, in contrast to having to ask koji for the number of builds
> since X ...

The way I see it is this:
With the number of commits+number of build idea, you get the same results
locally and in bodhi.
Locally fedpkg build or rpmbuild -ba will override the existing RPM
In koji, it will simply append a .1 to the release to avoid overriding the
existing RPM.
But the content and release, except for two characters, will be the same.

That being said, there seems to be a consensus forming about wanting to rely
only on number of commits (though, we still have the upgrade path issue to sort
out).


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

Re: Ideas and proposal for removing changelog and release fields from spec file

[Pierre-Yves Chibon]

On Tue, Feb 25, 2020 at 12:59:39PM +0100, Vít Ondruch wrote:
> 
> Dne 24. 02. 20 v 17:48 Pierre-Yves Chibon napsal(a):
> > Good Morning Everyone,
> >
> > This topic has already been discussed a few times over the past month, but 
> > Adam
> > Saleh, Nils Philippsen and myself have had the opportunity to invest some 
> > time
> > on it with the hope of making the packager's life simpler as well as making 
> > it
> > easier to build automation around our package maintenance.
> >
> > We have investigated a few ideas, the full list with their pros and cons 
> > can be
> > found in this document: https://hackmd.io/8pSwJidhTYel9euQqMEKpw?viev
> > If you have any questions about some of these, please ask them, we'll be 
> > happy
> > to answer them and potentially complete this document.
> >
> >
> > For both the release and the changelog fields we believe using RPM macros 
> > would
> > satisfy the requirements we have for opting-in/out:
> >   - You can easily opt-in by using the macros
> >   - You can easily opt-out by removing the macros from your spec file
> >
> >
> > For the changelog, we believe we have a potential good solution:
> > - The changelog will be automatically generated using an external 
> > `changelog`
> >   file as well as the commit history
> >   - When you opt-in, you will simply move the existing changelog to an 
> > external
> > file `changelog`, which is placed in the dist-git repo and add the
> > appropriate macro.
> 
> 
> I assume you are aware about my PR:
> 
> 
> https://pagure.io/packaging-committee/pull-request/942
> 
> 
> >   - Upon building, the macro will generate the changelog using all the 
> > commits
> > of the repo up to the last commit touching the `changelog` file.
> 
> 
> I proposed, that the changelog file is either included in the repository
> or it is not included (probably listed in .gitignore). So it is either
> used as it is or if later, then it is generated.
> 
> You propose mixture if I understand it correctly. I.e. the changelog
> file is always present in the dist-git and it is always is used. But if
> there are more recent commits without changelog modifications, they are
> prepended to the changelog, but the changelog file itself stays
> untouched. E.g. if my latest commit modifies the changelog, the
> changelog as it is present in the repo will be used without any
> modifications.
> 
> I like it. It is opt-in, because I have to place some macro into .spec
> file and it is even more or less bacward compatible, because the
> automation kicks in only if I don't maintain the changelog manually.
 
That is correct.
I was aware of the PR to the FPC which actually contributed to this idea
(figuring out the last commit that changed the `changelog` file is way easier
than the last commit that changed %changelog in the spec file).
So thanks for this!
 

[About the release field]

> I am not really sure about this. How do you envision this is going to be
> implemented? Is there going to be "release" file, similarly to
> changelog, which would help me to override this? Because, currently, it
> seems that both methods are going to need a lot of information from the
> build system. 

The first method using number of commits and number of builds, pull limited
information from the build system (just: how many builds succeed before this one
with this version and release?).
The second method does rely heavily on the build system.

> They will need to parse .spec file etc. I don't see this
> to be able to handle even a bit more complex stuff like e.g.
> https://src.fedoraproject.org/rpms/ruby/blob/master/f/ruby.spec#_26

We've been trying to find something that fit the majority of the packages but we
are well aware that there are and will always be some special snowflakes that
will not be able to adhere to this.
I'd be happy if this works makes life/packaging easier for 50% of our packages
(I'd even probably be happy if it's 20%).
Once we have the simple case out and we can test it, see how it behaves, what
its limits are, we can start building on more complex cases, but I don't really
believe on building the perfect solution in one go.


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

Re: Ideas and proposal for removing changelog and release fields from spec file

[Fabio Valentini]

On Tue, Feb 25, 2020 at 2:47 PM Remi Collet  wrote:
>
> Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :
>
> >   - You can easily opt-in by using the macros
>
> Please keep opt-in as a mandatory need for such a change.
>
>
> To be clear, I will be (perhaps the only) one to not use it.
>
>
> For now spec file are self-contained, which is nice.
>
> I don't like the idea of generated / external stuff related
> to "storage" or "build system"
>
>
> Sorry, to be again the old bad guy which don't like changes.
>
> Remi

FWIW, I agree. Maybe I'm getting old as well >:-D

I don't think it's a good idea to use any information from outside the
dist-git repository as a source of truth for anything.
The big benefit of only using the git repository as source of
information is that it is immutable, reproducible, and cannot be
changed after commits have been pushed.
The git repository data is also available for working on packages
*offline*, in contrast to having to ask koji for the number of builds
since X ...

Fabio

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Haskell on EPEL 8

[Stephen John Smoogen]

On Tue, 25 Feb 2020 at 08:53, Jos Vos  wrote:

> Hi,
>
> Is there a specific reason why the Haskell platform is not available
> anymore in EPEL 8 (it was in EPEL 7)?  Any ongoing work known to
> eventually support it again?
>
>
We do not automatically branch everything from one release to another. We
have found that trying doing so pisses off a lot of the
volunteer maintainers who are doing EPEL in their spare time and don't want
added work they didn't sign up for. Packages are put into a release when a
volunteer maintainer knows that the package is wanted, and they have time
to do so. If you need a set of packages, go to https://bugzilla.redhat.com
and check to see if there are outstanding bug tickets requesting a
maintainer to support it in EPEL-8. If there are add your info to that
ticket, if there are not please open a ticket.



> Thanks,
>
> --
> --Jos Vos 
> --X/OS Experts in Open Systems BV   |   Office: +31 20 6938364
> --Amsterdam, The Netherlands|   Mobile: +31 6 26216181
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
>


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Adopting fedora-jam-kde-theme and fedora-jam-backgrounds

[Ankur Sinha]

On Sat, Feb 22, 2020 07:03:16 -0800, Erich Eickmeyer wrote:
> 
> 
> I have had a few people looking at my reviews. After I made corrections and 
> posted that info, I have had zero responses on my bugs:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1801352
> https://bugzilla.redhat.com/show_bug.cgi?id=1803945
> https://bugzilla.redhat.com/show_bug.cgi?id=1804307

I just had a look. People are working on all three, and @salimma has
agreed to sponsor you there also. So it should all be done soon.

If there's anything else the community can help with, please let us
know.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Modularity branch name

[Remi Collet]

Hi,


After some test, is looks like the stream name of a module have to
match the branch name.

I think this constraint doesn't make sense.

We can want different content (.yaml file) for different
distributions (Fedora vs EPEL) or different Version

Reported as https://pagure.io/fedora-infrastructure/issue/8687
(but probably not the right place)


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

[EPEL-devel] Haskell on EPEL 8

[Jos Vos]

Hi,

Is there a specific reason why the Haskell platform is not available
anymore in EPEL 8 (it was in EPEL 7)?  Any ongoing work known to
eventually support it again?

Thanks,

-- 
--Jos Vos 
--X/OS Experts in Open Systems BV   |   Office: +31 20 6938364
--Amsterdam, The Netherlands|   Mobile: +31 6 26216181
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[Bug 1806997] perl-MooX-Struct-0.019 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-MooX-Struct-0.019-1.fc
   ||33
 Resolution|--- |RAWHIDE
Last Closed||2020-02-25 13:50:45



--- Comment #1 from Petr Pisar  ---
Fixes and new features. Safer for Rawhide only.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Ideas and proposal for removing changelog and release fields from spec file

[Remi Collet]

Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :

>   - You can easily opt-in by using the macros

Please keep opt-in as a mandatory need for such a change.


To be clear, I will be (perhaps the only) one to not use it.


For now spec file are self-contained, which is nice.

I don't like the idea of generated / external stuff related
to "storage" or "build system"


Sorry, to be again the old bad guy which don't like changes.



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

[Bug 1806997] perl-MooX-Struct-0.019 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value



-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1806997] New: perl-MooX-Struct-0.019 is available

[bugzilla]

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

Bug ID: 1806997
   Summary: perl-MooX-Struct-0.019 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-MooX-Struct
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.019
Current version/release in rawhide: 0.017-7.fc32
URL: http://search.cpan.org/dist/MooX-Struct/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/10995/

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1785827] perl-Module-CoreList-5.20191220 is available

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1793146] perl-Module-CoreList-5.20200120 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1794960] perl-perlfaq-5.20200125 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1793146] perl-Module-CoreList-5.20200120 is available

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1795119] Upgrade perl-Time-Local to 1.30

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1793459] perl-ExtUtils-CBuilder-0.280234 is available

[bugzilla]

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



--- Comment #12 from Fedora Update System  ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1791932] perl-autodie-2.32 is available

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1795119] Upgrade perl-Time-Local to 1.30

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1792861] perl-Exporter-5.74 is available

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1788685] perl-autodie-2.30 is available

[bugzilla]

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



--- Comment #11 from Fedora Update System  ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a

--- Comment #12 from Fedora Update System  ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1787958] perl-DB_File-1.853 is available

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1786801] perl-Encode-3.02 is available

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1794960] perl-perlfaq-5.20200125 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1785827] perl-Module-CoreList-5.20191220 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1793459] perl-ExtUtils-CBuilder-0.280234 is available

[bugzilla]

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



--- Comment #11 from Fedora Update System  ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1786801] perl-Encode-3.02 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1792861] perl-Exporter-5.74 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1787958] perl-DB_File-1.853 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1791932] perl-autodie-2.32 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: Looking for new maintainer: nagios, nagios-plugins, nrpe

[Stephen John Smoogen]

On Mon, 24 Feb 2020 at 18:31, Eduardo Kienetz  wrote:
>
> It would be my first time maintaining an EPEL package, but if nobody else 
> already experienced is willing, I could probably do it with minimal 
> supervision/hints to get started :)
> What has been the typical work? If they have git repos I can probably get a 
> good understanding from the commits.
>

Hi Eduardo.

I was going to add you to the group, but you are not a packager so I
could not. You can look at the package and its outstanding bugs in
bugzilla and look through the spec file to see if it is something you
can take on later when you become a packager.


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org