Bug#828986: liblrdf: FTBFS: devlibs error: There is no package matching [libraptor1-dev] and noone provides it, please report bug to d-shlibs maintainer

2016-06-29 Thread Jonas Smedegaard
Quoting Chris Lamb (2016-06-29 23:07:32)
> > [...] Sorry, not apt-file but apt-cache.  What d-shlibs rely on is an 
> > up-to-date APT cache
> 
> Ahhh, this was what I needed - for some reason I didn't have 
> pkgcache.bin & srcpkgcache.bin, so the whole d-shlibs machinery was 
> refusing to work.
> 
> Closing bug in BCC and apologies for the noise...

No need for apologies: Your tests are greatly appreciated, and it is no 
surprise you run into odd cornercases when doing so many of them.

...and it also helps if I knew how the code works that I maintain, to 
not confuse the conversation when attempting to enlighten :-P


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#828986: liblrdf: FTBFS: devlibs error: There is no package matching [libraptor1-dev] and noone provides it, please report bug to d-shlibs maintainer

2016-06-29 Thread Chris Lamb
> [...] Sorry, not apt-file but apt-cache.  What d-shlibs rely on is an 
> up-to-date APT cache

Ahhh, this was what I needed - for some reason I didn't have pkgcache.bin & 
srcpkgcache.bin, so the whole d-shlibs machinery was refusing to work.

Closing bug in BCC and apologies for the noise...


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


Bug#828986: liblrdf: FTBFS: devlibs error: There is no package matching [libraptor1-dev] and noone provides it, please report bug to d-shlibs maintainer

2016-06-29 Thread Jonas Smedegaard
Quoting Chris Lamb (2016-06-29 18:24:13)
>> this failure is most likely because your build environment is buggy
>
> It's always a fresh, clean container image that I recreate entirely 
> (not dist-upgrade) at 07:00 UTC on my laptop from the latest sid. I 
> run build-dep and then build with debuild; nothing special.

I believe that you do not expect your environment to be _too_ special, 
but highly suspect that you have applied some optimizations over, say, 
running debian-installer from bare metal for each and every build.

Can you try add an "apt update" in the build environment before building 
the package, and see if it still fails?


> Other systems -- including the reproducible builds servers -- can 
> reproduce the FTBFS, so I am not convinced at this point that my 
> environment is buggy.

Where do you see that?  The log currently linked from tracker.debian.org 
was another issue (since fixed in CDBS).


>> apt-file initializes its database when installed, and d-shlibs rely 
>> on that.
> 
> Ah, smells like the bug is there - d-shlibs does not depend on apt-file
[...] Sorry, not apt-file but apt-cache.  What d-shlibs rely on is an 
up-to-date APT cache (it calls "apt-cache --no-generate due to 
bug#630591 - which seems a no-op since ages but shouldn't fail either).

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#828986: liblrdf: FTBFS: devlibs error: There is no package matching [libraptor1-dev] and noone provides it, please report bug to d-shlibs maintainer

2016-06-29 Thread Chris Lamb
> this failure is most likely because your build environment is buggy

It's always a fresh, clean container image that I recreate entirely (not 
dist-upgrade) at 07:00 UTC on my laptop from the latest sid. I run build-dep 
and then build with debuild; nothing special. 

Other systems -- including the reproducible builds servers -- can reproduce the 
FTBFS, so I am not convinced at this point that my environment is buggy.

> One way that can happen is if your environment blocks network access not 
> only during build but also during installation of build-dependencies.

I don't block internet access. I really should though!

> apt-file initializes its database when installed, and d-shlibs rely on that.

Ah, smells like the bug is there - d-shlibs does not depend on apt-file and, 
clearly, I should not have to manage that dependency manually or have it 
installed in my minimal chroots. :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


Bug#828986: liblrdf: FTBFS: devlibs error: There is no package matching [libraptor1-dev] and noone provides it, please report bug to d-shlibs maintainer

2016-06-29 Thread Jonas Smedegaard
Hi Chris,

Quoting Chris Lamb (2016-06-29 16:28:30)
> liblrdf fails to build from source in unstable/amd64:
[...]
>   d-shlibmove --commit \
> --movedev "debian/tmp/usr/include/*" usr/include/ \
> --movedev "debian/tmp/usr/lib/pkgconfig/*.pc" usr/lib/pkgconfig/ \
> --moveshl debian/tmp/usr/share/ladspa/rdf/ladspa.rdfs 
> usr/share/ladspa/rdf/ \
> debian/tmp/usr/lib/liblrdf.so
>   Library package automatic movement utility
>   devlibs error: There is no package matching [libraptor1-dev] and noone 
> provides it, please report bug to d-shlibs maintainer
>   debian/rules:65: recipe for target 'binary-post-install/liblrdf0' failed
>   make: *** [binary-post-install/liblrdf0] Error 1

Like a previous report from you this failure is most likely because your 
build environment is buggy: apt-file initializes its database when 
installed, and d-shlibs rely on that.

One way that can happen is if your environment blocks network access not 
only during build but also during installation of build-dependencies.

Another idea is a race condition: Cache filling being slower than 
running the build.

In short: Please check that your environment has a working apt-file, and 
_after_ that is examined test if the build still fails.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#828986: liblrdf: FTBFS: devlibs error: There is no package matching [libraptor1-dev] and noone provides it, please report bug to d-shlibs maintainer

2016-06-29 Thread Chris Lamb
Source: liblrdf
Version: 0.4.0-7
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

liblrdf fails to build from source in unstable/amd64:

  [..]

  checking whether make sets $(MAKE)... (cached) yes
  checking build system type... x86_64-pc-linux-gnu
  checking host system type... x86_64-pc-linux-gnu
  checking how to print strings... printf
  checking for a sed that does not truncate output... /bin/sed
  checking for grep that handles long lines and -e... /bin/grep
  checking for egrep... /bin/grep -E
  checking for fgrep... /bin/grep -F
  checking for ld used by gcc... /usr/bin/ld
  checking if the linker (/usr/bin/ld) is GNU ld... yes
  checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
  checking the name lister (/usr/bin/nm -B) interface... BSD nm
  checking the maximum length of command line arguments... 1572864
  checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu 
format... func_convert_file_noop
  checking how to convert x86_64-pc-linux-gnu file names to toolchain format... 
func_convert_file_noop
  checking for /usr/bin/ld option to reload object files... -r
  checking for objdump... objdump
  checking how to recognize dependent libraries... pass_all
  checking for dlltool... no
  checking how to associate runtime and link libraries... printf %s\n
  checking for ar... ar
  checking for archiver @FILE support... @
  checking for strip... strip
  checking for ranlib... ranlib
  checking command to parse /usr/bin/nm -B output from gcc object... ok
  checking for sysroot... no
  checking for a working dd... /bin/dd
  checking how to truncate binary pipes... /bin/dd bs=4096 count=1
  checking for mt... no
  checking if : is a manifest tool... no
  checking for ANSI C header files... yes
  checking for sys/types.h... yes
  checking for sys/stat.h... yes
  checking for stdlib.h... yes
  checking for string.h... yes
  checking for memory.h... yes
  checking for strings.h... yes
  checking for inttypes.h... yes
  checking for stdint.h... yes
  checking for unistd.h... yes
  checking for dlfcn.h... yes
  checking for objdir... .libs
  checking if gcc supports -fno-rtti -fno-exceptions... no
  checking for gcc option to produce PIC... -fPIC -DPIC
  checking if gcc PIC flag -fPIC -DPIC works... yes
  checking if gcc static flag -static works... yes
  checking if gcc supports -c -o file.o... yes
  checking if gcc supports -c -o file.o... (cached) yes
  checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared 
libraries... yes
  checking whether -lc should be explicitly linked in... no
  checking dynamic linker characteristics... GNU/Linux ld.so
  checking how to hardcode library paths into programs... immediate
  checking whether stripping libraries is possible... yes
  checking if libtool supports shared libraries... yes
  checking whether to build shared libraries... yes
  checking whether to build static libraries... yes
  checking for ANSI C header files... (cached) yes
  checking errno.h usability... yes
  checking errno.h presence... yes
  checking for errno.h... yes
  checking limits.h usability... yes
  checking limits.h presence... yes
  checking for limits.h... yes
  checking for stdlib.h... (cached) yes
  checking for string.h... (cached) yes
  checking for unistd.h... (cached) yes
  checking for pkg-config... /usr/bin/pkg-config
  checking pkg-config is at least version 0.9.0... yes
  checking for RAPTOR... yes
  checking for an ANSI C-conforming const... yes
  checking for inline... inline
  checking for size_t... yes
  checking for vprintf... yes
  checking for _doprnt... no
  checking for getcwd... yes
  checking for strcasecmp... yes
  checking for strchr... yes
  checking for strdup... yes
  checking for strerror... yes
  checking for strncasecmp... yes
  checking for strrchr... yes
  checking that generated files are newer than configure... done
  configure: creating ./config.status
  config.status: creating lrdf.pc
  config.status: creating Makefile
  config.status: creating src/Makefile
  config.status: creating examples/Makefile
  config.status: creating config.h
  config.status: executing depfiles commands
  config.status: executing libtool commands
  configure: WARNING: unrecognized options: --disable-maintainer-mode
  touch debian/stamp-autotools
  /usr/bin/make -C . 
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160629155645.mRkmX5Gbx0.liblrdf/liblrdf-0.4.0'
  /usr/bin/make  all-recursive
  make[2]: Entering directory 
'/home/lamby/temp/cdt.20160629155645.mRkmX5Gbx0.liblrdf/liblrdf-0.4.0'
  Making all in src
  make[3]: Entering directory 
'/home/lamby/temp/cdt.20160629155645.mRkmX5Gbx0.liblrdf/liblrdf-0.4.0/src'
  /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..  
 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong