I'm using autoconf & automake in a C project. I'd like to create a .deb package, so I have the following control.in file:
Source: myproject
Section: misc
Priority: optional
Maintainer: Paul Walker <pwalk#test.it>
Build-Depends: debhelper (>=9), autotools-dev#MORE_DEPENDENCIES#
Standards-Version: 1.0.0
Homepage: https://www.my-website.it/
...
I'd like to configure this file with autoconf since there might be MORE_DEPENDENCIES according to some configure-time flag I did set.
This control.in file sits in a stubs/ folder, after substituting the MORE_DEPENDENCIES variable, I'd also like to copy the resulting control file into the final destination folder debian/ to create the .deb package.
So essentially I'm trying to have autoconf do the following:
Include {srcdir}/stubs/ as input folder in order to substitute macros in the .in file sitting there
Configure the stub {srcdir}/stubs/control.in, substitute whatever macro is in there, generate the file {srcdir}/stubs/control with substituted macros
Copy {srcdir}/stubs/control into the final destination folder {srcdir}/debian/control
I've been looking for examples or in the official documentation but still can't find how to configure a .in file outside of the root source folder.
Regarding 'how to copy the final file to the debian/ folder' I suppose I could use a symlink ? Is there any better way?
This is a top-of-the-foodchain problem.
The Debian packaging tools are designed to be the top-level tool for building Debian packages, and the control file is supposed to stay unchanged for the entire run of a package build. You can probably fudge your way around that if you only wish to build binary packages, but then there would be no point in modifying the build dependencies because they are evaluated earlier.
The normal build process will distclean the build tree in order to record changes in the source package, then rerun configure and build. If you update debian/control at this point, the results are undefined.
If you have to update debian/control programmatically, use a separate mechanism that is not reachable from the regular package build. If you have regular releases rather than cutting packages from development versions, it might even make more sense to treat the packaging as separate.
I just tried to build the Yocto core-image-minimal and was not able to change the keyboard layout using "loadkeys de".
So I googled a bit and found, that I have to add "kbd-keymaps" to IMAGE_INSTALL_append. Then it worked perfectly fine.
Afterwards I found https://layers.openembedded.org/layerindex/branch/master/recipes/ and saw that the package is not listed there.
Instead I only found just "kbd" and just "keymaps" as separate packages. But when only installing these instead of kbd-keymaps, "loadkeys de" did not work. kbd was installed then but NOT the accordant keymaps under "usr/share/keymaps".
So my question is: Where are such packages like "kbd-keymaps" officially listed? (Google only shows forum entries of experienced users knowing about that package name and on the kbd project page I also didn't find anything about the keymaps package)
Look at
http://layers.openembedded.org/layerindex/recipe/595/
A recipe is set of input rules to build a package, which can however generate different output packages for keeping the install size small the output artifacts may be bundled into different ipk/rpm output packages. So in this case input recipe is 'kbd' so when building you would do
bitbake kbd
but then when adding what you need into image you have to add the names of output packages generated from build. Hopefully that explains the crucial difference between recipe and package, what you add into IMAGE_INSTALL is name of output package. So in this case you will still add
IMAGE_INSTALL_append = " kbd-keymaps"
this would result in building kbd recipe and the use the kbd-keymaps package ( ipk/rpm/deb ) from it.
Hope that helps.
You can also use oe-pkgdata-util utility to inspect the recipes and packages.
How can I install a sublimetext3 package manually, without the package control. I am trying to fix a bug in an existing package, therefore I need a way to test my changes.
what are the naming conventions to be followed when naming the zip file?
Where do I place it?
what other configurations I have to do?
Download the ZIP, and then place it in your Packages directory which can be found by doing Sublime Text -> Preferences -> Browse Packages...
what are the naming conventions to be followed when naming the zip file? Where do I place it? what other configurations I have to do?
This really depends on the specific package you are downloading. For some packages, you can name it whatever you want. For others, the name has to be exact. If you are downloading these packages manually from GitHub, I urge you to read the documentation in the README. They usually provide instructions for manual installation. For example, if you wanted to download the Spacegray theme manually, it tells you to download the ZIP, unzip the folder, and rename it to Theme - Spacegray.
Depending on your OS, your package directory might be one of these and for most of the packages, just extract the content to this folder (with it's root folder as the name)
Linux: ~/.config/sublime-text-3/Packages
OS X: ~/Library/Application Support/Subime Text 3/Packages
Windows: %APPDATA%\\Sublime Text 3
I am trying to fix a bug in an existing package, therefore I need a
way to test my changes.
I was in the same situation. The accepted answer didn't work for me because Package Control would automatically remove the folder. I found this to be helpful:
https://packagecontrol.io/docs/customizing_packages
Sublime Text 3 offers the most options for overriding a package. By
default, packages will be installed by placing a .sublime-package file
in the Install Packages/ folder. Then users may override individual
files in the package by creating a folder Packages/{Package Name}/ and
placing edited files in there.
Another approach is PackageResourceViewer, which allows you to extract and override individual files from packages, including the built-in packages.
The best answer I think, so far, is this one by #Andreas Haferburg.
The most-upvoted answer also has some really useful information, such as the link to the spacegray package which states:
Manual
You can also install the theme manually:
Download the .zip
Unzip and rename the folder to Theme - Spacegray
Copy the folder into Packages directory, which you can find using the menu item Sublime Text -> Preferences -> Browse Packages...
That is where I first learned about the existence of the Packages folder and how to find its path.
Using those answers together, plus putting in about 1 weekend worth of work into learning about how Sublime Text packages and syntax highlighting work, I wrote the following "Developer Notes & Package Development Tutorial", on GitHub, as well as these "manual installation" instructions.
In short, to "install a package" withOUT Package Control, all you need to do is put the package into your Sublime Text Packages folder, whose path can be found by going to Preferences --> Browse Packages.... The folder name can be anything. It only needs to match what is inside the Installed Packages dir (which is at the same level as the Packages dir) if you want to override an already-installed package which was previously installed by Package Control in "packed" (zip file) format.
The main link you should study, aside from my tutorial, is this: https://packagecontrol.io/docs/customizing_packages.
1. How to manually install a package
Here are some of the key quotes and instructions from my manual installation instructions and tutorial.
Again, note that I am only requiring that the name in the Packages folder be something specific like gcode in the instructions below because my instructions are intended to override a Package-Control-installed package the reader may already have installed. If you want to install for the first time, or make a new package, the folder name you use inside the Packages folder can be anything.
2. Manual installation
In Sublime Text, find the path to your Packages folder by clicking Preferences --> Browse Packages.... This will open up your GUI file manager to the path where Sublime Text packages are stored. For me on Linux Ubuntu 20.04, that's /home/gabriel/.config/sublime-text-3/Packages (even though I am running Sublime Text 4).
Now, extract this package to that folder.
Option 1: the GUI way: click the green "Code" button above --> "Download ZIP" --> save the zip file, extract it to your Packages path above, and rename it to gcode.
OR Option 2 [what I prefer]: the command-line way:
# --------------
# Option 2.A: clone the repo directly into your "Packages" dir
# --------------
# cd to the Packages dir (change this path according to your Packages path above)
cd "$HOME/.config/sublime-text-3/Packages"
# clone the repo
git clone https://github.com/ElectricRCAircraftGuy/sublime_gcode.git
# rename the repo dir to "gcode"
mv sublime_gcode gcode
# --------------
# OR Option 2.B [what I prefer]: clone the repo into wherever you want, and then
# symlink it into your "Packages" dir
# --------------
# clone repo into ~/dev
mkdir -p ~/dev
cd ~/dev
git clone https://github.com/ElectricRCAircraftGuy/sublime_gcode.git
# now symlink it into your Packages dir
ln -si ~/dev/sublime_gcode ~/.config/sublime-text-3/Packages/gcode
That's it! The gcode entry is now instantly available in your syntax highlighting menu.
Developer Notes & Package Development Tutorial
...
...
...
Sublime Text packages and syntax highlighting--how it all works
And here are some really important notes about Sublime Text packages and how Package Control works:
1. Sublime Text packages
Any folder inside of your Sublime Text Packages folder (found via Preferences --> Browse Packages...) is automatically instantly loaded by Sublime Text as a "package".
Packages installed by the Package Control package, however, come in two types:
Packed: most packages installed by Package Control are "packed" into a zip file named packageName.sublime-package and are located inside the Installed Packages dir which is at the same level as the Packages dir.
If you manually create a dir inside the Packages dir and name it packageName (to match the packed file above), then any files in it with the same name as those in the packed package will override those in the packed package. See the "Overrides" section here: https://packagecontrol.io/docs/customizing_packages.
Unpacked: any package which is installed in the Packages dir is unpacked.
Developers can tell Package Control to unpack a package installed by Package Control by placing a file named .no-sublime-package at the root of their repo. See here: https://packagecontrol.io/docs/submitting_a_package.
Unpacked packages are required if they contain binary executables which need to be run by the system, for instance, as they apparently can't run from inside the packed zip file.
2. Syntax highlighting
Hopefully I got all of this straight.
If you want to learn more about Syntax Highlighting in Sublime Text, and how it maps to scope entries in your Color Scheme, read my tutorial.
2. Test your changes
I am trying to fix a bug in an existing package, therefore I need a way to test my changes.
See also this section in my tutorial:
To modify and test changes to this package locally...
...in case you'd like to change it or contribute to it, follow the "manual installation" instructions above. If you have already installed it via Package Control, then what is in your /home/$USERNAME/.config/sublime-text-3/Packages/gcode folder will override what is in your /home/$USERNAME/.config/sublime-text-3/Installed Packages/gcode.sublime-package zip file which Package Control installed, so long as the folder and file names are the same.
Modify any files in the Packages/gcode dir as desired. Each time you save, the changes will instantly be reflected in all Sublime Text editors you have open. As a quick test:
Open a gcode file.
Click your cursor on some text in the file.
Use the Tools --> Developer --> Show Scope Name trick to see what the scope is for that text.
Open the corresponding *.sublime-syntax file.
Change or delete the regular expression in the match entry for that corresponding scope you just found, so that it no longer matches the text on which you placed your cursor.
Save the *.sublime-syntax file and you will instantly see the formatting of that text in the gcode file change.
Undo your change to the match entry and save again. The formatting will return to how it was.
Go to Preferences --> Customize Color Scheme, and add a custom rules entry for that scope, with new formatting for that scope. Save it and watch the formatting instantly change again. Delete that custom entry when done, if desired.
I am little confused on how to create a complete binary package using rpmbuild from a project I just created (already compiled binary).
my current project contain similar format as this user (Packaging proprietary software for Linux)
Where I have
foo (binary)
data
libs
foo.sh
libs will contain all the shared libraries the project requires, and foo.sh is a script that sets LD_LIBRARY_PATH to include libs. Therefore, the user will execute foo.sh and the program should start.
I am looking at the tutorial from this site (rpm tutorial)
I understand to create a rpm I create a build area use rpmdev-setuptree
I can create a spec file use cd ~/rpmbuild/SPECS; rpmdev-newspec foo and if I got a good SOURCES folder I can build it with rpmbuild -ba foo.spec
But I have no idea how to setup the SOURCES directory. The tutorial stated (here) that I should create a tarball and place all my source file in it and put in SOURCE directory. What would be the source file in my case?
You are trying to create a RPM from binary files you have already? In that case, you can just leave the whole building stuff out of the SPEC file, and you need a SOURCE directory to keep the bundles you've got, the %prep step described below will take them from here.
In a binary package I built a while back from zip files, I did:
Heading, with name, version, description written by me/cribbed from the originals
Sources: The original places to download the Linux packages, official documentation, ...
%prep: Just unpack the different pieces, delete some redundant files, ...
%build: Nothing to do
%install: Create the relevant directories under $RPM_BUILD_ROOT by hand, copy files there by install, copy/create configuration files, ...
%clean: Blow away $RPM_BUILD_ROOT
%files: An exhaustive list of all files installed.
This required a few iterations to get right. Afterwards I followed the upstream package by rebuilding my RPM (conveniently I had everything packaged up in a SRPM, where the Source part was kind of a misnomer...)
In the project pandoc, Paths_pandoc is imported in Shared.hs. Paths_pandoc.hs is located in dist/build/autogen/. How is it generated and what does it do for pandoc.
It's a file that is generated by Cabal.
When you specify Data-files: in your .cabal file for your project, those files will be copied to a good location for "data files" on your system when you run cabal install. On Windows, this might be "C:\Program Files\Something" and on Linux it might be "/usr/share/something" (At least when you do a --system install).
Your code needs to know where the files were copied to, so Cabal generates that special module, which contains variables for the install paths that were used to copy the data files, so that your code can find the installed data files.
The module does also contain other information that Cabal provides for you, but the primary purpose of the module is what I just described.
See this blog post for more information.