Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1014555 > unrolled thread

Bug#963205: libmpg123-dev no longer multiarch installable

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#963205: libmpg123-dev no longer multiarch installable Christian Klein <dvlohp@gmail.com> - 2020-06-20 15:10 +0200
    Bug#963205: libmpg123-dev no longer multiarch installable Thomas Orgis <thomas-forum@orgis.org> - 2020-06-20 20:50 +0200
      Bug#963205: libmpg123-dev no longer multiarch installable Sebastian Ramacher <sramacher@debian.org> - 2020-06-21 11:30 +0200
        Bug#963205: libmpg123-dev no longer multiarch installable Thomas Orgis <thomas-forum@orgis.org> - 2020-06-21 12:50 +0200
    Bug#963205: Now … what should I do? Thomas Orgis <thomas-forum@orgis.org> - 2020-06-25 13:00 +0200
      Bug#963205: Now … what should I do? Sebastian Ramacher <sramacher@debian.org> - 2020-06-25 23:00 +0200
        Bug#963205: Now … what should I do? Thomas Orgis <thomas-forum@orgis.org> - 2020-06-26 08:50 +0200
    Bug#963205:  Thomas Orgis <thomas-forum@orgis.org> - 2020-06-26 16:00 +0200
      Bug#963205:  Sebastian Ramacher <sramacher@debian.org> - 2020-06-28 22:20 +0200
        Bug#963205:  Thomas Orgis <thomas-forum@orgis.org> - 2020-06-29 00:10 +0200
    Bug#963205: Next round Thomas Orgis <thomas-forum@orgis.org> - 2020-07-03 10:00 +0200
      Bug#963205: Next round Sebastian Ramacher <sramacher@debian.org> - 2020-07-03 20:30 +0200
        Bug#963205: Next round Thomas Orgis <thomas-forum@orgis.org> - 2020-07-05 11:10 +0200

#1014555 — Bug#963205: libmpg123-dev no longer multiarch installable

Package: libmpg123-dev
Version: 1.26.1-1
Severity: important

The i386 and amd64 versions of the dev-package are no longer co-installable.

Unpacking libmpg123-dev:i386 (1.26.1-1) ...
dpkg: error processing archive /tmp/apt-dpkg-install-
ZpltIr/09-libmpg123-dev_1.26.1-1_i386.deb (--unpack):
 trying to overwrite shared '/usr/include/syn123.h', which is different from
other instances of package libmpg123-dev:i386

A diff of the header files reveals that the i386 and amd64 versions are now
different:

****
$ diff -Naur 32/usr/include/syn123.h 64/usr/include/syn123.h
--- 32/usr/include/syn123.h     2020-06-19 23:19:16.000000000 +0200
+++ 64/usr/include/syn123.h     2020-06-19 23:19:16.000000000 +0200
@@ -978,8 +978,8 @@
 #    error "Unpredicted _FILE_OFFSET_BITS value."
 #  endif
 #else
-#    define syn123_resample_total   syn123_resample_total_32
-#    define syn123_resample_intotal syn123_resample_intotal_32
+#    define syn123_resample_total   syn123_resample_total_64
+#    define syn123_resample_intotal syn123_resample_intotal_64
 #endif

 /** Give exact output sample count for total input sample count.
$
****
I guess the problem was introduced by upstream.

This makes it impossible (or at least very hard) to build multiarch software
like, for example, wine.



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (999, 'unstable'), (998, 'testing'), (990, 'stable'), (500, 'unstable-debug'), (350, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

[toc] | [next] | [standalone]

#1014593

Am Sat, 20 Jun 2020 15:03:32 +0200
schrieb Christian Klein <dvlohp@gmail.com>: 

> A diff of the header files reveals that the i386 and amd64 versions are now
> different:

> -#    define syn123_resample_total   syn123_resample_total_32
> -#    define syn123_resample_intotal syn123_resample_intotal_32
> +#    define syn123_resample_total   syn123_resample_total_64
> +#    define syn123_resample_intotal syn123_resample_intotal_64

> I guess the problem was introduced by upstream.

Indeed. I am upstream and I confirm that I wrote this. But I did not
intend to break multiarch … I just didn't think about it. This is a
fallback for _FILE_OFFSET_BITS not being defined by the client
application. The fallback is to define off_t as long, basically, which
differs on 32 or 64 bit arch. Well one could drop the fallback and
return an error that the client application needs to define
_FILE_OFFSET_BITS … but then, there is no good solution when you got
off_t sometimes as 32 bit and sometimes as 64 bit on the same platform,
depending on a switch.

The largefile (off_t) stuff in libsyn123 is simpler than all the hoops
libmpg123 goes through, with implementing dual mode and wrappery in the
library. Here, the library works with fixed 64 or 32 bits and the
header shall choose the implementation that matches the client offset
size. It has the side effect of the fallback being different.

You could argue that I should have just used int64_t externally, but
the unspecific off_t is the natural type for file/stream offsets … at
least I'd like to pretend that it is:-/ Same reason I use size_t for
memory sizes.

Is it big trouble to separate the syn123 header into multiarch subdirs
to fix debian again? Would you rather have some switch in the same
header about native off_t/long size?


Alrighty then,

Thomas

[toc] | [prev] | [next] | [standalone]

#1014649

[Multipart message — attachments visible in raw view] — view raw

On 2020-06-20 20:37:08 +0200, Thomas Orgis wrote:
> Am Sat, 20 Jun 2020 15:03:32 +0200
> schrieb Christian Klein <dvlohp@gmail.com>: 
> 
> > A diff of the header files reveals that the i386 and amd64 versions are now
> > different:
> 
> > -#    define syn123_resample_total   syn123_resample_total_32
> > -#    define syn123_resample_intotal syn123_resample_intotal_32
> > +#    define syn123_resample_total   syn123_resample_total_64
> > +#    define syn123_resample_intotal syn123_resample_intotal_64
> 
> > I guess the problem was introduced by upstream.
> 
> Indeed. I am upstream and I confirm that I wrote this. But I did not
> intend to break multiarch … I just didn't think about it. This is a
> fallback for _FILE_OFFSET_BITS not being defined by the client
> application. The fallback is to define off_t as long, basically, which
> differs on 32 or 64 bit arch. Well one could drop the fallback and
> return an error that the client application needs to define
> _FILE_OFFSET_BITS … but then, there is no good solution when you got
> off_t sometimes as 32 bit and sometimes as 64 bit on the same platform,
> depending on a switch.
> 
> The largefile (off_t) stuff in libsyn123 is simpler than all the hoops
> libmpg123 goes through, with implementing dual mode and wrappery in the
> library. Here, the library works with fixed 64 or 32 bits and the
> header shall choose the implementation that matches the client offset
> size. It has the side effect of the fallback being different.
> 
> You could argue that I should have just used int64_t externally, but
> the unspecific off_t is the natural type for file/stream offsets … at
> least I'd like to pretend that it is:-/ Same reason I use size_t for
> memory sizes.
> 
> Is it big trouble to separate the syn123 header into multiarch subdirs
> to fix debian again? Would you rather have some switch in the same
> header about native off_t/long size?

I am wondering why syn123 and mpg123 use different approaches to achieve
the same thing. The mpg123-way of handling off_t using functions is
known to work and doesn't require any quirks on the Debian packaging
side. Why doesn't syn123 also use MPG123_LARGENAME?

Cheers
-- 
Sebastian Ramacher

[toc] | [prev] | [next] | [standalone]

#1014655

[Multipart message — attachments visible in raw view] — view raw

Am Sun, 21 Jun 2020 11:23:32 +0200
schrieb Sebastian Ramacher <sramacher@debian.org>: 

> I am wondering why syn123 and mpg123 use different approaches to achieve
> the same thing. The mpg123-way of handling off_t using functions is
> known to work and doesn't require any quirks on the Debian packaging
> side. Why doesn't syn123 also use MPG123_LARGENAME?

Well, then. I need to dive into this myself, again. First: syn123 is
using the same approach as MPG123_LARGENAME, actually. It is just
avoiding the flexible macro machinery to cover only two functions that
are affected. But the basic behaviour is the same

- _FILE_OFFSET_BITS==32: foo123_func → foo123_func_32
- _FILE_OFFSET_BITS==64: foo123_func → foo123_func_64

A difference is in how the libraries are built. In libmpg123, I used
off_t in the library, and it appeared in the API for a while, without
dealing with the issues of possible mismatch in large file support in
lib and client applications. There was a very painful transition to
make libmpg123 offer both LFS settings in one library like glibc does.
This resulted in warts like

	src/libmpg123/lfs_alias.c
	src/libmpg123/lfs_wrap.c

for the need to sport foo123_func, foo123_func_32, and foo123_func_64
in the same library (any of those can be an alias or wrapper, depening
on mpg123 build setup), to be compatible with all user binaries.

For syn123, off_t entered late in the game and there' actually no I/O
involved. It's just about function argument types. I decided to
simplify things by hardcoding _32 and _64 variants and having the
header decide at compile time which one is used.

The case of no _FILE_OFFSET_BITS being defined, in lack of a generic
suffix-less function for that case, results in the value LFS_ALIAS_BITS
being used. This results from this configure code:

dnl The native type used for aliases is what off_t maps to without any largefile-
dnl enabling switches. So, it's long int if the system is largefile-senstive,
dnl but it is actual plain off_t if the system does not have such switches.
if test "x$largefile_sensitive" = xyes; then
  lfs_alias_type=long
  lfs_alias_size=$ac_cv_sizeof_long
elif test "x$android_build" = xyes; then
  lfs_alias_type=off64_t
  lfs_alias_size=$ac_cv_sizeof_off64_t
else
  lfs_alias_type=off_t
  lfs_alias_size=$ac_cv_sizeof_off_t
fi

if test "x$lfs_alias_size" = "x"; then 
  AC_MSG_ERROR([Cannot determine sizeof(lfs_alias_t)?])
else
  LFS_ALIAS_BITS=`expr "$lfs_alias_size" "*" "8"`
  AC_DEFINE_UNQUOTED([lfs_alias_t], $lfs_alias_type,
    [Define to the native offset type (long or actually off_t).])
  AC_DEFINE_UNQUOTED([LFS_ALIAS_BITS], $LFS_ALIAS_BITS,
    [Define this to the size of native offset type in bits, used for LFS alias functions.])
fi

If we can get that logic into the header itself, it would be
arch-agnostic again. Is that easy enough? Otherwise, I'd have to add
plain wrappers named syn123_resample_total and syn123_resample_intotal,
like:

lfs_alias_t syn123_resample_total(long inrate, long outrate, lfs_alias_t ins)
{
#if   LFS_ALIAS_BITS+0 == 64
	return syn123_resample_total_64(inrate, outrate, ins);
#elif LFS_ALIAS_BITS+0 == 32
	return syn123_resample_total_32(inrate, outrate, ins);
#else
	#error "Unexpected LFS_ALIAS_BITS value."
#endif
}

lfs_alias_t syn123_resample_intotal(long inrate, long outrate, lfs_alias_t outs)
{
#if   LFS_ALIAS_BITS+0 == 64
	return syn123_resample_intotal_64(inrate, outrate, outs);
#elif LFS_ALIAS_BITS+0 == 32
	return syn123_resample_intotal_32(inrate, outrate, outs);
#else
	#error "Unexpected LFS_ALIAS_BITS value."
#endif
}

It's all ugly crap that we could avoid if we'd only settle for LFS
support being a fixed property of an architecture/OS setup, off_t not
being a chimera depending on a preprocessor switch.

Do you have a suggestion to avoid using @LFS_ALIAS_BITS@ in the header
and still keep the correct logic catering for the cases for choosing
lfs_alias_t?

If not, I guess I could add these two wrappers and forget about them,
as the code in question won't change much and I don't intend to add
more LFS-aware functions to syn123.

But I really was burned by what I had to do for libmpg123 and did not
want to repeat all that cruft.


Alrighty then,

Thomas

[toc] | [prev] | [next] | [standalone]

#1015239 — Bug#963205: Now … what should I do?

Hey, I am on the path to release mpg123 1.26.2. So, how should I
approach this one here? Can someone comment on my suggestions and
possibly give a variant that works in the header without adding
function wrappers?


Alrighty then,

Thomas

[toc] | [prev] | [next] | [standalone]

#1015298 — Bug#963205: Now … what should I do?

[Multipart message — attachments visible in raw view] — view raw

On 2020-06-25 12:48:17 +0200, Thomas Orgis wrote:
> Hey, I am on the path to release mpg123 1.26.2. So, how should I
> approach this one here? Can someone comment on my suggestions and
> possibly give a variant that works in the header without adding
> function wrappers?

Other than x32, I'm not aware of any 32-bit arch that doesn't have
32-bit off_t if _FILE_OFFSET_BITS is not set. So maybe architecture
specific handling could be enough: if _FILE_OFFSET_BITS==64 or
__WORDSIZE==64 or __x86_64__ && __ILP32__ (for x32) use 64 bit
interfaces; otherwise use 32 bit interfaces.

Cheers
-- 
Sebastian Ramacher

[toc] | [prev] | [next] | [standalone]

#1015335 — Bug#963205: Now … what should I do?

[Multipart message — attachments visible in raw view] — view raw

Am Thu, 25 Jun 2020 22:55:36 +0200
schrieb Sebastian Ramacher <sramacher@debian.org>: 

> Other than x32, I'm not aware of any 32-bit arch that doesn't have
> 32-bit off_t if _FILE_OFFSET_BITS is not set. So maybe architecture

A sure-fire ruleset is different …

> specific handling could be enough: if _FILE_OFFSET_BITS==64 or
> __WORDSIZE==64 or __x86_64__ && __ILP32__ (for x32) use 64 bit
> interfaces; otherwise use 32 bit interfaces.

I'd turn that around to have 64 bit as the „normal“ case. But then … it
has a smell of a bit of heuristic, still (even if it's right 99% of
cases). I guess it is safer to have a generic function symbol without
_bits suffix for the „native“ size, following the decision of the
largefile detection macros in configure.

I'm caving in and will add those two wrappers after all for the 1.26.2
release … stay tuned.


Alrighty then,

Thomas

[toc] | [prev] | [next] | [standalone]

#1015378 — Bug#963205:

[Multipart message — attachments visible in raw view] — view raw

OK,

I introduced the additional wrapper now with svn commit 4743 on
svn://scm.orgis.org/mpg123 .

You can test by using current https://mpg123.org/snapshot or by
applying the attached patch.

Test reports before I release (this weekend?) are welcome.


Alrighty then,

Thomas

[toc] | [prev] | [next] | [standalone]

#1015671 — Bug#963205:

[Multipart message — attachments visible in raw view] — view raw

On 2020-06-26 15:46:59 +0200, Thomas Orgis wrote:
> OK,
> 
> I introduced the additional wrapper now with svn commit 4743 on
> svn://scm.orgis.org/mpg123 .
> 
> You can test by using current https://mpg123.org/snapshot or by
> applying the attached patch.
> 
> Test reports before I release (this weekend?) are welcome.
> 
> 
> Alrighty then,
> 
> Thomas

> Index: NEWS
> ===================================================================
> --- NEWS	(revisión: 4742)
> +++ NEWS	(revisión: 4743)
> @@ -10,6 +10,8 @@
>  - More CMake build fixes thanks to David Callu (bug 290).
>  - Use PROG_LIBS for output modules, to reinstate not necessarily proper but
>    previous behaviour and fix FreeBSD port build (bug 291).
> +- Refine LFS support in libsyn123, avoiding architecture-dependent syn123.h
> +  (debian bug 963205).
>  
>  1.26.1
>  ------
> Index: src/libsyn123/resample.c
> ===================================================================
> --- src/libsyn123/resample.c	(revisión: 4742)
> +++ src/libsyn123/resample.c	(revisión: 4743)
> @@ -1899,15 +1899,25 @@
>  	return (tot <= INT64_MAX) ? (int64_t)tot : SYN123_OVERFLOW;
>  }
>  
> -#if SIZEOF_LONG == 4
> -long attribute_align_arg
> -syn123_resample_total_32(long inrate, long outrate, long ins)
> +int32_t attribute_align_arg
> +syn123_resample_total_32(int32_t inrate, int32_t outrate, int32_t ins)
>  {
>  	int64_t tot = syn123_resample_total_64(inrate, outrate, ins);
> -	return (tot <= LONG_MAX) ? (long)tot : SYN123_OVERFLOW;
> +	return (tot <= INT32_MAX) ? (int32_t)tot : SYN123_OVERFLOW;
>  }
> +
> +lfs_alias_t syn123_resample_total(long inrate, long outrate, lfs_alias_t ins)
> +{
> +#if   LFS_ALIAS_BITS+0 == 64
> +	return syn123_resample_total_64(inrate, outrate, ins);
> +#elif LFS_ALIAS_BITS+0 == 32
> +	return syn123_resample_total_32(inrate, outrate, ins);
> +#else
> +	#error "Unexpected LFS_ALIAS_BITS value."
>  #endif
> +}
>  
> +
>  // The inverse function: How many input samples are needed to get at least
>  // the desired amount of output?
>  int64_t attribute_align_arg
> @@ -1959,17 +1969,24 @@
>  	return (tot <= INT64_MAX) ? (int64_t)tot : SYN123_OVERFLOW;
>  }
>  
> -#if SIZEOF_LONG == 4
> -long attribute_align_arg
> -syn123_resample_intotal_32(long inrate, long outrate, long outs)
> +int32_t attribute_align_arg
> +syn123_resample_intotal_32(int32_t inrate, int32_t outrate, int32_t outs)
>  {
>  	int64_t tot = syn123_resample_intotal_64(inrate, outrate, outs);
> -	return (tot <= LONG_MAX) ? (long)tot : SYN123_OVERFLOW;
> +	return (tot <= INT32_MAX) ? (int32_t)tot : SYN123_OVERFLOW;
>  }
> +
> +lfs_alias_t syn123_resample_intotal(long inrate, long outrate, lfs_alias_t outs)
> +{
> +#if   LFS_ALIAS_BITS+0 == 64
> +	return syn123_resample_intotal_64(inrate, outrate, outs);
> +#elif LFS_ALIAS_BITS+0 == 32
> +	return syn123_resample_intotal_32(inrate, outrate, outs);
> +#else
> +	#error "Unexpected LFS_ALIAS_BITS value."
>  #endif
> +}
>  
> -#define syn123_resample_total syn123_resample_total_64
> -
>  // As any sensible return value is at least 1, this uses the unsigned
>  // type and 0 for error/pathological input.
>  // This function could be simplified to
> Index: src/libsyn123/syn123.h.in
> ===================================================================
> --- src/libsyn123/syn123.h.in	(revisión: 4742)
> +++ src/libsyn123/syn123.h.in	(revisión: 4743)
> @@ -977,9 +977,6 @@
>  #  else
>  #    error "Unpredicted _FILE_OFFSET_BITS value."
>  #  endif
> -#else
> -#    define syn123_resample_total   syn123_resample_total_@LFS_ALIAS_BITS@
> -#    define syn123_resample_intotal syn123_resample_intotal_@LFS_ALIAS_BITS@
>  #endif
>  
>  /** Give exact output sample count for total input sample count.

Unfortunately the patch fails to build on i386:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I./src -DPKGLIBDIR=\"/usr/lib/i386-linux-gnu/mpg123\" -I./src -I./src/compat -I./src/libmpg123 -I./src/libout123 -I./src/libmpg123 -I./src/libsyn123 -I./src/libout123 -DOPT_MULTI -DOPT_GENERIC -DOPT_GENERIC_DITHER -DOPT_I386 -DOPT_I586 -DOPT_I586_DITHER -DOPT_MMX -DOPT_3DNOW -DOPT_3DNOW_VINTAGE -DOPT_3DNOWEXT -DOPT_3DNOWEXT_VINTAGE -DOPT_SSE -DOPT_SSE_VINTAGE -DREAL_IS_FLOAT -DNEWOLD_WRITE_SAMPLE -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -fomit-frame-pointer -funroll-all-loops -finline-functions -ffast-math -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -c src/libsyn123/resample.c  -fPIC -DPIC -o src/libsyn123/.libs/resample.o
In file included from src/libsyn123/syn123_int.h:20,
                 from src/libsyn123/resample.c:84:
src/libsyn123/syn123.h:975:37: error: conflicting types for ‘syn123_resample_total_64’
  975 | #    define syn123_resample_total   syn123_resample_total_64
      |                                     ^~~~~~~~~~~~~~~~~~~~~~~~
src/libsyn123/resample.c:1909:13: note: in expansion of macro ‘syn123_resample_total’
 1909 | lfs_alias_t syn123_resample_total(long inrate, long outrate, lfs_alias_t ins)
      |             ^~~~~~~~~~~~~~~~~~~~~
src/libsyn123/resample.c:1855:1: note: previous definition of ‘syn123_resample_total_64’ was here
 1855 | syn123_resample_total_64(long inrate, long outrate, int64_t ins)
      | ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from src/libsyn123/syn123_int.h:20,
                 from src/libsyn123/resample.c:84:
src/libsyn123/syn123.h:976:37: error: conflicting types for ‘syn123_resample_intotal_64’
  976 | #    define syn123_resample_intotal syn123_resample_intotal_64
      |                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~
src/libsyn123/resample.c:1979:13: note: in expansion of macro ‘syn123_resample_intotal’
 1979 | lfs_alias_t syn123_resample_intotal(long inrate, long outrate, lfs_alias_t outs)
      |             ^~~~~~~~~~~~~~~~~~~~~~~
src/libsyn123/resample.c:1924:1: note: previous definition of ‘syn123_resample_intotal_64’ was here
 1924 | syn123_resample_intotal_64(long inrate, long outrate, int64_t outs)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~
make[1]: *** [Makefile:3849: src/libsyn123/resample.lo] Error 1

Cheers
-- 
Sebastian Ramacher

[toc] | [prev] | [next] | [standalone]

#1015682 — Bug#963205:

[Multipart message — attachments visible in raw view] — view raw

Am Sun, 28 Jun 2020 22:16:13 +0200
schrieb Sebastian Ramacher <sramacher@debian.org>: 

> Unfortunately the patch fails to build on i386:

Darn. Of course, sorry. This is missing:

Index: src/libsyn123/syn123.h.in
===================================================================
--- src/libsyn123/syn123.h.in	(revisión: 4743)
+++ src/libsyn123/syn123.h.in	(copia de trabajo)
@@ -964,6 +964,7 @@
 ssize_t syn123_resample_inexpect(syn123_handle *sh, size_t outs);
 
 
+#ifndef SYN123_NO_LARGENAME
 /* Lightweight large file hackery to enable worry-reduced use of off_t.
    Depending on the size of off_t in your client build, the corresponding
    library function needs to be chosen. */
@@ -978,6 +979,7 @@
 #    error "Unpredicted _FILE_OFFSET_BITS value."
 #  endif
 #endif
+#endif
 
 /** Give exact output sample count for total input sample count.
  *
Index: src/libsyn123/syn123_int.h
===================================================================
--- src/libsyn123/syn123_int.h	(revisión: 4743)
+++ src/libsyn123/syn123_int.h	(copia de trabajo)
@@ -17,6 +17,7 @@
 #include "intsym.h"
 #include "compat.h"
 #include "abi_align.h"
+#define SYN123_NO_LARGENAME
 #include "syn123.h"
 
 // Generally, a number of samples we work on in one go to


I pushed a new snapshot. Can you verify?


Alrighty then,

Thomas

[toc] | [prev] | [next] | [standalone]

#1016286 — Bug#963205: Next round

I made a new snapshot now. The old one still had a conflict of off_t
and lfs_alias_t in the suffix-less prototype. I hope this does it!

	https://mpg123.org/snapshot

Verify?

[toc] | [prev] | [next] | [standalone]

#1016362 — Bug#963205: Next round

[Multipart message — attachments visible in raw view] — view raw

Hi Thomas

On 2020-07-03 09:47:34 +0200, Thomas Orgis wrote:
> I made a new snapshot now. The old one still had a conflict of off_t
> and lfs_alias_t in the suffix-less prototype. I hope this does it!
> 
> 	https://mpg123.org/snapshot
> 
> Verify?

Build on both amd64 and i386 and the difference in the headers is gone.
Thanks

Cheers
-- 
Sebastian Ramacher

[toc] | [prev] | [next] | [standalone]

#1016558 — Bug#963205: Next round

[Multipart message — attachments visible in raw view] — view raw

Great. I released 1.26.2 now so that the package here can be updated.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web