TipsAndTricks/OnTargetWorkFlowLeveragingRPMPackagefeeds - Revision history

Bavery: /* Ways to Serve up the rpm repo */

2017-09-20T18:24:45Z

Ways to Serve up the rpm repo

← Older revision		Revision as of 18:24, 20 September 2017
Line 113:		Line 113:
	**** From this you can see I run emacs. The only change I did was to turn on directory listing .		**** From this you can see I run emacs. The only change I did was to turn on directory listing .
	**** diff lighttpd.conf lighttpd.conf~		**** diff lighttpd.conf lighttpd.conf~
	***** <code> 114c114		***** <code>
			114c114
	< dir-listing.activate = "enable"		< dir-listing.activate = "enable"
	---		---

Bavery: /* Ways to Serve up the rpm repo */

2017-09-20T18:24:05Z

Ways to Serve up the rpm repo

← Older revision		Revision as of 18:24, 20 September 2017
Line 89:		Line 89:
	* very simple - use python twistd.		* very simple - use python twistd.
	** let's suppose you have an rpm repo on the host that is in dir /home/me/mrrepo.		** let's suppose you have an rpm repo on the host that is in dir /home/me/mrrepo.
	** <code > cd /home/me/mrrepo;		** <code >
			cd /home/me/mrrepo;
	twistd -n web --path . -p 5678		twistd -n web --path . -p 5678
	</code>		</code>

Bavery: /* Ways to Serve up the rpm repo */

2017-09-20T18:23:53Z

Ways to Serve up the rpm repo

← Older revision		Revision as of 18:23, 20 September 2017
Line 93:		Line 93:
	</code>		</code>
	** similarly, if you are just serving up the build directories rpm's you can just do		** similarly, if you are just serving up the build directories rpm's you can just do
	*** <code > cd /home/me/mrrepo;		*** <code >
			cd /home/me/mrrepo;
	twistd -n web --path tmp/deploy/rpm -p 5678		twistd -n web --path tmp/deploy/rpm -p 5678
	</code>		</code>

Bavery at 18:23, 20 September 2017

2017-09-20T18:23:32Z

← Older revision		Revision as of 18:23, 20 September 2017
Line 84:		Line 84:
	Target ->		Target ->
	# dnf install zile		# dnf install zile

			== Ways to Serve up the rpm repo ==

			* very simple - use python twistd.
			** let's suppose you have an rpm repo on the host that is in dir /home/me/mrrepo.
			** <code > cd /home/me/mrrepo;
			twistd -n web --path . -p 5678
			</code>
			** similarly, if you are just serving up the build directories rpm's you can just do
			*** <code > cd /home/me/mrrepo;
			twistd -n web --path tmp/deploy/rpm -p 5678
			</code>
			*** Note , only 1 process can own a given port.
			* less simple, but better response and better stability- use lighthttpd.
			** I advocate using this from a container as it is simpler to maintain.
			** <code>
			docker run -it --rm --name user-rpm-server -v /home/me/mrrepo:/var/www/localhost/htdocs -v /home/me/lighttpd:/etc/lighttpd -p 5678:80 sebp/lighttpd
			</code>
			** What goes in /home/me/lighttpd? the config for the lighthttpd container you are running.
			** Where did they come from? Copied from inside the container
			*** <code> docker run -it --rm --user=root --entrypoint=/bin/sh -v /home/me/lighttpd:/frog sebp/lighttpd </code>
			*** <code> # cp -a /etc/lighttpd/* /frog </code>
			*** Now your /home/me/lightppd has the necessary config files.
			** The files in /home/me/lighthttpd:
			*** lighttpd.conf lighttpd.conf~ mime-types.conf mod_cgi.conf mod_fastcgi.conf mod_fastcgi_fpm.conf
			**** From this you can see I run emacs. The only change I did was to turn on directory listing .
			**** diff lighttpd.conf lighttpd.conf~
			***** <code> 114c114
			< dir-listing.activate = "enable"
			---
			> # dir-listing.activate = "enable"
			</code>

			** the -p 5678:80 exposes the default port the container runs it's service (aka 80) on to the host port 5678.

Bavery at 02:08, 18 July 2017

2017-07-18T02:08:00Z

← Older revision		Revision as of 02:08, 18 July 2017
Line 7:		Line 7:
	* It's typically easies to make an image that has most of what you think you'll need. In this example, I added the following to my local.conf:		* It's typically easies to make an image that has most of what you think you'll need. In this example, I added the following to my local.conf:
	EXTRA_IMAGE_FEATURES += " ssh-server-openssh package-management dev-pkgs tools-sdk tools-debug tools-profile "		EXTRA_IMAGE_FEATURES += " ssh-server-openssh package-management dev-pkgs tools-sdk tools-debug tools-profile "
	* Now I'll grab the src code we will try to build		* Now I'll grab the src code we will try to build <strong>Note: this is an ON TARGET build</strong> the build host side is just for the dependencies...
	git clone https://github.com/znc/znc.git		git clone https://github.com/znc/znc.git
	cd znc		cd znc

Bavery at 15:44, 8 July 2017

2017-07-08T15:44:38Z

← Older revision		Revision as of 15:44, 8 July 2017
Line 1:		Line 1:
	= Leveraging Pkg Feeds or How I got Tired of Burning Images =		= Leveraging Pkg Feeds or How I got Tired of Burning Images =
	I was trying to build a sw repo on target and found that I lacked many of the tools and libraries in order to accomplish this. I tend to do this first, if I want to make a recipe from scratch for software that I am not too familiar with. This way, I can follow the instructions for building w/o reinterpretation, verify that I have or can build the necessary dependencies, and check that the sw works properly; all before diving into recipes. I have found reflashing and rebooting the image on the target to be quite slow. Luckily YP supports a much better workflow for this process.		I was trying to build a sw repo on target and found that I lacked many of the tools and libraries in order to accomplish this. I tend to do this first, if I want to make a recipe from scratch for software that I am not too familiar with. This way, I can follow the instructions for building w/o reinterpretation, verify that I have or can build the necessary dependencies, and check that the sw works properly; all before diving into recipes. I have found reflashing and rebooting the image on the target to be quite slow. Luckily YP supports a much better workflow for this process.
			<strong> Note: This works as well with kernel modules as it does with libraries/binaries</strong>
	<br>		<br>
	In this example, we will be building znc 1.6.5, an irc bouncer. This is just a good complex example. In order to use this guide, you should set up your bitbake environment and your target as outlined in [https://wiki.yoctoproject.org/wiki/TipsAndTricks/EnablingAPackageFeed#Easiest_Way PkgFeeds the EasiestWay]		In this example, we will be building znc 1.6.5, an irc bouncer. This is just a good complex example. In order to use this guide, you should set up your bitbake environment and your target as outlined in [https://wiki.yoctoproject.org/wiki/TipsAndTricks/EnablingAPackageFeed#Easiest_Way PkgFeeds the EasiestWay]

Bavery at 01:17, 8 July 2017

2017-07-08T01:17:20Z

← Older revision		Revision as of 01:17, 8 July 2017
Line 25:		Line 25:
	* target side, pull in the new package. Since I am building stuff, I need the -dev pkg for configure to be happy.		* target side, pull in the new package. Since I am building stuff, I need the -dev pkg for configure to be happy.
	$dnf install cyrus-sasl-dev (note this will also pull in the cyrus-sasl rpm as a dependency.)		$dnf install cyrus-sasl-dev (note this will also pull in the cyrus-sasl rpm as a dependency.)
	If this fails, make sure you followed the instructions in https://wiki.yoctoproject.org/wiki/TipsAndTricks/EnablingAPackageFeed#Easiest_Way PkgFeeds the EasiestWay]. You should have set up the on target repo in /etc/yum.repos.d/myrepo.repo and have a web server of some type pointed to tmp/deploy/rpm (like twistd -n web --path tmp/deploy/rpm -p 5678) on your build host.		If this fails, make sure you followed the instructions in [https://wiki.yoctoproject.org/wiki/TipsAndTricks/EnablingAPackageFeed#Easiest_Way PkgFeeds the EasiestWay]. You should have set up the on target repo in /etc/yum.repos.d/myrepo.repo and have a web server of some type pointed to tmp/deploy/rpm (like twistd -n web --path tmp/deploy/rpm -p 5678) on your build host.
	* now we rerun configure and get:		* now we rerun configure and get:
	./configure --enable-cyrus		./configure --enable-cyrus

Bavery at 01:16, 8 July 2017

2017-07-08T01:16:49Z

← Older revision		Revision as of 01:16, 8 July 2017
Line 25:		Line 25:
	* target side, pull in the new package. Since I am building stuff, I need the -dev pkg for configure to be happy.		* target side, pull in the new package. Since I am building stuff, I need the -dev pkg for configure to be happy.
	$dnf install cyrus-sasl-dev (note this will also pull in the cyrus-sasl rpm as a dependency.)		$dnf install cyrus-sasl-dev (note this will also pull in the cyrus-sasl rpm as a dependency.)
			If this fails, make sure you followed the instructions in https://wiki.yoctoproject.org/wiki/TipsAndTricks/EnablingAPackageFeed#Easiest_Way PkgFeeds the EasiestWay]. You should have set up the on target repo in /etc/yum.repos.d/myrepo.repo and have a web server of some type pointed to tmp/deploy/rpm (like twistd -n web --path tmp/deploy/rpm -p 5678) on your build host.
	* now we rerun configure and get:		* now we rerun configure and get:
	./configure --enable-cyrus		./configure --enable-cyrus

Bavery: /* Leveraging Pkg Feeds or How I got Tired of Burning Images */

2017-07-08T01:11:35Z

Leveraging Pkg Feeds or How I got Tired of Burning Images

← Older revision		Revision as of 01:11, 8 July 2017
Line 1:		Line 1:
	= Leveraging Pkg Feeds or How I got Tired of Burning Images =		= Leveraging Pkg Feeds or How I got Tired of Burning Images =
	I was trying to build a sw repo on target and found that I lacked many of the tools and libraries in order to accomplish this. I found reflashing and rebooting the image on the target to be quite slow. Luckily YP supports a much better workflow for this process.		I was trying to build a sw repo on target and found that I lacked many of the tools and libraries in order to accomplish this. I tend to do this first, if I want to make a recipe from scratch for software that I am not too familiar with. This way, I can follow the instructions for building w/o reinterpretation, verify that I have or can build the necessary dependencies, and check that the sw works properly; all before diving into recipes. I have found reflashing and rebooting the image on the target to be quite slow. Luckily YP supports a much better workflow for this process.
	<br>		<br>
	In this example, we will be building znc 1.6.5, an irc bouncer. This is just a good complex example. In order to use this guide, you should set up your bitbake environment and your target as outlined in [https://wiki.yoctoproject.org/wiki/TipsAndTricks/EnablingAPackageFeed#Easiest_Way PkgFeeds the EasiestWay]		In this example, we will be building znc 1.6.5, an irc bouncer. This is just a good complex example. In order to use this guide, you should set up your bitbake environment and your target as outlined in [https://wiki.yoctoproject.org/wiki/TipsAndTricks/EnablingAPackageFeed#Easiest_Way PkgFeeds the EasiestWay]

Bavery at 01:09, 8 July 2017

2017-07-08T01:09:45Z

@@ Line 44: / Line 44: @@
 Pretty Easy, you can see how this cycle may be repeated a number of times for more complex projects.
 * I prefer emacs, so I tend to to this a lot as zile is a small emacs analogue:
-  bitbake zile
+  $ bitbake zile
-  bitbake package-index
+  $ bitbake package-index
 Target ->
-  $ dnf install zile
+  # dnf install zile