On Sun, Oct 25, 2015 at 12:17:11PM +0530, saurabh wrote:

From 999005638f8d3f95075fdfdc6bf8f7ff88810f5d Mon Sep 17 00:00:00 2001

From: Saurabh Sengar <saurabh.truth@...>
Date: Sun, 25 Oct 2015 08:58:42 +0530
Subject: [PATCH] fixing the coding style changes

Attached a patch whic fixes the checkpatch.pl script error
Here, couple of static variables were initialise to 0 which
was violating the linux coding style standards.

diffstat for this patch is:
hub.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

To apply the patch, in the root of a kernel tree use:
patch -p1 < 0001-fixing-the-coding-style-changes.patch

Signed-off-by: Saurabh Sengar <saurabh.truth@...>
---
drivers/usb/core/hub.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 431839b..6abc4ab 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -49,7 +49,7 @@ static void hub_event(struct work_struct *work);
DEFINE_MUTEX(usb_port_peer_mutex);

/* cycle leds on hubs that aren't blinking for attention */
-static bool blinkenlights = 0;
+static bool blinkenlights;
module_param(blinkenlights, bool, S_IRUGO);
MODULE_PARM_DESC(blinkenlights, "true to cycle leds on hubs");

@@ -78,7 +78,7 @@ MODULE_PARM_DESC(initial_descriptor_timeout,
* otherwise the new scheme is used. If that fails and "use_both_schemes"
* is set, then the driver will make another attempt, using the other scheme.
*/
-static bool old_scheme_first = 0;
+static bool old_scheme_first;
module_param(old_scheme_first, bool, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(old_scheme_first,
"start with the old device initialization scheme");

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You sent multiple patches, yet no indication of which ones should be
applied in which order. Greg could just guess, but if you are
receiving this email, he guessed wrong and the patches didn't apply.
Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/SubmittingPatches for a description of how
to do this so that Greg has a chance to apply these correctly.

- You did not write a descriptive Subject: for the patch, allowing Greg,
and everyone else, to know what this patch is all about. Please read
the section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what a proper Subject: line should
look like.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

On 10/18/2015 07:41 PM, Satoru Ueda wrote:

Dear All,

The video for last Japan Technical Jamboree released. Please look into the wiki page
which you will see the link to YouTube.

http://elinux.org/Japan_Technical_Jamboree_54

The j-core stuff is in english. (Thrill to my attempt to stay upright
and coherent despite food poisoning! Then Geoff gave a nice VHDL tutorial.)

Rob

Dear All,

The video for last Japan Technical Jamboree released. Please look into the wiki page
which you will see the link to YouTube.

http://elinux.org/Japan_Technical_Jamboree_54

On 2015/10/13 16:11, Satoru Ueda wrote:

PS. Sorry for delay uploading video for the last Jamboree. Please wait for a few days.

Best regards,
S. Ueda
--
| TEL: +81-(0)50-3750-3882 FAX: +81-(0)50-3750-6620
| Strategic Alliance Sec. Software Design Technology Promotion Dept.
| Application Platform Design Div. SRDG, Sony Corp.

Dear All,

Please be advised that the next Japan Jamboree is scheduled on 13th November
at Nakano Sunplaza.

November 13th, Japan Technical Jamboree.
http://elinux.org/Japan_Technical_Jamboree_55


Best,
S. Ueda

PS. Sorry for delay uploading video for the last Jamboree. Please wait for a few days.


----- JAPANESE -----

各位、

11月13日（金）に日本テクニカルジャンボリーを開催いたします。
会場は中野サンプラザ、午前10時～午後5時頃までです。

ELC Europe開催直後です。ELC-Eのディスカッションアフターケアなど、歓迎です。
もちろん他の話題も歓迎です。

http://elinux.org/Japan_Technical_Jamboree_55

なお、前回のビデオの公開が遅れています。申し訳ありません。

以上。
上田


--
| TEL: +81-(0)50-3750-3882 FAX: +81-(0)50-3750-6620
| Strategic Alliance Sec. Software Design Technology Promotion Dept.
| Application Platform Design Div. SRDG, Sony Corp.

Dear All,

For all of your information, though it does not appear on the agenda,
some discussion about the GUI building tool will be taken place.

September 18th, Japan Technical Jamboree.
http://elinux.org/Japan_Technical_Jamboree_54


Best,
S. Ueda

----- JAPANESE -----

各位、

既にご案内しましたとおり、9月18日（金）に日本テクニカルジャンボリーを開催いたします。
会場は中野サンプラザ、午前10時～午後5時頃までです。

都合により、アジェンダには記載していませんが、CordovaなどWeb 技術を応用した
GUI 構築ツールの話しを予定しています。家電関係のみならず、自動車関連の機器構築にも
参考になるかと思います。

ELC Europe開催直前です。ELC-Eの事前ディスカッションなど、歓迎です。もちろん
他の話題も歓迎です。第52回（http://elinux.org/Japan_Technical_Jamboree_52）で
ありました、特許が切れたCPU技術を使って安価なCPUを作るという話しの続編があります。
もしかすると評価ボードを見ること（さらにもしかするとそれ以上の話し）もあるかも
知れません。<== 未確定情報。

http://elinux.org/Japan_Technical_Jamboree_54



以上。
上田

--
| TEL: +81-(0)50-3750-3882 FAX: +81-(0)50-3750-6620
| Strategic Alliance Sec. Software Design Technology Promotion Dept.
| Application Platform Design Div. SRDG, Sony Corp.

Dear All,

Please be reminded that the next Japan Jamboree is scheduled on September 18th
which means next Friday.

Please look into the wiki page for the detail:

http://elinux.org/Japan_Technical_Jamboree_54


Best regards,
S. Ueda

----- JAPANESE -----

各位、

既にご案内しましたとおり、9月18日（金）に日本テクニカルジャンボリーを開催いたします。
ELC Europe開催直前です。ELC-Eの事前ディスカッションなど、歓迎です。もちろん
他の話題も歓迎です。第52回（http://elinux.org/Japan_Technical_Jamboree_52）で
ありました、特許が切れたCPU技術を使って安価なCPUを作るという話しの続編があります。
もしかすると評価ボードを見ること（さらにもしかするとそれ以上の話し）もあるかも
知れません。<== 未確定情報。

http://elinux.org/Japan_Technical_Jamboree_54



以上。
上田

--
| TEL: +81-(0)50-3750-3882 FAX: +81-(0)50-3750-6620
| Strategic Alliance Sec. Software Design Technology Promotion Dept.
| Application Platform Design Div. SRDG, Sony Corp.

Dear All,

As I had informed, the next Japan Jamboree is scheduled on September 18th Friday.

Please look into the wiki page for the detail:

http://elinux.org/Japan_Technical_Jamboree_54


Best regards,
S. Ueda

----- JAPANESE -----

各位、

既にご案内しましたとおり、9月18日（金）に日本テクニカルジャンボリーを開催いたします。
ELC Europe開催直前です。ELC-Eの事前ディスカッションなど、歓迎です。もちろん
他の話題も歓迎です。

http://elinux.org/Japan_Technical_Jamboree_54



以上。
上田

--
| TEL: +81-(0)50-3750-3882 FAX: +81-(0)50-3750-6620
| Strategic Alliance Sec. Software Design Technology Promotion Dept.
| Application Platform Design Div. SRDG, Sony Corp.

Hello all,

The CE Workgroup of the Linux Foundation occasionally solicits contractors
for projects they are considering. The following projects are currently
under consideration for funding this year, and the CE Workgroup would be
interested in hearing from you if you would like to work on them (and be
paid for it!)

http://elinux.org/Supporting_open-spec_development_board_and_libraries_on_meta-debian
and
http://elinux.org/Real-time_GPU_computing_with_RT_PREEMPT
and
http://elinux.org/Support_mainline_Broadcom_wireless_driver_on_an_Android_platform

A little background might be worthhile...

For a while now, CEWG has been studying the feasibility of combining the
Yocto Project with Debian, to create a system for using the Debian
distribution for embedded projects. The first proposal above, intends
to solicit (paid) contributions to extending CEWGs project to more
hardware and to include more libraries in the target distribution.

The second proposal is research project into the issues of utilizing
GPU functionality in combination with Linux RT (specifically the RT_PREEMPT
patch set).

The third proposal is related to CEWGs ongoing device mainlining
project. This is the first of what may be a series of proposals to
fund specific technical work to reduce the amount of out-of-tree code
used in mobile devices. For more information about that project,
see http://elinux.org/CE_Workgroup_Device_Mainlining_Project
and http://elinux.org/Kernel_areas_of_focus_for_mainlining

If you are interested in any of the above topics, and in particular
are willing to get paid to work on some of these areas (producing
or enhancing open source software to benefit the entire embedded
industry), then please contact me.

Please also respond to this thread, or e-mail me directly if you
have any questions about the projects.

Thanks,
-- Tim Bird

--------
Senior Software Engineer, Sony Mobile Communications, Inc
Architecture Group Chair, CE Workgroup of the Linux Foundation

Greetings embedded linux developer,

As in past years, we are organizing a technical showcase
for conference participants at this year's
Embedded Linux Conference Europe.

See http://elinux.org/ELCE_2015_Technical_Showcase

The technical showcase is an opportunity:

* For Free and Open Source Software (FOSS) projects to show their
software in action, to grow their user and developer community
* For system developers to share their experience using FOSS
components (knowledge sharing with other system developers will need
to be the primary focus)
* For hardware makers to show the capabilities of their hardware,
provided what is demonstrated is mostly based on FOSS.
* For ELCE 2015 speakers to give a hands-on experience related to what
they presented, and have plenty of time to interact with people who
were interested in their presentation.

The technical showcase is set to happen on Tuesday evening (October 6).

If you are interested in showcasing something, please contact me (Tim Bird)
by September 7, and prepare a poster too. However, the sooner, the better, as
demonstration space will be limited.

My spam-resistant e-mail is: tim (dot) bird (at) sonymobile (dot) com

Thanks - I look forward to seeing you there.
-- Tim Bird

# Information about additional Jamboree on September 18th.
# 日程追加のお知らせです。（9月18日）

Dear All,

Please be noted that based on discussion in last Japan Jamboree, we have added one
more Jamboree in September. I am very happy to announce it to have one more
exiting day in 2015.

[ADDED]
- Japan Technical Jamboree #54
--> September 18th (Friday) at Nakano Sunplaza (from 10am to 5pm or later)

[ALREADY SCHEDULED]
- Japan Technical Jamboree #55
--> November 13th (Friday) at Nakano Sunplaza (from 10am to 5pm or later)

Tim, could you please book your schedule for the morning regular session on
September 18th?


Best regards,
S. Ueda

----- JAPANESE -----

各位、

9月の中野サンプラザの空き状況を確認したところ、18日（金）が使えることが判りました。
前回のジャンボリーで「やはり9月にも」という声がかなりありました。ですので、18日に
開催する事といたします。是非皆さんふるって参加願います。また近日中に9月18日用の
Wikiページを用意します。セッションの提案もお願いします。

【追加】第54回日本テクニカルジャンボリー
　→　9月18日（金）中野サンプラザ8階研修室（６）、午前10時～午後5時（延長アリ）

【こちらも実施します】第55回日本テクニカルジャンボリー
　→　11月13日（金）中野サンプラザ8階研修室（６）、午前10時～午後5時（延長アリ）


以上。
上田
--
| TEL: +81-(0)50-3750-3882 FAX: +81-(0)50-3750-6620
| Strategic Alliance Sec. Software Design Technology Promotion Dept.
| Application Platform Design Div. SRDG, Sony Corp.

On Tue, Jun 30, 2015 at 12:44 PM, Robert Schwebel
<r.schwebel@...> wrote:

On Fri, Jun 26, 2015 at 11:47:45AM -0300, Gustavo Sverzut Barbieri wrote:

Not yet. We're using an internal one, github issues for the public. Is there a
good free ML service you recommend?

I don't think so. Let's stay here for the moment :-)

https://lists.solettaproject.org/mailman/listinfo

people finally setup a mailman, we can still talk about it here or
start discussions about it there. I'm on both ml.


--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (19) 99225-2202
Contact: http://www.gustavobarbieri.com.br/contact

On Tue, Jun 30, 2015 at 1:39 PM, Robert Schwebel
<r.schwebel@...> wrote:

On Tue, Jun 30, 2015 at 01:30:04PM -0300, Gustavo Sverzut Barbieri wrote:

On Fri, Jun 26, 2015 at 11:47:45AM -0300, Gustavo Sverzut Barbieri wrote:

Not yet. We're using an internal one, github issues for the public. Is
there a good free ML service you recommend?

I don't think so. Let's stay here for the moment :-)

Our first impression when we saw soletta was: wow, they did it right.

That's nice to read. You mean just the build or the project itself? Share your
ideas and needs please :-)

The project itself. We are doing a lot of industrial automation
projects, and over the years, everyone invents the typical IO framework
stuff over and over again. Even worse, people with a different
background invent the same stuff in different ways:

- control people use Matlab/Simulink
- measurement guys use Labview
- factory automation does IEC61131 or IEC41499
- IoT folks use COAP etc.

Everyone reinvents wheels all over the place already, and now the IoT
people start working on the same things again.

There are many frameworks out there which have started with a university
background and have many deficiencies for professional use, and on the
other hand there are commercial frameworks which take things like safety
into account, but are not open source.

It's all a big mess.

yes, this is the case. And to make things worse, some assumptions from
Industrial or "old" embedded are making hard to get efficient user
consumer electronics. Take polling, for instance. Most software out
there is based on a fixed base tick, like Arduino or even some OS. If
you can't define timers, you can't reprogram your base tick and thus
cannot do a technique similar to Linux 'tickless' scheduler. That
means battery drain. Not an issue for industrial where you have
reliable power supply with backups/ups and where the lack of power
stops everything else. On homes, power outages are common, people want
to run on few duracell AAA batteries and so on... Network connectivity
is also similar, particularly if you take the wifi mess into account.
And upgrades, while before either you'd never upgrade or you'd do so
using experienced maintenance support, while with consumer electronics
you get get your inexperienced family member to do it and they have
nobody to call if things go wrong.

That's why we also plan to cover these bits with Soletta. We will
implement some sol_platform targets to reset to factory defaults,
emergency and upgrade for platforms we support, of course some rely on
having a hardware (i.e.: if we do have flash we can upgrade, if we
have EEPROM/NVRAM/... we can reset to factory defaults). Those would
be generic implementation, users can always provide their own and
still use the common API.

Did you take some time to try the linux-micro platform with posix
mainloop? We're using it for some demos with impressive footprint
(140kb userspace using bluetooth low-energy - bluez-peripheral +
muslc) And we can avoid using busybox or shell scripts :-) a single
binary does it all, including some services such as mounting from
/etc/fstab or setup ipv6.

IMHO what we need is a heterogeic hierarchical modeling framework, in
the spirit of Ptolemy II (but withaut Java), coupled with the practical
experience from GStreamer and v4l2 subdevices, but for process data.

soletta comes close :-)

great, let's work to do it :-)


--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (19) 99225-2202
Contact: http://www.gustavobarbieri.com.br/contact

On Tue, Jun 30, 2015 at 1:31 PM, Robert Schwebel
<r.schwebel@...> wrote:

On Tue, Jun 30, 2015 at 01:18:28PM -0300, Gustavo Sverzut Barbieri wrote:

ARGH!

We're fixing it, we found problems within Yocto as well.

The idea of moving to Kbuild is to make options interdependency easier
to track and do, as well as allowing it to be extremely configurable
for small os (for standard Linux we can compile everything as .so and
ship what we need)

Sorry about the inconvenience at this moment, but I believe as soon as
we get enough test it will be stable and a better option.

"
Use autotools
- Every custom config/makefile/build system is worse for everybody
than autotools is.
- We are all used to autotools, it works, nobody cares.
- It's only two simple files to edit and include in git, which are
well understood by many many people, not just you.

[...]

- And really, nothing but autotools is really an option. Just get
over it. Everything else is an experiment, and it will come back
to you sooner or later. Why? think cross compilation, installation/
uninstallation, build root integration, separate object trees,
standard adherence, tarball handling, make distcheck, testing,
portability between distros, ...
"

... from https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git/plain/README
and it is very, very true.

well, this is Lennart and Kay, I know them and the history of libabc.
To put in context, the idea was to enlighten all the kernel developers
how to do stuff in userspace as most of them really invented something
new (not even kbuild, but their own Makefiles with shell scripts).


But I get your point. let's give people few more weeks to get it ready
for once and for all, it now we can go back.

(BTW, for cross compile we will need two builds of Soletta as we use some
built binaries to generate other files we use. One native and another for
target)

Yes, I've seen that you already started inventing stuff like TOOLCHAIN_PREFIX.

I'm not much into Kbuild so I'm not reviewing these patches. If you
know a Kbuild standard way let them know (Leandro Dorileo is the one
doing it).


--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (19) 99225-2202
Contact: http://www.gustavobarbieri.com.br/contact

Hello all,

On Tue, 30 Jun 2015 17:44:54 +0200, Robert Schwebel wrote:

All experience from packaging > 600 tools for ptxdist shows, that any
package that tries to be smarter than autotools and invent their own
build system didn't take care of many important things.

Similar experience as a Buildroot core developer: autotools-based
packages are the ones that cause the least amount of trouble.

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

On Tue, Jun 30, 2015 at 01:30:04PM -0300, Gustavo Sverzut Barbieri wrote:

On Fri, Jun 26, 2015 at 11:47:45AM -0300, Gustavo Sverzut Barbieri wrote:

Not yet. We're using an internal one, github issues for the public. Is
there a good free ML service you recommend?

I don't think so. Let's stay here for the moment :-)

Our first impression when we saw soletta was: wow, they did it right.

That's nice to read. You mean just the build or the project itself? Share your
ideas and needs please :-)

The project itself. We are doing a lot of industrial automation
projects, and over the years, everyone invents the typical IO framework
stuff over and over again. Even worse, people with a different
background invent the same stuff in different ways:

- control people use Matlab/Simulink
- measurement guys use Labview
- factory automation does IEC61131 or IEC41499
- IoT folks use COAP etc.

Everyone reinvents wheels all over the place already, and now the IoT
people start working on the same things again.

There are many frameworks out there which have started with a university
background and have many deficiencies for professional use, and on the
other hand there are commercial frameworks which take things like safety
into account, but are not open source.

It's all a big mess.

IMHO what we need is a heterogeic hierarchical modeling framework, in
the spirit of Ptolemy II (but withaut Java), coupled with the practical
experience from GStreamer and v4l2 subdevices, but for process data.

soletta comes close :-)

And now you are removing autotools and replace that by Kconfig. I
don't think that this is a good idea, especially when things make
further progress and there will be modules with external
dependencies.

Our hope is that it will make life easier as we already have modules
with external dependencies such as udev and systemd. Tracking that
with autotools was becoming more and more of a burden, like conflicts
and depends.

It looks easier in the first place, but usually it just shifts the
complexity somewhere else.

Got you. That's why I started it using autotools. :-) upon request
from many people we decided to try Kbuild. If it does not work we can
always go back to autotools.

However, let's see where your current activities lead to.

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 |

On Tue, Jun 30, 2015 at 01:18:28PM -0300, Gustavo Sverzut Barbieri wrote:

ARGH!

We're fixing it, we found problems within Yocto as well. 

The idea of moving to Kbuild is to make options interdependency easier
to track and do, as well as allowing it to be extremely configurable
for small os (for standard Linux we can compile everything as .so and
ship what we need)

Sorry about the inconvenience at this moment, but I believe as soon as
we get enough test it will be stable and a better option. 

"
Use autotools
- Every custom config/makefile/build system is worse for everybody
than autotools is.
- We are all used to autotools, it works, nobody cares.
- It's only two simple files to edit and include in git, which are
well understood by many many people, not just you.

[...]

- And really, nothing but autotools is really an option. Just get
over it. Everything else is an experiment, and it will come back
to you sooner or later. Why? think cross compilation, installation/
uninstallation, build root integration, separate object trees,
standard adherence, tarball handling, make distcheck, testing,
portability between distros, ...
"

... from https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git/plain/README
and it is very, very true.

(BTW, for cross compile we will need two builds of Soletta as we use some
built binaries to generate other files we use. One native and another for
target)

Yes, I've seen that you already started inventing stuff like TOOLCHAIN_PREFIX.

Sigh.

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 |

On Tuesday, June 30, 2015, Robert Schwebel <r.schwebel@...> wrote:

On Fri, Jun 26, 2015 at 11:47:45AM -0300, Gustavo Sverzut Barbieri wrote:
> Not yet. We're using an internal one, github issues for the public. Is there a
> good free ML service you recommend?

I don't think so. Let's stay here for the moment :-)

Our first impression when we saw soletta was: wow, they did it right.

And now you are removing autotools and replace that by Kconfig. I don't
think that this is a good idea, especially when things make further
progress and there will be modules with external dependencies.

Our hope is that it will make life easier as we already have modules with external dependencies such as udev and systemd. Tracking that with autotools was becoming more and more of a burden, like conflicts and depends.

--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (19) 99225-2202
Contact: http://www.gustavobarbieri.com.br/contact

On Tuesday, June 30, 2015, Robert Schwebel <r.schwebel@...> wrote:

On Tue, Jun 30, 2015 at 05:44:54PM +0200, Robert Schwebel wrote:
> Our first impression when we saw soletta was: wow, they did it right.
> And now you are removing autotools and replace that by Kconfig. I don't
> think that this is a good idea, especially when things make further
> progress and there will be modules with external dependencies.
>
> Are you sure you took care of things like out-of-tree builds and cross
> compilation in a clean environment?
>
> All experience from packaging > 600 tools for ptxdist shows, that any
> package that tries to be smarter than autotools and invent their own
> build system didn't take care of many important things.

rsc@callisto:soletta$ make -j 4 ARCH=arm CROSS_COMPILE=/opt/OSELAS.Toolchain-2014.12.0/arm-cortexa8-linux-gnueabihf/gcc-4.9.2-glibc-2.20-binutils-2.24-kernel-3.16-sanitized/bin/arm-cortexa8-linux-gnueabihf-

...

rsc@callisto:soletta$ file build/soletta_sysroot/usr/bin/sol-fbp-runner
build/soletta_sysroot/usr/bin/sol-fbp-runner: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=ab8c0ae81e21690d44fe635fc817f906caca899b, not stripped

ARGH!

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 |
_______________________________________________
Celinux-dev mailing list
Celinux-dev@...
https://lists.celinuxforum.org/mailman/listinfo/celinux-dev

--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (19) 99225-2202
Contact: http://www.gustavobarbieri.com.br/contact

On Tue, Jun 30, 2015 at 05:44:54PM +0200, Robert Schwebel wrote:

Our first impression when we saw soletta was: wow, they did it right.
And now you are removing autotools and replace that by Kconfig. I don't
think that this is a good idea, especially when things make further
progress and there will be modules with external dependencies.

Are you sure you took care of things like out-of-tree builds and cross
compilation in a clean environment?

All experience from packaging > 600 tools for ptxdist shows, that any
package that tries to be smarter than autotools and invent their own
build system didn't take care of many important things.

rsc@callisto:soletta$ make -j 4 ARCH=arm CROSS_COMPILE=/opt/OSELAS.Toolchain-2014.12.0/arm-cortexa8-linux-gnueabihf/gcc-4.9.2-glibc-2.20-binutils-2.24-kernel-3.16-sanitized/bin/arm-cortexa8-linux-gnueabihf-

...

rsc@callisto:soletta$ file build/soletta_sysroot/usr/bin/sol-fbp-runner
build/soletta_sysroot/usr/bin/sol-fbp-runner: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=ab8c0ae81e21690d44fe635fc817f906caca899b, not stripped

ARGH!

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 |

On Fri, Jun 26, 2015 at 11:47:45AM -0300, Gustavo Sverzut Barbieri wrote:

Not yet. We're using an internal one, github issues for the public. Is there a
good free ML service you recommend?

I don't think so. Let's stay here for the moment :-)

Our first impression when we saw soletta was: wow, they did it right.
And now you are removing autotools and replace that by Kconfig. I don't
think that this is a good idea, especially when things make further
progress and there will be modules with external dependencies.

Are you sure you took care of things like out-of-tree builds and cross
compilation in a clean environment?

All experience from packaging > 600 tools for ptxdist shows, that any
package that tries to be smarter than autotools and invent their own
build system didn't take care of many important things.

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 |