Commit dbc02c24 authored by Jeremy Bicha's avatar Jeremy Bicha

New upstream version 2.9.39

parents 1ae07919 b5af6877
Andre Moreira Magalhaes <andrunko[@]gmail.com>
Jonathan Matthew <jonathan[@]d14n.org>
William Jon McCann <jmccann[@]redhat.com>
W. Michael Petullo <mike[@]flyn.org>
Charles Schmidt <cschmidt2[@]gmail.com>
Alexandre Rosenfeld <alexandre.rosenfeld[@]gmail.com>
Noah Alcantara <black.ic[@]gmail.com>
A GObject-based DAAP library was first written as a plugin for
Rhythmbox by Charles Schmidt. This work was done as a part of the
2005 Google Summer of Code program. A few other developers, most
notably Jonathan Matthew and William Jon McCann, contributed to the
DAAP plugin after it was integrated into the Rhythmbox project.
Later, Andre Magalhaes expanded Charles' code into a general purpose
DMAP library, libdmapsharing. This library was used by a product
called Canola and was available on SourceForge. The Canola project
dropped support for DMAP before releasing its second version and
the development of the libdmapsharing library stopped. At this
point, libdmapsharing supported the client side of the DMAP protocol.
W. Michael Petullo pulled the libdmapsharing sources from SourceForge
in December of 2008. He began to add support for the server side of
the DMAP protocol, pulling the latest DAAP sharing code from Rhythmbox
and modifying it to support DPAP. Mike's changes were merged back into
the SourceForge in January of 2009 after he was made a member of the
libdmapsharing development team. The libdmapsharing project was moved
from SourceForge to GNOME Git in August of 2009.
Alexandre Rosenfeld added initial DACP support to libdmapsharing while
working on his 2010 Google Summer of Code project.
Noah Alcantara contributed client-side support for mDNS/DNS-SD on Mac
OS X early in 2011.
The original authors of Rhythmbox's DAAP plugin have endorsed the
re-licensing of their code to LGPL in the following two emails:
Date: Sun, 11 Jan 2009 14:46:35 -0500
From: Charles Schmidt <cschmidt2[@]gmail.com>
To: "W. Michael Petullo" <mike[@]flyn.org>
Subject: Re: LGPL of Rhythmbox DAAP Code
Cc: "cschmidt2[@]emich.edu" <cschmidt2[@]emich.edu>,
"jmccann[@]redhat.com" <jmccann[@]redhat.com>,
"jonathan[@]d14n.org" <jonathan[@]d14n.org>
Totally fine by me. Is there a website or vcs I can look at?
Charlie Schmidt
On Jan 11, 2009, at 2:30 PM, "W. Michael Petullo" <mike[@]flyn.org> wrote:
> Charles, Jon & Jonathan,
>
> I recently began maintaining the libdmapsharing library, a DMAP
> library originally based on Rhythmbox's DAAP plugin. The library is
> distributed under the LGPL license. Your original work was
> distributed under the GPL.
>
> The original maintainer of libdmapsharing has stated that he
> obtained permission from you regarding the relicensing of your code
> to the LGPL. If you do not have any objections, would each of you
> provide me with a brief statement to this effect that I may formally
> distribute with libdmapsharing?
>
> The following files were used in developing libdmapsharing:
>
> rb-daap-connection.c
> rb-daap-connection.h
> rb-daap-hash.c
> rb-daap-hash.h
> rb-daap-mdns-avahi.c
> rb-daap-mdns-avahi.h
> rb-daap-mdns-browser-avahi.c
> rb-daap-mdns-browser.h
> rb-daap-mdns-publisher-avahi.c
> rb-daap-mdns-publisher.h
> rb-daap-share.c
> rb-daap-share.h
> rb-daap-structure.c
> rb-daap-structure.h
>
> Thank you.
>
> Sincerely,
>
> Mike Petullo
Date: Wed, 14 Jan 2009 21:00:45 +1000
From: Jonathan Matthew <jonathan[@]d14n.org>
To: "W. Michael Petullo" <mike[@]flyn.org>
Subject: Re: LGPL of Rhythmbox DAAP Code
On Sun, Jan 11, 2009 at 02:30:15PM -0500, W. Michael Petullo wrote:
> Charles, Jon & Jonathan,
>
> I recently began maintaining the libdmapsharing library, a DMAP library
> originally based on Rhythmbox's DAAP plugin. The library is distributed
> under the LGPL license. Your original work was distributed under the GPL.
>
> The original maintainer of libdmapsharing has stated that he obtained
> permission from you regarding the relicensing of your code to the LGPL.
> If you do not have any objections, would each of you provide me with a
> brief statement to this effect that I may formally distribute with
> libdmapsharing?
>
sure, why not.
enjoy,
-jonathan
Alexandre Rosenfeld also confirmed that the GPL notice on dacp-player.[ch]
was not intentional:
Sure, sorry about that, I used a template for that code, it was never my
intention to make it GPL....
*Alexandre Rosenfeld*
On Fri, Sep 3, 2010 at 14:46, W. Michael Petullo <mike@flyn.org> wrote:
> Alexandre,
>
> I just noticed that dacp-player.[ch] are licensed as GPL. This should
> be LGPL because libdmapsharing is LGPL. May I have your permission to
> change the license of these files to LGPLv2.1+?
Andre Moreira Magalhaes approved the use of LGPL for test-dmap-client.c.
Please do it, no problem at all
BR
Andre
> Andre,
>
> I have been maintaining libdmapsharing and recently noticed that
> tests/test-dmap-client.c and test-dmap-server.c are licensed as
> GPL and you are the copyright holder. May I change this to LGPLv2.1+ in
> order to match the rest of libdmapsharing? This will make distribution
> easier as packages may be licensed at LGPLv2.1+ only.
>
> --
> Mike
This diff is collapsed.
This source diff could not be displayed because it is too large. You can view the blob instead.
Installation Instructions
*************************
Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005 Free
Software Foundation, Inc.
This file is free documentation; the Free Software Foundation gives
unlimited permission to copy, distribute and modify it.
Basic Installation
==================
These are generic installation instructions.
The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a `Makefile' in each directory of the package.
It may also create one or more `.h' files containing system-dependent
definitions. Finally, it creates a shell script `config.status' that
you can run in the future to recreate the current configuration, and a
file `config.log' containing compiler output (useful mainly for
debugging `configure').
It can also use an optional file (typically called `config.cache'
and enabled with `--cache-file=config.cache' or simply `-C') that saves
the results of its tests to speed up reconfiguring. (Caching is
disabled by default to prevent problems with accidental use of stale
cache files.)
If you need to do unusual things to compile the package, please try
to figure out how `configure' could check whether to do them, and mail
diffs or instructions to the address given in the `README' so they can
be considered for the next release. If you are using the cache, and at
some point `config.cache' contains results you don't want to keep, you
may remove or edit it.
The file `configure.ac' (or `configure.in') is used to create
`configure' by a program called `autoconf'. You only need
`configure.ac' if you want to change it or regenerate `configure' using
a newer version of `autoconf'.
The simplest way to compile this package is:
1. `cd' to the directory containing the package's source code and type
`./configure' to configure the package for your system. If you're
using `csh' on an old version of System V, you might need to type
`sh ./configure' instead to prevent `csh' from trying to execute
`configure' itself.
Running `configure' takes awhile. While running, it prints some
messages telling which features it is checking for.
2. Type `make' to compile the package.
3. Optionally, type `make check' to run any self-tests that come with
the package.
4. Type `make install' to install the programs and any data files and
documentation.
5. You can remove the program binaries and object files from the
source code directory by typing `make clean'. To also remove the
files that `configure' created (so you can compile the package for
a different kind of computer), type `make distclean'. There is
also a `make maintainer-clean' target, but that is intended mainly
for the package's developers. If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.
Compilers and Options
=====================
Some systems require unusual options for compilation or linking that the
`configure' script does not know about. Run `./configure --help' for
details on some of the pertinent environment variables.
You can give `configure' initial values for configuration parameters
by setting variables in the command line or in the environment. Here
is an example:
./configure CC=c89 CFLAGS=-O2 LIBS=-lposix
*Note Defining Variables::, for more details.
Compiling For Multiple Architectures
====================================
You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory. To do this, you must use a version of `make' that
supports the `VPATH' variable, such as GNU `make'. `cd' to the
directory where you want the object files and executables to go and run
the `configure' script. `configure' automatically checks for the
source code in the directory that `configure' is in and in `..'.
If you have to use a `make' that does not support the `VPATH'
variable, you have to compile the package for one architecture at a
time in the source code directory. After you have installed the
package for one architecture, use `make distclean' before reconfiguring
for another architecture.
Installation Names
==================
By default, `make install' installs the package's commands under
`/usr/local/bin', include files under `/usr/local/include', etc. You
can specify an installation prefix other than `/usr/local' by giving
`configure' the option `--prefix=PREFIX'.
You can specify separate installation prefixes for
architecture-specific files and architecture-independent files. If you
pass the option `--exec-prefix=PREFIX' to `configure', the package uses
PREFIX as the prefix for installing programs and libraries.
Documentation and other data files still use the regular prefix.
In addition, if you use an unusual directory layout you can give
options like `--bindir=DIR' to specify different values for particular
kinds of files. Run `configure --help' for a list of the directories
you can set and what kinds of files go in them.
If the package supports it, you can cause programs to be installed
with an extra prefix or suffix on their names by giving `configure' the
option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
Optional Features
=================
Some packages pay attention to `--enable-FEATURE' options to
`configure', where FEATURE indicates an optional part of the package.
They may also pay attention to `--with-PACKAGE' options, where PACKAGE
is something like `gnu-as' or `x' (for the X Window System). The
`README' should mention any `--enable-' and `--with-' options that the
package recognizes.
For packages that use the X Window System, `configure' can usually
find the X include and library files automatically, but if it doesn't,
you can use the `configure' options `--x-includes=DIR' and
`--x-libraries=DIR' to specify their locations.
Specifying the System Type
==========================
There may be some features `configure' cannot figure out automatically,
but needs to determine by the type of machine the package will run on.
Usually, assuming the package is built to be run on the _same_
architectures, `configure' can figure that out, but if it prints a
message saying it cannot guess the machine type, give it the
`--build=TYPE' option. TYPE can either be a short name for the system
type, such as `sun4', or a canonical name which has the form:
CPU-COMPANY-SYSTEM
where SYSTEM can have one of these forms:
OS KERNEL-OS
See the file `config.sub' for the possible values of each field. If
`config.sub' isn't included in this package, then this package doesn't
need to know the machine type.
If you are _building_ compiler tools for cross-compiling, you should
use the option `--target=TYPE' to select the type of system they will
produce code for.
If you want to _use_ a cross compiler, that generates code for a
platform different from the build platform, you should specify the
"host" platform (i.e., that on which the generated programs will
eventually be run) with `--host=TYPE'.
Sharing Defaults
================
If you want to set default values for `configure' scripts to share, you
can create a site shell script called `config.site' that gives default
values for variables like `CC', `cache_file', and `prefix'.
`configure' looks for `PREFIX/share/config.site' if it exists, then
`PREFIX/etc/config.site' if it exists. Or, you can set the
`CONFIG_SITE' environment variable to the location of the site script.
A warning: not all `configure' scripts look for a site script.
Defining Variables
==================
Variables not defined in a site shell script can be set in the
environment passed to `configure'. However, some packages may run
configure again during the build, and the customized values of these
variables may be lost. In order to avoid this problem, you should set
them in the `configure' command line, using `VAR=value'. For example:
./configure CC=/usr/local2/bin/gcc
causes the specified `gcc' to be used as the C compiler (unless it is
overridden in the site shell script). Here is a another example:
/bin/bash ./configure CONFIG_SHELL=/bin/bash
Here the `CONFIG_SHELL=/bin/bash' operand causes subsequent
configuration-related scripts to be executed by `/bin/bash'.
`configure' Invocation
======================
`configure' recognizes the following options to control how it operates.
`--help'
`-h'
Print a summary of the options to `configure', and exit.
`--version'
`-V'
Print the version of Autoconf used to generate the `configure'
script, and exit.
`--cache-file=FILE'
Enable the cache: use and save the results of the tests in FILE,
traditionally `config.cache'. FILE defaults to `/dev/null' to
disable caching.
`--config-cache'
`-C'
Alias for `--cache-file=config.cache'.
`--quiet'
`--silent'
`-q'
Do not print messages saying which checks are being made. To
suppress all normal output, redirect it to `/dev/null' (any error
messages will still be shown).
`--srcdir=DIR'
Look for the package's source code in directory DIR. Usually
`configure' can determine that directory automatically.
`configure' also accepts some other, not widely useful, options. Run
`configure --help' for more details.
SUBDIRS = libdmapsharing vala tests doc
DIST_SUBDIRS = $(SUBDIRS) m4 media
# pcfiles = libdmapsharing-@LIBDMAPSHARING_MAJORMINOR@.pc
pcfiles = libdmapsharing-@API_VERSION@.pc
pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = $(pcfiles)
EXTRA_DIST = \
autogen.sh \
libdmapsharing-@API_VERSION@-uninstalled.pc \
README-Memory
This diff is collapsed.
Libdmapsharing is a library which allows programs to access, share
and control the playback of media content using DMAP (DAAP, DPAP &
DACP). Libdmapsharing also detects audio AirPlay services; coupled
with the AirPlay support in PulseAudio or GStreamer, this can allow an
application to stream audio to an AirPlay device. The library presently
supports Linux and other POSIX-based systems. It is written in C using
GObject and libsoup. The DMAP family of protocols are used by products
such as Apple iTunes, Apple iPhoto, and the Roku SoundBridge family to
share media such as music and photos.
For documentation on libdmapsharing's API,
please refer to the API documentation, available at
http://www.flyn.org/projects/libdmapsharing/docs/ or with the
libdmapsharing source code.
This documents the effort to make dmapd and libdmapsharing more memory
efficient. This document describes work done in both libdmapsharing and
dmapd, because dmapd is the primary application of libdmapsharing's
server-side functionality.
I found that dmapd used a significant amount of heap space while trying to
port dmapd to OpenWRT on a WRT160NL router with 32 Megabytes of RAM. A
2,419-song library caused dmapd on x86_64 to use 7,413,760 bytes of heap
space after reading the library into memory. Furthermore, connecting to
dmapd using a DAAP client and receiving a list of songs caused heap usage
to increase to over 10 Megabytes. Note that this memory usage might be
smaller on the WRT160NL due to its 32-bit architecture, but it is still
significant in size.
After attempting to optimize memory use, I measured the following on
OpenWrt / WRT160NL (*** BUT WITH NO METADATA READ! ***):
Heap, after music is loaded: 0xf5000 (1,003,520)
Heap, after client received song list: 0x926000 (9,592,832)
SOME METADATA (MP3 ONLY):
Heap, after music is loaded: 0x2d3000 (2,961,408)
Heap, after client received song list: 0xafa000 (11,509,760)
I use the following tools to troubleshoot memory issues:
grep heap /proc/PID/maps (current heap size)
valgrind / memcheck (memory leaks)
valgrind / massif (max heap size and memory over time)
gdb
objdump -t OBJECT-FILE | grep -e "\.bss" -e "\.data" | sort -k5
| c++filt | tail
I have made the following changes in order to make dmapd more memory
efficient:
1. Replace the hash table-based DMAPDb implementation with a Berkeley
Database implementation. Currently measuring the memory use compared to
the in-memory database.
2. Fixed several memory leaks after analyzing with valgrind.
Heap without client connection: 3,940,352 bytes
3. Implement database cache so that dmapd does not need to use GStreamer
to read media metadata each time it is run.
Heap without client connection using DB cache: 3,346,432 bytes
4. Replace the DMAPDb in the DMAPContainerRecord implementation with a
GSList of ID's.
Heap without client connection using DB cache: 4,759,552 bytes
5. Implement "stringletons" and fix errors in 4) above.
Heap without client connection using DB cache: 2,854,912 bytes
Heap without client connection: 3,518,464 bytes
Heap after client connection and song list: 6,864,896 bytes
Max heap usages (massif): 8,945,760 bytes
6. Modify libdmapsharing so that it responds to "/1/items" requests in
chunks, avoiding the need to build the entire response in memory.
The effectiveness of this can be measured by observing the
maximum heap usage after a client has asked for a full media
list. Previous to this change, dmapd would use 7,811,072 bytes
of heap to describe a 2,232-song library. After this change,
dmapd's usage was 3,665,920 bytes, a very small increase over
the memory used by dmapd immediately after starting.
7. Write a disk-based database for dmapd.
In order to minimize the memory used by a newly started dmapd,
I wrote a disk-based DMAPDb backend. This backend stores all
database data in files and avoids storing the entire database
in memory. To measure the effectiveness, I measured the memory
usage of dmapd after loading a 3,276-photograph library (note
that thumbnails are especially problematic). The GHashTable-based
database used 35,885,056 bytes of heap space. The disk-based
database used 4,763,648 bytes.
8. Decompressing multiple scan JPEG's.
VIPS must decompress multiple scan JPEG's fully in memory due
to the way libjpeg works. Either 1) use embedded EXIF thumbnail
or 2) skip.
= Short term ===================================================================
GNOME Bugs:
344616: support database updates
686220: play nicely with firewalld
705539: confirm two share scenario fixed (seems to be in rhythmbox 3.0.2)
727839: wierd startup warning
705949: grilo
Noah: DNS-SD implementation
Finish browser side support.
Documentation:
Improve content (Noah?)
Fix alignment of object description code
Fix "up" icon in second level pages
Add standard sidebar
Improve aesthetics
= Mid term =====================================================================
Fix callbacks so that they do not provide a gpointer (see service-added
callback). They need to provide a proper GObject type (e.g., a new
DMAPMdnsBrowserService type) so that Python/GObject introspection works.
Noah: Comment purpose of each source file and describe interfaces, using test
programs as examples (Note: wait on doxygen vs. gtk-doc decision.
Mike: Realtime transcode: must g_input_stream_close what is returned from
daap_record_read, unless I change API (see also dmapd.c)
= Long term ====================================================================
API Changes:
now_playing_artwork seems to return a filename, so should return a gchar *, not guchar *?
Stuff related to Python introspection
Allow single client to more easily make use of both DAAP and DPAP (embed type in browser service?)
Mike: Audit remaining GSoC patch:
--- dmap-db.c
--- dmap-share.c
--- dacp-player.c
--- dacp-player.h
--- dacp-share.c
--- dacp-share.h
Mike: Add support for browse= on DMAPConnection side to filter results (see dmap-share.c).
Mike: Functions that could be simplified:
compare_record_property()
apply_filter()/_dmap_share_build_filter() (lex/yacc?)
Mike: Add support for DMAP_CC_MSUP, dmap.supportsupdate
Something odd (as best as I can remember):
TunesRemote+ on Android emulator
Ryhthmbox on same machine
Two network interfaces (i.e., _touch-remote._tcp listed twice by avahi-browse)
Rhythmbox:
Remote listed twice
If "wrong" remote selected:
entry_insert_text_cb has service_name set to garbled value
mdns_remote_added has service_name set to correct value
Mike: Where to handle DACP-specific stuff in dmap-mdns-browser-avahi.c?
Mike: Does, e.g., handle_server_info need user_data parameter?
Mike: Replace dmap-md5.[ch] with GChecksum.
Mike: Ensure client test catches newly shared files?
Mike: Do transcode based on client?
Mike: Fix seeking.
Mike: Clean up test_dmap_server.
Fix code that determines path of test.jpeg.
Mike: See FIXME's in dmap-share.c, daap-share.c, daap-record.c and dpap-share.c.
This diff is collapsed.
This diff is collapsed.
#! /bin/sh
# Wrapper for compilers which do not understand '-c -o'.
scriptversion=2012-10-14.11; # UTC
# Copyright (C) 1999-2014 Free Software Foundation, Inc.
# Written by Tom Tromey <tromey@cygnus.com>.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
# As a special exception to the GNU General Public License, if you
# distribute this file as part of a program that contains a
# configuration script generated by Autoconf, you may include it under
# the same distribution terms that you use for the rest of that program.
# This file is maintained in Automake, please report
# bugs to <bug-automake@gnu.org> or send patches to
# <automake-patches@gnu.org>.
nl='
'
# We need space, tab and new line, in precisely that order. Quoting is
# there to prevent tools from complaining about whitespace usage.
IFS=" "" $nl"
file_conv=
# func_file_conv build_file lazy
# Convert a $build file to $host form and store it in $file
# Currently only supports Windows hosts. If the determined conversion
# type is listed in (the comma separated) LAZY, no conversion will
# take place.
func_file_conv ()
{
file=$1
case $file in
/ | /[!/]*) # absolute file, and not a UNC file
if test -z "$file_conv"; then
# lazily determine how to convert abs files
case `uname -s` in
MINGW*)
file_conv=mingw
;;
CYGWIN*)
file_conv=cygwin
;;
*)
file_conv=wine
;;
esac
fi
case $file_conv/,$2, in
*,$file_conv,*)
;;
mingw/*)
file=`cmd //C echo "$file " | sed -e 's/"\(.*\) " *$/\1/'`
;;
cygwin/*)
file=`cygpath -m "$file" || echo "$file"`
;;
wine/*)
file=`winepath -w "$file" || echo "$file"`
;;
esac
;;
esac
}
# func_cl_dashL linkdir
# Make cl look for libraries in LINKDIR
func_cl_dashL ()
{