Re: [gentoo-user] OT: what audio file format / container to play on Android.

[Mick]

On Wednesday 06 Jul 2016 16:07:17 Stroller wrote:
> > On 5 Jul 2016, at 16:54, wabe  wrote:
> > 
> > If you wanna put the audio data into another container without recoding
> > it, you can use for example something like that:
> > 
> > ffmpeg -i filename.mp4 -acodec copy filename.m4a
> 
> This has worked. Many thanks for your help.
> 
> I did not actually expect this, as I thought .mp4 and .m4a were the same
> thing (see links below) and renaming the .mp4 to .m4a  did not have any
> effect.

They are not exactly the same thing, in the sense that m4a ought to only have 
an audio stream in it, but mp4 may have more streams (audio and video).


> ffmpeg did, however, seem to do no more than copy the stream (it took only a
> second or so), so presumably it has marked the container differently
> somehow. See attached, anyone who's interested.

If you notice youtube-dl used ffmpeg after it downloaded your file to fix 
something in the aac bitstream, which it considered 'malformated':

[download] Destination: The Bronze Age Collapse, In Our Time - BBC Radio 4-
b07fl2qw.mp4
[download] 100% of 40.56MiB in 01:36
[ffmpeg] Fixing malformated aac bitstream in "The Bronze Age Collapse, In Our 
Time - BBC Radio 4-b07fl2qw.mp4"

If you run ffprobe on the partly downloaded mp4 file before youtube-dl 
completes 
and has a chance to use ffmpeg, you can compare its output with the 'fixed' mp4 
file and then your own m4a audio extract to see what the differences might be.

> I appreciate the contributions of all who've replied,
> 
> Stroller.
> 
> 
> 
> [1] http://stackoverflow.com/questions/9412384/
> [2] https://en.wikipedia.org/wiki/MPEG-4_Part_14#.MP4_versus_.M4A
> [3] https://wiki.jriver.com/index.php/MP4_and_M4A_File_Support

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Duplicate USE flags

[waltdnes]

On Wed, Jul 06, 2016 at 05:25:01PM +0100, Peter Humphrey wrote

> 
> Well, you could always suggest that in the bug report...

  Done; see comment 2 in the bug.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Xcdroast users : alert

[Mike Gilbert]

On Wed, Jul 6, 2016 at 2:13 PM, Philip Webb  wrote:
> PS I am not receiving e-alerts re comments added to the bug :
> can anyone explain why that mb happening & advise me how to get them ?

You need to add yourself to the CC list field to receive updates via
email. This does not happen automatically.

Re: [gentoo-user] Re: How safe is it to change vanilla-USE-Flag in glibc?

[Fernando Rodriguez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/06/2016 01:10 PM, Franz Fellner wrote:
> On Wed, 06 Jul 2016 15:06:20 +, James  wrote:
>> Franz Fellner  gmail.com> writes:
>>
>>
>>> I have issues with some prgrams eating too much memory. This seems to be
>>> related to glibc not trimming as
>>> necessary which results in way too much memory still occupied by the
>>> program after free()ing memory.
>>
>> Perhaps you should file a bug, providing some evidence if other distros are
>> affected (this suggests it might be a gcc issue) or other distros are not
>> affected (this suggests it might be a gentoo pathch issue)?
> 
> I mentioned my issues several times with the answer "can't be, the issue is 
> on your side".
> When I filed a bug against tmux regarding its memory consumption I got told 
> "glibc is known to do bad things" and I was given this patch for tmux which 
> instantenously solved my issue:
> 
> diff --git a/grid.c b/grid.c
> index ef7c374..96385f4 100644
> --- a/grid.c
> +++ b/grid.c
> @@ -113,6 +113,8 @@ grid_destroy(struct grid *gd)
>   free(gd->linedata);
>  
>   
> +
> + malloc_trim(0);
>  }
>  
>  /* Compare grids. */
> @@ -326,6 +328,8 @@ grid_clear_lines(struct grid *gd, u_int py, u_int ny)
>   free(gl->celldata);
>   memset(gl, 0, sizeof *gl);
>   }
> +
> + malloc_trim(0);
>  }
>  
>  /* Move a group of lines. */
> 
> I have some other applications that are unusable to a certain degree. Having 
> to patch every single application isn't possible, I want to get to the root 
> of the issue :) And USE=vanilla is my first attempt.
> 
> Thx
> Franz
> 

Check out the mallopt(3) man page. You can fine-tune glibc heap through 
environment variables without patches. Specifically use MALLOC_TRIM_THRESHOLD_ 
to tell glibc when to trim and MALLOC_MMAP_THRESHOLD_ to tell it to use mmap() 
to allocate large chunks (so they're returned to the kernel when free()d).

Just setting the trim treshold too low or calling malloc_trim(0) may be a bad 
idea. In some cases it will make your process numbers look better but hurt 
performance because malloc() will have to request memory from the kernel more 
often and on a system with swap it will just be swapped out if needed so it 
shouldn't be a problem unless it's a lot. And if it is a lot I think you should 
be looking somewhere else for the source of the problem.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXfVIcAAoJEPbOFX/5UlwcwT4P/RDvLd6zsvNulN7AYCvPYFr/
2+BZmSSDeKJh5kbdGUzWb8FnqucAeFIBHYdpviEG7umDpZT6RN8MiFeDnK8W8Ww9
jLQyPgSXxTlfFNMGyxnJ/+EphSxPQ0LNjk98etHOKZNx6lM9NSN4kESRpk0LzSEs
Qqp5WWipZU0kMqpfXZDr9U92MFLuSSe/LMRxuovIkz/tqlDHA1HTScob5CCAGmBx
G4m1vxM7dPyv9YDAOELLR2y8CuoJzbiwhxOBAUBFJk3hF9Z1wDW0/8DbcogSwZkd
T4mEQB28zEawjs0aguBXSKYemN3Nik1d1sPokZQ7SKCgVpIT0bHDV/cuoccTsWr0
eliobWgCzipXa15hvccU+xqSD25tZYX3f47T7/IMiwZW4CMFZZtY4X9BX/KTn7/C
Q29M3ZM4NkbmSU27FtpKUQNl4/KrvMypmNBGcqb1BH74Y9Pay0Y9wHb+qeu8eITQ
A07wgCJTtCm0s3dtyU7tu5SU6R2CSbJurJ9pvAHC1qNhQfCQYy3yxOEh0CCrCXC1
5nH94W1W1wjthJzYf728lvFloEpI7uT0RngpTJIR5Fg6Ku5ZA14rv8qANEbLEnTe
hFV32a0cSbp3jMnUyvdYyxx89aOhJ08AU2Wf1L5DF5bMG864E5oH3AZc5a3OeNNu
jJ+zTzNMF2lZ2ePZYcRg
=ALKt
-END PGP SIGNATURE-

[gentoo-user] Re: Xcdroast users : alert

[James]

Philip Webb  ca.inter.net> writes:


> If anyone else uses Xcdroast to write CDs or DVDs,
> I suggest they read Bug 345337 & submit appropriate comments.

Tree-cleaners have been very active. If they prose to removed something
you like, you have options, like volunteering to proxy-maintain the package,
yourself via the proxy-maintainer project::
https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers

equery m xcdroast
 * app-cdr/xcdroast [gentoo]
Maintainer:  None specified


Move it to your own github.

Install it locally (usr/local/portage/), along with sources
in /usr/local/portage/distfiles.


Other ways surely exist.

> There seems to be no problem on single-user systems,
> but a 6-year-old bug which applies to multi-user systems
> is being used as an excuse to remove Xcdroast from the tree.
> There was a similar issue with Nethack recently too.

Reply to the bug with your evidence, plead your case, in bgo. If no timely
responses then discuss it on gentoo-dev.

> PS I am not receiving e-alerts re comments added to the bug :
> can anyone explain why that mb happening & advise me how to get them ?

You probably got listed on the bug to receive updates? What's the bug number?

There is a pseudo mandate to removed insecure packages from the tree.
It's been discussed on gentoo dev. Some new guideline are being 
brought forward on tree-cleaning. I have been actively requesting
for a well defined pathway for such codes. Read this post and you'll
see that one of the devs outlined a process to retrieve old ebuilds
from github. It was really easy, via 'the attic', but the attic is
not github centric, so those new instructions  hopefully will hit the gentoo
wiki and get expanded to allow folks to retrieve old codes. Then
you have to figure out how YOU are going to maintain those old ebuilds.


https://archives.gentoo.org/gentoo-dev/message/305c431c84c39bc74b1077f0b395ce91

hth,
James

[gentoo-user] Xcdroast users : alert

[Philip Webb]

If anyone else uses Xcdroast to write CDs or DVDs,
I suggest they read Bug 345337 & submit appropriate comments.

There seems to be no problem on single-user systems,
but a 6-year-old bug which applies to multi-user systems
is being used as an excuse to remove Xcdroast from the tree.
There was a similar issue with Nethack recently too.

PS I am not receiving e-alerts re comments added to the bug :
can anyone explain why that mb happening & advise me how to get them ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] How safe is it to change vanilla-USE-Flag in glibc?

[Michael Orlitzky]

On 07/06/2016 01:11 PM, Michael Orlitzky wrote:
>>
>> There is a huge glibc-2.23-patches-4.tar.bz2 in my DISTDIR and the patches 
>> get applied.
>>
> 
> Yeah, but they get applied even with USE=vanilla. You can check by
> beginning the emerge, and then hitting Ctrl-C while it's compiling.
> Scroll up and you should see a bunch of "Applying..." lines.
> 

Nevermind, you get different sets of patches with USE=vanilla. The glibc
ebuild is using that illegal eblit garbage. You'll have to get an
opinion from someone who knows what those patches do.

Re: [gentoo-user] How safe is it to change vanilla-USE-Flag in glibc?

[Michael Orlitzky]

On 07/06/2016 01:02 PM, Franz Fellner wrote:
>>
>> It looks to me like USE=vanilla controls only whether or not bundled
>> timezone data is used. If that's the case (double-check!), it's probably
>> safe to unmerge timezone-data and re-emerge glibc with USE=vanilla.
> 
> There is a huge glibc-2.23-patches-4.tar.bz2 in my DISTDIR and the patches 
> get applied.
> 

Yeah, but they get applied even with USE=vanilla. You can check by
beginning the emerge, and then hitting Ctrl-C while it's compiling.
Scroll up and you should see a bunch of "Applying..." lines.

Re: [gentoo-user] Re: How safe is it to change vanilla-USE-Flag in glibc?

[Franz Fellner]

On Wed, 06 Jul 2016 15:06:20 +, James  wrote:
> Franz Fellner  gmail.com> writes:
> 
> 
> > I have issues with some prgrams eating too much memory. This seems to be
> > related to glibc not trimming as
> > necessary which results in way too much memory still occupied by the
> > program after free()ing memory.
> 
> Perhaps you should file a bug, providing some evidence if other distros are
> affected (this suggests it might be a gcc issue) or other distros are not
> affected (this suggests it might be a gentoo pathch issue)?

I mentioned my issues several times with the answer "can't be, the issue is on 
your side".
When I filed a bug against tmux regarding its memory consumption I got told 
"glibc is known to do bad things" and I was given this patch for tmux which 
instantenously solved my issue:

diff --git a/grid.c b/grid.c
index ef7c374..96385f4 100644
--- a/grid.c
+++ b/grid.c
@@ -113,6 +113,8 @@ grid_destroy(struct grid *gd)
free(gd->linedata);
 
free(gd);
+
+   malloc_trim(0);
 }
 
 /* Compare grids. */
@@ -326,6 +328,8 @@ grid_clear_lines(struct grid *gd, u_int py, u_int ny)
free(gl->celldata);
memset(gl, 0, sizeof *gl);
}
+
+   malloc_trim(0);
 }
 
 /* Move a group of lines. */

I have some other applications that are unusable to a certain degree. Having to 
patch every single application isn't possible, I want to get to the root of the 
issue :) And USE=vanilla is my first attempt.

Thx
Franz

Re: [gentoo-user] How safe is it to change vanilla-USE-Flag in glibc?

[Franz Fellner]

On Wed, 06 Jul 2016 11:19:44 -0400, Michael Orlitzky  wrote:
> On 07/06/2016 03:17 AM, Franz Fellner wrote:
> > Hey all,
> > 
> > I have issues with some prgrams eating too much memory. This seems to be 
> > related to glibc not trimming as necessary which results in way too much 
> > memory still occupied by the program after free()ing memory.
> > I can't use gcc (specifically g++) with quite some apps now because it 
> > starts collecting memory (+swap) until everything falls apart, and I 
> > finally came to the conclusion also gcc might suffer from bad trimming 
> > behaviour.
> > As glibc is the package that implements free I want to have a closer look 
> > at it. The first idea is to get rid of Gentoo patches which are controlled 
> > by USE="vanilla". Playing around with glibc might destroy my system. 
> > Downgrades are already unsupported. So my question:
> > 
> > Can I safely switch from -vanilla to +vanilla in glibc?
> > 
> 
> It looks to me like USE=vanilla controls only whether or not bundled
> timezone data is used. If that's the case (double-check!), it's probably
> safe to unmerge timezone-data and re-emerge glibc with USE=vanilla.

There is a huge glibc-2.23-patches-4.tar.bz2 in my DISTDIR and the patches get 
applied.

> To be safe, you can bundle up your existing glibc with quickpkg. Then if
> something goes wrong, you can always boot to a liveCD and unpack the old
> version.

Yes, I know that works ;) But I don't have any livecd around (and most likely 
not even an empty disc, at least it's not therewhere it should be) so it is 
extra work I could avoid if a DEV gives me the OK regarding USE=vanilla.

Thx
Franz

Re: [gentoo-user] Duplicate USE flags

[Peter Humphrey]

On Wednesday 06 Jul 2016 12:11:02 waltd...@waltdnes.org wrote:
> > On Wed, Jul 6, 2016 at 10:31 AM, Mike Gilbert  wrote:
> > >> Hello list,
> > >> 
> > >> Can anyone tell me why we have two USE flags for the same thing?
> > >> Geoloc and geolocation both switch on geolocation but in different
> > >> packages.
> 
>   Would you believe 4 flags?  geolocation/geoip/geoipv2/geoloc



> On Wed, Jul 06, 2016 at 11:05:54AM -0400, Rich Freeman wrote
> 
> > Just to add one note, this happens fairly often, and when people
> > notice we generally fix it.  New USE flags pop up all the time,
> > because new ideas in software come up all the time...
> 
> [i3][waltdnes][~] grep ":geoi\|:geol" /usr/portage/profiles/use.local.desc
> 
> dev-qt/qtwebengine:geolocation - Enable physical position determination via
> dev-qt/qtpositioning dev-qt/qtwebkit:geolocation - Enable physical position
> determination via dev-qt/qtpositioning
> kde-plasma/plasma-workspace:geolocation - Enables dataengine providing
> location information media-gfx/kphotoalbum:geolocation - Add support for
> kde-apps/marble net-analyzer/bro:geoip - Enable support for Maxmind's GeoIP
> library net-analyzer/pmacct:geoipv2 - Add support for GeoIP2 through
> dev-libs/libmaxminddb net-im/empathy:geoloc - Enable geolocation support
> through app-misc/geoclue net-irc/inspircd:geoip - Add geoip support for
> country and city lookup based on IPs net-libs/webkit-gtk:geoloc - Enable
> geolocation support through app-misc/geoclue www-apache/mod_security:geoip
> - Configure ModSecurity to query the GeoIP database from MaxMind, provided
> by dev-libs/geoip. This flag only controls the default configuration, as
> the GeoIP query code is part of ModSecurity's source code.
> 
>   Maybe they should be consolidated into one global flag, and moved out
> of use.local.desc into use.desc.

Well, you could always suggest that in the bug report...

-- 
Rgds
Peter

Re: [gentoo-user] Duplicate USE flags

[waltdnes]

> On Wed, Jul 6, 2016 at 10:31 AM, Mike Gilbert  wrote:
> >> Hello list,
> >>
> >> Can anyone tell me why we have two USE flags for the same thing?
> >> Geoloc and geolocation both switch on geolocation but in different
> >> packages.

  Would you believe 4 flags?  geolocation/geoip/geoipv2/geoloc

On Wed, Jul 06, 2016 at 11:05:54AM -0400, Rich Freeman wrote
> Just to add one note, this happens fairly often, and when people
> notice we generally fix it.  New USE flags pop up all the time,
> because new ideas in software come up all the time...

[i3][waltdnes][~] grep ":geoi\|:geol" /usr/portage/profiles/use.local.desc

dev-qt/qtwebengine:geolocation - Enable physical position determination via 
dev-qt/qtpositioning
dev-qt/qtwebkit:geolocation - Enable physical position determination via 
dev-qt/qtpositioning
kde-plasma/plasma-workspace:geolocation - Enables dataengine providing location 
information
media-gfx/kphotoalbum:geolocation - Add support for kde-apps/marble
net-analyzer/bro:geoip - Enable support for Maxmind's GeoIP library
net-analyzer/pmacct:geoipv2 - Add support for GeoIP2 through 
dev-libs/libmaxminddb
net-im/empathy:geoloc - Enable geolocation support through app-misc/geoclue
net-irc/inspircd:geoip - Add geoip support for country and city lookup based on 
IPs
net-libs/webkit-gtk:geoloc - Enable geolocation support through app-misc/geoclue
www-apache/mod_security:geoip - Configure ModSecurity to query the GeoIP 
database from MaxMind, provided by dev-libs/geoip. This flag only controls the 
default configuration, as the GeoIP query code is part of ModSecurity's source 
code.

  Maybe they should be consolidated into one global flag, and moved out
of use.local.desc into use.desc.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Duplicate USE flags

[Peter Humphrey]

On Wednesday 06 Jul 2016 10:31:26 Mike Gilbert wrote:
> On Wed, Jul 6, 2016 at 5:10 AM, Peter Humphrey  
wrote:
> > Hello list,
> > 
> > Can anyone tell me why we have two USE flags for the same thing? Geoloc
> > and
> > geolocation both switch on geolocation but in different packages.
> > 
> > This duplication caused me much head-scratching and needless extra work in
> > trying to install a plasma system without NetworkManager.
> 
> Two different developers working on separate packages came up with
> similar looking USE flags. The GNOME team went with geoloc, while the
> KDE team went with geolocation.

I think they're more than similar looking: they're functionally identical.

> Contact the relevant developers or file a bug if you think they should
> be consolidated.

Done:   https://bugs.gentoo.org/show_bug.cgi?id=588168

-- 
Rgds
Peter

Re: [gentoo-user] How safe is it to change vanilla-USE-Flag in glibc?

[Michael Orlitzky]

On 07/06/2016 03:17 AM, Franz Fellner wrote:
> Hey all,
> 
> I have issues with some prgrams eating too much memory. This seems to be 
> related to glibc not trimming as necessary which results in way too much 
> memory still occupied by the program after free()ing memory.
> I can't use gcc (specifically g++) with quite some apps now because it starts 
> collecting memory (+swap) until everything falls apart, and I finally came to 
> the conclusion also gcc might suffer from bad trimming behaviour.
> As glibc is the package that implements free I want to have a closer look at 
> it. The first idea is to get rid of Gentoo patches which are controlled by 
> USE="vanilla". Playing around with glibc might destroy my system. Downgrades 
> are already unsupported. So my question:
> 
> Can I safely switch from -vanilla to +vanilla in glibc?
> 

It looks to me like USE=vanilla controls only whether or not bundled
timezone data is used. If that's the case (double-check!), it's probably
safe to unmerge timezone-data and re-emerge glibc with USE=vanilla.

To be safe, you can bundle up your existing glibc with quickpkg. Then if
something goes wrong, you can always boot to a liveCD and unpack the old
version.

Re: [gentoo-user] OT: what audio file format / container to play on Android.

[Stroller]

> On 5 Jul 2016, at 16:54, wabe  wrote:
> 
> If you wanna put the audio data into another container without recoding
> it, you can use for example something like that:
> 
> ffmpeg -i filename.mp4 -acodec copy filename.m4a

This has worked. Many thanks for your help.

I did not actually expect this, as I thought .mp4 and .m4a were the same thing 
(see links below) and renaming the .mp4 to .m4a  did not have any effect.

ffmpeg did, however, seem to do no more than copy the stream (it took only a 
second or so), so presumably it has marked the container differently somehow. 
See attached, anyone who's interested.

I appreciate the contributions of all who've replied,

Stroller.



[1] http://stackoverflow.com/questions/9412384/
[2] https://en.wikipedia.org/wiki/MPEG-4_Part_14#.MP4_versus_.M4A
[3] https://wiki.jriver.com/index.php/MP4_and_M4A_File_Support



$ youtube-dl http://www.bbc.co.uk/programmes/b07fl5bh
[bbc.co.uk] b07fl5bh: Downloading video page
[bbc.co.uk] b07fl2qw: Downloading media selection XML
[bbc.co.uk] b07fl2qw: Downloading m3u8 information
[bbc.co.uk] b07fl2qw: Downloading m3u8 information
[bbc.co.uk] b07fl2qw: Downloading m3u8 information
[hlsnative] Downloading m3u8 manifest
[hlsnative] Total fragments: 390
[download] Destination: The Bronze Age Collapse, In Our Time - BBC Radio 
4-b07fl2qw.mp4
[download] 100% of 40.56MiB in 01:36
[ffmpeg] Fixing malformated aac bitstream in "The Bronze Age Collapse, In Our 
Time - BBC Radio 4-b07fl2qw.mp4"
$ ffmpeg -i The\ Bronze\ Age\ Collapse\,\ In\ Our\ Time\ -\ BBC\ Radio\ 4-b07fl2
qw.mp4 -acodec copy The\ Bronze\ Age\ Collapse\,\ In\ Our\ Time\ -\ BBC\ Radio\
4\ \[b07fl2qw\].m4a
ffmpeg version 2.6.3 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.8.5 (Gentoo 4.8.5 p1.3, pie-0.6.2)
  configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 
--mandir=/usr/share/man --enable-shared --cc=x86_64-pc-linux-gnu-gcc 
--cxx=x86_64-pc-linux-gnu-g++ --ar=x86_64-pc-linux-gnu-ar --optflags=' ' 
--disable-static --enable-avfilter --enable-avresample --disable-stripping 
--enable-nonfree --enable-version3 --enable-nonfree --disable-indev=v4l2 
--disable-outdev=v4l2 --disable-indev=alsa --disable-indev=oss 
--disable-indev=jack --disable-outdev=alsa --disable-outdev=oss 
--disable-outdev=sdl --enable-version3 --enable-bzlib 
--disable-runtime-cpudetect --disable-debug --disable-doc --disable-gnutls 
--enable-gpl --enable-hardcoded-tables --enable-iconv --enable-lzma 
--enable-network --enable-openssl --enable-postproc --disable-libsmbclient 
--disable-ffplay --disable-vaapi --disable-vdpau --disable-xlib 
--disable-libxcb --disable-libxcb-shm --disable-libxcb-xfixes --enable-zlib 
--enable-libcdio --disable-libiec61883 --disable-libdc1394 --disable-libcaca 
--disable-openal --disable-opengl --disable-libv4l2 --disable-libpulse 
--enable-libopencore-amrwb --enable-libopencore-amrnb --disable-libfdk-aac 
--enable-libopenjpeg --enable-libbluray --disable-libcelt --disable-libgme 
--enable-libgsm --disable-libmodplug --disable-libopus --disable-libquvi 
--enable-librtmp --enable-libssh --enable-libschroedinger --disable-libspeex 
--enable-libvorbis --enable-libvpx --disable-libzvbi --disable-libbs2b 
--disable-libflite --disable-frei0r --disable-libfribidi --disable-fontconfig 
--disable-ladspa --enable-libass --enable-libfreetype --enable-libsoxr 
--enable-pthreads --enable-libvo-aacenc --disable-libvo-amrwbenc 
--enable-libmp3lame --enable-libaacplus --disable-libfaac --enable-libtheora 
--enable-libtwolame --disable-libwavpack --enable-libwebp --enable-libx264 
--enable-libx265 --enable-libxvid --disable-x11grab --disable-avx 
--disable-avx2 --disable-fma3 --disable-fma4 --disable-ssse3 --disable-sse4 
--disable-sse42 --disable-xop --cpu=host
  libavutil  54. 20.100 / 54. 20.100
  libavcodec 56. 26.100 / 56. 26.100
  libavformat56. 25.101 / 56. 25.101
  libavdevice56.  4.100 / 56.  4.100
  libavfilter 5. 11.102 /  5. 11.102
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale  3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc53.  3.100 / 53.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'The Bronze Age Collapse, In Our Time - 
BBC Radio 4-b07fl2qw.mp4':
  Metadata:
major_brand : isom
minor_version   : 512
compatible_brands: isomiso2mp41
encoder : Lavf56.25.101
  Duration: 00:41:35.92, start: 0.00, bitrate: 129 kb/s
Stream #0:0(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, 
fltp, 128 kb/s (default)
Metadata:
  handler_name: SoundHandler
Output #0, ipod, to 'The Bronze Age Collapse, In Our Time - BBC Radio 4 
[b07fl2qw].m4a':
  Metadata:
major_brand : isom
minor_version   : 512
compatible_brands: isomiso2mp41
encoder : Lavf56.25.101
Stream #0:0(eng): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, 128 
kb/s (default)
Metadata:
  handler_name: 

Re: [gentoo-user] OT: what audio file format / container to play on Android.

[Stroller]

> On 5 Jul 2016, at 23:33, Neil Bothwick  wrote:
> On Sat, 2 Jul 2016 13:30:16 +0100, Stroller wrote:
> 
>> The question may boil down to the Google Drive audio / video player,
>> and its (in)ability to play AAC audio. But that would be surprising,
>> don't you think?
> 
> Possibly, but easy to test. Download the file from drive to local
> storage then try to play it with another player.
> 
> If the problem is a limitation of the Drive player, maybe the best
> approach is to not use drive and use something [else]

It was lazy of me not to download and test it myself, I do admit.

I didn't expect this question to cause such consternation.

Stroller.

[gentoo-user] Re: How safe is it to change vanilla-USE-Flag in glibc?

[James]

Franz Fellner  gmail.com> writes:


> I have issues with some prgrams eating too much memory. This seems to be
related to glibc not trimming as
> necessary which results in way too much memory still occupied by the
program after free()ing memory.

Perhaps you should file a bug, providing some evidence if other distros are
affected (this suggests it might be a gcc issue) or other distros are not
affected (this suggests it might be a gentoo pathch issue)?

> Franz


hth,
James

Re: [gentoo-user] Duplicate USE flags

[Rich Freeman]

On Wed, Jul 6, 2016 at 10:31 AM, Mike Gilbert  wrote:
> On Wed, Jul 6, 2016 at 5:10 AM, Peter Humphrey  wrote:
>> Hello list,
>>
>> Can anyone tell me why we have two USE flags for the same thing? Geoloc and
>> geolocation both switch on geolocation but in different packages.
>>
>> This duplication caused me much head-scratching and needless extra work in
>> trying to install a plasma system without NetworkManager.
>
> Two different developers working on separate packages came up with
> similar looking USE flags. The GNOME team went with geoloc, while the
> KDE team went with geolocation.
>
> Contact the relevant developers or file a bug if you think they should
> be consolidated.
>

Just to add one note, this happens fairly often, and when people
notice we generally fix it.  New USE flags pop up all the time,
because new ideas in software come up all the time...

-- 
Rich

Re: [gentoo-user] Duplicate USE flags

[Mike Gilbert]

On Wed, Jul 6, 2016 at 5:10 AM, Peter Humphrey  wrote:
> Hello list,
>
> Can anyone tell me why we have two USE flags for the same thing? Geoloc and
> geolocation both switch on geolocation but in different packages.
>
> This duplication caused me much head-scratching and needless extra work in
> trying to install a plasma system without NetworkManager.

Two different developers working on separate packages came up with
similar looking USE flags. The GNOME team went with geoloc, while the
KDE team went with geolocation.

Contact the relevant developers or file a bug if you think they should
be consolidated.

[gentoo-user] Duplicate USE flags

[Peter Humphrey]

Hello list,

Can anyone tell me why we have two USE flags for the same thing? Geoloc and 
geolocation both switch on geolocation but in different packages.

This duplication caused me much head-scratching and needless extra work in 
trying to install a plasma system without NetworkManager.

-- 
Rgds
Peter

Re: [gentoo-user] Wrong SHA512 checksum for 20160630 amd64 minimal installation medium

[Marvin Gülker]

Am Tue, 5 Jul 2016 15:07:03 +0100
schrieb Stroller :
> This doesn't address the wider implications of this dodgy checksums,
> but I think most people on this list install using SystemRescueCD.

Okay, I’ll go that route then. Thank you again!

Greetings
Marvin

-- 
Blog: http://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F

[gentoo-user] How safe is it to change vanilla-USE-Flag in glibc?

[Franz Fellner]

Hey all,

I have issues with some prgrams eating too much memory. This seems to be 
related to glibc not trimming as necessary which results in way too much memory 
still occupied by the program after free()ing memory.
I can't use gcc (specifically g++) with quite some apps now because it starts 
collecting memory (+swap) until everything falls apart, and I finally came to 
the conclusion also gcc might suffer from bad trimming behaviour.
As glibc is the package that implements free I want to have a closer look at 
it. The first idea is to get rid of Gentoo patches which are controlled by 
USE="vanilla". Playing around with glibc might destroy my system. Downgrades 
are already unsupported. So my question:

Can I safely switch from -vanilla to +vanilla in glibc?

This is how glibc currently is installed:
sys-libs/glibc-2.23-r2(multilib rpc -audit -caps -debug -gd -hardened -nscd 
-profile -selinux -suid -systemtap -vanilla CROSSCOMPILE_OPTS="-headers-only")

Thx for your help
Franz