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

[Andrew Toskin]

I contributed an AppStream .metainfo.xml file to the upstream developers.

  
https://github.com/bleachbit/bleachbit/blob/master/org.bleachbit.BleachBit.metainfo.xml

Which seems to pass validation during builds based on my RPM spec.

  https://src.fedoraproject.org/rpms/bleachbit/blob/master/f/bleachbit.spec

The upstream metainfo file is included in the resulting package, which is 
installed on my f32 x86_64 workstation.

  ↪ rpm --query --list bleachbit | grep 'meta'
  /usr/share/metainfo/org.bleachbit.BleachBit.metainfo.xml

And the bleachbit package is now stable in Bodhi for f31 through f33 and EPEL8.

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

However, even after installing BleachBit, killing and restarting GNOME 
Software, and/or rebooting my computer, searching for "bleachbit" in GNOME 
Software returns no results. Curiously, I do see BleachBit listed under the 
Installed tab in Software, although even there it's still missing the app icon.

Am I missing something? I'd thought the .metainfo.xml file was all that was 
needed for GUI apps to appear in our "app store".

~ Andrew / FAS: terrycloth
___
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: User builds can't be viewed in bodhi

[Chihurumnaya Ibiam]

Just tried and I can access it now, thanks.

-- 

Ibiam Chihurumnaya
ibiamchihurumn...@gmail.com



On Thu, Aug 13, 2020 at 1:37 AM Kevin Fenzi  wrote:

> On Thu, Aug 13, 2020 at 01:16:59AM +0100, Chihurumnaya Ibiam wrote:
> > Hi,
> >
> > While trying to access a user's builds in bodhi I kept getting this error
> > .
>
> Can you try again now?
>
> There was/is just finishing up a planned outage:
> https://pagure.io/fedora-infrastructure/issue/9202
>
> You may have tried when a database server was rebooting or the like.
>
> If you still see it, please file a infrastructure ticket.
> ( https://pagure.io/fedora-infrastructure/issue/new )
>
> kevin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: User builds can't be viewed in bodhi

[Kevin Fenzi]

On Thu, Aug 13, 2020 at 01:16:59AM +0100, Chihurumnaya Ibiam wrote:
> Hi,
> 
> While trying to access a user's builds in bodhi I kept getting this error
> .

Can you try again now?

There was/is just finishing up a planned outage: 
https://pagure.io/fedora-infrastructure/issue/9202

You may have tried when a database server was rebooting or the like. 

If you still see it, please file a infrastructure ticket. 
( https://pagure.io/fedora-infrastructure/issue/new )

kevin


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

Re: EarlyOOM +ZRAM Only

[John M. Harris Jr]

On Wednesday, August 12, 2020 3:43:24 PM MST Samuel Sieb wrote:
> On 8/12/20 12:06 PM, John M. Harris Jr wrote:
> 
> > On Wednesday, August 12, 2020 11:27:37 AM MST Sergio Belkin wrote:
> > 
> >> mem avail:   337 of 15887 MiB ( 2.13%), swap free:0 of 4095 MiB (
> >> 0.00%)
> > > low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> >> sending SIGTERM to process 1898342 uid 1000 "zoom": badness 36, VmRSS
> >> 721
> >> MiB
> >> process exited after 0.0 seconds
> >>
> >>
> >>
> >>
> >> So I wonder if is advisable using EarlyOOM + ZRAM Only, what do you
> >> think?
> >> Thanks in advance!
> > 
> > 
> > Please keep this in mind going forward, and take a moment to consider
> > enabling EarlyOOM in Fedora. As it turns out, EarlyOOM does exactly what
> > it says it does: It kills your programs when you've still got plenty of
> > free memory.
> 
> Where do you see any evidence of "plenty of free memory".  There was 
> nothing left.  Maybe there is a bug in the reporting, but it definitely 
> wasn't doing what you say it was.

There was over 300 MiB of memory available. That's more than a quarter of a 
gigabyte. That's a ton of RAM. There was no *swap* left.

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

User builds can't be viewed in bodhi

[Chihurumnaya Ibiam]

Hi,

While trying to access a user's builds in bodhi I kept getting this error
.

-- 

Ibiam Chihurumnaya
ibiamchihurumn...@gmail.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

[Michael Catanzaro]

On Wed, Aug 12, 2020 at 5:43 pm, Michael Catanzaro 
 wrote:

 but it might instead get confused


I meant to write: it might *then* get confused. That is, it should 
always start by killing the right process, but it might then continue 
to kill more unnecessarily.


___
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

[Michael Catanzaro]

earlyoom actually works best with only zram. If you have a disk-based 
swap partition, your system is likely to become frozen and unusable 
before earlyoom gets a chance to save you.


On Wed, Aug 12, 2020 at 4:16 pm, 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.


I've seen this before actually. I think it's just a bug. Maybe earlyoom 
doesn't allow enough time after killing to see how the kill affects 
system memory use. It should always kill the real memory hog first, but 
it might instead get confused and start killing a bunch of other 
unproblematic processes before it realizes that system memory use is 
back under control.


___
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

[Samuel Sieb]

On 8/12/20 12:06 PM, John M. Harris Jr wrote:

On Wednesday, August 12, 2020 11:27:37 AM MST Sergio Belkin wrote:

mem avail:   337 of 15887 MiB ( 2.13%), swap free:0 of 4095 MiB ( 0.00%)
low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
sending SIGTERM to process 1898342 uid 1000 "zoom": badness 36, VmRSS 721
MiB
process exited after 0.0 seconds


So I wonder if is advisable using EarlyOOM + ZRAM Only, what do you
think?
Thanks in advance!


Please keep this in mind going forward, and take a moment to consider enabling
EarlyOOM in Fedora. As it turns out, EarlyOOM does exactly what it says it
does: It kills your programs when you've still got plenty of free memory.


Where do you see any evidence of "plenty of free memory".  There was 
nothing left.  Maybe there is a bug in the reporting, but it definitely 
wasn't doing what you say it was.

___
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 mié., 12 ago. 2020 a las 17:17, Przemek Klosowski via devel (<
devel@lists.fedoraproject.org>) escribió:

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

The only that I've found in logs is the infamous akonadi :)  and
sysstat-collect... earlyoom
More information:

systemctl status --no-pager --full earlyoom.service
● earlyoom.service - Early OOM Daemon
 Loaded: loaded (/usr/lib/systemd/system/earlyoom.service; enabled;
vendor preset: disabled)
 Active: active (running) since Thu 2020-07-30 15:36:11 -03; 1 weeks 6
days ago
   Docs: man:earlyoom(1)
 https://github.com/rfjakob/earlyoom
   Main PID: 888 (earlyoom)
  Tasks: 1 (limit: 10)
 Memory: 1.8M (max: 50.0M)
CPU: 1min 48.708s
 CGroup: /system.slice/earlyoom.service
 └─888 /usr/bin/earlyoom -r 0 -m 4 -M 409600 --prefer ^Web
Content$ --avoid
^(dnf|packagekitd|gnome-shell|gnome-session-c|gnome-session-b|lightdm|sddm|sddm-helper|gdm|gdm-wayland-ses|gdm-session-wor|gdm-x-session|Xorg|Xwayland|systemd|systemd-logind|dbus-daemon|dbus-broker|cinnamon|cinnamon-sessio|kwin_x11|kwin_wayland|plasmashell|ksmserver|plasma_session|startplasma-way|xfce4-session|mate-session|marco|lxqt-session|openbox)$

ago 12 10:20:14 dublin.ireland.home earlyoom[888]: sending SIGTERM to
process 1899907 uid 1000 "Web Content": badness 301, VmRSS 27 MiB
ago 12 10:20:24 dublin.ireland.home earlyoom[888]: kill failed: Timer
expired
ago 12 10:20:24 dublin.ireland.home earlyoom[888]: mem avail:   288 of
15887 MiB ( 1.81%), swap free:0 of 4095 MiB ( 0.00%)
ago 12 10:20:24 dublin.ireland.home earlyoom[888]: low memory! at or below
SIGTERM limits: mem  2.52%, swap 10.00%
ago 12 10:20:24 dublin.ireland.home earlyoom[888]: sending SIGTERM to
process 1898928 uid 1000 "VirtualBoxVM": badness 212, VmRSS 4244 MiB
ago 12 10:20:24 dublin.ireland.home earlyoom[888]: process exited after 0.0
seconds
ago 12 10:20:24 dublin.ireland.home earlyoom[888]: mem avail:   337 of
15887 MiB ( 2.13%), swap free:0 of 4095 MiB ( 0.00%)
ago 12 10:20:24 dublin.ireland.home earlyoom[888]: low memory! at or below
SIGTERM limits: mem  2.52%, swap 10.00%
ago 12 10:20:24 dublin.ireland.home earlyoom[888]: sending SIGTERM to
process 1898342 uid 1000 "zoom": badness 36, VmRSS 721 MiB
ago 12 10:20:24 dublin.ireland.home earlyoom[888]: process exited after 0.0
seconds

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

Re: EarlyOOM +ZRAM Only

[Sergio Belkin]

El mié., 12 ago. 2020 a las 16:07, John M. Harris Jr ()
escribió:

> On Wednesday, August 12, 2020 11:27:37 AM MST 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 the log:
> > mem avail:   399 of 15887 MiB ( 2.51%), swap free:0 of 4095 MiB (
> 0.00%)
> > low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> > sending SIGTERM to process 1899361 uid 1000 "Web Content": badness 315,
> > VmRSS 313 MiB
> > process exited after 2.2 seconds
> > mem avail:   397 of 15887 MiB ( 2.50%), swap free:0 of 4095 MiB (
> 0.00%)
> > low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> > sending SIGTERM to process 1899726 uid 1000 "Web Content": badness 304,
> > VmRSS 80 MiB
> > process exited after 3.7 seconds
> > mem avail:   379 of 15887 MiB ( 2.39%), swap free:0 of 4095 MiB (
> 0.00%)
> > low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> > sending SIGTERM to process 1896099 uid 1000 "Web Content": badness 303,
> > VmRSS 74 MiB
> > process exited after 3.6 seconds
> > mem avail:   335 of 15887 MiB ( 2.11%), swap free:0 of 4095 MiB (
> 0.00%)
> > low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> > sending SIGTERM to process 1899195 uid 1000 "Web Content": badness 303,
> > VmRSS 70 MiB
> > process exited after 3.6 seconds
> > mem avail:   315 of 15887 MiB ( 1.98%), swap free:0 of 4095 MiB (
> 0.00%)
> > low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> > sending SIGTERM to process 1899907 uid 1000 "Web Content": badness 301,
> > VmRSS 27 MiB
> > kill failed: Timer expired
> > mem avail:   288 of 15887 MiB ( 1.81%), swap free:0 of 4095 MiB (
> 0.00%)
> > low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> > sending SIGTERM to process 1898928 uid 1000 "VirtualBoxVM": badness 212,
> > VmRSS 4244 MiB
> > process exited after 0.0 seconds
> > mem avail:   337 of 15887 MiB ( 2.13%), swap free:0 of 4095 MiB (
> 0.00%)
> > low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> > sending SIGTERM to process 1898342 uid 1000 "zoom": badness 36, VmRSS 721
> > MiB
> > process exited after 0.0 seconds
> >
> >
> > So I wonder if is advisable using EarlyOOM + ZRAM Only, what do you
> > think?
> > Thanks in advance!
>
> Please keep this in mind going forward, and take a moment to consider
> enabling
> EarlyOOM in Fedora. As it turns out, EarlyOOM does exactly what it says it
> does: It kills your programs when you've still got plenty of free memory.
>
> --
> John M. Harris, Jr.
>
> ___
>

The OS is Fedora 32... Debian is the guest OS running on VirtualBox

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

Re: EarlyOOM +ZRAM Only

[Sergio Belkin]

El mié., 12 ago. 2020 a las 15:49, Samuel Sieb () escribió:

> On 8/12/20 11:27 AM, Sergio Belkin wrote:
> > 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 the log:
>
> The log of what?  Are there no timestamps?
>
> > mem avail:   399 of 15887 MiB ( 2.51%), swap free:0 of 4095 MiB (
> 0.00%)
> > low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> > sending SIGTERM to process 1899361 uid 1000 "Web Content": badness 315,
> > VmRSS 313 MiB
> > process exited after 2.2 seconds
> > mem avail:   397 of 15887 MiB ( 2.50%), swap free:0 of 4095 MiB (
> 0.00%)
> > low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> > sending SIGTERM to process 1899726 uid 1000 "Web Content": badness 304,
> > VmRSS 80 MiB
> > process exited after 3.7 seconds
> > mem avail:   379 of 15887 MiB ( 2.39%), swap free:0 of 4095 MiB (
> 0.00%)
> > low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> > sending SIGTERM to process 1896099 uid 1000 "Web Content": badness 303,
> > VmRSS 74 MiB
> > process exited after 3.6 seconds
> > mem avail:   335 of 15887 MiB ( 2.11%), swap free:0 of 4095 MiB (
> 0.00%)
> > low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> > sending SIGTERM to process 1899195 uid 1000 "Web Content": badness 303,
> > VmRSS 70 MiB
> > process exited after 3.6 seconds
> > mem avail:   315 of 15887 MiB ( 1.98%), swap free:0 of 4095 MiB (
> 0.00%)
> > low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> > sending SIGTERM to process 1899907 uid 1000 "Web Content": badness 301,
> > VmRSS 27 MiB
> > kill failed: Timer expired
> > mem avail:   288 of 15887 MiB ( 1.81%), swap free:0 of 4095 MiB (
> 0.00%)
> > low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> > sending SIGTERM to process 1898928 uid 1000 "VirtualBoxVM": badness 212,
> > VmRSS 4244 MiB
> > process exited after 0.0 seconds
> > mem avail:   337 of 15887 MiB ( 2.13%), swap free:0 of 4095 MiB (
> 0.00%)
> > low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> > sending SIGTERM to process 1898342 uid 1000 "zoom": badness 36, VmRSS
> > 721 MiB
> > process exited after 0.0 seconds
>
> According to this, you were completely out of memory.  zoom was the last
> resort.  I wonder what was taking up the memory that even killing the VM
> didn't free up enough.
> ___
> 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
>

It's the output of journalctl:
ago 12 10:01:01 dublin.ireland.home earlyoom[888]: mem avail:   399 of
15887 MiB ( 2.51%), swap free:0 of 4095 MiB ( 0.00%)
ago 12 10:01:01 dublin.ireland.home earlyoom[888]: low memory! at or below
SIGTERM limits: mem  2.52%, swap 10.00%
ago 12 10:01:01 dublin.ireland.home earlyoom[888]: sending SIGTERM to
process 1899361 uid 1000 "Web Content": badness 315, VmRSS 313 MiB
ago 12 10:01:03 dublin.ireland.home earlyoom[888]: process exited after 2.2
seconds
ago 12 10:20:03 dublin.ireland.home earlyoom[888]: mem avail:   397 of
15887 MiB ( 2.50%), swap free:0 of 4095 MiB ( 0.00%)
ago 12 10:20:03 dublin.ireland.home earlyoom[888]: low memory! at or below
SIGTERM limits: mem  2.52%, swap 10.00%
ago 12 10:20:03 dublin.ireland.home earlyoom[888]: sending SIGTERM to
process 1899726 uid 1000 "Web Content": badness 304, VmRSS 80 MiB
ago 12 10:20:07 dublin.ireland.home earlyoom[888]: process exited after 3.7
seconds
ago 12 10:20:07 dublin.ireland.home earlyoom[888]: mem avail:   379 of
15887 MiB ( 2.39%), swap free:0 of 4095 MiB ( 0.00%)
ago 12 10:20:07 dublin.ireland.home earlyoom[888]: low memory! at or below
SIGTERM limits: mem  2.52%, swap 10.00%
ago 12 10:20:07 dublin.ireland.home earlyoom[888]: sending SIGTERM to
process 1896099 uid 1000 "Web Content": badness 303, VmRSS 74 MiB
ago 12 10:20:10 dublin.ireland.home earlyoom[888]: process exited after 3.6
seconds
ago 12 10:20:10 dublin.ireland.home earlyoom[888]: mem avail:   335 of
15887 MiB ( 2.11%), swap free:0 of 4095 MiB ( 0.00%)
ago 12 10:20:10 dublin.ireland.home earlyoom[888]: low memory! at or below
SIGTERM limits: mem  2.52%, swap 10.00%
ago 12 10:20:10 dublin.ireland.home earlyoom[888]: sending SIGTERM to
process 1899195 uid 1000 "Web Content": badness 303, VmRSS 70 MiB
ago 12 10:20:14 dublin.ireland.home earlyoom[888]: process exited after 3.6
seconds
ago 12 10:20:14 dublin.ireland.home earlyoom[888]: mem avail:   315 of
15887 MiB ( 1.98%), swap free:0 of 4095 MiB ( 0.

Re: EarlyOOM +ZRAM Only

[Przemek Klosowski via devel]

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?

___
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 11:27:37 AM MST 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 the log:
> mem avail:   399 of 15887 MiB ( 2.51%), swap free:0 of 4095 MiB ( 0.00%)
> low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> sending SIGTERM to process 1899361 uid 1000 "Web Content": badness 315,
> VmRSS 313 MiB
> process exited after 2.2 seconds
> mem avail:   397 of 15887 MiB ( 2.50%), swap free:0 of 4095 MiB ( 0.00%)
> low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> sending SIGTERM to process 1899726 uid 1000 "Web Content": badness 304,
> VmRSS 80 MiB
> process exited after 3.7 seconds
> mem avail:   379 of 15887 MiB ( 2.39%), swap free:0 of 4095 MiB ( 0.00%)
> low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> sending SIGTERM to process 1896099 uid 1000 "Web Content": badness 303,
> VmRSS 74 MiB
> process exited after 3.6 seconds
> mem avail:   335 of 15887 MiB ( 2.11%), swap free:0 of 4095 MiB ( 0.00%)
> low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> sending SIGTERM to process 1899195 uid 1000 "Web Content": badness 303,
> VmRSS 70 MiB
> process exited after 3.6 seconds
> mem avail:   315 of 15887 MiB ( 1.98%), swap free:0 of 4095 MiB ( 0.00%)
> low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> sending SIGTERM to process 1899907 uid 1000 "Web Content": badness 301,
> VmRSS 27 MiB
> kill failed: Timer expired
> mem avail:   288 of 15887 MiB ( 1.81%), swap free:0 of 4095 MiB ( 0.00%)
> low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> sending SIGTERM to process 1898928 uid 1000 "VirtualBoxVM": badness 212,
> VmRSS 4244 MiB
> process exited after 0.0 seconds
> mem avail:   337 of 15887 MiB ( 2.13%), swap free:0 of 4095 MiB ( 0.00%)
> low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
> sending SIGTERM to process 1898342 uid 1000 "zoom": badness 36, VmRSS 721
> MiB
> process exited after 0.0 seconds
> 
> 
> So I wonder if is advisable using EarlyOOM + ZRAM Only, what do you
> think?
> Thanks in advance!

Please keep this in mind going forward, and take a moment to consider enabling 
EarlyOOM in Fedora. As it turns out, EarlyOOM does exactly what it says it 
does: It kills your programs when you've still got plenty of free 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: EarlyOOM +ZRAM Only

[Samuel Sieb]

On 8/12/20 11:27 AM, Sergio Belkin wrote:
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 the log:


The log of what?  Are there no timestamps?


mem avail:   399 of 15887 MiB ( 2.51%), swap free:    0 of 4095 MiB ( 0.00%)
low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
sending SIGTERM to process 1899361 uid 1000 "Web Content": badness 315, 
VmRSS 313 MiB

process exited after 2.2 seconds
mem avail:   397 of 15887 MiB ( 2.50%), swap free:    0 of 4095 MiB ( 0.00%)
low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
sending SIGTERM to process 1899726 uid 1000 "Web Content": badness 304, 
VmRSS 80 MiB

process exited after 3.7 seconds
mem avail:   379 of 15887 MiB ( 2.39%), swap free:    0 of 4095 MiB ( 0.00%)
low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
sending SIGTERM to process 1896099 uid 1000 "Web Content": badness 303, 
VmRSS 74 MiB

process exited after 3.6 seconds
mem avail:   335 of 15887 MiB ( 2.11%), swap free:    0 of 4095 MiB ( 0.00%)
low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
sending SIGTERM to process 1899195 uid 1000 "Web Content": badness 303, 
VmRSS 70 MiB

process exited after 3.6 seconds
mem avail:   315 of 15887 MiB ( 1.98%), swap free:    0 of 4095 MiB ( 0.00%)
low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
sending SIGTERM to process 1899907 uid 1000 "Web Content": badness 301, 
VmRSS 27 MiB

kill failed: Timer expired
mem avail:   288 of 15887 MiB ( 1.81%), swap free:    0 of 4095 MiB ( 0.00%)
low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
sending SIGTERM to process 1898928 uid 1000 "VirtualBoxVM": badness 212, 
VmRSS 4244 MiB

process exited after 0.0 seconds
mem avail:   337 of 15887 MiB ( 2.13%), swap free:    0 of 4095 MiB ( 0.00%)
low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
sending SIGTERM to process 1898342 uid 1000 "zoom": badness 36, VmRSS 
721 MiB

process exited after 0.0 seconds


According to this, you were completely out of memory.  zoom was the last 
resort.  I wonder what was taking up the memory that even killing the VM 
didn't free up enough.

___
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

EarlyOOM +ZRAM Only

[Sergio Belkin]

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 the log:
mem avail:   399 of 15887 MiB ( 2.51%), swap free:0 of 4095 MiB ( 0.00%)
low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
sending SIGTERM to process 1899361 uid 1000 "Web Content": badness 315,
VmRSS 313 MiB
process exited after 2.2 seconds
mem avail:   397 of 15887 MiB ( 2.50%), swap free:0 of 4095 MiB ( 0.00%)
low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
sending SIGTERM to process 1899726 uid 1000 "Web Content": badness 304,
VmRSS 80 MiB
process exited after 3.7 seconds
mem avail:   379 of 15887 MiB ( 2.39%), swap free:0 of 4095 MiB ( 0.00%)
low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
sending SIGTERM to process 1896099 uid 1000 "Web Content": badness 303,
VmRSS 74 MiB
process exited after 3.6 seconds
mem avail:   335 of 15887 MiB ( 2.11%), swap free:0 of 4095 MiB ( 0.00%)
low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
sending SIGTERM to process 1899195 uid 1000 "Web Content": badness 303,
VmRSS 70 MiB
process exited after 3.6 seconds
mem avail:   315 of 15887 MiB ( 1.98%), swap free:0 of 4095 MiB ( 0.00%)
low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
sending SIGTERM to process 1899907 uid 1000 "Web Content": badness 301,
VmRSS 27 MiB
kill failed: Timer expired
mem avail:   288 of 15887 MiB ( 1.81%), swap free:0 of 4095 MiB ( 0.00%)
low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
sending SIGTERM to process 1898928 uid 1000 "VirtualBoxVM": badness 212,
VmRSS 4244 MiB
process exited after 0.0 seconds
mem avail:   337 of 15887 MiB ( 2.13%), swap free:0 of 4095 MiB ( 0.00%)
low memory! at or below SIGTERM limits: mem  2.52%, swap 10.00%
sending SIGTERM to process 1898342 uid 1000 "zoom": badness 36, VmRSS 721
MiB
process exited after 0.0 seconds


So I wonder if is advisable using EarlyOOM + ZRAM Only, what do you
think?
Thanks in advance!


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

Re: Fedora 33, can't access NAS

[Adam Williamson]

On Wed, 2020-08-12 at 19:24 +0200, Andreas Tunek wrote:
> I made a fresh install with Fedora Workstation 33 today and everything
> seems to be working except for one problem. I can see my NAS in Files, but
> I can't connect to it. It looks exactly the same as F32 where everything
> works as expected.
> 
> Does anyone have any pointers on how to debug this, or should I just file a
> bug for Files?

Most obvious thing I'd do is run the app from a console (command is
'nautilus') and see if any useful errors show up on the console. Also
check the system journal around the time you tried to connect.
-- 
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

Fedora 33, can't access NAS

[Andreas Tunek]

I made a fresh install with Fedora Workstation 33 today and everything
seems to be working except for one problem. I can see my NAS in Files, but
I can't connect to it. It looks exactly the same as F32 where everything
works as expected.

Does anyone have any pointers on how to debug this, or should I just file a
bug for Files?

Best regards
Andreas
___
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: Fedora 33 Mass Branching

[Mattia Verga via devel]

Il 12/08/20 16:26, Mohan Boddu ha scritto:
>
> Yes, you are right, but maintainers shouldn't think that bodhi is
> active and try to submit builds as updates in bodhi.
>
> Maybe, it should be better to reword it
>
>
Actually, this should not be possible, Bodhi 5.5 will refuse to manually 
create an update if the release is not composed by Bodhi itself.

...if everything works as expected...

Mattia

___
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

where to add new documentation (and how)

[Matthew Miller]

On Sat, Aug 01, 2020 at 01:18:39PM -0500, Richard Shaw wrote:
> Perhaps... Is docs open? Or is there some process for getting this
> approved? I'm heavily making updates right now. I'm somewhat
> selfishly documenting it so I remember how I set everything up as I'm sure
> I won't remember a year from now :) But figured it's worth documenting for
> others as well.

I'm not sure what you mean by "open", but tentatively I'm going to say
"yes", because it's part of Fedora. If you want a whole docs section (like
https://docs.fedoraproject.org/en-US/diversity-inclusion/ for example), see
here:
https://docs.fedoraproject.org/en-US/fedora-docs/contributing/adding-new-docs/

However, since doing that is kind of involved and implies a level of
commitment, we have the "Quick Docs" -- that's designed for exactly this
kind of quick HOWTO information. See the repository for this at 
https://pagure.io/fedora-docs/quick-docs

-- 
Matthew Miller

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

Re: Fedora 33 Mass Branching

[Mohan Boddu]

On Wed, Aug 12, 2020 at 8:14 AM Miro Hrončok  wrote:
>
> On 12. 08. 20 1:09, Mohan Boddu wrote:
> > Bodhi is currently not
> > active for Fedora 33, it will be enabled in a couple of weeks when we
> > hit Beta change freeze point in the Fedora 33 schedule[1].
>
> It seems that this is not true this time due to gaitng. My f33 builds go 
> trough
> Bodhi (where they rest in pending, presumably until the compose is done).

Yes, you are right, but maintainers shouldn't think that bodhi is
active and try to submit builds as updates in bodhi.

Maybe, it should be better to reword it

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

Summary/Minutes from today's FESCo Meeting (2020-08-12)

[Miro Hrončok]

=
#fedora-meeting-2: FESCO (2020-08-12)
=


Meeting started by mhroncok at 14:00:07 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-08-12/fesco.2020-08-12-14.00.log.html
.



Meeting summary
---
* init process  (mhroncok, 14:00:18)

* Next week's chair  (mhroncok, 14:03:25)
  * ACTION: mhroncok will chair next meeting  (mhroncok, 14:04:15)

* Open Floor  (mhroncok, 14:04:28)
  * postgres is unlikely to get approved for 33 at this point, eln and
compiler policies can be rebranded to 34 once (if) approved
(mhroncok, 14:10:42)

Meeting ended at 14:13:40 UTC.




Action Items

* mhroncok will chair next meeting




Action Items, by person
---
* mhroncok
  * mhroncok will chair next meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* mhroncok (35)
* zodbot (13)
* bcotton (13)
* dcantrell (8)
* decathorpe (5)
* nirik (3)
* zbyszek (3)
* sgallagh (1)
* King_InuYasha (1)
* ignatenkobrain (0)
* Conan_Kudo (0)
* Eighth_Doctor (0)
* cverna (0)
* Sir_Gallantmon (0)
* Son_Goku (0)
* Pharaoh_Atem (0)




Generated by `MeetBot`_ 0.1.4

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

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

[Miro Hrončok]

On 12. 08. 20 14:39, Richard W.M. Jones wrote:

There is indeed no kernel package I can find that's tagged into
f34, but there is one tagged into f33:

   https://koji.fedoraproject.org/koji/buildinfo?buildID=1579426

Shouldn't that be enough to satisfy the dependency above through tag
inheritance?


AFAIK there is no inheritance. Upon branching, all f33 tagged builds are tagged 
to f34 and that's it. For some reason this one wasn't -- not sure if intentional 
or accidental.


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

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

[Richard W.M. Jones]

I suppose this might be a temporary issue caused by branching, but
this build in Rawhide has been failing since yesterday:

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

The error is a bit odd:

  DEBUG util.py:621:  Error: 
  DEBUG util.py:621:   Problem: package libguestfs-devel-1:1.43.1-4.fc33.x86_64 
requires libguestfs.so.0()(64bit), but none of the providers can be installed
  DEBUG util.py:621:- package libguestfs-devel-1:1.43.1-4.fc33.x86_64 
requires libguestfs(x86-64) = 1:1.43.1-4.fc33, but none of the providers can be 
installed
  DEBUG util.py:621:- conflicting requests
  DEBUG util.py:621:- nothing provides kernel needed by 
libguestfs-1:1.43.1-4.fc33.x86_64

There is indeed no kernel package I can find that's tagged into
f34, but there is one tagged into f33:

  https://koji.fedoraproject.org/koji/buildinfo?buildID=1579426

Shouldn't that be enough to satisfy the dependency above through tag
inheritance?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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: Fedora 33 Mass Branching

[Miro Hrončok]

On 12. 08. 20 1:09, Mohan Boddu wrote:

Bodhi is currently not
active for Fedora 33, it will be enabled in a couple of weeks when we
hit Beta change freeze point in the Fedora 33 schedule[1].


It seems that this is not true this time due to gaitng. My f33 builds go trough 
Bodhi (where they rest in pending, presumably until the compose is done).


--
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: CPE Team Engagement Feedback

[Aoife Moloney]

Hi Everyone,

It has been a little over a month since I have sent this email on changes
we have made to our work processes, how we are categorizing work within our
team and how we are planning projects in advance, so thank you to everyone
who replied to me with your feedback! If you caught the CPE Leadership
panel, the feedback was shared there, however here were the suggestions I
have received thus far, with my next steps inline:

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.


As a product owner of a community facing team, it is hugely important to me
to understand how you are finding our current process and what
amendments/improvements we/I should make to those ways of working for a
more transparent relationship.

If you would still like to share your suggestions and feedback with me,
please feel free to do so at any time either via email, IRC or google chat
(if you are/want to use that platform). Our team is also running a survey
so you can also submit your feedback through
https://fedoraproject.limequery.com/696793?lang=en

.
The survey will close on 30th August.


Thanks again for your engagement and please do take our survey if you wish
to share with us what you like about how we are working, and areas we can
still grow and improve in.


Kindest regards,
Aoife

On Wed, Jul 8, 2020 at 10:09 AM Aoife Moloney  wrote:

> Hi Everyone,
>
> As we kick off our team's work for Quarter 3 of this year, we would
> like to take this opportunity to ask for your feedback on our
> engagement over the last few months.
>
> The CPE has been working on trying to improve our communication with
> our communities and increase visibility on how we decide on what to
> work on. We have taken many steps to improve our communication such as
> IRC Office hours, regular initiative updates on our taiga board,
> weekly mail and blog posts on what we achieved in each quarter and
> what we are planning to work on next.
> We have also had a few discussions before with some Fedora Council and
> CentOS Board members on how best to engage with the CPE Team when you
> wish to brief in an initiative or need to file a
> bug/issue/enhancement, and as time goes by we are refining our
> processes.
> We would like to share with you our current approaches that we are
> using for you to provide feedback on how you feel these are working.
>
>
>
>
> It is important for our team to feel like their time is protected so
> that they are able to enjoy a healthy work-life balance, so we have
> categorized work requests that the team responds to into two
> categories which we believe benefits both the CPE team and the
> communities we serve:
>
> - Project Teams
> - These teams are created based on an initiative that has been:
> - Received by our product owner in advance
> - The work involved has been scoped, reviewed and accepted to
> the backlog by the CPE Review Team
> - Prioritized and actioned for work during our teams quarterly
> planning sessions by CPE Team Stakeholders and Review Team
>
> - Sustaining Team
> - This team responds to 'lights on work' and requests that come in
> on an ad hoc & regular basis such as:
> - BAU infra/releng requests
> - RFEs
> - Bug fixes
>
>
>
> ## How we propose to deal with Project Team Initiatives?
>
> * We have published deadlines for initiatives to be briefed into our
> team by for each quarter here:
> https://docs.fedoraproject.org/en-US/cpe/time_tables/
> * Project requests that are recieved are then discussed further with
> the requestor and relevant team lead(s) with our product owner
> * During our monthly quarterly planning sessions, the CPE Review Team
> reviews and prioritises which proposals to scope.
> * All scoped proposed initiatives are brought into our QP session for
> review and consideration to be worked on in the next quarter.
> 

Re: Fedora 33 Mass Branching

[Mohan Boddu]

Hi All,

Fedora 33 has now been branched, please be sure to do a git pull
--rebase to pick up the new branch, as an additional reminder
rawhide/f34 has been completely isolated from previous releases, so
this means that anything you do for f33 you also have to do in the
master branch and do a build there. There will be a Fedora 33 compose
and it'll appear in
http://dl.fedoraproject.org/pub/fedora/linux/development/33/ once
complete. Please be sure to check it out. Bodhi is currently not
active for Fedora 33, it will be enabled in a couple of weeks when we
hit Beta change freeze point in the Fedora 33 schedule[1].

Two things to remember:

1. The modules will be built for a new platform:f34
2. The signing of rpms is not done yet with the new f34 key.
3. F33/branched release is frozen right now until we get a successful
compose, expect that your f33 builds won't be available immediately.

Thanks for understanding.

Mohan Boddu.

[1] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html

On Sun, Aug 9, 2020 at 3:16 PM Mohan Boddu  wrote:
>
> Hello All,
>
> Fedora 33 will be branched from rawhide on August 11th 2020 as per the
> Fedora 33 schedule[1]. The process takes about a day and everything
> should be ready by August 12th 2020. You can still be able to build
> packages normally until then, but after the mass branching, rawhide
> and F33 will be separated.
>
> We will send another email once the branching is done.
>
> Thanks,
> Mohan Boddu.
>
> [1] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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-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

Re: Highlights from the latest Copr release

[Kevin Kofler]

Unfortunately, Copr still deletes data without warning:
https://bugzilla.redhat.com/show_bug.cgi?id=1868367

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

Re: Zanata removal is soon, please finish migration

[jkonecny]

Hi,

see my answers below.

On Tue, 2020-08-11 at 05:28 +, Jean-Baptiste Holcroft wrote:
> python-mehhttps://github.com/rhinstaller/python-meh/issues/25
This project didn't have a release in decade. I will try to look on
this soon.

> python-simpleline 
> https://github.com/rhinstaller/python-simpleline/issues/63
Already migrated. I just forget to close the issue. Thanks for
reminder.

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

Re: Highlights from the latest Copr release

[Iñaki Ucar]

On Wed, 12 Aug 2020 at 12:32, Pavel Raiskup  wrote:
>
> On Wednesday, August 12, 2020 11:19:00 AM CEST Iñaki Ucar wrote:
> > On Wed, 12 Aug 2020 at 10:29, Pavel Raiskup  wrote:
> > > - Copr newly provides a build-time macro %buildtag.  Its format is
> > >   `.copr` and is useable for auto-incrementing the package's NVR
> > >   in subsequent builds.  It may be used in spec file like:
> > >
> > > Release: 1%{?dist}%{?buildtag}
> > >
> > >   It could be useful as good-enough alternative for the Release
> > >   auto-bumping proposal.  See the fedora devel discussion [2] for more
> > >   info.  This is not any kind of encouragement to use it.  We added it
> > >   there to easy testing your ideas about the automatic filling of the
> > >   Release tag.
> >
> > Nice one! I understand that having a mix of builds with and without
> > this tag isn't an issue, right? I.e., would
> > --.copr.fcXX be picked as an update of
> > --.fcXX? Or do we need to rebuild all with the
> > new tag and remove the old ones?
>
> No need to do batch-updates.
>
>   $ rpmdev-vercmp 1-1.fc32.copr1234 1-1.fc32
>   1-1.fc32.copr1234 > 1-1.fc32
>
> But note I proposed to use %buildtag after %dist, not vice versa.  Moving
> %buildtag before %dist would mean that we loose the benefit of dist
> tag -- when both fcNN and fcNN-1 builds exist in multiple repositories
> (notable example is 'fedora' and 'updates') fcNN is the preferred variant
> for installation.

Oh, yeap, right, I pasted the dist tag in the wrong place.

> > > - All the background jobs have now a lower priority than normal jobs.
> > >   Previously, background source builds were still prioritized over normal
> > >   builds.  This should be the last step towards a fair build scheduler.
> >
> > Change of mind? My understanding from the last time we discussed this
> > was that source builds needed to be prioritized no matter what.
>
> No problems to admit a change of mind ;-) that happens all the time.

:)

> Mainly I was afraid that source background builds will eat too much of the
> frontend storage.  But there don't seem to be that huge performance
> problems, and that worry was probably a bit over-pessimistic.

I think both options are fine (background source builds with higher or
lower priority), as I said in prior discussions, provided that
non-background normal builds get prioritized over background normal
builds. :)

-- 
Iñaki Úcar
___
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: Highlights from the latest Copr release

[Pavel Raiskup]

On Wednesday, August 12, 2020 11:19:00 AM CEST Iñaki Ucar wrote:
> On Wed, 12 Aug 2020 at 10:29, Pavel Raiskup  wrote:
> >
> > Hello.
> >
> > On Aug 12 2020, a new Copr release landed production.  Here is the list
> > of visible changes:
> >
> > - Project karma implemented; Logged-in users can give
> >   thumbs-up/thumbs-down to the existing copr projects.  This is just
> >   another way to give feedback about a particular Copr project quality.
> >   This is merely subjective.  We do not give you guidance what "thumbs
> >   up/down" means.  When it is good for you - for whatever reason - give it
> >   thumbs up.  It may be just feedback for the maintainer or other users.
> >   Or we may automatically select and group high-quality projects in the
> >   future - and e.g. revive the idea of the Playground [1].  The options
> >   are open. We would like to hear your feedback about this feature!
> 
> I suppose that the UI looks for some resemblance to StackOverflow's
> vote counter. SO's counter is more prominent in the first place
> (larger arrows and number), but I don't even think that's a good UI.
> We simply got accustomed to it because we know what it is.

Yes, we looked at several popular sites and the voting UI, and picked one
of the existing variants.

> > - Copr newly provides a build-time macro %buildtag.  Its format is
> >   `.copr` and is useable for auto-incrementing the package's NVR
> >   in subsequent builds.  It may be used in spec file like:
> >
> > Release: 1%{?dist}%{?buildtag}
> >
> >   It could be useful as good-enough alternative for the Release
> >   auto-bumping proposal.  See the fedora devel discussion [2] for more
> >   info.  This is not any kind of encouragement to use it.  We added it
> >   there to easy testing your ideas about the automatic filling of the
> >   Release tag.
> 
> Nice one! I understand that having a mix of builds with and without
> this tag isn't an issue, right? I.e., would
> --.copr.fcXX be picked as an update of
> --.fcXX? Or do we need to rebuild all with the
> new tag and remove the old ones?

No need to do batch-updates.

  $ rpmdev-vercmp 1-1.fc32.copr1234 1-1.fc32
  1-1.fc32.copr1234 > 1-1.fc32

But note I proposed to use %buildtag after %dist, not vice versa.  Moving
%buildtag before %dist would mean that we loose the benefit of dist
tag -- when both fcNN and fcNN-1 builds exist in multiple repositories
(notable example is 'fedora' and 'updates') fcNN is the preferred variant
for installation.

> > - All the background jobs have now a lower priority than normal jobs.
> >   Previously, background source builds were still prioritized over normal
> >   builds.  This should be the last step towards a fair build scheduler.
> 
> Change of mind? My understanding from the last time we discussed this
> was that source builds needed to be prioritized no matter what.

No problems to admit a change of mind ;-) that happens all the time.

Mainly I was afraid that source background builds will eat too much of the
frontend storage.  But there don't seem to be that huge performance
problems, and that worry was probably a bit over-pessimistic.

Also, source builds are not yet visible in statistics, so if there's any
problem with source builds - it isn't anyhow obvious (Dominik is working
on the fix in issue 295).

Pavel


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

Re: Highlights from the latest Copr release

[Miro Hrončok]

On 12. 08. 20 11:19, Iñaki Ucar wrote:

- Copr newly provides a build-time macro %buildtag.  Its format is
   `.copr` and is useable for auto-incrementing the package's NVR
   in subsequent builds.  It may be used in spec file like:

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

   It could be useful as good-enough alternative for the Release
   auto-bumping proposal.  See the fedora devel discussion [2] for more
   info.  This is not any kind of encouragement to use it.  We added it
   there to easy testing your ideas about the automatic filling of the
   Release tag.

Nice one! I understand that having a mix of builds with and without
this tag isn't an issue, right? I.e., would
--.copr.fcXX be picked as an update of
--.fcXX? Or do we need to rebuild all with the
new tag and remove the old ones?



It's actually --.fcXX.copr in the example above. An 
that sorts higher.


$ rpmdev-vercmp e:v-r.fc34.copr1234567 e:v-r.fc34
e:v-r.fc34.copr1234567 > e:v-r.fc34

--
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: Highlights from the latest Copr release

[Miro Hrončok]

On 12. 08. 20 11:20, Pavel Raiskup wrote:

- Copr newly provides a build-time macro %buildtag.  Its format is
`.copr` and is useable for auto-incrementing the package's NVR
in subsequent builds.  It may be used in spec file like:

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

It could be useful as good-enough alternative for the Release
auto-bumping proposal.  See the fedora devel discussion [2] for more
info.  This is not any kind of encouragement to use it.  We added it
there to easy testing your ideas about the automatic filling of the
Release tag.

This is really interesting feature for some of the projects.
Can this be used in official Fedora specfiles

It is meant to be no-op as long as build system doesn't define it.  So at
least technically there's no problem.


or does it need a guideline?

I don't think it is forbidden by guidelines (we can not use macros for
other distributions, but that is a different topic).  Dunno if we need to
have an explicit ACK for this.  Ideas?


Most likely we don't. I was just trying to think ahead.

--
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: Highlights from the latest Copr release

[Pavel Raiskup]

On Wednesday, August 12, 2020 10:51:56 AM CEST Miro Hrončok wrote:
> On 12. 08. 20 10:29, Pavel Raiskup wrote:
> > - Project karma implemented; Logged-in users can give
> >thumbs-up/thumbs-down to the existing copr projects.  [snip]
> >This is just
>
> Assuming the arrows up and down near the copr name are for karma, I find the
> UI for this is a tad confusing. I've seen it before reading your announcement
> and had no idea what it is.
> 
> (This is true especially before refreshing the browser cache, it gets a bit
> better after.)

Bleh, I faced the cache issue as well.  Let's take a look if we can do something
about it...

> > - Copr newly provides a build-time macro %buildtag.  Its format is
> >`.copr` and is useable for auto-incrementing the package's NVR
> >in subsequent builds.  It may be used in spec file like:
> > 
> >  Release: 1%{?dist}%{?buildtag}
> > 
> >It could be useful as good-enough alternative for the Release
> >auto-bumping proposal.  See the fedora devel discussion [2] for more
> >info.  This is not any kind of encouragement to use it.  We added it
> >there to easy testing your ideas about the automatic filling of the
> >Release tag.
> 
> This is really interesting feature for some of the projects.
> Can this be used in official Fedora specfiles 

It is meant to be no-op as long as build system doesn't define it.  So at
least technically there's no problem.

> or does it need a guideline?

I don't think it is forbidden by guidelines (we can not use macros for
other distributions, but that is a different topic).  Dunno if we need to
have an explicit ACK for this.  Ideas?

Pavel


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

Re: Highlights from the latest Copr release

[Iñaki Ucar]

On Wed, 12 Aug 2020 at 10:29, Pavel Raiskup  wrote:
>
> Hello.
>
> On Aug 12 2020, a new Copr release landed production.  Here is the list
> of visible changes:
>
> - Project karma implemented; Logged-in users can give
>   thumbs-up/thumbs-down to the existing copr projects.  This is just
>   another way to give feedback about a particular Copr project quality.
>   This is merely subjective.  We do not give you guidance what "thumbs
>   up/down" means.  When it is good for you - for whatever reason - give it
>   thumbs up.  It may be just feedback for the maintainer or other users.
>   Or we may automatically select and group high-quality projects in the
>   future - and e.g. revive the idea of the Playground [1].  The options
>   are open. We would like to hear your feedback about this feature!

I suppose that the UI looks for some resemblance to StackOverflow's
vote counter. SO's counter is more prominent in the first place
(larger arrows and number), but I don't even think that's a good UI.
We simply got accustomed to it because we know what it is.

> - Copr newly provides a build-time macro %buildtag.  Its format is
>   `.copr` and is useable for auto-incrementing the package's NVR
>   in subsequent builds.  It may be used in spec file like:
>
> Release: 1%{?dist}%{?buildtag}
>
>   It could be useful as good-enough alternative for the Release
>   auto-bumping proposal.  See the fedora devel discussion [2] for more
>   info.  This is not any kind of encouragement to use it.  We added it
>   there to easy testing your ideas about the automatic filling of the
>   Release tag.

Nice one! I understand that having a mix of builds with and without
this tag isn't an issue, right? I.e., would
--.copr.fcXX be picked as an update of
--.fcXX? Or do we need to rebuild all with the
new tag and remove the old ones?

> - Command-line interface for the project package listing was significantly
>   optimized, and should now be faster than the web-UI on large projects
>   (issue/757).

Many thanks for this!

> - All the background jobs have now a lower priority than normal jobs.
>   Previously, background source builds were still prioritized over normal
>   builds.  This should be the last step towards a fair build scheduler.

Change of mind? My understanding from the last time we discussed this
was that source builds needed to be prioritized no matter what.

> - Support for a new command 'copr-cli list-builds ' was added.
>   It lists each build on a separate line, as a tab-separated list of
>  items.

Just great! I'll try this instead of my "download a several-dozen-MB
HTML of builds, parse the table to get a dataframe and then regex the
columns" mad script. :)

-- 
Iñaki Úcar
___
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: Highlights from the latest Copr release

[Miro Hrončok]

On 12. 08. 20 10:29, Pavel Raiskup wrote:

Hello.

On Aug 12 2020, a new Copr release landed production.  Here is the list
of visible changes:

- Project karma implemented; Logged-in users can give
   thumbs-up/thumbs-down to the existing copr projects.  This is just
   another way to give feedback about a particular Copr project quality.
   This is merely subjective.  We do not give you guidance what "thumbs
   up/down" means.  When it is good for you - for whatever reason - give it
   thumbs up.  It may be just feedback for the maintainer or other users.
   Or we may automatically select and group high-quality projects in the
   future - and e.g. revive the idea of the Playground [1].  The options
   are open. We would like to hear your feedback about this feature!


Assuming the arrows up and down near the copr name are for karma, I find the UI 
for this is a tad confusing. I've seen it before reading your announcement and 
had no idea what it is.


(This is true especially before refreshing the browser cache, it gets a bit 
better after.)



- Copr newly provides a build-time macro %buildtag.  Its format is
   `.copr` and is useable for auto-incrementing the package's NVR
   in subsequent builds.  It may be used in spec file like:

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

   It could be useful as good-enough alternative for the Release
   auto-bumping proposal.  See the fedora devel discussion [2] for more
   info.  This is not any kind of encouragement to use it.  We added it
   there to easy testing your ideas about the automatic filling of the
   Release tag.


This is really interesting feature for some of the projects.
Can this be used in official Fedora specfiles or does it need a guideline?


- Command-line interface for the project package listing was significantly
   optimized, and should now be faster than the web-UI on large projects
   (issue/757).


Thanks, I'll test it instead of my "parse-HTML-by-regex" mad script :)

--
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: LTO and the F33 mass rebuild

[Vít Ondruch]

Dne 11. 08. 20 v 18:43 Kevin Fenzi napsal(a):
> On Sun, Aug 09, 2020 at 10:06:49PM -0600, Jeff Law wrote:
>> On Sun, 2020-08-09 at 12:02 +0200, Fabio Valentini wrote:
>>> On Sun, Aug 9, 2020 at 12:03 AM Jeff Law  wrote:
 So I've done two passes over the F33 build failures here:

 https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html
>>> Hi Jeff,
>>>
>>> Thanks for looking at the failures, it's really appreciated!
>>>
>>> Be aware that the f33-failures.html page is not complete though, since
>>> packages for which there was an attempted rebuild *after* the mass
>>> rebuild are removed from the list, whether the builds succeeded or
>>> not. So it's possible that you missed builds that fail for LTO-related
>>> issues, just because they're no longer showing up in the list. The
>>> list of bugs blocking the F33FTBFS bug in bugzilla [0] might be
>>> helpful here. And the f33-need-rebuild list [1] should give you a
>>> complete picture of everything that has not successfully been rebuilt
>>> for f33 yet.
>> ACK.  I'm poking at the f33-need-rebuild.html list a bit.  THere's a lot of 
>> noise
>> in there -- things that haven't been built in a long time.  Anyway, I'll keep
>> poking around.
>>
>> It would be helpful if there was a clean way to download failed log files and
>> such in batches so that I could run tools on them to look for common things 
>> that
>> don't need my attention (like all the cmake failures).  As it stands I have 
>> to do
>> an insane amount of clickies to get to some basic data.
> It's been proposed to enable the koji 'save-failed-tree' plugin:
> https://pagure.io/releng/issue/8243


It could be so much better for FTBFS bugs after mass rebuild ...


Vít


>
> It might help for this sort of thing, as it lets you get a complete tar
> of the entire tree. 
>
> I'll look into it more after we have staging koji back...
>
> kevin
>
> ___
> 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


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

Highlights from the latest Copr release

[Pavel Raiskup]

Hello.

On Aug 12 2020, a new Copr release landed production.  Here is the list
of visible changes:

- Project karma implemented; Logged-in users can give
  thumbs-up/thumbs-down to the existing copr projects.  This is just
  another way to give feedback about a particular Copr project quality.
  This is merely subjective.  We do not give you guidance what "thumbs
  up/down" means.  When it is good for you - for whatever reason - give it
  thumbs up.  It may be just feedback for the maintainer or other users.
  Or we may automatically select and group high-quality projects in the
  future - and e.g. revive the idea of the Playground [1].  The options
  are open. We would like to hear your feedback about this feature!

- Copr newly provides a build-time macro %buildtag.  Its format is
  `.copr` and is useable for auto-incrementing the package's NVR
  in subsequent builds.  It may be used in spec file like:

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

  It could be useful as good-enough alternative for the Release
  auto-bumping proposal.  See the fedora devel discussion [2] for more
  info.  This is not any kind of encouragement to use it.  We added it
  there to easy testing your ideas about the automatic filling of the
  Release tag.

- The /status page has a new "Starting" tab [3] which shows all the binary
  builds where the worker process is already started, but appropriate
  builder VM is not yet assigned to it (issue/1429).

- Group avatars (user-icons assigned to an e-mail) were fixed to
  really use the groups' emails, not the administrators' (issue/1419).

- Command-line interface for the project package listing was significantly
  optimized, and should now be faster than the web-UI on large projects
  (issue/757).

- All the background jobs have now a lower priority than normal jobs.
  Previously, background source builds were still prioritized over normal
  builds.  This should be the last step towards a fair build scheduler.

- Support for a new command 'copr-cli list-builds ' was added.
  It lists each build on a separate line, as a tab-separated list of
 items.

Related copr client Fedora/EPEL updates:

  F32 - https://bodhi.fedoraproject.org/updates/FEDORA-2020-ce81a9539d
  F31 - https://bodhi.fedoraproject.org/updates/FEDORA-2020-76bfc383c3
  EPEL8 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4c313586d8
  EPEL7 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6a77e31d06
  EPEL6 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-78e089fe70

Should you have any related issues, please report them to us as usual.

[1] https://fedoraproject.org/wiki/Playground
[2] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/TXLF22CSUVUIQBVHH2NEFF4IOIFHS5WK/
[3] https://copr.fedorainfracloud.org/status/starting/

Happy building!
Copr Team


___
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