Re: koji build fails on arch armv7hl

[Martin Gansser]

always same behaviour

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=41489282
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=41489285

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

Re: Signal 4 (ILL) caught by ps in mock

[Petr Pisar]

On Thu, Feb 13, 2020 at 07:48:22PM -0700, Christoph Junghans wrote:
> when running "mock -r fedora-rawhide-ppc64le --no-clean
> gromacs-2019.5-2.fc32.1.src.rpm"
> I am getting the following error:
> Signal 4 (ILL) caught by ps (3.3.15).
> /usr/bin/ps:ps/display.c:66: please report this bug
> 
> I tried a couple of different src.rpm with the same result.
> This is mock 1.4.21 on f31.
> 
> Has anybody else seen this?
> 
Not exactly, but if you check Koji build history for gromacs package
. You will
find out that the build failed during F32 mass rebuild
 on ppc64le and
aarch64. The ppc64le failure is:

-- Performing Test CXX_mvsx_COMPILE_WORKS - Failed
-- Flag was accepted, but it did not build test source (this could be due to 
either the compiler or binutils)
-- Performing Test CXX_maltivec_mabi_altivec_FLAG_ACCEPTED
-- Performing Test CXX_maltivec_mabi_altivec_FLAG_ACCEPTED - Success
-- Performing Test CXX_maltivec_mabi_altivec_COMPILE_WORKS
-- Performing Test CXX_maltivec_mabi_altivec_COMPILE_WORKS - Failed
-- Flag was accepted, but it did not build test source (this could be due to 
either the compiler or binutils)
-- Performing Test CXX_qarch_auto_qaltivec_FLAG_ACCEPTED
-- Performing Test CXX_qarch_auto_qaltivec_FLAG_ACCEPTED - Failed
-- Performing Test CXX_COMPILE_WORKS_WITHOUT_SPECIAL_FLAGS
-- Performing Test CXX_COMPILE_WORKS_WITHOUT_SPECIAL_FLAGS - Failed
-- Could not find any flag to build test source (this could be due to either 
the compiler or binutils)
CMake Error at cmake/gmxManageSimd.cmake:51 (message):
  Cannot find IBM VSX compiler flag.  Use a newer compiler, or disable SIMD
  support (slower).
Call Stack (most recent call first):
  cmake/gmxManageSimd.cmake:265 
(gmx_give_fatal_error_when_simd_support_not_found)
  CMakeLists.txt:719 (gmx_manage_simd)
-- Configuring incomplete, errors occurred!
See also 
"/builddir/build/BUILD/gromacs-2019.5/serial/CMakeFiles/CMakeOutput.log".
See also 
"/builddir/build/BUILD/gromacs-2019.5/serial/CMakeFiles/CMakeError.log".

Koschei history  claims the
build started to fail with these changes
. It's probably a triggered by
an upgrade of GCC to 10 version.

SIGILL means the processor met an instruction it does not understand.

In your case procps-ng package seems to be miscompiled (or run on an
incopatible hardware). I recommend getting a shell in the mock enviroment
(mock --shell) and investigeting whether the ps program works there).

My gut feeling is that GCC 10 started to omit new instructions and your
hardware is not compatible with them. Can you reproduce it on one of these
machines
?

-- Petr


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

Fedora-Cloud-30-20200214.0 compose check report

[Fedora compose checker]

No missing expected images.

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

[EPEL-devel] Haskell environment in EPEL 8

[Mark Stopka]

Hi,
is anybody working on Haskell environment for EPEL 8? If not, what would be
the process for me to take ownership of those packages? They were available
in EPEL 6 and 7...
--
Best regards / S pozdravem,
BSc. Mark Stopka, BBA

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

Subject: Self Introduction: Sourabh Jain

[Sourabh Jain014]

Hello All,My name is Sourabh Jain and I am new to the packaging world.I have been a Fedora consumer for almost a decade and now I am really excitedto work with the community.My primary job involves a contribution to Linux RAS (Reliability Accessibility and Serviceability)feature and I also write tools that help to simplify the usage of Linux RAS utilities.Lately, I have introduced a python-based framework named ServiceReport that help to configureFirst Failure Data Configuration (FFDC). FFDC is one of the components of RAS whichdeal with collecting the system-related logs/data that will help developers to debug the problemthat leads the system to an invalid state.ServiceReport GitHub repo: https://github.com/linux-ras/ServiceReportIn the process of developing and delivering the ServiceReport to our internal teams, I did learnpython way of build rpm packages using setuptools package. This leads to a question regardingthe fedora package build ecosystem.Can I use python setuptools to build ServiceReport package for Fedora or I need to shift to the .spec and make model?Thanks very much, looking forward to know the community more.Best,Sourabh Jain
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[rpms/perl-Encode-Detect] PR #1: Remove old cruft

[James Ralston]

ralston commented on the pull-request: `Remove old cruft` that you are 
following:
``
Yes; merged. Thanks.

(I typically clean up the spec file whenever I rebase to the latest version of 
a package, but there hasn't been a new version of this perl module in… well, 
forever, basically.)
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Encode-Detect/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[rpms/perl-Encode-Detect] PR #1: Remove old cruft

[James Ralston]

ralston merged a pull-request against the project: `perl-Encode-Detect` that 
you are following.

Merged pull-request:

``
Remove old cruft
``

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

Re: How to get proper nsswitch.conf?

[Chris Murphy]

On Thu, Feb 13, 2020 at 6:20 PM Michael Catanzaro  wrote:
>
> On Thu, Feb 13, 2020 at 1:22 pm, Chris Murphy 
> wrote:
> > hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
>
> Why don't we have mymachines here?

It probably should be in the second position. Also needs insertion in
passwd: and group:
https://www.freedesktop.org/software/systemd/man/nss-mymachines.html

I'm not noticing any difference in latency using mdns_minimal and mdns4_minimal.


On second glance, this is confusing:

# Generated by authselect on Fri Sep 20 09:47:27 2019
# Do not modify this file manually.

However...

$ stat /etc/nsswitch.conf
  File: /etc/nsswitch.conf
  Size: 2402  Blocks: 8  IO Block: 4096   regular file
Device: 23h/35dInode: 2589745 Links: 1
Access: (0644/-rw-r--r--)  Uid: (0/root)   Gid: (0/root)
Context: system_u:object_r:etc_t:s0
Access: 2020-02-12 14:14:39.753698198 -0700
Modify: 2020-01-26 23:51:27.028724897 -0700
Change: 2020-02-12 14:14:40.658698145 -0700
 Birth: 2020-01-26 23:51:27.025724840 -0700

Generated by authselect, non-locally? I'm not modifying this file.


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

[389-devel] 389 DS nightly 2020-02-14 - 97% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/02/14/report-389-ds-base-1.4.3.3-20200214git776c6ed.fc31.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Signal 4 (ILL) caught by ps in mock

[Christoph Junghans]

Hi,

when running "mock -r fedora-rawhide-ppc64le --no-clean
gromacs-2019.5-2.fc32.1.src.rpm"
I am getting the following error:
Signal 4 (ILL) caught by ps (3.3.15).
/usr/bin/ps:ps/display.c:66: please report this bug

I tried a couple of different src.rpm with the same result.
This is mock 1.4.21 on f31.

Has anybody else seen this?

Christoph

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

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c3bf4a8f31   
php-horde-Horde-Data-2.1.5-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-06ccd2148b   
tomcat-7.0.99-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-42e4c7d470   
mbedtls-2.7.13-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-dd6b868b6d   
pam_radius-1.4.0-4.el6


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

php-fedora-autoloader-1.0.1-2.el6

Details about builds:



 php-fedora-autoloader-1.0.1-2.el6 (FEDORA-EPEL-2020-525009c3ae)
 Fedora Autoloader

Update Information:

## 1.0.1 (2020-02-12)  * Change `Autoload::loadClass()` to return if found
([#19](https://github.com/php-fedora/autoloader/pull/19))

ChangeLog:

* Wed Feb 12 2020 Shawn Iwinski  - 1.0.1-2
- Add tests bootstrap to fix EPEL6 build
* Wed Feb 12 2020 Shawn Iwinski  - 1.0.1-1
- Update to 1.0.1 (RHBZ #1802372)
* Thu Jan 30 2020 Fedora Release Engineering  - 
1.0.0-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
* Fri Jul 26 2019 Fedora Release Engineering  - 
1.0.0-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
* Sat Feb  2 2019 Fedora Release Engineering  - 
1.0.0-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
* Tue Dec  4 2018 Remi Collet  - 1.0.0-5
- cleanup for EL-8
* Fri Jul 13 2018 Fedora Release Engineering  - 
1.0.0-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Fri Feb  9 2018 Fedora Release Engineering  - 
1.0.0-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Thu Jul 27 2017 Fedora Release Engineering  - 
1.0.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild

References:

  [ 1 ] Bug #1802372 - php-fedora-autoloader-1.0.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1802372


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

[Bug 1757318] Request to build perl-REST-Client for EPEL 8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-REST-Client-273-15.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-47af0d3cb1

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

[Bug 1802773] perl-Sys-Mmap-0.20 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-552ee1dcf5 has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-552ee1dcf5

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

Orphaning llvm8.0 and clang8.0 compatibility packages

[Tom Stellard]

Hi,

I am orphaning the llvm8.0 and clang8.0 compatibility packages.

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

Re: How to get proper nsswitch.conf?

[Michael Catanzaro]

On Thu, Feb 13, 2020 at 1:22 pm, Chris Murphy  
wrote:

hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname


Why don't we have mymachines here?

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

Re: infrastructure problem: koji and bodhi responding very slow / dl with 80kb/s

[Artem Tim]

Same here. I am waiting several minutes for every my action. This is very 
unproductive.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaned appframework

[Omair Majid]

Hi,

I have just orphaned appframework:

https://src.fedoraproject.org/rpms/appframework

This package was failing to build in rawhide because one of its
dependencies, swing-layout was orphaned and removed. Unfortunately, I
don't have the time or interest to take over and maintain swing-layout.

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: infrastructure problem: koji and bodhi responding very slow / dl with 80kb/s

[Kevin Fenzi]

On Thu, Feb 13, 2020 at 11:46:00PM +0100, Robert-André Mauchin wrote:
> I don't have any issue with Bodhi, but Koji is extremely slow for me too, it 
> isn't a bandwidth problem but the time the server takes to answer a page 
> request is always several minutes, which makes it excruciatingly annoying 
> when 
> trying to get logs for a failed build.

Feel free to open a ticket if you can get us exact pages / load times? 

Perhaps it's something specific to the packages? 

My failed builds load pretty quickly here... 

kevin


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

Re: infrastructure problem: koji and bodhi responding very slow / dl with 80kb/s

[Robert-André Mauchin]

On Thursday, 13 February 2020 18:18:03 CET Kevin Fenzi wrote:
> On Thu, Feb 13, 2020 at 03:31:26PM +0100, Marius Schwarz wrote:
> > Hi,
> > 
> > while testing ff 73 update, i noticed that bodhi and koji are sponding
> > very slow. The download speed at koji for germany was around 80KB/s,
> > while other parts of the country reached MB/s easily. 
> > 
> > As bodhi does not have that much html to transfer, i don't think it's a
> > network issue.
> 
> I haven't seen any other reports and it's very fast here.
> 
> Do note that koji and bodhi are both things that are in one place: our
> main datacenter in phx2 (arizona, usa). They aren't distributed.
> So, I suspect it _is_ network between there and you.
> 
> Unfortunately, I am not sure there's too much we can do about it.
> If it's some upstream network issue we can try and talk to providers,
> but we seldom have any luck getting them to do anything.
> 
> We are going to be moving from the phx2 datacenter to another facility
> in virgina, usa later this year. I have no idea if that will improve
> things for you though. ;(
> 
> For koji downloads (those things that use kojipkgs.fedoraproject.org) we
> might be able to setup amazon cloudfront, that would help with those.
> 
> > Could someone from the infrastructure team take a look at your dashboards?
> 
> Do please note that if you hit an infrastructure problem, it's really
> best to open a infrastructure ticket, not post to devel list (which we
> read in our spare time):
> 
> https://pagure.io/fedora-infrastructure/issues
> 
> Sorry I couldn't be of more help...
> 
> kevin

I don't have any issue with Bodhi, but Koji is extremely slow for me too, it 
isn't a bandwidth problem but the time the server takes to answer a page 
request is always several minutes, which makes it excruciatingly annoying when 
trying to get logs for a failed build.

Best regards,

Robert-André

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

Re: deduplicating noarch subpackages

[Nicolas Mailhot via devel]

Le jeudi 13 février 2020 à 12:00 -0800, Josh Stone a écrit :
> On 2/13/20 11:26 AM, Nicolas Mailhot wrote:
> > Le jeudi 13 février 2020 à 09:59 -0800, Josh Stone a écrit :
> > > 
> > It is so black and white. If you can not produce bit-perfect
> > identical
> > builds, don’t try to make the result noarch.
> 
> AIUI, there's no requirement that noarch has to be perfectly
> reproducible -- Koji explicitly ignores file size and checksum.

Right, out infra has some loopholes right now, they allow the kind of
breakage that the reproducible build people try to erradicate

Anyway, sorry about the tone, I should not answer while battling
upstream breakage.

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

Re: Invalid body, keys: sls missing

[Fabio Valentini]

On Thu, Feb 13, 2020 at 7:41 PM Ben Rosser  wrote:
>
> On Thu, Feb 13, 2020 at 12:01 PM Jerry James  wrote:
> >
> > I'm trying to get an f32 branch for a newly created package.  Branch
> > creation has failed twice now with the error in $SUBJECT:
> >
> > https://pagure.io/releng/fedora-scm-requests/issue/22127
> >
> > Can I get a human to look at that ticket instead of whatever
> > automation it is that keeps closing it without actually accomplishing
> > the requested task?  Thanks,
> > --
> > Jerry James
> > http://www.jamezone.org/
>
> The same thing just happened to me with a f32 branch request as well:
> https://pagure.io/releng/fedora-scm-requests/issue/22140
>
> Ben

From the error message, it looks like the branch creation tooling
hasn't been updated for the f32 branch point - so it treats f32 as an
"arbitrary branch", where you need to specify service levels (SLs).
But that's just my guess.

Fabio

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

Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers

[Chris Murphy]

On Thu, Feb 13, 2020 at 12:53 PM David Cantrell
 wrote:

> > Similarly, a package with a medium CVE NEW bugzilla would be orphaned after 
> > 4
> > reminders (after 9-12 weeks), retired at a point if still not CLOSED after 
> > 4 months.
> >
> > With low severity, that is 6 reminders (after 15-18 weeks), retired at a 
> > point
> > if still not CLOSED after 6 months (similarly to the current policy).
>
> Where do get bug severity information?

Fedora Workstation WG has an issue "Reconsider updates policy" that
relates to this question.
https://pagure.io/fedora-workstation/issue/107

If there are any security updates, GNOME Software pops up a
notification to install them. This thwarts attempts to avoid nagging
the user, because so many updates contain some sort of security
mitigation. One proposal is to not treat security updates as special,
and still wait until a week has passed for the update.

But the contra argument is, well what if there is an urgent security fix?

The repo metadata, I guess, needs some way of distinguishing urgent vs
non-urgent security updates, so that GNOME Software knows whether to
notify the user accordingly. But is there a reliable way of
distinguishing between urgent and non-urgent security updates? I'd
informally suggest "urgent" is something that should be applied today
or tomorrow. Anything else can wait a week or two.


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

Re: How to get proper nsswitch.conf?

[Chris Murphy]

On Thu, Feb 13, 2020 at 11:17 AM Michael Catanzaro  wrote:
>
> On Thu, Feb 13, 2020 at 5:25 pm, Florian Weimer 
> wrote:
> > authselect is not the only package editing nsswitch.conf, other
> > packages
> > do it as well.  I have lost track.
>
> It'd be really good to know what else is doing this, because I have a
> pending change proposal that's going to require editing this file, and
> I had only been planning to modify the glibc and authselect packages.

dnf provides on workstation fc31 says it's owned by
glibc-2.30-5.fc31.x86_64

(was installed clean but has been used and update for some months since)

hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname

My understanding:
- avahi/mdns will only resolve IPv4 and only if the name ends with
.local, and then will be reported as not found; being able to resolve
IPv6 would be nice but I read that this can be slow, hence
mdns4_minimal and not mdns_minimal; but maybe this information is
stale?
- manpage for nss-resolve says that [!UNAVAIL=return] is required for
resolved, but ..
- I've read elsewhere systemd-resolved contains mdns resolving that I
think needs to be disabled if avahi will be used [2] or otherwise
disable avahi.

[1]
https://www.freedesktop.org/software/systemd/man/nss-resolve.html
[2]
https://wiki.archlinux.org/index.php/Systemd-resolved
"Note: If Avahi has been installed, consider disabling ... "

Anyway, I'm sorta confused.


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

Re: What is "FuturWarning" while calling fifloader.py ?

[Adam Williamson]

On Tue, 2020-02-11 at 09:55 -0800, Adam Williamson wrote:
> On Tue, 2020-02-11 at 15:38 +0100, Normand wrote:
> > Hello Adam,
> > 
> > I am starting to use locally the fifloader.py and templates.fif.json
> > 
> > Is the "FuturWarning" message something to be worked on ? Is it 
> > something you also have in your openQA servers ?
> > ===
> > $./fifloader.py -w --filename xx.upstream templates.fif.json
> > /usr/lib/python3.7/site-packages/jsonschema/_validators.py:200: 
> > FutureWarning: Possible nested set at position 7
> >not re.search(patrn, instance)
> > Input template data is valid
> > Generated template data is valid
> > ===
> 
> It's a thing to be worked on, but it's not in our code - look where the
> line reference is, it's in the jsonschema module. I actually keep
> meaning to look at it and see if there's a patch upstream to backport
> to Fedora, or else send one upstream - I just haven't got around to it
> yet.
> 
> It's just a deprecation warning for now, it doesn't mean anything's
> broken.

Filed an issue upstream:

https://github.com/Julian/jsonschema/issues/659
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org

Re: deduplicating noarch subpackages

[Josh Stone]

On 2/13/20 11:26 AM, Nicolas Mailhot wrote:
> Le jeudi 13 février 2020 à 09:59 -0800, Josh Stone a écrit :
>>
>> It's not so black and white. In theory, the only thing that should
>> matter is the target triple, but the metadata also hashes the
>> metadata
>> of all its build dependencies. That in turn may include procedural
>> macros (essentially compiler plugins) which are host binaries. The
>> end
>> result for the target should be the same, but it's a real concern for
>> upstream that ignoring the host would break caching that relies on
>> filename differences.
> 
> It is so black and white. If you can not produce bit-perfect identical
> builds, don’t try to make the result noarch.

AIUI, there's no requirement that noarch has to be perfectly
reproducible -- Koji explicitly ignores file size and checksum.

> Neither koji, nor auditors, nor other third parties, can be expected to
> check binary differences for you, and identify what differences matter
> and what differences do not matter.
> 
> Neither koji, nor auditors, nor other third parties, can be expected to
> trust that you did this checking for every single build that differs.
> 
> The *only* sane check strategy is a black and white equal/inequal test.
> 
> And you can not handwave those concerns aways because you feel your
> builds should be noarch (feeling is not implementable in software).

I'm not waving it away. Believe it or not, I actually do understand the
impact here.

> When you write
> 
>> it's a real concern for upstream that ignoring the host would break
>> caching
> 
> you are writing that upstream thinks the result is archful (because if
> it actually were noarch, it would be perfectly fine to substitute one
> build output for another, and there would be no caching concerns).

If you read that upstream PR, you might understand my comment about
caching better, and see that I'm also trying to find a better solution
for those concerns.

> The proof is in the pudding. noarch → binary differences do not matter,
> they can be removed during the build process, and koji will be happy.
> archful → removing differences will break something.
> 
> And, removing differences does not necessarily mean removing things.
> The reproducible build project didn’t remove timestamps. It just made
> sure the same timestamp would be used for all builds.
> 
> Regards,
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers

[David Cantrell]

> On Thu, Jan 30, 2020 at 08:39:05AM +0530, Huzaifa Sidhpurwala wrote:
> 
> Maybe?
> 
> The problem with this analysis is we don't know how many of these are
> actual current security issues, and of those how many are > low impact
> (because honestly low impact security issues should just be ignored).
> 
> We have a security team which is very rigorous about filing bugs for
> every CVE, which is a great thing.  However we don't have an automated
> system for clearing up bugs which are naturally fixed through rebases.

An automated system to reconcile open security bugs with current shipping 
packages sure would be handy.

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

Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers

[David Cantrell]

> On 1/30/20 8:32 AM, Kevin Kofler wrote:
> Issues which are blocking on upstream, will eventually get resolved once
> upstream figures out a solution in some time, maybe with subsequent rebases.

Which is fine.  Should Fedora in the meantime ship known vulnerable software?  
But the point, if I understand correctly, is valid.  We don't want to 
automatically assume security bugs are being ignored.  They could be waiting on 
upstream.  So maybe this requires a different categorization where 
bugs/packages can be in a parked state while we wait on upstream?  This would 
help communicate that the issue is being dealt with to the casual BZ viewer.

> If
> fixing security issues is extra work for packagers, then we are doing
> something wrong here. What percentage of security flaws will be
> closed:upstream? Why do we drop other fixes for such issues and
> eventually end up having tons of pending fixes.

For Fedora I think the majority of security bugs will be resolved via a new 
upstream release.  There are situations where we are also the upstream for the 
project we're packaging, and often times that can be the same person doing the 
upstream work and the packaging.  For these cases I think communicating that 
work is being done is more important.

> Do we want to continue the same condition as described here:
> https://mivehind.net/2020/01/28/Fedora-has-too-many-security-bugs/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers

[David Cantrell]

> Hello, Fedora has an approved security policy since September 2018 [0]:
> 
> 
> I have decided to have a look into this, since this has been approved more 
> than 
> a year ago and nothing ever happened since. Fedora has a very big pile of 
> open 
> CVE bugzillas [2].
> 
> There are several things I'd like us to consider based on the experience from 
> the FTBFS policy adjustments [1] before I go implement stuff:
> 
> 
> A. It's easier to **orphan** packages soon, retire later -- this allows the 
> dependent package owners  to notice the breakage and possibly adopt the 
> packages 
> themselves if needed while gives very little room for "cheating".
> 
> B. Getting this done on a certain point in the release schedule is 
> complicated 
> and requires a lot of  planning and focus -- if we miss the window, nothing 
> can 
> change until the next release. We have missed the window 3 times already.
> 
> C. Also because of the fixed date, the CRITICAL or IMPORTANT security issues 
> have no response time, if you get a new one at a certain point, the package 
> is 
> immediately treated as problematic, while getting it 1 day later, there is a 
> 6 
> month period where no action is required.

I like the main idea here, but one concern I have is the categorization of 
these packages.  Should we consider a separate type of orphan group for these 
packages or even a subset.  I'm thinking about the type of package where 
someone contributed it, maybe updated it once or twice, and then it has seen 
not activity for a long time.  Now it has a security update.  This package is 
not critical to the system but has a reasonable number of users who may or may 
not be impacted if it's removed.  The original contributor is no longer 
interested in maintaining it.

Then there's the type of package that is high profile for the distribution.  
Granted, we are not likely to see this happen to core packages, but it might be 
worth incorporating in to policy.  What happens if openssh has a vulnerability 
and there's not currently an active maintainer.  This is not all that 
unrealistic given the situation unfolding with FreeIPA and dependent Java 
packages (that's a different thread).

And lastly, what about packages that are currently in the orphan state but have 
security bugs opened?

> I'd like to adjust the policy before I go implement some tooling around this.
> 
> This is vague proposal of what I think would work easier for both "the 
> executioner" and the affected maintainers:
> 
> 
> 1. We automatically send reminders to NEW security bugzillas (as with FTBFS)
> 2. BZs that remain in NEW state for X reminders: pkg is orphaned
> 3. BZs that remain not CLOSED for Y months: pkg is retired (with 
> notifications)
> 
> 
> Point 2 makes it so that only a couple remaining packages actually need to 
> survive unfixed to point 3. Hence, point 3 can happen at a certain point in 
> the 
> schedule with less severe impact of points B and C -- and if we miss the 
> window, 
> we still have point 1 happening.
> 
> 
> The bugzilla reminders are sent every third calendar week (every week is too 
> disturbing).
> 
> 
> Here is an initial (albeit randomly generated) proposal of X and Y:
> 
> severity   CRITICAL/HIGH MEDIUM  LOW
>  X 2 4 6
>  Y 2 4 6
> 
> Note that X=1 effectively means anything from 1 second to 3 weeks, X=2 means 
> anything from 3 weeks (+1 second) to 6 weeks. Hence, we cannot orphan 
> packages 
> after just 1 reminder.
> 
> I've made it so that X always equals to Y and every lower level is +2, to 
> make 
> it easier to document, understand and remember, however this is not required.

This seems reasonable to me.

> For this example a critical/high CVE would get a reminder every third 
> calendar 
> week. After two reminders (that is after 3-6 weeks), if still in NEW state, 
> package is orphaned. The maintainer (and others) still have extra 6 weeks to 
> claim it.
> If the bug is ASSIGNED, MODIFIED, etc., the package may be retired after 2 
> months, but that only happens regularly at a certain point in the schedule.
> 
> Similarly, a package with a medium CVE NEW bugzilla would be orphaned after 4 
> reminders (after 9-12 weeks), retired at a point if still not CLOSED after 4 
> months.
> 
> With low severity, that is 6 reminders (after 15-18 weeks), retired at a 
> point 
> if still not CLOSED after 6 months (similarly to the current policy).

Where do get bug severity information?

> Please share your feedback, before I proceed with this to FESCo.
> If somebody would be interested in maintaining this procedure, I'd be happy 
> to 
> hand over that responsibility to anybody who is willing to help.
> The idea is to start with semi-automation and have something -- currently we 
> had 
> hoped for fully automated and we have nothing.
> 
> 
> [0] https://pagure.io/fesco/issue/1935
> [1] https://pagure.io/fesco/issue/2244
> [2] 

[Bug 1802773] perl-Sys-Mmap-0.20 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
An HTTP error occurred downloading the package's new Source URLs: Getting
https://cpan.metacpan.org/authors/id/S/SW/SWALTERS/Sys-Mmap-0.20.tar.gz to
./Sys-Mmap-0.20.tar.gz

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

[Bug 1802773] New: perl-Sys-Mmap-0.20 is available

[bugzilla]

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

Bug ID: 1802773
   Summary: perl-Sys-Mmap-0.20 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sys-Mmap
  Keywords: FutureFeature, Triaged
  Assignee: zonexpertconsult...@outlook.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
zonexpertconsult...@outlook.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.20
Current version/release in rawhide: 0.19-12.fc32
URL: http://search.cpan.org/dist/Sys-Mmap/

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

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

Re: deduplicating noarch subpackages

[Nicolas Mailhot via devel]

Le jeudi 13 février 2020 à 09:59 -0800, Josh Stone a écrit :
> 
> It's not so black and white. In theory, the only thing that should
> matter is the target triple, but the metadata also hashes the
> metadata
> of all its build dependencies. That in turn may include procedural
> macros (essentially compiler plugins) which are host binaries. The
> end
> result for the target should be the same, but it's a real concern for
> upstream that ignoring the host would break caching that relies on
> filename differences.

It is so black and white. If you can not produce bit-perfect identical
builds, don’t try to make the result noarch.

Neither koji, nor auditors, nor other third parties, can be expected to
check binary differences for you, and identify what differences matter
and what differences do not matter.

Neither koji, nor auditors, nor other third parties, can be expected to
trust that you did this checking for every single build that differs.

The *only* sane check strategy is a black and white equal/inequal test.

And you can not handwave those concerns aways because you feel your
builds should be noarch (feeling is not implementable in software).

When you write

> it's a real concern for upstream that ignoring the host would break
> caching

you are writing that upstream thinks the result is archful (because if
it actually were noarch, it would be perfectly fine to substitute one
build output for another, and there would be no caching concerns).

The proof is in the pudding. noarch → binary differences do not matter,
they can be removed during the build process, and koji will be happy.
archful → removing differences will break something.

And, removing differences does not necessarily mean removing things.
The reproducible build project didn’t remove timestamps. It just made
sure the same timestamp would be used for all builds.

Regards,

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

Re: Invalid body, keys: sls missing

[Ben Rosser]

On Thu, Feb 13, 2020 at 12:01 PM Jerry James  wrote:
>
> I'm trying to get an f32 branch for a newly created package.  Branch
> creation has failed twice now with the error in $SUBJECT:
>
> https://pagure.io/releng/fedora-scm-requests/issue/22127
>
> Can I get a human to look at that ticket instead of whatever
> automation it is that keeps closing it without actually accomplishing
> the requested task?  Thanks,
> --
> Jerry James
> http://www.jamezone.org/

The same thing just happened to me with a f32 branch request as well:
https://pagure.io/releng/fedora-scm-requests/issue/22140

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

Re: Seeking the maintainer of dbus-python

[Martin Kolman]

On Thu, 2020-02-13 at 18:54 +0100, Kevin Kofler wrote:
> Martin Kolman wrote:
> > I wonder if this is an actual problem on Fedora ? I would assume many
> > system services and applications depend on GLib, so using dasbus should
> > not pull on extra dependencies in practice.
> 
> From a distribution standpoint, the dependency on GLib is not a problem 
> (Neal Gompa's point about the event loop might be relevant, but I guess that 
> in the case of GTK applications such as Anaconda, using the GLib event loop 
> is actually desirable), but having yet another library dragged onto all 
> images as a dependency of the installer is not so nice (even if it is only a 
> wrapper around GLib/GIO code doing the actual work).
We have been using pydbus[0] before switching to dasbus, so this should not
be a net difference asa AFAIK nothing else is using pydbus on the image.

[0] https://koji.fedoraproject.org/koji/packageinfo?packageID=23792

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

Re: How to get proper nsswitch.conf?

[Michael Catanzaro]

On Thu, Feb 13, 2020 at 5:25 pm, Florian Weimer  
wrote:
authselect is not the only package editing nsswitch.conf, other 
packages

do it as well.  I have lost track.


It'd be really good to know what else is doing this, because I have a 
pending change proposal that's going to require editing this file, and 
I had only been planning to modify the glibc and authselect packages.


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

Re: deduplicating noarch subpackages

[Josh Stone]

On 2/12/20 8:29 AM, Adam Jackson wrote:
> On Tue, 2020-02-11 at 16:21 -0800, Josh Stone wrote:
> 
>> Another alternative is to try to remove the host information from the
>> metadata hash, which I've already started upstream[3], but I'm not sure
>> alleviate their concerns about caching and such.
>>
>> [3] https://github.com/rust-lang/cargo/pull/7873
>>
>> Worst case, I could just build them as arch'ed subpackages, specific to
>> the host which compiled them.
> 
> I'd lean in favor of removing at least the architecture part of the
> host triple from the hash. koji is still going to build those noarch
> packages on every architecture and compare them, so if you do remove
> the arch from the hash and they all compare equal, it can't have
> mattered which arch you built it from.

FWIW, I don't think Koji actually cares if the files are *identical*, as
long as the file list is the same. The rpmdiff call says:

# ignore differences in file size, md5sum, and mtime
# (files may have been generated at build time and contain
#  embedded dates or other insignificant differences)
d = koji.rpmdiff.Rpmdiff(joinpath(basepath, first_rpm),
joinpath(basepath, other_rpm), ignore='S5TN')
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: deduplicating noarch subpackages

[Josh Stone]

On 2/12/20 12:45 AM, Nicolas Mailhot wrote:
> Le 2020-02-12 01:21, Josh Stone a écrit :
> 
>> The problem is that those cross-target libraries built by two different
>> host arches will have different metadata hashes in the filenames,
>> because the hash includes the full "rustc -Vv" version output, 
>> including
>> the host triple.
> 
> koji is doing the right thing. For audits and QA checks a noarch package 
> must be produced exactly the same ways regardless of the arch of the 
> builder.
> 
> Either recording the triplet is meaningless, and you should inhibit 
> it(the same way reproducible builds inhibit date recording), or it 
> serves a purpose, and your builds are archfull by construction.

It's not so black and white. In theory, the only thing that should
matter is the target triple, but the metadata also hashes the metadata
of all its build dependencies. That in turn may include procedural
macros (essentially compiler plugins) which are host binaries. The end
result for the target should be the same, but it's a real concern for
upstream that ignoring the host would break caching that relies on
filename differences.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Seeking the maintainer of dbus-python

[Kevin Kofler]

Martin Kolman wrote:
> I wonder if this is an actual problem on Fedora ? I would assume many
> system services and applications depend on GLib, so using dasbus should
> not pull on extra dependencies in practice.

From a distribution standpoint, the dependency on GLib is not a problem 
(Neal Gompa's point about the event loop might be relevant, but I guess that 
in the case of GTK applications such as Anaconda, using the GLib event loop 
is actually desirable), but having yet another library dragged onto all 
images as a dependency of the installer is not so nice (even if it is only a 
wrapper around GLib/GIO code doing the actual work).

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

Re: deduplicating noarch subpackages

[Josh Stone]

On 2/13/20 7:26 AM, Kevin Kofler wrote:
> Neal Gompa wrote:
>> My instinct is that this wouldn't work, but I'm not certain. Have you
>> tried this change with a scratch build? Scratch builds run the same
>> checks that normal builds do, and would be a good way to verify if
>> your theory is true.

OK, I ran a scratch build where only x86_64 built the noarch wasm
target. I can't tell if koji actually ran the checks though.

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

> %ifarch-ing noarch subpackages (note: noarch SUBpackages of arch-dependent 
> packages) actually works and does the right thing in Koji. (Koji will still 
> copy them to all the architectures, even if they were built only on one of 
> them.) As far as I know, this was implemented that way to make QEMU 
> firmwares work (which are built on and for a specific architecture, and then 
> shipped as noarch packages for all of them so that the architecture can be 
> emulated).

Ah, I suppose you are referring to ipxe? It looks like that package has
always been built this way, as was gpxe before it. Even further back was
etherboot which did this since etherboot-5.4.4-13.fc11, and its
changelog for release 10 said, "Koji now supports noarch subpackages."
So it seems this has worked nearly as long as we've had noarch at all.

Thanks, it's useful to have history/precedent for this kind of design.

> Back when we had secondary Koji instances, the secondary architecture people 
> used to complain about that practice because those noarch subpackages would 
> then be missing on their Koji instances. But now that we build alternative 
> architectures on the primary Koji, I do not see a good reason to not %ifarch 
> the noarch subpackages, at least in the cases where it works around a known 
> bogus comparison failure. (In the other cases, you may still want Koji to 
> actually do that comparison as a form of automated QA, even if it is 
> technically a waste of resources.)
> 
> Building, e.g., noarch documentation subpackages only on a fast architecture 
> such as x86_64 also helps speeding up builds on slower architectures such as 
> armv7hl, without actually affecting their users (as per the first 
> paragraph).
> 
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: infrastructure problem: koji and bodhi responding very slow / dl with 80kb/s

[Kevin Fenzi]

On Thu, Feb 13, 2020 at 03:31:26PM +0100, Marius Schwarz wrote:
> 
> Hi,
> 
> while testing ff 73 update, i noticed that bodhi and koji are sponding
> very slow. The download speed at koji for germany was around 80KB/s,
> while other parts of the country reached MB/s easily. 
> 
> As bodhi does not have that much html to transfer, i don't think it's a
> network issue.

I haven't seen any other reports and it's very fast here. 

Do note that koji and bodhi are both things that are in one place: our
main datacenter in phx2 (arizona, usa). They aren't distributed. 
So, I suspect it _is_ network between there and you.

Unfortunately, I am not sure there's too much we can do about it. 
If it's some upstream network issue we can try and talk to providers,
but we seldom have any luck getting them to do anything. 

We are going to be moving from the phx2 datacenter to another facility
in virgina, usa later this year. I have no idea if that will improve
things for you though. ;( 

For koji downloads (those things that use kojipkgs.fedoraproject.org) we
might be able to setup amazon cloudfront, that would help with those. 

> Could someone from the infrastructure team take a look at your dashboards?

Do please note that if you hit an infrastructure problem, it's really
best to open a infrastructure ticket, not post to devel list (which we
read in our spare time): 

https://pagure.io/fedora-infrastructure/issues

Sorry I couldn't be of more help...

kevin


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

Invalid body, keys: sls missing

[Jerry James]

I'm trying to get an f32 branch for a newly created package.  Branch
creation has failed twice now with the error in $SUBJECT:

https://pagure.io/releng/fedora-scm-requests/issue/22127

Can I get a human to look at that ticket instead of whatever
automation it is that keeps closing it without actually accomplishing
the requested task?  Thanks,
-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 97/158 (x86_64), 1/2 (arm)

Old failures (same test failed in Fedora-32-20200212.n.1):

ID: 520572  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/520572
ID: 520573  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/520573
ID: 520574  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/520574
ID: 520575  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/520575
ID: 520576  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/520576
ID: 520580  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/520580
ID: 520585  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/520585
ID: 520586  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/520586
ID: 520587  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/520587
ID: 520588  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/520588
ID: 520589  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/520589
ID: 520597  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/520597
ID: 520602  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/520602
ID: 520605  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/520605
ID: 520612  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/520612
ID: 520613  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/520613
ID: 520614  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/520614
ID: 520615  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/520615
ID: 520616  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/520616
ID: 520636  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/520636
ID: 520640  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/520640
ID: 520642  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/520642
ID: 520652  Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/520652
ID: 520653  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/520653
ID: 520654  Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/520654
ID: 520656  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/520656
ID: 520657  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/520657
ID: 520658  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/520658
ID: 520659  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/520659
ID: 520660  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/520660
ID: 520662  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/520662
ID: 520663  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/520663
ID: 520664  Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/520664
ID: 520665  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/520665
ID: 520666  Test: x86_64 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/520666
ID: 520667  Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/520667
ID: 520668  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/520668
ID: 520669  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/520669
ID: 520670  Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/520670
ID: 520671  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/520671
ID: 520672  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/520672
ID: 520673  Test: x86_64 universal install_ext3@uefi
URL: 

Re: Seeking the maintainer of dbus-python

[Neal Gompa]

On Thu, Feb 13, 2020 at 11:06 AM Martin Kolman  wrote:
>
> On Thu, 2020-02-13 at 16:44 +0100, Kevin Kofler wrote:
> > Martin Kolman wrote:
> > > the rather new (F32+) pure-Python dasbus DBus library
> >
> > LOL, don't you love fake German? ^^
> > (Actual German would be "Der Bus", not "Das Bus". ;-) )
> We are aware of that & and it indeed is fake German on purpose. :)
>
> >
> > And the library is not really pure-Python, it uses GLib (including, as far
> > as I can tell, GLib/GIO's D-Bus protocol implementation, at least I see uses
> > of it in connection.py).
> I should have been more concrete - it is pure Python as in not containing
> C extension code that wold have to be compiled, but it indeed uses GLib for
> the low level DBus protocol handling.
>
> I wonder if this is an actual problem on Fedora ? I would assume many system 
> services
> and applications depend on GLib, so using dasbus should not pull on extra 
> dependencies
> in practice.
>

It's a problem only if the GLib main loop leaks into the consumer of
the library. If it does, then it could cause problems if there's a
mixture of incompatible event handling mechanisms. I've had problems
with that in the past with other libraries.



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

Re: How to get proper nsswitch.conf?

[Igor Gnatenko]

Hi Florian,

By "proper" I mean something supported and pristine so that I don't
end up with debugging weird problems. Some people name it "default".

I don't need anything special, just the one which should be by default
in Fedora Workstation.

On Thu, Feb 13, 2020 at 5:25 PM Florian Weimer  wrote:
>
> * Igor Gnatenko:
>
> > I've noticed that glibc ships one nsswitch.conf, but then it is
> > entirely overridden by authselect... What is the proper way of getting
> > proper nsswitch.conf on the system?
>
> authselect is not the only package editing nsswitch.conf, other packages
> do it as well.  I have lost track.
>
> Unfortunately, Fedora does not have a ban against scriptlets editing
> configuration files.
>
> Anyway, what do you mean by “proper”?  It really depends on what you
> need, and also on personal preferences.
>
> Thanks,
> Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How to get proper nsswitch.conf?

[Florian Weimer]

* Igor Gnatenko:

> I've noticed that glibc ships one nsswitch.conf, but then it is
> entirely overridden by authselect... What is the proper way of getting
> proper nsswitch.conf on the system?

authselect is not the only package editing nsswitch.conf, other packages
do it as well.  I have lost track.

Unfortunately, Fedora does not have a ban against scriptlets editing
configuration files.

Anyway, what do you mean by “proper”?  It really depends on what you
need, and also on personal preferences.

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

Re: Seeking the maintainer of dbus-python

[Martin Kolman]

On Thu, 2020-02-13 at 16:44 +0100, Kevin Kofler wrote:
> Martin Kolman wrote:
> > the rather new (F32+) pure-Python dasbus DBus library
> 
> LOL, don't you love fake German? ^^
> (Actual German would be "Der Bus", not "Das Bus". ;-) )
We are aware of that & and it indeed is fake German on purpose. :)

> 
> And the library is not really pure-Python, it uses GLib (including, as far 
> as I can tell, GLib/GIO's D-Bus protocol implementation, at least I see uses 
> of it in connection.py).
I should have been more concrete - it is pure Python as in not containing
C extension code that wold have to be compiled, but it indeed uses GLib for
the low level DBus protocol handling.

I wonder if this is an actual problem on Fedora ? I would assume many system 
services
and applications depend on GLib, so using dasbus should not pull on extra 
dependencies
in practice.


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

Re: Looking for new urlgrabber maintainer

[Michal Domonkos]

On Thu, Feb 13, 2020 at 4:37 PM Neal Gompa  wrote:
> Nothing stops you from writing tools to use it. :)

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

Fedora 32 compose report: 20200213.n.0 changes

[Fedora Branched Report]

OLD: Fedora-32-20200212.n.1
NEW: Fedora-32-20200213.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  2
Dropped packages:0
Upgraded packages:   86
Downgraded packages: 0

Size of added packages:  61.52 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.36 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Jam_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-32-20200213.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: 
mediawiki-lastmodified-0-0.3.20200210gitbe28231ebcd539fc99775811e5dc6df9064cfa94.fc32
Summary: Show the last modified page time
RPMs:mediawiki-lastmodified
Size:35.59 KiB

Package: ocaml-ppx-tools-6.1-1.fc32
Summary: Tools for authors of ppx rewriters
RPMs:ocaml-ppx-tools ocaml-ppx-tools-devel ocaml-ppx-tools-doc
Size:61.48 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  OpenImageIO-2.1.11.1-1.fc32
Old package:  OpenImageIO-2.1.10.1-3.fc32
Summary:  Library for reading and writing images
RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils 
python3-openimageio
Size: 19.74 MiB
Size change:  -34.21 KiB
Changelog:
  * Wed Feb 12 2020 Richard Shaw  - 2.1.11.1-1
  - Update to 2.1.11.0.


Package:  R-processx-3.4.2-1.fc32
Old package:  R-processx-3.4.1-3.fc31
Summary:  Execute and Control System Processes
RPMs: R-processx
Size: 1.38 MiB
Size change:  110.85 KiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
3.4.1-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Wed Feb 12 2020 Elliott Sales de Andrade  - 
3.4.2-1
  - Update to latest version


Package:  banshee-2.6.2-35.fc32
Old package:  banshee-2.6.2-34.fc31
Summary:  Easily import, manage, and play selections from your music 
collection
RPMs: banshee banshee-devel
Size: 16.72 MiB
Size change:  -547.52 KiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
2.6.2-35
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild


Package:  clang-10.0.0-0.2.rc1.fc32
Old package:  clang-10.0.0-0.1.rc1.fc32
Summary:  A C language family front-end for LLVM
RPMs: clang clang-analyzer clang-devel clang-libs clang-tools-extra 
git-clang-format python3-clang
Size: 235.55 MiB
Size change:  27.19 MiB

Package:  community-mysql-8.0.19-2.module_f32+7802+ea3258be
Old package:  community-mysql-8.0.18-6.module_f32+7378+6faafa4a
Summary:  MySQL client programs and shared libraries
RPMs: community-mysql community-mysql-common community-mysql-devel 
community-mysql-errmsg community-mysql-libs community-mysql-server 
community-mysql-test
Size: 1.06 GiB
Size change:  322.05 MiB
Changelog:
  * Thu Jan 02 2020 Lars Tangvald  - 8.0.19-1
  - Update to MySQL 8.0.19

  * Tue Jan 28 2020 Fedora Release Engineering  - 
8.0.19-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild


Package:  cups-bjnp-2.0.3-1.fc32
Old package:  cups-bjnp-2.0.1-4.fc31
Summary:  CUPS backend for the Canon BJNP network printers
RPMs: cups-bjnp
Size: 213.95 KiB
Size change:  -13.72 KiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
2.0.1-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Wed Feb 12 2020 Louis Lagendijk  - 2.0.3-1
  - New upstream version 2.0.3 
  - Fixes FTBS
  - Increased status buffer for compatibility with new printers


Package:  dbus-python-1.2.16-1.fc32
Old package:  dbus-python-1.2.8-10.fc32
Summary:  D-Bus Python Bindings
RPMs: dbus-python-devel python3-dbus
Size: 790.13 KiB
Size change:  -1001.68 KiB
Changelog:
  * Tue Feb 11 2020 Leigh Scott  - 1.2.16-1
  - Update to 1.2.16 (#1788491)


Package:  device-mapper-multipath-0.8.2-3.fc32
Old package:  device-mapper-multipath-0.8.2-1.fc32
Summary:  Tools to manage multipath devices using device-mapper
RPMs: device-mapper-multipath device-mapper-multipath-devel 
device-mapper-multipath-libs kpartx libdmmp libdmmp-devel
Size: 3.25 MiB
Size change:  -26.44 KiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
0.8.2-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Wed Feb 12 2020 Benjamin Marzinski  - 0.8.2-3
  - Add 0031-multipath-fix-issues-found-by-compiling-with-gcc-10.patch
* Patch submitted upstream
  - Resolves bz #1799276


Package:  dovecot-1:2.3.9.3-1.fc32
Old package:  dovecot-1:2.3.9.2-2.fc32
Summary:  Secure imap and pop3 server
RPMs: dovecot dovecot-devel dovecot-mysql dovecot-pgsql 
dovecot-pigeonhole
Size: 31.88 MiB
Size change:  3.47 KiB
Changelog:
  * Wed Feb 12 2020 Michal Hlavinka  - 1:2.3.9.3-1
  - dovecot updated to 2.3.9.3
  - fixes CVE-2020-7046: Truncated UTF-8

About "Disabling cgroup usage" when starting openQA job

[Normand]

Hello Adam,

Do you have lines with "Disabling cgroup usage ..."  in the journalctl 
of workers host ?


I noticed that since December 2019 after a dnf distro-sync
seems to be related to an upstream change 
https://github.com/os-autoinst/openQA/blame/master/lib/OpenQA/Worker/Engines/isotovideo.pm#L320



=== journalctl extract:
worker[4090]: [info] +++ setup notes +++
worker[4090]: [info] Start time: 2020-02-13 12:38:28
worker[4090]: [info] Running on abanb.tlslab.ibm.com:3 (Linux 
5.4.8-200.fc31.ppc64le #1 SMP Mon Jan 6 16:29:22 UTC 2020 ppc64le)

worker[4090]: [info] Preparing cgroup to start isotovideo
worker[4090]: [warn] Disabling cgroup usage because cgroup creation 
failed: mkdir /sys/fs/cgroup/systemd: Permission denied at 
/usr/share/perl5/vendor_perl/Mojo/File.pm line 87.
worker[4090]: [info] You can define a custom slice with 
OPENQA_CGROUP_SLICE or indicating the base mount with MOJO_CGROUP_FS.

worker[4090]: [info] Starting isotovideo container
===

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

Re: Seeking the maintainer of dbus-python

[Kevin Kofler]

Martin Kolman wrote:
> the rather new (F32+) pure-Python dasbus DBus library

LOL, don't you love fake German? ^^
(Actual German would be "Der Bus", not "Das Bus". ;-) )

And the library is not really pure-Python, it uses GLib (including, as far 
as I can tell, GLib/GIO's D-Bus protocol implementation, at least I see uses 
of it in connection.py).

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

Re: Looking for new urlgrabber maintainer

[Neal Gompa]

On Thu, Feb 13, 2020 at 10:10 AM Michal Domonkos  wrote:
>
> On Thu, Feb 13, 2020 at 3:59 PM Neal Gompa  wrote:
> > Cobbler uses it still, as does Spacewalk/Uyuni. Some of my software
> > does as well, though admittedly I could replace if I wanted to (I
> > don't, I like urlgrabber's handling semantics :) ).
>
> Okay, fair enough :)  FWIW, I have to admit I've also secretly liked
> urlgrabber's semantics. (I just don't happen to have a use-case for it
> anymore, with YUM being gone now.)

Nothing stops you from writing tools to use it. :)



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

Re: Any plans to include kotlin in Fedora

[Kevin Kofler]

Dridi Boukelmoune wrote:
> I think it boils down to having people to do the work, which is
> probably not an easy task. I'm also assuming we'd need a more
> up-to-date gradle package, which might not be a trivial task, and I
> suspect that the build system is probably full of "Fedora violations"
> between the need for an internet access, fetching pre-built
> dependencies, bundling some dependencies...

The main issue is that the dependency between Gradle and Kotlin is circular. 
Gradle is actually blocking, among other things, on Kotlin being packaged, 
and Kotlin is blocking on Gradle (which has been entirely retired because 
its maintainers were unable to keep it up to date). See the recent "Package 
uses Gradle (retired) to build: what to do?" thread.

Gradle also has a circular dependency of the same kind on its main 
implementation language, Groovy.

And of course, Gradle also has a trivial circular dependency on itself.

And finally, there is also Scala code in Gradle now. I am not sure whether 
the latest version of Scala can be built without Gradle or whether the 
dependency is circular there too.

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

Re: deduplicating noarch subpackages

[Kevin Kofler]

Neal Gompa wrote:
> My instinct is that this wouldn't work, but I'm not certain. Have you
> tried this change with a scratch build? Scratch builds run the same
> checks that normal builds do, and would be a good way to verify if
> your theory is true.

%ifarch-ing noarch subpackages (note: noarch SUBpackages of arch-dependent 
packages) actually works and does the right thing in Koji. (Koji will still 
copy them to all the architectures, even if they were built only on one of 
them.) As far as I know, this was implemented that way to make QEMU 
firmwares work (which are built on and for a specific architecture, and then 
shipped as noarch packages for all of them so that the architecture can be 
emulated).

Back when we had secondary Koji instances, the secondary architecture people 
used to complain about that practice because those noarch subpackages would 
then be missing on their Koji instances. But now that we build alternative 
architectures on the primary Koji, I do not see a good reason to not %ifarch 
the noarch subpackages, at least in the cases where it works around a known 
bogus comparison failure. (In the other cases, you may still want Koji to 
actually do that comparison as a form of automated QA, even if it is 
technically a waste of resources.)

Building, e.g., noarch documentation subpackages only on a fast architecture 
such as x86_64 also helps speeding up builds on slower architectures such as 
armv7hl, without actually affecting their users (as per the first 
paragraph).

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

Re: Looking for new urlgrabber maintainer

[Michal Domonkos]

On Thu, Feb 13, 2020 at 3:59 PM Neal Gompa  wrote:
> Cobbler uses it still, as does Spacewalk/Uyuni. Some of my software
> does as well, though admittedly I could replace if I wanted to (I
> don't, I like urlgrabber's handling semantics :) ).

Okay, fair enough :)  FWIW, I have to admit I've also secretly liked
urlgrabber's semantics. (I just don't happen to have a use-case for it
anymore, with YUM being gone now.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git forge requirements discussion

[Kamil Paral]

On Wed, Feb 12, 2020 at 10:35 AM Kamil Paral  wrote:

> On Tue, Feb 11, 2020 at 10:42 PM Ben Cotton  wrote:
>
>> On Tue, Feb 11, 2020 at 4:37 PM Matthew Miller 
>> wrote:
>> >
>> > Can you put the voting/polls idea in the form of a user story?
>> >
>> I think #44 on the list I sent covers that:
>> As a Fedora team member, I can vote +1/abstain/-1 on issues so that I
>> can approve or deny proposals.
>>
>
> We would actually need several polls per ticket, so that we can vote on
> Beta/Final Blocker/FE from a single discussion (and not 4 separate
> tickets). I'll add that user story.
>
>

Done, replied to the devel thread. Feel free to add whatever you think is
missing.
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Kamil Paral]

On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin  wrote:

> Hey Everyone,
>
> On behalf of the CPE team I want to draw the communities attention to a
> recent blog post which you may be impacted by:
>  https://communityblog.fedoraproject.org/git-forge-requirements/
>
> We will be seeking input and requirements in an open and
> transparent manner on the future of a git forge solution which will be run
> by the CPE team on behalf of the Fedora Community. This mail is being sent
> to the devel, mindshare and council-discuss lists for maximum visibility on
> a BCC to allow each list have their own views. Please forward it to any
> other list you may feel is relevant to maximise the exposure.
>
> Thanks in advance,
> Leigh
>

As QA, we don't have many git forge requirements. But this would be really
great to have:
* Be able to create several polls in a single ticket. This would allow us
to vote on blocker/freeze-exception status of proposed bugs.

If we can't have that, we can work around it using a ticket bot, which
would require at least the following:
* API to read tickets in a structured format
* API to add comments and edit the ticket description (ideally also adjust
ticket tags, milestones or some other properties)
* a webhook support to get notified of ticket changes or access to a
message bus

And to add some more to the wishlist:
* good integration to Fedora core services (the account system, messaging)
* open source
* be able to ping or CC someone using @name or similar
* be able to cross-reference projects using projectB#123 or similar
* be able to move tickets across projects
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Looking for new urlgrabber maintainer

[Neal Gompa]

On Thu, Feb 13, 2020 at 9:46 AM Michal Domonkos  wrote:
>
> On Thu, Feb 13, 2020 at 2:19 PM Neal Gompa  wrote:
> > Sure. Let's make it official. Though I'd love to still have you as
> > co-maintainer and other co-maintainers are welcome! :)
>
> OK, I just made a request:
> https://pagure.io/releng/issue/9257
>
> As for co-maintenance, it still is "maintenance" and defeats the
> purpose of us trying to "get rid of it" :)
>
> BTW, since koji-containerbuild no longer depends on python-urlgrabber
> (see above in this thread), do we have any motivation for keeping the
> package in the distro at all?  I understand that SUSE actually uses it
> (so the upstream should live on), but not sure about the Fedora
> downstream package.

Cobbler uses it still, as does Spacewalk/Uyuni. Some of my software
does as well, though admittedly I could replace if I wanted to (I
don't, I like urlgrabber's handling semantics :) ).



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

Re: Looking for new urlgrabber maintainer

[Michal Domonkos]

On Thu, Feb 13, 2020 at 2:19 PM Neal Gompa  wrote:
> Sure. Let's make it official. Though I'd love to still have you as
> co-maintainer and other co-maintainers are welcome! :)

OK, I just made a request:
https://pagure.io/releng/issue/9257

As for co-maintenance, it still is "maintenance" and defeats the
purpose of us trying to "get rid of it" :)

BTW, since koji-containerbuild no longer depends on python-urlgrabber
(see above in this thread), do we have any motivation for keeping the
package in the distro at all?  I understand that SUSE actually uses it
(so the upstream should live on), but not sure about the Fedora
downstream package.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Pat Riehecky]

On 2/13/20 6:54 AM, Matthew Miller wrote:

I've been saying this for a while as if it's fact, but of course it's not
actually fact until approved, so I'm puting this to the EPEL team to
hopefully do so.

The current guidelines * say:

EPEL packages should only enhance and never disturb the Enterprise Linux
distributions they were built for. Thus packages from EPEL should never
replace packages from the target base distribution - including those on the
base distribution as well as layered products; kernel-modules further are
not allowed, as they can disturb the base kernel easily.

With modularity in EPEL 8, we have the opportunity to allow more flexibility
while preserving the primary goal of not disturbing the base distribution.
Therefore, I propose adding:

   In EPEL 8 or later, it is permitted to have module streams which contain
   packages with alternate versions to those provided in RHEL. These packages
   may be newer, built with different options, or even older to serve
   compatibility needs. These MUST NOT be the default stream -- in every
   case, explicit user action must be required to opt in to these versions.


(Note that the base package _does not_ have to be part of a module for this
to work.)

What do you think?





I like it, but perhaps it is worth adding a note that EPEL8 packages 
must not include an 'Obsoletes' that targets packages shipped in RHEL 
itself.


--
Pat Riehecky

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

[Bug 1802607] perl-Net-DNS-1.22 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Net-DNS-1.22-1.fc30.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=41479405

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

infrastructure problem: koji and bodhi responding very slow / dl with 80kb/s

[Marius Schwarz]

Hi,

while testing ff 73 update, i noticed that bodhi and koji are sponding
very slow. The download speed at koji for germany was around 80KB/s,
while other parts of the country reached MB/s easily. 

As bodhi does not have that much html to transfer, i don't think it's a
network issue.

Could someone from the infrastructure team take a look at your dashboards?


best regards,
Marius

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

[Bug 1802607] perl-Net-DNS-1.22 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1662963
  --> https://bugzilla.redhat.com/attachment.cgi?id=1662963=edit
[patch] Update to 1.22 (#1802607)

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

[Bug 1802607] New: perl-Net-DNS-1.22 is available

[bugzilla]

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

Bug ID: 1802607
   Summary: perl-Net-DNS-1.22 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Net-DNS
  Keywords: FutureFeature, Triaged
  Assignee: pwout...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com,
john.j5l...@gmail.com, ka...@ucw.cz,
perl-devel@lists.fedoraproject.org,
pwout...@redhat.com, rhug...@redhat.com,
rstr...@redhat.com, sandm...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.22
Current version/release in rawhide: 1.21-2.fc32
URL: http://search.cpan.org/dist/Net-DNS/

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

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

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

[Troy Dawson]

On Thu, Feb 13, 2020 at 4:54 AM Matthew Miller  wrote:
>
> I've been saying this for a while as if it's fact, but of course it's not
> actually fact until approved, so I'm puting this to the EPEL team to
> hopefully do so.
>
> The current guidelines * say:
>
>EPEL packages should only enhance and never disturb the Enterprise Linux
>distributions they were built for. Thus packages from EPEL should never
>replace packages from the target base distribution - including those on the
>base distribution as well as layered products; kernel-modules further are
>not allowed, as they can disturb the base kernel easily.
>
> With modularity in EPEL 8, we have the opportunity to allow more flexibility
> while preserving the primary goal of not disturbing the base distribution.
> Therefore, I propose adding:
>
>   In EPEL 8 or later, it is permitted to have module streams which contain
>   packages with alternate versions to those provided in RHEL. These packages
>   may be newer, built with different options, or even older to serve
>   compatibility needs. These MUST NOT be the default stream -- in every
>   case, explicit user action must be required to opt in to these versions.
>
>
> (Note that the base package _does not_ have to be part of a module for this
> to work.)
>
> What do you think?
>
>
> * 
> https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Packaging_Guidelines_and_Policies_for_EPEL

Good idea.
I think you worded it very well.

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

How to get proper nsswitch.conf?

[Igor Gnatenko]

Hello,

I've noticed that glibc ships one nsswitch.conf, but then it is
entirely overridden by authselect... What is the proper way of getting
proper nsswitch.conf on the system?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Retiring mingw-* packages from EPEL 7

[Stephen John Smoogen]

On Thu, 13 Feb 2020 at 06:29, Richard W.M. Jones  wrote:

>
> This has been done now.  In total 107 EPEL 7 mingw-* packages
> were retired, and 307 bugs closed.
>

Thanks Richard.

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

[Bug 1802524] perl-Devel-Hide-0.0011 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Devel-Hide-0.0011-1.fc
   ||32
   ||perl-Devel-Hide-0.0011-1.fc
   ||33
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-02-13 13:50:00



--- Comment #3 from Paul Howarth  ---
Built for f32:
https://koji.fedoraproject.org/koji/taskinfo?taskID=41478038

And Rawhide:
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=41477867

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

Re: Looking for new urlgrabber maintainer

[Neal Gompa]

On Thu, Feb 13, 2020 at 8:16 AM Michal Domonkos  wrote:
>
> On Wed, Feb 12, 2020 at 5:07 PM Neal Gompa  wrote:
> > Umm, don't I already own python-urlgrabber in Fedora and upstream? Not
> > that I would mind co-maintainers, but I thought we already did this
> > switchover during Fedora 31 development...
>
> Oh, I almost forgot, of course.  We did talk about it.  After all, you
> made the release 4.0 happen, as a result of the discussion we had back
> then.
>
> We never made it "official", though, since "packaging-team-maint" is
> still listed as the primary maintainer on Pagure, which is basically
> what we're trying to change.  If you're interested, more power to you,
> just let me know :)

Sure. Let's make it official. Though I'd love to still have you as
co-maintainer and other co-maintainers are welcome! :)


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

Re: Looking for new urlgrabber maintainer

[Michal Domonkos]

On Wed, Feb 12, 2020 at 6:01 PM Martin Basti  wrote:
>
>
> On 12. 2. 2020 17:06, Neal Gompa wrote:
> > On Wed, Feb 12, 2020 at 10:52 AM Michal Domonkos  
> > wrote:
> >> Hi,
> >>
> >> I'd like to ask around if anyone would be willing to take ownership of
> >> the python3-urlgrabber package and its upstream repository[1]?
> >>
> >> For historical reasons, the project is de facto maintained by us, the
> >> DNF team (with the upstream repo hosted in our GitHub namespace).
> >> However, with the community's departure from YUM (which depended on
> >> urlgrabber) a few years back, we no longer have the incentive or
> >> capacity to keep the project alive, and are considering deprecating it
> >> in the near future, unless someone takes over.
> >>
> >> Now, urlgrabber has recently[2] been ported to Python 3, in an effort
> >> to maintain its legacy as a standalone general-purpose URL library,
> >> authored[3] by Jochen Breuer of SUSE in November, 2018.  It's the only
> >> component of the legacy YUM stack that wasn't dropped[4] from the
> >> distro in Fedora 31.  In addition to that, there currently is one last
> >> component in Fedora that requires the package; koji-containerbuild.
> >>
> >> That said, I'd like to address this request especially to Jochen and
> >> the maintainers of koji-containerbuild.  Please, let us know if you
> >> (or anyone, really) would be interested in the transfer.
> >>
> > Umm, don't I already own python-urlgrabber in Fedora and upstream? Not
> > that I would mind co-maintainers, but I thought we already did this
> > switchover during Fedora 31 development...
> >
> >
> Ehm sorry,
>
> it seems that somebody forgot to remove that dependency from
> koji-contianerbuild. At least it is not used in upstream I opened PR to
> drop it.
>
> https://github.com/containerbuildsystem/koji-containerbuild/pull/159

Oh, and I can see the PR has been merged in the meantime, which is
great!  Thank you, Martin!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Looking for new urlgrabber maintainer

[Michal Domonkos]

On Wed, Feb 12, 2020 at 5:07 PM Neal Gompa  wrote:
> Umm, don't I already own python-urlgrabber in Fedora and upstream? Not
> that I would mind co-maintainers, but I thought we already did this
> switchover during Fedora 31 development...

Oh, I almost forgot, of course.  We did talk about it.  After all, you
made the release 4.0 happen, as a result of the discussion we had back
then.

We never made it "official", though, since "packaging-team-maint" is
still listed as the primary maintainer on Pagure, which is basically
what we're trying to change.  If you're interested, more power to you,
just let me know :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Packaging Guidelines - .so in JARs?

[Andrew Haley]

On 2/12/20 8:57 PM, Alex Scheel wrote:
> Per $SUBJ, I was looking for guidance from the Java community about
> embedding .so files within JARs.
>
> I found these docs:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_applicability
>
> Which seem to have conflicting commentary on this:
>
>  - A Java package uses JNI if it contains a .so file. Note that this file can
>be embedded within JAR files themselves.

 - JAR files using JNI or containing JNI shared objects themselves
   MUST be placed in %{_jnidir} and MAY be symlinked to
   %{_libdir}/%{name}.

>  - JNI shared objects MUST be placed in %{_libdir}/%{name}
>
> As long as the JAR for the application is played in
> %{_libdir}/%{name}/%{name}.jar, does this mean that the .so can be
> placed within the JAR?

Yes. This is explicitly permitted by the rule above.

> The benefit to .so-in-JAR is that the JAR always knows where to find
> the .so, even if the user installs multiple versions of the same
> package, or, worse, copies JARs from different systems around.
>
>
> Wondering what the community's thoughts are,

Hidden shared objects have to be unpacked somewhere in order to be
used. If they're unpacked somewhere private they won't be shared. And
the runtime code will need to find the correct shared object, the one
relevant to the machine in use. I've seen this break on new
architectures.

So, generally it's not such a great idea to hide shared objects in
JARS, but it's not absolutely forbidden because we know that sometimes
this is what Java programs do and we don't want to burden packagers
unduly.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Thursday's FPC Meeting (2020-02-13 17:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2020-02-13 17:00 UTC in #fedora-meeting-1 on 
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2020-02-13 09:00 PST  US/Pacific
2020-02-13 12:00 EST  --> US/Eastern <--
2020-02-13 17:00 GMT  Europe/London 
2020-02-13 17:00 UTC  UTC   
2020-02-13 18:00 CET  Europe/Berlin 
2020-02-13 18:00 CET  Europe/Paris  
2020-02-13 22:30 IST  Asia/Calcutta 
 New Day: Friday -
2020-02-14 01:00 HKT  Asia/Hong_Kong
2020-02-14 01:00 +08  Asia/Singapore
2020-02-14 02:00 JST  Asia/Tokyo
2020-02-14 03:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

= Followups =

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

#topic #909 Suggest that linting/measuring-coverage is not for %check
.fpc 909
https://pagure.io/packaging-committee/issue/909

#topic #935 Fonts packaging policy rewrite  
.fpc 935
https://pagure.io/packaging-committee/issue/935
https://pagure.io/packaging-committee/pull-request/934

= Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines 
https://pagure.io/packaging-committee/pull-request/814

#topic #pr-938 Add Package Review Process page 
https://pagure.io/packaging-committee/pull-request/938

#topic #pr-940 Revisit the Python guidelines 
https://pagure.io/packaging-committee/pull-request/940

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * Bring it up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Matthew Miller]

I've been saying this for a while as if it's fact, but of course it's not
actually fact until approved, so I'm puting this to the EPEL team to
hopefully do so.

The current guidelines * say:

   EPEL packages should only enhance and never disturb the Enterprise Linux
   distributions they were built for. Thus packages from EPEL should never
   replace packages from the target base distribution - including those on the
   base distribution as well as layered products; kernel-modules further are
   not allowed, as they can disturb the base kernel easily.

With modularity in EPEL 8, we have the opportunity to allow more flexibility
while preserving the primary goal of not disturbing the base distribution.
Therefore, I propose adding:

  In EPEL 8 or later, it is permitted to have module streams which contain
  packages with alternate versions to those provided in RHEL. These packages
  may be newer, built with different options, or even older to serve
  compatibility needs. These MUST NOT be the default stream -- in every
  case, explicit user action must be required to opt in to these versions.


(Note that the base package _does not_ have to be part of a module for this
to work.)

What do you think?


* 
https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Packaging_Guidelines_and_Policies_for_EPEL
-- 
Matthew Miller

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

Re: dnf exit code

[Matthew Miller]

On Wed, Feb 12, 2020 at 10:29:47AM +0100, Daniel Mach wrote:
> There seem to be 2 related problems:
> 1) Only the image on docker.io doesn't work. If you use
> registry.fedoraproject.org/fedora:rawhide, it works as expected.

Yeah, that's ... concerning. They should be identical.

> 2) Fedora infra is unreliable. When the image from
> registry.fedoraproject.org cannot be downloaded, there's a fallback
> to docker.io which contains a different image. Running the command
> several times in a row produces "random" results:

I believe the plan is to migrate to using quay.io now that that's open
source.

-- 
Matthew Miller

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

Re: Turning off keys.fedoraproject.org

[Till Maas]

On Wed, Feb 12, 2020 at 11:15:01PM +0100, Björn Persson wrote:

> are sent over TLS, but what do they do if your email provider doesn't
> support SMTP over TLS? Do they refuse your key in that case? My guess
> is that they send the verification email unprotected, and that that's
> one reason why they say they're not a certification authority.

All CAs support verification via insecure protocols AFAIK because
usually the certificate is needed to secure the protocol. What other
option would they have?

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

[EPEL-devel] Re: Retiring mingw-* packages from EPEL 7

[Richard W.M. Jones]

This has been done now.  In total 107 EPEL 7 mingw-* packages
were retired, and 307 bugs closed.

Rich.

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

[Bug 1802524] perl-Devel-Hide-0.0011 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Devel-Hide-0.0011-1.fc30.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=41477078

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

Re: Co-Maintainers wanted for Pantheon / elementary apps (Vala / GObject / GTK+)

[Harsh Jain]

Hey Alain,
I've been trying to help with pantheon de on Fedora as well.Nice to know
someone who has experience with  vala /gtk  helping , I've started to learn
Vala but wil take some time to get to a stage where I can help with the
apps themselves. Looking forward to working together .
Thanks for helping,
Harsh

On Wed, Feb 12, 2020 at 11:29 PM Alain Vigne 
wrote:

> Hello Fabio
>
> I am not very active, and not a software engineer, but Vala/GTK
> applications are kind of my hobby, and I had the opportunity to take a look
> at elementary applications (code wise too).
> You are maintaining much more packages I can ever pretend to maintain, so
> this will be a little help.
> But I am ready to lend a hand, if I can get some guidance, milestones, and
> if we can work together... ?
>
> I am CET time zone based. Do you work from the USA ?
>
> My FAS is: avigne.
> Keep me posted.
> BR, Alain
>
>
> On Fri, Jan 31, 2020 at 9:30 PM Fabio Valentini 
> wrote:
>
>> Hi everybody,
>>
>> With more responsibilities (FPC, Stewardship SIG, FESCo) and the
>> ever-growing number of packages I maintain, I don't have as much time
>> for the things I originally started my contributions to fedora with -
>> the Pantheon desktop and the accompanying elementary applications.
>>
>> What makes things worse is that I am not particularly proficient with
>> Vala or C/GObject, other than including upstream patches or doing
>> simple backports. That means some issues are punted until upstream
>> projects get around to fixing them (and if these issues are only
>> affecting "third-party" distros like fedora, that can take a while).
>>
>> Also, the fact that GNOME frequently (almost with every new major
>> stable release, which means with almost every fedora release) breaks
>> something - either subtly or not - does not help.
>> gnome-settings-daemon changes its DBus interfaces almost every
>> release. mutter makes sweeping API changes almost every release. Both
>> gala and the elementary LightDM greeter can't keep up with upstream
>> mutter, and are basically still stuck on mutter 3.28 support (which is
>> why there is a mutter328 compat package) ...
>>
>> Overall, this results in the quality of all these packages not being
>> as high as I would like it to be (though it's still pretty good, all
>> things considered). In particular, there are some components that are
>> more "crashy" than the rest, and I don't have the time and skill to
>> get deep into debugging the issue in most cases:
>>
>> - wingpanel (the panel for Pantheon); issues in individual indicators
>> also crash the whole app because they are just dlopen()ed
>> - switchboard (the settings application); issues in individual
>> settings panels also crash the whole app because they are just
>> dlopen()ed
>> - gala (the window manager): obviously bad if the WM crashes, though
>> not as bad because it's still an Xorg session
>> - plank (the dock); also optionally used on XFCE (I think)
>> - sequeler (third-party SQL client developed for Pantheon)
>>
>> I would greatly appreciate if somebody who knows their GObject-fu
>> could help me out here.
>>
>> The elementaryOS upstream developers are usually helpful and accept
>> patches - even for things that are not a problem on elementaryOS, so
>> long as they can be switched on/off with e.g. conditional compilation.
>> But reported issues - that only affect fedora - without attached
>> patches / PRs are obviously low priority for them, and often sit
>> untouched for months or years.
>>
>> In general, I manage to keep the packages for Pantheon / elementary
>> projects up-to-date. Having set up "nightly" builds on COPR a few
>> years ago really helps to catch potential issues early.
>>
>> If anybody is interested, here are some pointers:
>>
>> - all packages are tracked in koschei, in the decathorpe/elementary group:
>> https://koschei.fedoraproject.org/groups/decathorpe/elementary
>>
>> - nightly builds are done on COPR:
>> https://copr.fedorainfracloud.org/coprs/decathorpe/elementary-nightly/
>>
>> Thanks,
>> Fabio
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
>
> --
> Alain V.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>

[Bug 1802524] New: perl-Devel-Hide-0.0011 is available

[bugzilla]

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

Bug ID: 1802524
   Summary: perl-Devel-Hide-0.0011 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Devel-Hide
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.0011
Current version/release in rawhide: 0.0010-7.fc32
URL: http://search.cpan.org/dist/Devel-Hide/

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

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

[Bug 1802524] perl-Devel-Hide-0.0011 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1662926
  --> https://bugzilla.redhat.com/attachment.cgi?id=1662926=edit
[patch] Update to 0.0011 (#1802524)

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

Re: Package uses Gradle (retired) to build: what to do?

[Mario Torre]

The problem with Gradle as far as I'm aware is that it's a moving
target. It insist on updating itself when you have an incompatible
version and versions tend to break compatibility a lot, with new
features added often, all of which makes impossible for a Linux
distribution to keep up realiably.

Cheers,
Mario

On Sat, Feb 8, 2020 at 12:23 PM Ankur Sinha  wrote:
>
> Hello,
>
> netcdf-java[1] uses the Gradle build system, and is required to update
> hdfview[2] to the latest version. Gradle, however, was retired[3] as
> "out of date, broken, fails to build, basically unmaintainable".
>
> Now, I know that following our system, one must package Gradle first but
> given the retirement comment, packaging and then maintaining it does not
> appear a simple task, and for one dependency only, it seems overkill.
>
> Is there perhaps a way of bypassing that somehow? For example, is there
> a way to use good old Maven to build a Gradle based project?
>
> [1] 
> https://docs.unidata.ucar.edu/netcdf-java/5.2/userguide/building_from_source.html
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1797361
> [3] https://src.fedoraproject.org/rpms/gradle/blob/master/f/dead.package
>
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) | 
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Package uses Gradle (retired) to build: what to do?

[Jun Aruga]

> Anyone with the time to (co-)maintain Gradle? :)

I added Mikolaj and Daniel to TO.
They had maintained gradle before being dead.package, seeing the past
commits in rpms/gradle.
Mikolaj and Daniel, do you like to come back as a maintainer of rpms/gradle?

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

Fedora-Cloud-31-20200213.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Re: Planing to retire sflphone

[Sandro Mani]

Hi

I went ahead and retired sflphone.

Sandro

On 05.02.20 17:45, Sandro Mani wrote:

Hi

I'm planing to retire sflphone (predecessor of ring.cx), since it's 
completely dead upstream (you won't even find the repo or sources 
anymore), and is now FTBFS due to recent pjproject changes. If someone 
wants to pick it up, please let me know, otherwise I'll retire it in 
one weeks time (2020-02-13).


Sandro


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

[EPEL-devel] Can we enable some "-devel" modules from CBR in the EPEL8 buildroot?

[Miro Hrončok]

Hello EPEL.

It seems that we have a python38-devel module in the RHEL 8.2 Beta Code Ready 
Builder repository. It has only one stream but it is not a default stream due to 
some technical limitations.


Can we please enable such stream in the EPEL8 buildroot trough some Ursa 
Major/Prime/... thing?


Is that technically possible on EPEL side?
Is that possible by policy?

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

[EPEL-devel] Re: How to support python 3.8 from RHEL 8.2 in EPEL?

[Tomas Orsava]

On 2/13/20 5:18 AM, Orion Poplawski wrote:

On 1/30/20 8:39 AM, Miro Hrončok wrote:

On 30. 01. 20 16:32, Orion Poplawski wrote:

Folks -

    Looks like RHEL 8.2 will have python 3.8 in addition to python 
3.6.  From

the 8.2 beta:

Red Hat Enterprise Linux 8 for x86_64 - AppStream Beta (RPMs)
Name   Stream  Profiles   Summary
python27   2.7 [d][e]  common [d] Python 
programming

language, version 2.7
python36   3.6 [d][e]  build, common [d]  Python 
programming

language, version 3.6
python38   3.8 [d][e]  build, common [d]  Python 
programming

language, version 3.8

Currently, %python_pkgversion is set to 3 in
/usr/lib/rpm/macros.d/macros.python-srpm from python-srpm-macros.

python3-devel is still provided only by python36-devel, so 
presumably all
EPEL8 python packages will continue to be built against python 3.6.  
But I

imagine that people will soon be asking for python 3.8 versions of EPEL
packages.  How can we provide those?  Does this have to be done in some
modular fashion - which seems to come back to the discussion of 
whether or not
every package has to become its own module or whether to group them 
together

somehow.  Or since both python modules are "default" modules and we can
install both python36-devel and python38-devel at the same time, 
perhaps we
can define the python3_other* macros again for python38 and just go 
that way?


Thoughts?


The idea is that the versions fo stuff we build in RHEL for different 
python versions is different and I'd like to keep that idea in EPEL 
as well. Building a python38-foo package from it's own spec should 
work as follows:


BR python38-rpm-macros
BR python38-devel
BR python38-bar etc...

Regular specfile follows.

You can even have a single specfile that build for different Python 
version based on local override of %python_pkgversion in the buildroot.


Building both versions from single spec file---single build would 
require a new set of macros, yes (or hardcoding stuff). However I'd 
not call them python3_other* unless you want to end up with 
python3_other_other* the next time this happens.




This along with some more info from rhel 8.2 beta yields more 
questions for me.  While I do agree that building the python38 
packages from separate specs probably is the best route (biggest 
reason being it allows for updating of individual module versions) I'm 
hoping we can brainstorm ways to make this less onerous on individual 
packagers.


Looks like python38-devel is a module in RHEL 8.2 that provides a 
bunch of stuff needed for building modules (python38-devel, 
python38-pytest, etc):



Hi!
Just a little correction, despite the name suggesting otherwise, the 
"python38-devel" package is not in the python38-devel module, but in the 
python38 module itself, which has a default stream.


The python38-devel module contains only python38-pytest and it's 
dependencies (pyparsing, atomicwrites, attrs, packaging, py, 
more-itertools, pluggy, wcwidth). And the reason it's not default is not 
an intention but a current technical limitation of the automatically 
generated "-devel" modules shipped in the CRB.





Red Hat CodeReady Linux Builder Beta for RHEL 8 x86_64 (RPMs)
Name   Stream Profiles  Summary
python38-devel 3.8 [e]  Python 
programming language, version 3.8


Since this isn't a default module, does this again mean the python38 
packages in EPEL 8 need to be modules as well?  Or can we provide a 
buildroot that enables this module?


My current pie-in-the-sky idea is that we could do:

- create a epel8-python38 branch for all of the python-* packages with 
epel8 branches.
- epel8-python38 buildroot would enable python38-devel and install 
python38-rpm-macros and define python3_pkgversion to 38.
- This would imply an epel8-python38 repo.  It's possible that some 
packages from epel8-python38 wouldn't be able to be installed unless 
the python38-devel module was enabled.
- This might lead to an explosion of repos if we try to work around 
other modules in RHEL8 like this (php 7.3, perl, ruby 2.6)



Otherwise I think we will need python38 packages in EPEL8 to be 
modular.  If the module route is the way to go, I really do think that 
we should try to not have every package be its own module, though the 
other extreme (all packages in one module) probably is untenable as 
well.  In any case, this will require a lot more coordination among 
packagers (not necessarily a bad thing).


Thoughts?  Plans?



Since pytest is usually a build dependency, then theoretically you could 
have non-modular python38 packages in EPEL, since all the important 
stuff is in python38 with a default stream.


Tomas




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

Fedora-Cloud-30-20200213.0 compose check report

[Fedora compose checker]

No missing expected images.

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