Re: [Angstrom-devel] [PATCH meta-ti] genext2fs: Imported from poky
Dear Joel,
thank you for the patch, I have several comments though.
0. Why should that recipe not go into meta-oe?
Am Montag, den 29.08.2011, 19:55 -0500 schrieb Joel A Fernandes:
1. As always the commit summary. In my opinion it is “useless”. Looking
over the history, I am more interested in what version was added.
genext2fs: Add version 1.4.1 (initial recipe)
or
genext2fs: Add version 1.4.1 (import from Poky)
Poky Commit: 8bf2fce59bd78feed260b9465d77a4a3d4c34159
2. Please add a URL so people do not have to search for the repository.
3. Why do you import it from Poky and not oe.dev?
The additional changes should be added by a follow up commit to be able
to see what changed from the import.
Will be used by SD Card creation command (IMAGE_CMD_sdimg)
Signed-off-by: Joel A Fernandes joelag...@ti.com
---
recipes-dev/genext2fs/genext2fs.inc | 16
recipes-dev/genext2fs/genext2fs_1.4.1.bb |6 ++
2 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 recipes-dev/genext2fs/genext2fs.inc
create mode 100644 recipes-dev/genext2fs/genext2fs_1.4.1.bb
diff --git a/recipes-dev/genext2fs/genext2fs.inc
b/recipes-dev/genext2fs/genext2fs.inc
new file mode 100644
index 000..5b5508f
--- /dev/null
+++ b/recipes-dev/genext2fs/genext2fs.inc
@@ -0,0 +1,16 @@
+inherit native
+
+SUMMARY = Ext2 filesystem generation tool
Since when does that variable exist?
+DESCRIPTION = A tool to generate an ext2 filesystem \
+as a normal (non-root) user.
+HOMEPAGE = http://genext2fs.sourceforge.net/;
+SECTION = console/utils
+
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
+
file://genext2fs.c;beginline=9;endline=17;md5=23ea077d1f7fbfd3a6fa573b415fa001
+
+SRC_URI = ${DEBIAN_MIRROR}/main/g/genext2fs/genext2fs_${PV}.orig.tar.gz
Please send a follow up patch changing `SRC_URI` to the official
SourceForge site.
+S = ${WORKDIR}/genext2fs-${PV}
With the change above that would not be needed anymore.
+
+inherit autotools
diff --git a/recipes-dev/genext2fs/genext2fs_1.4.1.bb
b/recipes-dev/genext2fs/genext2fs_1.4.1.bb
new file mode 100644
index 000..9364bb8
--- /dev/null
+++ b/recipes-dev/genext2fs/genext2fs_1.4.1.bb
@@ -0,0 +1,6 @@
+require genext2fs.inc
+
+PR = r0
Please send a follow up patch to introduce `INC_PR`.
+
+SRC_URI[md5sum] = b7b6361bcce2cedff1ae437fadafe53b
+SRC_URI[sha256sum] =
404dbbfa7a86a6c3de8225c8da254d026b17fd288e05cec4df2cc7e1f4feecfc
Thanks,
Paul
[1] http://sourceforge.net/projects/genext2fs/files/
signature.asc
Description: This is a digitally signed message part
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] Narcissus and device nodes
Op 29 aug. 2011, om 15:36 heeft Joel A Fernandes het volgende geschreven: Doesn't Narcissus suffer from mknod errors as the following is run as non-root? http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/narcissus/tree/scripts/assemble-image.sh#n147 If so, what are the effects of not being able to create device nodes in an image and, does udev auto create them during startup? The kernel creates them for you: root@beagleboard:~# zcat /proc/config.gz | grep DEVTMP CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y Is it ok to skip the tar stage and directly copy what's in TARGET_DIR into the fs loopback mount? It seems that, since tar -x is run as non-root anyway, then tarring and untarring is as good as copying in files directly. This would save a stage if a tar is not a desired output (for ex. just an sdcard image is desired) It serves as a sanity test for the tar code ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
[Angstrom-devel] Suggestions for narcissus rewrite
Hi, There are plans to make a rewrite of narcissus (echo) to move more of the processing to javascript (less php and shell). So before starting that, what changes would you like to see? And more importantly, do you want to help out making those changes? regards, Koen ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] Suggestions for narcissus rewrite
Koen Kooi wrote: There are plans to make a rewrite of narcissus (echo) to move more of the processing to javascript (less php and shell). So before starting that, what changes would you like to see? And more importantly, do you want to help out making those changes? Hmm, interesting. So, my suggestions: * Always make clear the revisions of the metadata that were used to build the packages. At the moment it's not always easy to see this information particularly if you are working on the metadata and want to solve a problem seen by a user in the images produced by Narcissus. * Provide not only a rootfs but also links to the kernel and any other applicable files that you got from the OE build. * Link to installation instructions for the machine if available * Use a database or other more configurable source to produce the options for additional packages / package groups to be added to the image - perhaps extract part of this data from the packaging index files? * Have a closer link to the actual package building on the backend (BitBake), so anyone can see when the last set of packages were built or if there is a build currently in progress. * The biggest one: would be nice if it was not dependent on the browser session - i.e. if you close your browser window, refresh at any time, etc. it does not affect the assembly process on the backend - the processing page is just a view into that process. This would require some kind of process pooling on the backend, and either a login or cookie on the frontend to be able to identify users again the next time. The pooling would have the added benefit of being able to better control the number of images being assembled at once. As to whether I can help, I can't make any promises particularly as I have limited experience with Javascript and builting websites, but I'd certainly like to. Cheers, Paul - Paul Eggleton Intel Open Source Technology Centre ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] Suggestions for narcissus rewrite
I'm responding to this specific point now, will address the others later in a seperate mail. Op 30 aug. 2011, om 09:55 heeft Paul Eggleton het volgende geschreven: * Have a closer link to the actual package building on the backend (BitBake), so anyone can see when the last set of packages were built or if there is a build currently in progress. The problem is that narcissus knows nothing about bitbake, it's just a fancy way of 'opkg update ; opkg install foo'. If we continue with that model, we have the following to work with: 1) /etc/angstrom-version: root@beagleboard:~# cat /etc/angstrom-version Angstrom v2011.08-core (Core edition) Built from branch: master Revision: 4816116d9c08c82e38dc5d95a170e2904bfe3786 [1] Target system: arm-angstrom-linux-gnueabi 2) Opkg metadata: koen@dominion:/OE/angstrom-v2011/build/tmp-angstrom-v2011/deploy/eglibc$ dpkg-deb -I ipk/armv7a/libav_0.6.2+r0.2+gitr0+c6c2dfcf15c1d93b2189adff6f71c5c4b6b05338-r0.2.9_armv7a.ipk | grep -e OE -e Build OE: libav Build: org.openembedded.dev/d5e59ef So after building the image we can extract the buildrevs and recipe name for each package[2] and when the last image build was done for said machine. That is pretty much there already: http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/narcissus/tree/scripts/assemble-image.sh#n291 Now, suppose we break with the 'opkg update ; opkg install foo' model and start leveraging sstate we can have a 'toplevel' thing that manages both narcissus options (read: package checkboxes) and autobuilder config (read: list of recipes to build): 1) have an autobuilder build the machine x packages set daily and store info (success, revisions, etc) into a shared db 2) make narcissus pull info from that db when presenting the options. As more hardware becomes available we could even have narcissus add the build to a workqueue for the autobuilder directly. This needs to be considered carefully, since the plain 'opkg install' method is already eating a big chunk of IO. The Oregon instance of narcissus is already using an SSD for the workdir since a spinning disk was too slow for the workload. Have a look at the last 30 days: http://narcissus.angstrom-distribution.org/graph.php?timeframe=30 or the past year for beagleboard: http://narcissus.angstrom-distribution.org/graph.php?timeframe=365machine=beagleboard The images aren't small either: 20110830 06:07:51 akita95M 20110830 07:12:51 beagleboard 30M 20110830 07:40:10 beagleboard 692M 20110830 07:41:26 beagleboard 8.6M 20110830 07:44:43 dm355-leopard31M 20110830 07:49:13 beagleboard 35M 20110830 07:52:26 beagleboard 30M 20110830 07:58:57 beagleboard 322M 20110830 07:59:54 omap3evm 456M 20110830 08:15:41 at91sam9263ek32M 20110830 08:32:13 h220093M 20110830 08:51:20 beagleboard 13M 20110830 08:56:02 beagleboard 258M 20110830 09:02:20 beagleboard 48M With all this info being known and the fact that narcissus will run parallel to echo for the time being, what design should we choose? regards, Koen [1] That rev doesn't exist upstream, the autobuilder has extra patches applied to oe-core (e.g. gst-plugin renaming). This is a seperate problem that needs addressing. [2] in .dev builds, OE-core doesn't have that yet: commit 6ae45bbf2b5ca9e4fd7e8b04e461f0bf120dd44d Author: Koen Kooi koen.k...@gmail.com Date: Tue Dec 21 18:06:06 2010 + package ipk bbclass: store build branch and revision in ipkg metadata The ipkg metadata will look like this now: koen@dominion:/OE/angstrom-dev/deploy/glibc$ dpkg-deb -I ipk/am3517-evm/matrix-gui_1.3-r19.0.6_am3517-evm.ipk new debian package, version 2.0. size 24112 bytes: control archive= 540 bytes. 629 bytes,13 lines control Package: matrix-gui Version: 1.3-r19.0.6 Description: Matrix GUI for Qt X11 Section: multimedia Priority: optional Maintainer: Angstrom Developers angstrom-distro-devel@linuxtogo.org License: BSD Architecture: am3517-evm OE: matrix-gui Homepage: https://gforge.ti.com/gf/project/matrix_gui/ Build: org.openembedded.dev/f35ab2d Depends: matrix-gui-common, libpng12-0, libfreetype6, libz1, libgthread-2.0-0, libqtwebkit4, libphonon4, libqtdbus4, libqtxml4, libqtgui4, libqtnetwork4, libqtcore4, libglib-2.0-0, libc6, libstdc++6, libgcc1 Source: svn://gforge.ti.com/svn/matrix_gui/;module=trunk;proto=https;user=anonymous;pswd='' koen@dominion:/OE/angstrom-dev/deploy/glibc$ Signed-off-by: Koen Kooi k...@openembedded.org Acked-by: Martin Jansa martin.ja...@gmail.com Acked-by: Chase Maupin chase.mau...@ti.com ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] Suggestions for narcissus rewrite
Koen Kooi wrote: Op 30 aug. 2011, om 09:55 heeft Paul Eggleton het volgende geschreven: * Have a closer link to the actual package building on the backend (BitBake), so anyone can see when the last set of packages were built or if there is a build currently in progress. The problem is that narcissus knows nothing about bitbake, it's just a fancy way of 'opkg update ; opkg install foo'. Yes, and I'm not necessarily suggesting a deviation from that. I figured assuming that continues to be the model, it might still be nice to get some more visibility into the actual build process, but no control over it from the web interface. If we continue with that model, we have the following to work with: 1) /etc/angstrom-version: root@beagleboard:~# cat /etc/angstrom-version Angstrom v2011.08-core (Core edition) Built from branch: master Revision: 4816116d9c08c82e38dc5d95a170e2904bfe3786 [1] Target system: arm-angstrom-linux-gnueabi BTW will this revision information be expanded for the OE-core model of multiple metadata repos? Might be ugly but it seems to me the single revision isn't as useful as it was previously. Now, suppose we break with the 'opkg update ; opkg install foo' model and start leveraging sstate we can have a 'toplevel' thing that manages both narcissus options (read: package checkboxes) and autobuilder config (read: list of recipes to build): 1) have an autobuilder build the machine x packages set daily and store info (success, revisions, etc) into a shared db 2) make narcissus pull info from that db when presenting the options. As more hardware becomes available we could even have narcissus add the build to a workqueue for the autobuilder directly. This needs to be considered carefully, since the plain 'opkg install' method is already eating a big chunk of IO. The Oregon instance of narcissus is already using an SSD for the workdir since a spinning disk was too slow for the workload. Have a look at the last 30 days: http://narcissus.angstrom-distribution.org/graph.php?timeframe=30 or the past year for beagleboard: http://narcissus.angstrom-distribution.org/graph.php?timeframe=365machine=beagleboard The images aren't small either: 20110830 06:07:51 akita95M 20110830 07:12:51 beagleboard 30M 20110830 07:40:10 beagleboard 692M 20110830 07:41:26 beagleboard 8.6M 20110830 07:44:43 dm355-leopard31M 20110830 07:49:13 beagleboard 35M 20110830 07:52:26 beagleboard 30M 20110830 07:58:57 beagleboard 322M 20110830 07:59:54 omap3evm 456M 20110830 08:15:41 at91sam9263ek32M 20110830 08:32:13 h220093M 20110830 08:51:20 beagleboard 13M 20110830 08:56:02 beagleboard 258M 20110830 09:02:20 beagleboard 48M With all this info being known and the fact that narcissus will run parallel to echo for the time being, what design should we choose? Well, one thing to consider as well is that it's very likely at some point in the near future that we will be writing a BitBake web-UI within the Yocto Project, and although it has not been designed yet I would expect that to be along similar lines to the hob GTK2+-based UI, at least in terms of the options it allows the user to change. The question is though, in a distro like Angstrom where you've specified quite a lot of policy (preferred versions, features, etc.) that you wouldn't necessarily want to allow the user to configure, does a UI at the BitBake level make sense? Cheers, Paul - Paul Eggleton Intel Open Source Technology Centre ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] Suggestions for narcissus rewrite
Op 30 aug. 2011, om 11:39 heeft Paul Eggleton het volgende geschreven:
Koen Kooi wrote:
Op 30 aug. 2011, om 09:55 heeft Paul Eggleton het volgende geschreven:
* Have a closer link to the actual package building on the backend
(BitBake), so anyone can see when the last set of packages were built or
if there is a build currently in progress.
The problem is that narcissus knows nothing about bitbake, it's just a
fancy way of 'opkg update ; opkg install foo'.
Yes, and I'm not necessarily suggesting a deviation from that. I figured
assuming that continues to be the model, it might still be nice to get
some more visibility into the actual build process, but no control over it
from the web interface.
If we continue with that
model, we have the following to work with:
1) /etc/angstrom-version:
root@beagleboard:~# cat /etc/angstrom-version
Angstrom v2011.08-core (Core edition)
Built from branch: master
Revision: 4816116d9c08c82e38dc5d95a170e2904bfe3786 [1]
Target system: arm-angstrom-linux-gnueabi
BTW will this revision information be expanded for the OE-core model of
multiple metadata repos? Might be ugly but it seems to me the single
revision isn't as useful as it was previously.
The angstrom-version recipe does this:
do_install() {
install -d ${D}${sysconfdir}
echo Angstrom ${DISTRO_VERSION} (Core edition)
${D}${sysconfdir}/angstrom-version
echo Built from branch: ${METADATA_BRANCH}
${D}${sysconfdir}/angstrom-version
echo Revision: ${METADATA_REVISION} ${D}${sysconfdir}/angstrom-version
echo Target system: ${TARGET_SYS} ${D}${sysconfdir}/angstrom-version
echo NAME=Angstrom ${D}${sysconfdir}/os-release
echo ID=angstrom ${D}${sysconfdir}/os-release
echo PRETTY_NAME=The Ångström Distribution ${D}${sysconfdir}/os-release
echo ANSI_COLOR=1;35 ${D}${sysconfdir}/os-release
install -d ${D}${bindir}
install -m 0755 ${WORKDIR}/lsb_release ${D}${bindir}/
}
So if METADATA_* becomes more usefull, angstrom-version becomes more usefull :)
Slightly off-topic: maybe we should try to standardize /etc/distro-release in
the OE-core universe, like systemd is standardizing /etc/os-release.
Now, suppose we break with the 'opkg update ; opkg install foo' model and
start leveraging sstate we can have a 'toplevel' thing that manages both
narcissus options (read: package checkboxes) and autobuilder config (read:
list of recipes to build):
1) have an autobuilder build the machine x packages set daily and store
info (success, revisions, etc) into a shared db
2) make narcissus pull info from that db when presenting the options.
As more hardware becomes available we could even have narcissus add the
build to a workqueue for the autobuilder directly. This needs to be
considered carefully, since the plain 'opkg install' method is already
eating a big chunk of IO. The Oregon instance of narcissus is already
using an SSD for the workdir since a spinning disk was too slow for the
workload. Have a look at the last 30 days:
http://narcissus.angstrom-distribution.org/graph.php?timeframe=30
or the past year for beagleboard:
http://narcissus.angstrom-distribution.org/graph.php?timeframe=365machine=beagleboard
The images aren't small either:
20110830 06:07:51 akita95M
20110830 07:12:51 beagleboard 30M
20110830 07:40:10 beagleboard 692M
20110830 07:41:26 beagleboard 8.6M
20110830 07:44:43 dm355-leopard31M
20110830 07:49:13 beagleboard 35M
20110830 07:52:26 beagleboard 30M
20110830 07:58:57 beagleboard 322M
20110830 07:59:54 omap3evm 456M
20110830 08:15:41 at91sam9263ek32M
20110830 08:32:13 h220093M
20110830 08:51:20 beagleboard 13M
20110830 08:56:02 beagleboard 258M
20110830 09:02:20 beagleboard 48M
With all this info being known and the fact that narcissus will run
parallel to echo for the time being, what design should we choose?
Well, one thing to consider as well is that it's very likely at some point
in the near future that we will be writing a BitBake web-UI within the
Yocto Project, and although it has not been designed yet I would expect
that to be along similar lines to the hob GTK2+-based UI, at least in
terms of the options it allows the user to change. The question is though,
in a distro like Angstrom where you've specified quite a lot of policy
(preferred versions, features, etc.) that you wouldn't necessarily want to
allow the user to configure, does a UI at the BitBake level make sense?
From what I've seem 'hob' hides pretty much everything as well so a web
version of it would be suitable as a narcissus replacement. I will postulate
that people using 'hob' or narcissus aren't distro developers and just want to
get a rootfs with their set of features. The feedback I get about narcisuss'
simple mode is that it has too many choices already :)
regards,
Koen
___
Angstrom-distro
[Angstrom-devel] OE Changelog for 2011-08-22 to 2011-08-29
Changelog for 2011-08-22 to 2011-08-29. Projects included in this report: bitbake: git://git.openembedded.org/bitbake openembedded-core: git://git.openembedded.org/openembedded-core meta-openembedded: git://git.openembedded.org/meta-openembedded meta-angstrom: git://git.angstrom-distribution.org/meta-angstrom meta-yocto: git://git.yoctoproject.org/poky meta-texasinstruments: git://git.angstrom-distribution.org/meta-texasinstruments meta-smartphone: http://git.shr-project.org/repo/meta-smartphone.git meta-micro: git://git.openembedded.org/meta-micro meta-slugos: git://github.com/kraj/meta-slugos meta-nslu2: git://github.com/kraj/meta-nslu2 meta-intel: git://git.yoctoproject.org/meta-intel openembedded: git://git.openembedded.org/openembedded Changelog for bitbake: Dongxiao Xu (1): data_smart.py: make use of expand cache in getVar() Joshua Lock (17): bb/ui/crumbs/runningbuild: reduce number of messages after recent msg change bb/ui/crumbs/runningbuild: hide the progress bar on cache load complete bb/ui/crumbs/tasklistmodel: more robust checking for substrings bb/ui/crumbs/tasklistmodel: remove useless items from dependency list bb/ui/crumbs/tasklistmodel: store all binb, not just the first hob: don't try and build if user selects Bake with no selections made bb/ui/crumbs/tasklistmodel: track the PN for each entry in the model bb/ui/hob: fix package only build bb/ui/crumbs/hobeventhandler: fix return values of *_image_output_type bb/ui/crumbs/hobprefs: fix setting IMAGE_FSYTPES bb/ui/hob: warn and prevent image build if no IMAGE_FSTYPE is set bb/fetch2/git: add checkstatus command hob: don't set PARALLEL_MAKE and BB_NUMBER_THREADS based on cpu count bb/ui/crumbs/tasklistmodel: fix find_reverse_depends method hob: disable some menu entries whilst build is in progress ui/crumbs/tasklistmodel: don't add same item to binb column more than once ui/crumbs/runningbuild: add a 'Copy' item to the messages right-click menu Richard Purdie (2): fetch2/git: Add rsync as a valid git protocol usermanual: The git fetcher defaults to the git protocol (or file) Changelog for openembedded-core: Bruce Ashfield (9): linux-yocto: move more default values into linux-yocto.inc linux-yocto: update SRCREVs for 3.0.3 kern-tools: allow flexible branch points linux-yocto-rt: update qemuppc support and streamline variables linux-yocto: update meta SRCREVs for beagleboard config changes linux-yocto: update machines and default configuration linux-yocto/2.6.37: apmd + get time of day fixes linux-yocto: update meta SRCREV to sync version strings linux-yocto-rt: qemumips: fix boot panic Chris Larson (4): libpcre: the generated libtool uses HOST_SYS rpm: be certain we don't prefix our binaries image_types_uboot: add uboot mkimage fs types terminal: fix issue with unset exportable env vars Darren Hart (2): tune: add missing closing quote to arch-armv7a.inc for AVAILTUNES tune: Add hard floating point variants of cortexa8 tunes Dmitry Eremin-Solenikov (1): opkg-utils: ignore packages disapperaring filelist generation Dongxiao Xu (7): procps: Fix lib path to support multilib package.bbclass: Fix recrdeptask of image type recipes base-passwd: Use BPN in FILES paths bitbake.conf: Use BPN in FILES paths multilib.bbclass: Fix renaming logic for FILES_, RDEPENDS_, etc multilib.bbclass: add pkg_postinst and pkg_postrm as renaming elements multilib.bbclass: add renaming for INITSCRIPT related variables Jessica Zhang (1): [YOCTO #1396] Fix adt-installer for consistent naming for powerpc and add al Jiajun Xu (2): libsdl: do not inherit nativesdk task-core-x11-sato: add libsdl into sato image Jingdong Lu (1): initrdscripts: fix init-live.sh for hddimg and livecd Joshua Lock (2): libtasn1: update SRC_URI classes/sanity: enhance the network connectivity test Kang Kai (3): bitbake.conf: set includedir_nativesdk qt4-tools-nativesdk: remove gcc standard paths cmake-nativesdk: remove gcc standard paths Khem Raj (1): recipes: Delete patch=1, its default and replace pnum with striplevel Koen Kooi (1): libc-package bbclass: fix binary localedata dependency code Kumar Gala (2): gcc-4.6: Drop gcc-poison-parameters.patch as its not need gcc-4.5.1: Drop gcc-poison-parameters.patch, replace with bug fix patch Lianhao Lu (3): adt-installer: Removed the hard coded repo url. toolchain-script.bbclass: Collected cached site config in runtime. meta-toolchain/environment: Collected site config files in runtime. Liming Wang (2): script/runqemu: change boot command line for qemuppc scripts/runqemu: disable unfs boot mode for qemuppc Martin Jansa (2): utils.bbclass: skip empty paths when handling FILESEXTRAPATHS eglibc: fix gconv packaging after 5486cac29db6e67051fff7637a0abc9aeab661e5 Mike Crowe (2): kernel.bbclass: support
