Re: [yocto] meta-selinux warrior support

[Jussi Kukkonen]

On Tue, 8 Oct 2019 at 09:59, Jussi Kukkonen  wrote:

>
>
> On Mon, 7 Oct 2019 at 17:57, Mark Hatle 
> wrote:
>
>> I thought this issue was already fixed:
>>
>>
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?h=warrior=bb0c9c3abcb935e4b362eb57985e1ee7fec0bfe0
>>
>>
> From the error log:
> > glib-2.58.3
>
> From the commit changelog
> > In glib 2.60.x, it turns selinux into a meson feature.
>
> That should explain the issue -- maybe oe-core was older than meta-selinux
> or glib was older for another reason.
>

Actually, poky warrior only has Glib 2.58.3, right? So the meta-selinux
commit makes no sense in Warrior branch?



>
>
>> This patch is what specifically adds the enabled/disabled that the system
>> is
>> saying (in the logs quoted below) is invalid.
>>
>> Can you try changing these to 'true' and 'false' instead?
>>
>> In the file: classes/meson-enable-selinux.bbclass
>>
>> --Mark
>>
>> On 10/1/19 1:39 AM, Oriya, Raxesh wrote:
>> > Hi,
>> >
>> >
>> >
>> > I am getting the below error when I am trying to integrate
>> 'meta-selinux' into
>> > our yocto solution. This error also happens when I just build
>> > 'core-image-selinux' by including the required layers in warrior
>> branch. Can
>> > anyone provide a fix for this..
>> >
>> >
>> >
>> > local.conf contains the following lines:
>> >
>> > -
>> >
>> > DISTRO_FEATURES_append = " acl xattr pam selinux"
>> >
>> > PREFERRED_PROVIDER_virtual/refpolicy ?= "refpolicy-mls"
>> >
>> > -
>> >
>> >
>> >
>> > ERROR: glib-2.0-native-1_2.58.3-r0 do_configure: meson failed
>> >
>> > ERROR: glib-2.0-native-1_2.58.3-r0 do_configure: Function failed:
>> do_configure
>> > (log file is located at
>> >
>> /home/panther2/warrior/build/tmp/work/x86_64-linux/glib-2.0-native/1_2.58.3-r0/temp/log.do_configure.34545)
>> >
>> > ERROR: Logfile of failure stored in:
>> >
>> /home/panther2/warrior/build/tmp/work/x86_64-linux/glib-2.0-native/1_2.58.3-r0/temp/log.do_configure.34545
>> >
>> > Log data follows:
>> >
>> > | DEBUG: Executing shell function do_configure
>> >
>> > | NOTE: Executing meson -Ddtrace=false -Dfam=false -Dsystemtap=false
>> > -Dselinux=false -Dlibmount=true -Dman=false -Dselinux=disabled
>> > -Dinternal_pcre=false -Dinstalled_tests=false...
>> >
>> > | The Meson build system
>> >
>> > | Version: 0.49.2
>> >
>> > | Source dir:
>> >
>> > | /home/panther2/warrior/build/tmp/work/x86_64-linux/glib-2.0-native/1_2
>> >
>> > | .58.3-r0/glib-2.58.3 Build dir:
>> >
>> > | /home/panther2/warrior/build/tmp/work/x86_64-linux/glib-2.0-native/1_2
>> >
>> > | .58.3-r0/build
>> >
>> > | Build type: native build
>> >
>> > |
>> >
>> > | meson.build:1:0: ERROR:  Value disabled is not boolean (true or
>> false).
>> >
>> > |
>> >
>> > | A full log can be found at
>> >
>> > | /home/panther2/warrior/build/tmp/work/x86_64-linux/glib-2.0-native/1_2
>> >
>> > | .58.3-r0/build/meson-logs/meson-log.txt
>> >
>> > | ERROR: meson failed
>> >
>> >
>> >
>> > Thanks,
>> >
>> > Raxesh
>> >
>> >
>> >
>> >
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-selinux warrior support

[Jussi Kukkonen]

On Mon, 7 Oct 2019 at 17:57, Mark Hatle 
wrote:

> I thought this issue was already fixed:
>
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?h=warrior=bb0c9c3abcb935e4b362eb57985e1ee7fec0bfe0
>
>
>From the error log:
> glib-2.58.3

>From the commit changelog
> In glib 2.60.x, it turns selinux into a meson feature.

That should explain the issue -- maybe oe-core was older than meta-selinux
or glib was older for another reason.



> This patch is what specifically adds the enabled/disabled that the system
> is
> saying (in the logs quoted below) is invalid.
>
> Can you try changing these to 'true' and 'false' instead?
>
> In the file: classes/meson-enable-selinux.bbclass
>
> --Mark
>
> On 10/1/19 1:39 AM, Oriya, Raxesh wrote:
> > Hi,
> >
> >
> >
> > I am getting the below error when I am trying to integrate
> 'meta-selinux' into
> > our yocto solution. This error also happens when I just build
> > 'core-image-selinux' by including the required layers in warrior branch.
> Can
> > anyone provide a fix for this..
> >
> >
> >
> > local.conf contains the following lines:
> >
> > -
> >
> > DISTRO_FEATURES_append = " acl xattr pam selinux"
> >
> > PREFERRED_PROVIDER_virtual/refpolicy ?= "refpolicy-mls"
> >
> > -
> >
> >
> >
> > ERROR: glib-2.0-native-1_2.58.3-r0 do_configure: meson failed
> >
> > ERROR: glib-2.0-native-1_2.58.3-r0 do_configure: Function failed:
> do_configure
> > (log file is located at
> >
> /home/panther2/warrior/build/tmp/work/x86_64-linux/glib-2.0-native/1_2.58.3-r0/temp/log.do_configure.34545)
> >
> > ERROR: Logfile of failure stored in:
> >
> /home/panther2/warrior/build/tmp/work/x86_64-linux/glib-2.0-native/1_2.58.3-r0/temp/log.do_configure.34545
> >
> > Log data follows:
> >
> > | DEBUG: Executing shell function do_configure
> >
> > | NOTE: Executing meson -Ddtrace=false -Dfam=false -Dsystemtap=false
> > -Dselinux=false -Dlibmount=true -Dman=false -Dselinux=disabled
> > -Dinternal_pcre=false -Dinstalled_tests=false...
> >
> > | The Meson build system
> >
> > | Version: 0.49.2
> >
> > | Source dir:
> >
> > | /home/panther2/warrior/build/tmp/work/x86_64-linux/glib-2.0-native/1_2
> >
> > | .58.3-r0/glib-2.58.3 Build dir:
> >
> > | /home/panther2/warrior/build/tmp/work/x86_64-linux/glib-2.0-native/1_2
> >
> > | .58.3-r0/build
> >
> > | Build type: native build
> >
> > |
> >
> > | meson.build:1:0: ERROR:  Value disabled is not boolean (true or false).
> >
> > |
> >
> > | A full log can be found at
> >
> > | /home/panther2/warrior/build/tmp/work/x86_64-linux/glib-2.0-native/1_2
> >
> > | .58.3-r0/build/meson-logs/meson-log.txt
> >
> > | ERROR: meson failed
> >
> >
> >
> > Thanks,
> >
> > Raxesh
> >
> >
> >
> >
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Nothing PROVIDES 'python3-dev'

[Jussi Kukkonen]

On Wed, 25 Sep 2019 at 09:16, Damien LEFEVRE  wrote:

> > On 24/09/2019 10:36, Damien LEFEVRE wrote:
> > > Hi,
> > >
> > > Migrating from poky:pyro to poky:warrior.
> > >
> > > It looks like the python3-dev package is generated from
> > > python3-manifest.json:
> > >
> > >  ? ? "dev": {
> > >  ? ? ? ? "cached": [],
> > >  ? ? ? ? "files": [
> > >  ? ? ? ? ? ? "${base_libdir}/*.a",
> > >  ? ? ? ? ? ? "${base_libdir}/*.o",
> > >  ? ? ? ? ? ? "${bindir}/python*-config",
> > >  ? ? ? ? ? ? "${datadir}/aclocal",
> > >  ? ? ? ? ? ? "${datadir}/pkgconfig",
> > >  ? ? ? ? ? ? "${includedir}",
> > >  ? ? ? ? ? ? "${libdir}/*.a",
> > >  ? ? ? ? ? ? "${libdir}/*.la",
> > >  ? ? ? ? ? ? "${libdir}/*.o",
> > >  ? ? ? ? ? ? "${libdir}/lib*${SOLIBSDEV}",
> > >  ? ? ? ? ? ? "${libdir}/pkgconfig"
> > >  ? ? ? ? ],
> > >  ? ? ? ? "rdepends": [
> > >  ? ? ? ? ? ? "core"
> > >  ? ? ? ? ],
> > >  ? ? ? ? "summary": "Python development package"
> > >  ? ? },
> > >
> > > and this is used in python3_3.7.2.bb .
> > >
> > > Still I get this error: Nothing PROVIDES 'python3-dev'
> >
> > Are you trying to 'bitbake python3-dev'?  You bitbake a recipe, not a
> > package, so 'bitbake python3'.
> >
> > Ross
>
> Hi Ross,
>
> The issue is with the python3 recipe. It declares RDEPENDS_python3-dev,
> not DEPENDS_python3-dev.
>

> I'm using the Python C API. So I need headers and so lib files at build
> time but only so lib at runtime.
>

DEPENDing on python3 should give you the former (headers etc in sysroot at
build time) and RDEPENDing on the correct package (maybe libpython3?)
should give you the latter -- but RDEPENDS should be automatic if your app
links to the library.

Is this not working?



>
> I can add python3-dev to my recipe's RDEPENDS list, but bitbake rightfully
> complains about installing -dev files to the image.
>
> I'll check today how to fix that.
>
> -Damien
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] "bitbake core-image-sato" yields "No package 'gdk-x11-3.0' found" build failure

[Jussi Kukkonen]

On Mon, 23 Sep 2019 at 17:26, Jean-Baptiste MARIE 
wrote:

> Ok, got it thanks.
>
> Indeed wayland is enabled in my distro features, so my question is more:
> is there any reason to remove x11 from package config when "wayland" is
> enabled as a distro feature (but maybe it is no longer a question to be
> addressed ot yocto community)? As Ross mentioned, there can both be built.
>

No generic reason that I can think of. The meta-freescale maintainers
probably didn't add it just for the fun of it ... but you'll have to
ask them (or try removing the PACKAGECONFIG modifications -- maybe the
reasons become obvious when something breaks horribly).

Jussi


>
>
> On Mon, Sep 23, 2019 at 3:42 PM Jussi Kukkonen  wrote:
>
>>
>> On Mon, 23 Sep 2019 at 15:48, Jean-Baptiste MARIE <
>> jbaptiste.ma...@gmail.com> wrote:
>>
>>> PACKAGECONFIG_remove_imxgpu2d = " \
>>> ${@bb.utils.contains("DISTRO_FEATURES", "wayland", "x11", "", d)} \
>>> "
>>>
>>
>> What Ross said: If wayland is in distro features this will remove the x11
>> packageconfig which means disabling the X11 backend for Gdk and removing
>> the X11-related API from libgdk3.so (and not installing the gdk-x11-3.0.pc
>> file which was the immediate reason for your build failure).
>>
>> Jussi
>>
>>
>>>
>>> CFLAGS_append_imxgpu2d = " \
>>> -DLINUX \
>>> ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', '-DEGL_API_FB
>>> -DEGL_API_WL', '', d)} \
>>> "
>>>
>>> - meta-solidrun-arm-imx6 (branch rocko): that branch overloads gtk
>>> recipe with the .bbappend as shown below:
>>>
>>> DEPENDS_append_imxgpu2d = " virtual/egl"
>>>
>>> PACKAGECONFIG_remove_imxgpu2d = " \
>>> ${@bb.utils.contains("DISTRO_FEATURES", "wayland", "x11", "", d)} \
>>> "
>>>
>>> I do not see any reason why gdk-x11-3.0 would not be built
>>>
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] "bitbake core-image-sato" yields "No package 'gdk-x11-3.0' found" build failure

[Jussi Kukkonen]

On Mon, 23 Sep 2019 at 15:48, Jean-Baptiste MARIE 
wrote:

> PACKAGECONFIG_remove_imxgpu2d = " \
> ${@bb.utils.contains("DISTRO_FEATURES", "wayland", "x11", "", d)} \
> "
>

What Ross said: If wayland is in distro features this will remove the x11
packageconfig which means disabling the X11 backend for Gdk and removing
the X11-related API from libgdk3.so (and not installing the gdk-x11-3.0.pc
file which was the immediate reason for your build failure).

Jussi


>
> CFLAGS_append_imxgpu2d = " \
> -DLINUX \
> ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', '-DEGL_API_FB
> -DEGL_API_WL', '', d)} \
> "
>
> - meta-solidrun-arm-imx6 (branch rocko): that branch overloads gtk recipe
> with the .bbappend as shown below:
>
> DEPENDS_append_imxgpu2d = " virtual/egl"
>
> PACKAGECONFIG_remove_imxgpu2d = " \
> ${@bb.utils.contains("DISTRO_FEATURES", "wayland", "x11", "", d)} \
> "
>
> I do not see any reason why gdk-x11-3.0 would not be built
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] "bitbake core-image-sato" yields "No package 'gdk-x11-3.0' found" build failure

[Jussi Kukkonen]

On Fri, 20 Sep 2019 at 18:09, Jean-Baptiste MARIE 
wrote:

> Hello,
> I am facing a problem that has already been addressed but not solved yet.
> When building "bitbake core-image-sato" for SolidRun iMX6 SOM, I always get
> an error message during configure task of matchbox-panel-2. The error is
> the following:
> checking for glib-2.0
>   gmodule-export-2.0
>   x11
>   gdk-x11-3.0
>   gtk+-3.0... no
> configure: error: Package requirements (glib-2.0
>   gmodule-export-2.0
>   x11
>   gdk-x11-3.0
>   gtk+-3.0) were not met:
>
> No package 'gdk-x11-3.0' found
>

gdk-x11-3.0 comes from Gtk+3 (as long as Gtk is compiled with X11 support).
Since matchbox-panel-2 is even trying to build, you should have the "x11"
distro feature enabled and this should really mean that Gtk does include
gdk-x11-3.0 by default...

I'd start with checking the Gtk+3 build: is the "x11" packageconfig really
enabled for gtk+3? Do your layers have bbappends that modify the Gtk recipe
somehow?

If you would like more help you need to at least list the layers (and their
branches) you use.
HTH,
Jussi



> If I run bitbake gdk-x11-3.0, I get:
> ERROR: Nothing PROVIDES 'gdk-x11-3.0'
>
> Any idea of what is wrong please?
>
> Thanks for your help.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Wayland-scanner missing from SDK

[Jussi Kukkonen]

On Tue, 17 Sep 2019 at 13:23, Teemu K  wrote:

> Hi,
>
> I'm trying to create SDK for my image created with Yocto's rocko -
> branch. It goes fine except wayland-scanner is missing from native
> toolchain.
>
> I found this patch and verified those changes are in place:
> https://patchwork.openembedded.org/patch/126669/
>
> Still the wayland-scanner is not  appearing to native toolchain side.
> The target side it is.
>

The scanner is in -dev package IIRC. There was a discussion later last year
where  someone tried to add -dev for that reason but that received critique
(because of the heavy price in dependencies).

There was a later attempt at tweaking the packaging (
https://patchwork.openembedded.org/patch/154282/) but that was not merged
I guess? I'm guessing that failed on autobuilder because builds that were
expecting to find the scanner suddenly didn't...

Jussi


> I'm using command 'populate_sdk' to create sdk. How do I get
> wayland-scanner to native toolchain side too?
>
> I tested with thud-branch and it has same issue.
>
> Hopefully this comes to correct mailing list.
>
> -Teemu Keskinarkaus
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] One second timestamp resolution?

[Jussi Kukkonen]

On Wed, 11 Sep 2019 at 08:53, Paul D. DeRocco  wrote:
>
> I just noticed that I'm getting one-second resolution on all my
> timestamps. This is for both ext4 and vfat partitions, and shows up in ls
> --full-time and the stat command. What could account for this? My uname -a
> output is "Linux CHROMA1 4.10.17-yocto-preempt-rt #1 SMP PREEMPT Wed Oct
> 11 12:33:54 PDT 2017 i686 i686 i386 GNU/Linux" if that's any help. Also,
> my ext4 mount options are "rw,noatime,nodiratime,data=ordered".

I think file timestamp resolution on ext4 is one of the things that
depend on inode size (ext4 does not enforce reasonable values because
of compatibility with earlier versions I guess). So maybe check inode
size (should be 256 bytes I think?).

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Pyro, bitbake, git pull for my recipe (Why not?)

[Jussi Kukkonen]

>From the AUTOREV documentation:

   If you use the previous statement to retrieve the latest version of
software, you need to be sure PV contains ${SRCPV}.

Typically this looks something like:
PV = "1.2+git${SRCPV}"

HTH,
  Jussi

On Mon, 5 Aug 2019 at 11:47, Mauro Ziliani  wrote:
>
> Hi all.
>
> It seems that bitbake doesn't check the remote git repository of my
> application (terminal is the name of the recipe) every time I do
>
>
> bitbake  terminal
>
>
> The recipe is this
>
> #  the recipe -
>
> SRCREV="${AUTOREV}"
>
> SRC_URI = " \
>
>  git://git@server/terminal.git;protocol=ssh;branch=master \
>
> "
>
>
> S := "${WORKDIR}/git"
>
> inherit qmake5
>
> #  the end of recipe -
>
>
> Any idea to force git pull?
>
>
> Best regards,
>
>MZ
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] install -m 0644 ${S}/lib/systemd/system/${PN}.service ${D}/${systemd_system_unitdir} failed to add service file to ${systemd_system_unitdir}

[Jussi Kukkonen]

On Tue, 23 Jul 2019 at 14:48, JH  wrote:
>
> Hi,
>
> I set up the configuration for service files at following:
>
> SYSTEMD_SERVICE_${PN} = "${PN}.service bootstrap.service"
>
> do_install() {
> ..
> install -d ${D}/${systemd_system_unitdir}
> install -m 0644 ${S}/lib/systemd/system/*.service
> ${D}/${systemd_system_unitdir}
> }
>
> Despite both service files are in build directory, the final image
> installation does not include those service files, appreciate anyone
> help.

Your script installs from ${S} but your explanation talks about the
build directory. Did you intend to install from ${B}?

If that's not the issue, then you want dig deeper: look in the build
logs and the package directories inside workdir: does the file
actually get installed and packaged? Is the correct package really
added to image?

HTH,
  Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] bitbak command: No recipe available for

[Jussi Kukkonen]

On Mon, 8 Jul 2019 at 12:29, danwe  wrote:
>
> Hi,
>
> while using the command:
> daniel@daniel-VirtualBox:~/bbb$ MACHINE=beaglebone bitbake core-immage-full 
> cmdline
> I get the following ouput:
>
> Loading cache: 100% || Time: 
> 0:00:03
> Loaded 1358 entries from dependency cache.
> Parsing recipes: 100% |##| Time: 
> 0:00:12
> Parsing of 832 .bb files complete (829 cached, 3 parsed). 1361 targets, 65 
> skipped, 0 masked, 0 errors.
> ERROR: No recipes available for:
>   /home/daniel/meta-bbb/recipes-connectivity/openssh/openssh_7.%.bbappend
>   /home/daniel/meta-bbb/recipes-qt/qt5/qtbase_git.bbappend
>   /home/daniel/meta-bbb/recipes-support/ntp/ntp_4.2.%.bbappend

Ross answered this already: Your meta-bbb version seems incompatible
with your poky version. If you are using git, make sure the branch
names of all your layers match and that the branches are up to date.

HTH,
  Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Fwd: [DNF YOCTO clarifications] smart was replaced with dnf in Yocto 2.3

[Jussi Kukkonen]

On 24 August 2017 at 10:33, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:
>
> Hello Jussi,
>
> I would like to thank you very much for the useful reply. It was a bit
different with me, but most boiled down as you said/explained (the
difference are in client/server IP addresses, but everything else is almost
the same - I guess, I do not have complete set of .rpms on my server side).
>
> I issued the following comand on client (qemux86-64): dnf list all | wc
-l, and got the following response:
> Repository 'oe-packages' is missing name in configuration, using id.
> Last metadata expiration check: 0:42:56 ago on Thu Aug 24 06:13:31 2017
UTC
> 7909
>
> Regarding the command's answer, I have two questions to ask: one easy,
and one tough. ;-)
>
> Easy one. What is the reason for this message: Repository 'oe-packages'
is missing name in configuration, using id???

I'm not a yum/dnf expert at all but the error seems to be saying that
oe-packages.repo is missing a line like "name =  OpenEmbedded packages".

> Tough one: 7909 packages overall on server. Could you (YOCTO
maintainers), please, keep DNF (for .rpm packages) onwards indefinitely in
YOCTO, and make/create master YOCTO download servers, the same what Fedora
distro does for almost two decades (with YUM, prior DNF)?
>
> The positive answer on the second question will make (for many thousand
people using .rpms in YOCTO) life much easier, won't it?!

No. Yocto is not an operating system, it's a toolset that can be used to
build many wildly different operating systems. An rpm repo would only be
compatible with one of those OSes.

If a Yocto user builds and maintains a specific OS with Yocto, it might
make sense for them to maintain rpm repos for that OS. It does not make
sense for Yocto project.

 - Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Fwd: [DNF YOCTO clarifications] smart was replaced with dnf in Yocto 2.3

[Jussi Kukkonen]

On 23 August 2017 at 14:51, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Hello Jussi,
>
> Let me start giving you all the hints. So you can see where I lead. You
> made few mistakes, so DNF won't work as such/is (by default) in Pyro 2.3.1.
>
> I investigated a bit (I already wrote that I am quite familiar with DNF
> and its concepts).
>
> For the starters: Your DNF repo on Pyro 2.3.1 is in the following
> directory (I built full SATO image for target qemux86-64), transcript from
> my bare metal F26 follows:
>
> [user@localhost poky]$ cd build/tmp/deploy/rpm
> [user@localhost rpm]$ ls -al
> total 564
> drwxr-xr-x. 5 user user   4096 Aug 22 13:33 .
> drwxr-xr-x. 5 user user   4096 Aug 22 13:28 ..
> drwxr-xr-x. 2 user user 462848 Aug 22 13:32 core2_64
> drwxr-xr-x. 2 user user  16384 Aug 22 13:32 noarch
> drwxr-xr-x. 2 user user  81920 Aug 22 13:32 qemux86_64
> [user@localhost rpm]$ cd noarch
> [user@localhost noarch]$ ls -al | wc -l
> 189
> [user@localhost noarch]$ ls -al *.xml
> ls: cannot access '*.xml': No such file or directory
> [user@localhost noarch]$
>
> As we see here, there are three .rpm repos on the server (let say, I am
> starting client qemux86-64). If you do the same, and built it for sato (or
> minimal, does not matter), you'll have the same. None of these .rpm repos
> have file which MUST be present there: repomd.xml???
>
> Where is this file? How to generate it, for/per each local server repo,
> one instance of repomd.xml???
>

repomd.xml is created into TMPDIR/deploy/rpm/repodata/ when you run
"bitbake package-index" as the documentation suggested.

I don't have Pyro but I've just tried this on master and it seems to work
fine (the docs might need updating on the baseurl format though).

** On the server:
~/src/poky/build/tmp/deploy/rpm$ python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

** On target qemu:
root@qemux86-64:~# cat /etc/yum.repos.d/oe-packages.repo
[oe-packages]
baseurl=http://192.168.7.3:8000/
root@qemux86-64:~# dnf makecache
Repository 'oe-packages' is missing name in configuration, using id.
Last metadata expiration check: 0:06:49 ago on Wed Aug 23 12:23:22 2017.
Metadata cache created.
root@qemux86-64:~# dnf --nogpgcheck install libinput-bin
Repository 'oe-packages' is missing name in configuration, using id.
Last metadata expiration check: 0:10:09 ago on Wed Aug 23 12:23:22 2017.
Dependencies resolved.

 PackageArch   Version
 Repository Size

Installing:
 libinput-bin   core2_64   1.8.1-r0
oe-packages12 k

Transaction Summary

Install  1 Package

Total download size: 12 k
Installed size: 19 k
Is this ok [y/N]: y
Downloading Packages:
libinput-bin-1.8.1-r0.core2_64.rpm
 323 kB/s |  12 kB 00:00

Total
134 kB/s |  12 kB 00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing:
 1/1
  Installing   : libinput-bin-1.8.1-r0.core2_64
1/1
  Verifying: libinput-bin-1.8.1-r0.core2_64
1/1

Installed:
  libinput-bin.core2_64 1.8.1-r0


Complete!
root@qemux86-64:~#



>
> I think, I am actually helping you to understand the issues with Pyro
> 2.3.1 and DNF. ;-)
>
> Thank you,
> Zoran Stojsavljevic
>
> On Wed, Aug 23, 2017 at 9:42 AM, Jussi Kukkonen <jussi.kukko...@intel.com>
> wrote:
>
>> On 23 August 2017 at 09:56, Zoran Stojsavljevic <
>> zoran.stojsavlje...@gmail.com> wrote:
>>
>>> Privet Aleks,
>>>
>>> Nezacem zlitsja/serditsja. Ja prosto ne znal cto u vas takaja politika.
>>>
>>> All Cool. Did not know that this is the policy, to have real names on
>>> YOCTO list. I removed nobody from it, and added my real name and real @. I
>>> removed user nobody from the YOCTO @ list.
>>>
>>> The/Your answer is 

Re: [yocto] Fwd: [DNF YOCTO clarifications] smart was replaced with dnf in Yocto 2.3

[Jussi Kukkonen]

On 23 August 2017 at 09:56, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Privet Aleks,
>
> Nezacem zlitsja/serditsja. Ja prosto ne znal cto u vas takaja politika.
>
> All Cool. Did not know that this is the policy, to have real names on
> YOCTO list. I removed nobody from it, and added my real name and real @. I
> removed user nobody from the YOCTO @ list.
>
> The/Your answer is too general. I somehow well know DNF service, but in
> FEDORA light. For fedora I do know what I need to do, and where/what are
> the options and which plug-ins to use/add, and ho to remove, upgrade, and
> configure.
>
> I tried all of this in the lieu of the following pointers:
> https://docs.fedoraproject.org/en-US...ositories.html
> 
> https://docs.fedoraproject.org/en-US...y_Options.html
> 
>
> And made on my target (which is connected with my server with simplistic
> Apache (it is one machine, which carries F26 on bare metal INTEL CORE) on
> server, client runs as qemux86_64 YOCTO emulator).
>

The answer is generic because the question is quite generic.

Some things you could mention to make it easier for someone to help you:
* explain the steps you took to setup (maybe copy-paste your repo file from
the target), mention what "dnf makecache" says
* mention whether you've verified that manually downloading a rpm from your
server works on image
* most importantly explain what exactly fails and how.


Thanks,
 Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Custom recipe - resolving "do_package_qa: QA Issue: -dev package contains non-symlink .so"

[Jussi Kukkonen]

On 22 August 2017 at 16:43,  wrote:
>
> I have a custom recipe (for the AWS SDK), which is failing at the
package_qa
> stage.
> The recipe is a very basic cmake styley, and on its own seems to begin
with:
> 'bitbake -f -c package aws-sdk'  completes without errors.
>
> But for 'bitbake -c package_qa aws-sdk) I get:
>
> ERROR: aws-sdk-1.1.31-r0 do_package_qa: QA Issue: -dev package contains
> non-symlink .so: aws-sdk-dev path
>
'/work/armv7a-neon-poky-linux-gnueabi/aws-sdk/1.1.31-r0/packages-split/aws-s
> dk-dev/usr/lib/libaws-cpp-sdk-core.so'
> -dev package contains non-symlink .so: aws-sdk-dev path
>
'/work/armv7a-neon-poky-linux-gnueabi/aws-sdk/1.1.31-r0/packages-split/aws-s
> dk-dev/usr/lib/libaws-cpp-sdk-s3.so' [dev-elf]
>
> I'd appreciate help with resolving this. Thanks.>
>

It looks like aws-sdk installs .so files that are actual libraries (and not
symlinks to the versioned libraries as would be the usual case). The best
solution would be to get aws to install versioned libraries but if that's
not an option, you probably want to package the .so files in the actual
library package, not the -dev package (which is the default since usually
.so are symlinks for development and the actually versioned ).

You may have to set both FILES_${PN}-dev and FILES_${PN} (so the former
doesn't grab the so files, and the latter does)

HTH,
  Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] raw copy lots of files to rootfs via recipe

[Jussi Kukkonen]

On 19 August 2017 at 20:11, Fabian Knapp  wrote:

> Hi,
>
>
>
> I have to copy a complete file structure to my rootfs which also contains
> .sh and .js files Makefiles and so on. However, I only want to „raw“ copy
> these files to /xyz to my rootfs.
> I tried to cp -r via do_install() and added the files to my FILES_${PN}
> but I get an error: ‚no package provides /usr/local/bin/node-bench‘ that
> indicates that this is not a raw copy as wanted.
>

cp is just cp, that is not likely to be the problem. Would you mind pasting
the full error message with any relevant context?

I'm going to guess that this is something in the packaging system (rpm?)
looking into scripts and adding whatever is in the shebang  into runtime
dependencies of the package during do_package(). Do you have
"#!/usr/local/bin/node-bench" in one of your scripts? If yes, can you
either avoid that or make sure something installs the correct binary into
the correct place?

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Errors while tring rpi-test-image for rpi3

[Jussi Kukkonen]

> ERROR: Nothing PROVIDES 'libav' (but
>
/u/hope_poky/poky_for_mon/poky/meta-raspberrypi/recipes-multimedia/omxplayer/
omxplayer_git.bb
> DEPENDS on or otherwise requires it)
> ERROR: ffmpeg PROVIDES libav but was skipped: because it has a
> restricted license not whitelisted in LICENSE_FLAGS_WHITELIST

Searching the Yocto reference manual for this term will lead to
http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#enabling-commercially-licensed-recipes
which should have the details you need to resolve the issue.

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Errors while tring rpi-test-image for rpi3

[Jussi Kukkonen]

On 12 August 2017 at 11:08, mohammed aqdam  wrote:
>
> to enable camera i was trying with rpi-test-image, after adding
> meta-openembedded layer into bblayer.conf, when i run bitbake i got
> this errors...
>
> root@(none):/u/hope_poky/poky_for_mon/poky/build# bitbake -k
rpi-test-image
> Parsing recipes: 100%
>
|###|
> Time: 0:05:39
> Parsing of 1518 .bb files complete (0 cached, 1518 parsed). 2129
> targets, 159 skipped, 0 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
> ERROR: Nothing RPROVIDES 'bigbuckbunny-1080p' (but
>
/u/hope_poky/poky_for_mon/poky/meta-raspberrypi/recipes-core/packagegroups/
packagegroup-rpi-test.bb
> RDEPENDS on or otherwise requires it)


When you add a layer into your setup you should read the layer  README for
the instructions and dependencies. In his case meta-raspberrypi README says
that you need meta-oe, meta-multimedia, meta-networking and meta-python
layers but looking at your build info...

> meta
> meta-poky
> meta-yocto-bsp= "pyro:4a39979c8d1e560fa54240e99734a651dfbaa63a"
> meta-raspberrypi  = "master:f6a2ca21c72b8d97cd0f89a0a436bf90b431698b"
> meta-oe   = "master:a8b54e300be027fefe8a774ca1861d0fb8e80d99"

... it looks like meta-multimedia, meta-python and meta-networking layers
(all part of meta-openembedded repo) are missing from bblayers.conf.

Hope this helps,
  Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto build at Kali

[Jussi Kukkonen]

On 10 July 2017 at 15:38, Rafael Machado 
wrote:

> Thanks for the answer guys.
> Yes Jussi. Seco website requires a registration. Sorry about that.
>
> Follows the complete output:
>
> Traceback (most recent call last):
>   File "/home/rafael/Projetos/seco/poky/bitbake/bin/bitbake", line 31, in
> 
> import bb
>   File "/home/rafael/Projetos/seco/poky/bitbake/lib/bb/__init__.py", line
> 77, in 
> from bb import fetch2 as fetch
>   File "/home/rafael/Projetos/seco/poky/bitbake/lib/bb/fetch2/__init__.py",
> line 1769, in 
> from . import wget
>   File "/home/rafael/Projetos/seco/poky/bitbake/lib/bb/fetch2/wget.py",
> line 40, in 
> from   bs4 import BeautifulSoup
>   File "/home/rafael/Projetos/seco/poky/bitbake/lib/bs4/__init__.py",
> line 30, in 
> from .builder import builder_registry, ParserRejectedMarkup
>   File "/home/rafael/Projetos/seco/poky/bitbake/lib/bs4/builder/__init__.py",
> line 311, in 
> from . import _html5lib
>   File "/home/rafael/Projetos/seco/poky/bitbake/lib/bs4/builder/_html5lib.py",
> line 57, in 
> class TreeBuilderForHtml5lib(html5lib.treebuilders._base.TreeBuilder):
> AttributeError: 'module' object has no attribute '_base'
>

This is probably an incompatibility with newish html5lib fixed by
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=
5c1ad6852e1246fda717582d7fb4959200bf71a6. This fix is in the last two Yocto
releases (pyro and morty).

You could try patching that yourself and/or reporting this issue to the BSP
maker.

HTH,
  Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto build at Kali

[Jussi Kukkonen]

On 9 July 2017 at 05:15, Rafael Machado 
wrote:

> Hi everyone
>
> I need your help. For the last several days, I've being trying to compile
> a yocto based project with no success. So in case someone can help me this
> would be really nice :)
>
> Follow the details of the problem.
> On my development system, I have installed a kali linux (debian)  4.9.0.
>
> http://cdimage.kali.org/kali-2017.1/kali-linux-2017.1-amd64.iso
>
> The project I'm trying to compile is from SECO, for the Q974 som.
> It can be found here:
>
> http://www.seco.com/prods/other/form-factor/qseven-7-x-7/q7-974.html
>
> At this page you can find the BSP (board support package), but it cannot
> be done, as described at the .pdf available at the BSP package. Doing the
> same steps at debian, ubuntu and fedora, everything works fine, but at Kali
> it fails with the message:
>

Everything is behind a registration so we can't know what is described
there.


>
> "File "/media/sda3/open_env/openembedded-core/bitbake/bin/bitbake", line
> 34, in 
>
> import bb
>   File "/media/sda3/open_env/openembedded-core/bitbake/lib/bb/__init__.py", 
> line 77, in 
> from bb import fetch2 as fetch
>   File 
> "/media/sda3/open_env/openembedded-core/bitbake/lib/bb/fetch2/__init__.py", 
> line 38, in 
> import bb.persist_data, bb.utils
>   File 
> "/media/sda3/open_env/openembedded-core/bitbake/lib/bb/persist_data.py", line 
> 35, in 
>
>
The actual error message is not listed here.

Cheers,
 Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] xorg-xserver and gtk+3 do_configure fail in poky-pyro

[Jussi Kukkonen]

On 5 July 2017 at 17:10, Joseph Ngigi  wrote:
> | checking for GDK_DEP... no
> | configure: error: Package requirements (pango pangocairo gdk-pixbuf-2.0
>= 2.30.0 cairo >= 1.14.0 cairo-gobject >= 1.14.0 gio-unix-2.0 >= 2.49.4
fontconfig x11 xext xi xrandr xcursor xfixes xcomposite xdamage
wayland-client >= 1.9.91 wayland-protocols >= 1.7 xkbcommon >= 0.2.0
wayland-cursor >= 1.9.91 wayland-egl   cairo-xlib cairo epoxy >= 1.0) were
not met:
> |
> | No package 'wayland-egl' found

This could be a bug in gtk+3 recipe when using something else than mesa:
The wayland packageconfig depends on "virtual/mesa" when it maybe needs
"virtual-egl" instead -- what it's really looking for wayland-egl.pc (which
is normally provided by mesa but I guess on your system it's something
else).

As an aside I have to admit the definitions of our various
virtual-whatevers are not clear to me at all... Is this something we could
reasonably document better ?


> | checking for GLAMOR... yes
> | checking for GBM... no
> | configure: error: Glamor for Xorg requires gbm >= 10.2.0

Here the glamor packageconfig seems to be missing a dependency on something
that provides libgbm (again we probably don't normally notice this because
the provider is mesa). My guess is that "virtual/libgl" _usually_ provides
libgbm, so adding that to glamor packageconfig dependencies might be a fix.


HTH,
 Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] : cmake and create_symlink using cmake 3.5 and yocto 2.2.2

[Jussi Kukkonen]

On 26 June 2017 at 21:46, Ehrlich Andrei  wrote:
> Please excuse the newbie question I want to ask, but I started with yocto
and cmake 3 month ago and now I have a couple of recipes based on cmake.
One of that cmake files installs links using following code:
>
> install(
> CODE "execute_process( \
> COMMAND ${CMAKE_COMMAND} -E create_symlink \
> __tool \
> ${CMAKE_INSTALL_PREFIX}/bin/tool_${DST_NAME} \
> )"
>
> When the code is executed in yocto  the do_install task fails with
following error:
> failed to create symbolic link '/usr/bin/tool_intf': Permission denied

The code should account for DESTDIR I think: maybe something like
"$ENV{DESTDIR}/${CMAKE_INSTALL_PREFIX}/bin/tool_${DST_NAME}" as the target

HTH,
  Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Failed to build gdb

[Jussi Kukkonen]

On 15 June 2017 at 10:19, Lm Chew  wrote:

> | /usr/src/debug/gdb/7.12.1-r0/gdb-7.12.1/gdb/completer.c:1862: undefined
> reference to `_rl_completion_prefix_display_length'
> | /usr/src/debug/gdb/7.12.1-r0/gdb-7.12.1/gdb/completer.c:1862: undefined
> reference to `rl_sort_completion_matches'
> | collect2: error: ld returned 1 exit status
>

Making an educated guess here: Because of the INCOMPATIBLE_LICENSE setting
you end up with an ancient version of readline that doesn't actually
provide the API that gdb needs. You may have to allow GPLv3+ for readline
as well.

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Wireshark but no Tshark?

[Jussi Kukkonen]

On 7 June 2017 at 20:59, Michael Calve  wrote:

> Hi, I've seen that Wireshark is portable to Yocto, however Tshark is not?
> Is there other/better software for reading pcaps and getting field data???
>

Hi,

tshark is part of wireshark: it should be built by the wireshark recipe in
meta-networking.

If you want a smaller footprint tool, try tcpdump (also in
meta-networking). It's not as featureful as tshark but uses the same
sniffing library and wireshark can display tcpdump results just fine.

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Changing terminal font in sato

[Jussi Kukkonen]

On 1 June 2017 at 18:58, Gary Thomas  wrote:
>
> How does one change the terminal font (size) used by matchbox-terminal
> in the sato desktop?  I tried the 'matchbox-appearance' app and it didn't
> have any affect, nor could I see a way to change the font.


Hi, sorry for late answer,

matchbox-terminal is a _very_ thin app based on VteTerminal widget:
Modifying Vte font is a single API call but that is not exposed in the app
(as it has no configuration at all). In the short term your options are to
use another more serious terminal or send patches for mb-terminal...

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Install Torch7

[Jussi Kukkonen]

On 18 May 2017 at 15:02, Abayiz  wrote:
> No, I didn't try 'devtool edit-recipe torch' to add dependencies.
Actually I didn't know how to add them. Is there any way to directly call
that .sh file there??

That shell script is very specific to a handful of distros. It will only
help you as a reference.

For the cache variables even the shell script wouldn't help: the project
just won't cross-compile on any distro unless you set those by hand.
I assume something like this in the recipe should help:
EXTRA_OECMAKE = "-D=  -D="
Experiment with one of the variables and see if you can make one of the
errors go away.

After that you will have to ensure each dependency is available at
build/run time as needed: Some of them will just require you to set DEPENDS
or RDEPENDS correctly, some may require you to write a recipe for the
dependency first.

> Could you give me a minimal example to illustrate it?

The documentation is extensive, I suggest you read the 5.3 section of the
dev-manual, especially 5.3.10. Dependencies:
http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-dependencies
and get back with specific questions if that doesn't help.

Based on a quick look I'd expect Torch to be quite tricky to package, be
prepared for new problems on the way.

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [libfakekey][PATCH 2/2] Handle shifted keysyms that are not in keymap

[Jussi Kukkonen]

This is based on a patch from Finn (at earthling.net):

"If my keymap is set to US and I use fakekey_press_keysym to send a Ó
the character isn't already in my keymap so fakekey adds it but then
sends ó instead. My patch now does the same check if a shift modifier
is required that's done in the code path for keys that are already in
the keymap."

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 src/libfakekey.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/libfakekey.c b/src/libfakekey.c
index df650a4..edf3006 100644
--- a/src/libfakekey.c
+++ b/src/libfakekey.c
@@ -357,7 +357,16 @@ fakekey_press_keysym(FakeKey *fk,
* 
* Probably better to try and grab the mapping notify *here* ?
*/
-  
+
+  if (XKeycodeToKeysym(fk->xdpy, code, 0) != keysym)
+{
+  DBG("does not equal code for index 0, needs shift?\n");
+  /* TODO: Assumes 1st modifier is shifted  */
+  if (XKeycodeToKeysym(fk->xdpy, code, 1) == keysym)
+flags |= FAKEKEYMOD_SHIFT; /* can get at it via shift */
+  else
+DBG("attempted to add keycode to keymap but seem to have failed");
+}
 }
 
   if (code != 0) 
-- 
2.11.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [libfakekey][PATCH 1/2] tests/Makefile.am: Add missing LIBS

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 tests/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 67ed38b..aac1dbd 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -2,4 +2,4 @@ INCLUDES=-I${top_srcdir}/src -I${top_srcdir} $(FAKEKEY_CFLAGS)
 
 noinst_PROGRAMS=fakekey-test
 
-fakekey_test_LDADD=../src/libfakekey.la
\ No newline at end of file
+fakekey_test_LDADD=../src/libfakekey.la $(FAKEKEY_LIBS)
-- 
2.11.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [libfakekey][PATCH 0/2] Bug fixes for libfakekey

[Jussi Kukkonen]

A (slightly modified) old patch from bugzilla that fixes handling of
fake shifted keypresses where the character is not in the keymap
already, and a build script fix.

Thanks, Jussi


The following changes since commit e327ff049b8503af2dadffa84370a0860b9fb682:

  src/Makefile.am: Fix compiles in out of tree build case (2013-03-08 11:52:39 
+)

are available in the git repository at:

  git://github.com/jku/libfakekey shifted-keysym-fix
  https://github.com/jku/libfakekey/tree/shifted-keysym-fix

Jussi Kukkonen (2):
  tests/Makefile.am: Add missing LIBS
  Handle shifted keysyms that are not in keymap

 src/libfakekey.c  | 11 ++-
 tests/Makefile.am |  2 +-
 2 files changed, 11 insertions(+), 2 deletions(-)

-- 
2.11.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Pre-compiling Python Byte Code

[Jussi Kukkonen]

On 3 May 2017 at 21:50, Chris Trobridge  wrote:
> To improve startup speed I have decided to pre-compile python3 byte code
in my bb recipe.  This is done semi automatically with the rpm build for
Fedora but I've not found anything similar for Yocto.
>
> I initially tried to use compileall:
>
> python3 -m compileall ${D}/opt/test_app/python
>
> This almost worked but it uses the host python3 to failed with a slight
difference in magic.
>
> The following works, as it uses the native python3 compiled by bitbake
but it feels a little contrived.  Is there a better way of specifying the
native python3 interpreter, or a better way of getting my python byte code
compiled prior to generating the packages?
>
> ${STAGING_BINDIR_NATIVE}/python3-native/python3 -m compileall
${D}/opt/test_app/python

Looks fine to me. I believe distutils/setuptools would do this for you
though.

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] fbida issue

[Jussi Kukkonen]

On 26 April 2017 at 21:47, bahjat khan  wrote:
>
> I'm trying to build a Yocto image for a kabylake processor. I keep on
running into this issue
>
> ERROR: Nothing RPROVIDES 'fbida' (but
/home/builder/project/prop/build/../meta-cusotom/recipes-custome/images/
custom-image-full.bb RDEPENDS on or otherwise requires it)
> ERROR: fbida was skipped: Recipe is blacklisted: Fails to build with RSS
http://errors.yoctoproject.org/Errors/Details/130677/ - the recipe will be
removed on 2017-09-01 unless the issue is fixed

The recipe has been blacklisted because it does not work as is (it broke
when recipe specific sysroots were added so it is probably missing some
native dependencies or inherits). You should remove the PNBLACKLIST line
from the recipe and try to build it. Then you should fix whatever issues
the build has.

I had a quick look on the output on that errors.yoctoproject.org case: at
least the recipe is missing a "inherit pkgconfig"

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Relicensing an Apache-licensed recipe as MIT

[Jussi Kukkonen]

On 12 April 2017 at 12:54, Paul Eggleton <paul.eggle...@linux.intel.com>
wrote:

> On Wednesday, 12 April 2017 7:14:00 PM NZST Jussi Kukkonen wrote:
> > On 11 April 2017 at 23:52, Martin Kelly <mke...@xevo.com> wrote:
> > > I'm thinking about integrating the open-vm-tools recipe from
> openswitch[1]
> > > into openembedded (it massively improves the performance of VMWare
> guests)
> > > but first I have a question about licensing. The openswitch repository
> is
> > > Apache-licensed while the openembedded layers are all MIT licensed. I'm
> > > not
> > > a lawyer, but my understanding is that the Apache license is a
> superset of
> > > the MIT license (it includes a patent clause that the MIT license
> lacks),
> > > and therefore MIT code can be relicensed as Apache but not the other
> way
> > > around.
> >
> > The license of the layer refers to the licensing of the recipe files
> > themselves: the source code licenses of the projects the recipes fetch
> and
> > build are another thing. As long as the source code license is an open
> > source one there should be no complaints about integrating into an
> > openembedded layer.
> >
> > To be completely clear: The LICENSE variable in a recipe refers to the
> > source code license of the project to be built and should be set based on
> > the licensing info found within the version of source code that we fetch
> > and build. The recipe files are licensed according to the LICENSE and/or
> > COPYING files of the layer it is in.
> >
> > By the way, a quick search on layers.openembedded.org reveals this:
> > http://git.openswitch.net/cgit/openswitch/ops-build/
> tree/yocto/openswitch/me
> > ta-foss-openswitch/recipes-extended/open-vm-tools/open-
> vm-tools_10.0.5.bb
> > (it seems to think the correct license is GPL).
>
> This is muddying the waters somewhat - the LICENSE variable has nothing to
> do
> with this. We're only concerned with the license of the recipe itself.
>


Thanks Paul: I was indeed confused and did not understand this was about an
existing recipe even though it was clearly explained in the original post.
Sorry for the noise.

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Relicensing an Apache-licensed recipe as MIT

[Jussi Kukkonen]

On 11 April 2017 at 23:52, Martin Kelly  wrote:

> Hi,
>
> I'm thinking about integrating the open-vm-tools recipe from openswitch[1]
> into openembedded (it massively improves the performance of VMWare guests)
> but first I have a question about licensing. The openswitch repository is
> Apache-licensed while the openembedded layers are all MIT licensed. I'm not
> a lawyer, but my understanding is that the Apache license is a superset of
> the MIT license (it includes a patent clause that the MIT license lacks),
> and therefore MIT code can be relicensed as Apache but not the other way
> around.
>

The license of the layer refers to the licensing of the recipe files
themselves: the source code licenses of the projects the recipes fetch and
build are another thing. As long as the source code license is an open
source one there should be no complaints about integrating into an
openembedded layer.

To be completely clear: The LICENSE variable in a recipe refers to the
source code license of the project to be built and should be set based on
the licensing info found within the version of source code that we fetch
and build. The recipe files are licensed according to the LICENSE and/or
COPYING files of the layer it is in.

By the way, a quick search on layers.openembedded.org reveals this:
http://git.openswitch.net/cgit/openswitch/ops-build/tree/yocto/openswitch/meta-foss-openswitch/recipes-extended/open-vm-tools/open-vm-tools_10.0.5.bb
(it seems to think the correct license is GPL).

   Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Porting a middleware to Yocto

[Jussi Kukkonen]

On 11 April 2017 at 09:20, Eswaran Vinothkumar (BEG/PJ-IOT-EL) <
vinothkumar.eswa...@de.bosch.com> wrote:

> Hallo,
>
>
>
> For our new project we are planning to use Yocto as a build system to
> build customized Linux distribution. I have already created a BSP for our
> customized hardware with Linux kernel, U-boot and UBIFS rootfs image.
>
>
>
> We are internally using a middleware which acts as an abstraction to
> underlying operating system and provides APIs to application layers. Now
> the task is to port the middleware to Yocto. The middleware contains lot of
> make files and folders which are interdependent and I am at lost on how to
> start.
>
> I have some 20 directories which contains makefiles and autotool
> configure.ac files to generate lib files.
>
>
>
> As of now I have planned to create a new Yocto layer called
> meta-middleware and a recipe file for individual folders. I then create a
> package group which will include all these recipes and can include this
> package group as dependency in the recipes of meta-application layer. I am
> facing a problem like I have to include headers from other recipes. In this
> case to include the headers , is it enough to add “DEPENDS = recipename” ?
>

Yes, a DEPENDS should be all that's needed in the normal case. The
assumption is that the recipe you depend on installs the headers and
libraries like it should -- these will then be made available in the
sysroot of the recipe you are compiling (the location and nature of this
sysroot depends on the version of yocto). If your autotools setup is well
behaving the recipes should be fairly straight forward to write.

If you have issues with not finding headers, start by making sure that the
recipe you depend on installs things correctly: see e.g.
$WORKDIR/sysroot-destdir/ to see files that should become available in the
sysroot of a anyone depending on this recipe. If that looks fine, make sure
the depending project is doing something sane to find the headers (like
using pkg-config): see e.g. $WORKDIR/temp/log.do_configure.

Better advice probably requires you to actually show a problem case and
mention the version of Yocto you are using.

HTH,
  Jussi


> I know my question is relatively vague, but anybody who ported middleware
> from another build systems like ptxdist would have faced similar issues.
> Any input on how you planned to port these source files to Yocto would be
> helpful.
>
>
>
>
>
> Mit freundlichen Grüßen / Best regards
>
>
> *Vinothkumar Eswaran BEG-PT/PJ-IOT1*
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] gobject introspection needing pygobject (cross-compilation)

[Jussi Kukkonen]

On 31 March 2017 at 09:06,  wrote:

> I've got a few packages in my image which need gobject introspection.
> (x86-64 host, ARM target)
> One is building fine, but the other - NetworkManager - is failing to
> generate the introspection data because it can't analyse the cross-compiled
> library. Apparently it uses pygobject in doing this, and thus needs a
> version of that for the target architecture.
> Are there steps I can take to achieve this? I guess it needs some 'qemu'
> technique as with other the G-I support mechanisms?
>

It's unlikely that python (or anything other than target versions of
gi-ir-compiler/g-ir-scanner) is needed for generating introspection data.
A quick look at configure.ac seems to imply it's actually trying to build
some documentation with python using the generated GIR data...

Maybe check if the pregenerated docs contain thes documentation bits and
try to disable that docs generation as first solution?

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Current situation with gobject introspection?

[Jussi Kukkonen]

On 28 March 2017 at 11:05,  wrote:
>
> I’m currently using Jethro (though about to move to Krogoth), and have an
external package which need gobject introspection. I’m building on 64-bit
x86, for ARM iMX6 target.
>
> I’ve been searching around to work out if this is possible under Yocto,
but not sure which of the info I’ve found is up-to-date.
>
> So I wondered what the latest [krogoth] situation is – am I likely to be
able to get this package to build, and where/how might I get started?
>
> Thanks

Hi Colin,

Alexander can give you the gory details if needed but the summary is:
Krogoth has full gobject-introspection support (for architectures that qemu
supports), jethro does not.

There is a distro feature but it is backfilled by default so no action
should be needed. For many libraries you only need to inherit the class,
but do read the fine manual just in case:
http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#enabling-gobject-introspection-support

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] PHP5 Recipe

[Jussi Kukkonen]

On 24 March 2017 at 12:57, Stefano Zuín  wrote:
>
> Good Morning,
>
> I am trying to use php in a simple poky kernel in a core-image-minimal
image. But I have some problems to get it working. I have also tried using
core-image-full-cmdline image having the same result explained after this.
>
> When I cook the recipe everything is OK. I can find inside the
/build/tmp/work/armv5e-poky-linux-gnueabi/php/5.6.23-r0/image/ directory
all the necessary files to have php running. but unfortunately, when I run
the emulator with my image I can't find all these files. Just in
/usr/lib/php5/php/ are Structures and XML directories. I have also added in
my conf/local.conf file IMAGE_INSTALL_append=" php".


Hi,

It'll help if you are more specific: which files did you expect to see but
did not?

Alternatively, you can look at the FILES_* variables in the recipe (or
$WORKDIR/packages-split/ directories): It's likely that the files you want
are not in "php" but another package like php-cli or php-cgi.

 - Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Morty 2.2.1 build failure

[Jussi Kukkonen]

On 23 March 2017 at 22:11, Greg Wilson-Lindberg 
wrote:

> Hi Armin & Paul,
>
> First there is nothing in the X log files.
> I'm building on a desktop machine with 12GB of memory and an 8 core
> processor running Kubuntu 14.04.
> I added the PARALLEL_MAKE parameter set to 4, no effect, still built with
> 8 threads, crashed.
> Set BB_NUMBER_THREADS to 4, built with 4 threads, still crashed.
>

Getting thrown out of your desktop environment probably indicates the core
problem is outside of Yocto -- this is still a fine place to discuss the
issue, just pointing it out. You could keep an eye on 'top' sorted by %MEM
while doing a build: my theory here is that something (like the monstrous
amount of IO) that the build does could trigger a desktop component to do
something stupid that cascades into your desktop shell exiting/crashing.
This could show up as something using more and more memory at some point
during the build.

Hope this helps, sorry for lack of definitive answers,
  Jussi



>
> Regards,
> Greg
>
> > -Original Message-
> > From: akuster [mailto:akus...@mvista.com]
> > Sent: Thursday, March 23, 2017 12:33 PM
> > To: Greg Wilson-Lindberg 
> > Cc: Paul Eggleton ;
> yocto@yoctoproject.org
> > Subject: Re: [yocto] Morty 2.2.1 build failure
> >
> >
> >
> > On 03/23/2017 12:25 PM, Paul Eggleton wrote:
> > > That's really bizarre. There shouldn't be anything in a bitbake build
> > > that could cause anything like this (other than possibly how intensive
> > > it is, which might trigger out-of-memory or an underlying
> > hardware/software failure).
> >
> > I usually get my builds to reboot my system when I build on a loptop. I
> have
> > not seen this on a tower style work station. You may want to play with
> the
> > BB_NUMBER_THREADS=# and PARALLEL_MAKE = "-j #" settings in your
> > local.conf.
> >
> > - armin
> > >
> > > Assuming the X session is ending is there anything in your
> > > ~/.xsession-errors or /var/log/Xorg.*.log?
> > >
> > > Cheers,
> > > Paul
> > >
> > > On Friday, 24 March 2017 5:58:24 AM NZDT Greg Wilson-Lindberg wrote:
> > >> Hi Paul,
> > >>
> > >> I looked in the logs from the failure yesterday and couldn't find
> > >> anything, so I restarted the build and it ran for about another 1000
> > >> steps before crashing again. I still can't find anything in any of
> > >> the logs, syslog, kern.log, auth.log, etc.
> > >>
> > >> Cheers,
> > >> Greg
> > >>
> > >>> -Original Message-
> > >>> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> > >>> Sent: Thursday, March 23, 2017 2:49 AM
> > >>> To: Greg Wilson-Lindberg 
> > >>> Cc: yocto@yoctoproject.org; akuster808 
> > >>> Subject: Re: [yocto] Morty 2.2.1 build failure
> > >>>
> > >>> On Thursday, 23 March 2017 9:23:24 AM NZDT Greg Wilson-Lindberg
> > wrote:
> >  I tried it again this morning and it did get past the file not
> >  found error.
> >  But when it gets above step 4000 somewhere it gets an error that
> >  kills not just the yocto build but the full login session. I'm left
> >  staring at the Linux Login screen.
> > >>> Your machine isn't running out of RAM by any chance, triggering the
> > >>> OOM killer? Anything indicative in your system logs?
> > >>>
> > >>> Cheers,
> > >>> Paul
> > >>>
> > >>> --
> > >>>
> > >>> Paul Eggleton
> > >>> Intel Open Source Technology Centre
> > >
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Morty 2.2.1 build failure

[Jussi Kukkonen]

On 22 March 2017 at 22:23, Greg Wilson-Lindberg 
wrote:

> Hi Armin, et al,
>
> I tried it again this morning and it did get past the file not found
> error. But when it gets above step 4000 somewhere it gets an error that
> kills not just the yocto build but the full login session. I'm left staring
> at the Linux Login screen. I originally saw this problem with a git clone
> of 16.0.0, and figured it was a git problem, tried building from a download
> of the 16.0.1 bz2 file when I ran into the file not found error.
>

The "file" git repo was broken twice in the past week but current poky
master branch (current commit 49c2df5652d2) and morty branch (current
commit e292e935b077) do fetch it correctly at the time of writing.

Personally I recommend not using the tarball releases: stick to git
branches (and remember to pull once in a while) as they are likely to get
fixes to issues like these faster.

HTH,
  Jussi


>
> At this point I'm not sure what I can pass on to the list to help find the
> bug, if there are some switches that I can set to get more debug info, or
> maybe something is already saved that I can send that will help?
>
> Regards,
> Greg
>
> > -Original Message-
> > From: yocto-boun...@yoctoproject.org [mailto:yocto-
> > boun...@yoctoproject.org] On Behalf Of akuster808
> > Sent: Tuesday, March 21, 2017 7:07 PM
> > To: yocto@yoctoproject.org
> > Subject: Re: [yocto] Morty 2.2.1 build failure
> >
> >
> > Greg,
> >
> > On 03/21/2017 04:29 PM, Greg Wilson-Lindberg wrote:
> > > Hello List,
> > >
> > > I got a copy of the book "Embedded Linux Systems with the Yocto
> Project"
> > at the SCALE 15x conference and this prompted me to try building the
> Yocto
> > Poky build before getting the Boot to Qt Yocto build environment.
> > >
> > > I tried building on 2 x86 systems, a 64 bit system at work and a 32
> bit system
> > at my home, both failed in the same way:
> > >
> > > gwilson 11:06:54:~/yocto/poky-morty-16.0.1$ source ./oe-init-build-env
> > > You had no conf/local.conf file. This configuration file has therefore
> > > been created for you with some default values. You may wish to edit it
> > > to, for example, select a different MACHINE (target hardware). See
> > > conf/local.conf for more information as common configuration options
> are
> > commented.
> > >
> > > You had no conf/bblayers.conf file. This configuration file has
> > > therefore been created for you with some default values. To add
> > > additional metadata layers into your configuration please add entries
> to
> > conf/bblayers.conf.
> > >
> > > The Yocto Project has extensive documentation about OE including a
> > > reference manual which can be found at:
> > >  http://yoctoproject.org/documentation
> > >
> > > For more information about OpenEmbedded see their website:
> > >  http://www.openembedded.org/
> > >
> > >
> > > ### Shell environment set up for builds. ###
> > >
> > > You can now run 'bitbake '
> > >
> > > Common targets are:
> > >  core-image-minimal
> > >  core-image-sato
> > >  meta-toolchain
> > >  meta-ide-support
> > >
> > > You can also run generated qemu images with a command like 'runqemu
> > qemux86'
> > > gwilson 11:07:08:~/yocto/poky-morty-16.0.1/build$
> > > gwilson 11:07:10:~/yocto/poky-morty-16.0.1/build$
> > > gwilson 11:07:11:~/yocto/poky-morty-16.0.1/build$ bitbake
> > > core-image-sato Parsing recipes: 100%
> > >
> > |#
> > ###| Time: 0:00:29 Parsing of 864
> > .bb files complete (0 cached, 864 parsed). 1318 targets, 50 skipped, 0
> masked,
> > 0 errors.
> > > NOTE: Resolving any missing task queue dependencies
> > >
> > > Build Configuration:
> > > BB_VERSION= "1.32.0"
> > > BUILD_SYS = "x86_64-linux"
> > > NATIVELSBSTRING   = "Ubuntu-14.04"
> > > TARGET_SYS= "i586-poky-linux"
> > > MACHINE   = "qemux86"
> > > DISTRO= "poky"
> > > DISTRO_VERSION= "2.2.1"
> > > TUNE_FEATURES = "m32 i586"
> > > TARGET_FPU= ""
> > > meta
> > > meta-poky
> > > meta-yocto-bsp= ":"
> > >
> > > NOTE: Fetching uninative binary shim from
> > > http://downloads.yoctoproject.org/releases/uninative/1.4/x86_64-native
> > > sdk-
> > libc.tar.bz2;sha256sum=101ff8f2580c193488db9e76f9646fb6ed38b65fb76
> > > f403acb0e2178ce7127ca
> > > --2017-03-20 11:07:57--
> > > http://downloads.yoctoproject.org/releases/uninative/1.4/x86_64-native
> > > sdk-libc.tar.bz2 Resolving downloads.yoctoproject.org
> > > (downloads.yoctoproject.org)... 198.145.20.127 Connecting to
> > > downloads.yoctoproject.org
> > (downloads.yoctoproject.org)|198.145.20.127|:80... connected.
> > > HTTP request sent, awaiting response... 200 OK
> > > Length: 2473216 (2.4M) [application/octet-stream] Saving to:
> > > '/home/gwilson/yocto/poky-morty-
> > 16.0.1/build/downloads/uninative/101ff8f2580c193488db9e76f9646fb6ed38b
> > 

Re: [yocto] [qa-tools][PATCH] full-test-cycle-wrapper: Correct qemu-auto variables

[Jussi Kukkonen]

On 16 March 2017 at 17:34,  wrote:
>
> From: Jose Perez Carranza 
>
> Update variables for creating test runs for qemu ato component
>
> Signed-off-by: Jose Perez Carranza 
> ---
>  scripts/full-test-cycle-wrapper.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/full-test-cycle-wrapper.sh
b/scripts/full-test-cycle-wrapper.sh
> index f52cd96..3a6ba0f 100755
> --- a/scripts/full-test-cycle-wrapper.sh
> +++ b/scripts/full-test-cycle-wrapper.sh
> @@ -82,8 +82,8 @@ create_yocto(){
> create_test_run "${1}" "core-image-sato-sdk_ANYQEMU"
>
> #QEMUs Autos
> -   EVIRONMETS=("qemu-x86" "qemuarm" "qemuarm64" "qemumips" "qemumips64"
"qemuppc" "qemux86-64" "qemux86-lsb" "qemux86_64-lsb")
> -   ECUTION_TYPE="AUTO"
> +   ENVIRONMETS=("qemu-x86" "qemuarm" "qemuarm64" "qemumips" "qemumips64"
"qemuppc" "qemux86-64")

It seems this is in master already so I'll just mention the typo for
future: ENVIRONMETS should probably be ENVIRONMENTS in whole file.

  Jussi

> +   EXECUTION_TYPE="AUTO"
> create_test_run "${1}" "core-image-sato-sdk_ANYQEMU"
>
> #QEMUs Autos LSB
> --
> 2.11.0
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] rpi-base.inc: Add xf86-input-evdev to XSERVER

[Jussi Kukkonen]

On 16 February 2017 at 04:14, Gary Thomas  wrote:

> On 2017-02-16 02:45, Andrei Gherzan wrote:
>
>> On Mon, Feb 13, 2017 at 12:25:48AM +0900, Yusuke Mitsuki wrote:
>>
>>> In order to fix problem that mouse does not work.
>>>
>>> This is removed c40558173ffd96c499d101155f6c4c2be85d9f0f.
>>> However mouse does not worked from this.
>>> ---
>>>  conf/machine/include/rpi-base.inc | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/conf/machine/include/rpi-base.inc
>>> b/conf/machine/include/rpi-base.inc
>>> index e069e70..051c717 100644
>>> --- a/conf/machine/include/rpi-base.inc
>>> +++ b/conf/machine/include/rpi-base.inc
>>> @@ -11,6 +11,7 @@ XSERVER = " \
>>>  xserver-xorg \
>>>  ${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics",
>>> "xserver-xorg-extension-glx", "", d)} \
>>>  ${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics",
>>> "xf86-video-modesetting", "xf86-video-fbdev", d)} \
>>> +xf86-input-evdev \
>>>  "
>>>
>>>  KERNEL_DEVICETREE ?= " \
>>> --
>>> 2.7.4
>>>
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>> CC-ing schnitzelt...@googlemail.com as he might have an opinion about
>> this. I personally don't really hold on any of the options.
>>
>
> I think it's the right thing to do, in fact, I was preparing a
> similar patch myself.  The change that removed this argued that
> it was not the responsibility of the BSP layer, but if you look
> around at other BSP layers, almost all of them do include this
> driver as part of their X server setup.  It also lets X work
> again on the RaspberryPi "out of the box" with the simplest
> configuration - HDMI display + USB keyboard & mouse.
>
> +1


Out of interest: Why is xf86-input-libinput not appropriate for these
setups? I honestly did not know of a use case where -evdev would work but
-libinput would not...

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Getting build dependencies correct

[Jussi Kukkonen]

On 13 February 2017 at 08:02, Gary Thomas  wrote:

> I'm trying to work with a new tool that creates executables
> for my target.  This tool has a shared library and some include
> files.  What I need to figure out is how to run the tool in my
> build environment such that it uses those files to create an
> executable for my target board.
>
> The tool is created by some recipe xxx.  I have enabled both
> the target version and the xxx-native version (using BBCLASSEXTEND)
> and end up with these files in the tmp/sysroots
>
> gthomas@europa:p8701_2016-10-22$ find tmp/sysroots-components/armv7a
> hf-neon/am335x-pru-support
> tmp/sysroots-components/armv7ahf-neon/am335x-pru-support
> tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/sysroot-providers
> tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/
> sysroot-providers/am335x-pru-support
> tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/usr
> tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/usr/lib
> tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/
> usr/lib/libprussdrv.so.0
> tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/
> usr/lib/libprussdrv.so.0.0
> tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/usr/include
> tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/usr/include/pruss
> tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/
> usr/include/pruss/pruss_intc_mapping.h
> tmp/sysroots-components/armv7ahf-neon/am335x-pru-support/
> usr/include/pruss/prussdrv.h
> gthomas@europa:p8701_2016-10-22$ find tmp/sysroots-components/x86_64
> /am335x-pru-support-native/
> tmp/sysroots-components/x86_64/am335x-pru-support-native/
> tmp/sysroots-components/x86_64/am335x-pru-support-native/sysroot-providers
> tmp/sysroots-components/x86_64/am335x-pru-support-native/sys
> root-providers/am335x-pru-support-native
> tmp/sysroots-components/x86_64/am335x-pru-support-native/usr
> tmp/sysroots-components/x86_64/am335x-pru-support-native/usr/lib
> tmp/sysroots-components/x86_64/am335x-pru-support-native/usr
> /lib/libprussdrv.so.0
> tmp/sysroots-components/x86_64/am335x-pru-support-native/usr
> /lib/libprussdrv.so.0.0
> tmp/sysroots-components/x86_64/am335x-pru-support-native/usr/include
> tmp/sysroots-components/x86_64/am335x-pru-support-native/usr/include/pruss
> tmp/sysroots-components/x86_64/am335x-pru-support-native/usr
> /include/pruss/pruss_intc_mapping.h
> tmp/sysroots-components/x86_64/am335x-pru-support-native/usr
> /include/pruss/prussdrv.h
> tmp/sysroots-components/x86_64/am335x-pru-support-native/usr/bin
> tmp/sysroots-components/x86_64/am335x-pru-support-native/usr/bin/pasm
>
> The question becomes how to make use of this in a separate recipe
> that wants to use both the 'pasm' tool, as well as the include files
> and library from the 'pruss' support.
>
> I tried to use
>   DEPENDS="am335x-pru-support"
> as well as
>   DEPENDS="am335x-pru-support-native"
> in my recipe, but the correct sysroot is never found (e.g.
> 
> is not in my search path).
>

You should probably depend on both: am335x-pru-support-native because you
want to run the binary, am335x-pru-support because if want to get the
target library to link with.

You should check the actual  recipe sysroots in WORKDIR/recipe-sysroot* to
see what is available during the build.

- Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] DEPENDS only half working

[Jussi Kukkonen]

On 1 February 2017 at 12:48, Patrick Ohly  wrote:

> On Wed, 2017-02-01 at 10:38 +, colin.helliw...@ln-systems.com wrote:
> > I’ve got an odd problem with a pair of recipes:
> >
> > App ‘bar’ uses ‘libfoo’, so I’ve set a DEPENDS in bar.bb – I can see
> > this is being half picked up, because ‘bitbake bar’ shows both builds
> > being started. However bar isn’t waiting on libfoo – bar tries to
> > compile before libfoo has even finished configuring, let alone
> > compiled and installed it’s header (foo_lib.h) into sysroot.
> >
> > I think the recipes are probably otherwise correct - if I ‘bitbake
> > libfoo’ then ‘bitbake bar’ then all works.
> >
> > I’ve looked at some simple lib recipes within poky (e.g.
> > libwebp_0.4.3.bb / webkitgtk_2.8.5.bb), and can’t spot anything
> > wrong/missing. Not sure if libfoo should have any ‘install’ or similar
> > sections, or any FILES_ settings, but I was [naively…?] hoping that
> > the inherited classes will be sorting out all that generic kinda
> > stuff.
>
> [...]
>
> > DEPENDS_${PN} = "libfoo"
>   ^
> This needs to be just "DEPENDS". DEPENDS sets the dependencies for the
> compilation of the entire recipe, whereas...
>
> > RDEPENDS_${PN} = "libfoo"
>
> ... RDEPENDS is for runtime dependencies specific packages and thus has
> _ as suffix ($PN = bar in this case).
>
>
You also don't need the RDEPENDS_${PN} line in your recipe at all in normal
cases: if your app links with libfoo, the runtime dependency will be
automatically added.

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] sstate-cache and native recipes

[Jussi Kukkonen]

On 18 January 2017 at 11:51, Gary Thomas  wrote:

> On 2017-01-18 10:35, Burton, Ross wrote:
>
>>
>> On 18 January 2017 at 09:13, Gary Thomas  g...@mlbassoc.com>> wrote:
>>
>> * glib-2.0-native depends on ${DISTRO_FEATURES}
>>   To me this seems silly as "native" should be "native" and
>>   not depend on any distribution settings.  Here's the code
>>   that's causing it (in do_install)
>>
>> if [ -f 
>> ${D}${datadir}/installed-tests/glib/gdbus-serialization.test
>> ]; then
>> if ${@bb.utils.contains("DISTRO_FEATURES", "x11",
>> "false", "true", d)}; then
>> rm ${D}${datadir}/installed-tests
>> /glib/gdbus-serialization.test
>> fi
>> fi
>>
>>   Obviously this isn't important for a native package.  Any
>>   suggestions on how I might keep this from creeping in?
>>
>>
>> The tests are only installed for target builds anyway, so that do_install
>> part could be target-specific.
>>
>
> How would one change the recipe to reflect that?  Is there an
> override that effectively says "not -native"?
>

do_install_append_class-target () should work.

 - Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] x86 testing

[Jussi Kukkonen]

On 18 January 2017 at 09:02, Gary Thomas  wrote:

> I'm trying to track down some recent changes in the X server
> (using the latest Poky/Yocto master).  I've had failures on
> a number of the embedded targets I work with, so I thought
> I'd give it a go on platforms with a larger base - x86 machines.


> It used to be that I could run qemu and it would pop up a separate
> window that emulated a display+keyboard+mouse.  That doesn't seem
> to be the same now, or at least I don't see how to make it work.
>

This is lacking a bit of detail ... What did you try and what failed?

Building a qemux86-64  (or qemux86) image and running it should certainly
work ("runqemu qemux86-64").

Advice on this would be great as I need to test the "native" X
> setup, not VNC connections.
>
> I'd also be happy to try this on real hardware, e.g. my wife's
> laptop, but I need some way to do that non-destructively.  Again,
> pointers would be greatly appreciated.
>

The hddimg is both an installer and a live image: in other words if you
build e.g. a x86-64 core-image-sato you can dd it to a USB disk and boot a
typical laptop from USB without installing anything on hard drive.

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Openembedded-architecture] Patchwork and incoming patch testing

[Jussi Kukkonen]

This looks great, thanks.

On 17 January 2017 at 20:05, Paul Eggleton 
wrote:

> In any event we are now finally in the
> position where our patchwork instance can be relied upon to collect emails,
> and the UI is much improved. This should give us a bit more visibility into
> where patches are at in the process, although we are still working on a few
> places where patch series status needs to be updated (e.g. when a patch
> goes
> into testing).


What's the plan for these status updates -- is the idea that you go to
patchwork UI to see the state of a specific patch set?
Or maybe a reply to either patch sender or even the ML?

On top of patchwork we have built a simple smoke-testing framework called
> "patchtest" [5] along with a suite of corresponding tests for OE [6]. These
> tests are fairly simplistic at this point but check the basics such as
> whether
> a patch has been properly signed off, etc. We should soon start seeing
> replies
> sent to the mailing list and to submitters with results if there are any
> failures, saving us from noticing and pointing out some of the more obvious
> classes of mistakes.


 Is there a reason for patchwork only showing "success" or "failure" in the
web ui, instead of linking to test results at least in in the failure case?



 - Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] setting up autobuilder on local machine

[Jussi Kukkonen]

On 19 December 2016 at 15:28, Mirza Krak  wrote:
>
> > Thank you for your fast responses. Generating the htpasswd file my
> > self did the trick. Now I can login. The full command was (as you
> > suggested I used the one in autobuilder git repo under ./bin):
> >
> > ./htpasswd -b -c   
> >
> > Forced a build of my configuration now and hoping for the best :).
>
> And it was not green all the way.
>
> I get an error that I do not get how to get around. The error message is:
>
> ERROR: Unable to parse
>
/home/mirzak/project/yocto-autobuilder/yocto-autobuilder-mender-rpi/yocto-worker/nightly-mender-rpi/build/meta-mender/conf/layer.conf:
> [Errno 2] file
/home/mirzak/project/yocto-autobuilder/yocto-autobuilder-mender-rpi/yocto-worker/nightly-mender-rpi/build/meta-mender/conf/layer.conf
> not found
>
> The error message I understand. But I do not understand why it adds
> meta-mender to bblayers files. I did not tell it to do that, because
> meta-mender contains layers that I want to include. Similar to
> meta-openembedded (which is also added to bblayers).
>

I'm not an expert but your nightly-mender-rpi.conf contains this:
'layerdirs': ['meta-yocto', 'meta-raspberrypi',
'meta-mender/meta-mender-core', 'meta-mender/meta-mender-raspberrypi',
'oe-meta-go', 'meta-openembedded/meta-oe']

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] live" image: iso and ext4 artifacts

[Jussi Kukkonen]

On 15 December 2016 at 09:30, Takashi Matsuzawa 
wrote:
>
> Hello Yocto.
>
> I am trying x86-64 BSP image (based on jethro version).
> It has following root filesystem type, and it generats .hddimg file
that I am using.
>
> > IMAGE_FSTYPES = "live"
>
> The issue is that in addition to .hddimg, it produces following image
files and it sometimes cause lack of disk space error on my build PC.
>
> > 2422489088 -intel-corei7-64-20161215004421.hddimg
> > 2402287616 -intel-corei7-64-20161215004421.iso
> > 2368578560 -intel-corei7-64-20161215004421.rootfs.ext4
>
> I do not need xxx.iso and .ext4 files as final output, though I
understand that .ext4 file may have been used to produce xxx.hddimg
file.

I think you should be able to define NOISO=1.

The rootfs is indeed used to produce the actual images, you could delete it
afterwards... but before you spend valuable time writing shell scripts,
consider a new SSD: 500GB is probably less than 150€ by now.

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] possible bug with dpkg-native with sstate-cache

[Jussi Kukkonen]

On 14 December 2016 at 06:59, Anders Oleson  wrote:

> I have found what I think is a sneaky nasty bug when using package_deb with
> SSTATE_MIRRORS on RPM based build hosts. Below is a short description of
> what
> I found and our workaround. A patch that adds a patch that is applied to
> the
> packager that packages the real packager.  To avoid this sneaking failure
> mode
> when building without building when using the cache (its all so very
> meta, btw.).

Don't ask how we found this; it wasn't pretty.
>
> Note: the fix approach below actually patches dpkg on the target too,
> but I do not
> know how to easily make the patch only apply to dpkg-native and not also
> dpkg.
> But in this case it should be fine anyhow; there is no reason that dpkg on
> the
> target should not behave this way too. I have checked the upstream and the
> lines in question have never been touched - it is possible they may want to
> eventually upstream this too (???).
>

I have to point out that the upstream developers are usually not going to
come to us looking for patches :) If we want patches upstreamed we have to
go to them and in fact there is a bit of process to to track this, see
below.

For future knowledge, is there an easy way to have a SRC_URI list that is
> different for dpkg-native than for dpkg?
>

I think this is actually already used in dpkg recipe:
SRC_URI_append_class-native = "..."
but as you said this doesn't seem required in this case.

Also, this is my first post to the group, so apologies if this is not the
> right place or way to upload a potential patch; set me straight if so.
>

Thanks and no problem: openembedded-c...@lists.openembedded.org would be
the correct place for meta/ patches. Please take a look at

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#how-to-submit-a-change
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

Some specific things you may want to look at:
* Send the commit as part of an email, not as attachment (git "send-email"
  and/or "create-pull-request/send-pull-request" script are good tools)
* Signed-off-by tag on both the commit and in any patch files in it
* Upstream-Status tag in any patch files in the commit

Thanks,
 Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-wm][PATCH 3/3] Fix "unused variable" warnings

[Jussi Kukkonen]

Some were removed as unused, some just silenced with the gcc
attribute since they were actually somehow used and fixing
otherwise would have been more invasive.

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 src/ewmh.c| 6 --
 src/mbtheme.c | 7 ---
 src/wm.c  | 2 +-
 3 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/src/ewmh.c b/src/ewmh.c
index 17ea48a..afcabe7 100644
--- a/src/ewmh.c
+++ b/src/ewmh.c
@@ -1257,8 +1257,9 @@ int
 ewmh_utf8_len(unsigned char *str) /* Only parse _validated_ utf8 */
 {
   unsigned char *p = str;
+  int len, result = 0;
+  __attribute__((unused)) int mask;
 
-  int mask, len, result = 0;
   while (*p != '\0')
 {
   UTF8_COMPUTE(*p, mask, len);
@@ -1273,8 +1274,9 @@ int
 ewmh_utf8_get_byte_cnt(unsigned char *str, int num_chars)
 {
   unsigned char *p = str;
+  int len, result = 0;
+  __attribute__((unused)) int mask;
 
-  int mask, len, result = 0;
   while (*p != '\0' && num_chars-- > 0)
 {
   UTF8_COMPUTE(*p, mask, len);
diff --git a/src/mbtheme.c b/src/mbtheme.c
index 42459a0..821195a 100644
--- a/src/mbtheme.c
+++ b/src/mbtheme.c
@@ -602,7 +602,6 @@ theme_frame_paint( MBTheme *theme,
   MBThemeFrame *frame;
   MBPixbufImage*img;
   MBThemeLayer *layer_label = NULL, *layer_icon = NULL;
-  struct list_item *layer_list_item;
   int   label_rendered_width;
   int   decor_idx = 0;
   MBDrawable   *drawable = NULL;
@@ -699,8 +698,6 @@ theme_frame_paint( MBTheme *theme,
   img = theme->img_caches[frame_type];
 }
 
-  layer_list_item = frame->layers;
-
   layer_label = (MBThemeLayer*)list_find_by_id(frame->layers, LAYER_LABEL);
 
   /* Figure out text alignment + positioning */
@@ -981,7 +978,6 @@ theme_frame_menu_highlight_entry(Client *c,
   MBDrawable*drw;
   MBThemeFrame  *frame;
   MBFont*font;
-  MBColor   *color;
   Client*entry = (Client *)button->data;
   intoffset, item_h;
 
@@ -991,7 +987,6 @@ theme_frame_menu_highlight_entry(Client *c,
 return;
 
   font  = frame->font;
-  color = frame->color;
 
   if (frame->hl_color)
 {
@@ -1982,7 +1977,6 @@ parse_color_tag (MBTheme *theme,
 XMLNode *node)
 {
   MBColor *color = NULL;
-  int alpha;
   char *id = get_attr(node, "id");
   char *spec   = get_attr(node, "def");
 
@@ -1990,7 +1984,6 @@ parse_color_tag (MBTheme *theme,
 {
   fprintf(stderr, "matchbox *warning*: alpha attribute in theme.xml color 
tar is depreciated\nUse def='rrggbbaa' format instead to 
specify alpha\n"); 
 }
-  else alpha = 0xff;
 
   dbg("%s() id : %s , def : %s\n", __func__, id, spec);
 
diff --git a/src/wm.c b/src/wm.c
index cb033c6..0823fef 100644
--- a/src/wm.c
+++ b/src/wm.c
@@ -2621,7 +2621,7 @@ wm_activate_client(Client *c)
   /* As matchbox works around 'main' windows ( apps/main and desktop wins).
 We need to sync extra stuff up when displaying a new one.
*/
-  Bool switching_from_to_fullscreen = False;
+  __attribute__((unused)) Bool switching_from_to_fullscreen = False;
 
   /* save focus state for transient dialogs of prev showing main win */
 
-- 
2.11.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-wm][PATCH 2/3] matchbox-remote: Fix execvp() argument

[Jussi Kukkonen]

The second argument is a NULL-terminated array.

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 src/matchbox-remote.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/matchbox-remote.c b/src/matchbox-remote.c
index 9f62523..e6cc076 100644
--- a/src/matchbox-remote.c
+++ b/src/matchbox-remote.c
@@ -143,11 +143,13 @@ mbcommand(int cmd_id, char *data) {
/* Check if desktop is running */
if (!XGetSelectionOwner(dpy, desktop_manager_atom))
 {
+  char *exec_args[] = { NULL };
+
   fprintf(stderr, "Desktop not running, exiting...\n");
   switch (fork())
 {
 case 0:
-  execvp ("mbdesktop", NULL);
+  execvp ("mbdesktop", exec_args);
   break;
 case -1:
   fprintf(stderr, "failed to exec mbdesktop");
-- 
2.11.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-wm][PATCH 1/3] ewmh: Actually set _NET_CURRENT_DESKTOP

[Jussi Kukkonen]

The property wasn't being set properly (both value and crucially
number of elements were wrong), leading to an assert in debug
chromium.

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 src/ewmh.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/ewmh.c b/src/ewmh.c
index a736037..17ea48a 100644
--- a/src/ewmh.c
+++ b/src/ewmh.c
@@ -137,7 +137,8 @@ void
 ewmh_init_props(Wm *w)
 {
   long num_desktops = 1;
-  
+  long current_desktop = 0;
+
   set_compliant(w);
   set_supported(w);
   
@@ -147,7 +148,7 @@ ewmh_init_props(Wm *w)
   
   XChangeProperty(w->dpy, w->root, w->atoms[_NET_CURRENT_DESKTOP],
  XA_CARDINAL, 32, PropModeReplace,
- (unsigned char *)_desktops, 0);
+ (unsigned char *)_desktop, 1);
 }
 
 int
-- 
2.11.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-wm][PATCH 0/3] matchbox-window-manager fixes

[Jussi Kukkonen]

One actual bug fix (YOCTO #10635) and a few build cleanups.

Thanks,
  Jussi


The following changes since commit 9fd1806dfa7c8f2202db18b7bc880857a3019f8c:

  Bump version, update bug-report URI (2016-06-02 14:46:42 +0300)

are available in the git repository at:

  git://github.com/jku/matchbox-window-manager net-current-desktop
  https://github.com/jku/matchbox-window-manager/tree/net-current-desktop

Jussi Kukkonen (3):
  ewmh: Actually set _NET_CURRENT_DESKTOP
  matchbox-remote: Fix execvp() argument
  Fix "unused variable" warnings

 src/ewmh.c| 11 +++
 src/matchbox-remote.c |  4 +++-
 src/mbtheme.c |  7 ---
 src/wm.c  |  2 +-
 4 files changed, 11 insertions(+), 13 deletions(-)

-- 
2.11.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Kernel too old?

[Jussi Kukkonen]

On 16 November 2016 at 13:29, Gary Thomas  wrote:

> I'm trying to run some user code on a [closed] box that it's
> difficult (maybe impossible) to update the kernel.  To date,
> I've been able to create my own user environment using Yocto
> and then just 'chroot XXX'.  That came to an end today with
> the latest (version 2.2) like this:
>
>   DiskStation> chroot /volume1/MY.test/
>   FATAL: kernel too old
>   DiskStation> cat /proc/version
>   Linux version 2.6.32.12 (root@build5) (gcc version 4.3.2 (GCC) ) #3202
> SMP Fri Mar 1 01:04:06 CST 2013
>
> Where '/volume1/MY.test' is my Yocto-built root file system.
>
> Is there any way around this if I can't update the running kernel?


Modern glibc needs linux 3.2, see
http://repo.or.cz/glibc.git/commit/5b4ecd3f95695ef593e4474b4ab5a117291ba5fc
(apparently on x86* you could still get away with setting OLDEST_KERNEL to
2.6.32).

Cheers,
  Jussi


>
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [sysvinit] Problem with disabling sysvinit service

[Jussi Kukkonen]

On 13 November 2016 at 16:51, Lukasz Majewski  wrote:

> Dear All,
>
> Maybe here I would find answer to question which puzzles me from some
> time.
>
> The problem:
>
> Disable syslog service on startup of sysvinit based board.
> (syslog is defined in e.g. /etc/rc5.d/S20syslog -> /etc/init.d/syslog)
>
> Syslog on my setup is provided by busybox.
>
> I was trying to find where 'update-rc.d ... syslog ...' is called in the
> poky (2.1.2) source tree but without any success.
>
> Then, I've discovered that it is appended to INITSCRIPT_NAME variable
> and further processed by update-rc.d.bbclass
>

> Is there any method/recipe which would allow just removing S20klogd
> symlink from /etc/rcX.d from the created rootfs?
>
>
You should be able to modify (append) the busybox recipe to not create the
symlinks in the first place. I'm not 100% sure what the correct line is
but INITSCRIPT_PARAMS is the variable you want to modify. Maybe something
like this?

INITSCRIPT_PARAMS_${PN}-syslog = "start 80 . stop 20 0 1 6 ."

(that should be the default except with all start runlevels removed)

 - Jussi



> The goal is to have syslog installed (in this case built into busybox),
> but disabled at boot up time.
>
> Any help is more than welcome.
>
> Tanks in advance,
> Łukasz Majewski
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Install mozroot-certdata package on a read only root file system

[Jussi Kukkonen]

On 19 October 2016 at 21:55, Burton, Ross  wrote:

>
> On 18 October 2016 at 23:26, Nick Wareing 
> wrote:
>
>> However I'm running into an issue with a recipe in the meta-mono layer:
>> mozroot-certdata. I see the culprit is the pkg_postint script (
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/re
>> cipes-mono/mozroot-certdata/mozroot-certdata_1.0.0.bb) which needs to
>> modify the root file system on first boot which the build system is
>> correctly flagging as impossible with a read only root file system:
>>
>>
> You'll have to extend the recipe to run mono inside a qemu, there are
> plenty of other recipes that demonstrate how to do this (fontcache and
> gio-module-cache classes come to mind, although they also use intercept
> scripts to avoid running qemu more than once).  Basically, use the qemu
> class.
>

Why qemu? There's a mono-native which I would expect to work unless the
certdata is somehow platform specific (?)

There's also an additional problem that came up on stack overflow:
mozroots.exe is hard coded to output to a specific file so that would have
to be fixed as well.


Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Using debian packages management

[Jussi Kukkonen]

On 17 October 2016 at 17:11, Michel D'HOOGE  wrote:

> Hi,
>
> From time to time I try to use the debian packages management instead of
> RPM because I feel more "at home"... And every time, there is a problem --
> but this time, I felt like I'll try to understand and solve it!
>
> I tried first with core-image-minimal, and it worked.
> But then I switched to core-image-sato and had the following error:
>
> ERROR : core-image-sato-1.0-r0 do_rootfs: Unable to install packages.
> Command '/mnt/Yocto/Fabric-x64/build/tmp/sysroots/x86_64-linux/usr/bin/apt-get
> install --force-yes --allow-unauthenticated apt packagegroup-base-extended
> packagegroup-core-ssh-dropbear dpkg packagegroup-core-x11-base
> packagegroup-core-boot packagegroup-core-x11-sato-games psplash
> packagegroup-core-x11-sato' returned 100:
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created or been
> moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
> packagegroup-core-x11-base : Depends: packagegroup-core-x11-utils but it
> is not going to be installed
> E: Unable to correct problems, you have held broken packages.
>

I suspect this is related to meta-oe taking over some X initialization when
you add it to bblayers -- this  maybe exposes a bug in the deb packaging
implementation. In any case I can say that a deb-based core-image-sato
builds fine without meta-oe.

Note that you may have to wipe TMPDIR after bblayers changes if you're
testing this.

I have a bug on improving the X initialization mess in oe-core vs meta-oe (
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5546) but please file one
on the debian packaging issue if it does not exist yet.

I checked: The package exists in /tmp/deploy/deb/all/
> packagegroup-core-x11-utils_1.0-r40_all.deb, but it is *empty*. It looks
> as if it is just there to create some RDEPENDS in the recipe.
>
>
> So... I played the game to explicitly add packages one by one to the image:
> IMAGE_INSTALL_append_pn-core-image-sato = " packagegroup-core-x11-utils
> xserver-nodm-init x11-common xserver-common"


> But now I have the following error:
> The following packages have unmet dependencies:
>  xserver-common : Conflicts: x11-common but 0.1-r47 is to be installed
>
>
xserver-common RCONFLICTS with x11-common: the package manager is doing
exactly what it was asked to do here (you shouldn't install both of those).

 - Jussi



>
> So my question is:
> Is using debian packages management definitely broken in Yocto? Or has
> someone managed to use it with some tweaking?
>
>
> Many thanks for your feedbacks
> Michel
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH] applets/systray: Allow icons to be smaller

[Jussi Kukkonen]

Don't expand/fill the systray items, align them in the center of the
systray panel. This makes sure the icons are drawn at the size they
expect.

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---

This is related to [YOCTO #9995]: GtkStatusIcon based systray items
render weirdly if the get allocated more space than they expected.


 applets/systray/systray.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/applets/systray/systray.c b/applets/systray/systray.c
index 39698a8..94a5753 100644
--- a/applets/systray/systray.c
+++ b/applets/systray/systray.c
@@ -29,8 +29,9 @@ on_realize (GtkWidget *widget, gpointer user_data)
   tray = (GtkWidget *)na_tray_new_for_screen (screen, orientation);
 
   gtk_widget_show (tray);
-
-  gtk_container_add (GTK_CONTAINER (widget), tray);
+  gtk_widget_set_valign (tray, GTK_ALIGN_CENTER);
+  gtk_widget_set_halign (tray, GTK_ALIGN_CENTER);
+  gtk_box_pack_start (GTK_BOX (widget), tray, FALSE, FALSE, 0);
 }
 
 G_MODULE_EXPORT GtkWidget *
-- 
2.9.3

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [pseudo-native] No real function for mknod

[Jussi Kukkonen]

On 3 October 2016 at 15:02, Michel D'HOOGE  wrote:
>
> Dear all,
>
> Since the end of last week, I try to produce any kind of images, with no
success :-(
>
> Note that even though I'm not a seasoned Yocto user, in more than a year
I managed many times to produce images & SDKs. And this time, I tried
several configs, erased everything and restarted from scratch, etc., but
with always the same problem.
>
> I have the following logs (in grey, so I guess not a warning nor an
error) when running bitbake:
> No real function for mknod:
/mnt/Yocto/Fabric-x64/build/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64/libpseudo.so:
undefined symbol: mknod
> No real function for mknodat:
/mnt/Yocto/Fabric-x64/build/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64/libpseudo.so:
undefined symbol: mknodat

I believe this issue was fixed with a patch in poky master with
commit e090775f7e in May (and later in an upstream pseudo release). Are you
sure you are seeing this with poky master?

 - Jussi

> And at the end, this crashes with:
> ERROR: core-image-minimal-initramfs-1.0-r0 do_rootfs: Unable to install
packages. Command
'/mnt/Yocto/Fabric-x64/build/tmp/sysroots/x86_64-linux/usr/bin/smart
--log-level=warning
--data-dir=/mnt/Yocto/Fabric-x64/build/tmp/work/genericx86_64-poky-linux/core-image-minimal-initramfs/1.0-r0/rootfs/var/lib/smart
install --attempt -y ' returned 1:
>
>
> I tried the poky git repo with krogoth (HEAD & mid-september) and master;
with recipes core-image-minima & core-image-sato.
>
> I know that I always have a warning from bitbake about "Debian-unstable"
not being validated, but so far, it worked.
>
>
> So if any of you has an idea, I'd be most grateful!
> Michel
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-toraxdex] unrecoverable build error

[Jussi Kukkonen]

On 26 September 2016 at 15:00, Karim ATIKI  wrote:
>
> Hi Jussi,
>
> >10-evdev.conf was moved from xserver-xorg to to the driver. If you are
using krogoth, xserver-xorg really should be new enough (>=1.18.0) to not
install the file.
> >Does meta-toradex maybe provide an older xorg?
>
> Actually, I don't know.
> In which kind of file can I find this information ?

Hi and sorry for taking a few days, I missed this message on monday.

You should look for a xserver-xorg_*.bb recipe in the layer.

You haven't mentioned what the layer is exactly, but e.g. git://
git.toradex.com/meta-toradex.git does provide an older xserver:
http://git.toradex.com/cgit/meta-toradex.git/tree/recipes-graphics/xorg-xserver
. Since this layer has a higher BBFILE_PRIORITY than oe-core its
xserver-xorg will be chosen even if the recipe version is lower than the
one in oe-core. That said the README in this layer explicitly states it's
meant for fido branches...

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-toraxdex] unrecoverable build error

[Jussi Kukkonen]

On 25 September 2016 at 09:10, Karim ATIKI  wrote:
>
> hi,
>
> During a core-image-x11  build   (yocto krogoth, meta-toradex) , I got
the following error I never encountered with Yocto:
>
> ERROR: xf86-input-evdev-2_2.10.1-r0 do_populate_sysroot: The recipe
xf86-input-evdev is trying to install files into a shared area when those
files already exist. Those files and their manifest location are:
>
 
/home/kai/yocto/colibri-t20-kts/tmp/sysroots/colibri-t20/usr/share/X11/xorg.conf.d/10-evdev.conf
>  Matched in manifest-colibri-t20-xserver-xorg.populate_sysroot
> Please verify which recipe should provide the above files.

10-evdev.conf was moved from xserver-xorg to to the driver. If you are
using krogoth, xserver-xorg really should be new enough (>=1.18.0) to not
install the file. Does meta-toradex maybe provide an older xorg?


 - Jussi


> The build has stopped as continuing in this scenario WILL break things,
if not now, possibly in the future (we've seen builds fail several months
later). If the system knew how to recover from this automatically it would
however there are several different scenarios which can result in this and
we don't know which one this is. It may be you have switched providers of
something like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev),
in that case you need to execute the clean task for both recipes and it
will resolve this error. It may be you changed DISTRO_FEATURES from systemd
to udev or vice versa. Cleaning those recipes should again resolve this
error however switching DISTRO_FEATURES on an existing build directory is
not supported, you should really clean out tmp and rebuild (reusing sstate
should be safe). It could be the overlapping files detected are harmless in
which case adding them to SSTATE_DUPWHITELIST may be the correct solution.
It could also be your build is including two different conflicting versions
of things (e.g. bluez 4 and bluez 5 and the correct solution for that would
be to resolve the conflict. If in doubt, please ask on the mailing list,
sharing the error and filelist above.
> ERROR: xf86-input-evdev-2_2.10.1-r0 do_populate_sysroot: If the above
message is too much, the simpler version is you're advised to wipe out tmp
and rebuild (reusing sstate is fine). That will likely fix things in most
(but not all) cases.
> ERROR: xf86-input-evdev-2_2.10.1-r0 do_populate_sysroot: Function failed:
sstate_task_postfunc
> ERROR: Logfile of failure stored in:
/home/kai/yocto/colibri-t20-kts/tmp/work/armv7ahf-vfp-poky-linux-gnueabi/xf86-input-evdev/2_2.10.1-r0/temp/log.do_populate_sysroot.639
> ERROR: Task 2181
(/home/kai/yocto/poky-toradex/meta/recipes-graphics/xorg-driver/
xf86-input-evdev_2.10.1.bb, do_populate_sysroot) failed with exit code '1'
>
>
> I cant' get rid of this error. I have deleted the tmp and
sstate-cache...nothing. it always occurs again.
>
>
> Any idea?
>
>
> Z.
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] : error: '__uint128_t' does not name a type

[Jussi Kukkonen]

On 12 September 2016 at 07:39, BHARATH RAJ  wrote:

> Hi All,
>
> I am trying to build one recipes on Yocto2.0 based environment.
>
> However I am seeing following error.I wonder if this is a known problem.
>
> It says error: '__uint128_t' does not name a type
>

Details might help: e.g. what arch are you building for? What are you
building exactly?



> /local/mnt/workspace/narasimha/AGL_NEW/poky/build/tmp-glibc/sysroots/usr/
> include/bits/mathcalls.h:240:1: warning: invoking macro __MATH_PRECNAME
> argument 2: empty macro arguments are undefined in ISO C90 and ISO C++98
> [enabled by default]
> /local/mnt/workspace/narasimha/AGL_NEW/poky/build/tmp-glibc/sysroots/usr/
> include/bits/mathcalls.h:250:31: warning: invoking macro __MATHDECL
> argument 3: empty macro arguments are undefined in ISO C90 and ISO C++98
> [enabled by default]
> /local/mnt/workspace/narasimha/AGL_NEW/poky/build/tmp-glibc/sysroots/usr/
> include/bits/mathcalls.h:279:1: warning: invoking macro __MATHDECL_1
> argument 3: empty macro arguments are undefined in ISO C90 and ISO C++98
> [enabled by default]
>  __MATHCALL (rint,, (_Mdouble_ __x));
>  ^
> /local/mnt/workspace/narasimha/AGL_NEW/poky/build/tmp-glibc/sysroots/usr/
> include/bits/mathcalls.h:240:1: warning: invoking macro __CONCAT argument
> 2: empty macro arguments are undefined in ISO C90 and ISO C++98 [enabled by
> default]
> In file included from /local/mnt/workspace/narasimha/AGL_NEW/poky/build/
> tmp-glibc/sysroots/usr/include/bits/sigcontext.h:27:0,
>  from /local/mnt/workspace/narasimha/AGL_NEW/poky/build/
> tmp-glibc/sysroots/usr/include/signal.h:306,
>  from /local/mnt/workspace/narasimha/AGL_NEW/poky/build/
> tmp-glibc/sysroots/usr/include/glib-2.0/glib/gbacktrace.h:33,
>  from /local/mnt/workspace/narasimha/AGL_NEW/poky/build/
> tmp-glibc/sysroots/usr/include/glib-2.0/glib.h:34,
>  from :0:
> /local/mnt/workspace/narasimha/AGL_NEW/poky/build/tmp-glibc/sysroots/usr/include/asm/sigcontext.h:53:2:
> error: '__uint128_t' does not name a type
>   __uint128_t vregs[32];
>   ^
> /local/mnt/workspace/narasimha/AGL_NEW/poky/build/tmp-glibc/sysroots/usr/include/bits/mathcalls.h:82:1:
> warning: invoking macro __MATHDECL argument 3: empty macro arguments are
> undefined in ISO C90 and ISO C++98 [enabled by default]
> /local/mnt/workspace/narasimha/AGL_NEW/poky/build/tmp-rglibc/sysroots/usr/
> include/bits/mathcalls.h:279:1: warning: invoking macro __MATH_PRECNAME
> argument 2: empty macro arguments are undefined in ISO C90 and ISO C++98
> [enabled by default]
> /local/mnt/workspace/narasimha/AGL_NEW/poky/build/tmp-glibc/sysroots/usr/
> include/bits/mathcalls.h:217:1: warning: invoking macro __MATHDECL_1
> argument 3: empty macro arguments are undefined in ISO C90 and ISO C++98
> [enabled by default]
>  __MATHCALLX (copysign,, (_Mdouble_ __x, _Mdouble_ __y), (__const__));
>  ^
> /local/mnt/workspace/narasimha/AGL_NEW/poky/build/tmp-glibc/sysroots/usr/
> include/bits/mathcalls.h:250:31: warning: invoking macro __MATHDECL_1
> argument 3: empty macro arguments are undefined in ISO C90 and ISO C++98
> [enabled by default]
> /local/mnt/workspace/narasimha/AGL_NEW/poky/build/tmp-glibc/sysroots/usr/
> include/bits/mathcalls.h:250:31: warning: invoking macro __MATH_PRECNAME
> argument 2: empty macro arguments are undefined in ISO C90 and ISO C++98
> [enabled by default]
> /local/mnt/workspace/narasimha/AGL_NEW/poky/build/tmp-glibc/sysroots/usr/
> include/bits/mathcalls.h:217:1: warning: invoking macro __MATH_PRECNAME
> argument 2: empty macro arguments are undefined in ISO C90 and ISO C++98
> [enabled by default]
> /local/mnt/workspace/narasimha/AGL_NEW/poky/build/tmp-glibc/sysroots/usr/include/bits/mathcalls.h:82:1:
> warning: invoking macro __MATHDECL_1 argument 3: empty macro arguments are
> undefined in ISO C90 and ISO C++98 [enabled by default]
> /local/mnt/workspace/narasimha/AGL_NEW/poky/build/tmp-glibc/sysroots/usr/include/bits/mathcalls.h:82:1:
> warning: invoking macro __MATH_PRECNAME argument 2: empty macro arguments
> are undefined in ISO C90 and ISO C++98 [enabled by default]
> /local/mnt/workspace/narasimha/AGL_NEW/poky/build/tmp-glibc/sysroots/usr/
> include/bits/mathcalls.h:241:29: warning: invoking macro __MATHCALL
> argument 2: empty macro arguments are undefined in ISO C90 and ISO C++98
> [enabled by default]
>
>
> Regards
> Bharath
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto and Google protobuffer

[Jussi Kukkonen]

On 1 September 2016 at 12:34, Pietro  wrote:

> Maciej Borzęcki
>  writes:
>
> > On Thu, Sep 1, 2016 at 10:40 AM, Pietro  wrote:
> >> Maciej Borzęcki
> >>  writes:
> >>
> >>> On Wed, Aug 31, 2016 at 6:44 PM, Pietro 
> wrote:
>  Hi all,
> 
>  I am new to the Yocto building system and I could be talking
> nonsense. I
>  used to work with buildroot time ago and I remember there is an area
>  where compiled software/packages/tools previously built are "staged"
> and
>  used when building other packages.
> 
>  Is there something like that available with Yocto ? Specifically I
> would
>  like to add a package which uses the Google Protocol Buffer, I do not
> have
>  administrator rights on the machine and I can't install the packages I
>  need system wise.
> 
>  Is it possible to add recipes and use them at building time without
>  including them in the image being generated ?
> 
>  A good example for that would be the protoc, the protocol buffer
> description
>  file compiler.
> 
> >>>
> >>> There is a recipe for protobuf in meta-oe (2.6.1). All you need to do,
> >>> is include meta-oe in your layers (bblayers.conf) and have
> >>> protobuf-native listed in DEPENDS inside your package recipe.
> >>>
> >>> The protoc compiler will be available in the PATH when package is
> >>> being built, so autotools checks like AC_CHECK_PROG/AC_PATH_PROG
> >>> should be able to find it.
> >>>
> >>> Cheers,
> >>> --
> >>> Maciej Borzecki
> >>> RnDity
> >> Thanks a lot.
> >>
> >> I have added the DEPENDS line and it indeed downloads and build the some
> >> protobuf related stuff, where did you get the dependency name from ?
> >> I can't see the protobuf-native as a recipe in the meta-oe website :
> >>
> >> https://layers.openembedded.org/layerindex/branch/master/layer/meta-oe/
> >
> > It's just a mechanism that allows for building the native (i.e. for
> > the host) packages, and these are autmatically named ${PN}-native.
> > There should a BBCLASSEXTEND = "..native.." stanza inside the protobuf
> > recipe that enables this feature.
> >
> >>
> >> I have just realised that GRPC (http://www.grpc.io/) is needed for my
> >> project, it is a library which uses the protobuffers, is there a
> >> recipe/package which provides them around or do I need to create my own
> >> recipe ?
> >
> > You can try searching for a recipe at http://layers.openembedded.org
> > If there's none, try to write your own. This might be a good changes
> > to get yourself acquainted with `devtool` tool that will help you in
> > the process.
> >
> >>
> >> I would like to check the root filesystem being generated as part of the
> >> build process, where is it ?
> >>
> >
> > ${TMPDIR}/_//../rootfs
> >
> > for instance, for my current build:
> >
> > tmp/work/vexpress_qemu-poky-linux-gnueabi/core-image-
> minimal/1.0-r0/rootfs
> >
> > --
> > Maciej Borzecki
> > RnDity
>
> Thanks, much appreciated.
>
> Do you know where the software which is not included in the image - such
> us protoc - is it stored ?
>

The sysroots are in ${TMPDIR}/sysroots/: The native sysroot (probably
x86_64-linux) will be one of those.

The corresponding protobuf work directory will be in
${TMPDIR}/work//protobuf

See the Yocto dev manual and reference manual for more details about these.
http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html
http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html

HTH,
  Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto and Google protobuffer

[Jussi Kukkonen]

On 1 September 2016 at 13:21, Herman van Hazendonk  wrote:

> Hi Pietro,
>
> You can override the recipe by adding a recipe for version 3.0.0+ in your
> own layer and making sure your layer has a higher priority in
> bblayers.conf. See for example what we do in our project:
>
> https://github.com/webOS-ports/webos-ports-setup/blob/testin
> g/conf/bblayers.conf
>
> openembedded-core provides ofono 1.1.7 for example with
> https://github.com/openembedded/openembedded-core/tree/
> krogoth/meta/recipes-connectivity/ofono
>
> However we want to use ANOTHER version of ofono (1.1.7 based, but from a
> different repo/project).
>
> So we have our own .bbappend at https://github.com/webOS-ports
> /meta-webos-ports/blob/krogoth/meta-luneos/recipes-connectiv
> ity/ofono/ofono_git.bbappend where we specify the different repo etc to
> use.
>
> This doesn't apply 1:1 in your case, but you could simply add a
> protobuf_3.0.0.bb in your own layer and it should build that instead.
> Just make sure you have your layer at a higher position compared to
> meta-openembedded in your bblayers.conf
>

In the normal case (a simple upgrade to the newest version) the best choice
would be to send a upgrade patch to openembedded-devel list: that way you
never have to maintain it in your own layer.

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] debug version of a package

[Jussi Kukkonen]

On 21 August 2016 at 16:55, Andy Ng  wrote:

> Hi,
>
> How do I trigger the build of the debug version of a single package?
>

Binaries are (almost) always built with debug symbols, there's nothing that
needs to be done there. The unstripped debug binaries are typically
packaged into "-dbg" package, while stripped versions of those
binaries go into other packages. To get debug binaries onto an image, you
can either add the specific -dbg packages with IMAGE_INSTALL_append or add
all debug packages with image features:
EXTRA_IMAGE_FEATURES += "tools-debug dbg-pkgs"

Jussi



> Thank you
> Andy
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-keyboard][PATCH] applet: Port to ScalingImage2

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 applet/applet.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/applet/applet.c b/applet/applet.c
index 0de5634..69cc600 100644
--- a/applet/applet.c
+++ b/applet/applet.c
@@ -19,7 +19,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 static void
@@ -35,9 +35,10 @@ mb_panel_applet_create (const char *id, GtkOrientation 
orientation)
 
   box = gtk_event_box_new ();
   gtk_event_box_set_visible_window (GTK_EVENT_BOX (box), FALSE);
+  gtk_event_box_set_above_child (GTK_EVENT_BOX (box), TRUE);
   gtk_widget_set_name (box, "MatchboxPanelKeyboard");
 
-  image = mb_panel_scaling_image_new (orientation, "matchbox-keyboard");
+  image = mb_panel_scaling_image2_new (orientation, "matchbox-keyboard");
   gtk_container_add (GTK_CONTAINER (box), image);
 
   g_signal_connect (box, "button-release-event", G_CALLBACK (on_toggled), 
NULL);
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH 4/4] launcher: Port to ScalingImage2

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 applets/launcher/launcher.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/applets/launcher/launcher.c b/applets/launcher/launcher.c
index 0ec8a43..d1ab8e4 100644
--- a/applets/launcher/launcher.c
+++ b/applets/launcher/launcher.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #ifdef USE_LIBSN
   #define SN_API_NOT_YET_FROZEN 1
@@ -20,7 +20,7 @@
 #endif
 
 typedef struct {
-GtkImage *image;
+MBPanelScalingImage2 *image;
 
 gboolean button_down;
 
@@ -331,7 +331,7 @@ mb_panel_applet_create (const char*id,
 
 gtk_widget_set_name (event_box, "MatchboxPanelLauncher");
 
-image = mb_panel_scaling_image_new (orientation, icon);
+image = mb_panel_scaling_image2_new (orientation, icon);
 g_free (icon);
 
 gtk_container_add (GTK_CONTAINER (event_box), image);
@@ -339,7 +339,7 @@ mb_panel_applet_create (const char*id,
 /* Set up applet structure */
 applet = g_slice_new0 (LauncherApplet);
 
-applet->image = GTK_IMAGE (image);
+applet->image = MB_PANEL_SCALING_IMAGE2 (image);
 
 applet->button_down = FALSE;
 
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH 3/4] startup: Port to ScalingImage2

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 applets/startup/startup.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/applets/startup/startup.c b/applets/startup/startup.c
index 1b304da..026dce2 100644
--- a/applets/startup/startup.c
+++ b/applets/startup/startup.c
@@ -38,7 +38,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 #define TIMEOUT 20
 #define HOURGLASS_PIXMAPS 8
@@ -50,7 +50,7 @@ typedef struct LaunchItem {
 } LaunchItem;
 
 typedef struct {
-MBPanelScalingImage *image;
+MBPanelScalingImage2 *image;
 GdkWindow *root_window;
 SnDisplay *sn_display;
 SnMonitorContext *sn_context;
@@ -201,7 +201,7 @@ timeout (StartupApplet *applet)
 sprintf (icon, "%s/hourglass-%i.png", DATADIR,
  applet->hourglass_cur_frame_n);
 
-mb_panel_scaling_image_set_icon (applet->image, icon);
+mb_panel_scaling_image2_set_icon (applet->image, icon);
 
 free (icon);
 
@@ -261,10 +261,8 @@ mb_panel_applet_create (const char*id,
 applet->hourglass_shown = FALSE;
 
 /* Create image */
-applet->image = MB_PANEL_SCALING_IMAGE
-  (mb_panel_scaling_image_new (orientation, NULL));
-mb_panel_scaling_image_set_caching (applet->image, TRUE);
-
+applet->image = MB_PANEL_SCALING_IMAGE2
+  (mb_panel_scaling_image2_new (orientation, 
NULL));
 gtk_widget_set_name (GTK_WIDGET(applet->image),
  "MatchboxPanelStartupMonitor");
 
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH 2/4] battery: Port to ScalingImage2

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 applets/battery/battery-acpi.c |  1 +
 applets/battery/battery.c  | 10 ++
 applets/battery/battery.h  |  2 --
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/applets/battery/battery-acpi.c b/applets/battery/battery-acpi.c
index c44dd12..8431127 100644
--- a/applets/battery/battery-acpi.c
+++ b/applets/battery/battery-acpi.c
@@ -5,6 +5,7 @@
  */
 
 #include "battery.h"
+#include 
 #include 
 
 global_t global;
diff --git a/applets/battery/battery.c b/applets/battery/battery.c
index ade3ff6..c755856 100644
--- a/applets/battery/battery.c
+++ b/applets/battery/battery.c
@@ -7,9 +7,11 @@
  */
 
 #include "battery.h"
+#include 
+#include 
 
 typedef struct {
-MBPanelScalingImage *image;
+MBPanelScalingImage2 *image;
 const char *last_icon;
 guint timeout_id;
 } BatteryApplet;
@@ -38,7 +40,7 @@ timeout (BatteryApplet *applet)
 
 applet->last_icon = icon;
 
-mb_panel_scaling_image_set_icon (applet->image, icon);
+mb_panel_scaling_image2_set_icon (applet->image, icon);
 
 /* Keep going */
 return TRUE;
@@ -59,8 +61,8 @@ mb_panel_applet_create (const char*id,
 
 applet->last_icon = NULL;
 
-image = mb_panel_scaling_image_new (orientation, NULL);
-applet->image = MB_PANEL_SCALING_IMAGE (image);
+image = mb_panel_scaling_image2_new (orientation, NULL);
+applet->image = MB_PANEL_SCALING_IMAGE2 (image);
 
 gtk_widget_set_name (image, "MatchboxPanelBatteryMonitor");
 
diff --git a/applets/battery/battery.h b/applets/battery/battery.h
index 29a44ca..cf23431 100644
--- a/applets/battery/battery.h
+++ b/applets/battery/battery.h
@@ -8,8 +8,6 @@
 #define MB_APPLET_BATTERY_H
 
 #include 
-#include 
-#include 
 
 int pm_support(void);
 const char* pm_battery_icon(void);
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH 1/4] mb-panel: Remove leftover call from old ScalingImage

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 matchbox-panel/mb-panel-scaling-image2.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/matchbox-panel/mb-panel-scaling-image2.c 
b/matchbox-panel/mb-panel-scaling-image2.c
index 8cdc3a1..258f1e4 100644
--- a/matchbox-panel/mb-panel-scaling-image2.c
+++ b/matchbox-panel/mb-panel-scaling-image2.c
@@ -220,7 +220,6 @@ reload_icon (MBPanelScalingImage2 *image, gboolean force)
 
 if (!image->priv->icon) {
 g_clear_object (>priv->pixbuf);
-gtk_image_set_from_pixbuf (GTK_IMAGE (image), NULL);
 gtk_widget_queue_resize (GTK_WIDGET (image));
 return;
 }
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH 0/4] Port to ScalingImage2

[Jussi Kukkonen]

Port all remaining applets to ScalingImage2.
Also fix a bug in ScalingImage2.

The following changes since commit 145a8075c66952dad9ab5f36d944c78c1ae3f4ab:

  Release 2.10, update contact info (2016-06-02 15:08:14 +0300)

are available in the git repository at:

  git://github.com/jku/matchbox-panel-2 scaling-image
  https://github.com/jku/matchbox-panel-2/tree/scaling-image

Jussi Kukkonen (4):
  mb-panel: Remove leftover call from old ScalingImage
  battery: Port to ScalingImage2
  startup: Port to ScalingImage2
  launcher: Port to ScalingImage2

 applets/battery/battery-acpi.c   |  1 +
 applets/battery/battery.c| 10 ++
 applets/battery/battery.h|  2 --
 applets/launcher/launcher.c  |  8 
 applets/startup/startup.c| 12 +---
 matchbox-panel/mb-panel-scaling-image2.c |  1 -
 6 files changed, 16 insertions(+), 18 deletions(-)

-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [sato-screenshot][PATCH] applet: Port to ScalingImage2

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 applet.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/applet.c b/applet.c
index 699a920..d403619 100644
--- a/applet.c
+++ b/applet.c
@@ -8,7 +8,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include "screenshot-ui.h"
 
 static void
@@ -26,7 +26,7 @@ mb_panel_applet_create (const char *id, GtkOrientation 
orientation)
   gtk_widget_set_name (button, "MatchboxPanelScreenshot");
   gtk_button_set_relief (GTK_BUTTON (button), GTK_RELIEF_NONE);
 
-  image = mb_panel_scaling_image_new (orientation, "applet-screenshot");
+  image = mb_panel_scaling_image2_new (orientation, "applet-screenshot");
   gtk_container_add (GTK_CONTAINER (button), image);
 
   g_signal_connect (button, "clicked", G_CALLBACK (on_clicked), NULL);
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [libmatchbox][PATCH 4/4] Keep an internal copy of xsettings-client

[Jussi Kukkonen]

xsettings-client code was meant to be a copy-and-paste module, not a
shared library. Grab a copy from
git://anongit.freedesktop.org/xdg/xdg-specs and include it in the
sources.

Remove the build complications: always build with xsettings.

The new files are MIT (old style) licensed: add a COPYING.MIT file.

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 COPYING.MIT  |  18 ++
 configure.ac |  68 --
 libmb/Makefile.am|   8 +-
 libmb/mbmenu.c   |   9 -
 libmb/mbmenu.h   |   7 +-
 libmb/mbtray.c   |  61 +
 libmb/xsettings-client.c | 577 +++
 libmb/xsettings-client.h |  72 ++
 libmb/xsettings-common.c | 264 ++
 libmb/xsettings-common.h | 110 +
 10 files changed, 1049 insertions(+), 145 deletions(-)
 create mode 100644 COPYING.MIT
 create mode 100644 libmb/xsettings-client.c
 create mode 100644 libmb/xsettings-client.h
 create mode 100644 libmb/xsettings-common.c
 create mode 100644 libmb/xsettings-common.h

diff --git a/COPYING.MIT b/COPYING.MIT
new file mode 100644
index 000..f7bdbba
--- /dev/null
+++ b/COPYING.MIT
@@ -0,0 +1,18 @@
+This license applies to libmb/xsettings-*:
+
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that
+ * copyright notice and this permission notice appear in supporting
+ * documentation, and that the name of Red Hat not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  Red Hat makes no representations about the
+ * suitability of this software for any purpose.  It is provided "as is"
+ * without express or implied warranty.
+ *
+ * RED HAT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL RED HAT
+ * BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
+ * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN 
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
diff --git a/configure.ac b/configure.ac
index 65d7c79..d369e2c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -17,7 +17,6 @@ SUPPORTS_PNG=0
 SUPPORTS_JPEG=0
 SUPPORTS_XFT=0
 SUPPORTS_PANGO=0
-SUPPORTS_XSETTINGS=0
 
 dnl - Args -
 
@@ -41,19 +40,6 @@ AC_ARG_ENABLE(doxygen-docs,
   [  --enable-doxygen-docs   build DOXYGEN API documentation (requires 
Doxygen)], 
  enable_doxygen_docs=$enableval,enable_doxygen_docs=no)
 
-AC_ARG_ENABLE(xsettings,
-  [  --enable-xsettings  enable xsettings client support],
- enable_xsettings=$enableval, enable_xsettings=no )
-
-AC_ARG_WITH(xsettings-includes,
-  [  --with-xsettings-includes=DIR Use xsettings-client includes in DIR],
- 
-  xsettings_includes=$withval, xsettings_includes=yes)
-
-AC_ARG_WITH(xsettings-lib, 
-  [  --with-xsettings-lib=DIR  Use xsettings-client library in DIR], 
-  xsettings_lib=$withval, xsettings_lib=yes)
-
 AC_ARG_ENABLE(debug,
   [  --enable-debug  enable debug ( verbose ) build],
  enable_debug=$enableval, enable_debug=no )
@@ -180,56 +166,6 @@ if test x$enable_jpeg != xno; then
   fi
 fi
 
-
-dnl -- Check for XSettings --
-
-if test x$enable_xsettings != xno; then
-  case "$xsettings_includes" in
-yes|no)
-   XSET_CFLAGS=""
-   ;;
-*)
-   XSET_CFLAGS="-I$xsettings_includes"
-   ;;
-  esac
-   
-  case "$xsettings_lib" in
-yes)
-   XSET_LIBS="-lXsettings-client"
-   ;;
-*)
-   XSET_LIBS="-L$xsettings_lib -lXsettings-client"
-   ;;
-   esac
-
-   xsetsaved_CPPFLAGS="$CPPFLAGS"
-   CPPFLAGS="$CPPFLAGS $XSET_CFLAGS $XLIBS_CFLAGS"
-   xsetsaved_LIBS="$LIBS"
-   LIBS="$LIBS $XSET_LIBS $XLIBS_LIBS"
-
-   AC_CHECK_HEADER(xsettings-client.h, [ have_xset_h="yes" ], [ 
have_xset_h="no" ] )
-
-   if test x$have_xset_h = xno; then
-  AC_MSG_ERROR([cannot find Xsettings-client headers])
-   fi
-
-   AC_CHECK_LIB([Xsettings-client], [xsettings_client_new], 
-[have_xset_libs="yes"], [ have_xset_libs="no"])
-
-   if test x$have_xset_libs = x"no"; then  
-  AC_MSG_ERROR([cannot find Xsettings-client headers])
-   fi
-   
-   CPPFLAGS="$xsetsaved_CPPFLAGS"
-   LIBS="$xsetsaved_LIBS"
-
-   MB_EXTRA_LIBS="$MB_EXTRA_LIBS $XSET_LIBS"   
-   MB_EXTRA_CFLAGS="$MB_EXTRA_CFLAGS $XSET_CFLAGS" 
-
-   A

[yocto] [libmatchbox][PATCH 3/4] Remove unused pointer dereferences

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 libmb/mbexp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libmb/mbexp.c b/libmb/mbexp.c
index c6e6046..bbe11d0 100644
--- a/libmb/mbexp.c
+++ b/libmb/mbexp.c
@@ -1369,7 +1369,7 @@ mb_layout_get_geometry (MBLayout *layout, int *width, int 
*height)
 }
else
 { 
-  nbytes++; *txt++; 
+  nbytes++; txt++;
 }
   
  line_width = mb_font_get_txt_width(layout->font, start, 
@@ -1703,14 +1703,14 @@ mb_util_next_utf8_char(unsigned char **string)
 return -1;
   }

-  *s++;
+  s++;
   tmp = length;
   while(tmp-- > 0) {
 if((*s & 0xc0) != 0x80) { /* trailer must be 10xx */
   /* ERROR */ 
   return -1;
 }
-*s++;
+s++;
   } 
   
   *string = s; 
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [libmatchbox][PATCH 1/4] Don't use deprecated XKeycodeToKeysym

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 libmb/mbmenu.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libmb/mbmenu.c b/libmb/mbmenu.c
index d25397b..5e4106e 100644
--- a/libmb/mbmenu.c
+++ b/libmb/mbmenu.c
@@ -23,6 +23,8 @@
 #include "config.h"
 #endif
 
+#include 
+
 #include "mbmenu.h"
 
 #define MBMAX(x,y) ((x>y)?(x):(y))
@@ -802,7 +804,7 @@ mb_menu_handle_xevent(MBMenu *mb, XEvent *an_event)
 {
 case KeyPress:
   MENUDBG("%s() Keyevent recieved\n", __func__ );
-  switch (key = XKeycodeToKeysym (mb->dpy, an_event->xkey.keycode, 0))
+  switch (key = XkbKeycodeToKeysym (mb->dpy, an_event->xkey.keycode, 0, 0))
{
case XK_Left:
  if (mb->active_depth > 0)
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [libmatchbox][PATCH 2/4] Use correct size with memset calls

[Jussi Kukkonen]

Found with -Wsizeof-pointer-memaccess.

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 libmb/hash.c   | 2 +-
 libmb/mbmenu.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libmb/hash.c b/libmb/hash.c
index 0226c7d..a867883 100644
--- a/libmb/hash.c
+++ b/libmb/hash.c
@@ -75,7 +75,7 @@ struct nlist *hash_add(struct hash *h, char *key, char *val)
 
 void hash_empty(struct hash *h)
 {
-   memset(h->hashtab, 0, sizeof(h->hashtab));
+   memset(h->hashtab, 0, sizeof(*h->hashtab));
 }
 
 void 
diff --git a/libmb/mbmenu.c b/libmb/mbmenu.c
index 5e4106e..6e35bed 100644
--- a/libmb/mbmenu.c
+++ b/libmb/mbmenu.c
@@ -1065,7 +1065,7 @@ static MBMenuMenu *
 new_menu(MBMenu *mb, char *title, int depth)
 {
   MBMenuMenu *menu = (MBMenuMenu *)malloc(sizeof(MBMenuMenu));
-   memset(menu, 0, sizeof(menu));
+   memset(menu, 0, sizeof(*menu));
menu->items = NULL;
 
MENUDBG("adding menu -> %s, (%i) \n", title, depth);
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [libmatchbox][PATCH 0/4] Add xsetting-client in tree + fixes

[Jussi Kukkonen]

Add an internal copy of xsettings-client into libmatchbox: it was
never meant to be a shared library.

Other commits avoid deprecated API use or fix problems found by
modern gcc with -Wall.

Jussi


The following changes since commit 9f7cf8895ae2d39c465c04cc78e918c157420269:

  tests: link to X11 (2013-12-10 11:45:28 +)

are available in the git repository at:

  git://github.com/jku/libmatchbox xsettings
  https://github.com/jku/libmatchbox/tree/xsettings

Jussi Kukkonen (4):
  Don't use deprecated XKeycodeToKeysym
  Use correct size with memset calls
  Remove unused pointer dereferences
  Keep an internal copy of xsettings-client

 COPYING.MIT  |  18 ++
 configure.ac |  68 --
 libmb/Makefile.am|   8 +-
 libmb/hash.c |   2 +-
 libmb/mbexp.c|   6 +-
 libmb/mbmenu.c   |  15 +-
 libmb/mbmenu.h   |   7 +-
 libmb/mbtray.c   |  61 +
 libmb/xsettings-client.c | 577 +++
 libmb/xsettings-client.h |  72 ++
 libmb/xsettings-common.c | 264 ++
 libmb/xsettings-common.h | 110 +
 12 files changed, 1057 insertions(+), 151 deletions(-)
 create mode 100644 COPYING.MIT
 create mode 100644 libmb/xsettings-client.c
 create mode 100644 libmb/xsettings-client.h
 create mode 100644 libmb/xsettings-common.c
 create mode 100644 libmb/xsettings-common.h

-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to install 2 or more initscrips out form one recipe?

[Jussi Kukkonen]

On 8 July 2016 at 16:57,  wrote:

> Hej
>
> I run into a problem when I tried to install 3 initscrips out of one
> recipe. My recipe looks like:
> #
> SUMMARY = "demo cfg"
> SECTION = "demo"
> LICENSE = "CLOSED"
>
> inherit update-rc.d
>
> RDEPENDS_${PN} = "bash initscripts"
>
> SRC_URI = "file://startA \
> file://startB \
> file://startC \
> "
>
> S = "${WORKDIR}"
>
> do_install () {
> install -d ${D}${sysconfdir}/
> install -d ${D}${sysconfdir}/init.d/
> install -m 0644 ${S}/startA ${D}${sysconfdir}/init.d/startA
> install -m 0644 ${S}/startB ${D}${sysconfdir}/init.d/startB
> install -m 0644 ${S}/startC ${D}${sysconfdir}/init.d/startC
>
> chmod a+x ${D}${sysconfdir}/init.d/startA
> chmod a+x ${D}${sysconfdir}/init.d/startB
> chmod a+x ${D}${sysconfdir}/init.d/startC
> }
>
> INITSCRIPT_PACKAGES = "${PN} ${PN}_B ${PN}_C"

INITSCRIPT_NAME_${PN} = "startA"
> INITSCRIPT_PARAMS_${PN} = "start 90 10"
> INITSCRIPT_NAME_${PN}_B   = "startB"
> INITSCRIPT_PARAMS_${PN}_B = "start 90 10"
> INITSCRIPT_NAME_${PN}_C   = "startC"
> INITSCRIPT_PARAMS_${PN}_C = "start 90 10"
>
> CONFFILES_${PN} += "${sysconfdir}/init.d/startA"
> CONFFILES_${PN} += "${sysconfdir}/init.d/startB"
> CONFFILES_${PN} += "${sysconfdir}/init.d/startC"
>
> FILES_${PN} += "${sysconfdir}/*"
>

This puts all the init scripts in ${PN} when each should go into their own
package. You'll also probably need to make sure the extra packages are
created:
PACKAGES =+ "${PN}_B ${PN}_C"
Check packages-split/-directory in WORKDIR to make sure all the files went
to the right place.

As a style comment: Underscore probably works in a package name but hyphen
("${PN}-B") is the common choice.

Jussi


#
>
> The do_install works but initscript does not generates the link. I build
> that after this document
> http://docs.openembedded.ru/update-rc-d_class.html.
>
> Any ideas?
>
> Regards!
>
> Stefan Jaritz
>
>
> 
> ESA Elektroschaltanlagen Grimma GmbH
> Broner Ring 30
> 04668 Grimma
> Telefon: +49 3437 9211 176
> Telefax: +49 3437 9211 26
> E-Mail: s.jar...@esa-grimma.de
> Internet: www.esa-grimma.de
>
>
> Geschäftsführer:
> Dipl.-Ing. Jörg Gaitzsch
> Jörg Reinker
>
> Sitz der Gesellschaft: Grimma
> Ust.-ID: DE 141784437
> Amtsgericht: Leipzig, HRB 5159
> Steuernummer: 238/108/00755
>
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen.
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
> erhalten
> haben, informieren Sie bitte sofort den Absender und löschen Sie diese
> Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
> Mail
> ist nicht gestattet.
>
> This e-mail may contain confidential and/or privileged information. If you
> are
> not the intended recipient (or have received this e-mail in error) please
> notify the sender immediately and destroy this e-mail. Any unauthorized
> copying, disclosure or distribution of the material in this e-mail is
> strictly
> forbidden.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] NTP

[Jussi Kukkonen]

On 17 June 2016 at 09:33, Anicic Damir (PSI)  wrote:
>
> Hi!
>
> I just realised that ntpd + ntpdate is not part of Yocto 2.1
>
> I found http://layers.openembedded.org/layerindex/recipe/2299/
>
> but how to get it?

Note that you do not need ntpd or extra layers for ntp client functionality
if you use systemd. See
https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html
and https://www.freedesktop.org/software/systemd/man/timedatectl.html. I'm
not sure what the default NTP setting is, you may have to enable it.

- Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Switch to GTK+3

[Jussi Kukkonen]

On 16 June 2016 at 15:44, Gary Thomas  wrote:
>
> I just tried a build from the latest Poky/Yocto master (2a85038dd)
> Overall, I think the switch to GTK+3 is an improvement, but I have
> a number of [usability] questions:

It's a tricky upgrade, essentially upgrading a major part of an operating
system from a version five years old version to a current one. I am sorry
for the inconvenience.

> * I built firefox from meta-browser and noticed that on my touch only
> device, it does not automatically pop-up the keyboard.  However, epiphany
> does.  I've only done a little testing but that's what I observed.  Not
> having this happen "on demand" (i.e. when a text field has the focus)
> will make using a full screen application impossible on this hardware.

I assume this is still the Gtk2 firefox? There is a Gtk3 version released
recently I believe.

Before the recent changes, Gtk+2 applications were the only thing supported
by the virtual keyboard.

Now, the default configuration is to build only support for Gtk+3 but it is
possible to support also Gtk+2 by adding "gtk2-im" into the
matchbox-keyboard PACKAGECONFIG. This is not done by default to prevent the
keyboard from bringing gtk+ into the image if nothing else requires it.

> * Also on firefox, I can't seem to get the vertical scrollbar to work.
> Again, with epiphany it at least works.

This is slightly surprising if firefox is a gtk+2 application. The only
thing that really changed with the GTK2 stack is the theme... but the
current one (gnome-theme-adwaita from gnome-themes-standard) is the GNOME
default so I'd expect it work. I have no suggestions here, Sorry.

> * The system also doesn't seem to play very nice with my GPU enhanced
> i.MX6 and causes the SoC to overheat (didn't happen with GTK+2).  Makes
> it rather unusable as well.

Eek. That sounds like a driver problem. The new Gtk is more demanding on
graphics drivers but not by a huge difference.

> * gtk-play ran my 1GB system out of memory, just starting up :-(  This
> caused a complete system lockup & I could not even restart the X server.
> This application also seemed to run quite well with GTK+2

gst-player did go through some refactoring (the library parts are now in
gst-plugins-bad) so new bugs are not impossible. It's unlikely that the Gtk
upgrade itself would have this kind of effects, but maybe this is related
to the previous problem -- wherever the root cause is.

> * There also seem to be a continuous stream of messages like these on the
console:
>
>   GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings
will not be saved or shared with other applications.
>   Gtk-Message: GtkDialog mapped without a transient parent. This is
discouraged.

The messages as such are not problematic, assuming there's no flood of them.

GSettings is still something we might want to bring in (as a replacement
for GConf which is deprecated), but that means a little porting work on
matchbox components. The GtkDialog message is probably from gtk-play and
should not be an issue.

Hope this helps,
  Jussi



> I know that these firefox vs. epiphany vs. chome vs. ... questions
> are not really the responsibility of Yocto or OE-core, but it does
> trickle down to those of us trying to use this framework.
>
> Many thanks for any thoughts
>
> n.b. I was torn what mailing list to use for this - it's tightly
> tied to OE-core, but isn't really about patches or changes, more
> about philosophy.  If the OE-core list is more appropriate, please
> move the replies there.
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Problems with do_rootfs when changing the user password

[Jussi Kukkonen]

On 9 June 2016 at 12:00,  wrote:
>
> Hej
>
> I want to change the root password. For that I create the recipe
"myNewPassword.bb" with:
> 
> SUMMARY = "my new password"
> SECTION = "new"
> LICENSE = "CLOSED"
>
> inherit extrausers
>
> EXTRA_USERS_PARAMS = "\
> usermod -P xyz root; \
> "
> 
>
> compiling and packaging works fine.
>
> In my layer I add at the layer.conf:
> 
> IMAGE_INSTALL_append=" myNewPassword"
> 
>
> When do_rootfs (core-image-minimal) the package could not be found. A
deb(ug) Package was created.

If your package would contain no files, bitbake will not produce it at all.
You should be able to override this with:
ALLOW_EMPTY_${PN} = "1"

 - Jussi


>
> Regards!
>
> Stefan Jaritz
>
> 
> ESA Elektroschaltanlagen Grimma GmbH
> Broner Ring 30
> 04668 Grimma
> Telefon: +49 3437 9211 176
> Telefax: +49 3437 9211 26
> E-Mail: s.jar...@esa-grimma.de
> Internet: www.esa-grimma.de
>
>
> Geschäftsführer:
> Dipl.-Ing. Jörg Gaitzsch
> Jörg Reinker
>
> Sitz der Gesellschaft: Grimma
> Ust.-ID: DE 141784437
> Amtsgericht: Leipzig, HRB 5159
> Steuernummer: 238/108/00755
>
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen.
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
erhalten
> haben, informieren Sie bitte sofort den Absender und löschen Sie diese
> Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
Mail
> ist nicht gestattet.
>
> This e-mail may contain confidential and/or privileged information. If
you are
> not the intended recipient (or have received this e-mail in error) please
> notify the sender immediately and destroy this e-mail. Any unauthorized
> copying, disclosure or distribution of the material in this e-mail is
strictly
> forbidden.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-desktop-sato][PATCH] Remove Utilities-folder

[Jussi Kukkonen]

Typical result of separate Applications and Utilities is that
Applications only contains a single icon. Applications is also
the default folder: it's a waste of space to have that empty.

Merge all Utilities into Applications.

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---

This is a partial fix for [YOCTO #9667] in that a typical
core-image-sato will have Terminal and File Manager icons visible
on the initial screen now, making it easier for newcomers to find
them and allowing faster access to common tools for everyone.

 Applications.directory | 2 +-
 Makefile.am| 3 +--
 Root.order | 1 -
 Utilities.directory| 8 
 4 files changed, 2 insertions(+), 12 deletions(-)
 delete mode 100644 Utilities.directory

diff --git a/Applications.directory b/Applications.directory
index 69f6ed1..a7e3501 100644
--- a/Applications.directory
+++ b/Applications.directory
@@ -3,4 +3,4 @@ Name=Applications
 Comment=Applications
 Icon=gnome-applications.png
 Type=Directory
-Match=AudioVideo;Audio;Video;Graphics;Network;Office;meta-fallback;
+Match=AudioVideo;Audio;Video;Graphics;Network;Office;Utility;System;Development;meta-fallback;
diff --git a/Makefile.am b/Makefile.am
index c4f4667..4e6cae2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4,5 +4,4 @@ dist_folder_DATA = \
All.directory \
Applications.directory \
Games.directory \
-   Settings.directory \
-   Utilities.directory
+   Settings.directory
diff --git a/Root.order b/Root.order
index 0c2f3cb..01a86d2 100644
--- a/Root.order
+++ b/Root.order
@@ -1,5 +1,4 @@
 Applications
-Utilities
 Games
 Settings
 All
diff --git a/Utilities.directory b/Utilities.directory
deleted file mode 100644
index 1a73e63..000
--- a/Utilities.directory
+++ /dev/null
@@ -1,8 +0,0 @@
-[Desktop Entry]
-Name=Utilities
-Name[de]=Einstellungen
-Comment=Various utilities
-Comment[de]=Verschiedene Hilfsprogramme
-Icon=mbfolder.png
-Type=Directory
-Match=Utility;System;Development;
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][matchbox-wm] wm: Do not set MB theme based on Net/ThemeName

[Jussi Kukkonen]

On 27 May 2016 at 12:32, Burton, Ross <ross.bur...@intel.com> wrote:
> On 26 April 2016 at 08:57, Jussi Kukkonen <jussi.kukko...@intel.com>
wrote:
>>
>> MBWM already supports setting MB theme with "MATCHBOX/THEME",
>> there is no advantage to also set it with "Net/ThemeName" -- the
>> expectation that MBWM has a matching theme for all toolkit themes
>> is not realistic.
>>
>> Net/ThemeName is used by Gtk+ to set Gtk theme so this change allows
>> the Gtk theme and MBWM theme to have different names.
>
> This behaviour is useful though, how about supporting both but having
Matchbox/Theme override Net/ThemeName?

I've solved what I think is the issue by supporting the "MATCHBOX/THEME"
property via the /desktop/poky/interface/wmtheme gconf key (similar to how
"Net/ThemeName" is supported via /desktop/poky/interface/theme) in
xsettings-daemon. So now both can be set at the same time very easily at
runtime -- the override should not be necessary.

 - Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How can I set a recipe that its binaries become available at cross-compile time?

[Jussi Kukkonen]

On 23 May 2016 at 16:37,   wrote:
> Hej
>
> I a cmake based application, some code generation via dbusxx-xml2cpp. It is
> provided by the dbuss-c++ lib. A recipe can be found under:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/tree/meta-ivi-demo/recipes-extended/dbus-c++?id=b90c2a20744e1e82b2169a88e68d7677bec907b6

You shouldn't need a separate native recipe: 'BBCLASSEXTEND =
"native"' in the main recipe should work.

> It working and it's compiling & linking, "dbusxx-xml2cpp" is included at the
> native build.
>
> How can I set a recipe that its binaries become available at cross-compile
> time?

If dbus-c++ installs the binaries properly and another recipe depends
on dbus-c++-native then the binaries should be in the native sysroot
during the other recipes build. As an example see dbus-glib and
connman-gnome in oe-core: dbus-glib-native provides dbus-binding-tool
which connman-gnome uses during build.

HTH,
  Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [matchbox-keyboard][PATCH 1/1] Addition of french keyboard

[Jussi Kukkonen]

On 18 May 2016 at 09:03, Herve Jourdain <herve.jourd...@neuf.fr> wrote:
> I believe you’re aware there is another patch, 1 line patch, by Jussi
> Kukkonen, applied to matchbox-keyboard,
> “0001-desktop-file-Hide-the-keyboard-from-app-list.patch”, that adds
> “NoDisplay=true” to matchbox-keyboard.desktop.
>
> Should anyone send it also as a patch to the branch, so it can be removed
> from the layer?
>
> Similarly, shouldn’t the script 80matchboxkeyboard.sh be also added to the
> branch?

I suppose there are few matchbox-keyboard users outside of oe-core,
but 80matchboxkeyboard.sh is definitely a oe-core specific script and
installing that from the upstream project would be a bit rude to the
hypothetical non-oecore user.

The “NoDisplay=true” patch is more debatable but I think my reasoning
back then was the same: it was a oe-core configuration decision.

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [matchbox-keyboard][PATCH ] Support of "caps" tag

[Jussi Kukkonen]

On 18 May 2016 at 08:51, Herve Jourdain  wrote:
> This patch allows the support of a "caps" tag, that defines the value of the 
> key when the CAPS action modifier is in effect.
> This feature is needed for the french keyboard - at least - in order to 
> handle the uppercase accented letters, that are the ones accessible when caps 
> is on, for some keys.
> There is no impact when the tag is not used in the xml description of the 
> layout, therefore there should be no impact on keyboards not using this tag.
> Tests have been done using sato.

Please write this message as the actual patch commit message: when
it's in a cover letter it will not end up in the git log where it's
most needed.

Otherwise patch looks good to me.

Jussi

> Herve Jourdain (1):
>   Support of "caps" tag
>
>  src/config-parser.c  |  5 +
>  src/matchbox-keyboard-key.c  | 11 ---
>  src/matchbox-keyboard-ui-cairo-backend.c | 10 +++---
>  src/matchbox-keyboard-ui-xft-backend.c   | 10 +++---
>  src/matchbox-keyboard.c  |  3 +++
>  src/matchbox-keyboard.h  |  1 +
>  6 files changed, 31 insertions(+), 9 deletions(-)
>
> --
> 2.7.4
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-desktop-2][PATCH 2/2] TakuIconTile: Avoid deprecated icon API

[Jussi Kukkonen]

Don't use a named icon size: that is no longer supported.

Instead add style property "taku-icon-size" to TakuIconTile
and use that.
---
 libtaku/taku-icon-tile.c | 24 +++-
 libtaku/taku-launcher-tile.c | 32 +---
 libtaku/taku-menu-desktop.c  |  8 ++--
 libtaku/taku-menu.h  |  3 +--
 src/desktop.c|  4 
 5 files changed, 39 insertions(+), 32 deletions(-)

diff --git a/libtaku/taku-icon-tile.c b/libtaku/taku-icon-tile.c
index 2e562aa..110db6b 100644
--- a/libtaku/taku-icon-tile.c
+++ b/libtaku/taku-icon-tile.c
@@ -63,14 +63,14 @@ tile_arrange (TakuIconTile *tile)
 
 switch (orientation) {
 case GTK_ORIENTATION_VERTICAL :
-  gtk_misc_set_alignment (GTK_MISC (tile->priv->primary), 0.5, 0.5);
-  gtk_misc_set_alignment (GTK_MISC (tile->priv->secondary), 0.5, 0.5);
+  gtk_label_set_xalign (GTK_LABEL (tile->priv->primary), 0.5);
+  gtk_label_set_xalign (GTK_LABEL (tile->priv->secondary), 0.5);
   box = gtk_box_new (GTK_ORIENTATION_VERTICAL, 6);
   break;
 default:
 case GTK_ORIENTATION_HORIZONTAL :
-  gtk_misc_set_alignment (GTK_MISC (tile->priv->primary), 0.0, 0.5);
-  gtk_misc_set_alignment (GTK_MISC (tile->priv->secondary), 0.0, 0.5);
+  gtk_label_set_xalign (GTK_LABEL (tile->priv->primary), 0.0);
+  gtk_label_set_xalign (GTK_LABEL (tile->priv->secondary), 0.0);
   box = gtk_box_new (GTK_ORIENTATION_HORIZONTAL, 6);
   break;
 }
@@ -243,6 +243,15 @@ taku_icon_tile_class_init (TakuIconTileClass *klass)
   
GTK_TYPE_ORIENTATION,
   
GTK_ORIENTATION_HORIZONTAL,
   
G_PARAM_READABLE));
+  gtk_widget_class_install_style_property (widget_class,
+   g_param_spec_uint ("taku-icon-size",
+  "Taku icon size",
+  "Icon size used 
by all Taku Icons",
+  0,
+  256,
+  64,
+  
G_PARAM_READABLE));
+
 }
 
 static void
@@ -311,10 +320,15 @@ taku_icon_tile_set_pixbuf (TakuIconTile *tile, GdkPixbuf 
*pixbuf)
 void
 taku_icon_tile_set_icon_name (TakuIconTile *tile, const char *name)
 {
+  uint size;
   g_return_if_fail (TAKU_IS_ICON_TILE (tile));
 
+  gtk_widget_style_get (GTK_WIDGET (tile),
+"taku-icon-size", ,
+NULL);
+
   gtk_image_set_from_icon_name (GTK_IMAGE (tile->priv->icon),
-name, gtk_icon_size_from_name ("taku-icon"));
+name, size);
 }
 
 void
diff --git a/libtaku/taku-launcher-tile.c b/libtaku/taku-launcher-tile.c
index b453eac..e7f58f3 100644
--- a/libtaku/taku-launcher-tile.c
+++ b/libtaku/taku-launcher-tile.c
@@ -38,8 +38,6 @@ struct _TakuLauncherTilePrivate
   gboolean loading_icon; /* If the icon is queued to be loaded */
 };
 
-/* Icon size ID for the TakuIcon size */
-static GtkIconSize icon_size;
 /* Queue of tiles with pending icons to load */
 static GQueue queue = G_QUEUE_INIT;
 
@@ -50,6 +48,7 @@ load_icon (gpointer data)
   TakuLauncherTile *tile;
   GdkPixbuf *pixbuf;
   int i;
+  guint size;
   
   /* Per iteration, load a few icons at once */
   for (i = 0; i < 5; i++) {
@@ -58,8 +57,11 @@ load_icon (gpointer data)
 if (tile == NULL) {
   return TRUE;
 }
-
-pixbuf = taku_menu_item_get_icon (tile->priv->item, (GtkWidget*)tile, 
icon_size);
+
+gtk_widget_style_get (GTK_WIDGET (tile),
+  "taku-icon-size", ,
+  NULL);
+pixbuf = taku_menu_item_get_icon (tile->priv->item, size);
 
 if (pixbuf) {
   taku_icon_tile_set_pixbuf (TAKU_ICON_TILE (tile), pixbuf);
@@ -110,7 +112,7 @@ taku_launcher_tile_finalize (GObject *object)
 static gboolean
 reset_state (gpointer data)
 {
-  gtk_widget_set_state (GTK_WIDGET (data), GTK_STATE_NORMAL);
+  gtk_widget_unset_state_flags (GTK_WIDGET (data), GTK_STATE_FLAG_ACTIVE);
   return FALSE;
 }
 
@@ -119,7 +121,7 @@ taku_launcher_tile_activate (TakuLauncherTile *tile)
 {
   TakuLauncherTile *launcher = TAKU_LAUNCHER_TILE (tile);
 
-  gtk_widget_set_state (GTK_WIDGET (tile), GTK_STATE_ACTIVE);
+  gtk_widget_set_state_flags (GTK_WIDGET (tile), GTK_STATE_FLAG_ACTIVE, FALSE);
 
   g_timeout_add (500, reset_state, tile);
 
@@ -147,12 +149,6 @@ taku_launcher_tile_class_init (TakuLauncherTileClass 
*klass)
 
   object_class->finalize = taku_launcher_tile_finalize;
 
-  /* Lookup the icon size from the theme */
-  icon_size = gtk_icon_size_from_name ("taku-icon");
-  

[yocto] [matchbox-desktop-2][PATCH 1/2] TakuCategoryBar: Avoid deprecated API

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 src/taku-category-bar.c | 27 ++-
 1 file changed, 6 insertions(+), 21 deletions(-)

diff --git a/src/taku-category-bar.c b/src/taku-category-bar.c
index 93bda61..5900d54 100644
--- a/src/taku-category-bar.c
+++ b/src/taku-category-bar.c
@@ -192,7 +192,6 @@ popup_menu (GtkWidget *button, GdkEventButton *event, 
gpointer user_data)
 
 label = gtk_label_new (category->name);
 make_bold (GTK_LABEL (label));
-gtk_misc_set_alignment (GTK_MISC (label), 0.5, 0.0);
 gtk_widget_show (label);
 gtk_container_add (GTK_CONTAINER (menu_item), label);
   }
@@ -216,16 +215,14 @@ static void
 taku_category_bar_init (TakuCategoryBar *bar)
 {
   TakuCategoryBarPrivate *priv;
-  GtkWidget *button, *arrow;
-  GtkSizeGroup *size_group;
+  GtkWidget *button;
 
   priv = GET_PRIVATE (bar);
 
-  size_group = gtk_size_group_new (GTK_SIZE_GROUP_VERTICAL);
-
   /* Previous button */
 
-  priv->prev_button = button = gtk_button_new ();
+  priv->prev_button = button = gtk_button_new_from_icon_name 
("go-previous-symbolic",
+  
GTK_ICON_SIZE_BUTTON);
   gtk_widget_set_name (button, "MatchboxDesktopPrevButton");
   atk_object_set_name (gtk_widget_get_accessible (button), "GroupPrevious");
   gtk_button_set_relief (GTK_BUTTON (button), GTK_RELIEF_NONE);
@@ -233,11 +230,6 @@ taku_category_bar_init (TakuCategoryBar *bar)
   gtk_widget_show (button);
   gtk_box_pack_start (GTK_BOX (bar), button, FALSE, TRUE, 0);
 
-  arrow = gtk_arrow_new (GTK_ARROW_LEFT, GTK_SHADOW_NONE);
-  gtk_widget_show (arrow);
-  gtk_container_add (GTK_CONTAINER (button), arrow);
-  gtk_size_group_add_widget (size_group, arrow);
-
   /* Category name button */
   
   priv->popup_button = button = gtk_toggle_button_new ();
@@ -252,11 +244,11 @@ taku_category_bar_init (TakuCategoryBar *bar)
   make_bold (GTK_LABEL (priv->switcher_label));
   gtk_widget_show (GTK_WIDGET (priv->switcher_label));
   gtk_container_add (GTK_CONTAINER (button), GTK_WIDGET 
(priv->switcher_label));
-  gtk_size_group_add_widget (size_group, GTK_WIDGET (priv->switcher_label));
 
   /* Next button */
 
-  priv->next_button = button = gtk_button_new ();
+  priv->next_button = button = gtk_button_new_from_icon_name 
("go-next-symbolic",
+  
GTK_ICON_SIZE_BUTTON);
   gtk_widget_set_name (button, "MatchboxDesktopNextButton");
   atk_object_set_name (gtk_widget_get_accessible (button), "GroupNext");
 
@@ -264,13 +256,6 @@ taku_category_bar_init (TakuCategoryBar *bar)
   g_signal_connect_swapped (button, "clicked", G_CALLBACK (next_category), 
bar);
   gtk_widget_show (button);
   gtk_box_pack_end (GTK_BOX (bar), button, FALSE, TRUE, 0);
-
-  arrow = gtk_arrow_new (GTK_ARROW_RIGHT, GTK_SHADOW_NONE);
-  gtk_widget_show (arrow);
-  gtk_container_add (GTK_CONTAINER (button), arrow);
-  gtk_size_group_add_widget (size_group, arrow);
-  
-  g_object_unref (size_group);
 }
 
 
@@ -324,7 +309,7 @@ taku_category_bar_get_current (TakuCategoryBar *bar)
 {
   TakuCategoryBarPrivate *priv;
 
-  g_return_if_fail (TAKU_IS_CATEGORY_BAR (bar));
+  g_return_val_if_fail (TAKU_IS_CATEGORY_BAR (bar), NULL);
   priv = GET_PRIVATE (bar);
 
   return (TakuLauncherCategory*)priv->current_category->data;
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-desktop-2][PATCH 0/2] More Gtk+3 fixes

[Jussi Kukkonen]

Two patches more on top of the 16 patch set earlier: these fix the
last deprecation warnings (with GTK 3.20).

I've pushed these into the same branch and have nothing more planned for
matchbox-desktop-2.

Jussi

The following changes since commit 606344f8b1652bcc3d369911990cf5bc46a16ab6:

  Don't set the desktop fullscreen if MODE_DESKTOP (2016-04-28 10:49:55 +0300)

are available in the git repository at:

  git://github.com/jku/matchbox-desktop-2 gtk3
  https://github.com/jku/matchbox-desktop-2/tree/gtk3

Jussi Kukkonen (2):
  TakuCategoryBar: Avoid deprecated API
  TakuIconTile: Avoid deprecated icon API

 libtaku/taku-icon-tile.c | 24 +++-
 libtaku/taku-launcher-tile.c | 32 +---
 libtaku/taku-menu-desktop.c  |  8 ++--
 libtaku/taku-menu.h  |  3 +--
 src/desktop.c|  4 
 src/taku-category-bar.c  | 27 ++-
 6 files changed, 45 insertions(+), 53 deletions(-)

-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH 25/25] windowselector: Port to ScalingImage2

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 applets/windowselector/windowselector.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/applets/windowselector/windowselector.c 
b/applets/windowselector/windowselector.c
index 9c1dadf..d269355 100644
--- a/applets/windowselector/windowselector.c
+++ b/applets/windowselector/windowselector.c
@@ -15,7 +15,7 @@
 #include 
 
 #include 
-#include 
+#include 
 
 #define DEFAULT_WINDOW_ICON_NAME "application-x-executable"
 
@@ -792,7 +792,7 @@ mb_panel_applet_create (const char*id,
 
 switch (applet->mode) {
 case MODE_STATIC_ICON:
-applet->image = mb_panel_scaling_image_new (orientation,
+applet->image = mb_panel_scaling_image2_new (orientation,
 "panel-task-switcher");
 gtk_container_add (GTK_CONTAINER (applet->button),
 applet->image);
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH 24/25] mb-panel: size request needs to be set before realize

[Jussi Kukkonen]

GtkWindow will default to 200 height on realize unless we request
otherwise  before that. On the other hand, struts can only be set
after the window has been realized.

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 matchbox-panel/mb-panel.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/matchbox-panel/mb-panel.c b/matchbox-panel/mb-panel.c
index 3f7e3b4..4f5fb74 100644
--- a/matchbox-panel/mb-panel.c
+++ b/matchbox-panel/mb-panel.c
@@ -387,8 +387,6 @@ main (int argc, char **argv)
 gtk_window_set_accept_focus (GTK_WINDOW (window), FALSE);
 }
 
-gtk_widget_realize (window);
-
 /* Set size */
 switch (mode) {
 case MODE_DOCK:
@@ -427,8 +425,6 @@ main (int argc, char **argv)
  screen_geom.x,
  screen_geom.y + screen_geom.height - 
size);
 }
-
-set_struts (window, edge, size);
 break;
 case MODE_TITLEBAR:
 /* TODO */
@@ -453,6 +449,10 @@ main (int argc, char **argv)
 break;
 }
 
+gtk_widget_realize (window);
+if (mode == MODE_DOCK)
+   set_struts (window, edge, size);
+
 /* Add frame */
 frame = gtk_frame_new (NULL);
 gtk_frame_set_shadow_type (GTK_FRAME (frame), GTK_SHADOW_NONE);
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH 23/25] Draw systray icons in their actual locations

[Jussi Kukkonen]

Cairo context is now in widget-relative coordinates instead of
window-relative: undo that transform so the icon draw code actually
draws inside the window.

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 applets/systray/na-tray.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/applets/systray/na-tray.c b/applets/systray/na-tray.c
index 7da908f..714bd90 100644
--- a/applets/systray/na-tray.c
+++ b/applets/systray/na-tray.c
@@ -538,6 +538,8 @@ static void
 na_tray_draw_box (GtkWidget *box,
  cairo_t   *cr)
 {
+  /* Transform to window-relative coordinates */
+  gtk_cairo_transform_to_window (cr, box, gtk_widget_get_window (box));
   gtk_container_foreach (GTK_CONTAINER (box), na_tray_draw_icon, cr);
 }
 
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH 22/25] Update .pc-file to require Gtk+-3.0

[Jussi Kukkonen]

---
 matchbox-panel.pc.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/matchbox-panel.pc.in b/matchbox-panel.pc.in
index dc0a75c..90374b7 100644
--- a/matchbox-panel.pc.in
+++ b/matchbox-panel.pc.in
@@ -8,4 +8,4 @@ Name: matchbox-panel
 Description: Simple GTK+ based panel
 Version: @VERSION@
 Cflags: -I${includedir}
-Requires: glib-2.0 gtk+-2.0
+Requires: glib-2.0 gtk+-3.0
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH 21/25] Don't use deprecated GtkMisc

[Jussi Kukkonen]

These changes should not affect fucntionality

Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
---
 applets/notify/mb-notification.c | 2 +-
 applets/systray/fixedtip.c   | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/applets/notify/mb-notification.c b/applets/notify/mb-notification.c
index e440ec9..c73b21f 100644
--- a/applets/notify/mb-notification.c
+++ b/applets/notify/mb-notification.c
@@ -85,7 +85,7 @@ mb_notification_init (MbNotification *self)
   gtk_box_pack_start (GTK_BOX (box), priv->image, FALSE, FALSE, 0);
 
   priv->label = gtk_label_new (NULL);
-  gtk_misc_set_alignment (GTK_MISC (priv->label), 0.0, 0.5);
+  gtk_label_set_xalign (GTK_LABEL (priv->label), 0.0);
   gtk_box_pack_start (GTK_BOX (box), priv->label, TRUE, TRUE, 0);
 }
 
diff --git a/applets/systray/fixedtip.c b/applets/systray/fixedtip.c
index 861e4ab..ce19067 100644
--- a/applets/systray/fixedtip.c
+++ b/applets/systray/fixedtip.c
@@ -116,7 +116,6 @@ na_fixed_tip_init (NaFixedTip *fixedtip)
 
   label = gtk_label_new (NULL);
   gtk_label_set_line_wrap (GTK_LABEL (label), TRUE);
-  gtk_misc_set_alignment (GTK_MISC (label), 0.5, 0.5);
   gtk_widget_show (label);
   gtk_container_add (GTK_CONTAINER (fixedtip), label);
   fixedtip->priv->label = label;
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH 19/25] showdesktop: port to use scaling-image2

[Jussi Kukkonen]

From: Ross Burton 

---
 applets/showdesktop/showdesktop.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/applets/showdesktop/showdesktop.c 
b/applets/showdesktop/showdesktop.c
index e40ebc3..14f9d96 100644
--- a/applets/showdesktop/showdesktop.c
+++ b/applets/showdesktop/showdesktop.c
@@ -11,11 +11,11 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 typedef struct {
 GtkButton *button;
-MBPanelScalingImage *image;
+MBPanelScalingImage2 *image;
 
 gboolean active;
 
@@ -45,15 +45,11 @@ show_desktop_applet_free (ShowDesktopApplet *applet)
 static void
 set_active (ShowDesktopApplet *applet, gboolean active)
 {
-const char *icon;
-
 applet->active = active;
 
 /* TODO: remove this function and instead use a toggle button? */
 
-icon = "panel-user-desktop";
-
-mb_panel_scaling_image_set_icon (applet->image, icon);
+mb_panel_scaling_image2_set_icon (applet->image, "panel-user-desktop");
 }
 
 /* Sync @applet with the _NET_SHOWING_DESKTOP root window property */
@@ -206,8 +202,8 @@ mb_panel_applet_create (const char*id,
 
 gtk_widget_set_name (button, "MatchboxPanelShowDesktop");
 
-image = mb_panel_scaling_image_new (orientation, NULL);
-applet->image = MB_PANEL_SCALING_IMAGE (image);
+image = mb_panel_scaling_image2_new (orientation, NULL);
+applet->image = MB_PANEL_SCALING_IMAGE2 (image);
 
 gtk_container_add (GTK_CONTAINER (button), image);
 
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH 20/25] Fix a crash on startup

[Jussi Kukkonen]

---
 matchbox-panel/mb-panel-scaling-image2.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/matchbox-panel/mb-panel-scaling-image2.c 
b/matchbox-panel/mb-panel-scaling-image2.c
index 5692ce1..8cdc3a1 100644
--- a/matchbox-panel/mb-panel-scaling-image2.c
+++ b/matchbox-panel/mb-panel-scaling-image2.c
@@ -327,8 +327,10 @@ mb_panel_scaling_image2_draw (GtkWidget *widget, cairo_t 
*cr)
 {
 MBPanelScalingImage2 *image = MB_PANEL_SCALING_IMAGE2 (widget);
 
-gdk_cairo_set_source_pixbuf (cr, image->priv->pixbuf, 0.0, 0.0);
-cairo_paint (cr);
+if (image->priv->pixbuf) {
+gdk_cairo_set_source_pixbuf (cr, image->priv->pixbuf, 0.0, 
0.0);
+cairo_paint (cr);
+}
 return TRUE;
 }
 
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH 17/25] scaling-image2: revised and slimmer scaling image implementation

[Jussi Kukkonen]

From: Ross Burton 

No caching, but it's lighter and doesn't misbehave (i.e. size-allocate loop).
---
 matchbox-panel/Makefile.am   |   4 +-
 matchbox-panel/mb-panel-scaling-image2.c | 449 +++
 matchbox-panel/mb-panel-scaling-image2.h |  64 +
 3 files changed, 515 insertions(+), 2 deletions(-)
 create mode 100644 matchbox-panel/mb-panel-scaling-image2.c
 create mode 100644 matchbox-panel/mb-panel-scaling-image2.h

diff --git a/matchbox-panel/Makefile.am b/matchbox-panel/Makefile.am
index 67e0756..a102402 100644
--- a/matchbox-panel/Makefile.am
+++ b/matchbox-panel/Makefile.am
@@ -7,11 +7,11 @@ AM_CFLAGS = $(WARN_CFLAGS)
 
 matchbox_panelincdir = $(pkgincludedir)
 
-matchbox_panelinc_HEADERS = mb-panel.h mb-panel-scaling-image.h
+matchbox_panelinc_HEADERS = mb-panel.h mb-panel-scaling-image.h 
mb-panel-scaling-image2.h
 
 bin_PROGRAMS = matchbox-panel
 
-matchbox_panel_SOURCES = mb-panel.c mb-panel-scaling-image.c
+matchbox_panel_SOURCES = mb-panel.c mb-panel-scaling-image.c 
mb-panel-scaling-image2.c
 
 matchbox_panel_LDADD = $(MATCHBOX_PANEL_LIBS)
 
diff --git a/matchbox-panel/mb-panel-scaling-image2.c 
b/matchbox-panel/mb-panel-scaling-image2.c
new file mode 100644
index 000..5692ce1
--- /dev/null
+++ b/matchbox-panel/mb-panel-scaling-image2.c
@@ -0,0 +1,449 @@
+/* -*- Mode: C; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 8 -*- */
+/*
+ * (C) 2013 Intel Corp
+ *
+ * Author: Ross Burton 
+ *
+ * Licensed under the GPL v2 or greater.
+ */
+
+#include 
+#include 
+#include 
+
+#include "mb-panel-scaling-image2.h"
+
+struct _MBPanelScalingImage2Private {
+GtkOrientation orientation;
+char *icon;
+int size;
+GtkIconTheme *icon_theme;
+guint icon_theme_changed_id;
+GdkPixbuf *pixbuf;
+};
+
+enum {
+PROP_0,
+PROP_ORIENTATION,
+PROP_ICON,
+};
+
+G_DEFINE_TYPE (MBPanelScalingImage2,
+   mb_panel_scaling_image2,
+   GTK_TYPE_DRAWING_AREA);
+
+static void
+mb_panel_scaling_image2_init (MBPanelScalingImage2 *image)
+{
+image->priv = G_TYPE_INSTANCE_GET_PRIVATE (image,
+   
MB_PANEL_TYPE_SCALING_IMAGE2,
+   
MBPanelScalingImage2Private);
+
+image->priv->orientation = GTK_ORIENTATION_HORIZONTAL;
+
+image->priv->icon = NULL;
+
+image->priv->pixbuf = NULL;
+}
+
+static void
+mb_panel_scaling_image2_set_property (GObject  *object,
+ guint property_id,
+ const GValue *value,
+ GParamSpec   *pspec)
+{
+MBPanelScalingImage2 *image;
+
+image = MB_PANEL_SCALING_IMAGE2 (object);
+
+switch (property_id) {
+case PROP_ORIENTATION:
+image->priv->orientation = g_value_get_enum (value);
+break;
+case PROP_ICON:
+mb_panel_scaling_image2_set_icon (image,
+ g_value_get_string (value));
+break;
+default:
+G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
+break;
+}
+}
+
+static void
+mb_panel_scaling_image2_get_property (GObject*object,
+ guint   property_id,
+ GValue *value,
+ GParamSpec *pspec)
+{
+MBPanelScalingImage2 *image;
+
+image = MB_PANEL_SCALING_IMAGE2 (object);
+
+switch (property_id) {
+case PROP_ORIENTATION:
+g_value_set_enum (value, image->priv->orientation);
+break;
+case PROP_ICON:
+g_value_set_string (value, image->priv->icon);
+break;
+default:
+G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
+break;
+}
+}
+
+static void
+mb_panel_scaling_image2_dispose (GObject *object)
+{
+MBPanelScalingImage2 *image;
+GObjectClass *object_class;
+
+object_class = G_OBJECT_CLASS (mb_panel_scaling_image2_parent_class);
+image = MB_PANEL_SCALING_IMAGE2 (object);
+
+if (image->priv->icon_theme_changed_id) {
+g_signal_handler_disconnect
+(image->priv->icon_theme,
+ image->priv->icon_theme_changed_id);
+image->priv->icon_theme_changed_id = 0;
+}
+
+object_class->dispose (object);
+}
+
+static void
+mb_panel_scaling_image2_finalize (GObject *object)
+{
+MBPanelScalingImage2 *image;
+GObjectClass *object_class;
+
+object_class = G_OBJECT_CLASS (mb_panel_scaling_image2_parent_class);
+image = MB_PANEL_SCALING_IMAGE2 (object);
+
+g_free 

[yocto] [matchbox-panel-2][PATCH 18/25] applets: add scaling-image2 to the test harness

[Jussi Kukkonen]

From: Ross Burton 

---
 applets/Makefile.applets | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/applets/Makefile.applets b/applets/Makefile.applets
index 9538818..1fff4ff 100644
--- a/applets/Makefile.applets
+++ b/applets/Makefile.applets
@@ -9,5 +9,6 @@ appletdir = $(pkglibdir)
 # Binary to check that the applet actually links against everything it needs.
 noinst_PROGRAMS = test-linkage
 test_linkage_SOURCES = $(srcdir)/../common/test_main.c \
-   $(top_srcdir)/matchbox-panel/mb-panel-scaling-image.c
+   $(top_srcdir)/matchbox-panel/mb-panel-scaling-image.c \
+   $(top_srcdir)/matchbox-panel/mb-panel-scaling-image2.c
 test_linkage_LDADD = $(MATCHBOX_PANEL_LIBS)
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH 12/25] build: bump version to 2.9

[Jussi Kukkonen]

From: Ross Burton 

---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 101df2d..c03c62e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
 AC_PREREQ(2.53)
-AC_INIT(matchbox-panel, 2.0, http://www.openedhand.com/)
+AC_INIT(matchbox-panel, 2.9, http://www.openedhand.com/)
 AM_INIT_AUTOMAKE([-Wno-portability])
 AC_CONFIG_SRCDIR(matchbox-panel/mb-panel.c)
 AM_CONFIG_HEADER(config.h)
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH 11/25] po: update POTFILES.in

[Jussi Kukkonen]

From: Ross Burton 

---
 po/POTFILES.in | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/po/POTFILES.in b/po/POTFILES.in
index b98a590..3ffdd38 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -1,12 +1,22 @@
-matchbox-panel/mb-panel-scaling-image.c
-matchbox-panel/mb-panel.c
-applets/launcher/launcher.c
-applets/startup/startup.c
+applets/exit/exit.c
 applets/windowselector/windowselector.c
+applets/startup/startup.c
+applets/battery/battery-apm.c
 applets/battery/battery.c
+applets/battery/battery-acpi.c
+applets/launcher/launcher.c
 applets/showdesktop/showdesktop.c
-applets/clock/clock.c
+applets/startup-notify/marshal.c
+applets/startup-notify/startup.c
 applets/systray/systray.c
-applets/systray/na-marshal.c
 applets/systray/na-tray-manager.c
-
+applets/systray/na-tray-child.c
+applets/systray/fixedtip.c
+applets/systray/na-tray.c
+applets/clock/clock.c
+applets/notify/mb-notification.c
+applets/notify/marshal.c
+applets/notify/notify-store.c
+applets/notify/applet.c
+applets/brightness/brightness.c
+applets/common/test_main.c
-- 
2.8.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto