Re: [ptxdist] Ptxdist BSP for STM32MP15x SoC

2019-09-02 Thread Robert Schwebel
Hi,

On Mon, Sep 02, 2019 at 07:35:25PM +0200, Guillermo Rodriguez Garcia wrote:
> Is someone using ptxdist with STM32MP15x based targets? ST only supports Yocto
> for this SoC.
> 
> Re. toolchain: Any recommended version of OSELAS.Toolchain? Any hints on
> settings to finetune for this CPU? This is a single or dual Cortex A7
> (depending on the actual p/n), and has NEON + VFPv4.

We made experiments with the MP1 recently, chances are good that we'll
get support for it soon in DistroKit. It should be part of the v7a
platform.

rsc
-- 
Pengutronix e.K.   | Dipl.-Ing. Robert Schwebel  |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
ptxdist mailing list
ptxdist@pengutronix.de


[ptxdist] Ptxdist BSP for STM32MP15x SoC

2019-09-02 Thread Guillermo Rodriguez Garcia
Hi all,

Is someone using ptxdist with STM32MP15x based targets? ST only supports
Yocto for this SoC.

Re. toolchain: Any recommended version of OSELAS.Toolchain? Any hints on
settings to finetune for this CPU? This is a single or dual Cortex A7
(depending on the actual p/n), and has NEON + VFPv4.

Thanks,

Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
ptxdist mailing list
ptxdist@pengutronix.de


[ptxdist] [PATCH v3 2/2] doc: remove empty chapter "Working with GIT sources"

2019-09-02 Thread Roland Hieber
All options for git:// _URLs are explained in that same paragraph,
`git ptx-patches` is already explained in the "Patching Packages"
chapter, and out-of-tree building is explained in the Daily Work
chapter. If anything else related to Git is still open, this chapter can
be re-added later, but it is useless for now (and regularly confuses me
when looking for the location where all those things mentioned above are
explained).

Fixes: 185c2bebaa1686f2faac ("Split the daily-work section into separate files")
Signed-off-by: Roland Hieber 
---

Notes:
v2 -> v3:
 - also remove the include from daily_work_section.rst

v1 -> v2: no changes

 doc/daily_work_section.rst   | 1 -
 doc/ref_make_variables.inc   | 3 +--
 doc/working_with_git_sources.inc | 6 --
 3 files changed, 1 insertion(+), 9 deletions(-)
 delete mode 100644 doc/working_with_git_sources.inc

diff --git a/doc/daily_work_section.rst b/doc/daily_work_section.rst
index 42a61e3c42dc..b9c4c0b5d98f 100644
--- a/doc/daily_work_section.rst
+++ b/doc/daily_work_section.rst
@@ -4,5 +4,4 @@ Various Aspects of Daily Work
 .. include:: daily_work.inc
 .. include:: nfsroot.inc
 .. include:: multi_image_platforms.inc
-.. include:: working_with_git_sources.inc
 .. include:: including_bsp_doc.inc
diff --git a/doc/ref_make_variables.inc b/doc/ref_make_variables.inc
index f2b491b407e9..e9a5c5a136ce 100644
--- a/doc/ref_make_variables.inc
+++ b/doc/ref_make_variables.inc
@@ -192,8 +192,7 @@ Package Definition
   archive defined ``_SOURCE`` and use it if available.
 
   Git URLs must either start with 'git://' or end with '.git'. They have a
-  mandatory ``tag=`` option. Refer :ref:`gitSources` how to make use 
of
-  it.
+  mandatory ``tag=`` option.
 
   Svn URLs must start with 'svn://'. They have a mandatory
   ``rev=r`` option.
diff --git a/doc/working_with_git_sources.inc b/doc/working_with_git_sources.inc
deleted file mode 100644
index 0514ba96640f..
--- a/doc/working_with_git_sources.inc
+++ /dev/null
@@ -1,6 +0,0 @@
-.. _gitSources:
-
-Working with GIT sources
-
-
-TBD
-- 
2.23.0


___
ptxdist mailing list
ptxdist@pengutronix.de


[ptxdist] [PATCH v3 1/2] doc: dev manual: proof-read and update the "Patching Packages" section

2019-09-02 Thread Roland Hieber
Remind the reader to upstream their patches, mention the layer
mechanism for search order, fix the logical structure of the whole
chapter by removing the superfluous "Creating Patches for a Package"
header, mention why `--git` can break packages, and general
proof-reading and typo correction.

Signed-off-by: Roland Hieber 
---

Notes:
v2 -> v3:
 - reformulate search order for layers
 - reformulate "experimental" explanation about --git
 - keep git lowercase where the command line tool is meant

v1 -> v2:
 - fix a vim-not-in-command-mode bug

 doc/dev_manual.rst | 52 +-
 1 file changed, 33 insertions(+), 19 deletions(-)

diff --git a/doc/dev_manual.rst b/doc/dev_manual.rst
index d79ebdba780d..3dcaeb3d31fa 100644
--- a/doc/dev_manual.rst
+++ b/doc/dev_manual.rst
@@ -494,7 +494,7 @@ At this stage things can fail:
 
 If the ``configure`` script is not cross compile aware, we are out of
 luck. We must patch the source archive in this case to make it work.
-Refer to section :ref:`configure_rebuild` on how to use
+Refer to the section :ref:`configure_rebuild` on how to use
 PTXdist’s features to simplify this task.
 If the package depends on external components, these components might
 be already part of PTXdist. In this case we just have to add this
@@ -1255,14 +1255,28 @@ There can be various reasons why a package must be 
patched:
 
 -  or anything else (this case is the most common one)
 
-PTXdist handles patching automatically. After extracting the archive,
-PTXdist checks for the existence of a patch directory with the same name
-as the package. If our package’s name is ``foo-1.1.0``, PTXdist searches
-for patches in:
+Ideally, those problems should be adressed in the original project,
+so any patches you add to your BSP or to PTXdist should also be submitted 
upstream.
+The upstream project can often provide better feedback, they can integrate your
+patch into a new release, and also maintain your changes as part of the 
project.
+This way we make sure that all advantages of the open source idea work for us;
+and your patch can be removed again later when a new release of the project is
+integrated into your BSP or into PTXdist.
 
-#. project (``./patches/foo-1.1.0``)
+PTXdist handles patching automatically.
+After extracting the archive of a package, PTXdist checks for the existence of
+a patch directory named like its `` variable.
+Take an exemplary package `foo` with version `1.1.0`:
+The variable `FOO` will have the value ``foo-1.1.0``, so PTXdist will look for
+a patch directory named ``foo-1.1.0`` in the following locations:
 
-#. platform (``./configs/|ptxdistPlatformConfigDir|/patches/foo-1.1.0``)
+#. the current layer:
+
+   a. project (``./patches/foo-1.1.0``)
+   b. platform (``./configs/|ptxdistPlatformConfigDir|/patches/foo-1.1.0``)
+
+#. any :ref:`base layers `,
+   applying the same search order as above for each layer recursively
 
 #. ptxdist (``/patches/foo-1.1.0``)
 
@@ -1272,9 +1286,6 @@ PTXdist installation. This can be useful if a project 
sticks to a
 specific PTXdist revision but fixes from a more recent revision of
 PTXdist should be used.
 
-Creating Patches for a Package
-~~
-
 PTXdist uses the utilities *git*, *patch* or *quilt* to work with
 patches or patch series. We recommend *git*, as it can manage patch
 series in a very easy way.
@@ -1331,7 +1342,7 @@ Using Git
 "
 
 Create the patch directory like above for *quilt*,
-but only add an empty series file
+but only add an empty series file:
 
 .. code-block:: text
 
@@ -1351,8 +1362,9 @@ and import the package source as the first commit.
 .. note:: Optionally, you can enable the setting *Developer Options →
   use git to apply patches* in `ptxdist setup` to get this behaviour
   as a default for every package.
-  However, note that this setting is still experimental and can lead to
-  failures for some packages.
+  However, note that this setting is meant for development only, and can lead
+  to failures – some packages try to determine if they are being compiled from
+  a Git source tree, and behave differently in that case.
 
 Then you can change into the package build directory
 (``platform-/build-target/foo-1.1.0``),
@@ -1367,8 +1379,8 @@ The Git history should now look something like this:
 * 65a360c2bd60 strfry.c: frobnicate the excusator
 * fdc315f6844c (tag: foobar-1.1.0, tag: base) initial commit
 
-Finally, call ``git ptx-patches`` to regenerate the patch series in the
-``patches/foo-1.1.0`` folder.
+Finally, call ``git ptx-patches`` to transform those Git commits into the patch
+series in the ``patches/foo-1.1.0`` folder.
 This way they don't get lost when cleaning the package.
 
 .. note:: PTXdist will only create a Git repository for packages with
@@ -1379,7 +1391,7 @@ This way they don't get lost when cleaning the package.
 
 Both approaches (Git and quilt) are not suitable for modifying files
 

Re: [ptxdist] [PATCH v2 1/2] doc: dev manual: proof-read and update the "Patching Packages" section

2019-09-02 Thread Roland Hieber
On Mon, Sep 02, 2019 at 11:02:00AM +0200, Michael Olbrich wrote:
> On Fri, Aug 30, 2019 at 03:36:37PM +0200, Roland Hieber wrote:
> > Remind the reader to upstream their patches, mention the layer
> > mechanism for search order, fix the logical structure of the whole
> > chapter by removing the superfluous "Creating Patches for a Package"
> > header, mention why `--git` can break packages, and general
> > proof-reading and typo correction.
> > 
> > Signed-off-by: Roland Hieber 
> > ---
> >  doc/dev_manual.rst | 44 
> >  1 file changed, 28 insertions(+), 16 deletions(-)
> > 
> > diff --git a/doc/dev_manual.rst b/doc/dev_manual.rst
> > index d79ebdba780d..5dcad97d4a6c 100644
> > --- a/doc/dev_manual.rst
> > +++ b/doc/dev_manual.rst
> > @@ -494,7 +494,7 @@ At this stage things can fail:
> >  
> >  If the ``configure`` script is not cross compile aware, we are out of
> >  luck. We must patch the source archive in this case to make it work.
> > -Refer to section :ref:`configure_rebuild` on how to use
> > +Refer to the section :ref:`configure_rebuild` on how to use
> >  PTXdist’s features to simplify this task.
> >  If the package depends on external components, these components might
> >  be already part of PTXdist. In this case we just have to add this
> > @@ -1255,15 +1255,27 @@ There can be various reasons why a package must be 
> > patched:
> >  
> >  -  or anything else (this case is the most common one)
> >  
> > -PTXdist handles patching automatically. After extracting the archive,
> > -PTXdist checks for the existence of a patch directory with the same name
> > -as the package. If our package’s name is ``foo-1.1.0``, PTXdist searches
> > -for patches in:
> > +Ideally, those problems should be adressed in the original project,
> > +so any patches you add to your BSP or to PTXdist should also be submitted 
> > upstream.
> > +The upstream project can often provide better feedback, they can integrate 
> > your
> > +patch into a new release, and also maintain your changes as part of the 
> > project.
> > +This way we make sure that all advantages of the open source idea work for 
> > us;
> > +and your patch can be removed again later when a new release of the 
> > project is
> > +integrated into your BSP or into PTXdist.
> > +
> > +PTXdist handles patching automatically.
> > +After extracting the archive of a package, PTXdist checks for the 
> > existence of
> > +a patch directory named like its `` variable.
> > +Take an exemplary package `foo` with version `1.1.0`:
> > +The variable `FOO` will have the value ``foo-1.1.0``, so PTXdist will look 
> > for
> > +a patch directory named ``foo-1.1.0`` in the following locations:
> >  
> >  #. project (``./patches/foo-1.1.0``)
> >  
> >  #. platform (``./configs/|ptxdistPlatformConfigDir|/patches/foo-1.1.0``)
> >  
> > +#. the base layer (see :ref:`layers-in-ptxdist`)
> > +
> 
> Hmmm, there can be zero to N layers. Maybe "all other layers (see ...)"
> 
> >  #. ptxdist (``/patches/foo-1.1.0``)
> >  
> >  The patches from the first location found are used. Note: Due to this
> > @@ -1272,9 +1284,6 @@ PTXdist installation. This can be useful if a project 
> > sticks to a
> >  specific PTXdist revision but fixes from a more recent revision of
> >  PTXdist should be used.
> >  
> > -Creating Patches for a Package
> > -~~
> 
> Maybe use this heading above instead of 'Patching Packages' for the whole
> section?

The next section after that also already starts with "Creating...", so
I'd like to prevent repetition here and leave it as-is.

For all other comments, see v3.

 - Roland

> > -
> >  PTXdist uses the utilities *git*, *patch* or *quilt* to work with
> >  patches or patch series. We recommend *git*, as it can manage patch
> >  series in a very easy way.
> > @@ -1331,7 +1340,7 @@ Using Git
> >  "
> >  
> >  Create the patch directory like above for *quilt*,
> > -but only add an empty series file
> > +but only add an empty series file:
> >  
> >  .. code-block:: text
> >  
> > @@ -1352,7 +1361,8 @@ and import the package source as the first commit.
> >use git to apply patches* in `ptxdist setup` to get this behaviour
> >as a default for every package.
> >However, note that this setting is still experimental and can lead to
> 
> Hmm 'experimental' is not correct any more. Can you change this too? Maybe:
> 
> However, note that this is a development feature that can lead to
> unexpected failures - ...
> 
> > -  failures for some packages.
> > +  failures – some packages try to determine if they are being compiled
> > +  from a Git source tree, and behave differently in that case.
> >  
> >  Then you can change into the package build directory
> >  (``platform-/build-target/foo-1.1.0``),
> > @@ -1367,8 +1377,8 @@ The Git history should now look something like this:
> >  * 65a360c2bd60 strfry.c: frobnicate the excusator
> >  * fdc315f6844c (tag: foobar-1.1.0, tag: base) 

Re: [ptxdist] [PATCH] README: update

2019-09-02 Thread Ladislav Michl
On Mon, Sep 02, 2019 at 11:09:49AM +0200, Michael Olbrich wrote:
> On Mon, Sep 02, 2019 at 10:23:40AM +0200, Michael Tretter wrote:
> > On Sun, 01 Sep 2019 23:04:56 +0200, Roland Hieber wrote:
[...]
> > > @@ -107,15 +98,14 @@ Bugs
> > >  
> > >  
> > >  - search for FIXMEs
> > > -- see TODO
> > >  
> > > -For documentation please refer:
> > > 
> > > +For documentation please refer to:
> > > +--
> > >  
> > > -http://www.pengutronix.de/software/ptxdist/documentation_en.html
> > > +https://www.ptxdist.org/doc
> > >  
> > > -For Patch Tagging please refer:
> > > 
> > > +For Patch Tagging please refer to:
> > > +--
> > >  
> > >  http://dep.debian.net/deps/dep3/
> > >  
> 
> I think this part should be removed. We don't do it like this anyways and
> either way, the README is not the place for this.

So now it seems README would contain mostly instalation instructions. What
about moving them into INSTALL, rename README.devel to README and be done
with that? :)

ladis

___
ptxdist mailing list
ptxdist@pengutronix.de


[ptxdist] [PATCH v2] weston: version bump 6.0.1 -> 7.0.0

2019-09-02 Thread Philipp Zabel
Signed-off-by: Philipp Zabel 
---
 rules/weston.in   |  6 ++
 rules/weston.make | 11 ---
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/rules/weston.in b/rules/weston.in
index 42dcb9eeadbe..d2ef2119b432 100644
--- a/rules/weston.in
+++ b/rules/weston.in
@@ -110,6 +110,12 @@ config WESTON_IVISHELL_EXAMPLE
  application, a few demo clients and the weston.ini configuration for
  the IVI-Shell.
 
+config WESTON_PIPEWIRE
+   bool
+   prompt "pipewire plugin"
+   # needs pipewire
+   depends on BROKEN
+
 config WESTON_REMOTING
bool
prompt "remoting plugin"
diff --git a/rules/weston.make b/rules/weston.make
index 1dd13bfb32d3..4c38fd2d1aa1 100644
--- a/rules/weston.make
+++ b/rules/weston.make
@@ -15,9 +15,9 @@ PACKAGES-$(PTXCONF_WESTON) += weston
 #
 # Paths and names
 #
-WESTON_VERSION := 6.0.1
-LIBWESTON_MAJOR := 6
-WESTON_MD5 := e7b10710ef1eac82258f97bfd41fe534
+WESTON_VERSION := 7.0.0
+LIBWESTON_MAJOR := 7
+WESTON_MD5 := cbfda483bc2501d0831af3f33c707850
 WESTON := weston-$(WESTON_VERSION)
 WESTON_SUFFIX  := tar.xz
 WESTON_URL := 
http://wayland.freedesktop.org/releases/$(WESTON).$(WESTON_SUFFIX)
@@ -53,9 +53,11 @@ WESTON_CONF_OPT  := \
-Dcolor-management-lcms=false \
-Ddemo-clients=$(call ptx/truefalse,PTXCONF_WESTON_IVISHELL_EXAMPLE) \
-Ddesktop-shell-client-default=weston-desktop-shell \
+   -Ddoc=false \
-Dimage-jpeg=true \
-Dimage-webp=false \
-Dlauncher-logind=$(call ptx/truefalse,PTXCONF_WESTON_SYSTEMD_LOGIND) \
+   -Dpipewire=$(call ptx/truefalse,PTXCONF_WESTON_PIPEWIRE) \
-Dremoting=$(call ptx/truefalse,PTXCONF_WESTON_REMOTING) \
-Drenderer-gl=$(call ptx/truefalse,PTXCONF_WESTON_GL) \
-Dresize-pool=true \
@@ -154,6 +156,9 @@ ifdef PTXCONF_WESTON_GL
@$(call install_lib, weston, 0, 0, 0644, 
libweston-$(LIBWESTON_MAJOR)/wayland-backend)
@$(call install_lib, weston, 0, 0, 0644, 
libweston-$(LIBWESTON_MAJOR)/gl-renderer)
 endif
+ifdef PTXCONF_WESTON_PIPEWIRE
+   @$(call install_lib, weston, 0, 0, 0644, 
libweston-$(LIBWESTON_MAJOR)/pipewire-plugin)
+endif
 ifdef PTXCONF_WESTON_REMOTING
@$(call install_lib, weston, 0, 0, 0644, 
libweston-$(LIBWESTON_MAJOR)/remoting-plugin)
 endif
-- 
2.20.1


___
ptxdist mailing list
ptxdist@pengutronix.de


Re: [ptxdist] [PATCH] README: update

2019-09-02 Thread Michael Olbrich
On Mon, Sep 02, 2019 at 10:23:40AM +0200, Michael Tretter wrote:
> On Sun, 01 Sep 2019 23:04:56 +0200, Roland Hieber wrote:
> > When reading this README, the tarball was obviously already extracted,
> > so remove the very unclear section about how to get it. Anyway, anything
> > important is in the manual, which is linked later.
> 
> I agree that the section is unclear, but the README can be read from
> the git webview, too. Maybe this section should be rewritten for the
> viewpoint of a git user?

I think it can be removed. This section used to contain multiple archives
that had to be downloaded but all others are gone now.

> > 
> > TODO is no longer there since commit b710f8cdf410a91b4298 ("PTXdist:
> > remove useless and unmaintained files").
> > 
> > Link to the new documentation directly instead of through a redirected
> > URL, and fix incorrect use of "refer" in the section heading.
> > 
> > Signed-off-by: Roland Hieber 
> > ---
> >  README | 20 +---
> >  1 file changed, 5 insertions(+), 15 deletions(-)
> > 
> > diff --git a/README b/README
> > index 33cf90e0bc19..608b4749bdcd 100644
> > --- a/README
> > +++ b/README
> > @@ -1,15 +1,6 @@
> >  PTXdist
> >  ===
> >  
> > -Necessary Packages
> > ---
> > -
> > -In order to build ptxdist, you need this archive:
> > -
> > -   ptxdist-.tgz
> > -
> > -Extract this archive into some build directory.
> > -
> >  Installation
> >  
> >  
> > @@ -107,15 +98,14 @@ Bugs
> >  
> >  
> >  - search for FIXMEs
> > -- see TODO
> >  
> > -For documentation please refer:
> > 
> > +For documentation please refer to:
> > +--
> >  
> > -http://www.pengutronix.de/software/ptxdist/documentation_en.html
> > +https://www.ptxdist.org/doc
> >  
> > -For Patch Tagging please refer:
> > 
> > +For Patch Tagging please refer to:
> > +--
> >  
> >  http://dep.debian.net/deps/dep3/
> >  

I think this part should be removed. We don't do it like this anyways and
either way, the README is not the place for this.

Michael

> 
> ___
> ptxdist mailing list
> ptxdist@pengutronix.de
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
ptxdist mailing list
ptxdist@pengutronix.de


Re: [ptxdist] [PATCH v2 1/2] doc: dev manual: proof-read and update the "Patching Packages" section

2019-09-02 Thread Michael Olbrich
On Fri, Aug 30, 2019 at 03:36:37PM +0200, Roland Hieber wrote:
> Remind the reader to upstream their patches, mention the layer
> mechanism for search order, fix the logical structure of the whole
> chapter by removing the superfluous "Creating Patches for a Package"
> header, mention why `--git` can break packages, and general
> proof-reading and typo correction.
> 
> Signed-off-by: Roland Hieber 
> ---
>  doc/dev_manual.rst | 44 
>  1 file changed, 28 insertions(+), 16 deletions(-)
> 
> diff --git a/doc/dev_manual.rst b/doc/dev_manual.rst
> index d79ebdba780d..5dcad97d4a6c 100644
> --- a/doc/dev_manual.rst
> +++ b/doc/dev_manual.rst
> @@ -494,7 +494,7 @@ At this stage things can fail:
>  
>  If the ``configure`` script is not cross compile aware, we are out of
>  luck. We must patch the source archive in this case to make it work.
> -Refer to section :ref:`configure_rebuild` on how to use
> +Refer to the section :ref:`configure_rebuild` on how to use
>  PTXdist’s features to simplify this task.
>  If the package depends on external components, these components might
>  be already part of PTXdist. In this case we just have to add this
> @@ -1255,15 +1255,27 @@ There can be various reasons why a package must be 
> patched:
>  
>  -  or anything else (this case is the most common one)
>  
> -PTXdist handles patching automatically. After extracting the archive,
> -PTXdist checks for the existence of a patch directory with the same name
> -as the package. If our package’s name is ``foo-1.1.0``, PTXdist searches
> -for patches in:
> +Ideally, those problems should be adressed in the original project,
> +so any patches you add to your BSP or to PTXdist should also be submitted 
> upstream.
> +The upstream project can often provide better feedback, they can integrate 
> your
> +patch into a new release, and also maintain your changes as part of the 
> project.
> +This way we make sure that all advantages of the open source idea work for 
> us;
> +and your patch can be removed again later when a new release of the project 
> is
> +integrated into your BSP or into PTXdist.
> +
> +PTXdist handles patching automatically.
> +After extracting the archive of a package, PTXdist checks for the existence 
> of
> +a patch directory named like its `` variable.
> +Take an exemplary package `foo` with version `1.1.0`:
> +The variable `FOO` will have the value ``foo-1.1.0``, so PTXdist will look 
> for
> +a patch directory named ``foo-1.1.0`` in the following locations:
>  
>  #. project (``./patches/foo-1.1.0``)
>  
>  #. platform (``./configs/|ptxdistPlatformConfigDir|/patches/foo-1.1.0``)
>  
> +#. the base layer (see :ref:`layers-in-ptxdist`)
> +

Hmmm, there can be zero to N layers. Maybe "all other layers (see ...)"

>  #. ptxdist (``/patches/foo-1.1.0``)
>  
>  The patches from the first location found are used. Note: Due to this
> @@ -1272,9 +1284,6 @@ PTXdist installation. This can be useful if a project 
> sticks to a
>  specific PTXdist revision but fixes from a more recent revision of
>  PTXdist should be used.
>  
> -Creating Patches for a Package
> -~~

Maybe use this heading above instead of 'Patching Packages' for the whole
section?

> -
>  PTXdist uses the utilities *git*, *patch* or *quilt* to work with
>  patches or patch series. We recommend *git*, as it can manage patch
>  series in a very easy way.
> @@ -1331,7 +1340,7 @@ Using Git
>  "
>  
>  Create the patch directory like above for *quilt*,
> -but only add an empty series file
> +but only add an empty series file:
>  
>  .. code-block:: text
>  
> @@ -1352,7 +1361,8 @@ and import the package source as the first commit.
>use git to apply patches* in `ptxdist setup` to get this behaviour
>as a default for every package.
>However, note that this setting is still experimental and can lead to

Hmm 'experimental' is not correct any more. Can you change this too? Maybe:

However, note that this is a development feature that can lead to
unexpected failures - ...

> -  failures for some packages.
> +  failures – some packages try to determine if they are being compiled
> +  from a Git source tree, and behave differently in that case.
>  
>  Then you can change into the package build directory
>  (``platform-/build-target/foo-1.1.0``),
> @@ -1367,8 +1377,8 @@ The Git history should now look something like this:
>  * 65a360c2bd60 strfry.c: frobnicate the excusator
>  * fdc315f6844c (tag: foobar-1.1.0, tag: base) initial commit
>  
> -Finally, call ``git ptx-patches`` to regenerate the patch series in the
> -``patches/foo-1.1.0`` folder.
> +Finally, call ``git ptx-patches`` to transform those Git commits into the 
> patch
> +series in the ``patches/foo-1.1.0`` folder.
>  This way they don't get lost when cleaning the package.
>  
>  .. note:: PTXdist will only create a Git repository for packages with
> @@ -1379,7 +1389,7 @@ This way they don't get lost when 

Re: [ptxdist] [PATCH] libgpg-error: Fix build on hosts with gawk-5.0

2019-09-02 Thread Michael Olbrich
On Fri, Aug 30, 2019 at 11:20:00AM +, Koch, Alexander wrote:
> ---
>   .../0001-Fix-for-gawk-5.0.patch   | 159 ++
>   patches/libgpg-error-1.32/series  |   1 +
>   2 files changed, 160 insertions(+)
>   create mode 100644 patches/libgpg-error-1.32/0001-Fix-for-gawk-5.0.patch
>   create mode 100644 patches/libgpg-error-1.32/series
> 
> diff --git a/patches/libgpg-error-1.32/0001-Fix-for-gawk-5.0.patch 
> b/patches/libgpg-error-1.32/0001-Fix-for-gawk-5.0.patch
> new file mode 100644
> index 0..3b67387dc
> --- /dev/null
> +++ b/patches/libgpg-error-1.32/0001-Fix-for-gawk-5.0.patch
> @@ -0,0 +1,159 @@
> +From ff9ae9d6537975d556444b2a16e185170527e271 Mon Sep 17 00:00:00 2001
> +From: "Alexander Koch" 
> +Date: Fri, 30 Aug 2019 13:07:08 +0200
> +Subject: [PATCH] Fix for gawk-5.0

These is a upstream commit for this. Please use it.

> +
> +---
> + lang/cl/mkerrcodes.awk |  2 +-
> + src/Makefile.am|  2 +-
> + src/Makefile.in|  2 +-

Don't patch Makefile.in, add a autogen.sh (probably a symlink to
../autogen.sh like many other packages) instead to regenerate it.

Michael

> + src/mkerrcodes.awk |  2 +-
> + src/mkerrcodes1.awk|  2 +-
> + src/mkerrcodes2.awk|  2 +-
> + src/mkerrnos.awk   |  2 +-
> + src/mkstrtable.awk | 10 +-
> + 8 files changed, 12 insertions(+), 12 deletions(-)
> +
> +diff --git a/lang/cl/mkerrcodes.awk b/lang/cl/mkerrcodes.awk
> +index ae29043..9a1fc18 100644
> +--- a/lang/cl/mkerrcodes.awk
>  b/lang/cl/mkerrcodes.awk
> +@@ -122,7 +122,7 @@ header {
> + }
> +
> + !header {
> +-  sub (/\#.+/, "");
> ++  sub (/#.+/, "");
> +   sub (/[   ]+$/, ""); # Strip trailing space and tab characters.
> +
> +   if (/^$/)
> +diff --git a/src/Makefile.am b/src/Makefile.am
> +index 42998e4..0ceac9f 100644
> +--- a/src/Makefile.am
>  b/src/Makefile.am
> +@@ -281,7 +281,7 @@ code-from-errno.h: mkerrcodes Makefile
> +
> + errnos-sym.h: Makefile mkstrtable.awk errnos.in
> + $(AWK) -f $(srcdir)/mkstrtable.awk -v textidx=2 -v nogettext=1 \
> +--v prefix=GPG_ERR_ -v namespace=errnos_ \
> ++-v prefix=GPG_ERR_ -v pkg_namespace=errnos_ \
> + $(srcdir)/errnos.in >$@
> +
> +
> +diff --git a/src/Makefile.in b/src/Makefile.in
> +index 9ffb29d..a9efa38 100644
> +--- a/src/Makefile.in
>  b/src/Makefile.in
> +@@ -1449,7 +1449,7 @@ code-from-errno.h: mkerrcodes Makefile
> +
> + errnos-sym.h: Makefile mkstrtable.awk errnos.in
> + $(AWK) -f $(srcdir)/mkstrtable.awk -v textidx=2 -v nogettext=1 \
> +--v prefix=GPG_ERR_ -v namespace=errnos_ \
> ++-v prefix=GPG_ERR_ -v pkg_namespace=errnos_ \
> + $(srcdir)/errnos.in >$@
> +
> + mkheader: mkheader.c Makefile
> +diff --git a/src/mkerrcodes.awk b/src/mkerrcodes.awk
> +index 46d436c..e9c857c 100644
> +--- a/src/mkerrcodes.awk
>  b/src/mkerrcodes.awk
> +@@ -85,7 +85,7 @@ header {
> + }
> +
> + !header {
> +-  sub (/\#.+/, "");
> ++  sub (/#.+/, "");
> +   sub (/[   ]+$/, ""); # Strip trailing space and tab characters.
> +
> +   if (/^$/)
> +diff --git a/src/mkerrcodes1.awk b/src/mkerrcodes1.awk
> +index a771a73..4578e29 100644
> +--- a/src/mkerrcodes1.awk
>  b/src/mkerrcodes1.awk
> +@@ -81,7 +81,7 @@ header {
> + }
> +
> + !header {
> +-  sub (/\#.+/, "");
> ++  sub (/#.+/, "");
> +   sub (/[   ]+$/, ""); # Strip trailing space and tab characters.
> +
> +   if (/^$/)
> +diff --git a/src/mkerrcodes2.awk b/src/mkerrcodes2.awk
> +index ea58503..188f7a4 100644
> +--- a/src/mkerrcodes2.awk
>  b/src/mkerrcodes2.awk
> +@@ -91,7 +91,7 @@ header {
> + }
> +
> + !header {
> +-  sub (/\#.+/, "");
> ++  sub (/#.+/, "");
> +   sub (/[   ]+$/, ""); # Strip trailing space and tab characters.
> +
> +   if (/^$/)
> +diff --git a/src/mkerrnos.awk b/src/mkerrnos.awk
> +index f79df66..15b1aad 100644
> +--- a/src/mkerrnos.awk
>  b/src/mkerrnos.awk
> +@@ -83,7 +83,7 @@ header {
> + }
> +
> + !header {
> +-  sub (/\#.+/, "");
> ++  sub (/#.+/, "");
> +   sub (/[   ]+$/, ""); # Strip trailing space and tab characters.
> +
> +   if (/^$/)
> +diff --git a/src/mkstrtable.awk b/src/mkstrtable.awk
> +index c9de9c1..285e45f 100644
> +--- a/src/mkstrtable.awk
>  b/src/mkstrtable.awk
> +@@ -77,7 +77,7 @@
> + #
> + # The variable prefix can be used to prepend a string to each message.
> + #
> +-# The variable namespace can be used to prepend a string to each
> ++# The variable pkg_namespace can be used to prepend a string to each
> + # variable and macro name.
> +
> + BEGIN {
> +@@ -102,7 +102,7 @@ header {
> +   print "/* The purpose of this complex string table is to produce";
> +   print "   optimal code with a minimum of relocations.  */";
> +   print "";
> +-  print "static const char " namespace "msgstr[] = ";
> ++  print "static const char " pkg_namespace "msgstr[] = ";
> +   header = 0;
> + }
> +   else
> +@@ -110,7 +110,7 @@ header {
> + }
> +
> + !header {
> +-  sub (/\#.+/, "");
> 

Re: [ptxdist] [PATCH v1] add socketcand package

2019-09-02 Thread Michael Olbrich
On Fri, Aug 30, 2019 at 11:06:32AM +0200, Oleksij Rempel wrote:
> Socketcand is a daemon that provides access to CAN interfaces on a
> machine via a network interface. The communication protocol uses a
> TCP/IP connection and a specific protocol to transfer CAN frames and
> control commands.
> 
> Signed-off-by: Oleksij Rempel 
> ---
>  .../socketcand-0.4.2-27-gec47073/autogen.sh   |  1 +
>  projectroot/etc/socketcand.conf   | 19 +++
>  .../usr/lib/systemd/system/socketcand.service |  7 +++
>  rules/socketcand.in   | 12 
>  rules/socketcand.make | 56 +++
>  5 files changed, 95 insertions(+)
>  create mode 12 patches/socketcand-0.4.2-27-gec47073/autogen.sh
>  create mode 100644 projectroot/etc/socketcand.conf
>  create mode 100644 projectroot/usr/lib/systemd/system/socketcand.service
>  create mode 100644 rules/socketcand.in
>  create mode 100644 rules/socketcand.make
> 
> diff --git a/patches/socketcand-0.4.2-27-gec47073/autogen.sh 
> b/patches/socketcand-0.4.2-27-gec47073/autogen.sh
> new file mode 12
> index 0..9f8a4cb7d
> --- /dev/null
> +++ b/patches/socketcand-0.4.2-27-gec47073/autogen.sh
> @@ -0,0 +1 @@
> +../autogen.sh
> \ No newline at end of file
> diff --git a/projectroot/etc/socketcand.conf b/projectroot/etc/socketcand.conf
> new file mode 100644
> index 0..0fdc19d07
> --- /dev/null
> +++ b/projectroot/etc/socketcand.conf
> @@ -0,0 +1,19 @@
> +# The network interface the socketcand will bind to
> +# listen = "eth0";
> +
> +# The port the socketcand is listening on
> +# port = 29536;
> +
> +# List of busses the daemon shall provide access to
> +# Multiple busses must be separated with ',' and whitespace
> +# is not allowed. eg "vcan0,vcan1"
> +busses = "can0";
> +
> +# Description of the service. This will show up in the discovery beacon
> +# description = "socketcand";
> +
> +# AF_UNIX name. As alternative to bind to a TCP/IP socket the socketcand can
> +# listen on an AF_UNIX socket.
> +# When afuxname starts with a '/' a path for the AF_UNIX socket is created.
> +# Alternatively an abstact AF_UNIX namespace is allocated with afuxname
> +# afuxname = "socketcand";
> diff --git a/projectroot/usr/lib/systemd/system/socketcand.service 
> b/projectroot/usr/lib/systemd/system/socketcand.service
> new file mode 100644
> index 0..3c1030676
> --- /dev/null
> +++ b/projectroot/usr/lib/systemd/system/socketcand.service
> @@ -0,0 +1,7 @@
> +[Unit]
> +Description=Server to access CAN sockets over ASCII protocol
> +After=network.target
> +
> +[Service]
> +ExecStart=/usr/bin/socketcand
> +Restart=always
> diff --git a/rules/socketcand.in b/rules/socketcand.in
> new file mode 100644
> index 0..779721208
> --- /dev/null
> +++ b/rules/socketcand.in
> @@ -0,0 +1,12 @@
> +## SECTION=communication
> +
> +config SOCKETCAND
> + tristate
> + prompt "socketcand"
> + select LIBCONFIG
> + help
> +   Socketcand is a daemon that provides access to CAN interfaces on a
> +   machine via a network interface. The communication protocol uses a
> +   TCP/IP connection and a specific protocol to transfer CAN frames and
> +   control commands.
> +
> diff --git a/rules/socketcand.make b/rules/socketcand.make
> new file mode 100644
> index 0..ecff9e05b
> --- /dev/null
> +++ b/rules/socketcand.make
> @@ -0,0 +1,56 @@
> +# -*-makefile-*-
> +#
> +# Copyright (C) 2019 by Oleksij Rempel 
> +#
> +# For further information about the PTXdist project and license conditions
> +# see the README file.
> +#
> +
> +#
> +# We provide this package
> +#
> +PACKAGES-$(PTXCONF_SOCKETCAND) += socketcand
> +
> +#
> +# Paths and names
> +#
> +SOCKETCAND_VERSION   := 0.4.2-27-gec47073
> +SOCKETCAND_MD5   := 2b32adf77d359af0f3cca27050e2c32d
> +SOCKETCAND   := socketcand-$(SOCKETCAND_VERSION)
> +SOCKETCAND_SUFFIX:= tar.gz
> +SOCKETCAND_URL   := 
> https://github.com/linux-can/socketcand/archive/$(SOCKETCAND_VERSION).$(SOCKETCAND_SUFFIX)
> +SOCKETCAND_SOURCE:= $(SRCDIR)/$(SOCKETCAND).$(SOCKETCAND_SUFFIX)
> +SOCKETCAND_DIR   := $(BUILDDIR)/$(SOCKETCAND)
> +SOCKETCAND_LICENSE   := GPL-2.0
> +
> +# 
> 
> +# Prepare
> +# 
> 
> +
> +SOCKETCAND_CONF_TOOL := autoconf
> +
> +# 
> 
> +# Target-Install
> +# 
> 
> +
> +$(STATEDIR)/socketcand.targetinstall:
> + @$(call targetinfo)
> +
> + @$(call install_init, socketcand)
> + @$(call install_fixup, socketcand,PRIORITY,optional)
> + @$(call install_fixup, socketcand,SECTION,base)
> + @$(call install_fixup, socketcand,AUTHOR,"Oleksij Rempel 
> ")
> + @$(call install_fixup, 

Re: [ptxdist] [PATCH] README: update

2019-09-02 Thread Michael Tretter
On Sun, 01 Sep 2019 23:04:56 +0200, Roland Hieber wrote:
> When reading this README, the tarball was obviously already extracted,
> so remove the very unclear section about how to get it. Anyway, anything
> important is in the manual, which is linked later.

I agree that the section is unclear, but the README can be read from
the git webview, too. Maybe this section should be rewritten for the
viewpoint of a git user?

Michael

> 
> TODO is no longer there since commit b710f8cdf410a91b4298 ("PTXdist:
> remove useless and unmaintained files").
> 
> Link to the new documentation directly instead of through a redirected
> URL, and fix incorrect use of "refer" in the section heading.
> 
> Signed-off-by: Roland Hieber 
> ---
>  README | 20 +---
>  1 file changed, 5 insertions(+), 15 deletions(-)
> 
> diff --git a/README b/README
> index 33cf90e0bc19..608b4749bdcd 100644
> --- a/README
> +++ b/README
> @@ -1,15 +1,6 @@
>  PTXdist
>  ===
>  
> -Necessary Packages
> ---
> -
> -In order to build ptxdist, you need this archive:
> -
> - ptxdist-.tgz
> -
> -Extract this archive into some build directory.
> -
>  Installation
>  
>  
> @@ -107,15 +98,14 @@ Bugs
>  
>  
>  - search for FIXMEs
> -- see TODO
>  
> -For documentation please refer:
> 
> +For documentation please refer to:
> +--
>  
> -http://www.pengutronix.de/software/ptxdist/documentation_en.html
> +https://www.ptxdist.org/doc
>  
> -For Patch Tagging please refer:
> 
> +For Patch Tagging please refer to:
> +--
>  
>  http://dep.debian.net/deps/dep3/
>  

___
ptxdist mailing list
ptxdist@pengutronix.de


Re: [ptxdist] [PATCH] weston: version bump 6.0.1 -> 7.0.0

2019-09-02 Thread Michael Olbrich
On Fri, Aug 23, 2019 at 11:42:23PM +0200, Philipp Zabel wrote:
> Signed-off-by: Philipp Zabel 
> ---
>  rules/weston.in   |  5 +
>  rules/weston.make | 11 ---
>  2 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/rules/weston.in b/rules/weston.in
> index 42dcb9eeadbe..a2d1c9ec8fbe 100644
> --- a/rules/weston.in
> +++ b/rules/weston.in
> @@ -39,6 +39,7 @@ menuconfig WESTON
>   select GST_PLUGINS_GOOD1_RTPif WESTON_REMOTING && RUNTIME
>   select GST_PLUGINS_GOOD1_UDPif WESTON_REMOTING && RUNTIME
>   select PANGOif WESTON_IVISHELL_EXAMPLE
> + select PIPEWIRE if WESTON_PIPEWIRE

PIPEWIRE is not defined.

Michael

>   prompt "weston"
>   help
> Wayland compositor reference implementation
> @@ -110,6 +111,10 @@ config WESTON_IVISHELL_EXAMPLE
> application, a few demo clients and the weston.ini configuration for
> the IVI-Shell.
>  
> +config WESTON_PIPEWIRE
> + bool
> + prompt "pipewire plugin"
> +
>  config WESTON_REMOTING
>   bool
>   prompt "remoting plugin"
> diff --git a/rules/weston.make b/rules/weston.make
> index 1dd13bfb32d3..4c38fd2d1aa1 100644
> --- a/rules/weston.make
> +++ b/rules/weston.make
> @@ -15,9 +15,9 @@ PACKAGES-$(PTXCONF_WESTON) += weston
>  #
>  # Paths and names
>  #
> -WESTON_VERSION   := 6.0.1
> -LIBWESTON_MAJOR := 6
> -WESTON_MD5   := e7b10710ef1eac82258f97bfd41fe534
> +WESTON_VERSION   := 7.0.0
> +LIBWESTON_MAJOR := 7
> +WESTON_MD5   := cbfda483bc2501d0831af3f33c707850
>  WESTON   := weston-$(WESTON_VERSION)
>  WESTON_SUFFIX:= tar.xz
>  WESTON_URL   := 
> http://wayland.freedesktop.org/releases/$(WESTON).$(WESTON_SUFFIX)
> @@ -53,9 +53,11 @@ WESTON_CONF_OPT:= \
>   -Dcolor-management-lcms=false \
>   -Ddemo-clients=$(call ptx/truefalse,PTXCONF_WESTON_IVISHELL_EXAMPLE) \
>   -Ddesktop-shell-client-default=weston-desktop-shell \
> + -Ddoc=false \
>   -Dimage-jpeg=true \
>   -Dimage-webp=false \
>   -Dlauncher-logind=$(call ptx/truefalse,PTXCONF_WESTON_SYSTEMD_LOGIND) \
> + -Dpipewire=$(call ptx/truefalse,PTXCONF_WESTON_PIPEWIRE) \
>   -Dremoting=$(call ptx/truefalse,PTXCONF_WESTON_REMOTING) \
>   -Drenderer-gl=$(call ptx/truefalse,PTXCONF_WESTON_GL) \
>   -Dresize-pool=true \
> @@ -154,6 +156,9 @@ ifdef PTXCONF_WESTON_GL
>   @$(call install_lib, weston, 0, 0, 0644, 
> libweston-$(LIBWESTON_MAJOR)/wayland-backend)
>   @$(call install_lib, weston, 0, 0, 0644, 
> libweston-$(LIBWESTON_MAJOR)/gl-renderer)
>  endif
> +ifdef PTXCONF_WESTON_PIPEWIRE
> + @$(call install_lib, weston, 0, 0, 0644, 
> libweston-$(LIBWESTON_MAJOR)/pipewire-plugin)
> +endif
>  ifdef PTXCONF_WESTON_REMOTING
>   @$(call install_lib, weston, 0, 0, 0644, 
> libweston-$(LIBWESTON_MAJOR)/remoting-plugin)
>  endif
> -- 
> 2.20.1
> 
> 
> ___
> ptxdist mailing list
> ptxdist@pengutronix.de
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
ptxdist mailing list
ptxdist@pengutronix.de