[debian-hurd-Patches][311571] Bug#522100: pulseaudio FTBFS (debian-ports)
Patches item #311571, was changed at 2009-03-31 21:08 by Emilio Pozuelo Monfort
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=410472&aid=311571&group_id=30628
Status: Open
Priority: 3
Submitted By: Samuel Thibault (sthibaul-guest)
Assigned to: Nobody (None)
Summary: Bug#522100: pulseaudio FTBFS (debian-ports)
Category: None
Group: None
Resolution: None
Initial Comment:
PATH_MAX, PIPE_MAX, pthread_setaffinity, alsa/evdev build fix.
----------------------------------------------------------------------
>Comment By: Emilio Pozuelo Monfort (pochu)
Date: 2010-01-29 00:38
Message:
The patch still applies and builds with 0.9.21
----------------------------------------------------------------------
Comment By: Pino Toscano (pino-guest)
Date: 2009-10-30 22:39
Message:
This is a first attempt in a porting patch for pulseaudio 0.9.19.
Below the various problems and eventual solutions found:
- src/pulse/context.c: usage of SA_NOCLDWAIT
sigaction(2) shows it is Linux-only, and waitpid(2) says that checking for the presence of that flag and checking that the handler is SIG_IGN is equivalent; thus, make the SA_NOCLDWAIT flag check optionally compiled depending on the SA_NOCLDWAIT presence
- src/pulsecore/memtrap.c: SA_SIGINFO
the first step is using a simple sa_handler if SA_SIGINFO is not defined;
futhermore, PA remaps memory in the SIGBUS signal handler, using the data provided in the siginfo_t,
so just fail in the simple signal handler
- src/modules/rtp/module-rtp-recv.c: SO_TIMESTAMP
Hurd does not support activating the timestamp receiving for sockets, so enable it only if SO_TIMESTAMP is defined
- src/modules/rtp/rtp.c: SO_TIMESTAMP
most probably the right type to check should be SCM_TIMESTAMP, like other types available for cmsg_type (eg SCM_RIGHTS)
- src/modules/module-pipe-source.c:
- src/utils/pacmd.c: PIPE_BUF
no solution yet, manual #define for now
- debian/rules: autogeneration of pulseaudio.install for Hurd
used the same approach used for kfreebsd-*
Of course, given the PIPE_BUF stuff (and the review needed) it is not worth being sent upstream yet, but I thought posting it could have been useful for others to take a look.
----------------------------------------------------------------------
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=410472&aid=311571&group_id=30628
Reply to: