Debian's devscripts suite has dch tool which allow to add new version to debian/changelog file.
When I add new version I make this:
package (1.0.2-1myname1-ubuntu0) UNRELEASED; urgency=medium
*
-- signature and date
package (1.0.2-1myname1) unstable; urgency=medium
* old changes
-- signature and date
If version ends on 'ubuntu' it bumped properly (ubuntu1, ubuntu2, etc), and when I use my own suite, it just append 'ubuntu'.
Where dch take sting 'ubuntu' to add to version?
That string is coming from the dpkg-vendor command. You can control it at least with the DEB_VENDOR environment variable, via the DEBCHANGE_VENDOR devscripts configuration option or the dch/debchange command-line --vendor option.
For more information please check the respective man pages.
Related
I need to configure WireGuard to bring up a VPN on boot on an Embedded Linux device.
My recipe installs a /etc/wireguard/wg0.conf pretty much like the examples found through the Internet.
Then I try to enable the service on SystemD like this on my wireguard.bb:
SYSTEMD_SERVICE = "wg-quick#wg0.service"
SYSTEMD_AUTO_ENABLE = "enable"
But bitbake throws me an error:
ERROR: Function failed: SYSTEMD_SERVICE_my-conf value wg-quick#wg0.service does not exist
I checked the temporary directory and file wg0.conf appears in the correct places but it seems that bitbake's SYSTEMD_SERVICE doesn't know how to expand the "wg0" after # sign.
If I try without the interface name (wg0):
SYSTEMD_SERVICE = "wg-quick#.service"
Bitbake is happy and finalizes my recipe, but it is not what systemd is expecting. Starting a service without an interface makes no sense...
Then I tried another approach and split the "wireguard" package itself from the configuration ("wireguard-conf" package) and added DEPENDS and RDEPENDS on "wireguard".
This got even worse since my wireguard-conf.bb recipe does not contain a "wg-quick#.service" file (it comes from the dependency "wireguard").
Well,
I don't know how to properly fix it and any suggestions will be highly appreciated.
Additional Info
I am using Yocto 2.0.3 in this project (with no hope of updating it).
Thanks to #TomasNovotny comments I managed to compare my "systemd.bbclas" against Github and noticed a change in systemd_populate_packages() that seems to solve the problem.
It works in newer OpenEmbedded (looks like in krogoth, version 2.1 released Apr 2016) and it is introduced by this commit. It works for me in rocko (version 2.4 released Oct 2017). According to j4x's comment, it doesn't work in jethro (version 2.0, Nov 2015).
For older (and currently unsupported OpenEmbeddeds) you can try to backport the patch or handle the symlinks for enabling the service in do_install().
Also please note that SYSTEMD_SERVICE_${PN} variable is package specific, so the _${PN} suffix has to be added (see manual).
I've also tried to enable OpenVPN with my profile (in Yocto rocko) without success.
Finally, I've made it working by providing OpenVPN recipe extension instead of custom one. So, the openvpn_%.bbappend file looks like:
inherit systemd
SYSTEMD_SERVICE_${PN} = "openvpn#clientprofile.service"
SYSTEMD_AUTO_ENABLE = "enable"
do_install_append() {
install -d ${D}${sysconfdir}/openvpn/
ln -sf /data/etc/openvpn/clientprofile.conf ${D}${sysconfdir}/openvpn/clientprofile.conf
}
As you can see, I'm using a symlink to my profile instead of the normal file. You can install a normal OpenVPN profile file instead of making symlink and it also works fine.
The Battlestar Galactica here
http://kickasstorrentsan.com/usearch/Battlestar%20Galactica/
can be downloaded with deluge.
Now i scrap the magnet with firebug on the web page.
It can be verified that the magnet is :
magnet:?xt=urn:btih:2D2CAE6AC83800490327547053597BAFF6701C2F&dn=battlestar+galactica+season+1+s01+1080p+bluray+x265+hevc+aac+5+1+joy+utr&tr=udp%3A%2F%2Ftracker.publicbt.com%2Fannounce&tr=udp%3A%2F%2Fglotorrents.pw%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce
The bash script were written as following:
1.the $url variable is right address for magnet.
2.aria2c command can be executed correctly.
3.aria2c $url has beeen executed for about one hour.Why nothing can be dowlonaded?
This page says, you need to enable DHT option while downloading using magnet-links:-
This official documentation page says, it is enabled by default from version 1.25.0
--enable-dht[=true|false]
Enable IPv4 DHT functionality. It also enables UDP tracker support. If a private flag is set in a torrent, aria2 doesn't use DHT for that download even if true is given. Default: true
Checked the release notes from GitHub, couldn't find the exact release since the flag --enable-dht has been made to true.
Upgrade to the latest version to have the flag enabled by default (or) enable it explicitly if you are using an older version.
aria2c --enable-dht=true "magnet:?xt=urn:btih:2D2CAE6AC83800490327547053597BAFF6701C2F&dn=battlestar+galactica+season+1+s01+1080p+bluray+x265+hevc+aac+5+1+joy+utr&tr=udp%3A%2F%2Ftracker.publicbt.com%2Fannounce&tr=udp%3A%2F%2Fglotorrents.pw%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce"
I'm running the configure.ac on RHEL 7.2, I'm wondering if there's a way to set the Release number (which is defined om the spec file) as a variable like the Version number which is being generated by the configure.ac and it's written to the config.h file , I'd like to set a kind of BUILD_NUMBER variable somewhere, and it'll take the value of the exported variable during the execution.
The release number for an RPM package is set by the Release: tag in the spec-file. Some spec-files are generated, e.g., using autoconf to substitute values such as the release number in a template, e.g., mypackage.spec.in, to obtain mypackage.spec
A quick check of wireshark's source shows that it uses this scheme, but its template hardcodes the release number as 1. You could modify the configure script and template to add your own option.
For example, adapting the style of --with-XXX options used in the wireshark 2.0.1 configure.ac, you would add a chunk like this (untested):
AC_ARG_WITH([release],
AC_HELP_STRING( [--with-release=#<:#1/no/4/5#:>#],
[set release-number in package #<:#default=1#:>#]),
with_release="$withval", with_release="unspecified")
case "x$with_release" in
x[[1-9]]*)
RELEASE="$with_release"
;;
*)
AC_MSG_ERROR(release is not a number: $with_release)
;;
esac
AC_SUBST(RELEASE)
and use the RELEASE variable in packaging/rpm/SPECS/wireshark.spec.in, as you see the VERSION value used:
Release: #RELEASE#
Alternatively, if you are using the wireshark source without modifying it directly, your build script could
unpack the sources,
update the spec-file,
repack the tarball,
deploy the updated tarball to your build area
Either way, you would have to do some work.
I require installing ruby without internet access. As ruby-build docs suggest I can change the mirror URL via specifying the environment variable RUBY_BUILD_MIRROR_URL. I did this and although it looks at my local repo for ruby it still attempts to connect to online repo to install yaml.
env RUBY_BUILD_MIRROR_URL=http://10.10.161.39/platforms/common/ruby-2.0.0-p247.tar.gz#3e71042872c77726409460e8647a2f304083a15ae0defe90d8000a69917e20d3 /opt/rbenv/bin/rbenv install 2.0.0-p247
Downloading yaml-0.1.6.tar.gz...
-> http://10.152.161.39/platforms/proteus/common/ruby-2.0.0-p247.tar.gz#3e71042872c77726409460e8647a2f304083a15ae0defe90d8000a69917e20d3/7da6971b4bd08a986dd2a61353bc422362bd0edcc67d7ebaac68c95f74182749
-> http://pyyaml.org/download/libyaml/yaml-0.1.6.tar.gz
error: failed to download yaml-0.1.6.tar.gz
BUILD FAILED (RedHatEnterpriseServer 5.10 using ruby-build 20150928)
I tried placing the yaml-0.1.6.tar.gz file in my local repo however that makes no difference besides it will fail since the sha2 checksum provided in the URL is for ruby-2.0.0-p247.tar.gz file.
How can install ruby offline with rbenv?
Update 1
I discovered that you can modify the lookup config file to point to a local mirror instead. i.e: /opt/rbenv/plugins/ruby-build/share/ruby-build/2.0.0-p247
install_package "yaml-0.1.6" "http://10.10.161.39/platforms/common/yaml-0.1.6.tar.gz#7da6971b4bd08a986dd2a61353bc422362bd0edcc67d7ebaac68c95f74182749" --if needs_yaml
install_package "openssl-1.0.1p" "ttp://10.10.161.39/platforms/common/openssl-1.0.1p.tar.gz#bd5ee6803165c0fb60bbecbacacf244f1f90d2aa0d71353af610c29121e9b2f1" mac_openssl --if has_broken_mac_openssl
install_package "ruby-2.0.0-p247" "http://10.10.161.39/platforms/common/ruby-2.0.0-p247.tar.gz#3e71042872c77726409460e8647a2f304083a15ae0defe90d8000a69917e20d3"
Is there a better way or is this is the best way forward?
So here's how I got it to work:
Update the contents of the download file in /opt/rbenv/plugins/ruby-build/share/ruby-build/<ruby-version> to point to your local repo.
You will also notice how each file has a long hash valued after the '#' symbol in the URL. For Example:
install_package "yaml-0.1.6" "http://10.10.161.39/platforms/common/yaml-0.1.6.tar.gz#7da6971b4bd08a986dd2a61353bc422362bd0edcc67d7ebaac68c95f74182749" --if needs_yaml
This hash value is the sha256sum the file which rbenv will use to validate if it is the expected file.
So you will need to generate the value by running sha256sum <filename> and appending to each file in the URL path.
Complete example below:
install_package "yaml-0.1.6" "http://10.10.161.39/platforms/common/yaml-0.1.6.tar.gz#7da6971b4bd08a986dd2a61353bc422362bd0edcc67d7ebaac68c95f74182749" --if needs_yaml
install_package "openssl-1.0.1p" "ttp://10.10.161.39/platforms/common/openssl-1.0.1p.tar.gz#bd5ee6803165c0fb60bbecbacacf244f1f90d2aa0d71353af610c29121e9b2f1" mac_openssl --if has_broken_mac_openssl
install_package "ruby-2.0.0-p247" "http://10.10.161.39/platforms/common/ruby-2.0.0-p247.tar.gz#3e71042872c77726409460e8647a2f304083a15ae0defe90d8000a69917e20d3"
In the example above we have a dedicated repository server at http://10.10.161.39/platforms/common. If your packages are locally available, you will need to point to the local path and verify if it works.
Can phpDocumentor be used to generate HTML docs for some legacy code that does not necessarily conform to its standard?
I'd like to generate some preliminary documentation for an old code tree and later on start improving my comments and add the appropriate # tags as I get fluent with phpDocumentor. I've never used this piece of software before and the examples I've found focus on how to write new code that conforms to its syntax and generate HTML file by file with the -f parameter.
I've installed latest phpDocumentor through the PEAR command line installer and tried this little *.bat file on Windows XP:
#echo off
phpdoc ^
--directory "\\server\project\trunk" ^
--target "C:\tests\project-doc"
... but this is all I get:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
directory: '' not found
I've also tried mapping the UNC path to a drive letter:
#echo off
phpdoc ^
--directory "I:\" ^
--target "C:\tests\project-doc"
... but:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
a target directory must be specified
try phpdoc -h
This error message is the same if I create "C:\tests\project-doc" before.
What's exactly wrong in my syntax?
phpDocumentor can indeed run against "undocumented" code. It builds its docs based on the code itself, and uses the docblocks as additional info (and additional organization, in the case of #package and #subpackage tags).
I'd suggest starting with phpDocumentor against your existing code, and work towards clearing out the warnings you see in the errors.html file that results -- this file is generated in the top level of your output docs, but there isn't any link to it from the output docs.
Once you have those cleared, you can start running phpDocumentor with the -ue argument (--undocumentedelements), which will add new warnings to errors.html, highlighting (in much greater detail) things that still need to be documented in docblocks.
Now, as for the issue you're having trying to run the program against code on a shared drive, I'm not sure what's wrong there. The script is clearly able to execute PHP and find the phpDocumentor code itself. You might try putting the arguments in the same line, rather than using the ^ as a line-feed escape character, and perhaps remove the quotes around the paths (since no spaces exist in the paths).
I think I've found what the issue is. The parameter parser is very picky and it doesn't like neither UNC paths nor bare root directories. If I replace this:
--directory "I:\"
... with this:
--directory "I:\."
... it finally starts running.
I suppose it's a bug. Their bug tracker doesn't seem to be public so I don't know if it's a known issue.