Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can not build hddtemp on DEBIAN Bullseye (v11) #5

Open
c64emulator opened this issue Jan 31, 2022 · 5 comments
Open

can not build hddtemp on DEBIAN Bullseye (v11) #5

c64emulator opened this issue Jan 31, 2022 · 5 comments

Comments

@c64emulator
Copy link

After download, extract and runing "autogen.sh", I invoke "make" in the top directory. Make fails cause there is a endless loop in the "po" directory. Invoking "make" in the "src" directoy works.

@modem7
Copy link

modem7 commented Mar 1, 2022

Thanks @c64emulator - you resolved an issue I was having!

@yann-morin-1998
Copy link

You need to run gettextize first.

And basically, one should not need to run autogen.sh nowadays; autogen.sh is a remnnant
from decades ago, when autoreconf was not yet capable enough to detect the tools it
needs to run. Calling autoreconf should always be sufficient in recent times.

arnout pushed a commit to buildroot/buildroot that referenced this issue Dec 11, 2022
[Bernd:
 - switched to actively maintained fork
 - package/Config.in: moved to "Hardware handling" (Peter)
 - added toolchain dependencies (Thomas)
 - added license hash
 - fixed build errors related to iconv and execinfo (Peter)
 - removed hook HDDTEMP_REMOVE_MAN (Thomas)
 - install hddtemp.db to target
 - added build/install _CMDS due to
   vitlav/hddtemp#5]
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[yann.morin.1998@free.fr:
  - use GETTEXTIZE=YES, drop host-gettext from _DEPENDENCIES
  - drop custom build and install commands now that we gettextize
  - explicitly specify the DB path, introduce HDDTEMP_DB_PATH
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
@modem7
Copy link

modem7 commented Jan 17, 2023

You need to run gettextize first.

And basically, one should not need to run autogen.sh nowadays; autogen.sh is a remnnant from decades ago, when autoreconf was not yet capable enough to detect the tools it needs to run. Calling autoreconf should always be sufficient in recent times.

@yann-morin-1998 - Would something like this be sane? (I'm not a programmer by trade, so apologies if this seems dumb)

apt-get install -y --no-install-recommends \
        build-essential                    \
        automake                           \
        autotools-dev                      \
        autopoint                          \
        gettext                            \
        git                                \
        pkg-config
git clone https://github.com/vitlav/hddtemp.git
cd hddtemp/
autoreconf -vsi --force
./configure
make

@yann-morin-1998
Copy link

yann-morin-1998 commented Jan 19, 2023

@modem7 That's basically it, except you missed gettextize. Also, I'd not use -s if
you are packaging (e.g. creating a .deb, .rpm or so), or the source package (deb-src,
etc...) would contain symlinks; instead, I'd just copy the files (that does not amount
to much space anyway):

cd hddtemp/
getttextize -f
autoreconf -vif
./configure
make

That should basically be the canonical sequence, except gettextize should be run by
the maintainer and the result committed to the tree. But gettext is very picky on the
version: the gettext used at build must be the same as the one that was used to
gettextize the source, e.g. mixing 1.2.3 is 1.2.4 are OK, but 1.2.3 and 1.3.4 is not.
So, this is why "old" packages may need to be locally gettextized...

@modem7
Copy link

modem7 commented Jan 19, 2023

@modem7 That's basically it, except you missed gettextize. Also, I'd not use -s if you are packaging (e.g. creating a .deb, .rpm or so), or the source package (deb-src, etc...) would contain symlinks; instead, I'd just copy the files (that does not amount to much space anyway):

cd hddtemp/
getttextize -f
autoreconf -vif
./configure
make

That should basically be the canonical sequence, except gettextize should be run by the maintainer and the result committed to the tree. But gettext is very picky on the version: the gettext used at build must be the same as the one that was used to gettextize the source, e.g. mixing 1.2.3 is 1.2.4 are OK, but 1.2.3 and 1.3.4 is not. So, this is why "old" packages may need to be locally gettextized...

That makes sense!

Do you know of any way to stop gettextize prompting to "confirm"? It seems to break CI/CD otherwise.

Worst case, I can always use "expect" or similar!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants