not sending emails for the semiannual rawhide→branched bug assignment update

[Zbigniew Jędrzejewski-Szmek]

Bugzilla now has "This is a minor update (do not send email)" checkbox in the
web interface. I hope the same setting is available through the API.
When bugs are reassigned (e.g. the recent rawhide→F31 reassignment), maybe
this could be used to not send mail notifications?

Zbyszek
___
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: vdr-epg-daemon does not compile on f32

[Martin Gansser]

I changed a few things in the spec file [1], but the compilation breaks on f30.

[1] 
https://src.fedoraproject.org/rpms/vdr-epg-daemon/blob/master/f/vdr-epg-daemon.spec

make[1]: Entering directory 
'/home/martin/rpmbuild/BUILD/vdr-epg-daemon-1.1.146/epglv'
gcc -c -I/usr/include/mysql -fPIC -L/usr/lib64/mysql -L/usr/lib64/ -lmariadb 
-DMYSQL_DYNAMIC_PLUGIN -DDEBUG_MYSQL=0 -ggdb -fno-stack-protector -O -O2 -g 
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong 
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c++11 -D__STDC_FORMAT_MACROS 
-shared src/epglv.c -o src/epglv.o
cc1: warning: command line option '-std=c++11' is valid for C++/ObjC++ but not 
for C
make[1]: Leaving directory 
'/home/martin/rpmbuild/BUILD/vdr-epg-daemon-1.1.146/epglv'
make[1]: Entering directory 
'/home/martin/rpmbuild/BUILD/vdr-epg-daemon-1.1.146/epglv'
gcc -c -I/usr/include/mysql -fPIC -L/usr/lib64/mysql -L/usr/lib64/ -lmariadb 
-DMYSQL_DYNAMIC_PLUGIN -DDEBUG_MYSQL=0 -ggdb -fno-stack-protector -O -O2 -g 
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong 
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c++11 -D__STDC_FORMAT_MACROS 
-shared src/epglvbase.c -o src/epglvbase.o
cc1: warning: command line option '-std=c++11' is valid for C++/ObjC++ but not 
for C
make[1]: Leaving directory 
'/home/martin/rpmbuild/BUILD/vdr-epg-daemon-1.1.146/epglv'
make[1]: Entering directory 
'/home/martin/rpmbuild/BUILD/vdr-epg-daemon-1.1.146/epglv'
gcc -I/usr/include/mysql -fPIC -L/usr/lib64/mysql -L/usr/lib64/ -lmariadb 
-DMYSQL_DYNAMIC_PLUGIN -DDEBUG_MYSQL=0 -ggdb -fno-stack-protector -O -O2 -g 
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong 
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c++11 -D__STDC_FORMAT_MACROS 
-shared -o mysqlepglv.so src/epglvbase.o src/epglv.o
make[1]: Leaving directory 
'/home/martin/rpmbuild/BUILD/vdr-epg-daemon-1.1.146/epglv'
Package python3.8-embed was not found in the pkg-config search path.
Perhaps you should add the directory containing `python3.8-embed.pc'
to the PKG_CONFIG_PATH environment variable
Package 'python3.8-embed', required by 'virtual:world', not found
Package python3.8 was not found in the pkg-config search path.
Perhaps you should add the directory containing `python3.8.pc'
to the PKG_CONFIG_PATH environment variable
Package 'python3.8', required by 'virtual:world', not found
Package python3.8-embed was not found in the pkg-config search path.
Perhaps you should add the directory containing `python3.8-embed.pc'
to the PKG_CONFIG_PATH environment variable
Package 'python3.8-embed', required by 'virtual:world', not found
Package python3.8 was not found in the pkg-config search path.
Perhaps you should add the directory containing `python3.8.pc'
to the PKG_CONFIG_PATH environment variable
Package 'python3.8', required by 'virtual:world', not found
g++ -rdynamic main.o update.o plugin.o epgdconfig.o channelmap.o series.o 
svdrpclient.o levenshtein.o episode.o tvdbmanager.o moviedbmanager.o 
tools/fuzzy.o tools/stringhelpers.o scraper/thetvdbscraper/thetvdbscraper.o 
scraper/thetvdbscraper/tvdbseries.o scraper/thetvdbscraper/tvdbmirrors.o 
scraper/thetvdbscraper/tvdbmedia.o scraper/thetvdbscraper/tvdbactor.o 
scraper/thetvdbscraper/tvdbepisode.o 
scraper/themoviedbscraper/themoviedbscraper.o 
scraper/themoviedbscraper/moviedbmovie.o 
scraper/themoviedbscraper/moviedbactor.o -L./lib -lhorchi -lrt -lz -larchive 
-ldl -lcrypto -luuid -L/usr/lib64/ -lmariadb Usage: 
/usr/bin/python3.7m-x86_64-config 
--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--extension-suffix|--help|--abiflags|--configdir
 -lpython3.7m -lcrypt -lpthread -ldl  -lutil -lm-lcurl -lxml2 -lz -llzma 
-lm -ldl -L/usr/lib64 -lxslt -lxml2 -lm -lexslt -o epgd
/bin/sh: --help: command not found
/bin/sh: --extension-suffix: command not found
/bin/sh: --configdir: command not found
/bin/sh: --ldflags: command not found
/bin/sh: --cflags: command not found
/bin/sh: --libs: command not found
/bin/sh: --exec-prefix: command not found
/bin/sh: --includes: command not found
/bin/sh: --abiflags: command not found
g++: error: Usage:: No such file or directory
g++: error: missing argumen

Re: not sending emails for the semiannual rawhide→branched bug assignment update

[Miro Hrončok]

On 18. 08. 19 10:35, Zbigniew Jędrzejewski-Szmek wrote:

Bugzilla now has "This is a minor update (do not send email)" checkbox in the
web interface. I hope the same setting is available through the API.
When bugs are reassigned (e.g. the recent rawhide→F31 reassignment), maybe
this could be used to not send mail notifications?


Done.

This was always the intention, but the API has changed in a weird way:

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

https://pagure.io/fedora-project-schedule/issue/134

--
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: not sending emails for the semiannual rawhide→branched bug assignment update

[Zbigniew Jędrzejewski-Szmek]

On Sun, Aug 18, 2019 at 11:35:12AM +0200, Miro Hrončok wrote:
> On 18. 08. 19 10:35, Zbigniew Jędrzejewski-Szmek wrote:
> >Bugzilla now has "This is a minor update (do not send email)" checkbox in the
> >web interface. I hope the same setting is available through the API.
> >When bugs are reassigned (e.g. the recent rawhide→F31 reassignment), maybe
> >this could be used to not send mail notifications?
> 
> Done.
> 
> This was always the intention, but the API has changed in a weird way:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7K5TBJD4ULT472WAGZGLOL4GJJX23H6W/
> 
> https://pagure.io/fedora-project-schedule/issue/134

Nice!

Zbyszek
___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[Vitaly Zaitsev via devel]

On 18.08.2019 2:24, Joseph D. Wagner wrote:
> The Plymouth LUKS password prompt will wait FOREVER for me to type in a
> password

This is intended, because system is not even started yet on
LUKS-encrypted media attach stage.

If you don't want to enter LUKS password on every boot, you should use
TPM or hardware tokens.

-- 
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: Better interactivity in low-memory situations

[Gordan Bobic]

On Sun, Aug 11, 2019 at 10:36 AM  wrote:
> This seems like a distraction from the real goal here, which is to
> ensure Fedora remains responsive under heavy memory pressure,

I think this is an overwhelmingly important point, and as somebody
regularly working with ARM machines with tiny amounts of RAM, it is of
considerable interest to me.
I typically use CentOS because stability is important to me, but most
worthwhile things filter to there, so I hope what I'm about to say is not
_too_ deprecated.

1) Compile options
>From what I can tell from rpm macro options, default on C7 seems to be -O2.
-Os seems to help in most cases.
Adding -ffunction-sections -fdata-sections to defaults can help
considerably in producing smaller binaries, and is not the default.
Linking with -Wl,--gc-sections helps a lot and is not the default
Extensive stripping seems to already be the default (--strip-unneeded,
removal of .comment and .note sections)

2) Runtime condiguration
Default stack size is 8192 (ulimit -s). This unnecessarily eats a
considerably amount of memory. I have yet to see anything that actually
experiences problems with 1M.

3) zram
This was mentioned earlier in the thread, and on most of my systems, memory
constrained or otherwise, unless I have an overwhelming reason not to, I
run with zram swap equal in size to RAM with lz4 compression and
vm.swappiness=100. I typically see compression ratios between 2:1 and 3:1
in zram, so on a system with, say, 10GB of RAM, it would provide 10GB of
very fast swap at a cost of 3-5GB of RAM. This seems like a favourable
trade off, especially on systems with extremely constrained RAM (e.g. ARM
devices with 512MB of RAM).

I'm sure there is more that can be done, but this seems like a good start
as far as the cost / benefit is concerned.
___
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: startx unsets DBUS_SESSION_BUS_ADDRESS, which breaks user D-Bus session

[Hans de Goede]

Hi,

On 24-10-18 00:53, Alexey Rochev wrote:

Hello,
I would like to draw some attention to this bug: 
https://bugzilla.redhat.com/show_bug.cgi?id=1622259. Description: startx unsets 
DBUS_SESSION_BUS_ADDRESS, which result in launching another D-Bus session which 
breaks communicating with user systemd services (and any D-Bus services started 
before launching X) from X session via D-Bus, since they use two different 
D-Bus daemons. I would really like this bug to be fixed.


I'm going over my backlog of things to respond to, even though
this mail was send a over a year ago this seems worthwhile to
respond too.

I've currently re-opened the discussion about this here:
https://gitlab.freedesktop.org/xorg/app/xinit/issues/9

Hopefully we can get some momentum on getting this fixed
there.

Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.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: Better interactivity in low-memory situations

[Hans de Goede]

Hi,

On 18-08-19 13:33, Gordan Bobic wrote:

On Sun, Aug 11, 2019 at 10:36 AM http://gnome.org/>> 
wrote:
 > This seems like a distraction from the real goal here, which is to
 > ensure Fedora remains responsive under heavy memory pressure,

I think this is an overwhelmingly important point, and as somebody regularly 
working with ARM machines with tiny amounts of RAM, it is of considerable 
interest to me.
I typically use CentOS because stability is important to me, but most 
worthwhile things filter to there, so I hope what I'm about to say is not _too_ 
deprecated.

1) Compile options
 From what I can tell from rpm macro options, default on C7 seems to be -O2. 
-Os seems to help in most cases.


I don't think it is likely that Fedora will switch to -Os


Adding -ffunction-sections -fdata-sections to defaults can help considerably in 
producing smaller binaries, and is not the default.
Linking with -Wl,--gc-sections helps a lot and is not the default


These OTOH are interesting I know that e.g. uboot combines these and it helps a 
lot to get smaller binaries,
and this should help with RAM size too, since if a page of a binary contains 
mostly unused things and 1 symbol
which is actually used it will still get paged in.

Can you perhaps start a new devel list thread about just this ? Maybe with some 
binary size numbers for
some apps / libs build with and without these options?


Extensive stripping seems to already be the default (--strip-unneeded, removal 
of .comment and .note sections)

2) Runtime condiguration
Default stack size is 8192 (ulimit -s). This unnecessarily eats a considerably 
amount of memory. I have yet to see anything that actually experiences problems 
with 1M.


Actually ulimit -s is the *maximum* stack size, I'm pretty sure the stack will 
start much smaller and
grow dynamically. So changing this is not saving any RAM and it will makes apps 
which do have high
stack usage crash when they hit the new lower limit.

Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.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: Better interactivity in low-memory situations

[Gordan Bobic]

On Sun, Aug 18, 2019 at 2:06 PM Hans de Goede  wrote:

> Hi,
>
> On 18-08-19 13:33, Gordan Bobic wrote:
> > On Sun, Aug 11, 2019 at 10:36 AM  http://gnome.org/>> wrote:
> >  > This seems like a distraction from the real goal here, which is to
> >  > ensure Fedora remains responsive under heavy memory pressure,
> >
> > I think this is an overwhelmingly important point, and as somebody
> regularly working with ARM machines with tiny amounts of RAM, it is of
> considerable interest to me.
> > I typically use CentOS because stability is important to me, but most
> worthwhile things filter to there, so I hope what I'm about to say is not
> _too_ deprecated.
> >
> > 1) Compile options
> >  From what I can tell from rpm macro options, default on C7 seems to be
> -O2. -Os seems to help in most cases.
>
> I don't think it is likely that Fedora will switch to -Os
>

It is not my place to argue about whether it will. The thread was asking
for things that might contribute toward alleviating the memory pressure
problem. This can make a fairly dramatic difference and it would contribute
toward alleviating the problem because smaller binaries mean less to mmap().


> > Adding -ffunction-sections -fdata-sections to defaults can help
> considerably in producing smaller binaries, and is not the default.
> > Linking with -Wl,--gc-sections helps a lot and is not the default
>
> These OTOH are interesting I know that e.g. uboot combines these and it
> helps a lot to get smaller binaries,
> and this should help with RAM size too, since if a page of a binary
> contains mostly unused things and 1 symbol
> which is actually used it will still get paged in.
>
> Can you perhaps start a new devel list thread about just this ? Maybe with
> some binary size numbers for
> some apps / libs build with and without these options?
>

It's pretty well documented in various articles, e.g.:
https://wiki.wxwidgets.org/Reducing_Executable_Size
It also covers how much difference -Os can make.


> > Extensive stripping seems to already be the default (--strip-unneeded,
> removal of .comment and .note sections)
> >
> > 2) Runtime condiguration
> > Default stack size is 8192 (ulimit -s). This unnecessarily eats a
> considerably amount of memory. I have yet to see anything that actually
> experiences problems with 1M.
>
> Actually ulimit -s is the *maximum* stack size, I'm pretty sure the stack
> will start much smaller and
> grow dynamically. So changing this is not saving any RAM and it will makes
> apps which do have high
> stack usage crash when they hit the new lower limit.


Either way, it makes a noticeable difference to memory consumption on a
very memory constrained system without any other obvious adverse effects.
___
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: Better interactivity in low-memory situations

[Hans de Goede]

Hi,

On 18-08-19 15:25, Gordan Bobic wrote:

On Sun, Aug 18, 2019 at 2:06 PM Hans de Goede mailto:hdego...@redhat.com>> wrote:

Hi,

On 18-08-19 13:33, Gordan Bobic wrote:
 > On Sun, Aug 11, 2019 at 10:36 AM http://gnome.org> 
> wrote:
 >  > This seems like a distraction from the real goal here, which is to
 >  > ensure Fedora remains responsive under heavy memory pressure,
 >
 > I think this is an overwhelmingly important point, and as somebody 
regularly working with ARM machines with tiny amounts of RAM, it is of 
considerable interest to me.
 > I typically use CentOS because stability is important to me, but most 
worthwhile things filter to there, so I hope what I'm about to say is not _too_ 
deprecated.
 >
 > 1) Compile options
 >  From what I can tell from rpm macro options, default on C7 seems to be 
-O2. -Os seems to help in most cases.

I don't think it is likely that Fedora will switch to -Os


It is not my place to argue about whether it will. The thread was asking for 
things that might contribute toward alleviating the memory pressure problem. 
This can make a fairly dramatic difference and it would contribute toward 
alleviating the problem because smaller binaries mean less to mmap().


 > Adding -ffunction-sections -fdata-sections to defaults can help 
considerably in producing smaller binaries, and is not the default.
 > Linking with -Wl,--gc-sections helps a lot and is not the default

These OTOH are interesting I know that e.g. uboot combines these and it 
helps a lot to get smaller binaries,
and this should help with RAM size too, since if a page of a binary 
contains mostly unused things and 1 symbol
which is actually used it will still get paged in.

Can you perhaps start a new devel list thread about just this ? Maybe with 
some binary size numbers for
some apps / libs build with and without these options?


It's pretty well documented in various articles, e.g.:
https://wiki.wxwidgets.org/Reducing_Executable_Size
It also covers how much difference -Os can make.


Interesting, thank you for that link.



 > Extensive stripping seems to already be the default (--strip-unneeded, 
removal of .comment and .note sections)
 >
 > 2) Runtime condiguration
 > Default stack size is 8192 (ulimit -s). This unnecessarily eats a 
considerably amount of memory. I have yet to see anything that actually 
experiences problems with 1M.

Actually ulimit -s is the *maximum* stack size, I'm pretty sure the stack 
will start much smaller and
grow dynamically. So changing this is not saving any RAM and it will makes 
apps which do have high
stack usage crash when they hit the new lower limit.


Either way, it makes a noticeable difference to memory consumption on a very 
memory constrained system without any other obvious adverse effects.


Interesting unless I'm reading the manpage wrong, "ulimit -s" sets the maximum 
stack-size.
Maybe that also influences the initial sizing of the stack ?

Can someone who knows more about this shed some light on this? Is there a way 
to go with
a smaller initial stack-size without changing the maximum size?

Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.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: Better interactivity in low-memory situations

[Gordan Bobic]

On Sun, Aug 18, 2019 at 2:33 PM Hans de Goede  wrote:

>
> >  > Adding -ffunction-sections -fdata-sections to defaults can help
> considerably in producing smaller binaries, and is not the default.
> >  > Linking with -Wl,--gc-sections helps a lot and is not the default
> >
> > These OTOH are interesting I know that e.g. uboot combines these and
> it helps a lot to get smaller binaries,
> > and this should help with RAM size too, since if a page of a binary
> contains mostly unused things and 1 symbol
> > which is actually used it will still get paged in.
> >
> > Can you perhaps start a new devel list thread about just this ?
> Maybe with some binary size numbers for
> > some apps / libs build with and without these options?
> >
> >
> > It's pretty well documented in various articles, e.g.:
> > https://wiki.wxwidgets.org/Reducing_Executable_Size
> > It also covers how much difference -Os can make.
>
> Interesting, thank you for that link.
>
>
> >  > Extensive stripping seems to already be the default
> (--strip-unneeded, removal of .comment and .note sections)
> >  >
> >  > 2) Runtime condiguration
> >  > Default stack size is 8192 (ulimit -s). This unnecessarily eats a
> considerably amount of memory. I have yet to see anything that actually
> experiences problems with 1M.
> >
> > Actually ulimit -s is the *maximum* stack size, I'm pretty sure the
> stack will start much smaller and
> > grow dynamically. So changing this is not saving any RAM and it will
> makes apps which do have high
> > stack usage crash when they hit the new lower limit.
> >
> >
> > Either way, it makes a noticeable difference to memory consumption on a
> very memory constrained system without any other obvious adverse effects.
>
> Interesting unless I'm reading the manpage wrong, "ulimit -s" sets the
> maximum stack-size.
> Maybe that also influences the initial sizing of the stack ?
>

I believe it does. Or at least that is the only explanation I can come up
with for the observation.


>
> Can someone who knows more about this shed some light on this? Is there a
> way to go with
> a smaller initial stack-size without changing the maximum size?
>

It may be simpler to approach the question from the other side, i.e. is
there anything that actually ever needs more than 1MB of stack space? If
there is, I haven't seen it in the decade since I've been using this tweak
with various Fedora derived distributions.
___
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: Request for write permission of menu-cache in Fedora

[Zamir SUN]

Ping for updates.

On 7/23/19 8:51 PM, Zamir SUN wrote:
> Ping for updates.
> 
> I've build menu-cach 1.1.0 in Copr and already tested against LXQt.
> 
> If you are not willing to grant me write permission, can you build this
> in EPEL directly?
> 
> https://copr.fedorainfracloud.org/coprs/zsun/epel7/build/948489/
> 
> On 7/15/19 1:58 PM, Zamir SUN wrote:
>> Ping for updates.
>>
>> On Thu, Jul 11, 2019 at 10:59 PM Zamir SUN  wrote:
>>>
>>> Hi Christoph,
>>>
>>> I am the current maintainer of Fedora LXQt spin. Recently I am updating
>>> LXQt in EPEL and I found that I need menu-cache 1.1.0 in EPEL. I filed a
>>> bug there[1] but no updates. I checked and see only LXQt uses menu-cache
>>> in EPEL, so can you please grant me write permission of menu-cache, so
>>> that I can update it in EPEL myself?
>>>
>>> Thanks.
>>>
>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1724495
>>> --
>>> Zamir SUN
>>> Fedora user
>>> GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
> 

-- 
Zamir SUN
Fedora user
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
___
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: Better interactivity in low-memory situations

[Dridi Boukelmoune]

> It may be simpler to approach the question from the other side, i.e. is there 
> anything that actually ever needs more than 1MB of stack space? If there is, 
> I haven't seen it in the decade since I've been using this tweak with various 
> Fedora derived distributions.

Any application allowing arbitrary regular expressions and/or regex
input using libpcre...

Dridi
___
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: Better interactivity in low-memory situations

[Kevin Kofler]

Gordan Bobic wrote:
> It may be simpler to approach the question from the other side, i.e. is
> there anything that actually ever needs more than 1MB of stack space? If
> there is, I haven't seen it in the decade since I've been using this tweak
> with various Fedora derived distributions.

I've more than once had Java applications crash with a StackOverflowError 
because Java has such a retarded 1 MiB default stack size independently of 
the amount of available RAM. (You have to explicitly use the -Xss parameter 
to get more.) It happened at least once in Java code and at least once in 
C++ code interfaced through JNI.

So I don't think 1 MiB is a reasonable default stack size for
general-purpose computers, though it might make sense on ARM.

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: Better interactivity in low-memory situations

[Kevin Kofler]

Gordan Bobic wrote:
> Adding -ffunction-sections -fdata-sections to defaults can help
> considerably in producing smaller binaries, and is not the default.
> Linking with -Wl,--gc-sections helps a lot and is not the default

Well, -ffunction-sections -fdata-sections -Wl,--gc-sections mostly helps if 
the binary contains a lot of unused code. This is not often the case in 
dynamically linked executables or shared libraries. Where it typically 
happens is statically linked binaries (where the static libraries contain 
APIs not used by the statically linked executable), and even there only if 
the library is not actually designed for static linking (in which case it 
would put separate APIs into separate compilation units to begin with). And 
static linking is a bad idea for RAM consumption anyway, at least on 
GNU/Linux where dynamically linked executables actually share the code 
sections of shared libraries in RAM too, not just on disk.

So I'm afraid you will probably find those options to be less useful in 
practice than you expect.

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: Better interactivity in low-memory situations

[Gordan Bobic]

On Sun, Aug 18, 2019 at 8:51 PM Kevin Kofler  wrote:

> Gordan Bobic wrote:
> > It may be simpler to approach the question from the other side, i.e. is
> > there anything that actually ever needs more than 1MB of stack space? If
> > there is, I haven't seen it in the decade since I've been using this
> tweak
> > with various Fedora derived distributions.
>
> I've more than once had Java applications crash with a StackOverflowError
> because Java has such a retarded 1 MiB default stack size independently of
> the amount of available RAM. (You have to explicitly use the -Xss
> parameter
> to get more.) It happened at least once in Java code and at least once in
> C++ code interfaced through JNI.
>
> So I don't think 1 MiB is a reasonable default stack size for
> general-purpose computers, though it might make sense on ARM.
>

Right, but is it better that _everything_ else suffers with more memory
pressure for the handful of relatively infrequent use cases for which
ulimit can be used to explicitly raise the limit?
___
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: Better interactivity in low-memory situations

[Kevin Kofler]

Gordan Bobic wrote:
> Right, but is it better that _everything_ else suffers with more memory
> pressure for the handful of relatively infrequent use cases for which
> ulimit can be used to explicitly raise the limit?

Well, as I wrote, a lower limit might actually make sense on ARM. But modern 
x86 computers have gigabytes of RAM, so 1 MiB is ridiculously small there. 
So this would have to be an architecture-specific setting for ARM.

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: Better interactivity in low-memory situations

[Gordan Bobic]

On Sun, Aug 18, 2019 at 9:07 PM Kevin Kofler  wrote:

> Gordan Bobic wrote:
> > Right, but is it better that _everything_ else suffers with more memory
> > pressure for the handful of relatively infrequent use cases for which
> > ulimit can be used to explicitly raise the limit?
>
> Well, as I wrote, a lower limit might actually make sense on ARM. But
> modern
> x86 computers have gigabytes of RAM, so 1 MiB is ridiculously small there.
> So this would have to be an architecture-specific setting for ARM.


That may be so, but this thread started off with memory pressure also being
an issue for regular desktop x86 use.
___
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: Better interactivity in low-memory situations

[Chris Murphy]

On Sun, Aug 18, 2019 at 2:55 PM Gordan Bobic  wrote:
>
> On Sun, Aug 18, 2019 at 9:07 PM Kevin Kofler  wrote:
>>
>> Gordan Bobic wrote:
>> > Right, but is it better that _everything_ else suffers with more memory
>> > pressure for the handful of relatively infrequent use cases for which
>> > ulimit can be used to explicitly raise the limit?
>>
>> Well, as I wrote, a lower limit might actually make sense on ARM. But modern
>> x86 computers have gigabytes of RAM, so 1 MiB is ridiculously small there.
>> So this would have to be an architecture-specific setting for ARM.
>
>
> That may be so, but this thread started off with memory pressure also being 
> an issue for regular desktop x86 use.
>

I think optimizations like this, and including compile time defaults
should get smarter to do such optimizations and have a lot of
intrinsic value. But in any case, I think it's fair to say that we're
in very broad agreement that no matter what options get used or what
optimization do or don't happen, unprivileged processes should not be
able to effectively take down the system. That to me is really
incredible to discover.

Everything else: no swap at all and tolerate abrupt and random
oom-killer killoffs, double the swap or use /dev/zram, or use 1/4 RAM
for swap, or throw a metric f ton of RAM at it, all of those are
different ways of dodging a cannon ball. Dodging the problem doesn't
actually fix the problem.Iff your dodge doesn't work out, you get hit
by a cannon ball. Not OK. It's an unprivileged task! I'm aghast.


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

Fedora-29-updates-testing-20190819.0 compose check report

[Fedora compose checker]

Missing expected images:

Atomichost raw-xz x86_64
Atomichost qcow2 x86_64

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

Re: Better interactivity in low-memory situations

[Emery Berger]

For what it's worth, my research group attacked basically exactly this
problem quite some time ago. We built a modified Linux kernel that we
called Redline that was impervious to fork bombs, malloc bombs, and so on.
No process could take down the system, much less unprivileged ones. I think
some of the ideas we described back then would be worth adopting / adapting
today (the code is of course hopelessly out of date: we published our paper
on this at OSDI 2008).

We had a demo where we would run two identical systems, side by side, with
the same workloads (a number of videos playing simultaneously), but with
one running Redline, and the other running stock Linux. We would launch a
fork/malloc bomb on both. The Redline system barely hiccuped. The stock
Linux kernel would freeze and become totally unresponsive (or panic). It
was a great demo, but also a pain, since we invariably had to restart the
stock Linux box :).

Redline: first class support for interactivity in commodity operating
systems

While modern workloads are increasingly interactive and resource-intensive
(e.g., graphical user interfaces, browsers, and multimedia players),
current operating systems have not kept up. These operating systems, which
evolved from core designs that date to the 1970s and 1980s, provide good
support for batch and command-line applications, but their ad hoc attempts
to handle interactive workloads are poor. Their best-effort, priority-based
schedulers provide no bounds on delays, and their resource managers (e.g.,
memory managers and disk I/O schedulers) are mostly oblivious to response
time requirements. Pressure on any one of these resources can significantly
degrade application responsiveness.

We present Redline, a system that brings first-class support for
interactive applications to commodity operating systems. Redline works with
unaltered applications and standard APIs. It uses lightweight
specifications to orchestrate memory and disk I/O management so that they
serve the needs of interactive applications. Unlike realtime systems that
treat specifications as strict requirements and thus pessimistically limit
system utilization, Redline dynamically adapts to recent load, maximizing
responsiveness and system utilization. We show that Redline delivers
responsiveness to interactive applications even in the face of extreme
workloads including fork bombs, memory bombs and bursty, large disk I/O
requests, reducing application pauses by up to two orders of magnitude.

Paper here:

https://www.usenix.org/legacy/events/osdi08/tech/full_papers/yang/yang.pdf

And links to code here:

https://emeryberger.com/research/redline/

There has been some recent follow-on work in this direction: see this work
out of Remzi and Andrea's lab at Wisconsin:
http://pages.cs.wisc.edu/~remzi/Classes/739/Fall2016/Papers/splitio-sosp15.pdf

-- emery

--
Professor Emery Berger
College of Information and Computer Sciences
University of Massachusetts Amherst
www.emeryberger.org, @emeryberger


On Sun, Aug 18, 2019 at 2:53 PM Chris Murphy 
wrote:

> On Sun, Aug 18, 2019 at 2:55 PM Gordan Bobic  wrote:
> >
> > On Sun, Aug 18, 2019 at 9:07 PM Kevin Kofler 
> wrote:
> >>
> >> Gordan Bobic wrote:
> >> > Right, but is it better that _everything_ else suffers with more
> memory
> >> > pressure for the handful of relatively infrequent use cases for which
> >> > ulimit can be used to explicitly raise the limit?
> >>
> >> Well, as I wrote, a lower limit might actually make sense on ARM. But
> modern
> >> x86 computers have gigabytes of RAM, so 1 MiB is ridiculously small
> there.
> >> So this would have to be an architecture-specific setting for ARM.
> >
> >
> > That may be so, but this thread started off with memory pressure also
> being an issue for regular desktop x86 use.
> >
>
> I think optimizations like this, and including compile time defaults
> should get smarter to do such optimizations and have a lot of
> intrinsic value. But in any case, I think it's fair to say that we're
> in very broad agreement that no matter what options get used or what
> optimization do or don't happen, unprivileged processes should not be
> able to effectively take down the system. That to me is really
> incredible to discover.
>
> Everything else: no swap at all and tolerate abrupt and random
> oom-killer killoffs, double the swap or use /dev/zram, or use 1/4 RAM
> for swap, or throw a metric f ton of RAM at it, all of those are
> different ways of dodging a cannon ball. Dodging the problem doesn't
> actually fix the problem.Iff your dodge doesn't work out, you get hit
> by a cannon ball. Not OK. It's an unprivileged task! I'm aghast.
>
>
> --
> 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/Ma

Re: Fedora-29-updates-testing-20190819.0 compose check report

[Sinny Kumari]

>From the build logs [1] [2] , it looks like disk got full which could be
builder specific. We can dig in more if it happens again.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=37134473
[2]
https://kojipkgs.fedoraproject.org//work/tasks/4473/37134473/screenshot.ppm

On Mon, Aug 19, 2019 at 8:33 AM Fedora compose checker <
rawh...@fedoraproject.org> wrote:

> Missing expected images:
>
> Atomichost raw-xz x86_64
> Atomichost qcow2 x86_64
>
> Passed openQA tests: 2/2 (x86_64)
> --
> Mail generated by check-compose:
> https://pagure.io/fedora-qa/check-compose
> ___
> Atomic Working Group mailing list -- ato...@lists.fedoraproject.org
> To unsubscribe send an email to atomic-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/ato...@lists.fedoraproject.org
>


-- 
http://sinny.io/
___
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: when will bodhi (updates) recognize fc31/f31 updates

[Clement Verna]

On Thu, 15 Aug 2019 at 22:33, Kevin Fenzi  wrote:
>
> On 8/15/19 7:44 AM, Alexander Bokovoy wrote:
> > On to, 15 elo 2019, Kaleb Keithley wrote:
> >> On Thu, Aug 15, 2019 at 10:21 AM Alexander Bokovoy 
> >> wrote:
> >>
> >>> On to, 15 elo 2019, Kaleb Keithley wrote:
> >>> >I've tried to submit a build on f31 to testing, using both the cli
> >>> and via
> >>> >the web site, and both are failing
> >>> >
> >>> >On the web site I get a popup with: Builds : Cannot find release
> >>> associated
> >>> >with build: nfs-ganesha-2.8.2-5.fc31, tags: ['f31']
> >>> >
> >>> >fedpkg update gets: Could not execute update: Could not generate update
> >>> >request: Cannot find release associated with build:
> >>> >nfs-ganesha-2.8.2-5.fc31, tags: ['f31']
> >>> My understanding is that F31 doesn't need bodhi right now -- all
> >>> packages built for it appear in the distro, as with rawhide before.
> >>>
> >>> Branched will get bodhi activated later this month.
> >>>
> >>
> >> Well, it's confusing (to me anyway), because before branching, new
> >> f31/rawhide builds showed up automatically as "stable" in bodhi.
> >>
> >> And now new f32/rawhide builds show up automatically as "stable."
> >>
> >> Making me wonder what is status of the new f31 build(s) I've just done?
> >> They don't show up in bodhi at all.
> > Yes, Bodhi activation for a Branched is marked in the schedule
> > separately. This was noted in the mass branching email:
> >
> > --
> > Bodhi is currently not active for Fedora 31, it will be enabled in
> > couple of weeks time when we hit Beta change freeze point in the Fedora
> > 31 schedule[1].
> >
> > [1] https://fedoraproject.org/wiki/Releases/31/Schedule
> > --
> >
> > A confusion is probably because at the same time Gating in Rawhide was
> > introduced. Gating in Rawhide relies on Bodhi, so there is Bodhi for
> > F32. I think we could have made Bodhi for F31 with automated acceptance
> > of the packages more visible but it might have been postponed to the
> > "Bodhi activation point" altogether.
>
> Yeah, it's been confusing for sure. :(
>
> Right now rawhide (f32) is doing gating as it was before.
>
> Branched (f31) is acting like rawhide used to, pre gating (ie, builds
> are just signed and added)

I just opened a PR to the releng SOP
(https://pagure.io/releng/pull-request/8651), so that the branched
release (f31) behave like rawhide in bodhi (Gated) until we activate
it properly (2 weeks after branching).

>
> I would expect branched to also do gating, so I think we should move it
> to that.
>
> Or, we could just decide to enable bodhi for good at branching. The
> reason we didn't do this before was that its more stuff for releng to
> deal with at branching, and the 2 weeks give people time to get builds
> in fast to finish up things they know for sure they want to get into the
> branched release. It might just be a lot less confusing to enable it tho.
>
> 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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[Joseph D. Wagner]

On 2019-08-18 02:57, Vitaly Zaitsev via devel wrote:


On 18.08.2019 2:24, Joseph D. Wagner wrote:

The Plymouth LUKS password prompt will wait FOREVER for me to type in 
a

password


This is intended, because system is not even started yet on
LUKS-encrypted media attach stage.


It is intended to display the same image on the screen continuously 
until I suffer from screen burn-in?



If you don't want to enter LUKS password on every boot, you should use
TPM or hardware tokens.


My issue is not with waiting forever on the password prompt. My issue is 
with displaying the same password prompt forever, causing screen 
burn-in.  There are unexpected reboots, like crashes and dual-boot 
systems where a non-default OS decides to automatically reboot for 
updates, only for the reboot to go into the default with LUKS.


Joseph D. Wagner
___
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