Bug#1075590: tuxpaint: ftbfs with GCC-14

[Florian Ernst]

On Sun, Oct 06, 2024 at 06:04:49PM +0200, Florian Ernst wrote:
> [...]
> So, not only is "-lm" missing, but now there is a bunch of additional
> libraries (Gnome?) present that wasn't there before, for whatever
> reason. H.

In May 2023 upstream already decided to not rely on receiving all
required libraries via pkg-config but to always link with "-lm", cf.
<https://sourceforge.net/p/tuxpaint/tuxpaint/ci/a58f1f64b5b691462b4bf766f34eaf194670afaa/>
or
<https://sourceforge.net/p/tuxpaint/tuxpaint/ci/a58f1f64b5b691462b4bf766f34eaf194670afaa/tree/Makefile?diff=f8358530ff76786863d0f801b6c68e49e3e98671>.

Pulling in that patch makes the package build again.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1075590: tuxpaint: ftbfs with GCC-14

[Florian Ernst]

On Sun, Oct 06, 2024 at 02:31:48PM +0200, Chris Hofstaedtler wrote:
> On Sun, Aug 11, 2024 at 01:35:34PM +0200, Florian Ernst wrote:
> > With the attached minimized patch this tuxpaint version compiles again
> > with gcc-14. It seems this was first fixed upstream in 0.9.29, cf.
> > <https://sourceforge.net/p/tuxpaint/tuxpaint/ci/9d70b5837cc307e6c9fe80e6e7dcabf7750b1d45/>.
> > [...]
> 
> I tried applying this, but then later linking fails (at least on arm64):
> [...]

Thanks for checking! Well, while this worked for me in August I now get
a similar error on amd64:

| ...Linking Tux Paint...
| cc -Wdate-time -D_FORTIFY_SOURCE=2 -O0 -g -W -Wall -fno-common -ffloat-store 
-fvisibility=hidden -Wcast-align -Wredundant-decls -Wbad-function-cast 
-Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes 
-Wstrict-aliasing=2   -g -I/usr/include/SDL2 -D_REENTRANT  
-I/usr/include/fribidi  -DVER_DATE=\"2024-10-06\" -DVER_VERSION=\"0.9.28\" 
-DDATA_PREFIX=\"/usr/share/tuxpaint/\" 
-DDOC_PREFIX=\"/usr/share/doc/tuxpaint-0.9.28/\" 
-DLOCALEDIR=\"/usr/share/locale/\" -DIMDIR=\"/usr/share/tuxpaint/im/\" 
-DCONFDIR=\"/etc/tuxpaint/\" -DMAGIC_PREFIX=\"/usr/lib/tuxpaint/plugins/\"
-DNO_SDLPANGO   \
| -o tuxpaint obj/tuxpaint.o obj/i18n.o obj/im.o obj/cursor.o 
obj/pixels.o obj/rgblinear.o obj/playsound.o obj/fonts.o obj/parse.o obj/fill.o 
obj/progressbar.o obj/dirwalk.o obj/get_fname.o obj/onscreen_keyboard.o 
obj/gifenc.o obj/sounds.o obj/postscript_print.o \
| -lSDL2  -lSDL2_image -lSDL2  -lSDL2_ttf -lSDL2  -lSDL2_gfx -lSDL2  
-lz  -lpng16  -lSDL2_mixer -lSDL2   
-L/usr/lib/x86_64-linux-gnu/pkgconfig/../../../lib/x86_64-linux-gnu -lrsvg-2 
-lcairo-gobject -lpng16 -ldav1d -lgdk_pixbuf-2.0 -lgio-2.0 -lxml2 
-lpangocairo-1.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lharfbuzz 
-lfontconfig -lfreetype -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 
-lglib-2.0 -lcairo  -lpaper -lfribidi  -limagequant
| /usr/bin/ld: obj/tuxpaint.o: undefined reference to symbol 
'round@@GLIBC_2.2.5'
| /usr/bin/ld: /lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO 
missing from command line
| collect2: error: ld returned 1 exit status

And indeed, in my previous attempt that linking still included "-lm"
which now is missing, explaining the error. Here the corresponding lines
from that attempt:

| ...Linking Tux Paint...
| cc -Wdate-time -D_FORTIFY_SOURCE=2 -O0 -g -W -Wall -fno-common -ffloat-store 
-fvisibility=hidden -Wcast-align -Wredundant-decls -Wbad-function-cast 
-Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes 
-Wstrict-aliasing=2   -g -I/usr/include/SDL2 -D_REENTRANT  
-I/usr/include/fribidi  -DVER_DATE=\"2024-08-11\" -DVER_VERSION=\"0.9.28\" 
-DDATA_PREFIX=\"/usr/share/tuxpaint/\" 
-DDOC_PREFIX=\"/usr/share/doc/tuxpaint-0.9.28/\" 
-DLOCALEDIR=\"/usr/share/locale/\" -DIMDIR=\"/usr/share/tuxpaint/im/\" 
-DCONFDIR=\"/etc/tuxpaint/\" -DMAGIC_PREFIX=\"/usr/lib/tuxpaint/plugins/\"
-DNO_SDLPANGO   \
| -o tuxpaint obj/tuxpaint.o obj/i18n.o obj/im.o obj/cursor.o 
obj/pixels.o obj/rgblinear.o obj/playsound.o obj/fonts.o obj/parse.o obj/fill.o 
obj/progressbar.o obj/dirwalk.o obj/get_fname.o obj/onscreen_keyboard.o 
obj/gifenc.o obj/sounds.o obj/postscript_print.o \
| -lSDL2  -lSDL2_image -lSDL2  -lSDL2_ttf -lSDL2  -lSDL2_gfx -lSDL2  
-lz  -lpng16  -lSDL2_mixer -lSDL2   -lrsvg-2 -lm -lgio-2.0 -lgdk_pixbuf-2.0 
-lgobject-2.0 -lglib-2.0 -lcairo  -lpaper -lfribidi  -limagequant
| 
| --
| 
| Done compiling.

So, not only is "-lm" missing, but now there is a bunch of additional
libraries (Gnome?) present that wasn't there before, for whatever
reason. H.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1075109: kbd: ftbfs with GCC-14

[Florian Ernst]

Control: tags -1 upstream fixed-upstream patch

On Sun, Aug 18, 2024 at 01:58:12AM +0200, Andreas Henriksson wrote:
> forwarded 1075109 https://github.com/legionus/kbd/pull/119

Just confirmed: this patch fixes the FTBFS. It was already merged upstream.

Thus now tagging accordingly.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1074915: discount: ftbfs with GCC-14

[Florian Ernst]

Control: tags -1 patch

On Wed, Jul 03, 2024 at 12:25:19PM +, Matthias Klose wrote:
> [...]
> The package fails to build in a test rebuild on at least amd64 with
> gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
> severity of this report will be raised before the trixie release.
> 
> The full build log can be found at:
> http://qa-logs.debian.net/2024/07/01/discount_2.2.7-2_unstable_gccexp.log
> The last lines of the build log are at the end of this report.
> [...]
> main.c: In function ‘main’:
> main.c:311:36: error: passing argument 2 of ‘mkd_e_code_format’ from 
> incompatible pointer type [-Wincompatible-pointer-types]
>   311 | mkd_e_code_format(doc, external_codefmt);
>   |^~~~
>   ||
>   |char * (*)(char *, int,  char *)
> In file included from main.c:12:
> ./mkdio.h:71:31: note: expected ‘mkd_callback_t’ {aka ‘char * (*)(const char 
> *, const int,  void *)’} but argument is of type ‘char * (*)(char *, int,  
> char *)’
>71 | void mkd_e_code_format(void*, mkd_callback_t);
>   |   ^~
> make[1]: *** [Makefile:128: main.o] Error 1
> [...]

Just confirmed: the patch at

or  (apparently not heeded
by upstream) fixes this.

HTH,
Flo


signature.asc
Description: PGP signature

Bug#1075157: libcddb: ftbfs with GCC-14

[Florian Ernst]

Control: tags -1 patch

On Wed, Jul 03, 2024 at 12:32:51PM +, Matthias Klose wrote:
> [...]
> The package fails to build in a test rebuild on at least amd64 with
> gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
> severity of this report will be raised before the trixie release.
> 
> The full build log can be found at:
> http://qa-logs.debian.net/2024/07/01/libcddb_1.3.2-7_unstable_gccexp.log
> The last lines of the build log are at the end of this report.
> [...]
> cddb_net.c: In function ‘timeout_connect’:
> cddb_net.c:332:63: error: passing argument 5 of ‘getsockopt’ from 
> incompatible pointer type [-Wincompatible-pointer-types]
>   332 | getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &rv, &l);
>   |   ^~
>   |   |
>   |   size_t 
> * {aka long unsigned int *}
> In file included from /usr/include/netinet/in.h:23,
>  from ../include/cddb/cddb_conn.h:32,
>  from ../include/cddb/cddb.h:37,
>  from ../include/cddb/cddb_ni.h:58,
>  from cddb_net.c:22:
> /usr/include/x86_64-linux-gnu/sys/socket.h:257:46: note: expected ‘socklen_t 
> * restrict’ {aka ‘unsigned int * restrict’} but argument is of type ‘size_t 
> *’ {aka ‘long unsigned int *’}
>   257 |socklen_t *__restrict __optlen) __THROW;
>   |~~^~~~
> make[3]: *** [Makefile:465: cddb_net.lo] Error 1
> [...]

Just confirmed: the patch at

or

fixes this.

HTH,
Flo


signature.asc
Description: PGP signature

Bug#1075188: libmpc: ftbfs with GCC-14

[Florian Ernst]

Control: tag -1 patch

On Wed, Jul 03, 2024 at 12:33:50PM +, Matthias Klose wrote:
> [...]
> The package fails to build in a test rebuild on at least amd64 with
> gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
> severity of this report will be raised before the trixie release.
> 
> The full build log can be found at:
> http://qa-logs.debian.net/2024/07/01/libmpc_0.1~r495-2_unstable_gccexp.log
> The last lines of the build log are at the end of this report.
> [...]
> ans.c: In function ‘NS_Analyse’:
> ans.c:290:120: error: passing argument 10 of ‘FindOptimalANS’ from 
> incompatible pointer type [-Wincompatible-pointer-types]
>   290 | FindOptimalANS ( MaxBand, MSflag, ANSspec_L, ANSspec_M, 
> m->NS_Order_L, m->SNR_comp_L, m->FIR_L, smr.L, smr.M, m->SCF_Index_L, 
> Transient );
>   |   
> ~^
>   |   
>  |
>   |   
>  int *
> ans.c:159:40: note: expected ‘const int (*)[3]’ but argument is of type ‘int 
> *’
>   159 |  const int scf [] [3],
>   |  ~~^~
> ans.c:295:120: error: passing argument 10 of ‘FindOptimalANS’ from 
> incompatible pointer type [-Wincompatible-pointer-types]
>   295 | FindOptimalANS ( MaxBand, MSflag, ANSspec_R, ANSspec_S, 
> m->NS_Order_R, m->SNR_comp_R, m->FIR_R, smr.R, smr.S, m->SCF_Index_R, 
> Transient );
>   |   
> ~^
>   |   
>  |
>   |   
>  int *
> ans.c:159:40: note: expected ‘const int (*)[3]’ but argument is of type ‘int 
> *’
>   159 |  const int scf [] [3],
>   |  ~~^~
> make[2]: *** [Makefile:387: ans.o] Error 1
> [...]

Just confirmed: the patch at

fixes this.

HTH,
Flo


signature.asc
Description: PGP signature

Bug#1075269: mhash: ftbfs with GCC-14

[Florian Ernst]

Control: tag -1 patch

On Wed, Jul 03, 2024 at 12:36:24PM +, Matthias Klose wrote:
> [...]
> The package fails to build in a test rebuild on at least amd64 with
> gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
> severity of this report will be raised before the trixie release.
> 
> The full build log can be found at:
> http://qa-logs.debian.net/2024/07/01/mhash_0.9.9.9-9_unstable_gccexp.log
> The last lines of the build log are at the end of this report.
> [...]
> tiger.c: In function ‘tiger_final’:
> tiger.c:257:30: error: initialization of ‘uint8_t *’ {aka ‘unsigned char *’} 
> from incompatible pointer type ‘uint64_t *’ {aka ‘long unsigned int *’} 
> [-Wincompatible-pointer-types]
>   257 | mutils_word8 *temp = temp_64bit;
>   |  ^~
> make[2]: *** [Makefile:510: tiger.lo] Error 1
> [...]

Just confirmed: the patch at

or

fixes this.

HTH,
Flo


signature.asc
Description: PGP signature

Bug#1075590: tuxpaint: ftbfs with GCC-14

[Florian Ernst]

Control: tags -1 upstream fixed-upstream patch

On Wed, Jul 03, 2024 at 12:46:36PM +, Matthias Klose wrote:
> [...]
> src/tuxpaint.c: In function ‘do_new_dialog’:
> src/tuxpaint.c:22025:54: error: passing argument 3 of 
> ‘autoscale_copy_smear_free’ from incompatible pointer type 
> [-Wincompatible-pointer-types]
> 22025 |   autoscale_copy_smear_free(img, canvas, SDL_BlitSurface);
>   |  ^~~
>   |  |
>   |  int 
> (*)(SDL_Surface *, const SDL_Rect *, SDL_Surface *, SDL_Rect *)
> src/tuxpaint.c:12998:52: note: expected ‘int (*)(SDL_Surface *, SDL_Rect *, 
> SDL_Surface *, SDL_Rect *)’ but argument is of type ‘int (*)(SDL_Surface *, 
> const SDL_Rect *, SDL_Surface *, SDL_Rect *)’
> 12998 |   int SDLCALL(*blit) (SDL_Surface 
> * src,
>   |   
> ~^
> 12999 |   SDL_Rect * 
> srcrect, SDL_Surface * dst, SDL_Rect * dstrect))
>   |   
> ~~
> src/tuxpaint.c:22080:54: error: passing argument 3 of 
> ‘autoscale_copy_smear_free’ from incompatible pointer type 
> [-Wincompatible-pointer-types]
> 22080 |   autoscale_copy_smear_free(img, canvas, SDL_BlitSurface);
>   |  ^~~
>   |  |
>   |  int 
> (*)(SDL_Surface *, const SDL_Rect *, SDL_Surface *, SDL_Rect *)
> src/tuxpaint.c:12998:52: note: expected ‘int (*)(SDL_Surface *, SDL_Rect *, 
> SDL_Surface *, SDL_Rect *)’ but argument is of type ‘int (*)(SDL_Surface *, 
> const SDL_Rect *, SDL_Surface *, SDL_Rect *)’
> 12998 |   int SDLCALL(*blit) (SDL_Surface 
> * src,
>   |   
> ~^
> 12999 |   SDL_Rect * 
> srcrect, SDL_Surface * dst, SDL_Rect * dstrect))
>   |   
> ~~
> [...]
> src/tuxpaint.c: In function ‘load_embedded_data’:
> src/tuxpaint.c:25969:57: error: passing argument 3 of 
> ‘autoscale_copy_smear_free’ from incompatible pointer type 
> [-Wincompatible-pointer-types]
> 25969 | autoscale_copy_smear_free(org_surf, canvas, 
> SDL_BlitSurface);
>   | 
> ^~~
>   | |
>   | int 
> (*)(SDL_Surface *, const SDL_Rect *, SDL_Surface *, SDL_Rect *)
> src/tuxpaint.c:12998:52: note: expected ‘int (*)(SDL_Surface *, SDL_Rect *, 
> SDL_Surface *, SDL_Rect *)’ but argument is of type ‘int (*)(SDL_Surface *, 
> const SDL_Rect *, SDL_Surface *, SDL_Rect *)’
> 12998 |   int SDLCALL(*blit) (SDL_Surface 
> * src,
>   |   
> ~^
> 12999 |   SDL_Rect * 
> srcrect, SDL_Surface * dst, SDL_Rect * dstrect))
>   |   
> ~~
> src/tuxpaint.c:26028:81: error: passing argument 3 of 
> ‘autoscale_copy_smear_free’ from incompatible pointer type 
> [-Wincompatible-pointer-types]
> 26028 |   autoscale_copy_smear_free(aux_surf, 
> img_starter_bkgd, SDL_BlitSurface);
>   |   
>   ^~~
>   |   
>   |
>   |   
>   int (*)(SDL_Surface *, const SDL_Rect *, SDL_Surface *, SDL_Rect *)
> src/tuxpaint.c:12998:52: note: expected ‘int (*)(SDL_Surface *, SDL_Rect *, 
> SDL_Surface *, SDL_Rect *)’ but argument is of type ‘int (*)(SDL_Surface *, 
> const SDL_Rect *, SDL_Surface *, SDL_Rect *)’
> 12998 |   int SDLCALL(*blit) (SDL_Surface 
> * src,
>   |   
> ~^
> 12999 |   SDL_Rect * 
> srcrect, SDL_Surface * dst, SDL_Rect * dstrect))
>   |   
> ~~
> src

Bug#1075586: trickle: ftbfs with GCC-14

[Florian Ernst]

Control: tag 1075586 patch
Control: forwarded 1075586 
https://github.com/mariusae/trickle/issues/34#issuecomment-2134139388

On Wed, Jul 03, 2024 at 12:46:27PM +, Matthias Klose wrote:
> [...]
> xdr.c: In function ‘xdr_msg’:
> xdr.c:106:32: error: passing argument 5 of ‘xdr_union’ from incompatible 
> pointer type [-Wincompatible-pointer-types]
>   106 |   xdr_msg_discrim, _xdr_void));
>   |^
>   ||
>   |bool_t (*)(void) {aka int (*)(void)}
> [...]
> make[2]: *** [Makefile:529: xdr.o] Error 1
> make[2]: Leaving directory '/<>'
> make[1]: *** [Makefile:407: all] Error 2
> make[1]: Leaving directory '/<>'
> dh_auto_build: error: make -j1 returned exit code 2
> make: *** [debian/rules:6: binary] Error 25
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
> 2

With the patch

| --- a/xdr.c
| +++ b/xdr.c
| @@ -103,7 +103,7 @@ xdr_msg(XDR *xdrs, struct msg *msg)
|  {
|   X(xdr_short(xdrs, &msg->status));
|   X(xdr_union(xdrs, (int *)&msg->type, (char *)&msg->data,
| -   xdr_msg_discrim, _xdr_void));
| +   xdr_msg_discrim, (xdrproc_t)_xdr_void));
| 
|   return (TRUE);
|  }

as mentioned in

trickle builds again.

Gürkan Myczko, do you still intend to adopt trickle as stated in
? If so, the
above might help. Otherwise please state there accordingly, easing the
path for a QA upload not stepping on your toes in any way. After all,
trickle has already been removed from testing due to this bug, cf.
.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1072366: libndp: CVE-2024-5564

[Florian Ernst]

On Thu, Jun 13, 2024 at 08:17:41PM +0200, Moritz Muehlenhoff wrote:
> Thanks, these look good! Please upload to security-master, I'll take care
> of the DSA over the weekend.

Thanks for verifying, thus just uploaded to security-master. And thanks
in advance for taking care of the DSA.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1072366: libndp: CVE-2024-5564

[Florian Ernst]

Hello Moritz,

On Mon, Jun 10, 2024 at 01:56:16PM +0200, Moritz Muehlenhoff wrote:
> It would be great if you could prepare updates for bullseye-security and
> bookworm-security [1]. Please use 1.6-1+deb11u1 and 1.8-1+deb12u1 as the
> respective version numbers. security.debian.org also has autopkgtests set
> up, so we should get some good coverage by reverse deps.
> [...]
> [1] 
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#bug-security

I prepared such updates, and they passed my local checks and tests.

However, heeding

I didn't directly upload them to the security upload queue as I was
still unsure whether they exactly meet the Debian Security Team's
requirements, so instead I just placed them in
 for further checking, all
signed for eventual uploading once found acceptable.

Please give those packages an additional check, and feel free to just
upload them when they indeed meet your requirements, or briefly ping me
back for me to upload them / possibly apply further changes, whatever
suits you best.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1072366: libndp: CVE-2024-5564

[Florian Ernst]

Dear Security Team,

On Sat, Jun 01, 2024 at 04:57:53PM +0200, Salvatore Bonaccorso wrote:
> [...]
> [0] https://security-tracker.debian.org/tracker/CVE-2024-5564
> https://www.cve.org/CVERecord?id=CVE-2024-5564

An updated package containing upstream's fix has just been uploaded and
is waiting to be processed for unstable.

Upstream's fix: 
https://github.com/jpirko/libndp/commit/05e4ba7b0d126eea4c04387dcf40596059ee24af
(as referenced from https://github.com/jpirko/libndp/issues/26 and
already seen by carnil)
Debian change: 
https://salsa.debian.org/debian/libndp/-/commit/a6136d60ef278c1aebee32f805ff473f0ee6ef99

The corresponding Debian change applies cleanly on bookworm / stable
(naturally, as until today bookworm and sid both had libndp 1.8-1) and
also on bullseye / oldstable and buster / oldoldstable (both having
libndp 1.6-1).

I could prepare packages targeting (old)stable, if so desired. Or would
it be easier for you if you just take over from here?

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1071321: tagging 1071321

[Florian Ernst]

Following up on this:

On Sun, May 26, 2024 at 11:42:56AM +0200, Florian Ernst wrote:
> On Sun, May 26, 2024 at 10:54:21AM +0200, Christoph Biedl wrote:
> > Étienne Mollier wrote...
> > > If that helps, the symbols strlcat and strlcpy have been added
> > > to the glibc 2.38, so I believe it should be safe to remove the
> > > following symbols without soname bump:
> > 
> > Just came here to say the same (and why does the BTS¹ not show Étienne's
> > message?). There might be a small chance this breaks packages due to
> > slight implementation differences - but that's what testing and
> > autopkgtests are for.
> 
> Thanks for your investigation. I suspected as much, but didn't yet get
> around to actually check on this any further, so thanks for the pointer.
> 
> I plan to deal with this on next Sunday, and I'll make sure to check
> building all reverse build deps against the updated package as well.

Only one of the reverse build depends actually made use of strlcat as
provided by libdumbnet:

- farpd
  The last build of 0.2-11.3+b1_amd64 from 2024-03-26 still shows this,
  but with the upload of 0.2-11.4 on 2024-05-30 it starts to reference
  the glibc version, so this seems fine now.

Two of the reverse build deps provide and use their own copy of
strlcat/strlcpy unless those are already available, but don't reference
libdumbnet's:

- scanssh
  The last build of 2.0-4.3+b1_amd64 from 2024-03-26 still shows the
  internal copies, whereas the build of 2.1.3.1-0.1_amd64 from
  2024-05-27 shows the glibc versions, so this seems fine.
- tcpreplay
  The last build of 4.4.4-1+b1_amd64 from 2024-03-29 still shows the
  internal copies, whereas a local rebuild references the glibc
  versions. This change is unrelated to libdumbnet dropping those
  symbols, though, and should happen seamlessly some time in the future
  with the next rebuild. There seems to be no need for such a rebuild as
  of now.

Five of the reverse build deps don't use strlcat/strlcpy at all, so they
are all fine:
- arpon
- daemonlogger
- daq
- firewalk
- libnet-libdnet-perl

One of the reverse build deps FTBFS and is overall in a rather sorry
state, so I didn't really investigate here:
- snort

All in all, to me it seems no further action is required here: Bastian's
upload of libdumbnet 1.18.0-1.1 solved this bug#1071321 here, and his
farpd 0.2-11.4 resolved the followup issue of the then-missing strlcat
for that package; all other reverse build deps are not affected or, as
is the case with snort, too broken anyway.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1071321: marked as done (libdumbnet: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file)

[Florian Ernst]

Hello Bastian,

thanks for taking care and fixing this speedily.

However, I am wondering whether there was a particular need to speed up
fixing this bug that I might have missed and that might need to have
been added to the bug for further consideration / clarification.

After all I, as the maintainer, had already confirmed its existence, had
acknowledged the pointers outlining the fix, and had announced when and
how I was going to deal with it.

Even the lowNMU page states 
| If the package maintainer or maintainer group is active, it is polite to
| let them have a stab at fixing the problem first.

As such, while your NMU has improved the overall state of things, I
indeed consider it impolite. And I wish I had had the chance to fix the
problem myself.

So, was there any such pressing need? And did you perhaps already test
building the reverse build deps as I had planned?

Please understand that I am trying to coordinate here in order to avoid
any duplication of effort or any misunderstandings.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1071321: tagging 1071321

[Florian Ernst]

Hello everyone,

On Sun, May 26, 2024 at 10:54:21AM +0200, Christoph Biedl wrote:
> Étienne Mollier wrote...
> > If that helps, the symbols strlcat and strlcpy have been added
> > to the glibc 2.38, so I believe it should be safe to remove the
> > following symbols without soname bump:
> 
> Just came here to say the same (and why does the BTS¹ not show Étienne's
> message?). There might be a small chance this breaks packages due to
> slight implementation differences - but that's what testing and
> autopkgtests are for.

Thanks for your investigation. I suspected as much, but didn't yet get
around to actually check on this any further, so thanks for the pointer.

I plan to deal with this on next Sunday, and I'll make sure to check
building all reverse build deps against the updated package as well.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1063361: nvidia-graphics-drivers-tesla-470: autopkgtest needs update for new version of linux

[Florian Ernst]

Control: tag 1063361 + bookworm

On Sat, Feb 10, 2024 at 03:49:45PM +0100,  wrote:
> Control: found 1063361 470.223.02-2~deb12u1
> [...]
> Thus now marking this bug accordingly.

Not quite, but hopefully now.

FWIW, manually adding 0035-fix-build-w-kernel-6.1.76-6.6.15-6.7.3.patch[0]
fixes the build for me on bookworm as well.

Cheers,
Flo

[0] 
https://sources.debian.org/src/nvidia-graphics-drivers-tesla-470/470.223.02-4/debian/module/debian/patches/0035-fix-build-w-kernel-6.1.76-6.6.15-6.7.3.patch/


signature.asc
Description: PGP signature

Bug#1063361: nvidia-graphics-drivers-tesla-470: autopkgtest needs update for new version of linux

[Florian Ernst]

Control: found 1063361 470.223.02-2~deb12u1

On Tue, Feb 06, 2024 at 09:18:15PM +0100, Paul Gevers wrote:
> Source: nvidia-graphics-drivers-tesla-470
> Version: 470.223.02-3
> Severity: serious
> X-Debbugs-CC: li...@packages.debian.org
> Tags: sid trixie
> User: debian...@lists.debian.org
> Usertags: needs-update
> Control: affects -1 src:linux
> [...]
> 320s # MODPOST
> /var/lib/dkms/nvidia-tesla-470/470.223.02/build/Module.symvers
> 320sscripts/mod/modpost -M -m   -o
> /var/lib/dkms/nvidia-tesla-470/470.223.02/build/Module.symvers -T
> /var/lib/dkms/nvidia-tesla-470/470.223.02/build/modules.order -i
> Module.symvers -e
> 320s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
> '__rcu_read_unlock'
> 320s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
> '__rcu_read_lock'
> 320s make[4]: ***
> [/usr/src/linux-headers-6.6.15-common/scripts/Makefile.modpost:145:
> /var/lib/dkms/nvidia-tesla-470/470.223.02/build/Module.symvers] Error 1

Well, now that Linux 6.1.76 has entered Bookworm as part of today's
point release[0] this bug eccurs there as well. Here the end of my
/var/lib/dkms/nvidia-tesla-470/470.223.02/build/make.log:

| sh /usr/src/linux-headers-6.1.0-18-common/scripts/modules-check.sh 
/var/lib/dkms/nvidia-tesla-470/470.223.02/build/modules.order
| make -f /usr/src/linux-headers-6.1.0-18-common/scripts/Makefile.modpost
|sed 's/ko$/o/'  
/var/lib/dkms/nvidia-tesla-470/470.223.02/build/modules.order | 
scripts/mod/modpost -m -o 
/var/lib/dkms/nvidia-tesla-470/470.223.02/build/Module.symvers -e -i 
Module.symvers -T -
| ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 
'__rcu_read_lock'
| ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 
'__rcu_read_unlock'
| make[3]: *** 
[/usr/src/linux-headers-6.1.0-18-common/scripts/Makefile.modpost:126: 
/var/lib/dkms/nvidia-tesla-470/470.223.02/build/Module.symvers] Error 1
| make[2]: *** [/usr/src/linux-headers-6.1.0-18-common/Makefile:1991: modpost] 
Error 2
| make[2]: Leaving directory '/usr/src/linux-headers-6.1.0-18-amd64'
| make[1]: *** [Makefile:250: __sub-make] Error 2
| make[1]: Leaving directory '/usr/src/linux-headers-6.1.0-18-common'
| make: *** [Makefile:80: modules] Error 2

Thus now marking this bug accordingly.

Cheers,
Flo


[0] 
https://tracker.debian.org/news/1499745/accepted-linux-6176-1-source-into-proposed-updates/


signature.asc
Description: PGP signature

Bug#1014506: slurm-wlm: flaky autopkgtest: sbatch fails without

[Florian Ernst]

Control: affects 1014506 src:libyaml

On Thu, Jul 07, 2022 at 11:22:44AM +0200, Paul Gevers wrote:
> [...]
> I looked at the results of the autopkgtest of you package on armhf because
> it was showing up as a regression for the upload of perl. I noticed that the
> test regularly fails and I saw failures on other architectures too.
> 
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests.

JFTR, this now also affects the unstable-to-testing migration of libyaml,
cf. https://tracker.debian.org/pkg/libyaml. Thus marking this issue here
as such.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1008312: clementine: diff for NMU version 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-2.1

[Florian Ernst]

On Thu, Apr 14, 2022 at 06:23:53PM +0200, Florian Ernst wrote:
> Please note that this bug also affects current stable, i.e. bullseye, and
> should be fixed there as well, as per
> <https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable>.

JFTR, this will now be tracked in <https://bugs.debian.org/1010050>.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1008312: clementine: diff for NMU version 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-2.1

[Florian Ernst]

Control: tags 1008312 + patch
Control: tags 1008312 + pending

Dear maintainer,

I've prepared an NMU for clementine (versioned as
1.4.0~rc1+git347-gfc4cb6fc7+dfsg-2.1) and uploaded it to DELAYED/7.
Please feel free to tell me if I should delay it longer.

I have verified that adding an explicit Depends on libqt5sql5-sqlite
allows clementine to start again and play some stuff as follows:
- create minimal chroot and enter
- install clementine via "apt install --no-install-recommends clementine"
- start clementine -> fails as reported
- install libqt5sql5-sqlite
- start clementine -> starts and allows to play music

Please note that this bug also affects current stable, i.e. bullseye, and
should be fixed there as well, as per
<https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable>.

Best regards,
Flo
diff -Nru clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog
--- clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog	2022-02-12 18:15:45.0 +0100
+++ clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog	2022-04-14 18:00:57.0 +0200
@@ -1,3 +1,10 @@
+clementine (1.4.0~rc1+git347-gfc4cb6fc7+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add explicit Depends on libqt5sql5-sqlite (Closes: #1008312)
+
+ -- Florian Ernst   Thu, 14 Apr 2022 18:00:57 +0200
+
 clementine (1.4.0~rc1+git347-gfc4cb6fc7+dfsg-2) unstable; urgency=medium
 
   [ Pino Toscano ]
diff -Nru clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/control clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/control
--- clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/control	2020-10-27 11:47:50.0 +0100
+++ clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/control	2022-04-14 17:26:41.0 +0200
@@ -38,6 +38,7 @@
 Package: clementine
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends},
+ libqt5sql5-sqlite,
  gstreamer1.0-plugins-base,
  gstreamer1.0-plugins-good,
  gstreamer1.0-plugins-ugly


signature.asc
Description: PGP signature

Bug#1008687: FTBFS: as-test_pool FAIL killed by signal 6 SIGABRT

[Florian Ernst]

Hello Matthias,

On Mon, Apr 11, 2022 at 11:14:41AM +0200, Matthias Klumpp wrote:
> I'll likely downgrade this bug, but this is fairly odd! If the tests
> fail on some building machines, there is a chance that the actual
> application also doesn't work everywhere. I can say though that this
> works on the buildds, on my local machine and on GitLab. Is there
> anything that's different in the reproducible build machines compared
> to the buildds? Is there anything special about your local machine?

Well, apperently there is, and I'd love to know what exactly it is, but
I'm afraid I don't know. I am using sbuild just like the buildd do, but
reproducible-builds is using pbuilder (cowbuilder?), and all in all I
don't see any common factor.

That being said I take some strange consolation now from the weird fact
that appstream 0.15.3-1 seems to FTBFS on reproducible-builds as well,
or at least on amd64, arm64, and armhf so far, right in the same manner
as initially reported. Yeah, I know, that is not really helpful ...

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1008687: FTBFS: as-test_pool FAIL killed by signal 6 SIGABRT

[Florian Ernst]

Hello Matthias,

thank you for your reply and for the appstream update.

On Sun, Apr 10, 2022 at 11:08:40PM +0200, Matthias Klumpp wrote:
> Am Mi., 30. März 2022 um 20:21 Uhr schrieb Florian Ernst 
> :
> > during a rebuild of the reverse b-d of libyaml I found that this package
> > failed to build on my amd64.
> >
> > In addition, the build also failed on amd64, i386, arm64, and armhf,
> > each both in unstable and in bookworm, cf.
> > <https://tests.reproducible-builds.org/debian/rb-pkg/appstream.html>
> > where you will also find full logs.
> 
> I can't reproduce this issue at all, and a recent upload of AppStream
> is building fine on all architectures...
> Does this issue still exist? Maybe it was a fluke or fixed in some
> other component meanwhile...

I agree that the new upload appears to be building just fine on the
official buildd, so thanks for that.

Unfortunately, for me both the previous version and the current version
still FTBFS on my local setup, with exactly the same error message. Of
course, that by itself could all too easily be a local fluke that I'd
have to investigate and that you could safely ignore, if it weren't for
reproducible-builds indicating the very same FTBFS as well.

Looking at the reproducible-builds history of appstream it seems it has
been FTBFS'ing in their setup for quite a while, cf.

https://tests.reproducible-builds.org/debian/history/appstream.html

as well as the individual logs at

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/appstream_0.15.2-2.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/unstable/i386/appstream_0.15.2-2.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/appstream_0.15.2-2.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/appstream_0.15.2-2.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/bookworm/amd64/appstream_0.15.2-2.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/bookworm/i386/appstream_0.15.2-2.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/bookworm/arm64/appstream_0.15.2-2.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/bookworm/armhf/appstream_0.15.2-2.rbuild.log.gz

All in all this hints at some issue still lingering around, but I cannot
exactly pinpoint what it might be.

I'd say let's wait until reproducible-builds attempts to build 0.15.3-1
and see what the results are. Or feel free to downgrade this issue here
as you deem fit, for on the official buildd and on your machine
everything seems to be working juts fine.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1008312: clementine doesn't start

[Florian Ernst]

Hello scorpion2185,

thanks for your report. Please bear with me, as I am not the package
maintainer but just stumbled over this report.

On Sat, Mar 26, 2022 at 05:55:26PM +0100, realroot wrote:
> clementine doesn't start:
> 
> -
> clementine
> 17:53:14.456 WARN  unknown  QSqlDatabase: QSQLITE 
> driver not loaded
> 17:53:14.456 WARN  unknown  QSqlDatabase: available 
> drivers:
> [...]

Do you have the package "libqt5sql5-sqlite" installed? If not please
install it and retry.

This package normally is installed on KDE-based systems, but it seems
clementine is not explicitly forcing its installation via declaring a
Depends, so it could happen that this package is missing even though
clementine needs it.

@Thomas, I confirmed that clementine in current Bullseye behaves just
like reported if that package is missing, and the reported empty list of
available drivers indicates this is indeed the culprit. Once confirmed
by the submitter clementine will need to add an explicit Depends on that
package, both in Sid and in Bullseye (in Buster, too? I haven't checked
...).

Best regards,
Flo


signature.asc
Description: PGP signature

Bug#1000980: kubernetes: diff for NMU version 1.20.5+really1.20.2-1.1

[Florian Ernst]

Dear maintainer,

I've prepared an NMU for kubernetes (versioned as 1.20.5+really1.20.2-1.1)
and uploaded it to DELAYED/7. Please feel free to tell me if I should
delay it longer.
(Note: the previous upload as per
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000980#41> has been
canceled, this one here will replace it.)

The diff is based on what I previously sent to this bugreport in
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000980#31>, but now
updated to use "golang-go" as per Shengjing Zhu's hint in
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000980#50> (and yes,
we could have saved a roundtrip here ...).

The binary package debdiff just lists
| $ debdiff kubernetes-client_1.20.5+really1.20.2-1_amd64.deb 
kubernetes-client_1.20.5+really1.20.2-1.1_amd64.deb
| File lists identical (after any substitutions)
| 
| Control files: lines which differ (wdiff format)
| 
| Installed-Size: [-40405-] {+37547+}
| Version: [-1.20.5+really1.20.2-1-] {+1.20.5+really1.20.2-1.1+}

I tested the kubectl binary against a local KinD cluster and found no
issues. Basic testing as follows:
| [ ... same (successful) results as before snipped ...]
| $ ./kubectl version
| Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.2", 
GitCommit:"faecb196815e248d3ecfb03c680a4507229c2a56", GitTreeState:"archive", 
BuildDate:"2022-04-02T14:49:13Z", GoVersion:"go1.18", Compiler:"gc", 
Platform:"linux/amd64"}
| Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.1", 
GitCommit:"5e58841cce77d4bc13713ad2b91fa0d961e69192", GitTreeState:"clean", 
BuildDate:"2021-05-21T23:01:33Z", GoVersion:"go1.16.4", Compiler:"gc", 
Platform:"linux/amd64"}

Please also find attached the local build log.

Best regards,
Flo
diff -Nru kubernetes-1.20.5+really1.20.2/debian/changelog kubernetes-1.20.5+really1.20.2/debian/changelog
--- kubernetes-1.20.5+really1.20.2/debian/changelog	2021-06-13 09:08:18.0 +0200
+++ kubernetes-1.20.5+really1.20.2/debian/changelog	2022-04-02 16:49:13.0 +0200
@@ -1,3 +1,10 @@
+kubernetes (1.20.5+really1.20.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build using golang-go (Closes: #1000980)
+
+ -- Florian Ernst   Sat, 02 Apr 2022 16:49:13 +0200
+
 kubernetes (1.20.5+really1.20.2-1) unstable; urgency=medium
 
   * This is actually still 1.20.2
diff -Nru kubernetes-1.20.5+really1.20.2/debian/control kubernetes-1.20.5+really1.20.2/debian/control
--- kubernetes-1.20.5+really1.20.2/debian/control	2021-06-13 09:08:18.0 +0200
+++ kubernetes-1.20.5+really1.20.2/debian/control	2022-04-02 16:49:00.0 +0200
@@ -2,7 +2,7 @@
 Section: admin
 Priority: optional
 Maintainer: Janos Lenart 
-Build-Depends: debhelper (>= 12~), bash-completion, golang-1.15-go, jq, rsync
+Build-Depends: debhelper (>= 12~), bash-completion, golang-go, jq, rsync
 Standards-Version: 4.5.0
 Homepage: http://kubernetes.io/
 
diff -Nru kubernetes-1.20.5+really1.20.2/debian/rules kubernetes-1.20.5+really1.20.2/debian/rules
--- kubernetes-1.20.5+really1.20.2/debian/rules	2020-10-21 13:29:24.0 +0200
+++ kubernetes-1.20.5+really1.20.2/debian/rules	2022-04-02 16:49:00.0 +0200
@@ -2,7 +2,7 @@
 
 export DH_VERBOSE = 1
 export GOPATH = $(CURDIR)/.go
-export PATH := /usr/lib/go-1.15/bin:$(PATH)
+export PATH := /usr/lib/go/bin:$(PATH)
 export CGO_ENABLED = 0
 
 %:
sbuild (Debian sbuild) 0.81.2 (31 January 2021) on fernst.no-ip.org

+==+
| kubernetes 1.20.5+really1.20.2-1.1 (amd64)   Sat, 02 Apr 2022 14:51:12 + |
+==+

Package: kubernetes
Version: 1.20.5+really1.20.2-1.1
Source Version: 1.20.5+really1.20.2-1.1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-84aad74e-1348-46a6-8c5c-123eb8e424d9'
 with '<>'
I: NOTICE: Log filtering will replace 'build/kubernetes-6AFsTn/resolver-UBQyvV' 
with '<>'

+--+
| Update chroot|
+--+

Get:1 http://127.0.0.1:3142/deb.debian.org/debian unstable InRelease [165 kB]
Get:2 http://127.0.0.1:3142/deb.debian.org/debian unstable/main 
Sources.diff/Index [63.6 kB]
Get:3 http://127.0.0.1:3142/deb.debian.org/debian unstable/main amd64 
Packages.diff/Index [63.6 kB]
Get:4 http://127.0.0.1:3142/deb.deb

Bug#1000980: kubernetes: diff for NMU version 1.20.5+really1.20.2-1.1

[Florian Ernst]

Control: tags 1000980 + patch
Control: tags 1000980 + pending

Dear maintainer,

I've prepared an NMU for kubernetes (versioned as 1.20.5+really1.20.2-1.1)
and uploaded it to DELAYED/7. Please feel free to tell me if I should
delay it longer.

The diff is based on what I previously sent to this bugreport in
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000980#31>.
The binary package debdiff just lists
| $ debdiff kubernetes-client_1.20.5+really1.20.2-1_amd64.deb 
kubernetes-client_1.20.5+really1.20.2-1.1_amd64.deb
| File lists identical (after any substitutions)
| 
| Control files: lines which differ (wdiff format)
| 
| Installed-Size: [-40405-] {+38907+}
| Version: [-1.20.5+really1.20.2-1-] {+1.20.5+really1.20.2-1.1+}

I tested the kubectl binary against a local KinD cluster and found no
issues. Basic testing as follows:
| 15:47:27 ⌁0% 1d :~/debian/temp/kubernetes $ ./kubectl create deployment nginx 
--image=nginx
| deployment.apps/nginx created
| 15:47:57 ⌁0% 1d :~/debian/temp/kubernetes $ ./kubectl expose deployment nginx 
--type LoadBalancer --port 80
| service/nginx exposed
| 15:48:04 ⌁0% 1d :~/debian/temp/kubernetes $ kubectl get svc nginx
| NAMETYPE   CLUSTER-IP EXTERNAL-IPPORT(S)AGE
| nginx   LoadBalancer   10.96.54.121   172.19.255.1   80:30032/TCP   14s
| 15:48:18 ⌁0% 1d :~/debian/temp/kubernetes $ curl 172.19.255.1
| 
| 
| 
| Welcome to nginx!
| 
| html { color-scheme: light dark; }
| body { width: 35em; margin: 0 auto;
| font-family: Tahoma, Verdana, Arial, sans-serif; }
| 
| 
| 
| Welcome to nginx!
| If you see this page, the nginx web server is successfully installed and
| working. Further configuration is required.
| 
| For online documentation and support please refer to
| http://nginx.org/";>nginx.org.
| Commercial support is available at
| http://nginx.com/";>nginx.com.
| 
| Thank you for using nginx.
| 
| 
| 15:48:25 ⌁0% 1d :~/debian/temp/kubernetes $ ./kubectl get po
| NAME READY   STATUSRESTARTS   AGE
| nginx-6799fc88d8-v5ms9   1/1 Running   0  77s
| 15:48:59 ⌁0% 1d :~/debian/temp/kubernetes $ ./kubectl exec -it 
nginx-6799fc88d8-v5ms9 -- hostname
| nginx-6799fc88d8-v5ms9
| 15:49:20 ⌁0% 1d :~/debian/temp/kubernetes $ ./kubectl delete deploy,svc nginx
| deployment.apps "nginx" deleted
| service "nginx" deleted
| 15:49:36 ⌁0% 1d :~/debian/temp/kubernetes $ ./kubectl get po
| No resources found in default namespace.
| 15:49:41 ⌁0% 1d :~/debian/temp/kubernetes $ ./kubectl version
| Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.2", 
GitCommit:"faecb196815e248d3ecfb03c680a4507229c2a56", GitTreeState:"archive", 
BuildDate:"2022-04-02T13:36:06Z", GoVersion:"go1.17.8", Compiler:"gc", 
Platform:"linux/amd64"}
| Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.1", 
GitCommit:"5e58841cce77d4bc13713ad2b91fa0d961e69192", GitTreeState:"clean", 
BuildDate:"2021-05-21T23:01:33Z", GoVersion:"go1.16.4", Compiler:"gc", 
Platform:"linux/amd64"}

Please also find attached the local build log.

Best regards,
Flo
diff -Nru kubernetes-1.20.5+really1.20.2/debian/changelog kubernetes-1.20.5+really1.20.2/debian/changelog
--- kubernetes-1.20.5+really1.20.2/debian/changelog	2021-06-13 09:08:18.0 +0200
+++ kubernetes-1.20.5+really1.20.2/debian/changelog	2022-04-02 15:36:06.0 +0200
@@ -1,3 +1,10 @@
+kubernetes (1.20.5+really1.20.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build using golang-1.17-go (Closes: #1000980)
+
+ -- Florian Ernst   Sat, 02 Apr 2022 15:36:06 +0200
+
 kubernetes (1.20.5+really1.20.2-1) unstable; urgency=medium
 
   * This is actually still 1.20.2
diff -Nru kubernetes-1.20.5+really1.20.2/debian/control kubernetes-1.20.5+really1.20.2/debian/control
--- kubernetes-1.20.5+really1.20.2/debian/control	2021-06-13 09:08:18.0 +0200
+++ kubernetes-1.20.5+really1.20.2/debian/control	2022-02-27 13:55:20.0 +0100
@@ -2,7 +2,7 @@
 Section: admin
 Priority: optional
 Maintainer: Janos Lenart 
-Build-Depends: debhelper (>= 12~), bash-completion, golang-1.15-go, jq, rsync
+Build-Depends: debhelper (>= 12~), bash-completion, golang-1.17-go, jq, rsync
 Standards-Version: 4.5.0
 Homepage: http://kubernetes.io/
 
diff -Nru kubernetes-1.20.5+really1.20.2/debian/rules kubernetes-1.20.5+really1.20.2/debian/rules
--- kubernetes-1.20.5+really1.20.2/debian/rules	2020-10-21 13:29:24.0 +0200
+++ kubernetes-1.20.5+really1.20.2/debian/rules	2022-02-27 13:55:20.0 +0100
@@ -2,7 +2,7 @@
 
 export DH_VERBOSE = 1
 export GOPATH = $(CURDIR)/.go
-export PATH := /usr/lib/go-1.15/bin:$(PATH)
+export PATH := /usr/lib/go-1.17/bin:$(PATH)
 export CGO_ENABLED = 0
 

Bug#1008698: libprelude-dev: Depends on unavailable package libltdl3-dev

[Florian Ernst]

JFTR:

On Wed, Mar 30, 2022 at 10:00:26PM +0200, Florian Ernst wrote:
> libtool 2.4.7-2 started to not provide the virtual package libltdl3-dev
> anymore, and as such this package here is now uninstallable due to a
> Depends on it. [...]

Some more background can be found in
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008470>.

Best regards,
Flo


signature.asc
Description: PGP signature

Bug#1008698: libprelude-dev: Depends on unavailable package libltdl3-dev

[Florian Ernst]

Package: libprelude-dev
Version: 5.2.0-5+b2
Severity: grave
Justification: renders package unusable

Hello there,

libtool 2.4.7-2 started to not provide the virtual package libltdl3-dev
anymore, and as such this package here is now uninstallable due to a
Depends on it.

For reference, libtool migrated to just providing libltdl3-dev from
libltdl-dev starting with 2.2.6a-2 from 30 Mar 2009, but now libltdl-dev
does not provide any such compatibility provides anymore.

Best regards,
Flo


signature.asc
Description: PGP signature

Bug#984114: liblastfm: diff for NMU version 1.0.9-1.2

[Florian Ernst]

Hello Stefan,

On Sun, Feb 13, 2022 at 11:30:07AM +, Stefan Ahlers wrote:
> I apologize for the very long delay. Thank you for preparing an NMU. Due to
> my private situation I'm unable to continue maintaining this package.
> Therefore, where is no reason to delay the upload any longer.

Thanks for the feedback! I have thus just rescheduled the upload from
DELAYED/7 to DELAYED/0.

Also thank you for your contributions, and all the best from my side.
I see that you have orphaned your remaining packages, and I'm sorry to
see you go.  Perhaps some other time again ...

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#984114: liblastfm: diff for NMU version 1.0.9-1.2

[Florian Ernst]

Dear maintainer,

I've prepared an NMU for liblastfm (versioned as 1.0.9-1.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Cheers,
Flo
diff -Nru liblastfm-1.0.9/debian/changelog liblastfm-1.0.9/debian/changelog
--- liblastfm-1.0.9/debian/changelog	2019-08-23 23:37:23.0 +0200
+++ liblastfm-1.0.9/debian/changelog	2022-02-13 08:04:58.0 +0100
@@ -1,3 +1,11 @@
+liblastfm (1.0.9-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with GCC-11 by removing dynamic exception specifications,
+patch taken from upstream PR. (Closes: #984114)
+
+ -- Florian Ernst   Sun, 13 Feb 2022 08:04:58 +0100
+
 liblastfm (1.0.9-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru liblastfm-1.0.9/debian/patches/fix_gcc11_ftbfs.patch liblastfm-1.0.9/debian/patches/fix_gcc11_ftbfs.patch
--- liblastfm-1.0.9/debian/patches/fix_gcc11_ftbfs.patch	1970-01-01 01:00:00.0 +0100
+++ liblastfm-1.0.9/debian/patches/fix_gcc11_ftbfs.patch	2022-02-13 08:03:57.0 +0100
@@ -0,0 +1,49 @@
+Description: Fix GCC-11 build issue
+Author: Xeonacid
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984114
+Bug-Upstream: https://github.com/lastfm/liblastfm/issues/39
+Origin: upstream, https://github.com/lastfm/liblastfm/pull/41/commits/d51ad3e759331d7d79c6675c5d22541280bf9a70
+Index: liblastfm-1.0.9/src/fingerprint/Fingerprint.cpp
+===
+--- liblastfm-1.0.9.orig/src/fingerprint/Fingerprint.cpp
 liblastfm-1.0.9/src/fingerprint/Fingerprint.cpp
+@@ -94,7 +94,7 @@ lastfm::Fingerprint::data() const
+ 
+ 
+ void
+-lastfm::Fingerprint::generate( FingerprintableSource* ms ) throw( Error )
++lastfm::Fingerprint::generate( FingerprintableSource* ms )
+ {
+ //TODO throw if we can't get required metadata from the track object
+ 
+@@ -306,7 +306,7 @@ lastfm::Fingerprint::submit() const
+ 
+ 
+ void
+-lastfm::Fingerprint::decode( QNetworkReply* reply, bool* complete_fingerprint_requested ) throw( Error )
++lastfm::Fingerprint::decode( QNetworkReply* reply, bool* complete_fingerprint_requested )
+ {
+ // The response data will consist of a number and a string.
+ // The number is the fpid and the string is either FOUND or NEW
+Index: liblastfm-1.0.9/src/fingerprint/Fingerprint.h
+===
+--- liblastfm-1.0.9.orig/src/fingerprint/Fingerprint.h
 liblastfm-1.0.9/src/fingerprint/Fingerprint.h
+@@ -71,7 +71,7 @@ namespace lastfm
+ };
+ 
+ /** This is CPU intensive, do it in a thread in your GUI application */
+-void generate( FingerprintableSource* ) throw( Error );
++void generate( FingerprintableSource* );
+ 
+ /** Submits the fingerprint data to Last.fm in order to get a FingerprintId
+   * back. You need to wait for the QNetworkReply to finish before you can
+@@ -82,7 +82,7 @@ namespace lastfm
+   * will be valid. Otherwise we will throw. You always get a valid id
+   * or a throw.
+   */
+-void decode( QNetworkReply*, bool* lastfm_needs_a_complete_fingerprint = 0 ) throw( Error );
++void decode( QNetworkReply*, bool* lastfm_needs_a_complete_fingerprint = 0 );
+ };
+ 
+ 
diff -Nru liblastfm-1.0.9/debian/patches/series liblastfm-1.0.9/debian/patches/series
--- liblastfm-1.0.9/debian/patches/series	2015-11-20 16:42:23.0 +0100
+++ liblastfm-1.0.9/debian/patches/series	2022-01-14 22:27:26.0 +0100
@@ -1,2 +1,3 @@
 change_target-name.patch
 strip_README.patch
+fix_gcc11_ftbfs.patch


signature.asc
Description: PGP signature

Bug#1002192: kitinerary: FTBFS: 12: QWARN : ExtractorScriptEngineTest::testInfiniteLoop() org.kde.kitinerary: JS ERROR: [qrc://buggy.js]:0: Error: Interrupted

[Florian Ernst]

tags 1002192 patch
thanks

On Tue, Dec 21, 2021 at 05:02:35PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> [...]
> > test 29
> >   Start 29: calendarhandlertest
> > 
> > 29: Test command: 
> > /<>/obj-x86_64-linux-gnu/bin/calendarhandlertest
> > 29: Environment variables: 
> > 29:  QT_PLUGIN_PATH=/<>/obj-x86_64-linux-gnu/bin:
> > 29: Test timeout computed to be: 1000
> > 29: * Start testing of CalendarHandlerTest *
> > 29: Config: Using QtTest library 5.15.2, Qt 5.15.2 
> > (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 11.2.0), 
> > debian unknown
> > 29: PASS   : CalendarHandlerTest::initTestCase()
> > 29: PASS   : CalendarHandlerTest::testCreateEvent(canceled.json)
> > 29: QWARN  : CalendarHandlerTest::testCreateEvent(event.json) 
> > QFSFileEngine::open: No file name specified
> > 29: QWARN  : CalendarHandlerTest::testCreateEvent(event.json) 
> > kf.i18n.localeData: Unable to open iso_3166-1.json "" "No file name 
> > specified"
> > 29: QWARN  : CalendarHandlerTest::testCreateEvent(event.json) 
> > QFSFileEngine::open: No file name specified
> > 29: QWARN  : CalendarHandlerTest::testCreateEvent(event.json) 
> > kf.i18n.localeData: Unable to open iso_3166-1.json "" "No file name 
> > specified"
> > 29: QWARN  : CalendarHandlerTest::testCreateEvent(event.json) 
> > QFSFileEngine::open: No file name specified
> > 29: QWARN  : CalendarHandlerTest::testCreateEvent(event.json) 
> > kf.i18n.localeData: Unable to open iso_3166-1.json "" "No file name 
> > specified"
> > 29: QWARN  : CalendarHandlerTest::testCreateEvent(event.json) kf.contacts: 
> > address format database incomplete (no format for locale "" found). Using 
> > default address formatting.
> > 29: QDEBUG : CalendarHandlerTest::testCreateEvent(event.json) Actual:  
> > BEGIN:VCALENDAR

(similar messages reported for the other failures)

That file iso_3166-1.json is part of the iso-codes package which was
*not* installed during the build as can be seen from the full build log

> http://qa-logs.debian.net/2021/12/20/kitinerary_21.08.1-1_unstable.log

which lists

| Recommended packages:
|   curl | wget | lynx ca-certificates dbus libarchive-cpio-perl libglib2.0-data
|   xdg-user-dirs libkf5archive-doc libkf5codecs-doc libkf5config-doc iso-codes
  ^
and I can confirm that without that package the build indeed fails.

However, when adding that package to B-D the build reproducably succeeds
again. This is a bit weird as during previous builds that package
apparently wasn't required, as can be seen in the old build logs, but it
seems now it is. Still, I'm taking the liberty to tag this bug "patch".

Cheers,
Flo
diff -Nru kitinerary-21.08.1/debian/control kitinerary-21.08.1/debian/control
--- kitinerary-21.08.1/debian/control   2021-09-11 00:21:58.0 +0200
+++ kitinerary-21.08.1/debian/control   2022-01-29 13:46:39.0 +0100
@@ -8,6 +8,7 @@
debhelper-compat (= 13),
extra-cmake-modules (>= 5.83.0~),
gettext,
+   iso-codes,
libkf5archive-dev (>= 5.71.0~),
libkf5calendarcore-dev (>= 5:5.83.0~),
libkf5contacts-dev (>= 5:5.83.0~),


signature.asc
Description: PGP signature

Bug#984114: liblastfm: ftbfs with GCC-11

[Florian Ernst]

forwarded 984114 https://github.com/lastfm/liblastfm/issues/39
tags 984114 + patch
thanks

On Wed, Mar 03, 2021 at 04:14:30PM +, Matthias Klose wrote:
> [...]
> /<>/src/fingerprint/Fingerprint.cpp:97:60: error: ISO C++17 does 
> not allow dynamic exception specifications
>97 | lastfm::Fingerprint::generate( FingerprintableSource* ms ) throw( 
> Error )
>   |^
> /<>/src/fingerprint/Fingerprint.cpp:309:91: error: ISO C++17 
> does not allow dynamic exception specifications
>   309 | lastfm::Fingerprint::decode( QNetworkReply* reply, bool* 
> complete_fingerprint_requested ) throw( Error )
>   |   
> ^
> make[4]: *** 
> [src/fingerprint/CMakeFiles/lastfm_fingerprint5.dir/build.make:111: 
> src/fingerprint/CMakeFiles/lastfm_fingerprint5.dir/Fingerprint.cpp.o] Error 1
> [...]

FWIW, I can confirm that 1.0.9-1.1 still FTBFS in the manner originally
reported in this bug, but with the attached debdiff implementing the fix
from upstream I was able to build it again.

This is referenced in https://github.com/lastfm/liblastfm/issues/39 from
where I extracted the patch.

HTH, and please feel free to adjust to your liking.

Cheers,
Florian
diff -Nru liblastfm-1.0.9/debian/changelog liblastfm-1.0.9/debian/changelog
--- liblastfm-1.0.9/debian/changelog2019-08-23 23:37:23.0 +0200
+++ liblastfm-1.0.9/debian/changelog2022-01-14 22:30:53.0 +0100
@@ -1,3 +1,11 @@
+liblastfm (1.0.9-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with GCC-11 by removing dynamic exception specifications,
+    patch taken from upstream. (Closes: #984114)
+
+ -- Florian Ernst   Fri, 14 Jan 2022 22:30:53 +0100
+
 liblastfm (1.0.9-1.1) unstable; urgency=medium

   * Non-maintainer upload.
diff -Nru liblastfm-1.0.9/debian/patches/fix_gcc11_ftbfs.patch 
liblastfm-1.0.9/debian/patches/fix_gcc11_ftbfs.patch
--- liblastfm-1.0.9/debian/patches/fix_gcc11_ftbfs.patch1970-01-01 
01:00:00.0 +0100
+++ liblastfm-1.0.9/debian/patches/fix_gcc11_ftbfs.patch2022-01-14 
22:30:47.0 +0100
@@ -0,0 +1,46 @@
+Description: Fix GCC-11 build issue
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984114
+Index: liblastfm-1.0.9/src/fingerprint/Fingerprint.cpp
+===
+--- liblastfm-1.0.9.orig/src/fingerprint/Fingerprint.cpp
 liblastfm-1.0.9/src/fingerprint/Fingerprint.cpp
+@@ -94,7 +94,7 @@ lastfm::Fingerprint::data() const
+
+
+ void
+-lastfm::Fingerprint::generate( FingerprintableSource* ms ) throw( Error )
++lastfm::Fingerprint::generate( FingerprintableSource* ms )
+ {
+ //TODO throw if we can't get required metadata from the track object
+
+@@ -306,7 +306,7 @@ lastfm::Fingerprint::submit() const
+
+
+ void
+-lastfm::Fingerprint::decode( QNetworkReply* reply, bool* 
complete_fingerprint_requested ) throw( Error )
++lastfm::Fingerprint::decode( QNetworkReply* reply, bool* 
complete_fingerprint_requested )
+ {
+ // The response data will consist of a number and a string.
+ // The number is the fpid and the string is either FOUND or NEW
+Index: liblastfm-1.0.9/src/fingerprint/Fingerprint.h
+===
+--- liblastfm-1.0.9.orig/src/fingerprint/Fingerprint.h
 liblastfm-1.0.9/src/fingerprint/Fingerprint.h
+@@ -71,7 +71,7 @@ namespace lastfm
+ };
+
+ /** This is CPU intensive, do it in a thread in your GUI application 
*/
+-void generate( FingerprintableSource* ) throw( Error );
++void generate( FingerprintableSource* );
+
+ /** Submits the fingerprint data to Last.fm in order to get a 
FingerprintId
+   * back. You need to wait for the QNetworkReply to finish before you 
can
+@@ -82,7 +82,7 @@ namespace lastfm
+   * will be valid. Otherwise we will throw. You always get a valid id
+   * or a throw.
+   */
+-void decode( QNetworkReply*, bool* 
lastfm_needs_a_complete_fingerprint = 0 ) throw( Error );
++void decode( QNetworkReply*, bool* 
lastfm_needs_a_complete_fingerprint = 0 );
+ };
+
+
diff -Nru liblastfm-1.0.9/debian/patches/series 
liblastfm-1.0.9/debian/patches/series
--- liblastfm-1.0.9/debian/patches/series   2015-11-20 16:42:23.0 
+0100
+++ liblastfm-1.0.9/debian/patches/series   2022-01-14 22:27:26.0 
+0100
@@ -1,2 +1,3 @@
 change_target-name.patch
 strip_README.patch
+fix_gcc11_ftbfs.patch

Bug#984014: clementine: ftbfs with GCC-11

[Florian Ernst]

forwarded 984014 https://github.com/clementine-player/Clementine/issues/6865
tags 984014 + patch
thanks

On Wed, Oct 27, 2021 at 11:05:04PM +0300, Alexander Kernozhitsky wrote:
> It's worth noting that the upstream has already fixed this bug:
>
> https://github.com/clementine-player/Clementine/commit/cfcd0a956e6758624fab0ff20aee9eb08b3df0b3

Indeed, and this is tracked in
https://github.com/clementine-player/Clementine/issues/6865 where that
patch is referenced.

FWIW, I can confirm that 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1 still FTBFS
in the manner originally reported in this bug, but with the attached
debdiff implementing the fix from upstream I was able to build it again.

HTH, and please feel free to adjust to your liking.

Cheers,
Florian
diff -Nru clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog 
clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog
--- clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog
2020-10-27 11:30:27.0 +0100
+++ clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog
2022-01-14 21:44:24.0 +0100
@@ -1,3 +1,11 @@
+clementine (1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with GCC-11 by dropping -std=c++0x and -U__STRICT_ANSI__,
+patch taken from upstream. (Closes: #984014)
+
+ -- Florian Ernst   Fri, 14 Jan 2022 21:44:24 +0100
+
 clementine (1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1) unstable; urgency=medium

   * New upstream snapshot.
diff -Nru 
clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/patches/fix_gcc11_ftbfs.patch
 
clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/patches/fix_gcc11_ftbfs.patch
--- 
clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/patches/fix_gcc11_ftbfs.patch
1970-01-01 01:00:00.0 +0100
+++ 
clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/patches/fix_gcc11_ftbfs.patch
2022-01-14 21:44:24.0 +0100
@@ -0,0 +1,52 @@
+Description: Fix GCC-11 build issue
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984014
+Index: 
clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/ext/clementine-spotifyblob/CMakeLists.txt
+===
+--- 
clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg.orig/ext/clementine-spotifyblob/CMakeLists.txt
 
clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/ext/clementine-spotifyblob/CMakeLists.txt
+@@ -7,7 +7,7 @@ include_directories(${CMAKE_SOURCE_DIR}/
+ include_directories(${CMAKE_SOURCE_DIR}/ext/libclementine-common)
+ include_directories(${CMAKE_SOURCE_DIR}/src)
+
+-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Woverloaded-virtual -Wall 
-Wno-sign-compare -Wno-deprecated-declarations -Wno-unused-local-typedefs 
-Wno-unused-private-field -Wno-unknown-warning-option --std=c++0x 
-U__STRICT_ANSI__")
++set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Woverloaded-virtual -Wall 
-Wno-sign-compare -Wno-deprecated-declarations -Wno-unused-local-typedefs 
-Wno-unused-private-field -Wno-unknown-warning-option")
+
+ link_directories(${SPOTIFY_LIBRARY_DIRS})
+
+Index: 
clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/ext/clementine-tagreader/CMakeLists.txt
+===
+--- 
clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg.orig/ext/clementine-tagreader/CMakeLists.txt
 
clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/ext/clementine-tagreader/CMakeLists.txt
+@@ -7,7 +7,7 @@ include_directories(${CMAKE_BINARY_DIR}/
+ include_directories(${CMAKE_SOURCE_DIR}/src)
+ include_directories(${CMAKE_BINARY_DIR}/src)
+
+-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --std=c++0x -U__STRICT_ANSI__")
++set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
+
+ set(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR})
+
+Index: clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/src/CMakeLists.txt
+===
+--- clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg.orig/src/CMakeLists.txt
 clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/src/CMakeLists.txt
+@@ -1,6 +1,6 @@
+
+ set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall")
+-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Woverloaded-virtual -Wall 
-Wno-sign-compare -Wno-deprecated-declarations -Wno-unused-local-typedefs 
--std=c++0x -U__STRICT_ANSI__")
++set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Woverloaded-virtual -Wall 
-Wno-sign-compare -Wno-deprecated-declarations -Wno-unused-local-typedefs")
+
+ option(BUILD_WERROR "Build with -Werror" ON)
+
+Index: clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/tests/CMakeLists.txt
+===
+--- clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg.orig/tests/CMakeLists.txt
 clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/tests/CMakeLists.txt
+@@ -1,6 +1,6 @@
+ cmake_minimum_required(VERSION 2.8.11)
+
+-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x -fpermissive 
-Wno-c++11-narrow

Bug#820984: proftpd-basic: cannot preseed / ignores local config changes

[Florian Ernst]

Package: proftpd-basic
Version: 1.3.5-1.1+deb8u1
Severity: serious
Justification: rc_policy.txt 3. Configuration files: "Changes to configuration 
files must be preserved during a package upgrade."

Dear Maintainer(s),

please consider the following (abridged) transcript of trying to run
proftpd-basic from inetd, but ending up having it running standalone:

root@testvz12:~# debconf-get-selections | grep proftpd || echo '# no match'
# no match
root@testvz12:~# echo 'proftpd-basic   shared/proftpd/inetd_or_standalone  
select  from inetd' | debconf-set-selections
root@testvz12:~# debconf-get-selections | grep proftpd || echo '# no match'
proftpd-basic   shared/proftpd/inetd_or_standalone  select   from inetd
root@testvz12:~# apt-get install -y openbsd-inetd
[...]
root@testvz12:~# DEBIAN_FRONTEND=noninteractive apt-get install -y proftpd-basic
[...]
root@testvz12:~# debconf-get-selections | grep proftpd || echo '# no match'
# Run proftpd:
proftpd-basic   shared/proftpd/inetd_or_standalone  select  standalone
root@testvz12:~# ps auxww | grep '[p]roftpd'
proftpd   2138  0.0  0.2 119900  2524 ?Ss   11:28   0:00 proftpd: 
(accepting connections)  
root@testvz12:~# netstat -tulpen | grep 21
tcp6   0  0 :::21   :::*LISTEN  
1081069993275  2138/proftpd: (acce

As you can see, the preseeding had no effect. This is due to
/var/lib/dpkg/info/proftpd-basic.config unconditionally calling
"db_set shared/proftpd/inetd_or_standalone standalone" before calling
"db_input high shared/proftpd/inetd_or_standalone", thus overwriting any
previous setting. JFTR, apparently it was debbug#707689 which triggered
adding the explicit db_set.

The same applies to any reconfiguring, of course:

root@testvz12:~# echo 'proftpd-basic   shared/proftpd/inetd_or_standalone  
select  from inetd' | debconf-set-selections
root@testvz12:~# debconf-get-selections | grep proftpd || echo '# no match'
# Run proftpd:
proftpd-basic   shared/proftpd/inetd_or_standalone  select   from inetd
root@testvz12:~# dpkg-reconfigure -fnoninteractive proftpd-basic
usermod: no changes
root@testvz12:~# debconf-get-selections | grep proftpd || echo '# no match'
# Run proftpd:
proftpd-basic   shared/proftpd/inetd_or_standalone  select  standalone

As such, the package cannot be preseeded to run from inetd at all.

Furthermore, given the current .config, any unattended (thus:
noninteractive) upgrade (or even a mere reinstall) will unconditionally
overwrite the local configuration just the same, leading to proftpd
running standalone instead of from inetd. I consider this to be in
violation of Debian policy requiring local configuration changes to be
preserved.


Best regards,
Flo

-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

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

Bug#760944: loganalyzer: postinst incorrectly checks for activation w/ apache2.4

[Florian Ernst]

Package: loganalyzer
Version: 3.6.6+dfsg-1
Severity: serious
Tags: patch
Justification: Policy 6.2

Hello there,

loganalyzer's postinst creates
/etc/apache2/conf-available/loganalyzer.conf during installation, but
fails to detect that it has already created this file during subsequent
postinst runs, which leads to failure to configure during package
upgrades. This appears to stem from copy-and-waste during converting the
package to work with both apache2.2 and apache2.4. :)

Please see the following transcript for details:

:) fernst@fernst:~$ ls -al /etc/apache2/*/*logana*
lrwxrwxrwx 1 root root 28 Mar 19 12:31 
/etc/apache2/conf-available/loganalyzer.conf -> /etc/loganalyzer/apache.conf
lrwxrwxrwx 1 root root 28 Mar 19 12:31 /etc/apache2/conf.d/loganalyzer -> 
/etc/loganalyzer/apache.conf
lrwxrwxrwx 1 root root 34 Mar 19 12:31 
/etc/apache2/conf-enabled/loganalyzer.conf -> ../conf-available/loganalyzer.conf
:) fernst@fernst:~$ sudo bash
:) root@fernst:/home/fernst$ sh -x /var/lib/dpkg/info/loganalyzer.postinst 
configure
+ set -e
+ [ configure = configure ]
+ webserver=apache2
+ pkgname=loganalyzer
+ [ -x /usr/sbin/apache2 ]
+ a2enmod php5
Module php5 already enabled
+ a2enmod cgi
Module cgi already enabled
+ HTTPD_ETC=/etc/apache2
+ HTTPD_CONF_OLD=/etc/apache2/conf.d
+ HTTPD_CONF_NEW=/etc/apache2/conf-available
+ [ -d /etc/apache2 ]
+ [ -d /etc/apache2/conf.d -a ! -f /etc/apache2/conf.d/loganalyzer -a ! -h 
/etc/apache2/conf.d/loganalyzer ]
+ [ -d /etc/apache2/conf-available -a ! -f 
/etc/apache2/conf-available/loganalyzer -a ! -h 
/etc/apache2/conf-available/loganalyzer ]
+ ln -s /etc/loganalyzer/apache.conf 
/etc/apache2/conf-available/loganalyzer.conf
ln: failed to create symbolic link 
‘/etc/apache2/conf-available/loganalyzer.conf’: File exists
:( root@fernst:/home/fernst$ echo $?
1

The following patch allows the package to be configured again:

:) fernst@fernst:~$ diff -u /var/lib/dpkg/info/loganalyzer.postinst.bak 
/var/lib/dpkg/info/loganalyzer.postinst
--- /var/lib/dpkg/info/loganalyzer.postinst.bak 2014-09-07 08:43:33.0 
+0200
+++ /var/lib/dpkg/info/loganalyzer.postinst 2014-09-09 13:12:48.642837223 
+0200
@@ -48,7 +48,7 @@
 then
 ln -s /etc/${pkgname}/apache.conf ${HTTPD_CONF_OLD}/${pkgname}
 fi
-if [ -d ${HTTPD_CONF_NEW} -a ! -f ${HTTPD_CONF_NEW}/${pkgname} -a 
! -h ${HTTPD_CONF_NEW}/${pkgname} ];
+if [ -d ${HTTPD_CONF_NEW} -a ! -f 
${HTTPD_CONF_NEW}/${pkgname}.conf -a ! -h ${HTTPD_CONF_NEW}/${pkgname}.conf ];
 then
 ln -s /etc/${pkgname}/apache.conf 
${HTTPD_CONF_NEW}/${pkgname}.conf
 if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then

HTH,
Flo

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (50, 'testing-proposed-updates'), (50, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages loganalyzer depends on:
ii  apache2  2.4.10-1
ii  apache2-bin [httpd-cgi]  2.4.10-1
ii  apache2-mpm-prefork [httpd-cgi]  2.4.10-1
ii  debconf  1.5.53
ii  libapache2-mod-php5  5.6.0+dfsg-1
ii  php5 5.6.0+dfsg-1
ii  ttf-bitstream-vera   1.10-8

Versions of packages loganalyzer recommends:
ii  php5-mongo  1.4.5-2+b1

Versions of packages loganalyzer suggests:
ii  php5-gd  5.6.0+dfsg-1
ii  rsyslog  8.4.0-2

-- Configuration Files:
/etc/loganalyzer/config.php changed [not included]

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#746642: Fails to detect SATA disks

[Florian Ernst]

Hello there,

On Sun, May 11, 2014 at 03:07:36AM +0100, Ben Hutchings wrote:
> On Wed, 2014-05-07 at 15:05 +0200, Salvatore Bonaccorso wrote:
> > This is the commit which is reverted in 3.2.58, which fixes these
> > issue:
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/bwh/linux-3.2.y.git/commit/?id=2e59f013993a74bf31366a59bcf36be830d0f058
> 
> Thanks.  This should be included in a security update shortly.  (Yes,
> even though it is not security-related.)

Hmm, it was updated, and thanks for that. But the d-i kernel in Wheezy
wasn't updated accordingly: it is still based on 7.5, so right now
installing on such a device is only possible using the 7.4 installer. 

However, during such an installation, the most recent kernel from
security.debian.org will be installed and thus the system will boot. So
it's not all bad, yet still the common netboot scenarios which just have
the most recent installer available will break. :)

I couldn't find any plans to update the installer with the most recent
Wheezy kernel, but I take it they exist?

Best regards,
Flo


signature.asc
Description: Digital signature

Bug#735530: samhain: FTBFS on amd64 and kfreebsd

[Florian Ernst]

Hello there,

On Sat, Mar 29, 2014 at 02:03:40AM -0600, Adam Conrad wrote:
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * Configure with disable-asm on amd64 targets to work around FTBFS.
>   * Build-depend on autotools-dev to always update config.{sub,guess}
> 
> Obviously, upstream fixing their asm would be better than disabling it,
> but this works around the FTBFS nicely.  [...]

FWIW, using that patch the package builds just fine in current sid on
amd64.

I couldn't find a report concerning this FTBFS in upstream's tracker,
but upstream has dealt with an equivalent issue on cygwin 64bit by
simply disabling assembler as well, cf.
.

Cheers,
Flo


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#731155: arpwatch consumes excessive CPU with libpcap0.8 1.5.1-1

[Florian Ernst]

Hello all,

just chiming in here ...

On Wed, Feb 12, 2014 at 10:18:32PM +0100, Florian Schlichting wrote:
> the issue you reportied looks a lot like
> https://github.com/the-tcpdump-group/libpcap/issues/333 or
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733747, which was
> fixed in libpcap 1.5.3 (uploaded 2014-01-16, in jessie since
> 2014-01-27).
> 
> As I'm unable to reproduce the issue today, would you care to check if a
> current libpcap0.8 >= 1.5.3 makes the infinite loop go away?

I - for one - don't experience any such problems anymore, neither in
arpwatch nor in ndpmon (cf. debbug#731202). Thanks for the pointer!

Cheers,
Flo


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#724179: ksplice: FTBFS: POD errors

[Florian Ernst]

Hello all,

On Sun, Sep 22, 2013 at 08:33:22PM +0200, David Suárez wrote:
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> [...]
> > pod2man: unable to format Ksplice.pm
> > make[1]: *** [Ksplice.pm.8] Error 1

JFTR, please see
:

| do not build pod from files without pod
| There are two helpers wihtout pod in them, but we try to build it with
| a failure:
| pod2man: unable to format Ksplice.pm
| 
| Remove those from the worklist.
| 
| Signed-off-by: Jiri Slaby 

As I haven't tested this I won't tag this bugreport wit "patch".

HTH,
Flo


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#717472: mod_log_sql.so: undefined symbol: ap_log_error_

[Florian Ernst]

retitle 717472 unfinished apache 2.4 transition
severity 717472 normal
thanks

Hello again,

following up to myself:

On Sun, Jul 21, 2013 at 10:23:03AM +0200, Florian Ernst wrote:
> there is some fallout from the recent sourceful transition towards
> Apache 2.4 as called for in #666797. The adapted package should not have
> migrated to testing as long as Apache 2.4 doesn't migrate as well.

Considering that the apache 2.4 migration seems finished and
consequently mod-log-sql works again in testing, this bug isn't grave
anymore.

IMHO the remainder of my initial bugreport still stands, though.
Downgrading and retitling accordingly.

Cheers,
Flo


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#717472: mod_log_sql.so: undefined symbol: ap_log_error_

[Florian Ernst]

Package: libapache2-mod-log-sql
Version: 1.100-15
Tags: jessie
Severity: grave
Justification: renders package unusable

Hello there,

there is some fallout from the recent sourceful transition towards
Apache 2.4 as called for in #666797. The adapted package should not have
migrated to testing as long as Apache 2.4 doesn't migrate as well.

>From a cursory glance this should have been achieved by the following
stanza on arno's initial bugreport:

"Do NOT depend on apache2, apache2-common or any other real apache2
package in your binary module package. Depend on our virtual
apache2-api-20120211 package only!"

I'd recommend to reevaluate all of his hints. For example, your package
still uses a2enmod/a2dismod in your maintainer scripts even though arno
explicitly advises against it ...
As such, I'd personally consider #666797 unresolved, but that is your
call. Still, at the moment, libapache2-mod-log-sql is completely
unusable in testing. Tagged for "jessie" accordingly as the package
version in question is present in sid (presumably bug not present) and
jessie.


Cheers,
Flo


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libapache2-mod-log-sql depends on:
ii  apache2-mpm-prefork  2.2.22-13
ii  libc62.17-7

Versions of packages libapache2-mod-log-sql recommends:
ii  perl  5.14.2-21

libapache2-mod-log-sql suggests no packages.

-- Configuration Files:
/etc/apache2/mods-available/log_sql.load changed [not included]
^^^ simply
deactivated by commenting every single line

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#689290: ldap-git-backup: Missing Depends: libmodern-perl-perl

[Florian Ernst]

Package: ldap-git-backup
Version: 1.0.1-1
Severity: grave
Justification: renders package unusable

Hello there,

$ sed -n -e '3p' /usr/sbin/ldap-git-backup
use Modern::Perl;
$ apt-file search Modern/Perl.pm
libmodern-perl-perl: /usr/share/perl5/Modern/Perl.pm

Without this library the program fails as attached.

Cheers,
Flo

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ldap-git-backup depends on:
ii  git   1:1.7.10.4-1
ii  perl  5.14.2-13

ldap-git-backup recommends no packages.

Versions of packages ldap-git-backup suggests:
ii  slapd  2.4.31-1

-- no debconf information
Received: from root by fernst.no-ip.org with local (Exim 4.80)
(envelope-from )
id 1TIVIg-0004XL-4g
for r...@fernst.no-ip.org; Mon, 01 Oct 2012 04:00:02 +0200
From: r...@fernst.no-ip.org (Cron Daemon)
To: r...@fernst.no-ip.org
Subject: Cron  [ -x /usr/sbin/ldap-git-backup ] && 
/usr/sbin/ldap-git-backup --commit-msg 'daily backup via cron'
Content-Type: text/plain; charset=UTF-8
X-Cron-Env: 
X-Cron-Env: 
X-Cron-Env: 
X-Cron-Env: 
Message-Id: 
Date: Mon, 01 Oct 2012 04:00:02 +0200
Lines: 16

Can't locate Modern/Perl.pm in @INC (@INC contains: /etc/perl 
/usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 
/usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 
/usr/local/lib/site_perl .) at /usr/sbin/ldap-git-backup line 3.
BEGIN failed--compilation aborted at /usr/sbin/ldap-git-backup line 3.

Bug#661528: /etc/nagios-plugins/config/ipmi_sensor.cfg: Duplicate definition found for command 'check_ipmi_sensor'

[Florian Ernst]

Package: nagios-plugins-contrib
Version: 1.20120220
Severity: grave
File: /etc/nagios-plugins/config/ipmi_sensor.cfg
Tags: patch
Justification: renders package unusable

Hello there,

the default ipmi_sensor.cfg ships a duplicate definition for
check_ipmi_sensor which causes icinga to fail:

| Processing object config file '/etc/nagios-plugins/config/ipmi_sensor.cfg'...
| Warning: Duplicate definition found for command 'check_ipmi_sensor' (config 
file '/etc/nagios-plugins/config/ipmi_sensor.cfg', starting on line 15)
| Error: Could not add object property in file 
'/etc/nagios-plugins/config/ipmi_sensor.cfg' on line 16.
|Error processing object config files!
| [...]
| ***> One or more problems was encountered while processing the config files...
| 
|  Check your configuration file(s) to ensure that they contain valid
|  directives and data definitions.  If you are upgrading from a previous
|  version of Icinga, you should be aware that some variables/definitions
|  may have been removed or modified in this version.  Make sure to read
|  the HTML documentation regarding the config files, as well as the
|  'Whats New' section to find out what has changed.
| 
| errors in config! ... failed!
|  failed!

So, merely by installing this package, I couldn't start my monitoring
setup anymore without modifying this file. Of course that can be easily
fixed, but the package as shipped breaks other software.

Cheers,
Flo

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

nagios-plugins-contrib depends on no packages.

Versions of packages nagios-plugins-contrib recommends:
ii  freeipmi-tools   
ii  libc62.13-26
ii  libio-socket-ssl-perl1.54-1
ii  libmail-imapclient-perl  
ii  libmemcached9
ii  libnagios-plugin-perl0.36-1
ii  libnet-dns-perl  0.66-2+b2
ii  libnet-smtp-tls-perl 0.12-1
ii  libnet-ssleay-perl   1.42-1+b1
ii  libreadonly-perl 1.03-3

Versions of packages nagios-plugins-contrib suggests:
pn  cciss-vol-status  
pn  mpt-status

-- Configuration Files:
/etc/nagios-plugins/config/ipmi_sensor.cfg changed:
define command{
command_namecheck_ipmi_sensor
command_line/usr/lib/nagios/plugins/check_ipmi_sensor -H 
$_HOSTIPMI_IP$ -f $ARG1$
}
define command{
command_namecheck_ipmi_sensor_exclude
command_line/usr/lib/nagios/plugins/check_ipmi_sensor -H 
$_HOSTIPMI_IP$ -f $ARG1$ -x $ARG2$
}


-- no debconf information
commit 963984a5c22ee2427c66f297c628e1e450808b76
Author: root 
Date:   Mon Feb 27 21:41:26 2012 +0100

nagios/icinga: fix duplicate definition for check_ipmi_sensor

diff --git a/nagios-plugins/config/ipmi_sensor.cfg b/nagios-plugins/config/ipmi_sensor.cfg
index 946534e..8d78ced 100644
--- a/nagios-plugins/config/ipmi_sensor.cfg
+++ b/nagios-plugins/config/ipmi_sensor.cfg
@@ -13,6 +13,6 @@ define command{
 
 # 'check_ipmi_sensor_exclude' command definition
 define command{
-command_namecheck_ipmi_sensor
+command_namecheck_ipmi_sensor_exclude
 command_line/usr/lib/nagios/plugins/check_ipmi_sensor -H $_HOSTIPMI_IP$ -f $ARG1$ -x $ARG2$
 }

Bug#556687: FTBFS with binutils-gold

[Florian Ernst]

tags patch pending
thanks

A simple patch has been tested to work, I just need to check how to best
integrate it.

Expect a maintainer upload soonish.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#600585: vzctl: package fails to purge due to missing line continuation

[Florian Ernst]

Package: vzctl
Version: 3.0.24-7
Severity: serious
Tags: patch

See subject. Trivial patch attached.

For a problem demonstration see the bottom part of
<http://piuparts.debian.org/sid/fail/vzctl_3.0.24-7.log>.

-- 
Gruss / Best regards  |  LF.net GmbH|  fon +49 711 90074-407
Florian Ernst |  Ruppmannstrasse 27 |  fax +49 711 90074-33
f...@lf.net |  D-70565 Stuttgart  |  http://www.lf.net

Handelsregister Stuttgart: HRB 18 189
Geschaeftsfuehrer: Norman Fuerst, Rodney Volz
diff -u vzctl-3.0.24/debian/vzctl.postrm vzctl-3.0.24/debian/vzctl.postrm
--- vzctl-3.0.24/debian/vzctl.postrm
+++ vzctl-3.0.24/debian/vzctl.postrm
@@ -31,7 +31,7 @@
/etc/cron.d/vpsnetclean,disabled \
/etc/cron.d/vpsreboot,disabled
# Upgrade path for old (lenny version) of vz cron scripts.
-   rm -f
+   rm -f \
/etc/cron.d/vz \
/etc/cron.d/vz,disabled \
/etc/vz/cron/vz
diff -u vzctl-3.0.24/debian/changelog vzctl-3.0.24/debian/changelog
--- vzctl-3.0.24/debian/changelog
+++ vzctl-3.0.24/debian/changelog
@@ -1,3 +1,11 @@
+vzctl (3.0.24-7.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/vzctl.postrm: correctly extend line in Lenny cleanup.
+Closes: #XX.
+
+ -- Florian Ernst   Mon, 18 Oct 2010 13:28:41 +0200
+
 vzctl (3.0.24-7) unstable; urgency=medium
 
   * No longer ignore errors on startup.

Bug#563438: apt-listbugs: Package has a Depends on libdpkg-ruby1.8 (>= 0.3.3) which cannot be satisfied

[Florian Ernst]

Package: apt-listbugs
Version: 0.1.2
Severity: grave
Justification: renders package unusable

Hello all,

commit da6864ae240d2ea2458b1c53aca2675ed1985f04 appears to have been
based on assumptions current reality fails to provide:
"Package has a Depends on libdpkg-ruby1.8 (>= 0.3.3) which cannot be
satisfied on *."


And indeed, such a package version is nowhere to be seen at the moment,
thus rendering apt-listbugs 0.1.2 uninstallable on all architectures.

Ryan, as you intent to adopt dpkg-ruby, I take it you wanted to release
a new version / have released a new version privately already, that
somehow didn't yet make it into the archives?

Cheers,
Flo

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'oldstable'), (990, 'testing'), (990, 'stable'), (500, 
'oldstable-proposed-updates'), (50, 'testing-proposed-updates'), (50, 
'proposed-updates'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages apt-listbugs depends on:
ii  apt  0.7.25  Advanced front-end for dpkg
ii  libdpkg-ruby1.8  0.3.2   modules/classes for dpkg on ruby 1
ii  libgettext-ruby1.8   1.93.0-1Gettext for ruby1.8
ii  libhttp-access2-ruby1.8  2.1.5.2-1   HTTP accessing library for ruby (t
ii  libruby1.8 [libzlib-ruby1.8] 1.8.7.174-3 Libraries necessary to run Ruby 1.
ii  libxml-parser-ruby1.80.6.8-4 Interface of expat for the scripti
ii  ruby 4.2 An interpreter of object-oriented 

apt-listbugs recommends no packages.

Versions of packages apt-listbugs suggests:
ii  debianutils  3.2.2   Miscellaneous utilities specific t
ii  iceweasel [www-brows 3.5.6-1 lightweight web browser based on M
ii  konqueror [www-brows 4:4.3.2-1   KDE 4's advanced file manager, web
ii  lynx-cur [www-browse 2.8.8dev.1-1Text-mode WWW Browser with NLS sup
ii  opera [www-browser]  10.10.4742.gcc4.qt3 The Opera Web Browser
ii  reportbug4.9 reports bugs in the Debian distrib

-- no debconf information


signature.asc
Description: Digital signature

Bug#445020: edict & kanjidic: License discrepancy between the Debian package and upstream, upstream's license being non-free

[Florian Ernst]

Hi there,

first of all, many thanks to Noritada-san and Kinoshita-san for
bugreport and analysis.

Just for the record, currently I'm drafting a letter to upstream. I'm
going to ask for a retroactive license change/upgrade to CC by-sa 3.0,
so that this problem can hopefully be resolved for Etch as well.

However, I feel rather uncomfortable at this as I don't trust my ability
to express this correctly, so any help will be greatly appreciated.
Furthermore, spare time is a scarce resource at the moment, so please
don't hold your breath till I cough up something ...

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#447821: xmms-singit: Depends on removed libssl0.9.7

[Florian Ernst]

tags 447821 experimental
thanks

Hello Alban,

thanks for your bugreport.

On Wed, Oct 24, 2007 at 12:42:45AM +0200, Alban Browaeys wrote:
> Package: xmms-singit
> Severity: grave
> Justification: renders package unusable
> 
> The package depends on non available libssl0.9.7. Could it be upgraded 
> to use libssl0.9.8 ?

Well, it could. However, xmms-singit has been removed from
testing/unstable, and personally I'm currently not eager to bring it
back. And the version in experimental most definitely isn't fit for
release, either!
Do you have an old version from the time when it was still in testing /
unstable or rather the version from experimental installed? Your
bugreport doesn't say ...

Either way, as long as nobody picks up this package soon the Debian
support for it will cease to exist. Please see

for some background info.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#445057: forcibly merging 445021 445057

[Florian Ernst]

# Automatically generated email from bts, devscripts version 2.10.8
# gnah, 445021 still hasn't reached my inbox ...
forcemerge 445021 445057




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#445020: edict & kanjidic: License discrepancy between the Debian package and upstream, upstream's license being non-free

[Florian Ernst]

tags 445020 confirmed
clone 445020 -1
reassign -1 kanjidic
thanks

On Wed, Oct 03, 2007 at 03:16:44AM +0900, Kobayashi Noritada wrote:
> >From these facts, I guess that the upstream changed the license from
> the custom one to CC by-sa 2.5 without notice.  It is obvious from
> web.archive.org[2] that the current license was already used in July,
> 2006.

Ack. This change wasn't clearly reflected in the files we wget and put
into the orig.tar.gz for edict and kanjidic.

Dang!

> To solve this situation, I make two proposals:
> 
> * To give the upstream suggestions to upgrade the license to CC by-sa
>   3.0 and to specify that version clearly in the license page.
> 
> * To include licence.html in the Debian source packages for edict and
>   kanjidic.
> 
> Although whether Debian now declare CC by 3.0 and CC by-sa 3.0 to be
> DFSG-free or not was uncertain[3], I hope CC by-sa 3.0 is considered
> to be DFSG-free now that ttf-konatu[4], a Japanese font package
> licensed by CC by-sa 3.0, has got in the Debian main archive.

This seems like the way to go to resolve this for testing/unstable.
However, what about Etch...? Ludovic, what do you think?

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#421490: Causes massive CPU load when enabled

[Florian Ernst]

Hello David,

thanks for your bugreport.

On Sun, Apr 29, 2007 at 06:37:15PM +0200, David wrote:
> Package: xmms-singit
> Version: 0.1.28+dfsg-1
> Severity: grave
> Justification: renders package unusable
> 
> After installing & enabling the xmms-singit package, XMMS starts taking 99% 
> CPU
> [...]
> This makes xmms-singit unusable for me.
> 
> Also, trying to disable the xmms-singit plugin in the XMMS
> configuration window causes XMMS
> to crash. I have to remove the xmms-singit package to get a usable XMMS.

So far I can only partially reproduce the problems you reported: I
noticed a high CPU usage, but the system stays responsive even on my old
P3 550MHz; and simply disabling the plugin works for me.
I'll look further into this, and hopefully I can get the upstream
developer to take a look at this as well.

For the record, there are long standing plans for upstream to take over
maintenance of this package by himself, but those seem to be stalled for
some time and are in dire need for clarification.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#417889: [Pkg-blender-maintainers] Bug#417889: blender: FTBFS on mips and sparc

[Florian Ernst]

Hello Sam,

On Thu, Apr 05, 2007 at 11:21:07AM +0200, Sam Hocevar wrote:
> Package: blender
> Version: 2.42a-6
> Severity: serious
> Tags: patch
> 
>blender fails to build on mips[1] and sparc[2] because the Debian
> build configuration uses -lstdc++ which is never guaranteed to work.
> [...]

Thanks a lot for investigation and patch! A fixed release is being
worked on.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#414721: libhtml-tableextract-perl: FTBFS: Test failures

[Florian Ernst]

Hello Gunnar,

On Tue, Mar 13, 2007 at 11:38:15AM -0600, Gunnar Wolf wrote:
> I'm attaching the patch here - What is it? Basically, I understand
> [...]
> where now it properly quotes them (). The fix is
> basically to change the original string it compares to/from :)

Thanks a lot for doing my work. :)

A new package containing your patch has just been uploaded.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#414832: ktorrent: security vulnerabilities fixed in newer upstream

[Florian Ernst]

Package: ktorrent
Version: 2.0.3+dfsg1-2
Severity: grave
Tags: security
Justification: user security hole

Hello Joel,

long time no see...

I guess some work lies ahead:

| Bryan Burns of Juniper networks found 2 security vulnerabilities in
| KTorrent. These have now been fixed in the 2.1.2 release. 
| 
| This is just 2.1.1 with these 2 fixes. It would be advisable to upgrade.

as seen on .

This concerns
 and
.

Ubuntu Security Notice USN-436-1 has already been issued[0] on this matter.

Even though these vulnerabilities don't affect the current stable
release, they need to be fixed for the upcoming release "Etch".
Please extract the relevant patches and apply them to ktorrent as
currently present in unstable. Changes for non-release-critical issues
are no longer accepted for Etch as per the latest release update[0], so
please stick to just these necessary changes.

Once a fixed package will have been uploaded we need to ask the release
managers to allow propagation to Etch.

Cheers,
Flo


[0] 
[1] 


signature.asc
Description: Digital signature

Bug#414721: libhtml-tableextract-perl: FTBFS: Test failures

[Florian Ernst]

tags 414721 confirmed
thanks

Hello Daniel,

On Tue, Mar 13, 2007 at 03:20:13PM +0100, Daniel Schepler wrote:
> Package: libhtml-tableextract-perl
> Version: 2.10-1
> Severity: serious
> Tags: sid
> [...]
> The package builds fine in an etch chroot.

Thanks for the hint. I can confirm the FTBFS in Sid, but I won't have
the time to further investigate right now. Also, there seems to be a
similar bugreport upstream which needs checking.

I will take care of this on Wednesday.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#411595: xmms-singit_0.1.33-1(hppa/experimental): FTBFS: outdated build-dependency

[Florian Ernst]

Hi Frank,

thanks for your pointer!

On Tue, Feb 20, 2007 at 02:52:23AM +0100, Frank Lichtenheld wrote:
> your package's version in experimental doesn't build anymore because one
> of the build-dependencies got renamed.

Indeed, I used experimental as a true testbed here and didn't put much
work into this version recently.
However, as upstream intends to take over package maintenance himself I
probably won't take any immediate action other than pinging him, so it
might take some time until this gets resolved. JFTR, FWIW ...

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#397560: blender: FTBFS: /usr/bin/ld: cannot find -lsh

[Florian Ernst]

On Wed, Nov 08, 2006 at 09:57:35AM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in etch, I discovered that your package
> failed to build on i386.
> 
> Relevant parts:
> Compiling ==> 'buildinfo.c'
> Linking program ==> 'blender'
> /usr/bin/ld: cannot find -lsh:
> collect2: ld returned 1 exit status

Incidentally, the unstable m68k build which occurred three weeks after
uploading the latest version of blender failed the same way. I'd guess
changes in the build environment in the meantime might have caused
this, but this demands further investigations.

I'll get to this as soon as I can.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#393697: xmms-singit: vixar.ttf is a non-free Microsoft font

[Florian Ernst]

On Tue, Oct 17, 2006 at 02:43:02PM +0200, Sam Hocevar (Debian packages) wrote:
>xmms-singit-0.1.28.orig/src/data/vixar.ttf has the text "Copyright (c)
> 1995 Microsoft Corporation. All rights reserved." in it and must be removed
> from the original tarball.

Yes, indeed. I removed the font from the binary package in a previous
upload but neglected to remove it from the tarball as well. Thanks for
the hint, this bug is just about to be fixed.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#392684: blender and xorg crush when i trying to move a camera around my object

[Florian Ernst]

severity 392684 important
tags 392684 unreproducible
thanks [EMAIL PROTECTED] BCC'd

Dear Antono,

thanks for your bugreport.

On Thu, Oct 12, 2006 at 11:22:48PM +0300, Antono Vasiljev wrote:
> Package: blender
> Version: 2.42a-3
> Severity: critical
> Justification: causes serious data loss
> 
> *** Please type your report below this line ***
> Blender and xorg crushes when i trying to move camera around my object.
> I have no idea which information could be useful for resolving the bug. 

Please understand that while I acknowledge that this particular bug
seems to have severe impact on your system, I cannot reproduce this
behaviour on my system and thus I downgrade this bug's severity.

Please test whether the whole issue isn't rather related to the video
driver you utilize, see /usr/share/doc/blender/README.Debian for a
start. As you didn't provide any of your system's specs (video
hardware, driver used, ...) and the bug's circumstances (happens with
every scene / only certain objects, steps to reproduce the problem) I
cannot say much more at the moment.
When adding any further information please try to cover as much as
possible from "How to Report Bugs Effectively" by Simon Tatham at
.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#378301: fixed in juman 5.1-2

[Florian Ernst]

Hello there,

On Mon, Sep 04, 2006 at 07:32:22AM -0700, TSUCHIYA Masatoshi wrote:
> Date: Fri, 25 Aug 2006 01:20:10 +0900
> Source: juman
> [...]
> Changes: 
>  juman (5.1-2) unstable; urgency=low
>  .
>* Fix. (closes: #378301).

Please take the time to compose meaningful entries as recommended by
the Developer's Reference, see ch. 6.3 at


Especially when it comes to RC bugs, "Fix" is just what to hope for,
but it doesn't explain what exactly is fixed as there were several
errors mentioned in the bugreport.
So, something along
| * Fix FTBFS: Segmentation fault during makepat, thanks to Jérôme
|   Pouiller for investigating and patch (closes: #378301).
would have been a start.

Thanks,
Flo


signature.asc
Description: Digital signature

Bug#365845: FTBFS: requires automake-1.7

[Florian Ernst]

On Sun, May 14, 2006 at 10:00:40AM -0700, Robert Woodcock wrote:
> Note to Florian: those are only "patches" from your perspective. All of
> those files are automatically generated by autoreconf/aclocal/autoconf/
> automake/etc. None of them are written by hand [...]

Please note that "patch" doesn't necessarily has a connotation on how
it was generated, just see the Jargon File entry (sense 3). Your
"lecture" indicates otherwise ...

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#365845: FTBFS: requires automake-1.7

[Florian Ernst]

tags 365845 patch
thanks [EMAIL PROTECTED] BCC'd

Hello Robert, hello Roberto,

On Wed, May 03, 2006 at 12:59:14PM +0200, Roberto Pariset wrote:
> mtr_0.71-1 FTBFS with error:
> [...]
> Which make it quite clear it needs automake-1.7. Please add it as a
> dependency.

Methinks this FTBFS occurs due to unnecessarily applying the 0.70-1
patches to img/Makefile.in, Makefile.in, aclocal.m4 and configure to
0.71 as well. Apparently upstream took care, so those simply aren't
needed anymore.
When dropping these patches as well as the "touch"ing in debian/rules
the package builds just fine (tested on i386, amd64, ia64 and s390).

Please find attached the corresponding interdiff. If I won't hear from
you I'll probably NMU on Monday.

Cheers,
Flo


mtr_interdiff.gz
Description: Binary data


signature.asc
Description: Digital signature

Bug#353431: xmltv-gui: 8392508 is not a hash at /usr/lib/perl5/Tk/Widget.pm line 190

[Florian Ernst]

On Tue, Feb 28, 2006 at 04:40:57PM +0100, Florian Ernst wrote:
> However, /usr/lib/perl5/Tk/Widget.pm is part of the perl-tk package,
> and downgrading this package to 800.025-2 as present until 2006-01-14

D'uh, of course I need to recompile libtk-tablematrix-perl against the
new perl-tk.

Sorry for the noise. Does it show that I RFA'd this package...?

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#353431: xmltv-gui: 8392508 is not a hash at /usr/lib/perl5/Tk/Widget.pm line 190

[Florian Ernst]

On Tue, Feb 28, 2006 at 01:57:22PM +, Chris Butler wrote:
> On Sat, Feb 18, 2006 at 11:13:04AM +0100, Nicolas Raspail wrote:
> > 8392508 is not a hash at /usr/lib/perl5/Tk/Widget.pm line 190.
> > [...]
> 
> This is not a bug in xmltv. It seems to be happening for any program
> that uses the Tk::TableMatrix object, even the examples that come with
> libtk-tablematrix-perl.

Yes, indeed.

However, /usr/lib/perl5/Tk/Widget.pm is part of the perl-tk package,
and downgrading this package to 800.025-2 as present until 2006-01-14
at least allows running all the demo programs shipped with
libtk-tablematrix-perl source again, so perl-tk might be the real
culprit.

Michael, do you perhaps know anything about this?

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#344566: sysutils: /usr/bin/memtest also found in package memtester

[Florian Ernst]

tags 344566 pending 
thanks [EMAIL PROTECTED] BCC'd 
 
Yes, I know about this conflict, please see bug#339481. 
 
Unfortunately I noticed this reduplication of effort rather late, 
and furthermore right now I have locked myself out from my 
working machine (again) being away from home over the holidays, 
so I can't help but vaguely saying "this will be resolved pretty 
soon". 
 
Cheers, 
Flo - using a stupid webmail account 

-- 
GMX DSL-Flatrate 1 Jahr kostenlos* + WLAN-Router ab 0,- Euro*
Bis 31.12.2005 einsteigen! Infos unter: http://www.gmx.net/de/go/dsl


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#344398: CVE-2005-4470: Integer overhead in header parser for .blend import

[Florian Ernst]

# I consider upstream's fix to be sufficient, so:
tags 344398 patch
thanks [EMAIL PROTECTED] BCC'd

On Thu, Dec 22, 2005 at 02:30:46PM +0100, Moritz Muehlenhoff wrote:
> An integer overflow in the header parser for .blend files can potentially
> be exploited to execute code through a heap overflow. Please see 
> http://www.overflow.pl/adv/blenderinteger.txt for details.
> 
> This is CVE-2005-4470.

Moritz, thanks a lot for the pointer!


On Thu, Dec 22, 2005 at 01:37:29PM +, Steve Kemp wrote:
>   Woody is non-free so most likely won't get updated.

Agreed, especially since there isn't a real source tarball (the
orig.tar.gz includes the binary for i386 and some additional files).

>   Sarge is vulnerable.

Confirmed.

Steve, btw, any news on CVE-2005-3302 aka bug#330895 (arbitrary code
execution when importing a .bvh file)? Last I heard you were going to
prepare an update unless anybody had an issue with the changes made,
yet I haven't heard of any such issues (or anything at all, to be
precise) since then...


On Thu, Dec 22, 2005 at 02:45:45PM +0100, Wouter van Heyst wrote:
> There was some uncertainty on how to actually exploit that. That also
> leads me to not being sure
> http://projects.blender.org/viewcvs/viewcvs.cgi/blender/source/blender/blenloader/intern/readfile.c.diff?r1=1.219&r2=1.220&cvsroot=bf-blender
> is enough of a fix, is it? 

Wouter, thanks for your initiative!

FWIW, I've put together an update for Sarge's version of the blender
package based on the upstream change mentioned above, please find
attached a cumulative interdiff for both CVE-2005-3302 aka bug#330895
and this bug so these issues can be resolved for Sarge.
Please tell whether you deem those patches sufficient for a potential
future security advisory, and if not, please provide pointers at what
might be missing.

I'll be afk for the weekend, but I'll come back to this issue on
Monday.

Cheers,
Flo
diff -u blender-2.36/debian/patches/00list blender-2.36/debian/patches/00list
--- blender-2.36/debian/patches/00list
+++ blender-2.36/debian/patches/00list
@@ -2,0 +3,2 @@
+03_fix_arbitrary_code_execution_in_bvh_import.py
+04_fix_integer_overflow_in_readfile.c
diff -u blender-2.36/debian/changelog blender-2.36/debian/changelog
--- blender-2.36/debian/changelog
+++ blender-2.36/debian/changelog
@@ -1,3 +1,19 @@
+blender (2.36-1sarge1) stable-security; urgency=high
+
+  * patch release/scripts/bvh_import.py to use float instead of eval by
+adding 03_fix_arbitrary_code_execution_in_bvh_import.py.dpatch,
+thus preventing arbitrary code execution when importing a .bvh file;
+this fix differs from the changes in
+
<http://projects.blender.org/viewcvs/viewcvs.cgi/blender/release/scripts/bvh_import.py.diff?r1=1.4&r2=1.5&cvsroot=bf-blender>
+in that it doesn't provide the new checks introduced therein;
+for reference, this is CVE-2005-3302 - closes: #330895
+  * patch source/blender/blenloader/intern/readfile.c to fix BlenLoader
+Integer Overflow by adding 04_fix_integer_overflow_in_readfile.c.dpatch,
+thus preventing potential code execution via a heap overflow;
+for reference, this is CVE-2005-4470 - closes: #344398
+
+ -- Florian Ernst <[EMAIL PROTECTED]>  Thu, 22 Dec 2005 23:23:45 +0100
+
 blender (2.36-1) unstable; urgency=high
 
   * The "Back From The Gig" release.
only in patch2:
unchanged:
--- 
blender-2.36.orig/debian/patches/04_fix_integer_overflow_in_readfile.c.dpatch
+++ blender-2.36/debian/patches/04_fix_integer_overflow_in_readfile.c.dpatch
@@ -0,0 +1,28 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 04_fix_integer_overflow_in_readfile.c.dpatch by Florian Ernst <[EMAIL 
PROTECTED]>
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: Fix for CVE-2005-4470, see bug#344398.
+
[EMAIL PROTECTED]@
+diff -urNad blender-2.36~/source/blender/blenloader/intern/readfile.c 
blender-2.36/source/blender/blenloader/intern/readfile.c
+--- blender-2.36~/source/blender/blenloader/intern/readfile.c  2004-12-10 
15:50:39.0 +0100
 blender-2.36/source/blender/blenloader/intern/readfile.c   2005-12-22 
23:29:13.0 +0100
+@@ -601,6 +601,9 @@
+   }
+   }
+ 
++  /* make sure people are not trying to pass bad blend 
files */
++  if (bhead.len < 0) fd->eof = 1;
++
+   // bhead now contains the (converted) bhead structure. 
Now read
+   // the associated data and put everything in a BHeadN 
(creative naming !)
+ 
+@@ -615,6 +618,7 @@
+   if (readsize != bhead.len) {
+   fd->eof = 1;
+   MEM_freeN(new_bhead);
++  new_bhead = 0;
+

Bug#339211: [EMAIL PROTECTED]: libmusicbrainz-2.1_2.1.2-1_i386.changes is NEW]

[Florian Ernst]

Forwarding this message to the three bugs that are related...

- Forwarded message from Debian Installer <[EMAIL PROTECTED]> -

From: Debian Installer <[EMAIL PROTECTED]>
Subject: libmusicbrainz-2.1_2.1.2-1_i386.changes is NEW
To: Florian Ernst <[EMAIL PROTECTED]>
Date: Thu, 22 Dec 2005 10:02:09 -0800
Message-Id: <[EMAIL PROTECTED]>

libmusicbrainz-2.1_2.1.2-1.diff.gz
  to pool/main/libm/libmusicbrainz-2.1/libmusicbrainz-2.1_2.1.2-1.diff.gz
libmusicbrainz-2.1_2.1.2-1.dsc
  to pool/main/libm/libmusicbrainz-2.1/libmusicbrainz-2.1_2.1.2-1.dsc
libmusicbrainz-2.1_2.1.2.orig.tar.gz
  to pool/main/libm/libmusicbrainz-2.1/libmusicbrainz-2.1_2.1.2.orig.tar.gz
libmusicbrainz4-dev_2.1.2-1_i386.deb
  to pool/main/libm/libmusicbrainz-2.1/libmusicbrainz4-dev_2.1.2-1_i386.deb
libmusicbrainz4c2a_2.1.2-1_i386.deb
  to pool/main/libm/libmusicbrainz-2.1/libmusicbrainz4c2a_2.1.2-1_i386.deb
python-musicbrainz_2.1.2-1_all.deb
  to pool/main/libm/libmusicbrainz-2.1/python-musicbrainz_2.1.2-1_all.deb
python2.3-musicbrainz_2.1.2-1_all.deb
  to pool/main/libm/libmusicbrainz-2.1/python2.3-musicbrainz_2.1.2-1_all.deb
(new) python2.4-musicbrainz_2.1.2-1_all.deb optional python
Second generation incarnation of the CD Index - python2.4 bindings
 MusicBrainz indexes both digital compressed audio (MP3/Vorbis) and
 digital audio CDs.
 .
 This is a straight python to c binding for libmusicbrainz.  It uses ctypes
 to avoid having to write c code.
 .
  Homepage: http://musicbrainz.org/
Changes: libmusicbrainz-2.1 (2.1.2-1) experimental; urgency=low
 .
  * Uploaded to experimental so it won't disturb ongoing transitions
  * New upstream release (Closes: #341654)
+ incorporates 02-gcc4.patch and 01-nonblock.patch
+ includes python bindings again, thus adding corresponding packages;
  the old bindings provided by libmusicbrainz-2.0 will soon be dropped
  * New maintainer (Closes: #328958)
+ miscellaneous packaging adjustments to personal style
Announcing to debian-devel-changes@lists.debian.org
Setting bugs to severity fixed: 328958 341654 


Your package contains new components which requires manual editing of
the override file.  It is ok otherwise, so please be patient.  New
packages are usually added to the override file about once a week.

You may have gotten the distribution wrong.  You'll get warnings above
if files already exist in other distributions.


- End forwarded message -


signature.asc
Description: Digital signature

Bug#333958: Future of blender maintenance (was: Patch for #333958, Intent to NMU)

[Florian Ernst]

Hello again,

thanks for your speedy reply.

On Tue, Dec 13, 2005 at 01:58:26PM +0900, Masayuki Hatta wrote:
> I'm still toying Blender sometimes, so I would like to be involved
> with the maintenance of blender package in some way.  You guys may add
> your name to Uploaders: right now -- and I think you are right, we
> should move to the team-maintenance via alioth ASAP.  I applied to
> alioth for a project called "pkg-blender", so let's use it when it's
> ready.

Wonderful, let's rock!

I guess we won't need to check in the full sources, but probably the
debian/ dir will suffice, as long as we use dpatch and separately
apply the patch for #22 / #333958... Every once in a while alioth
is pretty clogged, so I'd like to keep things small...

Wouter, I see you already have an account larstiq-guest, right?

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#333958: Future of blender maintenance (was: Patch for #333958, Intent to NMU)

[Florian Ernst]

Hello folks,

now coming back to this issue as my NMU of blender has finally migrated
to Testing / Etch.

On Thu, Nov 10, 2005 at 06:50:59PM +0100, Wouter van Heyst wrote:
> On Wed, Nov 09, 2005 at 06:47:33PM +0100, Florian Ernst wrote:
> > On Wed, Nov 09, 2005 at 05:05:17PM +0100, Wouter van Heyst wrote:
> > > In the past Masayuki has mentioned lack of time, if that is still the
> > > case, I'm willing to take over (or become part of a team), as I'm now
> > > much more able to do so. I'm still not a DD yet though.
> > 
> > FWIW, as I'm quite interested in this program, I'd happily join a
> > team, provided Hatta-san's time indeed is too limited and he'll hand
> > over the package.
> > Wouter, I see you previously have already prepared 2.26-1 as well as
> > directly contributed to Blender development, so I'm afraid you
> > wouldn't leave any work for me ;). Well, at least the DD part is what
> > I could still do...
> 
> Don't be too sure of that ;) You've been handling bugs when I wasn't,
> I'd be quite happy to work together with you on blender, if Hatta-san
> so agrees.

Masayuki, please don't take this as a personal insult:

Even though you seem to be continously working on most of the packages
you (co-)maintain as well as sponsoring people there are apparently
some packages that are ranked at a lower priority, accumulating RC
bugs, patches and / or NMUs over time and slowly bitrotting.
Both Wouter and me would like to work on the blender packaging for
Debian, possibly in team-maintenance via alioth. So, we can offer to
lighten your load by taking over maintainership or, at least, by
acting as co-maintainers and directly working on the package.

Please tell us what you think.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#339211: Bug#328958: RFA: libmusicbrainz-2.1: Second generation incarnation of the CD Index -- optional

[Florian Ernst]

Hello Joe,

On Sat, Dec 10, 2005 at 10:59:30PM -0600, Joe Wreschnig wrote:
> On Thu, 1 Dec 2005 20:25:15 +0100, Florian Ernst wrote:
> > With respect to this new situation I'd prefer to omit the python
> > bindings completely, despite the pending removal of the bindings as
> > shipped with libmusicbrainz-2.0. Any thoughts?
> 
> Couldn't you email upstream and ask for clarification, rather than just
> removing them? The Python bindings are very useful, and even recently
> attracted attention on Planet Debian.

Thanks for your input and the valuable pointer. Indeed, I tried to
contact upstream about this, but so far only received response that
omitting the python bindings from the release tarball wasn't
intentional. However, the copyright / licensing issue still needs to
be resolved...

Well, it seems that my usual understanding of RFA as "the maintainer
still wants to get involved" doesn't hold true in this case, so I'll
now start not to wait for input from Andreas anymore.
Please expect an update soonish...

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#339211: Bug#328958: RFA: libmusicbrainz-2.1: Second generation incarnation of the CD Index -- optional

[Florian Ernst]

[ Sent to the RFA for libmusicbrainz-2.1 and the RC bug of
libmusicbrainz-2.0, as this relates to both ]

On Thu, Nov 24, 2005 at 12:05:53PM +0100, Florian Ernst wrote:
> On Sun, 18 Sep 2005 14:02:42 +0200, Andreas Rottmann wrote:
> > I'd like someone adopt libmusicbrainz; [...]
> > from my side. Maintainance of libmusicbrainz package is not very 
> > time-consuming, you 
> > should be familiar with C++ though.
> 
> [...]
> I'm just wondering as I might be interested...

FWIW, I packaged the most recent upstream version, following my
personal style, i.e. omitting cdbs. Files are at
<http://people.debian.org/~florian/libmusicbrainz-2.1/>.

Unfortunately there were some problems with the python bindings:
contrary to what the upstream changelog suggests they were not
included in the tarball, but those bindings currently only exist in
CVS. However, they don't give any hint on what their copyright and
redistribution terms might be; in previous releases there was at least
a COPYING file in the python directory, even if no further reference
was given inside the individual files, but now this one is missing,
too. Thus I'm a bit hesitant to just copy them over...

With respect to this new situation I'd prefer to omit the python
bindings completely, despite the pending removal of the bindings as
shipped with libmusicbrainz-2.0. Any thoughts?

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#339211: Intent to NMU on 11/30

[Florian Ernst]

On Wed, 30 Nov 2005 16:58:05 +0100, Andreas Rottmann wrote:
> I agree. I've CC'ed the Maintainers of the remaining reverse depends of 
> libmusicbrainz2, to get feedback. Hopefully the two packages (dcd, 
> libtunepimp) can be rebuilt against libmusicbrainz 2.1.

They can, and they were:
for dcd see <[EMAIL PROTECTED]>, and libtunepimp
is a FP as an outdated version from the experimental distribution was
once compiled against libmusicbrainz-2.0, but the version from
unstable builds against libmusicbrainz-2.1 for almost four months now.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#339211: Intent to NMU on 11/30

[Florian Ernst]

On Wed, Nov 30, 2005 at 05:37:52AM -0800, Steve Langasek wrote:
> It's my opinion that libmusicbrainz-2.0 is unreleasable whether or not you
> do this NMU, because it's an obsolete version of the lib that should be
> removed.  So I would definitely recommend that you focus on making python
> bindings available for -2.1, rather than spending time NMUing -2.0.

OK, will do.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#326354: Intent to NMU on 11/30

[Florian Ernst]

On Tue, Nov 29, 2005 at 12:39:42PM -0700, Lukas Geyer wrote:
> On Mon, Nov 28, 2005 at 06:20:08PM +0100, Florian Ernst wrote:
> > given that this bug is RC for two weeks now while a trivial fix is
> > available I intent to NMU on Wednesday, the 30th, using the attached
> > patch and uploading to DELAYED/7-day.
> 
> sorry for not getting to this earlier. The patch is indeed trivial,
> please go ahead and NMU. If for some reason you prefer that I upload
> it, I'll do it.

Good to see you back :)

Please upload yourself. After all, you are the maintainer...

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#339211: Intent to NMU on 11/30

[Florian Ernst]

On Tue, Nov 29, 2005 at 12:28:50AM -0800, Steve Langasek wrote:
> Is there any reason to not simply drop libmusicbrainz-2.0, in favor of the
> libmusicbrainz-2.1 package that *everything* else in the archive is using?

Except for the (broken) dcd package, which still Build-Depends on
libmusicbrainz2-dev. However, I already tried building this package
with libmusicbrainz4-dev and all seemed to run fine, so this probably
isn't an issue at all.

> There currently seem to not be any python bindings for -2.1, but surely we
> should just get updated bindings instead of keeping -2.0 around.  (And in
> the process, hopefully dropping python2.1/python2.2 in favor of
> python2.4...)

In fact, this lack of python bindings was the reason for me to favor
keeping libmusicbrainz-2.0 for now.
On the other hand, upstream reintroduced those binding in their latest
release (not yet packaged), so it looks like libmusicbrainz-2.0 won't
be needed anymore at all in short time, and when packaging this new
release surely older python version support should be dropped in favor
of python2.4. Thus, dropping libmusicbrainz-2.0 would only hurt some
users and only for short while.

Still, right now I intended to stick to a minimal set of changes for
an NMU, especially as long as I haven't recieved any feedback from the
maintainer regarding the pending adoption...

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#339212: libmusicbrainz2.1 NMU imminent (allocator transition)

[Florian Ernst]

On Mon, 28 Nov 2005 08:52:55 -0500, Christopher Martin wrote:
> I will be NMUing this package very shortly, applying the patch from Matthias 
> Klose, for the allocator transition.

Well, I'm not Andreas, but only the person who just recently started
considering to take over maintenance of libmusicbrainz.
Still, I'd ask you to please go ahead, as I was going to NMU myself on
Wednesday, the 30th, using Matthias' patch. As we don't want to delay
the transition, the bug is RC for 11 days and a simple fix is available
without maintainer reaction so far, I'd guess a 0-day NMU will be
acceptable...

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#339211: Intent to NMU on 11/30

[Florian Ernst]

Dear maintainer,

as this bug is RC for 11 days now and a simple patch for fixing it is
available I intent to NMU this package on Wednesday, the 30th,
uploading to DELAYED/7-day.
If I don't hear any feedback from you wrt bug#328958 (RFA for
libmusicbrainz) I'll use the attached patch, otherwise I'll probably
go for Matthias' patch.

Cheers,
Flo
diff -u libmusicbrainz-2.0-2.0.2/debian/control 
libmusicbrainz-2.0-2.0.2/debian/control
--- libmusicbrainz-2.0-2.0.2/debian/control
+++ libmusicbrainz-2.0-2.0.2/debian/control
@@ -8,7 +8,7 @@
 Package: libmusicbrainz2-dev
 Architecture: any
 Section: libdevel
-Depends: libmusicbrainz2c2 (= ${Source-Version}), libc6-dev
+Depends: libmusicbrainz2c2a (= ${Source-Version}), libc6-dev
 Provides: libmusicbrainz-dev
 Conflicts: libmusicbrainz-dev
 Description: Second generation incarnation of the CD Index - development
@@ -17,12 +17,12 @@
  .
  This package contains the development files (headers, static library).
 
-Package: libmusicbrainz2c2
+Package: libmusicbrainz2c2a
 Architecture: any
 Section: libs
 Depends: ${shlibs:Depends}
-Conflicts: libmusicbrainz1, libmusicbrainz2
-Replaces: libmusicbrainz2
+Conflicts: libmusicbrainz1, libmusicbrainz2, libmusicbrainz2c2
+Replaces: libmusicbrainz2, libmusicbrainz2c2
 Description: Second generation incarnation of the CD Index - library
  MusicBrainz indexes both digital compressed audio (MP3/Vorbis) and 
  digital audio CDs.
diff -u libmusicbrainz-2.0-2.0.2/debian/changelog 
libmusicbrainz-2.0-2.0.2/debian/changelog
--- libmusicbrainz-2.0-2.0.2/debian/changelog
+++ libmusicbrainz-2.0-2.0.2/debian/changelog
@@ -1,3 +1,11 @@
+libmusicbrainz-2.0 (2.0.2-12.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Rename libmusicbrainz2c2 to libmusicbrainz2c2a (libstdc++ allocator
+change, closes: #339211).
+
+ -- Florian Ernst <[EMAIL PROTECTED]>  Mon, 28 Nov 2005 18:46:55 +0100
+
 libmusicbrainz-2.0 (2.0.2-12) unstable; urgency=low
 
   * libmusicbrainz2c2: Add conflicts, replaces on libmusicbrainz2 (closes:
diff -u libmusicbrainz-2.0-2.0.2/debian/rules 
libmusicbrainz-2.0-2.0.2/debian/rules
--- libmusicbrainz-2.0-2.0.2/debian/rules
+++ libmusicbrainz-2.0-2.0.2/debian/rules
@@ -20,6 +20,6 @@
-$(patsubst %,binary/%,$(DEB_PYTHON_REAL_PACKAGES)):: binary/libmusicbrainz2
+$(patsubst %,binary/%,$(DEB_PYTHON_REAL_PACKAGES)):: binary/libmusicbrainz2c2a
 
-DEB_SHLIBDEPS_INCLUDE := debian/libmusicbrainz2/usr/lib/
-DEB_SHLIBDEPS_LIBRARY_python2.1-musicbrainz := libmusicbrainz2
-DEB_SHLIBDEPS_LIBRARY_python2.2-musicbrainz := libmusicbrainz2
-DEB_SHLIBDEPS_LIBRARY_python2.3-musicbrainz := libmusicbrainz2
+DEB_SHLIBDEPS_INCLUDE := debian/libmusicbrainz2c2a/usr/lib/
+DEB_SHLIBDEPS_LIBRARY_python2.1-musicbrainz := libmusicbrainz2c2a
+DEB_SHLIBDEPS_LIBRARY_python2.2-musicbrainz := libmusicbrainz2c2a
+DEB_SHLIBDEPS_LIBRARY_python2.3-musicbrainz := libmusicbrainz2c2a
reverted:
--- libmusicbrainz-2.0-2.0.2/debian/libmusicbrainz2c2.install
+++ libmusicbrainz-2.0-2.0.2.orig/debian/libmusicbrainz2c2.install
@@ -1 +0,0 @@
-debian/tmp/usr/lib/*.so.*
only in patch2:
unchanged:
--- libmusicbrainz-2.0-2.0.2.orig/debian/libmusicbrainz2c2a.install
+++ libmusicbrainz-2.0-2.0.2/debian/libmusicbrainz2c2a.install
@@ -0,0 +1 @@
+debian/tmp/usr/lib/*.so.*


signature.asc
Description: Digital signature

Bug#326354: Intent to NMU on 11/30

[Florian Ernst]

Dear maintainer,

given that this bug is RC for two weeks now while a trivial fix is
available I intent to NMU on Wednesday, the 30th, using the attached
patch and uploading to DELAYED/7-day.

Cheers,
Flo
diff -u gnuchess-5.07/debian/changelog gnuchess-5.07/debian/changelog
--- gnuchess-5.07/debian/changelog
+++ gnuchess-5.07/debian/changelog
@@ -1,3 +1,12 @@
+gnuchess (5.07-3.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/control: Build-Depends change from "libreadline4-dev" to
+"libreadline5-dev | libreadline-dev" as proposed my Matthias Klose
+to resolve FTBFS and Broken Depends. (closes: #326354)
+
+ -- Florian Ernst <[EMAIL PROTECTED]>  Mon, 28 Nov 2005 18:18:48 +0100
+
 gnuchess (5.07-3) unstable; urgency=low
 
   * Removed superfluous declaration of input_thread in src/common.h.
diff -u gnuchess-5.07/debian/control gnuchess-5.07/debian/control
--- gnuchess-5.07/debian/control
+++ gnuchess-5.07/debian/control
@@ -1,7 +1,7 @@
 Source: gnuchess
 Section: games
 Priority: optional
-Build-Depends: debhelper (>> 4.0.0), libreadline4-dev, libncurses5-dev, flex, 
autotools-dev
+Build-Depends: debhelper (>> 4.0.0), libreadline5-dev | libreadline-dev, 
libncurses5-dev, flex, autotools-dev
 Maintainer: Lukas Geyer <[EMAIL PROTECTED]>
 Standards-Version: 3.6.1
 


signature.asc
Description: Digital signature

Bug#326354: please rebuild with libreadline5-dev as build dependency

[Florian Ernst]

On Fri, 2 Sep 2005 22:40:52 +0200, Matthias Klose wrote:
> The package depends/recommends libreadline4. This version
> will be removed from the archive in the near future.
> Please change your build dependencies to
> 
>  libreadline5-dev | libreadline-dev
> 
> Please raise the severity of this bug report to serious,
> if the package cannot be built with libreadline5-dev.

I can confirm the package builds fine in an up-to-date pbuilder chroot
after changing the Build-Depends as indicated above, and it also seems
to run just fine. As the new xboard maintainer I'd love to see gnuchess
RC-bug-free, so please update the package accordingly.
(FWIW, a simple rebuild will also let the package actually do the menu
transition...)

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#323527: FTBFS: Invalid conversions and undeclared function

[Florian Ernst]

retitle 323527 uses internal copy of openal
# severity could possibly be lowered even further
severity 323527 important
tags 323527 - patch
found 323527 2.37a-1
notfound 323527 2.36-1
thanks [EMAIL PROTECTED] BCC'd

On Tue, 16 Aug 2005 17:06:45 -0700, Matt Kraai wrote:
> Package: blender
> Version: 2.36-1
> Severity: serious
> Tags: patch
> 
> blender fails to build because there are some invalid conversions and
> a call of an undeclared function:
> [...]
> > intern/SoundSystem/openal/SND_OpenALDevice.cpp: In member function 'virtual 
> > SND_WaveSlot* SND_OpenALDevice::LoadSample(const STR_String&, void*, int)':
> > intern/SoundSystem/openal/SND_OpenALDevice.cpp:426: error: invalid 
> > conversion from 'signed char*' to 'ALbyte*'
> > intern/SoundSystem/openal/SND_OpenALDevice.cpp:426: error:   initializing 
> > argument 1 of 'void alutLoadWAVMemory(ALbyte*, ALenum*, ALvoid**, ALsizei*, 
> > ALsizei*, ALboolean*)'
> > intern/SoundSystem/openal/SND_OpenALDevice.cpp:441: error: 'alutLoadWAV' 
> > was not declared in this scope
> [...]
> The attached patch, extracted from upstream, fixes these problems by
> fixing the conversions and using alutLoadWAVFile instead of
> alutLoadWAV.

Starting with 2.37a blender uses an internal copy of openal, so this
FTBFS doesn't show anymore in a current Sid environment. As blender
has been removed from Testing due to general bugginess, and safely
assuming 2.36 as present in Sarge still builds fine, this bug could
simply be closed.

However, using an internal copy of a library when a Debian package is
available can be considered a bug of its own, so for now I prefer just
changing this bug a tiny little bit and leave it to the maintainer how
to best deal with this once he comes back actually maintaining this
package.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#333958: Patch for #333958, Intent to NMU

[Florian Ernst]

On Wed, Nov 09, 2005 at 05:05:17PM +0100, Wouter van Heyst wrote:
> In the past Masayuki has mentioned lack of time, if that is still the
> case, I'm willing to take over (or become part of a team), as I'm now
> much more able to do so. I'm still not a DD yet though.

FWIW, as I'm quite interested in this program, I'd happily join a
team, provided Hatta-san's time indeed is too limited and he'll hand
over the package.
Wouter, I see you previously have already prepared 2.26-1 as well as
directly contributed to Blender development, so I'm afraid you
wouldn't leave any work for me ;). Well, at least the DD part is what
I could still do...

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#297251: New upstream release packaged

[Florian Ernst]

tags 286191 patch
tags 271476 patch
tags 238678 patch
tags 201563 patch
tags 190258 patch
tags 297251 patch
thanks [EMAIL PROTECTED] BCC'd

Hello *,

FWIW, I've packaged the most recent upstream version. Please note that
those packages greatly differ from previous versions, most notacibly
only one binary package is built and the exotic / suid stuff left out,
and I'm generally unsure whether my patches are correct.

Still, lacking a better version, I dare to tag all appropriate
bugreports "patch" (again) as my version fixes them and the maintainer
appears to be MIA.

Get it from here (arm / amd64 / m68k missing):


Only the i386 version was tested and found to be running fine, all
packages built from the same source...
Please use them at your own risk.

HTH,
Flo


signature.asc
Description: Digital signature

Bug#337794: libhtml-fromtext-perl: FTBFS: Failing tests

[Florian Ernst]

tags 337794 pending
thanks [EMAIL PROTECTED] BCC'd

On Sun, Nov 06, 2005 at 04:09:48PM +0100, Roland Stigge wrote:
> building the package libhtml-fromtext-perl in a clean sid build environment
> (with pbuilder) on i386 results in: [...]

OK, this bug was triggered by the latest libhtml-parser-perl update as
this module now encodes "'" by default.
Hehe, adding insult to injury, it was me who filed the corresponding
wishlist bug for packaging this new upstream release, so I should have
known this will happen... :)

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#337794: libhtml-fromtext-perl: FTBFS: Failing tests

[Florian Ernst]

tags 337794 confirmed
thanks [EMAIL PROTECTED] BCC'd

On Sun, Nov 06, 2005 at 04:09:48PM +0100, Roland Stigge wrote:
> building the package libhtml-fromtext-perl in a clean sid build environment
> (with pbuilder) on i386 results in: [...]

Reproducable here, thanks for the pointer. Hmm, strange, must have
been triggered by some other package's update, I'll investigate
this...
Problem seems to be that single quotes aren't escaped anymore.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#330895: blender: Arbitrary code execution when importing a .bvh file

[Florian Ernst]

tags 330895 patch
thanks [EMAIL PROTECTED] BCCed

On Fri, 30 Sep 2005 12:51:35 +0200, Joxean Koret wrote:
> The bvh_import.py script supplied with the current Debian Stable and (I
> think) unstable versions of Blender is vulnerable to arbitrary code
> execution.

This time the patch is dpatch'yfied, and I'll also attach a patch that
is closer to upstream, but includes more changes to the code.

HTH,
Flo
diff -u blender-2.36/debian/patches/00list blender-2.36/debian/patches/00list
--- blender-2.36/debian/patches/00list
+++ blender-2.36/debian/patches/00list
@@ -2,0 +3 @@
+03_fix_arbitrary_code_execution_in_bvh_import.py
diff -u blender-2.36/debian/changelog blender-2.36/debian/changelog
--- blender-2.36/debian/changelog
+++ blender-2.36/debian/changelog
@@ -1,3 +1,15 @@
+blender (2.36-1sarge1) unstable; urgency=high
+
+  * patch release/scripts/bvh_import.py to use float instead of eval by
+adding 03_fix_arbitrary_code_execution_in_bvh_import.py.dpatch,
+thus preventing arbitrary code execution when importing a .bvh file;
+this fix differs from the changes in
+
<http://projects.blender.org/viewcvs/viewcvs.cgi/blender/release/scripts/bvh_import.py.diff?r1=1.4&r2=1.5&cvsroot=bf-blender>
+in that it doesn't provide the new checks introduced therein;
+for reference, this is CVE-2005-3302 - closes: #330895
+
+ -- Florian Ernst <[EMAIL PROTECTED]>  Wed,  2 Nov 2005 13:45:57 +0100
+
 blender (2.36-1) unstable; urgency=high
 
   * The "Back From The Gig" release.
only in patch2:
unchanged:
--- 
blender-2.36.orig/debian/patches/03_fix_arbitrary_code_execution_in_bvh_import.py.dpatch
+++ 
blender-2.36/debian/patches/03_fix_arbitrary_code_execution_in_bvh_import.py.dpatch
@@ -0,0 +1,47 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 03_fix_arbitrary_code_execution_in_bvh_import.py.dpatch by Florian Ernst 
<[EMAIL PROTECTED]>
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: Fix for CVE-2005-3302, see bug#330895
+
[EMAIL PROTECTED]@
+diff -urNad blender-2.36~/release/scripts/bvh_import.py 
blender-2.36/release/scripts/bvh_import.py
+--- blender-2.36~/release/scripts/bvh_import.py2004-11-07 
17:31:13.0 +0100
 blender-2.36/release/scripts/bvh_import.py 2005-11-02 13:36:01.0 
+0100
+@@ -331,7 +331,7 @@
+   
+   name = lines[lineIdx][1]
+   lineIdx += 2 # Incriment to the next line (Offset)
+-  offset = ( eval(lines[lineIdx][1]), eval(lines[lineIdx][2]), 
eval(lines[lineIdx][3]) )
++  offset = ( float(lines[lineIdx][1]), float(lines[lineIdx][2]), 
float(lines[lineIdx][3]) )
+   lineIdx += 1 # Incriment to the next line (Channels)
+   
+   # newChannel[Xposition, Yposition, Zposition, Xrotation, Yrotation, 
Zrotation]
+@@ -367,7 +367,7 @@
+ # Account for an end node
+ if lines[lineIdx][0] == 'End' and lines[lineIdx][1] == 'Site': # There is 
somtimes a name afetr 'End Site' but we will ignore it.
+   lineIdx += 2 # Incriment to the next line (Offset)
+-  offset = ( eval(lines[lineIdx][1]), eval(lines[lineIdx][2]), 
eval(lines[lineIdx][3]) )
++  offset = ( float(lines[lineIdx][1]), float(lines[lineIdx][2]), 
float(lines[lineIdx][3]) )
+   makeEnd(parent, prefix, offset)
+ 
+   # Just so we can remove the Parents in a uniform way- End end never has 
kids
+@@ -431,14 +431,14 @@
+ if debug: Blender.Redraw() 
+ while obIdx < len(objectList) -1:
+   if channelList[obIdx][0] != -1:
+-
objectList[obIdx].getIpo().getCurve('LocX').addBezier((currentFrame, scale * 
eval(lines[lineIdx][channelList[obIdx][0]])))
++
objectList[obIdx].getIpo().getCurve('LocX').addBezier((currentFrame, scale * 
float(lines[lineIdx][channelList[obIdx][0]])))
+   if channelList[obIdx][1] != -1:
+-
objectList[obIdx].getIpo().getCurve('LocY').addBezier((currentFrame, scale * 
eval(lines[lineIdx][channelList[obIdx][1]])))
++
objectList[obIdx].getIpo().getCurve('LocY').addBezier((currentFrame, scale * 
float(lines[lineIdx][channelList[obIdx][1]])))
+   if channelList[obIdx][2] != -1:
+-
objectList[obIdx].getIpo().getCurve('LocZ').addBezier((currentFrame, scale * 
eval(lines[lineIdx][channelList[obIdx][2]])))
++
objectList[obIdx].getIpo().getCurve('LocZ').addBezier((currentFrame, scale * 
float(lines[lineIdx][channelList[obIdx][2]])))
+   
+   if channelList[obIdx][3] != '-1' or channelList[obIdx][4] != '-1' 
or channelList[obIdx][5] != '-1':
+-x, y, z = 
eulerRotate(eval(lines[lineIdx][channelList[obIdx][3]]), 
eval(lines[lineIdx][channelList[obIdx][4]]), 
eval(lines[lineIdx][channelList[obIdx][5]]))
++x, y, z = 
eulerRotate(float(lines[lineIdx][channelList[obId

Bug#308587: Dealing with #308587 using BTS version tracking

[Florian Ernst]

# found in Woody, fixed in DSA-743-1 available from security.d.o
found 308587 0.5.0-1
close 308587 0.5.0-1woody4
# found in Sarge, fixed in DSA-743-1 available from security.d.o
found 308587 0.8.0-1
close 308587 0.8.0-2sarge4
# found in Sid, fixed by uploading 0.8.0-3, including Joey's patch
close 308587 0.8.0-3
thanks [EMAIL PROTECTED] BCCed

As the original bugreport didn't have any version tracking information
included I add the respective versions at the time of reporting.
However, this bug has been dealt with for all releases of Debian, so
it can effectively be closed for certain versions. BTS version tracking
will allow to track any further progress for all distributions
separately.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#330895: blender: Arbitrary code execution when importing a .bvh file

[Florian Ernst]

On Fri, 30 Sep 2005 12:51:35 +0200, Joxean Koret wrote:
> The bvh_import.py script supplied with the current Debian Stable and (I
> think) unstable versions of Blender is vulnerable to arbitrary code
> execution.

oldstable (2.23-0.1) isn't affected as it shipped a version of blender
that didn't include this script yet (and was non-free anyway).

stable (2.36-1) is affected, I've attached a naive patch to remove all
'eval's in the script, which in fact basically is what upstream did.
Please see
<http://projects.blender.org/viewcvs/viewcvs.cgi/blender/release/scripts/bvh_import.py.diff?r1=1.4&r2=1.5&cvsroot=bf-blender>
for upstream details.

testing isn't affected anymore as blender has been removed from
testing due to general bugginess.

unstable (2.36-1 on alpha mips mipsel, 2.37a-1 on all other archs) is
partially affected: while 2.37a includes the upstream fix for this
problem this version hasn't been built on all archs due to bug#333958.

HTH,
Flo
diff -u blender-2.36/debian/changelog blender-2.36/debian/changelog
--- blender-2.36/debian/changelog
+++ blender-2.36/debian/changelog
@@ -1,3 +1,14 @@
+blender (2.36-1sarge1) stable-security; urgency=high
+
+  * patch release/scripts/bvh_import.py to use float instead of eval,
+thus preventing arbitrary code execution when importing a .bvh file;
+this fix differs from the changes in
+
<http://projects.blender.org/viewcvs/viewcvs.cgi/blender/release/scripts/bvh_import.py.diff?r1=1.4&r2=1.5&cvsroot=bf-blender>
+in that it doesn't provide the new checks introduced therein;
+    for reference, this is CVE-2005-3302 - closes: #330895
+
+ -- Florian Ernst <[EMAIL PROTECTED]>  Tue,  1 Nov 2005 17:41:53 +0100
+
 blender (2.36-1) unstable; urgency=high
 
   * The "Back From The Gig" release.
only in patch2:
unchanged:
--- blender-2.36.orig/release/scripts/bvh_import.py
+++ blender-2.36/release/scripts/bvh_import.py
@@ -331,7 +331,7 @@
   
   name = lines[lineIdx][1]
   lineIdx += 2 # Incriment to the next line (Offset)
-  offset = ( eval(lines[lineIdx][1]), eval(lines[lineIdx][2]), 
eval(lines[lineIdx][3]) )
+  offset = ( float(lines[lineIdx][1]), float(lines[lineIdx][2]), 
float(lines[lineIdx][3]) )
   lineIdx += 1 # Incriment to the next line (Channels)
   
   # newChannel[Xposition, Yposition, Zposition, Xrotation, Yrotation, 
Zrotation]
@@ -367,7 +367,7 @@
 # Account for an end node
 if lines[lineIdx][0] == 'End' and lines[lineIdx][1] == 'Site': # There is 
somtimes a name afetr 'End Site' but we will ignore it.
   lineIdx += 2 # Incriment to the next line (Offset)
-  offset = ( eval(lines[lineIdx][1]), eval(lines[lineIdx][2]), 
eval(lines[lineIdx][3]) )
+  offset = ( float(lines[lineIdx][1]), float(lines[lineIdx][2]), 
float(lines[lineIdx][3]) )
   makeEnd(parent, prefix, offset)
 
   # Just so we can remove the Parents in a uniform way- End end never has 
kids
@@ -431,14 +431,14 @@
 if debug: Blender.Redraw() 
 while obIdx < len(objectList) -1:
   if channelList[obIdx][0] != -1:
-
objectList[obIdx].getIpo().getCurve('LocX').addBezier((currentFrame, scale * 
eval(lines[lineIdx][channelList[obIdx][0]])))
+
objectList[obIdx].getIpo().getCurve('LocX').addBezier((currentFrame, scale * 
float(lines[lineIdx][channelList[obIdx][0]])))
   if channelList[obIdx][1] != -1:
-
objectList[obIdx].getIpo().getCurve('LocY').addBezier((currentFrame, scale * 
eval(lines[lineIdx][channelList[obIdx][1]])))
+
objectList[obIdx].getIpo().getCurve('LocY').addBezier((currentFrame, scale * 
float(lines[lineIdx][channelList[obIdx][1]])))
   if channelList[obIdx][2] != -1:
-
objectList[obIdx].getIpo().getCurve('LocZ').addBezier((currentFrame, scale * 
eval(lines[lineIdx][channelList[obIdx][2]])))
+
objectList[obIdx].getIpo().getCurve('LocZ').addBezier((currentFrame, scale * 
float(lines[lineIdx][channelList[obIdx][2]])))
   
   if channelList[obIdx][3] != '-1' or channelList[obIdx][4] != '-1' or 
channelList[obIdx][5] != '-1':
-x, y, z = eulerRotate(eval(lines[lineIdx][channelList[obIdx][3]]), 
eval(lines[lineIdx][channelList[obIdx][4]]), 
eval(lines[lineIdx][channelList[obIdx][5]]))
+x, y, z = 
eulerRotate(float(lines[lineIdx][channelList[obIdx][3]]), 
float(lines[lineIdx][channelList[obIdx][4]]), 
float(lines[lineIdx][channelList[obIdx][5]]))
 
objectList[obIdx].getIpo().getCurve('RotX').addBezier((currentFrame, x))
 
objectList[obIdx].getIpo().getCurve('RotY').addBezier((currentFrame, y))
 
objectList[obIdx].getIpo().getCurve('RotZ').addBezier((currentFrame, z))


signature.asc
Description: Digital signature

Bug#323527: Doesn't FTBFS here...

[Florian Ernst]

Hello *,

blender_2.37a-1 builds fine in an unstable chroot using pbuilder.
Apparently it now uses an internal copy of openal, consequently not
showing a Depends on libopenal anymore.

Assuming 2.36-1 in stable still builds fine as well and taking into
account that 2.36-1 has been removed from testing due to general
bugginess I guess this bug can be closed...

However, not building against the openal package in Debian can be
considered a bug on its own.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#333958: FTBFS when using sudo (see #288882)

[Florian Ernst]

Just one more note:
Incidentally, all archs using sudo instead of fakeroot fail to
build[0]. Again this is caused by scons creating files during the
clean target, just as in #22, so the same fix should resolve both
the FTBFS on alpha, mips and mipsel and this bug.

Cheers,
Flo


[0] To be honest, mipsel failed due to a missing dependency. However,
Frank Lichtenheld has resolved the openal issue, so now I'd expect the
build to fail on mipsel the same way it did on alpha and mips.


signature.asc
Description: Digital signature

Bug#333958: #288882 came back to life

[Florian Ernst]

Just for the record, this problem had been fixed before in 2.36-1.1,
thanks to hints from Frank Lichtenheld, but somehow it came back to
life again.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#293667: #293667 not fixed by recent update

[Florian Ernst]

found 293667 4.41.3-2
found 293667 4.46.2-1
thanks [EMAIL PROTECTED] BCCed

Uhm, how does adding a Depends on debconf (>= 0.5) | debconf-2.0
resolve the problem of simply not sourcing the debconf library before
using a debconf function?
(Ref. ,
here the preinst code in question:
| case "$1" in
| install|upgrade)
|if [ -n "$2" ]; then
|if dpkg --compare-versions "$2" lt 4; then
|db_get mailscanner/v3_upgrade
 ^^
Sourcing /usr/share/debconf/confmodule only occurs later in the script.

The Woody version still can't be upgraded to the Sarge version, so
shouldn't there be an upload to stable-proposed-updates for Joey to
consider for the next point release...?

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#326210: Fixed in DSA 797-2?

[Florian Ernst]

Hi there,

doesn't DSA 797-2 address this issue, so this bug can be fixed by
now...?

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#218908: Candidates for removal

[Florian Ernst]

On Thu, Sep 29, 2005 at 12:36:18PM -0500, Sam Hart wrote:
> On Thu, 2005-09-29 at 18:23 +0200, Florian Ernst wrote:
> > On Thu, Sep 29, 2005 at 10:37:01AM -0500, Sam Hart wrote:
> > > [...]
> > > Nearly every graphic, sound and animation was something that I created
> > > except for a few images which were pulled from the Copyright Free Photo
> > > Archive here: http://gimp-savvy.com/PHOTO-ARCHIVE/index.html
> >
> > ...and the copyright (and redistribution terms) for those images needs
> > to be explicitely listed.
>
> Actually, I'm not 100% this really has to be the case on material I
> originally created. [...]
> If this isn't the case, then I can find /many/ other projects out there
> where artwork, sounds, etc. were created for projects that would need to
> be revised.

Ah, sorry, I didn't quite make myself clear. Actually I only mean
those "few images which were pulled from the Copyright Free Photo
Archive", and not those you have created.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#218908: Candidates for removal

[Florian Ernst]

Hello *,

On Thu, Sep 29, 2005 at 10:37:01AM -0500, Sam Hart wrote:
> >> 1266 days: tuxtype (0 waiting, new pkg, has RC bugs) [Rune B. Broberg]
> >>  Copyright issues (see bug 218908).  Jeroen wrote "let's see if someone
> >>  interested jumps in, otherwise, removal seems to be the best option to 
> >> me."
> >>  -- on 21 June.  Someone said that they were trying to make a sponsored
> >>  upload on 18 August; I've pinged them.
> 
> [...]
> Nearly every graphic, sound and animation was something that I created
> except for a few images which were pulled from the Copyright Free Photo
> Archive here: http://gimp-savvy.com/PHOTO-ARCHIVE/index.html

...and the copyright (and redistribution terms) for those images needs
to be explicitely listed. Only _most_ of the pictures at this archive
are really free to use, as I understand it. E.g. this archive lists
the U.S. Fish and Wildlife Service as one of their main sources, but
the FWS say "Not all the information on our site is in the public
domain. Some images/graphics are licensed for use under the copyright
law, [...]" (). Please
see 
for a longer list dealing with tuxtype_1.5.3 (not in Debian, but parts
of this list apply to 1.0 currently present in Debian as well, see
.

> Beyond the 1.0 release, there may have been some graphics that

Graphics, sound files and fonts.

> originated from somewhere else, I'm afraid you'd have to track down and
  ^^^
> ask Jesse Andrews for those details.
> [...]
> If anyone is willing to work with me to identify what /specifically/ is
> needed for it, I'd be more than obliged.

Methinks you already named it as underlined above, but possibly some
other people might want to chime in at this point...


BTW, there's someone interested in maintaining tuxtype, but currently
his approach seems to be to remove all questionable media files from
the package... Nathanael Nerode is on the spot, however.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#302431: xmms-crossfade: FTBFS (amd64/gcc-4.0): static declaration of 'monitor_win' follows non-static declaration

[Florian Ernst]

On Mon, Sep 12, 2005 at 03:36:46PM +0200, Martin Waitz wrote:
> On Mon, Sep 12, 2005 at 02:09:48PM +0200, Florian Ernst wrote:
> > Just uploaded, please find attached the build log from my machine
> > (i386). I tested and found no regression in functionality.
> 
> thanks a lot!

np. btw, the package currently FTBFS on m68k, see
<http://buildd.debian.org/build.php?&pkg=xmms-crossfade&ver=0.3.5-1.1&arch=m68k&file=log>
for reference. This is probably due to
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327780>,
so methinks there isn't much we can do...

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#302431: xmms-crossfade: FTBFS (amd64/gcc-4.0): static declaration of 'monitor_win' follows non-static declaration

[Florian Ernst]

.2.dfsg.1-6) ...

Setting up libice-dev (6.8.2.dfsg.1-6) ...
Setting up libsm6 (6.8.2.dfsg.1-6) ...

Setting up libsm-dev (6.8.2.dfsg.1-6) ...
Setting up libssl-dev (0.9.7g-2) ...

Setting up libxau6 (6.8.2.dfsg.1-6) ...

Setting up libxau-dev (6.8.2.dfsg.1-6) ...
Setting up libxdmcp6 (6.8.2.dfsg.1-6) ...

Setting up libxdmcp-dev (6.8.2.dfsg.1-6) ...
Setting up libxinerama1 (6.8.2.dfsg.1-6) ...

Setting up libxkbui1 (6.8.2.dfsg.1-6) ...

Setting up libxkbui-dev (6.8.2.dfsg.1-6) ...
Setting up libxt6 (6.8.2.dfsg.1-6) ...

Setting up libxmu6 (6.8.2.dfsg.1-6) ...

Setting up libxmuu1 (6.8.2.dfsg.1-6) ...

Setting up libxp6 (6.8.2.dfsg.1-6) ...

Setting up libxpm4 (6.8.2.dfsg.1-6) ...

Setting up libxrender1 (0.9.0-2) ...

Setting up libxrandr2 (6.8.2.dfsg.1-6) ...

Setting up render-dev (0.9-1) ...
Setting up libxres1 (6.8.2.dfsg.1-6) ...

Setting up libxres-dev (6.8.2.dfsg.1-6) ...
Setting up libxss1 (6.8.2.dfsg.1-6) ...

Setting up libxtrap6 (6.8.2.dfsg.1-6) ...

Setting up libxtst6 (6.8.2.dfsg.1-6) ...

Setting up libxv1 (6.8.2.dfsg.1-6) ...

Setting up libxvmc1 (6.8.2.dfsg.1-6) ...

Setting up libxxf86dga1 (6.8.2.dfsg.1-6) ...

Setting up libxxf86dga-dev (6.8.2.dfsg.1-6) ...
Setting up libxxf86misc1 (6.8.2.dfsg.1-6) ...

Setting up libxxf86misc-dev (6.8.2.dfsg.1-6) ...
Setting up libxxf86vm1 (6.8.2.dfsg.1-6) ...

Setting up libxxf86vm-dev (6.8.2.dfsg.1-6) ...
Setting up pm-dev (6.8.2.dfsg.1-6) ...
Setting up zlib1g-dev (1.2.3-4) ...
Setting up xmms (1.2.10+cvs20050809-1) ...

Setting up libxi-dev (6.8.2.dfsg.1-6) ...
Setting up libx11-dev (6.8.2.dfsg.1-6) ...
Setting up libgtk1.2-dev (1.2.10-17) ...
Setting up libxinerama-dev (6.8.2.dfsg.1-6) ...
Setting up libxt-dev (6.8.2.dfsg.1-6) ...
Setting up libxmu-dev (6.8.2.dfsg.1-6) ...
Setting up libxmuu-dev (6.8.2.dfsg.1-6) ...
Setting up libxp-dev (6.8.2.dfsg.1-6) ...
Setting up libxpm-dev (6.8.2.dfsg.1-6) ...
Setting up libxrender-dev (0.9.0-2) ...
Setting up libxrandr-dev (6.8.2.dfsg.1-6) ...
Setting up libxss-dev (6.8.2.dfsg.1-6) ...
Setting up libxtrap-dev (6.8.2.dfsg.1-6) ...
Setting up libxtst-dev (6.8.2.dfsg.1-6) ...
Setting up libxv-dev (6.8.2.dfsg.1-6) ...
Setting up libxvmc-dev (6.8.2.dfsg.1-6) ...
Setting up xlibs-static-dev (6.8.2.dfsg.1-6) ...
Setting up xmms-dev (1.2.10+cvs20050809-1) ...
Setting up xlibs-dev (6.8.2.dfsg.1-6) ...
 -> Finished parsing the build-deps
Copying back the cached apt archive contents
/var/cache/pbuilder/build/6227/etc/passwd
/var/cache/pbuilder/build/6227/etc/group
Copying source file
-> copying [xmms-crossfade_0.3.5-1.1.dsc]
-> copying [./xmms-crossfade_0.3.5.orig.tar.gz]
-> copying [./xmms-crossfade_0.3.5-1.1.diff.gz]
Extracting source
dpkg-source: extracting xmms-crossfade in xmms-crossfade-0.3.5
dpkg-source: unpacking xmms-crossfade_0.3.5.orig.tar.gz
dpkg-source: applying ./xmms-crossfade_0.3.5-1.1.diff.gz
 -> Building the package
dpkg-buildpackage: source package is xmms-crossfade
dpkg-buildpackage: source version is 0.3.5-1.1
dpkg-buildpackage: source changed by Florian Ernst <[EMAIL PROTECTED]>
dpkg-buildpackage: host architecture i386
 debian/rules clean
test -x debian/rules
test "`id -u`" = 0
if test -n "" && test "" != "."; then rmdir ""; fi
if test "." != "."; then rmdir .; fi
for i in ./config.guess ./config.sub  ; do \
if test -e $i.cdbs-orig ; then \
mv $i.cdbs-orig $i ; \
fi ; \
done
dh_clean
make -C . -k distclean || true
make[1]: Entering directory `/tmp/buildd/xmms-crossfade-0.3.5'
make[1]: *** No rule to make target `distclean'.
make[1]: Leaving directory `/tmp/buildd/xmms-crossfade-0.3.5'
rm -f debian/stamp-makefile-build
if [ -f "./config.log" ] && grep -i 'generated.*by.*autoconf' "./config.log" 
1>/dev/null; then \
  rm -f "./config.log"; \
fi
rm -f debian/stamp-autotools-files
if test -f ./config.status && grep -i -q 'Generated.*by configure.' 
./config.status; then rm -f ./config.status; fi
if test -f ./config.cache && grep -i -q 
'shell.*script.*caches.*results.*configure' ./config.cache; then rm -f 
./config.cache; fi
 dpkg-source -b xmms-crossfade-0.3.5
dpkg-source: building xmms-crossfade using existing 
xmms-crossfade_0.3.5.orig.tar.gz
dpkg-source: building xmms-crossfade in xmms-crossfade_0.3.5-1.1.diff.gz
dpkg-source: building xmms-crossfade in xmms-crossfade_0.3.5-1.1.dsc
 debian/rules build
test -x debian/rules
if [ -n "" ]; then \
  mkdir -p ""; \
fi
if [ ! -d "." ]; then \
  mkdir -p "."; \
fi
/usr/share/cdbs/1/rules/buildcore.mk:116: "DEB_BUILD_MAKE_TARGET is a 
deprecated variable"
/usr/share/cdbs/1/rules/buildcore.mk:116: "DEB_CLEAN_MAKE_TARGET is a 
deprecated variable"
/usr/share/cdbs/1/rules/buildcore.mk:116: "DEB_MAKE_TEST_TARGET is a deprecated 
variable"
if [ 

Bug#317207: Qt, aRts and KDE C++ ABI transitions: time to upload your packages

[Florian Ernst]

Hello Tommaso,

On Sat, 9 Jul 2005 07:47:57 +0200, Tommaso Moroni wrote:
> I'm waiting for the C++ transition to be completed (expecially
> for kdelibs4 and friends) before recompiling and uploading.

Just FYI, in the light of

the time for waiting seems to be over.

Cheers,
Flo


PS: Please don't forget to include Jens' patch about German l10n.


signature.asc
Description: Digital signature

Bug#320720: package built in old build-env, needs better build-deps

[Florian Ernst]

reassign 320720 htmldoc
thanks [EMAIL PROTECTED] BCCed

On Sat, Sep 10, 2005 at 12:11:31AM +0200, Matthias Klose wrote:
> Florian Ernst writes:
> > On Mon, 1 Aug 2005 00:20:27 +0200, Matthias Klose wrote:
> > > Package: htmlgen
> > > Version: 1.8.24-1
> > > Severity: serious
> > > 
> > > please build in a current unstable build environment, tighten the
> > > build dependency on the libfltk1.1 development package.
> > 
> > As htmlgen has entered the archives in 1998 at revision 2.1 and
> > furthermore has no (Build-)Depends on anything fltk-like, I suppose
> > this was meant for another package...?
> > 
> > Unfortunately it eludes me which package this might be.
> 
> sorry, htmldoc ... should'nt file bug report after midnight.
> 

Reassigning now and CCing the maintainer of htmldoc so he gets aware
of this.

HTH,
Flo


signature.asc
Description: Digital signature

Bug#320720: package built in old build-env, needs better build-deps

[Florian Ernst]

On Mon, 1 Aug 2005 00:20:27 +0200, Matthias Klose wrote:
> Package: htmlgen
> Version: 1.8.24-1
> Severity: serious
> 
> please build in a current unstable build environment, tighten the
> build dependency on the libfltk1.1 development package.

As htmlgen has entered the archives in 1998 at revision 2.1 and
furthermore has no (Build-)Depends on anything fltk-like, I suppose
this was meant for another package...?

Unfortunately it eludes me which package this might be.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#326198: fixed in 1:1.0.9.dfsg-3 and later?

[Florian Ernst]

On Fri, 08 Jul 2005 19:20:18 +0200, Fionn Behrens wrote:
> [...] the configuration stage of the asterisk
> package fails with the following error:
> adduser: No more than two names.
> dpkg: error processing asterisk (--configure):
>  subprocess post-installation script returned error exit status 255

But the changelog entry of 1:1.0.9.dfsg-3 reads:
|   * Cleanup postinit error: adduser asterisk audio; adduser asterisk
| dialout
and the corresponding code is still present in 1:1.0.9.dfsg-5.

So isn't this bug basically fixed?

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#326008: apt-listbugs #326008 related to ruby1.8 #311823?

[Florian Ernst]

Just for the record, it looks like the grave bug #326008 in
apt-listbugs might be related to bug #311823 in ruby1.8, thus adding
more info to ruby's bug and a possibly valid background to
apt-listbugs' bug.

Cheers,
Flo


signature.asc
Description: Digital signature