Re: js-jquery - Re: List of long term FTBFS packages to be retired in February (beta)

[Vít Ondruch]

According to [1], these are the packages which need to be preserved to
keep js-jquery around:


nodejs-grunt-legacy-util

nodejs-load-grunt-tasks

nodejs-raw-body


Vít


[1] https://churchyard.fedorapeople.org/orphans-2019-12-02.txt


Dne 03. 12. 19 v 2:24 Sérgio Basto napsal(a):
> I will take nodejs-dateformat .
> Do you have a list of what more packages we have to keep?
>
>
> On Mon, 2019-12-02 at 15:52 +0100, Raphael Groner wrote:
>> Thanks a lot.
>>
>> Am 02.12.19 um 15:20 schrieb Tom Hughes:
>> …
>>> As I explained the other day js-jquery was dependent on a
>>> nodejs module (a normal one, not modularised) which was
>>> failing to build and which I have now fixed.
>> …
>> ___
>> 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

[Bug 1758483] perl-Crypt-OpenSSL-X509 for EL8

[bugzilla]

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

Xavier Bachelot  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|wjhns...@hardakers.net  |xav...@bachelot.org
  Flags|needinfo?(wjhns174@hardaker |
   |s.net)  |



--- Comment #4 from Xavier Bachelot  ---
https://pagure.io/releng/fedora-scm-requests/issue/20204
https://pagure.io/releng/fedora-scm-requests/issue/20205

-- 
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: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Monday, December 2, 2019 12:39:52 PM MST Chris Murphy wrote:
> On Mon, Dec 2, 2019 at 9:48 AM Przemek Klosowski via devel
>  wrote:
> 
> >
> >
> > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
> >
> >
> >
> > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:
> >
> >
> >
> > Mabee systemd-homed is in
> > a position to solve this by having early enough authentication
> > capability by rescue.target time that any admin user can login?
> >
> >
> >
> > Actually, it may. Things are confusing here, because systemd-homed is
> > implemented together with changes to how user metadata querying is done:
> > instead of using dbus, a brokerless and much simpler varlink query is
> > used.
 That last part is what would be relevant to early-boot logins,
> > because less services need to be up to bring up the user session.
> >
> >
> >
> > There's one tricky feature of homed : remote login (ssh) is only possible
> > after an initial local login. It is OK for his intended use (a personal
> > laptop/tablet client), except for corner cases like a remotely accessed
> > personal desktop in the basement that might get rebooted e.g. for
> > updates, resulting in an accidental lockout.
> 
> It's not just an issue for systemd-homed, this problem applies to any
> user home encryption implementation when the user has not first
> authenticated/unlocked their user home. e.g. if you install with /home
> encrypted in Anaconda, in fact your boot stops at plymouth in the
> initramfs so sshd is thwarted from even starting in the first place;
> and even if GNOME Shell's login were to be enhanced to do this unlock,
> still requires unlock.

That is simply not the case. I don't know what you're referring to with "if 
you install with /home encrypted in Anaconda", or why GNOME Shell would have 
anything to ssh, however with Plasma, my desktop environment doesn't have to 
be loaded at all in order for me to ssh in.

> Basically you have to choose between user home security (or more
> specifically privacy) and remote logins. However, there are some ideas
> that could possibly work around this, to varying degrees of
> inelegance, which I'll gratuitously copy from a related Workstation WG
> issue [1].

You really don't. It's pretty much there by default, and there's not a lot 
that I have to change from a default Plasma install. Doing an Anaconda guided 
LVM full disk encryption setup is sufficient to protect data at rest.

> 1. Enhance openssh's PAM support

What do you believe needs to be "enhanced"?

> 2. Stub account to ssh into, whereby the user is prompted to
> authenticate+unlock the real account; and now ssh into the real
> account.

Why should somebody have to create TWO accounts in order to access their 
system?

> 3. Same as 2 but maybe it's possible to bind mount the real home dir
> over the stub home dir, eliminating the 2nd login? (Vaguely recall
> reading about this somewhere, maybe Ubuntu's use of ecryptfs based
> home, now since deprecated in favor of LUKS)

If we really wanted to, that's possible now, without systemd-homed.

> 4. If based on any fscrypt implementation, exclude ~/.ssh/ from encryption

That's a bad idea. That directory, by default, contains ssh private keys, as 
well as the list of authorized keys. A better workaround would be similar to 
what is already implemented for sssd, where a proxy command is used to get the 
authorized keys for an account.

-- 
John M. Harris, Jr.
Splentity

___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Monday, December 2, 2019 12:46:30 PM MST Chris Murphy wrote:
> It's almost 2020, and I shouldn't have to pick and choose between
> remote access and securing user data at rest by default.

You don't have to. Data at rest would mean that your system is powered off, or  
suspended to disk. You can have that now with full disk encryption, just as I 
do. Depending on your system, you can actually encrypt the entire disk such 
that you don't even have a partition table. I do this with my X200 Tablet, 
where GRUB is loaded from flash, which decrypts my disk, and then mounts ZFS 
mountpoints, swaps on a ZFS zdev.

-- 
John M. Harris, Jr.
Splentity

___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Monday, December 2, 2019 11:16:43 AM MST Zbigniew Jędrzejewski-Szmek wrote:
> How often do you ssh *into* your laptop?

Every time I'm on another system without access to my NFS server, or I need my 
GnuPG key when not using my laptop.

-- 
John M. Harris, Jr.
Splentity

___
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 1779031] New: perl-Email-Sender-1.300034 is available

[bugzilla]

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

Bug ID: 1779031
   Summary: perl-Email-Sender-1.300034 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Email-Sender
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, iarn...@gmail.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.300034
Current version/release in rawhide: 1.300031-9.fc31
URL: http://search.cpan.org/dist/Email-Sender/

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/6990/

-- 
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: [atomic-announce] Final EOL Fedora Atomic Host Two Week Release Announcement: 29.20191126.0

[Sinny Kumari]

On Tue, Dec 3, 2019 at 12:03 AM Mike Nguyen  wrote:

> With Fedora 29 reaching End Of Life, this will be the final Fedora Atomic
> Host release (based on the Fedora 29 stream).  Fedora Atomic Host will no
> longer receive any updates.  More details can be found at
> https://www.projectatomic.io/blog/2019/11/fedora-atomic-host-nearing-eol/
>
> Thank you for using Fedora Atomic Host and your contributions to the
> project.  We would love it if you please give Fedora CoreOS preview a try
> and help us get it towards stable.  Documentation and download links can be
> found at https://getfedora.org/coreos/.
>
> Thank you,
> Fedora Release Engineering
>
>
>
> The final Fedora Atomic Host update is available via an OSTree update:
>
> Version: 29.20191126.0
> Commit(x86_64):
> 563185fc932b93558a56dddb1f5688b941cc2d88dc8b400a3833766c68c2d2f1
> Commit(aarch64):
> de42987e180698a76934a75333ef438a2050b71704a33377bd85356e197efa06
> Commit(ppc64le):
> 4f30217814d71c3cef2a16ce8a9b834c1515466d54550ec65b7fc69625cd962a
>
>
> We are releasing images from multiple architectures but please note
> that x86_64 architecture is the only one that undergoes automated
> testing at this time.
>
> Existing systems can be upgraded in place via e.g. `atomic host upgrade`.
>
> Corresponding image media for new installations can be downloaded from:
>
> https://getfedora.org/en/atomic/download/
>
> Alternatively, image artifacts can be found at the following links:
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191126.0.aarch64.qcow2
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191126.0.aarch64.raw.xz
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20191126.0.iso
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191126.0.ppc64le.qcow2
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191126.0.ppc64le.raw.xz
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20191126.0.iso
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191126.0.x86_64.qcow2
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191126.0.x86_64.raw.xz
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20191126.0.x86_64.vagrant-libvirt.box
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20191126.0.x86_64.vagrant-virtualbox.box
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20191126.0.iso
>
> Respective signed CHECKSUM files can be found here:
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191126.0-aarch64-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20191126.0-aarch64-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191126.0-ppc64le-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20191126.0-ppc64le-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191126.0-x86_64-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191126.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20191126.0-x86_64-CHECKSUM
>
> For direct download, the "latest" targets are always available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest
> https://getfedora.org/atomic_raw_x86_64_latest
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest
>
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest
> https://getfedora.org/atomic_raw_aarch64_latest
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest
>
> ppc64le:
> https://getfedora.org/atomic_qcow2_ppc64le_latest
> https://getfedora.org/atomic_raw_ppc64le_latest
> https://getfedora.org/atomic_dvd_ostree_ppc64le_latest

Re: Orphaned camlp4 dependencies (was: Re: Orphaned packages looking for new maintainers)

[Yaakov Selkowitz]

On Mon, 2019-12-02 at 19:49 +, Richard W.M. Jones wrote:
> On Mon, Dec 02, 2019 at 07:15:27PM +0100, Miro Hrončok wrote:
> > ocaml-bin-protorphan   2 weeks 
> > ago
> > ocaml-bisect  orphan   2 weeks 
> > ago
> > ocaml-bitstring   orphan   2 weeks 
> > ago
> > ocaml-derivingorphan   2 weeks 
> > ago
> > ocaml-json-static orphan   2 weeks 
> > ago
> > ocaml-mikmatchorphan   2 weeks 
> > ago
> > ocaml-openin  orphan   2 weeks 
> > ago
> > ocaml-pa-monadorphan   2 weeks 
> > ago
> > ocaml-pgocaml orphan   2 weeks 
> > ago
> > ocaml-sexplib orphan   2 weeks 
> > ago
> > ocaml-type-conv   orphan   2 weeks 
> > ago
> > ocamldsortorphan   2 weeks 
> > ago
> 
> These were deliberately orphaned so are not really looking for new
> maintainers.  However if anyone does decide to take them on be sure to
> read this email carefully first:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G2JBIWB423ECYGBXZ3QCPR7NQ66XGXTU/

Note that a week and a half later there was a 4.08+1 release of camlp4.

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.

___
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 2019-12-03 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/12/03/report-389-ds-base-1.4.2.4-20191203gitd0f04dd.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

[Bug 1754124] perl-Module-CoreList-5.20190920 is available

[bugzilla]

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



--- Comment #22 from Fedora Update System  ---
perl-5.28-3120191129151235.a5d38390 has been pushed to the Fedora 31 Modular
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-MODULAR-2019-a622fe13c4

-- 
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 1770717] Upgrade perl-Module-Load-Conditional to 0.70

[bugzilla]

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



--- Comment #24 from Fedora Update System  ---
perl-5.28-3120191129151235.a5d38390 has been pushed to the Fedora 31 Modular
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-MODULAR-2019-a622fe13c4

-- 
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 1763515] perl-Module-CoreList-5.20191020 is available

[bugzilla]

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



--- Comment #22 from Fedora Update System  ---
perl-5.28-3120191129151235.a5d38390 has been pushed to the Fedora 31 Modular
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-MODULAR-2019-a622fe13c4

-- 
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 1768068] perl-perlfaq-5.20191102 is available

[bugzilla]

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



--- Comment #23 from Fedora Update System  ---
perl-5.28-3120191129151235.a5d38390 has been pushed to the Fedora 31 Modular
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-MODULAR-2019-a622fe13c4

-- 
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 1773830] perl-Term-Table-0.015 is available

[bugzilla]

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



--- Comment #17 from Fedora Update System  ---
perl-5.30-3120191129151030.a9ea5770 has been pushed to the Fedora 31 Modular
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-MODULAR-2019-3058bbd6a3

-- 
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 1773830] perl-Term-Table-0.015 is available

[bugzilla]

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



--- Comment #18 from Fedora Update System  ---
perl-5.28-3120191129151235.a5d38390 has been pushed to the Fedora 31 Modular
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-MODULAR-2019-a622fe13c4

-- 
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 1774785] perl-Module-CoreList-5.20191120 is available

[bugzilla]

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



--- Comment #17 from Fedora Update System  ---
perl-5.28-3120191129151235.a5d38390 has been pushed to the Fedora 31 Modular
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-MODULAR-2019-a622fe13c4

-- 
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 1774785] perl-Module-CoreList-5.20191120 is available

[bugzilla]

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



--- Comment #16 from Fedora Update System  ---
perl-5.30-3120191129151030.a9ea5770 has been pushed to the Fedora 31 Modular
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-MODULAR-2019-3058bbd6a3

-- 
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 1770716] Upgrade perl-Module-CoreList to 5.20191110

[bugzilla]

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



--- Comment #23 from Fedora Update System  ---
perl-5.28-3120191129151235.a5d38390 has been pushed to the Fedora 31 Modular
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-MODULAR-2019-a622fe13c4

-- 
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 1762085] perl-Term-Table-0.014 is available

[bugzilla]

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



--- Comment #22 from Fedora Update System  ---
perl-5.28-3120191129151235.a5d38390 has been pushed to the Fedora 31 Modular
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-MODULAR-2019-a622fe13c4

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

[Fedocal] Reminder meeting : Modularity Team (weekly)

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Team (weekly) on 2019-12-03 from 15:00:00 to 16:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Team.

More information available at: [Modularity Team 
Docs](https://docs.pagure.org/modularity/)

The agenda for the meeting is available as flagged tickets [in the Modularity 
repository](https://pagure.io/modularity/issues?status=Open=Meeting).



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

___
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 1778302] please build perl-Glib for EPEL8

[bugzilla]

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

Mukundan Ragavan  changed:

   What|Removed |Added

 Blocks||1744139
   Doc Type|--- |If docs needed, set a value




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1744139
[Bug 1744139] Request to build xfce for EPEL 8
-- 
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 1770716] Upgrade perl-Module-CoreList to 5.20191110

[bugzilla]

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



--- Comment #22 from Fedora Update System  ---
perl-5.28-3020191129151235.eb1b2d95 has been pushed to the Fedora 30 Modular
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-MODULAR-2019-b78565b9d2

-- 
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 1768068] perl-perlfaq-5.20191102 is available

[bugzilla]

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



--- Comment #22 from Fedora Update System  ---
perl-5.28-3020191129151235.eb1b2d95 has been pushed to the Fedora 30 Modular
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-MODULAR-2019-b78565b9d2

-- 
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 1774785] perl-Module-CoreList-5.20191120 is available

[bugzilla]

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



--- Comment #14 from Fedora Update System  ---
perl-5.30-3020191129151030.bba63816 has been pushed to the Fedora 30 Modular
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-MODULAR-2019-5698074897

-- 
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 1763515] perl-Module-CoreList-5.20191020 is available

[bugzilla]

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



--- Comment #21 from Fedora Update System  ---
perl-5.28-3020191129151235.eb1b2d95 has been pushed to the Fedora 30 Modular
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-MODULAR-2019-b78565b9d2

-- 
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 1773830] perl-Term-Table-0.015 is available

[bugzilla]

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



--- Comment #16 from Fedora Update System  ---
perl-5.28-3020191129151235.eb1b2d95 has been pushed to the Fedora 30 Modular
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-MODULAR-2019-b78565b9d2

-- 
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 1754124] perl-Module-CoreList-5.20190920 is available

[bugzilla]

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



--- Comment #21 from Fedora Update System  ---
perl-5.28-3020191129151235.eb1b2d95 has been pushed to the Fedora 30 Modular
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-MODULAR-2019-b78565b9d2

-- 
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 1774785] perl-Module-CoreList-5.20191120 is available

[bugzilla]

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



--- Comment #15 from Fedora Update System  ---
perl-5.28-3020191129151235.eb1b2d95 has been pushed to the Fedora 30 Modular
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-MODULAR-2019-b78565b9d2

-- 
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 1770717] Upgrade perl-Module-Load-Conditional to 0.70

[bugzilla]

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



--- Comment #23 from Fedora Update System  ---
perl-5.28-3020191129151235.eb1b2d95 has been pushed to the Fedora 30 Modular
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-MODULAR-2019-b78565b9d2

-- 
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 1762085] perl-Term-Table-0.014 is available

[bugzilla]

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



--- Comment #21 from Fedora Update System  ---
perl-5.28-3020191129151235.eb1b2d95 has been pushed to the Fedora 30 Modular
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-MODULAR-2019-b78565b9d2

-- 
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 1773830] perl-Term-Table-0.015 is available

[bugzilla]

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



--- Comment #15 from Fedora Update System  ---
perl-5.30-3020191129151030.bba63816 has been pushed to the Fedora 30 Modular
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-MODULAR-2019-5698074897

-- 
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: js-jquery - Re: List of long term FTBFS packages to be retired in February (beta)

[Sérgio Basto]

I will take nodejs-dateformat .
Do you have a list of what more packages we have to keep?


On Mon, 2019-12-02 at 15:52 +0100, Raphael Groner wrote:
> Thanks a lot.
> 
> Am 02.12.19 um 15:20 schrieb Tom Hughes:
> …
> > As I explained the other day js-jquery was dependent on a
> > nodejs module (a normal one, not modularised) which was
> > failing to build and which I have now fixed.
> …
> ___
> 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
-- 
Sérgio M. B.
___
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: Orphaned packages looking for new maintainers

[James Paul Turner]

On Mon, 2019-12-02 at 19:15 +0100, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know
> for sure
> that the package should be retired, please do so now with a proper
> reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> Note: If you received this mail directly you (co)maintain one of the
> affected
> packages or a package that depends on one. Please adopt the affected
> package or
> retire your depending package to avoid broken dependencies, otherwise
> your
> package will be retired when the affected package gets retired.
> 
> Request package ownership via releng issues:
> https://pagure.io/releng/issues
> 
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2019-12-02.txt
> grep it for your FAS username and follow the dependency chain.

Hi Miro.

I have requested scilab.

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

All the best,
James.

-- 

James Paul Turner
Department of Informatics
University of Sussex

Arpra: Arbitrary-Precision Range Analysis
https://github.com/arpra-project/arpra

___
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: "python3" vs "python%{python3_pkgversion}"

[Neal Gompa]

On Mon, Dec 2, 2019 at 7:04 PM Miro Hrončok  wrote:
>
> On 03. 12. 19 0:54, Kevin Fenzi wrote:
> > On Tue, Dec 03, 2019 at 12:38:01AM +0100, Miro Hrončok wrote:
> >> On 02. 12. 19 23:09, Ken Dreyer wrote:
> >>> On Mon, Dec 2, 2019 at 11:47 AM Neal Gompa  wrote:
> 
>  On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer  wrote:
> >
> > Hi folks,
> >
> > In EPEL 7 we have some packages with "python34" and "python36"
> > prefixes in their names. I guess this is a consequence of using the
> > %{python3_pkgversion} macro over time.
> >
> > Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
> > EPEL 7, I'm wondering about this.
> >
> > If I'm introducing a Python 3 subpackage in a new build today, should
> > I name this sub-package "python3-foo" or
> > "python%{python3_pkgversion}-foo" ?
> >
> 
>  The subpackage should be "python%{python3_pkgversion}-foo" and you
>  should also make sure you have "%{?python_provide:%python_provide
>  python%{python3_pkgversion}-foo}" in the subpackage declaration too.
> >>>
> >>> This is confusing to me, and it diverges from what Fedora does. Can we
> >>> just reduce this down to "python3-" now that RHEL 7 has python3, and
> >>> we'll probably never put another Python version into EPEL 7?
> >>
> >> We **can** but we **haven't yet**. IMHO doing it in random packages is 
> >> wrong.
> >>
> >> Currently, python36-foo is form EPEL (and if done right, provides 
> >> python3-foo).
> >> OTOH python3-bar is from RHEL (and if done right, provides python36-bar).
> >>
> >> They both provide both names, but from first glance, the origin of the
> >> package is obvious. I kinda like that.
> >>
> >> If we decide to redo this, it will be a lot of boring work for no clear 
> >> benefit.
> >> If we decide to only allow it for new packages, it would be a mess.
> >>
> >> That said, technically:
> >>
> >>   - it works either way
> >>   - there is no real EPEL packaging guideline forcing one way or the other
> >
> > I think we should encourage people to just use python3-foo now, but I
> > agree it would be a lot of work to try and convert everything to do
> > that.
> >
> > The orig reason was so we could move python stacks forward since we were
> > maintaining them in epel. Since python 3.6 is in rhel and rhel7 is past
> > the point where I would expect many changes, I think 3.6 is here to
> > stay, so we dont really need it anymore. It's just extra noise that
> > makes spec files less readable now.
>
> If we want to get rid of it, we might just:
>
> Fix the cases where srpm is called python3-foo and subpackage python36-foo.
> Switch the %{python3_pkgversion} to 3 (= remove the redefinition from EPEL).
>
> Rebuild everything. Profit.
>
> The problem of course, is bootstrapping.
>

We should probably consider rebuilding all the Python 3 packages in
EPEL7 no matter what so that the python3.6dist() Provides get
generated, though. The dependency generator was backported to EL7 and
is used with the Python 3 stack. It just isn't very useful yet because
not all the packages were rebuilt after python3 was introduced in RHEL
7. Though why the --majorver-provides switch was removed from the
attr, I don't know.

After that, we can backport the %python_enable_dependency_generator
macro to EPEL7...



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: "python3" vs "python%{python3_pkgversion}"

[Miro Hrončok]

On 03. 12. 19 0:54, Kevin Fenzi wrote:

On Tue, Dec 03, 2019 at 12:38:01AM +0100, Miro Hrončok wrote:

On 02. 12. 19 23:09, Ken Dreyer wrote:

On Mon, Dec 2, 2019 at 11:47 AM Neal Gompa  wrote:


On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer  wrote:


Hi folks,

In EPEL 7 we have some packages with "python34" and "python36"
prefixes in their names. I guess this is a consequence of using the
%{python3_pkgversion} macro over time.

Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
EPEL 7, I'm wondering about this.

If I'm introducing a Python 3 subpackage in a new build today, should
I name this sub-package "python3-foo" or
"python%{python3_pkgversion}-foo" ?



The subpackage should be "python%{python3_pkgversion}-foo" and you
should also make sure you have "%{?python_provide:%python_provide
python%{python3_pkgversion}-foo}" in the subpackage declaration too.


This is confusing to me, and it diverges from what Fedora does. Can we
just reduce this down to "python3-" now that RHEL 7 has python3, and
we'll probably never put another Python version into EPEL 7?


We **can** but we **haven't yet**. IMHO doing it in random packages is wrong.

Currently, python36-foo is form EPEL (and if done right, provides python3-foo).
OTOH python3-bar is from RHEL (and if done right, provides python36-bar).

They both provide both names, but from first glance, the origin of the
package is obvious. I kinda like that.

If we decide to redo this, it will be a lot of boring work for no clear benefit.
If we decide to only allow it for new packages, it would be a mess.

That said, technically:

  - it works either way
  - there is no real EPEL packaging guideline forcing one way or the other


I think we should encourage people to just use python3-foo now, but I
agree it would be a lot of work to try and convert everything to do
that.

The orig reason was so we could move python stacks forward since we were
maintaining them in epel. Since python 3.6 is in rhel and rhel7 is past
the point where I would expect many changes, I think 3.6 is here to
stay, so we dont really need it anymore. It's just extra noise that
makes spec files less readable now.


If we want to get rid of it, we might just:

Fix the cases where srpm is called python3-foo and subpackage python36-foo.
Switch the %{python3_pkgversion} to 3 (= remove the redefinition from EPEL).

Rebuild everything. Profit.

The problem of course, is bootstrapping.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: "python3" vs "python%{python3_pkgversion}"

[Kevin Fenzi]

On Tue, Dec 03, 2019 at 12:38:01AM +0100, Miro Hrončok wrote:
> On 02. 12. 19 23:09, Ken Dreyer wrote:
> > On Mon, Dec 2, 2019 at 11:47 AM Neal Gompa  wrote:
> > > 
> > > On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer  wrote:
> > > > 
> > > > Hi folks,
> > > > 
> > > > In EPEL 7 we have some packages with "python34" and "python36"
> > > > prefixes in their names. I guess this is a consequence of using the
> > > > %{python3_pkgversion} macro over time.
> > > > 
> > > > Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
> > > > EPEL 7, I'm wondering about this.
> > > > 
> > > > If I'm introducing a Python 3 subpackage in a new build today, should
> > > > I name this sub-package "python3-foo" or
> > > > "python%{python3_pkgversion}-foo" ?
> > > > 
> > > 
> > > The subpackage should be "python%{python3_pkgversion}-foo" and you
> > > should also make sure you have "%{?python_provide:%python_provide
> > > python%{python3_pkgversion}-foo}" in the subpackage declaration too.
> > 
> > This is confusing to me, and it diverges from what Fedora does. Can we
> > just reduce this down to "python3-" now that RHEL 7 has python3, and
> > we'll probably never put another Python version into EPEL 7?
> 
> We **can** but we **haven't yet**. IMHO doing it in random packages is wrong.
> 
> Currently, python36-foo is form EPEL (and if done right, provides 
> python3-foo).
> OTOH python3-bar is from RHEL (and if done right, provides python36-bar).
> 
> They both provide both names, but from first glance, the origin of the
> package is obvious. I kinda like that.
> 
> If we decide to redo this, it will be a lot of boring work for no clear 
> benefit.
> If we decide to only allow it for new packages, it would be a mess.
> 
> That said, technically:
> 
>  - it works either way
>  - there is no real EPEL packaging guideline forcing one way or the other

I think we should encourage people to just use python3-foo now, but I
agree it would be a lot of work to try and convert everything to do
that. 

The orig reason was so we could move python stacks forward since we were
maintaining them in epel. Since python 3.6 is in rhel and rhel7 is past
the point where I would expect many changes, I think 3.6 is here to
stay, so we dont really need it anymore. It's just extra noise that
makes spec files less readable now. 

kevin


signature.asc
Description: PGP signature
___
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: Non-responsive maintainer: Wes Hardaker (hardaker)

[Wes Hardaker]

Xavier Bachelot  writes:

> As offered in the bug, I can help with maintaining
> perl-Crypt-OpenSSL-X509. My FAS username is xavierb.
> I'll reassign the EL8 branch bug to me and take care of it. I'll also
> take care of updating to the recently released 1.813 in master.

1.813 is complete on master.  I just added you as an admin for the
package and am glad you're willing to help!
-- 
Wes Hardaker 
My Pictures:   http://capturedonearth.com/
My Thoughts:   http://blog.capturedonearth.com/
___
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: "python3" vs "python%{python3_pkgversion}"

[Miro Hrončok]

On 02. 12. 19 23:09, Ken Dreyer wrote:

On Mon, Dec 2, 2019 at 11:47 AM Neal Gompa  wrote:


On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer  wrote:


Hi folks,

In EPEL 7 we have some packages with "python34" and "python36"
prefixes in their names. I guess this is a consequence of using the
%{python3_pkgversion} macro over time.

Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
EPEL 7, I'm wondering about this.

If I'm introducing a Python 3 subpackage in a new build today, should
I name this sub-package "python3-foo" or
"python%{python3_pkgversion}-foo" ?



The subpackage should be "python%{python3_pkgversion}-foo" and you
should also make sure you have "%{?python_provide:%python_provide
python%{python3_pkgversion}-foo}" in the subpackage declaration too.


This is confusing to me, and it diverges from what Fedora does. Can we
just reduce this down to "python3-" now that RHEL 7 has python3, and
we'll probably never put another Python version into EPEL 7?


We **can** but we **haven't yet**. IMHO doing it in random packages is wrong.

Currently, python36-foo is form EPEL (and if done right, provides python3-foo).
OTOH python3-bar is from RHEL (and if done right, provides python36-bar).

They both provide both names, but from first glance, the origin of the package 
is obvious. I kinda like that.


If we decide to redo this, it will be a lot of boring work for no clear benefit.
If we decide to only allow it for new packages, it would be a mess.

That said, technically:

 - it works either way
 - there is no real EPEL packaging guideline forcing one way or the other

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

[Chris Murphy]

On Mon, Dec 2, 2019 at 12:39 PM Chris Murphy  wrote:

> 4. If based on any fscrypt implementation, exclude ~/.ssh/ from encryption

Actually this is essentially the same problem. Yes, I've ssh'd into
the real home, but everything is still encrypted, so I'd have to
unlock my home dir manually to gain access to my stuff. I mean, this
is the point, it's encrypted. And in any case there would be an opt
out for encryption.

-- 
Chris Murphy
___
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: dist-git bugzilla sync script being fixed

[Miro Hrončok]

On 03. 12. 19 0:26, Elliott Sales de Andrade wrote:

On Mon, 2 Dec 2019 at 08:22, Pierre-Yves Chibon  wrote:


Good Morning Everyone™,

we have recently spent some time refactoring, improving and fixing the script
that syncs the default assignee and CC list from dist-git to Bugzilla.

Since the script was broken for some time, we felt that it needs some validation
before we run it live (which will still require some work).
We have uploaded the results at:
https://pingou.fedorapeople.org/distgit_bugzilla_sync.log
(Note that this only shows what would be updated.)

We'd appreciate it if you could take some time and check the changes affecting
you and report any issues you might find.
An easy way to do this is downloading the file and grepping for your FAS
username.


[EDITCOMP] Fedora/python-Fiona  initialowner changed  to FAS name(s) `orphan`
[EDITCOMP] Fedora/python-Fiona  initialcclist changed from
`['@python-sig', 'qulogic']` to FAS name(s) `['orphan']`

Need to double-check this, because python-Fiona is retired, and I'm
not an owner of, or CC'd on, it. But I *am* an owner of python-fiona,
which is not orphaned.


Should I add you to python-Fiona so you are cced if people do file bugs for it 
by mistake?


--
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: dist-git bugzilla sync script being fixed

[Elliott Sales de Andrade]

On Mon, 2 Dec 2019 at 08:22, Pierre-Yves Chibon  wrote:
>
> Good Morning Everyone™,
>
> we have recently spent some time refactoring, improving and fixing the script
> that syncs the default assignee and CC list from dist-git to Bugzilla.
>
> Since the script was broken for some time, we felt that it needs some 
> validation
> before we run it live (which will still require some work).
> We have uploaded the results at:
> https://pingou.fedorapeople.org/distgit_bugzilla_sync.log
> (Note that this only shows what would be updated.)
>
> We'd appreciate it if you could take some time and check the changes affecting
> you and report any issues you might find.
> An easy way to do this is downloading the file and grepping for your FAS
> username.

[EDITCOMP] Fedora/python-Fiona  initialowner changed  to FAS name(s) `orphan`
[EDITCOMP] Fedora/python-Fiona  initialcclist changed from
`['@python-sig', 'qulogic']` to FAS name(s) `['orphan']`

Need to double-check this, because python-Fiona is retired, and I'm
not an owner of, or CC'd on, it. But I *am* an owner of python-fiona,
which is not orphaned.

-- 
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: RFC: Branch requests from non-maintainers

[Fabio Valentini]

On Mon, Dec 2, 2019, 22:44 Kevin Kofler  wrote:

> Igor Gnatenko wrote:
> > * Should any other packager (not that maintainer) be able to request
> > new branches on that repo?
> > * Should provenpackager be able to do the same request?
>
> Since I do not give a darn about what happens to my packages on EPEL, I am
> fine with anybody requesting EPEL branches for them as long as they do the
> work and don't expect me to do anything to those branches (which is not
> going to happen).
>

I think this might be a good time point out that it's actually possible to
override the default assignee for a component for EPEL bugs (also for
fedora) in bugzilla by adding this override in the
releng/fedora-scm-requests repo for the respective package, like here:

https://pagure.io/releng/fedora-scm-requests/blob/master/f/rpms/jackson-databind

(Note that lef was actually deemed non-responsive some months back, so this
is probably not a good example of a package where this split responsibility
"worked".)

Fabio


> 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
>
___
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: "python3" vs "python%{python3_pkgversion}"

[Ken Dreyer]

On Mon, Dec 2, 2019 at 11:47 AM Neal Gompa  wrote:
>
> On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer  wrote:
> >
> > Hi folks,
> >
> > In EPEL 7 we have some packages with "python34" and "python36"
> > prefixes in their names. I guess this is a consequence of using the
> > %{python3_pkgversion} macro over time.
> >
> > Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
> > EPEL 7, I'm wondering about this.
> >
> > If I'm introducing a Python 3 subpackage in a new build today, should
> > I name this sub-package "python3-foo" or
> > "python%{python3_pkgversion}-foo" ?
> >
>
> The subpackage should be "python%{python3_pkgversion}-foo" and you
> should also make sure you have "%{?python_provide:%python_provide
> python%{python3_pkgversion}-foo}" in the subpackage declaration too.

This is confusing to me, and it diverges from what Fedora does. Can we
just reduce this down to "python3-" now that RHEL 7 has python3, and
we'll probably never put another Python version into EPEL 7?

- Ken
___
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: FESCo (and others) election voting now open

[Ben Cotton]

This is your reminder that voting for FESCo (and other elected bodies) is
open through 23:59 UTC on Thursday, 5 December. See below for more
information.

On Thu, Nov 21, 2019 at 5:41 AM Ben Cotton  wrote:

> If you missed the Community Blog post[1], voting is now open for the
> Fedora 31 election cycle. In this cycle, the community is electing:
>
> * 1 member to the Fedora Council
> * 5 member to the Fedora Engineering Steering Committee (FESCo)
> * 1 member to the Fedora Mindshare Committee
>
> Voting is open through 23:59 UTC on Thursday, 5 December. To vote,
> visit the Elections app[2]. If you have any questions or difficulties
> with voting, please file a ticket[3].
>
> [1]
> https://communityblog.fedoraproject.org/fedora-31-elections-voting-now-open/
> [2] https://elections.fedoraproject.org/
> [3] https://pagure.io/fedora-project-schedule/new_issue
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
>


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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: RFC: Branch requests from non-maintainers

[Kevin Kofler]

Igor Gnatenko wrote:
> * Should any other packager (not that maintainer) be able to request
> new branches on that repo?
> * Should provenpackager be able to do the same request?

Since I do not give a darn about what happens to my packages on EPEL, I am 
fine with anybody requesting EPEL branches for them as long as they do the 
work and don't expect me to do anything to those branches (which is not 
going to happen).

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

Re: RFC: Branch requests from non-maintainers

[Matthias Runge]

On 02/12/2019 14:37, Daniel P. Berrangé wrote:

> IIUC, effectively "new branches" means "EPEL branches" since normal
> Fedora branches are all created automatically.
> 
> So to rephrase this
> 
>   * Should someone who is not the maintainer be able to declare
> that the maintainer must accept EPEL branches & the extra
> work that involves thereafter.
> 
> AFAIK, there's no requirement that Fedora package maintainers have
> to provide EPEL branches, its upto each maintainer if they want that
> work.
> 
...
> 
> So if the maintainer doesn't want to maintain the EPEL branches, the
> only long term viable option is to find willing co-maintainers to join,
> who can then request the branch & do builds, triage bugs, etc. 
> 
> IOW, I struggle to see a reason to allow someone who is a not a
> (co-)maintainer to request new branches in general. I'm not convinced
> that provenpackagers should be able to do this either, unless they
> want to volunteer to be the explicitly co-maintainer too, in which
> case the question doesn't arise.
> 

Yes! Several times. I've recently had this with some of "my" packages,
where someone could create branches and even kicked in builds for EPEL8.

Half of them are broken, and for a user, it just looks bad; users also
have the expectation that I'd fix those issues. I am currently thankful
for every bit I don't have to care about. I am assuming the best intent,
but if there's a chance for it, I'd rather forbid branch requests from
non-maintainers.

Matthias
___
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: Packaging guidelines

[Troy Dawson]

I believe the answer is "yes" ... to both.
As far as I know, there aren't any differences.  Where there are
differences, we're trying to get rid of the differences.
Example is that the automatic python dependencies weren't turned on in
epel8.  That should be fixed in a few days, so you should be able to
use your fedora python specs in epel8.

But, it would probably be good to update that page and say that there
aren't any differences.

On Mon, Dec 2, 2019 at 9:40 AM Mattia Verga  wrote:
>
> There used to be some differences between Fedora and EPEL packaging 
> guidelines, which were explained in the docs [1].
> I don't find any mention in that doc to EPEL8, does that mean there aren't 
> any differences or that the page isn't updated for EPEL8?
>
> Mattia
>
> [1] https://fedoraproject.org/wiki/EPEL:Packaging
> ___
> 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: RFC: Modularity Simplified

[Kevin Kofler]

Petr Pisar wrote:

> On 2019-12-02, John M. Harris Jr  wrote:
>> On Monday, December 2, 2019 12:17:20 AM MST Igor Gnatenko wrote:
>>> Sure, we just have to accept this until perl is made
>>> parallel-installable. Which may or may not happen, but if I have
>>> choice between "only one version of perl and no bugzilla" or "two
>>> conflicting versions of perl and bugzilla using non-default version
>>> of perl", I will choose latter. Unfortunately reality is not perfect.
>>
>> Doesn't that defeat the purpose of using a distro? At that point, you
>> might as well go grab some container nonsense, instead of using a real
>> system, if you care more for just "make it run", rather than "make it
>> run properly on a stable, supported Perl".
>>
> You assume that a non-default Perl is not stable and supported. While
> it's true that non-default streams have probably fewer users and thus
> are less tested, that does not mean it is an intention.

A non-default Perl packaged in a way that conflicts with the default one is 
by definition not a "stable, supported Perl", because it is incompatible 
with many packages in the distribution.

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

Re: Orphaned camlp4 dependencies (was: Re: Orphaned packages looking for new maintainers)

[Leigh Scott]

I have taken sassc but will welcome anyone else willing to help co-maintain 
this train wreck. 
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Kevin Fenzi]

On Mon, Dec 02, 2019 at 06:16:43PM +, Zbigniew Jędrzejewski-Szmek wrote:
...snip...
> Nevertheless, I'm pretty sure that a workaround for this will be made
> anyway. I think the latest version of the patchset allows exporting
> the authorized_keys content in the non-encrypted metadata for the user.

I wonder if clevis/tang could help here?
( https://github.com/latchset/clevis )

It could allow decryption in home networks, but not when traveling. 

Of course you would have to setup the server, etc. 

kevin


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

Orphaned camlp4 dependencies (was: Re: Orphaned packages looking for new maintainers)

[Richard W.M. Jones]

On Mon, Dec 02, 2019 at 07:15:27PM +0100, Miro Hrončok wrote:
> ocaml-bin-protorphan   2 weeks ago
> ocaml-bisect  orphan   2 weeks ago
> ocaml-bitstring   orphan   2 weeks ago
> ocaml-derivingorphan   2 weeks ago
> ocaml-json-static orphan   2 weeks ago
> ocaml-mikmatchorphan   2 weeks ago
> ocaml-openin  orphan   2 weeks ago
> ocaml-pa-monadorphan   2 weeks ago
> ocaml-pgocaml orphan   2 weeks ago
> ocaml-sexplib orphan   2 weeks ago
> ocaml-type-conv   orphan   2 weeks ago
> ocamldsortorphan   2 weeks ago

These were deliberately orphaned so are not really looking for new
maintainers.  However if anyone does decide to take them on be sure to
read this email carefully first:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G2JBIWB423ECYGBXZ3QCPR7NQ66XGXTU/

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Chris Murphy]

On Mon, Dec 2, 2019 at 10:45 AM John M. Harris Jr  wrote:
>
> On Monday, December 2, 2019 9:48:05 AM MST Przemek Klosowski via devel wrote:
> > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:
> > >> Mabee systemd-homed is in
> > >> a position to solve this by having early enough authentication
> > >> capability by rescue.target time that any admin user can login?
> > >
> > > Actually, it may. Things are confusing here, because systemd-homed is
> > > implemented together with changes to how user metadata querying is done:
> > > instead of using dbus, a brokerless and much simpler varlink query is
> > > used.
> > > That last part is what would be relevant to early-boot logins, because
> > > less services need to be up to bring up the user session.
> >
> > There's one tricky feature of homed : remote login (ssh) is only
> > possible after an initial local login. It is OK for his intended use (a
> > personal laptop/tablet client), except for corner cases like a remotely
> > accessed personal desktop in the basement that might get rebooted e.g.
> > for updates, resulting in an accidental lockout.
>
> Basically, systemd-homed is useless for any power user, but might be useful
> for people just getting into GNU/Linux, who don't use ssh yet or don't have
> more than one system.

I disagree with all of this, including the predisposition that this
limitation can't be worked around somehow. I ssh into various laptops
around the home office on a daily basis, I'm not going to give that
up. Based on the systemd-homed presentation, slides, and the early
code review happening, it addresses a number of concerns the
Workstation WG has in making forward progress to secure user data by
default.

It's almost 2020, and I shouldn't have to pick and choose between
remote access and securing user data at rest by default. We surely can
have our cake and eat it too.

-- 
Chris Murphy
___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Chris Murphy]

On Mon, Dec 2, 2019 at 9:48 AM Przemek Klosowski via devel
 wrote:
>
> On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
>
> On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:
>
> Mabee systemd-homed is in
> a position to solve this by having early enough authentication
> capability by rescue.target time that any admin user can login?
>
> Actually, it may. Things are confusing here, because systemd-homed is
> implemented together with changes to how user metadata querying is done:
> instead of using dbus, a brokerless and much simpler varlink query is used.
> That last part is what would be relevant to early-boot logins, because
> less services need to be up to bring up the user session.
>
> There's one tricky feature of homed : remote login (ssh) is only possible 
> after an initial local login. It is OK for his intended use (a personal 
> laptop/tablet client), except for corner cases like a remotely accessed 
> personal desktop in the basement that might get rebooted e.g. for updates, 
> resulting in an accidental lockout.

It's not just an issue for systemd-homed, this problem applies to any
user home encryption implementation when the user has not first
authenticated/unlocked their user home. e.g. if you install with /home
encrypted in Anaconda, in fact your boot stops at plymouth in the
initramfs so sshd is thwarted from even starting in the first place;
and even if GNOME Shell's login were to be enhanced to do this unlock,
still requires unlock.

Basically you have to choose between user home security (or more
specifically privacy) and remote logins. However, there are some ideas
that could possibly work around this, to varying degrees of
inelegance, which I'll gratuitously copy from a related Workstation WG
issue [1].

1. Enhance openssh's PAM support
2. Stub account to ssh into, whereby the user is prompted to
authenticate+unlock the real account; and now ssh into the real
account.
3. Same as 2 but maybe it's possible to bind mount the real home dir
over the stub home dir, eliminating the 2nd login? (Vaguely recall
reading about this somewhere, maybe Ubuntu's use of ecryptfs based
home, now since deprecated in favor of LUKS)
4. If based on any fscrypt implementation, exclude ~/.ssh/ from encryption


[1]
https://pagure.io/fedora-workstation/issue/82#comment-614193

-- 
Chris Murphy
___
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-responsive maintainer: Wes Hardaker (hardaker)

[Xavier Bachelot]

On 02/12/2019 19:15, Wes Hardaker wrote:

Xavier Bachelot  writes:


I've tried to get in touch with Wes Hardaker about
perl-Crypt-OpenSSL-X509 for 2 months. The bug was left untouched, even
after setting need-info flag. I've also tried to reach to him by
direct mail.


Hi, and sorry both.

I've been swamped lately and haven't had time to update the package.

I'll put it higher on my todo list, but if anyone would like to take
over the package I'd be more than happy to hand over the keys to someone
with more time.



Hi Wes,

Thanks for the answer.

As offered in the bug, I can help with maintaining 
perl-Crypt-OpenSSL-X509. My FAS username is xavierb.
I'll reassign the EL8 branch bug to me and take care of it. I'll also 
take care of updating to the recently released 1.813 in master.


Regards,
Xavier
___
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

Orphaned packages looking for new maintainers

[Miro Hrončok]

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

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

Request package ownership via releng issues:
https://pagure.io/releng/issues

Full report available at:
https://churchyard.fedorapeople.org/orphans-2019-12-02.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

ExchangeIRorphan   2 weeks ago
FUR   orphan   3 weeks ago
airsnort  orphan   3 weeks ago
apache-logging-parent mizdebsk, orphan 2 weeks ago
apache-mime4j orphan   5 weeks ago
apt-cacher-ng orphan   2 weeks ago
archaius  orphan   2 weeks ago
archmage  lbazan, orphan   1 weeks ago
audit-viewer  mitr, orphan 1 weeks ago
avalon-logkit jerboaa, mizdebsk, orphan1 weeks ago
base64coder   jcapik, mizdebsk, orphan 3 weeks ago
batik jvanek, mizdebsk, orphan 3 weeks ago
buildnumber-maven-plugin  orphan   1 weeks ago
bval  orphan   2 weeks ago
camotics  orphan   2 weeks ago
cduce orphan   2 weeks ago
clapham   orphan   2 weeks ago
classmate lef, orphan  4 weeks ago
cli-parserlef, orphan  4 weeks ago
cpptasks  orphan   0 weeks ago
csstidy   orphan   2 weeks ago
delve go-sig, orphan   2 weeks ago
dzen2 bstinson, dcantrel, fale,0 weeks ago
  lupinix, orphan
eclipse-anyedit   eclipse-sig, orphan, swagiaal2 weeks ago
eclipse-avr   orphan   2 weeks ago
eclipse-cdt   akurtakov, eclipse-sig,  5 weeks ago
  jjohnstn, kdaniel, orphan,
  rgrunber
eclipse-checkstyleakurtakov, eclipse-sig, orphan   2 weeks ago
eclipse-color-theme   eclipse-sig, orphan  2 weeks ago
eclipse-dltk  akurtakov, eclipse-sig,  2 weeks ago
  kdaniel, orphan, rgrunber
eclipse-egit  akurtakov, arobinso, eclipse-2 weeks ago
  sig, jerboaa, jjohnstn,
  kdaniel, nguzman, orphan,
  rgrunber
eclipse-emf   akurtakov, eclipse-sig,  2 weeks ago
  jjohnstn, kdaniel, orphan,
  rgrunber
eclipse-epic  eclipse-sig, orphan  2 weeks ago
eclipse-gef   akurtakov, eclipse-sig,  2 weeks ago
  kdaniel, orphan, rgrunber
eclipse-launchbar eclipse-sig, orphan, sopotc  4 weeks ago
eclipse-license   eclipse-sig, orphan  2 weeks ago
eclipse-m2e-antlr eclipse-sig, mizdebsk, orphan2 weeks ago
eclipse-m2e-core  eclipse-sig, galileo,2 weeks ago
  mizdebsk, orphan
eclipse-m2e-cxf   eclipse-sig, mizdebsk, orphan2 weeks ago
eclipse-m2e-maven-dependency- mizdebsk, orphan 2 weeks ago
plugin
eclipse-m2e-modello   eclipse-sig, mizdebsk, orphan2 weeks ago
eclipse-m2e-plexuseclipse-sig, mizdebsk, orphan2 weeks ago
eclipse-m2e-sisu  eclipse-sig, mizdebsk, orphan2 weeks ago
eclipse-m2e-takarimizdebsk, orphan 2 weeks ago
eclipse-m2e-workspace   

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

[Martin Kolman]

On Mon, 2019-12-02 at 18:16 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Dec 02, 2019 at 10:44:46AM -0700, John M. Harris Jr wrote:
> > On Monday, December 2, 2019 9:48:05 AM MST Przemek Klosowski via devel 
> > wrote:
> > > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:
> > > > > Mabee systemd-homed is in
> > > > > a position to solve this by having early enough authentication
> > > > > capability by rescue.target time that any admin user can login?
> > > > 
> > > > Actually, it may. Things are confusing here, because systemd-homed is
> > > > implemented together with changes to how user metadata querying is done:
> > > > instead of using dbus, a brokerless and much simpler varlink query is
> > > > used.
> > > > That last part is what would be relevant to early-boot logins, because
> > > > less services need to be up to bring up the user session.
> > > 
> > > There's one tricky feature of homed : remote login (ssh) is only
> > > possible after an initial local login. It is OK for his intended use (a
> > > personal laptop/tablet client), except for corner cases like a remotely
> > > accessed personal desktop in the basement that might get rebooted e.g.
> > > for updates, resulting in an accidental lockout.
> > 
> > Basically, systemd-homed is useless for any power user, but might be useful 
> > for people just getting into GNU/Linux, who don't use ssh yet or don't have 
> > more than one system.
> 
> How often do you ssh *into* your laptop?
Actually all the time - my (personal home) laptop is where my hobby projects
live, where various SSH private keys are, etc. So I SSH there to connect to 
another
machine using the SSH keys, to work an my hobby projects from a workstation 
computer
at home, etc.

And this is just "human" SSH sessions, various automated rsync/scp connections 
might
happen as well.

>  I occasionally do, but more
> because I can than because I really need to. systemd-homed is most
> suited for the case of a portable personal device, and this is exactly
> the type of device one is relatively unlikely to access from the
> network. So I don't think this limitation is so terrible.
> 
> Nevertheless, I'm pretty sure that a workaround for this will be made
> anyway. I think the latest version of the patchset allows exporting
> the authorized_keys content in the non-encrypted metadata for the user.
> 
> Zbyszek
> ___
> 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: "python3" vs "python%{python3_pkgversion}"

[Neal Gompa]

On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer  wrote:
>
> Hi folks,
>
> In EPEL 7 we have some packages with "python34" and "python36"
> prefixes in their names. I guess this is a consequence of using the
> %{python3_pkgversion} macro over time.
>
> Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
> EPEL 7, I'm wondering about this.
>
> If I'm introducing a Python 3 subpackage in a new build today, should
> I name this sub-package "python3-foo" or
> "python%{python3_pkgversion}-foo" ?
>

The subpackage should be "python%{python3_pkgversion}-foo" and you
should also make sure you have "%{?python_provide:%python_provide
python%{python3_pkgversion}-foo}" in the subpackage declaration too.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

[Nicolas Mailhot via devel]

Le lundi 02 décembre 2019 à 18:16 +, Zbigniew Jędrzejewski-Szmek a
écrit :
> 
> How often do you ssh *into* your laptop?

I use the same tech desktop and home server side. If it does not work
on my home server, I don’t want to see it on my desktops. I have other
things to do in life than coping with Linux systems fragmentation.

Trying to invent desktop-only things, when the Linux desktop market
share is marginal, and a large part of this marginal userbase is people
also working on Linux servers, is not likely to succeed.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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] "python3" vs "python%{python3_pkgversion}"

[Ken Dreyer]

Hi folks,

In EPEL 7 we have some packages with "python34" and "python36"
prefixes in their names. I guess this is a consequence of using the
%{python3_pkgversion} macro over time.

Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
EPEL 7, I'm wondering about this.

If I'm introducing a Python 3 subpackage in a new build today, should
I name this sub-package "python3-foo" or
"python%{python3_pkgversion}-foo" ?

- Ken
___
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: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 02, 2019 at 10:44:46AM -0700, John M. Harris Jr wrote:
> On Monday, December 2, 2019 9:48:05 AM MST Przemek Klosowski via devel wrote:
> > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:
> > >> Mabee systemd-homed is in
> > >> a position to solve this by having early enough authentication
> > >> capability by rescue.target time that any admin user can login?
> > > 
> > > Actually, it may. Things are confusing here, because systemd-homed is
> > > implemented together with changes to how user metadata querying is done:
> > > instead of using dbus, a brokerless and much simpler varlink query is
> > > used.
> > > That last part is what would be relevant to early-boot logins, because
> > > less services need to be up to bring up the user session.
> > 
> > There's one tricky feature of homed : remote login (ssh) is only
> > possible after an initial local login. It is OK for his intended use (a
> > personal laptop/tablet client), except for corner cases like a remotely
> > accessed personal desktop in the basement that might get rebooted e.g.
> > for updates, resulting in an accidental lockout.
> 
> Basically, systemd-homed is useless for any power user, but might be useful 
> for people just getting into GNU/Linux, who don't use ssh yet or don't have 
> more than one system.

How often do you ssh *into* your laptop? I occasionally do, but more
because I can than because I really need to. systemd-homed is most
suited for the case of a portable personal device, and this is exactly
the type of device one is relatively unlikely to access from the
network. So I don't think this limitation is so terrible.

Nevertheless, I'm pretty sure that a workaround for this will be made
anyway. I think the latest version of the patchset allows exporting
the authorized_keys content in the non-encrypted metadata for the user.

Zbyszek
___
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 1773105] perl-HTTP-Cookies-6.08 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-HTTP-Cookies-6.07 is   |perl-HTTP-Cookies-6.08 is
   |available   |available



--- Comment #2 from Upstream Release Monitoring 
 ---
Latest upstream release: 6.08
Current version/release in rawhide: 6.07-1.fc32
URL: http://search.cpan.org/dist/HTTP-Cookies/

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/2974/

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

Orphaned packages looking for new maintainers

[Miro Hrončok]

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

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

Request package ownership via releng issues:
https://pagure.io/releng/issues

Full report available at:
https://churchyard.fedorapeople.org/orphans-2019-12-02.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

ExchangeIRorphan   2 weeks ago
FUR   orphan   3 weeks ago
airsnort  orphan   3 weeks ago
apache-logging-parent mizdebsk, orphan 2 weeks ago
apache-mime4j orphan   5 weeks ago
apt-cacher-ng orphan   2 weeks ago
archaius  orphan   2 weeks ago
archmage  lbazan, orphan   1 weeks ago
audit-viewer  mitr, orphan 1 weeks ago
avalon-logkit jerboaa, mizdebsk, orphan1 weeks ago
base64coder   jcapik, mizdebsk, orphan 3 weeks ago
batik jvanek, mizdebsk, orphan 3 weeks ago
buildnumber-maven-plugin  orphan   1 weeks ago
bval  orphan   2 weeks ago
camotics  orphan   2 weeks ago
cduce orphan   2 weeks ago
clapham   orphan   2 weeks ago
classmate lef, orphan  4 weeks ago
cli-parserlef, orphan  4 weeks ago
cpptasks  orphan   0 weeks ago
csstidy   orphan   2 weeks ago
delve go-sig, orphan   2 weeks ago
dzen2 bstinson, dcantrel, fale,0 weeks ago
  lupinix, orphan
eclipse-anyedit   eclipse-sig, orphan, swagiaal2 weeks ago
eclipse-avr   orphan   2 weeks ago
eclipse-cdt   akurtakov, eclipse-sig,  5 weeks ago
  jjohnstn, kdaniel, orphan,
  rgrunber
eclipse-checkstyleakurtakov, eclipse-sig, orphan   2 weeks ago
eclipse-color-theme   eclipse-sig, orphan  2 weeks ago
eclipse-dltk  akurtakov, eclipse-sig,  2 weeks ago
  kdaniel, orphan, rgrunber
eclipse-egit  akurtakov, arobinso, eclipse-2 weeks ago
  sig, jerboaa, jjohnstn,
  kdaniel, nguzman, orphan,
  rgrunber
eclipse-emf   akurtakov, eclipse-sig,  2 weeks ago
  jjohnstn, kdaniel, orphan,
  rgrunber
eclipse-epic  eclipse-sig, orphan  2 weeks ago
eclipse-gef   akurtakov, eclipse-sig,  2 weeks ago
  kdaniel, orphan, rgrunber
eclipse-launchbar eclipse-sig, orphan, sopotc  4 weeks ago
eclipse-license   eclipse-sig, orphan  2 weeks ago
eclipse-m2e-antlr eclipse-sig, mizdebsk, orphan2 weeks ago
eclipse-m2e-core  eclipse-sig, galileo,2 weeks ago
  mizdebsk, orphan
eclipse-m2e-cxf   eclipse-sig, mizdebsk, orphan2 weeks ago
eclipse-m2e-maven-dependency- mizdebsk, orphan 2 weeks ago
plugin
eclipse-m2e-modello   eclipse-sig, mizdebsk, orphan2 weeks ago
eclipse-m2e-plexuseclipse-sig, mizdebsk, orphan2 weeks ago
eclipse-m2e-sisu  eclipse-sig, mizdebsk, orphan2 weeks ago
eclipse-m2e-takarimizdebsk, orphan 2 weeks ago
eclipse-m2e-workspace   

Re: Non-responsive maintainer: Wes Hardaker (hardaker)

[Wes Hardaker]

Xavier Bachelot  writes:

> I've tried to get in touch with Wes Hardaker about
> perl-Crypt-OpenSSL-X509 for 2 months. The bug was left untouched, even
> after setting need-info flag. I've also tried to reach to him by
> direct mail.

Hi, and sorry both.

I've been swamped lately and haven't had time to update the package.

I'll put it higher on my todo list, but if anyone would like to take
over the package I'd be more than happy to hand over the keys to someone
with more time.
-- 
Wes Hardaker 
My Pictures:   http://capturedonearth.com/
My Thoughts:   http://blog.capturedonearth.com/
___
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 1778701] Non-responsive maintainer check for hardaker

[bugzilla]

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

Wes Hardaker  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Wes Hardaker  ---
I'm still semi-active and can continue maintaining it, but if anyone else has
more energy they can probably respond faster and I wouldn't mind if someone
else wanted to take it over.

-- 
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: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

[John M. Harris Jr]

On Monday, December 2, 2019 9:48:05 AM MST Przemek Klosowski via devel wrote:
> On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:
> >> Mabee systemd-homed is in
> >> a position to solve this by having early enough authentication
> >> capability by rescue.target time that any admin user can login?
> > 
> > Actually, it may. Things are confusing here, because systemd-homed is
> > implemented together with changes to how user metadata querying is done:
> > instead of using dbus, a brokerless and much simpler varlink query is
> > used.
> > That last part is what would be relevant to early-boot logins, because
> > less services need to be up to bring up the user session.
> 
> There's one tricky feature of homed : remote login (ssh) is only
> possible after an initial local login. It is OK for his intended use (a
> personal laptop/tablet client), except for corner cases like a remotely
> accessed personal desktop in the basement that might get rebooted e.g.
> for updates, resulting in an accidental lockout.

Basically, systemd-homed is useless for any power user, but might be useful 
for people just getting into GNU/Linux, who don't use ssh yet or don't have 
more than one system.

-- 
John M. Harris, Jr.
Splentity

___
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] Packaging guidelines

[Mattia Verga]

There used to be some differences between Fedora and EPEL packaging guidelines, 
which were explained in the docs [1].
I don't find any mention in that doc to EPEL8, does that mean there aren't any 
differences or that the page isn't updated for EPEL8?

Mattia

[1] https://fedoraproject.org/wiki/EPEL:Packaging
___
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: RFC: Modularity Simplified

[Przemek Klosowski via devel]

On 12/1/19 10:37 PM, Kevin Kofler wrote:

I definitely want some mechanism which will tell to user that "THIS
PACKAGE IS NOT FULLY SUPPORTED."

And I think telling that to the user is absolutely unfair and against the
spirit of Fedora.

The dilemma is, how to allow the useful stuff to remain, while 
preventing the accumulation of non-functional abandonware, especially 
since one person's trash might be someone else's treasure. It's not good 
when cruft accumulates, as it gives Fedora a  bad name and wastes 
people's time when they stumble into unsupported packages that stop 
working, like in this case:


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

An 'unsupported' warning of some sort could be actually a good thing. 
Perhaps such warning could include a count of unresolved Bugzilla cases 
against the package in question.


___
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 32 System-Wide Change proposal: Disallow Empty Password By Default

[Przemek Klosowski via devel]

On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:

Mabee systemd-homed is in
a position to solve this by having early enough authentication
capability by rescue.target time that any admin user can login?

Actually, it may. Things are confusing here, because systemd-homed is
implemented together with changes to how user metadata querying is done:
instead of using dbus, a brokerless and much simpler varlink query is used.
That last part is what would be relevant to early-boot logins, because
less services need to be up to bring up the user session.


There's one tricky feature of homed : remote login (ssh) is only 
possible after an initial local login. It is OK for his intended use (a 
personal laptop/tablet client), except for corner cases like a remotely 
accessed personal desktop in the basement that might get rebooted e.g. 
for updates, resulting in an accidental lockout.


___
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 1778849] New: perl-Date-Manip-6.79 is available

[bugzilla]

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

Bug ID: 1778849
   Summary: perl-Date-Manip-6.79 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Date-Manip
  Keywords: FutureFeature, Triaged
  Assignee: jpazdzi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: huzai...@redhat.com, jpazdzi...@redhat.com,
ka...@ucw.cz, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 6.79
Current version/release in rawhide: 6.78-1.fc32
URL: http://search.cpan.org/dist/Date-Manip/

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/2785/

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

Summary/Minutes from today's FESCo Meeting (2019-12-02)

[Justin Forbes]

=
#fedora-meeting-1: FESCO (2019-12-02)
=


Meeting started by jforbes at 15:00:40 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-12-02/fesco.2019-12-02-15.00.log.html
.



Meeting summary
---
* init process  (jforbes, 15:00:42)

* #2285 Make Eclipse Installable  (jforbes, 15:03:43)
  * AGREED: Eclipse can be set as the default stream for F31 and F32
(+6,2,-0)  (jforbes, 15:12:11)

* Next week's chair  (jforbes, 15:12:27)
  * ACTION: ignatenkobrain_ will chair next meeting  (jforbes, 15:13:50)

* Open Floor  (jforbes, 15:13:54)
  * AGREED: Python 2 exception: sugar desktop environment close the
request, and ask the submitters to reopen with a concrete list of
packages. (+7,0,0)  (jforbes, 15:22:31)

Meeting ended at 15:25:06 UTC.




Action Items

* ignatenkobrain_ will chair next meeting




Action Items, by person
---
* ignatenkobrain
  * ignatenkobrain_ will chair next meeting
* ignatenkobrain_
  * ignatenkobrain_ will chair next meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* jforbes (27)
* zbyszek (17)
* zodbot (15)
* sgallagh (10)
* nirik (9)
* ignatenkobrain_ (8)
* contyk (4)
* mhroncok_mobile (4)
* bookwar (3)
* mbooth (2)
* ignatenkobrain (1)
* bcotton (1)
* mhroncok (0)
* otaylor (0)
___
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

Undead a package _if_ the new project is unrelated to the old

[Richard W.M. Jones]

Is there a special procedure for undeading a package if the two
packages happen to use the same name but are otherwise unrelated?

virt-v2v was a Perl program that existed up to Fedora 21.  It's long
dead (since 2013) and there's a new program with the same name written
from scratch which I want to add to Fedora.

I've been through a Fedora review of the new package:

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

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: js-jquery - Re: List of long term FTBFS packages to be retired in February (beta)

[Raphael Groner]

Thanks a lot.

Am 02.12.19 um 15:20 schrieb Tom Hughes:
…

As I explained the other day js-jquery was dependent on a
nodejs module (a normal one, not modularised) which was
failing to build and which I have now fixed.

…
___
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: js-jquery - Re: List of long term FTBFS packages to be retired in February (beta)

[Tom Hughes]

On 02/12/2019 14:04, Raphael Groner wrote:

 > I don't think modularity is to blame here.

Nah. The dependent nodejs stack broke away due to move into modularity
worlds.


No, it didn't.

I'm no fan of modularity but there is no need to blame it
for things it is not responsible for.

As I explained the other day js-jquery was dependent on a
nodejs module (a normal one, not modularised) which was
failing to build and which I have now fixed.

The only part of the nodejs stack that is modularised is
the actual nodejs engine - the large set of modules from npm
are just normal packages and that is what was involved here.

Tom

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

Next Open/Public NeuroFedora team meeting: 1600 UTC on Tuesday, 3rd December

[Ankur Sinha]

Hello everyone,

You are invited to the next Open/Public NeuroFedora team meeting at
1600UTC on Tuesday, 3rd December in #fedora-neuro on irc.freenode.net.

You can see the time in your local time zone by running this command in
a terminal:

$ date --date='TZ="UTC" 1600 next Tue'

or using the link below:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+team+meeting=20191203T16=1440=1

More information on joining the meeting on IRC can be found here:
https://fedoraproject.org/wiki/How_to_use_IRC

The channel is also bridged to Telegram: https://t.me/NeuroFedora

The agenda for the meeting is:

- Introductions and roll call.
- Tasks from last meeting: 
https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2019-11-12-15.59.html
- Pagure tickets: 
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
- Open NeuroFedora bugs: https://tinyurl.com/neurofedora-bugs
- Neuroscience of the week: https://pagure.io/neuro-sig/NeuroFedora/issue/318
- Next meeting day, and chair.
- Open floor.

Tomorrow's meeting will be chaired by: @ankursinha

Please let me know if there's anything else that you'd like added to the
agenda. We hope to see you at the meeting.

-- 
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: js-jquery - Re: List of long term FTBFS packages to be retired in February (beta)

[Raphael Groner]

> I don't think modularity is to blame here.

Nah. The dependent nodejs stack broke away due to move into modularity
worlds.


> 3) since the bundling policy is relaxed, everybody just bundles with
zero motivation to maintain package for somebody else.

Ack. The unbundling of js-jsquery has been an explicit requirement in
the package review. So either skip documentation nearly entirely or use
the bundled scripts with a small risk of vulnaribility issues.
___
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: RFC: Branch requests from non-maintainers

[Mat Booth]

On Mon, 2 Dec 2019 at 12:56, Igor Gnatenko 
wrote:

> Hello,
>
> 3 months ago, Miro opened releng ticket[0] raising question whether
> non-maintainers (of some specific packages) being able to request
> branches.
>
> However, it never went anywhere outside of that ticket.
>
> I'd like to ask people on this mailing list a few questions. Let's say
> we have some theoretical package and it has only one maintainer in
> src.fp.o.
>
> * Should any other packager (not that maintainer) be able to request
> new branches on that repo?
>

Is there a problem with adding such other packagers as comaintainers if
they want to maintain such a branch?

For example: I am not at all interested in EPEL branches, but if someone
wants to maintain an EPEL branch of my package, I have absolutely no
problem with adding them as a co-maintainer.
___
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-responsive maintainer: Ian Arnell (iarnell)

[Paul Howarth]

On Mon, 2 Dec 2019 12:07:22 +0100
Xavier Bachelot  wrote:

> Hi,
> 
> I've tried to get in touch with Ian Arnell about perl-Crypt-Rijndael
> for almost 2 months. The bug was left untouched, even after setting 
> need-info flag. I've also tried to reach to him by direct mail.
> 
> Anyone knows how to contact him ?
> 
> Here's the non-responsive maintainer bug :
> https://bugzilla.redhat.com/show_bug.cgi?id=1778699
> 
> The following bugs are assigned to him:
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=iarnell%40gmail.com_to1=1=equals_id=10682424_format=advanced
> 
> He is listed as maintainer for the following packages:
> https://src.fedoraproject.org/user/iarnell/projects

The non-responsive maintainer process for Iain was already done 5 years
ago:
https://lists.fedoraproject.org/pipermail/devel/2014-November/204098.html

Paul.
___
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: dist-git bugzilla sync script being fixed

[Pierre-Yves Chibon]

On Mon, Dec 02, 2019 at 01:26:00PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Nov 29, 2019 at 06:17:36PM +0100, Pierre-Yves Chibon wrote:
> > Good Morning Everyone™,
> > 
> > we have recently spent some time refactoring, improving and fixing the 
> > script
> > that syncs the default assignee and CC list from dist-git to Bugzilla.
> > 
> > Since the script was broken for some time, we felt that it needs some 
> > validation
> > before we run it live (which will still require some work).
> > We have uploaded the results at:
> > https://pingou.fedorapeople.org/distgit_bugzilla_sync.log
> > (Note that this only shows what would be updated.)
> > 
> > We'd appreciate it if you could take some time and check the changes 
> > affecting
> > you and report any issues you might find.
> > An easy way to do this is downloading the file and grepping for your FAS
> > username.
> 
> A bunch of lines look like this:
> 
> [EDITCOMP] Fedora/orsa  initialcclist changed from `[deji', 'lkundrak', 
> 'rakesh', 'mjakubicek', 'zbyszek', 'And 1 more']` to FAS name(s) `['deji', 
> 'lkundrak', 'mjakubicek', 'mmahut', 'rakesh', 'zbyszek']`
> 
> Was "And 1 more" an actual entry in the db, or is this just a rendering 
> artifact?

In order to share this output publicly we mapped back emails (what is used in
bugzilla) to FAS username. The `X more` are the emails we could not map back to
a FAS account.


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: dist-git bugzilla sync script being fixed

[Pierre-Yves Chibon]

On Mon, Dec 02, 2019 at 02:31:39PM +0100, Miro Hrončok wrote:
> On 29. 11. 19 18:17, Pierre-Yves Chibon wrote:
> > Good Morning Everyone™,
> 
> Morning o/
> 
> > we have recently spent some time refactoring, improving and fixing the 
> > script
> > that syncs the default assignee and CC list from dist-git to Bugzilla.
> 
> Will this actualy reassign the existing bugzillas or just set the defaults?

It should do both, this appears in the output in the lines:
... reassigning bug  ...
 

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: RFC: Branch requests from non-maintainers

[Daniel P . Berrangé]

On Mon, Dec 02, 2019 at 01:55:55PM +0100, Igor Gnatenko wrote:
> Hello,
> 
> 3 months ago, Miro opened releng ticket[0] raising question whether
> non-maintainers (of some specific packages) being able to request
> branches.
> 
> However, it never went anywhere outside of that ticket.
> 
> I'd like to ask people on this mailing list a few questions. Let's say
> we have some theoretical package and it has only one maintainer in
> src.fp.o.
> 
> * Should any other packager (not that maintainer) be able to request
> new branches on that repo?
> * Should provenpackager be able to do the same request?

IIUC, effectively "new branches" means "EPEL branches" since normal
Fedora branches are all created automatically.

So to rephrase this

  * Should someone who is not the maintainer be able to declare
that the maintainer must accept EPEL branches & the extra
work that involves thereafter.

AFAIK, there's no requirement that Fedora package maintainers have
to provide EPEL branches, its upto each maintainer if they want that
work.

Personally I don't wish to maintain EPEL branches for any package I'm
maintaining in Fedora, since it is an additional timesink I don't need.
I'm more than happy for people to volunteer as co-maintainers and then
take care of EPEL branches though & thus I've added co-maintainers on
many occassions for this reason.

Even if the request to create the branch by a non-maintainer was
honoured, it wouldn't result in any builds being done on that branch,
nor any bugs being triaged thereafter.

So if the maintainer doesn't want to maintain the EPEL branches, the
only long term viable option is to find willing co-maintainers to join,
who can then request the branch & do builds, triage bugs, etc. 

IOW, I struggle to see a reason to allow someone who is a not a
(co-)maintainer to request new branches in general. I'm not convinced
that provenpackagers should be able to do this either, unless they
want to volunteer to be the explicitly co-maintainer too, in which
case the question doesn't arise.



Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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 1778463] [RFE] EPEL-8 branch for perl-Data-Float

[bugzilla]

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



--- Comment #3 from Paul Howarth  ---
This seems to happen for every new package/branch these days. Usually, waiting
24 hours resolves it as I think there's a cron job that syncs everything over
to koji once a day.

-- 
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: dist-git bugzilla sync script being fixed

[Miro Hrončok]

On 29. 11. 19 18:17, Pierre-Yves Chibon wrote:

Good Morning Everyone™,


Morning o/


we have recently spent some time refactoring, improving and fixing the script
that syncs the default assignee and CC list from dist-git to Bugzilla.


Will this actualy reassign the existing bugzillas or just set the defaults?

Something like: "This component has changed owner..." - I haven't seen that in a 
(long) while. Especially with packages getting orphaned, this was crucial feature.


--
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: Non-responsive maintainer: Ian Arnell (iarnell)

[Silvia Sánchez]

I know the name but it's been a long time I don't see him around.  I don't
think he's working with Fedora anymore.




On Mon, 2 Dec 2019 at 12:08, Xavier Bachelot  wrote:

> Hi,
>
> I've tried to get in touch with Ian Arnell about perl-Crypt-Rijndael for
> almost 2 months. The bug was left untouched, even after setting
> need-info flag. I've also tried to reach to him by direct mail.
>
> Anyone knows how to contact him ?
>
> Here's the non-responsive maintainer bug :
> https://bugzilla.redhat.com/show_bug.cgi?id=1778699
>
> The following bugs are assigned to him:
>
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=iarnell%40gmail.com_to1=1=equals_id=10682424_format=advanced
>
> He is listed as maintainer for the following packages:
> https://src.fedoraproject.org/user/iarnell/projects
>
> Regards,
> Xavier
> ___
> 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

Re: dist-git bugzilla sync script being fixed

[Zbigniew Jędrzejewski-Szmek]

On Fri, Nov 29, 2019 at 06:17:36PM +0100, Pierre-Yves Chibon wrote:
> Good Morning Everyone™,
> 
> we have recently spent some time refactoring, improving and fixing the script
> that syncs the default assignee and CC list from dist-git to Bugzilla.
> 
> Since the script was broken for some time, we felt that it needs some 
> validation
> before we run it live (which will still require some work).
> We have uploaded the results at:
> https://pingou.fedorapeople.org/distgit_bugzilla_sync.log
> (Note that this only shows what would be updated.)
> 
> We'd appreciate it if you could take some time and check the changes affecting
> you and report any issues you might find.
> An easy way to do this is downloading the file and grepping for your FAS
> username.

A bunch of lines look like this:

[EDITCOMP] Fedora/orsa  initialcclist changed from `[deji', 'lkundrak', 
'rakesh', 'mjakubicek', 'zbyszek', 'And 1 more']` to FAS name(s) `['deji', 
'lkundrak', 'mjakubicek', 'mmahut', 'rakesh', 'zbyszek']`

Was "And 1 more" an actual entry in the db, or is this just a rendering 
artifact?

Zbyszek
___
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

dist-git bugzilla sync script being fixed

[Pierre-Yves Chibon]

Good Morning Everyone™,

we have recently spent some time refactoring, improving and fixing the script
that syncs the default assignee and CC list from dist-git to Bugzilla.

Since the script was broken for some time, we felt that it needs some validation
before we run it live (which will still require some work).
We have uploaded the results at:
https://pingou.fedorapeople.org/distgit_bugzilla_sync.log
(Note that this only shows what would be updated.)

We'd appreciate it if you could take some time and check the changes affecting
you and report any issues you might find.
An easy way to do this is downloading the file and grepping for your FAS
username.


Thanks in advance for your help,
Pierre
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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-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

dist-git bugzilla sync script being fixed

[Pierre-Yves Chibon]

Good Morning Everyone™,

we have recently spent some time refactoring, improving and fixing the script
that syncs the default assignee and CC list from dist-git to Bugzilla.

Since the script was broken for some time, we felt that it needs some validation
before we run it live (which will still require some work).
We have uploaded the results at:
https://pingou.fedorapeople.org/distgit_bugzilla_sync.log
(Note that this only shows what would be updated.)

We'd appreciate it if you could take some time and check the changes affecting
you and report any issues you might find.
An easy way to do this is downloading the file and grepping for your FAS
username.


Thanks in advance for your help,
Pierre
___
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

List of long term FTBFS packages to be retired in February (beta)

[Miro Hrončok]

Dear maintainers.

Based on the latest fail to build from source package, the following packages
will be retired from Fedora 32 approximately one week before branching (February 
2020).


Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


The packages in rawhide were not successfully built at least since Fedora 30.

This report is based on dist tags and represents a preliminary list of packages.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

The main purpose is to gather feedback.

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me 
know and we can work together to get a FESCo approval for that.


If you see a package that can be rebuilt, please do so.


Package  (co)maintainers   Latest build
===
arpackbesser82, davidcl,   Fedora 28
  jussilehtola, rathann
dnssec-nodes  hardaker Fedora 27
elasticsearch hubbitus, jvanek, lbazan,Fedora 24
  zbyszek
expresso  jamielinux, nodejs-sig,  Fedora 28
  patches
gnomint   verdurin Fedora 24
golang-gopkg-sourcemapeclipseo, go-sig, jchaloup   Fedora 28
gtef  kalevFedora 29
libocrdma ocrdma   Fedora 27
lilyterm  cwickert Fedora 27
nodejs-shelljsjamielinux, nodejs-sig,  Fedora 29
  patches
nuvola-app-google-calendarmartinkg Fedora 29
nuvola-app-groove martinkg Fedora 28
nuvola-app-logitech-media-martinkg Fedora 29
server
nuvola-app-plex   martinkg Fedora 29
nuvola-app-soundcloud martinkg Fedora 29
nuvola-app-yandex-music   martinkg Fedora 29
owncloud  adamwill, ignatenkobrain,Fedora 28
  jhogarth, kwizart, orphan,
  siwinski
rubygem-connection_pool   anujmore, axilleas   Fedora 24
rubygem-session   gomixFedora 29
shim-unsigned-aarch64 pjones   Fedora 28
shim-unsigned-x64 pjones   Fedora 28
target-isns   grover, mlombard Fedora 27
tcmu-runner   mlombard Fedora 26
telepathy-gabble  aperezbios   Fedora 29
telepathy-salut   aperezbios, johnpFedora 29

The following packages require above mentioned packages:
Depending on: arpack (49), status change: 2017-10-10 (111 weeks ago)
R-igraph (maintained by: qulogic)
R-igraph-1.2.4.1-3.fc31.src requires arpack-devel = 3.5.0-6.fc28
R-igraph-1.2.4.1-3.fc31.x86_64 requires libarpack.so.2()(64bit)

apbs (maintained by: rathann, timfenn)
apbs-1.5-4.fc31.src requires arpack-devel = 3.5.0-6.fc28

armadillo (maintained by: conrads, jamatos, rcurtin)
armadillo-9.600.6-1.fc31.i686 requires libarpack.so.2
armadillo-9.600.6-1.fc31.src requires arpack-devel = 
3.5.0-6.fc28
armadillo-9.600.6-1.fc31.x86_64 requires libarpack.so.2()(64bit)
armadillo-devel-9.600.6-1.fc31.i686 requires arpack-devel = 
3.5.0-6.fc28
armadillo-devel-9.600.6-1.fc31.x86_64 requires arpack-devel = 
3.5.0-6.fc28

exciting (maintained by: marcindulak)
exciting-12-17.fc32.src requires arpack-devel = 3.5.0-6.fc28
exciting-12-17.fc32.x86_64 requires libarpack.so.2()(64bit)
exciting-mpich-12-17.fc32.x86_64 requires 
libarpack.so.2()(64bit)
exciting-openmpi-12-17.fc32.x86_64 requires 
libarpack.so.2()(64bit)

freefem++ (maintained by: cicku, corsepiu, itamarjp)
freefem++-4.4.2-1.fc32.src requires arpack-devel = 3.5.0-6.fc28
freefem++-4.4.2-1.fc32.x86_64 requires libarpack.so.2()(64bit)
freefem++-mpich-4.4.2-1.fc32.x86_64 requires 
libarpack.so.2()(64bit)
freefem++-openmpi-4.4.2-1.fc32.x86_64 requires 
libarpack.so.2()(64bit)

getdp (maintained by: ignatenkobrain, neuro-sig, 

Re: RFC: Modularity Simplified

[Kevin Kofler]

Igor Gnatenko wrote:
> Yes, however maintainer of nodejs does not want to rename binaries and
> patch sources to be parallel-installable.

And that is exactly the problem.

> And today, we would block adding such "compat" package into the
> repositories.

Which is exactly how it should be.

> I agree it would be nice to have them parallel-installable, but I don't
> think we need to force it onto all packages.

But there is actually no way around it because every other approach 
inevitably leads to conflicts.

> We have different problems with modularity, like:
> 
> * Whole new tooling which has its own inputs/outputs (and many times
> it actually does not work)
> * Overcomplication of dependency solving (even after so many years,
> DNF still can't handle it properly)
> * Different workflow from standard packages which hurts
> discoverability and maintainability (basically it creates small
> distros within one distro)
> 
> and many more.

This is true. However, your approach may also introduce this kind of 
practical problems. E.g., if you keep the self-conflicting packages.

(For the record, the logically correct way to handle it would be:
Provides: stream(nodejs) = 10
Conflicts: stream(nodejs) < 10
Conflicts: stream(nodejs) > 10
but I disagree with this Conflicts approach to begin with.)

>> Non-default versions of non-leaf packages MUST be parallel installable
>> with the default version for the distribution to be consistent and for
>> users to be allowed to freely choose their applications without arbitrary
>> conflicts.
> 
> I believe that exactly one of the reasons why Modularity has been
> created. It requires patching of source code and renaming binaries and
> sometimes it is not trivial amount of work.

And this is exactly why I am against Modularity, at least for non-leaf 
packages. (And your proposal does not fix this.)

> And at the end of the day, most of the people probably don't need
> installed multiple versions of a package at the same time (e.g. nodejs).

They do if they want to use 2 (or more) applications that happen to depend 
on different versions of nodejs (something that is entirely beyond the 
user's control) on the same Fedora installation. I think it is entirely 
unacceptable to tell users that they cannot install application A and 
application B on the same Fedora n installation (even though it might have 
worked just fine on Fedora n-1) because A depends on libfoo 2 (or
foo-interpreter 2, this is actually no different) whereas B is stuck on 
libfoo 1. (It might have worked just fine on previous releases before the 
libfoo 2 stream was added.) The purpose of a distribution is to make 
software from different upstreams work together.

>> is just not true. If the 2 different versions of Perl cannot coexist,
>> building Bugzilla against only one version is not possible without making
>> Bugzilla incompatible with anything built against the other version.
> 
> Sure, we just have to accept this until perl is made
> parallel-installable. Which may or may not happen, but if I have
> choice between "only one version of perl and no bugzilla" or "two
> conflicting versions of perl and bugzilla using non-default version of
> perl", I will choose latter. Unfortunately reality is not perfect.

I do not see why it would be so hard to provide compatibility Perl versions 
in non-conflicting compatibility packages. It has already be done in the 
past. It is just a matter of versioning (suffixing) the binaries and the 
directories (e.g., /usr/bin/perl5.28, /usr/share/perl5.28/, etc.). The 
default version may or may not adopt some of this version-suffixing too. The 
only thing that matters is that the non-default versions use it.

> Sure, but let's take specific case. I have had
> rust-smallvec+std-devel-0.6.12-1 which depend on same EVR of
> rust-smallvec-devel. I have updated rust-smallvec-devel to 1.0.0 which
> does not have +std subpackage anymore. On upgrade that causes
> conflicts which can be resolved using --allowerasing --best, but our
> current guidelines say that proper obsoletes must be added somewhere
> so that upgrade works without manual intervention.

In this case, you probably want to add the Obsoletes to rust-smallvec-devel 
rather than fedora-obsolete-packages. That avoids all the bureaucracy and is 
just one line in the specfile that you need to update anyway.

That said, you may actually need or want to ship parallel-installable
rust-smallvec+std-0.6.12-devel, rust-smallvec-0.6.12-devel, and
rust-smallvec-1.0.0-devel instead (the actual package contents are 
inherently parallel-installable anyway!), in which case you don't have to 
Obsolete anything, just orphan and stop updating the 0.6.12 ones if you 
don't need them any longer.

> I believe I never said to not ship such packages (please correct me if
> I did), we perfectly can ship them to the users, but we need to make
> them aware that maintainer won't be providing proper upgradepath and
> might not fix CVEs in the time 

Re: RFC: Branch requests from non-maintainers

[Miro Hrončok]

On 02. 12. 19 13:55, Igor Gnatenko wrote:

Hello,

3 months ago, Miro opened releng ticket[0] raising question whether
non-maintainers (of some specific packages) being able to request
branches.

However, it never went anywhere outside of that ticket.

I'd like to ask people on this mailing list a few questions. Let's say
we have some theoretical package and it has only one maintainer in
src.fp.o.

* Should any other packager (not that maintainer) be able to request
new branches on that repo?


IMHO Yes, but there are a few preconditions:

When Anna requests an epel8 branch on "my" package:

- she maintains it, not me.
- I want to get notified to coordinate with her (in case I actually want to 
maintain it in epel8).


So until we have branch ownership and proper notifications, no.


> * Should provenpackager be able to do the same request?

Only if they are becoming regular maintainers. Provenpackagers requesting 
branches of packages where they are not maintainers is the worst combination. As 
said relatively recently somewhere else on this mailing list, they will create 
it, but nobody will actually maintain it. They will not be even notified on new 
bugzillas until they explicitly set that up somehow.


--
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: Non-responsive maintainer: Matias Kreder (delete)

[Silvia Sánchez]

No, sorry, I don't even know him.




On Mon, 2 Dec 2019 at 12:02, Xavier Bachelot  wrote:

> Hi,
>
> I've tried to get in touch with Matias Kreder about perl-Crypt-Rijndael
> for almost 2 months. The bug was left untouched, even after setting
> need-info flag. I've also tried to reach to him by direct mail.
>
> Anyone knows how to contact him ?
>
> Here's the non-responsive maintainer bug :
> https://bugzilla.redhat.com/show_bug.cgi?id=1778698
>
> The following bugs are assigned to him:
>
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=mkreder%40gmail.com_to1=1=equals_id=10682404_format=advanced
>
> He is listed as maintainer for the following packages:
> https://src.fedoraproject.org/user/delete/projects
>
>
> Regards,
> Xavier
> ___
> 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

Re: Fedora 32 Self-Contained Change proposal: Rebase apt package from apt-rpm to Debian's apt

[Neal Gompa]

On Mon, Dec 2, 2019 at 7:16 AM Vít Ondruch  wrote:
>
> I'm not sure I understand this change.
>
> Does it mean that currently, the "apt-rpm" is tool which installs RPMs
> from Fedora repositories, while the Debians "apt" will install the DEB
> packages coming from Debian?
>
> Does it means that previously, there was only one glibc package
> installed no matter what, but now I'll have the Fedora version coming
> via RPM and also the Debian DEB version installed via apt?
>
> Will these packages mix/conflict on the filesystem? Or may be they
> wan't, because Debian is using slightly different directory structure ...
>

Not quite. apt-rpm, contrary to the name, supported both RPMs and
DEBs. However, it was never configured to install DEBs in Fedora, only
RPMs through fedora-config-apt.

What's happening here is that the apt package is being rebased to the
mainline version, which loses the RPM backend (unless someone wants to
contribute it upstream, they're interested in having one now...). No
configuration to the apt package manager will be included for fetching
Debian packages and installing them.

The software will merely exist to support cross-build tools used for
building Debian packages in clean environments unless an RPM backend
is added to a modern version of apt.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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

RFC: Branch requests from non-maintainers

[Igor Gnatenko]

Hello,

3 months ago, Miro opened releng ticket[0] raising question whether
non-maintainers (of some specific packages) being able to request
branches.

However, it never went anywhere outside of that ticket.

I'd like to ask people on this mailing list a few questions. Let's say
we have some theoretical package and it has only one maintainer in
src.fp.o.

* Should any other packager (not that maintainer) be able to request
new branches on that repo?
* Should provenpackager be able to do the same request?


[0] https://pagure.io/releng/issue/8844
___
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: js-jquery - Re: List of long term FTBFS packages to be retired in February (beta)

[Vít Ondruch]

Dne 28. 11. 19 v 19:43 Raphael Groner napsal(a):
> Hi,
>
> in case of my packages, jpype and pyvirtualize, I'd say to skip
> generation of documentation while js-jquery is b0rken.
>
> What's the issue about js-jquery? I tend to blame modularity due to
> nodejs-*.


I don't think modularity is to blame here.

Previously, there were a lot of bundling exceptions for JS packages. It
took a lot of time to get js-jsquery as independent package.

But 1) the people who did that are probably burned out by the heroic
effort 2) they don't have the cycles anymore or 3) since the bundling
policy is relaxed, everybody just bundles with zero motivation to
maintain package for somebody else.


Vít


>
> Just my 5ct.
>
> Regards, Raphael
>
>
> Am 28.11.19 um 14:05 schrieb Miro Hrončok:
>> Dear maintainers.
>>
>> Based on the latest fail to build from source package, the following
>> packages
>> will be retired from Fedora 32 approximately one week before branching
>> (February 2020).
>>
>> Policy:
>> https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
>>
>>
>> The packages in rawhide were not successfully built at least since
>> Fedora 30.
>>
>> This report is based on dist tags and represents a preliminary list of
>> packages.
>>
>> Packages collected via:
>> https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb
>>
>>
>>
>> The main purpose is to gather feedback.
>>
>> If you see a package that was built, please let me know.
>> If you see a package that should be exempted from the process, please
>> let me know and we can work together to get a FESCo approval for that.
>>
>> If you see a package that can be rebuilt, please do so.
>>
>>
>>     Package  (co)maintainers Latest build
>> ===
>>
>>
>> arpack    besser82, davidcl, Fedora 28
>>   jussilehtola, rathann
>> dnssec-nodes  hardaker Fedora 27
>> elasticsearch hubbitus, jvanek, lbazan, Fedora 24
>>   zbyszek
>> expresso  jamielinux, nodejs-sig, Fedora 28
>>   patches
>> gnomint   verdurin Fedora 24
>> golang-gopkg-sourcemap    eclipseo, go-sig, jchaloup Fedora 28
>> gtef  kalev Fedora 29
>> libocrdma ocrdma Fedora 27
>> lilyterm  cwickert Fedora 27
>> nodejs-shelljs    jamielinux, nodejs-sig, Fedora 29
>>   patches
>> nuvola-app-google-calendar    martinkg Fedora 29
>> nuvola-app-groove martinkg Fedora 28
>> nuvola-app-logitech-media-    martinkg Fedora 29
>> server
>> nuvola-app-plex   martinkg Fedora 29
>> nuvola-app-soundcloud martinkg Fedora 29
>> nuvola-app-yandex-music   martinkg Fedora 29
>> owncloud  adamwill, ignatenkobrain, Fedora 28
>>   jhogarth, kwizart, orphan,
>>   siwinski
>> rubygem-connection_pool   anujmore, axilleas Fedora 24
>> rubygem-session   gomix Fedora 29
>> shim-unsigned-aarch64 pjones Fedora 28
>> shim-unsigned-x64 pjones Fedora 28
>> target-isns   grover, mlombard Fedora 27
>> tcmu-runner   mlombard Fedora 26
>> telepathy-gabble  aperezbios Fedora 29
>> telepathy-salut   aperezbios, johnp Fedora 29
>>
>> The following packages require above mentioned packages:
>> Depending on: arpack (49), status change: 2017-10-10 (111 weeks ago)
>> R-igraph (maintained by: qulogic)
>>     R-igraph-1.2.4.1-3.fc31.src requires arpack-devel = 3.5.0-6.fc28
>>     R-igraph-1.2.4.1-3.fc31.x86_64 requires libarpack.so.2()(64bit)
>>
>> apbs (maintained by: rathann, timfenn)
>>     apbs-1.5-4.fc31.src requires arpack-devel = 3.5.0-6.fc28
>>
>> armadillo (maintained by: conrads, jamatos, rcurtin)
>>     armadillo-9.600.6-1.fc31.i686 requires libarpack.so.2
>>     armadillo-9.600.6-1.fc31.src requires arpack-devel =
>> 3.5.0-6.fc28
>>     armadillo-9.600.6-1.fc31.x86_64 requires libarpack.so.2()(64bit)
>>     armadillo-devel-9.600.6-1.fc31.i686 requires arpack-devel =
>> 3.5.0-6.fc28
>>     armadillo-devel-9.600.6-1.fc31.x86_64 requires arpack-devel =
>> 3.5.0-6.fc28
>>
>> exciting (maintained by: marcindulak)
>>     exciting-12-17.fc32.src requires arpack-devel = 3.5.0-6.fc28
>>     exciting-12-17.fc32.x86_64 requires libarpack.so.2()(64bit)
>>     exciting-mpich-12-17.fc32.x86_64 requires
>> libarpack.so.2()(64bit)
>>     exciting-openmpi-12-17.fc32.x86_64 requires
>> libarpack.so.2()(64bit)
>>
>> freefem++ 

Schedule for Mondays's FESCo Meeting (2019-12-02)

[Justin Forbes]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2019-12-02 15:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

Nonresponsive maintainer: Yohan Graterol yograterol
 https://pagure.io/fesco/issue/2279

= Followups =

#2285 Make Eclipse Installable
https://pagure.io/fesco/issue/2285

= New business =

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
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: RFC: Modularity Simplified

[Petr Pisar]

On 2019-12-02, John M. Harris Jr  wrote:
> On Monday, December 2, 2019 12:17:20 AM MST Igor Gnatenko wrote:
>> Sure, we just have to accept this until perl is made
>> parallel-installable. Which may or may not happen, but if I have
>> choice between "only one version of perl and no bugzilla" or "two
>> conflicting versions of perl and bugzilla using non-default version
>> of perl", I will choose latter. Unfortunately reality is not perfect.
>
> Doesn't that defeat the purpose of using a distro? At that point, you
> might as well go grab some container nonsense, instead of using a real
> system, if you care more for just "make it run", rather than "make it
> run properly on a stable, supported Perl".
>
You assume that a non-default Perl is not stable and supported. While
it's true that non-default streams have probably fewer users and thus
are less tested, that does not mean it is an intention.

-- Petr
___
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 32 Self-Contained Change proposal: Rebase apt package from apt-rpm to Debian's apt

[Vít Ondruch]

I'm not sure I understand this change.

Does it mean that currently, the "apt-rpm" is tool which installs RPMs
from Fedora repositories, while the Debians "apt" will install the DEB
packages coming from Debian?

Does it means that previously, there was only one glibc package
installed no matter what, but now I'll have the Fedora version coming
via RPM and also the Debian DEB version installed via apt?

Will these packages mix/conflict on the filesystem? Or may be they
wan't, because Debian is using slightly different directory structure ...


Vít


Dne 25. 11. 19 v 22:33 Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Changes/Move_apt_package_from_RPM_to_DPKG_backend
>
> == Summary ==
> Currently the apt package in Fedora actually installs apt-rpm,
> starting with Fedora 32 it will provide the regular apt software
> backed by DPKG.
>
> == Owner ==
> * Name: [[User:dridi| Dridi Boukelmoune]],  [[User:ngompa | Neal Gompa]]
> * Email: dr...@fedoraproject.org, ngomp...@gmail.com
>
>
> == Detailed Description ==
> The apt package in Fedora does not ship the mainline apt software from
> Debian, but rather the apt-rpm fork instead. This allows a user to
> copy and paste apt or apt-get commands often found in "Linux"
> tutorials. This will usually work, apt-rpm will resolve dependencies
> from the Yum/DNF repositories and since our package naming guidelines
> often lead to the same package names as apt-based distributions like
> Debian and Ubuntu.
>
> The apt-rpm software is dead upstream and doesn't support rich
> dependencies or modules. It also has known vulnerabilities and
> according to its author other bugs that are never going to be fixed.
>
> == Benefit to Fedora ==
> By switching the Fedora apt package from apt-rpm to regular apt we
> move from a dead to a living upstream. We also close security holes
> and introduce a critical dependency for more packages from the DPKG
> ecosystem. It is already possible to build Deb packages in Fedora,
> including with pbuilder, an equivalent for mock in the DPKG ecosystem,
> however pbuilder uses debootstrap to provision a build environment.
> While we may lose the ability to "apt-get install" Fedora packages
> from the command line, we also open the gate for sbuild, another mock
> equivalent to build Debs in a clean environment. This change offers
> more options to target Debian and derivative systems without leaving
> the Fedora comfort zone.
>
> == Scope ==
> * Proposal owners: re-review of the apt package with the proper
> upstream ([https://bugzilla.redhat.com/show_bug.cgi?id=1764813
> RH#1764813]), and optionally more dependent packages.
> * Other developers: N/A (not a System Wide Change)
> * Release engineering: N/A (not needed for this Change)
> * Policies and guidelines: As apt would conflict with DNF for the host
> system, we may want to ship it without pre-configured repositories.
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> Any user actively relying on apt-rpm will lose functionality that
> cannot be replaced. Because apt-rpm's version is much lower than the
> current apt version, this change will follow the natural upgrade path.
>
> == How To Test ==
> If sbuild is packaged in time for the beta, performing builds with
> sbuild should be enough to confirm that apt was able to provision a
> build root.
>
> == User Experience ==
> Anyone used to paste apt-get commands in a terminal will no longer be
> able to install or remove Fedora packages this way.
>
> On the other hand anyone needing regular apt tooling will be able to
> work with it directly from Fedora.
>
> == Dependencies ==
> Apt shouldn't bring more dependencies, it will be the dependency for
> more packages from the DPKG ecosystem.
>
> == Contingency Plan ==
>
> * Contingency mechanism: Simply retire apt (apt-rpm)
> * Contingency deadline: N/A (not a System Wide Change)
> * Blocks release? N/A (not a System Wide Change)
> * Blocks product? N/A
>
> == Documentation ==
> Once installed, apt ships multiple manual pages available in several
> languages. There will no longer be any references in the shipped apt
> package documentation of handling RPMs.
>
> == Release Notes ==
> The apt package has been rebased from apt-rpm to Debian's apt. This
> means that apt no longer supports handling RPMs or managing RPM-based
> systems. Please use dnf for software management of RPM-based systems
> and 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

Re: Major rewrite of project

[Tomas Korbar]

Thanks for help Fabio.

On Mon, Dec 2, 2019 at 12:10 PM Fabio Valentini 
wrote:

> On Mon, Dec 2, 2019, 11:45 Tomas Korbar  wrote:
>
>> Hi,
>> I would like to ask you a question. If upstream of your package does
>> major rewrite of it, then what is the proper process to rebase such
>> package? I'm maintainer of cheat [0] which has been rewritten in go. I
>> suppose i need a new package review but then if the new spec passes review
>> am i supposed to replace the spec of old package entirely or preserve
>> changelog and add new entry with description of what happened + link to the
>> review?
>>
>
> Hi Tomas,
>
> You don't need to go through package review again, since it's not a new
> package. So just update it to the new version, and keep the old changelog.
>
> However, if you want feedback on the new packaging before pushing it to
> fedora, you could publish the .spec file and submit the new version to a
> COPR repo first, so users can look at it, test it, and give you comments. I
> do it like this for my packages when they have major changes.
>
> It would be another matter if the new version is installable alongside the
> old version, then you could package both of them separately, but I guess
> that's not the case here.
>
> Fabio
>
> [0] - https://github.com/cheat/cheat
>> ___
>> 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
>
___
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: RFC: Modularity Simplified

[John M. Harris Jr]

On Monday, December 2, 2019 12:17:20 AM MST Igor Gnatenko wrote:
> Sure, we just have to accept this until perl is made
> parallel-installable. Which may or may not happen, but if I have
> choice between "only one version of perl and no bugzilla" or "two
> conflicting versions of perl and bugzilla using non-default version of
> perl", I will choose latter. Unfortunately reality is not perfect.

Doesn't that defeat the purpose of using a distro? At that point, you might as 
well go grab some container nonsense, instead of using a real system, if you 
care more for just "make it run", rather than "make it run properly on a 
stable, supported Perl".

-- 
John M. Harris, Jr.
Splentity

___
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 1778463] [RFE] EPEL-8 branch for perl-Data-Float

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Data-Float-0.013-7.el8
   ||perl-Data-Float-0.013-7.epe
   ||l8.playground



--- Comment #2 from Petr Pisar  ---
The package is not white listed in Koji .

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

Fedora rawhide compose report: 20191202.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20191201.n.0
NEW: Fedora-Rawhide-20191202.n.0

= SUMMARY =
Added images:0
Dropped images:  3
Added packages:  1
Dropped packages:5
Upgraded packages:   16
Downgraded packages: 0

Size of added packages:  360.38 KiB
Size of dropped packages:3.47 MiB
Size of upgraded packages:   223.10 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   1.52 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20191201.n.0.ppc64le.raw.xz
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20191201.n.0.ppc64le.qcow2
Image: Cloud_Base vmdk ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20191201.n.0.ppc64le.vmdk

= ADDED PACKAGES =
Package: sqlitecpp-2.4.0-1.fc32
Summary: Smart and easy to use C++ SQLite3 wrapper
RPMs:sqlitecpp sqlitecpp-devel
Size:360.38 KiB


= DROPPED PACKAGES =
Package: extra166y-1.7.0-12.fc31
Summary: Concurrency JSR-166 - Collections supporting parallel operations
RPMs:extra166y extra166y-javadoc
Size:667.11 KiB

Package: felix-osgi-foundation-1.2.0-26.fc31
Summary: Felix OSGi Foundation EE Bundle
RPMs:felix-osgi-foundation felix-osgi-foundation-javadoc
Size:703.69 KiB

Package: jcsp-1.1-0.12.rc5.fc31
Summary: Communicating Sequential Processes for Java (JCSP)
RPMs:jcsp jcsp-javadoc
Size:1.60 MiB

Package: multiverse-0.7.0-11.fc31
Summary: A software transactional memory implementation for the JVM
RPMs:multiverse multiverse-javadoc
Size:499.69 KiB

Package: plexus-cli-1.6-9.fc31
Summary: Command Line Interface facilitator for Plexus
RPMs:plexus-cli plexus-cli-javadoc
Size:45.08 KiB


= UPGRADED PACKAGES =
Package:  atk-2.35.1-1.fc32
Old package:  atk-2.34.1-1.fc32
Summary:  Interfaces for accessibility support
RPMs: atk atk-devel
Size: 2.58 MiB
Size change:  5.74 KiB
Changelog:
  * Mon Dec 02 2019 Kalev Lember  - 2.35.1-1
  - Update to 2.35.1


Package:  bijiben-3.35.1-1.fc32
Old package:  bijiben-3.34.1-1.fc32
Summary:  Simple Note Viewer
RPMs: bijiben
Size: 2.81 MiB
Size change:  -6.22 KiB
Changelog:
  * Mon Dec 02 2019 Kalev Lember  - 3.35.1-1
  - Update to 3.35.1


Package:  bluez-5.52-2.fc32
Old package:  bluez-5.52-1.fc32
Summary:  Bluetooth utilities
RPMs: bluez bluez-cups bluez-hid2hci bluez-libs bluez-libs-devel 
bluez-mesh bluez-obexd
Size: 10.15 MiB
Size change:  410.21 KiB
Changelog:
  * Mon Dec 02 2019 Lubomir Rintel  - 5.52-2
  - Package the btvirt binary


Package:  breezy-3.0.2-1.fc32
Old package:  breezy-3.0.1-4.fc32
Summary:  Friendly distributed version control system
RPMs: breezy breezy-doc
Size: 31.17 MiB
Size change:  3.28 KiB
Changelog:
  * Sun Dec 01 2019 Miro Hron??ok  - 3.0.2-1
  - Update to 3.0.2


Package:  diffoscope-111-4.fc32
Old package:  diffoscope-111-3.fc32
Summary:  In-depth comparison of files, archives, and directories
RPMs: diffoscope
Size: 282.83 KiB
Size change:  64 B
Changelog:
  * Thu Oct 03 2019 Miro Hron??ok  - 111-4
  - Rebuilt for Python 3.8.0rc1 (#1748018)


Package:  eog-3.35.1-1.fc32
Old package:  eog-3.34.1-1.fc32
Summary:  Eye of GNOME image viewer
RPMs: eog eog-devel eog-tests
Size: 19.19 MiB
Size change:  2.58 KiB
Changelog:
  * Mon Dec 02 2019 Kalev Lember  - 3.35.1-1
  - Update to 3.35.1


Package:  et-6.0.4-1.fc32
Old package:  et-6.0.3-1.fc32
Summary:  Remote shell that survives IP roaming and disconnect
RPMs: et
Size: 4.05 MiB
Size change:  -99.31 KiB
Changelog:
  * Sun Dec 01 2019 Michel Alexandre Salim  - 6.0.4-1
  - Update to 6.0.4


Package:  ht-2.1.0-6.fc32
Old package:  ht-2.1.0-2.fc31
Summary:  File editor/viewer/analyzer for executables
RPMs: ht
Size: 3.35 MiB
Size change:  -38.85 KiB
Changelog:
  * Sun Dec 01 2019 Vitaly Zaitsev  - 2.1.0-6
  - Revived package. Fixed FTBFS.


Package:  nbdkit-1.17.1-1.fc32
Old package:  nbdkit-1.16.0-6.fc32
Summary:  NBD server
RPMs: nbdkit nbdkit-bash-completion nbdkit-basic-filters 
nbdkit-basic-plugins nbdkit-curl-plugin nbdkit-devel nbdkit-example-plugins 
nbdkit-ext2-plugin nbdkit-guestfs-plugin nbdkit-gzip-plugin nbdkit-iso-plugin 
nbdkit-libvirt-plugin nbdkit-linuxdisk-plugin nbdkit-lua-plugin 
nbdkit-nbd-plugin nbdkit-ocaml-plugin nbdkit-ocaml-plugin-devel 
nbdkit-perl-plugin nbdkit-python-plugin nbdkit-ruby-plugin nbdkit-server 
nbdkit-ssh-plugin nbdkit-tar-plugin nbdkit-tcl-plugin nbdkit-vddk-plugin 
nbdkit-xz-filter
Size: 5.28 MiB
Size change:  -1.20 MiB
Changelog:
  * Sun Dec 01 2019 Richard W.M. Jones  - 1.17.1-1
  - New upstream development version 1.17.1.
  - Add nbdkit-eval-plugin.
  - Add nbdkit-ip-filter.


Package:  php-PhpOption-1.6.0-1.fc32
Old