Re: Packaging hwinfo

[phodina]

> Petr,
>
> > Besides I also opened an issue
>
> Thanks! A good reflex, whether or not upstream cares or notices.
>

Well my point here is that the issue concerning the project itself should be 
reported e.g. what are the instructions to build it by hand.
However, when comes to the packaging then it's obvious not a problem of the 
project itself and therefore I ask on this mailing list.

> Please share packages in a form that can easily be built by others. I
>
> added missing module imports and changed a forgotten /usr/lib to /lib.
>

Good point and my apologizes for that.

> Please also place {native-,}inputs after arguments. Phases need no
>
> longer return #t.
>

Thanks. Fixed.

> > CFLAGS+="-fPIC -I$srcdir/$pkgname/src/hd -w"
>
> This does not look relevant, so I didn't add it anywhere.
>
> > starting phase `build'
> >
> > gcc -c -O2 -Wall -Wno-pointer-sign -pipe -g
> >
> > -I/tmp/guix-build-hwinfo-21.75.drv-0/source/src/hd -Lsrc hwinfo.c
> >
> > make: *** No rule to make target
> >
> > '/tmp/guix-build-hwinfo-21.75.drv-0/source/src/libhd.a', needed by
> >
> > 'hwinfo'. Stop.
> >
> > The build continues
>
> And how:
>
> make: *** Waiting for unfinished jobs....
>
> make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent
>
> make rule.
>
> make[1]: Entering directory
>
> '/tmp/guix-build-hwinfo-21.75.drv-0/source/src'
>
> make[2]: Entering directory
>
> '/tmp/guix-build-hwinfo-21.75.drv-0/source/src/hd'
>
> i.e.: "Oh no, you made some mistake, I can't make libhd! Anyway, before
>
> I perish dramatically, let's chdir into this here 'src/hd' directory and
>
> make whatever's there. ¯\( ツ )/¯ I'm sure it won't be relevant lol."
>
> That's one bug that only upstream can fix. For now, set
>
> "#:parallel-build? #f" (with a detailed comment!) and you'll be on your

Turning off the parallel build fixes the issue. But it's still a bug as the 
target src/libhd.a is "not relevant". I'll update the ticket on upstream with 
the findings. Thanks Tobias.

>
> merry, slow, way. Alas:
>
> > /gnu/store/74ldv6c74gslx5irsa0a8kn54yi4gc3h-hwinfo-21.75/bin/hwinfo:
> >
> > error: depends on 'libhd.so.21', which cannot be found in RUNPATH
>
> Weird, but (search for '-Wl,-rpath' in Guix) it happens. Let's--no,
>
> wait a minute, strange things are afoot:
>
> tree /gnu/store/74ldv6c74gslx5irsa0a8kn54yi4gc3h-hwinfo-21.75
>
> ├── bin
>
> │   ├── check_hd
>
> │   ├── convert_hd
>
> │   ├── getsysinfo
>
> │   ├── hwinfo
>
> │   └── mk_isdnhwdb
>
> ├── gnu
>
> │   └── store
>
> │   └── 74ldv6c74gslx5irsa0a8kn54yi4gc3h-hwinfo-21.75
>
> │   └── lib
>
> │   ├── libhd.so -> libhd.so.21
>
> [...]
>
> Afootness intensifies:
>
> > (string-append "DESTDIR=" %output)
>
> Seeing DESTDIR= is never a good sign (I didn't check whether its use in
>
> libx86emu is warranted or not). Let's stick with hwinfo & peer into its

Nope, but then again let's create a ticket upstream with the fix.

>
> Makefile again:
>
> > ULIBDIR = $(LIBDIR)
> >
> > [...]
> >
> > install -d -m 755 $(DESTDIR)/sbin $(DESTDIR)/usr/sbin \
> >
> > $(DESTDIR)$(ULIBDIR)
>
> Really? No support for the standard $prefix variable? Cool.
>
> Making LIBDIR 'relative' works around that. Not the rpath issue, so:
>
> > "LIBDIR=/lib"
> >
> > (string-append "LDFLAGS=-Lsrc -Wl,-rpath=" %output "/lib")
>
> The "-Lsrc" is repeated from upstream, because VARIABLE+= on the make
>
> command line doesn't actually work.
>
> With that, it finally builds and runs. Some software just isn't fun to
>
> package.

It's a tedious process that often overlooked in distros where all stuff is 
already packaged.

>
> From hwinfo:
>
> > using /var/lib/hardware
>
> This might need fixing. There may be remaining issues with the
>
> package(s); I'm out of time.
>

Thanks for your time! I made the modification and now it builds. Time to 
prepare the patches.

> From the build log:
>
> > info(FRITZ!Card PCMCIA): This card has multiple drivers, some functions
> >
> > are only available on the binonly driver
>
> We'll need to make sure this package doesn't include or 'promote' binary
>
> blobs in any way.
>

What do you mean by striping binary blobs?
Don't know exactly how to spot them yet :-)