Re: Strange build failures in rawhide buildroot (cont'd) - glibc 2.33 dev snapshot?

[Kevin Fenzi]

On Fri, Aug 14, 2020 at 09:14:46PM +0200, Fabio Valentini wrote:
> 
> Sérgio, I have no idea what you're talking about here. Do you mean the
> new policy to wait with a rawhide compose until the first "branched"
> compose is successful and synced out? If I understand correctly, that
> "policy" is enforced by bodhi not allowing any builds into "branched"
> by default, and releng not launching any rawhide composes until a
> "branched" compose finishes.

Yep. 

So, we have both branched and rawhide composes now so they will be back
to normal again. 

The f33 branched composes (there have been two successfull so far), had
a issue with permissions and didn't sync out right. I manually synced
much of it and the rest should sync on the next compose tonight. 

So now until 2020-08-25 both rawhide (f34) and branched (f33) use the
normal rawhide gating setup. On the 25th, branched changes to enable
updates-testing and we go into freeze, meaning only approved blockers or
freeze exceptions go into 'stable' for f33 until beta is approved. 

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

[389-devel] 389 DS nightly 2020-08-15 - 94% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/08/15/report-389-ds-base-1.4.4.4-20200814git5afcbb0.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 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-87ccee83b4   
hylafax+-7.0.3-1.el6


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

postgresqltuner-1.0.1-4.el6

Details about builds:



 postgresqltuner-1.0.1-4.el6 (FEDORA-EPEL-2020-d884e10277)
 Simple script to analyze PostgreSQL database configuration and tuning

Update Information:

New package

ChangeLog:


References:

  [ 1 ] Bug #1692560 - Review Request: postgresqltuner - Script to analyze 
PostgreSQL database configuration and tuning
https://bugzilla.redhat.com/show_bug.cgi?id=1692560


___
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
 731  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
 470  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b   
bubblewrap-0.3.3-2.el7
 180  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6   
python-waitress-1.4.3-1.el7
  10  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

gle-4.2.4c-13.el7
libmediainfo-20.08-1.el7
mediainfo-20.08-1.el7
postgresqltuner-1.0.1-4.el7

Details about builds:



 gle-4.2.4c-13.el7 (FEDORA-EPEL-2020-74a6a41f6a)
 Graphics Layout Engine

Update Information:

First release in EPEL7.

ChangeLog:





 libmediainfo-20.08-1.el7 (FEDORA-EPEL-2020-5201b6d7a7)
 Library for supplies technical and tag information about a video or audio file

Update Information:

Update to 20.08.

ChangeLog:

* Thu Aug 13 2020 Vasiliy N. Glazov  - 20.08-1
- Update to 20.08
* Sat Aug  1 2020 Fedora Release Engineering  - 
20.03-3
- Second attempt - Rebuilt for
  https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Tue Jul 28 2020 Fedora Release Engineering  - 
20.03-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild




 mediainfo-20.08-1.el7 (FEDORA-EPEL-2020-5201b6d7a7)
 Supplies technical and tag information about a video or audio file (CLI)

Update Information:

Update to 20.08.

ChangeLog:

* Thu Aug 13 2020 Vasiliy N. Glazov  - 20.08-1
- Update to 20.08
* Sat Aug  1 2020 Fedora Release Engineering  - 
20.03-3
- Second attempt - Rebuilt for
  https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Tue Jul 28 2020 Fedora Release Engineering  - 
20.03-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild




 postgresqltuner-1.0.1-4.el7 (FEDORA-EPEL-2020-c998efb60b)
 Simple script to analyze PostgreSQL database configuration and tuning

Update Information:

New package

ChangeLog:


References:

  [ 1 ] Bug #1692560 - Review Request: postgresqltuner - Script to analyze 
PostgreSQL database configuration and tuning
https://bugzilla.redhat.com/show_bug.cgi?id=1692560


___
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 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  14  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

castxml-0.3.4-3.el8
libcloudproviders-0.3.1-1.el8
libmediainfo-20.08-1.el8
mediainfo-20.08-1.el8
pgbouncer-1.14.0-2.el8
postgresqltuner-1.0.1-4.el8
wide-dhcpv6-20080615-13.2.el8

Details about builds:



 castxml-0.3.4-3.el8 (FEDORA-EPEL-2020-e3bdf80f8b)
 C-family abstract syntax tree XML output tool

Update Information:

Rebuild using new cmake RPM macros.

ChangeLog:

* Fri Aug 14 2020 Mattias Ellert  - 0.3.4-3
- Use backported new cmake macros
* Mon Jul 27 2020 Fedora Release Engineering  - 
0.3.4-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild




 libcloudproviders-0.3.1-1.el8 (FEDORA-EPEL-2020-0b99aec329)
 Library for integration of cloud storage providers

Update Information:

Initial import into EPEL 8 (#1862395).

ChangeLog:





 libmediainfo-20.08-1.el8 (FEDORA-EPEL-2020-0152461a0e)
 Library for supplies technical and tag information about a video or audio file

Update Information:

Update to 20.08.

ChangeLog:

* Thu Aug 13 2020 Vasiliy N. Glazov  - 20.08-1
- Update to 20.08
* Sat Aug  1 2020 Fedora Release Engineering  - 
20.03-3
- Second attempt - Rebuilt for
  https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Tue Jul 28 2020 Fedora Release Engineering  - 
20.03-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild




 mediainfo-20.08-1.el8 (FEDORA-EPEL-2020-0152461a0e)
 Supplies technical and tag information about a video or audio file (CLI)

Update Information:

Update to 20.08.

ChangeLog:

* Thu Aug 13 2020 Vasiliy N. Glazov  - 20.08-1
- Update to 20.08
* Sat Aug  1 2020 Fedora Release Engineering  - 
20.03-3
- Second attempt - Rebuilt for
  https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Tue Jul 28 2020 Fedora Release Engineering  - 
20.03-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild




 pgbouncer-1.14.0-2.el8 (FEDORA-EPEL-2020-9481e7176f)
 Lightweight connection pooler for PostgreSQL

Update Information:

Update to 1.14, improve systemd support:  - No notify on EPEL 7. - Notify and
socket support in EPEL 8+ and Fedora.

ChangeLog:

* Wed Jul 22 2020 Simone Caronni  - 1.14.0-2
- Do not enable notify support on RHEL/CentOS 7.
* Wed Jul 22 2020 Simone Caronni  - 1.14.0-1
- Update to 1.14.0.
- Update URL.
- Enable systemd support at compile time so notify/socket support is built in.

References:

  [ 1 ] Bug #1868654 - systemctl start pgbouncer times out
https://bugzilla.redhat.com/show_bug.cgi?id=1868654




 postgresqltuner-1.0.1-4.el8 (FEDORA-EPEL-2020-2f9876b6cf)
 Simple script to analyze PostgreSQL database configuration and tuning

Update Information:

New package

ChangeLog:

Re: Strange build failures in rawhide buildroot (cont'd) - glibc 2.33 dev snapshot?

[Sérgio Basto]

On Sat, 2020-08-15 at 00:46 +0200, Fabio Valentini wrote:
> There's a difference between bodhi pushing a rawhide update to
> "stable" and it being included in "rawhide" repositories.
> Because bodhi does not compose rawhide. 

OK, didn't know that. thanks for the update


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

Re: calculating process memory usage

[Samuel Sieb]

On 8/14/20 4:34 PM, Samuel Sieb wrote:

On 8/14/20 1:52 PM, Chris Murphy wrote:

/proc/pid/status

VmHWM or  VmRSS + VmSwap


Yes, thank you!
VmHWM is not so useful for this case, but certainly for others.
Comparing with the "top" numbers, the VmRSS total looks slightly high, 
depending on how zswap factors in to the numbers.

The VmSwap total is short by about 2GB (out of 12GB).
But that's the information I was looking for.  Now I can do some 
analysis to figure out what's hogging my (virtual) memory.


And it gave a very unexpected result.  The top two offenders are:
/usr/libexec/gnome-shell-calendar-server 3167256  (3GB)
/usr/libexec/evolution-calendar-factory 2006908   (2GB)

They have almost no RSS.

For anyone curious, this is how I did it:
grep VmSwap /proc/*/status | sort -r -n -k 2 | while read name size kb; 
do echo "$(readlink /proc/$(echo ${name} | cut -d/ -f 3)/exe) $size"; 
done | less


That's all one line.
___
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: calculating process memory usage

[Samuel Sieb]

On 8/14/20 1:52 PM, Chris Murphy wrote:

/proc/pid/status

VmHWM or  VmRSS + VmSwap


Yes, thank you!
VmHWM is not so useful for this case, but certainly for others.
Comparing with the "top" numbers, the VmRSS total looks slightly high, 
depending on how zswap factors in to the numbers.

The VmSwap total is short by about 2GB (out of 12GB).
But that's the information I was looking for.  Now I can do some 
analysis to figure out what's hogging my (virtual) memory.

___
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] 2020-08-17 @ 16:00 UTC - Fedora 33 Blocker Review Meeting

[Adam Williamson]

# F33 Blocker Review meeting
# Date: 2020-08-17
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net

Hi folks! We have 3 proposed Beta blockers and 2 proposed Beta freeze
exceptions to review, so let's have a Fedora 33 blocker review meeting
on Monday!

If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F33 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP adamw AT happyassassin . net
http://www.happyassassin.net
___
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

[Test-Announce] Proposal to CANCEL: 2020-08-17 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting for Monday. I don't
have anything urgent this week.

If you're aware of anything important we have to discuss this week,
please do reply to this mail and we can go ahead and run the meeting.

Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP adamw AT happyassassin . net
http://www.happyassassin.net
___
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

[Bug 1858788] ddclient dependency missing

[bugzilla]

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

Scott Talbert  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |CURRENTRELEASE
Last Closed|2020-07-20 12:57:39 |2020-08-14 23:11:52




-- 
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: Debug doxygen generated files with different names in noarch package

[Rich Mattes]

On 8/14/20 1:37 PM, Richard Shaw wrote:
On Fri, Aug 14, 2020 at 7:12 AM Rich Mattes > wrote:



On Fri, Aug 14, 2020, 7:37 AM Richard Shaw mailto:hobbes1...@gmail.com>> wrote:


I'm getting consistent differences across at least two versions
of zipios and the offending arches seem to always be s390x and
ppc64le.

BuildError: The following noarch package built differently on
different architectures: zipios-doc-2.2.1.0-5.fc33.noarch.rpm
rpmdiff output was:
removed
/usr/share/doc/zipios/html/dir_0f7abfb91da657dcb27dff31b827312f.html
removed
/usr/share/doc/zipios/html/dir_32504400af4b8c553a85c61a7ef01dea.html
added  
/usr/share/doc/zipios/html/dir_8f6b9ad7431774f92e3ec3efe35ac7da.html
added  
/usr/share/doc/zipios/html/dir_dd208edd458824e9eaf902c6da16200d.html


zipios 2.2.5.0
https://koji.fedoraproject.org/koji/taskinfo?taskID=49057750

zipios 2.2.1.0
https://koji.fedoraproject.org/koji/taskinfo?taskID=48597282

Is this likely a big vs little endian thing?

Is it a CMake package? The vpath_builddir that is now used for out
of source builds is different for each architecture. If that
directory is included in the doxygen processing paths you'll get
this error.


Yes, but why is doxygen using that to generate a directory name? Bah...

I worked around this in a few of my packages by adding the cmake
build directory to the EXCLUDE list in the doxyfile.


I added a patch to the doxy.in  file and it seemed to 
get rid of one of the directory problems, but not both...


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

Patch:
$ cat zipios-doxygen.patch
Index: doc/zipios.doxy.in 
===
--- Zipios/doc.orig/zipios.doxy.in 
+++ Zipios/doc/zipios.doxy.in 
@@ -152,7 +152,7 @@ FULL_PATH_NAMES        = YES
  # will be relative from the directory where doxygen is started.
  # This tag requires that the tag FULL_PATH_NAMES is set to YES.

-STRIP_FROM_PATH        = @CMAKE_CURRENT_SOURCE_DIR@
+STRIP_FROM_PATH        = @CMAKE_CURRENT_BINARY_DIR@

  # The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part 
of the
  # path mentioned in the documentation of a class, which tells the 
reader which




I downloaded the i686-generated doc package, 
dir_dd208edd458824e9eaf902c6da16200d.html is the directory that contains 
zipios-config.h.  That file is generated from a template by CMake, and 
is located in the root of the build folder (which is now 
%{_vpath_builddir}.  So it's going to be different on every arch.  I'm 
also seeing the file path to zipios-config.h that includes the 
%{_vpath_builddir} folder in the some of the images generated for the 
dependency graphs.


Your above patch is filtering out CMAKE_CURRENT_BINARY_DIR, which I 
think points the doc/ subdirectory of the build tree, since the doxyfile 
is configured in the doc/CMakeLists.txt, not the root CMakeLists.txt. 
Perhaps try using @PROJECT_BINARY_DIR@ instead.


Is it possible to override %{_vpath_builddir} to just be "build" on all 
architectures (e.g. "%global _vpath_builddir build" at the top of a spec?)


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

Re: Strange build failures in rawhide buildroot (cont'd) - glibc 2.33 dev snapshot?

[Fabio Valentini]

On Sat, Aug 15, 2020 at 12:37 AM Sérgio Basto  wrote:
>
> On Fri, 2020-08-14 at 21:14 +0200, Fabio Valentini wrote:
> > On Fri, Aug 14, 2020 at 8:48 PM Sérgio Basto 
> > wrote:
> > > On Fri, 2020-08-14 at 20:30 +0200, Fabio Valentini wrote:
> > > > So, I've been trying to figure out strange build failures in my
> > > > Java
> > > > packages when running mock with `--enablerepo local`.
> > > >
> > > > First I thought java-11-openjdk update might be to blame, but now
> > > > I
> > > > found another "unrelated" issue:
> > > >
> > > > OCaml packages built with dune and `--enablerepo local` right now
> > > > produce packages where binaries get permissions `555` set instead
> > > > of
> > > > `755` despite dune explicitly setting 755.
> > > >
> > > > So ... Huh?
> > > >
> > > > The only package update other than python 3.9 beta 5 → python 3.9
> > > > rc
> > > > 1
> > > > and a Java update that happened in this time frame - which might
> > > > affect *both* Java *and* OCaml builds in weird ways - would be
> > > > ...
> > > > the
> > > > first glibc 2.33 development snapshot.
> > >
> > > It is against the new policy rules, please only update rawhide
> > > after
> > > completing the first branched compose and his mirror
> > > synchronization. i.e when we have a new buildroot .
> > >
> > > While the compose today seems successful is not yet published
> >
> > Sérgio, I have no idea what you're talking about here. Do you mean
> > the
> > new policy to wait with a rawhide compose until the first "branched"
> > compose is successful and synced out?
>
> yes
>
> > If I understand correctly, that
> > "policy" is enforced by bodhi not allowing any builds into "branched"
> > by default, and releng not launching any rawhide composes until a
> > "branched" compose finishes.
>
>
> > I have no superpowers that allow me to circumvent those restrictions
> > :)
> > If I had, I would untag glibc 2.22.9000 to check if it is indeed
> > broken, or if my development PC is haunted instead.

(snip)

> https://bodhi.fedoraproject.org/updates/?packages=glibc
>
> glibc-2.32.9000-1.fc34 has been submitted for stable by bodhi
> a day ago ...

There's a difference between bodhi pushing a rawhide update to
"stable" and it being included in "rawhide" repositories.
Because bodhi does not compose rawhide. It just marks packages as "to
be included in the next compose".

> In my view, if f33 has not yet been composed and published, all
> packages that are in rawhide shouldn't have changes to what will be
> f33, to allow for a smooth transaction and not make things more hard
> that it is .

This is exactly what's already happening.

I think you're missing the "compose" step that's happening between
things getting built and them actually getting included in "public"
repositories.
Because that step has not happened for a few days, "to allow for a
smooth transaction", as you put it.

> And I don't understand what is the rush of update things in rawhide ,
> why people can't wait one week until things calm down , is just an
> exercise of coordination. And BTW, the opposite, we also should avoid
> last minute changes, before mass-rebuild :)

I am in no rush, but I also don't want to wait for a week twiddling my
thumbs for no good reason.

PS: I agree, rushing changes into rawhide before the mass rebuild is a
bad idea, but that's a different problem ...

> Hopefully f33 is almost published .

F33 won't be "published" for another two months :)
But if you're talking about a successful f33 compose, it already
happened half a day ago, and the repos and mirrors should get updated
soon ...
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WATCKLQ7S3B77CT4UGBPUPN3NJQGIJWU/

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: Non-responsive maintainer check for bochecha

[Artem Tim]

Ah, it all makes sense now.. Mail chatting lagging a little bit, so my previous 
questions not actual anymore then. :) Thanks for clearing that up.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Non-responsive maintainer check for bochecha

[Artem Tim]

Also, if upstream against about packaging, why they added packaging status 
badge then on their project page?

Availability in distros:
https://gitlab.com/BuildStream/buildstream

They against only Fedora? I don't understand at all then.
___
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: Strange build failures in rawhide buildroot (cont'd) - glibc 2.33 dev snapshot?

[Sérgio Basto]

On Fri, 2020-08-14 at 21:14 +0200, Fabio Valentini wrote:
> On Fri, Aug 14, 2020 at 8:48 PM Sérgio Basto 
> wrote:
> > On Fri, 2020-08-14 at 20:30 +0200, Fabio Valentini wrote:
> > > So, I've been trying to figure out strange build failures in my
> > > Java
> > > packages when running mock with `--enablerepo local`.
> > > 
> > > First I thought java-11-openjdk update might be to blame, but now
> > > I
> > > found another "unrelated" issue:
> > > 
> > > OCaml packages built with dune and `--enablerepo local` right now
> > > produce packages where binaries get permissions `555` set instead
> > > of
> > > `755` despite dune explicitly setting 755.
> > > 
> > > So ... Huh?
> > > 
> > > The only package update other than python 3.9 beta 5 → python 3.9
> > > rc
> > > 1
> > > and a Java update that happened in this time frame - which might
> > > affect *both* Java *and* OCaml builds in weird ways - would be
> > > ...
> > > the
> > > first glibc 2.33 development snapshot.
> > 
> > It is against the new policy rules, please only update rawhide
> > after
> > completing the first branched compose and his mirror
> > synchronization. i.e when we have a new buildroot .
> > 
> > While the compose today seems successful is not yet published
> 
> Sérgio, I have no idea what you're talking about here. Do you mean
> the
> new policy to wait with a rawhide compose until the first "branched"
> compose is successful and synced out? 

yes

> If I understand correctly, that
> "policy" is enforced by bodhi not allowing any builds into "branched"
> by default, and releng not launching any rawhide composes until a
> "branched" compose finishes.


> I have no superpowers that allow me to circumvent those restrictions
> :)
> If I had, I would untag glibc 2.22.9000 to check if it is indeed
> broken, or if my development PC is haunted instead.

https://bodhi.fedoraproject.org/updates/?packages=glibc

glibc-2.32.9000-1.fc34 has been submitted for stable by bodhi
a day ago ... 

In my view, if f33 has not yet been composed and published, all
packages that are in rawhide shouldn't have changes to what will be
f33, to allow for a smooth transaction and not make things more hard
that it is .

And I don't understand what is the rush of update things in rawhide ,
why people can't wait one week until things calm down , is just an
exercise of coordination. And BTW, the opposite, we also should avoid
last minute changes, before mass-rebuild :) 

Hopefully f33 is almost published .

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

Re: Non-responsive maintainer check for bochecha

[Michael Catanzaro]

On Fri, Aug 14, 2020 at 10:34 pm, Artem Tim  
wrote:

Michael, this is super weird. I pushed to repos bst-external already.


I see it's two months old. Thanks for creating it. :)

Upstream had asked bochecha not to package bst-external because it's 
not stable. But since every project that uses buildstream depends on 
bst-external, that was a bad idea


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

Re: Non-responsive maintainer check for bochecha

[Artem Tim]

> Also note the buildstream package is mostly useless without bst-external, 
> which is unfortunately not packaged in Fedora because upstream requested it 
> not be packaged

Michael, this is super weird. I pushed to repos bst-external already. And i 
never seen before that upstream against it. Quite the opposite, upstream 
emailed me about this issue and buildstream update in Fedora. The original bug 
report itself is reported by Javier btw 
https://bugzilla.redhat.com/show_bug.cgi?id=1821245
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Non-responsive maintainer check for bochecha

[Fabio Valentini]

On Sat, Aug 15, 2020 at 12:20 AM Neal Gompa  wrote:
>
> On Fri, Aug 14, 2020 at 6:03 PM Michael Catanzaro  
> wrote:
> >
> >
> > Hi,
> >
> > I believe Mathieu is temporarily unavailable. If you don't hear back
> > soon, it makes sense to proceed with nonresponsive maintainer procedure
> > if you want to take over the buildstream package, or ask a
> > provenpackager to help.
> >
> > (Also note the buildstream package is mostly useless without
> > bst-external, which is unfortunately not packaged in Fedora because
> > upstream requested it not be packaged)
> >
>
> Wait, what?! Why would we respect such a request and package something
> that's "mostly useless" then?

Curiously, this actually exists: https://src.fedoraproject.org/rpms/bst-external
___
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 Fri, Aug 14, 2020 at 3:04 PM Sergio Belkin  wrote:
>
> Good question this the output of he last lines of smem -c "name swap" -s swap 
> -k -t
>
> kaccess  4.1M
> kded54.5M
> cadmus   5.0M
> konsole  5.4M
> xdg-desktop-por 10.6M
> mount.ntfs  26.1M
> Xorg30.0M
> mysqld  36.6M
> plasmashell 36.9M
> packagekitd239.6M
> --
>547.3M

That's ~1/8th the size of the 100% full swap device though. Not enough
is accounted for. Are there a ton of small processes created by
something? Like many dozens of firefox tabs? Or?


> systemctl status packagekit
> ● packagekit.service - PackageKit Daemon
>  Loaded: loaded (/usr/lib/systemd/system/packagekit.service; static; 
> vendor preset: disabled)
>  Active: active (running) since Thu 2020-07-30 15:40:51 -03; 2 weeks 1 
> days ago
>Main PID: 5393 (packagekitd)
>   Tasks: 12 (limit: 19015)
>  Memory: 903.2M


> Now I've restarted packagekit and it outputs:
>
> ● packagekit.service - PackageKit Daemon
>  Loaded: loaded (/usr/lib/systemd/system/packagekit.service; static; 
> vendor preset: disabled)
>  Active: active (running) since Fri 2020-08-14 17:58:31 -03; 44s ago
>Main PID: 2073306 (packagekitd)
>   Tasks: 3 (limit: 19015)
>  Memory: 11.2M



> However swap usage is still high :
> free -m
>   totalusedfree  shared  buff/cache   
> available
> Mem:  158878577118745876123
> 2382
> Swap:  40953854 241
>
> It's weird, isn't it?

It's consistent. Only ~240 MB of 900M for PK had been evicted to swap.
When restarting PK, it dropped those 240MB in swap. Free memory also
went up no doubt. I don't know why it's using so much memory, what all
these anonymous pages are. If you catch it going above 500M, check
/proc/pid/status and let's see what the breakdown is of memory usage.

I want to see if we can stop these SIGTERMs from happening. I suggest
bumping your zram size cap to 8G. Create this file

/etc/systemd/zram-generator.conf

Containing just two lines:

[zram0]
max-zram-size = 8192

Either reboot, or maybe logout or quit a bunch of things first because
otherwise with a full swap, this command is risky:

systemctl restart swap-create@zram0

For that to work, it must swapoff which means all anonymous pages
still in swap must be restored to memory first, before the new sized
zram swap device is created and started.

This doesn't solve the problem of whatever is creating so many
anonymous pages. But I wonder if it levels off at something like 6G or
if it just keep spirally out of control, and what's doing it.


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

Re: Non-responsive maintainer check for bochecha

[Neal Gompa]

On Fri, Aug 14, 2020 at 6:03 PM Michael Catanzaro  wrote:
>
>
> Hi,
>
> I believe Mathieu is temporarily unavailable. If you don't hear back
> soon, it makes sense to proceed with nonresponsive maintainer procedure
> if you want to take over the buildstream package, or ask a
> provenpackager to help.
>
> (Also note the buildstream package is mostly useless without
> bst-external, which is unfortunately not packaged in Fedora because
> upstream requested it not be packaged)
>

Wait, what?! Why would we respect such a request and package something
that's "mostly useless" then?


-- 
真実はいつも一つ！/ 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: Non-responsive maintainer check for bochecha

[Michael Catanzaro]

Hi,

I believe Mathieu is temporarily unavailable. If you don't hear back 
soon, it makes sense to proceed with nonresponsive maintainer procedure 
if you want to take over the buildstream package, or ask a 
provenpackager to help.


(Also note the buildstream package is mostly useless without 
bst-external, which is unfortunately not packaged in Fedora because 
upstream requested it not be packaged)


Michael

___
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

CPE WEekly: 2020-08-14

[Aoife Moloney]

---
title: CPE Weekly status email
tags: CPE Weekly, email
---

# CPE Weekly: 2020-08-14
Background:
The Community Platform Engineering group, or CPE for short, is the Red
Hat team combining IT and release engineering from Fedora and CentOS.
Our goal is to keep core servers and services running and maintained,
build releases, and other strategic tasks that need more dedicated
time than volunteers can give.


See our wiki page here for more
information:https://docs.fedoraproject.org/en-US/cpe/


## General Project Updates

The CPE team are working on the following projects for Quarter 3,
which is the months of July, August & September:
* Data Centre Move - Final Works
* CentOS Stream Phase 3
* Noggin Phase 3
* Packager Workflow Healthcare
* Fedora Messaging Schemas

Details of the above projects, and of projects currently in progress,
done and what projects are in our backlog, can be found on our taiga
board per project card:
https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null

We also have an updated initiative timetable for briefing in new
projects to our team & key dates
here:https://docs.fedoraproject.org/en-US/cpe/time_tables/
*Note: Initiatives are large pieces of work that require a team of
people and weeks/months to complete. Please continue to open tickets
in the normal way for bugs, issues, etc.





### CPE Product Owner Office Hours
 #fedora-meeting-1
* Weekly on Thursdays @ 1300 UTC on #fedora-meeting-1
* Next Meeting: 2020-08-20
 #centos-meeting
* Every second Tuesday @ 1500 UTC on #centos-meeting
* Next Meeting: 2020-08-18

### Misc

 Nest With Fedora Note
Thank you to everyone who attended Nest With Fedora over the weekend
and engaged with us during our talks and social sessions. It was a
fantastic event, very well put together and run by the Fedora team and
it was both my pleasure and honour to have been a part of what was a
fantastic schedule! I cant wait to catch up on talks I missed when
they are uploaded, and the CPE team, with thanks to Michal Konecny who
put the structure of our piece together, will be submitting a
collaborative blog post to the Community blog space in the coming
weeks, recapping our experience at Nest this year. Well done Marie
Nordin, Matthew Miller and the wider team, and our very own Vipul
Siddarth, on what was a very successful and enjoyable event!


 Engagement Email Feedback
At the beginning of July I sent an email to devel-announce requesting
feedback from the community on changes I and the wider CPE team have
made when scheduling projects to work on, in an effort to find the
balance between work and life. We are still searching :)
However, I got some very good tips that I will definitely be
incorporating which I shared at Nest during the CPE AMA Session and in
reply to the original mail.
The link to the mails are here for full reading
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/UNWTLOI2U4VKAU4IKJZGZLZ2DTMPEFBW/
But the suggestions and actions are here for quicker reference:
Continue to communicate regularly on projects & updates
- Will do, weekly emails have been a bit more sporadic lately as I have had
some time off

Less acronyms & abbreviations in comms :)
- Sure, that's an easy fix on my end and makes sense

Publish team members timezone on docs.fpo/cpe to help define our ‘working
hours’
- Will do, I hope to get to this by end of August and they will be
reflected on docs.fpo/cpe

Publish the workflow diagram to docs.fpo/cpe and add filtered versions that
are user specific
- Same as above, publishing it on docs.fpo/cpe-initiatives

Office Hours on IRC are a useful way to contact team Product Owner
- Great to hear, please feel free to stop by when you can/want to. They are
on Thursdays @ 1300 UTC on #fedora-meeting-1 and every second Tuesday @
1500 UTC on #centos-meeting

Public tracker for bugs
- Our team meets twice a day, every day on IRC to review tickets and issues
to work on. They meet @ 0830 UTC on #centos-meeting and again @ 1800 UTC on
#fedora-admin. These are public meetings so please feel free to attend.

If you would like to offer any further suggestions or feedback on the
Community Platform Engineering team, please feel free to complete our
survey which is open until August 30th
https://fedoraproject.limequery.com/696793?lang=en


## Fedora Updates

### Data Centre Move
* Nearly done!!
* Firewalls for staging are going up this week
* Last of the hardware has been set up for networking changes
* The bringup of Communishift is being made into a dedicated project
for work as soon as the team have capacity to do so - this may be in
late September as the members of the colo team will (hopefully) take
some very well deserved time off work before tackling this one :)



### AAA Replacement
* Some of the Noggin team have been enjoying some very well deserved
time off work over the last week or two so work has, naturally slowed.
* The code is currently 

Re: EarlyOOM +ZRAM Only

[Sergio Belkin]

El vie., 14 ago. 2020 a las 16:32, Chris Murphy ()
escribió:

> On Fri, Aug 14, 2020 at 12:42 PM Sergio Belkin  wrote:
> >
> > 2 comments:
> > - I don't use disk-based swap, only zram.
> > - It happened again, and in this case there is no Virtual Machine nor
> Zoom app running:
> > ago 14 15:08:37 dublin.ireland.home earlyoom[888]: sending SIGTERM to
> process 2052260 uid 1000 "Web Content": badness 322, VmRSS 447 MiB
> > ago 14 15:08:40 dublin.ireland.home earlyoom[888]: process exited after
> 2.7 seconds
> > ago 14 15:12:15 dublin.ireland.home earlyoom[888]: mem avail:   395 of
> 15887 MiB ( 2.49%), swap free:0 of 4095 MiB ( 0.00%)
> > ago 14 15:12:15 dublin.ireland.home earlyoom[888]: low memory! at or
> below SIGTERM limits: mem  2.52%, swap 10.00%
> > ago 14 15:12:15 dublin.ireland.home earlyoom[888]: sending SIGTERM to
> process 2055755 uid 1000 "Web Content": badness 319, VmRSS 392 MiB
> > ago 14 15:12:17 dublin.ireland.home earlyoom[888]: process exited after
> 2.8 seconds
> > ago 14 15:28:35 dublin.ireland.home earlyoom[888]: mem avail:   371 of
> 15887 MiB ( 2.34%), swap free:0 of 4095 MiB ( 0.00%)
> > ago 14 15:28:35 dublin.ireland.home earlyoom[888]: low memory! at or
> below SIGTERM limits: mem  2.52%, swap 10.00%
> > ago 14 15:28:35 dublin.ireland.home earlyoom[888]: sending SIGTERM to
> process 2062157 uid 1000 "Web Content": badness 327, VmRSS 553 MiB
> > ago 14 15:28:37 dublin.ireland.home earlyoom[888]: process exited after
> 2.3 seconds
>
>
> What's the workload? What  is filling up 4G of swap with inactive
> pages such that none of them are being freed? The usual case is
> available memory is well below the watermark before swap has filled.
> But in this case, it's the opposite.
>


Good question this the output of he last lines of smem -c "name swap" -s
swap -k -t

kaccess  4.1M
kded54.5M
cadmus   5.0M
konsole  5.4M
xdg-desktop-por 10.6M
mount.ntfs  26.1M
Xorg30.0M
mysqld  36.6M
plasmashell 36.9M
packagekitd239.6M
--
   547.3M


>
> As sigterm is happening, memory available is still dropping. Some
> process is still taking up more memory, but has low enough badness
> that its not being terminated. It could be one of the exempt
> processes.
>
> >
> > Perhaps this ps_mem snippet is useful:
> >  > Private  +   Shared  =  RAM used   Program
> > 
> > 
> > 
> > 294.8 MiB +   4.7 MiB = 299.4 MiB   telegram-desktop.bin
> > 290.3 MiB +  22.1 MiB = 312.4 MiB   rocketchat-desktop (5)
> > 323.8 MiB +   9.5 MiB = 333.2 MiB   kwin_x11 (9)
> > 344.5 MiB +   1.4 MiB = 345.8 MiB   nextcloud
> > 373.2 MiB +  21.2 MiB = 394.4 MiB   spotify (5)
> > 416.6 MiB +   1.3 MiB = 417.9 MiB   plasma-discover
> > 448.5 MiB +  16.6 MiB = 465.2 MiB   MainThread
> > 892.8 MiB + 444.5 KiB = 893.2 MiB   packagekitd
> >   1.0 GiB +   8.6 MiB =   1.0 GiB   plasmashell
> >   1.9 GiB +  81.0 MiB =   1.9 GiB   Web Content (9)
>
> 892M for packagekit? Seems excessive. I wonder what's up with that. It
> is an exempt process. On my current system it's 1/2 that amount, which
> is in turn twice that of GNOME shell. Hmm.
>


systemctl status packagekit
● packagekit.service - PackageKit Daemon
 Loaded: loaded (/usr/lib/systemd/system/packagekit.service; static;
vendor preset: disabled)
 Active: active (running) since Thu 2020-07-30 15:40:51 -03; 2 weeks 1
days ago
   Main PID: 5393 (packagekitd)
  Tasks: 12 (limit: 19015)
 Memory: 903.2M
CPU: 9min 6.976s
 CGroup: /system.slice/packagekit.service
 ├─   5393 /usr/libexec/packagekitd
 ├─2019772 gpg-agent --homedir
/var/cache/PackageKit/32/metadata/fedora-modular-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
 ├─2019790 gpg-agent --homedir
/var/cache/PackageKit/32/metadata/updates-modular-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
 ├─2019808 gpg-agent --homedir
/var/cache/PackageKit/32/metadata/google-chrome-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
 ├─2019819 gpg-agent --homedir
/var/cache/PackageKit/32/metadata/updates-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
 ├─2019838 gpg-agent --homedir
/var/cache/PackageKit/32/metadata/rpmfusion-free-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
 ├─2019857 gpg-agent --homedir
/var/cache/PackageKit/32/metadata/ring-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
 ├─2019868 gpg-agent --homedir
/var/cache/PackageKit/32/metadata/rpmfusion-free-updates-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
 ├─2019885 gpg-agent --homedir
/var/cache/PackageKit/32/metadata/fedora-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
 └─2019926 gpg-agent --homedir

Re: calculating process memory usage

[Chris Murphy]

On Fri, Aug 14, 2020 at 2:29 PM Samuel Sieb  wrote:
>
> On 8/14/20 11:41 AM, Sergio Belkin wrote:
> > Perhaps this ps_mem snippet is useful:
> >  > Private  +   Shared  =  RAM used   Program
> > 
> > 
> > 
> > 294.8 MiB +   4.7 MiB = 299.4 MiB   telegram-desktop.bin
> > 290.3 MiB +  22.1 MiB = 312.4 MiB   rocketchat-desktop (5)
> > 323.8 MiB +   9.5 MiB = 333.2 MiB   kwin_x11 (9)
> > 344.5 MiB +   1.4 MiB = 345.8 MiB   nextcloud
> > 373.2 MiB +  21.2 MiB = 394.4 MiB   spotify (5)
> > 416.6 MiB +   1.3 MiB = 417.9 MiB   plasma-discover
> > 448.5 MiB +  16.6 MiB = 465.2 MiB   MainThread
> > 892.8 MiB + 444.5 KiB = 893.2 MiB   packagekitd
> >1.0 GiB +   8.6 MiB =   1.0 GiB   plasmashell
> >1.9 GiB +  81.0 MiB =   1.9 GiB   Web Content (9)
> > -
> >9.7 GiB
> > =
>
> Since you've brought this up, this is a question I've had for a long
> time.  How do you get real memory+swap usage information for processes
> or is that even possible?  Looking in ps or top, the RES is way too
> small and the VIRT/VSIZE is way too big.  ps_mem is also way too small,
> or at least the total is less than half of the real memory usage.  Is
> there something else using that much memory that isn't processes?
> buffers and cache don't account for the difference either.


Maybe ...

/proc/pid/status

VmHWM or  VmRSS + VmSwap


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

Non-responsive maintainer check for bochecha

[Artem Tim]

Hi. Anyone know how to contact Mathieu Bridon [FAS name: bochecha]?

'buildstream' package need urgent update. Related bug reports:

- https://bugzilla.redhat.com/show_bug.cgi?id=1868983
- https://bugzilla.redhat.com/show_bug.cgi?id=1821245
- PR with fix: https://src.fedoraproject.org/rpms/buildstream/pull-request/1

cc: boche...@daitauha.fr
___
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: calculating process memory usage

[Samuel Sieb]

On 8/14/20 11:41 AM, Sergio Belkin wrote:

Perhaps this ps_mem snippet is useful:



294.8 MiB +   4.7 MiB = 299.4 MiB       telegram-desktop.bin
290.3 MiB +  22.1 MiB = 312.4 MiB       rocketchat-desktop (5)
323.8 MiB +   9.5 MiB = 333.2 MiB       kwin_x11 (9)
344.5 MiB +   1.4 MiB = 345.8 MiB       nextcloud
373.2 MiB +  21.2 MiB = 394.4 MiB       spotify (5)
416.6 MiB +   1.3 MiB = 417.9 MiB       plasma-discover
448.5 MiB +  16.6 MiB = 465.2 MiB       MainThread
892.8 MiB + 444.5 KiB = 893.2 MiB       packagekitd
   1.0 GiB +   8.6 MiB =   1.0 GiB       plasmashell
   1.9 GiB +  81.0 MiB =   1.9 GiB       Web Content (9)
-
                           9.7 GiB
=


Since you've brought this up, this is a question I've had for a long 
time.  How do you get real memory+swap usage information for processes 
or is that even possible?  Looking in ps or top, the RES is way too 
small and the VIRT/VSIZE is way too big.  ps_mem is also way too small, 
or at least the total is less than half of the real memory usage.  Is 
there something else using that much memory that isn't processes? 
buffers and cache don't account for the difference either.

___
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: Strange build failures in rawhide buildroot (cont'd) - glibc 2.33 dev snapshot?

[Jerry James]

On Fri, Aug 14, 2020 at 1:29 PM Jerry James  wrote:
> I added "exit 1" to the end of %install in one of the affected OCaml
> packages, so that I could inspect the contents of
> /builddir/build/BUILDROOT in the mock chroot.  The files all have the
> correct permissions.  Yet when the binary RPM is generated, executable
> files are missing write permission for user; i.e., they have 555
> permissions instead of 755.
>
> I am also seeing "Error in  scriptlet in rpm package x",
> where x is some random package, when running mock with
> --enablerepo=local, just as Fabio reported.
>
> The combination of the two makes me suspect that RPM has gone bonkers
> in Rawhide, whether due to the new version of glibc or something else,
> I couldn't say.

I just did a koji build of an OCaml package for Rawhide.  None of the
above happened.  So whatever is going on is affecting mock
--enablerepo=local builds for Fabio and me, at least, but does not
appear to affect koji builds.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: EarlyOOM +ZRAM Only

[Chris Murphy]

On Fri, Aug 14, 2020 at 12:42 PM Sergio Belkin  wrote:
>
> 2 comments:
> - I don't use disk-based swap, only zram.
> - It happened again, and in this case there is no Virtual Machine nor Zoom 
> app running:
> ago 14 15:08:37 dublin.ireland.home earlyoom[888]: sending SIGTERM to process 
> 2052260 uid 1000 "Web Content": badness 322, VmRSS 447 MiB
> ago 14 15:08:40 dublin.ireland.home earlyoom[888]: process exited after 2.7 
> seconds
> ago 14 15:12:15 dublin.ireland.home earlyoom[888]: mem avail:   395 of 15887 
> MiB ( 2.49%), swap free:0 of 4095 MiB ( 0.00%)
> ago 14 15:12:15 dublin.ireland.home earlyoom[888]: low memory! at or below 
> SIGTERM limits: mem  2.52%, swap 10.00%
> ago 14 15:12:15 dublin.ireland.home earlyoom[888]: sending SIGTERM to process 
> 2055755 uid 1000 "Web Content": badness 319, VmRSS 392 MiB
> ago 14 15:12:17 dublin.ireland.home earlyoom[888]: process exited after 2.8 
> seconds
> ago 14 15:28:35 dublin.ireland.home earlyoom[888]: mem avail:   371 of 15887 
> MiB ( 2.34%), swap free:0 of 4095 MiB ( 0.00%)
> ago 14 15:28:35 dublin.ireland.home earlyoom[888]: low memory! at or below 
> SIGTERM limits: mem  2.52%, swap 10.00%
> ago 14 15:28:35 dublin.ireland.home earlyoom[888]: sending SIGTERM to process 
> 2062157 uid 1000 "Web Content": badness 327, VmRSS 553 MiB
> ago 14 15:28:37 dublin.ireland.home earlyoom[888]: process exited after 2.3 
> seconds


What's the workload? What  is filling up 4G of swap with inactive
pages such that none of them are being freed? The usual case is
available memory is well below the watermark before swap has filled.
But in this case, it's the opposite.

As sigterm is happening, memory available is still dropping. Some
process is still taking up more memory, but has low enough badness
that its not being terminated. It could be one of the exempt
processes.

>
> Perhaps this ps_mem snippet is useful:
>  Private  +   Shared  =  RAM used   Program
> 
> 
> 
> 294.8 MiB +   4.7 MiB = 299.4 MiB   telegram-desktop.bin
> 290.3 MiB +  22.1 MiB = 312.4 MiB   rocketchat-desktop (5)
> 323.8 MiB +   9.5 MiB = 333.2 MiB   kwin_x11 (9)
> 344.5 MiB +   1.4 MiB = 345.8 MiB   nextcloud
> 373.2 MiB +  21.2 MiB = 394.4 MiB   spotify (5)
> 416.6 MiB +   1.3 MiB = 417.9 MiB   plasma-discover
> 448.5 MiB +  16.6 MiB = 465.2 MiB   MainThread
> 892.8 MiB + 444.5 KiB = 893.2 MiB   packagekitd
>   1.0 GiB +   8.6 MiB =   1.0 GiB   plasmashell
>   1.9 GiB +  81.0 MiB =   1.9 GiB   Web Content (9)

892M for packagekit? Seems excessive. I wonder what's up with that. It
is an exempt process. On my current system it's 1/2 that amount, which
is in turn twice that of GNOME shell. Hmm.

> Well I'll report soon, any  idea (remember I have 16 GB of RAM with 4G of 
> zram-based swap) will be welcome

Very common. The defaults need to serve this use case.

-- 
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: Strange build failures in rawhide buildroot (cont'd) - glibc 2.33 dev snapshot?

[Jerry James]

On Fri, Aug 14, 2020 at 1:15 PM Fabio Valentini  wrote:
> Sérgio, I have no idea what you're talking about here. Do you mean the
> new policy to wait with a rawhide compose until the first "branched"
> compose is successful and synced out? If I understand correctly, that
> "policy" is enforced by bodhi not allowing any builds into "branched"
> by default, and releng not launching any rawhide composes until a
> "branched" compose finishes.
>
> I have no superpowers that allow me to circumvent those restrictions :)
> If I had, I would untag glibc 2.22.9000 to check if it is indeed
> broken, or if my development PC is haunted instead.

I added "exit 1" to the end of %install in one of the affected OCaml
packages, so that I could inspect the contents of
/builddir/build/BUILDROOT in the mock chroot.  The files all have the
correct permissions.  Yet when the binary RPM is generated, executable
files are missing write permission for user; i.e., they have 555
permissions instead of 755.

I am also seeing "Error in  scriptlet in rpm package x",
where x is some random package, when running mock with
--enablerepo=local, just as Fabio reported.

The combination of the two makes me suspect that RPM has gone bonkers
in Rawhide, whether due to the new version of glibc or something else,
I couldn't say.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Strange build failures in rawhide buildroot (cont'd) - glibc 2.33 dev snapshot?

[Fabio Valentini]

On Fri, Aug 14, 2020 at 8:48 PM Sérgio Basto  wrote:
>
> On Fri, 2020-08-14 at 20:30 +0200, Fabio Valentini wrote:
> > So, I've been trying to figure out strange build failures in my Java
> > packages when running mock with `--enablerepo local`.
> >
> > First I thought java-11-openjdk update might be to blame, but now I
> > found another "unrelated" issue:
> >
> > OCaml packages built with dune and `--enablerepo local` right now
> > produce packages where binaries get permissions `555` set instead of
> > `755` despite dune explicitly setting 755.
> >
> > So ... Huh?
> >
> > The only package update other than python 3.9 beta 5 → python 3.9 rc
> > 1
> > and a Java update that happened in this time frame - which might
> > affect *both* Java *and* OCaml builds in weird ways - would be ...
> > the
> > first glibc 2.33 development snapshot.
>
> It is against the new policy rules, please only update rawhide after
> completing the first branched compose and his mirror
> synchronization. i.e when we have a new buildroot .
>
> While the compose today seems successful is not yet published

Sérgio, I have no idea what you're talking about here. Do you mean the
new policy to wait with a rawhide compose until the first "branched"
compose is successful and synced out? If I understand correctly, that
"policy" is enforced by bodhi not allowing any builds into "branched"
by default, and releng not launching any rawhide composes until a
"branched" compose finishes.

I have no superpowers that allow me to circumvent those restrictions :)
If I had, I would untag glibc 2.22.9000 to check if it is indeed
broken, or if my development PC is haunted instead.

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: Strange build failures in rawhide buildroot (cont'd) - glibc 2.33 dev snapshot?

[Sérgio Basto]

On Fri, 2020-08-14 at 20:30 +0200, Fabio Valentini wrote:
> So, I've been trying to figure out strange build failures in my Java
> packages when running mock with `--enablerepo local`.
> 
> First I thought java-11-openjdk update might be to blame, but now I
> found another "unrelated" issue:
> 
> OCaml packages built with dune and `--enablerepo local` right now
> produce packages where binaries get permissions `555` set instead of
> `755` despite dune explicitly setting 755.
> 
> So ... Huh?
> 
> The only package update other than python 3.9 beta 5 → python 3.9 rc
> 1
> and a Java update that happened in this time frame - which might
> affect *both* Java *and* OCaml builds in weird ways - would be ...
> the
> first glibc 2.33 development snapshot.

It is against the new policy rules, please only update rawhide after
completing the first branched compose and his mirror 
synchronization. i.e when we have a new buildroot .

While the compose today seems successful is not yet published 


> Can somebody check if I'm going mad, if my PC now started producing
> Heisenbugs, or if there's actually something wrong with rawhide -
> possibly with the glibc snapshot?
> 
> 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
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: EarlyOOM +ZRAM Only

[Sergio Belkin]

El vie., 14 ago. 2020 a las 9:28, Przemek Klosowski via devel (<
devel@lists.fedoraproject.org>) escribió:

> On 8/14/20 7:33 AM, John M. Harris Jr wrote:
> > On Wednesday, August 12, 2020 1:16:34 PM MST Przemek Klosowski via devel
> > wrote:
> >>
> >> This is weird---your swap was 100% full, and ram almost full, and yet
> >> killing 4GB VirtualBox didn't seem to free up memory. I suspect some
> >> sort of measurement or reporting error---if these numbers were accurate,
> >> EarlyOOM did have a reason to panic and kill zoom. BTW, zoom taking 721
> >> MiB is crazy.
>
> > Are you kidding? The system still had over a quarter of a gigabyte of
> free
> > RAM. There's no reason to start killing off processes at that point.
> That's
> > tons of free memory. To put that into perspective, that's enough free
> memory
> > to store over 1000 average-length novels directly in memory.
>
> When the swap is 100% full, it is not like you have a bunch of processes
> neatly stored in it, and some free memory available---you have a mess of
> partly swapped out processes reading back their pages from swap and
> pushing other processes' RAM pages onto the fragmented swap, when they
> are trying to run.
>
> This is the worst case of disk usage, and as we discussed before, the
> transfer speeds for such traffic will be hundreds/thousands times
> slower---I would expect latencies going into tens of seconds. So, no, I
> am not kidding.
> ___
>

2 comments:
- I don't use disk-based swap, only zram.
- It happened again, and in this case there is no Virtual Machine nor Zoom
app running:
ago 14 15:08:37 dublin.ireland.home earlyoom[888]: sending SIGTERM to
process 2052260 uid 1000 "Web Content": badness 322, VmRSS 447 MiB
ago 14 15:08:40 dublin.ireland.home earlyoom[888]: process exited after 2.7
seconds
ago 14 15:12:15 dublin.ireland.home earlyoom[888]: mem avail:   395 of
15887 MiB ( 2.49%), swap free:0 of 4095 MiB ( 0.00%)
ago 14 15:12:15 dublin.ireland.home earlyoom[888]: low memory! at or below
SIGTERM limits: mem  2.52%, swap 10.00%
ago 14 15:12:15 dublin.ireland.home earlyoom[888]: sending SIGTERM to
process 2055755 uid 1000 "Web Content": badness 319, VmRSS 392 MiB
ago 14 15:12:17 dublin.ireland.home earlyoom[888]: process exited after 2.8
seconds
ago 14 15:28:35 dublin.ireland.home earlyoom[888]: mem avail:   371 of
15887 MiB ( 2.34%), swap free:0 of 4095 MiB ( 0.00%)
ago 14 15:28:35 dublin.ireland.home earlyoom[888]: low memory! at or below
SIGTERM limits: mem  2.52%, swap 10.00%
ago 14 15:28:35 dublin.ireland.home earlyoom[888]: sending SIGTERM to
process 2062157 uid 1000 "Web Content": badness 327, VmRSS 553 MiB
ago 14 15:28:37 dublin.ireland.home earlyoom[888]: process exited after 2.3
seconds

Perhaps this ps_mem snippet is useful:



294.8 MiB +   4.7 MiB = 299.4 MiB   telegram-desktop.bin
290.3 MiB +  22.1 MiB = 312.4 MiB   rocketchat-desktop (5)
323.8 MiB +   9.5 MiB = 333.2 MiB   kwin_x11 (9)
344.5 MiB +   1.4 MiB = 345.8 MiB   nextcloud
373.2 MiB +  21.2 MiB = 394.4 MiB   spotify (5)
416.6 MiB +   1.3 MiB = 417.9 MiB   plasma-discover
448.5 MiB +  16.6 MiB = 465.2 MiB   MainThread
892.8 MiB + 444.5 KiB = 893.2 MiB   packagekitd
  1.0 GiB +   8.6 MiB =   1.0 GiB   plasmashell
  1.9 GiB +  81.0 MiB =   1.9 GiB   Web Content (9)
-
  9.7 GiB
=


Well I'll report soon, any  idea (remember I have 16 GB of RAM with 4G of
zram-based swap) will be welcome
-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.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

Strange build failures in rawhide buildroot (cont'd) - glibc 2.33 dev snapshot?

[Fabio Valentini]

So, I've been trying to figure out strange build failures in my Java
packages when running mock with `--enablerepo local`.

First I thought java-11-openjdk update might be to blame, but now I
found another "unrelated" issue:

OCaml packages built with dune and `--enablerepo local` right now
produce packages where binaries get permissions `555` set instead of
`755` despite dune explicitly setting 755.

So ... Huh?

The only package update other than python 3.9 beta 5 → python 3.9 rc 1
and a Java update that happened in this time frame - which might
affect *both* Java *and* OCaml builds in weird ways - would be ... the
first glibc 2.33 development snapshot.

Can somebody check if I'm going mad, if my PC now started producing
Heisenbugs, or if there's actually something wrong with rawhide -
possibly with the glibc snapshot?

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

[Wells, Roger K. via devel]

On 8/14/20 9:15 AM, Wells, Roger K. via devel wrote:
On 8/14/20 8:45 AM, Przemek Klosowski via devel wrote:
On 8/14/20 8:33 AM, Wells, Roger K. via devel wrote:

That was not the cause.
Now when it happens I have only three tasks running at 100% (same ones
as reported earlier).
Everything else, kerneloops, shutdown via power switch, etc, is as before.


Could you repost to the list with more info? I think you're saying that after 
removing sadc you still are 100% CPU with

kworker/6:1+events_freezable
dmesg
systemd-journal

That is correct.  The "6:1" in the kworker case varies.

running full tilt. THis probably means that it's the kernel worker threads are 
doing something that causes lots of errors, and all the other processes 
(including sadc that is now gone) are just busy writing those errors.

So, what is kernel doing? what does your system log say? type 'dmesg' or 
'journalctl -e' and look at the end of the data.

The following repeats at the end of journalctl:
In the last second of the journal there are 14688 individual entries.

Aug 13 18:23:51 rwells-x280 kernel: Hardware name: LENOVO 
20KFCTO1WW/20KFCTO1WW, BIOS N20ET55W (1.40 ) 06/01/2020
Aug 13 18:23:51 rwells-x280 kernel: Workqueue: events_freezable 
ieee80211_restart_work [mac80211]
Aug 13 18:23:51 rwells-x280 kernel: RIP: 0010:drv_sta_state+0x26e/0x3e0 
[mac80211]
Aug 13 18:23:51 rwells-x280 kernel: Code: 0b 45 31 ed e9 44 fe ff ff 48 8b 83 
78 04 00 00 48 8d b3 98 04 00 00 48 c7 c7 80 46 f2 c0 48 85 c0 48 0f 45 f0 e8 
c9 bf 23 d2 <0f> 0b 41 bd fb ff ff ff e9 1b fe ff ff 65 8b 05 be fc 16 3f 89 c0
Aug 13 18:23:51 rwells-x280 systemd-journald[928]: Missed 44 kernel messages
Aug 13 18:23:51 rwells-x280 kernel:  iTCO_wdt mac80211 iTCO_vendor_support 
snd_hda_intel irqbypass intel_rapl_msr snd_intel_dspcfg rapl snd_hda_codec 
libarc4 snd_hda_core uvcvideo intel_cstate iwlwifi snd_hwdep btusb 
videobuf2_vmalloc snd_seq intel_uncore videobuf2_memops btrtl videobuf2_v4l2 
btbcm snd_seq_device btintel snd_pcm pcspkr cfg80211 mei_me wmi_bmof 
intel_wmi_thunderbolt videobuf2_common i2c_i801 snd_timer thunderbolt videodev 
bluetooth mei intel_pch_thermal mc thinkpad_acpi ucsi_acpi joydev typec_ucsi 
processor_thermal_device ecdh_generic intel_rapl_common ledtrig_audio ecc 
intel_xhci_usb_role_switch roles intel_soc_dts_iosf typec snd soundcore rfkill 
int3403_thermal int340x_thermal_zone int3400_thermal acpi_thermal_rel acpi_pad 
ip_tables dm_crypt i915 i2c_algo_bit cec crct10dif_pclmul crc32_pclmul 
crc32c_intel drm_kms_helper ghash_clmulni_intel nvme drm serio_raw e1000e uas 
nvme_core usb_storage wmi video hid_multitouch fuse
Aug 13 18:23:51 rwells-x280 kernel: CPU: 0 PID: 5 Comm: kworker/0:0 Tainted: G  
  W 5.7.12-200.fc32.x86_64 #1


Also, the perf toolkit might help as explained in 
https://askubuntu.com/questions/33640/kworker-what-is-it-and-why-is-it-hogging-so-much-cpu


  1.  Install perf:

sudo apt-get install linux-tools-common linux-tools-3.11.0-15-generic


(The second package must match your kernel version. You can first install just 
linux-tools-common and call perf to let it tell you which package it needs.)

  2.  Record some 10 seconds of backtraces on all your CPUs:

sudo perf record -g -a sleep 10


  3.  Analyse your recording:

sudo perf report


I'll give this a try
thanks

I did it but I should have remembered earlier:
When this happens all sudo prefaced terminal input just locks up and never 
(apparently) executes.
Maybe there is a clue here?

  1.



___
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



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

Re: Debug doxygen generated files with different names in noarch package

[Richard Shaw]

On Fri, Aug 14, 2020 at 7:12 AM Rich Mattes  wrote:

>
> On Fri, Aug 14, 2020, 7:37 AM Richard Shaw  wrote:
>
>>
>> I'm getting consistent differences across at least two versions of zipios
>> and the offending arches seem to always be s390x and ppc64le.
>>
>> BuildError: The following noarch package built differently on different
>> architectures: zipios-doc-2.2.1.0-5.fc33.noarch.rpm
>> rpmdiff output was:
>> removed
>> /usr/share/doc/zipios/html/dir_0f7abfb91da657dcb27dff31b827312f.html
>> removed
>> /usr/share/doc/zipios/html/dir_32504400af4b8c553a85c61a7ef01dea.html
>> added
>> /usr/share/doc/zipios/html/dir_8f6b9ad7431774f92e3ec3efe35ac7da.html
>> added
>> /usr/share/doc/zipios/html/dir_dd208edd458824e9eaf902c6da16200d.html
>>
>> zipios 2.2.5.0
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=49057750
>>
>> zipios 2.2.1.0
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=48597282
>>
>> Is this likely a big vs little endian thing?
>>
>> Is it a CMake package? The vpath_builddir that is now used for out of
> source builds is different for each architecture. If that directory is
> included in the doxygen processing paths you'll get this error.
>

Yes, but why is doxygen using that to generate a directory name? Bah...



> I worked around this in a few of my packages by adding the cmake build
> directory to the EXCLUDE list in the doxyfile.
>

I added a patch to the doxy.in file and it seemed to get rid of one of the
directory problems, but not both...

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

Patch:

$ cat zipios-doxygen.patch
Index: doc/zipios.doxy.in
===
--- Zipios/doc.orig/zipios.doxy.in
+++ Zipios/doc/zipios.doxy.in
@@ -152,7 +152,7 @@ FULL_PATH_NAMES= YES
 # will be relative from the directory where doxygen is started.
 # This tag requires that the tag FULL_PATH_NAMES is set to YES.

-STRIP_FROM_PATH= @CMAKE_CURRENT_SOURCE_DIR@
+STRIP_FROM_PATH= @CMAKE_CURRENT_BINARY_DIR@

 # The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of
the
 # path mentioned in the documentation of a class, which tells the reader
which

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.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: Unannounced soname bump: libreport

[Tomasz Torcz]

On Fri, Aug 14, 2020 at 11:14:59AM -0400, Neal Gompa wrote:
> On Fri, Aug 14, 2020 at 11:12 AM Fabio Valentini  wrote:
> >
> > On Fri, Aug 14, 2020 at 5:01 PM Michael Schwendt  
> > wrote:
> > >
> > > On Fri, 14 Aug 2020 16:37:28 +0200, Fabio Valentini wrote:
> > >
> > > > > As a side note, the update now has arch specific BuildRequires, so 
> > > > > the SRPM
> > > > > cannot be rebuilt on anything but .
> > > > >
> > > > > https://koschei.fedoraproject.org/package/libreport?collection=f33
> > > >
> > > > Aaaw ... stuff like this makes me sad :(
> > >
> > > What makes me sad is the poorly maintained package %changelog. Instead of
> > > summing up changes to the RPM package, it sums up changes internal to
> > > libreport. It does not list any of the spec file changes.
> > >
> > > A massive commit to the package without any %changelog entry:
> > > https://src.fedoraproject.org/rpms/libreport/c/246d3174118e03cbb345f1d434f3fbe11864b015?branch=master
> >
> > True. This is bad :( This is also the commit that added %{?_isa} to
> > BuildRequires. WHYYY
> >
> > > And later the addition of a %changelog entry that doesn't cover any of the
> > > package changes.
> >
> > It's also for the wrong version (2.13-2 instead of 2.14-2) ... which
> > was fixed in the next commit, with another Release bump. :(
> 
> As far as I know, libreport is directly synced from the
> libreport.spec.in in the libreport git repo on GitHub:
> https://github.com/abrt/libreport/blob/master/libreport.spec.in

  So %{_isa} changes would be from this:
  
https://github.com/abrt/libreport/commit/729214f13b1c036e4f9299ddcd12e9219a6ab60a

> I am unsure if ABRT folks are even reviewing stuff going on in Dist-Git...

  What do you mean by that?

-- 
Tomasz TorczTo co nierealne – tutaj jest normalne.
to...@pipebreaker.pl  Ziomale na życie mają tu patenty specjalne.
___
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

Strange Java package build failures (Error in scriptlet ?)

[Fabio Valentini]

Hi everybody,

Since ~2 days ago, the rawhide koji buildroot has exhibited some
*really weird* issues when building Java packages with maven (when
building packages locally with "mock -r fedora-rawhide-x86_64
--enablerepo local foo.src.rpm").

During installation of the build dependencies, some random (?) Java
package will have a scriptlet failure like this: "Error in 
scriptlet in rpm package mockito" (the package that this error occurs
in is not always the same). This is always the last scriptlet run
before the "Verifying" stage of "dnf install".

Then, later, during execution of %build, the following errors show up,
which make the it fail:

/usr/share/maven/bin/mvn: Failed to set JAVACMD
The JAVA_HOME environment variable is not defined correctly
This environment variable is needed to run this program
NB: JAVA_HOME should point to a JDK not a JRE

Sometimes, scrubbing the mock buildroot makes the next build succeed,
sometimes it doesn't. I tried entering the buildroot with "mock shell"
but it didn't yield any useful information.

I see that the scripts setting up JAVA_HOME etc. try to find a java +
javac executable, but they're all there, and the alternatives setup
also looks sane (no broken links in /etc/alternatives).

The only Java related updates I see in the buildroot for the "critical
time frame" are builds of java-11-openjdk, but I'm not sure how they
could have introduced such inconsistently buggy buildroot behaviour :(

Does anybody have an idea what might be the problem here? It's really
annoying to be unable to build Java packages locally most of the time
(curiously, I haven't seen this issue happen in any koji builds yet).

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

[Tony Nelson]

On 20-08-14 09:14:51, Wells, Roger K. via devel wrote:

On 8/14/20 8:45 AM, Przemek Klosowski via devel wrote:


So, what is kernel doing? what does your system log say? type  
'dmesg' or 'journalctl -e' and look at the end of the data.


The following repeats at the end of journalctl:
In the last second of the journal there are 14688 individual entries.

Aug 13 18:23:51 rwells-x280 kernel: Hardware name: LENOVO  
20KFCTO1WW/20KFCTO1WW, BIOS N20ET55W (1.40 ) 06/01/2020
Aug 13 18:23:51 rwells-x280 kernel: Workqueue: events_freezable  
ieee80211_restart_work [mac80211]
Aug 13 18:23:51 rwells-x280 kernel: RIP:  
0010:drv_sta_state+0x26e/0x3e0 [mac80211]
Aug 13 18:23:51 rwells-x280 kernel: Code: 0b 45 31 ed e9 44 fe ff ff  
48 8b 83 78 04 00 00 48 8d b3 98 04 00 00 48 c7 c7 80 46 f2 c0 48 85  
c0 48 0f 45 f0 e8 c9 bf 23 d2 <0f> 0b 41 bd fb ff ff ff e9 1b fe ff  
ff 65 8b 05 be fc 16 3f 89 c0
Aug 13 18:23:51 rwells-x280 systemd-journald[928]: Missed 44 kernel  
messages
Aug 13 18:23:51 rwells-x280 kernel:  iTCO_wdt mac80211  
iTCO_vendor_support snd_hda_intel irqbypass intel_rapl_msr  
snd_intel_dspcfg rapl snd_hda_codec libarc4 snd_hda_core uvcvideo  
intel_cstate iwlwifi snd_hwdep btusb videobuf2_vmalloc snd_seq  
intel_uncore videobuf2_memops btrtl videobuf2_v4l2 btbcm  
snd_seq_device btintel snd_pcm pcspkr cfg80211 mei_me wmi_bmof  
intel_wmi_thunderbolt videobuf2_common i2c_i801 snd_timer thunderbolt  
videodev bluetooth mei intel_pch_thermal mc thinkpad_acpi ucsi_acpi  
joydev typec_ucsi processor_thermal_device ecdh_generic  
intel_rapl_common ledtrig_audio ecc intel_xhci_usb_role_switch roles  
intel_soc_dts_iosf typec snd soundcore rfkill int3403_thermal  
int340x_thermal_zone int3400_thermal acpi_thermal_rel acpi_pad  
ip_tables dm_crypt i915 i2c_algo_bit cec crct10dif_pclmul  
crc32_pclmul crc32c_intel drm_kms_helper ghash_clmulni_intel nvme drm  
serio_raw e1000e uas nvme_core usb_storage wmi video hid_multitouch  
fuse
Aug 13 18:23:51 rwells-x280 kernel: CPU: 0 PID: 5 Comm: kworker/0:0  
Tainted: GW 5.7.12-200.fc32.x86_64 #1


There is a problem with your WIFI adapter (what mac80211 is referring
to).  I don't think you can unplug and replug the adapter, which would
likely help, so don't just reset the computer, but power-cycle it.

Sometimes dmesg has messages that don't make it into the log due to
rate-limiting.  Not sure how to see dmesg when things are jammed up.

Do you know if the problem depends on a particular kernel?  Ususally
an older kernel will work, even if it isn't for the current version of
Fedora.  If that helps, try to narrow it down to a particular kernel.
If you find a boundary where it starts happening, report it on the
kernel bugzilla. You won't be able to properly report the bug, since
your kernel is tainted, but reporting it improperly may still be worth
something to kernel developers.

I suspect the hardware, but I'm often wrong.

--

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

Re: Non-responsive maintainer check: spike

[Fabio Valentini]

On Fri, Aug 14, 2020 at 4:52 PM spike  wrote:
>
> Hi Fabio,
>
> Contacting me should be somewhat straight forward through the email address 
> associated with my user id in FAS or through IRC. Let me know how I can help.
>
> Cheers

We have resolved this issue on bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1868943

spike has orphaned some packages and joined the "new" Java SIG to
share maintenance of the rest.
So I'd consider this "problem" solved :)

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: Unannounced soname bump: libreport

[Neal Gompa]

On Fri, Aug 14, 2020 at 11:12 AM Fabio Valentini  wrote:
>
> On Fri, Aug 14, 2020 at 5:01 PM Michael Schwendt  wrote:
> >
> > On Fri, 14 Aug 2020 16:37:28 +0200, Fabio Valentini wrote:
> >
> > > > As a side note, the update now has arch specific BuildRequires, so the 
> > > > SRPM
> > > > cannot be rebuilt on anything but .
> > > >
> > > > https://koschei.fedoraproject.org/package/libreport?collection=f33
> > >
> > > Aaaw ... stuff like this makes me sad :(
> >
> > What makes me sad is the poorly maintained package %changelog. Instead of
> > summing up changes to the RPM package, it sums up changes internal to
> > libreport. It does not list any of the spec file changes.
> >
> > A massive commit to the package without any %changelog entry:
> > https://src.fedoraproject.org/rpms/libreport/c/246d3174118e03cbb345f1d434f3fbe11864b015?branch=master
>
> True. This is bad :( This is also the commit that added %{?_isa} to
> BuildRequires. WHYYY
>
> > And later the addition of a %changelog entry that doesn't cover any of the
> > package changes.
>
> It's also for the wrong version (2.13-2 instead of 2.14-2) ... which
> was fixed in the next commit, with another Release bump. :(

As far as I know, libreport is directly synced from the
libreport.spec.in in the libreport git repo on GitHub:
https://github.com/abrt/libreport/blob/master/libreport.spec.in

I am unsure if ABRT folks are even reviewing stuff going on in Dist-Git...




-- 
真実はいつも一つ！/ 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: Unannounced soname bump: libreport

[Fabio Valentini]

On Fri, Aug 14, 2020 at 5:01 PM Michael Schwendt  wrote:
>
> On Fri, 14 Aug 2020 16:37:28 +0200, Fabio Valentini wrote:
>
> > > As a side note, the update now has arch specific BuildRequires, so the 
> > > SRPM
> > > cannot be rebuilt on anything but .
> > >
> > > https://koschei.fedoraproject.org/package/libreport?collection=f33
> >
> > Aaaw ... stuff like this makes me sad :(
>
> What makes me sad is the poorly maintained package %changelog. Instead of
> summing up changes to the RPM package, it sums up changes internal to
> libreport. It does not list any of the spec file changes.
>
> A massive commit to the package without any %changelog entry:
> https://src.fedoraproject.org/rpms/libreport/c/246d3174118e03cbb345f1d434f3fbe11864b015?branch=master

True. This is bad :( This is also the commit that added %{?_isa} to
BuildRequires. WHYYY

> And later the addition of a %changelog entry that doesn't cover any of the
> package changes.

It's also for the wrong version (2.13-2 instead of 2.14-2) ... which
was fixed in the next commit, with another Release bump. :(
___
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: Unannounced soname bump: libreport

[Michael Schwendt]

On Fri, 14 Aug 2020 16:37:28 +0200, Fabio Valentini wrote:

> > As a side note, the update now has arch specific BuildRequires, so the SRPM
> > cannot be rebuilt on anything but .
> >
> > https://koschei.fedoraproject.org/package/libreport?collection=f33  
> 
> Aaaw ... stuff like this makes me sad :(

What makes me sad is the poorly maintained package %changelog. Instead of
summing up changes to the RPM package, it sums up changes internal to
libreport. It does not list any of the spec file changes.

A massive commit to the package without any %changelog entry:
https://src.fedoraproject.org/rpms/libreport/c/246d3174118e03cbb345f1d434f3fbe11864b015?branch=master

And later the addition of a %changelog entry that doesn't cover any of the
package changes.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Non-responsive maintainer check: spike

[spike]

Hi Fabio,

Contacting me should be somewhat straight forward through the email address 
associated with my user id in FAS or through IRC. Let me know how I can help.

Cheers

On 14.08.20 16:12, Fabio Valentini wrote:
> Hi everybody,
> 
> The Java package stack cleanup process continues, and I need to do
> another non-responsive maintainer check, this time for: spike. I have
> opened the corresponding non-responsive-check bug:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1868943
> 
> There's a growing list of bugs that are open against their packages:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1643710
> https://bugzilla.redhat.com/show_bug.cgi?id=1863215
> https://bugzilla.redhat.com/show_bug.cgi?id=1857884
> https://bugzilla.redhat.com/show_bug.cgi?id=1714899
> https://bugzilla.redhat.com/show_bug.cgi?id=1331897
> https://bugzilla.redhat.com/show_bug.cgi?id=1863216
> https://bugzilla.redhat.com/show_bug.cgi?id=1857888
> https://bugzilla.redhat.com/show_bug.cgi?id=1863609
> https://bugzilla.redhat.com/show_bug.cgi?id=1857943
> https://bugzilla.redhat.com/show_bug.cgi?id=1586304
> https://bugzilla.redhat.com/show_bug.cgi?id=1413019
> 
> All those bugs are untouched. Most of them are either FTBFS or
> release-monitoring bugs. Some of spike's packages have already been
> retired due to being orphaned as part of the long-term FTBFS policy.
> 
> Looking at koji, spike has not been an active packager in fedora since
> 2012, with the exception of *one* mkrdns update in 2019:
> 
> https://koji.fedoraproject.org/koji/userinfo?userID=1473
> 
> Does anybody know if they still want to maintain their packages
> (particularly the Java packages), or how to contact them?
> 
> 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: Unannounced soname bump: libreport

[Fabio Valentini]

On Fri, Aug 14, 2020 at 4:32 PM Miro Hrončok  wrote:
>
> On 14. 08. 20 2:10, 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
>  > ...
>
> As a side note, the update now has arch specific BuildRequires, so the SRPM
> cannot be rebuilt on anything but .
>
> https://koschei.fedoraproject.org/package/libreport?collection=f33

Aaaw ... stuff like this makes me sad :(
___
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: Unannounced soname bump: libreport

[Miro Hrončok]

On 14. 08. 20 2:10, 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

> ...

As a side note, the update now has arch specific BuildRequires, so the SRPM 
cannot be rebuilt on anything but .


https://koschei.fedoraproject.org/package/libreport?collection=f33

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

Non-responsive maintainer check: spike

[Fabio Valentini]

Hi everybody,

The Java package stack cleanup process continues, and I need to do
another non-responsive maintainer check, this time for: spike. I have
opened the corresponding non-responsive-check bug:

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

There's a growing list of bugs that are open against their packages:

https://bugzilla.redhat.com/show_bug.cgi?id=1643710
https://bugzilla.redhat.com/show_bug.cgi?id=1863215
https://bugzilla.redhat.com/show_bug.cgi?id=1857884
https://bugzilla.redhat.com/show_bug.cgi?id=1714899
https://bugzilla.redhat.com/show_bug.cgi?id=1331897
https://bugzilla.redhat.com/show_bug.cgi?id=1863216
https://bugzilla.redhat.com/show_bug.cgi?id=1857888
https://bugzilla.redhat.com/show_bug.cgi?id=1863609
https://bugzilla.redhat.com/show_bug.cgi?id=1857943
https://bugzilla.redhat.com/show_bug.cgi?id=1586304
https://bugzilla.redhat.com/show_bug.cgi?id=1413019

All those bugs are untouched. Most of them are either FTBFS or
release-monitoring bugs. Some of spike's packages have already been
retired due to being orphaned as part of the long-term FTBFS policy.

Looking at koji, spike has not been an active packager in fedora since
2012, with the exception of *one* mkrdns update in 2019:

https://koji.fedoraproject.org/koji/userinfo?userID=1473

Does anybody know if they still want to maintain their packages
(particularly the Java packages), or how to contact them?

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: Help needed with new pcl: cloudcompare FTBFS

[Miro Hrončok]

On 14. 08. 20 15:44, Orion Poplawski wrote:

On 8/14/20 4:09 AM, Miro Hrončok wrote:

Hello Rich, Orion.

I see you've managed to build pcl that was updated to 1.11 2 months ago but 
only built recently for Fedora 33+:


https://src.fedoraproject.org/rpms/pcl/commits/master


cloudcompare now FTBFS:


...

Any idea what needs to be changed and how? Note that my C++ skills are rusty 
at least. Thanks for help.




Not really.  The latter errors flow from the first, but I have no idea why 
boost::uint8_t isn't getting defined properly anymore.


Solved elsewhere in the thread on devel, thanks. I think that some pcl header 
included the boost header in the past and no longer does.


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

Re: Help needed with new pcl: cloudcompare FTBFS

[Orion Poplawski]

On 8/14/20 4:09 AM, Miro Hrončok wrote:

Hello Rich, Orion.

I see you've managed to build pcl that was updated to 1.11 2 months ago 
but only built recently for Fedora 33+:


https://src.fedoraproject.org/rpms/pcl/commits/master


cloudcompare now FTBFS:


https://koschei.fedoraproject.org/package/cloudcompare?collection=f33


In file included from /usr/include/pcl-1.11/pcl/pcl_macros.h:77,
  from /usr/include/pcl-1.11/pcl/PCLPointCloud2.h:8,
  from 
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/filters/../utils/PCLConv.h:30, 

  from 
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/filters/MLSSmoothingUpsampling.cpp:22: 

/usr/include/pcl-1.11/pcl/pcl_config.h:7:4: error: #error PCL requires 
C++14 or above

     7 |   #error PCL requires C++14 or above
   |    ^


So I've attempted a trivial workaround:

     sed -i 's/-std=c++11/-std=c++14/' $(grep -rl -- '-std=c++11')

or

     sed -i 's/-std=c++11/-std=gnu++14/' $(grep -rl -- '-std=c++11')

However the error is now:


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


In file included from 
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:21: 

/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/my_point_types.h:34:12: 
error: 'uint8_t' in namespace 'boost' does not name a type

    34 | boost::uint8_t b;
   |    ^~~


And:


/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp: 
In member function 'pcl::PCLPointCloud2::Ptr cc2smReader::getColors() 
const':
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:275:21: 
error: 'struct OnlyRGB' has no member named 'r'

   275 |    pcl_cloud->at(i).r = static_cast(rgb[0]);
   | ^
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:276:21: 
error: 'struct OnlyRGB' has no member named 'g'

   276 |    pcl_cloud->at(i).g = static_cast(rgb[1]);
   | ^
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:277:21: 
error: 'struct OnlyRGB' has no member named 'b'

   277 |    pcl_cloud->at(i).b = static_cast(rgb[2]);
   |


Any idea what needs to be changed and how? Note that my C++ skills are 
rusty at least. Thanks for help.




Not really.  The latter errors flow from the first, but I have no idea 
why boost::uint8_t isn't getting defined properly anymore.


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



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

Fedora 33 compose report: 20200814.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-33-20200813.n.2
NEW: Fedora-33-20200814.n.0

= SUMMARY =
Added images:1
Dropped images:  2
Added packages:  6
Dropped packages:44
Upgraded packages:   171
Downgraded packages: 0

Size of added packages:  2.38 MiB
Size of dropped packages:264.55 MiB
Size of upgraded packages:   7.94 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -107.53 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Silverblue dvd-ostree x86_64
Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-33-20200814.n.0.iso

= DROPPED IMAGES =
Image: Cloud_Base vagrant-libvirt x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-33-20200813.n.2.x86_64.vagrant-libvirt.box
Image: Cloud_Base vagrant-virtualbox x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-33-20200813.n.2.x86_64.vagrant-virtualbox.box

= ADDED PACKAGES =
Package: R-RcppDate-0.0.1-1.fc33
Summary: 'date' C++ Header Library for Date and Time Functionality
RPMs:R-RcppDate R-RcppDate-devel
Size:70.60 KiB

Package: R-cpp11-0.2.1-1.fc33~bootstrap
Summary: A C++11 Interface for R's C Interface
RPMs:R-cpp11 R-cpp11-devel
Size:158.41 KiB

Package: libvma-9.0.2-1.fc33
Summary: A library for boosting TCP and UDP traffic (over RDMA hardware)
RPMs:libvma libvma-devel libvma-utils
Size:1.96 MiB

Package: rust-adler32-1.2.0-1.fc33
Summary: Minimal Adler32 implementation for Rust
RPMs:rust-adler32+default-devel rust-adler32+std-devel rust-adler32-devel
Size:29.61 KiB

Package: rust-alphanumeric-sort-1.4.0-1.fc33
Summary: Sort order for files and folders whose names contain numerals
RPMs:rust-alphanumeric-sort+default-devel rust-alphanumeric-sort+std-devel 
rust-alphanumeric-sort-devel
Size:31.64 KiB

Package: rust-hashbrown-0.8.2-1.fc33
Summary: Rust port of Google's SwissTable hash map
RPMs:rust-hashbrown+ahash-compile-time-rng-devel rust-hashbrown+ahash-devel 
rust-hashbrown+default-devel rust-hashbrown+inline-more-devel 
rust-hashbrown+raw-devel rust-hashbrown+rayon-devel rust-hashbrown+serde-devel 
rust-hashbrown-devel
Size:133.41 KiB


= DROPPED PACKAGES =
Package: anchorman-0.0.1-17.fc32
Summary: The recording-studio-in-a-box
RPMs:anchorman
Size:110.47 KiB

Package: beacon-0.5-21.fc33
Summary: WYSIWYG editor for docbook xml
RPMs:beacon
Size:185.85 KiB

Package: ember-media-0.7.2.1-12.fc33
Summary: Media files for the ember WorldForge client
RPMs:ember-media
Size:240.23 MiB

Package: foo2zjs-0.20170412-14.fc33
Summary: Linux printer driver for ZjStream protocol
RPMs:foo2ddst foo2hbpl foo2hiperc foo2hp foo2lava foo2oak foo2qpdl foo2slx 
foo2xqx foo2zjs
Size:6.97 MiB

Package: gallery3-openid-2.0-0.15.beta.fc33
Summary: OpenID support for Gallery3
RPMs:gallery3-openid
Size:69.17 KiB

Package: gdb-heap-0.5-38.20191013gitf3dcc53.fc33
Summary: Extensions to gdb for debugging dynamic memory allocation
RPMs:gdb-heap
Size:217.88 KiB

Package: gloobus-preview-0.4.1-39.fc32
Summary: A Gnome extension to enable previews for any kind of file
RPMs:gloobus-preview
Size:831.31 KiB

Package: gnome-mud-0.11.2-26.fc32
Summary: A MUD client for GNOME
RPMs:gnome-mud
Size:1.29 MiB

Package: gr-iio-0.2-11.20170705git54c86a5.fc31
Summary: GNU Radio interface for IIO
RPMs:gr-iio gr-iio-devel
Size:909.96 KiB

Package: grig-0.8.1-11.fc32
Summary: A Ham Radio Control graphical user interface
RPMs:grig
Size:728.21 KiB

Package: gspiceui-1.1.00-5.fc33
Summary: A frontend to Spice circuit similators
RPMs:gspiceui
Size:2.12 MiB

Package: gtkmathview-0.8.0-30.fc32
Summary: A MathML rendering library
RPMs:gtkmathview gtkmathview-devel
Size:4.25 MiB

Package: inception-0.4.1-17.fc33
Summary: A fireWire physical memory manipulation tool
RPMs:inception
Size:2.05 MiB

Package: iptux-0.5.1-24.fc32
Summary: A software for sharing in LAN
RPMs:iptux
Size:1.15 MiB

Package: modtools-0.0.1-14.fc33
Summary: Utilities for creating and managing modules
RPMs:modtools
Size:38.28 KiB

Package: nodejs-babel-runtime-6.23.0-8.fc33
Summary: The babel selfContained runtime
RPMs:nodejs-babel-runtime
Size:51.15 KiB

Package: nodejs-benchmark-2.0.0-9.fc32
Summary: A JavaScript benchmarking library
RPMs:nodejs-benchmark
Size:44.06 KiB

Package: nodejs-call-delayed-1.0.0-7.fc32
Summary: Like setTimeout, but with arguments reversed
RPMs:nodejs-call-delayed
Size:10.45 KiB

Package: nodejs-conventional-changelog-writer-3.0.9-5.fc32
Summary: Write logs based on conventional commits and templates
RPMs:nodejs-conventional-changelog-writer
Size:19.71 KiB

Package: nodejs-conventional-commits-parser-2.1.7-7.fc33
Summary: Parse raw conventional commits
RPMs:nodejs-conventional-commits-parser
Size:21.88 KiB

Package: nodejs-ebnf-parser-0.1.10-10.fc33
Summary: A parser for BNF and EBNF grammars used

Re: EXTERNAL: Re: hundred percent cpu load

[Wells, Roger K. via devel]

On 8/14/20 8:45 AM, Przemek Klosowski via devel wrote:
On 8/14/20 8:33 AM, Wells, Roger K. via devel wrote:

That was not the cause.
Now when it happens I have only three tasks running at 100% (same ones
as reported earlier).
Everything else, kerneloops, shutdown via power switch, etc, is as before.


Could you repost to the list with more info? I think you're saying that after 
removing sadc you still are 100% CPU with

kworker/6:1+events_freezable
dmesg
systemd-journal

That is correct.  The "6:1" in the kworker case varies.



running full tilt. THis probably means that it's the kernel worker threads are 
doing something that causes lots of errors, and all the other processes 
(including sadc that is now gone) are just busy writing those errors.

So, what is kernel doing? what does your system log say? type 'dmesg' or 
'journalctl -e' and look at the end of the data.

The following repeats at the end of journalctl:
In the last second of the journal there are 14688 individual entries.

Aug 13 18:23:51 rwells-x280 kernel: Hardware name: LENOVO 
20KFCTO1WW/20KFCTO1WW, BIOS N20ET55W (1.40 ) 06/01/2020
Aug 13 18:23:51 rwells-x280 kernel: Workqueue: events_freezable 
ieee80211_restart_work [mac80211]
Aug 13 18:23:51 rwells-x280 kernel: RIP: 0010:drv_sta_state+0x26e/0x3e0 
[mac80211]
Aug 13 18:23:51 rwells-x280 kernel: Code: 0b 45 31 ed e9 44 fe ff ff 48 8b 83 
78 04 00 00 48 8d b3 98 04 00 00 48 c7 c7 80 46 f2 c0 48 85 c0 48 0f 45 f0 e8 
c9 bf 23 d2 <0f> 0b 41 bd fb ff ff ff e9 1b fe ff ff 65 8b 05 be fc 16 3f 89 c0
Aug 13 18:23:51 rwells-x280 systemd-journald[928]: Missed 44 kernel messages
Aug 13 18:23:51 rwells-x280 kernel:  iTCO_wdt mac80211 iTCO_vendor_support 
snd_hda_intel irqbypass intel_rapl_msr snd_intel_dspcfg rapl snd_hda_codec 
libarc4 snd_hda_core uvcvideo intel_cstate iwlwifi snd_hwdep btusb 
videobuf2_vmalloc snd_seq intel_uncore videobuf2_memops btrtl videobuf2_v4l2 
btbcm snd_seq_device btintel snd_pcm pcspkr cfg80211 mei_me wmi_bmof 
intel_wmi_thunderbolt videobuf2_common i2c_i801 snd_timer thunderbolt videodev 
bluetooth mei intel_pch_thermal mc thinkpad_acpi ucsi_acpi joydev typec_ucsi 
processor_thermal_device ecdh_generic intel_rapl_common ledtrig_audio ecc 
intel_xhci_usb_role_switch roles intel_soc_dts_iosf typec snd soundcore rfkill 
int3403_thermal int340x_thermal_zone int3400_thermal acpi_thermal_rel acpi_pad 
ip_tables dm_crypt i915 i2c_algo_bit cec crct10dif_pclmul crc32_pclmul 
crc32c_intel drm_kms_helper ghash_clmulni_intel nvme drm serio_raw e1000e uas 
nvme_core usb_storage wmi video hid_multitouch fuse
Aug 13 18:23:51 rwells-x280 kernel: CPU: 0 PID: 5 Comm: kworker/0:0 Tainted: G  
  W 5.7.12-200.fc32.x86_64 #1




Also, the perf toolkit might help as explained in 
https://askubuntu.com/questions/33640/kworker-what-is-it-and-why-is-it-hogging-so-much-cpu


  1.  Install perf:

sudo apt-get install linux-tools-common linux-tools-3.11.0-15-generic


(The second package must match your kernel version. You can first install just 
linux-tools-common and call perf to let it tell you which package it needs.)

  2.  Record some 10 seconds of backtraces on all your CPUs:

sudo perf record -g -a sleep 10


  3.  Analyse your recording:

sudo perf report


I'll give this a try
thanks

  1.



___
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: Help needed with new pcl: cloudcompare FTBFS

[Qiyu Yan]

> Hello Rich, Orion.
> 
> I see you've managed to build pcl that was updated to 1.11 2 months ago but 
> only 
> built recently for Fedora 33+:
> 
> https://src.fedoraproject.org/rpms/pcl/commits/master
> 
> 
> cloudcompare now FTBFS:
> 
> 
> https://koschei.fedoraproject.org/package/cloudcompare?collection=f33
> 
> 
> In file included from /usr/include/pcl-1.11/pcl/pcl_macros.h:77,
>   from /usr/include/pcl-1.11/pcl/PCLPointCloud2.h:8,
>   from 
> /builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/filters/../utils/PCLConv.h:30,
>   from 
> /builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/filters/MLSSmoothingUpsampling.cpp:22:
> /usr/include/pcl-1.11/pcl/pcl_config.h:7:4: error: #error PCL requires C++14 
> or 
> above
>  7 |   #error PCL requires C++14 or above
>|^
> 
> 
> So I've attempted a trivial workaround:
> 
>  sed -i 's/-std=c++11/-std=c++14/' $(grep -rl -- '-std=c++11')
> 
> or
> 
>  sed -i 's/-std=c++11/-std=gnu++14/' $(grep -rl -- '-std=c++11')
> 
> However the error is now:
> 
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=49241500
> 
> 
> In file included from 
> /builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:21:
> /builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/my_point_types.h:34:12:
> 
> error: 'uint8_t' in namespace 'boost' does not name a type
> 34 | boost::uint8_t b;
>|^~~
> 
> 
> And:
> 
> 
> /builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:
>  
> In member function 'pcl::PCLPointCloud2::Ptr cc2smReader::getColors() const':
> /builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:275:21:
>  
> error: 'struct OnlyRGB' has no member named 'r'
>275 |pcl_cloud->at(i).r = static_cast(rgb[0]);
>| ^
> /builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:276:21:
>  
> error: 'struct OnlyRGB' has no member named 'g'
>276 |pcl_cloud->at(i).g = static_cast(rgb[1]);
>| ^
> /builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:277:21:
>  
> error: 'struct OnlyRGB' has no member named 'b'
>277 |pcl_cloud->at(i).b = static_cast(rgb[2]);
>|
In this case, looking into the code itself is a must, check if the code 
correctly defined OnlyRGB before those lines (and with this error, seems 
upstream code didn't). I think this is due to an upstream coding issue. Try to 
find the definition and move it to a right place.
> 
> 
> Any idea what needs to be changed and how? Note that my C++ skills are rusty 
> at 
> least. Thanks for help.
___
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/14/20 8:33 AM, Wells, Roger K. via devel wrote:

That was not the cause.
Now when it happens I have only three tasks running at 100% (same ones
as reported earlier).
Everything else, kerneloops, shutdown via power switch, etc, is as before.


Could you repost to the list with more info? I think you're saying that 
after removing sadc you still are 100% CPU with


kworker/6:1+events_freezable
dmesg
systemd-journal

running full tilt. THis probably means that it's the kernel worker threads are 
doing something that causes lots of errors, and all the other processes 
(including sadc that is now gone) are just busy writing those errors.

So, what is kernel doing? what does your system log say? type 'dmesg' or 
'journalctl -e' and look at the end of the data.

Also, the perf toolkit might help as explained in 
https://askubuntu.com/questions/33640/kworker-what-is-it-and-why-is-it-hogging-so-much-cpu

1.

   Install |perf|:

   |sudo apt-get install linux-tools-common linux-tools-3.11.0-15-generic |

   (The second package must match your kernel version. You can first
   install just |linux-tools-common| and call |perf| to let it tell you
   which package it needs.)

2.

   Record some 10 seconds of backtraces on all your CPUs:

   |sudo perf record -g -a sleep 10 |

3.

   Analyse your recording:

   |sudo perf report |


___
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:44 PM, Wells, Roger K. via devel wrote:
> 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

That was not the cause. 
Now when it happens I have only three tasks running at 100% (same ones
as reported earlier).
Everything else, kerneloops, shutdown via power switch, etc, is as before.

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

[Przemek Klosowski via devel]

On 8/14/20 7:33 AM, John M. Harris Jr wrote:

On Wednesday, August 12, 2020 1:16:34 PM MST Przemek Klosowski via devel
wrote:


This is weird---your swap was 100% full, and ram almost full, and yet
killing 4GB VirtualBox didn't seem to free up memory. I suspect some
sort of measurement or reporting error---if these numbers were accurate,
EarlyOOM did have a reason to panic and kill zoom. BTW, zoom taking 721
MiB is crazy.



Are you kidding? The system still had over a quarter of a gigabyte of free
RAM. There's no reason to start killing off processes at that point. That's
tons of free memory. To put that into perspective, that's enough free memory
to store over 1000 average-length novels directly in memory.


When the swap is 100% full, it is not like you have a bunch of processes 
neatly stored in it, and some free memory available---you have a mess of 
partly swapped out processes reading back their pages from swap and 
pushing other processes' RAM pages onto the fragmented swap, when they 
are trying to run.


This is the worst case of disk usage, and as we discussed before, the 
transfer speeds for such traffic will be hundreds/thousands times 
slower---I would expect latencies going into tens of seconds. So, no, I 
am not kidding.

___
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: Debug doxygen generated files with different names in noarch package

[Rich Mattes]

On Fri, Aug 14, 2020, 7:37 AM Richard Shaw  wrote:

> I tried to get the subject as concise as possible :)
>
> I'm getting consistent differences across at least two versions of zipios
> and the offending arches seem to always be s390x and ppc64le.
>
> BuildError: The following noarch package built differently on different
> architectures: zipios-doc-2.2.1.0-5.fc33.noarch.rpm
> rpmdiff output was:
> removed
> /usr/share/doc/zipios/html/dir_0f7abfb91da657dcb27dff31b827312f.html
> removed
> /usr/share/doc/zipios/html/dir_32504400af4b8c553a85c61a7ef01dea.html
> added
> /usr/share/doc/zipios/html/dir_8f6b9ad7431774f92e3ec3efe35ac7da.html
> added
> /usr/share/doc/zipios/html/dir_dd208edd458824e9eaf902c6da16200d.html
>
> zipios 2.2.5.0
> https://koji.fedoraproject.org/koji/taskinfo?taskID=49057750
>
> zipios 2.2.1.0
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48597282
>
> Is this likely a big vs little endian thing?
>
> Thanks,
> Richard
>

Is it a CMake package? The vpath_builddir that is now used for out of
source builds is different for each architecture. If that directory is
included in the doxygen processing paths you'll get this error.

I worked around this in a few of my packages by adding the cmake build
directory to the EXCLUDE list in the doxyfile.

Rich

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

[Improvement Proposal] listing of keyboard layouts in anaconda

[Sundeep Anand]

Hi,

Please refer: https://bugzilla.redhat.com/show_bug.cgi?id=1158370 (list major 
common keyboard layouts first)

An attempt could be made to determine major keyboard layouts from langtable[1] 
and place them up in the order[2]. 
Which may help users find them with a lesser scroll.

thoughts?

thanks,
sundeep

[1] https://github.com/mike-fabian/langtable/pull/11
[2] https://github.com/rhinstaller/anaconda/pull/2788
___
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: Help needed with new pcl: cloudcompare FTBFS

[Miro Hrončok]

On 14. 08. 20 12:39, Qiyu Yan wrote:

Miro Hrončok  于2020年8月14日周五 下午6:09写道：


Hello Rich, Orion.

I see you've managed to build pcl that was updated to 1.11 2 months ago but only
built recently for Fedora 33+:

https://src.fedoraproject.org/rpms/pcl/commits/master


cloudcompare now FTBFS:


https://koschei.fedoraproject.org/package/cloudcompare?collection=f33


In file included from /usr/include/pcl-1.11/pcl/pcl_macros.h:77,
   from /usr/include/pcl-1.11/pcl/PCLPointCloud2.h:8,
   from
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/filters/../utils/PCLConv.h:30,
   from
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/filters/MLSSmoothingUpsampling.cpp:22:
/usr/include/pcl-1.11/pcl/pcl_config.h:7:4: error: #error PCL requires C++14 or
above
  7 |   #error PCL requires C++14 or above
|^


So I've attempted a trivial workaround:

  sed -i 's/-std=c++11/-std=c++14/' $(grep -rl -- '-std=c++11')

or

  sed -i 's/-std=c++11/-std=gnu++14/' $(grep -rl -- '-std=c++11')

However the error is now:


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


In file included from
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:21:
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/my_point_types.h:34:12:
error: 'uint8_t' in namespace 'boost' does not name a type
 34 | boost::uint8_t b;
|^~~

boost::uint8_t is defined in /usr/include/boost/cstdint.hpp, could you
check if the source file have includes boost/stdint.hpp


Thank You! Adding #include  works.


And:


/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:
In member function 'pcl::PCLPointCloud2::Ptr cc2smReader::getColors() const':
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:275:21:
error: 'struct OnlyRGB' has no member named 'r'
275 |pcl_cloud->at(i).r = static_cast(rgb[0]);
| ^
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:276:21:
error: 'struct OnlyRGB' has no member named 'g'
276 |pcl_cloud->at(i).g = static_cast(rgb[1]);
| ^
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:277:21:
error: 'struct OnlyRGB' has no member named 'b'
277 |pcl_cloud->at(i).b = static_cast(rgb[2]);
|

Don't know why, get error above fixed and see if this remains?

It indeed doesn't.

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

Re: EarlyOOM +ZRAM Only

[Neal Gompa]

On Fri, Aug 14, 2020 at 7:34 AM John M. Harris Jr  wrote:
>
> On Wednesday, August 12, 2020 1:16:34 PM MST Przemek Klosowski via devel
> wrote:
> > On 8/12/20 2:27 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 :(
> >
> >
> > This is weird---your swap was 100% full, and ram almost full, and yet
> > killing 4GB VirtualBox didn't seem to free up memory. I suspect some
> > sort of measurement or reporting error---if these numbers were accurate,
> > EarlyOOM did have a reason to panic and kill zoom. BTW, zoom taking 721
> > MiB is crazy.
> >
> > One possibility that comes to mind is that there's a process not
> > mentioned in the log (some system process???) that keeps allocating
> > memory as soon as it is freed by EarlyOOM, so killing the processes does
> > not result in increasing free memory (the first column).
> >
> > 399 of 15887 MiB ( 2.51%) SIGTERM "Web Content": badness 315, VmRSS 313 MiB
> > 397 of 15887 MiB ( 2.50%) SIGTERM "Web Content": badness 304, VmRSS 80 MiB
> > 379 of 15887 MiB ( 2.39%) SIGTERM "Web Content": badness 303, VmRSS 74 MiB
> > 335 of 15887 MiB ( 2.11%) SIGTERM "Web Content": badness 303, VmRSS 70 MiB
> > 315 of 15887 MiB ( 1.98%) SIGTERM "Web Content": badness 301, VmRSS 27 MiB
> > 288 of 15887 MiB ( 1.81%) SIGTERM "VirtualBoxVM":badness 212, VmRSS 4244
> > MiB 337 of 15887 MiB ( 2.13%) SIGTERM "zoom":badness 36, VmRSS 721
> > MiB
> > Note how the full log helpfully mentions the actual tresholds for
> > SIGTERM: mem 2.52%, swap 10%, Where does 2.52 come from, pray?
>
> Are you kidding? The system still had over a quarter of a gigabyte of free
> RAM. There's no reason to start killing off processes at that point. That's
> tons of free memory. To put that into perspective, that's enough free memory
> to store over 1000 average-length novels directly in memory.
>

It's also enough to store 1/8th of a significantly complex Electron
process. It's *not enough*. Text is a terrible comparison when we're
working with programs.



-- 
真実はいつも一つ！/ 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

Debug doxygen generated files with different names in noarch package

[Richard Shaw]

I tried to get the subject as concise as possible :)

I'm getting consistent differences across at least two versions of zipios
and the offending arches seem to always be s390x and ppc64le.

BuildError: The following noarch package built differently on different
architectures: zipios-doc-2.2.1.0-5.fc33.noarch.rpm
rpmdiff output was:
removed
/usr/share/doc/zipios/html/dir_0f7abfb91da657dcb27dff31b827312f.html
removed
/usr/share/doc/zipios/html/dir_32504400af4b8c553a85c61a7ef01dea.html
added
/usr/share/doc/zipios/html/dir_8f6b9ad7431774f92e3ec3efe35ac7da.html
added
/usr/share/doc/zipios/html/dir_dd208edd458824e9eaf902c6da16200d.html

zipios 2.2.5.0
https://koji.fedoraproject.org/koji/taskinfo?taskID=49057750

zipios 2.2.1.0
https://koji.fedoraproject.org/koji/taskinfo?taskID=48597282

Is this likely a big vs little endian thing?

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

[John M. Harris Jr]

On Wednesday, August 12, 2020 1:16:34 PM MST Przemek Klosowski via devel 
wrote:
> On 8/12/20 2:27 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 :(
> 
> 
> This is weird---your swap was 100% full, and ram almost full, and yet 
> killing 4GB VirtualBox didn't seem to free up memory. I suspect some 
> sort of measurement or reporting error---if these numbers were accurate, 
> EarlyOOM did have a reason to panic and kill zoom. BTW, zoom taking 721 
> MiB is crazy.
> 
> One possibility that comes to mind is that there's a process not 
> mentioned in the log (some system process???) that keeps allocating 
> memory as soon as it is freed by EarlyOOM, so killing the processes does 
> not result in increasing free memory (the first column).
> 
> 399 of 15887 MiB ( 2.51%) SIGTERM "Web Content": badness 315, VmRSS 313 MiB
> 397 of 15887 MiB ( 2.50%) SIGTERM "Web Content": badness 304, VmRSS 80 MiB
> 379 of 15887 MiB ( 2.39%) SIGTERM "Web Content": badness 303, VmRSS 74 MiB
> 335 of 15887 MiB ( 2.11%) SIGTERM "Web Content": badness 303, VmRSS 70 MiB
> 315 of 15887 MiB ( 1.98%) SIGTERM "Web Content": badness 301, VmRSS 27 MiB
> 288 of 15887 MiB ( 1.81%) SIGTERM "VirtualBoxVM":badness 212, VmRSS 4244
> MiB 337 of 15887 MiB ( 2.13%) SIGTERM "zoom":badness 36, VmRSS 721
> MiB 
> Note how the full log helpfully mentions the actual tresholds for 
> SIGTERM: mem 2.52%, swap 10%, Where does 2.52 come from, pray?

Are you kidding? The system still had over a quarter of a gigabyte of free 
RAM. There's no reason to start killing off processes at that point. That's 
tons of free memory. To put that into perspective, that's enough free memory 
to store over 1000 average-length novels directly in memory.

-- 
John M. Harris, Jr.

___
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: Help needed with new pcl: cloudcompare FTBFS

[Qiyu Yan]

Miro Hrončok  于2020年8月14日周五 下午6:09写道：
>
> Hello Rich, Orion.
>
> I see you've managed to build pcl that was updated to 1.11 2 months ago but 
> only
> built recently for Fedora 33+:
>
> https://src.fedoraproject.org/rpms/pcl/commits/master
>
>
> cloudcompare now FTBFS:
>
>
> https://koschei.fedoraproject.org/package/cloudcompare?collection=f33
>
>
> In file included from /usr/include/pcl-1.11/pcl/pcl_macros.h:77,
>   from /usr/include/pcl-1.11/pcl/PCLPointCloud2.h:8,
>   from
> /builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/filters/../utils/PCLConv.h:30,
>   from
> /builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/filters/MLSSmoothingUpsampling.cpp:22:
> /usr/include/pcl-1.11/pcl/pcl_config.h:7:4: error: #error PCL requires C++14 
> or
> above
>  7 |   #error PCL requires C++14 or above
>|^
>
>
> So I've attempted a trivial workaround:
>
>  sed -i 's/-std=c++11/-std=c++14/' $(grep -rl -- '-std=c++11')
>
> or
>
>  sed -i 's/-std=c++11/-std=gnu++14/' $(grep -rl -- '-std=c++11')
>
> However the error is now:
>
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=49241500
>
>
> In file included from
> /builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:21:
> /builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/my_point_types.h:34:12:
> error: 'uint8_t' in namespace 'boost' does not name a type
> 34 | boost::uint8_t b;
>|^~~
boost::uint8_t is defined in /usr/include/boost/cstdint.hpp, could you
check if the source file have includes boost/stdint.hpp
>
> And:
>
>
> /builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:
> In member function 'pcl::PCLPointCloud2::Ptr cc2smReader::getColors() const':
> /builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:275:21:
> error: 'struct OnlyRGB' has no member named 'r'
>275 |pcl_cloud->at(i).r = static_cast(rgb[0]);
>| ^
> /builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:276:21:
> error: 'struct OnlyRGB' has no member named 'g'
>276 |pcl_cloud->at(i).g = static_cast(rgb[1]);
>| ^
> /builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:277:21:
> error: 'struct OnlyRGB' has no member named 'b'
>277 |pcl_cloud->at(i).b = static_cast(rgb[2]);
>|
Don't know why, get error above fixed and see if this remains?
>
>
> Any idea what needs to be changed and how? Note that my C++ skills are rusty 
> at
> least. Thanks for help.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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

Help needed with new pcl: cloudcompare FTBFS

[Miro Hrončok]

Hello Rich, Orion.

I see you've managed to build pcl that was updated to 1.11 2 months ago but only 
built recently for Fedora 33+:


https://src.fedoraproject.org/rpms/pcl/commits/master


cloudcompare now FTBFS:


https://koschei.fedoraproject.org/package/cloudcompare?collection=f33


In file included from /usr/include/pcl-1.11/pcl/pcl_macros.h:77,
 from /usr/include/pcl-1.11/pcl/PCLPointCloud2.h:8,
 from 
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/filters/../utils/PCLConv.h:30,
 from 
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/filters/MLSSmoothingUpsampling.cpp:22:
/usr/include/pcl-1.11/pcl/pcl_config.h:7:4: error: #error PCL requires C++14 or 
above

7 |   #error PCL requires C++14 or above
  |^


So I've attempted a trivial workaround:

sed -i 's/-std=c++11/-std=c++14/' $(grep -rl -- '-std=c++11')

or

sed -i 's/-std=c++11/-std=gnu++14/' $(grep -rl -- '-std=c++11')

However the error is now:


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


In file included from 
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:21:
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/my_point_types.h:34:12: 
error: 'uint8_t' in namespace 'boost' does not name a type

   34 | boost::uint8_t b;
  |^~~


And:


/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp: 
In member function 'pcl::PCLPointCloud2::Ptr cc2smReader::getColors() const':
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:275:21: 
error: 'struct OnlyRGB' has no member named 'r'

  275 |pcl_cloud->at(i).r = static_cast(rgb[0]);
  | ^
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:276:21: 
error: 'struct OnlyRGB' has no member named 'g'

  276 |pcl_cloud->at(i).g = static_cast(rgb[1]);
  | ^
/builddir/build/BUILD/CloudCompare-2.9.1/plugins/qPCL/PclUtils/utils/cc2sm.cpp:277:21: 
error: 'struct OnlyRGB' has no member named 'b'

  277 |pcl_cloud->at(i).b = static_cast(rgb[2]);
  |


Any idea what needs to be changed and how? Note that my C++ skills are rusty at 
least. Thanks for help.


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

Bringing fcitx5 to Fedora, and Review Swap

[Qiyu Yan]

Hello all,

I am going to bring fcitx5 to fedora, fcitx5 is the next generation
for fcitx and upstream decided to treat fcitx and fcitx5 as a
different project (different git repo, different file paths and names
and configuration files). So, like most other distro do, I think we
are going to treat fcitx5 as a different package.

So I opened several review requests at Bugzilla, overall there are 11
packages and you can see a block tree here:
https://bugzilla.redhat.com/buglist.cgi?bug_id=1868845_id_type=andblocked=tvp_id=11288407_dir=blocked

The review process should be:
Stage1: https://bugzilla.redhat.com/show_bug.cgi?id=1868845
Stage2: https://bugzilla.redhat.com/show_bug.cgi?id=1868846
Stage3: https://bugzilla.redhat.com/show_bug.cgi?id=1868847
  https://bugzilla.redhat.com/show_bug.cgi?id=1868848
  https://bugzilla.redhat.com/show_bug.cgi?id=1868849
  https://bugzilla.redhat.com/show_bug.cgi?id=1868851
  https://bugzilla.redhat.com/show_bug.cgi?id=1868854
  https://bugzilla.redhat.com/show_bug.cgi?id=1868861
Stage4: https://bugzilla.redhat.com/show_bug.cgi?id=1868853
  https://bugzilla.redhat.com/show_bug.cgi?id=1868857
  https://bugzilla.redhat.com/show_bug.cgi?id=1868850

And a copr for the whole thing can be found
https://copr.fedorainfracloud.org/coprs/yanqiyu/fcitx5 , this may help
when you are looking for built packages.

This is a lot work, take it freely, and I can do reviews in exchange.



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

Pinta failed to build on f33/armv7hl

[Andrea Musuruane]

Hi guys,
   I tried to update pinta to the latest upstream version. It built fine
except than on f33/armv7hl:

https://kojipkgs.fedoraproject.org//work/tasks/1530/49241530/build.log

I have no idea why. Can someone please help?

Thanks!

Andrea
___
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?

[Vitaly Zaitsev via devel]

On 13.08.2020 15:08, Pavel Raiskup wrote:
> "Release: 1%{?dist}%{?buildtag}"

I have a better solution - automatically bump Release on every official
build. Additional tags are not good.

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

+1 for this. Most of changelogs contains just "Updated to version X" and
can be safely removed.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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: What is the real value of Release and %changelog metadata?

[Till Maas]

On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:

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

With this we will loose the ability to map RPM version information to a
SPEC file without querying Koji for the dist-git commit. Currently,
looking at dist-git allows to quickly check if there is a release there
than on a system. Not sure how useful it is but sometimes when I looked
into FTBFS bugs it was helpful to see that the last build did not match
dist-git which indicated that the SRPM creation failed in koji. Then it
looks like the package was never tried to be built. With those changes
it seems that dist-git will look untouched after a mass-rebuild.

Also, what about other special cases when using 0.1 for the release to
indicate pre-releases or git IDs for snapshots. How would  that look
like with your proposal?

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

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

[Clement Verna]

On Fri, 14 Aug 2020 at 01:08, Adam Williamson 
wrote:

> 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 am away from home this weekend so can't do much but I ll try to
investigate what is happening. I ll be using the following ticket to post
updates

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


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