Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Panu Matilainen]

On 6/4/19 4:00 AM, Jason L Tibbitts III wrote:

"PM" == Panu Matilainen  writes:


PM> Note that rpm doesn't support parallel zstd compression, and while
PM> it does for xz, that's not even utilized in Fedora.

Doing parallel xz compression has a surprising cost in compression ratio
which gets worse as the thread count increases (because it just splits
the input into independent blocks and compresses them separately).  I
did start on a feature to have it enabled but then abandoned that after
realizing that it didn't really work as I'd hoped.


Yup, I know. More than one people have been down that route :)



That said, I do wonder how difficult it would be to do parallel zstd
compression/decompression within RPM.  If it were possible then that
might help to obviate some of the downsides.


No idea, except that last I looked, zstd seemed to be the only kid in 
town who can do parallel decompression at all. The current zstd support 
in rpm is basically just an initial code drop that implements the 
barebones compress/decompress functionality. Besides parallel 
operations, it'd probably be worth trying to teach it to use a 
dictionary for example (the charts at https://github.com/facebook/zstd 
are pretty impressive on that)



PM> To me the sweet spot between compression efficiency and speed seems
PM> closer to 10 than 19 - yes at a minor loss in space but huge speedup
PM> in both compress and decompress times.

One problem is that I don't think anyone wants to see any quantifiable
regression in overall package size.  Spins still struggle to fit within
fixed media sizes as the package set grows ever larger.


Sure, everything's a compromise. Personally I find the fixed media 
battle one that was long lost already and low in the overall priorities 
but that's just me.


- 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 1716731] New: perl-Tree-1.14 is available

[bugzilla]

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

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



Latest upstream release: 1.14
Current version/release in rawhide: 1.13-2.fc30
URL: http://search.cpan.org/dist/Tree/

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

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

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-50e0fd4815   
drupal7-ds-2.16-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-fe7c636c57   
drupal7-uuid-1.2-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6326ff7745   
drupal7-xmlsitemap-2.6-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-65bad7ac43   
drupal7-context-3.10-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5621f2527a   
drupal7-path_breadcrumbs-3.4-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1af316b5db   
drupal7-module_filter-2.2-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e90e3284bc   
drupal7-views-3.23-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

php-horde-imp-6.2.24-1.el6
php-pda-pheanstalk-3.2.1-1.el6

Details about builds:



 php-horde-imp-6.2.24-1.el6 (FEDORA-EPEL-2019-cd02e09073)
 A web based webmail system

Update Information:

**imp 6.2.24**  * [mjr] Fix errors on initial quick search breaking subsequent
searches (Bug #14838). * [mjr] Don't indicate success if MDN fails (Bug #14920).
* [mjr] Fix/improve generation of PDF preview images.

ChangeLog:

* Wed May 29 2019 Remi Collet  - 6.2.24-1
- update to 6.2.24
- raise dependency on Horde_Image 2.6.0




 php-pda-pheanstalk-3.2.1-1.el6 (FEDORA-EPEL-2019-4603ac74ba)
 PHP client for beanstalkd queue

Update Information:

### v3.2.1 Bugfix for socket timeouts  This release fixes a bug that could, in
certain cases, cause data to be lost from a connection. Due to the way beanstalk
reservations work no data is permanently lost and the main effect of this would
be a delay in task execution.  Thanks for pointing out the problem @mialex!  ###
v3.2.0 Maintenance release  This is a maintenance release.  One issue that was
fixed in this release was the risk of an infinite loop in
`Connection::getLine()`. Now after a timeout, configurable via `ini-
set('default_socket_timeout', $timeout)`, the `getLine()` function will throw an
exception to bring it in line with `Connection::read()` and
`Connection::write()`.  If your worker has to potentially wait a long time for
jobs you might start to see exceptions that you did not see before. Even though
this behavior is a change it allows you to actually detect errors instead of
just waiting forever.   My worker runs via a supervisor  If your worker is
currently managed by a supervisor (ie, it restarts after it dies), set your
socket timeout to a value like `3600`. This means that if the worker doesn't get
jobs for 12 hours, it will be restarted 12 times, but in return, if the
connection is dead the worker will restart after at most 1 hour and resume
working.   My worker does not run via a supervisor  If a crash of your
worker results in manually having to restart it you should really change the
configuration. One option that partially resolves this is properly catching
errors in `reserve()`, socket errors are in that sense nothing new, the changes
in this version just make them more consistent in certain cases.

ChangeLog:

* Mon Jun  3 2019 Shawn Iwinski  - 3.2.1-1
- Update to 3.2.1
* Sat Feb  2 2019 Fedora Release Engineering  - 
3.1.0-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
* Fri Jul 13 2018 Fedora Release Engineering  - 
3.1.0-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Fri Feb  9 2018 Fedora Release Engineering  - 
3.1.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild


___
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

[Fedocal] Reminder meeting : Modularity Team (weekly)

[nils]

Dear all,

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

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

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

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



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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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

Unretire osslsigncode

[Marek Marczykowski-Górecki]

Hi,

I'd like to request unretire osslsigncode[1]. Originally it was retired
because of being abandoned upstream, but now there is an actively
maintained fork[2] with major release half a year ago and last commit
less than 2 months ago. As I understand[3], original maintainer of
Fedora osslsigncode package is not interested in maintaining it anymore.
I can take it from there, but that would be my first package in Fedora
(although I do maintain RPM packages elsewhere). I have already created
scratch build of it at [4].

Any objections?

[1] https://src.fedoraproject.org/rpms/osslsigncode
[2] https://github.com/mtrojnar/osslsigncode
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1424037#c9
[4] https://koji.fedoraproject.org/koji/taskinfo?taskID=35260552

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 293  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
 101  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f8311ec8a2   
tor-0.3.5.8-1.el7
  69  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294   
cinnamon-3.6.7-5.el7
  61  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-50a6a1ddfd   
afflib-3.7.18-2.el7
  35  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80   
python-gnupg-0.4.4-1.el7
  32  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b   
bubblewrap-0.3.3-2.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b909a6e178   
sleuthkit-4.6.6-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9cab93353c   
drupal7-ds-2.16-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2c1ec539fd   
drupal7-uuid-1.2-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f614c9a4bc   
drupal7-xmlsitemap-2.6-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-8278894e4d   
drupal7-context-3.10-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-de5e3216ff   
drupal7-path_breadcrumbs-3.4-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-748b40598c   
drupal7-module_filter-2.2-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-53f9189a5e   
drupal7-views-3.23-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-043371cfab   
rust-1.35.0-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-fc63c75ab1   
hostapd-2.8-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

cekit-3.1.0-1.el7
libsodium-1.0.18-1.el7
php-composer-xdebug-handler-1.3.3-1.el7
php-horde-imp-6.2.24-1.el7
php-pda-pheanstalk-3.2.1-1.el7
sip-redirect-0.2.0-9.el7
x509watch-0.6.1-6.el7

Details about builds:



 cekit-3.1.0-1.el7 (FEDORA-EPEL-2019-eb75f98956)
 Container image creation tool

Update Information:

Release 3.1.0

ChangeLog:

* Mon Jun  3 2019 Marek Goldmann  - 3.1.0-1
- Release 3.1.0




 libsodium-1.0.18-1.el7 (FEDORA-EPEL-2019-707f5271ca)
 The Sodium crypto library

Update Information:

** Version 1.0.18**   - A test that didn't work properly on Linux systems with
overcommit memory turned on has been removed. This fixes Ansible builds.  -
Emscripten: `print` and `printErr` functions are overridden to send errors to
the console, if there is one.  - Emscripten: `UTF8ToString()` is now exported
since `Pointer_stringify()` has been deprecated.  - Libsodium version detection
has been fixed in the CMake recipe.  - Generic hashing got a 10% speedup on
AVX2.  - New target: WebAssembly/WASI (compile with `dist-
builds/wasm32-wasi.sh`).  - New functions to map a hash to an edwards25519 point
or get a random point: `core_ed25519_from_hash()` and `core_ed25519_random()`.
- `crypto_core_ed25519_scalar_mul()` has been implemented for `scalar*scalar`
`(mod L)` multiplication.  - Support for the Ristretto group has been
implemented, for compatibility with wasm-crypto.  - Improvements have been made
to the test suite.  - Portability improvements has been made.  - `getentropy()`
is now used on systems providing this system call.  - `randombytes_salsa20 has
been renamed to `randombytes_internal`.  - Support for (p)nacl has been removed.
- Most `((nonnull))` attributes have been relaxed to allow 0-length inputs to be
`NULL`.  - The `-ftree-vectorize` and `-ftree-slp-vectorize` compiler switches
are now used, if available, for optimized builds.

ChangeLog:

* Mon Jun  3 2019 Remi Collet  - 1.0.18-1
- update to 1.0.18




 php-composer-xdebug-handler-1.3.3-1.el7 (FEDORA-EPEL-2019-03c96e507c)
 Restarts a process without xdebug

Update Information:

**Version 1.3.3** - 2019-05-27* Fixed: add environment changes to `$_ENV` if
it is being used.

ChangeLog:

* Tue May 28 2019 Remi Collet  - 1.3.3-1
- update to 1.3.3

[389-devel] 389 DS nightly 2019-06-04 - 94% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/06/04/report-389-ds-base-1.4.1.3-20190603git73cdeb7.fc30.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Jason L Tibbitts III]

> "PM" == Panu Matilainen  writes:

PM> Note that rpm doesn't support parallel zstd compression, and while
PM> it does for xz, that's not even utilized in Fedora.

Doing parallel xz compression has a surprising cost in compression ratio
which gets worse as the thread count increases (because it just splits
the input into independent blocks and compresses them separately).  I
did start on a feature to have it enabled but then abandoned that after
realizing that it didn't really work as I'd hoped.

That said, I do wonder how difficult it would be to do parallel zstd
compression/decompression within RPM.  If it were possible then that
might help to obviate some of the downsides.

PM> To me the sweet spot between compression efficiency and speed seems
PM> closer to 10 than 19 - yes at a minor loss in space but huge speedup
PM> in both compress and decompress times.

One problem is that I don't think anyone wants to see any quantifiable
regression in overall package size.  Spins still struggle to fit within
fixed media sizes as the package set grows ever larger.

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

Re: Proposal: Drop python2 versions of pyside and shiboken

[Felix Schwarz]

Am 03.06.19 um 22:33 schrieb Richard Shaw:
> I did some cursory searching with dnf repoquery and I can't find any consumers
> of the python2 side of pyside and shiboken in Rawhide.  I recently moved over
> the largest consumer (FreeCAD) to the python3 pyside bindings. 

+1

thanks for taking care of pyside in Fedora :-)
Felix
___
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 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Daniel Mach]

Dne 30. 05. 19 v 17:14 Peter Robinson napsal(a):

What about constrained systems where there's limited CPU, that could
be a container or a low end cloud instance without any guarantee of
resources or a Raspberry Pi.


Raspberry Pi is hard to measure. I'm getting quite random results due to 
IO, I blame the on-board microSD card controller.


I tested following package set (podman + deps):
containernetworking-plugins-0.7.4-2.fc30.aarch64.rpm
containers-common-0.1.36-9.dev.gitd93a581.fc30.aarch64.rpm
criu-3.12-11.fc30.aarch64.rpm
fuse3-libs-3.5.0-1.fc30.aarch64.rpm
fuse-overlayfs-0.3-10.dev.gita7c8295.fc30.aarch64.rpm
libbsd-0.9.1-3.fc30.aarch64.rpm
libnet-1.1.6-17.fc30.aarch64.rpm
ostree-libs-2019.2-1.fc30.aarch64.rpm
podman-1.3.1-1.git7210727.fc30.aarch64.rpm
protobuf-c-1.3.1-2.fc30.aarch64.rpm
runc-1.0.0-93.dev.gitb9b6cc6.fc30.aarch64.rpm
slirp4netns-0.3.0-2.git4992082.fc30.aarch64.rpm
tar-1.32-1.fc30.aarch64.rpm

Then I re-compressed the RPMs by running:
rpmrebuild --define "%_binary_payload w19.zstdio" -p 

xz.2 size: 27M
zstd.19 size: 22M

Then I ran installs into ramdisk:
sync; echo 3 > /proc/sys/vm/drop_caches; time rpm -Uvh * --force 
--nodeps --stats --noscripts --root=/tmp/foo


xz: 10.9s
zstd: 4.7s

When I installed RPMs on the system (micro SD card), it took approx. 
1m30s in both cases, but it's really giving quite random results due to IO.


Zstd performs slightly better than xz, but users can hardly see any 
difference, because of IO. Good thing is that it's almost equal and 
doesn't degrade performance on low end hardware.

___
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 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Daniel Mach]

Dne 30. 05. 19 v 17:14 Peter Robinson napsal(a):

What about constrained systems where there's limited CPU, that could
be a container or a low end cloud instance without any guarantee of
resources or a Raspberry Pi.


Raspberry Pi is hard to measure. I'm getting quite random results due to 
IO, I blame the on-board microSD card controller.


I tested following package set (podman + deps):
containernetworking-plugins-0.7.4-2.fc30.aarch64.rpm
containers-common-0.1.36-9.dev.gitd93a581.fc30.aarch64.rpm
criu-3.12-11.fc30.aarch64.rpm
fuse3-libs-3.5.0-1.fc30.aarch64.rpm
fuse-overlayfs-0.3-10.dev.gita7c8295.fc30.aarch64.rpm
libbsd-0.9.1-3.fc30.aarch64.rpm
libnet-1.1.6-17.fc30.aarch64.rpm
ostree-libs-2019.2-1.fc30.aarch64.rpm
podman-1.3.1-1.git7210727.fc30.aarch64.rpm
protobuf-c-1.3.1-2.fc30.aarch64.rpm
runc-1.0.0-93.dev.gitb9b6cc6.fc30.aarch64.rpm
slirp4netns-0.3.0-2.git4992082.fc30.aarch64.rpm
tar-1.32-1.fc30.aarch64.rpm

Then I re-compressed the RPMs by running:
rpmrebuild --define "%_binary_payload w19.zstdio" -p 

xz.2 size: 27M
zstd.19 size: 22M

Then I ran installs into ramdisk:
sync; echo 3 > /proc/sys/vm/drop_caches; time rpm -Uvh * --force 
--nodeps --stats --noscripts --root=/tmp/foo


xz: 10.9s
zstd: 4.7s

When I installed RPMs on the system (micro SD card), it took approx. 
1m30s in both cases, but it's really giving quite random results due to IO.


Zstd performs slightly better than xz, but users can hardly see any 
difference, because of IO. Good thing is that it's almost equal and 
doesn't degrade performance on low end hardware.

___
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: Proposal: Drop python2 versions of pyside and shiboken

[Richard Shaw]

On Mon, Jun 3, 2019 at 3:47 PM Miro Hrončok  wrote:

> On 03. 06. 19 22:33, Richard Shaw wrote:
> > I did some cursory searching with dnf repoquery and I can't find any
> consumers
> > of the python2 side of pyside and shiboken in Rawhide.  I recently moved
> over
> > the largest consumer (FreeCAD) to the python3 pyside bindings.
>
> Awesome news. Have you managed to switch freecad without pyside2?
>

Yes, the current release still works with Qt4/Pyside but I do have a review
request for Pyside2 (Qt5) that needs a reviewer.



> I see https://fedora.portingdb.xyz/pkg/pyside-tools/ but I guess that
> should be
> switched to Python 3 or dropped, right?
>

Whoops, forgot about that but I just ported it over to Python 3, but by
porting I mean I fixed build errors during byte compilation. I haven't done
any testing of the package yet.

Another case where arbitrary side tags would be nice to have :)

When I have time I'll try doing a local build of FreeCAD with it which will
at least provide some testing of the pyside-tools package, unless someone
knows of another package that makes extensive use of lupdate, pysideuic,
etc...

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: Another ceph build stuck in pending testing, four days

[Randy Barlow]

On Sun, 2019-06-02 at 18:03 -0400, Kaleb Keithley wrote:
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-60ba61b5ab
> 
> Why does this happen every time?
> 
> Would someone please kick it? Thanks

I filed an issue about this for you:

https://pagure.io/fedora-infrastructure/issue/7871


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: Proposal: Drop python2 versions of pyside and shiboken

[Miro Hrončok]

On 03. 06. 19 22:33, Richard Shaw wrote:
I did some cursory searching with dnf repoquery and I can't find any consumers 
of the python2 side of pyside and shiboken in Rawhide.  I recently moved over 
the largest consumer (FreeCAD) to the python3 pyside bindings.


Awesome news. Have you managed to switch freecad without pyside2?

I see https://fedora.portingdb.xyz/pkg/pyside-tools/ but I guess that should be 
switched to Python 3 or dropped, right?


> Anyone see a problem with this?

Nope :)

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

Proposal: Drop python2 versions of pyside and shiboken

[Richard Shaw]

I did some cursory searching with dnf repoquery and I can't find any
consumers of the python2 side of pyside and shiboken in Rawhide.  I
recently moved over the largest consumer (FreeCAD) to the python3 pyside
bindings.

Anyone see a problem with this?

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: Stale packages in Fedora 30

[Stephen John Smoogen]

On Mon, 3 Jun 2019 at 15:28, Adam Williamson 
wrote:

> On Mon, 2019-06-03 at 20:06 +0200, Ralf Corsepius wrote:
> > On 6/3/19 7:05 PM, Adam Williamson wrote:
> > > Some people don't see any problem with this, personally it drives me
> > > crazy and I wish it were policy that *every* retired package must be
> > > obsoleted. But it isn't.
> > I am quite shocked to hear this from you. I wouldn't have expected this
> > attitude from you.
> >
> > You seem have forgotten about the problems, such obsoletes cause, e.g.
> > when packages are being reintroduced or move to 3rd party repos or when
> > 3rd party packages depend upon them.
>
> Version the obsoletes correctly and this doesn't need to be a problem
> at all.
>

Write code correctly and we wouldn't need to ever do updates either :) That
never seems to happen so how do you deal with it when it doesn't.. tell the
user they should have had better backups?



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


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Stale packages in Fedora 30

[Adam Williamson]

On Mon, 2019-06-03 at 20:06 +0200, Ralf Corsepius wrote:
> On 6/3/19 7:05 PM, Adam Williamson wrote:
> > Some people don't see any problem with this, personally it drives me
> > crazy and I wish it were policy that *every* retired package must be
> > obsoleted. But it isn't.
> I am quite shocked to hear this from you. I wouldn't have expected this 
> attitude from you.
> 
> You seem have forgotten about the problems, such obsoletes cause, e.g. 
> when packages are being reintroduced or move to 3rd party repos or when 
> 3rd party packages depend upon them.

Version the obsoletes correctly and this doesn't need to be a problem
at all.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Stale packages in Fedora 30

[Bruno Wolff III]

On Mon, Jun 03, 2019 at 12:47:53 +0200,
 Hans de Goede  wrote:


I once maintained this, it seems that Bruno, who took it over,
no longer has time to maintain this.


Yeah, but leave me as a co-maintainer as things might get better. I did some 
CI work for squashfs-tools a couple of weeks ago, so I'm starting to get 
a little done again. But getting zstd support in squashfs-tools (which 
involves a few other changes as a prerequisite) is what I want to get done 
next.

___
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: Stale packages in Fedora 30

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jun 03, 2019 at 01:32:41PM -0400, Stephen John Smoogen wrote:
> On Mon, 3 Jun 2019 at 13:17, Chris Murphy  wrote:
> 
> > On Mon, Jun 3, 2019 at 11:07 AM Adam Williamson
> >  wrote:
> > >
> > > On Sun, 2019-06-02 at 21:35 -0600, Chris Murphy wrote:
> > > > Perhaps related, on an upgraded Fedora 30 system I see
> > > > ghostscript-fonts-5.50-37.fc27.noarch, which does not appear on any
> > > > clean installed systems, and also can't be installed (Error: Unable to
> > > > find a match ). That tells me it's been dropped or is obsolete, so is
> > > > it normal for such packages to persist through upgrades?
> > >
> > > Sure, very common. Packages are frequently retired and not formally
> > > obsoleted by anything else: in this case, if you have them installed,
> > > they'll stay installed until some dependency issue crops up and you
> > > have to remove them manually (or use --allowerasing) to clear it up.
> >
> > And does gnome-software do --allowerasing, or equivalent? Or other
> > behavior?
> >
> > >
> > > Some people don't see any problem with this, personally it drives me
> > > crazy and I wish it were policy that *every* retired package must be
> > > obsoleted. But it isn't.
> >
> > Not obsoleting retired packages is arguably inconsistent with the
> > Workstation PRD:
> >
> > "Upgrading the system multiple times through the upgrade process
> > should give a result that is the same as an original install of Fedora
> > Workstation."
> >
> > I understand that is a goal, not a policy or release criterion.
> >
> >
> I expect it is an impossible goal as it is making the installer guess that
> you didn't want to keep that version of wumpus from RHL6.2 which works
> still but isn't in the repository. And forcing an obsolete has knock-on
> effects. At best I can obsolete the version of emacs-freebird which came
> from Fedora up until release N, but if the person has a version they
> compile themselves.. then a centralized obsoletes has a good chance of
> removing it unless the packager did exactly the right things in the
> obsoletes and the other version of emacs-freebird also did the right
> things. I expect that instead you end up with a lot of pissed off people...
> which no one has the emotional labour to deal with.

It's possible that this used to be true, i.e. that the number of people who
compiled *their own versions* of packages that are already in the distro
was non-trivial. Nowadays, I'm pretty sure this happens very very rarely.
People install external and self-compiled packages mostly when they cannot
get something from the distro.

I don't have any formal numbers for this, but based on the bug reports
that come in before and around every release, it's quite obvious that
the number of users negatively impacted by non-obsoleted distro
packages (*) dwarves the number of people who have an external
package, and that in turn is still higher than those that have an
external package with a lower nevra.

(*) Fedora removes many many packages and subpackages on every
release. So every non-minimal installation of Fedora will have such
stale-but-not-obsoleted package after *every* upgrade. It's only a question
of time until some so-version changes and such packages cause upgrades
to break. Normal users are (correctly) wary of --allowerasing which is
risky and requires a good understanding of packaging and recovery methods.

I understand why this policy drives adamw crazy. I think we're shooting
our users in the foot.

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

Re: Stale packages in Fedora 30

[Michael Cronenworth]

On 5/30/19 1:18 PM, Adam Jackson wrote:

Fedora 26
...
mingw-wine-gecko-2.47-2.fc26.src.rpm


I would welcome eyes on this. Upstream has been informed about it, but they have not 
issued any new release.


This package is basically a mini-Firefox and usually breaks from Mingw-w64 updates. 
I haven't had any time to patch it myself.


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

Re: Intent to retire why

[Jerry James]

On Mon, Jun 3, 2019 at 9:40 AM Richard W.M. Jones  wrote:

> why3 is a replacement for it, is that right?
>

Sort of.  Wh3 was originally intended to be a complete replacement, but
functionality has been migrated slowly, requiring one to use both why and
why3 for some years now to get everything.  For example, why has a frama-c
plugin.  The why3 version exists, but upstream says it is experimental and
has advised me not to even build it for Fedora.  The C and Java front ends
for why (http://krakatoa.lri.fr/) have not been replicated in why3 yet.
The situation is unfortunate, but upstream has limited resources.

Over the weekend, I took a look at how hard it would be to keep why working
with the current versions of frama-c and why3.  I came up with a patch that
at least gets it to build.  I'm going to experiment with it over the next
couple of days and see if the functionality actually works at all.  If it
does, I will keep the why package around a little longer, to give any users
time to finish migrating to why3.  However, such users should note that
another release of Frama-C is expected in a couple of weeks.  If that
release breaks the why package again, I may or may not be able to repair it
again.  If not, I will retire the why package at that time.

Also:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1673688
> https://pagure.io/releng/issue/8310
>
> Still waiting for 4.08 to be released to complete this ...
>

Noted.  I will probably get all these packages built on Wednesday or
Thursday of this week.  If that turns out to be a bad time for you, please
let me know and I will postpone the builds.  Regards,
-- 
Jerry James
http://www.jamezone.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: Attempting to contact unresponsive maintainers: dkaspar flaper87

[Anderson, Charles R]

I can take tcsh if nobody else does.

On Mon, Jun 03, 2019 at 04:23:54PM +, Marcin Dulak wrote:
> Nobody took tcsh until now.
___
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: Stale packages in Fedora 30

[Ralf Corsepius]

On 6/3/19 7:05 PM, Adam Williamson wrote:

Some people don't see any problem with this, personally it drives me
crazy and I wish it were policy that *every* retired package must be
obsoleted. But it isn't.
I am quite shocked to hear this from you. I wouldn't have expected this 
attitude from you.


You seem have forgotten about the problems, such obsoletes cause, e.g. 
when packages are being reintroduced or move to 3rd party repos or when 
3rd party packages depend upon them.


Ralf






___
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: Stale packages in Fedora 30

[Przemek Klosowski via devel]

On 6/3/19 1:16 PM, Chris Murphy wrote:

On Mon, Jun 3, 2019 at 11:07 AM Adam Williamson
 wrote:

Some people don't see any problem with this, personally it drives me
crazy and I wish it were policy that *every* retired package must be
obsoleted. But it isn't.

Not obsoleting retired packages is arguably inconsistent with the
Workstation PRD:

"Upgrading the system multiple times through the upgrade process
should give a result that is the same as an original install of Fedora
Workstation."

I understand that is a goal, not a policy or release criterion.


It leads to situations like 
https://bugzilla.redhat.com/show_bug.cgi?id=1490074 where the package 
doesn't work, and there's not even any possibility for fixing it (the 
package was abandoned and it's successor was abandoned as well).


Situations like these just embarrass Fedora, so I agree with Adam that 
something should be done, but as the comments in #1490074 show, people 
aren't sure what exactly should happen.

___
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: Stale packages in Fedora 30

[Stephen John Smoogen]

On Mon, 3 Jun 2019 at 13:17, Chris Murphy  wrote:

> On Mon, Jun 3, 2019 at 11:07 AM Adam Williamson
>  wrote:
> >
> > On Sun, 2019-06-02 at 21:35 -0600, Chris Murphy wrote:
> > > Perhaps related, on an upgraded Fedora 30 system I see
> > > ghostscript-fonts-5.50-37.fc27.noarch, which does not appear on any
> > > clean installed systems, and also can't be installed (Error: Unable to
> > > find a match ). That tells me it's been dropped or is obsolete, so is
> > > it normal for such packages to persist through upgrades?
> >
> > Sure, very common. Packages are frequently retired and not formally
> > obsoleted by anything else: in this case, if you have them installed,
> > they'll stay installed until some dependency issue crops up and you
> > have to remove them manually (or use --allowerasing) to clear it up.
>
> And does gnome-software do --allowerasing, or equivalent? Or other
> behavior?
>
> >
> > Some people don't see any problem with this, personally it drives me
> > crazy and I wish it were policy that *every* retired package must be
> > obsoleted. But it isn't.
>
> Not obsoleting retired packages is arguably inconsistent with the
> Workstation PRD:
>
> "Upgrading the system multiple times through the upgrade process
> should give a result that is the same as an original install of Fedora
> Workstation."
>
> I understand that is a goal, not a policy or release criterion.
>
>
I expect it is an impossible goal as it is making the installer guess that
you didn't want to keep that version of wumpus from RHL6.2 which works
still but isn't in the repository. And forcing an obsolete has knock-on
effects. At best I can obsolete the version of emacs-freebird which came
from Fedora up until release N, but if the person has a version they
compile themselves.. then a centralized obsoletes has a good chance of
removing it unless the packager did exactly the right things in the
obsoletes and the other version of emacs-freebird also did the right
things. I expect that instead you end up with a lot of pissed off people...
which no one has the emotional labour to deal with.




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


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Stale packages in Fedora 30

[Chris Murphy]

On Mon, Jun 3, 2019 at 11:07 AM Adam Williamson
 wrote:
>
> On Sun, 2019-06-02 at 21:35 -0600, Chris Murphy wrote:
> > Perhaps related, on an upgraded Fedora 30 system I see
> > ghostscript-fonts-5.50-37.fc27.noarch, which does not appear on any
> > clean installed systems, and also can't be installed (Error: Unable to
> > find a match ). That tells me it's been dropped or is obsolete, so is
> > it normal for such packages to persist through upgrades?
>
> Sure, very common. Packages are frequently retired and not formally
> obsoleted by anything else: in this case, if you have them installed,
> they'll stay installed until some dependency issue crops up and you
> have to remove them manually (or use --allowerasing) to clear it up.

And does gnome-software do --allowerasing, or equivalent? Or other behavior?

>
> Some people don't see any problem with this, personally it drives me
> crazy and I wish it were policy that *every* retired package must be
> obsoleted. But it isn't.

Not obsoleting retired packages is arguably inconsistent with the
Workstation PRD:

"Upgrading the system multiple times through the upgrade process
should give a result that is the same as an original install of Fedora
Workstation."

I understand that is a goal, not a policy or release criterion.


-- 
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: Using fedora-active-user: unable to find fedora_cert

[Adam Williamson]

On Mon, 2019-06-03 at 12:52 +0200, Vít Ondruch wrote:
> Dne 30. 05. 19 v 23:50 Adam Williamson napsal(a):
> > On Thu, 2019-05-30 at 22:42 +0100, Tom Hughes wrote:
> > > On 30/05/2019 22:38, Adam Williamson wrote:
> > > 
> > > > I'd kinda rather there was a standard way for all such things to read
> > > > the username from a standard file, because my Fedora username is not my
> > > > system username and passing --user or --username or whatever to
> > > > everything is a pain.
> > > Don't most things look at $FAS_USERNAME for that?
> > > 
> > > There's ~/.fedora.upn as well though I'm not sure what looks
> > > at that?
> > That's...sorta my whole point. :P Clearly if you can think of two
> > mechanisms and you don't know what uses which...there isn't a
> > standard...
> > 
> > (I know some things used to look at ~/.fedora.cert to figure it out,
> > too).
> 
> Don't we have kerberos for Fedora?

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

Re: Stale packages in Fedora 30

[Adam Williamson]

On Sun, 2019-06-02 at 21:35 -0600, Chris Murphy wrote:
> Perhaps related, on an upgraded Fedora 30 system I see
> ghostscript-fonts-5.50-37.fc27.noarch, which does not appear on any
> clean installed systems, and also can't be installed (Error: Unable to
> find a match ). That tells me it's been dropped or is obsolete, so is
> it normal for such packages to persist through upgrades?

Sure, very common. Packages are frequently retired and not formally
obsoleted by anything else: in this case, if you have them installed,
they'll stay installed until some dependency issue crops up and you
have to remove them manually (or use --allowerasing) to clear it up.

Some people don't see any problem with this, personally it drives me
crazy and I wish it were policy that *every* retired package must be
obsoleted. But it isn't.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora Rawhide-20190603.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Atomichost raw-xz x86_64
Atomichost qcow2 x86_64

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 11/146 (x86_64), 3/24 (i386), 1/2 (arm)

ID: 408442  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/408442
ID: 408453  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/408453
ID: 408478  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/408478
ID: 408489  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/408489
ID: 408493  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/408493
ID: 408496  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/408496
ID: 408506  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/408506
ID: 408556  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/408556
ID: 408560  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/408560
ID: 408563  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/408563
ID: 408565  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/408565
ID: 408568  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/408568
ID: 408571  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/408571
ID: 408586  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/408586
ID: 408596  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/408596

Soft failed openQA tests: 75/146 (x86_64), 18/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 408425  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/408425
ID: 408426  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/408426
ID: 408427  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/408427
ID: 408428  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/408428
ID: 408435  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/408435
ID: 408436  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/408436
ID: 408437  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/408437
ID: 408438  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/408438
ID: 408440  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/408440
ID: 408447  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/408447
ID: 408452  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/408452
ID: 408456  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/408456
ID: 408457  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/408457
ID: 408458  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/408458
ID: 408459  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/408459
ID: 408460  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/408460
ID: 408468  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/408468
ID: 408475  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/408475
ID: 408476  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/408476
ID: 408480  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/408480
ID: 408507  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/408507
ID: 408508  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/408508
ID: 408510  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/408510
ID: 408511  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/408511
ID: 408512  Test: x86_64 universal 

Re: Orphaned packages looking for new maintainers

[Miro Hrončok]

On 03. 06. 19 17:41, Richard W.M. Jones wrote:

A lot of packages that I care about depend on mtools, but
I see no announcement of mtools being orphaned ...

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

--
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: Attempting to contact unresponsive maintainers: dkaspar flaper87

[Marcin Dulak]

Nobody took tcsh until now.
___
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] please review: PR 50422 - Fix legacy tools to work with recent systemd unit file changes

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/50422
___
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: Orphaned packages looking for new maintainers

[Paolo Bonzini]

On 03/06/19 16:18, Miro Hrončok wrote:
> 
> ipxe (maintained by: berrange, bonzini, crobinso, virtmaint-sig)
>     ipxe-20190125-1.git36a4c85f.fc30.src requires mtools =
> 4.0.18-16.fc30, syslinux = 6.04-0.8.fc28

I'll take a look at removing the dependency.

Paolo
___
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 rawhide compose report: 20190603.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20190601.n.0
NEW: Fedora-Rawhide-20190603.n.0

= SUMMARY =
Added images:7
Dropped images:  8
Added packages:  43
Dropped packages:1
Upgraded packages:   55
Downgraded packages: 0

Size of added packages:  5.57 MiB
Size of dropped packages:22.34 KiB
Size of upgraded packages:   1.38 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20190603.n.0.iso
Image: Xfce live i386
Path: Spins/i386/iso/Fedora-Xfce-Live-i386-Rawhide-20190603.n.0.iso
Image: Design_suite live i386
Path: Labs/i386/iso/Fedora-Design_suite-Live-i386-Rawhide-20190603.n.0.iso
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20190603.n.0.x86_64.vagrant-libvirt.box
Image: Mate live i386
Path: Spins/i386/iso/Fedora-MATE_Compiz-Live-i386-Rawhide-20190603.n.0.iso
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20190603.n.0.x86_64.vagrant-virtualbox.box
Image: SoaS live i386
Path: Spins/i386/iso/Fedora-SoaS-Live-i386-Rawhide-20190603.n.0.iso

= DROPPED IMAGES =
Image: Server raw-xz armhfp
Path: Server/armhfp/images/Fedora-Server-armhfp-Rawhide-20190601.n.0-sda.raw.xz
Image: Xfce live x86_64
Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20190601.n.0.iso
Image: LXDE live i386
Path: Spins/i386/iso/Fedora-LXDE-Live-i386-Rawhide-20190601.n.0.iso
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20190601.n.0-sda.raw.xz
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20190601.n.0.ppc64le.tar.xz
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20190601.n.0.s390x.tar.xz
Image: Mate raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Mate-armhfp-Rawhide-20190601.n.0-sda.raw.xz
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20190601.n.0.iso

= ADDED PACKAGES =
Package: python-pipreqs-0.4.9-1.fc31
Summary: Pip requirements.txt generator based on imports in project
RPMs:python-pipreqs-doc python3-pipreqs
Size:190.62 KiB

Package: python-smi-0.3.4-3.fc31
Summary: A Python implementation of SNMP/SMI MIB parsing and conversion library
RPMs:python3-smi
Size:135.38 KiB

Package: rust-actix-0.8.3-1.fc31
Summary: Actor framework for Rust
RPMs:rust-actix+actix-http-devel rust-actix+default-devel 
rust-actix+http-devel rust-actix+mailbox_assert-devel rust-actix+resolver-devel 
rust-actix+tokio-tcp-devel rust-actix+trust-dns-resolver-devel rust-actix-devel
Size:126.95 KiB

Package: rust-actix-codec-0.1.2-1.fc31
Summary: Utilities for encoding and decoding frames
RPMs:rust-actix-codec+default-devel rust-actix-codec-devel
Size:21.66 KiB

Package: rust-actix-connect-0.2.0-1.fc31
Summary: Actix Connector - tcp connector service
RPMs:rust-actix-connect+default-devel rust-actix-connect+http-devel 
rust-actix-connect+openssl-devel rust-actix-connect+ssl-devel 
rust-actix-connect+tokio-openssl-devel rust-actix-connect+uri-devel 
rust-actix-connect-devel
Size:58.98 KiB

Package: rust-actix-http-0.2.3-1.fc31
Summary: Actix http primitives
RPMs:rust-actix-http+brotli-devel rust-actix-http+brotli2-devel 
rust-actix-http+default-devel rust-actix-http+fail-devel 
rust-actix-http+failure-devel rust-actix-http+flate2-devel 
rust-actix-http+flate2-rust-devel rust-actix-http+flate2-zlib-devel 
rust-actix-http+openssl-devel rust-actix-http+ring-devel 
rust-actix-http+secure-cookies-devel rust-actix-http+ssl-devel 
rust-actix-http-devel
Size:241.11 KiB

Package: rust-actix-router-0.1.5-1.fc31
Summary: Path router
RPMs:rust-actix-router+default-devel rust-actix-router+http-devel 
rust-actix-router-devel
Size:34.43 KiB

Package: rust-actix-server-0.5.1-1.fc31
Summary: Actix server - General purpose tcp server
RPMs:rust-actix-server+default-devel rust-actix-server+native-tls-devel 
rust-actix-server+openssl-devel rust-actix-server+ssl-devel 
rust-actix-server+tls-devel rust-actix-server+tokio-openssl-devel 
rust-actix-server-devel
Size:70.80 KiB

Package: rust-actix-server-config-0.1.1-1.fc31
Summary: Actix server config utils
RPMs:rust-actix-server-config+default-devel 
rust-actix-server-config+ssl-devel rust-actix-server-config+tokio-openssl-devel 
rust-actix-server-config-devel
Size:31.56 KiB

Package: rust-actix-service-0.4.0-1.fc31
Summary: Actix Service
RPMs:rust-actix-service+default-devel rust-actix-service-devel
Size:30.95 KiB

Package: rust-actix-utils-0.4.1-1.fc31
Summary: Actix utils - various actix net related services
RPMs:rust-actix-utils+default-devel rust-actix-utils-devel
Size:27.29 KiB

Package: rust-actix-web

Re: Orphaned packages looking for new maintainers

[Richard W.M. Jones]

A lot of packages that I care about depend on mtools, but
I see no announcement of mtools being orphaned ...

> Depending on: mtools (21), status change: 2019-05-31 (0 weeks ago)
>   gnome-boxes (maintained by: elmarco, feborges, fidencio, gnome-sig, 
> teuf, zeenix)
>   gnome-boxes-3.33.1-2.fc31.i686 requires mtools = 4.0.18-16.fc30
> 
>   hatari (maintained by: musuruan)
>   hatari-2.2.1-5.fc31.i686 requires mtools = 4.0.18-16.fc30
> 
>   ipxe (maintained by: berrange, bonzini, crobinso, virtmaint-sig)
>   ipxe-20190125-1.git36a4c85f.fc30.src requires mtools =
> 4.0.18-16.fc30, syslinux = 6.04-0.8.fc28
> 
>   kiwi (maintained by: ngompa)
>   kiwi-systemdeps-9.17.38-1.fc31.i686 requires mtools =
> 4.0.18-16.fc30, syslinux = 6.04-0.8.fc28
>   kiwi-pxeboot-9.17.38-1.fc31.i686 requires syslinux = 
> 6.04-0.8.fc28
> 
>   oz (maintained by: clalance, imcleod)
>   oz-0.17.0-2.fc31.noarch requires mtools = 4.0.18-16.fc30
> 
>   syslinux (maintained by: pjones)
>   syslinux-6.04-0.8.fc28.i686 requires mtools = 4.0.18-16.fc30
> 
>   udisks (maintained by: amigadave)
>   udisks-1.0.5-12.fc31.i686 requires mtools = 4.0.18-16.fc30
> 
>   imagefactory (maintained by: clalance, imcleod, mmorsi)
>   imagefactory-1.1.11-2.fc30.noarch requires oz = 0.17.0-2.fc31
> 
>   imagefactory-plugins (maintained by: imcleod)
>   imagefactory-plugins-IndirectionCloud-1.1.11-2.fc30.noarch
> requires imagefactory-plugin-api = 1.0, oz = 0.17.0-2.fc31
>   imagefactory-plugins-OVA-1.1.11-2.fc30.noarch requires
> imagefactory-plugin-api = 1.0, oz = 0.17.0-2.fc31
>   imagefactory-plugins-TinMan-1.1.11-2.fc30.noarch requires
> imagefactory-plugin-api = 1.0, oz = 0.17.0-2.fc31
>   imagefactory-plugins-ovfcommon-1.1.11-2.fc30.noarch requires oz 
> = 0.17.0-2.fc31
>   imagefactory-plugins-1.1.11-2.fc30.noarch requires imagefactory 
> = 1.1.11-2.fc30
>   imagefactory-plugins-EC2-1.1.11-2.fc30.noarch requires
> imagefactory-plugin-api = 1.0
>   imagefactory-plugins-GCE-1.1.11-2.fc30.noarch requires
> imagefactory-plugin-api = 1.0
>   imagefactory-plugins-RHEVM-1.1.11-2.fc30.noarch requires
> imagefactory-plugin-api = 1.0
>   imagefactory-plugins-vSphere-1.1.11-2.fc30.noarch requires
> imagefactory-plugin-api = 1.0
> 
>   cobbler (maintained by: jimi, kwizart, orion, shenson)
>   cobbler-2.8.4-6.fc30.i686 requires syslinux = 6.04-0.8.fc28
> 
>   libguestfs (maintained by: mdbooth, ptoscano, rjones)
>   libguestfs-1:1.40.2-4.fc31.i686 requires syslinux = 
> 6.04-0.8.fc28
>   libguestfs-1:1.40.2-4.fc31.src requires syslinux = 6.04-0.8.fc28
> 
>   lorax (maintained by: bcl, clumens, dcantrel, dshea, wwoods)
>   lorax-31.6-1.fc31.i686 requires syslinux = 6.04-0.8.fc28
> 
>   mkbootdisk (maintained by: jskarvad)
>   mkbootdisk-1.5.5-22.fc30.i686 requires syslinux = 6.04-0.8.fc28
> 
>   livecd-tools (maintained by: astokes, bcl, bruno, huff, katzj, ngompa)
>   python-imgcreate-sysdeps-1:27.1-1.fc31.i686 requires lorax =
> 31.6-1.fc31, syslinux = 6.04-0.8.fc28
> 
>   rear (maintained by: gdha)
>   rear-2.4-3.fc30.i686 requires syslinux = 6.04-0.8.fc28
> 
>   unetbootin (maintained by: filiperosset)
>   unetbootin-657-5.fc30.i686 requires syslinux = 6.04-0.8.fc28
> 
>   emelfm2 (maintained by: cwickert)
>   emelfm2-0.9.1-12.fc30.i686 requires udisks = 1.0.5-12.fc31
> 
>   guestfs-browser (maintained by: rjones)
>   guestfs-browser-0.2.3-15.fc30.i686 requires libguestfs =
> 1:1.40.2-4.fc31, libguestfs.so.0
> 
>   nbdkit (maintained by: rjones)
>   nbdkit-guestfs-plugin-1.13.3-1.fc31.i686 requires 
> libguestfs.so.0
> 
>   testcloud (maintained by: mkrizek, qa-tools-sig, tflink)
>   testcloud-0.2.2-2.fc30.noarch requires libguestfs = 
> 1:1.40.2-4.fc31
> 
>   pungi (maintained by: dmach, lsedlar, maxamillion, tdawson, wwoods)
>   pungi-4.1.36-4.fc31.src requires lorax = 31.6-1.fc31
> 
>   Too many dependencies for mtools, not all listed here

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Re: Intent to retire why

[Richard W.M. Jones]

On Fri, May 31, 2019 at 10:10:11AM -0600, Jerry James wrote:
> In a few days, I intend to update coq to version 8.9.1 in Rawhide, and
> also update all of the packages that depend on it.  The why package
> has been abandoned by upstream.  Its latest version does not work with
> the latest versions of its dependent packages (why3 and frama-c), and
> upstream has no intention of fixing it.  I intend to retire it when I
> do the updates.  If somebody wants it, let me know, but be aware that
> you will effectively have to become upstream.

why3 is a replacement for it, is that right?

Also:

https://bugzilla.redhat.com/show_bug.cgi?id=1673688
https://pagure.io/releng/issue/8310

Still waiting for 4.08 to be released to complete this ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Fabio Valentini]

I'll submit a request to have apache-commons-discovery un-orphaned again.

Fabio

On Mon, Jun 3, 2019, 16:19 Miro Hrončok  wrote:

> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for
> sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the
> affected
> packages or a package that depends on one. Please adopt the affected
> package or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
> See this report online at:
> https://churchyard.fedorapeople.org/orphans-2019-06-03.txt
>
> Packages retired today but still in this report:
> aeskulap dvdbackup emacs-pymacs gnome-dvb-daemon
> gnome-shell-extension-panel-osd rubygem-chunky_png
> rubygem-compass-960-plugin
> rubygem-webrat
>
> Request package ownership via: https://pagure.io/releng/issues
>
>  Package  (co)maintainers   Status
> Change
>
> 
> aeskulap  orphan   7 weeks
> ago
> apache-commons-discovery  lkundrak, mizdebsk, orphan,  1 weeks
> ago
>spike
> ceph-deploy   branto, fsimonce, ktdreyer,  4 weeks
> ago
>orphan, trhoden
> checkstyledbhole, greghellings, lef,   2 weeks
> ago
>mizdebsk, nsantos, orphan,
>rmyers
> clpbardcantrel, orphan 4 weeks
> ago
> cmdtest   orphan   1 weeks
> ago
> compat-openssl10-pkcs11-helperorphan, rdieter  3 weeks
> ago
> crypto-utils  jorton, orphan   0 weeks
> ago
> dvdbackup cicku, orphan7 weeks
> ago
> emacs-pymacs  orphan   7 weeks
> ago
> fedocal   infra-sig, orphan0 weeks
> ago
> flr   orphan   1 weeks
> ago
> genbackupdata orphan   1 weeks
> ago
> gnome-dvb-daemon  orphan   7 weeks
> ago
> gnome-shell-extension-panel-osd   orphan   7 weeks
> ago
> gnumed-server orphan   1 weeks
> ago
> gpart dcantrel, orphan 4 weeks
> ago
> gscribble orphan   1 weeks
> ago
> h2akurtakov, dchen, lef, orphan4 weeks
> ago
> jwebunit  orphan   3 weeks
> ago
> kimchijcapik, orphan   1 weeks
> ago
> libemuorphan   0 weeks
> ago
> librtfcomporphan   1 weeks
> ago
> loopabull orphan   1 weeks
> ago
> lrbd  orphan   1 weeks
> ago
> ltspfsenslaver, orphan 6 weeks
> ago
> monkeysphere  ctubbsii, orphan 2 weeks
> ago
> mtoolsorphan   0 weeks
> ago
> ninja-ide echevemaster, orphan 6 weeks
> ago
> nodejs-array-uniq nodejs-sig, orphan   1 weeks
> ago
> pdc-updater   orphan   1 weeks
> ago
> plaguedcbw, orphan 5 weeks
> ago
> pyqt-mail-checker orphan   1 weeks
> ago
> python-cachy  orphan   2 weeks
> ago
> python-fmn-libinfra-sig, orphan, ralph 0 weeks
> ago
> python-larch  orphan   1 weeks
> ago
> python-mandrill   orphan   1 weeks
> ago
> python-pylev  orphan   2 weeks
> ago
> pywebkitgtk   ivazquez, orphan, walters6 weeks
> ago
> repoview  orphan   1 weeks
> ago
> rubygem-chunky_pngmmorsi, orphan   7 weeks
> ago
> rubygem-codemirror-rails  orphan   6 weeks
> ago
> rubygem-commander   

I found 2 problems on remove python2-foo packages

[Sérgio Basto]

Hi, 
These removed python2 packages are breaking upgrade path 

1- when you remove python2-foo , you should add to main package
Obsoletes: python2-foo 

2- IMHO you should just remove python2-foo only on latest branches,
please don't forget epel7 case, so please add something like : 
%if 0%{?fedora} >= 30 
%endif 

Thanks,
-- 
Sérgio M. B.
___
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

I found 2 problems on remove python2-foo packages

[Sérgio Basto]

Hi, 
These removed python2 packages are breaking upgrade path 

1- when you remove python2-foo , you should add to main package
Obsoletes: python2-foo 

2- IMHO you should just remove python2-foo only on latest branches,
please don't forget epel7 case, so please add something like : 
%if 0%{?fedora} >= 30 
%endif 

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

Orphaned packages looking for new maintainers

[Miro Hrončok]

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

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

See this report online at: 
https://churchyard.fedorapeople.org/orphans-2019-06-03.txt


Packages retired today but still in this report:
aeskulap dvdbackup emacs-pymacs gnome-dvb-daemon
gnome-shell-extension-panel-osd rubygem-chunky_png rubygem-compass-960-plugin
rubygem-webrat

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

Package  (co)maintainers   Status Change

aeskulap  orphan   7 weeks ago
apache-commons-discovery  lkundrak, mizdebsk, orphan,  1 weeks ago
  spike
ceph-deploy   branto, fsimonce, ktdreyer,  4 weeks ago
  orphan, trhoden
checkstyledbhole, greghellings, lef,   2 weeks ago
  mizdebsk, nsantos, orphan,
  rmyers
clpbardcantrel, orphan 4 weeks ago
cmdtest   orphan   1 weeks ago
compat-openssl10-pkcs11-helperorphan, rdieter  3 weeks ago
crypto-utils  jorton, orphan   0 weeks ago
dvdbackup cicku, orphan7 weeks ago
emacs-pymacs  orphan   7 weeks ago
fedocal   infra-sig, orphan0 weeks ago
flr   orphan   1 weeks ago
genbackupdata orphan   1 weeks ago
gnome-dvb-daemon  orphan   7 weeks ago
gnome-shell-extension-panel-osd   orphan   7 weeks ago
gnumed-server orphan   1 weeks ago
gpart dcantrel, orphan 4 weeks ago
gscribble orphan   1 weeks ago
h2akurtakov, dchen, lef, orphan4 weeks ago
jwebunit  orphan   3 weeks ago
kimchijcapik, orphan   1 weeks ago
libemuorphan   0 weeks ago
librtfcomporphan   1 weeks ago
loopabull orphan   1 weeks ago
lrbd  orphan   1 weeks ago
ltspfsenslaver, orphan 6 weeks ago
monkeysphere  ctubbsii, orphan 2 weeks ago
mtoolsorphan   0 weeks ago
ninja-ide echevemaster, orphan 6 weeks ago
nodejs-array-uniq nodejs-sig, orphan   1 weeks ago
pdc-updater   orphan   1 weeks ago
plaguedcbw, orphan 5 weeks ago
pyqt-mail-checker orphan   1 weeks ago
python-cachy  orphan   2 weeks ago
python-fmn-libinfra-sig, orphan, ralph 0 weeks ago
python-larch  orphan   1 weeks ago
python-mandrill   orphan   1 weeks ago
python-pylev  orphan   2 weeks ago
pywebkitgtk   ivazquez, orphan, walters6 weeks ago
repoview  orphan   1 weeks ago
rubygem-chunky_pngmmorsi, orphan   7 weeks ago
rubygem-codemirror-rails  orphan   6 weeks ago
rubygem-commander maxamillion, orphan, tdawson 4 weeks ago
rubygem-compass-960-pluginorphan   7 weeks ago
rubygem-jquery-ui-rails   orphan   4 weeks ago
rubygem-paranoia  orphan   4 weeks ago
rubygem-webratmmorsi, orphan   7 weeks 

[Bug 1716422] perl-Test-Unit-0.25-32.fc31 FTBFS with perl 5.30: test_numericness test fails on 0xF00

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2019-06-03 14:40:35



-- 
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 1716422] perl-Test-Unit-0.25-32.fc31 FTBFS with perl 5.30: test_numericness test fails on 0xF00

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
External Bug ID||CPAN 129738
   Fixed In Version||perl-Test-Unit-0.25-33.fc31



-- 
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: I plan to remove python2-pep8

[Ben Boeckel]

On Wed, May 15, 2019 at 13:36:42 +0200, Miro Hrončok wrote:
> $ dnf repoquery --repo=compose{,-source} --whatrequires python2-pep8
> cachedir-0:1.4-3.fc28.src

This has now been retired. Sorry for the delays.

--Ben
___
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: Writing C/C++ code to detect running desktop environment

[Germano Massullo]

A dubt about XDG_CURRENT_DESKTOP. Since boinc-client runs as a service
with its own user, I don't think it will be able to read
XDG_CURRENT_DESKTOP defined in other users sessions. Therefore IMHO I
need another kind of solution
___
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 1716422] perl-Test-Unit-0.25-32.fc31 FTBFS with perl 5.30: test_numericness test fails on 0xF00

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|xav...@bachelot.org |ppi...@redhat.com



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

Orphaned packages looking for new maintainers

[Miro Hrončok]

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

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

See this report online at: 
https://churchyard.fedorapeople.org/orphans-2019-06-03.txt


Packages retired today but still in this report:
aeskulap dvdbackup emacs-pymacs gnome-dvb-daemon
gnome-shell-extension-panel-osd rubygem-chunky_png rubygem-compass-960-plugin
rubygem-webrat

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

Package  (co)maintainers   Status Change

aeskulap  orphan   7 weeks ago
apache-commons-discovery  lkundrak, mizdebsk, orphan,  1 weeks ago
  spike
ceph-deploy   branto, fsimonce, ktdreyer,  4 weeks ago
  orphan, trhoden
checkstyledbhole, greghellings, lef,   2 weeks ago
  mizdebsk, nsantos, orphan,
  rmyers
clpbardcantrel, orphan 4 weeks ago
cmdtest   orphan   1 weeks ago
compat-openssl10-pkcs11-helperorphan, rdieter  3 weeks ago
crypto-utils  jorton, orphan   0 weeks ago
dvdbackup cicku, orphan7 weeks ago
emacs-pymacs  orphan   7 weeks ago
fedocal   infra-sig, orphan0 weeks ago
flr   orphan   1 weeks ago
genbackupdata orphan   1 weeks ago
gnome-dvb-daemon  orphan   7 weeks ago
gnome-shell-extension-panel-osd   orphan   7 weeks ago
gnumed-server orphan   1 weeks ago
gpart dcantrel, orphan 4 weeks ago
gscribble orphan   1 weeks ago
h2akurtakov, dchen, lef, orphan4 weeks ago
jwebunit  orphan   3 weeks ago
kimchijcapik, orphan   1 weeks ago
libemuorphan   0 weeks ago
librtfcomporphan   1 weeks ago
loopabull orphan   1 weeks ago
lrbd  orphan   1 weeks ago
ltspfsenslaver, orphan 6 weeks ago
monkeysphere  ctubbsii, orphan 2 weeks ago
mtoolsorphan   0 weeks ago
ninja-ide echevemaster, orphan 6 weeks ago
nodejs-array-uniq nodejs-sig, orphan   1 weeks ago
pdc-updater   orphan   1 weeks ago
plaguedcbw, orphan 5 weeks ago
pyqt-mail-checker orphan   1 weeks ago
python-cachy  orphan   2 weeks ago
python-fmn-libinfra-sig, orphan, ralph 0 weeks ago
python-larch  orphan   1 weeks ago
python-mandrill   orphan   1 weeks ago
python-pylev  orphan   2 weeks ago
pywebkitgtk   ivazquez, orphan, walters6 weeks ago
repoview  orphan   1 weeks ago
rubygem-chunky_pngmmorsi, orphan   7 weeks ago
rubygem-codemirror-rails  orphan   6 weeks ago
rubygem-commander maxamillion, orphan, tdawson 4 weeks ago
rubygem-compass-960-pluginorphan   7 weeks ago
rubygem-jquery-ui-rails   orphan   4 weeks ago
rubygem-paranoia  orphan   4 weeks ago
rubygem-webratmmorsi, orphan   7 weeks 

Re: Replacing glibc langpacks

[Florian Weimer]

* Zbigniew Jędrzejewski-Szmek:

> On Mon, Jun 03, 2019 at 02:59:13PM +0200, Florian Weimer wrote:
>> * Zbigniew Jędrzejewski-Szmek:
>> 
>> > On Mon, May 27, 2019 at 09:13:50PM +0200, Florian Weimer wrote:
>> >> * Tomasz Kłoczko:
>> >> 
>> >> > On Mon, 27 May 2019 at 10:41, Florian Weimer  wrote:
>> >> >> I'm investigating whether it makes sense to switch to a scheme where 
>> >> >> the
>> >> >> glibc locale data is built from source, during package installation,
>> >> >> based on the langpack configuration system.  This is similar to what
>> >> >> Debian does.
>> >> >>
>> >> >> The reason is that the compressed locale source code (without the
>> >> >> charmaps, which are not strictly needed once we patch localedef)
>> 
>> > Can you expand a bit on this part about patch?
>> 
>> localedef currently reads character conversion tables from charmap files
>> under /usr/share/i18n/charmaps.  The same information is contained in
>> the gconv modules unconditionally installed under /usr/lib*/gconv.
>> 
>> > Do I understand correctly, that the saving essentially comes from the fact
>> > that current glibc-langpack-en contains 14 localized variants (AU, BW, ZA,
>> > US, ...), and only a subset of those could be generated in your proposal?
>> > If so, would simply splitting glibc-langpack-en further into subpackages
>> > be an alternative? E.g. glibc-langpack-en-US, glibc-langpack-en-AU,
>> > ... ?
>> 
>> In theory, yes, but that would result in a few dozen more langpack
>> packages.
>> 
>> The other variance is the supported single-byte charset (UTF-8,
>> ISO-8859-1, ISO-8859-15).
>
> Hmm, so maybe that's the way to go: split each langpack into
> glibc-langpack-XX and glibc-langpack-XX-legacy. Not installing -legacy
> will halve the disk usage, no?

This will nearly double the number of langpack packages needed by glibc.
We also use hard links to share identical files across locales—compare
the output of “du -hcs /usr/lib/locale/en_*”, “du -hcsl
/usr/lib/locale/en_*”, “du -hcs /usr/lib/locale/en_US.utf8/” and finally
“du -hcs /usr/lib/locale/en_US{,.utf8}/”.

In short, there's 6.7 MiB today, 2.9 MiB for UTF-8 only, and 3.2 MiB for
UTF-8 and ISO-8859-1.  (I don't think skipping en_US is realistic.)

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Replacing glibc langpacks

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jun 03, 2019 at 02:59:13PM +0200, Florian Weimer wrote:
> * Zbigniew Jędrzejewski-Szmek:
> 
> > On Mon, May 27, 2019 at 09:13:50PM +0200, Florian Weimer wrote:
> >> * Tomasz Kłoczko:
> >> 
> >> > On Mon, 27 May 2019 at 10:41, Florian Weimer  wrote:
> >> >> I'm investigating whether it makes sense to switch to a scheme where the
> >> >> glibc locale data is built from source, during package installation,
> >> >> based on the langpack configuration system.  This is similar to what
> >> >> Debian does.
> >> >>
> >> >> The reason is that the compressed locale source code (without the
> >> >> charmaps, which are not strictly needed once we patch localedef)
> 
> > Can you expand a bit on this part about patch?
> 
> localedef currently reads character conversion tables from charmap files
> under /usr/share/i18n/charmaps.  The same information is contained in
> the gconv modules unconditionally installed under /usr/lib*/gconv.
> 
> > Do I understand correctly, that the saving essentially comes from the fact
> > that current glibc-langpack-en contains 14 localized variants (AU, BW, ZA,
> > US, ...), and only a subset of those could be generated in your proposal?
> > If so, would simply splitting glibc-langpack-en further into subpackages
> > be an alternative? E.g. glibc-langpack-en-US, glibc-langpack-en-AU,
> > ... ?
> 
> In theory, yes, but that would result in a few dozen more langpack
> packages.
> 
> The other variance is the supported single-byte charset (UTF-8,
> ISO-8859-1, ISO-8859-15).

Hmm, so maybe that's the way to go: split each langpack into
glibc-langpack-XX and glibc-langpack-XX-legacy. Not installing -legacy
will halve the disk usage, no?

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

Re: Stale packages in Fedora 30

[Vít Ondruch]

Dne 03. 06. 19 v 5:47 Samuel Sieb napsal(a):
> On 6/2/19 8:35 PM, Chris Murphy wrote:
>> Perhaps related, on an upgraded Fedora 30 system I see
>> ghostscript-fonts-5.50-37.fc27.noarch, which does not appear on any
>> clean installed systems, and also can't be installed (Error: Unable to
>> find a match ). That tells me it's been dropped or is obsolete, so is
>> it normal for such packages to persist through upgrades?
>
> Yes, normally there's nothing to cause it to be removed.  At some
> point you will probably get a conflict when a required library soname
> is bumped and then --allowerasing will remove it.


`dnf autoremove` could help as well.


Vít

___
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: Stale packages in Fedora 30

[Vít Ondruch]

Dne 30. 05. 19 v 20:18 Adam Jackson napsal(a):
> Since I was looking at a copy of the F30 repo for amd64, here's a list
> of a bunch of packages whose dist tag suggests they haven't rebuilt
> successfully in any currently-supported Fedora release. I'm sure some
> of these are incompletely retired or there's otherwise some good reason
> for it, this is just to raise visibility.
>
>
> rubygem-connection_pool-2.2.0-2.fc24.src.rpm


This one ^^ is fun story:

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


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

Re: Modularity tooling intro?

[Vít Ondruch]

I wish the initiative started with something simple like "get
module-build-macros SRPM out of modulemd YAML" [1].


Vít


[1] https://pagure.io/fm-orchestrator/issue/1217



Dne 03. 06. 19 v 10:03 Adam Samalik napsal(a):
> The local module builds we have documented at the moment [1] should
> work if you have an access to the Fedora infrastructure (==internet
> connection) and your packages are in the Fedora dist-git.
>
> I know that Merlin (merlinm) is working on tooling that allow you to
> do local module builds without relying on any external infrastructure,
> basically the way mock works with standalone packages today. He's
> submitted a talk to Flock [2] about it. I know that not everyone can
> attend, but he's probably a good person to talk to, and if his
> proposal gets accepted, there will be a recording. And the docs should
> get updated, too, when it's ready! So.. it's coming
>
> [1] 
> https://docs.fedoraproject.org/en-US/modularity/making-modules/building-modules-locally/
> [2] https://pagure.io/flock/issue/145
>
> On Sat, Jun 1, 2019 at 1:57 PM Jun Aruga  > wrote:
>
> > However, I want to do it on my own
> infrastructure and hence use the lower-level tooling such as
> mbs-manager/mock and local git repos rather than fedpkg/koji/dist-git.
>
> Sorry I missed your above message.
>
> Maybe you can open the ticket at below repository's issue page.
> https://pagure.io/fm-orchestrator
>
> fm-orchestrator repository is including module-build-service, and
> mbs-manager.
>
> I remember "mbs-build local" command worked for the local build in
> late 2017.
> But I could not find the command now.
>
> --
> Jun Aruga / He - His - Him
> ___
> 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
>
>
>
> -- 
>
> Adam Šamalík
> ---
> Senior Software Engineer
> Red Hat
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://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

[Bug 1716422] perl-Test-Unit-0.25-32.fc31 FTBFS with perl 5.30: test_numericness test fails on 0xF00

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

Version|30  |rawhide



-- 
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 1716422] New: perl-Test-Unit-0.25-32.fc31 FTBFS with perl 5.30: test_numericness test fails on 0xF00

[bugzilla]

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

Bug ID: 1716422
   Summary: perl-Test-Unit-0.25-32.fc31 FTBFS with perl 5.30:
test_numericness test fails on 0xF00
   Product: Fedora
   Version: 30
Status: NEW
 Component: perl-Test-Unit
  Assignee: xav...@bachelot.org
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
xav...@bachelot.org
  Target Milestone: ---
Classification: Fedora



perl-Test-Unit-0.25-32.fc31 fails build with perl 5.30 because a test started
to fail:

$ perl -Ilib t/assert.t
STARTING TEST RUN   
1..40   
[...]
ok PASS test_assert_raises

not ok ERROR test_numericness
t/tlib/AssertTest.pm:48 - test_numericness(Class::Inner::__A26)
For string '0xF00', expect f but got t
ok PASS test_fail_assert_null

That's caused by a change in perl. Perl 5.28 handles it as string:

$ perl -e 'print qq{YES\n} if q{0xF00} == 0'
YES

While perl 5.30 handles it as a number:

$ perl -e 'print qq{YES\n} if q{0xF00} == 0'

The failing test has a relevant notice at t/tlib/AssertTest.pm:37:

'0xF00' => 'f', # controversial?  but if you +=10 then it's == 10

-- 
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 1716421] New: perl-Locale-Codes-3.61 is available

[bugzilla]

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

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



Latest upstream release: 3.61
Current version/release in rawhide: 3.60-1.fc31
URL: http://search.cpan.org/dist/Locale-Codes/

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

-- 
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: Replacing glibc langpacks

[Neal Gompa]

On Mon, May 27, 2019 at 5:36 AM Florian Weimer  wrote:
>
> I'm investigating whether it makes sense to switch to a scheme where the
> glibc locale data is built from source, during package installation,
> based on the langpack configuration system.  This is similar to what
> Debian does.
>
> The reason is that the compressed locale source code (without the
> charmaps, which are not strictly needed once we patch localedef) is
> smaller than the subset of locales of a langpack package which people
> actually.  For example, glibc-langpack-en on Fedora 29 is 6.7 MiB when
> installed, but en_US.utf8 is 2.9 MiB, and the locale sources are
> 3.4 MiB, so even the common case realizes a small saving.
>
> For the installer, the savings might be much larger.  If we can teach
> anaconda to generate the appropriate locale only after the user has
> selected the language, then we no longer need the full locale archive in
> the installation image (and in RAM).
>

I'm generally opposed to this because it introduces a scriptlet
requirement fairly early on in the system and I don't consider it to
be significant enough. If we wanted to have savings here, we should
look at encoding finer-grained locale attributes to the files in the
package file list so that rpm locale filters can strip them.

Even without this, I don't think the savings are worth it as you propose.


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

[Bug 1716417] New: perl-Date-Manip-6.77 is available

[bugzilla]

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

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



Latest upstream release: 6.77
Current version/release in rawhide: 6.76-1.fc31
URL: http://search.cpan.org/dist/Date-Manip/

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


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


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


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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Replacing glibc langpacks

[Florian Weimer]

* Zbigniew Jędrzejewski-Szmek:

> On Mon, May 27, 2019 at 09:13:50PM +0200, Florian Weimer wrote:
>> * Tomasz Kłoczko:
>> 
>> > On Mon, 27 May 2019 at 10:41, Florian Weimer  wrote:
>> >> I'm investigating whether it makes sense to switch to a scheme where the
>> >> glibc locale data is built from source, during package installation,
>> >> based on the langpack configuration system.  This is similar to what
>> >> Debian does.
>> >>
>> >> The reason is that the compressed locale source code (without the
>> >> charmaps, which are not strictly needed once we patch localedef)

> Can you expand a bit on this part about patch?

localedef currently reads character conversion tables from charmap files
under /usr/share/i18n/charmaps.  The same information is contained in
the gconv modules unconditionally installed under /usr/lib*/gconv.

> Do I understand correctly, that the saving essentially comes from the fact
> that current glibc-langpack-en contains 14 localized variants (AU, BW, ZA,
> US, ...), and only a subset of those could be generated in your proposal?
> If so, would simply splitting glibc-langpack-en further into subpackages
> be an alternative? E.g. glibc-langpack-en-US, glibc-langpack-en-AU,
> ... ?

In theory, yes, but that would result in a few dozen more langpack
packages.

The other variance is the supported single-byte charset (UTF-8,
ISO-8859-1, ISO-8859-15).

Thansk,
Florian
___
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: I cannot reach Kushal Das

[Miro Hrončok]

On 03. 06. 19 12:20, Peter Robinson wrote:

On Mon, Jun 3, 2019 at 11:15 AM Miro Hrončok  wrote:


Hey, I am trying to get a response from Kushal since March.

I was briefly in e-mail contact with him, but he has stopped responding 
altogether.

Anyone who can help me contact him?

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



He's generally quite responsive on IRC (kushal) or twitter
https://twitter.com/kushaldas


I've just heard back from kushal on IRC. Thanks.

--
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: Stale packages in Fedora 30

[Robert-André Mauchin]

On Thursday, 30 May 2019 20:18:35 CEST Adam Jackson wrote:
> Since I was looking at a copy of the F30 repo for amd64, here's a list
> of a bunch of packages whose dist tag suggests they haven't rebuilt
> successfully in any currently-supported Fedora release. I'm sure some
> of these are incompletely retired or there's otherwise some good reason
> for it, this is just to raise visibility.
> 

All the golang-* packages will be updated as part of moving to new macros.

___
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: Introduction

[Miro Hrončok]

On 03. 06. 19 14:04, Marcel Plch wrote:

Hello,

I am Marcel, on most social networks I use the nickname 'Dormouse759'.
(a translation of my surname plus some numbers, very creative, isn't
it?)

I work for Red Hat in the Python Maintenance team and already
contribute to some bugfixes here on Fedora, though most of my work is
on RHEL currently. I also contribute to upstream, maintain the package
python-libsass and co-maintain cronie, crontabs and at packages.

Mostly I contribute to cpython upstream, fix some well hidden bugs in
larger Python projects or its bindings (Cython, eventlet, gdb etc.)

There also are some projects (mostly planned yet) I have in copr. I
would like to expand these and eventually move them to Fedora to make
my (and hopefully others') workflow easier.

Except for Python, I work also on some C projects.


I have sponsored Marcel to python-sig FAS group, so he can help us with Python 
3.8 rebuilds more comfortably.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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

Introduction

[Marcel Plch]

Hello,

I am Marcel, on most social networks I use the nickname 'Dormouse759'.
(a translation of my surname plus some numbers, very creative, isn't
it?)

I work for Red Hat in the Python Maintenance team and already
contribute to some bugfixes here on Fedora, though most of my work is
on RHEL currently. I also contribute to upstream, maintain the package
python-libsass and co-maintain cronie, crontabs and at packages.

Mostly I contribute to cpython upstream, fix some well hidden bugs in
larger Python projects or its bindings (Cython, eventlet, gdb etc.)

There also are some projects (mostly planned yet) I have in copr. I
would like to expand these and eventually move them to Fedora to make
my (and hopefully others') workflow easier.

Except for Python, I work also on some C projects.
-- 
Marcel Plch
___
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

[Bug 1716374] New: perl-CGI-4.44 is available

[bugzilla]

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

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



Latest upstream release: 4.44
Current version/release in rawhide: 4.43-1.fc31
URL: http://search.cpan.org/dist/CGI/

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

-- 
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: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Panu Matilainen]

On 5/29/19 11:19 PM, Ben Cotton wrote:


* The macro for setting the compression is: %define _binary_payload w19.zstdio
* The recommended compression level is 19. The builds will take
longer, but the additional compression time is negligible in the total
build time and it pays off in better compression ratio than xz lvl2
has.


This is what we always thought with rpmbuild, "no point optimizing 
because it'll just get drowned in the noise". However this has gotten to 
be a hot topic in the last year or so, with people from different 
backgrounds wanting to parallelize various aspects of rpmbuild to speed 
it up.


To that background, going from 9m55s compression time to 24m2s is a 
HORRIBLE regression that will eat away all the gains we just managed to 
scrape by parallelizing new things.


Note that rpm doesn't support parallel zstd compression, and while it 
does for xz, that's not even utilized in Fedora.


To me the sweet spot between compression efficiency and speed seems 
closer to 10 than 19 - yes at a minor loss in space but huge speedup in 
both compress and decompress times.


- 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: Mock - signal reaction

[Kamil Dudka]

On Monday, June 3, 2019 12:18:02 PM CEST Jan Buchmaier wrote:
> Now I'm working on signal SIGTERM handling and I would like to kill all
> processes related to the main mock process.
>  What do you think is it a good
> idea to kill all processes, or do we want to kill the main process only?
> And what about SIGINT so-called KeyInterrupt in python? Same reaction?

Your question is missing some context.  Are you trying to improve signal 
handling in your own code that uses mock, or are you trying to improve
signal handling in the implementation of mock itself?

Kamil

___
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: Stale packages in Fedora 30

[Hans de Goede]

Hi,

On 30-05-19 20:18, Adam Jackson wrote:

Since I was looking at a copy of the F30 repo for amd64, here's a list
of a bunch of packages whose dist tag suggests they haven't rebuilt
successfully in any currently-supported Fedora release. I'm sure some
of these are incompletely retired or there's otherwise some good reason
for it, this is just to raise visibility.



blobwars-1.19-13.fc24.src.rpm


I once maintained this, it seems that Bruno, who took it over,
no longer has time to maintain this.

I'll pick this up again and fix its FTBFS problems.

Regards,

Hans
___
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: Using fedora-active-user: unable to find fedora_cert

[Vít Ondruch]

Dne 30. 05. 19 v 23:50 Adam Williamson napsal(a):
> On Thu, 2019-05-30 at 22:42 +0100, Tom Hughes wrote:
>> On 30/05/2019 22:38, Adam Williamson wrote:
>>
>>> I'd kinda rather there was a standard way for all such things to read
>>> the username from a standard file, because my Fedora username is not my
>>> system username and passing --user or --username or whatever to
>>> everything is a pain.
>> Don't most things look at $FAS_USERNAME for that?
>>
>> There's ~/.fedora.upn as well though I'm not sure what looks
>> at that?
> That's...sorta my whole point. :P Clearly if you can think of two
> mechanisms and you don't know what uses which...there isn't a
> standard...
>
> (I know some things used to look at ~/.fedora.cert to figure it out,
> too).


Don't we have kerberos for Fedora?


Vít
___
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: I cannot reach Kushal Das

[Peter Robinson]

On Mon, Jun 3, 2019 at 11:15 AM Miro Hrončok  wrote:
>
> Hey, I am trying to get a response from Kushal since March.
>
> I was briefly in e-mail contact with him, but he has stopped responding 
> altogether.
>
> Anyone who can help me contact him?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1482953
>

He's generally quite responsive on IRC (kushal) or twitter
https://twitter.com/kushaldas

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

Mock - signal reaction

[Jan Buchmaier]

Now I'm working on signal SIGTERM handling and I would like to kill all 
processes related to the main mock process.
What do you think is it a good idea to kill all processes, or do we want to 
kill the main process only?
And what about SIGINT so-called KeyInterrupt in python? Same reaction?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

I cannot reach Kushal Das

[Miro Hrončok]

Hey, I am trying to get a response from Kushal since March.

I was briefly in e-mail contact with him, but he has stopped responding 
altogether.

Anyone who can help me contact him?

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

Thanks,
--
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: Intent to drop python2-tornado

[Miro Hrončok]

On 27. 05. 19 10:54, Miro Hrončok wrote:

On 20. 05. 19 11:26, Miro Hrončok wrote:

I intend to drop python2-tornado. There are following dependent packages:

- python-httpretty
 build time, for Python 2 tests, tests can be disabled

- python-pika
 build time, for Python 2 tests, one file can be skipped

- python-urllib3
 build time, for Python 2 tests, tests can be disabled

- salt (and salt-{api,cloud,syndic,ssh,master,minion})
 runtime, python 3 switch is blocked by a fixable bug
 https://github.com/saltstack/salt/issues/51883
 salt is not required by anything

- uwsgi-plugin-python2-tornado (from uwsgi)
 runtime, but not required by anything

- bup and bup-web
 runtime and buildtime, but not required by anything


https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Removing_Python_2_parts 



7 days have passed.

$ repoquery --repo=rawhide{,-source} --whatrequires python2-tornado
bup-0:0.29.2-3.fc30.src
bup-web-0:0.29.2-3.fc30.x86_64
python-httpretty-0:0.9.5-5.fc30.src
python-pika-0:1.0.1-1.fc31.src
python-urllib3-0:1.24.2-1.fc31.src
salt-0:2019.2.0-1.fc31.noarch
uwsgi-plugin-python2-tornado-0:2.0.17.1-10.fc31.x86_64

If anybody wants to package python2-tornado before we drop it, let me know in 2
weeks.


Another 7 days have passed.

$ repoquery --repo=rawhide{,-source} --whatrequires python2-tornado
bup-0:0.29.2-3.fc30.src
bup-web-0:0.29.2-3.fc30.x86_64
python-httpretty-0:0.9.5-5.fc30.src
salt-0:2019.2.0-1.fc31.noarch
uwsgi-plugin-python2-tornado-0:2.0.17.1-10.fc31.x86_64

If anybody wants to package python2-tornado before we drop it, let me know in 1 
week.



Reasons below:

 Forwarded Message 
Subject: Let's update tornado to 6 and drop python2-torando
Date: Wed, 15 May 2019 16:57:57 +0200
From: Miro Hrončok 
Reply-To: Fedora Python SIG 
Organisation: Red Hat
To: Fedora Python SIG , 
abomp...@fedoraproject.org, or...@fedoraproject.org, toms...@fedoraproject.org


Hi.

Tornado 6 doesn't support Python 2. Let's update the python-torando package to 
Python 3 only. There are several consumers of python2-torando and if their 
maintainers are interested, they can package it separately.


$ dnf repoquery --repo=compose{,-source} --whatrequires python2-tornado
bup-0:0.29.2-3.fc30.src
bup-web-0:0.29.2-3.fc30.x86_64
python-httpretty-0:0.9.5-5.fc30.src
python-pika-0:1.0.1-1.fc31.src
python-urllib3-0:1.24.2-1.fc31.src
salt-0:2019.2.0-1.fc31.noarch
uwsgi-plugin-python2-tornado-0:2.0.17.1-10.fc31.x86_64

Note that tornado is often used to test things. We can (and should) just skip 
such tests from Python 2 httpretty, pika and urllib3.


Is the plan OK? I'll talk to the dependent packages maintainers, but wanted to 
check with torando co-maintainers first.






--
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 1715909] perltidy-20190601 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perltidy-20190601-1.fc31
 Resolution|--- |RAWHIDE
Last Closed||2019-06-03 09:56:16



--- Comment #2 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=35246229

-- 
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: Announcing Fedora CI SIG

[Aleksandra Fedorova]

On Tue, May 28, 2019 at 12:15 PM Aleksandra Fedorova  wrote:
>
> Hi, all,
>
> I created a poll for the meeting time http://whenisgood.net/kdd4zmq
> Please add you votes.

As we have nonoverlapping meeting requirements, making it work for
everyone is impossible. Let's choose the

   Wednesday 5 June 6:00 p.m. Central European Time (16:00 UTC) [1]

to start with.

For everyone who is not going to make it for the meeting: you can add
your projects on the wiki page [2], introduce yourself on the CI
mailing list [3], or drop me a mail describing the topic you would
like me to raise during the meeting.

[1] 
http://whenisgood.net/ResultsPopup?event=kdd4zmq=h8hrzmp=155975040
[2] https://fedoraproject.org/wiki/SIGs/CI#Projects
[3] https://lists.fedorahosted.org/archives/list/c...@lists.fedoraproject.org/

-- 
Aleksandra Fedorova
bookwar
___
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 1716324] New: perl-Text-Xslate-3.5.6-5.fc30 is not linked to libperl.so

[bugzilla]

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

Bug ID: 1716324
   Summary: perl-Text-Xslate-3.5.6-5.fc30 is not linked to
libperl.so
   Product: Fedora
   Version: 30
Status: NEW
 Component: perl-Text-Xslate
  Assignee: jples...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: i...@cicku.me, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



perl-Text-Xslate-3.5.6-5.fc30 lost a dependency on libperl.so since
-Wl,--as-needed was added to distribution-wide linker flags:

$ scanelf -n blib/arch/auto/Text/Xslate/Xslate.so 
 TYPE   NEEDED FILE 
ET_DYN libc.so.6 blib/arch/auto/Text/Xslate/Xslate.so 

$ ldd -r  blib/arch/auto/Text/Xslate/Xslate.so
linux-vdso.so.1 (0x7fff0d5cb000)
libc.so.6 => /lib64/libc.so.6 (0x7f948b9a1000)
/lib64/ld-linux-x86-64.so.2 (0x7f948bb8f000)
undefined symbol: Perl_sv_cmp   (blib/arch/auto/Text/Xslate/Xslate.so)
undefined symbol: PL_ppaddr (blib/arch/auto/Text/Xslate/Xslate.so)
[...]

Xslate.so is built like this:

gcc -lpthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib
-fstack-protector-strong -lperl -o blib/arch/auto/Text/Xslate/Xslate.so
lib/Text/Xslate.o src/xslate_methods.o

The cause is that -Wl,--as-needed takes effect when library is supplied and
considering only preceding object files and ignoring and following object
files. A correct linker command must list all object files before -l flags.
Like this:

gcc lib/Text/Xslate.o src/xslate_methods.o -lpthread -shared -Wl,-z,relro
-Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-L/usr/local/lib -fstack-protector-strong -lperl -o
blib/arch/auto/Text/Xslate/Xslate.so

Either there is bug in perl-Text-Xslate build script or in
Module::Build::XSUtil that it uses.

-- 
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: Modularity tooling intro?

[Adam Samalik]

The local module builds we have documented at the moment [1] should work if
you have an access to the Fedora infrastructure (==internet connection) and
your packages are in the Fedora dist-git.

I know that Merlin (merlinm) is working on tooling that allow you to do
local module builds without relying on any external infrastructure,
basically the way mock works with standalone packages today. He's submitted
a talk to Flock [2] about it. I know that not everyone can attend, but he's
probably a good person to talk to, and if his proposal gets accepted, there
will be a recording. And the docs should get updated, too, when it's ready!
So.. it's coming

[1]
https://docs.fedoraproject.org/en-US/modularity/making-modules/building-modules-locally/
[2] https://pagure.io/flock/issue/145

On Sat, Jun 1, 2019 at 1:57 PM Jun Aruga  wrote:

> > However, I want to do it on my own
> infrastructure and hence use the lower-level tooling such as
> mbs-manager/mock and local git repos rather than fedpkg/koji/dist-git.
>
> Sorry I missed your above message.
>
> Maybe you can open the ticket at below repository's issue page.
> https://pagure.io/fm-orchestrator
>
> fm-orchestrator repository is including module-build-service, and
> mbs-manager.
>
> I remember "mbs-build local" command worked for the local build in late
> 2017.
> But I could not find the command now.
>
> --
> Jun Aruga / He - His - Him
> ___
> 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
>


-- 

Adam Šamalík
---
Senior Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Replacing glibc langpacks

[Zbigniew Jędrzejewski-Szmek]

On Mon, May 27, 2019 at 09:13:50PM +0200, Florian Weimer wrote:
> * Tomasz Kłoczko:
> 
> > On Mon, 27 May 2019 at 10:41, Florian Weimer  wrote:
> >> I'm investigating whether it makes sense to switch to a scheme where the
> >> glibc locale data is built from source, during package installation,
> >> based on the langpack configuration system.  This is similar to what
> >> Debian does.
> >>
> >> The reason is that the compressed locale source code (without the
> >> charmaps, which are not strictly needed once we patch localedef)
Can you expand a bit on this part about patch?

> >> smaller than the subset of locales of a langpack package which people
> >> actually.  For example, glibc-langpack-en on Fedora 29 is 6.7 MiB when
> >> installed, but en_US.utf8 is 2.9 MiB, and the locale sources are
> >> 3.4 MiB, so even the common case realizes a small saving.
> >>
> >> For the installer, the savings might be much larger.  If we can teach
> >> anaconda to generate the appropriate locale only after the user has
> >> selected the language, then we no longer need the full locale archive in
> >> the installation image (and in RAM).
> >
> > In other words your proposition is *not* about not any kind of
> > reduction size but increase size of installed resources because those
> > binary files which needs to be present will be increased by source of
> > those binary files. Other thing is that generating those files on
> > install-time elongates install time.
> 
> 2.9 MiB (compiled en_US.utf8 locale) plus 3.4 MiB (compressed locale
> sources without charmaps) is 6.3 MiB, which is less than 6.7 MiB
> (current installed glibc-langpack-en size).

Hmm, the tradeoff is not very convincing: doing install-time shenanigans
to save 400k doesn't seem like a great deal.

Do I understand correctly, that the saving essentially comes from the fact
that current glibc-langpack-en contains 14 localized variants (AU, BW, ZA,
US, ...), and only a subset of those could be generated in your proposal?
If so, would simply splitting glibc-langpack-en further into subpackages
be an alternative? E.g. glibc-langpack-en-US, glibc-langpack-en-AU, ... ?

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

Re: Perl 5.30 upgrade

[Jitka Plesnikova]

On 5/30/19 8:16 AM, Jitka Plesnikova wrote:
> Hello,
>
> Perl 5.30 was released on May 22 2019 and Perl 5.30 change is almost
> approved by FESCo [1].
>
> I have required `f31-perl' build-root for this purpose [2] and it was
> created.
>
> To prevent possible conflict with Python 3.8 rebuild, I start the
> rebuild today
> and you can be notified via mail about commits/builds in next days.
> The merge to rawhide won't be done before approving changes by FESCo.
>
> Please do not build anything into `f31-perl'. Boot-strapping core modules
> is very peculiar. I also track all changes. You can do your upgrades into
> rawhide freely in parallel.
>
> You can check status on Perl 5.30 change page [3]
>
> Regards,
> Jitka Plesnikova
>
> [1] https://pagure.io/fesco/issue/2134
> [2] https://pagure.io/releng/issue/8384
> [3] https://fedoraproject.org/wiki/Changes/perl5.30#Current_Status
>
We have successfully built all packages except 14 of them. I requested to
merge f31-perl tag back into f31 tag
https://pagure.io/releng/issue/8384#comment-573592 recently. Once rel-engs
do that, Perl 5.30.0 will become available in Fedora 31. If you built your
Perl package in the mean time, you would have to rebuild your package after
the merge again.

Regards,
Jitka

-- 
Jitka Plesnikova
Software Engineer
Red Hat

___
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: Stale packages in Fedora 30

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jun 02, 2019 at 08:47:34PM -0700, Samuel Sieb wrote:
> On 6/2/19 8:35 PM, Chris Murphy wrote:
> >Perhaps related, on an upgraded Fedora 30 system I see
> >ghostscript-fonts-5.50-37.fc27.noarch, which does not appear on any
> >clean installed systems, and also can't be installed (Error: Unable to
> >find a match ). That tells me it's been dropped or is obsolete, so is
> >it normal for such packages to persist through upgrades?
> 
> Yes, normally there's nothing to cause it to be removed.  At some
> point you will probably get a conflict when a required library
> soname is bumped and then --allowerasing will remove it.

Exactly. We have fedora-obsolete-packages to gather Obsoletes which don't
fit anywhere else, but there's no policy to require all packages which
have become obsolete to be added there.

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