In order to be able to cancel a process on Windows, I need to make use of this fix for process package, which is still not released. I've tried adding the latest version from github as a dependency in my stack.yaml file:
packages:
- '.'
- location:
git: https://github.com/haskell/process.git
commit: 2fb7e739771f4a899a12b45f8b392e4874616b89
extra-dep: true
But the stack build command fails:
Process exited with code: ExitFailure 1
Logs have been written to: C:\Users\nadalesagutde\Documents\github\capitanbatata\sandbox\racing-turtles\.stack-work\logs\process-1.6.1.0.log
Configuring process-1.6.1.0...
Warning: The 'build-type' is 'Configure' but there is no 'configure' script.
You probably need to run 'autoreconf -i' to generate it.
setup.exe: configure script not found.
In the README of process is stated that autoreconf -i must be run before, but I don't know how to tell this to stack. Do I need some extra configuration in my stack.yaml file?
Looks like the package's git repo does not include the "configure" script, which is needed to use the package directly. The reason things work when downloading from hackage is that the source distribution does include the configure script. Frustrating! I think this is an atypical design decision for a package that uses configure. I've opened this stack issue: https://github.com/commercialhaskell/stack/issues/3534
Suggested workaround is to clone the repo as a submodule and run autoreconf -i manually.
Related
I am working to enable the kexec support in my propriety Linux distribution and I would like to debug the kexec tools in user space. I am adding debug prints in the kexec.c that's located in buildroot/output/build/kexec-2.0.15/kexec/kexec.c, but if I do an incremental build with make, it doesn't look like the kexec binary has been updated. If I rebuild everything from scratch with make all, the source code kexec.c has been overridden and I don't see my changes. My guess is that every full build re-extracts the kexec package and that is why my changes are not taking affect.
How do I solve this issue?
Try to use "make kexec-rebuild".
If you only want to restart the build process of a package from its
compilation step, you can run make <package>-rebuild [...]. It will restart the compilation and installation of
the package, but not from scratch: it basically re-executes make and
make install inside the package, so it will only rebuild files that
changed.
[...]
Internally, Buildroot creates so-called stamp files to keep track of
which build steps have been completed for each package. They are
stored in the package build directory,
output/build/-/ and are named .stamp_.
The commands detailed above simply manipulate these stamp files to
force Buildroot to restart a specific set of steps of a package build
process.
(from the Buildroot manual, section Understanding how to rebuild packages -- I suggest you read the whole section)
Also, look at your build log. If you don't see a line like
>>> kexec 2.0.16 Building
then the kecxec package hasn't been (re)built.
How to install a specific version of git commit in Linux? When any program requests for the library it should take from the installation.
Eg:
The following version of wiringPi is required by one of my c++ program.
git://git.drogon.net/wiringPi
Version: 5edd177112c99416f68ba3e8c6c4db6ed942e796
Add a checkout statement after you clone?
Eg:
git clone git://git.drogon.net/wiringPi
git checkout 5edd177112c99416f68ba3e8c6c4db6ed942e796
Then you type the build and installation commands - if you want everything to use it, it probably needs to go in the default location. For the package you're looking at the documentation says it's:
./build
If you already have a version from a package manager (like apt you should remove that first - the README.md from the package you linked explains how to do this)
I've created packages previously by using a Makefile, the command "dh_make --createorig", then adjusting files in the debian folder generated and finally using the debuild command to generate the .deb. That workflow is simple and works for me, but I was told to adjust it a little in a way that you could build the project from the sources without requiring the orig files and I'm unsure how to do it, but according to this (https://askubuntu.com/questions/17508/how-to-have-debian-packaging-generate-two-packages-given-an-upstream-source-arch) and this structure (http://bazaar.launchpad.net/~andrewsomething/imagination/debian/files) there must be a way. In my case I would have a folder with the sources and all of that and then a debian folder (generated with dh_make) but I'm unsure on how to avoid the debuild command to ask for the .orig files or if I should be using some other command for this.
Sorry for the superlong question, I think I provided all the relevant information, but I can clarify if anything is fuzzy.
The difference is in the version number in the file debian/changelog.
If you use 1.2.3-1 it implied Debian build 1 of an upstream package 1.2.3 --- for which the build programs (dpkg-buildpackage and whichever wrappers on top) --- assume an .orig.tar.gz to exists.
But if you use 1.2.3 it will consider the package 'Debian native' and the archive is just a .tar.gz and not an .orig.tar.gz.
Now the choice should not be driven by your convenience alone. If this has an upstream source, use the first scheme. If not, the second can be fine. In the packages I maintain I have both but way more of the former.
If you want to create a Debian directory directly in the source package (ie you're packaging your own work, rather than from an upstream release) you could use the --native option to dh_make
I think the question was asked differently, it was somewhat clear that the project was upstream and it's probably not a good reason to change its format to native.
Currently I package some upstream python project, this exact same question came to my mind. Why isn't there any dh_* hook to overwrite in order to generate this origin tarball on the fly so you do not get bothered by:
This package has a Debian revision number but there does not seem to be
an appropriate original tar file or .orig directory in the parent directory;
for a start, I added a makefile to the project:
# Makefile
VERSION:=$(shell dpkg-parsechangelog -S Version | sed -rne 's,([^-\+]+)+(\+dfsg)*.*,\1,p'i)
UPSTREAM_PACKAGE:=click_${VERSION}.orig.tar.gz
dpkg:
tar cafv ../${UPSTREAM_PACKAGE} . --exclude debian --exclude .git
debuild -uc -us
clean:
rm -f ../${UPSTREAM_PACKAGE}
debuild clean
so a simple make clean dpkg was all it needed to build the package.
Now I think the question remains if someone has some bright idea how to insert the tar operation within the debian/rules so I could just call debuild -uc -us and it magically creates the orig tarball I would be awsome :)
I have to migrate software suite called Rivermuse from CentOS5 to CentOS6. The README file suggest the following steps:
Directory setup:
mkdir GNUbuild rpmbuild archive
rpmdev-setuptree
Build:
autoreconf -vfi
./configure
make dist-rpm
make createrepo
The following error occurs during step 3 of the build process:
Processing files: angara-perl-Omosd-4.2.2-9.el6.i386
error: File not found: /home/cas/sandbox/rpmbuild/BUILDROOT/angara-4.2.2-9.el6.i386/usr/src
error: File not found: /home/cas/sandbox/rpmbuild/BUILDROOT/angara-4.2.2-9.el6.i386/usr/lib/debug
error: File not found: /home/cas/sandbox/rpmbuild/BUILDROOT/angara-4.2.2-9.el6.i386/usr/share/man/man3/Omosd.3pm.gz
The BUILDROOT directory does not get generated or used in the build process on CentOS5. The online sources we've come across (such as the Fedora RPM guide) haven't been very useful for our specific case.
Any advice will be much appreciated.
Thanks
I eventually figured this out by going through the .spec files.
In the angara.spec file there was an if statement that evaluated whether the OS was fedora or Redhat. I modified this if statement to always run the fedora section, since fedora is redhat's upstream counterpart and a newer version of redhat/centos would have incorporated what was originally only available in fedora, and necessitated the if statement in the first place. I also had to comment out the following:
%exclude /usr/src
%exclude /usr/lib/debug
And I had to add the following just below the lines mentioned above:
/usr/local/share/perl5/Omosd.pm.conf
/usr/local/lib64/perl5/auto/Omosd/.packlist
/usr/local/share/perl5/Omosd.pm.in
I guess this info will only be applicable to rivermuse users, hopefully someone finds this useful..
Recently I downloaded a file using the following link
git clone git://github.com/mapserver/mapcache.git
Inside the downloaded mapcache folder I can not find a configure file to do "./configure". But the installation help file tell:
Unix compilation instructions
If you are using a git clone rather than a tarball distribution, you
must first run autoconf in the root directory, to create the configure
file from configure.in:
$ autoconf
For unix users, the compilation process should resume to:
$ ./configure
$ make
(as root)
make install-module
The installation script takes care of putting the built module in the
apache module directory.
To do ./configure there should be a configure file isn't it? Please show me how to make one to get rid of this problem.
maintainer speaking ...
mapcache and mapserver are switching to cmake for the next release and the docs for the master branch need updating. You can either use the branch-1-0 branch to continue using autoconf builds, or use cmake with master:
$ mkdir build
$ cd build
$ cmake ..
$ make
$ sudo make install
The help file tells you exactly what you need to do
If you are using a git clone rather than a tarball distribution, you must first run autoconf in the root directory, to create the configure file from configure.in
If you don't already have autoconf installed you'll need to install it in the normal way for your distribution.
The repository seems out of sync with the documentation
there is no configure.in as mentioned in the INSTALL file (nowhere not only in the root directory)
there is just a Makefile.vc file for MSVC++
You should contact the maintainer