Re: Help with a font package

[Parag Nemade]

Hi,

On Wed, Sep 23, 2015 at 8:43 AM, Jerry James  wrote:
> I've got a package that has started bundling a font, namely Roboto
> Slab.  I'd like to do things the right way and make this a separate
> package, but I've never done a font package before and could use a
> little hand holding.
>
> The home page for this font seems to be
> https://www.google.com/fonts/specimen/Roboto+Slab, but there are no
> download links anywhere that I can see.  I looked at the existing
> google-robot-fonts package to try to get some clues.  That one shows a
> download link from developer.android.com, but it requires knowing a
> version number, which isn't anywhere on the home page.  It also
> contains some mysterious fontconfig and xml files that I don't
> understand ... and I think I'm already in over my head.  I don't even
> know how to start with this.  If anybody has words of wisdom for me,
> I'd appreciate them very much.
>
> Or, better yet, someone with experience can package the font for me,
> and tell me what bribe I can send to you in the mail to make it worth
> your while. :-)

There is already a good documentation available on Fedora Wiki about
font packaging[1] [2] then we have Fedora fonts mailing lists then IRC
channel #fedora-g11n where you can get help.

I have packaged this font and submitted its review now ->
https://bugzilla.redhat.com/show_bug.cgi?id=1265484

You may want to review it ;-)

Regards,
Parag.

[1] https://fedoraproject.org/wiki/Packaging:FontsPolicy
[2] https://fedoraproject.org/wiki/Fontconfig_packaging_tips
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Help with a font package

[Christopher Meng]

Personally hate Google's way on open source, especially distribution.
This font is intended to be used in Google Keep, however it's not
included in roboto family.

Here is the link to the source:

https://github.com/google/fonts/tree/master/apache/robotoslab

-- 

Yours sincerely,
Christopher Meng

http://awk.io
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Help with a font package

[Jerry James]

I've got a package that has started bundling a font, namely Roboto
Slab.  I'd like to do things the right way and make this a separate
package, but I've never done a font package before and could use a
little hand holding.

The home page for this font seems to be
https://www.google.com/fonts/specimen/Roboto+Slab, but there are no
download links anywhere that I can see.  I looked at the existing
google-robot-fonts package to try to get some clues.  That one shows a
download link from developer.android.com, but it requires knowing a
version number, which isn't anywhere on the home page.  It also
contains some mysterious fontconfig and xml files that I don't
understand ... and I think I'm already in over my head.  I don't even
know how to start with this.  If anybody has words of wisdom for me,
I'd appreciate them very much.

Or, better yet, someone with experience can package the font for me,
and tell me what bribe I can send to you in the mail to make it worth
your while. :-)

Thanks,
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Announcing the release of Fedora 23 Beta!

[Ralf Corsepius]

On 09/22/2015 07:33 PM, Matthew Miller wrote:

On Tue, Sep 22, 2015 at 06:21:00PM +0100, Pádraig Brady wrote:

I just used dnf distro-sync as per:
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_22_-.3E_Fedora_23

This went fine, and I'm now typing this on F23 beta.
What are the main advantages of system-upgrade?
Should the above wiki mention the system-uprade instructions?


There's actually a "fedup" script as part of the package. I think we
should update the dnf-plugin-system-upgrade to Provide: fedup, and keep
the instructions the same. Rationale:


IMO, this discussion is moot.

Because ppckaging-wise, the dnf-plugin-system-upgrade situation 
currently is broken [1]:


dnf-plugin-system-upgrade Obsoletes: fedup, but lacks the corresponding 
Provides.


The result is
- "dnf install fedup" installs fedup
- subsequent "dnf update" kicks out fedup and replaces it with 
dnf-plugin-system-upgrade.


Ralf

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1264937
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Heads up: glibmm/gtkmm now requires -std=c++11

[Josh Stone]

On 09/22/2015 05:49 PM, Mamoru TASAKA wrote:
> Kalev Lember wrote on 09/23/2015 09:35 AM:
>> Hi,
>>
>> A quick heads up to anybody who might run into cryptic build errors when
>> building apps that use glibmm/gtkmm:
>>
>> Latest glibmm/gtkmm stack in rawhide and F23 now uses C++11 features in
>> header files. This means when building other programs that use those
>> headers, the C++ compiler needs to be in C++11 mode now.
>>
>> The fix is simple: make sure -std=c++11 is passed to the compiler.
>>
>> It can be done in either in upstream build scripts or hacked in
>> downstream in spec files. I would usually always suggest to go for
>> upstreamable fixes, but I think in this case it's fine to do it
>> downstream as well. The reason is that the workaround is just a
>> temporary measure until GCC switches to use C++11 by default, which is
>> probably going to happen in F24 when GCC 6 lands.
>>
>> Here's an example how to do it in a spec file:
>> http://pkgs.fedoraproject.org/cgit/inkscape.git/commit/?id=fc745c8687dd8a362235340bd3481ff18925dbaf
>>
>> And here's how to do it in an upstreamable way:
>> https://git.gnome.org/browse/gnome-system-monitor/commit/?id=e5d3ac014d7acc73c5f508a937c5656ffa8f08ad
>> or
>> https://git.gnome.org/browse/gnome-system-monitor/commit/?id=d81fe60bc3d6a481b6bc330490fd079b5cc30acc
> 
> Rather, can't be pkgconfig file in gtkmm30 modified for now to add -std=c++11
> to Cflags?

I'd guess that they really require *at least* c++11.

A project might instead choose gnu++11, c++14, gnu++14, etc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Heads up: glibmm/gtkmm now requires -std=c++11

[Mamoru TASAKA]

Kalev Lember wrote on 09/23/2015 09:35 AM:

Hi,

A quick heads up to anybody who might run into cryptic build errors when
building apps that use glibmm/gtkmm:

Latest glibmm/gtkmm stack in rawhide and F23 now uses C++11 features in
header files. This means when building other programs that use those
headers, the C++ compiler needs to be in C++11 mode now.

The fix is simple: make sure -std=c++11 is passed to the compiler.

It can be done in either in upstream build scripts or hacked in
downstream in spec files. I would usually always suggest to go for
upstreamable fixes, but I think in this case it's fine to do it
downstream as well. The reason is that the workaround is just a
temporary measure until GCC switches to use C++11 by default, which is
probably going to happen in F24 when GCC 6 lands.

Here's an example how to do it in a spec file:
http://pkgs.fedoraproject.org/cgit/inkscape.git/commit/?id=fc745c8687dd8a362235340bd3481ff18925dbaf

And here's how to do it in an upstreamable way:
https://git.gnome.org/browse/gnome-system-monitor/commit/?id=e5d3ac014d7acc73c5f508a937c5656ffa8f08ad
or
https://git.gnome.org/browse/gnome-system-monitor/commit/?id=d81fe60bc3d6a481b6bc330490fd079b5cc30acc


Rather, can't be pkgconfig file in gtkmm30 modified for now to add -std=c++11
to Cflags?

Regards,
Mamoru


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Heads up: glibmm/gtkmm now requires -std=c++11

[Kalev Lember]

Hi,

A quick heads up to anybody who might run into cryptic build errors when
building apps that use glibmm/gtkmm:

Latest glibmm/gtkmm stack in rawhide and F23 now uses C++11 features in
header files. This means when building other programs that use those
headers, the C++ compiler needs to be in C++11 mode now.

The fix is simple: make sure -std=c++11 is passed to the compiler.

It can be done in either in upstream build scripts or hacked in
downstream in spec files. I would usually always suggest to go for
upstreamable fixes, but I think in this case it's fine to do it
downstream as well. The reason is that the workaround is just a
temporary measure until GCC switches to use C++11 by default, which is
probably going to happen in F24 when GCC 6 lands.

Here's an example how to do it in a spec file:
http://pkgs.fedoraproject.org/cgit/inkscape.git/commit/?id=fc745c8687dd8a362235340bd3481ff18925dbaf

And here's how to do it in an upstreamable way:
https://git.gnome.org/browse/gnome-system-monitor/commit/?id=e5d3ac014d7acc73c5f508a937c5656ffa8f08ad
or
https://git.gnome.org/browse/gnome-system-monitor/commit/?id=d81fe60bc3d6a481b6bc330490fd079b5cc30acc

-- 
Kalev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Announcing the release of Fedora 23 Beta!

[Adam Williamson]

On Tue, 2015-09-22 at 17:38 -0500, Richard Shaw wrote:
> On an related note...
> 
> I just tried doing a "dnf --enablerepo=updates testing update fedup"
> on my
> Fedora 21 box and fedup was replaced by the dnf upgrade plugin so the
> information at:
> 
> https://fedoraproject.org/wiki/Upgrading
> 
> Is no longer correct, the dnf upgrade method should be used to
> upgrade
> F21+, not F22+.

I'm not sure we've actually tested it for upgrades to F22, but since
fedup is gone there really isn't much choice :) I'll re-jig the page
again later.
-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Announcing the release of Fedora 23 Beta!

[Richard Shaw]

On an related note...

I just tried doing a "dnf --enablerepo=updates testing update fedup" on my
Fedora 21 box and fedup was replaced by the dnf upgrade plugin so the
information at:

https://fedoraproject.org/wiki/Upgrading

Is no longer correct, the dnf upgrade method should be used to upgrade
F21+, not F22+.

Thanks,
Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Simo Sorce]

On Tue, 2015-09-22 at 16:58 -0500, kendell clark wrote:
> hi
> Oops? My apologies. I didn't mean to accuse anyone in particular of
> causing my problem. It makes it easier if someone either top or bottom
> posts, but I'm certainly not going to insist on it. I also need to
> figure out how to just reply to the list, rather than to the person who
> sent the message as well as the list. Maybe I should've read my message
> through better before sending, I didn't mean to accuse anyone of
> anything or sound irritable.

No problem, but replying to a specific message tends to carry a meaning
in mailing lists, that's why I pointed it out to you. I did not mean
that I actually am irritated, sorry for the cryptic response on that
part.

On the reply style, it is pretty useful to most of us to get inline
replies in most cases because then you know exactly what has been
replied to. Our clients of choice tend to handle quotation well, and
display it in a manner that makes immediately clear what it is being
responded to.

Perhaps you need to find a way (or a client) that makes it easy for you
to separate quoted text from normal text. I assure you that being able
to just skip back a few lines and read the quoted context of the reply
is often very valuable.

Simo.

> Thanks
> Kendell clark
> 
> 
> On 09/22/2015 04:51 PM, Simo Sorce wrote:
> > On Tue, 2015-09-22 at 16:31 -0500, kendell clark wrote:
> >> hi
> >> Just a polite request. I'm having trouble following the thread because
> >> there are so many intermingled responses, with different bits of it
> >> quoted and commented on. Would everyone mind putting their responses
> >> either on the top or the bottom of the message? Top would be better for
> >> me, but I also don't want to irritate anyone, since I've been yelled at
> >> on the arch list for top posting, even though as a blind person it makes
> >> following messages, especially long threads like this, easier.
> >> Sorry for the OT
> > 
> > This list traditionally follows the good rule of *not* top-posting, and
> > commenting inline.
> > 
> > You are the only one top-posting and breaking the thread as far as I can
> > see. You also commented on a sub-thread that had no top-posting
> > whatsoever and seem perfectly understandable, and replied to my post as
> > if I was the cause of your trouble (which doesn't seem so from the
> > content of your post), so your comment may come a little bit irritating.
> > 
> > It sucks that gmail has poor threading support and confuses you, but you
> > chose that tool, maybe you can find something better.
> > 
> > Simo.
> > 
> >>
> >>
> >> On 09/22/2015 01:29 PM, Simo Sorce wrote:
> >>> On Tue, 2015-09-22 at 09:56 -0400, Matthias Clasen wrote:
>  On Tue, 2015-09-22 at 15:51 +0200, Lennart Poettering wrote:
> > On Thu, 17.09.15 20:59, Germano Massullo (germano.massu...@gmail.com)
> > wrote:
> >
> >> Today I had a scary experience with the audio of my computer.
> >> I was listening to music with Amarok, using my headphones... The
> >> KMix
> >> volume level was ~ 35%. When I logged into a video conference
> >> application, the volume suddenly reached the 100%. I was shocked,
> >> having
> >> the maximum audio level shooted in your ears is a painful
> >> experience.
> >> The conference application that triggered PulseAudio pushing volume
> >> to
> >> maximum level probably should have never asked the system for a
> >> 100%
> >> audio level, but on the other hand, PulseAudio should never allow
> >> an
> >> application to make such sudden changes.
> >> To avoid that, you have to set
> >> flat-volumes = no
> >> in /etc/pulse/daemon.conf
> >
> > This is a non-sensical request. If an app uses the mixer APIs to set
> > the volume of something to very loud, that's what happens. Flat
> > volumes have nothing to do with that.
> >
> > I mean, the app you are using shouldn't set the volume like this, and
> > that's the key here. If you turn off flat volumes you win about
> > nothing, you just work around this specific app. Soon the next app
> > will come along and play the same game with the actual device volume,
> > and you won *zero*.
> >
> > Don't mix flat volumes with misbheaving apps. Turning off flat
> > volumes
> > is a hack around the broken apps at best, and completely pointless..
> 
>  For better or worse, misbehaving apps are a reality that is probably
>  not going to go away... I think we need to have a volume control
>  approach that is at least somewhat tolerant against such apps and has
>  some safeguards.
> >>>
> >>> Indeed, sticking your head in the sand and saying it is a misbehaving
> >>> app is not a useful answer.
> >>>
> >>> Apps misbehave, its a fact of life, you can deal with it, or not deal
> >>> with it, if you do not deal with it you have a bad system that causes
> >>> grief.
> >>>
> >>> I disabled flat-volu

Re: Announcing the release of Fedora 23 Beta!

[Adam Williamson]

On Tue, 2015-09-22 at 13:33 -0400, Matthew Miller wrote:
> On Tue, Sep 22, 2015 at 06:21:00PM +0100, Pádraig Brady wrote:
> > I just used dnf distro-sync as per:
> > https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_22
> > _-.3E_Fedora_23
> > 
> > This went fine, and I'm now typing this on F23 beta.
> > What are the main advantages of system-upgrade?
> > Should the above wiki mention the system-uprade instructions?
> 
> There's actually a "fedup" script as part of the package. I think we
> should update the dnf-plugin-system-upgrade to Provide: fedup, and
> keep
> the instructions the same. Rationale:

Sorry, but I already re-did all the wiki pages last week. Of course we
can change them again, but...

https://fedoraproject.org/wiki/Upgrading was revised to list dnf-
system-upgrade as the 'recommended method' for upgrades to F23, and I
wrote https://fedoraproject.org/wiki/DNF_system_upgrade documenting
how to use it.

The page Padraig linked to was not about fedup at all, it's the page
for doing your upgrades just using bare yum/dnf (which is not
officially supported, but we do have that page for known caveats and
best practices if you really must do it).
-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Announcing the release of Fedora 23 Beta!

[Adam Williamson]

On Tue, 2015-09-22 at 18:21 +0100, Pádraig Brady wrote:
> On 22/09/15 18:02, Stephen Gallagher wrote:
> > On Tue, 2015-09-22 at 12:13 -0400, Eric Griffith wrote:
> > > Suggested way to upgrade from 22 to 23? Fresh install? Fedup?
> > > Change
> > > release ver  for dnf? Did the new dnf upgrade tool get packaged?
> > 
> > `dnf install dnf-plugin-system-upgrade`
> > `dnf system-upgrade download --releasever=23`
> > `dnf system-upgrade reboot`
> 
> I see the above has replaced fedup:
> https://fedoraproject.org/wiki/Changes/DNF_System_Upgrades
> 
> I just used dnf distro-sync as per:
> https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_22_-
> .3E_Fedora_23
> 
> This went fine, and I'm now typing this on F23 beta.
> What are the main advantages of system-upgrade?
> Should the above wiki mention the system-uprade instructions?

It does. There's a big yellow box at the top which says:

"Although upgrades with yum do work, they are not explicitly tested as
part of the release process by Fedora QA and are not documented in the
Fedora installation guide.  If you are not prepared to resolve issues
on your own if things break, you should probably use the recommended
installation methods instead."

Where 'recommended installation methods' is a link to
https://fedoraproject.org/wiki/Upgrading , which in turn points to
https://fedoraproject.org/wiki/DNF_system_upgrade .
-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Reindl Harald]

Am 22.09.2015 um 23:58 schrieb kendell clark:

Oops? My apologies. I didn't mean to accuse anyone in particular of
causing my problem. It makes it easier if someone either top or bottom
posts


no it does not, nobody needs the whole thread in each message

see my reponse - the context is very clear - how do you know to which of 
your sentecnes i reply if i put both parts just on top?



but I'm certainly not going to insist on it. I also need to
figure out how to just reply to the list, rather than to the person who
sent the message as well as the list


get a mail-client which supports basic things like mail headers instead 
all this shitty webmail-crap would be a start


thunderbird just offers a "reply-to-list" button on any ML aslong 
sombody don't break it by "reply-all" with personal copies


List-Post: 
Reply-To: Development discussions related to Fedora





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[kendell clark]

hi
Oops? My apologies. I didn't mean to accuse anyone in particular of
causing my problem. It makes it easier if someone either top or bottom
posts, but I'm certainly not going to insist on it. I also need to
figure out how to just reply to the list, rather than to the person who
sent the message as well as the list. Maybe I should've read my message
through better before sending, I didn't mean to accuse anyone of
anything or sound irritable.
Thanks
Kendell clark


On 09/22/2015 04:51 PM, Simo Sorce wrote:
> On Tue, 2015-09-22 at 16:31 -0500, kendell clark wrote:
>> hi
>> Just a polite request. I'm having trouble following the thread because
>> there are so many intermingled responses, with different bits of it
>> quoted and commented on. Would everyone mind putting their responses
>> either on the top or the bottom of the message? Top would be better for
>> me, but I also don't want to irritate anyone, since I've been yelled at
>> on the arch list for top posting, even though as a blind person it makes
>> following messages, especially long threads like this, easier.
>> Sorry for the OT
> 
> This list traditionally follows the good rule of *not* top-posting, and
> commenting inline.
> 
> You are the only one top-posting and breaking the thread as far as I can
> see. You also commented on a sub-thread that had no top-posting
> whatsoever and seem perfectly understandable, and replied to my post as
> if I was the cause of your trouble (which doesn't seem so from the
> content of your post), so your comment may come a little bit irritating.
> 
> It sucks that gmail has poor threading support and confuses you, but you
> chose that tool, maybe you can find something better.
> 
> Simo.
> 
>>
>>
>> On 09/22/2015 01:29 PM, Simo Sorce wrote:
>>> On Tue, 2015-09-22 at 09:56 -0400, Matthias Clasen wrote:
 On Tue, 2015-09-22 at 15:51 +0200, Lennart Poettering wrote:
> On Thu, 17.09.15 20:59, Germano Massullo (germano.massu...@gmail.com)
> wrote:
>
>> Today I had a scary experience with the audio of my computer.
>> I was listening to music with Amarok, using my headphones... The
>> KMix
>> volume level was ~ 35%. When I logged into a video conference
>> application, the volume suddenly reached the 100%. I was shocked,
>> having
>> the maximum audio level shooted in your ears is a painful
>> experience.
>> The conference application that triggered PulseAudio pushing volume
>> to
>> maximum level probably should have never asked the system for a
>> 100%
>> audio level, but on the other hand, PulseAudio should never allow
>> an
>> application to make such sudden changes.
>> To avoid that, you have to set
>> flat-volumes = no
>> in /etc/pulse/daemon.conf
>
> This is a non-sensical request. If an app uses the mixer APIs to set
> the volume of something to very loud, that's what happens. Flat
> volumes have nothing to do with that.
>
> I mean, the app you are using shouldn't set the volume like this, and
> that's the key here. If you turn off flat volumes you win about
> nothing, you just work around this specific app. Soon the next app
> will come along and play the same game with the actual device volume,
> and you won *zero*.
>
> Don't mix flat volumes with misbheaving apps. Turning off flat
> volumes
> is a hack around the broken apps at best, and completely pointless..

 For better or worse, misbehaving apps are a reality that is probably
 not going to go away... I think we need to have a volume control
 approach that is at least somewhat tolerant against such apps and has
 some safeguards.
>>>
>>> Indeed, sticking your head in the sand and saying it is a misbehaving
>>> app is not a useful answer.
>>>
>>> Apps misbehave, its a fact of life, you can deal with it, or not deal
>>> with it, if you do not deal with it you have a bad system that causes
>>> grief.
>>>
>>> I disabled flat-volumes long ago for the same reasons people had to in
>>> this thread. Yes in theory I can beg every app to be perfect, but in the
>>> mean time I can't get my ears blasted (or in some cases end up with
>>> un-audible input/output). whatever it is with flat-volumes I could never
>>> figure out what was going on, while w/o flat-volumes it is very simple
>>> as each app is individually either low or high and an app raising its
>>> volume doesn't cause all other apps to disappear never to return ...
>>>
>>> Disabling flat-volumes may be a workaround but it works very well
>>> apparently. So something probably needs to be improved in flat-volumes,
>>> and until then it is as good an option to disable it by default.
>>>
>>> Simo.
>>>
> 
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Simo Sorce]

On Tue, 2015-09-22 at 16:31 -0500, kendell clark wrote:
> hi
> Just a polite request. I'm having trouble following the thread because
> there are so many intermingled responses, with different bits of it
> quoted and commented on. Would everyone mind putting their responses
> either on the top or the bottom of the message? Top would be better for
> me, but I also don't want to irritate anyone, since I've been yelled at
> on the arch list for top posting, even though as a blind person it makes
> following messages, especially long threads like this, easier.
> Sorry for the OT

This list traditionally follows the good rule of *not* top-posting, and
commenting inline.

You are the only one top-posting and breaking the thread as far as I can
see. You also commented on a sub-thread that had no top-posting
whatsoever and seem perfectly understandable, and replied to my post as
if I was the cause of your trouble (which doesn't seem so from the
content of your post), so your comment may come a little bit irritating.

It sucks that gmail has poor threading support and confuses you, but you
chose that tool, maybe you can find something better.

Simo.

> 
> 
> On 09/22/2015 01:29 PM, Simo Sorce wrote:
> > On Tue, 2015-09-22 at 09:56 -0400, Matthias Clasen wrote:
> >> On Tue, 2015-09-22 at 15:51 +0200, Lennart Poettering wrote:
> >>> On Thu, 17.09.15 20:59, Germano Massullo (germano.massu...@gmail.com)
> >>> wrote:
> >>>
>  Today I had a scary experience with the audio of my computer.
>  I was listening to music with Amarok, using my headphones... The
>  KMix
>  volume level was ~ 35%. When I logged into a video conference
>  application, the volume suddenly reached the 100%. I was shocked,
>  having
>  the maximum audio level shooted in your ears is a painful
>  experience.
>  The conference application that triggered PulseAudio pushing volume
>  to
>  maximum level probably should have never asked the system for a
>  100%
>  audio level, but on the other hand, PulseAudio should never allow
>  an
>  application to make such sudden changes.
>  To avoid that, you have to set
>  flat-volumes = no
>  in /etc/pulse/daemon.conf
> >>>
> >>> This is a non-sensical request. If an app uses the mixer APIs to set
> >>> the volume of something to very loud, that's what happens. Flat
> >>> volumes have nothing to do with that.
> >>>
> >>> I mean, the app you are using shouldn't set the volume like this, and
> >>> that's the key here. If you turn off flat volumes you win about
> >>> nothing, you just work around this specific app. Soon the next app
> >>> will come along and play the same game with the actual device volume,
> >>> and you won *zero*.
> >>>
> >>> Don't mix flat volumes with misbheaving apps. Turning off flat
> >>> volumes
> >>> is a hack around the broken apps at best, and completely pointless..
> >>
> >> For better or worse, misbehaving apps are a reality that is probably
> >> not going to go away... I think we need to have a volume control
> >> approach that is at least somewhat tolerant against such apps and has
> >> some safeguards.
> > 
> > Indeed, sticking your head in the sand and saying it is a misbehaving
> > app is not a useful answer.
> > 
> > Apps misbehave, its a fact of life, you can deal with it, or not deal
> > with it, if you do not deal with it you have a bad system that causes
> > grief.
> > 
> > I disabled flat-volumes long ago for the same reasons people had to in
> > this thread. Yes in theory I can beg every app to be perfect, but in the
> > mean time I can't get my ears blasted (or in some cases end up with
> > un-audible input/output). whatever it is with flat-volumes I could never
> > figure out what was going on, while w/o flat-volumes it is very simple
> > as each app is individually either low or high and an app raising its
> > volume doesn't cause all other apps to disappear never to return ...
> > 
> > Disabling flat-volumes may be a workaround but it works very well
> > apparently. So something probably needs to be improved in flat-volumes,
> > and until then it is as good an option to disable it by default.
> > 
> > Simo.
> > 


-- 
Simo Sorce * Red Hat, Inc * New York

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[kendell clark]

hi
Just a polite request. I'm having trouble following the thread because
there are so many intermingled responses, with different bits of it
quoted and commented on. Would everyone mind putting their responses
either on the top or the bottom of the message? Top would be better for
me, but I also don't want to irritate anyone, since I've been yelled at
on the arch list for top posting, even though as a blind person it makes
following messages, especially long threads like this, easier.
Sorry for the OT
Thanks
Kendell clark


On 09/22/2015 01:29 PM, Simo Sorce wrote:
> On Tue, 2015-09-22 at 09:56 -0400, Matthias Clasen wrote:
>> On Tue, 2015-09-22 at 15:51 +0200, Lennart Poettering wrote:
>>> On Thu, 17.09.15 20:59, Germano Massullo (germano.massu...@gmail.com)
>>> wrote:
>>>
 Today I had a scary experience with the audio of my computer.
 I was listening to music with Amarok, using my headphones... The
 KMix
 volume level was ~ 35%. When I logged into a video conference
 application, the volume suddenly reached the 100%. I was shocked,
 having
 the maximum audio level shooted in your ears is a painful
 experience.
 The conference application that triggered PulseAudio pushing volume
 to
 maximum level probably should have never asked the system for a
 100%
 audio level, but on the other hand, PulseAudio should never allow
 an
 application to make such sudden changes.
 To avoid that, you have to set
 flat-volumes = no
 in /etc/pulse/daemon.conf
>>>
>>> This is a non-sensical request. If an app uses the mixer APIs to set
>>> the volume of something to very loud, that's what happens. Flat
>>> volumes have nothing to do with that.
>>>
>>> I mean, the app you are using shouldn't set the volume like this, and
>>> that's the key here. If you turn off flat volumes you win about
>>> nothing, you just work around this specific app. Soon the next app
>>> will come along and play the same game with the actual device volume,
>>> and you won *zero*.
>>>
>>> Don't mix flat volumes with misbheaving apps. Turning off flat
>>> volumes
>>> is a hack around the broken apps at best, and completely pointless..
>>
>> For better or worse, misbehaving apps are a reality that is probably
>> not going to go away... I think we need to have a volume control
>> approach that is at least somewhat tolerant against such apps and has
>> some safeguards.
> 
> Indeed, sticking your head in the sand and saying it is a misbehaving
> app is not a useful answer.
> 
> Apps misbehave, its a fact of life, you can deal with it, or not deal
> with it, if you do not deal with it you have a bad system that causes
> grief.
> 
> I disabled flat-volumes long ago for the same reasons people had to in
> this thread. Yes in theory I can beg every app to be perfect, but in the
> mean time I can't get my ears blasted (or in some cases end up with
> un-audible input/output). whatever it is with flat-volumes I could never
> figure out what was going on, while w/o flat-volumes it is very simple
> as each app is individually either low or high and an app raising its
> volume doesn't cause all other apps to disappear never to return ...
> 
> Disabling flat-volumes may be a workaround but it works very well
> apparently. So something probably needs to be improved in flat-volumes,
> and until then it is as good an option to disable it by default.
> 
> Simo.
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[kendell clark]

hi
If this is true, then why have I had no luck getting PA developers to do
anything? Not to complain, but I've been on their irc channel several
time. If I get a response at all, it's to shrug and tell me to bug
whatever app it is that's misbehaving. This is all well and good if the
app is both free and open source and actively developed, but if one of
those is missing ... I'm not criticizing anyone, at least not on
purpose, but I don't know who's at fault here and how to fix it. If it's
the app, this is going to be tedious, filing the same bug against
multiple apps. If it's pulse audio, then it's the developers'
responsibility to fix it, preferably without passing the buck.
Thanks
Kendell clark


On 09/22/2015 08:51 AM, Lennart Poettering wrote:
> On Thu, 17.09.15 20:59, Germano Massullo (germano.massu...@gmail.com) wrote:
> 
>> Today I had a scary experience with the audio of my computer.
>> I was listening to music with Amarok, using my headphones... The KMix
>> volume level was ~ 35%. When I logged into a video conference
>> application, the volume suddenly reached the 100%. I was shocked, having
>> the maximum audio level shooted in your ears is a painful experience.
>> The conference application that triggered PulseAudio pushing volume to
>> maximum level probably should have never asked the system for a 100%
>> audio level, but on the other hand, PulseAudio should never allow an
>> application to make such sudden changes.
>> To avoid that, you have to set
>> flat-volumes = no
>> in /etc/pulse/daemon.conf
> 
> This is a non-sensical request. If an app uses the mixer APIs to set
> the volume of something to very loud, that's what happens. Flat
> volumes have nothing to do with that.
> 
> I mean, the app you are using shouldn't set the volume like this, and
> that's the key here. If you turn off flat volumes you win about
> nothing, you just work around this specific app. Soon the next app
> will come along and play the same game with the actual device volume,
> and you won *zero*.
> 
> Don't mix flat volumes with misbheaving apps. Turning off flat volumes
> is a hack around the broken apps at best, and completely pointless..
> 
> Lennart
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Additional information in email about Koji garbage collection?

[Kevin Fenzi]

On Tue, 22 Sep 2015 08:13:45 -0700
Dave Johansen  wrote:

> Can I open a ticket requesting this feature enhancement? If so, is
> https://fedorahosted.org/koji/wiki the right place?

Sure.

kevin


pgpgx7prf6ern.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Announcing the release of Fedora 23 Beta!

[Zbigniew Jędrzejewski-Szmek]

On Tue, Sep 22, 2015 at 01:18:30PM -0600, Nathanael D. Noblet wrote:
> On Tue, 2015-09-22 at 13:33 -0400, Matthew Miller wrote:
> > On Tue, Sep 22, 2015 at 06:21:00PM +0100, Pádraig Brady wrote:
> > > I just used dnf distro-sync as per:
> > > https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_22
> > > _-.3E_Fedora_23
> > > 
> > > This went fine, and I'm now typing this on F23 beta.
> > > What are the main advantages of system-upgrade?
> > > Should the above wiki mention the system-uprade instructions?
> > 
> > There's actually a "fedup" script as part of the package. I think we
> > should update the dnf-plugin-system-upgrade to Provide: fedup, and
> > keep
> > the instructions the same. Rationale:
> > 
> > * FedUp has gotten a lot of positive press *just recently*, including
> > this
> >   interview with Jim Whitehurst
> >   http://www.mylinuxrig.com/post/129154618674/the-linux-setup-jim-whi
> > tehurst-presidentceo
> > 
> > * Although the mechanisms are different, the basic concepts,
> >   especially from a user point of view, are very similar
> > 
> > * Documentation won't need (as much) updating
> > 
> > * fedup.sh is already done
> > 
> > * FedUp is an awesome name
> > 
> > * People get all stabby over changes. Let's save getting stabbed for
> >   when we really need it.
> > 
> So I noticed a little while ago fedup on my system was replaced by dnf-
> plugin-system-upgrade. Running fedup gets you the dnf 'this command is
> no longer the one to use use dnf system-upgrade...' I used it and am
> running F23 Beta now. It may be too late. One thing though is I
> searched for fedup first, found the wiki and it has nothing about using
> dnf on it anymore.
> 
> Otherwise it seemed to run fine.
> 
> It didn't however relabel the system during the upgrade which caused a
> few selinux messages. Should it?
I don't think it should: dnf-system-upgrade is just installing rpms.
selinux.rpm has a %postinstall script which does some relabelling.
What files were mislebelled exactly? Maybe you should file a bug
against selinux-policy.

Zbyszek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Announcing the release of Fedora 23 Beta!

[Nathanael D. Noblet]

On Tue, 2015-09-22 at 13:33 -0400, Matthew Miller wrote:
> On Tue, Sep 22, 2015 at 06:21:00PM +0100, Pádraig Brady wrote:
> > I just used dnf distro-sync as per:
> > https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_22
> > _-.3E_Fedora_23
> > 
> > This went fine, and I'm now typing this on F23 beta.
> > What are the main advantages of system-upgrade?
> > Should the above wiki mention the system-uprade instructions?
> 
> There's actually a "fedup" script as part of the package. I think we
> should update the dnf-plugin-system-upgrade to Provide: fedup, and
> keep
> the instructions the same. Rationale:
> 
> * FedUp has gotten a lot of positive press *just recently*, including
> this
>   interview with Jim Whitehurst
>   http://www.mylinuxrig.com/post/129154618674/the-linux-setup-jim-whi
> tehurst-presidentceo
> 
> * Although the mechanisms are different, the basic concepts,
>   especially from a user point of view, are very similar
> 
> * Documentation won't need (as much) updating
> 
> * fedup.sh is already done
> 
> * FedUp is an awesome name
> 
> * People get all stabby over changes. Let's save getting stabbed for
>   when we really need it.
> 
So I noticed a little while ago fedup on my system was replaced by dnf-
plugin-system-upgrade. Running fedup gets you the dnf 'this command is
no longer the one to use use dnf system-upgrade...' I used it and am
running F23 Beta now. It may be too late. One thing though is I
searched for fedup first, found the wiki and it has nothing about using
dnf on it anymore.

Otherwise it seemed to run fine.

It didn't however relabel the system during the upgrade which caused a
few selinux messages. Should it?

-- 
Nathanael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: grub2 wiki page

[Chris Murphy]

On Mon, Sep 21, 2015 at 11:51 PM, Yaakov Selkowitz  wrote:
> On Mon, 2015-09-21 at 19:20 -0600, Chris Murphy wrote:
>> 2. Also under "install the bootloader files" it lists the shim
>> package, but this should be shim-signed in order to include the
>> shim.efi that's been signed by the Microsoft signing service. The shim
>> package only contains an unsigned shim.
>
> Incorrect.  The shim *SRPM* produces shim-unsigned, while the
> shim-signed SRPM produces the shim binary package.  I know, extremely
> confusing, but it's shim you want.

OK got it, thanks.

-- 
Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Simo Sorce]

On Tue, 2015-09-22 at 09:56 -0400, Matthias Clasen wrote:
> On Tue, 2015-09-22 at 15:51 +0200, Lennart Poettering wrote:
> > On Thu, 17.09.15 20:59, Germano Massullo (germano.massu...@gmail.com)
> > wrote:
> > 
> > > Today I had a scary experience with the audio of my computer.
> > > I was listening to music with Amarok, using my headphones... The
> > > KMix
> > > volume level was ~ 35%. When I logged into a video conference
> > > application, the volume suddenly reached the 100%. I was shocked,
> > > having
> > > the maximum audio level shooted in your ears is a painful
> > > experience.
> > > The conference application that triggered PulseAudio pushing volume
> > > to
> > > maximum level probably should have never asked the system for a
> > > 100%
> > > audio level, but on the other hand, PulseAudio should never allow
> > > an
> > > application to make such sudden changes.
> > > To avoid that, you have to set
> > > flat-volumes = no
> > > in /etc/pulse/daemon.conf
> > 
> > This is a non-sensical request. If an app uses the mixer APIs to set
> > the volume of something to very loud, that's what happens. Flat
> > volumes have nothing to do with that.
> > 
> > I mean, the app you are using shouldn't set the volume like this, and
> > that's the key here. If you turn off flat volumes you win about
> > nothing, you just work around this specific app. Soon the next app
> > will come along and play the same game with the actual device volume,
> > and you won *zero*.
> > 
> > Don't mix flat volumes with misbheaving apps. Turning off flat
> > volumes
> > is a hack around the broken apps at best, and completely pointless..
> 
> For better or worse, misbehaving apps are a reality that is probably
> not going to go away... I think we need to have a volume control
> approach that is at least somewhat tolerant against such apps and has
> some safeguards.

Indeed, sticking your head in the sand and saying it is a misbehaving
app is not a useful answer.

Apps misbehave, its a fact of life, you can deal with it, or not deal
with it, if you do not deal with it you have a bad system that causes
grief.

I disabled flat-volumes long ago for the same reasons people had to in
this thread. Yes in theory I can beg every app to be perfect, but in the
mean time I can't get my ears blasted (or in some cases end up with
un-audible input/output). whatever it is with flat-volumes I could never
figure out what was going on, while w/o flat-volumes it is very simple
as each app is individually either low or high and an app raising its
volume doesn't cause all other apps to disappear never to return ...

Disabling flat-volumes may be a workaround but it works very well
apparently. So something probably needs to be improved in flat-volumes,
and until then it is as good an option to disable it by default.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Announcing the release of Fedora 23 Beta!

[Matthew Miller]

On Tue, Sep 22, 2015 at 06:21:00PM +0100, Pádraig Brady wrote:
> I just used dnf distro-sync as per:
> https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_22_-.3E_Fedora_23
> 
> This went fine, and I'm now typing this on F23 beta.
> What are the main advantages of system-upgrade?
> Should the above wiki mention the system-uprade instructions?

There's actually a "fedup" script as part of the package. I think we
should update the dnf-plugin-system-upgrade to Provide: fedup, and keep
the instructions the same. Rationale:

* FedUp has gotten a lot of positive press *just recently*, including this
  interview with Jim Whitehurst
  
http://www.mylinuxrig.com/post/129154618674/the-linux-setup-jim-whitehurst-presidentceo

* Although the mechanisms are different, the basic concepts,
  especially from a user point of view, are very similar

* Documentation won't need (as much) updating

* fedup.sh is already done

* FedUp is an awesome name

* People get all stabby over changes. Let's save getting stabbed for
  when we really need it.

-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Announcing the release of Fedora 23 Beta!

[Pádraig Brady]

On 22/09/15 18:02, Stephen Gallagher wrote:
> On Tue, 2015-09-22 at 12:13 -0400, Eric Griffith wrote:
>> Suggested way to upgrade from 22 to 23? Fresh install? Fedup? Change
>> release ver  for dnf? Did the new dnf upgrade tool get packaged?
> 
> `dnf install dnf-plugin-system-upgrade`
> `dnf system-upgrade download --releasever=23`
> `dnf system-upgrade reboot`

I see the above has replaced fedup:
https://fedoraproject.org/wiki/Changes/DNF_System_Upgrades

I just used dnf distro-sync as per:
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_22_-.3E_Fedora_23

This went fine, and I'm now typing this on F23 beta.
What are the main advantages of system-upgrade?
Should the above wiki mention the system-uprade instructions?

thanks,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora Rawhide 20150922 compose check report

[Fedora compose checker]

No missing expected images.

Images in this compose but not Rawhide 20150921:

Robotics live x86_64
Robotics live i386

No images in Rawhide 20150921 but not this.

Failed openQA tests: 49 of 52

ID: 3285Test: x86_64 workstation_live default_install@uefi
ID: 3284Test: x86_64 workstation_live default_install
ID: 3283Test: x86_64 kde_live default_install
ID: 3282Test: i386 kde_live default_install
ID: 3281Test: i386 workstation_live default_install
ID: 3280Test: i386 generic_boot default_install
ID: 3279Test: x86_64 generic_boot default_install@uefi
ID: 3278Test: x86_64 generic_boot default_install
ID: 3277Test: i386 universal upgrade_desktop_32bit
ID: 3276Test: i386 universal server_lvmthin
ID: 3275Test: i386 universal server_ext3
ID: 3274Test: i386 universal server_btrfs
ID: 3273Test: i386 universal server_software_raid
ID: 3272Test: i386 universal server_simple_encrypted
ID: 3271Test: i386 universal server_repository_http_graphical
ID: 3269Test: i386 universal package_set_minimal
ID: 3268Test: x86_64 universal server_no_swap@uefi
ID: 3267Test: x86_64 universal server_lvmthin@uefi
ID: 3266Test: x86_64 universal server_ext3@uefi
ID: 3265Test: x86_64 universal server_btrfs@uefi
ID: 3264Test: x86_64 universal server_software_raid@uefi
ID: 3263Test: x86_64 universal server_multi_empty@uefi
ID: 3262Test: x86_64 universal server_simple_free_space@uefi
ID: 3261Test: x86_64 universal server_simple_encrypted@uefi
ID: 3260Test: x86_64 universal server_delete_partial@uefi
ID: 3259Test: x86_64 universal server_delete_pata@uefi
ID: 3258Test: x86_64 universal server_sata_multi@uefi
ID: 3257Test: x86_64 universal european_language_install
ID: 3256Test: x86_64 universal server_shrink_ntfs
ID: 3255Test: x86_64 universal server_shrink_ext4
ID: 3254Test: x86_64 universal server_updates_img_local
ID: 3253Test: x86_64 universal upgrade_desktop_64bit
ID: 3252Test: x86_64 universal upgrade_minimal_64bit
ID: 3251Test: x86_64 universal server_kickstart_hdd
ID: 3250Test: x86_64 universal server_no_swap
ID: 3249Test: x86_64 universal server_lvmthin
ID: 3248Test: x86_64 universal server_ext3
ID: 3247Test: x86_64 universal server_btrfs
ID: 3246Test: x86_64 universal server_software_raid
ID: 3245Test: x86_64 universal server_multi_empty
ID: 3244Test: x86_64 universal server_simple_free_space
ID: 3243Test: x86_64 universal server_simple_encrypted
ID: 3242Test: x86_64 universal server_delete_partial
ID: 3241Test: x86_64 universal server_repository_http_variation
ID: 3240Test: x86_64 universal server_repository_http_graphical
ID: 3239Test: x86_64 universal server_mirrorlist_graphical
ID: 3238Test: x86_64 universal server_delete_pata
ID: 3235Test: x86_64 universal server_sata_multi
ID: 3234Test: x86_64 universal package_set_minimal

Passed openQA tests: 3 of 52
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Announcing the release of Fedora 23 Beta!

[Stephen Gallagher]

On Tue, 2015-09-22 at 12:13 -0400, Eric Griffith wrote:
> Suggested way to upgrade from 22 to 23? Fresh install? Fedup? Change
> release ver  for dnf? Did the new dnf upgrade tool get packaged?


`dnf install dnf-plugin-system-upgrade`
`dnf system-upgrade download --releasever=23`
`dnf system-upgrade reboot`


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Trying to contact package maintainer for boinc-client

[Mattia Verga]

Il 22/09/2015 16:12, Laurence ha scritto:

Thanks I have tried to contact him too but no response so far.

On 21.09.2015 12:23, Germano Massullo wrote:

The actual BOINC working mantainer is Mattia Verga




I'm no more a maintainer of boinc-client. And I didn't received any 
email from you... I assume you want someone to approve commit access, 
but I've resigned my commits and I can't.


You should try to ask some provenpackager.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Announcing the release of Fedora 23 Beta for AARCH64 and POWER!

[Peter Robinson]

Fedora 23 Beta Release Announcement for AARCH64 and POWER architectures
===

The Fedora 23 Beta is here for AARCH64 and POWER architectures, right
on schedule for our planned October final release! Want to help make
Fedora 23 be the best release ever on those architectures, or just
want to get a sneak peek? Download the prerelease from the site
and give it a whirl:

*   Get Fedora 23 Beta Server — make use of the very latest
server-based technologies available in the open source community

https://dl.fedoraproject.org/pub/fedora-secondary/releases/test/23_Beta/Server/

*   Get Fedora 23 Beta Cloud — build scale-out computing and utilize
the next generation of container deployment technology

https://dl.fedoraproject.org/pub/fedora-secondary/releases/test/23_Beta/Cloud_Images/


What is the Beta release?
-

The Beta release contains all the exciting features of Fedora 23's
editions in a form that anyone can help test. This testing, guided
by the Fedora QA team, helps us target and identify bugs. When
these bugs are fixed, we make a Beta release available. A Beta
release is code-complete and bears a very strong resemblance to the
third and final release. The final release of Fedora 23 is expected
in October.

We need your help to make Fedora 23 the best yet, so please take
some time to download and try out the Beta and make sure the things
that are important to you are working. If you find a bug, please
report it – every bug you uncover is a chance to improve the
experience for millions of Fedora users worldwide.

Together, we can make Fedora rock-solid. We have a culture of
coordinating new features and pushing fixes upstream as much as
feasible, and your feedback will help improve not only Fedora but
Linux and free software on the whole.


Fedora-Wide Changes
---

Fedora 23 includes a number of changes that will improve all of the
editions. For example, Fedora 23 makes use of compiler flags to
improve security by "hardening" the binaries against memory
corruption vulnerabilities, buffer overflows, and so on. This is a
"behind the scenes" change that most users won't notice through
normal use of a Fedora edition, but will help provide additional
system security.

Likewise, Fedora 23 has disabled SSL3 and RC4 by default due to
known vulnerabilities in the protocols. This means all applications
that use GNUTLS and OpenSSL libraries have had the SSL3 protocol
and RC4 cipher disabled.

Fedora 23 Beta also includes support for Unicode 8.0, which
includes new emojis, and improvements in sorting Unicode text and
processing non-ASCII URLs.


Fedora Server
-

The Fedora Server release includes a number of interesting changes
and additions.

The rolekit service now supports setting up three roles. In
addition to the previously supported Domain Controller (powered by
FreeIPA abd Database Server (powered by PostgreSQL) roles, Fedora
Server 23 features a cache server for web applications (powered by
memcached).

Rolekit can also now be used from the anaconda kickstart by passing
the `--deferred` arguments to `rolectl`. For example: `rolectl
deploy domaincontroller --name=example.com --deferred` will
instruct the system to deploy the Domain Controller role on the
next boot.

The Cockpit Admin Interface in Fedora Server has several big
improvements as well.

*   Support for SSH key authentication
*   Support for configuring user accounts with their authorized keys.
*   Basic cluster dashboard for driving Kubernetes on Fedora Server
and Fedora Atomic Host.
*   Set the imezone for your Fedora Server from the Cockpit User
Interface (UI).
*   Cockpit has also been made safe to use with multipath disks.


Fedora Cloud


Fedora 23 Cloud Base image includes many updates and enhancements to the
underlying Fedora base packages. For example, Fedora 23 now has the
latest Docker release, docker 1.8. We can now verify the publisher
of an image before running. This gives the users the power to identify
that the image publisher published has not been tampered with.


Issues and Details
--

This is an Beta release. As such, we expect that you may encounter bugs
or missing features. To report issues encountered during testing,
contact the Fedora QA team via the mailing list or in #fedora-qa on
freenode.

As testing progresses, common issues are tracked on the Common F23
Bugs page. https://fedoraproject.org/wiki/Common_F23_bugs

For tips on reporting a bug effectively, read "how to file a bug
report." https://fedoraproject.org/wiki/How_to_file_a_bug_report


Release Schedule


The full release schedule planned is available on the Fedora wiki.
The current schedule calls for a beta release towards the end of
September, and the final release scheduled towards the end of October.
https://fedoraproject.org/wiki/Releases/23/Schedule

These dates are subject to 

Re: Announcing the release of Fedora 23 Beta!

[Eric Griffith]

Suggested way to upgrade from 22 to 23? Fresh install? Fedup? Change
release ver  for dnf? Did the new dnf upgrade tool get packaged?
On Sep 22, 2015 11:49 AM, "Vít Ondruch"  wrote:

> Dne 22.9.2015 v 17:30 Richard Hughes napsal(a):
> > On 22 September 2015 at 16:16, Neal Gompa  wrote:
> >> Looks like Fedora 23 is shaping up to be an exciting release!
> > It does, but not exciting enough to use HTML email. Can you switch
> > your email client to use text emails please.
> >
> > Richard.
>
> Content-Type: multipart/alternative
>
> Content-Type: text/plain; charset=UTF-8
>
>
> You probably want to setup your email client to prefer the plain text.
>
>
> Vít
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Announcing the release of Fedora 23 Beta!

[Vít Ondruch]

Dne 22.9.2015 v 17:30 Richard Hughes napsal(a):
> On 22 September 2015 at 16:16, Neal Gompa  wrote:
>> Looks like Fedora 23 is shaping up to be an exciting release!
> It does, but not exciting enough to use HTML email. Can you switch
> your email client to use text emails please.
>
> Richard.

Content-Type: multipart/alternative

Content-Type: text/plain; charset=UTF-8


You probably want to setup your email client to prefer the plain text.


Vít


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Announcing the release of Fedora 23 Beta!

[Richard Hughes]

On 22 September 2015 at 16:16, Neal Gompa  wrote:
> Looks like Fedora 23 is shaping up to be an exciting release!

It does, but not exciting enough to use HTML email. Can you switch
your email client to use text emails please.

Richard.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Announcing the release of Fedora 23 Beta!

[Neal Gompa]

On Tue, Sep 22, 2015 at 9:46 AM, Dennis Gilmore  wrote:

> Fedora 23 Beta Release Announcement
> ===
>
> The Fedora 23 Beta is here, right on schedule for our planned
> October final release! Want to help make Fedora 23 be the best
> release ever, or just want to get a sneak peek? Download the
> prerelease from our Get Fedora site and give it a whirl:
>
> -   Get Fedora 23 Beta Workstation — a reliable, user-friendly, and
> powerful operating system for your laptop or desktop computer
> https://getfedora.org/en/workstation/prerelease/
>
> -   Get Fedora 23 Beta Server — make use of the very latest
> server-based technologies available in the open source community
> https://getfedora.org/en/server/prerelease/
>
> -   Get Fedora 23 Beta Cloud — build scale-out computing and utilize
> the next generation of container deployment technology
> https://getfedora.org/en/cloud/prerelease/
>
> -   Get Fedora 23 Beta Spins — alternative desktops for Fedora
> https://spins.fedoraproject.org/prerelease
>
> -   Get Fedora 23 Beta Labs — curated bundles of purpose-driven
> software and content
> https://labs.fedoraproject.org/prerelease
>
>
> What is the Beta release?
> -
>
> The Beta release contains all the exciting features of Fedora 23's
> editions in a form that anyone can help test. This testing, guided
> by the Fedora QA team, helps us target and identify bugs. When
> these bugs are fixed, we make a Beta release available. A Beta
> release is code-complete and bears a very strong resemblance to the
> third and final release. The final release of Fedora 23 is expected
> in October.
>
> We need your help to make Fedora 23 the best yet, so please take
> some time to download and try out the Beta and make sure the things
> that are important to you are working. If you find a bug, please
> report it – every bug you uncover is a chance to improve the
> experience for millions of Fedora users worldwide.
>
> Together, we can make Fedora rock-solid. We have a culture of
> coordinating new features and pushing fixes upstream as much as
> feasible, and your feedback will help improve not only Fedora but
> Linux and free software on the whole.
>
>
> Fedora-Wide Changes
> ---
>
> Fedora 23 includes a number of changes that will improve all of the
> editions. For example, Fedora 23 makes use of compiler flags to
> improve security by "hardening" the binaries against memory
> corruption vulnerabilities, buffer overflows, and so on. This is a
> "behind the scenes" change that most users won't notice through
> normal use of a Fedora edition, but will help provide additional
> system security.
>
> Likewise, Fedora 23 has disabled SSL3 and RC4 by default due to
> known vulnerabilities in the protocols. This means all applications
> that use GNUTLS and OpenSSL libraries have had the SSL3 protocol
> and RC4 cipher disabled.
>
> Fedora 23 comes with the latest version of Mono 4. This means a big
> improvement because we were stuck with an ancient version of Mono
> (2.10) for too long. All packages within Fedora that are based on
> Mono have been adjusted and rebuilt, to target the 4.5 version of
> the .Net framework. Mono 4 does not support solutions targeting
> v1.0, v2.0 or v3.5 of .Net, but usually they can be easily upgraded
> to v4.5.
>
> Fedora 23 Beta also includes support for Unicode 8.0, which
> includes new emojis, and improvements in sorting Unicode text and
> processing non-ASCII URLs.
>
>
> Fedora Server
> -
>
> The Fedora Server release includes a number of interesting changes
> and additions.
>
> The rolekit service now supports setting up three roles. In
> addition to the previously supported Domain Controller (powered by
> FreeIPA abd Database Server (powered by PostgreSQL) roles, Fedora
> Server 23 features a cache server for web applications (powered by
> memcached).
>
> Rolekit can also now be used from the anaconda kickstart by passing
> the `--deferred` arguments to `rolectl`. For example: `rolectl
> deploy domaincontroller --name=example.com --deferred` will
> instruct the system to deploy the Domain Controller role on the
> next boot.
>
> The Cockpit Admin Interface in Fedora Server has several big
> improvements as well.
>
> -   Support for SSH key authentication
> -   Support for configuring user accounts with their authorized keys.
> -   Basic cluster dashboard for driving Kubernetes on Fedora Server
> and Fedora Atomic Host.
> -   Set the imezone for your Fedora Server from the Cockpit User
> Interface (UI).
> -   Cockpit has also been made safe to use with multipath disks.
>
>
> Fedora Workstation
> --
>
> While there's a lot going on under the hood, desktop users are also
> going to find Fedora 23 Beta pretty exciting for all the obvious
> goodness coming to the desktop. The easiest way to experience the
> preview of these technologies is to download and try the Fe

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[Ville Skyttä]

On Tue, Sep 22, 2015 at 4:13 PM, Matej Stuchlik  wrote:
> - Original Message -
>> From: "Ville Skyttä" 
>>
>> Managed to fiddle around some more and looks like the above is a false
>> concern, many *.pyc, *.opt-1.pyc and *.opt-2.pyc are identical.
>> So, https://github.com/rpm-software-management/rpm/pull/16
>
> Is it? See my next email, Python 3.5.0 RPM seems ~50% bigger right now, unless
> I'm making some silly mistake,

I don't think I've seen the email you refer to yet, nor do I have
access to a Python 3.5.0 rpm -- where can I find one?

Anyway I wouldn't be surprised if the majority of that difference is
because rpmbuild's brp-hardlink-python only hardlinks pyc and pyo, not
the new optimized files. The pull request I have open should address
that.

> and from what I see *.opt-2.pyc is nearly always different from the other 
> ones.

The only quick and silly test I did was to run rpmlint without any
arguments using python3.5 binaries grabbed from an Arch Linux package,
with -O and -OO. It failed early because not all required modules were
available, but it generated pyc files for five modules: in three of
them all pyc, opt-1.pyc and opt-2.pyc were identical, and in two pyc
and opt-1.pyc were identical but opt-2.pyc differed.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Additional information in email about Koji garbage collection?

[Dave Johansen]

On Thu, Sep 17, 2015 at 3:54 PM, Kevin Fenzi  wrote:

> On Wed, 16 Sep 2015 12:19:46 -0700
> Dave Johansen  wrote:
>
> > Would it be possible to add more information to the emails sent to
> > notify about Koji Garbage Collection (
> > http://fedoraproject.org/wiki/Koji/GarbageCollection )?
>
> I would think so yeah. ;)
>
> Looks like these messages are hard coded into the koji-gc script, which
> is part of the koji-utils subpackage of koji.
>
> https://git.fedorahosted.org/cgit/koji/tree/util/koji-gc
>
> > I receive
> > these emails and I usually know why I received them (usually an
> > update was obsoleted because of a fix for an issue that was
> > identified in the testing repo), but sometimes I receive them and
> > have no idea why. Was there a build I did but forgot about? Was it
> > because of a rebuild that someone else did? Did I forgot to push an
> > update to stable? Is this something I need to look into? It's usually
> > possible to track down the "why" but annoying and time consuming to
> > do so. So is the "why" available in the system that sends out the
> > notification emails? If so, would it be possible for that to be
> > included? Thanks,
>
> Not sure. The config we use is at:
>
>
> http://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/koji_hub/files/koji-gc.conf
>
> I'm not sure it knows what rule matched or didn't match when it runs,
> but it might be possible to extend it.
>

Can I open a ticket requesting this feature enhancement? If so, is
https://fedorahosted.org/koji/wiki the right place?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Trying to contact package maintainer for boinc-client

[Laurence]

Thanks I have tried to contact him too but no response so far.

On 21.09.2015 12:23, Germano Massullo wrote:

The actual BOINC working mantainer is Mattia Verga


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 23 Branched 20150922 compose check report

[Fedora compose checker]

Missing expected images:

Cloud disk raw i386
Cloud disk raw x86_64
Cloud_atomic disk raw x86_64
Generic boot i386
Generic boot x86_64

No images in this compose but not 23 Branched 20150921

Images in 23 Branched 20150921 but not this:

Cloud disk raw i386
Cloud_atomic disk raw x86_64
Generic boot x86_64
Cloud disk qcow x86_64
Cloud docker x86_64
Generic boot i386
Cloud vagrant libvirt x86_64
Cloud vagrant virtualbox x86_64
Cloud_atomic disk qcow x86_64
Cloud disk raw x86_64
Cloud_atomic vagrant virtualbox x86_64
Cloud disk qcow i386
Cloud_atomic vagrant libvirt x86_64

Failed openQA tests: 5 of 5

ID: 3233Test: i386 kde_live default_install
ID: 3232Test: x86_64 workstation_live default_install@uefi
ID: 3231Test: x86_64 workstation_live default_install
ID: 3230Test: i386 workstation_live default_install
ID: 3229Test: x86_64 kde_live default_install
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Announcing the release of Fedora 23 Beta!

[Dennis Gilmore]

Fedora 23 Beta Release Announcement
===

The Fedora 23 Beta is here, right on schedule for our planned
October final release! Want to help make Fedora 23 be the best
release ever, or just want to get a sneak peek? Download the
prerelease from our Get Fedora site and give it a whirl:

-   Get Fedora 23 Beta Workstation — a reliable, user-friendly, and
powerful operating system for your laptop or desktop computer
https://getfedora.org/en/workstation/prerelease/

-   Get Fedora 23 Beta Server — make use of the very latest
server-based technologies available in the open source community
https://getfedora.org/en/server/prerelease/

-   Get Fedora 23 Beta Cloud — build scale-out computing and utilize
the next generation of container deployment technology
https://getfedora.org/en/cloud/prerelease/

-   Get Fedora 23 Beta Spins — alternative desktops for Fedora
https://spins.fedoraproject.org/prerelease

-   Get Fedora 23 Beta Labs — curated bundles of purpose-driven
software and content
https://labs.fedoraproject.org/prerelease


What is the Beta release?
-

The Beta release contains all the exciting features of Fedora 23's
editions in a form that anyone can help test. This testing, guided
by the Fedora QA team, helps us target and identify bugs. When
these bugs are fixed, we make a Beta release available. A Beta
release is code-complete and bears a very strong resemblance to the
third and final release. The final release of Fedora 23 is expected
in October.

We need your help to make Fedora 23 the best yet, so please take
some time to download and try out the Beta and make sure the things
that are important to you are working. If you find a bug, please
report it – every bug you uncover is a chance to improve the
experience for millions of Fedora users worldwide.

Together, we can make Fedora rock-solid. We have a culture of
coordinating new features and pushing fixes upstream as much as
feasible, and your feedback will help improve not only Fedora but
Linux and free software on the whole.


Fedora-Wide Changes
---

Fedora 23 includes a number of changes that will improve all of the
editions. For example, Fedora 23 makes use of compiler flags to
improve security by "hardening" the binaries against memory
corruption vulnerabilities, buffer overflows, and so on. This is a
"behind the scenes" change that most users won't notice through
normal use of a Fedora edition, but will help provide additional
system security.

Likewise, Fedora 23 has disabled SSL3 and RC4 by default due to
known vulnerabilities in the protocols. This means all applications
that use GNUTLS and OpenSSL libraries have had the SSL3 protocol
and RC4 cipher disabled.

Fedora 23 comes with the latest version of Mono 4. This means a big
improvement because we were stuck with an ancient version of Mono
(2.10) for too long. All packages within Fedora that are based on
Mono have been adjusted and rebuilt, to target the 4.5 version of
the .Net framework. Mono 4 does not support solutions targeting
v1.0, v2.0 or v3.5 of .Net, but usually they can be easily upgraded
to v4.5.

Fedora 23 Beta also includes support for Unicode 8.0, which
includes new emojis, and improvements in sorting Unicode text and
processing non-ASCII URLs.


Fedora Server
-

The Fedora Server release includes a number of interesting changes
and additions.

The rolekit service now supports setting up three roles. In
addition to the previously supported Domain Controller (powered by
FreeIPA abd Database Server (powered by PostgreSQL) roles, Fedora
Server 23 features a cache server for web applications (powered by
memcached).

Rolekit can also now be used from the anaconda kickstart by passing
the `--deferred` arguments to `rolectl`. For example: `rolectl
deploy domaincontroller --name=example.com --deferred` will
instruct the system to deploy the Domain Controller role on the
next boot.

The Cockpit Admin Interface in Fedora Server has several big
improvements as well.

-   Support for SSH key authentication
-   Support for configuring user accounts with their authorized keys.
-   Basic cluster dashboard for driving Kubernetes on Fedora Server
and Fedora Atomic Host.
-   Set the imezone for your Fedora Server from the Cockpit User
Interface (UI).
-   Cockpit has also been made safe to use with multipath disks.


Fedora Workstation
--

While there's a lot going on under the hood, desktop users are also
going to find Fedora 23 Beta pretty exciting for all the obvious
goodness coming to the desktop. The easiest way to experience the
preview of these technologies is to download and try the Fedora 23
Beta Workstation edition.

Naturally, GNOME is getting an upgrade, with Fedora 23 containing a
preview of the upcoming GNOME 3.18 release, which is easier to use
than ever. There are also many enhancements on the way, such as:

-   Improvements to next-gen

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Matthias Clasen]

On Tue, 2015-09-22 at 15:51 +0200, Lennart Poettering wrote:
> On Thu, 17.09.15 20:59, Germano Massullo (germano.massu...@gmail.com)
> wrote:
> 
> > Today I had a scary experience with the audio of my computer.
> > I was listening to music with Amarok, using my headphones... The
> > KMix
> > volume level was ~ 35%. When I logged into a video conference
> > application, the volume suddenly reached the 100%. I was shocked,
> > having
> > the maximum audio level shooted in your ears is a painful
> > experience.
> > The conference application that triggered PulseAudio pushing volume
> > to
> > maximum level probably should have never asked the system for a
> > 100%
> > audio level, but on the other hand, PulseAudio should never allow
> > an
> > application to make such sudden changes.
> > To avoid that, you have to set
> > flat-volumes = no
> > in /etc/pulse/daemon.conf
> 
> This is a non-sensical request. If an app uses the mixer APIs to set
> the volume of something to very loud, that's what happens. Flat
> volumes have nothing to do with that.
> 
> I mean, the app you are using shouldn't set the volume like this, and
> that's the key here. If you turn off flat volumes you win about
> nothing, you just work around this specific app. Soon the next app
> will come along and play the same game with the actual device volume,
> and you won *zero*.
> 
> Don't mix flat volumes with misbheaving apps. Turning off flat
> volumes
> is a hack around the broken apps at best, and completely pointless..

For better or worse, misbehaving apps are a reality that is probably
not going to go away... I think we need to have a volume control
approach that is at least somewhat tolerant against such apps and has
some safeguards.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Germano Massullo]

Il 22/09/2015 03:43, Rex Dieter ha scritto:
> Germano Massullo wrote:
>
>> Il 21/09/2015 21:45, Thomas Daede ha scritto:
>>> Is there currently a bug open for this? I'd rather it not get lost.
>> I think that a FESCo ticket would be more appropriate.
> I think it would be premature to appeal to FESCo without giving pulseaudio 
> maintainers a chance to respond to your proposal first.
>
> Mind filing a bug with your proposal ?
>
> -- Rex
>
Here we go
https://bugzilla.redhat.com/show_bug.cgi?id=1265267
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Lennart Poettering]

On Thu, 17.09.15 20:59, Germano Massullo (germano.massu...@gmail.com) wrote:

> Today I had a scary experience with the audio of my computer.
> I was listening to music with Amarok, using my headphones... The KMix
> volume level was ~ 35%. When I logged into a video conference
> application, the volume suddenly reached the 100%. I was shocked, having
> the maximum audio level shooted in your ears is a painful experience.
> The conference application that triggered PulseAudio pushing volume to
> maximum level probably should have never asked the system for a 100%
> audio level, but on the other hand, PulseAudio should never allow an
> application to make such sudden changes.
> To avoid that, you have to set
> flat-volumes = no
> in /etc/pulse/daemon.conf

This is a non-sensical request. If an app uses the mixer APIs to set
the volume of something to very loud, that's what happens. Flat
volumes have nothing to do with that.

I mean, the app you are using shouldn't set the volume like this, and
that's the key here. If you turn off flat volumes you win about
nothing, you just work around this specific app. Soon the next app
will come along and play the same game with the actual device volume,
and you won *zero*.

Don't mix flat volumes with misbheaving apps. Turning off flat volumes
is a hack around the broken apps at best, and completely pointless..

Lennart

-- 
Lennart Poettering, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[Matthew Miller]

On Tue, Sep 22, 2015 at 05:07:58AM -0400, Matej Stuchlik wrote:
> When it comes to python3, one way to shave off ~9MiB from
> python3-libs, and possibly quite a bit more overall, would be to not
> install both optimized and unoptimized bytecode, as we do now, but
> just the unoptimized one (the performance hit should be very small).
> 
> I'll look into if that could be done.
> 
> We could also move few things from -libs to -devel, possibly.

Cool. Let's put you on the future list for
https://fedorahosted.org/fedora-badges/ticket/378 :)



-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[Matthew Miller]

On Mon, Sep 21, 2015 at 07:26:52PM -0600, Chris Murphy wrote:
> For the cloud image, extlinux actually works. The problem pops up with
> any image intended for baremetal whre UEFI Secure Boot support is
> needed, and right now GRUB2 does and extlinux doesn't, so any "atomic"
> image would need GRUB2.

In theory, yes. In practice:
https://bugzilla.redhat.com/show_bug.cgi?id=1250874

[...]
> So, I'm not sure where 70MB is coming from. All four are needed for

On disk, and counting deps not previously required.

-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Matthias Clasen]

On Tue, 2015-09-22 at 05:31 -0500, kendell clark wrote:
> hi
> I'm ambivolent on the subject. If flat volumes become a problem, I
> know
> how to turn them off. However, I think because of all the complaints
> here by people who have a very good track record and don't complain
> often, this seems to bear out what I've been trying to say.

You can't really draw too many conclusions from the fact that people
complain on this list - its what you do on this list. Other people with
good track record who don't have a problem with volume handling (like
me) will not show up here to praise and defend PA.

Now, we should certainly look at ways to improve the situation, but
that that will require talking to PA developers...

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[Matej Stuchlik]

- Original Message -
> From: "Ville Skyttä" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, September 22, 2015 3:03:24 PM
> Subject: Re: Fedora 23 cloud image (and, for that matter, minimal 
> anything) bloat
> 
> On Tue, Sep 22, 2015 at 3:43 PM, Ville Skyttä  wrote:
> >
> > BTW I just had a peek into some Arch Linux Python 3.5 packages, and it
> > seems they contain *no* identical *.pyc and corresponding *.opt-1.pyc
> > files. This is bad news wrt the hardlinking. I haven't found any
> > *.opt-2.pyc files to play with, so I don't know what's the situation
> > with them.
> 
> Managed to fiddle around some more and looks like the above is a false
> concern, many *.pyc, *.opt-1.pyc and *.opt-2.pyc are identical.
> So, https://github.com/rpm-software-management/rpm/pull/16

Is it? See my next email, Python 3.5.0 RPM seems ~50% bigger right now, unless
I'm making some silly mistake, and from what I see *.opt-2.pyc is nearly always
different from the other ones.

> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[Matej Stuchlik]

- Original Message -
> From: "Ville Skyttä" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, September 22, 2015 2:43:33 PM
> Subject: Re: Fedora 23 cloud image (and, for that matter, minimal 
> anything) bloat
> 
> On Tue, Sep 22, 2015 at 3:32 PM, Matej Stuchlik  wrote:
> > - Original Message -
> >> From: "Ville Skyttä" 
> >>
> >> Also, be careful with measuring space savings when working with *.pyo.
> >> It is a common case that *.pyc and *.pyo are identical, and when they
> >> are rpmbuild already hardlinks them.
> >
> > That's really interesting, I've had no idea:
> 
> BTW I just had a peek into some Arch Linux Python 3.5 packages, and it
> seems they contain *no* identical *.pyc and corresponding *.opt-1.pyc
> files. This is bad news wrt the hardlinking. I haven't found any
> *.opt-2.pyc files to play with, so I don't know what's the situation
> with them.

And sure enough:

 % rpm2cpio python3-libs-3.4.3-5.fc24.x86_64.rpm | cpio -idmv 2> /dev/null && 
du -ch usr/ | tail -n1
31M total

% rpm2cpio python3-libs-3.5.0-1.fc24.x86_64.rpm | cpio -idmv 2> /dev/null && du 
-ch usr/ | tail -n1
43M total

That's definitely not great.

> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[Ville Skyttä]

On Tue, Sep 22, 2015 at 3:43 PM, Ville Skyttä  wrote:
>
> BTW I just had a peek into some Arch Linux Python 3.5 packages, and it
> seems they contain *no* identical *.pyc and corresponding *.opt-1.pyc
> files. This is bad news wrt the hardlinking. I haven't found any
> *.opt-2.pyc files to play with, so I don't know what's the situation
> with them.

Managed to fiddle around some more and looks like the above is a false
concern, many *.pyc, *.opt-1.pyc and *.opt-2.pyc are identical.
So, https://github.com/rpm-software-management/rpm/pull/16
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[Ville Skyttä]

On Tue, Sep 22, 2015 at 3:32 PM, Matej Stuchlik  wrote:
> - Original Message -
>> From: "Ville Skyttä" 
>>
>> Also, be careful with measuring space savings when working with *.pyo.
>> It is a common case that *.pyc and *.pyo are identical, and when they
>> are rpmbuild already hardlinks them.
>
> That's really interesting, I've had no idea:

BTW I just had a peek into some Arch Linux Python 3.5 packages, and it
seems they contain *no* identical *.pyc and corresponding *.opt-1.pyc
files. This is bad news wrt the hardlinking. I haven't found any
*.opt-2.pyc files to play with, so I don't know what's the situation
with them.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Orphaned Packages in rawhide (2015-09-21)

[Christopher Meng]

I released ownership of flickcurl, because I don't use it anymore.

I still hold epel branches, if someone wants to step in, welcome.

-- 

Yours sincerely,
Christopher Meng

http://awk.io
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[Matej Stuchlik]

- Original Message -
> From: "Ville Skyttä" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, September 22, 2015 1:36:09 PM
> Subject: Re: Fedora 23 cloud image (and, for that matter, minimal 
> anything) bloat
> 
> On Tue, Sep 22, 2015 at 2:25 PM, Neal Gompa  wrote:
> > On Tue, Sep 22, 2015 at 5:36 AM, Matej Stuchlik 
> > wrote:
> >>
> >> Also note that it's possibly not just 9MB. For instance python3-boto, also
> >> on this list, would
> >> save 4.7MB, python3-pip 2.9MB. In general most python packages could go
> >> down in size by ~20-30%.
> >
> > However, this approach would break with Python 3.5 (where pyo data is
> > merged
> > into *.pyc data)
> 
> To be more precise, AFAIU there's no "merging", *.pyo goes away but in
> exchange there are actually two new optimized bytecode files,
> *.opt-1.pyc and *.opt-2.pyc: https://www.python.org/dev/peps/pep-0488/
> If you want to exclude them from packages, they should be there listed
> as %ghost so they're removed in case they get generated by something
> run with -O or -OO. Ditto *.pyo if you intend to exclude them from
> python < 3.5 packages.
> 
> Also, be careful with measuring space savings when working with *.pyo.
> It is a common case that *.pyc and *.pyo are identical, and when they
> are rpmbuild already hardlinks them.

That's really interesting, I've had no idea:

% find /usr/ -name "*.pyc" | wc -l
# All .pyc files
18376

% find /usr/ -name "*.pyc" -links +1 | wc -l
# .pyc files that are hard linked
15761

find /usr/ -name '*.pyc' -links 1 -print0 | du --files0-from=- -ch | tail -n1
# Total size of non-hardlinked .pyc files
65M total

If I'm correct here it looks like it wouldn't really be worth it.

> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Orphaned Packages in rawhide (2015-09-21)

[Michael J Gruber]

> The following packages require above mentioned packages:
> Depending on: flickcurl (1), status change: 2015-09-11 (1 weeks ago)
>   darktable (maintained by: madko, germano)
>   darktable-1.6.8-2.fc24.i686 requires libflickcurl.so.0
>   darktable-1.6.8-2.fc24.src requires flickcurl-devel = 
> 1.26-2.fc23

I have taken up ownership for the Fedora branches of flickcurl, just to
solve the dependency problem of darktable. I'd be happy to pass that on
to anyone who is interested.

It would have been a really pitty to have a new artificial hurdle for
darktable in Fedora, now that that bizarre copylib discussion is muted
for at least 2 releases.

Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 22 September 2015 at 03:26, Chris Murphy wrote:
> On Mon, Sep 21, 2015 at 2:37 PM, Matthew Miller
>  wrote:
[...]
> > But *that* said, the current packaging means that grub2 adds 70MB on
> > disk — about 12% of the entire cloud image. I'm not saying grub2 is
> > evil, just that this is a big portion of the gain and is worth
> > attacking in order to reverse it. I talked briefly to Peter Jones and
> > he says there's quite a bit which can be done there, if going back to
> > extlinux doesn't seem like a viable option.
> 
> These are needed on BIOS systems
> grub2-tools is 7MiB

Installed size is actually 36MB.
/usr/sbin/grub2-sparc64-setup is 2MB and probably doesn't work on
anything else than ppc64(le).
/usr/sbin/grub2-macbless is also 2MB and probably doesn't work on non-Macs

> grub2 is 3.8MiB
> 
> These are needed on UEFI systems
> shim-signed is 633KiB
> grub2-efi is 837KiB
> 
> So, I'm not sure where 70MB is coming from.
[...]

Matt was talking about 70MB on disk (installed size), not rpm package size.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

rawhide report: 20150922 changes

[Fedora Rawhide Report]

Compose started at Tue Sep 22 05:15:03 UTC 2015
Broken deps for i386
--
[IQmol]
IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2
[Macaulay2]
Macaulay2-1.6-17.fc24.i686 requires libntl.so.14
[Singular]
Singular-3.1.6-16.fc24.i686 requires libntl.so.14
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[aqsis]
aqsis-1.8.2-20.fc24.i686 requires libboost_thread.so.1.58.0
aqsis-1.8.2-20.fc24.i686 requires libboost_system.so.1.58.0
aqsis-1.8.2-20.fc24.i686 requires libboost_regex.so.1.58.0
aqsis-1.8.2-20.fc24.i686 requires libboost_program_options.so.1.58.0
aqsis-1.8.2-20.fc24.i686 requires libboost_filesystem.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_wave.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_thread.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_system.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_regex.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_iostreams.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_filesystem.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_thread.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_system.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_regex.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_iostreams.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_filesystem.so.1.58.0
[aws]
aws-tools-2015-2.fc23.i686 requires libaws_ssl.so
[bro]
bro-2.3.2-6.fc23.i686 requires libjemalloc.so.1
[bwm-ng]
bwm-ng-0.6-18.fc24.i686 requires libstatgrab.so.6
[cp2k]
cp2k-openmpi-2.7.0-0.2.20150911svn15878.fc24.i686 requires 
libmpi_usempif08.so.0(openmpi-i386)
cp2k-openmpi-2.7.0-0.2.20150911svn15878.fc24.i686 requires 
libmpi_usempi_ignore_tkr.so.0(openmpi-i386)
cp2k-openmpi-2.7.0-0.2.20150911svn15878.fc24.i686 requires 
libmpi_mpifh.so.2(openmpi-i386)
cp2k-openmpi-2.7.0-0.2.20150911svn15878.fc24.i686 requires 
libmpi.so.1(openmpi-i386)
[derelict]
derelict-3-32.20141022git7fc1714.fc23.i686 requires 
libphobos2-ldc-debug.so.66
derelict-3-32.20141022git7fc1714.fc23.i686 requires 
libdruntime-ldc-debug.so.66
derelict-AL-3-32.20141022git7fc1714.fc23.i686 requires 
libphobos2-ldc-debug.so.66
derelict-AL-3-32.20141022git7fc1714.fc23.i686 requires 
libdruntime-ldc-debug.so.66
derelict-ALURE-3-32.20141022git7fc1714.fc23.i686 requires 
libphobos2-ldc-debug.so.66
derelict-ALURE-3-32.20141022git7fc1714.fc23.i686 requires 
libdruntime-ldc-debug.so.66
derelict-ASSIMP3-3-32.20141022git7fc1714.fc23.i686 requires 
libphobos2-ldc-debug.so.66
derelict-ASSIMP3-3-32.20141022git7fc1714.fc23.i686 requires 
libdruntime-ldc-debug.so.66
derelict-FI-3-32.20141022git7fc1714.fc23.i686 requires 
libphobos2-ldc-debug.so.66
derelict-FI-3-32.20141022git7fc1714.fc23.i686 requires 
libdruntime-ldc-debug.so.66
derelict-FT-3-32.20141022git7fc1714.fc23.i686 requires 
libphobos2-ldc-debug.so.66
derelict-FT-3-32.20141022git7fc1714.fc23.i686 requires 
libdruntime-ldc-debug.so.66
derelict-GL3-3-32.20141022git7fc1714.fc23.i686 requires 
libphobos2-ldc-debug.so.66
derelict-GL3-3-32.20141022git7fc1714.fc23.i686 requires 
libdruntime-ldc-debug.so.66
derelict-GLFW3-3-32.20141022git7fc1714.fc23.i686 requires 
libphobos2-ldc-debug.so.66
derelict-GLFW3-3-32.20141022git7fc1714.fc23.i686 requires 
libdruntime-ldc-debug.so.66
derelict-IL-3-32.20141022git7fc1714.fc23.i686 requires 
libphobos2-ldc-debug.so.66
derelict-IL-3-32.20141022git7fc1714.fc23.i686 requires 
libdruntime-ldc-debug.so.66
derelict-LUA-3-32.20141022git7fc1714.fc23.i686 requires 
libphobos2-ldc-debug.so.66
derelict-LUA-3-32.20141022git7fc1714.fc23.i686 requires 
libdruntime-ldc-debug.so.66
derelict-ODE-3-32.20141022git7fc1714.fc23.i686 requires 
libphobos2-ldc-debug.so.66
derelict-ODE-3-32.20141022git7fc1714.fc23.i686 requires 
libdruntime-ldc-debug.so.66
derelict-Ogg-3-32.20141022git7fc1714.fc23.i686 requires 
libphobos2-ldc-debug.so.66
derelict-Ogg-3-32.20141022git7fc1714.fc23.i686 requires 
libdruntime-ldc-debug.so.66
derelict-PHYSFS-3-32.20141022git7fc1714.fc23.i686 requires 
libphobos2-ldc-debug.so.66
derelict-PHYSFS-3-32.20141022git7fc1714.fc23.i686 requires 
libdruntime-ldc-debug.so.66
derelict-PQ-3-32.20141022git7fc1714.fc23.i686 requires 
libphobos2-ldc-debug.so.66
derelict-PQ-3-32.20141022git7f

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[Ville Skyttä]

On Tue, Sep 22, 2015 at 2:25 PM, Neal Gompa  wrote:
> On Tue, Sep 22, 2015 at 5:36 AM, Matej Stuchlik  wrote:
>>
>> Also note that it's possibly not just 9MB. For instance python3-boto, also
>> on this list, would
>> save 4.7MB, python3-pip 2.9MB. In general most python packages could go
>> down in size by ~20-30%.
>
> However, this approach would break with Python 3.5 (where pyo data is merged
> into *.pyc data)

To be more precise, AFAIU there's no "merging", *.pyo goes away but in
exchange there are actually two new optimized bytecode files,
*.opt-1.pyc and *.opt-2.pyc: https://www.python.org/dev/peps/pep-0488/
If you want to exclude them from packages, they should be there listed
as %ghost so they're removed in case they get generated by something
run with -O or -OO. Ditto *.pyo if you intend to exclude them from
python < 3.5 packages.

Also, be careful with measuring space savings when working with *.pyo.
It is a common case that *.pyc and *.pyo are identical, and when they
are rpmbuild already hardlinks them.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: package naming question: IT++

[Neal Gompa]

On Tue, Sep 22, 2015 at 6:44 AM, Jonathan Wakely  wrote:

> On 22/09/15 10:40 +0200, Marco Driusso wrote:
>
>> So I think we have two options:
>> 1) use 'itpp' as the name of the package, which corresponds to the
>> include dir name, but not to the lib file name (libitpp.so); in this
>>
>
> All libraries start with "lib" but that doesn't mean the package that
> provides a library should do.
>
> Look at the output of rpm -qf /usr/lib64/lib* and you'll see most of
> them are not called "libxxx" just because they install a file called
> "libxxx.so".  e.g. gtk3 installs libgtk-3
>
> The project is called IT++, it installs headers in  and
> installs libitpp.so, so itpp seems the most natural name.
>
>
>
If this wasn't a library that's linked at compile time, I would suggest
also including a "Provides: libitpp" line in there too, but I think that's
not necessary, since packages that would depend on it would use the library
dependency "libitpp.so.8" instead, which there should be an automatic
Provides generated in the itpp package.

Basically, RPM does nice things for you, so you don't have to care (as
much) about this kind of stuff.


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[drago01]

On Tue, Sep 22, 2015 at 12:00 AM, Owen Taylor  wrote:
> On Thu, 2015-09-17 at 23:26 +0200, Germano Massullo wrote:
>> Il 17/09/2015 21:13, Andrew Lutomirski ha scritto:
>> >
>> > To clarify: did you get blasted by music or by video conference
>> > sounds?  If the music volume got louder, then it sounds like either
>> > a
>> > straight-up bug in PulseAudio (and a severe and dangerous one at
>> > that)
>> > or a serious bug in your video conference volume in which it
>> > adjusts
>> > the volume of streams other than its own.
>> >
>> > If you got blasted by video conference sounds, then I'd say it's a
>> > serious design flaw in PulseAudio.  PulseAudio should offer an
>> > easy-to-configure maximum volume (probably A-weighted power, but
>> > peak
>> > level works, too, if considerably less well) on a per-output basis
>> > with which to protect your ears.
>> >
>> > --Andy
>> I got blasted from the music because I was not making a conference, I
>> only logged into the software, so the music was the only sound I was
>> listening to. PulseAudio pushed the master audio level to 100%
>> (therefore all applications audio level changed to 100%, due flat-
>> volume setting).
>
> I'm not an expert in the subject, but I'm pretty sure this is not how
> flat volumes are supposed to work - it doesn't sound like useful
> behavior at all!
>
> Experimenting with GNOME, the model presented to the user seems to be:
>
>  - Each application's volume control separate goes from 0-100% of the
>maximum system volume.
>  - Adjusting each application is independent
>  - Modifying the system global volume slider proportionally adjusts the
>volume of each application
>  - The system global volume slider is always maintained to be at least
>as much as the maximum of any application
>
>  NOTE: The system global volume slider is *not the same as the hardware
>volume and does not represent a multiplication factor for
>application volumes. It's just something that the user can
>drag to change the volume of all applications.
>
> There is danger to the ears if an application assumes that 100% volume
> is a safe volume and blindly sets its volume to 100% without user
> input. But that only affects that application - one application's
> misbehavior never affects another application.
>
> It sounds like KDE ends up implementing a different model, either
> intentionally or because of bugs. It's also possible that lower level
> bugs (sound card driver, for example) might be making things misbehave.
>
> In general, the fact that pulseaudio is configurable in this area is
> going to be the source of almost infinite bug chasing, as applications
> and desktop environments are "fixed" for one setting or another. It's
> also very easy for people to stop investigating problems and say that
> "changing the setting fixed it for me." :-(

Flat volumes only make sense if we have an appropriate UI for them ...
but we do not.
Such a UI would show all volumes in relation to each other and the
system volume like windows does:
http://blog.nirsoft.net/wp-content/uploads/2011/02/volume_mixer_win7.png

What we currently have makes no sense the user has to guess what each
volume control actually does and how it affects the global volume.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[Neal Gompa]

On Tue, Sep 22, 2015 at 5:36 AM, Matej Stuchlik  wrote:

> - Original Message -
> > From: "drago01" 
> > To: "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org>
> > Sent: Tuesday, September 22, 2015 11:20:27 AM
> > Subject: Re: Fedora 23 cloud image (and, for that matter, minimal
> anything) bloat
> >
> > On Tue, Sep 22, 2015 at 11:07 AM, Matej Stuchlik 
> wrote:
> > > [...]
> > > When it comes to python3, one way to shave off ~9MiB from
> python3-libs, and
> > > possibly quite a bit more overall, would be to not install both
> optimized
> > > and
> > > unoptimized bytecode, as we do now, but just the unoptimized one (the
> > > performance
> > > hit should be very small).
> >
> > How small is "very small" ? Have you measured it?
> > I don't think 9MB of disk space is worth taking a performance hit for ...
>
> The only difference between unoptimized and "optimized" bytecode should be
> that
> the latter is missing all docstrings, has disable asserts and sets
> __debug__ to False,
> I can't imagine this being significant, performance wise.
>
> That said I do not plan on doing this before I measure the performance
> difference and
> discuss it on python-sig and python-linux.
>
> Also note that it's possibly not just 9MB. For instance python3-boto, also
> on this list, would
> save 4.7MB, python3-pip 2.9MB. In general most python packages could go
> down in size by ~20-30%.
>
> Matt
>
>
​However, this approach would break with Python 3.5 (where pyo data is
merged into *.pyc data), so I would consider it an ill-advised approach
anyway.​ It may work for F23, but it won't work for F24, and then we'd be
back to square one again.


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F-23 Branched report: 20150922 changes

[Fedora Branched Report]

Compose started at Tue Sep 22 07:15:03 UTC 2015
Broken deps for armhfp
--
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[aws]
aws-tools-2015-2.fc23.armv7hl requires libaws_ssl.so
[calligra]
calligra-kexi-map-form-widget-2.9.7-1.fc23.armv7hl requires 
libmarblewidget.so.21
calligra-reports-map-element-2.9.7-1.fc23.armv7hl requires 
libmarblewidget.so.21
calligra-semanticitems-2.9.7-1.fc23.armv7hl requires 
libmarblewidget.so.21
[dpm-contrib-admintools]
dpm-contrib-admintools-0.2.1-6.fc23.armv7hl requires 
MySQL-python(armv7hl-32)
[hawaii-shell]
hawaii-shell-0.3.0-3.fc22.armv7hl requires 
libqtaccountsservice-qt5.so.0.1.2
[hbase]
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[licq]
licq-1.8.2-9.fc23.armv7hl requires libboost_regex.so.1.57.0
[mariadb-galera]
1:mariadb-galera-server-10.0.17-5.fc23.armv7hl requires galera >= 
0:25.3.3
[moon-buggy]
moon-buggy-1.0.51-14.fc23.armv7hl requires libesd.so.0
[netbeans-platform]
1:netbeans-platform-harness-7.0.1-11.fc22.armv7hl requires cobertura >= 
0:1.9.3
[nodejs-grunt-contrib-copy]
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) < 0:0.2
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) >= 0:0.1.0
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(chalk) >= 
0:0.5.1
[nodejs-grunt-saucelabs]
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(sauce-tunnel) 
>= 0:2.2.3
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(requestretry) < 
0:1.3
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(requestretry) 
>= 0:1.2.2
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(lodash) >= 
0:3.7.0
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(colors) >= 
0:1.0.0
[nodejs-proxy-agent]
nodejs-proxy-agent-1.1.0-1.fc22.noarch requires npm(socks-proxy-agent) 
< 0:1
[oat]
oat-appraiser-1.6.0-16.fc22.armv7hl requires tomcat-servlet-3.0-api
oat-client-1.6.0-16.fc22.armv7hl requires tomcat-servlet-3.0-api
[oozie]
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.pig:pig)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-serde)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-metastore)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-exec)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-common)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-cli)
oozie-4.0.1-5.fc22.noarch requires 
mvn(org.apache.hive.hcatalog:webhcat-java-client)
oozie-4.0.1-5.fc22.noarch requires 
mvn(org.apache.hive.hcatalog:hcatalog-server-extensions)
oozie-4.0.1-5.fc22.noarch requires 
mvn(org.apache.hive.hcatalog:hcatalog-pig-adapter)
oozie-4.0.1-5.fc22.noarch requires 
mvn(org.apache.hive.hcatalog:hcatalog-core)
[openstack-heat-gbp]
openstack-heat-gbp-2014.2-2.fc23.noarch requires openstack-heat-engine 
< 0:2014.3
[openstack-neutron-gbp]
openstack-neutron-gbp-2014.2-2.fc23.noarch requires openstack-neutron < 
0:2014.3
[openstack-swift]
openstack-swift-2.3.0-2.fc23.noarch requires python-pyeclib
[perl-B-Hooks-OP-Check-EntersubForCV]
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires 
libperl.so.5.20
[perl-Data-Alias]
perl-Data-Alias-1.18-4.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.armv7hl requires libperl.so.5.20
[perl-Data-Dump-Streamer]
perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires libperl.so.5.20
[perl-Devel-BeginLift]
perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires libperl.so.5.20
[perl-Devel-FindRef]
perl-Devel-FindRef-1.44-3.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.armv7hl requires libperl.so.5.20
[perl-Method-Signatures]
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
[perl-POE-API-Peek]
1:perl-PO

Re: package naming question: IT++

[Jonathan Wakely]

On 22/09/15 10:40 +0200, Marco Driusso wrote:

So I think we have two options:
1) use 'itpp' as the name of the package, which corresponds to the 
include dir name, but not to the lib file name (libitpp.so); in this 


All libraries start with "lib" but that doesn't mean the package that
provides a library should do.

Look at the output of rpm -qf /usr/lib64/lib* and you'll see most of
them are not called "libxxx" just because they install a file called
"libxxx.so".  e.g. gtk3 installs libgtk-3

The project is called IT++, it installs headers in  and
installs libitpp.so, so itpp seems the most natural name.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: OpenMesh soname bump in rawhide

[Jonathan Wakely]

On 21/09/15 17:34 -0700, Susi Lehtola wrote:

Hi,


I'm updating OpenMesh in rawhide to version 4.1, which bumps the 
soname. Only IQmol seems to use OpenMesh, which I'm rebuilding soon 
after.


IQmol is currently broken on rawhide and can't be built against Boost
1.59, see
https://github.com/nutjunkie/IQmol/issues/8#issuecomment-132523899

(That issue was closed by fixing the code to build with Boost 1.58,
but it broke again with Boost 1.59 and hasn't been fixed).
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[kendell clark]

hi
I'm ambivolent on the subject. If flat volumes become a problem, I know
how to turn them off. However, I think because of all the complaints
here by people who have a very good track record and don't complain
often, this seems to bear out what I've been trying to say. That this
should be fixed in pulse audio. I'll stop repeating myself and ask for
where to go from here. Should I file a bug against pulse audio, comment
on the redhat bug previously mentioned here, something else? I want to
get the ball rolling on this. I do know that I've tried a few times to
approach pulse audio devs on their irc channel, to no luck. I rarely get
a response. When I do, it's generally something like a shrug and, not my
problem, go file a bug against the app. Not that everyone's like that,
just saying what my personal experience has been.
Thanks
Kendell clark


On 09/22/2015 05:23 AM, Bastien Nocera wrote:
> 
> 
> - Original Message -
>> On Mon, 2015-09-21 at 18:00 -0400, Owen Taylor wrote:
>>> There is danger to the ears if an application assumes that 100%
>>> volume
>>> is a safe volume and blindly sets its volume to 100% without user
>>> input. But that only affects that application - one application's
>>> misbehavior never affects another application.
>>
>> That's definitely not correct. With flat volumes, applications can and
>> do set the system volume to 100%. I've received numerous complaints
>> about this. It's particularly frustrating when watching YouTube videos,
>> since YouTube sets the system volume to 1 when starting a video. We are
>> still waiting for some promised "browsers API" in PulseAudio to fix
>> this easily.
>>
>> I think it's telling that this thread is full of complaints about flat
>> volumes, with no supporters. Also, Ubuntu does not seem to be getting
>> any complaints about the lack of flat volumes. :)
> 
> Given that I don't want per-app volumes either, not sure that my opinion
> is required to choose between 2 schemes that are per-app.
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Bastien Nocera]

- Original Message -
> On Mon, 2015-09-21 at 18:00 -0400, Owen Taylor wrote:
> > There is danger to the ears if an application assumes that 100%
> > volume
> > is a safe volume and blindly sets its volume to 100% without user
> > input. But that only affects that application - one application's
> > misbehavior never affects another application.
> 
> That's definitely not correct. With flat volumes, applications can and
> do set the system volume to 100%. I've received numerous complaints
> about this. It's particularly frustrating when watching YouTube videos,
> since YouTube sets the system volume to 1 when starting a video. We are
> still waiting for some promised "browsers API" in PulseAudio to fix
> this easily.
> 
> I think it's telling that this thread is full of complaints about flat
> volumes, with no supporters. Also, Ubuntu does not seem to be getting
> any complaints about the lack of flat volumes. :)

Given that I don't want per-app volumes either, not sure that my opinion
is required to choose between 2 schemes that are per-app.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: package naming question: IT++

[Christopher Meng]

In line with tarball name, it's better to use itpp.

No +1 for libitpp if itpp had been there for several years.

-- 

Yours sincerely,
Christopher Meng

http://awk.io
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: package naming question: IT++

[Pierre-Yves Chibon]

On Tue, Sep 22, 2015 at 10:40:13AM +0200, Marco Driusso wrote:
> Hi all,
> 
> I have a question about the right name to give to a package of the IT++
> library (package review request here ->
> https://bugzilla.redhat.com/show_bug.cgi?id=1264686, any review - and also
> sponsorship, I need one! - is welcome).
> 
> Some info:
> - the actual name of the library is 'IT++', according to their web page and
> documentation http://itpp.sourceforge.net/4.3.1/;
> - the package used to be called 'itpp' in former versions of the spec in
> Fedora (now dead, since 2011);
> - the installed library comes out from the build process as 'libitpp.so*',
> but all headers are under %{_includedir}/itpp, of course contain a lot of
> #include , and of course all HTML documentation is
> written accordingly (basically, everything is called itpp*, except the
> actual lib file, which is called libitpp.so);
> - the package is named 'libitpp' in other distros, e.g. Ubuntu, openSUSE.
> 
> So I think we have two options:
> 1) use 'itpp' as the name of the package, which corresponds to the include
> dir name, but not to the lib file name (libitpp.so); in this case we will
> have:
> %{_libdir}/libitpp.so*
> %{_includedir}/itpp
> %{_datadir}/itpp
> %{_docdir}/itpp (<- comes out from %doc directive)

If we're sure there are no conflicts, what about a name itpp with a provides
libitpp ?

Pierre
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[Matej Stuchlik]

- Original Message -
> From: "drago01" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, September 22, 2015 11:20:27 AM
> Subject: Re: Fedora 23 cloud image (and, for that matter, minimal 
> anything) bloat
> 
> On Tue, Sep 22, 2015 at 11:07 AM, Matej Stuchlik  wrote:
> > [...]
> > When it comes to python3, one way to shave off ~9MiB from python3-libs, and
> > possibly quite a bit more overall, would be to not install both optimized
> > and
> > unoptimized bytecode, as we do now, but just the unoptimized one (the
> > performance
> > hit should be very small).
> 
> How small is "very small" ? Have you measured it?
> I don't think 9MB of disk space is worth taking a performance hit for ...

The only difference between unoptimized and "optimized" bytecode should be that
the latter is missing all docstrings, has disable asserts and sets __debug__ to 
False,
I can't imagine this being significant, performance wise.

That said I do not plan on doing this before I measure the performance 
difference and
discuss it on python-sig and python-linux.

Also note that it's possibly not just 9MB. For instance python3-boto, also on 
this list, would
save 4.7MB, python3-pip 2.9MB. In general most python packages could go down in 
size by ~20-30%.

Matt

> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: package naming question: IT++

[Igor Gnatenko]

I think you want to use just plain itpp

On Tue, Sep 22, 2015, 10:40 AM Marco Driusso  wrote:

> Hi all,
>
> I have a question about the right name to give to a package of the IT++
> library (package review request here ->
> https://bugzilla.redhat.com/show_bug.cgi?id=1264686, any review - and
> also sponsorship, I need one! - is welcome).
>
> Some info:
> - the actual name of the library is 'IT++', according to their web page
> and documentation http://itpp.sourceforge.net/4.3.1/;
> - the package used to be called 'itpp' in former versions of the spec in
> Fedora (now dead, since 2011);
> - the installed library comes out from the build process as
> 'libitpp.so*', but all headers are under %{_includedir}/itpp, of course
> contain a lot of #include , and of course all HTML
> documentation is written accordingly (basically, everything is called
> itpp*, except the actual lib file, which is called libitpp.so);
> - the package is named 'libitpp' in other distros, e.g. Ubuntu, openSUSE.
>
> So I think we have two options:
> 1) use 'itpp' as the name of the package, which corresponds to the
> include dir name, but not to the lib file name (libitpp.so); in this
> case we will have:
> %{_libdir}/libitpp.so*
> %{_includedir}/itpp
> %{_datadir}/itpp
> %{_docdir}/itpp (<- comes out from %doc directive)
>
> 2) use 'libitpp' as the name of the package, but leaving the include dir
> named as %{_includedir}/itpp (since all headers and documentation
> contain several #include ); in this case:
> %{_libdir}/libitpp.so*
> %{_includedir}/itpp
> %{_datadir}/itpp or %{_datadir}/libitpp (we can change this)
> %{_docdir}/libitpp (<- comes out from %doc directive)
>
> What do you think it is the best? (atm in the review we are using choice
> 2, but choice 1 seems more tidy).
>
> Marco
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[drago01]

On Tue, Sep 22, 2015 at 11:07 AM, Matej Stuchlik  wrote:
> [...]
> When it comes to python3, one way to shave off ~9MiB from python3-libs, and
> possibly quite a bit more overall, would be to not install both optimized and
> unoptimized bytecode, as we do now, but just the unoptimized one (the 
> performance
> hit should be very small).

How small is "very small" ? Have you measured it?
I don't think 9MB of disk space is worth taking a performance hit for ...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[Matej Stuchlik]

- Original Message -
> From: "Matthew Miller" 
> To: "Fedora Development List" 
> Sent: Monday, September 21, 2015 5:07:40 PM
> Subject: Fedora 23 cloud image (and, for that matter, minimal anything) bloat
> 
> Fedora-Cloud-Base-20141203-21.x86_64.qcow2:   151M
> Fedora-Cloud-Base-23_Beta-20150915.x86_64.qcow2:  275M
> 
> In just one year — 82% more awesome?
> 
> I'd really like this to stay below 200MB as a competitive threshold.
> Or, if we're going to be bigger than that, be bigger for REASONS, not
> just accretion.
> 
> tl;dr: grub2 is a lot to blame, but there seem to be some new
> questionable dep chains from systemd, and general dep growth across the
> board.
> 
> 
> Disk use at first boot:
> 
>   [f21]$ df -h  /
>   Filesystem  Size  Used Avail Use% Mounted on
>   /dev/vda120G  359M   19G   2% /
> 
>   [f23b]$ df -h  /
>   Filesystem  Size  Used Avail Use% Mounted on
>   /dev/vda120G  578M   19G   4% /
> 
> RPMs installed:
> 
>   [f21]$ rpm -qa | wc -l
>   226
> 
>   [f23b]$ rpm -qa | wc -l
>   264
> 
> Top 20 rpms by reported size:
> 
>   $ rpm -qa --qf '%{size} %{name}\n'|sort -nr|head -20
>   120417342 glibc-common
>   42307839 kernel-core
>   25000497 python-libs
>   22438155 systemd
>   14623272 coreutils
>   14000291 glibc
>   11282056 ruby-libs  # hey, at least we lost this
>   10845519 glib2
>   10593004 selinux-policy-targeted
>   9389116 cracklib-dicts  #
>   https://bugzilla.redhat.com/show_bug.cgi?id=865521
>   9078043 python-boto
>   8792531 util-linux
>   7084188 bash
>   6669884 gnupg2
>   5844544 yum
>   4893790 policycoreutils
>   3786564 file-libs
>   3540004 shadow-utils
>   3458312 groff-base  # who doesn't love groff?
>   2997717 tar
> 
> 
>   $ rpm -qa --qf '%{size} %{name}\n'|sort -nr|head -20
>   125195206 glibc-common
>   86298752 linux-firmware   # sadface, but hard
>   53291365 kernel-core
>   36004297 grub2-tools  # this is ridiculous
>   28453336 python3-libs # 13% growth
>   27233273 systemd  # 21% growth
>   16648994 grub2# *sigh*
>   14486819 glibc
>   14287847 coreutils# this package got _smaller!_
>   11143743 glib2
>   11129880 selinux-policy-targeted
>   9389116 cracklib-dicts
>   9261499 python3-boto
>   9237998 util-linux
>   9224255 fedora-logos  # this is also grub's fault.
>   7517574 gnupg2
>   7143418 bash
>   6574678 python3-pip   # :(
>   583 hwdata# this is ALSO grub's fault
>   5423400 xkeyboard-config  # really looks like a systemd dep chain
>   involving plymouth

When it comes to python3, one way to shave off ~9MiB from python3-libs, and
possibly quite a bit more overall, would be to not install both optimized and
unoptimized bytecode, as we do now, but just the unoptimized one (the 
performance
hit should be very small).

I'll look into if that could be done.

We could also move few things from -libs to -devel, possibly.

Matt

> Okay, let's look on disk:
> 
> 
>   [f21]$ sudo du -sh * 2>/dev/null|sort -h
>   [...]
>   36K home
>   40K root
>   228Krun
>   21M boot
>   22M etc
>   34M var
>   276Musr
> 
> 
>   [f23b]$ sudo du -sh * 2>/dev/null|sort -h
>   [...]
>   40K root
>   264Krun
>   16M etc
>   45M boot  # ugh
>   171Mvar   # oww
>   463Musr   # oww oww oww
> 
>   Breakdown:
>  
>- boot is mostly grub, but initramfs is also doubled
>- var: DNF cache is full of stuff! 123M... oh, hey, that wasn't
>  there when we booted. `df -h /` is now up to 702M. Maybe multiple
>  repos would help here, or some other more clever design. Does
>  every cloud image in the world _really_ need to replicate
>  dependency data so I can `dnf install
>  /usr/share/minetest/builtin/mainmenu/init_simple.lua`?
> 
>- usr:
> 
>   * linux-firmware is the biggest thing here
>   * python3 is another good chunk
>   * also kernel modules, but, eh, whatchagonnado
>   * oh, and of course, grub2.
>   
> --
> Matthew Miller
> 
> Fedora Project Leader
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

package naming question: IT++

[Marco Driusso]

Hi all,

I have a question about the right name to give to a package of the IT++ 
library (package review request here -> 
https://bugzilla.redhat.com/show_bug.cgi?id=1264686, any review - and 
also sponsorship, I need one! - is welcome).


Some info:
- the actual name of the library is 'IT++', according to their web page 
and documentation http://itpp.sourceforge.net/4.3.1/;
- the package used to be called 'itpp' in former versions of the spec in 
Fedora (now dead, since 2011);
- the installed library comes out from the build process as 
'libitpp.so*', but all headers are under %{_includedir}/itpp, of course 
contain a lot of #include , and of course all HTML 
documentation is written accordingly (basically, everything is called 
itpp*, except the actual lib file, which is called libitpp.so);

- the package is named 'libitpp' in other distros, e.g. Ubuntu, openSUSE.

So I think we have two options:
1) use 'itpp' as the name of the package, which corresponds to the 
include dir name, but not to the lib file name (libitpp.so); in this 
case we will have:

%{_libdir}/libitpp.so*
%{_includedir}/itpp
%{_datadir}/itpp
%{_docdir}/itpp (<- comes out from %doc directive)

2) use 'libitpp' as the name of the package, but leaving the include dir 
named as %{_includedir}/itpp (since all headers and documentation 
contain several #include ); in this case:

%{_libdir}/libitpp.so*
%{_includedir}/itpp
%{_datadir}/itpp or %{_datadir}/libitpp (we can change this)
%{_docdir}/libitpp (<- comes out from %doc directive)

What do you think it is the best? (atm in the review we are using choice 
2, but choice 1 seems more tidy).


Marco
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Vít Ondruch]

Dne 22.9.2015 v 00:00 Owen Taylor napsal(a):
> On Thu, 2015-09-17 at 23:26 +0200, Germano Massullo wrote:
>> Il 17/09/2015 21:13, Andrew Lutomirski ha scritto:
>>> To clarify: did you get blasted by music or by video conference
>>> sounds?  If the music volume got louder, then it sounds like either
>>> a
>>> straight-up bug in PulseAudio (and a severe and dangerous one at
>>> that)
>>> or a serious bug in your video conference volume in which it
>>> adjusts
>>> the volume of streams other than its own.
>>>
>>> If you got blasted by video conference sounds, then I'd say it's a
>>> serious design flaw in PulseAudio.  PulseAudio should offer an
>>> easy-to-configure maximum volume (probably A-weighted power, but
>>> peak
>>> level works, too, if considerably less well) on a per-output basis
>>> with which to protect your ears.
>>>
>>> --Andy
>> I got blasted from the music because I was not making a conference, I
>> only logged into the software, so the music was the only sound I was
>> listening to. PulseAudio pushed the master audio level to 100%
>> (therefore all applications audio level changed to 100%, due flat-
>> volume setting).
> I'm not an expert in the subject, but I'm pretty sure this is not how
> flat volumes are supposed to work - it doesn't sound like useful
> behavior at all!
>
> Experimenting with GNOME, the model presented to the user seems to be:
>
>  - Each application's volume control separate goes from 0-100% of the
>maximum system volume. 
>  - Adjusting each application is independent
>  - Modifying the system global volume slider proportionally adjusts the
>volume of each application
>  - The system global volume slider is always maintained to be at least
>as much as the maximum of any application

If this is true, than it is totally unexpected. I would expect that
system volume proportionally limits all volumes, e.g. if my system
volume is at 50%, the apps 0-100% is actually just 0-50% of system volume.


Vít

>
>  NOTE: The system global volume slider is *not the same as the hardware
>volume and does not represent a multiplication factor for
>application volumes. It's just something that the user can
>drag to change the volume of all applications.
>
> There is danger to the ears if an application assumes that 100% volume
> is a safe volume and blindly sets its volume to 100% without user
> input. But that only affects that application - one application's
> misbehavior never affects another application.
>
> It sounds like KDE ends up implementing a different model, either
> intentionally or because of bugs. It's also possible that lower level
> bugs (sound card driver, for example) might be making things misbehave.
>
> In general, the fact that pulseaudio is configurable in this area is
> going to be the source of almost infinite bug chasing, as applications
> and desktop environments are "fixed" for one setting or another. It's
> also very easy for people to stop investigating problems and say that
> "changing the setting fixed it for me." :-(
>
> - Owen
>

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct