[debian-hurd-Patches][311571] Bug#522100: pulseaudio FTBFS (debian-ports)
Patches item #311571, was changed at 31/03/2009 21:08 by Samuel Thibault
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: Samuel Thibault (sthibault)
Date: 07/05/2010 02:37
Message:
It seems fine, please submit, thanks!
----------------------------------------------------------------------
Comment By: Pino Toscano (pino-guest)
Date: 06/05/2010 19:59
Message:
Updated patch for pulseaudio 0.9.21. 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: PIPE_BUF
make use of the available pa_pipe_buf() for the job
- src/utils/pacmd.c: PIPE_BUF
here the two 'ibuf' and 'obuf' are dynamically allocated with the minimum size of all the pipe_buf for the fd's they are used as buffer when reading from and writing to
- debian/rules: autogeneration of pulseaudio.install for Hurd
used the same approach used for kfreebsd-*
If the patch looks ok, I can send the pulseaudio bits to the PA's trac and the debian part to #573339.
----------------------------------------------------------------------
Comment By: Emilio Pozuelo Monfort (pochu)
Date: 29/01/2010 00:38
Message:
The patch still applies and builds with 0.9.21
----------------------------------------------------------------------
Comment By: Pino Toscano (pino-guest)
Date: 30/10/2009 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: