[389-devel] 389 DS nightly 2020-08-14 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/08/14/report-389-ds-base-1.4.4.4-20200813git5afcbb0.fc32.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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6ba549ab3a   
ark-19.12.2-2.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c2936180ed   
ansible-2.9.12-1.el8


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

python-apprise-0.8.7-1.el8
rdesktop-1.9.0-3.el8

Details about builds:



 python-apprise-0.8.7-1.el8 (FEDORA-EPEL-2020-72e9a38948)
 A simple wrapper to many popular notification services used today

Update Information:

Updated to v0.8.7

ChangeLog:

* Thu Aug 13 2020 Chris Caron  - 0.8.7-1
- Updated to v0.8.7
* Mon Aug  3 2020 Chris Caron  - 0.8.6-4
- Updated SPEC so Fedora 33 Mass Rebuild would pass
* Sat Aug  1 2020 Fedora Release Engineering  - 
0.8.6-3
- Second attempt - Rebuilt for
  https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Tue Jul 28 2020 Fedora Release Engineering  - 
0.8.6-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild




 rdesktop-1.9.0-3.el8 (FEDORA-EPEL-2020-19cedc84a3)
 X client for remote desktop into Windows Terminal Server

Update Information:

Build for EPEL8

ChangeLog:


References:

  [ 1 ] Bug #1849793 - Please build rdesktop for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1849793


___
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] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 730  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
 469  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b   
bubblewrap-0.3.3-2.el7
 179  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6   
python-waitress-1.4.3-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5d276cc1c4   
hylafax+-7.0.3-1.el7


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

python-apprise-0.8.7-1.el7

Details about builds:



 python-apprise-0.8.7-1.el7 (FEDORA-EPEL-2020-2c97068bc3)
 A simple wrapper to many popular notification services used today

Update Information:

Updated to v0.8.7

ChangeLog:

* Thu Aug 13 2020 Chris Caron  - 0.8.7-1
- Updated to v0.8.7
* Mon Aug  3 2020 Chris Caron  - 0.8.6-4
- Updated SPEC so Fedora 33 Mass Rebuild would pass
* Sat Aug  1 2020 Fedora Release Engineering  - 
0.8.6-3
- Second attempt - Rebuilt for
  https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Tue Jul 28 2020 Fedora Release Engineering  - 
0.8.6-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.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 1867692] airscan driver crashes in mock during wsdd_cleanup()

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #13 from Fedora Update System  ---
FEDORA-2020-841f4ce8df has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-841f4ce8df`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-841f4ce8df

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
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 1860598] perl-Encode-3.07 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Encode-3.07-457.fc33   |perl-Encode-3.07-457.fc33
   |perl-Encode-3.07-457.fc32   |perl-Encode-3.07-457.fc32
   ||perl-Encode-3.07-457.fc31



--- Comment #10 from Fedora Update System  ---
FEDORA-2020-bf1678a097 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Adam Williamson]

On Thu, 2020-08-13 at 17:10 -0700, Adam Williamson wrote:
> A new build of libreport was done for all releases today by mfabik:
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1592551
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1592550
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1592524
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1592531
> 
> This build changes the soname of libreport from libreport.so.0 to
> libreport.so.1 (and indeed does introduce several API and ABI changes).
> 
> It was sent out as a 'stable' update for F31 and F32 (despite the
> soname bump). None of libreport's dependencies - notably including abrt
> - have been rebuilt for any release, AFAIK.
> 
> This means abrt is uninstallable in F33 and Rawhide build roots at
> present and probably will break subsequent F33 and Rawhide composes
> because there are probably release-blocking images with abrt in them. I
> have filed negative karma on the F31 and F32 updates, which failed
> openQA testing due to this issue.
> 
> It seems a new release of abrt has been made upstream, but at least one
> commit *after* that release looks necessary for the latest libreport.
> Additionally my first attempt to build the new release failed because
> the tarball was missing a file:
> https://github.com/abrt/abrt/issues/1519
> I am continuing to try and get a successful abrt build, but if we can't
> manage at least that, we will need to untag this build for F33 and
> Rawhide.

Follow up: couldn't get an abrt build to fly. It appears that the spec
file is lying about the source tarball locations. It points to the
github archive, but the tarball that's in dist-git for 2.14.2 is
clearly *not* the one you get from the github archive:

[adamw@adam abrt (master %)]$ spectool -g abrt.spec
Downloading: https://github.com/abrt/abrt/archive/2.14.2/abrt-2.14.2.tar.gz
[adamw@adam abrt (master %)]$ sha256sum abrt-2.14.2.tar.gz
df9ae2e649319ceffa64a301d946c6cfc6e8c7156566ec783fb6bf3c7c8c8249  
abrt-2.14.2.tar.gz
[adamw@adam abrt (master %)]$ rm -f abrt-2.14.2.tar.gz 
[adamw@adam abrt (master %)]$ fedpkg srpm
Downloading abrt-2.14.2.tar.gz
[adamw@adam abrt (master %)]$ sha256sum abrt-2.14.2.tar.gz 
735b97f6e6ae5af431aa68abd39c185f6de6afcbfe29453d26d696eeab24c0e4  
abrt-2.14.2.tar.gz

'spectool -g' downloads the tarball from wherever the spec file claims
it is from, 'fedpkg srpm' command downloads the tarball from dist-git;
as you can see, the two are not the same. The one from github is just a
github auto-generated source tree dump, without the autogen.sh script
run on it; the one from dist-git is a "real" release tarball, which
clearly did have autogen.sh run on it, but I can find no indication
anywhere of where such "real" release tarballs can actually be
downloaded, hence nowhere to get one for 2.14.3. It seems they used to
be published on fedorahosted.org, but that is shut down now, and I
can't find any other location mentioned anywhere.

If I use the github tarball and try to run `autoreconf -i -f` on it I
get a weirdly broken configure which has just a '.' command in the
middle of the comments at the top, and doesn't work. No idea why that
happens.

Anyway, since I can't get abrt to build, mboddu has untagged libreport
2.14.0 from F33 and Rawhide for now. They can be retagged once someone
sorts this mess out.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1810831] Please build an EPEL8 build for perl-DateTime-Format-DateParse

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2020-08-14 00:24:54



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-4e78eb6d88 has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.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 1853722] Include perl-XMLRPC-Lite in EPEL 8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2020-08-14 00:24:48



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-3a5d900fe6 has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


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

Unannounced soname bump: libreport

[Adam Williamson]

A new build of libreport was done for all releases today by mfabik:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1592551
https://koji.fedoraproject.org/koji/buildinfo?buildID=1592550
https://koji.fedoraproject.org/koji/buildinfo?buildID=1592524
https://koji.fedoraproject.org/koji/buildinfo?buildID=1592531

This build changes the soname of libreport from libreport.so.0 to
libreport.so.1 (and indeed does introduce several API and ABI changes).

It was sent out as a 'stable' update for F31 and F32 (despite the
soname bump). None of libreport's dependencies - notably including abrt
- have been rebuilt for any release, AFAIK.

This means abrt is uninstallable in F33 and Rawhide build roots at
present and probably will break subsequent F33 and Rawhide composes
because there are probably release-blocking images with abrt in them. I
have filed negative karma on the F31 and F32 updates, which failed
openQA testing due to this issue.

It seems a new release of abrt has been made upstream, but at least one
commit *after* that release looks necessary for the latest libreport.
Additionally my first attempt to build the new release failed because
the tarball was missing a file:
https://github.com/abrt/abrt/issues/1519
I am continuing to try and get a successful abrt build, but if we can't
manage at least that, we will need to untag this build for F33 and
Rawhide.

Other dependencies are abrt-java-connector and reportd, which I haven't
looked into it detail yet.

Please remember to announce soname bumps ahead of time so this kind of
problem can be avoided. Thanks. Please also try and generally do a
better job of release engineering and co-ordination...:)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: [Fedocal] Reminder meeting : EPEL Steering Committee

[Troy Dawson]

Due to several people not being available, this week's meeting has
been canceled.

On Thu, Aug 13, 2020 at 2:01 PM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>EPEL Steering Committee on 2020-08-14 from 21:00:00 to 22:00:00 UTC
>At freenode@fedora-meeting
>
> The meeting will be about:
> This is the weekly EPEL Steering Committee Meeting.
>
> A general agenda is the following:
>
> #meetingname EPEL
> #topic Intros
> #topic Old Business
> #topic EPEL-6
> #topic EPEL-7
> #topic EPEL-8
> #topic Openfloor
> #endmeeting
>
>
>
>
> Source: https://apps.fedoraproject.org/calendar/meeting/9722/
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: fedpkg update: Could not locate column in row for column 'comments.id'"

[Adam Williamson]

On Thu, 2020-08-13 at 18:46 -0400, Chris wrote:
> Hi guys,
> 
> I'm going through the typical routine of pushing my repository up to EPEL
> (fc33, fc32, fc31, and epel8)... all goes smoothly until this command:
> 
> fedpkg update --type enhancement
> 
> I get the following returned:
> Could not execute update: Could not generate update request: Unable to
> create update.  "Could not locate column in row for column 'comments.id'"
> A copy of the filled in template is saved as bodhi.template.last

I think it's a bug in Bodhi on the server end since we deployed 5.5
recently. It's also happening on `bodhi updates download`, which I
filed: https://github.com/fedora-infra/bodhi/issues/4105
For me it happens about one in every six times.

I've been poking through the commit log but haven't identified a clear-
cut suspect yet...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: nothing provides kernel needed by libguestfs-1:1.43.1-4.fc33.x86_64

[Kevin Fenzi]

On Wed, Aug 12, 2020 at 02:43:15PM +0200, Miro Hrončok wrote:
> On 12. 08. 20 14:39, Richard W.M. Jones wrote:
> > There is indeed no kernel package I can find that's tagged into
> > f34, but there is one tagged into f33:
> > 
> >https://koji.fedoraproject.org/koji/buildinfo?buildID=1579426
> > 
> > Shouldn't that be enough to satisfy the dependency above through tag
> > inheritance?
> 
> AFAIK there is no inheritance. Upon branching, all f33 tagged builds are
> tagged to f34 and that's it. For some reason this one wasn't -- not sure if
> intentional or accidental.

This was caused by the new release engineer doing the branching not
having secure-boot perms, so it didn't let him tag the kernel and a few
other packages into f34. :) We fixed the packages and made sure he was
added. 

Thanks for noticing it tho so we could fix it. :) 

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

fedpkg update: Could not locate column in row for column 'comments.id'"

[Chris]

Hi guys,

I'm going through the typical routine of pushing my repository up to EPEL
(fc33, fc32, fc31, and epel8)... all goes smoothly until this command:

fedpkg update --type enhancement

I get the following returned:
Could not execute update: Could not generate update request: Unable to
create update.  "Could not locate column in row for column 'comments.id'"
A copy of the filled in template is saved as bodhi.template.last

The command works perfectly with epel7 (and behaves as normal); Here is the
output of the file created: 'bodhi.template.last' (looks the same for
others minus first line)
[ python-apprise-0.8.7-1.fc31 ]

# bugfix, security, enhancement, newpackage (required)
type=enhancement

# testing, stable
request=testing

# Bug numbers: 1234,9876
bugs=

# Severity: low, medium, high, urgent
# This is required for security updates.
# severity=unspecified

display_name=


# Here is where you give an explanation of your update.
# Content can span multiple lines, as long as they are indented deeper than
# the first line. For example,
# notes=first line
# second line
# and so on
notes=Updated to v0.8.7

# Enable request automation based on the stable/unstable karma thresholds
autokarma=True
stable_karma=3
unstable_karma=-3

# Automatically close bugs when this marked as stable
close_bugs=True

# Suggest that users restart after update
suggest_reboot=False

# A boolean to require that all of the bugs in your update have been
confirmed by testers.
require_bugs=True

# A boolean to require that this update passes all test cases before
reaching stable.
require_testcases=True


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

[Test-Announce] [Test Week] Kernel 5.8 2020-08-17

[Sumantro Mukherjee]

Hey All,

I would like to invite all of you to participate in the Kernel 5.8
Test week which is happening from 2020-08-17 to 2020-08-24. It's
fairly simple, head over to the wiki [0] and read in details about the
test week and simply run the test case mentioned in[1] and enter your
results.

As usual, the Fedora QA team will hangout at #fedora-test-day@freenode
for question and
discussion.


[0] http://fedoraproject.org/wiki/Test_Day:2020-08-17_Kernel_5.8_Test_Week
[1] http://testdays.fedorainfracloud.org/events/89

-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 33 blocker status

[Ben Cotton]

We've branched, so let's start the weekly blocker status email yay

Action summary


Accepted blockers
-
1. libreport — abrt-server errors when processing zstd compressed core
dumps produced by systemd-246~rc1-1.fc33 — POST
ACTION: abrt maintainers to make a new release containing the fix

2. resteasy — FreeIPA deployment fails in current Rawhide due to
various issues with Java 11 — NEW
ACTION: resteasy maintainers to diagnose issue and fix or pass the
buck as appropriate

3. sddm — login stuck when changing users repeatedly (log out, log in
a different one) — NEW
ACTION: sddm maintainers to diagnose issue and fix or pass the buck as
appropriate

4. selinux-policy — SELinux is preventing systemd-machine from
'create' accesses on the sock_file io.systemd.Machine. — POST
ACTION: selinux-policy maintainers to make a new release containing the fixes

5. tomcat — FreeIPA server deployment fails in
Fedora-Rawhide-20200714.n.0 — MODIFIED
ACTION: tomcat maintainers to investigate failed upgrade test


Proposed blockers
-

1. gnome-shell — Network manager started stuck when I tries connecting
to VPN (openconnect) after upgrade gnome-shell to 3.37.1-1.fc33
version — NEW
ACTION: gnome-shell maintainers to diagnose issue

2. systemd  — systemd-resolved.service not work with DNS server placed
behind VPN (openconnect) — NEW
ACTION: systemd maintainers to diagnose issue

3. udisks2 — zram-setup@zram0.service: Failed to load configuration:
No such file or directory — NEW
ACTION: Someone! to figure out why udisks2-zram gets pulled in

Bug-by-bug detail
=

Accepted blockers
-
1. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1860616 — POST
abrt-server errors when processing zstd compressed core dumps produced
by systemd-246~rc1-1.fc33

abrt doesn't support core dumps compressed with zstd, which is now
used by systemd. Merged upstream PR uses libarchive to add support for
zstd (and other compression formats):
https://github.com/abrt/libreport/pull/656.

2. resteasy — https://bugzilla.redhat.com/show_bug.cgi?id=1866570 — NEW
FreeIPA deployment fails in current Rawhide due to various issues with Java 11

Deploying FreeIPA fails with a traceback in pki-tomcat. This appears
to be a dependency chain issue that (currently) ends at resteasy via
dogtag-pki. This may not be the last layer in the Java 11 onion.

3. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=1861700 — NEW
login stuck when changing users repeatedly (log out, log in a different one)

This is now a blocker based on a recent approval-in-principle of a
release criterion related to logout and user switching. User processes
linger after logout which blocks logging in when another user has
logged in between the two sessions. Or when the second user logs back
in. Or when a single user logs in repeatedly. Using
KillUserProcesses=Yes helps the first problem, but raises on of its
own. It appears to be a race condition of some kind as the behavior is
not fully consistent.

4. selinux-policy — https://bugzilla.redhat.com/show_bug.cgi?id=1862686 — POST
SELinux is preventing systemd-machine from 'create' accesses on the
sock_file io.systemd.Machine.

librvirt VMs and systemd-machined service fail with AVC denials.
Merged upstream PRs should fix the denials mentioned in this bug:
https://github.com/fedora-selinux/selinux-policy/pull/405 and
https://github.com/fedora-selinux/selinux-policy/pull/407

5. tomcat — https://bugzilla.redhat.com/show_bug.cgi?id=1857043 — MODIFIED
FreeIPA server deployment fails in Fedora-Rawhide-20200714.n.0 due to
pki-tomcat failing to run with "java.lang.ClassNotFoundException:
org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource"

An upstream commit resulted in tomcat-coyote.jar missing packages. A
previous fix (FEDORA-2020-f897a68801) moved the goalposts.
tomcat-9.0.37-3 should fix this. Verification is blocked on BZ1866570,
but Adam's most recent upgrade test still fails with a
ClassNotFoundException for
com.sun.xml.internal.bind.v2.ContextFactory.


Proposed blockers
-

1. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=1830343 — NEW
Network manager started stuck when I tries connecting to VPN
(openconnect) after upgrade gnome-shell to 3.37.1-1.fc33 version

Connecting to an OpenConnect VPN using 2FA hangs after the second
factor is entered. The journal contains an array.toString() message
which may or may not be a red herring (it looks like a deprecation
warning).

2. systemd — https://bugzilla.redhat.com/show_bug.cgi?id=1863041 — NEW
systemd-resolved.service not work with DNS server placed behind VPN
(openconnect)

When connected to an OpenConnect VPN, host name resolution fails.
Manually disabling the systemd-resolved service works around this
issue.

3. udisks2 — https://bugzilla.redhat.com/show_bug.cgi?id=1861463 — NEW
zram-setup@zram0.service: Failed to load configuration: No such file
or directory

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

[tdawson]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2020-08-14 from 21:00:00 to 22:00:00 UTC
   At freenode@fedora-meeting

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

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




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

___
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: EXTERNAL: Re: hundred percent cpu load

[Wells, Roger K. via devel]

On 8/13/20 4:28 PM, Przemek Klosowski via devel wrote:
> On 8/13/20 4:12 PM, Wells, Roger K. via devel wrote:
>>   I'll do something to disable it.
>
> Oh, just thougth I'd mention---what I'd do would be
>
> locate sadc <- hopefully this would return the location of the
> sadc binary, perhaps /var/lib64/sa/sadc
>
> rpm -qf /var/lib64/sa/sadc  <- this will report which package is sadc
> a part of, perhaps sysstat
>
> yum erase sysstat  <- deletes the offending package once and for all.
Thanks for the instructions.  I'll report back
> ___
> 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


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

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

Re: EXTERNAL: Re: hundred percent cpu load

[Wells, Roger K. via devel]

On 8/13/20 4:23 PM, Przemek Klosowski via devel wrote:
On 8/13/20 4:12 PM, Wells, Roger K. via devel wrote:

So sadc is not part of current Fedora. It may be some artifact from
older Fedoras (e.g. sysstat-11.5.7-4.fc27.x86_64 has
/usr/lib64/sa/sadc) or some custom system activity data collection
software that is locally installed at your site.


Thanks. I'll do something to disable it.  FWIW, this computer has never
run anything but Fedora since day1.


Did you install F32 from scratch, or was it an upgrade from earlier versions? 
If you had F27 on it, upgraded to 28->29->30->31->32, it would explain how sadc 
got on it.

Also, I have a Fedora box but my work installs third party management and 
monitoring software on it that is not part of official Fedora, so that would be 
another avenue for something called sadc to get on your Fedora box.

No, it has had several fedora releases and many updates.  I don't recall where 
it started.  F27 is possible though.
That's why I was going to do a fresh install (mentioned in the original)
I am the only one who puts anything on this machine though, so no third party 
management or monitoring.
I just thought that it might be worth understanding what's going on here in 
case someone else is affected now or later.
Thanks for your interest



___
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



--
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

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

Re: EXTERNAL: Re: hundred percent cpu load

[Przemek Klosowski via devel]

On 8/13/20 4:12 PM, Wells, Roger K. via devel wrote:

  I'll do something to disable it.


Oh, just thougth I'd mention---what I'd do would be

locate sadc <- hopefully this would return the location of the sadc 
binary, perhaps /var/lib64/sa/sadc


rpm -qf /var/lib64/sa/sadc  <- this will report which package is sadc a 
part of, perhaps sysstat


yum erase sysstat  <- deletes the offending package once and for all.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: EXTERNAL: Re: hundred percent cpu load

[Przemek Klosowski via devel]

On 8/13/20 4:12 PM, Wells, Roger K. via devel wrote:

So sadc is not part of current Fedora. It may be some artifact from
older Fedoras (e.g. sysstat-11.5.7-4.fc27.x86_64 has
/usr/lib64/sa/sadc) or some custom system activity data collection
software that is locally installed at your site.

Thanks. I'll do something to disable it.  FWIW, this computer has never
run anything but Fedora since day1.


Did you install F32 from scratch, or was it an upgrade from earlier 
versions? If you had F27 on it, upgraded to 28->29->30->31->32, it would 
explain how sadc got on it.


Also, I have a Fedora box but my work installs third party management 
and monitoring software on it that is not part of official Fedora, so 
that would be another avenue for something called sadc to get on your 
Fedora box.


___
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: EXTERNAL: Re: hundred percent cpu load

[Wells, Roger K. via devel]

On 8/13/20 4:05 PM, Przemek Klosowski via devel wrote:
> On 8/13/20 2:04 PM, Wells, Roger K. via devel wrote:
>> After some time, usually hours, the following four tasks in top are
>> running at 100%:
>> sadc
>> kworker/6:1+events_freezable
>> dmesg
>> systemd-journal
>
> So sadc is not part of current Fedora. It may be some artifact from
> older Fedoras (e.g. sysstat-11.5.7-4.fc27.x86_64 has
> /usr/lib64/sa/sadc) or some custom system activity data collection
> software that is locally installed at your site.
>
> My guess is it goes bonkers and causes frantic kernel worker thread
> activity, and generates tons of messges, keeping dmesg and journal
> busy. Please look into that, and let us know what you find out.
Thanks. I'll do something to disable it.  FWIW, this computer has never
run anything but Fedora since day1.
> ___
> 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


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

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

Re: hundred percent cpu load

[Przemek Klosowski via devel]

On 8/13/20 2:04 PM, Wells, Roger K. via devel wrote:

After some time, usually hours, the following four tasks in top are
running at 100%:
sadc
kworker/6:1+events_freezable
dmesg
systemd-journal


So sadc is not part of current Fedora. It may be some artifact from 
older Fedoras (e.g. sysstat-11.5.7-4.fc27.x86_64 has /usr/lib64/sa/sadc) 
or some custom system activity data collection software that is locally 
installed at your site.


My guess is it goes bonkers and causes frantic kernel worker thread 
activity, and generates tons of messges, keeping dmesg and journal busy. 
Please look into that, and let us know what you find out.

___
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

Advice for packaging a TI msp430 cross compiler

[Brandon Nielsen]

I have been working toward getting a "modern" cross compiling toolchain 
included in Fedora[0] ever since mspgcc stopped working[1] 4 years ago. 
Up until recently, my efforts have been almost entirely centered around 
packaging TI / Mitto Systems' somewhat bespoke branch of GCC[2].


It has been suggested[3] that my efforts may be better focused on having 
msp430-none-elf (and possibly msp430-none-elf-bare) added as an arch to 
the cross-gcc / cross-binutils packages. This would require building a 
msp430-none-elf-newlib package as well.


I have managed to build modified cross-gcc and cross-binutils packages 
with a matching newlib package. Code compiles and links, but the 
resulting binary does not actually work on the micro. I suspect the 
correct linker script is not being used, but I have not had time to 
investigate further and am somewhat over my head in building and 
troubleshooting cross compilers.


Which path forward is recommended? Option one, the bespoke branch, 
already produces a working toolchain[4]. Option two, modified cross-gcc 
/ cross-binutils has a lot more appeal being 'vanilla' upstream, and 
adds the possibility of supporting the 'bare' msp430 target, but I'm a 
bit lost in how to get the parts to produce a functional binary.


[0] - https://bugzilla.redhat.com/show_bug.cgi?id=1350884
[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1175942
[2] - https://www.ti.com/tool/MSP430-GCC-OPENSOURCE
[3] - 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KAYAKXOY7ZPQEENB6PUM2EEUN53X2HQQ/
[4] - 
https://copr.fedorainfracloud.org/coprs/nielsenb/msp430-development-tools/




___
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: hundred percent cpu load

[Chris Murphy]

On Thu, Aug 13, 2020 at 12:04 PM Wells, Roger K. via devel
 wrote:
>
> Current kernel: 5.7.12-200.fc32.x86_64
> gnome desktop
> PC: Thinkpad X280, intel core i7, 8th gen
>
> After some time, usually hours, the following four tasks in top are
> running at 100%:
> sadc

What is this? I don't have it running or installed on my system, and
dnf search returns nothing.

cat /proc//stack

To get a stack trace for that sadc process, and I guess file a bug
against it, whatever it is.

And also a complete dmesg might reveal something to go on.


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

hundred percent cpu load

[Wells, Roger K. via devel]

Current kernel: 5.7.12-200.fc32.x86_64
gnome desktop
PC: Thinkpad X280, intel core i7, 8th gen

After some time, usually hours, the following four tasks in top are
running at 100%:
sadc
kworker/6:1+events_freezable
dmesg
systemd-journal

sometimes there are only three of these at 100% but usually four, never
more.
I have not been able to come up with a sequence of steps to cause it.
At this point the only way to shut down is to use the power switch, it
will run forever in a normal shutdown as the timeout limits increase.
The next start up will always be strange:
Things will proceed apparently normally up to the login opportunity:
    If I check the upper right corner I will see that the wired and
wireless networks are both up.
    After I login the wireless will not be up and nothing I try will
bring it up.
There will also be notifications about "problems", up to 35 occurrences
of "system problem" and "kerneloops" none of which is "reportable"
This login process will have to be repeated probably twice before a
normal environment with wireless network operating.

This also occurred prior to the last one or two updates.

At this point I think I will do a clean install.
I have assumed that if this happened to others it would have appeared
here already, but just in case

I have been using Fedora forever as a software system development platform
screen shot of "top" available if anyone wants it.

-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

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

Re: BleachBit is available in the repos, but does not appear when searching in GNOME Software

[Andrew Toskin]

> Do you have the latest appstream-data installed? I believe it went to
> stable a few days ago.
> 
> Richard.

Turns out this was the problem. appstream-data had maybe lagged a little 
behind, so the new BleachBit package didn't show up in Software right away. I 
updated all system packages again today, and now BleachBit appears in search 
results, with a working app icon and everything. Thanks!
___
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: Please untag dotnet3.1-3.1.106-1.fc33

[Kevin Fenzi]

On Thu, Aug 13, 2020 at 09:23:35AM -0600, Jeff Law wrote:
> On Thu, 2020-08-13 at 11:13 -0400, Omair Majid wrote:
> > Jeff Law  writes:
> > 
> > > I can't help with the untagging, but I'm here if there's anything
> > > going wrong with the system tools that is ultimately affecting dotnet.
> > 
> > Thanks.
> > 
> > Just for context:
> > 
> > .NET Core uses a bundled (and modified) copy of libunwind for unwinding
> > the stack. This version doesn't work on aarch64 when built with one of
> > the new CFLAGS introduced in Fedora 33/34: -mbranch-protection=standard.
> > 
> > The upstream version of libunwind (the Fedora libunwind package) is also
> > broken (in a completely different way) for aarch64 from a .NET Core
> > point of view too.
> > 
> > For now, my "fix" is to remove `-mbranch-protection=standard` from
> > CFLAGS on aarch64 to get things working.
> That may work in the immediate term, but I think we'll need a better fix in 
> the
> long term -- I believe the plan is to have the BTI/PAC stuff enabled by 
> default
> for RHEL 9.  We can bug ARM to get upstream libunwind fixed if that would help
> (we meet with them Monday -- you'd be welcome to join to provide technical
> context to the libunwind issue).

FYI for the list: 

We talked about this on irc. We cannot untag that package as it's long
since been shipped out. However, a side tag can be used to build against
the old version:

* create side tag
* tag old version into it
* build new version against old working version. 
* merge side tag

This should allow everything to build and not disrupt all the people who
have the current version already installed, etc. 

kevin


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

Re: What is the real value of Release and %changelog metadata?

[Chris Adams]

Once upon a time, Matthew Miller  said:
> On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
> > Such %changelog has a very similar level of quality as all the generated
> > approaches, and we don't have to complicate our lives (or buildsystem).
> > Alternatively, we can teach build systems to upload the git-log file
> > somewhere, or even extremely drop the changelog entirely (and only
> > reference the upstream changelog in %doc payload).
> 
> Yeah, I like automatically including the git changelog as %doc at somewhere
> like `/usr/share/doc/rpm-changelogs/$PACKAGENAME`. As a sysadmin in the
> past, I've found it handy to be able to reference this directly on the
> system.

That makes it extra steps to see changelogs on a not-installed package.
I do sometimes do "rpm -q --changelog -p foo.rpm" or "dnf changelog foo"
(for example, to see what is changed since my installed version).
Converting to an installed file means I would have to extract the RPM
(possibly after manually downloading) and find it under a different
directory for every RPM - much less convenient.

-- 
Chris Adams 
___
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: BleachBit is available in the repos, but does not appear when searching in GNOME Software

[Andrew Toskin]

> We also have an icon size requirement. The app needs to provide an icon 
> that's at
> least 64x64 (or maybe even 128x128?).

The package does contain an icon, a 256×256 pixel PNG with a transparency 
channel.

- https://github.com/bleachbit/bleachbit/blob/master/bleachbit.png
- Installed to /usr/share/pixmaps/bleachbit.png

Is that larger size good enough on its own, or does there need to be a separate 
icon that's exactly 128×128 pixels too? Does AppStream expect the icon to be 
installed at a specific location, or is any standard icon path acceptable?

I don't know about adding a high-contrast icon, or where that would usually get 
installed to. But probably I would need to recommend that the upstream creates 
one.
___
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 1868187] perl-Devel-PPPort-3.60 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version|perl-Devel-PPPort-3.60-1.fc |perl-Devel-PPPort-3.60-1.fc
   |34  |33
 Resolution|--- |NEXTRELEASE
Last Closed||2020-08-13 16:36:08




-- 
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 1868736] New: perl-MongoDB-2.2.2 is available

[bugzilla]

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

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



Latest upstream release: 2.2.2
Current version/release in rawhide: 2.2.1-2.fc32
URL: http://search.cpan.org/dist/MongoDB/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/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/3121/


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

Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem

[Bohdan Khomutskyi]

Hello,

I have implemented the necessary changes in Pungi, the software that 
creates Fedora compose. So this change has a potential of moving forward.


I have created 2 pull-requests for release engineering for this change:

https://pagure.io/pungi-fedora/pull-request/871

https://pagure.io/pungi-fedora/pull-request/872

Fedora release engineering would have the ability to test this change 
and provide fresh test results after Pungi 4.2.4 is released.


I hope this change could land in Fedora 33.

As a reminder, here is the change proposal: 
https://fedoraproject.org/wiki/Changes/OptimizeSquashFS


Regards,

On 13/05/2020 13:32, Bohdan Khomutskyi wrote:


Hello,

It was a long time since the last message in this change proposal.

Recently I was working to reduce the impact of the increased 
compression ratio on the installation image size for Fedora. I have 
achieved outstanding results -- working proof of concept. With the 
following change: https://github.com/rhinstaller/anaconda/pull/2292 , 
not only the higher compression does not impact the installation time. 
In certain cases, the installation time is even reduced. This is 
because of the fact the filesystem internal structure aware process is 
used to install the system from the SquashFS. The new process also 
allows for taking advantage of the multi-core architecture of the 
system during installation -- does the decompression on multiple 
processors in parallel.


The combination of https://github.com/rhinstaller/anaconda/pull/2292 
and https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS 
should reduce _both_ the image size and the installation time. The 
installation time will be reduced in case the system is installed from 
the SquashFS. This is the case in Fedora Workstation.


For optimization of the SquashFS, I will work on requesting the 
support of the required functionality in the Pungi compose build software.


On 25/01/2020 16:36, Bohdan Khomutskyi wrote:

Hello,

I opened a request to anaconda team with a draft patch to use 
unsquashfs instead of rsync: 
https://github.com/rhinstaller/anaconda/pull/2292.

That should lower the installation time from Live media.
Adjustments should be made to make this patch work, I was not able to 
install the image using this patch. Anaconda installer crashes.


Chris,

> Could this be read amplification?
> That's probably mitigated with unsquashfs.
That could be read amplification, it will be mitigated with unsquashfs.
The memory usage should not be a problem: xz (1) manual page, states 
that 2 MiB of memory required to decompress an archive with 1MiB 
block size. My previous observations found that the squashfs is 
currently decompressed in single thread. I welcome additional 
testing, but I think the memory limit will not be a problem.


> If image size is a significant consideration, then evaluation of erofs
> seems indicated. It promises both significant compression and CPU
> performance. The intended use case is for Android device read-only
> partitions with both limited storage and CPU/power capacity.

I briefly reviewed the document and found that LZ4 is the only 
supported algorithm in EROFS, even if EROFS has perfect layout of the 
filesystem, it's to good to be true it can outperform the XZ in 
compression ratio tests. The difference for SquashFS LZ4hc 1M vs XZ 
1M is >40%.


On Fri, Jan 24, 2020 at 2:17 AM Chris Murphy > wrote:


On Mon, Jan 20, 2020 at 1:38 AM Bohdan Khomutskyi
mailto:bkhom...@redhat.com>> wrote:
>
> In my previous message, I mentioned that CPU is underutilized
during installation. I haven't investigated further why, but I
suspect it's due to the inefficiency caused by the usage of the
loop device and/or inefficiency in the rsync itself.

Could this be read amplification?

This paper on erofs suggests read amplification can be a significant
side effect with squashfs. It could be exacerbated with random reads,
and I expect it gets worse with larger block size. That's probably
mitigated with unsquashfs.

Specifically page 4, 2nd paragraph.
https://www.usenix.org/system/files/atc19-gao.pdf

This also makes me wonder about the memory consumption effect of a 1M
block size, especially for Fedora ARM where it looks like
Raspberry Pi
2B

Most of the ARM images are raw.xz but some are bootable ISOs, dvd and
netinstall. And those contain a squashfs sysroot. Even if there's no
out of memory problem, it could result in paging. All ISOs setup
swap-on-ZRAM these days, lives, DVD, and netinstall. I think the ARM
case needs testing before committing to 1M block size across all
ISOs,
or implementing changes in Fedora release engineering.


-- 
Chris Murphy




--
Bohdan Khomutskyi, RHCE
Release configuration management engineer, PnT DevOps
Red Hat Czech s.r.o
T: +420532270289 IRC: bkhomuts

--
Bohdan Khomutskyi

Red Hat


--
Bohdan 

Re: What is the real value of Release and %changelog metadata?

[Matthew Miller]

On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
> Such %changelog has a very similar level of quality as all the generated
> approaches, and we don't have to complicate our lives (or buildsystem).
> Alternatively, we can teach build systems to upload the git-log file
> somewhere, or even extremely drop the changelog entirely (and only
> reference the upstream changelog in %doc payload).

Yeah, I like automatically including the git changelog as %doc at somewhere
like `/usr/share/doc/rpm-changelogs/$PACKAGENAME`. As a sysadmin in the
past, I've found it handy to be able to reference this directly on the
system.


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

[Bug 1868727] New: perl-BSON-1.12.2 is available

[bugzilla]

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

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



Latest upstream release: 1.12.2
Current version/release in rawhide: 1.12.1-2.fc32
URL: http://search.cpan.org/dist/BSON/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/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/12628/


-- 
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: Please untag dotnet3.1-3.1.106-1.fc33

[Jeff Law]

On Thu, 2020-08-13 at 11:13 -0400, Omair Majid wrote:
> Jeff Law  writes:
> 
> > I can't help with the untagging, but I'm here if there's anything
> > going wrong with the system tools that is ultimately affecting dotnet.
> 
> Thanks.
> 
> Just for context:
> 
> .NET Core uses a bundled (and modified) copy of libunwind for unwinding
> the stack. This version doesn't work on aarch64 when built with one of
> the new CFLAGS introduced in Fedora 33/34: -mbranch-protection=standard.
> 
> The upstream version of libunwind (the Fedora libunwind package) is also
> broken (in a completely different way) for aarch64 from a .NET Core
> point of view too.
> 
> For now, my "fix" is to remove `-mbranch-protection=standard` from
> CFLAGS on aarch64 to get things working.
That may work in the immediate term, but I think we'll need a better fix in the
long term -- I believe the plan is to have the BTI/PAC stuff enabled by default
for RHEL 9.  We can bug ARM to get upstream libunwind fixed if that would help
(we meet with them Monday -- you'd be welcome to join to provide technical
context to the libunwind issue).

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

Re: Please untag dotnet3.1-3.1.106-1.fc33

[Omair Majid]

Jeff Law  writes:

> I can't help with the untagging, but I'm here if there's anything
> going wrong with the system tools that is ultimately affecting dotnet.

Thanks.

Just for context:

.NET Core uses a bundled (and modified) copy of libunwind for unwinding
the stack. This version doesn't work on aarch64 when built with one of
the new CFLAGS introduced in Fedora 33/34: -mbranch-protection=standard.

The upstream version of libunwind (the Fedora libunwind package) is also
broken (in a completely different way) for aarch64 from a .NET Core
point of view too.

For now, my "fix" is to remove `-mbranch-protection=standard` from
CFLAGS on aarch64 to get things working.

Thanks,
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: EarlyOOM +ZRAM Only

[Chris Murphy]

On Wed, Aug 12, 2020 at 12:28 PM Sergio Belkin  wrote:
>
> Hi!
> I 've just had a problem using EarlyOOM + ZRAM. I haven't a disk-based swap 
> partition.
> I was using mainly Zoom (desktop app) + Firefox + VirtualBox (Debian with 4GB 
> of RAM), and EarlyOOM killed Zoom in the middle of a call :(

Hi,

Could you open a bug report against earlyoom, and attach 'journalctl
-b -o short-monotonic > bugID-journal.txt'

It's not necessary to trim it. But if you do, keep about 5-10 minutes
prior to the first SIGTERM.

I think what's happened is earlyoom issues multiple SIGTERM, which are
ignored or delayed in actually terminating by the processes with the
most badness. And it just so happens that the zoom process badness
reacted to the terminate request despite having an order magnitude
lower badness.

Off hand I'd say earlyoom probably should only SIGTERM the top 3
offenders, possibly with some delay in between each one. And then once
we're below the kill watermark, issue SIGKILL to the top offender
again.

The difficulty is that's a VM, in this case. We might need an
oom_score_adj for qemu and virtualbox, because I think it's a bad idea
to kill off running VM's.

-- 
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 the real value of Release and %changelog metadata?

[Björn Persson]

Pavel Raiskup wrote:
> Questionnaire right at the beginning, so if you tl;dr, you don't miss it:
> 
> https://forms.gle/Jgr13vtRkiUwLb6W6

The questionnaire itself is short, but understanding all the proposals
is considerable work. That's where TL;DR will happen.

> Let's stop requiring Release bumps for each build.  And let's put an
> additional tag into Release, like proposed in [4]:
> 
> "Release: 1%{?dist}%{?buildtag}"
> 
> ... and let the build-system to put there an artificial (but increasing for
> subsequent build IDs) value.

I am of course in favor of this, as I've already suggested it myself.

> Or alternatively, teach the build-system to enhance
> %dist in a similar fashion, as suggested in [5].

That would also work technically, although it would turn the name
"dist" into a misnomer.

>   %changelog
>   * This package doesn't provide changelog metadata, check it online
> https://src.fedoraproject.org/rpms//commits/

To the extent that users read changelogs at all, I think they would be
more interested in the upstream changelog than in the Fedora Git
changelog.

> Side question:  Is it really useful to put "Rebuilt for
> https://fedoraproject.org/wiki/Fedora_XX_Mass_Rebuild; into changelogs?

I don't see any use for those entries. There is already a build
timestamp in the package metadata.

Björn Persson


pgpMsq9P1nJQE.pgp
Description: OpenPGP digital signatur
___
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: Please untag dotnet3.1-3.1.106-1.fc33

[Jeff Law]

On Thu, 2020-08-13 at 10:21 -0400, Omair Majid wrote:
> Hi,
> 
> One of the recent builds produced for "dotnet3.1" for rawhide is broken
> on aarch64. It built successfully in koji, but produced aarch64 binaries
> that segfault on startup. A new build of dotnet3.1 requires a working
> older build. That means all recent builds of dotnet3.1 in Rawhide/F33 on
> failed too.
> 
> As I understand it, the most recent (broken) build needs to be untagged.
> Then a newer build can build using an older (working) build of
> dotnet3.1.
> 
> This is the broken build:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1544928
> 
> I tried it myself, but I don't seem to have permissions:
> 
> $ koji untag-build f33 dotnet3.1-3.1.106-1.fc33
> 2020-08-13 10:11:30,777 [ERROR] koji: ActionNotAllowed: tag requires autosign 
> permission
I can't help with the untagging, but I'm here if there's anything going wrong
with the system tools that is ultimately affecting dotnet.

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

Re: s390x/fedora33 build job hangs

[Ralf Corsepius]

On 8/13/20 3:17 PM, Fabio Valentini wrote:

On Thu, Aug 13, 2020 at 3:15 PM Ralf Corsepius  wrote:


Hi,

A f33 build job, I launched a couple of hours ago, seems to hang on s390

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

What am I supposed to do?

Ralf


Wait. It's not hanging, it's not running yet.

Looking at [0] all the s390x builders are busy right now, so it's just
a matter of time until they become free again and your build will
proceed then.


Thanks, you were right.

I simply didn't expect a build job which usually takes very few minutes 
to build, to take 2hours+ for f33/s390x ;)


Ralf
___
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 1868434] perl-DBD-Pg-3.14.2 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-DBD-Pg-3.14.1 is   |perl-DBD-Pg-3.14.2 is
   |available   |available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 3.14.2
Current version/release in rawhide: 3.12.3-1.fc33
URL: http://search.cpan.org/dist/DBD-Pg/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/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/2809/


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

Please untag dotnet3.1-3.1.106-1.fc33

[Omair Majid]

Hi,

One of the recent builds produced for "dotnet3.1" for rawhide is broken
on aarch64. It built successfully in koji, but produced aarch64 binaries
that segfault on startup. A new build of dotnet3.1 requires a working
older build. That means all recent builds of dotnet3.1 in Rawhide/F33 on
failed too.

As I understand it, the most recent (broken) build needs to be untagged.
Then a newer build can build using an older (working) build of
dotnet3.1.

This is the broken build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1544928

I tried it myself, but I don't seem to have permissions:

$ koji untag-build f33 dotnet3.1-3.1.106-1.fc33
2020-08-13 10:11:30,777 [ERROR] koji: ActionNotAllowed: tag requires autosign 
permission

Thanks,
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: Deprecation of Anaconda boot parameters without inst. prefix

[Neal Gompa]

On Thu, Aug 13, 2020 at 9:43 AM  wrote:
>
> On Thu, 2020-08-13 at 09:22 -0400, Stephen John Smoogen wrote:
> > On Thu, 13 Aug 2020 at 08:58, Fabio Valentini 
> > wrote:
> > > On Thu, Aug 13, 2020 at 2:16 PM  wrote:
> > > > Hello everyone,
> > > >
> > > > Anaconda team has decided to deprecate use of Anaconda kernel
> > > > boot
> > > > parameters without 'inst.' prefix. As you may already know you
> > > > can
> > > > specify Anaconda kernel boot parameters both with and without
> > > > 'inst.'
> > > > prefix (e.g. 'inst.repo=' or 'repo='). This deprecation means
> > > > that when
> > > > you use Anaconda option without the 'inst.' prefix you will now
> > > > get a
> > > > warning. We are *not* disabling parameters without a prefix yet.
> > > >
> > > > The reason for this is keep running into parameter conflicts with
> > > > other
> > > > projects. As an example there is 'debug' parameter for both
> > > > kernel and
> > > > us, so when you want to enable kernel debugging in installation
> > > > environment you will also enable Anaconda debug mode.
> > > >
> > > > Because of this I have created the following pull request for
> > > > Anaconda:
> > > >
> > > > https://github.com/rhinstaller/anaconda/pull/2786
> > > >
> > > >
> > > > In case you have any objections please start discussion either on
> > > > the
> > > > pull request or here.
> > > >
> > > >
> > > > Best regards,
> > > > Jirka
> > >
> > > This may be a stupid question, but why are parameter namespaced
> > > with
> > > "inst." and not with "anaconda."? Is this a historical artifact?
> > > "inst" is a pretty generic term as well, and "anaconda" would
> > > definitely not lead to parameter overloading on the kernel cmdline.
> > >
> >
> > I think inst was meant to be universal so that debian etc could use
> > it. However I will say if I have to type 20 anaconda.= on
> > a serial terminal like I have to for the inst.= I will
> > quickly be looking for any other installer to use. I regularly end up
> > with enough redraw problems because the line went over whatever SOL
> > or
> > the HTML-console thinks a line should be and clearing the entire line
> > so I can't see what I am typing.
>
> I wasn't in the team when the decision to use `inst.` was made.
> However, I agree with Stephen that it's just shorter and some people
> have to write this a lot and lot of times. Also, it could be used for
> multiple installers if they want to.
>

It was intended to be a standard interface. And I'm pretty sure these
flags were created at around the same time that Anaconda was being
ported to Debian and having a generic prefix meant that
debian-installer could implement it. I don't know if d-i today
actually *does* have these, but I'm pretty sure that was the reason.

Though the cross-installer compatibility idea inspired the creation of
kickseed[1] for Debian and Ubuntu years later, too..

[1]: https://launchpad.net/kickseed

-- 
真実はいつも一つ！/ 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: Deprecation of Anaconda boot parameters without inst. prefix

[jkonecny]

On Thu, 2020-08-13 at 09:22 -0400, Stephen John Smoogen wrote:
> On Thu, 13 Aug 2020 at 08:58, Fabio Valentini 
> wrote:
> > On Thu, Aug 13, 2020 at 2:16 PM  wrote:
> > > Hello everyone,
> > > 
> > > Anaconda team has decided to deprecate use of Anaconda kernel
> > > boot
> > > parameters without 'inst.' prefix. As you may already know you
> > > can
> > > specify Anaconda kernel boot parameters both with and without
> > > 'inst.'
> > > prefix (e.g. 'inst.repo=' or 'repo='). This deprecation means
> > > that when
> > > you use Anaconda option without the 'inst.' prefix you will now
> > > get a
> > > warning. We are *not* disabling parameters without a prefix yet.
> > > 
> > > The reason for this is keep running into parameter conflicts with
> > > other
> > > projects. As an example there is 'debug' parameter for both
> > > kernel and
> > > us, so when you want to enable kernel debugging in installation
> > > environment you will also enable Anaconda debug mode.
> > > 
> > > Because of this I have created the following pull request for
> > > Anaconda:
> > > 
> > > https://github.com/rhinstaller/anaconda/pull/2786
> > > 
> > > 
> > > In case you have any objections please start discussion either on
> > > the
> > > pull request or here.
> > > 
> > > 
> > > Best regards,
> > > Jirka
> > 
> > This may be a stupid question, but why are parameter namespaced
> > with
> > "inst." and not with "anaconda."? Is this a historical artifact?
> > "inst" is a pretty generic term as well, and "anaconda" would
> > definitely not lead to parameter overloading on the kernel cmdline.
> > 
> 
> I think inst was meant to be universal so that debian etc could use
> it. However I will say if I have to type 20 anaconda.= on
> a serial terminal like I have to for the inst.= I will
> quickly be looking for any other installer to use. I regularly end up
> with enough redraw problems because the line went over whatever SOL
> or
> the HTML-console thinks a line should be and clearing the entire line
> so I can't see what I am typing.

I wasn't in the team when the decision to use `inst.` was made.
However, I agree with Stephen that it's just shorter and some people
have to write this a lot and lot of times. Also, it could be used for
multiple installers if they want to.

Jirka

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

[Stephen John Smoogen]

On Thu, 13 Aug 2020 at 08:58, Fabio Valentini  wrote:
>
> On Thu, Aug 13, 2020 at 2:16 PM  wrote:
> >
> > Hello everyone,
> >
> > Anaconda team has decided to deprecate use of Anaconda kernel boot
> > parameters without 'inst.' prefix. As you may already know you can
> > specify Anaconda kernel boot parameters both with and without 'inst.'
> > prefix (e.g. 'inst.repo=' or 'repo='). This deprecation means that when
> > you use Anaconda option without the 'inst.' prefix you will now get a
> > warning. We are *not* disabling parameters without a prefix yet.
> >
> > The reason for this is keep running into parameter conflicts with other
> > projects. As an example there is 'debug' parameter for both kernel and
> > us, so when you want to enable kernel debugging in installation
> > environment you will also enable Anaconda debug mode.
> >
> > Because of this I have created the following pull request for Anaconda:
> >
> > https://github.com/rhinstaller/anaconda/pull/2786
> >
> >
> > In case you have any objections please start discussion either on the
> > pull request or here.
> >
> >
> > Best regards,
> > Jirka
>
> This may be a stupid question, but why are parameter namespaced with
> "inst." and not with "anaconda."? Is this a historical artifact?
> "inst" is a pretty generic term as well, and "anaconda" would
> definitely not lead to parameter overloading on the kernel cmdline.
>

I think inst was meant to be universal so that debian etc could use
it. However I will say if I have to type 20 anaconda.= on
a serial terminal like I have to for the inst.= I will
quickly be looking for any other installer to use. I regularly end up
with enough redraw problems because the line went over whatever SOL or
the HTML-console thinks a line should be and clearing the entire line
so I can't see what I am typing.

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

Re: s390x/fedora33 build job hangs

[Fabio Valentini]

On Thu, Aug 13, 2020 at 3:15 PM Ralf Corsepius  wrote:
>
> Hi,
>
> A f33 build job, I launched a couple of hours ago, seems to hang on s390
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=49204466
>
> What am I supposed to do?
>
> Ralf

Wait. It's not hanging, it's not running yet.

Looking at [0] all the s390x builders are busy right now, so it's just
a matter of time until they become free again and your build will
proceed then.
[0]: https://koji.fedoraproject.org/koji/tasks

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

s390x/fedora33 build job hangs

[Ralf Corsepius]

Hi,

A f33 build job, I launched a couple of hours ago, seems to hang on s390

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

What am I supposed to do?

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

What is the real value of Release and %changelog metadata?

[Pavel Raiskup]

Questionnaire right at the beginning, so if you tl;dr, you don't miss it:

https://forms.gle/Jgr13vtRkiUwLb6W6

This is no change proposal but rather a result of my long-term curiosity
around the $Subject problem.  I hope I marked the results public so the
results are visible to anyone.

--

ATM, I know of at least those serious attempts to "automatize" the
%changelog maintenance and Release auto-bumping: [1, 2 and 3].

All those proposals are pretty complicated (I know, this is POV
statement), but some of them require significant changes in build systems
(like allowing the build system to back-push the generated stuff, building
the code variant which is not yet committed, so security problems, etc.).

It's not easy to decide the preferred variant...  :-)  But let me feed
the xkcd 927 :-)  here is another.  Call it e.g. the "Trivial" (or
compromise) variant.


Release tag problem/proposal


Let's stop requiring Release bumps for each build.  And let's put an
additional tag into Release, like proposed in [4]:

"Release: 1%{?dist}%{?buildtag}"

... and let the build-system to put there an artificial (but increasing for
subsequent build IDs) value.

Or alternatively, teach the build-system to enhance
%dist in a similar fashion, as suggested in [5].


The %changelog problem
==

IMO, all the burnouts and wasted time around %changelog is caused by those
things:

  a) we misinterpret what git-log is for, and what %chagnelog is for, but
  b) we are still forced to properly maintain the %changelog, and
  c) we have to duplicate %changelog in Bodhi

Simply put, IMO, there's no easy way to transform git-log to %changelog,
because those logs have different audiences (package users, vs. package
maintainers).

As I claimed somewhere before, as opt-in, I really don't see any problem
in allowing - as opt-in - any kind of the proposed automation.  Even all
of them. ...  so the questionnaire allows us to vote for (or against) all of
them.

But any such automation isn't for free ...  people do typos in changelog,
and tend to fix them quickly by follow-up commits.  Fixing changelog is
now a matter of just another commit, but with the automation - we have to
have proper syntax/semantics for fixes (and fixes for fixes), have some
commit filtering mechanisms, etc.  And maintainers need to understand
them..  Take a look at GNU's gitlog-to-changelog, and example of use [6]
(fwiw, none of [1,2,3] attempted to re-use that logic).

Bringing in the automation into our processes will either (a) require a
**lot more pedantic maintainers** (even though we don't want to complicate
our life) or (b) mean a decrease of quality of %changelog(s).  The (a) is
OK, as long as people opt-in.  We have to admit that there's (b).

Is it acceptable in the Fedora community to relax the rules around %changelog,
and decrease its quality (a bit, or a lot)?  Do we think that %changelog is no
more worth the all manual trouble?  If we tend to answer yes, maybe we should
rather go with something trivial as this:

  %changelog
  * This package doesn't provide changelog metadata, check it online
https://src.fedoraproject.org/rpms//commits/

Such %changelog has a very similar level of quality as all the generated
approaches, and we don't have to complicate our lives (or buildsystem).
Alternatively, we can teach build systems to upload the git-log file
somewhere, or even extremely drop the changelog entirely (and only
reference the upstream changelog in %doc payload).

Side question:  Is it really useful to put "Rebuilt for
https://fedoraproject.org/wiki/Fedora_XX_Mass_Rebuild; into changelogs?

[1] https://github.com/rpm-software-management/mock/pull/526
[2] 
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs
[3] https://docs.pagure.org/Fedora-Infra.rpmautospec/index.html
[4] 
https://lists.fedorahosted.org/archives/list/copr-de...@lists.fedorahosted.org/thread/S7EXSR4UX4KQO32PYDBNQHVPAWFFVGWK/
[5] 
https://lists.fedorahosted.org/archives/list/copr-de...@lists.fedorahosted.org/message/LJYXURA5RZFKD47LBDNEGPLTKHYJNX4R/
[6] https://git.savannah.gnu.org/cgit/libtool.git/tree/Makefile.am#n553

Ideas?

Pavel


___
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: Deprecation of Anaconda boot parameters without inst. prefix

[Fabio Valentini]

On Thu, Aug 13, 2020 at 2:16 PM  wrote:
>
> Hello everyone,
>
> Anaconda team has decided to deprecate use of Anaconda kernel boot
> parameters without 'inst.' prefix. As you may already know you can
> specify Anaconda kernel boot parameters both with and without 'inst.'
> prefix (e.g. 'inst.repo=' or 'repo='). This deprecation means that when
> you use Anaconda option without the 'inst.' prefix you will now get a
> warning. We are *not* disabling parameters without a prefix yet.
>
> The reason for this is keep running into parameter conflicts with other
> projects. As an example there is 'debug' parameter for both kernel and
> us, so when you want to enable kernel debugging in installation
> environment you will also enable Anaconda debug mode.
>
> Because of this I have created the following pull request for Anaconda:
>
> https://github.com/rhinstaller/anaconda/pull/2786
>
>
> In case you have any objections please start discussion either on the
> pull request or here.
>
>
> Best regards,
> Jirka

This may be a stupid question, but why are parameter namespaced with
"inst." and not with "anaconda."? Is this a historical artifact?
"inst" is a pretty generic term as well, and "anaconda" would
definitely not lead to parameter overloading on the kernel cmdline.

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

[Bug 1868187] perl-Devel-PPPort-3.60 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Devel-PPPort-3.60-1.fc
   ||34



--- Comment #2 from Petr Pisar  ---
A bug-fix release suitable for Fedora ≥ 33.


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

Deprecation of Anaconda boot parameters without inst. prefix

[jkonecny]

Hello everyone,

Anaconda team has decided to deprecate use of Anaconda kernel boot
parameters without 'inst.' prefix. As you may already know you can
specify Anaconda kernel boot parameters both with and without 'inst.'
prefix (e.g. 'inst.repo=' or 'repo='). This deprecation means that when
you use Anaconda option without the 'inst.' prefix you will now get a
warning. We are *not* disabling parameters without a prefix yet.

The reason for this is keep running into parameter conflicts with other
projects. As an example there is 'debug' parameter for both kernel and
us, so when you want to enable kernel debugging in installation
environment you will also enable Anaconda debug mode.

Because of this I have created the following pull request for Anaconda:

https://github.com/rhinstaller/anaconda/pull/2786


In case you have any objections please start discussion either on the
pull request or here.


Best regards,
Jirka


___
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 1867692] airscan driver crashes in mock during wsdd_cleanup()

[bugzilla]

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



--- Comment #12 from Fedora Update System  ---
FEDORA-2020-841f4ce8df has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-841f4ce8df


-- 
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 1867692] airscan driver crashes in mock during wsdd_cleanup()

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|POST|MODIFIED



--- Comment #11 from Fedora Update System  ---
FEDORA-2020-841f4ce8df has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-841f4ce8df


-- 
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: A few questions about rpmdev-bumpspec tool

[Vít Ondruch]

Dne 13. 08. 20 v 12:41 Qiyu Yan napsal(a):
> Hello all,
>
> I have some problem with rpmdev-bumpspec recently.
>
> In the latest version of rpmdevtools, rpmdev-bumpspec has changed to
> use time+date in the changelog it generates[1], while the packaging
> guidelines have not been updated accordingly[2], should the guideline
> be updated to the rpmdev-bumpspec change?


I don't like this change and asked revert:


https://pagure.io/rpmdevtools/issue/63


Vít


>
> I am packaging fcitx5 using forge macros, and upstream have never
> tagged a version, in this case, I am packaging like this [3] (The
> snapshot dates and git short commit hashesin changelog is manually
> added). With this spec file, I noticed that when I try to use
> rpmdev-bumpspec to generate a changelog, it will give things like this
> [4].
>
> You can see that, in case of using forge, rpmdev-bumpspec can't
> include either snapshot dates nor git short commit hashes, will this
> be fine (and we can ignore the warning from rpmlint when ran on the
> built packages, and start the review process) or I should always
> manually include snapshot dates and git commit hashes in the
> changelog. Or I should wait for this change [5] to be done and ignore
> all changelog things? (and submit for review then?)
>
> Thanks.
>
> [1]: https://pagure.io/rpmdevtools/c/d205ad9cfc4b7123acd573e028f8c4521ec79300
> [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs
> [3]: 
> https://github.com/karuboniru/fcitx5-fedora/blob/master/fcitx5/fcitx5.spec
> [4]: 
> https://github.com/karuboniru/fcitx5-fedora/blob/972fd2e2e84e6ca136a9c5f4f8ad20653cca3594/fcitx5/fcitx5.spec
> [5]: 
> https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs
> --
> And the snapshot dates generated on my machine and copr can be
> different, I think this is related to time zone (I am in UTC+8), I
> don't think it is a bug, but I hope this will be improved.
___
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: A few questions about rpmdev-bumpspec tool

[Fabio Valentini]

On Thu, Aug 13, 2020 at 12:42 PM Qiyu Yan  wrote:
>
> Hello all,
>
> I have some problem with rpmdev-bumpspec recently.
>
> In the latest version of rpmdevtools, rpmdev-bumpspec has changed to
> use time+date in the changelog it generates[1], while the packaging
> guidelines have not been updated accordingly[2], should the guideline
> be updated to the rpmdev-bumpspec change?
>
> I am packaging fcitx5 using forge macros, and upstream have never
> tagged a version, in this case, I am packaging like this [3] (The
> snapshot dates and git short commit hashesin changelog is manually
> added). With this spec file, I noticed that when I try to use
> rpmdev-bumpspec to generate a changelog, it will give things like this
> [4].
>
> You can see that, in case of using forge, rpmdev-bumpspec can't
> include either snapshot dates nor git short commit hashes, will this
> be fine (and we can ignore the warning from rpmlint when ran on the
> built packages, and start the review process) or I should always
> manually include snapshot dates and git commit hashes in the
> changelog. Or I should wait for this change [5] to be done and ignore
> all changelog things? (and submit for review then?)
>
> Thanks.

You're not wrong, rpmdev-bumpspec is not completely compatible with
the forge macros, especially in the snapshot packaging case (because
the forge macros mess with the value of %dist, as mentioned in the
other response).

While rpmdev-bump will produce changelog entries with "wrong" (or
incomplete) EVR information, SRPM and RPM builds will have the correct
Release set, so it's not a "big deal". For my packages that suffer
from this (e.g. some Go packages that internally use the forge
macros), I tend to manually "fix" the version-release in the changelog
entries after running rpmdev-bumpspec.

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

Re: A few questions about rpmdev-bumpspec tool

[Michael Schwendt]

On Thu, 13 Aug 2020 18:41:23 +0800, Qiyu Yan wrote:

> In the latest version of rpmdevtools, rpmdev-bumpspec has changed to
> use time+date in the changelog it generates[1], while the packaging
> guidelines have not been updated accordingly[2], should the guideline
> be updated to the rpmdev-bumpspec change?

The git commit message for that change is vague, since it only refers to
an RPM version but doesn't sum up what the goal of this change is.

> I am packaging fcitx5 using forge macros, and upstream have never
> tagged a version, in this case, I am packaging like this [3] (The
> snapshot dates and git short commit hashesin changelog is manually
> added). With this spec file, I noticed that when I try to use
> rpmdev-bumpspec to generate a changelog, it will give things like this
> [4].

The forge macros you use mess with %dist, which is highly questionable.

The rpmdev-bumpspec script itself doesn't evaluate any RPM macros. It only
recognizes a variety of version/release schemes used by Fedora.

For the %changelog comment, it relies on an "rpm" command-line call in
order to determine the full E:VR for the %changelog entry. Since %dist is
not to be included in %changelog comments, %dist gets undefined, but then
the %forge macro stuff is lost.

As a side-note: The E:V-R details right of the email address in changelog
comments are not everyone's cup of tea. They are not mission critical but
optional. If truncated, they don't break the rpmbuild. In your case, V-R
is complete and accurate. The left most-significant part of %release is
included in the V-R and is sufficient, and while the git commit hash is
missing, it is just noise in changelog comments.
___
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

A few questions about rpmdev-bumpspec tool

[Qiyu Yan]

Hello all,

I have some problem with rpmdev-bumpspec recently.

In the latest version of rpmdevtools, rpmdev-bumpspec has changed to
use time+date in the changelog it generates[1], while the packaging
guidelines have not been updated accordingly[2], should the guideline
be updated to the rpmdev-bumpspec change?

I am packaging fcitx5 using forge macros, and upstream have never
tagged a version, in this case, I am packaging like this [3] (The
snapshot dates and git short commit hashesin changelog is manually
added). With this spec file, I noticed that when I try to use
rpmdev-bumpspec to generate a changelog, it will give things like this
[4].

You can see that, in case of using forge, rpmdev-bumpspec can't
include either snapshot dates nor git short commit hashes, will this
be fine (and we can ignore the warning from rpmlint when ran on the
built packages, and start the review process) or I should always
manually include snapshot dates and git commit hashes in the
changelog. Or I should wait for this change [5] to be done and ignore
all changelog things? (and submit for review then?)

Thanks.

[1]: https://pagure.io/rpmdevtools/c/d205ad9cfc4b7123acd573e028f8c4521ec79300
[2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs
[3]: https://github.com/karuboniru/fcitx5-fedora/blob/master/fcitx5/fcitx5.spec
[4]: 
https://github.com/karuboniru/fcitx5-fedora/blob/972fd2e2e84e6ca136a9c5f4f8ad20653cca3594/fcitx5/fcitx5.spec
[5]: 
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs
--
And the snapshot dates generated on my machine and copr can be
different, I think this is related to time zone (I am in UTC+8), I
don't think it is a bug, but I hope this will be improved.
-- 
Best regards,
Qiyu Yan
___
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 1867692] airscan driver crashes in mock during wsdd_cleanup()

[bugzilla]

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

Zdenek Dohnal  changed:

   What|Removed |Added

Summary|libsane-airscan-0.99.12-1.f |airscan driver crashes in
   |c33: airscan driver crashes |mock during wsdd_cleanup()
   |in mock: file   |
   |airscan-wsdd.c: line 1696   |
   |(wsdd_cleanup): assertion   |
   |failed: |
   |(ll_empty(_finding_lis |
   |t)) |




-- 
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 1867692] airscan driver crashes in mock during wsdd_cleanup()

[bugzilla]

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

Zdenek Dohnal  changed:

   What|Removed |Added

 Attachment|0   |1
#1711079 is||
   obsolete||



--- Comment #10 from Zdenek Dohnal  ---
Created attachment 1711304
  --> https://bugzilla.redhat.com/attachment.cgi?id=1711304=edit
Upstream patch


-- 
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: Draft of New Python Packaging Guidelines - 0.2

[Petr Viktorin]

On 2020-08-12 18:19, Neal Gompa wrote:

On Wed, Aug 12, 2020 at 12:02 PM Petr Viktorin  wrote:

On 2020-08-12 17:22, Neal Gompa wrote:

On Wed, Aug 12, 2020 at 11:19 AM Petr Viktorin  wrote:

On 2020-08-12 16:53, Neal Gompa wrote:

On Wed, Aug 12, 2020 at 10:23 AM Petr Viktorin  wrote:

@Conan-Kudo:

Is there something you've done here to make the new macros unequivocally 
better? Do you have automated flavor builds, for example? Right now there is no 
effective difference.



The new macros allow other build tools than just setuptools.
They also use upstream metadata for BuildRequires & file lists.

Of course, where possible the changes were backported to the existing
macros. I don't necessarily see the macros as the main thing that
changes. But when you look at a specfile, you can usually tell what
conventions it uses by what macros you see.



Those are all nice things, for sure. I think it'd be important to
spell that out somewhere.


Do you mean providing a summary of the changes between the existing
guidelines and these?



Yes. Also indicating the *why* for pyproject stuff is useful within
the context of why the old macros are deprecated.


Is that necessary for the beta release of the packaging guidelines?
(i.e. when they would be in effect, but optional?)

You're asking for quite a lot of work around describing a document that
might still change.




I am only asking for what makes sense if the document as it stands
were to be finalized.


OK, you're right. I added a note to the checklist.


## PyPI parity

Every Python package in Fedora **SHOULD** also be available
on [the Python Package Index](https://pypi.org) (PyPI).

The command `pip install PROJECTNAME` **MUST** install the same package
(possibly in a different version),
install nothing,
or fail with a reasonable error message.

If this is not the case, the packager **MUST** contact upstream about this.
The goal is to get the project name registered or blocked on PyPI,
or to otherwise ensure the rule is followed.

To block a project name on PyPI, email
[ad...@pypi.org](mailto:ad...@pypi.org),
giving the project name and explaining the situation
(for example: the package cannot currently be installed via `pip`).
You can ask questions and discuss the process at the [Python
Discourse](https://discuss.python.org/t/block-names/4045).

> NOTE: Project names that were in Fedora but not on PyPI
> when these guidelines were proposed
> are *blocked* from being uploaded to PyPI.
> This prevents potential trolls from taking them,
> but it also blocks legitimate owners.
> If your package is affected, contact the Python SIG
> or [file a PyPA
issue](https://github.com/pypa/pypi-support/issues/new?labels=PEP+541=pep541-request.md=PEP+541+Request%3A+PROJECT_NAME)

> and mention `@encukou`.

This is necessary to protect users,
avoid confusion,
and enable automation as Fedora and upstream ecosystems grow more
integrated.

As always, [specific exceptions can be granted by the Packaging
Committee](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_general_exception_policy).



@Conan-Kudo:

This is not reasonable to ask of packagers to do. Such a check is difficult to 
do, and there is no particularly compelling reason for making everything 
written in Python using Python build system available in PyPI. Unless you plan 
to provide an automated system to inform PyPI of these things, this is not only 
unreasonable, it is unenforceable.


A lot of stuff in the guidelines is unenforceable, so let's focus on the
"unreasonable" part.

There is no reason to have everything available on PyPI, but I do
believe it's reasonable to *reserve the name* in such cases.

Here's a reason why I want this:

The issue here is that Python tools have access to project names. For
example, I can get the version of Requests using:

>>> from importlib.metadata import version
>>> version('requests')
'2.22.0'

Things like this are only useful if we use a common namespace. Upstream,
that namespace *is* PyPI; there's little we can do about that.
If project names mean something else in Fedora than in the wider
ecosystem, we'll get user confusion at best.

(If you use a private package index, like they do at CERN or some
closed-source shops, there can be some collisions -- but in that case
there's a limited number of software authors and users, and a lot more
control over the package set. Conflicts in global repositories of
free/open-source software are much harder to manage.)



Lately, I think about another way to handle this: packages that aren't
on PyPI could not ship the .dist-info at all, and so, they would not
have things like `python3dist(...)` provides. They'd only be usable with
Fedora tooling, not in the wider Python ecosystem.
It's a major case to think out and test, but maybe it would be worth it?



I think omitting the Provides is unfair.


Why?
In my view, `python3dist(...)` is using the namespace of the wider
Python 

Re: BleachBit is available in the repos, but does not appear when searching in GNOME Software

[Richard Hughes]

On Thu, 13 Aug 2020 at 08:29, Artur Iwicki  wrote:
> We also have an icon size requirement.

Do you have the latest appstream-data installed? I believe it went to
stable a few days ago.

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

Non-responsive maintainer check: fnasser

[Fabio Valentini]

Hi everybody,

Still working through Java package update backlog, it looks like
Fernando Nasser / fnasser is no longer contributing to fedora. I have
opened this non-responsive maintainer check bug:

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

Looking at dist-git and koji, fnasser has not done any packaging work
for fedora since 2010:
https://koji.fedoraproject.org/koji/userinfo?userID=5

(koji userID 5. wow)

Does anybody know if Fernando still wants to maintain his packages, or
how to contact him?

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

Non-responsive maintainer check: davidx

[Fabio Valentini]

Hi everybody,

Working through the Java packages that are in need of attention, I
came across glassfish-el and glassfish-servlet-api, which have
essentially been abandoned (in the latter case, the two co-maintainers
of the package were in fact already declared non-responsive last
year).

I filed this non-responsive maintainer check bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1868592

Does anybody know if David Xie / davidx still wants to maintain his
two packages, or how to contact him? Looking at koji, he has stopped
contributing in 2013, so I'm not hopeful :(
https://koji.fedoraproject.org/koji/userinfo?userID=2362

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

Re: BleachBit is available in the repos, but does not appear when searching in GNOME Software

[Artur Iwicki]

We also have an icon size requirement. The app needs to provide an icon that's 
at least 64x64 (or maybe even 128x128?). I vaguely remember there being a 
discussion here on devel when the requirement was introduced.

I tried searching the wiki and the Packaging Guidelines and this is the only 
place I've found that mentions this requirement:
https://fedoraproject.org/wiki/Workstation/Guidelines/Applications_and_Launchers#For_launchers:
___
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