koji & s390x - [Errno 111] Connection refused

[Lumir Balhar]

Hello.

I am building python-cassandra-driver in Koji and my last two attempts 
failed on s390x with error: URLError: Connection refused>


I found also other builds with the same issue:

* https://koji.fedoraproject.org/koji/taskinfo?taskID=32919248
* https://koji.fedoraproject.org/koji/taskinfo?taskID=32918607
* https://koji.fedoraproject.org/koji/taskinfo?taskID=32919840
* https://koji.fedoraproject.org/koji/taskinfo?taskID=32920470 (noarch 
package)

* https://koji.fedoraproject.org/koji/taskinfo?taskID=32920521
* https://koji.fedoraproject.org/koji/taskinfo?taskID=32920386
* https://koji.fedoraproject.org/koji/taskinfo?taskID=32918406

Could please anybody take a look on that?

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

[389-devel] Pleas review

[Anuj Borah]

Hi all,

Please review bellow PRs:

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

Its pending from long time.

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

Re: F31 System-Wide Change proposal: BuildRequires Generators

[Nicolas Mailhot]

Le mardi 19 février 2019 à 18:04 +, Raphael Groner a écrit :
> 
> Although, I doubt in general that any automagic with dependency
> generators brings a huge benefit in the long run.

That depends on the amount of deps the language uses. Human
handcrafting is always better but it does not scale past a certain
amount of dep and dep changes that need managing

Regards,

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

Re: libravatar is in fedorainfracloud!

[John Harris]

On Tuesday, February 19, 2019 11:46:16 PM EST Michal Novotny wrote:
> Hello!
> 
> maybe you know that around April 2018, there was an announcement that
> libravatar service (a service for serving user avatars) is shutting
> down:
> https://blog.libravatar.org/posts/Libravatar.org_is_shutting_down_on_2018-0
> 9-01/
 
> This raised a big wave of interest in the service and in keeping it
> alive because libravatar was here for quite a long time and used by
> many parties including Pagure, Mozilla Firefox, or Linux kernel. A
> group of people formed with the goal to port libravatar to a new
> platform and new servers and
> https://blog.libravatar.org/posts/Libravatar.org_is_not_going_away/
> was published. Then the work on saving libravatar had begun...
> 
> And now, it is finally done! Yesterday at 17pm UTC, Francois Marier
> flipped the DNS switch to point www.libravatar.org to the new server
> and completely new, modern implementation placed in our Fedora cloud!
> \o/ Check it out here: www.libravatar.org
> 
> I think it's quite a nice message of how well people in Open Source
> and Free Software can cooperate and how they can make something
> significant happen. I would like to say thank you to them and in
> particular to:
> 
> Oliver Falk who rewrote libravatar from scratch
> (https://git.linux-kernel.at/oliver/ivatar)
> 
> Francois Marier who wrote and maintained the original libravatar and
> who was helping us all the time with the migration
> 
> Tristan Le Guern who was testing the new implementation and provided
> great insights
> 
> Niklas Poslovski who themed new libravatar
> 
> Lars Kruse who lead our IRC meetings and setup our @libravatar.org
> email addresses
> 
> Me who setup the new servers in Fedora Infra Cloud and did some
> testing of the new implementation too
> 
> I would also like to thank the Fedora community and the Infra team for
> providing us with the space in the cloud for the new service.
> 
> So yeah, if your avatars are not served properly, you know whom to
> blame :). You can get in touch with us on #libravatar Freenode
> channel. Through https://git.linux-kernel.at/oliver/ivatar bugtracker
> or by writing to libravatar-f...@lists.launchpad.net mailing list.
> 
> Enjoy
> clime
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Awesome! I'm glad we won't be losing libravatar, and I couldn't be happier 
that it's supported by Fedora's Infra.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

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

libravatar is in fedorainfracloud!

[Michal Novotny]

Hello!

maybe you know that around April 2018, there was an announcement that
libravatar service (a service for serving user avatars) is shutting
down: 
https://blog.libravatar.org/posts/Libravatar.org_is_shutting_down_on_2018-09-01/

This raised a big wave of interest in the service and in keeping it
alive because libravatar was here for quite a long time and used by
many parties including Pagure, Mozilla Firefox, or Linux kernel. A
group of people formed with the goal to port libravatar to a new
platform and new servers and
https://blog.libravatar.org/posts/Libravatar.org_is_not_going_away/
was published. Then the work on saving libravatar had begun...

And now, it is finally done! Yesterday at 17pm UTC, Francois Marier
flipped the DNS switch to point www.libravatar.org to the new server
and completely new, modern implementation placed in our Fedora cloud!
\o/ Check it out here: www.libravatar.org

I think it's quite a nice message of how well people in Open Source
and Free Software can cooperate and how they can make something
significant happen. I would like to say thank you to them and in
particular to:

Oliver Falk who rewrote libravatar from scratch
(https://git.linux-kernel.at/oliver/ivatar)

Francois Marier who wrote and maintained the original libravatar and
who was helping us all the time with the migration

Tristan Le Guern who was testing the new implementation and provided
great insights

Niklas Poslovski who themed new libravatar

Lars Kruse who lead our IRC meetings and setup our @libravatar.org
email addresses

Me who setup the new servers in Fedora Infra Cloud and did some
testing of the new implementation too

I would also like to thank the Fedora community and the Infra team for
providing us with the space in the cloud for the new service.

So yeah, if your avatars are not served properly, you know whom to
blame :). You can get in touch with us on #libravatar Freenode
channel. Through https://git.linux-kernel.at/oliver/ivatar bugtracker
or by writing to libravatar-f...@lists.launchpad.net mailing list.

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

[Bug 1678623] Review Request: strip-nondeterminism - File non-deterministic information stripper

[bugzilla]

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



--- Comment #2 from Sergio Monteiro Basto  ---
It would be nice if we support epel 7 at least, I got this error [1] complete
logs [2] 
Thanks

[1]
BUILDSTDERR: Installed (but unpackaged) file(s) found:
BUILDSTDERR:   
/usr/lib64/perl5/vendor_perl/auto/File/StripNondeterminism/.packlist

[2] 
https://copr-be.cloud.fedoraproject.org/results/sergiomb/debs/epel-7-x86_64/00860413-strip-nondeterminism/
https://copr-be.cloud.fedoraproject.org/results/sergiomb/debs/epel-7-x86_64/00860413-strip-nondeterminism/build.log.gz

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

[Bug 1674257] perl-Module-Load-0.34 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Module-Load-0.34-1.fc3 |perl-Module-Load-0.34-1.fc3
   |0   |0
   |perl-Module-Load-0.34-1.fc2 |perl-Module-Load-0.34-1.fc2
   |8   |8
   ||perl-Module-Load-0.34-1.fc2
   ||9



--- Comment #7 from Fedora Update System  ---
perl-Module-Load-0.34-1.fc29 has been pushed to the Fedora 29 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1674257] perl-Module-Load-0.34 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Module-Load-0.34-1.fc3 |perl-Module-Load-0.34-1.fc3
   |0   |0
   ||perl-Module-Load-0.34-1.fc2
   ||8
 Resolution|--- |ERRATA
Last Closed||2019-02-20 02:37:07



--- Comment #6 from Fedora Update System  ---
perl-Module-Load-0.34-1.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

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

Fedora Atomic Host Two Week Release Announcement: 29.20190219.0

[noreply]

A new Fedora Atomic Host update is available via an OSTree update:

Version: 29.20190219.0
Commit(x86_64): d00adf110907f93f6cdd05deda0e2878c9bd71c74e0c4c2e9a5250d2f4cc8868
Commit(aarch64): 
b87cb9e59aa668ea0e79c3d2e7c017a340c03dcf79a2f7756fedddb3831ca74e
Commit(ppc64le): 
33ee5adfd3e33c8e03ad460c75fe71858528f0d91cffd9c01c07a92b2ad000c2


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-20190219.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190219.0.aarch64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190219.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190219.0.aarch64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190219.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190219.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190219.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190219.0.ppc64le.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190219.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190219.0.ppc64le.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190219.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190219.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190219.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190219.0.x86_64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190219.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190219.0.x86_64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190219.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190219.0.x86_64.vagrant-libvirt.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190219.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190219.0.x86_64.vagrant-virtualbox.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190219.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190219.0.iso

Respective signed CHECKSUM files can be found here:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190219.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190219.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190219.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190219.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190219.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190219.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190219.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190219.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190219.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190219.0-x86_64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190219.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190219.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

Filename fetching URLs are available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest_filename
https://getfedora.org/atomic_raw_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest_filename
https://getfedora.org/atomic_raw_aarch64_latest_filename
https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest_filename
https://getfedora.org/atomic_raw_ppc64le_latest_filename

Re: RFE: fedpkgdiff?

[Todd Zullinger]

Hi,

Richard Shaw wrote:
> Out of curiosity I took a look at abipkgdiff that's provided by the
> libabigail package and it's a python wrapper around abipkgdiff. I'm a
> little rusty on Python but I could probably use that as a very nice
> starting point...
> 
> The next question is what package would the wrapper go in? I think the
> natural place is fedora-packager.

That or integrate it into rpkg/fedpkg as a subcommand if
you're writing it in python anyway.

If you decide to propose it for inclusion in fedora-packager
(or anything other than as an rpkg/fedpkg subcommand), may I
suggest that the command name use some prefix other than
than fedpkg-, to avoid extra typing when tab completing
fedpkg commands?  If it's in fedora-packager, fedora- would
probably be a reasonable prefix.

Thanks, and happy hacking,

-- 
Todd


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

Re: Fedora 30 Mass Branching Starting Today

[Elliott Sales de Andrade]

Hi,

On Tue, 19 Feb 2019 at 09:21, Mohan Boddu  wrote:
>
> Hello All,
>
> Fedora 30 will be branched from rawhide today as per the Fedora 30 
> schedule[1]. The process takes about a day and everything should be ready by 
> tomorrow. You can still be able to build packages normally until then, but 
> after the mass branching rawhide and F31 will be separated.
>

I don't know if this is because branching is not complete, but it
looks like this did not take effect for new packages.

For example, my request for R-tidyselect [2], resulted in a master
branch (building for f31) only, but the package was tagged into
f30-pending, so I cannot build it. (Actually, I do need to request f30
as well, now.)

> We will send another email once the branching is done.
>
> Thanks,
> Fedora Release Engineering.
>
> [1] https://fedoraproject.org/wiki/Releases/30/Schedule
[2] https://pagure.io/releng/fedora-scm-requests/issue/9825

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

Re: PSA: Bodhi cannot associate bugs with updates right now

[Randy Barlow]

On Tue, 2019-02-19 at 10:43 -0500, Randy Barlow wrote:
> https://github.com/fedora-infra/bodhi/issues/3024

Bodhi 3.13.2 has been deployed to production just now, which should
address the above issue. You should again be able to associate bugs
with updates. Apologies for the issue!


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

Re: F30 System-Wide Change proposal: Move Gold Into A SubpackageOf Binutils

[Miro Hrončok]

On 19. 02. 19 22:37, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/BINUTILS_GOLD

== Summary ==
Move the GOLD linker from the main binutils package into its own sub-package.


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

Re: F30 System-Wide Change proposal: Move Gold Into A SubpackageOf Binutils

[Ben Cotton]

On Tue, Feb 19, 2019 at 4:40 PM Neal Gompa  wrote:

> This looks like a Fedora 31 change, not a Fedora 30 change?
>
That is correct. I am going back to sleep now.



-- 
Ben Cotton
Fedora Program Manager
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

abrt's usefulness for Firefox bug reporting

[Chris Murphy]

I've got a 100% reproducible crash[1] with Firefox on Wayland, but
I've run into a brick wall getting it properly reported.

Neither coredumpctl nor abrt even report a crash, so no coredump file
exists. I was advised in my bug report that abrt doesn't provide
useful information anyway [1], so I should collect it directly with
gdb.

The problem I then encountered: the laptop becomes a hair dryer and
unresponsive for at least 60 minutes with zero crash information
written out, so I gave up. I've processed coredumps from other
applications before with gdb, it usually takes less than a minute.
Anyway, it seems like a problem if possibly the most popular
application on Fedora is this difficult to debug.

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

[2]
https://bugzilla.redhat.com/show_bug.cgi?id=1676331#c2

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

Re: F30 System-Wide Change proposal: Move Gold Into A SubpackageOf Binutils

[Neal Gompa]

On Tue, Feb 19, 2019 at 4:38 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/BINUTILS_GOLD
>

This looks like a Fedora 31 change, not a Fedora 30 change?


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

F30 System-Wide Change proposal: Move Gold Into A SubpackageOf Binutils

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/BINUTILS_GOLD

== Summary ==
Move the GOLD linker from the main binutils package into its own sub-package.

== Owner ==
* Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
* Email: ni...@redhat.com

== Detailed Description ==
The GOLD linker is currently part of the binutils package.
Unfortunately it seems that Google have decided not to continue
development of the linker, and so it is possible that it may start to
bit-rot. The linker is still being maintained by the upstream GNU
Binutils project, but new development is not happening. Thus as a
precautionary measure I would like to move GOLD into its own
sub-package of the binutils, in case in the future we decide that it
should be deprecated.

== Benefit to Fedora ==

In the short term none.  Although also in the short term the change
should have no effect on Fedora.  In the long term moving the gold
linker into its own package means that it could then be removed from
Fedora, should it turn out to be unmaintainable.

== Scope ==
* Proposal owners: Create a sub-package of the binutils package
containing just the gold linker.
* Other developers: Packages that use the gold linker should add a
requirement on the new sub-package.
* Release engineering: https://pagure.io/releng/issue/8130 (a check of
an impact with Release Engineering is needed)
A mass rebuild would be useful as it will help to identify packages
that need to update their requirements.
* Policies and guidelines: The packaging guidelines should be updated
to indicate that any package that uses the gold linker should have a
requirement on the new sub-package.
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
In theory there should be no impact when upgrading.  As long as
packages that need a linker have a dependency upon the binutils
package, the new gold sub-package should be included as well.

== How To Test ==
No special hardware is needed, but a environment capable of building
packages is desirable.
First install the binutils package (if not already installed) and make
sure that both ld.bfd and ld.gold are in the search path.
Then try uninstalling the binutils-gold sub-package.  This should
remove ld.gold.  Try reinstalling it, which should restore ld.gold.

== User Experience ==
Ideally users should not notice any difference in their experience with Fedora.

== Dependencies ==
None.

== Contingency Plan ==
* Contingency mechanism: Restore GOLD to the main binutils package.
This can be done by anyone familair with spec files, although ideally
it would be done by the binutils package maintainer (ie me).
* Contingency deadline: F31 release.
* Blocks release? No
* Blocks product? No

== Documentation ==
None written yet.



-- 
Ben Cotton
Fedora Program Manager
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Retiring pysvn (was Re: Orphaning pysvn (and non-responsive maintainer: ravenoak))

[Miro Hrončok]

On 19. 02. 19 20:00, Barry Scott wrote:

Sorry this was supposed to go only to Kevin.


Actually, it's perfect that this went to devel.
Everybody knows what's going on.
The true spirit of open source and open collaboration. Please, keep doing this.

Good luck with packaging, Barry!

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

[Bug 1678915] New: perl-Test-Timer-2.10 is available

[bugzilla]

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

Bug ID: 1678915
   Summary: perl-Test-Timer-2.10 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test-Timer
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.10
Current version/release in rawhide: 2.09-5.fc30
URL: http://search.cpan.org/dist/Test-Timer/

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

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

Re: Ditch RPM in favor of DPKG

[Dridi Boukelmoune]

> I'm the debhelper maintainer
>
> where are your packages submissions ? (can you add me please )

https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config
https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism

I CC'd you just now. According to Neal we may not need to package GNU
config, let's move the discussion in that ticket.

> I have reports that pbuilder works fine even in el7 (with packages of
> epel7)

I have used pdebuild in the past on Fedora and maybe that one works,
but I think I had to run pbuilder on an ubuntu system to build my base
images and then use them on Fedora with pdebuild.

It's been a while.

With my package submissions, I'm finally able to do my deb packaging
directly in my favorite OS :)

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

Re: Ditch RPM in favor of DPKG

[Sérgio Basto]

On Tue, 2019-02-19 at 20:00 +0100, Dridi Boukelmoune wrote:
> > TLDR ,  apt-rpm should be retired because nobody use it since more
> > than
> > 10 years .
> > 
> > I maintain a lot of debian package in Fedora but apt-debian still
> > not
> > on Official repos you can get it from my devel corp repo [1]
> > My goal is make a system where rpm produce deb files , to allow
> > Debian
> > migrate from deb to rpm .
> > rpm is much more powerful than Debian IMHO .
> > 
> > [1]
> > https://copr.fedorainfracloud.org/coprs/sergiomb/debs/monitor/
> > 
> > 
> > I can build .deb packages in Fedora and download packages with apt-
> > debian :
> > 
> > debuild -i -us -uc -b -d
> > from
> > 
https://wiki.archlinux.org/index.php/Creating_packages_for_other_distributions#Tips_and_tricks_2
> 
> That's the beauty of the DPKG ecosystem, you always have a myriad of
> seemingly same tools and they often lack consistency.
> 
> Should I use debuild, dpkg-buildpackage, or one of the two others?
> 
> With or without rules? Should I rely on debhelper?
> 
> The list goes on.
> 
> > You may also need to override dh_shlibdeps by adding the following
> > lines to debian/rules:
> > 
> > override_dh_shlibdeps:
> > 
> >dh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info
> 
> Yes, that one needs an override on Fedora.
> 
> > and
> > override_dh_strip_nondeterminism:
> 
> That one should be solved by one of my package submissions.

I'm the debhelper maintainer 

where are your packages submissions ? (can you add me please ) 

I have reports that pbuilder works fine even in el7 (with packages of
epel7) 



> 
> > From [1] "I'd like propose retire this apt and fedora-package-
> > config-
> > apt".
> > 
> > [1]
> > https://bugzilla.redhat.com/show_bug.cgi?id=1462485
> 
> Again, I have no problem with apt-rpm if someone wants to maintain it
> and it keeps working, my problem is that it's called apt.
> 
> Dridi
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 30 Change checkpoint: code complete (testable)

[Ben Cotton]

According to the Fedora 30 schedule[1], today is the deadline for
changes to be in a testable state. If your change is ready to be
tested, please set the status in the tracker bug to MODIFIED. If you
know your change will not be ready for Fedora 30, you can set the
version to rawhide and notify me. For more information about this
milestone, see the Changes Policy[2].

As a reminder, the 100% code complete checkpoint is 2019-03-05. This
is the same day as the beginning of the Beta freeze. Change should be
fully complete and have tracking bugs set to ON_QA by that date.


[1] https://fedoraproject.org/wiki/Releases/30/Schedule
[2] 
https://fedoraproject.org/wiki/Changes/Policy#Change_Checkpoint:_Completion_deadline

-- 
Ben Cotton
Fedora Program Manager
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1678889] New: perl-Daemon-Control-0.001009 is available

[bugzilla]

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

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



Latest upstream release: 0.001009
Current version/release in rawhide: 0.001008-10.fc30
URL: http://search.cpan.org/dist/Daemon-Control/

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

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

Review request

[Robert-André Mauchin]

Hi Perl SIG,

Can a kind soul help with a review?

Review Request: perl-File-Rsync - Perl module interface to rsync
https://bugzilla.redhat.com/show_bug.cgi?id=1678884

Thank you,

Robert-André

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

Re: Using docs related fields in Bugzilla

[Ankur Sinha]

On Tue, Feb 19, 2019 09:48:19 -0800, Kevin Fenzi wrote:
> On 2/19/19 2:49 AM, Ankur Sinha wrote:
> > Hello,
> > 
> > While going through the NeuroFedora package reviews, I was wondering if
> > it were OK for us to use the documentation related fields in Bugzilla to
> > mark that we need to update our documentation at
> > https://neuro.fedoraproject.org. Is it OK if we:
> > 
> > - set a docs contact
> > - set doc type
> > - set doc text?
> 
> yes, I think so. We don't use or sync that information in Fedora
> components, so it should be fine.
> 
> If you run into issues, let us know.

Lovely---thanks very much.

-- 
Thanks,
Regards,

Ankur Sinha "FranciscoD"
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1678879] New: perl-Plack-Middleware-ReverseProxy-0.16 is available

[bugzilla]

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

Bug ID: 1678879
   Summary: perl-Plack-Middleware-ReverseProxy-0.16 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Plack-Middleware-ReverseProxy
  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: 0.16
Current version/release in rawhide: 0.15-18.fc30
URL: https://metacpan.org/release/Plack-Middleware-ReverseProxy

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

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

[Bug 1678875] New: perl-DBIx-Class-Schema-Config-0.001012 is available

[bugzilla]

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

Bug ID: 1678875
   Summary: perl-DBIx-Class-Schema-Config-0.001012 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DBIx-Class-Schema-Config
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.001012
Current version/release in rawhide: 0.001011-12.fc30
URL: http://search.cpan.org/dist/DBIx-Class-Schema-Config/

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

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

Re: Ditch RPM in favor of DPKG

[Dridi Boukelmoune]

On Tue, Feb 19, 2019 at 7:08 PM Tomasz Kłoczko  wrote:
>
> On Tue, 19 Feb 2019 at 11:11, Dridi Boukelmoune  
> wrote:
> [..]
>>
>> Apt is a mix of C, Perl and C++ code, so I would be reassured if I
>> could have a C++ co-maintainer too. I'm only a C developer so if
>> something goes wrong outside of the C realm that would be helpful.
>
>
> Doesn't matter in what kind of language is written PM. Probably you are not 
> aware that but initially rpm it was written 100% in perl. Nevertheless forget 
> about such change.

It does if things break during an upgrade and I have to patch it.

> DPKG technologically stopped evolving about +15 years ago and today rpm 
> packages relies on many features never implemented in DPKG (not only on area 
> of managing installed/upgraded software but building packages as well).
> In other words: move from rpm to dpkg would be only a lot of effort spent to 
> make happier really small bunch of people increasing only effort for the rest 
> of packagers and package consumers.

My problem is that I want to improve my work experience when it comes
to building debs and evolving packaging.

> What I see which potentially could make a sense would be writing rpm backend 
> to generate deb packages out of spec files.

What an alien concept, if you catch my drift... :p

> That would be beneficial for part of the Debian community the same way as 
> using rpm spec files to build IPS packages on Solaris. Such goal is possible 
> to archive the same way as in case of IPS by writing short wrapper like that 
> on on http://pkgbuild.sf.net/
> Fill free to code such tool .. you have already spec file parser and other 
> bits written so >=80-90% necessary work is already done.
>
> As long as it has nothing to do with Fedora for me EOT.
>
> kloczek
> --
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Retiring pysvn (was Re: Orphaning pysvn (and non-responsive maintainer: ravenoak))

[Barry Scott]

Sorry this was supposed to go only to Kevin.

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

Re: Ditch RPM in favor of DPKG

[Dridi Boukelmoune]

> TLDR ,  apt-rpm should be retired because nobody use it since more than
> 10 years .
>
> I maintain a lot of debian package in Fedora but apt-debian still not
> on Official repos you can get it from my devel corp repo [1]
> My goal is make a system where rpm produce deb files , to allow Debian
> migrate from deb to rpm .
> rpm is much more powerful than Debian IMHO .
>
> [1]
> https://copr.fedorainfracloud.org/coprs/sergiomb/debs/monitor/
>
>
> I can build .deb packages in Fedora and download packages with apt-
> debian :
>
> debuild -i -us -uc -b -d
> from
> https://wiki.archlinux.org/index.php/Creating_packages_for_other_distributions#Tips_and_tricks_2

That's the beauty of the DPKG ecosystem, you always have a myriad of
seemingly same tools and they often lack consistency.

Should I use debuild, dpkg-buildpackage, or one of the two others?

With or without rules? Should I rely on debhelper?

The list goes on.

> You may also need to override dh_shlibdeps by adding the following
> lines to debian/rules:
>
> override_dh_shlibdeps:
>
>dh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info

Yes, that one needs an override on Fedora.

> and
> override_dh_strip_nondeterminism:

That one should be solved by one of my package submissions.

> From [1] "I'd like propose retire this apt and fedora-package-config-
> apt".
>
> [1]
> https://bugzilla.redhat.com/show_bug.cgi?id=1462485

Again, I have no problem with apt-rpm if someone wants to maintain it
and it keeps working, my problem is that it's called apt.

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

Re: Retiring pysvn (was Re: Orphaning pysvn (and non-responsive maintainer: ravenoak))

[Barry Scott]

> On 18 Feb 2019, at 18:08, Kevin Fenzi  wrote:
> 
> On 2/15/19 5:56 AM, Barry Scott wrote:
>> 
>> 
>>> On 13 Feb 2019, at 13:52, Stephen Gallagher  wrote:
>>> 
>>> On Tue, Feb 5, 2019 at 10:01 AM Stephen Gallagher  
>>> wrote:
 
 I've been maintaining this for several years since the main admin
 (ravenoak) vanished from Fedora. I don't use it anymore (and most of
 the world has long since switched to git...) and it has yet again
 failed to rebuild during the mass rebuild.
 
 I'm initiating the Non-Responsive Maintainer process for ravenoak so
 the main admin will be cleared. If anyone wants to take it over, I'll
 happily make them a comaintainer on request.
>>> 
>>> No one seems to be jumping at taking this over, so I'm probably going
>>> to move towards retiring this package before F30 Beta Freeze. It's
>>> currently only used by three packages that I can find:
>> 
>> 
>> Just heard about this. I'm the author of pysvn.
>> 
>> I'd be willing to maintain the fedora package of
>> pysvn. What do you need me to do?
>> 
>> I am an active user and developer on Fedora and I create and maintain
>> a numbers of RPMs in my work and personal projects.
>> 
>> Barry
> 
> Hey Barry. Contact me off list and I can help you get setup.
> 
> You will need a fas account ( https://admin.fedoraproject.org/accounts )
> and take a look at

I already have a fas account username: barryascott

> 
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers 
> 

I have a bugzilla account under ba...@barrys-emacs.org 
 and can se
the fas login.

> 
> but of course since the package already exists a lot of this will be
> short circuted.

I can start by doing the work to update pysvn to the latest version
using the instruction in the Wiki.

It might be the weekend before I have time to do this.

Do you need to add me to the "fedora packager group"
or do I use the fedpkg clone -a until my first commit is reviewed to
make sure I keep up the standards?

> 
> Thanks so much for taking this on!

No problem.

Barry

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

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

Re: Ditch RPM in favor of DPKG

[Dridi Boukelmoune]

> For what it's worth, this was a terrible lede for this email. And

I couldn't help it, my inner prankster insisted :)

> having worked extensively with both package managers, I can sincerely
> tell you both are ugly as hell, but rpm is less ugly than dpkg.

Yes, I'm not saying that rpm is perfect, but at least I can wrap my
head around the tooling, the installation process (in a broad sense)
and the tools built on top like yum/dnf or mock.

The range of tools from dpkg to sbuild/pdebuild make little sense to
me, even after gaining significant experience because of $DAYJOB.

> Thankfully, I don't need to go into the reasons why, because this is
> not actually about switching to dpkg and its completely terrible
> system.

Apologies on behalf of my inner prankster :)

> If all you wanted was the rest of the tooling in so you can build
> Debian packages in Fedora, that's really not a problem. I made an
> apt-dpkg package a while ago and worked with APT upstream to make it
> build and have the tests work (mostly) on Fedora a couple of years
> ago. I imported it into COPR so you can see it:
> https://copr.fedorainfracloud.org/coprs/ngompa/apt-dpkg/build/860086/
>
> Instead of renaming the apt package to apt-rpm, we can introduce the
> apt-dpkg package that conflicts with apt for your purposes.

But I've been bit by "dnf install apt" in the past and I think we
should stick to upstream naming.

> I wish we could have the rpm backend integrated into the Debian
> upstream apt, but someone needs to drive that effort, and no one
> really cares anymore. It hasn't happened in the past due to
> frustrations with working with Debian upstream, and now it's diverged
> so much that they are separate upstreams. My understanding is that the
> current upstream developers are interested in an rpm backend, but they
> don't want to do any effort to make it happen.
>
> Also, you can build debs using RPM spec files[1], if you're aware
> enough to handle the differences. :)
>
> [1]: https://github.com/ascherer/debbuild

I'm not aware, and that probably wouldn't work for $DAYJOB.

Thanks for stepping up as a reviewer!

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

Re: Ditch RPM in favor of DPKG

[Tomasz Kłoczko]

On Tue, 19 Feb 2019 at 11:11, Dridi Boukelmoune 
wrote:
[..]

> Apt is a mix of C, Perl and C++ code, so I would be reassured if I
> could have a C++ co-maintainer too. I'm only a C developer so if
> something goes wrong outside of the C realm that would be helpful.
>

Doesn't matter in what kind of language is written PM. Probably you are not
aware that but initially rpm it was written 100% in perl. Nevertheless
forget about such change.
DPKG technologically stopped evolving about +15 years ago and today rpm
packages relies on many features never implemented in DPKG (not only on
area of managing installed/upgraded software but building packages as well).
In other words: move from rpm to dpkg would be only a lot of effort spent
to make happier really small bunch of people increasing only effort for the
rest of packagers and package consumers.

What I see which potentially could make a sense would be writing rpm
backend to generate deb packages out of spec files. That would be
beneficial for part of the Debian community the same way as using rpm spec
files to build IPS packages on Solaris. Such goal is possible to archive
the same way as in case of IPS by writing short wrapper like that on on
http://pkgbuild.sf.net/
Fill free to code such tool .. you have already spec file parser and other
bits written so >=80-90% necessary work is already done.

As long as it has nothing to do with Fedora for me EOT.

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

Re: F31 System-Wide Change proposal: BuildRequires Generators

[Raphael Groner]

Hi,

maybe you already noticed, there's a project called pipreqs that parses python 
code for import statements. We've already a review request:
https://bugzilla.redhat.com/show_bug.cgi?id=1665749

Although, I doubt in general that any automagic with dependency generators 
brings a huge benefit in the long run. In case of python projects, I see 
sometimes conditional dependencies that enable optional features by awareness 
of any existance of a library, e.g. SecretStorage that parses for alternative 
desktops and optional password storage. Further, mostly there are up to 5 
dependencies to note but sometimes 2 to ignore anyways.

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

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

[smooge]

Dear all,

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

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting. Agenda is in the 
https://infinote.fedoraproject.org/cgit/infinote/tree/epel-meeting-next 


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

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

Re: Using docs related fields in Bugzilla

[Kevin Fenzi]

On 2/19/19 2:49 AM, Ankur Sinha wrote:
> Hello,
> 
> While going through the NeuroFedora package reviews, I was wondering if
> it were OK for us to use the documentation related fields in Bugzilla to
> mark that we need to update our documentation at
> https://neuro.fedoraproject.org. Is it OK if we:
> 
> - set a docs contact
> - set doc type
> - set doc text?

yes, I think so. We don't use or sync that information in Fedora
components, so it should be fine.

If you run into issues, let us know.

kevin




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

Re: two Ceph updates for f28, f29, stuck in pending testing for six days

[Kevin Fenzi]

On 2/18/19 3:05 PM, Ken Dreyer wrote:
> On Mon, Feb 18, 2019 at 2:48 PM Kevin Fenzi  wrote:
>>
>> On 2/18/19 12:56 PM, Kaleb Keithley wrote:
>>> https://bodhi.fedoraproject.org/updates/FEDORA-2019-1c53f1a6c8
>>> https://bodhi.fedoraproject.org/updates/FEDORA-2019-6a2e72916a
>>>
>>> Would someone please give them a kick?
>>
>> For some reason autosign likes to not process these correctly.
> 
> Is there any error message from Sigul or somewhere else?

Sadly, not that I can find. ;(

kevin




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

Re: Ditch RPM in favor of DPKG

[Neal Gompa]

On Tue, Feb 19, 2019 at 12:16 PM Sérgio Basto  wrote:
>
> On Tue, 2019-02-19 at 08:21 -0500, Neal Gompa wrote:
> > On Tue, Feb 19, 2019 at 7:40 AM Sérgio Basto 
> > wrote:
> > >
> > > On Tue, 2019-02-19 at 11:03 +0100, Dridi Boukelmoune wrote:
> > > > Greetings packagers,
> > > >
> > > > I know how important RPM is to the Fedora Project, but it breaks
> > > > everything downstream and we'd be better off using DPKG as we
> > > > should
> > > > have from day one.
> > > >
> > > > I'm calling this initiative fedpkg: Fedora Embraces DPKG.
> > > >
> > > > A bit of background here: I build both RPMs and DEBs for $DAYJOB
> > > > and
> > > > until recently my workflow was quite painful because I needed
> > > > extra
> > > > steps
> > > > between git checkout and git push that involves a VM, because
> > > > what we
> > > > ship as apt is in reality apt-rpm.
> > > >
> > > > It finally got enough on my nerves to locally build the things I
> > > > needed and
> > > > after a month I have already amortized my efforts with the time I
> > > > save not
> > > > having to deal with needless extra hoops.
> > > >
> > > > In order to successfully build debs on Fedora I needed 4 packages
> > > > that
> > > > I'm now submitting for review:
> > > >
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=sbuild
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=apt
> > > >
> > > > I need more than reviews here.
> > > >
> > > > Three of those packages are heavy on Perl code, and I'm not a
> > > > Perl
> > > > Monk. I tried to CC perl-sig as per the guidelines [1] (also
> > > > tried
> > > > with
> > > > the mailing list address) but bugzilla replied kindly:
> > > >
> > > > CC: perl-sig did not match anything
> > > >
> > > > Apt is a mix of C, Perl and C++ code, so I would be reassured if
> > > > I
> > > > could have a C++ co-maintainer too. I'm only a C developer so if
> > > > something goes wrong outside of the C realm that would be
> > > > helpful.
> > > >
> > > > Two of those packages should be runtime dependencies of
> > > > debhelper.
> > > >
> > > > The current apt package should be renamed to apt-rpm, I will look
> > > > up
> > > > the procedure for that to happen. I understand that when someone
> > > > sees
> > > > they should run "apt-get install foo" somewhere on the web it's
> > > > helpful for non-savvy users that this JustWorks(tm) [2], but apt-
> > > > rpm
> > > > is
> > > > dead upstream and it shouldn't be advertised as apt.
> > > >
> > > > I hope I CC'd everyone that should get this heads up, and hope to
> > > > find
> > > > help for the reviews and co-maintainership. The packaging does
> > > > nothing
> > > > fancy, there are quirks here and there but overall it was rather
> > > > easy
> > > > to put together. And of course I would be happy to help with
> > > > reviews
> > > > too in exchange.
> > > >
> > > > And thanks again to the mock developers, its design is so much
> > > > better
> > > > than either sbuild or pdebuild that I barely have pain points
> > > > left
> > > > when it
> > > > comes to RPM packaging.
> > > >
> > > > Thanks,
> > > > Dridi
> > > >
> > > > [1]
> > > >
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_perl_sig
> > > > [2] I'm not against apt-rpm in the base install for example
> > >
> > >
> > > TLDR ,  apt-rpm should be retired because nobody use it since more
> > > than
> > > 10 years .
> > >
> >
> > Unfortunately, I *do* use it occasionally when working on Linux
> > distros that use apt-rpm, as only apt-rpm can process their repo
> > metadata. There are still a few out there that use it. That said,
> > Fedora's apt config package should probably be retired.
>
>
> Out of curiosity , what distro ? they have any update ? i.e. [1] last
> version is dated on 12-Jan-2008 ... seems a little old to me , anddon't see 
> any update ...
>

ALT Linux and PCLinuxOS are two that use apt-rpm.

There's _slightly_ more life (but not much) in the Git repo for
apt-rpm: https://gitlab.com/apt-rpm/apt-rpm


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

Re: Ditch RPM in favor of DPKG

[Sérgio Basto]

On Tue, 2019-02-19 at 08:21 -0500, Neal Gompa wrote:
> On Tue, Feb 19, 2019 at 7:40 AM Sérgio Basto 
> wrote:
> > 
> > On Tue, 2019-02-19 at 11:03 +0100, Dridi Boukelmoune wrote:
> > > Greetings packagers,
> > > 
> > > I know how important RPM is to the Fedora Project, but it breaks
> > > everything downstream and we'd be better off using DPKG as we
> > > should
> > > have from day one.
> > > 
> > > I'm calling this initiative fedpkg: Fedora Embraces DPKG.
> > > 
> > > A bit of background here: I build both RPMs and DEBs for $DAYJOB
> > > and
> > > until recently my workflow was quite painful because I needed
> > > extra
> > > steps
> > > between git checkout and git push that involves a VM, because
> > > what we
> > > ship as apt is in reality apt-rpm.
> > > 
> > > It finally got enough on my nerves to locally build the things I
> > > needed and
> > > after a month I have already amortized my efforts with the time I
> > > save not
> > > having to deal with needless extra hoops.
> > > 
> > > In order to successfully build debs on Fedora I needed 4 packages
> > > that
> > > I'm now submitting for review:
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config
> > > https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism
> > > https://bugzilla.redhat.com/show_bug.cgi?id=sbuild
> > > https://bugzilla.redhat.com/show_bug.cgi?id=apt
> > > 
> > > I need more than reviews here.
> > > 
> > > Three of those packages are heavy on Perl code, and I'm not a
> > > Perl
> > > Monk. I tried to CC perl-sig as per the guidelines [1] (also
> > > tried
> > > with
> > > the mailing list address) but bugzilla replied kindly:
> > > 
> > > CC: perl-sig did not match anything
> > > 
> > > Apt is a mix of C, Perl and C++ code, so I would be reassured if
> > > I
> > > could have a C++ co-maintainer too. I'm only a C developer so if
> > > something goes wrong outside of the C realm that would be
> > > helpful.
> > > 
> > > Two of those packages should be runtime dependencies of
> > > debhelper.
> > > 
> > > The current apt package should be renamed to apt-rpm, I will look
> > > up
> > > the procedure for that to happen. I understand that when someone
> > > sees
> > > they should run "apt-get install foo" somewhere on the web it's
> > > helpful for non-savvy users that this JustWorks(tm) [2], but apt-
> > > rpm
> > > is
> > > dead upstream and it shouldn't be advertised as apt.
> > > 
> > > I hope I CC'd everyone that should get this heads up, and hope to
> > > find
> > > help for the reviews and co-maintainership. The packaging does
> > > nothing
> > > fancy, there are quirks here and there but overall it was rather
> > > easy
> > > to put together. And of course I would be happy to help with
> > > reviews
> > > too in exchange.
> > > 
> > > And thanks again to the mock developers, its design is so much
> > > better
> > > than either sbuild or pdebuild that I barely have pain points
> > > left
> > > when it
> > > comes to RPM packaging.
> > > 
> > > Thanks,
> > > Dridi
> > > 
> > > [1]
> > > 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_perl_sig
> > > [2] I'm not against apt-rpm in the base install for example
> > 
> > 
> > TLDR ,  apt-rpm should be retired because nobody use it since more
> > than
> > 10 years .
> > 
> 
> Unfortunately, I *do* use it occasionally when working on Linux
> distros that use apt-rpm, as only apt-rpm can process their repo
> metadata. There are still a few out there that use it. That said,
> Fedora's apt config package should probably be retired.


Out of curiosity , what distro ? they have any update ? i.e. [1] last
version is dated on 12-Jan-2008 ... seems a little old to me , anddon't see any 
update ... 


[1]
https://src.fedoraproject.org/rpms/apt/blob/master/f/apt.spec
http://apt-rpm.org/testing/

> --
> 真実はいつも一つ！/ Always, there's only one truth!
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

PSA: Bodhi cannot associate bugs with updates right now

[Randy Barlow]

Hello fellow Fedora people!

I'm sorry to say, but Bodhi has a problem associating bugs with updates
right now:

https://github.com/fedora-infra/bodhi/issues/3024

For the moment, you should be able to create updates if you avoid
adding bugs to them. I am working on a fix, and I apologize for the
inconvenience.


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

Re: F31 System-Wide Change proposal: Automatic strict inter-package dependencies

[Igor Gnatenko]

On Tue, Feb 19, 2019 at 4:26 PM Petr Pisar  wrote:

> On 2019-02-18, Ben Cotton  wrote:
> > Let's take graphene as an example.
> >
> > Spec file contains:
> >
> > %package devel
> > Requires: %{name}%{?_isa} = %{version}-%{release}
> > %package tests
> > Requires: %{name}%{?_isa} = %{version}-%{release}
> >
> >
> > What we see when we build RPMs is:
> > * graphene-devel requires graphene(x86-64) =
> > 1.8.2-3.fc30 AND libgraphene-1.0.so.0()(64bit) AND
> >pkgconfig(graphene-1.0)
> > * graphene-tests requires graphene(x86-64) =
> > 1.8.2-3.fc30 AND libgraphene-1.0.so.0()(64bit)
> >
> > What can we do?
> > * Requires: libgraphene-1.0.so.0()(64bit) is actually
> > provided by graphene (coming from same package), so it
> > can be dropped in favor of Requires: graphene(x86-64) =
> > 1.8.2-3.fc30
> > * Requires: pkgconfig(graphene-1.0) is provided by
> >graphene-devel (coming from the same subpackage), so it
> > can be dropped entirely
> >
> Is this feature resticted to the dynamic library soname dependencies, or
> will it be a general replacement for subpackage interdependencies with
> exact NEVRAs? Will this feature also apply to boolean dependencies?
>

It should be general replacement for subpackage interdependencies with
exact NEVRAs. Yes, it should (though I don't know how to implement it yet).


> I have a few packages that use "virtual provides" provided by multiple
> subpackages to allow users to select an implementation that best fits
> his needs. See perl-Archive-Extract for an example.
>
> How would you cope with this use case?
>
> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F31 System-Wide Change proposal: Automatic strict inter-package dependencies

[Petr Pisar]

On 2019-02-18, Ben Cotton  wrote:
> Let's take graphene as an example.
>
> Spec file contains:
>
> %package devel
> Requires: %{name}%{?_isa} = %{version}-%{release}
> %package tests
> Requires: %{name}%{?_isa} = %{version}-%{release}
>
>
> What we see when we build RPMs is:
> * graphene-devel requires graphene(x86-64) =
> 1.8.2-3.fc30 AND libgraphene-1.0.so.0()(64bit) AND
>pkgconfig(graphene-1.0)
> * graphene-tests requires graphene(x86-64) =
> 1.8.2-3.fc30 AND libgraphene-1.0.so.0()(64bit)
>
> What can we do?
> * Requires: libgraphene-1.0.so.0()(64bit) is actually
> provided by graphene (coming from same package), so it
> can be dropped in favor of Requires: graphene(x86-64) =
> 1.8.2-3.fc30
> * Requires: pkgconfig(graphene-1.0) is provided by
>graphene-devel (coming from the same subpackage), so it
> can be dropped entirely
>
Is this feature resticted to the dynamic library soname dependencies, or
will it be a general replacement for subpackage interdependencies with
exact NEVRAs? Will this feature also apply to boolean dependencies?

I have a few packages that use "virtual provides" provided by multiple
subpackages to allow users to select an implementation that best fits
his needs. See perl-Archive-Extract for an example.

How would you cope with this use case?

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

Re: Fedora 30 Mass Branching Starting Today

[Mohan Boddu]

On Tue, Feb 19, 2019 at 8:26 AM Mohan Boddu  wrote:

> Hello All,
>
> Fedora 30 will be branched from rawhide today as per the Fedora 30
> schedule[1]. The process takes about a day and everything should be ready
> by tomorrow. You can still be able to build packages normally until then,
> but after the mass branching rawhide and F31 will be separated.
>
Correction, "rawhide and F30 will be separated"

>
> We will send another email once the branching is done.
>
> Thanks,
> Fedora Release Engineering.
>
> [1] https://fedoraproject.org/wiki/Releases/30/Schedule
>
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 30 Mass Branching Starting Today

[Mohan Boddu]

Hello All,

Fedora 30 will be branched from rawhide today as per the Fedora 30
schedule[1]. The process takes about a day and everything should be ready
by tomorrow. You can still be able to build packages normally until then,
but after the mass branching rawhide and F31 will be separated.

We will send another email once the branching is done.

Thanks,
Fedora Release Engineering.

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

pypy

[Antonette Caldwell]

Hi all

I commented on https://bugzilla.redhat.com/show_bug.cgi?id=1673127 that I will 
be working on building pypy. So far, I was able to build pypy and pypy3 on 
rawhide, but this is my first time creating the package. I copied the spec from 
both of the rpms/pypy packages[1], but I wanted to know if I will have to 
create new spec, since I can see there are changes between the 6.0.0 and 7.0.0 
versions.

Here's what I have done so far from building pypy on rawhide

pypy
A build of pypy (with jit) on x86_64
[Timer] Timings:
[Timer] annotate   ---  990.8 s
[Timer] rtype_lltype   --- 1797.3 s
[Timer] pyjitpl_lltype --- 2112.1 s
[Timer] backendopt_lltype  ---  400.0 s
[Timer] stackcheckinsertion_lltype ---  995.6 s
[Timer] database_c ---  907.0 s
[Timer] source_c   ---  413.2 s
[Timer] compile_c  --- 1274.7 s
[Timer] build_cffi_imports ---   16.7 s
[Timer] ===
[Timer] Total: --- 8907.5 s

A build of pypy without jit on x86_64
[Timer] Timings:
[Timer] annotate   --- 1233.1 s
[Timer] rtype_lltype   --- 1554.2 s
[Timer] backendopt_lltype  ---  407.9 s
[Timer] stackcheckinsertion_lltype ---  147.9 s
[Timer] database_c ---  698.6 s
[Timer] source_c   ---  304.9 s
[Timer] compile_c  ---  700.5 s
[Timer] build_cffi_imports ---   10.2 s
[Timer] ===
[Timer] Total:

pypy3
A build of pypy with jit on x86_64

[translation:info] usession directory: /tmp/usession-py3.5-0
[Timer] Timings:
[Timer] annotate   ---  260.5 s
[Timer] rtype_lltype   ---  342.1 s
[Timer] pyjitpl_lltype ---  560.0 s
[Timer] backendopt_lltype  ---  106.2 s
[Timer] stackcheckinsertion_lltype ---   53.4 s
[Timer] database_c ---  232.3 s
[Timer] source_c   ---  101.7 s
[Timer] compile_c  ---  547.3 s
[Timer] build_cffi_imports ---   17.9 s
[Timer] ===
[Timer] Total: --- 2221.5 s

Please let me know if I need to include devel in this email as well, since I am 
new and I have no built an rpm package, so I will not be able to push the new 
package once it is done.

[1] https://src.fedoraproject.org/rpms/pypy/blob/master/f/pypy.spec

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

Fedora 30 Mass Branching Starting Today

[Mohan Boddu]

Hello All,

Fedora 30 will be branched from rawhide today as per the Fedora 30
schedule[1]. The process takes about a day and everything should be ready
by tomorrow. You can still be able to build packages normally until then,
but after the mass branching rawhide and F31 will be separated.

We will send another email once the branching is done.

Thanks,
Fedora Release Engineering.

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

[Bug 1673655] perl-MongoDB-2.0.3 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-MongoDB-2.0.3-1.fc30   |perl-MongoDB-2.0.3-1.fc30
   ||perl-MongoDB-2.0.3-1.fc29
 Resolution|--- |ERRATA
Last Closed||2019-02-19 14:02:20



--- Comment #4 from Fedora Update System  ---
perl-MongoDB-2.0.3-1.fc29 has been pushed to the Fedora 29 stable repository.
If problems still persist, please make note of it in this bug report.

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

[Bug 1673009] perl-File-BOM-0.16 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-File-BOM-0.16-1.fc30   |perl-File-BOM-0.16-1.fc30
   ||perl-File-BOM-0.16-1.fc29
 Resolution|--- |ERRATA
Last Closed||2019-02-19 14:01:15



--- Comment #3 from Fedora Update System  ---
perl-File-BOM-0.16-1.fc29 has been pushed to the Fedora 29 stable repository.
If problems still persist, please make note of it in this bug report.

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

Re: RFE: fedpkgdiff?

[Richard Shaw]

Out of curiosity I took a look at abipkgdiff that's provided by the
libabigail package and it's a python wrapper around abipkgdiff. I'm a
little rusty on Python but I could probably use that as a very nice
starting point...

The next question is what package would the wrapper go in? I think the
natural place is fedora-packager.

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

Re: Ditch RPM in favor of DPKG

[Neal Gompa]

On Tue, Feb 19, 2019 at 7:40 AM Sérgio Basto  wrote:
>
> On Tue, 2019-02-19 at 11:03 +0100, Dridi Boukelmoune wrote:
> > Greetings packagers,
> >
> > I know how important RPM is to the Fedora Project, but it breaks
> > everything downstream and we'd be better off using DPKG as we should
> > have from day one.
> >
> > I'm calling this initiative fedpkg: Fedora Embraces DPKG.
> >
> > A bit of background here: I build both RPMs and DEBs for $DAYJOB and
> > until recently my workflow was quite painful because I needed extra
> > steps
> > between git checkout and git push that involves a VM, because what we
> > ship as apt is in reality apt-rpm.
> >
> > It finally got enough on my nerves to locally build the things I
> > needed and
> > after a month I have already amortized my efforts with the time I
> > save not
> > having to deal with needless extra hoops.
> >
> > In order to successfully build debs on Fedora I needed 4 packages
> > that
> > I'm now submitting for review:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config
> > https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism
> > https://bugzilla.redhat.com/show_bug.cgi?id=sbuild
> > https://bugzilla.redhat.com/show_bug.cgi?id=apt
> >
> > I need more than reviews here.
> >
> > Three of those packages are heavy on Perl code, and I'm not a Perl
> > Monk. I tried to CC perl-sig as per the guidelines [1] (also tried
> > with
> > the mailing list address) but bugzilla replied kindly:
> >
> > CC: perl-sig did not match anything
> >
> > Apt is a mix of C, Perl and C++ code, so I would be reassured if I
> > could have a C++ co-maintainer too. I'm only a C developer so if
> > something goes wrong outside of the C realm that would be helpful.
> >
> > Two of those packages should be runtime dependencies of debhelper.
> >
> > The current apt package should be renamed to apt-rpm, I will look up
> > the procedure for that to happen. I understand that when someone sees
> > they should run "apt-get install foo" somewhere on the web it's
> > helpful for non-savvy users that this JustWorks(tm) [2], but apt-rpm
> > is
> > dead upstream and it shouldn't be advertised as apt.
> >
> > I hope I CC'd everyone that should get this heads up, and hope to
> > find
> > help for the reviews and co-maintainership. The packaging does
> > nothing
> > fancy, there are quirks here and there but overall it was rather easy
> > to put together. And of course I would be happy to help with reviews
> > too in exchange.
> >
> > And thanks again to the mock developers, its design is so much better
> > than either sbuild or pdebuild that I barely have pain points left
> > when it
> > comes to RPM packaging.
> >
> > Thanks,
> > Dridi
> >
> > [1]
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_perl_sig
> > [2] I'm not against apt-rpm in the base install for example
>
>
> TLDR ,  apt-rpm should be retired because nobody use it since more than
> 10 years .
>

Unfortunately, I *do* use it occasionally when working on Linux
distros that use apt-rpm, as only apt-rpm can process their repo
metadata. There are still a few out there that use it. That said,
Fedora's apt config package should probably be retired.



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

Re: Ditch RPM in favor of DPKG

[Sérgio Basto]

On Tue, 2019-02-19 at 11:03 +0100, Dridi Boukelmoune wrote:
> Greetings packagers,
> 
> I know how important RPM is to the Fedora Project, but it breaks
> everything downstream and we'd be better off using DPKG as we should
> have from day one.
> 
> I'm calling this initiative fedpkg: Fedora Embraces DPKG.
> 
> A bit of background here: I build both RPMs and DEBs for $DAYJOB and
> until recently my workflow was quite painful because I needed extra
> steps
> between git checkout and git push that involves a VM, because what we
> ship as apt is in reality apt-rpm.
> 
> It finally got enough on my nerves to locally build the things I
> needed and
> after a month I have already amortized my efforts with the time I
> save not
> having to deal with needless extra hoops.
> 
> In order to successfully build debs on Fedora I needed 4 packages
> that
> I'm now submitting for review:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config
> https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism
> https://bugzilla.redhat.com/show_bug.cgi?id=sbuild
> https://bugzilla.redhat.com/show_bug.cgi?id=apt
> 
> I need more than reviews here.
> 
> Three of those packages are heavy on Perl code, and I'm not a Perl
> Monk. I tried to CC perl-sig as per the guidelines [1] (also tried
> with
> the mailing list address) but bugzilla replied kindly:
> 
> CC: perl-sig did not match anything
> 
> Apt is a mix of C, Perl and C++ code, so I would be reassured if I
> could have a C++ co-maintainer too. I'm only a C developer so if
> something goes wrong outside of the C realm that would be helpful.
> 
> Two of those packages should be runtime dependencies of debhelper.
> 
> The current apt package should be renamed to apt-rpm, I will look up
> the procedure for that to happen. I understand that when someone sees
> they should run "apt-get install foo" somewhere on the web it's
> helpful for non-savvy users that this JustWorks(tm) [2], but apt-rpm
> is
> dead upstream and it shouldn't be advertised as apt.
> 
> I hope I CC'd everyone that should get this heads up, and hope to
> find
> help for the reviews and co-maintainership. The packaging does
> nothing
> fancy, there are quirks here and there but overall it was rather easy
> to put together. And of course I would be happy to help with reviews
> too in exchange.
> 
> And thanks again to the mock developers, its design is so much better
> than either sbuild or pdebuild that I barely have pain points left
> when it
> comes to RPM packaging.
> 
> Thanks,
> Dridi
> 
> [1] 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_perl_sig
> [2] I'm not against apt-rpm in the base install for example


TLDR ,  apt-rpm should be retired because nobody use it since more than
10 years .

I maintain a lot of debian package in Fedora but apt-debian still not
on Official repos you can get it from my devel corp repo [1]
My goal is make a system where rpm produce deb files , to allow Debian
migrate from deb to rpm . 
rpm is much more powerful than Debian IMHO .

[1]
https://copr.fedorainfracloud.org/coprs/sergiomb/debs/monitor/


I can build .deb packages in Fedora and download packages with apt-
debian :

debuild -i -us -uc -b -d
from 
https://wiki.archlinux.org/index.php/Creating_packages_for_other_distributions#Tips_and_tricks_2

You may also need to override dh_shlibdeps by adding the following
lines to debian/rules:

override_dh_shlibdeps:

   dh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info

and
override_dh_strip_nondeterminism:


From [1] "I'd like propose retire this apt and fedora-package-config-
apt".
 
[1] 
https://bugzilla.redhat.com/show_bug.cgi?id=1462485

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

Re: Ditch RPM in favor of DPKG

[Neal Gompa]

On Tue, Feb 19, 2019 at 7:06 AM Leigh Scott  wrote:
>
> > Greetings packagers,
> >
> > I know how important RPM is to the Fedora Project, but it breaks
> > everything downstream and we'd be better off using DPKG as we should
> > have from day one.
> >
> > I'm calling this initiative fedpkg: Fedora Embraces DPKG.
> >
> > A bit of background here: I build both RPMs and DEBs for $DAYJOB and
> > until recently my workflow was quite painful because I needed extra steps
> > between git checkout and git push that involves a VM, because what we
> > ship as apt is in reality apt-rpm.
>
> Perhaps you could post a request to Debian devel-list to switch to RPM ;-)

I know this is a joke, but I'm going to answer this seriously anyway,
because it's an interesting exercise. :)

Well, one of the two package managers for Debian already supports RPM:
smart. Gustavo Niemeyer wrote smart to support multiple low level
package managers after dealing with the frustration of apt back then,
and it still retains that facility today. Smart[1] still works and is
present in Debian and Ubuntu.

The other, apt, needs someone to contribute the rpm backend. The basic
scaffolding was added a little over a decade ago (ironically, after
Gustavo gave up and started developing smart), and most of the
rpm-specific concepts (like Obsoletes dep clause) are supported in
Debian apt but are completely unused. The librpm code in apt-rpm is
mostly in its own sources, but it would need some rejiggering to plug
into the current apt, as the internal APIs have been shuffled around a
bit. The apt-rpm upstream maintainer is still around on this mailing
list, and could probably help with this if someone expressed interest
in trying to do this. :)

Another bit would be a way for debhelper to emit a correctly formed
spec file to pass to rpmbuild, or an application built on top of
librpmbuild and librpmsign to allow a custom frontend for building
RPMs. Alternatively, if they wanted to drop dh automagic, then
debbuild[0] can be used as a means of supporting building debs using
the RPM spec file format, giving a path to transition in that manner
too. Given Debian's culture, I would expect that a rpm building
frontend would need to be built rather than getting people to
transition to spec files.

Most likely, they'd want a way for rpm to accept debs and process
them. This in itself would probably not be difficult, since it's just
another archive format. In fact, there was a variant of rpm that could
do this, so it's not impossible. Once they have that, then it's just a
matter of churning things over, supporting both archive formats
indefinitely, or even working to develop a new unified format to
address pain points of both.

Alternatively, a plugin for rpm and a hook for dpkg could be written
so that the two package managers know what each are doing. The rpmdb
information would be exported to /var/lib/dpkg/status, and dpkg
actions would be written into the rpmdb with a key to indicate it was
from dpkg. That would give them a path to wind down usage of dpkg/deb
and switch things over to rpm. My understanding is that this has
actually been done before for supporting migrations both ways by
various people, but the code for those things was never released.

So if someone wanted to actually seriously propose this in Debian, it
*could* be done. But a strategy for the tooling needs to be addressed
first. I provided a couple of ideas of how someone could do it if they
wanted to.

The assumption, of course, is that Debian would want to preserve the
average user experience, which means not switching away from apt as
their primary package manager interface (even if I think DNF is
light-years ahead of it!).

[0]: https://github.com/ascherer/debbuild
[1]: http://smartpm.github.io/smart/

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

Re: Ditch RPM in favor of DPKG

[Leigh Scott]

> Greetings packagers,
> 
> I know how important RPM is to the Fedora Project, but it breaks
> everything downstream and we'd be better off using DPKG as we should
> have from day one.
> 
> I'm calling this initiative fedpkg: Fedora Embraces DPKG.
> 
> A bit of background here: I build both RPMs and DEBs for $DAYJOB and
> until recently my workflow was quite painful because I needed extra steps
> between git checkout and git push that involves a VM, because what we
> ship as apt is in reality apt-rpm.

Perhaps you could post a request to Debian devel-list to switch to RPM ;-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: doxygen crash on aarch64

[Ankur Sinha]

On Tue, Feb 19, 2019 11:51:25 +, Ankur Sinha wrote:
> On Tue, Feb 19, 2019 11:38:15 +, Peter Robinson wrote:
> > Hi,
> > 
> > > For one of my packages, doxygen is crashing on aarch64 (and not on any
> > > other arch). Any ideas/tips on how to fix this?
> > 
> > Is the package name secret? More details are always good here. There's
> > generally no issues with doxygen in general on aarch64.
> 
> No, it isn't "secret", it's "auryn" ;)

Here is the spec too if you'd like to have a look.  I have temporarily
disabled dev doc generation with doxygen with a conditional:

https://src.fedoraproject.org/rpms/auryn/blob/master/f/auryn.spec#_11

Doxygen is used later in the spec here:
https://src.fedoraproject.org/rpms/auryn/blob/master/f/auryn.spec#_162

-- 
Thanks,
Regards,

Ankur Sinha "FranciscoD"
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: doxygen crash on aarch64

[Ankur Sinha]

On Tue, Feb 19, 2019 11:38:15 +, Peter Robinson wrote:
> Hi,
> 
> > For one of my packages, doxygen is crashing on aarch64 (and not on any
> > other arch). Any ideas/tips on how to fix this?
> 
> Is the package name secret? More details are always good here. There's
> generally no issues with doxygen in general on aarch64.

No, it isn't "secret", it's "auryn" ;)


> > ...
> > Patching output file 570/631
> > BUILDSTDERR: Patching output file 57malloc_consolidate(): invalid chunk size
> > BUILDSTDERR: /var/tmp/rpm-tmp.YZzKpD: line 38:  6804 Aborted
> >  (core dumped) doxygen Doxyfile
> > RPM build errors:
> > BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.YZzKpD (%build)
> >
> > Complete build log for scratch build:
> > https://kojipkgs.fedoraproject.org//work/tasks/3971/32903971/build.log
> 
> Please always provide the root task not just a link to the logs,
> there's lots of things that someone might want to check and from here
> there's no link to get back to tasks so you're not making it easy for
> people to assist.

Sure, here you go:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32903971

It's only a scratch build though so it won't be around forever.

-- 
Thanks,
Regards,

Ankur Sinha "FranciscoD"
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1678623] Review Request: strip-nondeterminism - File non-deterministic information stripper

[bugzilla]

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

Neal Gompa  changed:

   What|Removed |Added

 CC||ngomp...@gmail.com
   Assignee|nob...@fedoraproject.org|ngomp...@gmail.com
  Flags||fedora-review?



--- Comment #1 from Neal Gompa  ---
Taking this review.

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

[Bug 1678632] Review Request: apt - Main commandline package manager for Debian and its derivatives

[bugzilla]

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

Neal Gompa  changed:

   What|Removed |Added

   Assignee|nob...@fedoraproject.org|ngomp...@gmail.com
  Flags||fedora-review?



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

[Bug 1678626] Review Request: sbuild - Tool for building Debian binary packages from Debian sources

[bugzilla]

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

Neal Gompa  changed:

   What|Removed |Added

 CC||ngomp...@gmail.com
   Assignee|nob...@fedoraproject.org|ngomp...@gmail.com
  Flags||fedora-review?



--- Comment #1 from Neal Gompa  ---
Taking this review.

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

[Bug 1678632] Review Request: apt - Main commandline package manager for Debian and its derivatives

[bugzilla]

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



--- Comment #1 from Neal Gompa  ---
Taking this review.

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

[Bug 1678632] Review Request: apt - Main commandline package manager for Debian and its derivatives

[bugzilla]

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

Neal Gompa  changed:

   What|Removed |Added

 CC||ngomp...@gmail.com
  Alias|apt |apt-dpkg



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

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Jens-Ulrik Petersen]

On Fri, Feb 15, 2019 at 11:30 PM Vít Ondruch  wrote:

> As long as we have no idea if the other maintainers are active, I am
> strongly against the automation. I've been there. Followed nor
> responsive policy just to find out later that instead of orphaning the
> package, next inactive maintainer became owner. Very frustrating 


I think it may depend on the type of package, for some SIGs at least I
think auto-retiring a needed working package is also rather frustrating
since it generates extra work for the SIG to recover that package.

Talking of which I just filed two review requests for ghc-fgl (which I had
untired last year) and ghc-setlocale:

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

which will unbreak xmonad and darcs. :-)

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

Re: doxygen crash on aarch64

[Peter Robinson]

Hi,

> For one of my packages, doxygen is crashing on aarch64 (and not on any
> other arch). Any ideas/tips on how to fix this?

Is the package name secret? More details are always good here. There's
generally no issues with doxygen in general on aarch64.

> ...
> Patching output file 570/631
> BUILDSTDERR: Patching output file 57malloc_consolidate(): invalid chunk size
> BUILDSTDERR: /var/tmp/rpm-tmp.YZzKpD: line 38:  6804 Aborted 
> (core dumped) doxygen Doxyfile
> RPM build errors:
> BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.YZzKpD (%build)
>
> Complete build log for scratch build:
> https://kojipkgs.fedoraproject.org//work/tasks/3971/32903971/build.log

Please always provide the root task not just a link to the logs,
there's lots of things that someone might want to check and from here
there's no link to get back to tasks so you're not making it easy for
people to assist.

> A related somewhat random query: since the -doc subpackage is noarch, is
> it OK to use %ifarch in the spec to only generate the docs on one arch
> and thus save resources on others?

Generally not, but that's one for someone that knows more about the
packaging guidelines.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ditch RPM in favor of DPKG

[Dridi Boukelmoune]

On Tue, Feb 19, 2019 at 11:20 AM Emmanuel Seyman  wrote:
>
> * Dridi Boukelmoune [19/02/2019 11:03] :
> >
> > Three of those packages are heavy on Perl code, and I'm not a Perl
> > Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with
> > the mailing list address) but bugzilla replied kindly:
> >
> > CC: perl-sig did not match anything
>
> The Perl SIG's mailing list address is perl-devel@lists.fedoraproject.org .
> This is a valid account in Bugzilla and should work.

Right, I tried perl-...@lists.fedoraproject.org when perl-sig didn't work.

It's CC'd now, thanks.

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

Re: Ditch RPM in favor of DPKG

[Neal Gompa]

On Tue, Feb 19, 2019 at 5:05 AM Dridi Boukelmoune
 wrote:
>
> Greetings packagers,
>
> I know how important RPM is to the Fedora Project, but it breaks
> everything downstream and we'd be better off using DPKG as we should
> have from day one.
>
> I'm calling this initiative fedpkg: Fedora Embraces DPKG.
>
> A bit of background here: I build both RPMs and DEBs for $DAYJOB and
> until recently my workflow was quite painful because I needed extra steps
> between git checkout and git push that involves a VM, because what we
> ship as apt is in reality apt-rpm.
>
> It finally got enough on my nerves to locally build the things I needed and
> after a month I have already amortized my efforts with the time I save not
> having to deal with needless extra hoops.
>
> In order to successfully build debs on Fedora I needed 4 packages that
> I'm now submitting for review:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config
> https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism
> https://bugzilla.redhat.com/show_bug.cgi?id=sbuild
> https://bugzilla.redhat.com/show_bug.cgi?id=apt
>
> I need more than reviews here.
>
> Three of those packages are heavy on Perl code, and I'm not a Perl
> Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with
> the mailing list address) but bugzilla replied kindly:
>
> CC: perl-sig did not match anything
>
> Apt is a mix of C, Perl and C++ code, so I would be reassured if I
> could have a C++ co-maintainer too. I'm only a C developer so if
> something goes wrong outside of the C realm that would be helpful.
>
> Two of those packages should be runtime dependencies of debhelper.
>
> The current apt package should be renamed to apt-rpm, I will look up
> the procedure for that to happen. I understand that when someone sees
> they should run "apt-get install foo" somewhere on the web it's
> helpful for non-savvy users that this JustWorks(tm) [2], but apt-rpm is
> dead upstream and it shouldn't be advertised as apt.
>
> I hope I CC'd everyone that should get this heads up, and hope to find
> help for the reviews and co-maintainership. The packaging does nothing
> fancy, there are quirks here and there but overall it was rather easy
> to put together. And of course I would be happy to help with reviews
> too in exchange.
>
> And thanks again to the mock developers, its design is so much better
> than either sbuild or pdebuild that I barely have pain points left when it
> comes to RPM packaging.
>

For what it's worth, this was a terrible lede for this email. And
having worked extensively with both package managers, I can sincerely
tell you both are ugly as hell, but rpm is less ugly than dpkg.
Thankfully, I don't need to go into the reasons why, because this is
not actually about switching to dpkg and its completely terrible
system.

If all you wanted was the rest of the tooling in so you can build
Debian packages in Fedora, that's really not a problem. I made an
apt-dpkg package a while ago and worked with APT upstream to make it
build and have the tests work (mostly) on Fedora a couple of years
ago. I imported it into COPR so you can see it:
https://copr.fedorainfracloud.org/coprs/ngompa/apt-dpkg/build/860086/

Instead of renaming the apt package to apt-rpm, we can introduce the
apt-dpkg package that conflicts with apt for your purposes.

I wish we could have the rpm backend integrated into the Debian
upstream apt, but someone needs to drive that effort, and no one
really cares anymore. It hasn't happened in the past due to
frustrations with working with Debian upstream, and now it's diverged
so much that they are separate upstreams. My understanding is that the
current upstream developers are interested in an rpm backend, but they
don't want to do any effort to make it happen.

Also, you can build debs using RPM spec files[1], if you're aware
enough to handle the differences. :)

[1]: https://github.com/ascherer/debbuild



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

Re: F31 System-Wide Change proposal: BuildRequires Generators

[Neal Gompa]

On Mon, Feb 18, 2019 at 4:36 PM Dridi Boukelmoune
 wrote:
>
> On Mon, Feb 18, 2019 at 9:21 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/BuildRequires_Generators
> >
> > = BuildRequires Generators =
> >
> > == Summary ==
> > Add possibility to generate build-time dependencies within RPM spec
> > file and teach RPM and mock how to handle this.
> >
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:ffesti|Florian
> > Festi]], [[User:msuchy|Miroslav Suchý]]
> > * Email: ignatenkobr...@fedoraproject.org, ffe...@redhat.com, 
> > miros...@suchy.cz
> >
> > == Detailed Description ==
> > For many languages (Rust, Golang, Node.Js, Ruby, Python),
> > BuildRequires can be automatically generated. All it takes, run some
> > special tool which will output dependencies in RPM format.
> >
> > Q: How will it work under the hood?
> > A: When you build RPM, something like this will happen under the hood…
> > # rpm would perform %prep (which is supposed to abort if some
> > dependencies missing and print them)
> > # mock would install those dependencies and resume build
>
> As of today, running %configure or %cmake is part of the %build step,
> not the %prep step according to the guidelines.
>
> Would it mean that we should move this kind of commands in the %prep
> step? I think that's technically where they belong. However, focusing
> on language stacks won't help for polyglot projects (for example when
> using gcc in a Rust project).
>

Current discussion upstream indicates we'll have a new spec section
for generating build dependencies. It'll happen between %prep and
%build, most likely.

That should not require changing the behavior of how things are done now.

> > Q: Will src.rpm contain all generated dependencies?
> > A: This is not known yet, we'll update page once it is known.
> >
> > Q: Does this mean that package builds won't be reproducible anymore?
> > A: No, as long as you have same buildroot and tool which is generating
> > BuildRequires is doing so in reproducible manner, it should not affect
> > reproducibility.
> >
> > == Benefit to Fedora ==
> >
> > Packagers won't have to pre-generate BuildRequires in the spec file
> > which means it will be always updated (and correct) :
> >
> > * Packagers can focus of making their packages better instead of
> > spending all their packaging time copying BuildRequires from
> > documentation and third party tools.
> > * BuildRequires are dropped as soon as they're no longer necessary
> > * Packages can be easily bumped without requiring a manual BuildRequires 
> > refresh
> > * BuildRequires and Requires generation can use similar utilities,
> > making sure that the deps packages declare can also be used for
> > second-level building. Packages no longer need to declare the deps of
> > their second and n-th dependencies because someone forgot to declare
> > them in the correct package.
> >
> > == Scope ==
> > * Proposal owners: Implement support for a feature in RPM and mock (if
> > implemented properly, Koji should just work). Make use of it in Rust
> > ecosystem.
> > * Other developers: Maintainers of language stacks are advised to use
> > this feature.
> > * Release engineering: [https://pagure.io/releng/issue/8129 #8129]
> > * Policies and guidelines: Packaging Guidelines need to be updated
> > with instructions how to use this feature.
> > * Trademark approval: N/A (not needed for this Change)
> >
> > == Upgrade/compatibility impact ==
> > Packagers and users who use repoquery might be affected (src.rpm might
> > not contain generated dependencies).
> >
> > == How To Test ==
> > TBD.
> >
> > == User Experience ==
> > Users won't notice differences.
>
> As a mock and RPM user on Fedora, outside of my Fedora endeavors, I
> beg to differ ;-)
>

Yeah, everyone has to update. :)



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

doxygen crash on aarch64

[Ankur Sinha]

Hello,

For one of my packages, doxygen is crashing on aarch64 (and not on any
other arch). Any ideas/tips on how to fix this?

...
Patching output file 570/631
BUILDSTDERR: Patching output file 57malloc_consolidate(): invalid chunk size
BUILDSTDERR: /var/tmp/rpm-tmp.YZzKpD: line 38:  6804 Aborted 
(core dumped) doxygen Doxyfile
RPM build errors:
BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.YZzKpD (%build)

Complete build log for scratch build:
https://kojipkgs.fedoraproject.org//work/tasks/3971/32903971/build.log

A related somewhat random query: since the -doc subpackage is noarch, is
it OK to use %ifarch in the spec to only generate the docs on one arch
and thus save resources on others?

-- 
Thanks,
Regards,

Ankur Sinha "FranciscoD"
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Using docs related fields in Bugzilla

[Ankur Sinha]

Hello,

While going through the NeuroFedora package reviews, I was wondering if
it were OK for us to use the documentation related fields in Bugzilla to
mark that we need to update our documentation at
https://neuro.fedoraproject.org. Is it OK if we:

- set a docs contact
- set doc type
- set doc text?

-- 
Thanks,
Regards,

Ankur Sinha "FranciscoD"
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ditch RPM in favor of DPKG

[Dridi Boukelmoune]

On Tue, Feb 19, 2019 at 11:20 AM Emmanuel Seyman  wrote:
>
> * Dridi Boukelmoune [19/02/2019 11:03] :
> >
> > Three of those packages are heavy on Perl code, and I'm not a Perl
> > Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with
> > the mailing list address) but bugzilla replied kindly:
> >
> > CC: perl-sig did not match anything
>
> The Perl SIG's mailing list address is perl-de...@lists.fedoraproject.org .
> This is a valid account in Bugzilla and should work.

Right, I tried perl-...@lists.fedoraproject.org when perl-sig didn't work.

It's CC'd now, thanks.

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

[Bug 1678632] Review Request: apt - Main commandline package manager for Debian and its derivatives

[bugzilla]

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

Dridi Boukelmoune  changed:

   What|Removed |Added

 CC||perl-devel@lists.fedoraproj
   ||ect.org



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

[Bug 1678626] Review Request: sbuild - Tool for building Debian binary packages from Debian sources

[bugzilla]

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

Dridi Boukelmoune  changed:

   What|Removed |Added

 CC||perl-devel@lists.fedoraproj
   ||ect.org



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

[Bug 1678623] Review Request: strip-nondeterminism - File non-deterministic information stripper

[bugzilla]

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

Dridi Boukelmoune  changed:

   What|Removed |Added

 CC||perl-devel@lists.fedoraproj
   ||ect.org



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

Re: Ditch RPM in favor of DPKG

[Emmanuel Seyman]

* Dridi Boukelmoune [19/02/2019 11:03] :
>
> Three of those packages are heavy on Perl code, and I'm not a Perl
> Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with
> the mailing list address) but bugzilla replied kindly:
> 
> CC: perl-sig did not match anything

The Perl SIG's mailing list address is perl-de...@lists.fedoraproject.org .
This is a valid account in Bugzilla and should work.

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

Re: Ditch RPM in favor of DPKG

[Emmanuel Seyman]

* Dridi Boukelmoune [19/02/2019 11:03] :
>
> Three of those packages are heavy on Perl code, and I'm not a Perl
> Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with
> the mailing list address) but bugzilla replied kindly:
> 
> CC: perl-sig did not match anything

The Perl SIG's mailing list address is perl-devel@lists.fedoraproject.org .
This is a valid account in Bugzilla and should work.

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

Ditch RPM in favor of DPKG

[Dridi Boukelmoune]

Greetings packagers,

I know how important RPM is to the Fedora Project, but it breaks
everything downstream and we'd be better off using DPKG as we should
have from day one.

I'm calling this initiative fedpkg: Fedora Embraces DPKG.

A bit of background here: I build both RPMs and DEBs for $DAYJOB and
until recently my workflow was quite painful because I needed extra steps
between git checkout and git push that involves a VM, because what we
ship as apt is in reality apt-rpm.

It finally got enough on my nerves to locally build the things I needed and
after a month I have already amortized my efforts with the time I save not
having to deal with needless extra hoops.

In order to successfully build debs on Fedora I needed 4 packages that
I'm now submitting for review:

https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config
https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism
https://bugzilla.redhat.com/show_bug.cgi?id=sbuild
https://bugzilla.redhat.com/show_bug.cgi?id=apt

I need more than reviews here.

Three of those packages are heavy on Perl code, and I'm not a Perl
Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with
the mailing list address) but bugzilla replied kindly:

CC: perl-sig did not match anything

Apt is a mix of C, Perl and C++ code, so I would be reassured if I
could have a C++ co-maintainer too. I'm only a C developer so if
something goes wrong outside of the C realm that would be helpful.

Two of those packages should be runtime dependencies of debhelper.

The current apt package should be renamed to apt-rpm, I will look up
the procedure for that to happen. I understand that when someone sees
they should run "apt-get install foo" somewhere on the web it's
helpful for non-savvy users that this JustWorks(tm) [2], but apt-rpm is
dead upstream and it shouldn't be advertised as apt.

I hope I CC'd everyone that should get this heads up, and hope to find
help for the reviews and co-maintainership. The packaging does nothing
fancy, there are quirks here and there but overall it was rather easy
to put together. And of course I would be happy to help with reviews
too in exchange.

And thanks again to the mock developers, its design is so much better
than either sbuild or pdebuild that I barely have pain points left when it
comes to RPM packaging.

Thanks,
Dridi

[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_perl_sig
[2] I'm not against apt-rpm in the base install for example
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F31 System-Wide Change proposal: Automatic strict inter-package dependencies

[Panu Matilainen]

On Mon, Feb 18, 2019 at 9:21 PM Ben Cotton  wrote:




== Dependencies ==
RPM changes are needed. Will be handled by Proposal Owners.




As with the other rpm change proposal, this change was submitted without 
prior communication with the primary rpm maintainers, so I think a 
clarification is in order:


There needs to be an upstream rpm release with this feature included, we 
do not do feature backports in Fedora rpm. As of now, this is only being 
discussed at upstream.


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

Re: F31 System-Wide Change proposal: BuildRequires Generators

[Panu Matilainen]

On 2/18/19 10:19 PM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/BuildRequires_Generators

= BuildRequires Generators =

== Summary ==
Add possibility to generate build-time dependencies within RPM spec
file and teach RPM and mock how to handle this.

== Owner ==
* Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:ffesti|Florian
Festi]], [[User:msuchy|Miroslav Suchý]]
* Email: ignatenkobr...@fedoraproject.org, ffe...@redhat.com, miros...@suchy.cz

== Detailed Description ==
For many languages (Rust, Golang, Node.Js, Ruby, Python),
BuildRequires can be automatically generated. All it takes, run some
special tool which will output dependencies in RPM format.

Q: How will it work under the hood?
A: When you build RPM, something like this will happen under the hood…
# rpm would perform %prep (which is supposed to abort if some
dependencies missing and print them)
# mock would install those dependencies and resume build

Q: Will src.rpm contain all generated dependencies?
A: This is not known yet, we'll update page once it is known.

Q: Does this mean that package builds won't be reproducible anymore?
A: No, as long as you have same buildroot and tool which is generating
BuildRequires is doing so in reproducible manner, it should not affect
reproducibility.

== Benefit to Fedora ==

Packagers won't have to pre-generate BuildRequires in the spec file
which means it will be always updated (and correct) :

* Packagers can focus of making their packages better instead of
spending all their packaging time copying BuildRequires from
documentation and third party tools.
* BuildRequires are dropped as soon as they're no longer necessary
* Packages can be easily bumped without requiring a manual BuildRequires refresh
* BuildRequires and Requires generation can use similar utilities,
making sure that the deps packages declare can also be used for
second-level building. Packages no longer need to declare the deps of
their second and n-th dependencies because someone forgot to declare
them in the correct package.

== Scope ==
* Proposal owners: Implement support for a feature in RPM and mock (if
implemented properly, Koji should just work). Make use of it in Rust
ecosystem.
* Other developers: Maintainers of language stacks are advised to use
this feature.
* Release engineering: [https://pagure.io/releng/issue/8129 #8129]
* Policies and guidelines: Packaging Guidelines need to be updated
with instructions how to use this feature.
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Packagers and users who use repoquery might be affected (src.rpm might
not contain generated dependencies).

== How To Test ==
TBD.

== User Experience ==
Users won't notice differences.

== Dependencies ==
Required feature needs to be implemented in RPM and mock.



As this change was submitted without prior communication with the 
primary rpm maintainers, I think a clarification is in order:


There needs to be an upstream rpm release with this feature included, we 
do not do feature backports in Fedora rpm. As of now, this is only being 
discussed at upstream.


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

[Bug 1678447] perl-Time-HiRes-1.9760 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Time-HiRes-1.9760-1.fc
   ||30



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for Fedora ≥ 29.

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