* [ptxdist] Yocto
@ 2017-09-09 13:03 Erwin Rol
2017-09-09 15:54 ` Enrico Weigelt, metux IT consult
` (3 more replies)
0 siblings, 4 replies; 22+ messages in thread
From: Erwin Rol @ 2017-09-09 13:03 UTC (permalink / raw)
To: ptxdist
Hey all,
yes I know the topic is blasphemy ;-) but I was wondering if there are
ppl that made usecase comparisons between ptxdist and Yocto? My personal
experience with small systems (no GUI/X/wayland) is that ptxdist is
really easy to get going. With large systems that need QT 5.9,
webkitgtk/chromium, different OpenGL versions etc. is that ptxdist is
not always that easy. But I am not experienced enough with Yocto to say
if that will be easier/better.
So hence the question, anybody out there that tried both and picked
ptxdist (or yocto) for a reason ?
- Erwin
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-09 13:03 [ptxdist] Yocto Erwin Rol
@ 2017-09-09 15:54 ` Enrico Weigelt, metux IT consult
2017-09-09 16:33 ` Erwin Rol
2017-09-09 18:36 ` Tim Sander
` (2 subsequent siblings)
3 siblings, 1 reply; 22+ messages in thread
From: Enrico Weigelt, metux IT consult @ 2017-09-09 15:54 UTC (permalink / raw)
To: ptxdist
On 09.09.2017 15:03, Erwin Rol wrote:
Hi,
> yes I know the topic is blasphemy ;-)
burn the witch ! ;-)
> but I was wondering if there are > ppl that made usecase comparisons between ptxdist and Yocto? My personal
I'm currently in process of bringing up a board, where the vendor
only supplied an image built via yocto (based on an phycore-imx6,
so they just phycore's repos).
Finding out what kernel and bbx trees it uses, and the exact configs,
and how to images are built, turned out to be quite time consuming.
And the whole bitbake machinery is really slow.
--mtx
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-09 15:54 ` Enrico Weigelt, metux IT consult
@ 2017-09-09 16:33 ` Erwin Rol
2017-09-10 19:24 ` Enrico Weigelt, metux IT consult
0 siblings, 1 reply; 22+ messages in thread
From: Erwin Rol @ 2017-09-09 16:33 UTC (permalink / raw)
To: ptxdist
Hey all,
On Sat, 2017-09-09 at 17:54 +0200, Enrico Weigelt, metux IT consult
wrote:
> On 09.09.2017 15:03, Erwin Rol wrote:
> > but I was wondering if there are > ppl that made usecase comparisons between ptxdist and Yocto? My personal
>
> I'm currently in process of bringing up a board, where the vendor
> only supplied an image built via yocto (based on an phycore-imx6,
> so they just phycore's repos).
Exactly my problem, Yocto is becoming the Ubuntu of embedded Linux, and
like Ubuntu not everything is good about it. But vendors like Intel,
Xilinx, TI, etc. don't even know ptxdist exists, they all only offer
some Yocto layers.
> Finding out what kernel and bbx trees it uses, and the exact configs,
> and how to images are built, turned out to be quite time consuming.
Yeah the learning curve is steep, but that should not be a show stopper.
> And the whole bitbake machinery is really slow.
Over all I don't think bitbake is much slower than ptxdist, when
building from 0 to 100%.
But when you want to do edit->compile->update iterations the "startup"
time for bitbake seems to be a killer. With ptxdist I just call
"./ptxdist compile bla" and I have no noticeable delay compared to
native compiling. That is something I extensively use with ptxdist, and
for Yocto that doesn't work (at least I don't know how) :-/
- Erwin
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-09 13:03 [ptxdist] Yocto Erwin Rol
2017-09-09 15:54 ` Enrico Weigelt, metux IT consult
@ 2017-09-09 18:36 ` Tim Sander
2017-09-10 19:16 ` Robert Schwebel
2017-09-10 19:13 ` Robert Schwebel
2017-09-11 9:25 ` Guillermo Rodriguez Garcia
3 siblings, 1 reply; 22+ messages in thread
From: Tim Sander @ 2017-09-09 18:36 UTC (permalink / raw)
To: ptxdist
Hi Erwin
Am Samstag, 9. September 2017, 15:03:39 CEST schrieb Erwin Rol:
> yes I know the topic is blasphemy ;-) but I was wondering if there are
> ppl that made usecase comparisons between ptxdist and Yocto? My personal
> experience with small systems (no GUI/X/wayland) is that ptxdist is
> really easy to get going. With large systems that need QT 5.9,
> webkitgtk/chromium, different OpenGL versions etc. is that ptxdist is
> not always that easy. But I am not experienced enough with Yocto to say
> if that will be easier/better.
>
> So hence the question, anybody out there that tried both and picked
> ptxdist (or yocto) for a reason ?
I really would like to use ptxdist for my next private project where i would
like to try ROS. As far as i see, its already packaged for OpenEmbedded or
Angstrom. But as it has its own build tools and lots of python module
dependencies it might be to much to get all this stuff build with ptxdist.
So i might go the OpenEmbedded road even if i have already a nice ptxdist
project for the Atlas board i am using. Btw. if some is interested in this
Atlas board ptxdist can publish it somewhere.
As for the speed i would say that one of my biggest gripes with ptxdist is
that -je16 -ji16 builds fail for me. And with that many virtual cores
available its realy a pitty :-(.
Best regards
Tim
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-09 13:03 [ptxdist] Yocto Erwin Rol
2017-09-09 15:54 ` Enrico Weigelt, metux IT consult
2017-09-09 18:36 ` Tim Sander
@ 2017-09-10 19:13 ` Robert Schwebel
2017-09-11 9:25 ` Guillermo Rodriguez Garcia
3 siblings, 0 replies; 22+ messages in thread
From: Robert Schwebel @ 2017-09-10 19:13 UTC (permalink / raw)
To: ptxdist
Hi,
On Sat, Sep 09, 2017 at 03:03:39PM +0200, Erwin Rol wrote:
> yes I know the topic is blasphemy ;-) but I was wondering if there are
> ppl that made usecase comparisons between ptxdist and Yocto?
Well, it's not blasphemy at all. At Pengutronix, we are doing both,
depending on the usecase and on customer requirements. The main
arguments have already been brought up in this thread.
> My personal experience with small systems (no GUI/X/wayland) is that
> ptxdist is really easy to get going. With large systems that need QT
> 5.9, webkitgtk/chromium, different OpenGL versions etc. is that
> ptxdist is not always that easy. But I am not experienced enough with
> Yocto to say if that will be easier/better.
Like with all complicated technical tasks, things are usually easy if
somebody else has already done the job and you just need to reproduce
that. Yocto has many users, so quite a lot of things have already been
done by somebody. If you reach the point where you need to fix things
yourself, ptxdist is often easier, because Yocto/oe have quite some
complexity.
I suppose the rest of the story is personal preferences. When I started
ptxdist, having a tool which made it easy for a developer to concentrate
on his own tasks was very important to me. This is why ptxdist is
focussed on solving a deverloper's tasks (not necessarily an enduser
one's). But of course this is all a matter of taste, and we continue to
support both.
rsc
--
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-5555 |
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-09 18:36 ` Tim Sander
@ 2017-09-10 19:16 ` Robert Schwebel
2017-09-12 18:42 ` Tim Sander
0 siblings, 1 reply; 22+ messages in thread
From: Robert Schwebel @ 2017-09-10 19:16 UTC (permalink / raw)
To: ptxdist
On Sat, Sep 09, 2017 at 08:36:13PM +0200, Tim Sander wrote:
> I really would like to use ptxdist for my next private project where i
> would like to try ROS.
ROS1 or ROS2?
> As far as i see, its already packaged for OpenEmbedded or Angstrom.
I only know of old ROS packages made by the BMW folks, but this is
neither current versions of ROS, nor ROS2. Do you know of newer code?
> But as it has its own build tools and lots of python module
> dependencies it might be to much to get all this stuff build with
> ptxdist.
We started with ptxdist packaging for ROS2 two techweeks ago, but it is
a slow process if you have only one week per year. If someone would be
interested commercially, it would probably be possible to get a solution
faster, bug that didn't happen so far.
> As for the speed i would say that one of my biggest gripes with ptxdist is
> that -je16 -ji16 builds fail for me. And with that many virtual cores
> available its realy a pitty :-(.
Do you have logfiles for the fails? We are doing a lot of test builds
here, and if something breaks, we would like to know.
rsc
--
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-5555 |
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-09 16:33 ` Erwin Rol
@ 2017-09-10 19:24 ` Enrico Weigelt, metux IT consult
2017-09-10 20:09 ` Erwin Rol
0 siblings, 1 reply; 22+ messages in thread
From: Enrico Weigelt, metux IT consult @ 2017-09-10 19:24 UTC (permalink / raw)
To: ptxdist, Erwin Rol
On 09.09.2017 18:33, Erwin Rol wrote:
> Exactly my problem, Yocto is becoming the Ubuntu of embedded Linux, and > like Ubuntu not everything is good about it.
apropos Ubuntu: just had a ugly problem w/ my trusty notebook, which
ate up my precious time: dbus didn't come up (just because a dumb
file - /etc/machine-id - was missing), and therefore nothing else
(except plain console) worked. oh, and some of their kernel versions
suddenly miss wifi drivers, etc, etc ...
> But vendors like Intel, > Xilinx, TI, etc. don't even know ptxdist exists, they all only offer>
some Yocto layers.
chip vendors usually aren't the right parties for bsp's anyways,
leave that to board vendors, or the folks here :p
>> And the whole bitbake machinery is really slow. > > Over all I don't think bitbake is much slower than ptxdist, when>
building from 0 to 100%.
I'm talking about the engine itself. It always took me several minutes
of metadata processing before it even starts jobs. Especially while
hacking on some code, it's (IMHO) a big con if it metadata stuff
sometimes takes even longer than the actual build.
> But when you want to do edit->compile->update iterations the "startup"
> time for bitbake seems to be a killer. With ptxdist I just call
> "./ptxdist compile bla" and I have no noticeable delay compared to
> native compiling. That is something I extensively use with ptxdist, and
> for Yocto that doesn't work (at least I don't know how) :-/
Exactly. I need incremental builds almost all the day, so yocto would
just slow me down by magnitudes.
At that point I really wonder whether there's some really good pro
argument that might compensate that big con.
--mtx
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-10 19:24 ` Enrico Weigelt, metux IT consult
@ 2017-09-10 20:09 ` Erwin Rol
0 siblings, 0 replies; 22+ messages in thread
From: Erwin Rol @ 2017-09-10 20:09 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult; +Cc: ptxdist
On Sun, 2017-09-10 at 21:24 +0200, Enrico Weigelt, metux IT consult
wrote:
> On 09.09.2017 18:33, Erwin Rol wrote:
> > But when you want to do edit->compile->update iterations the "startup"
> > time for bitbake seems to be a killer. With ptxdist I just call
> > "./ptxdist compile bla" and I have no noticeable delay compared to
> > native compiling. That is something I extensively use with ptxdist, and
> > for Yocto that doesn't work (at least I don't know how) :-/
>
> Exactly. I need incremental builds almost all the day, so yocto would
> just slow me down by magnitudes.
>
> At that point I really wonder whether there's some really good pro
> argument that might compensate that big con.
I think Yocto assumes you develop your applications with the exported
SDK and than just build a final distribution when the application is
stable. The work flow seems very different from ptxdist. A bit like you
don't rebuild Redhat to test a linux program.
- Erwin
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-09 13:03 [ptxdist] Yocto Erwin Rol
` (2 preceding siblings ...)
2017-09-10 19:13 ` Robert Schwebel
@ 2017-09-11 9:25 ` Guillermo Rodriguez Garcia
2017-09-12 10:49 ` Alexander Dahl
3 siblings, 1 reply; 22+ messages in thread
From: Guillermo Rodriguez Garcia @ 2017-09-11 9:25 UTC (permalink / raw)
To: ptxdist
[-- Attachment #1.1: Type: text/plain, Size: 1510 bytes --]
Hello,
My team is using ptxdist for several projects on several different boards
and while
there are of course things that can be improved, we are very happy with it.
I have not used Yocto but have looked into it from time to time; my feeling
is that
it raises the level of abstraction too much ("too much" for my personal
preferences,
that is), thus making it difficult to see what is happening under the hood.
I share
your feeling that Yocto is becoming "the Ubuntu of the embedded world".
The main good thing about Yocto is that it is becoming hugely popular and
has a
very strong and active community. It would be great if the same would
happen with
ptxdist :-)
Guillermo
2017-09-09 15:03 GMT+02:00 Erwin Rol <mailinglists@erwinrol.com>:
> Hey all,
>
> yes I know the topic is blasphemy ;-) but I was wondering if there are
> ppl that made usecase comparisons between ptxdist and Yocto? My personal
> experience with small systems (no GUI/X/wayland) is that ptxdist is
> really easy to get going. With large systems that need QT 5.9,
> webkitgtk/chromium, different OpenGL versions etc. is that ptxdist is
> not always that easy. But I am not experienced enough with Yocto to say
> if that will be easier/better.
>
> So hence the question, anybody out there that tried both and picked
> ptxdist (or yocto) for a reason ?
>
> - Erwin
>
>
>
> _______________________________________________
> ptxdist mailing list
> ptxdist@pengutronix.de
--
Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com
[-- Attachment #1.2: Type: text/html, Size: 2273 bytes --]
[-- Attachment #2: Type: text/plain, Size: 91 bytes --]
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-11 9:25 ` Guillermo Rodriguez Garcia
@ 2017-09-12 10:49 ` Alexander Dahl
0 siblings, 0 replies; 22+ messages in thread
From: Alexander Dahl @ 2017-09-12 10:49 UTC (permalink / raw)
To: ptxdist
Hei hei,
Am Montag, 11. September 2017, 11:25:53 schrieb Guillermo Rodriguez
Garcia:
> The main good thing about Yocto is that it is becoming hugely popular
> and has a
> very strong and active community. It would be great if the same would
> happen with
> ptxdist :-)
FWIW: somewhere in between is buildroot [1] with a community bigger than
ptxdist and a lot more packages, but concepts more like ptxdist than
yocto, like build stages. I liked the buildroot documentation very much,
when I made my first package for it.
Greets
Alex
[1] https://buildroot.org/
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-10 19:16 ` Robert Schwebel
@ 2017-09-12 18:42 ` Tim Sander
2017-09-12 20:12 ` Robert Schwebel
2017-09-13 15:38 ` Michael Olbrich
0 siblings, 2 replies; 22+ messages in thread
From: Tim Sander @ 2017-09-12 18:42 UTC (permalink / raw)
To: ptxdist; +Cc: Robert Schwebel
On Sonntag, 10. September 2017 21:16:52 CEST Robert Schwebel wrote:
> On Sat, Sep 09, 2017 at 08:36:13PM +0200, Tim Sander wrote:
> > I really would like to use ptxdist for my next private project where i
> > would like to try ROS.
>
> ROS1 or ROS2?
I would like to have something not to dated. The website lists Lunar or
Kinetic Kame as versions...
> > As far as i see, its already packaged for OpenEmbedded or Angstrom.
>
> I only know of old ROS packages made by the BMW folks, but this is
> neither current versions of ROS, nor ROS2. Do you know of newer code?
This seems to be the repository for kinetic kame:
https://github.com/bulwahn/meta-ros/tree/kinetic-experimental
> > But as it has its own build tools and lots of python module
> > dependencies it might be to much to get all this stuff build with
> > ptxdist.
>
> We started with ptxdist packaging for ROS2 two techweeks ago, but it is
> a slow process if you have only one week per year. If someone would be
> interested commercially, it would probably be possible to get a solution
> faster, bug that didn't happen so far.
Well its my private tinkering project...
Do you have something i can build upon. I think one hurdle would be the custom
build system?
> > As for the speed i would say that one of my biggest gripes with ptxdist is
> > that -je16 -ji16 builds fail for me. And with that many virtual cores
> > available its realy a pitty :-(.
>
> Do you have logfiles for the fails? We are doing a lot of test builds
> here, and if something breaks, we would like to know.
Strange, i think if i just do a build of DistroKit i can observe that make
just stops. I can restart it so a
for i in `seq 1 10`; do ptxdist -je16 -ji16 go; done;
Works faster than a normal build, so the failure is that not all packages are
getting build?
Best regards
Tim
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-12 18:42 ` Tim Sander
@ 2017-09-12 20:12 ` Robert Schwebel
2017-09-12 21:33 ` Tim Sander
2017-09-13 15:38 ` Michael Olbrich
1 sibling, 1 reply; 22+ messages in thread
From: Robert Schwebel @ 2017-09-12 20:12 UTC (permalink / raw)
To: Tim Sander; +Cc: ptxdist
On Tue, Sep 12, 2017 at 08:42:26PM +0200, Tim Sander wrote:
> On Sonntag, 10. September 2017 21:16:52 CEST Robert Schwebel wrote:
> > On Sat, Sep 09, 2017 at 08:36:13PM +0200, Tim Sander wrote:
> > > I really would like to use ptxdist for my next private project where i
> > > would like to try ROS.
> >
> > ROS1 or ROS2?
>
> I would like to have something not to dated. The website lists Lunar or
> Kinetic Kame as versions...
That's all ROS1. ROS2 is a complete redesign.
> > > As far as i see, its already packaged for OpenEmbedded or Angstrom.
> >
> > I only know of old ROS packages made by the BMW folks, but this is
> > neither current versions of ROS, nor ROS2. Do you know of newer code?
>
> This seems to be the repository for kinetic kame:
> https://github.com/bulwahn/meta-ros/tree/kinetic-experimental
Lunar Loggerhead is the current release, right?
> > > But as it has its own build tools and lots of python module
> > > dependencies it might be to much to get all this stuff build with
> > > ptxdist.
> >
> > We started with ptxdist packaging for ROS2 two techweeks ago, but it is
> > a slow process if you have only one week per year. If someone would be
> > interested commercially, it would probably be possible to get a solution
> > faster, bug that didn't happen so far.
>
> Well its my private tinkering project...
> Do you have something i can build upon. I think one hurdle would be the custom
> build system?
Of course, that's the main issue. Sorry, nothing finished yet...
> > > As for the speed i would say that one of my biggest gripes with ptxdist is
> > > that -je16 -ji16 builds fail for me. And with that many virtual cores
> > > available its realy a pitty :-(.
> >
> > Do you have logfiles for the fails? We are doing a lot of test builds
> > here, and if something breaks, we would like to know.
>
> Strange, i think if i just do a build of DistroKit i can observe that make
> just stops. I can restart it so a
> for i in `seq 1 10`; do ptxdist -je16 -ji16 go; done;
> Works faster than a normal build, so the failure is that not all packages are
> getting build?
Hmm, we'll have a look.
rsc
--
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-5555 |
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-12 20:12 ` Robert Schwebel
@ 2017-09-12 21:33 ` Tim Sander
2017-09-13 5:42 ` Robert Schwebel
0 siblings, 1 reply; 22+ messages in thread
From: Tim Sander @ 2017-09-12 21:33 UTC (permalink / raw)
To: Robert Schwebel; +Cc: ptxdist
Am Dienstag, 12. September 2017, 22:12:15 CEST schrieb Robert Schwebel:
> On Tue, Sep 12, 2017 at 08:42:26PM +0200, Tim Sander wrote:
> > On Sonntag, 10. September 2017 21:16:52 CEST Robert Schwebel wrote:
> > > On Sat, Sep 09, 2017 at 08:36:13PM +0200, Tim Sander wrote:
> > > > I really would like to use ptxdist for my next private project where i
> > > > would like to try ROS.
> > >
> > > ROS1 or ROS2?
> >
> > I would like to have something not to dated. The website lists Lunar or
> > Kinetic Kame as versions...
>
> That's all ROS1. ROS2 is a complete redesign.
You are right, but i am wetting my toes... and the ros.org website does not
mention ros2. Do you think ros2 is already usable?
> > > > As far as i see, its already packaged for OpenEmbedded or Angstrom.
> > >
> > > I only know of old ROS packages made by the BMW folks, but this is
> > > neither current versions of ROS, nor ROS2. Do you know of newer code?
> >
> > This seems to be the repository for kinetic kame:
> > https://github.com/bulwahn/meta-ros/tree/kinetic-experimental
>
> Lunar Loggerhead is the current release, right?
Yes and kinetic is kind of a stable release, whatever that means.
> > > > But as it has its own build tools and lots of python module
> > > > dependencies it might be to much to get all this stuff build with
> > > > ptxdist.
> > >
> > > We started with ptxdist packaging for ROS2 two techweeks ago, but it is
> > > a slow process if you have only one week per year. If someone would be
> > > interested commercially, it would probably be possible to get a solution
> > > faster, bug that didn't happen so far.
> >
> > Well its my private tinkering project...
> > Do you have something i can build upon. I think one hurdle would be the
> > custom build system?
>
> Of course, that's the main issue. Sorry, nothing finished yet...
I am happy with anything borken. Its better than nothing...
> > > > As for the speed i would say that one of my biggest gripes with
> > > > ptxdist is
> > > > that -je16 -ji16 builds fail for me. And with that many virtual cores
> > > > available its realy a pitty :-(.
> > >
> > > Do you have logfiles for the fails? We are doing a lot of test builds
> > > here, and if something breaks, we would like to know.
> >
> > Strange, i think if i just do a build of DistroKit i can observe that make
> > just stops. I can restart it so a
> > for i in `seq 1 10`; do ptxdist -je16 -ji16 go; done;
> > Works faster than a normal build, so the failure is that not all packages
> > are getting build?
>
> Hmm, we'll have a look.
That would be really nice :-)
Tim
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-12 21:33 ` Tim Sander
@ 2017-09-13 5:42 ` Robert Schwebel
0 siblings, 0 replies; 22+ messages in thread
From: Robert Schwebel @ 2017-09-13 5:42 UTC (permalink / raw)
To: Tim Sander; +Cc: ptxdist
On Tue, Sep 12, 2017 at 11:33:42PM +0200, Tim Sander wrote:
> Am Dienstag, 12. September 2017, 22:12:15 CEST schrieb Robert Schwebel:
> > On Tue, Sep 12, 2017 at 08:42:26PM +0200, Tim Sander wrote:
> > > On Sonntag, 10. September 2017 21:16:52 CEST Robert Schwebel wrote:
> > > > On Sat, Sep 09, 2017 at 08:36:13PM +0200, Tim Sander wrote:
> > > > > I really would like to use ptxdist for my next private project where i
> > > > > would like to try ROS.
> > > >
> > > > ROS1 or ROS2?
> > >
> > > I would like to have something not to dated. The website lists Lunar or
> > > Kinetic Kame as versions...
> >
> > That's all ROS1. ROS2 is a complete redesign.
>
> You are right, but i am wetting my toes... and the ros.org website does not
> mention ros2. Do you think ros2 is already usable?
It's not about being ros2 a finished thing that you just can use, it's
about thinking about what might be relevant in the future. Technology
wise, ros2 solves some issues which have just "happened" with ros1
without being designed.
However, any ros package set for ptxdist would be welcome :-)
> > > > > As far as i see, its already packaged for OpenEmbedded or Angstrom.
> > > >
> > > > I only know of old ROS packages made by the BMW folks, but this is
> > > > neither current versions of ROS, nor ROS2. Do you know of newer code?
> > >
> > > This seems to be the repository for kinetic kame:
> > > https://github.com/bulwahn/meta-ros/tree/kinetic-experimental
> >
> > Lunar Loggerhead is the current release, right?
>
> Yes and kinetic is kind of a stable release, whatever that means.
Basically, like with all Linux things, you should not care about
"stable" at the beginning of a development. "Stable" is something you
can think of when your development is finished and you care about using
it for some real work. But as long as there are not even packages, start
with "top-of-tree".
> > > > We started with ptxdist packaging for ROS2 two techweeks ago, but it is
> > > > a slow process if you have only one week per year. If someone would be
> > > > interested commercially, it would probably be possible to get a solution
> > > > faster, bug that didn't happen so far.
> > >
> > > Well its my private tinkering project...
> > > Do you have something i can build upon. I think one hurdle would be the
> > > custom build system?
> >
> > Of course, that's the main issue. Sorry, nothing finished yet...
>
> I am happy with anything borken. Its better than nothing...
I'll look around if we have something that could be in a state to be
shared.
rsc
--
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-5555 |
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-12 18:42 ` Tim Sander
2017-09-12 20:12 ` Robert Schwebel
@ 2017-09-13 15:38 ` Michael Olbrich
2017-09-14 22:44 ` Tim Sander
1 sibling, 1 reply; 22+ messages in thread
From: Michael Olbrich @ 2017-09-13 15:38 UTC (permalink / raw)
To: ptxdist
On Tue, Sep 12, 2017 at 08:42:26PM +0200, Tim Sander wrote:
> On Sonntag, 10. September 2017 21:16:52 CEST Robert Schwebel wrote:
> > On Sat, Sep 09, 2017 at 08:36:13PM +0200, Tim Sander wrote:
> > > As for the speed i would say that one of my biggest gripes with ptxdist is
> > > that -je16 -ji16 builds fail for me. And with that many virtual cores
> > > available its realy a pitty :-(.
> >
> > Do you have logfiles for the fails? We are doing a lot of test builds
> > here, and if something breaks, we would like to know.
> Strange, i think if i just do a build of DistroKit i can observe that make
> just stops. I can restart it so a
> for i in `seq 1 10`; do ptxdist -je16 -ji16 go; done;
> Works faster than a normal build, so the failure is that not all packages are
> getting build?
It's probably a dependency problem exposed by the -jeX. If you see
something like this again, a logfile would be great. Stuff like that often
depends on the hardware so it's difficult to reproduce.
I've not seen Problems like this for some time.
Btw. don't use '-jeX -jiX' use '-j' instead. That uses a global jobserver
shared by all packages.
Michael
--
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-5555 |
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-13 15:38 ` Michael Olbrich
@ 2017-09-14 22:44 ` Tim Sander
2017-09-15 6:47 ` Michael Olbrich
0 siblings, 1 reply; 22+ messages in thread
From: Tim Sander @ 2017-09-14 22:44 UTC (permalink / raw)
To: ptxdist
Hi Micheal
Am Mittwoch, 13. September 2017, 17:38:24 CEST schrieb Michael Olbrich:
> On Tue, Sep 12, 2017 at 08:42:26PM +0200, Tim Sander wrote:
> > On Sonntag, 10. September 2017 21:16:52 CEST Robert Schwebel wrote:
> > > On Sat, Sep 09, 2017 at 08:36:13PM +0200, Tim Sander wrote:
> > > > As for the speed i would say that one of my biggest gripes with
> > > > ptxdist is
> > > > that -je16 -ji16 builds fail for me. And with that many virtual cores
> > > > available its realy a pitty :-(.
> > >
> > > Do you have logfiles for the fails? We are doing a lot of test builds
> > > here, and if something breaks, we would like to know.
> >
> > Strange, i think if i just do a build of DistroKit i can observe that make
> > just stops. I can restart it so a
> > for i in `seq 1 10`; do ptxdist -je16 -ji16 go; done;
> > Works faster than a normal build, so the failure is that not all packages
> > are getting build?
>
> It's probably a dependency problem exposed by the -jeX. If you see
> something like this again, a logfile would be great. Stuff like that often
> depends on the hardware so it's difficult to reproduce.
> I've not seen Problems like this for some time.
>
> Btw. don't use '-jeX -jiX' use '-j' instead. That uses a global jobserver
> shared by all packages.
Well i missed out this one. I know that this option didn't exist. But i didn't
realize that its now the recommended way. Its much better now, just with a few
passages where the cores are waiting for install io.
Probably you should update the default output of ptxdist. Because at least
2017.07.0 doesn't list -j as an option. So now i know why the -j options
slipped my attention :-).
Besides what is -je good for now?
Best regards
Tim
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-14 22:44 ` Tim Sander
@ 2017-09-15 6:47 ` Michael Olbrich
2017-09-15 11:02 ` Alm, Michael
0 siblings, 1 reply; 22+ messages in thread
From: Michael Olbrich @ 2017-09-15 6:47 UTC (permalink / raw)
To: ptxdist
Hi,
On Fri, Sep 15, 2017 at 12:44:13AM +0200, Tim Sander wrote:
> Am Mittwoch, 13. September 2017, 17:38:24 CEST schrieb Michael Olbrich:
> > Btw. don't use '-jeX -jiX' use '-j' instead. That uses a global jobserver
> > shared by all packages.
> Well i missed out this one. I know that this option didn't exist. But i didn't
> realize that its now the recommended way. Its much better now, just with a few
> passages where the cores are waiting for install io.
>
> Probably you should update the default output of ptxdist. Because at least
> 2017.07.0 doesn't list -j as an option. So now i know why the -j options
> slipped my attention :-).
I added it to the documentation but not the help text :-/. Fixed now.
> Besides what is -je good for now?
Nothing really. I left it there at first because I wasn't sure if there
were any problems with -j. Now it's just for backwards compatibility.
Regards,
Michael
--
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-5555 |
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-15 6:47 ` Michael Olbrich
@ 2017-09-15 11:02 ` Alm, Michael
2017-09-16 9:25 ` Michael Olbrich
0 siblings, 1 reply; 22+ messages in thread
From: Alm, Michael @ 2017-09-15 11:02 UTC (permalink / raw)
To: 'ptxdist@pengutronix.de'
Hi,
when was the -j option added to ptxdist? Which version?
Regards,
Michael
-----Ursprüngliche Nachricht-----
Von: ptxdist [mailto:ptxdist-bounces@pengutronix.de] Im Auftrag von Michael Olbrich
Gesendet: Freitag, 15. September 2017 08:47
An: ptxdist@pengutronix.de
Betreff: Re: [ptxdist] Yocto
Hi,
On Fri, Sep 15, 2017 at 12:44:13AM +0200, Tim Sander wrote:
> Am Mittwoch, 13. September 2017, 17:38:24 CEST schrieb Michael Olbrich:
> > Btw. don't use '-jeX -jiX' use '-j' instead. That uses a global
> > jobserver shared by all packages.
> Well i missed out this one. I know that this option didn't exist. But
> i didn't realize that its now the recommended way. Its much better
> now, just with a few passages where the cores are waiting for install io.
>
> Probably you should update the default output of ptxdist. Because at
> least
> 2017.07.0 doesn't list -j as an option. So now i know why the -j
> options slipped my attention :-).
I added it to the documentation but not the help text :-/. Fixed now.
> Besides what is -je good for now?
Nothing really. I left it there at first because I wasn't sure if there were any problems with -j. Now it's just for backwards compatibility.
Regards,
Michael
--
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-5555 |
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-15 11:02 ` Alm, Michael
@ 2017-09-16 9:25 ` Michael Olbrich
0 siblings, 0 replies; 22+ messages in thread
From: Michael Olbrich @ 2017-09-16 9:25 UTC (permalink / raw)
To: ptxdist
Hi,
On Fri, Sep 15, 2017 at 11:02:14AM +0000, Alm, Michael wrote:
> when was the -j option added to ptxdist? Which version?
It was first introduced in ptxdist-2015.06.0 but, if I remember correctly
there were still some parallel building issues to fix at the time.
It works quite well for me these days, but we find some remaining issues
occasionally. In most cases, just restarting ptxdist is sufficient.
Michael
--
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-5555 |
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-12 10:44 ` Alexander Dahl
@ 2017-09-12 13:29 ` Schenk, Gavin
0 siblings, 0 replies; 22+ messages in thread
From: Schenk, Gavin @ 2017-09-12 13:29 UTC (permalink / raw)
To: ptxdist
Hi,
> Am Montag, 11. September 2017, 07:14:00 schrieb Schenk, Gavin:
> > * No Tab-completition as PTXDIST offers it. 5 Stages, ~130packages and
> > 100.000 commands. I think a very usefull feature in PTXDIST!
>
> How does this work? I use zsh and have no tab completion for ptxdist,
> but miss it every now and then. :-/
>
In house workshops with e.g. Michael Olbrich are the solution for many problems ;-).
I am not familiar with zsh, here is the solution for bash that works for me:
1.) apt-get install bash-completion
2.) Create a file ~/.bash_completion with content
export PATH=/opt/ptxdist/bin:$PATH
. /opt/ptxdist/lib/ptxdist-2017.07.0/scripts/bash_completion
3.) If you use a symbolic link in your project to the ptxdist binary that is not called ptxdist ( I use only 'p' ) you have to add a line in ~/.bash_completion
complete -F _ptxdist_completion p
4.) Restart your bash .. enjoy
Examples:
[schenk:~/projects/OSELAS.BSP-Eckelmann] eckelmann/prototyp/systemA_sd_systemB_nand* ± ./p compile [TAB][TAB]
Display all 160 possibilities? (y or n)
[schenk:~/projects/OSELAS.BSP-Eckelmann] eckelmann/prototyp/systemA_sd_systemB_nand* ± ./p compile ./p drop host-rauc. [TAB][TAB]
host-rauc.compile host-rauc.extract host-rauc.get host-rauc.install host-rauc.prepare
Regards
Gavin Schenk
Eckelmann AG
Vorstand: Dipl.-Ing. Peter Frankenbach (Sprecher) Dipl.-Wi.-Ing. Philipp Eckelmann
Dr.-Ing. Marco Münchhof Dr.-Ing. Frank Uhlemann
Vorsitzender des Aufsichtsrats: Hubertus G. Krossa
Stv. Vorsitzender des Aufsichtsrats: Dr.-Ing. Gerd Eckelmann
Sitz der Gesellschaft: Berliner Str. 161, 65205 Wiesbaden, Amtsgericht Wiesbaden HRB 12636
http://www.eckelmann.de
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
2017-09-11 7:14 ` Schenk, Gavin
@ 2017-09-12 10:44 ` Alexander Dahl
2017-09-12 13:29 ` Schenk, Gavin
0 siblings, 1 reply; 22+ messages in thread
From: Alexander Dahl @ 2017-09-12 10:44 UTC (permalink / raw)
To: ptxdist
Hei hei,
Am Montag, 11. September 2017, 07:14:00 schrieb Schenk, Gavin:
> * No Tab-completition as PTXDIST offers it. 5
> Stages, ~130packages and 100.000 commands. I think a very usefull
> feature in PTXDIST!
How does this work? I use zsh and have no tab completion for ptxdist,
but miss it every now and then. :-/
Greets
Alex
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ptxdist] Yocto
[not found] <20170911063001.A6FE73EC2A2E_9B62D69B@mail.eckelmann.de>
@ 2017-09-11 7:14 ` Schenk, Gavin
2017-09-12 10:44 ` Alexander Dahl
0 siblings, 1 reply; 22+ messages in thread
From: Schenk, Gavin @ 2017-09-11 7:14 UTC (permalink / raw)
To: ptxdist
Hi,
>
> yes I know the topic is blasphemy ;-) but I was wondering if there are
> ppl that made usecase comparisons between ptxdist and Yocto? My personal
> experience with small systems (no GUI/X/wayland) is that ptxdist is
> really easy to get going. With large systems that need QT 5.9,
> webkitgtk/chromium, different OpenGL versions etc. is that ptxdist is
> not always that easy. But I am not experienced enough with Yocto to say
> if that will be easier/better.
>
> So hence the question, anybody out there that tried both and picked
> ptxdist (or yocto) for a reason ?
>
My company uses PTXDIST for quite some Years and we go very good with it! Thanks for this great tool.
In September 2016 I visited a Yocto workshop to have a look at it and build an opinion: Switch to Yocto, or stay with PTXDIST in the near future?
As a result I recommended to stick to PTXDIST, and have a look at Yocto from time to time because of the big community and its progress.
In September 2016 ( Maybe the information is a little outdated ) I noted:
PRO Yocto:
* Releasetrain every half year a new YOCTO. PTXDIST releases more often. Sometimes with only some bugfixes, sometimes major changes. Maybe a factor for planning stuff.
* Fully implemented in Python you can see/change everything. (Same concept in PTXDIST).
* Strict object-oriented design in the recipes.
* Licensing is part of the concept in Yocto. (Meanwhile PTXDIST support license reports, too)
* Documentation is extensive. (Meanwhile PTXDIST docu is getting better, too)
* Package based logfiles
* Reduce build time with state-caches (PTXDIST supports pre build packages, ccache and ICECREAM to reduce build time, too)
* In YOCTO you have free choice for package management (RPM, DEB, ipkg, opkg). That impressed me, as I remember.
And the trend in PTXDIST is to manage and update the whole firmware using RAUC, right?
* The build process splits up in tasks, and for every task YOCTO creates scripts that can be called manually. Useful for searching problems I guess.
(PTXDIST has its get, extract, prepare, compile, install, targetinstall stages)
CON Yocto:
* No nativ support for NFS boot (Maybe outdated?). The lecturer tried to sell it as an advantage, but I did not hear him ... I was in stage of shock.
* Strange in such a modern systems to build semantic on top of filenames (e.g. No '_' in package name because the must only be one '_' that separates name from version ...
* Changes in source (that must be marked see GPL...) are done in patchstacks (same in PTXDIST).
But there is even less support for this in Yocto than PTXDIST offers (git ptx-patches).
Everything has to be done manualy. For me THE big regress.
* No Tab-completition as PTXDIST offers it. 5 Stages, ~130packages and 100.000 commands. I think a very usefull feature in PTXDIST!
* The generic design of Yocto leaves you with a complicated, not really intuitive, folder structure. (Maybe a learning process)
* No graphical support, not even dialog based. In the lesson it seemed to me that you edit configfiles until the end of time...
Ok, so my conclusion was not 100% clear. Yocto is new, shiny, generic ... and not simple.
Hope my information is useful
Regards
Gavin Schenk
Eckelmann AG
Vorstand: Dipl.-Ing. Peter Frankenbach (Sprecher) Dipl.-Wi.-Ing. Philipp Eckelmann
Dr.-Ing. Marco Münchhof Dr.-Ing. Frank Uhlemann
Vorsitzender des Aufsichtsrats: Hubertus G. Krossa
Stv. Vorsitzender des Aufsichtsrats: Dr.-Ing. Gerd Eckelmann
Sitz der Gesellschaft: Berliner Str. 161, 65205 Wiesbaden, Amtsgericht Wiesbaden HRB 12636
http://www.eckelmann.de
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2017-09-16 9:25 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-09 13:03 [ptxdist] Yocto Erwin Rol
2017-09-09 15:54 ` Enrico Weigelt, metux IT consult
2017-09-09 16:33 ` Erwin Rol
2017-09-10 19:24 ` Enrico Weigelt, metux IT consult
2017-09-10 20:09 ` Erwin Rol
2017-09-09 18:36 ` Tim Sander
2017-09-10 19:16 ` Robert Schwebel
2017-09-12 18:42 ` Tim Sander
2017-09-12 20:12 ` Robert Schwebel
2017-09-12 21:33 ` Tim Sander
2017-09-13 5:42 ` Robert Schwebel
2017-09-13 15:38 ` Michael Olbrich
2017-09-14 22:44 ` Tim Sander
2017-09-15 6:47 ` Michael Olbrich
2017-09-15 11:02 ` Alm, Michael
2017-09-16 9:25 ` Michael Olbrich
2017-09-10 19:13 ` Robert Schwebel
2017-09-11 9:25 ` Guillermo Rodriguez Garcia
2017-09-12 10:49 ` Alexander Dahl
[not found] <20170911063001.A6FE73EC2A2E_9B62D69B@mail.eckelmann.de>
2017-09-11 7:14 ` Schenk, Gavin
2017-09-12 10:44 ` Alexander Dahl
2017-09-12 13:29 ` Schenk, Gavin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox